Re: 2.4.0-test9-pre8 on SPARC build failure
On Tue, Oct 03, 2000 at 10:41:57PM -0700, Dr. Kelsey Hudson wrote: > > Question is, is this still broken on -test9-final or did > > the fix Linus merged earlier today get rid of your problems? > > Let me try this and find out... ... > making dep... > > ::curses his SS20 for being so SLOW!:: > I need better than a 50MHz processor in this damn thing. :) Better yet, I > need a better machine! :) Got any donations? Just kidding. > > ...Ok...Making boot... > > Damn. A good 2 hours later and it looks as though the compile exited > cleanly :) yaaay! > > The answer to your question is yes, the fix Linus put in today fixed the > problem :) This does tell nothing if the pcibios thing is fixed or not, because you most probably did not configure PCI on your sparc32 (why would you do that, when you don't have a JavaStation?). So you have to either look at the code or configure PCI in... Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre9 keyboard and mouse stopped working - deadlock?
Hi, I started a compile of kernel test9-final on a virtual console. (make bzImage modules modules_install) Then I started X on another one. Initial windows showed up fine. But mouse was stuck. Tried magic - nothing. (early in compile, should not be at modules_install for a long time) I noticed that disk led flashed now and then - decided to wait. After a while the xlock (really the kde one) started - did not react on keys (I had pressed magic-r earlier). Left it over night. Still no reaction to keyboard and mouse - RESET. Conclusion: - Probably not vm related since compilation probably continued in the background. /RogerL -- Home page: http://www.norran.net/nra02596/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kapmd cpu usage
My apologies to all on the list and Stephen. I should have thought before I typed. My concern was that this was a behavior that I had not previously seen in older 2.4.0pre or 2.2.x kernels... Once again, my apologies, Geoff This one time, at band camp, Stephen Rothwell wrote: > Hi Geoffrey, > > Geoffrey Gallaway <[EMAIL PROTECTED]> writes: > > in 2.4.0-test9, kampd is taking up between 70% and 80% of cpu usage on my > > Good! > > Seriously, the kapmd is doing the job of yje idle loop. The processor > is almost always asleep, but the time just gets accounted to kapmd. > > Cheers, > Stephen > -- Geoffrey Gallaway || Be wary when walking down the path to madness, all such [EMAIL PROTECTED] || paths invariably lead to madness. D e v o r z h u n || - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8 on SPARC build failure
> Question is, is this still broken on -test9-final or did > the fix Linus merged earlier today get rid of your problems? Let me try this and find out... Hmm. I get an error when trying to run 'make xconfig': gmake[1]: Entering directory `/usr/src/linux-2.4.0-test9/scripts' cat header.tk >> ./kconfig.tk ./tkparse < ../arch/sparc/config.in >> kconfig.tk -: 97: unknown command gmake[1]: *** [kconfig.tk] Error 1 OK, Big deal. I'll use menuconfig. That seems to work... making dep... ::curses his SS20 for being so SLOW!:: I need better than a 50MHz processor in this damn thing. :) Better yet, I need a better machine! :) Got any donations? Just kidding. ...Ok...Making boot... Damn. A good 2 hours later and it looks as though the compile exited cleanly :) yaaay! The answer to your question is yes, the fix Linus put in today fixed the problem :) Talk to you later, Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why does everyone hate gcc 2.95?
On Tue, 3 Oct 2000, Larry McVoy wrote: > hand picked tests. No faster. Just compiles slower. Add to that > some distributions BRAINDEAD default of havving colorgcc be the default > compiler (can you say fork perl to fork gcc? Can you say STUPID?), and ITYM "cute". As in "cute dancing paperclip". As colourized ls. Or rm aliased to rm -i for root. Or 31337 cAp1tAl1z3d directory names in root. Or manpages in HTML (yes, today I had to touch Slowlaris too, why are you asking?) Or info crap verbose as "War and Peace" instead of manpages. Or --ignore-fail-on-non-empty as rmdir option. Or "let's replace config files with directories full of one-liners since packagers can't be arsed to learn sed(1)" religion. Sigh... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9USB related oops
On Wed, Oct 04, 2000 at 07:55:33AM +0200, FORT David wrote: > > To be noted: my kernel is compiled with "Enforce USB bandwidth allocation", This is a known bug that just showed up (see the linux-usb-devel list for Randy Dunlap's message about this http://www.geocrawler.com/lists/3/SourceForge/2571/0/4441199/ ) Try turning off the bandwidth stuff, and trying the other UHCI driver. greg k-h -- greg@(kroah|wirex).com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why does everyone hate gcc 2.95?
On Wed, Oct 04, 2000 at 04:28:41AM +, John Anthony Kazos Jr. wrote: > What does everyone have against gcc 2.95 on this list? I've been > compiling kernels successfully (read: not one single (ever) error > in compilation) with gcc 2.95.2 for more than a year now. What's the > big deal? [Fix your mail program to put in carriage returns at 72 columns, please] I hate it because it compiles much more slowly than 2.72 and for my purposes, at least, the resulting code is not any faster on any of the following platforms: x86, SPARC, MIPS, PA-RISC, and Alpha. I ran a bunch of tests with both on the BitKeeper source base, about 100K lines of code or so, and then ran the regressions as well as some hand picked tests. No faster. Just compiles slower. Add to that some distributions BRAINDEAD default of havving colorgcc be the default compiler (can you say fork perl to fork gcc? Can you say STUPID?), and you start to understand why the first thing I do is remove all that garbage and put back a reasonable compiler. I'm not impressed. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kapmd cpu usage
Hi Geoffrey, Geoffrey Gallaway <[EMAIL PROTECTED]> writes: > in 2.4.0-test9, kampd is taking up between 70% and 80% of cpu usage on my Good! Seriously, the kapmd is doing the job of yje idle loop. The processor is almost always asleep, but the time just gets accounted to kapmd. Cheers, Stephen -- Stephen Rothwell, Open Source Researcher, Linuxcare, Inc. +61-2-62628990 tel, +61-2-62628991 fax [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Support for the revolution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kapmd cpu usage
in 2.4.0-test9, kampd is taking up between 70% and 80% of cpu usage on my Celeon 300A box. This is a fresly compiled kernel, Ill list some stats: Celeron 300A Asus Motherboard 64 Megs ram APM enabled in BIOS Ne2000 ethernet card S3 PCI video card This is based on a redhat 6.2.. Any ideas? I'll be happy to do as much as I can to give whoever needs it better errors (files in /proc, better description of problem, etc). Just let me know... Geoff -- Geoffrey Gallaway || What kills you makes me stronger. [EMAIL PROTECTED] || D e v o r z h u n || - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9USB related oops
Got the foolowing oops with a Trust Sp@ce C@m USB webcam, sensor is a
ov720 and it uses the ov511 driver. To reproduce it i open a netscape
on a page which grab pictures from the web-cam, as soon as grabbing starts
got the oops on serial console:
ksymoops 2.3.4 on i686 2.4.0-test9. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test9/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Unable to handle kernel NULL pointer dereference at virtual address 00a0
c8c8165d
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210246
eax: ebx: c2a08980 ecx: edx: 006b
esi: c2a08980 edi: c7e3b8bc ebp: esp: c022ff0c
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c022f000)
Stack: c6de32c8 c8c92814 c2a08980 0001 c6de32c8 c7e3b8a0 c7e3b8bc
0001 c8c929b5 c7e3b8a0 c2a08988 c4552700 0401
000a c002 c010be71 000a c7e3b8a0 c022ffa8 c0282260
Call Trace: [] [] [] [] []
[] []
[] [] [] [] [] []
[]
Code: 8b 91 a0 00 00 00 8b 43 30 29 42 28 83 7c 24 10 00 74 10 8b
>>EIP; c8c8165d <[usbcore]usb_release_bandwidth+9/60> <=
Trace; c8c92814 <[usb-uhci]process_urb+d4/1ec>
Trace; c8c929b5 <[usb-uhci]uhci_interrupt+89/e0>
Trace; c010be71
Trace; c010c056
Trace; c0108960
Trace; c0108960
Trace; c010a7c0
Trace; c0108960
Trace; c0108960
Trace; c0100018
Trace; c010898d
Trace; c01089f2
Trace; c0105000
Trace; c01001d0
Code; c8c8165d <[usbcore]usb_release_bandwidth+9/60>
<_EIP>:
Code; c8c8165d <[usbcore]usb_release_bandwidth+9/60> <=
0: 8b 91 a0 00 00 00 mov0xa0(%ecx),%edx <=
Code; c8c81663 <[usbcore]usb_release_bandwidth+f/60>
6: 8b 43 30 mov0x30(%ebx),%eax
Code; c8c81666 <[usbcore]usb_release_bandwidth+12/60>
9: 29 42 28 sub%eax,0x28(%edx)
Code; c8c81669 <[usbcore]usb_release_bandwidth+15/60>
c: 83 7c 24 10 00cmpl $0x0,0x10(%esp,1)
Code; c8c8166e <[usbcore]usb_release_bandwidth+1a/60>
11: 74 10 je 23 <_EIP+0x23> c8c81680
<[usbcore]usb_release_bandwidth+2c/60>
Code; c8c81670 <[usbcore]usb_release_bandwidth+1c/60>
13: 8b 00 mov(%eax),%eax
Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
1 warning issued. Results may not be reliable.
To be noted: my kernel is compiled with "Enforce USB bandwidth allocation",
I 'll without to see if it changes. When the webcam is unplugged everythings
goes right At least for now.
--
%--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
% FORT David, %
% 7 avenue de la morvandière 0240726275 %
% 44470 Thouare, France[EMAIL PROTECTED] %
% ICU:78064991 AIM: enlighted popo [EMAIL PROTECTED] %
%--LINUX-HTTPD-PIOGENE%
% -datamining <-/| .~. %
% -networking/flashed PHP3 coming soon | /V\L I N U X%
% -opensource| // \\ >Fear the Penguin< %
% -GNOME/enlightenment/GIMP | /( )\ %
% feel enlighted| ^^-^^%
% http://ibonneace.dyndns.org/ when connected %
%-%
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Why does everyone hate gcc 2.95?
What does everyone have against gcc 2.95 on this list? I've been compiling kernels successfully (read: not one single (ever) error in compilation) with gcc 2.95.2 for more than a year now. What's the big deal? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
acquiring resources shared or exclusive
I have a rudimentary question as I'm new to the Linux kernel. Is there a resource that can be acquired shared so that multiple threads can read data from a protected region and not block each other? It seems that the semaphore in the Linux kernel is only exclusively acquirable. I need to be able to share read access from several threads to some global structures and don't want them to block. I do want blocking whenever I have to modify the structures though. Thus I'm looking for a way to perform synchronization for reads (shared) and writes (exclusively) in the kernel. I assume it can be done it's just that I'm not sure how to do it yet. This is probably a very easy question. Thanks in advance. --- Jerry Kelley [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: warning message posted from apic.h
Jakub Jelinek <[EMAIL PROTECTED]> said: > Yes, this one is apic.h bug which RHL 7 cpp warns about: > > --- linux/include/asm-i386/apic.h.jj Mon Oct 2 20:01:18 2000 > +++ linux/include/asm-i386/apic.h Tue Oct 3 23:50:33 2000 > @@ -10,7 +10,7 @@ > #ifdef CONFIG_X86_LOCAL_APIC > > #if APIC_DEBUG > -#define Dprintk(x...) printk(##x) > +#define Dprintk(x...) printk(x) > #else > #define Dprintk(x...) > #endif Are you sure gcc-2.7.2.3 (still the recommended compiler for 2.4.0-test9!) handles this right? egcs-1.1.2 (RH kgcc) and RH gcc-2.96 do, just checked. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: one-line umount patch needed for am-utils
On Tue, 3 Oct 2000, Ion Badulescu wrote: > On Tue, 3 Oct 2000, Alexander Viro wrote: > > > On 2.4 you can do them directly - no intermediate filesystem > > needed. mount() with MS_BIND in flags will do the thing quite fine > > (mount(old_dir,new_dir,NULL,MS_BIND,NULL); or mount --bind $old_dir > > $new_dir; notices that old_dir doesn't have to be a root of any filesystem > > - any existing directory will be fine). Essentially, that's "symlinks done > > right". > > I know about the bind-mounting, but it doesn't make a significant > difference in this case. There is still a need for a "trigger" symlink > that causes amd to mount the remote filesystem. Nope. Doesn't have to be a symlink - it can be a directory. Overmounted by bind-mount - you can mount over a mountpoint. > Autofs is a totally different thing, and am-utils-6.1 does support autofs, > and it will also support bind-mounting on linux-2.4. However, autofs > doesn't support direct mounts, at least for the time being. > > > It's kind of silly and an abuse of the VFS, I agree. Unfortunately, it's > > > been around for a while, it works on other systems and real people are > > > using it. And they get a nasty surprise when they try it on Linux: the > > > amd-provided NFS filesystems cannot be unmounted, because the VFS umount > > > code follows the root symlink. > > > > So fix amd and teach it not to do that. > > Can't do that. As I said, there are real people using this feature out > there, it cannot be removed. I know what you're thinking, emulate direct > mounts using indirect mounts (and/or autofs). It's possible, but not > without system administrator support, because amd then needs a third > directory in the namespace to support the indirect mounts, whose name has > not been provided and which cannot simply appear out of the blue. Indeed it doesn't. Replace symlinks with directories and make e.g. revalidation to trigger mount --bind. > Besides, amd issues aside, can you point to something in the NFS spec that > says such a filesystem is illegal? If not, than the current Linux behavior > is buggy, because it allow mounting a filesystem which cannot then be > unmounted. Oh, that I agree with - we probably shouldn't allow such mounts in the first place (non-directories and directories shouldn't turn into each other). > > Last time I've touched 2.2 VFS was long ago. And 2.4 doesn't need that - > > there's much better mechanism for the same thing. E.g. you get correct > > behaviour of ".." in the root of bound subtree - it goes to parent > > of new_dir, instead of the parent of old_dir (as it would be with > > symlinks). See below: > [example trimmed] > > I fail to see how this is relevant to the problem at hand.. maybe I'm just > dense, please enlighten me. :-) Umm... Works as symlink minus several bogus details associated with the latter? > Don't forget that linux 2.2 is the proposed beneficiary of the patch.. > So, to get back on-topic, can you think of a case when doing > lnamei() instead of namei() on the mountpoint could break things? Not much - I'ld check do_follow_mount() and neighbors, though (watch for assumptions re directory vs. non-directory in the lookup_dentry() and other places using ->d_covers/->d_mounts). Again, the right thing for 2.4 is to do bind-mount instead of playing with symlinks. As for the autofs plans - ask HPA... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
I've allocated $20,000 US for this, but i doubt you will use all of it. Linux IP issues affect all of us since we ship Linux, so I am happy to pick up the tab. Tux is hot stuff, and we plan to use it, along with all the other great Linux stuff. Consider it our part to help Linux. The structure of TRG is modeled a lot like Microsoft -- we are actually a law firm thinly disguised as a software company (just like MS) snicker... snicker :-) Jeff Daniel Phillips wrote: > > Daniel Phillips wrote: > > Can I ask a stupid question: Who's paying for this? > > Err, like I said it was stupid. A better question is "why"? OK, you > don't have to answer. It's 4:20 am here, I should have been asleep long > ago, till tomorrow. > > -- > Daniel > "patents never sleep" > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: one-line umount patch needed for am-utils
On Tue, 3 Oct 2000, Alexander Viro wrote: > On 2.4 you can do them directly - no intermediate filesystem > needed. mount() with MS_BIND in flags will do the thing quite fine > (mount(old_dir,new_dir,NULL,MS_BIND,NULL); or mount --bind $old_dir > $new_dir; notices that old_dir doesn't have to be a root of any filesystem > - any existing directory will be fine). Essentially, that's "symlinks done > right". I know about the bind-mounting, but it doesn't make a significant difference in this case. There is still a need for a "trigger" symlink that causes amd to mount the remote filesystem. Autofs is a totally different thing, and am-utils-6.1 does support autofs, and it will also support bind-mounting on linux-2.4. However, autofs doesn't support direct mounts, at least for the time being. > > It's kind of silly and an abuse of the VFS, I agree. Unfortunately, it's > > been around for a while, it works on other systems and real people are > > using it. And they get a nasty surprise when they try it on Linux: the > > amd-provided NFS filesystems cannot be unmounted, because the VFS umount > > code follows the root symlink. > > So fix amd and teach it not to do that. Can't do that. As I said, there are real people using this feature out there, it cannot be removed. I know what you're thinking, emulate direct mounts using indirect mounts (and/or autofs). It's possible, but not without system administrator support, because amd then needs a third directory in the namespace to support the indirect mounts, whose name has not been provided and which cannot simply appear out of the blue. Besides, amd issues aside, can you point to something in the NFS spec that says such a filesystem is illegal? If not, than the current Linux behavior is buggy, because it allow mounting a filesystem which cannot then be unmounted. > Last time I've touched 2.2 VFS was long ago. And 2.4 doesn't need that - > there's much better mechanism for the same thing. E.g. you get correct > behaviour of ".." in the root of bound subtree - it goes to parent > of new_dir, instead of the parent of old_dir (as it would be with > symlinks). See below: [example trimmed] I fail to see how this is relevant to the problem at hand.. maybe I'm just dense, please enlighten me. :-) Don't forget that linux 2.2 is the proposed beneficiary of the patch.. So, to get back on-topic, can you think of a case when doing lnamei() instead of namei() on the mountpoint could break things? Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
Daniel, Andrew is the candidate for Attorney General for the State of Utah, and informs he has has television and radio interviews all day tommorrow, but promised he would get on it late tommorrow afternoon and get back to you. :-) Jeff Daniel Phillips wrote: > > "Jeff V. Merkey" wrote: > > I've forwarded everything to Andrew ([EMAIL PROTECTED]). He will > > contact Malinkrodt and assign a patent attorney to work with you on > > this. Andy's direct line is 801-222-9635. Since the Linux Community is > > basically a "client" now, your communications with him will be > > priviledged. After the analysis is completed, if you agree, I will post > > the results back to the list. Call Andrew and give him your phone # so > > we have a way for the patent attorneys to get in touch. > > Thankyou. :-O > > I will need a little time to prepare a formal description of the > algorithm. A tutorial description is here: > > http://innominate.org/pipermail/tux2-dev/2000-September/11.html > > Can I ask a stupid question: Who's paying for this? > > -- > Daniel > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
Daniel Phillips wrote: > Can I ask a stupid question: Who's paying for this? Err, like I said it was stupid. A better question is "why"? OK, you don't have to answer. It's 4:20 am here, I should have been asleep long ago, till tomorrow. -- Daniel "patents never sleep" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
"Jeff V. Merkey" wrote: > I've forwarded everything to Andrew ([EMAIL PROTECTED]). He will > contact Malinkrodt and assign a patent attorney to work with you on > this. Andy's direct line is 801-222-9635. Since the Linux Community is > basically a "client" now, your communications with him will be > priviledged. After the analysis is completed, if you agree, I will post > the results back to the list. Call Andrew and give him your phone # so > we have a way for the patent attorneys to get in touch. Thankyou. :-O I will need a little time to prepare a formal description of the algorithm. A tutorial description is here: http://innominate.org/pipermail/tux2-dev/2000-September/11.html Can I ask a stupid question: Who's paying for this? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
Daniel, Sorry, this was directed to you about the phone number (Thomas can call as well if he has info). :-) Jeff "Jeff V. Merkey" wrote: > > I've forwarded everything to Andrew ([EMAIL PROTECTED]). He will > contact Malinkrodt and assign a patent attorney to work with you on > this. Andy's direct line is 801-222-9635. Since the Linux Community is > basically a "client" now, your communications with him will be > priviledged. After the analysis is completed, if you agree, I will post > the results back to the list. Call Andrew and give him your phone # so > we have a way for the patent attorneys to get in touch. > > :-) > > Jeff > > Thomas Davis wrote: > > > > Daniel Phillips wrote: > > > > > > "Jeff V. Merkey" wrote: > > > > I am having Andrew McCullough review these patents to determine if there > > > > are any infringement issues that may affect us. Whomever is concerned > > > > her, if it would not be too much trouble, please forward what > > > > documentation and patent no.'s to [EMAIL PROTECTED] and copy me at > > > > [EMAIL PROTECTED] and we will forward them to Malinkrodt & > > > > Malinkrodt in Salt Lake City. I'll pay them to do a patent infringment > > > > analysis, and post their analysis to interested/affected parties. > > > > > > >http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1=HITOFF=PALL=1=/netahtml/srchnum.htm=1=G=50='5819292'.WKU.=PN/5819292=PN/5819292 > > > > > > >http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1=HITOFF=PALL=1=/netahtml/srchnum.htm=1=G=50='5963962'.WKU.=PN/5963962=PN/5963962 > > > > > > >http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO2=HITOFF=/netahtml/search-adv.htm=1=G=50=PALL=1=6038570=6038570=6038570 > > > > > > I suppose you will need a formal description of my algorithm. > > > > > > > You probably also want to add > > http://www.patents.ibm.com/details?pn=US06049528__ for the bonding > > driver.. Since it's already in the kernel, and prior work can be > > demonstrated also. > > > > -- > > +-- > > Thomas Davis| PDSF Project Leader > > [EMAIL PROTECTED] | > > (510) 486-4524 | "Only a petabyte of data this year?" > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-2.2] Bonding Driver Enhancements + Security fix
Hello Thomas, I've modified the slaves lists as you suggested to me. The more I tried to optimize the code, the more it looked like 2.4's, so it seems the last one is already optimal. There's no slave_queue anymore, and the transmit path in bond_xmit_roundrobin is far faster. I have also implemented a second xmit method : active-backup : instead of alternating on the slaves, it always emits on the same until its link fails, then it chooses the next good one. This way, there's only one active device at a time, and backup links are still monitored. This is very useful for high availability with 2 switches (one link to each one). Of course, I tried to make all the backup slaves deaf and for that I set their NO_ARP flag, to prevent the switches from seeing the interface at two different places. This may not be enough, but I'll try this tomorrow on my 2 alteon. So for now, there are two xmit methods : - round robin (default, or mode=0) - active-backup (mode=1) the mode argument should be given to modprobe when loading the driver as a module. For the MII link monitoring, I've set the default to disable checking, to avoid any potential breaking of existing installations. To activate it, simply pass "miimon=XXX" where XXX is the check interval in milliseconds. At 10ms (one check at each jiffy), my mouse becomes a bit "jumpy", but 100ms is quite good. I wanted to write some doc, but I will do tomorrow if I can find some spare time. It's too late for me to write something correct and I must get up in 3 hours. But I've included your Configure.help patch. So for this night, here's my patch against 2.2.17 (should be OK for 2.2.18pre15). I'd like several people to stress-test it. > See this: http://docs.sun.com:80/ab2/coll.539.1/UGTRUNKING/@Ab2PageView/1311?Ab2Lang=C=iso-8859-1 > > for information on the 4 possible trunking > transmittors. Thanks a lot, I will take a look. Willy ___ Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, Yahoo! Messenger : http://fr.messenger.yahoo.com patch-bonding-20001004-2.2.17.gz
Re: Tux2 - evil patents sighted
Daniel Phillips wrote: > > "Jeff V. Merkey" wrote: > > I am having Andrew McCullough review these patents to determine if there > > are any infringement issues that may affect us. Whomever is concerned > > her, if it would not be too much trouble, please forward what > > documentation and patent no.'s to [EMAIL PROTECTED] and copy me at > > [EMAIL PROTECTED] and we will forward them to Malinkrodt & > > Malinkrodt in Salt Lake City. I'll pay them to do a patent infringment > > analysis, and post their analysis to interested/affected parties. > > >http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1=HITOFF=PALL=1=/netahtml/srchnum.htm=1=G=50='5819292'.WKU.=PN/5819292=PN/5819292 > > >http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1=HITOFF=PALL=1=/netahtml/srchnum.htm=1=G=50='5963962'.WKU.=PN/5963962=PN/5963962 > > >http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO2=HITOFF=/netahtml/search-adv.htm=1=G=50=PALL=1=6038570=6038570=6038570 > > I suppose you will need a formal description of my algorithm. > You probably also want to add http://www.patents.ibm.com/details?pn=US06049528__ for the bonding driver.. Since it's already in the kernel, and prior work can be demonstrated also. -- +-- Thomas Davis| PDSF Project Leader [EMAIL PROTECTED] | (510) 486-4524 | "Only a petabyte of data this year?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] Make linux logo centered, add margins, etc. for 2.2.1 7
(This is an improved version of my earlier patch to linux-2.2.17. Thanks
are
due to Mohammad A. Haque and Even Jeffrey who gave me helpful tips on my
first
attempt. This version should correctly handle multiple CPUs.)
The patch adds an option to display a single, horizontally centered logo
with
optional vertical margins (LOGO_MARGIN), when framebuffer support is
compiled into the kernel, and an appropriate VGA= parameter is supplied.
This option is enabled by defining LOGO_CENTERED.
If LOGO_CENTERED is not defined, one logo will be shown for each CPU,
starting
from the left, (as the current code does) but still adding the margins above
and below.
Either way, the boot console displays in the remaining space. As before,
all
80x80 pixel restrictions on the logo size are removed, and the definitions
of
the logo size are moved to linux_logo.h so changing the logo only requires
changes to the single header file.
If you want to use this patch but keep the existing behavior, leave
LOGO_CENTERED
undefined and set all definitions of LOGO_MARGIN to 0.
Note: The _existing_ problem of what happens when (LOGO_W * smp_num_cpus) is
greater than the horizontal screen resolution has not been addressed.
For more information on this patch, see my first posting to this thread.
Please
let me know of bugs or problems - all I can really say is "it works for me",
and
it's pretty simple patch, so it should be ok.
Thanks.
Torrey Hoffman.
diff -u -r -x *.o -x *.flags -x *.depend -x *.config
linux-2.2.17/drivers/video/fbcon.c linux/drivers/video/fbcon.c
--- linux-2.2.17/drivers/video/fbcon.c Mon Sep 4 10:39:22 2000
+++ linux/drivers/video/fbcon.c Tue Oct 3 11:25:34 2000
@@ -31,6 +31,9 @@
*
* Random hacking by Martin Mares <[EMAIL PROTECTED]>
*
+ * Small changes for arbitrary size, optionally centered logos with
margins,
+ * cleanup so all logo size and positioning options are in linux_logo.h
+ * by Torrey Hoffman ([EMAIL PROTECTED]).
*
* The low level operations for the various display memory organizations
are
* now in separate source files.
@@ -107,8 +110,6 @@
# define DPRINTK(fmt, args...)
#endif
-#define LOGO_H 80
-#define LOGO_W 80
#define LOGO_LINE (LOGO_W/8)
struct display fb_display[MAX_NR_CONSOLES];
@@ -522,7 +523,7 @@
int cnt;
int step;
- logo_lines = (LOGO_H + fontheight(p) - 1) / fontheight(p);
+ logo_lines = (LOGO_H + LOGO_MARGIN + LOGO_MARGIN + fontheight(p) -
1) / fontheight(p);
q = (unsigned short *)(conp->vc_origin + conp->vc_size_row *
old_rows);
step = logo_lines * old_cols;
for (r = q - logo_lines * old_cols; r < q; r++)
@@ -2013,9 +2014,14 @@
if (p->fb_info->fbops->fb_rasterimg)
p->fb_info->fbops->fb_rasterimg(p->fb_info, 1);
+#if defined(LOGO_CENTERED)
+if (1) {
+ x = (p->var.xres - LOGO_W) / 2;
+#else
for (x = 0; x < smp_num_cpus * (LOGO_W + 8) &&
x < p->var.xres - (LOGO_W + 8); x += (LOGO_W + 8)) {
-
+#endif
+
#if defined(CONFIG_FBCON_CFB16) || defined(CONFIG_FBCON_CFB24) || \
defined(CONFIG_FBCON_CFB32) || defined(CONFIG_FB_SBUS)
if (p->visual == FB_VISUAL_DIRECTCOLOR) {
@@ -2032,7 +2038,7 @@
/* have at least 8 bits per color */
src = logo;
bdepth = depth/8;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = LOGO_MARGIN; y1 < LOGO_H + LOGO_MARGIN; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
val = (*src << redshift) |
@@ -2058,7 +2064,7 @@
unsigned int pix;
src = linux_logo16;
bdepth = (depth+7)/8;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = LOGO_MARGIN; y1 < LOGO_H + LOGO_MARGIN; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 < LOGO_W/2; x1++, src++ ) {
pix = (*src >> 4) | 0x10; /* upper nibble */
@@ -2106,12 +2112,13 @@
blueshift = p->var.blue.offset - (8-p->var.blue.length);
src = logo;
- for( y1 = 0; y1 < LOGO_H; y1++ ) {
+ for( y1 = LOGO_MARGIN; y1 < LOGO_H + LOGO_MARGIN; y1++ ) {
dst = fb + y1*line + x*bdepth;
for( x1 = 0; x1 < LOGO_W; x1++, src++ ) {
val = safe_shift((linux_logo_red[*src-32] & redmask),
redshift) |
safe_shift((linux_logo_green[*src-32] &
greenmask), greenshift) |
safe_shift((linux_logo_blue[*src-32] & bluemask),
blueshift);
+
if (bdepth == 4 && !((long)dst & 3)) {
/* Some cards require 32bit access */
*(u32 *)dst = val;
@@ -2132,7 +2139,7 @@
#if defined(CONFIG_FBCON_CFB4)
if (depth == 4 && p->type ==
user-mode port 0.32-2.4.0-test9
The user-mode port of 2.4.0-test9 is available. The bug that caused bash to occasionally segfault on address 0 was fixed. I also went on a breakpoint-fixing binge. The problems caused by the kernel debugger hitting breakpoints are fixed. Also, gdb no longer panics the kernel when it hits a breakpoint. Both the kernel debugger and gdb now seem to work well. Bill Stearns produced a number of new bootable filesystems, including Red Hat 7.0, Mandrake 7.1, and Immunix 6.2. These are available from the project's download page. The project's home page is http://user-mode-linux.sourceforge.net The project's download page is http://sourceforge.net/project/filelist.php?grou p_id=429 Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
"Jeff V. Merkey" wrote: > I am having Andrew McCullough review these patents to determine if there > are any infringement issues that may affect us. Whomever is concerned > her, if it would not be too much trouble, please forward what > documentation and patent no.'s to [EMAIL PROTECTED] and copy me at > [EMAIL PROTECTED] and we will forward them to Malinkrodt & > Malinkrodt in Salt Lake City. I'll pay them to do a patent infringment > analysis, and post their analysis to interested/affected parties. http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1=HITOFF=PALL=1=/netahtml/srchnum.htm=1=G=50='5819292'.WKU.=PN/5819292=PN/5819292 http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1=HITOFF=PALL=1=/netahtml/srchnum.htm=1=G=50='5963962'.WKU.=PN/5963962=PN/5963962 http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO2=HITOFF=/netahtml/search-adv.htm=1=G=50=PALL=1=6038570=6038570=6038570 I suppose you will need a formal description of my algorithm. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 32-bit pid_t / security
> > S/390 folks run 70,000 sessions active within the same 60 second period off > one big box. Not on Linux (yet ;)) but its worth bearing in mind. Yes, but they don't do it with 7 separate processes (or "address spaces" to use the 390 terminology). They have a few processes/address spaces accepting a transaction, processing it, and spitting out the result. (Or, in some cases, accepting a transaction, processing it, issuing an async disk I/O requerst, and then doing another transaction while the first disk I/O waits). (Think of, say, a Web Server, which might be providing service for thousands of simultaneous clients, with just a relative handfull of web server daemon processes running.) I don't think 7 Unix login users, or 7 TSO users, or 7 processes/address spaces of any kind, would fly. Not that I have a problem with 32 bit process IDs. -- Brett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Why does test9 outlaw HZ < 48?
UML has HZ == 20. When I built test9, I ran into trouble with this new block in include/linux/timex.h: #if HZ >= 24 && HZ < 48 # define SHIFT_HZ 5 #elif HZ >= 48 && HZ < 96 # define SHIFT_HZ 6 ... I added the obvious 12 <= HZ < 24 lines and got this from kernel/timer.c: timer.c:446: warning: right shift count is negative timer.c:449: warning: right shift count is negative Those lines are these: time_adj -= -ltemp >> (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE); time_adj += ltemp >> (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE); When you chase down the constants (the others are in timex.h, too), the shift value turns out to be: 16 + SHIFT_HZ - 22 16 + SHIFT_HZ - 22 >= 0 implies SHIFT_HZ >= 6. Now, my questions are: What's the reasoning behind these magic numbers? The comment associated with those constants is less than illumunating IMHO. Is there anything wrong with HZ < 48? If not, what's the right way to get it without upsetting the compiler? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
I am having Andrew McCullough review these patents to determine if there
are any infringement issues that may affect us. Whomever is concerned
her, if it would not be too much trouble, please forward what
documentation and patent no.'s to [EMAIL PROTECTED] and copy me at
[EMAIL PROTECTED] and we will forward them to Malinkrodt &
Malinkrodt in Salt Lake City. I'll pay them to do a patent infringment
analysis, and post their analysis to interested/affected parties.
:-)
Jeff
"J. Dow" wrote:
>
> From: "Daniel Phillips" <[EMAIL PROTECTED]>
>
> > Yes, I know the game, Unisys played it with gif. Wait until it's in
> > widespread use then appear out of the woodwork and demand licence fees.
> > It's called submarining. It's evil. People and corporations who do it
> > are little better than thugs.
>
> This one is a bad example, Daniel. The word from inside UniSys is that
> this was pure ineptitude in action.
> {o.o}
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: one-line umount patch needed for am-utils
On Tue, 3 Oct 2000, Ion Badulescu wrote: > Hi Alan, > > The patch included below allows the kernel to unmount a filesystem whose > root entry is a symlink. > > Let me give you a bit of background. In addition to more common 2-level > indirect mounts (also provided by autofs), amd allows for the so-called > "direct mounts". They are implemented by mounting an amd-provided NFS > filesystem with only one entry: the root "directory", which is in fact a > symlink. Upon readlink, amd mounts the real (remote) NFS filesystem > somewhere else and makes the symlink point to the real mountpoint. On 2.4 you can do them directly - no intermediate filesystem needed. mount() with MS_BIND in flags will do the thing quite fine (mount(old_dir,new_dir,NULL,MS_BIND,NULL); or mount --bind $old_dir $new_dir; notices that old_dir doesn't have to be a root of any filesystem - any existing directory will be fine). Essentially, that's "symlinks done right". > It's kind of silly and an abuse of the VFS, I agree. Unfortunately, it's > been around for a while, it works on other systems and real people are > using it. And they get a nasty surprise when they try it on Linux: the > amd-provided NFS filesystems cannot be unmounted, because the VFS umount > code follows the root symlink. So fix amd and teach it not to do that. > The patch fixes this by replacing the namei() in sys_umount with a > lnamei() which doesn't follow symlinks at the end of the chain. It has > been tested, and it does solve the amd problem. It does not break > anything else, at least in my testing, and the change makes sense. > > Al, I'm cc:-ing you because this is basically your turf. Please let us > know if you have any objections to the patch. The same change (different > code though) is also needed for 2.4, by the way. Last time I've touched 2.2 VFS was long ago. And 2.4 doesn't need that - there's much better mechanism for the same thing. E.g. you get correct behaviour of ".." in the root of bound subtree - it goes to parent of new_dir, instead of the parent of old_dir (as it would be with symlinks). See below: # mkdir /tmp/foo # mount --bind /usr/lib/gcc-lib /tmp/foo # ln -sf /usr/lib/gcc/lib /tmp/bar # ls -l /usr/lib/gcc-lib total 1 drwxr-xr-x4 root root 1024 Feb 23 2000 i386-linux # ls -l /tmp/foo/ total 1 drwxr-xr-x4 root root 1024 Feb 23 2000 i386-linux # ls -l /tmp/foo total 1 drwxr-xr-x4 root root 1024 Feb 23 2000 i386-linux # ls /tmp/foo/../.. bin cdrom etc homelib mnt root tmp var boot devfloppy initrd lost+found proc sbin usr vmlinuz # ls -l /tmp/bar/ total 1 drwxr-xr-x4 root root 1024 Feb 23 2000 i386-linux # ls -l /tmp/bar lrwxrwxrwx1 root root 17 Oct 3 21:45 /tmp/bar -> /usr/lib/gcc-lib/ # ls /tmp/bar/../.. X11R6 docinclude liblost+found sbin src bingames info local man share - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9-pre9 floppy not working on Alpha
Hi! since at least 2.4.0-test5 (the oldest kernel I have around) floppy support is broken on alpha. If I e.g. do od -c /dev/fd0 | more I get all sorts of weird stuff (parts of libc, directory contents, other binary data) but not the floppy's real contents. Mounting of floppies also doesn't work. The floppy drive and controller hardware is presumably ok since I currently sucessfully boot MILO from it. System is AXPpci33 'noname', onboard floppy controller gcc version 2.96 2925 (experimental) Linux kernel 2.4.0-9-9 (problem exists since at least 2.4.0-5) Does anbody else have this problem? Where can I start hunting this down? Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
"J. Dow" wrote:
>
> From: "Daniel Phillips" <[EMAIL PROTECTED]>
>
> > Yes, I know the game, Unisys played it with gif. Wait until it's in
> > widespread use then appear out of the woodwork and demand licence fees.
> > It's called submarining. It's evil. People and corporations who do it
> > are little better than thugs.
>
> This one is a bad example, Daniel. The word from inside UniSys is that
> this was pure ineptitude in action.
> {o.o}
I don't buy it. Sure, it might have started as ineptitude, but somebody
made the decision to stick it to everybody, and that turned it into a
submarine maneuver. They took advantage of the situation. They did not
take advantage of the opportunity to earn some good will and admit that
didn't properly advise the public of their intention to demand
royalties. They should have done the right thing and placed the patent
in the publilc domain because of their mistake. Instead they made their
name forever mud - I seriously doubt it was worth it.
Excuse me, the gif fiasco is well-known and everything useful that could
be said about it has already been said. I don't know why I even posted
this.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
From: "Daniel Phillips" <[EMAIL PROTECTED]>
> Yes, I know the game, Unisys played it with gif. Wait until it's in
> widespread use then appear out of the woodwork and demand licence fees.
> It's called submarining. It's evil. People and corporations who do it
> are little better than thugs.
This one is a bad example, Daniel. The word from inside UniSys is that
this was pure ineptitude in action.
{o.o}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8 on SPARC build failure
On Tue, 3 Oct 2000, Dr. Kelsey Hudson wrote: > > pcic.c: At top level: > > pcic.c:39: redefinition of `pcibios_present' > > /usr/src/linux-2.4.0-test/include/linux/pci.h:562: `pcibios_present' previously >defined here > > make[1]: *** [pcic.o] Error 1 > > make[1]: Leaving directory `/usr/src/linux-2.4.0-test/arch/sparc/kernel' > > make: *** [_dir_arch/sparc/kernel] Error 2 > > I can confirm this. Question is, is this still broken on -test9-final or did the fix Linus merged earlier today get rid of your problems? regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
one-line umount patch needed for am-utils
Hi Alan,
The patch included below allows the kernel to unmount a filesystem whose
root entry is a symlink.
Let me give you a bit of background. In addition to more common 2-level
indirect mounts (also provided by autofs), amd allows for the so-called
"direct mounts". They are implemented by mounting an amd-provided NFS
filesystem with only one entry: the root "directory", which is in fact a
symlink. Upon readlink, amd mounts the real (remote) NFS filesystem
somewhere else and makes the symlink point to the real mountpoint.
It's kind of silly and an abuse of the VFS, I agree. Unfortunately, it's
been around for a while, it works on other systems and real people are
using it. And they get a nasty surprise when they try it on Linux: the
amd-provided NFS filesystems cannot be unmounted, because the VFS umount
code follows the root symlink.
The patch fixes this by replacing the namei() in sys_umount with a
lnamei() which doesn't follow symlinks at the end of the chain. It has
been tested, and it does solve the amd problem. It does not break
anything else, at least in my testing, and the change makes sense.
Al, I'm cc:-ing you because this is basically your turf. Please let us
know if you have any objections to the patch. The same change (different
code though) is also needed for 2.4, by the way.
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
---
--- linux-2.2.17/fs/super.c.old Thu Sep 28 01:26:42 2000
+++ linux-2.2.17/fs/super.c Thu Sep 28 01:21:20 2000
@@ -782,7 +782,7 @@
return -EPERM;
lock_kernel();
- dentry = namei(name);
+ dentry = lnamei(name);
retval = PTR_ERR(dentry);
if (!IS_ERR(dentry)) {
struct inode * inode = dentry->d_inode;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
On Tue, 3 Oct 2000, Martin Diehl wrote: > On Tue, 3 Oct 2000, Rik van Riel wrote: > > On Tue, 3 Oct 2000, Martin Diehl wrote: > > > > > * deadlock in initscripts (even for runlevel 2). SysRq shows idle_task > > > being the only one ever getting the CPU when deadlocked. > > > > This suggests tasks yielding the CPU while task->state != > > TASK_RUNNABLE, which results in them never being rescheduled > > again ... > > Just tried 2.4.0-t9p8 + t9p8-vmpatch: No change here. Box > appears to hang upon "init 2" (or higher) when starting several > things (sendmail, xfs e.g.) with (according to SysRq+p) > idle_task being the only one R. Now that I think of it ... this could be a new (old?) case of a UP-only bug. Is anybody seeing this upon booting their SMP system with 'mem=8m' ?? (if it is, I know what to look for and how to fix them) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8 on SPARC build failure
> pcic.c: At top level: > pcic.c:39: redefinition of `pcibios_present' > /usr/src/linux-2.4.0-test/include/linux/pci.h:562: `pcibios_present' previously >defined here > make[1]: *** [pcic.o] Error 1 > make[1]: Leaving directory `/usr/src/linux-2.4.0-test/arch/sparc/kernel' > make: *** [_dir_arch/sparc/kernel] Error 2 I can confirm this. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MIME QP encoded good/bad ...
In article <[EMAIL PROTECTED]>, Matti Aarnio <[EMAIL PROTECTED]> wrote: > Yes Linus, ASCII is fine, but then the ENTIRE MESSAGE must be > in 7-bit ASCII only. A single 8-bit char anywhere makes worlds > of difference to the rules. (E.g. 8-bit char in .signature > may force QP encoding of the entire message.) So, what do you think of http://pobox.com/~djb/docs/8bit/06.txt http://pobox.com/~djb/docs/8bit/08.txt Mike "QP must die". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: warning message posted from apic.h
On Fri, Sep 29, 2000 at 11:09:33AM +, Stephen Torri wrote: > I get the following message compiling 2.4.0-test6 or test8 on a RedHat 7 > system. "/usr/src/linux/include/asm/apic.h:13:29: warning: nothing can be > posted after this token". Is this an issue with apic? Yes, this one is apic.h bug which RHL 7 cpp warns about: --- linux/include/asm-i386/apic.h.jj Mon Oct 2 20:01:18 2000 +++ linux/include/asm-i386/apic.h Tue Oct 3 23:50:33 2000 @@ -10,7 +10,7 @@ #ifdef CONFIG_X86_LOCAL_APIC #if APIC_DEBUG -#define Dprintk(x...) printk(##x) +#define Dprintk(x...) printk(x) #else #define Dprintk(x...) #endif Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
LOCKUP on CPU x
Hello everybody, I had several strange system hangs that are somehow related to CPU lockups. Strange enough that system works without problem under high load several days, than hungs up. Actualy system responds to ping (with usual times), but it is impossible neither to log in, nor to exchange data after binding to, for example, smtp port - system accepts connection, but is waiting for something... Swap is not used. When I hit magic SysRq+T sequence system crashed with: NMI Watchdog detected LOCKUP on CPU 1, registers CPU : 1 EIP : 0010: [] EFLAGS : 0097 eax : c0273420ebx : c029b820 ecx : c19ca000 edx : c0229d4cesi : dfb8b000edi: 0008 ebp : c19cbd88esp: c19cbd80 ds: 0018 es: 0018 ss: 0018 Process kreiserfsd (pid: 5, stackpage=c19c800) Stack: ... CallTrace: [] [] [] [] [c018b609] [] [] .. Note, that several times I have seen init process instead of kreiserfsd, but was unable to write down register dump. Also I include my boot'up dmesg, which has some in my opinion strange complains (take a look at BIOS warnings about CPU's, mtrr's and other cpu boot up info). System - 2.4.0-test7+reiserfs-3.6.14, SMP 2 PIII 500, Asus P2B-D motherboard, Symbios SYM53C8XX U2W controler, 3c905. --- Oct 3 14:41:15 cl1 kernel: klogd 1.3-3, log source = /proc/kmsg started. Oct 3 14:41:15 cl1 kernel: Inspecting /boot/System.map-2.4.0-test7-sym Oct 3 14:41:16 cl1 kernel: Loaded 13187 symbols from /boot/System.map-2.4.0-test7-sym. Oct 3 14:41:16 cl1 kernel: Symbols match kernel version 2.4.0. Oct 3 14:41:16 cl1 kernel: Loaded 10 symbols from 2 modules. Oct 3 14:41:16 cl1 kernel: Linux version 2.4.0-test7-sym (root@(none)) (gcc version 2.95.2 19991024 (release)) #2 SMP Fri Sep 29 18:32:51 CEST 2000 Oct 3 14:41:16 cl1 kernel: BIOS-provided physical RAM map: Oct 3 14:41:16 cl1 kernel: BIOS-e820: 0009f800 @ (usable) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 0800 @ 0009f800 (reserved) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 0001 @ 000f (reserved) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 00e0 @ 0010 (usable) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 0010 @ 00f0 (reserved) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 1effd000 @ 0100 (usable) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 2000 @ 1fffd000 (ACPI data) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 1000 @ 1000 (ACPI NVS) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 1000 @ fec0 (reserved) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 1000 @ fee0 (reserved) Oct 3 14:41:16 cl1 kernel: BIOS-e820: 0001 @ (reserved) Oct 3 14:41:16 cl1 kernel: Scan SMP from c000 for 1024 bytes. Oct 3 14:41:16 cl1 kernel: Scan SMP from c009fc00 for 1024 bytes. Oct 3 14:41:16 cl1 kernel: Scan SMP from c00f for 65536 bytes. Oct 3 14:41:16 cl1 kernel: found SMP MP-table at 000f6e80 Oct 3 14:41:16 cl1 kernel: hm, page 000f6000 reserved twice. Oct 3 14:41:16 cl1 kernel: hm, page 000f7000 reserved twice. Oct 3 14:41:16 cl1 kernel: hm, page 000f6000 reserved twice. Oct 3 14:41:16 cl1 kernel: hm, page 000f7000 reserved twice. Oct 3 14:41:16 cl1 kernel: On node 0 totalpages: 131069 Oct 3 14:41:16 cl1 kernel: zone(0): 4096 pages. Oct 3 14:41:16 cl1 kernel: zone(1): 126973 pages. Oct 3 14:41:16 cl1 kernel: zone(2): 0 pages. Oct 3 14:41:16 cl1 kernel: Intel MultiProcessor Specification v1.1 Oct 3 14:41:16 cl1 kernel: Virtual Wire compatibility mode. Oct 3 14:41:16 cl1 kernel: OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Oct 3 14:41:16 cl1 kernel: Processor #1 Pentium(tm) Pro APIC version 17 Oct 3 14:41:16 cl1 kernel: Floating point unit present. Oct 3 14:41:16 cl1 kernel: Machine Exception supported. Oct 3 14:41:16 cl1 kernel: 64 bit compare & exchange supported. Oct 3 14:41:16 cl1 kernel: Internal APIC present. Oct 3 14:41:16 cl1 kernel: Bootup CPU Oct 3 14:41:16 cl1 kernel: Processor #0 Pentium(tm) Pro APIC version 17 Oct 3 14:41:16 cl1 kernel: Floating point unit present. Oct 3 14:41:16 cl1 kernel: Machine Exception supported. Oct 3 14:41:16 cl1 kernel: 64 bit compare & exchange supported. Oct 3 14:41:16 cl1 kernel: Internal APIC present. Oct 3 14:41:16 cl1 kernel: Bus #0 is PCI Oct 3 14:41:16 cl1 kernel: Bus #1 is ISA Oct 3 14:41:16 cl1 kernel: I/O APIC #2 Version 17 at 0xFEC0. Oct 3 14:41:16 cl1 kernel: Int: type 3, pol 0, trig 0, bus 1, IRQ 00, APIC ID 2, APIC INT 00 Oct 3 14:41:16 cl1 kernel: Int: type 0, pol 0, trig 0, bus 1, IRQ 01, APIC ID 2, APIC INT 01 Oct 3 14:41:16 cl1 kernel: Int: type 0, pol 0, trig 0, bus 1, IRQ 00, APIC ID 2, APIC INT 02 Oct 3 14:41:16 cl1 kernel: Int: type 0, pol 0, trig 0, bus 1, IRQ 03, APIC ID 2, APIC INT 03 Oct 3 14:41:16 cl1 kernel: Int: type 0,
BUG : alloc_skb called nonatomically from interrupt
I am running Linux v2.4-test5 on MIPS (NEC DDB5476). I got the above run-time BUG report. See the call stack below. Can someone shed a light on this problem? Thanks. Jun -- reakpoint 2, alloc_skb (size=1531, gfp_mask=7) at skbuff.c:175 175 BUG(); (gdb) bt #0 alloc_skb (size=1531, gfp_mask=7) at skbuff.c:175 #1 0x8012ffc8 in sock_alloc_send_skb (sk=0x81179640, size=1531, fallback=0, noblock=60, errcode=0x811f3cd0) at sock.c:816 #2 0x80142308 in ip_build_xmit_slow (sk=0x81179640, getfrag=0x80158634 , frag=0x811f3d98, length=60, ipc=0x811f3d88, rt=0x811f71c0, flags=16448) at ip_output.c:555 #3 0x801427d4 in ip_build_xmit (sk=0x81179640, getfrag=0x80158634 , frag=0x811f3d98, length=4248, ipc=0x811f3d88, rt=0x811f71c0, flags=16448) at ip_output.c:687 #4 0x80158b88 in udp_sendmsg (sk=0x81179640, msg=0x811f3e50, len=4220) at udp.c:585 #5 0x8015f50c in inet_sendmsg (sock=0x801adf54, msg=0x811f3e50, size=4220, scm=0x3c) at af_inet.c:727 #6 0x8012d35c in sock_sendmsg (sock=0x8110a8b0, msg=0x811f3e50, size=4220) at socket.c:509 #7 0x8016dd1c in do_xprt_transmit (task=0x836a47c0) at xprt.c:215 #8 0x8016db6c in xprt_transmit (task=0x836a47c0) at xprt.c:1190 #9 0x8016b564 in call_transmit (task=0x836a47c0) at clnt.c:554 #10 0x8016f968 in __rpc_execute (task=0x836a47c0) at sched.c:574 #11 0x8016fde4 in __rpc_schedule () at sched.c:712 #12 0x801709d4 in rpciod (ptr=0x801adf54) at sched.c:1065 #13 0x8008c2f0 in kernel_thread (fn=0x80170810 , arg=0x801bb08c, flags=5) at process.c:158 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
On Tue, 3 Oct 2000, Rik van Riel wrote: > On Tue, 3 Oct 2000, Martin Diehl wrote: > > > * deadlock in initscripts (even for runlevel 2). SysRq shows idle_task > > being the only one ever getting the CPU when deadlocked. > > This suggests tasks yielding the CPU while task->state != > TASK_RUNNABLE, which results in them never being rescheduled > again ... Just tried 2.4.0-t9p8 + t9p8-vmpatch: No change here. Box appears to hang upon "init 2" (or higher) when starting several things (sendmail, xfs e.g.) with (according to SysRq+p) idle_task being the only one R. However, if I just wait for some 15 minutes or so it finally reaches the console login prompt - but I'm unable to login, since this seems to require the same duration, so the login timeout is killing me. Things seem to speed up, when *continously* pressing SysRq+[tpm]: Besides screen scrolling there is some minor disk activity, but always EIP in idle_task. Looks similar to what somebody else reported. Problem appeares for the first time when switching from vanilla t9p7 to t9p8+t9p[78]-vmpatch (Haven't tried vanilla t9p[89]). Will try 2.4.0-test9 (final). > (time to hunt down the rescheduling points) Willing to try the patch for this when available. Regards, Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Kernel config labelling
My vote for most humorous line in "make config": Ethertap network tap (OBSOLETE) (NEW) I think for clarity's sake we should probably just stick with (OBSOLETE). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ixj.c compile error in kernel 240-test9
Hi. When I compile drivers/telephony/ixj.c from the 2.4.0-test9 kernel I get the following: make[3]: Entering directory `/home/rasmus/kernel/linux/drivers/telephony' gcc -D__KERNEL__ -I/home/rasmus/kernel/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -march=i686 -fno-strict-aliasing-c -o ixj.o ixj.c ixj.c:5794: parse error before `dev_node_t' ixj.c:5794: warning: no semicolon at end of struct or union ixj.c:5795: `port' redeclared as different kind of symbol /home/rasmus/kernel/linux/include/linux/telephony.h:61: previous declaration of `port' ixj.c:5796: parse error before `}' ixj.c:5796: warning: type defaults to `int' in declaration of `ixj_info_t' ixj.c:5796: warning: data definition has no type or storage class ixj.c:5797: parse error before `*' ixj.c:5797: warning: type defaults to `int' in declaration of `ixj_attach' ixj.c:5797: warning: data definition has no type or storage class ixj.c:5798: parse error before `*' ixj.c:5798: warning: function declaration isn't a prototype ixj.c:5799: parse error before `*' ixj.c:5799: warning: function declaration isn't a prototype ixj.c:5801: parse error before `event' ixj.c:5801: warning: function declaration isn't a prototype ixj.c:5802: parse error before `dev_info' ixj.c:5802: warning: type defaults to `int' in declaration of `dev_info' ixj.c:5802: warning: initialization makes integer from pointer without a cast ixj.c:5802: warning: data definition has no type or storage class ixj.c:5803: parse error before `*' ixj.c:5803: warning: type defaults to `int' in declaration of `dev_list' ixj.c:5803: warning: data definition has no type or storage class ixj.c:5804: parse error before `handle' ixj.c:5805: warning: function declaration isn't a prototype ixj.c: In function `cs_error': ixj.c:5806: `error_info_t' undeclared (first use in this function) ixj.c:5806: (Each undeclared identifier is reported only once ixj.c:5806: for each function it appears in.) ixj.c:5806: parse error before `err' ixj.c: At top level: ixj.c:5810: parse error before `&' ixj.c:5810: warning: type defaults to `int' in declaration of `CardServices' ixj.c:5810: warning: function declaration isn't a prototype ixj.c:5810: warning: data definition has no type or storage class ixj.c:5813: parse error before `*' ixj.c:5814: warning: return-type defaults to `int' ixj.c: In function `ixj_attach': ixj.c:5815: `client_reg_t' undeclared (first use in this function) ixj.c:5815: parse error before `client_reg' ixj.c:5816: `dev_link_t' undeclared (first use in this function) ixj.c:5816: `link' undeclared (first use in this function) ixj.c:5816: warning: statement with no effect ixj.c:5817: parse error before `int' ixj.c:5820: sizeof applied to an incomplete type ixj.c:5821: sizeof applied to an incomplete type ixj.c:5821: sizeof applied to an incomplete type ixj.c:5821: sizeof applied to an incomplete type ixj.c:5821: sizeof applied to an incomplete type ixj.c:5821: sizeof applied to an incomplete type ixj.c:5821: sizeof applied to an incomplete type ixj.c:5824: `IO_DATA_PATH_WIDTH_8' undeclared (first use in this function) ixj.c:5828: `INT_MEMORY_AND_IO' undeclared (first use in this function) ixj.c:5829: sizeof applied to an incomplete type ixj.c:5830: sizeof applied to an incomplete type ixj.c:5830: sizeof applied to an incomplete type ixj.c:5830: sizeof applied to an incomplete type ixj.c:5830: sizeof applied to an incomplete type ixj.c:5830: sizeof applied to an incomplete type ixj.c:5830: sizeof applied to an incomplete type ixj.c:5834: `client_reg' undeclared (first use in this function) ixj.c:5835: `INFO_IO_CLIENT' undeclared (first use in this function) ixj.c:5835: `INFO_CARD_SHARE' undeclared (first use in this function) ixj.c:5837: `CS_EVENT_CARD_INSERTION' undeclared (first use in this function) ixj.c:5837: `CS_EVENT_CARD_REMOVAL' undeclared (first use in this function) ixj.c:5838: `CS_EVENT_RESET_PHYSICAL' undeclared (first use in this function) ixj.c:5838: `CS_EVENT_CARD_RESET' undeclared (first use in this function) ixj.c:5839: `CS_EVENT_PM_SUSPEND' undeclared (first use in this function) ixj.c:5839: `CS_EVENT_PM_RESUME' undeclared (first use in this function) ixj.c:5843: `ret' undeclared (first use in this function) ixj.c:5843: `RegisterClient' undeclared (first use in this function) ixj.c:5844: `CS_SUCCESS' undeclared (first use in this function) ixj.c: At top level: ixj.c:5852: parse error before `*' ixj.c:5853: warning: function declaration isn't a prototype ixj.c: In function `ixj_detach': ixj.c:5854: `dev_link_t' undeclared (first use in this function) ixj.c:5854: `linkp' undeclared (first use in this function) ixj.c:5854: warning: statement with no effect ixj.c:5855: parse error before `long' ixj.c:5859: `link' undeclared (first use in this function) ixj.c:5863: `flags' undeclared (first use in this function) ixj.c:5865: `DEV_RELEASE_PENDING' undeclared (first use in this function) ixj.c:5870: `DEV_CONFIG' undeclared (first use in this function)
Re: Update Linux 2.4 Status/TODO list
[EMAIL PROTECTED] wrote: The bug about loopback devices is still not fixed, but this document says it is. This hangs linux-2.4.0.test9 (only tested with Pentium II. Noname SMP and a Dell.) dd if=/dev/zero of=/tmp/dos.img bs=64k count=1 # a lot more the viritual memory avail mkdosfs /tmp/dos.img mount -o loop /tmp/dos.img /mnt/dos dd if=/dev/zero of=/mnt/dos/bigfile.empty OK, here's the updated Linux 2.4 bug list. I let myself get a bit behind, so it took me a while to process through all of my backlogged l-k mail archives to assemble this list. As always, it's complete as I can make it, but it's not perfect. In particualar, some bugs listed on this page may have been fixed already. If so, or if you know some bug that didn't make on to this list, please let me know. For people who are wondering what changed, the differences from the last major release of this page can be found at http://linux24.sourceforge.net/status-changes.html As always, if you're curious what state this document is in, you can always get the latest copy by going to: http://linux24.sourceforge.net - Ted Linux 2.4 Status/TODO Page Last modified: [tytso:2913.0151EDT] Hopefully up to date as of: test8 1. Should Be Fixed (Confirmation Wanted) * Fbcon races (cursor problems when running continual streaming output mixed with printk + races when switching from X while doing continuous rapid printing --- Alan) 2. Capable Of Corrupting Your FS/data * Use PCI DMA by default in IDE is unsafe (must not do so on via VPx, x < 3) (requires chipset tuning to be enabled according to Andre Hedrick --- we need to turn this on by default -- TYT) * Fix the OOPS in usb-storage from the error-recovery handler. (reported by Matthew Dharm) * Non-atomic page-map operations can cause loss of dirty bit on pages (sct, alan) 3. Security * Fix module remove race bug (still to be done: TTY, ldisc, I2C, video_device - Al Viro) (Rogier Wolff will handle ATM) 4. Boot Time Failures * Use PCI DMA 'lost interrupt' problem with some hw [which ?] (NEC Versa LX with PIIX tuning) * HT6560/UMC8672 ide sets up stuff too early (before region stuff can be done) * Crashes on boot on some Compaqs ? (may be fixed) * Boot hangs on a range of Dell docking stations (Latitude) + Almost certainly related: PCI code doesn't see devices behind DECchip 21150 PCI bridges (used in Dell Latitude). Reported by Simon Trimmer . (Patch from Martin Mares exists but it disables cardbus devices, according to Tigran.) + Derek Fawcus at Cisco reports similar problems with Toshiba Tecra 8000 attached to the DeskStation V+ docking station. (once again, caused by bridge returning 0 when reading the I/O base/limit and Memory base/limit registers which confuses the new PCI resource code). * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for more info) 5. Compile errors * arcnet/com20020-isa.c doesn't compile, as of 2.4.0-test8. Dan Aloni has a fix * drivers/sound/cs46xx.c has compile errors test7 and test8 (C Sanjayan Rosenmund) 6. In Progress * Finish I2O merge (Intel/Alan) * Restore O_SYNC functionality (Stephen) - core code and ext2 done * Fix all remaining PCI code to use pci_enable_device (mostly done) * Fix, um, interesting races around dup2() and friends. (Al Viro) * Finish the audit/code review of the code dealing with descriptor tables. (Al Viro) * DMFE is not SMP safe (Frank Davis patch exists, but hasn't gotten much commens yet) * Audit all char and block drivers to ensure they are safe with the 2.3 locking - a lot of them are not especially on the read()/write() path. (Frank Davis --- moving slowly; if someone wants to help, contact Frank) 7. Obvious Projects For People (well if you have the hardware..) * Make syncppp use new ppp code * Fix SPX socket code 8. Fix Exists But Isnt Merged * Update SGI VisWS to new-style IRQ handling (Ingo) * Support MP table above 1Gig (Ingo) * Dont panic on boot when meeting HP boxes with wacked APIC table numbering (AC) * Scheduler bugs in RT (Dimitris) * AIC7xxx doesnt work non PCI ? (Doug says OK, new version due anyway) * Fix boards with different TSC per CPU and kill TSC use on them * Floppy last block cache flush error * PPC-specific: won't boot on 601 CPU's (powermac) (Andreas Tobler; Paul Mackerras has fix in PPC tree) * IRDA fixes (patches from Russell King
Re: NGROUPS_MAX
On Tue, 3 Oct 2000, Jeff Garzik wrote: > On Wed, 4 Oct 2000, Craig Whitmore wrote: > > I need to set up a server with a user that is in more than 32 groups at a time > > and as far as I know NGROUPS_MAX in limits.h changes this maximum. > > If I increase (say to 256) this will this break anything or will linux work >perfectly > > well? > > I am interested in the answer too, though I suspect this belongs on the > glibc not linux-kernel list. > > Some ports of glibc have it as high as 256, but I don't think that port > is based on the Linux kernel. Secondary groups' array is a part of task_struct, so you are risking to eat too much space from the kernel stack (256 words is a fairly large chunk when taken out of 8Kb) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: compiling kernel and modules issues
On Tue, 3 Oct 2000, Tom Cheung wrote: > Would anyone tell me how can I update the kernel and modules > simultaneously without losing previous installed modules.Thanks a lot !! Hi. Let me first say that although I'm subscribed to lkml, I'm really only an aspiring kernel hacker, not in any way a guru at this point in time. However, I have found a solution to your last question that Works For Me(tm). The kernel modules are stored in /lib/modules//. The version number that the kernel will report (to 'uname -r', for example) is set in the top-level makefile, in three variables. What I do is I just append a string, usually -b#, which indicates which build this is from the source tree. For example, the first time I compiled a kernel from my 2.4.0-test9-pre7 tree, I appended '-b0' to the $EXTRAVERSION variable in the makefile, and the modules I compiled for that kernel were placed in /lib/modules/2.4.0-test9-pre7/. When that didn't work for me quite right, I edited the makefile again, changing '-b0' to '-b1', changed my configuration a little, and re-compiled. This time, make modules_install put the new modules in /lib/modules/2.4.0-test9-pre7-b1/. When I booted with the new kernel, it looked there for its modules. As I said, I'm really no guru, and as a result there may be some reason why this solution won't work for other people, and I just don't know about that reason yet. I do hope it helps you, though. The issue of overwriting all my modules when I re-compiled a kernel used to be a real annoyance to me, too, when I had one that pretty much worked but I just wanted to try another configuration. -Andrew C. Dingman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is up with Redhat 7.0?
Matthew Hawkins wrote: > > Perhaps you're getting Redhat confused with Debian here. Redhat doesn't > have package maintainers. It has 1,000 monkeys at 1,000 typewriters > recreating the works of Shakespeare, a la "it was the best of times, it > was the blurst of times" Er... Just a side note, and completely off-topic, but that's Dickens, not Shakespeare. Just thought I'd put my thought in... :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 i810_rng compilation failure
On Tue, 3 Oct 2000, Rasmus Andersen wrote:
> On Tue, Oct 03, 2000 at 08:20:12PM +, Graham Murray wrote:
> > i810_rng.c does not compile when not a module. It fails at line 384,
> > which looks as though it should only be included when being built as a
> > module.
>
> This patch fixes this. Could the maintainer comment? Is there a better
> way to do this?
>
>
> --- linux-240-test9-clean/drivers/char/i810_rng.c Tue Oct 3 22:12:37 2000
> +++ linux/drivers/char/i810_rng.c Tue Oct 3 22:36:01 2000
> @@ -380,7 +380,7 @@
> rng_hw_enabled = 1;
> MOD_INC_USE_COUNT;
> } else {
> -#ifndef __alpha__
> +#if !defined(__alpha__) && defined (CONFIG_MODULE)
> if (GET_USE_COUNT (THIS_MODULE) > 0)
> MOD_DEC_USE_COUNT;
> if (GET_USE_COUNT (THIS_MODULE) == 0)
>
This patch looks ok to me.
That entire #if is a hack. GET_USE_COUNT kills the Alpha build.
Further, all module-related stuff should ideally work when built into
the kernel, without ifdefs.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 i810_rng compilation failure
On Tue, Oct 03, 2000 at 08:20:12PM +, Graham Murray wrote:
> i810_rng.c does not compile when not a module. It fails at line 384,
> which looks as though it should only be included when being built as a
> module.
This patch fixes this. Could the maintainer comment? Is there a better
way to do this?
--- linux-240-test9-clean/drivers/char/i810_rng.c Tue Oct 3 22:12:37 2000
+++ linux/drivers/char/i810_rng.c Tue Oct 3 22:36:01 2000
@@ -380,7 +380,7 @@
rng_hw_enabled = 1;
MOD_INC_USE_COUNT;
} else {
-#ifndef __alpha__
+#if !defined(__alpha__) && defined (CONFIG_MODULE)
if (GET_USE_COUNT (THIS_MODULE) > 0)
MOD_DEC_USE_COUNT;
if (GET_USE_COUNT (THIS_MODULE) == 0)
--
Regards,
Rasmus([EMAIL PROTECTED])
``When the president does it, that means that it is not illegal.''
--Richard M. Nixon, TV interview with David Frost, 1977 May 4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: NGROUPS_MAX
On Wed, 4 Oct 2000, Craig Whitmore wrote: > I need to set up a server with a user that is in more than 32 groups at a time > and as far as I know NGROUPS_MAX in limits.h changes this maximum. > If I increase (say to 256) this will this break anything or will linux work perfectly > well? I am interested in the answer too, though I suspect this belongs on the glibc not linux-kernel list. Some ports of glibc have it as high as 256, but I don't think that port is based on the Linux kernel. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
NGROUPS_MAX
I need to set up a server with a user that is in more than 32 groups at a time and as far as I know NGROUPS_MAX in limits.h changes this maximum. If I increase (say to 256) this will this break anything or will linux work perfectly well? Â Thanks Craig Whitmore
Re: [PATCH-2.2] Bonding Driver Enhancements + Security fix
willy tarreau wrote: > > > rename bond_xmit to bond_xmit_roundrobin, so > > bond_xmit_xor can be implemented, and used if > > desired. bond_xmit_xor is what cisco > > etherchannel/sun trunking really uses, not round > > robin. > > how does their xor method work ? do you know about an > RFC stating about this, that I could read ? I'm > really interested in this since I must propose a > completely redondant switch/server solution for a big > project here. The more I will know about their trunk, > the best I may be able to do :-) See this: http://docs.sun.com:80/ab2/coll.539.1/UGTRUNKING/@Ab2PageView/1311?Ab2Lang=C=iso-8859-1 for information on the 4 possible trunking transmittors. -- +-- Thomas Davis| PDSF Project Leader [EMAIL PROTECTED] | (510) 486-4524 | "Only a petabyte of data this year?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
Chris Good wrote: > In article <[EMAIL PROTECTED]>, Daniel Phillips wrote: > >Thomas Graichen forwarded me some interesting information from the > >freebsd-fsdevel list regarding 3 patents held by Network Appliance > > A couple of points: > First their patents are very much tied into their implementation > of WAFL, your implementation of Tux2 should be sufficiently different > not to cause a problem. This may well be the case, see below. > You mentioned multi-bit maps which sounds > like a big enough difference on its own. Yes, thats a big difference. Here is my current list of significant differences: - No defree list in WAFL (see multiple bits/block below). Tux2 puts all blocks freed or rewritten on a list for freeing later, after the next phase change. *probably very important* - Tux2 uses one bit per block for allocation map, WAFL uses 32. Perhaps one reason for this is that Tux2's snapshot algorithm is separate from its atomic commit algorithm. Perhaps combining those two parts clouded somebody's thinking. - Atomic updating and snapshotting are combined in WAFL, separate in Tux2 - Different sense of WAFL's in snapshot bit: WAFL: snapshot bit on -> block must not be flushed or modified Tux2: inphase bit on -> block must not be flushed but *ok to modify* Again,this is probably key. - WAFL maintains one divergent tree in memory, Tux2 maintains two. - WAFL has to block some file transactions while blocks are written to disk, Tux2 doesn't. - WAFL maintains a single filesystem root, overwriting it on each atomic update. Tux2 keeps a group of metaroots, choosing for the atomic update the nearest one not overwritten in the previous update. All this suggests the algorithms are different in some fundamental sense. ***But I have not seen the patents themselves, only the abstracts*** If anyone has copies of these patents, would they please be so kind as to send them to me. > Second Netapp are a pretty nice bunch and chasing someone doing GPL > code isn't their style. Netapp may be great guys but they have still claimed to own something that properly belongs to me and the rest of humanity. > Thirdly a hell of a lot of people buying Netapp products are fans > of linux/*BSD, I very much doubt that they're going to risk their > bottom line. I retract anything I may have said that might reflect negatively on Netapp. I haven't met them, I know very little about them. I wasn't calm yesterday. I suspected such patents might exist ever since I first heard of WAFL last spring. When I actually saw the patent abstracts I became angry, not angry at Netapps but at the whole barbaric patent system. Netapps had no choice but to apply for their patent and I have no choice but to confront it. If they are really great guys then let them prove it by licencing their patents for unrestricted use in GPL-compatible code. They don't have a lot to lose: my work is superior and GPL, and directly based on work I did in 1989. They should realize that their main patents aren't worth much now except to lawyers, so they might as well collect some good karma by making their licence GPL-compatible. It was suggested to me privately that I contact Netapp and show them my algorithm. That seems to me to be a very good idea. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9 i810_rng compilation failure
i810_rng.c does not compile when not a module. It fails at line 384, which looks as though it should only be included when being built as a module. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8 on SPARC build failure
Joshua Uziel <[EMAIL PROTECTED]> said: > * Horst von Brand <[EMAIL PROTECTED]> [001002 10:35]: > > This PCI stuff was discussed before... > > > > pcic.c: At top level: > > pcic.c:39: redefinition of `pcibios_present' > > /usr/src/linux-2.4.0-test/include/linux/pci.h:562: `pcibios_present' previous > ly defined here > > make[1]: *** [pcic.o] Error 1 > > make[1]: Leaving directory `/usr/src/linux-2.4.0-test/arch/sparc/kernel' > > make: *** [_dir_arch/sparc/kernel] Error 2 > That fix is already in the vger sparc cvs kernel tree... just remove the > definition of pcibios_present() in pcic.c and you should be fine... "Why hasn't it been merged over to Linus" is my question then... -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
On Tue, Oct 03, 2000 at 09:42:04AM -0700, Thomas Davis wrote: > Ion Badulescu wrote: ... > > For another fine example of GPL technology covered by a parent, check out: > > > > http://www.patents.ibm.com/details?pn=US06049528__ > > > > This a patent filed by Sun in June 1997 and awarded in April 2000 which > > covers very well the ethernet bonding device in Linux 2.2.x. > > > > I wonder if the equalizer device present in Linux kernels since before > > 1996 could count as prior art. IANAL, of course. > > Or, even better, the fact that Ethernet bonding has been available as a > Linux patch since about 1995.. I am fairly sure that that is in series of "will patent that so that nobody can ransom us"... (Like IBM did with HTML.) Surprisingly I don't see any patent at Cisco Systems which relates to that ? They have been doing ether-channel for ages, but perhaps their solution is just an implementation of Sun's idea ? > I'm sure Donald Becker could produce prior art on that one! > -- > +-- > Thomas Davis | PDSF Project Leader > [EMAIL PROTECTED] | /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
Jeff Garzik writes: > On Mon, 2 Oct 2000, Rasmus Andersen wrote: > > On Sun, Oct 01, 2000 at 09:14:49PM -0700, Linus Torvalds wrote: > > > > > > Last pre-kernel - I'll do the real test9 before I fly off to Germany on > > > Tuesday. > > > > > > Linus > > > --- > > > - pre8: > > > - initialize to zero -> put it in the .bss instead > > > > This patch was inspired by a comment from Jeff Garzik. It should > > be correct (famous last words!) and consists of trivial changes > > to the affected files to correct __initdata and pointers to > > strings. Thus the crosspost to the maintainers, Linus and > > l-k. That being said, I sure hope it is correct :) > > You patch looks good to me... Same opinion here. Please apply. _ |_| - ---+---+- | |Russell King [EMAIL PROTECTED] --- --- | | | |http://www.arm.linux.org.uk// / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: MIME QP encoded good/bad ...
On Tue, Oct 03, 2000 at 09:10:17AM -0700, Linus Torvalds wrote: > On Tue, 3 Oct 2000, Matti Aarnio wrote: > > > >Just FYI. THAT can't be MIME (quoted printable) error. > > Oh, but it is. Oh, so you destroyed the evidence ? I see... > >The '=' is very special in MIME QP, and as the '+=' at > >that very same line has not been turned into '+=3D', it > >wasn't QP encoding happenstance. > > That's simply because I caught the worst mime-damage, and missed the fact > that the "-" had also been damaged. "-" isn't among characters to be QP encoded -- or then you will see EVERY character QP encoded, in which case you propably get BASE64 encoded attachment/body anyway. The encoded character was: "=AD" which at iso-8859-1 is listed as: oct dec hex chardescription 255 173 AD Â SOFT HYPHEN So right, it may LOOK like a hyphen/minus, but isn't it. Patch writer's bug. (And his/her mail program definitely considered the situation as "now I must QP encode everything".) Linus, please use MUTT or PINE -- hmm... you do use PINE, so what is the problem at receiving MIME attachments, or QP encoded material at all ? (Aside of pine possibly saving/piping non-decoded QP text/plain message into file/pipe in original encoded form ? Hmm.. That is a though problem at the user agent...) Some 10 years ago when MIME technology was being developed, our(*) goal was to make it as robust as possible. Unless your inbound email transport paths contain EBCDIC monsters, there really is no need complain about QP. (And not even then.) (*) "our" as "the IETF MIME working group". I do have technology which helps in cases where users are dead set to use non-mime understanding tools; those got created so that I myself could be lazy and use non-mime MUA 10 years ago, and still send and receive 8-bit iso-8859-1 character encoded email, like is our habit in Finland... (I write MTA software, not MUAs.) Sendmail implemented something similar few years latter. > Anyway, please avoid MIME if you can. Plain ascii is fine. > Linus Yes Linus, ASCII is fine, but then the ENTIRE MESSAGE must be in 7-bit ASCII only. A single 8-bit char anywhere makes worlds of difference to the rules. (E.g. 8-bit char in .signature may force QP encoding of the entire message.) You do need to have technology to grok (decode, I mean) QP encoded TEXT/PLAIN email transparently into your message store so that you never see any QP in it. If fact you propably have it, but it simply isn't enabled. You actually have no option there. Your wishes won't change how people's MTAs and MUAs are working when they follow RFCs. There may even be systems in between people and you, which don't announce capability to transport 8BITMIME so that some intermediate transport step is forced (per RFCs) to downgrade an 8BIT message to QUOTED-PRINTABLE. Most systems won't decode QP-email when sending it to systems announcing 8BITMIME capability. (And all qmail systems are lying -- they are not prepared to downgrade the message, if the remote system isn't announcing 8BITMIME capability. Also, qmail's aren't decoding any incoming QP in any case.) Looking at Transmeta's neosilicon, I would say that you need at "Mlocal"/"Mpipe"/"Mfile" definitions to add "9" flag into "F=". ( Neosilicon is the MX defined server for transmeta.com ) ( I am now assuming that it does delivery to your local mailboxes -- which it possibly doesn't do... ) ( sendmail seems to have a bunch of "local" related "M" entries, all of those need to have the "9" added. ) This explanation matches sendmail 8.11, but neosilicon is 8.9.x, so "cavet emptor"... 9 If present, do limited 7->8 bit MIME conversions. These conversions are limited to text/plain data. With that done, you won't complain about incoming MIME QP encoded TEXT/PLAIN messages (your local MTA decodes them for you), and when you receive an attachment of something, you can save/pipe that attachment properly decoded with your pine. ... which won't help in case of "soft hyphen" being incorrect character for the Makefile, but that is another issue. /Matti Aarnio <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How Can I develop a process monitor?
On Tue, 3 Oct 2000, [iso-8859-1] Abel Muñoz Alcaraz wrote: > Hi everybody, > > I want to develop a process monitor (like TOP) in a kernel module. > I think I must get the '/proc' superblock and replace the > inode_operations->mkdir,rmdir,create and open. None of these exist. > Is this correct? No. > Can I get the /proc superbloc with 'struct super_block * get_super(kdev_t > dev' function? No (for obvious reason: what device number would you use?) It might help if you would * describe what do you want to do * tell which kernel branch you are dealing with - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
How Can I develop a process monitor?
Hi everybody, I want to develop a process monitor (like TOP) in a kernel module. I think I must get the '/proc' superblock and replace the inode_operations->mkdir,rmdir,create and open. Is this correct? Can I get the /proc superbloc with 'struct super_block * get_super(kdev_t dev' function? I am going to develop this module in C. Thanks in advance. -Abel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problems with 2.4.0-test8
On Tue, 3 Oct 2000, Adam Sampson wrote: > On Tue, Oct 03, 2000 at 01:54:55PM -0300, Rik van Riel wrote: > > > It always happens the same although I can't repeat it on demand. > > > Start a kernel compile and go read mail. Somewhere upon > > > switching mail folders in netscape it locks. Box is _never_ > > > under swap when this occurs. Wish it would at least log > > > _something_ to report. > > > > That sounds suspiciously like something going to sleep > > and not being woken up again ... > > I had an interesting one yesterday (when I was running > test9-pre7 with the reiserfs and Riel VM patches)---I came back > to my machine which was running X to find that it had apparently > locked (display had frozen, mouse and keyboard had no effect). I > then tried the normal last-ditch Alt-SysRq-s to get it to sync, > and it burst back to life as if nothing had happened... Interesting. That might mean that something was sleeping on bdflush (kflushd), while at the same time kflushd was sleeping and never woke up (at least, not until you sent it a signal). Hmm, now that you mention it... The reschedule point in flush_dirty_buffers() looks suspect. Are we /sure/ that a task going to sleep there is in TASK_RUNNING mode? regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problems with 2.4.0-test8
On Tue, Oct 03, 2000 at 01:54:55PM -0300, Rik van Riel wrote: > > It always happens the same although I can't repeat it on demand. > > Start a kernel compile and go read mail. Somewhere upon > > switching mail folders in netscape it locks. Box is _never_ > > under swap when this occurs. Wish it would at least log > > _something_ to report. > > That sounds suspiciously like something going to sleep > and not being woken up again ... I had an interesting one yesterday (when I was running test9-pre7 with the reiserfs and Riel VM patches)---I came back to my machine which was running X to find that it had apparently locked (display had frozen, mouse and keyboard had no effect). I then tried the normal last-ditch Alt-SysRq-s to get it to sync, and it burst back to life as if nothing had happened... No messages in the syslog (other than the emergency sync, of course). On the plus side, test9-pre9 + reiserfs seems to be working nicely. Good job, guys. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
dst cache overflow
Hello, Recently we have been experiencing some problems with the network dying temporarily on a machine then magically coming back to life. This appears to happen more frequently when the machines are loaded down CPU wise and usually sustain over 3Mbits/sec of network traffic. This is happening on several machines with similar configurations. Each machine has about 2000 active tcp connections on them and CPU usage is typically over 75%. They have AMD 800-950 processors and 3Com 905C cards running Redhat 6.2 with kernel build ranges from 2.2.17p3 to 2.2.18p10. When this happens the below logs appear in the system logger: Oct 3 12:14:38 onion kernel: dst cache overflow Oct 3 12:14:38 onion last message repeated 9 times Oct 3 12:14:43 onion kernel: NET: 486 messages suppressed. Oct 3 12:14:43 onion kernel: dst cache overflow Oct 3 12:14:48 onion kernel: RPC: sendmsg returned error 105 Oct 3 12:14:49 onion kernel: NET: 367 messages suppressed. Oct 3 12:14:49 onion kernel: dst cache overflow Oct 3 12:14:51 onion kernel: RPC: sendmsg returned error 105 Oct 3 12:14:53 onion kernel: NET: 192 messages suppressed. Oct 3 12:14:53 onion kernel: dst cache overflow Oct 3 12:14:55 onion kernel: RPC: sendmsg returned error 105 Oct 3 12:14:59 onion kernel: NET: 122 messages suppressed. Oct 3 12:14:59 onion kernel: dst cache overflow Oct 3 12:15:01 onion kernel: nfs: server toastem not responding, still trying Oct 3 12:15:01 onion kernel: RPC: sendmsg returned error 105 Oct 3 12:15:03 onion kernel: RPC: sendmsg returned error 105 Oct 3 12:15:04 onion kernel: NET: 52 messages suppressed. Oct 3 12:15:05 onion kernel: dst cache overflow Oct 3 12:15:08 onion kernel: RPC: sendmsg returned error 105 Oct 3 12:15:11 onion kernel: nfs: server toastem OK Oct 3 09:23:58 mint kernel: NET: 271 messages suppressed. Oct 3 09:23:58 mint kernel: dst cache overflow Oct 3 09:23:58 mint last message repeated 9 times Oct 3 09:24:07 mint kernel: NET: 384 messages suppressed. Oct 3 09:24:07 mint kernel: dst cache overflow Oct 3 09:24:07 mint kernel: NET: 255 messages suppressed. Oct 3 09:24:07 mint kernel: dst cache overflow Oct 3 09:24:12 mint kernel: NET: 149 messages suppressed. Oct 3 09:24:12 mint kernel: dst cache overflow Oct 3 09:24:18 mint kernel: NET: 64 messages suppressed. Oct 3 09:24:18 mint kernel: dst cache overflow Oct 3 09:24:23 mint kernel: NET: 35 messages suppressed. Oct 3 09:24:23 mint kernel: dst cache overflow Oct 3 09:24:27 mint kernel: NET: 23 messages suppressed. . . Hope this helps Thanks --Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Please explain the change..
Jeff, What is the significance of the changes in ide-pci.c? What vender does something different that requires this change? Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux2 - evil patents sighted
On Tue, 3 Oct 2000, Thomas Davis wrote: > > For another fine example of GPL technology covered by a parent, check out: > > > > http://www.patents.ibm.com/details?pn=US06049528__ > > > > This a patent filed by Sun in June 1997 and awarded in April 2000 which > > covers very well the ethernet bonding device in Linux 2.2.x. > > > > I wonder if the equalizer device present in Linux kernels since before > > 1996 could count as prior art. IANAL, of course. > > Or, even better, the fact that Ethernet bonding has been > available as a Linux patch since about 1995.. > > I'm sure Donald Becker could produce prior art on that one! I'm pretty sure Sun won't force the issue. Since prior art is available on a few hundred FTP sites, they would be foolish to sue and nullify their patent ;) [better keep up the status quo so they can try to get a few bucks from random sucke^W^Wother software companies infringing on their intellectual monopoly^W^Wpatent] regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problems with 2.4.0-test8
On Tue, 3 Oct 2000, TimO wrote: > As for the hard lockups, I s'pose we can blame Rik. ;-) I've > been loathe to do so tho' because on my box the locks always > occur with low memory pressure. I actually thought that he had > them fixed with his vmpatch cuz' I didn't get any lockups with a > heavier load. Opening netscape, star office and doing repeated > make clean/Build-kernels worked just fine. Closed star office > started compiling -pre9 went back to reading mail and zap; > lock-up. > > It always happens the same although I can't repeat it on demand. > Start a kernel compile and go read mail. Somewhere upon > switching mail folders in netscape it locks. Box is _never_ > under swap when this occurs. Wish it would at least log > _something_ to report. That sounds suspiciously like something going to sleep and not being woken up again ... > Rik: are you having fun yet?? ;-) Hunting as we speak ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8, usb, unresolved symbols
On Tue, Oct 03, 2000 at 06:22:32PM +0200, f5ibh wrote: > Christoph wrote : > > Could you try undoing the -pre8 changes to drivers/usb/Makefile? > THIS was the solution I've compiled 2.4.0-test9-pre9 with the > drivers/usb/Makefile of the test9-pre7 version of the kernel. I've no more the > 'unresolved symbols' and the usb mouse works. Very strange, I'll beat on this some more today and try to see what's up. thanks for letting us know. greg k-h (I must remember to keep chanting, "the Makefile is your friend, the Makefile is your friend...") -- greg@(kroah|wirex).com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
Hi David, Ingo, Keith, Kier and all, As the developer of PAPI, I can only reiterate what Ingo and David have suggested. The user base of people wanting access to performance counters has greatly expanded. PAPI has now been out for over a year and a half and we get pings from developers across the globe working with the performance counters on everything from performance tool development, to database tuning, to feedback directed compilation. For the Linux port, we originally (in 2.0 and 2.2) used David's patch with some minor modifications that I made for inheritance of the MSR when an option is set. For 2.4 we have migrated to Mikael Petterson's excellent perfctr patch which provides us with extrememly low latency access to the counters via a memory mapped interface. The only outstanding issue with that patch as far as PAPI goes is how MSR/counter inheritance is handled by threads and making the virtualized TSC run freely from 'attach' time. As far as a kernel interface goes, we need to remember that most architectures allow the counters to be read in user mode, which lends itself very nicely to the kind of implementation that Mikael has done. Basically, reading the counters is a 2 step process: read the mmapped virtual counters and add that to the contents of rdpmc(). This means that (at least for the x86 series) the kernel interface only needs to 'guard' access to the MSR to make sure the user doesn't set up anything pathological. This same kind of interface is also possible for the UltraSparc. For other systems where a lower IPL is required, the interface needs to be a fast-path syscall interface. I would like to point out that this is not just something that us hackers need, but now that multi-million dollar superclusters are being sold by the dozen, hardware based performance analysis and tuning is a real necessity. I know the TurboLinux folks are playing here, but no one has come out an championed a kernel interface. In fact, there is at least one commercial product (DEEP/MPI from PSRV) I know of that uses the hardware counters (and PAPI for that matter) that is dependent upon us academics to make sure we keep the kernel patch up to date. Now, back to the subject at hand, if the NMI mechanism is coded properly, we can also use it to generate statistical profiles instead of emulating them in user land. Well, that's all for now. If anyone is motivated to spearhead a formal interface to the PMC's, please let us know. Thanks for reading this novel, -Philip Mucci IBM Research UTK Innovative Computing Lab. David Mentré wrote: > > Ingo Molnar <[EMAIL PROTECTED]> writes: > > > that having all said, i'm not against a generic, nonpriviledged (kernel > > based) performance counter API within the kernel (if there is demand), and > > such an API should of course have close control over the contents of the > > performance counter registers, and in this case the NMI oopser has to > > cooperate. Something like doing per-process performance monitoring and > > potentially switching the MSRs on task-switch. > > regarding perf. counters, there is also the PAPI initiative, standard > *user level* API : > > Performance Data Standard and API >http://icl.cs.utk.edu/projects/papi/ > > Linux 2.2 and 2.4 (CVS) are actively supported with a patch. Probably > PAPI developers would also be glad to have a standard linux kernel API. > > d. > -- > [EMAIL PROTECTED] -- http://www.irisa.fr/prive/dmentre/ > Linux SMP HOWTO: http://www.irisa.fr/prive/dmentre/smp-howto/ > Opinions expressed here are only mine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
linux-2.4.0-test9
- final: - USB: ohci controller update, round-robin device numbering - ksymoops moved: document - sparc updates - sg.c: get rid of more #ifdef MODULE code - pre9: - USB: documentation. - Yeah. MD/LVM should really be fixed this time. - SH architecture update - i810 RNG driver update - IDE-PCI: make sure we initialize the chipsets correctly - VIA IDE driver fixes - VM balancing, part 53761 of 798321 - SCHED_YIELD cleanups - pre8: - initialize to zero -> put it in the .bss instead - no extended dumb serial driver options, if no dumb serial driver - access() on a special file on a read-only filesystem is special. - DRM update - fix SCHED_YIELD problems. - quintela: fix the synchronous wait on kmem_cache_shrink(). This should fix the mmap02 lockup. - syncppp got lost in the Makefile reshuffle. Unlose it. - firewire update - flock blocking list fix - correct watchdog initialization order - USB-storage: reset fixes. Race condition fixes. - USB: fix freeing already free'd device. - minix truncate fixes - USB: pack only the relevant subset, not the whole descriptor (so as to not create extra unaligned fields). - nfsfh: DCACHE_NFSD_DISCONNECTED checking typo - dquota silly bugfix - sound updates (get rid of check_region, check request_region() instead) - scsihosts boottime parameter passing - avoid double init of MD - eicon ISDN driver update - fix Cyrix MTRR thinko - toshiba driver 2.4.x update - Makefile subdirectory traversal cleanup and documentation - cciss typos from bad merge fixed - cdrom driver oops fix for CONFIG_SYSCTL=y CONFIG_PROC_FS=n - coda initialization - we already did the module_init, no need for the extra double init. - pre7: - USB: remember to release the kernel lock and other updates.. - recognize the k6 model 13: it's a K6-2+ mobile processor. - file locking deadlock detection bugfix.. - NFSv3 is not really really experimental any more. - don't raise privileges when re-trying a failed NFS RPM request - alpha cross-compile fixes.. - sound init cleanups - shm statistics bugfix. - nfsd: mark us as a O_LARGEFILE case, so that the VFS allows the full 64-bit access.. - fix up ac97 codec initialization - Ingo: clean up VM handling, improve balancing. - add SGI PCI ID's. - export the new lock copy/init functions - cs4281 sound driver - official Compaq CISS driver. - pre6: - TUN/TAP driver: use proper device number (misc device, minor=200). - teach st.c about some SCSI tapes that really aren't SCSI tapes (OnStream) - samba 2.2 needs leases for efficient file sharing. They are kind of like file locks with async IO notification. - broadcast I/O APIC interrupt MP-tables are legal.. - alpha RTC year magic again.. - careful memory ordering by Andrea.. - make the scsi-generic module work properly again. - file locking fixes - update atp ISA net driver - VIA IDE driver bugfixes - more linux-2.2 driver sync-ups - new PCI ids - emu10k stereo sound fix. - makefile documentation update - USB uhci updates - networking updates - codafs fixups - VM UP deadlock fix - Add Camino chipset ID to eepro100 driver. - pre5: - Make SCSI initialization order be same as before. - fix cardbus bridge resources.. - don't disallow Onstream ide-scsi devices - byteorder: use statement expressions instead of macros, to avoid argument re-use. - codafs update - more USB updates - _fput/__fput are no longer used. - ixj telephony driver fixes - pmac SCSI driver init update - Andries: net device name allocation as in 2.2.x - sis900 driver update - more drivers synced to Alan's 2.2.x changes - pre4: - continued SCSI cleanup - more USB updates - pre3: - USB updates - NFS over TCP - handle TCP socket writability right.. - NFS cache coherency across file locking fix - floppy: we'd better hold the io_request_lock when playing with "CURRENT". - acenic driver update - ARM update (including ARM drivers) - adfs correct dentry operations - netfilter update - networking updates (iipv6 works non-modular etc) - Sync up with Alans 2.2.x driver changes - SCSI initialization - move over to the modular case. No more double initialization. - block_prepare_write and block_truncate_page: if the page is up-to-date, then so are the buffer heads inside it once they are mapped.. - uninitialized == zero. Remove extra initializers. - pre2: - scsi fixes - network updates - PCI bridge scanning fix: assign numbers properly - sparc updates - Riel VM update - disallow re-mounting same filesystem in same place multiple times. Too confusing. And /etc/mtab gets strange. - PPC updates
Re: Tux2 - evil patents sighted
Ion Badulescu wrote: > > In article <[EMAIL PROTECTED]> Daniel Phillips wrote: > > > It is important that all technology used in GPL software be free of > > patent restrictions. > > Indeed. > > For another fine example of GPL technology covered by a parent, check out: > > http://www.patents.ibm.com/details?pn=US06049528__ > > This a patent filed by Sun in June 1997 and awarded in April 2000 which > covers very well the ethernet bonding device in Linux 2.2.x. > > I wonder if the equalizer device present in Linux kernels since before > 1996 could count as prior art. IANAL, of course. > Or, even better, the fact that Ethernet bonding has been available as a Linux patch since about 1995.. I'm sure Donald Becker could produce prior art on that one! -- +-- Thomas Davis| PDSF Project Leader [EMAIL PROTECTED] | (510) 486-4524 | "Only a petabyte of data this year?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom problems with test9-preX
On Wed, Oct 04, 2000 at 01:56:27AM +1100, Andrew Morton wrote: > > This patchlet was selectively taken from the latest pcmcia-cs > (3.1.21-beta). It made my NIC work correctly - without this patch the > Xircom NIC incorrectly enters half-duplex mode with disastrous > performance consequences. I doubt that the full duplex fix itself caused the problem. I think this is probably another instance of the receive filter issue. When you bring up the Xircom card, if you don't get incoming traffic, try doing things like "ifconfig eth0 promisc" (which should always work); sometimes it is also enough to do "ifconfig eth0 -promisc" a few times (which should do nothing, but...) -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: problems with 2.4.0-test8
Petko Manolov wrote: > > > which DaveM submitted a patch some time ago. Check your logs for: > >kernel BUG at ll_rw_blk.c:711 > > It might be, but might not. My log files are clear from such error. This > is because of hard locking of the machine. > > I'll test Rik's patch first. > > best, > Petkan My previous replly was targeted more to the comments of R. Polton where sysreq still functioned but was unable to sync the disk netscape was reading/writing. The fix for this one was posted by DaveM and is in the test9.prex kernels. As for the hard lockups, I s'pose we can blame Rik. ;-) I've been loathe to do so tho' because on my box the locks always occur with low memory pressure. I actually thought that he had them fixed with his vmpatch cuz' I didn't get any lockups with a heavier load. Opening netscape, star office and doing repeated make clean/Build-kernels worked just fine. Closed star office started compiling -pre9 went back to reading mail and zap; lock-up. It always happens the same although I can't repeat it on demand. Start a kernel compile and go read mail. Somewhere upon switching mail folders in netscape it locks. Box is _never_ under swap when this occurs. Wish it would at least log _something_ to report. Athlon 750 128M memory 124M swap Rik: are you having fun yet?? ;-) -- === -- TimO - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where did my symbols go?
On Tue, 3 Oct 2000 [EMAIL PROTECTED] wrote: > Hi. > > Sorry if this is an idiotic question, especially if it's one worthy of > slapping! > > I've been trying to set my system up to have multiple linux "test-bed" > setups on one drive - That was done easily, I thought. However, my Caldera > (freebie eDesktop 2.4) distribution won't insmod my driver, saying that a > load of unresolved symbols exist. The strange thing, is that all the > symbols, I thought, are supposed to be in the kernel itself. Symbols like > kmalloc, iounmap, jiffies, printk... > > I've never come across this problem before. I'm pretty sure that my driver > isn't the only thing on my Caldera partition that need these symbols! > > Any lights? > > Does the System.map file have any part in the boot (or module-loading) > process? I thought it was just a text file that gets produced when the > kernel is compiled showing humans (or debuggers) where everything is... just make sure that: a) you have recompiled the kernel -- distribution-supplied kernels is for dummies and so using them is silly b) make sure that neither your newly compiled kernel nor the module are using modversions. Module versioning is more annoyance-some (heh, a new English word?) than useful. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel modules development in C++
I'm attaching a module i'm using to write C++ drivers for linux 2.0.xx The following line goes into the Rules.make file %.o: %.cpp $(CC) -fno-exceptions -fno-rtti $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_DEBUG) -c -o $@ $< For me it is working really great the new.cpp file goes in my arch//lib directory Vadim new.cpp
Re:2.4.0-test9-pre8, usb, unresolved symbols
Hi! Randy wrote : > Are you building USB core support in-kernel or as ai > module? (Maybe provide your .config file, or at least > the CONFIG_USB_xxx portion of it.) I use modules, here is part of my .config file. Remark : I've the same problem with 2.4.0-test9-pre9. Greg wrote: > Is your modutils package the more recent one? > Did this same thing happen for 2.4.0-test8? modutils version is 2.3.16 I had not the problem with test8, the last one without problem was test9-pre7. So the problem came with test9-pre8. The .config file is basically the same as with previous versions. Christoph wrote : > Could you try undoing the -pre8 changes to drivers/usb/Makefile? THIS was the solution I've compiled 2.4.0-test9-pre9 with the drivers/usb/Makefile of the test9-pre7 version of the kernel. I've no more the 'unresolved symbols' and the usb mouse works. --- Regards Jean-Luc --- CONFIG_INPUT=m # CONFIG_INPUT_KEYBDEV is not set CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_NS558 is not set # CONFIG_INPUT_LIGHTNING is not set # CONFIG_INPUT_PCIGAME is not set CONFIG_INPUT_ANALOG=m ... # USB support CONFIG_USB=y # CONFIG_USB_DEBUG is not set # Miscellaneous USB options CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # USB Controllers CONFIG_USB_UHCI=m # CONFIG_USB_UHCI_ALT is not set # CONFIG_USB_OHCI is not set # USB Devices # CONFIG_USB_PRINTER is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_ACM is not set # CONFIG_USB_SERIAL is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_USS720 is not set # CONFIG_USB_DABUSB is not set # CONFIG_USB_PLUSB is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_NET1080 is not set # USB Human Interface Devices (HID) CONFIG_USB_HID=m # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_WACOM is not set ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre9 lockups using pine
On Tue, 3 Oct 2000, Rik van Riel wrote: > On Tue, 3 Oct 2000, Christoph Lameter wrote: > > > I frequently experience lockups since test9-pre7. It usually > > happens when leaving pine. Pine asks if the deleted messages > > should be purged. Say yes and everything freezes up. > > > # CONFIG_MAGIC_SYSRQ is not set > > Maybe you want to switch on this option and tell us some > more useful information ;) > > - system hardware configuration (how much memory) > - running X or not > - compiler version used to compile the kernel > - what do you see after the system 'hangs' and > you type sysrq-T, sysrq-M and/or sysrq-P ? I wrote a message yesterday with the same problem. test8 works ok but test9-pre? hang when quickly keying while expunging a mailbox. Only sysrq-o (power down) responds. No oops. Pau - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/Makefile error in test9pre8 (dquot.o left behind)
On Tue, 3 Oct 2000, Matti Aarnio wrote: > >Just FYI. THAT can't be MIME (quoted printable) error. Oh, but it is. >The '=' is very special in MIME QP, and as the '+=' at >that very same line has not been turned into '+=3D', it >wasn't QP encoding happenstance. That's simply because I caught the worst mime-damage, and missed the fact that the "-" had also been damaged. Anyway, please avoid MIME if you can. Plain ascii is fine. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Where did my symbols go?
Hi. Sorry if this is an idiotic question, especially if it's one worthy of slapping! I've been trying to set my system up to have multiple linux "test-bed" setups on one drive - That was done easily, I thought. However, my Caldera (freebie eDesktop 2.4) distribution won't insmod my driver, saying that a load of unresolved symbols exist. The strange thing, is that all the symbols, I thought, are supposed to be in the kernel itself. Symbols like kmalloc, iounmap, jiffies, printk... I've never come across this problem before. I'm pretty sure that my driver isn't the only thing on my Caldera partition that need these symbols! Any lights? Does the System.map file have any part in the boot (or module-loading) process? I thought it was just a text file that gets produced when the kernel is compiled showing humans (or debuggers) where everything is... Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test9-pre9 lockups using pine
On Tue, 3 Oct 2000, Christoph Lameter wrote: > I frequently experience lockups since test9-pre7. It usually > happens when leaving pine. Pine asks if the deleted messages > should be purged. Say yes and everything freezes up. > # CONFIG_MAGIC_SYSRQ is not set Maybe you want to switch on this option and tell us some more useful information ;) - system hardware configuration (how much memory) - running X or not - compiler version used to compile the kernel - what do you see after the system 'hangs' and you type sysrq-T, sysrq-M and/or sysrq-P ? regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs hang at boot) where is the kernel debugger?
On Tue, 3 Oct 2000 12:32:37 -0300 (BRST), Rik van Riel <[EMAIL PROTECTED]> wrote: >On Wed, 4 Oct 2000, Keith Owens wrote: >> Rik van Riel <[EMAIL PROTECTED]> wrote: >> >Sysrq-T is broken on x86 ; >> >> show_task() calls thread_saved_pc() which is giving bad results. >> Getting the correct PC for blocked threads is easy, >> But it does not give you much. Thread esp and eip are only >> saved during switch_to(), at which point eip always points to >> schedule+0x42c. > >Yup ;) > >So this function will need to look at the call trace and >give the function that called schedule() ... Shudder. I had to do that for kdb and it is as ugly as sin. See kdba_prologue and kdb_get_next_ar in the kdb patch, especially the comments at the start of kdb_get_next_ar. ix86 back trace has special cases galore. This is why an oops dumps so much rubbish in the "call trace" on ix86, it is just too hard to get a correct call trace so we print anything on stack that might be a kernel or module address and expect the user to filter out all the false positives. Also bear in mind that for running threads you have no idea where the stack pointer is, esp is not saved in the process table unless the thread blocks. So sysrq-T cannot even think about looking at the stack for running threads on other cpus unless you force them to block first. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre9 lockups using pine
I frequently experience lockups since test9-pre7. It usually happens when leaving pine. Pine asks if the deleted messages should be purged. Say yes and everything freezes up. Kernel configuration (Debian woody + pine 4.21) # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_M686FXSR is not set CONFIG_MK6=y # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_BYTES=32 CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # CONFIG_LVM_PROC_FS is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y CONFIG_NET_IPGRE=y # CONFIG_ARPD is not set CONFIG_INET_ECN=y # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_UNCLEAN=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_MIRROR=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_LOG=y # CONFIG_IPV6 is not set CONFIG_KHTTPD=m # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set #
Re: Xircom problems with test9-preX
Tom Sightler wrote: > > Is there a better location to report the issues for this driver? David prefers to use a web system. Current: http://sourceforge.net/forum/forum.php?forum_id=33427 Old: http://pcmcia.sourceforge.org/cgi-bin/HyperNews/get/pcmcia/xircom.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Request for net guru help: waitqueue oops
On Tue, 3 Oct 2000, Petko Manolov wrote: > None of these can sleep. netif_*_queue routines are quite simple. > They are all atomic so there is no need to protect them with locks. Ok. I originally had them outside locks as they appeared to be atomic. I moved them in incase they were the cause of the problem. > It is not clear from the example above if it is needed to lock in > the timer routine and what is locked inside. Anyway be careful > about locking regions shared between interrupts/bottom halves and > user context as this happens often. The timer routines (there are 4) are used to switch hardware states and must therefore be mutually exclusive with respect to the interrupt handler. There are no bottom halves used in this driver. Andrew Morton suggested that the problem could be in my use of the skb pointers, which seems a likely candidate. I'll check that. Thanks -- Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom problems with test9-preX
Quoting Andrew Morton <[EMAIL PROTECTED]>: > But it broke yours completely, so I guess the hunk should be backed out > until David has a chance to do a full merge. Are you able to test with > the latest pcmcia-cs package? > > A number of people (esp. David) have spent a lot of time trying to make > the Xircom driver work correctly. It's being a real problem. I will try to test the latest pcmcia-cs package shortly and report my findings later this afternoon. Is there a better location to report the issues for this driver? Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs hang at boot) where is the kernel debugger?
On Wed, 4 Oct 2000, Keith Owens wrote:
> Rik van Riel <[EMAIL PROTECTED]> wrote:
> >Sysrq-T is broken on x86 ;
>
> show_task() calls thread_saved_pc() which is giving bad results.
> Getting the correct PC for blocked threads is easy,
>
> Index: 0-test9-pre9.3/include/asm-i386/processor.h
> --- 0-test9-pre9.3/include/asm-i386/processor.h Tue, 08 Aug 2000 16:14:08 +1000 kaos
>(linux-2.4/P/18_processor. 1.1.1.5 644)
> +++ 0-test9-pre9.3(w)/include/asm-i386/processor.h Wed, 04 Oct 2000 01:48:32 +1100
>kaos (linux-2.4/P/18_processor. 1.1.1.5 644)
> @@ -411,7 +411,7 @@ extern void forget_segments(void);
> * Return saved PC of a blocked thread.
> */
> extern inline unsigned long thread_saved_pc(struct thread_struct *t)
> {
> - return ((unsigned long *)t->esp)[3];
> + return (t->eip);
> }
>
> But it does not give you much. Thread esp and eip are only
> saved during switch_to(), at which point eip always points to
> schedule+0x42c.
Yup ;)
So this function will need to look at the call trace and
give the function that called schedule() ...
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: (reiserfs hang at boot) where is the kernel debugger?
On Sun, 1 Oct 2000 23:50:17 -0300 (BRST),
Rik van Riel <[EMAIL PROTECTED]> wrote:
>On Sun, 1 Oct 2000, David Ford wrote:
>> During normal operation of the machine, -T shows processes
>> having PCs of 0x and 0x7f00 which strikes me as a
>> bit odd.
>>
>> For e.g. the following:
>>
>> sshd S 7FFF 0 247 88 248 (NOTLB)
>> 121
>> sig: 0 : X
>> bash S 0 248247 263 (NOTLB)
>> sig: 0 0001 : X
>
>Sysrq-T is broken on x86 ;
>
>(very much to my dismay ... this is one of the best
>debugging helps we have^Whad and I could have used
>it quite well)
show_task() calls thread_saved_pc() which is giving bad results.
Getting the correct PC for blocked threads is easy,
Index: 0-test9-pre9.3/include/asm-i386/processor.h
--- 0-test9-pre9.3/include/asm-i386/processor.h Tue, 08 Aug 2000 16:14:08 +1000 kaos
(linux-2.4/P/18_processor. 1.1.1.5 644)
+++ 0-test9-pre9.3(w)/include/asm-i386/processor.h Wed, 04 Oct 2000 01:48:32 +1100
+kaos (linux-2.4/P/18_processor. 1.1.1.5 644)
@@ -411,7 +411,7 @@ extern void forget_segments(void);
* Return saved PC of a blocked thread.
*/
extern inline unsigned long thread_saved_pc(struct thread_struct *t)
{
- return ((unsigned long *)t->esp)[3];
+ return (t->eip);
}
But it does not give you much. Thread esp and eip are only saved
during switch_to(), at which point eip always points to schedule+0x42c.
If the task is running on a cpu (the interesting case) then neither
t->esp nor t->eip contain useful values so you cannot get the PC for
running tasks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Adding vendor drivers...
So, when a vendor has to add a new driver, especially with the new-style makefiles, you have a one-line patch to a makefile, a one-line patch to a Config.in, and a patch which adds the driver to the tree. It would make adding new drivers to vendor kernel packages a whole lot easier and more modular if you could add a driver simply by doing: cp driver.c driver.config.in driver.mak linux/extras ...and then the makefile and config system automatically slurps this data. extras/Makefile could look something like: ...new style init.. include *.mak ...new style obj-x handling... include Rules.make Something similar would have to be worked out for Config.in. Of course, for anything complex, patching is still an option. Comments? Suggested implementation? :) I think this feature would be valuable for many vendors. In addition to making it easier to add new drivers, it makes the separation between kernel changes and vendor additions more apparently and obvious. Regards, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kmalloc questions
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Xircom problems with test9-preX
Tom Sightler wrote: > > Hi all, > > My Xircom RBEM56G-100 almost completely stops working in the latest test9-pre8 > and pre9 versions. It will still get an IP address via DHCP, but that's it, no > pings or anything. > > It works mostly correctly with test8 (quits responding when leaving promisuous > mode, and seems to hang under heavy load/collisions, but these are problems you > can usually live with). > > Backing out the attached patch returns it to the previous, mostly working > condition. This patchlet was selectively taken from the latest pcmcia-cs (3.1.21-beta). It made my NIC work correctly - without this patch the Xircom NIC incorrectly enters half-duplex mode with disastrous performance consequences. But it broke yours completely, so I guess the hunk should be backed out until David has a chance to do a full merge. Are you able to test with the latest pcmcia-cs package? A number of people (esp. David) have spent a lot of time trying to make the Xircom driver work correctly. It's being a real problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.2.16 in redhat 7.0
> Florent Cueto wrote: > > > The kernel provided with the redhat 7.0 cannot be compiled with ip > masquerading on & icmp masquerading on (using gcc and kgcc, I got the > same error). > I could not found any information about that. > Anyone can help ? Yes, make mrproper and compile again. -- Regards, Daniel - http://www.futuregate.ping-net.de ftp://futuregate.ping-net.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [KBUILD] Adding vendor drivers...
On Wed, 4 Oct 2000, Keith Owens wrote: > On Tue, 3 Oct 2000 07:11:01 -0500 (CDT), > Jeff Garzik <[EMAIL PROTECTED]> wrote: > >So, when a vendor has to add a new driver, especially with the new-style > >makefiles, you have a one-line patch to a makefile, a one-line patch to > >a Config.in, and a patch which adds the driver to the tree. > > Jeff, before making any more suggestions about the kernel build system, > please see ftp://ftp.kernel.org/pub/linux/kernel/projects/kbuild/, > makefile-wishlist-2.5-x.bz2. Your idea plus many others are already on > the wishlist for the 2.5 kernel build redesign. This is a vendor feature, MDK needs this for 2.2.x and 2.4.x kernels. It will exist before 2.5.x one way or another. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Xircom problems with test9-preX
Hi all, My Xircom RBEM56G-100 almost completely stops working in the latest test9-pre8 and pre9 versions. It will still get an IP address via DHCP, but that's it, no pings or anything. It works mostly correctly with test8 (quits responding when leaving promisuous mode, and seems to hang under heavy load/collisions, but these are problems you can usually live with). Backing out the attached patch returns it to the previous, mostly working condition. Later, Tom xircom_tulip_cb.patch
2.4.0test9pre9 - is it correct ?
Hi, I noticed the following change in the test9pre9 and doubt if it is correct. Especially as Alan Cox rejected *identical* change for 2.2 arguing that in may break some architectures with non-byte based memory addressing (especially ARM). diff -uNr linux-test9pre8/drivers/net/3c505.c linux-test9pre9/drivers/net/3c505.c --- linux-test9pre8/drivers/net/3c505.c Mon Oct 2 20:30:53 2000 +++ linux-test9pre9/drivers/net/3c505.c Tue Oct 3 15:35:22 2000 @@ -130,15 +130,15 @@ #define INVALID_PCB_MSG(len) \ printk(invalid_pcb_msg, (len),filename,__FUNCTION__,__LINE__) -static char *search_msg __initdata = "%s: Looking for 3c505 adapter at address %#x..."; +static char search_msg[] __initdata = "%s: Looking for 3c505 adapter at address +%#x..."; -static char *stilllooking_msg __initdata = "still looking..."; +static char stilllooking_msg[] __initdata = "still looking..."; [...] Could anybody confirm whether the above patch is correct or errorneus ? -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Request for net guru help: waitqueue oops
Hans Grobler wrote:
>
> On Tue, 3 Oct 2000, Petko Manolov wrote:
>
> > It seems you're trying to sleep without process context (most likely in
> > net_tx_action). It would be more clear if you send that part of the
> > code.
>
> Since I don't explictly sleep anywhere, I'm not sure which code fragment
> would be useful... (net_tx_action is part of the networking layers). Which
> network functions can sleep (netif_rx, netif_stop_queue, netif_wake_queue,
> ...) ?
None of these can sleep. netif_*_queue routines are quite simple.
They are all atomic so there is no need to protect them with locks.
> After reading the softnet HOWTO, and some of the network drivers, I
> was unsure about the netif_stop_queue and netif_wake_queue functions. The
> howto indicated that these two should be protected from concurrent
> execution by a private lock. Not all the drivers seem to do this. In my
> case (although I'm running UP at the moment), I've used a driver global
> spinlock, for example:
>
> spinlock_t driver_lock = SPIN_LOCK_UNLOCKED;
>
> int scc72_hard_xmit (struct sk_buff *skb, struct net_device *dev)
> {
> unsigned long flags;
>
> /* ... */
>
> spin_lock_irqsave (_lock, flags);
> netif_stop_queue (dev);
> spin_unlock_irqrestore (_lock, flags);
>
> /* ... */
> }
>
> /* Example timer callback, to wake the queue */
> void scc72_interframewait (unsigned long channel)
> {
> unsigned long flags;
> struct scc72_channel *scc = (struct scc72_channel *) channel;
>
> /* ... */
>
> spin_lock_irqsave (_lock, flags);
>
> /* ... */
>
> if (netif_queue_stopped (scc->dev))
> netif_wake_queue (scc->dev);
>
> spin_unlock_irqrestore (_lock, flags);
> }
It is not clear from the example above if it is needed to lock in
the timer routine and what is locked inside. Anyway be careful
about locking regions shared between interrupts/bottom halves and
user context as this happens often.
best,
Petkan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Removal of modutils/ksymoops ftp site
Serving modutils and ksymoops is too much traffic for my 56K link. With immediate effect, I have removed modutils and ksymoops from ftp.ocs.com.au. These tools can be obtained from any kernel.org mirror, they have been on kernel.org since January. ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops ftp://ftp..kernel.org/pub/linux/utils/kernel/modutils - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Request for net guru help: waitqueue oops
Hi Petkan,
Thanks for your comment.
On Tue, 3 Oct 2000, Petko Manolov wrote:
> > A driver I'm working on seems to be doing/triggering something related
> > to waitqueues. This causes a perfectly reproducable oops (small mercies!).
> > Since the oops is not happening in my driver, I'm having a hard time
> > figuring out whats going wrong. I suspect a networking guru will take
> > one look and know what I'm doing wrong. Any suggestions please?
>
>
> It seems you're trying to sleep without process context (most likely in
> net_tx_action). It would be more clear if you send that part of the
> code.
Since I don't explictly sleep anywhere, I'm not sure which code fragment
would be useful... (net_tx_action is part of the networking layers). Which
network functions can sleep (netif_rx, netif_stop_queue, netif_wake_queue,
...) ?
After reading the softnet HOWTO, and some of the network drivers, I
was unsure about the netif_stop_queue and netif_wake_queue functions. The
howto indicated that these two should be protected from concurrent
execution by a private lock. Not all the drivers seem to do this. In my
case (although I'm running UP at the moment), I've used a driver global
spinlock, for example:
spinlock_t driver_lock = SPIN_LOCK_UNLOCKED;
int scc72_hard_xmit (struct sk_buff *skb, struct net_device *dev)
{
unsigned long flags;
/* ... */
spin_lock_irqsave (_lock, flags);
netif_stop_queue (dev);
spin_unlock_irqrestore (_lock, flags);
/* ... */
}
/* Example timer callback, to wake the queue */
void scc72_interframewait (unsigned long channel)
{
unsigned long flags;
struct scc72_channel *scc = (struct scc72_channel *) channel;
/* ... */
spin_lock_irqsave (_lock, flags);
/* ... */
if (netif_queue_stopped (scc->dev))
netif_wake_queue (scc->dev);
spin_unlock_irqrestore (_lock, flags);
}
I've just checked my driver, and below is the list of all the external
functions called. Any idea which of these could be trying to sleep?
dev_kfree_skb_any (called from both hard IRQ and non IRQ context)
dev_alloc_skb (called from both hard IRQ and non IRQ context)
del_timer (called from both hard IRQ and non IRQ context)
add_timer (called from both hard IRQ and non IRQ context)
netif_rx (called from IRQ context)
netif_start_queue (called from non hard IRQ context, ex: dev_open)
netif_stop_queue (called from non hard IRQ context, ex: hard_start_xmit)
netif_wake_queue (called from non hard IRQ context, ex: timer callbacks)
netif_queue_stopped (called from non hard IRQ context, ex: timer callbacks)
skb_queue_tail(called from non hard IRQ context, ex: hard_start_xmit)
skb_dequeue (called from both hard IRQ and non IRQ context)
skb_queue_head_init (called from non hard IRQ context, ex: dev_open)
and the standard functions dev_init_buffers, register_netdevice,
copy_from_user, unregister_netdev, etc. called in the standard places.
skb_queue_tail, skb_dequeue and skb_queue_head_init are used to manage
an internal queue of outgoing skb's.
Thanks.
-- Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
For Jeff Garzik
Have to use a mailing list for this, direct TCP/IP to mandrakesoft is blocked. Jeff, the route from this side of the world to mandrakesoft is looping in bbnplanet. # traceroute 216.71.116.162 1 Loopback1.lon4.Melbourne.telstra.net (139.130.49.65) 111.222 ms 98.984 ms 108.281 ms 2 Ethernet4-0.vic.telstra.net (139.130.239.65) 108.666 ms 101.301 ms 108.524 ms 3 GigabitEthernet3-0.lon-core3.Melbourne.telstra.net (139.130.239.246) 108.863 ms 100.603 ms 108.712 ms 4 Pos2-1.way-core3.Adelaide.telstra.net (203.50.6.86) 108.566 ms 109.294 ms 108.738 ms 5 GigabitEthernet1-0.way-core4.Adelaide.telstra.net (203.50.117.18) 118.521 ms 111.377 ms 107.933 ms 6 Pos2-0.wel-core4.Perth.telstra.net (203.50.6.74) 148.647 ms 130.674 ms 139.754 ms 7 GigabitEthernet5-0.wel-core3.Perth.telstra.net (203.50.113.29) 147.267 ms 139.712 ms 149.059 ms 8 GigabitEthernet4-0.wel-gw1.Perth.telstra.net (203.50.113.18) 148.509 ms 137.705 ms 138.887 ms 9 Pos1-1.paix1.PaloAlto.telstra.net (203.50.126.26) 378.110 ms 360.816 ms 369.231 ms 10 p4-3.paloalto-cr1.bbnplanet.net (4.0.24.45) 378.010 ms 368.162 ms 378.620 ms 11 4.0.6.73 (4.0.6.73) 378.604 ms 379.503 ms 379.326 ms 12 p3-0.chcgil1-br2.bbnplanet.net (4.24.6.97) 428.137 ms 428.556 ms 438.602 ms 13 p2-0.nchicago2-br1.bbnplanet.net (4.0.5.210) 428.773 ms 427.992 ms 418.828 ms 14 p1-0.nchicago2-br2.bbnplanet.net (4.0.1.146) 578.351 ms 622.686 ms 588.305 ms 15 p1-0.nchicago2-br1.bbnplanet.net (4.0.1.145) 595.787 ms 569.973 ms 578.732 ms 16 p1-0.nchicago2-br2.bbnplanet.net (4.0.1.146) 738.297 ms 808.888 ms 748.376 ms 17 p1-0.nchicago2-br1.bbnplanet.net (4.0.1.145) 738.246 ms 798.582 ms 759.022 ms 18 p1-0.nchicago2-br2.bbnplanet.net (4.0.1.146) 887.759 ms 898.615 ms 908.512 ms 19 p1-0.nchicago2-br1.bbnplanet.net (4.0.1.145) 888.273 ms 898.957 ms 888.764 ms 20 p1-0.nchicago2-br2.bbnplanet.net (4.0.1.146) 1078.710 ms 1057.862 ms 1068.680 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Soft-Updates for Linux ?
Hi, On Mon, Oct 02, 2000 at 03:13:07AM +0200, Daniel Phillips wrote: > What I've seen proposed is a mechanism where the VM can say 'flush this > page' to a filesystem and the filesystem can then go ahead and do what > it wants, including flushing the page, flushing some other page, or not > doing anything and just being part of the problem. I'm having trouble > seeing that as a clear way for the VM to communicate what it wants. Why > is it interested in *that* page in particular? Because the VM has access to the usage patterns of those pages, and is in the best position to tell which pages are oldest and should be sent to disk and cleared from memory most quickly. > Passing in the target page seems to be an attempt at communicating some > of the LRU information that the VM maintains. If so, this is a very > low-bandwidth way of doing that. I have to admit I haven't studied the > VM the way I should, I'm still trying to preserve the fiction that one > can write a filesystem without getting involved in the memory manager. > But here is a half-baked idea: how about exporting the page aging > mechanism so a filesystem can age its own pages. Because the filesystem doesn't have anything to do with page aging. Page aging is something that happens in the VM to react to user pressure in the page cache etc. It's not something which the filesystem has any business caring about. There's good reason for this. If you have multiple different types of pages (eg. mmaped or not, mlocked or not, and pages from different filesystems) in the cache, then how is any one filesystem _ever_ going to be able to take a balanced look at memory and decide which pages are ripe to be evicted? Only the VM has that global knowledge. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
On Tue, 3 Oct 2000, Mohammad A. Haque wrote: > I'm experiencing what appears to be lockups, but probably not. They're lockups allright. I went over the VM code and buffer.c today and found a whole bunch of rescheduling points where the kernel can call schedule() while current->state != TASK_RUNNING, causing the task to never be scheduled in again ... I'm making a patch to fix those right now. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
I'm experiencing what appears to be lockups, but probably not. I'm always in X when it happens so maybe that's one source of the problem. Basically, I loose complete control of the system but it still responds to pings and still passes traffic through (my machine is also the NAT gateway on my home network). Responds to alt-sysreq-b. I can't tell if alt-sysreq-s o U work. I need to compile w/o a framebuffer so I can drop myself back to a nice console. Any else experiencing similar. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
