Re: 2.6.20*: PATA DMA timeout, hangs (2)
Alistair John Strachan wrote: On Monday 12 March 2007 13:25, Frank van Maarseveen wrote: [snip] So, are /dev/hd* going to disappear in a few years? iow, does it make sense to _slowly_ start to migrate to /dev/sd*? How would you propose doing this? I'm sure modern distros with an initrd/initramfs probably already do some sort of root detection. Doesn't fix the fstab issue, but I suppose this could be auto-generated too. The problem is there's no plan B in case of any troubles except rename everything back again to boot an old kernel. I doubt this matters for distributors, as they'll simply switch over when you upgrade the distro, and the earliest supported kernel will be the one that shipped with the newer version. I accept that it's a bit of a drag, but it's better to have a standard naming convention for all disks, isn't it? The solution is quite simple. Use the LABEL= trick or other methods to uniquely identify the partition regardless how it's connected. Most modern distributions are already doing this. -- tejun - 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.6.20*: PATA DMA timeout, hangs (2)
Alistair John Strachan wrote: On Monday 12 March 2007 13:25, Frank van Maarseveen wrote: [snip] So, are /dev/hd* going to disappear in a few years? iow, does it make sense to _slowly_ start to migrate to /dev/sd*? How would you propose doing this? I'm sure modern distros with an initrd/initramfs probably already do some sort of root detection. Doesn't fix the fstab issue, but I suppose this could be auto-generated too. The problem is there's no plan B in case of any troubles except rename everything back again to boot an old kernel. I doubt this matters for distributors, as they'll simply switch over when you upgrade the distro, and the earliest supported kernel will be the one that shipped with the newer version. I accept that it's a bit of a drag, but it's better to have a standard naming convention for all disks, isn't it? The solution is quite simple. Use the LABEL= trick or other methods to uniquely identify the partition regardless how it's connected. Most modern distributions are already doing this. -- tejun - 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.6.20*: PATA DMA timeout, hangs (2)
On Tuesday 13 March 2007, Frank van Maarseveen wrote: > On Mon, Mar 12, 2007 at 09:40:25PM +0100, Bartlomiej Zolnierkiewicz wrote: > > > > Hi, > > > > On Monday 12 March 2007, Frank van Maarseveen wrote: > > > On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote: > > > > > > > > Hi, > > > > > > > > Could you check if this is the same problem as this one: > > > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8169 > > > > > > Looks like it except that I don't see "lost interrupt" messages here. So, > > > it might be something different (I don't know). > > > > From the first mail: > > > > hda: max request size: 128KiB > > hda: 40021632 sectors (20491 MB) w/2048KiB Cache, CHS=39704/16/63 > > hda: cache flushes not supported > > hda: hda1 hda2 hda4 > > > > It seems that DMA is not used by default (CONFIG_IDEDMA_PCI_AUTO=n), > > so this is probably exactly the same issue. > > > > Please try the patch attached to the bugzilla bug entry. > > 2.6.20.2 rejects this patch and I don't see a way to apply it by hand: > ide_set_dma() isn't there, nothing seems to match. The patch is for 2.6.21-rc3, sorry for not making it clear. Bart - 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.6.20*: PATA DMA timeout, hangs (2)
On Mon, Mar 12, 2007 at 09:40:25PM +0100, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday 12 March 2007, Frank van Maarseveen wrote: > > On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote: > > > > > > Hi, > > > > > > Could you check if this is the same problem as this one: > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8169 > > > > Looks like it except that I don't see "lost interrupt" messages here. So, > > it might be something different (I don't know). > > From the first mail: > > hda: max request size: 128KiB > hda: 40021632 sectors (20491 MB) w/2048KiB Cache, CHS=39704/16/63 > hda: cache flushes not supported > hda: hda1 hda2 hda4 > > It seems that DMA is not used by default (CONFIG_IDEDMA_PCI_AUTO=n), > so this is probably exactly the same issue. > > Please try the patch attached to the bugzilla bug entry. 2.6.20.2 rejects this patch and I don't see a way to apply it by hand: ide_set_dma() isn't there, nothing seems to match. -- Frank - 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.6.20*: PATA DMA timeout, hangs (2)
On Mon, Mar 12, 2007 at 09:40:25PM +0100, Bartlomiej Zolnierkiewicz wrote: Hi, On Monday 12 March 2007, Frank van Maarseveen wrote: On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote: Hi, Could you check if this is the same problem as this one: http://bugzilla.kernel.org/show_bug.cgi?id=8169 Looks like it except that I don't see lost interrupt messages here. So, it might be something different (I don't know). From the first mail: hda: max request size: 128KiB hda: 40021632 sectors (20491 MB) w/2048KiB Cache, CHS=39704/16/63 hda: cache flushes not supported hda: hda1 hda2 hda4 It seems that DMA is not used by default (CONFIG_IDEDMA_PCI_AUTO=n), so this is probably exactly the same issue. Please try the patch attached to the bugzilla bug entry. 2.6.20.2 rejects this patch and I don't see a way to apply it by hand: ide_set_dma() isn't there, nothing seems to match. -- Frank - 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.6.20*: PATA DMA timeout, hangs (2)
On Tuesday 13 March 2007, Frank van Maarseveen wrote: On Mon, Mar 12, 2007 at 09:40:25PM +0100, Bartlomiej Zolnierkiewicz wrote: Hi, On Monday 12 March 2007, Frank van Maarseveen wrote: On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote: Hi, Could you check if this is the same problem as this one: http://bugzilla.kernel.org/show_bug.cgi?id=8169 Looks like it except that I don't see lost interrupt messages here. So, it might be something different (I don't know). From the first mail: hda: max request size: 128KiB hda: 40021632 sectors (20491 MB) w/2048KiB Cache, CHS=39704/16/63 hda: cache flushes not supported hda: hda1 hda2 hda4 It seems that DMA is not used by default (CONFIG_IDEDMA_PCI_AUTO=n), so this is probably exactly the same issue. Please try the patch attached to the bugzilla bug entry. 2.6.20.2 rejects this patch and I don't see a way to apply it by hand: ide_set_dma() isn't there, nothing seems to match. The patch is for 2.6.21-rc3, sorry for not making it clear. Bart - 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.6.20*: PATA DMA timeout, hangs (2)
Hi, On Monday 12 March 2007, Frank van Maarseveen wrote: > On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote: > > > > Hi, > > > > Could you check if this is the same problem as this one: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8169 > > Looks like it except that I don't see "lost interrupt" messages here. So, > it might be something different (I don't know). >From the first mail: hda: max request size: 128KiB hda: 40021632 sectors (20491 MB) w/2048KiB Cache, CHS=39704/16/63 hda: cache flushes not supported hda: hda1 hda2 hda4 It seems that DMA is not used by default (CONFIG_IDEDMA_PCI_AUTO=n), so this is probably exactly the same issue. Please try the patch attached to the bugzilla bug entry. Thanks, Bart - 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.6.20*: PATA DMA timeout, hangs (2)
On Monday 12 March 2007 13:25, Frank van Maarseveen wrote: [snip] > So, are /dev/hd* going to disappear in a few years? iow, does it make > sense to _slowly_ start to migrate to /dev/sd*? How would you propose doing this? I'm sure modern distros with an initrd/initramfs probably already do some sort of root detection. Doesn't fix the fstab issue, but I suppose this could be auto-generated too. > The problem is there's no plan B in case of any troubles except rename > everything back again to boot an old kernel. I doubt this matters for distributors, as they'll simply switch over when you upgrade the distro, and the earliest supported kernel will be the one that shipped with the newer version. I accept that it's a bit of a drag, but it's better to have a standard naming convention for all disks, isn't it? Glad this is working for you. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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.6.20*: PATA DMA timeout, hangs (2)
On Mon, Mar 12, 2007 at 12:07:18PM +, Alistair John Strachan wrote:
> On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
> > On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
> > > 2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
> > > -d 1 /dev/hda):
> > >
> > > hda: dma_timer_expiry: dma status == 0x20
> > > hda: DMA timeout retry
> > > hda: timeout waiting for DMA
> > > hda: status error: status=0x58 {
> > > DriveReady
> > > SeekComplete
> > > DataRequest
> > > }
> [snip]
> > This system has SATA but there's only one PATA disk
>
> Not a solution, unfortunately, but try disabling CONFIG_IDE and using Alan's
> new PATA drivers. For your Intel systems, this should mean you need only:
>
> CONFIG_ATA_PIIX
>
> For both SATA and PATA support. You'll need the appropriate SCSI modules
> built
> in (if you say =y), i.e. SCSI disk and SCSI CDROM should be built in.
yes, that worked... after booting with root=/dev/sda2 and s/hda/sda/
/etc/fstab /etc/lilo.conf + lilo. didn't mount a /dev/sr0 for a loong
time.
So, are /dev/hd* going to disappear in a few years? iow, does it make
sense to _slowly_ start to migrate to /dev/sd*?
The problem is there's no plan B in case of any troubles except rename
everything back again to boot an old kernel.
--
Frank
-
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.6.20*: PATA DMA timeout, hangs (2)
On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > Could you check if this is the same problem as this one: > > http://bugzilla.kernel.org/show_bug.cgi?id=8169 Looks like it except that I don't see "lost interrupt" messages here. So, it might be something different (I don't know). -- Frank - 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.6.20*: PATA DMA timeout, hangs (2)
Hi,
Could you check if this is the same problem as this one:
http://bugzilla.kernel.org/show_bug.cgi?id=8169
Thanks,
Bart
On Monday 12 March 2007, Frank van Maarseveen wrote:
> On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
> >
> > 2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
> > -d 1 /dev/hda):
> >
> > hda: dma_timer_expiry: dma status == 0x20
> > hda: DMA timeout retry
> > hda: timeout waiting for DMA
> > hda: status error: status=0x58 {
> > DriveReady
> > SeekComplete
> > DataRequest
> > }
>
> I have a totally different PATA based system (P4 HT) with similar symptoms
> except that it seem to recover by switching DMA off during boot after
> 5 errors:
>
> hda: dma_timer_expiry: dma status == 0x20
> hda: DMA timeout retry
> hda: timeout waiting for DMA
> hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: drive not ready for command
> hda: dma_timer_expiry: dma status == 0x20
> hda: DMA timeout retry
> hda: timeout waiting for DMA
> hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: drive not ready for command
> hda: dma_timer_expiry: dma status == 0x20
> hda: DMA timeout retry
> hda: timeout waiting for DMA
> hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: drive not ready for command
> hda: dma_timer_expiry: dma status == 0x20
> hda: DMA timeout retry
> hda: timeout waiting for DMA
> hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: drive not ready for command
> hda: dma_timer_expiry: dma status == 0x20
> hda: DMA timeout retry
> hda: timeout waiting for DMA
> hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hda: drive not ready for command
>
> So in this case it doesn't hang but is not really usable either.
>
> lspci:
> 00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub
> Interface (rev 02)
> 00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev
> 02)
> 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
> Controller #1 (rev 02)
> 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
> Controller #2 (rev 02)
> 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
> Controller #3 (rev 02)
> 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
> Controller #4 (rev 02)
> 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI
> Controller (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
> 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface
> Bridge (rev 02)
> 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE
> Controller (rev 02)
> 00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev
> 02)
> 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller
> (rev 02)
> 00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER
> (ICH5/ICH5R) AC'97 Audio Controller (rev 02)
> 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200]
> (rev a1)
> 02:00.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet
> Controller (rev 05)
>
> This system has SATA but there's only one PATA disk
-
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.6.20*: PATA DMA timeout, hangs (2)
On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
> On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
> > 2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
> > -d 1 /dev/hda):
> >
> > hda: dma_timer_expiry: dma status == 0x20
> > hda: DMA timeout retry
> > hda: timeout waiting for DMA
> > hda: status error: status=0x58 {
> > DriveReady
> > SeekComplete
> > DataRequest
> > }
[snip]
> This system has SATA but there's only one PATA disk
Not a solution, unfortunately, but try disabling CONFIG_IDE and using Alan's
new PATA drivers. For your Intel systems, this should mean you need only:
CONFIG_ATA_PIIX
For both SATA and PATA support. You'll need the appropriate SCSI modules built
in (if you say =y), i.e. SCSI disk and SCSI CDROM should be built in.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
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.6.20*: PATA DMA timeout, hangs (2)
On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda):
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 {
DriveReady
SeekComplete
DataRequest
}
[snip]
This system has SATA but there's only one PATA disk
Not a solution, unfortunately, but try disabling CONFIG_IDE and using Alan's
new PATA drivers. For your Intel systems, this should mean you need only:
CONFIG_ATA_PIIX
For both SATA and PATA support. You'll need the appropriate SCSI modules built
in (if you say =y), i.e. SCSI disk and SCSI CDROM should be built in.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
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.6.20*: PATA DMA timeout, hangs (2)
Hi,
Could you check if this is the same problem as this one:
http://bugzilla.kernel.org/show_bug.cgi?id=8169
Thanks,
Bart
On Monday 12 March 2007, Frank van Maarseveen wrote:
On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda):
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 {
DriveReady
SeekComplete
DataRequest
}
I have a totally different PATA based system (P4 HT) with similar symptoms
except that it seem to recover by switching DMA off during boot after
5 errors:
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hda: drive not ready for command
So in this case it doesn't hang but is not really usable either.
lspci:
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub
Interface (rev 02)
00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev
02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface
Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev
02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller
(rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER
(ICH5/ICH5R) AC'97 Audio Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200]
(rev a1)
02:00.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet
Controller (rev 05)
This system has SATA but there's only one PATA disk
-
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.6.20*: PATA DMA timeout, hangs (2)
On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote: Hi, Could you check if this is the same problem as this one: http://bugzilla.kernel.org/show_bug.cgi?id=8169 Looks like it except that I don't see lost interrupt messages here. So, it might be something different (I don't know). -- Frank - 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.6.20*: PATA DMA timeout, hangs (2)
On Mon, Mar 12, 2007 at 12:07:18PM +, Alistair John Strachan wrote:
On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda):
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 {
DriveReady
SeekComplete
DataRequest
}
[snip]
This system has SATA but there's only one PATA disk
Not a solution, unfortunately, but try disabling CONFIG_IDE and using Alan's
new PATA drivers. For your Intel systems, this should mean you need only:
CONFIG_ATA_PIIX
For both SATA and PATA support. You'll need the appropriate SCSI modules
built
in (if you say =y), i.e. SCSI disk and SCSI CDROM should be built in.
yes, that worked... after booting with root=/dev/sda2 and s/hda/sda/
/etc/fstab /etc/lilo.conf + lilo. didn't mount a /dev/sr0 for a loong
time.
So, are /dev/hd* going to disappear in a few years? iow, does it make
sense to _slowly_ start to migrate to /dev/sd*?
The problem is there's no plan B in case of any troubles except rename
everything back again to boot an old kernel.
--
Frank
-
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.6.20*: PATA DMA timeout, hangs (2)
On Monday 12 March 2007 13:25, Frank van Maarseveen wrote: [snip] So, are /dev/hd* going to disappear in a few years? iow, does it make sense to _slowly_ start to migrate to /dev/sd*? How would you propose doing this? I'm sure modern distros with an initrd/initramfs probably already do some sort of root detection. Doesn't fix the fstab issue, but I suppose this could be auto-generated too. The problem is there's no plan B in case of any troubles except rename everything back again to boot an old kernel. I doubt this matters for distributors, as they'll simply switch over when you upgrade the distro, and the earliest supported kernel will be the one that shipped with the newer version. I accept that it's a bit of a drag, but it's better to have a standard naming convention for all disks, isn't it? Glad this is working for you. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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.6.20*: PATA DMA timeout, hangs (2)
Hi, On Monday 12 March 2007, Frank van Maarseveen wrote: On Mon, Mar 12, 2007 at 01:21:18PM +0100, Bartlomiej Zolnierkiewicz wrote: Hi, Could you check if this is the same problem as this one: http://bugzilla.kernel.org/show_bug.cgi?id=8169 Looks like it except that I don't see lost interrupt messages here. So, it might be something different (I don't know). From the first mail: hda: max request size: 128KiB hda: 40021632 sectors (20491 MB) w/2048KiB Cache, CHS=39704/16/63 hda: cache flushes not supported hda: hda1 hda2 hda4 It seems that DMA is not used by default (CONFIG_IDEDMA_PCI_AUTO=n), so this is probably exactly the same issue. Please try the patch attached to the bugzilla bug entry. Thanks, Bart - 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/
