headers
Greg KH | 1 Sep 2005 03:55
Gravatar

Re: trying 068 with Gentoo

On Wed, Aug 31, 2005 at 11:02:39PM +0200, Bob Barry wrote:
> I installed udev-068 on Gentoo, installed the new /etc/udev/udev.conf
> and /etc/udev/rules.d/50-udev.rules, and restarted with kernel 2.6.13.

You forgot to mention that you ignored the ewarn messages that the 068
gentoo release stated that explained how to fix this problem.

Also, this isn't a Gentoo specific mailing list, if you have Gentoo
specific problems with udev (like this) please enter a bug into their
bugzilla system (bugs.gentoo.org)

thanks,

greg k-h

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Permalink | Reply | 2 comments |
headers
John_Hull | 1 Sep 2005 22:15
Picon
Favicon

Udev support for EDD

I'd like to get feedback from this mailing list on a small project I've
been working on, which is adding support to udev for the persistent
naming of BIOS disk devices via EDD. EDD is mechanism to match x86 BIOS
device names (e.g. int13 device 80h) to Linux device names (e.g.
/dev/sda, /dev/hda), and a kernel module to support this was written by
Matt Domsch (see http://linux.dell.com/projects.shtml#edd for more
information). The EDD module makes device information available in
/sys/firmware/edd/int13_dev8*/, with the directory containing various
information for each device. For example, the first BIOS disk drive
would be int13_dev80, the second int13_dev81, etc. 

My udev persistent namimg implementation for EDD results in the example
following tree:

$ tree /dev/disk/by-bios-id
/dev/disk/by-bios-id/
|-- int13_dev80 -> ../../sda
|-- int13_dev80part1 -> ../../sda1
|-- int13_dev80part2 -> ../../sda2
|-- int13_dev80part5 -> ../../sda5
|-- int13_dev80part6 -> ../../sda6
|-- int13_dev81 -> ../../sdb
|-- int13_dev81part1 -> ../../sdb1
`-- int13_dev81part2 -> ../../sdb2

To match the int13_dev8* device to the kernel block device, the
"mbr_signature" for the device exposed by EDD must be matched to the
disk signature read directly from the device by a user-space program
(signature is 4-bytes long starting at offset 0x1B8 on the disk). To
ensure that each disk can be matched to the corresponding BIOS disk,
(Continue reading)

Permalink | Reply | 6 comments |
headers
Kay Sievers | 2 Sep 2005 02:57

Re: Udev support for EDD

On Thu, Sep 01, 2005 at 03:15:38PM -0500, John_Hull <at> Dell.com wrote:
> I'd like to get feedback from this mailing list on a small project I've
> been working on, which is adding support to udev for the persistent
> naming of BIOS disk devices via EDD. EDD is mechanism to match x86 BIOS
> device names (e.g. int13 device 80h) to Linux device names (e.g.
> /dev/sda, /dev/hda), and a kernel module to support this was written by
> Matt Domsch (see http://linux.dell.com/projects.shtml#edd for more
> information). The EDD module makes device information available in
> /sys/firmware/edd/int13_dev8*/, with the directory containing various
> information for each device. For example, the first BIOS disk drive
> would be int13_dev80, the second int13_dev81, etc. 

Nice to see more *_id programs. :)

> My udev persistent namimg implementation for EDD results in the example
> following tree:
> 
> $ tree /dev/disk/by-bios-id
> /dev/disk/by-bios-id/
> |-- int13_dev80 -> ../../sda
> |-- int13_dev80part1 -> ../../sda1
> |-- int13_dev80part2 -> ../../sda2
> |-- int13_dev80part5 -> ../../sda5
> |-- int13_dev80part6 -> ../../sda6
> |-- int13_dev81 -> ../../sdb
> |-- int13_dev81part1 -> ../../sdb1
> `-- int13_dev81part2 -> ../../sdb2

How about "by-firmware-id" to match the kernel sysfs name?
Or putting the links just in /dev/disk/by-id/* with an edd- prefix?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rajat Jain | 2 Sep 2005 09:57
Picon

ACPI problem with PCI Express Native Hot-plug driver

Hi,

I'm using RHEL4 kernel (2.6.9), and am trying to make PCI Express
Native Hot-plug driver (pciehp) work on my system (My system has two
hot-pluggable PCI Express slots). I am facing following problem, and
would really appreciate if any one can provide any info regarding this
problem.

When I disable the ACPI support in my kernel configuration, the
("non-acpi") pciehp driver inserts successfully and I see the
following two entries appearing in my /sys/bus/pci/slots:

drwxr-xr-x  2 root root 0 Sep  2 14:28 10
drwxr-xr-x  2 root root 0 Sep  2 14:28 11

However, when I enable the ACPI support in the kernel, the controller
initialization fails giving me following error (excerpts):

......
......
pciehp: pfar:cannot locate acpi bridge of PCI 0xb.
pciehp: pciehprm_find_available_resources = 0xffffffff
pciehp: unable to locate PCI configuration resources for hot plug add.
......
......
pciehp: pfar:cannot locate acpi bridge of PCI 0xe.
pciehp: pciehprm_find_available_resources = 0xffffffff
pciehp: unable to locate PCI configuration resources for hot plug add.
......
......
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rajat Jain | 2 Sep 2005 09:58
Picon

Re: ACPI problem with PCI Express Native Hot-plug driver

Sorry I forgot to attach the message logs.

Rajat

On 9/2/05, Rajat Jain <rajat.noida.india <at> gmail.com> wrote:
> Hi,
> 
> I'm using RHEL4 kernel (2.6.9), and am trying to make PCI Express
> Native Hot-plug driver (pciehp) work on my system (My system has two
> hot-pluggable PCI Express slots). I am facing following problem, and
> would really appreciate if any one can provide any info regarding this
> problem.
> 
> When I disable the ACPI support in my kernel configuration, the
> ("non-acpi") pciehp driver inserts successfully and I see the
> following two entries appearing in my /sys/bus/pci/slots:
> 
> drwxr-xr-x  2 root root 0 Sep  2 14:28 10
> drwxr-xr-x  2 root root 0 Sep  2 14:28 11
> 
> However, when I enable the ACPI support in the kernel, the controller
> initialization fails giving me following error (excerpts):
> 
> ......
> ......
> pciehp: pfar:cannot locate acpi bridge of PCI 0xb.
> pciehp: pciehprm_find_available_resources = 0xffffffff
> pciehp: unable to locate PCI configuration resources for hot plug add.
> ......
> ......
(Continue reading)

Permalink | Reply | 3 comments |
headers
Greg KH | 2 Sep 2005 10:12
Gravatar

Re: ACPI problem with PCI Express Native Hot-plug driver

On Fri, Sep 02, 2005 at 04:57:33PM +0900, Rajat Jain wrote:
> Hi,
> 
> I'm using RHEL4 kernel (2.6.9), and am trying to make PCI Express
> Native Hot-plug driver (pciehp) work on my system (My system has two
> hot-pluggable PCI Express slots). I am facing following problem, and
> would really appreciate if any one can provide any info regarding this
> problem.

Can you try 2.6.13?  It is much improved in the pciehp area than 2.6.9.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
Permalink | Reply | 0 comments |
headers
Duncan Sands | 2 Sep 2005 13:41
Picon
Favicon

firmware.agent and trailing newlines

After upgrading to a newer kernel (2.6.12 + ubuntu patches) I'm
having all kinds of problems with the kernel firmware loader.
The first problem is that request_firmware is not loading
firmware that is present.  This is due to firmware.agent
using echo rather than echo -n when writing to loading, i.e.:

load() {
    echo 1 > $SYSFS/$DEVPATH/loading
    cat "$1" > $SYSFS/$DEVPATH/data
    echo 0 > $SYSFS/$DEVPATH/loading
    exit
}

and

    echo -1 > $SYSFS/$DEVPATH/loading

rather than

load() {
    echo -n 1 > $SYSFS/$DEVPATH/loading
    cat "$1" > $SYSFS/$DEVPATH/data
    echo -n 0 > $SYSFS/$DEVPATH/loading
    exit
}

and

    echo -n -1 > $SYSFS/$DEVPATH/loading
(Continue reading)

Permalink | Reply | 2 comments |
headers
John_Hull | 2 Sep 2005 17:13
Picon
Favicon

RE: Udev support for EDD


>How about "by-firmware-id" to match the kernel sysfs name?
>Or putting the links just in /dev/disk/by-id/* with an edd- prefix?

I don't have any particular preference on what to name the directory;
"by-bios-id", "by-firmware-id", or "by-edd-id" are all fine by me. Ild
rather do that, though, than put the links in /dev/disk/by-id.

> To match the int13_dev8* device to the kernel block device, the 
> "mbr_signature" for the device exposed by EDD must be matched to the 
> disk signature read directly from the device by a user-space program 
> (signature is 4-bytes long starting at offset 0x1B8 on the disk). To 
> ensure that each disk can be matched to the corresponding BIOS disk, 
> each disk should have a unique disk signature. In my current 
> implementation with udev, I pass the kernel device (hd* or sd*) to a 
> bash script which reads its signature and then tries to match it to a 
> corresponding mbr_signature in the int13_dev* directories. If there is

> a unique match, it returns this directory to udev, and returns nothing

> otherwise.
> 
> I have placed a rules file and the script that it calls here:
> http://linux.dell.com/files/edd/udev/, as well as a Python module that

> can be used to read and write the signatures. Please review my 
> approach and let me know how I can improve this for eventual inclusion
with udev.

>The edd_id.sh should not check for a loaded module, otherwise it will
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kristen Accardi | 2 Sep 2005 19:46
Picon
Favicon

Re: [Pcihpd-discuss] Re: ACPI problem with PCI Express Native Hot-plug driver

>  
> > Even if no body had faced this problem before, I would really
> > appreciate if any one can provide ANY kind of pointers / information
> > regarding this (As I am willing to explore and solve this, no matter
> > what :-))
> > 
> > TIA
> > 
> > Rajat Jain
> >

Hello,
Would you be willing to test the mainline kernel (2.6.13) to see if you
have the same problem with the most recent version of the driver?  And
attach the logs again please.

Thanks,
Kristen

--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/
Permalink | Reply | 3 comments |
headers
John_Hull | 2 Sep 2005 20:30
Picon
Favicon

RE: Udev support for EDD

Kay,

Your patch looks really good so far (I've been testing on opensuse 10
beta 3). I modified the udev rules to work with edd_id, and put them
here: http://linux.dell.com/files/edd/udev/60-edd.rules. I like your
idea of matching by-*-id to the sysfs name, so I changed it to by-edd-id
to reflect that.

The one problem I noticed is when the disks do not have unique
signatures. For example, on my test box, I made the signatures be 0x00
on both sda and sdb. When I run edd_id for each disk, both spit out
int13_dev81. My thought is that it should return nothing, as we can't
verify which disk is which int13_dev8* device. Thoughts?

    John

> -----Original Message-----
> From: Kay Sievers [mailto:kay.sievers <at> vrfy.org] 
> Sent: Thursday, September 01, 2005 7:58 PM
> To: Hull, John
> Cc: linux-hotplug-devel <at> lists.sourceforge.net
> Subject: Re: Udev support for EDD
> 
> On Thu, Sep 01, 2005 at 03:15:38PM -0500, John_Hull <at> Dell.com wrote:
> > I'd like to get feedback from this mailing list on a small project 
> > I've been working on, which is adding support to udev for the 
> > persistent naming of BIOS disk devices via EDD. EDD is mechanism to 
> > match x86 BIOS device names (e.g. int13 device 80h) to 
> Linux device names (e.g.
> > /dev/sda, /dev/hda), and a kernel module to support this
(Continue reading)

Permalink | Reply | 1 comment |

Gmane