[chris@onthe.net.au: Re: linux-kernel]

David S. Miller (davem@jenolan.rutgers.edu)
Fri, 25 Apr 1997 01:52:56 -0400


------- Start of forwarded message -------
From: Chris Dunlop <chris@onthe.net.au>
Subject: Re: linux-kernel
To: davem@jenolan.rutgers.edu (David S. Miller)
Date: Fri, 25 Apr 1997 15:52:06 +1000 (EST)
In-Reply-To: <199704160320.XAA01912@jenolan.caipgeneral> from "David S. Miller" at Apr 15, 97 11:20:15 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi David,

I'm still having no luck getting this message on the linux-kernel list.

Sorry to be a pain, but could you please forward this onto the list
for me ?

Thanks,

Chris.

> From chris Mon Mar 31 23:41:14 1997
> Subject: Help! jiffies oddness in keyboard.c ?
> To: linux-kernel@vger.rutgers.edu
> Date: Mon, 31 Mar 1997 23:41:14 +1000 (EST)
> X-Mailer: ELM [version 2.4 PL25]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Length: 4162
>
> Hi,
>
> I've been having a devil of a time trying to get an oldish 486-DX50
> to boot... this is with 2.0.27 and 2.0.29, trying to install linux
> on a brand new partition.
>
> The machine has a DTK bios, version 4.51. which I suspect may be the
> cause of my problem. Not that I know a lot (or anything actually) about
> how the bios integrates with the kernel, but it doesn't look like
> 'standard' bioses when it boots e.g. no splash screen showing installed
> devices etc. Oh yeah, it boots and runs dos/win95. As if that mattered.
>
> I'm trying to boot from floppy: originally I was trying a RedHat 2.0.27
> boot thingummy, but then I got to roll my own on another linux box.
>
> The original problem was a freeze during the initialization of the ide
> controller: I'd get a 'Ramdisk initialized' message and then nothing.
>
> I took out all unessential hardware leaving just the motherboard, 32Mb,
> keyboard, super I/O card with only ide and floppy enabled, and the
> harddrive. I also tried mem=16M when booting.
>
> No difference: hang after the ramdisk message appears, when it should be
> doing the ide stuff.
>
> I poked around and put in some printk's and reduced the problem to a
> call to delay_50ms() in drivers/block/ide.c:
>
> static void delay_50ms (void)
> {
> unsigned long timer = jiffies + ((HZ + 19)/20) + 1;
> while (timer > jiffies);
> }
>
> The thing was getting into the routine but never coming out. At first I
> thought 'Ah-ha! This code is obviously wrong - how can we ever break
> out of the loop ?!?'. (This shows my level of kernel expertise: none.)
> After getting all excited at finding a kernel bug I settled down and
> worked out that jiffies should be incrementing in an interrupt handler.
> OK, so then what ?
>
> I hacked and hacked (if you can call inserting a whole lot of printk's
> hacking) and reduced the problem to drivers/char/keyboard.c. At the end
> of keyboard.c:kbd_init() there is the following fragment:
>
> #ifdef INIT_KBD
> initialize_kbd();
> #endif
> init_bh(KEYBOARD_BH, kbd_bh);
> mark_bh(KEYBOARD_BH);
> return 0;
> }
>
> The init_bh() routine is an inline, defined in include/linux/interrupt.h:
>
> extern inline void init_bh(int nr, void (*routine)(void))
> {
> bh_base[nr] = routine;
> bh_mask_count[nr] = 0;
> bh_mask |= 1 << nr;
> }
>
> It seems that prior to setting bh_mask, jiffies are being incremented as
> expected, but after setting bh_mask they're not.
>
> This assertion is based on the following evidence:
>
> Based on the delay_50ms code above, I put the following near the top
> of keyboard.c:
>
> #define DBGDELAY { \
> unsigned long timer = jiffies + 6; \
> printk("%s:%d timer = %lu, jiffies = %lu\n", \
> __FILE__, __LINE__, timer, jiffies); \
> while (timer > jiffies); \
> printk("%s:%d done (timer = %lu, jiffies = %lu)\n", \
> __FILE__, __LINE__, timer, jiffies); \
> }
>
> Then I manually expanded the call to init_bh() in kbd_init() and put in
> some debug stuff:
>
> #ifdef INIT_KBD
> initialize_kbd();
> #endif
> bh_base[KEYBOARD_BH] = kbd_bh;
> bh_mask_count[KEYBOARD_BH] = 0;
> printk("%s:%d bh_mask = %#lx\n", __FILE__, __LINE__, bh_mask);
> DBGDELAY
> bh_mask |= 1 << KEYBOARD_BH;
> printk("%s:%d bh_mask = %#lx\n", __FILE__, __LINE__, bh_mask);
> DBGDELAY /* never comes out */
> mark_bh(KEYBOARD_BH);
> DBGDELAY
> return 0;
> }
>
> The output of this was:
>
> keyboard.c:1218 bh_mask = 0x107
> keyboard.c:1219 timer = 41, jiffies = 35
> keyboard.c:1219 done (timer = 41, jiffies = 41)
> keyboard.c:1221 bh_mask = 0x107
> keyboard.c:1222 timer = 47, jiffies = 41
> >>> hang <<<
>
> It seems that DBGDELAY works fine prior to bh_mask being set, but after
> bh_mask is set I never get out of the 'while (timer > jiffies);' loop.
>
> I made an attempt at going further than this, but I have _no_ idea
> how/when/why interrupts happen and how they are dispatched and handled
> in the PC architecture so I've reached the limits of what I can do by
> myself.
>
> Oh... I tried this same debug kernel/boot floppy on another machine (a
> P120) and it works fine.
>
>
> Does anyone know where I can go from here ?
>
>
> Regards,
>
> Chris.
>
------- End of forwarded message -------