Again problems with PDC20268 and vol_id

Again problems with PDC20268 and vol_id

[Guido Diepen]

Hi,
Hi,

some time ago I mentioned on this mailing list that I had some problems
with udev in combination with a promise PCI IDE controler (PDC20268
chipset). As soon as I had udev enabled, one of the things that was done
during device creation was a call to the vol_id program. Whenever vol_id
was executed on one of the drives attached to this extra IDE controller,
my system would freeze with the following snippet of errors:

hdg: dma_intr: status=0x51 { DriveRead SeekComplete Error}
hdg: dma_intr: error=0x10 {SectorIdNotFound }, LBAsect= ... (rest of this
I could not see anymore on the foto I took of the screen)
ide: failed opcode was: unknown

This error repeats a couple of times, then I get the message:
hdg: DMA disabled
PDC202XX: Secondary channel reset.
ide3: reset: success
hdg: task_in_intr: status=0x59 { DriveReady SeekComplete ...
hdg: task_in_intr: error=0x10 {SectorIdNotFound }, LBAsect ...

This particular harddrive is a 120 GB Maxtor 4G120J6 drive and is split
into two equal size partitions of 58GB and this error only occurred when
the vol_id was ran on the second partition (hdg2) and nothing happened
when running it on the first partition.

I started looking more into the problem and found out that the vol_id
program would only crash IF it was looking for raid. If I rain the vol_id
program with the option --skip-raid, everything worked flawless.
Therefore, currently in the udev rules I have replaced all occurrences of
the vol_id program with vol_id --skip-raid and now my system works fine.
(not really solution, but more work-around ;) )




This week I wanted to get the DBUS/HAL/UDEV combination to work and as
soon as I started the dbus program, my system freezed again. Finally,
after doing this again in the console, I found out that the hal program
makes use of the libvolume-id library and this library again tries to find
some raid-info and during that process it crashes my system with exactly
the same error as above.

What more information would be needed to solve this problem? Please let me
know and I will see if I can supply the needed information.

Kind regards,

Guido Diepen


-- 
Aviation is proof that given the will, we have the capacity to achieve
the impossible.
          --Eddie Rickenbacker



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Again problems with PDC20268 and vol_id

[Kay Sievers]

On 3/9/07, Guido Diepen <guido@jcwodan.nl> wrote:
> some time ago I mentioned on this mailing list that I had some problems
> with udev in combination with a promise PCI IDE controler (PDC20268
> chipset). As soon as I had udev enabled, one of the things that was done
> during device creation was a call to the vol_id program. Whenever vol_id
> was executed on one of the drives attached to this extra IDE controller,
> my system would freeze with the following snippet of errors:
>
> hdg: dma_intr: status=0x51 { DriveRead SeekComplete Error}
> hdg: dma_intr: error=0x10 {SectorIdNotFound }, LBAsect= ... (rest of this
> I could not see anymore on the foto I took of the screen)
> ide: failed opcode was: unknown
>
> This error repeats a couple of times, then I get the message:
> hdg: DMA disabled
> PDC202XX: Secondary channel reset.
> ide3: reset: success
> hdg: task_in_intr: status=0x59 { DriveReady SeekComplete ...
> hdg: task_in_intr: error=0x10 {SectorIdNotFound }, LBAsect ...
>
> This particular harddrive is a 120 GB Maxtor 4G120J6 drive and is split
> into two equal size partitions of 58GB and this error only occurred when
> the vol_id was ran on the second partition (hdg2) and nothing happened
> when running it on the first partition.
>
> I started looking more into the problem and found out that the vol_id
> program would only crash IF it was looking for raid. If I rain the vol_id
> program with the option --skip-raid, everything worked flawless.
> Therefore, currently in the udev rules I have replaced all occurrences of
> the vol_id program with vol_id --skip-raid and now my system works fine.
> (not really solution, but more work-around ;) )

Please ask the ide maintainers, or the driver author, or on the linux
kernel mailing list, this looks like a bug in the driver. Udev just
tries to read the very last sectors of the disk, which shouldn't crash
your box.

Maybe you can use a libata driver for that hardware instead? So you
would get sd* device nodes, but maybe not this failure. But I don't
know if that's possible for that hardware.

Thanks,
Kay

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Again problems with PDC20268 and vol_id

[Sergey Vlasov]

[-- Attachment #1.1: Type: text/plain, Size: 2484 bytes --]

On Fri, 9 Mar 2007 14:16:43 +0100 (CET) Guido Diepen wrote:

> some time ago I mentioned on this mailing list that I had some problems
> with udev in combination with a promise PCI IDE controler (PDC20268
> chipset). As soon as I had udev enabled, one of the things that was done
> during device creation was a call to the vol_id program. Whenever vol_id
> was executed on one of the drives attached to this extra IDE controller,
> my system would freeze with the following snippet of errors:
>
> hdg: dma_intr: status=0x51 { DriveRead SeekComplete Error}
> hdg: dma_intr: error=0x10 {SectorIdNotFound }, LBAsect= ... (rest of this
> I could not see anymore on the foto I took of the screen)

However, that value is important - together with the kernel messages
printed during detection of drivers.  Most likely the sector number is
out of range for your disk, and the disk replies to such access with
the SectorIdNotFound error.

Just provide the full dmesg output if you are unsure which lines are
relevant for the problem.

> ide: failed opcode was: unknown
>
> This error repeats a couple of times, then I get the message:
> hdg: DMA disabled
> PDC202XX: Secondary channel reset.
> ide3: reset: success
> hdg: task_in_intr: status=0x59 { DriveReady SeekComplete ...
> hdg: task_in_intr: error=0x10 {SectorIdNotFound }, LBAsect ...
>
> This particular harddrive is a 120 GB Maxtor 4G120J6 drive and is split
> into two equal size partitions of 58GB and this error only occurred when
> the vol_id was ran on the second partition (hdg2) and nothing happened
> when running it on the first partition.

Please provide also the "fdisk -l -u /dev/hdg" output.

Is the partition table correct?  Maybe the partition extends beyond
the end of physical disk for some reason, and when the kernel tries to
access last blocks of the partition, it actually tries to read sectors
beyond the actual drive capacity, which fails and exposes broken error
handling in the Promise IDE driver.

I have added the linux-ide mailing list to Cc: - problems related to
IDE/ATA drivers (both old IDE, which you are using currently, and
newer libata) should be discussed there.

> I started looking more into the problem and found out that the vol_id
> program would only crash IF it was looking for raid. If I rain the vol_id
> program with the option --skip-raid, everything worked flawless.

With --skip-raid vol_id does not look for Linux software RAID
superblocks, which are located at the end of device.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Again problems with PDC20268 and vol_id

[Guido Diepen]

Sergey Vlasov wrote:
>
> However, that value is important - together with the kernel messages
> printed during detection of drivers.  Most likely the sector number is
> out of range for your disk, and the disk replies to such access with
> the SectorIdNotFound error.

Unfortunately it means I will have to crash my system once more :) I will
do that this weekend, after unmounting everything.

>
> Just provide the full dmesg output if you are unsure which lines are
> relevant for the problem.

Relevant dmesg output:
...
Probing IDE interface ide3...
hdg: Maxtor 4G120J6, ATA DISK drive
...
hdg: max request size: 512KiB
hdg: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS\x16383/255/63,
UDMA(100)
hdg: cache flushes not supported
 hdg: hdg1 hdg2




>
> Please provide also the "fdisk -l -u /dev/hdg" output.

cartman:/home/guido# fdisk -l -u /dev/hdg

Disk /dev/hdg: 122.9 GB, 122942324736 bytes
16 heads, 63 sectors/track, 238216 cylinders, total 240121728 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdg1   *          63   120060863    60030400+  83  Linux
/dev/hdg2       120060896   240121759    60030432   83  Linux


>
> Is the partition table correct?  Maybe the partition extends beyond
> the end of physical disk for some reason, and when the kernel tries to
> access last blocks of the partition, it actually tries to read sectors
> beyond the actual drive capacity, which fails and exposes broken error
> handling in the Promise IDE driver.

I don't know how to verify that the partition table is correct, hopefully
you can extract this from the supplied data. (If partition table is not
correct, would I be able to update that dynamically, or must I move all
data to different disks, reset the partition table and copy data back?)


>
> I have added the linux-ide mailing list to Cc: - problems related to
> IDE/ATA drivers (both old IDE, which you are using currently, and
> newer libata) should be discussed there.
>
>> I started looking more into the problem and found out that the vol_id
>> program would only crash IF it was looking for raid. If I rain the
>> vol_id
>> program with the option --skip-raid, everything worked flawless.
>
> With --skip-raid vol_id does not look for Linux software RAID
> superblocks, which are located at the end of device.

Ok, now that part is clear to me also :)

Hope you have enough of info with this, if not, I can crash my system this
weekend again and supply you with more relevant data :)

Regards,

Guido Diepen




-- 
Aviation is proof that given the will, we have the capacity to achieve
the impossible.
          --Eddie Rickenbacker



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Again problems with PDC20268 and vol_id

[Sergey Vlasov]

[-- Attachment #1.1: Type: text/plain, Size: 2552 bytes --]

On Fri, Mar 09, 2007 at 05:51:25PM +0100, Guido Diepen wrote:
[...]
> Probing IDE interface ide3...
> hdg: Maxtor 4G120J6, ATA DISK drive
> ...
> hdg: max request size: 512KiB
> hdg: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=16383/255/63,
> UDMA(100)
> hdg: cache flushes not supported
>  hdg: hdg1 hdg2
[...]
> cartman:/home/guido# fdisk -l -u /dev/hdg
> 
> Disk /dev/hdg: 122.9 GB, 122942324736 bytes
> 16 heads, 63 sectors/track, 238216 cylinders, total 240121728 sectors
> Units = sectors of 1 * 512 = 512 bytes
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/hdg1   *          63   120060863    60030400+  83  Linux
> /dev/hdg2       120060896   240121759    60030432   83  Linux

Here is a problem: according to the partition table, the last sector of
hdg2 is 240121759, but the disk has only 240121728 sectors (the number of
last sector is 1 less - 240121727).  So you have a partition which extends
beyond the end of the disk by 240121727 - 240121759 = 32 sectors (16 KB).

How did you create these partitions?  Maybe you have changed disks and
used dd to copy the whole old disk, which happened to be slightly bigger?

> I don't know how to verify that the partition table is correct, hopefully
> you can extract this from the supplied data. (If partition table is not
> correct, would I be able to update that dynamically, or must I move all
> data to different disks, reset the partition table and copy data back?)

This depends on the filesystem used on the problematic partition (although
creating a backup copy would be wise in any case).

You need to determine what device size is assumed by the filesystem.  If
you use ext2/3, run "tune2fs -l /dev/hdg2" (this is safe even if the
filesystem is mounted - it only reads some information from the
superblock).  Then from the "Block count" and "Block size" fields you can
determine the size of the filesystem in sectors.

Then, if the filesystem data really does not extend beyond the end of
disk, you can just delete and recreate the hdg2 partition in Linux fdisk
with the proper size (be careful not to make it smaller than the
filesystem).  If the filesystem extends beyond the end of disk, the
situation is worse: there are resizing programs for ext2/3 and some other
filesystems, but they may behave badly when some parts of the filesystem
are not available.  And if you have used xfs, bad luck - xfs can be only
grown, not shrunk, so the only solution is to recreate the filesystem from
scratch.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Again problems with PDC20268 and vol_id

[Guido Diepen]

Hi Sergey,

> Is the partition table correct?  Maybe the partition extends beyond
> the end of physical disk for some reason, and when the kernel tries to
> access last blocks of the partition, it actually tries to read sectors
> beyond the actual drive capacity, which fails and exposes broken error
> handling in the Promise IDE driver.
>
> I have added the linux-ide mailing list to Cc: - problems related to
> IDE/ATA drivers (both old IDE, which you are using currently, and
> newer libata) should be discussed there.

Last night I copied all data on the /dev/hdg2 partition to other partitions, 
removed the /dev/hdg2 partition and recreated it. Currently everything works 
flawless !!!

Apparently there is a bug in the promise IDE pdc202xx_new.c driver :)

Thank you very much for the help!!!

Regards,

Guido Diepen


-- 
Aviation is proof that given the will, we have the 
capacity to achieve the impossible.
     --Eddie Rickenbacker

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Again problems with PDC20268 and vol_id

[Bartlomiej Zolnierkiewicz]

[ added Jens to cc: ]

Hi,

On Saturday 10 March 2007, Guido Diepen wrote:
> Hi Sergey,
> 
> > Is the partition table correct?  Maybe the partition extends beyond
> > the end of physical disk for some reason, and when the kernel tries to
> > access last blocks of the partition, it actually tries to read sectors
> > beyond the actual drive capacity, which fails and exposes broken error
> > handling in the Promise IDE driver.
> >
> > I have added the linux-ide mailing list to Cc: - problems related to
> > IDE/ATA drivers (both old IDE, which you are using currently, and
> > newer libata) should be discussed there.
> 
> Last night I copied all data on the /dev/hdg2 partition to other partitions, 
> removed the /dev/hdg2 partition and recreated it. Currently everything works 
> flawless !!!

Thanks for testing this (and reporting the bug in the first place).
Also big thanks to Sergey for digging out the source of the issue.

> Apparently there is a bug in the promise IDE pdc202xx_new.c driver :)

IDE error recovery code needs improvements (people are working at it)
but there is no wonder that it failed miserably first in DMA mode and later
during PIO retries - it just couldn't read the sector which doesn't exist.
Probably the final steps of error recovery procedure were unsuccessful because
it is using the older method for putting the drive into the "good" idle state
which confuses newer disks (there is a patch - to be merged - from Suleiman
Souhlal addressing this).

However it seems that the root source of the problem was that IDE subsystem
got the request for sector outside the valid sector range and it should _never_
happen for requests originating from the block layer (a lot of code - not only
in the IDE subsystem - assumes this)...

Thanks,
Bart

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel