[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-users:00844] [mantel@xxxxxxx: Re: bzImage kernels don't boot on some hardware]



 吉山です。

 ThinkPad で debian がインストールできないというのが kernel-ml
にも流れました。対処法も流れたので近く解決されるでしょう。
 以下はその対処法です。

------- Forwarded Message

Seen: 
Return-Path: owner-linux-kernel-outgoing@xxxxxxxxxxxxxxxx
Return-Path: owner-linux-kernel-outgoing@xxxxxxxxxxxxxxxx
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by jedi.seg.kobe-u.ac.jp (8.8.5+2.7Wbeta5/3.5Wpl3) with ESMTP id TAA00300 for <yosshy@xxxxxxxxxxxxxxxxxxxxx>; Sun, 22 Jun 1997 19:03:09 +0900 (JST)
Received: from root@xxxxxxxxxxxxxxxx (port 14884 [128.6.190.2]) by nic.funet.fi with ESMTP id <2787-31789>; Sun, 22 Jun 1997 13:01:32 +0300
Received: by vger.rutgers.edu id <972181-307>; Sun, 22 Jun 1997 05:49:28 -0400
Received: from Galois.fs100.suse.de ([193.141.17.193]) by vger.rutgers.edu with ESMTP id <971912-311>; Sun, 22 Jun 1997 05:46:00 -0400
Received: from localhost (mantel@localhost)
          by Galois.fs100.suse.de (8.8.4/8.8.4) with SMTP
	  id LAA26619; Sun, 22 Jun 1997 11:47:24 +0200
Date: 	Sun, 22 Jun 1997 11:47:24 +0200 (MEST)
From: Hubert Mantel <mantel@xxxxxxx>
X-Sender: mantel@xxxxxxxxxxxxxxxxxxxx
To: Bruce Perens <bruce-1268@xxxxxxxxxxxxxxxxx>
cc: linux-kernel@xxxxxxxxxxxxxxxx
Subject: Re: bzImage kernels don't boot on some hardware
In-Reply-To: <m0wffdz-00J4hTC@xxxxxxxxxxxxxxx>
Message-ID: <Pine.LNX.3.95.970622113808.26084B-100000@xxxxxxxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-kernel@xxxxxxxxxxxxxxxx
Precedence: bulk

Hello,

On Sat, 21 Jun 1997, Bruce Perens wrote:

> Debian 1.3 uses a bzImage kernel on its installation floppy. I have reports
> from a number of users that bzImage kernels don't boot on their hardware from
> either floppy or hard disk, but zImage kernels do. One of these users has an
> IBM ThinkPad 365X 16MB. I'm tracking down what the others have.
> 
> Has anyone seen this?

Yes, it's a known problem. Interestingly, using loadlin instead of lilo
helps on most of the affected machines. Disabling caches and/or adding
waitstates may help on some machines, too.

There exists a kernel patch from Jens Maurer which cures the problem on
some of the machines, but not on all.

> 	Thanks
> 
> 	Bruce

      Hubert mantel@xxxxxxx

-----------------------------------------------------------------------
--- linux/arch/i386/boot/setup.S.old	Sat Mar 30 19:58:57 1996
+++ linux/arch/i386/boot/setup.S	Thu Aug  8 11:50:32 1996
@@ -446,10 +449,7 @@
 			! now we are at the right place
 end_move_self:
 
-	lidt	idt_48		! load idt with 0,0
-	lgdt	gdt_48		! load gdt with whatever appropriate
-
-! that was painless, now we enable A20
+! now we enable A20
 
 	call	empty_8042
 	mov	al,#0xD1		! command write
@@ -458,6 +458,32 @@
 	mov	al,#0xDF		! A20 on
 	out	#0x60,al
 	call	empty_8042
+
+! On some machines, there are cache coherency problems with
+! addresses above 0x100000 after enabling the A20 gate.
+! ( observed on a Toshiba Tecra 710CDT )
+! The cache still contains invalid data for the new situation,
+! because 0x100000 is no longer an alias for 0x000000.
+! To deal with this we just read some bytes silently and hope that
+! the cache is reloaded afterwards. (Jens Maurer)
+	seg cs
+	test	byte ptr loadflags,#LOADED_HIGH
+	jz	end_cache_kludge
+	mov	ax,#0xffff	! ds:si = 0x100000
+	mov	ds,ax
+	mov	si,#0x10
+	cld
+	mov	cx,#0x2000	! 16 KB
+	rep
+	lodsw
+	mov	ax,cs
+	mov	ds,ax		! restore DS
+end_cache_kludge:
+
+! setup descriptor tables
+
+	lidt	idt_48		! load idt with 0,0
+	lgdt	gdt_48		! load gdt with whatever appropriate
 
 ! make sure any possible coprocessor is properly reset..
-----------------------------------------------------------------------



------- End of Forwarded Message

---

  name   : 吉山あきら (Akira Yoshiyama)
  e-mail : yosshy@xxxxxxxxxxxxxxxxxxxxx, yosshy@xxxxxxxxxxxxxxx
  URL    : http://jedi.seg.kobe-u.ac.jp/~yosshy/linux.html