All this discussion is well and good, but I suspect there is a driver setup
problem where the interrupt isn't being handled properly. Please retest with
the latest version of skge driver (I just pushed patches to netdev about 2min
ago).
One patch changes to disable IRQ's from device for packets un
On Wed, Mar 14, 2007 at 10:46:47PM +0100, Andi Kleen wrote:
> Tejun Heo <[EMAIL PROTECTED]> writes:
> >
> > Let's assume there's a device which shares its INTX IRQ line with
> > another device and the other one is already initialized. During boot,
> > due to BIOS's fault, bad hardware design or s
> Do you mean between disabling IRQ mechanisms and enabling PCI device in
> pcim_prepare_device()?
Yes.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 15, 2007 at 11:37:20AM +0900, Tejun Heo wrote:
...
> Also, the current implementation doesn't have any arch independent part.
I thnk you meant "arch dependent" here.
> It's wholly contained in arch independent PCI layer, but it might be
> beneficial to have arch dependent hooks (IR
[cc'ing Andi, Hi!]
Hello,
Russell King wrote:
> On Wed, Mar 14, 2007 at 06:34:11PM -0400, Jeff Garzik wrote:
>> Russell King wrote:
>>> pci_enable_device() doesn't deal with this; in most PCI setups I've
>>> seen, there is no control at PCI level over whether a device generates
>>> an interrupt o
Andi Kleen wrote:
Tejun Heo <[EMAIL PROTECTED]> writes:
Let's assume there's a device which shares its INTX IRQ line with
another device and the other one is already initialized. During boot,
due to BIOS's fault, bad hardware design or sheer bad luck, the device
has got a pending IRQ.
This se
Stephen Hemminger wrote:
The problem is the BIOS is busted on these machines. How much effort
do we want to put into dealing with systems with broken BIOS?
I would rather have the root cause fixed than creating a bandaid that
has to be maintained for all the other architectures and platforms.
F
Russell King wrote:
In any case, relying on such a new control bit to implement this kind
of functionality would result in a very hit and miss result; Linux
How does Tejun's patch or thesis rely on this new control bit? He
explicitly mentions DISABLE_INTX variability...
Jeff
-
To
On Wed, Mar 14, 2007 at 06:34:11PM -0400, Jeff Garzik wrote:
> Russell King wrote:
> >pci_enable_device() doesn't deal with this; in most PCI setups I've
> >seen, there is no control at PCI level over whether a device generates
> >an interrupt on the bus. Certainly the memory and io command enable
Russell King wrote:
pci_enable_device() doesn't deal with this; in most PCI setups I've
seen, there is no control at PCI level over whether a device generates
an interrupt on the bus. Certainly the memory and io command enables
PCI grew an interrupt enable while you weren't looking:
PCI_COMMA
On Thu, Mar 15, 2007 at 12:23:02AM +0900, Tejun Heo wrote:
> The problem is that a PCI device can be in any arbitrary when it gets
> enabled and the device has to be enabled for its driver to
> initialize/reset it. The most common case this causes headache is as
> follows.
>
> Let's assume there'
Tejun Heo <[EMAIL PROTECTED]> writes:
>
> Let's assume there's a device which shares its INTX IRQ line with
> another device and the other one is already initialized. During boot,
> due to BIOS's fault, bad hardware design or sheer bad luck, the device
> has got a pending IRQ.
This seems to be a
On Thu, 15 Mar 2007 00:23:02 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello, all.
>
> This patch started off from the following thread.
>
> http://thread.gmane.org/gmane.linux.ide/16899
>
> The problem is that a PCI device can be in any arbitrary when it gets
> enabled and the device has
On Thu, 15 Mar 2007, Tejun Heo wrote:
> Hello, all.
>
> This patch started off from the following thread.
>
> http://thread.gmane.org/gmane.linux.ide/16899
>
> The problem is that a PCI device can be in any arbitrary when it gets
> enabled and the device has to be enabled for its driver to
>
Hello, all.
This patch started off from the following thread.
http://thread.gmane.org/gmane.linux.ide/16899
The problem is that a PCI device can be in any arbitrary when it gets
enabled and the device has to be enabled for its driver to
initialize/reset it. The most common case this causes he
15 matches
Mail list logo
