Re: Serial related oops
From: jose . goncalves
Date: Thu Feb 22 2007 - 12:24:19 EST
Quoting Russell King <rmk+lkml@xxxxxxxxxxxxxxxx>:
On Thu, Feb 22, 2007 at 03:02:46PM +0000, Jose Goncalves wrote:
It could be a silly question (tamper with me as I'm not familiar with
such low level programming), but couldn't it be possible for a interrupt
to hit in the middle of the serial_in() calls and mess with %ebx?
I'm no expert on x86, but if an interrupt was messing with %ebx, you'd
have random crashes verywhere - userspace, kernel space in unpredicatable
ways.
What I find real hard to understand is why a hardware fault happens
always in the same software instruction! I would expect a hardware fault
to hit randomly...
Well, compared with your previous report, your latest report is different.
Your first report had both EIP and %ebx being zero (because they got
corrupted when returning from serial_in). This time only %ebx was
corrupted.
Consequently, this time we oopsed in the subsequent serial_in() rather
than trying to return to serial8250_startup() as last time.
But there was also another difference. I CONFIGed the kernel to produce
more debug info. This should influence the Oops report...
I left my application running this night, with a 2.6.16.41 kernel
unpatched on the serial driver (my last Oops report was with Frederik
patch to remove the insertion made in 2.6.12) and it crashed again on
exactly the same point!
From that I take it that you removed the test in serial8250_startup which
sets UART_BUG_TXEN, and the problem persisted. That tends to suggest
that it's not the culpret.
From that I mean that with or without this code -
http://lkml.org/lkml/2007/2/19/124 - the problem persisted. The
difference is that, without it, the crashes happens more sparsly.
José Gonçalves
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/