Pset patches
Are you the same Tim Hockin that wrote the pset patches for Linux 2.2.12? I noticed your pset web page is gone and I'd like to mirror it if it hasn't been already. -VAL - 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/
Pset patches
Are you the same Tim Hockin that wrote the pset patches for Linux 2.2.12? I noticed your pset web page is gone and I'd like to mirror it if it hasn't been already. -VAL - 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] drivers/char/serial.c bug in ST16C654 detection
On Thu, May 17, 2001 at 09:49:11AM -0400, Stuart MacDonald wrote: > Are you using the serial console though? That seems to be > implied by your problem, but I just want to check. Yes, I have serial console only on this board. -VAL - 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] drivers/char/serial.c bug in ST16C654 detection
On Thu, May 17, 2001 at 09:49:11AM -0400, Stuart MacDonald wrote: Are you using the serial console though? That seems to be implied by your problem, but I just want to check. Yes, I have serial console only on this board. -VAL - 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] drivers/char/serial.c bug in ST16C654 detection
Anyone know where Ted Tso is? He hasn't posted in several weeks.
Alan, will you put this in -ac? This patch fixes a bug in serial.c
that causes a crash on machines with a ST16C654.
On Tue, May 15, 2001 at 09:52:01AM -0400, Stuart MacDonald wrote:
> Kernel version? Distribution? Are you using a serial console?
2.4.5-pre1 (see patch).
> The revision should always be saved if it's available. Hmm.
> I didn't look carefully yesterday. The DLL always contains the
> revision for the 85x family. Why do you think it doesn't?
Because the comment was ambiguous. I don't have the data sheet for
the 85x family so I just wrote the code according to the comment.
I'll change the comment to make it clear.
> I think your patch below is good, I'm just mystified by this
> kablooey thing.
Thanks. Corrected version of the patch is below.
-VAL
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Thu May 17 03:12:09 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3548,20 +3548,33 @@
* then reading back DLL and DLM. If DLM reads back 0x10,
* then the UART is a XR16C850 and the DLL contains the chip
* revision. If DLM reads back 0x14, then the UART is a
-* XR16C854.
-*
+* XR16C854 and the DLL contains the chip revision.
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state->revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ state->revision = scratch2;
state->type = PORT_16850;
return;
}
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
-
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] drivers/char/serial.c bug in ST16C654 detection
On Mon, May 14, 2001 at 03:50:01PM -0400, Stuart MacDonald wrote:
> What version of serial.c? I'm assuming 5.05.
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
> Define "go kablooey". We haven't noticed any problems, and we supplied
> this bit of code.
"Go kablooey" means that all serial output stops and the kernel never
finishes booting. This patch makes it correctly detect the
controller, continue to produce serial output, and finish booting.
> The size_fifo() routine supplies its own baud rate divisor, and
> on any rs_open() change_speed() sets the baud rate properly.
> I can't figure what you might be seeing.
I don't know why it doesn't work the way you describe. If I comment
out the section of code that sets the baud rate to 0, everything works
fine. Otherwise, it doesn't even finish booting. The Exar datasheet
at http://www.exar.com/products/st16c654.pdf doesn't define what
happens if you set the baud rate registers to 0.
> This isn't necessary. The revision field is only checked
> for 950s, so setting it here doesn't harm anything. If the
> current (only) example of checking it is followed as normal
> procedure, the port type will always be checked first, before
> checking the revision, ensuring only valid revisions are
> referenced.
It's just sloppy programming. There's no benefit from setting an
invalid revision for the Exar and if the usage of state->revision
changes it may introduce a bug.
> Only saving the revision for 850s is probably wrong. It should
> be saved for all the 85x uarts.
The comment above it should also be changed then. If someone knows
for sure whether the revision should be saved for the XR16C854 then
the comment can be made clearer. See patch below.
-VAL
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Tue May 15 03:19:08 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3548,20 +3548,33 @@
* then reading back DLL and DLM. If DLM reads back 0x10,
* then the UART is a XR16C850 and the DLL contains the chip
* revision. If DLM reads back 0x14, then the UART is a
-* XR16C854.
-*
+* XR16C854 and the DLL may or may not contain the revision.
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state->revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ state->revision = scratch2;
state->type = PORT_16850;
return;
}
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
-
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] drivers/char/serial.c bug in ST16C654 detection
On Mon, May 14, 2001 at 03:50:01PM -0400, Stuart MacDonald wrote:
What version of serial.c? I'm assuming 5.05.
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
Define go kablooey. We haven't noticed any problems, and we supplied
this bit of code.
Go kablooey means that all serial output stops and the kernel never
finishes booting. This patch makes it correctly detect the
controller, continue to produce serial output, and finish booting.
The size_fifo() routine supplies its own baud rate divisor, and
on any rs_open() change_speed() sets the baud rate properly.
I can't figure what you might be seeing.
I don't know why it doesn't work the way you describe. If I comment
out the section of code that sets the baud rate to 0, everything works
fine. Otherwise, it doesn't even finish booting. The Exar datasheet
at http://www.exar.com/products/st16c654.pdf doesn't define what
happens if you set the baud rate registers to 0.
This isn't necessary. The revision field is only checked
for 950s, so setting it here doesn't harm anything. If the
current (only) example of checking it is followed as normal
procedure, the port type will always be checked first, before
checking the revision, ensuring only valid revisions are
referenced.
It's just sloppy programming. There's no benefit from setting an
invalid revision for the Exar and if the usage of state-revision
changes it may introduce a bug.
Only saving the revision for 850s is probably wrong. It should
be saved for all the 85x uarts.
The comment above it should also be changed then. If someone knows
for sure whether the revision should be saved for the XR16C854 then
the comment can be made clearer. See patch below.
-VAL
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Tue May 15 03:19:08 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3548,20 +3548,33 @@
* then reading back DLL and DLM. If DLM reads back 0x10,
* then the UART is a XR16C850 and the DLL contains the chip
* revision. If DLM reads back 0x14, then the UART is a
-* XR16C854.
-*
+* XR16C854 and the DLL may or may not contain the revision.
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state-revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ state-revision = scratch2;
state-type = PORT_16850;
return;
}
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
-
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] drivers/char/serial.c bug in ST16C654 detection
This fixes a bug in the autoconfig_startech_uarts function in
serial.c. The problem is that 0's are written to the baud rate
registers in order to detect an XR16C850 or XR16C854. This makes the
Exar ST16C654 go kablooey. Saving and restoring the baud rate
registers after the test fixes it.
I'm assuming that the XR16C85[04] detection works as is and doesn't
need the original baud rate restored. If I'm wrong, I'll rewrite the
patch.
-VAL
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Sat May 12 05:19:26 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3551,17 +3551,32 @@
* XR16C854.
*
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state->revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ if (scratch == 0x10)
+ state->revision = scratch2;
state->type = PORT_16850;
return;
}
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
-
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] drivers/char/serial.c bug in ST16C654 detection
This fixes a bug in the autoconfig_startech_uarts function in
serial.c. The problem is that 0's are written to the baud rate
registers in order to detect an XR16C850 or XR16C854. This makes the
Exar ST16C654 go kablooey. Saving and restoring the baud rate
registers after the test fixes it.
I'm assuming that the XR16C85[04] detection works as is and doesn't
need the original baud rate restored. If I'm wrong, I'll rewrite the
patch.
-VAL
--- linux-2.4.5-pre1/drivers/char/serial.c Thu Apr 19 00:26:34 2001
+++ linux/drivers/char/serial.c Sat May 12 05:19:26 2001
@@ -3507,7 +3507,7 @@
struct serial_state *state,
unsigned long flags)
{
- unsigned char scratch, scratch2, scratch3;
+ unsigned char scratch, scratch2, scratch3, scratch4;
/*
* First we check to see if it's an Oxford Semiconductor UART.
@@ -3551,17 +3551,32 @@
* XR16C854.
*
*/
+
+ /* Save the DLL and DLM */
+
serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ scratch3 = serial_inp(info, UART_DLL);
+ scratch4 = serial_inp(info, UART_DLM);
+
serial_outp(info, UART_DLL, 0);
serial_outp(info, UART_DLM, 0);
- state-revision = serial_inp(info, UART_DLL);
+ scratch2 = serial_inp(info, UART_DLL);
scratch = serial_inp(info, UART_DLM);
serial_outp(info, UART_LCR, 0);
+
if (scratch == 0x10 || scratch == 0x14) {
+ if (scratch == 0x10)
+ state-revision = scratch2;
state-type = PORT_16850;
return;
}
+ /* Restore the DLL and DLM */
+
+ serial_outp(info, UART_LCR, UART_LCR_DLAB);
+ serial_outp(info, UART_DLL, scratch3);
+ serial_outp(info, UART_DLM, scratch4);
+ serial_outp(info, UART_LCR, 0);
/*
* We distinguish between the '654 and the '650 by counting
* how many bytes are in the FIFO. I'm using this for now,
-
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: Is sendfile all that sexy?
On Mon, Jan 22, 2001 at 10:27:58AM -0800, David Lang wrote: > On Mon, 22 Jan 2001, Val Henson wrote: > > > There is a use for an optimized socket->socket transfer - proxying > > high speed TCP connections. It would be exciting if the zerocopy > > networking framework led to a decent socket->socket transfer. > > if you are proxying connextions you should really be looking at what data > you pass through your proxy. > > now replay proxying with routing and I would agree with you (but I'll bet > this is handled in the kernel IP stack anyway) Well, there is a (real-world) case where your TCP proxy doesn't want to look at the data and you can't use IP forwarding. If you have TCP connections between networks that have very different MTU's, using IP forwarding will result in tiny packets on the large MTU networks. So who cares? Some machines, notably Crays and NEC's, have a severely rate-limited network stack and can only transmit up to about 3500 packets per second. That's 40 Mbps on a 1500 byte MTU network, but greater than line speed on HIPPI (65280 MTU, 800 Mbps). So, for a rate-limited network stack on a HIPPI network, the best way to talk to a machine on a gigabit ethernet network is through a TCP proxy which just doesn't care about the data going through it. Hence my interest in socket->socket sendfile(). I'll admit this is an odd corner case which isn't important enough to justify socket->socket sendfile() on its own. But this odd corner case did make enough money to pay my salary for years to come. :) -VAL - 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: Is sendfile all that sexy?
On Wed, Jan 17, 2001 at 11:32:35AM -0800, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Ben Mansell <[EMAIL PROTECTED]> wrote: > > > >The current sendfile() has the limitation that it can't read data from > >a socket. Would it be another 5-minute hack to remove this limitation, so > >you could sendfile between sockets? Now _that_ would be sexy :) > > I don't think that would be all that sexy at all. > > You have to realize, that sendfile() is meant as an optimization, by > being able to re-use the same buffers that act as the in-kernel page > cache as buffers for sending data. So you avoid one copy. > > However, for socket->socket, we would not have such an advantage. A > socket->socket sendfile() would not avoid any copies the way the > networking is done today. That _may_ change, of course. But it might > not. And I'd rather tell people using sendfile() that you get EINVAL if > it isn't able to optimize the transfer.. Yes, socket->socket sendfile is not that sexy. I actually did this for 2.2.16 in the obvious (and stupid) way, copying data into a buffer and writing it it out again. The performance was unsurprisingly _exactly_ identical to a userspace read()/write() loop. There is a use for an optimized socket->socket transfer - proxying high speed TCP connections. It would be exciting if the zerocopy networking framework led to a decent socket->socket transfer. -VAL - 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: Is sendfile all that sexy?
On Wed, Jan 17, 2001 at 11:32:35AM -0800, Linus Torvalds wrote: In article [EMAIL PROTECTED], Ben Mansell [EMAIL PROTECTED] wrote: The current sendfile() has the limitation that it can't read data from a socket. Would it be another 5-minute hack to remove this limitation, so you could sendfile between sockets? Now _that_ would be sexy :) I don't think that would be all that sexy at all. You have to realize, that sendfile() is meant as an optimization, by being able to re-use the same buffers that act as the in-kernel page cache as buffers for sending data. So you avoid one copy. However, for socket-socket, we would not have such an advantage. A socket-socket sendfile() would not avoid any copies the way the networking is done today. That _may_ change, of course. But it might not. And I'd rather tell people using sendfile() that you get EINVAL if it isn't able to optimize the transfer.. Yes, socket-socket sendfile is not that sexy. I actually did this for 2.2.16 in the obvious (and stupid) way, copying data into a buffer and writing it it out again. The performance was unsurprisingly _exactly_ identical to a userspace read()/write() loop. There is a use for an optimized socket-socket transfer - proxying high speed TCP connections. It would be exciting if the zerocopy networking framework led to a decent socket-socket transfer. -VAL - 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: Is sendfile all that sexy?
On Mon, Jan 22, 2001 at 10:27:58AM -0800, David Lang wrote: On Mon, 22 Jan 2001, Val Henson wrote: There is a use for an optimized socket-socket transfer - proxying high speed TCP connections. It would be exciting if the zerocopy networking framework led to a decent socket-socket transfer. if you are proxying connextions you should really be looking at what data you pass through your proxy. now replay proxying with routing and I would agree with you (but I'll bet this is handled in the kernel IP stack anyway) Well, there is a (real-world) case where your TCP proxy doesn't want to look at the data and you can't use IP forwarding. If you have TCP connections between networks that have very different MTU's, using IP forwarding will result in tiny packets on the large MTU networks. So who cares? Some machines, notably Crays and NEC's, have a severely rate-limited network stack and can only transmit up to about 3500 packets per second. That's 40 Mbps on a 1500 byte MTU network, but greater than line speed on HIPPI (65280 MTU, 800 Mbps). So, for a rate-limited network stack on a HIPPI network, the best way to talk to a machine on a gigabit ethernet network is through a TCP proxy which just doesn't care about the data going through it. Hence my interest in socket-socket sendfile(). I'll admit this is an odd corner case which isn't important enough to justify socket-socket sendfile() on its own. But this odd corner case did make enough money to pay my salary for years to come. :) -VAL - 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/
[PATCH] rrunner.c
This patch for the RoadRunner HIPPI driver includes: * Fix crash on null dereference in rr_interrupt due to firmware bug * Fix crash on null dereference in rr_interrupt with better link ON/OFF handling * Fix crash due to NIC continuing to DMA after HALT (requires firmware >= 2.0.67) Plus numerous smaller bugfixes and features. Patches are available against 2.2.18 and 2.4.0. The patches are too big to post on the list, so here's the URL (with more details on the patch): http://www.nmt.edu/~val/patch.html Sorry for the big patch, I'll be happy to create a subset of the patch for anyone who doesn't want to merge the whole thing. Credit goes mainly to Kurt Ferreira <[EMAIL PROTECTED]>, also of Essential Communications. -VAL - 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/
[PATCH] rrunner.c
This patch for the RoadRunner HIPPI driver includes: * Fix crash on null dereference in rr_interrupt due to firmware bug * Fix crash on null dereference in rr_interrupt with better link ON/OFF handling * Fix crash due to NIC continuing to DMA after HALT (requires firmware = 2.0.67) Plus numerous smaller bugfixes and features. Patches are available against 2.2.18 and 2.4.0. The patches are too big to post on the list, so here's the URL (with more details on the patch): http://www.nmt.edu/~val/patch.html Sorry for the big patch, I'll be happy to create a subset of the patch for anyone who doesn't want to merge the whole thing. Credit goes mainly to Kurt Ferreira [EMAIL PROTECTED], also of Essential Communications. -VAL - 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: [BUG] /proc//stat access stalls badly for swapping process, 2.4.0-test10
On Thu, Nov 02, 2000 at 08:19:06AM +0100, Mike Galbraith wrote: > On Wed, 1 Nov 2000, Rik van Riel wrote: > > > I have one possible reason for this > > > > 1) the procfs process does (in fs/proc/array.c::proc_pid_stat) > > down(>mmap_sem); > > > > 2) but, in order to do that, it has to wait until the process > >it is trying to stat has /finished/ its page fault, and is > >not into its next one ... > > > > 3) combine this with the elevator starvation stuff (ask Jens > >Axboe for blk-7 to alleviate this issue) and you have a > >scenario where processes using /proc//stat have the > >possibility to block on multiple processes that are in the > >process of handling a page fault (but are being starved) > > I'm experimenting with blk.[67] in test10 right now. The stalls > are not helped at all. It doesn't seem to become request bound > (haven't instrumented that yet to be sure) but the stalls persist. > > -Mike This is not an elevator starvation problem. I also experienced these stalls with my IDE-only system. Unless I'm badly mistaken, the elevator is only used on SCSI disks, therefore elevator starvation cannot be blamed for this problem. These stalls are particularly annoying since I want to find the pid of the process hogging memory in order to kill it, but the read from /proc stalls for 45 seconds or more. -VAL - 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: Availability of kdb
One way of increasing signal to noise ratio (place in .procmailrc): :0 * ^FROM.*jmerkey@timpanogas\.com /dev/null On Mon, Sep 11, 2000 at 03:53:48PM -0400, [EMAIL PROTECTED] wrote: > On Mon, 11 Sep 2000, Jeff V. Merkey wrote: > Now will you stop trying to incite pointless riots and allow those of us > who are trying to use linux-kernel as a useful means of communicating > development issues a chance for a decent signal to noise ratio? -VAL - 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: Availability of kdb
One way of increasing signal to noise ratio (place in .procmailrc): :0 * ^FROM.*jmerkey@timpanogas\.com /dev/null On Mon, Sep 11, 2000 at 03:53:48PM -0400, [EMAIL PROTECTED] wrote: On Mon, 11 Sep 2000, Jeff V. Merkey wrote: snip Now will you stop trying to incite pointless riots and allow those of us who are trying to use linux-kernel as a useful means of communicating development issues a chance for a decent signal to noise ratio? -VAL - 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/
