As M. Warner Losh wrote:
> I'd like to know what causes this, if possible.
One more datapoint, don't know whether it's related or not.
I've got a cardbus ethernet card around (a Xircom one), which it is
normally used in a different machine. When I insert it into the
TP600, I get:
cardbus1: Una
As M. Warner Losh wrote:
> : > Does this happen on a cold boot or a warm boot?
> :
> : That doesn't matter.
> Bummer. I'll have to look at the original data a little more
> closely. I'd like to know what causes this, if possible.
OK, I could insert any printf you'd like me to. I could perhap
In message: <20100320134517.go52...@uriah.heep.sax.de>
Joerg Wunsch writes:
: As M. Warner Losh wrote:
:
: > : I guess vgapci0 doesn't really use interrupts, so this leaves cbb0/1
: > : and uhci0 sharing an interrupt. Apparently, the interrupt storm at
: > : cbb gets detected correct
As M. Warner Losh wrote:
> : I guess vgapci0 doesn't really use interrupts, so this leaves cbb0/1
> : and uhci0 sharing an interrupt. Apparently, the interrupt storm at
> : cbb gets detected correctly as long as at least another device
> : installs an interrupt handler on irq 11.
> Does this hap
In message: <20100320115528.ga50...@uriah.heep.sax.de>
Joerg Wunsch writes:
: As Joerg Wunsch wrote:
:
: > OK, at kernel #11 :), I can now say it's the USB subsystem. Just
: > leaving "device usb" (and also "device uhci") in makes it work.
: >
: > So the question appears to be why k
As Joerg Wunsch wrote:
> OK, at kernel #11 :), I can now say it's the USB subsystem. Just
> leaving "device usb" (and also "device uhci") in makes it work.
>
> So the question appears to be why keeping the USB driver in makes the
> interrupt storm detection work...
Maybe that's the relationship
As John Baldwin wrote:
> Sounds like the process of removing things prevented the interrupt
> storm from being throttled somehow, and that ejecting the card
> caused the interrupt storm to finally stop at which point the card
> was probed. I would talk to Warner (imp@) about trying to fix the
> i
As M. Warner Losh wrote:
> Yes. Do other cards cause this same problem?
Nope, but the xe card is the only one I've got that tries to use the
memory space. The remaining cards use the ep(4) driver which only
uses IO space access.
> The cbb1: Bad Vcc is a
> big clue something is going wrong with
In message: <201003190837.48346@freebsd.org>
John Baldwin writes:
: On Thursday 18 March 2010 3:27:58 pm Joerg Wunsch wrote:
: > I'm running into a strange problem with 8-current (or 8.0-RELEASE) on
: > an elderly Thinkpad 600E.
: >
: > As long as I'm using the GENERIC kernel, an
On Thursday 18 March 2010 3:27:58 pm Joerg Wunsch wrote:
> I'm running into a strange problem with 8-current (or 8.0-RELEASE) on
> an elderly Thinkpad 600E.
>
> As long as I'm using the GENERIC kernel, an Intel Etherexpress PC card
> works as expected:
>
> interrupt storm detected on "irq11:"; th
Lowell Gilbert wrote:
> Try "device cbb". Also make sure you have pccard. I don't think
> you'll need cardbus with that setup, but I'm not certain.
cbb, pccard, and also cardbus are part of the kernel config. I
originally left out xe on purpose (so I could e.g. recompile it while
the machine
Joerg Wunsch writes:
> I'm running into a strange problem with 8-current (or 8.0-RELEASE) on
> an elderly Thinkpad 600E.
>
> As long as I'm using the GENERIC kernel, an Intel Etherexpress PC card
> works as expected:
>
> interrupt storm detected on "irq11:"; throttling interrupt source
> xe0: at
I'm running into a strange problem with 8-current (or 8.0-RELEASE) on
an elderly Thinkpad 600E.
As long as I'm using the GENERIC kernel, an Intel Etherexpress PC card
works as expected:
interrupt storm detected on "irq11:"; throttling interrupt source
xe0: at port
0x100-0x10f iomem 0x2000-0
13 matches
Mail list logo
