I have a 486 box which ran 2.5.7 fine, but 2.5.8 oopses during
boot at the BUG_ON() in drivers/ide/ide-disk.c, line 360:
if (drive->using_tcq) {
int tag = ide_get_tag(drive);
BUG_ON(drive->tcq->active_tag != -1);
Relevant .config is
# CONFIG_PCI is not set
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
(That's it. No chipset support selected; neither I nor Linux
has ever detected any known IDE chipset in this box...)
Why is drive->using_tcq non-zero when CONFIG_BLK_DEV_IDE_TCQ=n
and the disk is an early/mid-90s 500MB WD drive?
/Mikael
On Tue, Apr 16 2002, Mikael Pettersson wrote:
> I have a 486 box which ran 2.5.7 fine, but 2.5.8 oopses during
> boot at the BUG_ON() in drivers/ide/ide-disk.c, line 360:
>
> if (drive->using_tcq) {
> int tag = ide_get_tag(drive);
>
> BUG_ON(drive->tcq->active_tag != -1);
>
> Relevant .config is
> # CONFIG_PCI is not set
> CONFIG_IDE=y
> CONFIG_BLK_DEV_IDE=y
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> (That's it. No chipset support selected; neither I nor Linux
> has ever detected any known IDE chipset in this box...)
>
> Why is drive->using_tcq non-zero when CONFIG_BLK_DEV_IDE_TCQ=n
> and the disk is an early/mid-90s 500MB WD drive?
No ata pci adapter selected, probably. Apply 2.5.8-dj1, it should have
the most interesting parts for you. I'll update my stuff tomorrow.
--
Jens Axboe
Mikael Pettersson wrote:
> I have a 486 box which ran 2.5.7 fine, but 2.5.8 oopses during
> boot at the BUG_ON() in drivers/ide/ide-disk.c, line 360:
>
> if (drive->using_tcq) {
> int tag = ide_get_tag(drive);
>
> BUG_ON(drive->tcq->active_tag != -1);
OK it could be that the tca goesn't get allocated if there
was no chipset selected. Lets have a look...
>
> Relevant .config is
> # CONFIG_PCI is not set
> CONFIG_IDE=y
> CONFIG_BLK_DEV_IDE=y
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> (That's it. No chipset support selected; neither I nor Linux
> has ever detected any known IDE chipset in this box...)
>
> Why is drive->using_tcq non-zero when CONFIG_BLK_DEV_IDE_TCQ=n
> and the disk is an early/mid-90s 500MB WD drive?
>
> /Mikael
> -
> 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/
>
>
--
- phone: +49 214 8656 283
- job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R
On Wed, Apr 17 2002, Martin Dalecki wrote:
> Mikael Pettersson wrote:
> >I have a 486 box which ran 2.5.7 fine, but 2.5.8 oopses during
> >boot at the BUG_ON() in drivers/ide/ide-disk.c, line 360:
> >
> > if (drive->using_tcq) {
> > int tag = ide_get_tag(drive);
> >
> > BUG_ON(drive->tcq->active_tag != -1);
>
> OK it could be that the tca goesn't get allocated if there
> was no chipset selected. Lets have a look...
Add a drive->using_dma check to ide_dma_queued_on in ide-tcq.c, it needs
to look like this:
ide_tcq_dmaproc()
{
...
case ide_dma_queued_off:
enable_tcq = 0;
case ide_dma_queued_on:
if (!drive->using_dma)
return 1;
return ide_enable_queued(drive, enable_tcq);
default:
break;
}
that should fix it.
--
Jens Axboe
On Wed, Apr 17 2002, Jens Axboe wrote:
> On Wed, Apr 17 2002, Martin Dalecki wrote:
> > Mikael Pettersson wrote:
> > >I have a 486 box which ran 2.5.7 fine, but 2.5.8 oopses during
> > >boot at the BUG_ON() in drivers/ide/ide-disk.c, line 360:
> > >
> > > if (drive->using_tcq) {
> > > int tag = ide_get_tag(drive);
> > >
> > > BUG_ON(drive->tcq->active_tag != -1);
> >
> > OK it could be that the tca goesn't get allocated if there
> > was no chipset selected. Lets have a look...
>
> Add a drive->using_dma check to ide_dma_queued_on in ide-tcq.c, it needs
> to look like this:
>
> ide_tcq_dmaproc()
> {
>
> ...
>
> case ide_dma_queued_off:
> enable_tcq = 0;
> case ide_dma_queued_on:
> if (!drive->using_dma)
> return 1;
> return ide_enable_queued(drive, enable_tcq);
> default:
> break;
> }
>
> that should fix it.
Should only be done if 'enable_tcq == 1' of course, and we also need to
switch off tcq when dma is being disabled. 4th patch set against 2.5.8.
Note to Martin: I'll merge with IDE-XX later today.
--
Jens Axboe
Jens Axboe wrote:
> On Wed, Apr 17 2002, Jens Axboe wrote:
>
>>On Wed, Apr 17 2002, Martin Dalecki wrote:
>>
>>>Mikael Pettersson wrote:
>>>
>>>>I have a 486 box which ran 2.5.7 fine, but 2.5.8 oopses during
>>>>boot at the BUG_ON() in drivers/ide/ide-disk.c, line 360:
>>>>
>>>> if (drive->using_tcq) {
>>>> int tag = ide_get_tag(drive);
>>>>
>>>> BUG_ON(drive->tcq->active_tag != -1);
>>>
>>>OK it could be that the tca goesn't get allocated if there
>>>was no chipset selected. Lets have a look...
>>
>>Add a drive->using_dma check to ide_dma_queued_on in ide-tcq.c, it needs
>>to look like this:
>>
>>ide_tcq_dmaproc()
>>{
>>
>> ...
>>
>> case ide_dma_queued_off:
>> enable_tcq = 0;
>> case ide_dma_queued_on:
>> if (!drive->using_dma)
>> return 1;
>> return ide_enable_queued(drive, enable_tcq);
>> default:
>> break;
>> }
>>
>>that should fix it.
Yes I see. However for now I will just concentrate on ide-cd.c and
await you to merge up with IDE 37 OK? (It should be easy this time :-).
On Wed, Apr 17 2002, Martin Dalecki wrote:
> Yes I see. However for now I will just concentrate on ide-cd.c and
> await you to merge up with IDE 37 OK? (It should be easy this time :-).
Perfect, sounds good to me. Running a few shake-down tests right now, so
in a few hours it should be ready.
--
Jens Axboe
On Wed Apr 17, 2002 at 01:33:39PM +0200, Martin Dalecki wrote:
> Yes I see. However for now I will just concentrate on ide-cd.c and
> await you to merge up with IDE 37 OK? (It should be easy this time :-).
While working on ide-cd, I think the bad sector handling needs
serious attention... For example, I have a CD-ROM (a toddler
game for windoz) that my 2 year old son scratched into
non-functional oblivion. I attempted to extract the contents in
the hope of burning it to a new CD. Using dd conv=noerror, it
began ripping the content just fine -- till it hit the bad spot.
Then it took like 12 hours to progress by an additional 10 MB...
Looking at the ide-cd code (since I used to maintain it years
ago) it seems that on a bad sector, ide-cd retries ERROR_MAX (8)
times. But the low level ide driver is _also_ doing ERROR_MAX
retries for each of those 8 retries from ide-cd.... Do we
really need to retry 64 times when the drive told us clearly the
_first_ time that it is an uncorrectable medium error?
Perhaps something like this patch would make more sense? With
this patch is place, error handling is still awful, but at least
a dd was able to make a bit of progress....
--- linux/drivers/ide/ide-cd.c.orig Tue Apr 16 06:59:56 2002
+++ linux/drivers/ide/ide-cd.c Tue Apr 16 07:04:59 2002
@@ -657,6 +657,11 @@
request or data protect error.*/
ide_dump_status (drive, "command error", stat);
cdrom_end_request (0, drive);
+ } else if (sense_key == MEDIUM_ERROR) {
+ /* No point in re-trying a zillion times on a bad
+ * sector... If we got here the error is not correctable */
+ ide_dump_status (drive, "media error (bad sector)", stat);
+ cdrom_end_request (0, drive);
} else if ((err & ~ABRT_ERR) != 0) {
/* Go to the default handler
for other errors. */
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Erik Andersen wrote:
> On Wed Apr 17, 2002 at 01:33:39PM +0200, Martin Dalecki wrote:
>
>>Yes I see. However for now I will just concentrate on ide-cd.c and
>>await you to merge up with IDE 37 OK? (It should be easy this time :-).
>
>
> While working on ide-cd, I think the bad sector handling needs
> serious attention... For example, I have a CD-ROM (a toddler
> game for windoz) that my 2 year old son scratched into
> non-functional oblivion. I attempted to extract the contents in
> the hope of burning it to a new CD. Using dd conv=noerror, it
> began ripping the content just fine -- till it hit the bad spot.
> Then it took like 12 hours to progress by an additional 10 MB...
>
> Looking at the ide-cd code (since I used to maintain it years
> ago) it seems that on a bad sector, ide-cd retries ERROR_MAX (8)
> times. But the low level ide driver is _also_ doing ERROR_MAX
> retries for each of those 8 retries from ide-cd.... Do we
> really need to retry 64 times when the drive told us clearly the
> _first_ time that it is an uncorrectable medium error?
>
> Perhaps something like this patch would make more sense? With
> this patch is place, error handling is still awful, but at least
> a dd was able to make a bit of progress....
Yeep you are entierly right. I will include your patch directly.
On Wed, 17 Apr 2002 14:25:02 +0200, Jens Axboe wrote:
>> > Mikael Pettersson wrote:
>> > >I have a 486 box which ran 2.5.7 fine, but 2.5.8 oopses during
>> > >boot at the BUG_ON() in drivers/ide/ide-disk.c, line 360:
...
>Should only be done if 'enable_tcq == 1' of course, and we also need to
>switch off tcq when dma is being disabled. 4th patch set against 2.5.8.
Thanks, this patch set cured the problem. 2.5.8-dj1 also worked.
/Mikael