Ubuntu
linux package

BUG: Bad page state in process firefox-bin pfn:3ed00

Bug #653414 reported by Eric on 2010-10-02

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	linux (Ubuntu)	Invalid	Undecided	Unassigned

Bug Description

Binary package hint: firefox

unknown...firefox appears to have started normally. was unaware of the error until seeing the apport icon in the bar

ProblemType: KernelOops
DistroRelease: Ubuntu 10.10
Package: linux-image-2.6.35-22-generic 2.6.35-22.33
Regression: No
Reproducible: No
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic i686
NonfreeKernelModules: wl
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
Annotation: Your system might become unstable now and might need to be restarted.
Architecture: i386
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 2/2
   Subdevice #0: subdevice #0
   Subdevice #1: subdevice #1
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: eric 1620 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'SB'/'HDA ATI SB at 0x96500000 irq 16'
   Mixer name : 'IDT 92HD75B3X5'
   Components : 'HDA:111d7603,103c1457,00100202'
   Controls : 19
   Simple ctrls : 13
Card1.Amixer.info:
Card hw:1 'HDMI'/'HDA ATI HDMI at 0x96410000 irq 45'
   Mixer name : 'ATI RS690/780 HDMI'
   Components : 'HDA:1002791a,00791a00,00100000'
   Controls : 4
   Simple ctrls : 1
Card1.Amixer.values:
Simple mixer control 'IEC958',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
Date: Sat Oct 2 01:05:25 2010
Failure: oops
Frequency: This has only happened once.
HibernationDevice: RESUME=UUID=c0bf6932-6bdc-4f63-a928-d8bceb1f4158
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta i386 (20100901.1)
MachineType: Hewlett-Packard HP ProBook 6555b
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=UUID=133ce903-18ff-488b-ac28-79a4162abde2 ro quiet splash
RelatedPackageVersions: linux-firmware 1.38
RfKill:
0: hp-wwan: Wireless WAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
Title: BUG: Bad page state in process firefox-bin pfn:3ed00
dmi.bios.date: 05/11/2010
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68DTM Ver. F.02
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 1455
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 75.10
dmi.chassis.asset.tag: CNU0232ZKV
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68DTMVer.F.02:bd05/11/2010:svnHewlett-Packard:pnHPProBook6555b:pvr:rvnHewlett-Packard:rn1455:rvrKBCVersion75.10:cvnHewlett-Packard:ct10:cvr:
dmi.product.name: HP ProBook 6555b
dmi.sys.vendor: Hewlett-Packard

Tags:

Revision history for this message

Eric (1ballistic1) wrote on 2010-10-02:

AcpiTables.txt Edit (528.2 KiB, text/plain; charset="utf-8")
AlsaDevices.txt Edit (586 bytes, text/plain; charset="utf-8")
AplayDevices.txt Edit (265 bytes, text/plain; charset="utf-8")
BootDmesg.txt Edit (62.9 KiB, text/plain; charset="utf-8")
Card0.Amixer.values.txt Edit (2.4 KiB, text/plain; charset="utf-8")
Card0.Codecs.codec.0.txt Edit (8.7 KiB, text/plain; charset="utf-8")
Card1.Codecs.codec.0.txt Edit (1.0 KiB, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (1.7 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (1.8 KiB, text/plain; charset="utf-8")
IwConfig.txt Edit (568 bytes, text/plain; charset="utf-8")
Lspci.txt Edit (41.1 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (819 bytes, text/plain; charset="utf-8")
OopsText.txt Edit (822 bytes, text/plain; charset="utf-8")
PciMultimedia.txt Edit (1.6 KiB, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (1.8 KiB, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (1.5 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (2.7 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (140.3 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (309.4 KiB, text/plain; charset="utf-8")
WifiSyslog.txt Edit (153.2 KiB, text/plain; charset="utf-8")

Chris Coulson (chrisccoulson) on 2010-10-02

affects:

firefox (Ubuntu) → linux (Ubuntu)

Jeremy Foshee (jeremyfoshee) on 2010-10-15

tags:

added: kj-triage

Revision history for this message

octoploid (cryptooctoploid) wrote on 2010-11-15:

Download full text (3.4 KiB)

This is fixed by:
commit a56d5318716d120e040294bb258901ba89fb9c90
Author: Jiri Slaby <email address hidden>
Date: Tue Oct 26 14:22:11 2010 -0700

hpet: unmap unused I/O space

When the initialization code in hpet finds a memory resource and does not
find an IRQ, it does not unmap the memory resource previously mapped.

    There are buggy BIOSes which report resources exactly like this and what
    is worse the memory region bases point to normal RAM. This normally would
    not matter since the space is not touched. But when PAT is turned on,
    ioremap causes the page to be uncached and sets this bit in page->flags.

Then when the page is about to be used by the allocator, it is reported
as:

    BUG: Bad page state in process md5sum pfn:3ed00
    page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0
    page flags: 0x20000001000000(uncached)
    Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1
    Call Trace:
     [<ffffffff810df851>] bad_page+0xb1/0x100
     [<ffffffff810dfa45>] prep_new_page+0x1a5/0x1c0
     [<ffffffff810dfe01>] get_page_from_freelist+0x3a1/0x640
     [<ffffffff810e01af>] __alloc_pages_nodemask+0x10f/0x6b0
    ...

In this particular case:

    1) HPET returns 3ed00000 as memory region base, but it is not in
    reserved ranges reported by the BIOS (excerpt):
     BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable)
     BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved)

    2) there is no IRQ resource reported by HPET method. On the other
    hand, the Intel HPET specs (1.0a) says (3.2.5.1):
    _CRS (
      // Report 1K of memory consumed by this Timer Block
      memory range consumed
      // Optional: only used if BIOS allocates Interrupts [1]
      IRQs consumed
    )

    [1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND
    Legacy 8254/Legacy RTC hardware still exists, the device objects
    associated with 8254 & RTC devices should not report IRQ0/IRQ8 as
    "consumed resources".

So in theory we should check whether if it is the case and use those
interrupts instead.

Anyway the address reported by the BIOS here is bogus, so non-presence
of IRQ doesn't mean the "optional" part in point 2).

    Since I got no reply previously, fix this by simply unmapping the space
    when IRQ is not found and memory region was mapped previously. It would
    be probably more safe to walk the resources again and unmap appropriately
    depending on type. But as we now use only ioremap for both 2 memory
    resource types, it is not necessarily needed right now.

Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908

    Reported-by: Olaf Hering <email address hidden>
    Signed-off-by: Jiri Slaby <email address hidden>
    Acked-by: Clemens Ladisch <email address hidden>
    Cc: <email address hidden>
    Signed-off-by: Andrew Morton <email address hidden>
    Signed-off-by: Linus Torvalds <email address hidden>

diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index a4eee32..84e6a7e 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -1000,6 +1000,8 @@ static...

This is fixed by:
commit a56d5318716d120e040294bb258901ba89fb9c90
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Tue Oct 26 14:22:11 2010 -0700

hpet: unmap unused I/O space
    
    When the initialization code in hpet finds a memory resource and does not
    find an IRQ, it does not unmap the memory resource previously mapped.
    
    There are buggy BIOSes which report resources exactly like this and what
    is worse the memory region bases point to normal RAM.  This normally would
    not matter since the space is not touched.  But when PAT is turned on,
    ioremap causes the page to be uncached and sets this bit in page->flags.
    
    Then when the page is about to be used by the allocator, it is reported
    as:
    
    BUG: Bad page state in process md5sum  pfn:3ed00
    page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0
    page flags: 0x20000001000000(uncached)
    Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1
    Call Trace:
     [<ffffffff810df851>] bad_page+0xb1/0x100
     [<ffffffff810dfa45>] prep_new_page+0x1a5/0x1c0
     [<ffffffff810dfe01>] get_page_from_freelist+0x3a1/0x640
     [<ffffffff810e01af>] __alloc_pages_nodemask+0x10f/0x6b0
    ...
    
    In this particular case:
    
    1) HPET returns 3ed00000 as memory region base, but it is not in
    reserved ranges reported by the BIOS (excerpt):
     BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable)
     BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved)
    
    2) there is no IRQ resource reported by HPET method. On the other
    hand, the Intel HPET specs (1.0a) says (3.2.5.1):
    _CRS (
      // Report 1K of memory consumed by this Timer Block
      memory range consumed
      // Optional: only used if BIOS allocates Interrupts [1]
      IRQs consumed
    )
    
    [1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND
    Legacy 8254/Legacy RTC hardware still exists, the device objects
    associated with 8254 & RTC devices should not report IRQ0/IRQ8 as
    "consumed resources".
    
    So in theory we should check whether if it is the case and use those
    interrupts instead.
    
    Anyway the address reported by the BIOS here is bogus, so non-presence
    of IRQ doesn't mean the "optional" part in point 2).
    
    Since I got no reply previously, fix this by simply unmapping the space
    when IRQ is not found and memory region was mapped previously.  It would
    be probably more safe to walk the resources again and unmap appropriately
    depending on type.  But as we now use only ioremap for both 2 memory
    resource types, it is not necessarily needed right now.
    
    Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Acked-by: Clemens Ladisch <clemens@ladisch.de>
    Cc: <stable@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index a4eee32..84e6a7e 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -1000,6 +1000,8 @@ static int hpet_acpi_add(struct acpi_device *device)
                return -ENODEV;
 
        if (!data.hd_address || !data.hd_nirqs) {
+               if (data.hd_address)
+                       iounmap(data.hd_address);
                printk("%s: no address or irqs in _CRS\n", __func__);
                return -ENODEV;
        }

Brad Figg (brad-figg) on 2010-12-04

tags:

added: acpi-bad-address

Brad Figg (brad-figg) on 2011-05-04

Changed in linux (Ubuntu):
status:	New → Confirmed

Revision history for this message

penalvch (penalvch) wrote on 2012-06-10:

Eric, thank you for reporting this and helping make Ubuntu better. Maverick reached EOL on April 10, 2012.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in a supported release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.

Please let us know your results. Thanks in advance.

Changed in linux (Ubuntu):
status:	Confirmed → Incomplete

Revision history for this message

Eric (1ballistic1) wrote on 2012-06-10:

Couldn't tell you now, I don't have that laptop as of about 6 months ago.

penalvch (penalvch) on 2012-06-11

Changed in linux (Ubuntu):
status:	Incomplete → Invalid

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

Add attachment

Remote bug watches

novell-bugs #629908
[RESOLVED FIXED] Edit

Bug watches keep track of this bug in other bug trackers.

Ubuntulinux package

BUG: Bad page state in process firefox-bin pfn:3ed00

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
linux package