Hi!
> hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> ide1: unexpected interrupt, status=0x58, count=1
> hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> hdc: drive not ready for command
>
> all with the same timestamp in the syslog. (IRQ
Jens Axboe wrote:
> You don't need a slow disk, it's trivial to provoke 256 sector sized
> request on even the fastest disk available. People hit it all the time,
> just with working drives...
Here is an update on the 255 vs 256 IDE issue. As Jens said, if it
screws up on every 256, then I shou
On Sun, 18 Mar 2001, Linus Torvalds wrote:
>
>
> On Mon, 19 Mar 2001 [EMAIL PROTECTED] wrote:
> >
> > Agreed. That would be a trivially easy bug in the firmware, limiting to
> > 255 sectors seems safer.
> >
> > Linus
> >
> > Yes, possibly.
> > I checked old standards, and se
On Mon, 19 Mar 2001 [EMAIL PROTECTED] wrote:
>
> Agreed. That would be a trivially easy bug in the firmware, limiting to
> 255 sectors seems safer.
>
> Linus
>
> Yes, possibly.
> I checked old standards, and see that "0 means 256 as a sector count"
> is already in ATA-1.
Yes
On Sun, 18 Mar 2001, Jens Axboe wrote:
>
> The 256 is _not_ a bug in the driver, it's more likely a bug in your
> drive. 256 is a perfectly legal transfer size. That said, maybe it is
> a good idea to leave it at 255 just for safety on drives not handling
> 0 sectors == 12
On Sun, 18 Mar 2001, Linus Torvalds wrote:
>
>
> On Sun, 18 Mar 2001, Jens Axboe wrote:
> >
> > The 256 is _not_ a bug in the driver, it's more likely a bug in your
> > drive. 256 is a perfectly legal transfer size. That said, maybe it is
> > a good idea to leave it at 255 just for safety on dr
On Sun, 18 Mar 2001, Jens Axboe wrote:
>
> The 256 is _not_ a bug in the driver, it's more likely a bug in your
> drive. 256 is a perfectly legal transfer size. That said, maybe it is
> a good idea to leave it at 255 just for safety on drives not handling
> 0 sectors == 128kB transfer.
Agreed.
On Sun, Mar 18 2001, Paul Gortmaker wrote:
> There is a potentially serious bug in ide-probe.c in which max_sectors
> is set to 256 instead of 255. I am surprised that this hasn't bit anyone
> else yet. Perhaps because you need a disk that is slow in comparison to
> the host in order for the qu
There is a potentially serious bug in ide-probe.c in which max_sectors
is set to 256 instead of 255. I am surprised that this hasn't bit anyone
else yet. Perhaps because you need a disk that is slow in comparison to
the host in order for the queue to climb up to and then hit the 256, at
which p
9 matches
Mail list logo
