Subject: port-mac68k/6839: Kernel compiled with default options hangs at adb probe
To: None <gnats-bugs@gnats.netbsd.org>
From: Frederick Bruckman <fb@enteract.com>
List: netbsd-bugs
Date: 01/18/1999 11:13:56
>Number: 6839
>Category: port-mac68k
>Synopsis: Kernel compiled with default options hangs at adb probe
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: port-mac68k-maintainer (NetBSD/mac68k Portmaster)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Jan 18 09:35:00 1999
>Last-Modified:
>Originator: Frederick Bruckman
>Organization:
>Release: Jan 16, 1998
>Environment:
System: NetBSD fb.sa.enteract.com 1.3I NetBSD 1.3I (FB) #203:
Fri Jan 15 09:27:34 CST 1999 fredb@fb.sa.enteract.com:
/usr/src/sys/arch/mac68k/compile/FB mac68k
>Description:
Since moving to egcs, kernels compiled with the default -O2 hang
after "adb at obio0" on my Performa 63x. Kernels compiled with
-O are OK; in fact, compiling adb.o, only, with -O is OK. My
first guess is that the stack is being corrupted in one of the
functions called by config_found_sm. This hammers a register or
two on return. Pre-egcs, adb.o didn't use many registers, so it
didn't care; same without -O2.
I do see at least one problem in adb.c, namely where
aa-args.adbaddr, a u_char, is set to adbaddr, an int! I've
tested the following patch against a few different sups in the
past few weeks, and it seems to do the job consistently. Part of
the difficulty is, that even without any change, the symptom
disappears after innocuous changes to other parts of the kernel.
That is, against any given sup, there's about a 50% chance the
bug will manifest. Once you build a kernel with the bug though,
it will absolutely and consistently hang as described.
This also bears on port-mac68k/2568. With this patch, I can
begin moving the mouse continuously after the console appears
without ill effect. (Perhaps not coincidently, the outward
manifestation of that bug is the same as this one.) Moving the
mouse continously, beginning when the kernel is loading, will
still cause the hang, however, so perhaps there's more to it.
>How-To-Repeat:
As above.
>Fix:
--- /sys/arch/mac68k/dev/adbvar.h.orig Mon Dec 28 11:19:21 1998
+++ /sys/arch/mac68k/dev/adbvar.h Mon Dec 28 11:43:46 1998
@@ -91,7 +91,7 @@
int adb_poweroff __P((void));
int CountADBs __P((void));
void ADBReInit __P((void));
-int GetIndADB __P((ADBDataBlock * info, int index));
+u_char GetIndADB __P((ADBDataBlock * info, int index));
int GetADBInfo __P((ADBDataBlock * info, int adbAddr));
int SetADBInfo __P((ADBSetInfoBlock * info, int adbAddr));
int ADBOp __P((Ptr buffer, Ptr compRout, Ptr data, short commandNum));
--- /sys/arch/mac68k/dev/adb.c.orig Mon Dec 28 11:19:23 1998
+++ /sys/arch/mac68k/dev/adb.c Mon Dec 28 11:43:47 1998
@@ -102,8 +102,9 @@
{
ADBDataBlock adbdata;
struct adb_attach_args aa_args;
+ u_char adbaddr;
int totaladbs;
- int adbindex, adbaddr;
+ int adbindex;
#ifdef MRG_ADB
/*
--- /sys/arch/mac68k/dev/adb_direct.c.orig Mon Dec 28 11:19:25 1998
+++ /sys/arch/mac68k/dev/adb_direct.c Tue Dec 29 13:09:32 1998
@@ -290,7 +290,7 @@
void adb_op_comprout __P((void));
void adb_reinit __P((void));
int count_adbs __P((void));
-int get_ind_adb_info __P((ADBDataBlock *, int));
+u_char get_ind_adb_info __P((ADBDataBlock *, int));
int get_adb_info __P((ADBDataBlock *, int));
int set_adb_info __P((ADBSetInfoBlock *, int));
void adb_setup_hw_type __P((void));
@@ -2002,7 +2002,8 @@
{
u_char send_string[ADB_MAX_MSG_LENGTH];
int s = 0;
- volatile int i, x;
+ volatile int i;
+ volatile u_char x;
int command;
int result;
int saveptr; /* point to next free relocation address */
@@ -2508,7 +2509,7 @@
return found;
}
-int
+u_char
get_ind_adb_info(ADBDataBlock * info, int index)
{
if ((index < 1) || (index > 15)) /* check range 1-15 */
@@ -2822,7 +2823,7 @@
adb_reinit();
}
-int
+u_char
GetIndADB(ADBDataBlock * info, int index)
{
return (get_ind_adb_info(info, index));
>Audit-Trail:
>Unformatted: