I frequently receive this message in my syslog, apparently
whenever there are periods of significant write activity:
bio too big device ide0(3,7) (256 > 255)
bio too big device ide1(22,6) (256 > 255)
It's worth noting that on this system I have had ongoing trouble
with system stability during write activity as well, using a
wide variety of 2.5.x kernels, even though at the time of this
symptom things are apparently running fine.
Filesystems are all ext3 on top soft raid0 devices. This happens
to be 2.5.64, but it has been happening for at least the last
5-6 versions.
Ideas? Any further debugging output I can provide?
---scott
After a little more digging in drivers/block/ll_rw_blk.c, it
seems that Jens might be the best person to discuss the
following with.
Apparently I have a system that is making bio requests of a size
that exceeds the max sector size for the device? How is that
possible, and more to the point, how can I help get it fixed?
Or am I misinterpreting something?
---scott
On Tuesday 11 March 2003 08:55 pm, scott thomason wrote:
> I frequently receive this message in my syslog, apparently
> whenever there are periods of significant write activity:
>
> bio too big device ide0(3,7) (256 > 255)
> bio too big device ide1(22,6) (256 > 255)
>
> It's worth noting that on this system I have had ongoing
> trouble with system stability during write activity as well,
> using a wide variety of 2.5.x kernels, even though at the time
> of this symptom things are apparently running fine.
>
> Filesystems are all ext3 on top soft raid0 devices. This
> happens to be 2.5.64, but it has been happening for at least
> the last 5-6 versions.
>
> Ideas? Any further debugging output I can provide?
> ---scott
> -
> 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/
On Tuesday March 11, [email protected] wrote:
> I frequently receive this message in my syslog, apparently
> whenever there are periods of significant write activity:
>
> bio too big device ide0(3,7) (256 > 255)
> bio too big device ide1(22,6) (256 > 255)
>
> It's worth noting that on this system I have had ongoing trouble
> with system stability during write activity as well, using a
> wide variety of 2.5.x kernels, even though at the time of this
> symptom things are apparently running fine.
>
> Filesystems are all ext3 on top soft raid0 devices. This happens
> to be 2.5.64, but it has been happening for at least the last
> 5-6 versions.
>
> Ideas? Any further debugging output I can provide?
raid0 doesn't really work well in 2.5 yet.... as you have noticed.
We really need to grab the bio splitting code out of md/dm.c and use
it to split bios that are too big or that cross device boundaries.
any volunteers??
NeilBrown
On Tuesday 11 March 2003 09:37 pm, you wrote:
> raid0 doesn't really work well in 2.5 yet.... as you have
> noticed.
>
> We really need to grab the bio splitting code out of md/dm.c
> and use it to split bios that are too big or that cross device
> boundaries.
>
> any volunteers??
>
> NeilBrown
Given all the grief I've encountered with ALSA, SCSI emulation,
other stuff, and now RAID 0, I would certainly say that the
spelling corrections may have been a little premature. It
doesn't feel ready for 2.6 to me :(
---scott
That has to be a BIO bug or IDE setup bug.
256 sectors is legal and correct for 28-bit addressing.
Cheers,
On Tue, 11 Mar 2003, scott thomason wrote:
> I frequently receive this message in my syslog, apparently
> whenever there are periods of significant write activity:
>
> bio too big device ide0(3,7) (256 > 255)
> bio too big device ide1(22,6) (256 > 255)
>
> It's worth noting that on this system I have had ongoing trouble
> with system stability during write activity as well, using a
> wide variety of 2.5.x kernels, even though at the time of this
> symptom things are apparently running fine.
>
> Filesystems are all ext3 on top soft raid0 devices. This happens
> to be 2.5.64, but it has been happening for at least the last
> 5-6 versions.
>
> Ideas? Any further debugging output I can provide?
> ---scott
> -
> 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/
>
Andre Hedrick
LAD Storage Consulting Group
On Tue, Mar 11 2003, scott thomason wrote:
> After a little more digging in drivers/block/ll_rw_blk.c, it
> seems that Jens might be the best person to discuss the
> following with.
>
> Apparently I have a system that is making bio requests of a size
> that exceeds the max sector size for the device? How is that
> possible, and more to the point, how can I help get it fixed?
>
> Or am I misinterpreting something?
Search the lkml archives, this has been answered before in more detail.
In short, it's a raid bug.
--
Jens Axboe
On Wed, Mar 12 2003, Neil Brown wrote:
> On Tuesday March 11, [email protected] wrote:
> > I frequently receive this message in my syslog, apparently
> > whenever there are periods of significant write activity:
> >
> > bio too big device ide0(3,7) (256 > 255)
> > bio too big device ide1(22,6) (256 > 255)
> >
> > It's worth noting that on this system I have had ongoing trouble
> > with system stability during write activity as well, using a
> > wide variety of 2.5.x kernels, even though at the time of this
> > symptom things are apparently running fine.
> >
> > Filesystems are all ext3 on top soft raid0 devices. This happens
> > to be 2.5.64, but it has been happening for at least the last
> > 5-6 versions.
> >
> > Ideas? Any further debugging output I can provide?
>
>
> raid0 doesn't really work well in 2.5 yet.... as you have noticed.
>
> We really need to grab the bio splitting code out of md/dm.c and use
> it to split bios that are too big or that cross device boundaries.
>
> any volunteers??
I can give it a shot
--
Jens Axboe
On Tue, Mar 11 2003, Andre Hedrick wrote:
>
> That has to be a BIO bug or IDE setup bug.
raid bug
> 256 sectors is legal and correct for 28-bit addressing.
yes, but ide itself limits incoming requests to 255 sectors. so it
cannot get 256 sector requests.
--
Jens Axboe
> On Tue, 11 Mar 2003, scott thomason wrote:
>
> > I frequently receive this message in my syslog, apparently
> > whenever there are periods of significant write activity:
> >
> > bio too big device ide0(3,7) (256 > 255)
> > bio too big device ide1(22,6) (256 > 255)
On Tue, Mar 11, 2003 at 09:01:25PM -0800, Andre Hedrick wrote:
> That has to be a BIO bug or IDE setup bug.
>
> 256 sectors is legal and correct for 28-bit addressing.
Yes, it is. However, Paul Gortmaker reported on his old 700MB
Maxtor 7850 AV that would give errors with 256-sector requests
and work well with 255-sector requests. In a later post he
added that one has to work hard to evoke this error - usually
256-sector requests are fine, but after torturing the disk with
an hour of simultaneous untar and make, an error occurred.
Maybe that is the only disk that gives problems.
Jens replied:
= 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
So that is how this length was limited.
In short: 256 is legal, has always been legal, nothing wrong with it.
But at least one old disk has been discovered that was happier with 255.
Andries
So lets dirty list the one drive by Paul G. and be done.
Can we do that?
Cheers,
On Wed, 12 Mar 2003, Jens Axboe wrote:
> On Tue, Mar 11 2003, Andre Hedrick wrote:
> >
> > That has to be a BIO bug or IDE setup bug.
>
> raid bug
>
> > 256 sectors is legal and correct for 28-bit addressing.
>
> yes, but ide itself limits incoming requests to 255 sectors. so it
> cannot get 256 sector requests.
>
> --
> Jens Axboe
>
Andre Hedrick
LAD Storage Consulting Group
Well that is the first complete explaination of the 255 limit.
That belongs in a simple dirty drive list in ide-probe.c (or whatever the
latest filename is) and then dump this issue for good.
Cheer,
On Wed, 12 Mar 2003, Andries Brouwer wrote:
> > On Tue, 11 Mar 2003, scott thomason wrote:
> >
> > > I frequently receive this message in my syslog, apparently
> > > whenever there are periods of significant write activity:
> > >
> > > bio too big device ide0(3,7) (256 > 255)
> > > bio too big device ide1(22,6) (256 > 255)
>
> On Tue, Mar 11, 2003 at 09:01:25PM -0800, Andre Hedrick wrote:
>
> > That has to be a BIO bug or IDE setup bug.
> >
> > 256 sectors is legal and correct for 28-bit addressing.
>
> Yes, it is. However, Paul Gortmaker reported on his old 700MB
> Maxtor 7850 AV that would give errors with 256-sector requests
> and work well with 255-sector requests. In a later post he
> added that one has to work hard to evoke this error - usually
> 256-sector requests are fine, but after torturing the disk with
> an hour of simultaneous untar and make, an error occurred.
>
> Maybe that is the only disk that gives problems.
>
> Jens replied:
>
> = 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
>
> So that is how this length was limited.
>
> In short: 256 is legal, has always been legal, nothing wrong with it.
> But at least one old disk has been discovered that was happier with 255.
>
> Andries
>
Andre Hedrick
LAD Storage Consulting Group
On Wed, Mar 12 2003, Andre Hedrick wrote:
>
> So lets dirty list the one drive by Paul G. and be done.
> Can we do that?
Who cares, really? There's not much point in doing it, we're talking 248
vs 256 sectors in reality. I think it's a _bad_ idea, lets just keep it
at 255 and avoid silly drive bugs there.
--
Jens Axboe
No that is wrong to force all other drives to under perform because on
one. If you are going to impose 255 then pushi it back to 128 were it is
a single scatter list. This issue has bugged me for years and now that we
know the exact model we apply an exception rule to it.
This is one silly bug that I have heard about.
Cheers,
On Wed, 12 Mar 2003, Jens Axboe wrote:
> On Wed, Mar 12 2003, Andre Hedrick wrote:
> >
> > So lets dirty list the one drive by Paul G. and be done.
> > Can we do that?
>
> Who cares, really? There's not much point in doing it, we're talking 248
> vs 256 sectors in reality. I think it's a _bad_ idea, lets just keep it
> at 255 and avoid silly drive bugs there.
>
> --
> Jens Axboe
>
Andre Hedrick
LAD Storage Consulting Group
On Wed, Mar 12 2003, Andre Hedrick wrote:
>
> No that is wrong to force all other drives to under perform because on
> one. If you are going to impose 255 then pushi it back to 128 were it is
> a single scatter list. This issue has bugged me for years and now that we
> know the exact model we apply an exception rule to it.
>
> This is one silly bug that I have heard about.
See that's the whole point, is there any performance issue with 248 vs
256 sectors? For a 248 sectors vs 256 command alone, I doubt it. The
only problem I see is for potential chop-ups of 248 - 8 - 248 - 8 - 248
- 8 - etc. But due to merging, only the last command should be smaller.
So I still think it's much better stick with the safe choice. Why do you
think it's only one drive that has this bug? It basically boils down to
whether That Other OS uses 256 sector commands or not. If it doesn't, I
wouldn't trust the drives one bit.
And finally, _I'm_ not imposing anything. The limit is driver tweakable,
always has been.
--
Jens Axboe
On Wed, Mar 12 2003, scott thomason wrote:
> Just so everyone knows...these aren't ancient drives I'm talking
> about. One is a 30GB Maxtor 5T030H3, less than two years old
> IIRC, and the other is a 30GB IBM-DTLA-307030 purchased about
> six months ago.
What Andre and I are talking about know is an entirely different issue,
not related to your problem at all.
--
Jens Axboe
Just so everyone knows...these aren't ancient drives I'm talking
about. One is a 30GB Maxtor 5T030H3, less than two years old
IIRC, and the other is a 30GB IBM-DTLA-307030 purchased about
six months ago.
---scott
On Wednesday 12 March 2003 04:07 am, Andre Hedrick wrote:
> No that is wrong to force all other drives to under perform
> because on one. If you are going to impose 255 then pushi it
> back to 128 were it is a single scatter list. This issue has
> bugged me for years and now that we know the exact model we
> apply an exception rule to it.
>
> This is one silly bug that I have heard about.
>
> Cheers,
>
> On Wed, 12 Mar 2003, Jens Axboe wrote:
> > On Wed, Mar 12 2003, Andre Hedrick wrote:
> > > So lets dirty list the one drive by Paul G. and be done.
> > > Can we do that?
> >
> > Who cares, really? There's not much point in doing it, we're
> > talking 248 vs 256 sectors in reality. I think it's a _bad_
> > idea, lets just keep it at 255 and avoid silly drive bugs
> > there.
> >
> > --
> > Jens Axboe
>
> Andre Hedrick
> LAD Storage Consulting Group
On Wed, 2003-03-12 at 09:09, Jens Axboe wrote:
> On Wed, Mar 12 2003, Andre Hedrick wrote:
> >
> > So lets dirty list the one drive by Paul G. and be done.
> > Can we do that?
>
> Who cares, really? There's not much point in doing it, we're talking 248
> vs 256 sectors in reality. I think it's a _bad_ idea, lets just keep it
> at 255 and avoid silly drive bugs there.
255 trashes your performance, 128 will perform far better with most
setups. This is especially true with raid setups. I'd much rather we
got the IDE layer using 256 block writes even if we have to limit it
to more modern drives by some handwaving (8Gb+ say)
Alan
On Wed, Mar 12 2003, Alan Cox wrote:
> On Wed, 2003-03-12 at 09:09, Jens Axboe wrote:
> > On Wed, Mar 12 2003, Andre Hedrick wrote:
> > >
> > > So lets dirty list the one drive by Paul G. and be done.
> > > Can we do that?
> >
> > Who cares, really? There's not much point in doing it, we're talking 248
> > vs 256 sectors in reality. I think it's a _bad_ idea, lets just keep it
> > at 255 and avoid silly drive bugs there.
>
> 255 trashes your performance, 128 will perform far better with most
> setups. This is especially true with raid setups. I'd much rather we
Then go with 128. I'd like to stress again that _if_ you get worse
performance it's not due to the request being a bit smaller, but indeed
because 248 can cause badly aligned requests.
> got the IDE layer using 256 block writes even if we have to limit it
> to more modern drives by some handwaving (8Gb+ say)
Does Windows use 256 sector requests or not? If not, then I'd sure don't
want to do it in Linux, the handwaving doesn't mean anything then.
--
Jens Axboe
On Wed, Mar 12, 2003 at 11:14:14AM +0100, Jens Axboe wrote:
> So I still think it's much better stick with the safe choice. Why do you
> think it's only one drive that has this bug? It basically boils down to
> whether That Other OS uses 256 sector commands or not. If it doesn't, I
> wouldn't trust the drives one bit.
I am not quite sure I understand your reasoning.
We have seen *zero* drives that do not understand 256 sector commands.
Maybe such drives exist, but so far there is zero evidence.
Andries
On Wed, Mar 12 2003, Andries Brouwer wrote:
> On Wed, Mar 12, 2003 at 11:14:14AM +0100, Jens Axboe wrote:
>
> > So I still think it's much better stick with the safe choice. Why do you
> > think it's only one drive that has this bug? It basically boils down to
> > whether That Other OS uses 256 sector commands or not. If it doesn't, I
> > wouldn't trust the drives one bit.
>
> I am not quite sure I understand your reasoning.
> We have seen *zero* drives that do not understand 256 sector commands.
> Maybe such drives exist, but so far there is zero evidence.
Have you read the thread? You are obviously mistaken.
--
Jens Axboe
On Wed, 2003-03-12 at 14:54, scott thomason wrote:
> Just so everyone knows...these aren't ancient drives I'm talking
> about. One is a 30GB Maxtor 5T030H3, less than two years old
> IIRC, and the other is a 30GB IBM-DTLA-307030 purchased about
> six months ago.
The conversation drifted ontoa different issue, your drives are fine,
in your case you are hitting bugs in the 2.5.x md driver.
On Wed, Mar 12, 2003 at 04:51:05PM +0100, Jens Axboe wrote:
> On Wed, Mar 12 2003, Andries Brouwer wrote:
> > On Wed, Mar 12, 2003 at 11:14:14AM +0100, Jens Axboe wrote:
> >
> > > So I still think it's much better stick with the safe choice. Why do you
> > > think it's only one drive that has this bug? It basically boils down to
> > > whether That Other OS uses 256 sector commands or not. If it doesn't, I
> > > wouldn't trust the drives one bit.
> >
> > I am not quite sure I understand your reasoning.
> > We have seen *zero* drives that do not understand 256 sector commands.
> > Maybe such drives exist, but so far there is zero evidence.
>
> Have you read the thread? You are obviously mistaken.
Usually I am not, but I am happy to be corrected.
Please point out the facts.
What I have seen is Paul Gortmaker, who reported on an old disk
that showed errors with 256 sector transfers. In an early post
he thought that that just was because the drive did not understand
256-sector transfers, in a later post he reported that in fact
256-sector transfers worked but that it was possible to
provoke a problem by having heavy load for an hour with
256-sector transfers.
I have an old drive that works fine but after three crashes
at 4 in the morning I decided that the load of updating
the locate database was more than it could handle.
Heavy load is something that kills many a machine.
Andries
On Wed, 2003-03-12 at 15:11, Jens Axboe wrote:
> Then go with 128. I'd like to stress again that _if_ you get worse
> performance it's not due to the request being a bit smaller, but indeed
> because 248 can cause badly aligned requests.
>
> > got the IDE layer using 256 block writes even if we have to limit it
> > to more modern drives by some handwaving (8Gb+ say)
>
> Does Windows use 256 sector requests or not? If not, then I'd sure don't
> want to do it in Linux, the handwaving doesn't mean anything then.
I am told it does, Andre can you confirm this either way. If not then its
time to ask vendors to confirm and any vendor who says "our drives are fine"
we put on the ok list.
On Wed, Mar 12 2003, Alan Cox wrote:
> On Wed, 2003-03-12 at 15:11, Jens Axboe wrote:
> > Then go with 128. I'd like to stress again that _if_ you get worse
> > performance it's not due to the request being a bit smaller, but indeed
> > because 248 can cause badly aligned requests.
> >
> > > got the IDE layer using 256 block writes even if we have to limit it
> > > to more modern drives by some handwaving (8Gb+ say)
> >
> > Does Windows use 256 sector requests or not? If not, then I'd sure don't
> > want to do it in Linux, the handwaving doesn't mean anything then.
>
> I am told it does, Andre can you confirm this either way. If not then its
> time to ask vendors to confirm and any vendor who says "our drives are fine"
> we put on the ok list.
Well I can hook an analyzer to such a bastard and verify it for sure,
that's one way :)
If Windows does, then we have nothing to worry about.
--
Jens Axboe
On Wed, Mar 12 2003, Andries Brouwer wrote:
> On Wed, Mar 12, 2003 at 04:51:05PM +0100, Jens Axboe wrote:
> > On Wed, Mar 12 2003, Andries Brouwer wrote:
> > > On Wed, Mar 12, 2003 at 11:14:14AM +0100, Jens Axboe wrote:
> > >
> > > > So I still think it's much better stick with the safe choice. Why do you
> > > > think it's only one drive that has this bug? It basically boils down to
> > > > whether That Other OS uses 256 sector commands or not. If it doesn't, I
> > > > wouldn't trust the drives one bit.
> > >
> > > I am not quite sure I understand your reasoning.
> > > We have seen *zero* drives that do not understand 256 sector commands.
> > > Maybe such drives exist, but so far there is zero evidence.
> >
> > Have you read the thread? You are obviously mistaken.
>
> Usually I am not, but I am happy to be corrected.
> Please point out the facts.
>
> What I have seen is Paul Gortmaker, who reported on an old disk
> that showed errors with 256 sector transfers. In an early post
> he thought that that just was because the drive did not understand
> 256-sector transfers, in a later post he reported that in fact
> 256-sector transfers worked but that it was possible to
> provoke a problem by having heavy load for an hour with
> 256-sector transfers.
>
> I have an old drive that works fine but after three crashes
> at 4 in the morning I decided that the load of updating
> the locate database was more than it could handle.
> Heavy load is something that kills many a machine.
Either the drive has the bug or not. I seriously doubt that 256 vs 248
sectors would put any extra strain on the drive.
If there's no real precedent wrt 256 sector bug in _any_ drive, then I'm
fine with that change. Remember that we _did_ have it that way for a
while, it was only changed back because of apparent problems. If those
problems turn out to be non-existant, then the error was changing it
away from 256 in the first place.
--
Jens Axboe
> > I am not quite sure I understand your reasoning.
> > We have seen *zero* drives that do not understand 256 sector commands.
> > Maybe such drives exist, but so far there is zero evidence.
>
> Have you read the thread? You are obviously mistaken.
I've read most of it, and as far as I can see the problem is that one
drive is known to accept 256 sector commands and occasionally fail on
them. Since that is obviously broken behavior, I don't see how it can
possibly even be suggested that we reduce the performance of possibly
every other hard disk in use[1] just to compensate for it.
[1] Note that the known broken disk is 700 MB one, so there probably
aren't many in use anyway.
John.
In article <[email protected]>,
Andries Brouwer <[email protected]> wrote:
>On Wed, Mar 12, 2003 at 11:14:14AM +0100, Jens Axboe wrote:
>
>> So I still think it's much better stick with the safe choice. Why do you
>> think it's only one drive that has this bug? It basically boils down to
>> whether That Other OS uses 256 sector commands or not. If it doesn't, I
>> wouldn't trust the drives one bit.
>
>I am not quite sure I understand your reasoning.
>We have seen *zero* drives that do not understand 256 sector commands.
>Maybe such drives exist, but so far there is zero evidence.
That is definitely not true. We definitely _have_ had drives that
misconstrue the 256-sector case. It's been a long time, but they
definitely exist.
The right limit for IDE is 255 sectors, and doing 256 sectors WILL fail
on some setups.
Linus
Jens wrote:
>On Wed, Mar 12 2003, Andre Hedrick wrote:
>>
>> So lets dirty list the one drive by Paul G. and be done.
>> Can we do that?
>
>Who cares, really? There's not much point in doing it, we're talking 248
>vs 256 sectors in reality. I think it's a _bad_ idea, lets just keep it
>at 255 and avoid silly drive bugs there.
>
>
I think a black list would be the right thing:
linux/drivers/ide/ide-probe.c:
>#ifdef CONFIG_BLK_DEV_PDC4030
> max_sectors = 127;
>#else
> max_sectors = 255;
>#endif
> blk_queue_max_sectors(q, max_sectors);
>
>
>
IDE uses 127 sector requests if support for PDC4030 is compiled it,
otherwise 255. It seems someone started with a blacklist, but never
completed it.
Does any distro enable PDC4030 support?
--
Manfred
> >I am not quite sure I understand your reasoning.
> >We have seen *zero* drives that do not understand 256 sector commands.
> >Maybe such drives exist, but so far there is zero evidence.
>
> That is definitely not true. We definitely _have_ had drives that
> misconstrue the 256-sector case. It's been a long time, but they
> definitely exist.
>
> The right limit for IDE is 255 sectors, and doing 256 sectors WILL fail
> on some setups.
Couldn't we have a list of known good drives, though, and enable 256
sectors as a special case?
John.
On Wed, 12 Mar 2003, John Bradford wrote:
>
> Couldn't we have a list of known good drives, though, and enable 256
> sectors as a special case?
My problem is that I just don't see the point. What's the difference
between 256 and 254 sectors? 128kB vs 127kB?
Also, looking closer, the current limit actually seems to be _controller_
dependent, not disk-dependent. I don't know how valid that is, but it
looks reasonable at least in theory - while the IDE controller is mostly a
passthrough thing, it does end up doing part of the work. So the picture
look smore complex than just another drive blacklist.
In short, the headaches just aren't worth the 127->128kB gain.
Linus
On Wed, 2003-03-12 at 17:59, Linus Torvalds wrote:
> That is definitely not true. We definitely _have_ had drives that
> misconstrue the 256-sector case. It's been a long time, but they
> definitely exist.
>
> The right limit for IDE is 255 sectors, and doing 256 sectors WILL fail
> on some setups.
One single possible but unclear case. I'm waiting to find out what
Win2K does.
We have had controllers that misconstrue it as the only definitive case
and that is correctly handled by the IDE code already, which splits
the DMA descriptor.
Alan
On Wed, 2003-03-12 at 18:19, Manfred Spraul wrote:
> IDE uses 127 sector requests if support for PDC4030 is compiled it,
> otherwise 255. It seems someone started with a blacklist, but never
> completed it.
> Does any distro enable PDC4030 support?
I'd be quite suprised. The 2.5 kernel means we can set max sectors per
channel easily so that issue is solvable too. I'd just not noticed it
until you pointed it out
On Wed, Mar 12, 2003 at 05:59:03PM +0000, Linus Torvalds wrote:
> >We have seen *zero* drives that do not understand 256 sector commands.
> >Maybe such drives exist, but so far there is zero evidence.
>
> That is definitely not true. We definitely _have_ had drives that
> misconstrue the 256-sector case. It's been a long time, but they
> definitely exist.
I disagree. If you have any proof, please show it.
Let me repeat:
We have seen *zero* drives that do not understand 256 sector commands.
We have seen *one* drive (a six years old Maxtor 7850AV) that could not
sustain heavy load with max # secs set to 256, while it behaved better
with max set to 255.
But we have seen lots of old old drives that show all kinds of errors.
> The right limit for IDE is 255 sectors, and doing 256 sectors WILL fail
> on some setups.
Paul remarked: "So the 255 (or even the old 128) fixes things vs. 256,
but I'd feel better being 100% sure why. Is 255 a "fix" or a perturbation
that happens to paper over something else?"
I think there is no good reason to limit us to 255 sectors.
(And no reason for blacklists either - there is just no good evidence
that something is systematically wrong with 256 sectors for any brand or
model. Things would change if a second Maxtor 7850AV owner could confirm.)
Andries
Hello,
On Wed, 12 Mar 2003, Manfred Spraul wrote:
> linux/drivers/ide/ide-probe.c:
>
> >#ifdef CONFIG_BLK_DEV_PDC4030
> > max_sectors = 127;
> >#else
> > max_sectors = 255;
> >#endif
> > blk_queue_max_sectors(q, max_sectors);
> >
> >
> >
> IDE uses 127 sector requests if support for PDC4030 is compiled it,
> otherwise 255. It seems someone started with a blacklist, but never
> completed it.
There is something wrong with this.
2.4.20-pre5-ac1 for example does:
*max_sect++ = ((hwif->rqsize) ? hwif->rqsize : 128);
(hmm why 128?)
PDC4030 (127 sectors) and siimage (128 or 16) are setting own sector size,
so this may be related to
http://bugzilla.kernel.org/show_bug.cgi?id=123.
Not tested patch (sorry, no hardware) agains 2.5.64-ac3 (applies to 2.5.64
too).
--
have fun,
alex
===== drivers/ide/ide-probe.c 1.33 vs edited =====
--- 1.33/drivers/ide/ide-probe.c Sat Mar 8 01:45:31 2003
+++ edited/drivers/ide/ide-probe.c Wed Mar 12 23:12:35 2003
@@ -995,18 +995,15 @@
static void ide_init_queue(ide_drive_t *drive)
{
request_queue_t *q = &drive->queue;
- int max_sectors;
+ int max_sectors = 255;
q->queuedata = HWGROUP(drive);
blk_init_queue(q, do_ide_request, &ide_lock);
drive->queue_setup = 1;
blk_queue_segment_boundary(q, 0xffff);
-#ifdef CONFIG_BLK_DEV_PDC4030
- max_sectors = 127;
-#else
- max_sectors = 255;
-#endif
+ if (HWIF(drive)->rqsize)
+ max_sectors = HWIF(drive)->rqsize;
blk_queue_max_sectors(q, max_sectors);
/* IDE DMA can do PRD_ENTRIES number of segments. */
> > Couldn't we have a list of known good drives, though, and enable 256
> > sectors as a special case?
>
> My problem is that I just don't see the point. What's the difference
> between 256 and 254 sectors? 128kB vs 127kB?
Ah, I thought there was a reason that it was a Good Thing to keep it
as a power of 2, which would mean 64kB vs 128kB, but if not then I
totally agree.
> Also, looking closer, the current limit actually seems to be _controller_
> dependent, not disk-dependent. I don't know how valid that is, but it
> looks reasonable at least in theory - while the IDE controller is mostly a
> passthrough thing, it does end up doing part of the work. So the picture
> look smore complex than just another drive blacklist.
>
> In short, the headaches just aren't worth the 127->128kB gain.
I wasn't aware of the controller issue - with that thrown in to the
mix, I see your point.
John.
Andries Brouwer wrote:
> We have seen *one* drive (a six years old Maxtor 7850AV) that could not
> sustain heavy load with max # secs set to 256, while it behaved better
> with max set to 255.
[...]
> Paul remarked: "So the 255 (or even the old 128) fixes things vs. 256,
> but I'd feel better being 100% sure why. Is 255 a "fix" or a perturbation
> that happens to paper over something else?"
As luck would have it, I kept that drive around, thinking it might be
interesting to have around if the above "why" part got revisited
someday.
> I think there is no good reason to limit us to 255 sectors.
>
> (And no reason for blacklists either - there is just no good evidence
> that something is systematically wrong with 256 sectors for any brand or
> model. Things would change if a second Maxtor 7850AV owner could confirm.)
Perhaps I can also act as the second owner in this case. :-) The drive is
currently in an old 16MB P133 on a PIIX3, so after tripping over this
thread, I did some testing to 1st see if I could still re-create any
problems in this different box. Of note, 2.4.21pre5 reports:
hda: 1667232 sectors (854 MB) w/64KiB Cache, CHS=1654/16/63, BUG DMA OFF
-------------------->^^^
which I haven't looked into yet. Anyway, I tweaked pre5 to re-allow 256
and then let it do two 2.5.64 compiles at the same time (in 16MB, this
takes a while) and nothing broke. Thinking that the original problem was
in an even older VLB box, I disabled DMA and did the same test. Still no
breakage.
What does this mean? I'm not sure :) Maybe this simple test isn't as
harsh as the prior one from several years ago. Realistically, there
are a fair number of changes that also may have a role: e.g. ide driver,
gcc, gas, kernel, CPU, mainboard, ide controller, PSU, cables, and so on
all have changed. It looks like I would need to jump back into the past
and test on the exact same system and then progressively rule out some
of these variables.
Paul.