* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 1:35 ` Andrew Morton
@ 2001-06-10 4:56 ` Glenn C. Hofmann
2001-06-10 5:08 ` Glenn C. Hofmann
2001-06-10 5:54 ` Ben LaHaise
2 siblings, 0 replies; 20+ messages in thread
From: Glenn C. Hofmann @ 2001-06-10 4:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
<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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 1:35 ` Andrew Morton
2001-06-10 4:56 ` Glenn C. Hofmann
@ 2001-06-10 5:08 ` Glenn C. Hofmann
2001-06-10 5:54 ` Ben LaHaise
2 siblings, 0 replies; 20+ messages in thread
From: Glenn C. Hofmann @ 2001-06-10 5:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 1:35 ` Andrew Morton
2001-06-10 4:56 ` Glenn C. Hofmann
2001-06-10 5:08 ` Glenn C. Hofmann
@ 2001-06-10 5:54 ` Ben LaHaise
2001-06-10 8:38 ` Russell King
2 siblings, 1 reply; 20+ messages in thread
From: Ben LaHaise @ 2001-06-10 5:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: hofmang, linux-kernel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 5:54 ` Ben LaHaise
@ 2001-06-10 8:38 ` Russell King
2001-06-10 9:39 ` arjan
2001-06-10 16:06 ` Ben LaHaise
0 siblings, 2 replies; 20+ messages in thread
From: Russell King @ 2001-06-10 8:38 UTC (permalink / raw)
To: Ben LaHaise; +Cc: Andrew Morton, hofmang, linux-kernel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 8:38 ` Russell King
@ 2001-06-10 9:39 ` arjan
2001-06-10 16:06 ` Ben LaHaise
1 sibling, 0 replies; 20+ messages in thread
From: arjan @ 2001-06-10 9:39 UTC (permalink / raw)
To: Russell King; +Cc: linux-kernel
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 8:38 ` Russell King
2001-06-10 9:39 ` arjan
@ 2001-06-10 16:06 ` Ben LaHaise
2001-06-10 16:34 ` Russell King
1 sibling, 1 reply; 20+ messages in thread
From: Ben LaHaise @ 2001-06-10 16:06 UTC (permalink / raw)
To: Russell King; +Cc: Andrew Morton, hofmang, linux-kernel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 16:06 ` Ben LaHaise
@ 2001-06-10 16:34 ` Russell King
2001-06-10 16:47 ` Jeff Garzik
2001-06-11 0:53 ` David S. Miller
0 siblings, 2 replies; 20+ messages in thread
From: Russell King @ 2001-06-10 16:34 UTC (permalink / raw)
To: Ben LaHaise; +Cc: Andrew Morton, linux-kernel
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 16:34 ` Russell King
@ 2001-06-10 16:47 ` Jeff Garzik
2001-06-10 22:23 ` Ben LaHaise
2001-06-11 3:17 ` Glenn C. Hofmann
2001-06-11 0:53 ` David S. Miller
1 sibling, 2 replies; 20+ messages in thread
From: Jeff Garzik @ 2001-06-10 16:47 UTC (permalink / raw)
To: Russell King; +Cc: Ben LaHaise, Andrew Morton, linux-kernel, netdev
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 |
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 16:47 ` Jeff Garzik
@ 2001-06-10 22:23 ` Ben LaHaise
2001-06-11 3:17 ` Glenn C. Hofmann
1 sibling, 0 replies; 20+ messages in thread
From: Ben LaHaise @ 2001-06-10 22:23 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Russell King, Andrew Morton, linux-kernel, netdev
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 16:47 ` Jeff Garzik
2001-06-10 22:23 ` Ben LaHaise
@ 2001-06-11 3:17 ` Glenn C. Hofmann
2001-06-11 3:25 ` Jeff Garzik
1 sibling, 1 reply; 20+ messages in thread
From: Glenn C. Hofmann @ 2001-06-11 3:17 UTC (permalink / raw)
To: Jeff Garzik, David S. Miller
Cc: Russell King, Ben LaHaise, Andrew Morton, linux-kernel, netdev
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-11 3:17 ` Glenn C. Hofmann
@ 2001-06-11 3:25 ` Jeff Garzik
2001-06-12 3:17 ` Glenn C. Hofmann
0 siblings, 1 reply; 20+ messages in thread
From: Jeff Garzik @ 2001-06-11 3:25 UTC (permalink / raw)
To: ghofmann
Cc: David S. Miller, Russell King, Ben LaHaise, Andrew Morton,
linux-kernel, netdev
"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 |
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-11 3:25 ` Jeff Garzik
@ 2001-06-12 3:17 ` Glenn C. Hofmann
0 siblings, 0 replies; 20+ messages in thread
From: Glenn C. Hofmann @ 2001-06-12 3:17 UTC (permalink / raw)
To: ghofmann, Jeff Garzik
Cc: David S. Miller, Russell King, Ben LaHaise, Andrew Morton,
linux-kernel, netdev
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-10 16:34 ` Russell King
2001-06-10 16:47 ` Jeff Garzik
@ 2001-06-11 0:53 ` David S. Miller
2001-06-11 13:03 ` Andrew Morton
2001-06-11 13:27 ` David S. Miller
1 sibling, 2 replies; 20+ messages in thread
From: David S. Miller @ 2001-06-11 0:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: Russell King, Ben LaHaise, Andrew Morton, linux-kernel, netdev
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-11 0:53 ` David S. Miller
@ 2001-06-11 13:03 ` Andrew Morton
2001-06-11 13:27 ` David S. Miller
1 sibling, 0 replies; 20+ messages in thread
From: Andrew Morton @ 2001-06-11 13:03 UTC (permalink / raw)
To: David S. Miller
Cc: Jeff Garzik, Russell King, Ben LaHaise, linux-kernel, netdev
"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.
-
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-11 0:53 ` David S. Miller
2001-06-11 13:03 ` Andrew Morton
@ 2001-06-11 13:27 ` David S. Miller
2001-06-11 13:49 ` Jeff Garzik
1 sibling, 1 reply; 20+ messages in thread
From: David S. Miller @ 2001-06-11 13:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Jeff Garzik, Russell King, Ben LaHaise, linux-kernel, netdev
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-11 13:27 ` David S. Miller
@ 2001-06-11 13:49 ` Jeff Garzik
2001-06-11 14:21 ` Andrew Morton
0 siblings, 1 reply; 20+ messages in thread
From: Jeff Garzik @ 2001-06-11 13:49 UTC (permalink / raw)
To: David S. Miller
Cc: Andrew Morton, Russell King, Ben LaHaise, linux-kernel, netdev
"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 |
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-11 13:49 ` Jeff Garzik
@ 2001-06-11 14:21 ` Andrew Morton
2001-06-11 16:05 ` Jeff Garzik
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Morton @ 2001-06-11 14:21 UTC (permalink / raw)
To: Jeff Garzik
Cc: David S. Miller, Russell King, Ben LaHaise, linux-kernel, netdev
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: 3C905b partial lockup in 2.4.5-pre5 and up to 2.4.6-pre1
2001-06-11 14:21 ` Andrew Morton
@ 2001-06-11 16:05 ` Jeff Garzik
0 siblings, 0 replies; 20+ messages in thread
From: Jeff Garzik @ 2001-06-11 16:05 UTC (permalink / raw)
To: Andrew Morton
Cc: David S. Miller, Russell King, Ben LaHaise, linux-kernel, netdev
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 |
^ permalink raw reply [flat|nested] 20+ messages in thread