Re: aacraid: Host adapter reset request. SCSI hang ?
On Sat, 16 Feb 2008 17:38:13 +1100 "Omar Kilani" <[EMAIL PROTECTED]> wrote: > Hi there, > > We're having issues with our Adaptec RAID controller and I was > wondering if anyone would be able to advise on how to go about > resolving them. :) > > The system: > > RHEL 5.1 x86_64 > Kernel 2.6.18-53.1.4.el5 > aacraid 1.1-5[2437]-mh4 (The default module shipped with the RHEL kernel) Hi, Maybe starting there is better : https://www.redhat.com/apps/support/ Best, Francois -- 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: aacraid: Host adapter reset request. SCSI hang ?
On Sat, 16 Feb 2008 17:38:13 +1100 Omar Kilani [EMAIL PROTECTED] wrote: Hi there, We're having issues with our Adaptec RAID controller and I was wondering if anyone would be able to advise on how to go about resolving them. :) The system: RHEL 5.1 x86_64 Kernel 2.6.18-53.1.4.el5 aacraid 1.1-5[2437]-mh4 (The default module shipped with the RHEL kernel) Hi, Maybe starting there is better : https://www.redhat.com/apps/support/ Best, Francois -- 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: Disk schedulers
On Fri, 15 Feb 2008 10:11:26 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-02-15 at 15:57 +0100, Prakash Punnoor wrote: > > On the day of Friday 15 February 2008 Jan Engelhardt hast written: > > > On Feb 14 2008 17:21, Lukas Hejtmanek wrote: > > > >Hello, > > > > > > > >whom should I blame about disk schedulers? > > > > > > Also consider > > > - DMA (e.g. only UDMA2 selected) > > > - aging disk > > > > Nope, I also reported this problem _years_ ago, but till now much hasn't > > changed. Large writes lead to read starvation. > > Yes, I see this often myself. It's like the disk IO queue (I set mine > to 1024) fills up, and pdflush and friends can stuff write requests into > it much more quickly than any other programs can provide read requests. > > CFQ and ionice work very well up until iostat shows average IO queuing > above 1024 (where I set the queue number). I can confirm that as well. This is easily reproductible with dd if=/dev/zero of=somefile bs=2048 for example. After a short while, trying to read the disks takes an awfully long time, even if the dd process is ionice'd. What is worse is that other drives attached to the same controller become unresponsive as well. I use a Dell Perc 5/i (megaraid_sas) with : * 2 SAS 15000 RPM drives, RAID1 => sda * 4 SAS 15000 RPM drives, RAID5 => sdb * 2 SATA 72000 RPM drives, RAID1 => sdc Using dd or mkfs on sdb or sdc makes sda unresponsive as well. Is this expected ? Cheers Francois -- 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: Disk schedulers
On Fri, 15 Feb 2008 10:11:26 -0700 Zan Lynx [EMAIL PROTECTED] wrote: On Fri, 2008-02-15 at 15:57 +0100, Prakash Punnoor wrote: On the day of Friday 15 February 2008 Jan Engelhardt hast written: On Feb 14 2008 17:21, Lukas Hejtmanek wrote: Hello, whom should I blame about disk schedulers? Also consider - DMA (e.g. only UDMA2 selected) - aging disk Nope, I also reported this problem _years_ ago, but till now much hasn't changed. Large writes lead to read starvation. Yes, I see this often myself. It's like the disk IO queue (I set mine to 1024) fills up, and pdflush and friends can stuff write requests into it much more quickly than any other programs can provide read requests. CFQ and ionice work very well up until iostat shows average IO queuing above 1024 (where I set the queue number). I can confirm that as well. This is easily reproductible with dd if=/dev/zero of=somefile bs=2048 for example. After a short while, trying to read the disks takes an awfully long time, even if the dd process is ionice'd. What is worse is that other drives attached to the same controller become unresponsive as well. I use a Dell Perc 5/i (megaraid_sas) with : * 2 SAS 15000 RPM drives, RAID1 = sda * 4 SAS 15000 RPM drives, RAID5 = sdb * 2 SATA 72000 RPM drives, RAID1 = sdc Using dd or mkfs on sdb or sdc makes sda unresponsive as well. Is this expected ? Cheers Francois -- 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] Re: Forcing modes in libata
Hi, On Thu, 10 Jan 2008 16:56:10 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > FD Cami wrote: > > Revised patch attached. > > > > Best, > > > > François > > > > applied. please include signed-off-by lines in the future... Will do. Thanks ! François -- 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] Re: Forcing modes in libata
Hi, On Thu, 10 Jan 2008 16:56:10 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: FD Cami wrote: Revised patch attached. Best, François applied. please include signed-off-by lines in the future... Will do. Thanks ! François -- 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] Re: Forcing modes in libata (was: SATA buffered read VERY slow)
On Sun, 6 Jan 2008 17:27:38 +0100 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > On Sunday 06 January 2008, FD Cami wrote: > > On Sun, 6 Jan 2008 13:36:09 + > > Alan Cox <[EMAIL PROTECTED]> wrote: > > > > > On Sun, 6 Jan 2008 08:03:31 +0300 > > > > > For now you can boot with libata.dma=1 to select DMA on disks > > > > > but not CD > > > > > > > > Great, but why isn't this in the documentation? > > > > > > Send patches > > > > patch attached. > > > > Description : Add libata.dma= to Documentation/kernel-parameters.txt > > > > Found documentation in : > > http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html > > http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html > > > > Signed-off-by: François Cami <[EMAIL PROTECTED]> > > diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt > linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt > --- > linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 > 15:58:54.0 +0100 +++ > linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt 2008-01-06 > 16:11:20.0 +0100 @@ -883,4 +883,11 @@ C2 power state. > + libata.dma= [LIBATA] DMA control > + libata.dma=0 Disable all PATA DMA like > old IDE > > this doesn't seem entirely correct: > > * IDE has "hdx=nodma" so you can disable DMA on per-device basis I think that libata.dma=1 is designed to behave like CONFIG_IDEDMA_ONLYDISK used to. "hdx=nodma" is more fine-grained than this. > * is this really limited to PATA? Alan's original patch took care of PATA. SATA support was added later by Jeff Garzik. Corrected documentation patch attached. > + libata.dma=1 Disk DMA only > + libata.dma=2 ATAPI DMA only > + libata.dma=3 CF DMA only This is also wrong, it should be "libata.dma=4 CF DMA only" Thanks to Zoltan Boszormenyi <[EMAIL PROTECTED]> for catching this mistake. Revised patch attached. Best, François diff -rU4 linux-2.6.24-rc6/Documentation/kernel-parameters.txt linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt --- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 15:58:54.0 +0100 +++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt 2008-01-06 18:46:49.0 +0100 @@ -881,8 +881,16 @@ lapic_timer_c2_ok [X86-32,x86-64,APIC] trust the local apic timer in C2 power state. + libata.dma= [LIBATA] DMA control + libata.dma=0 Disable all PATA and SATA DMA + libata.dma=1 PATA and SATA Disk DMA only + libata.dma=2 ATAPI (CDROM) DMA only + libata.dma=4 Compact Flash DMA only + Combinations also work, so libata.dma=3 enables DMA + for disks and CDROMs, but not CFs. + libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume when set. Format:
[PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY slow)
On Sun, 6 Jan 2008 13:36:09 + Alan Cox <[EMAIL PROTECTED]> wrote: > On Sun, 6 Jan 2008 08:03:31 +0300 > > > For now you can boot with libata.dma=1 to select DMA on disks but > > > not CD > > > > Great, but why isn't this in the documentation? > > Send patches patch attached. Description : Add libata.dma= to Documentation/kernel-parameters.txt Found documentation in : http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html Signed-off-by: François Cami <[EMAIL PROTECTED]> diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt --- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 15:58:54.0 +0100 +++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt 2008-01-06 16:11:20.0 +0100 @@ -883,4 +883,11 @@ C2 power state. + libata.dma= [LIBATA] DMA control + libata.dma=0 Disable all PATA DMA like old IDE + libata.dma=1 Disk DMA only + libata.dma=2 ATAPI DMA only + libata.dma=3 CF DMA only + libata.dma=0,1,3 Combinations also work. + libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume when set.
[PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY slow)
On Sun, 6 Jan 2008 13:36:09 + Alan Cox [EMAIL PROTECTED] wrote: On Sun, 6 Jan 2008 08:03:31 +0300 For now you can boot with libata.dma=1 to select DMA on disks but not CD Great, but why isn't this in the documentation? Send patches patch attached. Description : Add libata.dma= to Documentation/kernel-parameters.txt Found documentation in : http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html Signed-off-by: François Cami [EMAIL PROTECTED] diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt --- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 15:58:54.0 +0100 +++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt 2008-01-06 16:11:20.0 +0100 @@ -883,4 +883,11 @@ C2 power state. + libata.dma= [LIBATA] DMA control + libata.dma=0 Disable all PATA DMA like old IDE + libata.dma=1 Disk DMA only + libata.dma=2 ATAPI DMA only + libata.dma=3 CF DMA only + libata.dma=0,1,3 Combinations also work. + libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume when set.
Re: [PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY slow)
On Sun, 6 Jan 2008 17:27:38 +0100 Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote: On Sunday 06 January 2008, FD Cami wrote: On Sun, 6 Jan 2008 13:36:09 + Alan Cox [EMAIL PROTECTED] wrote: On Sun, 6 Jan 2008 08:03:31 +0300 For now you can boot with libata.dma=1 to select DMA on disks but not CD Great, but why isn't this in the documentation? Send patches patch attached. Description : Add libata.dma= to Documentation/kernel-parameters.txt Found documentation in : http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html Signed-off-by: François Cami [EMAIL PROTECTED] diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt --- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 15:58:54.0 +0100 +++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt 2008-01-06 16:11:20.0 +0100 @@ -883,4 +883,11 @@ C2 power state. + libata.dma= [LIBATA] DMA control + libata.dma=0 Disable all PATA DMA like old IDE this doesn't seem entirely correct: * IDE has hdx=nodma so you can disable DMA on per-device basis I think that libata.dma=1 is designed to behave like CONFIG_IDEDMA_ONLYDISK used to. hdx=nodma is more fine-grained than this. * is this really limited to PATA? Alan's original patch took care of PATA. SATA support was added later by Jeff Garzik. Corrected documentation patch attached. + libata.dma=1 Disk DMA only + libata.dma=2 ATAPI DMA only + libata.dma=3 CF DMA only This is also wrong, it should be libata.dma=4 CF DMA only Thanks to Zoltan Boszormenyi [EMAIL PROTECTED] for catching this mistake. Revised patch attached. Best, François diff -rU4 linux-2.6.24-rc6/Documentation/kernel-parameters.txt linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt --- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 15:58:54.0 +0100 +++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt 2008-01-06 18:46:49.0 +0100 @@ -881,8 +881,16 @@ lapic_timer_c2_ok [X86-32,x86-64,APIC] trust the local apic timer in C2 power state. + libata.dma= [LIBATA] DMA control + libata.dma=0 Disable all PATA and SATA DMA + libata.dma=1 PATA and SATA Disk DMA only + libata.dma=2 ATAPI (CDROM) DMA only + libata.dma=4 Compact Flash DMA only + Combinations also work, so libata.dma=3 enables DMA + for disks and CDROMs, but not CFs. + libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume when set. Format: int
scheduler improvements : 2.6.21 vs 2.6.22-ck1 vs 2.6.23-rc6
Warning: I have not run any benchmarks. One thing I am (more or less) able to measure is my own ability to headshot in some games like UT99. The other thing is to see if flash videos stutter or die under load. Please remember, this is about desktop usage - not numbers. my computer: PIII-S 1400 (512KB L2) TUSL2-C (i815ep) 512MB PC133 FireGL 8800 (~Radeon 8500 128MB) with dri drivers Hello Ingo, LKML, Here are the results of a few informal tests (flash videos, playing UT99, and looping kernel compilation in background). * 2.6.21.5 is OK but interactivity is not good (i.e. I sometimes get "lag" under load). * 2.6.22-ck1 is better, interactivity-wise, but becomes unusable under load (i.e. a kernel compilation + desktop switch breaks flash videos ; UT99 is too slow when compiling too). * 2.6.23-rc6 is... perfect, as good as can be on my old PC. Flash never breaks even on high I/O or compilation load (within reasonable limits). Gaming is great, which wasn't the case before. Thanks for the good work. Best, François - 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/
scheduler improvements : 2.6.21 vs 2.6.22-ck1 vs 2.6.23-rc6
Warning: I have not run any benchmarks. One thing I am (more or less) able to measure is my own ability to headshot in some games like UT99. The other thing is to see if flash videos stutter or die under load. Please remember, this is about desktop usage - not numbers. my computer: PIII-S 1400 (512KB L2) TUSL2-C (i815ep) 512MB PC133 FireGL 8800 (~Radeon 8500 128MB) with dri drivers Hello Ingo, LKML, Here are the results of a few informal tests (flash videos, playing UT99, and looping kernel compilation in background). * 2.6.21.5 is OK but interactivity is not good (i.e. I sometimes get lag under load). * 2.6.22-ck1 is better, interactivity-wise, but becomes unusable under load (i.e. a kernel compilation + desktop switch breaks flash videos ; UT99 is too slow when compiling too). * 2.6.23-rc6 is... perfect, as good as can be on my old PC. Flash never breaks even on high I/O or compilation load (within reasonable limits). Gaming is great, which wasn't the case before. Thanks for the good work. Best, François - 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: Hang in 2.6.23-rc5
On Mon, 3 Sep 2007 04:15:01 +0530 (IST) Satyam Sharma <[EMAIL PROTECTED]> wrote: > On Mon, 3 Sep 2007, Alexey Dobriyan wrote: > > > > Try this from net-2.6 tree: > > > > --- a/net/ipv4/tcp_input.c > > +++ b/net/ipv4/tcp_input.c > > @@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk) > > struct dst_entry *dst = __sk_dst_get(sk); > > u32 rto_min = TCP_RTO_MIN; > > > > - if (dst_metric_locked(dst, RTAX_RTO_MIN)) > > + if (dst && dst_metric_locked(dst, RTAX_RTO_MIN)) > > rto_min = dst->metrics[RTAX_RTO_MIN-1]; > > return rto_min; > > } > > That's my impression as well. That's way too core/busy a codepath to > have a bug in. As I said earlier, almost anybody testing -rc5 is sure > to hit this within a few hours (probably less) -- sad, it greatly > erodes from the usefulness of -rc5 as a release candidate. For the record, I haven't been able to reproduce the lockup with this patch. Cheers François - 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: Hang in 2.6.23-rc5
On Mon, 3 Sep 2007 04:15:01 +0530 (IST) Satyam Sharma [EMAIL PROTECTED] wrote: On Mon, 3 Sep 2007, Alexey Dobriyan wrote: Try this from net-2.6 tree: --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk) struct dst_entry *dst = __sk_dst_get(sk); u32 rto_min = TCP_RTO_MIN; - if (dst_metric_locked(dst, RTAX_RTO_MIN)) + if (dst dst_metric_locked(dst, RTAX_RTO_MIN)) rto_min = dst-metrics[RTAX_RTO_MIN-1]; return rto_min; } That's my impression as well. That's way too core/busy a codepath to have a bug in. As I said earlier, almost anybody testing -rc5 is sure to hit this within a few hours (probably less) -- sad, it greatly erodes from the usefulness of -rc5 as a release candidate. For the record, I haven't been able to reproduce the lockup with this patch. Cheers François - 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: Hang in 2.6.23-rc5
On Sun, 2 Sep 2007 22:38:28 +0200 "Alessandro Suardi" <[EMAIL PROTECTED]> wrote: > On 9/2/07, charles gagalac <[EMAIL PROTECTED]> wrote: > > On 9/2/07, daryll q wrote: > > > Upgraded my kernel from 2.6.23-rc2 to 2.6.23-rc5. > > > > > > System hangs (caps lock and scroll lock leds are both flashing). > > > > > > It *randomly* happens but most of the time during after login to > > > KDE. > > > > > > I have not investigated it yet because I have not tried doing > > > it before. > > > > > > Also the system is really not responding so I can't do much.. > > > Just hope it blue screen so I can send the error code easily :) > > > > i experienced hangs, with the flashing caps and scroll locks as > > you've described, in a few of my later pulls prior to rc5. i > > couldn't reproduce the hangs and my logs didn't show evidence of a > > problem. my system under rc5, so far, hasn't hung on me. > > > > charles > > Oh, I thought I was the only one. I also had a single hang+flashing > Caps & Scroll Lock with -rc5, but haven't had one since. > > I had VMWare Player modules loaded at the time though, and I > recently rebuilt them with the any-any-patch-113 (earlier versions > would not build with very recent kernels). > > -rc4-git2 and -git3 never hung even with VMWare modules loaded. > > So I disabled the autoload of VMWare stuff. The problem has not > reproduced so far. My system is a Dell D610, running updated > Fedora 7, with Intel 915GM video chipset. I've just had a kernel panic, running a vanilla 2.6.23-rc5, no proprietary modules loaded, running X11 under moderate load. 2.6.23-rc[2-4] have been rock solid on the same box. I've reverted to rc4 for now. François - 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: Hang in 2.6.23-rc5
On Sun, 2 Sep 2007 22:38:28 +0200 Alessandro Suardi [EMAIL PROTECTED] wrote: On 9/2/07, charles gagalac [EMAIL PROTECTED] wrote: On 9/2/07, daryll q wrote: Upgraded my kernel from 2.6.23-rc2 to 2.6.23-rc5. System hangs (caps lock and scroll lock leds are both flashing). It *randomly* happens but most of the time during after login to KDE. I have not investigated it yet because I have not tried doing it before. Also the system is really not responding so I can't do much.. Just hope it blue screen so I can send the error code easily :) i experienced hangs, with the flashing caps and scroll locks as you've described, in a few of my later pulls prior to rc5. i couldn't reproduce the hangs and my logs didn't show evidence of a problem. my system under rc5, so far, hasn't hung on me. charles Oh, I thought I was the only one. I also had a single hang+flashing Caps Scroll Lock with -rc5, but haven't had one since. I had VMWare Player modules loaded at the time though, and I recently rebuilt them with the any-any-patch-113 (earlier versions would not build with very recent kernels). -rc4-git2 and -git3 never hung even with VMWare modules loaded. So I disabled the autoload of VMWare stuff. The problem has not reproduced so far. My system is a Dell D610, running updated Fedora 7, with Intel 915GM video chipset. I've just had a kernel panic, running a vanilla 2.6.23-rc5, no proprietary modules loaded, running X11 under moderate load. 2.6.23-rc[2-4] have been rock solid on the same box. I've reverted to rc4 for now. François - 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/
