Re: WARNING : kernel 2.6.11.7 (others) kills megaraid 4e/Si dead
On Wed, 6 Jul 2005, Thomas Backlund wrote: I could check the firmware versions if you want. Yes thanks, please do. megaraid: fw version:[516A] bios version:[H418] megaraid: fw version:[513O] bios version:[H418] At least these versions seem to work just fine. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=-
Re: WARNING : kernel 2.6.11.7 (others) kills megaraid 4e/Si dead
On Wed, 6 Jul 2005, Thomas Backlund wrote: I could check the firmware versions if you want. Yes thanks, please do. megaraid: fw version:[516A] bios version:[H418] megaraid: fw version:[513O] bios version:[H418] At least these versions seem to work just fine. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=-
Re: WARNING : kernel 2.6.11.7 (others) kills megaraid 4e/Si dead
On Tue, 5 Jul 2005, Chris Wright wrote: Any news on this matter? I hvr a PE1850 waiting for kernel upgrade, but I'm afraid to do so now... I can't break my box with tests since it's in active use... For now I'm running a 2.6.8.1 based kernel on the box... Last known good one (that Andy tested) was 2.6.10. His was the only report I've seen, and I haven't found any more details on it. I have several PE1850s running 2.6.11.10 and above. I have never had a megaraid controller die on me. This might be something related to a particular firmware version or setup. I could check the firmware versions if you want. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=-
Re: WARNING : kernel 2.6.11.7 (others) kills megaraid 4e/Si dead
On Tue, 5 Jul 2005, Chris Wright wrote: Any news on this matter? I hvr a PE1850 waiting for kernel upgrade, but I'm afraid to do so now... I can't break my box with tests since it's in active use... For now I'm running a 2.6.8.1 based kernel on the box... Last known good one (that Andy tested) was 2.6.10. His was the only report I've seen, and I haven't found any more details on it. I have several PE1850s running 2.6.11.10 and above. I have never had a megaraid controller die on me. This might be something related to a particular firmware version or setup. I could check the firmware versions if you want. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=-
Re: CPU overheat with 2.2
On Thu, 17 May 2001, Simon Richter wrote: > CPU is a Pentium 166 MMX on an Asus TX97 mainboard, ISA cards are a 3c509 > and a Soundblaster. The Asus TX97 is known to be a CPU toaster. I've replaced dozens of them because of overheating problems. I don't know why the problem seems to come up with Linux though. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPU overheat with 2.2
On Thu, 17 May 2001, Simon Richter wrote: CPU is a Pentium 166 MMX on an Asus TX97 mainboard, ISA cards are a 3c509 and a Soundblaster. The Asus TX97 is known to be a CPU toaster. I've replaced dozens of them because of overheating problems. I don't know why the problem seems to come up with Linux though. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockd trouble
On Tue, 10 Apr 2001, Jussi Hamalainen wrote: >program vers proto port > 102 tcp111 portmapper > 102 udp111 portmapper > 1000211 udp 1024 nlockmgr > 1000213 udp 1024 nlockmgr > 151 udp686 mountd > 152 udp686 mountd > 151 tcp689 mountd > 152 tcp689 mountd > 132 udp 2049 nfs > 132 tcp 2049 nfs Duhh. Obviously I should have read the documentation before bashing my head against the wall. I wasn't running statd. Got it working now, sorry about that. I do have a question about lockd. How do I get it back if I need to restart portmap? Running rpc.lockd doesn't seem to have any effect whatsoever on the listed rpc services and I can't just reload the module since nfs depends on it. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lockd trouble
I have two PCs running Slackware 7.1. I can't get lockd to work properly with NFS: Apr 10 21:03:59 sputnik kernel: nsm_mon_unmon: rpc failed, status=-93 Apr 10 21:03:59 sputnik kernel: lockd: cannot monitor xxx.xxx.xxx.xxx Apr 10 21:03:59 sputnik kernel: lockd: failed to monitor xxx.xxx.xxx.xxx Yet rpcinfo -p gives the following: magellan:~$ rpcinfo -p mir program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 1000211 udp 1024 nlockmgr 1000213 udp 1024 nlockmgr 151 udp686 mountd 152 udp686 mountd 151 tcp689 mountd 152 tcp689 mountd 132 udp 2049 nfs 132 tcp 2049 nfs magellan:~$ rpcinfo -p sputnik program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 1000211 udp 1024 nlockmgr 1000213 udp 1024 nlockmgr 151 udp721 mountd 152 udp721 mountd 151 tcp724 mountd 152 tcp724 mountd 132 udp 2049 nfs 132 tcp 2049 nfs The NFS share in question is mounted as locking. Every time procmail tries to get a kernel lock for a file in my home directory, I get an error as described above. Both boxes are running exactly the same 2.2.19 kernel. Am I doing something wrong or is this a bug? -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lockd trouble
I have two PCs running Slackware 7.1. I can't get lockd to work properly with NFS: Apr 10 21:03:59 sputnik kernel: nsm_mon_unmon: rpc failed, status=-93 Apr 10 21:03:59 sputnik kernel: lockd: cannot monitor xxx.xxx.xxx.xxx Apr 10 21:03:59 sputnik kernel: lockd: failed to monitor xxx.xxx.xxx.xxx Yet rpcinfo -p gives the following: magellan:~$ rpcinfo -p mir program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 1000211 udp 1024 nlockmgr 1000213 udp 1024 nlockmgr 151 udp686 mountd 152 udp686 mountd 151 tcp689 mountd 152 tcp689 mountd 132 udp 2049 nfs 132 tcp 2049 nfs magellan:~$ rpcinfo -p sputnik program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 1000211 udp 1024 nlockmgr 1000213 udp 1024 nlockmgr 151 udp721 mountd 152 udp721 mountd 151 tcp724 mountd 152 tcp724 mountd 132 udp 2049 nfs 132 tcp 2049 nfs The NFS share in question is mounted as locking. Every time procmail tries to get a kernel lock for a file in my home directory, I get an error as described above. Both boxes are running exactly the same 2.2.19 kernel. Am I doing something wrong or is this a bug? -- -=[ Count Zero / TBH - Jussi Hmlinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lockd trouble
On Tue, 10 Apr 2001, Jussi Hamalainen wrote: program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 1000211 udp 1024 nlockmgr 1000213 udp 1024 nlockmgr 151 udp686 mountd 152 udp686 mountd 151 tcp689 mountd 152 tcp689 mountd 132 udp 2049 nfs 132 tcp 2049 nfs Duhh. Obviously I should have read the documentation before bashing my head against the wall. I wasn't running statd. Got it working now, sorry about that. I do have a question about lockd. How do I get it back if I need to restart portmap? Running rpc.lockd doesn't seem to have any effect whatsoever on the listed rpc services and I can't just reload the module since nfs depends on it. -- -=[ Count Zero / TBH - Jussi Hmlinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LFS patch for 2.2.18
Where can I get the LFS patch for 2.2.18? Www.scyld.com doesn't seem to be carrying it anymore. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ipchains blocking port 65535
On Wed, 17 Jan 2001, Tony Gale wrote: > It looks like this is due to the odd way in which ipchains handles > fragments. Try: > > echo 1 > /proc/sys/net/ipv4/ip_always_defrag Thanks, this seems to do the trick. Does this oddity still exist in 2.4? -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ipchains blocking port 65535
There seems to be a bug in ipchains. Matching port 65535 seems to always fail. If I set the chain policy to REJECT or DENY and then add a rule that accepts TCP to/from ports 0:65535, packets going to port 65535 will still be caught by the kernel. Is there a fix for this? It's driving me nuts. The firewall box is a 486 with 3 NICs and is running kernel 2.2.18 vanilla. Here is a piece of the kernel log: Jan 17 15:13:03 galileo kernel: Packet log: forward REJECT eth0 PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00 I=16815 F=0x00B6 T=56 (#25) Jan 17 15:15:03 galileo kernel: Packet log: forward REJECT eth0 PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00 I=19969 F=0x00B6 T=56 (#25) Jan 17 15:17:03 galileo kernel: Packet log: forward REJECT eth0 PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00 I=21869 F=0x00B6 T=56 (#25) And here a piece of my forward chain: ACCEPT tcp -- anywhere myhomenet/27 any -> 1024:65535 ACCEPT udp -- anywhere myhomenet/27 any -> 1024:65535 -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ipchains blocking port 65535
There seems to be a bug in ipchains. Matching port 65535 seems to always fail. If I set the chain policy to REJECT or DENY and then add a rule that accepts TCP to/from ports 0:65535, packets going to port 65535 will still be caught by the kernel. Is there a fix for this? It's driving me nuts. The firewall box is a 486 with 3 NICs and is running kernel 2.2.18 vanilla. Here is a piece of the kernel log: Jan 17 15:13:03 galileo kernel: Packet log: forward REJECT eth0 PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00 I=16815 F=0x00B6 T=56 (#25) Jan 17 15:15:03 galileo kernel: Packet log: forward REJECT eth0 PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00 I=19969 F=0x00B6 T=56 (#25) Jan 17 15:17:03 galileo kernel: Packet log: forward REJECT eth0 PROTO=6 213.173.130.69:65535 xxx.xxx.xxx.xxx:65535 L=44 S=0x00 I=21869 F=0x00B6 T=56 (#25) And here a piece of my forward chain: ACCEPT tcp -- anywhere myhomenet/27 any - 1024:65535 ACCEPT udp -- anywhere myhomenet/27 any - 1024:65535 -- -=[ Count Zero / TBH - Jussi Hmlinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: ipchains blocking port 65535
On Wed, 17 Jan 2001, Tony Gale wrote: It looks like this is due to the odd way in which ipchains handles fragments. Try: echo 1 /proc/sys/net/ipv4/ip_always_defrag Thanks, this seems to do the trick. Does this oddity still exist in 2.4? -- -=[ Count Zero / TBH - Jussi Hmlinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: path MTU bug still there?
On Mon, 1 Jan 2001, Lincoln Dale wrote: > i know that you've said previously that you've increased your MTU beyond > 1500, but can you validate that it is actually working? Yup. At least 1500 byte ICMP echo packets get through the tunnel OK. > alternatively, ensure that your application is capable of enforcing a MSS > <1460 if this is shown to not be the case .. I found a way to work around this problem. I had to tell _ALL_ the hosts on my local network to use an MSS of 576 for the default route (the GRE tunnel). Thus the packets always fit through without fragmentation and the problem is gone (but not solved). If someone has a more elegant solution, please tell me. This one seems to be poison for the Windows boxes on my network. :I -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: path MTU bug still there?
On Sun, 31 Dec 2000, Mikael Abrahamsson wrote: > When the linux box does TCP to the outside it'll use the MTU of > the tunnel (default route is the tunnel) and thus works perfectly > (since TCP MSS will be set low enough to fit into the tunnel). In my case I can't access a problematic host even from the router box. > Could it be some kind of incompability at the tunnel level that > make you unable to receive large packets over the tunnel? Could be. The internet connection is a 64k ISDN link. > Have you tcpdump:ed to see if the tunnel packets actually make it > the way they should? I can't snoop the actual tunnel device, because tcpdump and sniffit give me an unknown media type error. Here's a tcpdump from the router box's ethernet device of a HTTP session (using lynx) to www.doomworld.com: 17:19:46.126297 xxx.xxx.xxx.xxx.1029 > 206.96.221.6.80: S 2549095564:2549095564(0) win 32120 (DF) 17:19:46.386142 206.96.221.6.80 > xxx.xxx.xxx.xxx.1029: S 1631828281:1631828281(0) ack 2549095565 win 30660 (DF) 17:19:46.386142 206.96.221.6.80 > xxx.xxx.xxx.xxx.1029: S 1631828281:1631828281(0) ack 2549095565 win 30660 (DF) 17:19:46.386142 xxx.xxx.xxx.xxx.1029 > 206.96.221.6.80: . ack 1 win 32120 (DF) 17:19:46.386142 xxx.xxx.xxx.xxx.1029 > 206.96.221.6.80: P 1:369(368) ack 1 win 32120 (DF) 17:19:46.685963 206.96.221.6.80 > xxx.xxx.xxx.xxx.1029: . ack 369 win 30660 (DF) 17:19:46.685963 206.96.221.6.80 > xxx.xxx.xxx.xxx.1029: . ack 369 win 30660 (DF) And the connection locks up. This happens every time. I don't have access to the Cisco so I can't dump traffic on the remote end of my tunnel. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
path MTU bug still there?
I have an old 486-box acting as a router. It has two NICs and an ISDN adapter. The box is connected to my ISP by ISDN link and has a GRE tunnel running over the ISDN link. The other end of the tunnel is a Cisco router and the tunnel is the default route. I'm experiencing problems identical to the classic MTU problem with IP masquarade where a TCP-connection to/from some hosts becomes jammed after a few bytes have been sent. The only difference is that the problem is reproducable also on the router box itself. I'm running 2.2.18 vanilla and my firewall rules aren't blocking ICMP. The ethernet interfaces and the ISDN link have an MTU of 1500 and the GRE tunnel has an MTU of 1514 (courtesy of Cisco). Has anyone got any bright ideas how to work around this? Would upgrading to 2.4 fix this? -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
path MTU bug still there?
I have an old 486-box acting as a router. It has two NICs and an ISDN adapter. The box is connected to my ISP by ISDN link and has a GRE tunnel running over the ISDN link. The other end of the tunnel is a Cisco router and the tunnel is the default route. I'm experiencing problems identical to the classic MTU problem with IP masquarade where a TCP-connection to/from some hosts becomes jammed after a few bytes have been sent. The only difference is that the problem is reproducable also on the router box itself. I'm running 2.2.18 vanilla and my firewall rules aren't blocking ICMP. The ethernet interfaces and the ISDN link have an MTU of 1500 and the GRE tunnel has an MTU of 1514 (courtesy of Cisco). Has anyone got any bright ideas how to work around this? Would upgrading to 2.4 fix this? -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: path MTU bug still there?
On Sun, 31 Dec 2000, Mikael Abrahamsson wrote: When the linux box does TCP to the outside it'll use the MTU of the tunnel (default route is the tunnel) and thus works perfectly (since TCP MSS will be set low enough to fit into the tunnel). In my case I can't access a problematic host even from the router box. Could it be some kind of incompability at the tunnel level that make you unable to receive large packets over the tunnel? Could be. The internet connection is a 64k ISDN link. Have you tcpdump:ed to see if the tunnel packets actually make it the way they should? I can't snoop the actual tunnel device, because tcpdump and sniffit give me an unknown media type error. Here's a tcpdump from the router box's ethernet device of a HTTP session (using lynx) to www.doomworld.com: 17:19:46.126297 xxx.xxx.xxx.xxx.1029 206.96.221.6.80: S 2549095564:2549095564(0) win 32120 mss 1460,sackOK,timestamp 649398[|tcp] (DF) 17:19:46.386142 206.96.221.6.80 xxx.xxx.xxx.xxx.1029: S 1631828281:1631828281(0) ack 2549095565 win 30660 mss 1460,sackOK,timestamp 91687185[|tcp] (DF) 17:19:46.386142 206.96.221.6.80 xxx.xxx.xxx.xxx.1029: S 1631828281:1631828281(0) ack 2549095565 win 30660 mss 1460,sackOK,timestamp 91687185[|tcp] (DF) 17:19:46.386142 xxx.xxx.xxx.xxx.1029 206.96.221.6.80: . ack 1 win 32120 nop,nop,timestamp 649423 91687185 (DF) 17:19:46.386142 xxx.xxx.xxx.xxx.1029 206.96.221.6.80: P 1:369(368) ack 1 win 32120 nop,nop,timestamp 649423 91687185 (DF) 17:19:46.685963 206.96.221.6.80 xxx.xxx.xxx.xxx.1029: . ack 369 win 30660 nop,nop,timestamp 91687216 649423 (DF) 17:19:46.685963 206.96.221.6.80 xxx.xxx.xxx.xxx.1029: . ack 369 win 30660 nop,nop,timestamp 91687216 649423 (DF) And the connection locks up. This happens every time. I don't have access to the Cisco so I can't dump traffic on the remote end of my tunnel. -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: path MTU bug still there?
On Mon, 1 Jan 2001, Lincoln Dale wrote: i know that you've said previously that you've increased your MTU beyond 1500, but can you validate that it is actually working? Yup. At least 1500 byte ICMP echo packets get through the tunnel OK. alternatively, ensure that your application is capable of enforcing a MSS 1460 if this is shown to not be the case .. I found a way to work around this problem. I had to tell _ALL_ the hosts on my local network to use an MSS of 576 for the default route (the GRE tunnel). Thus the packets always fit through without fragmentation and the problem is gone (but not solved). If someone has a more elegant solution, please tell me. This one seems to be poison for the Windows boxes on my network. :I -- -=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ide-disk: set_multmode?
hdc:hdc: set_multmode: status=0x51 { DriveReady SeekComplete Error }
hdc: set_multmode: error=0x04 { DriveStatusError }
[PTBL] [523/255/63] hdc1 hdc2
This has been happening at least since 2.2.10. It's probably just
something cosmetic, but shouldn't it still be fixed? Running
vanilla-2.2.16 SMP on i686,
hdc: ST34321A, 4103MB w/128kB Cache, CHS=8894/15/63, (U)DMA
Here's a fix someone on this list suggested some time ago. It seems
to make the symptoms disappear, but I'm not sure wether it fixes the
actual problem. From vanilla-2.2.16:
--- ide-disk.c.orig Tue Sep 26 01:58:58 2000
+++ ide-disk.c Tue Sep 26 02:00:36 2000
@@ -856,7 +856,7 @@
drive->mult_req = INITIAL_MULT_COUNT;
if (drive->mult_req > id->max_multsect)
drive->mult_req = id->max_multsect;
- if (drive->mult_req || ((id->multsect_valid & 1) &&
id->multsect))
+ if (drive->mult_req && ((id->multsect_valid & 1) &&
id->multsect))
drive->special.b.set_multmode = 1;
#else
id->multsect = ((id->max_multsect/2) >
1) ? id->max_multsect : 0;
--
-=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
ide-disk: set_multmode?
hdc:hdc: set_multmode: status=0x51 { DriveReady SeekComplete Error }
hdc: set_multmode: error=0x04 { DriveStatusError }
[PTBL] [523/255/63] hdc1 hdc2
This has been happening at least since 2.2.10. It's probably just
something cosmetic, but shouldn't it still be fixed? Running
vanilla-2.2.16 SMP on i686,
hdc: ST34321A, 4103MB w/128kB Cache, CHS=8894/15/63, (U)DMA
Here's a fix someone on this list suggested some time ago. It seems
to make the symptoms disappear, but I'm not sure wether it fixes the
actual problem. From vanilla-2.2.16:
--- ide-disk.c.orig Tue Sep 26 01:58:58 2000
+++ ide-disk.c Tue Sep 26 02:00:36 2000
@@ -856,7 +856,7 @@
drive-mult_req = INITIAL_MULT_COUNT;
if (drive-mult_req id-max_multsect)
drive-mult_req = id-max_multsect;
- if (drive-mult_req || ((id-multsect_valid 1)
id-multsect))
+ if (drive-mult_req ((id-multsect_valid 1)
id-multsect))
drive-special.b.set_multmode = 1;
#else
id-multsect = ((id-max_multsect/2)
1) ? id-max_multsect : 0;
--
-=[ Count Zero / TBH - Jussi Hämäläinen - email [EMAIL PROTECTED] ]=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
