People with HP Desktops (including me) encounter couple of DMI errors
during boot - dmi_save_oem_strings_devices: out of memory and dmi_string: out of
memory.
On some HP desktops the DMI data include OEM strings (type 11) out of
which only few are meaningful and most other are empty. DMI code
religiously creates copies of these 27 strings (65 bytes each in my
case) and goes OOM in dmi_string().
If DMI_MAX_DATA is bumped up a little then it goes and fails in
dmi_save_oem_strings while allocating dmi_devices of sizeof(struct
dmi_device) corresponding to these strings.
On x86_64 since we cannot use alloc_bootmem this early, the code uses a
static array of 2048 bytes (DMI_MAX_DATA) for allocating the memory DMI
needs. It does not survive the creation of empty strings and devices.
Fix this by detecting and not newly allocating empty strings and instead
using a one statically defined dmi_empty_string.
Also do not create a new struct dmi_device for each empty string - use one
statically define dmi_device with .name=dmi_empty_string and add that to
the dmi_devices list.
On x64 this should stop the OOM with same current size of DMI_MAX_DATA and
on x86 this should save a good amount of (27*65 bytes + 27*sizeof(struct
dmi_device) bootmem.
Compile and boot tested on both x86 and x86_64.
Signed-off-by: Parag Warudkar <[email protected]>
--- linux-2.6/drivers/firmware/dmi_scan.c 2007-12-07 10:04:38.000000000 -0500
+++ linux-2.6-work/drivers/firmware/dmi_scan.c 2007-12-18 19:21:52.000000000 -0500
@@ -8,6 +8,8 @@
#include <linux/slab.h>
#include <asm/dmi.h>
+static char dmi_empty_string[] = " ";
+
static char * __init dmi_string(const struct dmi_header *dm, u8 s)
{
const u8 *bp = ((u8 *) dm) + dm->length;
@@ -21,11 +23,15 @@
}
if (*bp != 0) {
- str = dmi_alloc(strlen(bp) + 1);
+ size_t len = strlen(bp)+1;
+ size_t cmp_len = len > 8 ? 8 : len;
+ if (!memcmp(bp, dmi_empty_string, cmp_len))
+ return dmi_empty_string;
+ str = dmi_alloc(len);
if (str != NULL)
strcpy(str, bp);
else
- printk(KERN_ERR "dmi_string: out of memory.\n");
+ printk(KERN_ERR "dmi_string: cannot allocate %Zu bytes.\n", len);
}
}
@@ -175,12 +181,24 @@
}
}
+static struct dmi_device empty_oem_string_dev =
+ {.name = dmi_empty_string,
+ .device_data = NULL
+ };
+
static void __init dmi_save_oem_strings_devices(const struct dmi_header *dm)
{
int i, count = *(u8 *)(dm + 1);
struct dmi_device *dev;
for (i = 1; i <= count; i++) {
+ char* devname = dmi_string(dm, i);
+
+ if (!strcmp(devname, dmi_empty_string)) {
+ list_add(&empty_oem_string_dev.list, &dmi_devices);
+ continue;
+ }
+
dev = dmi_alloc(sizeof(*dev));
if (!dev) {
printk(KERN_ERR
@@ -189,7 +207,7 @@
}
dev->type = DMI_DEV_TYPE_OEM_STRING;
- dev->name = dmi_string(dm, i);
+ dev->name = devname;
dev->device_data = NULL;
list_add(&dev->list, &dmi_devices);
* Parag Warudkar <[email protected]> wrote:
> People with HP Desktops (including me) encounter couple of DMI errors
> during boot - dmi_save_oem_strings_devices: out of memory and
> dmi_string: out of memory.
>
> On some HP desktops the DMI data include OEM strings (type 11) out of
> which only few are meaningful and most other are empty. DMI code
> religiously creates copies of these 27 strings (65 bytes each in my
> case) and goes OOM in dmi_string().
>
> If DMI_MAX_DATA is bumped up a little then it goes and fails in
> dmi_save_oem_strings while allocating dmi_devices of sizeof(struct
> dmi_device) corresponding to these strings.
>
> On x86_64 since we cannot use alloc_bootmem this early, the code uses
> a static array of 2048 bytes (DMI_MAX_DATA) for allocating the memory
> DMI needs. It does not survive the creation of empty strings and
> devices.
>
> Fix this by detecting and not newly allocating empty strings and
> instead using a one statically defined dmi_empty_string.
>
> Also do not create a new struct dmi_device for each empty string - use
> one statically define dmi_device with .name=dmi_empty_string and add
> that to the dmi_devices list.
>
> On x64 this should stop the OOM with same current size of DMI_MAX_DATA
> and on x86 this should save a good amount of (27*65 bytes +
> 27*sizeof(struct dmi_device) bootmem.
>
> Compile and boot tested on both x86 and x86_64.
thanks, i've applied your patch to x86.git. (tentative merge target of
2.6.25)
[ note: i had to manually fix up your patch because your email client
added an extra space to every diff line - see
Documentation/email-clients.txt on how to avoid that. I also did a few
small cleanups - please check patches via scripts/checkpatch.pl. I've
attached the merged patch below. ]
What's the worst-case symptom you get with that bug - any failure type
thing - or only annoying boot messages? Could you perhaps post the diff
-u between the unpatched and patched kernel's full dmesg/bootlog? Are
there any specific DMI quirks that are skipped due to us wasting DMI
space on empty strings?
Also, shouldnt we perhaps increase DMI_MAX_DATA from 2K to 4K?
Ingo
--------------->
Subject: x86: fix DMI out of memory problems
From: Parag Warudkar <[email protected]>
People with HP Desktops (including me) encounter couple of DMI errors
during boot - dmi_save_oem_strings_devices: out of memory and
dmi_string: out of memory.
On some HP desktops the DMI data include OEM strings (type 11) out of
which only few are meaningful and most other are empty. DMI code
religiously creates copies of these 27 strings (65 bytes each in my
case) and goes OOM in dmi_string().
If DMI_MAX_DATA is bumped up a little then it goes and fails in
dmi_save_oem_strings while allocating dmi_devices of sizeof(struct
dmi_device) corresponding to these strings.
On x86_64 since we cannot use alloc_bootmem this early, the code uses a
static array of 2048 bytes (DMI_MAX_DATA) for allocating the memory DMI
needs. It does not survive the creation of empty strings and devices.
Fix this by detecting and not newly allocating empty strings and instead
using a one statically defined dmi_empty_string.
Also do not create a new struct dmi_device for each empty string - use
one statically define dmi_device with .name=dmi_empty_string and add
that to the dmi_devices list.
On x64 this should stop the OOM with same current size of DMI_MAX_DATA
and on x86 this should save a good amount of (27*65 bytes +
27*sizeof(struct dmi_device) bootmem.
Compile and boot tested on both 32-bit and 64-bit x86.
Signed-off-by: Parag Warudkar <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
---
drivers/firmware/dmi_scan.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
Index: linux-x86.q/drivers/firmware/dmi_scan.c
===================================================================
--- linux-x86.q.orig/drivers/firmware/dmi_scan.c
+++ linux-x86.q/drivers/firmware/dmi_scan.c
@@ -8,6 +8,8 @@
#include <linux/slab.h>
#include <asm/dmi.h>
+static char dmi_empty_string[] = " ";
+
static char * __init dmi_string(const struct dmi_header *dm, u8 s)
{
const u8 *bp = ((u8 *) dm) + dm->length;
@@ -21,11 +23,16 @@ static char * __init dmi_string(const st
}
if (*bp != 0) {
- str = dmi_alloc(strlen(bp) + 1);
+ size_t len = strlen(bp)+1;
+ size_t cmp_len = len > 8 ? 8 : len;
+
+ if (!memcmp(bp, dmi_empty_string, cmp_len))
+ return dmi_empty_string;
+ str = dmi_alloc(len);
if (str != NULL)
strcpy(str, bp);
else
- printk(KERN_ERR "dmi_string: out of memory.\n");
+ printk(KERN_ERR "dmi_string: cannot allocate %Zu bytes.\n", len);
}
}
@@ -175,12 +182,23 @@ static void __init dmi_save_devices(cons
}
}
+static struct dmi_device empty_oem_string_dev = {
+ .name = dmi_empty_string,
+};
+
static void __init dmi_save_oem_strings_devices(const struct dmi_header *dm)
{
int i, count = *(u8 *)(dm + 1);
struct dmi_device *dev;
for (i = 1; i <= count; i++) {
+ char *devname = dmi_string(dm, i);
+
+ if (!strcmp(devname, dmi_empty_string)) {
+ list_add(&empty_oem_string_dev.list, &dmi_devices);
+ continue;
+ }
+
dev = dmi_alloc(sizeof(*dev));
if (!dev) {
printk(KERN_ERR
@@ -189,7 +207,7 @@ static void __init dmi_save_oem_strings_
}
dev->type = DMI_DEV_TYPE_OEM_STRING;
- dev->name = dmi_string(dm, i);
+ dev->name = devname;
dev->device_data = NULL;
list_add(&dev->list, &dmi_devices);
On Dec 19, 2007 5:48 AM, Ingo Molnar <[email protected]> wrote:
>
> * Parag Warudkar <[email protected]> wrote:
>
> [ note: i had to manually fix up your patch because your email client
> added an extra space to every diff line - see
> Documentation/email-clients.txt on how to avoid that. I also did a few
> small cleanups - please check patches via scripts/checkpatch.pl. I've
> attached the merged patch below. ]
Thanks for fixing this up - the only recommended option missing in
pine is quell-flowed-text. Will set it up and see how that goes.
>
> What's the worst-case symptom you get with that bug - any failure type
> thing - or only annoying boot messages? Could you perhaps post the diff
> -u between the unpatched and patched kernel's full dmesg/bootlog? Are
> there any specific DMI quirks that are skipped due to us wasting DMI
> space on empty strings?
I did not see any failures on my desktop at least - being a newer
Intel board (P35) it does not seem to require any quirks - for those
HP desktops which do require quirks it sounds plausible that some may
be missed without the patch. dmesg diff does not look significantly
different apart from the obviously absent DMI OOM messages and time.c
/ apic timer calibration differences along with same but differently
placed lines - not sure why that happens, may not be related to this
patch I think.
--- 2.6.24-rc5-patched 2007-12-19 07:21:05.000000000 -0500
+++ 2.6.24-rc5-new 2007-12-19 11:36:54.000000000 -0500
@@ -1,4 +1,4 @@
-Linux version 2.6.24-rc5 ([email protected]) (gcc
version 4.1.2 20070626 (Red Hat 4.1.2-14)) #2 SMP Mon Dec 17 18:42:27
EST 2007
+Linux version 2.6.24-rc5 ([email protected]) (gcc
version 4.1.2 20070626 (Red Hat 4.1.2-14)) #2 SMP Wed Dec 19 11:32:37
EST 2007
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
@@ -75,7 +75,7 @@
PID hash table entries: 4096 (order: 12, 32768 bytes)
hpet clockevent registered
TSC calibrated against HPET
-time.c: Detected 2199.954 MHz processor.
+time.c: Detected 2199.958 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
@@ -85,7 +85,7 @@
Placing software IO TLB between 0x7add000 - 0xbadd000
Memory: 6107352k/7077888k available (2349k kernel code, 182900k
reserved, 1103k data, 216k init)
SLUB: Genslabs=11, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1
-Calibrating delay using timer specific routine.. 4403.90 BogoMIPS (lpj=8807812)
+Calibrating delay using timer specific routine.. 4403.90 BogoMIPS (lpj=8807800)
Security Framework initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
@@ -101,12 +101,12 @@
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
Using local APIC timer interrupts.
-APIC timer calibration result 12499737
+APIC timer calibration result 12499803
Detected 12.499 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
-Calibrating delay using timer specific routine.. 4399.88 BogoMIPS (lpj=8799760)
+Calibrating delay using timer specific routine.. 4399.95 BogoMIPS (lpj=8799915)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
@@ -192,9 +192,9 @@
checking if image is initramfs...<7>Switched to high resolution mode on CPU 1
Switched to high resolution mode on CPU 0
it is
-Freeing initrd memory: 3036k freed
+Freeing initrd memory: 3037k freed
audit: initializing netlink socket (disabled)
-audit(1198048697.636:1): initialized
+audit(1198064108.636:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
@@ -318,17 +318,9 @@
ata2: SATA max UDMA/100 mmio m512@0xf9ffec00 tf 0xf9ffecc0 irq 17
usb 8-5: new high speed USB device using ehci_hcd and address 2
ata1: SATA link down (SStatus 0 SControl 310)
-usb 8-5: configuration #1 chosen from 1 choice
ata2: SATA link down (SStatus 0 SControl 310)
ahci 0000:00:1f.2: version 3.0
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
-usb 8-7: new high speed USB device using ehci_hcd and address 3
-usb 8-7: configuration #1 chosen from 1 choice
-hub 8-7:1.0: USB hub found
-hub 8-7:1.0: 3 ports detected
-usb 8-7.2: new low speed USB device using ehci_hcd and address 4
-usb 8-7.2: configuration #1 chosen from 1 choice
-hiddev96: USB HID v1.11 Device [Apple Cinema Display] on usb-0000:00:1d.7-7.2
ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pio slum part
PCI: Setting latency timer of device 0000:00:1f.2 to 64
@@ -400,11 +392,19 @@
[LDM] sdc1
sd 7:0:0:0: [sdc] Attached SCSI disk
Initializing USB Mass Storage driver...
+usb 8-5: configuration #1 chosen from 1 choice
+usb 8-7: new high speed USB device using ehci_hcd and address 3
+usb 8-7: configuration #1 chosen from 1 choice
+hub 8-7:1.0: USB hub found
+hub 8-7:1.0: 3 ports detected
scsi8 : SCSI emulation for USB Mass Storage devices
-usbcore: registered new interface driver usb-storage
-USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
+usb 8-7.2: new low speed USB device using ehci_hcd and address 4
+usb 8-7.2: configuration #1 chosen from 1 choice
+hiddev96: USB HID v1.11 Device [Apple Cinema Display] on usb-0000:00:1d.7-7.2
+usbcore: registered new interface driver usb-storage
+USB Mass Storage support registered.
usb-storage: device scan complete
scsi 8:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0
scsi 8:0:0:1: Direct-Access Generic USB CF Reader 1.01 PQ: 0 ANSI: 0
@@ -442,7 +442,8 @@
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
SELinux: policy loaded with handle_unknown=deny
-audit(1198048714.948:2): policy loaded auid=4294967295
+audit(1198064127.320:2): policy loaded auid=4294967295
+shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0
e1000e: Copyright (c) 1999-2007 Intel Corporation.
ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 20 (level, low) -> IRQ 20
@@ -451,16 +452,14 @@
input: PC Speaker as /class/input/input3
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input4
+ACPI: Power Button (CM) [PWRB]
0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1d:60:d1:07:13
0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
0000:00:19.0: eth0: MAC: 5, PHY: 6, PBA No: ffffff-0ff
-shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
ACPI: PCI Interrupt 0000:00:1f.3[C] -> GSI 18 (level, low) -> IRQ 18
-ACPI: Power Button (CM) [PWRB]
sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 3:0:0:0: Attached scsi CD-ROM sr0
-usbcore: registered new interface driver appledisplay
sd 2:0:0:0: Attached scsi generic sg0 type 0
sr 3:0:0:0: Attached scsi generic sg1 type 5
sd 4:0:0:0: Attached scsi generic sg2 type 0
@@ -469,6 +468,7 @@
sd 8:0:0:1: Attached scsi generic sg5 type 0
sd 8:0:0:2: Attached scsi generic sg6 type 0
sd 8:0:0:3: Attached scsi generic sg7 type 0
+usbcore: registered new interface driver appledisplay
floppy0: no floppy controllers found
lp: driver loaded but no devices found
SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts
@@ -505,3 +505,4 @@
eth0: no IPv6 routers present
Bridge firewalling registered
virbr0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature.
+ip_tables: (C) 2000-2006 Netfilter Core Team
>
> Also, shouldnt we perhaps increase DMI_MAX_DATA from 2K to 4K?
>
Google doesn't reveal anyone apart from HP Desktop owners [*] with
large empty OEM strings as having this problem - and with this patch
the existing 2K is underutilized - less than 500 bytes on my desktop.
So I think we can defer the increase until someone actually needs that
much DMI space for valid purposes.
Thanks
Parag
[*] http://forums.fedoraforum.org/archive/index.php/t-163317.html
[*] http://ubuntuforums.org/archive/index.php/t-357738.html
* Parag Warudkar <[email protected]> wrote:
> --- 2.6.24-rc5-patched 2007-12-19 07:21:05.000000000 -0500
> +++ 2.6.24-rc5-new 2007-12-19 11:36:54.000000000 -0500
hm, i see no OOM messages in the diff - what am i missing?
best would be to run:
sort 2.6.24-rc5-patched > new.log
sort 2.6.24-rc5-new > old.log
diff -up old.log new.log
to remove line ordering issues.
Ingo
On Dec 19, 2007 11:54 AM, Ingo Molnar <[email protected]> wrote:
>
> * Parag Warudkar <[email protected]> wrote:
>
> > --- 2.6.24-rc5-patched 2007-12-19 07:21:05.000000000 -0500
> > +++ 2.6.24-rc5-new 2007-12-19 11:36:54.000000000 -0500
>
> hm, i see no OOM messages in the diff - what am i missing?
>
> best would be to run:
>
> sort 2.6.24-rc5-patched > new.log
> sort 2.6.24-rc5-new > old.log
> diff -up old.log new.log
>
> to remove line ordering issues.
Pasted the wrong diff - just wanted to feel normal about the day I guess.
Here is the right one -
2.6.24-rc5 is without patch, 2.6.24-rc5-new is with patch.
--- old.log 2007-12-19 11:59:15.000000000 -0500
+++ new.log 2007-12-19 11:59:08.000000000 -0500
@@ -76,7 +76,7 @@ ahci 0000:00:1f.2: flags: 64bit ncq sntf
ahci 0000:00:1f.2: version 3.0
Allocate Port Service[0000:00:01.0:pcie00]
Allocating PCI resources starting at d4000000 (gap: d0000000:2ee00000)
-APIC timer calibration result 12499727
+APIC timer calibration result 12499803
assign_interrupt_mode Found MSI capability
ata1: SATA link down (SStatus 0 SControl 310)
ata1: SATA max UDMA/100 mmio m512@0xf9ffec00 tf 0xf9ffec80 irq 17
@@ -105,8 +105,8 @@ ata8.00: ATA-7: ST3300622AS, 3.AAH, max
ata8.00: configured for UDMA/133
ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata8: SATA max UDMA/133 abar m2048@0xf9eff000 port 0xf9eff380 irq 318
-audit(1198063330.636:1): initialized
-audit(1198063349.305:2): policy loaded auid=4294967295
+audit(1198064108.636:1): initialized
+audit(1198064127.320:2): policy loaded auid=4294967295
audit: initializing netlink socket (disabled)
BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
@@ -133,8 +133,8 @@ Boot video device is 0000:02:00.0
Bridge firewalling registered
Brought up 2 CPUs
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1547375
-Calibrating delay using timer specific routine.. 4399.87 BogoMIPS (lpj=8799757)
-Calibrating delay using timer specific routine.. 4403.76 BogoMIPS (lpj=8807520)
+Calibrating delay using timer specific routine.. 4399.95 BogoMIPS (lpj=8799915)
+Calibrating delay using timer specific routine.. 4403.90 BogoMIPS (lpj=8807800)
Capability LSM initialized as secondary
Checking aperture...
checking if image is initramfs...<7>Switched to high resolution mode on CPU 1
@@ -164,8 +164,6 @@ device-mapper: multipath: version 1.0.5
DMA zone: 2823 pages, LIFO batch:0
DMA zone: 56 pages used for memmap
DMI present.
-dmi_save_oem_strings_devices: out of memory.
-dmi_string: out of memory.
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
e1000e: Copyright (c) 1999-2007 Intel Corporation.
@@ -227,9 +225,9 @@ Initializing XFRM netlink socket
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
input: AT Translated Set 2 keyboard as /class/input/input1
input: ImPS/2 Generic Wheel Mouse as /class/input/input0
-input: PC Speaker as /class/input/input2
+input: PC Speaker as /class/input/input3
input: Power Button (CM) as /class/input/input4
-input: Power Button (FF) as /class/input/input3
+input: Power Button (FF) as /class/input/input2
Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz stepping 0d
IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
io scheduler anticipatory registered
@@ -251,7 +249,7 @@ ldm_parse_tocblock(): Cannot find TOCBLO
libata version 3.00 loaded.
Linux agpgart interface v0.102
Linux Plug and Play Support v0.97 (c) Adam Belay
-Linux version 2.6.24-rc5 ([email protected]) (gcc
version 4.1.2 20070626 (Red Hat 4.1.2-14)) #1 SMP Wed Dec 19 07:39:04
EST 2007
+Linux version 2.6.24-rc5 ([email protected]) (gcc
version 4.1.2 20070626 (Red Hat 4.1.2-14)) #2 SMP Wed Dec 19 11:32:37
EST 2007
Linux video capture interface: v2.00
lo: Disabled Privacy Extensions
lp: driver loaded but no devices found
@@ -450,7 +448,7 @@ TCP bind hash table entries: 65536 (orde
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
-time.c: Detected 2199.952 MHz processor.
+time.c: Detected 2199.958 MHz processor.
Time: tsc clocksource has been installed.
Total HugeTLB memory allocated, 0
TSC calibrated against HPET
Parag
* Parag Warudkar <[email protected]> wrote:
> Here is the right one -
> 2.6.24-rc5 is without patch, 2.6.24-rc5-new is with patch.
> DMI present.
> -dmi_save_oem_strings_devices: out of memory.
> -dmi_string: out of memory.
ok. I guess absent a real regression/bug reported by someone who gets
these messages, we can do your patches in 2.6.25. DMI stuff is quite
hardware dependent so it's hard to get the code tested well.
Ingo
On Dec 19, 2007 12:06 PM, Ingo Molnar <[email protected]> wrote:
>
> * Parag Warudkar <[email protected]> wrote:
>
> > Here is the right one -
> > 2.6.24-rc5 is without patch, 2.6.24-rc5-new is with patch.
>
> > DMI present.
> > -dmi_save_oem_strings_devices: out of memory.
> > -dmi_string: out of memory.
>
> ok. I guess absent a real regression/bug reported by someone who gets
> these messages, we can do your patches in 2.6.25. DMI stuff is quite
> hardware dependent so it's hard to get the code tested well.
>
Yep, I agree.
Andrew if you want to keep it in -mm till 2.6.25 - that'd hopefully
give it some testing.
Parag
* Parag Warudkar <[email protected]> wrote:
> On Dec 19, 2007 12:06 PM, Ingo Molnar <[email protected]> wrote:
> >
> > * Parag Warudkar <[email protected]> wrote:
> >
> > > Here is the right one -
> > > 2.6.24-rc5 is without patch, 2.6.24-rc5-new is with patch.
> >
> > > DMI present.
> > > -dmi_save_oem_strings_devices: out of memory.
> > > -dmi_string: out of memory.
> >
> > ok. I guess absent a real regression/bug reported by someone who gets
> > these messages, we can do your patches in 2.6.25. DMI stuff is quite
> > hardware dependent so it's hard to get the code tested well.
> >
>
> Yep, I agree.
>
> Andrew if you want to keep it in -mm till 2.6.25 - that'd hopefully
> give it some testing.
i've added it to x86.git - that gets included in -mm.
Ingo
On Tue, Dec 18, 2007 at 07:33:00PM -0500, Parag Warudkar wrote:
>
> People with HP Desktops (including me) encounter couple of DMI errors
> during boot - dmi_save_oem_strings_devices: out of memory and dmi_string:
> out of memory.
>
> On some HP desktops the DMI data include OEM strings (type 11) out of which
> only few are meaningful and most other are empty. DMI code religiously
> creates copies of these 27 strings (65ytes each in my case) and goes OOM
> in dmi_string().
>
> If DMI_MAX_DATA is bumped up a little then it goes and fails in
> dmi_save_oem_strings while allocating dmi_devices of sizeof(struct
> dmi_device) corresponding to these strings.
>
> On x86_64 since we cannot use alloc_bootmem this early, the code uses a
FWIW the ff tree has patches to allow "really early allocation" now.
They could be used for this. I didn't implement that for i386 though,
so that would still need some variant of your patch.
Disadvantage right now: e820 memory allocation currently rounds to pages
always. I intend to fix that though because it also wastes memory
with the memnodemap for once.
The forced page rounding was recently added as another bugfix, but that needs
to be reworked.
-Andi
ftp://ftp.firstfloor.org/pub/ak/quilt/patches/early-reserve
ftp://ftp.firstfloor.org/pub/ak/quilt/patches/early-alloc
On Fri, 21 Dec 2007, Andi Kleen wrote:
>
> FWIW the ff tree has patches to allow "really early allocation" now.
> They could be used for this. I didn't implement that for i386 though,
> so that would still need some variant of your patch.
Just to clarify -The allocation failure currently happens only on x86_64 -
on i386 it uses alloc_bootmem and does not fail.
Regardless though this patch is a good idea for both i386 and x86_64 -
there is no point in repeatedly allocating memory for large empty strings
no matter where it comes from, which was the point of this patch.
>
> Disadvantage right now: e820 memory allocation currently rounds to pages
> always. I intend to fix that though because it also wastes memory
> with the memnodemap for once.
>
So looks like currently we have to at least use 4K with these patches -
that would be at least 8 times more than what is actually used after this
patch unless we also fit in some other early alloc in this 4k. I will keep
an eye on the ff tree though - when you get to fix it we can switch all early allocs to use it.
Thanks
Parag