This issue looks similar to this: http://www.coreboot.org/pipermail/coreboot/2009-February/044672.html
Any ideas? cheers, Pádraig.
# /tmp/flashrom -V -c W25x80 flashrom v0.9.2-r1182 on Linux 2.6.32.10-90.fc12.i686 (i686), built with libpci 2.2.4, GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2), little endian flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OS timer resolution is 5 usecs, 716M loops per second, 10 myus = 10 us, 100 myus = 341 us, 1000 myus = 1126 us, 10000 myus = 9809 us, 20 myus = 20 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: " " DMI string system-product-name: " " DMI string system-version: " " DMI string baseboard-manufacturer: " " DMI string baseboard-product-name: "945GSE" DMI string baseboard-version: " " DMI string chassis-type: "Desktop" Found chipset "Intel ICH7M", enabling flash write... chipset PCI ID is 8086:27b9, 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x4 0x7fffffff/0x7fffffff FWH IDSEL: 0x5 0x7fffffff/0x7fffffff FWH IDSEL: 0x6 0x7fffffff/0x7fffffff FWH IDSEL: 0x7 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode disabled Maximum FWH chip size: 0x100000 bytes BIOS Lock Enable: enabled, BIOS Write Enable: enabled, BIOS_CNTL is 0x3
Root Complex Register Block address = 0xfed1c000 GCS = 0xc20445: BIOS Interface Lock-Down: enabled, BOOT BIOS Straps: 0x1 (SPI) Top Swap : not enabled SPIBAR = 0xfed1c000 + 0x3020 0x00: 0x0008 (SPIS) 0x02: 0x4320 (SPIC) 0x04: 0x00000000 (SPIA) 0x08: 0x001430ef (SPID0) 0x0c: 0x00000000 (SPID0+4) 0x10: 0x00000000 (SPID1) 0x14: 0x00000000 (SPID1+4) 0x18: 0x00000000 (SPID2) 0x1c: 0x00000000 (SPID2+4) 0x20: 0x00000000 (SPID3) 0x24: 0x00000000 (SPID3+4) 0x28: 0x00000000 (SPID4) 0x2c: 0x00000000 (SPID4+4) 0x30: 0x00000000 (SPID5) 0x34: 0x00000000 (SPID5+4) 0x38: 0x00000000 (SPID6) 0x3c: 0x00000000 (SPID6+4) 0x40: 0x00000000 (SPID7) 0x44: 0x00000000 (SPID7+4) 0x50: 0x00000000 (BBAR) 0x54: 0x5006 (PREOP) 0x56: 0x463b (OPTYPE) 0x58: 0x05d80302 (OPMENU) 0x5c: 0xc79f0190 (OPMENU+4) 0x60: 0x00000000 (PBR0) 0x64: 0x00000000 (PBR1) 0x68: 0x00000000 (PBR2) 0x6c: 0x00000000 (PBR3)
Programming OPCODES... program_opcodes: preop=5006 optype=463b opmenu=05d80302c79f0190 done SPI Read Configuration: prefetching disabled, caching enabled, OK. This chipset supports the following protocols: SPI. Probing for Winbond W25x80, 1024 KB: Error accessing flash chip, 0x100000 bytes at 0xfff00000 /dev/mem mmap failed: Value too large for defined data type
On 28/09/10 13:54, Pádraig Brady wrote:
This issue looks similar to this: http://www.coreboot.org/pipermail/coreboot/2009-February/044672.html
Any ideas?
Ah, when trying the same binary on an official fedora 13 live usb key it works. So it's something specific to my system. Feel free to ignore this unless you know off the top of your head what the issue might be on my read-only root, custom F12 distro.
The differences are summarised below:
Broken...
flashrom v0.9.2-r1182 on Linux 2.6.32.10-90.fc12.i686 (i686) Probing for Winbond W25x80, 1024 KB: Error accessing flash chip, 0x100000 bytes at 0xfff00000 /dev/mem mmap failed: Value too large for defined data type
Working...
flashrom v0.9.2-r1182 on Linux 2.6.33.3-85.fc13.i686 (i686) Probing for Winbond W25x80, 1024 KB: probe_spi_rdid_generic: id1 0xef, id2 0x3014 Chip status register is 00 Found chip "Winbond W25x80" (1024 KB, SPI) at physical address 0xfff00000.
cheers, Pádraig.
On 28.09.2010 15:43, Pádraig Brady wrote:
On 28/09/10 13:54, Pádraig Brady wrote:
This issue looks similar to this: http://www.coreboot.org/pipermail/coreboot/2009-February/044672.html
Any ideas?
Ah, when trying the same binary on an official fedora 13 live usb key it works. So it's something specific to my system. Feel free to ignore this unless you know off the top of your head what the issue might be on my read-only root, custom F12 distro.
The differences are summarised below:
Broken...
flashrom v0.9.2-r1182 on Linux 2.6.32.10-90.fc12.i686 (i686) Probing for Winbond W25x80, 1024 KB: Error accessing flash chip, 0x100000 bytes at 0xfff00000 /dev/mem mmap failed: Value too large for defined data type
Working...
flashrom v0.9.2-r1182 on Linux 2.6.33.3-85.fc13.i686 (i686) Probing for Winbond W25x80, 1024 KB: probe_spi_rdid_generic: id1 0xef, id2 0x3014 Chip status register is 00 Found chip "Winbond W25x80" (1024 KB, SPI) at physical address 0xfff00000.
Mh. Could you please compare the following for both kernels? CONFIG_X86_PAT CONFIG_STRICT_DEVMEM /proc/iomem The first 100 lines of dmesg
I believe there should be a clue somewhere.
Finally, I'd love to see if flashrom r1180 works on the broken machine. (Explanation: r1181 changed physical memory handling, and I want to be totally sure that this is not the reason you're seeing errors).
Regards, Carl-Daniel
On 30/09/10 00:50, Carl-Daniel Hailfinger wrote:
On 28.09.2010 15:43, Pádraig Brady wrote:
On 28/09/10 13:54, Pádraig Brady wrote:
This issue looks similar to this: http://www.coreboot.org/pipermail/coreboot/2009-February/044672.html
Any ideas?
Ah, when trying the same binary on an official fedora 13 live usb key it works. So it's something specific to my system. Feel free to ignore this unless you know off the top of your head what the issue might be on my read-only root, custom F12 distro.
The differences are summarised below:
Broken...
flashrom v0.9.2-r1182 on Linux 2.6.32.10-90.fc12.i686 (i686) Probing for Winbond W25x80, 1024 KB: Error accessing flash chip, 0x100000 bytes at 0xfff00000 /dev/mem mmap failed: Value too large for defined data type
Working...
flashrom v0.9.2-r1182 on Linux 2.6.33.3-85.fc13.i686 (i686) Probing for Winbond W25x80, 1024 KB: probe_spi_rdid_generic: id1 0xef, id2 0x3014 Chip status register is 00 Found chip "Winbond W25x80" (1024 KB, SPI) at physical address 0xfff00000.
Mh. Could you please compare the following for both kernels? CONFIG_X86_PAT CONFIG_STRICT_DEVMEM
I had noticed the associated error message in the source, which was not output as EOVERFLOW is returned rather than EINVAL, and so had already confirmed that both systems had:
# grep -E "CONFIG_(X86_PAT|STRICT_DEVMEM)" /boot/config* CONFIG_X86_PAT=y CONFIG_STRICT_DEVMEM=y
/proc/iomem The first 100 lines of dmesg
I've not access to the working system at the moment, and realise that the comparison might highlight the issue, but just in case, I've attached the above for the broken system. I'll post a diff from the working system later.
I believe there should be a clue somewhere.
Finally, I'd love to see if flashrom r1180 works on the broken machine. (Explanation: r1181 changed physical memory handling, and I want to be totally sure that this is not the reason you're seeing errors).
I had tried to bisect, but r709 behaves the same way at least.
cheers, Pádraig.
On 30/09/10 07:47, Pádraig Brady wrote:
On 30/09/10 00:50, Carl-Daniel Hailfinger wrote:
Mh. Could you please compare the following for both kernels?
/proc/iomem The first 100 lines of dmesg
I believe there should be a clue somewhere.
Attached is dmesg and iomem from the working kernel (I just booted a Fedora 14 live key on the same system and flashrom works fine).
Nothing obvious from the iomem diff: (02:00.0 is the ethernet controller BTW)
$ diff broken.iomem working.iomem 11,13c11,13 < 00400000-0079856f : Kernel code < 00798570-009d970f : Kernel data < 00a6a000-00b318d7 : Kernel bss ---
00400000-007d8801 : Kernel code 007d8802-00a6213f : Kernel data 00c31000-0130a14b : Kernel bss
19c19 < e0000000-efffffff : PCI MMCONFIG 0 [00-ff] ---
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
27d26 < fdc00000-fdc1ffff : 0000:02:00.0 30a30
fddc0000-fdddffff : 0000:02:00.0
42c42 < fec00000-fec00fff : IOAPIC 0 ---
fec00000-fec003ff : IOAPIC 0
dmesg shows some differences in the memory maps but I'll need to do further investigation to be able to interpret these differences:
$ diff broken.dmesg working.dmesg 3,12c3 < Linux version 2.6.32.10-90.fc12.i686 (p4@f12.labs.lincor.com) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Fri Aug 13 11:59:33 IST 2010 ---
Linux version 2.6.35.4-28.fc14.i686 (mockbuild@x86-19.phx2.fedoraproject.org) (gcc version 4.5.1 20100907 (Red Hat 4.5.1-3) (GCC) ) #1 SMP Wed Sep 15 02:03:44 UTC 2010
22a14
Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel!
25a18,19
e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved) e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
55c49,50 < initial memory mapped : 0 - 01000000 ---
initial memory mapped : 0 - 01800000 found SMP MP-table at [c00f3860] f3860
57d51 < Using x86 segment limits to approximate NX protection 61,62c55,56 < kernel direct mapping tables up to 1f6e0000 @ 10000-16000 < RAMDISK: 1e6b6000 - 1f6bf3e3 ---
kernel direct mapping tables up to 1f6e0000 @ 15000-1b000 RAMDISK: 1ef22000 - 1f6df000
79,90c73,87 < node 0 bootmap 00013000 - 00016edc < (9 early reservations) ==> bootmem [0000000000 - 001f6e0000] < #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] < #1 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000] < #2 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000] < #3 [0000400000 - 0000b318d8] TEXT DATA BSS ==> [0000400000 - 0000b318d8] < #4 [001e6b6000 - 001f6bf3e3] RAMDISK ==> [001e6b6000 - 001f6bf3e3] < #5 [000009dc00 - 0000100000] BIOS reserved ==> [000009dc00 - 0000100000] < #6 [0000b32000 - 0000b3606a] BRK ==> [0000b32000 - 0000b3606a] < #7 [0000010000 - 0000013000] PGTABLE ==> [0000010000 - 0000013000] < #8 [0000013000 - 0000017000] BOOTMAP ==> [0000013000 - 0000017000] < found SMP MP-table at [c00f3860] f3860 ---
node 0 bootmap 00018000 - 0001bedc (13/32 early reservations) ==> bootmem [0000000000 - 001f6e0000] #0 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000] #1 [0000400000 - 000130a14c] TEXT DATA BSS ==> [0000400000 - 000130a14c] #2 [001ef22000 - 001f6df000] RAMDISK ==> [001ef22000 - 001f6df000] #3 [000130b000 - 000131106a] BRK ==> [000130b000 - 000131106a] #4 [00000f3870 - 0000100000] BIOS reserved ==> [00000f3870 - 0000100000] #5 [00000f3860 - 00000f3870] MP-table mpf ==> [00000f3860 - 00000f3870] #6 [000009f000 - 00000f1e34] BIOS reserved ==> [000009f000 - 00000f1e34] #7 [00000f1f74 - 00000f3860] BIOS reserved ==> [00000f1f74 - 00000f3860] #8 [00000f1e34 - 00000f1f74] MP-table mpc ==> [00000f1e34 - 00000f1f74] #9 [0000010000 - 0000011000] TRAMPOLINE ==> [0000010000 - 0000011000] #10 [0000011000 - 0000015000] ACPI WAKEUP ==> [0000011000 - 0000015000] #11 [0000015000 - 0000018000] PGTABLE ==> [0000015000 - 0000018000] #12 [0000018000 - 000001c000] BOOTMAP ==> [0000018000 - 000001c000]
94c91 < HighMem 0x0001f6e0 -> 0x0001f6e0 ---
HighMem empty
100c97,100 < free_area_init_node: node 0, pgdat c09b9260, node_mem_map c1001200 ---
free_area_init_node: node 0, pgdat c0a42ec0, node_mem_map c1313200 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 3951 pages, LIFO batch:0
cheers, Pádraig.
On 30.09.2010 12:15, Pádraig Brady wrote:
On 30/09/10 07:47, Pádraig Brady wrote:
On 30/09/10 00:50, Carl-Daniel Hailfinger wrote:
Mh. Could you please compare the following for both kernels?
/proc/iomem The first 100 lines of dmesg
I believe there should be a clue somewhere.
Attached is dmesg and iomem from the working kernel (I just booted a Fedora 14 live key on the same system and flashrom works fine).
Nothing obvious from the iomem diff: (02:00.0 is the ethernet controller BTW)
$ diff broken.iomem working.iomem [...]
dmesg shows some differences in the memory maps but I'll need to do further investigation to be able to interpret these differences:
$ diff broken.dmesg working.dmesg 3,12c3
< Linux version 2.6.32.10-90.fc12.i686 (p4@f12.labs.lincor.com) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Fri Aug 13 11:59:33 IST 2010
Linux version 2.6.35.4-28.fc14.i686 (mockbuild@x86-19.phx2.fedoraproject.org) (gcc version 4.5.1 20100907 (Red Hat 4.5.1-3) (GCC) ) #1 SMP Wed Sep 15 02:03:44 UTC 2010
I noticed that the broken kernel is apparently some self-built kernel, possibly with extra patches. Still, I'd like to make sure it works fine if at all possible.
Could you add the following kernel parameters to the command line of the broken kernel? noexec=off nopat acpi_enforce_resources=lax highmem=0K iomem=relaxed
The character after "highmen=" is a zero. A combination of these parameters may fix it.
Regards, Carl-Daniel
On 30/09/10 13:13, Carl-Daniel Hailfinger wrote:
I noticed that the broken kernel is apparently some self-built kernel, possibly with extra patches. Still, I'd like to make sure it works fine if at all possible.
It's F12 official, rebuilt with a patch to a network driver. No changes to config.
Could you add the following kernel parameters to the command line of the broken kernel? noexec=off nopat acpi_enforce_resources=lax highmem=0K iomem=relaxed
The character after "highmen=" is a zero.
OK :)
A combination of these parameters may fix it.
No change with all of the above included :(
cheers, Pádraig.
On 30/09/10 13:25, Pádraig Brady wrote:
On 30/09/10 13:13, Carl-Daniel Hailfinger wrote:
I noticed that the broken kernel is apparently some self-built kernel, possibly with extra patches. Still, I'd like to make sure it works fine if at all possible.
It's F12 official, rebuilt with a patch to a network driver. No changes to config.
Could you add the following kernel parameters to the command line of the broken kernel? noexec=off nopat acpi_enforce_resources=lax highmem=0K iomem=relaxed
The character after "highmen=" is a zero.
OK :)
A combination of these parameters may fix it.
No change with all of the above included :(
Hmm doing an strace shows:
sys_physmap_rw_uncached (phys_addr=FFF00000, size=1048576) { mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0xffffffffffffff00) = -1 EOVERFLOW }
I at first thought that strace was just getting it wrong, but perhaps something (glibc?) is messing up and doing a signed right shift of the address, and thus mangling the address.
more digging...
cheers, Pádraig.
On 30.09.2010 14:43, Pádraig Brady wrote:
On 30/09/10 13:25, Pádraig Brady wrote:
On 30/09/10 13:13, Carl-Daniel Hailfinger wrote:
I noticed that the broken kernel is apparently some self-built kernel, possibly with extra patches. Still, I'd like to make sure it works fine if at all possible.
It's F12 official, rebuilt with a patch to a network driver. No changes to config.
Could you add the following kernel parameters to the command line of the broken kernel? noexec=off nopat acpi_enforce_resources=lax highmem=0K iomem=relaxed
The character after "highmen=" is a zero.
OK :)
A combination of these parameters may fix it.
No change with all of the above included :(
Hmm doing an strace shows:
sys_physmap_rw_uncached (phys_addr=FFF00000, size=1048576) { mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0xffffffffffffff00) = -1 EOVERFLOW }
I at first thought that strace was just getting it wrong, but perhaps something (glibc?) is messing up and doing a signed right shift of the address, and thus mangling the address.
The man page for mmap2() says: "the final argument specifies the offset into the file in 4096-byte units instead of bytes" So the shifting is correct, but the sign extension is a HUGE FREAKING BUG. It would be interesting to see if the same sign extension happens on the working machine. If the flashrom binary is the same, we can rule out compiler side effects, and should probably blame libc.
What happens if you don't use the -c parameter to flashrom? Just flashrom -V maybe that gives us some additional clues.
On 30/09/10 17:13, Carl-Daniel Hailfinger wrote:
On 30.09.2010 14:43, Pádraig Brady wrote:
On 30/09/10 13:25, Pádraig Brady wrote:
On 30/09/10 13:13, Carl-Daniel Hailfinger wrote:
I noticed that the broken kernel is apparently some self-built kernel, possibly with extra patches. Still, I'd like to make sure it works fine if at all possible.
It's F12 official, rebuilt with a patch to a network driver. No changes to config.
Could you add the following kernel parameters to the command line of the broken kernel? noexec=off nopat acpi_enforce_resources=lax highmem=0K iomem=relaxed
The character after "highmen=" is a zero.
OK :)
A combination of these parameters may fix it.
No change with all of the above included :(
Hmm doing an strace shows:
sys_physmap_rw_uncached (phys_addr=FFF00000, size=1048576) { mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0xffffffffffffff00) = -1 EOVERFLOW }
I at first thought that strace was just getting it wrong, but perhaps something (glibc?) is messing up and doing a signed right shift of the address, and thus mangling the address.
The man page for mmap2() says: "the final argument specifies the offset into the file in 4096-byte units instead of bytes" So the shifting is correct, but the sign extension is a HUGE FREAKING BUG. It would be interesting to see if the same sign extension happens on the working machine. If the flashrom binary is the same, we can rule out compiler side effects, and should probably blame libc.
What happens if you don't use the -c parameter to flashrom? Just flashrom -V maybe that gives us some additional clues.
Nothing seems pertinent in flashrom -V. I've changed the hardware to one with a different BIOS chip. Same issue. I went back to an older build of ours with glibc-2.11-2 and it works! I downgraded from glibc-2.11.2-1 to glibc-2.11-2 on our current build and still broken. So it's some recent config in our build that's triggering this.
So there is nothing you can help with I think I'm afraid. I'll just keep looking when I have time.
cheers, Pádraig.
Am Donnerstag, den 30.09.2010, 17:36 +0100 schrieb Pádraig Brady:
Nothing seems pertinent in flashrom -V. I've changed the hardware to one with a different BIOS chip. Same issue. I went back to an older build of ours with glibc-2.11-2 and it works! I downgraded from glibc-2.11.2-1 to glibc-2.11-2 on our current build and still broken. So it's some recent config in our build that's triggering this.
Or a compiler bug/bugfix, if you updated the compiler between the old builds and the new ones.
Regards, Michael Karcher
On 30/09/10 17:46, Michael Karcher wrote:
Am Donnerstag, den 30.09.2010, 17:36 +0100 schrieb Pádraig Brady:
Nothing seems pertinent in flashrom -V. I've changed the hardware to one with a different BIOS chip. Same issue. I went back to an older build of ours with glibc-2.11-2 and it works! I downgraded from glibc-2.11.2-1 to glibc-2.11-2 on our current build and still broken. So it's some recent config in our build that's triggering this.
Or a compiler bug/bugfix, if you updated the compiler between the old builds and the new ones.
After an interesting session in gdb I single stepped into some assembly and noticed the culprit "sar" instruction, which was in a preloaded closed source library that was intercepting mmap().
cheers, Pádraig.
-
Carl-Daniel Hailfinger -
Michael Karcher -
Pádraig Brady