| 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
| ||
|
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/
Powered by blists - more mailing lists