Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Andrea Arcangeli quoted: > On Thu, Jul 05, 2001 at 11:46:33AM -0400, Arjan van de Ven wrote: > > On Thu, Jul 05, 2001 at 11:32:00PM +0800, Thibaut Laurent wrote: > > > And the winner is... Andrea. Kudos to you, I've just applied these patches, > > > recompiled and it seems to work fine. > > > Too bad, this was the perfect excuse for getting rid of those good old Cyrix > > > boxen ;) > > > > As Andrea's patches don't actually fix anything Cyrix related it's obvious > > that they just avoid the real bug instead of fixing it. > > It's a very useful datapoint though. Put me in the "it works for me" camp also. Do we have the definitive answer as far as what is/was broken? Thanks, Andrea... --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Alan Cox wrote: > > Something I forgot to mention that I didn't see in any of the other > > problem reports. In my case, the panic happens immediately after > > "Calibrating delay loop" appears during the boot sequence. > > Duplicated here. Works fine on a non Cyrix processor with the same kernel image. > Perhaps the folks who submitted the 2.4.6 tasklet changes could review them ? Definitely *not* "APIC support on uniprocessor" related. At least one of the posted configurations had that option disabled. --Bob - 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: [2.4.6] kernel BUG at softirq.c:206!
Alan Cox wrote: > Intriguing its all Cyrix. That was the first thing that hit me (stood out). > What compiler, what processor choice in the build. compiler: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) processor choice: 586/K5/5x86/6x86/6x86MXCONFIG_M586 > It looks like it is time > to run 2.4.6ac on my Cyrix MII/233 and take a look. Any chance this might be an "APIC support on uniprocessor" kind of thing? I haven't tried disabling that yet to see if it makes any difference, and it will be several hours before I'll get a chance to try it :-(. --Bob - 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: [2.4.6] kernel BUG at softirq.c:206!
Something I forgot to mention that I didn't see in any of the other problem reports. In my case, the panic happens immediately after "Calibrating delay loop" appears during the boot sequence. --Bob - 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: [2.4.6] kernel BUG at softirq.c:206!
Alan Cox wrote: > > This bug hits me since 2.4.6-pre5 but nobody answered to my emails... The > > code line is identical (and the softirq.c:206 ofc). > > > > Anyone, any idea? > > None at all. There are odd items in your config - like khttpd which if > involved might explain why there are not more reports. Add me to the list :-(. Like the other folks reporting the softirq.c:206 panic problem, I've got a Cyrix. Mine's a MII 300 (233 MHz). Works fine with 2.4.5 and prior kernels. Didn't try any of the pre-2.4.6 or -ac kernels. Oops report available on request, but it's similar if not identical to one I saw posted earlier. --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Andrea Arcangeli quoted: On Thu, Jul 05, 2001 at 11:46:33AM -0400, Arjan van de Ven wrote: On Thu, Jul 05, 2001 at 11:32:00PM +0800, Thibaut Laurent wrote: And the winner is... Andrea. Kudos to you, I've just applied these patches, recompiled and it seems to work fine. Too bad, this was the perfect excuse for getting rid of those good old Cyrix boxen ;) As Andrea's patches don't actually fix anything Cyrix related it's obvious that they just avoid the real bug instead of fixing it. It's a very useful datapoint though. Put me in the it works for me camp also. Do we have the definitive answer as far as what is/was broken? Thanks, Andrea... --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Alan Cox wrote: Something I forgot to mention that I didn't see in any of the other problem reports. In my case, the panic happens immediately after Calibrating delay loop appears during the boot sequence. Duplicated here. Works fine on a non Cyrix processor with the same kernel image. Perhaps the folks who submitted the 2.4.6 tasklet changes could review them ? Definitely *not* APIC support on uniprocessor related. At least one of the posted configurations had that option disabled. --Bob - 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: [2.4.6] kernel BUG at softirq.c:206!
Alan Cox wrote: This bug hits me since 2.4.6-pre5 but nobody answered to my emails... The code line is identical (and the softirq.c:206 ofc). Anyone, any idea? None at all. There are odd items in your config - like khttpd which if involved might explain why there are not more reports. Add me to the list :-(. Like the other folks reporting the softirq.c:206 panic problem, I've got a Cyrix. Mine's a MII 300 (233 MHz). Works fine with 2.4.5 and prior kernels. Didn't try any of the pre-2.4.6 or -ac kernels. Oops report available on request, but it's similar if not identical to one I saw posted earlier. --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Something I forgot to mention that I didn't see in any of the other problem reports. In my case, the panic happens immediately after Calibrating delay loop appears during the boot sequence. --Bob - 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: [2.4.6] kernel BUG at softirq.c:206!
Alan Cox wrote: Intriguing its all Cyrix. That was the first thing that hit me (stood out). What compiler, what processor choice in the build. compiler: gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) processor choice: 586/K5/5x86/6x86/6x86MXCONFIG_M586 It looks like it is time to run 2.4.6ac on my Cyrix MII/233 and take a look. Any chance this might be an APIC support on uniprocessor kind of thing? I haven't tried disabling that yet to see if it makes any difference, and it will be several hours before I'll get a chance to try it :-(. --Bob - 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: SCSI Tape Corruption - update
[EMAIL PROTECTED] wrote: > It seems that the tape is written incorrectly. I wrote some large file > (300MB) > and read it back four time. The read copies are all the same. They differ > from the original only in 32 consecutive bytes (the replaced values SEEM > random). Of course, 32 bytes in 300MB tar.gz files are TOO MUCH to be > accepted :) Several years ago I ran into a problem with similar symptoms on an old Adaptec AHA-154X controller. Files (and most certainly "file systems" if I had persisted) on my hard disk were getting corrupted in random places with constant length strings of garbage. This turned out to be an inappropriate setting for the AHA1542_SCATTER constant: it *was* 16, and setting it to 8 fixed my problem. I'd look for a similar "#define" in the header file for your SCSI device driver and try cutting the value by half. Why "half"? No justification other than it worked for me, and it's a power-of-two kind of thing that hardware seems to like :-). --Bob - 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: SCSI Tape Corruption - update
[EMAIL PROTECTED] wrote: It seems that the tape is written incorrectly. I wrote some large file (300MB) and read it back four time. The read copies are all the same. They differ from the original only in 32 consecutive bytes (the replaced values SEEM random). Of course, 32 bytes in 300MB tar.gz files are TOO MUCH to be accepted :) Several years ago I ran into a problem with similar symptoms on an old Adaptec AHA-154X controller. Files (and most certainly "file systems" if I had persisted) on my hard disk were getting corrupted in random places with constant length strings of garbage. This turned out to be an inappropriate setting for the AHA1542_SCATTER constant: it *was* 16, and setting it to 8 fixed my problem. I'd look for a similar "#define" in the header file for your SCSI device driver and try cutting the value by half. Why "half"? No justification other than it worked for me, and it's a power-of-two kind of thing that hardware seems to like :-). --Bob - 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/
Cyrix/mtrr fix missing from 2.4.3
The following fix was omitted from 2.4.3. It corrects a problem where the mtrr code attempts to set up a region twice as large as the user requested. The original message appeared in linux-kernel on 14 Mar 2001. --Bob Tracy - Forwarded message from David Wragg - >From: David Wragg <[EMAIL PROTECTED]> >Date: 14 Mar 2001 22:57:21 + Oops, it got broken by the MTRR >32-bit support in 2.4.0-testX. The patch below should fix it. Joerg, I think this might well fix your Cyrix mtrr problem also. Let me know how it goes, Dave Wragg diff -uar linux-2.4.2/arch/i386/kernel/mtrr.c linux-2.4.2.cyrix/arch/i386/kernel/mtrr.c --- linux-2.4.2/arch/i386/kernel/mtrr.c Thu Feb 22 15:24:53 2001 +++ linux-2.4.2.cyrix/arch/i386/kernel/mtrr.c Wed Mar 14 22:28:02 2001 @@ -538,7 +538,7 @@ * Note: shift==0xf means 4G, this is unsupported. */ if (shift) - *size = (reg < 7 ? 0x1UL : 0x40UL) << shift; + *size = (reg < 7 ? 0x1UL : 0x40UL) << (shift - 1); else *size = 0; - End of forwarded message from David Wragg - - 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/
Cyrix/mtrr fix missing from 2.4.3
The following fix was omitted from 2.4.3. It corrects a problem where the mtrr code attempts to set up a region twice as large as the user requested. The original message appeared in linux-kernel on 14 Mar 2001. --Bob Tracy - Forwarded message from David Wragg - From: David Wragg [EMAIL PROTECTED] Date: 14 Mar 2001 22:57:21 + Oops, it got broken by the MTRR 32-bit support in 2.4.0-testX. The patch below should fix it. Joerg, I think this might well fix your Cyrix mtrr problem also. Let me know how it goes, Dave Wragg diff -uar linux-2.4.2/arch/i386/kernel/mtrr.c linux-2.4.2.cyrix/arch/i386/kernel/mtrr.c --- linux-2.4.2/arch/i386/kernel/mtrr.c Thu Feb 22 15:24:53 2001 +++ linux-2.4.2.cyrix/arch/i386/kernel/mtrr.c Wed Mar 14 22:28:02 2001 @@ -538,7 +538,7 @@ * Note: shift==0xf means 4G, this is unsupported. */ if (shift) - *size = (reg 7 ? 0x1UL : 0x40UL) shift; + *size = (reg 7 ? 0x1UL : 0x40UL) (shift - 1); else *size = 0; - End of forwarded message from David Wragg - - 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 Worm (fwd)
Gregory Maxwell wrote: > On Mon, Mar 26, 2001 at 10:07:22AM -0500, Richard B. Johnson wrote: > [snip] > > I have just received notice that my machines will no longer be > > provided access to "The Internet". > > It's sad that people like the one who sent out messages like that can stay > employed. So let's quit covering for 'em. Let's have the name(s) behind that idiotic policy letter, because I would not knowingly allow any company I work for to hire such people. ProblemRemedy ----- hangnail amputate headache amputate (etc.) Sheesh... --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Worm (fwd)
Gregory Maxwell wrote: On Mon, Mar 26, 2001 at 10:07:22AM -0500, Richard B. Johnson wrote: [snip] I have just received notice that my machines will no longer be provided access to "The Internet". It's sad that people like the one who sent out messages like that can stay employed. So let's quit covering for 'em. Let's have the name(s) behind that idiotic policy letter, because I would not knowingly allow any company I work for to hire such people. ProblemRemedy ----- hangnail amputate headache amputate (etc.) Sheesh... --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: another Cyrix/mtrr problem?
David Wragg wrote: > [EMAIL PROTECTED] (Bob_Tracy) writes: > > echo "base=0xd800 size=0x10 type=write-combining" >| /proc/mtrr > > > > I get a 2MB region instead of the 1MB region I expected... > > Oops, it got broken by the MTRR >32-bit support in 2.4.0-testX. The > patch below should fix it. > > Joerg, I think this might well fix your Cyrix mtrr problem also. > > Let me know how it goes, That fixed the "wrong size" problem nicely. Thanks! AGP support on this beast (Tyan S1590S / Apollo MVP3) is still broken, however. I'll try the new NVIDIA driver (as someone suggested -- thanks for the steer!) and see if that helps. If there's an NVIDIA person reading this that would like to work this issue off-line, your help would be appreciated. Thanks! -- Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: another Cyrix/mtrr problem?
David Wragg wrote: [EMAIL PROTECTED] (Bob_Tracy) writes: echo "base=0xd800 size=0x10 type=write-combining" | /proc/mtrr I get a 2MB region instead of the 1MB region I expected... Oops, it got broken by the MTRR 32-bit support in 2.4.0-testX. The patch below should fix it. Joerg, I think this might well fix your Cyrix mtrr problem also. Let me know how it goes, That fixed the "wrong size" problem nicely. Thanks! AGP support on this beast (Tyan S1590S / Apollo MVP3) is still broken, however. I'll try the new NVIDIA driver (as someone suggested -- thanks for the steer!) and see if that helps. If there's an NVIDIA person reading this that would like to work this issue off-line, your help would be appreciated. Thanks! -- Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: another Cyrix/mtrr problem?
[EMAIL PROTECTED] wrote: > Normally the answer would be "Closed driver, complain to nVidia", > but just in case.. Glad you were open-minded enough to consider that it *might* be "our" code. > Can you verify that.. > > a. You have MTRR support compiled into the kernel. yes > b. You have a /proc/mtrr file yes > c. You can add/delete ranges using /proc/mtrr > (See Documentation/mtrr.txt for info on how to do this) yes, BUT... The "Documentation/mtrr.txt" file says "... 4 megabytes, which is 0x40 bytes (in hexadecimal)." The math is correct: 1MB == 2**20 == 0x10 the last time I checked. Unfortunately, when I execute echo "base=0xd800 size=0x10 type=write-combining" >| /proc/mtrr I get a 2MB region instead of the 1MB region I expected... reg00: base=0xd800 (3456MB), size= 2MB: write-combining, count=1 reg01: base=0x000c ( 0MB), size= 512KB: uncachable, count=1 reg07: base=0x ( 0MB), size= 256MB: write-through, count=1 Similarly, the NVIDIA driver attempts to create a 32MB write-combining region by passing a size argument of 0x200, and fails because the underlying mtrr code tries to carve out a 64MB region whereas my video card has only 32MB of RAM. Looks like an off-by-one (bit) error to me. So... Is this a legitimate bug sighting, or is my analysis faulty? --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
another Cyrix/mtrr problem?
Since I've seen a few other posts on the subject, I might as well poke my head out of the foxhole long enough to get shot at :-). System is a Tyan S1590S motherboard (Apollo MVP3 chipset) with Cyrix MII 300 processor, NVIDIA GeForce2 MX AGP video card, 2.4.2 kernel, XFree86-4.0.2, and the NVIDIA 0.9-6 driver. Everything worked great with the 2.4.1 kernel, XFree86-4.0.1, and the NVIDIA 0.9-5 driver (patched to compile with 2.4.X kernels). With the current setup, the NVIDIA driver fails to set up a desired write-combining memory range and disables AGP support. If I try to force the issue by configuring the NVIDIA driver to use the kernel's AGPGART support, the console switches to graphics mode and then becomes completely unresponsive to input other than tracking mouse cursor movement. The only safe way I've found to restore console functionality is to login remotely and reboot the machine: killing the X server and associated apps won't do the trick. If anyone is interested in working this issue, I can/will forward a copy of a representative /var/log/XFree86.0.log file showing what happens for the case of using the NVIDIA driver's internal AGP support. Within the log file are the following two lines that pretty much sum it up: (WW) NVIDIA(0): Failed to set up write-combining range (0xd800,0x200) (II) NVIDIA(0): AGP is disabled Jeff Hartmann (AGPGART support) thinks this is probably a MTRR issue. I'm leaning that way, given a recent posting by someone else having MTRR problems with his Cyrix 6x86. Anyone that can help troubleshoot this and/or provide a fix would be greatly appreciated. Thanks in advance! Sincerely, --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
another Cyrix/mtrr problem?
Since I've seen a few other posts on the subject, I might as well poke my head out of the foxhole long enough to get shot at :-). System is a Tyan S1590S motherboard (Apollo MVP3 chipset) with Cyrix MII 300 processor, NVIDIA GeForce2 MX AGP video card, 2.4.2 kernel, XFree86-4.0.2, and the NVIDIA 0.9-6 driver. Everything worked great with the 2.4.1 kernel, XFree86-4.0.1, and the NVIDIA 0.9-5 driver (patched to compile with 2.4.X kernels). With the current setup, the NVIDIA driver fails to set up a desired write-combining memory range and disables AGP support. If I try to force the issue by configuring the NVIDIA driver to use the kernel's AGPGART support, the console switches to graphics mode and then becomes completely unresponsive to input other than tracking mouse cursor movement. The only safe way I've found to restore console functionality is to login remotely and reboot the machine: killing the X server and associated apps won't do the trick. If anyone is interested in working this issue, I can/will forward a copy of a representative /var/log/XFree86.0.log file showing what happens for the case of using the NVIDIA driver's internal AGP support. Within the log file are the following two lines that pretty much sum it up: (WW) NVIDIA(0): Failed to set up write-combining range (0xd800,0x200) (II) NVIDIA(0): AGP is disabled Jeff Hartmann (AGPGART support) thinks this is probably a MTRR issue. I'm leaning that way, given a recent posting by someone else having MTRR problems with his Cyrix 6x86. Anyone that can help troubleshoot this and/or provide a fix would be greatly appreciated. Thanks in advance! Sincerely, --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: another Cyrix/mtrr problem?
[EMAIL PROTECTED] wrote: Normally the answer would be "Closed driver, complain to nVidia", but just in case.. Glad you were open-minded enough to consider that it *might* be "our" code. Can you verify that.. a. You have MTRR support compiled into the kernel. yes b. You have a /proc/mtrr file yes c. You can add/delete ranges using /proc/mtrr (See Documentation/mtrr.txt for info on how to do this) yes, BUT... The "Documentation/mtrr.txt" file says "... 4 megabytes, which is 0x40 bytes (in hexadecimal)." The math is correct: 1MB == 2**20 == 0x10 the last time I checked. Unfortunately, when I execute echo "base=0xd800 size=0x10 type=write-combining" | /proc/mtrr I get a 2MB region instead of the 1MB region I expected... reg00: base=0xd800 (3456MB), size= 2MB: write-combining, count=1 reg01: base=0x000c ( 0MB), size= 512KB: uncachable, count=1 reg07: base=0x ( 0MB), size= 256MB: write-through, count=1 Similarly, the NVIDIA driver attempts to create a 32MB write-combining region by passing a size argument of 0x200, and fails because the underlying mtrr code tries to carve out a 64MB region whereas my video card has only 32MB of RAM. Looks like an off-by-one (bit) error to me. So... Is this a legitimate bug sighting, or is my analysis faulty? --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ATAPI CD burner with cdrecord > 1.6.1
Kernel version is 2.4.1. For versions of cdrecord later than 1.6.1 (1.8.1 through the latest 1.10 alpha verified), attempting to burn a CD results in a SCSI error of some kind. Here's some representative output from a "dummy" burn session with cdrecord-1.9: Calling: /usr/local/lib/xcdroast-0.98/bin/cdrecord dev=0,1,0 fs=4096k -v -useinfo speed=4 -dao -dummy -eject -pad -data "/u3/superrescue/superrescue-1.2.3.raw" ... pregap1: -1 Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '0,1,0' scsibus: 0 target: 1 lun: 0 Linux sg driver version: 3.1.17 Using libscg version 'schily-0.1' atapi: 1 Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'HP ' Identifikation : 'CD-Writer+ 7200 ' Revision : '3.01' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Drive buf size : 786432 = 768 KB FIFO size : 4194304 = 4096 KB Track 01: data 498 MB padsize: 30 KB Total size: 572 MB (56:41.28) = 255096 sectors Lout start: 572 MB (56:43/21) = 255096 sectors Current Secsize: 2048 ATIP start of lead in: -11754 (97:25/21) ATIP start of lead out: 335100 (74:30/00) Disk type:Long strategy type (Cyanine, AZO or similar) Manuf. index: 8 Manufacturer: Hitachi Maxell, Ltd. Blocks total: 335100 Blocks current: 335100 Blocks remaining: 80004 RBlocks total: 346013 RBlocks current: 346013 RBlocks remaining: 90917 Starting to write CD/DVD at speed 2 in dummy mode for single session. Waiting for reader process to fill input buffer ... input buffer ready. cdrecord: Input/output error. mode select g1: scsi sendcmd: retryable error CDB: 55 10 00 00 00 00 00 00 3C 00 status: 0x0 (GOOD STATUS) cmd finished after 0.023s timeout 200s cdrecord: Warning: using default CD write parameter data. cdrecord: Cannot open new session. Mode Select Data 00 10 00 00 05 32 12 00 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cdrecord: fifo had 64 puts and 0 gets. As I recall, things work just fine with a real SCSI CD burner, so I think this behavior is limited to the ide-scsi flavor of things. If anyone has a clue as to what's really happening here, a fix or workaround would be appreciated. In the meantime, I'll continue to use the older software (xcdroast-0.96e with cdrecord-1.6.1). Thanks! -- Bob Tracy [EMAIL PROTECTED] - 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/
ATAPI CD burner with cdrecord 1.6.1
Kernel version is 2.4.1. For versions of cdrecord later than 1.6.1 (1.8.1 through the latest 1.10 alpha verified), attempting to burn a CD results in a SCSI error of some kind. Here's some representative output from a "dummy" burn session with cdrecord-1.9: Calling: /usr/local/lib/xcdroast-0.98/bin/cdrecord dev=0,1,0 fs=4096k -v -useinfo speed=4 -dao -dummy -eject -pad -data "/u3/superrescue/superrescue-1.2.3.raw" ... pregap1: -1 Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling TOC Type: 1 = CD-ROM scsidev: '0,1,0' scsibus: 0 target: 1 lun: 0 Linux sg driver version: 3.1.17 Using libscg version 'schily-0.1' atapi: 1 Device type: Removable CD-ROM Version: 0 Response Format: 1 Vendor_info: 'HP ' Identifikation : 'CD-Writer+ 7200 ' Revision : '3.01' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : SWABAUDIO Drive buf size : 786432 = 768 KB FIFO size : 4194304 = 4096 KB Track 01: data 498 MB padsize: 30 KB Total size: 572 MB (56:41.28) = 255096 sectors Lout start: 572 MB (56:43/21) = 255096 sectors Current Secsize: 2048 ATIP start of lead in: -11754 (97:25/21) ATIP start of lead out: 335100 (74:30/00) Disk type:Long strategy type (Cyanine, AZO or similar) Manuf. index: 8 Manufacturer: Hitachi Maxell, Ltd. Blocks total: 335100 Blocks current: 335100 Blocks remaining: 80004 RBlocks total: 346013 RBlocks current: 346013 RBlocks remaining: 90917 Starting to write CD/DVD at speed 2 in dummy mode for single session. Waiting for reader process to fill input buffer ... input buffer ready. cdrecord: Input/output error. mode select g1: scsi sendcmd: retryable error CDB: 55 10 00 00 00 00 00 00 3C 00 status: 0x0 (GOOD STATUS) cmd finished after 0.023s timeout 200s cdrecord: Warning: using default CD write parameter data. cdrecord: Cannot open new session. Mode Select Data 00 10 00 00 05 32 12 00 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cdrecord: fifo had 64 puts and 0 gets. As I recall, things work just fine with a real SCSI CD burner, so I think this behavior is limited to the ide-scsi flavor of things. If anyone has a clue as to what's really happening here, a fix or workaround would be appreciated. In the meantime, I'll continue to use the older software (xcdroast-0.96e with cdrecord-1.6.1). Thanks! -- Bob Tracy [EMAIL PROTECTED] - 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: AGPGART problems with VIA KX133 chipsets under 2.2.18/2.4.0
Congratulations to all involved in fixing the subject problem. With the 2.4.1 kernel, I can now actually use agpgart with my GeForce2 MX on a Tyan S1590S motherboard. Just thought someone might appreciate another data point, because prior to 2.4.1 I had to leave out agpgart support :-(. --Bob [EMAIL PROTECTED] - 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: AGPGART problems with VIA KX133 chipsets under 2.2.18/2.4.0
Congratulations to all involved in fixing the subject problem. With the 2.4.1 kernel, I can now actually use agpgart with my GeForce2 MX on a Tyan S1590S motherboard. Just thought someone might appreciate another data point, because prior to 2.4.1 I had to leave out agpgart support :-(. --Bob [EMAIL PROTECTED] - 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/
followup: depmod -a and 2.4.0
Dooh! Please ignore earlier bogus report of module loading "trouble". This was my bad: an old init script was running "modprobe -a". Sigh... -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
depmod -a and 2.4.0
Maybe I missed the discussion, but why might "depmod -a" result in every module getting installed? This didn't happen under any of the 2.4.0-testX releases that I recall, and I ran every one of those and the prerelease without this "trouble". Gotta say, the screen output from running "lsmod" with everything installed is pretty darned impressive :-). Another oddity that someone else already reported: the ipv6 module shows a reference count of -1. Yes, I'm running modutils-2.4.1, and I get the same results with modutils-2.3.15. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
depmod -a and 2.4.0
Maybe I missed the discussion, but why might "depmod -a" result in every module getting installed? This didn't happen under any of the 2.4.0-testX releases that I recall, and I ran every one of those and the prerelease without this "trouble". Gotta say, the screen output from running "lsmod" with everything installed is pretty darned impressive :-). Another oddity that someone else already reported: the ipv6 module shows a reference count of -1. Yes, I'm running modutils-2.4.1, and I get the same results with modutils-2.3.15. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
followup: depmod -a and 2.4.0
Dooh! Please ignore earlier bogus report of module loading "trouble". This was my bad: an old init script was running "modprobe -a". Sigh... -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
Ion Badulescu wrote: > On Thu, 14 Dec 2000 07:15:04 -0500, Mohammad A. Haque <[EMAIL PROTECTED]> wrote: > > Were you connected to a network or receiving/sending anything? > > ip_defrag is broken -- there is an obvious NULL pointer dereference > in it, introduced in test12. It doesn't hit normally, because of > path MTU discovery, but using NFS causes instant death. ...and then I wrote: > This is consistent with the lockup I reported several hours ago. > In the case of my "unstable" 2.4.0-test12 machine where "startx" > worked fine for "root" but not for a normal user, the "root" > account is local. The normal user account home directories are > NFS mounted :-(. I tried the submitted patch for ip_fragment.c, and there's still no joy on that one unstable machine in my sample set. At this point, I should probably go back through all the pre-12 patches and see if the problem scope can be narrowed a bit. -- Bob Tracy [EMAIL PROTECTED] - 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: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
Ion Badulescu wrote: > On Thu, 14 Dec 2000 07:15:04 -0500, Mohammad A. Haque <[EMAIL PROTECTED]> wrote: > > Were you connected to a network or receiving/sending anything? > > ip_defrag is broken -- there is an obvious NULL pointer dereference > in it, introduced in test12. It doesn't hit normally, because of > path MTU discovery, but using NFS causes instant death. This is consistent with the lockup I reported several hours ago. In the case of my "unstable" 2.4.0-test12 machine where "startx" worked fine for "root" but not for a normal user, the "root" account is local. The normal user account home directories are NFS mounted :-(. Good spot! I've done a little mucking around with the networking code, i.e., no promises, but maybe I can come up with a fix. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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: test12 lockups -- need feedback
Mohammad A. Haque wrote: > Were you connected to a network or receiving/sending anything? > > dep wrote: > > > > okay. got it here this morning, too. solid lock -- no dumping out of > > x, no changing terminals, no mouse, no keyboard. > > > > k6-2-550 @ 500; 256mb memory, fic 503a mb with via chipset. This one is going to be fun to track down. So far, with a personal sample size of three machines, 2.4.0-test12 is stable on two, locks up in a predictable and repeatable manner on one. First, the stable machines: (1) P150 MMX Toshiba Tecra 730XCDT notebook, egcs-2.91.66, openwin with XFree86 3.3.6. (2) Cyrix 6x86 MII 233, egcs-2.91.66, AfterStep with XFree86 4.0.1, NVIDIA-0.9-5 video driver. The unstable machine: Gateway PII 333, egcs-2.91.66, AfterStep with XFree86 3.3.6. Running "startx" as "root" --> ok: no problem. Running "startx" as normal user --> I get as far as the grey moire pattern with the black "X" cursor in the center of the screen, and the machine locks up solid. Cannot switch consoles, machine doesn't respond to pings (much less remote access attempts), no disk activity, no "oops" messages in any of the logfiles. Absolutely repeatable. Machine works fine with earlier kernels. Does anyone have a feeling one way or the other as far as this being related to the CPU type? I can try building a pre-PII CPU kernel on the unstable machine and see if that makes any difference. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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: test12 lockups -- need feedback
Mohammad A. Haque wrote: Were you connected to a network or receiving/sending anything? dep wrote: okay. got it here this morning, too. solid lock -- no dumping out of x, no changing terminals, no mouse, no keyboard. k6-2-550 @ 500; 256mb memory, fic 503a mb with via chipset. This one is going to be fun to track down. So far, with a personal sample size of three machines, 2.4.0-test12 is stable on two, locks up in a predictable and repeatable manner on one. First, the stable machines: (1) P150 MMX Toshiba Tecra 730XCDT notebook, egcs-2.91.66, openwin with XFree86 3.3.6. (2) Cyrix 6x86 MII 233, egcs-2.91.66, AfterStep with XFree86 4.0.1, NVIDIA-0.9-5 video driver. The unstable machine: Gateway PII 333, egcs-2.91.66, AfterStep with XFree86 3.3.6. Running "startx" as "root" -- ok: no problem. Running "startx" as normal user -- I get as far as the grey moire pattern with the black "X" cursor in the center of the screen, and the machine locks up solid. Cannot switch consoles, machine doesn't respond to pings (much less remote access attempts), no disk activity, no "oops" messages in any of the logfiles. Absolutely repeatable. Machine works fine with earlier kernels. Does anyone have a feeling one way or the other as far as this being related to the CPU type? I can try building a pre-PII CPU kernel on the unstable machine and see if that makes any difference. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
Ion Badulescu wrote: On Thu, 14 Dec 2000 07:15:04 -0500, Mohammad A. Haque [EMAIL PROTECTED] wrote: Were you connected to a network or receiving/sending anything? ip_defrag is broken -- there is an obvious NULL pointer dereference in it, introduced in test12. It doesn't hit normally, because of path MTU discovery, but using NFS causes instant death. This is consistent with the lockup I reported several hours ago. In the case of my "unstable" 2.4.0-test12 machine where "startx" worked fine for "root" but not for a normal user, the "root" account is local. The normal user account home directories are NFS mounted :-(. Good spot! I've done a little mucking around with the networking code, i.e., no promises, but maybe I can come up with a fix. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
Ion Badulescu wrote: On Thu, 14 Dec 2000 07:15:04 -0500, Mohammad A. Haque [EMAIL PROTECTED] wrote: Were you connected to a network or receiving/sending anything? ip_defrag is broken -- there is an obvious NULL pointer dereference in it, introduced in test12. It doesn't hit normally, because of path MTU discovery, but using NFS causes instant death. ...and then I wrote: This is consistent with the lockup I reported several hours ago. In the case of my "unstable" 2.4.0-test12 machine where "startx" worked fine for "root" but not for a normal user, the "root" account is local. The normal user account home directories are NFS mounted :-(. I tried the submitted patch for ip_fragment.c, and there's still no joy on that one unstable machine in my sample set. At this point, I should probably go back through all the pre-12 patches and see if the problem scope can be narrowed a bit. -- Bob Tracy [EMAIL PROTECTED] - 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/
followup: 2.4.0-test12 unresolved SCSI symbols
The quick (not necessarily correct) fix is to back out that portion of the linux/drivers/scsi/Makefile patch that moves "scsi_syms.o" from line 33 to line 126. "It works for me." (tm) -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
2.4.0-test12 unresolved SCSI symbols
Someone else mentioned the problem in a different context, so this report isn't exactly new... LOTS of unresolved symbols in several SCSI modules. Here's the list for "st.o": scsi_unregister_module scsi_block_when_processing_errors scsi_release_request scsi_do_req scsi_allocate_request print_req_sense scsi_register_module scsi_ioctl Other modules I'm personally having problems with are "sg.o" and "sr_mod.o". I'll have a look and see if there's a quick fix if someone doesn't beat me to the punch. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
2.4.0-test12 unresolved SCSI symbols
Someone else mentioned the problem in a different context, so this report isn't exactly new... LOTS of unresolved symbols in several SCSI modules. Here's the list for "st.o": scsi_unregister_module scsi_block_when_processing_errors scsi_release_request scsi_do_req scsi_allocate_request print_req_sense scsi_register_module scsi_ioctl Other modules I'm personally having problems with are "sg.o" and "sr_mod.o". I'll have a look and see if there's a quick fix if someone doesn't beat me to the punch. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
followup: 2.4.0-test12 unresolved SCSI symbols
The quick (not necessarily correct) fix is to back out that portion of the linux/drivers/scsi/Makefile patch that moves "scsi_syms.o" from line 33 to line 126. "It works for me." (tm) -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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: ESS device "1998"
Mo McKinlay wrote: > 00:0d.0 Multimedia audio controller: ESS Technology: Unknown device 1998 > 00:0d.1 Communication controller: ESS Technology: Unknown device 1999 > > Any hints/clues/etc welcome. Welcome to the "wonderful" world of the Maestro 3i. You'll find the following URL to be of interest... http://www.zabbo.net/mailman/listinfo/maestro-users Executive summary: a free driver is in its infancy, and you're more than welcome to join the debugging effort. If you *must* have sound capability, go to http://www.opensound.com and get the OSS driver: that will run you $15 for the base driver, and another $15 for the ESS Maestro add-on. It works well on my Dell Latitude CPx. You can try before you buy, and the 2.4.X kernel support is pretty good: new driver versions lag the release of a 2.4.0-testX kernel by less than a week in most cases. Good luck! -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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: ESS device 1998
Mo McKinlay wrote: 00:0d.0 Multimedia audio controller: ESS Technology: Unknown device 1998 00:0d.1 Communication controller: ESS Technology: Unknown device 1999 Any hints/clues/etc welcome. Welcome to the "wonderful" world of the Maestro 3i. You'll find the following URL to be of interest... http://www.zabbo.net/mailman/listinfo/maestro-users Executive summary: a free driver is in its infancy, and you're more than welcome to join the debugging effort. If you *must* have sound capability, go to http://www.opensound.com and get the OSS driver: that will run you $15 for the base driver, and another $15 for the ESS Maestro add-on. It works well on my Dell Latitude CPx. You can try before you buy, and the 2.4.X kernel support is pretty good: new driver versions lag the release of a 2.4.0-testX kernel by less than a week in most cases. Good luck! -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
Adaptec 2930U2 followup
Thought it might be worth a followup report in case anyone was interested. All the problems I was seeing with my 2930U2 went bye-bye when I replaced my bottom-feeder M537 VXpro motherboard with a Tyan S1590S. Current setup is Linux 2.4.0-test7 with the aic7xxx driver compiled in. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
Adaptec 2930U2 followup
Thought it might be worth a followup report in case anyone was interested. All the problems I was seeing with my 2930U2 went bye-bye when I replaced my bottom-feeder M537 VXpro motherboard with a Tyan S1590S. Current setup is Linux 2.4.0-test7 with the aic7xxx driver compiled in. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
www.crucial.com won't talk to 2.4.0-test7 system
I *thought* I wanted to buy some memory from Crucial :-). Can't get there from here with my 2.4.0-test7 machine, but Win95 seems to be ok, and 2.4.0-test5 worked ok from a different location yesterday. Has anyone else seen this kind of thing that might shed some light on the matter? Here's what tcpdump saw: 2.4.0-test7 trial 08:16:50.800511 gherkin.sa.wlk.com.3337 > www.crucial.com.www: S 3556516453:3556516453(0) win 5840 (DF) 4500 003c 4000 4006 010f c09e fe31 89c9 f113 0d09 0050 d3fc 2265 a0c2 16d0 1a35 0204 05b4 0402 080a 01d5 d704 08:16:50.970196 www.crucial.com.www > gherkin.sa.wlk.com.3337: R 0:0(0) ack 3556516454 win 5840 (DF) 4500 003c 4000 2906 180f 89c9 f113 c09e fe31 0050 0d09 d3fc 2266 a0d4 16d0 1a22 0204 05b4 0402 080a 01d5 d704 Win95 trial 08:20:23.433484 jerkin.sa.wlk.com.4270 > www.crucial.com.www: S 3089930255:3089930255(0) win 8192 (DF) 4500 002c 2387 4000 2006 fd91 c09e fe37 89c9 f113 10ae 0050 b82c 980f 6002 2000 dd38 0204 05b4 2f6d 08:20:23.601543 www.crucial.com.www > jerkin.sa.wlk.com.4270: S 2742373527:2742373527(0) ack 3089930256 win 8760 (DF) 4500 002c 20b3 4000 7406 ac65 89c9 f113 c09e fe37 0050 10ae a375 4c97 b82c 9810 6012 2238 eae2 0204 05b4 08:20:23.602582 jerkin.sa.wlk.com.4270 > www.crucial.com.www: . ack 1 win 8760 (DF) 4500 0028 2487 4000 2006 fc95 c09e fe37 89c9 f113 10ae 0050 b82c 9810 a375 4c98 5010 2238 02a0 0377 0763 08:20:23.666221 jerkin.sa.wlk.com.4270 > www.crucial.com.www: P 1:362(361) ack 1 win 8760 (DF) 4500 0191 2587 4000 2006 fa2c c09e fe37 89c9 f113 10ae 0050 b82c 9810 a375 4c98 5018 2238 5b9f 4745 5420 2f20 4854 5450 2f31 2e30 (etc.) -- Bob Tracy[EMAIL PROTECTED] "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - 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/
