3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Glenn C. Hofmann]

I have tried 2.4.5-pre2 up to 2.4.6-pre1 with the same results.  Everything boots 
great and I can login fine.  When I try to assign an IP via DHCP or ifconfig, the system 
sits and stares at me indefinitely.  2.4.5-pre4 didn't compile for me, but pre3 works fine 
and pre5 locks.  There is keyboard response, and Alt-SysRq will tell me that it knows I 
want it to sync the disks, but won't actually do it.  It will reboot, though.  I can switch 
between terminals, but cannot type anything at the login prompt.

The board is a Abit KT7-RAID.  I have waited to see if this issue has been resolved and 
will recompile the newer kernels (AC and Linus flavours) to see if it has cleared up, but 
wanted to see if maybe there is something else I should look at.  I can provide any more 
information that might help, so please let me know.  Thanks in advance.


Glenn C. Hofmann

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Andrew Morton]

"Glenn C. Hofmann" wrote:
> 
> I have tried 2.4.5-pre2 up to 2.4.6-pre1 with the same results.  Everything boots
> great and I can login fine.  When I try to assign an IP via DHCP or ifconfig, the system
> sits and stares at me indefinitely.  2.4.5-pre4 didn't compile for me, but pre3 works fine
> and pre5 locks.  There is keyboard response, and Alt-SysRq will tell me that it knows I
> want it to sync the disks, but won't actually do it.  It will reboot, though.  I can switch
> between terminals, but cannot type anything at the login prompt.
> 
> The board is a Abit KT7-RAID.  I have waited to see if this issue has been resolved and
> will recompile the newer kernels (AC and Linus flavours) to see if it has cleared up, but
> wanted to see if maybe there is something else I should look at.  I can provide any more
> information that might help, so please let me know.  Thanks in advance.

There's a problem in some versions of `pump' where it gets
confused and ends up spinning indefinitely.  If you're using
pump could you please try the latest RPM?

If that doesn't help, and if you're unable to kill pump
with ^C, and if other virtual consoles are not responding then
it could be a kernel problem - try hitting sysrq-T and feeding
the resulting logs through `ksymoops -m System.map'

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Glenn C. Hofmann]

<bold><color><param>0100,0100,0100</param><bigger><bigger><bigger><bigger><bigger>Andrew,

Although I don't run 
Redhat, your response 
tells me that, even though I 
was feeling that it was a 
kernel problem, it could be 
a userspace issue, which I 
also suspected.  Debian 
updated their nettools 
today, so I will see if that 
helps in any way.  Thanks 
for your help.


Glenn C. Hofmann



</bold>On Sunday, 10 June 2001 
Andrew wrote:


<color><param>7F00,0000,0000</param><smaller><smaller><smaller><smaller><smaller>> "Glenn C. Hofmann" wrote:

> > 

> > I have tried 2.4.5-pre2 up to 2.4.6-pre1 with the same results. 

> > Everything boots great and I can login fine.  When I try to assign

> > an IP via DHCP or ifconfig, the system sits and stares at me

> > indefinitely.  2.4.5-pre4 didn't compile for me, but pre3 works fine

> > and pre5 locks.  There is keyboard response, and Alt-SysRq will tell

> > me that it knows I want it to sync the disks, but won't actually do

> > it.  It will reboot, though.  I can switch between terminals, but

> > cannot type anything at the login prompt.

> > 

> > The board is a Abit KT7-RAID.  I have waited to see if this issue

> > has been resolved and will recompile the newer kernels (AC and Linus

> > flavours) to see if it has cleared up, but wanted to see if maybe

> > there is something else I should look at.  I can provide any more

> > information that might help, so please let me know.  Thanks in

> > advance.

> 

> There's a problem in some versions of `pump' where it gets

> confused and ends up spinning indefinitely.  If you're using

> pump could you please try the latest RPM?

> 

> If that doesn't help, and if you're unable to kill pump

> with ^C, and if other virtual consoles are not responding then

> it could be a kernel problem - try hitting sysrq-T and feeding

> the resulting logs through `ksymoops -m System.map'

> -

> To unsubscribe from this list: send the line "unsubscribe

> linux-kernel" in the body of a message to majordomo@vger.kernel.org

> More majordomo info at  http://vger.kernel.org/majordomo-info.html

> Please read the FAQ at  http://www.tux.org/lkml/

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Glenn C. Hofmann]

Andrew, 
Although I don't run  
Redhat, your response  
tells me that, even though I 
 was feeling that it was a  
kernel problem, it could be  
a userspace issue, which I  
also suspected.  Debian  
updated their nettools  
today, so I will see if that  
helps in any way.  Thanks  
for your help.  If you think 
of anything else that might 
be an issue, please let me 
know.  

Glenn C. Hofmann 

Andrew wrote:

Date sent:      	Sun, 10 Jun 2001 11:35:53 +1000
From:           	Andrew Morton <andrewm@uow.edu.au>
Subject:        	Re: 3C905b partial  lockup in 2.4.5-pre5 and up to 2.4.6-pre1
To:             	hofmang@ibm.net
Copies to:      	linux-kernel@vger.kernel.org

> "Glenn C. Hofmann" wrote:
> > 
> > I have tried 2.4.5-pre2 up to 2.4.6-pre1 with the same results. 
> > Everything boots great and I can login fine.  When I try to assign
> > an IP via DHCP or ifconfig, the system sits and stares at me
> > indefinitely.  2.4.5-pre4 didn't compile for me, but pre3 works fine
> > and pre5 locks.  There is keyboard response, and Alt-SysRq will tell
> > me that it knows I want it to sync the disks, but won't actually do
> > it.  It will reboot, though.  I can switch between terminals, but
> > cannot type anything at the login prompt.
> > 
> > The board is a Abit KT7-RAID.  I have waited to see if this issue
> > has been resolved and will recompile the newer kernels (AC and Linus
> > flavours) to see if it has cleared up, but wanted to see if maybe
> > there is something else I should look at.  I can provide any more
> > information that might help, so please let me know.  Thanks in
> > advance.
> 
> There's a problem in some versions of `pump' where it gets
> confused and ends up spinning indefinitely.  If you're using
> pump could you please try the latest RPM?
> 
> If that doesn't help, and if you're unable to kill pump
> with ^C, and if other virtual consoles are not responding then
> it could be a kernel problem - try hitting sysrq-T and feeding
> the resulting logs through `ksymoops -m System.map'
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Ben LaHaise]

On Sun, 10 Jun 2001, Andrew Morton wrote:

> There's a problem in some versions of `pump' where it gets
> confused and ends up spinning indefinitely.  If you're using
> pump could you please try the latest RPM?

I doubt it's related to pump: a few times I've seen the 3c59x driver drop
the first few transmit packets.  Try loading the driver as a module and
putting the whole modprobe ; ifconfig ; ping <somehost> set of commands
into a script and watch what happens.  This goes for all ethernet driver
writers.

		-ben

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Russell King]

On Sun, Jun 10, 2001 at 01:54:13AM -0400, Ben LaHaise wrote:
> I doubt it's related to pump: a few times I've seen the 3c59x driver drop
> the first few transmit packets.  Try loading the driver as a module and
> putting the whole modprobe ; ifconfig ; ping <somehost> set of commands
> into a script and watch what happens.  This goes for all ethernet driver
> writers.

Is this a change of requirements for ethernet drivers?  Many other drivers
do exactly the same (drop the first few packets while they're negotiating
with a hub), unless they're using 10base2, even back to the days of 2.0
kernels.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[arjan]

In article <20010610093838.A13074@flint.arm.linux.org.uk> you wrote:
> Is this a change of requirements for ethernet drivers?  Many other drivers
> do exactly the same (drop the first few packets while they're negotiating
> with a hub), unless they're using 10base2, even back to the days of 2.0
> kernels.

I think it would make sense, from the other sides perspective, to only return 
from the "up" function when you actually can send packets[1]. Sure, pump show
this most of all because it does

"up"
send DHCP req
wait
if failed "down"
	  wait
	  repeat


and that sucks if you always eat the first packets after an up...

xircom had this bug for a loooong time, 8139too just got it a few weeks ago
and, well, from an applications point of view expecting to be able to send
packets when the interface is up makes sense.

Applications like pump must be robust against "random" packetloss, and,
well, pump is. Just not against the "targeted" packetloss of loosing every
first few packets.

Greetings,
   Arjan van de Ven


[1] I know this is not always easy for the driverwrite. For one, xircom
    will eat every first few packets, so the driver would have to send a few
    fake packets to get going.

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Ben LaHaise]

On Sun, 10 Jun 2001, Russell King wrote:

> Is this a change of requirements for ethernet drivers?  Many other drivers
> do exactly the same (drop the first few packets while they're negotiating
> with a hub), unless they're using 10base2, even back to the days of 2.0
> kernels.

I doubt it's a change, more likely an undocumented requirement.  Look at
it another way: is the transmitter ready when the link is down?  No.
Why?  Because if it does attempt to transmit a packet, it will get a
transmit error, but it can't possibly be an error since it's a normal part
of bringing the link up.  Does this sound reasonable?

		-ben

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Russell King]

On Sun, Jun 10, 2001 at 12:06:08PM -0400, Ben LaHaise wrote:
> I doubt it's a change, more likely an undocumented requirement.  Look at
> it another way: is the transmitter ready when the link is down?  No.
> Why?  Because if it does attempt to transmit a packet, it will get a
> transmit error, but it can't possibly be an error since it's a normal part
> of bringing the link up.  Does this sound reasonable?

Indeed.  However, I don't believe user space should _rely_ on the flag.
The reason is that there are network cards out there where the only way
to get the link status _is_ to transmit a packet, even on 10baseT.

PCNET is one example - the "oh my god my link is down" status bit is in
the transmit ring headers, not in an easily accessible register.

The only interpretation user space can place on IFF_RUNNING for these
cards is that if its not set, packets will get dropped by the interface.
If its set, packets _may_ be dropped by the interface.

[note I've not found anything in 2.4.5 where netif_carrier_ok prevents
the net layers queueing packets for an interface, and forwarding them
on for transmission].

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Jeff Garzik]

Russell King wrote:
> Indeed.  However, I don't believe user space should _rely_ on the flag.
> The reason is that there are network cards out there where the only way
> to get the link status _is_ to transmit a packet, even on 10baseT.
> 
> PCNET is one example - the "oh my god my link is down" status bit is in
> the transmit ring headers, not in an easily accessible register.
> 
> The only interpretation user space can place on IFF_RUNNING for these
> cards is that if its not set, packets will get dropped by the interface.
> If its set, packets _may_ be dropped by the interface.

These are the exception not the rule, though, so I don't think we should
design primarily for them.  On most decent cards, we can not only ask
for link status from a register, but also get interrupts when link
change occurs [though we may still need a timer for certain link
states].


> [note I've not found anything in 2.4.5 where netif_carrier_ok prevents
> the net layers queueing packets for an interface, and forwarding them
> on for transmission].

we want netif_carrier_{on,off} to emit netlink messages.  I don't know
how DaveM would feel about such getting implemented in 2.4.x though,
even if well tested.

Note we went over netif_carrier_xxx and related issues not a week ago,
IIRC

	Jeff


P.S. netdev@oss.sgi.com added to cc.  please cc there on net
interface/driver issues...

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Ben LaHaise]

On Sun, 10 Jun 2001, Jeff Garzik wrote:
> rmk wrote:
> > [note I've not found anything in 2.4.5 where netif_carrier_ok prevents
> > the net layers queueing packets for an interface, and forwarding them
> > on for transmission].
>
> we want netif_carrier_{on,off} to emit netlink messages.  I don't know
> how DaveM would feel about such getting implemented in 2.4.x though,
> even if well tested.

There are a lot of places that make the assumption that packets
transmitted after ifconfig eth0 .... up returns will hit the wire, and
yes, anything that does make that assumption is indeed broken.  That said,
adding an extra 30s of DNS timeouts and a few more seconds of rpc timeouts
there to bootup is painful.

		-ben

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[David S. Miller]

Jeff Garzik writes:
 > > [note I've not found anything in 2.4.5 where netif_carrier_ok prevents
 > > the net layers queueing packets for an interface, and forwarding them
 > > on for transmission].
 > 
 > we want netif_carrier_{on,off} to emit netlink messages.  I don't know
 > how DaveM would feel about such getting implemented in 2.4.x though,
 > even if well tested.

If someone sent me patches which did this (and minded the
restrictions, if any, this adds to the execution contexts in
which the carrier on/off stuff can be invoked) I would consider
the patch seriously for 2.4.x

Later,
David S. Miller
davem@redhat.com

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Glenn C. Hofmann]

I have, as was suggested, built as a module, and get unresolved symbol do_softirq, so 
this appears to be another problem in this driver with 2.4.6-pre2.  If I can help in any 
way, please let me know, although I am by no means a programmer, just a tester.  
Thanks.

Glenn C. Hofmann


On 10 Jun 2001, at 17:53 David S. Miller wrote:

> 
> Jeff Garzik writes:
>  > > [note I've not found anything in 2.4.5 where netif_carrier_ok prevents
>  > > the net layers queueing packets for an interface, and forwarding them
>  > > on for transmission].
>  > 
>  > we want netif_carrier_{on,off} to emit netlink messages.  I don't know
>  > how DaveM would feel about such getting implemented in 2.4.x though,
>  > even if well tested.
> 
> If someone sent me patches which did this (and minded the
> restrictions, if any, this adds to the execution contexts in
> which the carrier on/off stuff can be invoked) I would consider
> the patch seriously for 2.4.x
> 
> Later,
> David S. Miller
> davem@redhat.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Jeff Garzik]

"Glenn C. Hofmann" wrote:
> 
> I have, as was suggested, built as a module, and get unresolved symbol do_softirq, so
> this appears to be another problem in this driver with 2.4.6-pre2.  If I can help in any
> way, please let me know, although I am by no means a programmer, just a tester.

edit kernel/ksyms.c:

-EXPORT_SYMBOL(do_softirq);
+EXPORT_SYMBOL_NOVERS(do_softirq);

and see if that helps.

Errors about do_softirq are unrelated to a specific driver.

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Andrew Morton]

"David S. Miller" wrote:
> 
> Jeff Garzik writes:
>  > > [note I've not found anything in 2.4.5 where netif_carrier_ok prevents
>  > > the net layers queueing packets for an interface, and forwarding them
>  > > on for transmission].
>  >
>  > we want netif_carrier_{on,off} to emit netlink messages.  I don't know
>  > how DaveM would feel about such getting implemented in 2.4.x though,
>  > even if well tested.
> 
> If someone sent me patches which did this (and minded the
> restrictions, if any, this adds to the execution contexts in
> which the carrier on/off stuff can be invoked) I would consider
> the patch seriously for 2.4.x

It'd need to be callable from interrupt context - otherwise
each device/driver which has link status change interrupts
will need to implement some form of interrupt->process context
trick.

On the DHCP/DNS issue which Ben raised - MII-based NICs can take up
to 3.5 seconds before they start sending packets, *after* their
open() has returned success.  This is within the letter of the law
(ethernet can drop packets) but it'd be nicer to userspace if we
were to not return from the open until the interface was actually
usable.

Jamal has a patch somewhere which does the netlink status
notification.  If he cares to share it I'll take a look.

-

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[David S. Miller]

Andrew Morton writes:
 > It'd need to be callable from interrupt context - otherwise
 > each device/driver which has link status change interrupts
 > will need to implement some form of interrupt->process context
 > trick.

Well, we could make the netif_carrier_*() implementation do the
"interrupt->process context" trick.

Jamal can feel free to post what he has.

Later,
David S. Miller
davem@redhat.com

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Jeff Garzik]

"David S. Miller" wrote:
> 
> Andrew Morton writes:
>  > It'd need to be callable from interrupt context - otherwise
>  > each device/driver which has link status change interrupts
>  > will need to implement some form of interrupt->process context
>  > trick.
> 
> Well, we could make the netif_carrier_*() implementation do the
> "interrupt->process context" trick.
> 
> Jamal can feel free to post what he has.

If we have any problems with context we can always use schedule_task()

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Andrew Morton]

Jeff Garzik wrote:
> 
> "David S. Miller" wrote:
> >
> > Andrew Morton writes:
> >  > It'd need to be callable from interrupt context - otherwise
> >  > each device/driver which has link status change interrupts
> >  > will need to implement some form of interrupt->process context
> >  > trick.
> >
> > Well, we could make the netif_carrier_*() implementation do the
> > "interrupt->process context" trick.
> >
> > Jamal can feel free to post what he has.
> 
> If we have any problems with context we can always use schedule_task()

Yep.  With dev_hold() and dev_put() to avoid module removal
races.  One would also have to be sure that the right things
happen if the interface is downed between the interrupt and
execution of the schedule_task() callback.

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Jeff Garzik]

Andrew Morton wrote:
> 
> Jeff Garzik wrote:
> >
> > "David S. Miller" wrote:
> > >
> > > Andrew Morton writes:
> > >  > It'd need to be callable from interrupt context - otherwise
> > >  > each device/driver which has link status change interrupts
> > >  > will need to implement some form of interrupt->process context
> > >  > trick.
> > >
> > > Well, we could make the netif_carrier_*() implementation do the
> > > "interrupt->process context" trick.
> > >
> > > Jamal can feel free to post what he has.
> >
> > If we have any problems with context we can always use schedule_task()
> 
> Yep.  With dev_hold() and dev_put() to avoid module removal
> races.  One would also have to be sure that the right things
> happen if the interface is downed between the interrupt and
> execution of the schedule_task() callback.

Why not call MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT?  It makes it much
more obvious you are closing a race related to modules, and it goes away
when the module is built into the kernel.

(as a tangent, I have run into cases where it would be nice to always
have a module ref count, whether or not you were built into the kernel. 
this would be ok with me...)


-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1

[Glenn C. Hofmann]

Yes, thank you, that makes it load and it also works with ifconfig and dhcp as a module.

Glenn C. Hofmann

On 10 Jun 2001, at 23:25 Jeff Garzik wrote:

> "Glenn C. Hofmann" wrote:
> > 
> > I have, as was suggested, built as a module, and get unresolved symbol do_softirq, so
> > this appears to be another problem in this driver with 2.4.6-pre2.  If I can help in any
> > way, please let me know, although I am by no means a programmer, just a tester.
> 
> edit kernel/ksyms.c:
> 
> -EXPORT_SYMBOL(do_softirq);
> +EXPORT_SYMBOL_NOVERS(do_softirq);
> 
> and see if that helps.
> 
> Errors about do_softirq are unrelated to a specific driver.
> 
> -- 
> Jeff Garzik      | Andre the Giant has a posse.
> Building 1024    |
> MandrakeSoft     |
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/