Re: Missing virtio modules for sparc64

[John Paul Adrian Glaubitz]

On 03/16/2017 11:24 PM, John Paul Adrian Glaubitz wrote:
> I'm rebuilding the sparc64 installer image now and will hopefully post
> it shortly.

Here they are: https://people.debian.org/~glaubitz/debian-cd/2017-03-17/

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: New sparc64 installation images 2017-03-14

[Sébastien Bernard]

Le jeu. 16 mars 2017 à 23:43, John Paul Adrian Glaubitz 
 a écrit :

On 03/16/2017 11:35 PM, Sébastien Bernard wrote:

 Here's the output although there's not much to show.


It's still more useful to have the actual debug output than relying
on paraphrased installation reports.


 There are 3 boot sequences :
 boot.img from 2016.02.12
 boot.img from 2016.03.14


Could you try the latest image?


 https://people.debian.org/~glaubitz/debian-cd/2017-03-14/


This crash is very early and in case the 2017 image doesn't work 
either, you
should post this to the sparclinux Linux kernel mailing list and ask 
the
SPARC kernel wizards for advise. It might even be SILO that is 
crashing

and not the kernel itself.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


Hum,
I made a mistake in my answer, I tried all boot.img provided.
Second boot is with the boot.img file from 2017.03.14
Here's the md5sum.

md5sum boot.img-Debian-7.11 boot.img.201*
281ae77030424ac82ce65b3a06059273  boot.img-Debian-7.11
ecc7ebcc26082b7f39846ee93a13cd70  boot.img.2016-02-12
a3cb58eeda39c3cad80f2928f7f7f218  boot.img.2017-03-14


Seb

Re: New sparc64 installation images 2017-03-14

[John Paul Adrian Glaubitz]

On 03/16/2017 11:46 PM, Sébastien Bernard wrote:
> I made a mistake in my answer, I tried all boot.img provided.
> Second boot is with the boot.img file from 2017.03.14

Oh, right, netboot. Hmm, then I'd suggest posting your issue
to the sparclinux kernel mailing list.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: New sparc64 installation images 2017-03-14

[John Paul Adrian Glaubitz]

On 03/16/2017 11:35 PM, Sébastien Bernard wrote:
> Here's the output although there's not much to show.

It's still more useful to have the actual debug output than relying
on paraphrased installation reports.

> There are 3 boot sequences :
> boot.img from 2016.02.12
> boot.img from 2016.03.14

Could you try the latest image?

> https://people.debian.org/~glaubitz/debian-cd/2017-03-14/

This crash is very early and in case the 2017 image doesn't work either, you
should post this to the sparclinux Linux kernel mailing list and ask the
SPARC kernel wizards for advise. It might even be SILO that is crashing
and not the kernel itself.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Missing virtio modules for sparc64

[John Paul Adrian Glaubitz]

Hi Mark, Hi Helge!

On 03/16/2017 10:57 PM, Helge Deller wrote:
>> Please can you consider the attached patch for inclusion in the
>> debian-installer so that it becomes possible to perform a complete
>> sparc64 installation from virtio devices under QEMU?
>>(...)
> I just committed it, together with the patch for powerpc (bug #767487).

I'm rebuilding the sparc64 installer image now and will hopefully post
it shortly.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Retrieving disk info from sunvdc using udevadm

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/16/2017 01:44 PM, John Paul Adrian Glaubitz wrote:
> On 03/16/2017 01:39 PM, James Clarke wrote:
>> Patching d-i might make sense, since it will ensure other architectures 
>> don't have similar issues, but I believe the problem is in udev itself, 
>> specifically 60-cdrom_id.rules[1] which needs to whitelist "vdisk*" as 
>> possible CDs.
> 
> Ah, good point. I will try patching the file and see if that helps.

It does. Sent a pull request to systemd upstream [1].

Adrian

> [1] https://github.com/systemd/systemd/pull/5599

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAljKkNwACgkQdCY7N/W1
+ROC6xAArSbF8zFTTwMu8D1IASAHyNzFa8GpdPfKpaHOKRVZwuTADf4RuVsEct6f
fNy5k1oMXJxTOiguOA4rkuWQjtyVOUVXhxh5W+xBtEDCrz4NSvBw9m4WbpWKbCtk
zgkvq1jXVuiut81VLbZhYDlIjMNcyplHs9tpwqQXbQfWSo0Xu8Yb9exWkSs1/Jg/
O7y0kyUQqkhIHU0stsgsZh+uP97PAFobBfBNhtSbRRNbMQr2nY1v+AHpTvoaHMrI
CLBWXGCJgM/64HKIiBe3TWF9RPwehyLRUgoTKfWDCCst+Yi3OZZ7LGGSdef9tiux
iF1e173ZjWEMnmB78ejogRaZz+TZWAIEBOAH2Bcf83ycm7rnjW6mUShAxt+W7pLN
q1RdFXrNLwVlXmFAlrvLyRTWj6csLgj3Iu8JD3Qn9TE8zWHBXP83EnOeTyyAzERs
716SrkwkopkAcoeBqR2RhvJqi5/DhdPZfZXXCbvF+360BPqGldEkG+FlJdvYtUka
m5lnmGiSFsDZ+wsSvuPoAALWnAuYo7S0v5TFyHO5z3YHs/q9p8n1Ucm36bKHHyYq
qvXB/9k7t+PGd8Kjk3zgB/Nx2EkoCB3VMpxi6QRKzkyOD+aJ/+NLcck2IyNikDMy
eimsN96lWhND7uSYnUi+U8AvxZhHZkTjBwnBRZv3OOM565SkLzM=
=82ZK
-END PGP SIGNATURE-

Re: Retrieving disk info from sunvdc using udevadm

[John Paul Adrian Glaubitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/16/2017 01:39 PM, James Clarke wrote:
> Patching d-i might make sense, since it will ensure other architectures don't 
> have similar issues, but I believe the problem is in udev itself,
> specifically 60-cdrom_id.rules[1] which needs to whitelist "vdisk*" as 
> possible CDs.

Ah, good point. I will try patching the file and see if that helps.

> Certainly if you invoke /lib/udev/cdrom_id manually it is able to distinguish 
> between CDs and non-CDs.

I have actually been fumbling with that in the past. That was when I fixed
the autoloading mechanism.

Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAljKiL8ACgkQdCY7N/W1
+RNcMw//XIBd7T5xnVb7ENWRrld8vMiBP9zl7xkHg7s8zjJ7uQDPlm/P/Styc1fU
IjLOpVSuZyS83uRe33R62SgIEmv1PKKotvmYJXBznIaLZnSrDEwEuISJregJU2Jb
Nb9eYppwyDi/flpxqaKuTHIVrkGyJRU7LAMv1Gd91L5ELqNUAfmF5hsx9A1q4rgJ
ARpw+nQf15zdy0YTgxTXlFz2f8rPYFOv0ueh5ZGqfn8zFQiFZh49OtLghkkpjdFF
SZ4+rQ5NlquAl2WOLXudlC/oIopNhEb6J7nXnI056vuOTHQvhDnPw0wF7tcdf97g
PHxZpr1KRYQrqG3Q/AVAR5uOfxvNKBJUL/sUmBXkY3WLUMeUafzXAIqMWAw81FpB
VIFj6yDkhDFr0bFgAj2GhmoCLnH8izmuUKEK3GSJndsoftP8ilXe4OU0E4/kJxB9
w/LW52YqXb+ih0k2bh2iMdzhzRCo/qyVNJzCHwkv1EDVVHnwV3HlWS29wKlMezcM
4uU6FJPytiAuBs9f8MM0QtHq/u1bqUsghdlgw3SsZYDkXjISW/awMLkjAASf/RSD
c9hKl5kTAg5lMG2Na5NhUloiQ0CLKFRL7UES7PKMbqbQj4lC1MbZDYSgXPRGNjfc
aPuohLXE7+isGBCGRYdwRWXR58kOdyFB9OkPrdwVVLAdFwBy+A8=
=zoL8
-END PGP SIGNATURE-

Re: Retrieving disk info from sunvdc using udevadm

[James Clarke]

On 16 Mar 2017, at 12:15, Anatoly Pugachev  wrote:
> On Wed, Mar 15, 2017 at 1:14 AM, John Paul Adrian Glaubitz
>  wrote:
>> Hi!
>> 
>> Some Debian users who are installing Debian for sparc64 in an LDOM run into
>> the problem that the debian-installer is unable to detect the installation
>> medium.
>> 
>> Digging through the sources of the responsible debian-installer module, it
>> turns out that d-i uses "udevadm info" to query information from all 
>> available
>> block devices listed in /sys/block. To detect a CD-ROM, it looks for 
>> "ID_CDROM=1"
>> or "ID_TYPE=cd".
>> 
>> Unfortunately, this fails with sunvdc with a virtual CD-ROM drive as the data
>> retrieved by "udevadm info" is very limited as compared to a standard PC with
>> a physical CD-ROM drive.
>> 
>> For comparison, on a SPARC T5, I get:
>> 
>> /sys/block # udevadm info -q env -p /sys/block/vdiskd
>> DEVLINKS=/dev/disk/by-uuid/2017-03-14-14-05-33-00 
>> /dev/disk/by-label/Debian\x209.0\x20sparc64\x201
>> DEVNAME=/dev/vdiskd
>> DEVPATH=/devices/channel-devices/vdc-port-3-0/block/vdiskd
>> DEVTYPE=disk
>> ID_FS_LABEL=Debian_9.0_sparc64_1
>> ID_FS_LABEL_ENC=Debian\x209.0\x20sparc64\x201
>> ID_FS_TYPE=iso9660
>> ID_FS_USAGE=filesystem
>> ID_FS_UUID=2017-03-14-14-05-33-00
>> ID_FS_UUID_ENC=2017-03-14-14-05-33-00
>> ID_PART_TABLE_TYPE=sun
>> MAJOR=254
>> MINOR=24
>> SUBSYSTEM=block
>> USEC_INITIALIZED=634522
>> /sys/block #
>> 
>> Compare this to the output for a standard USB CD-ROM device on my laptop:
>> 
>> glaubitz@ikarus:/sys/block$ udevadm info -q env -p /sys/block/sr0
>> DEVLINKS=/dev/disk/by-path/pci-:00:14.0-usb-0:2:1.0-scsi-0:0:0:0 
>> /dev/disk/by-id/usb-TSSTcorp_CDDVDW_SE-S084D_0j468695-0:0 /dev/dvdrw 
>> /dev/dvd /dev/cdrom
>> /dev/cdrw
>> DEVNAME=/dev/sr0
>> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/host4/target4:0:0/4:0:0:0/block/sr0
>> DEVTYPE=disk
>> ID_BUS=usb
>> ID_CDROM=1
>> ID_CDROM_CD=1
>> ID_CDROM_CD_R=1
>> ID_CDROM_CD_RW=1
>> ID_CDROM_DVD=1
>> ID_CDROM_DVD_PLUS_R=1
>> ID_CDROM_DVD_PLUS_RW=1
>> ID_CDROM_DVD_PLUS_R_DL=1
>> ID_CDROM_DVD_R=1
>> ID_CDROM_DVD_RAM=1
>> ID_CDROM_DVD_RW=1
>> ID_CDROM_MRW=1
>> ID_CDROM_MRW_W=1
>> ID_FOR_SEAT=block-pci-_00_14_0-usb-0_2_1_0-scsi-0_0_0_0
>> ID_INSTANCE=0:0
>> ID_MODEL=CDDVDW_SE-S084D
>> ID_MODEL_ENC=CDDVDW\x20SE-S084D\x20
>> ID_MODEL_ID=1836
>> ID_PATH=pci-:00:14.0-usb-0:2:1.0-scsi-0:0:0:0
>> ID_PATH_TAG=pci-_00_14_0-usb-0_2_1_0-scsi-0_0_0_0
>> ID_REVISION=TS00
>> ID_SERIAL=TSSTcorp_CDDVDW_SE-S084D_0j468695-0:0
>> ID_SERIAL_SHORT=0j468695
>> ID_TYPE=cd
>> ID_USB_DRIVER=usb-storage
>> ID_USB_INTERFACES=:080250:
>> ID_USB_INTERFACE_NUM=00
>> ID_VENDOR=TSSTcorp
>> ID_VENDOR_ENC=TSSTcorp
>> ID_VENDOR_ID=0e8d
>> MAJOR=11
>> MINOR=0
>> SUBSYSTEM=block
>> SYSTEMD_READY=0
>> TAGS=:systemd:uaccess:seat:
>> USEC_INITIALIZED=16198574878
>> glaubitz@ikarus:/sys/block$
>> 
>> Would it be possible to extend sunvdc to display additional fields? In 
>> particular, it would be very useful
>> if sunvdc could indicate whether the virtual block device is a regular disk 
>> or a CD-ROM drive.
> 
> 
> Adrian,
> 
> wouldn't it be easier to patch d-i (userspace) to add support for
> "ID_FS_TYPE=iso9660" as /dev/cdrom (besides of "ID_CDROM=1"), instead
> of patching kernel (sunvdc.c) sources?

Patching d-i might make sense, since it will ensure other architectures don't
have similar issues, but I believe the problem is in udev itself, specifically
60-cdrom_id.rules[1] which needs to whitelist "vdisk*" as possible CDs.
Certainly if you invoke /lib/udev/cdrom_id manually it is able to distinguish
between CDs and non-CDs.

Regards,
James

[1] https://github.com/systemd/systemd/blob/master/rules/60-cdrom_id.rules



signature.asc
Description: Message signed with OpenPGP

Re: Retrieving disk info from sunvdc using udevadm

[John Paul Adrian Glaubitz]

On 03/16/2017 01:15 PM, Anatoly Pugachev wrote:
> wouldn't it be easier to patch d-i (userspace) to add support for
> "ID_FS_TYPE=iso9660" as /dev/cdrom (besides of "ID_CDROM=1"), instead
> of patching kernel (sunvdc.c) sources?

We have discussed this shortly, but we haven't really agreed on whether
this would be a clean solution after all. I mean, if you attach an ISO
file to a virtual CD-ROM drive, the kernel should report the corresponding
block device to be an actual CD-ROM drive, shouldn't it?

> # udevadm info -q env -p /sys/block/sr0
> (...)
> ID_CDROM=1

See, qemu does it correctly, sunvdc does not. And I assume all other type
of virtualization software (VirtualBox, VMWare) reports the right block
device type either. Otherwise we would have already seen lots of bug
reports regarding this. So I don't think it's justified to add a quirk for
sunvdc, is it?

> dmesg cut:
> (...)

I'm not sure how this is relevant here?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Retrieving disk info from sunvdc using udevadm

[Anatoly Pugachev]

On Wed, Mar 15, 2017 at 1:14 AM, John Paul Adrian Glaubitz
 wrote:
> Hi!
>
> Some Debian users who are installing Debian for sparc64 in an LDOM run into
> the problem that the debian-installer is unable to detect the installation
> medium.
>
> Digging through the sources of the responsible debian-installer module, it
> turns out that d-i uses "udevadm info" to query information from all available
> block devices listed in /sys/block. To detect a CD-ROM, it looks for 
> "ID_CDROM=1"
> or "ID_TYPE=cd".
>
> Unfortunately, this fails with sunvdc with a virtual CD-ROM drive as the data
> retrieved by "udevadm info" is very limited as compared to a standard PC with
> a physical CD-ROM drive.
>
> For comparison, on a SPARC T5, I get:
>
> /sys/block # udevadm info -q env -p /sys/block/vdiskd
> DEVLINKS=/dev/disk/by-uuid/2017-03-14-14-05-33-00 
> /dev/disk/by-label/Debian\x209.0\x20sparc64\x201
> DEVNAME=/dev/vdiskd
> DEVPATH=/devices/channel-devices/vdc-port-3-0/block/vdiskd
> DEVTYPE=disk
> ID_FS_LABEL=Debian_9.0_sparc64_1
> ID_FS_LABEL_ENC=Debian\x209.0\x20sparc64\x201
> ID_FS_TYPE=iso9660
> ID_FS_USAGE=filesystem
> ID_FS_UUID=2017-03-14-14-05-33-00
> ID_FS_UUID_ENC=2017-03-14-14-05-33-00
> ID_PART_TABLE_TYPE=sun
> MAJOR=254
> MINOR=24
> SUBSYSTEM=block
> USEC_INITIALIZED=634522
> /sys/block #
>
> Compare this to the output for a standard USB CD-ROM device on my laptop:
>
> glaubitz@ikarus:/sys/block$ udevadm info -q env -p /sys/block/sr0
> DEVLINKS=/dev/disk/by-path/pci-:00:14.0-usb-0:2:1.0-scsi-0:0:0:0 
> /dev/disk/by-id/usb-TSSTcorp_CDDVDW_SE-S084D_0j468695-0:0 /dev/dvdrw /dev/dvd 
> /dev/cdrom
> /dev/cdrw
> DEVNAME=/dev/sr0
> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/host4/target4:0:0/4:0:0:0/block/sr0
> DEVTYPE=disk
> ID_BUS=usb
> ID_CDROM=1
> ID_CDROM_CD=1
> ID_CDROM_CD_R=1
> ID_CDROM_CD_RW=1
> ID_CDROM_DVD=1
> ID_CDROM_DVD_PLUS_R=1
> ID_CDROM_DVD_PLUS_RW=1
> ID_CDROM_DVD_PLUS_R_DL=1
> ID_CDROM_DVD_R=1
> ID_CDROM_DVD_RAM=1
> ID_CDROM_DVD_RW=1
> ID_CDROM_MRW=1
> ID_CDROM_MRW_W=1
> ID_FOR_SEAT=block-pci-_00_14_0-usb-0_2_1_0-scsi-0_0_0_0
> ID_INSTANCE=0:0
> ID_MODEL=CDDVDW_SE-S084D
> ID_MODEL_ENC=CDDVDW\x20SE-S084D\x20
> ID_MODEL_ID=1836
> ID_PATH=pci-:00:14.0-usb-0:2:1.0-scsi-0:0:0:0
> ID_PATH_TAG=pci-_00_14_0-usb-0_2_1_0-scsi-0_0_0_0
> ID_REVISION=TS00
> ID_SERIAL=TSSTcorp_CDDVDW_SE-S084D_0j468695-0:0
> ID_SERIAL_SHORT=0j468695
> ID_TYPE=cd
> ID_USB_DRIVER=usb-storage
> ID_USB_INTERFACES=:080250:
> ID_USB_INTERFACE_NUM=00
> ID_VENDOR=TSSTcorp
> ID_VENDOR_ENC=TSSTcorp
> ID_VENDOR_ID=0e8d
> MAJOR=11
> MINOR=0
> SUBSYSTEM=block
> SYSTEMD_READY=0
> TAGS=:systemd:uaccess:seat:
> USEC_INITIALIZED=16198574878
> glaubitz@ikarus:/sys/block$
>
> Would it be possible to extend sunvdc to display additional fields? In 
> particular, it would be very useful
> if sunvdc could indicate whether the virtual block device is a regular disk 
> or a CD-ROM drive.


Adrian,

wouldn't it be easier to patch d-i (userspace) to add support for
"ID_FS_TYPE=iso9660" as /dev/cdrom (besides of "ID_CDROM=1"), instead
of patching kernel (sunvdc.c) sources?

PS: running qemu on x86_64 as

$ qemu-system-sparc64  -hda hda.img  -cdrom debian-7.11.0-sparc-netinst.iso

and inside qemu :

# udevadm info -q env -p /sys/block/sr0
DEVLINKS=/dev/cdrom1 /dev/disk/by-id/ata-EQUMD_DVR-MO_MQ_3
/dev/disk/by-label/Debian\x207.11.0\x20sparc\x201
/dev/disk/by-path/platform-ffe2b5a8-pci-:00:05.0-scsi-1:0:0:0
/dev/dvd1
DEVNAME=/dev/sr0
DEVPATH=/devices/root/ffe2b5a8/pci:00/:00:05.0/host1/target1:0:0/1:0:0:0/block/sr0
DEVTYPE=disk
GENERATED=1
ID_ATA=1
ID_BUS=ata
ID_CDROM=1
ID_CDROM_DVD=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_CD=1
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_FS_LABEL=Debian_7.11.0_sparc_1
ID_FS_LABEL_ENC=Debian\x207.11.0\x20sparc\x201
ID_FS_TYPE=iso9660
ID_FS_USAGE=filesystem
ID_MODEL=EQUMD_DVR-MO
ID_MODEL_ENC=EQUMD\x20DVR-MO\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_PART_TABLE_TYPE=sun
ID_PATH=platform-ffe2b5a8-pci-:00:05.0-scsi-1:0:0:0
ID_PATH_TAG=platform-ffe2b5a8-pci-_00_05_0-scsi-1_0_0_0
ID_REVISION=.2+5
ID_SERIAL=EQUMD_DVR-MO_MQ_3
ID_SERIAL_SHORT=MQ_3
ID_TYPE=cd
MAJOR=11
MINOR=0
SUBSYSTEM=block
TAGS=:udev-acl:
UDEV_LOG=3
USEC_INITIALIZED=39425573

dmesg cut:

[   37.995639] udevd[43]: starting version 175
[   43.839280] SCSI subsystem initialized
[   44.074912] libata version 3.00 loaded.
[   44.168027] scsi0 : pata_cmd64x
[   44.174100] scsi1 : pata_cmd64x
[   44.175483] ata1: PATA max UDMA/33 cmd 0x1fe02008080 ctl
0x1fe02008100 bmdma 0x1fe02008280 irq 7
[   44.176309] ata2: PATA max UDMA/33 cmd 0x1fe02008180 ctl
0x1fe02008200 bmdma 0x1fe02008288 irq 7
[   44.197377] pata_cmd64x: active 10 recovery 10 setup 3.
[   44.197550] pata_cmd64x: active 10 recovery 10 setup 3.
[   44.366417] ata1.01: NODEV