Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1502067 > unrolled thread

console issue since 3.6, console=ttyS1 hangs

Back to article view | Back to linux.kernel

Contents

  console issue since 3.6, console=ttyS1 hangs Nathan Zimmer <nzimmer@sgi.com> - 2016-10-17 17:00 +0200
    Re: console issue since 3.6, console=ttyS1 hangs Sean Young <sean@mess.org> - 2016-10-17 17:20 +0200
      Re: console issue since 3.6, console=ttyS1 hangs Nathan Zimmer <nzimmer@sgi.com> - 2016-10-17 18:50 +0200
        Re: console issue since 3.6, console=ttyS1 hangs Nathan Zimmer <nzimmer@sgi.com> - 2016-10-18 18:50 +0200
          Re: console issue since 3.6, console=ttyS1 hangs Sean Young <sean@mess.org> - 2016-10-18 20:10 +0200
            Re: console issue since 3.6, console=ttyS1 hangs Sean Young <sean@mess.org> - 2016-10-19 17:10 +0200
              Re: console issue since 3.6, console=ttyS1 hangs Nathan Zimmer <nzimmer@sgi.com> - 2016-10-20 00:20 +0200
                Re: console issue since 3.6, console=ttyS1 hangs Sean Young <sean@mess.org> - 2016-10-20 22:20 +0200
                  Re: console issue since 3.6, console=ttyS1 hangs Nathan Zimmer <nzimmer@sgi.com> - 2016-10-21 18:00 +0200
                    Re: console issue since 3.6, console=ttyS1 hangs Sean Young <sean@mess.org> - 2016-10-24 16:00 +0200
                      Re: console issue since 3.6, console=ttyS1 hangs Sean Young <sean@mess.org> - 2016-10-25 22:50 +0200
                        Re: console issue since 3.6, console=ttyS1 hangs Nathan Zimmer <nzimmer@sgi.com> - 2016-10-26 20:20 +0200

#1502067 — console issue since 3.6, console=ttyS1 hangs

A cluster client recently tried to update from Sles11 to Sles12 and found in
some cases the boxes would hang in early boot.  It came down to console=ttyS1
on the command line.  After a bisection I found it happended in here:

commit 835d844d1a28efba81d5aca7385e24c29d3a6db2
Author: Sean Young <sean@mess.org>
Date:   Fri Sep 7 19:06:23 2012 +0100

    8250_pnp: do pnp probe before legacy probe


I found I can revert the part of the patch in 8250.c (now 8250_core.c) and
the hangs do not happen.

Bios of the offending box ( I don't know if there a bios update )
Version 2.15.1234. Copyright (C) 2012 American Megatrends, Inc.
BIOS Date: 02/05/2014 13:45:09
Ver: ma2e2054.16I

I don't have much more info but will collect anything that is asked.
Any help would be appeciated.

Nate

[toc] | [next] | [standalone]

#1502094

On Mon, Oct 17, 2016 at 09:49:51AM -0500, Nathan Zimmer wrote:
> A cluster client recently tried to update from Sles11 to Sles12 and found in
> some cases the boxes would hang in early boot.  It came down to console=ttyS1
> on the command line.  After a bisection I found it happended in here:
> 
> commit 835d844d1a28efba81d5aca7385e24c29d3a6db2
> Author: Sean Young <sean@mess.org>
> Date:   Fri Sep 7 19:06:23 2012 +0100
> 
>     8250_pnp: do pnp probe before legacy probe
> 
> 
> I found I can revert the part of the patch in 8250.c (now 8250_core.c) and
> the hangs do not happen.
> 
> Bios of the offending box ( I don't know if there a bios update )
> Version 2.15.1234. Copyright (C) 2012 American Megatrends, Inc.
> BIOS Date: 02/05/2014 13:45:09
> Ver: ma2e2054.16I
> 
> I don't have much more info but will collect anything that is asked.
> Any help would be appeciated.

The console output would be helpful (both before 3.6 and with 3.6). It 
could be that what the bios provides in pnp does not match the actual
config.

The output of:

cat /sys/bus/pnp/drivers/serial/*/resources

Would be helpful, thanks.


Sean

[toc] | [prev] | [next] | [standalone]

#1502197

Ok I'll get that sometime tomorrow.  Right now they pulled it down maintenance...

On Mon, Oct 17, 2016 at 04:19:07PM +0100, Sean Young wrote:
> On Mon, Oct 17, 2016 at 09:49:51AM -0500, Nathan Zimmer wrote:
> > A cluster client recently tried to update from Sles11 to Sles12 and found in
> > some cases the boxes would hang in early boot.  It came down to console=ttyS1
> > on the command line.  After a bisection I found it happended in here:
> > 
> > commit 835d844d1a28efba81d5aca7385e24c29d3a6db2
> > Author: Sean Young <sean@mess.org>
> > Date:   Fri Sep 7 19:06:23 2012 +0100
> > 
> >     8250_pnp: do pnp probe before legacy probe
> > 
> > 
> > I found I can revert the part of the patch in 8250.c (now 8250_core.c) and
> > the hangs do not happen.
> > 
> > Bios of the offending box ( I don't know if there a bios update )
> > Version 2.15.1234. Copyright (C) 2012 American Megatrends, Inc.
> > BIOS Date: 02/05/2014 13:45:09
> > Ver: ma2e2054.16I
> > 
> > I don't have much more info but will collect anything that is asked.
> > Any help would be appeciated.
> 
> The console output would be helpful (both before 3.6 and with 3.6). It 
> could be that what the bios provides in pnp does not match the actual
> config.
> 
> The output of:
> 
> cat /sys/bus/pnp/drivers/serial/*/resources
> 
> Would be helpful, thanks.
> 
> 
> Sean

[toc] | [prev] | [next] | [standalone]

#1503220

[Multipart message — attachments visible in raw view] — view raw

3.7.0
cat /sys/bus/pnp/drivers/serial/*/resources
state = active
io 0x2f8-0x2ff
irq 12
dma disabled

3.6.0
:~ # cat /sys/bus/pnp/drivers/serial/*/resources
cat: /sys/bus/pnp/drivers/serial/*/resources: No such file or directory

Which is intresting.
So I thought tacking on "tail /sys/devices/pnp0/*/resources" might be helpful.



On Mon, Oct 17, 2016 at 11:41:40AM -0500, Nathan Zimmer wrote:
> Ok I'll get that sometime tomorrow.  Right now they pulled it down maintenance...
> 
> On Mon, Oct 17, 2016 at 04:19:07PM +0100, Sean Young wrote:
> > On Mon, Oct 17, 2016 at 09:49:51AM -0500, Nathan Zimmer wrote:
> > > A cluster client recently tried to update from Sles11 to Sles12 and found in
> > > some cases the boxes would hang in early boot.  It came down to console=ttyS1
> > > on the command line.  After a bisection I found it happended in here:
> > > 
> > > commit 835d844d1a28efba81d5aca7385e24c29d3a6db2
> > > Author: Sean Young <sean@mess.org>
> > > Date:   Fri Sep 7 19:06:23 2012 +0100
> > > 
> > >     8250_pnp: do pnp probe before legacy probe
> > > 
> > > 
> > > I found I can revert the part of the patch in 8250.c (now 8250_core.c) and
> > > the hangs do not happen.
> > > 
> > > Bios of the offending box ( I don't know if there a bios update )
> > > Version 2.15.1234. Copyright (C) 2012 American Megatrends, Inc.
> > > BIOS Date: 02/05/2014 13:45:09
> > > Ver: ma2e2054.16I
> > > 
> > > I don't have much more info but will collect anything that is asked.
> > > Any help would be appeciated.
> > 
> > The console output would be helpful (both before 3.6 and with 3.6). It 
> > could be that what the bios provides in pnp does not match the actual
> > config.
> > 
> > The output of:
> > 
> > cat /sys/bus/pnp/drivers/serial/*/resources
> > 
> > Would be helpful, thanks.
> > 
> > 
> > Sean

[toc] | [prev] | [next] | [standalone]

#1503267

On Tue, Oct 18, 2016 at 11:40:04AM -0500, Nathan Zimmer wrote:
> 3.7.0
> cat /sys/bus/pnp/drivers/serial/*/resources
> state = active
> io 0x2f8-0x2ff
> irq 12
> dma disabled
> 
> 3.6.0
> :~ # cat /sys/bus/pnp/drivers/serial/*/resources
> cat: /sys/bus/pnp/drivers/serial/*/resources: No such file or directory

irq 12 for ttyS1? That should be irq 3. The bios is putting bogus information
in pnp. Maybe there is rubbish in the bios setup or maybe it's fixed in a 
newer bios update.

So before this change, the kernel would assume irq 3. After this change,
the kernel first uses the information in pnp to see where the serial
port is. It gets told that it's irq 12 and presumably it runs into all
sorts of problems then. If memory serves that's the irq for the ps/2 mouse.

The interesting bit is in 3.6.0:

setserial
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3

becomes in 3.7.0:

setserial
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 12

You should be able to set the right irq with setserial, but obviously
that doesn't help you if it fails in early boot. It's not immediately
obvious to me what can be done in the kernel for this. Maybe the dmesg
output could inspire, thanks.


Sean

[toc] | [prev] | [next] | [standalone]

#1503830

On Tue, Oct 18, 2016 at 02:29:30PM -0500, Nathan Zimmer wrote:
> On Tue, Oct 18, 2016 at 07:05:18PM +0100, Sean Young wrote:
> > On Tue, Oct 18, 2016 at 11:40:04AM -0500, Nathan Zimmer wrote:
> > > 3.7.0
> > > cat /sys/bus/pnp/drivers/serial/*/resources
> > > state = active
> > > io 0x2f8-0x2ff
> > > irq 12
> > > dma disabled
> > > 
> > > 3.6.0
> > > :~ # cat /sys/bus/pnp/drivers/serial/*/resources
> > > cat: /sys/bus/pnp/drivers/serial/*/resources: No such file or directory
> > 
> > irq 12 for ttyS1? That should be irq 3. The bios is putting bogus information
> > in pnp. Maybe there is rubbish in the bios setup or maybe it's fixed in a 
> > newer bios update.
> > 
> > So before this change, the kernel would assume irq 3. After this change,
> > the kernel first uses the information in pnp to see where the serial
> > port is. It gets told that it's irq 12 and presumably it runs into all
> > sorts of problems then. If memory serves that's the irq for the ps/2 mouse.
> > 
> > The interesting bit is in 3.6.0:
> > 
> > setserial
> > /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
> > 
> > becomes in 3.7.0:
> > 
> > setserial
> > /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 12
> > 
> > You should be able to set the right irq with setserial, but obviously
> > that doesn't help you if it fails in early boot. It's not immediately
> > obvious to me what can be done in the kernel for this. Maybe the dmesg
> > output could inspire, thanks.
> 
> Yea the changing irq seemed weird to me too but I couldn't manage a guess to why.
> 
> Here are the dmesgs.

So with 3.6.0:

> [    2.079980] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
> [    2.100887] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> [    2.101715] serial 00:04: unable to assign resources
> [    2.102174] serial: probe of 00:04 failed with error -16

The pnp probe fails for some reason. I don't understand why.

With 3.7.0:

> [    2.062700] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
> [    2.063250] serial 00:04: [io  0x02f8-0x02ff]
> [    2.063875] serial 00:04: [irq 12]
> [    2.064345] serial 00:04: [dma 18446744073709551615 disabled]
> [    2.065540] serial 00:04: activated
> [    2.086442] 00:04: ttyS1 at I/O 0x2f8 (irq = 12) is a 16550A

Now the pnp probe succeeds (with broken irq from pnp).

Can you please check if there is a wrong irq configured in the bios setup
or if there is a bios update available? I don't know why this worked in
the first place.


Sean

[toc] | [prev] | [next] | [standalone]

#1504363

On 10/19/2016 04:07 AM, Sean Young wrote:
> On Tue, Oct 18, 2016 at 02:29:30PM -0500, Nathan Zimmer wrote:
>> On Tue, Oct 18, 2016 at 07:05:18PM +0100, Sean Young wrote:
>>> On Tue, Oct 18, 2016 at 11:40:04AM -0500, Nathan Zimmer wrote:
>>>> 3.7.0
>>>> cat /sys/bus/pnp/drivers/serial/*/resources
>>>> state = active
>>>> io 0x2f8-0x2ff
>>>> irq 12
>>>> dma disabled
>>>>
>>>> 3.6.0
>>>> :~ # cat /sys/bus/pnp/drivers/serial/*/resources
>>>> cat: /sys/bus/pnp/drivers/serial/*/resources: No such file or directory
>>> irq 12 for ttyS1? That should be irq 3. The bios is putting bogus information
>>> in pnp. Maybe there is rubbish in the bios setup or maybe it's fixed in a
>>> newer bios update.
>>>
>>> So before this change, the kernel would assume irq 3. After this change,
>>> the kernel first uses the information in pnp to see where the serial
>>> port is. It gets told that it's irq 12 and presumably it runs into all
>>> sorts of problems then. If memory serves that's the irq for the ps/2 mouse.
>>>
>>> The interesting bit is in 3.6.0:
>>>
>>> setserial
>>> /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
>>>
>>> becomes in 3.7.0:
>>>
>>> setserial
>>> /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 12
>>>
>>> You should be able to set the right irq with setserial, but obviously
>>> that doesn't help you if it fails in early boot. It's not immediately
>>> obvious to me what can be done in the kernel for this. Maybe the dmesg
>>> output could inspire, thanks.
>> Yea the changing irq seemed weird to me too but I couldn't manage a guess to why.
>>
>> Here are the dmesgs.
> So with 3.6.0:
>
>> [    2.079980] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
>> [    2.100887] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>> [    2.101715] serial 00:04: unable to assign resources
>> [    2.102174] serial: probe of 00:04 failed with error -16
> The pnp probe fails for some reason. I don't understand why.
>
> With 3.7.0:
>
>> [    2.062700] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
>> [    2.063250] serial 00:04: [io  0x02f8-0x02ff]
>> [    2.063875] serial 00:04: [irq 12]
>> [    2.064345] serial 00:04: [dma 18446744073709551615 disabled]
>> [    2.065540] serial 00:04: activated
>> [    2.086442] 00:04: ttyS1 at I/O 0x2f8 (irq = 12) is a 16550A
> Now the pnp probe succeeds (with broken irq from pnp).
>
> Can you please check if there is a wrong irq configured in the bios setup
> or if there is a bios update available? I don't know why this worked in
> the first place.
>
>
> Sean

Apparently this is the latest bios available for these nodes.
Also in the bios setup screens I don't see anything for changing irq 
numbers for serial console.
But this is a cluster so sometimes thing get hidden to keep everything 
uniform as possible.

If you want to point me to the pnp probe code you would be suspicious of 
I can try to debug and see what is going there.

[toc] | [prev] | [next] | [standalone]

#1505230

On Wed, Oct 19, 2016 at 05:13:41PM -0500, Nathan Zimmer wrote:
> On 10/19/2016 04:07 AM, Sean Young wrote:
> >So with 3.6.0:
> >
> >>[    2.079980] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
> >>[    2.100887] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> >>[    2.101715] serial 00:04: unable to assign resources
> >>[    2.102174] serial: probe of 00:04 failed with error -16
> >The pnp probe fails for some reason. I don't understand why.
> >
> >With 3.7.0:
> >
> >>[    2.062700] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
> >>[    2.063250] serial 00:04: [io  0x02f8-0x02ff]
> >>[    2.063875] serial 00:04: [irq 12]
> >>[    2.064345] serial 00:04: [dma 18446744073709551615 disabled]
> >>[    2.065540] serial 00:04: activated
> >>[    2.086442] 00:04: ttyS1 at I/O 0x2f8 (irq = 12) is a 16550A
> >Now the pnp probe succeeds (with broken irq from pnp).
> >
> >Can you please check if there is a wrong irq configured in the bios setup
> >or if there is a bios update available? I don't know why this worked in
> >the first place.
> 
> Apparently this is the latest bios available for these nodes.
> Also in the bios setup screens I don't see anything for changing irq numbers
> for serial console.
> But this is a cluster so sometimes thing get hidden to keep everything
> uniform as possible.
> 
> If you want to point me to the pnp probe code you would be suspicious of I
> can try to debug and see what is going there.

That would be great, thanks. A good start would be to boot 3.6.0 with 
"loglevel=7 pnp.debug=1" and hopefully that will show why the probe
used to fail.

Also, does the issue still exist with a more contemporary kernel?


Sean

[toc] | [prev] | [next] | [standalone]

#1506115

It didn't seem to make a difference as far as output.
Did I miss a config option? or something else?

[    0.000000] Linux version 3.6.0 (root@r1i2n0) (gcc version 4.3.4 
[gcc-4_3-branch revision 152973] (SUSE Linux) ) #3 SMP Mon Oct 17 
20:43:34 EDT 2016
[    0.000000] Command line: 
root=/dev/disk/by-id/ata-WDC_WD5000BHTZ-04JCPV1_WD-WXA1E54KKR60-part2 
resume=/dev/disk/by-id/ata-WDC_WD5000BHTZ-04JCPV1_WD-WXA1E54KKR60-part1 
crashkernel=256M-:128M loglevel=8 pnp.debug=1
...
[    2.076084] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    2.097001] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    2.097844] serial 00:04: unable to assign resources
[    2.098303] serial: probe of 00:04 failed with error -16


On 10/20/2016 03:10 PM, Sean Young wrote:
> On Wed, Oct 19, 2016 at 05:13:41PM -0500, Nathan Zimmer wrote:
>> On 10/19/2016 04:07 AM, Sean Young wrote:
>>> So with 3.6.0:
>>>
>>>> [    2.079980] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
>>>> [    2.100887] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>>>> [    2.101715] serial 00:04: unable to assign resources
>>>> [    2.102174] serial: probe of 00:04 failed with error -16
>>> The pnp probe fails for some reason. I don't understand why.
>>>
>>> With 3.7.0:
>>>
>>>> [    2.062700] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
>>>> [    2.063250] serial 00:04: [io  0x02f8-0x02ff]
>>>> [    2.063875] serial 00:04: [irq 12]
>>>> [    2.064345] serial 00:04: [dma 18446744073709551615 disabled]
>>>> [    2.065540] serial 00:04: activated
>>>> [    2.086442] 00:04: ttyS1 at I/O 0x2f8 (irq = 12) is a 16550A
>>> Now the pnp probe succeeds (with broken irq from pnp).
>>>
>>> Can you please check if there is a wrong irq configured in the bios setup
>>> or if there is a bios update available? I don't know why this worked in
>>> the first place.
>> Apparently this is the latest bios available for these nodes.
>> Also in the bios setup screens I don't see anything for changing irq numbers
>> for serial console.
>> But this is a cluster so sometimes thing get hidden to keep everything
>> uniform as possible.
>>
>> If you want to point me to the pnp probe code you would be suspicious of I
>> can try to debug and see what is going there.
> That would be great, thanks. A good start would be to boot 3.6.0 with
> "loglevel=7 pnp.debug=1" and hopefully that will show why the probe
> used to fail.
>
> Also, does the issue still exist with a more contemporary kernel?
>
>
> Sean

[toc] | [prev] | [next] | [standalone]

#1507220

On Fri, Oct 21, 2016 at 10:55:40AM -0500, Nathan Zimmer wrote:
> It didn't seem to make a difference as far as output.
> Did I miss a config option? or something else?
> 
> [    0.000000] Linux version 3.6.0 (root@r1i2n0) (gcc version 4.3.4
> [gcc-4_3-branch revision 152973] (SUSE Linux) ) #3 SMP Mon Oct 17 20:43:34
> EDT 2016
> [    0.000000] Command line:
> root=/dev/disk/by-id/ata-WDC_WD5000BHTZ-04JCPV1_WD-WXA1E54KKR60-part2
> resume=/dev/disk/by-id/ata-WDC_WD5000BHTZ-04JCPV1_WD-WXA1E54KKR60-part1
> crashkernel=256M-:128M loglevel=8 pnp.debug=1
> ...
> [    2.076084] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
> [    2.097001] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> [    2.097844] serial 00:04: unable to assign resources
> [    2.098303] serial: probe of 00:04 failed with error -16

Ehm is this kernel compiled with CONFIG_PNP_DEBUG_MESSAGES? Are you 
getting any debug messages? You could try ignore_loglevel. 


Sean

[toc] | [prev] | [next] | [standalone]

#1508614

On Mon, Oct 24, 2016 at 04:49:25PM -0500, Nathan Zimmer wrote:
> [    0.974874] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.975038] pnp 00:04: parse resource options
> [    0.975048] pnp 00:04:   dependent set 0 (acceptable) io  min 0x2f8 max 0x2f8 align 1 size 8 flags 0x1
> [    0.975056] pnp 00:04:   dependent set 0 (acceptable) irq 3 4 5 6 7 10 11 12 flags 0x1
> [    0.975060] pnp 00:04:   dependent set 0 (acceptable) dma <none> (bitmask 0x0) flags 0x0

So here the bios claims that the serial port can use any of 3 to 12 irqs.

> [    1.543636] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled

Why is this kernel compiled with irq sharing disabled?

> [    1.565062] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

The isa probe driver find the serial port.

> [    1.566453] serial 00:04: pnp_assign_resources, try dependent set 0
> [    1.567383] serial 00:04:   couldn't assign io 0 (min 0x2f8 max 0x2f8)

But then decides that the port is already in use (the existing serial driver).

> [    1.568366] serial 00:04: pnp_assign_resources failed (-16)
> [    1.569188] serial 00:04: unable to assign resources
> [    1.569924] serial: probe of 00:04 failed with error -16

Please try and boot 3.7.0 with "8250.share_irqs=1", maybe it will pick
irq 3 and it will be happy again, but that is just a guess.

I think I have not fully understood what the failure is. Does the serial
port not work or does the boot hang? What are the symptoms?

We might be able to fix the problem with a pnp quirk but 3.7 is has not had
any releases for a long time. We will need a reproduction on a concurrent
kernel so a patch can be written for that.


Sean

[toc] | [prev] | [next] | [standalone]

#1509683

On 10/25/2016 03:41 PM, Sean Young wrote:
> On Mon, Oct 24, 2016 at 04:49:25PM -0500, Nathan Zimmer wrote:
>> [    0.974874] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
>> [    0.975038] pnp 00:04: parse resource options
>> [    0.975048] pnp 00:04:   dependent set 0 (acceptable) io  min 0x2f8 max 0x2f8 align 1 size 8 flags 0x1
>> [    0.975056] pnp 00:04:   dependent set 0 (acceptable) irq 3 4 5 6 7 10 11 12 flags 0x1
>> [    0.975060] pnp 00:04:   dependent set 0 (acceptable) dma <none> (bitmask 0x0) flags 0x0
> So here the bios claims that the serial port can use any of 3 to 12 irqs.
>
>> [    1.543636] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
> Why is this kernel compiled with irq sharing disabled?
Because I first noticed the error on a sles kernel and that is how they 
have it set.
The error also occurs with sharing on.

<snip from a 4.8 dmesg with irq sharing enabled>
[    4.662336] Serial: 8250/16550 driver, 8 ports, IRQ sharing enabled
[    4.663316] serial 00:03: pnp_assign_resources, try dependent set 0
[    4.664249] serial 00:03: [io  0x02f8-0x02ff]
[    4.664913] serial 00:03:   device 0000:00:16.1 using irq 5
[    4.688879] serial 00:03:   device 0000:00:1f.3 using irq 10
[    4.712265] serial 00:03:   device 0000:00:16.0 using irq 11
[    4.735265] serial 00:03: [irq 12]
[    4.757538] serial 00:03:   dma 0 disabled
[    4.780153] serial 00:03: [dma 18446744073709551615 disabled]
[    4.802826] serial 00:03: pnp_assign_resources succeeded: current 
resources:
[    4.825758] serial 00:03: [io  0x02f8-0x02ff flags 0x40000101]
[    4.848625] serial 00:03: [irq 12 flags 0x40000401]
[    4.871224] serial 00:03: [dma 18446744073709551615 flags 0x50000800]
[    4.893988] serial 00:03: pnp_start_dev: current resources:
[    4.916634] serial 00:03: [io  0x02f8-0x02ff flags 0x40000101]
[    4.939280] serial 00:03: [irq 12 flags 0x40000401]
[    4.961646] serial 00:03: [dma 18446744073709551615 flags 0x50000800]
[    4.984180] serial 00:03: set resources
[    5.006654] serial 00:03: encode 3 resources
[    5.028545] serial 00:03:   encode io 0x2f8-0x2ff decode 0x1
[    5.050486] serial 00:03:   encode irq 12 edge high exclusive (2-byte 
descriptor)
[    5.072593] serial 00:03:   encode dma (disabled)
[    5.094644] serial 00:03: activated
[    5.136000] 00:03: ttyS1 at I/O 0x2f8 (irq = 12, base_baud = 115200) 
is a 16550A


>> [    1.565062] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> The isa probe driver find the serial port.
>
>> [    1.566453] serial 00:04: pnp_assign_resources, try dependent set 0
>> [    1.567383] serial 00:04:   couldn't assign io 0 (min 0x2f8 max 0x2f8)
> But then decides that the port is already in use (the existing serial driver).
>> [    1.568366] serial 00:04: pnp_assign_resources failed (-16)
>> [    1.569188] serial 00:04: unable to assign resources
>> [    1.569924] serial: probe of 00:04 failed with error -16
> Please try and boot 3.7.0 with "8250.share_irqs=1", maybe it will pick
> irq 3 and it will be happy again, but that is just a guess.
>
> I think I have not fully understood what the failure is. Does the serial
> port not work or does the boot hang? What are the symptoms?
With console=ttyS1 the boot will "hang", sometimes it makes it all the 
way through but may take 30 minutes, instead of the 2-4 minutes this box

> We might be able to fix the problem with a pnp quirk but 3.7 is has not had
> any releases for a long time. We will need a reproduction on a concurrent
> kernel so a patch can be written for that.
Yes it still happens with 4.8+
I had only started dwelling on 3.6/3.7 since that is where it first 
appears and don't have any attachment to those.

>
> Sean

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web