Re: `rmdir .` doesn't work in 2.4

[Stefan Traby]

On Mon, Jan 08, 2001 at 03:28:29PM -0800, Linus Torvalds wrote:

> But at least "rmdir `pwd`" is not _required_ to fail, like rmdir("."/"..").

"rmdir `pwd`" is required to fail (at least under csh, bash, ksh) if the
path component contains a white space and thereof it can't be a valid
replacement for Andreas "rmdir ." which was what Al initially suggested.

Yes, I'm very pickey about that; but hey, I don't want to force anyone
to write GNU/Linux like rms; just valid shell code. :)

I hope you now agree that "rmdir `pwd`" makes not much sense - except in
bug reports for bash, csh and ksh scripts or in scripts dedicated to
the Win32 environment :)

-- 

  ciao - 
Stefan

" Lession 1: Quoting.   Lession 2: Power up the machine. "
-
To unsubscribe from this list: send 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: VM subsystem bug in 2.4.0 ?

[Christoph Rohland]

Hi Rik,

On Mon, 8 Jan 2001, Rik van Riel wrote:
> And when the bit changes again, the page can be evicted
> from memory just fine. In the mean time, the locked pages
> will also have undergone normal page aging and at unlock
> time we know whether to swap out the page or not.
>
> I agree that this scheme has a higher overhead than your
> idea, but it also seems to be a bit more flexible and
> simple.  Alternatively, we could just scan the wired_list
> once a minute and move the unwired pages to the active
> list.

At IPC_UNLOCK there is no reference to the pages locked by this
segment available. We could perhaps move the whole locked list to the
active list if we unlock any segment.

Second point: How do we handle out of swap? I do not think that we
should lock these pages but keep them in the active list.

Greetings
Christoph

-
To unsubscribe from this list: send 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] advansys.c: include missing restore_flags, etc

[Pauline Middelink]

On Tue, 09 Jan 2001 around 00:14:43 -0200, Arnaldo Carvalho de Melo wrote:
> Hi,
> 
>   Please consider applying, comments in the patch.
> 
> - Arnaldo
> 
> 
> --- linux-2.4.0-ac4/drivers/scsi/advansys.c   Mon Jan  8 20:39:28 2001
> +++ linux-2.4.0-ac4.acme/drivers/scsi/advansys.c  Tue Jan  9 00:12:03 2001

> -STATIC int
> +STATIC unsigned long
>  DvcEnterCritical(void)
>  {
> -intflags;
> +unsigned long flags;
>  
>  save_flags(flags);
>  cli();
> @@ -9965,7 +9972,7 @@
>  }

Err, according tho wise ppl on this list, this does not work on
MIPSes. The flags thing must stay in the same stackframe.

(I know, not your fault, but since you are patching the driver...)

>  STATIC void
> -DvcLeaveCritical(int flags)
> +DvcLeaveCritical(unsigned long flags)
>  {
>  restore_flags(flags);
>  }

Item.

Met vriendelijke groet,
Pauline Middelink
-- 
GPG Key fingerprint = 2D5B 87A7 DDA6 0378 5DEA  BD3B 9A50 B416 E2D0 C3C2
For more details look at my website http://www.polyware.nl/~middelink
-
To unsubscribe from this list: send 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: Subtle MM bug

[Linus Torvalds]

On 8 Jan 2001, Eric W. Biederman wrote:

> Zlatko Calusic <[EMAIL PROTECTED]> writes:> 
> > 
> > Yes, but a lot more data on the swap also means degraded performance,
> > because the disk head has to seek around in the much bigger area. Are
> > you sure this is all OK?
> 
> I don't think we have more data on the swap, just more data has an
> allocated home on the swap.

I think Zlatko's point is that because of the extra allocations, we will
have worse locality (more seeks etc). 

Clearly we should not actually do any more actual IO. But the sticky
allocation _might_ make the IO we do be more spread out.

To offset that, I think the sticky allocation makes us much better able to
handle things like clustering etc more intelligently, which is why I think
it's very much worth it.  But let's not close our eyes to potential
downsides.

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/

Re: Subtle MM bug

[Eric W. Biederman]

Zlatko Calusic <[EMAIL PROTECTED]> writes:

> 
> Yes, but a lot more data on the swap also means degraded performance,
> because the disk head has to seek around in the much bigger area. Are
> you sure this is all OK?

I don't think we have more data on the swap, just more data has an
allocated home on the swap.  With the earlier allocation we should
(I haven't verified) allocate contiguous chunks of memory contiguously
on the swap.   And reusing the same swap pages helps out with this.

Eric
-
To unsubscribe from this list: send 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: Related VIA PCI crazyness?

[Eric W. Biederman]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> On Sun, 7 Jan 2001, Albert Cranford wrote:
> > > Could anybody with a VIA chip who has the energy please do something for
> > > me:
> > >  - enable DEBUG in arch/i386/kernel/pci-i386.h
> > >  - do a "/sbin/lspci -xxvvv" on the interrupt routing chip (it's the
> > >"ISA bridge" chip - the VIA numbers are 82c586, 82c596, the PCI
> > >numbers for them are 1106:0586 and 1106:0596, I think)
> > >  - do a cat /proc/pci
> > > 
> > 
> > Does this help.
> 
> Ahh, no.
> 
> A SMP kernel (or one with UP IO-APIC) is not going to be helpful for this,
> actually. SMP will take the irq data from the MP block, not the pirq table
> (that can be considered something of a misfeature right now, but getting
> the mixture of PCI irq redirection from the MP tables and the pirq irq
> routing information right together is probably not worth it - especially
> as I don't think any MS OS has ever done that either, so the BIOS writers
> have never experienced that combination - so it's almost guaranteed to
> result in strange results).

pirq is specific to they legacy i8259 interrupt handler.
MP is specific to some kind of IO-APIC.

Right now when we enable the IO-APIC we disable the legacy i8259
controller.  And I'm not even certain you can have them both enabled
at the same time.

So except for not having an option to disable use of the IO-APIC
I don't see what we could do better.

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

[Announcement] kgdb - unofficial (untested) patch available for 2.4.0

[Paul Schulz]

For those who are interested..

I have taken the kgdb patch for 2.4.0-test9 and ported it to 2.4.0.
This is a minimal patch, and doesn't include any of the documentation
or supporting programmes. It can be found at:

http://www.foursticks.com.au/~pschulz/kgdb
http://www.foursticks.com.au/~pschulz/kgdb/linux-2.4.0-kgdb.patch

There is also a patch for 2.4.0-test12

http://www.foursticks.com.au/~pschulz/kgdb/linux-2.4.0-test12-kgdb.patch

For more information see...

http://kgdb.sourceforge.net

kgdb is a patch to the linux kernel. It allows use of gdb for source level
debugging of a linux kernel. One can place breakpoints, step through code
and observe variables in the kernel similar to debugging a program.

For using kgdb you need two machines. One of these machines is the development
machine and the other is tests machine. The kernel to be debugged runs
on the tests machine. gdb runs on the development machine. The machines
are connected through a serial line. The serial line is used by gdb to
communicate to the kernel being debugged.



-
To unsubscribe from this list: send 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.2.19pre6aa1 degraded performance for me...

[Sasi Peter]

On Tue, 9 Jan 2001, Andrea Arcangeli wrote:

> On Mon, Jan 08, 2001 at 10:46:29PM +0100, Sasi Peter wrote:
> > What I had w/2.2.18pre19 (+raid+ide):
> > ~80MB more in cache and ~80MB swapped out (eg. currently unused notes
> > server and squid) There is enough of swap over 3 disks (like the
> > raid), so I did not bother disabling squid and notes, since - I thought -
> > they would only take up some swap unused.
>
> There are many variables. However I guess the slowdown is because your idle
> apps didn't got swapped out in favour of cache as you noticed. An aggressive
> aging algorithm would probably fix that but it then would hurt other cases
> (after you don't need a frequenty accessed part of filesystem cache anymore it
> would take ages before it gets collected potentially causing an unnecessary
> swapout storms because the kernel doesn't know you don't need such cache
> anymore).  Furthmore if notes and squid are rarely running but they provides
> critical services if they would go totally into swap in favour of fs cache you
> would get very bad latencies the first time somebody connects to the server. So
> the fix I suggest you is to buy more ram or to shutdown squid and notes. Than

Oh well I thought 384MB should be enought for everyone aiming at this
performance (almost TM ;). At least it would up till now :(

> you may as well see a performance improvement compared to 2.2.18pre19
> (+raid+ide).  Otherwise you can push the machine low on memory a bit until they
> both goes totally into swap (check with `ps v`). Hope this helps.

I'll try this, thanks. (so no echo '1 23 456' >/proc/sys/vm/...?)

-- 
SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/


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

Sorry about the email. . (re: 2.4.0-ac4)

[David Joyce]

  I'm sure this isn't the address to send this to, but I
don't know where to send this.

I just upgraded from 2.4.0-test12 to 2.4.0, and I got a
kernel panac after about 6 hours.  Then updated to 2.4.0-ac4
and got a massive amount of scsi errors.  The server was again
up for about 6 hours.  This was in the syslog:

-
Jan  8 16:51:34 kenny kernel: (scsi0:-1:-1:-1) Referenced SCB 12 not valid
during SELTO.
Jan  8 16:51:34 kenny kernel: SCSISEQ = 0x5a SEQADDR = 0x8 SSTAT0 =
0x10 SSTAT1 = 0x88
Jan  8 16:51:34 kenny kernel: (scsi0:-1:-1:-1) Referenced SCB 12 not valid
during SELTO.
Jan  8 16:51:34 kenny kernel: SCSISEQ = 0x5a SEQADDR = 0x8 SSTAT0 =
0x10 SSTAT1 = 0x88
Jan  8 16:51:34 kenny kernel: (scsi0:-1:-1:-1) Referenced SCB 12 not valid
during SELTO.
Jan  8 16:51:34 kenny kernel: SCSISEQ = 0x5a SEQADDR = 0x8 SSTAT0 =
0x10 SSTAT1 = 0x88
Jan  8 16:51:34 kenny kernel: (scsi0:-1:-1:-1) Referenced SCB 12 not valid
during SELTO.
Jan  8 16:51:34 kenny kernel: SCSISEQ = 0x5a SEQADDR = 0x8 SSTAT0 =
0x10 SSTAT1 = 0x88
Jan  8 16:51:34 kenny kernel: (scsi0:0:1:0) Synchronous at 80.0 Mbyte/sec,
offset 63.
Jan  8 16:51:34 kenny kernel: (scsi0:0:3:0) Synchronous at 80.0 Mbyte/sec,
offset 63.
Jan  8 16:51:56 kenny kernel: SCSI host 0 abort (pid 0) timed out -
resetting
Jan  8 16:51:56 kenny kernel: SCSI bus is being reset for host 0 channel 0.
Jan  8 16:51:57 kenny kernel: SCSI host 0 channel 0 reset (pid 0) timed
out - trying harder
Jan  8 16:51:57 kenny kernel: SCSI bus is being reset for host 0 channel 0.
Jan  8 16:51:57 kenny kernel: SCSI host 0 reset (pid 0) timed out again -
Jan  8 16:51:57 kenny kernel: probably an unrecoverable SCSI bus or device
hang.
Jan  8 16:52:04 kenny kernel: scsi : aborting command due to timeout : pid
0, scsi0, channel 0, id 2, lun 0 0x2a 00 00
 1b 00 5c 00 00 08 00
Jan  8 16:52:04 kenny kernel: scsi : aborting command due to timeout : pid
0, scsi0, channel 0, id 2, lun 0 0x2a 00 00
 1b 00 68 00 00 08 00
Jan  8 16:52:04 kenny kernel: scsi : aborting command due to timeout : pid
0, scsi0, channel 0, id 2, lun 0 0x2a 00 00
 1b 00 84 00 00 04 00
--

The server board is an Intel STL2, with one P3-800.  I will atach my current
dmesg.
Thanks for any help

Dave Joyce
ProbeTalk.com server admin


Jan  8 21:00:06 kenny syslogd 1.3-3#33.1: restart.
Jan  8 21:00:06 kenny kernel: klogd 1.3-3#33.1, log source = /proc/kmsg started.
Jan  8 21:00:06 kenny kernel: Inspecting /System.map
Jan  8 21:00:06 kenny kernel: Loaded 11761 symbols from /System.map.
Jan  8 21:00:06 kenny kernel: Symbols match kernel version 2.4.0.
Jan  8 21:00:06 kenny kernel: No module symbols loaded - kernel modules not enabled. 
Jan  8 21:00:06 kenny kernel: de 0 totalpages: 65520
Jan  8 21:00:06 kenny kernel: zone(0): 4096 pages.
Jan  8 21:00:06 kenny kernel: zone(1): 61424 pages.
Jan  8 21:00:06 kenny kernel: zone(2): 0 pages.
Jan  8 21:00:06 kenny kernel: Intel MultiProcessor Specification v1.4
Jan  8 21:00:06 kenny kernel: Virtual Wire compatibility mode.
Jan  8 21:00:06 kenny kernel: OEM ID: INTELProduct ID: STL2 APIC at: 
0xFEE0
Jan  8 21:00:06 kenny kernel: Processor #0 Pentium(tm) Pro APIC version 17
Jan  8 21:00:06 kenny kernel: Floating point unit present.
Jan  8 21:00:06 kenny kernel: Machine Exception supported.
Jan  8 21:00:06 kenny kernel: 64 bit compare & exchange supported.
Jan  8 21:00:06 kenny kernel: Internal APIC present.
Jan  8 21:00:06 kenny kernel: SEP present.
Jan  8 21:00:06 kenny kernel: MTRR  present.
Jan  8 21:00:06 kenny kernel: PGE  present.
Jan  8 21:00:06 kenny kernel: MCA  present.
Jan  8 21:00:06 kenny kernel: CMOV  present.
Jan  8 21:00:06 kenny kernel: PAT  present.
Jan  8 21:00:06 kenny kernel: PSE  present.
Jan  8 21:00:06 kenny kernel: PSN  present.
Jan  8 21:00:06 kenny kernel: MMX  present.
Jan  8 21:00:06 kenny kernel: FXSR  present.
Jan  8 21:00:06 kenny kernel: XMM  present.
Jan  8 21:00:06 kenny kernel: Bootup CPU
Jan  8 21:00:06 kenny kernel: Bus #0 is PCI   
Jan  8 21:00:06 kenny kernel: Bus #1 is PCI   
Jan  8 21:00:06 kenny kernel: Bus #2 is ISA   
Jan  8 21:00:06 kenny kernel: I/O APIC #4 Version 17 at 0xFEC0.
Jan  8 21:00:06 kenny kernel: I/O APIC #5 Version 17 at 0xFEC01000.
Jan  8 21:00:06 kenny kernel: Int: type 3, pol 1, trig 1, bus 2, IRQ 00, APIC ID 4, 
APIC INT 00
Jan  8 21:00:06 kenny kernel: Int: type 0, pol 1, trig 1, bus 2, IRQ 01, APIC ID 4, 
APIC INT 01
Jan  8 21:00:06 kenny kernel: Int: type 0, pol 1, trig 1, bus 2, IRQ 00, APIC ID 4, 
APIC INT 02
Jan  8 21:00:06 kenny kernel: Int: type 0, pol 1, trig 1, bus 2, IRQ 03, APIC ID 4, 
APIC INT 03
Jan  8 21:00:06 kenny kernel: Int: type 0, pol 1, trig 1, bus 2, IRQ 04, APIC ID 4, 
APIC INT 04
Jan  8 21:00:06 kenny kernel: Int: type 0, pol 3, trig 3, bus 1, IRQ 11, APIC ID 5, 

Re: [PATCH] More compile warning fixes for 2.4.0

[Richard Henderson]

On Mon, Jan 08, 2001 at 08:50:01PM +0100, Erik Mouw wrote:
> Is this really a kernel bug? This is common idiom in C, so gcc
> shouldn't warn about it. If it does, it is a bug in gcc IMHO.

No, it is not a common idiom in C.  It has _never_ been valid C.

GCC originally allowed it due to a mistake in the grammar; we
now warn for it.  Fix your source.


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

Re: question on generating a patch

[Peter Samuelson]

[David L. Parsley]
> I read the FAQ and SubmittingPatches, but how best to generate a
> patch that moves a file from on dir to another?  diff -urNP makes the
> patch a lot longer than it seems like it should be...

A major weakness of the 'patch' command -- you cannot gracefully move
or rename files.  Larry Wall saw this years ago and invented a hybrid
sort of patch that runs as a shar-like shell script, moving things
around before actually applying itself as a patch.  But most people,
including linux-kernel, don't use lwall's patch+shar format.


- If it's a fairly small file anyway, just use 'diff -urN' and don't
worry about it.

- If it's a large file or several files, or if you are making
significant changes to said files besides moving them, you should
probably list two separate steps: first, describe the rearrangement,
perhaps as a series of 'mv' commands; second, give us a patch against
the new arrangement.


Either way, you need to make it clear what changes, if any, have been
made to a particular file "in transit".  With just 'diff -urN' and no
explanation, it is hard to tell one way or the other.

Peter
-
To unsubscribe from this list: send 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: `rmdir .` doesn't work in 2.4

[Marc Lehmann]

On Tue, Jan 09, 2001 at 02:55:15AM +0100, Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> > [wakko@:/home/wakko/test] rmdir "`pwd`"
> > rmdir: /home/wakko/test: Invalid argument
> 
> Some other OS with a yet different retval? :)

It can be much worse (irix-6.5.4):

   bash# mkdir x; cd x; rmdir "`pwd`"
   /x: Can't remove current directory or ..

Here the error message makes sense - but is totally wron in this case :(

And here is linux-2.2.18:

   cerebro:~# mkdir x; cd x;rmdir "`pwd`"
   cerebro:~/x# ls -la
   total 6
   drwxr-x---   0 root root   35 Jan  9 05:54 .
   drwx--  69 root root 5372 Jan  9 05:54 ..
   cerebro:~/x# cd
   cerebro:~# ls -la x
   ls: x: No such file or directory

So, no, linux certainly does NOT remove "." ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
-
To unsubscribe from this list: send 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: Delay in authentication.gy

[Andi Kleen]

On Mon, Jan 08, 2001 at 10:01:26PM +, Alan Cox wrote:
> > It was intentionally changed because there is no way for the "ICMP
> > port unreachable" message coming back to be uniquely matched to that
> > UDP socket.  It can reset sockets illegally in high load scenerios.
> > 
> > Solaris and other systems act identically.
> 
> And have identical bad problems with auth failures. Right now I've given up
> trying to make 2.4 and YP mix because my RH setup assumes NIS auth will fail
> fast during boot up scripts and it doesnt.
> 
> Unfortunately for the quickfix folks, Dave is right about needing to sort it,
> and that means someone has to sort glibc to use the new interfaces

If anyone wants to fix and doesn't know how -- 
http://www.firstfloor.org/~andi/OLS/img27.htm and following slides describe the
Linux interface. Note that msg_name as original destination is not set in some 2.2 
kernels, so that needs to be handled too. 



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

UDP performance drop from -test9 to 2.4.0 (fwd)

[Todd]

sorry for the resend. i sent this earlier today but still haven't seen it,
so i'm resending without attachments.

the originally attached netperf results are at:

http://www.unm.edu/~todd/udp.2.4.0-test9.9000mtu
http://www.unm.edu/~todd/udp.2.4.0-test9.1500mtu
http://www.unm.edu/~todd/udp.2.4.0.9000mtu
http://www.unm.edu/~todd/udp.2.4.0.1500mtu

-- Forwarded message --
Date: Mon, 8 Jan 2001 09:38:24 -0700 (MST)
From: Todd <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: UDP performance drop from -test9 to 2.4.0

folx,

i'm seeing a signficant performance decline between the -test9 and the
release version 2.4.0 on udp on acenic gig-e cards.  i should say that
the performance is startlingly better than it was under 2.2.14 (where the
best we could get was 150+ Mbps on udp) but it still represents a
signficant decline.

i'm attaching netperf numbers with 1500 and 9000 byte mtus for both kernel
versions (with interrupt coalescing and everything else as default--this
is just a compile/boot/test scenario with no tuning in particular).
standard kernel, standard /proc settings, standard acenic firmware and
driver that shipped with the version in question.

the summary of results:  12% reduction in performance at 1500-byte mtu, 6%
reduction at 9000.  when looking at the results remember that the second
line in each case is the 'receive bandwith' line, which is the only useful
number to report.

kernel version  max udp bandwithmtu message size
==  === 
2.4.0-test9 554.9   15001470
2.4.0-test9 636.7   90008870
2.4.0   489.4   15001470
2.4.0   597.3   90007270

both versions show the horrible effect that the reassembly of fragments
has on receive bandwith, but that's not really my question for the day
:-).

any info would be helpful.  i'd be happy to run any further tests to get
at the bottom of this.

todd

=
Todd Underwood, [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/

question on generating a patch

[David L. Parsley]

I read the FAQ and SubmittingPatches, but how best to generate a patch
that moves a file from on dir to another?  diff -urNP makes the patch a
lot longer than it seems like it should be... (fortunately it's just a
short header file)

Is there a better way?

regards,
David
-- 
David L. Parsley
Network Administrator
Roanoke College
-
To unsubscribe from this list: send 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: Confirmation request about new 2.4.x. kernel limits

[Venkatesh Ramamurthy]

> Max. RAM size:64 GB   (any slowness
accessing RAM over 4 GB
*   with 32 bit machines ?)
Imore than 4GB in RAM is bounce buffered, so there is performance
penalty as the data have to be copied into the 4GB RAM area
-
To unsubscribe from this list: send 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: FS callback routines

[David Weinehall]

On Mon, Jan 08, 2001 at 11:12:24PM +, Michael D. Crawford wrote:

[snipped a lot of sane opinions]
> While Be, Inc.'s implementation is closed-source, the design of the
> BFS (_not_ "befs" as it is sometimes called) is explained in Practical
> File System Design with the Be File System by Dominic Giampolo, ISBN
> 1-55860-497-9.  Dominic has since left Be and I understand works at
> Google now.

The reason why BFS is often referred to as BeFS, is that there is a
another file-system, far older than Be's filesystem AFAIK, called BFS;
the SCO Unixware Boot File System, which is already supported in the
Linux-kernel. Hence the misnomer BeFS. I think we should keep it that
way to avoid confusion... After all, BeFS does indicate pretty well what
file-system we mean, and other alternatives, such as be_bfs, or renaming
SCO BFS to sco_bfs or similar feels awkward.


/David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

AHA1542 driver does not accept command-line options

[Dmitry Potapov]

When I switch to 2.4 kernel my SCSI card does not detect anymore,
because AHA1542 driver does not accept kernel command-line options.

I send small patch to fix that.

I'm not subscribed at the kernel mail list, so please send any 
question/answer to my personal mail address.

Thanks,
Dmitry Potapov

--- drivers/scsi/aha1542.c.orig Thu Nov 23 20:33:36 2000
+++ drivers/scsi/aha1542.c  Tue Jan  9 04:45:12 2001
@@ -947,11 +947,12 @@
return 0;
 }
 
-/* called from init/main.c */
+#ifndef MODULE
+static int setup_idx = 0;
+
 void __init aha1542_setup(char *str, int *ints)
 {
const char *ahausage = "aha1542: usage: 
aha1542=[,,[,]]\n";
-   static int setup_idx = 0;
int setup_portbase;
 
if (setup_idx >= MAXBOARDS) {
@@ -1004,6 +1005,21 @@
 
++setup_idx;
 }
+
+static int __init do_setup(char *str)
+{
+   int ints[4];
+
+   int count=setup_idx;
+
+   get_options(str, sizeof(ints)/sizeof(int), ints);
+   aha1542_setup(str,ints);
+
+   return counthttp://www.tux.org/lkml/

[PATCH] 2.4.0 Changes - add compiler source code URL, minor cleanup

[Barry K. Nathan]

The following patch:

(a) Adds a URL for the egcs 1.1.2 source code. This change is both
low-risk and important IMO.

(b) Fixes two sloppy underlines.

Please apply.

-Barry K. Nathan <[EMAIL PROTECTED]>


--- linux-2.4.0/Documentation/Changes   Mon Jan  1 10:00:04 2001
+++ linux-2.4.0bkn1/Documentation/Changes   Mon Jan  8 19:09:44 2001
@@ -31,7 +31,7 @@
 Eine deutsche Version dieser Datei finden Sie unter
 .
 
-Last updated: December 11, 2000
+Last updated: January 8, 2001
 
 Chris Ricker ([EMAIL PROTECTED] or [EMAIL PROTECTED]).
 
@@ -261,12 +261,16 @@
 Compilers
 *
 
-egcs 1.1.2 (gcc 2.91.66)
--
+egcs 1.1.2 (gcc 2.91.66) binaries
+-
 o  
 o  
 o  
 
+egcs 1.1.2 (gcc 2.91.66) source code
+
+o  
+
 Binutils
 
 
@@ -275,7 +279,7 @@
 o  
 
 2.10 series
-
+---
 o  
 
 System utilities
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

netfilter ipv6 as module unresolved symbols

[Frank Dekervel]

Hello,

test13-acXX and final-acXX have unresolved symbols, namely
ipt_register_target and ipt_unregister_target in the module
ip6t_MARK.o

Greetings,

Kervel

-
To unsubscribe from this list: send 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: Subtle MM bug

[Linus Torvalds]

On 9 Jan 2001, Zlatko Calusic wrote:
> 
> Yes, but a lot more data on the swap also means degraded performance,
> because the disk head has to seek around in the much bigger area. Are
> you sure this is all OK?

Yes and no.

I'm not _sure_, obviously.

However, one thing I _am_ sure of is that the sticky page-cache simplifies
some things enormously, and make some things possible that simply weren't
possible before. 

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/

Re: Subtle MM bug (really 830MB barrier question)

[Wayne Whitney]

On Mon, Jan 08, 2001 at 03:22:44PM -0800, Wayne Whitney wrote:

> I guess I conclude that either (1) MAGMA does not use libc's malloc
> (checking on this, I doubt it)

I'm still a bit unclear on this one.  I now have two executables,
magma.exe and magma.exe.dyn (ignore the .exe).  magma.exe is statically
linked, and magma.exe.dyn is dynamically linked against libc.so.6.  But
the binaries are the same size!  Well 13.7MB and 13.4MB, respectively.

'strings magma.exe' does not mention MALLOC_MMAP_*, so I conclude it is
statically linked against an older libc (libc.so.5?).  Is it possible that
magma.exe.dyn is statically linked against libc.so.5 and dynamically
linked against libc.so.6, so that the older malloc is getting used?  This
would explain the size similarity.

> or (2) glibc-2.1.92 knows of these variables but has not yet
> implemented the tuning (I'll try glibc-2.2) or

I see the same behavior with glibc-2.2 as with glibc-2.1.92.

On Tue, 9 Jan 2001, Andrea Arcangeli wrote:

> You should monitor the program with strace while it fails (last few
> syscalls).

At the very end of this message is the (slightly edited) strace of the
following test magma session:

  Magma V2.7-4  Mon Jan  8 2001 21:27:34 on modular  [Seed = 3551764170]
  Type ? for help.  Type -D to quit.
  > M1:=MatrixAlgebra(Rationals(),1)!1;
  > M2:=MatrixAlgebra(Rationals(),1)!1;
  > M3:=MatrixAlgebra(Rationals(),1)!1;

  System error: Out of memory.
  All virtual memory has been exhausted so Magma cannot perform this
  statement.

Here I try three times to allocate a 1x1 matrix of a 32bit data
type, so each matrix takes up 4e8 bytes.

My limited understanding of the strace output is that magma.exe allocates
memory by calling brk() to increase the size of its data segment, and
brk() returns the new size of the data segment (on complete success, this
is the size requested), but that eventually this sequence fails with:

brk(0x53567c68) = 0x3b807d68

> You can breakpoint at exit() and run `cat /proc/pid/maps` to show us
> the vma layout of the task.

I'm not sure how to set a breakpoint, I didn't see anything in the strace
man page about it handling this.  Do I need to use gdb? I tried 'rbreak
exit' and 'rbreak _exit' with gdb, and those didn't work.

But I did check /proc/pid/maps each time I got MAGMA's > prompt.  Here is
the output the first time (before allocating any matrices):

08048000-08b5c000 r-xp  03:05 1130923/tmp/newmagma/magma.exe.dyn
08b5c000-08cc9000 rw-p 00b13000 03:05 1130923/tmp/newmagma/magma.exe.dyn
08cc9000-0bd0 rwxp  00:00 0
4000-40016000 r-xp  03:05 393301 /lib/ld-2.2.so
40016000-40017000 rw-p 00015000 03:05 393301 /lib/ld-2.2.so
40017000-40018000 rwxp  00:00 0
40018000-40019000 rw-p  00:00 0
40024000-40043000 r-xp  03:05 393307 /lib/libm-2.2.so
40043000-40044000 rw-p 0001e000 03:05 393307 /lib/libm-2.2.so
40044000-40164000 r-xp  03:05 393304 /lib/libc-2.2.so
40164000-4016a000 rw-p 0011f000 03:05 393304 /lib/libc-2.2.so
4016a000-4016e000 rw-p  00:00 0
bfffe000-c000 rwxp f000 00:00 0

Now, subsequent to each memory allocation, only the second number in the
third line changes.  It becomes 23a78000, then 3b7f, and finally
3b808000 (after the failed allocation).

Sorry this is a bit long, I wanted to include the full strace output in
case it would allow one to divine what memory allocation scheme this
program is using.  Did I mention that a different mathematics package,
pari (for which I have the source), does not see this 830MB limit?  It
will happily allocate more memory (I haven't checked whether it hits a
limit around 1.5GB).

Thanks again for all the responses, they are quite helpful and educational
and heart-warming!!

Cheers,
Wayne

execve("/tmp/newmagma/magma.exe.dyn", ["/tmp/newmagma/magma.exe.dyn"], [/* 27 vars 
*/]) = 0
uname({sys="Linux", node="modular", ...}) = 0
brk(0)  = 0xbce7460
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=45881, ...}) = 0
old_mmap(NULL, 45881, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40018000
close(4)= 0
open("/lib/libm.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20J\0\000"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=503435, ...}) = 0
old_mmap(NULL, 128760, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40024000
mprotect(0x40043000, 1784, PROT_NONE)   = 0
old_mmap(0x40043000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1e000) = 
0x40043000
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\301\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=4851725, ...}) = 0
old_mmap(NULL, 1

Re: [PATCH] cramfs is ro only, so honour this in inode->mode

[Linus Torvalds]

On Tue, 9 Jan 2001, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you
>  write:
> > I've been thinking of doing a cramfs2, and the only thing I'd change is
> > (a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
> > meta-data and the real data so that I could easily compress the metadata
> > too. cramfs doesn't have any traditional meta-data (no bitmap blocks or
> > anything like that), but it wouldn't be that hard to put the directory
> > structure in the page cache and just compress the directories the same way
> > the real data is compressed.
> 
> And you'd still be worse than compressed loopback w/32k blocks, and
> more complex.  Now most of the loopback bugs seem fixed in 2.4, I'll
> port the cloop stuff, and we can compare.

If you compare, make sure that you don't compare the way some people seem
to compare. They see how well the ext2 image compresses, and ignore the
fact that the ext2 image itself has a lot of extraneous stuff (alignment,
bitmaps, very compressible meta-data etc).

The only valid comparison is how big the actual image file is for the same
trees. Also, you should take into account the size of the ext2 module and
cloop. I don't think you'd win.

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/

RE: FS callback routines

[Sean R. Bright]

Agreed.

I will have a look at the URLs you passed along.  I was talking to a
colleague about this just after I sent the initial message and the number of
places where this would be useful suddenly became much more apparent to me
:)  For example, _ANY_ daemon process could be notified of configuration
changes when they happen, mail servers/spoolers would have immediate access
to the locations of files, without tying up the disk with polling.  All and
all a very good idea (and its not even mine anymore it would seem, so I can
say that! :))

Thanks again,
Sean

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Michael D.
> Crawford
> Sent: Monday, January 08, 2001 6:12 PM
> To: [EMAIL PROTECTED]
> Subject: Re: FS callback routines
>
>
> Regarding notification when there's a change to the filesystem:
>
> This is one of the most significant things about the BeOS BFS
> filesystem, and
> something I'd dearly love to see Linux adopt.  It makes an
> app very efficient,
> you just get notified when a directory changes and you never
> waste time polling.
>
> I think it would require changes to the VFS layer, not just
> to the filesystems,
> because this is a concept POSIX filesystems do not presently possess.
>
> The other is indexed filesystem attributes, for example a
> file can have its
> mimetype in the filesystem, and any application can add an
> attribute and have it
> indexed.
>
> There's a method to do boolean queries on indexed attributes,
> and you can find
> files in an entire filesystem that match a query in a
> blazingly short time, much
> faster than walking the directory tree.
>
> If you want to try out the BeOS, there's a free-as-in-beer version at
> http://free.be.com for Pentium PC's.  You can also purchase a
> version that comes
> for both PC's and certain PowerPC macs.
>
> There are read-only versions of this for Linux which I
> believe are under the
> GPL.  The original author is here:
>
> http://hp.vector.co.jp/authors/VA008030/bfs/
>
> He refers you to here to get a version that works under 2.2.16:
>
> http://milosch.net/beos/
>
> The author's intention was to take it read-write, but it's
> complex because it is
> a journaling filesystem.
>
> Daniel Berlin, a BeOS developer modified the Linux BFS driver
> so it works with
> 2.4.0-test1.  I don't know if it works with 2.4.0.  The web
> site where it used
> to be posted isn't there anymore, and the laptop where I had
> it is in for
> repair.  I may have it on a backup, and I'll see if I can
> track Daniel down.
>
> While Be, Inc.'s implementation is closed-source, the design
> of the BFS (_not_
> "befs" as it is sometimes called) is explained in Practical
> File System Design
> with the Be File System by Dominic Giampolo, ISBN
> 1-55860-497-9.  Dominic has
> since left Be and I understand works at Google now.
>
>
> --
> Michael D. Crawford
> GoingWare Inc. - Expert Software Development and Consulting
> http://www.goingware.com/
> [EMAIL PROTECTED]
>
>Tilting at Windmills for a Better Tomorrow.
> -
> To unsubscribe from this list: send 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: FS callback routines

[Michael D. Crawford]

Regarding notification when there's a change to the filesystem:

This is one of the most significant things about the BeOS BFS filesystem, and
something I'd dearly love to see Linux adopt.  It makes an app very efficient,
you just get notified when a directory changes and you never waste time polling.

I think it would require changes to the VFS layer, not just to the filesystems,
because this is a concept POSIX filesystems do not presently possess.

The other is indexed filesystem attributes, for example a file can have its
mimetype in the filesystem, and any application can add an attribute and have it
indexed.

There's a method to do boolean queries on indexed attributes, and you can find
files in an entire filesystem that match a query in a blazingly short time, much
faster than walking the directory tree.

If you want to try out the BeOS, there's a free-as-in-beer version at
http://free.be.com for Pentium PC's.  You can also purchase a version that comes
for both PC's and certain PowerPC macs.

There are read-only versions of this for Linux which I believe are under the
GPL.  The original author is here:

http://hp.vector.co.jp/authors/VA008030/bfs/

He refers you to here to get a version that works under 2.2.16:

http://milosch.net/beos/

The author's intention was to take it read-write, but it's complex because it is
a journaling filesystem.

Daniel Berlin, a BeOS developer modified the Linux BFS driver so it works with
2.4.0-test1.  I don't know if it works with 2.4.0.  The web site where it used
to be posted isn't there anymore, and the laptop where I had it is in for
repair.  I may have it on a backup, and I'll see if I can track Daniel down.

While Be, Inc.'s implementation is closed-source, the design of the BFS (_not_
"befs" as it is sometimes called) is explained in Practical File System Design
with the Be File System by Dominic Giampolo, ISBN 1-55860-497-9.  Dominic has
since left Be and I understand works at Google now.


-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

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

[PATCH] eata_dma.c: include missing restore_flags

[Arnaldo Carvalho de Melo]

Hi,

Please consider applying.

- Arnaldo

--- linux-2.4.0-ac4/drivers/scsi/eata_dma.c Mon Jan  8 20:39:29 2001
+++ linux-2.4.0-ac4.acme/drivers/scsi/eata_dma.cTue Jan  9 00:25:54 2001
@@ -482,7 +482,7 @@
 DBG(DBG_REQSENSE, printk(KERN_DEBUG "Tried to REQUEST SENSE\n"));
cmd->result = DID_OK << 16;
done(cmd);
-
+   restore_flags(flags);
return(0);
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] advansys.c: include missing restore_flags, etc

[Arnaldo Carvalho de Melo]

Hi,

Please consider applying, comments in the patch.

- Arnaldo


--- linux-2.4.0-ac4/drivers/scsi/advansys.c Mon Jan  8 20:39:28 2001
+++ linux-2.4.0-ac4.acme/drivers/scsi/advansys.cTue Jan  9 00:12:03 2001
@@ -717,6 +717,13 @@
  Ken Mort <[EMAIL PROTECTED]> reported a DEBUG compile bug fixed
  in 3.2K.
 
+ Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> fix issues
+ related to save_flags/restore_flags, some restore_flags and
+ DvcLeaveCritical were missing, use unsigned long flags instead
+ of int flags, a not needed cli commented out, like the sti
+ that matches it (in advansys_abort) - 08/01/2001
+ 
+
   L. AdvanSys Contact Information
  
  Mail:   Advanced System Products, Inc.
@@ -2098,8 +2105,8 @@
 STATIC uchar AscGetChipIRQ(PortAddr, ushort);
 STATIC uchar AscSetChipIRQ(PortAddr, uchar, ushort);
 STATIC ushortAscGetChipBiosAddress(PortAddr, ushort);
-STATIC int   DvcEnterCritical(void);
-STATIC void  DvcLeaveCritical(int);
+STATIC unsigned long DvcEnterCritical(void);
+STATIC void  DvcLeaveCritical(unsigned long);
 STATIC void  DvcInPortWords(PortAddr, ushort *, int);
 STATIC void  DvcOutPortWords(PortAddr, ushort *, int);
 STATIC void  DvcOutPortDWords(PortAddr, ASC_DCNT *, int);
@@ -3103,8 +3110,8 @@
 /*
  * Device drivers must define the following functions.
  */
-STATIC int   DvcEnterCritical(void);
-STATIC void  DvcLeaveCritical(int);
+STATIC unsigned long  DvcEnterCritical(void);
+STATIC void  DvcLeaveCritical(unsigned long);
 STATIC void  DvcSleepMilliSecond(ADV_DCNT);
 STATIC uchar DvcAdvReadPCIConfigByte(ADV_DVC_VAR *, ushort);
 STATIC void  DvcAdvWritePCIConfigByte(ADV_DVC_VAR *, ushort, uchar);
@@ -5938,7 +5945,7 @@
 {
 struct Scsi_Host*shp;
 asc_board_t *boardp;
-int flags;
+unsigned long   flags;
 Scsi_Cmnd   *done_scp;
 
 shp = scp->host;
@@ -6033,7 +6040,7 @@
 asc_board_t *boardp;
 ASC_DVC_VAR *asc_dvc_varp;
 ADV_DVC_VAR *adv_dvc_varp;
-int flags;
+unsigned long   flags;
 int do_scsi_done;
 int scp_found;
 Scsi_Cmnd   *done_scp = NULL;
@@ -6138,7 +6145,7 @@
 ret = SCSI_ABORT_ERROR;
 break;
 }
-cli();
+/* cli(); XXX */
 } else {
 /*
  * Wide Board
@@ -6278,7 +6285,7 @@
 asc_board_t  *boardp;
 ASC_DVC_VAR  *asc_dvc_varp;
 ADV_DVC_VAR  *adv_dvc_varp;
-int  flags;
+unsigned longflags;
 Scsi_Cmnd*done_scp = NULL, *last_scp = NULL;
 Scsi_Cmnd*tscp, *new_last_scp;
 int  do_scsi_done;
@@ -9954,10 +9961,10 @@
 #endif /* version < v2.1.0 */ 
 }
 
-STATIC int
+STATIC unsigned long
 DvcEnterCritical(void)
 {
-intflags;
+unsigned long flags;
 
 save_flags(flags);
 cli();
@@ -9965,7 +9972,7 @@
 }
 
 STATIC void
-DvcLeaveCritical(int flags)
+DvcLeaveCritical(unsigned long flags)
 {
 restore_flags(flags);
 }
@@ -12173,7 +12180,7 @@
 )
 {
 PortAddriop_base;
-int last_int_level;
+unsigned long   last_int_level;
 int sta;
 int n_q_required;
 int disable_syn_offset_one_fix;
@@ -12235,6 +12242,7 @@
 #if !CC_VERY_LONG_SG_LIST
 if (sg_entry_cnt > ASC_MAX_SG_LIST)
 {
+DvcLeaveCritical(last_int_level);
 return(ERR);
 }
 #endif /* !CC_VERY_LONG_SG_LIST */
@@ -13112,7 +13120,7 @@
 ASC_QDONE_INFO  scsiq_buf;
 ASC_QDONE_INFO *scsiq;
 ASC_ISR_CALLBACKasc_isr_callback;
-int last_int_level;
+unsigned long   last_int_level;
 
 iop_base = asc_dvc->iop_base;
 asc_isr_callback = asc_dvc->isr_callback;
@@ -13137,6 +13145,7 @@
 (ushort) (q_addr + (ushort) ASC_SCSIQ_B_STATUS),
  scsiq->q_status);
 (*asc_isr_callback) (asc_dvc, scsiq);
+   DvcLeaveCritical(last_int_level);
 return (1);
 }
 }
@@ -13158,7 +13167,7 @@
 ASC_QDONE_INFO  scsiq_buf;
 ASC_QDONE_INFO *scsiq;
 ASC_ISR_CALLBACKasc_isr_callback;
-int last_int_level;
+unsigned long   last_int_level;
 
 iop_base = asc_dvc->iop_base;
 asc_isr_callback = asc_dvc->isr_callback;
@@ -17570,7 +17579,7 @@
 AdvExeScsiQueue(ADV_DVC_VAR *asc_dvc,
 ADV_SCSI_REQ_Q *scsiq)
 {
-intlast_int_level;
+unsigned long  last_int_level;
 AdvPortAddriop_base;
 ADV_DCNT   req_size;
 ADV_PADDR  req_paddr;
@@ -17598,6 +17607,7 @@
  */
 if ((new_carrp = asc_d

Re: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Michael D. Crawford]

J Sloan ([EMAIL PROTECTED]) sez:

> This is a little OT for linux-kernel

Off-topic to debug a new kernel feature that will significantly add to the
competitiveness of Linux on the desktop and in engineering applications?

Remember, my original report was that DRI was reported to be working in before
the final 2.4.0 release, but stopped when the penguin peed on it, but now that
I've done what should be done to fix this, I don't have the results that others
are seeing.

While this may be due to problems with Mesa, XFree86 4.0.2, or the kernel, the
fact is that in our brave new world they operate as an integrated whole so it is
important to figure it out as a unit.  And I'm not really trying to play quake
here but QA the kernel in general - it was in noticing a discrepancy while
running the Mesa test suite that I got onto this, not because I care so much
about 3D performance.  I've yet to find a programmer's editor where 3D
performance makes much of a difference.

Comments posted here and received privately indicate that some get blazing speed
from 4.0.2 + 2.4.0, and some get, well, software speeds.  So there's a problem
to be worked out.

I've done what others have suggested, removing any GL libraries other than the
ones in /usr/X11R6/lib to make sure my applications used that one.

The build of the Mesa demos are hardwired to use the libraries from within the
source distribution directories.  If you take the gloss binary somewhere else,
delete those libraries, and make a link to the X11 GL library in /usr/lib, gloss
will run, at the amazing (and previously observed) frame rate of 7.5 FPS.

So that doesn't work.

glxinfo says dri is not available if I remove the library as I did.  So I
rebuilt Mesa and reinstalled it.  The full output of glxinfo on my machine
follows.  Note that it says "direct rendering: Yes" but the version strings
don't match.  Does that indicate the problem?

Server: 1.3 Mesa 3.4
Client: 1.2 Mesa 3.4
OpenGL: 1.2 Mesa 3.4

display: :0.0  screen:0
direct rendering: Yes
server glx vendor string: Brian Paul
server glx version string: 1.3 Mesa 3.4
server glx extensions:
GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, 
GLX_ARB_get_proc_address
client glx vendor string: Brian Paul
client glx version string: 1.2 Mesa 3.4
client glx extensions:
GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, 
GLX_ARB_get_proc_address
GLX extensions:
GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, 
GLX_ARB_get_proc_address
OpenGL vendor string: Brian Paul
OpenGL renderer string: Mesa X11
OpenGL version string: 1.2 Mesa 3.4
OpenGL extensions:
GL_ARB_multitexture, GL_ARB_texture_cube_map, GL_ARB_tranpose_matrix, 
GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_func_separate, 
GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, 
GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, 
GL_EXT_polygon_offset, GL_EXT_rescale_normal, 
GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_texture3D, 
GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_object, 
GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_HP_occlusion_test, 
GL_INGR_blend_func_separate, GL_MESA_window_pos, GL_MESA_resize_buffers, 
GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGI_color_matrix, 
GL_SGI_color_table, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp, 
GL_SGIX_pixel_texture

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
--
0x23 24 tc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x24 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x25 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x26 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x27 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x28 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x29 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None
0x2a 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  8 16 16 16 16  0 0 None

-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send 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.2 vs. 2.4 benchmarks

[Marcelo Tosatti]

On Tue, 9 Jan 2001, Chris Evans wrote:

> I did one other quick test, with disappointing results for 2.4.0. I did a
> kernel build with 32Mb.
> 
> 2.4.0 was taking about 10 mins to do the build. 2.2.x was 1min30 quicker
> :( I was hoping/expecting the 2.4.0 page aging to do better, due to
> keeping the more useful pages in RAM better. I have no explanation.

The swap device was used how much during the compilation ? 

-
To unsubscribe from this list: send 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: Subtle MM bug

[Zlatko Calusic]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> On Mon, 8 Jan 2001, Rik van Riel wrote:
> 
> > On Sun, 7 Jan 2001, Wayne Whitney wrote:
> > 
> > > Well, here is a workload that performs worse on 2.4.0 than on 2.2.19pre,
> > 
> > > The typical machine is a dual Intel box with 512MB RAM and 512MB swap.
> > 
> > How does 2.4 perform when you add an extra GB of swap ?
> > 
> > 2.4 keeps dirty pages in the swap cache, so you will need
> > more swap to run the same programs...
> > 
> > Linus: is this something we want to keep or should we give
> > the user the option to run in a mode where swap space is
> > freed when we swap in something non-shared ?
> 
> I'd prefer just documenting it and keeping it. I'd hate to have two fairly
> different modes of behaviour. It's always been the suggested "twice the
> amount of RAM", although there's historically been the "Linux doesn't
> really need that much" that we just killed with 2.4.x.
> 
> If you have 512MB or RAM, you can probably afford another 40GB or so of
> harddisk. They are disgustingly cheap these days.
> 

Yes, but a lot more data on the swap also means degraded performance,
because the disk head has to seek around in the much bigger area. Are
you sure this is all OK?
-- 
Zlatko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[patch] mm-cleanup-2 (2.4.0)

[Zlatko Calusic]

OK, take two. This patch:

o removes obsolete /proc entryes and other mm structures not used
  anymore.
o adds new /proc/sys/vm/max-async-pages
o updates documentation

As the patch doesn't change any kernel vital functionality it is
completely safe. I don't know if it satisfies Linus' patch submitting
guidelines. So sent only to the lists to be on the safe side. :)


Index: 0.2/mm/oom_kill.c
--- 0.2/mm/oom_kill.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic (linux24/j/0_oom_kill.c 
1.1 644)
+++ 0.10/mm/oom_kill.c Sun, 07 Jan 2001 20:17:13 +0100 zcalusic 
+(linux24/j/0_oom_kill.c 1.2 644)
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /* #define DEBUG */
Index: 0.2/mm/bootmem.c
--- 0.2/mm/bootmem.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic (linux24/j/3_bootmem.c 
1.1 644)
+++ 0.10/mm/bootmem.c Sun, 07 Jan 2001 20:17:13 +0100 zcalusic (linux24/j/3_bootmem.c 
+1.2 644)
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
Index: 0.2/mm/swap_state.c
--- 0.2/mm/swap_state.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic 
(linux24/j/6_swap_state 1.1 644)
+++ 0.10/mm/swap_state.c Sun, 07 Jan 2001 20:17:13 +0100 zcalusic 
+(linux24/j/6_swap_state 1.2 644)
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
Index: 0.2/mm/swapfile.c
--- 0.2/mm/swapfile.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic (linux24/j/8_swapfile.c 
1.1 644)
+++ 0.10/mm/swapfile.c Sun, 07 Jan 2001 20:17:13 +0100 zcalusic 
+(linux24/j/8_swapfile.c 1.2 644)
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include  /* for blk_size */
 #include 
 #include 
Index: 0.2/mm/vmscan.c
--- 0.2/mm/vmscan.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic (linux24/j/9_vmscan.c 1.1 
644)
+++ 0.10/mm/vmscan.c Tue, 09 Jan 2001 01:39:38 +0100 zcalusic (linux24/j/9_vmscan.c 
+1.4 644)
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
Index: 0.2/mm/page_io.c
--- 0.2/mm/page_io.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic (linux24/j/10_page_io.c 
1.1 644)
+++ 0.10/mm/page_io.c Tue, 09 Jan 2001 01:31:18 +0100 zcalusic (linux24/j/10_page_io.c 
+1.4 644)
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -43,8 +42,7 @@
struct inode *swapf = 0;
 
/* Don't allow too many pending pages in flight.. */
-   if ((rw == WRITE) && atomic_read(&nr_async_pages) >
-   pager_daemon.swap_cluster * (1 << page_cluster))
+   if ((rw == WRITE) && atomic_read(&nr_async_pages) > max_async_pages)
wait = 1;
 
if (rw == READ) {
Index: 0.2/mm/filemap.c
--- 0.2/mm/filemap.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic (linux24/j/12_filemap.c 
1.1 644)
+++ 0.10/mm/filemap.c Sun, 07 Jan 2001 20:17:13 +0100 zcalusic (linux24/j/12_filemap.c 
+1.2 644)
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
Index: 0.2/mm/page_alloc.c
--- 0.2/mm/page_alloc.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic 
(linux24/j/14_page_alloc 1.1 644)
+++ 0.10/mm/page_alloc.c Sun, 07 Jan 2001 20:17:13 +0100 zcalusic 
+(linux24/j/14_page_alloc 1.2 644)
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
Index: 0.2/mm/mmap.c
--- 0.2/mm/mmap.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic (linux24/j/16_mmap.c 1.1 
644)
+++ 0.10/mm/mmap.c Sun, 07 Jan 2001 20:17:13 +0100 zcalusic (linux24/j/16_mmap.c 1.2 
+644)
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
Index: 0.2/mm/swap.c
--- 0.2/mm/swap.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic (linux24/j/17_swap.c 1.1 
644)
+++ 0.10/mm/swap.c Tue, 09 Jan 2001 01:31:18 +0100 zcalusic (linux24/j/17_swap.c 1.5 
+644)
@@ -10,13 +10,11 @@
  * linux/Documentation/sysctl/vm.txt.
  * Started 18.12.91
  * Swap aging added 23.2.95, Stephen Tweedie.
- * Buffermem limits added 12.3.98, Rik van Riel.
  */
 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -42,6 +40,13 @@
 /* How many pages do we try to swap or page in/out together? */
 int page_cluster;
 
+/* Maximum number of swap pages in flight */
+int max_async_pages;
+
+/* We track the number of pages currently being asynchronously swapped
+   out, so that we don't try to swap TOO many pages out at once */
+atomic_t nr_async_pages = ATOMIC_INIT(0);
+
 /*
  * This variable contains the amount of page steals the system
  * is doing, averaged over a minute. We use this to determine how
@@ -53,28 +58,6 @@
  */
 int memory_pressure;
 
-/* We track the number of pages currently being asynchronously swapped
-   out, so that we don't try to swap TOO many pages out at once */
-atomic_t nr_async_pages = ATOMIC_INIT(0);
-
-buffer_mem_t buffer_mem = {
-   2,  /* minimum percent buffer */
-   10, /* borrow percent buffer */
-   60  /* maximum percent buffer */
-};
-
-buffer_mem_t page_cache = {
-   2,  /* minimum percent page cache */
- 

Re: Subtle MM bug

[Zlatko Calusic]

Rik van Riel <[EMAIL PROTECTED]> writes:

> Now if 2.4 has worse _performance_ than 2.2 due to one
> reason or another, that I'd like to hear about ;)
> 

Oh, well, it seems that I was wrong. :)


First test: hogmem 180 5 = allocate 180MB and dirty it 5 times (on a
192MB machine)

kernel | swap usage | speed
---
2.2.17 |  48 MB | 11.8 MB/s
---
2.4.0  | 206 MB | 11.1 MB/s
---

So 2.2 is only marginally faster. Also it can be seen that 2.4 uses 4
times more swap space. If Linus says it's ok... :)


Second test: kernel compile make -j32 (empirically this puts the VM
under load, but not excessively!)

2.2.17 -> make -j32  392.49s user 47.87s system 168% cpu 4:21.13 total
2.4.0  -> make -j32  389.59s user 31.29s system 182% cpu 3:50.24 total

Now, is this great news or what, 2.4.0 is definitely faster.

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

[PATCH][2.2] eepro 0.12d

[aris]

ok,
as i don't have documentation this is the right thing to be
done: restore the default path for old cards and keep the new one to these
blue cards. i hope this finally fixes all problems that my changes (by
guesses and lot of dosemu) introduced on a stable driver.
if it doesn't work for you please email me. i won't rest until i restore
the stability of the old boards and make the blue one supported.

P.S.: (again) if you have any documentation about these boards please send
to me. it will make my work easy and more decent than guesses by sniffing
io.
---
aristeu sergio rozanski filho | www.cathedrallabs.org/~aris
[EMAIL PROTECTED]| [EMAIL PROTECTED] 
---


--- linux/drivers/net/eepro.c.old   Wed Dec 27 21:44:29 2000
+++ linux/drivers/net/eepro.c   Wed Dec 27 22:17:54 2000
@@ -23,6 +23,8 @@
This is a compatibility hardware problem.
 
Versions:
+   0.12d   tottaly isolated old code to new code (blue cards).
+   (aris, 12/27/2000)
0.12c   fixed other multiple cards bug and other cleanups
(aris, 08/21/2000)
0.12b   added reset when the tx interrupt is called and TX isn't done
@@ -103,7 +105,7 @@
 */
 
 static const char *version =
-   "eepro.c: v0.12b 06/20/2000 [EMAIL PROTECTED]\n";
+   "eepro.c: v0.12d 12/27/2000 [EMAIL PROTECTED]\n";
 
 #include 
 
@@ -149,47 +151,28 @@
 #include 
 #include 
 
-
 #include 
 
-/* For linux 2.1.xx */
-#if defined (LINUX_VERSION_CODE) && LINUX_VERSION_CODE > 0x20155
-
 #include 
 #include 
 #include 
 
-#define compat_dev_kfree_skb( skb, mode ) dev_kfree_skb( (skb) )
 /* I had reports of looong delays with SLOW_DOWN defined as udelay(2) */
 #define SLOW_DOWN inb(0x80)
-/* udelay(2) */
-#define compat_init_func(X)  __initfunc(X)
-#define compat_init_data __initdata
-
-#else 
-/* for 2.x */
-
-#define compat_dev_kfree_skb( skb, mode ) dev_kfree_skb( (skb), (mode) )
-#define test_and_set_bit(a,b) set_bit((a),(b))
-#define SLOW_DOWN SLOW_DOWN_IO
-#define compat_init_func(X) X
-#define compat_init_data
-
-#endif
 
-
-/* First, a few definitions that the brave might change. */
-/* A zero-terminated list of I/O addresses to be probed. */
-static unsigned int eepro_portlist[] compat_init_data =
+/* First, a few definitions that the brave might change.
+ * A zero-terminated list of I/O addresses to be probed.
+ * note: 0x300 is default, the 595FX supports ALL IO Ports 
+ * from 0x000 to 0x3F0, some of which are reserved in PCs
+ */
+static unsigned eepro_portlist[] __initdata =
{ 0x300, 0x210, 0x240, 0x280, 0x2C0, 0x200, 0x320, 0x340, 0x360, 0};
-/* note: 0x300 is default, the 595FX supports ALL IO Ports 
-  from 0x000 to 0x3F0, some of which are reserved in PCs */
 
 /* use 0 for production, 1 for verification, >2 for debug */
 #ifndef NET_DEBUG
 #define NET_DEBUG 0
 #endif
-static unsigned int net_debug = NET_DEBUG;
+static unsigned net_debug = NET_DEBUG;
 
 /* The number of low I/O ports used by the ethercard. */
 #define EEPRO_IO_EXTENT16
@@ -204,16 +187,17 @@
 struct eepro_local {
struct enet_statistics stats;
unsigned rx_start;
-   unsigned tx_start; /* start of the transmit chain */
-   int tx_last;  /* pointer to last packet in the transmit chain */
-   unsigned tx_end;   /* end of the transmit chain (plus 1) */
-   int eepro;  /* 1 for the EtherExpress Pro/10,
-  2 for the EtherExpress Pro/10+,
-  0 for other 82595-based lan cards. */
-   int version;/* a flag to indicate if this is a TX or FX
-  version of the 82595 chip. */
+   unsigned tx_start;  /* start of the transmit chain */
+   int tx_last;/* pointer to last packet in the transmit chain */
+   unsigned tx_end;/* end of the transmit chain (plus 1) */
+   int eepro;  /* 1 for the EtherExpress Pro/10,
+* 2 for the EtherExpress Pro/10+,
+* 3 for the blue cards,
+* 0 for other 82595-based lan cards. */
+   int version;/* a flag to indicate if this is a TX or FX
+* version of the 82595 chip. */
int stepping;
-   spinlock_t lock; /* Serializing lock  */ 
+   spinlock_t lock;/* Serializing lock  */ 
unsigned rcv_ram;
unsigned rcv_start;
unsigned xmt_bar;
@@ -322,7 +306,7 @@
 static void set_multicast_list(struct device *dev);
 
 static int read_eeprom(int ioaddr, int location, struct device *dev);
-static void hardware_send_packet(struct device *dev, void *buf, short length);
+static int hardware_send_packet(struct d

[PATCH] 2.4.0-ac4 : Removal of drivers/misc/misc.o

[Frank Davis]

Hello,
 The following patch removes drivers/misc/misc.o 
from the kernel build. It appears that drivers/misc isn't used for anything, and 
should be probably be removed.
Regards,
Frank
 
--- Makefile.old  Sun Jan  7 23:59:37 2001+++ Makefile  Mon Jan  8 00:24:46 2001@@ -121,7 +121,6 
@@ NETWORKS  
=net/network.o DRIVERS      
=drivers/block/block.o \    
 drivers/char/char.o 
\-   
drivers/misc/misc.o \    
 drivers/net/net.o \    
 drivers/media/media.o LIBS 
  
=$(TOPDIR)/lib/lib.a--- drivers/Makefile.old  Sun Jan  7 23:59:48 2001+++ 
drivers/Makefile  Mon Jan  8 20:25:57 2001@@ -9,7 +9,7 
@@ mod-subdirs :=    dio mtd sbus video macintosh 
usb input telephony sgi message/i2o message/fusion ide \    scsi md ieee1394 
pnp isdn atm fc4 net/hamradio i2c acpi -subdir-y :=  block char net 
parport sound misc media cdrom+subdir-y :=  block char net 
parport sound media cdrom subdir-m :=  
$(subdir-y) 
 

[PATCH][2.4] eepro 0.12c

[aris]

hi linus,
driver: eepro
problem: the actual state of driver makes old supported board stop
 to function after some time of operation.

please consider applying this patch. the cleanup and cosmetic
changes will be in the next release of driver as you asked for.

---
aristeu sergio rozanski filho | www.cathedrallabs.org/~aris
[EMAIL PROTECTED]| [EMAIL PROTECTED] 
---



--- linux/drivers/net/eepro.c.old   Tue Dec  5 20:29:38 2000
+++ linux/drivers/net/eepro.c   Mon Jan  8 22:56:44 2001
@@ -23,6 +23,7 @@
This is a compatibility hardware problem.
 
Versions:
+   0.12c   fixing some problems with old cards (aris, 01/08/2001)
0.12b   misc fixes (aris, 06/26/2000)
0.12a   port of version 0.12a of 2.2.x kernels to 2.3.x
(aris ([EMAIL PROTECTED]), 05/19/2000)
@@ -96,7 +97,7 @@
 */
 
 static const char *version =
-   "eepro.c: v0.12b 04/26/2000 [EMAIL PROTECTED]\n";
+   "eepro.c: v0.12c 01/08/2000 [EMAIL PROTECTED]\n";
 
 #include 
 
@@ -501,8 +502,10 @@
 /* set diagnose flag */
 #define eepro_diag(ioaddr) outb(DIAGNOSE_CMD, ioaddr)
 
+#ifdef ANSWER_TX_AND_RX/* experimental way of handling interrupts */
 /* ack for rx/tx int */
 #define eepro_ack_rxtx(ioaddr) outb (RX_INT | TX_INT, ioaddr + STATUS_REG)
+#endif
 
 /* ack for rx int */
 #define eepro_ack_rx(ioaddr) outb (RX_INT, ioaddr + STATUS_REG)
@@ -1067,6 +1070,8 @@
}

eepro_sel_reset(ioaddr);
+   SLOW_DOWN;
+   SLOW_DOWN;
 
lp->tx_start = lp->tx_end = XMT_LOWER_LIMIT << 8;
lp->tx_last = 0;
@@ -1162,9 +1167,11 @@
while (((status = inb(ioaddr + STATUS_REG)) & 0x06) && (boguscount--))
{
switch (status & (RX_INT | TX_INT)) {
+#ifdef ANSWER_TX_AND_RX
case (RX_INT | TX_INT):
eepro_ack_rxtx(ioaddr);
break;
+#endif
case RX_INT:
eepro_ack_rx(ioaddr);
break;
@@ -1178,6 +1185,9 @@
 
/* Get the received packets */
eepro_rx(dev);
+#ifndef ANSWER_TX_AND_RX
+   continue;
+#endif
}
if (status & TX_INT) {
if (net_debug > 4)
@@ -1367,7 +1377,11 @@
/* Re-enable RX and TX interrupts */
eepro_en_int(ioaddr);
}
-   eepro_complete_selreset(ioaddr);
+   if (lp->eepro == LAN595FX_10ISA) {
+   eepro_complete_selreset(ioaddr);
+   }
+   else
+   eepro_en_rx(ioaddr);
 }
 
 /* The horrible routine to read a word from the serial EEPROM. */
@@ -1535,7 +1549,9 @@
printk(KERN_DEBUG "%s: exiting hardware_send_packet 
routine.\n", dev->name);
return;
}
-   netif_stop_queue(dev);
+   if (lp->eepro == LAN595FX_10ISA)
+   netif_stop_queue(dev);
+
if (net_debug > 5)
printk(KERN_DEBUG "%s: exiting hardware_send_packet routine.\n", 
dev->name);
 }
@@ -1654,9 +1670,13 @@
xmt_status = inw(ioaddr+IO_PORT);

if ((xmt_status & TX_DONE_BIT) == 0) {
-   udelay(40);
-   boguscount--;
-   continue;
+   if (lp->eepro == LAN595FX_10ISA) {
+   udelay(40);
+   boguscount--;
+   continue;
+   }
+   else
+   break;
}
 
xmt_status = inw(ioaddr+IO_PORT); 
@@ -1723,7 +1743,7 @@
 * interrupt again for tx. in other words: tx timeout what will take
 * a lot of time to happen, so we'll do a complete selreset.
 */
-   if (!boguscount)
+   if (!boguscount && lp->eepro == LAN595FX_10ISA)
eepro_complete_selreset(ioaddr);
 }
 

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 08:37:22PM -0500, Wakko Warner wrote:
> [wakko@:/home/wakko/test] rmdir "`pwd`"
> rmdir: /home/wakko/test: Invalid argument

Some other OS with a yet different retval? :)

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

FS callback routines

[Sean R. Bright]

Ok, before I begin, don't shoot me down, but I had an idea for a kernel
modification and was wondering how feasible the group thought it was.

I was writing a user space application to monitor a folder's contents.  The
folder itself contained 100 folders, and each of those contained 24 folders.
While writing the code to traverse the directory structure I realized that
instead of my software figuring out when things change, why not just have
the fs tell my application when something was updated.  For example, say we
had a function called watch_fs(), that took an inode reference and a
function pointer and maybe a bitmask of events to watch for.  When that
inode (or its children) were changed, why couldn't the fs code call the
callback function I specified?

I have no idea how expensive this would be or if its even worth it at this
point.  It also wouldn't be portable at all considering that I know of no
other OS that does this (could be wrong).

Like I said, I am not asking that this be (necessarily) implemented, I am
just curious as to what the percieved performance ramifications would be if
it were to implemented, say, by a virgin kernel developer ;)

Thanks,
Sean
[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: `rmdir .` doesn't work in 2.4

[Wakko Warner]

> Not very portable at all...
> 
> hpux = HP/UX 10.2
> 
> hpux:~$ mkdir foo
> hpux:~$ cd foo
> hpux:~/foo$ rmdir "`pwd`"
> rmdir: /home/blc/foo: Cannot remove mountable directory
> hpux:~/foo$ rmdir .
> rmdir: cannot remove .. or .
> hpux:~/foo$ rmdir /home/blc/foo
> rmdir: /home/blc/foo: Cannot remove mountable directory
> hpux:~/foo$ rmdir ./
> rmdir: ./: Cannot remove mountable directory
> hpux:~/foo$
> 
> Maybe HP/UX is messed up as well.

Nor solaris
[wakko@:/home/wakko/test] rmdir "`pwd`"
rmdir: /home/wakko/test: Invalid argument
[wakko@:/home/wakko/test] uname -a
SunOS  5.8 Generic_108528-03 sun4d sparc SUNW,SPARCcenter-2000
[wakko@:/home/wakko/test] 


-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send 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] cramfs is ro only, so honour this in inode->mode

[Rusty Russell]

In message <[EMAIL PROTECTED]> you
 write:
> I've been thinking of doing a cramfs2, and the only thing I'd change is
> (a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
> meta-data and the real data so that I could easily compress the metadata
> too. cramfs doesn't have any traditional meta-data (no bitmap blocks or
> anything like that), but it wouldn't be that hard to put the directory
> structure in the page cache and just compress the directories the same way
> the real data is compressed.

And you'd still be worse than compressed loopback w/32k blocks, and
more complex.  Now most of the loopback bugs seem fixed in 2.4, I'll
port the cloop stuff, and we can compare.

Time to stop this cramfs madness!
Rusty.
--
http://linux.conf.au The Linux conference Australia needed.
-
To unsubscribe from this list: send 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] More compile warning fixes for 2.4.0

[Rich Baum]

On 8 Jan 2001, at 20:50, Erik Mouw wrote:

> On Sat, Jan 06, 2001 at 09:40:51PM -0500, Rich Baum wrote:
> > Here's a patch that fixes more of the compile warnings with gcc 
> > 2.97.
> 
> > -case FORE200E_STATE_BLANK:
> > +case FORE200E_STATE_BLANK:;
> 
> Is this really a kernel bug? This is common idiom in C, so gcc
> shouldn't warn about it. If it does, it is a bug in gcc IMHO.
> 
> 
> Erik
> (compiling a GCC CVS snapshot to see if it really breaks)
> 
> -- 
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
> of Electrical Engineering, Faculty of Information Technology and Systems,
> Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
> Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
> WWW: http://www-ict.its.tudelft.nl/~erik/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

It still compiles and works just as well as it does without the patch. 
 Without the patch it says: 
warning: deprecated use of label at end of compound statement

My patches are basically telling the compiler to be quiet.  If you 
use egcs it won't give these warnings even if the code hasn't been 
patched.
-
To unsubscribe from this list: send 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.2.19pre6aa1 degraded performance for me...

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 10:46:29PM +0100, Sasi Peter wrote:
> What I had w/2.2.18pre19 (+raid+ide):
> ~80MB more in cache and ~80MB swapped out (eg. currently unused notes
> server and squid) There is enough of swap over 3 disks (like the
> raid), so I did not bother disabling squid and notes, since - I thought -
> they would only take up some swap unused.

There are many variables. However I guess the slowdown is because your idle
apps didn't got swapped out in favour of cache as you noticed. An aggressive
aging algorithm would probably fix that but it then would hurt other cases
(after you don't need a frequenty accessed part of filesystem cache anymore it
would take ages before it gets collected potentially causing an unnecessary
swapout storms because the kernel doesn't know you don't need such cache
anymore).  Furthmore if notes and squid are rarely running but they provides
critical services if they would go totally into swap in favour of fs cache you
would get very bad latencies the first time somebody connects to the server. So
the fix I suggest you is to buy more ram or to shutdown squid and notes. Than
you may as well see a performance improvement compared to 2.2.18pre19
(+raid+ide).  Otherwise you can push the machine low on memory a bit until they
both goes totally into swap (check with `ps v`). Hope this helps.

Andrea
-
To unsubscribe from this list: send 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: Related VIA PCI crazyness?

[Evan Thompson]

LINUS:

>  - enable DEBUG in arch/i386/kernel/pci-i386.h
>  - do a "/sbin/lspci -xxvvv" on the interrupt routing chip (it's the
>"ISA bridge" chip - the VIA numbers are 82c586, 82c596, the PCI
>numbers for them are 1106:0586 and 1106:0596, I think)
>  - do a cat /proc/pci

Okay, I've attached the following files:

dmesg -> dmesg output of Linux 2.4.0-ac4 (w/extra DEBUG info)
lspci -> output of /sbin/lspci -xxvvv (I'm just attaching the whole
 output, in case I might have selected the wrong device.
 If you still need something, just ask)

procpci -> output of cat /proc/pci

Does this help?

(Like my signature?  It updates itself with the current Linux kernel
version I have installed.  It's quite clever, just a 44 line Perl
script that tries to squeese a uname -a into that...)
-- 
+--+---+
| Evan Thompson|POWERED BY:|
| [EMAIL PROTECTED]   | Linux cd168990-a 2.4.0-ac4 #1 Sun |
| Freelance Computer Nerd  |  Jan 7 21:25:16 CST 2001 i686 |
| http://evaner.penguinpowered.com |   unknown (w/extra DEBUG info)|
+--+---+


Linux version 2.4.0-ac4 (root@cd168990-a) (gcc version 2.95.3 20001229 (prerelease)) 
#1 Sun Jan 7 21:25:16 CST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 09f0 @ 0010 (usable)
 BIOS-e820: 0001 @  (reserved)
On node 0 totalpages: 40960
zone(0): 4096 pages.
zone(1): 36864 pages.
zone(2): 0 pages.
Kernel command line: mem=160M ide1=0x170,0x376,15 hdd=ide-scsi root=/dev/hdb5
ide_setup: ide1=0x170,0x376,15

ide_setup: hdd=ide-scsi
Initializing CPU#0
Detected 400.939 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 799.53 BogoMIPS
Memory: 158904k/163840k available (1002k kernel code, 4548k reserved, 391k data, 200k 
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0183f9ff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183f9ff   
CPU: After generic, caps: 0183f9ff   
CPU: Common caps: 0183f9ff   
CPU: Intel Celeron (Covington) stepping 01
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: BIOS32 Service Directory structure at 0xc00fdb40
PCI: BIOS32 Service Directory entry at 0xfdb50
PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=01
PCI: PCI BIOS revision 2.10 entry at 0xfdb71, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: IDE base address fixup for 00:07.1
PCI: Scanning for ghost devices on bus 0
PCI: Scanning for ghost devices on bus 1
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00f85f0
00:07 slot=00 0:fe/4000 1:ff/8000 2:00/ 3:04/deb8
00:08 slot=01 0:01/deb8 1:02/deb8 2:03/deb8 3:04/deb8
00:09 slot=02 0:02/deb8 1:03/deb8 2:04/deb8 3:01/deb8
00:0a slot=03 0:03/deb8 1:04/deb8 2:01/deb8 3:02/deb8
c3:00 slot=72 0:60/0e1e 1:1f/e852 2:93/8b00 3:fa/1f5a
0a:18 slot=05 0:74/3c27 1:f0/0c73 2:e8/feb9 3:0a/74c0
PCI: Scanning for ghost devices on bus 10
PCI: Discovered primary peer bus 0a [IRQ]
PCI: Scanning for ghost devices on bus 195
PCI: Discovered primary peer bus c3 [IRQ]
PCI: Using IRQ router VIA [1106/0586] at 00:07.0
PCI: IRQ fixup
PCI: Allocating resources
PCI: Resource e800-ebff (f=1208, d=0, p=0)
PCI: Resource 01f0-01f7 (f=101, d=0, p=0)
PCI: Resource 03f6-03f6 (f=105, d=0, p=0)
PCI: Resource 0170-0177 (f=101, d=0, p=0)
PCI: Resource 0376-0376 (f=105, d=0, p=0)
PCI: Resource ffa0-ffaf (f=101, d=0, p=0)
PCI: Resource df00-df1f (f=101, d=0, p=0)
PCI: Resource de80-de9f (f=101, d=0, p=0)
PCI: Resource e700-e77f (f=1208, d=0, p=0)
PCI: Resource efef-efef (f=200, d=0, p=0)
PCI: Resource cc80-ccff (f=101, d=0, p=0)
PCI: Sorting device list...
Activating ISA DMA hang workarounds.
isapnp: Scanning for Pnp cards...
isapnp: Calling quirk for 01:03
isapnp: CMI8330 quirk - fixing interrupts and dma
isapnp: Card 'CMI8330/C3D Audio Adapter'
isapnp: 1 Plug & Play card detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
DMI 2.0 present.
0 structures occupying 0 bytes.
DMI table at 0x000F.
Starting kswap

Re: [uml-devel] Re: [reiserfs-list] BUG at inode.c:371

[Daniel Phillips]

Jeff Dike wrote:
> 
> You've got two problems here, and one of them is mine:
> 
> > In uml I continue the debian installation off of cdrom and as I say ok
> > to the final screen I get a "Kernel panic: Kernel mode fault at addr
> > 0xbefffe90, ip 0x1009f315" from user-mode linux which is running as
> > me, not as root.
> 
> Can you get me a stack trace from the panic?  See http://user-mode-linux.source
> forge.net/trouble.html if you need information on doing that.

I don't know about your panic but the BUG itself is related to dirty
page handling on inodes and is already cleaned up in 2.4.0.

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

adding a system call

[Mihai Moise]

Hello,

What is the procedure for adding a new system call to the Linux kernel?

Mihai
-
To unsubscribe from this list: send 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: Subtle MM bug

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Andrea Arcangeli  <[EMAIL PROTECTED]> wrote:
>On Mon, Jan 08, 2001 at 03:22:44PM -0800, Wayne Whitney wrote:
>> I guess I conclude that either (1) MAGMA does not use libc's malloc
>> (checking on this, I doubt it) or (2) glibc-2.1.92 knows of these
>> variables but has not yet implemented the tuning (I'll try glibc-2.2) or
>> (3) this is not the problem.
>
>You should monitor the program with strace while it fails (last few syscalls).
>You can breakpoint at exit() and run `cat /proc/pid/maps` to show us the vma
>layout of the task. Then we'll see why it's failing.  With CONFIG_1G in 2.2.x
>or 2.4.x (confinguration option doesn't matter) you should at least reach
>something like 1.5G.

It might be doing its own memory management with brk() directly - some
older UNIX programs will do that (for various reasons - it can be faster
than malloc() etc if you know your access patterns, for example).

If you do that, and you have shared libraries, you'll get a failure
around the point Wayne sees it. 

But your suggestion to check with strace is a good one.

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/

Re: [uml-devel] Re: [reiserfs-list] BUG at inode.c:371

[Jeff Dike]

You've got two problems here, and one of them is mine:

> In uml I continue the debian installation off of cdrom and as I say ok
> to the final screen I get a "Kernel panic: Kernel mode fault at addr
> 0xbefffe90, ip 0x1009f315" from user-mode linux which is running as
> me, not as root.

Can you get me a stack trace from the panic?  See http://user-mode-linux.source
forge.net/trouble.html if you need information on doing that.

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: [OT]: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[J Sloan]

Ragnar Hojland Espinosa wrote:

> On Mon, Jan 08, 2001 at 02:56:05PM -0800, J Sloan wrote:
>
> > In my case, that meant nuking mesa from my system and
> > letting Linux use what was left, which got me back the good
> > accelerated performance - you may choose a less drastic
> > option. I don't see any breakage from the absence of mesa.
>
> Well, the real problem is that (at least Voodoo3) DRI didn't work _before_
> with the "latest" test and pre kernels, and X < 4.0.2 (unless there was some
> combination I didn't manage to find) even if it was using the correct
> library.

That's odd, perhaps we should compare notes -

I have been getting good accelerated 3D from my voodoo3
since around 2.3.36, except for one brief period around
2.3.99-something where some critical kernel code changed.

I have been using the kernel drm all along.

BTW I am using the X server from 3dfx.com -

jjs

-
To unsubscribe from this list: send 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: Extraneous whitespace removal?

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:
> Pluses:
>  - clean up messy whitespace
>  - cut precious picoseconds off compile time
>  - cut kernel tree by 200k (+/- alot)

I've done this before, but never posted it, lest they think I'm
insane.  I vote this for 2.5.1.

You, sir, have balls,
Rusty.
--
http://linux.conf.au The Linux conference Australia needed.
--- working-2.4.0/MAINTAINERS.~1~   Mon Jan  1 04:31:15 2001
+++ working-2.4.0/MAINTAINERS   Tue Jan  9 11:23:48 2001
@@ -1434,6 +1434,11 @@
 L: [EMAIL PROTECTED]
 S: Maintained
 
+WHITESPACE
+P: Jeremy M. Dolan
+M: [EMAIL PROTECTED]
+S: Maintained
+
 X.25 NETWORK LAYER
 P: Henner Eisen
 M: [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: setfsuid on ext2 weirdness (2.4)

[Kai Henningsen]

[EMAIL PROTECTED] (Linus Torvalds)  wrote on 08.01.01 in 
<93d7fr$429$[EMAIL PROTECTED]>:

> And hey, if you think the above is confusing, try making your /dev/null
> a regular (writable) file by mistake.  Now THAT will be confusing as
> hell: things will actually work surprisingly well, but some thing
> _really_ don't work the way they are intended to.  And chasing it down
> is an exercise in futility.  Yes, I've done that at least twice as root
> by mistake.

So have I. It's so damned easy. Just remove the original; pretty soon  
*something* will create a plain file there.

Now you have:

* Actual input reading from /dev/null (and it changes!).
* Unusual permissions on /dev/null

Fun fun fun. Many unusual failure modes.

MfG Kai
-
To unsubscribe from this list: send 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.2 vs. 2.4 benchmarks

[Chris Evans]

Hi,

I ran some 2.2 vs. 2.4 benchmarks, particularly in the area of file i/o,
using bonnie++.

The machine is a SMP 128Mb PII-350 with a udma2 drive capable of some
20Mb/sec+. Kernels involved are 2.4.0, and the default RH7.0 kernel
(2.2.16 plus more patches than you can shake a stick at).

Not going too much into the gory details, here are the differences exposed
between 2,2 and 2.4:

1) Amazing 2.4 increase in streaming write performance; 13Mb/sec ->
20Mb/sec. I suspect this is the result of the "last minute" 2.4.0 dirty
buffer/sync waiting handling changes.

2) Slight 2.4 increase in streaming read performance; 16Mb/sec ->
17Mb/sec. This leaves 2.4.0 writing faster than reading, I find that
surprising.

3) Some 10% drop in rewrite performance from 2.2 -> 2.4 (possibly because
page aging, like LRU, isn't too hot for the 2nd+ linear scan over data)

4) File creation 30% faster in 2.4; random deletes 30% faster; sequential
deletes 10% slower.


I did one other quick test, with disappointing results for 2.4.0. I did a
kernel build with 32Mb.

2.4.0 was taking about 10 mins to do the build. 2.2.x was 1min30 quicker
:( I was hoping/expecting the 2.4.0 page aging to do better, due to
keeping the more useful pages in RAM better. I have no explanation.

Cheers
Chris

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

[PATCH] tidy 53c7,8xx.c was Re: [PATCH] de620.c: nitpicking

[Arnaldo Carvalho de Melo]

ouch, sorry for the misleading subject, cut and paste sometimes doesn't work ;(

Em Mon, Jan 08, 2001 at 08:25:33PM -0200, Arnaldo Carvalho de Melo escreveu:
> Hi,
> 
>   Please consider applying, no need to restore_flags here, as it is
> restored in the beginning of this if block.
> 
> - Arnaldo
> 
> 
> --- linux-2.4.0-ac3/drivers/scsi/53c7,8xx.c   Fri Oct 13 18:40:51 2000
> +++ linux-2.4.0-ac3.acme/drivers/scsi/53c7,8xx.c  Mon Jan  8 20:24:35 2001
> @@ -1899,7 +1899,6 @@
>   hostdata->script, start);
>   printk ("scsi%d : DSPS = 0x%x\n", host->host_no,
>   NCR53c7x0_read32(DSPS_REG));
> - restore_flags(flags);
>   return -1;
>   }
>   hostdata->test_running = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] de620.c: nitpicking

[Arnaldo Carvalho de Melo]

Hi,

Please consider applying, no need to restore_flags here, as it is
restored in the beginning of this if block.

- Arnaldo


--- linux-2.4.0-ac3/drivers/scsi/53c7,8xx.c Fri Oct 13 18:40:51 2000
+++ linux-2.4.0-ac3.acme/drivers/scsi/53c7,8xx.cMon Jan  8 20:24:35 2001
@@ -1899,7 +1899,6 @@
hostdata->script, start);
printk ("scsi%d : DSPS = 0x%x\n", host->host_no,
NCR53c7x0_read32(DSPS_REG));
-   restore_flags(flags);
return -1;
}
hostdata->test_running = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 03:27:21PM -0800, Linus Torvalds wrote:
> However, it is against all UNIX standards, and Linux-2.4 will explicitly

I may be missing something but apparently SuSv2 allows it, you can check here:

http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html

Infact SuSv2 doesn't even allow rmdir to return -EINVAL.

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

[PATCH] de620.c: nitpicking

[Arnaldo Carvalho de Melo]

Bjorn/Alan,

Yes, I'm a nitpicker ;)

--- linux-2.4.0-ac3/drivers/net/de620.c Tue Dec 19 11:24:52 2000
+++ linux-2.4.0-ac3.acme/drivers/net/de620.cMon Jan  8 20:06:28 2001
@@ -563,7 +563,6 @@
printk(KERN_WARNING "%s: No tx-buffer available!\n", dev->name);
restore_flags(flags);
return 1;
-   break;
}
de620_write_block(dev, buffer, len);
 
-
To unsubscribe from this list: send 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: HomePNA 2.0 flamage

[Dan Hollis]

On Mon, 8 Jan 2001, Alan Cox wrote:
> I suspect homepna is dead to be honest.

Apparently its competing rather well with DSL for MDU deployments (eg
hotels, apartment complexes)

-Dan

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

Re: HomePNA 2.0 flamage

[Timur Tabi]

** Reply to message from Alan Cox <[EMAIL PROTECTED]> on Mon, 8 Jan 2001
23:54:16 + (GMT)


> I suspect homepna is dead to be honest.

I'm not so sure.  My father-in-law just purchased a Gateway system with a
HomePNA device.  It was the only networking device the computer came with.

It certainly would be a great addition to Linux (and other OS's).


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please direct the reply to the mailing list 
only.  Don't send another copy to me.
-
To unsubscribe from this list: send 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: [OT]: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Ragnar Hojland Espinosa]

On Mon, Jan 08, 2001 at 02:56:05PM -0800, J Sloan wrote:

> In my case, that meant nuking mesa from my system and
> letting Linux use what was left, which got me back the good
> accelerated performance - you may choose a less drastic
> option. I don't see any breakage from the absence of mesa.

Well, the real problem is that (at least Voodoo3) DRI didn't work _before_
with the "latest" test and pre kernels, and X < 4.0.2 (unless there was some
combination I didn't manage to find) even if it was using the correct
library.

[ If anyone would like some help, feel free to email me directly ]
-- 
/|  Ragnar Højland Freedom - Linux - OpenGL  Fingerprint  94C4B
\ o.O|   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for  104B78C56 B72F0822
   U chaos and madness await thee at its end."   hkp://keys.pgp.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: HomePNA 2.0 flamage

[Alan Cox]

> This doesn't seem to be the case with HomePNA 2.0 which makes me suspect
> that Broadcom has a patent on some critical piece of technology.  I

Quite possible. Search for 'broadcom intel patent lawsuit' on google - there
are other outstanding things.

> can't think of any other reason how they seem to have a defacto monopoly
> on HomePNA 2.0 products.  This is bad because HomePNA 1.0 products
> are becoming increasingly difficult to find.

I suspect homepna is dead to be honest.

Alan

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

[PATCH] bmac.c: restore_flags on failure

[Arnaldo Carvalho de Melo]

Alan,

I haven't found Randy Gobbel's e-mail, please apply.

- Arnaldo

--- linux-2.4.0-ac3/drivers/net/bmac.c  Tue Dec 19 11:24:51 2000
+++ linux-2.4.0-ac3.acme/drivers/net/bmac.c Mon Jan  8 19:55:30 2001
@@ -6,6 +6,8 @@
  *
  * May 1999, Al Viro: proper release of /proc/net/bmac entry, switched to
  * dynamic procfs inode.
+ * Jan 2001, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
+ * restore_flags on failure in bmac_reset_and_enable
  */
 #include 
 #include 
@@ -1227,9 +1229,9 @@
bmac_reset_chip(dev);
if (enable) {
if (!bmac_init_tx_ring(bp) || !bmac_init_rx_ring(bp))
-   return 0;
+   goto out;
if (!bmac_init_chip(dev))
-   return 0;
+   goto out;
bmac_start_chip(dev);
bmwrite(dev, INTDISABLE, EnableNormal);
bp->reset_and_enabled = 1;
@@ -1247,6 +1249,8 @@
}
restore_flags(flags);
return 1;
+out:   restore_flags(flags);
+   return 0;
 }
 
 static int __init bmac_probe(void)
-
To unsubscribe from this list: send 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: The advantage of modules?

[Alan Cox]

> Although I haven't been involved for over 8 years, it us unlikely that
> the word "SCSI" has been given up as some generic aspirin. SCSI still
> means the stuff specified in the 519 Page document copyrighted by
> ANSI, called "SMALL COMPUTER SYSTEM INTERFACE - 2", Dated May 20, 1991,
> and the first draft released in June of 1986.

SCSI nowdays is a message protocol. Its what powers fibrechannel at the high
end and ATAPI (IDE) and USB at the low end.

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

HomePNA 2.0 flamage

[Joseph Wang]

I've been trying to search for a 10 Mpbs phone ethernet card that works
with linux.  Apparently all of the products that implement HomePNA 2.0
use the Broadcom chipset and Broadcom has been extremely non-responsive
at providing chipset specifications.

The situation really irks me because the whole point of having a standard
is to allow for competition between different manufacturers.  In the
case of HomePNA 1.0, there were some chipsets that provided enough
information to write a driver and it was possible to use market pressure
to force chipset makers to make their products usable with linux.
There were about four or five chip manufacturers with homePNA 1.0 chips
and some of them provided some excellent documentation and tech specs.

This doesn't seem to be the case with HomePNA 2.0 which makes me suspect
that Broadcom has a patent on some critical piece of technology.  I
can't think of any other reason how they seem to have a defacto monopoly
on HomePNA 2.0 products.  This is bad because HomePNA 1.0 products
are becoming increasingly difficult to find.

My question is

1) do I have any options other than to give up on HomePNA 2.0 and start
digging holes in walls.  At this point, I would welecome any product
that doesn't use a broadcom chip set.

2) how did Broadcom manage to get a de-facto monopoly on high speed
phone line ethernet cards?  If it's possible for Broadcom to do this
with phone line ethernet, I shudder to think about the possibility of
some other linux-unfriendly company owning a piece of critical technology.

3) is there anything that we as a community can do other than to keep
shouting at broadcom?A

-- 
---
Joseph Wang Ph.D.  Globewide Network Academy
[EMAIL PROTECTED]FREE Distance Education catalog database
http://www.gnacademy.org   Over 20,000 courses and degrees

-
To unsubscribe from this list: send 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: Subtle MM bug

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 03:22:44PM -0800, Wayne Whitney wrote:
> I guess I conclude that either (1) MAGMA does not use libc's malloc
> (checking on this, I doubt it) or (2) glibc-2.1.92 knows of these
> variables but has not yet implemented the tuning (I'll try glibc-2.2) or
> (3) this is not the problem.

You should monitor the program with strace while it fails (last few syscalls).
You can breakpoint at exit() and run `cat /proc/pid/maps` to show us the vma
layout of the task. Then we'll see why it's failing.  With CONFIG_1G in 2.2.x
or 2.4.x (confinguration option doesn't matter) you should at least reach
something like 1.5G.

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

Oops in stock 2.2.18

[Mike Frisch]

Can anybody shed some light on this?

Thanks,

--- cut here ---

Unable to handle kernel paging request at virtual address e6d94ba1
current->tss.cr3 = 07211000, %cr3 = 07211000
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: c72e1b0a   ebx: c72e1b80   ecx: c15d   edx: 
esi: c731e000   edi: 0024   ebp:    esp: c731ff2c
ds: 0018   es: 0018   ss: 0018
Process master (pid: 465, process nr: 32, stackpage=c731f000)
Stack: c70c6d80 c72060a0 c15d 0001 c012d31f c70c6d80 c15d 
   0002 c163af30  0010 0145 c731e000 1770 c15d
   c15d c012d785 003b c731ffa8 c731ffa4 c731e000 bb54 bb4c
Call Trace: [] [] []
Code: 8b 43 6c 2b 43 50 3d ff 07 00 00 7e 06 81 ca 04 03 00 00 89

>>EIP; c016faa5<=
Trace; c012d31f 
Trace; c012d785 
Trace; c0107b68 
Code;  c016faa5 
 <_EIP>:
Code;  c016faa5<=
   0:   8b 43 6c  movl   0x6c(%ebx),%eax   <=
Code;  c016faa8 
   3:   2b 43 50  subl   0x50(%ebx),%eax
Code;  c016faab 
   6:   3d ff 07 00 00cmpl   $0x7ff,%eax
Code;  c016fab0 
   b:   7e 06 jle13 <_EIP+0x13> c016fab8 
Code;  c016fab2 
   d:   81 ca 04 03 00orl$0x304,%edx
Code;  c016fab7 
  12:   00
Code;  c016fab8 
  13:   89 00 movl   %eax,(%eax)


6 warnings issued.  Results may not be reliable.

-
To unsubscribe from this list: send 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: `rmdir .` doesn't work in 2.4

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Andrea Arcangeli  <[EMAIL PROTECTED]> wrote:
>On Mon, Jan 08, 2001 at 04:08:58PM -0500, Alexander Viro wrote:
>>  Andrea, fix your code. Linux-only stuff is OK when there is no
>
>BTW, "rmdir `pwd`" is not portable either.

Indeed. Avoid it if you can.

But at least "rmdir `pwd`" is not _required_ to fail, like rmdir("."/"..").

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/

Re: `rmdir .` doesn't work in 2.4

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Andrea Arcangeli  <[EMAIL PROTECTED]> wrote:
>On Mon, Jan 08, 2001 at 01:04:24PM -0500, Alexander Viro wrote:
>> Racy. Nonportable. Has portable and simple equivalent. Again, don't
>> bother with chdir at all - if you know the name of directory even
>> ../name will work. It's not about the current directory. It's about
>> the invalid last component of the name.
>
>The last component of the name isn't invalid, it's a plain valid directory. If
>according to you `rmdir ../name` and rmdir `pwd` makes sense  then according to
>me `rmdir .` makes perfect sense too.

It makes perfect sense, and Linux used to accept it during the 2.3.x
timeframe.

However, it is against all UNIX standards, and Linux-2.4 will explicitly
not allow it (there's also some parent locking issues there).

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/

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 11:50:44PM +0100, [EMAIL PROTECTED] wrote:
> From: Andrea Arcangeli <[EMAIL PROTECTED]>
> 
> > But in fact it fails with EINVAL, and
> > 
> > [EINVAL]: The path argument contains a last component that is dot.
> 
> I can't confirm. The specs I'm checking are here:
> 
> http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html
> 
> That is the SUSv2 text, one of the ingredients for the new
> POSIX standard. I quoted the current Austin draft, the current
> draft for the next version of the POSIX standard.
> 
> Quoting a text fragment:
> 
> The rmdir( ) function shall remove a directory whose name is given by
> path. The directory is removed only if it is an empty directory.
> If the directory is the root directory or the current working
> directory of any process, it is unspecified whether the function
> succeeds, or whether it shall fail and set errno to [EBUSY].
> If path names a symbolic link, then rmdir( ) shall fail and
> set errno to [ENOTDIR]. If the path argument refers to a path
> whose final component is either dot or dot-dot, rmdir( ) shall
> fail. ...

I trust your specs said so, however I'm not sure which are the specs
we should follow for Linux.

At least for LFS 2.2.x fixage I always followed the SuSv2 specs and they
doesn't even say that rmdir can return -EINVAL. So returning -EINVAL is wrong
in first place according to SuSv2.

> from the directory "foo", but rmdir("foo/.") does not finish
> by removing the name "." from the directory "foo".

Sure. Also `rmdir .` doesn't mean remove "." from current directory but it
means "remove the directory pointed out by path `.'". The kernel/We definitely
knows which is such directory. That is in sync with the specs: "The rmdir()
function removes a directory whose name is given by path". You agree that the
path "." identifys one directory.

Andrea
-
To unsubscribe from this list: send 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: Shared memory not enabled in 2.4.0?

[David Schwartz]

> For some reason shared memory is not being enabled on my system
> running kernel
> v2.4.0 (on RedHat v6.2,  with all updates applied).

You are confusing System V shared memory (IPC) with VM shared memory. The
'0' for shared in /proc/meminfo means the system can't easily tell you how
much memory the VM is sharing. But this has nothing whatsoever to do with
IPC shared memory, which is what the /dev/shm thing is about.

DS

-
To unsubscribe from this list: send 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: Journaling: Surviving or allowing unclean shutdown?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Also thing about cases where powerplant fails, or when electricity in
> the house fails. I've seen places where electricity failed 5 times a
> day, because someone put 10A fuse and we were using just about 2kW...

Especially evil is a power failure, and then a second failure while fsck is
running...

So i hope Journaling FSs will have the power of normal FSs soon, so we can
have them as a default for consumers. Otherwise:

/dev/scsi/host0/bus0/target6/lun0/part1 on / type ext2 (ro)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
/dev/sda5 on /usr type ext2 (ro)
/dev/sda6 on /var type ext2 (r,noexec)
/dev/sda7 on /home type ext2 (rw,nosuid)
/dev/scd0 on /cdrom type iso9660 (ro)

some read only filesystems :)

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

Re: Subtle MM bug

[Wayne Whitney]

On Mon, 8 Jan 2001, Wayne Whitney wrote:

> On Mon, 8 Jan 2001, Szabolcs Szakacsits wrote:
>
> > AFAIK newer glibc = CVS glibc but the malloc() tune parameters work
> > via environment variables for the current stable ones as well,
>
> I'll arrange a binary linked against glibc2.2, and then your suggestion
> will hopefully do the trick.  Thanks for your kind help!

OK, I now have a binary dynamically linked against /lib/libc.so.6,
(according to ldd), and that points to glibc-2.1.92.  And I tried setting
the environment variables you suggested, I checked that they are set and
checked that they appear in /lib/libc.so.6.  But the behaviour is
unchanged:  MAGMA still hits this barrier at 830M (not 870M, that was a
typo).

I guess I conclude that either (1) MAGMA does not use libc's malloc
(checking on this, I doubt it) or (2) glibc-2.1.92 knows of these
variables but has not yet implemented the tuning (I'll try glibc-2.2) or
(3) this is not the problem.

I'll look at Andrea's hack as well.  Thanks for everybody's help!

Cheers, Wayne






-
To unsubscribe from this list: send 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-list] BUG at inode.c:371

[Geoff Hoff]

> > I have gotten this semi-reproducable bug three times already under the same
> > circumstances.  The bug happens at approximately the same time as I kill
> > xterms after user-mode linux has crashed and I am cleaning up what it has
> > left behind.  User mode linux is using a 1 gig file on a 6 gig reiser
> > filesystem.  After each BUG I have reformated the filesystem and recreated
> > the image I am operating on, so it doesn't seem to be some long term bug
> > in the on disk information that I am just running into.  For the specifics,
> > the first and second time I was running linux-2.4.0-prerelease with the
> > reiserfs-3.6.24 patch.  
> 
> Hmmm, could you try to reproduce under ext2?  I'll see what I can find on the
> reiserfs side.

The good? news is that it isn't a reiserfs specific problem.  The bad news
is it also happens with ext2.  This is what I was doing:  I have a 1GB image
file with the 74 megs that the first stage debian installer puts on the disk.
I make a few changes to it and then boot user mode linux on this image.  In
uml I continue the debian installation off of cdrom and as I say ok to the
final screen I get a "Kernel panic: Kernel mode fault at addr 0xbefffe90, ip
0x1009f315" from user-mode linux which is running as me, not as root.  I then
killall linux, which is the uml executable.  Afterward I do a killall xterm,
as uml spawns an xterm for each virtual console.  Immediately I get the BUG
message.  This is with uml-2.4.0-prerelease running on real 2.4.0-prerelease
with reiserfs-3.6.25 on either a reiser or ext2 filesystem.  I am not subscribed
to user-mode-linux-devel or linux-kernel, so cc me if I can provide any more
information.  Everything has been compiled with gcc-2.91.66.
The decoded bug is:

kernel BUG at inode.c:371!
invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 001b   ebx: c3621240   ecx:    edx: 
esi: 00076e57   edi: c3621240   ebp: c3621240   esp: c693bee0
ds: 0018   es: 0018   ss: 0018
Process xterm (pid: 3531, stackpage=c693b000)
Stack: c01cb3a4 c01cb424 0173 c12c1800 c014b583 c3621240 c3621240 c01eff40 
   c3621240 c4821b60 c7ad7400 c38c2b40 0116 001e  c1ac2c80 
   c014bce0 c014bd06 c3621240 c3621240 c01414de c3621240 c4821b60 c3621240 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
Code: 0f 0b 83 c4 0c 8b 83 f0 00 00 00 a8 10 75 26 68 75 01 00 00 

>>EIP; c0140c1b<=
Trace; c01cb3a4 
Trace; c01cb424 
Trace; c014b583 
Trace; c014bce0 
Trace; c014bd06 
Trace; c01414de 
Trace; c013f74e 
Trace; c012ed70 
Trace; c012defc 
Trace; c0115dda 
Trace; c01163cf 
Trace; c0116536 
Trace; c0108d5f 
Code;  c0140c1b 
 <_EIP>:
Code;  c0140c1b<=
   0:   0f 0b ud2a  <=
Code;  c0140c1d 
   2:   83 c4 0c  add$0xc,%esp
Code;  c0140c20 
   5:   8b 83 f0 00 00 00 mov0xf0(%ebx),%eax
Code;  c0140c26 
   b:   a8 10 test   $0x10,%al
Code;  c0140c28 
   d:   75 26 jne35 <_EIP+0x35> c0140c50 
Code;  c0140c2a 
   f:   68 75 01 00 00push   $0x175
-
To unsubscribe from this list: send 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: ipchains vs netfilter performance

[Rusty Russell]

In message <3A585D9F.21907.1452FA04@localhost> you write:
> I've noticed that my Linux boxes take quite a hit in terms of
> packets per second rate when I define ipchains rules with
> 2.2.X kernels. Does the netfilter replacement found in 2.4
> kernels improve this performance?

Not really.  What are your rules?

Rusty.
--
http://linux.conf.au The Linux conference Australia needed.
-
To unsubscribe from this list: send 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: The advantage of modules?

[Richard B. Johnson]

On Mon, 8 Jan 2001, Dan Hollis wrote:

> On Mon, 8 Jan 2001, Russell King wrote:
> > Seriously though, you can't depreciate a term for referring to a type of
> > bus without providing some other term to describe said bus.
> 
> You need to distinguish between SCSI-the-protocol and
> SCSI-the-physical-layer. The term "SCSI" alone is simply too ambiguous to
> be really useful anymore. I think you can use term "SCSI-1" or "SCSI-2"
> when specicfally meaning SCSI protocol over classic 50 wire layer.
> 
> Saying "SCSI does not support hotplug" is very misleading.
> 
> Right now, the term "SCSI" is more akin to "IP".
> 
> -Dan

Err The American National Standard for information Systems, under
the American National Standards Institute, ANSI, approved a "Small
Computer System Interface" (SCSI) standard on June 23, 1986.

There have been many revisions, one of the last, called SCSI-2, was
approved on May 20, 1991. I used to sit on the committee. I have some
of the original drafts.

Although I haven't been involved for over 8 years, it us unlikely that
the word "SCSI" has been given up as some generic aspirin. SCSI still
means the stuff specified in the 519 Page document copyrighted by
ANSI, called "SMALL COMPUTER SYSTEM INTERFACE - 2", Dated May 20, 1991,
and the first draft released in June of 1986.

As such, you are not supposed to use the word SCSI to mean "control packet
interface" or whatever. It is supposed to refer to the hardware and
communications specifications (software), defined by the standard.
Although nobody is likely to haul is into court, we should not be using
SCSI to mean anything else.

And, SCSI does not "specify" hot-plug. It's just not covered in the
standard. However, you can certainly provide capabilities not covered
by a particular standard. It is some implementation details on how
SCSI (and other) devices are mounted, connected, disconnected, and
controlled that may allow hot-plugging.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Unified power management userspace policy

[John Fremlin]

Hi all!

At the moment there are two power management drivers in the linux
kernel (AFAIK). They each have different userspace interfaces --
/proc/apm and /dev/apmctl and /proc/sys/acpi/events or something. This
is not altogether bad, but as they do the same thing, it might be nice
to unify (part) of the interface. In fact this is already done for the
in kernel interface with pm_send_all.

The kernel patch below extends the pm_send_all idea to ask userspace
if the event causing it should be allowed to go ahead or not. This
functionality is useful to me, because my power button sends an APM
user suspend to the kernel, which I wish to convert into a clean
shutdown -p now. The functionality is only hooked up to the APM driver
at the moment (because that was the only caller of pm_send_all that I
could find and ACPI doesn't seem to do anything useful on my box).

The kernel will run /sbin/powermanager (proc configurable) when it
receives a rejectable PM event. This is to my mind preferable to
having a power daemon because a PM event might occur even when the
daemon isn't started yet, you waste a process entry the whole time,
I'd have to implement a bunch of special file ops and binary
interfaces, and to parallel the hotplug system.

There is an APM specific patch floating around that would permit apmd
to reject suspend events. I played around with it for a bit updating
it to the late 2.4.0-test12 but I didn't like it because it did
suspend() directly after receiving the event from the BIOS, so my box
would suspend briefly before rejecting the event.

An example /sbin/powermanager should be being uploaded to my homepage
as I write:

http://www.penguinpowered.com/~vii/programs/linux/offbutton

or
http://john.snoop.dk/programs/linux/offbutton

The patch has been working fine for me in various forms since
2.4.0-prerelease came out, though I'm hardly a power user (pun).

It is against linux 2.4.0.



diff -u --recursive linux-clean/arch/i386/kernel/apm.c linux-hacked-pmpolicy/arch/i386/kernel/apm.c
--- linux-clean/arch/i386/kernel/apm.c	Sat Dec 30 00:21:33 2000
+++ linux-hacked-pmpolicy/arch/i386/kernel/apm.c	Mon Jan  8 21:15:23 2001
@@ -148,6 +148,8 @@
  *   1.14: Make connection version persist across module unload/load.
  * Enable and engage power management earlier.
  * Disengage power management on module unload.
+ *   ---   Modified to support new pm_event API (John Fremlin
+ * <[EMAIL PROTECTED]>)
  *
  * APM 1.1 Reference:
  *
@@ -884,30 +886,65 @@
 #endif
 }
 
+static int soft_suspend()
+{
+	struct pm_event pe;
+	memset(&pe,0,sizeof pe);
+
+	pe.pe_state = PM_STATE_SLEEP;
+	pe.pe_source = PME_SRC_SOFT;
+	pe.pe_flags = PME_FLAGS_REJECTABLE;
+
+	return pm_request_event(&pe);
+}
+
 static int send_event(apm_event_t event)
 {
+	struct pm_event pe;
+	memset(&pe,0,sizeof pe);
+
 	switch (event) {
 	case APM_SYS_SUSPEND:
+		pe.pe_state = PM_STATE_SLEEP;
+		pe.pe_source = PME_SRC_SYS;
+		pe.pe_flags = PME_FLAGS_REJECTABLE;
+		break;
+		
 	case APM_CRITICAL_SUSPEND:
+		pe.pe_state = PM_STATE_SLEEP;
+		pe.pe_source = PME_SRC_SYS;
+		break;
+			
 	case APM_USER_SUSPEND:
-		/* map all suspends to ACPI D3 */
-		if (pm_send_all(PM_SUSPEND, (void *)3)) {
-			if (event == APM_CRITICAL_SUSPEND) {
-printk(KERN_CRIT "apm: Critical suspend was vetoed, expect armageddon\n" );
-return 0;
-			}
-			if (apm_info.connection_version > 0x100)
-apm_set_power_state(APM_STATE_REJECT);
-			return 0;
-		}
+		pe.pe_state = PM_STATE_SLEEP;
+		pe.pe_source = PME_SRC_HWUSER;
+		pe.pe_flags = PME_FLAGS_REJECTABLE;
 		break;
-	case APM_NORMAL_RESUME:
+
 	case APM_CRITICAL_RESUME:
-		/* map all resumes to ACPI D0 */
-		(void) pm_send_all(PM_RESUME, (void *)0);
+		pe.pe_state = PM_STATE_WAKEFUL;
+		pe.pe_source = PME_SRC_SYS;
+		break;
+		
+	case APM_NORMAL_RESUME:
+		pe.pe_state = PM_STATE_WAKEFUL;
+		pe.pe_source = PME_SRC_HWUSER;
 		break;
+		
+	default:
+		return 1;
 	}
 
+	if(pm_prepare_for_event(&pe))
+	{
+		if (event == APM_CRITICAL_SUSPEND) {
+			printk(KERN_CRIT "apm: critical suspend was vetoed, expect armageddon\n" );
+			return 0;
+		}
+		if (apm_info.connection_version > 0x100)
+			apm_set_power_state(APM_STATE_REJECT);
+		return 0;
+	}
 	return 1;
 }
 
@@ -925,8 +962,10 @@
 		err = APM_SUCCESS;
 	if (err != APM_SUCCESS)
 		apm_error("suspend", err);
-	send_event(APM_NORMAL_RESUME);
 	sti();
+	/* We mustn't pm_event_lock because whoever is waiting for the
+	 * end of this suspend is holding the lock */
+	send_event(APM_NORMAL_RESUME);
 	queue_event(APM_NORMAL_RESUME, NULL);
 	for (as = user_list; as != NULL; as = as->next) {
 		as->suspend_wait = 0;
@@ -947,6 +986,21 @@
 		apm_error("standby", err);
 }
 
+static int apm_enter_state(pm_state_t*ps)
+{
+	switch(*ps){
+	case PM_STATE_SLEEP:
+		return suspend();
+	case PM_STATE_WAKEFUL:
+		return 0;
+	case PM_STATE_POWEROFF:
+		apm_power_off();
+		return 2; /* it didn't work, did it? */
+	default:
+		return 1;
+	}
+}
+
 static apm_event_

Re: msg : cannot create ksymoops/nnnnn.ksyms

[Keith Owens]

On Mon, 8 Jan 2001 23:30:12 +0100, 
f5ibh <[EMAIL PROTECTED]> wrote:
>Ok, I knew that, the problem is why unix.o is loaded so early ? I've not found
>where it is requested / loaded (I've kmod enabled). 

Probably syslog().

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

[OT]: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[J Sloan]

This is a little OT for linux-kernel, but I'll take a swing at it
since I'm running 2.4 and Xfree 4 with a voodoo 3.

After upgrading to Red Hat 7.0, I noticed 3D screensavers
and Quake 3 Arena were dog slow - in the end, I basically
had to make sure the mesa libs didn't get found before the
real opengl libs.

In my case, that meant nuking mesa from my system and
letting Linux use what was left, which got me back the good
accelerated performance - you may choose a less drastic
option. I don't see any breakage from the absence of mesa.

Hope this helps,

jjs


"Michael D. Crawford" wrote:

> OK, I built XFree86 4.0.2 and DRI seems to be working for me now under
> 2.4.0-ac4.  (Starting with 2.4.0, it wouldn't, this is with an ATI XPert 2000
> AGP).
>
> BUT - although /var/log/XFree86.0.log documents the startup of DRI, DRM and AGP,
> and states the info about their initialization and stuff so that it looks like
> they're working, I don't notice any performance difference running any of the
> Mesa-3.4 demos whether or not I use DRI, and whether I run 4.0.1 or 4.0.2.
>
> This makes me suspect it's not really working, or else my build of the Mesa-3.4
> library wasn't configured right - but note that if I disable DRI, one of the
> Mesa demos will comment that it's not available.
>
> A specific example is Mesa-3.4/demos/gloss.  It's a rotating textured cylinder
> that is partially reflective of what seems to be a landscape that is in front of
> the screen being reflecting back to the viewer.  I get a pretty consistent 7.5
> frames per second:
>
> - in 4.0.1 with no DRI
> - in 4.0.1 with DRI
> - in 4.0.2 with no DRI
> - in 4.0.2 with DRI
>
> Having agpgart and drm/r128 compiled in or as modules also doesn't appear to
> make a difference.
>
> The frame rate for gloss drops to about 3.5 if I run geartrain (another demo)
> alongside it.  Geartrain by itself seems to be about the same speed in all
> cases, though it doesn't report a number.
>
> There are a couple benchmarking tools in Mesa if someone wanted hard numbers
> from me.
>
> Can anyone suggest any 3D code that I can download that does more complex things
> than the mesa demos that I can test this with?
>
> Is my DRI really working?  If not, any tips on getting it to do so?
>
> Mike
> --
> Michael D. Crawford
> GoingWare Inc. - Expert Software Development and Consulting
> http://www.goingware.com/
> [EMAIL PROTECTED]
>
>Tilting at Windmills for a Better Tomorrow.
> -
> To unsubscribe from this list: send 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: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[khromy]

On Mon, Jan 08, 2001 at 06:35:43PM +, Michael D. Crawford wrote:
> OK, I built XFree86 4.0.2 and DRI seems to be working for me now under
> 2.4.0-ac4.  (Starting with 2.4.0, it wouldn't, this is with an ATI XPert 2000
> AGP).
> 
> BUT - although /var/log/XFree86.0.log documents the startup of DRI, DRM and AGP,
> and states the info about their initialization and stuff so that it looks like
> they're working, I don't notice any performance difference running any of the
> Mesa-3.4 demos whether or not I use DRI, and whether I run 4.0.1 or 4.0.2.
> 
> This makes me suspect it's not really working, or else my build of the Mesa-3.4
> library wasn't configured right - but note that if I disable DRI, one of the
> Mesa demos will comment that it's not available.
> 
> A specific example is Mesa-3.4/demos/gloss.  It's a rotating textured cylinder
> that is partially reflective of what seems to be a landscape that is in front of
> the screen being reflecting back to the viewer.  I get a pretty consistent 7.5
> frames per second:
> 
> - in 4.0.1 with no DRI
> - in 4.0.1 with DRI
> - in 4.0.2 with no DRI
> - in 4.0.2 with DRI
> 
> Having agpgart and drm/r128 compiled in or as modules also doesn't appear to
> make a difference.
> 
> The frame rate for gloss drops to about 3.5 if I run geartrain (another demo)
> alongside it.  Geartrain by itself seems to be about the same speed in all
> cases, though it doesn't report a number.
> 
> There are a couple benchmarking tools in Mesa if someone wanted hard numbers
> from me.
> 
> Can anyone suggest any 3D code that I can download that does more complex things
> than the mesa demos that I can test this with?
> 
> Is my DRI really working?  If not, any tips on getting it to do so?
I have this same problem with a Voodoo 3 2000(tdfx) running 2.4.0 and XFree86 4.0.2.

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

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[David S. Miller]

   Date: Mon, 8 Jan 2001 17:43:56 -0500
   From: Stephen Frost <[EMAIL PROTECTED]>

   Perhaps you missed it, but I believe Dave's intent is for
   this to only be a proof-of-concept idea at this time.

Thank you Stephen, this is the point Jes continues to miss.

Later,
David S. Miller
[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: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[David S. Miller]

   From: Jes Sorensen <[EMAIL PROTECTED]>
   Date: 08 Jan 2001 23:32:48 +0100

   All I am asking is that someone lets me know if they make major
   changes to my code so I can keep track of whats happening.

We have not made any major changes to your code, in lieu of this
not being code which is actually being submitted yet.

If it bothers you that publicly someone has published changes to your
driver which you disagree with, oh well... :-)

This "please check things out" phase is precisely what you are
asking of us, it is how we are saying "here is what we need to
do with your driver, please comment".

Later,
David S. Miller
[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: `rmdir .` doesn't work in 2.4

[Andries . Brouwer]

From: Andrea Arcangeli <[EMAIL PROTECTED]>

> But in fact it fails with EINVAL, and
> 
> [EINVAL]: The path argument contains a last component that is dot.

I can't confirm. The specs I'm checking are here:

http://www.opengroup.org/onlinepubs/007908799/xsh/rmdir.html

That is the SUSv2 text, one of the ingredients for the new
POSIX standard. I quoted the current Austin draft, the current
draft for the next version of the POSIX standard.

Quoting a text fragment:

The rmdir( ) function shall remove a directory whose name is given by
path. The directory is removed only if it is an empty directory.
If the directory is the root directory or the current working
directory of any process, it is unspecified whether the function
succeeds, or whether it shall fail and set errno to [EBUSY].
If path names a symbolic link, then rmdir( ) shall fail and
set errno to [ENOTDIR]. If the path argument refers to a path
whose final component is either dot or dot-dot, rmdir( ) shall
fail. ...


> Indeed, rmdir("P/D") does roughly the following:
> (i) check that P/D is a directory
> (ii) check that P/D does not have entries other than . and ..
> (iii) delete the names . and .. from P/D
> (iv) delete the name D from P

SUSv2 is straightforward. It doesn't talk about (iv).

I just made explicit what rmdir() actually does, in order to
show that a trailing dot really is a different case where
other rules than the usual ones would have to be applied.
Indeed, rmdir("foo/bar") finishes by removing the name "bar"
from the directory "foo", but rmdir("foo/.") does not finish
by removing the name "." from the directory "foo".

Andries


[Think classical Unix: there are inodes, and there are names.
The rmdir call, just like rm, removes names. Now foo and foo/.
may both be names for the same inode, but they are not the same name.]
-
To unsubscribe from this list: send 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: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Stephen Frost]

* Jes Sorensen ([EMAIL PROTECTED]) wrote:
> > "David" == David S Miller <[EMAIL PROTECTED]> writes:
> 
> I don't question Alexey's skills and I have no intentions of working
> against him. All I am asking is that someone lets me know if they make
> major changes to my code so I can keep track of whats happening. It is
> really hard to maintain code if you work on major changes while
> someone else branches off in a different direction without you
> knowing. It's simply a waste of everybody's time.

Perhaps you missed it, but I believe Dave's intent is for this to
only be a proof-of-concept idea at this time.  These changes are not 
currently up for inclusion into the mainstream kernel.  I can not think
that Dave would ever just step around a maintainer and submit a patch to
Linus for large changes.

If many people test these and things work out well for them 
then I'm sure Dave will go back to the maintainers with the code and 
the api and work with them to get it into the mainstream kernel.  
Soliciting ideas and suggestions on how to improve the api and the code 
paths in the drivers to handle this new method most effectively.

Stephen

 PGP signature

Re: lvm 0.8 to 0.9 conversion?

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 07:18:53PM +, Todd M. Roy wrote:
> 
> I've been on vacation
> 
> Nope, no snapshots.
> 
> Well, I couldn't get my orginal volume group visible under both
> lvm 0.8 and 0.9.  I don't know why.  So I grabbed a big empty hard disk,
> created a new volume group that was visible under both, dded all the logical
> volumes over to it, updated fstab  and removed the offending vg.  I've yet to
> recreate the original vg, copy stuff back and remove the new drive.
> I should point out that the offending vg was relatively ancient, I think I
> created it when 0.7 was king under some something like 2.2.14.  Now I'm 
> running 2.4.0-ac4 and all works well.

Good. You may consider to also apply this kernel-driver bugfix for
online extent/reduce of the VG and other assorted fixes:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0ac2/lvm-fix-1

I sumbitted them to Heinz a few days ago so that he can merge them with Linus.

Andrea
-
To unsubscribe from this list: send 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: The advantage of modules?

[Dan Hollis]

On Mon, 8 Jan 2001, Russell King wrote:
> Seriously though, you can't depreciate a term for referring to a type of
> bus without providing some other term to describe said bus.

You need to distinguish between SCSI-the-protocol and
SCSI-the-physical-layer. The term "SCSI" alone is simply too ambiguous to
be really useful anymore. I think you can use term "SCSI-1" or "SCSI-2"
when specicfally meaning SCSI protocol over classic 50 wire layer.

Saying "SCSI does not support hotplug" is very misleading.

Right now, the term "SCSI" is more akin to "IP".

-Dan

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

Re: `rmdir .` doesn't work in 2.4

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 03:11:08PM -0700, Benson Chow wrote:
> Not very portable at all...
> 
> hpux = HP/UX 10.2
> 
> hpux:~$ mkdir foo
> hpux:~$ cd foo
> hpux:~/foo$ rmdir "`pwd`"
> rmdir: /home/blc/foo: Cannot remove mountable directory
> hpux:~/foo$ rmdir .
> rmdir: cannot remove .. or .
> hpux:~/foo$ rmdir /home/blc/foo
> rmdir: /home/blc/foo: Cannot remove mountable directory
> hpux:~/foo$ rmdir ./
> rmdir: ./: Cannot remove mountable directory
> hpux:~/foo$
> 
> Maybe HP/UX is messed up as well.

It seems not to return -EBUSY. As also mentioned by Andries:

If the directory is the root directory or the current working directory
of any process, it is unspecified whether the function succeeds, or
whether it fails and sets errno to [EBUSY]. 

The portable way is the one I mentioned as possible change for my code:

os.chdir("..")
shutil.rmtree(binutils_build)

Andrea
-
To unsubscribe from this list: send 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: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Jes Sorensen]

> "David" == David S Miller <[EMAIL PROTECTED]> writes:

David> We _had_ to change some drivers to show how to support this new
David> SKB api for transmit sg+csum support.  If you can think of a
David> way for us to effectively do this work without changing at
David> least a few drivers as examples (and proof of concept), please
David> let us know.

Dave, I am not complaining about drivers having to be changed for this
to work I am fully aware of this need. My complaints are about how
this is being done, ie. I some people try to maintain drivers and have
certain ideas about how they structure their code etc. If you had sent
me a short email saying this is what we plan to do and this is what we
think should be done to your code, whats your oppinion. I would have
volunteered to help write the code and get the stuff integrated much
earlier as well as given you my input on how I would like to see the
changes implemented. Instead we now have a fairly large patch which
will take me a long time to merge into the driver version that I
maintain.

David> In the process we hit real bugs in your driver, and tried to
David> deal with them as best we could so that we could continue
David> testing and debugging our own code.

I would have appreciated a simple email saying "we found bug X in your
driver" with either a patch attached or a short note of your
observations.

David> As a side note, as much as you may hate some of Alexey's
David> changes to your driver, several things he does fixes long
David> standing real bugs in the Acenic driver that you've been
David> papering over with workarounds for quite some time.  I would
David> even go so far as to say that in many regards Alexey
David> understands the Acenic much better than you, and you would be
David> wise to work with Alexey and not against him.  Thanks.

I don't question Alexey's skills and I have no intentions of working
against him. All I am asking is that someone lets me know if they make
major changes to my code so I can keep track of whats happening. It is
really hard to maintain code if you work on major changes while
someone else branches off in a different direction without you
knowing. It's simply a waste of everybody's time.

Thanks
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: msg : cannot create ksymoops/nnnnn.ksyms

[f5ibh]

Hi Keith,
>> NET4: Unix domain sockets 1.0 for Linux NET4.0.
>> insmod: /lib/modules/2.2.19pre6/misc/unix.o: cannot create
> /var/log/ksymoops/20010106112242.ksyms Read-only file system

> man insmod, look for /var/log/ksymoops.  If you define this directory
> then it is expected to be writable when modules are loaded.  Logging
> module data for ksymoops is a user selectable option, you have to
> decide to use it, and you have done so.

Ok, I knew that, the problem is why unix.o is loaded so early ? I've not found
where it is requested / loaded (I've kmod enabled). 

>> insmod:/lib/modules/2.4.0/kernel/net/unix/unix.o : insmod net-pf-1 failed.

> "alias net-pf-1 unix" is a built in alias.  Looks like you did not
> compile for Unix sockets and something in the kernel wants Unix
> sockets.  If you really do not want Unix sockets, "alias net-pf-1 off".

This was a configuration error. I had missed a configuration step. Thank you.


Thank you and best regards

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

PCI IRQ routing on buggy BIOSes

[Petr Vandrovec]

Hi,
  following happened on my well-known SMP VIA based GA6VXD7 motherboard.

Last week on Thursday I decided to connect printer to the box. To do that
I had to switch parallel port mode from ECP to Normal (because of I
had problems with that printer). Today I found, that since that time
(Thu 3:57) my second bttv, which is used for teletext grabbing, stopped
functioning.

After some testing I found that correct IRQ is 19, and not 18... And after
turning some options in BIOS I found that it is related to parallel port
setting:

Parallel port setting:   Normal   ECP driver/location
B0,I7,P3   18 19  usb 00:07.2 (not used)
B0,I7,P3   18 19  usb 00:07.3 (not used)
B0,I10,P0  18 18  bttv0 0:0a.0
B0,I11,P0  18 19  bttv1-video 0:0b.0
B0,I11,P0  18 19  bttv1-audio 0:0b.1
B0,I13,P0  17 17  eth0 0:0d.0
B0,I14,P0  18 18  dsp0 0:0e.0
B1,I0,P0   16 16  dri0 1:00.0

Of course table reported for ECP mode is correct one. Anybody have any
idea how to get it to work in Normal/EPP mode without hardwiring this
routing table to kernel? There are no complaints in system dmesg.

Every IRQ in BIOS is selected as PCI/PnP, as there are no ISA devices
in box (except on-board southbridge COM/LPT). PnP OS setting does not
matter.

There is also one difference at BIOS info screen: in first case (normal),
it prints _all_ these devices on IRQ10, while in ECP mode some devices 
use IRQ5. Probably another bug in Award core, they generate wrong
PIRQ routing table when couple (all 4) PIRQ are routed to same 8259 IRQ :-(
This leaves open why all devices use IRQ10 in 8259 mode - are other really 
used by onboard unshareable ACPI/RTC/IDE/COM/LPT/PS2/KBD/TIMER/FLOPPY?!
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]

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

bigmem (2GB in this case) patches for the 2.0.x kernel.

[Adam Scislowicz]

I have had no luck finding a bigmem patch for the 2.0.x kernel. I am in
the situation where I would rather not update the kernel,  do I have
any options?

 -Adam Scislowicz <[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: The advantage of modules?

[Russell King]

Dan Hollis writes:
> On Mon, 8 Jan 2001, Russell King wrote:
> > I don't believe that is what it's trying to say.  There have been instances
> > in the past where unplugging a SCSI device from a powered on SCSI bus can
> > result in blown terminator power fuses and the like.  Whether this still
> > applies today, I don't know (are active terminators better or worse than
> > passive when it comes to this type of thing?)
> 
> The term SCSI is depreciated as purely a physical layer. We talk SCSI over
> many different physical layers (1394, usb, ata). Of course many of these
> support hot plug natively.

And can you please explain how I can attach this USB Zip drive to this
50-wire SCSI bus please?  Or would you prefer me to call it a bus?
Something with 4 wheels maybe?  Maybe we should depreciate the term "bus"
as well just to remove that confusion. ;)

Seriously though, you can't depreciate a term for referring to a type of
bus without providing some other term to describe said bus.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Subtle MM bug

[Andrea Arcangeli]

On Mon, Jan 08, 2001 at 02:00:19PM -0800, Wayne Whitney wrote:
> I'd ask if this jives with your theory:  if I configure the linux kernel
> to be able to use 2GB of RAM, then the 870MB limit becomes much lower, to
> 230MB.

It's because the virtual address space for userspace tasks gets reduced
from 3G to 2G to give an additional giga of direct mapping to the kernel.

Also the other limit you hit (at around 800mbyte) is partly because
of the too low userspace virtual address space.

You can use this hack by me to allow the tasks to grow up to 3.5G per task on
IA32 on 2.4.0 (equivalent hack exists for 2.2.19pre6aa1 with bigmem, btw it
makes sense also without bigmem if you have lots of swap, that's all about
virtual memory not physical RAM).  However it doesn't work with PAE enabled
yet.


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test11-pre5/per-process-3.5G-IA32-no-PAE-1

If you run your program on any 64bit architecture (in 64bit userspace mode)
supported by linux, you won't run into those per-process address space limits.

Andrea
-
To unsubscribe from this list: send 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: The advantage of modules?

[Dan Hollis]

On Mon, 8 Jan 2001, Russell King wrote:
> > so my take is unless you explicitly use hotplug devices (I wasn't), that
> > it is much safer to unload the driver, unattach/attach scsi devices, and
> > then reload the driver (which will scan the scsi bus for devices), which
> > you need modules for.
> I don't believe that is what it's trying to say.  There have been instances
> in the past where unplugging a SCSI device from a powered on SCSI bus can
> result in blown terminator power fuses and the like.  Whether this still
> applies today, I don't know (are active terminators better or worse than
> passive when it comes to this type of thing?)

The term SCSI is depreciated as purely a physical layer. We talk SCSI over
many different physical layers (1394, usb, ata). Of course many of these
support hot plug natively.

You can get hotplug adapters for ata devices now. Can linux handle them?

-Dan

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

Re: `rmdir .` doesn't work in 2.4

[Benson Chow]

Not very portable at all...

hpux = HP/UX 10.2

hpux:~$ mkdir foo
hpux:~$ cd foo
hpux:~/foo$ rmdir "`pwd`"
rmdir: /home/blc/foo: Cannot remove mountable directory
hpux:~/foo$ rmdir .
rmdir: cannot remove .. or .
hpux:~/foo$ rmdir /home/blc/foo
rmdir: /home/blc/foo: Cannot remove mountable directory
hpux:~/foo$ rmdir ./
rmdir: ./: Cannot remove mountable directory
hpux:~/foo$

Maybe HP/UX is messed up as well.

But anyway I'll try to step out of the building that i'm trying to blow
up, regardless of whether or not it will work on a particular OS will
hold onto a floor of it till it's done with it...

-bc

On Mon, 8 Jan 2001, Stefan Traby wrote:

> Date: Mon, 8 Jan 2001 22:54:51 +0100
> From: Stefan Traby <[EMAIL PROTECTED]>
> To: Alexander Viro <[EMAIL PROTECTED]>
> Cc: Andrea Arcangeli <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: `rmdir .` doesn't work in 2.4
>
> On Mon, Jan 08, 2001 at 12:58:20PM -0500, Alexander Viro wrote:
>
> > Shell equivalent is rmdir `pwd`. Also portable.
>
> Very portable - not.
>
> rmdir "`pwd`" !!!
>
> --
>
>   ciao -
> Stefan
>
> " ( cd /lib ; ln -s libBrokenLocale-2.2.so libNiedersachsen.so ) "
>
> Stefan TrabyLinux/ia32   fax:  +43-3133-6107-9
> Mitterlasznitzstr. 13   Linux/alphaphone:  +43-3133-6107-2
> 8302 Nestelbach Linux/sparc   http://www.hello-penguin.com
> Austriamailto:[EMAIL PROTECTED]
> Europe   mailto:[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/
>




-
To unsubscribe from this list: send 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: Delay in authentication.gy

[David S. Miller]

   Date:Mon, 8 Jan 2001 22:01:26 + (GMT)
   From: Alan Cox <[EMAIL PROTECTED]>

   > Solaris and other systems act identically.

   And have identical bad problems with auth failures.

Actually, I believe their sunrpc library uses an extended error
facility via the streams APIs that works similar to what is available
under Linux to solve this problem.

Later,
David S. Miller
[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: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Bill Nottingham]

Michael D. Crawford ([EMAIL PROTECTED]) said: 
> This makes me suspect it's not really working, or else my build of the Mesa-3.4
> library wasn't configured right - but note that if I disable DRI, one of the
> Mesa demos will comment that it's not available.

It sounds as if you're using a Mesa lib that doesn't support the
X DRI stuff, just the software renderer.

Bill
-
To unsubscribe from this list: send 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: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[David S. Miller]

   From: Jes Sorensen <[EMAIL PROTECTED]>
   Date: 08 Jan 2001 22:56:48 +0100

   I don't think it's too much to ask that one actually tries to
   communicate with an author of a piece of code before making such
   major changes and submitting them opting for inclusion in the
   kernel.

Jes, I have not submitted this for inclusion into the kernel.

This is the "everyone, including driver authors, take a look"
part of the development process.

We _had_ to change some drivers to show how to support this
new SKB api for transmit sg+csum support.  If you can think of
a way for us to effectively do this work without changing at least a
few drivers as examples (and proof of concept), please let us know.

In the process we hit real bugs in your driver, and tried to deal
with them as best we could so that we could continue testing and
debugging our own code.

As a side note, as much as you may hate some of Alexey's changes to
your driver, several things he does fixes long standing real bugs in
the Acenic driver that you've been papering over with workarounds
for quite some time.  I would even go so far as to say that in many
regards Alexey understands the Acenic much better than you, and you
would be wise to work with Alexey and not against him.  Thanks.

Later,
David S. Miller
[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: DRI doesn't work on 2.4.0 but does on prerelease-ac5

[Michael D. Crawford]

OK, I built XFree86 4.0.2 and DRI seems to be working for me now under
2.4.0-ac4.  (Starting with 2.4.0, it wouldn't, this is with an ATI XPert 2000
AGP).

BUT - although /var/log/XFree86.0.log documents the startup of DRI, DRM and AGP,
and states the info about their initialization and stuff so that it looks like
they're working, I don't notice any performance difference running any of the
Mesa-3.4 demos whether or not I use DRI, and whether I run 4.0.1 or 4.0.2.

This makes me suspect it's not really working, or else my build of the Mesa-3.4
library wasn't configured right - but note that if I disable DRI, one of the
Mesa demos will comment that it's not available.

A specific example is Mesa-3.4/demos/gloss.  It's a rotating textured cylinder
that is partially reflective of what seems to be a landscape that is in front of
the screen being reflecting back to the viewer.  I get a pretty consistent 7.5
frames per second:

- in 4.0.1 with no DRI
- in 4.0.1 with DRI
- in 4.0.2 with no DRI
- in 4.0.2 with DRI

Having agpgart and drm/r128 compiled in or as modules also doesn't appear to
make a difference.

The frame rate for gloss drops to about 3.5 if I run geartrain (another demo)
alongside it.  Geartrain by itself seems to be about the same speed in all
cases, though it doesn't report a number.

There are a couple benchmarking tools in Mesa if someone wanted hard numbers
from me.

Can anyone suggest any 3D code that I can download that does more complex things
than the mesa demos that I can test this with?

Is my DRI really working?  If not, any tips on getting it to do so?

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]

   Tilting at Windmills for a Better Tomorrow.
-
To unsubscribe from this list: send 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: Delay in authentication.gy

[Alan Cox]

> It was intentionally changed because there is no way for the "ICMP
> port unreachable" message coming back to be uniquely matched to that
> UDP socket.  It can reset sockets illegally in high load scenerios.
> 
> Solaris and other systems act identically.

And have identical bad problems with auth failures. Right now I've given up
trying to make 2.4 and YP mix because my RH setup assumes NIS auth will fail
fast during boot up scripts and it doesnt.

Unfortunately for the quickfix folks, Dave is right about needing to sort it,
and that means someone has to sort glibc to use the new interfaces

-
To unsubscribe from this list: send 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.2.18 and EMU10K1 problems...

[Taner Halicioglu]

Err, I should have mentioned that the configs I used for .17 and .18 are
identical, too.  Machine is a dual celeron 450 on a asus p2b-ds (Adaptec
aic78xx SCSI), via-rhine ethernet, and nvidia tnt2 ultra.

Thanks, again

-Taner

On Mon, Jan 08, 2001 at 01:56:29PM -0800, Taner Halicioglu <[EMAIL PROTECTED]> wrote:

> (please cc me if you reply - thanks :)
> 
> I probably missed a message or note or something about this, but when I went
> from 2.2.17 to 2.2.18, my sound card (SB Live!) stopped working.  It seems
> that in 2.2.18, it gets detected TWICE:
> 
> 
> kernel: Linux version 2.2.18
> [...]
> kernel: Creative EMU10K1 PCI Audio Driver, version 0.7, 20:05:23 Jan  7 2001 
> kernel: emu10k1: EMU10K1 rev 5 model 0x21 found, IO at 0xb400-0xb41f, IRQ 10 
> [... IDE, floppy, SCSI, eth0, partition check ...]
> kernel: Creative EMU10K1 PCI Audio Driver, version 0.7, 20:05:23 Jan  7 2001 
> 
> 
> This is what it normally does:
> 
> 
> kernel: Linux version 2.2.17
> [...]
> kernel: Creative EMU10K1 PCI Audio Driver, version 0.6, 20:25:53 Jan  7 2001 
> kernel: emu10k1: EMU10K1 rev 5 model 0x21 found, IO at 0xb400-0xb41f, IRQ 10 
> [...]
> 
> 
> In the 2.2.18 case, /proc/interrupts doesn't show anything on int 10.
> 
> I guess I should (and will) take this up with the EMU10k people, but I was
> just wondering if anyone here has seen this problem before?  I'm curious how
> a broken driver would have made it into .18 like that ;-)  ...unless I'm the
> one that is broken :)
> 
> Thanks,
> 
>   -Taner
-
To unsubscribe from this list: send 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: Subtle MM bug

[Wayne Whitney]

On Mon, 8 Jan 2001, Szabolcs Szakacsits wrote:

> AFAIK newer glibc = CVS glibc but the malloc() tune parameters work
> via environment variables for the current stable ones as well, e.g. to
> overcome the above "out of memory" one could do,
>
> % export MALLOC_MMAP_MAX_=100
> % export MALLOC_MMAP_THRESHOLD_=0
> % magma

As I just mentioned, I haven't been able to test this yet due to my
current binary being linked against an older libc with doesn't seem to
have these parameters.  But here's one other data point, I just thought
I'd ask if this jives with your theory:  if I configure the linux kernel
to be able to use 2GB of RAM, then the 870MB limit becomes much lower, to
230MB.

Cheers, Wayne



-
To unsubscribe from this list: send 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: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[Jes Sorensen]

> "David" == David S Miller <[EMAIL PROTECTED]> writes:

David> I've put a patch up for testing on the kernel.org mirrors:

David> /pub/linux/kernel/people/davem/zerocopy-2.4.0-1.diff.gz

David> It provides a framework for zerocopy transmits and delayed
David> receive fragment coalescing.  TUX-1.01 uses this framework.

David> Zerocopy transmit requires some driver support, things run as
David> they did before for drivers which do not have the support
David> added.  Currently sg+csum driver support has been added to
David> Acenic, 3c59x, sunhme, and loopback drivers.  We had eepro100
David> support coded at one point, but it was removed because we
David> didn't know how to identify the cards which support hw csum
David> assist vs. ones which could not.

I haven't had time to test this patch, but looking over the changes to
the acenic driver I have to say that I am quite displeased with the
way the changes were done. I can't comment on how authors of the other
drivers which were changed feel about it. However I find it highly
annoying that someone goes off and makes major cosmetic structural
changes to someone elses code without even consulting the author who
happens to maintain the code. It doesn't help that the patch reverts
changes that should not have been reverted.

I don't think it's too much to ask that one actually tries to
communicate with an author of a piece of code before making such major
changes and submitting them opting for inclusion in the kernel.

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/

2.2.18 and EMU10K1 problems...

[Taner Halicioglu]

(please cc me if you reply - thanks :)

I probably missed a message or note or something about this, but when I went
from 2.2.17 to 2.2.18, my sound card (SB Live!) stopped working.  It seems
that in 2.2.18, it gets detected TWICE:


kernel: Linux version 2.2.18
[...]
kernel: Creative EMU10K1 PCI Audio Driver, version 0.7, 20:05:23 Jan  7 2001 
kernel: emu10k1: EMU10K1 rev 5 model 0x21 found, IO at 0xb400-0xb41f, IRQ 10 
[... IDE, floppy, SCSI, eth0, partition check ...]
kernel: Creative EMU10K1 PCI Audio Driver, version 0.7, 20:05:23 Jan  7 2001 


This is what it normally does:


kernel: Linux version 2.2.17
[...]
kernel: Creative EMU10K1 PCI Audio Driver, version 0.6, 20:25:53 Jan  7 2001 
kernel: emu10k1: EMU10K1 rev 5 model 0x21 found, IO at 0xb400-0xb41f, IRQ 10 
[...]


In the 2.2.18 case, /proc/interrupts doesn't show anything on int 10.

I guess I should (and will) take this up with the EMU10k people, but I was
just wondering if anyone here has seen this problem before?  I'm curious how
a broken driver would have made it into .18 like that ;-)  ...unless I'm the
one that is broken :)

Thanks,

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