Bug#454493: Display PCI slot for nics, if available
On Thu, Dec 27, 2007 at 07:15:01PM -0200, Otavio Salvador wrote: dann frazier [EMAIL PROTECTED] writes: Yeah. Options here would be: 1) big hammer - write a modprobe wrapper that cleans unused/unloadable modules after every load 2) smaller hammer - write a modprobe wrapper that remembers what was loaded before and, on failure, unloads all newly added, unused, unloadable modules 3) surgical hammer - whatever ends up loading acpihpi knows that, on failure, dock and pci_hotplug should be removed (if unused) fyi, the dependencies loaded, and left unused, eat 9476 (dock) and 28600 (pci_hotplug) bytes. imo, the best and more widly solution would be the 2. That shouldn't be too hard and would allow us to reduce the memory footprint not only on your user case but in general usage too. Might be vearing off topic for this bug, but here's a wrapper I worked up (not yet tested in the d-i environment). -- dann frazier modprobe-and-clean.sh Description: Bourne shell script
Bug#454493: Display PCI slot for nics, if available
dann frazier [EMAIL PROTECTED] writes: imo, the best and more widly solution would be the 2. That shouldn't be too hard and would allow us to reduce the memory footprint not only on your user case but in general usage too. Might be vearing off topic for this bug, but here's a wrapper I worked up (not yet tested in the d-i environment). It looks nice. I think that code might be more clear if you change the cleanup step to be a funtion and it will make simpler to spot what is being done in each case. I see no point in using aggresive policy. It would unload the modules detected by udev and since we provide a small set of modules it looks useless to me. Do you see any possible usage? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
On Mon, Dec 31, 2007 at 09:43:15AM -0200, Otavio Salvador wrote: dann frazier [EMAIL PROTECTED] writes: imo, the best and more widly solution would be the 2. That shouldn't be too hard and would allow us to reduce the memory footprint not only on your user case but in general usage too. Might be vearing off topic for this bug, but here's a wrapper I worked up (not yet tested in the d-i environment). It looks nice. I think that code might be more clear if you change the cleanup step to be a funtion and it will make simpler to spot what is being done in each case. Yes, this does improve readability. I see no point in using aggresive policy. It would unload the modules detected by udev and since we provide a small set of modules it looks useless to me. Do you see any possible usage? No - it was just something I was playing with (see my comment in the code warning people not to use it). Also, I only think it makes sense to include a policy setting if its an option - e.g. an environment variable. If we find only only one policy useful, the others should be dropped to reduce code size/complexity. Attached is a new version that incorporates your factoring suggestion, and does away with the policy options. -- dann frazier modprobe-and-clean.sh Description: Bourne shell script
Bug#454493: Display PCI slot for nics, if available
dann frazier [EMAIL PROTECTED] writes: I think that code might be more clear if you change the cleanup step to be a funtion and it will make simpler to spot what is being done in each case. Yes, this does improve readability. And it did, indeed. This lastest version is much easier to read. :-) Nice job. I see no point in using aggresive policy. It would unload the modules detected by udev and since we provide a small set of modules it looks useless to me. Do you see any possible usage? No - it was just something I was playing with (see my comment in the code warning people not to use it). Also, I only think it makes sense to include a policy setting if its an option - e.g. an environment variable. If we find only only one policy useful, the others should be dropped to reduce code size/complexity. Great. It looks like we just need to put it inside of d-i and see if it gives any regression, otherwise it looks like a nice improvement of what we have now. Have you done any test to see if it changes the memory footprint? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
(Good discussion so far, sorry for the late response..) On Sunday 09 December 2007, Frans Pop wrote: On Friday 07 December 2007, dann frazier wrote: Understood. Note that this implementation doesn't *require* the module, it just takes advantage of it if its available. And, if other non-ACPI platforms begin populating the 'slot' sysfs field in the future, the installer would automatically work with it. Sure, but what use is it to implement it if we're not going to actually use it? Adding support for it IMO also means adding any modules needed to display the info (for platforms that support it of course). My implication is that any installer builds that happen to include the appropriate acpi modules could use this functionality. However, I see you state elsewhere: On Sunday 09 December 2007, Frans Pop wrote: For Dann's usage however, IMO it would really need to be part of the initrd to ensure that we have consistent functionality between installation methods, If consistency between install methods is a goal, then my note above isn't relevant... at least not while slot info requires additional modules. Could you provide some data on what it would cost to add this module to initrds? Needed is total of extra memory used because of increased initrd size the module(s) getting loaded. Ideally we could do this experiment on i386 since its the only architecture I would expect to have ACPI and have tight memory requirements. Unfortunately, I don't have an i386 system that supports the acpiphp module - my systems only support cpqphp and acpiphp refuses to load if the system does not support it. However, if we can make the assumption that memory pressure isn't an issue on systems that support ACPI PCI HotPlug, then the memory lost to module load isn't significant[1]. I compared a standard build of the netboot/i386 flavor, and one where the acpiphp module were added to the acpi-modules udeb. acpiphp depends upon the pci_hotplug and dock modules, so they are also included. build initrd.gz sizeused memory standard 5005534 23864 w/ acpiphp5031680 24176 [1] Of course, acpiphp has module dependencies, and if these aren't cleaned up after a failed load, memory will still be lost to those modules Joey Hess wrote: Frans Pop wrote: eth0: foo bar description, eth0: mac address: xxx:xxx... [slot 1] That would be one way to do it without modifying debconf. You could also get rid of the eth0: prefix if you wanted to by using Choices-C. I'm probably just being thick, but what exactly are you proposing here? Debconf would display the above example as: eth0: foo bar description eth0: mac address: xxx:xxx... [slot 1] I like this idea, and Frans' suggestion to indent instead of duplicating the interface name would make it looks pretty nice. I can't think of any better way to do it w/o extending debconf. If noone has any major objections, I'll see if I can work up a patch. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
dann frazier [EMAIL PROTECTED] writes: [1] Of course, acpiphp has module dependencies, and if these aren't cleaned up after a failed load, memory will still be lost to those modules It means that we'd need to find a way to get those dependencies and walk throught them removing the unused ones. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
On Thu, Dec 27, 2007 at 05:09:38PM -0200, Otavio Salvador wrote: dann frazier [EMAIL PROTECTED] writes: [1] Of course, acpiphp has module dependencies, and if these aren't cleaned up after a failed load, memory will still be lost to those modules It means that we'd need to find a way to get those dependencies and walk throught them removing the unused ones. Yeah. Options here would be: 1) big hammer - write a modprobe wrapper that cleans unused/unloadable modules after every load 2) smaller hammer - write a modprobe wrapper that remembers what was loaded before and, on failure, unloads all newly added, unused, unloadable modules 3) surgical hammer - whatever ends up loading acpihpi knows that, on failure, dock and pci_hotplug should be removed (if unused) fyi, the dependencies loaded, and left unused, eat 9476 (dock) and 28600 (pci_hotplug) bytes. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
dann frazier [EMAIL PROTECTED] writes: On Thu, Dec 27, 2007 at 05:09:38PM -0200, Otavio Salvador wrote: dann frazier [EMAIL PROTECTED] writes: [1] Of course, acpiphp has module dependencies, and if these aren't cleaned up after a failed load, memory will still be lost to those modules It means that we'd need to find a way to get those dependencies and walk throught them removing the unused ones. Yeah. Options here would be: 1) big hammer - write a modprobe wrapper that cleans unused/unloadable modules after every load 2) smaller hammer - write a modprobe wrapper that remembers what was loaded before and, on failure, unloads all newly added, unused, unloadable modules 3) surgical hammer - whatever ends up loading acpihpi knows that, on failure, dock and pci_hotplug should be removed (if unused) fyi, the dependencies loaded, and left unused, eat 9476 (dock) and 28600 (pci_hotplug) bytes. imo, the best and more widly solution would be the 2. That shouldn't be too hard and would allow us to reduce the memory footprint not only on your user case but in general usage too. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
On Friday 07 December 2007, Joey Hess wrote: dann frazier wrote: * Modify cdebconf to support multi-line choice fields. Make each interface choice be a multi-lined option that includes things like vendor, model, mac, slot. eth0: foo bar description, eth0: mac address: xxx:xxx... [slot 1] That would be one way to do it without modifying debconf. You could also get rid of the eth0: prefix if you wanted to by using Choices-C. I'm probably just being thick, but what exactly are you proposing here? Having the description and then having other details behind that on the same line separated by a comma obviously will not work as most of it will just be truncated as it's over the screen width. What I have been thinking of is allowing to switch between the two: == eth0: regular description A eth1: regular description B eth2: regular description B Show interface MAC address and slot information(select this line) == eth0: xx:xx:xx:xx:xx:xx [Slot Q] (+ other info?) eth1: yy:yy:yy:yy:yy:yy [Slot R] eth2: zz:zz:zz:zz:zz:zz [Slot S] Show interface description == This could be done with existing debconf. Although while all these controls and detail can be nice, I'd generally prefer that d-i just figured out which nic has link and a dhcp server and got on with it. We already have the test for the link (although I'm not sure that it works in all cases). Any ideas on how to test for a dhcp server in netcfg? Maybe using something like dhcping on all NICs where a link is detected? One problem is that the available version of dhcping requires a specific server as target and we'd really want to do a broadcast. # dhcping -r -h 00:16:76:04:ff:09 no answer # dhcping -r -h 00:16:76:04:ff:09 -s elrond Got answer from: 10.19.66.2 Although it can be tricked (but then returns with error 1): # dhcping -r -h 00:16:76:04:ff:09 -s 255.255.255.255 Got answer from: 10.19.66.2 received from 10.19.66.2, expected from 255.255.255.255 no answer You'd then also still need to solve the case where you get replies from different (sets of?) dhcp servers on different NICs, and of course the case where there is no dhcp server still needs to be handled without too much delay due to timeouts. signature.asc Description: This is a digitally signed message part.
Bug#454493: Display PCI slot for nics, if available
On Friday 07 December 2007, Otavio Salvador wrote: In fact, as to Otavio's point, it probably makes sense to do the module loading outside of hw-detect (e.g. his acpi-support-udeb suggestion), and just let hw-detect use the interface if its available. Yes, I think it's starting to makes sense to have something like that and put all this in one cannonical place. Does someone objects if I start to prepare this udeb for review? I still don't see this. If that means that udeb is going to be part of initrds, I don't see why it should be separate from hw-detect. Or is Otavio referring to to a separate kernel udeb? In that case again, if it is going to be part of the initrd, why not just add it to the existing acpi-modules udeb. For Otavio's usage (laptop detection), it does not _need_ to be part of the initrd and then a separate modules udeb could make sense, but it still could be loaded in hw-detect as we always have at least one hw-detect run after additional udebs have been loaded. For Dann's usage however, IMO it would really need to be part of the initrd to ensure that we have consistent functionality between installation methods, so creating separate udebs for it makes absolutely no sense. And then we come back to my earlier question: is being able to show slot info worth increasing the size of initrds and memory usage because the acpi module is loaded. Note that every udeb that is added also brings its own overhead! signature.asc Description: This is a digitally signed message part.
Bug#454493: Display PCI slot for nics, if available
On Friday 07 December 2007, dann frazier wrote: On Thu, Dec 06, 2007 at 01:34:25AM +0100, Frans Pop wrote: On Wednesday 05 December 2007, dann frazier wrote: This patch to hw-detect adds slot information, if available, to the network device name. Its not uncommon for HP (or our customers) to have systems with many network devices, and knowing the physical slot number of an adapter makes configuration that much easier. I have several reservations against this patch: - to have it work for all installation methods you'd need to to include this acpi module (and others?) in initrds, which is something we don't do lightly [1] Understood. Note that this implementation doesn't *require* the module, it just takes advantage of it if its available. And, if other non-ACPI platforms begin populating the 'slot' sysfs field in the future, the installer would automatically work with it. Sure, but what use is it to implement it if we're not going to actually use it? Adding support for it IMO also means adding any modules needed to display the info (for platforms that support it of course). Could you provide some data on what it would cost to add this module to initrds? Needed is total of extra memory used because of increased initrd size the module(s) getting loaded. In fact, as to Otavio's point, it probably makes sense to do the module loading outside of hw-detect (e.g. his acpi-support-udeb suggestion), and just let hw-detect use the interface if its available. See my reply to Otavio's mail. - I'm not sure that as a user it would be clear to me what exactly a Slot is in this context I could change this to PCI Slot or PCI Card Slot, and would even prefer it, but that will of course take more space. Yes, so we really need some different implementation. I still feel that PCI slot is not something that is meaningful to a lot of end users, although of course it would be to sysadmins. Therefore I don't really like the idea of showing it by default together with the description. I'd prefer showing it on a separate disambiguation screen (see my reply to Joey's mail). - looking at your screenshot it does not seem to add all that much identification as there are still several NICs with identical slots The snapshot was taken from a machine w/ dual-port cards installed, so it is correct for both nics to claim the same slot. This case does leave some ambiguity, but much less ambiguity than before. Showing the MAC address would remove _all_ ambiguity and would not require loading any additional modules. - I'm not sure that it makes sense to print slot if it's the only identification Can you restate this one - I didn't really follow it. It's based on this change (indentation reduced): - if [ $vendorname ] || [ $devicename ]; then - echo $dev:$vendorname $devicename /etc/network/devnames + if [ $vendorname ] || [ $devicename ] || [ $slot ]; then + echo $dev:$slot$vendorname $devicename /etc/network/devnames Adding '|| [ $slot ]' means that slot could be added if both vendor and device are empty. That is probably unlikely, but if it would happen I wonder if it is desirable. I'd suggest to only write a line if at least vendor or device are available. We've had other requests to provide additional identification of NICs (see #450605 and merged BRs) and so far we (or at least I) have been thinking of some way to display the MAC address, possibly by allowing to switch between display of the current descriptions and MAC address. That would help some users, but I'd like to see us find a more general way to display all the available information that a user might use for identification. And I expect a separate display, or view for each may prove not to scale. See my reply to Joey for an example of my proposal. I do like the genearl principle of Geert's proposal: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450605#31 With the exception that I don't like splitting the option list from the selection widget (and as Bastian points out, its not possible anyway). Also, Geert's proposal to show all details on a single screen is totally unworkable if you _do_ have 20 or so NICs in a system. Some brainstorming: * Modify cdebconf to permit per-option descriptions, and use those descriptions to provide details about each nic. Frontends could use this to implement a more info button, or just include the description text in-line. * Modify cdebconf to support multi-line choice fields. Make each interface choice be a multi-lined option that includes things like vendor, model, mac, slot. Well, if someone is willing to do the work to extend debconf... * Change the flow from select iface - configure iface to: select iface v display info about iface confirm v configure iface This is
Bug#454493: Display PCI slot for nics, if available
Frans Pop wrote: eth0: foo bar description, eth0: mac address: xxx:xxx... [slot 1] That would be one way to do it without modifying debconf. You could also get rid of the eth0: prefix if you wanted to by using Choices-C. I'm probably just being thick, but what exactly are you proposing here? Debconf would display the above example as: eth0: foo bar description eth0: mac address: xxx:xxx... [slot 1] We already have the test for the link (although I'm not sure that it works in all cases). Any ideas on how to test for a dhcp server in netcfg? Maybe using something like dhcping on all NICs where a link is detected? It could just run dhclient on all NICs in parallel and take the winner. -- see shy jo signature.asc Description: Digital signature
Bug#454493: Display PCI slot for nics, if available
On Sunday 09 December 2007, Joey Hess wrote: Debconf would display the above example as: eth0: foo bar description eth0: mac address: xxx:xxx... [slot 1] Ah, so basically just have two lines and two effectively identical choices per NIC. Guess that could work. Maybe we could even code it so that that is only done if there are duplicate descriptions. Maybe we should not duplicate the eth0:, but indent with spaces. Would it affect preseeding? What did you think of my proposal? We already have the test for the link (although I'm not sure that it works in all cases). Any ideas on how to test for a dhcp server in netcfg? Maybe using something like dhcping on all NICs where a link is detected? It could just run dhclient on all NICs in parallel and take the winner. Hmm. Doesn't dhclient do that anyway if you call it without a specific interface name? We would indeed have to identify the winner for correct creation of /etc/interfaces. It would however mean either moving dhclient from netcfg to ethdetect or moving interface selection (for the static configuration case) from ethdetect to netcfg. signature.asc Description: This is a digitally signed message part.
Bug#454493: Display PCI slot for nics, if available
dann frazier [EMAIL PROTECTED] writes: ... In fact, as to Otavio's point, it probably makes sense to do the module loading outside of hw-detect (e.g. his acpi-support-udeb suggestion), and just let hw-detect use the interface if its available. Yes, I think it's starting to makes sense to have something like that and put all this in one cannonical place. Does someone objects if I start to prepare this udeb for review? ... We've had other requests to provide additional identification of NICs (see #450605 and merged BRs) and so far we (or at least I) have been thinking of some way to display the MAC address, possibly by allowing to switch between display of the current descriptions and MAC address. That would help some users, but I'd like to see us find a more general way to display all the available information that a user might use for identification. And I expect a separate display, or view for each may prove not to scale. I do like the genearl principle of Geert's proposal: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450605#31 With the exception that I don't like splitting the option list from the selection widget (and as Bastian points out, its not possible anyway). Some brainstorming: * Modify cdebconf to permit per-option descriptions, and use those descriptions to provide details about each nic. Frontends could use this to implement a more info button, or just include the description text in-line. * Modify cdebconf to support multi-line choice fields. Make each interface choice be a multi-lined option that includes things like vendor, model, mac, slot. * Change the flow from select iface - configure iface to: select iface v display info about iface confirm v configure iface This is probably the only one possible w/ today's cdebconf, but its pretty non-intuitive. I personaly like the description idea since it looks to be more suitable for the way we have the dialogs now. Others? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
On Thu, Dec 06, 2007 at 01:34:25AM +0100, Frans Pop wrote: On Wednesday 05 December 2007, dann frazier wrote: This patch to hw-detect adds slot information, if available, to the network device name. Its not uncommon for HP (or our customers) to have systems with many network devices, and knowing the physical slot number of an adapter makes configuration that much easier. I have several reservations against this patch: - to have it work for all installation methods you'd need to to include this acpi module (and others?) in initrds, which is something we don't do lightly [1] Understood. Note that this implementation doesn't *require* the module, it just takes advantage of it if its available. And, if other non-ACPI platforms begin populating the 'slot' sysfs field in the future, the installer would automatically work with it. In fact, as to Otavio's point, it probably makes sense to do the module loading outside of hw-detect (e.g. his acpi-support-udeb suggestion), and just let hw-detect use the interface if its available. - the slot indication is not translatable in the current patch I didn't think to make this translatable, but yes, it should be. - the descriptions are already quite long and this will truncate some of them even more than they already are Yeah, I expected someone would point this out. There are possible hacks like filtering out redundant words/phrases like Ethernet Controller, but I think what we really need is to get out of the single-line description, more on this below. - I'm not sure that as a user it would be clear to me what exactly a Slot is in this context I could change this to PCI Slot or PCI Card Slot, and would even prefer it, but that will of course take more space. - looking at your screenshot it does not seem to add all that much identification as there are still several NICs with identical slots The snapshot was taken from a machine w/ dual-port cards installed, so it is correct for both nics to claim the same slot. This case does leave some ambiguity, but much less ambiguity than before. - it seems only a partial solution as not all NICs will be get a slot identifier Again, it decreases ambiguity. In my screenshot, you can see that two nics aren't in slots because they are built into the system board. You don't know which one is which, but in a system with 20 nics, it certainly saves you some time finding the right one. (And 20 NICs really isn't a contrived example, but is of course a small minority of Debian users). - I'm not sure that it makes sense to print slot if it's the only identification Can you restate this one - I didn't really follow it. We've had other requests to provide additional identification of NICs (see #450605 and merged BRs) and so far we (or at least I) have been thinking of some way to display the MAC address, possibly by allowing to switch between display of the current descriptions and MAC address. That would help some users, but I'd like to see us find a more general way to display all the available information that a user might use for identification. And I expect a separate display, or view for each may prove not to scale. I do like the genearl principle of Geert's proposal: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450605#31 With the exception that I don't like splitting the option list from the selection widget (and as Bastian points out, its not possible anyway). Some brainstorming: * Modify cdebconf to permit per-option descriptions, and use those descriptions to provide details about each nic. Frontends could use this to implement a more info button, or just include the description text in-line. * Modify cdebconf to support multi-line choice fields. Make each interface choice be a multi-lined option that includes things like vendor, model, mac, slot. * Change the flow from select iface - configure iface to: select iface v display info about iface confirm v configure iface This is probably the only one possible w/ today's cdebconf, but its pretty non-intuitive. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
dann frazier wrote: * Modify cdebconf to support multi-line choice fields. Make each interface choice be a multi-lined option that includes things like vendor, model, mac, slot. eth0: foo bar description, eth0: mac address: xxx:xxx... [slot 1] That would be one way to do it without modifying debconf. You could also get rid of the eth0: prefix if you wanted to by using Choices-C. Although while all these controls and detail can be nice, I'd generally prefer that d-i just figured out which nic has link and a dhcp server and got on with it. -- see shy jo signature.asc Description: Digital signature
Bug#454493: Display PCI slot for nics, if available
dann frazier [EMAIL PROTECTED] writes: Currently this patch only attempts to load the acpiphp driver - it should probably try and load others as well (e.g. pciehp shchp, and the future possible pci_slot). Why acpihp isn't loaded by udev automaticaly? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
Package: hw-detect
Version: 1.58
Severity: wishlist
Tags: patch
The linux kernel may expose slot information for PCI devices in
sysfs. Currently slot info is only exposed if the PCI device is
hotpluggable and the associated hotplug driver is loaded. However,
work is underway[1] to expose slot information for non-hotplug pci
devices that are exposed via ACPI.
This patch to hw-detect adds slot information, if available, to the
network device name. Its not uncommon for HP (or our customers) to
have systems with many network devices, and knowing the physical slot
number of an adapter makes configuration that much easier.
Currently this patch only attempts to load the acpiphp driver - it
should probably try and load others as well (e.g. pciehp shchp, and
the future possible pci_slot).
Attached is a screen shot of a d-i build w/ this patch. Some nics
share the same slot because they are dual-port cards, and some nics
have no slot info because they are not hotplug and I'm using a
standard kernel that does not yet have non-hotplug slot support.
[1] http://lkml.org/lkml/2007/11/12/263
http://lkml.org/lkml/2007/11/14/331
http://lkml.org/lkml/2007/11/17/126
Index: hw-detect/debian/changelog
===
--- hw-detect/debian/changelog (revision 50286)
+++ hw-detect/debian/changelog (working copy)
@@ -1,3 +1,9 @@
+hw-detect (1.59) UNRELEASED; urgency=low
+
+ * Display the PCI slot for network device, if exported in sysfs
+
+ -- dann frazier [EMAIL PROTECTED] Tue, 04 Dec 2007 18:02:24 -0700
+
hw-detect (1.58) unstable; urgency=low
* Install acpi-support-base, needed now to get power button shutdowns to
Index: hw-detect/sysfs-update-devnames.sh
===
--- hw-detect/sysfs-update-devnames.sh (revision 50286)
+++ hw-detect/sysfs-update-devnames.sh (working copy)
@@ -2,6 +2,35 @@
# Make sure that /etc/network/devnames is up to date, using sysfs. In
# hotplug land, we may not get a chance to update it otherwise.
+# This currently only works for hotplug devices, but may work for
+# others devices in the future.
+iface_to_slot() {
+ iface=$1
+
+ if [ ! -h /sys/class/net/$iface/device ]; then
+ return 1
+ fi
+
+ modprobe acpiphp || true
+
+ if [ ! -d /sys/bus/pci/slots ]; then
+ return 2
+ fi
+
+ ifdevpath=$(readlink /sys/class/net/$iface/device)
+ ifaddr=${ifdevpath##*/}
+ ifaddr=${ifaddr%.*}
+
+ ifslot=
+ for slot in /sys/bus/pci/slots/*; do
+ if [ $ifaddr = $(cat $slot/address) ]; then
+ echo ${slot##*/}
+ return 0
+ fi
+ done
+ return 4
+}
+
if [ ! -d /sys/class/net ] || ! type lspci /dev/null 21; then
exit
fi
@@ -14,12 +43,13 @@
[ -f /sys/class/net/$dev/device/device ]; then
vendor=$(sed 's/^0x//' /sys/class/net/$dev/device/vendor)
device=$(sed 's/^0x//' /sys/class/net/$dev/device/device)
+ slot=[Slot $(iface_to_slot $dev)] || slot=
# 'tail -n 1' because for some reason lspci outputs two
# Device: lines.
vendorname=$(lspci -d $vendor:$device -m -v | grep ^Vendor:
| tail -n 1 | sed 's/^Vendor:[[:space:]]*//; s/,/\\,/g')
devicename=$(lspci -d $vendor:$device -m -v | grep ^Device:
| tail -n 1 | sed 's/^Device:[[:space:]]*//; s/,/\\,/g')
- if [ $vendorname ] || [ $devicename ]; then
- echo $dev:$vendorname $devicename
/etc/network/devnames
+ if [ $vendorname ] || [ $devicename ] || [ $slot ]; then
+ echo $dev:$slot$vendorname $devicename
/etc/network/devnames
fi
elif [ $(readlink -f /sys/class/net/$dev/device/bus) =
/sys/bus/ieee1394 ] || \
[ $(readlink -f /sys/class/net/$dev/device/bus) =
/sys/bus/firewire ]; then
--
dann frazier
attachment: nic-slot-info.png
Bug#454493: Display PCI slot for nics, if available
On Wednesday 05 December 2007, dann frazier wrote: This patch to hw-detect adds slot information, if available, to the network device name. Its not uncommon for HP (or our customers) to have systems with many network devices, and knowing the physical slot number of an adapter makes configuration that much easier. I have several reservations against this patch: - to have it work for all installation methods you'd need to to include this acpi module (and others?) in initrds, which is something we don't do lightly [1] - the slot indication is not translatable in the current patch - the descriptions are already quite long and this will truncate some of them even more than they already are - I'm not sure that as a user it would be clear to me what exactly a Slot is in this context - looking at your screenshot it does not seem to add all that much identification as there are still several NICs with identical slots - it seems only a partial solution as not all NICs will be get a slot identifier - I'm not sure that it makes sense to print slot if it's the only identification We've had other requests to provide additional identification of NICs (see #450605 and merged BRs) and so far we (or at least I) have been thinking of some way to display the MAC address, possibly by allowing to switch between display of the current descriptions and MAC address. For me at least making the slot identification translatable (which is not that hard) would be a blocker for acceptance of this patch. On Thursday 06 December 2007, dann frazier wrote: I believe that currently the only way to know if a machine supports acpiphp is to load it. This seems to match up pretty well with my observations of other acpi drivers. acpid seems to take ownership of loading acpi modules like battery, fan, thermal, etc - it simply modprobes them and lets the driver do the discovery. Maybe it should also be loading acpiphp? Perhaps. Does d-i do anything wrt loading acpi drivers today (other than installing acpid into the target)? For x86 some acpi modules are available during install and are loaded (thermal, fan and processor). For powerpc some drivers are loaded for some systems to avoid the fans running wild. See in rootskel/src/lib/debian-installer-startup.d: S05acpi-linux-x86, S05fancontrol-linux-powerpc Cheers, FJP [1] As a porter you have of course quite considerable freedom to decide what to include in initrds for your arches. signature.asc Description: This is a digitally signed message part.
Bug#454493: Display PCI slot for nics, if available
On Wed, Dec 05, 2007 at 05:03:41PM -0200, Otavio Salvador wrote: dann frazier [EMAIL PROTECTED] writes: Currently this patch only attempts to load the acpiphp driver - it should probably try and load others as well (e.g. pciehp shchp, and the future possible pci_slot). Why acpihp isn't loaded by udev automaticaly? I'm probably not the best person to answer that question, but I can give you some handwavy guesswork :) I'm guessing that you're asking this because you've seen other pci hotplug drivers get loaded by udev. I've noticed this too - shpchp loads on some of my boxes, so I looked to see why. Turns out that shpchp registers itself as a driver for pci devices that are in the pci bridge class, so this mapping is available to udev in modules.pcimap. acpiphp doesn't register itself for any pci devices - in fact, the machine I test on doesn't show any pci bridges devices in lspci, so I'm assuming they're transparent to udev as well. The devices on this bridge work just fine, they are just not hotpluggable until the acpiphp module is loaded. I wondered if this was always the case with ACPI-described bridges, so I asked Matthew Wilcox: dannf willy: is it the case that pci bridges described by ACPI never (or not always) appear as pci devices themselves? willy dannf: No correlation. If they're PCI-PCI bridges, they will show up in the PCI namespace, but there's no way to tell whether or not they support acpiphp I believe that currently the only way to know if a machine supports acpiphp is to load it. This seems to match up pretty well with my observations of other acpi drivers. acpid seems to take ownership of loading acpi modules like battery, fan, thermal, etc - it simply modprobes them and lets the driver do the discovery. Maybe it should also be loading acpiphp? Perhaps. Does d-i do anything wrt loading acpi drivers today (other than installing acpid into the target)? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
dann frazier [EMAIL PROTECTED] writes: ... I believe that currently the only way to know if a machine supports acpiphp is to load it. This seems to match up pretty well with my observations of other acpi drivers. acpid seems to take ownership of loading acpi modules like battery, fan, thermal, etc - it simply modprobes them and lets the driver do the discovery. Maybe it should also be loading acpiphp? Perhaps. Maybe we might then think about something general for this type of problem. Does d-i do anything wrt loading acpi drivers today (other than installing acpid into the target)? Yes. thermal and fan modules, IIRC but I'd also want to get batteries detected so laptop-detect could work better. I'm thinking that we might consider to have an acpi-support-udeb package for that kind of thing be centralized on one cannonical place. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
