Re: solution to printk() blocking interrupts?

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

Jon Smirl wrote:

>> Not sure if Stephen was the right person to CC, including Matt now...

>>>>>>What controls this? "carrier detect appears untrustworthy, waiting 4
>>>>>>seconds"
>>>>>>Get that fixed and this patch could be useful,

>>>>>Does the driver properly uses netif_carrier_on/off to signal the
>>>>>system when the link is up/down ?

>>>> Implementing the poll_controller() method in the network driver is
>>>>usually

>>>> Looks like the answer is "no"...

>>> Hm... it uses phylib, so probably it does that. That message and a 4 s
>>>pause appears if the carrier is seen in <10 ms after opening the device.

>>  Oops, not 10 -- 100 ms (HZ / 10).

>>>Maybe this threshold needs to be changed?

>>  Seems like too much indeed.

> The link is coming up, but it appears that netconsole has already
> decided to wait 4s.
> mpc52xx MII bus: probed
> net eth0: Using PHY at MDIO address 0
> netconsole: local port 6666
> netconsole: local IP 192.168.1.11
> netconsole: interface eth0
> netconsole: remote port 514
> netconsole: remote IP 192.168.1.4
> netconsole: remote ethernet address 00:19:d1:e4:0f:8d
> netconsole: device eth0 not up yet, forcing it
> net eth0: attached phy 0 to driver Generic PHY
> netconsole: carrier detect appears untrustworthy, waiting 4 seconds

    Netpoll code decides to wait 4 secs after seeing that carrier is OK before 
100 ms passed...

> PHY: f0003000:00 - Link is Up - 100/Full

    ...but it's only reported to be OK later. So indeed, the carrier reported 
by the driver appears untrustworthy. ;-)

WBR, Sergei