Kernel bug crashing in HDIO_DRIVE_TASKFILE

Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Norman Diamond]

Kernel 2.6.27.7 in Slax gets a panic or oops (I can't tell which).
Of course I had to recompile the Slax kernel with CONFIG_IDE_TASK_IOCTL enabled.
Kernel 2.6.19 in Knoppix handles the same HDIO_DRIVE_TASKFILE perfectly.
In all cases /dev/hda has no mounted partitions and it is free for me to write to.

100% reproduced in four configurations:
(1) drive supports LBA48 and WRITE_DMA_EXT was used
(2) drive supports LBA48 but WRITE_DMA (LBA28) was used
(3) drive doesn't support LBA48 and WRITE_DMA was used
(4) VMware drive probably supports LBA48 but WRITE_DMA was used
I am trying to write 126 sectors starting at sector number 0.
(Of course the real purpose of the program will not be to write 126 sectors starting at 0.)

kernel BUG at block/cfg-iosched.c:2001!
invalid opcode: 0000 [#1] SMP
Modules linked in: pcmcia pcmcia_core lp pcspkr ppdev parport_pc isp1760 pcnet32
 psmouse serio_raw mii i2c_piix4 parport shpchp intel_agp agpgart evdev fuse auf
s squashfs sqlzma unlzma [last unloaded: pcmcia_core]

Pid: 3634, comm: pee3en Tainted: G        W (2.6.27.7 #1)
EIP: 0060:[<c03be1a5>] EFLAGS: 00010046 CPU: 0
EIP is at cfq_put_request+0x45/0x50
EAX: 00000000 EBX: dec59960 ECX: c03be160 EDX: 00000001
ESI: defa0a50 EDI: dec3f230 EBP: 00000400 ESP: def09d5c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process pee3en (pid: 3634, ti=def08000 task=dec1ee00 task.ti=def08000)
Stack: dec59960 000104c9 c03b20c0 c03b4441 dec3f230 dec59960 00000282 def09dd8
       c03b4829 fffffffb 0000007e dec59960 c045e308 00000000 df32d850 d9000640
       00000000 00000004 0000fc00 c045f273 0000007e 00000000 def09ea0 def09dd8
Call Trace:
 [<c03b20c0>] elv_put_request+0x10/0x20
 [<c03b4441>] __blk_put_request+0x71/0x80
 [<c03b4829>] blk_put_request+0x29/0x50
 [<c045e308>] ide_raw_taskfile+0x78/0x90
 [<c045f273>] ide_taskfile_ioctl+0x283/0x4c0
 [<c0469a8d>] idedisk_ioctl+0x3d/0x150
 [<c03b88fd>] blkdev_driver_ioctl+0x6d/0x80
 [<c03b8b9e>] blkdev_ioctl+0x283/0x820
 [<c0175705>] do_sync_write+0xd5/0x120
 [<c0156517>] get_page_from_freelist+0x2c7/0x440
 [<c01568b8>] __alloc_pages_internal+0xa8/0x430
 [<c015f9d4>] unmap_vmas+0x364/0x560
 [<c01593f6>] __pagevec_lru_add_active+0x96/0xb0
 [<c016066c>] handle_mm_fault+0x46c/0x640
 [<c01638e4>] vma_merge+0x144/0x1d0
 [<c019c2a8>] block_ioctl+0x18/0x20
 [<c019c290>] block_ioctl+0x0/0x20
 [<c018178b>] vfs_ioctl+0x2b/0x90
 [<c0181a4b>] do_vfs_ioctl+0x25b/0x2a0
 [<c0181ae6>] sys_ioctl+0x56/0x70
 [<c0103262>] syscall_call+0x7/0xb
 =======================
Code: e8 01 89 44 96 2c 8b 43 58 8b 40 10 e8 a5 90 ff ff 89 f0 c7 43 58 00 00 00
 00 c7 43 5c 00 00 00 00 5b 5e e9 3e ff ff ff 5b 5e c3 <0f> 0b eb fe 8d b4 26 00
 00 00 00 83 ec 08 89 1c 24 89 d3 89 74
EIP: [<c03be1a5>] cfq_put_request+0x45/0x50 SS:ESP 0068:def09d5c
---[ end trace 4eaa2a86a8e2da22 ]---

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Chuck Ebbert]

On Tue, 24 Feb 2009 20:36:52 +0900
"Norman Diamond" <n0diamond@yahoo.co.jp> wrote:

> Kernel 2.6.27.7 in Slax gets a panic or oops (I can't tell which).
> Of course I had to recompile the Slax kernel with CONFIG_IDE_TASK_IOCTL enabled.
> Kernel 2.6.19 in Knoppix handles the same HDIO_DRIVE_TASKFILE perfectly.
> In all cases /dev/hda has no mounted partitions and it is free for me to write to.
> 
> 100% reproduced in four configurations:
> (1) drive supports LBA48 and WRITE_DMA_EXT was used
> (2) drive supports LBA48 but WRITE_DMA (LBA28) was used
> (3) drive doesn't support LBA48 and WRITE_DMA was used
> (4) VMware drive probably supports LBA48 but WRITE_DMA was used
> I am trying to write 126 sectors starting at sector number 0.
> (Of course the real purpose of the program will not be to write 126 sectors starting at 0.)
> 
> kernel BUG at block/cfg-iosched.c:2001!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: pcmcia pcmcia_core lp pcspkr ppdev parport_pc isp1760 pcnet32
>  psmouse serio_raw mii i2c_piix4 parport shpchp intel_agp agpgart evdev fuse auf
> s squashfs sqlzma unlzma [last unloaded: pcmcia_core]
> 
> Pid: 3634, comm: pee3en Tainted: G        W (2.6.27.7 #1)
> EIP: 0060:[<c03be1a5>] EFLAGS: 00010046 CPU: 0
> EIP is at cfq_put_request+0x45/0x50
> EAX: 00000000 EBX: dec59960 ECX: c03be160 EDX: 00000001
> ESI: defa0a50 EDI: dec3f230 EBP: 00000400 ESP: def09d5c
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process pee3en (pid: 3634, ti=def08000 task=dec1ee00 task.ti=def08000)
> Stack: dec59960 000104c9 c03b20c0 c03b4441 dec3f230 dec59960 00000282 def09dd8
>        c03b4829 fffffffb 0000007e dec59960 c045e308 00000000 df32d850 d9000640
>        00000000 00000004 0000fc00 c045f273 0000007e 00000000 def09ea0 def09dd8
> Call Trace:
>  [<c03b20c0>] elv_put_request+0x10/0x20
>  [<c03b4441>] __blk_put_request+0x71/0x80
>  [<c03b4829>] blk_put_request+0x29/0x50
>  [<c045e308>] ide_raw_taskfile+0x78/0x90
>  [<c045f273>] ide_taskfile_ioctl+0x283/0x4c0
>  [<c0469a8d>] idedisk_ioctl+0x3d/0x150
>  [<c03b88fd>] blkdev_driver_ioctl+0x6d/0x80
>  [<c03b8b9e>] blkdev_ioctl+0x283/0x820
>  [<c0175705>] do_sync_write+0xd5/0x120
>  [<c0156517>] get_page_from_freelist+0x2c7/0x440
>  [<c01568b8>] __alloc_pages_internal+0xa8/0x430
>  [<c015f9d4>] unmap_vmas+0x364/0x560
>  [<c01593f6>] __pagevec_lru_add_active+0x96/0xb0
>  [<c016066c>] handle_mm_fault+0x46c/0x640
>  [<c01638e4>] vma_merge+0x144/0x1d0
>  [<c019c2a8>] block_ioctl+0x18/0x20
>  [<c019c290>] block_ioctl+0x0/0x20
>  [<c018178b>] vfs_ioctl+0x2b/0x90
>  [<c0181a4b>] do_vfs_ioctl+0x25b/0x2a0
>  [<c0181ae6>] sys_ioctl+0x56/0x70
>  [<c0103262>] syscall_call+0x7/0xb
>  =======================
> Code: e8 01 89 44 96 2c 8b 43 58 8b 40 10 e8 a5 90 ff ff 89 f0 c7 43 58 00 00 00
>  00 c7 43 5c 00 00 00 00 5b 5e e9 3e ff ff ff 5b 5e c3 <0f> 0b eb fe 8d b4 26 00
>  00 00 00 83 ec 08 89 1c 24 89 d3 89 74
> EIP: [<c03be1a5>] cfq_put_request+0x45/0x50 SS:ESP 0068:def09d5c
> ---[ end trace 4eaa2a86a8e2da22 ]---
> 

block/cfq-iosched.c:
/*
 * queue lock held here
 */
static void cfq_put_request(struct request *rq)
{
	struct cfq_queue *cfqq = RQ_CFQQ(rq);

	if (cfqq) {
		const int rw = rq_data_dir(rq);

		BUG_ON(!cfqq->allocated[rw]);     <================
		cfqq->allocated[rw]--;

		put_io_context(RQ_CIC(rq)->ioc);

		rq->elevator_private = NULL;
		rq->elevator_private2 = NULL;

		cfq_put_queue(cfqq);
	}
}

You should try 2.6.27.6 and 2.6.27.19 to see if they have the bug too.

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Norman Diamond]

Chuck Ebbert wrote:
> Norman Diamond wrote:
>
>> Kernel 2.6.27.7 in Slax gets a panic or oops (I can't tell which).
>> Of course I had to recompile the Slax kernel with CONFIG_IDE_TASK_IOCTL
>> enabled.
>> Kernel 2.6.19 in Knoppix handles the same HDIO_DRIVE_TASKFILE perfectly.
>> 100% reproduced in four configurations: [WRITE_DMA_EXT and WRITE_DMA].
>> (Of course the real purpose of the program will not be to write 126
>> sectors starting at 0.)
>>
>> kernel BUG at block/cfg-iosched.c:2001!
>> invalid opcode: 0000 [#1] SMP
>> Pid: 3634, comm: pee3en Tainted: G        W (2.6.27.7 #1)
>> EIP: 0060:[<c03be1a5>] EFLAGS: 00010046 CPU: 0
>> EIP is at cfq_put_request+0x45/0x50
>>  [<c03b20c0>] elv_put_request+0x10/0x20
>>  [<c03b4441>] __blk_put_request+0x71/0x80
>>  [<c03b4829>] blk_put_request+0x29/0x50
>>  [<c045e308>] ide_raw_taskfile+0x78/0x90
>>  [<c045f273>] ide_taskfile_ioctl+0x283/0x4c0
>
> block/cfq-iosched.c:
> static void cfq_put_request(struct request *rq)
> BUG_ON(!cfqq->allocated[rw]);     <================
>
> You should try 2.6.27.6 and 2.6.27.19 to see if they have the bug too.

The latest kernel available from Slax with their build script is 2.6.27.8. 
Today I modified their config to enable CONFIG_IDE_TASK_IOCTL and reproed 
the bug with 2.6.27.8.

Tomorrow I will try to figure out if I can combine 2.6.27.19 with Slax's
build script but I might not be able to figure it out.

Does anyone know when this bug was added?  2.6.19 is too old for my needs,
but the range 2.6.24 to 2.6.26 might be OK if they had taskfiles working.
Maybe I should look for a Slax version that had a kernel from 2.6.24 or so,
since I can probably customize it in a single day by now.  But if the bug
was already present in 2.6.24 then it would be a waste of time. 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Mark Lord]

Norman Diamond wrote:
..
> Does anyone know when this bug was added?  2.6.19 is too old for my needs,
> but the range 2.6.24 to 2.6.26 might be OK if they had taskfiles working.
> Maybe I should look for a Slax version that had a kernel from 2.6.24 or so,
> since I can probably customize it in a single day by now.  But if the bug
> was already present in 2.6.24 then it would be a waste of time.
..

Heh.. the question could be more like, does anyone know which few kernels
that HDIO_DRIVE_TASKFILE ever worked completely on?  :)

I know I have to patch drivers/ide rather heavily to get a working,
reliable HDIO_DRIVE_TASKFILE on it.

Much better is to move to libata, and use ATA_16 with SG_IO,
for a standard, working way of doing this kind of stuff.

Cheers

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Bartlomiej Zolnierkiewicz]

On Wednesday 25 February 2009, Mark Lord wrote:
> Norman Diamond wrote:
> ..
> > Does anyone know when this bug was added?  2.6.19 is too old for my needs,
> > but the range 2.6.24 to 2.6.26 might be OK if they had taskfiles working.
> > Maybe I should look for a Slax version that had a kernel from 2.6.24 or so,
> > since I can probably customize it in a single day by now.  But if the bug
> > was already present in 2.6.24 then it would be a waste of time.
> ..
> 
> Heh.. the question could be more like, does anyone know which few kernels
> that HDIO_DRIVE_TASKFILE ever worked completely on?  :)
> 
> I know I have to patch drivers/ide rather heavily to get a working,
> reliable HDIO_DRIVE_TASKFILE on it.
> 
> Much better is to move to libata, and use ATA_16 with SG_IO,
> for a standard, working way of doing this kind of stuff.

While SG_IO is definitely better way to go submitting your
HDIO_DRIVE_TASKFILE patches wouldn't hurt...

Thanks,
Bart

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Norman Diamond]

Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 25 February 2009, Mark Lord wrote:
>> Norman Diamond wrote:
>> ..
>>> Does anyone know when this bug was added?  2.6.19 is too old for my
>>> needs, but the range 2.6.24 to 2.6.26 might be OK if they had taskfiles
>>> working.
>>> Maybe I should look for a Slax version that had a kernel from 2.6.24 or
>>> so, since I can probably customize it in a single day by now.  But if
>>> the bug was already present in 2.6.24 then it would be a waste of time.
>>
>> Heh.. the question could be more like, does anyone know which few kernels
>> that HDIO_DRIVE_TASKFILE ever worked completely on?  :)

I don't need an answer to that ^~^  2.6.19 had it working well enough for my
program, but didn't have drivers for some chipsets.

>> I know I have to patch drivers/ide rather heavily to get a working,
>> reliable HDIO_DRIVE_TASKFILE on it.
>>
>> Much better is to move to libata, and use ATA_16 with SG_IO, for a
>> standard, working way of doing this kind of stuff.
>
> While SG_IO is definitely better way to go submitting your
> HDIO_DRIVE_TASKFILE patches wouldn't hurt...

Especially since my SG_IO code already works[*] with SATA controllers, I
sure would like to use it with ATA, but I couldn't find a way to persuade
Slax to use libata for ATA controllers.  Does anyone have suggestions?

Meanwhile I also can't help wondering, if Mark Lord has patched drivers/ide
to make it work, why has he delayed submitting the patches?

With my immense expertise, I only needed a few hours to find where the limit
of 65536 bytes is explained in documentation so that users will know not to
use HDIO_DRIVE_TASKFILE with some nonsense buffer size like 131072.
I forgot which document where a pair of if statements document that fact, 
but the filename ended in .c.  Of course this does beat Windows where we 
don't get to see that kind of documentation at all.  Anyway, I wouldn't dare 
patch that stuff unless I'd been working on it for say at least a week ^~^

[* Wait a minute.  My SG_IO code already worked in which kernel version, and
now I have to test if it still works now.  Arrrrrgggggghhhhhh.]

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Mark Lord]

Norman Diamond wrote:
>
> Meanwhile I also can't help wondering, if Mark Lord has patched drivers/ide
> to make it work, why has he delayed submitting the patches?
..

There's simply too much churn in drivers/ide for me to keep up with,
and my patches won't apply to kernels from the past year.

Drivers/ide is on the way out FAST now, and any new systems that
still use it are mostly based on older kernels, where patches like
mine are inappropriate for maintenance point releases.

Libata should be used for any new setup that doesn't have a strict
legacy requirement now.

Cheers

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Norman Diamond]

Mark Lord wrote:
> Norman Diamond wrote:
>>
>> Meanwhile I also can't help wondering, if Mark Lord has patched
>> drivers/ide to make it work, why has he delayed submitting the patches?
>
> There's simply too much churn in drivers/ide for me to keep up with, and
> my patches won't apply to kernels from the past year.

OK!  For my present needs, a year-old kernel didn't need your patches.

This problem with 2.6.27.7 and 2.6.27.8 was solved by grading to 2.6.24.3.
Slax 6.0.3 came with configuration files for 2.6.24.3, I edited the
configuration to set CONFIG_IDE_TASK_IOCTL=y, and the result ran without
crashing -- today anyway.  It still needs more testing.

This kind of solution, fixing a problem by upgrading to an older version, is
something that we normally expect to pay for.  Usually we have to pay for
that kind of software every time we buy a PC.  I'm well aware that this one
came from volunteers, and I ought to contribute by finding where the bug was
introduced, but sorry, I don't have that kind of free time.

> Drivers/ide is on the way out FAST now, and any new systems that still use
> it are mostly based on older kernels, where patches like mine are
> inappropriate for maintenance point releases.

Some are old systems that need their own maintenance, their maintenance
ought to be accompanied by upgrading to newer kernels, and patches would be
very highly appropriate for maintenance point releases.

> Libata should be used for any new setup that doesn't have a strict legacy
> requirement now.

90% agreed.  However, I've read that libata will never support add-on IDE
boards. 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Robert Hancock]

Norman Diamond wrote:
>> Libata should be used for any new setup that doesn't have a strict legacy
>> requirement now.
> 
> 90% agreed.  However, I've read that libata will never support add-on IDE
> boards.

Huh? It already does support most or all that one is likely to see..

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Norman Diamond]

Robert Hancock wrote:
> Norman Diamond wrote:
>> [attribution stolen:]
>>
>>> Libata should be used for any new setup that doesn't have a strict 
>>> legacy requirement now.
>>
>> 90% agreed.  However, I've read that libata will never support add-on IDE 
>> boards.
>
> Huh? It already does support most or all that one is likely to see..

That is good news then.

Last week when searching for articles about Slax and libata, I found various 
postings about methods that temporarily worked but no longer (for example 
there used to be a kernel boot parameter for the combined mode of some Intel 
chipsets, and there used to be a parameter to disable probing by 
ide_generic).  While not finding a way to get a particular chipset to be 
recognized as /dev/sda instead of /dev/hda, I also found other articles 
explaining various limitations of libata.  Some said that SATA is the 
priority for libata as it should be, but PATA was low priority with just 
enough effort to get it working with common legacy IDE controllers, and 
add-on IDE boards were zero priority.  My troubles last week were with 
notebook PCs that didn't have add-on IDE cards, but I will also have to 
support add-on IDE cards.

If anyone here knows how to put libata in control of chipsets that could be 
claimed by either libata or legacy ide, please say.  As mentioned I found 
various postings by others that temporarily worked but no longer.  It was 
kind of reassuring to see my program operate correctly under Slax 6.0.3 with 
my slight modification to Slax's config kernel 2.6.24.3 to enable 
taskfiles -- and then heartbreaking to see ordinary programs get 1.5 
megabytes per second to the hard drive. 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Alan Cox]

> If anyone here knows how to put libata in control of chipsets that could be 
> claimed by either libata or legacy ide, please say.  As mentioned I found 

Just compile in the libata drivers you need not the old IDE ones. Simple
as that.

Alan

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Robert Hancock]

Norman Diamond wrote:
> Robert Hancock wrote:
>> Norman Diamond wrote:
>>> [attribution stolen:]
>>>
>>>> Libata should be used for any new setup that doesn't have a strict 
>>>> legacy requirement now.
>>>
>>> 90% agreed.  However, I've read that libata will never support add-on 
>>> IDE boards.
>>
>> Huh? It already does support most or all that one is likely to see..
> 
> That is good news then.
> 
> Last week when searching for articles about Slax and libata, I found 
> various postings about methods that temporarily worked but no longer 
> (for example there used to be a kernel boot parameter for the combined 
> mode of some Intel chipsets, and there used to be a parameter to disable 
> probing by ide_generic).  While not finding a way to get a particular 
> chipset to be recognized as /dev/sda instead of /dev/hda, I also found 
> other articles explaining various limitations of libata.  Some said that 
> SATA is the priority for libata as it should be, but PATA was low 
> priority with just enough effort to get it working with common legacy 
> IDE controllers, and add-on IDE boards were zero priority.  My troubles 

That's probably a fairly old article, not really the way things are today.

> last week were with notebook PCs that didn't have add-on IDE cards, but 
> I will also have to support add-on IDE cards.
> 
> If anyone here knows how to put libata in control of chipsets that could 
> be claimed by either libata or legacy ide, please say.  As mentioned I 
> found various postings by others that temporarily worked but no longer.  
> It was kind of reassuring to see my program operate correctly under Slax 
> 6.0.3 with my slight modification to Slax's config kernel 2.6.24.3 to 
> enable taskfiles -- and then heartbreaking to see ordinary programs get 
> 1.5 megabytes per second to the hard drive.

Likely easiest to just disable CONFIG_IDE in your kernel configuration 
entirely. If you have two drivers compiled for the same hardware, there 
isn't really a good way to force one or the other to be used.

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Norman Diamond]

I will try building a kernel without legacy IDE drivers,
but meanwhile here's the latest bug.

Knoppix 6.0.1 is built on kernel 2.6.28.4.  Legacy IDE
drivers still claim /dev/hda and /dev/hdc (the Knoppix CD
being on /dev/hdc).

In order to view part of a dump if it occurs, I typed the
following boot command:
knoppix 3 lang=en keyboard=jp106

When I try to do a TASKFILE WRITE_DMA (LBA28), the process
hangs.  No dump.  Ctrl+C and Ctrl+Z were ignored. 
Ctrl+Alt+F2 switched to a second VT (by the way this no
longer works if Knoppix 6.0.1 is booted to graphical
mode).  The second VT responded at first.  Then tried to
do a dd if=/dev/hda bs=512 count=5 | od, and the second VT
hanged too.

In the third VT, dmesg showed this error message:
hda-intel: Invalid position buffer, using LPIB read method
instead.

Google found several threads where people are blaming this
error message on audio drivers or wireless LAN drivers. 
Some people are saying it was fixed somewhere earlier than
2.6.28.4.  2.6.28.4 tells me it's not fixed, and the
timing sure doesn't look like audio or wireless LAN.

I'll try building a kernel without legacy IDE drivers, but
I wonder which kernel version to try.


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Robert Hancock]

Norman Diamond wrote:
> I will try building a kernel without legacy IDE drivers,
> but meanwhile here's the latest bug.
> 
> Knoppix 6.0.1 is built on kernel 2.6.28.4.  Legacy IDE
> drivers still claim /dev/hda and /dev/hdc (the Knoppix CD
> being on /dev/hdc).
> 
> In order to view part of a dump if it occurs, I typed the
> following boot command:
> knoppix 3 lang=en keyboard=jp106
> 
> When I try to do a TASKFILE WRITE_DMA (LBA28), the process
> hangs.  No dump.  Ctrl+C and Ctrl+Z were ignored. 
> Ctrl+Alt+F2 switched to a second VT (by the way this no
> longer works if Knoppix 6.0.1 is booted to graphical
> mode).  The second VT responded at first.  Then tried to
> do a dd if=/dev/hda bs=512 count=5 | od, and the second VT
> hanged too.
> 
> In the third VT, dmesg showed this error message:
> hda-intel: Invalid position buffer, using LPIB read method
> instead.
> 
> Google found several threads where people are blaming this
> error message on audio drivers or wireless LAN drivers. 
> Some people are saying it was fixed somewhere earlier than
> 2.6.28.4.  2.6.28.4 tells me it's not fixed, and the
> timing sure doesn't look like audio or wireless LAN.

I'm guessing that's a symptom and not a cause, if the IDE driver is
causing some kind of partial lockup then that could be messing with the
audio driver..

> 
> I'll try building a kernel without legacy IDE drivers, but
> I wonder which kernel version to try.

Normally latest is best..

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Norman Diamond]

Robert Hancock wrote:
> Norman Diamond wrote:
>> In the third VT, dmesg showed this error message:
>> hda-intel: Invalid position buffer, using LPIB read method instead.
>>
>> Google found several threads where people are blaming this error message 
>> on audio drivers or wireless LAN drivers.  Some people are saying it was 
>> fixed somewhere earlier than 2.6.28.4.  2.6.28.4 tells me it's not fixed, 
>> and the timing sure doesn't look like audio or wireless LAN.
>
> I'm guessing that's a symptom and not a cause, if the IDE driver is 
> causing some kind of partial lockup then that could be messing with the 
> audio driver..
>
>> I'll try building a kernel without legacy IDE drivers, but I wonder which 
>> kernel version to try.
>
> Normally latest is best..

Yeah but "normally" doesn't help a lot with this problem.  I do plan to see 
if I can build a Slax CD with the latest kernel with a configuration to omit 
legacy IDE drivers, but meanwhile I'm still primarily using Slax 6.0.3 with 
kernel 2.6.24.3 because I could use Slax's tools to build it and it seemed 
to work.

Well, it turns out that 2.6.24.3 doesn't work either.  Sometimes 
HDIO_DRIVE_TASKFILE doesn't just hang a process without a dump, sometimes it 
hangs other stuff too.  This time I could still switch VT's (after booting 
Slax to text mode) but couldn't type the name "root" to log in.

So, why sometimes but not other times?  Here's some evidence.
(1)  A 40GB PATA hard drive supports LBA48, and is connected through a 
moderately old Intel controller which presents a PATA interface that 
supports LBA48, but I used an LBA28 WRITE_DMA to write 126 sectors starting 
at sector 0, and it worked perfectly.
(2)  A 250GB SATA hard drive supports LBA48, and is connected through a 
moderately new Intel controller which presents a PATA interface that 
supports LBA48, but I used an LBA28 WRITE_DMA to write 126 sectors starting 
at sector 0, and it hanged.
(3)  A 250GB SATA hard drive supports LBA48, and is connected through an 
Nvidia controller which presents a SATA interface ... oops, that means I 
used SG_IO instead of HDIO_DRIVE_TASKFILE, so there's no surprise that it 
worked.

So does this mean that some part of HDIO_DRIVE_TASKFILE doesn't want to 
believe the flags I set to use or not use the HOB registers?  If the total 
number of sectors on the drive is larger than 0x0fffffff then the driver 
wants me to use HOB registers even when lower sector numbers don't need 
them?  Notice that it doesn't seem to matter if the drive supports LBA48 or 
not.  It seems to matter if some other sectors, which aren't involved in 
this I/O, would need LBA48 when someone else accesses them.

I plan to experiment tomorrow, using LBA48 even when it shouldn't be 
necessary, to see if it avoids that hang. 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Bartlomiej Zolnierkiewicz]

On Monday 02 March 2009, Norman Diamond wrote:
> I will try building a kernel without legacy IDE drivers,
> but meanwhile here's the latest bug.
> 
> Knoppix 6.0.1 is built on kernel 2.6.28.4.  Legacy IDE
> drivers still claim /dev/hda and /dev/hdc (the Knoppix CD
> being on /dev/hdc).
> 
> In order to view part of a dump if it occurs, I typed the
> following boot command:
> knoppix 3 lang=en keyboard=jp106
> 
> When I try to do a TASKFILE WRITE_DMA (LBA28), the process
> hangs.  No dump.  Ctrl+C and Ctrl+Z were ignored. 

Could you post source code of your program or at least
the minimal test case reproducing the problem?

Thanks,
Bart

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Norman Diamond]

Bartlomiej Zolnierkiewicz wrote:
> On Monday 02 March 2009, Norman Diamond wrote:
>>
>> Knoppix 6.0.1 is built on kernel 2.6.28.4.  Legacy
>> IDE drivers still claim /dev/hda and /dev/hdc (the
>> Knoppix CD being on /dev/hdc).
>> 
>> When I try to do a TASKFILE WRITE_DMA (LBA28), the
>> process hangs.  No dump.  Ctrl+C and Ctrl+Z were
>> ignored. 
> 
> Could you post source code of your program or at
> least the minimal test case reproducing the problem?

Sorry, that one was my fault, as mentioned last week.
When kernels 2.6.28.4, 2.6.24.3, etc., don't enable
DMA on Intel ICH7M chipsets, it is my fault for trying
to use WRITE_DMA.

I am leaning towards reverting to kernel 2.6.20,
because there was a Slax distribution for it, it
enabled DMA on Intel ICH7M chipsets, and on other
machines where ICH7 presented a SATA interface its
LIBATA could access LBA sector address 0x0fffffff.
I've been told (can't test personally) that 2.6.20
had trouble with AMD chipsets, but Intel users
outnumber AMD users.  I probably have to rebuild that
Slax with TASKFILEs enabled and see if they work.

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

[Norman Diamond]

I (Norman Diamond) wrote:

> Well, it turns out that 2.6.24.3 doesn't work either.  Sometimes
> HDIO_DRIVE_TASKFILE doesn't just hang a process without a dump, sometimes
> it hangs other stuff too.  This time I could still switch VT's (after
> booting Slax to text mode) but couldn't type the name "root" to log in.

Sorry, that one was my fault.

> So does this mean that some part of HDIO_DRIVE_TASKFILE doesn't want to
> believe the flags I set to use or not use the HOB registers?

No, that problem doesn't occur (in 2.6.24.3 anyway).

WRITE_DMA doesn't work very well when DMA isn't enabled on the drive.  I
wonder why there was such a widespread hang but not complete hang.  I can
imagine the driver not checking because the caller is responsible for the
contents of the taskfile, but I would have expected the drive to return an
error and the driver to push the error back up, instead of hanging.  Anyway 
it was my fault.

This unfortunate case was on a Dell Latitude D820 with an Intel ICH7M
chipset.  The hard drive is SATA and I don't know the interface of the DVD
drive, but Dell's BIOS sets the ICH7M to present a PATA interface with no
option to change it.  The hard drive gets /dev/hda, the DVD drive gets
/dev/hdc, DMA is disabled, and hdparm can't enable DMA on the hard drive.
Google showed me lots of complaints from people who couldn't enable DMA on
the DVD drive but it looks like I'm the only one who couldn't enable DMA on
the hard drive.  Putting hda=noprobe in the boot command line let the hard
drive become /dev/sda and speed up by a factor of 40.

I understand libata is the biggest answer.  I hope it really handles
everything but that's going to take a lot of testing to confirm.

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/