Fumitoshi UKAI | 27 Apr 2001 19:56
Picon
Favicon

Bug#95354: net.agent and ifdown

Hi,

I'm maintainer of hotplug deb package, and got the bug report
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=95354&repeatmerged=yes

I'm not sure, but would this patch solve this problem?

--- hotplug-2001-04-24.orig/etc/hotplug/net.agent
+++ hotplug-2001-04-24/etc/hotplug/net.agent
 <at>  <at>  -52,6 +52,16  <at>  <at> 
     mesg $1 $ACTION event not handled
     ;;

+unregister)
+    if [ -x /sbin/ifdown ]; then
+	if [ "$DEBUG" != "" ]; then
+	    mesg invoke ifdown $INTERFACE
+	fi
+	exec /sbin/ifdown $INTERFACE
+    fi
+    mesg $1 $ACTION event not handled
+    ;;
+
 *)
     if [ "$DEBUG" != "" ]; then
 	mesg NET $ACTION event not supported

Regards,
Fumitoshi UKAI
(Continue reading)

David Brownell | 28 Apr 2001 18:08

Re: Bug#95354: net.agent and ifdown

>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=95354&repeatmerged=yes

Hmm, interesting ... Debian "ifup" maintains non-kernel state,
trying to track (augment?) kernel state.  I'd suspect that's likely
to be a bit fragile (as in this bug).

> I'm not sure, but would this patch solve this problem?

The interface is not listed in the kernel state any more,
so "ifdown $INTERFACE" will fail at least on RH7
(which I just checked).  Not that the network hotplug
code cares about agent failure status code now, but I'd
not return with that "ifdown" failure status.  Other than
that, it looks like it's worth trying.

The "hot unplug" paths deserve more attention than they've
gotten so far.  That's not just in relation to the module
unloading problem that's gotten discussed a bit.

- Dave

> --- hotplug-2001-04-24.orig/etc/hotplug/net.agent
> +++ hotplug-2001-04-24/etc/hotplug/net.agent
>  <at>  <at>  -52,6 +52,16  <at>  <at> 
>      mesg $1 $ACTION event not handled
>      ;;
>  
> +unregister)
> +    if [ -x /sbin/ifdown ]; then
> + if [ "$DEBUG" != "" ]; then
(Continue reading)

Kartoz, Michael F | 26 Apr 2001 02:14
Picon
Favicon

need to assign IRQs for PCI and cPCI

How do I assign IRQs for inserted PCI boards?

I have been writing a very rough version of a hotplug system driver as a
module.  I am specifically looking at how to get Linux 2.4.3 with the
hotplug package to assign resources (I/O, memory, IRQs) to the appropriate
places in the new board's PCI config space and in the kernel prior to
calling pci_insert_device.  I seem to have gotten the I/O and memory regions
as well as some of the other registers such as cache line size initialized
(although I'm not sure whether bridges are being handled properly or not).
However, I could not find any way of assigning the IRQs.  It seems that the
routines that exist for assigning the IRQs are only available during initial
boot.  Specifically, one routine that seems to be necessary (if using
IOAPIC) is IO_APIC_get_PCI_irq_vector which provides the IRQ for use by the
driver instead of the one in config space when APICs are being used.

Does anyone know how I should go about doing this?  Am I going about this
the wrong way?  Is anyone else doing this same kind of work?

The basic flow of an insert in my hotplug system driver is:
1) Create and zero out new dev structure for device that was inserted.
2) Fill in the bus, sysdata, devfn, device, vendor, dma_mask and hdr_type
elements of dev.
3) Fill in cache line size in PCI config space.
4) Call pci_setup_device.
5) Call pci_assign_resource for each of the first six resource structures in
dev.
6) Set PCI command register in PCI config space.
7) Call IO_APIC_get_PCI_irq_vector to fill in IRQ element of dev (I hacked
the kernel to make this symbol visible to my module)
8) Call pci_insert_device.
(Continue reading)

Chris Brand | 27 Apr 2001 20:58

Re: need to assign IRQs for PCI and cPCI

On Wed, Apr 25, 2001 at 05:14:14PM -0700, Kartoz, Michael F wrote:
> Does anyone know how I should go about doing this?  Am I going about this
> the wrong way?  Is anyone else doing this same kind of work?

Motorola Computer Group have something along these lines for cPCI and 2.2
kernels, downloadable from
http://www.mcg.mot.com/cfm/templates/swDetails.cfm?PageID=704&SoftwareID=6&P
roductID=172 No idea whether it's any use, but it may give you some clues.

Chris
Greg KH | 26 Apr 2001 01:26
Gravatar

Re: need to assign IRQs for PCI and cPCI

On Wed, Apr 25, 2001 at 05:14:14PM -0700, Kartoz, Michael F wrote:
> Does anyone know how I should go about doing this?  Am I going about this
> the wrong way?  Is anyone else doing this same kind of work?

Have you looked at how the Compaq Hotplug PCI driver handles this?
It's at http://opensource.compaq.com/ and I have a patch against 2.4.3
around here to make it build a bit cleaner.

Have you also looked at the 2 compactPCI drivers?  MonteVista wrote
them, and there is a sourceforge site that has the source for them
(can't remember it off the top of my head, sorry.)

What controller are you doing this work for?

thanks,

greg k-h
randallr | 25 Apr 2001 06:02

Register Event not handled (again)

To all developers:
I recently installed Red Hat 7.0.91 Wolverine to fix a serious KDE v1
problem running XTerm.  It is now about 3 days, and I still cannot
connect to my ISP.
Here's the /var/log/messages file:
Apr 24 20:08:34 npl pppd[4344]: pppd 2.4.0 started by root, uid 0
Apr 24 20:08:35 npl chat[4345]: timeout set to 5 seconds
Apr 24 20:08:35 npl chat[4345]: send (ATZ^M)
Apr 24 20:08:35 npl chat[4345]: expect (OK)
Apr 24 20:08:36 npl chat[4345]: ATZ^M^M
Apr 24 20:08:36 npl chat[4345]: OK
Apr 24 20:08:36 npl chat[4345]:  -- got it
Apr 24 20:08:36 npl chat[4345]: send (ATDT7089981^M)
Apr 24 20:08:36 npl chat[4345]: abort on (NO CARRIER)
Apr 24 20:08:36 npl chat[4345]: abort on (BUSY)
Apr 24 20:08:36 npl chat[4345]: abort on (NO DIALTONE)
Apr 24 20:08:36 npl chat[4345]: abort on (WAITING)
Apr 24 20:08:36 npl chat[4345]: timeout set to 45 seconds
Apr 24 20:08:36 npl chat[4345]: expect (CONNECT)
Apr 24 20:08:36 npl chat[4345]: ^M
Apr 24 20:09:01 npl chat[4345]: ATDT7089981^M^M
Apr 24 20:09:01 npl chat[4345]: CONNECT
Apr 24 20:09:01 npl chat[4345]:  -- got it
Apr 24 20:09:01 npl chat[4345]: send (^M)
Apr 24 20:09:01 npl chat[4345]: timeout set to 15 seconds
Apr 24 20:09:01 npl chat[4345]: expect (V42BIS)
Apr 24 20:09:01 npl chat[4345]:  49333/ARQ/V90/LAPM/V42BIS
Apr 24 20:09:01 npl chat[4345]:  -- got it
Apr 24 20:09:01 npl chat[4345]: send (ppp^M)
Apr 24 20:09:01 npl pppd[4344]: Serial connection established.
(Continue reading)

David Brownell | 25 Apr 2001 19:27

Re: Register Event not handled (again)

So far as I know, this problem is specific to rather old versions
of the scripts ... try current ones (perhaps not from RedHat).

----- Original Message ----- 
From: <randallr <at> abac.com>
To: <linux-hotplug-devel <at> lists.sourceforge.net>
Sent: Tuesday, April 24, 2001 9:02 PM
Subject: Register Event not handled (again)

> To all developers:
> I recently installed Red Hat 7.0.91 Wolverine to fix a serious KDE v1
> problem running XTerm.  It is now about 3 days, and I still cannot
> connect to my ISP.
> Here's the /var/log/messages file:
> Apr 24 20:08:34 npl pppd[4344]: pppd 2.4.0 started by root, uid 0
> Apr 24 20:08:35 npl chat[4345]: timeout set to 5 seconds
> Apr 24 20:08:35 npl chat[4345]: send (ATZ^M)
> Apr 24 20:08:35 npl chat[4345]: expect (OK)
> Apr 24 20:08:36 npl chat[4345]: ATZ^M^M
> Apr 24 20:08:36 npl chat[4345]: OK
> Apr 24 20:08:36 npl chat[4345]:  -- got it
> Apr 24 20:08:36 npl chat[4345]: send (ATDT7089981^M)
> Apr 24 20:08:36 npl chat[4345]: abort on (NO CARRIER)
> Apr 24 20:08:36 npl chat[4345]: abort on (BUSY)
> Apr 24 20:08:36 npl chat[4345]: abort on (NO DIALTONE)
> Apr 24 20:08:36 npl chat[4345]: abort on (WAITING)
> Apr 24 20:08:36 npl chat[4345]: timeout set to 45 seconds
> Apr 24 20:08:36 npl chat[4345]: expect (CONNECT)
> Apr 24 20:08:36 npl chat[4345]: ^M
> Apr 24 20:09:01 npl chat[4345]: ATDT7089981^M^M
(Continue reading)

Greg KH | 24 Apr 2001 21:41
Gravatar

2001-04-24 release of hotplug scripts

I've just packaged up the latest Linux hotplug scripts into a release,
which can be found at:
	http://sourceforge.net/project/showfiles.php?group_id=17679

This release adds the Debian scripts to the tarball, although all of the
debian specific changes were not merged into the main scripts, it would
have caused too much conflict, sorry.  But the Debian patch is now much
smaller :)  It also adds a hotplug manpage donated by Debian developer
Fumitoshi UKAI.

Numerous little changes were also added to the scripts, here is the full
changelog:
        - added debian hotplug.8 manpage by Fumitoshi UKAI
        - bugfixes to modprobing
        - make sure setup scripts run even when there is no module
        - "event not supported" only seen if debugging
        - added debian directory filled with things needed to package
          the scripts for a debian release.
        - make sure setup scripts (for usermode drivers/apps) will
          run even without a kernel driver
        - bugfix match_flags support from Gioele Barabuci; might
          require bash2-isms
        - add kernel 2.2.18 bcdDevice bug workaround (Ben Woodard)
        - cleanups from Gioele Barabuci
        - tweaked the post and preun sections to fix problem of hotplug
          not starting automatically when the package is upgraded.

I've built RedHat 6.x and 7.x specific rpms due to some small
differences in where the two version place their documentation.  The
individual releases are at:
(Continue reading)

Tim Jansen | 24 Apr 2001 03:08
Picon

Device Registry (DevReg) Patch 0.2.0

The Linux Device Registry (devreg) is a kernel patch that adds a device 
database in XML format to the /proc filesystem. It collects all information 
about the system's physical devices, creates persistent device ids and 
provides them in the file /proc/devreg.

Devreg has three purposes:
- collect all configuration data from drivers so the user can browse his 
hardware configuration. 
-allow an application to display all devices that provide a certain interface 
(for example all mice) so the user can chose one. 
-allow an application to find the device that the user has selected after a 
reboot or a hotplug action: the device files in /dev do not offer stable 
names, they depend on the order in that the devices have been plugged in or 
powered on. 

Changes since last release (0.1.1):
- converted file format to XML
- bus-specific information from pci and usb added
- fixed locking

The patch (for 2.4.3) can be found at 
http://www.tjansen.de/devreg/devreg-2.4.3-0.2.0.diff.gz
To test it, apply the patch, select CONFIG_DEVFS_FS and CONFIG_DEVREG and 
compile. Note that the patch will break binary drivers.

Supported hardware in version 0.2.0: PCI subsystem, USB subsystem, most PCI 
sound cards, USB HID devices, USB hubs, USB printers

Other information and a user-space library can be found at 
http://www.tjansen.de/devreg
(Continue reading)

Martin Dalecki | 24 Apr 2001 11:40

Re: Device Registry (DevReg) Patch 0.2.0

Tim Jansen wrote:
> 
> The Linux Device Registry (devreg) is a kernel patch that adds a device
> database in XML format to the /proc filesystem. It collects all information
OH SHIT!!     ^^^ 

<IRONY>
Why don't you just add postscript output to /proc?
</IRONY>

> about the system's physical devices, creates persistent device ids and
> provides them in the file /proc/devreg.

Gmane