Hi
We are using linux in quite a harsh mobile environment (high
temperatures, unreliable power sources, electrical interference, etc).
It has been doing very well, except for this scenario. The wireless
interface wlan0 is busy communicating, and the power is disconnected
abruptedly. In the next boot, we get a kernel panic when the wlan
interface is initialised.
We want to know if this is due to linux's journaling file system (we
are using ext3)? Does it keep track of the state so closely, even up
to the point of the previous abrupt shutdown? If so, what can we do to
"cleanup" in the next boot to avoid the kernel panic?
Regards
Keith
Ar Sul, 2006-09-17 am 14:30 +1200, ysgrifennodd Keith Chew:
> It has been doing very well, except for this scenario. The wireless
> interface wlan0 is busy communicating, and the power is disconnected
> abruptedly. In the next boot, we get a kernel panic when the wlan
> interface is initialised.
>
> We want to know if this is due to linux's journaling file system
Very unlikely but you don't provide enough information to even guess.
I've seen similar behaviours before and they usually indicate a bug in
the driver that crashed. Eg the setup code for a network card not being
able to cope if the network card is in a particular state but does
enough that next boot it works.
You need to work back from your wireless driver panic to the root cause
of that panic and then back from there.
On 17/09/06, Keith Chew <[email protected]> wrote:
> Hi
>
> We are using linux in quite a harsh mobile environment (high
> temperatures, unreliable power sources, electrical interference, etc).
>
> It has been doing very well, except for this scenario. The wireless
> interface wlan0 is busy communicating, and the power is disconnected
> abruptedly. In the next boot, we get a kernel panic when the wlan
> interface is initialised.
>
> We want to know if this is due to linux's journaling file system (we
> are using ext3)? Does it keep track of the state so closely, even up
> to the point of the previous abrupt shutdown? If so, what can we do to
> "cleanup" in the next boot to avoid the kernel panic?
>
You could start by posting your panic/Oops message. That would give
people something to work with.
Perhaps also a bit more detail on the system in question - see the
REPORTING-BUGS document in the kernel source dir.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Hi Alan
> Very unlikely but you don't provide enough information to even guess.
>
> I've seen similar behaviours before and they usually indicate a bug in
> the driver that crashed. Eg the setup code for a network card not being
> able to cope if the network card is in a particular state but does
> enough that next boot it works.
>
> You need to work back from your wireless driver panic to the root cause
> of that panic and then back from there.
>
Thank you very much for your diagnostic. The stack traces are not as
consistent as our driver crashes, so we have not posted them yet
before digging a bit deeper. We are now looking at the
startup/shutdown process of the driver, and there could be some
critical timing issues, but we will check and test.
Thanks again, will report back soon.
Regards
Keith