RE: [Criticism] On the discussion about C++ modules
I prefer Peter Salus' wording, myself: The difference between theory and practice is always larger in practice than in theory. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel BUG in vmscan.c in 2.4.0-test10-pre4
System is a 486DX2 66 MHz, 16 MB ram running redhat 7.0 with the latest (Oct 20) patches. The kernel was compiled for it on a faster machine, the only additional patch is the netfilter mss patch. Here are the 2 instances of this bug: Oct 21 15:16:42 morel kernel: kernel BUG at vmscan.c:102! Oct 21 15:16:42 morel kernel: invalid operand: Oct 21 15:16:42 morel kernel: CPU:0 Oct 21 15:16:42 morel kernel: EIP:0010:[try_to_swap_out+268/816] Oct 21 15:16:42 morel kernel: EFLAGS: 00010292 Oct 21 15:16:42 morel kernel: eax: 001c ebx: c0025d18 ecx: edx: Oct 21 15:16:42 morel kernel: esi: 0100 edi: 0001 ebp: 0077c045 esp: c0257eb4 Oct 21 15:16:42 morel kernel: ds: 0018 es: 0018 ss: 0018 Oct 21 15:16:42 morel kernel: Process kswapd (pid: 2, stackpage=c0257000) Oct 21 15:16:42 morel kernel: Stack: c01c4ced c01c4ecc 0066 4003d000 c0277990 40037000 4004 c01eee40 Oct 21 15:16:42 morel kernel:1700 c0126ddb c0277990 c0e6a530 4003c000 c0bbf0f0 0004 40037000 Oct 21 15:16:42 morel kernel:c0e6a530 c0277990 0004 c0bbf0f0 40437000 c0c00400 4004 4004 Oct 21 15:16:42 morel kernel: Call Trace: [tvecs+7069/53520] [tvecs+7548/53520] [swap_out_vma+315/448] [swap_out_mm+60/112] [swap_out+291/384] [refill_inactive+201/368] [do_try_to_free_pages+98/144] Oct 21 15:16:42 morel kernel:[tvecs+7937/53520] [kswapd+129/336] [empty_bad_page+0/4096] [kernel_thread+35/48] Oct 21 15:16:42 morel kernel: Code: 0f 0b 83 c4 0c f7 c5 02 00 00 00 74 17 6a 68 68 cc 4e 1c c0 Oct 21 20:33:01 morel kernel: kernel BUG at vmscan.c:102! Oct 21 20:33:01 morel kernel: invalid operand: Oct 21 20:33:01 morel kernel: CPU:0 Oct 21 20:33:01 morel kernel: EIP:0010:[try_to_swap_out+268/816] Oct 21 20:33:01 morel kernel: EFLAGS: 00010292 Oct 21 20:33:01 morel kernel: eax: 001c ebx: c0022044 ecx: edx: 0004 Oct 21 20:33:01 morel kernel: esi: 5500 edi: 0001 ebp: 00697045 esp: c0257eb4 Oct 21 20:33:01 morel kernel: ds: 0018 es: 0018 ss: 0018 Oct 21 20:33:01 morel kernel: Process kswapd (pid: 2, stackpage=c0257000) Oct 21 20:33:01 morel kernel: Stack: c01c4ced c01c4ecc 0066 4013 c02776c0 4012f000 40135000 c0177570 Oct 21 20:33:01 morel kernel:c010a21f c0126ddb c02776c0 c0275f90 4012f000 c06b14bc 0004 4012f000 Oct 21 20:33:01 morel kernel:c0275f90 c02776c0 0004 c06b14bc 4052f000 c06b3400 40135000 40135000 Oct 21 20:33:01 morel kernel: Call Trace: [tvecs+7069/53520] [tvecs+7548/53520] [read_intr+0/320] [handle_IRQ_event+47/96] [swap_out_vma+315/448] [swap_out_mm+60/112] [swap_out+291/384] Oct 21 20:33:01 morel kernel:[refill_inactive+275/368] [do_try_to_free_pages+98/144] [tvecs+7937/53520] [kswapd+129/336] [empty_bad_page+0/4096] [kernel_thread+35/48] Oct 21 20:33:01 morel kernel: Code: 0f 0b 83 c4 0c f7 c5 02 00 00 00 74 17 6a 68 68 cc 4e 1c c0 Here is the boot up log: Oct 21 19:59:32 morel kernel: Loaded 12026 symbols from /boot/System.map-2.4.0-test10. Oct 21 19:59:32 morel kernel: Symbols match kernel version 2.4.0. Oct 21 19:59:32 morel kernel: Loaded 16 symbols from 2 modules. Oct 21 19:59:32 morel kernel: Linux version 2.4.0-test10 (reimer@harmony) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Sat Oct 21 14:26:35 EDT 2000 Oct 21 19:59:32 morel kernel: BIOS-provided physical RAM map: Oct 21 19:59:32 morel kernel: BIOS-e801: 0009f000 @ (usable) Oct 21 19:59:32 morel kernel: BIOS-e801: 00f0 @ 0010 (usable) Oct 21 19:59:32 morel kernel: On node 0 totalpages: 4096 Oct 21 19:59:32 morel kernel: zone(0): 4096 pages. Oct 21 19:59:32 morel kernel: zone(1): 0 pages. Oct 21 19:59:32 morel kernel: zone(2): 0 pages. Oct 21 19:59:32 morel kernel: Kernel command line: auto BOOT_IMAGE=linuxn ro root=304 BOOT_FILE=/boot/vmlinuz-2.4.0-test10 idebus=33 Oct 21 19:59:32 morel kernel: ide_setup: idebus=33 Oct 21 19:59:32 morel kernel: Initializing CPU#0 Oct 21 19:59:32 morel kernel: Console: colour VGA+ 80x25 Oct 21 19:59:32 morel kernel: Calibrating delay loop... 33.18 BogoMIPS Oct 21 19:59:32 morel kernel: Memory: 14356k/16384k available (943k kernel code, 1640k reserved, 54k data, 168k init, 0k highmem) Oct 21 19:59:32 morel kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok. Oct 21 19:59:32 morel kernel: Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Oct 21 19:59:32 morel kernel: Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Oct 21 19:59:32 morel kernel: Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Oct 21 19:59:32 morel kernel: Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) Oct 21 19:59:32 morel kernel: CPU: Intel 486 DX/2 stepping 05 Oct 21 19:59:32 morel kernel: Checking 'hlt' instruction... OK. Oct 21 19:59:32 morel kernel: POSIX conformance testing by
Re: Which kernel?
Paul King wrote: > > I think I may have found a bug in the kernel, and wish to verify this by > testing this with the "latest" kernel. In order that I make a valid bug > report, which kernel would be considered to be good for testing on? Is it the > latest *stable* version (now 2.2.17, I believe); or is it one of the 2.4.* > test kernels (now 2.4.test9)? Which one would a bug report be taken seriously? All bugs are taken seriously, regardless of whether the kernel is showing up in the stable or development kernel series. Patches specific to the 2.2 series kernel get merged into the stable series code base be Alan Cox. Patches to the development tree get merged by Linus Torvalds. You can raise problems that may be bugs on this mailing list. If it turns out to be a real and significant bug, when the patch is developed, the kernel maintainer will add it to the appropriate kernel source tree. I imagine that the 2.2 series will be maintained for quite a while after 2.4 is released. Though, at some point, the 2.4 kernel series will become the one used by most distributions. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch(?)] question wrt context switching during disk i/o
On Sat, 21 Oct 2000, Mark Hahn wrote:
> > } > bdflush is broken in current kernels. I posted to linux-mm about this,
> > } > but Rik et al haven't shown any interest. I normally see bursts of
> > } > up to around 40K cs/second when doing writes; I hacked a little
> > } > premption counter into the kernel and verified that they're practially
> > } > all bdflush...
> > }
> > There's some strangness in bdflush(). The comment says:
> >
> > /*
> > * If there are still a lot of dirty buffers around,
> > * skip the sleep and flush some more. Otherwise, we
> > * go to sleep waiting a wakeup.
> > */
> > if (!flushed || balance_dirty_state(NODEV) < 0) {
> > run_task_queue(_disk);
> > schedule();
> > }
>
> to me, that says: we haven't succeeded in flushing anything,
> and our balance looks OK, so unplug the disks and sleep. this logic
> must have got accidentally inverted at some point.
>
> I think we want to unplug if we've flushed and are low on memory:
To me, whether we suceeded in flushing something is meaningless.
balance_dirty_state() tells us everything we need to know.. that
we still have too many dirty buffers despite having tried to flush.
We should then unplug to accelerate io completion. I don't see why
bdflush() even calls page_launder().. that calls wakeup_bdflush()
when it hasn't been able to free enough.
Something else that looks strange to me is wakeup_bdflush(1) usage.
In those spots, we add a SCHED_YIELD and schedule() after returning
from wakeup_bdflush().. where we've already scheduled. I moved the
SCHED_YIELD addition into the wakeup_bdflush() blocking portion and
killed the extra schedule, seemingly without doing harm.
> if (flushed && balance_dirty_state(NODEV) >= 0)
>
> > Which leads me to believe that the `<' should be either `==' or `<='. I
> > tried it with the `<=' and it doesn't seem to be so bad...Here's a patch
> > to see if it helps you?
>
> definitely. actually, I think there's some major code rot in the tuning
> logic of the VM. specifically, free_shortage() and inactive_shortage()
> both return an int that tells you how many pages we're short. negative
> returns mean we're not short. but all calls to these functions treat the
> return as a boolean! so for example, the following is wrong:
>
> if (can_get_io_locks && !launder_loop && free_shortage()) {
>
> (vmscan.c:page_launder) should be "free_shortage > 0". there are
> about a dozen other similar places, for which I'll shortly post a patch.
Looking forward to trying your patch.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: cpia_usb cameras
"Dunlap, Randy" wrote: > > > From: John M. Flinchbaugh [mailto:[EMAIL PROTECTED]] > > did something change in the past 2 months to break cpia_usb cameras? > > 2.4.0-test9 (and maybe test8) had some significant changes that broke > several USB drivers, including cpia USB. > > Should be fixed in 2.4.0-test10-pre3. > If not, please report it. > Also, if there's a problem, please test with both of the > uhci host controller drivers. The bug was actually fixed in pre4, at least for usb-uhci. pre3 freezes my kernel with usb-uhci and hangs the driver with uhci. The patch that fixed this is available at http://alpha.dyndns.org/ov511/download/usb-uhci.patch in case you don't want to upgrade the whole kernel. -- Mark McClelland [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: modutils 2.3.19 is available
On Sun, 22 Oct 2000 12:58:32 +1100, Keith Owens <[EMAIL PROTECTED]> wrote: >Everybody using 2.4 kernels needs modutils >= 2.3.15. I recommend that >you upgrade to modutils 2.3.19 for IA64, ISA PNP and USB support. > >ftp://ftp..kernel.org/pub/linux/utils/kernel/modutils/v2.3 > >patch-modutils-2.3.19.bz2 Patch from modutils 2.3.18 to 2.3.19 >modutils-2.3.19.tar.bz2 Source tarball, includes RPM spec file >modutils-2.3.19-1.src.rpm As above, in SRPM format >modutils-2.3.19-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2 For some reason, the above files have not propagated from master.kernel.org to ftp.kernel.org. master was changed recently so there might be problems with the automatic mirroring. Please try again later. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Which kernel?
I think I may have found a bug in the kernel, and wish to verify this by testing this with the "latest" kernel. In order that I make a valid bug report, which kernel would be considered to be good for testing on? Is it the latest *stable* version (now 2.2.17, I believe); or is it one of the 2.4.* test kernels (now 2.4.test9)? Which one would a bug report be taken seriously? Paul King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
HD Benchmark 2.2.17(ide_patch)/2.4.0-test10-pre3 AMD v1.2 ide driver
Greetings all:
I was doing some benchmark between kernels and i came out with
this results, for what I can see, 2.2.17 with the ide_patch is faster,
although it uses more CPU, but then again i could be wrong, any ideas?
-Rodrigo
2.4.0-test10-pre3 FS=ext2 AMD v1.2 (viper) IDE DRIVE
Version 1.00d --Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
Ono-Sendai.lin 248M 6713 98 23372 17 7515 9 6814 94 16644 12 40.4 0
--Sequential Create-- RandomCreate
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
30 256 99 + +++ 8282 100 258 99 + +++ 1005 99
--
2.2.17-ide_patch-reiser_patch FS=ext2
Version 1.00d
--Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
Ono-Sendai.lin 248M 6458 94 23786 19 6662 13 6941 95 17266 11 43.1 0
--Sequential Create-- Random Create
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
30 261 99 636 99 6466 99 259 99 801 100 373 57
--
lspci output:
00:07.1 IDE interface: Advanced Micro Devices [AMD]: Unknown device 7409 (rev 07)
128mb RAM
/dev/hda: (western digital 20gig udma(66))
Model=WDC WD205AA, FwRev=05.05B05, SerialNo=WD-WMA0W1681543
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
CurCHS=16383/16/63, CurSects=16514064, LBA=yes
LBA CHS=1023/256/63 Remapping, LBA=yes, LBAsects=40079088
tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2
IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4
UDMA modes: mode0 mode1 mode2
-
Webmaster of http://www.securityportal.com.ar
[EMAIL PROTECTED]
/"\
\ / ASCII Ribbon Campaign
X Against HTML Mail
/ \
Proud member of http://www.undersec.com
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: getting module symbols into ksyms
On Sat, 21 Oct 2000 10:41:08 -0500, "Jerry Kelley" <[EMAIL PROTECTED]> wrote: >I'm trying to debug the oops that my module is generating. When I use = >ksymoops on the oops text I get a warning saying that the module is in = >lsmod but is not found in ksyms. I have two questions: Please send in plain text instead of quoted printable+HTML, it uses less bandwidth for exactly the same result. Tools, Options, Send, set Mail send for Plain text. You provided zero details about your system, no indication of which kernel, modutils or ksymoops you are running. So the only help that can be provided is to tell you to upgrade to the latest modutils and ksymoops[*] and try again. If you still have a problem, provide details next time. [*] ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.3 ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Announce: modutils 2.3.19 is available
Everybody using 2.4 kernels needs modutils >= 2.3.15. I recommend that you upgrade to modutils 2.3.19 for IA64, ISA PNP and USB support. ftp://ftp..kernel.org/pub/linux/utils/kernel/modutils/v2.3 patch-modutils-2.3.19.bz2 Patch from modutils 2.3.18 to 2.3.19 modutils-2.3.19.tar.bz2 Source tarball, includes RPM spec file modutils-2.3.19-1.src.rpm As above, in SRPM format modutils-2.3.19-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2 Changelog extract * Add insmod -O. * Generate usbmap from MODULE_DEVICE_TABLE(usb). * Move print map before sys_init_module to assist debugging. * Ignore ALLOC attribute for .modinfo. * Correct R_MIPS_26 relocations by Maciej W. Rozycki. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
Eray Ozkural <[EMAIL PROTECTED]> said: > Rik van Riel wrote: > > If C++ really is that good for kernel modules, I'd like to > > see some code that proves it can be done without too much > > of a performance hit (or without a performance hit at all?). > it can be done in theory :) "Theory and practice are the same in theory, but quite different in practice" (or thereabouts) Larry McVoy > > Sending 500 rants to the kernel list isn't even close to > > being productive. Sending 1 patch is... > i already made that point. the only proof that it can > be done is the demonstration of an actual kernel module > without a grave performance hit. Performance is an important point, but by no means to only one. Bloat (source (i.e., wrappers over/around the C API) or binary) is most unwelcome. Screwing up the API for C++'s sake and similar games is right out of the question. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: unfair stress on non memory allocating apps while swapout (in 2.4)
In article <[EMAIL PROTECTED]> you wrote: > I know it does thats why i have run that tool- The question is still, why > gets my system unusable in the same second my systems starts to page out? To follow up on myself: the question was why are programs which do not allocate memory be delayed while one program is eating up all memory. This clearly means they are not delayed in the malloc call but simply the kernel will not schedule them while he is bussy to page out processes. Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testx fr0kedness?
On Sat, 21 Oct 2000, Jason Slagle wrote: > Oooh! > > I'll try this later. Is there any recourse if I have this > problem? ie: Recall or anything? Or should I just nab another > board? Different vender? No recourse. Pig in a POKE, go for it. > I like the BP6 but really don't HAVE to have one since I have 1 IDE device > and that. Has nothing to do with ATA. We are talking about voltage/power loads on the system. If the ripple is large enough, then the clocking signals will be malformed and improper/mis-phased events will happen. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOM Test Case - Failed!
On Sat, 21 Oct 2000, Rik van Riel wrote: > > The oom killer avoided killing your busy, large, root-owned > > process. Don't run gcc compiles as root. Protecting root > > processes is an explicit design goal here. > > Also: > > 1) his system pretty much continued to run > 2) since only httpd children got killed, no work >was lost The system ran, but nothing moved. No process was able to do any activity, because they were all waiting on swapped out space or waiting to use more as-of-yet unallocated virtual memory. I could verify this because one of my daemons writes one line to disk every 5 minutes. That stopped completely during this event. > (only the fact that he ran genattrtab as root screwed > up things a bit and kept the system from killing the > task -- but probably only just) If I would have known, I would have done otherwise. -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: trouble with eepro100+catalyst
Dennis wrote: > > Ciscos and catalysts have all kinds of problems connecting to PCs. >From Documentation/networking/vortex.txt Cisco interoperability note from Walter Wong <[EMAIL PROTECTED]>: On a side note, adding HAS_NWAY seems to share a problem with the Cisco 6509 switch. Specifically, you need to change the spanning tree parameter for the port the machine is plugged into to 'portfast' mode. Otherwise, the negotiation fails. This has been an issue we've noticed for a while but haven't had the time to track down. I'd be interested in getting wider confirmation of this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: An excellent read on CPU caches
Rik van Riel wrote: > > On Tue, 17 Oct 2000, David Ford wrote: > > > http://www.systemlogic.net/articles/00/10/cache/print.php3 > > Linked from http://www.linux.eu.org/Linux-MM/mm-links.html > > (where a bunch of other - maybe relevant - links can be found) > Nice web page. The proceedings from ALS2000 are available at http://www.usenix.org/publications/library/proceedings/als2000/ - lots of good stuff there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: about /proc/meminfo and mmap
Zhixu, On Sat, 21 Oct 2000, Zhixu Liu wrote: > > > > man 2 mlock > > > After I use mlock, how can I know the memory I malloced is in RAM? Thanks. > man 2 mlock DESCRIPTION ... All pages which contain part of the specified memory range are guaranteed be resident in RAM when the mlock system call returns successfully and they are guaranteed to stay in RAM until the pages are unlocked by munlock or munlockall, or until the process terminates or starts another program with exec. ... -- Brian F. G. Bidulock [EMAIL PROTECTED] http://www.openss7.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: about /proc/meminfo and mmap
> man 2 mlock > > On Sat, 21 Oct 2000, Zhixu Liu wrote: > > > > But now, question > > is if I want to reserve some RAM for program use, how can I do? Thanks for > > your help. > > After I use mlock, how can I know the memory I malloced is in RAM? Thanks. Zhixu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testx fr0kedness?
On Sat, 21 Oct 2000, Jason Slagle wrote: > It worked fine under 2.3.x and as a matter of fact worked fine under > 2.4.0-test1-4 I believe. > > I don't buy a hardware explination when I've been running this setup for > well over a year and only just now have problems :) Well let me put some authority into his statement. Pull off your CASE. Enter the BIOS. Wave your hand and fingers over the surface of the mainboard. Watch your voltages move wildly. Now if they are stable and do not change +- 0.01 then you have a stable board. But 95%+ of the people have this problem on the second release of the BP6. FYI, EMF's change with age, as do the effect Z of the LRC circuits. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testx fr0kedness?
Oooh! I'll try this later. Is there any recourse if I have this problem? ie: Recall or anything? Or should I just nab another board? Different vender? I like the BP6 but really don't HAVE to have one since I have 1 IDE device and that. Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - [EMAIL PROTECTED] - [EMAIL PROTECTED] - WHOIS JS10172 -BEGIN GEEK CODE BLOCK- Version: 3.12 GE d-- s:+ a-- C++ UL+++ P--- L+++ E- W- N+ o-- K- w--- O M- V PS+ PE+++ Y+ PGP t+ 5 X+ R tv+ b+ DI+ D G e+ h! r++ y+ --END GEEK CODE BLOCK-- On Sat, 21 Oct 2000, Andre Hedrick wrote: > On Sat, 21 Oct 2000, Jason Slagle wrote: > > > It worked fine under 2.3.x and as a matter of fact worked fine under > > 2.4.0-test1-4 I believe. > > > > I don't buy a hardware explination when I've been running this setup for > > well over a year and only just now have problems :) > > Well let me put some authority into his statement. > > Pull off your CASE. > Enter the BIOS. > Wave your hand and fingers over the surface of the mainboard. > Watch your voltages move wildly. > > Now if they are stable and do not change +- 0.01 then you have a stable > board. But 95%+ of the people have this problem on the second release of > the BP6. > > FYI, EMF's change with age, as do the effect Z of the LRC circuits. > > Cheers, > > Andre Hedrick > The Linux ATA/IDE guy > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testx fr0kedness?
> Anyway, turn off overclokcing and try to reproduce. If this OC'ed report == /dev/null. Nobody will listen. Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testx fr0kedness?
I can try that, although it doesn't seem to hold true that 1) The load average would reflect the sluggishness I'm seeing, and 2) w and ps and that would hang but other programs would continue to run fine. I'll try to get some strace output in a w or something next time it happens. Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - [EMAIL PROTECTED] - [EMAIL PROTECTED] - WHOIS JS10172 -BEGIN GEEK CODE BLOCK- Version: 3.12 GE d-- s:+ a-- C++ UL+++ P--- L+++ E- W- N+ o-- K- w--- O M- V PS+ PE+++ Y+ PGP t+ 5 X+ R tv+ b+ DI+ D G e+ h! r++ y+ --END GEEK CODE BLOCK-- On Sat, 21 Oct 2000, Mitchell Blank Jr wrote: > It's because we've seen it a hundred zillion times before... weird problems > with overclocked systems that the owners claim "work fine under any other > version, so it must be a kernel bug". > > You could well be on the edge of where overclocking breaks down. There's > some sequence of instructions and/or memory access in the kernel that is > causing your particular CPU to croak every billionth time through. Maybe > previous kernel compiles didn't emit those exact instructions and you > lucked out. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testx fr0kedness?
Jason Slagle wrote: > > Howdy! 2.4.0 is looking almost ready except 1 HY00GE problem I'm having. > > I'm SMP here 2 Celeron 300A's at 450 in an Abit BP6. 256M of RAM, all > SCSI. > > System will run for a week no problems. > > Then I compile mozilla and all hell breaks loose. > > Compile will go for a bit then it'll hang and need SAK'd. w and ps and > top will then hang. loadavg is over 4 and I can't paticuraly see whats > causing it. Meminfo looks fine but it's acting like it's outta RAM. I'm > like 37 megs into swap when it happened with over 100 megs of buffer > cache. > > Pretty normal setup here except these: > > echo "1024 2048 4096" > /proc/sys/vm/freepages > echo "5 10 60" > /proc/sys/vm/buffermem > echo "16384" >/proc/sys/fs/file-max > echo "0" >/proc/sys/net/ipv4/tcp_ecn > > These bad? They worked well under 2.2 but who knows under 2.4 > > Please advise, will provide any info I can if needed. > > Jason Hmm... Possibly VM related. Are you using 2.4.0-test9? There are some not so nice things that are fixed in later "test10-preX" (from "testing" subdirectory, pre3 might be the best choice) Even if you are using test10 you could run vmstat 1 and include a typical part. An ALT-SysRq-M (need magic sysrq compiled and enabled) could be useful too. /RogerL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testx fr0kedness?
Jason Slagle wrote: > It worked fine under 2.3.x and as a matter of fact worked fine under > 2.4.0-test1-4 I believe. > > I don't buy a hardware explination when I've been running this setup for > well over a year and only just now have problems :) It's because we've seen it a hundred zillion times before... weird problems with overclocked systems that the owners claim "work fine under any other version, so it must be a kernel bug". You could well be on the edge of where overclocking breaks down. There's some sequence of instructions and/or memory access in the kernel that is causing your particular CPU to croak every billionth time through. Maybe previous kernel compiles didn't emit those exact instructions and you lucked out. Anyway, turn off overclokcing and try to reproduce. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testx fr0kedness?
It worked fine under 2.3.x and as a matter of fact worked fine under 2.4.0-test1-4 I believe. I don't buy a hardware explination when I've been running this setup for well over a year and only just now have problems :) Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - [EMAIL PROTECTED] - [EMAIL PROTECTED] - WHOIS JS10172 -BEGIN GEEK CODE BLOCK- Version: 3.12 GE d-- s:+ a-- C++ UL+++ P--- L+++ E- W- N+ o-- K- w--- O M- V PS+ PE+++ Y+ PGP t+ 5 X+ R tv+ b+ DI+ D G e+ h! r++ y+ --END GEEK CODE BLOCK-- On Sat, 21 Oct 2000, Roeland Th. Jansen wrote: > On Sat, Oct 21, 2000 at 07:37:36PM -0400, Jason Slagle wrote: > > I'm SMP here 2 Celeron 300A's at 450 in an Abit BP6. 256M of RAM, all > > SCSI. > > > > These bad? They worked well under 2.2 but who knows under 2.4 > > > 1) clock the system to specs -- overclocking could kill the stuff > 2) there are batches of BP6's (rev 1.1) that may fail due to an >incorrect capacitor behind some regulator, causing crashes > > > -- > Grobbebol's Home | Don't give in to spammers. -o) > http://www.xs4all.nl/~bengel | Use your real e-mail address /\ > Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-testx fr0kedness?
On Sat, Oct 21, 2000 at 07:37:36PM -0400, Jason Slagle wrote: > I'm SMP here 2 Celeron 300A's at 450 in an Abit BP6. 256M of RAM, all > SCSI. > > These bad? They worked well under 2.2 but who knows under 2.4 1) clock the system to specs -- overclocking could kill the stuff 2) there are batches of BP6's (rev 1.1) that may fail due to an incorrect capacitor behind some regulator, causing crashes -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-testx fr0kedness?
Howdy! 2.4.0 is looking almost ready except 1 HY00GE problem I'm having. I'm SMP here 2 Celeron 300A's at 450 in an Abit BP6. 256M of RAM, all SCSI. System will run for a week no problems. Then I compile mozilla and all hell breaks loose. Compile will go for a bit then it'll hang and need SAK'd. w and ps and top will then hang. loadavg is over 4 and I can't paticuraly see whats causing it. Meminfo looks fine but it's acting like it's outta RAM. I'm like 37 megs into swap when it happened with over 100 megs of buffer cache. Pretty normal setup here except these: echo "1024 2048 4096" > /proc/sys/vm/freepages echo "5 10 60" > /proc/sys/vm/buffermem echo "16384" >/proc/sys/fs/file-max echo "0" >/proc/sys/net/ipv4/tcp_ecn These bad? They worked well under 2.2 but who knows under 2.4 Please advise, will provide any info I can if needed. Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - [EMAIL PROTECTED] - [EMAIL PROTECTED] - WHOIS JS10172 -BEGIN GEEK CODE BLOCK- Version: 3.12 GE d-- s:+ a-- C++ UL+++ P--- L+++ E- W- N+ o-- K- w--- O M- V PS+ PE+++ Y+ PGP t+ 5 X+ R tv+ b+ DI+ D G e+ h! r++ y+ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PPP bug?
This afternoon I saw an anomaly. Merrily typing away (as best one can when downgrading from cable to dialup for a bit) I ran into some lag. Oddly enough what has happened is that the PPP drivers reports a VJ error and stops inbound packet flow. "PPP: VJ decompression error" is the message. After about 8 of these messages all at once tcpdump shows traffic only going out and none inbound, yet the modem indicates a return packet for each outbound ping packet. I had to break the connection and dial up again. Any ideas? -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
Re: [PATCH] x86 PCI detection and documentation
> I still think the code is correct and only the documentation needs to be
> updated (I'll send a patch to Linus as soon as I catch up with my mail queue).
You are right. I missed the place in check_pcibios where you remove the
PCI_PROBE_CONF{1,2}-flags from pci_probe :( My bad. If you would like
to hand off the documentation patch, I'll take another stab (based on
my new insight :) )
> Anyway, have you already tried "pci=conf1" as I've suggested in my previous mail?
Yes. It worked/works very nice. Thanks.
--
Rasmus([EMAIL PROTECTED])
"It's like an Alcatraz around my neck."
-Boston mayor Menino on the shortage of city parking spaces
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 PCI detection and documentation
Hello! > > Some years ago, the PCI routines have really used this strategy > > (and the obsolete help text reflects this situation), but unfortunately, > > there exist machines where the direct access detection gives bogus > > results, so it's much better to ask the BIOS first. Also, it's conceptually > > cleaner to use a well-defined BIOS interface than to probe random > > ports (well, they are random on all non-PCI machines). > > > > These are the reasons why I'd prefer keeping the current code and > > just fixing the documentation. > > AFAICS the current code does not follow this line of thought > completely, as it still probes the hw directly after asking the > BIOS, even though the BIOS might have returned valid data. > > So I propose the following patch (patch 1) that changes the code > to check the BIOS results before probing directly and changes the > documentation to reflect this. It seems you've misunderstood the code (I agree it isn't as straightforward as I would wish, but the whole PCI probing business is a bit fishy anyway). The current probing code doesn't ignore the BIOS check results at all -- the check_pcibios() function looks which direct access methods are said by the BIOS to be supported by the hardware and if there are any, we continue with probing these direct access methods. Only if they fail or the BIOS reports no known direct access methods, we fall back to using the BIOS functions. (There is a couple of good reasons for trying to avoid using BIOS to access the configuration registers -- these functions are slow and sometimes buggy.) I still think the code is correct and only the documentation needs to be updated (I'll send a patch to Linus as soon as I catch up with my mail queue). > If this is rejected for some reason, I include a patch 2 that > merely changes the Documentation/Configure.help to reflect how > the code works currently. Unfortunately, it doesn't :( Anyway, have you already tried "pci=conf1" as I've suggested in my previous mail? Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Linux vs. Windows is a no-WIN situation." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
serial problems
Hi, I use the serial cart with 5.03 / 2.2.17 Serial driver version 5.03 (2000-08-11) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled 00:0d.0 Serial controller: Timedia Technology Co Ltd: Unknown device 7168 (rev 01) I realized it can crash easy a system: run kermit on a ttySX to an another box. when you get the terminal just disconnect the cable and connect it on a another serial port (without any output) now quit kermit: your system should be crashed. another bug (known bug I think) is: if you use a serial cable not connected, your system crashs on the boot. I tested thoses bugs on freebsd. it seems to work on *bsd hope it helps Octave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: unfair stress on non memory allocating apps while swapout (in 2.4)
On Sat, Oct 21, 2000 at 12:22:00PM -0200, Rik van Riel wrote:
> > as the proccess is killed. But still i wonder why the swap out
> > is such unfair to the rest of the system, especially to a
> > process which is not actually allocating memory at all.
>
> Look again ... "tail /dev/zero" allocates INFINITE memory.
>
> (trying to read the last 10 lines of /dev/zero, but the
> device spits out one infinite line ;))
I know it does thats why i have run that tool- The question is still, why
gets my system unusable in the same second my systems starts to page out?
Greetings
Bernd
--
(OO) -- [EMAIL PROTECTED] --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI bookkeeping
Hello! > The problem I'm seeing is that at least one driver > has signed up to handle the wrong IRQ because, > when it queried that PCI config value, it went > back and got it from PCI config space rather > than from the in-kernel data structures where the > (correct) recalculated value had been stored. So, > I'm wondering if our Official Approach is to always > query the in-kernel data structures which have > been setup so nicely for us, or are we supposed > to obtain (some or all of) that sort of info from > PCI space? Or is this all just a bleeding mess? The only correct way to get the IRQ number for a given PCI card is to look to the pci_dev structure. This holds for both 2.2 and 2.4 kernels. (The main reason being that on some architectures the interrupt number doesn't fit in a single byte.) If you know of any drivers reading interrupt line information from the configuration space, please tell us and we'll fix them. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ "Immanuel doesn't pun, he Kant." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Netfilter MAC address filtering in the FORWARD chain
I think the following patch makes MAC address filtering work better in
the FORWARD chain. The problem in the original code is that it uses
skb->len in determining whether or not the packet being filtered has
enough bytes to contain a MAC address, but that field is not necessarily
valid when the filtering code gets called in the FORWARD chain. Using
just skb->head and skb->tail in the bounds checking avoids that problem.
Berend
diff -u linux/net/ipv4/netfilter/ipt_mac.c{.original,}
--- linux/net/ipv4/netfilter/ipt_mac.c.original Sat Oct 21 14:01:33 2000
+++ linux/net/ipv4/netfilter/ipt_mac.c Sat Oct 21 14:03:07 2000
@@ -20,7 +20,7 @@
/* Is mac pointer valid? */
return (skb->mac.raw >= skb->head
- && skb->mac.raw < skb->head + skb->len - ETH_HLEN
+ && skb->mac.raw + ETH_HLEN <= skb->tail
/* If so, compare... */
&& ((memcmp(skb->mac.ethernet->h_source, info->srcaddr,
ETH_ALEN)
== 0) ^ info->invert));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch(?)] question wrt context switching during disk i/o
> } > bdflush is broken in current kernels. I posted to linux-mm about this,
> } > but Rik et al haven't shown any interest. I normally see bursts of
> } > up to around 40K cs/second when doing writes; I hacked a little
> } > premption counter into the kernel and verified that they're practially
> } > all bdflush...
> }
> There's some strangness in bdflush(). The comment says:
>
> /*
> * If there are still a lot of dirty buffers around,
> * skip the sleep and flush some more. Otherwise, we
> * go to sleep waiting a wakeup.
> */
> if (!flushed || balance_dirty_state(NODEV) < 0) {
> run_task_queue(_disk);
> schedule();
> }
to me, that says: we haven't succeeded in flushing anything,
and our balance looks OK, so unplug the disks and sleep. this logic
must have got accidentally inverted at some point.
I think we want to unplug if we've flushed and are low on memory:
if (flushed && balance_dirty_state(NODEV) >= 0)
> Which leads me to believe that the `<' should be either `==' or `<='. I
> tried it with the `<=' and it doesn't seem to be so bad...Here's a patch
> to see if it helps you?
definitely. actually, I think there's some major code rot in the tuning
logic of the VM. specifically, free_shortage() and inactive_shortage()
both return an int that tells you how many pages we're short. negative
returns mean we're not short. but all calls to these functions treat the
return as a boolean! so for example, the following is wrong:
if (can_get_io_locks && !launder_loop && free_shortage()) {
(vmscan.c:page_launder) should be "free_shortage > 0". there are
about a dozen other similar places, for which I'll shortly post a patch.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch(?)] question wrt context switching during disk i/o
On Sat, 21 Oct 2000, Bill Wendling wrote:
> } > bdflush is broken in current kernels. I posted to linux-mm about this,
> } > but Rik et al haven't shown any interest. I normally see bursts of
> } > up to around 40K cs/second when doing writes; I hacked a little
> } > premption counter into the kernel and verified that they're practially
> } > all bdflush...
> }
> There's some strangness in bdflush(). The comment says:
>
> /*
> * If there are still a lot of dirty buffers around,
> * skip the sleep and flush some more. Otherwise, we
> * go to sleep waiting a wakeup.
> */
> if (!flushed || balance_dirty_state(NODEV) < 0) {
> run_task_queue(_disk);
> schedule();
> }
Speaking of bdflush brokenness, I was trying to tune it using
/proc/sys/vm/bdflush. I was trying to eliminate the bursty write behaviour
Linux always seems to have had (exhibited by e.g. find /).
Unfortunately, different /proc/sys/vm/bdflush settings didn't seem to have
much (if any) effect. Is this another case of /proc/sys/vm/* settings
being ignored? If so they should be removed.
I was hoping to get a steady trickle of writes instead of the occasional
mammoth burst.
Cheers
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: reproducable oops with 2.4.0-test9/reiserfs-3.6.17
from the quill of Chris Mason <[EMAIL PROTECTED]> on scroll <1368.972144523@coffee> > > --On 10/15/00 03:19:17 -0700 "Brian J. Murrell" ><[EMAIL PROTECTED]> wrote: > > > During the cpio I get: > > > > kernel BUG at highmem.c:221! > > invalid operand: > > CPU:0 > > EIP:0010:[kunmap_high+28/120] > > Sigh, kunmap works a little better when you send it a page. Try this: Thanks for the response Chris!! Unfortunately, that BUG might have been a red herring. After applying your patch I get very much the same thing still during the cpio. strace of cpio during the copy confirms that it is in "close()" that this bombs. Oct 21 12:53:07 pc kernel: ReiserFS version 3.6.18 Oct 21 12:54:14 pc kernel: Unable to handle kernel NULL pointer dereference at virtual address 0014 Oct 21 12:54:14 pc kernel: printing eip: Oct 21 12:54:14 pc kernel: c0163dcf Oct 21 12:54:14 pc kernel: *pde = Oct 21 12:54:14 pc kernel: Oops: Oct 21 12:54:14 pc kernel: CPU:0 Oct 21 12:54:14 pc kernel: EIP:0010:[create_virtual_node+687/1216] Oct 21 12:54:14 pc kernel: EFLAGS: 00010213 Oct 21 12:54:14 pc kernel: eax: ebx: 000f ecx: c5ab99ec edx: 0ef8 Oct 21 12:54:14 pc kernel: esi: edi: c163704c ebp: c1637000 esp: c5ab9884 Oct 21 12:54:14 pc kernel: ds: 0018 es: 0018 ss: 0018 Oct 21 12:54:14 pc kernel: Process cpio (pid: 819, stackpage=c5ab9000) Oct 21 12:54:14 pc kernel: Stack: c1637000 c163704c 0ef8 0030 c0f02300 0002 Oct 21 12:54:14 pc kernel:c0efc018 c5ab99ec c0f02300 c01654cd c5ab99ec Oct 21 12:54:14 pc kernel:c005b380 c015dbd0 c5ab9df4 c6900600 1ee0 1000da5d 0ef8 Oct 21 12:54:14 pc kernel: Call Trace: [ip_check_balance+877/2912] [do_balance_mark_leaf_dirty+80/112] [journal_mark_dirty+667/688] [fix_nodes+211/1008] [tasklet_hi_action+54/96] [journal_mark_dirty+667/688] [reiserfs_insert_item+137/272] Oct 21 12:54:14 pc kernel:[indirect2direct+569/800] [reiserfs_cut_from_item+246/1056] [is_tree_node+76/112] [reiserfs_do_truncate+822/1136] [reiserfs_truncate_file+180/496] [devfsd_buf_size+8132/39500] [devfsd_buf_size+26735/39500] [reiserfs_file_release+437/816] Oct 21 12:54:14 pc kernel:[reiserfs_file_release+771/816] [devfsd_buf_size+8452/39500] [devfsd_buf_size+26735/39500] [file_read_actor+0/256] [fput+54/208] [filp_close+83/96] [sys_close+67/80] [system_call+51/64] Oct 21 12:54:14 pc kernel: Code: ff 50 14 89 c2 8b 5d 00 01 da 89 55 00 8b 5c 24 38 83 c4 10 Any other ideas? b. -- Brian J. Murrell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DMA and my Maxtor drive
On Sat, 21 Oct 2000, Dennis wrote:
> The same thing happens with big Seagates. It is linux specific. its been a
> problem for a long time.
Really,
It is nice to almost never get reports like this.
>Oct 20 15:39:07 cr753963-a kernel: hdb: timeout waiting for DMA
>Oct 20 15:39:07 cr753963-a kernel: hdb: irq timeout: status=0x6e {
>DriveReady DeviceFault DataRequest CorrectedError Index }
>ide0: reset: success
>Oct 20 15:39:07 cr753963-a kernel: hdb: DMA disabled
>Oct 20 15:39:07 cr753963-a kernel: ide0: reset: success
This is the first time an error of this type as every been reported to me.
Specifically "status=0x6e".
Was for the other OS like M$, if I reset the bus everytime Linux in
countered an error, I could be as slow and clunky as they are.
Second the drive in question is an OLD!
That drive has been out of warrenty for at least 2 years.
So we are talking about a drive that is possiblely 5 years old that is
spec. to live only 3 years. The final doc rev on that drive that I can get
is 3/24/96 rev E.
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: "Tux" is the wrong logo for Linux
On Thu, 19 Oct 2000, KMF AV wrote: > ... obviously the Linux logo should be the > international symbol for the fucking retard. > > http://www.geocities.com/kmfav/ *compares URL and email address* Why would we want to make you the Linux logo? *runs like hell* cheers, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: about /proc/meminfo and mmap
Zhixu, man 2 mlock On Sat, 21 Oct 2000, Zhixu Liu wrote: > > But now, question > is if I want to reserve some RAM for program use, how can I do? Thanks for > your help. > -- Brian F. G. Bidulock [EMAIL PROTECTED] http://www.openss7.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: OOM Test Case - Failed!
On Wed, 18 Oct 2000, Stephen Tweedie wrote: > On Tue, Oct 17, 2000 at 10:02:52AM -0400, Byron Stanoszek wrote: > > > I am very unimpressed with the current OOM killer. After 10 days of online > > time, I decided to try compiling gcc again, the very culprit that killed my > > last system using 2.4.0-test8 Friday night (to which I was unable to reset > > the system until Monday morning). > > > > root 1099 63.6 61.5 71424 18740 pts/0 R09:39 1:22 ./genattrtab > > The oom killer avoided killing your busy, large, root-owned > process. Don't run gcc compiles as root. Protecting root > processes is an explicit design goal here. Also: 1) his system pretty much continued to run 2) since only httpd children got killed, no work was lost (only the fact that he ran genattrtab as root screwed up things a bit and kept the system from killing the task -- but probably only just) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
TCP_DEFER_ACCEPT possible bug + documentation patch for tcp.7
On Sat, Oct 21, 2000 at 08:50:54AM +0200, Andi Kleen wrote: > Linux 2.4 has the "dataready" filter in form of the (currently undocumented) > TCP_DEFER_ACCEPT option. Patch follows beneath. On a related note, I'm not sure if this is right (connecting to a daemon using TCP_DEFER_ACCEPT) # tcpdump -i lo & $ telnet 0 2500 20:46:04.646941 localhost.2030 > localhost.2500: S 2082276900:2082276900(0) win 32280 (DF) [tos 0x10] 20:46:04.647053 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 (DF) 20:46:04.647128 localhost.2030 > localhost.2500: . ack 1 win 32280 (DF) [tos 0x10] Connected to 0. Escape character is '^]'. 20:46:08.442729 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 (DF) 20:46:08.442824 localhost.2030 > localhost.2500: . ack 1 win 32280 (DF) [tos 0x10] 20:46:14.842753 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 (DF) 20:46:14.842858 localhost.2030 > localhost.2500: . ack 1 win 32280 (DF) [tos 0x10] 20:46:27.642750 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 (DF) 20:46:27.642856 localhost.2030 > localhost.2500: . ack 1 win 32280 (DF) [tos 0x1 20:46:51.642733 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 (DF) 20:46:51.642803 localhost.2030 > localhost.2500: . ack 1 win 32280 (DF) [tos 0x10] 20:47:39.642730 localhost.2500 > localhost.2030: S 2083048556:2083048556(0) ack 2082276901 win 32280 (DF) 20:47:39.642805 localhost.2030 > localhost.2500: . ack 1 win 32280 (DF) [tos 0x1 The SYN/ACK handshake appears to go well, and telnet reports a connection (the daemon doesn't, no data has been sent). However, Linux keeps sending SYNs, which keep getting ACKed. I'm not sure if this is desired behavior. It appears to be a side effect of the TCP_DEFER_ACCEPT timeout implementation, which seems to hijack the SYNACK_RESEND timeout. Also, this timeout is not quite the number of seconds specified to setsockopt, because of this. Oh well: the patch diff -c -r old/tcp.7 new/tcp.7 *** old/tcp.7 Sat Oct 21 20:42:10 2000 --- new/tcp.7 Sat Oct 21 20:41:50 2000 *** *** 209,214 --- 209,222 .BR sendfile (2), or for throughput optimization. This option cannot be combined with .BR TCP_NODELAY . + .TP + .B TCP_DEFER_ACCEPT + Instruct the kernel to do connection preprocessing and not to wake the + process until the first packet of real data has arrived. Especially useful + for webservers, which needn't pay attention during the time between completion + of the TCP handshake and the arrival of the first data packet. The integer value + passed is interpreted as the time to wait before the arrival of data before + giving up the connection. .SH IOCTLS These ioctls can be accessed using .BR ioctl (2). -- PowerDNS Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
On Sat, 21 Oct 2000, Eray Ozkural wrote: > Rik van Riel wrote: > > If C++ really is that good for kernel modules, I'd like to > > see some code that proves it can be done without too much > > of a performance hit (or without a performance hit at all?). > > it can be done in theory :) I guess I'll have to quote Larry McVoy here ... "In theory, theory and practice are the same. In practice they are not." > > Sending 500 rants to the kernel list isn't even close to > > being productive. Sending 1 patch is... > > i already made that point. the only proof that it can > be done is the demonstration of an actual kernel module > without a grave performance hit. *nod* If there is anybody around who seriously believes C++ would be a good language for kernel modules, consider this a challange to show us that this is the case. I'm willing to look at code and/or benchmark numbers showing that you people are right, but assertions that nobody backs up with code go into /dev/null pretty quickly... cheers, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: e2fsck hang with test9
On Tue, 17 Oct 2000, Pete Harlan wrote: > e2fsck froze up (waited 10 minutes before rebooting) after checking > 70.0% of a 63Gb scsi partition (41Gb used) under 2.4.0test9. > > This was repeatable. Can you repeat it with 2.4.0-test10-preX ? (I think you're hitting a known - and fixed - bug) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: An excellent read on CPU caches
On Tue, 17 Oct 2000, David Ford wrote: > http://www.systemlogic.net/articles/00/10/cache/print.php3 Linked from http://www.linux.eu.org/Linux-MM/mm-links.html (where a bunch of other - maybe relevant - links can be found) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
Rik van Riel wrote: > If C++ really is that good for kernel modules, I'd like to > see some code that proves it can be done without too much > of a performance hit (or without a performance hit at all?). > it can be done in theory :) > Sending 500 rants to the kernel list isn't even close to > being productive. Sending 1 patch is... > i already made that point. the only proof that it can be done is the demonstration of an actual kernel module without a grave performance hit. many thanks! > regards, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Criticism] On the discussion about C++ modules
On Tue, 17 Oct 2000, Eray Ozkural wrote: > Let it remain C as you like it. I'm just telling that > > * you can't prevent people from writing C++ linux modules as they like > * you are making unfair criticism of C++ language Let me add one more point: * you can't get the C++ advocates to write the stuff they want to see in the kernel themselves If C++ really is that good for kernel modules, I'd like to see some code that proves it can be done without too much of a performance hit (or without a performance hit at all?). Sending 500 rants to the kernel list isn't even close to being productive. Sending 1 patch is... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: want to hire a kernel hacker ...
On Mon, 16 Oct 2000, Don Cohen wrote: > (If there's a better place to post this let me know.) I'd like > some help in modifying linux networking code (IP, firewall, > routing). There are several related projects. They have to > start out proprietary, but I fully expect the resulting code to > become free software before long. You'll /have/ to make the code available to everyone you ship the binaries too, at least you have to do that whenever a piece of code can be reasonably considered "derivative code" from the GPLed code you're modifying ... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre3
On 16 Oct 2000, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:[EMAIL PROTECTED] > In newsgroup: linux.dev.kernel > > > > > but intel refuse to guarantee they wont produce an actual '786' class > > > CPU. > > > > Worry about that if/when it happens ? > > Dare one guess the 786 is actually the Itanic in x86 mode? In that case I guess we won't have to worry about it happening ;) *runs like hell* cheers, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch(?)] question wrt context switching during disk i/o
Also sprach Mike Galbraith:
} On Fri, 20 Oct 2000, Mark Hahn wrote:
}
} > > This is something that has been bugging me for a while. I notice
} > > on my system that during disk write we do much context switching,
} > > but not during disk read. Why is that?
} >
} > bdflush is broken in current kernels. I posted to linux-mm about this,
} > but Rik et al haven't shown any interest. I normally see bursts of
} > up to around 40K cs/second when doing writes; I hacked a little
} > premption counter into the kernel and verified that they're practially
} > all bdflush...
}
There's some strangness in bdflush(). The comment says:
/*
* If there are still a lot of dirty buffers around,
* skip the sleep and flush some more. Otherwise, we
* go to sleep waiting a wakeup.
*/
if (!flushed || balance_dirty_state(NODEV) < 0) {
run_task_queue(_disk);
schedule();
}
but the comment for balance_dirty_state() says:
/* -1 -> no need to flush
0 -> async flush
1 -> sync flush (wait for I/O completation) */
int balance_dirty_state(kdev_t dev)
{
Which leads me to believe that the `<' should be either `==' or `<='. I
tried it with the `<=' and it doesn't seem to be so bad...Here's a patch
to see if it helps you?
--
|| Bill Wendling[EMAIL PROTECTED]
--- linux/fs/buffer.c Sat Oct 21 02:55:41 2000
+++ linux-2.4.0-test10pre4/fs/buffer.c Sat Oct 21 12:27:10 2000
@@ -2683,7 +2683,7 @@
* skip the sleep and flush some more. Otherwise, we
* go to sleep waiting a wakeup.
*/
- if (!flushed || balance_dirty_state(NODEV) < 0) {
+ if (!flushed || balance_dirty_state(NODEV) <= 0) {
run_task_queue(_disk);
schedule();
}
BUG (vmscan.c:102) and possibly VIA IDE timing problems with test10-pre4
Hi, Attached is a tarball with the log of the event, a config used for the kernel and dmesg output for overview of what the machine is. The BUG ocurred while XFree 4 was running, the swap wasn't allocated at all, half of the machine's memory was free. BUG ocurred two times, the second time it wasn't logged entirely as seen from the attached excerpt. Also, the hda/hdb errors seen in dmesg output started ocurring with test10-pre3 AFAIR - when the disk parameters are reset using hdparm to turn DMA off and turn UDMA33 on (mode2 for the hda, mode4 for hdb) everything works just fine. If any more information is required, please let me know. regards, marek bug.tar.gz PGP signature
Re: DMA and my Maxtor drive
At 06:43 PM 10/20/2000, [EMAIL PROTECTED] wrote:
>I get this when DMA is enabled:
>
>Oct 20 15:39:07 cr753963-a kernel: hdb: timeout waiting for DMA
>Oct 20 15:39:07 cr753963-a kernel: hdb: irq timeout: status=0x6e {
>DriveReady DeviceFault DataRequest CorrectedError Index }
>ide0: reset: success
>Oct 20 15:39:07 cr753963-a kernel: hdb: DMA disabled
>Oct 20 15:39:07 cr753963-a kernel: ide0: reset: success
>
>It only happens when there lots of data is being transferred, or compiled
>on the drive.. The drive status is this:
>
>/dev/hdb:
>
> Model=Maxtor 82560A4, FwRev=AA8Z2726, SerialNo=C40LTQGA
> Config={ Fixed }
> RawCHS=4962/16/63, TrkSize=0, SectSize=0, ECCbytes=20
> BuffType=DualPortCache, BuffSize=256kB, MaxMultSect=16, MultSect=off
> CurCHS=4962/16/63, CurSects=5001696, LBA=yes, LBAsects=5001728
> IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 *mdma2
The same thing happens with big Seagates. It is linux specific. its been a
problem for a long time.
the problem doesnt occur with Western Digital drives, whatever it is.
DB
Emerging Technologies, Inc.
-
http://www.etinc.com
ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX
Multiport T1 and HSSI/T3 UNIX-based Routers
Bandwidth Management Standalone Systems
Bandwidth Management software for LINUX and FreeBSD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: trouble with eepro100+catalyst
At 11:06 PM 10/20/2000, [EMAIL PROTECTED] wrote: >We're having lots of trouble with eepro100 and Cisco Catalyst switch, >and my net are a vlan. I am using RedHat 6.2/7.0 and not ping to gateway, >but with o Slackware 7.0 ok. What's the magic? > >Regards, > >Umberto >Systems Analyst >.comDominio >Brazil Ciscos and catalysts have all kinds of problems connecting to PCs. They like to talk to each other mostly. Unfortunately, the widespread propaganda that cisco is flawless hinders the true diagnosis in many cases. get yourself a cheap 10/100 hub or switch and wire it between the units and then go watch some sports instead of banging your head for nothing Sometimes its better to sacrifice performance (ie catalysts) for something that works. Dennis - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
wierd behaviour with hard disks
Hello, System: RedHat 6.2, AMD K6-2 500 Mhz, 64MB SDRAM (100Mhz), 512kb L2 cache. Kernel: 2.2.14-5.0 I am running a utility that reads the entire hard disk sector by sector twice, and compares the two buffers for each read. This is causing wierd behaviour; sometimes I get a segmentation fault, sometimes the system runs the init boot sequence again (if I run the program in runlevel 1, then it automatically starts the system in runlevel 3) !!! Also, I get errors using the 'llseek' and '_llseek' functions; sometimes they work correctly, and otherwise they return errno=22 (EINVAL). (my hard disk is a 2.1 GB Seagate drive, and the errors are returned with lseek offsets that are sometimes just 1 byte from the start of the disk == SEEK_SET !!!) Sometimes, due to heavy memory allocation, the kernel starts killing the system daemons, including the kernel threads, and the system just hangs. (I have a program that starts allocating memory infinitely, 1024 bytes at a time, in a for loop, and it too displays the same behaviour). The code is very simple ... I open the device file, read 512 bytes at a time, and continue to do so till the end of the hard disk is reached. Any ideas ? Thanks, -- Ashutosh S. Rajekar IBM India. http://www.rajekar.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: what is the most efficient wakeup method (signals,msgs,semaphores)?
> I'd like to hear your opinions on the efficiency for the IPC mechanism > betweeen two processes. (from a kernel point of view) Have you read "Unix Network Programming, Volume 2, 2nd edition: IPC" by Richard Stevens? It has measurements for this kind of thing on two OS's, and you can run the tests yourself on your favorite OS; the code is probably at http://www.kohala.com - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
getting module symbols into ksyms
I'm trying to debug the oops that my module is generating. When I use ksymoops on the oops text I get a warning saying that the module is in lsmod but is not found in ksyms. I have two questions: Â 1. How do I get my symbols into ksyms? Â 2. Are only exported symbols in ksyms? Translation: Will I have to export all of my routines in order to effectively debug the module? (I assume that only exported symbols are in ksyms and will build a debug version that exports more routines in the debug version but not in the release version.) Â Thanks. I realize that these are probably very rudimentary questions but I'd rather ask the experts rather than wander around. Â Jerry Kelley [EMAIL PROTECTED] Â
Re: PCI bookkeeping
>> The problem I'm seeing is that at least one driver >> has signed up to handle the wrong IRQ because, >> when it queried that PCI config value, it went >> back and got it from PCI config space rather >> than from the in-kernel data structures where the >> (correct) recalculated value had been stored. So, >> I'm wondering if our Official Approach is to always >> query the in-kernel data structures which have >> been setup so nicely for us, or are we supposed >> to obtain (some or all of) that sort of info from >> PCI space? Or is this all just a bleeding mess? > >Correct. The official way is to quiery kernel data structures >rather than peek directly into PCI config space. Which driver >(in 2.4) do you manipulating irq values from config space? Sorry to mislead you - I only mentioned 2.4.X to note that I observed the same IRQ-transform behavior there, not to say that there was a broken 2.4.X driver. The 2.2.X driver in question is serial.c with patches from MBV to support one of their RAStel multi-modem cards, and it is apparently broken in the manner I described. Thanks for the clarification. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: about /proc/meminfo and mmap
On Sat, 21 Oct 2000, Cefiar wrote: > At 08:24 PM 20/10/00 -0400, Zhixu Liu wrote: > >My PC have 128M RAM, but in /proc/meminfo, it display 122424K, not > >128*1024K = 131072K, what does this mean? > > Sounds like something is stealing your ram. > > Usual suspects are.. > > Shadow RAM is enabled. > - This steals a TINY (usually 64k for BIOS, and 32k each for each extra > memory address enabled) of ram. Nothing major though. > > Local memory accessing devices. > - Embedded video cards (and possibly embedded sound devices) on boards > using the Intel 815E chipset (and others) use local RAM for memory, instead > of their own special memory - to reduce cost. Apart from weird memory > sizes, this also can lead to latency and slow-down issues when accessing > the memory normally. Many of these machines have AGP slots, and almost > always have a PCI slot, so throwing in a cheap video (audio?) card can > remove such issues, and frees up that memory again. Maximum I've seen a > board allow for local video ram is 8 Meg, which is pretty much the amount > you are missing. The board in question was a Socket 7 board with embedded > video. My PC is intel i810 chipset, so perhaps you are right. But now, question is if I want to reserve some RAM for program use, how can I do? Thanks for your help. Zhixu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 12:30:52AM +0100, Alan Cox wrote: > > Assuming that my "compatibility argument" is not considered valid. What > > I really need is some good ammunition for going back to Sun to ask them > > to change the JRE spec -- like some significant kernel features or Linux > > applications that relies on this new bind() behavior. > > The XNS specification seems loose enough to allow the Linux behaviour. I don't I cant see why.. > think we should however adopt it as default behaviour. Programs that dont care > about addresses use INADDR_ANY. IMHO it does _not_ allow Linux behaviour: (Snipped from SUS) NAME bind - bind a name to a socket [...] RETURN VALUE Upon successful completion, bind() returns 0. Otherwise, -1 is returned and errno is set to indicate the error. ERRORS The bind() function will fail if: [...] [EADDRNOTAVAIL] The specified address is not available from the local machine. - So binding to a non-local ip address shouldnt be allowed because it "is not available from the local machine"; even if the machine has a dynamic ip. Alberto Bertogli [EMAIL PROTECTED] PGP signature
Re: about /proc/meminfo and mmap
On Sat, 21 Oct 2000 [EMAIL PROTECTED] wrote: > On Sat, 21 Oct 2000, Cefiar wrote: > > > At 08:24 PM 20/10/00 -0400, Zhixu Liu wrote: > > >My PC have 128M RAM, but in /proc/meminfo, it display 122424K, not > > >128*1024K = 131072K, what does this mean? > > > > Sounds like something is stealing your ram. > > > > Usual suspects are.. > > no, things are a lot simpler than that. /proc/meminfo shows the total > amount of usable memory which obviously can't include the amount reserved ~~~ looking at the code this no longer looks obvious -- does anyone know what is the correct definition of totalram_pages? It would be nice if totalram_pages stood for "total number of RAM pages" but it doesn't seem to... It seems to be a sum of "low" and "high" pages. Does it include kernel text/data/init or not? > by the kernel text and data. Interestingly, it is not quite the same > number as the one shown at boot "Memory: bla/bla...". The one at boot is > nr_free_pages() whilst the one shown in /proc/meminfo is totalram_pages -- > they are different. Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI bookkeeping
Michael O'Donnell wrote: > [...] Later on, various > drivers use code like pcibios_read_config_byte() > to query the IRQ value for use during setup of > their interrupt handlers. Unless there is a very special reason, that's a driver bug. Please define "various drivers" so we can fix them :) > I'm wondering if our Official Approach is to always > query the in-kernel data structures[...]? Correct. Jeff -- Jeff Garzik| The difference between laziness and Building 1024 | prioritization is the end result. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: about /proc/meminfo and mmap
On Sat, 21 Oct 2000, Cefiar wrote: > At 08:24 PM 20/10/00 -0400, Zhixu Liu wrote: > >My PC have 128M RAM, but in /proc/meminfo, it display 122424K, not > >128*1024K = 131072K, what does this mean? > > Sounds like something is stealing your ram. > > Usual suspects are.. no, things are a lot simpler than that. /proc/meminfo shows the total amount of usable memory which obviously can't include the amount reserved by the kernel text and data. Interestingly, it is not quite the same number as the one shown at boot "Memory: bla/bla...". The one at boot is nr_free_pages() whilst the one shown in /proc/meminfo is totalram_pages -- they are different. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
USB problem in 2.2.18pre17
Hi, my digital camera (Kodak DC 280) doesn't work with USB in 2.2.18pre17 (and previos kernels). It did work with 2.4.0-test9. Here's the log: usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.237 $ time 21:44:51 Oct 20 2000 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xa000, IRQ 5 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb.c: USB new device connect, assigned device number 1 usb.c: kmalloc IF c3ea2340, numif 1 usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1 usb.c: USB device number 1 default language ID 0x0 Product: USB UHCI Root Hub SerialNumber: a000 hub.c: USB hub found hub.c: 2 ports detected hub.c: ganged power switching hub.c: standalone hub hub.c: global over-current protection hub.c: power on to power good time: 2ms hub.c: hub controller current requirement: 0mA hub.c: port 1 is removable hub.c: port 2 is removable hub.c: local power source is good hub.c: no over-current condition exists hub.c: enabling power on all ports usb.c: hub driver claimed interface c3ea2340 usb.c: kusbd: /sbin/hotplug add 1 usb.c: kusbd policy returned 0x0 hub.c: port 1 connection change hub.c: portstatus 101, change 1, 12 Mb/s hub.c: portstatus 103, change 0, 12 Mb/s usb.c: USB new device connect, assigned device number 2 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address (error=-110) usb.c: USB new device connect, assigned device number -1 usb.c: registered new driver dc2xx usb_control/bulk_msg: timeout usb.c: USB device not accepting new address (error=-110) usb.c: USB disconnect on device -1 usb.c: device already deleted ?? hub.c: hub: disabling port 1 /proc/interrupts: CPU0 CPU1 0: 60730 61882IO-APIC-edge timer 1: 1 1IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 4: 1587 3138IO-APIC-edge serial 5: 0 0IO-APIC-edge usb-uhci 8: 0 1IO-APIC-edge rtc 12:219269IO-APIC-edge HiSax 13: 1 0 XT-PIC fpu 14: 68127 10671IO-APIC-edge ide0 15: 5 1IO-APIC-edge ide1 16: 3638 3819 IO-APIC-level eth1 19:78975847897362 IO-APIC-level eth0 NMI: 0 ERR: 0 /proc/bus/usb/devices: T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=a000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms /proc/bus/usb/drivers: 80- 95: dc2xx hub usbdevfs The other driver, uhci.o, has the same behavior. Regards, hjb -- http://www.pro-linux.de/ - Germany's largest volunteer Linux support site - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test10-pre3:mkdir() returns -EIO when ext2 filesystem full
Hi,
Something weird is going on with VFS return codes with kernel
2.4.0-test10-pre3:
[root@sturm glibc-2.1.92]# df /var/tmp
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 127383127383 0 100% /var
[root@sturm glibc-2.1.92]# df -i /var/tmp
FilesystemInodes IUsed IFree IUse% Mounted on
/dev/hda3 329122936 299769% /var
[root@sturm glibc-2.1.92]# mkdir /var/tmp/tst
mkdir: cannot create directory `/var/tmp/tst': Input/output error
[root@sturm glibc-2.1.92]#
Just a guess, but I think this is caused by:
dir_block = ext2_bread (inode, 0, 1, );
if (!dir_block) {
inode->i_nlink--; /* is this nlink == 0? */
mark_inode_dirty(inode);
iput (inode);
return -EIO;
}
in fs/ext2/namei.c:ext2_mkdir(). Note that I can't find any cases where
ext2_alloc_block() would actually give a ENOSPC return.
Note (again) the dodgy return error by reference, and then we totally
ignore 'err', so even if ext2_alloc_block() was fixed, it wouldn't
matter unless this and probably other places were also fixed to return
err instead of EIO.
_
|_| - ---+---+-
| | Russell King[EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ - /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: TRACED] Re: "Tux" is the wrong logo for Linux
On Fri, 20 Oct 2000, Ricky Beam wrote: >>the whole county than have computers. Two haven't been booted since > >If that were really true, then the world is in trouble... one of Cisco's >largest offices is here. Nortel has a large footprint as well. > >(You should know better anyway as RedHat's offices are near Cary.) Cary is roughly the size of Chapel Hill, and is approx 10Mi from RH offices, due south of RDU. ;o) -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Looking for Linux software? http://freshmeat.net http://www.rpmfind.net http://filewatcher.org http://www.coldstorage.org http://sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TRACED] Re: "Tux" is the wrong logo for Linux
On Thu, 19 Oct 2000, Alex Buell wrote: >112.437 ms 129.723 ms >12 bar2-loopback.Atlantaald.cw.net (208.172.66.4) 114.681 ms >119.636 ms 118.449 ms >13 interlan-technologies.Atlantaald.cw.net (208.172.72.202) 116.647 >ms 115.374 ms 113.748 ms >14 crs8-gw.cary.ilan.net (216.27.0.1) 110.314 ms 112.902 ms >111.051 ms >15 * * * > >Feel free to send complaints to [EMAIL PROTECTED] and get his account >yanked for abuse of mailing lists. While I disagree with the poster's idiotic posting, and harsh comments, this is free speech, and he has every right to speak freely. A shame he hides from us, but to be removed from a list for such a troll is totalitarian IMHO. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- #[Mike A. Harris bash tip #1 - separate history files per virtual console] # Put the following at the bottom of your ~/.bash_profile [ ! -d ~/.bash_histdir ] && mkdir ~/.bash_histdir tty |grep "^/dev/tty[0-9]" >& /dev/null && \ export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PCI bookkeeping
Is there something (other than the kernel sources) that I can read in order to understand the background to the current state of PCI handling? I'm asking because I (think I) have found an interrupt handling bug that derives from uncoordinated management of PCI config info, but I don't want to proclaim that Linux is broken if the real problem is just a lack of understanding on my part. Here's what I'm tryng to understand: in 2.2.X in pcibios_fixup_devices() [and apparently in pcibios_fixup_irqs() in 2.4.0test8 as well] we run through the list of PCI devices (as represented by the in-kernel data structures) looking in each device structure for its IRQ, if any. We then calculate new IRQ values (suitable for use with the I/O-APIC?) and write those new values back into the corresponding structure. Later on, various drivers use code like pcibios_read_config_byte() to query the IRQ value for use during setup of their interrupt handlers. The problem I'm seeing is that at least one driver has signed up to handle the wrong IRQ because, when it queried that PCI config value, it went back and got it from PCI config space rather than from the in-kernel data structures where the (correct) recalculated value had been stored. So, I'm wondering if our Official Approach is to always query the in-kernel data structures which have been setup so nicely for us, or are we supposed to obtain (some or all of) that sort of info from PCI space? Or is this all just a bleeding mess? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
nm256 audio driver fix
Hello!
attached diff fixes unneeded releases in NeoMagic256 audio driver.
Bye,
Oleg
--- drivers/sound/nm256_audio.c.origSat Oct 21 14:26:47 2000
+++ drivers/sound/nm256_audio.c Sat Oct 21 14:41:20 2000
@@ -58,9 +58,7 @@
for (x = 0; x < 2; x++) {
if (card->port[x].ptr != NULL) {
- u32 size =
- card->port[x].end_offset - card->port[x].start_offset;
- release_region ((unsigned long) card->port[x].ptr, size);
+ iounmap (card->port[x].ptr);
card->port[x].ptr = NULL;
}
}
@@ -1025,7 +1023,7 @@
pointer);
}
-release_region ((unsigned long) temp, 16);
+iounmap (temp);
}
/*
Re: real_root_dev
On Fri, 20 Oct 2000, Andries Brouwer wrote:
> On Thu, Oct 19, 2000 at 09:50:48PM +0200, Geert Uytterhoeven wrote:
> >
> > `real_root_dev' must be `int', not `kdev_t'.
> >
> > - if (MAJOR(real_root_dev) != RAMDISK_MAJOR
> > + if (MAJOR((kdev_t)real_root_dev) != RAMDISK_MAJOR
>
> Ach, Geert, how painful to behold!
>
> Never forget: a kdev_t is a pointer to a structure,
> and MAJOR takes a field of this structure.
> Casting an integer to a structure is ridiculous.
> There are functions to_kdev_t etc to do the conversion
> (and these may involve lookup in a hash table).
Well, that's what the _comments_ in say:
| However, for the time being we let kdev_t be almost the same as dev_t:
|
| typedef struct { unsigned short major, minor; } kdev_t;
But the actual definition is
| typedef unsigned short kdev_t;
Which is incompatible with taking the address of a kdev_t object and assuming
it has the same size as an int, which doesn't equal to any of the `admissible
operations on an object of type kdev_t', as per .
> Please keep the source as much as possible kdev_t clean.
> At some point in time, I hope 2.5.1, we must change,
> and all such cruft would have to be fixed again.
So what do you suggest to fix the bug related to sysctl of real_root_dev?
Just disable it completely?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: question wrt context switching during disk i/o
On Sat, 21 Oct 2000, Mike Galbraith wrote: > On Fri, 20 Oct 2000, Mark Hahn wrote: > > > > This is something that has been bugging me for a while. I notice > > > on my system that during disk write we do much context switching, > > > but not during disk read. Why is that? > > > > bdflush is broken in current kernels. I posted to linux-mm about this, > > but Rik et al haven't shown any interest. I normally see bursts of > > up to around 40K cs/second when doing writes; I hacked a little > > premption counter into the kernel and verified that they're practially > > all bdflush... > > P.S. > > I took a ktrace snapshot of iozone doing 8k writes. This seems like > a strange and expensive way to only unplug a device ;-) Anyone know > why? > > c010a976 system_call +<22/40> (0.16) pid(257) > c0131bc0 sys_write +<10/d8> (0.12) pid(257) > ... > c010a99a ret_from_sys_call +<6/19> (0.20) pid(257) > c0117f7b schedule +<13/404> (2.14) pid(257->5) > c01091a3 __switch_to +<13/cc> (1.16) pid(5) > c01888c6 generic_unplug_device + (0.27) pid(5) > c0117f7b schedule +<13/404> (0.51) pid(5->257) > c01091a3 __switch_to +<13/cc> (0.30) pid(257) > c010a99a ret_from_sys_call +<6/19> (1.20) pid(257) (arg!) P.P.S That was perhaps too brief to be clear exactly what I mean. In a trace segment 263 milliseconds long we switch to kflushd 279 times. 251 of 279 cases are exactly the above. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IDE disk slow? There's help...
Here is what I can acheive using an IBM DeskStar 75 Gig 7200 RPM UDMA 100 (controller only does UDMA 66) using linux-2.4.0-test10-pre3 and 3.6 drivers for my VIA vt82c596b (I believe they are not official yet but were released as a test package by email around October 6th on this email list), here is the output of hdparm -Tt /dev/hda on my machine: 4 root@ledzep /var/log > hdparm -Tt /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 0.91 seconds =140.66 MB/sec Timing buffered disk reads: 64 MB in 2.32 seconds = 27.59 MB/sec 5 root@ledzep /var/log > Which blows away the U/W SCSI hard drive I had in my last machine! Jordan Breeding Michael Kwasigroch wrote: > > Hi, > > I recently bought a 40Gig IBM ATA100 disk as a replacement for a dying 4G > SCSI disk. I knew I was risking some trouble because I have an about 4 year > old triton 2 board (Intel 430HX) and I didn't want to risk more trouble > (and spend more money) by using a proprietary PCI IDE controller board. But > the disk was dead cheap and really big so I bought it and connected it as > the primary master on the onboard controller and... > > Linux (stock 2.2.17) could ony push about 2.6 MB/s "through" it (hdparm -Tt > /dev/hda)... :-( > > The scsi disks can do about 5.5 - 6.1 MB/s (8Bit fast SCSI, no ultra, > adaptec 2940 PCI). > > So I tried to enable IDE DMA, 16 bit data transfers, no use. That was quite > disappointing but I gave up until yesterday when I (again) searched > >http://www.linux-ide.org > > I got the latest 2.2.17 ide-patch, made a new kernel and voila: > > My new IDE disk now "flies" at about 9.2 MB/s and really outperforms the > scsi disks!!! > > ABOUT 3.5 PERFORMANCE GAIN! FOR FREE!!! Unbelievable, but the truth with > free software... > > One thing I don't understand: Why is this patch not in the stock kernel? It > should (positively) affect lots of people, or am I missing something? > > P.S.: Please email me directly, I'm not subscribed to any Linux list. > > PPS: Beware 33+ Gig IDE disks if you have an Award 4.51 BIOS and want to > boot from it. > You will **NOT** be able to boot from disks >33G due to a BIOS bug. > See > http://www.storage.ibm.com/techsup/hddtech/bios338gb.htm > and > http://www.storage.ibm.com/techsup/hddtech/hddfaqs.htm > for details. > > Enjoy. > > Mit freundlichen Gruessen / best regards > > Michael Kwasigroch > FaxPlus/Open Development > > > eMail: [EMAIL PROTECTED] > > INTERCOPE GmbH > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: question wrt context switching during disk i/o
On Fri, 20 Oct 2000, Mark Hahn wrote: > > This is something that has been bugging me for a while. I notice > > on my system that during disk write we do much context switching, > > but not during disk read. Why is that? > > bdflush is broken in current kernels. I posted to linux-mm about this, > but Rik et al haven't shown any interest. I normally see bursts of > up to around 40K cs/second when doing writes; I hacked a little > premption counter into the kernel and verified that they're practially > all bdflush... P.S. I took a ktrace snapshot of iozone doing 8k writes. This seems like a strange and expensive way to only unplug a device ;-) Anyone know why? c010a976 system_call +<22/40> (0.16) pid(257) c0131bc0 sys_write +<10/d8> (0.12) pid(257) ... c010a99a ret_from_sys_call +<6/19> (0.20) pid(257) c0117f7b schedule +<13/404> (2.14) pid(257->5) c01091a3 __switch_to +<13/cc> (1.16) pid(5) c01888c6 generic_unplug_device + (0.27) pid(5) c0117f7b schedule +<13/404> (0.51) pid(5->257) c01091a3 __switch_to +<13/cc> (0.30) pid(257) c010a99a ret_from_sys_call +<6/19> (1.20) pid(257) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anything in Linux similar to FreeBSD accept filter
On Sat, Oct 21, 2000 at 02:10:02PM +0800, ym g wrote: > The release notes for Apache 1.3.14 mention that it has support for FreeBSD's accept >filters [which are in FreeBSD 4.0 onwards]. Reading the man page. I find that this >allows the application to request the kernel to pre-process incoming connections and >it was pioneered by engineers at Yahoo.com. > > According to this URL at the Apache site, > http://httpd.apache.org/docs/misc/perf-bsd44.html#accf > > shows how accept filters improve performance > > Is there anything similar in Linux 2.4 (possibly back-ported to 2.2) Linux 2.4 has the "dataready" filter in form of the (currently undocumented) TCP_DEFER_ACCEPT option. Another option would be to use one of the in kernel http accelerators, e.g. khttpd or tux. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: about /proc/meminfo and mmap
At 08:24 PM 20/10/00 -0400, Zhixu Liu wrote: >My PC have 128M RAM, but in /proc/meminfo, it display 122424K, not >128*1024K = 131072K, what does this mean? Sounds like something is stealing your ram. Usual suspects are.. Shadow RAM is enabled. - This steals a TINY (usually 64k for BIOS, and 32k each for each extra memory address enabled) of ram. Nothing major though. Local memory accessing devices. - Embedded video cards (and possibly embedded sound devices) on boards using the Intel 815E chipset (and others) use local RAM for memory, instead of their own special memory - to reduce cost. Apart from weird memory sizes, this also can lead to latency and slow-down issues when accessing the memory normally. Many of these machines have AGP slots, and almost always have a PCI slot, so throwing in a cheap video (audio?) card can remove such issues, and frees up that memory again. Maximum I've seen a board allow for local video ram is 8 Meg, which is pretty much the amount you are missing. The board in question was a Socket 7 board with embedded video. -- -=[ Stuart Young (Aka Cefiar) ]=--- | http://amarok.glasswings.com.au/ | [EMAIL PROTECTED] | --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: question wrt context switching during disk i/o
On Fri, 20 Oct 2000, Mark Hahn wrote: > > This is something that has been bugging me for a while. I notice > > on my system that during disk write we do much context switching, > > but not during disk read. Why is that? > > bdflush is broken in current kernels. I posted to linux-mm about this, > but Rik et al haven't shown any interest. I normally see bursts of > up to around 40K cs/second when doing writes; I hacked a little > premption counter into the kernel and verified that they're practially > all bdflush... Thanks for the info Mark. My box still isn't really happy with VM in general. It works fine until I use swap.. then it starts grinding pretty badly. Something is still amiss. (I tried and failed to figure out what;) Perhaps this is related. time make bzImage test10-pre4 -j 30 single task real12m41.040s 6m25.163s user6m19.510s 5m58.300s sys 1m28.160s 0m21.360s test1-ac22-class -j 30 single task real7m14.076s 6m24.839s user6m18.740s 5m59.660s sys 0m31.180s 0m21.280s Classzone (beating a dead horse I suppose) consistantly adds under one minute to single process build times versus over six minutes for latest kernel. Swap frenzies like the two below flat don't happen in a classzone build. Neither do extended periods of mostly idle cpu. This shows that this load _can_ be handled smoothly and efficiently. The stock VM chokes on this load.. and IMHO it shouldn't. procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 29 5 1 0 1956 4044 11924 0 051 176 180 222 86 14 0 31 4 1 0 1452 1740 7432 0 0 15692 322 897 85 15 0 23 7 1 18184 1404232 3196 12652 18652 8192 4863 3897 35233 22 77 2 6 25 1 43608 77836300 23136 49352 36844 18683 9271 6405 17727 46 21 33 1 37 0 40616 84384348 26080 4916 0 1333 0 1148 1425 27 3 70 0 54 0 39524 79108364 30852 5528 0 1448 0 672 817 0 1 99 5 35 0 39412 75560388 33240 2280 0 798 0 351 599 0 4 96 0 41 0 39160 70360536 34008 336 0 761 0 220 549 4 20 76 3 48 0 38432 70616540 34608 1264 0 323 0 227 282 2 6 92 1 50 0 37868 66648760 35536 1260 0 464 0 596 790 4 3 93 2 28 0 37864 65816832 35776 0 0 133 0 202 264 3 3 94 4 27 0 37860 63880 1008 36304 0 0 221 0 226 340 25 5 70 26 28 0 37732 5 1120 37148 300 0 403 0 362 538 34 5 61 29 9 0 36844 26040 1176 37788 388 0 513 0 470 940 79 21 0 31 0 0 36828 17332 1200 38184 88 0 112 0 184 281 87 13 0 29 5 0 36100 8740 1212 38056 300 0 173 0 235 482 91 9 0 30 0 0 35420 1940 1220 37348 116 0 276 0 187 328 77 23 0 30 1 0 31424 1460 1224 29584 420 0 129 241 287 531 85 15 0 31 1 0 27088 1460 1232 22292 0 0 115 0 122 378 89 11 0 30 2 0 24916 1464 1232 16296 320 0 112 0 151 412 89 11 0 31 3 0 24664 1952832 11580 428 1776 190 444 224 460 77 23 0 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 30 3 2 50348 1412228 10424 13532 27664 8013 7097 3660 35359 26 66 8 7 15 1 56140 93120248 22380 67536 32272 22272 8143 9132 16245 39 7 53 37 15 0 50168 79500364 29184 6912 0 2649 0 1969 2716 2 3 95 0 13 0 48596 74052676 33028 5136 0 1446 0 2074 2332 1 3 96 2 28 0 48556 72440820 33432 92 0 444 0 218 302 6 3 92 7 32 0 45596 46476892 36980 4780 0 1555 0 1631 2330 9 6 86 28 2 0 45304 40376992 37200 132 0 139 0 226 876 49 11 41 29 2 0 45304 32432 1072 37840 0 0 180 0 248 1154 81 16 4 25 6 0 45300 23664 1116 38004 4 053 0 146 261 90 10 0 31 0 0 45300 15108 1144 38448 0 0 118 0 201 394 93 7 0 31 0 0 45300 7092 1172 38492 0 01882 130 310 96 4 0 29 4 0 43404 1940 1172 36676 0 027 188 177 311 95 5 0 30 0 0 37248 1940 1172 29172 0 010 0 134 337 93 7 0 30 0 0 31344 1460 1172 22668 0 0 0 0 103 341 93 7 0 30 2 0 26044 1460 1172 16188 0 12 0 3 105 258 97 3 0 30 2 1 24220 1944 1124 9772 0 28 0 7 104 246 82 18 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() - Old/Current behaviour - Change?
At 03:02 PM 20/10/00 +0800, Andrey Savochkin wrote: >On Thu, Oct 19, 2000 at 09:52:30PM +1000, Cefiar wrote: >[snip] > > ... what is really necessary, > > which is to simply not allow the programs to bind to the addresses in the > > first place. Unfortunately to implement this sort of thing in god knows > how > > many user space programs looked like too much re-inventing of the wheel. >[snip] > >I think that it's a good idea. >The only question is whether such lists and conditions, and such a big degree >of flexibility belongs to the kernel space. >Isn't it better just to pass almost all bind() calls through a special daemon >for systems which want non-trivial bind policies? I'm happy with that - still produces the required effect and removes bloat from kernel space. Also means it should be easy to revert to default behavior. My original idea was basically a wrapper much like the way chroot works. Being able to lock things in some state that was more appropriate for the program in question. I know that when I set up named/bind on a 2.2 system I set up with a chroot environment, every time an interface changed state, we had to restart named so that it could re-bind to the addresses. Being able to lock the state of those addresses in some way would be brilliant, wether it's the default or not. -- -=[ Stuart Young (Aka Cefiar) ]=--- | http://amarok.glasswings.com.au/ | [EMAIL PROTECTED] | --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Anything in Linux similar to FreeBSD accept filter
The release notes for Apache 1.3.14 mention that it has support for FreeBSD's accept filters [which are in FreeBSD 4.0 onwards]. Reading the man page. I find that this allows the application to request the kernel to pre-process incoming connections and it was pioneered by engineers at Yahoo.com. According to this URL at the Apache site, http://httpd.apache.org/docs/misc/perf-bsd44.html#accf shows how accept filters improve performance Is there anything similar in Linux 2.4 (possibly back-ported to 2.2) Regards /ymg -- ___ Get your free email from http://www.graffiti.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Anything in Linux similar to FreeBSD accept filter
The release notes for Apache 1.3.14 mention that it has support for FreeBSD's accept filters [which are in FreeBSD 4.0 onwards]. Reading the man page. I find that this allows the application to request the kernel to pre-process incoming connections and it was pioneered by engineers at Yahoo.com. According to this URL at the Apache site, http://httpd.apache.org/docs/misc/perf-bsd44.html#accf shows how accept filters improve performance Is there anything similar in Linux 2.4 (possibly back-ported to 2.2) Regards /ymg -- ___ Get your free email from http://www.graffiti.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() - Old/Current behaviour - Change?
At 03:02 PM 20/10/00 +0800, Andrey Savochkin wrote: On Thu, Oct 19, 2000 at 09:52:30PM +1000, Cefiar wrote: [snip] ... what is really necessary, which is to simply not allow the programs to bind to the addresses in the first place. Unfortunately to implement this sort of thing in god knows how many user space programs looked like too much re-inventing of the wheel. [snip] I think that it's a good idea. The only question is whether such lists and conditions, and such a big degree of flexibility belongs to the kernel space. Isn't it better just to pass almost all bind() calls through a special daemon for systems which want non-trivial bind policies? I'm happy with that - still produces the required effect and removes bloat from kernel space. Also means it should be easy to revert to default behavior. My original idea was basically a wrapper much like the way chroot works. Being able to lock things in some state that was more appropriate for the program in question. I know that when I set up named/bind on a 2.2 system I set up with a chroot environment, every time an interface changed state, we had to restart named so that it could re-bind to the addresses. Being able to lock the state of those addresses in some way would be brilliant, wether it's the default or not. -- -=[ Stuart Young (Aka Cefiar) ]=--- | http://amarok.glasswings.com.au/ | [EMAIL PROTECTED] | --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: question wrt context switching during disk i/o
On Fri, 20 Oct 2000, Mark Hahn wrote: This is something that has been bugging me for a while. I notice on my system that during disk write we do much context switching, but not during disk read. Why is that? bdflush is broken in current kernels. I posted to linux-mm about this, but Rik et al haven't shown any interest. I normally see bursts of up to around 40K cs/second when doing writes; I hacked a little premption counter into the kernel and verified that they're practially all bdflush... Thanks for the info Mark. My box still isn't really happy with VM in general. It works fine until I use swap.. then it starts grinding pretty badly. Something is still amiss. (I tried and failed to figure out what;) Perhaps this is related. time make bzImage test10-pre4 -j 30 single task real12m41.040s 6m25.163s user6m19.510s 5m58.300s sys 1m28.160s 0m21.360s test1-ac22-class -j 30 single task real7m14.076s 6m24.839s user6m18.740s 5m59.660s sys 0m31.180s 0m21.280s Classzone (beating a dead horse I suppose) consistantly adds under one minute to single process build times versus over six minutes for latest kernel. Swap frenzies like the two below flat don't happen in a classzone build. Neither do extended periods of mostly idle cpu. This shows that this load _can_ be handled smoothly and efficiently. The stock VM chokes on this load.. and IMHO it shouldn't. procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 29 5 1 0 1956 4044 11924 0 051 176 180 222 86 14 0 31 4 1 0 1452 1740 7432 0 0 15692 322 897 85 15 0 23 7 1 18184 1404232 3196 12652 18652 8192 4863 3897 35233 22 77 2 6 25 1 43608 77836300 23136 49352 36844 18683 9271 6405 17727 46 21 33 1 37 0 40616 84384348 26080 4916 0 1333 0 1148 1425 27 3 70 0 54 0 39524 79108364 30852 5528 0 1448 0 672 817 0 1 99 5 35 0 39412 75560388 33240 2280 0 798 0 351 599 0 4 96 0 41 0 39160 70360536 34008 336 0 761 0 220 549 4 20 76 3 48 0 38432 70616540 34608 1264 0 323 0 227 282 2 6 92 1 50 0 37868 66648760 35536 1260 0 464 0 596 790 4 3 93 2 28 0 37864 65816832 35776 0 0 133 0 202 264 3 3 94 4 27 0 37860 63880 1008 36304 0 0 221 0 226 340 25 5 70 26 28 0 37732 5 1120 37148 300 0 403 0 362 538 34 5 61 29 9 0 36844 26040 1176 37788 388 0 513 0 470 940 79 21 0 31 0 0 36828 17332 1200 38184 88 0 112 0 184 281 87 13 0 29 5 0 36100 8740 1212 38056 300 0 173 0 235 482 91 9 0 30 0 0 35420 1940 1220 37348 116 0 276 0 187 328 77 23 0 30 1 0 31424 1460 1224 29584 420 0 129 241 287 531 85 15 0 31 1 0 27088 1460 1232 22292 0 0 115 0 122 378 89 11 0 30 2 0 24916 1464 1232 16296 320 0 112 0 151 412 89 11 0 31 3 0 24664 1952832 11580 428 1776 190 444 224 460 77 23 0 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 30 3 2 50348 1412228 10424 13532 27664 8013 7097 3660 35359 26 66 8 7 15 1 56140 93120248 22380 67536 32272 22272 8143 9132 16245 39 7 53 37 15 0 50168 79500364 29184 6912 0 2649 0 1969 2716 2 3 95 0 13 0 48596 74052676 33028 5136 0 1446 0 2074 2332 1 3 96 2 28 0 48556 72440820 33432 92 0 444 0 218 302 6 3 92 7 32 0 45596 46476892 36980 4780 0 1555 0 1631 2330 9 6 86 28 2 0 45304 40376992 37200 132 0 139 0 226 876 49 11 41 29 2 0 45304 32432 1072 37840 0 0 180 0 248 1154 81 16 4 25 6 0 45300 23664 1116 38004 4 053 0 146 261 90 10 0 31 0 0 45300 15108 1144 38448 0 0 118 0 201 394 93 7 0 31 0 0 45300 7092 1172 38492 0 01882 130 310 96 4 0 29 4 0 43404 1940 1172 36676 0 027 188 177 311 95 5 0 30 0 0 37248 1940 1172 29172 0 010 0 134 337 93 7 0 30 0 0 31344 1460 1172 22668 0 0 0 0 103 341 93 7 0 30 2 0 26044 1460 1172 16188 0 12 0 3 105 258 97 3 0 30 2 1 24220 1944 1124 9772 0 28 0 7 104 246 82 18 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: about /proc/meminfo and mmap
At 08:24 PM 20/10/00 -0400, Zhixu Liu wrote: My PC have 128M RAM, but in /proc/meminfo, it display 122424K, not 128*1024K = 131072K, what does this mean? Sounds like something is stealing your ram. Usual suspects are.. Shadow RAM is enabled. - This steals a TINY (usually 64k for BIOS, and 32k each for each extra memory address enabled) of ram. Nothing major though. Local memory accessing devices. - Embedded video cards (and possibly embedded sound devices) on boards using the Intel 815E chipset (and others) use local RAM for memory, instead of their own special memory - to reduce cost. Apart from weird memory sizes, this also can lead to latency and slow-down issues when accessing the memory normally. Many of these machines have AGP slots, and almost always have a PCI slot, so throwing in a cheap video (audio?) card can remove such issues, and frees up that memory again. Maximum I've seen a board allow for local video ram is 8 Meg, which is pretty much the amount you are missing. The board in question was a Socket 7 board with embedded video. -- -=[ Stuart Young (Aka Cefiar) ]=--- | http://amarok.glasswings.com.au/ | [EMAIL PROTECTED] | --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anything in Linux similar to FreeBSD accept filter
On Sat, Oct 21, 2000 at 02:10:02PM +0800, ym g wrote: The release notes for Apache 1.3.14 mention that it has support for FreeBSD's accept filters [which are in FreeBSD 4.0 onwards]. Reading the man page. I find that this allows the application to request the kernel to pre-process incoming connections and it was pioneered by engineers at Yahoo.com. According to this URL at the Apache site, http://httpd.apache.org/docs/misc/perf-bsd44.html#accf shows how accept filters improve performance Is there anything similar in Linux 2.4 (possibly back-ported to 2.2) Linux 2.4 has the "dataready" filter in form of the (currently undocumented) TCP_DEFER_ACCEPT option. Another option would be to use one of the in kernel http accelerators, e.g. khttpd or tux. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IDE disk slow? There's help...
Here is what I can acheive using an IBM DeskStar 75 Gig 7200 RPM UDMA 100 (controller only does UDMA 66) using linux-2.4.0-test10-pre3 and 3.6 drivers for my VIA vt82c596b (I believe they are not official yet but were released as a test package by email around October 6th on this email list), here is the output of hdparm -Tt /dev/hda on my machine: 4 root@ledzep /var/log hdparm -Tt /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 0.91 seconds =140.66 MB/sec Timing buffered disk reads: 64 MB in 2.32 seconds = 27.59 MB/sec 5 root@ledzep /var/log Which blows away the U/W SCSI hard drive I had in my last machine! Jordan Breeding Michael Kwasigroch wrote: Hi, I recently bought a 40Gig IBM ATA100 disk as a replacement for a dying 4G SCSI disk. I knew I was risking some trouble because I have an about 4 year old triton 2 board (Intel 430HX) and I didn't want to risk more trouble (and spend more money) by using a proprietary PCI IDE controller board. But the disk was dead cheap and really big so I bought it and connected it as the primary master on the onboard controller and... Linux (stock 2.2.17) could ony push about 2.6 MB/s "through" it (hdparm -Tt /dev/hda)... :-( The scsi disks can do about 5.5 - 6.1 MB/s (8Bit fast SCSI, no ultra, adaptec 2940 PCI). So I tried to enable IDE DMA, 16 bit data transfers, no use. That was quite disappointing but I gave up until yesterday when I (again) searched http://www.linux-ide.org I got the latest 2.2.17 ide-patch, made a new kernel and voila: My new IDE disk now "flies" at about 9.2 MB/s and really outperforms the scsi disks!!! ABOUT 3.5 PERFORMANCE GAIN! FOR FREE!!! Unbelievable, but the truth with free software... One thing I don't understand: Why is this patch not in the stock kernel? It should (positively) affect lots of people, or am I missing something? P.S.: Please email me directly, I'm not subscribed to any Linux list. PPS: Beware 33+ Gig IDE disks if you have an Award 4.51 BIOS and want to boot from it. You will **NOT** be able to boot from disks 33G due to a BIOS bug. See http://www.storage.ibm.com/techsup/hddtech/bios338gb.htm and http://www.storage.ibm.com/techsup/hddtech/hddfaqs.htm for details. Enjoy. Mit freundlichen Gruessen / best regards Michael Kwasigroch FaxPlus/Open Development eMail: [EMAIL PROTECTED] INTERCOPE GmbH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: question wrt context switching during disk i/o
On Sat, 21 Oct 2000, Mike Galbraith wrote: On Fri, 20 Oct 2000, Mark Hahn wrote: This is something that has been bugging me for a while. I notice on my system that during disk write we do much context switching, but not during disk read. Why is that? bdflush is broken in current kernels. I posted to linux-mm about this, but Rik et al haven't shown any interest. I normally see bursts of up to around 40K cs/second when doing writes; I hacked a little premption counter into the kernel and verified that they're practially all bdflush... P.S. I took a ktrace snapshot of iozone doing 8k writes. This seems like a strange and expensive way to only unplug a device ;-) Anyone know why? c010a976 system_call +22/40 (0.16) pid(257) c0131bc0 sys_write +10/d8 (0.12) pid(257) ... c010a99a ret_from_sys_call +6/19 (0.20) pid(257) c0117f7b schedule +13/404 (2.14) pid(257-5) c01091a3 __switch_to +13/cc (1.16) pid(5) c01888c6 generic_unplug_device +e/38 (0.27) pid(5) c0117f7b schedule +13/404 (0.51) pid(5-257) c01091a3 __switch_to +13/cc (0.30) pid(257) c010a99a ret_from_sys_call +6/19 (1.20) pid(257) (arg!) P.P.S That was perhaps too brief to be clear exactly what I mean. In a trace segment 263 milliseconds long we switch to kflushd 279 times. 251 of 279 cases are exactly the above. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: real_root_dev
On Fri, 20 Oct 2000, Andries Brouwer wrote:
On Thu, Oct 19, 2000 at 09:50:48PM +0200, Geert Uytterhoeven wrote:
`real_root_dev' must be `int', not `kdev_t'.
- if (MAJOR(real_root_dev) != RAMDISK_MAJOR
+ if (MAJOR((kdev_t)real_root_dev) != RAMDISK_MAJOR
Ach, Geert, how painful to behold!
Never forget: a kdev_t is a pointer to a structure,
and MAJOR takes a field of this structure.
Casting an integer to a structure is ridiculous.
There are functions to_kdev_t etc to do the conversion
(and these may involve lookup in a hash table).
Well, that's what the _comments_ in linux/kdev_t.h say:
| However, for the time being we let kdev_t be almost the same as dev_t:
|
| typedef struct { unsigned short major, minor; } kdev_t;
But the actual definition is
| typedef unsigned short kdev_t;
Which is incompatible with taking the address of a kdev_t object and assuming
it has the same size as an int, which doesn't equal to any of the `admissible
operations on an object of type kdev_t', as per linux/kdev_t.h.
Please keep the source as much as possible kdev_t clean.
At some point in time, I hope 2.5.1, we must change,
and all such cruft would have to be fixed again.
So what do you suggest to fix the bug related to sysctl of real_root_dev?
Just disable it completely?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
nm256 audio driver fix
Hello!
attached diff fixes unneeded releases in NeoMagic256 audio driver.
Bye,
Oleg
--- drivers/sound/nm256_audio.c.origSat Oct 21 14:26:47 2000
+++ drivers/sound/nm256_audio.c Sat Oct 21 14:41:20 2000
@@ -58,9 +58,7 @@
for (x = 0; x 2; x++) {
if (card-port[x].ptr != NULL) {
- u32 size =
- card-port[x].end_offset - card-port[x].start_offset;
- release_region ((unsigned long) card-port[x].ptr, size);
+ iounmap (card-port[x].ptr);
card-port[x].ptr = NULL;
}
}
@@ -1025,7 +1023,7 @@
pointer);
}
-release_region ((unsigned long) temp, 16);
+iounmap (temp);
}
/*
PCI bookkeeping
Is there something (other than the kernel sources) that I can read in order to understand the background to the current state of PCI handling? I'm asking because I (think I) have found an interrupt handling bug that derives from uncoordinated management of PCI config info, but I don't want to proclaim that Linux is broken if the real problem is just a lack of understanding on my part. Here's what I'm tryng to understand: in 2.2.X in pcibios_fixup_devices() [and apparently in pcibios_fixup_irqs() in 2.4.0test8 as well] we run through the list of PCI devices (as represented by the in-kernel data structures) looking in each device structure for its IRQ, if any. We then calculate new IRQ values (suitable for use with the I/O-APIC?) and write those new values back into the corresponding structure. Later on, various drivers use code like pcibios_read_config_byte() to query the IRQ value for use during setup of their interrupt handlers. The problem I'm seeing is that at least one driver has signed up to handle the wrong IRQ because, when it queried that PCI config value, it went back and got it from PCI config space rather than from the in-kernel data structures where the (correct) recalculated value had been stored. So, I'm wondering if our Official Approach is to always query the in-kernel data structures which have been setup so nicely for us, or are we supposed to obtain (some or all of) that sort of info from PCI space? Or is this all just a bleeding mess? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TRACED] Re: Tux is the wrong logo for Linux
On Thu, 19 Oct 2000, Alex Buell wrote: 112.437 ms 129.723 ms 12 bar2-loopback.Atlantaald.cw.net (208.172.66.4) 114.681 ms 119.636 ms 118.449 ms 13 interlan-technologies.Atlantaald.cw.net (208.172.72.202) 116.647 ms 115.374 ms 113.748 ms 14 crs8-gw.cary.ilan.net (216.27.0.1) 110.314 ms 112.902 ms 111.051 ms 15 * * * Feel free to send complaints to [EMAIL PROTECTED] and get his account yanked for abuse of mailing lists. While I disagree with the poster's idiotic posting, and harsh comments, this is free speech, and he has every right to speak freely. A shame he hides from us, but to be removed from a list for such a troll is totalitarian IMHO. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- #[Mike A. Harris bash tip #1 - separate history files per virtual console] # Put the following at the bottom of your ~/.bash_profile [ ! -d ~/.bash_histdir ] mkdir ~/.bash_histdir tty |grep "^/dev/tty[0-9]" /dev/null \ export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: TRACED] Re: Tux is the wrong logo for Linux
On Fri, 20 Oct 2000, Ricky Beam wrote: the whole county than have computers. Two haven't been booted since If that were really true, then the world is in trouble... one of Cisco's largest offices is here. Nortel has a large footprint as well. (You should know better anyway as RedHat's offices are near Cary.) Cary is roughly the size of Chapel Hill, and is approx 10Mi from RH offices, due south of RDU. ;o) -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Looking for Linux software? http://freshmeat.net http://www.rpmfind.net http://filewatcher.org http://www.coldstorage.org http://sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
USB problem in 2.2.18pre17
Hi, my digital camera (Kodak DC 280) doesn't work with USB in 2.2.18pre17 (and previos kernels). It did work with 2.4.0-test9. Here's the log: usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.237 $ time 21:44:51 Oct 20 2000 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xa000, IRQ 5 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb.c: USB new device connect, assigned device number 1 usb.c: kmalloc IF c3ea2340, numif 1 usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1 usb.c: USB device number 1 default language ID 0x0 Product: USB UHCI Root Hub SerialNumber: a000 hub.c: USB hub found hub.c: 2 ports detected hub.c: ganged power switching hub.c: standalone hub hub.c: global over-current protection hub.c: power on to power good time: 2ms hub.c: hub controller current requirement: 0mA hub.c: port 1 is removable hub.c: port 2 is removable hub.c: local power source is good hub.c: no over-current condition exists hub.c: enabling power on all ports usb.c: hub driver claimed interface c3ea2340 usb.c: kusbd: /sbin/hotplug add 1 usb.c: kusbd policy returned 0x0 hub.c: port 1 connection change hub.c: portstatus 101, change 1, 12 Mb/s hub.c: portstatus 103, change 0, 12 Mb/s usb.c: USB new device connect, assigned device number 2 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address (error=-110) usb.c: USB new device connect, assigned device number -1 usb.c: registered new driver dc2xx usb_control/bulk_msg: timeout usb.c: USB device not accepting new address (error=-110) usb.c: USB disconnect on device -1 usb.c: device already deleted ?? hub.c: hub: disabling port 1 /proc/interrupts: CPU0 CPU1 0: 60730 61882IO-APIC-edge timer 1: 1 1IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 4: 1587 3138IO-APIC-edge serial 5: 0 0IO-APIC-edge usb-uhci 8: 0 1IO-APIC-edge rtc 12:219269IO-APIC-edge HiSax 13: 1 0 XT-PIC fpu 14: 68127 10671IO-APIC-edge ide0 15: 5 1IO-APIC-edge ide1 16: 3638 3819 IO-APIC-level eth1 19:78975847897362 IO-APIC-level eth0 NMI: 0 ERR: 0 /proc/bus/usb/devices: T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=a000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms /proc/bus/usb/drivers: 80- 95: dc2xx hub usbdevfs The other driver, uhci.o, has the same behavior. Regards, hjb -- http://www.pro-linux.de/ - Germany's largest volunteer Linux support site - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: about /proc/meminfo and mmap
On Sat, 21 Oct 2000, Cefiar wrote: At 08:24 PM 20/10/00 -0400, Zhixu Liu wrote: My PC have 128M RAM, but in /proc/meminfo, it display 122424K, not 128*1024K = 131072K, what does this mean? Sounds like something is stealing your ram. Usual suspects are.. no, things are a lot simpler than that. /proc/meminfo shows the total amount of usable memory which obviously can't include the amount reserved by the kernel text and data. Interestingly, it is not quite the same number as the one shown at boot "Memory: bla/bla...". The one at boot is nr_free_pages() whilst the one shown in /proc/meminfo is totalram_pages -- they are different. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI bookkeeping
Michael O'Donnell wrote: [...] Later on, various drivers use code like pcibios_read_config_byte() to query the IRQ value for use during setup of their interrupt handlers. Unless there is a very special reason, that's a driver bug. Please define "various drivers" so we can fix them :) I'm wondering if our Official Approach is to always query the in-kernel data structures[...]? Correct. Jeff -- Jeff Garzik| The difference between laziness and Building 1024 | prioritization is the end result. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bind() allowed to non-local addresses
On Thu, Oct 19, 2000 at 12:30:52AM +0100, Alan Cox wrote: Assuming that my "compatibility argument" is not considered valid. What I really need is some good ammunition for going back to Sun to ask them to change the JRE spec -- like some significant kernel features or Linux applications that relies on this new bind() behavior. The XNS specification seems loose enough to allow the Linux behaviour. I don't I cant see why.. think we should however adopt it as default behaviour. Programs that dont care about addresses use INADDR_ANY. IMHO it does _not_ allow Linux behaviour: (Snipped from SUS) NAME bind - bind a name to a socket [...] RETURN VALUE Upon successful completion, bind() returns 0. Otherwise, -1 is returned and errno is set to indicate the error. ERRORS The bind() function will fail if: [...] [EADDRNOTAVAIL] The specified address is not available from the local machine. - So binding to a non-local ip address shouldnt be allowed because it "is not available from the local machine"; even if the machine has a dynamic ip. Alberto Bertogli [EMAIL PROTECTED] PGP signature
Re: about /proc/meminfo and mmap
On Sat, 21 Oct 2000, Cefiar wrote: At 08:24 PM 20/10/00 -0400, Zhixu Liu wrote: My PC have 128M RAM, but in /proc/meminfo, it display 122424K, not 128*1024K = 131072K, what does this mean? Sounds like something is stealing your ram. Usual suspects are.. Shadow RAM is enabled. - This steals a TINY (usually 64k for BIOS, and 32k each for each extra memory address enabled) of ram. Nothing major though. Local memory accessing devices. - Embedded video cards (and possibly embedded sound devices) on boards using the Intel 815E chipset (and others) use local RAM for memory, instead of their own special memory - to reduce cost. Apart from weird memory sizes, this also can lead to latency and slow-down issues when accessing the memory normally. Many of these machines have AGP slots, and almost always have a PCI slot, so throwing in a cheap video (audio?) card can remove such issues, and frees up that memory again. Maximum I've seen a board allow for local video ram is 8 Meg, which is pretty much the amount you are missing. The board in question was a Socket 7 board with embedded video. My PC is intel i810 chipset, so perhaps you are right. But now, question is if I want to reserve some RAM for program use, how can I do? Thanks for your help. Zhixu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI bookkeeping
The problem I'm seeing is that at least one driver has signed up to handle the wrong IRQ because, when it queried that PCI config value, it went back and got it from PCI config space rather than from the in-kernel data structures where the (correct) recalculated value had been stored. So, I'm wondering if our Official Approach is to always query the in-kernel data structures which have been setup so nicely for us, or are we supposed to obtain (some or all of) that sort of info from PCI space? Or is this all just a bleeding mess? Correct. The official way is to quiery kernel data structures rather than peek directly into PCI config space. Which driver (in 2.4) do you manipulating irq values from config space? Sorry to mislead you - I only mentioned 2.4.X to note that I observed the same IRQ-transform behavior there, not to say that there was a broken 2.4.X driver. The 2.2.X driver in question is serial.c with patches from MBV to support one of their RAStel multi-modem cards, and it is apparently broken in the manner I described. Thanks for the clarification. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
getting module symbols into ksyms
I'm trying to debug the oops that my module is generating. When I use ksymoops on the oops text I get a warning saying that the module is in lsmod but is not found in ksyms. I have two questions: 1. How do I get my symbols into ksyms? 2. Are only exported symbols in ksyms? Translation: Will I have to export all of my routines in order to effectively debug the module? (I assume that only exported symbols are in ksyms and will build a debug version that exports more routines in the debug version but not in the release version.) Thanks. I realize that these are probably very rudimentary questions but I'd rather ask the experts rather than wander around. Jerry Kelley [EMAIL PROTECTED]
wierd behaviour with hard disks
Hello, System: RedHat 6.2, AMD K6-2 500 Mhz, 64MB SDRAM (100Mhz), 512kb L2 cache. Kernel: 2.2.14-5.0 I am running a utility that reads the entire hard disk sector by sector twice, and compares the two buffers for each read. This is causing wierd behaviour; sometimes I get a segmentation fault, sometimes the system runs the init boot sequence again (if I run the program in runlevel 1, then it automatically starts the system in runlevel 3) !!! Also, I get errors using the 'llseek' and '_llseek' functions; sometimes they work correctly, and otherwise they return errno=22 (EINVAL). (my hard disk is a 2.1 GB Seagate drive, and the errors are returned with lseek offsets that are sometimes just 1 byte from the start of the disk == SEEK_SET !!!) Sometimes, due to heavy memory allocation, the kernel starts killing the system daemons, including the kernel threads, and the system just hangs. (I have a program that starts allocating memory infinitely, 1024 bytes at a time, in a for loop, and it too displays the same behaviour). The code is very simple ... I open the device file, read 512 bytes at a time, and continue to do so till the end of the hard disk is reached. Any ideas ? Thanks, -- Ashutosh S. Rajekar IBM India. http://www.rajekar.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DMA and my Maxtor drive
At 06:43 PM 10/20/2000, [EMAIL PROTECTED] wrote:
I get this when DMA is enabled:
Oct 20 15:39:07 cr753963-a kernel: hdb: timeout waiting for DMA
Oct 20 15:39:07 cr753963-a kernel: hdb: irq timeout: status=0x6e {
DriveReady DeviceFault DataRequest CorrectedError Index }
ide0: reset: success
Oct 20 15:39:07 cr753963-a kernel: hdb: DMA disabled
Oct 20 15:39:07 cr753963-a kernel: ide0: reset: success
It only happens when there lots of data is being transferred, or compiled
on the drive.. The drive status is this:
/dev/hdb:
Model=Maxtor 82560A4, FwRev=AA8Z2726, SerialNo=C40LTQGA
Config={ Fixed }
RawCHS=4962/16/63, TrkSize=0, SectSize=0, ECCbytes=20
BuffType=DualPortCache, BuffSize=256kB, MaxMultSect=16, MultSect=off
CurCHS=4962/16/63, CurSects=5001696, LBA=yes, LBAsects=5001728
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2
The same thing happens with big Seagates. It is linux specific. its been a
problem for a long time.
the problem doesnt occur with Western Digital drives, whatever it is.
DB
Emerging Technologies, Inc.
-
http://www.etinc.com
ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX
Multiport T1 and HSSI/T3 UNIX-based Routers
Bandwidth Management Standalone Systems
Bandwidth Management software for LINUX and FreeBSD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
BUG (vmscan.c:102) and possibly VIA IDE timing problems with test10-pre4
Hi, Attached is a tarball with the log of the event, a config used for the kernel and dmesg output for overview of what the machine is. The BUG ocurred while XFree 4 was running, the swap wasn't allocated at all, half of the machine's memory was free. BUG ocurred two times, the second time it wasn't logged entirely as seen from the attached excerpt. Also, the hda/hdb errors seen in dmesg output started ocurring with test10-pre3 AFAIR - when the disk parameters are reset using hdparm to turn DMA off and turn UDMA33 on (mode2 for the hda, mode4 for hdb) everything works just fine. If any more information is required, please let me know. regards, marek bug.tar.gz PGP signature
[patch(?)] question wrt context switching during disk i/o
Also sprach Mike Galbraith:
} On Fri, 20 Oct 2000, Mark Hahn wrote:
}
} This is something that has been bugging me for a while. I notice
} on my system that during disk write we do much context switching,
} but not during disk read. Why is that?
}
} bdflush is broken in current kernels. I posted to linux-mm about this,
} but Rik et al haven't shown any interest. I normally see bursts of
} up to around 40K cs/second when doing writes; I hacked a little
} premption counter into the kernel and verified that they're practially
} all bdflush...
}
There's some strangness in bdflush(). The comment says:
/*
* If there are still a lot of dirty buffers around,
* skip the sleep and flush some more. Otherwise, we
* go to sleep waiting a wakeup.
*/
if (!flushed || balance_dirty_state(NODEV) 0) {
run_task_queue(tq_disk);
schedule();
}
but the comment for balance_dirty_state() says:
/* -1 - no need to flush
0 - async flush
1 - sync flush (wait for I/O completation) */
int balance_dirty_state(kdev_t dev)
{
Which leads me to believe that the `' should be either `==' or `='. I
tried it with the `=' and it doesn't seem to be so bad...Here's a patch
to see if it helps you?
--
|| Bill Wendling[EMAIL PROTECTED]
--- linux/fs/buffer.c Sat Oct 21 02:55:41 2000
+++ linux-2.4.0-test10pre4/fs/buffer.c Sat Oct 21 12:27:10 2000
@@ -2683,7 +2683,7 @@
* skip the sleep and flush some more. Otherwise, we
* go to sleep waiting a wakeup.
*/
- if (!flushed || balance_dirty_state(NODEV) 0) {
+ if (!flushed || balance_dirty_state(NODEV) = 0) {
run_task_queue(tq_disk);
schedule();
}
