> > 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, it should. It's not bright enough to do that yet. '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 message for rev1.32? Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
- GENERIC kernel hangs at boot (uhci-related) John Polstra
- Re: GENERIC kernel hangs at boot (uhci-related) Warner Losh
- Re: GENERIC kernel hangs at boot (uhci-related) John Polstra
- Re: GENERIC kernel hangs at boot (uhci-related) John Polstra
- Re: GENERIC kernel hangs at boot (uhci-related) Mike Smith
- Re: GENERIC kernel hangs at boot (uhci-relat... John Polstra
- Re: GENERIC kernel hangs at boot (uhci-... Mike Smith
- Re: GENERIC kernel hangs at boot (u... Nick Hibma
- Re: GENERIC kernel hangs at boo... Mike Smith
- Re: GENERIC kernel hangs at boo... Mike Smith
- Re: GENERIC kernel hangs at boo... n_hibma
- Re: GENERIC kernel hangs at boo... Warner Losh
- Re: GENERIC kernel hangs at boo... Warner Losh
- Re: GENERIC kernel hangs at boot (uhci-related) John Polstra