* [PATCH] x86: Fix DMI out of memory problems
@ 2007-12-19 0:33 Parag Warudkar
2007-12-19 10:48 ` Ingo Molnar
2007-12-21 13:41 ` Andi Kleen
0 siblings, 2 replies; 10+ messages in thread
From: Parag Warudkar @ 2007-12-19 0:33 UTC (permalink / raw)
To: linux-kernel; +Cc: mingo, akpm, torvalds, ak
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 <parag.warudkar@gmail.com>
--- 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);
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] x86: Fix DMI out of memory problems 2007-12-19 0:33 [PATCH] x86: Fix DMI out of memory problems Parag Warudkar @ 2007-12-19 10:48 ` Ingo Molnar 2007-12-19 16:48 ` Parag Warudkar 2007-12-21 13:41 ` Andi Kleen 1 sibling, 1 reply; 10+ messages in thread From: Ingo Molnar @ 2007-12-19 10:48 UTC (permalink / raw) To: Parag Warudkar Cc: linux-kernel, akpm, torvalds, ak, Thomas Gleixner, H. Peter Anvin * Parag Warudkar <parag.warudkar@gmail.com> 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 <parag.warudkar@gmail.com> 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 <parag.warudkar@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> --- 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); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] x86: Fix DMI out of memory problems 2007-12-19 10:48 ` Ingo Molnar @ 2007-12-19 16:48 ` Parag Warudkar 2007-12-19 16:54 ` Ingo Molnar 0 siblings, 1 reply; 10+ messages in thread From: Parag Warudkar @ 2007-12-19 16:48 UTC (permalink / raw) To: Ingo Molnar Cc: linux-kernel, akpm, torvalds, ak, Thomas Gleixner, H. Peter Anvin On Dec 19, 2007 5:48 AM, Ingo Molnar <mingo@elte.hu> wrote: > > * Parag Warudkar <parag.warudkar@gmail.com> 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 (root@pavillion.hsd1.mi.comcast.net) (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 (parag@pavillion.hsd1.mi.comcast.net) (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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] x86: Fix DMI out of memory problems 2007-12-19 16:48 ` Parag Warudkar @ 2007-12-19 16:54 ` Ingo Molnar 2007-12-19 17:00 ` Parag Warudkar 0 siblings, 1 reply; 10+ messages in thread From: Ingo Molnar @ 2007-12-19 16:54 UTC (permalink / raw) To: Parag Warudkar Cc: linux-kernel, akpm, torvalds, ak, Thomas Gleixner, H. Peter Anvin * Parag Warudkar <parag.warudkar@gmail.com> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] x86: Fix DMI out of memory problems 2007-12-19 16:54 ` Ingo Molnar @ 2007-12-19 17:00 ` Parag Warudkar 2007-12-19 17:06 ` Ingo Molnar 0 siblings, 1 reply; 10+ messages in thread From: Parag Warudkar @ 2007-12-19 17:00 UTC (permalink / raw) To: Ingo Molnar Cc: linux-kernel, akpm, torvalds, ak, Thomas Gleixner, H. Peter Anvin On Dec 19, 2007 11:54 AM, Ingo Molnar <mingo@elte.hu> wrote: > > * Parag Warudkar <parag.warudkar@gmail.com> 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 (parag@pavillion.hsd1.mi.comcast.net) (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 (parag@pavillion.hsd1.mi.comcast.net) (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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] x86: Fix DMI out of memory problems 2007-12-19 17:00 ` Parag Warudkar @ 2007-12-19 17:06 ` Ingo Molnar 2007-12-19 17:09 ` Parag Warudkar 0 siblings, 1 reply; 10+ messages in thread From: Ingo Molnar @ 2007-12-19 17:06 UTC (permalink / raw) To: Parag Warudkar Cc: linux-kernel, akpm, torvalds, ak, Thomas Gleixner, H. Peter Anvin * Parag Warudkar <parag.warudkar@gmail.com> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] x86: Fix DMI out of memory problems 2007-12-19 17:06 ` Ingo Molnar @ 2007-12-19 17:09 ` Parag Warudkar 2007-12-19 17:56 ` Ingo Molnar 0 siblings, 1 reply; 10+ messages in thread From: Parag Warudkar @ 2007-12-19 17:09 UTC (permalink / raw) To: Ingo Molnar Cc: linux-kernel, akpm, torvalds, ak, Thomas Gleixner, H. Peter Anvin On Dec 19, 2007 12:06 PM, Ingo Molnar <mingo@elte.hu> wrote: > > * Parag Warudkar <parag.warudkar@gmail.com> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] x86: Fix DMI out of memory problems 2007-12-19 17:09 ` Parag Warudkar @ 2007-12-19 17:56 ` Ingo Molnar 0 siblings, 0 replies; 10+ messages in thread From: Ingo Molnar @ 2007-12-19 17:56 UTC (permalink / raw) To: Parag Warudkar Cc: linux-kernel, akpm, torvalds, ak, Thomas Gleixner, H. Peter Anvin * Parag Warudkar <parag.warudkar@gmail.com> wrote: > On Dec 19, 2007 12:06 PM, Ingo Molnar <mingo@elte.hu> wrote: > > > > * Parag Warudkar <parag.warudkar@gmail.com> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] x86: Fix DMI out of memory problems 2007-12-19 0:33 [PATCH] x86: Fix DMI out of memory problems Parag Warudkar 2007-12-19 10:48 ` Ingo Molnar @ 2007-12-21 13:41 ` Andi Kleen 2007-12-21 16:31 ` Parag Warudkar 1 sibling, 1 reply; 10+ messages in thread From: Andi Kleen @ 2007-12-21 13:41 UTC (permalink / raw) To: Parag Warudkar; +Cc: linux-kernel, mingo, akpm, torvalds, ak 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] x86: Fix DMI out of memory problems 2007-12-21 13:41 ` Andi Kleen @ 2007-12-21 16:31 ` Parag Warudkar 0 siblings, 0 replies; 10+ messages in thread From: Parag Warudkar @ 2007-12-21 16:31 UTC (permalink / raw) To: Andi Kleen; +Cc: Parag Warudkar, linux-kernel, mingo, akpm, torvalds 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-12-21 16:32 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-12-19 0:33 [PATCH] x86: Fix DMI out of memory problems Parag Warudkar 2007-12-19 10:48 ` Ingo Molnar 2007-12-19 16:48 ` Parag Warudkar 2007-12-19 16:54 ` Ingo Molnar 2007-12-19 17:00 ` Parag Warudkar 2007-12-19 17:06 ` Ingo Molnar 2007-12-19 17:09 ` Parag Warudkar 2007-12-19 17:56 ` Ingo Molnar 2007-12-21 13:41 ` Andi Kleen 2007-12-21 16:31 ` Parag Warudkar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.