Re: kernel BUG at drivers/serial/8250.c:1256!
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at drivers/serial/8250.c:1256!
On Tue, Mar 01, 2005 at 11:37:20PM +, 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.cSat 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 = _to_dev(handle);
if (buggy_uart)
port.flags |= UPF_BUGGY_UART;
line = serial8250_register_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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at drivers/serial/8250.c:1256!
On Tue, Mar 01, 2005 at 11:37:20PM +, 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.cSat 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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at drivers/serial/8250.c:1256!
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] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at drivers/serial/8250.c:1256!
On Tue, Mar 01, 2005 at 11:37:20PM +, 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 = _to_dev(handle);
}
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at drivers/serial/8250.c:1256!
On Tue, Mar 01, 2005 at 11:37:20PM +, 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at drivers/serial/8250.c:1256!
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at drivers/serial/8250.c:1256!
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: [#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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at drivers/serial/8250.c:1256!
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: [#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] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at drivers/serial/8250.c:1256!
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 kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
