lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 01 Feb 2010 15:51:51 -0800
From:	"Justin P. Mattock" <justinmattock@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	Dan Carpenter <error27@...il.com>,
	linux1394-devel@...ts.sourceforge.net,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>
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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ