Messages in this thread | | | Date | Mon, 01 Feb 2010 15:51:51 -0800 | From | "Justin P. Mattock" <> | Subject | Re: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early exception 08 rip 246:10 error ffffffff810251b5 cr2 0) |
| |
On 02/01/10 14:27, Stefan Richter wrote: > Justin P. Mattock wrote: >> (as for yesterdays 0xffffffffffffffff(just experimenting)Google gives me >> no info on the differences between 8f's to 16f's, I was under the >> impression that it's x86_32 and x86_64 for the pci address). > > As Dan noted, > (class == 0xffffffff || 0xffffffffffffffff) > is always true because it is logically the same as > (class == whatever) || true > > If you really meant > class == 0xffffffff || class == 0xffffffffffffffff
yeah that's what I was going for(just to see).
> then the latter half will never become true because class is declared as > u32 and got its value from read_pci_config() which also returns u32. >
That's what I was afraid of. I'm guessing there probably would be a lot of things to change for(if this correct) u64.
> BTW, whether a PCI device is capable of accessing 32 bit bus addresses > or also 64 bit bus addresses depends on the device, not on the CPU. > Originally, PCI only had a 32 bit addressing model. OHCI 1394 1.0/1.1 > implementations only deal with 32 bit local bus addresses. > I haven't even looked at what the device was capable of doing.
> The 'class' however is not an address but merely a register value with > 24 bits width. (Defined in the PCI Local Bus spec which is not freely > available, cited in OHCI 1394 annex A.3.) This register is read as a 32 > bits wide register from which the excess byte is later discarded. If > all bits read are 1, the bus:slot:function is not actually populated.
So(correct me if I'm wrong), I'm generating a 64 bit register and the kernel is looking for a 32 bit register causing the crash.
Justin P. Mattock
| |