linux-kernel - Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47E557D5.9020604@s5r6.in-berlin.de>
Date:	Sat, 22 Mar 2008 20:02:45 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Thomas Meyer <thomas@...3r.de>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>
Subject: Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported
 regressions from 2.6.24)

I wrote:
> Thomas Meyer wrote:
>> Stefan Richter schrieb:
>>>   - Is the "WARNING: at arch/x86/mm/ioremap.c" still there?
>> No. I couldn't reproduce this warning, yet.
>>
>>>   - Can you reproduce it without the atheros driver?
>> Yes.
>>
>> See http://bugzilla.kernel.org/show_bug.cgi?id=10080.
> 
> Thanks.  Summary from today's bugzilla comments:
> No ioremap warning, but MMIO reads still give bogus values and let 
> ohci1394 fail.  ohci1394 still got the MMIO region 0x1'0000'0000 - 
> 0x1'0000'07ff, FWIW.  The length of the region is correct, but its 
> contents bogus.

Can an MMIO region reside above 0x1'0000'0000 on x86-32? ... Apparently 
yes, if CONFIG_RESOURCES_64BIT=y.

 From Thomas' dmesg:
http://bugzilla.kernel.org/attachment.cgi?id=15397

BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000ede00 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 000000007f0c8000 (usable)
  BIOS-e820: 000000007f0c8000 - 000000007f2c9000 (ACPI NVS)
  BIOS-e820: 000000007f2c9000 - 000000007feb9000 (ACPI data)
  BIOS-e820: 000000007feb9000 - 000000007feef000 (ACPI NVS)
  BIOS-e820: 000000007feef000 - 000000007ff00000 (ACPI data)
  BIOS-e820: 000000007ff00000 - 0000000080000000 (reserved)
  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
  BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved)
  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
  BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
1136MB HIGHMEM available.
896MB LOWMEM available.
...
ACPI: RSDP 000FE020, 0024 (r2 APPLE )
ACPI: XSDT 7FEFD120, 0074 (r1 APPLE   Apple00       55       1000013)
ACPI: FACP 7FEFB000, 00F4 (r3 APPLE   Apple00       55 Loki       5F)
ACPI: DSDT 7FEF0000, 48C0 (r1 APPLE  MacBookP    10001 INTL 20050309)

 From Thomas' .config:
http://bugzilla.kernel.org/attachment.cgi?id=15396
CONFIG_RESOURCES_64BIT=y

I have a Mac mini but run x86-64 on it.  However, I've got another 
i945GM based PC with x86-32 and three OHCI-1394 controllers in it.
I always had CONFIG_RESOURCES_64BIT switched off.  I shall try 
CONFIG_RESOURCES_64BIT=y on that PC.

Thomas, did you use CONFIG_RESOURCES_64BIT=y already under Linux 2.6.24?

All, is there anything special that drivers need to take care of for 
CONFIG_RESOURCES_64BIT=y?

We use resource_size_t ohci_base to request the MMIO region in 
drivers/ieee1394/ohci1394.c::ohci1394_pci_probe().  And we use struct 
ti_ohci::void __iomem *registers to store the MMIO base we get from 
ioremap, and readl(ohci->registers + (int)offset) and writel((u32)data, 
ohci->registers + (int)offset) to peek and poke in them; see 
drivers/ieee1394/ohci1394.h.
-- 
Stefan Richter
-=====-==--- --== =-==-
http://arcgraph.de/sr/
--
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/