It's time for a week long party!
It works great, interrupts are even delivered to the tulip handler :)
Attached is the boot dmesg in case any aesthetic changes are desired.
Ted, please scratch off the NEC Versa LX PCMCIA entries as fixed, I assume this patch
will go in on the
next release.
ME
On Sat, 18 Nov 2000, David Ford wrote:
> Linus Torvalds wrote:
>
> > Can you (you've probably done this before, but anyway) enable DEBUG in
> > arch/i386/kernel/pci-i386.h? I wonder if the kernel for some strange
> > reason doesn't find your router, even though "dump_pirq" obviously does..
> >
Linus Torvalds wrote:
> Can you (you've probably done this before, but anyway) enable DEBUG in
> arch/i386/kernel/pci-i386.h? I wonder if the kernel for some strange
> reason doesn't find your router, even though "dump_pirq" obviously does..
> If there's something wrong with the checksumming for
On Sat, Nov 18, 2000 at 08:03:51AM -0800, Linus Torvalds wrote:
>
> Strange. Your interrupt router is a bog-standard PIIX4, we know how to
> route the thing, AND your device shows up:
>
> > # dump_pirq
> > Interrupt routing table found at address 0xf5a80:
> > Version 1.0, size 0x0080
> > Int
Hi!
> [EMAIL PROTECTED] said:
> > Umm.. Linus drivers dont appear to be SMP safe on unload
>
> AFAIK, no kernel threads are currently SMP safe on unload. However,
> the PCMCIA thread would be safe with the patch below, and we could fairly
> easily convert the others to use up_and_exit() onc
On Sat, 18 Nov 2000, David Ford wrote:
> Linus Torvalds wrote:
> [...]
>
> > If somebody still has a problem with the in-kernel stuff, speak up.
>
> The kernel's irq detection for the card sockets doesn't work for me. It's the NEC
> Versa LX story. The DH code also reports no IRQ found but
Linus Torvalds wrote:
[...]
> If somebody still has a problem with the in-kernel stuff, speak up.
The kernel's irq detection for the card sockets doesn't work for me. It's the NEC
Versa LX story. The DH code also reports no IRQ found but still figures out a
working IRQ (normally 3) and assigns
> 2. Even when I specify cs_irq=27, it resorts to polling:
>
> Intel PCIC probe:
> Intel i82365sl DF ISA-to-PCMCIA at port 0x8400 ofs 0x00, 2 sockets
> host opts [0]: none
> host opts [1]: none
> ISA irqs (default) = none! polling interval =
[EMAIL PROTECTED] said:
> It should be possible to do the same thing with a nice simple
> concentrated PCI probe, instead of having stuff quite as spread out as
> it used to be.
That's the plan.
> As to why it doesn't show any ISA interrupts, who knows... Some of
> the PCI PCMCIA bridges need
On Fri, 17 Nov 2000, Jeff Garzik wrote:
> >
> > 2. Even when I specify cs_irq=27, it resorts to polling:
> >
> > Intel PCIC probe:
> > Intel i82365sl DF ISA-to-PCMCIA at port 0x8400 ofs 0x00, 2 sockets
> > host opts [0]: none
> > host opts [1]: none
>
[EMAIL PROTECTED] said:
> For these two, it sounds to me like you need to be doing a PCI probe,
> and getting the irq and I/O port info from pci_dev. And calling
> pci_enable_device, which may or may not be a showstopper here...
Yep. The same code is already present in David Hinds' i82365.c,
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > If somebody still has a problem with the in-kernel stuff, speak up.
>
> I have an i82092AA evaluation board:
>
> 00:06.0 PCMCIA bridge: Intel Corporation 82092AA_0 (rev 02)
> Flags: slow devsel, IRQ 27
> I/O ports at 8400 [
> Who makes those pieces of crap? And who _buys_ them? I can understand it
> in embedded stuff simply because the chips are simpler and smaller, but in
> a laptop you should definitely try to avoid it.
These are mostly handhelds where the space/power issues get important. And as
to who makes them
On Fri, 17 Nov 2000, Alan Cox wrote:
> > Alan, Russell is talking about CardBus controllers (it's also PCMCIA, in
> > fact, these days it's the _only_ pcmcia in any machine made less than five
> > years ago).
>
> I have at least two machines here that are < 2 years old but disagree
> with you.
[EMAIL PROTECTED] said:
> If somebody still has a problem with the in-kernel stuff, speak up.
I have an i82092AA evaluation board:
00:06.0 PCMCIA bridge: Intel Corporation 82092AA_0 (rev 02)
Flags: slow devsel, IRQ 27
I/O ports at 8400 [size=4]
I have three problems:
1. I ha
Linus Torvalds writes:
> On Fri, 17 Nov 2000, Alan Cox wrote:
> Alan, Russell is talking about CardBus controllers (it's also PCMCIA, in
> fact, these days it's the _only_ pcmcia in any machine made less than five
> years ago).
Actually, I wasn't. I was referring to the embedded-type ARM devices
> Alan, Russell is talking about CardBus controllers (it's also PCMCIA, in
> fact, these days it's the _only_ pcmcia in any machine made less than five
> years ago).
I have at least two machines here that are < 2 years old but disagree
with you. Once is only months old.
> The patches to get i82
On Fri, 17 Nov 2000, Alan Cox wrote:
> > > regardless of what you are doing' since the modules from David Hinds and Linus
> > > pcmcia are not 100% binary compatible for all cases.
> >
> > However, deleting that code would render a significant number of ARM platforms
> > without PCMCIA support
On Fri, 17 Nov 2000, Russell King wrote:
> Alan Cox writes:
> > >From a practical point of view that currently means 'delete Linus tree pcmcia
> > regardless of what you are doing' since the modules from David Hinds and Linus
> > pcmcia are not 100% binary compatible for all cases.
>
> However
> > regardless of what you are doing' since the modules from David Hinds and Linus
> > pcmcia are not 100% binary compatible for all cases.
>
> However, deleting that code would render a significant number of ARM platforms
> without PCMCIA support, which would be real bad.
It would actually have
Alan Cox writes:
> >From a practical point of view that currently means 'delete Linus tree pcmcia
> regardless of what you are doing' since the modules from David Hinds and Linus
> pcmcia are not 100% binary compatible for all cases.
However, deleting that code would render a significant number o
On Thu, Nov 16, 2000 at 01:26:36PM -0800, [EMAIL PROTECTED] wrote:
>
> > Ted, is this true? It would be wonderfull to be able to use i82365 without
> > need for pcmcia_cs...
>
> > I think in-kernel pcmcia crashing even on simple things *is* critical bug.
It wasn't a critical bug, in the sense t
Date: Sat, 1 Jan 2000 02:54:52 +
From: Pavel Machek <[EMAIL PROTECTED]>
Cc: David Woodhouse <[EMAIL PROTECTED]>, David Hinds <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
> It's purposefully not on Ted's criti
Hi!
> > Cool. Linus, please could you apply this patch. If the fact that i82365
> > and tcic are broken in 2.4 isn't on Ted's critical list, then I think it
> > probably ought to have been - and this should fix it.
>
> It's purposefully not on Ted's critical list, the official line is "use
> pcm
On Thu, 16 Nov 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Umm.. Linus drivers dont appear to be SMP safe on unload
>
> AFAIK, no kernel threads are currently SMP safe on unload. However,
> the PCMCIA thread would be safe with the patch below, and we could fairly
> easily c
> > pcmcia are not 100% binary compatible for all cases.
>
> What cases are these?
>
> David's been pretty good about putting 2.4.x support into pcmcia_cs
> package...
Build a tree with the kernel pcmcia cs, build the pcmcia modules from David
Hinds on the same tree. Attempt to randomly load Da
Alan Cox wrote:
> the modules from David Hinds and Linus
> pcmcia are not 100% binary compatible for all cases.
What cases are these?
David's been pretty good about putting 2.4.x support into pcmcia_cs
package...
--
Jeff Garzik |
Building 1024 | The chief enemy of creativ
> It's purposefully not on Ted's critical list, the official line is "use
> pcmcia_cs external package" if you need i82365 or tcic instead of yenta
> AFAIK. However... fixing things and being able to support all pcmcia
> and cardbus adapters would be wonderful.
>From a practical point of view th
[EMAIL PROTECTED] said:
> Umm.. Linus drivers dont appear to be SMP safe on unload
AFAIK, no kernel threads are currently SMP safe on unload. However,
the PCMCIA thread would be safe with the patch below, and we could fairly
easily convert the others to use up_and_exit() once it's available
> It's the socket drivers which _aren't_ in the kernel source which are most
> likely to exhibit this problem. Anything in the kernel tree was probably
> converted by Linus, and hence done right. As there are so few socket drivers
Umm.. Linus drivers dont appear to be SMP safe on unload
-
To un
> > up_and_exit() would do it. Or preferably passing the address of the
> > semaphore as an extra argument to kernel_thread() in the first place.
>
> Any solution which involves a function being called from a kernel
> thread, and/or passing another arg to a kernel thread, is a non-starter
> ...
> it looks like the loop can be simplified to
>
> while (1) {
> mb();
> active = tq_pcmcia;
> if (!active)
> interruptible_sleep_on(&event_thread_wq);
> if (signal_pending(current)
> break;
> run_task_queue(&tq_pcmcia);
> }
Not if you wan
David Woodhouse writes:
> If we don't specify CLONE_FS | CLONE_FILES | CLONE_SIGHAND then new ones
> get allocated just for us to free them again immediately. If we clone them,
> then we just increase and decrease the use counts of the parent's ones. The
> latter is slightly more efficient, and
On Mon, 13 Nov 2000, Jeff Garzik wrote:
> It's purposefully not on Ted's critical list, the official line is "use
> pcmcia_cs external package" if you need i82365 or tcic instead of yenta
> AFAIK. However... fixing things and being able to support all pcmcia
> and cardbus adapters would be wonde
David Woodhouse wrote:
>
> On Mon, 13 Nov 2000, David Hinds wrote:
>
> > The i82365 and tcic drivers in the 2.4 tree have not been converted to
> > use the thread stuff; as far as I know, the yenta driver is the only
> > socket driver that works at all in 2.4.
> >
> > On Mon, Nov 13, 2000 at 09:
On Mon, 13 Nov 2000, David Hinds wrote:
> The i82365 and tcic drivers in the 2.4 tree have not been converted to
> use the thread stuff; as far as I know, the yenta driver is the only
> socket driver that works at all in 2.4.
>
> On Mon, Nov 13, 2000 at 09:52:30PM +, David Woodhouse wrote:
>
On Mon, Nov 13, 2000 at 03:42:34PM +, David Woodhouse wrote:
> It's the socket drivers which _aren't_ in the kernel source which are most
> likely to exhibit this problem. Anything in the kernel tree was probably
> converted by Linus, and hence done right. As there are so few socket drivers
>
[EMAIL PROTECTED] said:
> Thanks for all the explanation, I think I now understand all the
> stuff your kernel thread is doing. Your solution sounds like a decent
> solution for the problem described. I have not looked at the socket
> driver code observe parse_events() usage, so I cannot say w
David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > In any case, we -really- need a wait_for_kernel_thread_to_die()
> > function.
>
> up_and_exit() would do it. Or preferably passing the address of the
> semaphore as an extra argument to kernel_thread() in the first place.
Any solution which in
[EMAIL PROTECTED] said:
> Doh, totally forgot about that. Will this work:
> save_current = current;
> current = find_task_by_pid(1);
> waitpid(...);
> current = save_current;
Changing the thread's parent to current->pid would be better than modifying
current. Still suck
David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > Racy. Use waitpid() in the thread killer instead.
>
> Doesn't waitpid() require the thread we're waiting for to be child of the
> rmmod process? I suppose we could arrange that, but it's not particularly
> clean.
Doh, totally forgot about tha
[EMAIL PROTECTED] said:
> Replace most if not all of this crap w/ daemonize()
OK.
> it looks like the loop can be simplified to
Nope. sleep_on is bad. We have to set_current_state(TASK_INTERRUPTIBLE)
before checking tq_pcmcia.
> while (1) {
> mb();
> active = tq_pcmcia;
David Woodhouse wrote:
> I'm not sure why we changed from the existing state machine / timer setup to
> sleeping in the PCMCIA parse_events() routine,
I don't remember the exact reason, but Linus changed it for yenta...
maybe because CardBus Watcher always called the state machine from user
co
Argh. I give up - I've added a rewrite rule to my MTA because I'm too
stupid to remember that the list moved.
--
dwmw2
--- Forwarded Message
From: David Woodhouse <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [PATCH] pcmcia event thread.
Date:
44 matches
Mail list logo
