Hi,
I've finally got around to test latest kernels and managed to find a bug in
the serial subsystem, which happens during suspend.
I use a 3Com PC Card Bluetooth adapter that needs serial_cs and hci_uart
modules. Whenever I try to suspend using 2.6.10 or a newer kernel, the
following bug appears. Note that 2.6.9 works perfectly.
#v+ handwritten, 2.6.11-rc5
kernel BUG at drivers/serial/8250.c:1256!
invalid operand: 0000 [#1]
PREEMPT
[...]
EIP is at serial_unlink_irq_chain+0x4b/0x60 [8250]
[...]
Call Trace:
uart_suspend_port [serial_core]
serial_suspend [serial_cs]
serial_event [serial_cs]
send_event_callback [pcmcia]
__bus_for_each_dev
bus_for_each_dev
send_event_callback [pcmcia]
send_event [pcmcia]
send_event_callback [pcmcia]
handle_event [pcmcia]
ds_event [pcmcia]
send_event [pcmcia_core]
socket_suspend [pcmcia_core]
#v-
Photos are available here (sorry for the quality):
http://hell.org.pl/~sziwan/bug_8250-1.jpg
http://hell.org.pl/~sziwan/bug_8250-2.jpg
http://hell.org.pl/~sziwan/bug_8250-3.jpg
I'll be happy to provide whatever information is needed.
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]
On Wed, Mar 02, 2005 at 12:09:46AM +0100, Karol Kozimor wrote:
> I've finally got around to test latest kernels and managed to find a bug in
> the serial subsystem, which happens during suspend.
Yes, serial_cs is claiming that we don't have a device associated with
the port, so we're treating it as a legacy port. However, serial_cs is
implementing the suspend/resume methods. This is wrong, since that
means the port will be suspended twice, and hence causes this bug.
serial_cs needs to register the ports along with the PCMCIA device with
which the port belongs to. This will stop it being treated as a legacy
serial port.
Unfortunately, it's too late tonight for me to dig into PCMCIA to work
out how we get at the device structure - I can't find any examples off
hand either. Therefore, it may be a while before I can produce a patch
to resolve this.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Tue, Mar 01, 2005 at 11:37:20PM +0000, Russell King wrote:
> On Wed, Mar 02, 2005 at 12:09:46AM +0100, Karol Kozimor wrote:
> > I've finally got around to test latest kernels and managed to find a bug in
> > the serial subsystem, which happens during suspend.
>
> Yes, serial_cs is claiming that we don't have a device associated with
> the port, so we're treating it as a legacy port. However, serial_cs is
> implementing the suspend/resume methods. This is wrong, since that
> means the port will be suspended twice, and hence causes this bug.
>
> serial_cs needs to register the ports along with the PCMCIA device with
> which the port belongs to. This will stop it being treated as a legacy
> serial port.
>
> Unfortunately, it's too late tonight for me to dig into PCMCIA to work
> out how we get at the device structure - I can't find any examples off
> hand either.
For the time being:
{
client_handle_t handle = ...
struct device *dev;
dev = &handle_to_dev(handle);
}
Dominik
On Tue, Mar 01, 2005 at 11:37:20PM +0000, Russell King wrote:
> On Wed, Mar 02, 2005 at 12:09:46AM +0100, Karol Kozimor wrote:
> > I've finally got around to test latest kernels and managed to find a bug in
> > the serial subsystem, which happens during suspend.
>
> Yes, serial_cs is claiming that we don't have a device associated with
> the port, so we're treating it as a legacy port. However, serial_cs is
> implementing the suspend/resume methods. This is wrong, since that
> means the port will be suspended twice, and hence causes this bug.
Ok, here's the patch. Please test and let me know if it resolves your
problem. Thanks.
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej orig/drivers/serial/serial_cs.c linux/drivers/serial/serial_cs.c
--- orig/drivers/serial/serial_cs.c Sun Feb 6 11:38:41 2005
+++ linux/drivers/serial/serial_cs.c Sat Mar 5 14:09:53 2005
@@ -289,7 +289,8 @@ static void serial_detach(dev_link_t * l
/*====================================================================*/
-static int setup_serial(struct serial_info * info, kio_addr_t iobase, int irq)
+static int setup_serial(client_handle_t handle, struct serial_info * info,
+ kio_addr_t iobase, int irq)
{
struct uart_port port;
int line;
@@ -299,6 +300,7 @@ static int setup_serial(struct serial_in
port.irq = irq;
port.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_SHARE_IRQ;
port.uartclk = 1843200;
+ port.dev = &handle_to_dev(handle);
if (buggy_uart)
port.flags |= UPF_BUGGY_UART;
line = serial8250_register_port(&port);
@@ -376,7 +378,7 @@ static int simple_config(dev_link_t *lin
info->slave = 1;
}
if (info->slave)
- return setup_serial(info, port, config.AssignedIRQ);
+ return setup_serial(handle, info, port, config.AssignedIRQ);
}
link->conf.Vcc = config.Vcc;
@@ -451,7 +453,7 @@ next_entry:
return -1;
}
- return setup_serial(info, link->io.BasePort1, link->irq.AssignedIRQ);
+ return setup_serial(handle, info, link->io.BasePort1, link->irq.AssignedIRQ);
}
static int multi_config(dev_link_t * link)
@@ -546,21 +548,21 @@ static int multi_config(dev_link_t * lin
8 registers are for the UART, the others are extra registers */
if (info->manfid == MANFID_OXSEMI) {
if (cf->index == 1 || cf->index == 3) {
- setup_serial(info, base2, link->irq.AssignedIRQ);
+ setup_serial(handle, info, base2, link->irq.AssignedIRQ);
outb(12, link->io.BasePort1 + 1);
} else {
- setup_serial(info, link->io.BasePort1, link->irq.AssignedIRQ);
+ setup_serial(handle, info, link->io.BasePort1, link->irq.AssignedIRQ);
outb(12, base2 + 1);
}
return 0;
}
- setup_serial(info, link->io.BasePort1, link->irq.AssignedIRQ);
+ setup_serial(handle, info, link->io.BasePort1, link->irq.AssignedIRQ);
/* The Nokia cards are not really multiport cards */
if (info->manfid == MANFID_NOKIA)
return 0;
for (i = 0; i < info->multi - 1; i++)
- setup_serial(info, base2 + (8 * i), link->irq.AssignedIRQ);
+ setup_serial(handle, info, base2 + (8 * i), link->irq.AssignedIRQ);
return 0;
}
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Thus wrote Russell King:
> Ok, here's the patch. Please test and let me know if it resolves your
> problem. Thanks.
Oh, I thought I did reply to your previous mail. In case you didn't get it,
yes, the patch fixes the problem.
Thanks,
--
Karol 'sziwan' Kozimor
[email protected]
