alpha stack problem: resource.h
Hi
Yesterday I installed 2.2.19 one of out alpha servers and I found that it
still has the same bug that we patched 2.2.14 to get rid of. In the 2.4 line
it seems to be fixed.
The bug has the affect that a unprev. user cannot increase the stack limit
even if he/she is allowed to.
This mailing list item fom Jun 12 2000 describes the problem:
http://www.uwsg.iu.edu/hypermail/linux/alpha/0006.1/0003.html
It is because wrong value in the
/usr/src/linux/include/asm-alpha/resource.h
The INIT_RLIMITS defined the RLIMIT_STACK as
{_STK_LIM, _STK_LIM}
The latter defines hard limit of the stack.
When I pointed the problem, only Intel and PPC people corrected it.
You should change the value as
{_STK_LIM, LONG_MAX}
and recompile your kernel.
It will resolve your problem.
I can report that is does resolve the problem here. Is this a bug or is the
kernel supposed to work that way?
/Allan
Outlook stinks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: Athlon-optimized 2.4.4pre7 still won't boot.
I have an Athlon + VIA system that would never boot an Athlon-optimized 2.4.3[-ac*], and just FYI, it will not boot an Athlon-optimized 2.4.4pre7 either. It does compile without errors, and an otherwise identical i686 kernel boots and appears to run fine. With the Athlon kernel I get a flood of boot-time error messages that streams off the screen, so I do not know exactly what the trigger is; it ultimately hangs without completing the boot. I have tried a couple of times with different compilers, and I notice that sometimes it gets past the point of mounting the disks, and other times it does not get that far. The tail of the message on my most recent try is: Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing The most basic poop follows. If this is news, I'll be happy to provide however much more detail you require. Thanks, Bobby Bryant Austin, Texas % cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 1202.732 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 2398.61 % cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 3). Master Capable. Latency=8. Prefetchable 32 bit memory at 0xd000 [0xd3ff]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (rev 0). Master Capable. No bursts. Min Gnt=4. Bus 0, device 7, function 0: ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 64). Bus 0, device 7, function 1: IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 6). Master Capable. Latency=32. I/O at 0xe000 [0xe00f]. Bus 0, device 7, function 2: USB Controller: VIA Technologies, Inc. UHCI USB (rev 22). IRQ 9. Master Capable. Latency=32. I/O at 0xe400 [0xe41f]. Bus 0, device 7, function 4: Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 64). Bus 0, device 8, function 0: VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] (rev 1). IRQ 10. Non-prefetchable 32 bit memory at 0xd400 [0xd4003fff]. Prefetchable 32 bit memory at 0xd500 [0xd57f]. Bus 0, device 12, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16). IRQ 11. Master Capable. Latency=32. Min Gnt=32.Max Lat=64. I/O at 0xec00 [0xecff]. Non-prefetchable 32 bit memory at 0xd700 [0xd7ff]. % gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.0) = % rpm -q gcc gcc-2.96-71 (That's from a Red Hat "Rawhide" RPM of a few weeks back.) Also, the "kgcc" hack gives the same result: % kgcc -v Reading specs from /usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: __alloc_pages: 4-order allocation failed
I am seeing this as well on 2.4.3 with both _get_free_pages() and kmalloc(). In the kmalloc case, the modules hang waiting for memory. Jeff On Wed, Apr 25, 2001 at 09:09:57PM -0400, Feng Xian wrote: > Hi, > > I am running linux-2.4.3 on a Dell dual PIII machine with 128M memory. > After the machine runs a while, dmesg shows, > > __alloc_pages: 4-order allocation failed. > __alloc_pages: 3-order allocation failed. > __alloc_pages: 4-order allocation failed. > __alloc_pages: 4-order allocation failed. > __alloc_pages: 4-order allocation failed. > __alloc_pages: 4-order allocation failed. > > > and sometime the system will crash. I looked into the memory info, > there still has some free physical memory (20M) left and swap space is > almost not in use. (250M swap) > > I didn't have this problem when I ran 2.4.0 (I even didn't see it on > 2.4.2) could anybody tell me what's wrong or where should I look into this > problem? > > Thanks, > > Alex > > -- > Feng Xian > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reiserfs highmem bug on tail reads
Ok, so all the reiserfs tail bugs weren't quite fixed yet, the last
tail fix can cause problems with highmem turned on. Both bugs are
in fs/reiserfs/inode.c:_get_block_create_0
When reading the tail in, if the buffer was already up to date,
we skip the disk i/o and return. But the cleanup code assumes the
page was kmap'd, which isn't right.
Also, there was a chance to double kmap the page if kmap scheduled a
nd the tree balanced while we slept. This bug has been there for
a long time.
Anyway, this was tested with Andrea's HIGHMEM_DEBUG_MERE_MORTALS
patch to force highmem on my 128MB machine. It works for me, but
more testers are always good.
-chris
against 2.4.4-pre6, should work against 2.4.3 or higher.
diff -Nru a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
--- a/fs/reiserfs/inode.c Wed Apr 25 23:15:14 2001
+++ b/fs/reiserfs/inode.c Wed Apr 25 23:15:14 2001
@@ -374,9 +374,11 @@
** sure we need to. But, this means the item might move if
** kmap schedules
*/
-p = (char *)kmap(bh_result->b_page) ;
-if (fs_changed (fs_gen, inode->i_sb) && item_moved (&tmp_ih, &path)) {
-goto research;
+if (!p) {
+ p = (char *)kmap(bh_result->b_page) ;
+ if (fs_changed (fs_gen, inode->i_sb) && item_moved (&tmp_ih, &path)) {
+ goto research;
+ }
}
p += offset ;
memset (p, 0, inode->i_sb->s_blocksize);
@@ -420,14 +422,15 @@
ih = get_ih (&path);
} while (1);
+flush_dcache_page(bh_result->b_page) ;
+kunmap(bh_result->b_page) ;
+
finished:
pathrelse (&path);
bh_result->b_blocknr = 0 ;
bh_result->b_dev = inode->i_dev;
mark_buffer_uptodate (bh_result, 1);
bh_result->b_state |= (1UL << BH_Mapped);
-flush_dcache_page(bh_result->b_page) ;
-kunmap(bh_result->b_page) ;
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: it isn't aa's rwsem-generic-6 bug but something else [Re: aa's rwsem-generic-6 bug? Process stuck in 'R' state.]
Andrea Arcangeli [[EMAIL PROTECTED]] wrote: > On Wed, Apr 25, 2001 at 10:39:39PM -0500, Bob McElrath wrote: > > Running 2.4.4pre4 with Andrea's rwsem-generic-6 patch, I have just > > gotten a process stuck in the 'R' state. According to the ps man page > > this is: "runnable (on run queue)". The 'ps aux' output is: > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > > root 7921 0.8 26.9 91720 68608 ? R< 00:33 11:20 /usr/X11R6/bin/X > > > > X is niced at -10 and doesn't respond to kill or kill -9. > > > > alpha 21164 (ev56) architecture. kernel compiled with: > > gcc version 2.96 2731 (Red Hat Linux 7.0) > > The fact X is also part of the equation makes things even less obvious > (now we're not even sure it's a kernel bug). Tell me about it. But the fact remains that I never see these hangs with a 2.2 kernel. I've also futzed with X quite a bit to try and track this down, to no avail. I have tracked down some separate X bugs though. In the next iteration I'll use the mga driver from XFree86 CVS (which had some alpha-specific changes, I hear). During this last hang I tried to get gdb to attach to the X process. gdb hung after issuing 'attach 7921', and had to be killed. My naive interpretation is that this indicates a kernel problem, and nothing to do with X. Egad I wish this were more reproducible. Having a hang once every 3 days sucks for debugging. > generic-rwsem-6 is a very trivial implementation and I'm pretty sure it > is the _last_ thing that could go wrong in your equation. I mean if it > goes wrong then it's more likely to be a bug in the spinlocks or > whatever in the architectural part of the kernel than in the common code > (rwsem-generic-6 was all common code btw). > > Furthmore the X server shouldn't really be such an heavy user of the > rwsemaphores, as first it's not even threaded. When I posted this bug originally, you came right out and said it was probably the rwsemaphores. I really have no idea how the rwsemaphores work, and don't know myself that they are even the problem. My process-table-hang seems consistent with something having a lock on the process table and not letting go of it. (Note in this last "hang", the process table did not hang...that is, ps dumped the entire process list without a burp) > You can also press SYSRQ+P and get some EIP so we see a bit more what's > going on with the X server (assuming such cpu still receives interrupt). The CPU still receives interrupts, and other than this one X process, acts normally. (even in the process-table-hang-case...as long as I don't run ps, everything is fine) I had to reboot to get rid of the hung X process though. (shutdown proceeded normally) I'm running a debug X build at this point, and have identified at least two separate bugs in the X server that were causing hangs. I've reported these to the X people. I didn't get debug info out of the X server after the process-table-hang because X continued to behave normally during the process-table-hang. > BTW, could you also try to compile with egcs 1.1.2 just in case? I > learnt the hard way that for the alpha gcc 2.95.* isn't going to work > well (I didn't tried official 95.3 exactly yet, but certainly an older .3 > from the 2_95-branch of gcc cvs definitely miscompiled all my 2.4 > kernels, 2.96 with some houndred of patches [literally] is certainly > better than 2.95.* on the alpha but egcs is definitely still worth a > try) (personally I'm using egcs 1.1.2 for the 2.[24] alpha kernels and > 2.95.4 (2_95-branch of cvs) for the 2.[24] x86 kernels [and gcc 3.1 for > x86-64 ;]) I have been using egcs 1.1.2 (rh7 kgcc) Only this last hang was with a 2.96-compiled kernel (I forgot to change the makefile to use kgcc instead of gcc...then figured what the hell) The rest were with egcs 1.1.2. I'll use egcs 1.1.2 in the future. Cheers, -- Bob Bob McElrath ([EMAIL PROTECTED]) Univ. of Wisconsin at Madison, Department of Physics PGP signature
Re: 2.2.19 Realaudio masq problem
Le 25 Apr 2001 18:12:38 -0500, Whit Blauvelt a écrit : > On Wed, Apr 25, 2001 at 10:56:11PM +0200, Xavier Bestel wrote: > > Le 25 Apr 2001 14:52:56 -0400, Dave Mielke a écrit : > > > > strace writes to standard error, not standard output, by default. Better yet, > > > though, use the -o option of strace to direct its output to a file, which > > > leaves the standard output streams alone for the aplication being traced. > > Okay, so being unfamiliar with strace, I should be able to invoke something > like "strace -o log realplay some-realaudio-url"? And this should mean > something to me? > > > I didn't follow this thread at all (just caught this last mail), but I > > use realplayer8 here, and I actually had to *rmmod* the realaudio > > masquerading module to make it stream audio from the internet on a > > masqueraded machine. The server is a debian with kernel 2.2.19, does > > NAT. > > Thanks for reasuring me there's something broken in the module. Xavier, do > you happen to know what transport mode your realplay is using then? That > would show under View | Preferences | Transport. And if you hit the > Autoconfigure button therer, does it succeed? It doesn't for me either with > or without the module loaded, and it used to with a 2.2.17 kernel plus > realplay 7 rather than 8. Well, it says 'Automatically select best transport', and Autoconfigure doesn't succeed. With or without ip_masq_raudio. > Of course, the masq module is only to handle udp - if real goes to tcp it > doesn't need it, so I suspect what Xavier's seeing is it working via tcp - > but perhaps some servers today refuse to do anything but udp connections? I confirm it uses TCP for streaming (I just looked with ethereal). The problem is that when insmoding ip_masq_raudio on the firewall, realplayer just hangs when buffering - if the server only supported UDP, I suspect it would negociate TCP or something like that. Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] swap-speedup-2.4.3-B3 (fwd)
On Thu, 26 Apr 2001, Marcelo Tosatti wrote: > On Thu, 26 Apr 2001, Mike Galbraith wrote: > > > > Comments? > > > > More of a question. Neither Ingo's nor your patch makes any difference > > on my UP box (128mb PIII/500) doing make -j30. > > Well, my patch incorporates Ingo's patch. > > It is now integrated into pre7, btw. > > > It is taking me 11 1/2 > > minutes to do this test (that's horrible). Any idea why?~ > > Not really. (darn) > If you have concurrent swapping activity, pre7 should improve the > performance since all swap IO is asynchronous now. Only paths which really > need to stop and wait for the swap data are doing it. (eg do_swap_page) I'll grab virgin pre7 in a few. > > (I can get it to under 9 with MUCH extremely ugly tinkering. I've done > > this enough to know that I _should_ be able to do 8 1/2 minutes ~easily) > > Which kind of changes you're doing to get better performance on this test? Prevent cache collapse at all cost is #one. Matching deactivation rate to launder/reclaim.. et al. Trying HARD to give PG_referenced a chance to happen between aging scans [1]. -Mike 1. pagecache is becoming swapcache and must be aged before anything is done. Meanwhile we're calling refill_inactive_scan() so fast that noone has a chance to touch a page. Age becomes a simple counter.. I think. When you hit a big surge, swap pages are at the back of all lists, so all of your valuable cache gets reclaimed before we write even one swap page. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Tiny little problem
Hi, I have a problem with accessing a magneto opto drive in Linux. Since I upgraded the kernel from 2.3 to 2.4 I can mount the MO drive but if I try to access a file on the drive the kernel oopses... After the kernel oops the MO can't be unmounted. The MO is has a SCSI-2 interface and the SCSI interface is a Symbios NCR8xx type. Any ideas?? Cheers, /Tore - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.x APM interferes with FA311TX/natsemi.o
SUMMARY: the APM call apm_bios_call_simple(APM_FUNC_SET_STATE, 0x100, APM_STATE_READY, &eax) causes my Netgear FA311TX to enter a sleep mode. DESCRIPTION: I am having difficulties with the natsemi.o driver with a Netgear FA311TX. When the call apm_bios_call_simple(APM_FUNC_SET_STATE, 0x100, APM_STATE_READY, &eax) is made, the PMEEN (PME enable) bit in the CCSR register on my FA311 mysteriously changes from 0 to 1, causing the card to stop processing received packets. This APM call is made when unblanking the screen, for instance when switching from KD_GRAPHICS to KD_TEXT with the KDSETMODE ioctl on a virtual terminal. I've modified this APM call to report the status of the PMEEN bit before and after the short sequence of assembly statement in apm_bios_call_simple() is executed. I'm guessing there isn't any interrupt activity between my "before" and "after" checks. At least the natsemi.o driver's interrupt handler isn't being called, but I can't vouch for other interrupt handlers. I'm more-or-less stuck for what to do next. I'm a complete novice with the kernel, the PCI bus, APM, or network cards, and this is my first project. I'd appreciate pointers for what to try next, since I've received no responses from the driver maintainers Donald Becker, Tjeerd Mulder, and Jeff Garzik yet. Please cc me in any responses, as I'm not currently subscribed to the kernel mailing list. Thanks in advance. -Paul Komarek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] to detect ActionTec PCI modem
This patch modifies serial.c to detect the ActionTec PCI modem. This
particular device has a class of PCI_CLASS_COMMUNICATION_OTHER, so it
isn't detected by the current catch-all rule that detects devices of
"PCI_CLASS_COMMUNICATION_SERIAL".
Patch is against kernel 2.4.3. Tested to compiled and run. Comments
welcome.
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
--- clean-2.4.3/drivers/char/serial.c Fri Mar 30 23:15:33 2001
+++ linux/drivers/char/serial.c Tue Apr 24 16:32:02 2001
@@ -4706,6 +4728,8 @@
static struct pci_device_id serial_pci_tbl[] __devinitdata = {
+ { PCI_VENDOR_ID_ATT, PCI_DEVICE_ID_ATT_VENUS_MODEM,
+ PCI_ANY_ID, PCI_ANY_ID, },
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_COMMUNICATION_SERIAL << 8, 0x00, },
{ 0, }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] swap-speedup-2.4.3-B3 (fwd)
On Thu, 26 Apr 2001, Mike Galbraith wrote: > > Comments? > > More of a question. Neither Ingo's nor your patch makes any difference > on my UP box (128mb PIII/500) doing make -j30. Well, my patch incorporates Ingo's patch. It is now integrated into pre7, btw. > It is taking me 11 1/2 > minutes to do this test (that's horrible). Any idea why?~ Not really. If you have concurrent swapping activity, pre7 should improve the performance since all swap IO is asynchronous now. Only paths which really need to stop and wait for the swap data are doing it. (eg do_swap_page) > (I can get it to under 9 with MUCH extremely ugly tinkering. I've done > this enough to know that I _should_ be able to do 8 1/2 minutes ~easily) Which kind of changes you're doing to get better performance on this test? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with "su -" and kernels 2.4.3-ac11 and higher
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> writes:
>> > Did you try nesting more than one "su -"? The first one after a boot
>> > works for me - every other one fails.
>>
>> Same here: the first "su -" works OK, but a second nested one hangs:
>
> It appears to be a bug in PAM. Someone seems to reply on parent/child running
> order and just got caught out
>
I once debugged a very simular sounding problem that I solved with
the following patch to login. It's a wild guess, but you could try if
it happens to solve it. If not it might at least be a hint of what has to
be done to su.
(the problem is that the extra process PAM keeps waiting is process leader)
(I don't have redhat, so I can't check if this is relevant here)
diff -ur util-linux-2.9x/login-utils/login.c util-linux-2.9x-ton/login-utils/login.c
--- util-linux-2.9x/login-utils/login.c Sun Sep 12 23:25:30 1999
+++ util-linux-2.9x-ton/login-utils/login.c Tue Sep 21 03:24:52 1999
@@ -1109,6 +1112,15 @@
exit(0);
}
/* child */
+
+if (tcsetpgrp(0, getpid()) < 0)
+fprintf(stderr,
+_("login: could not become foreground process group: %s\n"),
+strerror(errno));
+if (setpgid(0, 0) < 0)
+fprintf(stderr, _("login: could not become process leader: %s\n"),
+strerror(errno));
+
#endif
signal(SIGINT, SIG_DFL);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] swap-speedup-2.4.3-B3 (fwd)
On Wed, 25 Apr 2001, Marcelo Tosatti wrote: > On Tue, 24 Apr 2001, Linus Torvalds wrote: > > > Basically, I don't want to mix synchronous and asynchronous > > interfaces. Everything should be asynchronous by default, and waiting > > should be explicit. > > The following patch changes all swap IO functions to be asynchronous by > default and changes the callers to wait when needed (except > rw_swap_page_base which will block writers if there are too many in flight > swap IOs). > > Ingo's find_get_swapcache_page() does not wait on locked pages anymore, > which is now up to the callers. > > time make -j32 test with 4 CPUs machine, 128M ram and 128M swap: > > pre5 > > 228.04user 28.14system 5:16.52elapsed 80%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (525113major+678617minor)pagefaults 0swaps > > pre5 + attached patch > > 227.18user 25.49system 3:40.53elapsed 114%CPU (0avgtext+0avgdata > 0maxresident)k > 0inputs+0outputs (495387major+644924minor)pagefaults 0swaps > > > Comments? More of a question. Neither Ingo's nor your patch makes any difference on my UP box (128mb PIII/500) doing make -j30. It is taking me 11 1/2 minutes to do this test (that's horrible). Any idea why? (I can get it to under 9 with MUCH extremely ugly tinkering. I've done this enough to know that I _should_ be able to do 8 1/2 minutes ~easily) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
it isn't aa's rwsem-generic-6 bug but something else [Re: aa's rwsem-generic-6 bug? Process stuck in 'R' state.]
On Wed, Apr 25, 2001 at 10:39:39PM -0500, Bob McElrath wrote: > Running 2.4.4pre4 with Andrea's rwsem-generic-6 patch, I have just > gotten a process stuck in the 'R' state. According to the ps man page > this is: "runnable (on run queue)". The 'ps aux' output is: > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 7921 0.8 26.9 91720 68608 ? R< 00:33 11:20 /usr/X11R6/bin/X > > X is niced at -10 and doesn't respond to kill or kill -9. > > alpha 21164 (ev56) architecture. kernel compiled with: > gcc version 2.96 2731 (Red Hat Linux 7.0) The fact X is also part of the equation makes things even less obvious (now we're not even sure it's a kernel bug). generic-rwsem-6 is a very trivial implementation and I'm pretty sure it is the _last_ thing that could go wrong in your equation. I mean if it goes wrong then it's more likely to be a bug in the spinlocks or whatever in the architectural part of the kernel than in the common code (rwsem-generic-6 was all common code btw). Furthmore the X server shouldn't really be such an heavy user of the rwsemaphores, as first it's not even threaded. You can also press SYSRQ+P and get some EIP so we see a bit more what's going on with the X server (assuming such cpu still receives interrupt). BTW, could you also try to compile with egcs 1.1.2 just in case? I learnt the hard way that for the alpha gcc 2.95.* isn't going to work well (I didn't tried official 95.3 exactly yet, but certainly an older .3 from the 2_95-branch of gcc cvs definitely miscompiled all my 2.4 kernels, 2.96 with some houndred of patches [literally] is certainly better than 2.95.* on the alpha but egcs is definitely still worth a try) (personally I'm using egcs 1.1.2 for the 2.[24] alpha kernels and 2.95.4 (2_95-branch of cvs) for the 2.[24] x86 kernels [and gcc 3.1 for x86-64 ;]) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects?
On Wed, 25 Apr 2001, Dan Maas wrote: > The only other possibility I can think of is a scheduler anomaly. A thread > arose on this list recently about strange scheduling behavior of processes > using local IPC - even though one process had readable data pending, the > kernel would still go idle until the next timer interrupt. If this is the > case, then HZ=1024 would kick the system back into action more quickly... Hmm. I've caught tasks looping here (experimental tree but..) with interrupts enabled, but schedule never being called despite having many runnable tasks. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
aa's rwsem-generic-6 bug? Process stuck in 'R' state.
Running 2.4.4pre4 with Andrea's rwsem-generic-6 patch, I have just gotten a process stuck in the 'R' state. According to the ps man page this is: "runnable (on run queue)". The 'ps aux' output is: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 7921 0.8 26.9 91720 68608 ? R< 00:33 11:20 /usr/X11R6/bin/X X is niced at -10 and doesn't respond to kill or kill -9. alpha 21164 (ev56) architecture. kernel compiled with: gcc version 2.96 2731 (Red Hat Linux 7.0) Cheers, -- Bob Bob McElrath ([EMAIL PROTECTED]) Univ. of Wisconsin at Madison, Department of Physics PGP signature
Re: __alloc_pages: 4-order allocation failed
On Wed, 25 Apr 2001, Feng Xian wrote: > Hi, > > I am running linux-2.4.3 on a Dell dual PIII machine with 128M memory. > After the machine runs a while, dmesg shows, > > __alloc_pages: 4-order allocation failed. > __alloc_pages: 3-order allocation failed. > __alloc_pages: 4-order allocation failed. > __alloc_pages: 4-order allocation failed. > __alloc_pages: 4-order allocation failed. > __alloc_pages: 4-order allocation failed. > > > and sometime the system will crash. I looked into the memory info, > there still has some free physical memory (20M) left and swap space is > almost not in use. (250M swap) > > I didn't have this problem when I ran 2.4.0 (I even didn't see it on > 2.4.2) could anybody tell me what's wrong or where should I look into this > problem? Feng, Which apps are you running when this happens ? Thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops when using the Netfilter QUEUE target
On Tue, 24 Apr 2001 19:25:47 +0200, Martin Clausen <[EMAIL PROTECTED]> wrote: >I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops >in some cases when injecting new packets through Netfilter's QUEUE target. The >problem >Entering kdb (current=0xc68f6000, pid 884) Oops: Oops >due to oops @ 0xc01e7456 >eax = 0x05dc ebx = 0xc7acf224 ecx = 0x000e edx = 0xc72f8440 >esi = 0xc7cee740 edi = 0x esp = 0xc68f7c90 eip = 0xc01e7456 >ebp = 0xc68f7cb0 xss = 0x0018 xcs = 0x0010 eflags = 0x00010287 >xds = 0x0018 xes = 0x0018 origeax = 0x ®s = 0xc68f7c5c >kdb> > >I will be glad to submit som more (debug) information?! At the very least, you need to run the kdb commands 'bt' (backtrace) and 'id %eip-0x10' (disassemble around failing instruction). Registers and eip on their own are almost meaningless. ps. Don't copy me on the reply, I only maintain kdb, not the failing netfilter code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RAWIO-6 update [was Re: RAWIO-5 and O_DIRECT-3 updates]
On Tue, Apr 24, 2001 at 08:56:00AM +0200, Andrea Arcangeli wrote:
> I fixed a new bug pointed out by Andrew and discussed on the kiobuf list
> (thanks Andrew!) (lock_kiovec was not handling correctly a failed trylockpage
> and could unlock pages locked by other people, not a big deal though as such
> function is never called in the whole pre6 and I'm wondering if it make sense
> at all to allow the pinned pages to be locked down in 2.4 [it certainly is
> still necessary in 2.2 for all the reads from disk]). However I didn't killed
> that function just in case there's an useful use of it. New updated rawio patch
> against vanilla 2.4.4pre6 is here:
>
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre6/rawio-5.bz2
My 2.4 rawio-* patches had from the start an annoying bug that can be
triggered only with machines with more than 1G (I know, strictly
speaking some houndred MB less than 1G for vmalloc and friends but you
got it)
The bug is caused by this debugging check in the highmem bounce buffer
code that I didn't trapped while keeping the slab cache constructed
to improve the allocation of the buffer headers:
memset(&bh->b_wait, -1, sizeof(bh->b_wait));
The side effect of the bug is that the kernel locks hard while paging
init in during boot (as said above only if you have more than 1G of
ram). You can guess why I didn't trapped it during regression testing.
So this is the incremental fix against rawio-5:
diff -urN rawio-5/mm/highmem.c rawio-6/mm/highmem.c
--- rawio-5/mm/highmem.cThu Dec 14 22:34:14 2000
+++ rawio-6/mm/highmem.cThu Apr 26 02:37:07 2001
@@ -207,6 +207,10 @@
bh_orig->b_end_io(bh_orig, uptodate);
__free_page(bh->b_page);
+#ifdef HIGHMEM_DEBUG
+ /* Don't clobber the constructed slab cache */
+ init_waitqueue_head(&bh->b_wait);
+#endif
kmem_cache_free(bh_cachep, bh);
}
@@ -260,12 +264,14 @@
bh->b_count = bh_orig->b_count;
bh->b_rdev = bh_orig->b_rdev;
bh->b_state = bh_orig->b_state;
+#ifdef HIGHMEM_DEBUG
bh->b_flushtime = jiffies;
bh->b_next_free = NULL;
bh->b_prev_free = NULL;
/* bh->b_this_page */
bh->b_reqnext = NULL;
bh->b_pprev = NULL;
+#endif
/* bh->b_page */
if (rw == WRITE) {
bh->b_end_io = bounce_end_io_write;
@@ -274,7 +280,9 @@
bh->b_end_io = bounce_end_io_read;
bh->b_private = (void *)bh_orig;
bh->b_rsector = bh_orig->b_rsector;
+#ifdef HIGHMEM_DEBUG
memset(&bh->b_wait, -1, sizeof(bh->b_wait));
+#endif
return bh;
}
(side note: right now HIGHMEM_DEBUG is enabled by default and that's ok of
course)
And here it is an update that is now supposed to work with highmem
machines as well:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre7/rawio-6
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects?
On Wed, 25 Apr 2001, Dan Maas wrote: > > Are there any negative effects of editing include/asm/param.h to change > > HZ from 100 to 1024? Or any other number? This has been suggested as a > > way to improve the responsiveness of the GUI on a Linux system. > > I have also played around with HZ=1024 and wondered how it affects > interactivity. I don't quite understand why it could help - one thing I've > learned looking at kernel traces (LTT) is that interactive processes very, > very rarely eat up their whole timeslice (even hogs like X). So more > frequent timer interrupts shouldn't have much of an effect... > > If you are burning CPU doing stuff like long compiles, then the increased HZ > might make the system appear more responsive because the CPU hog gets > pre-empted more often. However, you could get the same result just by > running the task 'nice'ly... A tradeoff of having better system responsiveness by having the kernel to check more often if a running process should be preempted is that the CPU spends more time in Kernel Mode and less time in User Mode. And as a consequence, user programs run slower. Regards, Werner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] handling of failed copy_thread() in do_fork()
If copy_thread() fails (it can't happen on x86, but on other architectures, e.g. on sparc, it's possible) do_fork() doesn't do full cleanup - it forgets to do exit_mm(). Obvious fix follows. Please, apply. Al diff -urN S4-pre7/kernel/fork.c S4-pre7-fork/kernel/fork.c --- S4-pre7/kernel/fork.c Wed Apr 25 20:43:12 2001 +++ S4-pre7-fork/kernel/fork.c Wed Apr 25 22:12:39 2001 @@ -652,7 +652,7 @@ goto bad_fork_cleanup_sighand; retval = copy_thread(0, clone_flags, stack_start, stack_size, p, regs); if (retval) - goto bad_fork_cleanup_sighand; + goto bad_fork_cleanup_mm; p->semundo = NULL; /* Our parent execution domain becomes current domain @@ -708,6 +708,8 @@ down(&sem); return retval; +bad_fork_cleanup_mm: + exit_mm(p); bad_fork_cleanup_sighand: exit_sighand(p); bad_fork_cleanup_fs: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: random reboots
I've gotten a lot more response to this than I'd ever dreamed, but I figured out the problem on my own... I have (had) one of those exhaust fans that fits into a PCI/ISA slot, and it died. Not only did it die, but it started creating heat of it's own. I don't think the video card adjacent to it appreciated this a whole lot. I removed the dead fan, and everything is back to normal, I just need to go get a new fan to make myself feel better ;-) The 1007 bios, and ac14 have been perfectly stable, so no worries about either. Thanks, Nathan Petr Vandrovec wrote: > > On Tue, Apr 24, 2001 at 12:18:42PM -0400, Nathan Walp wrote: > > I upgraded the BIOS on this Asus A7V sometime in the past week, but I > > honestly don't remember when. From 1005C to 1007. This was released in > > march, so I assumed it was pretty stable, but it could be the cause. > > I'm going to go downgrade now, but is this more likely to be a kernel > > bug, or a hardware bug/new bios bug? > > No problem here. I'm using 1007 since its release in first half > of March. > > Linux version 2.4.3-ac12-amd (root@ppc) (gcc version 3.0 20010402 (Debian >prerelease)) #1 Mon Apr 23 02:31:13 CEST 2001 > ... > Kernel command line: BOOT_IMAGE=Linux ro root=2105 video=matrox:vesa:0x105,fv:85 >devfs=nomount > Initializing CPU#0 > Detected 1009.013 MHz processor. > ... > CPU: AMD Athlon(tm) Processor stepping 02 > Enabling fast FPU save and restore... done. > ... > apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) > ... > > Except that I got 'ide only func: 14' today with my Promise PDC20265 > (which looks strange to me - either all Intel, VIA and Promise have > same bug in their UDMA hardware, or there is a bug in Linux IDE > driver...) (I had to reboot because of kernel somehow believed that > it read some garbage instead of MBR from hdg, so I could not run my > repartitioning session, as I found no way to invalidate hdg kernel > cache). > But machine for sure does not spontaneously reboot. And I have > enabled local apic in kernel configuration. All previous kernels > were built with Debian's 2.95.3-something, ac12 was built with > gcc-3.0, as I wanted to update anyway, and ac12 just gave me a reason. > Best regards, > Petr Vandrovec > [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects?
> Are there any negative effects of editing include/asm/param.h to change > HZ from 100 to 1024? Or any other number? This has been suggested as a > way to improve the responsiveness of the GUI on a Linux system. I have also played around with HZ=1024 and wondered how it affects interactivity. I don't quite understand why it could help - one thing I've learned looking at kernel traces (LTT) is that interactive processes very, very rarely eat up their whole timeslice (even hogs like X). So more frequent timer interrupts shouldn't have much of an effect... If you are burning CPU doing stuff like long compiles, then the increased HZ might make the system appear more responsive because the CPU hog gets pre-empted more often. However, you could get the same result just by running the task 'nice'ly... The only other possibility I can think of is a scheduler anomaly. A thread arose on this list recently about strange scheduling behavior of processes using local IPC - even though one process had readable data pending, the kernel would still go idle until the next timer interrupt. If this is the case, then HZ=1024 would kick the system back into action more quickly... Of course, the appearance of better interactivity could just be a placebo effect. Double-blind trials, anyone? =) Regards, Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Architecture-specific include files
> "Matthew" == Matthew Wilcox <[EMAIL PROTECTED]> writes: Matthew> Something which came up in one of the hallway discussions at Matthew> the kernelsummit was that a lot of the architecture Matthew> maintainers would find it more convenient if the Matthew> arch-specific header files were moved from include/asm-$ARCH Matthew> to arch/$ARCH/include. Since we use a symlink _anyway_, no Matthew> global changes to include statements are necessary, we'd Matthew> merely need to change Makefile from [snip] Matthew> Would anyone have a problem with this change? It'll make for Matthew> a hell of a big patch from Linus, but it really will simplify Matthew> the lives of the architecture maintainers. I don't see what it saves, except for the fact you just have to run diff -urN once instead of twice when you want to send Linus a large diff. Or am I missing something? Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Matrox FB console driver
On Tue, Apr 24, 2001 at 06:19:31AM -0500, Andy Carlson wrote: > time prime before x > real1m23.535s > user0m40.550s > sys 0m42.980s > > time prime in X > real0m42.835s > user0m41.180s > sys 0m1.710s There can be two reasons: (1) You are using matrox's mga module. They have 'program chip core to production level frequency instead of bios safe one' in their changelog. Although difference 100% makes (2) more probably. (2) matroxfb does not try to activate any AGP transfer mode. Maybe some X driver tries and succeeds. You can try: time dd if=/dev/zero of=/dev/fb0 bs=1M count=8 before X and after X. If times are same, then it is chip core frequency. If times are 2:1, it is either chip memory freqency, or AGP... Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: random reboots
On Tue, Apr 24, 2001 at 12:18:42PM -0400, Nathan Walp wrote: > I upgraded the BIOS on this Asus A7V sometime in the past week, but I > honestly don't remember when. From 1005C to 1007. This was released in > march, so I assumed it was pretty stable, but it could be the cause. > I'm going to go downgrade now, but is this more likely to be a kernel > bug, or a hardware bug/new bios bug? No problem here. I'm using 1007 since its release in first half of March. Linux version 2.4.3-ac12-amd (root@ppc) (gcc version 3.0 20010402 (Debian prerelease)) #1 Mon Apr 23 02:31:13 CEST 2001 ... Kernel command line: BOOT_IMAGE=Linux ro root=2105 video=matrox:vesa:0x105,fv:85 devfs=nomount Initializing CPU#0 Detected 1009.013 MHz processor. ... CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. ... apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) ... Except that I got 'ide only func: 14' today with my Promise PDC20265 (which looks strange to me - either all Intel, VIA and Promise have same bug in their UDMA hardware, or there is a bug in Linux IDE driver...) (I had to reboot because of kernel somehow believed that it read some garbage instead of MBR from hdg, so I could not run my repartitioning session, as I found no way to invalidate hdg kernel cache). But machine for sure does not spontaneously reboot. And I have enabled local apic in kernel configuration. All previous kernels were built with Debian's 2.95.3-something, ac12 was built with gcc-3.0, as I wanted to update anyway, and ac12 just gave me a reason. Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird problem with 2.4.4-pre6
Tobias Ringstrom wrote: > > Yesterday, I was running tcpdump, paging the output with less. All of a > sudden, less started to dump core (SIGSEGV). I could not even start less > by itself: > > > less > > without it getting a SIGSEGV, and in fact no user could run less without > getting a SIGSEGV, but it did work perfectly a few minutes earlier. This > morning, I tried to run less again, and now it was working! No core > dumps! > > How can this happen? Something overwriting the page/buffer cache? Yes. Something scribbled on the pagecache, most likely. If this happens, take a copy of the offending binary and all its shared libraries - simply copy them into a temp directory. The corrupted version will be written to disk, from the pagecache. Make sure you keep a copy of the offending vmlinux as well for looking things up in. Then reboot and start diffing things; the differences can provide clues. If the diffs show single-bit errors then it's a RAM problem. If the diffs look like pointers into kernel space then look 'em up in vmlinux and shout loudly. etc. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
Mark Hahn wrote: > the main goal at this point is to make kernel proc-related > code more efficient, easy-to-use, etc. a purely secondary goal > is to make user-space tools more robust, efficient, and simpler. > > there are three things that need to be communicated through the proc > interface, for each chunk of data: its type, it's name and its value. > it's critical that data be tagged in some way, since that's the only > way to permit back-compatibility. that is, a tool looking for a particular > tag will naturally ignore new data with other tags. Agreed. > [three example schemes in use in /proc today] > I have a sense that all of these could be collapsed into a single > api where kernel systems would register hierarchies of tuples of > , where callback would be passed the tag, > and proc code would take care of "rendering" the data into > human readable text (default), binary, or even xml. Sounds reasonable to me. Relieve the modules of having to format their /proc entries by defining standard code that does it. And as an extra bonus, if tuples registration was table-driven, the tables would define a grammar that could be fed to a parser generator. (It sounds a little bit like the snmpd code I'm working on, actually. How eerie.) (It also sounds a little like (gasp) the windows registry, but hey, that's ok.) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
__alloc_pages: 4-order allocation failed
Hi, I am running linux-2.4.3 on a Dell dual PIII machine with 128M memory. After the machine runs a while, dmesg shows, __alloc_pages: 4-order allocation failed. __alloc_pages: 3-order allocation failed. __alloc_pages: 4-order allocation failed. __alloc_pages: 4-order allocation failed. __alloc_pages: 4-order allocation failed. __alloc_pages: 4-order allocation failed. and sometime the system will crash. I looked into the memory info, there still has some free physical memory (20M) left and swap space is almost not in use. (250M swap) I didn't have this problem when I ran 2.4.0 (I even didn't see it on 2.4.2) could anybody tell me what's wrong or where should I look into this problem? Thanks, Alex -- Feng Xian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects
Well, for kicks, I tried setting HZ to 1024 with 2.2.19. It seemed a
little more responsive, but that could be psychosomatic. :) I did notice
that I was unable to sync my palm pilot until I set it back to 100.
YMMV. The most useful "performace" tweak for a GUI that I've come across is:
#define _SHM_ID_BITS10
... if y ou're running Gnome and/or Gtk, because of its appetite for
lots of SHM segments.
-Michael
Mark Hahn wrote:
>>> Are there any negative effects of editing include/asm/param.h to change
>>> HZ from 100 to 1024? Or any other number? This has been suggested as a
>>> way to improve the responsiveness of the GUI on a Linux system. Does it
>>
> ...
>
>> Why not just run the X server at a realtime priority? Then it will get
>> to respond to existing events, such as keyboard and mouse input,
>> promptly without creating lots of superfluous extra clock interrupts.
>> I think you will find this is a better solution.
>
>
> it's surprisingly ineffective; usually, if someone thinks responsiveness
> is bad, there's a problem with the system. for instance, if the system
> is swapping, setting X (and wm, and clients) to RT makes little difference,
> since the kernel is stealing pages from them, regardless of their scheduling
> priority.
>
> if you're curious, you might be interested in two toy programs
> I've attached. one is "setrealtime", which will make a pid RT, or else act
> as a wrapper (ala /bin/time). I have it installed suid root on my system,
> though this is rather dangerous if your have lusers around. the second is a
> simple memory-hog: mmaps a bunch of ram, and keeps it active (printing out a
> handy measure of how long it took to touch its pages...)
>
> regards, mark hahn.
>
>
>
>
> #include
> #include
> #include
> #include
> #include
>
> volatile unsigned sink;
>
> double second() {
> struct timeval tv;
> gettimeofday(&tv,0);
> return tv.tv_sec + 1e-6 * tv.tv_usec;
> }
>
> int
> main(int argc, char *argv[]) {
> int doWrite = 1;
> unsigned size = 80 * 1024 * 1024;
>
> int letter;
> while ((letter = getopt(argc, argv, "s:wrvh?" )) != -1) {
> switch(letter) {
> case 's': size = atoi(optarg) * 1024 * 1024; break;
> case 'w': doWrite = 1; break;
> default:
> fprintf(stderr,"useup [-s mb][-w]\n");
> exit(1);
> }
> }
> int *base = (int*) mmap(0, size,
> PROT_READ|PROT_WRITE,
> MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
> if (base == MAP_FAILED) {
> perror("mmap failed");
> exit(1);
> }
>
> int *end = base + size/4;
>
> while (1) {
> double start = second();
> if (doWrite)
> for (int *p = base; p < end; p += 1024)
> *p = 0;
> else {
> unsigned sum = 0;
> for (int *p = base; p < end; p += 1024)
> sum += *p;
> sink = sum;
> }
> printf("%f\n",1000*(second() - start));
> }
> }
>
>
>
>
> #include
> #include
> #include
> #include
>
> int
> main(int argc, char *argv[]) {
> int uid = getuid();
> int pid = atoi(argv[1]);
> int sched_fifo_min, sched_fifo_max;
> static struct sched_param sched_parms;
>
> if (!pid)
> pid = getpid();
>
> sched_fifo_min = sched_get_priority_min(SCHED_FIFO);
> sched_fifo_max = sched_get_priority_max(SCHED_FIFO);
> sched_parms.sched_priority = sched_fifo_min + 1;
>
> if (sched_setscheduler(pid, SCHED_FIFO, &sched_parms) == -1)
> perror("cannot set realtime scheduling policy");
>
> if (uid)
> setuid(uid);
>
> if (pid == getpid())
> execvp(argv[1],&argv[1]);
> return 0;
> }
> useup.c
>
> Content-Description:
>
> useup.c
> Content-Type:
>
> TEXT/PLAIN
> Content-Encoding:
>
> BASE64
>
>
>
> setrealtime.c
>
> Content-Description:
>
> setrealtime.c
> Content-Type:
>
> TEXT/PLAIN
> Content-Encoding:
>
> BASE64
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Lid support.
I assume there is no generic APM support for lid-close? My BIOS (P100 DEC CTS5100 Hinote VP) has no way to do anything other than beep, when the lid is closed, so I'm using a hack that polls the ct65548 video chips registers to find when the BIOS turns the LCD off, so I can do whatever. Or is there a better wya? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: down_timeout
On Wed, Apr 25, 2001 at 04:21:22PM -0700, Grover, Andrew wrote:
> It seems like we need to implement down_timeout (and
> down_timeout_interruptible) to fully flesh out the semaphore implementation.
> It is difficult and inefficient to emulate this using wrapper functions, as
> far as I can see.
>
> Seems like this is a fairly standard interface to have for OS semaphores. We
> have a prototype implementation, and could contribute this, if desired.
>
> Thoughts?
Sure you can't implement this via waitqueues? semaphores use them
internally anyway.
I use this for interrupt or polling based waiting:
/* IO polling waits */
/* Timeout after this amount of jiffies */
#define IO_POLL_TIMEOUT (HZ)
/* Split timeout while polling into chunks of that many jiffies */
#define IO_POLL_SPLIT 2
/* generic interrupt based wait with timeouts! */
#define __wait_event_timeout_int(wq, condition, timeout, ret) \
do { \
struct wait_queue __wait; \
signed long __expire=timeout; \
__wait.task=current; \
add_wait_queue(wq, &__wait); \
for (;;) { \
current->state=TASK_UNINTERRUPTIBLE; \
mb(); \
if (condition) break; \
__expire=schedule_timeout(__expire); \
if (__expire == 0) { \
ret=-ETIMEDOUT; \
break; \
} \
} \
current->state = TASK_RUNNING; \
remove_wait_queue(wq, &__wait); \
} while (0)
/* polling wait, if we shouldn't use interrupts for this */
#define __wait_event_timeout_poll(wq, condition, timeout, ret) \
do { \
unsigned int __tries=0; \
unsigned int __maxtry=timeout / IO_POLL_SPLIT; \
do { \
schedule_timeout(IO_POLL_SPLIT); \
if (condition) \
break; \
} while (++__tries < __maxtry); \
if (__tries == __maxtry && !condition) \
ret=-ETIMEDOUT; \
} while (0)
#ifdef INTS_ARE_CHEAP
#define __wait_event_timeout(wq, condition, timeout, ret) \
__wait_event_timeout_int(wq, condition, timeout, ret)
#else /* INTS_ARE_CHEAP */
#define __wait_event_timeout(wq, condition, timeout, ret) \
__wait_event_timeout_poll(wq, condition, timeout, ret)
#endif /* INTS_ARE_CHEAP */
#define wait_event_timeout(wq, condition, timeout, ret) \
do { \
if (condition) \
break; \
__wait_event_timeout(wq, condition, timeout, ret); \
} while (0)
What about that?
Use it just as you use wait_event() but check for -ETIMEDOUT as
value in ret.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag
been there and had much fun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: filp_open() in 2.2.19 causes memory corruption
On Mon, Apr 23, 2001 at 11:47:27PM +0100, David Woodhouse wrote: David/LKML, I've gotten to the bottom of this problem, and you are correct that klog is trashing the messages file for the oops. As for the oops, it was related to the use of ll_rw_blk() instead of submit_bh() in 2.4.3 which was causing memory corruption in Linus' buffer cache code. In NetWare, we used to create a signature field for I/O and other structures that were submitted by modules other than the media manager. This would be useful for the buffer cache to put in a signature field so if he ever gets back a buffer head that is not his, the buffer cache could drop it with a noisy message rather than have memory corruption and other side effects that take days to track down. Jeff > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
down_timeout
It seems like we need to implement down_timeout (and down_timeout_interruptible) to fully flesh out the semaphore implementation. It is difficult and inefficient to emulate this using wrapper functions, as far as I can see. Seems like this is a fairly standard interface to have for OS semaphores. We have a prototype implementation, and could contribute this, if desired. Thoughts? Regards -- Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reiserfs lfs fix for 2.4.4-pre5 and above
Hello everyone,
2.4.4-pre5 started honoring the s_maxbytes field, so reiserfs needs a
patch to allow files > 4GB on 3.6.x format filesystems.
If you work with large files on reiserfs and are willing to try
the prerelease kernels (non-production), please give this a try,
it works for me but I'd like a few confirmations before I send to Linus.
This also prevents someone from using truncate to expand an old
format file past the 2GB mark.
-chris
diff -Nru a/fs/reiserfs/file.c b/fs/reiserfs/file.c
--- a/fs/reiserfs/file.cTue Apr 24 13:37:21 2001
+++ b/fs/reiserfs/file.cTue Apr 24 13:37:21 2001
@@ -106,6 +106,24 @@
return ( n_err < 0 ) ? -EIO : 0;
}
+static int reiserfs_setattr(struct dentry *dentry, struct iattr *attr) {
+struct inode *inode = dentry->d_inode ;
+int error ;
+if (attr->ia_valid & ATTR_SIZE) {
+ /* version 2 items will be caught by the s_maxbytes check
+ ** done for us in vmtruncate
+ */
+if (inode_items_version(inode) == ITEM_VERSION_1 &&
+ attr->ia_size > MAX_NON_LFS)
+return -EFBIG ;
+}
+
+error = inode_change_ok(inode, attr) ;
+if (!error)
+inode_setattr(inode, attr) ;
+
+return error ;
+}
struct file_operations reiserfs_file_operations = {
read: generic_file_read,
@@ -119,6 +137,7 @@
struct inode_operations reiserfs_file_inode_operations = {
truncate: reiserfs_vfs_truncate_file,
+setattr:reiserfs_setattr,
};
diff -Nru a/fs/reiserfs/super.c b/fs/reiserfs/super.c
--- a/fs/reiserfs/super.c Tue Apr 24 13:37:21 2001
+++ b/fs/reiserfs/super.c Tue Apr 24 13:37:21 2001
@@ -492,7 +492,11 @@
SB_BUFFER_WITH_SB (s) = bh;
SB_DISK_SUPER_BLOCK (s) = rs;
s->s_op = &reiserfs_sops;
-s->s_maxbytes = 0x;/* 4Gig */
+
+/* new format is limited by the 32 bit wide i_blocks field, want to
+** be one full block below that.
+*/
+s->s_maxbytes = (512LL << 32) - s->s_blocksize ;
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] swap-speedup-2.4.3-B3 (fwd)
Resending...
-- Forwarded message --
Date: Tue, 24 Apr 2001 23:28:38 -0300 (BRT)
From: Marcelo Tosatti <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]>,
Linux Kernel List <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
Rik van Riel <[EMAIL PROTECTED]>,
Szabolcs Szakacsits <[EMAIL PROTECTED]>
Subject: Re: [patch] swap-speedup-2.4.3-B3
On Tue, 24 Apr 2001, Linus Torvalds wrote:
> Basically, I don't want to mix synchronous and asynchronous
> interfaces. Everything should be asynchronous by default, and waiting
> should be explicit.
The following patch changes all swap IO functions to be asynchronous by
default and changes the callers to wait when needed (except
rw_swap_page_base which will block writers if there are too many in flight
swap IOs).
Ingo's find_get_swapcache_page() does not wait on locked pages anymore,
which is now up to the callers.
time make -j32 test with 4 CPUs machine, 128M ram and 128M swap:
pre5
228.04user 28.14system 5:16.52elapsed 80%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (525113major+678617minor)pagefaults 0swaps
pre5 + attached patch
227.18user 25.49system 3:40.53elapsed 114%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (495387major+644924minor)pagefaults 0swaps
Comments?
diff -Nur linux.orig/include/linux/pagemap.h linux/include/linux/pagemap.h
--- linux.orig/include/linux/pagemap.h Wed Apr 25 00:51:36 2001
+++ linux/include/linux/pagemap.h Wed Apr 25 00:53:04 2001
@@ -77,7 +77,12 @@
unsigned long index, struct page **hash);
extern void lock_page(struct page *page);
#define find_lock_page(mapping, index) \
- __find_lock_page(mapping, index, page_hash(mapping, index))
+ __find_lock_page(mapping, index, page_hash(mapping, index))
+
+extern struct page * __find_get_swapcache_page (struct address_space * mapping,
+ unsigned long index, struct page **hash);
+#define find_get_swapcache_page(mapping, index) \
+ __find_get_swapcache_page(mapping, index, page_hash(mapping, index))
extern void __add_page_to_hash_queue(struct page * page, struct page **p);
diff -Nur linux.orig/include/linux/swap.h linux/include/linux/swap.h
--- linux.orig/include/linux/swap.h Wed Apr 25 00:51:36 2001
+++ linux/include/linux/swap.h Wed Apr 25 00:53:04 2001
@@ -111,8 +111,8 @@
extern int try_to_free_pages(unsigned int gfp_mask);
/* linux/mm/page_io.c */
-extern void rw_swap_page(int, struct page *, int);
-extern void rw_swap_page_nolock(int, swp_entry_t, char *, int);
+extern void rw_swap_page(int, struct page *);
+extern void rw_swap_page_nolock(int, swp_entry_t, char *);
/* linux/mm/page_alloc.c */
@@ -121,8 +121,7 @@
extern void add_to_swap_cache(struct page *, swp_entry_t);
extern int swap_check_entry(unsigned long);
extern struct page * lookup_swap_cache(swp_entry_t);
-extern struct page * read_swap_cache_async(swp_entry_t, int);
-#define read_swap_cache(entry) read_swap_cache_async(entry, 1);
+extern struct page * read_swap_cache_async(swp_entry_t);
/* linux/mm/oom_kill.c */
extern int out_of_memory(void);
diff -Nur linux.orig/mm/filemap.c linux/mm/filemap.c
--- linux.orig/mm/filemap.c Wed Apr 25 00:51:35 2001
+++ linux/mm/filemap.c Wed Apr 25 00:53:04 2001
@@ -678,6 +678,34 @@
}
/*
+ * Find a swapcache page (and get a reference) or return NULL.
+ * The SwapCache check is protected by the pagecache lock.
+ */
+struct page * __find_get_swapcache_page(struct address_space *mapping,
+ unsigned long offset, struct page **hash)
+{
+ struct page *page;
+
+ /*
+* We need the LRU lock to protect against page_launder().
+*/
+
+ spin_lock(&pagecache_lock);
+ page = __find_page_nolock(mapping, offset, *hash);
+ if (page) {
+ spin_lock(&pagemap_lru_lock);
+ if (PageSwapCache(page))
+ page_cache_get(page);
+ else
+ page = NULL;
+ spin_unlock(&pagemap_lru_lock);
+ }
+ spin_unlock(&pagecache_lock);
+
+ return page;
+}
+
+/*
* Same as the above, but lock the page too, verifying that
* it's still valid once we own it.
*/
diff -Nur linux.orig/mm/memory.c linux/mm/memory.c
--- linux.orig/mm/memory.c Wed Apr 25 00:51:35 2001
+++ linux/mm/memory.c Wed Apr 25 00:53:04 2001
@@ -1040,7 +1040,7 @@
break;
}
/* Ok, do the async read-ahead now */
- new_page = read_swap_cache_async(SWP_ENTRY(SWP_TYPE(entry), offset),
0);
+ new_page = read_swap_cache_async(SWP_ENTRY(SWP_TYPE(entry), offset));
if (new_page != NULL)
page_cache_release(new_page);
swap_free(SWP_ENTRY(SWP_TYPE(entry), offset));
@@ -1063,1
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 21:19, you wrote: > The corresponding one-value-per-file approach can probably be made to > be a single call per value. Yes, the real problem is writing a callback-based filesystem (unless you want to hold everything in memory). After thinking about it for the last two hours I already find the one-value-per-file approach not as hard to do as I did before, but it's still a lot of work. > Have you bothered to go back and read the old discussions on this topic? Yes. But in my case is different than, for example, the files in /proc/sys: - the file names in /proc/sys are static. For devreg the filenames must be made dynamically (similar to the /proc process directories or usbdevfs) - in /proc/sys there is just one piece for code responsible for every file or directory and no cooperation between different parts. If devreg creates, for example, a directory for a USB mouse it must be prepared to share this directory with the USB subsystem, the input subsystem and the USB hid driver. All four modules are responsible for their own files. - files and their content should be created on demand, so there must be some callback to tell the USB subsystem something like "the user just opened the directory of device X, please tell me which directories or files you want to add". It is certainly possible to convert devreg to the one-value-per-file approach and if this is all that it takes to get into some future (2.5) kernel I will do it. I just doubt that this is the easiest way to implement the functionality, because that's what I really want. > Are you trying to avoid writing a DTD? Yes, at least a have a complete DTD, because it would be a nightmare to maintain it. Each time somebody adds a new capability to a driver the DTD would have to be updated. And what about drivers that are not part of the official kernel? I thought about using a separate XML Schema definition for each namespace though. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects
> > Are there any negative effects of editing include/asm/param.h to change
> > HZ from 100 to 1024? Or any other number? This has been suggested as a
> > way to improve the responsiveness of the GUI on a Linux system. Does it
...
> Why not just run the X server at a realtime priority? Then it will get
> to respond to existing events, such as keyboard and mouse input,
> promptly without creating lots of superfluous extra clock interrupts.
> I think you will find this is a better solution.
it's surprisingly ineffective; usually, if someone thinks responsiveness
is bad, there's a problem with the system. for instance, if the system
is swapping, setting X (and wm, and clients) to RT makes little difference,
since the kernel is stealing pages from them, regardless of their scheduling
priority.
if you're curious, you might be interested in two toy programs
I've attached. one is "setrealtime", which will make a pid RT, or else act
as a wrapper (ala /bin/time). I have it installed suid root on my system,
though this is rather dangerous if your have lusers around. the second is a
simple memory-hog: mmaps a bunch of ram, and keeps it active (printing out a
handy measure of how long it took to touch its pages...)
regards, mark hahn.
#include
#include
#include
#include
#include
volatile unsigned sink;
double second() {
struct timeval tv;
gettimeofday(&tv,0);
return tv.tv_sec + 1e-6 * tv.tv_usec;
}
int
main(int argc, char *argv[]) {
int doWrite = 1;
unsigned size = 80 * 1024 * 1024;
int letter;
while ((letter = getopt(argc, argv, "s:wrvh?" )) != -1) {
switch(letter) {
case 's': size = atoi(optarg) * 1024 * 1024; break;
case 'w': doWrite = 1; break;
default:
fprintf(stderr,"useup [-s mb][-w]\n");
exit(1);
}
}
int *base = (int*) mmap(0, size,
PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
if (base == MAP_FAILED) {
perror("mmap failed");
exit(1);
}
int *end = base + size/4;
while (1) {
double start = second();
if (doWrite)
for (int *p = base; p < end; p += 1024)
*p = 0;
else {
unsigned sum = 0;
for (int *p = base; p < end; p += 1024)
sum += *p;
sink = sum;
}
printf("%f\n",1000*(second() - start));
}
}
#include
#include
#include
#include
int
main(int argc, char *argv[]) {
int uid = getuid();
int pid = atoi(argv[1]);
int sched_fifo_min, sched_fifo_max;
static struct sched_param sched_parms;
if (!pid)
pid = getpid();
sched_fifo_min = sched_get_priority_min(SCHED_FIFO);
sched_fifo_max = sched_get_priority_max(SCHED_FIFO);
sched_parms.sched_priority = sched_fifo_min + 1;
if (sched_setscheduler(pid, SCHED_FIFO, &sched_parms) == -1)
perror("cannot set realtime scheduling policy");
if (uid)
setuid(uid);
if (pid == getpid())
execvp(argv[1],&argv[1]);
return 0;
}
Re: routing & ipchains
In message <3AE6208C.8379.146C84FE@localhost> you write: > Greetings All, > After upgrading from kernel 2.0.38 w/ slackware-3.4 to > kernel 2.2.16 w/ slackware-7.1 I have developed the following > routing problems. > > Hardware - > eth0 - 10meg on net 192.168.0.0 i/f 192.168.0.1 subnet > 255.255.255.128 > eth1 - 100meg on net 192.168.0.128 i/f 192.168.0.130 subnet > 255.255.255.128 > > >From either network I can use ipchains and surf/telnet/ftp/... on > each network to the ppp0 dialup connection. I cannot ping or > anything from eth0 to eth1 or back. Um, I don't see what this has to do with ipchains, but my guess is: echo 1 > /proc/sys/net/ipv4/ip_forward Rusty. -- Premature optmztion is rt of all evl. --DK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 23:16, you wrote: > Not necessarily. If the "extended data" is put following the current data > (since the data is currently record oriented) just making the output > format longer will not/should not casue problems in reading the data. > Alternatively, you can always put one value per record: > tag:value > tag2:value2... Both solutions only work for simple data, they dont help for more complex things like adding a variable-sized list of structures. Actually the first devreg version used something like your second proposal and I gave it up because it wasnt flexible enough to add USB configuration data. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #define HZ 1024 -- negative effects?
On Tue, 24 Apr 2001, Michael Rothwell wrote: > Are there any negative effects of editing include/asm/param.h to change > HZ from 100 to 1024? Or any other number? This has been suggested as a > way to improve the responsiveness of the GUI on a Linux system. Does it > throw off anything else, like serial port timing, etc.? Why not just run the X server at a realtime priority? Then it will get to respond to existing events, such as keyboard and mouse input, promptly without creating lots of superfluous extra clock interrupts. I think you will find this is a better solution. Nigel Gamble[EMAIL PROTECTED] Mountain View, CA, USA. http://www.nrg.org/ MontaVista Software [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Thu, 26 Apr 2001, J . A . Magallon wrote: > > On 04.25 Doug McNaught wrote: > > "J . A . Magallon" <[EMAIL PROTECTED]> writes: > > > > > Question: it is possible to redirect the same fs call (say read) to > > different > > > implementations, based on the open mode of the file descriptor ? So, if > > > you open the entry in binary, you just get the number chunk, if you open > > > it in ascii you get a pretty printed version, or a format description like > > > > There is no distinction between "text" and "binary" modes on a file > > descriptor. The distinction exists in the C stdio layer, but is a > > no-op on Unix systems. > > > > Yep, realized after the post, fopen() is a wrapper for open(). The idea > is to (someway) set the proc entry in verbose vs fast-binary mode for > reads. Perhaps an ioctl() or an fcntl() or something similar. > So the verbose mode gives the field names, and the binary mode just > gives the numbers. Applications that know what are reading can just > read binary data, and fast. OK, _what_ applications spend a considerable time (and considerable percentage of the total execution time) parsing stuff in /proc? ps(1)? top(1)? Fine. They touch how many files outside of /proc//* ? Exactly. _Please_, drop this idiotic "parsing ASCII is slow" strawman. Or show some valid examples. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
> > Question: it is possible to redirect the same fs call (say read) to different > > implementations, based on the open mode of the file descriptor ? So, if > > you open the entry in binary, you just get the number chunk, if you open > > it in ascii you get a pretty printed version, or a format description like > > There is no distinction between "text" and "binary" modes on a file > descriptor. The distinction exists in the C stdio layer, but is a > no-op on Unix systems. of course. but we could trivially define O_PROC_BINARY, or an ioctl/fcntl, or even do something fancy like use lseek(). pardon my stream of consciousness here, but: I think it's well-established that proc exists for humans, and that there's no real sympathy for the eternal whines of how terribly hard it is to parse. it's NOT hard to parse, but would be more trivial if it were more consistent. the main goal at this point is to make kernel proc-related code more efficient, easy-to-use, etc. a purely secondary goal is to make user-space tools more robust, efficient, and simpler. there are three things that need to be communicated through the proc interface, for each chunk of data: its type, it's name and its value. it's critical that data be tagged in some way, since that's the only way to permit back-compatibility. that is, a tool looking for a particular tag will naturally ignore new data with other tags. /proc/sys is an attempt to provide tagged data; it works well, is easy to comprehend, but requires an open for each datum, and provides no hints about type. /proc/cpuinfo is another attempt: "tag : data", with no attempt to provide types. the tags have also mutated somewhat over time. /proc/partitions is an example of a record-oriented file: one line per record, and tags for the record members at the top. still no typing information. I have a sense that all of these could be collapsed into a single api where kernel systems would register hierarchies of tuples of , where callback would be passed the tag, and proc code would take care of "rendering" the data into human readable text (default), binary, or even xml. the latter would require some signalling mechanism like O_PROC_XML or the like. further, programs could perform a meta-query, where they ask for the types and tags of a datum (or hierarchy), so that on subsequent queries, they'd now how to handle binary data. if only one piece of code handled the rendering of /proc stuff, it could do more, without burdoning all the disparate /proc producers. regards, mark hahn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long standing bug in alternate stack handling
On Wed, Feb 21, 2001 at 11:02:17PM +0100, Christian Ehrhardt wrote:
Hi,
[ Sorry for the follow up on my own post ]
> If a signal handler is registered with the SA_ONSTACK flag the
> kernel will try to execute the signal handler on the alternate
> stack even if no such stack is registered.
Here's a simple patch for i386. Please consider it for inclusion.
Posix explicitly requires the behaviour implemented by this patch.
--- arch/i386/kernel/signal.c.old Mon Sep 25 22:10:28 2000
+++ arch/i386/kernel/signal.c Sun Apr 22 16:04:47 2001
@@ -371,7 +371,7 @@
/* This is the X/Open sanctioned signal stack switching. */
if (ka->sa.sa_flags & SA_ONSTACK) {
- if (! on_sig_stack(esp))
+ if (sas_ss_flags(esp) == 0)
esp = current->sas_ss_sp + current->sas_ss_size;
}
NOTE: As far as I can tell all archs are affected by this bug.
best regards Christian Ehrhardt
--
THAT'S ALL FOLKS!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
test
mail test - ignore - John Heil South Coast Software Custom systems software for UNIX and IBM MVS mainframes 1-714-774-6952 [EMAIL PROTECTED] http://www.sc-software.com - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Thu, Apr 26, 2001 at 12:03:25AM +0200, J . A . Magallon wrote: > > On 04.25 Doug McNaught wrote: > > "J . A . Magallon" <[EMAIL PROTECTED]> writes: > > > > > Question: it is possible to redirect the same fs call (say read) to > > different > > > implementations, based on the open mode of the file descriptor ? So, if > > > you open the entry in binary, you just get the number chunk, if you open > > > it in ascii you get a pretty printed version, or a format description like > > > > There is no distinction between "text" and "binary" modes on a file > > descriptor. The distinction exists in the C stdio layer, but is a > > no-op on Unix systems. > > > > Yep, realized after the post, fopen() is a wrapper for open(). The idea > is to (someway) set the proc entry in verbose vs fast-binary mode for > reads. Perhaps an ioctl() or an fcntl() or something similar. > So the verbose mode gives the field names, and the binary mode just > gives the numbers. Applications that know what are reading can just > read binary data, and fast. Eh. Search in archives for "ascii is tough"... -- marko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 Realaudio masq problem
On Wed, Apr 25, 2001 at 10:56:11PM +0200, Xavier Bestel wrote: > Le 25 Apr 2001 14:52:56 -0400, Dave Mielke a écrit : > > strace writes to standard error, not standard output, by default. Better yet, > > though, use the -o option of strace to direct its output to a file, which > > leaves the standard output streams alone for the aplication being traced. Okay, so being unfamiliar with strace, I should be able to invoke something like "strace -o log realplay some-realaudio-url"? And this should mean something to me? > I didn't follow this thread at all (just caught this last mail), but I > use realplayer8 here, and I actually had to *rmmod* the realaudio > masquerading module to make it stream audio from the internet on a > masqueraded machine. The server is a debian with kernel 2.2.19, does > NAT. Thanks for reasuring me there's something broken in the module. Xavier, do you happen to know what transport mode your realplay is using then? That would show under View | Preferences | Transport. And if you hit the Autoconfigure button therer, does it succeed? It doesn't for me either with or without the module loaded, and it used to with a 2.2.17 kernel plus realplay 7 rather than 8. Of course, the masq module is only to handle udp - if real goes to tcp it doesn't need it, so I suspect what Xavier's seeing is it working via tcp - but perhaps some servers today refuse to do anything but udp connections? Whit PS: Please cc me, I'm not on the list. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On 04.25 Doug McNaught wrote: > "J . A . Magallon" <[EMAIL PROTECTED]> writes: > > > Question: it is possible to redirect the same fs call (say read) to > different > > implementations, based on the open mode of the file descriptor ? So, if > > you open the entry in binary, you just get the number chunk, if you open > > it in ascii you get a pretty printed version, or a format description like > > There is no distinction between "text" and "binary" modes on a file > descriptor. The distinction exists in the C stdio layer, but is a > no-op on Unix systems. > Yep, realized after the post, fopen() is a wrapper for open(). The idea is to (someway) set the proc entry in verbose vs fast-binary mode for reads. Perhaps an ioctl() or an fcntl() or something similar. So the verbose mode gives the field names, and the binary mode just gives the numbers. Applications that know what are reading can just read binary data, and fast. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.3-ac14 #1 SMP Wed Apr 25 02:07:45 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
"J . A . Magallon" <[EMAIL PROTECTED]> writes: > Question: it is possible to redirect the same fs call (say read) to different > implementations, based on the open mode of the file descriptor ? So, if > you open the entry in binary, you just get the number chunk, if you open > it in ascii you get a pretty printed version, or a format description like There is no distinction between "text" and "binary" modes on a file descriptor. The distinction exists in the C stdio layer, but is a no-op on Unix systems. -Doug -- The rain man gave me two cures; he said jump right in, The first was Texas medicine--the second was just railroad gin, And like a fool I mixed them, and it strangled up my mind, Now people just get uglier, and I got no sense of time... --Dylan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Fwd: Help with Fasttrack/100 Raid on Linux]
> This is probably the first and last time I will openly agree for someone > to tell me were to go, and do it ;-). > > You tell me what you want the driver to do, and I will make it happen. > It will be legal and technically correct. Does that sound like a good > idea? > > Cheers, > > Andre Hedrick > that would be great the first thing the driver must do is boot from the boot partition and mount my partition where i installed linux on with the promise driver for redhat ;=) assie
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On 04.25 Jesse Pollard wrote: > > Alternatively, you can always put one value per record: > tag:value > tag2:value2... > > This is still simpler than XML to read, and to generate. > Just my two cents. It looks clear that /proc is for programs, not for humans. So the best format for proc is just binary values. So programs can read it quickly, even in a chunk if they know the format. But sometimes it is usefull to do a cat on a /proc entry. Question: it is possible to redirect the same fs call (say read) to different implementations, based on the open mode of the file descriptor ? So, if you open the entry in binary, you just get the number chunk, if you open it in ascii you get a pretty printed version, or a format description like Bus: %d Device: %h .. to 'vprintf' the values. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.3-ac14 #1 SMP Wed Apr 25 02:07:45 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drivers/usb/hid.c
Hi: Been battling w. my new Gravis joystick [kernel 2.4.3-ac5] - the
driver wouldn't recognise it through the gameport, but would through the
USB port [the stick came with a converter]. I did have one problem though:
I had to apply the following one line patch to get the joystick hat to
work correctly: Don't know if this is generally correct, as I only have
one USB joystick with which to test it.
--- linux/drivers/usb/hid.c~Sat Apr 21 20:34:33 2001
+++ linux/drivers/usb/hid.c Sat Apr 21 20:38:51 2001
@@ -78,7 +78,7 @@
static struct {
__s32 x;
__s32 y;
-} hid_hat_to_axis[] = {{ 0,-1}, { 1,-1}, { 1, 0}, { 1, 1}, { 0, 1}, {-1, 1}, {-1,
0}, {-1,-1}, { 0, 0}};
+} hid_hat_to_axis[] = {{ 0, 0}, { 0,-1}, { 1,-1}, { 1, 0}, { 1, 1}, { 0, 1}, {-1,
+1}, {-1, 0}, {-1,-1}};
static char *hid_types[] = {"Device", "Pointer", "Mouse", "Device", "Joystick",
"Gamepad", "Keyboard", "Keypad", "Multi-Axis
Controller"};
--
I've had a perfectly wonderful evening. But this wasn't it.
-- Groucho Marx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs & IrDA
On Tue, 24 Apr 2001, Jean Tourrilhes wrote: > > I've got a question... I would like where to send my driver > patches... Probably both me and Alan. [ General rules follow. Too few people seem to have seen them before ] Most importantly, when sending patches to me: - specify clearly that you really want to see them in the standard kernel, and why. I occasionally get patches that just say "this is a good idea". I don't apply them. Especially if they are cc'd to somebody else too, in which case I pretty much assume that it's a RFC, not a "real patch". - do NOT send patches in attachements. Send one patch per mail, in clear-text under your message, so that I can easily see the patch and decide then-and-there whether it looks ok. And if it doesn't look ok, and I do a "reply", the patch gets included in the reply so that I can point out which part of the patch I dislike. Don't worry about sending me five emails. That's FINE. I much prefer seeing five consecutive emails from the same person with five distinct subject lines and five distinct patches, than seeing one email with five attachements to it. - if your email system is broken, and you want to send patches as attachements to avoid whitspace damage, then please FIX YOUR EMAIL SYSTEM INSTEAD. - Don't point to web-sites. If I have to move the mouse outside my email xterm to work on the email, your email just got ignored. - Make your patches one sub-directory under the source tree you're working on. In short, your patches should look like something like --- clean/fs/inode.c ... +++ linux/fs/inode.c .. @@ -179,7 +179,7 @@ ... so that I can (regardless of where my source tree is) apply them with "patch -p1" from my linux top directory. Then I can just do a cd v2.4/linux patch -p1 < ~/multiple-emails-with-multiple-accepted-patches and not have to worry about three patches being based on /usr/src/linux, while two others not having a path at all and being individual filenames in linux/drivers/net. - and finally: re-send. If I had laser-eye surgery the fay you sent the patches, I won't have applied them. If I took a day off and spent it with the kids at the pool instead, I won't have applied them. If I decided that this weekend I'm not going to read email for a change, I won't have applied them. And when I come back to work a day or two later, I will have several hundred other emails to work through. I never go backwards in my emails. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Wed, 25 Apr 2001 [EMAIL PROTECTED] wrote: > so i guess i deserve opinions instead of flames. the > approach is from personal use, not the usual server use. > if you think a server setup is best for all use just say so, > i'm listening. Several distributions (Red Hat and Mandrake certainly) offer auto-login tools. In conjunction with those tools, take the approach that Apple used with OS X and setup "sudo" for administrative tasks on the machine. This allows the end user to generally administer the machine without all the need to hack the kernel, modify login, operate as root, etc. You can even restrict their actions with it and log what they do. In the end though, I really don't see the big deal with having a root user for general home use. Even traditionally stand-alone operating systems have gone to this model (Mac OS X) or are heading that way fast (Windows XP). There are always ways to configure permissions, and even in a stand-alone environment it's always better to protect against accidental deletion of system critical files. In other words, the benefits vastly outweigh the minor inconvenience. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
Tim Jansen <[EMAIL PROTECTED]>: > On Wednesday 25 April 2001 21:37, you wrote: > > Personally, I think > >>proc_printf(fragment, "%d %d",get_portnum(usbdev), usbdev->maxchild); > > is shorter (and faster) to parse with > > fscanf(input,"%d %d",&usbdev,&maxchild); > > Right, but what happens if you need to extend the format? For example > somebody adds support for USB 2.0 to the kernel and you need to some new > values. Then you would have the choice between changing the format and > breaking applications or keeping the format and dont provide the additional > information. > With XML (or single-value-per-file) it is easy to tell application to ignore > unknown tags (or files). When you just list values you will be damned sooner > or later, unless you make up additional rules that say how apps should handle > these cases. And then your approach is no longer simple, but possibly even > more complicated Not necessarily. If the "extended data" is put following the current data (since the data is currently record oriented) just making the output format longer will not/should not casue problems in reading the data. Just look at FORTRAN for an example of a extensible input :-) More data on the record will/should just be ignored. The only coding change might be to use a fgets to read a record, followed by a sscanf to get the known values. Alternatively, you can always put one value per record: tag:value tag2:value2... This is still simpler than XML to read, and to generate. The problem with this and XML is the same - If the tag is no longer relevent (or changes its name), then the output must either continue to include it, or break applications that depend on that tag. In all cases, atomic extraction of the structured data will be problematical since there may be buffering issues in output. XML is very verbose, and the tagged format better; but a series of values goes even farther... Try them out - Just go through the /proc/net formats and stick in the XML... Just don't count on the regular utilities to decode them. It would give some actual results to compair with the current structure. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
Jesse Pollard wrote: > > But one thing XML provides (potentially) is a DTD that defines meanings and >formats. > > IMHO the kernel needs something like this for /proc (though not in DTD format!). > > > > Has anyone ever tried to write a formal syntax for all the entries > > in /proc? We have bits and pieces of /proc documentation in > > /usr/src/linux/Documentation, but nothing you could feed directly > > into a parser generator. It'd be neat to have a good definition for /proc > > in the LSB, and have an LSB conformance test that could look in > > /proc and say "Yup, all the entries there conform to the spec and can > > be parsed properly."... > > From one point of view (that of the /proc entries...) each file > is by definition in the proper format. That format is specified > (in the /proc interface to the driver). Using "proc_printf" is a > specification for the output. When two different distributions ship different forks of the kernel source, which differ in the arguments passed to proc_printf, which one is right? There's no way to tell. That's why saying "the source is the spec" doesn't cut it. Also, the source is not a specification a parser generator can use. A formal spec for /proc entries maintained by e.g. the LSB is needed; it has to be separate from the source code (to avoid forking problems), and it should be machine-readable (so we can build parsers from it). > That DOES NOT mean that no improvements are possible. If the formats > used by the various modules/drivers has some variation in format from > access to acess, then the determination of that format must also be > included. From what I've seen (via "cat /proc/") the files all > have a fixed format. Sometimes the number of entries varies, but then > the count should ALSO be included in the file (in a known place of > course). The multi-entry files I've looked at (/proc/net) reach the > EOF to end the list. This is not unreasonable. Yeah, there's a general style that seems to work; it just needs to be formalized. > I'm not sure of the usefullness of the title lines that are printed. If > looked at in raw form, yes the titles are nice. But the utilities > that are aimed at examining the values should not have to discard them, nor > should the drivers have to generate them. I think they're good; they're a little bit like the XML tags you're proposing. > I can live with them anyway, since they are already there. > > The biggest problem I know of is being able to retrieve structure > in an atomic manner. Not easy (in any system, not just Linux). Something SNMP doesn't deal well with, either. People seem to cope, though. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 Realaudio masq problem
Le 25 Apr 2001 14:52:56 -0400, Dave Mielke a écrit : > [quoted lines by Whit Blauvelt on April 25, 2001, at 13:38] > > >On Tue, Apr 24, 2001 at 06:01:05PM -0700, Tim Moore wrote: > >> Try '# strace /usr/bin/X11/realplay On24ram.asp > log' and see where the > >> connect fails if you aren't getting specific error messages. > > > >Unfortunately this spits out a bunch of stuff and then totally freezes up my > >KDE 2.1.1 desktop. > > strace writes to standard error, not standard output, by default. Better yet, > though, use the -o option of strace to direct its output to a file, which > leaves the standard output streams alone for the aplication being traced. I didn't follow this thread at all (just caught this last mail), but I use realplayer8 here, and I actually had to *rmmod* the realaudio masquerading module to make it stream audio from the internet on a masqueraded machine. The server is a debian with kernel 2.2.19, does NAT. Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
- Received message begins Here - > > On Wed, 25 Apr 2001, Rick Hohensee wrote: > > > [EMAIL PROTECTED] wrote: > > > for those who didn't read that patch, i #define capable(), > > > suser(), and fsuser() to 1. the implication is all users > > > will have root capabilities. > > > > How is that not single user? > > Every user still has it's own account, means profile etc. Until some user removes all the other users Or reads the other users mail Or changes the other users configuration - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rw_semaphores, optimisations try #4
On Wed, Apr 25, 2001 at 09:06:38PM +0100, D . W . Howells wrote: > This patch (made against linux-2.4.4-pre6 + rwsem-opt3) somewhat improves > performance on the i386 XADD optimised implementation: It seems more similar to my code btw (you finally killed the useless chmxchg ;). I only had a short low at your attached patch, but the results are quite suspect to my eyes beacuse we should still be equally fast in the fast path and I should still beat you on the write fast path because I do a much faster subl; js while you do movl -1; xadd ; js, while according to your results you beat me on both. Do you have an explanation or you don't know the reason either? I will re-benchmark the whole thing shortly. But before re-benchmark if you have time could you fix the benchmark to use the variable pointer and send me a new tarball? For your code it probably doesn't matter because you dereference the pointer by hand anyways, but it matters for mine and we want to benchmark real world fast path of course. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nfs performance at high loads
Kapish K wrote: > > Hello, > I had sent in a note on nfs performance issues some time back, > and Mark Hemment had been kind enough to point out to the > zerocopy networking patch. Well, we tried with it, and it does > seem to have some improvement, but it seems to have screwed up > nfs performance a bit, because we see a LOT of rpc failures for > all kinds of calls, starting from lookup, to read and writes. > Could this possibly be triggered by this patch ( picked up from > davem's site for 2.4.0 ). > On the other hand, we do plan to migrate to 2.4.2. Can somebody > update me or provide pointers to info. as to whether we can > expect some of these problems have been resolved in 2.4.2? We > should soon be testing on 2.4.2 > Thanks > While I'm not an expert hacker or anything, I can tell you for sure, that even 2.4.2 is full of really system crippling bugs. You need to track the current kernels. All of the 2.4.x series should be compatible, in other words, you should upgrade as soon as possible to the latest stable kernel. Currently, that's 2.4.3 (not 2.4.2). And even 2.4.3 has many known bugs that are capable of 1) destroying performance and 2) destroying filesystems. At the very least, you should upgrade to 2.4.3, but better yet would be to upgrade to the 2.4.4 when it comes out (soon?), or even the 2.4.4-pre patch since it has the zero copy networking patch already included, as well as fixes for bugs that could corrupt your filesystems. The zero copy patch as it existed for 2.4.0 was also buggy in itself, so that would explain some of your extended problems. Really, 2.4.0 is a 'horrible' kernel to be running, as it is missing an enormous amount of performance fixes, and bug fixes. David -- David Mansfield (718) 963-2020 [EMAIL PROTECTED] Ultramaster Group, LLC www.ultramaster.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Lid support for ACPI
> > It'd be great if you could focus your testing and patches > on this code base > > -- I think it's a lot better but it's still a work in progress. > > Are you planning to merge to 2.4.4? Planning on merging ASAP. That may be 2.4.4, we'll see. > > PS I'm not quite sure why you copied the acpi list *and* lkml.. ;-) > > Is acpi list some kind of lkml subset? [I wanted people to know that > I'm playing with acpi. I probably should stop mailing to acpi list > that I do not read...] We have a dedicated list for ACPI so you should subscribe to it and use it. Regards -- Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 21:37, you wrote: > Personally, I think >> proc_printf(fragment, "%d %d",get_portnum(usbdev), usbdev->maxchild); > is shorter (and faster) to parse with > fscanf(input,"%d %d",&usbdev,&maxchild); Right, but what happens if you need to extend the format? For example somebody adds support for USB 2.0 to the kernel and you need to some new values. Then you would have the choice between changing the format and breaking applications or keeping the format and dont provide the additional information. With XML (or single-value-per-file) it is easy to tell application to ignore unknown tags (or files). When you just list values you will be damned sooner or later, unless you make up additional rules that say how apps should handle these cases. And then your approach is no longer simple, but possibly even more complicated bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] linux likes to kill bad inodes
On Wednesday, April 25, 2001 10:01:20 PM +0200 Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > >> > Hi! >> > >> > I had a temporary disk failure (played with acpi too much). What >> > happened was that disk was not able to do anything for five minutes >> > or so. When disk recovered, linux happily overwrote all inodes it >> > could not read while disk was down with zeros -> massive disk >> > corruption. >> > >> > Solution is not to write bad inodes back to disk. >> > >> >> Wouldn't we rather make it so bad inodes don't get marked dirty at all? > > I guess this is cheaper: we can mark inode dirty at 1000 points, but > you only write it at one point. Whoops, I worded that poorly. To me, it seems like a bug to dirty a bad inode. If this patch works, it is because somewhere, somebody did something with a bad inode, and thought the operation worked (otherwise, why dirty it?). So yes, even if we dirty them in a 1000 different places, we need to find the one place that believes it can do something worthwhile to a bad inode. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Lid support for ACPI
Hi! > We already have lid support in the latest ACPI versions (not in the official > kernel yet.) You can download this code from > http://developer.intel.com/technology/iapc/acpi/downloads.htm . This site is as ugly as hell but does the trick. (And btw link to "kernel howto" points to list of howtos [after really ugly disclaimer], not to kernel howto directly; and size of patch with "debug version" on page is wrong). > It'd be great if you could focus your testing and patches on this code base > -- I think it's a lot better but it's still a work in progress. Are you planning to merge to 2.4.4? > PS I'm not quite sure why you copied the acpi list *and* lkml.. ;-) Is acpi list some kind of lkml subset? [I wanted people to know that I'm playing with acpi. I probably should stop mailing to acpi list that I do not read...] Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rw_semaphores, optimisations try #4
This patch (made against linux-2.4.4-pre6 + rwsem-opt3) somewhat improves
performance on the i386 XADD optimised implementation:
A patch against -pre6 can be obtained too:
ftp://infradead.org/pub/people/dwh/rwsem-pre6-opt4.diff
Here's some benchmarks (take with a pinch of salt of course):
TESTNUM READERS NUM WRITERS CONTENTION DURATION
=== === === ===
rwsem-r11 0 no 10s
rwsem-r22 0 no 10s
rwsem-ro4 0 no 10s
rwsem-w10 1 no 10s
rwsem-wo0 4 w-w only10s
rwsem-rw4 2 r-w & w-w 10s
rwsem-worm 30 1 r-w & w-w 10s
rwsem-xx30 15 r-w & w-w 50s
rwsem-opt4 (mine) 00_rwsem-9 (Andrea's)
--- ---
TESTREADERS WRITERS READERS WRITERS
=== === === ===
===
rwsem-r130347096n/a 30130004n/a
30362972n/a 30127882n/a
rwsem-r211031268n/a 11035072n/a
11038232n/a 11030787n/a
rwsem-ro12641408n/a 12722192n/a
12636058n/a 12729404n/a
rwsem-w1n/a 28607326n/a 28505470
n/a 28609208n/a 28508206
rwsem-won/a 1607789 n/a 1783876
n/a 1608603 n/a 1800982
rwsem-rw545 557071 1106763 554698
1109773 555901 1103090 552567
rwsem-worm 5229696 54807 1585755 52438
5219531 54528 1588428 5
rwsem-xx5396096 2786619 5361894 2768893
5398443 2787613 5400716 2788801
I've compared my patch to Andrea's 00_rwsem-9, both built on top of
linux-2.4.4-pre6.
David
diff -uNr linux-2.4.4-pre6-opt3/include/asm-i386/rwsem.h linux/include/asm-i386/rwsem.h
--- linux-2.4.4-pre6-opt3/include/asm-i386/rwsem.h Wed Apr 25 00:12:14 2001
+++ linux/include/asm-i386/rwsem.h Wed Apr 25 20:21:31 2001
@@ -3,6 +3,30 @@
* Written by David Howells ([EMAIL PROTECTED]).
*
* Derived from asm-i386/semaphore.h
+ *
+ *
+ * The MSW of the count is the negated number of active writers and waiting
+ * lockers, and the LSW is the total number of active locks
+ *
+ * The lock count is initialized to 0 (no active and no waiting lockers).
+ *
+ * When a writer subtracts WRITE_BIAS, it'll get 0x0001 for the case of an
+ * uncontended lock. This can be determined because XADD returns the old value.
+ * Readers increment by 1 and see a positive value when uncontended, negative
+ * if there are writers (and maybe) readers waiting (in which case it goes to
+ * sleep).
+ *
+ * The value of WAITING_BIAS supports up to 32766 waiting processes. This can
+ * be extended to 65534 by manually checking the whole MSW rather than relying
+ * on the S flag.
+ *
+ * The value of ACTIVE_BIAS supports up to 65535 active processes.
+ *
+ * This should be totally fair - if anything is waiting, a process that wants a
+ * lock will go to the back of the queue. When the currently active lock is
+ * released, if there's a writer at the front of the queue, then that and only
+ * that will be woken up; if there's a bunch of consequtive readers at the
+ * front, then they'll all be woken up, but no other readers will be.
*/
#ifndef _I386_RWSEM_H
@@ -19,6 +43,10 @@
struct rwsem_waiter;
+extern struct rw_semaphore *FASTCALL(rwsem_down_read_failed(struct rw_semaphore
+*sem));
+extern struct rw_semaphore *FASTCALL(rwsem_down_write_failed(struct rw_semaphore
+*sem));
+extern struct rw_semaphore *FASTCALL(rwsem_wake(struct rw_semaphore *));
+
/*
* the semaphore definition
*/
@@ -31,8 +59,7 @@
#define RWSEM_ACTIVE_READ_BIAS RWSEM_ACTIVE_BIAS
#define RWSEM_ACTIVE_WRITE_BIAS(RWSEM_WAITING_BIAS +
RWSEM_ACTIVE_BIAS)
spinlock_t wait_lock;
- struct rwsem_waiter *wait_front;
- struct rwsem_waiter **wait_back;
+ struct list_headwait_list;
#if RWSEM_DEBUG
int debug;
#endif
@@ -48,7 +75,7 @@
#endif
#define __RWSEM_INITIALIZER(name) \
-{ RWSEM_UNLOCKED_VALUE, SPIN_LOCK_UNLOCKED, NULL, &(name).wait_front \
+{ RWSEM_UN
Re: [patch] linux likes to kill bad inodes
Hi! > > Hi! > > > > I had a temporary disk failure (played with acpi too much). What > > happened was that disk was not able to do anything for five minutes > > or so. When disk recovered, linux happily overwrote all inodes it > > could not read while disk was down with zeros -> massive disk > > corruption. > > > > Solution is not to write bad inodes back to disk. > > > > Wouldn't we rather make it so bad inodes don't get marked dirty at all? I guess this is cheaper: we can mark inode dirty at 1000 points, but you only write it at one point. But I'm no FS expert. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
On Wed, 25 Apr 2001, Rick Hohensee wrote: > [EMAIL PROTECTED] wrote: > > for those who didn't read that patch, i #define capable(), > > suser(), and fsuser() to 1. the implication is all users > > will have root capabilities. > > How is that not single user? Every user still has it's own account, means profile etc. Gruß, Markus -- | Gluecklich ist, wer vergisst, was nicht aus ihm geworden ist. +---. ,> http://www.uni-ulm.de/~s_mschab/ \ / mailto:[EMAIL PROTECTED] \_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
Jesse Pollard wrote: > Personally, I think > proc_printf(fragment, "%d %d",get_portnum(usbdev), usbdev->maxchild); > (or the string " ddd" with d representing a digit) > > is shorter (and faster) to parse with > fscanf(input,"%d %d",&usbdev,&maxchild); > > Than it would be to try parsing > > with an XML parser. > > Sorry - XML is good for some things. It is not designed to be a > interface language between a kernel and user space. > > I am NOT in favor of "one file per value", but structured data needs > to be written in a reasonable, concise manner. XML is intended for > communication between disparate systems in an exreemly precise manner > to allow some self documentation to be included when the communication > fails. Agreed. But one thing XML provides (potentially) is a DTD that defines meanings and formats. IMHO the kernel needs something like this for /proc (though not in DTD format!). Has anyone ever tried to write a formal syntax for all the entries in /proc? We have bits and pieces of /proc documentation in /usr/src/linux/Documentation, but nothing you could feed directly into a parser generator. It'd be neat to have a good definition for /proc in the LSB, and have an LSB conformance test that could look in /proc and say "Yup, all the entries there conform to the spec and can be parsed properly." (http://www.pathname.com/fhs/2.2-beta/fhs-2.2-beta.txt mentions /proc, but doesn't standardize any of it, except to suggest that /etc/mtab can be a symbolic link to /proc/mounts.) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pcnet32.c: PCI posting bug prevents 2.4.3-ac14 compilation
This one is new - 2.4.3-ac12 built without problems. make[3]: Entering directory `/usr/src/linux-2.4.3-ac14/drivers/net' gcc -D__KERNEL__ -I/usr/src/linux-2.4.3-ac14/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -m preferred-stack-boundary=2 -march=i686-c -o pcnet32.o pcnet32.c pcnet32.c:1385: warning: #warning "PCI posting bug" pcnet32.c:327: pcnet32_pci_tbl causes a section type conflict make[3]: *** [pcnet32.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.3-ac14/drivers/net' I must confess, that the meaning of the warning isn't clear to me, but that's a warning. The session-type conflict is even more vague. Reading the patch I don't see any obvious hints. I'm using Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) on a SuSE 7.1 base system. Thanks! Jurriaan -- If something was not wrong things would not be right. Sergeant Ortega - Zorro GNU/Linux 2.4.3-ac12 SMP/ReiserFS 2x1743 bogomips load av: 0.13 0.03 0.01 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
- Received message begins Here - > > On Wednesday 25 April 2001 19:10, you wrote: > > The command > > more foo/* foo/*/* > > will display the values in the foo subtree nicely, I think. > > Unfortunately it displays only the values. Dumping numbers and strings > without knowing their meaning (and probably not even the order) is not very > useful. > > > Better to factor the XML part out to a userspace library... > > But the one-value per file approach is MORE work. It would be less work to > create XML and factor out the directory structure in user-space :) > Devreg collects its data from the drivers, each driver should contribute the > information that it can provide about the device. > Printing a few values in XML format using the functions from xmlprocfs is as > easy as writing > proc_printf(fragment, "\n", > get_portnum(usbdev), usbdev->maxchild); > > Extending the devreg output with driver-specific data means registering a > callback function that prints the driver's data. The driver should use its > own XML namespace, so whatever the driver adds will not break any > (well-written) user-space applications. The data is created on-demand, so the > values can be dynamic and do not waste any space when devreg is not used. > > The code is easy to read and not larger than a solution that creates static > /proc entries, and holding the data completely static would take much more > memory. And it takes less code than a solution that would create the values > in /proc dynamically because this would mean one callback per file or a > complicated way to specify several values with a single callback. Personally, I think proc_printf(fragment, "%d %d",get_portnum(usbdev), usbdev->maxchild); (or the string " ddd" with d representing a digit) is shorter (and faster) to parse with fscanf(input,"%d %d",&usbdev,&maxchild); Than it would be to try parsing with an XML parser. Sorry - XML is good for some things. It is not designed to be a interface language between a kernel and user space. I am NOT in favor of "one file per value", but structured data needs to be written in a reasonable, concise manner. XML is intended for communication between disparate systems in an exreemly precise manner to allow some self documentation to be included when the communication fails. Even Lisp S expressions are easier :-) - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a fork-like C-wrapper for clone(), DONE!
Followup to: <9c77p7$upd$[EMAIL PROTECTED]> By author:"H. Peter Anvin" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > glibc already contains such a wrapper; it is called __clone(). At > least my system has "man clone" show the man page for it. > Actually, the man page is wrong, it's called clone() unless you define a function with that name yourself (weak symbol.) My version of the man pages are a bit old. -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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
Tim Jansen wrote: > > On Wednesday 25 April 2001 19:10, you wrote: > > The command > > more foo/* foo/*/* > > will display the values in the foo subtree nicely, I think. > > Unfortunately it displays only the values. Dumping numbers and strings > without knowing their meaning (and probably not even the order) is not very > useful. The meanings should be implied by the filenames, which are displayed (try it). The order is alphabetical by filename. > But the one-value per file approach is MORE work. It would be less work to > create XML and factor out the directory structure in user-space :) > Devreg collects its data from the drivers, each driver should contribute the > information that it can provide about the device. > Printing a few values in XML format using the functions from xmlprocfs is as > easy as writing > proc_printf(fragment, "\n", > get_portnum(usbdev), usbdev->maxchild); The corresponding one-value-per-file approach can probably be made to be a single call per value. IMHO that's more useful; it means that (once we agree on definitions) programs don't need to parse XML to access this data; they can go straight to the node in the document object model tree ( = /proc ). Think of /proc as a preparsed XML tree that hasn't been standardized yet. > The code is easy to read and not larger than a solution that creates static > /proc entries, and holding the data completely static would take much more > memory. And it takes less code than a solution that would create the values > in /proc dynamically because this would mean one callback per file or a > complicated way to specify several values with a single callback. ... but XML parsing is something we don't want to force on people when we can provide the same data in a pre-parsed, much easier to access form, IMHO. Have you bothered to go back and read the old discussions on this topic? > The driver should use its > own XML namespace, so whatever the driver adds will not break any > (well-written) user-space applications. Are you trying to avoid writing a DTD? IMHO it would be better to have a single DTD for the entire tree, rather than a separate anything-goes namespace for each driver. Yes, this is more work, but all the Linux drivers are tightly integrated into the kernel source tree, we may as well have a tightly-integrated DTD documenting what each block, serial, synch, etc. driver must provide. I think we both agree that there needs to be an easy, standardized way to access this data. IMHO there's a lot of standardizing that needs to happen before you can start writing code -- otherwise your new code won't help, and we'll be in the same mess we're in now. The DTD can apply to both the existing /proc form and any proposed XML form of config info exported by the kernel; there should be an easy transformation between them. And it has to come first! - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: a fork-like C-wrapper for clone(), DONE!
Followup to: <[EMAIL PROTECTED]> By author:Francesc Oller <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Hi all, > > Some days before I asked for a fork-like C-wrapper for clone() which > could be used like fork() thinking that somebody could have done it > before but I only received two e-mails saying that probably it > wasn't worth it or even it was complete non-sense. > > Therefore, I've done it myself. Code follows. > > Please, before beginning to flame me for doing "such kind of non- > standard threading model", I've to say that IMHO it has some merit. > After all it was E.W.Dijkstra who invented it in the late sixties. > glibc already contains such a wrapper; it is called __clone(). At least my system has "man clone" show the man page for it. -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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
l2tpd and kernel support...
This is definitely 2.5 material here since I have exactly 0 lines of code for kernel support at this point, but...wanted to put it on some radar screens. Scott Balmos, David Stipp and myself and begun to do some development work on the l2tpd software that Mark Spencer originally wrote. We've made several major improvements to it at this point and have made great strides in bringing the software up to date with respect to RFC compliance. I'm of the opinion that, eventually l2tpd will need to move some of the L2TP processing into the kernel. Like I said, I don't have even a single line of code written at this point, but I've been doing lot's of reading and learning in preperation for this. I'm starting to do some playing around to get up to speed on kernel module programming and hope to have some code available to do some of this within a fairly short period of time (mostly dependant on how many of those tuits I get). Anyway...I wanted to bring this up to get on some radar screens and see if anyone had any interest in helping this effort out. If you'd like to see where we've gone with the code so far, feel free to check out http://www.sourceforge.net/projects/l2tpd/ -- Jeff McAdamsEmail: [EMAIL PROTECTED] Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services(800) 436-4456 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: nfs performance at high loads
Hello, I had sent in a note on nfs performance issues some time back, and Mark Hemment had been kind enough to point out to the zerocopy networking patch. Well, we tried with it, and it does seem to have some improvement, but it seems to have screwed up nfs performance a bit, because we see a LOT of rpc failures for all kinds of calls, starting from lookup, to read and writes. Could this possibly be triggered by this patch ( picked up from davem's site for 2.4.0 ). On the other hand, we do plan to migrate to 2.4.2. Can somebody update me or provide pointers to info. as to whether we can expect some of these problems have been resolved in 2.4.2? We should soon be testing on 2.4.2 Thanks Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag On Wed, 4 Apr 2001, Mark Hemment ([EMAIL PROTECTED]) wrote: > > I believe David Miller's latest zero-copy patches might help here. > In his patch, the pull-up buffer is now allocated near the top of > stack > (in the sunrpc code), so it can be a blocking allocation. > This doesn't fix the core VM problems, but does relieve the pressure > _slightly_ on the VM (I assume, haven't tried David's patch yet). > > One of the core problems is that the VM keeps no measure of > page fragmentation in the free page pool. The system reaches the state > of > having plenty of free single pages (so kswapd and friends aren't kicked > - or if they are, they do no or little word), and very few buddied pages > (which you need for some of the NFS requests). > > Unfortunately, even with keeping a mesaure of fragmentation, and > insuring work is done when it is reached, doesn't solve the next > problem. > > When a large order request comes in, the inactive_clean page list is > reaped. As reclaim_page() simply selects the "oldest" page it can, with > no regard as to whether it will buddy (now, or 'possibily in the near > future), this list is quickly shrunk by a large order request - far too > quickly for a well behaved system. > > An NFS write request, with an 8K block size, needs an order-2 (16K) > pull > up buffer (we shouldn't really be pulling the header into the same > buffer > as the data - perhaps we aren't any more?). On a well used system, an > order-2 _blocking_ allocation ends up populating the order-0 and order-1 > with quite a few pages from the inactive_clean. > > This then triggers another problem. :( > > As large (non-zero) order requests are always from the NORMAL or DMA > zones, these zones tend to have a lot of free-pages (put there by the > blind reclaim_page() - well, once you can do a blocking allocation they > are, or when the fragmentation kicking is working). > New allocations for pages for the page-cache often ignore the HIGHMEM > zone (it reaches a steady state), and so is passed over by the loop at > the > head of __alloc_pages()). > However, NORMAL and DMA zones tend to be above pages_low (due to the > reason above), and so new page-cache pages came from these zones. On a > HIGHMEM system this leads to thrashing of the NORMAL zone, while the > HIGHMEM zone stays (relatively) quiet. > Note: To make matters even worse under this condition, pulling pages > out > of the NORMAL zone is exactly what you don't want to happen! It would > be > much better if they could be left alone for a (short) while to give them > chance to buddy - Linux (at present) doesn't care about the budding of > pages in the HIGHMEM zone (no non-zero allocations come from there). > > I was working on these problems (and some others) a few months back, > and > will to return to them shortly. Unfortunately, the changes started to > look too large for 2.4 > Also, for NFS, the best solution now might be to give the nfsd threads > a > receive buffer. With David's patches, the pull-up occurs in the context > of a thread, making this possible. > This doesn't solve the problem for other subsystems which do non-zero > order page allocations, but (perhaps) they have a low enough frequency > not > to be of real issue. > > > Kapish, > > Note: Ensure you put a "sync" in your /etc/exports - the default > behaviour was "async" (not legal for a valid SpecFS run). > > Mark > > > On Wed, 4 Apr 2001, Alan Cox wrote: > > > > We have been seeing some problems with running nfs benchmarks > > > at very high loads and were wondering if somebody could show > > > some pointers to where the problem lies. > > > The system is a 2.4.0 kernel on a 6.2 Red at distribution ( so > > > > Use 2.2.19. The 2.4 VM is currently too broken to survive high I/O > benchmark > > tests without going silly > > > > - > > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/l
Re: 2.2.19 Realaudio masq problem
[quoted lines by Whit Blauvelt on April 25, 2001, at 13:38] >On Tue, Apr 24, 2001 at 06:01:05PM -0700, Tim Moore wrote: >> Try '# strace /usr/bin/X11/realplay On24ram.asp > log' and see where the >> connect fails if you aren't getting specific error messages. > >Unfortunately this spits out a bunch of stuff and then totally freezes up my >KDE 2.1.1 desktop. strace writes to standard error, not standard output, by default. Better yet, though, use the -o option of strace to direct its output to a file, which leaves the standard output streams alone for the aplication being traced. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc format (was Device Registry (DevReg) Patch 0.2.0)
On Wednesday 25 April 2001 19:10, you wrote: > The command > more foo/* foo/*/* > will display the values in the foo subtree nicely, I think. Unfortunately it displays only the values. Dumping numbers and strings without knowing their meaning (and probably not even the order) is not very useful. > Better to factor the XML part out to a userspace library... But the one-value per file approach is MORE work. It would be less work to create XML and factor out the directory structure in user-space :) Devreg collects its data from the drivers, each driver should contribute the information that it can provide about the device. Printing a few values in XML format using the functions from xmlprocfs is as easy as writing proc_printf(fragment, "\n", get_portnum(usbdev), usbdev->maxchild); Extending the devreg output with driver-specific data means registering a callback function that prints the driver's data. The driver should use its own XML namespace, so whatever the driver adds will not break any (well-written) user-space applications. The data is created on-demand, so the values can be dynamic and do not waste any space when devreg is not used. The code is easy to read and not larger than a solution that creates static /proc entries, and holding the data completely static would take much more memory. And it takes less code than a solution that would create the values in /proc dynamically because this would mean one callback per file or a complicated way to specify several values with a single callback. bye... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Your response is requested
- Original Message - From: "Dale Amon" <[EMAIL PROTECTED]> To: "J Sloan" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, April 23, 2001 9:12 PM Subject: Re: [OT] Re: Your response is requested > On Tue, Apr 17, 2001 at 12:34:36PM -0700, J Sloan wrote: > > [EMAIL PROTECTED] wrote: > > > > > Dear Friend: > > > > > > YOU CAN make over a half million dollars every 4 to 5 months from > > > your home for a one time investment of only twenty five U.S. > > > Dollars. > > > > This did not originate from toyota.com - The spammer simply > > used that domain as the "from" hostname. We are careful > > about mail server security here, there is no open relay. > > > > Yeah, I saw it to with *MY* domain on it and near had a fit! Well it's kinda easy to protect yourself against this crap... Just look through your mailer for 'dollar' || 'dollars' in the *body* of the message, or more than two exclamation marks in the subject - and you shall find the bastards ;-) 0.02 e andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hundreds of mount --bind mountpoints?
On Wed, 25 Apr 2001, Andreas Dilger wrote: > Al writes: > > It's not a fscking rocket science - encapsulate accesses to ->u.foofs_i > > into inlined function, find ->read_inode, find places that do get_empty_inode > > OK, I was doing this for the ext3 port I'm working on for 2.4, and ran into > a snag. In the ext3_inode_info, there is a list_head. However, if this is > moved into a separate slab struct, it is now impossible to locate the inode > from the offset in the slab struct. When I was checking the size of each > inode_info struct, I noticed several others that had list_heads in them. > One solution is that we store list_heads in the inode proper, after generic_ip. If you need to go from ext3_inode_info to inode - put the pointer into the thing and be done with that. No need to bump ->i_count - fs-private part dies before inode itself. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Single user linux
[EMAIL PROTECTED] wrote: > for those who didn't read that patch, i #define capable(), > suser(), and fsuser() to 1. the implication is all users > will have root capabilities. How is that not single user? I have been doing single-user oriented Linux/GNU/unix longer than anyone I'm aware of with exactly that focus. The one trivial patch I do to the kernel disgusts the core Linux developers for reasons unrelated to single user. cLIeNUX boots with 12 vt's logging in already as root. No kernel molestation. (But stay tuned ;o) Rather than me contributing further to the topic-skew, please have a browse at www.clienux.com Rick Hohensee cLIeNUX user 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: ECN vendor support page
little typo: >From 5. External resources (notice "Congrestion"): Sally Floyd's page on Explicit Congrestion Notification in TCP/IP. http://www.aciri.org/floyd/ecn.html -- Drew Bertola | Send a text message to my pager or cell ... | http://jpager.com/Drew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problem found (was Re: [PATCH] Single user linux)
hi imel, On Tue, 24 Apr 2001 [EMAIL PROTECTED] wrote: > problem is you guys are to unix-centric, try to be user-centric a little. with all respect: the problem is that you do not listen. as people keep trying to point out to you: - you can have your single-user centric user environment (no logon) while - retaining advantages of multi-user security no kernel changes needed. ie: you can have your phone's user environment come straight up (without needing a login or anything) and have security so that the phone user can't do harmful things like delete system files. you can have the best of all worlds... > imel --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 Realaudio masq problem
On Tue, Apr 24, 2001 at 06:01:05PM -0700, Tim Moore wrote: > rtsp://rm.on24.com/media/news/04192001/palumbo_ted6.rm > --stop-- > http://rm.on24.com/media/news/04192001/palumbo_ted6.rm Hmm, the rtsp: fails while the http: works for that one. But then a tcp connection doesn't depend on the realaudio masq module. > Try '# strace /usr/bin/X11/realplay On24ram.asp > log' and see where the > connect fails if you aren't getting specific error messages. Unfortunately this spits out a bunch of stuff and then totally freezes up my KDE 2.1.1 desktop. Probably totally unrelated, but that's what happens - the part of the log that ends up in the frozen display doesn't tell me much, and have to go to shell and kill strace to unfreeze things. Could the problem be that I have realplay 8.0.3.412 on the systems here and they've introduced some bug or incompatibility? Whit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI-Multipath driver for 2.4?
Doug Ledford <[EMAIL PROTECTED]> wrote: > When we reviewed the code, we didn't like it all that much. It served it's > purpose on the t3 stuff from Sun, but it wasn't generic enough to suit our > tastes. True, but the MD layer in 2.2.x (at least as of last June, when I wrote the T3 SCSI-Alias-Chain failover code) was poorly documented, race-prone, and nasty. :^) My _first_ attempt at multipath was with the MD layer, but the 2.2.x code was just way too hairy for it to work by the deadlines Sun had on us. So I went into the SCSI block handling layer. Only one major race I had to avoid, and got the final implementation written in a week. > (for instance, there > are horribly stupid devices out there that support what is called > "Active-Passive" multipath, where if you write to the passive path, it makes > the active path error out, which makes the device 100% useless for > multi-initiator, shared SCSI/FC environments, and makes the device total junk > in my opinion, but if we are going to support them in a Multipath setup, then > the multipath driver has to be modified so it doesn't attempt to touch passive > paths until the active path has already failed, which it doesn't currently > attempt to do when writing superblocks or reading partition tables). Interestingly enough, that is exactly the type of hardware that the SCSI Alias Chains patch is designed to support - the Sun T3, IBM Shark, etc. Nasty, evil critters, but supported. I do wish you the best of luck with the MD layer version, since that's where it should have gone in the first place If the MD layer had been up to snuff. ];^) -- Jason McMullan, Senior Linux Consultant Linuxcare, Inc. 412.432.6457 tel, 412.656.3519 cell [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Putting open source to work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
Followup to: <[EMAIL PROTECTED]> By author:Dan Kegel <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > The only problem with /proc as it stands is that there is no formal > syntax for its entries. Some of them are hard to parse. > /proc/sys is probably the method to follow. Every item is a datum of a simple datatype. -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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 1.2.5 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.2.5: Wed Apr 25 13:55:02 EDT 2001 * Synchronized with 2.4.4-pre6. * Fixed KEY_HOME bug reported by Alex L. Mauer. * Tom Rini's next round of PPC rules patches. * Reference manual updated to reflect gcml implementation experience. Just another point release. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert A. Heinlein, "Time Enough for Love" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Recent ACPI patch
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]] > Stephen Torri wrote: > > > > I noticed that the big update patch for ACPI was a part of > 2.4.3-ac11 (Can > > remember). Now its not a part of 2.4.3-ac12. Has it been > removed? I have > > turned on experimental settings when running make xconfig. > > Alan noted the update did not build, so it was removed. Doh! OK, I'm on it. ;-) BTW did ACPI in ac11 build for you? -- Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Lid support for ACPI
Pavel, We already have lid support in the latest ACPI versions (not in the official kernel yet.) You can download this code from http://developer.intel.com/technology/iapc/acpi/downloads.htm . It'd be great if you could focus your testing and patches on this code base -- I think it's a lot better but it's still a work in progress. Regards -- Andy PS I'm not quite sure why you copied the acpi list *and* lkml.. ;-) > -Original Message- > From: Pavel Machek [mailto:[EMAIL PROTECTED]] > Hi! > > Here's lid support for ACPI, please apply. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NTOP for Redhat
On Wed, Apr 25, 2001 at 10:55:44AM -0400, Ahmed Warsame wrote: > I tried to install my Linux Redhat the Network Monitoring system call Ntop > and the following messages is what I am getting each time I execute make. > > I thought Libpcap is what is needed and I installed but it did not help. Install the development package of libpcap as well. (libpcap-dev on Debian, I guess it must be libpcap-devel or something on RedHat) However, it's not the right forum for these types of questions. This mailing list is about kernel developmenting and related topics. - Gabor -- --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]-[ [EMAIL PROTECTED] ]-- U have 8 bit comp or chip of them and it's unused or to be sold? Call me! ---[ +36 30 2270823 ]--> LGB <-[ Linux/UNIX/8bit 4ever ]- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Registry (DevReg) Patch 0.2.0
Tim Jansen wrote: > On Tuesday 24 April 2001 18:39, Martin Dalecki wrote: > >> Are there alternatives to get complex and extendable information out to > >> user space? > > Yes filesystem structures. > > How exactly can this work? A single value per file is not very helpful if you > have a thousand values. You could cluster them (for example one level in the > XML hierarchy == one file), but this will soon get very complicated. Its much > more work to implement in the kernel, its painful in user-space and you cant > just use a text editor to look at it (because you always have to look at 10 > files per device). The command more foo/* foo/*/* will display the values in the foo subtree nicely, I think. Think of the /proc tree as the XML parse tree already exploded for you. The only problem with /proc as it stands is that there is no formal syntax for its entries. Some of them are hard to parse. Before we add a new /proc entry that generates XML which summarizes the rest of /proc, it might make sense to standardize /proc entries and write a regression test to verify they are formatted correctly. It would then be trivial to write a /proc to XML converter which ran solely in userspace. See http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.0/0506.html and http://marc.theaimsgroup.com/?l=linux-kernel&s=%2Fproc+xml for prior discussion on the matter. I don't want to dismiss the reasons you want to use XML for this, but tread carefully, lest you duplicate lots of code and introduce cruft. Better to factor the XML part out to a userspace library... - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
trident fb?
Hi is there an effort to make trident framebuffer drivers? TIA, Jani. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent ACPI patch
Stephen Torri wrote: > > I noticed that the big update patch for ACPI was a part of 2.4.3-ac11 (Can > remember). Now its not a part of 2.4.3-ac12. Has it been removed? I have > turned on experimental settings when running make xconfig. Alan noted the update did not build, so it was removed. -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Jamie Lokier writes: > Hmm. Perhaps apmd needs a "do not sync" option, for when you don't care. Alternatively, use my pmeventd (previously suspendd) from my pmutils package. You get complete control over all PM events. The daemon sets no policy (unlike apmd). http://www.atnf.csiro.au/~rgooch/linux/ ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/daemons/pmutils.tar.gz Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI-Multipath driver for 2.4?
Christoph Biardzki wrote: > > Hi, > > I wondered whether thera are already effrots to por the Multipath-driver > for FibreChannel (http://t3.linuxcare.org) to the 2.4 kernel? This patch > allows a transparent failover to another path to FC-attached > disk in case the primary path fails. When we reviewed the code, we didn't like it all that much. It served it's purpose on the t3 stuff from Sun, but it wasn't generic enough to suit our tastes. So, Ingo wrote a multipath RAID extension as part of the MD driver and that's in our 7.1 product and will be sent to the mainstream kernel as soon as it's gotten enough testing to be deemed finished (for instance, there are horribly stupid devices out there that support what is called "Active-Passive" multipath, where if you write to the passive path, it makes the active path error out, which makes the device 100% useless for multi-initiator, shared SCSI/FC environments, and makes the device total junk in my opinion, but if we are going to support them in a Multipath setup, then the multipath driver has to be modified so it doesn't attempt to touch passive paths until the active path has already failed, which it doesn't currently attempt to do when writing superblocks or reading partition tables). > Is there any documentation about the changes in the SCSI-driver interfaces > from 2.2 -> 2.4 (eg. in sd.c) ? -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Recent ACPI patch
I noticed that the big update patch for ACPI was a part of 2.4.3-ac11 (Can remember). Now its not a part of 2.4.3-ac12. Has it been removed? I have turned on experimental settings when running make xconfig. Stephen --- Buyer's Guide for a Operating System: Don't care to know: Mac Don't mind knowing but not too much: Windows Hit me! I can take it!: Linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: trident , pci_enable_device moved
Andres Salomon wrote: > This is what I was told (it was only needed for secondary video > devices). From that, I would expect that all video devices would > need it, just in case they happened to be the second card. Am I > missing some subtlety in some of the video driers/chipsets that > wouldn't allow them to be used as a second video device (therefore > not requiring pci_enable_device)? They do need pci_enable_device, both primary and secondary displays. For the primary display its safe to call pci_enable_device. For secondary displays, you have to first disable I/O decoding for all VGA devices before you can enable a secondary display. You don't want more than one device decoding the legacy VGA region at any one time. Some cards have the capability to relocate the VGA region, which is nice. The bigger problem is initializing secondary displays; every video card has a proprietary video BIOS initialization sequence that is run by main BIOS on startup. You can either duplicate this sequence with C code, which is sometimes difficult due to lack of docs or variety of boards, or you can execute the video BIOS with an x86 emulator. -- Jeff Garzik | The difference between America and England is that Building 1024| the English think 100 miles is a long distance and MandrakeSoft | the Americans think 100 years is a long time. | (random fortune) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can't eject cdrom ! (again?!)
Hi all! While burning a cdrom, xcdroast 0.98alpha8 hanged up. After killing it, the cdwriter doesn't respond to any commands and the tray door doesn't open anymore. The cdwriter isn't mounted (df output and cat /proc/mounts). output from eject -v /dev/scd1: eject: device name is `/dev/scd1' eject: expanded name is `/dev/scd1' eject: `/dev/scd1' is not mounted eject: `/dev/scd1' is not a mount point eject: `/dev/scd1' is not a multipartition device eject: trying to eject `/dev/scd1' using CD-ROM eject command eject: CD-ROM eject command failed eject: trying to eject `/dev/scd1' using SCSI commands eject: SCSI eject failed eject: trying to eject `/dev/scd1' using floppy eject command eject: floppy eject command failed eject: trying to eject `/dev/scd1' using tape offline command eject: tape offline command failed eject: unable to eject, last error: Invalid argument vanilla linux 2.2.19 SMP (2x700 Mhz Pentium III Coppermine, 512 MB) SuSE 7.1 distro output from scsi_inquiry /dev/sr1: PLEXTOR CD-R PX-W1210S 1.01, byte_7=0x18 in /var/log/messages: kernel: sr1: CDROM (ioctl) reports ILLEGAL REQUEST. Can I somehow do a scsi reset or anything to be able to use again the cdwriter whitout rebooting? Why did this happen? Thanks, Richard Please CC to my address since I'm not on the linux-kernel list. -- Richard Ems ... e-mail: [EMAIL PROTECTED] ... Computing Science, University of Hamburg Unix IS user friendly. It's just selective about who its friends are. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SMP and USB keyboard
Hi. kernel hackers. I use kernel 2.4.3-ac4 with smp support and I have found strange problem in using usb keyboard. When I pressed CAPS, NUM, SCROLL LOCK key twice (toggle LED light on keyboard), Keyboard and console goes hang. but up(uni-processor) kernel has no problem. I use gcc 2.95.3 glibc 2.2.2 make 3.79.1 binutils 2.10.1 util-linux 2.10q modutils 2.4.2 and used usb-uhci and keybdev modules. anybody have been heard same problems? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Event tools, do they exist
I think all of this has been done... you should check out the Linux Trace Toolkit. george anzinger wrote: > This is an attempt to look in the wheel locker. > > I need a simple event sub system for use in the kernel. I envision at > least two types of events: the history event and the timing event. > > The timing event would keep track of start/stop times by class. If, for > example, I wanted to know how much time the kernel spends doing the > recalc in schedule() I would put and event start in front of it and an > end at the other end. The sub system would note the first event time > and the cumulative time between all starts and stops on the same event. > When reported by /proc/ it would give the total event time, the elapsed > time and the % of processor time for each of the possibly several > classes. > > The history event would record each events time, location, data1, > data2. It would keep N of these (the last N) and report M (M= /proc/. This list should also be kept in a format that a simple > debugger can easily examine. > > Somebody must have written these routines and have them in their > library. Sure would help if I could have a peek. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: trident , pci_enable_device moved
Oops, I saw "trident" and thought video. Sorry, marcus. :) This is what I was told (it was only needed for secondary video devices). From that, I would expect that all video devices would need it, just in case they happened to be the second card. Am I missing some subtlety in some of the video driers/chipsets that wouldn't allow them to be used as a second video device (therefore not requiring pci_enable_device)? On Wed, Apr 25, 2001 at 11:04:55AM -0400, Jeff Garzik wrote: > > Andres Salomon wrote: > > Just a warning; I was informed by Alan that doing this for video > > drivers was unnecessary, since video devices were already enabled > > during bootup. > > To clarify: the primary display device is enabled and initialized, and > its video BIOS executed, when during BIOS startup and before the Linux > kernel gets control. All other display devices are not only not > initialized, but they are disabled as well. > > Marcus is doing sound ATM so I doubt this matters to him... > > -- > Jeff Garzik | The difference between America and England is that > Building 1024| the English think 100 miles is a long distance and > MandrakeSoft | the Americans think 100 years is a long time. > | (random fortune) > -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
