Re: [ANOMALIES]: 2.4.2 - __alloc_pages: failed - Patch failed
The way sg_low_malloc() tries to allocate, failure messages are pretty much garanteed. It tries high order allocations (which are unreliable even when not stressed) and backs off until it succeeds. In other words, the messages are a red herring. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 242-ac3 loop bug
Halleluiah ;)!!!
Finally, it works as is suposed to do :, the load on my dual
PIIIx950 is 0.01 three times and I can mount and umonunt ISOs as much I
wish.
Thank you very much Jens and all that provided usefull feedback, this
patch alone deserves including in an .acX release.
And Jens if you ever come to Romania give me a call I owe you a lot of
beers and pizzas :).
Mircea "happy, happy, joy, joy...;)" C.
Jens Axboe wrote:
>
> On Sat, Feb 24 2001, Mark Swanson wrote:
> > First, good job on the loop device. It's rock stable for me - except
>
> thanks, glad to hear it.
>
> > when I try to load the blowfish module which oops the kernel and
> > crashes the loop device:-) No problem, I just use another cipher.
>
> cipher bug or? never the less, could you ksymoops that and send
> it along?
>
> > The bug I'm reporting is that when a loop device is in use the load of
> > the machine stays at 1.00 even though nothing is happening. If I umount
> > the loop filesystem the load goes down to 0.00.
> >
> > > ps -aux | grep loop
> > 1674 tty1 DW< 0:00 [loop0]
> >
> > The system is doing nothing to the loop filesystem.
> > Strange that the process isn't logging any cpu usage time. It's
> > definately responsible for the 1.00 load.
>
> Oops, this slipped by me. Patch should fix it.
>
> --
> Jens Axboe
>
>
> --- drivers/block/loop.c~ Sat Feb 24 23:08:38 2001
> +++ drivers/block/loop.cSat Feb 24 23:11:13 2001
> @@ -507,7 +507,7 @@
> sprintf(current->comm, "loop%d", lo->lo_number);
>
> spin_lock_irq(¤t->sigmask_lock);
> - siginitsetinv(¤t->blocked, sigmask(SIGKILL));
> + sigfillset(¤t->blocked);
> flush_signals(current);
> spin_unlock_irq(¤t->sigmask_lock);
>
> @@ -525,7 +525,7 @@
> up(&lo->lo_sem);
>
> for (;;) {
> - down(&lo->lo_bh_mutex);
> + down_interruptible(&lo->lo_bh_mutex);
> if (!atomic_read(&lo->lo_pending))
> break;
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: 2.2.18: weird eepro100 msgs
I've been seeing the same kind of messages with an eepro100 but they don't happen when the module is loaded. They happen after it has been running for a few days. I am running 2.4.1. I haven't seen any real problems but these messages still scare me. Micah > > On Fri, 2 Feb 2001, Ivan Passos wrote: > > > > On Fri, 2 Feb 2001, Ion Badulescu wrote: > > > > > On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos <[EMAIL PROTECTED]> wrote: > > > > > > > Sometimes when I reboot the system, as soon as the eepro100 module is > > > > loaded, I start to get these msgs on the screen: > > > > > > > > eth0: card reports no resources. > > > > eth0: card reports no RX buffers. > > > > eth0: card reports no resources. > > > > eth0: card reports no RX buffers. > > > > eth0: card reports no resources. > > > > eth0: card reports no RX buffers. > > > > (...) > > > > > > Does the following patch, taken from 2.4.1, help? > > > > I'm currently testing. I'll get back to you soon (have to reboot the > > system a lot to make sure it's really solved ... :)). > > Yes, the patch did solve the problem. > > Alan, could you please include this patch on your 2.2.19pre series (if > it's not already included)?? > > Ion, thanks again for your help!! > > Later, > Ivan > > --- linux-2.2.18/drivers/net/eepro100-old.c Fri Feb 2 15:30:23 2001 > +++ linux-2.2.18/drivers/net/eepro100.c Fri Feb 2 15:33:19 2001 > @@ -751,6 +751,7 @@ > This takes less than 10usec and will easily finish before the next > action. */ > outl(PortReset, ioaddr + SCBPort); > + inl(ioaddr + SCBPort); > /* Honor PortReset timing. */ > udelay(10); > > @@ -839,6 +840,7 @@ > #endif /* kernel_bloat */ > > outl(PortReset, ioaddr + SCBPort); > + inl(ioaddr + SCBPort); > /* Honor PortReset timing. */ > udelay(10); > > @@ -1062,6 +1064,9 @@ > /* Set the segment registers to '0'. */ > wait_for_cmd_done(ioaddr + SCBCmd); > outl(0, ioaddr + SCBPointer); > + /* impose a delay to avoid a bug */ > + inl(ioaddr + SCBPointer); > + udelay(10); > outb(RxAddrLoad, ioaddr + SCBCmd); > wait_for_cmd_done(ioaddr + SCBCmd); > outb(CUCmdBase, ioaddr + SCBCmd); > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo- info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANOMALIES]: 2.4.2 - __alloc_pages: failed - Patch failed
Right now before OOPS: Mem:62244K av, 61292K used, 952K free, 0K shrd,1496K buff Swap: 467444K av, 37344K used, 430100K free 29528K cached I got a lot of things running, several daemons, netscape, and other things. I put a 400MB swap for now just to help things. Here's what happens after oops: Wait a second...before I didn't have the 400MB swap on, and I had about 952K of physical ram left. Shouldn't it try and swap if it cant get enough physical memory? It did NOT oops with that amount of swap: If i turn it off: Mem:62244K av, 61288K used, 956K free, 0K shrd,1448K buff Swap: 64252K av, 38024K used, 26228K free 29880K cached and try the xcdrgtk (X CDRoaster) I get...hrm.. this is really strange. Now its not ooping?! I dont know it must have to do with something somewhere I cant tell you. Mike Galbraith wrote: > On Sun, 25 Feb 2001, Shawn Starr wrote: > > > Unsure, the system remains stable after the fault though, strangely /dev/dsp > > becomes "busy". I suspect it has to do with this somehow.. but im not sure. > > I submitted a ksymoops dump, maybe that can help. > > Drop to single user and do a whopping big dd or iozone or bonnie > and see what free reports afterward. If much of your ram becomes > available, it's not a leak. > > -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
On Wed, 7 Feb 2001, David L. Nicol wrote: > Peter Samuelson wrote: > > > A more useful thing to fall out of the same hacking is loopback > > mounting -- i.e. the same filesystem mounted multiple places. In > > Linux-land I guess we call it 'mount --bind'. > > > > Peter > > Does this kind of thing play nice with nfs and coda, in terms of > change notifications and write-backs? In distributed FS we've got > the same thing mounted multiple places, of course, but not on the > same machine There is no cache coherency problems since we have no copies to keep in sync ;-) Dentry tree is shared by all instances. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
On Wed, 7 Feb 2001, John R Lenton wrote: > On Wed, Feb 07, 2001 at 12:25:10AM -0600, Peter Samuelson wrote: > > > > [Wakko Warner] > > > I have a question, why was this idea even considered? > > > > Al Viro likes Plan9 process-local namespaces. He seems to be trying to > > move Linux in that direction. In the past year he has been hacking the > > semantics of filesystems and mounting, probably with namespaces as an > > eventual goal, and this is one of the things that has fallen out of the > > implementation. > > Aren't "translucid" mounts the idea behind this? Nope. Completely different beast - bindings have nothing to layered filesystems. I.e. if we bind /foo to /bar then /foo/barf and /bar/barf are the same object. Translucent-type would have one of them redirecting all requests to another. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OK to mount multiple FS in one dir?
On Tue, 6 Feb 2001, Wakko Warner wrote: > > > > I found I could mount three partitions on /mnt > > > > > > Yes. New feature, appeared in the 2.4.0test series, or shortly before. > > I have a question, why was this idea even considered? Direct request from HPA. Autofs can win from having that (mounting atop of mountpoint). I'd rather live without that stuff, but back then it looked like an OK idea - we could do that. There is a better solution for original problem, but... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stale NFS handles on 2.4.2
On Sun, Feb 25, 2001 at 04:43:46PM +1100, Neil Brown wrote: > On Saturday February 24, [EMAIL PROTECTED] wrote: > > I have my home directory mounted on one computer from another. I > > rebooted the server and now the client is saying Stale NFS file handle > > anytime something goes to read my home directory. It has been this > > way for about a day. Shouldn't any caches expire by now? > > It isn't that a cache needs to expire. It sounds like it is a cache > that needs to be filled. > > The kernel keeps a cache of ip addresses that are allowed access to > particular filesystems. This is visible through /proc/fs/nfs/exports. > It is filled at reboot by "exportfs -a" or "exportfs -r" which gets > information from /etc/exports and /var/lib/nfs/rmtab. > > So check that /etc/exports contains the right info. > Check that /var/lib/nfs/rmtab lists the filesystems and clients that > you expect to have access, and then run "exportfs -av" checked, verified, re-exported, still Stale NFS file handle on client. I also used tcpdump on server and when I do ls on my home directory (this is where I see the Stale NFS message), it does not generate any network traffic. It can't be the server if the client isn't asking for it. > > Both server and client are running 2.4.2. > > > > I'ved tried `mount /home -o remount`, and reading lots of other > > directories to flush out that entry if it was in cache without any > > results. > > > > I was hopping to avoid unmounting, as I would have to shut about > > everything down to do that. -- +-+ | David Fries| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Stale NFS handles on 2.4.2
On Saturday February 24, [EMAIL PROTECTED] wrote: > I have my home directory mounted on one computer from another. I > rebooted the server and now the client is saying Stale NFS file handle > anytime something goes to read my home directory. It has been this > way for about a day. Shouldn't any caches expire by now? It isn't that a cache needs to expire. It sounds like it is a cache that needs to be filled. The kernel keeps a cache of ip addresses that are allowed access to particular filesystems. This is visible through /proc/fs/nfs/exports. It is filled at reboot by "exportfs -a" or "exportfs -r" which gets information from /etc/exports and /var/lib/nfs/rmtab. So check that /etc/exports contains the right info. Check that /var/lib/nfs/rmtab lists the filesystems and clients that you expect to have access, and then run "exportfs -av" NeilBrown > > Both server and client are running 2.4.2. > > I'ved tried `mount /home -o remount`, and reading lots of other > directories to flush out that entry if it was in cache without any > results. > > I was hopping to avoid unmounting, as I would have to shut about > everything down to do that. > > -- > +-+ > | David Fries| > | [EMAIL PROTECTED] | > +-+ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs: still problems with tail conversion
On Sun, 25 Feb 2001, Bernd Eckenfels wrote: > In article <87861.983061717@tiny> you wrote: > > Exactly. The tail conversion code depends heavily on the page up to date > > bit being set right. It is more than possible that I've screwed up > > something there, and the code thinks a page is valid when it really isn't. > > I have seen null byte corruptions in syslog files with ext2 in various > kernels. So perhaps it is a general VFS problem? aol.. none since 2.4.0 release here though. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] per-process namespaces for Linux
On Sun, 25 Feb 2001, Rick Hohensee wrote: [I wrote] > >ask. So far that's the best I can do - all documentation is a pile of > >notes > >+ CVS log. [snip] > That sounds like an especially fascinating pile of notes. Perhaps you > could pile it next to the patch on the ftp site? You know, CDA is dead and gone, but I really doubt that putting this pile as-is in any vicinity of this account would be a good idea. Besides, half of them will need a translation - I doubt that 80Kb of grep output intermixed with comments in English and Russian, some of them printable, would be useful. Fasicanting - maybe, but... IOW, turning that into documentation will take some efforts. Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANOMALIES]: 2.4.2 - __alloc_pages: failed - Patch failed
On Fri, 23 Feb 2001, Shawn Starr wrote: > Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed. > Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed. > Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed. > Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed. > Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed. > Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed. > Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed. > > didnt, work, still causing this.. What does free output look like after abort? (is someone leaking or is all memory just temporarily tied up?) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2-ac3 IDE-Module-Deadlock on DEC Alpha
hi... Machine: DEC Alpha XL300 (Alcor/XLT) boots from scsi, and ide is used modular IDE-Controller: Promise ATA100 controller (PCI card) bios knows absolutely nothing about IDE (there aren't even options to set drive geometry etc) Deadlocks on loading the ide-modules with modprobe ide-probe-mod || return=$rc_failed modprobe ide-disk || return=$rc_failed (Nothing in the logs, no visible output on the screen) Applying Andre Hedrick's ide.2.4.1-p8.all.01172001.patch.gz fixes it - with this patch ide works like a charm - thanks for your good work Andre! more info's available on request c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] per-process namespaces for Linux
>I'm more than willing to answer questions on the design of the thing - >just >ask. So far that's the best I can do - all documentation is a pile of >notes >+ CVS log. > >Cheers, >Al >PS: hopefully - back for good. That sounds like an especially fascinating pile of notes. Perhaps you could pile it next to the patch on the ftp site? Rick Hohensee :; cLIeNUX /dev/tty5 01:08:45 / :;ls -d */ Linux/dev/ help/ owner/temp/ boot/ device/ incoming/ source/ command/ floppy/ log/ subroutines/ configure/guest/mounts/ suite/ :; cLIeNUX /dev/tty5 01:08:55 / :; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: weird /proc/ide/hdx/settings
Zero is a counting number. 0->255 == 1->256.
On Fri, 23 Feb 2001, David Balazic wrote:
> Running kernel 2.4.2 :
>
> cat /proc/ide/hdc/settings
>
> namevalue min max mode
> - --- ---
> bios_cyl89355 0 65535 rw
> bios_head 16 0 255 rw
> bios_sect 63 0 63 rw
> breada_readahead4 0 127 rw
> bswap 0 0 1 r
> current_speed 69 0 69 rw
> file_readahead 0 0 2097151 rw
> ide_scsi0 0 1 rw
> init_speed 12 0 69 rw
> io_32bit1 0 3 rw
> keepsettings0 0 1 rw
> lun 0 0 7 rw
> max_kb_per_request 128 1 127 rw
> multcount 0 0 8 rw
> nice1 1 0 1 rw
> nowerr 0 0 1 rw
> number 2 0 3 rw
> pio_modewrite-only 0 255 w
> slow0 0 1 rw
> unmaskirq 1 0 1 rw
> using_dma
> %X---
>
> max_kb_per_request has value 128 , but max is 127 !?
>
> max for multcount is 8 , but my drive supports 16 sectors. ( see hdparm output below
>)
> If I set multcount to 8 sectors ( hdparm -m 8 /dev/hdc )
> then /proc/ide/hdc/settings will show :
> multcount 4 0 8 rw
>
> The values are divided by 2. Why ?
>
>
> hdparm -i /dev/hdc :
>
> /dev/hdc:
>
> Model=IBM-DTLA-307045, FwRev=TX6OA60A, SerialNo=YMEYMML9342
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
> BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
> CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=90069840
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
>
> IDE interface is VIA xxx686b ( ATA-100 )
> IDE driver is VIA IDE v4.3
>
> --
> David Balazic
> --
> "Be excellent to each other." - Bill & Ted
> - - - - - - - - - - - - - - - - - - - - - -
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x in 2.4.{0,1,2}
Igor Mozetic wrote: > > There is probably just some miscoordination between the kernel > mainteiners, but anyway. The 3c59x driver shipped with all > official 2.4.x kernels lacks the 'medialock' feature. > The result on 3c900 10M/combo cards can be unpleasant: > kernel log fills up quickly and only reboot helps. > However, Andrew's unofficial drivers at > http://www.uow.edu.au/~andrewm/linux/ work fine so this is > just a plea to include them into the official kernel. The latest 3c59x driver is in the zerocopy patch, as well as at the above site. Until things converge I'd suggest that you run a zerocopy kernel rather than updating just the driver. We need the testing. Alexey has done wonders recently, and for 3com cards a zerocopy kernel now performs at least as well as a stock kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs: still problems with tail conversion
In article <87861.983061717@tiny> you wrote: > Exactly. The tail conversion code depends heavily on the page up to date > bit being set right. It is more than possible that I've screwed up > something there, and the code thinks a page is valid when it really isn't. I have seen null byte corruptions in syslog files with ext2 in various kernels. So perhaps it is a general VFS problem? Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Odd network problems
> i had a try with Linux-2.4.2 Mozilla 0.8 > > www.codewarrioru.com > time out answer (pingable however) Reachable on my windows machine. There may have been some confusion here -- it is not on a network. The two computers are in different rooms but share a phone line, regular dial-up modems. > > www.backwire.com > connection refused with ECN. > echo '0' > tcp_ecn makes it reachable. Mozilla sucks (CPU99%) and does > not display the page in a reasonable time (maybe a problem i have with > java and glibc-2.2.2) Here are the tcpdumps for two sites. Note that both are complete, with 12 and 8 packets tracked respectively. Normal sites have at least 150 packets for me. 23:08:44.811245 63.53.132.224.3466 > 64.14.114.71.www: S 964278824:964278824(0) win 2144 (DF) 23:08:44.976314 64.14.114.71.www > 63.53.132.224.3466: S 89259702:89259702(0) ack 964278825 win 16616 (DF) 23:08:44.976518 63.53.132.224.3466 > 64.14.114.71.www: . ack 1 win 2144 (DF) 23:08:44.984338 63.53.132.224.3466 > 64.14.114.71.www: . 1:501(500) ack 1 win 2144 (DF) 23:08:44.984763 63.53.132.224.3466 > 64.14.114.71.www: P 501:678(177) ack 1 win 2144 (DF) 23:08:45.286316 64.14.114.71.www > 63.53.132.224.3466: . ack 678 win 16616 (DF) 23:08:45.426324 64.14.114.71.www > 63.53.132.224.3466: . 1049:1073(24) ack 678 win 16616 (DF) 23:08:45.426489 63.53.132.224.3466 > 64.14.114.71.www: . ack 1 win 2144 (DF) 23:08:48.646309 64.14.114.71.www > 63.53.132.224.3466: . 525:537(12) ack 678 win 16616 (DF) 23:08:48.646482 63.53.132.224.3466 > 64.14.114.71.www: . ack 1 win 2144 (DF) 23:08:55.206303 64.14.114.71.www > 63.53.132.224.3466: . 525:537(12) ack 678 win 16616 (DF) 23:08:55.206484 63.53.132.224.3466 > 64.14.114.71.www: . ack 1 win 2144 (DF) > > www.counterpane.com > no problem with this one. And for this: 23:12:57.726945 63.53.132.224.3479 > 208.42.65.154.www: S 1237658684:1237658684(0) win 2144 (DF) 23:12:57.976374 208.42.65.154.www > 63.53.132.224.3479: S 3499622070:3499622070(0) ack 1237658685 win 8908 (DF) 23:12:57.976576 63.53.132.224.3479 > 208.42.65.154.www: . ack 1 win 2144 (DF) 23:12:57.984439 63.53.132.224.3479 > 208.42.65.154.www: . 1:501(500) ack 1 win 2144 (DF) 23:12:57.984854 63.53.132.224.3479 > 208.42.65.154.www: P 501:681(180) ack 1 win 2144 (DF) 23:12:58.336375 208.42.65.154.www > 63.53.132.224.3479: . ack 501 win 8908 (DF) 23:13:03.876409 63.53.132.224.3479 > 208.42.65.154.www: P 501:681(180) ack 1 win 2144 (DF) 23:13:04.166373 208.42.65.154.www > 63.53.132.224.3479: . ack 681 win 8908 (DF) > > www.zip2it.com > un-resolved (could it be www.zip2.com) This one was off of the top of my head. Turns out I was referring to www.zap2it.com, and apparently, that was a one-time problem. That was just the proverbial straw that broke the camel's back. Jonathan Eisenstein [EMAIL PROTECTED] PGP Public Key: http://www.mindspring.com/~jeisen/pgp.asc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][CFT] per-process namespaces for Linux
He's back. And this time he's got a chainsaw. Yes, folks. We got per-process namespaces. Working. With proper behaviour on exit(), yodda, yodda. Enjoy. Help with testing would be more than welcome. Current patch is on ftp.math.psu.edu/pub/viro/namespaces-S2.gz It's against 2.4.2. Contents: * proper refcounting of struct super_block * GC for vfsmounts (finally) * fix for races between get_super() and umount() * SMP-safe lock_super() * general cleanup of fs/super.c * "lazy" option for umount() (detach from mountpoint now, do the rest when it will cease to be busy - use MNT_DETACH in 'flags' argument to get that behaviour). * Plan 9 per-process namespaces (sans unions so far) * large cleanup of boot process (ramdisk handling, etc.) Variant without namespaces (they were the last part) is in the same directory, called s_lock-S2.gz. rfork.c (in the same place) will copy a namespace and start shell in it. Use for testing... It's an equivalent of rfork(RFNAMEG) on Plan 9. One detail - patch requires ramfs built into the kernel (boot process cleanup part needs that). It works here (ran for about 12 hours with no problems). It's _NOT_ for inclusion into 2.4. Some pieces might go (get_super() races have to be fixed, after all), but most of this stuff is 2.5 fodder. However, it seems to be working. No doubt there are bugs and it's far from being a final version. I would call it _very_ early beta. Please, help with testing. Comments on the code/design/amount of dope it took to write the thing (zero, actually) are welcome. I _will_ document it, but it's still not in the final form. Pretty close to it, hopefully, but... I'm more than willing to answer questions on the design of the thing - just ask. So far that's the best I can do - all documentation is a pile of notes + CVS log. Cheers, Al PS: hopefully - back for good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.2 - kernel BUG at apic.c:220!
On Sat, 24 Feb 2001, Manfred Spraul wrote: > > kernel BUG at apic.c:220! > >From apic.c: > <<< > > /* > * Double-check wether this APIC is really registered. > */ > if (!test_bit(GET_APIC_ID(apic_read(APIC_ID)), > &phys_cpu_present_map)) > BUG(); > >>> > Really odd. That's usually a sign of a bad MP table. > > Could you check your BIOS settings for an entry MP, or MPS, or > Multiprocessor Table? > Usually the options are 1.1 and 1.4 - just try the other one. This is a single CPU system, not dual. The kernel is compiled for a single CPU system as well. Looking at .config, I notice that Processor family is set to Pentium-Pro/Celeron/Pentium-II. I could have *sworn* I changed that before compiling. Could that cause the problem I'm seeing? In any case, I'll try to get some time early next week to try the patch - this is, unfortunately, a work machine, and as such, needs to work, even if I go with 2.2.x. :) I'll let you know when I can try out the patch. > > or try the attached patch - it prints 2 additional debug lines. > > -- > Manfred > > > --- Unsolicited advertisments to this address are not welcome. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] zerocopy BETA 3
On Sun, 25 Feb 2001, Chris Wedgwood wrote:
> On Fri, Feb 23, 2001 at 11:42:49AM +0100, Jan Rekorajski wrote:
>
> Could you please make a patch with this fix only? Or is it
> available somewhere?
>
[cut incomplete patch ;)]
There are more changes, I hacked'em out of vger CVS:
diff -urN linux/include/net/ip.h linux.fixed/include/net/ip.h
--- linux/include/net/ip.h Thu Feb 22 01:10:38 2001
+++ linux.fixed/include/net/ip.hFri Feb 23 14:40:40 2001
@@ -188,11 +188,16 @@
extern void __ip_select_ident(struct iphdr *iph, struct dst_entry *dst);
-static inline void ip_select_ident(struct iphdr *iph, struct dst_entry *dst)
+static inline void ip_select_ident(struct iphdr *iph, struct dst_entry *dst, struct
+sock *sk)
{
- if (iph->frag_off&__constant_htons(IP_DF))
- iph->id = 0;
- else
+ if (iph->frag_off&__constant_htons(IP_DF)) {
+ /* This is only to work around buggy Windows95/2000
+* VJ compression implementations. If the ID field
+* does not change, they drop every other packet in
+* a TCP stream using header compression.
+*/
+ iph->id = (sk ? sk->protinfo.af_inet.id++ : 0);
+ } else
__ip_select_ident(iph, dst);
}
diff -urN linux/include/net/ipip.h linux.fixed/include/net/ipip.h
--- linux/include/net/ipip.hSat Aug 5 03:18:49 2000
+++ linux.fixed/include/net/ipip.h Fri Feb 23 14:40:43 2001
@@ -30,7 +30,7 @@
int pkt_len = skb->len; \
\
iph->tot_len = htons(skb->len); \
- ip_select_ident(iph, &rt->u.dst); \
+ ip_select_ident(iph, &rt->u.dst, NULL); \
ip_send_check(iph); \
\
err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev, do_ip_send);
\
diff -urN linux/include/net/sock.h linux.fixed/include/net/sock.h
--- linux/include/net/sock.hThu Feb 22 01:10:24 2001
+++ linux.fixed/include/net/sock.h Fri Feb 23 14:40:49 2001
@@ -204,6 +204,7 @@
__u8mc_loop;/* Loopback */
unsignedrecverr : 1,
freebind : 1;
+ __u16 id; /* ID counter for DF pkts */
__u8pmtudisc;
int mc_index; /* Multicast device index */
__u32 mc_addr;
diff -urN linux/net/ipv4/af_inet.c linux.fixed/net/ipv4/af_inet.c
--- linux/net/ipv4/af_inet.cFri Dec 29 23:07:24 2000
+++ linux.fixed/net/ipv4/af_inet.c Fri Feb 23 14:40:34 2001
@@ -355,6 +355,8 @@
else
sk->protinfo.af_inet.pmtudisc = IP_PMTUDISC_WANT;
+ sk->protinfo.af_inet.id = 0;
+
sock_init_data(sock,sk);
sk->destruct = inet_sock_destruct;
diff -urN linux/net/ipv4/igmp.c linux.fixed/net/ipv4/igmp.c
--- linux/net/ipv4/igmp.c Tue Jan 9 19:54:57 2001
+++ linux.fixed/net/ipv4/igmp.c Fri Feb 23 14:40:38 2001
@@ -235,7 +235,7 @@
iph->saddr= rt->rt_src;
iph->protocol = IPPROTO_IGMP;
iph->tot_len = htons(IGMP_SIZE);
- ip_select_ident(iph, &rt->u.dst);
+ ip_select_ident(iph, &rt->u.dst, NULL);
((u8*)&iph[1])[0] = IPOPT_RA;
((u8*)&iph[1])[1] = 4;
((u8*)&iph[1])[2] = 0;
diff -urN linux/net/ipv4/ip_output.c linux.fixed/net/ipv4/ip_output.c
--- linux/net/ipv4/ip_output.c Fri Oct 27 20:03:14 2000
+++ linux.fixed/net/ipv4/ip_output.cFri Feb 23 14:54:17 2001
@@ -141,7 +141,7 @@
iph->saddr= rt->rt_src;
iph->protocol = sk->protocol;
iph->tot_len = htons(skb->len);
- ip_select_ident(iph, &rt->u.dst);
+ ip_select_ident(iph, &rt->u.dst, sk);
skb->nh.iph = iph;
if (opt && opt->optlen) {
@@ -307,7 +307,7 @@
if (ip_dont_fragment(sk, &rt->u.dst))
iph->frag_off |= __constant_htons(IP_DF);
- ip_select_ident(iph, &rt->u.dst);
+ ip_select_ident(iph, &rt->u.dst, sk);
/* Add an IP checksum. */
ip_send_check(iph);
@@ -328,7 +328,7 @@
kfree_skb(skb);
return -EMSGSIZE;
}
- ip_select_ident(iph, &rt->u.dst);
+ ip_select_ident(iph, &rt->u.dst, sk);
return ip_fragment(skb, skb->dst->output);
}
@@ -425,7 +425,7 @@
int err;
int offset, mf;
int mtu;
- u16 id = 0;
+ u16 id;
int hh_len = (rt->u.dst.dev->hard_header_len + 15)&~15;
int nfrags=0;
@@ -495,6 +495,8 @@
* Begin outputting the bytes.
*/
+ id = (sk ? sk->protinfo.af_inet.id++ : 0);
+
do {
user-mode port 0.39-2.4.2
The user-mode port of 2.4.2 is available. For the particularly paranoid, the ubd device now has the option of doing all writes O_SYNC, either as a config option for all devices or on a device-by-device basis. This is thanks to Lennert Buytenhek. A couple of hostfs bugs were fixed. A crash involving breakpoints set at the very beginning or very end of an interrupt handler was fixed. SIGFPE is now passed along to processes correctly. The SIGIO handler tries harder to empty file descriptors by giving tasklets more chances to feed the input to a process. A crash involving the tracing thread trying, and failing, to allocate memory was fixed. Fixed a race which caused timer interrupts to stop being handled. Temporary files are not created in /tmp. This apparently provides a noticable performance improvement when tmpfs is mounted on /tmp. This is also due to Lennert. The project's home page is http://user-mode-linux.sourceforge.net Downloads are available at http://sourceforge.net/project/filelist.php?group_id =429 (which Sourceforge has managed to break) and ftp://ftp.nl.linux.org/pub/um l/ Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
On Sat, 24 Feb 2001, Jeff Garzik wrote: > Disclaimer: This is 2.5, repeat, 2.5 material. [snip] > 1) Rx Skb recycling. It would be nice to have skbs returned to the > driver after the net core is done with them, rather than have netif_rx > free the skb. Many drivers pre-allocate a number of maximum-sized skbs > into which the net card DMA's data. If netif_rx returned the SKB > instead of freeing it, the driver could simply flip the DescriptorOwned > bit for that buffer, giving it immediately back to the net card. > > Advantages: A de-allocation immediately followed by a reallocation is > eliminated, less L1 cache pollution during interrupt handling. > Potentially less DMA traffic between card and host. This could be quite useful for the network driver I maintain (it's made it to the -ac patch set for 2.4, but not yet into the main kernel tarball). At the momement, it allocates 127 "buckets" (skb's under linux) at start of day and posts them to the card. After that, it maintains a minimum of 80 data buffers available to the card at any one time. There's a noticable performance hit when the driver has to reallocate new skbs to keep above the threshold. I try to recycle as much as possible w/in the driver (i.e. really small incoming packets get a new skb allocated for them and the original buffer is put back on the queue), but it would be nice to be able to recycle even more of the skbs. > Disadvantages? As has been pointed out, there's a certain loss of control over allocation of memory (could check for low memory conditions before sending the skb back to the driver, but . . .). I do see a failure to allocate all 127 skbs, occasionally, when the driver is first loaded (only way to get around this is to reboot the system). > 2) Tx packet grouping. If the net core has knowledge that more packets > will be following the current one being sent to dev->hard_start_xmit(), > it should pass that knowledge on to dev->hard_start_xmit(), either as an > estimated number yet-to-be-sent, or just as a flag that "more is > coming." > > Advantages: This lets the net driver make smarter decisions about Tx > interrupt mitigation, Tx buffer queueing, etc. > > Disadvantages? Can this sort of knowledge be obtained by a netdevice > right now, without any kernel modifications? In my experience, Tx interrupt mitigation is of little benefit. I actually saw a performance increase of ~20% when I turned off Tx interrupt mitigation in my driver (could have been poor implementation on my part). -- Noah Romer |"Calm down, it's only ones and zeros." - this message [EMAIL PROTECTED] |brought to you by The Network PGP key available |"Time will have its say, it always does." - Celltrex by finger or email |from Flying to Valhalla by Charles Pellegrino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
Jeff Garzik wrote: (about optimizing kernel network code for busmastering NIC's) > Disclaimer: This is 2.5, repeat, 2.5 material. Related question: are there any 100Mbit NICs with cpu's onboard? Something mainstream/affordable?(i.e. not 1G ethernet) Just recently someone posted asking some technical question about ARMlinux for and intel card with 2 1G ports, 8 100M ports, an onboard ARM cpu and 4 other uControllers... seems to me that ultimately the networking code should go in that direction: immagine having the *NIC* do most of this... no cache pollution problems... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> 1) Rx Skb recycling. It would be nice to have skbs returned to the
Jeff> driver after the net core is done with them, rather than have netif_rx
Jeff> free the skb. Many drivers pre-allocate a number of maximum-sized skbs
Jeff> into which the net card DMA's data. If netif_rx returned the SKB
Jeff> instead of freeing it, the driver could simply flip the DescriptorOwned
Jeff> bit for that buffer, giving it immediately back to the net card.
Jeff> Disadvantages?
netif_rx() would have to copy the buffer.
Right now, it just puts it on the queue towards the BH. For it to return
the skb would require that all processing occur inside of netif_rx() (a la BSD),
or that it copy the buffer.
Jeff> 3) Slabbier packet allocation. Even though skb allocation is decently
Jeff> fast, you are still looking at an skb buffer head grab and a
I think that if you had this, and you also returned skb's to this list on
a per device basis (change skb->free, I think) instead of to the general
pool, you probably eliminate your request #1.
] Train travel features AC outlets with no take-off restrictions|gigabit is no[
] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[
] [EMAIL PROTECTED] www.solidum.com the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANOMALIES]: 2.4.2 - __alloc_pages: ksysoops debug info
Ok, I copied the part from kern.log and pasted it into a separate file then ran
ksysoops and it appeared to have worked.
Any more info you need?
Shawn.
Shawn Starr wrote:
> Doing so..., Im not sure hot to use ksymoops or where to get that program.
> I just usually use the sysq and dump but its ugly ;-)
>
> Shawn.
>
> Marcelo Tosatti wrote:
>
> > On Fri, 23 Feb 2001, Shawn Starr wrote:
> >
> > > Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
> > > Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed.
> > > Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed.
> > > Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
> > > Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
> > > Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed.
> > > Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed.
> > >
> > > didnt, work, still causing this..
> >
> > Ok, could you please add a line with "BUG();" after the
> > printk("__alloc_pages: %d-order allocation failed", ..) in mm/page_alloc.c
> > function __alloc_pages() ?
> >
> > This will make you get an oops when an allocation fails and if you decode
> > it (with ksymoops) we can have a pretty useful backtrace to have more clue
> > of what's failing.
> >
> > TIA
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
ksymoops 2.3.7 on i586 2.4.2. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2/ (default)
-m /boot/System.map (specified)
Feb 24 19:57:32 coredump kernel: kernel BUG at page_alloc.c:507!
Feb 24 19:57:32 coredump kernel: invalid operand:
Feb 24 19:57:32 coredump kernel: CPU:0
Feb 24 19:57:32 coredump kernel: EIP:0010:[__alloc_pages+761/776]
Feb 24 19:57:32 coredump kernel: EFLAGS: 00013282
Feb 24 19:57:32 coredump kernel: eax: 0020 ebx: ecx: c1ba8000 edx:
c025abe8
Feb 24 19:57:32 coredump kernel: esi: c025c000 edi: 0003 ebp: c1d06000 esp:
c1d07d38
Feb 24 19:57:32 coredump kernel: ds: 0018 es: 0018 ss: 0018
Feb 24 19:57:32 coredump kernel: Process cdda2wav (pid: 386, stackpage=c1d07000)
Feb 24 19:57:32 coredump kernel: Stack: c0219a05 c0219b93 01fb 0003 8000
8000 0007
Feb 24 19:57:32 coredump kernel:0008 c025bff4 c0127fe4 c01b5079
c1d07de4 0001
Feb 24 19:57:32 coredump kernel:c1d07de0 8000 0007 c01b5142 8000
0001
Feb 24 19:57:32 coredump kernel: Call Trace: [__get_free_pages+20/36]
[sg_low_malloc+305/408] [sg_malloc+98/280] [sg_build_indi+385/440]
[sg_build_reserve+37/68] [sg_ioctl+1582/2588] [__get_free_pages+20/36]
Feb 24 19:57:32 coredump kernel: Code: 0f 0b 83 c4 0c 31 c0 5b 5e 5f 5d 83 c4 10 c3 83
fa 09 77 13
Using defaults from ksymoops -t elf32-i386 -a i386
Code; Before first symbol
<_EIP>:
Code; Before first symbol
0: 0f 0b ud2a
Code; 0002 Before first symbol
2: 83 c4 0c add$0xc,%esp
Code; 0005 Before first symbol
5: 31 c0 xor%eax,%eax
Code; 0007 Before first symbol
7: 5bpop%ebx
Code; 0008 Before first symbol
8: 5epop%esi
Code; 0009 Before first symbol
9: 5fpop%edi
Code; 000a Before first symbol
a: 5dpop%ebp
Code; 000b Before first symbol
b: 83 c4 10 add$0x10,%esp
Code; 000e Before first symbol
e: c3ret
Code; 000f Before first symbol
f: 83 fa 09 cmp$0x9,%edx
Code; 0012 Before first symbol
12: 77 13 ja 27 <_EIP+0x27> 0027 Before first symbol
Re: vmware 2.0.3, kernel 2.4.0 and a cdrom
On Sun, Jan 14 2001, Martin Maciaszek wrote: > Since I installed Kernel 2.4.0 VMware is no longer able to > recognize my cdrom drive. VMware shows a dialog box on power up > with following content: > [...] > CDROM: '/dev/scd0' exists, but does not appear tobe a CDROM device. On Mon Jan 15 2001, Jens Axboe wrote: > Could you try with this patch, so maybe we can get some hints as to what > is going on? I didn't see any reply to the request to see the debug output from the patch. So here is the output when it is applied to kernel 2.4.2: Feb 24 18:36:11 ipcroe kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0 Feb 24 18:36:11 ipcroe kernel: sr0: scsi-1 drive Feb 24 18:36:19 ipcroe kernel: sr0: CDROM (ioctl) reports ILLEGAL REQUEST. Feb 24 18:36:19 ipcroe kernel: Mode Sense (10) 00 0e 00 00 00 00 00 18 00 Feb 24 18:36:19 ipcroe kernel: [valid=0] Info fld=0x0, Current sr00:00: sense key Illegal Request Feb 24 18:36:19 ipcroe kernel: Additional sense indicates Invalid command operation code -Rick -- Rick Richardson [EMAIL PROTECTED] http://home.mn.rr.com/richardsons/ Twins Cities traffic animations are at http://members.nbci.com/tctraffic/ Important data should not be entrusted to Fisher, as it may eat it and make loud belching noises. -- RH 7.1 beta release notes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs: still problems with tail conversion
On Saturday, February 24, 2001 08:53:15 PM + Alan Cox <[EMAIL PROTECTED]> wrote: >> 32Mb. The test results vary depending on what else is on the partition, >> but in each case the last file affected is 01017 and there are sequences >> of previous_number+4, for up to 8 files (but next file after this might >> be previous+7 or previous +15, or sporadic). From other problems I've >> seen on the list, maybe I need more memory to run reiserfs ? > > No. Reiserfs cannot go around corrupting files regardless of the amount of > memory you have. What is however quite possible is that there is a race > condition on reiserfs (or in the VFS) that is triggered when you are > paging and programs are thus sleeping on buffer and memory allocations > > Exactly. The tail conversion code depends heavily on the page up to date bit being set right. It is more than possible that I've screwed up something there, and the code thinks a page is valid when it really isn't. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
On Sat, Feb 24, 2001 at 07:13:14PM -0500, Jeff Garzik wrote: > Sorry... I should also point out that I was thinking of tulip > architecture and similar architectures, where you have a fixed number of > Skbs allocated at all times, and that number doesn't change for the > lifetime of the driver. > > Clearly not all cases would benefit from skb recycling, but there are a > number of rx-ring-based systems where this would be useful, and (AFAICS) > reduce the work needed to be done by the system, and reduce the amount > of overall DMA traffic by a bit. A simple way to do it currently is just to compare the new skb with the old one. If it is the same, do a shortcut. That should usually work out when the system has enough memory. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
Jeff Garzik wrote: > > Andi Kleen wrote: > > > > Jeff Garzik <[EMAIL PROTECTED]> writes: > > > > > Advantages: A de-allocation immediately followed by a reallocation is > > > eliminated, less L1 cache pollution during interrupt handling. > > > Potentially less DMA traffic between card and host. > > > > > > Disadvantages? > > > > You need a new mechanism to cope with low memory situations because the > > drivers can tie up quite a bit of memory (in fact you gave up unified > > memory management). > > I think you misunderstand.. netif_rx frees the skb. In this example: > > netif_rx(skb); /* free skb of size PKT_BUF_SZ */ > skb = dev_alloc_skb(PKT_BUF_SZ) > > an alloc of a PKT_BUF_SZ'd skb immediately follows a free of a > same-sized skb. 100% of the time. > > It seems an obvious shortcut to me, to have __netif_rx or similar > -clear- the skb head not free it. No changes to memory management or > additional low memory situations created by this, AFAICS. Sorry... I should also point out that I was thinking of tulip architecture and similar architectures, where you have a fixed number of Skbs allocated at all times, and that number doesn't change for the lifetime of the driver. Clearly not all cases would benefit from skb recycling, but there are a number of rx-ring-based systems where this would be useful, and (AFAICS) reduce the work needed to be done by the system, and reduce the amount of overall DMA traffic by a bit. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops in 2.4.2 during pump on 3c509
Hi, This is not uniqe to 2.4.2 but it's the first time I scraped this of the console (so there may be errors in this report). I may not have managed to copy this correctly from the console. Greetings, Jarek Warning (compare_maps): mismatch on symbol __module_author , es1371 says d08c5080, /lib/modules/2.4.2/kernel/drivers/sound/es1371.o says d08be180. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/es1371.o entry Warning (compare_maps): mismatch on symbol __module_description , es1371 says d08c50e0, /lib/modules/2.4.2/kernel/drivers/sound/es1371.o says d08be1e0. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/es1371.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_joystick , es1371 says d08c4f40, /lib/modules/2.4.2/kernel/drivers/sound/es1371.o says d08be040. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/es1371.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_nomix , es1371 says d08c5020, /lib/modules/2.4.2/kernel/drivers/sound/es1371.o says d08be120. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/es1371.o entry Warning (compare_maps): mismatch on symbol __module_parm_desc_spdif , es1371 says d08c4fc0, /lib/modules/2.4.2/kernel/drivers/sound/es1371.o says d08be0c0. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/es1371.o entry Warning (compare_maps): mismatch on symbol __module_parm_joystick , es1371 says d08c4f27, /lib/modules/2.4.2/kernel/drivers/sound/es1371.o says d08be027. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/es1371.o entry Warning (compare_maps): mismatch on symbol __module_parm_nomix , es1371 says d08c4ffa, /lib/modules/2.4.2/kernel/drivers/sound/es1371.o says d08be0fa. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/es1371.o entry Warning (compare_maps): mismatch on symbol __module_parm_spdif , es1371 says d08c4f9c, /lib/modules/2.4.2/kernel/drivers/sound/es1371.o says d08be09c. Ignoring /lib/modules/2.4.2/kernel/drivers/sound/es1371.o entry Warning (compare_maps): mismatch on symbol __module_parm_debug , 3c509 says d08b9a8b, /lib/modules/2.4.2/kernel/drivers/net/3c509.o says d08b9d07. Ignoring /lib/modules/2.4.2/kernel/drivers/net/3c509.o entry Warning (compare_maps): mismatch on symbol __module_parm_irq , 3c509 says d08b9a98, /lib/modules/2.4.2/kernel/drivers/net/3c509.o says d08b9d14. Ignoring /lib/modules/2.4.2/kernel/drivers/net/3c509.o entry Warning (compare_maps): mismatch on symbol __module_parm_max_interrupt_work , 3c509 says d08b9ab5, /lib/modules/2.4.2/kernel/drivers/net/3c509.o says d08b9d31. Ignoring /lib/modules/2.4.2/kernel/drivers/net/3c509.o entry Warning (compare_maps): mismatch on symbol __module_parm_nopnp , 3c509 says d08b9acf, /lib/modules/2.4.2/kernel/drivers/net/3c509.o says d08b9d4b. Ignoring /lib/modules/2.4.2/kernel/drivers/net/3c509.o entry Warning (compare_maps): mismatch on symbol __module_parm_xcvr , 3c509 says d08b9aa6, /lib/modules/2.4.2/kernel/drivers/net/3c509.o says d08b9d22. Ignoring /lib/modules/2.4.2/kernel/drivers/net/3c509.o entry CPU: 0 EIP: 0010 :[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 0086 eax: 0026 ebx: cf71b800 ecx: 0296 edx: 0001 esi: 0200 edi: cf716940 ebp: cf664000 esf: cf665dc0 ds: 0018 es: 0018 ss: 0018 stack: [] [] [] [] [] [] Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available >>EIP; d08b935e <[3c509].text.end+2c/4e> <= Trace; c01dce0e <__dev_mc_upload+1e/24> Trace; c01dd03d Trace; c02041e6 Trace; c0204266 Trace; c0204266 Trace; c0204344 Trace; c020450f Trace; c020294b Trace; c012085a Trace; c01db3d3 Trace; c01dc228 Trace; c0202444 Trace; c020d3f7 Trace; c02041fb Trace; c01d742b Trace; c01d67ef Trace; c0143a36 Trace; c01d678c Trace; c0108fdb 15 warnings issued. Results may not be reliable. - my copy of the oops from the console - CPU: 0 EIP: 0010 :[] EFLAGS: 0086 eax: 0026 ebx: cf71b800 ecx: 0296 edx: 0001 esi: 0200 edi: cf716940 ebp: cf664000 esf: cf665dc0 ds: 0018 es: 0018 ss: 0018 process pump (pid: 212, stack page = cf665000) stack: [] [] [] [] [] [] [] [] [] [<01e0>] [<0093>] [] [<0086>] [<0008>] [] [] [] [] [<0006>] [<>] [] [] [<005e0001>] [] Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code f3 30 7e f8 e9 10 fe ff ff 00 00 00 00 00 00 00 00 00 00 00 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
On Sat, Feb 24, 2001 at 07:03:38PM -0500, Jeff Garzik wrote: > Andi Kleen wrote: > > > > Jeff Garzik <[EMAIL PROTECTED]> writes: > > > > > Advantages: A de-allocation immediately followed by a reallocation is > > > eliminated, less L1 cache pollution during interrupt handling. > > > Potentially less DMA traffic between card and host. > > > > > > Disadvantages? > > > > You need a new mechanism to cope with low memory situations because the > > drivers can tie up quite a bit of memory (in fact you gave up unified > > memory management). > > I think you misunderstand.. netif_rx frees the skb. In this example: > > netif_rx(skb); /* free skb of size PKT_BUF_SZ */ > skb = dev_alloc_skb(PKT_BUF_SZ) > > an alloc of a PKT_BUF_SZ'd skb immediately follows a free of a > same-sized skb. 100% of the time. Free/Alloc gives the mm the chance to throttle it by failing, and also to recover from fragmentation by packing the slabs. If you don't do it you need to add a hook somewhere that gets triggered on low memory situations and frees the buffers. > > 4) Better support for aligned RX by only copying the header, no the whole > > packet, to end up with an aligned IP header. Unless the driver knows about > > all protocol lengths this means the stack needs to support "parse header > > in this buffer, then switch to other buffer with computed offset for data" > > This requires scatter-gather hardware support, right? If so, would this > support only exist for checksumming hardware -- like the current > zerocopy -- or would non-checksumming SG hardware like tulip be > supported too? It doesn't need any hardware support. In fact it is especially helpful for the tulip. The idea is that instead of copying the whole packet to get an aligned header (e.g. on the alpha or other boxes where unaligned accesses are very expensive) you just copy the first 128 byte that probably contain the header. For the data it doesn't matter much if it's unaligned; copy_to_user and csum_copy_to_user can deal with that fine. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
Andi Kleen wrote: > > Jeff Garzik <[EMAIL PROTECTED]> writes: > > > Advantages: A de-allocation immediately followed by a reallocation is > > eliminated, less L1 cache pollution during interrupt handling. > > Potentially less DMA traffic between card and host. > > > > Disadvantages? > > You need a new mechanism to cope with low memory situations because the > drivers can tie up quite a bit of memory (in fact you gave up unified > memory management). I think you misunderstand.. netif_rx frees the skb. In this example: netif_rx(skb); /* free skb of size PKT_BUF_SZ */ skb = dev_alloc_skb(PKT_BUF_SZ) an alloc of a PKT_BUF_SZ'd skb immediately follows a free of a same-sized skb. 100% of the time. It seems an obvious shortcut to me, to have __netif_rx or similar -clear- the skb head not free it. No changes to memory management or additional low memory situations created by this, AFAICS. > 4) Better support for aligned RX by only copying the header, no the whole > packet, to end up with an aligned IP header. Unless the driver knows about > all protocol lengths this means the stack needs to support "parse header > in this buffer, then switch to other buffer with computed offset for data" This requires scatter-gather hardware support, right? If so, would this support only exist for checksumming hardware -- like the current zerocopy -- or would non-checksumming SG hardware like tulip be supported too? Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why CONFIG_MPENTIUMIII by default?
--- Frédéric L. W. Meunier <[EMAIL PROTECTED]> wrote: > Is there any reason to use CONFIG_MPENTIUMIII by > default? I > think this should be changed to CONFIG_M386, which > should work > for most, and would avoid people reporting problems > because > they forgot to set the right processor type. > I don't see many people reporting that kind of problems... as a first-year CS student I can attest that most students, even, never used Linux before. I installed Red Hat Linux on a friend's laptop - how much easier can it get - and kernel configuration just flabbergasted him. When people feel they are ready to start compiling kernels, they should learn to do so properly, in my opinion. The I-want-the-latest-and-greatest genre roughly coincide with early tech adopters, no? :) Michel Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why CONFIG_MPENTIUMIII by default?
Em Sat, Feb 24, 2001 at 08:42:53PM -0300, Frédéric L. W. Meunier escreveu: > Is there any reason to use CONFIG_MPENTIUMIII by default? I > think this should be changed to CONFIG_M386, which should work > for most, and would avoid people reporting problems because > they forgot to set the right processor type. humm AFAIK the default config is nothing more than Linus setup, not something to server as a basic setup for everybody, so go buy Linus a i386 machine for development 8) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
Jeff Garzik <[EMAIL PROTECTED]> writes: > Advantages: A de-allocation immediately followed by a reallocation is > eliminated, less L1 cache pollution during interrupt handling. > Potentially less DMA traffic between card and host. > > Disadvantages? You need a new mechanism to cope with low memory situations because the drivers can tie up quite a bit of memory (in fact you gave up unified memory management). > 3) Slabbier packet allocation. Even though skb allocation is decently > fast, you are still looking at an skb buffer head grab and a kmalloc, > for each [dev_]alloc_skb call. I was wondering if it would be possible > to create a helper function for drivers which would improve the hot-path > considerably: [...] If you need such a horror it just means there is something wrong with slab. Better fix slab. 4) Better support for aligned RX by only copying the header, no the whole packet, to end up with an aligned IP header. Unless the driver knows about all protocol lengths this means the stack needs to support "parse header in this buffer, then switch to other buffer with computed offset for data" -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Why CONFIG_MPENTIUMIII by default?
Is there any reason to use CONFIG_MPENTIUMIII by default? I
think this should be changed to CONFIG_M386, which should work
for most, and would avoid people reporting problems because
they forgot to set the right processor type.
--
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
New net features for added performance
Disclaimer: This is 2.5, repeat, 2.5 material.
I've talked about the following items with a couple people on this list
in private. I wanted to bring these up again, to see if anyone has
comments on the following suggested netdevice changes for the upcoming
2.5 development series of kernels.
1) Rx Skb recycling. It would be nice to have skbs returned to the
driver after the net core is done with them, rather than have netif_rx
free the skb. Many drivers pre-allocate a number of maximum-sized skbs
into which the net card DMA's data. If netif_rx returned the SKB
instead of freeing it, the driver could simply flip the DescriptorOwned
bit for that buffer, giving it immediately back to the net card.
Advantages: A de-allocation immediately followed by a reallocation is
eliminated, less L1 cache pollution during interrupt handling.
Potentially less DMA traffic between card and host.
Disadvantages?
2) Tx packet grouping. If the net core has knowledge that more packets
will be following the current one being sent to dev->hard_start_xmit(),
it should pass that knowledge on to dev->hard_start_xmit(), either as an
estimated number yet-to-be-sent, or just as a flag that "more is
coming."
Advantages: This lets the net driver make smarter decisions about Tx
interrupt mitigation, Tx buffer queueing, etc.
Disadvantages? Can this sort of knowledge be obtained by a netdevice
right now, without any kernel modifications?
3) Slabbier packet allocation. Even though skb allocation is decently
fast, you are still looking at an skb buffer head grab and a kmalloc,
for each [dev_]alloc_skb call. I was wondering if it would be possible
to create a helper function for drivers which would improve the hot-path
considerably:
static struct skbuff *ether_alloc_skb (int size)
{
if (size >= preallocated_skb_list->skb->size) {
dequeue_skb_from_list()
if (preallocate_size < low_water_limit)
schedule_tasklet(refill_skb_list);
return skb;
}
return dev_alloc_skb(size);
}
The skbs from this list would be allocated by a tasklet in the
background to the maximum size requested by the ethernet driver. If you
wanted to waste even more memory, you could allocate from per-CPU
lists..
Disadvantages? Doing this might increase cache pollution due to
increased code and data size, but I think the hot path is much improved
(dequeue a properly sized, initialized, skb-reserved'd skb off a list)
and would help mitigate the impact of sudden bursts of traffic.
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Maybe a bug
Maciej W. Rozycki wrote: > Hmm, you state the watchdog works from time to time and the log you > provided confirms the statement -- it reports: > > ..TIMER: vector=49 pin1=2 pin2=0 > > activating NMI Watchdog ... done. Yes, but I reach this message only once of 10 trials to boot. The other nine trials I just reach activating NMI Watchdog ... followed by no "done" (and not followed by anything else). > What chipset do you use (check with lspci)? 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40) 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16) 00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16) 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:09.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH A1 ISDN [Fritz] (rev 02) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) 00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 07) 00:0b.1 Input device controller: Creative Labs SB Live! (rev 07) 01:00.0 VGA compatible controller: nVidia Corporation NV15 (Geforce2 GTS) (rev a3) > In any case the code should not hang there in any case -- it the watchdog > appears stuck, it reports it and goes on. A hang almost surely means > hardware locked up. Yes, but why only with the 2.4.x kernels. I am using a 2.2.17 smp kernel without problems. Regards, Matthias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANOMALIES]: 2.4.2 - __alloc_pages: failed - Patch failed
Em Sat, Feb 24, 2001 at 05:31:55PM -0500, Shawn Starr escreveu: > Doing so..., Im not sure hot to use ksymoops or where to get that program. > I just usually use the sysq and dump but its ugly ;-) http://www.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/ksymoops-2.4.0.tar.bz2 - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 242-ac3 loop bug
On Sat, Feb 24 2001, Mark Swanson wrote:
> First, good job on the loop device. It's rock stable for me - except
thanks, glad to hear it.
> when I try to load the blowfish module which oops the kernel and
> crashes the loop device:-) No problem, I just use another cipher.
cipher bug or? never the less, could you ksymoops that and send
it along?
> The bug I'm reporting is that when a loop device is in use the load of
> the machine stays at 1.00 even though nothing is happening. If I umount
> the loop filesystem the load goes down to 0.00.
>
> > ps -aux | grep loop
> 1674 tty1 DW< 0:00 [loop0]
>
> The system is doing nothing to the loop filesystem.
> Strange that the process isn't logging any cpu usage time. It's
> definately responsible for the 1.00 load.
Oops, this slipped by me. Patch should fix it.
--
Jens Axboe
--- drivers/block/loop.c~ Sat Feb 24 23:08:38 2001
+++ drivers/block/loop.cSat Feb 24 23:11:13 2001
@@ -507,7 +507,7 @@
sprintf(current->comm, "loop%d", lo->lo_number);
spin_lock_irq(¤t->sigmask_lock);
- siginitsetinv(¤t->blocked, sigmask(SIGKILL));
+ sigfillset(¤t->blocked);
flush_signals(current);
spin_unlock_irq(¤t->sigmask_lock);
@@ -525,7 +525,7 @@
up(&lo->lo_sem);
for (;;) {
- down(&lo->lo_bh_mutex);
+ down_interruptible(&lo->lo_bh_mutex);
if (!atomic_read(&lo->lo_pending))
break;
Re: EXT2-fs error
A E Lawrence wrote: > > Alan Cox wrote: > > > > > I have seen similar problems on stock 2.4.2 a machine which has not run > > > 2.4.1. > > > > What disk controllers ? We really need that sort of info in order to see the > > pattern in the odd reports of corruption we get Problems have just started to show up under 2.2.18, so it is likely that the hardware has become flakey. Bit of a coincidence, unless it is a side effect of upgrading one of the packages for 2.4.2 :-( or a damaged library. So you had better discount this report. Apologies. Adrian -- A E Lawrence - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
> In your message of: Sat, 24 Feb 2001 11:55:07 CST, you write: > > > >Careful, you're overwriting ACPI data now (and using it as normal RAM). > > Hmm, I guess that would be bad. > > >Can you try one of a) LILO b) a fixed version of grub c) this patch ? > > I tried LILO and the problem did indeed go away when using that. I > guess I'll stick with LILO until Linux or grub (whichever is broken) > is fixed. There is just something appealing about a proper boot > console on a PC... Even though I wasn't much help on this, it's nice to know what was different on your config that was causing problems while I wasn't seeing any issues. I sat here for almost an hour last night trying to figure out why your machines memory map would different than mine (I have 320MB of RAM as well, so they should have been the same). The thought that you might be using a different boot loader never even crossed my mind. I've always used LILO so that's why I didn't see any problems. It's nice to know it wasn't just working for me by accident. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANOMALIES]: 2.4.2 - __alloc_pages: failed - Patch failed
Doing so..., Im not sure hot to use ksymoops or where to get that program.
I just usually use the sysq and dump but its ugly ;-)
Shawn.
Marcelo Tosatti wrote:
> On Fri, 23 Feb 2001, Shawn Starr wrote:
>
> > Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
> > Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed.
> > Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed.
> > Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
> > Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
> > Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed.
> > Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed.
> >
> > didnt, work, still causing this..
>
> Ok, could you please add a line with "BUG();" after the
> printk("__alloc_pages: %d-order allocation failed", ..) in mm/page_alloc.c
> function __alloc_pages() ?
>
> This will make you get an oops when an allocation fails and if you decode
> it (with ksymoops) we can have a pretty useful backtrace to have more clue
> of what's failing.
>
> TIA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2-fs error
Alan Cox wrote: > > > I have seen similar problems on stock 2.4.2 a machine which has not run > > 2.4.1. > > What disk controllers ? We really need that sort of info in order to see the > pattern in the odd reports of corruption we get Sorry:- 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d000 Capabilities: [c0] Power Management version 2 With dma enabled. If this is a known problem on this chipset, that may be the explanation. ael -- A E Lawrence - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mtrr message
> I'm noticing these messages: > > mtrr: base(0xd400) is not aligned on a size(0x180) boundary > :many times in dmesg. System is a dual P3-933 on a MSI 694D board (Apollo > Pro 133). > > Is it worrisome? Possibly a slight performance loss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ext2 errors under 2.4.2
Hi, I received the following errors while trying out 2.4.2. After going back to 2.2.19prexx and doing an fsck, it works fine. They came up after about six hours or so of running time. EXT2-fs warning (device md(9,5)): ext2_unlink: Deleting nonexistent file (7635227), 0 EXT2-fs error (device md(9,5)): ext2_free_blocks: Freeing blocks not in datazone - block = 982921785, count = 1 EXT2-fs error (device md(9,5)): ext2_free_blocks: Freeing blocks not in datazone - block = 982921785, count = 1 EXT2-fs error (device md(9,5)): ext2_free_blocks: Freeing blocks in system zones - Block = 65536, count = 1 EXT2-fs error (device md(9,5)): ext2_free_blocks: Freeing blocks in system zones - Block = 8, count = 1 EXT2-fs warning (device md(9,5)): ext2_unlink: Deleting nonexistent file (7635226), 0 EXT2-fs error (device md(9,5)): ext2_free_blocks: Freeing blocks not in datazone - block = 982921785, count = 1 EXT2-fs error (device md(9,5)): ext2_free_blocks: Freeing blocks not in datazone - block = 982921785, count = 1 EXT2-fs error (device md(9,5)): ext2_free_blocks: Freeing blocks in system zones - Block = 65536, count = 1 EXT2-fs error (device md(9,5)): ext2_free_blocks: bit already cleared for block 65536 EXT2-fs error (device md(9,5)): ext2_free_blocks: Freeing blocks in system zones - Block = 8, count = 1 EXT2-fs error (device md(9,5)): ext2_free_blocks: bit already cleared for block 8 init_special_inode: bogus imode (1011) init_special_inode: bogus imode (1012) init_special_inode: bogus imode (1013) init_special_inode: bogus imode (1026) I'm not sure if those init_special_inode errors are related. /dev/md5 is an md linear array composed of two IDE hard disks on an HPT370 IDE controler. Both Maxtor disks. DMA was enabled on both disks when the errors occurred. Regards, Shane -- Shane Wegner: [EMAIL PROTECTED] http://www.cm.nu/~shane/ PGP: 1024D/FFE3035D A0ED DAC4 77EC D674 5487 5B5C 4F89 9A4E FFE3 035D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mtrr message
I'm noticing these messages: mtrr: base(0xd400) is not aligned on a size(0x180) boundary :many times in dmesg. System is a dual P3-933 on a MSI 694D board (Apollo Pro 133). Is it worrisome? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Core dumps for threads
> Can anyone explain why this test is in routine `do_coredump' > in file `fs/exec.c' in the 2.4.0 kernel? > > if (!current->dumpable || atomic_read(¤t->mm->mm_users) != 1) > goto fail; > > The only thing the test on `mm_users' seems to be doing is stopping > a thread process from dumping core. What's the rationale for this? The I/O to dump the core would race other changes on the mm. The right fix is probably to copy the mm (as fork does) then dump the copy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Odd network problems
Jon Eisenstein wrote: > Here is a partial list of sites that I have had problems with. Note that > once I find one of these sites, it is consistantly unreachable, even with > sites found months ago. i had a try with Linux-2.4.2 Mozilla 0.8 > www.codewarrioru.com time out answer (pingable however) > www.backwire.com connection refused with ECN. echo '0' > tcp_ecn makes it reachable. Mozilla sucks (CPU99%) and does not display the page in a reasonable time (maybe a problem i have with java and glibc-2.2.2) > www.counterpane.com no problem with this one. > www.zip2it.com un-resolved (could it be www.zip2.com) -- Pierre Rousselet <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Core dumps for threads
Can anyone explain why this test is in routine `do_coredump' in file `fs/exec.c' in the 2.4.0 kernel? if (!current->dumpable || atomic_read(¤t->mm->mm_users) != 1) goto fail; The only thing the test on `mm_users' seems to be doing is stopping a thread process from dumping core. What's the rationale for this? -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
refill_freelist() and page_launder()
Linus,
refill_freelist() (fs/buffer.c) calls page_launder(GFP_BUFFER) after
syncing some of the oldest dirty buffers.
As fair as I can see, that used to make sense because clean pages could be
freed with page_launder(GFP_BUFFER) -- this could avoid a potential sleep
on kswapd when trying to allocate a buffer page with grow_buffers().
But now __alloc_pages will not wait kswapd anymore.
Instead the running thread will free clean pages only when it has to call
page_launder() itself because kswapd could not keep up.
Could you remove the call to page_launder() and the if() on top on your
tree ?
Come one, doing by hand its easier than a patch.
Here's the function:
/*
* We used to try various strange things. Let's not.
* We'll just try to balance dirty buffers, and possibly
* launder some pages.
*/
static void refill_freelist(int size)
{
balance_dirty(NODEV);
if (free_shortage())
page_launder(GFP_BUFFER, 0);
grow_buffers(size);
}
grow_buffers() calls alloc_page(GFP_BUFFER).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.4.2-ac3: loop threads in D state
Kernel 2.4.2-ac3. FLAGS UID PID PPID PRI NI SIZE RSS WCHAN STA TTY TIME COMMAND 40 0 425 1 -1 -20 0 0 downDW< ? 0:00 (loop0) >From a look at the source it seems that this may be normal behavior (though I'm not sure). However, it's still cosmetically annoying, because it throws off the load average (a D state process is counted as "running" for the loadavg calculation). My loopback-mounted fs seems to be working fine, nevertheless, which is a nice change from previous kernels. -- Nate Eldredge [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
> Why would anyone want to "discuss" paying intel when the license allows you > to distribute it for nothing? Its clearly designed as an alternative to GPL > for commercial vendors. Because if you bother to talk to Intel about your problems Im sure they will give you a quote to work on it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
At 03:47 PM 02/17/2001, Alan Cox wrote: > > both lock up under load. You dont run a busy ISP i guess. The fact that > > they come out with a new release every few minutes is clear evidence that > > it is problematic. > >I've been technical director of an ISP. I help manage sites that have not >insignificant loads and no eepro100 driver problems. For that matter there >are porn sites using eepro100 drivers. > > > Intel doesnt sell the e100.o driver, so they couldnt give a rats ass if it > >Your information is wrong. But then it usually is. If you are large >corporation >and would care to talk to Intel they will be happy to discuss it further. I can lock both of them up in 10 seconds with a simple test. Why would anyone want to "discuss" paying intel when the license allows you to distribute it for nothing? Its clearly designed as an alternative to GPL for commercial vendors. There have been ongoing complaints and discussions over eepro100 problems on many of the lists that I know you monitor, so why are you in denial about it? >Of course the single biggest problem with the eepro100 is closedness, and >people >in Intel with attitudes like yours who refuse to release full documentation. LINUX has no formal documentation, so are you guilty of "closedness" also? (ie "where is the 2.4 device driver spec?"), You have source to the e100 driver (which handles initialization properly, unlike the eepro driver), so what more documentation do you need? it seems that intel is being as "open" as the LInux camp, actually more so. At least with the eepro you can get the docs under non-disclosure. Under LInux you have no chance unless someone feels like helping you. DB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loop device hang
> Has the loop device hang problem that was in kernel 2.4.0 been fixed in > 2.4.1 or 2.4.2? 2.4.2 + loop-6 patch or 2.4.2-ac - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs: still problems with tail conversion
> 32Mb. The test results vary depending on what else is on the partition, > but in each case the last file affected is 01017 and there are sequences > of previous_number+4, for up to 8 files (but next file after this might be > previous+7 or previous +15, or sporadic). From other problems I've seen on > the list, maybe I need more memory to run reiserfs ? No. Reiserfs cannot go around corrupting files regardless of the amount of memory you have. What is however quite possible is that there is a race condition on reiserfs (or in the VFS) that is triggered when you are paging and programs are thus sleeping on buffer and memory allocations - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs: still problems with tail conversion
(reisertest)
I get the same problems with straight 2.4.2, machine is a k5 with
32Mb. The test results vary depending on what else is on the partition,
but in each case the last file affected is 01017 and there are sequences
of previous_number+4, for up to 8 files (but next file after this might be
previous+7 or previous +15, or sporadic). From other problems I've seen on
the list, maybe I need more memory to run reiserfs ?
This happens whether I compile the kernel (and/or the test program) with
Red Hat's revised gcc-2.96 or with egcs. First testing was with a
partition created from the rpm version of mkreiserfs, while running a
2.96-built-kernel. I've now recreated the partition while running a kernel
compiled with egcs ('kgcc'), the only difference is some of the numbers
for the affected files differ.
Partition approx 1.7Gb, built with defaults, block size is 4096.
More details of config or whatever available if required.
Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Stale NFS handles on 2.4.2
I have my home directory mounted on one computer from another. I rebooted the server and now the client is saying Stale NFS file handle anytime something goes to read my home directory. It has been this way for about a day. Shouldn't any caches expire by now? Both server and client are running 2.4.2. I'ved tried `mount /home -o remount`, and reading lots of other directories to flush out that entry if it was in cache without any results. I was hopping to avoid unmounting, as I would have to shut about everything down to do that. -- +-+ | David Fries| | [EMAIL PROTECTED] | +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some char * optimizations in kernel
Hi! > Hello everybody, > > looking through the sources I found several pieces like > lib/vsprintf.c, line 111: > const char *digits="0123456789abcdefghijklmnopqrstuvwxyz"; > > As tested with egcs-2.91.60 even with -O3 there is a difference > between > const char *digits="0123456789abcdefghijklmnopqrstuvwxyz"; > and > const char digits[]="0123456789abcdefghijklmnopqrstuvwxyz"; > > in the resulting assembler code. > > > Usage of this pointer results in it being loaded in a register, and then > pushed on the stack (for subrouting using); if it's an array, the address > is pushed directly. > > Furthermore, in the "char *"-case the pointer is stored in memory. It has to be, no matter of optimalization level. Some other module might access that variable. You _could_ do static const char *..., but it would probably not help. > As I'm not at home I can't give a complete reference of all these cases. > (But it's trivial [at least for me :-)] using perl). > > So if this changes are approved and I have the time I can post a diff in > the next few days. > > > BTW: For which size of patch is it possible to get included in the "Hall of > fame" (has helped with linux kernel)? Try something bigger than this :-). > And, btw too, where can I find a maintainer of a specific file? eg., one of > these cases is in init/version.c which has "Copyright (C) 1992 Theodore > Ts'o" - but I have to guess it's [EMAIL PROTECTED] > Is there something like Documentation/maintainers? It is something like MAINTAINERS in root. -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IDE errors on APM resume
On my Toshiba Libretto I get the following error messages after a resume following an
apm -s. Base system is SuSE 6.3 but running the 2.4.2 kernel.
IDE experts: is this anything to worry about?
trevor@trevor5: ~> dmesg
Linux version 2.4.2 (root@trevor5) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #5 Sat Feb 24 00:18:47 GMT 2001
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820: 0001 @ 000f (reserved)
BIOS-e820: 03f1 @ 0010 (usable)
BIOS-e820: 0001 @ 0401 (ACPI data)
BIOS-e820: 0002 @ 0402 (reserved)
BIOS-e820: 0008 @ fef8 (reserved)
BIOS-e820: 6e00 @ fffe (reserved)
BIOS-e820: 0200 @ fffe6e00 (ACPI NVS)
BIOS-e820: 9000 @ fffe7000 (reserved)
BIOS-e820: 0001 @ (reserved)
On node 0 totalpages: 16400
zone(0): 4096 pages.
zone(1): 12304 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=l242 ro root=306 video=vesa:ywrap
Initializing CPU#0
Detected 166.637 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 332.59 BogoMIPS
Memory: 62608k/65600k available (815k kernel code, 2604k reserved, 280k data, 196k
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 008001bf , vendor = 0
Intel Pentium with F0 0F bug - workaround enabled.
CPU: After vendor init, caps: 008001bf
CPU: After generic, caps: 008001bf
CPU: Common caps: 008001bf
CPU: Intel Mobile Pentium MMX stepping 01
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfc5f8, last bus=21
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
apm: BIOS version 1.2 Flags 0x02 (Driver version 1.14)
Starting kswapd v1.8
vesafb: framebuffer at 0xfd00, mapped to 0xc5002000, size 1984k
vesafb: mode is 800x480x8, linelength=800, pages=4
vesafb: protected mode interface info at c000:8610
vesafb: pmi: set display start = c00c8646, set palette = c00c8698
vesafb: scrolling: ywrap using protected mode interface, yres_virtual=2539
Console: switching to colour frame buffer device 100x30
fb0: VESA VGA frame buffer device
pty: 256 Unix98 ptys configured
Toshiba System Managment Mode driver v1.7 22/6/2000
block: queued sectors max/low 41389kB/13796kB, 128 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: FUJITSU MHH2064AT, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 12685680 sectors (6495 MB) w/512KiB Cache, CHS=789/255/63
Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Linux PCMCIA Card Services 3.1.22
options: [pci] [cardbus] [pm]
PCI: No IRQ known for interrupt pin A of device 00:06.0. Please try using pci=biosirq.
PCI: No IRQ known for interrupt pin B of device 00:06.1. Please try using pci=biosirq.
PCI: No IRQ known for interrupt pin A of device 00:13.0. Please try using pci=biosirq.
PCI: No IRQ known for interrupt pin B of device 00:13.1. Please try using pci=biosirq.
Intel PCIC probe: not found.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Yenta IRQ list 0eb8, PCI irq0
Socket status: 3007
Yenta IRQ list 0eb8, PCI irq0
Socket status: 3007
Yenta IRQ list 0eb8, PCI irq0
Socket status: 3011
Yenta IRQ list 0eb8, PCI irq0
Socket status: 3219
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 196k freed
Adding Swap: 64220k swap-space (priority -1)
cs: IO port probe 0x1000-0x17ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x220-0x22f 0x330-0x337 0x370-0x377
0x388-0x38f 0x480-0x48f 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa000-0xa0ff: clean.
eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:60:97:8B:2B:2B
8K FIFO split 5:3 Rx:Tx, auto xcvr
inserting floppy driver for 2.4.2
floppy0: pcmcia=1
Floppy drive(s): fd0 is 1.44M
FDC 0 is an 8272A
eth0: flipped to 10baseT
eth0: flipped to 10baseT
hda: status error: status=0x58 { DriveReady SeekComplet
Re: Loop device hang
On Saturday, 24 February 2001, at 12:38:57 -0500, Mark Bratcher wrote: > Has the loop device hang problem that was in kernel 2.4.0 been fixed in > 2.4.1 or 2.4.2? > Tried on 2.4.1 and 2.4.2 with different results: on 2.4.1 I've had no problem mounting loop devices, but creating filesystems on them "hangs" the machine (networking seems to be up for example, but remote login via ssh doesn't work). Under 2.4.2 I've been unable to use loopback devices, but AFAIK this is a known issue in this release. -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo AT internautas DOT org => Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 242-ac3 loop bug
In article <[EMAIL PROTECTED]> you wrote: > First, good job on the loop device. It's rock stable for me - except > when I try to load the blowfish module which oops the kernel and > crashes the loop device:-) No problem, I just use another cipher. > The bug I'm reporting is that when a loop device is in use the load of > the machine stays at 1.00 even though nothing is happening. If I umount > the loop filesystem the load goes down to 0.00. >> ps -aux | grep loop > 1674 tty1 DW< 0:00 [loop0] This is probably easy to fix in the driver, right now it waits for events in UNINTERRUPTIBLE state, while it should wait in INTERRUPTIBLE state. The fix isn't as trivial as removing 2 letters though, I'll send Alan a real patch on monday. Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 242-ac3 loop bug
Mark Swanson <[EMAIL PROTECTED]> writes: > --- Doug McNaught <[EMAIL PROTECTED]> wrote: > > It's just an artifact of the fact that processes in state D > > (uninterruptible sleep) are included in the load average calculation. > > Since the loop thread apparently sits in state D waiting for events > > on its device, you get a load average of 1 for each mounted loop > > device. > > My thought was that the calculation seems to be misleading. The loop > process isn't taking up any CPU time. My applications are running > faster than ever. I'm guessing that ps (and /proc/loadavg) need to make > the distinction between: > 1. uninterruptable sleep - where the process is blocking but taking > 0CPU > 2. uninterruptable sleep - I/O is happening using CPU > > But I may not understand what uninterruptable sleep is supposed to > mean. Well, "sleep" means we're not using CPU at all; we're waiting for something. Remember, "load average" isn't purely a CPU measure. Historically, state D has meant "fast" i/o--reading from disk or tape, where the result is supposed to be available very soon and it's not worth doing the extra housekeeping to sleep interruptibly. Processes aren't supposed to sit in state D for more than a fraction of a second. This being the case, Unix has always factored state D processes into the load average. For your distinction to work, there would have to be an extra flag somewhere saying "I'm in state D, but don't factor me into the load average", with corresponding code in the load average calculation routine to honor the flag. Doable, but not useful up to now, and only (possibly) worth doing if we get more threads like the loop driver that sit in D state for a long time. This is the first example I've seen in Linux of something sitting in state D for a long time on purpose. I agree that IMHO it's not ideal (for the reason you outline below, mainly). > Take sendmail for example. Its default configuration for Linux won't > send attachments if the machine's load is too high. If I have 8 loop > devices in use and the load is at least 8, this may affect how sendmail > operates. Yup. The whole Sendmail/load average thing needs careful thought anyway when setting up a production system--a load average of 8 on an 8-way system, for example, is a much lighter load than a load of 8 on a single-CPU machine. -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: reiserfs: still problems with tail conversion
On Sat, Feb 24, 2001 at 04:45:04PM +0100, Arjan Filius wrote: > Hello, > > I tried Erik's trigger-program. > > After some test i thing it's memory related, and it seems to match the > other reports i saw on lkm. > With my 384M ram i was not able te reproduce it. > With "mem=32M" linux hang while starting a test oracle-db. > However i tried (not repeated tests, and after a fresh reboot): > ram=128M ; Triggered > ram=138M ; Triggered > ram=180M ; Triggered > ram=192M ; NOT Triggered > ram=250M ; NOT Triggered > ram=256M ; NOT Triggered > > These results say that it memory dependent, and perhaps memory use > dependent. > With the mem=180M i did some additional tests: > > reisertest; triggered > free ; shows only 60M on cached data and 8192 files*8192 > bytes=64M > /sbin/swapout 100M; make sure enough cache to hold 64M data > reisertest; NOT Triggered > While leaving the data, and executing reisertest in a new dir i'm > triggring it again! > > So i think i can say, it's triggerable when the cache has no space to hold > all the data (64M), but i didn't extensive tests. > I can't confirm that. This machine has 512 Mb memory: free total used free sharedbuffers cached Mem:512940 144916 368024 0 12052 106552 -/+ buffers/cache: 26312 486628 Swap: 1992052 01992052 total used free sharedbuffers cached Mem:512940 144924 368016 0 12052 106552 -/+ buffers/cache: 26320 486620 Swap: 1992052 01992052 Jurriaan -- BOFH excuse #167: excessive collisions & not enough packet ambulances GNU/Linux 2.4.2-ac3 SMP/ReiserFS 2x1730 bogomips load av: 0.26 0.06 0.02 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.4.2 - kernel BUG at apic.c:220!
> kernel BUG at apic.c:220! >From apic.c: <<< /* * Double-check wether this APIC is really registered. */ if (!test_bit(GET_APIC_ID(apic_read(APIC_ID)), &phys_cpu_present_map)) BUG(); >>> Really odd. That's usually a sign of a bad MP table. Could you check your BIOS settings for an entry MP, or MPS, or Multiprocessor Table? Usually the options are 1.1 and 1.4 - just try the other one. or try the attached patch - it prints 2 additional debug lines. -- Manfred patch.out
Re: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
In your message of: Sat, 24 Feb 2001 11:55:07 CST, you write: > >Careful, you're overwriting ACPI data now (and using it as normal RAM). Hmm, I guess that would be bad. >Can you try one of a) LILO b) a fixed version of grub c) this patch ? I tried LILO and the problem did indeed go away when using that. I guess I'll stick with LILO until Linux or grub (whichever is broken) is fixed. There is just something appealing about a proper boot console on a PC... BIOS-provided physical RAM map: BIOS-e820: 0009f800 @ (usable) BIOS-e820: 0800 @ 0009f800 (reserved) BIOS-e820: 00019800 @ 000e6800 (reserved) BIOS-e820: 13ef @ 0010 (usable) BIOS-e820: fc00 @ 13ff (ACPI data) BIOS-e820: 0400 @ 13fffc00 (ACPI NVS) BIOS-e820: 0008 @ fff8 (reserved) On node 0 totalpages: 81904 zone(0): 4096 pages. zone(1): 77808 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=Linux ro root=301 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 242-ac3 loop bug
--- Doug McNaught <[EMAIL PROTECTED]> wrote: > Mark Swanson <[EMAIL PROTECTED]> writes: > > > > ps -aux | grep loop > > 1674 tty1 DW< 0:00 [loop0] > > > > The system is doing nothing to the loop filesystem. > > Strange that the process isn't logging any cpu usage time. It's > > definately responsible for the 1.00 load. > > It's just an artifact of the fact that processes in state D > (uninterruptible sleep) are included in the load average calculation. > Since the loop thread apparently sits in state D waiting for events > on its device, you get a load average of 1 for each mounted loop > device. My thought was that the calculation seems to be misleading. The loop process isn't taking up any CPU time. My applications are running faster than ever. I'm guessing that ps (and /proc/loadavg) need to make the distinction between: 1. uninterruptable sleep - where the process is blocking but taking 0CPU 2. uninterruptable sleep - I/O is happening using CPU But I may not understand what uninterruptable sleep is supposed to mean. Take sendmail for example. Its default configuration for Linux won't send attachments if the machine's load is too high. If I have 8 loop devices in use and the load is at least 8, this may affect how sendmail operates. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 242-ac3 loop bug
Mark Swanson <[EMAIL PROTECTED]> writes: > > ps -aux | grep loop > 1674 tty1 DW< 0:00 [loop0] > > The system is doing nothing to the loop filesystem. > Strange that the process isn't logging any cpu usage time. It's > definately responsible for the 1.00 load. It's just an artifact of the fact that processes in state D (uninterruptible sleep) are included in the load average calculation. Since the loop thread apparently sits in state D waiting for events on its device, you get a load average of 1 for each mounted loop device. I know nothing about the implementation of the loop thread so won't presume to say whether/how it can be "fixed". -Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
On Sat, Feb 24, 2001 at 10:25:42AM -0700, Jeff Lessem wrote:
> In your message of: Sat, 24 Feb 2001 09:54:47 CST, you write:
> >Jeff, are you using the e820 memory map at all ? In particular, are you
> >using grub or some other buggy bootloader that insists on specifying a
> >mem= option on the kernel command line ? There should be a kernel command
> >line message very early on, what does that say ?
>
> Yes, I am using grub, the buggy bootloader. The relevant chunk of
> kernal messages are:
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0009f800 @ (usable)
> BIOS-e820: 0800 @ 0009f800 (reserved)
> BIOS-e820: 00019800 @ 000e6800 (reserved)
> BIOS-e820: 13ef @ 0010 (usable)
> BIOS-e820: fc00 @ 13ff (ACPI data)
> BIOS-e820: 0400 @ 13fffc00 (ACPI NVS)
> BIOS-e820: 0008 @ fff8 (reserved)
> On node 0 totalpages: 81904
> zone(0): 4096 pages.
> zone(1): 77808 pages.
> zone(2): 0 pages.
> Kernel command line: root=/dev/hda1 mem=327616K
>
> You are dead on, mem= seems a bit small. Forcing mem=320M on the
> command line fixes the problem completely.
Careful, you're overwriting ACPI data now (and using it as normal RAM).
Can you try one of a) LILO b) a fixed version of grub c) this patch ?
diff -ur linux/arch/i386/kernel/setup.c linux-prumpf/arch/i386/kernel/setup.c
--- linux/arch/i386/kernel/setup.c Fri Feb 23 13:37:38 2001
+++ linux-prumpf/arch/i386/kernel/setup.c Sat Feb 24 09:49:50 2001
@@ -555,30 +555,9 @@
e820.nr_map = 0;
usermem = 1;
} else {
- /* If the user specifies memory size, we
-* blow away any automatically generated
-* size
-*/
- unsigned long start_at, mem_size;
-
- if (usermem == 0) {
- /* first time in: zap the whitelist
-* and reinitialize it with the
-* standard low-memory region.
-*/
- e820.nr_map = 0;
- usermem = 1;
- add_memory_region(0, LOWMEMSIZE(), E820_RAM);
- }
- mem_size = memparse(from+4, &from);
+ memparse(from+4, &from);
if (*from == '@')
- start_at = memparse(from+1, &from);
- else {
- start_at = HIGH_MEMORY;
- mem_size -= HIGH_MEMORY;
- usermem=0;
- }
- add_memory_region(start_at, mem_size, E820_RAM);
+ memparse(from+1, &from);
}
}
c = *(from++);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Odd network problems
I have sent this question to 3 other mailing lists already without success, so hopefully there is an answer related to kernel that can be answered here. For some strange, unidentifiable reason, I cannot reach certain sites through any web browser. Pinging the site responds well, as does traceroute, and telnetting to port 80 on the machine connects me to the site. However, once connected, no web commands are working, and any programs simply hang at this point. Using lynx (as an example; all web browsers on my machine have this problem), a connection is established, but the program hangs on "HTTP request sent; waiting for response." I have waited overnight for a response, but it stays at that point. I have tested this in any way I could think of. I have telnetted to other Linux machines, and found that they can reach the site without difficulty. I have tried using my other computer, which shares the phone line, internet account and settings, but runs Windows 98. Again, no difficulty. I have removed all software that might be acting as a firewall, removed local DNS services and have rebooted to verify that it is not a cache issue. I have also checked the FAQ, and tried to follow the directions for problems with ECN, but do not have a file named /proc/sys/net/ipv4/tcp_ecn. (I am using devfs, if that makes a difference.) If this is not a kernel issue, then I hope someone can direct me to some other way of fixing this problem. If a solution cannot be offered, then advice about how to trace this problem would also be welcomed. Here is a partial list of sites that I have had problems with. Note that once I find one of these sites, it is consistantly unreachable, even with sites found months ago. www.codewarrioru.com www.backwire.com www.counterpane.com www.zip2it.com Thank you for any help you might be able to provide. Jonathan Eisenstein [EMAIL PROTECTED] PGP Public Key: http://www.mindspring.com/~jeisen/pgp.asc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANOMALIES]: 2.4.2 - __alloc_pages: failed - Patch failed
On Fri, 23 Feb 2001, Shawn Starr wrote:
> Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
> Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed.
> Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed.
> Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
> Feb 23 21:17:47 coredump kernel: __alloc_pages: 3-order allocation failed.
> Feb 23 21:17:47 coredump kernel: __alloc_pages: 2-order allocation failed.
> Feb 23 21:17:47 coredump kernel: __alloc_pages: 1-order allocation failed.
>
> didnt, work, still causing this..
Ok, could you please add a line with "BUG();" after the
printk("__alloc_pages: %d-order allocation failed", ..) in mm/page_alloc.c
function __alloc_pages() ?
This will make you get an oops when an allocation fails and if you decode
it (with ksymoops) we can have a pretty useful backtrace to have more clue
of what's failing.
TIA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Loop device hang
Hi, Has the loop device hang problem that was in kernel 2.4.0 been fixed in 2.4.1 or 2.4.2? Thanks. -- Mark Bratcher - Escape from Microsoft's proprietary tentacles: use Linux! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
242-ac3 loop bug
First, good job on the loop device. It's rock stable for me - except when I try to load the blowfish module which oops the kernel and crashes the loop device:-) No problem, I just use another cipher. The bug I'm reporting is that when a loop device is in use the load of the machine stays at 1.00 even though nothing is happening. If I umount the loop filesystem the load goes down to 0.00. > ps -aux | grep loop 1674 tty1 DW< 0:00 [loop0] The system is doing nothing to the loop filesystem. Strange that the process isn't logging any cpu usage time. It's definately responsible for the 1.00 load. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs: still problems with tail conversion
On Saturday, February 24, 2001 04:45:04 PM +0100 Arjan Filius <[EMAIL PROTECTED]> wrote: > Hello, > > I tried Erik's trigger-program. > > After some test i thing it's memory related, and it seems to match the > other reports i saw on lkm. > With my 384M ram i was not able te reproduce it. > With "mem=32M" linux hang while starting a test oracle-db. > However i tried (not repeated tests, and after a fresh reboot): > ram=128M ; Triggered Ah, I did not get it at 128M, but did get the messages at 32MB. The read stage of the test program does not close the fd by the way, so some of the errors were from that (but not all). So, there must be somewhere else that we are screwing up the tail conversion, I'll see what I can find. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
In your message of: Sat, 24 Feb 2001 09:54:47 CST, you write: >Jeff, are you using the e820 memory map at all ? In particular, are you >using grub or some other buggy bootloader that insists on specifying a >mem= option on the kernel command line ? There should be a kernel command >line message very early on, what does that say ? Yes, I am using grub, the buggy bootloader. The relevant chunk of kernal messages are: BIOS-provided physical RAM map: BIOS-e820: 0009f800 @ (usable) BIOS-e820: 0800 @ 0009f800 (reserved) BIOS-e820: 00019800 @ 000e6800 (reserved) BIOS-e820: 13ef @ 0010 (usable) BIOS-e820: fc00 @ 13ff (ACPI data) BIOS-e820: 0400 @ 13fffc00 (ACPI NVS) BIOS-e820: 0008 @ fff8 (reserved) On node 0 totalpages: 81904 zone(0): 4096 pages. zone(1): 77808 pages. zone(2): 0 pages. Kernel command line: root=/dev/hda1 mem=327616K You are dead on, mem= seems a bit small. Forcing mem=320M on the command line fixes the problem completely. BIOS-provided physical RAM map: BIOS-e820: 0009f800 @ (usable) BIOS-e820: 0800 @ 0009f800 (reserved) BIOS-e820: 00019800 @ 000e6800 (reserved) BIOS-e820: 13ef @ 0010 (usable) BIOS-e820: fc00 @ 13ff (ACPI data) BIOS-e820: 0400 @ 13fffc00 (ACPI NVS) BIOS-e820: 0008 @ fff8 (reserved) On node 0 totalpages: 81920 zone(0): 4096 pages. zone(1): 77824 pages. zone(2): 0 pages. Kernel command line: root=/dev/hda1 mem=320M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] philips rush usb support
On Sat, Feb 24, 2001, Pifko Krisztian <[EMAIL PROTECTED]> wrote: > I've made a patch which adds usb support for the philips > rush mp3 player. The driver is mainly the rio500 driver > only the rush specific parts were modified. > > The patch is against 2.4.2. > > It uses char 180 65 at /dev/usb/rush. > > Userspace stuff should be found at http://openrush.sourceforge.net > if you have a rush. It works for me on ia32 with the model sa125. Why can't the entire driver be in userspace? It appears it uses a completely proprietary protocol and you've created a completely proprietary interface to the kernel. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APM suspend system lockup under 2.4.2 and 2.4.2ac1
> the sound card is a yamaha YMF-744B. i hadn't been > compiling with sound support (i dont care about sound > on my laptop), but when i got 2.4.2 i decided to try, > and now i'm pretty sure that was the problem. The Yamaha sound driver doesnt handle the case where the bios fails to restore the chip status and expects a windows driver to do its dirty work. That requires on resume that the device is completely reloaded. A workaround is to make it a module, unload it before suspend and reload it after resume but thats pretty umm uggly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 broke gcd (or, audio CD's won't play)
On Fri Feb 23 2001, Steven Walter wrote: > After upgrading to 2.4.2, gcd or any audio CD player will work. The > attached chunk of dmesg is the messages produced by attempting to play > them. The player just loops through all tracks, playing nothing. Here, xmcd and cda both work perfectly. Linux elfie 2.4.2 #1 Thu Feb 22 10:52:17 CET 2001 i586 unknown Kernel modules 2.4.2 Gnu C 2.95.2 Gnu Make 3.79 Binutils 2.10.91.0.2 Linux C Library2.2.2 Dynamic linker ldd (GNU libc) 2.2.2 Linux C++ Library 2.9.0 Procps 2.0.2 Mount 2.10r Net-tools 1.46 Kbd0.96 Sh-utils 1.12 Modules Loaded serial -- # Heinz Diehl, 68259 Mannheim, Germany - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2-fs error
> I have seen similar problems on stock 2.4.2 a machine which has not run > 2.4.1. What disk controllers ? We really need that sort of info in order to see the pattern in the odd reports of corruption we get - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ide / usb problem
> I get the following message when copying a 300MB directory under 2.4.2.
>
> uhci:host system error, PCI problems?
> uhci:host controller halted, very bad
The USB code should recover from that , if it doesnt report it to the USB
folks.
> I was not sure if the VIA82CXXX option should be set with the via kt133
> chipset , but setting it results in hundreds of
> hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr:error=0x84 { DriveStatusError BadCRC }
> mesages along with the uhci: errors mentioned above.
> Again , the directory was copied correctly.
That indicates cable problems. The CRC will avoid bad transfers as it will
do retries
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] philips rush usb support
Hi! I've made a patch which adds usb support for the philips rush mp3 player. The driver is mainly the rio500 driver only the rush specific parts were modified. The patch is against 2.4.2. It uses char 180 65 at /dev/usb/rush. Userspace stuff should be found at http://openrush.sourceforge.net if you have a rush. It works for me on ia32 with the model sa125. regards: Krisztian Pifko diff -urN -X dontdiff linux/Documentation/Configure.help linux-2.4.2-rush1/Documentation/Configure.help --- linux/Documentation/Configure.help Sat Feb 24 15:44:32 2001 +++ linux-2.4.2-rush1/Documentation/Configure.help Sat Feb 24 15:49:02 2001 @@ -10727,6 +10727,17 @@ The module will be called rio500.o. If you want to compile it as a module, say M here and read Documentation/modules.txt. +USB Philips Rush support +CONFIG_USB_RUSH + Say Y here if you want to connect a USB Philips Rush mp3 player to your + computer's USB port. Please read Documentation/usb/rush.txt + for more information. + + This code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called rush.o. If you want to compile it as + a module, say M here and read Documentation/modules.txt. + D-Link DSB-R100 FM radio support CONFIG_USB_DSBR Say Y here if you want to connect this type of radio to your diff -urN -X dontdiff linux/Documentation/usb/rush.txt linux-2.4.2-rush1/Documentation/usb/rush.txt --- linux/Documentation/usb/rush.txtWed Dec 31 19:00:00 1969 +++ linux-2.4.2-rush1/Documentation/usb/rush.txtSat Feb 24 15:49:02 2001 @@ -0,0 +1,113 @@ +Copyright (C) 2001 Krisztian Pifko +Based on rio.txt + +Feb. 25, 2001 + +CHANGES + +- Initial Release + + +OVERVIEW + +This README will address issues regarding how to configure the kernel +to access a Philips Rush mp3 player. +Before I explain how to use this to access the Rush please be warned: + +W A R N I N G: +-- + +Please note that this software is still under development. The authors +are in no way responsible for any damage that may occur, no matter how +inconsequential. + +Contact information: + + + The main page for the project is hosted at sourceforge.net in the following + address: http://rush.sourceforge.net You can also go to the sourceforge + project page at: http://sourceforge.net/projects/openrush/ There is + also a mailing list: [EMAIL PROTECTED] + +Authors: +--- + +Kernel code based on the rio500 driver. Modified by Krisztian Pifko +<[EMAIL PROTECTED]> to suit the needs of Rush. + + +ADDITIONAL INFORMATION and Userspace tools + +http://openrush.sourceforge.net/ + + +REQUIREMENTS + +A host with a USB port. Ideally, either a UHCI (Intel) or OHCI +(Compaq and others) hardware port should work. + +A Linux development kernel (2.3.x) with USB support enabled or a +backported version to linux-2.2.x. See http://www.linux-usb.org for +more information on accomplishing this. + +A Linux kernel with Rush support enabled. + +'lspci' which is only needed to determine the type of USB hardware +available in your machine. + +CONFIGURATION + +Using `lspci -v`, determine the type of USB hardware available. + + If you see something like: + +USB Controller: .. +Flags: . +I/O ports at + + Then you have a UHCI based controller. + + If you see something like: + + USB Controller: . + Flags: + Memory at . + + Then you have a OHCI based controller. + +Using `make menuconfig` or your preferred method for configuring the +kernel, select 'Support for USB', 'OHCI/UHCI' depending on your +hardware (determined from the steps above), 'USB Philips Rush support', and +'Preliminary USB device filesystem'. Compile and install the modules +(you may need to execute `depmod -a` to update the module +dependencies). + +Add a device for the USB rush: + `mknod /dev/usb/rush c 180 65 + +Set appropriate permissions for /dev/usb/rush (don't forget about +group and world permissions). Both read and write permissions are +required for proper operation. + +Load the appropriate modules (if compiled as modules): + + OHCI: +modprobe usbcore +modprobe usb-ohci +modprobe rush + + UHCI: +modprobe usbcore +modprobe usb-uhci (or uhci) +modprobe rush + +That's it. The OpenRUSH utilities at: http://openrush.sourceforge.net should +be able to access the rush. + +BUGS + +If you encounter any problems please contact me. + +Krisztian Pifko [EMAIL PROTECTED] + diff -urN -X dontdiff linux/MAINTAINERS linux-2.4.2-rush1/MAINTAINERS --- linux/MAINTAINERS Sat Feb 24 15:44:32 2001 +++ linux-2.4.2-rush1/MAINTAINERS Sat Feb 24 15:49:02 2001 @@ -1423,6 +1423,13 @@ W: http://rio500.sourceforge.net S: Maintained +USB PHILIPS RUSH DRIVER +P: Krisztian Pifko +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://openrush.sourceforge.net +S: Maintained + VIDEO FOR LINUX P:
Re: creation of sock
Hello,
It seems like linux replaces sock with tcp_tw_bucket structure in the
sock list in order to "work around the memory consumption problems for
the heavilly loaded server".
The header file tcp.h has some comments before declaring
"tcp_tw_bucket" structure. It is done in tcp_input.c.
But anyway, tcp_tw_bucket is never identical to sock structure. This
is a serious hack and I'm suprised no linux kernel documentation talks
about it.
I just wanted to let others know so that no one else faces this
problem.
--
Sourav
>
> im a kernel newbie here so pardon "the blind leading the blind" ...
>
> doing a quick search for all calls to sk_alloc in the entire kernel
> sources
> yields only one call that sets the "zero out the allocated struct"
> boolean
> to false and that is:
> net/ipv4/tcp_minisocks.c:tcp_create_openreq_child().
> this funtion in turn is only ever called from:
> net/ipv[46]/tcp_ipv[46].c:tcp_v[46]_syn_recv_sock()
>
> the comment above the ipv4 version is (verbatim):
>
> /*
>* The three way handshake has completed - we got a valid synack -
>* now create the new socket.
>*/
>
> so if you need those experimental values of yours zeroed out on socket
> creation i suggest replacing this snippet from
> net/core/sock.c:sk_alloc()
>
> if(sk && zero_it) {
> memset(sk, 0, sizeof(struct sock));
> sk->family = family;
> sock_lock_init(sk);
> }
>
> with
>
> if( sk ) {
> /* set your NULL init values here */
> if( zero_it ) {
> memset(sk, 0, sizeof(struct sock));
> sk->family = family;
> sock_lock_init(sk);
> }
> }
>
> doh! i just re-read your mail and realized youre using the 2.2.15
> kernel.
> my examples are from the 2.4.2 sources...
>
> looking at the 2.2.16 source (i have only 2.2.1[46] and not 2.2.15 for
> the
> 2.2 series) the (roughly) congruent if block of code is:
>
> if(sk) {
> if (zero_it)
> memset(sk, 0, sizeof(struct sock));
> sk->family = family;
> }
>
> and so if you're setting your init values to NULL under the "zero_it"
> condition you would get the behavior that you reported.
>
> hope that helps.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Promise Supertrak status
Hello all, I'm just wondering if is / will be support for the Promise Supertrak 100 and the likes in the kernel... If anyone have any pointers to where I can find info about this it is deeply appreciated... A company has bought three Supertrak cards + 18 drives, and I don't want to install WinNt on those boxes... Magnus Naeslund -- no .sig - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
On Sat, Feb 24, 2001 at 05:36:47AM -0800, Linus Torvalds wrote: > On Sat, 24 Feb 2001, Jeff Lessem wrote: > > > > >Also, how much memory does this machine have? That "13ff" does worry > > >me a bit.. > > > > The comptuer has 320MB. At this point I am ready to conclude that the > > computer is broken in some way, because nobody else with an Inspiron > > 5000e that I have heard from has anything like this problem. > I didn't believe that you'd have 320MB just because it's such an odd > number, but the problem is that Linux apparently starts allocating the PCI > address space just _under_ the 320MB mark (you probably have some memory > reserved for ACPI that doesn't show up in the e820 memory map). Jeff, are you using the e820 memory map at all ? In particular, are you using grub or some other buggy bootloader that insists on specifying a mem= option on the kernel command line ? There should be a kernel command line message very early on, what does that say ? Also, can you give us the E820 memory map (kernel messages starting with BIOS-e820) ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs: still problems with tail conversion
Hello,
I tried Erik's trigger-program.
After some test i thing it's memory related, and it seems to match the
other reports i saw on lkm.
With my 384M ram i was not able te reproduce it.
With "mem=32M" linux hang while starting a test oracle-db.
However i tried (not repeated tests, and after a fresh reboot):
ram=128M; Triggered
ram=138M; Triggered
ram=180M; Triggered
ram=192M; NOT Triggered
ram=250M; NOT Triggered
ram=256M; NOT Triggered
These results say that it memory dependent, and perhaps memory use
dependent.
With the mem=180M i did some additional tests:
reisertest ; triggered
free; shows only 60M on cached data and 8192 files*8192
bytes=64M
/sbin/swapout 100M ; make sure enough cache to hold 64M data
reisertest ; NOT Triggered
While leaving the data, and executing reisertest in a new dir i'm
triggring it again!
So i think i can say, it's triggerable when the cache has no space to hold
all the data (64M), but i didn't extensive tests.
Running suse7.0+updates
kernel 2.4.2
Greatings,
On Fri, 23 Feb 2001, Erik Mouw wrote:
> Hi all,
>
> I am running linux-2.4.2-pre4 with Chris Mason's tailconversion bug fix
> applied, but I still have problems with null bytes in files. I wrote a
> little test program that clearly shows the problem:
>
>
> /* reisertest.c: test for tailconversion bug in reiserfs
> *
> * Compile with: gcc -O2 -o reisertest reisertest.c
> */
> #include
> #include
> #include
> #include
> #include
>
> #define MAXBYTES 8192
>
> int main(int argc, char *argv[])
> {
> int fd;
> int i;
> char name[32];
> char buf[MAXBYTES];
> char check[MAXBYTES];
>
> memset(buf, 0x55, MAXBYTES);
>
> fprintf(stderr, "Creating %d files ... ", MAXBYTES);
>
> for(i = 0; i < MAXBYTES; i++) {
> sprintf(name, "reiser-%05d.test", i);
> fd = open(name, O_WRONLY | O_CREAT, 0644);
> write(fd, buf, i);
> close(fd);
> }
>
> fprintf(stderr, "done\n");
> fprintf(stderr, "Appending to the files ... ");
>
> for(i = 0; i < MAXBYTES; i++) {
> sprintf(name, "reiser-%05d.test", i);
> fd = open(name, O_WRONLY | O_APPEND);
> write(fd, buf, MAXBYTES - i);
> close(fd);
> }
>
> fprintf(stderr, "done\n");
> fprintf(stderr, "Checking files for null bytes ...\n");
>
> for(i = 0; i < MAXBYTES; i++) {
> sprintf(name, "reiser-%05d.test", i);
> fd = open(name, O_RDONLY);
> read(fd, check, MAXBYTES);
> if(memcmp(buf, check, MAXBYTES) != 0)
> fprintf(stderr, " %s contains null bytes\n", name);
> }
>
> fprintf(stderr, "Checking done\n");
>
> return 0;
> }
>
>
> When I run this on a reiserfs partition, I get output like this:
>
>
> erik@arthur:~/reisertest/foo> ../reisertest
> Creating 8192 files ... done
> Appending to the files ... done
> Checking files for null bytes ...
> reiser-00193.test contains null bytes
> reiser-00220.test contains null bytes
> reiser-00256.test contains null bytes
> reiser-00289.test contains null bytes
> reiser-00329.test contains null bytes
> reiser-00338.test contains null bytes
> reiser-00374.test contains null bytes
> reiser-00407.test contains null bytes
> reiser-00415.test contains null bytes
> reiser-00430.test contains null bytes
> reiser-00438.test contains null bytes
> reiser-00445.test contains null bytes
> reiser-00459.test contains null bytes
> reiser-00481.test contains null bytes
> reiser-00501.test contains null bytes
> reiser-00508.test contains null bytes
> reiser-00521.test contains null bytes
> reiser-00534.test contains null bytes
> reiser-00558.test contains null bytes
> reiser-00577.test contains null bytes
> reiser-00583.test contains null bytes
> reiser-00600.test contains null bytes
> reiser-00606.test contains null bytes
> reiser-00612.test contains null bytes
> reiser-00623.test contains null bytes
> reiser-00634.test contains null bytes
> reiser-00645.test contains null bytes
> reiser-00665.test contains null bytes
> reiser-00685.test contains null bytes
> reiser-00730.test contains null bytes
> reiser-00735.test contains null bytes
> reiser-00740.test contains null bytes
> reiser-00745.test contains null bytes
> reiser-00750.test contains null bytes
> reiser-00759.test contains null bytes
> reiser-00764.test contains null bytes
> reiser-00773.test contains null bytes
> reiser-00778.test contains null bytes
> reiser-00787.test contains null bytes
> reiser-00796.test contains null bytes
> reiser-00805.test contains null bytes
> reiser-00814.test contains null bytes
> reiser-00866.test contains null bytes
> reiser-00915.test contains null bytes
> reiser-00930.test contains null bytes
>
test delete me
please disregard this message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
test delete me
please disregard this message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM balancing problems under 2.4.2-ac1
On Sat, 24 Feb 2001, Joseph Bueno wrote: > Rik van Riel a écrit : > > On 23 Feb 2001, Adam Sampson wrote: > > > > > The VM balancing updates in the recent ac kernels seem to have caused > > > some interesting performance problems on my desktop machine. I've got > > > 160Mb of RAM, and 2.4.2-ac1 appears to be using excessively large > > > amounts of it for buffers and cache while pushing stuff out to > > > swap. This means that Mozilla, for instance, runs significantly worse > > > than under 2.4.0, since bits of it are being swapped in and out. > > > > This is a known problem which I'll fix as soon as I have a > > solution. > > > > The problem is that we still have no good way to balance > > how much memory we take from the cache and how much memory > > we take from processes. > I understand that auto-balancing code that deals with all > situations is very hard to design; so let me share my experience > on other Unix systems (from a user/administrator point of view): > > I have used Unix systems (mainly HPUX) for several years as personal > workstations or servers and buffer cache usage were very differents: > > On workstations, you are mainly looking for fast interactive response > time and you want to dedicate as much memory as possible to running > processes so limiting buffer cache to 10% of physical memory (these > workstations had typically 32 - 64 Mb of RAM) was good. "Unfortunately" the cache also contains _process memory_ in Linux. Limiting the cache to 10% also means limiting the code size of all your processes to something smaller than that. Also, read-in swap pages are in the so-called swap cache, which is also part of the page cache. This means that simple limits on cache size probably won't do much good on Linux. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2-ac3 == 400% speed improvement with Java
Hello, any 2.4.1-ac5 kernel and above until 2.4.2-ac3 had a bug (Ingo guessed it might be the yield() bug) that made Java (and some other things *really* slow). This is fixed now. When I profiled slow kernels the mtrr_file_add was taking up all of the time - even though I had disabled mtrr in my kernel (it wasn't in /proc). (Alan Cox: I'm not sure if the yield() bug was the problem, or if that patch was in the TUX patch (based on -ac3) or the -ac3 patch.) Here was the old test: (With 2.4.2-ac3 things are even faster than 2.2.14 at 0:00.44elapsed!!) (jdk1.3.0_01) > time java (done multiple times so everything is in cache) On 2.2.14 (400MHz Celeron/192MB RAM) this takes about 0.66ms. 0.37 user 0.07 system 0:00.62elapsed 70% CPU (oavgtext+0avgdata 0maxresident)k 0inputs+0outputs (3957major+1707minor)pagefulats 0swaps On linux 2.4.2-ac1-TUX (same machine) 0.33 user 2.17 system 0:03.49elapsed 71%CPU (ovgtext+0avgdata 0maxresident)k 0inputs+0outputs (3987major+1784minor)pagefaults 0swaps __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.2.19pre14 VP3 + Quantum: dma on hangs
Hello all, Using 2.2.19pre14 with: * software raid * raid1 readbalancing * i2c * lm_sensors * ipsec My drives are as follows: hda: QUANTUM FIREBALLP AS20.5, 19595MB w/1902kB Cache, CHS=2498/255/63 hdc: QUANTUM FIREBALLP AS20.5, 19595MB w/1902kB Cache, CHS=39813/16/63 hdd: IBM-DTTA-350840, 8063MB w/467kB Cache, CHS=16383/16/63 hdb: ATAPI 4X CD-ROM drive, 256kB Cache [ Bios sees: HDA & HDC : udma5, HDD: udma2 ] And the mainboard related stuff in lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02) 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10) Now, if I turn on dma on hdd, and run hdparm benchmark, everything works fine. If I turn on dma with hdparm on hda or hdc, next disk activity will freeze the system completely. No keyboard interaction, not anything. Only reset helps. Also, if I disable UDMA in bios completely on hda and hdc, hdparm will work, but the speed is awful (only ~6 MB/s) even if DMA is enabled. The most relevant kernel settings are, I think: CONFIG_BLK_DEV_IDEDMA=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_NS87415 is not set CONFIG_BLK_DEV_VIA82C586=y # CONFIG_BLK_DEV_CMD646 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_IDE_CHIPSETS is not set Any ideas? Please Cc: -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oynot those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Request: increase in PCI bus limit
On Wed, Jan 31, 2001 at 03:38:55PM -0500, George wrote: > It's somewhat annoying that by choosing SMP NR_CPUS goes to 32 when I know > I only have (and ever will have) 2 in this machine. Don't make busses have > the same assumptions that just waste memory. It's just sad that bumping to NR_CPUS to 128 won't work that easily ;-) Ralf (fixing that so he gets some machine time again ...) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk is cheap?
On Wed, Jan 31, 2001 at 02:29:54PM +0100, Robert Kaiser wrote: > Perhaps a more convincing argument may be that in embedded devices, > disk as well as memory and CPU power are _not_ cheap. > > The more resources Linux requires, the less are it's chances of being > accepted as a viable alternative in embedded systems. > > > I'm still stuck with a P-133, 56 MB RAM (60-70 ns, some EDO, > > some FPM) and not only Linux but also W2K on a 2.1 and a 0.8 GB > > HDD. > > That would be _a_ _lot_ for an embedded system! Oh this common missconception that embedded system equals small systems. There are embedded systems that outrun supercomputers without sweating, have gigs of RAM and sometimes if you look at them closly even have the names of well known big iron companies on their boards. The whole embedded term is just so weakly defined and everybody seem to have his personal definition. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Detecting SMP
On Tue, 20 Feb 2001, Burton Windle wrote:
>Hello. Is there a way, when running a non-SMP kernel, to detect or
>otherwise tell (software only; the machine is 2400 miles away) if the
>system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
>kernel is non-SMP? Thanks!
>
>(btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I
>know I should update it anyways and that a SMP kernel will run on a UP
>system)
Yes, there are several ways. How do you want to know how to do
it, in C, or a bash script? sysconf is one way, parsing
/proc/cpuinfo and /proc/stat is another. Beware though, if you
parse /proc/cpuinfo or stat, it is very different on different
architectures, particularly sparc.
Here is some code which should do it more or less correctly on
any arch:
ncpus=$(egrep -c ^cpu[0-9]+ /proc/stat || :)
[ "$ncpus" = "0" ] && ncpus=1
--
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
--
if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
printf("Don't Panic!\n");
exit(42);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI oddities on Dell Inspiron 5000e w/ 2.4.x
On Sat, 24 Feb 2001, Jeff Lessem wrote: > > >Also, how much memory does this machine have? That "13ff" does worry > >me a bit.. > > The comptuer has 320MB. At this point I am ready to conclude that the > computer is broken in some way, because nobody else with an Inspiron > 5000e that I have heard from has anything like this problem. The machine isn't broken. It's Linux. I didn't believe that you'd have 320MB just because it's such an odd number, but the problem is that Linux apparently starts allocating the PCI address space just _under_ the 320MB mark (you probably have some memory reserved for ACPI that doesn't show up in the e820 memory map). The PCI allocation needs to be fixed, but I'm off for two days in Finland.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.2 'ld' fix
> The ld in newer bintuils doesn't like -oformat, rather it > requires --oformat instead. This is backwards compatible at > least to 2.9.5 so shouldn't break anything :) > > As far as I can tell on i386 uses ld in such a way. There's a tested patch for this in -ac. The use of --oformat seems to have caused no problems to anyone so is worth applying - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ide / usb problem
I get the following message when copying a 300MB directory under 2.4.2.
uhci:host system error, PCI problems?
uhci:host controller halted, very bad
This does not happen under 2.4.1 and it happens every time under 2.4.2.
The system still runs fine except for usb mouse.
All of the files in the directory are copied correctly.
It happens when dma is enabled by hdparm -d1 /dev/hda or when dma is
enabled automatically by the kernel.
I have an Abit kt7 mb with the kt133 chipset,Athlon 900 , 128MB mem,
quantum fireball 20G disk, gcc 2-95-2 , glibc 2-2-1.
There are no problems with dma disabled.
I was not sure if the VIA82CXXX option should be set with the via kt133
chipset , but setting it results in hundreds of
hda: dma_intr:status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr:error=0x84 { DriveStatusError BadCRC }
mesages along with the uhci: errors mentioned above.
Again , the directory was copied correctly.
Is there anyway to get 2.4.2 to use dma and not turn off my usb mouse ?
thanks jpd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Disc corruption on stock 2.4.2 [Atlon on Abit KT7R]
--
Dr A E Lawrence
Disc corruption on stock 2.4.2
~~
Looks similar to problems on 2.4.2-pre{3,4}, but those were seen when
overclocking. This report refers to an Athlon at standard clock frequency.
Activity: under X, running several tars with gzip writing onto an ide disc
/dev/hdb1. Some of the tar images reading from scsi discs.
(This machine is not well balanced, and tends to be disc bound: there was
thus intense disc activity.)
Mounts:-
/dev/hda1 on / type ext2 (rw)
/dev/sdb4 on /usr type ext2 (rw)
/dev/sda2 on /home type ext2 (rw)
/dev/hda3 on /fs0 type ext2 (rw)
/dev/hdb1 on /fs1 type ext2 (rw)
/dev/sda1 on /dos type msdos (rw)
/dev/sdb1 on /doze95 type vfat (rw)
Feb 23 21:24:32 conquest2 kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
Feb 23 21:24:32 conquest2 kernel: ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
Feb 23 21:24:32 conquest2 kernel: VP_IDE: IDE controller on PCI bus 00 dev 39
Feb 23 21:24:32 conquest2 kernel: VP_IDE: chipset revision 16
[Note:
/sbin/hdparm -d1 -m16 /dev/hdb
/sbin/hdparm -d1 -m8 /dev/hda
in rc.local ]
Feb 23 21:24:23 conquest2 fsck: /dev/sda2: clean, 93394/1007616 files, 2263187/4025226
blocks
Feb 23 21:24:32 conquest2 kernel: VP_IDE: not 100%% native mode: will probe irqs later
Feb 23 21:24:23 conquest2 fsck: /dev/sdb4: clean, 144574/610304 files, 2089495/2436588
blocks
Feb 23 21:24:32 conquest2 kernel: ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
Feb 23 21:24:23 conquest2 fsck: /dev/hda3: clean, 1725/573440 files, 1335775/2288160
blocks
Feb 23 21:24:32 conquest2 kernel: VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller
on pci00:07.1
Feb 23 21:24:23 conquest2 fsck: /dev/hdb1: clean, 14322/4126720 files,
6507086/16506756 blocks
Feb 23 21:24:33 conquest2 kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS settings:
hda:DMA, hdb:DMA
Feb 23 21:24:23 conquest2 rc.sysinit: Checking filesystems succeeded
Feb 23 21:24:33 conquest2 kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS settings:
hdc:pio, hdd:pio
Feb 23 21:24:23 conquest2 rc.sysinit: Mounting local filesystems: succeeded
Feb 23 21:24:33 conquest2 kernel: hda: JTS Corporation CHAMPION MODEL C3000-3A, ATA
DISK drive
Feb 23 21:24:23 conquest2 rc.sysinit: Turning on user and group quotas for local
filesystems: succeeded
Feb 23 21:24:33 conquest2 kernel: hdb: IBM-DTTA-351680, ATA DISK drive
Feb 23 21:24:24 conquest2 rc.sysinit: Enabling swap space: succeeded
Feb 23 21:24:33 conquest2 kernel: hdc: CRD-8160B, ATAPI CD/DVD-ROM drive
Feb 23 21:24:26 conquest2 init: Entering runlevel: 3
Feb 23 21:24:33 conquest2 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Feb 23 21:24:26 conquest2 rc: Starting hotplug: succeeded
Feb 23 21:24:33 conquest2 kernel: ide1 at 0x170-0x177,0x376 on irq 15
Feb 23 21:24:33 conquest2 kernel: hda: 5870592 sectors (3006 MB) w/256KiB Cache,
CHS=5824/16/63, DMA
Feb 23 21:24:34 conquest2 kernel: hdb: 33022080 sectors (16907 MB) w/462KiB Cache,
CHS=2055/255/63, UDMA(33)
The first errors logged (later) involved /dev/sda2. Scsi driver init messages:-
Feb 23 21:24:34 conquest2 kernel: sym53c8xx: at PCI bus 0, device 15, function 0Feb 23
21:24:34 conquest2 kernel: sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
Feb 23 21:24:35 conquest2 kernel: sym53c8xx: 53c875 detected
Feb 23 21:24:35 conquest2 kernel: sym53c875-0: rev 0x3 on pci bus 0 device 15 function
0 irq 11
Feb 23 21:24:35 conquest2 kernel: sym53c875-0: ID 7, Fast-20, Parity Checking
Feb 23 21:24:35 conquest2 kernel: sym53c875-0: on-chip RAM at 0xde002000
Feb 23 21:24:35 conquest2 kernel: sym53c875-0: restart (scsi reset).
Feb 23 21:24:35 conquest2 kernel: sym53c875-0: Downloading SCSI SCRIPTS.
Feb 23 21:24:35 conquest2 kernel: scsi0 : sym53c8xx - version 1.6b
Feb 23 21:24:35 conquest2 kernel: Vendor: IBM Model: DCAS-34330Rev:
S65A
Feb 23 21:24:35 conquest2 kernel: Type: Direct-Access ANSI
SCSI revision: 02
Feb 23 21:24:35 conquest2 kernel: Vendor: IBM Model: DCAS-34330W Rev:
S61A
Feb 23 21:24:35 conquest2 kernel: Type: Direct-Access ANSI
SCSI revision: 02
Feb 23 21:24:35 conquest2 kernel: sym53c875-0-<4,0>: tagged command queue depth set to
8
Feb 23 21:24:36 conquest2 kernel: sym53c875-0-<6,0>: tagged command queue depth set to
8
Feb 23 21:24:36 conquest2 kernel: Detected scsi disk sda at scsi0, channel 0, id 4,
lun 0
Feb 23 21:24:36 conquest2 kernel: Detected scsi disk sdb at scsi0, channel 0, id 6,
lun 0
Feb 23 21:24:36 conquest2 kernel: sym53c875-0-<4,0>: sync msgout: 1-3-1-c-10.
Feb 23 21:24:36 conquest2 kernel: sym53c875-0-<4,0>: sync msg in: 1-3-1-c-f.
Feb 23 21:24:36 conquest2 kernel: sym53c875-0-<4,0>: sync: per=12 scntl3=0x90
scntl4=0x0 ofs=15 fak=0 chg=0.
Feb 23 21:24:36 conquest2 kernel: sym53c875-0-<4,*>: FAST-20 SCSI 20.0 MB/s (50 ns,
offset 15)
Feb 23 21:24:36 conquest2 kernel: sym
2.4.2-ax2 / ac3 die silently
Hi ! I've experienced Oops with 2.4.x and all the 2.4.1-ac versions of the kernel. I've the same Oops with 2.4.2. With 2.4.2-ac2 and ac3 (I've not not tested ac1). I've no OOps but, in the same conditions, the system die silently ; without any message, nothing in the log and the magic keys not working. last time, this appended just after the message : ax25_sendmsh(): ulistd uses obsolete socket structure There is no problem at all with the 2.2 serie. -- Regards Jean-Luc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PCI: Setting latency timer of device 00:02.0 to 64
Hi, What does mean this message ? Why is the latency timer resetted ? PCI: Found IRQ 11 for device 00:02.0 PCI: Setting latency timer of device 00:02.0 to 64 from lspci : 00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03) (prog-if 10 [OHCI]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
