After new kernel boot takes signifcantly longer [SOLVED]

airencracken · 2011-02-15 00:43:08

The boot seems to hang in two places. Once when it's loading my CD drive, and on processing udev events.

I've found this in the error.log

Feb 14 16:35:21 localhost kernel: ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Feb 14 16:35:21 localhost kernel: ata6.00: failed command: IDENTIFY PACKET DEVICE
Feb 14 16:35:21 localhost kernel: ata6.00: cmd a1/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
Feb 14 16:35:21 localhost kernel: res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
Feb 14 16:35:21 localhost kernel: ata6.00: status: { DRDY }
Feb 14 16:35:21 localhost kernel: ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Feb 14 16:35:21 localhost kernel: ata6.00: failed command: IDENTIFY PACKET DEVICE
Feb 14 16:35:21 localhost kernel: ata6.00: cmd a1/00:01:00:00:00/00:00:00:00:00/00 tag 0 pio 512 in
Feb 14 16:35:21 localhost kernel: res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
Feb 14 16:35:21 localhost kernel: ata6.00: status: { DRDY }

Any ideas? This problem only showed up with a recent pacman -Syu.

Last edited by airencracken (2011-02-24 00:32:45)

azleifel · 2011-02-19 01:27:01

It's a problem with udev-165 that persists in udev-166. I posted my version of the same problem at https://bbs.archlinux.org/viewtopic.php … 47#p883847 and the only effective solutions I've found are to either downgrade to udev-164 or remove the "Use ata_id, not scsi_id, on ATAPI devices" code from udev-165.

azleifel · 2011-02-20 02:52:16

For the record, I have a workaround. The "Use ata_id, not scsi_id, on ATAPI devices" commit in udev-165 uses a 16-byte ATA pass through command to identify ATAPI cdrom drives, apparently to avoid clashing with the MMC BLANK command. That's something akin to running

$ sg_sat_identify -vv -p -l 16 /dev/dvd

which fails on my PC (Samsung SH-S223C SATA CD/DVD drive, AHCI enabled) with

open /dev/dvd with flags=0x802
    ATA pass through (16) cdb: 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 a1 00 
ioctl(SG_IO v3) failed: Bad address (errno=14)
ATA pass through (16): os error: Bad address
ATA pass through (16) failed

This probably means that the Samsung drive doesn't like 16-byte pass through commands, though I guess that there could be some other reason for the failure. Whatever, after some research I found that the libata kernel module has an "atapi_passthru16" option that can be used to disable 16-byte ATA pass through commands and since doing that I've had no

Feb 19 00:45:36 localhost kernel: ata3.00: failed command: IDENTIFY PACKET DEVICE

errors with udev-165 installed, either during boot or when mounting/unmounting CDs and DVDs, processing udev uevents takes no longer than normal, CDs still burn properly with cdrecord, there have been no unwanted attempts to blank a CD or DVD left in the drive and, as a bonus, the old double eject problem (tray opens, tray closes, tray opens again) has gone away...for now!

Implementation:

Add
```
options libata atapi_passthru16=0
```
to /etc/modprobe.d/modprobe.conf
Add
```
FILES="/etc/modprobe.d/modprobe.conf"
```
to /etc/mkinitcpio.conf
(Install udev-165)
Rebuild the kernel image with mkinitcpio
Reboot

airencracken · 2011-02-23 05:08:48

Wicked. I'm going to try this asap and let you know how it goes. Thanks for the help!

Edit

Worked great! Thanks for the assist. I was pretty stumped.

Last edited by airencracken (2011-02-23 05:49:01)

azleifel · 2011-02-23 19:28:35

Good news! Don't forget to mark this thread [solved] ;-)

Lucagb · 2012-03-17 10:06:46

azleifel wrote:

For the record, I have a workaround. The "Use ata_id, not scsi_id, on ATAPI devices" commit in udev-165 uses a 16-byte ATA pass through command to identify ATAPI cdrom drives, apparently to avoid clashing with the MMC BLANK command. That's something akin to running
$ sg_sat_identify -vv -p -l 16 /dev/dvd
which fails on my PC (Samsung SH-S223C SATA CD/DVD drive, AHCI enabled) with
open /dev/dvd with flags=0x802
    ATA pass through (16) cdb: 85 08 0e 00 00 00 01 00 00 00 00 00 00 00 a1 00 
ioctl(SG_IO v3) failed: Bad address (errno=14)
ATA pass through (16): os error: Bad address
ATA pass through (16) failed
This probably means that the Samsung drive doesn't like 16-byte pass through commands, though I guess that there could be some other reason for the failure. Whatever, after some research I found that the libata kernel module has an "atapi_passthru16" option that can be used to disable 16-byte ATA pass through commands and since doing that I've had no
Feb 19 00:45:36 localhost kernel: ata3.00: failed command: IDENTIFY PACKET DEVICE
errors with udev-165 installed, either during boot or when mounting/unmounting CDs and DVDs, processing udev uevents takes no longer than normal, CDs still burn properly with cdrecord, there have been no unwanted attempts to blank a CD or DVD left in the drive and, as a bonus, the old double eject problem (tray opens, tray closes, tray opens again) has gone away...for now!
Implementation:
Add
options libata atapi_passthru16=0
to /etc/modprobe.d/modprobe.conf
Add
FILES="/etc/modprobe.d/modprobe.conf"
to /etc/mkinitcpio.conf
(Install udev-165)
Rebuild the kernel image with mkinitcpio
Reboot

Thanks a lot,
I'm an italian Chakra's user,
I had this problem to many months and thanks to you I have solved
grazie 1000

Arch Linux

#1 2011-02-15 00:43:08

After new kernel boot takes signifcantly longer [SOLVED]

#2 2011-02-19 01:27:01

Re: After new kernel boot takes signifcantly longer [SOLVED]

#3 2011-02-20 02:52:16

Re: After new kernel boot takes signifcantly longer [SOLVED]

#4 2011-02-23 05:08:48

Re: After new kernel boot takes signifcantly longer [SOLVED]

#5 2011-02-23 19:28:35

Re: After new kernel boot takes signifcantly longer [SOLVED]

#6 2012-03-17 10:06:46

Re: After new kernel boot takes signifcantly longer [SOLVED]

Board footer