new device support for forcedeth.c fourth try
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Carl-Daniel Hailfinger
Known Bug: You will get a "bad: scheduling while atomic" message because of the msleep(500) in PHY reset.
Any suggestions how I can avoid this message? Using mdelay(500) has its share of problems too, because it will cause lost time.
Use schedule_work() to push it into a worker thread. While letting a worker thread sleep for 500ms is also not nice, it's better than doing it in an interrupt. The best but also most complicated solution is to set up a timer using add_timer for this, but this quickly gets you into state machine hell.
-Andi
Quoted 11 lines · Andi Kleen
Quoted 5 lines · Carl-Daniel Hailfinger
Known Bug: You will get a "bad: scheduling while atomic" message because of the msleep(500) in PHY reset.
Any suggestions how I can avoid this message? Using mdelay(500) has its share of problems too, because it will cause lost time.
Use
schedule_work()to push it into a worker thread.
Agreed. This is what I am moving net drivers to, for slow path stuff like chip reset or twiddling the phy.
Jeff
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Jeff" == Jeff Garzik <[email protected]> writes:
Quoted 5 lines · Andi Kleen
Carl-Daniel Hailfinger <[email protected]>
Quoted 2 lines · writes:
Known Bug: You will get a "bad: scheduling while atomic" message because of the msleep(500) in PHY reset.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Any suggestions how I can avoid this message? Using mdelay(500) has its share of problems too, because it will cause lost time.
Use
schedule_work()to push it into a worker thread.Agreed. This is what I am moving net drivers to, for slow path stuff like chip reset or twiddling the phy.
In this case is it possible to use schedule_delayed_work() to avoid stalling keventd for half a second?
- R.
Quoted 14 lines · Roland Dreier
Quoted 13 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Jeff" == Jeff Garzik <[email protected]> writes:
Quoted 9 lines · Andi Kleen
Carl-Daniel Hailfinger <[email protected]>
Quoted 6 lines · writes:
Known Bug: You will get a "bad: scheduling while atomic" message because of the msleep(500) in PHY reset.
Any suggestions how I can avoid this message? Using mdelay(500) has its share of problems too, because it will cause lost time.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Use
schedule_work()to push it into a worker thread.Agreed. This is what I am moving net drivers to, for slow path stuff like chip reset or twiddling the phy.
In this case is it possible to use
schedule_delayed_work()to avoid stalling keventd for half a second?
Certainly. Won't work in a 2.4.x backport, though.
This reminds me, I'm tempted to create a "you can sleep for a while in it" workqueue, to avoid tying up keventd.
Jeff