Messages in this thread Patch in this message | | | Date | Thu, 12 Aug 1999 22:19:14 +0200 | From | Manfred Spraul <> | Subject | Re: 2.3.12 - klogd 100%CPU |
| |
Andrea Arcangeli wrote: > > There's no one difference in returning random data or writing nothing to > the buffer. If you really want to fix this minor issue at the expense of > allocing a tmp-kernel buffer see the below patch. But now my solution is far better. Alloc memory, check that you have enough mem, realloc otherwise, ... All I have to do is copy the data from the end to the beginning, then I stop automagically as soon as I collide with parallel printk()'s.
> >* register_console(CON_PRINTBUFFER) could use the wrong msg_level for > >the first line. > I think you are wrong. The current code seems fine.
After a wrap-around, the first line could be incomplete. This means that the first line does not start with a "<?>", and thus the line "msg_level = buf[1] - '0';" is not perfect. [I use default_message_loglevel for a incomplete first line]. It's not important.
Btw, what about adding something like this to your IKD kernel? >>>>>>>>> --- 2.3/include/asm-i386/spinlock.h Sat Jun 26 11:52:55 1999 +++ build-2.3/include/asm-i386/spinlock.h Thu Aug 12 19:27:00 1999 @@ -7,7 +7,7 @@ * <linux/spinlock.h> with all of this. Oh, well. */ #define spin_lock_irqsave(lock, flags) do { local_irq_save(flags); spin_lock(lock); } while (0) -#define spin_lock_irq(lock) do { local_irq_disable(); spin_lock(lock); } while (0) +#define spin_lock_irq(lock) do { unsigned long flags; local_irq_save(flags); if( (flags&(1<<9)) ==0) printk("spinlock bad: %lxh\n",lock); spin_lock(lock); } while (0) #define spin_lock_bh(lock) do { local_bh_disable(); spin_lock(lock); } while (0) #define read_lock_irqsave(lock, flags) do { local_irq_save(flags); read_lock(lock); } while (0) <<<<<<<<< I tried this, and I only found the spin_lock_irq(&runqueue_lock) -call in sched.c, line 679. [This is not a bug. do_bottom_half always returns with interrupts disabled even if it was called with interrupts enabled.]
-- Manfred
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |