Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Linux Software

Linux 2.2.0pre6 Released 86

Chad Miller was the first to tell us that pre6 is out. Remember that the new kernel.org mirrors are up and running- you can hit ftp.<country code>.kernel.org for a mirror near you. Help ensure that everyone can download it faster so we can hammer this thing smooth for the 2.2 final.
This discussion has been archived. No new comments can be posted.

Linux 2.2.0pre6 Released

Comments Filter:
  • Install debian
    Then you could just type "apt-get install libncurses4-dev" and it would download ncurses and all the dependencies automatically and set them up.
  • I'm betting that the reasons for the different names has something to do with RFC standards; perhaps the ppp-* and net-pf-* names are standard across different OS's. I think it could be a bit better documented, however.

    Anyway,

    I think what it is is that ppp-compress-26,24 go t o ppp_deflate, and ppp-compress-21 goes to bsd_comp.

    From /usr/include/linux/ppp-comp.h
    ----
    #define CI_BSD_COMPRESS 21 /* config. option for BSD-Compress */
    #define CI_DEFLATE 26 /* config option for Deflate */
    #define CI_DEFLATE_DRAFT 24 /* value used in original draft RFC *
  • As the only changes to the ISDN code are cosmetic, it's a fairly safe bet that it still won't work.
    The ISDN link comes up and works for a few hours, but then fails, complaining
    HiSax: if_command 14 called with invalid driverId 0!
    until it's rebooted.
  • Report it to the list.

    I did. [linuxhq.com] And I've even got it back from linux-kernel, after the obligatory 2-day delay.

    But there's no point trying to fix it - we just need to put the latest CVS code into 2.2.

  • If you read his plea for help carefully, you'll see he mentioned he _was_ running ppp-2.3.5. RTFQ.

    To the original poster: you need to give more info. You say you've managed to ping and nslookup. Did you do that with IP addresses or domain name addresses?

    Also, I'll mention a small problem I had when I moved up to ppp-2.3.5. It would dial fine, and connect, but wouldn't let me telnet and lynx anywhere (didn't try ping and/or nslookup). I made a slight change to my ppp-on script to add a defaultroute option to my pppd command line. Now it looks like this:

    exec /usr/sbin/pppd -d /dev/modem 115200 \
    defaultroute \
    $LOCAL_IP:$REMOTE_IP \
    connect $DIALER_SCRIPT

    Hope this helps.

    ---

  • I've found ftp2.us.kernel.org to always have the newest stuff, while ftp.us.kernel.org takes forever.

    I wonder if there is an ftp3.
  • So when exactly is the actual 2.2.0 coming out?

    Linus said in a Boot interview that it would be out by the end of October. Then he said it'd be out by Christmas. It's January 9th and I'm still waiting.
  • We had a Cyrix 6x86-PR200 at our school that was doing exactly this. The machine was running one of the 2.0 kernels (probably 2.0.27 or so.) We never fixed the problem, as our plans for the machine changed and it became a web server as opposed to a shell-account machine. We just assumed that it was a problem with the Cyrix CPU as the computer was being weird and crashing in a lot of other ways too. Guess we were wrong.
  • It should be a matter of doing what you said - downloading the sources, exploding the .tar.gz/.tar.bz2, and running the various make commands. In addition to make dep; make clean; make zImage you will want to run one of make config/make menuconfig/make xconfig so that you can choose what nifty new stuff you want to go into the kernel. Just be sure you download the complete sources and not the patch. When you patch, you need to have the patch for each version increment from the one you have now. Moving from 2.0.36 to 2.2.0pre6 would require a lot of patches (I am assuming that one would have to work their way through the entire 2.1.x series first, but I may be wrong.). However, patches are nice for single-increment upgrades. There is a script that installs the patches for you, it's in /usr/src/linux/scripts/patch-kernel or something like that.

    One other thing you may want to do is to take your old /usr/src/linux and make sure it is a symlink to /usr/src/linux-2.x.xx, and if not make it like this. Then be sure the new version expands into /usr/src/linux-2.2.blah, and then change the /usr/src/linux symlink. This way you can go back to the old kernel if things go wrong.

    Also, once you type make zImage, the finished file is in usr/src/linux/arch/i386/boot. (Unless someone changed it - it's been a while.) This goes into your RedHat /boot directory. Keep the old kernel image file and name the new one something different. Then edit /etc/lilo.conf, add an entry for the new kernel, and run /sbin/lilo. If you are using an initial ramdisk because your root filesystem is on a device that runs off a kernel module, things may be hairy. Compiling whatever device you need into the kernel should allow you to avoid having to deal with this.

    Hope this all helps.
  • when it's ready (TM)
  • It worked fine for me with one of the previous 2.2.0-pre kernels, but it screwed up X so I went back to the regular console. Why would anyone want to use it anyway? Apart from the cute penguin logo during bootup I couldn't detect any change.

    (FWIW, my card is ATI Xpression+ - 264VT.)
  • by osu-neko ( 2604 )

    Well, gosh, if Linus Torvalds doesn't know, what makes you think some idiot on /. is going to be able to give you a better estimate?

    Here's a clue for you, since you appear to need one: No one knows the answer to your question! Anyone who gives you an answer is guessing at best. We don't have access to a time machine which would enable us to go into the future, find out when it was done, come back and tell you. Deal with it...


    --
    Starting reality daemon: realityd

  • Looks like your build tree got corrupted somehow...
    arch/i386/lib/checksum.c was renamed .../old-checksum.c and replaced by asm-code .../checksum.S
    In short, checksum.c should not exist.

    To get back up to spec, you'll have to...

    1. Cross your fingers :)
    2. Roll back to an older (vanilla) kernel.
    3. Do a 'make distclean'.
    4. Make sure that you have the latest version of patch(2.5 should be OK)
    5. Apply the patches in order (yes, all over again).
  • you can reset the console blindly by typing:

    reset



    ;)

    -l
  • I just installed 2.2.0-Pre6 and when I booted the kernel hanged on PCI probing for hardware.
    I booted once more and this time it worked. The kernel I have used previously was 2.1.131 and it has never hanged that way. Anyone more who noticed this?
  • Please report to me (zivav@cs.bgu.ac.il), since
    ATI cards are the most interesting cases:
    I have the exact same model working in one machine
    and not-working in another machine, without
    a simple explanation.

    I already have 13 reports on mach64 based cards,
    but still can't predict if a given card will work
    with the VESA driver.
  • Does dmesg show checksum errors?
    If so, I have a workaround.
  • in line 1644 of /usr/src/linux/net/ipv4/tcp_ipv4.c
    a line that begins with
    if(tcp_v4_check(th,if(tcp_v4_check(th,
    chan ge to
    if(0&tcp_v4_check(th,...
    (so that the condition is always false)
    Then, recompile and reboot.
    It works for me.
  • all,

    my compile always stops in arch/i386/lib
    with the following error message:

    make[1]: Entering directory `/usr/src/linux-2.2.0-pre6/arch/i386/lib'
    make all_targets
    make[2]: Entering directory `/usr/src/linux-2.2.0-pre6/arch/i386/lib'
    gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o checksum.o checksum.c
    checksum.c:200: redefinition of `csum_partial_copy'
    checksum.c:105: `csum_partial_copy' previously defined here
    {standard input}: Assembler messages:
    {standard input}:188: Fatal error: Symbol csum_partial_copy already defined.
    make[2]: *** [checksum.o] Error 1
    make[2]: Leaving directory `/usr/src/linux-2.2.0-pre6/arch/i386/lib'
    make[1]: *** [first_rule] Error 2
    make[1]: Leaving directory `/usr/src/linux-2.2.0-pre6/arch/i386/lib'
    make: *** [_dir_arch/i386/lib] Error 2

    However by looking at the code i notice a
    csum_partial_copy and a csum_partial_copy_fromuser, and not twice
    csum_partial_copy.

    So whats going on?
  • thanks guys, as you correctly stated, checksum.c
    should not be there. so i just deleted it and the
    build went just fine.

    However I got a new problem:


    startx fails with

    Cannot open mouse (Operation not supported by device)

    Mouse support is compiled in, however. Could that be related to the corrupted tree i presumably got?
  • it seems there is something wrong with my mouse.
    when i do startx, i get

    Cannot open mouse (Operation not supported by device)

    I checked, and ps/2 mouse support *is* compiled in. This is on 2.2.0pre6 on a Sony Vaio.

    what gives?
  • by Freud ( 5279 )
    I'm running Red Hat 5.2 on a compaq deskpro, 200 Mhz. I've got on board adaptec scsi, and I have the built on network card (netflex i believe..). Whats the problem u have with it?
  • I'm having trouble with BOOTP, which is like DHCP. I've just remembered that there were issues with 2.1 and DHCP. Does anyone know where I can find details about this?

    Also, should lockd be spewing messages to my console all the time?

  • When you download this pre, install and submit bug list! Not sooner!

  • ftp.us.kernel.org: latest pre5
    ftp.ru.kernel.org: latest pre6 !

  • net-pf-3 should be off because no ax25 module is available yet.. net-pf-4 should be off if you don't use the ipx module, and net-pf-5 should be off if you don't use the appletalk module.

    I have no idea why it would be calling ppp-compress instead of bsd_comp and ppp_deflate (both are ppp modules), but I would assume you could alias any of those ppp-compress modules to bsd_comp or ppp_deflate. =)

    EraseMe
  • I have a RedHat 5.2 system that I had running 2.0.36 without any problems. It is a dual pentium pro system so I decided that it would be to my advantage to upgrade to 2.2 pre 4 for performance reasons. When I did so, things appeared to be working. However, it crashes everytime I use repquota to check user quotas.

    I compiled quota support into my new 2.2 kernel and everything. However the crash is very dependent and it leaves the system running but nobody capable of logging in. Has anybody else had this problem? Has it been fixed some time between pre 4 and pre 6? Or might it be something that I am doing dreadfully wrong. I would have tried upgrading to 2.2 pre 6 except that I cannot afford to crash the computer because it is in a locked closet and a hassle for me to get in to reboot manually.

    Please email me if you have any ideas.
    Thanks!
  • Right now there is ftp1.us.kernel.org up to ftp11.us.kernel.org; "ftp.us.kernel.org" gives you a random site.
  • How many times do we have to answer this same effing question?

    WHEN IT'S READY, AND NOT ONE PICOSECOND BEFORE.

    At least one lamer asks this question for EACH pre release. When will you folks get the point?

    BTW, "ready" means "when Linus Torvalds and Alan Cox think it's ready, announce that they think it's ready, and don't get any credible flames from the developers list".

    Oh; and an equally credible answer is "it's ready now, use it and shut up yer whining".
  • The answer to this problem is in the FAQ on www.x11amp.org [x11amp.org]. What you need to do is turn off skins, or unzip the skin to a directory and run it that way. (That's what I'm doing and it works fine in 2.2pre4)

    Chris
  • Unfortunately, I can't get into ftp.uk.linux.org to pick up the inevitable pre6ac1 patch. Perhaps kernel.org needs to start mirroring that list of patches as well.

  • I can maintain a ppp dialup connection for 10 days or more with 2.0.x, but not for more then a few hours with 2.2.x. Yes, I am using the lastest ppp. I also noticed some neat things in my syslog. Anybody else having this problem?

    Jan 9 14:09:08 bd pppd[770]: Using interface ppp0
    Jan 9 14:09:08 bd pppd[770]: Connect: ppp0 /dev/ttyS1
    Jan 9 14:09:11 bd modprobe: can't locate module ppp-compress-21
    Jan 9 14:09:11 bd modprobe: can't locate module ppp-compress-26
    Jan 9 14:09:11 bd modprobe: can't locate module ppp-compress-24
    Jan 9 14:09:11 bd pppd[770]: local IP address
    Jan 9 14:09:11 bd pppd[770]: remote IP address 38.1.1.1
    Jan 9 14:10:00 bd modprobe: can't locate module net-pf-4
    Jan 9 14:10:00 bd modprobe: can't locate module net-pf-5
    Jan 9 14:20:00 bd modprobe: can't locate module net-pf-4
    Jan 9 14:20:00 bd modprobe: can't locate module net-pf-5
  • (*)Console Drivers
    (*)ATI Mach64 Display Support

    works like a charm here ... although, I couldnt get vga=anything to work on boot so I just manually used fbset to set the frame buffer mode I wanted in one of my rc files. It also messes up the mach64 xserver .. I had to switch to vesa (fbserver works too, but its a pain)


    talking windows users is where I draw the line ..
  • I have observed the exact same problem. It happens with every kernel after 2.1.108, where there was a "major PPP rewrite". I've sent detailed bug reports to the PPP maintainer and to the listed author of the rewrite with no answer (I even said "what can I do to help track this down", but no reply -- grr!), and I've searched all over dejanews and mailing list archives, but (until today) haven't found anyone with the same problem.

    To anyone who would offer suggestions:

    1. Yes, we're using the latest pppd.
    2. Yes, we have routing set up correctly.
    3. Yes, we have our PPP options set up correctly.

    If you don't believe me, then note that the exact same configuration works *great* in 2.1.108 and below, and that IP, ICMP, and UDP all work fine; it's only TCP that breaks.

    The only clue I have is that people with later kernels and PPP have suffered from "TCP stalls". This is a different, but similar problem, where TCP becomes very very slow sometimes. Perhaps the extra latency of the Ricochet turns "very very slow sometimes" into "never works ever"? Kinda dubious, but...

    It's too bad Amit didn't include his e-mail, I'd like to get in touch with him.


    P.S. Several times recently, I've had a problem, tried to diagnose it or search for a fix, with the same results -- some combination of the following:

    1. I search DejaNews and mlist archives, and find others with the same (or similar problems), who have posted about them but gotten no reply (or maybe one or two unhelpful replies).

    2. I post myself, and get no reply (or maybe one or two unhelpful replies).

    3. I e-mail the maintainer, and get no reply.

    4. I fix the problem, and post a patch to a mailing list, and get no reply.

    5. I mail the patch to the maintainer, and get no reply, and it isn't folded in. In both (4) and (5), I include "bug fix patch!" prominently in the subject line.

    This gets frustrating after a while. I think a major problem with open source (and Linux in particular) is that the low S/N ratio of public channels makes it very difficult to be heard, especially if you're not a well known contributor, or you have a relatively esoteric problem that doesn't happen to (directly) affect loads of other people.
  • I have the same problem, and no, there are no checksum errors. (In fact, there are no errors at all in dmesg or anywhere else.)
  • Well, I'm going to post to the linux-ppp mailing list. We'll see if we can get some response on this issue (at least some clue about how I might go about tracking the problem down).
  • by Basil ( 14051 )
    Hi,

    I had this problem too ( with all the 2.2.0pre series ), but a friend ( Hi Victor! ) mentioned to me that there is a 'fix' on the X11amp web site.

    Not a fix really, but the problem is when using zipped skins. If you unzip your skin, and point to the dir in your config file ( instead of the zip file ) everything works fine. Or just do not use skins.

    Bas
  • i've found pre6 to be VERY swap-happy, to the extent that once in a while it will swap like nutz, leaving about only 3 or 4 meg of stuff resident, this is on a 64meg machine. doing anything in netscape is unbearable, unfortunately had to buttshuffle over to the win98 box to post this...ugh..
  • when will the actual 2.2 kernel be out?
  • I tried to compile the 2.2pre5 on a SS20 with RedHat 5.1 kernel 2.0.34. The make dep; make clean were ok but it crashed on the file of the make vmlinux. Can someone help me with this one, I never compiled a linux kernel on a Sparc before.
  • Has anyone watched the console and get "TCPv4 bad checksum from (whatever IP)".

    I got this on pre 2 and pre 5 but 2.0.36 worked ok

    This tends to slow the connection esp. on long downloads
    Any ideas?
  • has anybody tried real player with any success on the new 2.2.0 pr kernels? i keep getting:

    ***audio: write error

    messages...local or streamed.
  • I just compiled my first 'pre' kernel last nite, and upon reboot, it says that I'm still in 2.1.132 yet when i uname -r it brings back 2.2.0pre6. Is this normal?

    Also, anyone else have any problems with DHCP with 2.2?


  • Nope, that didn't help at all, besides, it was working in 2.1.132.

    I just manually entered the ip and mask and everything looks dandy.


  • PPP worked as recently as pre5, then all of a sudden went poof when I went to pre6. I'll probably just back up to pre1 or something. But any ideas on this? I setserial everything correctly like I normally do, and poof. No response from modem.
  • If you are from the first console, press CTRL-ALT-F1 to read your error message.

    I can't get myself through the KDE that I have installed on my system as well with the new kernel. I think it would be my old library file which need update. Anyway, I am waiting for the Redhat 5.3 or SuSE 6.0 or whatever that comes with Kernel v2.2

Real programmers don't bring brown-bag lunches. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.

Working...