Re: [RFC] Early flush (was: spindown)
Quoting Daniel Phillips <[EMAIL PROTECTED]>: > I originally intended to implement a sliding flush delay based on disk > load. > This turned out to be a lot of work for a hard-to-discern benefit. So > the > current approach has just two delays: .1 second and whatever the bdflush > > delay is set to. If there is any non-flush disk traffic the longer > delay is > used. This is crude but effective... I think. I hope that somebody > will run > this through some benchmarks to see if I lost any performance. > According to > my calculations, I did not. I tested this mainly in UML, and also ran > it > briefly on my laptop. The interactive feel of the change is immediately > > obvious, and for me at least, a big improvement. Well, since a lot of this discussion seemed to spin off from my original posting last week about my particular issue with disk flushing I decided to try your patch with my simple test/problem that I experience on my laptop. One note, I ran your patch against 2.4.6-pre3 as that is what currently performs the best on my laptop. It seems to apply cleanly and compiled without problems. I used this kernel on my laptop kernel on my laptop all day for my normal workload which consist ofa Gnome 1.4 desktop, several Mozilla instances, several ssh sessions with remote X programs displayed, StarOffice, VMware (running Windows 2000 Pro in 128MB). I also preformed several compiles throughout the day. Overall the machine feels slightly more sluggish I think due to the following two things: 1. When running a compile, or anything else that produces lots of small disk writes, you tend to get lots of little pauses for all the little writes to disk. These seem to be unnoticable without the patch. 2. Loading programs when writing activity is occuring (even light activity like during the compile) is noticable slower, actually any reading from disk is. I also ran my simple ftp test that produced the symptom I reported earlier. I transferred a 750MB file via FTP, and with your patch sure enough disk writing started almost immediately, but it still didn't seem to write enough data to disk to keep up with the transfer so at approximately the 200MB mark the old behavior still kicked in as it went into full flush mode, during the time network activity halted, just like before. The big difference with the patch and without is that the patched kernel never seems to balance out, without the patch once the initial burst is done you get a nice stream of data from the network to disk with the disk staying moderately active. With the patch the disk varies from barely active moderate to heavy and back, during the heavy the network transfer always pauses (although very briefly). Just my observations, you asked for comments. Later, Tom - 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: [RFC] Early flush (was: spindown)
Quoting Daniel Phillips [EMAIL PROTECTED]: I originally intended to implement a sliding flush delay based on disk load. This turned out to be a lot of work for a hard-to-discern benefit. So the current approach has just two delays: .1 second and whatever the bdflush delay is set to. If there is any non-flush disk traffic the longer delay is used. This is crude but effective... I think. I hope that somebody will run this through some benchmarks to see if I lost any performance. According to my calculations, I did not. I tested this mainly in UML, and also ran it briefly on my laptop. The interactive feel of the change is immediately obvious, and for me at least, a big improvement. Well, since a lot of this discussion seemed to spin off from my original posting last week about my particular issue with disk flushing I decided to try your patch with my simple test/problem that I experience on my laptop. One note, I ran your patch against 2.4.6-pre3 as that is what currently performs the best on my laptop. It seems to apply cleanly and compiled without problems. I used this kernel on my laptop kernel on my laptop all day for my normal workload which consist ofa Gnome 1.4 desktop, several Mozilla instances, several ssh sessions with remote X programs displayed, StarOffice, VMware (running Windows 2000 Pro in 128MB). I also preformed several compiles throughout the day. Overall the machine feels slightly more sluggish I think due to the following two things: 1. When running a compile, or anything else that produces lots of small disk writes, you tend to get lots of little pauses for all the little writes to disk. These seem to be unnoticable without the patch. 2. Loading programs when writing activity is occuring (even light activity like during the compile) is noticable slower, actually any reading from disk is. I also ran my simple ftp test that produced the symptom I reported earlier. I transferred a 750MB file via FTP, and with your patch sure enough disk writing started almost immediately, but it still didn't seem to write enough data to disk to keep up with the transfer so at approximately the 200MB mark the old behavior still kicked in as it went into full flush mode, during the time network activity halted, just like before. The big difference with the patch and without is that the patched kernel never seems to balance out, without the patch once the initial burst is done you get a nice stream of data from the network to disk with the disk staying moderately active. With the patch the disk varies from barely active moderate to heavy and back, during the heavy the network transfer always pauses (although very briefly). Just my observations, you asked for comments. Later, Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre2, pre3 VM Behavior
Quoting Mark Hahn <[EMAIL PROTECTED]>: > > 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb > Ethernet, > > close to wire speed). At this point Linux has yet to write the first > byte to > > disk. OK, this might be an exaggerated, but very little disk activity > has > > occured on my laptop. > > right. it could be that the VM scheduling stuff needs some way to > tell > whether the IO system is idle. that is, if there's no contention for > the disk, it might as well be less lazy about writebacks. That's exactly the way it seems. > > 2. Suddenly it's as if Linux says, "Damn, I've got a lot of data to > flush, > > maybe I should do that" then the hard drive light comes on solid for > several > > seconds. During this time the ftp transfer drops to about 1/5 of the > original > > speed. > > such a dramatic change could be the result of IDE misconfiguration; > is it safe to assume you have DMA or UDMA enabled? Yes, UDMA/33 is enabled and working on the drive (using hdparm -d 0 makes the problem way worse and my drive performs about 1/4 the speed). > > This was much less noticeable on a server with a much faster SCSI hard > disk > > subsystem as it took significantly less time to flush the information > to the > > is the SCSI disk actually faster (unlikley, for modern disks), or > is the SCSI controller simply busmastering, like DMA/UDMA IDE, > but wholly unlike PIO-mode IDE? First, lets be fair, we're comparing a UDMA/33 IDE drive in a 1 year old laptop (IBM Travelstar, if your interested) to a true SCSI Disk Subsystem with mirrored/striped Ultra160 SCSI disk connected via 64bit PCI/66Mhz bus, so yes, the SCSI subsystem is MUCH faster. Specific numbers: Laptop with TravelStar IDE HD Max sustained read: 16.5MB/s Server with Ultra160 SCSI disk array Max sustained read: >100MB/s That's a big difference. The Travelstar is probably only 5400RPM and is optimized for power savings, not speed, the SCSI subsystem has multiple 15000RPM in a striped/mirrored configuration for speed. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre2, pre3 VM Behavior
Quoting Rik van Riel <[EMAIL PROTECTED]>: > After the initial burst, the system should stabilise, > starting the writeout of pages before we run low on > memory. How to handle the initial burst is something > I haven't figured out yet ... ;) Well, at least I know that this is expected with the VM, although I do still think this is bad behavior. If my disk is idle why would I wait until I have greater than 100MB of data to write before I finally start actually moving some data to disk? > This is due to this smarter handling of the flushing of > dirty pages and due to a more subtle bug where the system > ended up doing synchronous IO on too many pages, whereas > now it only does synchronous IO on _1_ page per scan ;) And this is definately a noticeable fix, thanks for your continued work. I know it's hard to get everything balanced out right, and I only wrote this email to describe some behavior I was seeing and make sure it was expected in the current VM. You've let me know that it is, and it's really minor compared to problems some of the earlier kernels had. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.6-pre2, pre3 VM Behavior
Hi All, I have been using the 2.4.x kernels since the 2.4.0-test days on my Dell 5000e laptop with 320MB of RAM and have experienced first hand many of the problems other users have reported with the VM system in 2.4. Most of these problems have been only minor anoyances and I have continued testing kernels as the 2.4 series has continued, mostly without noticing much change. With 2.4.6-pre2, and -pre3 I can say that I have seen a marked improvement on my machine, especially in interactive response, for my day to day workstation uses. However, I do have one observation that seems rather strange, or at least wrong. I, on occasion, have the need to transfer relatively large files (750MB-1GB) from our larger Linux servers to my machine. I usually use ftp to transfer these files and this is where I notice the following: 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb Ethernet, close to wire speed). At this point Linux has yet to write the first byte to disk. OK, this might be an exaggerated, but very little disk activity has occured on my laptop. 2. Suddenly it's as if Linux says, "Damn, I've got a lot of data to flush, maybe I should do that" then the hard drive light comes on solid for several seconds. During this time the ftp transfer drops to about 1/5 of the original speed. 3. After the initial burst of data is written things seem much more reasonable, and data streams to the disk almost continually while the rest of the transfer completes at near full speed again. Basically, it seems the kernel buffers all of the incoming file up to nearly available memory before it begins to panic and starts flushing the file to disk. It seems it should start to lazy write somewhat ealier. Perhaps some of this is tuneable from userland and I just don't know how. This was much less noticeable on a server with a much faster SCSI hard disk subsystem as it took significantly less time to flush the information to the disk once it finally starterd, but laptop hard drives are traditionally poor performers and at 15MB/s it take 10-15 seconds before things stable out, just from transferring a file. Anyway, things are still much better, with older kernels things would almost seem locked up during those 10-15 seconds but now my apps stay fairly responsive (I can still type in AbiWord, browse in Mozilla, etc). Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.6-pre2, pre3 VM Behavior
Hi All, I have been using the 2.4.x kernels since the 2.4.0-test days on my Dell 5000e laptop with 320MB of RAM and have experienced first hand many of the problems other users have reported with the VM system in 2.4. Most of these problems have been only minor anoyances and I have continued testing kernels as the 2.4 series has continued, mostly without noticing much change. With 2.4.6-pre2, and -pre3 I can say that I have seen a marked improvement on my machine, especially in interactive response, for my day to day workstation uses. However, I do have one observation that seems rather strange, or at least wrong. I, on occasion, have the need to transfer relatively large files (750MB-1GB) from our larger Linux servers to my machine. I usually use ftp to transfer these files and this is where I notice the following: 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb Ethernet, close to wire speed). At this point Linux has yet to write the first byte to disk. OK, this might be an exaggerated, but very little disk activity has occured on my laptop. 2. Suddenly it's as if Linux says, Damn, I've got a lot of data to flush, maybe I should do that then the hard drive light comes on solid for several seconds. During this time the ftp transfer drops to about 1/5 of the original speed. 3. After the initial burst of data is written things seem much more reasonable, and data streams to the disk almost continually while the rest of the transfer completes at near full speed again. Basically, it seems the kernel buffers all of the incoming file up to nearly available memory before it begins to panic and starts flushing the file to disk. It seems it should start to lazy write somewhat ealier. Perhaps some of this is tuneable from userland and I just don't know how. This was much less noticeable on a server with a much faster SCSI hard disk subsystem as it took significantly less time to flush the information to the disk once it finally starterd, but laptop hard drives are traditionally poor performers and at 15MB/s it take 10-15 seconds before things stable out, just from transferring a file. Anyway, things are still much better, with older kernels things would almost seem locked up during those 10-15 seconds but now my apps stay fairly responsive (I can still type in AbiWord, browse in Mozilla, etc). Later, Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre2, pre3 VM Behavior
Quoting Rik van Riel [EMAIL PROTECTED]: After the initial burst, the system should stabilise, starting the writeout of pages before we run low on memory. How to handle the initial burst is something I haven't figured out yet ... ;) Well, at least I know that this is expected with the VM, although I do still think this is bad behavior. If my disk is idle why would I wait until I have greater than 100MB of data to write before I finally start actually moving some data to disk? This is due to this smarter handling of the flushing of dirty pages and due to a more subtle bug where the system ended up doing synchronous IO on too many pages, whereas now it only does synchronous IO on _1_ page per scan ;) And this is definately a noticeable fix, thanks for your continued work. I know it's hard to get everything balanced out right, and I only wrote this email to describe some behavior I was seeing and make sure it was expected in the current VM. You've let me know that it is, and it's really minor compared to problems some of the earlier kernels had. Later, Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre2, pre3 VM Behavior
Quoting Mark Hahn [EMAIL PROTECTED]: 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb Ethernet, close to wire speed). At this point Linux has yet to write the first byte to disk. OK, this might be an exaggerated, but very little disk activity has occured on my laptop. right. it could be that the VM scheduling stuff needs some way to tell whether the IO system is idle. that is, if there's no contention for the disk, it might as well be less lazy about writebacks. That's exactly the way it seems. 2. Suddenly it's as if Linux says, Damn, I've got a lot of data to flush, maybe I should do that then the hard drive light comes on solid for several seconds. During this time the ftp transfer drops to about 1/5 of the original speed. such a dramatic change could be the result of IDE misconfiguration; is it safe to assume you have DMA or UDMA enabled? Yes, UDMA/33 is enabled and working on the drive (using hdparm -d 0 makes the problem way worse and my drive performs about 1/4 the speed). This was much less noticeable on a server with a much faster SCSI hard disk subsystem as it took significantly less time to flush the information to the is the SCSI disk actually faster (unlikley, for modern disks), or is the SCSI controller simply busmastering, like DMA/UDMA IDE, but wholly unlike PIO-mode IDE? First, lets be fair, we're comparing a UDMA/33 IDE drive in a 1 year old laptop (IBM Travelstar, if your interested) to a true SCSI Disk Subsystem with mirrored/striped Ultra160 SCSI disk connected via 64bit PCI/66Mhz bus, so yes, the SCSI subsystem is MUCH faster. Specific numbers: Laptop with TravelStar IDE HD Max sustained read: 16.5MB/s Server with Ultra160 SCSI disk array Max sustained read: 100MB/s That's a big difference. The Travelstar is probably only 5400RPM and is optimized for power savings, not speed, the SCSI subsystem has multiple 15000RPM in a striped/mirrored configuration for speed. Later, Tom - 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: xircom_cb problems
Quoting Ion Badulescu <[EMAIL PROTECTED]>: > On Fri, 8 Jun 2001, Tom Sightler wrote: > > > OK, I tried your patch, it did fix the problem where pump wouldn't > > pull an IP address, but I'm still having the problem where my ping > > times go nuts. I've attached an example, it's 100% repeatable on my > > network at work. It was so bad I couldn't get any benchmark > numbers. > > Just one more question: do you see the same bad ping times if you > completely comment out the call to set_half_duplex? No, the problem goes away if I do this, although then I hae the performance problems as before. I also noticed that even when the call to set_half_duplex is left in, the switch reports that the link is still in full duplex, 100Mb mode. I tried forcing half duplex on the switch but this didn't help. It actually looks like half duplex is not really being set correctly. I plugged in a desktop with an eepro100 based card and forced the duplex to half with the command line options and the switch properly reported a half-duplex link had been negotiated, with the xircom card the switch reports full-duplex with or without the set_half_duplex line, which certainly implies it's not really working right. Hope the helps. I won't be back at the office until Monday so that's the earliest I'll be able to test again, but I'll be glad to test any combination that I can. Later, Tom - 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: xircom_cb problems
Whoops!! Sorry, forgot the attachment. Thanks, Tom > Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving > from a 100Mbit box (tulip or starfire, doesn't seem to matter). > Transmitting is still slow for me, but that is most likely a different > problem -- and I'm looking into it. Yeah, I knew they were both slow, but at least one is acceptable, the <200KB/s is below usable when doing any network based work. > Moreover, I'm getting 9+MB/s in both directions when using the other > driver (xircom_tulip_cb), patched to do half-duplex only. So the card > can definitely transfer at network speeds. I'm not doing nearly as well with the other driver, but I don't have it patched for half-duplex only. I tried setting the remote end to force half-duplex but this didn't seem to work quite right. > Looking forward to seeing them... OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP address, but I'm still having the problem where my ping times go nuts. I've attached an example, it's 100% repeatable on my network at work. It was so bad I couldn't get any benchmark numbers. Later, Tom [root@iso-2146-l1 ttsig]# ping 10.10.4.254 PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=590 usec 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=2.996 sec 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=2.000 sec 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=1.000 sec 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=575 usec 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=3.000 sec 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=2.000 sec 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=1.000 sec --- 10.10.4.254 ping statistics --- 10 packets transmitted, 8 packets received, 20% packet loss round-trip min/avg/max/mdev = 0.575/1500.228/3000.710/1117.327 ms [root@iso-2146-l1 ttsig]# rmmod xircom_cb rmmod: module xircom_cb is not loaded [root@iso-2146-l1 ttsig]# lsmod Module Size Used by appletalk 18352 0 (autoclean) serial 44864 0 vmnet 16448 1 vmmon 18352 0 r128 145392 1 agpgart13568 3 (autoclean) usb-uhci 20864 0 (unused) usbcore48176 1 [usb-uhci] [root@iso-2146-l1 ttsig]# ping 10.10.4.254 PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=955 usec 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=492 usec 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=453 usec 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=465 usec 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=451 usec 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=455 usec 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=450 usec 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=453 usec --- 10.10.4.254 ping statistics --- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.450/0.521/0.955/0.166 ms
Re: xircom_cb problems
> Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving > from a 100Mbit box (tulip or starfire, doesn't seem to matter). > Transmitting is still slow for me, but that is most likely a different > problem -- and I'm looking into it. Yeah, I knew they were both slow, but at least one is acceptable, the <200KB/s is below usable when doing any network based work. > Moreover, I'm getting 9+MB/s in both directions when using the other > driver (xircom_tulip_cb), patched to do half-duplex only. So the card > can definitely transfer at network speeds. I'm not doing nearly as well with the other driver, but I don't have it patched for half-duplex only. I tried setting the remote end to force half-duplex but this didn't seem to work quite right. > Looking forward to seeing them... OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP address, but I'm still having the problem where my ping times go nuts. I've attached an example, it's 100% repeatable on my network at work. It was so bad I couldn't get any benchmark numbers. Later, Tom - 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: xircom_cb problems
Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving from a 100Mbit box (tulip or starfire, doesn't seem to matter). Transmitting is still slow for me, but that is most likely a different problem -- and I'm looking into it. Yeah, I knew they were both slow, but at least one is acceptable, the 200KB/s is below usable when doing any network based work. Moreover, I'm getting 9+MB/s in both directions when using the other driver (xircom_tulip_cb), patched to do half-duplex only. So the card can definitely transfer at network speeds. I'm not doing nearly as well with the other driver, but I don't have it patched for half-duplex only. I tried setting the remote end to force half-duplex but this didn't seem to work quite right. Looking forward to seeing them... OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP address, but I'm still having the problem where my ping times go nuts. I've attached an example, it's 100% repeatable on my network at work. It was so bad I couldn't get any benchmark numbers. Later, Tom - 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: xircom_cb problems
Whoops!! Sorry, forgot the attachment. Thanks, Tom Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving from a 100Mbit box (tulip or starfire, doesn't seem to matter). Transmitting is still slow for me, but that is most likely a different problem -- and I'm looking into it. Yeah, I knew they were both slow, but at least one is acceptable, the 200KB/s is below usable when doing any network based work. Moreover, I'm getting 9+MB/s in both directions when using the other driver (xircom_tulip_cb), patched to do half-duplex only. So the card can definitely transfer at network speeds. I'm not doing nearly as well with the other driver, but I don't have it patched for half-duplex only. I tried setting the remote end to force half-duplex but this didn't seem to work quite right. Looking forward to seeing them... OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP address, but I'm still having the problem where my ping times go nuts. I've attached an example, it's 100% repeatable on my network at work. It was so bad I couldn't get any benchmark numbers. Later, Tom [root@iso-2146-l1 ttsig]# ping 10.10.4.254 PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=590 usec 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=2.996 sec 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=2.000 sec 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=1.000 sec 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=575 usec 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=3.000 sec 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=2.000 sec 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=1.000 sec --- 10.10.4.254 ping statistics --- 10 packets transmitted, 8 packets received, 20% packet loss round-trip min/avg/max/mdev = 0.575/1500.228/3000.710/1117.327 ms [root@iso-2146-l1 ttsig]# rmmod xircom_cb rmmod: module xircom_cb is not loaded [root@iso-2146-l1 ttsig]# lsmod Module Size Used by appletalk 18352 0 (autoclean) serial 44864 0 vmnet 16448 1 vmmon 18352 0 r128 145392 1 agpgart13568 3 (autoclean) usb-uhci 20864 0 (unused) usbcore48176 1 [usb-uhci] [root@iso-2146-l1 ttsig]# ping 10.10.4.254 PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=955 usec 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=492 usec 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=453 usec 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=465 usec 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=451 usec 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=455 usec 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=450 usec 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=453 usec --- 10.10.4.254 ping statistics --- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.450/0.521/0.955/0.166 ms
Re: xircom_cb problems
Quoting Ion Badulescu [EMAIL PROTECTED]: On Fri, 8 Jun 2001, Tom Sightler wrote: OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP address, but I'm still having the problem where my ping times go nuts. I've attached an example, it's 100% repeatable on my network at work. It was so bad I couldn't get any benchmark numbers. Just one more question: do you see the same bad ping times if you completely comment out the call to set_half_duplex? No, the problem goes away if I do this, although then I hae the performance problems as before. I also noticed that even when the call to set_half_duplex is left in, the switch reports that the link is still in full duplex, 100Mb mode. I tried forcing half duplex on the switch but this didn't help. It actually looks like half duplex is not really being set correctly. I plugged in a desktop with an eepro100 based card and forced the duplex to half with the command line options and the switch properly reported a half-duplex link had been negotiated, with the xircom card the switch reports full-duplex with or without the set_half_duplex line, which certainly implies it's not really working right. Hope the helps. I won't be back at the office until Monday so that's the earliest I'll be able to test again, but I'll be glad to test any combination that I can. Later, Tom - 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: xircom_cb problems
Quoting Ion Badulescu <[EMAIL PROTECTED]>: > > 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep > > Can you run some performance testing with this driver, though? The > speed > of ftp transfers in both directions would be a good measure. The > reason > I'm asking is because we saw really poor performance on 100Mb > full-duplex, > something like 200-300KB/s when receiving. OK, I did some simple FTP benchmarking, transferring a 100MB to and from my laptop connected to a Cisco Catalyst 6509. The other systems were a PIII 700Mhz UP with eepro100 NIC running 2.4.2-ac11, and a PIII 1Ghz SMP (2 proc) with Alteon Gigabit NIC running 2.2.19. Transferring files between the eepro100 machine running 2.4.2-ac11 and my laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the file. Transfering files between the Alteon Gigabit machine running 2.2.19 and my laptop resulted in the dismal numbers of 249KB/s sending and 185KB/s recieving, close to the numbers you quoted above, but actually slightly worse. I'm not sure what would explain the 2.2.19 1GB conencted box being 10x slower than the 2.4.2-ac11 100MB machine. Transferring the same file between the two other boxes gives 9.81MB/s which is near the theoretical maximum for 100Mb. > > 2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit" > over and > > over when trying to pull an IP address via dhcp using pump or dhcpcd. > > > pump likes to bring the interface up and down and up and down, so those > > messages are not necessarily unusual. Yea, I've actually complained of this before, the interface up/down things that pump does makes it very tough to use on a large network with full spanning tree as pump brings the interface down and up again right about the time spanning tree puts the port into forwarding mode. I can get around this by setting Cisco's portfast feature, but doing that on all ports somewhat defeats the purpose of spanning tree and I move my laptop a lot. > Hmm. I have an idea though. In set_half_duplex, we shouldn't touch the > MII > if the new autoneg value is the same as the old one. It should certainly > > help with things like pump. Arjan, what do you think? > > > Interestingly manually setting an IP address seems to work fine with > > this driver. > > That's very good to know. So most likely the repeated up/down that > pump's > doing is upsetting the card. Commenting out the set_half_duplex made the driver in 2.4.5-ac9 work with DHCP again so your probably right. I'll apply your patch with the change to MII handling and rerun some simple file transfers and report the results soon. Thanks, Tom - 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: xircom_cb problems
Quoting Ion Badulescu [EMAIL PROTECTED]: 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep Can you run some performance testing with this driver, though? The speed of ftp transfers in both directions would be a good measure. The reason I'm asking is because we saw really poor performance on 100Mb full-duplex, something like 200-300KB/s when receiving. OK, I did some simple FTP benchmarking, transferring a 100MB to and from my laptop connected to a Cisco Catalyst 6509. The other systems were a PIII 700Mhz UP with eepro100 NIC running 2.4.2-ac11, and a PIII 1Ghz SMP (2 proc) with Alteon Gigabit NIC running 2.2.19. Transferring files between the eepro100 machine running 2.4.2-ac11 and my laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the file. Transfering files between the Alteon Gigabit machine running 2.2.19 and my laptop resulted in the dismal numbers of 249KB/s sending and 185KB/s recieving, close to the numbers you quoted above, but actually slightly worse. I'm not sure what would explain the 2.2.19 1GB conencted box being 10x slower than the 2.4.2-ac11 100MB machine. Transferring the same file between the two other boxes gives 9.81MB/s which is near the theoretical maximum for 100Mb. 2.4.5-ac9 -- keeps logging Link is absent then Linux is 100 mbit over and over when trying to pull an IP address via dhcp using pump or dhcpcd. pump likes to bring the interface up and down and up and down, so those messages are not necessarily unusual. Yea, I've actually complained of this before, the interface up/down things that pump does makes it very tough to use on a large network with full spanning tree as pump brings the interface down and up again right about the time spanning tree puts the port into forwarding mode. I can get around this by setting Cisco's portfast feature, but doing that on all ports somewhat defeats the purpose of spanning tree and I move my laptop a lot. Hmm. I have an idea though. In set_half_duplex, we shouldn't touch the MII if the new autoneg value is the same as the old one. It should certainly help with things like pump. Arjan, what do you think? Interestingly manually setting an IP address seems to work fine with this driver. That's very good to know. So most likely the repeated up/down that pump's doing is upsetting the card. Commenting out the set_half_duplex made the driver in 2.4.5-ac9 work with DHCP again so your probably right. I'll apply your patch with the change to MII handling and rerun some simple file transfers and report the results soon. Thanks, Tom - 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/
xircom_cb problems
> The patch does only one thing: it instructs the card not to negotiate > full-duplex modes, because (for undocumented and yet unexplained > reasons) > full-duplex modes don't work well on this card. > > If you had problems before, then their cause is most likely elsewhere. > 1-second ping time is definitely wrong. Well, I compiled the driver from 2.4.4-ac11, 2.4.5-ac3, and 2.4.5-ac9 all with the exact same source from 2.4.5-ac9, and my problems are 100% repeatable on my hardware. At home where I have a 10Mb half-duplex hub connection all of the drivers work properly. At work where I have a 10/100Mb full-duplex switch connection the drivers work exactly as I described before: 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep 2.4.5-ac3 -- seems to work but pings are >1 second (yes really a full second) 2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit" over and over when trying to pull an IP address via dhcp using pump or dhcpcd. Interestingly manually setting an IP address seems to work fine with this driver. > The thing is, I don't really see any significant differences between > the > 2.4.4-ac11 driver and the 2.4.5-ac9 driver. I see lots of clean-ups, > some > power management stuff, and the half-duplex stuff. None of them should > affect the core functionality directly.. I looked at this before posting, and generally agree, but the results are 100% reproducable on my machine as listed above, so they must be having some affect. My current working system is 2.4.5-ac9 with the driver source from 2.4.4-ac11 recomiled for it and it's working great (minor resume problems aside). > Please do me a favor: comment out the call to set_half_duplex() (in > xircom_up), recompile and see if it makes a difference. I'll do this tomorrow morning when I get in and report back. Thanks for the help, I'd really like to see this card get stable as we have it in a lot of our laptops here at work. > > One other note, the version in 2.4.4-ac11 is listed as 1.33 while > the > > version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there > > significant problems with the newer version? The 1.33 sure seems to > work > > better for me. > > The CVS version is almost irrelevant, I guess Arjan simply rebuild his > repository. And you would be correct as Arjan confirmed in a follow up messages, sorry about that, it just looked strange. Thanks for the help, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
> 2.4.5-ac9 > o Fix xircom_cb problems with some cisco kit (Ion Badulescu) I'm not sure what this is supposed to fix, but it makes my Xircom RBEM56G-100 almost useless on my network at the office. Actually, I can't quite blame just this patch, it only makes the problem worse, the driver from 2.4.5-ac3 worked, but with 1 second ping times, the new driver barely works at all, it seems to think the link is not there, at least not enough to pull an IP address. The last driver that worked moderately well for me was the one from 2.4.4-ac11, it still had a few issues, mostly when resuming, but everything worked at home on my 10Mb hub, and at the office on my 10/100Mb FD Cisco 6509. I must admist that I haven't tested every version in between. One other note, the version in 2.4.4-ac11 is listed as 1.33 while the version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there significant problems with the newer version? The 1.33 sure seems to work better for me. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
2.4.5-ac9 o Fix xircom_cb problems with some cisco kit (Ion Badulescu) I'm not sure what this is supposed to fix, but it makes my Xircom RBEM56G-100 almost useless on my network at the office. Actually, I can't quite blame just this patch, it only makes the problem worse, the driver from 2.4.5-ac3 worked, but with 1 second ping times, the new driver barely works at all, it seems to think the link is not there, at least not enough to pull an IP address. The last driver that worked moderately well for me was the one from 2.4.4-ac11, it still had a few issues, mostly when resuming, but everything worked at home on my 10Mb hub, and at the office on my 10/100Mb FD Cisco 6509. I must admist that I haven't tested every version in between. One other note, the version in 2.4.4-ac11 is listed as 1.33 while the version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there significant problems with the newer version? The 1.33 sure seems to work better for me. Later, Tom - 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/
xircom_cb problems
The patch does only one thing: it instructs the card not to negotiate full-duplex modes, because (for undocumented and yet unexplained reasons) full-duplex modes don't work well on this card. If you had problems before, then their cause is most likely elsewhere. 1-second ping time is definitely wrong. Well, I compiled the driver from 2.4.4-ac11, 2.4.5-ac3, and 2.4.5-ac9 all with the exact same source from 2.4.5-ac9, and my problems are 100% repeatable on my hardware. At home where I have a 10Mb half-duplex hub connection all of the drivers work properly. At work where I have a 10/100Mb full-duplex switch connection the drivers work exactly as I described before: 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep 2.4.5-ac3 -- seems to work but pings are 1 second (yes really a full second) 2.4.5-ac9 -- keeps logging Link is absent then Linux is 100 mbit over and over when trying to pull an IP address via dhcp using pump or dhcpcd. Interestingly manually setting an IP address seems to work fine with this driver. The thing is, I don't really see any significant differences between the 2.4.4-ac11 driver and the 2.4.5-ac9 driver. I see lots of clean-ups, some power management stuff, and the half-duplex stuff. None of them should affect the core functionality directly.. I looked at this before posting, and generally agree, but the results are 100% reproducable on my machine as listed above, so they must be having some affect. My current working system is 2.4.5-ac9 with the driver source from 2.4.4-ac11 recomiled for it and it's working great (minor resume problems aside). Please do me a favor: comment out the call to set_half_duplex() (in xircom_up), recompile and see if it makes a difference. I'll do this tomorrow morning when I get in and report back. Thanks for the help, I'd really like to see this card get stable as we have it in a lot of our laptops here at work. One other note, the version in 2.4.4-ac11 is listed as 1.33 while the version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there significant problems with the newer version? The 1.33 sure seems to work better for me. The CVS version is almost irrelevant, I guess Arjan simply rebuild his repository. And you would be correct as Arjan confirmed in a follow up messages, sorry about that, it just looked strange. Thanks for the help, Tom - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make Xircom cardbus modems work
> Does the attached patch work for you? > > serial.c still has the basic problem that there is a logical disconnect > between the pci_boards list and the pci-device-id list: any device > which is not PCI_CLASS_COMMUNICATION_SERIAL or > PCI_CLASS_COMMUNICATION_MODEM will not get scanned. The solution is to > move the PCI ids into the probe list, before the class listing. Ideally > I would like to merge the Xircom cardbus fix with this fix, since they > are both modifying the pci_board list and thus conflict. > > Except for the Xircom Cardbus update (based on your patch, Bill), this > patch has been tested and is known to solve the problems reported to me > which were caused by the logical disconnect. > > (Alessandro, Tom, tytso: the attached patch is updated for the changes > in Bill's patch, so you haven't seen this version yet) > > Jeff Just wanted to report that this patch finally fixes my Xircom Cardbus adapter. Works like a charm. Thanks!! Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make Xircom cardbus modems work
Does the attached patch work for you? serial.c still has the basic problem that there is a logical disconnect between the pci_boards list and the pci-device-id list: any device which is not PCI_CLASS_COMMUNICATION_SERIAL or PCI_CLASS_COMMUNICATION_MODEM will not get scanned. The solution is to move the PCI ids into the probe list, before the class listing. Ideally I would like to merge the Xircom cardbus fix with this fix, since they are both modifying the pci_board list and thus conflict. Except for the Xircom Cardbus update (based on your patch, Bill), this patch has been tested and is known to solve the problems reported to me which were caused by the logical disconnect. (Alessandro, Tom, tytso: the attached patch is updated for the changes in Bill's patch, so you haven't seen this version yet) Jeff Just wanted to report that this patch finally fixes my Xircom Cardbus adapter. Works like a charm. Thanks!! Later, Tom - 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: Serial, 115Kbps, 2.2, 2.4
Actually, I do have a similar problem that I've been unable to track down 100%. Under 2.4.x when I run the modem on my Xircom Cardbus 10/100 Ethernet/56K Modem combo card (installed in a Dell 5000e with 650Mhz Pentium III) I get a fair number of dropped packets at 115Kbps, enough to cause problems and a significant speed decrease. Simply dropping the serial port rate to 56K seems to solve the problem. I'm actually suspicious that the hardware handshaking isn't working quite right, but I haven't take the time to look at it. I never noticed the problem under 2.2.x, but the last kernel I ran from that era was the 2.2.16 kernel included with Redhat 7. I've really not looked at it very hard, backing the speed down to 56K was a good enough solution for me for now, the Xircom has such a troublesome history that I just blamed it on that but your report makes me more curious. Later, Tom - 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: Serial, 115Kbps, 2.2, 2.4
Actually, I do have a similar problem that I've been unable to track down 100%. Under 2.4.x when I run the modem on my Xircom Cardbus 10/100 Ethernet/56K Modem combo card (installed in a Dell 5000e with 650Mhz Pentium III) I get a fair number of dropped packets at 115Kbps, enough to cause problems and a significant speed decrease. Simply dropping the serial port rate to 56K seems to solve the problem. I'm actually suspicious that the hardware handshaking isn't working quite right, but I haven't take the time to look at it. I never noticed the problem under 2.2.x, but the last kernel I ran from that era was the 2.2.16 kernel included with Redhat 7. I've really not looked at it very hard, backing the speed down to 56K was a good enough solution for me for now, the Xircom has such a troublesome history that I just blamed it on that but your report makes me more curious. Later, Tom - 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: Loopback device hangs on mount command
> [1.] Loopback device hangs on mount command. > > [2.] Mounting a loopback device hangs the process. Eg. Issuing > > losetup /dev/loop0 fsimg > mount /dev/loop0 /mnt > > will hang at the mount command. The mount process cannot be > killed, nor can the loopback device be destroyed with losetup. > > [4.] Linux mantissa 2.4.2 #15 Wed Mar 28 11:00:17 EST 2001 i686 Widely known and reported problem with 2.4 kernels before 2.4.3. Please search archives before posting such problems. Either apply Jens loop patches (available on via your ftp.kernel.org mirror), apply a recent -ac patch (which includes Jens patches), or upgrade to 2.4.3 (which also includes Jens patches). Later, Tom - 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: Loopback device hangs on mount command
[1.] Loopback device hangs on mount command. [2.] Mounting a loopback device hangs the process. Eg. Issuing losetup /dev/loop0 fsimg mount /dev/loop0 /mnt will hang at the mount command. The mount process cannot be killed, nor can the loopback device be destroyed with losetup. [4.] Linux mantissa 2.4.2 #15 Wed Mar 28 11:00:17 EST 2001 i686 Widely known and reported problem with 2.4 kernels before 2.4.3. Please search archives before posting such problems. Either apply Jens loop patches (available on via your ftp.kernel.org mirror), apply a recent -ac patch (which includes Jens patches), or upgrade to 2.4.3 (which also includes Jens patches). Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix for serial.c to work with Xircom Cardbus Ethernet+Modem
>> It seems something changed in 2.4.3-pre7 (against which I applied your >> patch) so that it doesn't make a difference. On startup I now get this, >> which I am CC:ing as per printk to [EMAIL PROTECTED] >> >> Mar 24 23:59:05 princess cardmgr[374]: initializing socket 1 >> Mar 24 23:59:05 princess kernel: got res[10c04000:10c07fff] for resource 6 of PCI device 115d:0103 >> Mar 24 23:59:05 princess cardmgr[374]: socket 1: Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem >> Mar 24 23:59:05 princess kernel: PCI: Enabling device 05:00.1 ( -> 0003) >> Mar 24 23:59:05 princess kernel: Redundant entry in serial pci_table. Please send the output of >> Mar 24 23:59:05 princess kernel: lspci -vv, this message (4445,259,4445,4481) >> Mar 24 23:59:05 princess kernel: and the manufacturer and name of serial board or modem board >> Mar 24 23:59:05 princess kernel: to [EMAIL PROTECTED] >> Mar 24 23:59:05 princess kernel: register_serial(): autoconfig failed >> >> The card is a Xircom RBEM56G-100, despite what the card advertises. >> >> (in case you wonder, cardmgr is from pcmcia_cs-3.1.25). > OK, I'll take a look at it. I made the patch against -ac21 which I think > was only synced up to 2.4.3-pre6, I should have mentioned that. Perhaps > someone added the proper Xircom stuff already or some other change made my > patch irrelavent. BTW, are you building serial.c as a module, or built in? > I have mine as a module so it doesn't load until after the card is > initialized. Just curious. I tested 2.4.3-pre7 and it still fails without my patch. With my patch I get the above message about 'Redundant entry in serial pci_table' but it still manages to setup my serial device as /dev/ttyS4 (the same patch applied to 2.4.2-ac21 sets the device to /dev/ttyS1). However it only works if I load serial.c as a module AFTER the card is inserted, if serial.c is already loaded it doesn't register correctly with a messages similar to above. Perhaps I need to check my hotplug setup. Could your try serial.c as a module and see if it works for you like that? That way I'd know I'm on the right track and haven't just found some strange way to make it work on my system alone. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix for serial.c to work with Xircom Cardbus Ethernet+Modem
It seems something changed in 2.4.3-pre7 (against which I applied your patch) so that it doesn't make a difference. On startup I now get this, which I am CC:ing as per printk to [EMAIL PROTECTED] Mar 24 23:59:05 princess cardmgr[374]: initializing socket 1 Mar 24 23:59:05 princess kernel: got res[10c04000:10c07fff] for resource 6 of PCI device 115d:0103 Mar 24 23:59:05 princess cardmgr[374]: socket 1: Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem Mar 24 23:59:05 princess kernel: PCI: Enabling device 05:00.1 ( - 0003) Mar 24 23:59:05 princess kernel: Redundant entry in serial pci_table. Please send the output of Mar 24 23:59:05 princess kernel: lspci -vv, this message (4445,259,4445,4481) Mar 24 23:59:05 princess kernel: and the manufacturer and name of serial board or modem board Mar 24 23:59:05 princess kernel: to [EMAIL PROTECTED] Mar 24 23:59:05 princess kernel: register_serial(): autoconfig failed The card is a Xircom RBEM56G-100, despite what the card advertises. (in case you wonder, cardmgr is from pcmcia_cs-3.1.25). OK, I'll take a look at it. I made the patch against -ac21 which I think was only synced up to 2.4.3-pre6, I should have mentioned that. Perhaps someone added the proper Xircom stuff already or some other change made my patch irrelavent. BTW, are you building serial.c as a module, or built in? I have mine as a module so it doesn't load until after the card is initialized. Just curious. I tested 2.4.3-pre7 and it still fails without my patch. With my patch I get the above message about 'Redundant entry in serial pci_table' but it still manages to setup my serial device as /dev/ttyS4 (the same patch applied to 2.4.2-ac21 sets the device to /dev/ttyS1). However it only works if I load serial.c as a module AFTER the card is inserted, if serial.c is already loaded it doesn't register correctly with a messages similar to above. Perhaps I need to check my hotplug setup. Could your try serial.c as a module and see if it works for you like that? That way I'd know I'm on the right track and haven't just found some strange way to make it work on my system alone. Later, Tom - 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/
[PATCH] Fix for serial.c to work with Xircom Cardbus Ethernet+Modem
> Tom Sightler wrote:
> >
> > Hi all,
> >
> > I saw a discussion on this list about this problem earlier, but could
not
> > find that it had actually been resolved.
>
> That was me :) and no, it doesn't work. Jeff Garzik asked me to enable
> a couple debug #defines in serial.c, apply patches to serial.c and
> finally disable i82365 support but as of now it doesn't work.
>
> It looks like we have the same card with modem @ 0x1880.
Yep, almost certainly the same, or at least very similar Xircom card.
> > Any ideas? I may look at it more tomorrow. For now I'm back to using
> > serial_cb which still works fine (even though that apparently suprises
many
> > people).
>
> :) this is -pre4 with serial_cb which works fine, and always has...
OK, can you try this patch? It's very simple, and is probably not the
correct fix (the correct fix is probably to add the Xircom card to the
supported PCI table), but it works for me. I'm not sure why the generic pci
serial code counts the number of iomem regions and only uses it if it has
exactly 0 or 1, but the Xircom has 2 iomem regions so the generic code fails
to use it. The following change relaxes the generic code to allow for up to
2 iomem regions on a PCI serial device. I have no idea what the side
effects would be to this change, but it makes my Xircom work again and that
was my goal. If I can help someone fix this correctly let me know what you
need.
Later,
Tom
--- serial.c.oldFri Mar 23 23:23:17 2001
+++ serial.cFri Mar 23 23:24:17 2001
@@ -4616,10 +4616,10 @@
}
/*
-* If there is 1 or 0 iomem regions, and exactly one port, use
+* If there is <= 2 iomem regions, and exactly one port, use
* it.
*/
- if (num_iomem <= 1 && num_port == 1) {
+ if (num_iomem <= 2 && num_port == 1) {
board->flags = first_port;
return 0;
}
-
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/
[PATCH] Fix for serial.c to work with Xircom Cardbus Ethernet+Modem
Tom Sightler wrote:
Hi all,
I saw a discussion on this list about this problem earlier, but could
not
find that it had actually been resolved.
That was me :) and no, it doesn't work. Jeff Garzik asked me to enable
a couple debug #defines in serial.c, apply patches to serial.c and
finally disable i82365 support but as of now it doesn't work.
It looks like we have the same card with modem @ 0x1880.
Yep, almost certainly the same, or at least very similar Xircom card.
Any ideas? I may look at it more tomorrow. For now I'm back to using
serial_cb which still works fine (even though that apparently suprises
many
people).
:) this is -pre4 with serial_cb which works fine, and always has...
OK, can you try this patch? It's very simple, and is probably not the
correct fix (the correct fix is probably to add the Xircom card to the
supported PCI table), but it works for me. I'm not sure why the generic pci
serial code counts the number of iomem regions and only uses it if it has
exactly 0 or 1, but the Xircom has 2 iomem regions so the generic code fails
to use it. The following change relaxes the generic code to allow for up to
2 iomem regions on a PCI serial device. I have no idea what the side
effects would be to this change, but it makes my Xircom work again and that
was my goal. If I can help someone fix this correctly let me know what you
need.
Later,
Tom
--- serial.c.oldFri Mar 23 23:23:17 2001
+++ serial.cFri Mar 23 23:24:17 2001
@@ -4616,10 +4616,10 @@
}
/*
-* If there is 1 or 0 iomem regions, and exactly one port, use
+* If there is = 2 iomem regions, and exactly one port, use
* it.
*/
- if (num_iomem = 1 num_port == 1) {
+ if (num_iomem = 2 num_port == 1) {
board-flags = first_port;
return 0;
}
-
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/
Can't get serial.c to work with Xircom Cardbus Ethernet+Modem
Hi all, I saw a discussion on this list about this problem earlier, but could not find that it had actually been resolved. With the removal of serial_cb from the 2.4.3pre kernels I can no longer use the modem of my Xircom adapter. According to the posts in the other thread serial.c should now provide this functionality, however it still does not, at least for me. The thread seemed to come to the conclusion that this was caused because the serial driver only looks for PCI devices of class SERIAL and not MODEM. I tried the patch shown there for the 5.05 serial driver but it still doesn't find the serial interface on my Xircom 10/100 Ethernet+56K Modem combo card. I'm pretty sure the issue is not caused by the problem above, because as far as I can tell the modem on the adapter does present itself as a PCI SERIAL class device as shown by the following lspci output: [root@iso-2146-l1 ttsig]# /sbin/lspci 02:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) 02:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) [root@iso-2146-l1 ttsig]# /sbin/lspci -n 02:00.0 Class 0200: 115d:0003 (rev 03) 02:00.1 Class 0700: 115d:0103 (rev 03) [root@iso-2146-l1 ttsig]# /sbin/lspci -v 02:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 1800 [size=128] Memory at 1480 (32-bit, non-prefetchable) [size=2K] Memory at 14800800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 1440 [size=16K] Capabilities: [dc] Power Management version 1 02:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02 [16550]) Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem Flags: medium devsel, IRQ 11 I/O ports at 1880 [size=8] Memory at 14801000 (32-bit, non-prefetchable) [size=2K] Memory at 14801800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 14404000 [size=16K] Capabilities: [dc] Power Management version 1 I'm pretty sure that Class 0700 is the proper class for a PCI serial device. The serial_cb driver from 2.4.2 always recognized this device properly and set it up as /dev/ttyS1 using IO 0x1880 and IRQ 11. It showed under setserial as a follows: /dev/ttyS1, UART: 16550A, Port: 0x1880, IRQ: 11 Now with serial.c it doesn't even get reported, I get the following when I load serial.c: Serial driver version 5.05.SA (2000-09-14) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A I know the version doesn't show as 5.05A, but I applied the patch by hand and left off that part. I'm pretty sure the patch is irrelavent since the device does show up as a true PCI SERIAL Class device. Any ideas? I may look at it more tomorrow. For now I'm back to using serial_cb which still works fine (even though that apparently suprises many people). Later, Tom - 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/
Can't get serial.c to work with Xircom Cardbus Ethernet+Modem
Hi all, I saw a discussion on this list about this problem earlier, but could not find that it had actually been resolved. With the removal of serial_cb from the 2.4.3pre kernels I can no longer use the modem of my Xircom adapter. According to the posts in the other thread serial.c should now provide this functionality, however it still does not, at least for me. The thread seemed to come to the conclusion that this was caused because the serial driver only looks for PCI devices of class SERIAL and not MODEM. I tried the patch shown there for the 5.05 serial driver but it still doesn't find the serial interface on my Xircom 10/100 Ethernet+56K Modem combo card. I'm pretty sure the issue is not caused by the problem above, because as far as I can tell the modem on the adapter does present itself as a PCI SERIAL class device as shown by the following lspci output: [root@iso-2146-l1 ttsig]# /sbin/lspci 02:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) 02:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) [root@iso-2146-l1 ttsig]# /sbin/lspci -n 02:00.0 Class 0200: 115d:0003 (rev 03) 02:00.1 Class 0700: 115d:0103 (rev 03) [root@iso-2146-l1 ttsig]# /sbin/lspci -v 02:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at 1800 [size=128] Memory at 1480 (32-bit, non-prefetchable) [size=2K] Memory at 14800800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 1440 [size=16K] Capabilities: [dc] Power Management version 1 02:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02 [16550]) Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem Flags: medium devsel, IRQ 11 I/O ports at 1880 [size=8] Memory at 14801000 (32-bit, non-prefetchable) [size=2K] Memory at 14801800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 14404000 [size=16K] Capabilities: [dc] Power Management version 1 I'm pretty sure that Class 0700 is the proper class for a PCI serial device. The serial_cb driver from 2.4.2 always recognized this device properly and set it up as /dev/ttyS1 using IO 0x1880 and IRQ 11. It showed under setserial as a follows: /dev/ttyS1, UART: 16550A, Port: 0x1880, IRQ: 11 Now with serial.c it doesn't even get reported, I get the following when I load serial.c: Serial driver version 5.05.SA (2000-09-14) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A I know the version doesn't show as 5.05A, but I applied the patch by hand and left off that part. I'm pretty sure the patch is irrelavent since the device does show up as a true PCI SERIAL Class device. Any ideas? I may look at it more tomorrow. For now I'm back to using serial_cb which still works fine (even though that apparently suprises many people). Later, Tom - 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: APM battery status reporting
> > tested in previous kernels. Then again my dmesg says the BIOS is probably > > buggy (same BIOS though as mentioned in those posts). Apmd does notice the > > change from mains to battery and vice versa (I have disabled Speedstep so now > > everything actually survives this transition :-). > > So to end all the confusion, is there a patch out there that enables battery > > status reporting for me (and other Dell owners :-) ? > > Yes but the update you need is a new BIOS revision. Ask Dell > The BIOS update has been around forever from Compal (the people who actually OEM the unit for Dell), you can get their generic BIOS at http://software.tuxtops.com. This probably violates your Dell warranty but I know many who use it and we've now installed it on all the 5000e systems we own, without any problem. I'm not sure why Dell is taking so long to get an update to it consumers, but it probably has something to do with the fact that Linux isn't a supported platform on this machine. Their official stance appears to be "APM isn't supported on this laptop, only ACPI." That's pretty bogus since everything but this one system call works, and even that works with the Compal generic BIOS, so I'd more likely guess it's just not high on the priority list because it's not important enough for their largest user base which is of course Windows. Later, Tom - 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: Questions about Enterprise Storage with Linux
> >1. What is the largest block device that linux currently supports? i.e. > >Can I create a single 1TB volume on my storage device and expect linux to > >see it and be able to format it? > > Checkout the GFS project for really large filesystems with a high capability > of "fail safe" configuration. > > The block/file limits are more determined by the size of the hosts. Alpha/Sparc > based systems use 64 bit operations, Intel/AMD use 32 bit. It also depends > on usage of the sign bit in the drivers. Most 32bit systems are limited > to 1 TB (depending on the driver of course - some allow for 2 TB). Yes, I should have clarified, we will be using the Intel platform. A large portion of the fiber channel storage (as much as 300GB in year one) will be dedicated to an Oracle 8i database, I'm not sure if GFS is truly suited for this server, although we have considered using LVM (perhaps even RAWIO on LVM although I see reports of problems with that) to ease some storage management issues (we've been testing LVM with reiserfs and are very impressed with the ease of adding space and growing the filesystem live). > >2. Does linux have any problems with large (500GB+) NFS exports, how about > >large files over NFS? > > I can't really say - you might clarify by what you count as large ( just > 2G > should be fine for any current kernel), not sure if "large" means 25-100GB. For example if we purchase a NetApp Filer, or EMC Celerra with 1TB of storage, and elect to export that entire amount as a single NFS mount, and then use that storage to allow several Linux boxes to share 100GB (admittedly temporary) files, will Linux handle that, at least in theory? Basically, I don't know what the file size limits are on NFS (on any system, not neccesarily just Linux) and was hoping someone could tell me. And actually, we have looked at GFS as an alternative for this function, biggest disadvantage is cost of connecting 7 machines via fiber channel (we already have GigE from the network connectivity), but it does look like an excellent option which we may very well go with. And some of these sizes I'm asking about are just seeking the limits, I'll personally be amazed if we actually approach within half of these sizes any time soon, but then again, data always manages to grow to fill whatever storage you have available so I guess you never know, right? > >3. What filesystem would be best for such large volumes? We currently use > >reirserfs on our internal system, but they generally have filesystems in the > >18-30GB ranges and we're talking about potentially 10-20x that. Should we > >look at JFS/XFS or others? > > The GFS project already has tested 2TB in fiber channel array(s) with full > multi-host connectivity (shared filesystems rather than NFS). > > The big advantage with GFS is that redundant servers can be available > by having two or more NFS servers attached to the same GFS filesystem. Yep, as I mentioned above, we may very well use GFS here. It certainly has some advantages that we really like, but we need to justify the additional host of HBA's and another fiber channel switch (saying it won't work over NFS would be enough to justify it). We also had some concerns of stability with GFS, not that we know of any issues, but we don't really have an easy way test it in our current environment, and we haven't ordered the new equipment yet. > >4. We're seriously considering using LVM for volume management. Does it > >have size limits per volume or other limitations that we should be aware of? > > GFS may serve better. It is a full shared filesystem with RAID target disks > (these are smart controllers) and incudes journaling. The LVM issue was largely for the managent of the volumes dedicated to the Oracle database (basically a replacement for Veritas Volume Manager that Oracle on Solaris folks seem to love). Once again, we don't think GFS is really suited for Oracle (other opinions accepted). I was interrupted a few too many times when composing the first email, I should have been more detailed about exactly what we were doing, what we've looked at, etc. Thanks, Tom - 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/
Questions about Enterprise Storage with Linux
Hi All, I'm seeking information in regards to a large Linux implementation we are planning. We have been evaluating many storage options and I've come up with some questions that I have been unable to answer as far as Linux capabilities in regards to storage. We are looking at storage systems that provide approximately 1TB of capacity for now and can scale to 10+TB in the future. We will almost certainly use a storage system that provides both fiber channel connectivity as well as NFS connectivity. The questions that have been asked are as follows (assume 2.4.x kernels): 1. What is the largest block device that linux currently supports? i.e. Can I create a single 1TB volume on my storage device and expect linux to see it and be able to format it? 2. Does linux have any problems with large (500GB+) NFS exports, how about large files over NFS? 3. What filesystem would be best for such large volumes? We currently use reirserfs on our internal system, but they generally have filesystems in the 18-30GB ranges and we're talking about potentially 10-20x that. Should we look at JFS/XFS or others? 4. We're seriously considering using LVM for volume management. Does it have size limits per volume or other limitations that we should be aware of? I'm sure these answers are out there, but I haven't been able to find definitive answers (it seems everyone has a different answer to each question). Any assistance in pointing me to the correct information would be greatly appreciated. Thanks, Tom - 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/
Questions about Enterprise Storage with Linux
Hi All, I'm seeking information in regards to a large Linux implementation we are planning. We have been evaluating many storage options and I've come up with some questions that I have been unable to answer as far as Linux capabilities in regards to storage. We are looking at storage systems that provide approximately 1TB of capacity for now and can scale to 10+TB in the future. We will almost certainly use a storage system that provides both fiber channel connectivity as well as NFS connectivity. The questions that have been asked are as follows (assume 2.4.x kernels): 1. What is the largest block device that linux currently supports? i.e. Can I create a single 1TB volume on my storage device and expect linux to see it and be able to format it? 2. Does linux have any problems with large (500GB+) NFS exports, how about large files over NFS? 3. What filesystem would be best for such large volumes? We currently use reirserfs on our internal system, but they generally have filesystems in the 18-30GB ranges and we're talking about potentially 10-20x that. Should we look at JFS/XFS or others? 4. We're seriously considering using LVM for volume management. Does it have size limits per volume or other limitations that we should be aware of? I'm sure these answers are out there, but I haven't been able to find definitive answers (it seems everyone has a different answer to each question). Any assistance in pointing me to the correct information would be greatly appreciated. Thanks, Tom - 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: Questions about Enterprise Storage with Linux
1. What is the largest block device that linux currently supports? i.e. Can I create a single 1TB volume on my storage device and expect linux to see it and be able to format it? Checkout the GFS project for really large filesystems with a high capability of "fail safe" configuration. The block/file limits are more determined by the size of the hosts. Alpha/Sparc based systems use 64 bit operations, Intel/AMD use 32 bit. It also depends on usage of the sign bit in the drivers. Most 32bit systems are limited to 1 TB (depending on the driver of course - some allow for 2 TB). Yes, I should have clarified, we will be using the Intel platform. A large portion of the fiber channel storage (as much as 300GB in year one) will be dedicated to an Oracle 8i database, I'm not sure if GFS is truly suited for this server, although we have considered using LVM (perhaps even RAWIO on LVM although I see reports of problems with that) to ease some storage management issues (we've been testing LVM with reiserfs and are very impressed with the ease of adding space and growing the filesystem live). 2. Does linux have any problems with large (500GB+) NFS exports, how about large files over NFS? I can't really say - you might clarify by what you count as large ( just 2G should be fine for any current kernel), not sure if "large" means 25-100GB. For example if we purchase a NetApp Filer, or EMC Celerra with 1TB of storage, and elect to export that entire amount as a single NFS mount, and then use that storage to allow several Linux boxes to share 100GB (admittedly temporary) files, will Linux handle that, at least in theory? Basically, I don't know what the file size limits are on NFS (on any system, not neccesarily just Linux) and was hoping someone could tell me. And actually, we have looked at GFS as an alternative for this function, biggest disadvantage is cost of connecting 7 machines via fiber channel (we already have GigE from the network connectivity), but it does look like an excellent option which we may very well go with. And some of these sizes I'm asking about are just seeking the limits, I'll personally be amazed if we actually approach within half of these sizes any time soon, but then again, data always manages to grow to fill whatever storage you have available so I guess you never know, right? 3. What filesystem would be best for such large volumes? We currently use reirserfs on our internal system, but they generally have filesystems in the 18-30GB ranges and we're talking about potentially 10-20x that. Should we look at JFS/XFS or others? The GFS project already has tested 2TB in fiber channel array(s) with full multi-host connectivity (shared filesystems rather than NFS). The big advantage with GFS is that redundant servers can be available by having two or more NFS servers attached to the same GFS filesystem. Yep, as I mentioned above, we may very well use GFS here. It certainly has some advantages that we really like, but we need to justify the additional host of HBA's and another fiber channel switch (saying it won't work over NFS would be enough to justify it). We also had some concerns of stability with GFS, not that we know of any issues, but we don't really have an easy way test it in our current environment, and we haven't ordered the new equipment yet. 4. We're seriously considering using LVM for volume management. Does it have size limits per volume or other limitations that we should be aware of? GFS may serve better. It is a full shared filesystem with RAID target disks (these are smart controllers) and incudes journaling. The LVM issue was largely for the managent of the volumes dedicated to the Oracle database (basically a replacement for Veritas Volume Manager that Oracle on Solaris folks seem to love). Once again, we don't think GFS is really suited for Oracle (other opinions accepted). I was interrupted a few too many times when composing the first email, I should have been more detailed about exactly what we were doing, what we've looked at, etc. Thanks, Tom - 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: [CFT] maestro update vs 2.2.18
> Its an awfully large diff, so it can be fetched from: > > http://www.zabbo.net/maestro/patches/2.2.18-mega-1.diff.gz > > if this works I'll officially submit it and make the same sorts of > changes to 2.4. I'd love to test this on my Dell 5000e (Maestro 2E) but it's pretty impractical for me to return to the 2.2.x kernels. I know you said you'll wait before making the changes to 2.4, but I think you'll get more testers if you turn it out sooner rather than later. Later, Tom - 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: [CFT] maestro update vs 2.2.18
Its an awfully large diff, so it can be fetched from: http://www.zabbo.net/maestro/patches/2.2.18-mega-1.diff.gz if this works I'll officially submit it and make the same sorts of changes to 2.4. I'd love to test this on my Dell 5000e (Maestro 2E) but it's pretty impractical for me to return to the 2.2.x kernels. I know you said you'll wait before making the changes to 2.4, but I think you'll get more testers if you turn it out sooner rather than later. Later, Tom - 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: LILO error with 2.4.3-pre1...
- Original Message - From: "Keith Owens" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, March 03, 2001 8:39 PM Subject: Re: LILO error with 2.4.3-pre1... > On Sat, 03 Mar 2001 19:19:28 -0600, > "Steven J. Hill" <[EMAIL PROTECTED]> wrote: > >I have no idea why the 1023 limit is coming up considering 2.4.2 and > >LILO were working just fine together and I have a newer BIOS that has > >not problems detecting the driver properly. Go ahead, call me idiot :). > > OK, you're an idiot :). It only worked before because all the files > that lilo used just happened to be below cylinder 1024. Your partition > goes past cyl 1024 and your new kernel is using space above 1024. I would agree with this explanation. > Find a version of lilo that can cope with cyl >= 1024 (is there one?) Uh, the version he has can cope with this, see the following: >LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger >'lba32' extensions Copyright (C) 1999,2000 John Coffman The lba32 extensions should take care of this, of course you have to add 'lba32' as a line in your lilo.conf before lilo actually uses them (and, I assume, the BIOS must support the LBA extensions, but it seems most modern ones do). Give that a try. Works for me. Later, Tom - 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: LILO error with 2.4.3-pre1...
- Original Message - From: "Keith Owens" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, March 03, 2001 8:39 PM Subject: Re: LILO error with 2.4.3-pre1... On Sat, 03 Mar 2001 19:19:28 -0600, "Steven J. Hill" [EMAIL PROTECTED] wrote: I have no idea why the 1023 limit is coming up considering 2.4.2 and LILO were working just fine together and I have a newer BIOS that has not problems detecting the driver properly. Go ahead, call me idiot :). OK, you're an idiot :). It only worked before because all the files that lilo used just happened to be below cylinder 1024. Your partition goes past cyl 1024 and your new kernel is using space above 1024. I would agree with this explanation. Find a version of lilo that can cope with cyl = 1024 (is there one?) Uh, the version he has can cope with this, see the following: LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger 'lba32' extensions Copyright (C) 1999,2000 John Coffman The lba32 extensions should take care of this, of course you have to add 'lba32' as a line in your lilo.conf before lilo actually uses them (and, I assume, the BIOS must support the LBA extensions, but it seems most modern ones do). Give that a try. Works for me. Later, Tom - 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: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
> In your message of: Sat, 24 Feb 2001 11:55:07 CST, you write: > > > >Careful, you're overwriting ACPI data now (and using it as normal RAM). > > Hmm, I guess that would be bad. > > >Can you try one of a) LILO b) a fixed version of grub c) this patch ? > > I tried LILO and the problem did indeed go away when using that. I > guess I'll stick with LILO until Linux or grub (whichever is broken) > is fixed. There is just something appealing about a proper boot > console on a PC... Even though I wasn't much help on this, it's nice to know what was different on your config that was causing problems while I wasn't seeing any issues. I sat here for almost an hour last night trying to figure out why your machines memory map would different than mine (I have 320MB of RAM as well, so they should have been the same). The thought that you might be using a different boot loader never even crossed my mind. I've always used LILO so that's why I didn't see any problems. It's nice to know it wasn't just working for me by accident. Later, Tom - 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: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
In your message of: Sat, 24 Feb 2001 11:55:07 CST, you write: Careful, you're overwriting ACPI data now (and using it as normal RAM). Hmm, I guess that would be bad. Can you try one of a) LILO b) a fixed version of grub c) this patch ? I tried LILO and the problem did indeed go away when using that. I guess I'll stick with LILO until Linux or grub (whichever is broken) is fixed. There is just something appealing about a proper boot console on a PC... Even though I wasn't much help on this, it's nice to know what was different on your config that was causing problems while I wasn't seeing any issues. I sat here for almost an hour last night trying to figure out why your machines memory map would different than mine (I have 320MB of RAM as well, so they should have been the same). The thought that you might be using a different boot loader never even crossed my mind. I've always used LILO so that's why I didn't see any problems. It's nice to know it wasn't just working for me by accident. Later, Tom - 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: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
> I took your advice and used the kernel drivers from 2.4.2. I built > the Cardbus and i82365 drivers into the kernel. This shows the exact > same behavior, after a power-on reboot I get: You don't need the i82365 driver, only the Cardbus (yenta) driver. I don't think this would cause your problem, but it's possible, maybe try without it. > and though the cardmgr loads it does not respond to card events, > i.e. inserting a card produces *no* effect, there is not a beep, or > any logged messages. Rebooting with 2.2.17 fixes the problem and > 2.4.2 then works again. It looks to me like something in the PCI bus > isn't setup correctly by the 2.4 kernels, but chasing that down is way > beyond my ability, hence the post to linux-kernel. What's strange is that I have the exact same type of machine and I don't see this problem, could you forward me your kernel config as well? I'll compare that, and your info from your previous message to mine and see if we can find a difference. Later, Tom - 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: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
I took your advice and used the kernel drivers from 2.4.2. I built the Cardbus and i82365 drivers into the kernel. This shows the exact same behavior, after a power-on reboot I get: You don't need the i82365 driver, only the Cardbus (yenta) driver. I don't think this would cause your problem, but it's possible, maybe try without it. and though the cardmgr loads it does not respond to card events, i.e. inserting a card produces *no* effect, there is not a beep, or any logged messages. Rebooting with 2.2.17 fixes the problem and 2.4.2 then works again. It looks to me like something in the PCI bus isn't setup correctly by the 2.4 kernels, but chasing that down is way beyond my ability, hence the post to linux-kernel. What's strange is that I have the exact same type of machine and I don't see this problem, could you forward me your kernel config as well? I'll compare that, and your info from your previous message to mine and see if we can find a difference. Later, Tom - 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: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up
> > There seem to be several reports of reiserfs falling over when memory is > > low. It seems to be undetermined if this problem is actually reiserfs or MM > > related, but there are other threads on this list regarding similar issues. > > This would explain why the same disk would work on a different machine with > > more memory. Any chance you could add memory to the box temporarily just to > > see if it helps, this may help prove if this is the problem or not. > > > > Out of all the old 72 pin simms we have, we have it maxed out at 48 MB's. I'm > tempted to take the 2 drives out and put them in the k6-2, but that's too much > of a hassle. I'm currently going to try 2.4.1-ac19 and see what happens. > > The machine does have 128MB of swap space working, and whenever I've checked > memory usage (while the system was still responding), it never went over a > couple megs of swap space used. Ah yes, but, from what I've read, the problem seems to occur when buffer/cache memory is low (<6MB), you could have tons of swap and still reach this level. Later, Tom - 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: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up
>> >I'm building a firewall on a P133 with 48 MB of memory using RH 7.0, >> >latest updates, etc. and kernel 2.4.1. >> >I've built a customized install of RH (~200MB) which I untar onto the >> >system after building my raid arrays, etc. via a Rescue CD which I >> >created using Timo's Rescue CD project. The booting kernel is >> >2.4.1-ac10, no networking, raid compiled in but raid1 as a module >> >> Hmm, raid as a module was always a Bad Idea(tm) in the 2.2 "alpha" >> raid (which was misnamed and is 2.4 raid). I suggest you change that >> and update, as I had no problems with 2.4.2-pre2/3, nor have any been >> posted to the raid list. > >I just tried with 2.4.1-ac14, raid and raid1 compiled in and it did the >same thing. I'm going to try to compile reiserfs in (if I have enough room >to still fit the kernel on the floppy with it's initial ramdisk, etc.) and >see what that does. There seem to be several reports of reiserfs falling over when memory is low. It seems to be undetermined if this problem is actually reiserfs or MM related, but there are other threads on this list regarding similar issues. This would explain why the same disk would work on a different machine with more memory. Any chance you could add memory to the box temporarily just to see if it helps, this may help prove if this is the problem or not. Later, Tom - 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: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up
I'm building a firewall on a P133 with 48 MB of memory using RH 7.0, latest updates, etc. and kernel 2.4.1. I've built a customized install of RH (~200MB) which I untar onto the system after building my raid arrays, etc. via a Rescue CD which I created using Timo's Rescue CD project. The booting kernel is 2.4.1-ac10, no networking, raid compiled in but raid1 as a module Hmm, raid as a module was always a Bad Idea(tm) in the 2.2 "alpha" raid (which was misnamed and is 2.4 raid). I suggest you change that and update, as I had no problems with 2.4.2-pre2/3, nor have any been posted to the raid list. I just tried with 2.4.1-ac14, raid and raid1 compiled in and it did the same thing. I'm going to try to compile reiserfs in (if I have enough room to still fit the kernel on the floppy with it's initial ramdisk, etc.) and see what that does. There seem to be several reports of reiserfs falling over when memory is low. It seems to be undetermined if this problem is actually reiserfs or MM related, but there are other threads on this list regarding similar issues. This would explain why the same disk would work on a different machine with more memory. Any chance you could add memory to the box temporarily just to see if it helps, this may help prove if this is the problem or not. Later, Tom - 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: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up
There seem to be several reports of reiserfs falling over when memory is low. It seems to be undetermined if this problem is actually reiserfs or MM related, but there are other threads on this list regarding similar issues. This would explain why the same disk would work on a different machine with more memory. Any chance you could add memory to the box temporarily just to see if it helps, this may help prove if this is the problem or not. Out of all the old 72 pin simms we have, we have it maxed out at 48 MB's. I'm tempted to take the 2 drives out and put them in the k6-2, but that's too much of a hassle. I'm currently going to try 2.4.1-ac19 and see what happens. The machine does have 128MB of swap space working, and whenever I've checked memory usage (while the system was still responding), it never went over a couple megs of swap space used. Ah yes, but, from what I've read, the problem seems to occur when buffer/cache memory is low (6MB), you could have tons of swap and still reach this level. Later, Tom - 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: Samba performance / zero-copy network I/O
> > My testing showed that the lowlatency patches abosolutely destroy a system > > thoughput under heavy disk IO. > > I'm surprised - I've been keeping an eye on that. > > Here's the result of a bunch of back-to-back `dbench 12' runs > on UP, alternating with and without LL: It's interesting that your results seem to show an improvement in performance, while mine show a consistent drop. My tests were not very scientific, and I was running much higher dbench processes, 'dbench 64' or 'dbench 128', and at those levels performance with lowlatency enabled fell though the floor on my setup. My system is a PIII 700Mhz, Adaptec 7892 Ultra-160, software RAID1, reiserfs, 256MB RAM. Under lower loads, like the 'dbench 12' lowlatency only showed only a few percent loss, but once you approached the levels around 50 things really went downhill. I might try to do a more complete test, maybe there's something else in my config that would make this be a problem, but it was definately quite noticable. Later, Tom - 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: Samba performance / zero-copy network I/O
My testing showed that the lowlatency patches abosolutely destroy a system thoughput under heavy disk IO. I'm surprised - I've been keeping an eye on that. Here's the result of a bunch of back-to-back `dbench 12' runs on UP, alternating with and without LL: It's interesting that your results seem to show an improvement in performance, while mine show a consistent drop. My tests were not very scientific, and I was running much higher dbench processes, 'dbench 64' or 'dbench 128', and at those levels performance with lowlatency enabled fell though the floor on my setup. My system is a PIII 700Mhz, Adaptec 7892 Ultra-160, software RAID1, reiserfs, 256MB RAM. Under lower loads, like the 'dbench 12' lowlatency only showed only a few percent loss, but once you approached the levels around 50 things really went downhill. I might try to do a more complete test, maybe there's something else in my config that would make this be a problem, but it was definately quite noticable. Later, Tom - 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: Samba performance / zero-copy network I/O
Quoting "Gord R. Lamb" <[EMAIL PROTECTED]>: > On Wed, 14 Feb 2001, Jeremy Jackson wrote: > > > "Gord R. Lamb" wrote: > > > in etherchannel bond, running > linux-2.4.1+smptimers+zero-copy+lowlatency) Not related to network, but why would you have lowlatency patches on this box? My testing showed that the lowlatency patches abosolutely destroy a system thoughput under heavy disk IO. Sure, the box stays nice and responsive, but something has to give. On a file server I'll trade console responsivness for IO performance any day (might choose the opposite on my laptop). My testing wasn't very complete, but heavy dbench and multiple simultaneous file copies both showed significantly lower performance with lowlatency enabled, and returned to normal when disabled. Of course you may have had lowlatency disabled via sysctl but I was mainly curious if your results were different. Later, Tom - 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: Samba performance / zero-copy network I/O
Quoting "Gord R. Lamb" [EMAIL PROTECTED]: On Wed, 14 Feb 2001, Jeremy Jackson wrote: "Gord R. Lamb" wrote: in etherchannel bond, running linux-2.4.1+smptimers+zero-copy+lowlatency) Not related to network, but why would you have lowlatency patches on this box? My testing showed that the lowlatency patches abosolutely destroy a system thoughput under heavy disk IO. Sure, the box stays nice and responsive, but something has to give. On a file server I'll trade console responsivness for IO performance any day (might choose the opposite on my laptop). My testing wasn't very complete, but heavy dbench and multiple simultaneous file copies both showed significantly lower performance with lowlatency enabled, and returned to normal when disabled. Of course you may have had lowlatency disabled via sysctl but I was mainly curious if your results were different. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with Netscape/Linux v.2.4.x [repeat] (MTU problem??)
Quoting [EMAIL PROTECTED]: > Symptoms: The browser (Netscape or Lynx) will not download from remote > web sites (dynamic ppp connection via external modem). > > This looks to be a problem for my PC and the 2.4.x kernel, It is very interesting that your are having this problem. I have been having a similar problem with with 2.4.x on my laptop and had been unable to totally put it all together. Here's my basic symtoms: I can use the web quite normally for quite some time, but certain sites seem to be a trigger. For example, if I go to IBM site and attempt to download they're JDK I immediately start getting errors on my ppp0 interface. From that point on I get errors on other sites that previously were working, and the ppp0 errors continue to increase throughout the entire duration of the call. If I hang up and dial back everything goes back to normal again until I attempt to connect to the IBM download site again. I originally thought this was a problem with my Xircom adapter, but if I fire up VMware I can use Windows 2000 to dial the same link and everything works fine to all the same sites. This certainly implies that the serial layer is working properly since VMware still simply passes control of /dev/ttyS1 to the VM. I was unable to reproduce this problem on the same system with kernel 2.2.18, all other things being the same. I don't think my ISP uses trasparent proxies, but it is possible the remote IBM system uses some transparent web accelerator/load balancer. Most of the IBM web site works properly, only the software download site seems to trigger the problem. The problem does exhibit itself on other sites, but the IBM site is where began to realize it was repeatable. Do you get errors on your ppp0 interface? Just curious. Now that I know I'm not just crazy maybe I'll look into it more. Later, Tom - 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://vger.kernel.org/lkml/
Re: Problem with Netscape/Linux v.2.4.x [repeat] (MTU problem??)
Quoting [EMAIL PROTECTED]: Symptoms: The browser (Netscape or Lynx) will not download from remote web sites (dynamic ppp connection via external modem). This looks to be a problem for my PC and the 2.4.x kernel, It is very interesting that your are having this problem. I have been having a similar problem with with 2.4.x on my laptop and had been unable to totally put it all together. Here's my basic symtoms: I can use the web quite normally for quite some time, but certain sites seem to be a trigger. For example, if I go to IBM site and attempt to download they're JDK I immediately start getting errors on my ppp0 interface. From that point on I get errors on other sites that previously were working, and the ppp0 errors continue to increase throughout the entire duration of the call. If I hang up and dial back everything goes back to normal again until I attempt to connect to the IBM download site again. I originally thought this was a problem with my Xircom adapter, but if I fire up VMware I can use Windows 2000 to dial the same link and everything works fine to all the same sites. This certainly implies that the serial layer is working properly since VMware still simply passes control of /dev/ttyS1 to the VM. I was unable to reproduce this problem on the same system with kernel 2.2.18, all other things being the same. I don't think my ISP uses trasparent proxies, but it is possible the remote IBM system uses some transparent web accelerator/load balancer. Most of the IBM web site works properly, only the software download site seems to trigger the problem. The problem does exhibit itself on other sites, but the IBM site is where began to realize it was repeatable. Do you get errors on your ppp0 interface? Just curious. Now that I know I'm not just crazy maybe I'll look into it more. Later, Tom - 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://vger.kernel.org/lkml/
[Patch] [Repost] 3Com 3c523: Can't load module in kernel 2.4.1
Alan informs me that my mailer digested the last attempt at this post so
here's another attempt from a mailer I'm pretty sure is working correctly.
Another point, I don't take much credit for these patches as they are
largely ripped directly from the ni52 driver, with only minor
modifications. These should be enough to make the card work in 2.4 (they
"Work for Me"), although they're probably still not ideal.
I have some additional modifications that are more aggressive and attempt
to fix various problems with this driver that have existed for some time
(multicast, hard hangs, etc), but they're not very stable at this time.
When they act better I'll post them as well.
Anyway, here's the patch again, hope it works this time. It includes the
following changes:
- fix addresses with bus_to_virt
- reduce xmit buffers from 4 to 1 (puts driver in noop mode like ni52 driver)
- increase recv buffers from 6 to 9 (should help decrease dropped packets)
- add short delay to detect routine (makes cards detectable on fast machines)
- use eth_copy_and_sum for receiving packets
It passed basic stress testing with multiple, simultaneous ftp transfers.
Known bugs:
- Multicast still doesn't work at all (I have patches that seem to fix
this but they have other problems)
- Still drops packets under heavy traffic (can be reduced further by
lowering MTU on interface)
- Sometimes requires host to send a packet before it starts receiving (I
can't reproduce this on my equipment anymore, but needs more testing)
Anyone with this card please test and report back.
Later,
Tom
--- 3c523.c.241 Fri Feb 2 21:09:20 2001
+++ 3c523.c Sun Feb 4 21:02:18 2001
@@ -148,9 +148,9 @@
#define RECV_BUFF_SIZE 1524/* slightly oversized */
#define XMIT_BUFF_SIZE 1524/* slightly oversized */
-#define NUM_XMIT_BUFFS 4 /* config for both, 8K and 16K shmem */
-#define NUM_RECV_BUFFS_8 1/* config for 8K shared mem */
-#define NUM_RECV_BUFFS_16 6/* config for 16K shared mem */
+#define NUM_XMIT_BUFFS 1 /* config for both, 8K and 16K shmem */
+#define NUM_RECV_BUFFS_8 4/* config for 8K shared mem */
+#define NUM_RECV_BUFFS_16 9/* config for 16K shared mem */
#if (NUM_XMIT_BUFFS == 1)
#define NO_NOPCOMMANDS /* only possible with NUM_XMIT_BUFFS=1 */
@@ -303,13 +303,13 @@
char *iscp_addrs[2];
int i = 0;
- p->base = where + size - 0x0100;
- p->memtop = phys_to_virt(where) + size;
- p->scp = (struct scp_struct *)phys_to_virt(p->base + SCP_DEFAULT_ADDRESS);
+ p->base = (unsigned long) bus_to_virt((unsigned long)where) + size -
+0x0100;
+ p->memtop = bus_to_virt((unsigned long)where) + size;
+ p->scp = (struct scp_struct *)(p->base + SCP_DEFAULT_ADDRESS);
memset((char *) p->scp, 0, sizeof(struct scp_struct));
p->scp->sysbus = SYSBUSVAL; /* 1 = 8Bit-Bus, 0 = 16 Bit */
- iscp_addrs[0] = phys_to_virt(where);
+ iscp_addrs[0] = bus_to_virt((unsigned long)where);
iscp_addrs[1] = (char *) p->scp - sizeof(struct iscp_struct);
for (i = 0; i < 2; i++) {
@@ -325,6 +325,7 @@
/* apparently, you sometimes have to kick the 82586 twice... */
elmc_id_attn586();
+ DELAY(1);
if (p->iscp->busy) {/* i82586 clears 'busy' after successful init
*/
return 0;
@@ -344,8 +345,8 @@
elmc_id_reset586();
DELAY(2);
- p->scp = (struct scp_struct *) phys_to_virt(p->base + SCP_DEFAULT_ADDRESS);
- p->scb = (struct scb_struct *) phys_to_virt(dev->mem_start);
+ p->scp = (struct scp_struct *) (p->base + SCP_DEFAULT_ADDRESS);
+ p->scb = (struct scb_struct *) bus_to_virt(dev->mem_start);
p->iscp = (struct iscp_struct *) ((char *) p->scp - sizeof(struct
iscp_struct));
memset((char *) p->iscp, 0, sizeof(struct iscp_struct));
@@ -518,7 +519,8 @@
}
dev->mem_end = dev->mem_start + size; /* set mem_end showed by 'ifconfig' */
- ((struct priv *) (dev->priv))->base = dev->mem_start + size - 0x0100;
+ ((struct priv *) (dev->priv))->memtop = bus_to_virt(dev->mem_start) + size;
+ ((struct priv *) (dev->priv))->base = (unsigned long)
+bus_to_virt(dev->mem_start) + size - 0x0100;
alloc586(dev);
elmc_id_reset586(); /* make sure it doesn't generate spurious ints */
@@ -944,7 +946,8 @@
if (skb != NULL) {
skb->dev = dev;
skb_reserve(skb, 2);/* 16 byte alignment */
- memcpy(skb_put(skb, totlen), (u8
*)phys_to_virt(p->base) + (unsigned long) rbd->buffer, totlen);
+ skb_put(skb,totlen);
+ eth_copy_and_sum(skb, (char *)
+p->base+(unsigned long) rbd->buffer,totlen,0);
[Patch] [Repost] 3Com 3c523: Can't load module in kernel 2.4.1
Alan informs me that my mailer digested the last attempt at this post so
here's another attempt from a mailer I'm pretty sure is working correctly.
Another point, I don't take much credit for these patches as they are
largely ripped directly from the ni52 driver, with only minor
modifications. These should be enough to make the card work in 2.4 (they
"Work for Me"), although they're probably still not ideal.
I have some additional modifications that are more aggressive and attempt
to fix various problems with this driver that have existed for some time
(multicast, hard hangs, etc), but they're not very stable at this time.
When they act better I'll post them as well.
Anyway, here's the patch again, hope it works this time. It includes the
following changes:
- fix addresses with bus_to_virt
- reduce xmit buffers from 4 to 1 (puts driver in noop mode like ni52 driver)
- increase recv buffers from 6 to 9 (should help decrease dropped packets)
- add short delay to detect routine (makes cards detectable on fast machines)
- use eth_copy_and_sum for receiving packets
It passed basic stress testing with multiple, simultaneous ftp transfers.
Known bugs:
- Multicast still doesn't work at all (I have patches that seem to fix
this but they have other problems)
- Still drops packets under heavy traffic (can be reduced further by
lowering MTU on interface)
- Sometimes requires host to send a packet before it starts receiving (I
can't reproduce this on my equipment anymore, but needs more testing)
Anyone with this card please test and report back.
Later,
Tom
--- 3c523.c.241 Fri Feb 2 21:09:20 2001
+++ 3c523.c Sun Feb 4 21:02:18 2001
@@ -148,9 +148,9 @@
#define RECV_BUFF_SIZE 1524/* slightly oversized */
#define XMIT_BUFF_SIZE 1524/* slightly oversized */
-#define NUM_XMIT_BUFFS 4 /* config for both, 8K and 16K shmem */
-#define NUM_RECV_BUFFS_8 1/* config for 8K shared mem */
-#define NUM_RECV_BUFFS_16 6/* config for 16K shared mem */
+#define NUM_XMIT_BUFFS 1 /* config for both, 8K and 16K shmem */
+#define NUM_RECV_BUFFS_8 4/* config for 8K shared mem */
+#define NUM_RECV_BUFFS_16 9/* config for 16K shared mem */
#if (NUM_XMIT_BUFFS == 1)
#define NO_NOPCOMMANDS /* only possible with NUM_XMIT_BUFFS=1 */
@@ -303,13 +303,13 @@
char *iscp_addrs[2];
int i = 0;
- p-base = where + size - 0x0100;
- p-memtop = phys_to_virt(where) + size;
- p-scp = (struct scp_struct *)phys_to_virt(p-base + SCP_DEFAULT_ADDRESS);
+ p-base = (unsigned long) bus_to_virt((unsigned long)where) + size -
+0x0100;
+ p-memtop = bus_to_virt((unsigned long)where) + size;
+ p-scp = (struct scp_struct *)(p-base + SCP_DEFAULT_ADDRESS);
memset((char *) p-scp, 0, sizeof(struct scp_struct));
p-scp-sysbus = SYSBUSVAL; /* 1 = 8Bit-Bus, 0 = 16 Bit */
- iscp_addrs[0] = phys_to_virt(where);
+ iscp_addrs[0] = bus_to_virt((unsigned long)where);
iscp_addrs[1] = (char *) p-scp - sizeof(struct iscp_struct);
for (i = 0; i 2; i++) {
@@ -325,6 +325,7 @@
/* apparently, you sometimes have to kick the 82586 twice... */
elmc_id_attn586();
+ DELAY(1);
if (p-iscp-busy) {/* i82586 clears 'busy' after successful init
*/
return 0;
@@ -344,8 +345,8 @@
elmc_id_reset586();
DELAY(2);
- p-scp = (struct scp_struct *) phys_to_virt(p-base + SCP_DEFAULT_ADDRESS);
- p-scb = (struct scb_struct *) phys_to_virt(dev-mem_start);
+ p-scp = (struct scp_struct *) (p-base + SCP_DEFAULT_ADDRESS);
+ p-scb = (struct scb_struct *) bus_to_virt(dev-mem_start);
p-iscp = (struct iscp_struct *) ((char *) p-scp - sizeof(struct
iscp_struct));
memset((char *) p-iscp, 0, sizeof(struct iscp_struct));
@@ -518,7 +519,8 @@
}
dev-mem_end = dev-mem_start + size; /* set mem_end showed by 'ifconfig' */
- ((struct priv *) (dev-priv))-base = dev-mem_start + size - 0x0100;
+ ((struct priv *) (dev-priv))-memtop = bus_to_virt(dev-mem_start) + size;
+ ((struct priv *) (dev-priv))-base = (unsigned long)
+bus_to_virt(dev-mem_start) + size - 0x0100;
alloc586(dev);
elmc_id_reset586(); /* make sure it doesn't generate spurious ints */
@@ -944,7 +946,8 @@
if (skb != NULL) {
skb-dev = dev;
skb_reserve(skb, 2);/* 16 byte alignment */
- memcpy(skb_put(skb, totlen), (u8
*)phys_to_virt(p-base) + (unsigned long) rbd-buffer, totlen);
+ skb_put(skb,totlen);
+ eth_copy_and_sum(skb, (char *)
+p-base+(unsigned long) rbd-buffer,totlen,0);
skb-protocol = eth_type_trans(skb, dev);
[Patch] 3Com 3c523: Can't load module in kernel 2.4.1
Ok all, here's a patch that attempts to make the 3c523 driver work again in 2.4.1. It
includes the following changes:
- fix addresses with bus_to_virt
- reduce xmit buffers from 4 to 1 (puts driver in noop mode like ni52 driver)
- increase recv buffers from 6 to 9 (should help decrease dropped packets)
- add short delay to detect routine (makes cards detectable on fast machines)
- use eth_copy_and_sum for receiving packets
It passed basic stress testing with multiple, simultaneous ftp transfers.
Know bugs:
- Multicast still doesn't work at all (I have patches that seem to fix this but they
have other problems)
- Still drops packets under heavy traffic (can be reduced further by lowering MTU on
interface)
- Sometimes requires host to send a packet before it starts receiving (I can't
reproduce this on my equipment anymore, but needs more testing)
Anyone with this card please test and report back.
Later,
Tom
--- 3c523.c.241 Fri Feb 2 21:09:20 2001
+++ 3c523.c Sun Feb 4 21:02:18 2001
@@ -148,9 +148,9 @@
#define RECV_BUFF_SIZE 1524 /* slightly oversized */
#define XMIT_BUFF_SIZE 1524 /* slightly oversized */
-#define NUM_XMIT_BUFFS 4 /* config for both, 8K and 16K shmem */
-#define NUM_RECV_BUFFS_8 1/* config for 8K shared mem */
-#define NUM_RECV_BUFFS_16 6/* config for 16K shared mem */
+#define NUM_XMIT_BUFFS 1 /* config for both, 8K and 16K shmem */
+#define NUM_RECV_BUFFS_8 4/* config for 8K shared mem */
+#define NUM_RECV_BUFFS_16 9/* config for 16K shared mem */
#if (NUM_XMIT_BUFFS == 1)
#define NO_NOPCOMMANDS/* only possible with NUM_XMIT_BUFFS=1 */
@@ -303,13 +303,13 @@
char *iscp_addrs[2];
int i = 0;
-
p->base = where + size - 0x0100;
-
p->memtop = phys_to_virt(where) + size;
-
p->scp = (struct scp_struct *)phys_to_virt(p->base + SCP_DEFAULT_ADDRESS);
+
p->base = (unsigned long) bus_to_virt((unsigned long)where) + size - 0x0100;
+
p->memtop = bus_to_virt((unsigned long)where) + size;
+
p->scp = (struct scp_struct *)(p->base + SCP_DEFAULT_ADDRESS);
memset((char *) p->scp, 0, sizeof(struct scp_struct));
p->scp->sysbus = SYSBUSVAL; /* 1 = 8Bit-Bus, 0 = 16 Bit */
-
iscp_addrs[0] = phys_to_virt(where);
+
iscp_addrs[0] = bus_to_virt((unsigned long)where);
iscp_addrs[1] = (char *) p->scp - sizeof(struct iscp_struct);
for (i = 0; i < 2; i++) {
@@ -325,6 +325,7 @@
/* apparently, you sometimes have to kick the 82586 twice... */
elmc_id_attn586();
+
DELAY(1);
if (p->iscp->busy) {/* i82586 clears 'busy' after successful init
*/
return 0;
@@ -344,8 +345,8 @@
elmc_id_reset586();
DELAY(2);
-
p->scp = (struct scp_struct *) phys_to_virt(p->base + SCP_DEFAULT_ADDRESS);
-
p->scb = (struct scb_struct *) phys_to_virt(dev->mem_start);
+
p->scp = (struct scp_struct *) (p->base + SCP_DEFAULT_ADDRESS);
+
p->scb = (struct scb_struct *) bus_to_virt(dev->mem_start);
p->iscp = (struct iscp_struct *) ((char *) p->scp - sizeof(struct
iscp_struct));
memset((char *) p->iscp, 0, sizeof(struct iscp_struct));
@@ -518,7 +519,8 @@
}
dev->mem_end = dev->mem_start + size; /* set mem_end showed by 'ifconfig' */
-
((struct priv *) (dev->priv))->base = dev->mem_start + size - 0x0100;
+
((struct priv *) (dev->priv))->memtop = bus_to_virt(dev->mem_start) + size;
+
((struct priv *) (dev->priv))->base = (unsigned long) bus_to_virt(dev->mem_start) +
size - 0x0100;
alloc586(dev);
elmc_id_reset586(); /* make sure it doesn't generate spurious ints */
@@ -944,7 +946,8 @@
if (skb != NULL) {
skb->dev = dev;
skb_reserve(skb, 2);/* 16 byte alignment */
-
memcpy(skb_put(skb, totlen), (u8
*)phys_to_virt(p->base) + (unsigned long) rbd->buffer, totlen);
+
skb_put(skb,totlen);
+
eth_copy_and_sum(skb, (char *) p->base+(unsigned long)
rbd->buffer,totlen,0);
skb->protocol = eth_type_trans(skb, dev);
netif_rx(skb);
p->stats.rx_packets++;
@@ -1086,6 +1089,7 @@
static int elmc_send_packet(struct sk_buff *skb, struct net_device *dev)
{
int len;
+
int i;
#ifndef NO_NOPCOMMANDS
int next_nop;
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[Patch] 3Com 3c523: Can't load module in kernel 2.4.1
Ok all, here's a patch that attempts to make the 3c523 driver work again in 2.4.1. It
includes the following changes:
- fix addresses with bus_to_virt
- reduce xmit buffers from 4 to 1 (puts driver in noop mode like ni52 driver)
- increase recv buffers from 6 to 9 (should help decrease dropped packets)
- add short delay to detect routine (makes cards detectable on fast machines)
- use eth_copy_and_sum for receiving packets
It passed basic stress testing with multiple, simultaneous ftp transfers.
Know bugs:
- Multicast still doesn't work at all (I have patches that seem to fix this but they
have other problems)
- Still drops packets under heavy traffic (can be reduced further by lowering MTU on
interface)
- Sometimes requires host to send a packet before it starts receiving (I can't
reproduce this on my equipment anymore, but needs more testing)
Anyone with this card please test and report back.
Later,
Tom
--- 3c523.c.241 Fri Feb 2 21:09:20 2001
+++ 3c523.c Sun Feb 4 21:02:18 2001
@@ -148,9 +148,9 @@
#define RECV_BUFF_SIZE 1524 /* slightly oversized */
#define XMIT_BUFF_SIZE 1524 /* slightly oversized */
-#define NUM_XMIT_BUFFS 4 /* config for both, 8K and 16K shmem */
-#define NUM_RECV_BUFFS_8 1/* config for 8K shared mem */
-#define NUM_RECV_BUFFS_16 6/* config for 16K shared mem */
+#define NUM_XMIT_BUFFS 1 /* config for both, 8K and 16K shmem */
+#define NUM_RECV_BUFFS_8 4/* config for 8K shared mem */
+#define NUM_RECV_BUFFS_16 9/* config for 16K shared mem */
#if (NUM_XMIT_BUFFS == 1)
#define NO_NOPCOMMANDS/* only possible with NUM_XMIT_BUFFS=1 */
@@ -303,13 +303,13 @@
char *iscp_addrs[2];
int i = 0;
-
p-base = where + size - 0x0100;
-
p-memtop = phys_to_virt(where) + size;
-
p-scp = (struct scp_struct *)phys_to_virt(p-base + SCP_DEFAULT_ADDRESS);
+
p-base = (unsigned long) bus_to_virt((unsigned long)where) + size - 0x0100;
+
p-memtop = bus_to_virt((unsigned long)where) + size;
+
p-scp = (struct scp_struct *)(p-base + SCP_DEFAULT_ADDRESS);
memset((char *) p-scp, 0, sizeof(struct scp_struct));
p-scp-sysbus = SYSBUSVAL; /* 1 = 8Bit-Bus, 0 = 16 Bit */
-
iscp_addrs[0] = phys_to_virt(where);
+
iscp_addrs[0] = bus_to_virt((unsigned long)where);
iscp_addrs[1] = (char *) p-scp - sizeof(struct iscp_struct);
for (i = 0; i 2; i++) {
@@ -325,6 +325,7 @@
/* apparently, you sometimes have to kick the 82586 twice... */
elmc_id_attn586();
+
DELAY(1);
if (p-iscp-busy) {/* i82586 clears 'busy' after successful init
*/
return 0;
@@ -344,8 +345,8 @@
elmc_id_reset586();
DELAY(2);
-
p-scp = (struct scp_struct *) phys_to_virt(p-base + SCP_DEFAULT_ADDRESS);
-
p-scb = (struct scb_struct *) phys_to_virt(dev-mem_start);
+
p-scp = (struct scp_struct *) (p-base + SCP_DEFAULT_ADDRESS);
+
p-scb = (struct scb_struct *) bus_to_virt(dev-mem_start);
p-iscp = (struct iscp_struct *) ((char *) p-scp - sizeof(struct
iscp_struct));
memset((char *) p-iscp, 0, sizeof(struct iscp_struct));
@@ -518,7 +519,8 @@
}
dev-mem_end = dev-mem_start + size; /* set mem_end showed by 'ifconfig' */
-
((struct priv *) (dev-priv))-base = dev-mem_start + size - 0x0100;
+
((struct priv *) (dev-priv))-memtop = bus_to_virt(dev-mem_start) + size;
+
((struct priv *) (dev-priv))-base = (unsigned long) bus_to_virt(dev-mem_start) +
size - 0x0100;
alloc586(dev);
elmc_id_reset586(); /* make sure it doesn't generate spurious ints */
@@ -944,7 +946,8 @@
if (skb != NULL) {
skb-dev = dev;
skb_reserve(skb, 2);/* 16 byte alignment */
-
memcpy(skb_put(skb, totlen), (u8
*)phys_to_virt(p-base) + (unsigned long) rbd-buffer, totlen);
+
skb_put(skb,totlen);
+
eth_copy_and_sum(skb, (char *) p-base+(unsigned long)
rbd-buffer,totlen,0);
skb-protocol = eth_type_trans(skb, dev);
netif_rx(skb);
p-stats.rx_packets++;
@@ -1086,6 +1089,7 @@
static int elmc_send_packet(struct sk_buff *skb, struct net_device *dev)
{
int len;
+
int i;
#ifndef NO_NOPCOMMANDS
int next_nop;
#endif
-
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: 3Com 3c523 in IBM PS/2 9585: Can't load module in kernel 2.4.1
> > > eth0: memprobe, Can't find memory at 0xc! > > > 3c523.c: No 3c523 cards found > > > > Yep. Most probably it needs munging to use isa_memcpy_fromio and the like > > or ioremap. > > Right... OK I'll leave that to someone else I have patches that I believe fix this, but their own my box at home that I can't get do right now. When I get back from LinuxWorld tomorrow I'll pull them off and post them. > > Are you willing to be test victim for fixes ? > > Yes. > And if you think the NFS problems might be fixable, I'll be pleased to > keep the card out of the bucket. My patches also include changes that should improve this, but I doubt it will eliminate the problem. The basic thing here is that it's a horrid card in regards to performance and most of them only have 8K of buffer, it's just too easy to overrun the buffer, especially since the default is to allocate 4 transmit and 1 receive buffer (or 6 receive buffers it your lucky enough to have a 16K card). Because of this the card drops packets like crazy, which is bad for NFS, especially over UDP. My patches basically change the buffer allocation to only a single transmit buffer and whatever is left to receive buffers, this puts the card in a different mode of operation which seems to allow it to almost keep up. For me, this made the card usable, I still get drops, but their now much lower. I'm not sure this is your problem, but I bet if you look at you ifconfig stats when your having the problem you'll see lots of dropped packets. Even if you don't use the card, it's be nice to have another user test it out before I submit the patch. Later, Tom - 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: 3Com 3c523 in IBM PS/2 9585: Can't load module in kernel 2.4.1
eth0: memprobe, Can't find memory at 0xc! 3c523.c: No 3c523 cards found Yep. Most probably it needs munging to use isa_memcpy_fromio and the like or ioremap. Right... OK I'll leave that to someone else I have patches that I believe fix this, but their own my box at home that I can't get do right now. When I get back from LinuxWorld tomorrow I'll pull them off and post them. Are you willing to be test victim for fixes ? Yes. And if you think the NFS problems might be fixable, I'll be pleased to keep the card out of the bucket. My patches also include changes that should improve this, but I doubt it will eliminate the problem. The basic thing here is that it's a horrid card in regards to performance and most of them only have 8K of buffer, it's just too easy to overrun the buffer, especially since the default is to allocate 4 transmit and 1 receive buffer (or 6 receive buffers it your lucky enough to have a 16K card). Because of this the card drops packets like crazy, which is bad for NFS, especially over UDP. My patches basically change the buffer allocation to only a single transmit buffer and whatever is left to receive buffers, this puts the card in a different mode of operation which seems to allow it to almost keep up. For me, this made the card usable, I still get drops, but their now much lower. I'm not sure this is your problem, but I bet if you look at you ifconfig stats when your having the problem you'll see lots of dropped packets. Even if you don't use the card, it's be nice to have another user test it out before I submit the patch. Later, Tom - 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: Possible Bug: drivers/sound/maestro.c
> I haven't done any sound stuff with 2.4 on my Dell Inspiron 5000e, but I > have this problem (or a similar one, anyway -- sometimes the sound becomes > distorted or comes only through one speaker) under both Linux 2.2 and > Win2K. If it was just Linux, I'd assume it was a driver problem, but the > fact that I'm getting very similar misbehavior from both Linux and Win2K Just to add a note, my Dell Inspiron 5000e also exhibits this problem under both Linux and W2K. I've never heard it happen under Win98 but I spend very little time actually running that OS (I occasionally boot it to troubleshoot client issues that are still running on Win95/98) compared to the others so that probably doesn't mean a lot. I've also tried the ALSA drivers on this machine but have never has success in even getting their Maestro driver to work on this machine. I do have ALSA drivers working on several desktop machines at home and have always had good success with them, but they fail miserably for me on this laptop. I haven't tried the absolute latest version released earlier this week though, maybe over the weekend. > (I don't have Win98 or ME on the machine, so I can't test that) makes me > really wonder... It makes me wonder as well, maybe I'll try to force myself to use Win98 for a while and see if I can force the problem to occur there as well. Later, Tom - 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: Possible Bug: drivers/sound/maestro.c
I haven't done any sound stuff with 2.4 on my Dell Inspiron 5000e, but I have this problem (or a similar one, anyway -- sometimes the sound becomes distorted or comes only through one speaker) under both Linux 2.2 and Win2K. If it was just Linux, I'd assume it was a driver problem, but the fact that I'm getting very similar misbehavior from both Linux and Win2K Just to add a note, my Dell Inspiron 5000e also exhibits this problem under both Linux and W2K. I've never heard it happen under Win98 but I spend very little time actually running that OS (I occasionally boot it to troubleshoot client issues that are still running on Win95/98) compared to the others so that probably doesn't mean a lot. I've also tried the ALSA drivers on this machine but have never has success in even getting their Maestro driver to work on this machine. I do have ALSA drivers working on several desktop machines at home and have always had good success with them, but they fail miserably for me on this laptop. I haven't tried the absolute latest version released earlier this week though, maybe over the weekend. (I don't have Win98 or ME on the machine, so I can't test that) makes me really wonder... It makes me wonder as well, maybe I'll try to force myself to use Win98 for a while and see if I can force the problem to occur there as well. Later, Tom - 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: eepro100 problems in 2.4.0
> I have doing some testing with kernel 2.4 and I have had constant problems > with the eepro100 driver. Under 2.2 it works perfectly but under 2.4 I am > unable to use more than one card in a server and when I do use one card I > get errors stating that eth0 reports no recources. Has anyone else seen > this kind of problem? I had a similar problem with a server that had dual embedded eepro100 adapters however selecting the 'Enable Power Management (EXPERIMENTAL)' option for the eepro100 seemed to make the problem go away. I don't really know why but it might be worth trying if it wasn't already selected. Later, Tom - 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: eepro100 problems in 2.4.0
I have doing some testing with kernel 2.4 and I have had constant problems with the eepro100 driver. Under 2.2 it works perfectly but under 2.4 I am unable to use more than one card in a server and when I do use one card I get errors stating that eth0 reports no recources. Has anyone else seen this kind of problem? I had a similar problem with a server that had dual embedded eepro100 adapters however selecting the 'Enable Power Management (EXPERIMENTAL)' option for the eepro100 seemed to make the problem go away. I don't really know why but it might be worth trying if it wasn't already selected. Later, Tom - 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: No SCSI Ultra 160 with Adaptec Controller
> Actually, aren't a number of newer drives getting upwards of 30MB/s? > Well, at 80MB/sec these drives are able to come in at an average of about 34MB/s across the board. > > Therefore, you only exceed the 80MB/sec bus speed if you > > have more than 4 disks all doing maximum I/O at the same time. Since the > > PowerApp.web 100 has at most 2 disks internally, you really shouldn't see > > any significant performance difference. I wouldn't dare argue that I'd get some huge performance boost, but I am running software raid1 on multiple spindles (we have some drives attached externally) so it should help some. Also, this unit is doing heavy read/write of small files and the lower latency, and burstable transfers do help some. I temporarily disabled that code and the increase in IO's per second is measurable, though not earth shattering, but I was afraid to leave it that way because fast corrupted data is worth much less that only slightly slower good data. It was really just an issue of if the code still needed to be there. Workarounds that are put in as temporary have a tendency to never get revisited until someone brings them up, and on top of that they make Linux look sloppy to me (the same drives work correctly at Ultra160 under that other OS, or at least appear to). I know it won't make a huge difference to me, but if some user has a 12 disk RAID array full of Quantum disks it will make a big difference to them. Later, Tom - 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: No SCSI Ultra 160 with Adaptec Controller
Actually, aren't a number of newer drives getting upwards of 30MB/s? Well, at 80MB/sec these drives are able to come in at an average of about 34MB/s across the board. Therefore, you only exceed the 80MB/sec bus speed if you have more than 4 disks all doing maximum I/O at the same time. Since the PowerApp.web 100 has at most 2 disks internally, you really shouldn't see any significant performance difference. I wouldn't dare argue that I'd get some huge performance boost, but I am running software raid1 on multiple spindles (we have some drives attached externally) so it should help some. Also, this unit is doing heavy read/write of small files and the lower latency, and burstable transfers do help some. I temporarily disabled that code and the increase in IO's per second is measurable, though not earth shattering, but I was afraid to leave it that way because fast corrupted data is worth much less that only slightly slower good data. It was really just an issue of if the code still needed to be there. Workarounds that are put in as temporary have a tendency to never get revisited until someone brings them up, and on top of that they make Linux look sloppy to me (the same drives work correctly at Ultra160 under that other OS, or at least appear to). I know it won't make a huge difference to me, but if some user has a 12 disk RAID array full of Quantum disks it will make a big difference to them. Later, Tom - 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/
No SCSI Ultra 160 with Adaptec Controller
Hi All, While trying to determine why my SCSI Ultra 160 drives don't work on my Dell PowerApp.Web 100 I noticed this section of code: /* * This is needed to work around a sequencer bug for now. Regardless * of the controller in use, if we have a Quantum drive, we need to * limit the speed to 80MByte/sec. As soon as I get a fixed version * of the sequencer, this code will get yanked. */ if(!strncmp(buffer + 8, "QUANTUM", 7) && p->transinfo[tindex].goal_options ) Since this machine has Quantum drives I guess this is my problem. Does anyone know if this code is still actually neccessary? It seems it's been there a while. It's dissapointing to not get full performance out of the hardware you have. Thanks, Tom - 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/
No SCSI Ultra 160 with Adaptec Controller
Hi All, While trying to determine why my SCSI Ultra 160 drives don't work on my Dell PowerApp.Web 100 I noticed this section of code: /* * This is needed to work around a sequencer bug for now. Regardless * of the controller in use, if we have a Quantum drive, we need to * limit the speed to 80MByte/sec. As soon as I get a fixed version * of the sequencer, this code will get yanked. */ if(!strncmp(buffer + 8, "QUANTUM", 7) p-transinfo[tindex].goal_options ) Since this machine has Quantum drives I guess this is my problem. Does anyone know if this code is still actually neccessary? It seems it's been there a while. It's dissapointing to not get full performance out of the hardware you have. Thanks, Tom - 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: Xircom problems with test9-preX
Quoting Andrew Morton <[EMAIL PROTECTED]>: > But it broke yours completely, so I guess the hunk should be backed out > until David has a chance to do a full merge. Are you able to test with > the latest pcmcia-cs package? > > A number of people (esp. David) have spent a lot of time trying to make > the Xircom driver work correctly. It's being a real problem. I will try to test the latest pcmcia-cs package shortly and report my findings later this afternoon. Is there a better location to report the issues for this driver? Later, Tom - 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/
Xircom problems with test9-preX
Hi all, My Xircom RBEM56G-100 almost completely stops working in the latest test9-pre8 and pre9 versions. It will still get an IP address via DHCP, but that's it, no pings or anything. It works mostly correctly with test8 (quits responding when leaving promisuous mode, and seems to hang under heavy load/collisions, but these are problems you can usually live with). Backing out the attached patch returns it to the previous, mostly working condition. Later, Tom xircom_tulip_cb.patch
Xircom problems with test9-preX
Hi all, My Xircom RBEM56G-100 almost completely stops working in the latest test9-pre8 and pre9 versions. It will still get an IP address via DHCP, but that's it, no pings or anything. It works mostly correctly with test8 (quits responding when leaving promisuous mode, and seems to hang under heavy load/collisions, but these are problems you can usually live with). Backing out the attached patch returns it to the previous, mostly working condition. Later, Tom xircom_tulip_cb.patch
Re: Xircom problems with test9-preX
Quoting Andrew Morton [EMAIL PROTECTED]: But it broke yours completely, so I guess the hunk should be backed out until David has a chance to do a full merge. Are you able to test with the latest pcmcia-cs package? A number of people (esp. David) have spent a lot of time trying to make the Xircom driver work correctly. It's being a real problem. I will try to test the latest pcmcia-cs package shortly and report my findings later this afternoon. Is there a better location to report the issues for this driver? Later, Tom - 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/
APM Problems
Hi All, I'm having a problem related to APM on my Dell Inspiron 5000e (just arrived a few days ago). I installed Redhat 7.0 and upon reboot was immediately greeted by scrolling oops screens. The system did boot on up and upon further examintation I found the errors were caused by the attempt to start apmd. Acutally, any access to /proc/apm would generate a non-fatal oops (general protection fault). I compiled a standard 2.2.17 and 2.4.0-test9-pre7 but both experience exactly the same symptom, any access to /proc/apm and you get an oops. A check of the linux laptop list indicated that other owners of the Inspiron 5000e have this same problem so I thought it might be worthy to report here. I did try ACPI support in 2.4.0-test9-pre7 and was able to get it to work, at least in regards to sleep and resume, but I loose functions like battery alerts (it doesn't appear the current linux acpi supports battery status, but I could be brain dead here). Anyway, all this worked fine on my older 5000, and on my APM desktop at home, so it does seem to be somewhat unique to this model Dell. Any thoughts on how to debug this. I'll gladly gather oops info and post it here, or help in any other way. Any other thoughts? Later, Tom - 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/
APM Problems
Hi All, I'm having a problem related to APM on my Dell Inspiron 5000e (just arrived a few days ago). I installed Redhat 7.0 and upon reboot was immediately greeted by scrolling oops screens. The system did boot on up and upon further examintation I found the errors were caused by the attempt to start apmd. Acutally, any access to /proc/apm would generate a non-fatal oops (general protection fault). I compiled a standard 2.2.17 and 2.4.0-test9-pre7 but both experience exactly the same symptom, any access to /proc/apm and you get an oops. A check of the linux laptop list indicated that other owners of the Inspiron 5000e have this same problem so I thought it might be worthy to report here. I did try ACPI support in 2.4.0-test9-pre7 and was able to get it to work, at least in regards to sleep and resume, but I loose functions like battery alerts (it doesn't appear the current linux acpi supports battery status, but I could be brain dead here). Anyway, all this worked fine on my older 5000, and on my APM desktop at home, so it does seem to be somewhat unique to this model Dell. Any thoughts on how to debug this. I'll gladly gather oops info and post it here, or help in any other way. Any other thoughts? Later, Tom - 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/
