Re: processes> 2^15
Le Sat, Nov 04, 2000 at 09:01:58PM +0100, Andries Brouwer a écrit: > > after reaching process count something around 30568, processes start > > getting pid from start, which ever is the first free entry slot in process > > table. that means we can't have simultaneously more than roughly 2^15 > > processes? > > am i correct? > > Yes. > (If that displeases you I can give you the trivial patch. > However, you really need some awesome machine before it > becomes reasonable to run that many processes.) In the fact, the first limit to be reached will be NR_TASKS defined in linux/tasks.h: #define NR_TASKS512 /* On x86 Max 4092, or 4090 w/APM configured. */ So I wonder if we could really have more than 4092 process under x86 ? Arnaud. - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
I've seen the same arguments over and over again here. It seems that there are two feasible ways to accomplish persistence: totally kernel and totally user-space The totally kernel-space people want to make a way for modules to store persistent data, either in memory, or across boots on disk. These people seem to debate whether modules should be unloaded/loaded upon suspend/resume. Among the user-space people, there are some who want the status quo, where the driver initializes the card, and then a user proggy sets it up the way it really should be, which causes the gap problem. There was also a suggestion (which sounded pretty interesting) where the driver would not initialize the card until prompted to do so by a user-space program, which would also give it the correct settings. It seems that the big problem with this is that the card may not get initialized when it needs to be. The initialization/state-saver proggy may have to be called: on boot, on suspend, on restore, when the hardware is physically removed and replaced, when something goes wrong and the user wants to reset things, and on shutdown. I just wanted to try to get all the arguments together on one page. I hope I didn't miss anything, or make any big mistakes. My own guess is that the first option is the most reliable, and that the last one is the most flexible. -- This message has been brought to you by the letter alpha and the number pi. David Feuer [EMAIL PROTECTED] - 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: malloc(1/0) ??
> hi,
> why does this program works. when executed, it doesnt
> give a segmentation fault. when the program requests
> memory, is a standard chunk is allocated irrespective
> of the what the user specifies. please explain.
>
> main()
> {
>char *s;
>s = (char*)malloc(0);
>strcpy(s,"f");
>printf("%s\n",s);
> }
>
> NOTE:
> i know its a 'C' problem. but i wanted to know how
> this works
The program does not work. A program works if it does what it's supposed to
do. If you want to argue that this program is supposed to print "ff"
then explain to me why the 'malloc' contains a zero in parenthesis.
The program can't possibly work because it invokes undefined behavior. It
is impossible to determine what a program that invokes undefined behavior is
'supposed to do'.
DS
-
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: malloc(1/0) ??
> From: "Dan Kegel" <[EMAIL PROTECTED]>
> > [EMAIL PROTECTED] asked:
> > > [Why does this program not crash?]
> > >
> > > main()
> > > {
> > >char *s;
> > >s = (char*)malloc(0);
> > >strcpy(s,"f");
> > >printf("%s\n",s);
> > > }
> >
> > It doesn't crash because the standard malloc is
> > optimized for speed, not for finding bugs.
> >
> > Try linking it with a debugging malloc, e.g.
> > cc bug.c -lefence
> > and watch it dump core.
>
> I'm not sure that is fully responsive, Dan. Why doesn't the
> strcpy throw a hissyfit and coredump?
Why should it? Do you think that when you allocate memory, the chunk of
mappable memory you got always ends on the exact byte you asked it to? When
you invoke undefined behavior, anything can happen.
DS
-
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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 23:32:42 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> Ok, but why doesn't 2.2.16 exhibit this behavior? We've had reports from quite a number of people complaining about this and I'm fairly certain not all of them are from Earthlink. The only thing different is that 2.2.x is packetizing the write() system calls on the server differently, otherwise there is no difference whatsoever. What 2.4.x is doing is completely legal. Really, even if not all of these people are from Earthlink (well, you should see if this is for certain) they may all be using the same buggy terminal server at these different ISPs. Later, David S. Miller [EMAIL PROTECTED] - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date: Mon, 06 Nov 2000 23:16:21 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >"David S. Miller" wrote: >> It is clear though, that something is messing with or corrupting the >> packets. One thing you might try is turning off TCP header >> compression for the PPP link, does this make a difference? > >Actually, there has been several reports that turning header >compression does help. > > If this is what is causing the TCP sequence numbers to change > then either Win98's or Earthlink terminal server's implementation > of TCP header compression is buggy. > > Assuming this is true, it explains why Win98's TCP does not "see" the > data sent by Linux, because such a bug would make the TCP checksum of > these packets incorrect and thus dropped by Win98's TCP. Ok, but why doesn't 2.2.16 exhibit this behavior? We've had reports from quite a number of people complaining about this and I'm fairly certain not all of them are from Earthlink. Jordan - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Tue, 7 Nov 2000 08:16:04 +0100 From: Andi Kleen <[EMAIL PROTECTED]> Hmm. One of these weird bandwidth limiters again? In a more recent mail, TCP header compression in Win98 or Earthlink's terminal servers have become the current prime suspect. :-) The RTT is lower than 2.2's initial 3s RTT, so 2.2 would never see it. The 240 traces are using an RTT of 3s (look at the time difference of the first retransmit), so this is not it. Later, David S. Miller [EMAIL PROTECTED] - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 23:16:21 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> "David S. Miller" wrote: > It is clear though, that something is messing with or corrupting the > packets. One thing you might try is turning off TCP header > compression for the PPP link, does this make a difference? Actually, there has been several reports that turning header compression does help. If this is what is causing the TCP sequence numbers to change then either Win98's or Earthlink terminal server's implementation of TCP header compression is buggy. Assuming this is true, it explains why Win98's TCP does not "see" the data sent by Linux, because such a bug would make the TCP checksum of these packets incorrect and thus dropped by Win98's TCP. Later, David S. Miller [EMAIL PROTECTED] - 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: locks.c: removal of semaphores
[EMAIL PROTECTED] wrote:
>
> Andrew,
> I got 5250 Req/s with your locks-sem.patch on normal Apache.
> It is good performance on normal Apache.
Great. Thanks again. Trond has this patch now for ongoing
NFS locking stuff. Hopefully 2.4 will now work OK with "legacy"
Apache configurations.
As long as the "new style" Apache configurations work OK.
Which leads us to...
> ...
> We also did durability test of 2.4.0-test10-pre5. Unfortunately
> enough, we didn't successfully complete the test of Apache w/o
> serialization (-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT), it couldn't
> continue to run for a night. The kernel got complete deadlock.
>
> The message is:
> "Unable to handle kernel NULL pointer dereference NMI watchdog detected LOCKUP on
>CPU1."
>
> Yes, obviously it's not Andrew's problem, that is genuine test10-pre5.
>
> Hidden bugs are awakened by removing serialization.
>
(Places fingertips lightly upon spinning disk drive.
Closes eyes. Quietly hums low monotone. Time passes...)
I sense a corrupted struct timer_list!
Your kernel was traversing the tvecs[] array and took a fault.
The fault handler called printk() which called the console code
which called mod_timer() which deadlocked on timerlist_lock.
The NMI handler broke the deadlock and called the console code.
The NMI handler also deadlocked on timerlist_lock.
If this theory is correct the below patch should remove the
deadlock and thus allow you to get the usual diagnostics.
But I suspect the diagnostics will just show a trace up
into cascade_timers() or run_timer_list() which doesn't
tell us much.
If that is the case I'm afraid you will have to identify the
_exact_ statement where the error occured, put some diagnostic
code just prior to it and run the tests a second time.
The interesting piece of information will be the timer's
function pointer. So you'll need to add something like:
struct timer_list *some_timer; /* The timer which causes the fault */
...
if (some_timer->list.next == 0 || some_timer->list.prev == 0)
printk("Corrupted timer! function=0x%p\n", some_timer->function);
/* The next statement is where the oops occurs */
Then if you can look the function pointer up in System.map or gdb
we will have our culprit.
--- linux-2.4.0-test10/arch/i386/kernel/traps.c Sat Nov 4 16:22:47 2000
+++ linux-akpm/arch/i386/kernel/traps.c Tue Nov 7 17:56:15 2000
@@ -396,9 +396,22 @@
__setup("nmi_watchdog=", setup_nmi_watchdog);
-extern spinlock_t console_lock;
+extern spinlock_t console_lock, timerlist_lock;
static spinlock_t nmi_print_lock = SPIN_LOCK_UNLOCKED;
+/*
+ * Unlock any spinlocks which will prevent us from getting the
+ * message out
+ */
+
+void bust_spinlocks(void)
+{
+ spin_trylock(_lock);
+ spin_unlock(_lock);
+ spin_trylock(_lock);
+ spin_unlock(_lock);
+}
+
inline void nmi_watchdog_tick(struct pt_regs * regs)
{
/*
@@ -439,8 +452,7 @@
* We are in trouble anyway, lets at least try
* to get a message out.
*/
- spin_trylock(_lock);
- spin_unlock(_lock);
+ bust_spinlocks();
printk("NMI Watchdog detected LOCKUP on CPU%d, registers:\n",
cpu);
show_registers(regs);
printk("console shuts up ...\n");
--- linux-2.4.0-test10/arch/i386/mm/fault.c Sat Nov 4 16:22:47 2000
+++ linux-akpm/arch/i386/mm/fault.c Tue Nov 7 17:57:15 2000
@@ -24,6 +24,7 @@
#include
extern void die(const char *,struct pt_regs *,long);
+extern void bust_spinlocks(void);
/*
* Ugly, ugly, but the goto's result in better assembly..
@@ -250,6 +251,8 @@
* Oops. The kernel tried to access some bad page. We'll have to
* terminate things with extreme prejudice.
*/
+
+ bust_spinlocks();
if (address < PAGE_SIZE)
printk(KERN_ALERT "Unable to handle kernel NULL pointer dereference");
-
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/
sound driver persistent state
David Feuer writes: > People keep saying it's OK to start muted on boot, but I must say that I > don't think this is really acceptable I may very well want to set my > mixer and just leave it that way forever would there be any way to give > the sound driver a scribble pad on disk to let it sa You can't guarantee that the mixer will retain its settings across a hardware reset, APM suspend/resume cycle, or power cycle. The typical ALSA installation runs an "alsactl restore" after loading the driver modules to set the initial mixer levels, and an "alsactl store" on shutdown to save the mixer levels before unloading the modules. This seems to work fine on my laptop, and is in user space where it belongs. In fact, on my laptop the intel8x0 driver can't cope with a suspend/resume cycle while loaded or it hangs after the resume, so my APM scripts unload the ALSA drivers every time I suspend and reload them every time I resume. - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date: Mon, 06 Nov 2000 22:44:00 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >Attached to this message are dumps from the windows 98 machine using >windump and the linux 2.4.0-test10. Sorry the time stamps don't match >up. > > (ie. Linux sends bytes 1:21 both the first time, and when it > retransmits that data. However win98 "sees" this as 1:19 the first > time and 1:21 during the retransmit by Linux) > > That is bogus. Something is mangling the packets between the Linux > machine and the win98 machine. You mentioned something about > bandwidth limiting at your upstream provider, any chance you can have > them turn this bandwidth limiting device off? It actually turns out that that problem with bandwidth was fixed yesterday, so this can not be the problem here and yes, 64.124.41.179 is a linux box. :) > Or maybe earthlink is using some packet mangling device? > > It is clear though, that something is messing with or corrupting the > packets. One thing you might try is turning off TCP header > compression for the PPP link, does this make a difference? Actually, there has been several reports that turning header compression does help. Jordan - 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: malloc(1/0) ??
From: "Dan Kegel" <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] asked:
> > [Why does this program not crash?]
> >
> > main()
> > {
> >char *s;
> >s = (char*)malloc(0);
> >strcpy(s,"f");
> >printf("%s\n",s);
> > }
>
> It doesn't crash because the standard malloc is
> optimized for speed, not for finding bugs.
>
> Try linking it with a debugging malloc, e.g.
> cc bug.c -lefence
> and watch it dump core.
I'm not sure that is fully responsive, Dan. Why doesn't the
strcpy throw a hissyfit and coredump?
{^_^}
-
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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
On Mon, Nov 06, 2000 at 10:59:04PM -0800, David S. Miller wrote: >Date: Tue, 7 Nov 2000 08:03:42 +0100 >From: Andi Kleen <[EMAIL PROTECTED]> > >It looks very like to me like a poster child for the non timestamp >RTT update problem I just described on netdev. Linux always >retransmits too early and there is never a better RTT estimate >which could fix it. > > I thought so too, _BUT_ see my analysis of the Linux side vs. > Win98 side logs, they don't match up and therefore something > is mangling the packets in the middle. The TCP sequence numbers are > being changed! Hmm. One of these weird bandwidth limiters again? > > Also, if your theory were true then 2.2.x would be affected > by it as well. 2.2 does not save RTTs between connections. The RTT is lower than 2.2's initial 3s RTT, so 2.2 would never see it. One useful experiment would be to flush the routing cache between attempts or turn off the tcp metrics saving (why don't we have a sysctl for that btw?) -Andi - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Tue, 7 Nov 2000 08:03:42 +0100 From: Andi Kleen <[EMAIL PROTECTED]> It looks very like to me like a poster child for the non timestamp RTT update problem I just described on netdev. Linux always retransmits too early and there is never a better RTT estimate which could fix it. I thought so too, _BUT_ see my analysis of the Linux side vs. Win98 side logs, they don't match up and therefore something is mangling the packets in the middle. The TCP sequence numbers are being changed! Also, if your theory were true then 2.2.x would be affected by it as well. Later, David S. Miller [EMAIL PROTECTED] - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 22:44:00 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> Attached to this message are dumps from the windows 98 machine using windump and the linux 2.4.0-test10. Sorry the time stamps don't match up. Ok, something is "odd" at the win98 side, I quote the win98 log: 22:34:36.069773 64.124.41.179. > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF) 22:34:36.069837 64.124.41.179. > 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF) Linux sends 1-->553 Since this is in the win98 log, it saw this data, but refuses to acknowledge it and the retransmit timeout expires on the Linux side. 22:34:39.049788 64.124.41.179. > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) So Linux resends 1-->21 22:34:39.051638 209.179.194.175.1084 > 64.124.41.179.: P 44:56(12) ack 21 win 65260 (DF) Win98 sends data, and only acknowledges the resent data from Linux. 22:34:39.245138 64.124.41.179. > 209.179.194.175.1084: P 21:555(534) ack 44 win 5840 (DF) 22:34:39.245208 64.124.41.179. > 209.179.194.175.1084: P 557:1091(534) ack 56 win 5840 (DF) Win98 machine receives bytes 21-->1091 from Linux, Linux also is acknowledging Win98's data up to 56, but... 22:34:41.739438 209.179.194.175.1084 > 64.124.41.179.: P 44:456(412) ack 21 win 65260 (DF) Win98 still claims it only saw up to byte 21 from Linux. Win98 also resends its data, therefore it has not seen Linux's ACKs either. And this goes on and on. Just to be absolutely sure, 64.124.41.179 is the Linux machine, right? If so, Win98 is dropping packets it did in fact receive correctly, before Win98's TCP has a look at them. WHOA, wait a second! From the Linux side log: 23:36:16.261533 64.124.41.179. > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) 23:36:16.261669 64.124.41.179. > 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF) 23:36:19.261055 64.124.41.179. > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) The equivalent packets from the win98 log: 22:34:36.069773 64.124.41.179. > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF) 22:34:36.069837 64.124.41.179. > 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF) 22:34:39.049788 64.124.41.179. > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) (ie. Linux sends bytes 1:21 both the first time, and when it retransmits that data. However win98 "sees" this as 1:19 the first time and 1:21 during the retransmit by Linux) That is bogus. Something is mangling the packets between the Linux machine and the win98 machine. You mentioned something about bandwidth limiting at your upstream provider, any chance you can have them turn this bandwidth limiting device off? Or maybe earthlink is using some packet mangling device? It is clear though, that something is messing with or corrupting the packets. One thing you might try is turning off TCP header compression for the PPP link, does this make a difference? Later, David S. Miller [EMAIL PROTECTED] - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
On Mon, Nov 06, 2000 at 10:03:05PM -0800, David S. Miller wrote: > The only thing I can do now is beg for a tcpdump from the windows95 > machine side. Do you have the facilities necessary to obtain this? > This would prove that it is packet drop between the two systems, for > whatever reason, that is causing this. It looks very like to me like a poster child for the non timestamp RTT update problem I just described on netdev. Linux always retransmits too early and there is never a better RTT estimate which could fix it. 2.4's advertised windows also do not seem to cope with weird window advertising strategy of windows (start with a small window and then suddenly increase it). Linux's stays small. -Andi - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date: Mon, 06 Nov 2000 22:13:23 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >There is a possibility that we are hitting an upper level bandwidth >limit between us an our upstream provider due to a misconfiguration >on the other end, but this should only happen during peak time >(which it is not right now). It just bugs me that 2.2.16 doesn't >appear to have this problem. > > The only thing I can do now is beg for a tcpdump from the windows95 > machine side. Do you have the facilities necessary to obtain this? > This would prove that it is packet drop between the two systems, for > whatever reason, that is causing this. Attached to this message are dumps from the windows 98 machine using windump and the linux 2.4.0-test10. Sorry the time stamps don't match up. Jordan 23:36:15.252817 209.179.194.175.1084 > 64.124.41.179.: S 370996:370996(0) win 8192 (DF) 23:36:15.252891 64.124.41.179. > 209.179.194.175.1084: S 3050526223:3050526223(0) ack 370997 win 5840 (DF) 23:36:16.159685 209.179.194.175.1084 > 64.124.41.179.: . ack 1 win 8576 (DF) 23:36:16.160461 209.179.194.175.1084 > 64.124.41.179.: . ack 1 win 65280 (DF) 23:36:16.160488 209.179.194.175.1084 > 64.124.41.179.: P 1:44(43) ack 1 win 65280 (DF) 23:36:16.160506 64.124.41.179. > 209.179.194.175.1084: . ack 44 win 5840 (DF) 23:36:16.261533 64.124.41.179. > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) 23:36:16.261669 64.124.41.179. > 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF) 23:36:19.261055 64.124.41.179. > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) 23:36:19.450762 209.179.194.175.1084 > 64.124.41.179.: P 44:56(12) ack 21 win 65260 (DF) 23:36:19.450788 64.124.41.179. > 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF) 23:36:19.450820 64.124.41.179. > 209.179.194.175.1084: P 557:1093(536) ack 56 win 5840 (DF) 23:36:22.281248 209.179.194.175.1084 > 64.124.41.179.: P 44:456(412) ack 21 win 65260 (DF) 23:36:22.281308 64.124.41.179. > 209.179.194.175.1084: . ack 456 win 6432 (DF) 23:36:25.441061 64.124.41.179. > 209.179.194.175.1084: P 21:557(536) ack 456 win 6432 (DF) 23:36:25.701796 209.179.194.175.1084 > 64.124.41.179.: . ack 557 win 65280 (DF) 23:36:25.701841 64.124.41.179. > 209.179.194.175.1084: P 557:1093(536) ack 456 win 6432 (DF) 23:36:25.701859 64.124.41.179. > 209.179.194.175.1084: P 1093:1629(536) ack 456 win 6432 (DF) 23:36:37.701091 64.124.41.179. > 209.179.194.175.1084: P 557:1093(536) ack 456 win 6432 (DF) 23:36:38.026766 209.179.194.175.1084 > 64.124.41.179.: . ack 1093 win 65280 (DF) 23:36:38.026826 64.124.41.179. > 209.179.194.175.1084: P 1093:1629(536) ack 456 win 6432 (DF) 23:36:38.026839 64.124.41.179. > 209.179.194.175.1084: P 1629:1847(218) ack 456 win 6432 (DF) 23:37:02.021068 64.124.41.179. > 209.179.194.175.1084: P 1093:1629(536) ack 456 win 6432 (DF) 23:37:02.328163 209.179.194.175.1084 > 64.124.41.179.: . ack 1629 win 65280 (DF) 23:37:02.328189 64.124.41.179. > 209.179.194.175.1084: P 1629:1847(218) ack 456 win 6432 (DF) 23:37:50.321057 64.124.41.179. > 209.179.194.175.1084: P 1629:1847(218) ack 456 win 6432 (DF) 23:37:50.673000 209.179.194.175.1084 > 64.124.41.179.: . ack 1847 win 65062 (DF) 23:37:50.673068 64.124.41.179. > 209.179.194.175.1084: P 1847:1868(21) ack 456 win 6432 (DF) 23:38:00.162380 209.179.194.175.1084 > 64.124.41.179.: F 456:456(0) ack 1847 win 65062 (DF) 23:38:00.181055 64.124.41.179. > 209.179.194.175.1084: . ack 457 win 6432 (DF) 23:38:00.187291 64.124.41.179. > 209.179.194.175.1084: F 1868:1868(0) ack 457 win 6432 (DF) 23:38:00.363357 209.179.194.175.1084 > 64.124.41.179.: . ack 1847 win 65062 (DF) 23:39:26.671050 64.124.41.179. > 209.179.194.175.1084: P 1847:1868(21) ack 457 win 6432 (DF) 23:39:26.886417 209.179.194.175.1084 > 64.124.41.179.: R 371453:371453(0) win 0 (DF) 22:34:34.884487 arp who-has 64.124.41.179 tell 209.179.194.175 22:34:34.889477 209.179.194.175.1084 > 64.124.41.179.: S 370996:370996(0) win 8192 (DF) 22:34:35.669892 64.124.41.179. > 209.179.194.175.1084: S 3050526223:3050526223(0) ack 370997 win 5840 (DF) 22:34:35.670624 209.179.194.175.1084 > 64.124.41.179.: . ack 1 win 8576 (DF) 22:34:35.670653 209.179.194.175.1084 > 64.124.41.179.: . ack 1 win 65280 (DF) 22:34:35.674484 209.179.194.175.1084 > 64.124.41.179.: P 1:44(43) ack 1 win 65280 (DF) 22:34:36.049808 64.124.41.179. > 209.179.194.175.1084: . ack 44 win 5840 (DF) 22:34:36.069773 64.124.41.179. > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF) 22:34:36.069837 64.124.41.179. > 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF) 22:34:39.049788 64.124.41.179. > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) 22:34:39.051638 209.179.194.175.1084 > 64.124.41.179.: P 44:56(12) ack 21 win 65260 (DF)
Re: malloc(1/0) ??
[EMAIL PROTECTED] asked:
> [Why does this program not crash?]
>
> main()
> {
>char *s;
>s = (char*)malloc(0);
>strcpy(s,"f");
>printf("%s\n",s);
> }
It doesn't crash because the standard malloc is
optimized for speed, not for finding bugs.
Try linking it with a debugging malloc, e.g.
cc bug.c -lefence
and watch it dump core.
- Dan
-
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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 22:13:23 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> There is a possibility that we are hitting an upper level bandwidth limit between us an our upstream provider due to a misconfiguration on the other end, but this should only happen during peak time (which it is not right now). It just bugs me that 2.2.16 doesn't appear to have this problem. The only thing I can do now is beg for a tcpdump from the windows95 machine side. Do you have the facilities necessary to obtain this? This would prove that it is packet drop between the two systems, for whatever reason, that is causing this. Later, David S. Miller [EMAIL PROTECTED] - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date: Mon, 06 Nov 2000 21:20:39 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >It looks to me like there is an artificial delay in 2.4.0 which is >slowing down the traffic to unbearable levels. > > No, I think I see whats wrong, it's nothing more than packet drop. > > Looking at the equivalent 220 traces, the only difference appears to > be that the packets are not getting dropped. I would like to note that these two machines the windows client is connecting to are sitting on the exact same switch connected to the same provider handling identical user loads. > Alexey, do you have any other similar reports wrt. the new MSS > advertisement scheme in 2.4.x? > > Jordan, you mentioned something about possibly being "bandwidth > limited"? Please, elaborate... There is a possibility that we are hitting an upper level bandwidth limit between us an our upstream provider due to a misconfiguration on the other end, but this should only happen during peak time (which it is not right now). It just bugs me that 2.2.16 doesn't appear to have this problem. Jordan - 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: rdtsc to mili secs?
Followup to: <[EMAIL PROTECTED]> By author:Antony Suter <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > This issue, and all related issues, need to be taken care of for all > speed changing CPUs from Intel, AMD and Transmeta. Is the answer of > "howto write userland programs correctly with a speed changing cpu" > in a FAQ somewhere? > At least in case of Transmeta, RDTSC will return wall time. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: 2.4.0-test10 -- Problem reading VFAT formatted ORB drive.
Andries Brouwer wrote: > On Tue, Nov 07, 2000 at 12:43:43AM -0800, Miles Lane wrote: > > >> I have an ORB drive I am accessing using the usb-storage driver. >> I formatted the drive media last night using Windoze 98. The media >> was formatted as though it had one large partition, which is weird >> because I had previously partitioned the drive under Linux 2.4.0-test10 >> with several partitions. The Windoze format utility did not notice >> those partitions and simply (I thought) wrote one large partition and >> formatted it as VFAT. I have successfully written and read data on >> the media using two separate Windoze 98 machines. When I mounted >> the drive under 2.4.0-test10 and then looked at the media with >> fdisk, here's what I see: >> >> #> fdisk /dev/sda >> >> Disk /dev/sda: 68 heads, 62 sectors, 1021 cylinders >> Units = cylinders of 4216 * 512 bytes >> >> Device BootStart EndBlocks Id System >> /dev/sda1 ?455397584533 272218546+ 20 Unknown >> Partition 1 has different physical/logical beginnings (non-Linux?): >> phys=(356, 97, 46) logical=(455396, 22, 59) > > ... > >> What's going on here? It seems to me that this is a bug in the >> Linux test10 filesystem support, since Windoze can read and write >> to this drive currently. Our implementation should be compatible. > > > Well, clearly (i) you can read it, and (ii) you don't like the contents. > With these removable disks there are often two possibilities: > either format the thing as a large floppy (without partition table) > or format it as a disk. > Maybe you did the former. (In that case, "mount /dev/sda" might work.) > > If you can't find out what happened, I wouldnt mind seeing > the first 64 sectors or so. > > (By the way, the geometry is interesting: 1021/68/62. > My web page says: > "The size is 2.2 GB. Castlewood recommends a C/H/S = 4273/16/63 geometry, >which multiplies out to 4307184 sectors, that is, 2205278208 bytes. >The default geometry with which the IDE version of the drive is shipped >gives only 528 MB." > Now 68*62*1021*512=2203922432, almost full capacity. I wonder who > invented it.) > > Andries > - > 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/ Thanks to you and Matt (who also sent this idea to me). You are correct, the drive got formatted with no partition table. I had never heard, before, that a disk could be formatted without a partition. I also am surprised to discover that the ORB drive got formatted this way. Thankyou both for the education! Miles - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 21:20:39 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> It looks to me like there is an artificial delay in 2.4.0 which is slowing down the traffic to unbearable levels. No, I think I see whats wrong, it's nothing more than packet drop. The large gaps in time seem to be due to packets being dropped: 22:00:39.991515 64.124.41.179. > 209.179.245.186.1092: P 1:21(20) ack 44 win 5840 (DF) 22:00:39.991660 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 44 win 5840 (DF) 3 seconds pass, retransmit time out. 22:00:42.991490 64.124.41.179. > 209.179.245.186.1092: P 1:21(20) ack 44 win 5840 (DF) Linux retransmits dropped data. 22:00:43.180946 209.179.245.186.1092 > 64.124.41.179.: P 44:56(12) ack 21 win 65260 (DF) Windows95 responds, acknowledges up to byte 21. 22:00:43.180997 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 44 win 5840 (DF) 22:00:43.181025 64.124.41.179. > 209.179.245.186.1092: P 557:1093(536) ack 56 win 5840 (DF) 22:00:45.685143 209.179.245.186.1092 > 64.124.41.179.: P 44:456(412) ack 21 win 65260 (DF) Linux resends bytes 21:556 and sends new data from 557:1093. Windows95 sends new data and ACKs only up to 21 (meaning presumably that all bytes sent by Linux this time were dropped). 22:00:45.685204 64.124.41.179. > 209.179.245.186.1092: . ack 456 win 6432 (DF) Linux acknowledges data received from Windows95 machine. A retransmit timeout occurs on the lost data. 22:00:49.171046 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 456 win 6432 (DF) 22:00:49.470193 209.179.245.186.1092 > 64.124.41.179.: . ack 557 win 65280 (DF) Linux resends 21:557, Windows95 (finally) acknowledges it. Looking at the equivalent 220 traces, the only difference appears to be that the packets are not getting dropped. Alexey, do you have any other similar reports wrt. the new MSS advertisement scheme in 2.4.x? Jordan, you mentioned something about possibly being "bandwidth limited"? Please, elaborate... Later, David S. Miller [EMAIL PROTECTED] - 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: [PATCH] Re: Negative scalability by removal of
Date:Mon, 6 Nov 2000 21:23:57 -0800 (PST) From: dean gaudet <[EMAIL PROTECTED]> apache is about correctness first, and performance second. Which is why we say it is "incorrect" for apache to try and work around kernel performance problems. :-))) Later, David S. Miller [EMAIL PROTECTED] - 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: [PATCH] Re: Negative scalability by removal of
On Mon, 6 Nov 2000, Linus Torvalds wrote: > This is why I'd love to _not_ see silly work-arounds in apache hey, maybe it's time for me to repeat something that i'm often quoted as saying: apache is about correctness first, and performance second. i don't think that's silly personally. remember most websites can be served fine off an anemic 486/33 with one ethernet port tied behind its back while doing a three legged race with a 6502 up a hill in san francisco during el nino. don't let the benchmarks fool ya! it's generally more important that a server be able to fork perl and parse CGIs fast than it is for it to accept an extra 1000 conns/s. apache-1.3.15 defines SINGLE_LISTEN_UNSERIALIZED_ACCEPT on linux 2.2 and later. dunno when the release date will be... someone go find a security flaw and it'll push up the release ;) (p.s. and rbb promised to forward the change into 2.0 and rse said he'd forward the change into mm, all of which were based off the same code.) -dean - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date:Mon, 06 Nov 2000 18:17:19 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >18:54:57.394894 eth0 > 64.124.41.177. > 209.179.248.69.1238: . >2429:2429(0) ack 506 win 6432 (DF) > > And this is it? The connection dies right here and says no > more? Surely, there was more said on this connection after > this point. > > Otherwise I see nothing obviously wrong in these dumps. I've provided two new dumps of the complete connection lifetime between 2.4.0 and 2.2.16. Both logs show the same client connecting to identical machines, receiving the same data and then disconnecting. 2.2.16 handles the entire process in under 5 seconds while 2.4.0 takes over 2 minutes. Also note that the 2.4.0 connection did not get shut down correctly and had to send an RST... though this is probably due to the client side closing down the connection while there was still data on it. Both machines were under approximately the same load. It looks to me like there is an artificial delay in 2.4.0 which is slowing down the traffic to unbearable levels. Jordan 22:00:39.625351 209.179.245.186.1092 > 64.124.41.179.: S 4155530:4155530(0) win 8192 (DF) 22:00:39.625437 64.124.41.179. > 209.179.245.186.1092: S 1301092473:1301092473(0) ack 4155531 win 5840 (DF) 22:00:39.887133 209.179.245.186.1092 > 64.124.41.179.: . ack 1 win 8576 (DF) 22:00:39.887969 209.179.245.186.1092 > 64.124.41.179.: . ack 1 win 65280 (DF) 22:00:39.888951 209.179.245.186.1092 > 64.124.41.179.: P 1:44(43) ack 1 win 65280 (DF) 22:00:39.888964 64.124.41.179. > 209.179.245.186.1092: . ack 44 win 5840 (DF) 22:00:39.991515 64.124.41.179. > 209.179.245.186.1092: P 1:21(20) ack 44 win 5840 (DF) 22:00:39.991660 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 44 win 5840 (DF) 22:00:42.991490 64.124.41.179. > 209.179.245.186.1092: P 1:21(20) ack 44 win 5840 (DF) 22:00:43.180946 209.179.245.186.1092 > 64.124.41.179.: P 44:56(12) ack 21 win 65260 (DF) 22:00:43.180997 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 44 win 5840 (DF) 22:00:43.181025 64.124.41.179. > 209.179.245.186.1092: P 557:1093(536) ack 56 win 5840 (DF) 22:00:45.685143 209.179.245.186.1092 > 64.124.41.179.: P 44:456(412) ack 21 win 65260 (DF) 22:00:45.685204 64.124.41.179. > 209.179.245.186.1092: . ack 456 win 6432 (DF) 22:00:49.171046 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 456 win 6432 (DF) 22:00:49.470193 209.179.245.186.1092 > 64.124.41.179.: . ack 557 win 65280 (DF) 22:00:49.470233 64.124.41.179. > 209.179.245.186.1092: P 557:1093(536) ack 456 win 6432 (DF) 22:00:49.470248 64.124.41.179. > 209.179.245.186.1092: P 1093:1629(536) ack 456 win 6432 (DF) 22:01:01.461056 64.124.41.179. > 209.179.245.186.1092: P 557:1093(536) ack 456 win 6432 (DF) 22:01:01.755362 209.179.245.186.1092 > 64.124.41.179.: . ack 1093 win 65280 (DF) 22:01:01.755428 64.124.41.179. > 209.179.245.186.1092: P 1093:1629(536) ack 456 win 6432 (DF) 22:01:01.755451 64.124.41.179. > 209.179.245.186.1092: P 1629:1825(196) ack 456 win 6432 (DF) 22:01:25.751048 64.124.41.179. > 209.179.245.186.1092: P 1093:1629(536) ack 456 win 6432 (DF) 22:01:26.171932 209.179.245.186.1092 > 64.124.41.179.: . ack 1629 win 65280 (DF) 22:01:26.171979 64.124.41.179. > 209.179.245.186.1092: P 1629:1825(196) ack 456 win 6432 (DF) 22:02:14.171052 64.124.41.179. > 209.179.245.186.1092: P 1629:1825(196) ack 456 win 6432 (DF) 22:02:14.499920 209.179.245.186.1092 > 64.124.41.179.: . ack 1825 win 65084 (DF) 22:02:14.499944 64.124.41.179. > 209.179.245.186.1092: P 1825:1847(22) ack 456 win 6432 (DF) 22:02:16.168708 209.179.245.186.1092 > 64.124.41.179.: F 456:456(0) ack 1825 win 65084 (DF) 22:02:16.181061 64.124.41.179. > 209.179.245.186.1092: . ack 457 win 6432 (DF) 22:02:16.281724 64.124.41.179. > 209.179.245.186.1092: F 1847:1847(0) ack 457 win 6432 (DF) 22:02:16.477943 209.179.245.186.1092 > 64.124.41.179.: . ack 1825 win 65084 (DF) 22:03:50.491063 64.124.41.179. > 209.179.245.186.1092: P 1825:1847(22) ack 457 win 6432 (DF) 22:03:50.680141 209.179.245.186.1092 > 64.124.41.179.: R 4155987:4155987(0) win 0 (DF) 22:00:01.684927 209.179.245.186.1091 > 64.124.41.136.: S 4033171:4033171(0) win 8192 (DF) 22:00:01.685021 64.124.41.136. > 209.179.245.186.1091: S 1261602556:1261602556(0) ack 4033172 win 32696 (DF) 22:00:01.916120 209.179.245.186.1091 > 64.124.41.136.: . ack 1 win 8576 (DF) 22:00:01.916191 209.179.245.186.1091 > 64.124.41.136.: . ack 1 win 65280 (DF) 22:00:01.916981 209.179.245.186.1091 > 64.124.41.136.: P 1:44(43) ack 1 win 65280 (DF) 22:00:01.917032 64.124.41.136. > 209.179.245.186.1091: . ack 44 win 32696 (DF) 22:00:02.121143 64.124.41.136. > 209.179.245.186.1091: P 1:21(20) ack 44 win 32696 (DF) 22:00:02.121279 64.124.41.136. > 209.179.245.186.1091: P
Re: rdtsc to mili secs?
Anton Blanchard wrote: > > > > fast_gettimeoffset_quotient, see do_fast_gettimeoffset(). > > > > Also remember that the TSC may not be available due to the chip era, chip > > bugs or running SMP with non matched CPU clocks. > > When I boot my thinkpad 600e off battery and then change to AC power, > gettimeofday has a nasty habit of going backwards. Stephen Rothwell > tells me it is one of these machines in which the cycle counter > slows down when power is removed. > > This means our offset calculations in do_fast_gettimeoffset are way off > and taking a reading just before a timer tick and just after results in > a negative interval. Perhaps we should disable tsc based gettimeofday > for these type of machines. This issue, and all related issues, need to be taken care of for all speed changing CPUs from Intel, AMD and Transmeta. Is the answer of "howto write userland programs correctly with a speed changing cpu" in a FAQ somewhere? -- - Antony Suter ([EMAIL PROTECTED]) "Examiner" openpgp:71ADFC87 - "And how do you store the nuclear equivalent of the universal - solvent?" - 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: Persistent module storage - modutils design
On Tue, 07 Nov 2000 15:00:11 +1100, Keith Owens <[EMAIL PROTECTED]> wrote: >insmod takes parameters from modules.conf, from the saved persistent >data (see below) and from the command line, in that order. The last >value for a parameter takes precedence. Correction: modprobe takes parameters from ... insmod only does exactly what you tell it to. It does not get parameter values from modules.conf or anywhere else, only from the command line. - 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: Can EINTR be handled the way BSD handles it? -- a plea from auser-land programmer...
On Mon, 6 Nov 2000, George Talbot wrote:
> I respectfully disagree that programs which don't surround some of the
> most common system calls with
>
> do
> {
> rv = __some_system_call__(...);
> } while (rv == -1 && errno == EINTR);
welcome to Unix. this is how it is, and it's not just linux. and it's
not just glibc/linuxthreads. in your code do you go about setting all
signals to SA_RESTART? if not then you're subject to the vagaries of
whatever the default signal settings are.
ted mentioned ^Z... there's also strace/truss/ktrace (depending on your
flavour of unix). there's also page-out/in (and on some unixes there's
swap-out/in).
it's something which bites lots of folks. gnu tar had this bug for at
least 5 years, and may still have it -- i got tired of submitting the bug
fix.
-dean
-
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: 2.4.0-test10 -- Problem reading VFAT formatted ORB drive.
On Tue, Nov 07, 2000 at 12:43:43AM -0800, Miles Lane wrote: > I have an ORB drive I am accessing using the usb-storage driver. > I formatted the drive media last night using Windoze 98. The media > was formatted as though it had one large partition, which is weird > because I had previously partitioned the drive under Linux 2.4.0-test10 > with several partitions. The Windoze format utility did not notice > those partitions and simply (I thought) wrote one large partition and > formatted it as VFAT. I have successfully written and read data on > the media using two separate Windoze 98 machines. When I mounted > the drive under 2.4.0-test10 and then looked at the media with > fdisk, here's what I see: > > #> fdisk /dev/sda > > Disk /dev/sda: 68 heads, 62 sectors, 1021 cylinders > Units = cylinders of 4216 * 512 bytes > > Device BootStart EndBlocks Id System > /dev/sda1 ?455397584533 272218546+ 20 Unknown > Partition 1 has different physical/logical beginnings (non-Linux?): > phys=(356, 97, 46) logical=(455396, 22, 59) ... > > What's going on here? It seems to me that this is a bug in the > Linux test10 filesystem support, since Windoze can read and write > to this drive currently. Our implementation should be compatible. Well, clearly (i) you can read it, and (ii) you don't like the contents. With these removable disks there are often two possibilities: either format the thing as a large floppy (without partition table) or format it as a disk. Maybe you did the former. (In that case, "mount /dev/sda" might work.) If you can't find out what happened, I wouldnt mind seeing the first 64 sectors or so. (By the way, the geometry is interesting: 1021/68/62. My web page says: "The size is 2.2 GB. Castlewood recommends a C/H/S = 4273/16/63 geometry, which multiplies out to 4307184 sectors, that is, 2205278208 bytes. The default geometry with which the IDE version of the drive is shipped gives only 528 MB." Now 68*62*1021*512=2203922432, almost full capacity. I wonder who invented it.) Andries - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 19:44:57 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> Just some updates. This problem does not appear to happen under 2.2.16. The dump for 2.2.16 is almost the same except we send an mss back of 536 and not 1460 (remote mtu vs local mtu). MSS advertized makes no difference, it controls not what sized payloads we send, which is determined in this case by PMTU and thus both Linux 2.2.x and 2.4.x send equally sized limited packets. Later, David S. Miller [EMAIL PROTECTED] - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date:Mon, 06 Nov 2000 18:17:19 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> 18:54:57.394894 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 2429:2429(0) ack 506 win 6432 (DF) And this is it? The connection dies right here and says no more? Surely, there was more said on this connection after this point. Otherwise I see nothing obviously wrong in these dumps. Later, David S. Miller [EMAIL PROTECTED] - 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: kernel
Joe Harrington wrote: > > Sorry about the question to do with visuall gcc. Alot of people seemed to > get a intolerable response to my question. The reason I posted it here was > a) I am lazy, b) On all the sites to do with Kdevelop the download links are > down, and c) I wanted to use the program to compile such files as schedule.c > and other scheduling algorithms I create. What do most of you use to comile > the kernel, just good ole' command line gcc. Definitely. As much as I appreciate the efforts to make a workable end-user GUI for Linux, I think people are still going to have to get used to using command-line tools at the moment. For what it's worth, there are two visual configuration options for the kernel; for a text console, you can use "make menuconfig" while you can use "make xconfig" if you're really into X. Personally, I found the standard "make config" useful only the first time around, because it forced me to look at every option, but it's much easier to undo mistakes using menuconfig or xconfig. - 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/
sound driver persistent state
People keep saying it's OK to start muted on boot, but I must say that I don't think this is really acceptable I may very well want to set my mixer and just leave it that way forever would there be any way to give the sound driver a scribble pad on disk to let it sa -- This message has been brought to you by the letter alpha and the number pi. David Feuer [EMAIL PROTECTED] - 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: Pentium 4 and 2.4/2.5
On Sat, 4 Nov 2000, Frank Davis hissed: > I noticed that Pentium 4 isn't an config option in 2.4.0-test10. Is > someone working on a patch for the the kernel (if needed) to support the > Pentium 4 after 2.4.0 is released? from what i have read of the Pentium IV, the linux kernel will not need any patches to run successfully. that being said, a lot of oppurtunity exists for optimization, i bet. some 686-core optimizations may need to be rethought, but there is at least some things we can better do to take advantage of the P4. if nothing else, the new pipeline size and cache- -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Persistent module storage - modutils design
Enough people have asked for persistent module storage to at least
justify me writing the code. The design is simple.
MODULE_PARM(var,type) currently defines type as [min[-max]]{b,h,i,l,s}.
For persistent data support, type is now [min[-max]]{b,h,i,l,s}{p}, the
trailing 'p' for persistent is optional. Existing modutils only checks
one character after [min[-max]] so this is backwards compatible, no
need to upgrade modutils unless you want persistent data.
insmod takes parameters from modules.conf, from the saved persistent
data (see below) and from the command line, in that order. The last
value for a parameter takes precedence.
rmmod locates the object for the module using the __insmod_xxx_O ksyms
entry. If the object cannot be found or its timestamp has changed
since it was loaded then rmmod silently skips the persistent data.
Otherwise rmmod uses the .modinfo data in that object to determine the
address and type of the persistent parameters. Each persistent
parameter is extracted from the module being unloaded, formatted as a
module parameter (e.g. "irq=17") and written to /somewhere/module_name
which is a text file (vi is the ultimate configuration tool).
Almost all support is in user space. The only kernel change is to add
'p' to the end of module parameters that are to be persistent. Module
variables that are to be persistent and are not currently module
parameters need to be defined as MODULE_PARM(). The same kernel code
should work on 2.2 and 2.4 kernels, it should even work with modutils
2.1.121.
I have not decided where to save the persistent module parameters. It
could be under /lib/modules//persist or it could be under
/var/log or /var/run. I am tending towards /var/run/module_persist, in
any case it will be a modules.conf parameter.
-
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/
malloc(1/0) ??
hi,
why does this program works. when executed, it doesnt
give a segmentation fault. when the program requests
memory, is a standard chunk is allocated irrespective
of the what the user specifies. please explain.
main()
{
char *s;
s = (char*)malloc(0);
strcpy(s,"f");
printf("%s\n",s);
}
NOTE:
i know its a 'C' problem. but i wanted to know how
this works
__
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one Place.
http://shopping.yahoo.com/
-
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/
kernel
Sorry about the question to do with visuall gcc. Alot of people seemed to get a intolerable response to my question. The reason I posted it here was a) I am lazy, b) On all the sites to do with Kdevelop the download links are down, and c) I wanted to use the program to compile such files as schedule.c and other scheduling algorithms I create. What do most of you use to comile the kernel, just good ole' command line gcc. - 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: [PATCH] document ECN in 2.4 Configure.help
From: Bernd Eckenfels <[EMAIL PROTECTED]> Date:Tue, 07 Nov 2000 03:38:35 +0100 Because this will add a Fallback (non ECN) packet to every denied target. I think this is bad policy at least. It might violate the RFCs, too. Keep in mind, we cannot recognice a rejection due to ECN. It does in fact violate RFCs because the fallback has to handle the case where ECN rejection comes in the form of a (perfectly valid) TCP reset. Any workaround which ignores TCP resets is broken from the start and is not to be implemented. Later, David S. Miller [EMAIL PROTECTED] - 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: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Jordan Mendelson wrote: > > We are seeing a performance slowdown between Windows PPP users and > servers running 2.4.0-test10. Attached is a tcpdump log of the > connection. The machines is without TCP ECN support. The Windows machine > is running Windows 98 SE 4.10. A dialed up over PPP w/ TCP header > compression. The Linux machine is connected directly to the Internet via > a 6509. There is a possibility that we are hitting a bandwidth cap on > outgoing traffic. Just some updates. This problem does not appear to happen under 2.2.16. The dump for 2.2.16 is almost the same except we send an mss back of 536 and not 1460 (remote mtu vs local mtu). Here is the head of a tcpdump with the same client, but this time with a 2.2.16 machine instead of a 2.4.0-test10 machine: 19:26:23.593114 eth0 < 209.179.248.69.1260 > 64.124.41.136.: S 5061245:5061245(0) win 8192 (DF) 19:26:23.593237 eth0 > 64.124.41.136. > 209.179.248.69.1260: S 119520695:119520695(0) ack 5061246 win 32696 (DF) 19:26:23.824394 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 1:1(0) ack 1 win 65280 (DF) 19:26:23.824398 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 1:1(0) ack 1 win 8576 (DF) 19:26:23.825249 eth0 < 209.179.248.69.1260 > 64.124.41.136.: P 1:44(43) ack 1 win 65280 (DF) 19:26:23.825283 eth0 > 64.124.41.136. > 209.179.248.69.1260: . 1:1(0) ack 44 win 32696 (DF) 19:26:25.245845 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 1:21(20) ack 44 win 32696 (DF) 19:26:25.245956 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 21:342(321) ack 44 win 32696 (DF) 19:26:25.466759 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 44:44(0) ack 342 win 64939 (DF) 19:26:25.466792 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 342:878(536) ack 44 win 32696 (DF) 19:26:25.466800 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 878:1401(523) ack 44 win 32696 (DF) 19:26:25.467562 eth0 < 209.179.248.69.1260 > 64.124.41.136.: P 44:56(12) ack 342 win 64939 (DF) 19:26:25.480104 eth0 > 64.124.41.136. > 209.179.248.69.1260: . 1401:1401(0) ack 56 win 32696 (DF) 19:26:25.763509 eth0 < 209.179.248.69.1260 > 64.124.41.136.: P 56:456(400) ack 878 win 65280 (DF) 19:26:25.766253 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 456:456(0) ack 1401 win 64757 (DF) 19:26:26.070115 eth0 > 64.124.41.136. > 209.179.248.69.1260: . 1401:1401(0) ack 456 win 32296 (DF) 19:26:26.431515 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 1401:1413(12) ack 456 win 32696 (DF) 19:26:26.432141 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 1413:1684(271) ack 456 win 32696 (DF) 19:26:26.657631 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 456:456(0) ack 1684 win 65280 (DF) 19:26:26.657663 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 1684:1817(133) ack 456 win 32696 (DF) 19:26:26.952825 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 456:456(0) ack 1817 win 65147 (DF) 19:26:31.086138 eth0 < 209.179.248.69.1260 > 64.124.41.136.: P 456:506(50) ack 1817 win 65147 (DF) > 18:51:33.282286 eth0 < 209.179.248.69.1238 > 64.124.41.177.: S > 3013389:3013389(0) win 8192 (DF) > 18:51:33.282395 eth0 > 64.124.41.177. > 209.179.248.69.1238: S > 2198113890:2198113890(0) ack 3013390 win 5840 > (DF) > 18:51:33.509532 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . > 1:1(0) ack 1 win 8576 (DF) > 18:51:33.510360 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . > 1:1(0) ack 1 win 65280 (DF) > 18:51:33.510416 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P > 1:44(43) ack 1 win 65280 (DF) > 18:51:33.510457 eth0 > 64.124.41.177. > 209.179.248.69.1238: . > 1:1(0) ack 44 win 5840 (DF) > 18:51:33.988330 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 1:21(20) ack 44 win 5840 (DF) > 18:51:33.988474 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 21:557(536) ack 44 win 5840 (DF) > 18:51:36.987336 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 1:21(20) ack 44 win 5840 (DF) > 18:51:37.12 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P > 44:56(12) ack 21 win 65260 (DF) > 18:51:37.177794 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 21:557(536) ack 44 win 5840 (DF) > 18:51:37.177806 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 557:1093(536) ack 56 win 5840 (DF) > 18:51:39.845046 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P > 44:456(412) ack 21 win 65260 (DF) > 18:51:39.845071 eth0 > 64.124.41.177. > 209.179.248.69.1238: . > 1093:1093(0) ack 456 win 6432 (DF) > 18:51:43.177329 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 21:557(536) ack 456 win 6432 (DF) > 18:51:43.538219 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . > 456:456(0) ack 557 win 65280 (DF) > 18:51:43.538275 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 557:1093(536) ack 456 win 6432 (DF) > 18:51:43.538292 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 1093:1629(536) ack 456 win 6432 (DF) > 18:51:55.537346 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 557:1093(536) ack 456
Re: Pentium 4 and 2.4/2.5
Not to worry, some of us are working with the 'I' guys to do proper P4 detection. Cheers, On Sat, 4 Nov 2000, Frank Davis wrote: > Hello, > I noticed that Pentium 4 isn't an config option in 2.4.0-test10. Is > someone working on a patch for the the kernel (if needed) to support the > Pentium 4 after 2.4.0 is released? > > Regards, > Frank > - > 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/ > Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - 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: ide-probe.c:400: `rtc_lock' undeclared and /lib/modules/..../build
On Tue, 7 Nov 2000 01:20:36 +0100 (CET), Tomasz Motylewski <[EMAIL PROTECTED]> wrote: >2.2.18pre19: >And , whose idea was that "make modules_install" should create >/lib/modules//build symlink to the kernel sources? >It really breakes depmod -a (modutils 2.3.11)(*) > >(*) I could find a workaround, but if it hits me, it will hit lots of other >people not reading linux-kernel regularly. In my opinion upgrading stable >kernels should work without any modifications to the existing system. Agreed, I was unhappy that the build symlink was added to 2.2 kernels. Now you need modutils >= 2.3.14 for 2.2 kernels :(. But nobody asks me, I'm just the kernel module.[ch] and modutils maintainer. - 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: [HARDLOCK] 2.2.17 locks up hard on Ultra66/PDC20262 in DMA modewhen using ide + raid-A0 + eepro100 patches
UPDATE:
Now I have upgraded to 2.2.18pre19 + ide-2.2.18pre18 + raid-2.2.18-A2 +
patched eepro100.
Unfortunately, I still get:
hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hde: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=15347359,
sector=15347328
hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hde: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=15347359,
sector=15347328
hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hde: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=15347359,
sector=15347328
hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hde: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=15347359,
sector=15347328
after a few minutes/hours of uptime (60-180 minutes). I even tried some
SysRq keys and those wouldn't work. (hard lockup). So what do I try from
here? I d'nt think there is any way to disable DMA in the hardware (on
the Promise anyway). Should I pull out hde and throw in another seagate?
thanks for any ideas.
-dan
-
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: 2.4.0-test10 Oops
On Mon, 6 Nov 2000 23:03:44 +0100, Frank van Maarseveen <[EMAIL PROTECTED]> wrote: >First a firewall is installed (ppp0). Starting the network (eth0/lo only. ppp0 is >nonexistent at this point) gives the following Oops: >Nov 6 22:20:25 iapetus kernel: EIP: >0010:[ipt_REJECT:__insmod_ipt_REJECT_O/lib/modules/2.4.0-test10-x23/kernel/n+-92757/96] > > >[ipt_REJECT:__insmod_ipt_REJECT_O/lib/modules/2.4.0-test10-x23/kernel/n+-89253/96] klogd has tried to convert the addresses and got it completely wrong, leaving nothing useful for ksymoops. Change /etc/rc.d/init.d/syslog to run klogd as "klogd -x", restart klogd, reproduce the problem and run the result through ksymoops. - 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/
Pentium 4 and 2.4/2.5
Hello, I noticed that Pentium 4 isn't an config option in 2.4.0-test10. Is someone working on a patch for the the kernel (if needed) to support the Pentium 4 after 2.4.0 is released? Regards, Frank - 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/
locks.c: removal of semaphores
Andrew, I got 5250 Req/s with your locks-sem.patch on normal Apache. It is good performance on normal Apache. Andrew Morton writes: > Kouichi, could you please test the performance of this on > your 8-way with Apache+fcntl serialisation? (the normal > Apache). Please use 2.4.0-test10-pre5, not 2.4.0-test10. > Something has gone funny with test10 and I'm getting much > lower rates. Followings are the recent data with/without serialization. w/ serializew/o serialize 240t10pre5 22375358 240t10pre5+P2 52535355** 240t10pre5+P3 --- NG 240t10pre5+locksem 5250--- **: once we found deadlock NG: cannot complete measurement --: we've not measured. Normal apache on various kernel setting as follows: > test8 5287 <-- best performance > test10-pre5+P25258 > 240t10pre5+locksem5250 > test9+P2 5243 > test9+mypatch 5192 <-- a little bit worse > test10-pre5+P15187 > test1 3702 <-- no good scalability > test10-pre5 2255 <-- negative scalability > test9 2193 We also did durability test of 2.4.0-test10-pre5. Unfortunately enough, we didn't successfully complete the test of Apache w/o serialization (-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT), it couldn't continue to run for a night. The kernel got complete deadlock. The message is: "Unable to handle kernel NULL pointer dereference NMI watchdog detected LOCKUP on CPU1." Yes, obviously it's not Andrew's problem, that is genuine test10-pre5. Hidden bugs are awakened by removing serialization. If the bug is same as what I observed, It is NULL pointer dereference on run-queue list. -- Computer Systems Laboratory, Fujitsu Labs. [EMAIL PROTECTED] - 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: linux 2.4.0-test9
On Mon, 6 Nov 2000 16:31:23 -0500 (EST), "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: >However when running, the new kernel 2.4.0-test9, can't be used to >make a usable initrd ram disk. The result being that 2.4.0-test9 >can't, itself, build an "initrd" bootable system. > >Before everybody screams that I don't know what I'm doing, let me >assure you that I know that the two kernels put their modules in >different directories and the new directory scheme seems to require >the latest and greatest version of modutils. You also need the latest version of mkinitrd to handle the modules directory structure. - 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: Calling module symbols from inside the kernel !
On Mon, 6 Nov 2000 16:24:13 -0300, [EMAIL PROTECTED] wrote: >Is it possible to access symbols exported by modules from inside the kernel ? Not via symbol name, the linkage goes module => kernel, not the other way round. Your module needs to register its data when it loads, then any code can use the registration "get" function to access the data. This works kernel <=> kernel, kernel <=> module, module <=> module. Be careful that you lock the module down while you are using its data. See ftp://ftp.ocs.com.au/pub/2.4.0-test10-pre6-module-symbol.gz for sample registration code. - 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: [patch] NE2000
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > No, that code is correct, provided (current->state == TASK_RUNNING)
> > on entry. If it isn't, there's a race window which can cause
> > lost wakeups. As a check you could add:
> >
> > if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0)
> > BUG();
>
> Though it really cannot happen and really happens, as we have seen... 8)
>
> In any case, Andrew, where is the race, when we enter in sleeping state?
> Wakeup is not lost, it is just not required when we are not going
> to schedule and force task to running state.
>
> I still do not see how it is possible that task runs in sleeping state.
> Apparently, set_current_state is forgotten somewhere. Do you see, where? 8)
>
OK, there are a few areas which look fishy.
Calling __lock_sock when we're getting ready to wait
on a different waitqueue looks like a rather risky area.
We have a single task which is on two waitqueues.
Consider the case of tcp_data_wait():
add_wait_queue(sk->sleep)
set_current_state(TASK_INTERRUPTIBLE);
release_sock(sk);
if (...)/* Suppose this evaluates to false */
schedule_timeout();
lock_sock();
__lock_sock()
{
add_wait_queue_exclusive(sk->lock.wq);
/* Window 1: What does a wake_up(sk->sleep) do here? */
current->state = TASK_EXCLUSIVE | TASK_UNINTERRUPTIBLE;
/* Window 2: Bad things happen here */
schedule();
If someone does a wakeup(sk->sleep) in Window 2 in
__lock_sock() the wakeup code will think that the
task is sleeping on sk->sleep in state
TASK_EXCLUSIVE|TASK_UNINTERRUPTIBLE,
when in fact it is not. So a wakeup which _should_ have gone to
a different exclusive task actually goes to this one. This is
fantastically hard to hit because of the direction of the
waitqueue scan.
If the wakeup on sk->sleep happens during Window 1
it will be completely lost, but that's OK because
this task is not yet TASK_EXCLUSIVE (providing the
write ordering behaves as we want?)
If a wakeup on sk->lock.wq happens during Window 1
it will be completely lost.
wait_for_connect() and wait_for_tcp_memory() play similar
games with lock_sock() whereby they can appear to be on
two waitqueues at the same time. And again, because
lock_sock() uses TASK_EXCLUSIVE a wake_up on sk->sleep
could choose this task instead of a TASK_EXCLUSIVE task
which is _really_ sleeping on sk->sleep.
Now, this may not be a problem in practise, and in fact the
above may not be bugs because I missed something. But I suggest you
have a think about it. My brain is starting to hurt.
But none of these explain Jorge's problem. How he got to where
he did in !TASK_RUNNING. Plus the possible lock_sock problems
just look too damn hard to hit to explain Jorge's repeatability.
It may be useful to put a Pentium hardware watchpoint onto
current->state. Does kdb support those?
Can sock_fasync() be called when we're on a waitqueue, not in
state TASK_RUNNING and prior to schedule()?
inet_wait_for_connect() is OK.
wait_for_tcp_connect() is OK.
tcp_close() is OK.
Also, are you sure that all occurrences of
current->state = ;
are still safe on weakly ordered CPUs? (Not that this
would explain Jorge's problem).
hmm.. khttpd tries to do wake-one, but
interruptible_sleep_on_timeout() confounds it.
Bummer.
-
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: [PATCH] document ECN in 2.4 Configure.help
In article <[EMAIL PROTECTED]> you wrote: > I'm still not sure why it's been decided not to do fallback or how this > whole situation is any different from path MTU discovery. Because this will add a Fallback (non ECN) packet to every denied target. I think this is bad policy at least. It might violate the RFCs, too. Keep in mind, we cannot recognice a rejection due to ECN. Greetings Bernd - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
"James A. Sutherland" <[EMAIL PROTECTED]> said: [...] > That only happens if the driver is stupid enough to try guessing "correct" > volume settings. It did not touch anything: By a fluke, or by default, the sound output was going full blast, and the mike input was patched over to it ==> feedback shriek until (a few tenths of second later) the volume settings _were_ set. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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/
Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
We are seeing a performance slowdown between Windows PPP users and servers running 2.4.0-test10. Attached is a tcpdump log of the connection. The machines is without TCP ECN support. The Windows machine is running Windows 98 SE 4.10. A dialed up over PPP w/ TCP header compression. The Linux machine is connected directly to the Internet via a 6509. There is a possibility that we are hitting a bandwidth cap on outgoing traffic. 18:51:33.282286 eth0 < 209.179.248.69.1238 > 64.124.41.177.: S 3013389:3013389(0) win 8192 (DF) 18:51:33.282395 eth0 > 64.124.41.177. > 209.179.248.69.1238: S 2198113890:2198113890(0) ack 3013390 win 5840 (DF) 18:51:33.509532 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 1:1(0) ack 1 win 8576 (DF) 18:51:33.510360 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 1:1(0) ack 1 win 65280 (DF) 18:51:33.510416 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 1:44(43) ack 1 win 65280 (DF) 18:51:33.510457 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 1:1(0) ack 44 win 5840 (DF) 18:51:33.988330 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1:21(20) ack 44 win 5840 (DF) 18:51:33.988474 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 21:557(536) ack 44 win 5840 (DF) 18:51:36.987336 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1:21(20) ack 44 win 5840 (DF) 18:51:37.12 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 44:56(12) ack 21 win 65260 (DF) 18:51:37.177794 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 21:557(536) ack 44 win 5840 (DF) 18:51:37.177806 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 557:1093(536) ack 56 win 5840 (DF) 18:51:39.845046 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 44:456(412) ack 21 win 65260 (DF) 18:51:39.845071 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 1093:1093(0) ack 456 win 6432 (DF) 18:51:43.177329 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 21:557(536) ack 456 win 6432 (DF) 18:51:43.538219 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 557 win 65280 (DF) 18:51:43.538275 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 557:1093(536) ack 456 win 6432 (DF) 18:51:43.538292 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1093:1629(536) ack 456 win 6432 (DF) 18:51:55.537346 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 557:1093(536) ack 456 win 6432 (DF) 18:51:55.841360 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 1093 win 65280 (DF) 18:51:55.841384 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1093:1629(536) ack 456 win 6432 (DF) 18:51:55.841393 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1629:1849(220) ack 456 win 6432 (DF) 18:52:19.837335 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1093:1629(536) ack 456 win 6432 (DF) 18:52:20.153776 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 1629 win 65280 (DF) 18:52:20.153803 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1629:1849(220) ack 456 win 6432 (DF) 18:53:08.147334 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1629:1849(220) ack 456 win 6432 (DF) 18:53:08.475911 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 1849 win 65060 (DF) 18:53:08.475947 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1849:1871(22) ack 456 win 6432 (DF) 18:54:44.467332 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1849:1871(22) ack 456 win 6432 (DF) 18:54:44.824187 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 1871 win 65038 (DF) 18:54:44.824256 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1871:1893(22) ack 456 win 6432 (DF) 18:54:55.212750 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 456:506(50) ack 1871 win 65038 (DF) 18:54:55.212767 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 1893:1893(0) ack 506 win 6432 (DF) 18:54:55.571337 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1893:2429(536) ack 506 win 6432 (DF) 18:54:57.394879 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 456:506(50) ack 1871 win 65038 (DF) 18:54:57.394894 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 2429:2429(0) ack 506 win 6432 (DF) Here are some numbers from /proc/sys/net/ipv4: $ cat /proc/sys/net/ipv4/tcp_rmem 409687380 174760 $ cat /proc/sys/net/ipv4/tcp_wmem 409616384 131072 $ cat /proc/sys/net/ipv4/tcp_sack 1 $ cat /proc/sys/net/ipv4/tcp_fack 1 $ cat /proc/sys/net/ipv4/tcp_dsack 1 $ cat /proc/sys/net/ipv4/tcp_window_scaling 1 $ cat /proc/sys/net/ipv4/tcp_syncookies 0 $ cat /proc/sys/net/ipv4/tcp_timestamps 1 Jordan - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000 23:00:05 + (GMT), Paul Jakma <[EMAIL PROTECTED]> wrote: >On Mon, 6 Nov 2000, Alan Cox wrote: >> Its called modules.conf. It has all these nice preload directives in it > >cool.. > >doesn't seem to be documented though in modutils 2.3.17. what exactly >does it do? man modules.conf (yes, it _is_ documented). - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On 06 Nov 2000 11:09:41 -0700, [EMAIL PROTECTED] (Eric W. Biederman) wrote: >Well we don't have auto unload. Check crontab, if it contains rmmod -a then you have auto unload. - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
Martin Mares <[EMAIL PROTECTED]> said:
[...]
> I think that automatic loading / unloading of modules has been a terrible hack
> since its first days (although back in these times a useful one) and that the
> era of its usefulness is over. There are zillions of problems with this
> mechanism, the most important ones being:
Strange somebody from a distribution forgets _the_ most important use of
modules: Remember old-time Slackware, with dozens of different boot
diskettes, and the imperative to compile a kernel to your machine once you
got it running?
>o It would have to preserve _complete_ device state over module
> reload.
If too hard, just leave it alone: Don't allow unloading.
>o For many drivers, the "device currently open" concept makes no
> sense.
Ditto.
>o It interferes with hotplug in nasty ways. Let's have a USB host
> controller driver with currently no devices on its bus. It's also an
> example of a zero use count driver, but it also must not be unloaded
> as it's needed for recognizing newly plugged in devices.
Ditto.
> I don't argue whether we need or need not some kind of persistent storage
> for the modules (it might be a good idea when it comes to hotplug, but it
> should be probably taken care of by the userspace hotplug helpers), but I
> think that it has no chance to solve the problems with automatic
> unloading.
The cases mentioned are cases where unloading (automatic or manual, doesn't
matter) would break things. Just don't allow it, ever (IPv6 does this, for
one example). Or fix the loading/unloading somehow. Strategies to be able
to do so is what is being discussed here, BTW...
> We could of course attempt to circumvent the problems listed above by
> adding some hints to module state which will say whether it's possible to
> auto-unload the module or not even if it has zero use count,
Just force a non-zero count as long as the module is in use. Wait a
minute... that is exactly what a non-zero count is supposed to mean!
> but it means
> another thing to handle in all the drivers (well, at least another thing
> to think of whether it's needed or not for each driver) and I think that
> the total effect of the autounloading mechanism (a minimum amount of
> memory saved) in no way outweighs the cost of implementing it right.
What is a "minimal ammount of memory" on the 1+Gb RAM machines I've seen
discussed here isn't at all "minimal" for somebody who has to run Linux in
4Mb, preferably less...
Linux came to be what it is today in large part because the PC nobody
wanted anymore ("too slow", "can't run XYZ") became the router/firewall/web
server/mail server/... over in some closet, and soon nobody even remembered
where the machine was physically. Don't kill this.
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
-
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: Persistent module storage [was Linux 2.4 Status / TODO page]
Oliver Xymoron <[EMAIL PROTECTED]> say: [...] > Ioctl (or alternate device for plan9 groupies) is fine. My point is final > initialization of the device is obviously delayed until the firmware is > loaded. Let's play perverse: What if I load the module, but don't initialize the firmware, then unload? The fact that the firmware has been initialized has to be kept somewhere... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
David Woodhouse <[EMAIL PROTECTED]> said: [...] > No. You should initialise the hardware completely when the driver is > reloaded. Although the expected case is that the levels just happen to be > the same as the last time the module was loaded, you can't know that the > machine hasn't been suspended and resumed since then. Oh? Suspending with the module loaded is forbidden then? -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
David Woodhouse <[EMAIL PROTECTED]> said: > [EMAIL PROTECTED] said: > > No funny "persistent data" mechanisms or screwups when the worker > > gets removed and reinserted. In many cases the data module could be > > shared among several others, in other cases it would have to be able > > lo load several times or manage several incarnations of its payload. > The reason I brought this up now is because Keith's new > inter_module_register stuff could easily be used to provide this > functionality _without_ the extra module remaining loaded. AFAIU, this is a acknowledged wart, to be added if there is no sane way out. Better just loose it before it gets into the kernel, no? -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
"James A. Sutherland" <[EMAIL PROTECTED]> said: > On Mon, 06 Nov 2000, Horst von Brand wrote: [...] > > The problem (AFAIU) is that if the levels aren't set on startup, they are > > random in some cases. > So set them on startup. NOT when the driver is first loaded. Put it in > the rc.d scripts. There is a noticeable delay between to moment the module is insmod(8)ed, and the moment when its settings are set by the startup script. Not funny if it is going full blast ATM. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
> Then none of this is relevant to you, since you can't unload any modules! And > now you're the one doing the trolling... WTF do you think module code is > supposed to do when you don't use modules?! > Simple ... I'd rather the hardware was set to 0 on startup but I know what problems that presents to modules.. And no it wasn't the driver doing it afik. Sound card starts on max volume as soon as it's initialised. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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/
Comprehensive list of locks available?
Now that we've taken to heart the "one lock does not fit all" and we made the kernel increasingly fine-grained with regards to locking, there are many more locks appearing in the code. While Linux does not currently support hierarchical locks, it is still true that the order in which you acquire multiple locks (when needed) can be your first defense against inadvertent deadlock. Knowing how to properly utilize a lock is becoming increasingly important. Has anybody documented, in total or in part, how the various locks are to be used? A quick scan of the 2.4 source indicates there may be more than 400 non-static spinlocks right now. I've checked the Documentation directory and although there's a little "how-to" from Linus there on how to properly use spinlocks, there does not (yet) appear to be any document on the proper use of specific spinlocks. I suspect once I start digging that there will undoubtedly be nuggets of information in the comments in the source code. But before I dig too deep, let me make sure I'm not doing unnecessarily redundant work :) Has anybody started on such a document? (Would anybody be willing to contribute to one if I produce and coordinate it?) Rick - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 07 Nov 2000, Gerhard Mack wrote: > On Tue, 7 Nov 2000, James A. Sutherland wrote: > > > On Mon, 06 Nov 2000, Gerhard Mack wrote: > > > Sure .. lets see you start a laptop in class or buisness meeting and have > > > everyone turn to look at you wondering why your laptop let off an ear > > > piercing shreak because the hardware defaults to all settings max. > > > > That only happens if the driver is stupid enough to try guessing "correct" > > volume settings. If it leaves well alone until it KNOWS the correct settings, > > there is no ear piercing shriek. Nor is there any break in the sound if you > > were listening to something from the mixer. > > > > > And you will _STILL_ have that shriek for 1/2 - 1 second before the > > > userspace app loads. > > > > Wrong. The userspace app is the one triggering the device init, when it gives > > the sound driver the correct volume settings. There is no half second delay. > > > > > And no we couldn't unplug either the mike or the speakers since they come > > > embedded in the laptop's case. > > > > > > I don't see in any of your trolling an answer for this problem. > > > > It isn't trolling, and there is a perfectly simple answer, as I have already > > explained. > > > > And if I don't use modules? Then none of this is relevant to you, since you can't unload any modules! And now you're the one doing the trolling... WTF do you think module code is supposed to do when you don't use modules?! James. - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 07 Nov 2000, Alan Cox wrote: > > changing settings. If I plug in a hotplug soundcard and load the driver, I do > > NOT want the driver to decide to set some settings. If I want settings set, > > I'll do it myself (or have a script to do it). > > How about if your stuff is already nicely set up and you remove then replug > a device, When I plug it in and modprobe is triggered to load the driver, a script then runs to feed the device appropriate configuration info. Since the driver only resets the hardware when it is given the correct configuration, there's no problem. > or remove and swap for an identical replacement part. Most people then > want the configuration preserved. Hmm... define "identical". I take a laptop home, use a USB NIC to talk to my LAN at home (using NAT) with a 192.168.* address. Then I take it elsewhere and use the same model of NIC on the college LAN. All of a sudden, I get myself banging on the door complaining about misconfigured NICs :-) > And guess what the simple modutils solution using an ELF section solves that > too Want to go to default configuration ? > > rm /var/run/modules/eth0.data > > or wrap it in a GUI. That sounds a lot like what I've been advocating all along, if that file is created/updated by a script when eth0's driver is unloaded, then fed back to eth0 on load. > [BTW windows gets the USB speaker state management right, seems they store all > the module persistent data in the registry!] Yes, that's what we need. A registry, so configuration problems can be persistent across boots, and even reinstallations... ;-) James. - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On Tue, 7 Nov 2000, James A. Sutherland wrote: > On Mon, 06 Nov 2000, Gerhard Mack wrote: > > Sure .. lets see you start a laptop in class or buisness meeting and have > > everyone turn to look at you wondering why your laptop let off an ear > > piercing shreak because the hardware defaults to all settings max. > > That only happens if the driver is stupid enough to try guessing "correct" > volume settings. If it leaves well alone until it KNOWS the correct settings, > there is no ear piercing shriek. Nor is there any break in the sound if you > were listening to something from the mixer. > > > And you will _STILL_ have that shriek for 1/2 - 1 second before the > > userspace app loads. > > Wrong. The userspace app is the one triggering the device init, when it gives > the sound driver the correct volume settings. There is no half second delay. > > > And no we couldn't unplug either the mike or the speakers since they come > > embedded in the laptop's case. > > > > I don't see in any of your trolling an answer for this problem. > > It isn't trolling, and there is a perfectly simple answer, as I have already > explained. > And if I don't use modules? Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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: current snapshots of pcmcia
David Hinds wrote: > Incidentally, the i82365 module should work ok (using ISA interrupts) > despite the "No IRQ known" messages. The Yenta driver won't work at > all if PCI interrupts aren't set up. So I guess another question > would be, what card(s) are you using and how are they misbehaving? I'm using tulip based cards and a linksys PC 10/100 + 56K mdm. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
Gentlemen! Start your engines!
FACT! The average male reaches climax in 9-12 minutes! FACT! The average female reaches climax in 20-29 minutes! CLOSE THE GAP! Order the number one selling delay spray worldwide! Click here to learn more! "THIS MESSAGE IS BEING SENT IN COMPLIANCE OF THE EMAIL BILL: SECTION 301.PER SECTION #)!, PARAGRAPH (a) (2) (c) of S. 1618. WE RENTED YOUR EMAILADDRESS FOR A ONE TIME MAILING AS THAT OF AN INDIVIDUAL INTERESTED INRECEIVING INFORMATION ABOUT LEGITIMATE BUSINESS. IF THIS MESSAGE IS INERROR, PLEASE FORGIVE THIS INTRUSION AND SEND A BLANK EMAIL WITH"UNSUBSCRIBE" IN THE SUBJECT LINE TO Remove! AND YOURADDRESS WILL BE IMMEDIATELY AND PERMANENTLY REMOVED FROM OUR LIST" - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Gerhard Mack wrote: > On Mon, 6 Nov 2000, James A. Sutherland wrote: > > > Except this isn't possible with the hardware in question! If it were, there > > would be no problem. In cases where the hardware doesn't support the > > functionality userspace "needs", why put the kludge in the kernel? > > > > If userspace wants to know what settings it set last time, it should store > > those values somewhere. > > > > > [EMAIL PROTECTED] said: > > > > The right thing in this context is not to screw with hardware > > > > settings unless and until it is given settings to set. Do not set > > > > values arbitrarily: set only the values you are explicitly given. > > > > Anything else is simply a bug in your driver. > > > > > > It is unwise to assume that the hardware is in a sane state when the driver > > > has been unloaded and reloaded. I agree that you should set the values that > > > were explicitly given. That's why we should remember them. > > > > No values are being explicitly given. Loading the driver should not cause > > any settings to be changed: changing the settings should do that! > > > > There is no need for the drivers to change any settings. If the settings need > > to be (re)set, let userspace do it. > > > > > > James. > > Sure .. lets see you start a laptop in class or buisness meeting and have > everyone turn to look at you wondering why your laptop let off an ear > piercing shreak because the hardware defaults to all settings max. That only happens if the driver is stupid enough to try guessing "correct" volume settings. If it leaves well alone until it KNOWS the correct settings, there is no ear piercing shriek. Nor is there any break in the sound if you were listening to something from the mixer. > And you will _STILL_ have that shriek for 1/2 - 1 second before the > userspace app loads. Wrong. The userspace app is the one triggering the device init, when it gives the sound driver the correct volume settings. There is no half second delay. > And no we couldn't unplug either the mike or the speakers since they come > embedded in the laptop's case. > > I don't see in any of your trolling an answer for this problem. It isn't trolling, and there is a perfectly simple answer, as I have already explained. James. - 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: current snapshots of pcmcia
Incidentally, the i82365 module should work ok (using ISA interrupts) despite the "No IRQ known" messages. The Yenta driver won't work at all if PCI interrupts aren't set up. So I guess another question would be, what card(s) are you using and how are they misbehaving? -- Dave - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
> changing settings. If I plug in a hotplug soundcard and load the driver, I do > NOT want the driver to decide to set some settings. If I want settings set, > I'll do it myself (or have a script to do it). How about if your stuff is already nicely set up and you remove then replug a device, or remove and swap for an identical replacement part. Most people then want the configuration preserved. And guess what the simple modutils solution using an ELF section solves that too Want to go to default configuration ? rm /var/run/modules/eth0.data or wrap it in a GUI. [BTW windows gets the USB speaker state management right, seems they store all the module persistent data in the registry!] - 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: xterm: no available ptys
Followup to: <[EMAIL PROTECTED]> By author:Igmar Palsenberg <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > I'm missing ptmx. You NEED a writable /dev/pts dir. > Actually, what you need is the devpts filesystem mounted onto /dev/pts. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Evan Jeffrey wrote: > > On Mon, 06 Nov 2000, David Woodhouse wrote: > > > > > > No. You have to reset the hardware fully each time you load the module. > > > Although you _expect_ it to be in the state in which you left it, you can't > > > > > be sure of that. > > > > If a reset is needed, I think it should come explicitly from userspace. > > Take Alan's example of a USB device, say USB audio. If it is disconnected > and reconnected to add a hub, or anything else, the device may shut itself > down, go to an undefined state, or even power cycle (if it draws power from > the USB +5V). Same with hot-swap PCI cards. The driver *MUST* reset the > device on load. If saving mixer levels through this kind of transition is > desired (which it evidentally is), the module load/unload code must save and > restore the settings. I'm not convinced. > This is exactly equivelent to reseting hardware after a warm boot. Interesting. If that were done, my last sound card wouldn't have worked at all under Linux: it had to be initialised under DOS before loading Linux. Had Linux then reset everything, I'd have been soundless! > Who knows > what the Windows driver did to your card in the mean time. Either it initialises it (as it does, in this case), and I want (even NEED) it to STAY initialised (i.e. if your driver does an unnecessary reset, your driver is broken), or it doesn't, and I'll reset the card with an ioctl. > A device driver > can only guarantee that nobody horkes with its hardware while it is loaded-- > In the interim, the driver may have been connected to another computer, > accessed by another driver, or accessed from userspace (say, VMWare doing > a pass through driver). So provide the FACILITY to reset the card, IFF it is needed. There are cases where resetting the card is just stupid: don't force stupidity by design into the kernel. > I personally like the idea of having insmod/rmmod do copy-out/copy-in from > a cache file in userspace. That way, if we need large data sets (a ROM > image for something.) they don't take up kernel space when not in use. > Also, it allows people to have persistant settings across reboot through > the same mechanism--avoiding duplicating information in shutdown/startup > scripts. I prefer the idea of the drivers which need this coming with a suitable interface (/dev or /proc item) and a script to do this when needed. James. - 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] VCD support for isofs
Attached patches add VCD support in isofs.
Against 2.2.16 and 2.4.0-test10.
diff -ur isofs.orig/file.c isofs/file.c
--- isofs.orig/file.c Mon Mar 8 07:25:23 1999
+++ isofs/file.cTue Nov 7 08:07:57 2000
@@ -54,3 +54,24 @@
NULL, /* truncate */
NULL/* permission */
};
+
+extern int readpage_form2(struct file *, struct page *);
+struct inode_operations isofs_file_inode_operations_form2 = {
+ _file_operations, /* default file operations */
+ NULL, /* create */
+ NULL, /* lookup */
+ NULL, /* link */
+ NULL, /* unlink */
+ NULL, /* symlink */
+ NULL, /* mkdir */
+ NULL, /* rmdir */
+ NULL, /* mknod */
+ NULL, /* rename */
+ NULL, /* readlink */
+ NULL, /* follow_link */
+ readpage_form2, /* readpage */
+ NULL, /* writepage */
+ isofs_bmap, /* bmap */
+ NULL, /* truncate */
+ NULL/* permission */
+};
diff -ur isofs.orig/inode.c isofs/inode.c
--- isofs.orig/inode.c Wed Aug 23 03:24:10 2000
+++ isofs/inode.c Tue Nov 7 08:08:02 2000
@@ -1085,6 +1085,231 @@
goto out;
}
+int cd_ioctl(struct super_block *s, int request, unsigned long arg)
+{
+ extern struct file_operations * get_blkfops(unsigned int);
+ kdev_t dev = s->s_dev;
+ struct file_operations *fops = get_blkfops(MAJOR(dev));
+ int ret = -1;
+ if(fops && fops->ioctl)
+ {
+ struct inode inode_fake;
+ mm_segment_t old_fs=get_fs();
+ set_fs(KERNEL_DS);
+ inode_fake.i_rdev=dev;
+ ret = fops->ioctl(_fake,NULL,request,arg);
+ set_fs(old_fs);
+ }
+ return ret;
+}
+
+static char *last_buf;
+unsigned char* cd_read_raw_sector(struct inode *inode, int sector_nr)
+{
+ static struct semaphore last_buf_sem = MUTEX;
+ static struct inode* last_inode;
+ static int last_sector_nr = -1;
+ unsigned char *buf;
+ struct cdrom_msf *msf;
+ int lba;
+
+ buf = kmalloc(CD_FRAMESIZE_RAW,GFP_KERNEL);
+ if(buf == NULL) return NULL;
+
+ down(_buf_sem);
+
+ if(sector_nr == last_sector_nr && inode == last_inode)
+ // how to do the right check/invalidate?
+ {
+ memcpy(buf,last_buf,CD_FRAMESIZE_RAW);
+ goto out;
+ }
+
+ lba = isofs_bmap(inode,0) + 150 + sector_nr;
+ msf = (struct cdrom_msf *)buf;
+ msf->cdmsf_min0 = lba/75/60;
+ msf->cdmsf_sec0 = (lba/75)%60;
+ msf->cdmsf_frame0 = lba%75;
+ if(cd_ioctl(inode->i_sb,CDROMREADRAW,(unsigned long)msf) < 0)
+ {
+ kfree(buf);
+ buf = NULL;
+ }
+ else
+ {
+ last_inode = inode;
+ last_sector_nr = sector_nr;
+ memcpy(last_buf,buf,CD_FRAMESIZE_RAW);
+ }
+out:
+ up(_buf_sem);
+ return buf;
+}
+
+#define FORM2_DATA_SIZE 2324
+static int kisofsd_pid;
+static int kisofsd_running = 0;
+static spinlock_t kisofsd_req_lock = SPIN_LOCK_UNLOCKED;
+static LIST_HEAD(kisofsd_req_list);/* List of requests needing servicing */
+static struct wait_queue *kisofsd_wait;
+
+struct kisofsd_req {
+ struct list_head req_list;
+ struct inode *inode;
+ struct page *page;
+};
+
+static int kisofsd_add_request(struct inode* inode, struct page *page)
+{
+ struct kisofsd_req *req = kmalloc(sizeof(struct kisofsd_req),
+ GFP_KERNEL);
+ if(req == NULL) return -ENOMEM;
+
+ set_bit(PG_locked, >flags);
+ clear_bit(PG_uptodate, >flags);
+ clear_bit(PG_error, >flags);
+
+ INIT_LIST_HEAD(>req_list);
+ req->inode = inode;
+ req->page = page;
+
+ spin_lock(_req_lock);
+ list_add(>req_list,kisofsd_req_list.prev);
+ wake_up(_wait);
+ spin_unlock(_req_lock);
+
+ return 0;
+}
+
+static void readpage_form2_real(struct inode* inode, struct page* page)
+{
+ char *buf = (char *)page_address(page);
+ int start_sector, start_byte;
+ int stop_sector, stop_byte;
+ int sector;
+ int offset = page->offset;
+
+ // the code is adapted from cdXA.c of cdfs-0.41
+
+ start_sector = offset / FORM2_DATA_SIZE;
+ start_byte = offset % FORM2_DATA_SIZE;
+ stop_sector = (offset + PAGE_SIZE) / FORM2_DATA_SIZE;
+ stop_byte = (offset + PAGE_SIZE) % FORM2_DATA_SIZE;
+
+ if(stop_byte == 0)
+ {
+
Re: ide-probe.c:400: `rtc_lock' undeclared and /lib/modules/..../build
On Tue, 7 Nov 2000, Tomasz Motylewski wrote: > 2.2.18pre19: > ide-probe.c:400: `rtc_lock' undeclared (first use this function) > ide-probe.c:400: (Each undeclared identifier is reported only once > ide-probe.c:400: for each function it appears in.) See the attached patch. Just declares it as an extern spinlock_t, as per a boatload of other places in the kernel. Mark -- +-+ Mark Cooke The views expressed above are mine and are not Systems Programmer necessarily representative of university policy University Of BirminghamURL: http://www.sr.bham.ac.uk/~mpc/ +-+ --- linux/drivers/block/ide-probe.c.origSat Nov 4 06:32:43 2000 +++ linux/drivers/block/ide-probe.c Sat Nov 4 06:32:52 2000 @@ -43,6 +43,8 @@ #include #include +extern spinlock_t rtc_lock; + #include "ide.h" static inline void do_identify (ide_drive_t *drive, byte cmd)
PCI oddness with Ali 1541 chipset
Hi, I'm running 2.4.0-test10 on my desktop machine. The system works perfectly well, but I get some strange PCI messages at boot time. Here is part it: PCI: PCI BIOS revision 2.10 entry at 0xf0560, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router ALI [10b9/1533] at 00:07.0 I don't know what kind of bridge resources these are. A little bit furthur, the IDE controller gets detected: ALI15X3: IDE controller on PCI bus 00 dev 78 PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using pci=biosirq. ALI15X3: chipset revision 193 I tried "pci=biosirq", but that didn't make any difference. I don't know if this is related with the unknown bridge resources earlier. After booting, the IDE controller uses IRQ 14 and 15, but lscpi says that the IDE controller has pin A routed to IRQ 0. What's going wrong over here, or is this just normal behaviour? Short description of the system: K6-II@333MHz, 160MB memory, Asus P5A motherboard (Ali 1541 chipset), Debian GNU/Linux 2.2. I attached the config file, the boot messages, and the output of "lspci -vvvx". Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_M686FXSR is not set CONFIG_MK6=y # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_RTC_IS_GMT=y # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set CONFIG_PARIDE=m CONFIG_PARIDE_PARPORT=m CONFIG_PARIDE_PD=m CONFIG_PARIDE_PCD=m CONFIG_PARIDE_PF=m CONFIG_PARIDE_PT=m CONFIG_PARIDE_PG=m CONFIG_PARIDE_ATEN=m CONFIG_PARIDE_BPCK=m CONFIG_PARIDE_COMM=m CONFIG_PARIDE_DSTR=m CONFIG_PARIDE_FIT2=m CONFIG_PARIDE_FIT3=m CONFIG_PARIDE_EPAT=m CONFIG_PARIDE_EPIA=m CONFIG_PARIDE_FRIQ=m CONFIG_PARIDE_FRPW=m CONFIG_PARIDE_KBIC=m CONFIG_PARIDE_KTTI=m CONFIG_PARIDE_ON20=m CONFIG_PARIDE_ON26=m # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set #
Re: current snapshots of pcmcia
David Hinds wrote: > > On Mon, Nov 06, 2000 at 04:45:52PM -0700, Jeff V. Merkey wrote: > > > > On a related topic, I've pulled down your stuff at sourceforge and we > > are using it for our 2.4 build. Is this the baest place or do you have > > somewhere more recent and is this the list to report bugs? We have seen > > some problems with IBM thinkpads with DSP devices having some issues > > (like the volume control doesn't work right on 2.4). Most are just > > annoyances and what I would classify as level IV bugs (very > > non-critical). > > The sourceforge site is the most up to date place for PCMCIA. That is > the best place to report bugs that are specific to that code. For > bugs that are specific to things in the 2.4 tree and/or have to do > with how PCMCIA interacts with other subsystems (i.e., the problem > that started this thread, where I think the problem is in the PCI > subsystem), then linux-kernel is probably a better place. Thanks :-) Jeff > > -- Dave - 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: current snapshots of pcmcia
David Hinds wrote: > On Mon, Nov 06, 2000 at 03:19:41PM -0800, David Ford wrote: > > > > Undoubtedly :( But it used to work when I used your i82365 module instead of > > the kernel's yenta module. The i82365 module now gives the same failure > > output as the yenta module. > > How long ago was this? I would need to know what kernel versions and > what PCMCIA driver versions were involved. It has been months since I > changed any of the PCI bridge setup code in the PCMCIA modules. test10-pre6, your code from mid october worked (with gross hack I made for the L1 cache define). test10 release, nothing works now. > > I modprobed the following to get things up and running, (all your pkg) > > pcmcia_core, i82365, and ds. Then ran cardmgr. All was well. Now when I > > load i82365, it yields the pci irq failure and the irq type is changed. > > > > 2nd sentc: What changed in the last two-three weeks? I notice that the > > current pcmcia (yours) code loads a new module called pci_fixup. > > There is no module called pci_fixup. There is an object file called > pci_fixup that is linked into pcmcia_core. This has been there since > PCMCIA release 3.1.11. Hmm, lsmod showed it. I'll duplicate and report. > > Intel PCIC probe: <4>PCI: No IRQ known for interrupt pin A of device 00:03.0. > > PCI: No IRQ known for interrupt pin B of device 00:03.1. > > This is a PCI subsystem issue; the PCMCIA code asks the PCI subsystem > to activate the bridge device and isn't working. > > > Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 > > host opts [0]: [isa irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > > 168/176] [bus 2/5] > > host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > > 168/176] [bus 6/9] > > ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms > > > > Previous output was: > > Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 > > host opts [0]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > > 168/176] [bus 2/5] > > host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > > 168/176] [bus 6/9] > > ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms > > > > Notice the change from serial irq to isa irq. > > This is odd. I don't have an explanation for this, especially without > knowing what PCMCIA driver releases were involved. Unless you specify > otherwise, the i82365 driver just reports the bridge settings that it > finds; it won't change the interrupt delivery mode unless told to do > so. So something else has caused your two sockets to be set up in > different ways; there isn't any way to tell the i82365 module to do > that. Ok. I'll go back to test10-pre6 and get a working pcmcia system and we'll go from there. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
ide-probe.c:400: `rtc_lock' undeclared and /lib/modules/..../build
2.2.18pre19: /usr/bin/gcc272 -D__KERNEL__ -I/home/22/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o fork.o fork.c ide-probe.c: In function `probe_cmos_for_drives': ide-probe.c:400: `rtc_lock' undeclared (first use this function) ide-probe.c:400: (Each undeclared identifier is reported only once ide-probe.c:400: for each function it appears in.) And , whose idea was that "make modules_install" should create /lib/modules//build symlink to the kernel sources? It really breakes depmod -a (modutils 2.3.11)(*) Best regards, -- Tomasz Motylewski (*) I could find a workaround, but if it hits me, it will hit lots of other people not reading linux-kernel regularly. In my opinion upgrading stable kernels should work without any modifications to the existing system. - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Dan Hollis wrote: > On Mon, 6 Nov 2000, James A. Sutherland wrote: > > So autoload the module with a "dont_screw_with_mixer" option. When the kernel > > first boots, initialise the mixer to suitable settings (load the module with > > "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change > > the mixer settings on load. > > You are asking for real trouble on hotplug hardware if you insist on this. How so? There is no need for the driver to decide off its own bat to go changing settings. If I plug in a hotplug soundcard and load the driver, I do NOT want the driver to decide to set some settings. If I want settings set, I'll do it myself (or have a script to do it). James. - 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: ping -f kills ne2k (was:[patch] NE2000)
Paul Gortmaker wrote: > > > > > Well, I have tried it with 2.4.0-test10, both SMP and non-SMP, and the > > result is a little confusing. > > > > Under SMP a ping -s 5 -f other_host takes down the network access > > with no messages (ne2k-pci), and no possibility of being restored > > without a reboot. > > > > Under UP the same command works ok, but after a while the dots stop for > > 30sec, then ping prints an 'E' and the dots continue. strace revealed > > this: > > Another suggestion - if you have your heart set on using ping > as your network stress tool, you may want to try using multiple > instances of MTU sized pings versus a single "ping -s 5". > In this way you aren't involving any IP frag code and its associated > bean counting - giving us one less factor to consider. > > Oh, and since you get a silent failure, maybe you would be interested > in testing this patch I was (originally) saving for 2.5.x. -- It adds > watchdog transmit timeout functionality to 8390.c (which is used by > the ne2k-pci driver). Last time I updated it was a couple of months > ago, but nothing has changed since then. > > Paul. > Tested with ping -f -s 1400 (1400 in order not to reach 1500) It took about half an hour and more than one million packets, but I finally took the net down, with 12 concurrent pings. To eliminate factors I have deleted all the NAT rules wich gave messages about dropped packets, and unloaded all the iptables modules. I have to make the test without the test check in sock_wait_for_wmem: if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0) BUG(); Because as I said in a previous msg it gave me BUG()s very early in the tests, and I still had network access. If someone has a better sugestion as a nic stress tool I can try it, but now I only have two ways of reaching this limits, ping -f of big packets, and sometimes (only 4 or 5) during a copy of a large file over NFS, but it's not a easy way to cause this. -- Jorge Nerin <[EMAIL PROTECTED]> - 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/
Another Oops with latest kernel
Any hints on what caused this one? Nov 6 18:28:53 phlegmish kernel: Unable to handle kernel paging request at virt ual address 9cca Nov 6 18:28:53 phlegmish kernel: c012cdd6 Nov 6 18:28:53 phlegmish kernel: *pde = Nov 6 18:28:53 phlegmish kernel: Oops: Nov 6 18:28:53 phlegmish kernel: CPU:0 Nov 6 18:28:53 phlegmish kernel: EIP:0010:[] Nov 6 18:28:53 phlegmish kernel: EFLAGS: 00010202 Nov 6 18:28:53 phlegmish kernel: eax: 9cb6 ebx: 9cb6 ecx: 9cb6 edx: 0400 Nov 6 18:28:53 phlegmish kernel: esi: edi: c2d7ba80 ebp: 0001 esp: c1743f80 Nov 6 18:28:53 phlegmish kernel: ds: 0018 es: 0018 ss: 0018 Nov 6 18:28:53 phlegmish kernel: Process netscape-commun (pid: 889, stackpage=c 1743000) Nov 6 18:28:53 phlegmish kernel: Stack: 069e7fff c0118c5a 9cb6 c2d 7ba80 c4e4dc80 c1742000 Nov 6 18:28:53 phlegmish kernel:bfffe308 c011925a c2d7ba80 c1742000 403 148ec c01193a2 Nov 6 18:28:53 phlegmish kernel:c010a407 40315740 403 148ec bfffe308 0001 Nov 6 18:28:53 phlegmish kernel: Call Trace: [] [] [] [] Nov 6 18:28:53 phlegmish kernel: Code: 8b 43 14 85 c0 75 13 68 c2 4d 22 c0 e8 3 5 9f fe ff 31 c0 83 >>EIP; c012cdd6<= Trace; c0118c5a Trace; c011925a Trace; c01193a2 Trace; c010a407 <__rwsem_wake+1073/2264> Code; c012cdd6 <_EIP>: Code; c012cdd6<= 0: 8b 43 14 mov0x14(%ebx),%eax <= Code; c012cdd9 3: 85 c0 test %eax,%eax Code; c012cddb 5: 75 13 jne1a <_EIP+0x1a> c012cdf0 Code; c012cddd 7: 68 c2 4d 22 c0push $0xc0224dc2 Code; c012cde2 c: e8 35 9f fe ffcall fffe9f46 <_EIP+0xfffe9f46> c0116d1c Code; c012cde7 11: 31 c0 xor%eax,%eax Code; c012cde9 13: 83 00 00 addl $0x0,(%eax) - 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: Kernel 2.4.0test10 crash (RAID+SMP)
[s/rutgers.edu/kernel.org/] On Tue, 7 Nov 2000 09:19:12 +1100 (EST), Neil Brown <[EMAIL PROTECTED]> wrote: > On Monday November 6, [EMAIL PROTECTED] wrote: >> If multiple interrupts are hitting a single code path (like IDE irqs 14 >> -and- 15), you definitely have to think about that. The reentrancy >> guarantee only exists when a single IRQ is assigned to a single >> handler... >> > The b_end_io routine that raid1 attaches to io request buffer_heads > that are used for resyncing had a side effect of re-enabling > interrupts. As it is called from an interrupt context, this is > clearly a bug. It allowed another interrupt to be serviced before a > previous interrupt had been completed, which is a problem waiting to > happen. > In this case, it became a real problem because the first interrupt had > grabbed a spinlock (I didn't bother to discover which one) and the > second interrupt tried to grab the same spinlock. This produced the > deadlock which the NMI-Oopser detected and reported. You are absolutely right, it is a bug, but Jeff is also right in pointing that the bug won't hit you unless you have two different hardware IRQ's being serviced by the same code. Otherwise, just enabling the interrupts won't re-enable _your_ IRQ, so another interrupt triggered by your IRQ won't be serviced until you exit the handler. It could also be that the code is running with SA_INTERRUPT and is relying on the fact that _all_ interrupts are disabled. That's less likely, especially since AFAIK the interrupts are disabled only on the local processor, so it's not much of a guarantee on SMP. In any case, a bug is a bug and should get fixed, no question about it. :) Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - 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/
swapout vs. filemap_sync_pte...?
The address_space::writepage callback is called from try_to_swap_out() path, and also from the filemap_sync_pte() path. There appears to be no way to tell the difference between the two callers. This is not good because the semantics are very different: "sync this page" versus "page is going away". Should address_space::writepage get passed an additional arg, indicating the caller? Should filemap_sync_pte call address_space::sync_page instead of ::writepage? Either way, this allows the writepage function to know whether it really needs to store the page, because it is going away, or not. I will admit I might be missing something obvious... I'm pretty new to this part of the code. Jeff -- Jeff Garzik | "When I do this, my computer freezes." Building 1024 | -user MandrakeSoft| "Don't do that." | -level 1 - 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: USB init order dependencies.
Randy.Dunlap wrote: > > While Jeff and I basically agree on the short-term > > solution (if one is still needed, altho I'm not aware of > > any init order problems in USB in 2.4.0-test10), my > > recollection of Linus's preference (without > > looking it up) is to remove the calls from init/main.c > > and to use __initcalls. > Russell King wrote: > The problem for ARM is that Linux does a lot of the initialisation for > some machines, but not for ARM ? > which basically means the hardware isn't setup > for access > to the USB device if the USB initialisation was placed in init/main.c > (this initialisation is done by the very first initcall on > ARM). However, > that said, we may be able to get away with only adding > hw_sa1100_init() > before the USB call, but this is only one family of the ARM > machine types. I'm not following your argument very well. I've read it and reread it several times. Does adding a call to usb_init() in init/main.c cause USB to be init 2 times? I'm not complaining or arguing against you, just trying to understand better. > BTW, I've long lost track of what the original problem that > sparked off > this thread was, does someone have a quick reference to it? (please > reply in private mail). Thanks. There were several threads but I can't find the "original" one right now. IIRC, it was simply that CONFIG_USB=y and CONFIG_USB_*=m (any USB except usbcore built as modules) caused depmod problems, but that could be incorrect also. ~Randy - 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: current snapshots of pcmcia
On Mon, Nov 06, 2000 at 04:45:52PM -0700, Jeff V. Merkey wrote: > > On a related topic, I've pulled down your stuff at sourceforge and we > are using it for our 2.4 build. Is this the baest place or do you have > somewhere more recent and is this the list to report bugs? We have seen > some problems with IBM thinkpads with DSP devices having some issues > (like the volume control doesn't work right on 2.4). Most are just > annoyances and what I would classify as level IV bugs (very > non-critical). The sourceforge site is the most up to date place for PCMCIA. That is the best place to report bugs that are specific to that code. For bugs that are specific to things in the 2.4 tree and/or have to do with how PCMCIA interacts with other subsystems (i.e., the problem that started this thread, where I think the problem is in the PCI subsystem), then linux-kernel is probably a better place. -- Dave - 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: current snapshots of pcmcia
David [Hinds], On a related topic, I've pulled down your stuff at sourceforge and we are using it for our 2.4 build. Is this the baest place or do you have somewhere more recent and is this the list to report bugs? We have seen some problems with IBM thinkpads with DSP devices having some issues (like the volume control doesn't work right on 2.4). Most are just annoyances and what I would classify as level IV bugs (very non-critical). Thanks, Jeff David Hinds wrote: > > On Mon, Nov 06, 2000 at 03:19:41PM -0800, David Ford wrote: > > > > Undoubtedly :( But it used to work when I used your i82365 module instead of > > the kernel's yenta module. The i82365 module now gives the same failure > > output as the yenta module. > > How long ago was this? I would need to know what kernel versions and > what PCMCIA driver versions were involved. It has been months since I > changed any of the PCI bridge setup code in the PCMCIA modules. > > > I modprobed the following to get things up and running, (all your pkg) > > pcmcia_core, i82365, and ds. Then ran cardmgr. All was well. Now when I > > load i82365, it yields the pci irq failure and the irq type is changed. > > > > 2nd sentc: What changed in the last two-three weeks? I notice that the > > current pcmcia (yours) code loads a new module called pci_fixup. > > There is no module called pci_fixup. There is an object file called > pci_fixup that is linked into pcmcia_core. This has been there since > PCMCIA release 3.1.11. > > > Intel PCIC probe: <4>PCI: No IRQ known for interrupt pin A of device 00:03.0. > > PCI: No IRQ known for interrupt pin B of device 00:03.1. > > This is a PCI subsystem issue; the PCMCIA code asks the PCI subsystem > to activate the bridge device and isn't working. > > > Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 > > host opts [0]: [isa irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > > 168/176] [bus 2/5] > > host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > > 168/176] [bus 6/9] > > ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms > > > > Previous output was: > > Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 > > host opts [0]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > > 168/176] [bus 2/5] > > host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > > 168/176] [bus 6/9] > > ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms > > > > Notice the change from serial irq to isa irq. > > This is odd. I don't have an explanation for this, especially without > knowing what PCMCIA driver releases were involved. Unless you specify > otherwise, the i82365 driver just reports the bridge settings that it > finds; it won't change the interrupt delivery mode unless told to do > so. So something else has caused your two sockets to be set up in > different ways; there isn't any way to tell the i82365 module to do > that. > > -- Dave > - > 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: xterm: no available ptys
On Mon, 6 Nov 2000, Paul Powell wrote: > Hello, > > I have created a trimmed down /dev directory to be > used with my custom bootable Linux CD. I've run into > a problem where I can't start an xterm. I get the > error... > > xterm: no available ptys > > I'm not sure which device I'm missing in /dev. I'm no > expert on how the tty's and stuff work so feel free to > fill me in. Everything else seems to work fine on the > CD. > > Here is what my /dev directory looks like now: > > /dev: > console > cua0 > cua1 > cua2 > cua3 > fb > fb0 > fb1 > fb2 > fb3 > fb4 > fb5 > fb6 > fb7 > fd0 > fd1 > hda > hdb > hdc > hdd > kmem > listing > mem > mouse > null > psaux > pts > |...0 I'm missing ptmx. You NEED a writable /dev/pts dir. Igmar - 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: Play Kernel Hangman!
From: "Leen Besselink" <[EMAIL PROTECTED]>
> On Mon, 6 Nov 2000, Jeff Dike wrote:
>
> > After a stranger than usual late-night #kernelnewbies session on Thursday, I
> > was inspired to come up with Kernel Hangman. This is the traditional game
of
> > hangman, except that the words you have to guess are kernel symbols.
> >
> > So, test your knowledge of kernel trivia and play it at
> > http://user-mode-linux.sourceforge.net/cgi-bin/hangman
> >
> > Jeff
>
> Actually, OpenBSD already has this (in the kernel !) After a kernel crash
> ones, I got in the kerneldebugger. I didn't really know how to use it, but
> I could play hangman. I just downloaded the source
Now that might be the best argument for a kernel debugger we've seen yet.
{O,o}Joanne Dow, somewhat crazed.
-
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: current snapshots of pcmcia
On Mon, Nov 06, 2000 at 03:19:41PM -0800, David Ford wrote: > > Undoubtedly :( But it used to work when I used your i82365 module instead of > the kernel's yenta module. The i82365 module now gives the same failure > output as the yenta module. How long ago was this? I would need to know what kernel versions and what PCMCIA driver versions were involved. It has been months since I changed any of the PCI bridge setup code in the PCMCIA modules. > I modprobed the following to get things up and running, (all your pkg) > pcmcia_core, i82365, and ds. Then ran cardmgr. All was well. Now when I > load i82365, it yields the pci irq failure and the irq type is changed. > > 2nd sentc: What changed in the last two-three weeks? I notice that the > current pcmcia (yours) code loads a new module called pci_fixup. There is no module called pci_fixup. There is an object file called pci_fixup that is linked into pcmcia_core. This has been there since PCMCIA release 3.1.11. > Intel PCIC probe: <4>PCI: No IRQ known for interrupt pin A of device 00:03.0. > PCI: No IRQ known for interrupt pin B of device 00:03.1. This is a PCI subsystem issue; the PCMCIA code asks the PCI subsystem to activate the bridge device and isn't working. > Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 > host opts [0]: [isa irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > 168/176] [bus 2/5] > host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > 168/176] [bus 6/9] > ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms > > Previous output was: > Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 > host opts [0]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > 168/176] [bus 2/5] > host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat > 168/176] [bus 6/9] > ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms > > Notice the change from serial irq to isa irq. This is odd. I don't have an explanation for this, especially without knowing what PCMCIA driver releases were involved. Unless you specify otherwise, the i82365 driver just reports the bridge settings that it finds; it won't change the interrupt delivery mode unless told to do so. So something else has caused your two sockets to be set up in different ways; there isn't any way to tell the i82365 module to do that. -- Dave - 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/
2.2.18pre19 + raid-2.2.18-AX?
I can't get raid-2.2.18-A2 to apply cleanly on 2.2.18pre19. Does anyone know of a newer raid-2.2.18preX patch? (pre18 or pre19 would be great). Here's the output I get... [root@server linux]# patch -p1 < raid-2.2.18-A2 patching file init/main.c Hunk #4 succeeded at 1631 (offset 4 lines). patching file include/linux/raid/hsm.h patching file include/linux/raid/hsm_p.h patching file include/linux/raid/linear.h patching file include/linux/raid/md.h patching file include/linux/raid/md_compatible.h patching file include/linux/raid/md_k.h patching file include/linux/raid/md_p.h patching file include/linux/raid/md_u.h patching file include/linux/raid/raid0.h patching file include/linux/raid/raid1.h patching file include/linux/raid/raid5.h patching file include/linux/raid/translucent.h patching file include/linux/raid/xor.h patching file include/linux/blkdev.h Hunk #1 succeeded at 91 (offset -2 lines). patching file include/linux/fs.h Hunk #2 succeeded at 781 (offset 9 lines). Hunk #4 succeeded at 828 (offset 9 lines). Hunk #6 succeeded at 938 (offset 9 lines). patching file include/linux/md.h patching file include/linux/raid0.h patching file include/linux/raid1.h patching file include/linux/raid5.h patching file include/linux/sysctl.h Hunk #1 succeeded at 433 (offset 2 lines). patching file include/asm-i386/md.h patching file include/asm-alpha/md.h patching file include/asm-m68k/md.h patching file include/asm-sparc/md.h patching file include/asm-ppc/md.h patching file include/asm-sparc64/md.h patching file drivers/block/Config.in patching file drivers/block/Makefile patching file drivers/block/genhd.c patching file drivers/block/hsm.c patching file drivers/block/linear.c patching file drivers/block/linear.h patching file drivers/block/ll_rw_blk.c Hunk #3 succeeded at 589 (offset -68 lines). Hunk #4 succeeded at 908 (offset -2 lines). Hunk #5 succeeded at 862 (offset -68 lines). patching file drivers/block/md.c patching file drivers/block/raid0.c patching file drivers/block/raid1.c Hunk #7 FAILED at 146. Hunk #10 FAILED at 287. 2 out of 15 hunks FAILED -- saving rejects to file drivers/block/raid1.c.rej patching file drivers/block/raid5.c patching file drivers/block/translucent.c patching file drivers/block/xor.c patching file arch/i386/defconfig patching file arch/sparc/config.in patching file arch/sparc/defconfig Hunk #1 succeeded at 88 with fuzz 2. patching file arch/sparc64/config.in patching file arch/sparc64/defconfig Hunk #1 succeeded at 107 with fuzz 2 (offset 1 line). patching file Documentation/Configure.help Hunk #1 succeeded at 1017 (offset 44 lines). patching file Makefile Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej Best regards, Dan Browning Network/DB Admin Cyclone Computer Systems - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, James A. Sutherland wrote: > Except this isn't possible with the hardware in question! If it were, there > would be no problem. In cases where the hardware doesn't support the > functionality userspace "needs", why put the kludge in the kernel? > > If userspace wants to know what settings it set last time, it should store > those values somewhere. > > > [EMAIL PROTECTED] said: > > > The right thing in this context is not to screw with hardware > > > settings unless and until it is given settings to set. Do not set > > > values arbitrarily: set only the values you are explicitly given. > > > Anything else is simply a bug in your driver. > > > > It is unwise to assume that the hardware is in a sane state when the driver > > has been unloaded and reloaded. I agree that you should set the values that > > were explicitly given. That's why we should remember them. > > No values are being explicitly given. Loading the driver should not cause > any settings to be changed: changing the settings should do that! > > There is no need for the drivers to change any settings. If the settings need > to be (re)set, let userspace do it. > > > James. Sure .. lets see you start a laptop in class or buisness meeting and have everyone turn to look at you wondering why your laptop let off an ear piercing shreak because the hardware defaults to all settings max. And you will _STILL_ have that shriek for 1/2 - 1 second before the userspace app loads. And no we couldn't unplug either the mike or the speakers since they come embedded in the laptop's case. I don't see in any of your trolling an answer for this problem. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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: Announce: NFS-client & NIS-client UID/GID remapper
The UID/GID mapper should be sepatate from the regex rewriting rules. Both should be separate from NFS, because they have little to do with NFS. These are useful generic VFS features. It would be perfectly reasonable to use these features on a Zip disk with UFS (from MacOS X maybe). Another example: given two Linux boxes with existing user accounts, how does one merge them together into one box? The UID/GID remapper could be helpful for this; just put both disks in the same box and remap as needed. The pathname remapper might best be done as a namespace operation similar to mounting. Given a read-only /usr on CD-ROM or NFS with an exploitable /usr/bin/suidperl, I'd like to "mount" a new executable on top of that from /bin/good-suidperl to fix the hole. Even more interesting is the case where /usr/bin/setuidperl does not exist at all, so there isn't anything to use for a mount point, but I have scripts that need to use it. - 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: Loadavg calculation
hi, As you've suggested, you'd be better off not using the load average but rather some other measure (or combination of measures) to figure out when you have enough spare cycles or bandwidth. The "pmie" tool might be useful to you - here's a contrived example I just knocked up (instead of a "print" you'd want to run your program via the "shell" keyword) with an occassional artificial load in the background. kernel.all.cpu.idle is aggregate idle time across all cpus. pmie converts it to a rate (#idle milliseconds / 8 seconds) so it will always have a value between 0 (no idle time) and 1 (lots of idle time). $ pmie -t 8sec -v ( kernel.all.cpu.idle > 0.5 ) -> print "start a new job"; ^D expr_1: ? Tue Nov 7 09:33:36 2000: start a new job expr_1: true Tue Nov 7 09:33:44 2000: start a new job expr_1: true Tue Nov 7 09:33:52 2000: start a new job expr_1: true expr_1: false expr_1: false expr_1: false Tue Nov 7 09:34:24 2000: start a new job expr_1: true Tue Nov 7 09:34:32 2000: start a new job expr_1: true expr_1: false expr_1: false Tue Nov 7 09:34:56 2000: start a new job expr_1: true pmie is one of the gpl'd pcp tools which you can get from the sgi oss site... hope its useful to you. mailto the pcp list if you need any more info. cheers. [EMAIL PROTECTED] wrote: > > I'm working a project a work that is using Linux to run some very > math-intensive calculations. One of the things we do is use the 1-minute > loadavg to determine how busy the machine is and can we fire off another > program to do more calculations.However, there's a problem with that. > > Because it's a 1 minute load average, there's quite a bit of lag time from > when 1 program finishes until the loadavg goes down below a threshold for > our control mechanism to fire off another program. > > Let me give an example (all on a 1-cpu PC) > > HH:MM:SS > 00:00:00fire off 4 programs > 00:01:00loadavg goes up to 4 > 00:01:303 of the 4 programs finish loadavg still at 4 > 00:02:20load avg goes down to 1, below our threshold > 00:02:21we fire off 3 more programs. > > We'd like to reduce that almost 50 second lag time. Is it possible, in > user-space, to duplicate the loadavg calculation period, say to a 15 > second load average, using the information in /proc? > > The other option we looked at, besides using loadavg, was using idle pct%, > but if I read the source for top right, involves reading the entire > process table to calculate clock ticks used and then figuring out how many > weren't used. > > Ideas, opinions welcome. Yes, I read the list, so either respond direct > to me, or to the list. > > [EMAIL PROTECTED] (Robert A. Yetman) > > - > 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/ -- Nathan -- Nathan - 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: current snapshots of pcmcia
(cc: lkml) David Hinds wrote: > On Mon, Nov 06, 2000 at 01:10:24AM -0800, David Ford wrote: > > :( > > > > Ok. Here's the story. 2.3/2.4 kernel pcmcia gave up the ghost on my > > socket controller several versions back. It is unable to assign an irq. > > PCMCIA in 2.4 (whether you build the modules in the kernel, or build > the modules in the standalone package) is completely dependent on the > kernel PCI layer to assign PCI interrupts (I assume that's what you > mean by "an irq"? without system log messages I can't be sure). > There has been no change in this in recent months; there may have been > changes in the PCI layer that broke your setup. > > > What changed in the last ~two weeks? I notice that the current snapshot > > also loads pci fixup. > > I don't understand the second sentence. Please explain. Undoubtedly :( But it used to work when I used your i82365 module instead of the kernel's yenta module. The i82365 module now gives the same failure output as the yenta module. I modprobed the following to get things up and running, (all your pkg) pcmcia_core, i82365, and ds. Then ran cardmgr. All was well. Now when I load i82365, it yields the pci irq failure and the irq type is changed. 2nd sentc: What changed in the last two-three weeks? I notice that the current pcmcia (yours) code loads a new module called pci_fixup. The dmesg output from loading i82365 is: Intel PCIC probe: <4>PCI: No IRQ known for interrupt pin A of device 00:03.0. PCI: No IRQ known for interrupt pin B of device 00:03.1. Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 host opts [0]: [isa irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat 168/176] [bus 2/5] host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat 168/176] [bus 6/9] ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms Previous output was: Ricoh RL5C478 rev 03 PCI-to-CardBus at slot 00:03, mem 0x1000 host opts [0]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat 168/176] [bus 2/5] host opts [1]: [serial irq] [io 3/6/1] [mem 3/6/1] [no pci irq] [lat 168/176] [bus 6/9] ISA irqs (default) = 3,4,7,11 polling interval = 1000 ms Notice the change from serial irq to isa irq. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
Re: non-gcc linux?
On Sun, Nov 05, 2000 at 06:01:29PM -0700, Tim Riker wrote: > In short the impact of adding code to gcc that is not copyright FSF is > minimal. Only the FSF copyrighted code would be defensible by the FSF. Any > other code GPL violations would be the responsibility of the copyright > owners to defend. Just as a minor point: pro64 _does_ use GCC code. It's effectively the GCC frontend stuck together with the SGI backend, with a translation layer in the middle to translate between the intermediate code formats that the two compilers use. There are some fairly entertaining "this is a gruesome hack" comments in the source code. -- Adam Sampson [EMAIL PROTECTED] - 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: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, Alan Cox wrote: > Its called modules.conf. It has all these nice preload directives in it cool.. doesn't seem to be documented though in modutils 2.3.17. what exactly does it do? regards, -- Paul Jakma [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: I finally went to the eye doctor. I got contacts. I only need them to read, so I got flip-ups. -- Steven Wright - 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/
cramfs 2.2.x back-port
Hello everybody, I am fairly new to the kernel programming, in fact it's my first attemt at it. As an exercise I was trying to back-port cramfs code to the 2.2.x kernel, and I seem to have succeeded! The only thing still not working are symlinks. There are 2 routines in the code, cramfs_readlink() and cramfs_follow_link() which both use new (2.3.x) function get_cache_page(), which I don't know how to substitute in 2.2.x. If you guys know this better than I do, I'd be very grateful if you helped me out. There may be not much reason in back-porting, but I like 2.2.x and the only feature from 2.4.x I needed was cramfs. My cramfs 2.2.x patch follows. It is based on 2.3.40 cramfs code. Please if you answer to this post, CC: me directly, I am not subscribed. cramfs-2.2.x-patch.diff.gz
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
This sounds to me like the most flexible way to do it. If the module accepts parameters then those who want the sound card initialized at every load can put the desired settings in modules.conf. The rest of us can just initialize it once at boot time and the rest of the time the settings will be left untouched. James A.Sutherland <[EMAIL PROTECTED]> on 11/06/2000 11:38:44 AM To: Alan Cox <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (James A. Sutherland) cc: [EMAIL PROTECTED] (David Woodhouse), [EMAIL PROTECTED] (Jeff Garzik), [EMAIL PROTECTED] (Dan Hollis), [EMAIL PROTECTED] (Alan Cox), [EMAIL PROTECTED] (Oliver Xymoron), [EMAIL PROTECTED] (Keith Owens), [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec) Subject: Re: Persistent module storage [was Linux 2.4 Status / TODO page] On Mon, 06 Nov 2000, Alan Cox wrote: > > So autoload the module with a "dont_screw_with_mixer" option. When the kernel > > first boots, initialise the mixer to suitable settings (load the module with > > "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change > > the mixer settings on load. > > Which is part of what persistent module data lets you do. And without having > to mess with dont_screw_with_mixer (which if you get it wrong btw can be > fatal and hang the hardware) Eh? You just load the driver once, probably on boot, to configure sane values. This time round, you use an argument (or an ioctl or whatever) to specify the values you want. (cat /etc/sysconfig/sound/defaultvolume > /dev/sound/mixer or whatever). After that, the module can be unloaded and loaded as needed, without any need to touch the mixer settings except in response to *explicit* "set volume" commands from userspace. James. - 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: [patch] NE2000
[EMAIL PROTECTED] wrote: > > Hello! > > > No, that code is correct, provided (current->state == TASK_RUNNING) > > on entry. If it isn't, there's a race window which can cause > > lost wakeups. As a check you could add: > > > > if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0) > > BUG(); > > Though it really cannot happen and really happens, as we have seen... 8) > > In any case, Andrew, where is the race, when we enter in sleeping state? > Wakeup is not lost, it is just not required when we are not going > to schedule and force task to running state. set_current_state(TASK_INTERRUPTIBLE); add_wait_queue(...); /* window here */ set_current_state(TASK_INTERRUPTIBLE); schedule(); If there's a wakeup by another CPU (or this CPU in an interrupt) in that window, current->state will get switched to TASK_RUNNING. Then it's immediately overwritten and we go to sleep. Lost wakeup. > I still do not see how it is possible that task runs in sleeping state. > Apparently, set_current_state is forgotten somewhere. Do you see, where? 8) Nope. Is Jorge running SMP? - 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/
CONFIG_BLK_DEV_RAM_SIZE not used
What's up with CONFIG_BLK_DEV_RAM_SIZE? It is set in .config by "make config", but it not used by the kernel. I checked the cvs tree and see that it was used for in a single rev of the file. Looks to me like this change may have been lost by accident. Can anyone confirm or deny? Is someone who can fix this on this maillist? cvs diff -r1.59 -r1.60 rd.c < int rd_size = 8192; /* Size of the RAM disks */ < int rd_size = 4096; /* Size of the RAM disks */ > int rd_size = CONFIG_BLK_DEV_RAM_SIZE;/* Size of the RAM disks */ cvs diff -r1.60 -r1.61 rd.c < int rd_size = CONFIG_BLK_DEV_RAM_SIZE;/* Size of the RAM disks */ > int rd_size = 4096; /* Size of the RAM disks */ -- Michael Pruznick, [EMAIL PROTECTED] - 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] drivers/isdn/hisax/nj_{s,u}.c fails compilation (2.4.0-test10)
Hi.
If I compile a 2.4.0-test10 kernel without pci support I get a compile
error in both drivers/isdn/hisax/nj_u.c and nj_s.c. The patch below
fixes these in what I hope is the Right Way. But I am not sure, so
Linus is not cc'ed on this. Please forward to him if the patches are
correct.
--- linux-240-t10-clean/drivers/isdn/hisax/nj_s.c Sat Nov 4 23:25:26 2000
+++ linux/drivers/isdn/hisax/nj_s.c Mon Nov 6 23:52:00 2000
@@ -148,11 +148,10 @@
return(0);
test_and_clear_bit(FLG_LOCK_ATOMIC, >HW_Flags);
- for ( ;; )
- {
-
#if CONFIG_PCI
+ for ( ;; )
+ {
if (!pci_present()) {
printk(KERN_ERR "Netjet: no PCI bus present\n");
return(0);
--- linux-240-t10-clean/drivers/isdn/hisax/nj_u.c Sat Nov 4 23:25:26 2000
+++ linux/drivers/isdn/hisax/nj_u.c Mon Nov 6 23:51:50 2000
@@ -150,11 +150,10 @@
return(0);
test_and_clear_bit(FLG_LOCK_ATOMIC, >HW_Flags);
- for ( ;; )
- {
-
#if CONFIG_PCI
+ for ( ;; )
+ {
if (!pci_present()) {
printk(KERN_ERR "NETspider-U: no PCI bus present\n");
return(0);
--
Regards,
Rasmus([EMAIL PROTECTED])
You know how dumb the average guy is? Well, by definition, half
of them are even dumber than that.
-- J.R. "Bob" Dobbs
-
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/
