[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#589778: linux-image-2.6.32-5-686: prism2.5: hostap loads 90s



On Wed, 2010-07-21 at 10:10 +0200, Sten Heinze wrote:
> 
> On Wednesday 21 July 2010 01:32:38 Ben Hutchings wrote:
> > On Wed, 2010-07-21 at 01:04 +0200, Sten Heinze wrote:
> > > Package: linux-2.6
> > > Version: 2.6.32-15 and 2.6.32-17
> > > Severity: minor
> > > 
> > > 
> > > After upgrading from Lenny to Squeeze loading the hostap* modules
> for the
> > > built-in prism2.5 wireless network card need ~90s to load (I think
> > > loading is done by udev) and thus extend the boot process by this
> time.
> > > It is quite annoying to have to wait twice as long as the boot
> process
> > > usually takes, e.g. if the orinoco module for this card is loaded
> (but
> > > no connection is possible with the orinoco module).
> > 
> > [...]
> > 
> > Please send the file /etc/udev/rules.d/70-persistent-net.rules from
> this
> > system.
> 
> Attached.
> 
> Sten

I'm sorry about this ridiculously belated reply.  I think the problem is
this entry:

> # PCI device 0x1260:0x3873 (orinoco_pci)
> SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:20:e0:8d:ea:db", NAME="eth2"

which now matches two different network devices, initally created as
'wifi0' and 'wlan0':

> [    7.831480] hostap_pci 0000:02:02.0: PCI INT A -> Link[LNKC] -> GSI 11 (level, low) -> IRQ 11
> [    7.833476] hostap_pci: Registered netdevice wifi0
> [    7.833487] wifi0: Original COR value: 0x21
> [    8.038478] prism2_hw_init: initialized in 200 ms
> [    8.039317] wifi0: NIC: id=0x8013 v1.0.0
> [    8.039530] wifi0: PRI: id=0x15 v1.1.1
> [    8.039735] wifi0: STA: id=0x1f v1.5.6
> [    8.044622] wifi0: Intersil Prism2.5 PCI: mem=0xec000000, irq=11
> [    8.053279] wifi0: registered netdevice wlan0
> [    8.094549] udev: renamed network interface wifi0 to eth2

udev's net device naming script is a bit dumb: when it deals with
'wlan0' it assumes that the device already named 'eth2' (originally
'wifi0') is being dealt with in parallel and is going to get renamed to
something else.  Eventually it gives up waiting.

The simple thing to do is just to delete that entry; the current version
of udev should automatically generate new entries with the appropriate
qualifying attributes in addition to the MAC address.  Unfortunately I
don't think there's any good way to make this happen automatically on
upgrade.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: