date:20001003

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

2000-10-03 Thread Greg KH


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?

2000-10-03 Thread Larry McVoy

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

2000-10-03 Thread Stephen Rothwell


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

2000-10-03 Thread Geoffrey Gallaway


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

2000-10-03 Thread FORT David


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?

2000-10-03 Thread John Anthony Kazos Jr.


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

2000-10-03 Thread Jerry Kelley


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

2000-10-03 Thread Horst von Brand


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/

Status of ReiserFS + Journalling

2000-10-03 Thread Magnus Naeslund


I'm setting up a big fileserver here.
The storage will be exported via ftp, samba, nfs & cvs.
I will patch the selected kernel to support LFS and LVM, and the filesystem
will run on that.

I am very interested in ReiserFS, and success/failure stories about it.
>From what I hear, ReiserFS is working really good, basically it is
production quality, and the limited testing I've done seems to tell me the
same thing.
I have _not_ tested the journaling part at all, and would like to hear from
people that have.

What I would like is to have some info on how much slower ReiserFS is with
journaling, how long the journal takes to replay, and generally if there
could be any problems with the setup I described above.
For example, will ReiserFS with journaling still beat or pair "normal" ext2,
or if it's slower, how much slower?

It would be nice to hear some theory/thoughts but real users with loaded
systems is preferred/more appreciated.
I don't know what kernel to use for this system (2.2 or 2.4-testX) and what
the ReiserFS status is on 2.4 (2.2 I've tested (suse kernel)).

Many thanks in advance,

Magnus Naeslund

P.S. Sorry for spelling etc, no spelchekar

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 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

2000-10-03 Thread Ion Badulescu

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&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5819292'.WKU.&OS=PN/5819292&RS=PN/5819292
> > >
> > > 
>http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5963962'.WKU.&OS=PN/5963962&RS=PN/5963962
> > >
> > > 
>http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=/netahtml/search-adv.htm&r=1&f=G&l=50&d=PALL&p=1&S1=6038570&OS=6038570&RS=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: Tux2 - evil patents sighted



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&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5819292'.WKU.&OS=PN/5819292&RS=PN/5819292
> >
> > 
>http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5963962'.WKU.&OS=PN/5963962&RS=PN/5963962
> >
> > 
>http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=/netahtml/search-adv.htm&r=1&f=G&l=50&d=PALL&p=1&S1=6038570&OS=6038570&RS=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: What is up with Redhat 7.0?

2000-10-03 Thread Jes Sorensen

> "Marc" == Marc Lehmann <[EMAIL PROTECTED]> writes:

Marc> On Tue, Oct 03, 2000 at 01:27:36PM +0200, Jes Sorensen
Marc> <[EMAIL PROTECTED]> wrote:
>> Looks to me like Alan's plonk was very appropriate here.

Marc> No, what Alan did was proving bad taste, or bad mood, or
Marc> whatever. This disucssion simply does not belong here and has
Marc> nothig to do with the now-off-topic disucssion about binary
Marc> incompatibility.

So far you have mainly used this as an opportunity to whine over Red
Hat.

Marc> As such, what Alan did was a cheap trick to try to draw
Marc> attention away from the real problem. He didn't succeed, of
Marc> course and I only accurse him of a temporary bad mood which I
Marc> can certainly live with ;)

What real problem? The issue of C++ was well explain, gcc 2.95 is
broken beyond repair and until we get the new 3.0 API/ABI set in stone
there isn't any real reason to even try to be compatible. WRT the
glibc-2.2 shipping then this is not going to be an issue unless there
is going to be an ABI change between now and the final 2.2 release and
then thats going to be up to RH to solve that problem - Ulrich clearly
stated that he wasn't going to take RHAT's distribution people into
consideration if there was a need for an ABI change it would
happen. Thus in this case all there is for people to scream about is
*if* an ABI change happens and RHAT doesn't deal with it properly.

Marc> On Tue, Oct 03, 2000 at 01:38:01PM +0200, Jes Sorensen
Marc> <[EMAIL PROTECTED]> wrote:
>> release? Maybe you should stop insulting the people who are
>> actually doing the Free Software work

Marc> Like myself??

You rudely insult quite a few free software developers claiming
they've put their souls up for sale and they'll budge for coorporate
pressure. So far you have proven none of those claims - which makes it
nothing but insulting.

Marc> Only a very small part, actually. That means that everybody
Marc> should play well together, rather than trying to force
Marc> non-standards onto others.

Everybody agrees that glibc-2.2 is the target to switch to as soon as
possible, whats your problem with that? It is the future standard.

>> glibc-2.2 was put out as a release candidate. gcc on the other hand
>> I don't expect to see being released anytime soon enough for it to
>> make sense (I might be wrong),

Marc> FYI: gcc is already "released" since quite some time.

Yes gcc-2.7.2.3, 2.8.1 (eeek) or egcs-1.1.2 - gcc-2.95 is too broken
to even consider.

>> binary compat problems, so far nobody has even been able to agree
>> on the naming scheme of the shared libstdc++ package, we just have
>> to wait for 3.0.

Marc> Unfortunately some company couldn't wait. The higher numbers
Marc> probably...

Oh rubbish, you have the choice between egcs-1.1.2 or gcc-2.96-cvs,
you pick the latter if you want to consider reasonable C++ support and
want the future API.

Jes
-
To unsubscribe from this list: send 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

2000-10-03 Thread willy tarreau

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&Ab2Enc=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

2000-10-03 Thread Thomas Davis


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&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5819292'.WKU.&OS=PN/5819292&RS=PN/5819292
> 
> 
>http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5963962'.WKU.&OS=PN/5963962&RS=PN/5963962
> 
> 
>http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=/netahtml/search-adv.htm&r=1&f=G&l=50&d=PALL&p=1&S1=6038570&OS=6038570&RS=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

2000-10-03 Thread Torrey Hoffman


(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 == FB_TYPE_PACKED_PIXELS

user-mode port 0.32-2.4.0-test9

2000-10-03 Thread Jeff Dike


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&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5819292'.WKU.&OS=PN/5819292&RS=PN/5819292

http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5963962'.WKU.&OS=PN/5963962&RS=PN/5963962

http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=/netahtml/search-adv.htm&r=1&f=G&l=50&d=PALL&p=1&S1=6038570&OS=6038570&RS=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

2000-10-03 Thread Brett Frankenberger


> 
> 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?

2000-10-03 Thread Jeff Dike


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

2000-10-03 Thread Thorsten Kranzkowski


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

2000-10-03 Thread J. Dow


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

2000-10-03 Thread Ion Badulescu


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

2000-10-03 Thread Dr. Kelsey Hudson


> 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 ...

2000-10-03 Thread Miquel van Smoorenburg

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

2000-10-03 Thread Jakub Jelinek


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

2000-10-03 Thread Andrius Adomaitis



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

2000-10-03 Thread Jun Sun



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

2000-10-03 Thread Martin Diehl

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

2000-10-03 Thread David Riley


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

2000-10-03 Thread Rasmus Andersen


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)
ix

Re: Update Linux 2.4 Status/TODO list

2000-10-03 Thread Peter Enderborg



[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

2000-10-03 Thread lkml recipient

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?

2000-10-03 Thread David Riley

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

2000-10-03 Thread Rasmus Andersen


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

2000-10-03 Thread Craig Whitmore




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

2000-10-03 Thread Thomas Davis


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&Ab2Enc=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

2000-10-03 Thread Graham Murray


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

2000-10-03 Thread Horst von Brand


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

2000-10-03 Thread Matti Aarnio


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

2000-10-03 Thread Russell King - ARM Linux Admin


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/

No Subject

2000-10-03 Thread larsg



-- 
"The fact that Congress elected to leave technologically unsophisticated 
persons who wish to make fair use of encrypted copyrighted works without 
the technical means of doing so is a matter for Congress"
-Judge Kaplan, in the MPAA vs 2600 ruling.
-
To unsubscribe from this list: send 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 ...

2000-10-03 Thread Matti Aarnio

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?

2000-10-03 Thread Abel Muñoz Alcaraz


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

2000-10-03 Thread Adam Sampson

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

2000-10-03 Thread Michael Merhej


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..

2000-10-03 Thread Andre Hedrick



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

2000-10-03 Thread Greg KH


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

2000-10-03 Thread Philip J. Mucci

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

2000-10-03 Thread Linus Torvalds



 - 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 (in

Re: Tux2 - evil patents sighted

2000-10-03 Thread Thomas Davis


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

2000-10-03 Thread David Hinds

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

2000-10-03 Thread TimO

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?

2000-10-03 Thread Tigran Aivazian


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++

2000-10-03 Thread Vadim Lebedev



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

2000-10-03 Thread f5ibh

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

2000-10-03 Thread Pau


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)

2000-10-03 Thread Linus Torvalds




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?

2000-10-03 Thread Justin . Skists


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?

2000-10-03 Thread Keith Owens

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

2000-10-03 Thread Christoph Lameter


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
# CONFIG_BLK_DEV_IDEDISK_MAXTOR

Re: Xircom problems with test9-preX

2000-10-03 Thread Andrew Morton


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

2000-10-03 Thread Hans Grobler

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

2000-10-03 Thread Tom Sightler


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?

2000-10-03 Thread Keith Owens


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