In message [EMAIL PROTECTED] Nick Hibma writes:
: 'It' in the second case refers to the PCI irq allocation code I presume?
: An irq that is 0 or 255 is invalid and should not be allocated to a PCI
: device. But speaking about rev1.32, how would you assign an interrupt as
: is stated in the log
In message [EMAIL PROTECTED] [EMAIL PROTECTED]
writes:
: The problem is not that the PCI device is not initialised, but that the
: device is assigned a bogus irq (0/255) by the BIOS.
That's not true. They are the default values by the chip. The BIOS
likely isn't initializing the chip at all.
Could be, and I certainly don't know much about this code. But
it seems like the driver is being given reason to assume it has a
working device when it doesn't really have one. I assume the device
is unusable without its interrupt, so shouldn't it fail at probe or
attach time?
Yes,
Could be, and I certainly don't know much about this code. But
it seems like the driver is being given reason to assume it has a
working device when it doesn't really have one. I assume the device
is unusable without its interrupt, so shouldn't it fail at probe or
attach time?
The bottom line is this; in your driver, ask for the resources that you
need. If you don't get them, you fail. The PCI bus infrastructure is
being worked on to improve your chances of getting these resources; it's
not something that a driver writer should be worrying about per se.
And
The reason it is failing is that the assigned IRQ is 0 or 255. If I
can't assume that that setup is done, I might as well start implementing
PCI resource allocation, because that is what is missing here.
The problem is not that the PCI device is not initialised, but that the
device is assigned
In article [EMAIL PROTECTED],
Warner Losh [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED] John Polstra writes:
: When booting GENERIC, the kernel probes most (all?) of the devices and
: gets to the point where it says, Waiting 15 seconds for SCSI devices
: to settle. At that point it
I have some more information about this now. There is a BIOS knob
USB IRQ which can be set to Disabled or Enabled. If it is Disabled,
the hangs occur as I described. If it is Enabled, everything works
fine. I think it ought to boot in either case (-4.x does). I am not
actually using the USB
I have some more information about this now. There is a BIOS knob
USB IRQ which can be set to Disabled or Enabled. If it is Disabled,
the hangs occur as I described. If it is Enabled, everything works
fine. I think it ought to boot in either case (-4.x does). I am not
actually using the
In article [EMAIL PROTECTED],
John Polstra [EMAIL PROTECTED] wrote:
I have a strong suspicion that backing out sys/pci/uhci_pci.c
revision 1.32 will make this problem go away. I'll test that next.
Yep, I reverted that file to revision 1.31 and the hangs went away
even with the USB IRQ
In article [EMAIL PROTECTED],
Mike Smith [EMAIL PROTECTED] wrote:
You're not tying up an interrupt; PCI interrupts are shared. With the
new PCI code, even if you turn it off, we'll just turn it right back on
again. 8)
But if IRQ 5 is assigned to the uhci device, then it's not available
In article [EMAIL PROTECTED],
Mike Smith [EMAIL PROTECTED] wrote:
You're not tying up an interrupt; PCI interrupts are shared. With the
new PCI code, even if you turn it off, we'll just turn it right back on
again. 8)
But if IRQ 5 is assigned to the uhci device, then it's not
The GENERIC kernel in -current hangs on my ASUS P2B-S system, but my
custom kernel is OK. By trial and error I determined that removing
the uhci device from the GENERIC kernel makes it work. I don't know
how long this has been broken, because I don't normally use GENERIC.
I do know it was
In message [EMAIL PROTECTED] John Polstra writes:
: When booting GENERIC, the kernel probes most (all?) of the devices and
: gets to the point where it says, Waiting 15 seconds for SCSI devices
: to settle. At that point it hangs solid. Keystrokes aren't echoed;
: scroll-lock doesn't work;
14 matches
Mail list logo
