mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Oops in dmi_table() from Linux 2.4.7
@ 2001-08-02 11:57 Lars Aronsson
  0 siblings, 0 replies; 2+ messages in thread
From: Lars Aronsson @ 2001-08-02 11:57 UTC (permalink / raw)
  To: linux-kernel

Hi guys,

I tried to compile and boot a fresh linux-2.4.7 kernel, and I got an
"Unable to handle kernel paging request" during boot, at EIP
0010:[<c02491d1>].  The docs tell me to run "nm vmlinux" to find the
address, but I didn't get this to work on my "bzImage", so instead I
looked in System.map, which indicates the problem is in dmi_table():

    c0249090 t winchip_mcheck_init
    c02490cc T mcheck_init
    c0249110 t mcheck_disable
    c0249120 t dmi_string
    c0249160 t dmi_table
    c0249210 T dmi_iterate
    c02492f0 t dmi_save_ident
    c024936c t disable_ide_dma

The "Call Trace: [<c0105037>][<c0105454>]" seems to indicate init()
and kernel_thread(), respectively, which I geuss is not very helpful.

dmi_table() is in arch/i386/kernel/dmi_scan.c which was not present in
my old 2.2.16 kernel.  The file doesn't have any comments indicating
who wrote it.

Hope you can use this for something.  Will you be helped if I enable
dmi_printk() and try this again?

This happened on a Toshiba Portege 7020CT with a Pentium II processor.


Lars Aronsson.
-- 
  Aronsson Datateknik
  Teknikringen 1e              tel +46-70-7891609     lars@aronsson.se
  SE-583 30 Linköping, Sweden  fax +46-13-211820    http://aronsson.se

^ permalink raw reply	[flat|nested] 2+ messages in thread
* Oops in dmi_table() from Linux 2.4.7
@ 2001-08-02 15:16 Lars Aronsson
  0 siblings, 0 replies; 2+ messages in thread
From: Lars Aronsson @ 2001-08-02 15:16 UTC (permalink / raw)
  To: linux-kernel


Hi guys, it's me again,


My previously reported problem has its roots here:

	Linux 2.4.7
	file arch/i386/kernel/dmi_scan.c
	function dmi_table()
	the if() statement for breaking out of the loop.

What happened on my hardware is that dm->type == 255 (this happens the
very first time these statements are executed), which I guess
indicates that there are no DMI data on my hardware/BIOS.  The type of
dm->type is u8, which means the loop is not broken.  I have no idea
about the DMI specs, so I don't know how other values of dm->type
should be interpreted.  The function dmi_decode() only uses 0,1,2,3.
A simple cast to signed char fixed the problem for me:

	if (((signed char)dm->type) < last) break;

Again, my hardware is a Toshiba Portege 7020CT.  I think I did some
BIOS update when I first installed support for the Dock II docking
station, but I won't care to dig up bios version info unless you say
you need it.

Again, hope you can use this.


Lars Aronsson.
-- 
  Aronsson Datateknik
  Teknikringen 1e              tel +46-70-7891609     lars@aronsson.se
  SE-583 30 Linköping, Sweden  fax +46-13-211820    http://aronsson.se

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-08-02 15:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-02 11:57 Oops in dmi_table() from Linux 2.4.7 Lars Aronsson
2001-08-02 15:16 Lars Aronsson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®