Re: kmalloc() allocation.

[Mark W. McClelland]

"Richard B. Johnson" wrote:
> 
> Hello,
> How much memory would it be reasonable for kmalloc() to be able
> to allocate to a module?
> 
> Oct 30 10:48:31 chaos kernel: kmalloc: Size (524288) too large
> 
> Using Version 2.2.17, I can't allocate more than 64k!  I need
> to allocate at least 1/2 megabyte and preferably more (like 2 megabytes).

I glad someone asked this. The embedded system I am working on requires
that I allocate about at least 64KB or so of physically contiguous RAM,
to be used as the "backing store" for a PCI<->SDRAM mapper chip. What
makes this difficult is that it has to be aligned on a 256KB boundary,
so the only way to guarantee this is to allocate 512KB and only use the
256KB-aligned chunk within that. 

I have already tried reserving the memory at boot time with the mem
kernel argument, but our boot loader is broken and the kernel won't boot
when arguments are passed to the kernel. Is there an easy way to
hardcode this argument into the kernel?

I have also looked into allocation at boot time, but the init functions
in init/main.c no longer have a return value in 2.4. Is there still a
way to do this?

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

Re: Readiness vs. completion (was: Re: Linux's implementationofpoll()not scalable?)

[Dan Kegel]

John Gardiner Myers wrote:
> 
> Dan Kegel wrote:
> > IMHO you're describing a situation where a 'completion notification event'
> > (as with aio) would be more appropriate than a 'readiness notification event'
> > (as with poll).
> 
> I've found that I want both types of events, preferably through the same
> interface.  

That's good to know.

> To provide a "completion notification event" interface on
> top of an existing nonblocking interface, one needs an "async poll"
> mechanism with edge-triggered events with no event coalescing.

If you have a top-notch completion notification event interface
provided natively by the OS, though, does that get rid of the
need for the "async poll" mechanism?
 
> You are correct in recognizing NT completion ports from my description.
> While the NT completion port interface is ugly as sin, it gets a number
> of performance issues right.
> 
> > And, come to think of it, network programmers usually can be categorized
> > into the same two groups :-)  Each style of programming is an acquired taste.
> 
> I would say that the "completion notification" style is a paradigm
> beyond the "readiness notification" style.  I started with the select()
> model of network programming and have since learned the clear
> superiority of the "completion notificatin" style.

Both seem to have their place, and deserve good support, IMHO.

- 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: kmalloc() allocation.

[Mike Galbraith]

On Mon, 30 Oct 2000, Rik van Riel wrote:

> On Mon, 30 Oct 2000, Richard B. Johnson wrote:
> 
> > How much memory would it be reasonable for kmalloc() to be able
> > to allocate to a module?
> 
> > There are 256 megabytes of SDRAM available. I don't think it's
> > reasonable that a 1/2 megabyte allocation would fail, especially
> > since it's the first module being installed.
> 
> If you write the defragmentation code for the VM, I'll
> be happy to bump up the limit a bit ...

Hmm.. Bill Hawes wrote a memory defragger a long time ago.  I have a
copy of it lying around if you want to take a look at it.

-Mike

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

Re: 2.2.18Pre Lan Performance Rocks!

[Ingo Molnar]

On Mon, 30 Oct 2000, Jeff V. Merkey wrote:

> Ingo's helping me get the info together on this for putting a MARS-NWE
> tux module in the kernel. [...]

TUX modules are user-space, so i certainly cannot help you in 'putting
MARS-NWE in the kernel'. While you (apparently) are trying to move server
applications into ring0, i agree with Andrea and i'm trying to move kernel
functionality out to user-space.

> He had to go do some things this week he told me before he would be
> ready to look at it. He did point me over to the info, and I agreed we
> would attempt to implement it as something to look at. If it performs
> well enough, I will have something reasonable to send out to Novell
> Resellers (CNEs) and Cutomers.

All i did was to inform you that the next release of TUX is imminent and
that you might want to take a look at the new code. You interpreted that
in a very interesting way. You are certainly free and welcome to take a
look at any code and documentation released, but as visible in the past
couple of email exchanges, our technical views about Linux networking
scalability differ in fundamental ways.

Ingo

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

[ANNOUNCE] SUBTERFUGUE 0.1.99a (bugfix)

[Mike Coleman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This mini-release just fixes a bug that could allow processes to escape
tracing under certain circumstances.  If you plan to make use of 'sf', you
should upgrade.

- --Mike


See http://subterfugue.org for info on SUBTERFUGUE.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard 

iD8DBQE5/mo0HxpYi0vMj/QRAmE6AJ9N/V57LZ6qUzYdSOsiAihqACQIEgCfVm7h
KShS58o2uzOWHyMUtUg5U9A=
=YKmp
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: kmalloc() allocation.

[Brian Gerst]

"H. Peter Anvin" wrote:
> 
> Followup to:  <[EMAIL PROTECTED]>
> By author:"Richard B. Johnson" <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will
> > > happily grab you 2Mb of space but it will not be physically linear
> > >
> >
> > Okay. Thanks.
> >
> 
> FWIW, vmalloc()-allocated pages are definitely pinned-down and
> available to interrupts.  However, you should keep in mind that the
> vmalloc() call *itself* is quite expensive on SMP machines (have to
> interrupt all CPUs and flush their TLBs!!) so if you're using
> vmalloc(), be careful with the number of calls you make.  Of course,
> this is usually not a problem.

This was just changed in 2.4 so that vmalloced pages are faulted in on
demand.

--

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

Re: test10-pre7

[Linus Torvalds]

On Tue, 31 Oct 2000, Rusty Russell wrote:
> 
> Quiet suggestion:

If I understood the GNU make syntax correctly (which is possibly not the
case - GNU make is possibly the only example of "overkill" to rival GNU
emacs), this looks like a reasonable idea.

However, it also looks like much more of a change than to change the
fairly boiler-plate OX_OBJS etc stuff in new-style makefiles. And quite
frankly, I don't see how it would get the multi-part object file case
right, but that's probably because you left off some of the black magic
required to do that (and it's not as if the current Makefile magic doesn't
do black magic for that already).

Why do I really care? We actually have the same issue in the SCSI driver
directory, where the ordering restraints are much stricter than for USB.
Now that case has fewer export-objs, and that case isn't a part of a
multi-list, but I really want to have something that works for both these
cases with minimal (and reasonably straightforward) surgery.

In fact, I suspect the SCSI rules would work almost as-is. They break
ordering for the export-objs entry, but that looks fixable. This is how it
looks now:

# Extract lists of the multi-part drivers.
# The 'int-*' lists are the intermediate files used to build the multi's.
multi-y := $(filter $(list-multi), $(obj-y))
multi-m := $(filter $(list-multi), $(obj-m))
int-y   := $(sort $(foreach m, $(multi-y), $($(basename $(m))-objs)))
int-m   := $(sort $(foreach m, $(multi-m), $($(basename $(m))-objs)))

# Files that are both resident and modular: remove from modular.
obj-m   := $(filter-out $(obj-y), $(obj-m))
int-m   := $(filter-out $(int-y), $(int-m))

O_OBJS  := $(filter-out $(export-objs), $(obj-y))
OX_OBJS := $(filter $(export-objs), $(obj-y))
M_OBJS  := $(sort $(filter-out  $(export-objs), $(obj-m)))
MX_OBJS := $(sort $(filter  $(export-objs), $(obj-m)))
MI_OBJS := $(sort $(filter-out  $(export-objs), $(int-m)))
MIX_OBJS:= $(sort $(filter  $(export-objs), $(int-m)))

In the above, the only problem is OX_OBJS and the breaking of ordering of
"export-objs" (which SCSI doesn't care about, unlike USB, partly because
SCSI uses the old-fashioned "every export in a special file" approach).
And it looks like even THAT could be fixed by changing it to

O_OBJS  := $(obj-y)
OX_OBJS :=
MIX_OBJS:= $(sort $(filter  $(export-objs), $(int-m) $(obj-y)))

(and the others are unchanged) which looks like it would handle it all
correctly. Basically, the changes would mean that the export-objs subset
of $(obj-y) would stay in O_OBJS instead of moving to OX_OBJS, but
additionally those objs would also be added to MIX_OBJS.

Would this satisfy everybody? It _is_ complex enough that I guess it
easily rates having it's own rule-file and be included by new-style
Makefiles instead of being copied over and over again..

Rusty's suggestion would mean having to actually change all the lists
themselves, which at this point sounds a bit dangerous.

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: kmalloc() allocation.

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:"Richard B. Johnson" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> > 64K probably less. kmalloc allocates physically linear spaces. vmalloc will
> > happily grab you 2Mb of space but it will not be physically linear
> > 
> 
> Okay. Thanks.
> 

FWIW, vmalloc()-allocated pages are definitely pinned-down and
available to interrupts.  However, you should keep in mind that the
vmalloc() call *itself* is quite expensive on SMP machines (have to
interrupt all CPUs and flush their TLBs!!) so if you're using
vmalloc(), be careful with the number of calls you make.  Of course,
this is usually not a problem.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:
> On Mon, 30 Oct 2000 16:47:15 -0800 (PST), 
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >Actually, I think I have an even simpler solution, which is to change the
> >newstyle rule to something very simple:
> >
> > # Translate to Rules.make lists.
> >
> > O_OBJS  := $(obj-y)
> > M_OBJS  := $(obj-m)
> > MIX_OBJS:= $(export-objs)
> 
> make modules depends on MIX_OBJS, with the above change make modules
> now depends on kernel objects.  Can be fixed in Rules.make, but only if
> every Makefile is changed (code freeze, what code freeze?).

Quiet suggestion:

Maybe better is to get rid of the X version variables?  Append -EXPORTS
to everything that exports, and generate the genksyms food from:

$(patsubst %.o-EXPORTS,%.c, $(filter %-EXPORTS, $(OBJS))

And the link line from:

$(patsubst %-EXPORTS, %, $(OBJS))

This allows complete control over the link order.
Rusty.
--
Hacking time.
-
To unsubscribe from this list: send 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: UDMA/66 Data Corruption on SiS530

[Andre Hedrick]

On Mon, 30 Oct 2000, Steven Walter wrote:

> 
> Recently, when trying to use UDMA/66 on my SiS 530 and
> WD84AA, I got some data corruption.  At first, I tried
> with "UDMA Enabled" set to off in the BIOS, because I
> had known this to previously cause problems.  However,
> like this, I couldn't set the harddrive to use UDMA
> mode4 (-X68).  I would set it, it would appear
> successful, check with hdparm -i, and it would still
> say mode2.  Additionally, there was no speed increase
> after the -X68.

Check your logs and see if their is a speed setting block issued, only if
you are using patched 2.2x or 2.4.0x kernels will this report be
generated.

> Before, on a 40-conductor cable, I was getting 11MB/s
> with hdparm -t .  I bought an 80-conductor cable
> today, and saw no speed improvement in mode2, which is

This clear indicates a problem in the device pairing or you have not
enable the entire driver.

> the only mode I can set it to.  Something that striked
> me as odd about the cable, though, is that the red
> wire was broken between the Drive 1 socket and the
> Drive 0 socket.  Is this to differentiate the two?

Explain...

> Anyway, what's interesting is what happens after I
> turned "UDMA Enabled" on in the BIOS.  Upon booting,
> everything appeared normal until just before X
> started.  At this point, I got a
> 
> dma_intr: hda: status=0x58 { DriveReady SeekComplete
> Error}
> error=0x0 { }
> 
> I'm not sure about the numbers, but I am sure about
> the texts.  The drive said there was an error, but no
> error was set.  After fooling around with hdparm
> (setting the drive to -X68, timing it, etc) I got a
> few more identical errors.  Then, I started getting
> errors from EXT3-fs regarding invalid/corrupt data.

If you are using "EXT3-fs" journalling and your write cache is not
disable, you are TOAST!  I just now got the drive venders to auto-update
the contents of the identify page that reports the features set and
masked.

Regards,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

-
To unsubscribe from this list: send 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: Is IPv4 totally broken in 2.4-test

[Mohammad A. Haque]

if [ -f /proc/sys/net/ipv4/tcp_ecn ]
then
echo "0" >/proc/sys/net/ipv4/tcp_ecn
fi

or dont compile with ECN support int he kernel.

Carl Perry wrote:
> 
> I have test9 running in an original Athlon 500, a PII 300, and a K6-2/400.  All
> of them are experiencing the same problems with networking.  I confimred that
> this is not happening to just my, as my buddy in a far away (California) land is
> experiencing the same thing.  I cannot connect to ubid.com, landsend.com,
> etrade.com, travelocity.com, and a slew of others.  I'm not sure if this is
> because all of those sites are going "Wow!  His IP stack conforms to _STANDARDS_
> - it must be fake" or what.  However, it's really starting to get on my nerves.
> 
> All of the above boxes are based on SuSE 6.4.  Using the latest modutils,
> binutils 2.10, and egcs-1.1.2 (Which I think is still compiler gratas)  My
> buddy's box is a Mandrake 7.1 box.  I know he was using gcc-2.95.2 and an old
> binutils, but he has changed to egcs-1.1.2 and a newer binutils.  He's still
> having the same problem.  I pretty sure it's not an iptables issue, since I
> believe that he has iptables off.  I also tried no tables on my K6-2 box with
> the same effects.
> 
> Is anyone else experiencing these problems?  Does anyone know if certain
> firewalls don't like 2.4 with a passion?  Even better, does anyone know how to
> fix it?
> 
> BTW: I have narrowed this down to a 2.4 problem.  If I load 2.2 on any of those
> machines on the same ISP it doesn't work.
> 
> Any ideas?
> --
> -Carl Perry
> [EMAIL PROTECTED]
> 
> "Real programmers don't draw flowcharts.  Flowcharts are, after
> all, the illiterate's form of documentation.  Cavemen drew
> flowcharts; look how much good it did them."
> -Fortune (The App, not the Magazine)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Q: ip_masq module for battlecom?

[William Stearns]

Good evening, Gerhard,

On Mon, 30 Oct 2000, Gerhard Fuellgrabe wrote:

> in my LAN there are users working on battle.net (Starcraft,
> Diablo2 etc.). There is a Linux 2.2.14 box routing the LAN
> with private IP addresses to the internet (with IP masqerading).
> 
> A feature that does not work is the battlecom communication. 
> Is there an ip_masq module available for this (like e.g. 
> ipv4/ip_masq_cuseeme.o or ipv4/ip_masq_quake.o) or is anybody
> working on this?

See the "Application Support" link at http://ipmasq.cjb.net for
information about specific applications under masquerading.
Future questions about masquerade support should go to the
ip-masq mailing list; info on that list can also be found at the above
link.
Best of luck.
Cheers,
- Bill

---
"Put down those Windows disks, Dave..."
-- HAL
--
William Stearns ([EMAIL PROTECTED]).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.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/

Is IPv4 totally broken in 2.4-test

[Carl Perry]

I have test9 running in an original Athlon 500, a PII 300, and a K6-2/400.  All
of them are experiencing the same problems with networking.  I confimred that
this is not happening to just my, as my buddy in a far away (California) land is
experiencing the same thing.  I cannot connect to ubid.com, landsend.com,
etrade.com, travelocity.com, and a slew of others.  I'm not sure if this is
because all of those sites are going "Wow!  His IP stack conforms to _STANDARDS_
- it must be fake" or what.  However, it's really starting to get on my nerves.

All of the above boxes are based on SuSE 6.4.  Using the latest modutils,
binutils 2.10, and egcs-1.1.2 (Which I think is still compiler gratas)  My
buddy's box is a Mandrake 7.1 box.  I know he was using gcc-2.95.2 and an old
binutils, but he has changed to egcs-1.1.2 and a newer binutils.  He's still
having the same problem.  I pretty sure it's not an iptables issue, since I
believe that he has iptables off.  I also tried no tables on my K6-2 box with
the same effects.

Is anyone else experiencing these problems?  Does anyone know if certain
firewalls don't like 2.4 with a passion?  Even better, does anyone know how to
fix it?

BTW: I have narrowed this down to a 2.4 problem.  If I load 2.2 on any of those
machines on the same ISP it doesn't work.

Any ideas?
-- 
-Carl Perry
[EMAIL PROTECTED]

"Real programmers don't draw flowcharts.  Flowcharts are, after
all, the illiterate's form of documentation.  Cavemen drew
flowcharts; look how much good it did them."
-Fortune (The App, not the Magazine)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

UDMA/66 Data Corruption on SiS530

[Steven Walter]

Recently, when trying to use UDMA/66 on my SiS 530 and
WD84AA, I got some data corruption.  At first, I tried
with "UDMA Enabled" set to off in the BIOS, because I
had known this to previously cause problems.  However,
like this, I couldn't set the harddrive to use UDMA
mode4 (-X68).  I would set it, it would appear
successful, check with hdparm -i, and it would still
say mode2.  Additionally, there was no speed increase
after the -X68.

Before, on a 40-conductor cable, I was getting 11MB/s
with hdparm -t .  I bought an 80-conductor cable
today, and saw no speed improvement in mode2, which is
the only mode I can set it to.  Something that striked
me as odd about the cable, though, is that the red
wire was broken between the Drive 1 socket and the
Drive 0 socket.  Is this to differentiate the two?

Anyway, what's interesting is what happens after I
turned "UDMA Enabled" on in the BIOS.  Upon booting,
everything appeared normal until just before X
started.  At this point, I got a

dma_intr: hda: status=0x58 { DriveReady SeekComplete
Error}
error=0x0 { }

I'm not sure about the numbers, but I am sure about
the texts.  The drive said there was an error, but no
error was set.  After fooling around with hdparm
(setting the drive to -X68, timing it, etc) I got a
few more identical errors.  Then, I started getting
errors from EXT3-fs regarding invalid/corrupt data. 
This concerned me, so I tried a "shutdown -r now", but
to no avail.  I instead did a SysRq
Sync-Unmount-reBoot.  Upon rebooting, I could no
longer mount my root fs due to "Invalid track type or
session number," or something to that effect.  I tried
using e2fsck, but I can't find a valid superblock on
the root partition.  Other partitions on the drive
remain intact, however.

If anyone can shed any light on this problem, it would
be much appreciated.  I wonder whether this is a linux
bug, or a hardware problem, and if a hardware problem, where?

=
-Steven

"The most foolish mistake we could possibly make would be to allow the subject races 
to possess arms. History shows that all conquerors who have allowed their subject 
races to carry arms have prepared their own downfall by doing so."
Adolph Hitler

__
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.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/

Q: ip_masq module for battlecom?

[Gerhard Fuellgrabe]

Hi folks,

in my LAN there are users working on battle.net (Starcraft,
Diablo2 etc.). There is a Linux 2.2.14 box routing the LAN
with private IP addresses to the internet (with IP masqerading).

A feature that does not work is the battlecom communication. 
Is there an ip_masq module available for this (like e.g. 
ipv4/ip_masq_cuseeme.o or ipv4/ip_masq_quake.o) or is anybody
working on this?

Regards,
Gerry

-- 
Gerhard Füllgrabe Phone: +49.5323.96788   Fax: 962044
Arnikaweg 34  Mobile: +49.170.3508588
D-38678 Clausthal-Zellerfeld E-mail: [EMAIL PROTECTED]

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

Re: trouble with apm on dell latitude cs in 2.2.1[67]

[Joshua Jore]

I seem to recall there is mention of this in the recent pcmcia-cs
sources. This requires playing with hdparm if I remember correctly.

Josh

On Tue, 31 Oct 2000 [EMAIL PROTECTED] wrote:

> 
>  I've recently upgraded a latitude cs running redhat 6.2 on 2.2.14 with
>  card services v3.1.14 to 2.2.17 with card services v3.1.21. Immediately
>  I noticed that suspend/resume was broken. Well, suspend was working fine
>  but when I raised the lid, the system would come back like normal, then
>  the HD drive light would go solid and a few seconds later the system
>  would lock hard. No oops or any other indicators. I tried tailing the
>  /var/log/messages file (starting before the suspend), but this revealed
>  nothing at first. After about 5 tries I managed to elicit one error
>  in the log:
> 
>  "hda: timeout waiting for DMA"
> 
>  but this message did not show up consistently. I tried backing down to
>  2.2.16 in case it was a recent bug and then also tried backing up to a
>  previous version of card services, but none of this helps. Unless I go
>  back to 2.2.14, this system will lock hard on a resume about 7-10 seconds
>  after I raise the lid.
> 
>  Lacking any other kernel debugging skills, I compiled sysrq into the kernel
>  hoping to get something more useful for the list. Although 'showkey -s'
>  does generate 0x54 codes, pressing alt-sysrq- yields nothing in the
>  kernel I just built it into (2.2.17). 
> 
>  One another kernel note, I cannot get the 2.4.0-test9/10 kernels to boot
>  on this machine. After lilo, it says:
> 
>  "Uncompressing Linux... Ok, booting the kernel."
> 
>  then the machine hangs solid. It is not recoverable via alt-ctrl-del.
>  I have to hold the power button until the machine cycles. I have no data
>  for earlier 2.4.0 kernels.
> 
>  What else can I do to debug this and what other info will help in
>  identifying the problem?
> 
>  Thanks,
> 
>  Stewart
> 
> -
> To unsubscribe from this list: send 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/

test10-pre7 compile error in ip_forward.c

[Decklin Foster]

I'm getting this when I try to compile test10-pre7:

make[3]: Entering directory `/home/decklin/src/kernel/linux/net/ipv4'
gcc -D__KERNEL__ -I/home/decklin/src/kernel/linux/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686-c -o route.o route.c
gcc -D__KERNEL__ -I/home/decklin/src/kernel/linux/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686-c -o ip_forward.o ip_forward.c
ip_forward.c: In function `ip_forward':
ip_forward.c:139: `NET_RX_BAD' undeclared (first use in this function)
ip_forward.c:139: (Each undeclared identifier is reported only once
ip_forward.c:139: for each function it appears in.)
make[3]: *** [ip_forward.o] Error 1

-- 
There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There
are no ABSOLUTE STATEMENTS. I'm very probably wrong. -- BSD fortune(6)
-
To unsubscribe from this list: send 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: / on ramfs, possible? [yes! - patch included]

[Matt Yourst]

Hi,

I read your post and I think I have just what you're looking for. I've
attached a patch that allows you to mount root as ramfs and populate
it directly from a tar archive (specified just like an initrd image,
but without having to deal with a fixed-size initrd or pivot_root at
all.) This was based on some earlier work from the Linux router
project that I rewrote and ported to 2.2 and 2.4 a few months ago. I
didn't post it to the list since I figured it was too late for 2.4.0,
but if you're interested, here it is.

Here's the Configure.help description:

CONFIG_RAMFS_ROOT
  Allow the kernel to mount a ramfs namespace as the root filesystem
  or as a pre-root filesystem for running a /linuxrc script (similar
  to how initial RAM disk (initrd) support works.)
 
  Since ramfs has no physical or virtual block device to provide its
  data as an initrd image would, you must provide a standard tar
format
  archive to be extracted into the empty ramfs root filesystem.
Currently
  this tar archive may *not* be compressed (i.e., tar.gz style); if
  compression is desired, use a bootloader with automatic gunzip
support
  such as GRUB.
 
  To specify the tar archive used to build the root filesystem, use
the
  initrd= kernel command line option (except with a tar
archive
  instead of a real ext2/minix/romfs filesystem image.)
 
  To mount the tar archive as the actual root filesystem, specify the
  same initrd= option above and also include
"root=/dev/ramfs"
  in the kernel command line.
 
  You may enable both this option and initrd support; however, if a
  tar archive is detected instead of an initrd-supported filesystem
  image, this option will override initrd support.
 
  Note: Some versions of GNU tar create invalid archives that cannot
  be extracted by the kernel. In particular, tar may add a file to an
  archive without previously adding its containing directory. If your
  ramfs archive does not mount correctly because of this, try creating
  it in another way or with another file order.

(Patch should apply to 2.4.0-test10-pre6 on i386. It needs to be
updated for other architectures, mostly in setup.c though.) 

I hope this is helpful. Maybe the maintainers would like to comment on
this too (i.e., might it be considered for 2.4.1, etc.?)

- Matt Yourst

-
 Matt T. YourstMassachusetts Institute of Technology
 [EMAIL PROTECTED] 617.225.7690
 513 French House - 476 Memorial Drive - Cambridge, MA 02136
-
 linux-ramfs-tar-root.diff

Re: test10-pre7

[Linus Torvalds]

On Tue, 31 Oct 2000, Keith Owens wrote:
> 
> You will compile all export objects, whether they are configured or
> not.  The "obvious" fix does not work.
> 
>   MIX_OBJS:= $(filter $(export-objs),$(obj-y) $(obj-m))
> 
> export_objs contains usb.o, obj-y contains usb_core.o, it does not
> contain usb.o.  Multi lists in obj-y and obj-m need to be expanded
> while preserving the required link order (which is where we came in).

No. We can expand multi-lists at ANY OTHER POINT than O_OBJS. That's ok.
It's only O_OBJS that has any ordering issues.

And we just shouldn't use OX_OBJS at all, as that breaks ordering _and_
can be done equally well with MIX_OBJS instead.

> It still does not document the only real link order constraint in USB.
> The almost complete lack of documentation on which link orders are
> required and which are historical is extremely annoying and _must_ be
> fixed, instead we just propagate the problem.

We can add a comment to the Makefile. That's trivial.

What's not trivial, and what I WANT DONE is to make sure that _when_
somebody wants to maintain link ordering, he can do so in an easy and
obvious way. Not with Yet Another Hack.

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: test10-pre7

[Linus Torvalds]

On Tue, 31 Oct 2000, Christoph Hellwig wrote:
> > newstyle rule to something very simple:
> > 
> > # Translate to Rules.make lists.
> > 
> > O_OBJS  := $(obj-y)
> > M_OBJS  := $(obj-m)
> 
> This will destroy one nice feature of list-style makefiles:
> when you have and object both in obj-y and obj-m it will be removed
> from obj-m with the old boiler-plates, not with your proposal.

Ok. That's fine, the "obj-m" thing doesn't have any ordering constraints,
so we can do whatever we want to it. Including the $(filter-out ..) thing.

> > MIX_OBJS:= $(export-objs)
> 
> The MIX_OBJS change is wrong.  It may not hurt the resulting
> kernel image but you will build all export-objs, not only the
> ones you actually have selected.  But we might get around this
> with some $(filter ...) magic.

Yes. That's fine, again MIX_OBJS does not care about ordering, so
filtering etc is fine here.

The only thing I really care about is O_OBJS = $(obj-y), and with this
setup it seems to be a valid thing to do, with some slight hackery on the
other ones.

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: 2.2.X patch query

[Horst von Brand]

Riley Williams <[EMAIL PROTECTED]> said:

[...]

> Before I go any further with this, I would like to ask a few questions
> relating to it:
> 
>  1. Is there any likelihood of this making it into the official
> kernel, or am I just wasting my time?

Depends, I'd say... perhaps after a long shakeout and much use.

>  2. Would I be right in thinking it's too late for either the
> 2.2 or 2.4 kernels ???

No way.

> Assuming it'd be of interest to Linus and yourself...

[...]

>  5. I was wondering about providing some means of selecting
> whether to dump to /dev/fd0 or /dev/fd1 (or others if
> present). What would be your opinion on this?

Keep it as simple as possible. I'd leave the option open if not hard, but
not implement it at all at first.

>  6. A while back, I developed a high-level floppy formatter
> that produces a non-standard DOS-compatible format that
> allows 1436k of data on a 1440k floppy, and produced a
> bash script that would produce disks formatted in this
> format.
> 
> My current plans are for SYSRQ-D to raw write direct to
> /dev/fd0 and effectively reformat the disks in this
> format, dropping the log file thereon in the process. I
> don't plan on doing the low-level format, just the
> high-level one.

KISS, again. What use is a non-standard 1436Kb DOS format when writing at
most 1Mb? I'd just dump it raw to /dev/fd0, whoever wants to read it later
will have all kinds of tools at hand.

Remember:

- Bloat
- This will have to work even in a thoroughly hosed system to be of any use
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] kiobuf/rawio fixes for 2.4.0-test10-pre6

[Andrea Arcangeli]

On Mon, Oct 30, 2000 at 12:45:13PM +0100, Christoph Hellwig wrote:
> @@ -393,10 +396,15 @@
>   pmd = pmd_offset(pgd, address);
>   if (pmd) {
>   pte_t * pte = pte_offset(pmd, address);
> - if (pte && pte_present(*pte))
> + if (pte && pte_present(*pte)) {
> + if (writeacc && !pte_write(*pte))
> + goto retry;
>   return pte_page(*pte);
> + }
>   }

It should also make sure the pte is dirty before starting the read-from-disk
I/O and then things will currently break in the swapout because the page is not
locked (see discussion of last week). The fix for that problem proposed by SCT
and Linus is that the page (not pte) will be marked dirty during swapout and
written back to disk _only_ once reference count is 1 (btw I now noticed
invalidate_inode_pages+MAP_SHARED will mess with that fix and it will trigger a
BUG() in free_pages).

> +
> +faultin:
>   if (handle_mm_fault(current->mm, vma, ptr, datain) <= 0) 
>   goto out_unlock;
>   spin_lock(&mm->page_table_lock);
> - map = follow_page(ptr);
> - if (!map) {
> + map = follow_page(ptr, datain, &failed);
> + if (failed) {
> + /*
> +  * Page got stolen before we could lock it down.
> +  * Retry.
> +  */
>   spin_unlock(&mm->page_table_lock);
> - dprintk (KERN_ERR "Missing page in map_user_kiobuf\n");
> - goto out_unlock;
> + goto faultin;

This is suboptimal (walks the pagetables twice if the page is just mapped). It
should be a follow page first and handle_mm_fault only if follow page failed.

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: test10-pre7

[Keith Owens]

On Tue, 31 Oct 2000 12:49:12 +1100, 
Keith Owens <[EMAIL PROTECTED]> wrote:
>You will compile all export objects, whether they are configured or
>not.  The "obvious" fix does not work.
>
>   MIX_OBJS:= $(filter $(export-objs),$(obj-y) $(obj-m))
>
>export_objs contains usb.o, obj-y contains usb_core.o, it does not
>contain usb.o.  Multi lists in obj-y and obj-m need to be expanded
>while preserving the required link order.

Correction to my own mail.  Multi lists in obj-y and obj-m just need to
be expanded, the order does not matter in MIX_OBJS.

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

Re: test10-pre7

[Keith Owens]

On Mon, 30 Oct 2000 16:47:15 -0800 (PST), 
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>Actually, I think I have an even simpler solution, which is to change the
>newstyle rule to something very simple:
>
>   # Translate to Rules.make lists.
>
>   O_OBJS  := $(obj-y)
>   M_OBJS  := $(obj-m)
>   MIX_OBJS:= $(export-objs)

It makes kbuild variables in USB mean something different from the rest
of the kernel.  Unless you plan to change all Makefiles (code freeze,
what code freeze?).

make modules depends on MIX_OBJS, with the above change make modules
now depends on kernel objects.  Can be fixed in Rules.make, but only if
every Makefile is changed (code freeze, what code freeze?).

You will compile all export objects, whether they are configured or
not.  The "obvious" fix does not work.

MIX_OBJS:= $(filter $(export-objs),$(obj-y) $(obj-m))

export_objs contains usb.o, obj-y contains usb_core.o, it does not
contain usb.o.  Multi lists in obj-y and obj-m need to be expanded
while preserving the required link order (which is where we came in).

It still does not document the only real link order constraint in USB.
The almost complete lack of documentation on which link orders are
required and which are historical is extremely annoying and _must_ be
fixed, instead we just propagate the problem.

If you cannot do sort then you cannot (easily) remove duplicate objects
from the lists, resulting in make warning messages.  Doing an explicit
link first, list last then sort the rest also fixes the problem of
duplicate objects.

-
To unsubscribe from this list: send 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.17, Promise FastTrak66/PDC20262, ugly patches to enable second interface

[Zygo Blaxell]

I started with this:

Software:

Linux 2.2.17
Unified IDE 6.30 (ide.2.2.17.all.2904.patch.bz2)
Linux raid 0.90 (raid-2.2.17-A0)

Hardware:

Dual PIII-550
2 x PIIX4 IDE interfaces on motherboard
2 x Promise FastTrak 66 (PDC20262) in PCI slots

.config and dmesg available on request.

I could not get the second IDE interface on two Promise FastTrak66
(PDC20262, (C) 1998, BIOS revision 1.30) controllers to work until I
applied the following patch:

--- drivers/block/ide-pci.c Mon Oct 23 17:45:39 2000
+++ /tmp/kludgedMon Oct 30 18:31:47 2000
@@ -562,8 +562,6 @@
for (port = 0; port <= 1; ++port) {
unsigned long base = 0, ctl = 0;
ide_pci_enablebit_t *e = &(d->enablebits[port]);
-   if (e->reg && (pci_read_config_byte(dev, e->reg, &tmp) || (tmp & 
e->mask) != e->val))
-   continue;   /* port not enabled */
if (IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT366) && (port) && (class_rev < 
0x03))
return;
if ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE || (dev->class & (port 
? 4 : 1)) != 0) {

This made the second IDE interface on both Promise cards work.  

Am I missing something?  

The patch disregards the enabled flag on the Promise card's second
IDE interface.  Any idea why is that interface is not marked enabled?
More importantly, why is it not enabled on my cards, but apparently
enabled on all of the PDC20262 cards previously mentioned in lkml?

The second IDE on these cards certainly seems to be enabled, because
it's operating in UDMA66 mode through a raid5 sync, lots of md5summing,
and a bonnie or two:

  ---Sequential Output ---Sequential Input-- --Random--
  -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
raid5x5  1536  7465 98.3 29956 35.1 16710 40.1  8575 96.5 50594 35.6 251.4  2.6

-- 
Zygo Blaxell (Laptop) <[EMAIL PROTECTED]>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: request advice: how stable is devfs in 2.4.0-test9?

[Jeff Dike]

[EMAIL PROTECTED] said:
> I am currently using 2.4.0-test* as an "ordinary user" and want to try
> some  of the 2.4 specific new features out, but this is my only system
> and I don't  want it to be messed up so much, so I'd like to hear some
> comments first.

This is one of the things that user-mode Linux (http://user-mode-linux.sourcefo
rge.net) is for.  I've been shipping kernels with devfs since devfs made it 
into the mainline pool.

With UML, you can boot up a virtual machine, and play with devfs all you want 
without any chance of messing up the host.

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: hard_sector / hard_nr_sectors

[Andrea Arcangeli]

On Mon, Oct 30, 2000 at 10:56:39AM -0800, Al Peat wrote:
>   I was wondering if someone could give me a quick
> overview of the differences between sector/nr_sectors
> and hard_sector/hard_nr_sectors in blk_dev.h's request
> structure, or point me to some
> documentation/discussion on this?

The reason hard_nr_sectors is been introduced is that it allows all device
drivers to handle merged I/O requests transparently. In 2.4.x we do merging at
the highlevel layer unconditionally and so it was necessary to avoid breakage
of lowlevel drivers.

This way device drivers can limit themself to look at
current_request->buffer/current_nr_sectors/sector... and to call end_request(1)
once the I/O is completed (end_that_request_first will take care of updating
current->sector/nr_sector for the next pass of the request_fn without the need
of ugly changes to the lowlevel drivers).

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: test10-pre7

[Christoph Hellwig]

On Mon, Oct 30, 2000 at 06:52:08PM -0600, Michael Elizabeth Chastain wrote:
> Let me see if I have all this straight:
> 
> (1) Change Rules.make to use "new style" variables as its native form.
> (1A) Add a "Compat.make" for old style Makefiles, and
> (1B) Continue to convert all the remaining old style Makefiles.

This is difficult because old-style makefiles can do much more magic
then list-style ones.  But after a bit more thinking it looks like is
is possible ... (yeah I said otherwise some time ago).

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Christoph Hellwig]

On Mon, Oct 30, 2000 at 04:47:15PM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 31 Oct 2000, Christoph Hellwig wrote:
> >
> > Old-style Makefiles are playing dirty tricks with defining
> > L_TARGET and then using O_TARGET for linking some onjects into
> > an intermediate object.
> 
> Actually, I think I have an even simpler solution, which is to change the
> newstyle rule to something very simple:
> 
>   # Translate to Rules.make lists.
> 
>   O_OBJS  := $(obj-y)
>   M_OBJS  := $(obj-m)

This will destroy one nice feature of list-style makefiles:
when you have and object both in obj-y and obj-m it will be removed
from obj-m with the old boiler-plates, not with your proposal.

>   MIX_OBJS:= $(export-objs)

The MIX_OBJS change is wrong.  It may not hurt the resulting
kernel image but you will build all export-objs, not only the
ones you actually have selected.  But we might get around this
with some $(filter ...) magic.


>   # The global Rules.make.
> 
>   include $(TOPDIR)/Rules.make
> 
> And you're done..
> 
> Does anybody see anything wrong with this approach?
> 
> It's kin dof cheesy, but I think it should work. The magic is that by
> avoiding OX_OBJS and MX_OBJS, we avoid all the sorting issues. We
> basically lie, and say that we don't have anything like that.
> 
> Then, MIX_OBJS picks up the stragglers, and makes sure that we consider
> the proper files to be SYMTAB_OBJS.
> 
> This works for me for USB (ie just remove all the stuff with "int-y" and
> multi's etc). Does it work for anybody else?

The idea looks great, but it looks like the implementation needs a little
bit work.

Keith do you want to hack on this now - or should I prepare a patch tomorrow?

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Michael Elizabeth Chastain]

Let me see if I have all this straight:

(1) Change Rules.make to use "new style" variables as its native form.
(1A) Add a "Compat.make" for old style Makefiles, and
(1B) Continue to convert all the remaining old style Makefiles.

(2) Go with the "export-objs" style of declaring source files that need
to be run through genksyms.  Files never get built just because they
are in $(export-objs); $(export-objs) just determines who gets
processed by genksyms at compile time.

(3) No LINK_FIRST / LINK_LAST.  Whatever is in the Makefile gets linked
in that order.  We won't use $(sort ...) to eliminate duplicates
(we will continue to handle them another way).

(4) When a multi is built into the resident kernel, the whole multi goes in,
with no splitting into component parts.

Is that your plan, Linus?

I disagree with (3) because I think that initialization order requirements
should be spelled out and documented.  But I accept it.

Historical note on (4): as Keith said, I had to split up the multi's in
order to get the components into the OX_OBJS list.  But with a more
thorough implementation of (2), this becomes unnecessary.

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

Re: test10-pre7

[Linus Torvalds]

On Tue, 31 Oct 2000, Christoph Hellwig wrote:
>
> Old-style Makefiles are playing dirty tricks with defining
> L_TARGET and then using O_TARGET for linking some onjects into
> an intermediate object.

Actually, I think I have an even simpler solution, which is to change the
newstyle rule to something very simple:

# Translate to Rules.make lists.

O_OBJS  := $(obj-y)
M_OBJS  := $(obj-m)
MIX_OBJS:= $(export-objs)

# The global Rules.make.

include $(TOPDIR)/Rules.make

And you're done..

Does anybody see anything wrong with this approach?

It's kin dof cheesy, but I think it should work. The magic is that by
avoiding OX_OBJS and MX_OBJS, we avoid all the sorting issues. We
basically lie, and say that we don't have anything like that.

Then, MIX_OBJS picks up the stragglers, and makes sure that we consider
the proper files to be SYMTAB_OBJS.

This works for me for USB (ie just remove all the stuff with "int-y" and
multi's etc). Does it work for anybody else?

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: Blocked processes <=> Elevator starvation?

[Miles Lane]

Jens Axboe wrote:

> On Sun, Oct 29 2000, Miles Lane wrote:
> 
 There were still some stalls but they only lasted a couple of
 seconds. The patch did make a difference and for the better.
>>> 
>>> 
>>> Ok, still needs a bit of work. Thanks for the feedback.
>> 
>> Have you resolved this problem completely, now?
>> 
>> I am testing the USB Storage support with my ORB backup
>> drive.  When I run:
>> 
>>  dd if=/dev/zero of=/dev/sda bs=1k count=2G
>> 
>> The drive gets data quickly for about thirty seconds.
>> Then the throughput drops off to about ten percent
>> of its previous transfer rate.  This dropoff appears to
>> be due to conflict over accessing filesystems.  Specifically,
>> I have USB_STORAGE_DEBUG enabled, which shoots a ton of
>> debugging output into my kernel log.  When the throughput
>> to the ORB drive falls off, all writing to the syslog
>> ceases.  At least, that's what "tail -f" shows.
>> 
>> I would be happy to test any patches you have for this
>> problem.
> 
> 
> Could you send vmstat 1 info from the start of the copy
> and until the i/o rate drops off?

I just reproduced the problem in test10-pre7.  Here's the
output you requested:

vmstat 1
procs  memoryswap  io system cpu
  r  b  w   swpd   free   buff  cache  si  sobibo   incs  us  sy  id
  1  0  0  0 126308   5724  59480   0   023 9  162   306   6   2  92
  0  0  0  0 126292   5724  59480   0   0 0 0  297   786   4   4  92
  0  0  0  0 126292   5724  59480   0   0 0 0  210   593   2   1  97
  1  2  2  0  59768  64308  59508   0   0 0 17425  950 37095  11  66  23
  0  2  3  0  59460  64580  59508   0   0 0   645  317  1169   0   1  99
  0  2  2  0  58672  65272  59508   0   0 0   657  293  1928   0   2  98
  0  2  2  0  58272  65628  59508   0   0 0   647  283  1228   1   0  99
  0  2  2  0  57868  65984  59508   0   0 0   647  284  1230   0   4  96
  0  2  2  0  57464  66340  59508   0   0 0   648  284  1221   0   0 100
  1  2  2  0  56600  67100  59512   0   0 0   662  295  2062   0   0 100
  0  2  2  0  56192  67460  59512   0   0 0   522  285  1237   0   1  99
  0  2  2  0  55888  67728  59512   0   0 0   644  282  1040   0   1  99
  0  2  2  0  55484  68084  59512   0   0 0   646  285  1227   0   1  99
  0  2  2  0  54648  68820  59512   0   0 0   661  299  2019   0   2  98
  1  2  2  0  54240  69176  59512   0   0 0   648  406  1549   1   3  96
  1  2  2  0  53824  69532  59512   0   0 0   649  637  2073   6   1  93
  0  2  2  0  53424  69884  59516   0   0 0   649  466  1705   2   1  97
  2  2  2  0  52172  70380  59516   0   0 0   656 1011  3612  14   4  82
  3  2  2  0  51728  70716  59516   0   0 0   647 1994  2329   9   6  85
  1  2  2  0  51312  71064  59516   0   0 0   636 1883  1517  12   9  79
  2  2  2  0  50972  71420  59516   0   0 0   636 1092  1541  12   0  88
  0  2  2  0  50100  72176  59520   0   0 0   671  611  2266  19   6  75
  1  2  2  0  49692  72532  59520   0   0 0   638  305   682   1   1  98
  1  2  2  0  49292  72888  59520   0   0 0   650  368  1574   0   1  99
  0  2  2  0  48580  73516  59520   0   0 0   638  289   613   0   5  95
  1  2  2  0  48180  73868  59520   0   0 0   636  278   542   1   0  99
  0  2  2  0  47776  74224  59520   0   0 0   637  285   595   0   0 100
  0  2  2  0  47372  74580  59520   0   0 0   636  274   513   0   8  92
  0  2  2  0  46572  75288  59520   0   0 0   638  273   525   0   1  99
  0  2  2  0  46168  75644  59520   0   0 0   637  281   588   0   2  98
  0  2  2  0  45764  76000  59520   0   0 0   509  272   508   0   0 100
  0  2  2  0  45300  76324  59520   0   0 0   636  276   548   1   0  99
  0  2  2  0  44896  76680  59520   0   0 0   636  273   523   0   0 100
  0  2  2  0  44088  77392  59520   0   0 0   650  281  1307   0   7  93
  1  1  2  0  43736  77680  59548   0   0 0  1279  908  2637   1   8  91
  0  2  3  0  43072  78040  59592   0   0 0  1660 1281  4119   5   6  89

 >>> /var/log/kernel output stopped being emitted here <<<
 >>>  CRUNCH!  <<<

  0  2  3  0  42656  78384  59592   0   0 0   259  271   551   0   0 100
  0  2  3  0  42656  78384  59592   0   0 0 5  271   499   0   0 100
  0  2  3  0  42656  78384  59592   0   0 0 5  272   511   0   2  98
  0  2  3  0  42656  78384  59592   0   0 0 4  268   502   0   0 100
  0  2  3  0  42656  78384  59592   0   0 0 5  272   508   0   0 100
  0  2  3  0  42656  78384  59592   0   0 0 5  274   523   0   0 100
  0  2  3  0  42656  78384  59592   0   0 0 5  274   508   0   0 100
procs  memoryswap  io system cp

kernel.org cryptographic software policy change

[H. Peter Anvin]

Hi everyone,

The U.S. government further liberalized the handling of cryptographic
Open Source software in the new crypto regulations dated 2000-10-19.  As
a result, I have consulted with our lawyer and we no longer feel that it
is necessary to require that object code be derived from source code only
available on kernel.org; as long as it is available for free.

Thus, the new kernel.org policy on cryptographic software is:

Cryptographic software may only be uploaded if it is Open Source; and, if
binary, the source code is available on for free via the Internet.

The legal notice w.r.t. encryption software is revised to read as
follows:

This site includes publicly available encryption source code which,
together with object code resulting from the compiling of publicly
available
source code, may be exported from the United States under License
Exception
"TSU" pursuant to 15 CFR Section 740.13(e).

This change is effective immediately.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.4.0-test10-pre6 TLB flush race in establish_pte

[Andrea Arcangeli]

On Mon, Oct 30, 2000 at 03:31:22PM -0600, Steve Pratt/Austin/IBM wrote:
> [..] no patch ever
> appeared. [..]

You didn't followed l-k closely enough as the strict fix was submitted two
times but it got not merged. (maybe because it had an #ifdef __s390__ that was
_necessary_ by that time?)

You can find the old and now useless patch here:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test5/tlb-flush-smp-race-1

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: test10-pre7

[Keith Owens]

On Mon, 30 Oct 2000 15:47:59 -0800 (PST), 
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>On Tue, 31 Oct 2000, Keith Owens wrote:
>We should have some REALLY simple and to-the-point rules. Namely:
>
> - object files get linked in the order specified
>
>No ifs, buts, "except when the user doesn't care", or anything like that.
>No extra new logic with fancy new names for FIRST and LAST objects. No,
>that's the wrong thing.

It is the right thing because it self documents which objects really
need a link order and why.  The existing mechanism has demonstrably
failed to do this, resulting in fragile and error prone makefiles.

>The two things are entirely orthogonal, as far as I can see. Except
>historically we've mixed them up (OX_OBJS + O_OBJS is the link-list,
>O_OBJS is the symtab information). And this mixup is what the problems
>come from.

True, which is one of the reasons that kbuild 2.5 will remove OX_OBJS,
MX_OBJS and MIX_OBJS.  But that change affects all Makefiles, we are
supposed to be in a code freeze.  My patch fixes usb and only affects
usb, not the entire kernel.

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

Re: test10-pre7

[Christoph Hellwig]

On Mon, Oct 30, 2000 at 03:51:53PM -0800, Linus Torvalds wrote:
> I hate your patch.
> 
> I'd rather see "Rules.make" just base itself entirely off the new-style
> Makefiles, and have it use "$(obj-y)" instead of O_OBJS etc.
> 
> Then, _old_style Makefiles could be fixed up by doing a
> 
>   include Compat.make

That can't be done.
Old-style Makefiles are playing dirty tricks with defining
L_TARGET and then using O_TARGET for linking some onjects into
an intermediate object.

But the patch I have proposed is _not_ a resend of that old patch.
Instead this is a separate Makefile.inc that does not include the
old Rules.make - because it needs to do the different handling of
symtab objects - and btw it gets simpler because much of the Rule.make
logic is similar to the list-style makefiles.

So Rule.make would only be for the old-style Makefiles that should be
killed as fast as possible.

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send 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.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

David/Alan,

Andre Hedrick is now the CTO of TRG and Chief Scientist over Linux
Development.  After talking 
to him, we are going to do our own ring 0 2.4 and 2.2.x code bases for
the MANOS merge.  
the uClinux is interesting, but I agree is limited.  

MANOS schedules should be unaffected.  The current DLL prototype of
Linux 2.2 is ring 0, but I shudder at trying to merge all the changes
I've done to it into core 2.2.X as a .config
option.  There's also the gravity well forces of different views to this
effort.  With Andre 
on the job, I am more confident in co-opting the Linux drivers and just
biting the bullet 
on the support issues, and doing a full fork of Linux.

Jeff

David Woodhouse wrote:
> 
> On Mon, 30 Oct 2000, Ingo Molnar wrote:
> 
> > On Mon, 30 Oct 2000, Jeff V. Merkey wrote:
> >
> > > Is there an option to map Linux into a flat address space [...]
> >
> > nope, Linux is fundamentally multitasked.
> 
> uClinux may be able to do this, at the cost of a dramatically reduced
> userspace functionality.
> 
> --
> dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Linus Torvalds]

On Tue, 31 Oct 2000, Christoph Hellwig wrote:
> 
> But when we are changing makefiles everywhere - why not do the proper think
> and let the new-style makefiles share their code?
> 
> (I have a patch ready - it just needs some forward-porting and testing)

I hate your patch.

I'd rather see "Rules.make" just base itself entirely off the new-style
Makefiles, and have it use "$(obj-y)" instead of O_OBJS etc.

Then, _old_style Makefiles could be fixed up by doing a

include Compat.make

or preferably by just fixing them. I don't want to have another
Rules.make. I want to fix the old users.

(Compat.make would then look like

obj-y = $(OX_OBJS) $(O_OBJS)
export-objs = $(OX_OBJS)
...

and make _old_ Makefiles look like new ones as far as Rules.make is
concerned.

See? 

This is the same as with source code. I do NOT want to have backwards
compatibility in source code - if compatibility is needed, I'd much rather
have it be _forwards_ compatibility, where the old setup is made to look
like the new with wrapper functions etc.

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: test10-pre7

[Linus Torvalds]

On Tue, 31 Oct 2000, Keith Owens wrote:
> 
> >It is NEVER acceptable to change the order of object files.
> 
> It is NEVER acceptable to change the order of object files, but only
> for those files where the developer has explicitly said what the order
> must be.  In the case of USB, the developers say usb.o must be first,
> the rest can be in any order.

How much do you want to bet that this can and will change if people were
made aware of how easy ordering can be?

I think we have too many "subtle" rules already.

We should have some REALLY simple and to-the-point rules. Namely:

 - object files get linked in the order specified

No ifs, buts, "except when the user doesn't care", or anything like that.
No extra new logic with fancy new names for FIRST and LAST objects. No,
that's the wrong thing.

> > ALL_O = $(O_OBJS)
> >
> >and the meaning of $OX_OBJS is the _subset_ of object file that have
> >SYMTAB objects.
> 
> We do not have an automatic way of detecting SYMTAB objects, OX_OBJS is
> the only way that 2.4 kbuild can tell if an source has SYMTAB or not.

I _know_.

I'm saying that we should not care. OX_OBJS still exists, but it has
nothing to do with _linking_. It has everything to do with the build
rules.

OX_OBJS is just a list of files that have exports.

It won't affect linking. It will only affect the list of SYMTAB_OBJS,
_nothing_ more.

For example, the old-style kernel/Makefile, you'd have O_OBJS containing
signal.o and sys.o. As would OX_OBJS. They'd be in both places, because
O_OBJS would tell that yes, we want to link it into the kernel, and
OX_OBJS would tell that yes, we need to generate symtab informaiton for
the files in question.

The two things are entirely orthogonal, as far as I can see. Except
historically we've mixed them up (OX_OBJS + O_OBJS is the link-list,
O_OBJS is the symtab information). And this mixup is what the problems
come from.

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: test10-pre7

[Christoph Hellwig]

On Mon, Oct 30, 2000 at 03:40:24PM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 31 Oct 2000, Christoph Hellwig wrote:
> > 
> > It is simple - but a change in _every_ makefile is required.
> > And it is not really needed for old-style makefiles.
> 
> Actually, you don't have to change every makefile, because you CAN do this
> all with a simple backwards-compatibility layer, something like:
> 
>   OXONLY = $(filter-out $(O_OBJS), $(OX_OBJS))
>   ALL_O = $(OXONLY) $(O_OBJS)
> 
> which is a no-op for a "proper" makefile that follows the new rules
> (OXONLY will be empty, because all OX_OBJS files will be part of O_OBJS),
> but it will make old-style stuff act the same..

Ok, that should do the job - but it is horribly ugly ...

> I'd actually prefer to just change every Makefile, but hey, I think
> something like the above (untested) would make them work unmodified too.

But when we are changing makefiles everywhere - why not do the proper think
and let the new-style makefiles share their code?

(I have a patch ready - it just needs some forward-porting and testing)

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Linus Torvalds]

On Tue, 31 Oct 2000, Christoph Hellwig wrote:
> 
> It is simple - but a change in _every_ makefile is required.
> And it is not really needed for old-style makefiles.

Actually, you don't have to change every makefile, because you CAN do this
all with a simple backwards-compatibility layer, something like:

OXONLY = $(filter-out $(O_OBJS), $(OX_OBJS))
ALL_O = $(OXONLY) $(O_OBJS)

which is a no-op for a "proper" makefile that follows the new rules
(OXONLY will be empty, because all OX_OBJS files will be part of O_OBJS),
but it will make old-style stuff act the same..

I'd actually prefer to just change every Makefile, but hey, I think
something like the above (untested) would make them work unmodified too.

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: Update: SMP 2.2.15 #2 kernel, lock ups...

[Alan Cox]

> Ugh, I had nothing but disaster  First, the kernel would not
> auto-recognize I had 1 gig of memory... it would only boot saying I had 64

BIOS error. Ask the vendor to fix E801 sizing. Could be your old kernels had
the hack to try E820 (windows uses this so the BIOS writing morons have to
get it right) [sorry the quality of BIOS QA is on my rant list, it appears to
be 'boot windows and ship']

> meg.  So I added the MEM=1024M line to the lilo config (I believe that is
> the correct line, don't have it in front of me).  Whenever I booted the

Chances are its not 1024 that is available. It'll only use about 900Mb with
a 1Gig sized kernel anyway. Try 900Mb just for now

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/

Re: test10-pre7

[Keith Owens]

On Mon, 30 Oct 2000 15:15:57 -0800 (PST), 
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>I'm saying that EVERYTHING should be order-critical.

We (almost) agree about that, we are arguing about implementation
details.  The existing implementation relies on the order that objects
are declared.  In almost all cases there are no documented reasons for
the existing order, people who know about the link order problems are
scared to change declaration orders.  OTOH, relying on declaration
order is error prone, people who do not know about the side effects of
declaration order try to change it and sometimes it works, sometimes it
breaks.

kbuild 2.5 splits link order into three categories.  Those that must
come first, in the order they are specified - LINK_FIRST.  Those that
must come last, in the order they are specified - LINK_LAST.
Everything else, in no defined order.  This solves the documentation
problem, use of LINK_FIRST and LINK_LAST is explicit and the reasons
for the order will be documented, or else!  Declaration order is then
irrelevant, it can be any order that makes sense to the developers.
The end effect if the same, LINK_FIRST/LAST is a better implementation.

>It is NEVER acceptable to change the order of object files.

It is NEVER acceptable to change the order of object files, but only
for those files where the developer has explicitly said what the order
must be.  In the case of USB, the developers say usb.o must be first,
the rest can be in any order.

>Then we change the meaning of OX_OBJS, and instead of saying
>
>   ALL_O = $(OX_OBJS) $(O_OBJS)
>
>we just say
>
>   ALL_O = $(O_OBJS)
>
>and the meaning of $OX_OBJS is the _subset_ of object file that have
>SYMTAB objects.

We do not have an automatic way of detecting SYMTAB objects, OX_OBJS is
the only way that 2.4 kbuild can tell if an source has SYMTAB or not.
I could change Rules.make to grep the sources and work out what the
flags should be but that is messy and affects all of 2.4 kbuild.

>This should all work pretty much as-is, with som every simple
>modifications to existing old-style Makefiles, and with some even simpler
>modifications to the new-style ones. In fact, it should remove pretty much
>all the ugly games that new-style files do.

Let me get this straight.  I provide a minimal patch that helps
document link order, is compatible with kbuild 2.5 and only affects
usb.  But you want me to change the meaning of OX_OBJS, add grep to
Rules.make, edit all the old style Makefiles, change all the
bolierplate code in new style makefiles, in short to hit all of 2.4
kbuild.  Why?

>And it should make all this FIRST/LAST object file mockery a total
>non-issue, because the whole concept turns out to be completely
>unnecessary.

Only if you think that documentation is unncessary.

-
To unsubscribe from this list: send 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: / on ramfs, possible?

[Jeff Garzik]

David Woodhouse wrote:
> 
> On Mon, 30 Oct 2000, H. Peter Anvin wrote:
> 
> > Pardon?!  This doesn't make any sense...
> >
> > The question was: how do switch from the initrd to using the ramfs as /?
> > Using pivot_root should do it (after the pivot, you can of course nuke
> > the initrd ramdisk.)
> 
> My question is: What do you want to do that for? You can nuke the initrd
> ramdisk, but you can't drop the rd.c code, or ll_rw_blk.c code, etc. So
> why not just keep your root filesystem in the initrd where it started off?

ramfs size is far more dynamic than rd, and it shrinks as well as grows.

Unless you are creating a lot of temporary files and such, though,
initrd is indeed a much better solution from many perspectives. (IMHO)

Jeff


-- 
Jeff Garzik | "Mind if I drive?"  -Sam
Building 1024   | "Not if you don't mind me clawing at the
MandrakeSoft|  dash and shrieking like a cheerleader."
| -Max
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Christoph Hellwig]

In article <[EMAIL PROTECTED]> you wrote:


> We should just link it in the order specified:

>   ld -r usbdrv.o $(obj-y)
>
> [...]
>
> Then we change the meaning of OX_OBJS, and instead of saying
>
>   ALL_O = $(OX_OBJS) $(O_OBJS)
>
> we just say
>
>   ALL_O = $(O_OBJS)
>
> and the meaning of $OX_OBJS is the _subset_ of object file that have
> SYMTAB objects.
>
> This should all work pretty much as-is, with som every simple
> modifications to existing old-style Makefiles,

It is simple - but a change in _every_ makefile is required.
And it is not really needed for old-style makefiles.

Would you accept a patch that makes the new-styles include
a separated Makefile library (e.g. $(TOPDIR)/Makefile.inc)
and leaves the old-style one as is (in hope of eleminating
them fast)?

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send 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: / on ramfs, possible?

[H. Peter Anvin]

David Woodhouse wrote:
> 
> On Mon, 30 Oct 2000, H. Peter Anvin wrote:
> 
> > Pardon?!  This doesn't make any sense...
> >
> > The question was: how do switch from the initrd to using the ramfs as /?
> > Using pivot_root should do it (after the pivot, you can of course nuke
> > the initrd ramdisk.)
> 
> My question is: What do you want to do that for? You can nuke the initrd
> ramdisk, but you can't drop the rd.c code, or ll_rw_blk.c code, etc. So
> why not just keep your root filesystem in the initrd where it started off?
> 

Umm... because the size of a ramdisk is fixed, but the size of a ramfs is
flexible?

I can certainly understand this problem... I might in fact do exactly
this in the next version of my SuperRescue disk.  There, the ramdisk
which is the real root is populated from a .tar.gz file; the initrd is
just there to unpack the .tar.gz file onto the "real" ramdisk; the initrd
is then jettisoned.

Why not just have the real root be the initrd, you ask?  It's too large:
since an initrd needs to exist in both compressed form and uncompressed
form in memory at the same time; it would mean SuperRescue would no
longer work on systems with 64 MB RAM.  If I went to ramfs it might
actually work on systems with 48 MB RAM, albeit you better not need to
much space in / (or conversely, it would suddenly let you put a whole lot
more stuff in /tmp if you have 512 MB.)

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: /proc & xml data

[Olaf Titz]

> "MemTotal:  %8lu kB\n"
> to something like
> "%8lu kB\n"

The latter form offers no significant advantage over the former at
all - there is nothing that can be expressed as
 value
which can't also be expressed as
 name: value
or
 name=value
and the latter format is significantly easier to parse.

The only situation where XML really would be useful would be
some need of grouping, and this is done in /proc using directories.
(Which are also much easier to parse using existing standard tools.)

Olaf

-
To unsubscribe from this list: send 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: / on ramfs, possible?

[David Woodhouse]

On Mon, 30 Oct 2000, H. Peter Anvin wrote:

> Pardon?!  This doesn't make any sense...
> 
> The question was: how do switch from the initrd to using the ramfs as /? 
> Using pivot_root should do it (after the pivot, you can of course nuke
> the initrd ramdisk.)

My question is: What do you want to do that for? You can nuke the initrd
ramdisk, but you can't drop the rd.c code, or ll_rw_blk.c code, etc. So
why not just keep your root filesystem in the initrd where it started off?

-- 
dwmw2


-
To unsubscribe from this list: send 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.18Pre Lan Performance Rocks!

[David Woodhouse]

On Mon, 30 Oct 2000, Ingo Molnar wrote:

> On Mon, 30 Oct 2000, Jeff V. Merkey wrote:
> 
> > Is there an option to map Linux into a flat address space [...]
> 
> nope, Linux is fundamentally multitasked.

uClinux may be able to do this, at the cost of a dramatically reduced
userspace functionality.

-- 
dwmw2


-
To unsubscribe from this list: send 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: / on ramfs, possible?

[H. Peter Anvin]

David Woodhouse wrote:
> 
> On 29 Oct 2000, H. Peter Anvin wrote:
> 
> > > I want my / to be a ramfs filesystem. I intend to populate it from an
> > > initrd image, and then remount / as the ramfs filesystem. Is that at
> > > all possible? The way I see it the kernel requires / on a device
> > > (major,minor) or nfs.
> > >
> > > Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?
> > >
> >
> > Use pivot_root instead of the initrd stuff in /proc/sys.
> 
> Urgh. Then you're still using an initrd, and you still have to include all
> the crap necessary to support those horrid block-device thingies.
> 
> Why not just use a ramdisk?
> 

Pardon?!  This doesn't make any sense...

The question was: how do switch from the initrd to using the ramfs as /? 
Using pivot_root should do it (after the pivot, you can of course nuke
the initrd ramdisk.)

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Third arg to switch_to()

[Kenn Humborg]

On Mon, Oct 30, 2000 at 07:15:58PM +, I wrote:
> 
> Can anyone point me to an explanation of the third arg to 
> switch_to(prev, next, last)?
> 
> It appeared in 2.2.8.
> 
> What exactly is supposed to be written to it?

Mea culpa...

Further digging revealed that it's for returning prev in the
new task, to deal with the fact that the stack has changed
so local variables in schedule() don't exist anymore.

Later,
Kenn


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

Update: SMP 2.2.15 #2 kernel, lock ups...

[John Babina III]

I spent the entire day working on this problem... as per Alan's
suggestion, I attempted to upgrade to 2.2.17.

Ugh, I had nothing but disaster  First, the kernel would not
auto-recognize I had 1 gig of memory... it would only boot saying I had 64
meg.  So I added the MEM=1024M line to the lilo config (I believe that is
the correct line, don't have it in front of me).  Whenever I booted the
machine under 2.2.17, I would get errors during the boot process... here
is part of one (if you need more details let me know, i had to copy these
down on scrap paper)

Swap_Free trying to free no-existant swap page

Zap_Pte_range: bad pmd (371b10b7)

Unable to handle Kernel Null Ptr deref at virt addr 01a9

then it goes on and finally lists an oops for a process "top100" (it's an
apache process I have running)

The machine has 1 Gig, a Mylex ExtremeRaid 1100, dual 700 mhz pentium
3's.  To refresh, the original problem I had was a lockup every 24-48
hours randomly, with no warning or errors.

As per suggested here (as well as upgrading to .17) I also checked into
bios upgrades for the motherboard -- I found mine was the most current.  I
also checked and upgraded the Mylex bios to the latest version and moved
the cards around to different PCI slots.  As for the lockups, I don't know
If I have resolved them yet or not, but I do know I am having horrible
problems besides the lockups, as per upgrading to .17.

I am starting to wonder if I am having memory problems?  I noticed that
when I was running at 64 megs (by accident, the system was not detecting
my full memory for some reason) the machine seemed to work perfectly, but
once I said MEM=1024, all hell broke loose... thats when I started getting
errors.  One thing that consistently happened with .17 was after I had an
error and had to reboot, FSCK had to run.  FSCK would find all of these
bad time header things and would work at fixing them, then after like 1
minute of crunching it would just lockup, I could hit return on the
keyboard and see a blank line appear on the screen but that was it.  The
drives stopped running and no further processing.  If i kept rebooting,
this occurred over and over.  Once I dropped back to an older kernel (via
a kernel boot disk), the fsck would work perfectly and complete the boot
process... 

Does this sound like a .17 problem or a memory problem or both?  I have
had 4 machines with similar hardware (dual processor, mylex raid cards, 1
gig) and not had any problems like this before. (theo ther machines had
slower processors, or older mylex raid).  I am about to boot this machine
out the door.

Shouldn't my machine be auto-detecting how much memory I have without
using the MEM= line in lilo?.. I believe it had in the past.

I have ordered a new gig of memory overnight so I can drop it in and see
if it resolves the problem(s)... if you need any more info, such as more
details on those errors, etc. please let me know.

Thanks in advance,
-John

-
To unsubscribe from this list: send 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: / on ramfs, possible?

[David Woodhouse]

On 29 Oct 2000, H. Peter Anvin wrote:

> > I want my / to be a ramfs filesystem. I intend to populate it from an 
> > initrd image, and then remount / as the ramfs filesystem. Is that at 
> > all possible? The way I see it the kernel requires / on a device 
> > (major,minor) or nfs.
> > 
> > Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?
> > 
> 
> Use pivot_root instead of the initrd stuff in /proc/sys.

Urgh. Then you're still using an initrd, and you still have to include all
the crap necessary to support those horrid block-device thingies. 

Why not just use a ramdisk?

-- 
dwmw2


-
To unsubscribe from this list: send 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] Re: test10-pre7

[Linus Torvalds]

On Mon, 30 Oct 2000, Alexander Viro wrote:
> 
> Fine with me. Just let's remember that it should be revisited in 2.5.
> What about filemap_swapout()? If you agree with checking ->mapping
> there... looks like we are done with that crap for the time being.

Yup, I agree. I already applied your patch, and did the additional
"mapping" check in nfs_sync_page. We should be ok for now, the only wart
being the fact that sync_page() is ugly.

But better ugly than broken.

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: test10-pre7

[Linus Torvalds]

On Tue, 31 Oct 2000, Keith Owens wrote:
> >
> >What would be wrong with just splitting it the other way, ie make OX_OBJS
> >be the expanded (but not ordered) list?
> >
> >That should take care of it, no?
> 
> usbcore.o is both multi part *and* order critical.  This is a
> combination that the existing "link order relies on declaration order"
> kludge cannot cope with.  It requires an explicit declaration of link
> order, which is exactly what LINK_FIRST implements.

I don't see your point.

I'm saying that EVERYTHING should be order-critical.

It is NEVER acceptable to change the order of object files.

If the Makefile said that the ordering should be

obj-y = usb.o usbcore.o third.o last.o

then the fact that usbcore.o is a multi-part object file SHOULD NOT
MATTER.

We should just link it in the order specified:

ld -r usbdrv.o $(obj-y)

No re-ordering. No expansion of multi-objs. No games. Do what the Makefile
author expected.

In short, we should _remove_ all traces of stuff like

O_OBJS = $(filter-out $(export-objs), $(obj-y))

It's wrong.

We should just have

O_OBJS = $(obj-y)

which is always right.

Then we change the meaning of OX_OBJS, and instead of saying

ALL_O = $(OX_OBJS) $(O_OBJS)

we just say

ALL_O = $(O_OBJS)

and the meaning of $OX_OBJS is the _subset_ of object file that have
SYMTAB objects.

This should all work pretty much as-is, with som every simple
modifications to existing old-style Makefiles, and with some even simpler
modifications to the new-style ones. In fact, it should remove pretty much
all the ugly games that new-style files do.

And it should make all this FIRST/LAST object file mockery a total
non-issue, because the whole concept turns out to be completely
unnecessary.

Is there anything that makes this more complex than what I've outlined
above? 

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: [PATCH] Re: test10-pre7

[Alexander Viro]

On Mon, 30 Oct 2000, Linus Torvalds wrote:

> Ok, sync_page() looks like a broken design, but I suspect that for
> expediency the simplest fix is to just make the NFS sync_page() (re-)check
> for "mapping == NULL", and let it be at that. Avoid the NULL pointer
> dereference (very small window already).

Fine with me. Just let's remember that it should be revisited in 2.5.
What about filemap_swapout()? If you agree with checking ->mapping
there... looks like we are done with that crap for the time being.
If it's OK with you I'll send such patch against vanilla -pre7.
Cheers,
Al

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

Re: test10-pre7

[Linus Torvalds]

On Mon, 30 Oct 2000, Jeff Garzik wrote:
> > 
> > What would be wrong with just splitting it the other way, ie make OX_OBJS
> > be the expanded (but not ordered) list?
> > 
> > That should take care of it, no?
> 
> As an aside:  remember you mentioned we should try to go 100% OX_OBJS
> anyway, eliminating O_OBJS completely...

The only problem is that those unfortunate people without tons of
CPU-power would get really fed up with the extra "made depend" overhead.

So as a less drastic step we should just make it more of a hint, and less
of a design that impacts the link-order..

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: [PATCH] Re: test10-pre7

[Linus Torvalds]

On Mon, 30 Oct 2000, Alexander Viro wrote:
>
> [ sync_page brokenness ]
> 
> To elaborate: the thing is called if we get a contention on the page lock.

Ok, sync_page() looks like a broken design, but I suspect that for
expediency the simplest fix is to just make the NFS sync_page() (re-)check
for "mapping == NULL", and let it be at that. Avoid the NULL pointer
dereference (very small window already).

We should probably in the long run make "page->buffers" be a more generic
thing, and let NFS use it as a wb-info thing, and be done with it. That's
obviously not 2.4.x material, though.

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: test10-pre7

[Keith Owens]

On Mon, 30 Oct 2000 18:02:34 -0500, 
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>As an aside:  remember you mentioned we should try to go 100% OX_OBJS
>anyway, eliminating O_OBJS completely...

That is a global change for 2.5, it would massively break 2.4 kbuild.

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

Re: test10-pre7

[Keith Owens]

On Mon, 30 Oct 2000 14:51:25 -0800 (PST), 
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>On Tue, 31 Oct 2000, Keith Owens wrote:
>> 
>> obj-y is used together with export-objs to split objects into O_OBJS
>> (no export symbol) and OX_OBJS (export symbol).  If usbcore.o (multi)
>> is not replaced by its components then usb.o (in export-objs) is not
>> added to OX_OBJS so usb.c gets compiled with the wrong flags which
>> causes incorrect module symbols.  Multi's in obj-y have to replaced by
>> their components before being split into O_OBS and OX_OBJS.
>
>Your honour, I object.
>
>What would be wrong with just splitting it the other way, ie make OX_OBJS
>be the expanded (but not ordered) list?
>
>That should take care of it, no?

usbcore.o is both multi part *and* order critical.  This is a
combination that the existing "link order relies on declaration order"
kludge cannot cope with.  It requires an explicit declaration of link
order, which is exactly what LINK_FIRST implements.

FWIW, 2.5 kbuild will use LINK_FIRST and LINK_LAST exclusively, instead
of relying on the declaration order.  This is primarily so we get
documentation of link order and why it matters.  But it will also mean
that we can neatly sort declarations by CONFIG_ name if we want to.
That global change is only for 2.5, but there is nothing to stop us
using the preferred technique now, if nothing else works.

For usb, no other Makefile techniques will work, it needs LINK_FIRST.
I don't want to change the USB source code to overcome kbuild problems,
especially when those problems will disappear in 2.5.  And I repeat,
this change only affects usb in 2.4.

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

Re: test10-pre7

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Tue, 31 Oct 2000, Keith Owens wrote:
> >
> > obj-y is used together with export-objs to split objects into O_OBJS
> > (no export symbol) and OX_OBJS (export symbol).  If usbcore.o (multi)
> > is not replaced by its components then usb.o (in export-objs) is not
> > added to OX_OBJS so usb.c gets compiled with the wrong flags which
> > causes incorrect module symbols.  Multi's in obj-y have to replaced by
> > their components before being split into O_OBS and OX_OBJS.
> 
> Your honour, I object.
> 
> What would be wrong with just splitting it the other way, ie make OX_OBJS
> be the expanded (but not ordered) list?
> 
> That should take care of it, no?

As an aside:  remember you mentioned we should try to go 100% OX_OBJS
anyway, eliminating O_OBJS completely...

-- 
Jeff Garzik | "Mind if I drive?"  -Sam
Building 1024   | "Not if you don't mind me clawing at the
MandrakeSoft|  dash and shrieking like a cheerleader."
| -Max
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Linus Torvalds]

On Tue, 31 Oct 2000, Keith Owens wrote:
> 
> obj-y is used together with export-objs to split objects into O_OBJS
> (no export symbol) and OX_OBJS (export symbol).  If usbcore.o (multi)
> is not replaced by its components then usb.o (in export-objs) is not
> added to OX_OBJS so usb.c gets compiled with the wrong flags which
> causes incorrect module symbols.  Multi's in obj-y have to replaced by
> their components before being split into O_OBS and OX_OBJS.

Your honour, I object.

What would be wrong with just splitting it the other way, ie make OX_OBJS
be the expanded (but not ordered) list?

That should take care of it, no?

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: test10-pre7

[Keith Owens]

On Mon, 30 Oct 2000 14:24:13 -0800 (PST), 
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>This is the right fix. We MUST NOT sort those things.

Correction.  We can sort them if we know what the correct link order
should be.  In far too many Makefiles, we have no idea if the existing
order is required or is just historical so we fail safe and do not sort
them.  For USB we know what the link order must be, usb.o must be
first, the rest do not matter.  This patch only affects usb because it
is the only one that uses LINK_FIRST.

>The only reason for sorting is apparently to remove the "multi-objs"
>things, and replace them with the object files they are composed of.
>
>To which I say "Why?"
>
>It makes more sense to just leave the multi's there.

obj-y is used together with export-objs to split objects into O_OBJS
(no export symbol) and OX_OBJS (export symbol).  If usbcore.o (multi)
is not replaced by its components then usb.o (in export-objs) is not
added to OX_OBJS so usb.c gets compiled with the wrong flags which
causes incorrect module symbols.  Multi's in obj-y have to replaced by
their components before being split into O_OBS and OX_OBJS.

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

Re: request advice: how stable is devfs in 2.4.0-test9?

[Marko Kreen]

On Mon, Oct 30, 2000 at 10:45:48PM +0100, Mirko Klemm wrote:
> Could anyone please send me a comment on how actually usable the devfs 
> support in the 2.4.0 test series is at the moment?

Fine.  I was forced to use it from 2.3.99-something and
have not had any problems with it.  (I lifted whole system
from one disk to another and forgot to create /dev :)


> I am currently using 2.4.0-test* as an "ordinary user" and want to try some 
> of the 2.4 specific new features out, but this is my only system and I don't 
> want it to be messed up so much, so I'd like to hear some comments first.
> Which version of devfsd/utils is needed?

I have devfsd 1.3.10.

You better be sure you have following lines in devfsd.conf:

REGISTER.*  MKOLDCOMPAT
UNREGISTER  .*  RMOLDCOMPAT

You can later reconfigure most stuff to use new layout
but especially X is a pain.

-- 
marko

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

trouble with apm on dell latitude cs in 2.2.1[67]

[stewart]

 I've recently upgraded a latitude cs running redhat 6.2 on 2.2.14 with
 card services v3.1.14 to 2.2.17 with card services v3.1.21. Immediately
 I noticed that suspend/resume was broken. Well, suspend was working fine
 but when I raised the lid, the system would come back like normal, then
 the HD drive light would go solid and a few seconds later the system
 would lock hard. No oops or any other indicators. I tried tailing the
 /var/log/messages file (starting before the suspend), but this revealed
 nothing at first. After about 5 tries I managed to elicit one error
 in the log:

 "hda: timeout waiting for DMA"

 but this message did not show up consistently. I tried backing down to
 2.2.16 in case it was a recent bug and then also tried backing up to a
 previous version of card services, but none of this helps. Unless I go
 back to 2.2.14, this system will lock hard on a resume about 7-10 seconds
 after I raise the lid.

 Lacking any other kernel debugging skills, I compiled sysrq into the kernel
 hoping to get something more useful for the list. Although 'showkey -s'
 does generate 0x54 codes, pressing alt-sysrq- yields nothing in the
 kernel I just built it into (2.2.17). 

 One another kernel note, I cannot get the 2.4.0-test9/10 kernels to boot
 on this machine. After lilo, it says:

 "Uncompressing Linux... Ok, booting the kernel."

 then the machine hangs solid. It is not recoverable via alt-ctrl-del.
 I have to hold the power button until the machine cycles. I have no data
 for earlier 2.4.0 kernels.

 What else can I do to debug this and what other info will help in
 identifying the problem?

 Thanks,

 Stewart

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

RE: Linux's implementation of poll() not scalable?

[Mike Jagdis]

Here's something I did last year and then put on ice, partly
through lack of time and partly because I thought I'd pick
it up for 2.5.

  All this talk of event queues misses one thing: we already
have an event queue mechanism. They're called wait queues.
The only problem is that the only on-event action possible
is to wake the process (assuming it was asleep in the first
place). This patch firstly extends the wait queue mechanism
to allow an arbitrary action to be performed. Then I rewrote
the select/poll implementation to use event queueing to avoid
rescanning descriptors that had not changed - and restructured
the loops to be rather more efficient. This approach doesn't
need any changes to driver poll routines, it doesn't need
backwards mapping struct files. It should be fairly easy to
implement a /dev/poll mechanism using this, although I haven't
yet.

  Yes, the change to wait queues has a slight cost, but it isn't
great and the main part of it only happens if you actually sleep.

  Performance graphs and the lmbench derived test programs I
used are at http://www.purplet.demon.co.uk/linux/select/ (bounce
in and out of the index page 'cos the next and prev buttons
aren't wired up :-) )

  Oh, and I updated this patch for 2.4.0-test9.

  Comments and opinions are, as always, welcome :-).

Mike

 select.patch

Re: test10-pre7

[Linus Torvalds]

On Mon, 30 Oct 2000, Jeff Garzik wrote:
> 
> Ya know, sorting those lists causes this problem, too...  usb.o is
> listed first in the various lists, as is usbcore.o.  Is it possible to
> avoid sorting?  Doing so will fix this, and also any other link order
> breakage like this that exists, too.

This is the right fix. We MUST NOT sort those things.

The only reason for sorting is apparently to remove the "multi-objs"
things, and replace them with the object files they are composed of.

To which I say "Why?"

It makes more sense to just leave the multi's 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: [PATCH] Re: test10-pre7

[Linus Torvalds]

On Mon, 30 Oct 2000, Alexander Viro wrote:
> 
> > I didn't actually miss it, I just looked at the users and decided that it
> > looks like they should never have this issue. But I might have missed
> > something. As far as I can tell, "read_cache_page()" is only used for
> > meta-data like things that cannot be truncated.
> 
> invalidate_inode_pages().

Nope. It checks the page count these days, so it would never kill such a
page from under us (we increment the page count while holding the
pagecache lock).

But yes, I'm starting to agree with you more and more..

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: test10-pre7

[Jeff Garzik]

Keith Owens wrote:
> 
> On Mon, 30 Oct 2000 17:01:20 -0500,
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >Keith Owens wrote:
> >> USB still gets unresolved symbols when part is in kernel, part is in
> >> modules and modversions are set.  Patch against 2.4.0-test10-pre7, only
> >> affects drivers/usb/Makefile.
> >
> >Or instead of all that, you could simply call the core init function
> >from init/main.c...
> 
> Does that work when all of usb is a module?  The point of __initcall is
> to avoid all the conditional code that used to be in main.c.

When all of usb is a module, there are no initcalls.

If you need static initialization for in-kernel init, here is the
shortest solution I can come up with:

/* usb.c **/

int usbcore_init() {...}

#ifdef MODULE
module_init(usbcore_init);
#endif
module_exit(usbcore_exit);

/ main.c **/

extern int usbcore_init (void);
/* ... */
#ifdef CONFIG_USB
usbcore_init();
#endif

-- 
Jeff Garzik | "Mind if I drive?"  -Sam
Building 1024   | "Not if you don't mind me clawing at the
MandrakeSoft|  dash and shrieking like a cheerleader."
| -Max
-
To unsubscribe from this list: send 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] Re: test10-pre7

[Rik van Riel]

On Mon, 30 Oct 2000, Alexander Viro wrote:

> The last one is in deactivate_page_nolock() - there we check the
> ->mapping without pagecache_lock and without page lock. Hell
> knows whether it's a bug or not. Rik?

Shouldn't be a problem, since we'll have the lock at a time
we actually /do/ something with those pointers.

In deactivate_page_nolock(), all we can modify is the list
in which the page resides, the flags indicating on which
list the page is and the referenced bit + page age. No other
stuff is touched.

Furthermore, the locking order (first pagecache lock, then
the page_list_lock) would make it difficult to do this right...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

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

Re: test10-pre7

[Keith Owens]

On Mon, 30 Oct 2000 17:01:20 -0500, 
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> USB still gets unresolved symbols when part is in kernel, part is in
>> modules and modversions are set.  Patch against 2.4.0-test10-pre7, only
>> affects drivers/usb/Makefile.
>
>Or instead of all that, you could simply call the core init function
>from init/main.c...

Does that work when all of usb is a module?  The point of __initcall is
to avoid all the conditional code that used to be in main.c.

>Ya know, sorting those lists causes this problem, too...  usb.o is
>listed first in the various lists, as is usbcore.o.  Is it possible to
>avoid sorting?  Doing so will fix this, and also any other link order
>breakage like this that exists, too.

You have it backwards.  Rules.make does *not* sort, the link order is
implicit in the declaration order of objects in the Makefiles.  For
most makefiles, this kludge works, it does not work for USB.  See
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0010.3/0661.html

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

Re: test10-pre7

[Jeff Garzik]

Keith Owens wrote:
> 
> On Mon, 30 Oct 2000 11:32:33 -0800 (PST),
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > - pre7:
> >- Randy Dunlap, USB: printer.c, usb-storage, usb identification and
> >  memory leak fixes
> 
> USB still gets unresolved symbols when part is in kernel, part is in
> modules and modversions are set.  Patch against 2.4.0-test10-pre7, only
> affects drivers/usb/Makefile.

Or instead of all that, you could simply call the core init function
from init/main.c...

Ya know, sorting those lists causes this problem, too...  usb.o is
listed first in the various lists, as is usbcore.o.  Is it possible to
avoid sorting?  Doing so will fix this, and also any other link order
breakage like this that exists, too.

Jeff


-- 
Jeff Garzik | "Mind if I drive?"  -Sam
Building 1024   | "Not if you don't mind me clawing at the
MandrakeSoft|  dash and shrieking like a cheerleader."
| -Max
-
To unsubscribe from this list: send 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: Recommended compiler? - Re: [patch] kernel/module.c (plus gratuitous rant)

[Jakub Jelinek]

On Mon, Oct 30, 2000 at 05:50:07PM -0300, Horst von Brand wrote:
> Martin Dalecki <[EMAIL PROTECTED]> said:
> > Peter Samuelson wrote:
> 
> [...]
> 
> > > * Red Hat "2.96" or CVS 2.97 will probably break any known kernel.
> 
> > Works fine for me and 2.4.0-test10-pre5... however there are tons of
> > preprocessor warnings in some drivers.
> 
> CVS (from 20001028 or so) gave a 2.4.0.10.6/i686 that crashed on boot, no
> time to dig deeper yet.

CVS 2.97 is known to miscompile e.g. buffer.c.

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

Re: [PATCH] Re: test10-pre7

[Alexander Viro]

On Mon, 30 Oct 2000, Alexander Viro wrote:

> 
> 
> On Mon, 30 Oct 2000, Linus Torvalds wrote:
> 
> > How about just changing ->sync_page() semantics to own the page lock? That
> > sound slike the right thing anyway, no?
> 
> It would kill the ->sync_page(), but yes, _that_ might be the right thing ;-)

To elaborate: the thing is called if we get a contention on the page lock.
Essentially, its use in NFS is renice -20 for the requests on our page
wrt RPC scheduler. By the time when page gets unlocked it becomes a NOP.
On local filesystems it just runs the tq_disk - nothing in common with
the NFS case and IMO Trond was wrong lumping them together. In effect,
we are getting run_task_queue(&tq_disk) executed _very_ often and I'm less
than sure that it's a good idea. I think that ->sync_page() is not a
well-defined operation and NFS scheduler should use the locking of its own,
both for inavlidate_... and here.
Cheers,
Al

-
To unsubscribe from this list: send 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: atapi dvd-ram support

[Jens Axboe]

On Tue, Oct 31 2000, Hisaaki Shibata wrote:
> By using serial console, I get messages for you ;-)

Thanks, now you're just one step short of being really
helpful :-). Pass it through ksymoops please, so the
addresses will map to function names + offsets.

> In case of doing "dd if=/dev/zero of=/dev/hdc bs=2048 count=1".
> 
> hdc: ATAPI DVD-ROM DVD-RAM drive, 512kB Cache, UDMA(33)
> hdc: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14

Try it without DMA as well, please. I think I see a DMA bug in there right
now, I'll recheck and send you a new patch.

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send 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] kiobuf/rawio fixes for 2.4.0-test10-pre6

[Jeff Garzik]

Christoph Hellwig wrote:
> 
> On Mon, Oct 30, 2000 at 03:08:31PM -0500, Jeff Garzik wrote:
> > Actually, I wonder if its even possible for mmap_kiobuf to support audio
> > -- full duplex requires that both record and playback buffer(s),
> > theoretically two separate sets of kiobufs, to be presented as one space
> > (with playback always presented before record).
> 
> kvmaps take kiovecs, which are multiple kiobufs ...

s/sets of kiobufs/kiovecs/ in my message and re-read :)

  Ok kiobuf mmap in OSS audio is possible, but at that point
using kiobufs is still 100% overhead, because you still have to allocate
and manage DMA buffers separately due to read(2) and write(2).

-- 
Jeff Garzik | "Mind if I drive?"  -Sam
Building 1024   | "Not if you don't mind me clawing at the
MandrakeSoft|  dash and shrieking like a cheerleader."
| -Max
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

request advice: how stable is devfs in 2.4.0-test9?

[Mirko Klemm]

Could anyone please send me a comment on how actually usable the devfs 
support in the 2.4.0 test series is at the moment?
I am currently using 2.4.0-test* as an "ordinary user" and want to try some 
of the 2.4 specific new features out, but this is my only system and I don't 
want it to be messed up so much, so I'd like to hear some comments first.
Which version of devfsd/utils is needed?
Thanks,
Mirko
-- 
Mirko Klemm

[EMAIL PROTECTED]

GPG-Public Key at:
http://www.mutantenzoo.de/kmirko.asc

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

Re: [PATCH] 2.4.0-test10-pre6 TLB flush race in establish_pte

[Kanoj Sarcar]

> 
> So while there may be a more elegant solution down the road, I would like
> to see the simple fix put back into 2.4.  Here is the patch to essential
> put the code back to the way it was before the S/390 merge.  Patch is
> against 2.4.0-test10pre6.
> 
> --- linux/mm/memory.cFri Oct 27 15:26:14 2000
> +++ linux-2.4.0-test10patch/mm/memory.c  Fri Oct 27 15:45:54 2000
> @@ -781,8 +781,8 @@
>   */
>  static inline void establish_pte(struct vm_area_struct * vma, unsigned long 
>address, pte_t *page_table, pte_t entry)
>  {
> -flush_tlb_page(vma, address);
>  set_pte(page_table, entry);
> +flush_tlb_page(vma, address);
>  update_mmu_cache(vma, address, entry);
>  }
>

Great, lets do it. Definitely solves one race. 

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

Re: test10-pre7

[Keith Owens]

On Mon, 30 Oct 2000 11:32:33 -0800 (PST), 
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> - pre7:
>- Randy Dunlap, USB: printer.c, usb-storage, usb identification and
>  memory leak fixes

USB still gets unresolved symbols when part is in kernel, part is in
modules and modversions are set.  Patch against 2.4.0-test10-pre7, only
affects drivers/usb/Makefile.

Index: 0-test10-pre7.1/drivers/usb/Makefile
--- 0-test10-pre7.1/drivers/usb/Makefile Tue, 24 Oct 2000 14:20:12 +1100 kaos 
(linux-2.4/n/b/19_Makefile 1.1.1.11 644)
+++ 0-test10-pre7.1(w)/drivers/usb/Makefile Tue, 31 Oct 2000 08:33:46 +1100 kaos 
+(linux-2.4/n/b/19_Makefile 1.1.1.11 644)
@@ -18,6 +18,18 @@ O_OBJS   :=
 
 export-objs:= usb.o
 
+# usb.o contains usb_init which is marked as __initcall (actually
+# module_init).  usb_init must be executed before all other usb __initcall
+# routines, otherwise the individual drivers will be initialized before the
+# hub driver is, causing the hub driver initialization sequence to
+# needlessly probe every USB driver with the root hub device.  This causes
+# a lot of unnecessary system log messages, a lot of user confusion, and
+# has been known to cause a incorrectly programmed USB device driver to
+# grab the root hub device improperly.
+# Greg Kroah-Hartman, 27 Oct 2000
+
+LINK_FIRST := usb.o
+
 # Multipart objects.
 
 list-multi := usbcore.o
@@ -98,6 +110,10 @@ int-m   := $(sort $(foreach m, $(multi-m)
 
 obj-m  := $(filter-out $(obj-y), $(obj-m))
 int-m  := $(filter-out $(int-y), $(int-m))
+
+# Take multi-part drivers out of obj-y and put components in.
+
+obj-y  := $(filter-out $(list-multi), $(obj-y)) $(int-y)
 
 # Translate to Rules.make lists.
 
Index: 0-test10-pre7.1/Rules.make
--- 0-test10-pre7.1/Rules.make Tue, 19 Sep 2000 10:36:07 +1100 kaos 
(linux-2.4/B/c/24_Rules.make 1.2.1.4 644)
+++ 0-test10-pre7.1(w)/Rules.make Tue, 31 Oct 2000 08:33:46 +1100 kaos 
+(linux-2.4/B/c/24_Rules.make 1.2.1.4 644)
@@ -31,6 +31,9 @@ unexport LX_OBJS
 unexport MX_OBJS
 unexport MIX_OBJS
 unexport SYMTAB_OBJS
+# Control link order, added 29 Oct 2000 Keith Owens <[EMAIL PROTECTED]>
+unexport LINK_FIRST
+unexport LINK_LAST
 
 #
 # Get things started.
@@ -84,8 +87,19 @@ all_targets: $(O_TARGET) $(L_TARGET)
 #
 # Rule to compile a set of .o files into one .o file
 #
+# Note: if LINK_FIRST or LINK_LAST are specified, the rest of the
+# object files are sorted to remove duplicates.  Thus, if you use
+# LINK_FIRST/LAST, make sure they specify all ordering requirements.
+#
 ifdef O_TARGET
-ALL_O = $(OX_OBJS) $(O_OBJS)
+  ALL_O = $(OX_OBJS) $(O_OBJS)
+  ifneq ($(strip $(LINK_FIRST)$(LINK_LAST)),)
+ALL_O := $(sort $(ALL_O))
+ALL_O := \
+  $(filter $(ALL_O), $(LINK_FIRST)) \
+  $(filter-out $(LINK_FIRST) $(LINK_LAST), $(ALL_O)) \
+  $(filter $(ALL_O), $(LINK_LAST))
+  endif
 $(O_TARGET): $(ALL_O)
rm -f $@
 ifneq "$(strip $(ALL_O))" ""
Index: 0-test10-pre7.1/Documentation/kbuild/makefiles.txt
--- 0-test10-pre7.1/Documentation/kbuild/makefiles.txt Tue, 31 Oct 2000 08:28:16 +1100 
kaos (linux-2.4/b/d/12_makefiles. 1.4 644)
+++ 0-test10-pre7.1(w)/Documentation/kbuild/makefiles.txt Tue, 31 Oct 2000 08:33:46 
++1100 kaos (linux-2.4/b/d/12_makefiles. 1.4 644)
@@ -1,6 +1,9 @@
 Linux Kernel Makefiles
 2000-September-14
 Michael Elizabeth Chastain, <[EMAIL PROTECTED]>
+2000-October-29
+LINK_FIRST/LAST Keith Owens <[EMAIL PROTECTED]>,
+   Peter Samuelson <[EMAIL PROTECTED]>
 
 
 
@@ -319,7 +322,7 @@ architecture-specific values.
# arch/alpha/Makefile
 
SUBDIRS := $(SUBDIRS) arch/alpha/kernel arch/alpha/mm \
-  arch/alpha/lib arch/alpha/math-emu
+  arch/alpha/lib arch/alpha/math-emu
 
This list may depend on the configuration:
 
@@ -645,12 +648,17 @@ The public interface of Rules.make consi
with the name $(O_TARGET).  This $(O_TARGET) name also appears
in the top Makefile.
 
-   The order of files in $(O_OBJS) and $(OX_OBJS) is significant.
-   All $(OX_OBJS) files come first, in the order listed, followed by
-   all $(O_OBJS) files, in the order listed.  Duplicates in the lists
-   are allowed: the first instance will be linked into $(O_TARGET)
-   and succeeding instances will be ignored.  (Note: Rules.make may
-   emit warning messages for duplicates, but this is harmless).
+   Even if a subdirectory Makefile has an $(O_TARGET), the .config
+   options still control whether or not its $(O_TARGET) goes into
+   vmlinux.  See the $(M_OBJS) example below.
+
+   If neither $(LINK_FIRST) nor $(LINK_LAST) are defined, the order of
+   files in $(O_OBJS) and $(OX_OBJS) is significant.  All $(OX_OBJS)
+   files come first, in the order listed, followed by all $(O_OBJS)
+   files, in the order listed.  Duplicates in the lists are allowed:
+   the first instance wil

[PATCH] 2.4.0-test10-pre6 TLB flush race in establish_pte

[Steve Pratt/Austin/IBM]

Back in April there were discussions about the race in establish_pte with
the flush_tlb before the set_pte.  Many options were discussed, but due in
part to a concern about S/390 having introduced the code, no patch ever
appeared.  I talked with Martin Schwidefsky of the S/390 Linux development
team and he said that:

>the establish_pte was in fact introduced because of Linux/390. We wanted
to use the special S/390 instruction ipte (invalidate page >table entry).
In the meantime we found out that we need a lot more changes to be able to
use this instruction, so we disabled it again. >Until we have a proper
patch you should revoke the establish_pte change if you found it to be
faulty. I too think there is a race >condition.

So while there may be a more elegant solution down the road, I would like
to see the simple fix put back into 2.4.  Here is the patch to essential
put the code back to the way it was before the S/390 merge.  Patch is
against 2.4.0-test10pre6.

--- linux/mm/memory.cFri Oct 27 15:26:14 2000
+++ linux-2.4.0-test10patch/mm/memory.c  Fri Oct 27 15:45:54 2000
@@ -781,8 +781,8 @@
  */
 static inline void establish_pte(struct vm_area_struct * vma, unsigned long address, 
pte_t *page_table, pte_t entry)
 {
-flush_tlb_page(vma, address);
 set_pte(page_table, entry);
+flush_tlb_page(vma, address);
 update_mmu_cache(vma, address, entry);
 }




Linux Technology Center - IBM Corporation
11400 Burnet Road
Austin, TX  78758
(512) 838-9763  EMAIL: [EMAIL PROTECTED]

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

Re: [PATCH] Re: test10-pre7

[Alexander Viro]

On Mon, 30 Oct 2000, Linus Torvalds wrote:

> How about just changing ->sync_page() semantics to own the page lock? That
> sound slike the right thing anyway, no?

It would kill the ->sync_page(), but yes, _that_ might be the right thing ;-)

> I didn't actually miss it, I just looked at the users and decided that it
> looks like they should never have this issue. But I might have missed
> something. As far as I can tell, "read_cache_page()" is only used for
> meta-data like things that cannot be truncated.

invalidate_inode_pages().

> I'd really like to do these in the thing that locks the page, and make the
> rule be that the page locker needs to do the work. That's why I'd prefer
> to let the test be in the _caller_ of filemap_write_page(), as that's the
> point where we got the lock.

Fine with me, but then we would have to do it in try_to_swap_out() and
that would be Wrong Thing(tm) (e.g. because ->swapout() makes sense for
anonymous pages).

We could do it in filemap_swapout(), but the lock is taken by its caller,
so...
Cheers,
Al

-
To unsubscribe from this list: send 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.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Thanks,

It will make merging the MANOS kernel happen faster.  My DLL prototypes
are using subsets
of Linux 2.2.16 for MANOS at present, and what I really need is for the
support issues to dovetail into a supported effort.  This one might fit
the bill.  I have no desire for TRG to support the 100's of LAN and disk
drivers all by our little lonesome in a divergent code base.

Jeff

Alan Cox wrote:
> 
> > context switches.   profiling Ring 0 Linux vs. NetWare will give me an
> > excellent idea of where
> > the optimizations will need to be inserted.  A straight MARS-NWE port to
> > kernel would just
> > happen, since we would be able to just load in kernel space and run it
> > with no code
> > changes.
> 
> There are one bunch of people running Linux on a flat memory space with no
> protection although their goal was to make Linux run on mmuless embedded
> hardware.
> 
> See www.uclinux.org; the uclinux guys started a 2.4 port recently. Basically
> the idea is to have a mm-nommu/ directory which implements a mostly compatible
> replacement for the mm layer (obviously stuff like mmap dont work without an
> mmu and fork is odd), and a set of binary loaders to load flat binaries with
> relocations.
> 
> That I think is the project that overlaps ..
> 
> -
> To unsubscribe from this list: send 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: 2.2.X patch query

[Andreas Dilger]

Riley Williams writes:
> I'm NOT planning on making panics automatically dump to floppy. What I
> was looking at instead was to add a SysRq option to dump the current
> syslog buffer to floppy. This would be available at any time, but ONLY
> if the kernel has SYSRQ support compiled in, and has additionally
> enabled CONFIG_SYSRQ_DUMPLOG (which appears when SYSRQ is enabled). In
> addition, it would need to be enabled at runtime, probably by writing
> to a root-owned /proc file with 0600 permissions.

Just as an FYI, there is a patch that does essentially what you are
looking at: kmsgdump, by Willy Tarreau.  It does a syslog dump to
floppy with SysRq-D, and has the excellent feature that it writes a
(simple) MS-DOS formatted floppy, which also has a "pass-through"
boot sector, so you can leave it in the floppy drive and it will not
halt booting.  You can have syslog sizes up to 64kB.  It also supports
printing to the printer port.

http://www-miaif.lip6.fr/willy/pub/linux-patches/kmsgdump/

This would actually be very handy in conjunction with the "loadable
sysrq functions" patch that has been posted here a couple of times.

I suspect that such a patch wouldn't make it into 2.2 or 2.4.  I also
don't see why you want to have a strangely formatted floppy, since even
a regular 1.44 format will hold your proposed maximum 1MB buffer.  Since
the printk buffer is pinned kernel memory, you probably don't want that
any larger (if 1MB at all).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send 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: Need info on the use of certain datastructures and the first C++ keyword patch for 2.2.17

[Keith Owens]

On Mon, 30 Oct 2000 18:16:44 + (GMT), 
Alan Cox <[EMAIL PROTECTED]> wrote:
>> 2.4 symbol generation code never sees the C++ names, 2.5 code might.
>> To detect a mismatch between kernel headers and the module version
>> file, I have to generate the checksum for the consumer of the symbol
>> (C++) as well as the generator of the symbol (C) and compare them.
>
>These are structure field names. They aren't part of a symbol and are only
>part of your checksum computation which is done on the C headers so a constant.
>
>If we were renaming variables or actual objects I'd agree. But structure names
>are fine so long as we only use C names for the module checksum computation

The checksum is done on the output from the preprocessor, not the
headers.  Changing field names via preprocessor flags gives different
checksums for structures.

-
To unsubscribe from this list: send 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] Re: test10-pre7

[Linus Torvalds]

On Mon, 30 Oct 2000, Alexander Viro wrote:
> 
> Unfortunately, it doesn't fix the thing. ->sync_page() is called when we
> do not own the page lock and nfs_sync_page() uses page->mapping. Yes, we
> check it before calling the bloody thing, but we don't own the lock.

Good catch.

> Problem only for NFS, but I'm not sure what to do about it - the whole
> point of ->sync_page() seems to be (if I understood Trond's intentions
> right) in forcing the ->readpage() in progress.

How about just changing ->sync_page() semantics to own the page lock? That
sound slike the right thing anyway, no?

> Another place you've missed is in read_cache_page(). That one is easy - we've
> just locked the page and we should just repeat the whole thing if it's out
> of cache.

I didn't actually miss it, I just looked at the users and decided that it
looks like they should never have this issue. But I might have missed
something. As far as I can tell, "read_cache_page()" is only used for
meta-data like things that cannot be truncated.

But you're right, we should do it for consistency.

> One more is in filemap_swapout() - dunno, I just shifted the check to
> filemap_write_page().

I'd really like to do these in the thing that locks the page, and make the
rule be that the page locker needs to do the work. That's why I'd prefer
to let the test be in the _caller_ of filemap_write_page(), as that's the
point where we got the lock.

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: Recommended compiler? - Re: [patch] kernel/module.c (plus gratuitous rant)

[Horst von Brand]

Martin Dalecki <[EMAIL PROTECTED]> said:
> Peter Samuelson wrote:

[...]

> > * Red Hat "2.96" or CVS 2.97 will probably break any known kernel.

> Works fine for me and 2.4.0-test10-pre5... however there are tons of
> preprocessor warnings in some drivers.

CVS (from 20001028 or so) gave a 2.4.0.10.6/i686 that crashed on boot, no
time to dig deeper yet.
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Readiness vs. completion (was: Re: Linux'simplementationofpoll()not scalable?)

[John Gardiner Myers]

Dan Kegel wrote:
> If you have a top-notch completion notification event interface
> provided natively by the OS, though, does that get rid of the
> need for the "async poll" mechanism?

A top-notch completion notification event interface needs to be able to
provide "async poll" functionality.  There are some situations where an
application needs a completion notification event when an fd is readable
or writeable, but cannot supply buffers or data until after the event
arrives.

One of these situations is when the application is using a nonblocking
interface to an existing library.  When the library returns a
"wouldblock" condition, the application determines through the interface
(or the interface definition) which poll events need to occur before a
subsequent call to the library is likely to result in progress.  The
application then needs to schedule a completion event for when those
poll events occur.  The application does not know enough about the
library implementation to schedule async I/O and the library is not
written to use async I/O itself.

Another situation occurs when handling a large number of mostly idle
connections.  Consider a protocol for which a server receives one
command per half hour per connection.  A server process would want to
handle hundreds of thousands to millions of such connections.  If the
server were to use asynchronous read operations, then it would have to
allocate one input buffer per connection.  Better to instead use
asynchronous read poll operations, allocating buffers to connections
only when those connections have pending input.

This latter situation would be further improved by a variant of the
asynchronous read operation where the buffer is supplied by either the
event queue object or the caller to get_event(), but that's a separate
issue.
 S/MIME Cryptographic Signature

[PATCH] Re: test10-pre7

[Alexander Viro]

On Mon, 30 Oct 2000, Linus Torvalds wrote:

> 
> Ok, this one contains at least a preliminary fix for the problem with
> truncate together with a concurrent page access - the bug that causes
> oopses in block_read_full_page() and filemap_nopage().
> 
> This is a fairly minimal fix, and I'll still have to verify that I caught
> all the relevant places, but I wanted people who have seen this problem to
> please test this out asap - I'll make a real test10 later once I've
> integrated some further patches from Alan and Jeff, but this should fix
> the major show-stopper bug.

Unfortunately, it doesn't fix the thing. ->sync_page() is called when we
do not own the page lock and nfs_sync_page() uses page->mapping. Yes, we
check it before calling the bloody thing, but we don't own the lock.
Problem only for NFS, but I'm not sure what to do about it - the whole
point of ->sync_page() seems to be (if I understood Trond's intentions
right) in forcing the ->readpage() in progress.

Another place you've missed is in read_cache_page(). That one is easy - we've
just locked the page and we should just repeat the whole thing if it's out
of cache.

One more is in filemap_swapout() - dunno, I just shifted the check to
filemap_write_page().

One more: check in do_generic_file_read() for ->mapping->i_shared_mmap.
Fix: trivial.

The last one is in deactivate_page_nolock() - there we check the ->mapping
without pagecache_lock and without page lock. Hell knows whether it's a
bug or not. Rik?

Minimal patch (against -pre7) follows. It still leaves sync_page() problem
open - any suggestions on that one are very welcome. Other than that and
deactivate_page_nolock() we should be safe wrt. ->mapping. Please, apply -
after that we will be in sync. nfs_sync_page() is still a problem and if
somebody (Trond?) might tell WTF it is supposed to be...
Cheers,
Al

--- filemap.c   Mon Oct 30 18:46:17 2000
+++ filemap.c.new   Mon Oct 30 18:54:05 2000
@@ -981,7 +981,7 @@
 * virtual addresses, take care about potential aliasing
 * before reading the page on the kernel side.
 */
-   if (page->mapping->i_mmap_shared != NULL)
+   if (mapping->i_mmap_shared != NULL)
flush_dcache_page(page);
 
/*
@@ -1473,7 +1473,8 @@
 * vma/file is guaranteed to exist in the unmap/sync cases because
 * mmap_sem is held.
 */
-   return page->mapping->a_ops->writepage(file, page);
+   /* Nothing to do if somebody truncated the page from under us.. */
+   return page->mapping?page->mapping->a_ops->writepage(file, page):0;
 }
 
 
@@ -1544,9 +1545,7 @@
lock_page(page);
 
error = 0;
-   /* Nothing to do if somebody truncated the page from under us.. */
-   if (page->mapping)
-   error = filemap_write_page(vma->vm_file, page, 1);
+   error = filemap_write_page(vma->vm_file, page, 1);
 
UnlockPage(page);
page_cache_free(page);
@@ -2313,13 +2312,20 @@
int (*filler)(void *,struct page*),
void *data)
 {
-   struct page *page = __read_cache_page(mapping, index, filler, data);
+   struct page *page;
+retry:
+   page = __read_cache_page(mapping, index, filler, data);
int err;
 
if (IS_ERR(page) || Page_Uptodate(page))
goto out;
 
lock_page(page);
+   if (!page->mapping) {
+   UnlockPage(page);
+   page_cache_release(page);
+   goto retry;
+   }
if (Page_Uptodate(page)) {
UnlockPage(page);
goto out;

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

Re: [PATCH] kiobuf/rawio fixes for 2.4.0-test10-pre6

[Christoph Hellwig]

On Mon, Oct 30, 2000 at 03:08:31PM -0500, Jeff Garzik wrote:
> Actually, I wonder if its even possible for mmap_kiobuf to support audio
> -- full duplex requires that both record and playback buffer(s),
> theoretically two separate sets of kiobufs, to be presented as one space
> (with playback always presented before record).

kvmaps take kiovecs, which are multiple kiobufs ...

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send 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: / on ramfs, possible?

[Stuart Lynne]

In article <[EMAIL PROTECTED]>,
Anders Eriksson <[EMAIL PROTECTED]> wrote:
>--==_Exmh_17293564P
>Content-Type: text/plain; charset=us-ascii
>
>
>I want my / to be a ramfs filesystem. I intend to populate it from an 
>initrd image, and then remount / as the ramfs filesystem. Is that at 
>all possible? The way I see it the kernel requires / on a device 
>(major,minor) or nfs.
>
>Am I out of luck using ramfs as /? If it's easy to fix, how do I fix it?

Yes it works.

You will need pivot_root. 

Something like the following at the end of your initrd /linuxrc script 
should mount your ramfs, copy the existing root fs files to it, pivot
and unmount your old root. YMMV
 
mkdir -p /ramfs /ram1
mount -t ramfs /ramfs /ramfs
find / | sed '/^\/ramfs/d;/^\/proc\/.*/d' | cpio -pdmV /ramfs
cd /ramfs
pivot_root . ram1
exec chroot . sh -c 'umount /ram1; exit' < dev/console >dev/console


BTW has anyone thought of writing a small utility to emulate df for ramfs?

-- 
__O 
Fireplug - a Lineo company_-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <[EMAIL PROTECTED]>   www.fireplug.net604-461-7532
-
To unsubscribe from this list: send 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] kiobuf/rawio fixes for 2.4.0-test10-pre6

[Jeff Garzik]

Christoph Hellwig wrote:
> 
> On Mon, Oct 30, 2000 at 01:56:07PM -0500, Jeff Garzik wrote:
> > My question from above is:  how can the via audio mmap in test10-preXX
> > be improved by using kiobufs?  I am not a kiobuf expert, but AFAICS a
> > non-kiobuf implementation is better for audio drivers.  (and the via
> > audio mmap implementation is what some other audio drivers are about to
> > start using...)
> 
> I think the biggest advantage is that you actually get the list of pages
> when you perform the mmap instead of doing virt_to_page on every ->nopage.
> That should speed up the operations on the mmap'ed are a bit.

nopage() is only called when the page is not mapped for the current
process.  So it doesn't get called very often.  Easy enough to call
virt_to_page at alloc instead of nopage time, though.  Patch attached :)


> The other strong argument for the kiobuf solution is code-sharing. Instead
> of having every (sound) driver playing with the vm, there is one central
> place when you use kvmaps.

Actually, I wonder if its even possible for mmap_kiobuf to support audio
-- full duplex requires that both record and playback buffer(s),
theoretically two separate sets of kiobufs, to be presented as one space
(with playback always presented before record).  Even if you can do that
with mmap_kiobuf, some audio hardware doesn't support scatter-gather, so
each set of kiobufs must be physically contiguous for each channel.

  audio drivers' write(2) should be kiobuf'd, but only for
hardware which supports scatter-gather.

I can't think of any other cases where kiobuf would apply to audio.

Jeff


-- 
Jeff Garzik | "Mind if I drive?"  -Sam
Building 1024   | "Not if you don't mind me clawing at the
MandrakeSoft|  dash and shrieking like a cheerleader."
| -Max

Index: drivers/sound/via82cxxx_audio.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/sound/via82cxxx_audio.c,v
retrieving revision 1.1.1.6.4.1
diff -u -r1.1.1.6.4.1 via82cxxx_audio.c
--- drivers/sound/via82cxxx_audio.c 2000/10/27 08:21:41 1.1.1.6.4.1
+++ drivers/sound/via82cxxx_audio.c 2000/10/30 19:57:21
@@ -226,6 +226,7 @@
 struct via_sgd_data {
dma_addr_t handle;
void *cpuaddr;
+   struct page *page;
 };
 
 
@@ -626,6 +627,7 @@
 
if (!chan->sgbuf[i].cpuaddr)
goto err_out_nomem;
+   chan->sgbuf[i].page = virt_to_page (chan->sgbuf[i].cpuaddr);
 
if (i < (VIA_DMA_BUFFERS - 1))
chan->sgtable[i].count = cpu_to_le32 (VIA_DMA_BUF_SIZE | 
VIA_FLAG);
@@ -722,6 +724,7 @@
 chan->sgbuf[i].handle);
chan->sgbuf[i].cpuaddr = NULL;
chan->sgbuf[i].handle = 0;
+   chan->sgbuf[i].page = NULL;
}
 
if (chan->sgtable) {
@@ -1717,9 +1720,11 @@
} else if (!wr)
chan = &card->ch_in;
 
+   assert (chan->sgbuf[pgoff].cpuaddr != NULL);
+   assert (chan->sgbuf[pgoff].page != NULL);
assert unsigned long)chan->sgbuf[pgoff].cpuaddr) % PAGE_SIZE) == 0);
 
-   dmapage = virt_to_page (chan->sgbuf[pgoff].cpuaddr);
+   dmapage = chan->sgbuf[pgoff].page;
DPRINTK ("EXIT, returning page %p for cpuaddr %lXh\n",
 dmapage, (unsigned long) chan->sgbuf[pgoff].cpuaddr);
get_page (dmapage);

Re: installing an ISR from user code

[Richard B. Johnson]

On Mon, 30 Oct 2000, Tim Waugh wrote:

> On Mon, Oct 30, 2000 at 11:06:59AM -0800, [EMAIL PROTECTED] wrote:
> 
> > I'm new at this myself, but how about creating a minor number for each
> > ISR?  When the BH runs, it wakes up the processing waiting on the
> > device for that ISR.
> 
> ... which won't get run until after the interrupt is processed, but
> the interrupt won't get processed until it's run.  Nope.
> 
> Tim.
> */
> 

An interrupt will occur at any time. The user-pages may not be in
memory at that time.

I suggest you do your ISR in the driver (or module) where it really
should be done. The ISR pages are always present.

Cheers,
Dick Johnson

Penguin : Linux version 2.2.17 on an i686 machine (801.18 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/

2.2.X patch query

[Riley Williams]

Hi Alan.

You may remember a while back a suggestion that panic messages be
dumped to floppy so they can be read afterwards.

I've been looking into this idea for a while, in between working on my
plans to get married, and looking for a job somewhere, and I think I
have the bones of it laid out now.

I'm NOT planning on making panics automatically dump to floppy. What I
was looking at instead was to add a SysRq option to dump the current
syslog buffer to floppy. This would be available at any time, but ONLY
if the kernel has SYSRQ support compiled in, and has additionally
enabled CONFIG_SYSRQ_DUMPLOG (which appears when SYSRQ is enabled). In
addition, it would need to be enabled at runtime, probably by writing
to a root-owned /proc file with 0600 permissions.

Before I go any further with this, I would like to ask a few questions
relating to it:

 1. Is there any likelihood of this making it into the official
kernel, or am I just wasting my time?

 2. Would I be right in thinking it's too late for either the
2.2 or 2.4 kernels ???

Assuming it'd be of interest to Linus and yourself...

 3. My investigations so far have indicated that the current
syslog buffer at 16k is too small to guarantee that all
the relevant messages are still there. I would therefore
be looking at increasing this to at least 32k, and would
probably include a config menu to select the size to use
if CONFIG_SYSRQ_DUMPLOG is enabled, offering 32k, 64k,
128k, 256k, 512k and 1M as options.

Would this cause any problems?

 4. My choice would be to use SYSRQ-D to activate this. Are
there any other plans for that combination, that you are
aware of?

 5. I was wondering about providing some means of selecting
whether to dump to /dev/fd0 or /dev/fd1 (or others if
present). What would be your opinion on this?

 6. A while back, I developed a high-level floppy formatter
that produces a non-standard DOS-compatible format that
allows 1436k of data on a 1440k floppy, and produced a
bash script that would produce disks formatted in this
format.

My current plans are for SYSRQ-D to raw write direct to
/dev/fd0 and effectively reformat the disks in this
format, dropping the log file thereon in the process. I
don't plan on doing the low-level format, just the
high-level one.

Can you see anything wrong with this idea?

Best wishes from Riley.


-
To unsubscribe from this list: send 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] kiobuf/rawio fixes for 2.4.0-test10-pre6

[Christoph Hellwig]

On Mon, Oct 30, 2000 at 01:56:07PM -0500, Jeff Garzik wrote:
> My question from above is:  how can the via audio mmap in test10-preXX
> be improved by using kiobufs?  I am not a kiobuf expert, but AFAICS a
> non-kiobuf implementation is better for audio drivers.  (and the via
> audio mmap implementation is what some other audio drivers are about to
> start using...)

I think the biggest advantage is that you actually get the list of pages
when you perform the mmap instead of doing virt_to_page on every ->nopage.
That should speed up the operations on the mmap'ed are a bit.

The other strong argument for the kiobuf solution is code-sharing. Instead
of having every (sound) driver playing with the vm, there is one central
place when you use kvmaps.

Christoph

-- 
Always remember that you are unique.  Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test9 v4l-bttv missing?

[Mirko Klemm]

Hi,
when I "make config" 2.4.0-test9 the option to select video for linux for 
bt848 seems to have gone away. How come? Has it been removed or am I just too 
stupid to find it?

Regards,
Mirko
-- 
Mirko Klemm

[EMAIL PROTECTED]

GPG-Public Key at:
http://www.mutantenzoo.de/kmirko.asc

encrypted messages preferred
-
To unsubscribe from this list: send 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: installing an ISR from user code

[Anton Altaparmakov]

At 17:23 30/10/2000, Brett Smith wrote:
>We have written a char driver for our proprietary h/w.  This driver
>handles a multitude of interrupts from the h/w in the following 
>fashion:  The ISR reads/saves the status register (indication of which int 
>was hit) in
>global, and the marks the BH to run.  The BH uses the global to call one
>of 32 "ISRs" (an array of func ptrs).  I would like to be able to
>install an "ISR" dynamically from user code (the module has already been
>installed).  Is this possible?
>
>If it is possible, how does the build/link work?

Of course it is possible. - There are drivers out there doing similar 
things. - Unfortunately while the one I actually know is open source the 
program attaching to this driver is not open source so you can only see the 
kernel side of the solution. )-:

Download: ftp://ftp.sigmadesigns.com/NetStr_2000/NetStream2000-0.1.033.0.tar.gz

Gunzip/Untar the archive and look in the Barbados/kernelmode directory in 
the file quasar.c. - In that file you will find the implementation of some 
IOCTLs and the one you will find most interesting is IOCTL_SEND_PID which 
is used for the purpose of registering a user space ISR with the kernel 
mode driver.

This concept can easily be extended by another passed in argument 
containing which ISR to register with this call or you could do them all at 
once whatever suits you.

Hope this helps.

Regards,

 Anton

>thanks,
>[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/

-- 
  "Education is what remains after one has forgotten everything he 
learned in school." - Albert Einstein
-- 
Anton Altaparmakov  Voice: +44-(0)1223-333541(lab) / +44-(0)7712-632205(mobile)
Christ's CollegeeMail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Cambridge CB2 3BUICQ: 8561279
United Kingdom   WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

test10-pre7

[Linus Torvalds]

Ok, this one contains at least a preliminary fix for the problem with
truncate together with a concurrent page access - the bug that causes
oopses in block_read_full_page() and filemap_nopage().

This is a fairly minimal fix, and I'll still have to verify that I caught
all the relevant places, but I wanted people who have seen this problem to
please test this out asap - I'll make a real test10 later once I've
integrated some further patches from Alan and Jeff, but this should fix
the major show-stopper bug.

Thanks,

Linus


 - pre7:
- Niels Jensen: remove no-longer-needed workarounds for old gcc versions
- Ingo Molnar & Rik v Riel: VM inactive list maintenance correction
- Randy Dunlap, USB: printer.c, usb-storage, usb identification and
  memory leak fixes
- David Miller: networking updates
- David Mosberger: add AT_CLKTCK to elf information. And make AT_PAGESZ work
  for static binaries too.
- oops. pcmcia broke by mistake
- Me: truncate vs page access race fix.

 - pre6:
- Jeremy Fitzhardinge: autofs4 expiry fix
- David Miller: sparc driver updates, networking updates
- Mathieu Chouquet-Stringer: buffer overflow in sg_proc_dressz_write
- Ingo Molnar: wakeup race fix (admittedly the window was basically
  non-existent, but still..)
- Rasmus Andersen: notice that "this_slice" is no longer used for
  scheduling - delete the code that calculates it.
- ALI pirq routing update. It's even uglier than we initially thought..
- Dimitrios Michailidis: fix ipip locking bugs
- Various: face it - gcc-2.7.2.3 miscompiles structure initializers.
- Paul Cassella: locking comments on dev_base
- Trond Myklebust: NFS locking atomicity. refresh inode properly.
- Andre Hedrick: Serverworks Chipset driver, IDE-tape fix
- Paul Gortmaker: kill unused code from 8390 support.
- Andrea Arcangeli: fix nfsv3d wrong truncates over 4G
- Maciej W. Rozycki: PIIX4 needs the same USB quirk handling as PIIX3.
- me: if we cannot figure out the PCI bridge windows, just "inherit"
  the window from the parent. Better than not booting.
- Ching-Ling Lee: ALI 5451 Audio core support update

 - pre5:
- Mikael Pettersson: more Pentium IV cleanup.
- David Miller: non-x86 platforms missed "pte_same()".
- Russell King: NFS invalidate_inode_pages() can do bad things!
- Randy Dunlap: usb-core.c is gone - module fix
- Ben LaHaise: swapcache fixups for the new atomic pte update code
- Oleg Drokin: fix nm256_audio memory region confusion
- Randy Dunlap: USB printer fixes
- David Miller: sparc updates
- David Miller: off-by-one error in /proc socket dumper
- David Miller: restore non-local bind() behaviour.
- David Miller: wakeups on socket shutdown()
- Jeff Garzik: DEPCA net drvr fixes and CodingStyle
- Jeff Garzik: netsemi net drvr fix
- Jeff Garzik & Andrea Arkangeli: keyboard cleanup
- Jeff Garzik: VIA audio update
- Andrea Arkangeli: mxcsr initialization cleanup and fix
- Gabriel Paubert: better twd_i387_to_fxsr() emulation
- Andries Brouwer: proper error return in ext2 mkdir()

 - pre4:
- disable writing to /proc/xxx/mem. Sure, it works now, but it's still
  a security risk.
- IDE driver update (Victroy66 SouthBridge support)
- i810 rng driver cleanup
- fix sbus Makefile
- named initializers in module..
- ppoe: remove explicit initializer - it's done with initcalls.
- x86 WP bit detection: do it cleanly with exception handling
- Arnaldo Carvalho de Melo: memory leaks in drivers/media/video
- Bartlomiej Zolnierkiewicz: video init functions get __init
- David Miller: get rid of net/protocols.c - they get to initialize themselves
- David Miller: get rid of dev_mc_lock - we hold dev->xmit_lock anyway.
- Geert Uytterhoeven: Zorro (Amiga) bus support update
- David Miller: work around gcc-2.7.2 bug
- Geert Uytterhoeven: mark struct consw's "const".
- Jeff Garzik: network driver cleanups, ns558 joystick driver oops fix
- Tigran Aivazian: clean up __alloc_pages(), kill_super() and
  notify_change()
- Tigran Aivazian: move stuff from .data to .bss
- Jeff Garzik: divert.h typename cleanups
- James Simmons: mdacon using spinlocks
- Tigran Aivazian: fix BFS free block calculation
- David Miller: sparc32 works again
- Bernd Schmidt: fix undefined C code (set/use without a sequence point)
- Mikael Pettersson: nicer Pentium IV setup handling.
- Georg Acher: usb-uhci cpia oops fix
- Kanoj Sarcar: more node_data cleanups for [non]NUMA.
- Richard Henderson: alpha update to new vmalloc setup
- Ben LaHaise: atomic pte updates (don't lose dirty bit)
- David Brownell: ohci memory debugging (== use separate slabs for allocation)

 - pre3:
- update email address of Joerg Reuter
- Andries Brouwer: spelling fixes, missing atari brel

2.4.0-test9 pppoe broken?

[Mirko Klemm]

Hi,
I just upgraded from test7 to test9, now the pppoe (to be precise, pppox on 
which pppoe depends)  module segfaults when loaded with modprobe the first 
time, a second attempt causes lots of disk activity and eats up all processor 
time, eventually locking me out of my system (no oops, though, so I guess 
it's actually modprobe that crashes).
I use modutils 2.3.14, and I got pppox device nodes in my /dev on major 144 
from a different pppox module, a third-party pppoe implementation that was 
partly user and partly kernel based as opposed to the all-kernel 2.4.0 
solution. As everything works fine with test7 I wonder what has changed in 
test9. What could be wrong here? Any ideas?

Thanks,
Mirko
--
Mirko Klemm

[EMAIL PROTECTED]

GPG-Public Key at:
http://www.mutantenzoo.de/mklemm.asc

encrypted messages preferred
-
To unsubscribe from this list: send 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] NE2000

[Jorge Nerin]

Alan Cox wrote:
> 
> > This change sounds ok to me, if noone else objects.  (I added to the CC
> > a bit)  I saw that code, and was thinking about doing the same thing
> > myself.  ne2k-pci.c definitely has changes which are not included in
> > ne.c, and it seems silly to duplicate ne2000 PCI support.
> 
> Unless there are any cards that need the bug workarounds in ne.c for use
> on PCI then I see no problem. I've not heard of any.
> 

Ok, I reported it several times, but it gets ignored. I have a Realtek
8029 (ne2k-pci), and with both drivers ne and ne2k-pci I can easily get
it stuck by doing a ping -f to a host in the local net, and sometimes it
happens doing copies to/from nfs shared resources.

rmmod & insmod don't cure the problem, it seems that no interrupts are
delivered from the card, and there are no log messages, so a reboot is
needed to restore net access.

System is dual 2x200mmx 96Mb ide discs no interrupts shared, and as far
as I can remember all kernel from 2.2.x, 2.3.x up to 2.4.0-testx exhibit
this problem.

-- 
Jorge Nerin
<[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: [patch] NE2000

[Jeff Garzik]

Paul Gortmaker wrote:
> There is no urgency in trying to squeeze a patch like this in the back
> door of a 2.4.0 release.  For example, there are people out there now
> who are using the ne.c driver to run both ISA and PCI cards in the same
> box without having to use 2 different drivers.  We can wait until 2.5.0
> to break their .config file.

IMNSHO this is a bug, though...

Do a diff of the key 8390 interface routines in ne.c, and ne2k-pci.c. 
Ignoring the inb_p and outb_p differences, there are distinct advantages
to using ne2k-pci.c on with an NE2000 PCI board.

Since ne2k-pci.c supports all boards ne.c does, and includes some fixes
that ne.c does not, it seems like removing the PCI support in ne.c is a
bug fix change.

It looks like ne2k-pci.c does need a HZ scaling fixing from ne.c
though...

Jeff



-- 
Jeff Garzik | "Mind if I drive?"  -Sam
Building 1024   | "Not if you don't mind me clawing at the
MandrakeSoft|  dash and shrieking like a cheerleader."
| -Max

--- /g/g/tmp/1  Mon Oct 30 14:22:41 2000
+++ /g/g/tmp/2  Mon Oct 30 14:22:58 2000
@@ -1,60 +1,61 @@
 /* Hard reset the card.  This used to pause for the same period that a
8390 reset command required, but that shouldn't be necessary. */
-
-static void ne_reset_8390(struct net_device *dev)
+static void
+ne2k_pci_reset_8390(struct net_device *dev)
 {
unsigned long reset_start_time = jiffies;
 
-   if (ei_debug > 1)
-   printk(KERN_DEBUG "resetting the 8390 t=%ld...", jiffies);
+   if (debug > 1) printk("%s: Resetting the 8390 t=%ld...",
+ dev->name, jiffies);
 
-   /* DON'T change these to inb_p/outb_p or reset will fail on clones. */
outb(inb(NE_BASE + NE_RESET), NE_BASE + NE_RESET);
 
ei_status.txing = 0;
ei_status.dmaing = 0;
 
/* This check _should_not_ be necessary, omit eventually. */
-   while ((inb_p(NE_BASE+EN0_ISR) & ENISR_RESET) == 0)
-   if (jiffies - reset_start_time > 2*HZ/100) {
-   printk(KERN_WARNING "%s: ne_reset_8390() did not complete.\n", 
dev->name);
+   while ((inb(NE_BASE+EN0_ISR) & ENISR_RESET) == 0)
+   if (jiffies - reset_start_time > 2) {
+   printk("%s: ne2k_pci_reset_8390() did not complete.\n", 
+dev->name);
break;
}
-   outb_p(ENISR_RESET, NE_BASE + EN0_ISR); /* Ack intr. */
+   outb(ENISR_RESET, NE_BASE + EN0_ISR);   /* Ack intr. */
 }
 
 /* Grab the 8390 specific header. Similar to the block_input routine, but
we don't need to be concerned with ring wrap as the header will be at
the start of a page, so we optimize accordingly. */
 
-static void ne_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int 
ring_page)
+static void
+ne2k_pci_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int 
+ring_page)
 {
-   int nic_base = dev->base_addr;
 
-   /* This *shouldn't* happen. If it does, it's the last thing you'll see */
+   long nic_base = dev->base_addr;
 
-   if (ei_status.dmaing) 
-   {
-   printk(KERN_EMERG "%s: DMAing conflict in ne_get_8390_hdr "
+   /* This *shouldn't* happen. If it does, it's the last thing you'll see */
+   if (ei_status.dmaing) {
+   printk("%s: DMAing conflict in ne2k_pci_get_8390_hdr "
"[DMAstat:%d][irqlock:%d].\n",
dev->name, ei_status.dmaing, ei_status.irqlock);
return;
}
 
ei_status.dmaing |= 0x01;
-   outb_p(E8390_NODMA+E8390_PAGE0+E8390_START, nic_base+ NE_CMD);
-   outb_p(sizeof(struct e8390_pkt_hdr), nic_base + EN0_RCNTLO);
-   outb_p(0, nic_base + EN0_RCNTHI);
-   outb_p(0, nic_base + EN0_RSARLO);   /* On page boundary */
-   outb_p(ring_page, nic_base + EN0_RSARHI);
-   outb_p(E8390_RREAD+E8390_START, nic_base + NE_CMD);
+   outb(E8390_NODMA+E8390_PAGE0+E8390_START, nic_base+ NE_CMD);
+   outb(sizeof(struct e8390_pkt_hdr), nic_base + EN0_RCNTLO);
+   outb(0, nic_base + EN0_RCNTHI);
+   outb(0, nic_base + EN0_RSARLO); /* On page boundary */
+   outb(ring_page, nic_base + EN0_RSARHI);
+   outb(E8390_RREAD+E8390_START, nic_base + NE_CMD);
 
-   if (ei_status.word16)
+   if (ei_status.ne2k_flags & ONLY_16BIT_IO) {
insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)>>1);
-   else
-   insb(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr));
+   } else {
+   *(u32*)hdr = le32_to_cpu(inl(NE_BASE + NE_DATAPORT));
+   le16_to_cpus(&hdr->count);
+   }
 
-   outb_p(ENISR_RDC, nic_base + EN0_ISR);  /* Ack intr. */
+   outb(ENISR_RDC, nic_base + EN0_ISR);/* Ack intr. */
ei_status.dmaing &= ~0x01;
 }
 
@@ -63,172 +64,116 @@
The NEx000