3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
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
Quoted 8 lines · 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.
Quoted 4 lines
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'
<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:
Quoted 59 lines · <color><param>7F00,0000,0000</param><smaller><smaller><smaller><smaller><smalle…
Quoted 24 lines
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
Quoted 7 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 <[email protected]> Subject: Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1 To: [email protected] Copies to: [email protected]
Quoted 31 lines
Quoted 10 lines · 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.
Quoted 6 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Andrew Morton
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
Quoted 5 lines · Ben LaHaise
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 4 lines · In article <[email protected]> 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.
Quoted 4 lines · Russell King
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
Quoted 5 lines · Ben LaHaise
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 10 lines · Russell King
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_RUNNINGfor 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].
Quoted 3 lines
[note I've not found anything in 2.4.5 where
netif_carrier_okprevents 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. [email protected] added to cc. please cc there on net interface/driver issues...
Signature · 3 lines
Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft |
Quoted 8 lines · Jeff Garzik
Quoted 3 lines · rmk
[note I've not found anything in 2.4.5 where
netif_carrier_okprevents 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
Quoted 7 lines · Jeff Garzik
Quoted 3 lines
[note I've not found anything in 2.4.5 where
netif_carrier_okprevents 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
[email protected]
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
Quoted 23 lines · On 10 Jun 2001, at 17:53 David S. Miller wrote:
Quoted 7 lines · Jeff Garzik
Quoted 3 lines
[note I've not found anything in 2.4.5 where
netif_carrier_okprevents 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
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · 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.
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.
Signature · 3 lines
Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft |
Quoted 6 lines · David S. Miller
Quoted 4 lines · Jeff Garzik
Quoted 3 lines
[note I've not found anything in 2.4.5 where
netif_carrier_okprevents the net layers queueing packets for an interface, and forwarding them on for transmission].
Quoted 8 lines
Quoted 3 lines
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.
-
Quoted 4 lines · Andrew Morton
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->processcontext 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
[email protected]
Quoted 11 lines · David S. Miller
Quoted 4 lines · Andrew Morton
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->processcontext trick.Well, we could make the netif_carrier_*() implementation do the "
interrupt->processcontext" trick.Jamal can feel free to post what he has.
If we have any problems with context we can always use schedule_task()
Signature · 3 lines
Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft |
Quoted 9 lines · Jeff Garzik
Quoted 7 lines · David S. Miller
Quoted 4 lines · Andrew Morton
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->processcontext trick.
Quoted 6 lines
Quoted 4 lines
Well, we could make the netif_carrier_*() implementation do the "
interrupt->processcontext" 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.
Quoted 14 lines · Andrew Morton
Quoted 12 lines · Jeff Garzik
Quoted 10 lines · David S. Miller
Quoted 4 lines · Andrew Morton
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->processcontext trick.Well, we could make the netif_carrier_*() implementation do the "
interrupt->processcontext" trick.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
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()anddev_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 theschedule_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...)
Signature · 3 lines
Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft |
Yes, thank you, that makes it load and it also works with ifconfig and dhcp as a module.
Glenn C. Hofmann
Quoted 24 lines · On 10 Jun 2001, at 23:25 Jeff Garzik wrote:
Quoted 4 lines · 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.edit
kernel/ksyms.c:(quoted diff) +1
-1-EXPORT_SYMBOL(do_softirq); +EXPORT_SYMBOL_NOVERS(do_softirq);and see if that helps.
Errors about
do_softirqare unrelated to a specific driver.Signature · 8 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/