Most recent kernel where this bug did not occur:
do not know, can only test fairly recent kernels (drivers of IDE/SATA
controller), but I think I had this problem before on a 2.6.12 kernel, but am
not 100% sure.

Distribution:
Debian Unstable

Hardware Environment:
lspci -vvv (of network card):
0000:03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX
(rev 02)
        Subsystem: Dell Inspiron 6000 laptop
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 64
        Interrupt: pin A routed to IRQ 9
        Region 0: Memory at dfdfe000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

Software Environment:
mii-tool.c 1.9 2000/04/28 00:56:08 (David Hinds)
ifconfig 1.42 (2001-04-13)
gcc (GCC) 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)

Problem Description:
Computer/kernel freezes/locks up solid every time when 'mii-tool ethX' is done,
while no 'ifconfig ethX up' is done. It works properly when ifconfig is done
before mii-tool.
After some 'research' with printk's I found out that it happens when a
SIOCGMIIPHY is sent to the ioctl. It finally freezes over 'u32 val = br32(bp,
reg);' in b44_wait_bit.
I presume that the hardware is not brought up properly, as I see

Steps to reproduce:
- start computer, but do not run 'ifconfig ethX up' (i.e. disable network scripts)
- mii-tool ethX
=== computer freezes ===