New USB HID driver in -ac series
I upgraded from 2.4.5-ac2 to 2.4.5-ac5 recently, and all seemed well. However, I noticed that the scrollwheel on my mouse wasn't working very well. I have that new Logitech cordless optical mouse, so my first thought was that the batteries were low, but it was late at night, and I didn't have spares, so I just dealt with it. I got new batteries, and the problem didn't go away. Booted into windows, and the scrollwheel worked fine. I then remembered seeing the HID drivers in Alan's changelog. I booted back into -ac2, and the scrollwheel worked fine. -ac5 and -ac6 both show this problem, and I assume every kernel since the HID driver update has it as well. Here's the contents of /proc/bus/usb/devices: T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 11/900 us ( 1%), #Int= 1, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=058f ProdID=9254 Rev= 1.00 S: Manufacturer=ALCOR S: Product=Generic USB Hub C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc=118/900 us (13%), #Int= 1, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d400 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=c501 Rev= 9.10 S: Manufacturer=Logitech S: Product=USB Receiver C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 50mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=hid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl= 10ms Hope this is of some help Nathan -- Nathan Walp || [EMAIL PROTECTED] GPG Fingerprint:|| http://faceprint.com/ 5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E PGP signature
New USB HID driver in -ac series
I upgraded from 2.4.5-ac2 to 2.4.5-ac5 recently, and all seemed well. However, I noticed that the scrollwheel on my mouse wasn't working very well. I have that new Logitech cordless optical mouse, so my first thought was that the batteries were low, but it was late at night, and I didn't have spares, so I just dealt with it. I got new batteries, and the problem didn't go away. Booted into windows, and the scrollwheel worked fine. I then remembered seeing the HID drivers in Alan's changelog. I booted back into -ac2, and the scrollwheel worked fine. -ac5 and -ac6 both show this problem, and I assume every kernel since the HID driver update has it as well. Here's the contents of /proc/bus/usb/devices: T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 11/900 us ( 1%), #Int= 1, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=058f ProdID=9254 Rev= 1.00 S: Manufacturer=ALCOR S: Product=Generic USB Hub C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc=118/900 us (13%), #Int= 1, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d400 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=c501 Rev= 9.10 S: Manufacturer=Logitech S: Product=USB Receiver C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 50mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=hid E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl= 10ms Hope this is of some help Nathan -- Nathan Walp || [EMAIL PROTECTED] GPG Fingerprint:|| http://faceprint.com/ 5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E PGP signature
Re: random reboots
I've gotten a lot more response to this than I'd ever dreamed, but I figured out the problem on my own... I have (had) one of those exhaust fans that fits into a PCI/ISA slot, and it died. Not only did it die, but it started creating heat of it's own. I don't think the video card adjacent to it appreciated this a whole lot. I removed the dead fan, and everything is back to normal, I just need to go get a new fan to make myself feel better ;-) The 1007 bios, and ac14 have been perfectly stable, so no worries about either. Thanks, Nathan Petr Vandrovec wrote: > > On Tue, Apr 24, 2001 at 12:18:42PM -0400, Nathan Walp wrote: > > I upgraded the BIOS on this Asus A7V sometime in the past week, but I > > honestly don't remember when. From 1005C to 1007. This was released in > > march, so I assumed it was pretty stable, but it could be the cause. > > I'm going to go downgrade now, but is this more likely to be a kernel > > bug, or a hardware bug/new bios bug? > > No problem here. I'm using 1007 since its release in first half > of March. > > Linux version 2.4.3-ac12-amd (root@ppc) (gcc version 3.0 20010402 (Debian >prerelease)) #1 Mon Apr 23 02:31:13 CEST 2001 > ... > Kernel command line: BOOT_IMAGE=Linux ro root=2105 video=matrox:vesa:0x105,fv:85 >devfs=nomount > Initializing CPU#0 > Detected 1009.013 MHz processor. > ... > CPU: AMD Athlon(tm) Processor stepping 02 > Enabling fast FPU save and restore... done. > ... > apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) > ... > > Except that I got 'ide only func: 14' today with my Promise PDC20265 > (which looks strange to me - either all Intel, VIA and Promise have > same bug in their UDMA hardware, or there is a bug in Linux IDE > driver...) (I had to reboot because of kernel somehow believed that > it read some garbage instead of MBR from hdg, so I could not run my > repartitioning session, as I found no way to invalidate hdg kernel > cache). > But machine for sure does not spontaneously reboot. And I have > enabled local apic in kernel configuration. All previous kernels > were built with Debian's 2.95.3-something, ac12 was built with > gcc-3.0, as I wanted to update anyway, and ac12 just gave me a reason. > Best regards, > Petr Vandrovec > [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: random reboots
I've gotten a lot more response to this than I'd ever dreamed, but I figured out the problem on my own... I have (had) one of those exhaust fans that fits into a PCI/ISA slot, and it died. Not only did it die, but it started creating heat of it's own. I don't think the video card adjacent to it appreciated this a whole lot. I removed the dead fan, and everything is back to normal, I just need to go get a new fan to make myself feel better ;-) The 1007 bios, and ac14 have been perfectly stable, so no worries about either. Thanks, Nathan Petr Vandrovec wrote: On Tue, Apr 24, 2001 at 12:18:42PM -0400, Nathan Walp wrote: I upgraded the BIOS on this Asus A7V sometime in the past week, but I honestly don't remember when. From 1005C to 1007. This was released in march, so I assumed it was pretty stable, but it could be the cause. I'm going to go downgrade now, but is this more likely to be a kernel bug, or a hardware bug/new bios bug? No problem here. I'm using 1007 since its release in first half of March. Linux version 2.4.3-ac12-amd (root@ppc) (gcc version 3.0 20010402 (Debian prerelease)) #1 Mon Apr 23 02:31:13 CEST 2001 ... Kernel command line: BOOT_IMAGE=Linux ro root=2105 video=matrox:vesa:0x105,fv:85 devfs=nomount Initializing CPU#0 Detected 1009.013 MHz processor. ... CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. ... apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) ... Except that I got 'ide only func: 14' today with my Promise PDC20265 (which looks strange to me - either all Intel, VIA and Promise have same bug in their UDMA hardware, or there is a bug in Linux IDE driver...) (I had to reboot because of kernel somehow believed that it read some garbage instead of MBR from hdg, so I could not run my repartitioning session, as I found no way to invalidate hdg kernel cache). But machine for sure does not spontaneously reboot. And I have enabled local apic in kernel configuration. All previous kernels were built with Debian's 2.95.3-something, ac12 was built with gcc-3.0, as I wanted to update anyway, and ac12 just gave me a reason. Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
random reboots
Help! My machine seems to be rebooting at random. Actually, it's more like the screen blanks, and suddenly the BIOS is going through POST. There may be a reset-button gnome in my case putting a jumper over the reset pins, but I seriously doubt it. ;-) I recently tried to switch from APM to ACPI, when i upgraded from ac9 to ac11, so I thought that might be the cause. So I switched back to APM with ac13 (I had the same ac12 compile problems as the rest of the world). It's still rebooting, without any aparent cause. I upgraded the BIOS on this Asus A7V sometime in the past week, but I honestly don't remember when. From 1005C to 1007. This was released in march, so I assumed it was pretty stable, but it could be the cause. I'm going to go downgrade now, but is this more likely to be a kernel bug, or a hardware bug/new bios bug? Thanks, Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
random reboots
Help! My machine seems to be rebooting at random. Actually, it's more like the screen blanks, and suddenly the BIOS is going through POST. There may be a reset-button gnome in my case putting a jumper over the reset pins, but I seriously doubt it. ;-) I recently tried to switch from APM to ACPI, when i upgraded from ac9 to ac11, so I thought that might be the cause. So I switched back to APM with ac13 (I had the same ac12 compile problems as the rest of the world). It's still rebooting, without any aparent cause. I upgraded the BIOS on this Asus A7V sometime in the past week, but I honestly don't remember when. From 1005C to 1007. This was released in march, so I assumed it was pretty stable, but it could be the cause. I'm going to go downgrade now, but is this more likely to be a kernel bug, or a hardware bug/new bios bug? Thanks, Nathan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [sligthly OT] serial console on palm
Andreas Dilger wrote: > > John Lenton writes: > > I remember seing a project to get a palm pilot working as a > > serial console, but now google seems unable to find it. Does > > anyone know of such a project? > > I got one recently called "serialrecord" for the Palm, but it is one-way > only (useful for capturing OOPSes or so. If someone had a two-way console > for the Palm, it would be great. Sorry, no URL, but you _should_ be able > to find it in l-k archives. > > Cheers, Andreas > -- > Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, > \ would they cancel out, leaving him still hungry?" > http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ This one has proved handy in the past. I've used it to log into routers and the like, it's pretty cool. The actual website (not palmgear) is incredibly slow tho. http://www.palmgear.com/software/showsoftware.cfm?prodID=552 Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [sligthly OT] serial console on palm
Andreas Dilger wrote: John Lenton writes: I remember seing a project to get a palm pilot working as a serial console, but now google seems unable to find it. Does anyone know of such a project? I got one recently called "serialrecord" for the Palm, but it is one-way only (useful for capturing OOPSes or so. If someone had a two-way console for the Palm, it would be great. Sorry, no URL, but you _should_ be able to find it in l-k archives. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ This one has proved handy in the past. I've used it to log into routers and the like, it's pretty cool. The actual website (not palmgear) is incredibly slow tho. http://www.palmgear.com/software/showsoftware.cfm?prodID=552 Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: devfs vs. devpts
John Jasen wrote: > > On 16 Mar 2001, Ian Soboroff wrote: > > > i don't have devpts mounted under 2.4.2 (debian checks whether you > > have devfs before mounting devpts), so i tried building my kernel with > > Unix 98 pty support but without the devpts filesystem. i get the > > following error at the very end of 'make bzImage': > > snipped from .config: > > # > # Character devices > # > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_SERIAL=y > # CONFIG_SERIAL_CONSOLE is not set > # CONFIG_SERIAL_EXTENDED is not set > # CONFIG_SERIAL_NONSTANDARD is not set > CONFIG_UNIX98_PTYS=y > CONFIG_UNIX98_PTY_COUNT=256 > > # > # File systems > # > CONFIG_DEVFS_FS=y > CONFIG_DEVFS_MOUNT=y > CONFIG_DEVFS_DEBUG=y > ... > # CONFIG_DEVPTS_FS is not set > > from my /etc/devfsd.conf, I have: > REGISTERpts/.* MKOLDCOMPAT > UNREGISTER pts/.* RMOLDCOMPAT > > and for permissions: > REGISTERpts/.* IGNORE > I had the same problem, so i added those devfsd lines to my config files, and everything's peachy now. I'm thinking it's a debian problem, cause everything was fine till I ran a dist-upgrade. I didn't notice it right away, and I did random kernel stuff before I did notice it. Ian, which debian are you running, I'm using sid. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: devfs vs. devpts
John Jasen wrote: On 16 Mar 2001, Ian Soboroff wrote: i don't have devpts mounted under 2.4.2 (debian checks whether you have devfs before mounting devpts), so i tried building my kernel with Unix 98 pty support but without the devpts filesystem. i get the following error at the very end of 'make bzImage': snipped from .config: # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # File systems # CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y CONFIG_DEVFS_DEBUG=y ... # CONFIG_DEVPTS_FS is not set from my /etc/devfsd.conf, I have: REGISTERpts/.* MKOLDCOMPAT UNREGISTER pts/.* RMOLDCOMPAT and for permissions: REGISTERpts/.* IGNORE I had the same problem, so i added those devfsd lines to my config files, and everything's peachy now. I'm thinking it's a debian problem, cause everything was fine till I ran a dist-upgrade. I didn't notice it right away, and I did random kernel stuff before I did notice it. Ian, which debian are you running, I'm using sid. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
David Balazic wrote: > > Nathan Walp wrote: > > > > David Balazic wrote: > > > > > > Nathan Walp ([EMAIL PROTECTED]) wrote : > > > > > > > Also, sometime between ac7 and ac18 (spring break kept me from testing > > > > stuff inbetween), i assume during the new aic7xxx driver merge, the > > > > order of detection got changed, and now the ide-scsi virtual host is > > > > host0, and my 29160N is host1. Is this on purpose? It messed up a > > > > bunch of my stuff as far as /dev and such are concerned. > > > > > > SCSI adapters are enumerated randomly(*) , relying on certain numbering > > > will get you into trouble, sooner or later. > > > There is no commonly accepted solution, AFAIK. > > > The same thing can happent to disk enumeration ( sdb becomes sdc ) > > > or partition enumeration ( hda6 becomes hda5 ). > > > > > > * - theoreticaly no, but practicaly yes ( most of the time ) > > > > > > -- > > > David Balazic > > > -- > > > "Be excellent to each other." - Bill & Ted > > > - - - - - - - - - - - - - - - - - - - - - - > > > > SCSI adapters are given host numbers in a random order? Even with no > > hardware changes? Does this make less than sense to anyone else? Every > > kernel EVER up till now has had the real scsi cards (in some particular > > order) then ide-scsi. Have I just been lucky??? > > > > Nathan > > What I mean that too many factors are affecting the enumeration, > so that you can not rely on it : > > - kernel changes > - driver changes ( partly overlaps with the previous poit ) > - hardware changes > - something else ? > > There is no policy for this enumeration ( AFAIK ) , so there is > nothing to rely on , except luck :-) See, that all makes sense. You can't depend on hardware to detect in the same order, whether it's SCSI cards, network cards, or anything really. But the software psuedo-device that is ide-scsi, shouldn't that pick a spot before or after the hardware and stay there? That's my point, i guess. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
David Balazic wrote: > > Nathan Walp ([EMAIL PROTECTED]) wrote : > > > Also, sometime between ac7 and ac18 (spring break kept me from testing > > stuff inbetween), i assume during the new aic7xxx driver merge, the > > order of detection got changed, and now the ide-scsi virtual host is > > host0, and my 29160N is host1. Is this on purpose? It messed up a > > bunch of my stuff as far as /dev and such are concerned. > > SCSI adapters are enumerated randomly(*) , relying on certain numbering > will get you into trouble, sooner or later. > There is no commonly accepted solution, AFAIK. > The same thing can happent to disk enumeration ( sdb becomes sdc ) > or partition enumeration ( hda6 becomes hda5 ). > > * - theoreticaly no, but practicaly yes ( most of the time ) > > -- > David Balazic > -- > "Be excellent to each other." - Bill & Ted > - - - - - - - - - - - - - - - - - - - - - - SCSI adapters are given host numbers in a random order? Even with no hardware changes? Does this make less than sense to anyone else? Every kernel EVER up till now has had the real scsi cards (in some particular order) then ide-scsi. Have I just been lucky??? Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
David Balazic wrote: Nathan Walp ([EMAIL PROTECTED]) wrote : Also, sometime between ac7 and ac18 (spring break kept me from testing stuff inbetween), i assume during the new aic7xxx driver merge, the order of detection got changed, and now the ide-scsi virtual host is host0, and my 29160N is host1. Is this on purpose? It messed up a bunch of my stuff as far as /dev and such are concerned. SCSI adapters are enumerated randomly(*) , relying on certain numbering will get you into trouble, sooner or later. There is no commonly accepted solution, AFAIK. The same thing can happent to disk enumeration ( sdb becomes sdc ) or partition enumeration ( hda6 becomes hda5 ). * - theoreticaly no, but practicaly yes ( most of the time ) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - SCSI adapters are given host numbers in a random order? Even with no hardware changes? Does this make less than sense to anyone else? Every kernel EVER up till now has had the real scsi cards (in some particular order) then ide-scsi. Have I just been lucky??? Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
Alan Cox wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/3.4/ > > Intermediate diffs are available from > > http://www.bzimage.org > > (Note that the cmsfs port to 2.4 is a work in progress) > > Its now 2767631 bytes .gz but a fair amount of stuff has gone to Linus so > if you redo the diff versus 2.4.3pre4 it looks a lot nicer 8) > > 2.4.2-ac20 > o Add support for the GoHubs GO-COM232(Greg Kroah-Hartman) > o Remove cobalt remnants (Ralf Baechle) > o First block of mm documentation (Rik van Riel) > o Replace ancient Zoran driver with new one (Serguei Miridonov, > Wolfgang Scherr, Rainer Johanni, Dave Perks) > o Fix Alpha build (Jeff Garzik) > o Fix K7 mtrr breakage(Dave Jones) > o Fix pcnet32 touching resources before enable(Dave Jones) > o Merge with Linus 2.4.3pre4 Debian sid (unstable). ac18 compiled fine. ac20, i got this: gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory aicasm/aicasm_gram.y:50: aicasm.h: No such file or directory aicasm/aicasm_gram.y:51: aicasm_symbol.h: No such file or directory aicasm/aicasm_gram.y:52: aicasm_insformat.h: No such file or directory aicasm/aicasm_scan.l:44: ../queue.h: No such file or directory aicasm/aicasm_scan.l:49: aicasm.h: No such file or directory aicasm/aicasm_scan.l:50: aicasm_symbol.h: No such file or directory aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory make[5]: *** [aicasm] Error 1 make[5]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx/aicasm' make[4]: *** [aicasm/aicasm] Error 2 make[4]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx' make[2]: *** [_subdir_aic7xxx] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers' make: *** [_dir_drivers] Error 2 patience:/usr/src/linux# Also, sometime between ac7 and ac18 (spring break kept me from testing stuff inbetween), i assume during the new aic7xxx driver merge, the order of detection got changed, and now the ide-scsi virtual host is host0, and my 29160N is host1. Is this on purpose? It messed up a bunch of my stuff as far as /dev and such are concerned. Thanks, Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac20
Alan Cox wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/3.4/ Intermediate diffs are available from http://www.bzimage.org (Note that the cmsfs port to 2.4 is a work in progress) Its now 2767631 bytes .gz but a fair amount of stuff has gone to Linus so if you redo the diff versus 2.4.3pre4 it looks a lot nicer 8) 2.4.2-ac20 o Add support for the GoHubs GO-COM232(Greg Kroah-Hartman) o Remove cobalt remnants (Ralf Baechle) o First block of mm documentation (Rik van Riel) o Replace ancient Zoran driver with new one (Serguei Miridonov, Wolfgang Scherr, Rainer Johanni, Dave Perks) o Fix Alpha build (Jeff Garzik) o Fix K7 mtrr breakage(Dave Jones) o Fix pcnet32 touching resources before enable(Dave Jones) o Merge with Linus 2.4.3pre4 Debian sid (unstable). ac18 compiled fine. ac20, i got this: gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory aicasm/aicasm_gram.y:50: aicasm.h: No such file or directory aicasm/aicasm_gram.y:51: aicasm_symbol.h: No such file or directory aicasm/aicasm_gram.y:52: aicasm_insformat.h: No such file or directory aicasm/aicasm_scan.l:44: ../queue.h: No such file or directory aicasm/aicasm_scan.l:49: aicasm.h: No such file or directory aicasm/aicasm_scan.l:50: aicasm_symbol.h: No such file or directory aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory make[5]: *** [aicasm] Error 1 make[5]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx/aicasm' make[4]: *** [aicasm/aicasm] Error 2 make[4]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx' make[2]: *** [_subdir_aic7xxx] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers' make: *** [_dir_drivers] Error 2 patience:/usr/src/linux# Also, sometime between ac7 and ac18 (spring break kept me from testing stuff inbetween), i assume during the new aic7xxx driver merge, the order of detection got changed, and now the ide-scsi virtual host is host0, and my 29160N is host1. Is this on purpose? It messed up a bunch of my stuff as far as /dev and such are concerned. Thanks, Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac14 tulip woes
The fix in ac14 for the ac13 patch that killed the tulip driver doesn't quite work either: Feb 15 13:04:16 patience kernel: LDT allocated for cloned task! Feb 15 13:04:55 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 15 13:05:27 patience last message repeated 4 times Feb 15 13:06:31 patience last message repeated 8 times Feb 15 13:07:35 patience last message repeated 8 times Feb 15 13:07:59 patience last message repeated 3 times Feb 15 13:08:07 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 15 13:08:39 patience last message repeated 4 times Feb 15 13:08:41 patience init: Switching to runlevel: 6 lspci -v from ac13 w/ ac12 tulip driver: 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9800 [size=256] Memory at e000 (32-bit, non-prefetchable) [size=256] Expansion ROM at [disabled] [size=256K] dmesg snippet from ac13 w/ ac12 tulip driver: PCI: Found IRQ 5 for device 00:0a.0 eth0: Lite-On 82c168 PNIC rev 32 at 0x9800, 00:A0:CC:61:CC:D2, IRQ 5. eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac14 tulip woes
The fix in ac14 for the ac13 patch that killed the tulip driver doesn't quite work either: Feb 15 13:04:16 patience kernel: LDT allocated for cloned task! Feb 15 13:04:55 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 15 13:05:27 patience last message repeated 4 times Feb 15 13:06:31 patience last message repeated 8 times Feb 15 13:07:35 patience last message repeated 8 times Feb 15 13:07:59 patience last message repeated 3 times Feb 15 13:08:07 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 15 13:08:39 patience last message repeated 4 times Feb 15 13:08:41 patience init: Switching to runlevel: 6 lspci -v from ac13 w/ ac12 tulip driver: 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9800 [size=256] Memory at e000 (32-bit, non-prefetchable) [size=256] Expansion ROM at unassigned [disabled] [size=256K] dmesg snippet from ac13 w/ ac12 tulip driver: PCI: Found IRQ 5 for device 00:0a.0 eth0: Lite-On 82c168 PNIC rev 32 at 0x9800, 00:A0:CC:61:CC:D2, IRQ 5. eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-ac13 tulip problems
Alan Cox wrote: > > > I just booted to 2.4.1-ac13, and was fine for a couple minutes. Then > > all network connectivity went away, and I had this sitting in syslog: > > Hence, I'm back to 2.4.1-ac12, and sending this in. No other noticible > > problems in my short-lived uptime ;-) > > I guess the pnic fixes have a side effect we didnt want. What kind of tulip > do you have (lspci -v ?) oops, i guess that would have been helpful, eh? ;-) It's a Netgear FA310TX. Here's lspci output: patience:~# lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: bus master, medium devsel, latency 0 Memory at e400 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: e080-e1df Prefetchable memory behind bridge: e1f0-e3ff Capabilities: [80] Power Management version 2 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: bus master, stepping, medium devsel, latency 0 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d800 [size=16] Capabilities: [c0] Power Management version 2 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at d400 [size=32] Capabilities: [80] Power Management version 2 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: medium devsel, IRQ 9 Capabilities: [68] Power Management version 2 00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 05) Subsystem: Creative Labs CT4760 SBLive! Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at a400 [size=32] Capabilities: [dc] Power Management version 1 00:09.1 Input device controller: Creative Labs SB Live! (rev 05) Subsystem: Creative Labs Gameport Joystick Flags: bus master, medium devsel, latency 32 I/O ports at a000 [size=8] Capabilities: [dc] Power Management version 1 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9800 [size=256] Memory at e000 (32-bit, non-prefetchable) [size=256] Expansion ROM at [disabled] [size=256K] 00:0d.0 SCSI storage controller: Adaptec 7892A (rev 02) Subsystem: Adaptec: Unknown device 62a0 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 9 BIST result: 00 I/O ports at 9400 [size=256] Memory at df80 (64-bit, non-prefetchable) [size=4K] Expansion ROM at [disabled] [size=128K] Capabilities: [dc] Power Management version 2 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at 9000 [size=8] I/O ports at 8800 [size=4] I/O ports at 8400 [size=8] I/O ports at 8000 [size=4] I/O ports at 7800 [size=64] Memory at df00 (32-bit, non-prefetchable) [size=128K] Expansion ROM at [disabled] [size=64K] Capabilities: [58] Power Management version 1 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 05) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G400 MAX/Dual Head 32Mb Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at e200 (32-bit, prefetchable) [size=32M] Memory at e100 (32-bit, non-prefetchable) [size=16K] Memory at e080 (32-bit, non-prefetchable) [size=8M] Expansion ROM at e1ff [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [f0] AGP version 2.0 Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of
2.4.1-ac13 tulip problems
I just booted to 2.4.1-ac13, and was fine for a couple minutes. Then all network connectivity went away, and I had this sitting in syslog: Feb 14 16:45:48 patience kernel: LDT allocated for cloned task! Feb 14 16:47:19 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 14 16:47:51 patience last message repeated 4 times Feb 14 16:48:55 patience last message repeated 8 times Feb 14 16:49:59 patience last message repeated 8 times Feb 14 16:51:03 patience last message repeated 8 times Feb 14 16:51:51 patience last message repeated 6 times Feb 14 16:51:59 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 14 16:52:31 patience last message repeated 4 times Feb 14 16:53:35 patience last message repeated 8 times Feb 14 16:54:39 patience last message repeated 8 times Feb 14 16:54:47 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 14 16:54:49 patience kernel: inet6_ifa_finish_destroy Feb 14 16:54:49 patience kernel: inet6_ifa_finish_destroy Feb 14 16:54:57 patience kernel: eth0: Setting half-duplex based on MII#1 link partner capability of 0021. Feb 14 16:55:15 patience kernel: eth0: no IPv6 routers present Feb 14 16:55:15 patience kernel: eth0: no IPv6 routers present Hence, I'm back to 2.4.1-ac12, and sending this in. No other noticible problems in my short-lived uptime ;-) Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac13 tulip problems
I just booted to 2.4.1-ac13, and was fine for a couple minutes. Then all network connectivity went away, and I had this sitting in syslog: Feb 14 16:45:48 patience kernel: LDT allocated for cloned task! Feb 14 16:47:19 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 14 16:47:51 patience last message repeated 4 times Feb 14 16:48:55 patience last message repeated 8 times Feb 14 16:49:59 patience last message repeated 8 times Feb 14 16:51:03 patience last message repeated 8 times Feb 14 16:51:51 patience last message repeated 6 times snip Feb 14 16:51:59 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 14 16:52:31 patience last message repeated 4 times Feb 14 16:53:35 patience last message repeated 8 times Feb 14 16:54:39 patience last message repeated 8 times Feb 14 16:54:47 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 14 16:54:49 patience kernel: inet6_ifa_finish_destroy Feb 14 16:54:49 patience kernel: inet6_ifa_finish_destroy Feb 14 16:54:57 patience kernel: eth0: Setting half-duplex based on MII#1 link partner capability of 0021. Feb 14 16:55:15 patience kernel: eth0: no IPv6 routers present Feb 14 16:55:15 patience kernel: eth0: no IPv6 routers present Hence, I'm back to 2.4.1-ac12, and sending this in. No other noticible problems in my short-lived uptime ;-) Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-ac13 tulip problems
Alan Cox wrote: I just booted to 2.4.1-ac13, and was fine for a couple minutes. Then all network connectivity went away, and I had this sitting in syslog: Hence, I'm back to 2.4.1-ac12, and sending this in. No other noticible problems in my short-lived uptime ;-) I guess the pnic fixes have a side effect we didnt want. What kind of tulip do you have (lspci -v ?) oops, i guess that would have been helpful, eh? ;-) It's a Netgear FA310TX. Here's lspci output: patience:~# lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: bus master, medium devsel, latency 0 Memory at e400 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: e080-e1df Prefetchable memory behind bridge: e1f0-e3ff Capabilities: [80] Power Management version 2 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: bus master, stepping, medium devsel, latency 0 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d800 [size=16] Capabilities: [c0] Power Management version 2 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at d400 [size=32] Capabilities: [80] Power Management version 2 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: medium devsel, IRQ 9 Capabilities: [68] Power Management version 2 00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 05) Subsystem: Creative Labs CT4760 SBLive! Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at a400 [size=32] Capabilities: [dc] Power Management version 1 00:09.1 Input device controller: Creative Labs SB Live! (rev 05) Subsystem: Creative Labs Gameport Joystick Flags: bus master, medium devsel, latency 32 I/O ports at a000 [size=8] Capabilities: [dc] Power Management version 1 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9800 [size=256] Memory at e000 (32-bit, non-prefetchable) [size=256] Expansion ROM at unassigned [disabled] [size=256K] 00:0d.0 SCSI storage controller: Adaptec 7892A (rev 02) Subsystem: Adaptec: Unknown device 62a0 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 9 BIST result: 00 I/O ports at 9400 [size=256] Memory at df80 (64-bit, non-prefetchable) [size=4K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [dc] Power Management version 2 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at 9000 [size=8] I/O ports at 8800 [size=4] I/O ports at 8400 [size=8] I/O ports at 8000 [size=4] I/O ports at 7800 [size=64] Memory at df00 (32-bit, non-prefetchable) [size=128K] Expansion ROM at unassigned [disabled] [size=64K] Capabilities: [58] Power Management version 1 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 05) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G400 MAX/Dual Head 32Mb Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at e200 (32-bit, prefetchable) [size=32M] Memory at e100 (32-bit, non-prefetchable) [size=16K] Memory at e080 (32-bit, non-prefetchable) [size=8M] Expansion ROM at e1ff [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [f0] AGP version 2.0 Nathan - To unsubscribe from this list: send the line "unsubscribe
Re: OOPSes and BUGs everywhere (2.4.0)
Nathan Walp wrote: > I'm gonna type fast and send this as soon as possible, cuz I'm not sure > how long i'll be able to stay up. I'm OOPSing and BUGging (is that a > word?) like crazy, and I can't figure it out. I thought it was the BIOS > upgrade I did, but downgrading didn't do anything. System is 1.1GHz > Tbird on Asus A7V, mixed SCSI and IDE. I hope to post a follow-up w/ > more info shortly, but here's the bulk of the info. > > Nathan Don't worry about these oopses and bugs...MAJOR hardware issues, I think i have a faulty chip. segfaults on clean deb potato system. windows WAS stable, till I started actually using the CPU, then BSOD all over the place. I guess it's time to see how good that warranty really is ;-) Sorry for all the trouble. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
OOPSes and BUGs everywhere (2.4.0)
I'm gonna type fast and send this as soon as possible, cuz I'm not sure how long i'll be able to stay up. I'm OOPSing and BUGging (is that a word?) like crazy, and I can't figure it out. I thought it was the BIOS upgrade I did, but downgrading didn't do anything. System is 1.1GHz Tbird on Asus A7V, mixed SCSI and IDE. I hope to post a follow-up w/ more info shortly, but here's the bulk of the info. Nathan ksymoops 2.3.7 on i686 2.4.0. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0/ (default) -m /boot/System.map-2.4.0 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Feb 4 23:23:01 patience kernel: aec671x_detect: Feb 4 23:23:01 patience kernel: ds: no socket drivers loaded! Feb 5 00:42:55 patience kernel: aec671x_detect: Feb 5 08:52:17 patience kernel: aec671x_detect: Feb 5 10:40:46 patience kernel: Unable to handle kernel paging request at virtual address 8f09897c Feb 5 10:40:46 patience kernel: c0114a59 Feb 5 10:40:46 patience kernel: *pde = Feb 5 10:40:46 patience kernel: Oops: 0002 Feb 5 10:40:46 patience kernel: CPU:0 Feb 5 10:40:46 patience kernel: EIP:0010:[remove_wait_queue+9/32] Feb 5 10:40:46 patience kernel: EFLAGS: 00010097 Feb 5 10:40:46 patience kernel: eax: 0297 ebx: c7a42050 ecx: cf098978 edx: 8f098978 Feb 5 10:40:46 patience kernel: esi: c7a42000 edi: c7a42008 ebp: cf463f70 esp: cf463f2c Feb 5 10:40:46 patience kernel: ds: 0018 es: 0018 ss: 0018 Feb 5 10:40:46 patience kernel: Process X (pid: 223, stackpage=cf463000) Feb 5 10:40:46 patience kernel: Stack: c013ece4 ce7df2c0 0001 c013f018 cf463f68 0008 0020 Feb 5 10:40:46 patience kernel:c14ddd40 0304 0080 cf462000 1876 0018 Feb 5 10:40:46 patience kernel:c7a42000 c013f3a2 0018 cf463fa8 cf463fa4 cf462000 Feb 5 10:40:46 patience kernel: Call Trace: [poll_freewait+36/80] [do_select+456/480] [sys_select+834/1152] [system_call+51/56] Feb 5 10:40:46 patience kernel: Code: 89 4a 04 89 11 50 9d c3 eb 0d 90 90 90 90 90 90 90 90 90 90 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 89 4a 04 mov%ecx,0x4(%edx) Code; 0003 Before first symbol 3: 89 11 mov%edx,(%ecx) Code; 0005 Before first symbol 5: 50push %eax Code; 0006 Before first symbol 6: 9dpopf Code; 0007 Before first symbol 7: c3ret Code; 0008 Before first symbol 8: eb 0d jmp17 <_EIP+0x17> 0017 Before first symbol Code; 000a Before first symbol a: 90nop Code; 000b Before first symbol b: 90nop Code; 000c Before first symbol c: 90nop Code; 000d Before first symbol d: 90nop Code; 000e Before first symbol e: 90nop Code; 000f Before first symbol f: 90nop Code; 0010 Before first symbol 10: 90nop Code; 0011 Before first symbol 11: 90nop Code; 0012 Before first symbol 12: 90nop Code; 0013 Before first symbol 13: 90nop Feb 5 10:40:46 patience kernel: kernel BUG at page_alloc.c:72! Feb 5 10:40:46 patience kernel: invalid operand: Feb 5 10:40:46 patience kernel: CPU:0 Feb 5 10:40:46 patience kernel: EIP:0010:[__free_pages_ok+34/784] Feb 5 10:40:46 patience kernel: EFLAGS: 00010282 Feb 5 10:40:46 patience kernel: eax: 001f ebx: c12628b0 ecx: c02cf988 edx: Feb 5 10:40:46 patience kernel: esi: 0005 edi: cdfc8404 ebp: esp: cdfcbefc Feb 5 10:40:46 patience kernel: ds: 0018 es: 0018 ss: 0018 Feb 5 10:40:46 patience kernel: Process enlightenment (pid: 259, stackpage=cdfcb000) Feb 5 10:40:46 patience kernel: Stack: c0271805 c0271993 0048 c12628b0 0005 cdfc8404 ce1dc080 c1044010 Feb 5 10:40:46 patience kernel:c02d0d20 0212 6775 c012c80a c012ccfa c12628b0 0005 Feb 5 10:40:46 patience kernel:c0121a39 c12628b0 ce311700 cdf7b0c0 4001d000 8000 0041d000 4041d000 Feb 5 10:40:46 patience kernel: Call Trace:
OOPSes and BUGs everywhere (2.4.0)
I'm gonna type fast and send this as soon as possible, cuz I'm not sure how long i'll be able to stay up. I'm OOPSing and BUGging (is that a word?) like crazy, and I can't figure it out. I thought it was the BIOS upgrade I did, but downgrading didn't do anything. System is 1.1GHz Tbird on Asus A7V, mixed SCSI and IDE. I hope to post a follow-up w/ more info shortly, but here's the bulk of the info. Nathan ksymoops 2.3.7 on i686 2.4.0. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0/ (default) -m /boot/System.map-2.4.0 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Feb 4 23:23:01 patience kernel: aec671x_detect: Feb 4 23:23:01 patience kernel: ds: no socket drivers loaded! Feb 5 00:42:55 patience kernel: aec671x_detect: Feb 5 08:52:17 patience kernel: aec671x_detect: Feb 5 10:40:46 patience kernel: Unable to handle kernel paging request at virtual address 8f09897c Feb 5 10:40:46 patience kernel: c0114a59 Feb 5 10:40:46 patience kernel: *pde = Feb 5 10:40:46 patience kernel: Oops: 0002 Feb 5 10:40:46 patience kernel: CPU:0 Feb 5 10:40:46 patience kernel: EIP:0010:[remove_wait_queue+9/32] Feb 5 10:40:46 patience kernel: EFLAGS: 00010097 Feb 5 10:40:46 patience kernel: eax: 0297 ebx: c7a42050 ecx: cf098978 edx: 8f098978 Feb 5 10:40:46 patience kernel: esi: c7a42000 edi: c7a42008 ebp: cf463f70 esp: cf463f2c Feb 5 10:40:46 patience kernel: ds: 0018 es: 0018 ss: 0018 Feb 5 10:40:46 patience kernel: Process X (pid: 223, stackpage=cf463000) Feb 5 10:40:46 patience kernel: Stack: c013ece4 ce7df2c0 0001 c013f018 cf463f68 0008 0020 Feb 5 10:40:46 patience kernel:c14ddd40 0304 0080 cf462000 1876 0018 Feb 5 10:40:46 patience kernel:c7a42000 c013f3a2 0018 cf463fa8 cf463fa4 cf462000 Feb 5 10:40:46 patience kernel: Call Trace: [poll_freewait+36/80] [do_select+456/480] [sys_select+834/1152] [system_call+51/56] Feb 5 10:40:46 patience kernel: Code: 89 4a 04 89 11 50 9d c3 eb 0d 90 90 90 90 90 90 90 90 90 90 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol _EIP: Code; Before first symbol 0: 89 4a 04 mov%ecx,0x4(%edx) Code; 0003 Before first symbol 3: 89 11 mov%edx,(%ecx) Code; 0005 Before first symbol 5: 50push %eax Code; 0006 Before first symbol 6: 9dpopf Code; 0007 Before first symbol 7: c3ret Code; 0008 Before first symbol 8: eb 0d jmp17 _EIP+0x17 0017 Before first symbol Code; 000a Before first symbol a: 90nop Code; 000b Before first symbol b: 90nop Code; 000c Before first symbol c: 90nop Code; 000d Before first symbol d: 90nop Code; 000e Before first symbol e: 90nop Code; 000f Before first symbol f: 90nop Code; 0010 Before first symbol 10: 90nop Code; 0011 Before first symbol 11: 90nop Code; 0012 Before first symbol 12: 90nop Code; 0013 Before first symbol 13: 90nop Feb 5 10:40:46 patience kernel: kernel BUG at page_alloc.c:72! Feb 5 10:40:46 patience kernel: invalid operand: Feb 5 10:40:46 patience kernel: CPU:0 Feb 5 10:40:46 patience kernel: EIP:0010:[__free_pages_ok+34/784] Feb 5 10:40:46 patience kernel: EFLAGS: 00010282 Feb 5 10:40:46 patience kernel: eax: 001f ebx: c12628b0 ecx: c02cf988 edx: Feb 5 10:40:46 patience kernel: esi: 0005 edi: cdfc8404 ebp: esp: cdfcbefc Feb 5 10:40:46 patience kernel: ds: 0018 es: 0018 ss: 0018 Feb 5 10:40:46 patience kernel: Process enlightenment (pid: 259, stackpage=cdfcb000) Feb 5 10:40:46 patience kernel: Stack: c0271805 c0271993 0048 c12628b0 0005 cdfc8404 ce1dc080 c1044010 Feb 5 10:40:46 patience kernel:c02d0d20 0212 6775 c012c80a c012ccfa c12628b0 0005 Feb 5 10:40:46 patience kernel:c0121a39 c12628b0 ce311700 cdf7b0c0 4001d000 8000 0041d000 4041d000 Feb 5 10:40:46 patience kernel: Call Trace:
Re: Promise PDC20265, VIA KT133 and corruption
Petr Vandrovec wrote: > > Hi Andre, > if you remember, last week I complained that Promise corrupts data > when I copy them from hdh to hde. Today I did some more experiments > (running 2.4.1-ac1) and found: > > 1) Debian sid's 'cmp' prints incorrect offsets when files differ >in more than one place if distance > cmp buffer size :-( > 2) When I read data from hdh (UDMA2 Toshiba) sometime last four >bytes of 4KB page (== probably last 4 bytes of read request) >are not read at all and old contents of page is left here >(it happens about once per 20MB read; and in about 1% of >these last 8 bytes of page are incorrect). >I have no idea whether promise or KT133 is at fault, but >it for sure does not happen under Windows... > 3) During write some corruption can happen on either hde (IBM >DTLA-307045 running UDMA5) or hdh - it looks like that >data are shifted on HDD, as fsck then complains about >imagic set, dtime set while inode not deleted and so on, >and then it cleaned inodes 178200-178300 from my hde :-( >Fortunately they were mostly in old kernel trees, >not in current data (except one inode, which was just >created by dpkg) > 4) So I compiled kernel without IDE DMA support at all and now >everything works at PIO4 without any corruption... > > If anybody has any idea what I should try to get UDMA to > work under Linux here... > > lspci: > > 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] > 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) > 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) > 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) > 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) > 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) > 00:0a.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) > 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) > > Thanks, > Petr Vandrovec > [EMAIL PROTECTED] I've got a very similar setup, but i've got a SCSI hard drive as well. In copying a rather large file (600+ MB) from my home directory (on the SCSI drive) to my IDE drive (on the promise controller, ata/100). scsi drive is ext2, the ide drive is vfat (basically to share movies and music w/ windoze). First try at copying, I got corruption. Second try, cp segfaulted. Looked, and sure enough, had an oops sitting for me in syslog, so here it is: ksymoops 2.3.7 on i686 2.4.1-ac2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-ac2/ (default) -m /boot/System.map-2.4.1-ac2 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Feb 3 23:38:01 patience kernel: Unable to handle kernel paging request at virtual address 81180b00 Feb 3 23:38:01 patience kernel: c0123a60 Feb 3 23:38:01 patience kernel: *pde = Feb 3 23:38:01 patience kernel: Oops: 0002 Feb 3 23:38:01 patience kernel: CPU:0 Feb 3 23:38:01 patience kernel: EIP: 0010:[__remove_inode_page+48/96] Feb 3 23:38:01 patience kernel: EFLAGS: 00010202 Feb 3 23:38:01 patience kernel: eax: c102b228 ebx: c1202058 ecx: 0106 edx: 81180b00 Feb 3 23:38:01 patience kernel: esi: c532a828 edi: c1202058 ebp: 1532 esp: cc8c5eac Feb 3 23:38:01 patience kernel: ds: 0018 es: 0018 ss: 0018 Feb 3 23:38:01 patience kernel: Process cp (pid: 483, stackpage=cc8c5000) Feb 3 23:38:01 patience kernel: Stack: c1202074 c012a476 c1202058 c0309758 c0309930 0002 c012bc18 Feb 3 23:38:01 patience kernel:c0309758 c0309938 c012bd80 c030992c Feb 3 23:38:01 patience kernel:0002 0001 cc8c5f58 15ece000 0005 0001 Feb 3 23:38:01 patience kernel: Call Trace: [reclaim_page+790/1024] [__alloc_pages_limit+120/176] [__alloc_pages+304/736] [generic_file_write+724/1408] [] [default_fat_file_write+34/80] Feb 3 23:38:01 patience kernel: Code: 89 02 8b 43 10 8b 53 34 c7 43 08 00 00 00 00 85 c0 74 03 89 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 89 02
Re: Promise PDC20265, VIA KT133 and corruption
Petr Vandrovec wrote: Hi Andre, if you remember, last week I complained that Promise corrupts data when I copy them from hdh to hde. Today I did some more experiments (running 2.4.1-ac1) and found: 1) Debian sid's 'cmp' prints incorrect offsets when files differ in more than one place if distance cmp buffer size :-( 2) When I read data from hdh (UDMA2 Toshiba) sometime last four bytes of 4KB page (== probably last 4 bytes of read request) are not read at all and old contents of page is left here (it happens about once per 20MB read; and in about 1% of these last 8 bytes of page are incorrect). I have no idea whether promise or KT133 is at fault, but it for sure does not happen under Windows... 3) During write some corruption can happen on either hde (IBM DTLA-307045 running UDMA5) or hdh - it looks like that data are shifted on HDD, as fsck then complains about imagic set, dtime set while inode not deleted and so on, and then it cleaned inodes 178200-178300 from my hde :-( Fortunately they were mostly in old kernel trees, not in current data (except one inode, which was just created by dpkg) 4) So I compiled kernel without IDE DMA support at all and now everything works at PIO4 without any corruption... If anybody has any idea what I should try to get UDMA to work under Linux here... lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) 00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:0a.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) Thanks, Petr Vandrovec [EMAIL PROTECTED] I've got a very similar setup, but i've got a SCSI hard drive as well. In copying a rather large file (600+ MB) from my home directory (on the SCSI drive) to my IDE drive (on the promise controller, ata/100). scsi drive is ext2, the ide drive is vfat (basically to share movies and music w/ windoze). First try at copying, I got corruption. Second try, cp segfaulted. Looked, and sure enough, had an oops sitting for me in syslog, so here it is: ksymoops 2.3.7 on i686 2.4.1-ac2. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1-ac2/ (default) -m /boot/System.map-2.4.1-ac2 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Feb 3 23:38:01 patience kernel: Unable to handle kernel paging request at virtual address 81180b00 Feb 3 23:38:01 patience kernel: c0123a60 Feb 3 23:38:01 patience kernel: *pde = Feb 3 23:38:01 patience kernel: Oops: 0002 Feb 3 23:38:01 patience kernel: CPU:0 Feb 3 23:38:01 patience kernel: EIP: 0010:[__remove_inode_page+48/96] Feb 3 23:38:01 patience kernel: EFLAGS: 00010202 Feb 3 23:38:01 patience kernel: eax: c102b228 ebx: c1202058 ecx: 0106 edx: 81180b00 Feb 3 23:38:01 patience kernel: esi: c532a828 edi: c1202058 ebp: 1532 esp: cc8c5eac Feb 3 23:38:01 patience kernel: ds: 0018 es: 0018 ss: 0018 Feb 3 23:38:01 patience kernel: Process cp (pid: 483, stackpage=cc8c5000) Feb 3 23:38:01 patience kernel: Stack: c1202074 c012a476 c1202058 c0309758 c0309930 0002 c012bc18 Feb 3 23:38:01 patience kernel:c0309758 c0309938 c012bd80 c030992c Feb 3 23:38:01 patience kernel:0002 0001 cc8c5f58 15ece000 0005 0001 Feb 3 23:38:01 patience kernel: Call Trace: [reclaim_page+790/1024] [__alloc_pages_limit+120/176] [__alloc_pages+304/736] [generic_file_write+724/1408] [d201] [default_fat_file_write+34/80] Feb 3 23:38:01 patience kernel: Code: 89 02 8b 43 10 8b 53 34 c7 43 08 00 00 00 00 85 c0 74 03 89 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol _EIP: Code; Before first symbol 0: 89 02 mov%eax,(%edx) Code; 0002
Re: fat32 corruption with 2.4.0
Heikki Lindholm wrote: > > Hello, > I haven't seen much vfat/fat32 complaints lately, so: > 2.4.0 destroyed my windows partition. There seemed to be some trouble in > 2.4.0-test9, too. I don't know if this was a known problem or not, but > 2.4.0-test9 wrote filenames in a wrong way. It could be observed by > running windows (98 in my case) file system checker (not scandisk, but the > graphical one) after copying some files with non-8.3 names to a fat32 > partition. There was no noticable data loss, however. > > Yesterday, with 2.4.0 release kernel, mounting a fat32 filesystem caused > data loss. The filesystem seemed to mount ok at a first glance, but > reported falsely 100% space usage. Then, after unmounting it, the oldest > (probably at start of the partition) directories "windows" and "my > documents" were mangled beyond recognition. I think, in this case, the > filenames got written REALLY wrong and showed as something like > "? * ~ ?. ? ?". Running scandisk caused most directories and files > in root directory to change to FILE0xxx.CHK and DIR0xxx.CHK. Most of the > data was intact, however - and subdirectories below DIR0xxx.CHK's were > good, too. I had VIA (868B) UDMA enabled, but don't think that was the > cause since it worked fine with ext2 partitions. > > In addition, trying to write to vfat /floppy with 2.4.0 also didn't > work. Kernel complained about (bad?) sectors. Whereas 2.2.0 did the job > fine (obviously, to the same floppy). > I just got through rebuilding my system (messy partition table, and windoze wouldn't install w/o blowing away everything). To backup, I tarred everything up, and put it on a big vfat drive I share between win and linux. I also burnt a CD w/ those backup tars. Being the moron that I am, I didn't test the tars, and I got burned. They got corrupted. At first I blamed the windows install scandisk that found some errors on that huge drive, but then i realized that I had burnt the backup CD before windows ever touched that drive. So, the files must have gotten corrupted as they were written to the vfat drive, or in the 5 minutes it took me to find my spindle ;-) This was under either kernel 2.4.0-ac10, or 2.4.1-pre10. I honestly don't remember which I was in at the time. If you can fix a crc-messy .tar.gz, I can find out for you ;-) Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: fat32 corruption with 2.4.0
Heikki Lindholm wrote: Hello, I haven't seen much vfat/fat32 complaints lately, so: 2.4.0 destroyed my windows partition. There seemed to be some trouble in 2.4.0-test9, too. I don't know if this was a known problem or not, but 2.4.0-test9 wrote filenames in a wrong way. It could be observed by running windows (98 in my case) file system checker (not scandisk, but the graphical one) after copying some files with non-8.3 names to a fat32 partition. There was no noticable data loss, however. Yesterday, with 2.4.0 release kernel, mounting a fat32 filesystem caused data loss. The filesystem seemed to mount ok at a first glance, but reported falsely 100% space usage. Then, after unmounting it, the oldest (probably at start of the partition) directories "windows" and "my documents" were mangled beyond recognition. I think, in this case, the filenames got written REALLY wrong and showed as something like "? * ~ ?. ? ?". Running scandisk caused most directories and files in root directory to change to FILE0xxx.CHK and DIR0xxx.CHK. Most of the data was intact, however - and subdirectories below DIR0xxx.CHK's were good, too. I had VIA (868B) UDMA enabled, but don't think that was the cause since it worked fine with ext2 partitions. In addition, trying to write to vfat /floppy with 2.4.0 also didn't work. Kernel complained about (bad?) sectors. Whereas 2.2.0 did the job fine (obviously, to the same floppy). I just got through rebuilding my system (messy partition table, and windoze wouldn't install w/o blowing away everything). To backup, I tarred everything up, and put it on a big vfat drive I share between win and linux. I also burnt a CD w/ those backup tars. Being the moron that I am, I didn't test the tars, and I got burned. They got corrupted. At first I blamed the windows install scandisk that found some errors on that huge drive, but then i realized that I had burnt the backup CD before windows ever touched that drive. So, the files must have gotten corrupted as they were written to the vfat drive, or in the 5 minutes it took me to find my spindle ;-) This was under either kernel 2.4.0-ac10, or 2.4.1-pre10. I honestly don't remember which I was in at the time. If you can fix a crc-messy .tar.gz, I can find out for you ;-) Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
OOPS in 2.4.0-ac10
A whole bunch of oopses. Was able to alt-sysrq with all of them. The second one of the 4 i'm posting here happened about a dozen times in a row in about a 45 min period while I was away from my machine. I opted not to post a dozen duplicate oopses, so I sipped those out. For the most part, I think these all occured w/ some combination of netscape, gaim, xmms, and possibly gnapster running, plus a couple Eterms. The system is an Athlon Tbird 1.1GHz, Asus A7V motherboard, blah, blah. I can give more detailed info if anyone wants it. I'm gonna hurry up and hit send now before it oopses again ;-) Nathan patience:~# uname -a Linux patience 2.4.0-ac10 #50 Sat Jan 20 17:13:29 EST 2001 i686 unknown ksymoops 2.3.7 on i686 2.4.0-ac10. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-ac10/ (default) -m /boot/System.map-2.4.0-ac10 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Jan 22 23:23:29 patience kernel: c01436c2 Jan 22 23:23:29 patience kernel: Oops: 0002 Jan 22 23:23:29 patience kernel: CPU:0 Jan 22 23:23:29 patience kernel: EIP:0010:[d_alloc+146/400] Jan 22 23:23:29 patience kernel: EFLAGS: 00010216 Jan 22 23:23:29 patience kernel: eax: cbd21f24 ebx: 6e4c4040 ecx: 0003 edx: 000c Jan 22 23:23:29 patience kernel: esi: cbd21f5c edi: 6e4c40a0 ebp: c1449140 esp: cbd21ef4 Jan 22 23:23:29 patience kernel: ds: 0018 es: 0018 ss: 0018 Jan 22 23:23:29 patience kernel: Process enlightenment (pid: 297, stackpage=cbd21000) Jan 22 23:23:29 patience kernel: Stack: cbd21f5c c5abe640 c1449140 fff4 6e4c40a0 c013029f c1449140 cbd21f24 Jan 22 23:23:29 patience kernel:cbd21f5c c5abe640 03b6 0001 cbd21f5c 000c c01a8872 Jan 22 23:23:29 patience kernel:cbd21f5c 0270 cbd21f5c c02d6e16 0270 Jan 22 23:23:29 patience kernel: Call Trace: [shmem_file_setup+95/256] [newseg+146/352] [sys_shmget+104/304] [sys_ipc+476/512] [system_call+51/56] Jan 22 23:23:29 patience kernel: Code: f3 a5 f6 c2 02 74 02 66 a5 f6 c2 01 74 01 a4 eb 0f 52 56 8b Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: f3 a5 repz movsl %ds:(%esi),%es:(%edi) Code; 0002 Before first symbol 2: f6 c2 02 test $0x2,%dl Code; 0005 Before first symbol 5: 74 02 je 9 <_EIP+0x9> 0009 Before first symbol Code; 0007 Before first symbol 7: 66 a5 movsw %ds:(%esi),%es:(%edi) Code; 0009 Before first symbol 9: f6 c2 01 test $0x1,%dl Code; 000c Before first symbol c: 74 01 je f <_EIP+0xf> 000f Before first symbol Code; 000e Before first symbol e: a4movsb %ds:(%esi),%es:(%edi) Code; 000f Before first symbol f: eb 0f jmp20 <_EIP+0x20> 0020 Before first symbol Code; 0011 Before first symbol 11: 52push %edx Code; 0012 Before first symbol 12: 56push %esi Code; 0013 Before first symbol 13: 8b 00 mov(%eax),%eax Jan 22 23:23:29 patience kernel: c0129bd4 Jan 22 23:23:29 patience kernel: Oops: Jan 22 23:23:29 patience kernel: CPU:0 Jan 22 23:23:29 patience kernel: EIP:0010:[kmem_cache_alloc+36/96] Jan 22 23:23:29 patience kernel: EFLAGS: 00010803 Jan 22 23:23:29 patience kernel: eax: 291f110b ebx: c1447e08 ecx: 5df4c640 edx: ce6c4000 Jan 22 23:23:29 patience kernel: esi: 0282 edi: 0007 ebp: c14490c0 esp: c75bbf10 Jan 22 23:23:29 patience kernel: ds: 0018 es: 0018 ss: 0018 Jan 22 23:23:29 patience kernel: Process xmms (pid: 1089, stackpage=c75bb000) Jan 22 23:23:29 patience kernel: Stack: cc89aac0 c75bbf62 c0143648 c1447e08 0007 cc89aac0 Jan 22 23:23:29 patience kernel:c75bbf62 000c c02559a0 c02559db c14490c0 c75bbf78 080572d4 Jan 22 23:23:29 patience kernel:08144d20 bae4 3631395b 36343532 c75b005d c1044010 0282 Jan 22 23:23:29 patience kernel: Call Trace: [d_alloc+24/400] [sock_map_fd+96/384] [sock_map_fd+155/384] [sys_socket+48/96] [sys_socketcall+99/512] [system_call+51/56] Jan 22 23:23:29 patience kernel: Code: 8b 44 82 18 89 42 14 83 f8 ff 75 05 8b 02 89 43 08 56 9d 89 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 8b 44 82 18
OOPS in 2.4.0-ac10
A whole bunch of oopses. Was able to alt-sysrq with all of them. The second one of the 4 i'm posting here happened about a dozen times in a row in about a 45 min period while I was away from my machine. I opted not to post a dozen duplicate oopses, so I sipped those out. For the most part, I think these all occured w/ some combination of netscape, gaim, xmms, and possibly gnapster running, plus a couple Eterms. The system is an Athlon Tbird 1.1GHz, Asus A7V motherboard, blah, blah. I can give more detailed info if anyone wants it. I'm gonna hurry up and hit send now before it oopses again ;-) Nathan patience:~# uname -a Linux patience 2.4.0-ac10 #50 Sat Jan 20 17:13:29 EST 2001 i686 unknown ksymoops 2.3.7 on i686 2.4.0-ac10. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-ac10/ (default) -m /boot/System.map-2.4.0-ac10 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Jan 22 23:23:29 patience kernel: c01436c2 Jan 22 23:23:29 patience kernel: Oops: 0002 Jan 22 23:23:29 patience kernel: CPU:0 Jan 22 23:23:29 patience kernel: EIP:0010:[d_alloc+146/400] Jan 22 23:23:29 patience kernel: EFLAGS: 00010216 Jan 22 23:23:29 patience kernel: eax: cbd21f24 ebx: 6e4c4040 ecx: 0003 edx: 000c Jan 22 23:23:29 patience kernel: esi: cbd21f5c edi: 6e4c40a0 ebp: c1449140 esp: cbd21ef4 Jan 22 23:23:29 patience kernel: ds: 0018 es: 0018 ss: 0018 Jan 22 23:23:29 patience kernel: Process enlightenment (pid: 297, stackpage=cbd21000) Jan 22 23:23:29 patience kernel: Stack: cbd21f5c c5abe640 c1449140 fff4 6e4c40a0 c013029f c1449140 cbd21f24 Jan 22 23:23:29 patience kernel:cbd21f5c c5abe640 03b6 0001 cbd21f5c 000c c01a8872 Jan 22 23:23:29 patience kernel:cbd21f5c 0270 cbd21f5c c02d6e16 0270 Jan 22 23:23:29 patience kernel: Call Trace: [shmem_file_setup+95/256] [newseg+146/352] [sys_shmget+104/304] [sys_ipc+476/512] [system_call+51/56] Jan 22 23:23:29 patience kernel: Code: f3 a5 f6 c2 02 74 02 66 a5 f6 c2 01 74 01 a4 eb 0f 52 56 8b Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol _EIP: Code; Before first symbol 0: f3 a5 repz movsl %ds:(%esi),%es:(%edi) Code; 0002 Before first symbol 2: f6 c2 02 test $0x2,%dl Code; 0005 Before first symbol 5: 74 02 je 9 _EIP+0x9 0009 Before first symbol Code; 0007 Before first symbol 7: 66 a5 movsw %ds:(%esi),%es:(%edi) Code; 0009 Before first symbol 9: f6 c2 01 test $0x1,%dl Code; 000c Before first symbol c: 74 01 je f _EIP+0xf 000f Before first symbol Code; 000e Before first symbol e: a4movsb %ds:(%esi),%es:(%edi) Code; 000f Before first symbol f: eb 0f jmp20 _EIP+0x20 0020 Before first symbol Code; 0011 Before first symbol 11: 52push %edx Code; 0012 Before first symbol 12: 56push %esi Code; 0013 Before first symbol 13: 8b 00 mov(%eax),%eax Jan 22 23:23:29 patience kernel: c0129bd4 Jan 22 23:23:29 patience kernel: Oops: Jan 22 23:23:29 patience kernel: CPU:0 Jan 22 23:23:29 patience kernel: EIP:0010:[kmem_cache_alloc+36/96] Jan 22 23:23:29 patience kernel: EFLAGS: 00010803 Jan 22 23:23:29 patience kernel: eax: 291f110b ebx: c1447e08 ecx: 5df4c640 edx: ce6c4000 Jan 22 23:23:29 patience kernel: esi: 0282 edi: 0007 ebp: c14490c0 esp: c75bbf10 Jan 22 23:23:29 patience kernel: ds: 0018 es: 0018 ss: 0018 Jan 22 23:23:29 patience kernel: Process xmms (pid: 1089, stackpage=c75bb000) Jan 22 23:23:29 patience kernel: Stack: cc89aac0 c75bbf62 c0143648 c1447e08 0007 cc89aac0 Jan 22 23:23:29 patience kernel:c75bbf62 000c c02559a0 c02559db c14490c0 c75bbf78 080572d4 Jan 22 23:23:29 patience kernel:08144d20 bae4 3631395b 36343532 c75b005d c1044010 0282 Jan 22 23:23:29 patience kernel: Call Trace: [d_alloc+24/400] [sock_map_fd+96/384] [sock_map_fd+155/384] [sys_socket+48/96] [sys_socketcall+99/512] [system_call+51/56] Jan 22 23:23:29 patience kernel: Code: 8b 44 82 18 89 42 14 83 f8 ff 75 05 8b 02 89 43 08 56 9d 89 Code; Before first symbol _EIP: Code; Before first symbol 0: 8b 44 82 18
Re: Oops in 2.4.0-ac5
Hans Grobler wrote: > > On Wed, 10 Jan 2001, Nathan Walp wrote: > > Here it is... I opted to cut out the 1200-odd warnings, which from the > > look of them were all because i'm running it under 2.4.0-ac4 (which > > boots fine). > > Thanks! My local mirror does not have -ac5 yet so I can't help > immediately. From the -ac5 log & the oops it looks as if Ingo's change > isn't quite complete yet... > > o Uniprocessor APIC support/NMI wdog etc (Ingo Molnar) > > Until then, what about disabling APIC support and trying again. This > will help confirm it... although it looks pretty definite. > > -- Hans I noticed (and was told by someone else) that it was APIC related. I looked, and realized that IO-APIC got selected between my compiles of ac4 and ac5. I recompiled ac5 w/o the IO-APIC stuff, and still got an oops. So, i recompiled without ANY APIC stuff, and it booted fine, but then had the same problems I was having w/ 2.4.1-pre1 related to X and (maybe) the framebuffer. But that's a whole different story that I think has been brought up in another thread. Guess I'm back to -ac4 for now ;-) Thanks, Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.4.0-ac5
Hans Grobler wrote: > > On Wed, 10 Jan 2001, Nathan Walp wrote: > > First post to the list, hope I get this right... > > Could you please run this through ksymoops on your machine. > Depending on which distribution you're using, this can be as > simple as: > > ksymoops < oops.txt > > Remember to set the System.map to the correct one, if you did > not compile in /usr/src/linux. > > Thanks, > -- Hans Here it is... I opted to cut out the 1200-odd warnings, which from the look of them were all because i'm running it under 2.4.0-ac4 (which boots fine). faceprint@patience:~$ ksymoops -o /lib/modules/2.4.0-ac5/ -m /boot/System.map-2.4.0-ac5 < oops.txt | less ksymoops 2.3.4 on i686 2.4.0-ac4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-ac5/ (specified) -m /boot/System.map-2.4.0-ac5 (specified) No modules in ksyms, skipping objects CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: ecx: 0186 edx: esi: 0004 edi: c0105000 ebp: 0008e000 esp: c0335fc0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0335000) Stack: c033bdbb ffec 0009ee00 c033c093 c03367f5 c03368fb c0299040 ffec ffec ffec ffec ffec c0370ce0 c0100191 Call Trace: [] Code: 0f 30 41 0f 30 b9 c1 00 00 00 0f 30 b9 c2 00 00 00 0f 30 b8 >>EIP; c01129ba<= Trace; c0100191 Code; c01129ba <_EIP>: Code; c01129ba<= 0: 0f 30 wrmsr <= Code; c01129bc 2: 41inc%ecx Code; c01129bd 3: 0f 30 wrmsr Code; c01129bf 5: b9 c1 00 00 00mov$0xc1,%ecx Code; c01129c4 a: 0f 30 wrmsr Code; c01129c6 c: b9 c2 00 00 00mov$0xc2,%ecx Code; c01129cb 11: 0f 30 wrmsr Code; c01129cd 13: b8 00 00 00 00mov$0x0,%eax Kernel panic: Attempted to kill the idle task! 1205 warnings issued. Results may not be reliable. Hope this is of a little more help ;-) Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops in 2.4.0-ac5
First post to the list, hope I get this right... 2.4.0-ac5 oopses very early on in the boot process. I can't get the actual oops off of the machine, but this is what i managed to type into my laptop: ... Getting VERSION: 40010 Getting VERSION: 40010 Getting ID: 0 Getting ID: f00 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: general protection fault: CPU:0 EIP:0010:[] EFLAGS: 00010246 eax: ebx: ecx: 0186 edx: esi: 0004 edi: c0105000 ebp: 0008e000 esp: c0335fc0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0335000) Stack: c033bdbb ffec 0009ee00 c033c093 c03367f5 c03368fb c0299040 ffec ffec ffec ffec ffec c0370ce0 c0100191 Call Trace: [] Code: 0f 30 41 0f 30 b9 c1 00 00 00 0f 30 b9 c2 00 00 00 0f 30 b8 Kernel panic: Attempted to kill the idle task! In idle task - not syncing It's an Athlon Tbird 1.1GHz on an ASUS A7V. The oops happens before the framebuffer kicks in, but that's all I can tell about the position of it. And no, I don't have any way to connect this machine to my laptop other than my network card, so I can't capture the entire oops. Sorry. Oh, and my .config is attached. Nathan # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # CONFIG_LVM_PROC_FS is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set
Oops in 2.4.0-ac5
First post to the list, hope I get this right... 2.4.0-ac5 oopses very early on in the boot process. I can't get the actual oops off of the machine, but this is what i managed to type into my laptop: stuff that's scrolled off screen ... Getting VERSION: 40010 Getting VERSION: 40010 Getting ID: 0 Getting ID: f00 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: general protection fault: CPU:0 EIP:0010:[c01129ba] EFLAGS: 00010246 eax: ebx: ecx: 0186 edx: esi: 0004 edi: c0105000 ebp: 0008e000 esp: c0335fc0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0335000) Stack: c033bdbb ffec 0009ee00 c033c093 c03367f5 c03368fb c0299040 ffec ffec ffec ffec ffec c0370ce0 c0100191 Call Trace: [c0100191] Code: 0f 30 41 0f 30 b9 c1 00 00 00 0f 30 b9 c2 00 00 00 0f 30 b8 Kernel panic: Attempted to kill the idle task! In idle task - not syncing It's an Athlon Tbird 1.1GHz on an ASUS A7V. The oops happens before the framebuffer kicks in, but that's all I can tell about the position of it. And no, I don't have any way to connect this machine to my laptop other than my network card, so I can't capture the entire oops. Sorry. Oh, and my .config is attached. Nathan # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # CONFIG_LVM_PROC_FS is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set #
Re: Oops in 2.4.0-ac5
Hans Grobler wrote: On Wed, 10 Jan 2001, Nathan Walp wrote: First post to the list, hope I get this right... Could you please run this through ksymoops on your machine. Depending on which distribution you're using, this can be as simple as: ksymoops oops.txt Remember to set the System.map to the correct one, if you did not compile in /usr/src/linux. Thanks, -- Hans Here it is... I opted to cut out the 1200-odd warnings, which from the look of them were all because i'm running it under 2.4.0-ac4 (which boots fine). faceprint@patience:~$ ksymoops -o /lib/modules/2.4.0-ac5/ -m /boot/System.map-2.4.0-ac5 oops.txt | less ksymoops 2.3.4 on i686 2.4.0-ac4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-ac5/ (specified) -m /boot/System.map-2.4.0-ac5 (specified) No modules in ksyms, skipping objects snip warnings CPU:0 EIP:0010:[c01129ba] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: ecx: 0186 edx: esi: 0004 edi: c0105000 ebp: 0008e000 esp: c0335fc0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0335000) Stack: c033bdbb ffec 0009ee00 c033c093 c03367f5 c03368fb c0299040 ffec ffec ffec ffec ffec c0370ce0 c0100191 Call Trace: [c0100191] Code: 0f 30 41 0f 30 b9 c1 00 00 00 0f 30 b9 c2 00 00 00 0f 30 b8 EIP; c01129ba setup_apic_nmi_watchdog+a/90 = Trace; c0100191 L6+0/2 Code; c01129ba setup_apic_nmi_watchdog+a/90 _EIP: Code; c01129ba setup_apic_nmi_watchdog+a/90 = 0: 0f 30 wrmsr = Code; c01129bc setup_apic_nmi_watchdog+c/90 2: 41inc%ecx Code; c01129bd setup_apic_nmi_watchdog+d/90 3: 0f 30 wrmsr Code; c01129bf setup_apic_nmi_watchdog+f/90 5: b9 c1 00 00 00mov$0xc1,%ecx Code; c01129c4 setup_apic_nmi_watchdog+14/90 a: 0f 30 wrmsr Code; c01129c6 setup_apic_nmi_watchdog+16/90 c: b9 c2 00 00 00mov$0xc2,%ecx Code; c01129cb setup_apic_nmi_watchdog+1b/90 11: 0f 30 wrmsr Code; c01129cd setup_apic_nmi_watchdog+1d/90 13: b8 00 00 00 00mov$0x0,%eax Kernel panic: Attempted to kill the idle task! 1205 warnings issued. Results may not be reliable. Hope this is of a little more help ;-) Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in 2.4.0-ac5
Hans Grobler wrote: On Wed, 10 Jan 2001, Nathan Walp wrote: Here it is... I opted to cut out the 1200-odd warnings, which from the look of them were all because i'm running it under 2.4.0-ac4 (which boots fine). Thanks! My local mirror does not have -ac5 yet so I can't help immediately. From the -ac5 log the oops it looks as if Ingo's change isn't quite complete yet... o Uniprocessor APIC support/NMI wdog etc (Ingo Molnar) Until then, what about disabling APIC support and trying again. This will help confirm it... although it looks pretty definite. -- Hans I noticed (and was told by someone else) that it was APIC related. I looked, and realized that IO-APIC got selected between my compiles of ac4 and ac5. I recompiled ac5 w/o the IO-APIC stuff, and still got an oops. So, i recompiled without ANY APIC stuff, and it booted fine, but then had the same problems I was having w/ 2.4.1-pre1 related to X and (maybe) the framebuffer. But that's a whole different story that I think has been brought up in another thread. Guess I'm back to -ac4 for now ;-) Thanks, Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
