Re: your mail
On Sun, Mar 11, 2001 at 09:03:09PM -0800, Greg KH wrote: > On Sun, Mar 11, 2001 at 06:06:24PM +0100, Martin Bruchanov wrote: > > > > Bug report from Martin Bruchanov ([EMAIL PROTECTED], [EMAIL PROTECTED]) > > > > > > [1.] One line summary of the problem: > > USB doesn't work properly with SMP kernel on dual-mainboard or with APIC. > > What kind of motherboard is this? > >From the lspci output, looks like I have the same mainboard or at least one with an identical chipset. I've got an MSI 694D Pro Mainboard with 694X VIA chipset, with 2 cpus installed, and I had the same USB problem with 2.4.0, but haven't had time to test it on a recent kernel. robert > And does USB work in SMP mode with "noapic" given on the kernel command > line? > > thanks, > > greg k-h > > -- > greg@(kroah|wirex).com > http://immunix.org/~greg > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
On Sat, Mar 10, 2001 at 01:21:25AM +1100, Andrew Morton wrote:
> +static atomic_t nmi_watchdog_enabled = ATOMIC_INIT(0); /* 0 == enabled */
> +
> +void enable_nmi_watchdog(int yes)
> +{
> + if (yes)
> + atomic_inc(_watchdog_enabled);
> + else
> + atomic_dec(_watchdog_enabled);
> +}
>
> void nmi_watchdog_tick (struct pt_regs * regs)
> {
> @@ -255,7 +264,7 @@
>
> sum = apic_timer_irqs[cpu];
>
> - if (last_irq_sums[cpu] == sum) {
> + if (last_irq_sums[cpu] == sum && atomic_read(_watchdog_enabled) == 0) {
Shouldn't that be atomic_read(_watchdog_enabled) != 0?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] serial console vs NMI watchdog
On Sat, Mar 10, 2001 at 01:21:25AM +1100, Andrew Morton wrote:
+static atomic_t nmi_watchdog_enabled = ATOMIC_INIT(0); /* 0 == enabled */
+
+void enable_nmi_watchdog(int yes)
+{
+ if (yes)
+ atomic_inc(nmi_watchdog_enabled);
+ else
+ atomic_dec(nmi_watchdog_enabled);
+}
void nmi_watchdog_tick (struct pt_regs * regs)
{
@@ -255,7 +264,7 @@
sum = apic_timer_irqs[cpu];
- if (last_irq_sums[cpu] == sum) {
+ if (last_irq_sums[cpu] == sum atomic_read(nmi_watchdog_enabled) == 0) {
Shouldn't that be atomic_read(nmi_watchdog_enabled) != 0?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
On Mon, Mar 05, 2001 at 10:05:36PM +0100, Pozsar Balazs wrote:
> On Mon, 5 Mar 2001, Robert Read wrote:
> > On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
> > >
> > > And what does POSIX say about "#!/bin/sh\r" ?
> > > In other words: should the kernel look for the interpreter between the !
> > > and the newline, or [the first space or newline] or the first whitespace?
> > >
> > > IMHO, the first whitespace. Which means that "#!/bin/sh\r" should invoke
> > > /bin/sh. (though it is junk).
> >
> > The line terminator, '\n', is what terminates the interpreter. White
> > space (in this case, only ' ' and '\t') is used to seperate the
> ^
> > arguments to the interpreter.
>
>
> The last little tiny thing that bothers me: why? Why only ' ' and '\t' _in
> this case_? As someone mentioned, even isspace() returns whitespace.
>
> A possible answer (that i can think of), is that those ar the whitespaces,
> which are in IFS (as said previously), taking out us from kernel-space
> into userspace. But imho we shouldn't define another set whitespace for
> this case, can't we just use what isspace() says?
And isspace('\n') is also true. At question here is not the
definition of whitespace. The question is, what is the definition of
a command line? What characters are valid command line seperators?
robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote: > > And what does POSIX say about "#!/bin/sh\r" ? > In other words: should the kernel look for the interpreter between the ! > and the newline, or [the first space or newline] or the first whitespace? > > IMHO, the first whitespace. Which means that "#!/bin/sh\r" should invoke > /bin/sh. (though it is junk). > The line terminator, '\n', is what terminates the interpreter. White space (in this case, only ' ' and '\t') is used to seperate the arguments to the interpreter. This allows scripts to pass args to intepreters, as in #!/usr/bin/per -w or #!/usr/bin/env perl -w So is '\r' a line terminator? For Linux, no. Should '\r' seperate arguments? No, that would be very strange. robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote: And what does POSIX say about "#!/bin/sh\r" ? In other words: should the kernel look for the interpreter between the ! and the newline, or [the first space or newline] or the first whitespace? IMHO, the first whitespace. Which means that "#!/bin/sh\r" should invoke /bin/sh. (though it is junk). The line terminator, '\n', is what terminates the interpreter. White space (in this case, only ' ' and '\t') is used to seperate the arguments to the interpreter. This allows scripts to pass args to intepreters, as in #!/usr/bin/per -w or #!/usr/bin/env perl -w So is '\r' a line terminator? For Linux, no. Should '\r' seperate arguments? No, that would be very strange. robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
On Mon, Mar 05, 2001 at 10:05:36PM +0100, Pozsar Balazs wrote:
On Mon, 5 Mar 2001, Robert Read wrote:
On Mon, Mar 05, 2001 at 07:58:52PM +0100, Pozsar Balazs wrote:
And what does POSIX say about "#!/bin/sh\r" ?
In other words: should the kernel look for the interpreter between the !
and the newline, or [the first space or newline] or the first whitespace?
IMHO, the first whitespace. Which means that "#!/bin/sh\r" should invoke
/bin/sh. (though it is junk).
The line terminator, '\n', is what terminates the interpreter. White
space (in this case, only ' ' and '\t') is used to seperate the
^
arguments to the interpreter.
The last little tiny thing that bothers me: why? Why only ' ' and '\t' _in
this case_? As someone mentioned, even isspace() returns whitespace.
A possible answer (that i can think of), is that those ar the whitespaces,
which are in IFS (as said previously), taking out us from kernel-space
into userspace. But imho we shouldn't define another set whitespace for
this case, can't we just use what isspace() says?
And isspace('\n') is also true. At question here is not the
definition of whitespace. The question is, what is the definition of
a command line? What characters are valid command line seperators?
robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] set kiobuf io_count once, instead of increment
On Tue, Feb 27, 2001 at 10:50:54PM -0300, Marcelo Tosatti wrote: > > > It seems your patch breaks bh allocation failure handling. If > get_unused_buffer_head() fails, iobuf->io_count never reaches 0, so > processes waiting on kiobuf_wait_for_io() will block forever. > This is true, but it looks like the brw_kiovec allocation failure handling is broken already; it's calling __put_unused_buffer_head on bhs without waiting for them to complete first. Also, the err won't be returned if the previous batch of bhs finished ok. It looks like brw_kiovec needs some work, but I'm going to need some coffee first... robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] set kiobuf io_count once, instead of increment
On Tue, Feb 27, 2001 at 10:50:54PM -0300, Marcelo Tosatti wrote: It seems your patch breaks bh allocation failure handling. If get_unused_buffer_head() fails, iobuf-io_count never reaches 0, so processes waiting on kiobuf_wait_for_io() will block forever. This is true, but it looks like the brw_kiovec allocation failure handling is broken already; it's calling __put_unused_buffer_head on bhs without waiting for them to complete first. Also, the err won't be returned if the previous batch of bhs finished ok. It looks like brw_kiovec needs some work, but I'm going to need some coffee first... robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] set kiobuf io_count once, instead of increment
Currently in brw_kiovec, iobuf->io_count is being incremented as each
bh is submitted, and decremented in the bh->b_end_io(). This means
io_count can go to zero before all the bhs have been submitted,
especially during a large request. This causes the end_kio_request()
to be called before all of the io is complete.
This suggested patch against 2.4.2 sets io_count to the total amount
before the bhs are submitted, although there is probably a better way
to determine the io_count than this.
robert
diff -ru linux/fs/buffer.c linux-rm/fs/buffer.c
--- linux/fs/buffer.c Mon Jan 15 12:42:32 2001
+++ linux-rm/fs/buffer.cTue Jan 30 11:41:57 2001
@@ -2085,6 +2085,7 @@
offset = iobuf->offset;
length = iobuf->length;
iobuf->errno = 0;
+ atomic_set(>io_count, length/size);
for (pageind = 0; pageind < iobuf->nr_pages; pageind++) {
map = iobuf->maplist[pageind];
@@ -2119,8 +2120,6 @@
bh[bhind++] = tmp;
length -= size;
offset += size;
-
- atomic_inc(>io_count);
submit_bh(rw, tmp);
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] set kiobuf io_count once, instead of increment
Currently in brw_kiovec, iobuf-io_count is being incremented as each
bh is submitted, and decremented in the bh-b_end_io(). This means
io_count can go to zero before all the bhs have been submitted,
especially during a large request. This causes the end_kio_request()
to be called before all of the io is complete.
This suggested patch against 2.4.2 sets io_count to the total amount
before the bhs are submitted, although there is probably a better way
to determine the io_count than this.
robert
diff -ru linux/fs/buffer.c linux-rm/fs/buffer.c
--- linux/fs/buffer.c Mon Jan 15 12:42:32 2001
+++ linux-rm/fs/buffer.cTue Jan 30 11:41:57 2001
@@ -2085,6 +2085,7 @@
offset = iobuf-offset;
length = iobuf-length;
iobuf-errno = 0;
+ atomic_set(iobuf-io_count, length/size);
for (pageind = 0; pageind iobuf-nr_pages; pageind++) {
map = iobuf-maplist[pageind];
@@ -2119,8 +2120,6 @@
bh[bhind++] = tmp;
length -= size;
offset += size;
-
- atomic_inc(iobuf-io_count);
submit_bh(rw, tmp);
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] use correct include dir for build tools
Ok, my bad, I forgot about cross-compiles. The problem was scripts/split-include.c includes errno.h, which requires linux/errno.h to exist, and I thought it would be better to use the current kernel's version, rather than the system version. I guess not. robert On Thu, Feb 22, 2001 at 10:28:58PM +, Alan Cox wrote: > > FINDHPATH = $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net > > > > HOSTCC = gcc > > -HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer > > +HOSTCFLAGS = -I$(HPATH) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer > > That seems odd. Which build tools need to find kernel includes for this kernel > not the standard C includes > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] use correct include dir for build tools
Ok, my bad, I forgot about cross-compiles. The problem was scripts/split-include.c includes errno.h, which requires linux/errno.h to exist, and I thought it would be better to use the current kernel's version, rather than the system version. I guess not. robert On Thu, Feb 22, 2001 at 10:28:58PM +, Alan Cox wrote: FINDHPATH = $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net HOSTCC = gcc -HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +HOSTCFLAGS = -I$(HPATH) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer That seems odd. Which build tools need to find kernel includes for this kernel not the standard C includes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: newbie fodder
This looks great, in fact I was working on something similar for myself. Unfortunately, like all good documentation, it's already slightly out of date. Just this morning I noticed that as of the 2.4.2-preX, the __make_request function no longer contains this code: if (!q->plugged) q->request_fn(q); I don't know why the change was made, and I have not yet found where how q->request_fn gets called for non-plugged request queues, but since this is one of the key steps of the whole process, it will be great to keep this documentation current. robert On Wed, Feb 21, 2001 at 11:23:51PM +0100, [EMAIL PROTECTED] wrote: > For a beginner I recently wrote a tiny demonstration > of what the kernel does, given a trivial user program. > Now that it served its purpose it would be a pity to > throw it out again, maybe it can be useful to someone else. > > See > http://www.win.tue.nl/~aeb/linux/vfs/trail-1.html > > Andries > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: newbie fodder
This looks great, in fact I was working on something similar for myself. Unfortunately, like all good documentation, it's already slightly out of date. Just this morning I noticed that as of the 2.4.2-preX, the __make_request function no longer contains this code: if (!q-plugged) q-request_fn(q); I don't know why the change was made, and I have not yet found where how q-request_fn gets called for non-plugged request queues, but since this is one of the key steps of the whole process, it will be great to keep this documentation current. robert On Wed, Feb 21, 2001 at 11:23:51PM +0100, [EMAIL PROTECTED] wrote: For a beginner I recently wrote a tiny demonstration of what the kernel does, given a trivial user program. Now that it served its purpose it would be a pity to throw it out again, maybe it can be useful to someone else. See http://www.win.tue.nl/~aeb/linux/vfs/trail-1.html Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can somebody explain how linux support 64G memory
There are two ways, the PAE flag and the PSE-36 feature introduced in P3. These extensions are documented in the IA-32 Intel Architecture Software Developer's Manuals, which you can find here: http://developer.intel.com/design/Pentium4/manuals/ Look in Volume 3, Chapter 3 for this info. robert On Wed, Feb 21, 2001 at 10:44:30AM +0800, michaelc wrote: > Hi, >How does linux support more than 4G memory? I 've read the >documentation of Intel IA-32 Architecture, I knew that OS >just address up to 4G physical address space, If OS want to >access additional 4-GByte section of physical memory, it must >change the pointer in register CR3 or entries in the >page-directory-pointer table. That means that Linux just has >up to 4-GByte page mapping at one time , is that right? > > > > -- > Best regards, > michael chen mailto:[EMAIL PROTECTED] > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] configurable printk buffer size
The obvious solution struck me just after the last email. I change the config parameter to be an order, like the argument to get_free_pages(). How does this look? It's not tested, but there isn't much to it... robert diff --exclude=*~ -ru linux-2.4.2-pre4/arch/i386/config.in linux-2.4.2-pre4-logbuf/arch/i386/config.in --- linux-2.4.2-pre4/arch/i386/config.inMon Jan 8 13:27:56 2001 +++ linux-2.4.2-pre4-logbuf/arch/i386/config.in Tue Feb 20 14:10:12 2001 @@ -366,4 +366,5 @@ #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ +int 'Printk buffer size order 2**x' CONFIG_PRINTK_BUF_ORDER 14 endmenu diff --exclude=*~ -ru linux-2.4.2-pre4/kernel/printk.c linux-2.4.2-pre4-logbuf/kernel/printk.c --- linux-2.4.2-pre4/kernel/printk.cTue Feb 20 11:56:31 2001 +++ linux-2.4.2-pre4-logbuf/kernel/printk.c Tue Feb 20 14:10:06 2001 @@ -23,7 +23,11 @@ #include -#define LOG_BUF_LEN(16384) +#ifdef CONFIG_PRINTK_BUF_LEN +# define LOG_BUF_LEN (2**CONFIG_PRINTK_BUF_ORDER) +#else +# define LOG_BUF_LEN (16384) +#endif #define LOG_BUF_MASK (LOG_BUF_LEN-1) static char buf[1024];
Re: [PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
On Tue, Feb 20, 2001 at 02:53:04PM -0600, Thomas Dodd wrote:
> Robert Read wrote:
>
> Why not just make the config option in Kbytes.
> and do:
>
> #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024)
>
This is good idea, but I believe LOG_BUF_LEN needs to be a power of
2. A bitmask is used in several places to wrap around the end of the
ring buffer. For example
#define LOG_BUF_MASK (LOG_BUF_LEN-1)
printk() {
log_buf[(log_start+log_size) & LOG_BUF_MASK] = *p;
}
I think LOG_BUF_LEN could be defined to round up (or down) at compile
time, but my post-lunch-sleepy brain can't think of the trick to do
it.
robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
On Tue, Feb 20, 2001 at 01:37:16PM -0600, Thomas Dodd wrote: > Robert Read wrote: > > > > On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: > > > > > > Has anyone tried 128K buffer size in kernel/printk.c > > > and still have the kernel boot (without > > > hard to notice memory corruption problems and other subtle bugs)? > > > Any hints and tips will be appreciated. > > > > I have used 128k and larger buffer sizes, and I just noticed this > > fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: > > I think this should be a config option. Ok, here is a simple patch to add a config option, I'm compiling it now, so it's not tested yet. One question: what is the best way to force this option to be a power of 2? robert diff -ru linux-2.4.2-pre4/arch/i386/config.in linux-2.4.2-pre4-logbuf/arch/i386/config.in --- linux-2.4.2-pre4/arch/i386/config.inMon Jan 8 13:27:56 2001 +++ linux-2.4.2-pre4-logbuf/arch/i386/config.in Tue Feb 20 12:10:19 2001 @@ -366,4 +366,5 @@ #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ +int 'Printk buffer size (must be power of 2)' CONFIG_PRINTK_BUF_LEN 16384 endmenu Only in linux-2.4.2-pre4-logbuf/arch/i386: config.in~ Only in linux-2.4.2-pre4-logbuf/include: asm Only in linux-2.4.2-pre4-logbuf/include/linux: autoconf.h Only in linux-2.4.2-pre4-logbuf/include/linux: modules diff -ru linux-2.4.2-pre4/kernel/printk.c linux-2.4.2-pre4-logbuf/kernel/printk.c --- linux-2.4.2-pre4/kernel/printk.cTue Feb 20 11:56:31 2001 +++ linux-2.4.2-pre4-logbuf/kernel/printk.c Tue Feb 20 11:59:35 2001 @@ -23,7 +23,11 @@ #include -#define LOG_BUF_LEN(16384) +#ifdef CONFIG_PRINTK_BUF_LEN +# define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN) +#else +# define LOG_BUF_LEN (16384) +#endif #define LOG_BUF_MASK (LOG_BUF_LEN-1) static char buf[1024];
Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: > > Has anyone tried 128K buffer size in kernel/printk.c > and still have the kernel boot (without > hard to notice memory corruption problems and other subtle bugs)? > Any hints and tips will be appreciated. I have used 128k and larger buffer sizes, and I just noticed this fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: --- linux/kernel/printk.c.orig Sun Jan 28 20:24:13 2001 +++ linux/kernel/printk.c Wed Jan 31 23:21:25 2001 @@ -22,7 +22,11 @@ #include -#define LOG_BUF_LEN(16384) +#if CONFIG_TUX_DEBUG +# define LOG_BUF_LEN (16384*128) +#else +# define LOG_BUF_LEN (16384) +#endif #define LOG_BUF_MASK (LOG_BUF_LEN-1) static char buf[1024]; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: Has anyone tried 128K buffer size in kernel/printk.c and still have the kernel boot (without hard to notice memory corruption problems and other subtle bugs)? Any hints and tips will be appreciated. I have used 128k and larger buffer sizes, and I just noticed this fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: --- linux/kernel/printk.c.orig Sun Jan 28 20:24:13 2001 +++ linux/kernel/printk.c Wed Jan 31 23:21:25 2001 @@ -22,7 +22,11 @@ #include asm/uaccess.h -#define LOG_BUF_LEN(16384) +#if CONFIG_TUX_DEBUG +# define LOG_BUF_LEN (16384*128) +#else +# define LOG_BUF_LEN (16384) +#endif #define LOG_BUF_MASK (LOG_BUF_LEN-1) static char buf[1024]; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
On Tue, Feb 20, 2001 at 01:37:16PM -0600, Thomas Dodd wrote: Robert Read wrote: On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote: Has anyone tried 128K buffer size in kernel/printk.c and still have the kernel boot (without hard to notice memory corruption problems and other subtle bugs)? Any hints and tips will be appreciated. I have used 128k and larger buffer sizes, and I just noticed this fragment in the RedHat Tux Webserver patch. It creates a 2MB buffer: I think this should be a config option. Ok, here is a simple patch to add a config option, I'm compiling it now, so it's not tested yet. One question: what is the best way to force this option to be a power of 2? robert diff -ru linux-2.4.2-pre4/arch/i386/config.in linux-2.4.2-pre4-logbuf/arch/i386/config.in --- linux-2.4.2-pre4/arch/i386/config.inMon Jan 8 13:27:56 2001 +++ linux-2.4.2-pre4-logbuf/arch/i386/config.in Tue Feb 20 12:10:19 2001 @@ -366,4 +366,5 @@ #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ +int 'Printk buffer size (must be power of 2)' CONFIG_PRINTK_BUF_LEN 16384 endmenu Only in linux-2.4.2-pre4-logbuf/arch/i386: config.in~ Only in linux-2.4.2-pre4-logbuf/include: asm Only in linux-2.4.2-pre4-logbuf/include/linux: autoconf.h Only in linux-2.4.2-pre4-logbuf/include/linux: modules diff -ru linux-2.4.2-pre4/kernel/printk.c linux-2.4.2-pre4-logbuf/kernel/printk.c --- linux-2.4.2-pre4/kernel/printk.cTue Feb 20 11:56:31 2001 +++ linux-2.4.2-pre4-logbuf/kernel/printk.c Tue Feb 20 11:59:35 2001 @@ -23,7 +23,11 @@ #include asm/uaccess.h -#define LOG_BUF_LEN(16384) +#ifdef CONFIG_PRINTK_BUF_LEN +# define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN) +#else +# define LOG_BUF_LEN (16384) +#endif #define LOG_BUF_MASK (LOG_BUF_LEN-1) static char buf[1024];
Re: [PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.
On Tue, Feb 20, 2001 at 02:53:04PM -0600, Thomas Dodd wrote:
Robert Read wrote:
Why not just make the config option in Kbytes.
and do:
#define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024)
This is good idea, but I believe LOG_BUF_LEN needs to be a power of
2. A bitmask is used in several places to wrap around the end of the
ring buffer. For example
#define LOG_BUF_MASK (LOG_BUF_LEN-1)
printk() {
log_buf[(log_start+log_size) LOG_BUF_MASK] = *p;
}
I think LOG_BUF_LEN could be defined to round up (or down) at compile
time, but my post-lunch-sleepy brain can't think of the trick to do
it.
robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] configurable printk buffer size
The obvious solution struck me just after the last email. I change the config parameter to be an order, like the argument to get_free_pages(). How does this look? It's not tested, but there isn't much to it... robert diff --exclude=*~ -ru linux-2.4.2-pre4/arch/i386/config.in linux-2.4.2-pre4-logbuf/arch/i386/config.in --- linux-2.4.2-pre4/arch/i386/config.inMon Jan 8 13:27:56 2001 +++ linux-2.4.2-pre4-logbuf/arch/i386/config.in Tue Feb 20 14:10:12 2001 @@ -366,4 +366,5 @@ #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ +int 'Printk buffer size order 2**x' CONFIG_PRINTK_BUF_ORDER 14 endmenu diff --exclude=*~ -ru linux-2.4.2-pre4/kernel/printk.c linux-2.4.2-pre4-logbuf/kernel/printk.c --- linux-2.4.2-pre4/kernel/printk.cTue Feb 20 11:56:31 2001 +++ linux-2.4.2-pre4-logbuf/kernel/printk.c Tue Feb 20 14:10:06 2001 @@ -23,7 +23,11 @@ #include asm/uaccess.h -#define LOG_BUF_LEN(16384) +#ifdef CONFIG_PRINTK_BUF_LEN +# define LOG_BUF_LEN (2**CONFIG_PRINTK_BUF_ORDER) +#else +# define LOG_BUF_LEN (16384) +#endif #define LOG_BUF_MASK (LOG_BUF_LEN-1) static char buf[1024];
Re: can somebody explain how linux support 64G memory
There are two ways, the PAE flag and the PSE-36 feature introduced in P3. These extensions are documented in the IA-32 Intel Architecture Software Developer's Manuals, which you can find here: http://developer.intel.com/design/Pentium4/manuals/ Look in Volume 3, Chapter 3 for this info. robert On Wed, Feb 21, 2001 at 10:44:30AM +0800, michaelc wrote: Hi, How does linux support more than 4G memory? I 've read the documentation of Intel IA-32 Architecture, I knew that OS just address up to 4G physical address space, If OS want to access additional 4-GByte section of physical memory, it must change the pointer in register CR3 or entries in the page-directory-pointer table. That means that Linux just has up to 4-GByte page mapping at one time , is that right? -- Best regards, michael chen mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 12:41:57PM +, Henning P. Schmiedehausen wrote: > > If HP would spent only 5% of their driver writing > buget for Windows into Linux driver development, that I would call "a > move". Have you seen this: http://hp.sourceforge.net/ I certainly don't know what the percentage is (or care), but I'd call that "a move." robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Sat, Feb 17, 2001 at 12:41:57PM +, Henning P. Schmiedehausen wrote: If HP would spent only 5% of their driver writing buget for Windows into Linux driver development, that I would call "a move". Have you seen this: http://hp.sourceforge.net/ I certainly don't know what the percentage is (or care), but I'd call that "a move." robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PC-speaker control
On Tue, Jan 02, 2001 at 01:40:43AM +0100, Daniel Phillips wrote: > Daniel Phillips wrote: > > > > Robert Read wrote: > > > Try this on the console: > > > > > > setterm -blength 0 > > > > > > no assembly required. :) > > > > Yes, and my xterm still beeps - if I make that go away then something > > else will beep. > > > > Somebody posted a patch to do a global disable of the speaker some time > > back, and I wish that the patch were generally available. The result of > > not having the global disable is an office full of beeping > > computers. Right, I see what you mean. Disabling the beep is one thing I always do, and it requires a few differnt steps, like "xset b off" for xterms and so on. It would be nice to switch it off in one place and be done with it. > > > > How does this look: > > > echo 0 >/proc/sys/dev/speaker/beep > This looks good to me. As far as I can tell, it looks like the beep is generated by kd_mksound, which is a function pointer that usually points to drivers/char/vt.c:_kd_mksound(). Can anyone verify this? It doesn't look to hard to write a sysctl driver that would change the function pointer to something quieter. Is this what patch did? robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: devices.txt inconsistency
How's this? Should char-major-15 be obsoleted, deleted or just left in for now? robert --- linux/Documentation/devices.txt.bak Mon Jan 1 15:29:24 2001 +++ linux/Documentation/devices.txt Mon Jan 1 15:33:38 2001 @@ -430,14 +430,14 @@ 1 = /dev/dos_cd1 Second MSCDEX CD-ROM ... - 13 char PC speaker (OBSOLETE) - 0 = /dev/pcmixer Emulates /dev/mixer - 1 = /dev/pcsp Emulates /dev/dsp (8-bit) - 4 = /dev/pcaudio Emulates /dev/audio - 5 = /dev/pcsp16 Emulates /dev/dsp (16-bit) + 13 char Generic Input Driver + 0 = /dev/input/js0First joystick + 1 = /dev/input/js1Second joystick +... - The current PC speaker driver uses the Open Sound - System interface, and these devices are obsolete. + 64 = /dev/input/event0 For testing/debugging + 65 = /dev/input/event1 + ... block 8-bit MFM/RLL/IDE controller 0 = /dev/xda First XT disk whole disk On Mon, Jan 01, 2001 at 05:06:54PM -0500, Ari Pollak wrote: > This has not been fixed for at least a year that i can remember - in > Documentation/devices.txt, it says /dev/js* should be char-major-15*, > but in Documentation/joystick.txt it says it should be char-major-13. > I'm assuming joystick.txt is the correct one, and devices.txt should be > updated to reflect this.. before 2.4.0 would be nice. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: devices.txt inconsistency
devices.txt does need some updating. It still lists char-major-13 as the PC Speaker, but 13 appears to be the major for new input driver, and the joystick driver is now a minor off the that. Are there now two Joystick drivers, or can char-major-15 be obsoleted/deleted? robert On Mon, Jan 01, 2001 at 05:06:54PM -0500, Ari Pollak wrote: > This has not been fixed for at least a year that i can remember - in > Documentation/devices.txt, it says /dev/js* should be char-major-15*, > but in Documentation/joystick.txt it says it should be char-major-13. > I'm assuming joystick.txt is the correct one, and devices.txt should be > updated to reflect this.. before 2.4.0 would be nice. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC-speaker control
Try this on the console: setterm -blength 0 no assembly required. :) robert On Mon, Jan 01, 2001 at 06:30:37PM -0200, Rafael Diniz wrote: > Hey, Is there a way to control the PC-speaker with the Linux kernel 2.2? > I want to disable it. > I guy told me that with this assembly code I can disable it: > in al , 97 > and al,253 > out 97,al > Linux 2.4 will have any syscall to do this? > > Thanks > Rafael Diniz > Brazil > = > Conectiva Linux 6.0 (2.2.17) XFree86-4.0.1 > PII 233mhz 96Mb ram > SB16, USR56k, S3 VirgeDX/GX 4Mb, CD creative48X > HDa 10Gb Quantum HDb 4.1Gb Fugitsu > MSX2.0 256k MegaRam 256k Mapper 128k Vram > MSX is the future > = > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC-speaker control
Try this on the console: setterm -blength 0 no assembly required. :) robert On Mon, Jan 01, 2001 at 06:30:37PM -0200, Rafael Diniz wrote: Hey, Is there a way to control the PC-speaker with the Linux kernel 2.2? I want to disable it. I guy told me that with this assembly code I can disable it: in al , 97 and al,253 out 97,al Linux 2.4 will have any syscall to do this? Thanks Rafael Diniz Brazil = Conectiva Linux 6.0 (2.2.17) XFree86-4.0.1 PII 233mhz 96Mb ram SB16, USR56k, S3 VirgeDX/GX 4Mb, CD creative48X HDa 10Gb Quantum HDb 4.1Gb Fugitsu MSX2.0 256k MegaRam 256k Mapper 128k Vram MSX is the future = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: devices.txt inconsistency
devices.txt does need some updating. It still lists char-major-13 as the PC Speaker, but 13 appears to be the major for new input driver, and the joystick driver is now a minor off the that. Are there now two Joystick drivers, or can char-major-15 be obsoleted/deleted? robert On Mon, Jan 01, 2001 at 05:06:54PM -0500, Ari Pollak wrote: This has not been fixed for at least a year that i can remember - in Documentation/devices.txt, it says /dev/js* should be char-major-15*, but in Documentation/joystick.txt it says it should be char-major-13. I'm assuming joystick.txt is the correct one, and devices.txt should be updated to reflect this.. before 2.4.0 would be nice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: devices.txt inconsistency
How's this? Should char-major-15 be obsoleted, deleted or just left in for now? robert --- linux/Documentation/devices.txt.bak Mon Jan 1 15:29:24 2001 +++ linux/Documentation/devices.txt Mon Jan 1 15:33:38 2001 @@ -430,14 +430,14 @@ 1 = /dev/dos_cd1 Second MSCDEX CD-ROM ... - 13 char PC speaker (OBSOLETE) - 0 = /dev/pcmixer Emulates /dev/mixer - 1 = /dev/pcsp Emulates /dev/dsp (8-bit) - 4 = /dev/pcaudio Emulates /dev/audio - 5 = /dev/pcsp16 Emulates /dev/dsp (16-bit) + 13 char Generic Input Driver + 0 = /dev/input/js0First joystick + 1 = /dev/input/js1Second joystick +... - The current PC speaker driver uses the Open Sound - System interface, and these devices are obsolete. + 64 = /dev/input/event0 For testing/debugging + 65 = /dev/input/event1 + ... block 8-bit MFM/RLL/IDE controller 0 = /dev/xda First XT disk whole disk On Mon, Jan 01, 2001 at 05:06:54PM -0500, Ari Pollak wrote: This has not been fixed for at least a year that i can remember - in Documentation/devices.txt, it says /dev/js* should be char-major-15*, but in Documentation/joystick.txt it says it should be char-major-13. I'm assuming joystick.txt is the correct one, and devices.txt should be updated to reflect this.. before 2.4.0 would be nice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC-speaker control
On Tue, Jan 02, 2001 at 01:40:43AM +0100, Daniel Phillips wrote: Daniel Phillips wrote: Robert Read wrote: Try this on the console: setterm -blength 0 no assembly required. :) Yes, and my xterm still beeps - if I make that go away then something else will beep. Somebody posted a patch to do a global disable of the speaker some time back, and I wish that the patch were generally available. The result of not having the global disable is an office full of beeping computers. Right, I see what you mean. Disabling the beep is one thing I always do, and it requires a few differnt steps, like "xset b off" for xterms and so on. It would be nice to switch it off in one place and be done with it. How does this look: echo 0 /proc/sys/dev/speaker/beep This looks good to me. As far as I can tell, it looks like the beep is generated by kd_mksound, which is a function pointer that usually points to drivers/char/vt.c:_kd_mksound(). Can anyone verify this? It doesn't look to hard to write a sysctl driver that would change the function pointer to something quieter. Is this what patch did? robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Wiring down Pages
On Thu, Dec 21, 2000 at 06:46:33PM -0200, Rik van Riel wrote: > > page_cache_drop(page); <= removes your extra count I can't find that function, do you mean page_cache_free() and page_cache_release(), both are aliases for __free_page(). Maybe we need another alias. :) Should non-page cache related code use get_page() and __free_page() directly? Or should the page_cache_* macros be used everywhere? robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Wiring down Pages
On Thu, Dec 21, 2000 at 06:46:33PM -0200, Rik van Riel wrote: page_cache_drop(page); = removes your extra count I can't find that function, do you mean page_cache_free() and page_cache_release(), both are aliases for __free_page(). Maybe we need another alias. :) Should non-page cache related code use get_page() and __free_page() directly? Or should the page_cache_* macros be used everywhere? robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: QLogicFC problems with 2.4.x?
The driver loads for me on 2.4 on Intel, but I don't have access to an Alpha right now. Have you tried Mathew Jacob's driver? It looks like it supports Alpha. http://www.feral.com/isp.html robert On Mon, Dec 18, 2000 at 04:24:38PM -0500, Peter Rival wrote: > Hi, > >I was just lent a QLogic ISP2200 FC adapter and have been having a > bear of a time trying to get it to work on my Alpha ES40 and GS80. I've > tried both the qlogicfc (with standard kernel) and qla2x00 (from QLogic > and Compaq) driver both built-in and as modules but neither of them are > working. Has anyone had success with later (I'm using 2.4.0-test11) 2.4 > kernels and the QLogic FC adapter? I'm currently plugged into a Brocade > switch (Plaides I, I believe) which is also attached to two pair of > HSG80 FC RAID controllers. AFAIK, the 2200 is supposed to work with an > FC fabric, so this should work, right? Can anyone offer any > assistance? Thanks! > > - Pete > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
