Hi Linus!
> My tentative fix for this would be to make Linux never assign bus #1 or #2
> to a cardbus bridge, and start cardbus bridges at bus #8 or something like
> that. That way we'd still catch any strangeness in the pirq table, but we
> wouldn't get the message for this case which seems to
On Mon, 11 Dec 2000, Matthew Galgoci wrote:
>
> I do however still recieve a nasty message about a pirq table
> conflict, but it does not seem to affect the operation of the
> card.
It doesn't.
> The pirq conflict message seems a little harsh though, and perhaps
> unnecessary.
It is a bit
I goofed in the report below. I had switched to the i82365
pcmcia driver to see if it was affected by the pirq problems
the night before, and forgotten to switch back to the yenta_socket.
Switching back to the yenta_socket, plus andrewm's keventd patch
allowed the collection of cardbus pcmcia
Hello,
I tried this patch against test12-pre7, and all that I get is
"cs: socket c7604800 timed out during reset. Try increasing
setup_delay."
Performing cardctl reset yields the same message. I think that
cardctl reset takes away the possibility that increasing
setup_delay would actually
Hello,
I tried this patch against test12-pre7, and all that I get is
"cs: socket c7604800 timed out during reset. Try increasing
setup_delay."
Performing cardctl reset yields the same message. I think that
cardctl reset takes away the possibility that increasing
setup_delay would actually
I goofed in the report below. I had switched to the i82365
pcmcia driver to see if it was affected by the pirq problems
the night before, and forgotten to switch back to the yenta_socket.
Switching back to the yenta_socket, plus andrewm's keventd patch
allowed the collection of cardbus pcmcia
On Mon, 11 Dec 2000, Matthew Galgoci wrote:
I do however still recieve a nasty message about a pirq table
conflict, but it does not seem to affect the operation of the
card.
It doesn't.
The pirq conflict message seems a little harsh though, and perhaps
unnecessary.
It is a bit
Hi Linus!
My tentative fix for this would be to make Linux never assign bus #1 or #2
to a cardbus bridge, and start cardbus bridges at bus #8 or something like
that. That way we'd still catch any strangeness in the pirq table, but we
wouldn't get the message for this case which seems to be
Matthew Galgoci wrote:
>
> Hi Folks,
>
> I am running the 2.4.0test12pre7 kernel on my laptop computer, and
> I'm having some rather interesting problems.
>
> For the longest time, usb never worked on this machine. As of the
> happy patch that enabled bus mastering for usb controllers, it
>
Matthew Galgoci wrote:
Hi Folks,
I am running the 2.4.0test12pre7 kernel on my laptop computer, and
I'm having some rather interesting problems.
For the longest time, usb never worked on this machine. As of the
happy patch that enabled bus mastering for usb controllers, it
magically
10 matches
Mail list logo
