Device Driver Etiquette
Greetings, I maintain a device driver that has been bitten by the transition to 4K stacks. It is a T1/E1 line interface PCI card driver that is maintained outside of the kernel, although is used by a significant number of people. The card has a part for doing echo cancellation, but it is accessed through a vendor API which (when we received it) was quite stack heavy. It used the stack for a number of large data structures, although I have moved a great deal of them (particularly the larger ones) onto the heap instead of the stack. Although this has reduced stack usage to the point where it is usable within 4K stacks, on some code paths, it can still use quite a bit of stack space (though under 4K) for local variables and a handful of small data structures. The problem is that in order to initialize and use the echo canceler, there is a firmware load portion which takes a noticeable period of time (~5-10 seconds). That is done through this stack heavy portion of the code. The problem that I am seeing is that while this card is loading its firmware, there are other device interrupts that occur, and if enough levels of interrupt happen, it overflows the stack. Oh, the firmware load occurs in the context of an ioctl, FWIW. My solution was to disable interrupts while the firmware was being loaded using local_irq_save/local_irq_restore, although that seems to be a naughty thing to do, especially given the long period of time it takes to load the firmware on the card. My question is this: is there a way to either work around the problem I am seeing with the stack without recompiling the kernel with 8K stack size or without disabling irqs for such a long period of time (which I think is not a nice thing to do either) OR is it acceptable (although not nice) to simply fix it this way, by disabling irqs while it loads the firmware? Thanks, Matthew Fredrickson Kernel Developer Digium, Inc. - 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/
Device Driver Etiquette
Greetings, I maintain a device driver that has been bitten by the transition to 4K stacks. It is a T1/E1 line interface PCI card driver that is maintained outside of the kernel, although is used by a significant number of people. The card has a part for doing echo cancellation, but it is accessed through a vendor API which (when we received it) was quite stack heavy. It used the stack for a number of large data structures, although I have moved a great deal of them (particularly the larger ones) onto the heap instead of the stack. Although this has reduced stack usage to the point where it is usable within 4K stacks, on some code paths, it can still use quite a bit of stack space (though under 4K) for local variables and a handful of small data structures. The problem is that in order to initialize and use the echo canceler, there is a firmware load portion which takes a noticeable period of time (~5-10 seconds). That is done through this stack heavy portion of the code. The problem that I am seeing is that while this card is loading its firmware, there are other device interrupts that occur, and if enough levels of interrupt happen, it overflows the stack. Oh, the firmware load occurs in the context of an ioctl, FWIW. My solution was to disable interrupts while the firmware was being loaded using local_irq_save/local_irq_restore, although that seems to be a naughty thing to do, especially given the long period of time it takes to load the firmware on the card. My question is this: is there a way to either work around the problem I am seeing with the stack without recompiling the kernel with 8K stack size or without disabling irqs for such a long period of time (which I think is not a nice thing to do either) OR is it acceptable (although not nice) to simply fix it this way, by disabling irqs while it loads the firmware? Thanks, Matthew Fredrickson Kernel Developer Digium, Inc. - 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: High CPU usage with sata_nv
On Feb 20, 2007, at 9:43 PM, Robert Hancock wrote: Matthew Fredrickson wrote: I have noticed something that might be related as well. I am working on a device driver that would have periodic data errors due to exceptionally long interrupt handling latency. I have come to the point that I suspect that it's the sata_nv driver, and now that we can't do the hdparm -u1 option for sata, it seems to be a bigger problem. What kernel are you using? There were some complaints about latency problems (the ATA status register read taking a ridiculous amount of time to complete) on sata_nv previously, but 2.6.20 should eliminate that problem at least on nForce4 chipsets.. It's a 2.6.18 kernel. What we're seeing (by means of the interrupt pin on another card) is extremely large interrupt latency (measured from the time the interrupt pin goes low to the first couple lines of code in the IRQ handler to clear it) occasionally, in the order of 500-700 microseconds. I figured it was some other driver on the system disabling irqs for a long period of time, but it's difficult to trace what might be doing that. Matthew Fredrickson - 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: High CPU usage with sata_nv
On Feb 20, 2007, at 9:43 PM, Robert Hancock wrote: Matthew Fredrickson wrote: I have noticed something that might be related as well. I am working on a device driver that would have periodic data errors due to exceptionally long interrupt handling latency. I have come to the point that I suspect that it's the sata_nv driver, and now that we can't do the hdparm -u1 option for sata, it seems to be a bigger problem. What kernel are you using? There were some complaints about latency problems (the ATA status register read taking a ridiculous amount of time to complete) on sata_nv previously, but 2.6.20 should eliminate that problem at least on nForce4 chipsets.. It's a 2.6.18 kernel. What we're seeing (by means of the interrupt pin on another card) is extremely large interrupt latency (measured from the time the interrupt pin goes low to the first couple lines of code in the IRQ handler to clear it) occasionally, in the order of 500-700 microseconds. I figured it was some other driver on the system disabling irqs for a long period of time, but it's difficult to trace what might be doing that. Matthew Fredrickson - 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: High CPU usage with sata_nv
On Feb 12, 2007, at 12:49 AM, Tejun Heo wrote: ris wrote: procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 303444 53224 36013200 276 157 627 814 5 2 89 4 0 0 0 302956 53228 36033200 196 0 1193 1686 2 2 95 1 0 0 0 303204 53228 36033200 0 0 1175 1544 2 1 97 0 1 0 0 234656 53240 42888000 34428 0 1498 2532 4 11 69 16 2 0 0 105776 53248 55637200 63752 0 1729 2696 6 18 47 29 0 3 0 9464 53248 64870800 43780 28008 1804 2262 6 20 29 44 0 3 2588 9548 51548 64748800 19200 47616 1503 1903 4 7 42 46 0 3 2640 10152 50840 64848000 24716 11876 1695 2251 5 8 7 80 1 2 2640 9788 46468 65205200 54280 5620 1740 2687 6 18 0 76 0 3 2640 9788 46308 65250000 43392 2212 1626 2038 5 14 0 81 1 2 2640 9636 46308 65300000 38528 1164 1588 2181 4 12 0 84 0 3 2640 13872 46084 64826400 30088 12972 1701 2223 4 12 0 85 0 4 2644 8460 37140 6615720 2640 25648 26372 1615 1908 3 10 0 88 0 3 2644 9188 16760 68319600 33840 48988 1639 2154 4 12 0 84 iowait != cpu busy. Your cpu idleness stays above 80%. I have noticed something that might be related as well. I am working on a device driver that would have periodic data errors due to exceptionally long interrupt handling latency. I have come to the point that I suspect that it's the sata_nv driver, and now that we can't do the hdparm -u1 option for sata, it seems to be a bigger problem. Matthew Fredrickson - 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: High CPU usage with sata_nv
On Feb 12, 2007, at 12:49 AM, Tejun Heo wrote: ris wrote: procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 303444 53224 36013200 276 157 627 814 5 2 89 4 0 0 0 302956 53228 36033200 196 0 1193 1686 2 2 95 1 0 0 0 303204 53228 36033200 0 0 1175 1544 2 1 97 0 1 0 0 234656 53240 42888000 34428 0 1498 2532 4 11 69 16 2 0 0 105776 53248 55637200 63752 0 1729 2696 6 18 47 29 0 3 0 9464 53248 64870800 43780 28008 1804 2262 6 20 29 44 0 3 2588 9548 51548 64748800 19200 47616 1503 1903 4 7 42 46 0 3 2640 10152 50840 64848000 24716 11876 1695 2251 5 8 7 80 1 2 2640 9788 46468 65205200 54280 5620 1740 2687 6 18 0 76 0 3 2640 9788 46308 65250000 43392 2212 1626 2038 5 14 0 81 1 2 2640 9636 46308 65300000 38528 1164 1588 2181 4 12 0 84 0 3 2640 13872 46084 64826400 30088 12972 1701 2223 4 12 0 85 0 4 2644 8460 37140 6615720 2640 25648 26372 1615 1908 3 10 0 88 0 3 2644 9188 16760 68319600 33840 48988 1639 2154 4 12 0 84 iowait != cpu busy. Your cpu idleness stays above 80%. I have noticed something that might be related as well. I am working on a device driver that would have periodic data errors due to exceptionally long interrupt handling latency. I have come to the point that I suspect that it's the sata_nv driver, and now that we can't do the hdparm -u1 option for sata, it seems to be a bigger problem. Matthew Fredrickson - 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/
Goodbye
I have decided to leave lkml because everybody else is doing it too. Matthew Fredrickson - 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/
Goodbye
I have decided to leave lkml because everybody else is doing it too. Matthew Fredrickson - 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: [OT] Sane Architectures
On Mon, Mar 26, 2001 at 06:07:56PM -0500, Adam Schrotenboer wrote: > > alpha? mips? > > Yes, I just didn't feel like listing all arch's. Plus, (ducks) the MIPS > is no longer supported by Windoze, and I rarely see any discussion on lk > about this arch, and I forgot about Alpha for a minute. Mostly because there is an entirely seperate mailing list for MIPS issues. You'll find a quite active list that is so prestegious there are guys that work the MIPS Technologies (The MIPS people :-) ) on it. You might even want to check in on it. The MIPS arch is actually quite nice. It has generally good FP performance, a large pool of general use registers, and many other really convenient attributes. You can join the list by sending a mail to [EMAIL PROTECTED] with subscribe linux-mips [EMAIL PROTECTED] in the body. Matthew Fredrickson - 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: [OT] Sane Architectures
On Mon, Mar 26, 2001 at 06:07:56PM -0500, Adam Schrotenboer wrote: alpha? mips? Yes, I just didn't feel like listing all arch's. Plus, (ducks) the MIPS is no longer supported by Windoze, and I rarely see any discussion on lk about this arch, and I forgot about Alpha for a minute. Mostly because there is an entirely seperate mailing list for MIPS issues. You'll find a quite active list that is so prestegiousg there are guys that work the MIPS Technologies (The MIPS people :-) ) on it. You might even want to check in on it. The MIPS arch is actually quite nice. It has generally good FP performance, a large pool of general use registers, and many other really convenient attributes. You can join the list by sending a mail to [EMAIL PROTECTED] with subscribe linux-mips [EMAIL PROTECTED] in the body. Matthew Fredrickson - 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/
[jford@tusc.net: LUNA: Megaraid problems]
I have a machine with a built-in Adaptec aic7xxx card and a Megaraid PCI card. My system (raid 5) boots off the Megaraid. For this to work I compiled the Megaraid module into the kernel while the aic7xxx loads as a module. dmesg shows the following: megaraid: v107 (December 22, 1999) megaraid: found 0x101e:0x9010:idx 0:bus 0:slot 14:func 0 scsi0 : Found a MegaRAID controller at 0x7810, IRQ: 10 megaraid: [UF80:1.61] detected 1 logical drives scsi0 : AMI MegaRAID UF80 254 commands 16 targs 3 chans 8 luns scsi : 1 host. scsi0: scanning channel 1 for devices. scsi0: scanning channel 2 for devices. scsi0: scanning channel 3 for devices. scsi0: scanning virtual channel for logical drives. Vendor: MegaRAID Model: LD0 RAID5 34712R Rev: UF80 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 3, id 0, lun 0 scsi : detected 1 SCSI generic 1 SCSI disk total. Works great with kernel 2.2.16. Worked great up to kernel 2.3.99-test8 or so. However under the current 2.4.x kernels (2.4.0, 2.4.1, 2.4.2) I get the following message: scsi subsystem driver rev 1.0 megaraid: v107 (Dec 22, 1999) megaraid: found 0x101e: 0x9010: in 00:0e.0 scsi0: found a megaraid controller at 0x7810, irq 10 megaraid: couldn't register I/O register requested_modules[scsi_hostadapter] root fs not found (repeat above 2 more time) VFS - cannot open boot device 806 or 08:06 which makes sense - can't register device, can open device. The only difference I've been able to find between the working and non-working kernels is the "SCSI Subsystem Driver Rev 1.0" line. So, what direction should I go? Anyone have any pointers? Tia. -- James LUNA-LIST help: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] To email the list keeper:[EMAIL PROTECTED] LUNA-LIST Web Site: http://luna.huntsville.al.us/lunalist.htm>
[jford@tusc.net: LUNA: Megaraid problems]
I have a machine with a built-in Adaptec aic7xxx card and a Megaraid PCI card. My system (raid 5) boots off the Megaraid. For this to work I compiled the Megaraid module into the kernel while the aic7xxx loads as a module. dmesg shows the following: megaraid: v107 (December 22, 1999) megaraid: found 0x101e:0x9010:idx 0:bus 0:slot 14:func 0 scsi0 : Found a MegaRAID controller at 0x7810, IRQ: 10 megaraid: [UF80:1.61] detected 1 logical drives scsi0 : AMI MegaRAID UF80 254 commands 16 targs 3 chans 8 luns scsi : 1 host. scsi0: scanning channel 1 for devices. scsi0: scanning channel 2 for devices. scsi0: scanning channel 3 for devices. scsi0: scanning virtual channel for logical drives. Vendor: MegaRAID Model: LD0 RAID5 34712R Rev: UF80 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 3, id 0, lun 0 scsi : detected 1 SCSI generic 1 SCSI disk total. Works great with kernel 2.2.16. Worked great up to kernel 2.3.99-test8 or so. However under the current 2.4.x kernels (2.4.0, 2.4.1, 2.4.2) I get the following message: scsi subsystem driver rev 1.0 megaraid: v107 (Dec 22, 1999) megaraid: found 0x101e: 0x9010: in 00:0e.0 scsi0: found a megaraid controller at 0x7810, irq 10 megaraid: couldn't register I/O register requested_modules[scsi_hostadapter] root fs not found (repeat above 2 more time) VFS - cannot open boot device 806 or 08:06 which makes sense - can't register device, can open device. The only difference I've been able to find between the working and non-working kernels is the "SCSI Subsystem Driver Rev 1.0" line. So, what direction should I go? Anyone have any pointers? Tia. -- James LUNA-LIST help: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] To email the list keeper:[EMAIL PROTECTED] LUNA-LIST Web Site: URL:http://luna.huntsville.al.us/lunalist.htm
Re: [Slightly OT] x86 PROM project
On Sun, Mar 04, 2001 at 08:08:32PM +0100, Erik Mouw wrote: > Have a look at OpenBIOS: > > http://www.freiburg.linux.de/OpenBIOS/ > > The project wants to create an IEEE 1275-1994 compliant firmware, like > used by SUN (for example). I don't want to appear to be offensive in regards to this project considering I have no prior knowledge about it other than what I've seen at the web site just now, but it appears that there is a lot more talk than coding occuring at this project. It just appears that everybody has wants but nobody is turning the wants into realities. Maybe I'm wrong (and I hope I am), but it just seems to be a bit vaporous. > [who likes SUN firmware even more than SGI firmware] [I was just using SGI as an example] Matthew Fredrickson - 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/
[Slightly OT] x86 PROM project
What does everybody think of the idea of trying to write a RISC PROM-like BIOS for the x86 architecture? I've been tossing the idea around in my head for a while, and after I got my first SGI I realized that something like this would be fairly useful. Basically, I'm wondering if anybody is already doing something like this (not linuxBIOS, though the code for that could be a useful base). Thanks. Matthew Fredrickson - 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/
[Slightly OT] x86 PROM project
What does everybody think of the idea of trying to write a RISC PROM-like BIOS for the x86 architecture? I've been tossing the idea around in my head for a while, and after I got my first SGI I realized that something like this would be fairly useful. Basically, I'm wondering if anybody is already doing something like this (not linuxBIOS, though the code for that could be a useful base). Thanks. Matthew Fredrickson - 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: [Slightly OT] x86 PROM project
On Sun, Mar 04, 2001 at 08:08:32PM +0100, Erik Mouw wrote: Have a look at OpenBIOS: http://www.freiburg.linux.de/OpenBIOS/ The project wants to create an IEEE 1275-1994 compliant firmware, like used by SUN (for example). I don't want to appear to be offensive in regards to this project considering I have no prior knowledge about it other than what I've seen at the web site just now, but it appears that there is a lot more talk than coding occuring at this project. It just appears that everybody has wants but nobody is turning the wants into realities. Maybe I'm wrong (and I hope I am), but it just seems to be a bit vaporous. [who likes SUN firmware even more than SGI firmware] [I was just using SGI as an example] Matthew Fredrickson - 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: Errors compiling 2.4.2
On Wed, Feb 28, 2001 at 05:13:26PM -0700, Jeff Coy wrote: > Are you by chance using HJ's new binutils? I believe he stated in his > announcement that -oformat now needs to be --oformat to function. Thanks very much, I didn't even think about that. Sorry for bugging the list about it, but the quick response is appreciated _very_ much so. Matthew Fredrickson - 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/
Errors compiling 2.4.2
When I do a make bzImage I get this problem: nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map make[1]: Entering directory `/usr/src/linux-2.4.2/arch/i386/boot' ld -m elf_i386 -Ttext 0x0 -s -oformat binary bbootsect.o -o bbootsect ld: cannot open binary: No such file or directory make[1]: *** [bbootsect] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.2/arch/i386/boot' make: *** [bzImage] Error 2 I don't exactly understand what's the problem but it's located at the ld line, and I can't seem to identify what binary it can't seem to find. I'm running debian (unstable) system, 2.4.1, Athlon-1Ghz, Asus A7Pro board, ld version : GNU ld version 2.10.91 (with BFD 2.10.91.0.2) Any help would be appreciated. btw, if I just do a regular make, it works out fine, just that one line seems to be problematic. Matthew Fredrickson - 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/
Errors compiling 2.4.2
When I do a make bzImage I get this problem: nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort System.map make[1]: Entering directory `/usr/src/linux-2.4.2/arch/i386/boot' ld -m elf_i386 -Ttext 0x0 -s -oformat binary bbootsect.o -o bbootsect ld: cannot open binary: No such file or directory make[1]: *** [bbootsect] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.2/arch/i386/boot' make: *** [bzImage] Error 2 I don't exactly understand what's the problem but it's located at the ld line, and I can't seem to identify what binary it can't seem to find. I'm running debian (unstable) system, 2.4.1, Athlon-1Ghz, Asus A7Pro board, ld version : GNU ld version 2.10.91 (with BFD 2.10.91.0.2) Any help would be appreciated. btw, if I just do a regular make, it works out fine, just that one line seems to be problematic. Matthew Fredrickson - 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: Errors compiling 2.4.2
On Wed, Feb 28, 2001 at 05:13:26PM -0700, Jeff Coy wrote: Are you by chance using HJ's new binutils? I believe he stated in his announcement that -oformat now needs to be --oformat to function. Thanks very much, I didn't even think about that. Sorry for bugging the list about it, but the quick response is appreciated _very_ much so. Matthew Fredrickson - 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: [ANNOUNCE] Linux-NTFS project, first public release
On Sun, Feb 04, 2001 at 01:51:43AM +, Anton Altaparmakov wrote: > At 02:42 04/02/2001, you wrote: > >Hell will freeze, and the US will break off from the continental mass and > >sink into the oceans before I think MS will ever endorse Linux > >officially. I could be wrong, but I doubt it. > > Well there is that. But why not think positive. You never know. Miracles > sometimes do happen. And just as darkness covers the entire earth, a light comes from the clouds. A voice says, "Behold, this is my beloved son, hear him" And then the people didn't need Microsoft anymore. :-) Matthew Fredrickson - 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: [ANNOUNCE] Linux-NTFS project, first public release
On Sun, Feb 04, 2001 at 01:51:43AM +, Anton Altaparmakov wrote: At 02:42 04/02/2001, you wrote: Hell will freeze, and the US will break off from the continental mass and sink into the oceans before I think MS will ever endorse Linux officially. I could be wrong, but I doubt it. Well there is that. But why not think positive. You never know. Miracles sometimes do happen. And just as darkness covers the entire earth, a light comes from the clouds. A voice says, "Behold, this is my beloved son, hear him" And then the people didn't need Microsoft anymore. :-) Matthew Fredrickson - 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: Kernel PPP/Modem connection problems starting somewhere between 2.2.14(maybe 15) and 2.2.18
On Sun, Jan 28, 2001 at 07:48:29PM +, Adrian Bridgett wrote: > On Wed, Jan 24, 2001 at 17:30:38 -0600 (+), Matthew Fredrickson wrote: > > I'm not positive if this is a bug, I'm only able to confirm this from one > > other source. Somewhere between (I can't remember exactly which kernel my > > server started on) ~2.2.14(or 15) and 2.2.18 my ppp connection > > periodically hangs and I have to restart the connection. My situation is > [snip] > > Ditto. Using evil winmodem here and Debian (ppp-2.4.0f-1). 2.2.19pre3 at > the moment but it's been happening for a while. Things seemed better when I > turned on default-asyncmap, however it still occasionally goes belly up > (almost _always_ when scping files out (uploading Debian packages)). Last > time I checked it also happend with my 28.8k USB modem (a normal modem, that > one). > > I've found a magic fix and when I've got time I'll try and burrow though the > pppd source to try and find out why. The magic fix? Turn on recording in > pppd (i.e. add "record /tmp/foo" to /etc/ppp/options). I'd be interested > if it fixes it for you. I'm not positive, but so far, it looks like that fixed the problem. I don't know what would cause it to break like that, but I think I'm going to go hunt around changelogs to see if there are any major changes in that kernel version range. -- Matthew Fredrickson AIM MatthewFredricks ICQ 13923212 [EMAIL PROTECTED] http://www.fredricknet.net/~matt/ "Everything is relative" - 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: Kernel PPP/Modem connection problems starting somewhere between 2.2.14(maybe 15) and 2.2.18
On Sun, Jan 28, 2001 at 07:48:29PM +, Adrian Bridgett wrote: On Wed, Jan 24, 2001 at 17:30:38 -0600 (+), Matthew Fredrickson wrote: I'm not positive if this is a bug, I'm only able to confirm this from one other source. Somewhere between (I can't remember exactly which kernel my server started on) ~2.2.14(or 15) and 2.2.18 my ppp connection periodically hangs and I have to restart the connection. My situation is [snip] Ditto. Using evil winmodem here and Debian (ppp-2.4.0f-1). 2.2.19pre3 at the moment but it's been happening for a while. Things seemed better when I turned on default-asyncmap, however it still occasionally goes belly up (almost _always_ when scping files out (uploading Debian packages)). Last time I checked it also happend with my 28.8k USB modem (a normal modem, that one). I've found a magic fix and when I've got time I'll try and burrow though the pppd source to try and find out why. The magic fix? Turn on recording in pppd (i.e. add "record /tmp/foo" to /etc/ppp/options). I'd be interested if it fixes it for you. I'm not positive, but so far, it looks like that fixed the problem. I don't know what would cause it to break like that, but I think I'm going to go hunt around changelogs to see if there are any major changes in that kernel version range. -- Matthew Fredrickson AIM MatthewFredricks ICQ 13923212 [EMAIL PROTECTED] http://www.fredricknet.net/~matt/ "Everything is relative" - 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: More on the VIA KT133 chipset misbehaving in Linux
On Mon, Jan 29, 2001 at 11:14:02AM +, Adrian Cox wrote: > Dylan Griffiths wrote: > > The VIA KT133 chipset exhibits the following bugs under Linux 2.2.17 and > > 2.4.0: > > 1) PS/2 mouse cursor randomly jumps to upper right hand corner of screen and > > locks for a bit > > This happens to me about once a month on a BX chipset PII machine here, > and on a KT133 chipset machine I have. I have to hit ctrl-alt-backspace > to regain control of the console. I always assumed it was a bug in X, > but it never caused me enough trouble to actually make me pursue it. It happens to me also. In fact, I posted a message a week or two ago asking if anybody else had similar trouble and if anybody knew anything about it. I eventually just quit using the ps/2 mouse port and hooked my mouse up to the usb port to get it fixed. It irritated me a great deal though until I finally just switched it over to usb. Matthew Fredrickson - 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: PPP/Modem connection problems starting somewhere between 2.2.14(maybe 15) and 2.2.18
On Sun, Jan 28, 2001 at 07:48:29PM +, Adrian Bridgett wrote: > On Wed, Jan 24, 2001 at 17:30:38 -0600 (+), Matthew Fredrickson wrote: > > I'm not positive if this is a bug, I'm only able to confirm this from one > > other source. Somewhere between (I can't remember exactly which kernel my > > server started on) ~2.2.14(or 15) and 2.2.18 my ppp connection > > periodically hangs and I have to restart the connection. My situation is > [snip] > > Ditto. Using evil winmodem here and Debian (ppp-2.4.0f-1). 2.2.19pre3 at > the moment but it's been happening for a while. Things seemed better when I > turned on default-asyncmap, however it still occasionally goes belly up > (almost _always_ when scping files out (uploading Debian packages)). Last > time I checked it also happend with my 28.8k USB modem (a normal modem, that > one). > > I've found a magic fix and when I've got time I'll try and burrow though the > pppd source to try and find out why. The magic fix? Turn on recording in > pppd (i.e. add "record /tmp/foo" to /etc/ppp/options). I'd be interested > if it fixes it for you. Just put it in, will see if it helps any. FWIW, my modem is a USR ISA 56k, and had been rock solid until around there. My friend also had the same issues, and before we'd talked to each other about it, we'd both assumed that possibly the modem might be failing. After finding that we both had troubles, and around the same "kernel time frame", we knew that something must have happened in the kernel that either broke something with the PPP or the kernel end of it. Thanks for responding. -- Matthew Fredrickson AIM MatthewFredricks ICQ 13923212 [EMAIL PROTECTED] http://www.fredricknet.net/~matt/ "Everything is relative" - 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: More on the VIA KT133 chipset misbehaving in Linux
On Mon, Jan 29, 2001 at 11:14:02AM +, Adrian Cox wrote: Dylan Griffiths wrote: The VIA KT133 chipset exhibits the following bugs under Linux 2.2.17 and 2.4.0: 1) PS/2 mouse cursor randomly jumps to upper right hand corner of screen and locks for a bit This happens to me about once a month on a BX chipset PII machine here, and on a KT133 chipset machine I have. I have to hit ctrl-alt-backspace to regain control of the console. I always assumed it was a bug in X, but it never caused me enough trouble to actually make me pursue it. It happens to me also. In fact, I posted a message a week or two ago asking if anybody else had similar trouble and if anybody knew anything about it. I eventually just quit using the ps/2 mouse port and hooked my mouse up to the usb port to get it fixed. It irritated me a great deal though until I finally just switched it over to usb. Matthew Fredrickson - 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/
PPP/Modem connection problems starting somewhere between 2.2.14(maybe 15) and 2.2.18
I'm not positive if this is a bug, I'm only able to confirm this from one other source. Somewhere between (I can't remember exactly which kernel my server started on) ~2.2.14(or 15) and 2.2.18 my ppp connection periodically hangs and I have to restart the connection. My situation is a modem that is dialed into the internet pretty close to 24/7. Sometimes the connection seems to hang up (but ifconfig reports ppp0 as being there and up w/ and IP address). The only solution to this problem is killing wvdial and wvdial'ing again. Sometimes (pretty randomly I might add) even when I redial it has this problem when it dials up except I can get a few kilobytes and then the connection freezes up. I can confirm this by a friend of mine who is just running a periodic dialup box but has seen similar troubles in the same time frame. He and I are both running debian (potato) on the boxen involved. This problem has persisted and still occurs even as I've upgraded the kernel but I think (not sure) that it has gotten a little better w/2.2.18. I'm not sure how I can replicate it, but sometimes when I get home I find the internet connection not working and the linux box says ppp0 is up. I would appreciate any help I can get. I'm about to go look at historical kernel changelogs. Thanks. -- Matthew Fredrickson AIM MatthewFredricks ICQ 13923212 [EMAIL PROTECTED] http://www.fredricknet.net/~matt/ "Everything is relative" - 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/
PPP/Modem connection problems starting somewhere between 2.2.14(maybe 15) and 2.2.18
I'm not positive if this is a bug, I'm only able to confirm this from one other source. Somewhere between (I can't remember exactly which kernel my server started on) ~2.2.14(or 15) and 2.2.18 my ppp connection periodically hangs and I have to restart the connection. My situation is a modem that is dialed into the internet pretty close to 24/7. Sometimes the connection seems to hang up (but ifconfig reports ppp0 as being there and up w/ and IP address). The only solution to this problem is killing wvdial and wvdial'ing again. Sometimes (pretty randomly I might add) even when I redial it has this problem when it dials up except I can get a few kilobytes and then the connection freezes up. I can confirm this by a friend of mine who is just running a periodic dialup box but has seen similar troubles in the same time frame. He and I are both running debian (potato) on the boxen involved. This problem has persisted and still occurs even as I've upgraded the kernel but I think (not sure) that it has gotten a little better w/2.2.18. I'm not sure how I can replicate it, but sometimes when I get home I find the internet connection not working and the linux box says ppp0 is up. I would appreciate any help I can get. I'm about to go look at historical kernel changelogs. Thanks. -- Matthew Fredrickson AIM MatthewFredricks ICQ 13923212 [EMAIL PROTECTED] http://www.fredricknet.net/~matt/ "Everything is relative" - 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: VIA chipset discussion
On Fri, Jan 19, 2001 at 11:42:01AM -0500, John O'Donnell wrote: > Vojtech Pavlik wrote: > > > > On Thu, Jan 18, 2001 at 11:42:25PM +, Howard Johnson wrote: > > > On Thu, Jan 18, 2001 at 06:32:39PM -0500, John O'Donnell wrote: > > > > Matthew Fredrickson wrote: > > > > > > > > I have the ASUS CUV4X. > > > > VIA vt82c686a (cf/cg) IDE UDMA66 controller on pci0:4.1 > > > > I also run DMA66 with no problems here. > > > > > > > > I never have seen any issues with the PS/2 mouse and X. > > > > I use the Logitech cordless wheel mouse. I use the "MouseManPlusPS/2" > > > > driver in XFree. When I was first setting this up (about a year ago) > > > > I had the problems you mention. I read an article on setting up your > > > > scroll wheel in X and it said to use the IMPS/2 setting. This was > > > > nothing but trouble, till I RTFM on XFree and mice and found my solution. > > > > Can you tell us what kind of mouse this is and how you have it set up in > > > > XFree. > > > > > > I'm seeing the same mouse problems... fine under 2.2.x, but jumps around under > > > a couple of 2.4.x releases (2.4.0-test6, IIRC, and 2.4.1-pre7). I find it odd > > > that if it isn't a kernel-related problem, that it's only manifesting itself > > > under 2.4. > > > > > > I'm running a slot A athlon on an abit KA7-100. > > > > My bet is ACPI/powermanagement messing with it ... > > Forgive me. I know _nothing_ about Power Management resources. > What kind of resouces would PM use to interfere with the mouse. > FYI I have power management turned off in my BIOS and in the kernel > I have CONFIG_APM and ONLY CONFIG_APM_REAL_MODE_POWER_OFF. > How does that compare with the rest of you? The same for me if I remember correctly (I've been dinking around on the linux side of my box sparingly with X not working correctly), though I might have compiled in some other ACPI stuff if I thought it looked cool (heh). My trouble is that I figure that the kernel must have _something_ to do with it since my problem got slightly better since upgrading from 2.2.18 to 2.4.0. just my .02 Matthew Fredrickson - 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: VIA chipset discussion
On Fri, Jan 19, 2001 at 11:42:01AM -0500, John O'Donnell wrote: Vojtech Pavlik wrote: On Thu, Jan 18, 2001 at 11:42:25PM +, Howard Johnson wrote: On Thu, Jan 18, 2001 at 06:32:39PM -0500, John O'Donnell wrote: Matthew Fredrickson wrote: I have the ASUS CUV4X. VIA vt82c686a (cf/cg) IDE UDMA66 controller on pci0:4.1 I also run DMA66 with no problems here. I never have seen any issues with the PS/2 mouse and X. I use the Logitech cordless wheel mouse. I use the "MouseManPlusPS/2" driver in XFree. When I was first setting this up (about a year ago) I had the problems you mention. I read an article on setting up your scroll wheel in X and it said to use the IMPS/2 setting. This was nothing but trouble, till I RTFM on XFree and mice and found my solution. Can you tell us what kind of mouse this is and how you have it set up in XFree. I'm seeing the same mouse problems... fine under 2.2.x, but jumps around under a couple of 2.4.x releases (2.4.0-test6, IIRC, and 2.4.1-pre7). I find it odd that if it isn't a kernel-related problem, that it's only manifesting itself under 2.4. I'm running a slot A athlon on an abit KA7-100. My bet is ACPI/powermanagement messing with it ... Forgive me. I know _nothing_ about Power Management resources. What kind of resouces would PM use to interfere with the mouse. FYI I have power management turned off in my BIOS and in the kernel I have CONFIG_APM and ONLY CONFIG_APM_REAL_MODE_POWER_OFF. How does that compare with the rest of you? The same for me if I remember correctly (I've been dinking around on the linux side of my box sparingly with X not working correctly), though I might have compiled in some other ACPI stuff if I thought it looked cool (heh). My trouble is that I figure that the kernel must have _something_ to do with it since my problem got slightly better since upgrading from 2.2.18 to 2.4.0. just my .02 Matthew Fredrickson - 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: VIA chipset discussion
On Thu, Jan 18, 2001 at 02:04:08AM -0200, Rogerio Brito wrote: > On Jan 17 2001, David D.W. Downey wrote: > > > > Could those that were involved in the VIA chipset discussion email me > > privately at [EMAIL PROTECTED]? > > Just to add a datapoint to the discussion, I'm using a VIA > chipset here (in fact, it's an Asus A7V board with a Duron), a > 2.2.18 kernel with André's patches and I'm only using IDE > (UDMA/66 and UDMA/33 here) and I'm *not* seeing any problems. BTW, are you having any trouble with your ps/2 mouse port in X? On my new ASUS board, ps/2 mouse devices (just in X, gpm works fine) act a little crazy (random mouse movement, random clicking, etc., except I'm not the one doing all the random movement). I'm not sure what it is, though I do know it's not as bad once I upgraded from 2.2.18pre21 to 2.4.0. I think I'm going to try using the mouse as a usb device and see if I still have trouble. Anyway, just wondering if you're seeing the same problem. Matthew Fredrickson - 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: VIA chipset discussion
On Thu, Jan 18, 2001 at 02:04:08AM -0200, Rogerio Brito wrote: On Jan 17 2001, David D.W. Downey wrote: Could those that were involved in the VIA chipset discussion email me privately at [EMAIL PROTECTED]? Just to add a datapoint to the discussion, I'm using a VIA chipset here (in fact, it's an Asus A7V board with a Duron), a 2.2.18 kernel with Andr's patches and I'm only using IDE (UDMA/66 and UDMA/33 here) and I'm *not* seeing any problems. BTW, are you having any trouble with your ps/2 mouse port in X? On my new ASUS board, ps/2 mouse devices (just in X, gpm works fine) act a little crazy (random mouse movement, random clicking, etc., except I'm not the one doing all the random movement). I'm not sure what it is, though I do know it's not as bad once I upgraded from 2.2.18pre21 to 2.4.0. I think I'm going to try using the mouse as a usb device and see if I still have trouble. Anyway, just wondering if you're seeing the same problem. Matthew Fredrickson - 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/
PROBLEM: PS/2 Mouse && Asus A7V Mobo && X 4.0.x (and 3.3.x)
Specs: AMD T-bird 1ghz Asus A7Vpro motherboard 160M of mem Kensington Mouseworks mouse(or any other ps2 mouse I hook up for that matter) I think those are all the relevant specs. My problem is in that when I try to use my mouse in X, after a brief period of time my mouse pointer activity goes a little crazy. It almosts start acting like a mouse does when you used to switch it to 3 button mode in windows. It seems to occur mostly when the mouse button is held down (click and drag operations). The only reason I'm mailing the kernel list about it is that when I upgraded from kernel 2.2.18pre21 which caused the mouse pointer to eventually completely freeze, to 2.4.0 stock it doesn't lock up completely anymore, just is a little bit sporadic. Any ideas what might be causing this? My ignorance is about to show through, but could it be some kind of bug in the VIA ps/2 mouse code? (ugh). I wasn't quite sure to what extent I should go into detail about what is happening, so if more info is needed, I can give more. btw, gpm works just fine with no problems, just X has problems. Thanks. -- Matthew Fredrickson AIM MatthewFredricks ICQ 13923212 [EMAIL PROTECTED] http://www.fredricknet.net/~matt/ "Everything is relative" - 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/
PROBLEM: PS/2 Mouse Asus A7V Mobo X 4.0.x (and 3.3.x)
Specs: AMD T-bird 1ghz Asus A7Vpro motherboard 160M of mem Kensington Mouseworks mouse(or any other ps2 mouse I hook up for that matter) I think those are all the relevant specs. My problem is in that when I try to use my mouse in X, after a brief period of time my mouse pointer activity goes a little crazy. It almosts start acting like a mouse does when you used to switch it to 3 button mode in windows. It seems to occur mostly when the mouse button is held down (click and drag operations). The only reason I'm mailing the kernel list about it is that when I upgraded from kernel 2.2.18pre21 which caused the mouse pointer to eventually completely freeze, to 2.4.0 stock it doesn't lock up completely anymore, just is a little bit sporadic. Any ideas what might be causing this? My ignorance is about to show through, but could it be some kind of bug in the VIA ps/2 mouse code? (ugh). I wasn't quite sure to what extent I should go into detail about what is happening, so if more info is needed, I can give more. btw, gpm works just fine with no problems, just X has problems. Thanks. -- Matthew Fredrickson AIM MatthewFredricks ICQ 13923212 [EMAIL PROTECTED] http://www.fredricknet.net/~matt/ "Everything is relative" - 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: [Demo program]: Poor elevator performance in 2.4.0-test9pre6
On Wed, Sep 27, 2000 at 04:10:38PM +1000, Robert Cohen wrote: > > [EMAIL PROTECTED] wrote > > I doubt this has any relevance whatsoever, but when I try this on a > 2.2.16 > kernel running on top of a Pentium Pro 200 w/96megs of mem w/ a SCSI 2 > disk, I get some funny numbers: > > matt@zeus:~/cwork/personal$ ./elv_test 8 30 > files created, 240 megs written at 4.32 megs/sec > finished writing 240 megs written at 1794.23 megs per sec > finished reading, 240 megs read at 1675.813817 megs/sec > > Any ideas why I would be getting these numbers? > - > > That will teach me to play fast and loose with checking error returns > from system calls. I wasnt specifying a mode when creating the files. > So they were being created without user write permission.. > I dont know why it worked under 2.4.0. Maybe a kernel bug :-). > > Anyway, a new version is available now at > http://tltsu.anu.edu.au/~robert/elv_test.c Ah, thanks. I have much more likely results now: matt@zeus:~/cwork/personal$ ./elv_test2 8 30 files created, 240 megs written at 3.91 megs/sec finished writing 240 megs written at 2.28 megs per sec finished reading, 240 megs read at 0.909702 megs/sec BTW, why would the first incorrectly function in kernel 2.2? A bug feature? - 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/
