geninitrd fails on masked vendor:device entries.

Bug #715930 reported by Paweł Sikora
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
PLD Linux
New
Undecided
Unassigned

Bug Description

the new logic in /lib/geninitrd/mod-sata.sh is broken. it simply doesn't work for masked vendor's devices.

e.g., for jmicorn sata/ide controlers we have masked 0xffff (all devices) entries:

pata_jmicron 0x0000197b 0x0000ffff 0x0000ffff 0x0000ffff 0x00010100 0x00ffff00 0x0
jmicron 0x0000197b 0x0000ffff 0x0000ffff 0x0000ffff 0x00010100 0x00ffff00 0x0

in such situation the awk logic which uses equality operator won't work and return empty list of kernel modules.
this is a serious bug.

geninitrd-10000.31-0.1.noarch

summary: - geninitrd fails on masked vendor:class devices.
+ geninitrd fails on masked vendor:devices entries.
summary: - geninitrd fails on masked vendor:devices entries.
+ geninitrd fails on masked vendor:device entries.
description: updated
Revision history for this message
Elan Ruusamäe (glen666) wrote :

1. geninitrd -v output needed
(i.e: geninitrd -f --initrdfs=rom /tmp/test.img `uname -r` -v

2. lspci -n output needed

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :
Download full text (3.4 KiB)

[root@szymonk ~]# geninitrd -f --initrdfs=rom /tmp/test.img `uname -r` -v
geninitrd: # $Revision: 12081 $ $Date: 2011-01-24 00:36:56 +0200 (E, 24 jaan 2011) $
geninitrd: Using _lib: lib64
geninitrd: Using initrd_dir: /usr/lib64/initrd
geninitrd: find_tool: found /usr/lib64/initrd/busybox
geninitrd: find_tool: did not found any of: /usr/lib64/initrd/cryptsetup /sbin/cryptsetup-initrd
geninitrd: find_tool: did not found any of: /usr/lib64/initrd/dmraid /sbin/dmraid-initrd
geninitrd: find_tool: found /usr/lib64/initrd/lvm
geninitrd: find_tool: did not found any of: /usr/lib64/initrd/mdassemble /sbin/initrd-mdassemble
geninitrd: find_tool: found /sbin/mdadm
geninitrd: find_tool: found /usr/lib64/initrd/blkid
geninitrd: find_tool: did not found any of: /usr/lib64/initrd/udevd /sbin/initrd-udevd
geninitrd: find_tool: did not found any of: /usr/lib64/initrd/udevadm /sbin/initrd-udevadm
geninitrd: find_tool: did not found any of: /usr/lib64/initrd/resume /usr/lib64/suspend/resume /usr/sbin/resume
geninitrd: find_tool: did not found any of: /usr/sbin/splash_geninitramfs /usr/bin/splash_geninitramfs
geninitrd: find_tool: did not found any of: /usr/sbin/splash_geninitramfs /usr/bin/splash_geninitramfs
geninitrd: find_tool: did not found any of: /bin/splash.bin
geninitrd: find_tool: found /sbin/v86d
geninitrd: Using modprobe -c to get modules config
geninitrd: Finding SATA modules (class=0x0106)
geninitrd: Using /dev/sda1 as device for rootfs
geninitrd: Finding modules for device path /dev/sda1
geninitrd: Finding SCSI modules using scsi_hostadapter
geninitrd: Building initrd...
geninitrd: + cp /usr/lib64/initrd/busybox /root/tmp/initrd.tWKExX/bin/busybox
geninitrd: Loading module [scsi_mod] with options [scan=sync ]
geninitrd: Loading module [libata]
geninitrd: Loading module [pata_amd]
geninitrd: Loading module [sata_nv]
geninitrd: Loading module [mbcache]
geninitrd: Loading module [jbd]
geninitrd: Loading module [ext3]
geninitrd: Loading module [crc-t10dif]
geninitrd: Loading module [sd_mod]
geninitrd: Loading module [scsi_wait_scan]
geninitrd: Adding BLKID support to initrd
geninitrd: + cp /usr/lib64/initrd/blkid /root/tmp/initrd.tWKExX/bin/blkid
geninitrd: Adding rootfs finding based on kernel cmdline root= option support.
geninitrd: Creating rom image /root/tmp/initrd.img-NcngR0
geninitrd: image size: 2048 KiB (/root/tmp/initrd.tWKExX)
geninitrd: finding compressor: lzo gzip xz lzma bzip2 (via yes)
geninitrd: Compressing /tmp/test.img with gzip
[root@szymonk ~]# lspci -n
00:00.0 0500: 10de:02f4 (rev a2)
00:00.1 0500: 10de:02fa (rev a2)
00:00.2 0500: 10de:02fe (rev a2)
00:00.3 0500: 10de:02f8 (rev a2)
00:00.4 0500: 10de:02f9 (rev a2)
00:00.5 0500: 10de:02ff (rev a2)
00:00.6 0500: 10de:027f (rev a2)
00:00.7 0500: 10de:027e (rev a2)
00:04.0 0604: 10de:02fb (rev a1)
00:08.0 0500: 10de:0369 (rev a1)
00:09.0 0601: 10de:0360 (rev a2)
00:09.1 0c05: 10de:0368 (rev a2)
00:09.2 0500: 10de:036a (rev a2)
00:0a.0 0c03: 10de:036c (rev a1)
00:0a.1 0c03: 10de:036d (rev a2)
00:0c.0 0101: 10de:036e (rev a1)
00:0d.0 0101: 10de:037f (rev a2)
00:0d.1 0101: 10de:037f (rev a2)
00:0d.2 0101: 10de:037f (rev a2)
...

Read more...

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :

03:00.0 0106: 197b:2363 (rev 02)
03:00.1 0101: 197b:2363 (rev 02

Revision history for this message
Elan Ruusamäe (glen666) wrote :

this patch makes it accept module subid with "0x0000ffff"

this resulting these modules:
jmicron
pata_jmicron
ahci

what should be done with these? all of them be loaded?

matching modules.pcimap entries for those modules:
geninitrd/tests $ grep -E 'jmicron|pata_jmicron|ahci' modules.pcimap-2.6.33.4-1 | grep 197b
# pci module vendor device subvendor subdevice class class_mask driver_data
jmicron 0x0000197b 0x0000ffff 0x0000ffff 0x0000ffff 0x00010100 0x00ffff00 0x0
pata_jmicron 0x0000197b 0x0000ffff 0x0000ffff 0x0000ffff 0x00010100 0x00ffff00 0x0
ahci 0x0000197b 0x0000ffff 0x0000ffff 0x0000ffff 0x00010601 0x00ffffff 0x0

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :

all libata based (see 'depends:' in modinfo result) modules should be prefered and loaded.

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :

one more thing. instead of comparing against specific 0xffff mask there'd be a bit-and operation:

if ((lspci-device-id & device-mask-from-kernel-pcimap)==lspci-device-id) then module-matched.

Revision history for this message
Elan Ruusamäe (glen666) wrote : Re: [Bug 715930] Re: geninitrd fails on masked vendor:device entries.

On 10/02/11 19:57, Paweł Sikora wrote:
> one more thing. instead of comparing against specific 0xffff mask
> there'd be a bit-and operation:
>
> if ((lspci-device-id & device-mask-from-kernel-pcimap)==lspci-device-id)
> then module-matched.

propose some code to do bitwise hex string matching in limited base
tools (awk, sed, grep...)

awk doesn't do it natively:

$ awk '{print 1&2}'
awk: 1: unexpected character '&'

--
glen

Revision history for this message
Elan Ruusamäe (glen666) wrote :

please test current trunk for fix and regressions

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :

with current trunk we get:

geninitrd: Loading module [scsi_mod] with options [scan=sync ]
geninitrd: Loading module [libata]
geninitrd: Loading module [pata_amd]
geninitrd: Loading module [sata_nv]
geninitrd: Loading module [mbcache]
geninitrd: Loading module [jbd]
geninitrd: Loading module [ext3]
geninitrd: Loading module [pata_jmicron] <===== ok.
geninitrd: Loading module [libahci]
geninitrd: Loading module [ahci]
geninitrd: Loading module [ide-core]
geninitrd: Loading module [jmicron]
geninitrd: Loading module [crc-t10dif]
geninitrd: Loading module [sd_mod]
geninitrd: Loading module [scsi_wait_scan]

and it looks ok.

Revision history for this message
Elan Ruusamäe (glen666) wrote :

sorry, you were wrong, there is no bitwise matching, arekm looked it up from code.
so reverted bitwise and added special value only

could you retest with trunk again?

the code:
                for(map = pcimap_list; map != NULL; map = map->next) {
                        if (((map->class ^ class) & map->class_mask) == 0 &&
                            ((desired_class ^ class) & desired_classmask)==0 &&
                            (map->dev == DEVICE_ANY ||
                             map->dev == dev->device_id) &&
                            (map->vendor == VENDOR_ANY ||
                             map->vendor == dev->vendor_id) &&
                            (map->subsys_dev == DEVICE_ANY ||
                             map->subsys_dev == subsys_dev) &&
                            (map->subsys_vendor == VENDOR_ANY ||
                             map->subsys_vendor == subsys_vendor) &&
                            prevmodule != map->module) {
                                printf("%s\n", map->module);
                                prevmodule = map->module;
                        }
                }

Revision history for this message
Elan Ruusamäe (glen666) wrote :

also:
geninitrd: Loading module [pata_jmicron] <===== ok.
...
geninitrd: Loading module [jmicron]
...

both modules being loaded is not problem for you?

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :

the latest mod-sata works fine.

both pata_jmicron and jmicron works for me but there're known cases where legacy
jmicron (and generally legacy ide drivers) hangs on recent hardware, so we should
load only libata based modules. from the other side we can't simply disable legacy
drivers in kernel for people with working ancient driver/hardware.

Revision history for this message
Paweł Sikora (pluto-pld-linux) wrote :

i think that we can ask user which module to load and use explicit value or all matching modules.

example:

$ cat select.sh
#!/bin/zsh

tempfile="$(mktemp)"
dialog --menu "select module" 15 70 5 pata_jmicron "new libata based" jmicron "legacy" 2>${tempfile}
if [ $? -eq 0 ]; then
        echo "[loading $(cat $tempfile)]"
else
# cancel/esc.
        echo "[loading all modules...]"
fi

Revision history for this message
Elan Ruusamäe (glen666) wrote :

ui is out of scope for geninitrd. sorry :)

if jmicron is unwanted (causes problems), then it should blacklisted in modprobe config, ideally geninitrd would not see that module (needs to be tested if that's true)

those ui-dialogs can be added to some installer which asks user's decision and creates blacklist entry, and then geninitrd is invoked.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.