> > > I don't use modules. As a result, I haven't been all that interested
> > > in making them work - at worst I will just not allow the "m"odule answer
> > > in configure as nobody seems to be interested in fixing this.
> >
> > I can tell, but the way I've always seen it, if you don't need it to boot,
> > you don't need it in the kernel.
>
> Well, I personally think I need it to boot - not the way I have things set
> up right now, but that's partly because ofit not being historically
> possible.
>
> There are some important devices behind the cardbus bridge - CD-ROM's,
> network, stuff like that that can all be rather important for booting.
I'm not disagreeing with you on this. The machine that I have doesn't
require cardbus support for cdrom access.
> > > PCCARD really has two differentkinds of interrupts: the PCI interrupts and
> > > the legacy ISA interrupts. The legacy ISA interrupts are dynamic, the PCI
> > > interrupts are wired.
> >
> > So are you saying that my cardbus controller is hard wired to irq's 5 and
> > 10 which the bios has no control over?
>
> I'm saying that your _PCI_ interrupts are hardwired (*). Which is not to
> say that the cardbus controller doesn't have other interrupts. The ISA
> interrupts are usually handled with a generic serial protocol to the
> southbridge, and have no hard routing at all.
>
> Anyway, back to the actual practical problem at hand:
>
> What may be problematic is that when Linux changes the interrupt routing
> when enabling a new PCI device, the kernel _tries_ to avoid re-using an
> interrupt that is used by another PCI card. The fact that you get the same
> interrupt for both sound and CardBus can mean either:
>
> - they really are wired to the same physical chip (or firmware setup is
> such that they end up virtually wired that way anyway)
>
> OR
>
> - the Linux southbridge PCI interrupt routing code isn't trying hard
> enough.
>
> The latter is definitely a possible problem. Linux does know how to route
> various interrupts in the southbridge (at least to a limited degree), but
> that code may not be quite good enough in trying to distribute interrupts
> well.
One time, with cardbus being a module, I loaded the maestro card and after
it loaded, yenta decided to allocate irq10 for both slots.
Completely lost me on what a southbridge is. I looked over the information,
but didn't explain it (maybe I really don't need to know =)
> Even if that could be improved upon, however, the fact remains that if the
> sound driver has problems with shared PCI interrupts, then that is a bug
> in itself. As I've tried to explain above, it is not guaranteed that it is
> at all possible to avoid sharing the interrupt, and a good driver should
> not be unhappy about the sharing.
This happened once (pci bios assigned it this way) on my pII box, scsi card
and one of my nics got the same irq. I didn't experience any problems, but
after I disabled things I wasn't going to use (ide) I had 1 irq free. When
we get the irq for yenta, is it assigned via linux or via bios?
> [ more asides: sharing a PCI interrupt results in extra "spurious"
> interrupts as far as a driver is concerned: the sound driver sees not
> only its own interrupts, but also those of the other devices that share
> the same interrupt line. It's usually very easy to handle spurious
> interrupts: just ignore them if there doesn't seem to be anything to do.
>
> But sometimes drivers are set up in a way that they will ignore status
> reports etc, and do something unconditionally just because an interrupt
> happened - even if that interrupt was not generated by the device that
> the driver is there for.. ]
Actually, I don't believe I saw any.
> > Well if I decide to insert a pcmcia card, does this mean it will use that
> > "yenta irq" or will it assign a new one?
>
> That depends on the card. A 32-bit cardbus card will always use the PCI
> interrupt (the "yenta interrupt"). A 16-bit PCMCIA card will use a legacy
> ISA interrupt that is assigned at that time (ISA interrupts cannot be
> shared).
Done it once on a machine that had a dead builtin modem so I used it's irq.
Never once had a problem since it was never used.
> Finally, regardless of the card the yenta driver itself will always use
> the PCI interrupt (if available) for card status change information (ie
> for when cards are inserted, removed, lose power etc etc).
What's the difference between cardwatcher(kernel) and the cardmgr(user)?
> Note that sometimes a PCI interrupt is not available at all, at which
> point the yenta driver falls back on trying to use a legacy interrupt even
> for 32-bit CardBus cards (and will not use a CSC interrupt at all, instead
> just using a timeout to check whether cards have been added or removed).
> This =usually= works.
What is CSC?
> Actually, as far as I can tell, on the laptop side Sony makes some of the
> best laptops available. I'm biased, because I like my laptops _small_, and
> the Japanese laptop vendors tend to be more aggressive in the size
> department (and many of the japanese models never make it to the US).
Actually, my versa sx is smaller than most. I believe the panel is the same
thickness as the sony, but the system is 1" thick. I guess that means
sony's are easier broken when dropped eh? (BTW, I did drop the nec once,
everything still works just fine)
> The problem with the Sony VAIO (and many other thin-and-lights) is that
> because it tries to be so small, it tends to rely much more on cardbus
> than a bigger laptop that has a CD-ROM and network built in. That meant
> that when my new 100Mbps CardBus card did not work for me, I ended up
> deciding that I really have to fix it up ;)
How is the cdrom connected to the sony laptop? pc card? It doesn't have a
builtin cdrom does it?
> > Well, I must say the system worked better under 2.2.14 with david hinds
> > pcmcia (3.1.11 I believe). My nic is a 3com 3cxfe575ct (I hate these
> > numbers now).
>
> Ok. I'll probably buy one of those cards, because it's fairly common too.
> It may be that the driver just makes tons of assumptions that used to be
> true... What are the console spam messages?
How about the pc card 574 card? We have one at work which was purchased by
mistake (but being used)
Mar 11 09:31:31 krillin kernel: eth0: Too much work in interrupt, status e003.
Mar 11 09:31:31 krillin kernel: eth0: Host error, FIFO diagnostic register 0000.
Mar 11 09:31:31 krillin last message repeated 32 times
Those errors. I've always had these, it seems to work better on this card,
we bought a new laptop and nic at work so I swapped the 10/100 that I had
for the one we bought. They are the same card except the one I have is the
one above, the other was a 3cxfe575bt (note the 'b'). The 'b' card gave me
the error more. I did find out that the wire had something to do with it as
well. I brought home a few cables that had rj45's on it just so I could use
the wire for something else, but I used it on the laptop. on the 3c589
card, no problems ever. With the 10/100, problems. I used the wire that
came with the 10/100 card, problem went away (kernel 2.3.34 I believe was
more stable than pcmcia-modules). No, I haven't tried the 'b' card in
2.3.51 (no longer have it)
> For example, one of the whole points of the new CardBus code is that a
> cardbus card (like the 3c575) is supposed to look like a normal PCI card
> that just supports hot-plug. This is what we did to the tulip driver:
> instead of having one "tulip_cb.c" and one "tulip.c" - one for cardbus
> devices and one for "regular" Tulip PCI cards, 2.3.x has one unified
> driver that doesn't even care whether the card is in a PCI slot or behind
> a CardBus bridge.
I *DO* like this idea. I've looked briefly at the 3c575_cb.c and noticed it
said it was mostly the 3c59x.c
> The same is not true of the 3c575 driver. There _should_ be just one
> vortex driver (drivers/net/3c59x.c) that handles all of this, and some of
> your problems may simply be due to old drivers.. The cardbus version of
> the driver doesn't use the new PCI DMA interfaces, for example.
Oh, by the way, the 575 driver can't be compiled in, I tried and it told me
to go away <g>
> This is something where Jeff Garzik has been very good at making these
> cleanups. Maybe I should buy him a 3c575 card too ;)
I guess you have more $$$ than I do =)
> > The biggest problem I have with this thing is why it's always grabbing IRQs
> > that are already inuse as opposed to ones that are available. I currently
> > have USB disabled for 2 reasons, last time I tried the driver, it just
> > didn't work (timeout errors), and 2, I don't have any usb devices. So I
> > have irq 9 and irq 11 free. Maybe you could have something like
> > yentairqlist= and list irqs that I want to use there. I'm not sure how
> > windoze handles irq allocation, but I'll find out when I get to work monday.
>
> Having a "yentairqlist=" thing is probably a good idea regardless. I'd be
> even happier if all the drivers happily shared interrupts, though.
As long as it works, I'm fine with it, I've just had the preference not to
have multiple devices in use that share the same irq (PC hardware if you
know what I mean)
> I agree that right now not all drivers do, but both ACPI and USB tend to
> really require it because once they get enabled (something that is very
> useful on a laptop), as you mention the free irq's tend to be fairly hard
> to find. Which means that any driver that doesn't gracefully handle the
> shared irq case is going to be a problem eventually..
Why does acpi require an IRQ? I haven't used it since it uses an irq.
Speaking of IRQs, what's the deal on machines (I have a supermicro p6dbe)
that have PCI irq's >= 16. This would be nice if it would work on my
laptop. My tyan s1832dl doesn't support those higher irq's (Wish it did)
-- Lab tests show that use of micro$oft causes cancer in lab animals- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:20 EST