Re: ASUS CUV4X-D Dual CPU's - Failure to boot...
[EMAIL PROTECTED] wrote: > > In article <[EMAIL PROTECTED]> you >wrote: > > Dear Kernel People, > > A friend of mine has a new PC with an ASUS CUV4X-D motherboard > > and dual 1GHZ PIII's. ... > For several people the following works: > 1) Upgrade to the latest bios > 2) Change the "MPS" level in the bios. It can have 3 values "1.4" "1.1" and >"none". the default one doesn't work, one of the others does (but I >forgot which one) 1.1 works fine for me. I haven't had a problem with this board since upgrading the BIOS and changing the MPS version to 1.1. You can also specify "noapic" to the booting kernel. John - 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: ASUS CUV4X-D Dual CPU's - Failure to boot...
[EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] you wrote: Dear Kernel People, A friend of mine has a new PC with an ASUS CUV4X-D motherboard and dual 1GHZ PIII's. ... For several people the following works: 1) Upgrade to the latest bios 2) Change the MPS level in the bios. It can have 3 values 1.4 1.1 and none. the default one doesn't work, one of the others does (but I forgot which one) 1.1 works fine for me. I haven't had a problem with this board since upgrading the BIOS and changing the MPS version to 1.1. You can also specify noapic to the booting kernel. John - 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: Asus CUV4X-DLS
John Cavan wrote: > I have an AIC7 based SCSI card in my machine as well, hooked up to a > Jaz. I haven't actually used it in ages, but I'll test it to see of the > problem is apparent on CUV4X-D board as well. First, I copied 640 Mb file to the jaz disk, no problem. Then I ran the same commands you did, also no problem... That would imply, at least, that the SCSI drivers are not at fault here. John - 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: Asus CUV4X-DLS
"J. Nick Koston" wrote: > > Thanks for the tips, however it doesn't help :-( It was worth a shot... > > Also, try passing "noapic" to the kernel on boot if the problem still > > persists. The downside is that all interrupts will be handled by a > > single CPU. There is a definite problem with VIA chipsets. > > > Tried this as well (mentioned in my original email) I realized that after I sent the message. Doh! I have an AIC7 based SCSI card in my machine as well, hooked up to a Jaz. I haven't actually used it in ages, but I'll test it to see of the problem is apparent on CUV4X-D board as well. John - 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: Asus CUV4X-DLS
J. Nick Koston wrote: Thanks for the tips, however it doesn't help :-( It was worth a shot... Also, try passing noapic to the kernel on boot if the problem still persists. The downside is that all interrupts will be handled by a single CPU. There is a definite problem with VIA chipsets. Tried this as well (mentioned in my original email) I realized that after I sent the message. Doh! I have an AIC7 based SCSI card in my machine as well, hooked up to a Jaz. I haven't actually used it in ages, but I'll test it to see of the problem is apparent on CUV4X-D board as well. John - 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: Asus CUV4X-DLS
John Cavan wrote: I have an AIC7 based SCSI card in my machine as well, hooked up to a Jaz. I haven't actually used it in ages, but I'll test it to see of the problem is apparent on CUV4X-D board as well. First, I copied 640 Mb file to the jaz disk, no problem. Then I ran the same commands you did, also no problem... That would imply, at least, that the SCSI drivers are not at fault here. John - 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.5-ac14
Dieter Nützel wrote: > > Hello Alan, > > I see 4.29 GB under shm with your latest try. > something wrong? total:used:free: shared: buffers: cached: Mem: 1053483008 431419392 622063616 122880 24387584 260923392 Swap: 3947642880 394764288 MemTotal: 1028792 kB MemFree:607484 kB MemShared: 120 kB Buffers: 23816 kB Cached: 254808 kB Active: 225536 kB Inact_dirty: 53208 kB Inact_clean: 0 kB Inact_target: 44 kB HighTotal: 131056 kB HighFree: 1048 kB LowTotal: 897736 kB LowFree:606436 kB SwapTotal: 385512 kB SwapFree: 385512 kB I don't seem to have the problem... John - 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.5-ac14
Dieter Nützel wrote: Hello Alan, I see 4.29 GB under shm with your latest try. something wrong? total:used:free: shared: buffers: cached: Mem: 1053483008 431419392 622063616 122880 24387584 260923392 Swap: 3947642880 394764288 MemTotal: 1028792 kB MemFree:607484 kB MemShared: 120 kB Buffers: 23816 kB Cached: 254808 kB Active: 225536 kB Inact_dirty: 53208 kB Inact_clean: 0 kB Inact_target: 44 kB HighTotal: 131056 kB HighFree: 1048 kB LowTotal: 897736 kB LowFree:606436 kB SwapTotal: 385512 kB SwapFree: 385512 kB I don't seem to have the problem... John - 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Not to sound dense, but what part of the GPL prohibits a piece of GPL'd software from including non-GPL'd code? The GPL does explicitly state that you can't include it's software in proprietary code, but I don't recall seeing a provision that prohibits the other way around. It may not be in the "spirit" of the GPL, but as a legal document, the letter means more than the spirit in the final determination. Sorry to intrude on this, but the thought just struck me. I could be wrong in my remembrance. John - 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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
Not to sound dense, but what part of the GPL prohibits a piece of GPL'd software from including non-GPL'd code? The GPL does explicitly state that you can't include it's software in proprietary code, but I don't recall seeing a provision that prohibits the other way around. It may not be in the spirit of the GPL, but as a legal document, the letter means more than the spirit in the final determination. Sorry to intrude on this, but the thought just struck me. I could be wrong in my remembrance. John - 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/
Potential help for VIA problems and ASUS motherboards
Hi, I've seen a lot of messages regarding problems with the VIA chipset... I've experienced them myself. Anyways, I just put in a new ASUS CUV4X-D motherboard, BIOS revision 1004. Once installed, I ran into a raft of problems when IO-APIC was enabled... and discovered that ASUS had a BIOS update (revision 1007) available. Once the BIOS was updated and MPS 1.4 support was disabled, everything has been working fine, including USB with IO-APIC enabled. I also don't seem to be getting the timer problem anymore. Anyways, if you have one of these boards, you may want to flash your BIOS and see if the problems are fixed. YMMV, but it worked for me. John - 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/
Potential help for VIA problems and ASUS motherboards
Hi, I've seen a lot of messages regarding problems with the VIA chipset... I've experienced them myself. Anyways, I just put in a new ASUS CUV4X-D motherboard, BIOS revision 1004. Once installed, I ran into a raft of problems when IO-APIC was enabled... and discovered that ASUS had a BIOS update (revision 1007) available. Once the BIOS was updated and MPS 1.4 support was disabled, everything has been working fine, including USB with IO-APIC enabled. I also don't seem to be getting the timer problem anymore. Anyways, if you have one of these boards, you may want to flash your BIOS and see if the problems are fixed. YMMV, but it worked for me. John - 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: [PATCH] Single user linux
On Thu, 26 Apr 2001 [EMAIL PROTECTED] wrote: > you're right, we could do it in more than one way. like copying > with mcopy without mounting a fat disk. the question is where to put it. > why we do it is an important thing. > taking place as a clueless user, i think i should be able to do anything. > i'd be happy to accept proof that multi-user is a solution for > clueless user, not because it's proven on servers. but because it is > a solution by definition. > I think you have it backwards here, given that Linux works one way and you want it to work another. Basically, I would suggest that it is up to you to prove that multi-user is NOT a solution for "clueless" user, especially given that there have been a number of suggestions on how to do it without changing the kernel or even changing software. If you can't prove the case, I rather suspect that your patch won't make it. Don't feel bad though, I've yet to get one through either. :o) John - 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: [PATCH] Single user linux
On Wed, 25 Apr 2001 [EMAIL PROTECTED] wrote: > so i guess i deserve opinions instead of flames. the > approach is from personal use, not the usual server use. > if you think a server setup is best for all use just say so, > i'm listening. Several distributions (Red Hat and Mandrake certainly) offer auto-login tools. In conjunction with those tools, take the approach that Apple used with OS X and setup "sudo" for administrative tasks on the machine. This allows the end user to generally administer the machine without all the need to hack the kernel, modify login, operate as root, etc. You can even restrict their actions with it and log what they do. In the end though, I really don't see the big deal with having a root user for general home use. Even traditionally stand-alone operating systems have gone to this model (Mac OS X) or are heading that way fast (Windows XP). There are always ways to configure permissions, and even in a stand-alone environment it's always better to protect against accidental deletion of system critical files. In other words, the benefits vastly outweigh the minor inconvenience. John - 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: [PATCH] Single user linux
On Wed, 25 Apr 2001 [EMAIL PROTECTED] wrote: so i guess i deserve opinions instead of flames. the approach is from personal use, not the usual server use. if you think a server setup is best for all use just say so, i'm listening. Several distributions (Red Hat and Mandrake certainly) offer auto-login tools. In conjunction with those tools, take the approach that Apple used with OS X and setup sudo for administrative tasks on the machine. This allows the end user to generally administer the machine without all the need to hack the kernel, modify login, operate as root, etc. You can even restrict their actions with it and log what they do. In the end though, I really don't see the big deal with having a root user for general home use. Even traditionally stand-alone operating systems have gone to this model (Mac OS X) or are heading that way fast (Windows XP). There are always ways to configure permissions, and even in a stand-alone environment it's always better to protect against accidental deletion of system critical files. In other words, the benefits vastly outweigh the minor inconvenience. John - 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: Problem with "su -" and kernels 2.4.3-ac11 and higher
Manuel McLure wrote: > Did you try nesting more than one "su -"? The first one after a boot works > for me - every other one fails. I tried it with about a half-dozen nested and no problem. Mandrake cooker here... uname -a Linux lion 2.4.3-ac11 #5 SMP Fri Apr 20 22:10:41 EDT 2001 i686 unknown gcc --version 2.96 ls -l /lib/libc-* -rwxr-xr-x1 root root 1216268 Feb 21 05:38 /lib/libc-2.2.2.so su --version su (GNU sh-utils) 2.0 I don't think libc is the problem, unless it is in conjunction with the compiler choice. Have you tried building the kernel with the updated Red Hat gcc version? I know Mandrake has kept theirs current to Red Hat and it works fine for me. John - 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.3-ac12
Alan Cox wrote: > > > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o > > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved > > > symbol rwsem_up_write_wake > > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved > > > symbol rwsem_down_write_failed > > > > Same thing with tdfx.o... > > "Works for me" as ever. What configuration options are you using. This sounds > like some of the code is built with each kind of semaphore. Mine is attached. I always run "make menuconfig", reconfirm my selections (which haven't changed in ages), save it, and then run "make dep" before building. I should note that I'm using a version of the DRI from CVS from early April, but it has been perfectly happy until now. I also tried it with the code in the kernel tree, same problem. John config
Re: Linux 2.4.3-ac12
Alan Cox wrote: > 2.4.3-ac12 > o Further semaphore fixes (David Howells) Getting unresolved symbols in some modules (notably, for me, microcode.o and radeon.o)... Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved symbol rwsem_up_write_wake /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved symbol rwsem_down_write_failed John - 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.3-ac12
Alan Cox wrote: 2.4.3-ac12 o Further semaphore fixes (David Howells) Getting unresolved symbols in some modules (notably, for me, microcode.o and radeon.o)... Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved symbol rwsem_up_write_wake /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved symbol rwsem_down_write_failed John - 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.3-ac12
Alan Cox wrote: Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved symbol rwsem_up_write_wake /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved symbol rwsem_down_write_failed Same thing with tdfx.o... "Works for me" as ever. What configuration options are you using. This sounds like some of the code is built with each kind of semaphore. Mine is attached. I always run "make menuconfig", reconfirm my selections (which haven't changed in ages), save it, and then run "make dep" before building. I should note that I'm using a version of the DRI from CVS from early April, but it has been perfectly happy until now. I also tried it with the code in the kernel tree, same problem. John config
Re: Problem with su - and kernels 2.4.3-ac11 and higher
Manuel McLure wrote: Did you try nesting more than one "su -"? The first one after a boot works for me - every other one fails. I tried it with about a half-dozen nested and no problem. Mandrake cooker here... uname -a Linux lion 2.4.3-ac11 #5 SMP Fri Apr 20 22:10:41 EDT 2001 i686 unknown gcc --version 2.96 ls -l /lib/libc-* -rwxr-xr-x1 root root 1216268 Feb 21 05:38 /lib/libc-2.2.2.so su --version su (GNU sh-utils) 2.0 I don't think libc is the problem, unless it is in conjunction with the compiler choice. Have you tried building the kernel with the updated Red Hat gcc version? I know Mandrake has kept theirs current to Red Hat and it works fine for me. John - 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.3-ac7
Alan Cox wrote: > VIA users should test this kernel carefully. It has what are supposed to be > the right fixes for the VIA hardware bugs. Obviously the right fixes are not > as tested as the deduced ones. > > 2.4.3-ac7 > o Updated VIA quirk handling for the chipset (Andre Hedrick, > flawsGeorge Breese) > | Experimental version removed > | VIA users should check this kernel -carefully- I tried it on my dual P3 box with the VIA chipset and I'm definitely getting timeouts for the USB devices. Booting with "noapic" resolves the problem for me. Output of lspci for the VIA stuff is: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 23) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 11) 00:07.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050 (rev 30) The motherboard is a Tyan Tiger 133 (slot 1). I'd be happy to provide more info, just tell me what you need. Thanks, John - 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.3-ac7
Alan Cox wrote: VIA users should test this kernel carefully. It has what are supposed to be the right fixes for the VIA hardware bugs. Obviously the right fixes are not as tested as the deduced ones. 2.4.3-ac7 o Updated VIA quirk handling for the chipset (Andre Hedrick, flawsGeorge Breese) | Experimental version removed | VIA users should check this kernel -carefully- I tried it on my dual P3 box with the VIA chipset and I'm definitely getting timeouts for the USB devices. Booting with "noapic" resolves the problem for me. Output of lspci for the VIA stuff is: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 23) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 11) 00:07.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050 (rev 30) The motherboard is a Tyan Tiger 133 (slot 1). I'd be happy to provide more info, just tell me what you need. Thanks, John - 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: Seems to be a lot of confusion about aic7xxx in linux 2.4.3
"Jeffrey W. Baker" wrote: > So, I conclude that the patch was created incorrectly, or that something > changed between cutting the patch and the tarball. Compiled fine for me without the complete tarball, just patched. Now, I went straight to ac2 (now ac3) without building the 2.4.3 stock kernel. Have you tried a "make mrproper" on the tree? John - 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.2-ac24
Alan Cox wrote: > 2.4.2-ac24 Is DRI still hosed? - 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: Error compiling aic7xxx driver on 2.4.2-ac13
Phil Oester wrote: > > one more try... > > anyone else get the following: > > make[5]: Entering directory > `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' > lex -t aicasm_scan.l > aicasm_scan.c > gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c > aicasm_symbol.c -o aicasm > aicasm_symbol.c:39: db/db_185.h: No such file or directory > make[5]: *** [aicasm] Error 1 > make[5]: Leaving directory > `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' The location of db_185.h is somewhat vendor dependent. In my case (Mandrake cooker), the location is in /usr/include/db3 rather than /usr/include/db. You have a couple of choices for now... symlink db3 to db if that is your situation or back out that portion of the patch to use the original db1 library. I personally chose the symlink, but it does highlight the problem of having userspace dependencies in the tree... John - 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: Error compiling aic7xxx driver on 2.4.2-ac13
Phil Oester wrote: one more try... anyone else get the following: make[5]: Entering directory `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' lex -t aicasm_scan.l aicasm_scan.c gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db/db_185.h: No such file or directory make[5]: *** [aicasm] Error 1 make[5]: Leaving directory `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' The location of db_185.h is somewhat vendor dependent. In my case (Mandrake cooker), the location is in /usr/include/db3 rather than /usr/include/db. You have a couple of choices for now... symlink db3 to db if that is your situation or back out that portion of the patch to use the original db1 library. I personally chose the symlink, but it does highlight the problem of having userspace dependencies in the tree... John - 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.2ac11
Alan Cox wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > > 2.4.2-ac11 Doesn't apply cleanly against a 2.4.2 tree... ./mm/slab.c.rej ./net/irda/irnet/irnet.h.rej ./arch/i386/kernel/traps.c.rej ./drivers/net/tulip/tulip.h.rej ./drivers/net/tulip/tulip_core.c.rej ./drivers/net/tulip/pnic.c.rej ./drivers/net/pcmcia/wavelan_cs.c.rej ./drivers/pci/pci.c.rej ./drivers/char/i810_rng.c.rej ./Makefile.rej Also, a lot of them suceeded, but with offsets. John - 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.2ac11
Alan Cox wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.2-ac11 Doesn't apply cleanly against a 2.4.2 tree... ./mm/slab.c.rej ./net/irda/irnet/irnet.h.rej ./arch/i386/kernel/traps.c.rej ./drivers/net/tulip/tulip.h.rej ./drivers/net/tulip/tulip_core.c.rej ./drivers/net/tulip/pnic.c.rej ./drivers/net/pcmcia/wavelan_cs.c.rej ./drivers/pci/pci.c.rej ./drivers/char/i810_rng.c.rej ./Makefile.rej Also, a lot of them suceeded, but with offsets. John - 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 stifles innovation... [way O.T.]
"Henning P. Schmiedehausen" wrote: > > [EMAIL PROTECTED] (Michael H. Warfield) writes: > > > Excuse me? A 1 billion dolar investment in Linux is not > >supporting it? > > On their own hardware. Which is really the point and they won't be the only ones. If IBM wants to attract and keep customers on their hardware, they will ensure that the software and Linux drivers for it run very well, if Linux is going to be their main play to sell hardware. The same will hold true for other hardware manufacturers, including those the make video cards, modems, etc, as Linux grows in the marketplace. Linux will not displace the software industry, it will eventually displace the commodity portions of it. This is what has Microsoft afraid, since commodity software is their real play, games and specialty software isn't. The fact is, the majority of software is written in-house and through contracted professional services work, not off the shelf. Linux will make that side of the industry even more valuable, it will empower the developers and the businesses that hire them to do even more than they can today. It will empower them to do it right. As for games and similar specialties, they aren't going anywhere. It costs far too much money to produce a high-end game and the open source world either can't afford it or can't produce it fast enough to support the market. So Allchin's flag waving is simple posturing. Microsoft may become irrelevant, but the software industry won't. John - 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 stifles innovation... [way O.T.]
"Henning P. Schmiedehausen" wrote: [EMAIL PROTECTED] (Michael H. Warfield) writes: Excuse me? A 1 billion dolar investment in Linux is not supporting it? On their own hardware. Which is really the point and they won't be the only ones. If IBM wants to attract and keep customers on their hardware, they will ensure that the software and Linux drivers for it run very well, if Linux is going to be their main play to sell hardware. The same will hold true for other hardware manufacturers, including those the make video cards, modems, etc, as Linux grows in the marketplace. Linux will not displace the software industry, it will eventually displace the commodity portions of it. This is what has Microsoft afraid, since commodity software is their real play, games and specialty software isn't. The fact is, the majority of software is written in-house and through contracted professional services work, not off the shelf. Linux will make that side of the industry even more valuable, it will empower the developers and the businesses that hire them to do even more than they can today. It will empower them to do it right. As for games and similar specialties, they aren't going anywhere. It costs far too much money to produce a high-end game and the open source world either can't afford it or can't produce it fast enough to support the market. So Allchin's flag waving is simple posturing. Microsoft may become irrelevant, but the software industry won't. John - 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 stifles innovation... [way O.T.]
Dennis wrote: > objective, arent we? You might ask yourself the same question... > For example, if there were six different companies that marketed ethernet > drivers for the eepro100, you'd have a choice of which one to buy..perhaps > with different "features" that were of value to you. Instead, you have > crappy GPL code that locks up under load, and its not worth spending > corporate dollars to fix it because you have to give away your work for > free under GPL. And since there is a "free" driver that most people can > use, its not worth building a better mousetrap either because the market is > too small. So, the handful of users with problems get to "fit it > themselves", most of whom cant of course. A large bulk of the investment in Linux is starting to come in from hardware manufacturers, notably IBM. These companies see Linux as a means to sell more hardware, not as a means to sell software. This is critical, because it means that it IS worth the money to make the driver perform correctly, GPL or not, because a bad driver means no sales. You can't argue from the standpoint of "small market" and then the destruction of the market itself. By definition, in order for the software market to be significantly damaged, Linux (and other open source projects) would have to hold more than a small percentage of the market. Hence, your market just got big and if you make hardware, you better make a good driver. [snip general name calling and other sorts of bashing - remember, objective?] John - 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: PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree864.0.2)
David Wood wrote: > > I believe you, although... why doesn't it happen with 2.2.17? vconsole > buffers in a different place in memory, I suppose? > > I'll forward this to the XFree team. Thanks! > -David Known bug, they're working on it. If you want to avoid the corruption, use the Vesa framebuffer driver for the console for the time being, it works fine for the Radeon. John - 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: PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree864.0.2)
David Wood wrote: I believe you, although... why doesn't it happen with 2.2.17? vconsole buffers in a different place in memory, I suppose? I'll forward this to the XFree team. Thanks! -David Known bug, they're working on it. If you want to avoid the corruption, use the Vesa framebuffer driver for the console for the time being, it works fine for the Radeon. John - 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 stifles innovation... [way O.T.]
Dennis wrote: objective, arent we? You might ask yourself the same question... For example, if there were six different companies that marketed ethernet drivers for the eepro100, you'd have a choice of which one to buy..perhaps with different "features" that were of value to you. Instead, you have crappy GPL code that locks up under load, and its not worth spending corporate dollars to fix it because you have to give away your work for free under GPL. And since there is a "free" driver that most people can use, its not worth building a better mousetrap either because the market is too small. So, the handful of users with problems get to "fit it themselves", most of whom cant of course. A large bulk of the investment in Linux is starting to come in from hardware manufacturers, notably IBM. These companies see Linux as a means to sell more hardware, not as a means to sell software. This is critical, because it means that it IS worth the money to make the driver perform correctly, GPL or not, because a bad driver means no sales. You can't argue from the standpoint of "small market" and then the destruction of the market itself. By definition, in order for the software market to be significantly damaged, Linux (and other open source projects) would have to hold more than a small percentage of the market. Hence, your market just got big and if you make hardware, you better make a good driver. [snip general name calling and other sorts of bashing - remember, objective?] John - 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: spelling of disc (disk) in /devfs
"Albert D. Cahalan" wrote: > > > It had always been my assumption that non-optical storage media used > > the 'disk' spelling, whereas optical media, such as CDs, DVDs, and MO, > > were reffered to using the 'disc' spelling. > > No, "disk" is correct for everything, but we use "disc" for a reason. Because "disc" is the English way of spelling it. I find it refreshing to have proper English show up in the industry, I'm getting tired of typing "color"... :o) - 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: Mucho timeouts on USB
Greg KH wrote: > > On Fri, Feb 09, 2001 at 07:22:54PM -0500, John Cavan wrote: > > > > Current config: > > > > Dual P3-500 w/ 512mb of RAM > > Tyan Tiger 133 mobo with VIA chipset, onboard USB > > Kernel 2.4.1-ac9 compiled with egcs-1.1.2 > > This motherboard does not currently work with USB in SMP mode, unless > you boot with "noapic" on the command line. People are working on it, > but it's slow going. That did the trick! Thanks alot. Nice too, first song played by Rush. :o) John - 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: Mucho timeouts on USB
Greg KH wrote: > > On Fri, Feb 09, 2001 at 07:22:54PM -0500, John Cavan wrote: > > > > Current config: > > > > Dual P3-500 w/ 512mb of RAM > > Tyan Tiger 133 mobo with VIA chipset, onboard USB > > Kernel 2.4.1-ac9 compiled with egcs-1.1.2 > > This motherboard does not currently work with USB in SMP mode, unless > you boot with "noapic" on the command line. People are working on it, > but it's slow going. I'll try that. > FWIW, Windows2000 refuses to also work for this VIA USB chipset :) According to Tyan, the issue should be fixed with the last BIOS update. I'm up to date in the BIOS (and I really wish that these guys would create a flash program that was OSS so I could avoid DOS), but one of the work arounds suggested was setting IRQ 12 to ISA/Legacy for Windows 2000. Didn't seem to cut it. Thanks, John - 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/
Mucho timeouts on USB
Hi, Just got a D-Link USB radio (R100) and I'm seeing lots of timeouts with it. I've seen this through the last few 2.4.1+ and -ac+ kernels. Current config: Dual P3-500 w/ 512mb of RAM Tyan Tiger 133 mobo with VIA chipset, onboard USB Kernel 2.4.1-ac9 compiled with egcs-1.1.2 The only thing funky is that three devices are sharing an interrupt: CPU0 CPU1 0: 216690 219652IO-APIC-edge timer 1: 3564 3816IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3: 7 20IO-APIC-edge serial 5: 1017 1135 IO-APIC-level EMU10K1 8: 0 1IO-APIC-edge rtc 11: 22978 22756 IO-APIC-level aic7xxx, eth0, usb-uhci 12: 64220 63272IO-APIC-edge PS/2 Mouse 14: 12132 12810IO-APIC-edge ide0 15: 3 10IO-APIC-edge ide1 NMI: 436327 436327 LOC: 436151 436128 ERR: 0 The ethernet card is a 3Com 3c905, the SCSI card is Adaptec 7892B (19160 card). No problems with either as far as I can tell, but one of these modules may not be playing nice with interrupt sharing. The messages: usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.251 $ time 17:33:47 Feb 9 2001 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 11 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=2 (error=-110) usb.c: USB device 3 (vend/prod 0x4b4/0x1002) is not claimed by any active driver. usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout - 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/
Mucho timeouts on USB
Hi, Just got a D-Link USB radio (R100) and I'm seeing lots of timeouts with it. I've seen this through the last few 2.4.1+ and -ac+ kernels. Current config: Dual P3-500 w/ 512mb of RAM Tyan Tiger 133 mobo with VIA chipset, onboard USB Kernel 2.4.1-ac9 compiled with egcs-1.1.2 The only thing funky is that three devices are sharing an interrupt: CPU0 CPU1 0: 216690 219652IO-APIC-edge timer 1: 3564 3816IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3: 7 20IO-APIC-edge serial 5: 1017 1135 IO-APIC-level EMU10K1 8: 0 1IO-APIC-edge rtc 11: 22978 22756 IO-APIC-level aic7xxx, eth0, usb-uhci 12: 64220 63272IO-APIC-edge PS/2 Mouse 14: 12132 12810IO-APIC-edge ide0 15: 3 10IO-APIC-edge ide1 NMI: 436327 436327 LOC: 436151 436128 ERR: 0 The ethernet card is a 3Com 3c905, the SCSI card is Adaptec 7892B (19160 card). No problems with either as far as I can tell, but one of these modules may not be playing nice with interrupt sharing. The messages: usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.251 $ time 17:33:47 Feb 9 2001 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 11 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=2 (error=-110) usb.c: USB device 3 (vend/prod 0x4b4/0x1002) is not claimed by any active driver. usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout - 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: Mucho timeouts on USB
Greg KH wrote: On Fri, Feb 09, 2001 at 07:22:54PM -0500, John Cavan wrote: Current config: Dual P3-500 w/ 512mb of RAM Tyan Tiger 133 mobo with VIA chipset, onboard USB Kernel 2.4.1-ac9 compiled with egcs-1.1.2 This motherboard does not currently work with USB in SMP mode, unless you boot with "noapic" on the command line. People are working on it, but it's slow going. I'll try that. FWIW, Windows2000 refuses to also work for this VIA USB chipset :) According to Tyan, the issue should be fixed with the last BIOS update. I'm up to date in the BIOS (and I really wish that these guys would create a flash program that was OSS so I could avoid DOS), but one of the work arounds suggested was setting IRQ 12 to ISA/Legacy for Windows 2000. Didn't seem to cut it. Thanks, John - 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: Mucho timeouts on USB
Greg KH wrote: On Fri, Feb 09, 2001 at 07:22:54PM -0500, John Cavan wrote: Current config: Dual P3-500 w/ 512mb of RAM Tyan Tiger 133 mobo with VIA chipset, onboard USB Kernel 2.4.1-ac9 compiled with egcs-1.1.2 This motherboard does not currently work with USB in SMP mode, unless you boot with "noapic" on the command line. People are working on it, but it's slow going. That did the trick! Thanks alot. Nice too, first song played by Rush. :o) John - 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/
Odd behaviour on / filesystem and SCSI removable media
Hi, I noticed an odd thing about my / file system: du -hx reports 74mb used df -h . reports 236mb used The same behaviour does not show on other mounted filesystems... I'm not sure which to believe... I've seen this with 2.4.1 and 2.4.1-ac1, the filesystem is ReiserFS and the kernel was compiled with egcs-1.1.2 (egcs-2.91.66). Also, I've seen some interesting behaviour with an Iomega Jaz drive. Basically, if I boot without a disk in the drive, the device is listed as 1gb assumed so that when I insert a 2gb disk in the drive, it gets messed up, unable to read the partition table. Same behaviour with the Zip drive, picked up as a default 1gb (no Zip disk I'm aware of is this large!) and can't deal with a 100 mb disk. Makes disk swapping with removable media rather clunky since modules need to be removed and reloaded to detect properly. John - 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/
Odd behaviour on / filesystem and SCSI removable media
Hi, I noticed an odd thing about my / file system: du -hx reports 74mb used df -h . reports 236mb used The same behaviour does not show on other mounted filesystems... I'm not sure which to believe... I've seen this with 2.4.1 and 2.4.1-ac1, the filesystem is ReiserFS and the kernel was compiled with egcs-1.1.2 (egcs-2.91.66). Also, I've seen some interesting behaviour with an Iomega Jaz drive. Basically, if I boot without a disk in the drive, the device is listed as 1gb assumed so that when I insert a 2gb disk in the drive, it gets messed up, unable to read the partition table. Same behaviour with the Zip drive, picked up as a default 1gb (no Zip disk I'm aware of is this large!) and can't deal with a 100 mb disk. Makes disk swapping with removable media rather clunky since modules need to be removed and reloaded to detect properly. John - 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: spurious IRQ complaints
David Ford wrote: > > PCI: No IRQ known for interrupt pin A of device 01:00.0. Please try > using pci=biosirq. > > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF > (prog-if 00 [VGA]) > Subsystem: ATI Technologies Inc: Unknown device 0008 > Flags: bus master, stepping, 66Mhz, medium devsel, latency 64 > Memory at e400 (32-bit, prefetchable) [size=64M] > I/O ports at d000 [size=256] > Memory at e900 (32-bit, non-prefetchable) [size=16K] > Expansion ROM at e800 [disabled] [size=128K] > Capabilities: [50] AGP version 2.0 > Capabilities: [5c] Power Management version 1 > > Does it really need one? DRI versions of X seem to behave better if an IRQ is assigned to the VGA device via the BIOS. Didn't seem like a problem to let it have one, so I did. :o) John - 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: spurious IRQ complaints
David Ford wrote: PCI: No IRQ known for interrupt pin A of device 01:00.0. Please try using pci=biosirq. 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0008 Flags: bus master, stepping, 66Mhz, medium devsel, latency 64 Memory at e400 (32-bit, prefetchable) [size=64M] I/O ports at d000 [size=256] Memory at e900 (32-bit, non-prefetchable) [size=16K] Expansion ROM at e800 [disabled] [size=128K] Capabilities: [50] AGP version 2.0 Capabilities: [5c] Power Management version 1 Does it really need one? DRI versions of X seem to behave better if an IRQ is assigned to the VGA device via the BIOS. Didn't seem like a problem to let it have one, so I did. :o) John - 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/
Networking strangeness 2.4.0-ac9 and earlier
Hi all, I've seen this for a while... the output from netstat and ifconfig do not agree on the MTU of the device: [root@lion /root]# netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.1.11.0 * 255.255.255.0 U40 0 0 eth0 127.0.0.0 * 255.0.0.0 U40 0 0 lo default spqr0.0.0.0 UG 40 0 0 eth0 [root@lion /root]# ifconfig eth0 Link encap:Ethernet HWaddr 00:10:4B:2B:12:80 inet addr:10.1.11.76 Bcast:10.1.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3648 errors:77 dropped:0 overruns:0 frame:144 TX packets:3863 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xd800 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16192 Metric:1 RX packets:139 errors:0 dropped:0 overruns:0 frame:0 TX packets:139 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 AFAIK, the MSS value should be about 40 less than the MTU, not 40, though on other Linux boxes I have, the MSS column from netstat shows 0 (both of them are 2.2 kernels and single proc machines). This machine is a dual P3-500 with 512mb of RAM and a 3COM 3c905 card. I understand that the MSS column should actually read the MTU, but I don't know if that is the case. Either way cat /proc/net/route shows: Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0000B010A00010 0 0 00FF 40 0 0 lo 007F00010 0 0 00FF 40 0 0 eth0FE0B010A00030 0 0 40 0 0 One of the things that seem to be symptomatic of the problem is web browsing to my Ultra 5 (Solaris 2.6 with recommended patches). A single web page can take several minutes to load with all images on my local LAN, but on the other Linux machines, it blows in before you can blink (as would be expected). Similar behaviour can be seen browsing against other Linux machines as well, though not as bad. Other network protocols are slower as well (FTP, telnet), though not once it gets through the firewall, oddly enough. Any help appreciated. Thanks, John - 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/
Networking strangeness 2.4.0-ac9 and earlier
Hi all, I've seen this for a while... the output from netstat and ifconfig do not agree on the MTU of the device: [root@lion /root]# netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.1.11.0 * 255.255.255.0 U40 0 0 eth0 127.0.0.0 * 255.0.0.0 U40 0 0 lo default spqr0.0.0.0 UG 40 0 0 eth0 [root@lion /root]# ifconfig eth0 Link encap:Ethernet HWaddr 00:10:4B:2B:12:80 inet addr:10.1.11.76 Bcast:10.1.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3648 errors:77 dropped:0 overruns:0 frame:144 TX packets:3863 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xd800 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16192 Metric:1 RX packets:139 errors:0 dropped:0 overruns:0 frame:0 TX packets:139 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 AFAIK, the MSS value should be about 40 less than the MTU, not 40, though on other Linux boxes I have, the MSS column from netstat shows 0 (both of them are 2.2 kernels and single proc machines). This machine is a dual P3-500 with 512mb of RAM and a 3COM 3c905 card. I understand that the MSS column should actually read the MTU, but I don't know if that is the case. Either way cat /proc/net/route shows: Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0000B010A00010 0 0 00FF 40 0 0 lo 007F00010 0 0 00FF 40 0 0 eth0FE0B010A00030 0 0 40 0 0 One of the things that seem to be symptomatic of the problem is web browsing to my Ultra 5 (Solaris 2.6 with recommended patches). A single web page can take several minutes to load with all images on my local LAN, but on the other Linux machines, it blows in before you can blink (as would be expected). Similar behaviour can be seen browsing against other Linux machines as well, though not as bad. Other network protocols are slower as well (FTP, telnet), though not once it gets through the firewall, oddly enough. Any help appreciated. Thanks, John - 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: Coding Style
David Ford wrote: > > One other thing. Allot of people neglect to brace a statement if > > it has a single line body. This is VERY bad, always brace your > > statements > > > > if (x = 1) > >if (y = 2) > > if (z = 3) > >for (i = 1; i < 10; i++) > > if > >switch (foo) > > . > > > > ...is really stupid. DON'T DO IT! > > No, it's really stupid to surround it with braces that aren't needed. The > above is incredibly easy to read and incredibly easy to trace and debug. "really stupid" is probably too harsh in both cases... Anyways, he has a point here: clarity. When doing late night debugging, your eyes are not going to be fooled as easily if the result of the condition is braced. Whether you consider it important is a personal taste, but it is also consistent with multi-line if statements, and when rapidly scanning code consistency is very useful. The rest of it, I generally agree with, except I like perl. :o) But, just like working for a company, you follow the standards for the system you're working on. John P.S. What's wrong with perl? Very useful language IMHO. - 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: Coding Style
David Ford wrote: One other thing. Allot of people neglect to brace a statement if it has a single line body. This is VERY bad, always brace your statements if (x = 1) if (y = 2) if (z = 3) for (i = 1; i 10; i++) if switch (foo) . ...is really stupid. DON'T DO IT! No, it's really stupid to surround it with braces that aren't needed. The above is incredibly easy to read and incredibly easy to trace and debug. "really stupid" is probably too harsh in both cases... Anyways, he has a point here: clarity. When doing late night debugging, your eyes are not going to be fooled as easily if the result of the condition is braced. Whether you consider it important is a personal taste, but it is also consistent with multi-line if statements, and when rapidly scanning code consistency is very useful. The rest of it, I generally agree with, except I like perl. :o) But, just like working for a company, you follow the standards for the system you're working on. John P.S. What's wrong with perl? Very useful language IMHO. - 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: tcp no-ack bug can-rpt, w/script incl (this bugs 4 u)
> I have been trying to figure out > why linux tcp is failing to ack > properly in some situations. This is exactly the same problem I'm seeing with a Solaris box talking to my Linux box. It has a similar problem with Linux as well, but does not manifest as bad against a 2.2 kernel machine. Seems I was chasing down the wrong path with MSS and MTU strangeness, I tested this with ethereal as soon as I saw your post. No help from me, I'm afraid, but I can at least verify that you are not the only one seeing it. John - 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/
Networking strangeness 2.4.0-ac9 and earlier
Hi all, I've seen this for a while... the output from netstat and ifconfig do not agree on the MTU of the device: [root@lion /root]# netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.1.11.0 * 255.255.255.0 U40 0 0 eth0 127.0.0.0 * 255.0.0.0 U40 0 0 lo default spqr0.0.0.0 UG 40 0 0 eth0 [root@lion /root]# ifconfig eth0 Link encap:Ethernet HWaddr 00:10:4B:2B:12:80 inet addr:10.1.11.76 Bcast:10.1.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3648 errors:77 dropped:0 overruns:0 frame:144 TX packets:3863 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xd800 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16192 Metric:1 RX packets:139 errors:0 dropped:0 overruns:0 frame:0 TX packets:139 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 AFAIK, the MSS value should be about 40 less than the MTU, not 40, though on other Linux boxes I have, the MSS column from netstat shows 0 (both of them are 2.2 kernels and single proc machines). This machine is a dual P3-500 with 512mb of RAM and a 3COM 3c905 card. I understand that the MSS column should actually read the MTU, but I don't know if that is the case. Either way cat /proc/net/route shows: Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0000B010A00010 0 0 00FF 40 0 0 lo 007F00010 0 0 00FF 40 0 0 eth0FE0B010A00030 0 0 40 0 0 One of the things that seem to be symptomatic of the problem is web browsing to my Ultra 5 (Solaris 2.6 with recommended patches). A single web page can take several minutes to load with all images on my local LAN, but on the other Linux machines, it blows in before you can blink (as would be expected). Similar behaviour can be seen browsing against other Linux machines as well, though not as bad. Other network protocols are slower as well (FTP, telnet), though not once it gets through the firewall, oddly enough. Any help appreciated. Thanks, John - 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/
Networking strangeness 2.4.0-ac9 and earlier
Hi all, I've seen this for a while... the output from netstat and ifconfig do not agree on the MTU of the device: [root@lion /root]# netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.1.11.0 * 255.255.255.0 U40 0 0 eth0 127.0.0.0 * 255.0.0.0 U40 0 0 lo default spqr0.0.0.0 UG 40 0 0 eth0 [root@lion /root]# ifconfig eth0 Link encap:Ethernet HWaddr 00:10:4B:2B:12:80 inet addr:10.1.11.76 Bcast:10.1.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3648 errors:77 dropped:0 overruns:0 frame:144 TX packets:3863 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:11 Base address:0xd800 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16192 Metric:1 RX packets:139 errors:0 dropped:0 overruns:0 frame:0 TX packets:139 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 AFAIK, the MSS value should be about 40 less than the MTU, not 40, though on other Linux boxes I have, the MSS column from netstat shows 0 (both of them are 2.2 kernels and single proc machines). This machine is a dual P3-500 with 512mb of RAM and a 3COM 3c905 card. I understand that the MSS column should actually read the MTU, but I don't know if that is the case. Either way cat /proc/net/route shows: Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0000B010A00010 0 0 00FF 40 0 0 lo 007F00010 0 0 00FF 40 0 0 eth0FE0B010A00030 0 0 40 0 0 One of the things that seem to be symptomatic of the problem is web browsing to my Ultra 5 (Solaris 2.6 with recommended patches). A single web page can take several minutes to load with all images on my local LAN, but on the other Linux machines, it blows in before you can blink (as would be expected). Similar behaviour can be seen browsing against other Linux machines as well, though not as bad. Other network protocols are slower as well (FTP, telnet), though not once it gets through the firewall, oddly enough. Any help appreciated. Thanks, John - 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: tcp no-ack bug can-rpt, w/script incl (this bugs 4 u)
I have been trying to figure out why linux tcp is failing to ack properly in some situations. This is exactly the same problem I'm seeing with a Solaris box talking to my Linux box. It has a similar problem with Linux as well, but does not manifest as bad against a 2.2 kernel machine. Seems I was chasing down the wrong path with MSS and MTU strangeness, I tested this with ethereal as soon as I saw your post. No help from me, I'm afraid, but I can at least verify that you are not the only one seeing it. John - 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: 2.2.16 SMP: mtrr errors
Alan Cox wrote: > > to fall through, but is this correct? I've inserted a break at the end > > of the Intel switch before and have not had problems, but I left it out > > Lucky Wouldn't be the first time... - 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: 2.2.16 SMP: mtrr errors
Petr Vandrovec wrote: > > kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary > > last message repeated 2 times > > For some strange reason X thinks that you have 24MB of memory on the G450. > You can either create 32MB write-combining region at 0xd400, or > teach X that your device occupies 32MB and not 24 (you should do it anyway, > region size can be only power of two)... Petr, the Matrox card splits the memory between the two video screens when running in a multi-head configuration and "pretends" that it is two distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and for 8mb seperately when in this mode. At line 1190 in arch/i386/kernel/mtrr.c the switch on Intel falls through hitting the error message for Centaur. I know the comment says to fall through, but is this correct? I've inserted a break at the end of the Intel switch before and have not had problems, but I left it out in the latest couple of kernels because of all the mtrr work being done, waiting to see if there was resolution. John - 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: 2.2.16 SMP: mtrr errors
> kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary > last message repeated 2 times > > and finally: > > %cat /proc/mtrr > reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 > reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 > reg02: base=0xd580 (3416MB), size= 8MB: write-combining, count=1 I'm seeing the same thing with the Matrox G400. John - 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: 2.2.16 SMP: mtrr errors
kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary last message repeated 2 times and finally: %cat /proc/mtrr reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 reg02: base=0xd580 (3416MB), size= 8MB: write-combining, count=1 I'm seeing the same thing with the Matrox G400. John - 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: 2.2.16 SMP: mtrr errors
Petr Vandrovec wrote: kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary last message repeated 2 times For some strange reason X thinks that you have 24MB of memory on the G450. You can either create 32MB write-combining region at 0xd400, or teach X that your device occupies 32MB and not 24 (you should do it anyway, region size can be only power of two)... Petr, the Matrox card splits the memory between the two video screens when running in a multi-head configuration and "pretends" that it is two distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and for 8mb seperately when in this mode. At line 1190 in arch/i386/kernel/mtrr.c the switch on Intel falls through hitting the error message for Centaur. I know the comment says to fall through, but is this correct? I've inserted a break at the end of the Intel switch before and have not had problems, but I left it out in the latest couple of kernels because of all the mtrr work being done, waiting to see if there was resolution. John - 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: Linux 2.4.0test11ac4
Alan Cox wrote: > o Fix ppa and imm hangs on io_request_lock(Tim Waugh) Just so I understand the differences, for learning purposes... Tim did this a little different than I did and I'd just like to understand the "whys" of it. Can't learn if I don't understand. :o) Thanks, John - 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: Linux 2.4.0test11ac4
Alan Cox wrote: o Fix ppa and imm hangs on io_request_lock(Tim Waugh) Just so I understand the differences, for learning purposes... Tim did this a little different than I did and I'd just like to understand the "whys" of it. Can't learn if I don't understand. :o) Thanks, John - 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: Odd behaviour with agpgart
Petr Vandrovec wrote: > > On Sat, Nov 18, 2000 at 10:43:20PM -0500, John Cavan wrote: > > Bus 1, device 0, function 0: > > VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 5). > > IRQ 16. > > Master Capable. Latency=64. Min Gnt=16.Max Lat=32. > > Prefetchable 32 bit memory at 0xf600 [0xf7ff]. > > Non-prefetchable 32 bit memory at 0xfeafc000 [0xfeaf]. > > Non-prefetchable 32 bit memory at 0xfe00 [0xfe7f]. > > > > But agpgart sets up: > > > > agpgart: Maximum main memory to use for agp memory: 440M > > agpgart: Detected Intel 440BX chipset > > agpgart: AGP aperture is 32M @ 0xfa00 > > AGP aperture is feature of host bridge: > > 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02) > Flags: bus master, medium devsel, latency 32 > Memory at d000 (32-bit, prefetchable) [size=64M] > ^^ > Capabilities: [a0] AGP version 1.0 > > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) >(prog-if 00 [VGA]) > Subsystem: Matrox Graphics, Inc. Millennium G200 AGP > Flags: bus master, medium devsel, latency 32, IRQ 11 > Memory at d800 (32-bit, prefetchable) [size=16M] > Memory at d400 (32-bit, non-prefetchable) [size=16K] > Memory at d500 (32-bit, non-prefetchable) [size=8M] > Expansion ROM at [disabled] [size=64K] > Capabilities: [dc] Power Management version 1 > Capabilities: [f0] AGP version 1.0 > > So it matters what you have listed in 00:00.0 node, not on Matrox device. Ah, now it makes sense. Interestingly, yours show that the bridge address is lower than the card address, mine is reversed. > > Needless to say, the two disagree and direct rendering is disabled. > > Attached is my .config for 2.4.0-test11-pre7. I've been wading through > > the code for AGP and DRM support, but nothing jumps out at me. > > > (http://www.matrox.com/mga/support/drivers/latest/home.htm) > > As matrox driver contains large BLOB which does all important things > (dualhead) usual practices about binary only software applies. Unfortunately, dual head is what I want from it. I can get dual head, but not accelerated 3D on the primary display. The stock XFree86 driver just chokes even trying dual head. Oh well. I guess I'll be waiting for Matrox to sort themselves out or for the XFree86 guys to get it. - 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: Odd behaviour with agpgart
Petr Vandrovec wrote: On Sat, Nov 18, 2000 at 10:43:20PM -0500, John Cavan wrote: Bus 1, device 0, function 0: VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 5). IRQ 16. Master Capable. Latency=64. Min Gnt=16.Max Lat=32. Prefetchable 32 bit memory at 0xf600 [0xf7ff]. Non-prefetchable 32 bit memory at 0xfeafc000 [0xfeaf]. Non-prefetchable 32 bit memory at 0xfe00 [0xfe7f]. But agpgart sets up: agpgart: Maximum main memory to use for agp memory: 440M agpgart: Detected Intel 440BX chipset agpgart: AGP aperture is 32M @ 0xfa00 AGP aperture is feature of host bridge: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02) Flags: bus master, medium devsel, latency 32 Memory at d000 (32-bit, prefetchable) [size=64M] ^^ Capabilities: [a0] AGP version 1.0 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G200 AGP Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at d800 (32-bit, prefetchable) [size=16M] Memory at d400 (32-bit, non-prefetchable) [size=16K] Memory at d500 (32-bit, non-prefetchable) [size=8M] Expansion ROM at unassigned [disabled] [size=64K] Capabilities: [dc] Power Management version 1 Capabilities: [f0] AGP version 1.0 So it matters what you have listed in 00:00.0 node, not on Matrox device. Ah, now it makes sense. Interestingly, yours show that the bridge address is lower than the card address, mine is reversed. Needless to say, the two disagree and direct rendering is disabled. Attached is my .config for 2.4.0-test11-pre7. I've been wading through the code for AGP and DRM support, but nothing jumps out at me. (http://www.matrox.com/mga/support/drivers/latest/home.htm) As matrox driver contains large BLOB which does all important things (dualhead) usual practices about binary only software applies. Unfortunately, dual head is what I want from it. I can get dual head, but not accelerated 3D on the primary display. The stock XFree86 driver just chokes even trying dual head. Oh well. I guess I'll be waiting for Matrox to sort themselves out or for the XFree86 guys to get it. - 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/
Odd behaviour with agpgart
I don't know if this is specifically a problem with the AGP driver or with X, but basically the AGP driver detects an aperture base address different from that of the prefetchable memory area of the video card and the mtrr's are not in agreement. I'm using this with a Dual P3-500mhz and a Matrox 400 under XFree86 4.0.1 with the Matrox supplied driver. Both X and /proc/pci report the same frame buffer addresses: Bus 1, device 0, function 0: VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 5). IRQ 16. Master Capable. Latency=64. Min Gnt=16.Max Lat=32. Prefetchable 32 bit memory at 0xf600 [0xf7ff]. Non-prefetchable 32 bit memory at 0xfeafc000 [0xfeaf]. Non-prefetchable 32 bit memory at 0xfe00 [0xfe7f]. But agpgart sets up: agpgart: Maximum main memory to use for agp memory: 440M agpgart: Detected Intel 440BX chipset agpgart: AGP aperture is 32M @ 0xfa00 Needless to say, the two disagree and direct rendering is disabled. Attached is my .config for 2.4.0-test11-pre7. I've been wading through the code for AGP and DRM support, but nothing jumps out at me. Attached is my .config. The hardware is: Dual P3-500 mhz Intel 440bx AGP set 512mb of RAM Matrox G400 dual head card XFree86 4.0.1 Matrox driver 1.00.003 (beta) (http://www.matrox.com/mga/support/drivers/latest/home.htm) This is with X configured to run multi-head, not Xinerama and the kernel built with egcs 1.1.2. Also, I noticed that in arch/i386/kernel/mtrr.c around line 1888 that the mtrr_add call for Intel chips falls through to the next case. When that happens, X cannot register the mtrr for the main display on the Matrox card, though it can register the secondary display. I slipped a break in there to bypass the fall through and the mtrr registered (with performance improvement). Is the fall through correct? I haven't had any failures or lockups since putting in the bypass, but I suspect that it is incorrect and related to the misdetection of the base address of the video card. John # # Automatically generated by make menuconfig: 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 is not set 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_M686FXSR=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # 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=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=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_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y 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=y 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 is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m 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=m CONFIG_ISAPNP=m # # 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=m CONFIG_BLK_DEV_NBD=m # 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=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y
Re: [PATCH] (new for ppa and imm) Re: [PATCH] Re: Patch to fix lockup on ppa insert
Tim Waugh wrote: > > On Thu, Nov 16, 2000 at 09:50:40PM -0500, John Cavan wrote: > > > [...] This patch unlocks, allows the lowlevel driver to do it's > > probes, and then relocks. It could probably be more granular in the > > parport_pc code, but my own home tests show it to be working fine. > > Is that safe? I'm not sure. I know why it causes the NMI lockup, but I'm not enough of an expert to sort it out. I've got a pretty good feel for the Zip driver, but not the parport or scsi code yet, so I don't know how safe it is. The new scsi error stuff does mention that drivers must spinunlock/spinlock if it enables interrupts. > Also, what bit of the parport code is tripping over the lock? > Request_module or something? During the init phase of the parport_pc module it probes and enables the IRQ(s) of the parallel port, but the scsi layer has them locked. > A nicer fix would probably be to use parport_register_driver, but > that's likely to be too big a change right now. I agree and it's recommended in the parport code. Now if I can get enough time, I will take a stab at it, but nobody should be relying on me for it. :o) John - 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: [PATCH] (new for ppa and imm) Re: [PATCH] Re: Patch to fix lockup on ppa insert
Tim Waugh wrote: On Thu, Nov 16, 2000 at 09:50:40PM -0500, John Cavan wrote: [...] This patch unlocks, allows the lowlevel driver to do it's probes, and then relocks. It could probably be more granular in the parport_pc code, but my own home tests show it to be working fine. Is that safe? I'm not sure. I know why it causes the NMI lockup, but I'm not enough of an expert to sort it out. I've got a pretty good feel for the Zip driver, but not the parport or scsi code yet, so I don't know how safe it is. The new scsi error stuff does mention that drivers must spinunlock/spinlock if it enables interrupts. Also, what bit of the parport code is tripping over the lock? Request_module or something? During the init phase of the parport_pc module it probes and enables the IRQ(s) of the parallel port, but the scsi layer has them locked. A nicer fix would probably be to use parport_register_driver, but that's likely to be too big a change right now. I agree and it's recommended in the parport code. Now if I can get enough time, I will take a stab at it, but nobody should be relying on me for it. :o) John - 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/
Odd behaviour with agpgart
I don't know if this is specifically a problem with the AGP driver or with X, but basically the AGP driver detects an aperture base address different from that of the prefetchable memory area of the video card and the mtrr's are not in agreement. I'm using this with a Dual P3-500mhz and a Matrox 400 under XFree86 4.0.1 with the Matrox supplied driver. Both X and /proc/pci report the same frame buffer addresses: Bus 1, device 0, function 0: VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 5). IRQ 16. Master Capable. Latency=64. Min Gnt=16.Max Lat=32. Prefetchable 32 bit memory at 0xf600 [0xf7ff]. Non-prefetchable 32 bit memory at 0xfeafc000 [0xfeaf]. Non-prefetchable 32 bit memory at 0xfe00 [0xfe7f]. But agpgart sets up: agpgart: Maximum main memory to use for agp memory: 440M agpgart: Detected Intel 440BX chipset agpgart: AGP aperture is 32M @ 0xfa00 Needless to say, the two disagree and direct rendering is disabled. Attached is my .config for 2.4.0-test11-pre7. I've been wading through the code for AGP and DRM support, but nothing jumps out at me. Attached is my .config. The hardware is: Dual P3-500 mhz Intel 440bx AGP set 512mb of RAM Matrox G400 dual head card XFree86 4.0.1 Matrox driver 1.00.003 (beta) (http://www.matrox.com/mga/support/drivers/latest/home.htm) This is with X configured to run multi-head, not Xinerama and the kernel built with egcs 1.1.2. Also, I noticed that in arch/i386/kernel/mtrr.c around line 1888 that the mtrr_add call for Intel chips falls through to the next case. When that happens, X cannot register the mtrr for the main display on the Matrox card, though it can register the secondary display. I slipped a break in there to bypass the fall through and the mtrr registered (with performance improvement). Is the fall through correct? I haven't had any failures or lockups since putting in the bypass, but I suspect that it is incorrect and related to the misdetection of the base address of the video card. John # # Automatically generated by make menuconfig: 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 is not set 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_M686FXSR=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # 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=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=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_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y 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=y 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 is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m 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=m CONFIG_ISAPNP=m # # 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=m CONFIG_BLK_DEV_NBD=m # 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=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y
[PATCH] (new for ppa and imm) Re: [PATCH] Re: Patch to fix lockup on ppa insert
Jens Axboe wrote:
> Wouldn't it be more interesting to fix the reason the new error
> handling code dies with imm and ppa?
Yes it would... :o) I think I've got it here.
The new error handling code spinlocks the IRQ which cause the lowlevel
parport driver to choke. This patch unlocks, allows the lowlevel driver
to do it's probes, and then relocks. It could probably be more granular
in the parport_pc code, but my own home tests show it to be working
fine.
John
diff -urN -X /usr/src/dontdiff linux.clean/drivers/scsi/imm.c
linux.current/drivers/scsi/imm.c
--- linux.clean/drivers/scsi/imm.c Thu Nov 16 07:25:29 2000
+++ linux.current/drivers/scsi/imm.cThu Nov 16 21:39:10 2000
@@ -122,7 +122,15 @@
struct Scsi_Host *hreg;
int ports;
int i, nhosts, try_again;
-struct parport *pb = parport_enumerate();
+struct parport *pb;
+
+/*
+ * unlock to allow the lowlevel parport driver to probe
+ * the irqs
+ */
+spin_unlock_irq(_request_lock);
+pb = parport_enumerate();
+spin_lock_irq(_request_lock);
printk("imm: Version %s\n", IMM_VERSION);
nhosts = 0;
diff -urN -X /usr/src/dontdiff linux.clean/drivers/scsi/ppa.c
linux.current/drivers/scsi/ppa.c
--- linux.clean/drivers/scsi/ppa.c Thu Nov 16 07:25:29 2000
+++ linux.current/drivers/scsi/ppa.cThu Nov 16 21:37:33 2000
@@ -111,7 +111,15 @@
struct Scsi_Host *hreg;
int ports;
int i, nhosts, try_again;
-struct parport *pb = parport_enumerate();
+struct parport *pb;
+
+/*
+ * unlock to allow the lowlevel parport driver to probe
+ * the irqs
+ */
+spin_unlock_irq(_request_lock);
+pb = parport_enumerate();
+spin_lock_irq(_request_lock);
printk("ppa: Version %s\n", PPA_VERSION);
nhosts = 0;
[PATCH] Re: Patch to fix lockup on ppa insert
John Cavan wrote:
>
> Similar to the imm patch, it's working for me.
>
> John
Again... not all screwed up...
patch -ur linux.clean/drivers/scsi/ppa.h linux.current/drivers/scsi/ppa.h
--- linux.clean/drivers/scsi/ppa.h Thu Sep 14 20:27:05 2000
+++ linux.current/drivers/scsi/ppa.hThu Nov 16 07:26:38 2000
@@ -170,7 +170,7 @@
eh_device_reset_handler:NULL, \
eh_bus_reset_handler: ppa_reset, \
eh_host_reset_handler: ppa_reset, \
- use_new_eh_code:1, \
+ use_new_eh_code:0, \
bios_param: ppa_biosparam, \
this_id:-1, \
sg_tablesize: SG_ALL, \
patch -ur linux.clean/drivers/scsi/ppa.c linux.current/drivers/scsi/ppa.c
--- linux.clean/drivers/scsi/ppa.c Thu Nov 16 07:25:29 2000
+++ linux.current/drivers/scsi/ppa.cThu Nov 16 07:28:10 2000
@@ -215,8 +215,10 @@
}
try_again = 1;
goto retry_entry;
-} else
+} else {
+ host->use_new_eh_code = 1;
return 1; /* return number of hosts detected */
+}
}
/* This is to give the ppa driver a way to modify the timings (and other
Patch to fix lockup on ppa insert
Similar to the imm patch, it's working for me.
John
diff -ru linux.clean/drivers/scsi/ppa.h linux.current/drivers/scsi/ppa.h
--- linux.clean/drivers/scsi/ppa.h Thu Sep 14 20:27:05 2000
+++ linux.current/drivers/scsi/ppa.hThu Nov 16 07:26:38 2000
@@ -170,7 +170,7 @@
eh_device_reset_handler:NULL,
\
eh_bus_reset_handler: ppa_reset,
\
eh_host_reset_handler: ppa_reset,
\
- use_new_eh_code:1,
\
+ use_new_eh_code:0,
\
bios_param: ppa_biosparam,
\
this_id:-1,
\
sg_tablesize: SG_ALL,
\
diff -ru linux.clean/drivers/scsi/ppa.c linux.current/drivers/scsi/ppa.c
--- linux.clean/drivers/scsi/ppa.c Thu Nov 16 07:25:29 2000
+++ linux.current/drivers/scsi/ppa.cThu Nov 16 07:28:10 2000
@@ -215,8 +215,10 @@
}
try_again = 1;
goto retry_entry;
-} else
+} else {
+ host->use_new_eh_code = 1;
return 1; /* return number of hosts detected */
+}
}
/* This is to give the ppa driver a way to modify the timings (and
other
-
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/
Patch to fix lockup on ppa insert
Similar to the imm patch, it's working for me.
John
diff -ru linux.clean/drivers/scsi/ppa.h linux.current/drivers/scsi/ppa.h
--- linux.clean/drivers/scsi/ppa.h Thu Sep 14 20:27:05 2000
+++ linux.current/drivers/scsi/ppa.hThu Nov 16 07:26:38 2000
@@ -170,7 +170,7 @@
eh_device_reset_handler:NULL,
\
eh_bus_reset_handler: ppa_reset,
\
eh_host_reset_handler: ppa_reset,
\
- use_new_eh_code:1,
\
+ use_new_eh_code:0,
\
bios_param: ppa_biosparam,
\
this_id:-1,
\
sg_tablesize: SG_ALL,
\
diff -ru linux.clean/drivers/scsi/ppa.c linux.current/drivers/scsi/ppa.c
--- linux.clean/drivers/scsi/ppa.c Thu Nov 16 07:25:29 2000
+++ linux.current/drivers/scsi/ppa.cThu Nov 16 07:28:10 2000
@@ -215,8 +215,10 @@
}
try_again = 1;
goto retry_entry;
-} else
+} else {
+ host-use_new_eh_code = 1;
return 1; /* return number of hosts detected */
+}
}
/* This is to give the ppa driver a way to modify the timings (and
other
-
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/
[PATCH] Re: Patch to fix lockup on ppa insert
John Cavan wrote:
Similar to the imm patch, it's working for me.
John
Again... not all screwed up...
patch -ur linux.clean/drivers/scsi/ppa.h linux.current/drivers/scsi/ppa.h
--- linux.clean/drivers/scsi/ppa.h Thu Sep 14 20:27:05 2000
+++ linux.current/drivers/scsi/ppa.hThu Nov 16 07:26:38 2000
@@ -170,7 +170,7 @@
eh_device_reset_handler:NULL, \
eh_bus_reset_handler: ppa_reset, \
eh_host_reset_handler: ppa_reset, \
- use_new_eh_code:1, \
+ use_new_eh_code:0, \
bios_param: ppa_biosparam, \
this_id:-1, \
sg_tablesize: SG_ALL, \
patch -ur linux.clean/drivers/scsi/ppa.c linux.current/drivers/scsi/ppa.c
--- linux.clean/drivers/scsi/ppa.c Thu Nov 16 07:25:29 2000
+++ linux.current/drivers/scsi/ppa.cThu Nov 16 07:28:10 2000
@@ -215,8 +215,10 @@
}
try_again = 1;
goto retry_entry;
-} else
+} else {
+ host-use_new_eh_code = 1;
return 1; /* return number of hosts detected */
+}
}
/* This is to give the ppa driver a way to modify the timings (and other
[PATCH] (new for ppa and imm) Re: [PATCH] Re: Patch to fix lockup on ppa insert
Jens Axboe wrote:
Wouldn't it be more interesting to fix the reason the new error
handling code dies with imm and ppa?
Yes it would... :o) I think I've got it here.
The new error handling code spinlocks the IRQ which cause the lowlevel
parport driver to choke. This patch unlocks, allows the lowlevel driver
to do it's probes, and then relocks. It could probably be more granular
in the parport_pc code, but my own home tests show it to be working
fine.
John
diff -urN -X /usr/src/dontdiff linux.clean/drivers/scsi/imm.c
linux.current/drivers/scsi/imm.c
--- linux.clean/drivers/scsi/imm.c Thu Nov 16 07:25:29 2000
+++ linux.current/drivers/scsi/imm.cThu Nov 16 21:39:10 2000
@@ -122,7 +122,15 @@
struct Scsi_Host *hreg;
int ports;
int i, nhosts, try_again;
-struct parport *pb = parport_enumerate();
+struct parport *pb;
+
+/*
+ * unlock to allow the lowlevel parport driver to probe
+ * the irqs
+ */
+spin_unlock_irq(io_request_lock);
+pb = parport_enumerate();
+spin_lock_irq(io_request_lock);
printk("imm: Version %s\n", IMM_VERSION);
nhosts = 0;
diff -urN -X /usr/src/dontdiff linux.clean/drivers/scsi/ppa.c
linux.current/drivers/scsi/ppa.c
--- linux.clean/drivers/scsi/ppa.c Thu Nov 16 07:25:29 2000
+++ linux.current/drivers/scsi/ppa.cThu Nov 16 21:37:33 2000
@@ -111,7 +111,15 @@
struct Scsi_Host *hreg;
int ports;
int i, nhosts, try_again;
-struct parport *pb = parport_enumerate();
+struct parport *pb;
+
+/*
+ * unlock to allow the lowlevel parport driver to probe
+ * the irqs
+ */
+spin_unlock_irq(io_request_lock);
+pb = parport_enumerate();
+spin_lock_irq(io_request_lock);
printk("ppa: Version %s\n", PPA_VERSION);
nhosts = 0;
Re: lockup with parport_pc on 2.4.0-test10-pre1
Tim Waugh wrote: > > On Wed, Oct 11, 2000 at 11:01:20PM -0400, John Cavan wrote: > > > I don't if this is specifically a problem in the module or with modprobe > > (2.3.17), but it doesn't happen with any other module. Unfortunately > > parport_pc.c was as far as I traced before my work life sucked me back > > in. > > I think it's a parport problem. I haven't had time to look at this > yet, sorry. Actually, I got further. It's the Zip ppa.o driver that's causing it. I'll keep digging. John - 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: lockup with parport_pc on 2.4.0-test10-pre1
Tim Waugh wrote: On Wed, Oct 11, 2000 at 11:01:20PM -0400, John Cavan wrote: I don't if this is specifically a problem in the module or with modprobe (2.3.17), but it doesn't happen with any other module. Unfortunately parport_pc.c was as far as I traced before my work life sucked me back in. I think it's a parport problem. I haven't had time to look at this yet, sorry. Actually, I got further. It's the Zip ppa.o driver that's causing it. I'll keep digging. John - 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/
lockup with parport_pc on 2.4.0-test10-pre1
I managed to follow, with a number of debug statements, a problem that
appears to be in parport_pc that causes the following lockup on a dual
P3 500 with modprobe:
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[]
EFLAGS: 0086
eax: 0301 ebx: 0216 ecx: 0001 edx: 000816a1
esi: 0301 edi: 000c ebp: 00034a4e esp: df91fe98
ds: 0018 es: 0018 ss: 0018
Process modprobe (pid: 79, stackpage=df91f000)
Stack: df8f3f20 0001 c0162cea 0301 df8f3f20
df91ff0c
c0162ea1 df8f3f20 df8f3f20 0004 000a 0400
c0134492
0004 df91ff0c c196ea04 c18620e0 df9b385c
1000
Call Trace: [] [] [] []
[] [] []
[] [] [] [] []
Code: 80 3d 64 4d 22 c0 00 f3 90 7e f5 e9 e6 31 f8 ff 80 3d ac f6
console shuts up ...
I don't if this is specifically a problem in the module or with modprobe
(2.3.17), but it doesn't happen with any other module. Unfortunately
parport_pc.c was as far as I traced before my work life sucked me back
in.
If more information is needed, please tell me what you need and I'll try
to provide it.
John
-
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/
lockup with parport_pc on 2.4.0-test10-pre1
I managed to follow, with a number of debug statements, a problem that
appears to be in parport_pc that causes the following lockup on a dual
P3 500 with modprobe:
NMI Watchdog detected LOCKUP on CPU0, registers:
CPU:0
EIP:0010:[c01deec3]
EFLAGS: 0086
eax: 0301 ebx: 0216 ecx: 0001 edx: 000816a1
esi: 0301 edi: 000c ebp: 00034a4e esp: df91fe98
ds: 0018 es: 0018 ss: 0018
Process modprobe (pid: 79, stackpage=df91f000)
Stack: df8f3f20 0001 c0162cea 0301 df8f3f20
df91ff0c
c0162ea1 df8f3f20 df8f3f20 0004 000a 0400
c0134492
0004 df91ff0c c196ea04 c18620e0 df9b385c
1000
Call Trace: [c0162cea] [c0162ea1] [c0134492] [c012dd73]
[c01527d3] [c
0152108] [c0125f96]
[c012628f] [c01261e0] [c0131827] [c010abf7] [c01e002b]
Code: 80 3d 64 4d 22 c0 00 f3 90 7e f5 e9 e6 31 f8 ff 80 3d ac f6
console shuts up ...
I don't if this is specifically a problem in the module or with modprobe
(2.3.17), but it doesn't happen with any other module. Unfortunately
parport_pc.c was as far as I traced before my work life sucked me back
in.
If more information is needed, please tell me what you need and I'll try
to provide it.
John
-
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/
