Hi,
On Sun, Apr 23, 2006 at 03:02:06PM -0700, Andrew Morton wrote:
> It's actually not an oops - it's a warning, telling us that i82365 is
> requesting an IRQ in non-sharing mode, but there's already a handler
> registered for that IRQ (which might or might not be shareable).
And the same thing on a Toshiba Satellite 4280, P3/450, 2.6.17-rc3-ck2:
setup_irq: irq handler mismatch
<c0103248> show_trace+0xd/0xf <c010325f> dump_stack+0x15/0x17
<c012aeca> setup_irq+0xd9/0xe8 <c012b002> request_irq+0x6e/0x8c
<c020cdfd> serial8250_startup+0x263/0x394 <c020a1aa> uart_startup+0x68/0xf1
<c020adba> uart_ioctl+0x554/0x847 <c01f31ed> tty_ioctl+0xbae/0xc36
<c0151eec> do_ioctl+0x3c/0x4f <c01520ed> vfs_ioctl+0x1ee/0x205
<c015212e> sys_ioctl+0x2a/0x44 <c01029bb> sysenter_past_esp+0x54/0x75
setup_irq: irq handler mismatch
<c0103248> show_trace+0xd/0xf <c010325f> dump_stack+0x15/0x17
<c012aeca> setup_irq+0xd9/0xe8 <c012b002> request_irq+0x6e/0x8c
<c020cdfd> serial8250_startup+0x263/0x394 <c020a1aa> uart_startup+0x68/0xf1
<c020a3aa> uart_open+0x177/0x345 <c01f399d> tty_open+0x174/0x29a
<c014b0b5> chrdev_open+0xf6/0x10d <c0143b37> __dentry_open+0xb7/0x185
<c0143c73> nameidata_to_filp+0x1c/0x2e <c0143cb3> do_filp_open+0x2e/0x35
<c0143d9e> do_sys_open+0x3f/0xb7 <c0143e42> sys_open+0x16/0x18
<c01029bb> sysenter_past_esp+0x54/0x75
setup_irq: irq handler mismatch
<c0103248> show_trace+0xd/0xf <c010325f> dump_stack+0x15/0x17
<c012aeca> setup_irq+0xd9/0xe8 <c012b002> request_irq+0x6e/0x8c
<c020cdfd> serial8250_startup+0x263/0x394 <c020a1aa> uart_startup+0x68/0xf1
<c020a3aa> uart_open+0x177/0x345 <c01f399d> tty_open+0x174/0x29a
<c014b0b5> chrdev_open+0xf6/0x10d <c0143b37> __dentry_open+0xb7/0x185
<c0143c73> nameidata_to_filp+0x1c/0x2e <c0143cb3> do_filp_open+0x2e/0x35
<c0143d9e> do_sys_open+0x3f/0xb7 <c0143e42> sys_open+0x16/0x18
<c01029bb> sysenter_past_esp+0x54/0x75
# cat /proc/interrupts
CPU0
0: 31607214 XT-PIC timer
1: 11092 XT-PIC i8042
2: 0 XT-PIC cascade
3: 36368 XT-PIC pcnet_cs
8: 3 XT-PIC rtc
9: 84 XT-PIC acpi
11: 73639 XT-PIC yenta, yenta, uhci_hcd:usb1, YMFPCI, irda0
12: 9996 XT-PIC i8042
14: 63830 XT-PIC ide0
15: 536942 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
# lspci
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
0000:00:05.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
0000:00:05.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
0000:00:05.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
0000:00:05.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
0000:00:07.0 Communication controller: Agere Systems 56k WinModem (rev 01)
0000:00:09.0 IRDA controller: Toshiba America Info Systems FIR Port Type-DO
0000:00:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus Bridge with ZV Support (rev 20)
0000:00:0b.1 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus Bridge with ZV Support (rev 20)
0000:00:0c.0 Multimedia audio controller: Yamaha Corporation YMF-744B [DS-1S Audio Controller] (rev 02)
0000:01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
> Your machine should otherwise continue to work OK. Is that the case?
It seems so, yes.
> i82365 appears to be poking around in interrupt space trying to find an IRQ
> which isn't shared with anyone else (I'm not sure why, but these sorts of
> things tend to be derived from hard experience).
>
> Anyway. We need to either a) make i82365 better-behaved or b) remove the
> warning or c) allow callers to suppress the warning (SA_PROBEIRQ?).
Add SA_PROBEIRQ to 8250.c, then, I guess?
Thanks!
Andreas Mohr
Andreas Mohr <[email protected]> wrote:
>
> Hi,
>
> On Sun, Apr 23, 2006 at 03:02:06PM -0700, Andrew Morton wrote:
> > It's actually not an oops - it's a warning, telling us that i82365 is
> > requesting an IRQ in non-sharing mode, but there's already a handler
> > registered for that IRQ (which might or might not be shareable).
>
> And the same thing on a Toshiba Satellite 4280, P3/450, 2.6.17-rc3-ck2:
>
> setup_irq: irq handler mismatch
> <c0103248> show_trace+0xd/0xf <c010325f> dump_stack+0x15/0x17
> <c012aeca> setup_irq+0xd9/0xe8 <c012b002> request_irq+0x6e/0x8c
> <c020cdfd> serial8250_startup+0x263/0x394 <c020a1aa> uart_startup+0x68/0xf1
> <c020adba> uart_ioctl+0x554/0x847 <c01f31ed> tty_ioctl+0xbae/0xc36
> <c0151eec> do_ioctl+0x3c/0x4f <c01520ed> vfs_ioctl+0x1ee/0x205
> <c015212e> sys_ioctl+0x2a/0x44 <c01029bb> sysenter_past_esp+0x54/0x75
>
> ...
>
> # cat /proc/interrupts
> CPU0
> 0: 31607214 XT-PIC timer
> 1: 11092 XT-PIC i8042
> 2: 0 XT-PIC cascade
> 3: 36368 XT-PIC pcnet_cs
> 8: 3 XT-PIC rtc
> 9: 84 XT-PIC acpi
> 11: 73639 XT-PIC yenta, yenta, uhci_hcd:usb1, YMFPCI, irda0
> 12: 9996 XT-PIC i8042
> 14: 63830 XT-PIC ide0
> 15: 536942 XT-PIC ide1
> NMI: 0
> LOC: 0
> ERR: 0
So 8250 is requesting an IRQ for non-sharing mode and it's actually
failing, because something else is already using that IRQ. The difference
is that the kernel now generates a warning when this happens.
> # lspci
> 0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
> 0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
> 0000:00:05.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
> 0000:00:05.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
> 0000:00:05.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
> 0000:00:05.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 0000:00:07.0 Communication controller: Agere Systems 56k WinModem (rev 01)
> 0000:00:09.0 IRDA controller: Toshiba America Info Systems FIR Port Type-DO
> 0000:00:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus Bridge with ZV Support (rev 20)
> 0000:00:0b.1 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus Bridge with ZV Support (rev 20)
> 0000:00:0c.0 Multimedia audio controller: Yamaha Corporation YMF-744B [DS-1S Audio Controller] (rev 02)
> 0000:01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
>
> > Your machine should otherwise continue to work OK. Is that the case?
>
> It seems so, yes.
I don't see how your 8250 can be working if serial_link_irq_chain() has failed.
> > i82365 appears to be poking around in interrupt space trying to find an IRQ
> > which isn't shared with anyone else (I'm not sure why, but these sorts of
> > things tend to be derived from hard experience).
> >
> > Anyway. We need to either a) make i82365 better-behaved or b) remove the
> > warning or c) allow callers to suppress the warning (SA_PROBEIRQ?).
>
> Add SA_PROBEIRQ to 8250.c, then, I guess?
That would be appropriate if it is actually expected that the request_irq()
in there will fail, and we still manage to make the hardware work via some
fallback method. But I don't immediately see any code which does that.
Russell, any opinions?
Thanks.
On Mon, May 08, 2006 at 08:43:01AM -0700, Andrew Morton wrote:
> Andreas Mohr <[email protected]> wrote:
> >
> > Hi,
> >
> > On Sun, Apr 23, 2006 at 03:02:06PM -0700, Andrew Morton wrote:
> > > It's actually not an oops - it's a warning, telling us that i82365 is
> > > requesting an IRQ in non-sharing mode, but there's already a handler
> > > registered for that IRQ (which might or might not be shareable).
> >
> > And the same thing on a Toshiba Satellite 4280, P3/450, 2.6.17-rc3-ck2:
> >
> > setup_irq: irq handler mismatch
> > <c0103248> show_trace+0xd/0xf <c010325f> dump_stack+0x15/0x17
> > <c012aeca> setup_irq+0xd9/0xe8 <c012b002> request_irq+0x6e/0x8c
> > <c020cdfd> serial8250_startup+0x263/0x394 <c020a1aa> uart_startup+0x68/0xf1
> > <c020adba> uart_ioctl+0x554/0x847 <c01f31ed> tty_ioctl+0xbae/0xc36
> > <c0151eec> do_ioctl+0x3c/0x4f <c01520ed> vfs_ioctl+0x1ee/0x205
> > <c015212e> sys_ioctl+0x2a/0x44 <c01029bb> sysenter_past_esp+0x54/0x75
Hmm, someone's fiddling with setserial here...
> > # cat /proc/interrupts
> > CPU0
> > 0: 31607214 XT-PIC timer
> > 1: 11092 XT-PIC i8042
> > 2: 0 XT-PIC cascade
> > 3: 36368 XT-PIC pcnet_cs
> > 8: 3 XT-PIC rtc
> > 9: 84 XT-PIC acpi
> > 11: 73639 XT-PIC yenta, yenta, uhci_hcd:usb1, YMFPCI, irda0
> > 12: 9996 XT-PIC i8042
> > 14: 63830 XT-PIC ide0
> > 15: 536942 XT-PIC ide1
> > NMI: 0
> > LOC: 0
> > ERR: 0
>
> So 8250 is requesting an IRQ for non-sharing mode and it's actually
> failing, because something else is already using that IRQ. The difference
> is that the kernel now generates a warning when this happens.
Maybe someone is clearing the UPF_SHARE_IRQ flag? Which port is this?
> Russell, any opinions?
I'd like to get a better idea what's going on here. Is this a port on a
PCMCIA card? Is it a motherboard serial port? Which IRQ is it trying
to use? How was it setup?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Llu, 2006-05-08 at 17:34 +0100, Russell King wrote:
> > So 8250 is requesting an IRQ for non-sharing mode and it's actually
> > failing, because something else is already using that IRQ. The difference
> > is that the kernel now generates a warning when this happens.
>
> Maybe someone is clearing the UPF_SHARE_IRQ flag? Which port is this?
Its a bug in the PCMCIA code. Its the one I hit with the IDE code.
Asking for a private IRQ is not always honoured.
Just happened to see the message again and notice the pattern.
Alan
On Mon, May 15, 2006 at 11:07:08PM +0100, Alan Cox wrote:
> On Llu, 2006-05-08 at 17:34 +0100, Russell King wrote:
> > > So 8250 is requesting an IRQ for non-sharing mode and it's actually
> > > failing, because something else is already using that IRQ. The difference
> > > is that the kernel now generates a warning when this happens.
> >
> > Maybe someone is clearing the UPF_SHARE_IRQ flag? Which port is this?
>
> Its a bug in the PCMCIA code. Its the one I hit with the IDE code.
> Asking for a private IRQ is not always honoured.
Not in this case - the call trace is definitely a result of setserial
being used. serial_cs _always_ registers ports with 8250 with the
share IRQ flag set.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Mon, 15 May 2006, Alan Cox wrote:
> On Llu, 2006-05-08 at 17:34 +0100, Russell King wrote:
> > > So 8250 is requesting an IRQ for non-sharing mode and it's actually
> > > failing, because something else is already using that IRQ. The difference
> > > is that the kernel now generates a warning when this happens.
> >
> > Maybe someone is clearing the UPF_SHARE_IRQ flag? Which port is this?
>
> Its a bug in the PCMCIA code. Its the one I hit with the IDE code.
> Asking for a private IRQ is not always honoured.
Note that some PCMCIA architectures simply _will_not_ give you a private
IRQ. Ever. They may not have any ISA interrupts to give, even to old
16-bit cards. So the choice may be "shared irq or nothing".
So I would strongly argue that any driver that depends on getting an
exclusive IRQ is buggy, not the PCMCIA layer itself, and that it would be
a lot more productive to try to fix those drivers.
Especially since exclusive irq's are clearly a dying breed, and have been
for the last decade or two. Why try to keep that braindamage alive?
Linus
On Llu, 2006-05-15 at 15:02 -0700, Linus Torvalds wrote:
> Note that some PCMCIA architectures simply _will_not_ give you a private
> IRQ. Ever. They may not have any ISA interrupts to give, even to old
> 16-bit cards. So the choice may be "shared irq or nothing".
Yes I realise that, the test patches in my tree will hand back a shared
one but hand back the status so you know you asked for exclusive, got
shared and need to decide.
> So I would strongly argue that any driver that depends on getting an
> exclusive IRQ is buggy, not the PCMCIA layer itself, and that it would be
> a lot more productive to try to fix those drivers.
It would certainly be a lot cleaner than this sort of code in the pcmcia
core right now. Want me to send a patch which only allows for SA_SHIRQ
and WARN_ON()'s for any driver not asking for shared IRQ ?
On Tue, 16 May 2006, Alan Cox wrote:
>
> It would certainly be a lot cleaner than this sort of code in the pcmcia
> core right now. Want me to send a patch which only allows for SA_SHIRQ
> and WARN_ON()'s for any driver not asking for shared IRQ ?
I think it's too late for that in the current series, but yes, we could do
it for 2.6.18.
There are a few valid reasons for not using SA_SHIRQ, but they tend to be
really special. Ie you'd better _know_ that you're either some system
device, or you're physically in an ISA slot, not just based on some old
ISA design. And PCMCIA is no longer an excuse, exactly because of some
systems that will route even the 16-bit interrupts through a PCI irq.
So anything in arch/ is likely ok (for example, the vm86 interrupt
handling on x86 had _better_ be an exclusive interrupt ;)
Doing a quick grep shows a surprising amount of drivers that pass in zero,
but I guess that they truly _are_ old ISA sound/networking drivers.
Linus
On Mon, 15 May 2006, Linus Torvalds wrote:
>
> On Tue, 16 May 2006, Alan Cox wrote:
> >
> > It would certainly be a lot cleaner than this sort of code in the
> > pcmcia core right now. Want me to send a patch which only allows for
> > SA_SHIRQ and WARN_ON()'s for any driver not asking for shared IRQ ?
>
> I think it's too late for that in the current series, but yes, we could do
> it for 2.6.18.
Actually, thinking about it some more, what we _should_ do is to just make
any code that simply doesn't _work_ with shared interrupts have to use
SA_EXCLUSIVE.
And then, for a while, warn if we see a "request_irq()" call that has
neither SA_SHIRQ nor SA_EXCLUSIVE set. But this would be a pretty mild
warning, along the lines of
"%s getting non-SHIRQ irq. It _may_ or may not be shared in the future"
and eventually just stop caring, and making SA_SHIRQ have no meaning. It's
kind of pointless to ask all drivers to use SA_SHIRQ, when it really
should be the default.
Even the ISA drivers that currently do not have SA_SHIRQ won't generally
_break_ when/if they were to get a shared interrupt. The reason they don't
have SA_SHIRQ isn't generally that they really really want an exclusive
interrupt, but simply because they never had a reason to say SA_SHIRQ.
So a lack of SA_SHIRQ doesn't generally mean "I _need_ an exclusive
interrupt". It could equally well mean "I never bothered to even think
about whether I could share interrupts or not".
Making it an error to pass in 0 would be silly, because for old ISA
devices, most of the time they really just don't care.
What think you?
The SA_EXCLUSIVE flag is still needed, but it would be used by things that
literally cannot handle anything but an exclusive interrupt (eg vm86 mode
irq access), exactly because they do things like disable that particular
irq for long times, or because they don't have a status register to read
(eg, on x86, the timer interrupt really _is_ exclusive for that reason).
Most ISA drivers probably wouldn't care at all one way or the other, I
suspect. And it would be a waste of time to add SA_SHIRQ to them for no
actual real gain.
Comments?
Linus
On Llu, 2006-05-15 at 16:52 -0700, Linus Torvalds wrote:
> Even the ISA drivers that currently do not have SA_SHIRQ won't generally
> _break_ when/if they were to get a shared interrupt. The reason they don't
> have SA_SHIRQ isn't generally that they really really want an exclusive
> interrupt, but simply because they never had a reason to say SA_SHIRQ.
The reason they do it is also however because the ISA bus IRQ allocation
scheme and IRQ probing scheme they use for auto detection relies upon
other users marking the IRQ as exclusively used. The same is true for
things like setserial and ISA ports.
Given the historical use of exclusive IRQ allocation as a resource
management API it appears to be easier just to beat up the PCMCIA
drivers where the resource element is not present (it is tracked
internally by the pcmcia core).
PCMCIA doesn't seem to have too many offenders, and the number of
drivers is low so it won't take long to go over them.
Alan
On Tue, 16 May 2006, Alan Cox wrote:
>
> The reason they do it is also however because the ISA bus IRQ allocation
> scheme and IRQ probing scheme they use for auto detection relies upon
> other users marking the IRQ as exclusively used. The same is true for
> things like setserial and ISA ports.
The irq auto-detection should work with shared interrupts, but yes, it
won't _detect_ them if they are already in use (but it's ok with them
becoming shared later).
That said, true ISA cards obviously won't ever have a shared irq, in any
normal circumstances.
Which is one reason why I think it would be silly to force such a driver
to use a SA_SHIRQ flag, and would prefer to do it the other way instead
(ie make drivers that fundamentally _require_ - as opposed to "in
practice use" - an exclusive interrupt say so).
> PCMCIA doesn't seem to have too many offenders, and the number of
> drivers is low so it won't take long to go over them.
Yeah.
Linus
On Llu, 2006-05-15 at 17:18 -0700, Linus Torvalds wrote:
> The irq auto-detection should work with shared interrupts, but yes, it
> won't _detect_ them if they are already in use (but it's ok with them
> becoming shared later).
>
> That said, true ISA cards obviously won't ever have a shared irq, in any
> normal circumstances.
It really isn't that simple. ISAPnP and later ISA cards often allowed
the IRQ to be configured at runtime. Drivers doing this depend upon the
request_irq failing to decide which interrupt line to assign. The
resource management side of exclusive IRQ allocation is for better or
worse deeply embedded in the current interrupt design.
Alan
On Llu, 2006-05-15 at 16:37 -0700, Linus Torvalds wrote:
> ISA design. And PCMCIA is no longer an excuse, exactly because of some
> systems that will route even the 16-bit interrupts through a PCI irq.
The patch below cleans up the pcmcia code a bit on the IRQ side (I did
this while debugging the problem just so I could read wtf it was doing),
and also adds a warning and passes back the correct information when a
device asks for exclusive but gets given shared. This at least means the
dmesg dump of a problem triggered by this will have a signature to find.
Alan
Signed-off-by: Alan Cox <[email protected]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.17-rc4/drivers/pcmcia/pcmcia_resource.c linux-2.6.17-rc4/drivers/pcmcia/pcmcia_resource.c
--- linux.vanilla-2.6.17-rc4/drivers/pcmcia/pcmcia_resource.c 2006-05-15 15:46:04.000000000 +0100
+++ linux-2.6.17-rc4/drivers/pcmcia/pcmcia_resource.c 2006-05-16 14:59:42.000000000 +0100
@@ -788,6 +788,7 @@
struct pcmcia_socket *s = p_dev->socket;
config_t *c;
int ret = CS_IN_USE, irq = 0;
+ int type;
if (!(s->state & SOCKET_PRESENT))
return CS_NO_CARD;
@@ -797,6 +798,13 @@
if (c->state & CONFIG_IRQ_REQ)
return CS_IN_USE;
+ /* Decide what type of interrupt we are registering */
+ type = 0;
+ if (s->functions > 1) /* All of this ought to be handled higher up */
+ type = SA_SHIRQ;
+ if (req->Attributes & IRQ_TYPE_DYNAMIC_SHARING)
+ type = SA_SHIRQ;
+
#ifdef CONFIG_PCMCIA_PROBE
if (s->irq.AssignedIRQ != 0) {
/* If the interrupt is already assigned, it must be the same */
@@ -822,9 +830,7 @@
* marked as used by the kernel resource management core */
ret = request_irq(irq,
(req->Attributes & IRQ_HANDLE_PRESENT) ? req->Handler : test_action,
- ((req->Attributes & IRQ_TYPE_DYNAMIC_SHARING) ||
- (s->functions > 1) ||
- (irq == s->pci_irq)) ? SA_SHIRQ : 0,
+ type,
p_dev->devname,
(req->Attributes & IRQ_HANDLE_PRESENT) ? req->Instance : data);
if (!ret) {
@@ -839,18 +845,21 @@
if (ret && !s->irq.AssignedIRQ) {
if (!s->pci_irq)
return ret;
+ type = SA_SHIRQ;
irq = s->pci_irq;
}
- if (ret && req->Attributes & IRQ_HANDLE_PRESENT) {
- if (request_irq(irq, req->Handler,
- ((req->Attributes & IRQ_TYPE_DYNAMIC_SHARING) ||
- (s->functions > 1) ||
- (irq == s->pci_irq)) ? SA_SHIRQ : 0,
- p_dev->devname, req->Instance))
+ if (ret && (req->Attributes & IRQ_HANDLE_PRESENT)) {
+ if (request_irq(irq, req->Handler, type, p_dev->devname, req->Instance))
return CS_IN_USE;
}
+ /* Make sure the fact the request type was overridden is passed back */
+ if (type == SA_SHIRQ && !(req->Attributes & IRQ_TYPE_DYNAMIC_SHARING)) {
+ req->Attributes |= IRQ_TYPE_DYNAMIC_SHARING;
+ printk(KERN_WARNING "pcmcia: request for exclusive IRQ could not be fulfilled.\n");
+ printk(KERN_WARNING "pcmcia: the driver needs updating to supported shared IRQ lines.\n");
+ }
c->irq.Attributes = req->Attributes;
s->irq.AssignedIRQ = req->AssignedIRQ = irq;
s->irq.Config++;
On Mon, May 15, 2006 at 11:00:44PM +0100, Russell King wrote:
> On Mon, May 15, 2006 at 11:07:08PM +0100, Alan Cox wrote:
> > On Llu, 2006-05-08 at 17:34 +0100, Russell King wrote:
> > > > So 8250 is requesting an IRQ for non-sharing mode and it's actually
> > > > failing, because something else is already using that IRQ. The difference
> > > > is that the kernel now generates a warning when this happens.
> > >
> > > Maybe someone is clearing the UPF_SHARE_IRQ flag? Which port is this?
> >
> > Its a bug in the PCMCIA code. Its the one I hit with the IDE code.
> > Asking for a private IRQ is not always honoured.
>
> Not in this case - the call trace is definitely a result of setserial
> being used. serial_cs _always_ registers ports with 8250 with the
> share IRQ flag set.
Given that no one has responded to my comments on this, I take it that
this is a case of user error or distro scripting error.
setserial should never be used to clear the shared IRQ flag bit unless
there's a very good reason (eg, the admin knows that the IRQ should not
be shared.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Tue, May 16, 2006 at 12:00:26AM +0100, Alan Cox wrote:
> > So I would strongly argue that any driver that depends on getting an
> > exclusive IRQ is buggy, not the PCMCIA layer itself, and that it would be
> > a lot more productive to try to fix those drivers.
>
> It would certainly be a lot cleaner than this sort of code in the pcmcia
> core right now. Want me to send a patch which only allows for SA_SHIRQ
> and WARN_ON()'s for any driver not asking for shared IRQ ?
The question I'm stuck with is: When is it valid to ask for a non-shared
IRQ, and get back a shared one.
Drivers that know that they don't work well if they are called by the
"other" interrupt?
I happen to know (ISA) hardware that CANNOT share an interrupt: It
drives the IRQ line either high or low, and has a driver that will
overpower anything else on that line. This sounds like a good place to
me to have the driver request no sharing (*), and to prevent the IRQ
line drivers getting in eachothers way, it would be nice if the kernel
refused "early on" (i.e. before the stronger driver asserts: No IRQ
pending, and the weaker one keeps trying to assert: "YES, I have an
IRQ", and the weaker one slowly burning out).
Or am I talking nonsense again?
Roger.
(*) The driver knows to allow sharing when it's talking to the PCI
version of the card.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
On Llu, 2006-05-22 at 13:50 +0200, Rogier Wolff wrote:
> The question I'm stuck with is: When is it valid to ask for a non-shared
> IRQ, and get back a shared one.
I don't think it is. The problem is that some PCMCIA drivers currently
assume they can do so. The rules changed a bit over time on the hardware
side. The real fix is to squash those. I sent out a patch which warns
when a shared IRQ is given and an exclusive one requested so that it is
possible to pin down offenders.
> I happen to know (ISA) hardware that CANNOT share an interrupt: It
> drives the IRQ line either high or low, and has a driver that will
You happen to be wrong. Some ISA boards use the correct diodes and
pulldowns and can share an IRQ line although being edge triggered you
must take great care to get it right.
Alan
On Mon, 22 May 2006, Rogier Wolff wrote:
>
> The question I'm stuck with is: When is it valid to ask for a non-shared
> IRQ, and get back a shared one.
>
> Drivers that know that they don't work well if they are called by the
> "other" interrupt?
No.
For example, on certain 16-bit PCMCIA setups, the PCMCIA controller may
have just one interrupt. It may even have that interrupt exclusively, but
the point is, it has _one_. One interrupt shared for both doing not just
card interrupts, but also for PCMCIA CSC interrupts.
In that situation, once the card has been inserted (and powerup etc has
happened), the only interrupts you'll get is actually the interrupts for
the card. So everything is fine.
BUT A PCMCIA DRIVER STILL MUST NOT ASK FOR A NON-SHARED IRQ.
Because the irq will still be registered by the PCMCIA layer, and the
PCMCIA layer will check whether the interrupt was due to a CSC when the
card was removed, for example.
So there's basically never any valid reason to ask for a nonshared irq.
> I happen to know (ISA) hardware that CANNOT share an interrupt
Not necessarily true, since ISA cards have been known to be able to share
an interrupt with the proper pull-down resistors. It was even common for
serial cards.
Perhaps more importantly, not relevant for PCMCIA. There is no PCMCIA
hardware that cannot share an interrupt, for reasons outlines above.
There might be really bad hardware that doesn't even have an interrupt
status register so you can't tell if an interrupt happened from that card
or not, making it hard to write a driver that can handle "spurious"
interrupts (in the case of real sharing), but that sounds pretty damn
unlikely.
Linus
On Mon, May 22, 2006 at 01:10:04PM +0100, Alan Cox wrote:
> On Llu, 2006-05-22 at 13:50 +0200, Rogier Wolff wrote:
> > I happen to know (ISA) hardware that CANNOT share an interrupt: It
> > drives the IRQ line either high or low, and has a driver that will
>
> You happen to be wrong. Some ISA boards use the correct diodes and
> pulldowns and can share an IRQ line although being edge triggered you
> must take great care to get it right.
I feel like I'm repeating myself... I happen to know (ISA) hardware
that /cannot/ share an interrupt. It does /not/ use correct diodes and
pulldowns. I have equipped the driver with the knowledge that it
cannot share the interrupt.
Linus' sugesstion that as an intermediate measure request that
everybody explictly flag: shared is ok, or "NO WAY", sounds like a
plan. In the meanwhile the infrastructure may warn about that driver
so that some human thinks about it, and adds the right flag. Only after
a while, (when there is no longer anybody using the default) can we
change the default....
Alan and Linus know (ISA) hardware that /can/ share interrupts.
Fine. I know hardware that /cannot/ share interrupts. So, my driver
requesting an interrupt, and getting: "Can't allocate interrupt" is an
indication of a hardware configuration error. Or software (you've been
telling one of the drivers the wrong interrupt line). If you force
"shared mode", my driver will cope (it works just great on the PCI
version of the card, no problem). But will the hardware?
You guys maybe trying to fix very real problems in PCMCIA land, of
which I have very little knowledge. But changing what "not passing
SA_SHIRQ" means globlaly IMHO changes too much...
Rogier.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
On Llu, 2006-05-22 at 23:27 +0200, Rogier Wolff wrote:
> Fine. I know hardware that /cannot/ share interrupts. So, my driver
> requesting an interrupt, and getting: "Can't allocate interrupt" is an
> indication of a hardware configuration error. Or software (you've been
> telling one of the drivers the wrong interrupt line). If you force
> "shared mode", my driver will cope (it works just great on the PCI
> version of the card, no problem). But will the hardware?
Depends on the backplane
> You guys maybe trying to fix very real problems in PCMCIA land, of
> which I have very little knowledge. But changing what "not passing
> SA_SHIRQ" means globlaly IMHO changes too much...
PCMCIA doesn't need any big changes. The rules are simple. PCMCIA IRQs
today are shared, period. Because of the way the hardware works this
isn't an electrical issue. Drivers that ask for an exclusive PCMCIA IRQ
need to wake up and smell the coffee and get fixed.
Alan