Re: PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial

[David Ford]

There was a round of discussion about /proc.../serial back in May.  It
covered corruption and bad addresses.  Although it didn't specifically say
"I'm fixing the segmentation fault that some people are going to report",
they did indeed discuss the bad data, smp locking, and etc precisely on
serial.c.

If a specific problem such as a bad address went away by upgrading, there's a
very strong chance that the bug was fixed.  Such problems aren't likely to
migrate around in the kernel and be hidden, they tend to stay localized.
Instead of searching for a given author's comments, diff the two files and
see if the initializing code changed.  A lot of fixes go in without specific
credits.

-d

David Ciemiewicz wrote:

> Igmar,
>
> Thanks for attempting to validate that the problem is fixed in a
> later release.  However, I still stand by my submission.
>
> If the readers will note, the problem is in 2.2.14 and
> AND in 2.3.5 as referenced by another auther.  It looks like the
> info structure in drivers/char/serial.c:line_info is not sufficiently
> initialized in all cases that might be processed by serial_in()
> for instance, the CONFIG_HUB6 case.  If line_info populates an
> info struct and CONFIG_HUB6 is defined and info->hub6 is
> dereferenced, there may well be garbage in info->hub6.
>
> I've searched the source trees and I don't see any of the fixes
> between 2.2.14 and 2.2.17 referenced by the previous author at
> the end of my original post.
>
> That said, the incompletely initialized "info" structure problem
> exists.  The fact that you and many others may not encountered the
> problem is pure happenstance either because CONFIG_HUB6 was not
> configured or you were lucky enough not to have garbage in any
> of the data structures.
>
> So, if I upgraded to 2.2.17 and the problem went away, that doesn't
> mean the problem doesn't exist, it just means that the problem may
> simply be being masked or has not yet been encountered.
>
> --- Ciemo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard

Re: Ethernet Driver for Built in Network Card

[David Ford]

Craig Whitmore wrote:

> Does anyone know what driver will work with the ethernet card in a New
> Intel motherboard /proc/pci says its ..
> PCI_DEVICE_ID_INTEL_82865
> 0x1227PCI_VENDOR_ID_INTEL   0x8086 But I can't find any
> drivers for this device :-( Its a 820 Motherboard I think.
> ThanksCraig Whitmore

A quick search for "intel i820 network" on google.com yields toms
hardware site which lists the onboard card as a Netgear FA310TX.  Use
the tulip.

As another note, the 8086 ID you provided is also listed in the
tulip/tulip_core.c file.

Use the source Luke :)

-d


--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard

webcam II & kernel compiling

[Joe]

I have 2 questions.

1) Who is working on the webcam II cpia driver.  Under NT I can get 15
to 25 fps, while Linux seems to be limited to 15 max.  Is this a hard
coded value in the lernel somewhere and is there plans for changing
this?  (I know that this is an experimental driver, but rebooting to NT
is just not what I want to do.  8-)

2) I recently read that when upgrading to a new kernel you should not
compile the new kernel in /usr/src/linux .  If I upgrade to a new kernel
what is the 'proper method' and what other program will I need to
recompile to take full advantage of the new kernel?  (the more detail
the better and please email just me and not the kernel list )

--
Joe Acosta 
home: [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/

Ethernet Driver for Built in Network Card

[Craig Whitmore]

Does anyone know what driver will work with the 
ethernet card in a New Intel motherboard
 
/proc/pci says its ..
 
PCI_DEVICE_ID_INTEL_82865   
0x1227
PCI_VENDOR_ID_INTEL   
0x8086
 
But I can't find any drivers for this device 
:-(
 
Its a 820 Motherboard I think.
 
 
 
Thanks
Craig Whitmore
 
 

Re: [PATCH] arch/i386/kernel/acpi.c: get rid of check_region and other small fixes/cleanups

[Arnaldo Carvalho de Melo]

Em Sat, Sep 16, 2000 at 10:49:08PM -0400, Jeff Garzik escreveu:
> Applied, but... :)
> 
> In reviewing your patch, I noticed more ugliness.  Can you be convinced
> to take care of these, too?

yap, I'm adding it to my todo list.
 
> In acpi_init(), it is possible for the function to error exit without
> cleaning up from a successful acpi_claim_ioports call.
> 
> Further, acpi_claim_ioports itself is pretty nasty if some of its
> acpi_claim calls succeed, and others fail.
> 
> We're getting there..

:)

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

PROBLEM: Segmentation fault [SIGSEGV] reading from /proc/tty/driver/serial

[David Ciemiewicz]

Igmar,

Thanks for attempting to validate that the problem is fixed in a
later release.  However, I still stand by my submission.

If the readers will note, the problem is in 2.2.14 and
AND in 2.3.5 as referenced by another auther.  It looks like the
info structure in drivers/char/serial.c:line_info is not sufficiently 
initialized in all cases that might be processed by serial_in()
for instance, the CONFIG_HUB6 case.  If line_info populates an
info struct and CONFIG_HUB6 is defined and info->hub6 is
dereferenced, there may well be garbage in info->hub6.

I've searched the source trees and I don't see any of the fixes
between 2.2.14 and 2.2.17 referenced by the previous author at
the end of my original post.

That said, the incompletely initialized "info" structure problem
exists.  The fact that you and many others may not encountered the
problem is pure happenstance either because CONFIG_HUB6 was not
configured or you were lucky enough not to have garbage in any
of the data structures.

So, if I upgraded to 2.2.17 and the problem went away, that doesn't
mean the problem doesn't exist, it just means that the problem may
simply be being masked or has not yet been encountered.

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

Re: Very aggressive swapping after 2 hours rest

[Albert D. Cahalan]

Rik van Riel writes:

> It would be better to put that in a userspace tool like
> vmstat.
>
> Oh, and now we're talking about vmstat, I guess that
> program also needs support for displaying the number
> of active/inactive_dirty/inactive_clean pages ... ;)
>
> (any volunteers?)

Umm, OK. I suppose that BSD prints this stuff? If so,
somebody please send me an output sample and explanation
so that I know where to put this stuff.


-
To unsubscribe from this list: send 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 VIA 82Cxxx Audio Driver - help

[Gregory Maxwell]

Hi. I've had great success with your VIA 82Cxxx in 2.4test9 on a new
system I'm helping a friend setup for his mom. Unfortunately,  I'm not
having so much luck with the rest of 2.4.

Because of general stability issues, I need to move back to 2.2 on this
system.

However, the VIA 82Cxxx driver in 2.2 (tried Redhat's 2.2.16 RPM as well
as straight 2.2.17+patches) doesn't work with this system. As soon as the
module is loaded the system hard-locks with no errors, sysrq, or network
access.

I tried to get a newer driver, but it appears that all your drivers later
then the 1.2(?, whichever one is in 2.2.17) are made for 2.3+, and I'm
really not up to backporting a driver for a friends system. :P

I'd appreciate any advice or assistance you could provide. Thanks.

It's a new Athlon board. lspci -vvv:

00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
Subsystem: Elitegroup Computer Systems: Unknown device 0979
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 
Capabilities: [c0] Power Management version 2
Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- AuxPwr- DSI- D1+ D2- PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
Subsystem: VIA Technologies, Inc.: Unknown device 
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/

RE: system hang with usb audio driver

[Dunlap, Randy]

> Hi, I have been having problems with the usb audio driver on a set of 
> Philips DSS330. The driver seemed to work properly up until 2.3.99-6.
> The driver included with 2.3.99-6 worked correctly when included with
> kernels up to 2.4.0test6 or so. The current driver (2.4.0test7+) will
> hang my system reliably when I access the audio device. The kernel
> detects the device correctly, the system comes up correctly, I login
> and the system dies when I start up xmms. Is there a newer version of
> the driver than the one in the kernel or usb cvs tree?
> thanks..
>  -nld

Not that I know of.
Which host controller driver are you using?
If it's "uhci", please try "usb-uhci" instead.

~Randy

-
To unsubscribe from this list: send the 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] arch/i386/kernel/acpi.c: get rid of check_region and other small fixes/cleanups

[Jeff Garzik]

Applied, but... :)

In reviewing your patch, I noticed more ugliness.  Can you be convinced
to take care of these, too?

In acpi_init(), it is possible for the function to error exit without
cleaning up from a successful acpi_claim_ioports call.

Further, acpi_claim_ioports itself is pretty nasty if some of its
acpi_claim calls succeed, and others fail.

We're getting there..

Jeff



-- 
Jeff Garzik  | Would you *really* want to
Building 1024| get on a non-stop flight?
MandrakeSoft, Inc.   |   -- George Carlin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [BUG] That bloody /usr/local busy back again

[Matthew Dharm]

I'm seeing something very similar to this on test8 with my root partition.
umount reports device is busy at shutdown.  This is an IDE device.

I'm using a x86 system based on RH6.2 with a few upgrades (modutils, etc).

Matt

On Sun, Sep 17, 2000 at 01:17:11PM -1100, Daniel Stone wrote:
> I haven't had time to test it thoroughly, but I've noticed from about
> test8-preX onwards (latest tested test8) that on shutdown, my /usr/local
> (/dev/ide/host0/bus0/target0/lun0/part6, ReiserFS), is always "busy" - the
> last thing I see in shutdown -r now is:
> "Unmounting filesystems...
> /dev/ide/host0/bus0/target0/lun0/part6 busy, mounting read-only
> Rebooting system..."
> (may not be absolute verbatim, but pretty close).
> 
> I'm using the latest update of Debian 2.3 (Woody). I remember this problem
> sprung up a while ago. *shrug*
> 
> :) d
> 
> --
> Daniel Stone
> Kernel Hacker (or at least has aspirations to be)
> [EMAIL PROTECTED]
> http://dustpuppy.ods.org
> 
> -BEGIN GEEK CODE BLOCK-
> Version: 3.1
> G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K?
> w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G 
> e->++ h!(+) r+(%) y? UF++
> --END GEEK CODE BLOCK--
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

Hey Chief.  We've figured out how to save the technical department.  We 
need to be committed.
-- The Techs
User Friendly, 1/22/1998

 PGP signature

[BUG] That bloody /usr/local busy back again

[Daniel Stone]

I haven't had time to test it thoroughly, but I've noticed from about
test8-preX onwards (latest tested test8) that on shutdown, my /usr/local
(/dev/ide/host0/bus0/target0/lun0/part6, ReiserFS), is always "busy" - the
last thing I see in shutdown -r now is:
"Unmounting filesystems...
/dev/ide/host0/bus0/target0/lun0/part6 busy, mounting read-only
Rebooting system..."
(may not be absolute verbatim, but pretty close).

I'm using the latest update of Debian 2.3 (Woody). I remember this problem
sprung up a while ago. *shrug*

:) d

--
Daniel Stone
Kernel Hacker (or at least has aspirations to be)
[EMAIL PROTECTED]
http://dustpuppy.ods.org

-BEGIN GEEK CODE BLOCK-
Version: 3.1
G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K?
w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G 
e->++ h!(+) r+(%) y? UF++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

smp_num_cpus undeclared compile error in 2.4.0-test8

[Hao Xu]

Hi,

I found a bug on the 2.4.0-test8 release:

I was not able to build linux-2.4.0-test8 on my dual PIII box if I did NOT choose the 
"smp support".

Here is the compile error message:

/usr/src/linux/include/linux/kernel_stat.h:48: `smp_num_cpus' undeclared (first use in 
this function)
/usr/src/linux/include/linux/kernel_stat.h:48: (Each undeclared identifier is reported 
only once
/usr/src/linux/include/linux/kernel_stat.h:48: for each function it appears in.)

I think the simple fix is to check "#ifdef CONFIG_SMP" in this kstat_irq(int) routine.

I could compile the code just fine if I choose the "smp support".

Best regards,

Hao Xu
-
Email: [EMAIL PROTECTED]
Xu Hao homepage: http://www.cs.pdx.edu/~xuhao
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Streams (again)

[Cesar Eduardo Barros]

This is a proposal for a simple way of adding streams support to the Linux
kernel, without significant changes in current Unix-like semantics.

It was inspired by a recent discussion in the #kernelnewbies IRC channel, and
by the recent talk about the subject in the Linux Kernel mailing lists. I did a
first fast design, and took an hour polishing it, simplifying it, and making
sure I covered most of the important cases.

This should be read as a RFC (of which I've been reading maybe too much
lately).

I've included both the polished draft and the informal first draft, since the
informal draft is a bit more explicit in some issues. I changed some things in
the second version (found out I needed one less syscall), so treat the first
version as a informative historical document.

I plan on trying to learn the VFS code to try to implement the proposal if it
is considered good enough to be worth an implementation. Note that I currently
know nothing of the VFS code, so if nobody else wants to implement it it'll
take some months until I'm good enough at it.

-- 
Cesar Eduardo Barros
[EMAIL PROTECTED]
[EMAIL PROTECTED]


Streams design draft, version 0.02


This is a proposal for a simple way of adding streams support to the Linux
kernel, without significant changes in current Unix-like semantics.

It was inspired by a recent discussion in the #kernelnewbies IRC channel, and
by the recent talk about the subject in the Linux Kernel mailing lists. I did a
first fast design, and took an hour polishing it, simplifying it, and making
sure I covered most of the important cases.

This should be read as a RFC (of which I've been reading maybe too much
lately).



Motivation (informative)

Much has been said recently about support for "streams". Streams are defined
here as arbitrary-sized chunks of binary data attached to a file.

The need for support for streams arise from the desire of better support for
legacy filesystems which have them. Some also want to create new filesystems
which explicitly support arbitrary streams.

(long explanation of what they really are inserted here)

A well-defined API is required to avoid every different kernel doing things in
a different way, and to make clear all the allowed and disallowed situations.
That's why I'm submitting this informal Linux Kernel Standard proposal.



Word usage (normative)

(insert standard RFC rant about must/should/may/should not/must not)



Vocabulary (normative)

stream - (insert definition here)

streams directory - the invisible virtual directory associated to a file or
directory. It can contain zero or more streams or streams
subdirectories.

streams subdirectory - a normal directory within a streams directory or streams
   subdirectory

root file - The file associated with a streams directory (and thus with all its
streams subdirectories) and with their streams.

streams hierarchy - The set of all streams, streams directories, streams
subdirectories, symlinks and other things which have the
same root file



Alternate representations (informative)

Some have proposed using the current API and extending it to handle streams.
The methods proposed ranged from the horrible (using :: like some unnamed
operating system does) to the reasonable (trating files as directories in a
open request causing the associate streams to be opened). The problem with all
these proposals is that they confuse the namespaces. One case where it fails is
when you use dumb programs that assume the operating system will return an
error if you try to treat a file as a directory (which is not a dumb idea --
letting the operating system do the checking instead of having to do it every
time by hand).

Most of these alternative approaches are targeted at making a specific
userspace program happy -- the most common targets being cp and tar. My view is
that it should not be needed or, if needed, the C library can handle it, much
like calls like opendir() are.



Streams representation (normative)

Every file has an associated "streams directory". A streams directory (or more
shortly streamsdir) is like a normal directory, except that it's invisible in
normal operation and can only be accessed using the streams API. Directories
can also have an associated streams directory.

Streams directories and subdirectories can only handle normal files and streams
subdirectories. These can also have their own streams, and so on, recursively.
Note that a streams directory MUST NOT have an associated streams directory.
Note that it is allowed to have a streams directory associated with a streams
subdirectory.

Notice that being allowed to do something doesn't mean you have to; be
conservative in what you do and liberal in what you accept. While userspace
programs SHOULD NOT reactly incorrectly when finding deep streams recursion and
streams in directories, it is recommended that filesystem 

Re: CONFIG_VIDEO_BT848 in 2.4.0-test9pre1 missing

[Rui Sousa]

Michael Elizabeth Chastain wrote:
> 
> Hi Dietmar,
> 
> First go to 'General Setup' and make sure that 'PCI support' is turned on.
> 
> Then go to 'Character Devices' -> 'I2C support'.  Turn on both
> 'I2C support' and 'I2C bit-banging interfaces'.
> 
> Then go to 'Multimedia devices'.  Turn on 'Video for Linux' and
> enter the 'Video for Linux' submenu.  Now you can turn on
> 'BT848 Video For Linux'.
> 

I noticed this before and thought it would be nice to have
a new config system statement called, say, "info" which
would show up like this in the menus.

< > Bttv driver. Enable I2C support and I2C bit-banging interfaces
first.


Hmm... Just checked and by the name the "text" statement could probably
be used for this. It's mentioned in the kbuild documentation but
I couldn't find a single instance in the current Config.in
files.


Rui Sousa
-
To unsubscribe from this list: send the 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/sys/vm/freepages not writable.

[davej]

> I compiled kernel 2.4.0test9-pre1 (kernel names are a real mess
> these days ...) and noticed that /proc/sys/vm/freepages is no
> longer writable:
> If this was intentional, why has it changed ?

New VM in test9-pre1.
Changing this field is no longer relevant to the restructured code.

Dave.

-- 
| Dave Jones <[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: SCSI scanning

[Torben Mathiasen]

On Sat, Sep 16 2000, Jan Niehusmann wrote:
> test9-pre1 does not contain a fix for the test8 scsi scanning problem. SCSI
> disks are detected twice if scsi is not compiled as a module. Torben already
> posted a patch.
>

Linus,

The proper way of fixing this is to add #ifdef MODULE around the init
functions or going back to init/exit_module. 
I know it looks ugly, but because of the structure of the 
scsi subsytem this is the only way out besides doing a nasty hack
to scsi.c. And even with the hack, the initialisation functions
will get called twice which is wrong.

I guess the scsi subsystem is in need of an overhaul for 2.5.

Patches have already been sent to you for sd (me) and sr (Jens Axboe).



-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

/proc/sys/vm/freepages not writable.

[Patrick Mau]

Dear kernel-hackers,

I compiled kernel 2.4.0test9-pre1 (kernel names are a real mess
these days ...) and noticed that /proc/sys/vm/freepages is no
longer writable:

[root@oscar] ll /proc/sys/vm/freepages
-r--r--r--1 root root0 Sep 17 02:25 /proc/sys/vm/freepages

If this was intentional, why has it changed ?

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

[PATCH] update to new VM

[Rik van Riel]

Hi Linus,

after increasing the test base, the following 2 problems have
been noticed with the VM patch, and are (hopefully) fixed in
this patch:

1)  if __alloc_pages() is called without __GFP_IO in the
gfp_mask, we cannot wait for kswapd
-> use try_to_free_pages() the oldfashioned way instead
1b) while fixing up the other __GFP_IO problems, I noticed
programs at schedule points in the VM, sleeping in S state,
this is fixed by explicitly making them runnable
2)  the VM was badly balanced for low-memory (8MB) machines,
this has been fixed by making it easier for kswapd to go
to sleep in refill_inactive() and by waking up kswapd earlier
at the top of __alloc_pages()

I'm still not 100% sure if this patch is completely correct,
but it fixes one serious bug in the current VM inside -test9-pre1
and I'm leaving for Linux Kongress tomorrow so this is my last
chance to post anything for the next few days ;(

If this patch proves stable for everyone and makes 8MB machines
workable again with the new VM, please include this in the next
pre-patch. If it doesn't work correctly, I'll somehow find it
in my email while at Linux Kongress and I'll prepare a new fix.

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: Q: sock output serialization

[Andi Kleen]

On Sat, Sep 16, 2000 at 11:39:45PM +0200, Henner Eisen wrote:
> int netif_would_drop(dev)
> {
>   return (queue->input_pkt_queue.qlen > netdev_max_backlog)
>  || ( (queue->input_pkt_queue.qlen) && (queue->throttle) )
> }
> 
> would fulfil those requirements.

It would just be racy. You test, get a not drop and then another different
interrupt would deliver another packet before you can and fill the queue.
Jamal's extended netif_rx probably makes more sense, because it can be 
atomic.


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

Re: An elevator algorithm (patch)

[Peter Osterlund]

Ragnar Kjørstad <[EMAIL PROTECTED]> writes:

> If I understand the current code correctly, it works like this:
[ example deleted ]
> So we've ended up with a very silly queue

Indeed, the elevator logic is somewhat flawed. There are two problems
with the current code:

1. The test that decides if we have found a good spot to insert the
   current request doesn't handle the wraparound case correctly. (The
   case when the elevator reaches the end of the disk and starts over
   from the beginning.)

2. If we can't find a good spot to insert the new request, we
   currently insert it as early as possible in the queue. If no good
   spot is found, it is more efficient and more fair to insert the new
   request last in the queue.

The following patch fixes both problems. Here are the results from
'iozone 100' and Bonnie with and without this patch.

test8:
--

iozone:
4626750 bytes/second for writing the file
7431438 bytes/second for reading the file

bonnie:
  ---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
  100  5278 60.6  7940 18.3  2876  9.7  5635 49.3  8344 16.7 179.3  2.0

test8 + modified elevator:
--

iozone:
4801172 bytes/second for writing the file
7613088 bytes/second for reading the file

bonnie:
  ---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
  100  5727 66.6  8365 18.1  2921  9.2  5991 52.2  8171 16.0 171.0  2.0

Here is the patch:

--- linux-2.4.0-test8/drivers/block/elevator.c.orig Sun Sep 17 00:05:03 2000
+++ linux-2.4.0-test8/drivers/block/elevator.c  Sun Sep 17 00:06:31 2000
@@ -34,20 +34,38 @@
struct list_head *real_head,
struct list_head *head, int orig_latency)
 {
-   struct list_head *entry = real_head;
-   struct request *tmp;
-
-   req->elevator_sequence = orig_latency;
-
-   while ((entry = entry->prev) != head) {
-   tmp = blkdev_entry_to_request(entry);
-   if (IN_ORDER(tmp, req))
-   break;
-   if (!tmp->elevator_sequence)
-   break;
-   tmp->elevator_sequence--;
-   }
-   list_add(>queue, entry);
+   struct list_head *last = real_head->prev;
+   struct list_head *insert_after = last;
+   struct list_head *entry;
+   struct request *tmp1, *tmp2;
+
+   req->elevator_sequence = orig_latency;
+
+   if (last == head)
+   goto out;
+
+   entry = last;
+   tmp1 = blkdev_entry_to_request(entry);
+   do {
+   tmp2 = tmp1;
+   entry = entry->prev;
+   tmp1 = blkdev_entry_to_request(entry);
+   if (!tmp2->elevator_sequence)
+   break;
+   if (IN_ORDER(tmp1, tmp2) ?
+   (IN_ORDER(tmp1, req) && IN_ORDER(req, tmp2)) :
+   (IN_ORDER(tmp1, req) || IN_ORDER(req, tmp2))) {
+   insert_after = entry;
+   do {
+   entry = entry->next;
+   tmp1 = blkdev_entry_to_request(entry);
+   tmp1->elevator_sequence--;
+   } while (entry != last);
+   break;
+   }
+   } while (entry != head);
+out:
+   list_add(>queue, insert_after);
 }
 
 int elevator_linus_merge(request_queue_t *q, struct request **req,


-- 
Peter Österlund  Email: [EMAIL PROTECTED]
Sköndalsvägen 35[EMAIL PROTECTED]
S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919
Sweden   Phone: +46 8 942647

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

Re: [ANNOUNCE] Darkstar Development Project

[Thomas Graichen]

Larry McVoy <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
>> > Err, "faster"?  The following is the moral equiv of 4 kernel updates
>> > which had nothing to do using BitKeeper instead of CVS.  The local copy
>> > was in San Francisco and the remote copy is Cort's machine in New Mexico
>> > over a 384Kbits/sec link.  All 4 updates in 5 seconds.  Anyone have a
>> > CVS tree they can try to get comparable numbers?
>> 
>> Try: http://innominate.org/~tgr/projects/lksr/

> Thanks, that was helpful.  Comparison numbers for a null update of the 2.3
> kernel, which means you update and then update again, timing the second update
> to get some idea of the system's best case throughput, are:

> CVS: 139.5 seconds
> BK:1.6 seconds

> The BK tree is the 2.3 kernel tree maintained by FSMlabs.

larry - this one is a bit unfair i think: the innominate.org tree
runs right now on a 200mhz pentium and is quite a bit worse
connected to you than the bk tree - also it's a "synthetic"
tree which contains for instance 100+ tags in the 2.3
tree which might make it a bit slow too ...

but all that does not mean that bk is bad - haven't had a look at
it so far - i just wanted to say: better avoid such comparisions
- i think the mozilla idea (from some mails later) side by side
will give a much better comparision

t

-- 
[EMAIL PROTECTED]
technical director   innominate AG
clustering & securitynetworking people
tel: +49.30.308806-13  fax: -77   http://innominate.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Q: sock output serialization

[Alan Cox]

> > With the current scheme, lapb first acknowleges reception of the frame
> > and after that, netif_rx() might still discard it -- which is evil.
> 
> This might screw things a bit. Can you defer to say first call
> netif_rx() then acknowledge or is this hard-coded into the f/ware?

I think its fixable to make it do the RR/RNR after bouncing it up the stack.
-
To unsubscribe from this list: send the 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: sock output serialization

[jamal]

Seems all the good network stuff gets discussed on l-k instead ;-<
(hint: some people are not subscribed to l-k)

On Sat, 16 Sep 2000, Henner Eisen wrote:

> 
> What about a function to query the state of the backlog queue?
> 
> Something like
> 
> if(netif_would_drop(dev)){
> kfree_skb(skb);
>   /*optionally,if supported by lapb implementation:*/
>   set_lapb_rx_busy_condition();
>   return; 
> }
> clear_lapb_rx_busy_condition(); /* if supported */
> pass_frame_to_lapb(lapb,skb);
> 
> The key point is that we need to query the backlog queue and
> discard the skb before lapb can acknowledge it. Simply discarding
> it when backlog is known to be congested should be sufficient. It could
> however improve performance if lapb did additionally flow control the peer.


This should be resolved by a patch i am about to submit based on the OLS
talk.
netif_rx() now returns a value which tells you the congestion levels when
you give it a packet (change from void netif_rx())

--- 
/*  return values:
 *  BLG_CNG_NONE(no congestion)   
 *  BLG_CNG_LOW (low congestion) 
 *  BLG_CNG_MOD (moderate congestion)
 *  BLG_CNG_HIGH(high congestion) 
 *  BLG_CNG_DROP(packet was dropped)
 */  
---

> 
> With the current scheme, lapb first acknowleges reception of the frame
> and after that, netif_rx() might still discard it -- which is evil.
> 

This might screw things a bit. Can you defer to say first call
netif_rx() then acknowledge or is this hard-coded into the f/ware?


> Provided that netif_would_drop(dev) is reliable (a subsequent netif_rf will
> reliably not drop the frame), this should make the netif_rx path reliable.
> 
> It seems that, on 2.4.0, something like
> 
> int netif_would_drop(dev)
> {
>   return (queue->input_pkt_queue.qlen > netdev_max_backlog)
>  || ( (queue->input_pkt_queue.qlen) && (queue->throttle) )
> }
> 
> would fulfil those requirements.

I think this would make it a little more complex than necessary; the queue
state might change right after you return from netif_would_drop() -- maybe
not, i am just hypothesizing. 
** You can still create the netif_would_drop() --it just sounds too
expensive to me since to be realy sure no packet of yours is dropped, you
have to make this call for every packet.

If you cant defer the acknowledgement until netif_rx() returns then what
we could do is instead: 

1) for devices that are registered with hardware flow control
==> you have to register as a CONFIG_NET_HW_FLOWCONTROL device.

a) to let them queue that last packet before they are shut-up, the
assumption is they respect the protocol and will 'back-off' after
that. 
b) return BLG_CNG_WOULD_DROP instead to the device and give it the
responsibility to free the skb or store it wherever it wants but not in
the backlog.

I personally prefer a). Reason: If we have done all the work so
far(context switch etc) and we know the device is well behaved(meaning it
is not going to send another packet without beiong told things are fine) 
then it is probably wiser to just let that packet get on the backlog
queue.

cheers,
jamal

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

system hang with usb audio driver

[Narayan Desai]

Hi, I have been having problems with the usb audio driver on a set of 
Philips DSS330. The driver seemed to work properly up until 2.3.99-6.
The driver included with 2.3.99-6 worked correctly when included with
kernels up to 2.4.0test6 or so. The current driver (2.4.0test7+) will
hang my system reliably when I access the audio device. The kernel
detects the device correctly, the system comes up correctly, I login
and the system dies when I start up xmms. Is there a newer version of
the driver than the one in the kernel or usb cvs tree?
thanks..
 -nld
-
To unsubscribe from this list: send the 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: sock output serialization

[Henner Eisen]

Hi,

> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:

>> However, for drivers which support intelligent controllers
>> (with lapb in firmware) this is not an option and the problem
>> will persist.

Alan> 'Smart hardware is broken' repeat .. ;) - but yes its an
Alan> issue there. These cards could bypass netif_rx and call
Alan> directly to the lapb top end though ?

What about a function to query the state of the backlog queue?

Something like

if(netif_would_drop(dev)){
kfree_skb(skb);
/*optionally,if supported by lapb implementation:*/
set_lapb_rx_busy_condition();
return; 
}
clear_lapb_rx_busy_condition(); /* if supported */
pass_frame_to_lapb(lapb,skb);

The key point is that we need to query the backlog queue and
discard the skb before lapb can acknowledge it. Simply discarding
it when backlog is known to be congested should be sufficient. It could
however improve performance if lapb did additionally flow control the peer.

With the current scheme, lapb first acknowleges reception of the frame
and after that, netif_rx() might still discard it -- which is evil.

Provided that netif_would_drop(dev) is reliable (a subsequent netif_rf will
reliably not drop the frame), this should make the netif_rx path reliable.

It seems that, on 2.4.0, something like

int netif_would_drop(dev)
{
return (queue->input_pkt_queue.qlen > netdev_max_backlog)
   || ( (queue->input_pkt_queue.qlen) && (queue->throttle) )
}

would fulfil those requirements.

Henner
-
To unsubscribe from this list: send the 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: sock output serialization

[Henner Eisen]

Hi,

> "kuznet" == kuznet  <[EMAIL PROTECTED]> writes:

kuznet> Hello!
>> scheduler may re-order frames

kuznet> It cannot, provided sender holds order until
kuznet> dev_queue_xmit().

But if I set different skb->priority? ;) Well that would be my fault than .. 

>> or drop them.

kuznet> Yes. And if you share _single_ device both for reliable
kuznet> and unreliable services, you have to make special tricks.

Well, I think this problem will not occur. For shared service, we
will use a datalink protocol running above netif. (e.g. mixed X.25
and IP over ethernet where X.25 runs on top of 802.2 LLC.2 which
will be implemented above netif). And for smart (firmware lapb)
interfaces, which are the real problem, we won´t need to support
shared service.

>> be fixed by providing a special LAPB network scheduler which
>> takes care about preserving reliable LAPB semantics.

kuznet> Yes. ATM CLIP already does this, look at atm clip.c and
kuznet> sch_atm.c to get an example.

Yes. But the above seems to be a network scheduler specialized
for passing IP down to an ATM tunnel. What I had in mind would
correspond to a special scheduler for an atm net_device (but ATM
does not use stadard linux net_device).   

>> that value before calling netif_rx().  Then upper layer´s
>> worried about netif_rx() re-ordering can detect this and act
>> appropriately.
kuznet> etc.

kuznet> No!

kuznet> In fact, it is mathematical fact, that as soon as order is
kuznet> broken once it is _impossible_ to restore it back. No
kuznet> valid actions are invented to do this f.e. for TCP.

Agreed.

kuznet> Though with lapb the situation is different: it cannot
kuznet> lose frames, this changes the situation.

Unfortunatly, the netif_rx might still loose frames, and its concurrent
netif_rx() which re-orders the frames. Thus, we cannot take advantage
of reliable LAPB below netif_rx when packet loss and re-ordering occured
above netif_rx().

kuznet> In any case, order must not be broken, if it is
kuznet> essential. That's answer.

I see. Apparently, IRQ affinity seems the only simple and cheep
solution the re-ordering problem.

Henner

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

boot sequence in linux

[Tulika Pradhan]

i would like to boot linux (ported for a ppc based board) from
ROM. This is how i think the booting should happen -

Code in ROM should contain -
- crt0.S (entry point in ROM code)
- head.S (something like what is there is arch/ppc/boot/head.S)
- other files containing code to download and decompress the vmlinux
  image in RAM.

finally, when the vmlinux.bin.gz is decompressed and we jump to it, the 
entry
point is arch/ppc/kernel/head.S
is this correct ?

regards,

tulika
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

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

Re: 2.4.0-test8 tried to kill init! (addendum)

[Nils Faerber]

On Sat, 16 Sep 2000, Harley Anderson wrote:
> > This sounds like either some bit errors in memory
> > (memtest86 will find those), or a device driver
> > scribbling over memory, or the memory not being
> > refreshed or operated at the right speed (memory
> > to slow for the speed you're running it at?)...
> Hmm, Andrew just informed me that the rtl8139 driver in test8 is pretty nasty. 
> Does that sound like a probable suspect?
> The card itself hasn't talked to anything in a few days, is it likely to mess
> with memory if it isn't doing anything?
Even it is just of minor help I might add that I also see freezes and panics
with test8 on my machine which also carries a rtl8139 board (running with
100MBit connection). And definitely have no memory problem whatsoever (since
every kernel before was and _is_ stable).
CU
   nils faerber

-- 
kernel concepts
Engel & Faerber GbR  Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen  D1 : +49-170-2729106
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Tailmerging for Ext2 - release 0.0

[Daniel Phillips]

Here we are, finally: code.  I do not make any claim that this code is
elegant, correct, complete, esthetically pleasing or that it will
refrain from eating your hard disk.

What this code will do is let you verify for yourself whether my
proposed approach to tailmerging for Ext2 is worth the effort.  After
you build the mrg2 module you can go around and test various
partitions to see how much safe you would save with this tailmerging
approach:

  mount /dev/hda9 /try-me -t mrg2 -o tails=tell

This is non-invasive, i.e., it doesn't write to the partition.  I
think.  :-)

I've tried this a few times myself and gotten some pretty impressive
results: 14 percent of data blocks saved for the linux source tree and
30% saved for the mozilla tree.  Even better is what it does to
worst-case disk wastage.  With no special handling of tail blocks Ext2
is quite capable of wasting 99.9% of your disk space in the worst
case.  With this tailmerging algorithm the worst case improves to
about 50% wastage... much, much, better.  Keep in mind it's not just
space savings at stake here - fewer blocks to read means less time
spent reading them.  The question is: what is the bottom line
performance impact?  I just don't know yet.  Please help me and try
the code.  Even better, *read the code* then try it.

This code has been tested far less than it should have been. 
Basically, I tried a few test cases and fixed the obvious bugs that
came up, then zipped it and shipped it out.  The merge/unmerge code is
a little more tested than the file operations code.  There is one
thing you can be sure of: this is not thread safe.  Yet.  I'll look at
those issues next week.

And when this code is working perfectly it will still only be version
0.4.  Version 0.5 is the first version that will do incremental
tail merging, i.e., actually be useful.  I'm thinking now about
algorithms and data structures for that because I think the first half
of this problem is pretty well licked.  Please, you be the judge of
that.

Let me put in one more plug here.  There is some urgency to this
tailmerging stuff because the trend is towards bigger and bigger
filesystem block sizes,  Bigger blocks sizes means more potential
wastage of space in tail blocks.  We really need the bigger blocks so
we can have bigger filesystems and faster I/O transfers, but the tail
fragmentation problem has to be solved before we can head much further
in that direction.

And finally, some credits: thanks to Hans Reiser for giving me the
idea to do this, to Stephen Tweedie for a timely push in the right
direction, Chris Mason for his war stories and helpful suggestions,
and Al Viro for keeping a watchful eye out for dragon attacks.

The patch is here:

  http://innominate.org/~phillips/tailmerge.0.0.zip

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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[James Sutherland]

On Sat, 16 Sep 2000, Giuliano Pochini wrote:

> I wrote, then got air-brushed out of the thread?!
> > That's one approach; I prefer my "weighted scoring" approach. Supposing we
> > have three devices: a solid state disk (instant "seeks"), a hard drive and
> > a tape. The SSD will benefit from merges (fewer commands to process), but
> > not hugely - set both the metrics at 1, so a 64Kb request is just under
> > twice the "cost" of a 32Kb one. The hard drive can seek fairly quickly,
> > but long reads are preferable - say, seek_cost = 16, block_cost = 1. A
> > single 64Kb request is "cheaper" than a pair of 32Kb requests, but not
> > hugely so. Then the tape: seeks can take a few minutes, so make it
> > seek_cost = 65536, block_cost = 1: we don't really care how much is being
> > read, within reason, since seeks are so "expensive".
> 
> If we could read by a SCSI command the maximun/typical/minimum seek and
> transfer speed directly from the drive things were a lot simpler :))

We can almost do that with any device; if we have a nice interface for
user-space tuning (a few /proc files), we can be told at boot-time what
the characteristics of each device are. A simple piece of code which does
a couple of seeks and a big read or two on each device would achieve this
easily enough.

We don't need to know the exact characteristics, but it could be of some
use in fine-tuning performance; my overall approach should work reasonably
well for any given device, I think?


James.

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

Re: Attempting to mount Zip causes floppy access (2.2.16)

[Andries Brouwer]

On Sat, Sep 16, 2000 at 11:35:24AM +0100, Nick Holloway wrote:

> I have a zip disk which I attempted to mount using the following fstab
> entry:
> 
> /dev/sda4 /zip vfat noauto,nodev,nosuid,user
> 
> This caused a spew of "bread failed" errors, and the mount process ended
> up blocked in "wait_on_buffer".  I thought at first that Zip disk had
> gone to silicon heaven.
> 
> After rebooting, I had a look at the kernel messages, and was _amazed_ to
> see the following:
> 
> SCSI device sda: hdwr sector= 512 bytes.
> Sectors= 196608 [96 MB] [0.1 GB]
> sda: Write Protect is off
>  sda: sda1 sda2 sda3 sda4
> floppy0: disk absent or changed during operation
> end_request: I/O error, dev 02:00 (floppy), sector 1
> bread in fat_access failed
> [...]
> 
> There are two questions.  Firstly, why did the mount process get stuck
> in the kernel, and secondly (and more importantly) what was it doing
> accessing "/dev/fd0"?

Does that follow? Maybe the floppy I/O error occurred at some other
time, or for some other reason. Can you reproduce access of device 02:00
using mount /dev/sda4?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test9-pre1 hang when loading scsi-ide cdrom

[Frank van de Pol]

On Sat, Sep 16, 2000 at 09:04:55PM +0200, Kenneth Johansson wrote:
> 
> If it worked for you in test8 the only thing that changed is that in sr.c the
> init_sr() function been maked with __init and the exit_sr() with __exit. You
> could test removing them (__init and __exit that is not the function) it should
> not matter but it's all I could find :(

I'll give it a try. 

Previous version I tried was test7. Didn't run test8 because it gave some
compilation error (which have been fixed in the test9-pre1 :-)

> 
> By the way it works for me and I compile sr as a module mybe you don't ?
I'm compiling it as module too. This ide-scsi driver the 2nd scsi host, 1st
one is a AHA-2940UW (aic-7xxx). 

Frank.


-- 
+ --- -- -  -   -- 
|Frank van de Pol  -o)
| [EMAIL PROTECTED]   /\\
| _\_v
|Linux - Why use Windows, since there is a door?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RAID HW Questions...

[Ricky Beam]

On Sat, 16 Sep 2000, Bryan Whitehead wrote:
>> Have you bothered tell us what that error is?  I've not seen anything on
>> dpt's mail-list. (Which is where this should be discussed.)
>
>I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to
>do for help) MANY times pleading for help. i asked for Phone#'s, web
>pages, ftp sites, and yes email lists. I've yet to get a reply in 6 months
>of asking.

Gez, Adaptec has made a fscking mess out of this -- I knew those *sses would.

>> Yes they do.  You just are talking to the right people.  (Maybe those "right
>> people" aren't there anymore.  DPT is now an Adaptec company, remember.)
>
>If I can call and email for 6 months and never get a reply that means they
>DON'T care in my book.

([EMAIL PROTECTED] is the mail list, btw)

The people I talked to in April:
"Salyzyn, Mark" <[EMAIL PROTECTED]>
"Tran, Huy" <[EMAIL PROTECTED]>

At the time, they had someone "starting on monday" to handle the linux
driver.  I guess they never made it to work that Monday :-)

>> I'm the one who made it work at 2.3.33... I sent those changes to DPT and
>> mailed several lists.
>> 
>> (http://chickenboo.bluetopia.net/~jfbeam/DPT/)
>
>Great! What about 2.2.17? ot 2.4.0(test) ? I really don't care much
>about 2.3.33. 

I don't run 2.2.  And I showed you the driver (that very 2.3.33 driver)
running on 2.4.0-test...  I've put a README in there to deal with alot
of these questions (and I knew you where gonna bitch about it being 2.3.33)

Why are people always to inflexable as to require everything to match up
atom to atom (bit for bit) before they will try anything?  Did you look
at the patches at all?  They hardly touch the kernel sources at all.  The
changes necessary are to the dpt_i2o driver itself.

As I've stated in the README, I do not have explicit permission to distribute
their driver.

>Vendor: DPT Model: PM2554U2 Rev: 211D, scsi 1:

First, get the latest firmware (I have no clue where adaptec might have
hidden them.)

>Q:  When attempting to compile my kernel, I am getting lots
>of error such as:
>   drivers/scsi/scsi.a(dpt_i2o.o): In function `dpt_add_timer':
>   dpt_i2o.o(.text+0x10): undefined reference to
>   `del_timer_Rsmp_5811f067'
>A:  This is an error seen when using a compiler newer than gcc 2.7.2.  Use 
>   gcc 2.7.2 or older.

Right.  This is caused by the compiler... *cough*bullshit*cough*.  Either
del_timer isn't exported or the dpt driver didn't load the right include
file.  I'll go play with 2.2.17 later. (Some companies have a negative
clue level.)

>Another wierd thing is even though they have a "patch" for this card they
>give instructions to manually edit it a .h file they forgot to include.

See above about "clue".

--Ricky

PS: Ignore the mis-information from Adaptec/DPT.  If you're as smart as you
should be, you can fix this yourself (assuming you know much about the
linux kernel and how it gets built.)


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

Re: RAID HW Questions...

[Alan Cox]

> One of the primary reasons for use the DPT driver is to use the DPT RAID
> mananger.  The Linux I2O code doesn't (currently) have that support.  It
> could be added later, but someone's got to get the card to work with the

DPT don't do standard I2O block management. Linux supports the standard stuff
including configuring your raid card with a web browser


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

Re: folk: no more resource available

[Alan Cox]

> How can I run more that 500 process ? is there any
> /proc to change or is the hard limitation of kernel
> 2.2.x ? 

Edit include/linux/tasks.h

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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Giuliano Pochini]

> The current HUGE queue size is probably another reason for
> the very bad latencies we sometimes see...

Yes, but if the queue is short processes are likely to remain
blocked in D state for more time and the chances to merge rq
are smaller.
IMHO we should add a way to give priority to rqs from live
tasks. i.e. a "cp" usually puts stuff on the queue and then
exits. There's no need to service that i/o immediately.

> > I don't think you should allow merges. If one process is doing a big
> > IO operation on a big file it would still get _all_ capacity, right?
>
> Only if you were to allow unlimited merges ;)
>
> I guess a 'decent' maximum size for one request would
> be somewhere around 256kB, since this is the amount of
> data a drive can read in the time of one disk seek...

Today's HDs transfer rates of 10+MB/s are not uncommon. 256KB is a bit
too small IMHO. SCSI discs that don't support TQ (e.g. quantum) get a
performance hit.

Bye.


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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Giuliano Pochini]

> That's one approach; I prefer my "weighted scoring" approach. Supposing we
> have three devices: a solid state disk (instant "seeks"), a hard drive and
> a tape. The SSD will benefit from merges (fewer commands to process), but
> not hugely - set both the metrics at 1, so a 64Kb request is just under
> twice the "cost" of a 32Kb one. The hard drive can seek fairly quickly,
> but long reads are preferable - say, seek_cost = 16, block_cost = 1. A
> single 64Kb request is "cheaper" than a pair of 32Kb requests, but not
> hugely so. Then the tape: seeks can take a few minutes, so make it
> seek_cost = 65536, block_cost = 1: we don't really care how much is being
> read, within reason, since seeks are so "expensive".

If we could read by a SCSI command the maximun/typical/minimum seek and
transfer speed directly from the drive things were a lot simpler :))

Bye.

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

Re: insmod failure in kernel-2.2.14

[Alan Cox]

> i wrote a simple module to just printk a a message and tried to insmod it,
> but
> it gave error message: resource/device busy (EBUSY)
> but the message gets printed in /var/log/messages

Compile it with -Wall and you should see why
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RAID HW Questions...

[Bryan Whitehead]

On Sat, 16 Sep 2000, Ricky Beam wrote:

> This is true of _any_ binary module.  That's why I never use binary modules.

That's why I don't want to use them either.

> Have you bothered tell us what that error is?  I've not seen anything on
> dpt's mail-list. (Which is where this should be discussed.)

I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to
do for help) MANY times pleading for help. i asked for Phone#'s, web
pages, ftp sites, and yes email lists. I've yet to get a reply in 6 months
of asking.
 
> Yes they do.  You just are talking to the right people.  (Maybe those "right
> people" aren't there anymore.  DPT is now an Adaptec company, remember.)

If I can call and email for 6 months and never get a reply that means they
DON'T care in my book.

> Point of fact: There _are_ people using >2.2.12 with the DPT driver.
> Point of fact: There _are_ people usin 2.4 with the DPT driver.

You know what? I REALLY hope I'm wrong. I really do. I hope it was sitting
in front of me the whole time. Please please please tell me where I can
get it. (and 2.2.12 isn't good enough).

> I'm the one who made it work at 2.3.33... I sent those changes to DPT and
> mailed several lists.
> 
> (http://chickenboo.bluetopia.net/~jfbeam/DPT/)

Great! What about 2.2.17? ot 2.4.0(test) ? I really don't care much
about 2.3.33. 

> For starters, you can tell us exactly what the hell your problem is.  Blow
> off all the steam you want, but no one can help you until you tell us your
> specific problem.

He's something to start on: If you want full build logs let me know. They
may take awile to get. (I'd rather not work on the weekend).
I have 2 systems. one in production, one just sitting around
for me to mess with. They both have the same exact software. I'll
show the current configuration from the production machine using
the binary drivers from DPT.

BTW this is where I got the drivers:
ftp://ftp.adaptec.com/raid/dpt/SRV/software/drivers/linux/
here is my sysinfo (same as what you put out).
uname -a
Linux www.rccacm.org 2.2.5-22smp #1 SMP Wed Jun 2 09:11:51 EDT 1999 i686
unknown
gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
cat /proc/scsi/dpt/1 
Vendor: DPT Model: PM2554U2 Rev: 211D, scsi 1:

DPT I2O Driver Version: 1.06/1.1:

cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 0
sg_tablesize = 39, irq = 18, OutstandingMsgs = 0
maxfromiopmsgs = 64, maxtoiopmsgs = 210

Devices:
Channel = 0, Target = 1, Lun = 0
cat /proc/scsi/scsi
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: QUANTUM  Model: ATLAS IV 9 WLS   Rev: 0808
Type:   Direct-AccessANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: DPT  Model: RAID-5   Rev: 211D
Type:   Direct-AccessANSI SCSI revision: 02

Now for the Building. This is using 2.2.17 Kernel. The errors are the same
for the previous Kernels as well. I patched in the 109patch.gz file found
in the FTP site I gave you. (As it's stated to do in the readme - you neet
to d/l dpti2olinux.zip to get the linuxi2oreadme.txt). At the very end of
the .txt file it states a error I *might* get. i get that one. This is
what it says:
Q:  When attempting to compile my kernel, I am getting lots
of error such as:
drivers/scsi/scsi.a(dpt_i2o.o): In function `dpt_add_timer':
dpt_i2o.o(.text+0x10): undefined reference to
`del_timer_Rsmp_5811f067'
A:  This is an error seen when using a compiler newer than gcc 2.7.2.  Use 
gcc 2.7.2 or older.

I've used gcc 2.7.2 and get the same results. :(

Another wierd thing is even though they have a "patch" for this card they
give instructions to manually edit it a .h file they forgot to include.



-- 
---
Bryan Whitehead
Email: [EMAIL PROTECTED]
WorkE: [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: insmod failure in kernel-2.2.14

[Christoph Hellwig]

In article <[EMAIL PROTECTED]> you wrote:
> i am using kernel-2.2.14-5.0,
> i wrote a simple module to just printk a a message and tried to insmod it,
> but
> it gave error message: resource/device busy (EBUSY)
> but the message gets printed in /var/log/messages

> the code is:
> --
> #define MODULE
> #include
> int init_module(void)
> {
>  printk("this is amodule");

add 'return 0' here

> }
> void cleanup_module(void)
> {
>  printk("removing the module");
> }

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: test9-pre1 hang when loading scsi-ide cdrom

[Kenneth Johansson]

Frank van de Pol wrote:

> Just experienced a (reproducable) hang of the system when loading the
> drivers for my cdrom drives. (ide-cd and ide-scsi). System freezes
> completely; interupts / alt-sysreq is still working.
>

...

>
> It appears to me that something breaks during the init/registration of these
> devices. Any hint/tips to pinpoint the problem?
>

If it worked for you in test8 the only thing that changed is that in sr.c the
init_sr() function been maked with __init and the exit_sr() with __exit. You
could test removing them (__init and __exit that is not the function) it should
not matter but it's all I could find :(

By the way it works for me and I compile sr as a module mybe you don't ?


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

Re: NFS locking bug -- limited mtime resolution means nfs_lock()does not provide coherency guarantee

[Linus Torvalds]

On 16 Sep 2000, Trond Myklebust wrote:
> 
> Yes. fs/read_write calls the NFS subsystem. The problem then is that
> NFS uses the generic_file_{read,write,mmap}() interfaces. These are
> what enforce use of the page cache.
> 
> You could drop these functions, but that would mean designing an
> entire VFS for NFS's use alone. Such a decision would have to be very
> well motivated in order to convince Linus.

Ehh..

I would say that such a decision would be stupid beyond belief, and
impossible to motivate.

NFS certainly doesn't _have_ to use the page cache. However, not using the
page cache would basically in the end be equivalent to 
 (a) not having coherent mmap's over NFS
 (b) probably having much weaker caching
neither of which is really an option at all, I suspect.

You could do caching on your own, but I dare anybody to come up with a
better cache that is able to handle mmap and read/write coherency.

The page granularity issues come from mmap, not from the page cache per
se. ANYTHING that solves the coherency issue is pretty much bound by the
limitations of a page-cache-like thing - they are not limitations of the
implementation, but limitations pretty much inherent to the problem
itself.

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: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> >Flush
>> 
>> What is so shocking about flushing away the cache for a
>> write-protected floppy?
>
>Erm... The fact that final close() will do it anyway?

Well it shouldn't, that would be a useless performance hit.

> Oh, and the fact
>that we have a generic ioctl() doing the same.

This is interesting.  Could you supply some details, so I can add
support for it to the floppy driver?

>> > *PRM and FDTWADDLE - why
>> >not? That leaves FDRAWCMD, FDRESET and FDEJECT. Looks like controller
>> >commands for me...
>> 
>> What do you mean by "controller" commands?  Personnally, I'd find it
>> extremely bizarre to read a disk using sysctl or /proc/floppy/rawcmd
>
>How about /dev/fd0ctl? I also find use of sysctl() an extremely bizarre
>way to read the disk. The thing being, ioctl() is not better. Dunno about
>you, but I prefer to use read() for reading...

Why do we suddenly have to change the structure of the floppy API,
after it worked flawlessly for years? What will be next? Will we
suddenly need a /dev/cdromplay in addition to /dev/cdrom just because
you don't understand some of Jens' code, but are too proud to ask (or
too lazy to browse /usr/src/linux/CREDITS)?  This is getting
ridiculous...

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

Re: folk: no more resource available

[Rik van Riel]

On Sat, 16 Sep 2000, octave klaba wrote:

> Running on 2.2.17 / raid-soft (piii600/512ram) I have the
> problems with the number of process. When ps auxw | wc -l
> is more than 500 process no command works and all I get is
> folk: no more resource available.
> 
> How can I run more that 500 process ? is there any
> /proc to change or is the hard limitation of kernel
> 2.2.x ? 

Edit include/linux/threads.h and increase the maximum
number processes...

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/

[PATCH 2.4.0.9.1] Re: sisfb compile error (2.4.0-test8)

[Jeff Garzik]

This patch should fix sisfb the right way...  You don't want to define
...LINUXBIOS for normal situations..

Jeff



-- 
Jeff Garzik  | Would you *really* want to
Building 1024| get on a non-stop flight?
MandrakeSoft, Inc.   |   -- George Carlin

Index: drivers/video/sisfb.c
===
RCS file: /g/cvslan/linux_2_3/drivers/video/sisfb.c,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 sisfb.c
--- drivers/video/sisfb.c   2000/09/05 03:41:24 1.1.1.8
+++ drivers/video/sisfb.c   2000/09/16 19:01:14
@@ -356,8 +356,6 @@
0x0B, 0x0C, 0x0D, 0x0F, 0x10
 };
 
-#ifdef CONFIG_FB_SIS_LINUXBIOS
-
 #define Monitor1Sense 0x20
 
 unsigned char SRegsInit[] = { 
@@ -371,6 +369,8 @@
0x8e, 0x40, 0x00, 0x00, 0x08, 0x00, 0xff, 0xff
 };
 
+#ifdef CONFIG_FB_SIS_LINUXBIOS
+
 unsigned char SRegs[] = { 
0x03, 0x01, 0x0F, 0x00, 0x0E, 0xA1, 0x02, 0x13,
0x3F, 0x86, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00,
@@ -1440,7 +1440,6 @@
 
 static u16 get_modeID_length(unsigned long ROMAddr, u16 ModeNo)
 {
-   unsigned char ModeID;
u16 modeidlength;
u16 usModeIDOffset;
unsigned short PreviousWord,CurrentWord;

folk: no more resource available

[octave klaba]

Hi,
Running on 2.2.17 / raid-soft (piii600/512ram) I have the
problems with the number of process. When ps auxw | wc -l
is more than 500 process no command works and all I get is
folk: no more resource available.

How can I run more that 500 process ? is there any
/proc to change or is the hard limitation of kernel
2.2.x ? 

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> >You know, I have nothing against having it that way for CDs and Zips.
> >And you have an interesting idea of old-fashioned - I'ld say that
> >echo(1) was in place way before ioctl(2)...
> 
> You're right, echo is indeed older than ioctl.  However, ioctl is
> older than /proc, or odd character pseudo-devices that are used solely
> for control.

/proc - sure, but character devices? That's funny, because I distinctly
remember using write() for control of TTY in v7. Stuff like color, etc.
If it's not "solely for control"... Oh, OK - not solely, you have the
control and data streams mixed. And that's better which way?

> The point is not to do "do permissions of time of open", but rather to
> "do permissions independantly of open mode".

Exactly. Sorry for bad English - that's precisely what I meant. Can you
show me another example of such thing?

> If you still find the permission(inode,2) thing so ugly, I could move
> it from open() to fd_ioctl().

No, thanks. That would be even more weird.

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Alan Cox]

> I'm not a Linux kernel literate. However, I found your
> assertion surprising. Does procfs do page i/o as well?

No. An fs isnt required to use the page caches at all. It makes life a lot saner
to do so

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

Re: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> 
> > I'd like to be able to use that extra 16mb for process memory more than I would
> > for cache. When most of my programs get loaded up, it totals to around 24mb on
> > average, and medium-to-low disk access is used. I like the way it is now, where
> > it won't start swapping unless a process starts eating up memory quickly, or a
> > process starts to do a lot of disk access.
> 
> I do agree that processes that start up and never get 'touched'
> again should definitely get swapped out, but only when system
> ram is nearing the low point. At this point, processes who
> haven't used memory the longest should get swapped.

This is one of the things I'm thinking about at the moment.
Doing something like this should make the VM run a bit more
smooth at the moment the system would have just started
swapping, and the "kick in" of swap wouldn't be as sudden
as it is now.

> Also, one other thing I noticed (in the old VM, haven't noticed
> it on my 32mb machine yet) is that when processes get swapped
> out, doing a 'ps -aux' prints the SWAP values correctly as '0'.
> But doing a consecutive 'ps' shows these processes as '4'. Is
> there something new in recent kernels that getting process
> states actually has to access a page of the process's RAM? Just
> curious.

Shared glibc pages which are still in active use by other
processes aren't swapped out. As long as somebody is still
using this page actively we won't swap it out anyway, so
we might as well keep it mapped in the page table of every
process which references it ...

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/

[PATCH] Fix floppy ioctls, REVISED edition

[Alain Knaff]

The following patch (against 2.4.0-test8) restores floppy ioctl functionality,
which has been broken in 2.4.0-test6-pre7. It now tests for fake
ioctl's, so their should be no interaction with read-only mounts:

--- 2.4.0-test8/linux/drivers/block/floppy.cMon Sep 11 20:09:28 2000
+++ linux/drivers/block/floppy.cSat Sep 16 18:57:14 2000
@@ -3435,6 +3435,7 @@
 static int fd_ioctl(struct inode *inode, struct file *filp, unsigned int cmd,
unsigned long param)
 {
+#define FD_IOCTL_ALLOWED ((filp) && (filp)->private_data)
 #define OUT(c,x) case c: outparam = (const char *) (x); break
 #define IN(c,x,tag) case c: *(x) = inparam. tag ; return 0
 
@@ -3502,7 +3503,7 @@
return -EINVAL;
 
/* permission checks */
-   if (((cmd & 0x40) && !(filp->f_mode & 2)) ||
+   if (((cmd & 0x40) && !FD_IOCTL_ALLOWED) ||
((cmd & 0x80) && !capable(CAP_SYS_ADMIN)))
return -EPERM;
 
@@ -3708,6 +3709,8 @@
return -EIO;
}
 
+   filp->private_data = (void*) 0;
+
drive = DRIVE(inode->i_rdev);
if (drive >= N_DRIVE ||
!(allowed_drive_mask & (1 << drive)) ||
@@ -3774,6 +3777,13 @@
buffer_track = -1;
invalidate_buffers(MKDEV(FLOPPY_MAJOR,old_dev));
}
+
+   /* Allow ioctls if we have write-permissions even if read-only open.
+* Needed so that programs such as fdrawcmd still can work on write
+* protected disks */
+   if ((filp->f_mode & 2) || 
+   (inode->i_sb && (permission(inode,2) == 0)))
+   filp->private_data = (void*) 8;
 
if (UFDCS->rawcmd == 1)
UFDCS->rawcmd = 2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RAID HW Questions...

[Ricky Beam]

On Sat, 16 Sep 2000, Bryan Whitehead wrote:
>> The driver should be on DPT's site. Im not sure on the current state with the

(The driver _IS_ on DPT's site.  It always has been.)

>The driver directory is on thier web site. true. But it only works for
>specific versions of kernel's from RH. They do have the sources available

This is true of _any_ binary module.  That's why I never use binary modules.

>also. The problem comes when compiling. They specifically say not to use
>Linux's i2o stuff. Fine. They claim they have their "own" i2o
>implementaion. But it won't build, actually it won;t link. After looking
>at the FAQ more they say I need to build with gcc version 2.7.2. Becasue
>their driver only works with that. So i remove the gcc from my system and
>install an old gcc / linker. no change. Still the same damn error.

Have you bothered tell us what that error is?  I've not seen anything on
dpt's mail-list. (Which is where this should be discussed.)

>not like I'm some stupid moron (i wish that were the case then I'd be able
...
>development for Mission and Control for NASA's Deep Space network. So i'm
(you aren't inspiring any confidence here...)

>I need to have at LEAST 2.2.16 for security resons. But they don't give a
>crap.

Yes they do.  You just are talking to the right people.  (Maybe those "right
people" aren't there anymore.  DPT is now an Adaptec company, remember.)

>If Linux can get the card working with they native i2o drivers then
>great.

One of the primary reasons for use the DPT driver is to use the DPT RAID
mananger.  The Linux I2O code doesn't (currently) have that support.  It
could be added later, but someone's got to get the card to work with the
existing I2O code. (And I'll add the standard warning about SCSI card
HW RAID solutions... all of them require mucking about with the SCSI core
to prevent command timeouts.  In the case of the DPT card, it can take over
2 MINUTES to signal command completion -- my card will queue 210 commands
in an instant.)


>I'm to the point I don't mind blowing another $10,000 in taxpayers money
>to get the fsck'n RAID working in 2.2.17 land and hopefully 2.4 soon.

Point of fact: There _are_ people using >2.2.12 with the DPT driver.
Point of fact: There _are_ people usin 2.4 with the DPT driver.

I'm the one who made it work at 2.3.33... I sent those changes to DPT and
mailed several lists.

(http://chickenboo.bluetopia.net/~jfbeam/DPT/)

[jfbeam:pts/0]chickenboo:~/[2:05pm]:uname -a
Linux chickenboo 2.4.0-test5-SMP #13 SMP Thu Aug 24 16:23:36 EDT 2000 i686 unknown

[jfbeam:pts/0]chickenboo:~/[2:05pm]:gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

[jfbeam:pts/0]chickenboo:~/[2:10pm]:cat /proc/scsi/dpt_i2o/0 
Vendor: DPT Model: PM1554U2 Rev: 3013, scsi 0:

DPT I2O Driver Version: 1.09.1-cramer/1.2:

cmd_per_lun = 210, max_id = 15, max_lun = 7, max_channel = 1
sg_tablesize = 39, irq = 16, OutstandingMsgs = 0
maxfromiopmsgs = 64, maxtoiopmsgs = 210

Devices:
Channel = 0, Target = 0, Lun = 0
Channel = 1, Target = 4, Lun = 0

[jfbeam:pts/0]chickenboo:~/[2:11pm]:cat /proc/scsi/scsi
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: DPT  Model: CHICKENBOO   Rev: 3013
  Type:   Direct-AccessANSI SCSI revision: 02
Host: scsi0 Channel: 01 Id: 04 Lun: 00
  Vendor: SONY Model: SDT-1Rev: 0101
  Type:   Sequential-AccessANSI SCSI revision: 02

It's currently booting from that controller.  The driver also works as a
module.

>All I gatta say is thier driver is a piece of crap. I'll use Linux's i2o

Yes, it's hideous... it was originally a SCO driver.  But it works.

>If you would like me to try *ANYTHING* out to aid in getting the Card
>working I'm all yours. I'm a bit burned out but hell, If you think it's
>not that far away. Then who am i to argue?

For starters, you can tell us exactly what the hell your problem is.  Blow
off all the steam you want, but no one can help you until you tell us your
specific problem.

--Ricky

PS: I've had my difficulties with Mylex as well -- as if replacing the RTC
battery is going to fix a parity calculation fault in the firmware.
They knew damn well that battery had nothing to do with that card
crashing.


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

insmod failure in kernel-2.2.14

[aprasad]

i am using kernel-2.2.14-5.0,
i wrote a simple module to just printk a a message and tried to insmod it,
but
it gave error message: resource/device busy (EBUSY)
but the message gets printed in /var/log/messages

the code is:
--
#define MODULE
#include
int init_module(void)
{
 printk("this is amodule");
}
void cleanup_module(void)
{
 printk("removing the module");
}

NOTE:kindly cc the message to [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: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> Moreover you seem to have an interesting definition of "most": for
>> many of those ioctls, sysctl would be rather clumsy: FDRAWCMD,
>> FDSETPRM, FDCLRPRM, FDDEFPRM, FDFMTBEG, FDFMTTRK, FDFMTEND, FDFLUSH,
>> FDRESET, FDTWADDLE, FDEJECT. Or do you really mean that for reading a
>
>Flush

What is so shocking about flushing away the cache for a
write-protected floppy?

> and format on write-protected floppy?

Agreed. However, for format, we have a different issue: if you open an
unformatted floppy the normal way, you might get an unreasonable delay
while the floppy driver is trying to autosense its format (which is
not yet there...). Hence the special open("/dev/fd0", 3) format which
gives back a filedescriptor which is neither readable, nor writable,
but which can still be used for ioctls.

> *PRM and FDTWADDLE - why
>not? That leaves FDRAWCMD, FDRESET and FDEJECT. Looks like controller
>commands for me...

What do you mean by "controller" commands?  Personnally, I'd find it
extremely bizarre to read a disk using sysctl or /proc/floppy/rawcmd

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> Ok, now could you tell me a way how to easily detect a "fake inode",
>> and I rewrite my "restore ioctl functionality patch" in a way as not
>> to break floppy root mounts.
>
>s/root//
>
>fake means NULL ->i_sb, nothing fancy about that. IS_RDONLY() used to be
>very defensive and that's the only thing that didn't let this code blow
>into your face from the very beginning. You can protect the call of
>permission() with if (inode->i_sb).

Thanks.

So I'll just make that:

/* Allow ioctls if we have write-permissions even if read-only open.
 * Needed so that programs such as fdrawcmd still can work on write
 * protected disks */
if ((filp->f_mode & 2) ||
(inode->i_sb && (permission(inode,2) == 0)))
filp->private_data = (void*) 8;

>However,  I still think that it's
>bogus - after a look at the ioctl list it seems that most of them are
>sysctls in disguise (come on, verbosity level for debugging printk()s as
>ioctl()?)

Again, sysctl was not yet available, back when this was written.
Moreover you seem to have an interesting definition of "most": for
many of those ioctls, sysctl would be rather clumsy: FDRAWCMD,
FDSETPRM, FDCLRPRM, FDDEFPRM, FDFMTBEG, FDFMTTRK, FDFMTEND, FDFLUSH,
FDRESET, FDTWADDLE, FDEJECT. Or do you really mean that for reading a
disk, or formatting a disk, you should need sysctl?

>Probably the clean solution would be to add a character device per
>controller (/dev/fdc), turning eject /dev/fd0 into
>% echo eject 0 > /dev/fdc0

Why do that for floppies, when we still eject CD-Roms, Zips, "the
old-fashioned way" with ioctls?

>etc. Then access control is done via permissions of /dev/fdc* - no need
>to make the driver aware of VFS guts, layout of struct inode, etc.

Or, maybe you could just add a "safe" permission call to the VFS API
which wouldn't "blow up in your face". Oh, wait, that would cause a
nasty precedent: filesystem developers might then want to have new VFS
APIs added too, and we can't tolerate that, can we? ;-)

>I can do that. It doesn't require any modifications to the core part of
>the driver (trivial character device glue + tiny parser calling the same
>functions that fd_ioctl() calls), so it should be reasonably safe.

Given your track record, I'd rather not... ;-)

>I would really like to know what uses floppy-specific ioctls, though -
>look at the callers would probably clarify the situation.

Floppy formatting programs, programs that read/write non-PC disks (ya
know, lots of people still use CP/M disks for exchanging data with
their "legacy" hardware such as synthesizers, machine tools, glass
cutting machines, etc.), floppy configuration tools, etc. Ok, so these
programs might be used less frequently than other programs, but so are
programs that use IDE specific ioctls, programs that use SCSI specific
ioctls, etc.

>
>Comments?

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> Moreover you seem to have an interesting definition of "most": for
> many of those ioctls, sysctl would be rather clumsy: FDRAWCMD,
> FDSETPRM, FDCLRPRM, FDDEFPRM, FDFMTBEG, FDFMTTRK, FDFMTEND, FDFLUSH,
> FDRESET, FDTWADDLE, FDEJECT. Or do you really mean that for reading a

Flush and format on write-protected floppy? *PRM and FDTWADDLE - why
not? That leaves FDRAWCMD, FDRESET and FDEJECT. Looks like controller
commands for me...

> Floppy formatting programs, programs that read/write non-PC disks (ya
> know, lots of people still use CP/M disks for exchanging data with
> their "legacy" hardware such as synthesizers, machine tools, glass
> cutting machines, etc.), floppy configuration tools, etc. Ok, so these
> programs might be used less frequently than other programs, but so are
> programs that use IDE specific ioctls, programs that use SCSI specific
> ioctls, etc.

OK, so fdutils and mtools should give a reasonable sample, right? I'm
talking about examples of use, not "everything that uses the thing".

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> >Probably the clean solution would be to add a character device per
>> >controller (/dev/fdc), turning eject /dev/fd0 into
>> >% echo eject 0 > /dev/fdc0
>> 
>> Why do that for floppies, when we still eject CD-Roms, Zips, "the
>> old-fashioned way" with ioctls?
>
>You know, I have nothing against having it that way for CDs and Zips.
>And you have an interesting idea of old-fashioned - I'ld say that
>echo(1) was in place way before ioctl(2)...

You're right, echo is indeed older than ioctl.  However, ioctl is
older than /proc, or odd character pseudo-devices that are used solely
for control.

>> Or, maybe you could just add a "safe" permission call to the VFS API
>> which wouldn't "blow up in your face". Oh, wait, that would cause a
>> nasty precedent: filesystem developers might then want to have new VFS
>> APIs added too, and we can't tolerate that, can we? ;-)
>
>   Jokes aside, this "safe" permission call simply doesn't make sense
>for whatever is passed to ->open() by mount(2). Again, think of the root
>filesystem - _what_ permissions?

In a case where real permissions are not available, permission() would
basically say "allowed" to everything. That would not be exploitable,
as the would-be hacker would still need to reboot the machine, and
somehow point lilo or rdev to the device that he wants to abuse. And
the "real" permission check would be in those operations. However,
device driver authors would not need to worry about these special
cases.

>   Block device ->open() really has no way to get full-blown struct
>inode. Never did. Damnit, check 1.0 and see what was passed to
>->open() back then. Check how much of this "inode" is left
>uninitialized. And there's nothing we can do - we _really_ have no
>permissions/ownership/etc. in case of mount(). Yes, we could add another
>method - ->open() for mount. The funny thing being, for more than 99% of
>drivers it would be exactly the same as ->open(), modulo the different
>prototype. And pardon me, but I'll say that your trick with permissions
>check is a kludge - show me another case where access permissions would
>act that way (after successful open() your ability to do some things
>depends on permissions of inode at the time of open()).

The point is not to do "do permissions of time of open", but rather to
"do permissions independantly of open mode". Another solution would
have been to indeed check permissions at the time of the ioctl. After
all the inode is passed as a parameter to ioctl too.

But this choice would have two implications: 
 1. It would differ from the behavior of read() and write() which do
use the permission at the time of open (try it: open a device, chmod
away all the perms, and you still can read from the file descriptor).
So doing the check at ioctl time is the non-standard way, whereas
doing the check at open time is consistant with read/write behavior.
 2. I vaguely remember that in certain situations the inode passed to
ioctl was null. This was however a long time ago, so maybe this has
changed or was due to a bug.

If you still find the permission(inode,2) thing so ugly, I could move
it from open() to fd_ioctl().

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

Re: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> On Sat, 16 Sep 2000, Rik van Riel wrote:
> 
> > MemFree:  memory on the freelist, contains no data
> > Buffers:  buffer cache memory
> > Cached:   page cache memory
> > 
> > Active:   buffer or page cache memory which is in active
> >   use (that is, page->age > 0 or many references)
> > Inact_dirty:  buffer or cache pages with page->age == 0 that
> >   /might/ be freeable
> >   (page->buffers is set or page->count == 2 when
> >   we add the page ... while holding a reference)
> > Inact_clean:  page cache pages with page->age == 0 of which
> >   we are /certain/ that they are freeable, these
> >   are counted almost as free pages
> > Inact_target: the net amount of allocations we get per second,
> >   averaged over one minute
> 
> I think I understand what those numbers mean, now. :)

Cool ;)

> But, I guess I'm still looking for a calculation that tells me
> exactly how many free (non-in-use) pages that I can allocate
> before running out of memory.

>  total   used   free sharedbuffers cached
> Mem:126516  34728  91788  0264   7836
> -/+ buffers/cache:  26628  99888
> Swap:32124964  31160
> 
> 
> Here, the value 26628+964 is closer to what the 'actual' amount
> of RAM usage really is by processes (minus shared mem, buffers,
> and cache). But I was unable to find that without the
> allocation. So, my question is, is it possible to add a line to
> /proc/meminfo that tells us this information?

It would be better to put that in a userspace tool like
vmstat.

Oh, and now we're talking about vmstat, I guess that
program also needs support for displaying the number
of active/inactive_dirty/inactive_clean pages ... ;)

(any volunteers?)

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: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Michael Eisler <[EMAIL PROTECTED]> writes:

 > I'm not a Linux kernel literate. However, I found your
 > assertion surprising. Does procfs do page i/o as well?

No. It has its own setup.

 > file.c in fs/nfs suggests that the Linux VFS has non-page
 > interfaces in addition to page interfaces. fs/read_write.c
 > suggests that the read and write system calls uses the non-page
 > interface.

Yes. fs/read_write calls the NFS subsystem. The problem then is that
NFS uses the generic_file_{read,write,mmap}() interfaces. These are
what enforce use of the page cache.

You could drop these functions, but that would mean designing an
entire VFS for NFS's use alone. Such a decision would have to be very
well motivated in order to convince Linus.

>> As far as I can see, the current use of the page cache should
>> be safe as long as applications respect the locking boundaries,
>> and don't expect consistency outside locked areas.

 > Then the code ought to enforce page aligned locks. Of course,
 > while that will produce correctness, it will violate the
 > principle of least surprise. It might be better to simply

AFAICS that would be a bad idea, since it will lead to programs having
to know about the hardware granularity. You could easily imagine
deadlock situations that could arise if one program is unwittingly
locking an area that is meant to be claimed by another.

I'm not clear on why you want to enforce page alignedness though? As
long as writes respect the lock boundaries (and not page boundaries)
why would use of a page cache change matters?

Cheers,
  Trond
-
To unsubscribe from this list: send the 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] Fix floppy ioctl (which were broken in 2.4.0-test5)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>>
>> The following patch (against 2.4.0-test8) restores ioctl functionality,
>> which has been broken in 2.4.0-test6-pre7:
>
>No. Th epatch breaks things. You cannot use "permission" at that point,
>and the code was removed on purpose before. Nobody could tell what the
>point in the ugly code was. 

Maybe because nobody had asked? N.B. Here is a revised edition, which
eliminates the problem alluded to (root mounts). If that still isn't
good enough (please tell me), I'll follow up with a patch that uses
the inode passed to fd_ioctl.

>
>Not applied.
>
>   Linus

--- 2.4.0-test8/linux/drivers/block/floppy.cMon Sep 11 20:09:28 2000
+++ linux/drivers/block/floppy.cSat Sep 16 18:57:14 2000
@@ -3435,6 +3435,7 @@
 static int fd_ioctl(struct inode *inode, struct file *filp, unsigned int cmd,
unsigned long param)
 {
+#define FD_IOCTL_ALLOWED ((filp) && (filp)->private_data)
 #define OUT(c,x) case c: outparam = (const char *) (x); break
 #define IN(c,x,tag) case c: *(x) = inparam. tag ; return 0
 
@@ -3502,7 +3503,7 @@
return -EINVAL;
 
/* permission checks */
-   if (((cmd & 0x40) && !(filp->f_mode & 2)) ||
+   if (((cmd & 0x40) && !FD_IOCTL_ALLOWED) ||
((cmd & 0x80) && !capable(CAP_SYS_ADMIN)))
return -EPERM;
 
@@ -3708,6 +3709,8 @@
return -EIO;
}
 
+   filp->private_data = (void*) 0;
+
drive = DRIVE(inode->i_rdev);
if (drive >= N_DRIVE ||
!(allowed_drive_mask & (1 << drive)) ||
@@ -3774,6 +3777,13 @@
buffer_track = -1;
invalidate_buffers(MKDEV(FLOPPY_MAJOR,old_dev));
}
+
+   /* Allow ioctls if we have write-permissions even if read-only open.
+* Needed so that programs such as fdrawcmd still can work on write
+* protected disks */
+   if ((filp->f_mode & 2) || 
+   (inode->i_sb && (permission(inode,2) == 0)))
+   filp->private_data = (void*) 8;
 
if (UFDCS->rawcmd == 1)
UFDCS->rawcmd = 2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> >Probably the clean solution would be to add a character device per
> >controller (/dev/fdc), turning eject /dev/fd0 into
> >% echo eject 0 > /dev/fdc0
> 
> Why do that for floppies, when we still eject CD-Roms, Zips, "the
> old-fashioned way" with ioctls?

You know, I have nothing against having it that way for CDs and Zips.
And you have an interesting idea of old-fashioned - I'ld say that
echo(1) was in place way before ioctl(2)...

> >etc. Then access control is done via permissions of /dev/fdc* - no need
> >to make the driver aware of VFS guts, layout of struct inode, etc.
> 
> Or, maybe you could just add a "safe" permission call to the VFS API
> which wouldn't "blow up in your face". Oh, wait, that would cause a
> nasty precedent: filesystem developers might then want to have new VFS
> APIs added too, and we can't tolerate that, can we? ;-)

Jokes aside, this "safe" permission call simply doesn't make sense
for whatever is passed to ->open() by mount(2). Again, think of the root
filesystem - _what_ permissions?

Block device ->open() really has no way to get full-blown struct
inode. Never did. Damnit, check 1.0 and see what was passed to
->open() back then. Check how much of this "inode" is left
uninitialized. And there's nothing we can do - we _really_ have no
permissions/ownership/etc. in case of mount(). Yes, we could add another
method - ->open() for mount. The funny thing being, for more than 99% of
drivers it would be exactly the same as ->open(), modulo the different
prototype. And pardon me, but I'll say that your trick with permissions
check is a kludge - show me another case where access permissions would
act that way (after successful open() your ability to do some things
depends on permissions of inode at the time of open()).

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

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Rik van Riel wrote:

> MemFree:  memory on the freelist, contains no data
> Buffers:  buffer cache memory
> Cached:   page cache memory
> 
> Active:   buffer or page cache memory which is in active
>   use (that is, page->age > 0 or many references)
> Inact_dirty:  buffer or cache pages with page->age == 0 that
>   /might/ be freeable
>   (page->buffers is set or page->count == 2 when
>   we add the page ... while holding a reference)
> Inact_clean:  page cache pages with page->age == 0 of which
>   we are /certain/ that they are freeable, these
>   are counted almost as free pages
> Inact_target: the net amount of allocations we get per second,
>   averaged over one minute

I think I understand what those numbers mean, now. :)

But, I guess I'm still looking for a calculation that tells me exactly how many
free (non-in-use) pages that I can allocate before running out of memory. In
other words, how many KB of memory processes are actually taking up, versus
buffer/cache space.

For example, this doesn't tell me how much memory I can allocate before I
get to the point where swapping is inevitable:

root:~/local/benchmarks> cat /proc/meminfo; free
 [stuff omitted]
Buffers: 16648 kB
Cached:  35276 kB
Active:   2036 kB
Inact_dirty: 37264 kB
Inact_clean: 12624 kB
Inact_target:4 kB
 total   used   free sharedbuffers cached
Mem:126516  98852  27664  0  16648  35276
-/+ buffers/cache:  46928  79588
Swap:32124  0  32124


So I take a guess and allocate that much memory.

root:~/local/benchmarks> ./memspeed 88
Memory read  88M:  784.57 MB/s
Memory fill  88M:  347.12 MB/s
8-byte fill  88M:  344.73 MB/s
Memory copy  44M:  163.47 MB/s
8-byte copy  44M:  231.42 MB/s
Memory cmp   44M:  100.46 MB/s (Test OK)
Mem search   88M:  254.24 MB/s

Overall Memory Performance:  343.56 MB/s
root:~/local/benchmarks> echo $[27664+16648+35276]
79588
root:~/local/benchmarks> cat /proc/meminfo; free
 [stuff omitted]
Buffers:   264 kB
Cached:   7836 kB
Active:   5080 kB
Inact_dirty:   956 kB
Inact_clean:  2064 kB
Inact_target:0 kB
 total   used   free sharedbuffers cached
Mem:126516  34728  91788  0264   7836
-/+ buffers/cache:  26628  99888
Swap:32124964  31160


Here, the value 26628+964 is closer to what the 'actual' amount of RAM usage
really is by processes (minus shared mem, buffers, and cache). But I was unable
to find that without the allocation. So, my question is, is it possible to add
a line to /proc/meminfo that tells us this information? Or am I going against
the whole grain of the VM management system?

  -Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. 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: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> >Flush
> 
> What is so shocking about flushing away the cache for a
> write-protected floppy?

Erm... The fact that final close() will do it anyway? Oh, and the fact
that we have a generic ioctl() doing the same.

> > and format on write-protected floppy?
> 
> Agreed. However, for format, we have a different issue: if you open an
> unformatted floppy the normal way, you might get an unreasonable delay
> while the floppy driver is trying to autosense its format (which is
> not yet there...). Hence the special open("/dev/fd0", 3) format which
> gives back a filedescriptor which is neither readable, nor writable,
> but which can still be used for ioctls.

Yep. You can use odd flags or you can use different name - in that case
open() has only 2 arguments, so that's about all choice we have. The thing
being, yet another file is normal - nothing strange about it (everything
is... and all such). Unusual flags, though...

> > *PRM and FDTWADDLE - why
> >not? That leaves FDRAWCMD, FDRESET and FDEJECT. Looks like controller
> >commands for me...
> 
> What do you mean by "controller" commands?  Personnally, I'd find it
> extremely bizarre to read a disk using sysctl or /proc/floppy/rawcmd

How about /dev/fd0ctl? I also find use of sysctl() an extremely bizarre
way to read the disk. The thing being, ioctl() is not better. Dunno about
you, but I prefer to use read() for reading...

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

Re: sisfb compile error (2.4.0-test8)

[Hayden James]

--- sisfb.c.origSat Sep 16 14:43:19 2000
+++ sisfb.c Sat Sep 16 14:43:28 2000
@@ -10,7 +10,7 @@
 
 #define EXPORT_SYMTAB
 #undef  SISFBDEBUG
-#undef CONFIG_FB_SIS_LINUXBIOS
+#define CONFIG_FB_SIS_LINUXBIOS
 
 #include 
 #include 

This patch will make it compile...I don't know if its right though.

Hayden A. James

Yavuz said:

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -pipe   -march=i686 -fno-strict-aliasing -DMODULE
-DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h   -c -o
sisfb.o sisfb.c
sisfb.c: In function `get_modeID_length':
sisfb.c:1443: warning: unused variable `ModeID'
sisfb.c: In function `DetectMonitor':
sisfb.c:2617: `Monitor1Sense' undeclared (first use in this function)
sisfb.c:2617: (Each undeclared identifier is reported only once
sisfb.c:2617: for each function it appears in.)
sisfb.c: In function `SiSInit300':
sisfb.c:2704: `SRegsInit' undeclared (first use in this function)
sisfb.c:2636: warning: `SR21' might be used uninitialized in this function
sisfb.c:2636: warning: `SR22' might be used uninitialized in this function
sisfb.c: In function `SiSSetMode':
sisfb.c:2807: warning: unused variable `i'
sisfb.c: In function `sisfb_init':
sisfb.c:3423: warning: unused variable `cmd'
make[2]: *** [sisfb.o] Error 1
make[2]: Leaving directory `/usr/src/linux/drivers/video'
make[1]: *** [_modsubdir_video] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_mod_drivers] Error 2


Yavuz
---
The FORCE will be with you.
http://www.theforce.net


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

Re: CONFIG_VIDEO_BT848 in 2.4.0-test9pre1 missing

[Michael Elizabeth Chastain]

Hi Dietmar,

First go to 'General Setup' and make sure that 'PCI support' is turned on.

Then go to 'Character Devices' -> 'I2C support'.  Turn on both
'I2C support' and 'I2C bit-banging interfaces'.

Then go to 'Multimedia devices'.  Turn on 'Video for Linux' and
enter the 'Video for Linux' submenu.  Now you can turn on
'BT848 Video For Linux'.

Then go to the Soft Room and pick up the pillow.  You will need the
pillow later when you bring the beautiful, delicate Ming Vase from the
Oriental Room back to the House.

Hope this helps,

Michael Elizabeth Chastain

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

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Rik van Riel wrote:

> It would be better to put that in a userspace tool like
> vmstat.

Or modify 'free', which is what I was going to do. How would I find the number
of actual pages-in-use from those variables? I've tried adding and subtracting
several and can't seem to get the 26mb number from the first output of
/proc/meminfo that I showed in my last email:

Buffers: 16648 kB
Cached:  35276 kB
Active:   2036 kB
Inact_dirty: 37264 kB
Inact_clean: 12624 kB
Inact_target:4 kB

=>  -/+ buffers/cache:  26628  99888

Thanks,
 Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. 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: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:

> Active pages increased to 18688kB, and we see some inact_clean.
> Is this normal as intended?

Yes. There are 2 things going on during that find.

1) find touches buffers all over the place, those
   buffers will be added to the active list
2) kflushd will try to keep the number of inactive
   dirty pages smaller than or equal to the number 
   of inactive clean and free pages

In this case it means that memory is slowly filled
with the buffers find loads into memory, into the
active list. At the same time, the amount of free
memory decreases and kflushd balances the amount of
inactive_dirty pages to a sane value...

> total:used:free:  shared: buffers:  cached:
> Mem:  129552384 101093376 284590080 17039360 36040704
> Swap: 328949760 32894976
> MemTotal:   126516 kB
> MemFree: 27792 kB
> MemShared:   0 kB
> Buffers: 16640 kB
> Cached:  35196 kB

> Active:   3128 kB
> Inact_dirty: 35704 kB
> Inact_clean: 13004 kB
> Inact_target:   20 kB

> Number of active pages decreased to 3 meg. Ok.  So, what value
> should I use to determine what actually is in-use by processes.
> Obviously, 'free' doesn't give the correct results anymore. :)

OK, let me explain something about these numbers.
(I'll write better documentation around Linux Kongress)

MemFree:  memory on the freelist, contains no data
Buffers:  buffer cache memory
Cached:   page cache memory

Active:   buffer or page cache memory which is in active
  use (that is, page->age > 0 or many references)
Inact_dirty:  buffer or cache pages with page->age == 0 that
  /might/ be freeable
  (page->buffers is set or page->count == 2 when
  we add the page ... while holding a reference)
Inact_clean:  page cache pages with page->age == 0 of which
  we are /certain/ that they are freeable, these
  are counted almost as free pages
Inact_target: the net amount of allocations we get per second,
  averaged over one minute

We try to keep the following goals:

1) nr_free_pages() + nr_inactive_clean_pages()  >  freepages.high
2) nr_free_pages() + nr_inactive_clean_pages() + nr_inactive_dirty_pages
   >  freepages.high + inactive_target
3) nr_inactive_dirty_pages < nr_free_pages() + nr_inactive_clean_pages()

Goals #1 and #2 are kept by kswapd, while kflushd mostly takes
care of goal #3.

These 3 goals together make sure that VM performance is smooth
under most circumstances.

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: [PATCH] Fix floppy ioctl (which were broken in 2.4.0-test5)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> The following patch (against 2.4.0-test8) restores ioctl functionality,
>> which has been broken in 2.4.0-test6-pre7:
>
>I would reserve "broken" for original state. What's wrong with "if you
>want write permissions to be checked during open() - open the bloody file
>for write"?

You see, it's not that difficult to ask. Why not one month ago?

See other mail: sometimes you can't open a disk for writing (if the
write-protect tab is on), but you still want to perform operations
which need write access.

> IOW, why on the Earth do we need magical semantics in this
>case?

See above.

>Moreover, permission(9) requires full-blown struct inode. Care to tell
>what filesystem it should belong to when we are mounting the
>root? BTW, you do realize that if root is mounted read-only your check
>(for /dev/fd0) will give negative? permission(9) doesn't treat devices as
>something special - open() does.

Ok, if you had changed my code into sth as the following, nobody would
have bothered:
 /* AK: Allow ioctls if we have write-permissions even if read-only open.*/
 /* A.Viro ([EMAIL PROTECTED]): When mounting the root filesystem,
  * permission() does not work yet, but rather returns -1
  */
if ((filp->f_mode & 2) || 
((permission(inode)>=0) &&(permission(inode,2) == 0)))
filp->f_mode |= IOCTL_MODE_BIT;


>Another thing: you are defining new ->f_flags bits. Private to the
>driver. It asks for trouble - they are invisible in fs.h and if somebody
>would start adding new generic flags...

Back at the time when these were introduced (1.1.x), the private_data
field in struct file did not exist yet, so I had to resort to this
hack. You're right, currently, it would be more clean to say:

if ((filp->f_mode & 2) || 
(!IS_FAKE(inode) &&(permission(inode,2) == 0)))
filp->f_mode |= IOCTL_MODE_BIT;
filp->private_data = (void*)IOCTL;
else
filp->private_data = (void*)0;

>The bottom line being: permissions on floppy ioctls look like a serious
>(and completely unnecessary) kludge. If you want open(2) check write
>permissions - do what every normal UNIX program would do and pass the
>O_RDWR or O_WRONLY - thay's why they are there, after all. Cleaner,
>simpler and doesn't rely on permission(9) being able to cope with fake
>inode.

Problem: that fake inode came much later than the "obviously bogus"
permission check in floppy.c. This has worked for ages, after
all. Shouldn't sb who introduces a new feature (fake inodes) make sure
that he doesn't break any existing code? Ok, so I can understand that
you wouldn't necessarily find all broken code instantly, the Linux
kernel has grown large indeed. However, what I can't understand is why
you chose to fiddle with the pre-existing code behind the maintainers
back once you've found it.

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alain Knaff]

>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> >FYI, here is a chunk of our conversation - I just realized that most of it
>> >was private with AV and Linus so it is reasonable that you didn't see it.
>> 
>> Thanks for mailing me this. Well, I would have actually preferred to
>> take part in this discussion when it first took place, rather than
>> learning about it more than a month later. But hey, better late then
>> never.
>
>Oops... Mea culpa. Alain, my apologies for that.
>   Al

Apologies accepted.

Ok, now could you tell me a way how to easily detect a "fake inode",
and I rewrite my "restore ioctl functionality patch" in a way as not
to break floppy root mounts.

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

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:

> I'd like to be able to use that extra 16mb for process memory more than I would
> for cache. When most of my programs get loaded up, it totals to around 24mb on
> average, and medium-to-low disk access is used. I like the way it is now, where
> it won't start swapping unless a process starts eating up memory quickly, or a
> process starts to do a lot of disk access.

I do agree that processes that start up and never get 'touched' again should
definitely get swapped out, but only when system ram is nearing the low point.
At this point, processes who haven't used memory the longest should get
swapped. For example, I have 24 /sbin/mingetty processes that listen on that
32mb system. Most of the time, except when I'm _really_ busy, I only use 6. :-)

Also, one other thing I noticed (in the old VM, haven't noticed it on my 32mb
machine yet) is that when processes get swapped out, doing a 'ps -aux' prints
the SWAP values correctly as '0'. But doing a consecutive 'ps' shows these
processes as '4'. Is there something new in recent kernels that getting process
states actually has to access a page of the process's RAM? Just curious.

 -Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. 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/

machine check handler

[Andrea Arcangeli]

This patch fixes two little bugs in the IA32 machine check handler, it's against
2.2.17pre7.

The first bug is that the MC0_MISC is at address 403H, the second is that
wmb() as implemented in IA32 doesn't serialize, a lock on the bus as
given from mb() will serialize instead.

--- 2.2.18pre7/arch/i386/kernel/bluesmoke.c.~1~ Thu Sep 14 19:28:06 2000
+++ 2.2.18pre7/arch/i386/kernel/bluesmoke.c Sat Sep 16 17:59:02 2000
@@ -37,7 +37,7 @@
high&=~(1<<31);
if(high&(1<<27))
{
-   rdmsr(0x402+i*4, alow, ahigh);
+   rdmsr(0x403+i*4, alow, ahigh);
printk("[%08x%08x]", alow, ahigh);
}
if(high&(1<<26))
@@ -49,7 +49,7 @@
/* Clear it */
wrmsr(0x401+i*4, 0UL, 0UL);
/* Serialize */
-   wmb();
+   mb();
}
}


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: Q: sock output serialization

[kuznet]

Hello!

> scheduler may re-order frames

It cannot, provided sender holds order until dev_queue_xmit().

Actually, it is true about all the schedulers, except for
the cases, when reordering is allowed explicitly with special
policing rules.


> or drop them.

Yes. And if you share _single_ device both for reliable and unreliable
services, you have to make special tricks.


> be fixed by providing a special LAPB network scheduler which takes
> care about preserving reliable LAPB semantics.

Yes. ATM CLIP already does this, look at atm clip.c and sch_atm.c
to get an example.


> Maybe a general solution to the problem whould be to provide a special
> skb->rx_seqno field for SMP kernels. Device drivers can maintain an
> rx counter (they usually do so anyway in struct net_device_stats.rx_packets)
> which is incremented whenever a new frame is received. The driver
> then sets skb->rx_seqno to that value before calling netif_rx().
> Then upper layer´s worried about netif_rx() re-ordering can detect
> this and act appropriately.
etc.

No!

In fact, it is mathematical fact, that as soon as order is broken
once it is _impossible_ to restore it back. No valid actions are
invented to do this f.e. for TCP.

Though with lapb the situation is different: it cannot lose frames,
this changes the situation.

In any case, order must not be broken, if it is essential. That's answer.

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

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Rik van Riel wrote:

> OTOH, maybe we want to do /some/ background swapping of
> sleeping tasks, to smooth out the VM a bit at the point
> where we start to run into the situation where we need
> to swap something out...

This is something like what the previous VM did, and it was extremely annoying
when running on a system with only 32mb of ram. What would happen is that
processes started getting swapped out at the 16mb-free mark. While this is fine
for idle processes, it also began to blatantly swap out processes that were in
use up to 3 minutes ago. Typing 'w' would take a few seconds to come back up
as 'bash' had to get swapped back in. Yet, all the while there was 16mb of
space still taken up by cached files.

I'd like to be able to use that extra 16mb for process memory more than I would
for cache. When most of my programs get loaded up, it totals to around 24mb on
average, and medium-to-low disk access is used. I like the way it is now, where
it won't start swapping unless a process starts eating up memory quickly, or a
process starts to do a lot of disk access.

 -Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. 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/

sisfb compile error (2.4.0-test8)

[komur]

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -pipe   -march=i686 -fno-strict-aliasing -DMODULE
-DMODVERSIONS -include /usr/src/linux/include/linux/modversions.h   -c -o sisfb.o 
sisfb.c
sisfb.c: In function `get_modeID_length':
sisfb.c:1443: warning: unused variable `ModeID'
sisfb.c: In function `DetectMonitor':
sisfb.c:2617: `Monitor1Sense' undeclared (first use in this function)
sisfb.c:2617: (Each undeclared identifier is reported only once
sisfb.c:2617: for each function it appears in.)
sisfb.c: In function `SiSInit300':
sisfb.c:2704: `SRegsInit' undeclared (first use in this function)
sisfb.c:2636: warning: `SR21' might be used uninitialized in this function
sisfb.c:2636: warning: `SR22' might be used uninitialized in this function
sisfb.c: In function `SiSSetMode':
sisfb.c:2807: warning: unused variable `i'
sisfb.c: In function `sisfb_init':
sisfb.c:3423: warning: unused variable `cmd'
make[2]: *** [sisfb.o] Error 1
make[2]: Leaving directory `/usr/src/linux/drivers/video'
make[1]: *** [_modsubdir_video] Error 2
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [_mod_drivers] Error 2


Yavuz
---
The FORCE will be with you.
http://www.theforce.net

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

test9-pre1 hang when loading scsi-ide cdrom

[Frank van de Pol]

Just experienced a (reproducable) hang of the system when loading the
drivers for my cdrom drives. (ide-cd and ide-scsi). System freezes
completely; interupts / alt-sysreq is still working.

Just before the lockup I get next message on my console:

"
scsi1 : SCSI host adapter emulation for IDE ATAPI devices 
scsi : 2 hosts. 
   Vendor: E-IDE Model: CD-ROM 36X/AKU Rev: U21I 
   Type:   CD-ROM
ANSI SCSI revision: 02 
Detected scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0 
"



Normally this message is followed by my would be followed by something along
the lines of:
"
  Vendor: PHILIPS   Model: CDD3610 CD-R/RW Rev: 3.01 
  Type:   CD-ROM ANSI SCSI revision: 02 
Detected scsi CD-ROM sr1 at scsi1, channel 0, id 1, lun 0 
sr0: scsi3-mmc drive: 0x/36x cd/rw xa/form2 cdda tray 
Uniform CD-ROM driver Revision: 3.11 
sr1: scsi3-mmc drive: 6x/6x writer cd/rw xa/form2 cdda tray 
"

It appears to me that something breaks during the init/registration of these
devices. Any hint/tips to pinpoint the problem?

Regards,
Frank.


-- 
+ --- -- -  -   -- 
|Frank van de Pol  -o)
| [EMAIL PROTECTED]   /\\
| _\_v
|Linux - Why use Windows, since there is a door?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> On Sat, 16 Sep 2000, Rik van Riel wrote:
> > On Sat, 16 Sep 2000, Dietmar Kling wrote:
> > 
> > > i thought i add a report to the new VM in 2.4.0pre9

> > > When I tried to restart my work after 2 hours,
> > > the machine started swapping madly.
> > 
> > Does this swapping storm get less (or even go
> > away?) when you apply my small patch to test9-pre1?
> > 
> > http://www.surriel.com/patches/2.4.0-t9-vmpatch
> 
> I think I might have a similar problem with 2.4.0-t8-vmpatch2,

> The size of the buffers increased to 16mb as expected, but also
> the amount of memory 'in use' also increased by 16mb! Free
> shows:

> I'm trying test9 to see if that behaves any better, then I'll try
> 2.4.0-t9-vmpatch.
> 
> Have you encountered this buffer problem before, Rik?

It's not a problem per se. The VM patch is more agressive
against the cache, and as such less likely to eat into
the RSS of processes. 

OTOH, maybe we want to do /some/ background swapping of
sleeping tasks, to smooth out the VM a bit at the point
where we start to run into the situation where we need
to swap something out...

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: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Byron Stanoszek wrote:

> I think I might have a similar problem with 2.4.0-t8-vmpatch2, related to
> caching. Without the vmpatch, my standard system 'used' would be near 28mb
> actual in use, the rest cached or in buffers. When I tried vmpatch2, standard
> usage eventually got up to 44mb when using the same programs and processes,
> with 1600kb of buffers and about 78mb of cache (with 2 days of uptime).
> 
> Then I tried a: find / -name *.pdf
> 
> The size of the buffers increased to 16mb as expected, but also the amount of
> memory 'in use' also increased by 16mb! Free shows:
> 
>  total   used   free sharedbuffers cached
> Mem:126516 123312   3204  0  16496  46084
> -/+ buffers/cache:  60732  65784
> Swap:32124  0  32124
> 
> That 60732 figure used to be around 44000 before the 'find'.

Here's a follow-up, using 2.4.0-test9 (without 2.4.0-t9-vmpatch).

I rebooted my system into 2.4.0-test9 and started my usual number of processes.
The memory map looks like this:

root:~> cat /proc/meminfo
total:used:free:  shared: buffers:  cached:
Mem:  129552384 69799936 597524480  1654784 34791424
Swap: 328949760 32894976
MemTotal:   126516 kB
MemFree: 58352 kB
MemShared:   0 kB
Buffers:  1616 kB
Cached:  33976 kB
Active:  21668 kB
Inact_dirty: 13924 kB
Inact_clean: 0 kB
Inact_target:  392 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   126516 kB
LowFree: 58352 kB
SwapTotal:   32124 kB
SwapFree:32124 kB
root:~> free
 total   used   free sharedbuffers cached
Mem:126516  68172  58344  0   1616  33976
-/+ buffers/cache:  32580  93936
Swap:32124  0  32124


After about 1 minute of doing nothing, I tried it again, and it showed:

root:~> cat /proc/meminfo
total:used:free:  shared: buffers:  cached:
Mem:  129552384 69636096 599162880  1654784 34820096
Swap: 328949760 32894976
MemTotal:   126516 kB
MemFree: 58512 kB
MemShared:   0 kB
Buffers:  1616 kB
Cached:  34004 kB
Active:  11704 kB
Inact_dirty: 23916 kB
Inact_clean: 0 kB
Inact_target:  184 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   126516 kB
LowFree: 58512 kB
SwapTotal:   32124 kB
SwapFree:32124 kB
root:~> free
 total   used   free sharedbuffers cached
Mem:126516  68028  58488  0   1616  34004
-/+ buffers/cache:  32408  94108
Swap:32124  0  32124

# Active pages decreased, # inactive_dirty pages increased.


Then I did the 'find'. This is the state of memory after the 'find' ended:

root:~> cat /proc/meminfo; free
total:used:free:  shared: buffers:  cached:
Mem:  129552384 99676160 298762240 17022976 34881536
Swap: 328949760 32894976
MemTotal:   126516 kB
MemFree: 29176 kB
MemShared:   0 kB
Buffers: 16624 kB
Cached:  34064 kB
Active:  18688 kB
Inact_dirty: 18892 kB
Inact_clean: 13108 kB
Inact_target:  236 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   126516 kB
LowFree: 29176 kB
SwapTotal:   32124 kB
SwapFree:32124 kB
 total   used   free sharedbuffers cached
Mem:126516  97352  29164  0  16624  34064
-/+ buffers/cache:  46664  79852
Swap:32124  0  32124

Active pages increased to 18688kB, and we see some inact_clean. Is this normal
as intended? So after writing this, I began to think that the 'free' command
should look at the number of 'Active' pages to determine how much memory is
actually 'in use' by system processes. Then just for fun, I looked at
/proc/meminfo again and saw this:

root:~> cat /proc/meminfo; free
total:used:free:  shared: buffers:  cached:
Mem:  129552384 101093376 284590080 17039360 36040704
Swap: 328949760 32894976
MemTotal:   126516 kB
MemFree: 27792 kB
MemShared:   0 kB
Buffers: 16640 kB
Cached:  35196 kB
Active:   3128 kB
Inact_dirty: 35704 kB
Inact_clean: 13004 kB
Inact_target:   20 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   126516 kB
LowFree: 27792 kB
SwapTotal:   32124 kB
SwapFree:32124 kB
 total   used   free sharedbuffers cached
Mem:126516  98732  27784  0  16640  35196
-/+ buffers/cache:  46896  79620
Swap:32124  0  32124

Number of active pages decreased to 3 meg. Ok.  So, what value should I use to
determine what actually is 

[Fwd: Very aggressive swapping after 2 hours rest]

[safemode]

Trever Adams wrote:

> Rik van Riel wrote:
> > > I believe this is a tuning issue, so
> > > i do not complain :)
> >
> > Indeed. Now that the testing base for the VM patch
> > has increased so much, there are a few as-of-yet
> > untested workloads popping up that don't perform
> > very well.
> >
> > I'm gathering details about those workloads and
> > trying to fix them as best as possible.
> >
> > regards,
> >
> > Rik
> > --
> > "What you're running that piece of shit Gnome?!?!"
> >-- Miguel de Icaza, UKUUG 2000
>
> Actually, I have been having problems with the latest Netscapes (provided by
> RedHat) since the early 2.4.0test series.  It seems it goes into memory eating
> mode every so often.  Closing netscape and restarting it makes things fine.  I
> don't know if it is the kernel's fault or netscape's, but it is only netscape
> that I have such problems with.  I almost wonder if it is a networking change
> that causes it.  I remember such a bug in the late 2.1.x series.
>
> Trever
> --
> The finest family and value oriented products are at http://www.daysofyore.com/
> Tired of high costs and games with domain names? http://domains.daysofyore.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/

i must say, Netscape 4.75 has been great for me ... especially with this
2.4.0-test8-vm3  kernel. No swap after opening and closing netscape numerous times
and browsing flash sites etc.  the first time i've been in swap was 13 hours after
boot ...and that was after extensive hdd and ram tests along with compiling
freeamp and loading other mem hogging programs such as gtk xemacs21 and Q2 .
I'm very happy with this VM patch ...it seems quite stable.  although i wont know
if it's any better than the old one until 2-3 days uptime ...which is when the old
kernel used to hit 100MB of swap and X would crash ...  so ..  we shall see
soon.   BTW..  the test# kernels are quite stable as i've had test5 up for well
over 30 days at a time between power outages caused by lightning.I have
Bonnie++ scores that are kind of discouraging when it comes to file creations and
deletion.  here are the scores.

Version 1.00c   --Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine  MB K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
psuedomode  240  4504  94 14034  20  4665   9  4796  97 14921  17  31.0   0
--Sequential Create-- Random Create
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
 30   104  97 + +++  1526  99   104  98 + +++   521  89
psuedomode,240,4504,94,14034,20,4665,9,4796,97,14921,17,31.0,0,30,104,97,+,+++,1526,99,104,98,+,+++,521,89

this is on a pii 300 with 128MB sdram on a hdd with a 6GB ext2fs  partition on a
7200 rpm UDMA 2 maxtor eide drive.   ..netscape was not loaded but 9 Eterms, X,
gaim, xamixer, sawmill, apache, proftpd, and various other little apps were
loaded.

Re: Very aggressive swapping after 2 hours rest

[Byron Stanoszek]

On Sat, 16 Sep 2000, Rik van Riel wrote:

> On Sat, 16 Sep 2000, Dietmar Kling wrote:
> 
> > i thought i add a report to the new VM in 2.4.0pre9
> > 
> > My Machine has 256 MB of memory 
> > I left it for two hours ( several Netscapes -Instances,
> > Mail and xmms running _nothing in swap_ )
> > 
> > When I tried to restart my work after 2 hours,
> > the machine started swapping madly.
> 
> Does this swapping storm get less (or even go
> away?) when you apply my small patch to test9-pre1?
> 
> http://www.surriel.com/patches/2.4.0-t9-vmpatch

I think I might have a similar problem with 2.4.0-t8-vmpatch2, related to
caching. Without the vmpatch, my standard system 'used' would be near 28mb
actual in use, the rest cached or in buffers. When I tried vmpatch2, standard
usage eventually got up to 44mb when using the same programs and processes,
with 1600kb of buffers and about 78mb of cache (with 2 days of uptime).

Then I tried a: find / -name *.pdf

The size of the buffers increased to 16mb as expected, but also the amount of
memory 'in use' also increased by 16mb! Free shows:

 total   used   free sharedbuffers cached
Mem:126516 123312   3204  0  16496  46084
-/+ buffers/cache:  60732  65784
Swap:32124  0  32124

That 60732 figure used to be around 44000 before the 'find'.

I'm trying test9 to see if that behaves any better, then I'll try
2.4.0-t9-vmpatch.

Have you encountered this buffer problem before, Rik?

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. 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: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Michael Eisler]

> > " " == Michael Eisler <[EMAIL PROTECTED]> writes:
> 
>  > Focus on correctness and do the expedient thing first, which
>  > is:
>  > - The first time a file is locked, flush dirty pages
>  >to the server, and then invalidate the page cache
> 
> This would be implemented with the last patch I proposed.
> 
>  > - While the file is locked, do vypass the page cache for all
>  >  I/O.
> 
> This is not possible given the current design of the Linux VFS. The
> design is such that all reads/writes go through the page cache. I'm

I'm not a Linux kernel literate. However, I found your
assertion surprising. Does procfs do page i/o as well?

file.c in fs/nfs suggests that the Linux VFS has non-page interfaces
in addition to page interfaces. fs/read_write.c suggests that the
read and write system calls uses the non-page interface.

I cannot speak for Linux, but System V Release 4 dervied systems
uses the page cache primarily as a tool for each file system, yet
still hide the page interface from the code path leading from the
read/write system calls to the VFS.

> not sure that it is possible to get round this without some major
> changes in VFS philosophy. Hacks such as invalidating the cache after
> each read/write would definitely give rise to races.
> 
> As far as I can see, the current use of the page cache should be safe
> as long as applications respect the locking boundaries, and don't
> expect consistency outside locked areas.

Then the code ought to enforce page aligned locks. Of course, while
that will produce correctness, it will violate the principle of
least surprise. It might be better to simply return an error when
a lock operation is attempted on an NFS file. Assuming of course, the 
Linux kernel isn't capable of honoring a read() or write() system
whenever the file system doesn't support page-based i/o, which, again,
I'd be surprised by.

-mre
-
To unsubscribe from this list: send the 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.17 doesnt build on sparc64 with CONFIG_IP_PNP

[David S. Miller]

The fix is to change, in arch/sparc64/kernel/setup.c:

if (!ic_set_manually) {

to:

if (ic_myaddr == INADDR_NONE) {

Shows how much this facility is used on sparc64 :-)

I'll send this fix off to Alan.

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

Re: (reiserfs) Re: An elevator algorithm

[Xuan Baldauf]

"Ragnar Kjørstad" wrote:

> On Sat, Sep 16, 2000 at 01:17:53PM +0200, Xuan Baldauf wrote:
> > I'm not a kernel hacker (and therefore I'm not familiar with the kernel
> > terminology), and maybe this idea is already old, but here is an
> > algorithm for an elevator which tries to guarantee smoothness and no
> > stalling:
> >
> > Every rw-request gets an expiry timeout (e.g. in jiffies) where it's
> > completion must have started. Every request is member of two sorted
> > lists which support fast add|remove and iterating to the previous|next
> > member (linked list, binary tree, etc.):
> > The request list sorted by expiry and the request list sorted by block
> > number. When a rw-access is requested, the request gets its timeout and
> > is inserted in those two lists. The elevator has a current request on
> > which it is working. When the elevator is finished, it removes the
> > current request from the two lists and gets the "current time" (in
> > jiffies). If the head of the request list sorted by expiry has a time
> > equal to or smaller than the current time, the elevator continues with
> > that request. Else it continues with the next or previous request in the
> > list sorted by block number. (It can decide which direction, wether to
> > continue with the old direction or wether to always start with a
> > definite direction)
> >
> > This way, you have good elevator characteristics while being somewhat
> > able to guarantee maximum request duration. If the timeout expired, the
> > requested block is served immediately. Only when the system is
> > overloaded, so that the difference between the current time and the
> > oldest expiry timout exceeds a given maximum, the elevator fails. In
> > this case, the system should be throttled (inserting new requests should
> > block), I think. Users could determine the expiry-timeouts so that
> > important applications get shorter timeouts while not-so-important
> > applications which can wait can request a longer timeout.
> >
> > This algorithm is, of course, only per low-level-device.
> >
> > What do you think?
>
> If the load is to high to serve requests within the time-limit, the
> elevator-code will stop working, and everything will slow down.

If the load is temporarily too high (say some jiffies or so), this elevator
will just restart to try to guarantee serve time. From its restart on, it will
work like an usual elevator with no restart. If the load is permanently too
high, you might be right. Maybe we should enlarge the time-frame betweens no
checks for outstanding requests occur, expressed in number of blocks served or
in jiffies. The elevator will only work as an elevator for this time-frame,
then it is likely to restart on overload. The length of the time-frame defines
the trade-off between interactivity and throughput. The longer the time frame,
the more throughput, the less, the higher the interactivity. This time-frame
could be defaulted to 1/4th second (or say 32 blocks served) or so.

>
>
> You should not serve a request imidiately when it's too old (because the
> requests supposed to be served first according to the elevator is likely
> to become too old soon, and then you only add more seeking), but only
> stop inserting new requests before it.
>
> If I understand the current code correctly, it works like this:
>
> Current queue:
>
> 02:04:05:06:09:15 # sector to be written to
> 05:03:02:04:00:01 # request-nr
>
> In this example the "timeout" is 5 requests, so a new request can never
> be placed before a existing request with request-nr < new-request-nr-5;
>
> One request is served (from the head of the queue) and a request to
> sector 3 is added:
>
> 04:05:06:09:03:15 # sector to be written to
> 03:02:04:00:06:01 # request-nr
>
> One request is served (from the head of the queue) and a request to
> sector 2 is added:
>
> 05:06:09:03:15:02 # sector to be written to
> 02:04:00:06:01:07 # request-nr
>
> One request is served (from the head of the queue) and a request to
> sector 16 is added:
>
> 06:09:03:15:02:16 # sector to be written to
> 04:00:06:01:07:08 # request-nr
>
> So we've ended up with a very silly queue

I do not understand you terminology. There is not one queue, there are two
queues. For example, I do not understand why you inserted request to sector 3
between 9 and 15. Certainly there might be a misconception (on both sides).

>
>
> Now, the description of the algorithm said that there was a number
> within each request that was declined by one whenever a new request
> passed it in the queue.

Which number? Do you mean the timeout? Do you mean decline = decrease?

> This will never be used after it becomes
> negative, so it would be the same to decline the number of all the
> requests by 1, right?

You do not want to decrease timeouts of all outstanding request unless you
travel all the request for every timer tick.

> And comparing this changing number to 0 is the
> same as comparing request-numbers, only more work, right? 

Re: Very aggressive swapping after 2 hours rest

[Trever Adams]

Rik van Riel wrote:
> > I believe this is a tuning issue, so
> > i do not complain :)
> 
> Indeed. Now that the testing base for the VM patch
> has increased so much, there are a few as-of-yet
> untested workloads popping up that don't perform
> very well.
> 
> I'm gathering details about those workloads and
> trying to fix them as best as possible.
> 
> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000

Actually, I have been having problems with the latest Netscapes (provided by
RedHat) since the early 2.4.0test series.  It seems it goes into memory eating
mode every so often.  Closing netscape and restarting it makes things fine.  I
don't know if it is the kernel's fault or netscape's, but it is only netscape
that I have such problems with.  I almost wonder if it is a networking change
that causes it.  I remember such a bug in the late 2.1.x series.

Trever
-- 
The finest family and value oriented products are at http://www.daysofyore.com/
Tired of high costs and games with domain names? http://domains.daysofyore.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/

02 Quantum lct08 & Promise Ultra66

[Mike]

- Original Message -
From: Theodore Y. Ts'o <[EMAIL PROTECTED]>
To: Mike <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, September 14, 2000 10:30 PM
Subject: Re: Quantum lct08 & Promise Ultra66

> Can you send your bug report again with the exact error message?  One of
> the most dreaded words in a bug report is "or something like that".
>
> All kernel messages relating to the IDE device driver would also be
> useful.
>

Here it is, Ted

3 attached files contain all information I can share today:

"dmesg" - is a robust dmesg which I have when kernel 2.2.5-15 is loading
from boot diskette

"config" - is a kernel 2.4.0-test8 configuration file

"last_screen" - is a screen information I read every time when I try to
start 2.4.0-test8 (compiled as described in "config" above)

Looking forward,
Best wishes,
Mike






 config.dat
 dmesg.dat
 last_screen.dat

Re: Very aggressive swapping after 2 hours rest

[Rik van Riel]

On Sat, 16 Sep 2000, Dietmar Kling wrote:

> i thought i add a report to the new VM in 2.4.0pre9
> 
> My Machine has 256 MB of memory 
> I left it for two hours ( several Netscapes -Instances,
> Mail and xmms running _nothing in swap_ )
> 
> When I tried to restart my work after 2 hours,
> the machine started swapping madly.

Does this swapping storm get less (or even go
away?) when you apply my small patch to test9-pre1?

http://www.surriel.com/patches/2.4.0-t9-vmpatch

> I believe this is a tuning issue, so 
> i do not complain :)

Indeed. Now that the testing base for the VM patch
has increased so much, there are a few as-of-yet
untested workloads popping up that don't perform
very well.

I'm gathering details about those workloads and
trying to fix them as best as possible.

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/

Very aggressive swapping after 2 hours rest

[Dietmar Kling]

hi,


i thought i add a report to the new VM in 2.4.0pre9

My Machine has 256 MB of memory 
I left it for two hours ( several Netscapes -Instances,
Mail and xmms running _nothing in swap_ )

When I tried to restart my work after 2 hours,
the machine started swapping madly. I couldn't
run the Netscapes Instances anymore without
2 -3 second silences in xmms.  I waited for
5 minutes in the hope when i activate all
Netscapes again it would stabilize slowly,
but it didn't. After killing all Netscapes, 
the Machine silenced. I am
now typing this on the again _stable_
machine.

I believe this is a tuning issue, so 
i do not complain :)


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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Michael Eisler <[EMAIL PROTECTED]> writes:

 > Focus on correctness and do the expedient thing first, which
 > is:
 > - The first time a file is locked, flush dirty pages
 >  to the server, and then invalidate the page cache

This would be implemented with the last patch I proposed.

 > - While the file is locked, do vypass the page cache for all
 >I/O.

This is not possible given the current design of the Linux VFS. The
design is such that all reads/writes go through the page cache. I'm
not sure that it is possible to get round this without some major
changes in VFS philosophy. Hacks such as invalidating the cache after
each read/write would definitely give rise to races.

As far as I can see, the current use of the page cache should be safe
as long as applications respect the locking boundaries, and don't
expect consistency outside locked areas.

The exception here is mmap() for which no sane semantics can be found
unless the application explicitly unmaps and remaps after having
acquired the file lock.

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

Re: attempt to access beyond end of device

[Andries Brouwer]

On Sat, Sep 16, 2000 at 09:35:46AM -0400, Stephen E. Clark wrote:

> How do I relate dev 08:02 to my actual physical devices. I have 2 ide
> drives and 3 scsi drives.

dev 08:02 is /dev/sda2, your swap device.

> Sep 15 19:01:55 joker kernel: Adding Swap: 66020k swap-space (priority
> -1) 
> Sep 15 19:01:55 joker kernel: Adding Swap: 52412k swap-space (priority
> -2) 
> Sep 15 23:24:34 joker inetd[419]: pid 1458: exit status 1
> Sep 15 23:53:48 joker kernel: attempt to access beyond end of device 
> Sep 15 23:53:48 joker kernel: 08:02: rw=1, want=40164, limit=40162 
> Sep 15 23:53:48 joker kernel: dev 08:02 blksize=4096 blocknr=10040
> sector=80320 size=4096 count=1 

> /dev/hda3   swapswapdefaults   
> /dev/sda2   swapswapdefaults   

> /dev/hda3   251   381 66024   82  Linux swap
> /dev/sda26165 40162+  82  Linux swap

You see what happened:
You added /dev/sda2, a device that has 40162 blocks,
and told the kernel that it was good for 52412k swap space.

I seem to recall that I once fixed this, in the sense that
the kernel noticed a mismatch between the size of the swap device
and what the swap header says - but maybe that was only for 2.4
or perhaps it never got in - will check.
In the meantime it seems that your problems will be fixed
if you redo mkswap.

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

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> Ok, now could you tell me a way how to easily detect a "fake inode",
> and I rewrite my "restore ioctl functionality patch" in a way as not
> to break floppy root mounts.

s/root//

fake means NULL ->i_sb, nothing fancy about that. IS_RDONLY() used to be
very defensive and that's the only thing that didn't let this code blow
into your face from the very beginning. You can protect the call of
permission() with if (inode->i_sb). However,  I still think that it's
bogus - after a look at the ioctl list it seems that most of them are
sysctls in disguise (come on, verbosity level for debugging printk()s as
ioctl()?)

Probably the clean solution would be to add a character device per
controller (/dev/fdc), turning eject /dev/fd0 into
% echo eject 0 > /dev/fdc0
etc. Then access control is done via permissions of /dev/fdc* - no need
to make the driver aware of VFS guts, layout of struct inode, etc.

I can do that. It doesn't require any modifications to the core part of
the driver (trivial character device glue + tiny parser calling the same
functions that fd_ioctl() calls), so it should be reasonably safe.
I would really like to know what uses floppy-specific ioctls, though -
look at the callers would probably clarify the situation.

Comments?

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

Re: Preallocated skb's?

[jamal]

On Fri, 15 Sep 2000, Bogdan Costescu wrote:

> On Fri, 15 Sep 2000, jamal wrote:
> 
> > Only the timer runs at HZ granularity ;-<
> 
> Some cards provide their own high resolution timers; latest 3Com cards
> provide several with different purposes (none currently used). The
> question is how many of these also provide the Rx early interrupts.
> You also mentioned an auto-tunable Rx mitigation scheme. How do you
> implement it without using hardware timers ?
> 

Oh, the tulip 21143 explicitly has an interupt mitigation timer; this is
for both the tx and rx. But i see you can also use a general purpose timer
on the NIC to simulate mitigation.
disable rx interupts and other sources of noise (eg rx no buf) and set the
timer to wait a certain number of packet times.
Donald's drivers generally have this scheme built in; however, it is a
one-shot mode on rx work overload (mostly there for interupt sharing
according to one of Donald's old posts).
So what you do instead is have a table of these 'mitigation' values[1]
and select the appropriate mitigation value; i.e you have a pointer that
moves up and down the table and based on the load picks the correct
mitigation value.
When Robert Oks the current tulip, you should be able to see how it is
done there.

> > 20Msec is probably too much time. If my math is not wrong, 1 bit time in
> > a 100Mps is 1 ns; 64 bytes is 512ns.
> 
> I think your are wrong by a factor of 10 here, 1 bit time at 100Mbps
> should be 10 ns. Then 64 bytes is 5.12 us (u=micro). Anyway, this is
> comparable with the time needed to reach ISR, so you can have several
> (but small number) of packets already waiting for processing.
> 
> > You use the period(5-10micros), while waiting
> > for full packet arrival, to make the route decision (lookup etc).
> > i.e this will allow for a better FF; it will not offload things.
> 
> Just that you span several layers by doing this, it's not driver specific
> anymore.

I think we should heed Donald's advice on this early rx. I would take
Donald's word for it; he's been there done that. He knows.
eg the PCI burst issues makes a lot of sense. Unless someone with the
right tools (eg PCI bus monitors) might do some measurements and maybe
challenge Donald ;->

cheers,
jamal

[1] the table would look something like:
table[0] == 1 packet per interupt (default); disable timer
table[1] == 2 packets per interupt
table[3] == 3 packets per interupt 
.
.
etc.
use 64 bytes as the packet size since it is the smallest ethernet size.
as you pointed out that is 51.2 microsecs. so 102.4 microsecs for table[1]


-
To unsubscribe from this list: send 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.18pre7 [OOPS] + [PATCH]

[Andrzej Krzysztofowicz]

>From kufel!ankry  Fri Sep 15 23:04:36 2000
Return-Path: 
Received: from kufel.UUCP (uucp@localhost)
by green.mif.pg.gda.pl (8.9.3/8.9.3) with UUCP id XAA15722
for green.mif.pg.gda.pl!ankry; Fri, 15 Sep 2000 23:04:36 +0200
Received: (from ankry@localhost)
by kufel.dom (8.9.3/8.9.3) id XAA03971
for green!ankry; Fri, 15 Sep 2000 23:08:21 +0200
From: Andrzej Krzysztofowicz 
Message-Id: <[EMAIL PROTECTED]>
Subject: 2.2.18pre7 [OOPS] +  [PATCH]
To: kufel!green.mif.pg.gda.pl!ankry
Date: Fri, 15 Sep 2000 23:08:21 +0200 (CEST)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[EMAIL PROTECTED], cox

Hi,

   I think, I found accidentally a bug in the universal cdrom driver with no
/proc fs support. The following configuration gives me an oops during boot
(key options):

CONFIG_SYSCTL=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_QLOGIC_FAS=y
# CONFIG_PROC_FS is not set

Oops, and patch that fixes it for build-in cdrom.c follows.

Unfortunately I'm not sure whether it is correct, that MOD_INC_USE_COUNT /
MOD_DEC_USE_COUNT for cdrom module are called only via /proc interface and
can't work when /proc is disabled ...
Well, maybe the module is locked in an alteranative way ? Can anybody confirm
it ?


Unable to handle NULL pointer dereference at virtual address 001c
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
EFLAGS: 00010202
eax:    ebx: c01df3f8   ecx:    edx: c7ffc0e0
esi: c01df42c   edi: c7ff3018   ebp: 000b   esp: c7ff9f74
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, process nr: 1, stackpage=c7ff9000)
Stack: c01a1e33 c01c69cc  c7ff9fac c7ff3040  c019f930 c7ff3018
   c01df3c0    c7ff9fa8 00307273  c01ea343
   0f00 c01e1fd8 c0106000 c01e733d 0f00 c01e1fd8 c0106000 8000
Call Trace: [] [] [] [] [] 
[] []
   [] 
Code: c7 40 1c d0 65 1a c0 a1 cc f4 1d c0 a3 84 b3 20 c0 a1 d0 f4

4533 symbols from /usr/src/kernel/2.2/linux/System.map

EIP:   0xc01a65f6 t cdrom_sysctl_register+0x22/0x6c
trace: 0xc01a1e33 T register_cdrom+0x73/0x1d8
trace: 0xc01c69cc T stext_lock+0xf5d8/0x19f5c
trace: 0xc019f930 t sr_finish+0x128/0x178
trace: 0xc0106000 T get_options+0x0/0x74
trace: 0xc0106000 T get_options+0x0/0x74
trace: 0xc011ef48 T kswapd+0x0/0x9c
trace: 0xc0106093 t init+0x7/0x140
trace: 0xc0106527 T kernel_thread+0x23/0x30
code:   :
code: 0:c7 40 1c d0 65 1a c0movl   $0xc01a65d0,0x1c(%eax)
code: 7:a1 cc f4 1d c0  mov0xc01df4cc,%eax
code: c:a3 84 b3 20 c0  mov%eax,0xc020b384
code:11:a1  .byte 0xa1
code:12:d0  (bad)  
code:13:f4  hlt


--- drivers/cdrom/cdrom.c.old   Fri Sep 15 22:09:44 2000
+++ drivers/cdrom/cdrom.c   Fri Sep 15 22:48:28 2000
@@ -2557,6 +2557,7 @@
 
 static struct ctl_table_header *cdrom_sysctl_header;
 
+#ifdef CONFIG_PROC_FS
 /*
  * This is called as the fill_inode function when an inode
  * is going into (fill = 1) or out of service (fill = 0).
@@ -2573,6 +2574,7 @@
MOD_DEC_USE_COUNT;
}
 }
+#endif /* CONFIG_PROC_FS */
 
 static void cdrom_sysctl_register(void)
 {
@@ -2582,7 +2584,9 @@
return;
 
cdrom_sysctl_header = register_sysctl_table(cdrom_root_table, 1);
+#ifdef CONFIG_PROC_FS
cdrom_root_table->child->de->fill_inode = _procfs_modcount;
+#endif /* CONFIG_PROC_FS */
 
/* set the defaults */
cdrom_sysctl_settings.autoclose = autoclose;


-- 
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  tel.  (0-58) 347 14 61
Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

[Alexander Viro]

On Sat, 16 Sep 2000, Alain Knaff wrote:

> >FYI, here is a chunk of our conversation - I just realized that most of it
> >was private with AV and Linus so it is reasonable that you didn't see it.
> 
> Thanks for mailing me this. Well, I would have actually preferred to
> take part in this discussion when it first took place, rather than
> learning about it more than a month later. But hey, better late then
> never.

Oops... Mea culpa. Alain, my apologies for that.
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/

ISAPnP + Soundblaster doesn't work without 'multiple=0'

[Harald Dunkel]

Hi folks,

According to Documentation/sound/Soundblaster I have to report that
I had to set the option 'multiple=0' to make my Soundblaster16 work.
Without this option I get the following message at boot time:

:
:
Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
SB 4.13 detected OK (220)
sb: I/O region in use.
Sound: Hmm, DMA1 was left allocated - fixed
Sound: Hmm, DMA6 was left allocated - fixed
Unable to handle kernel paging request at virtual address c8866060
 printing eip:
c885844d
*pde = 012d8063
*pte = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010286
eax: c8866060   ebx: c120cd20   ecx:    edx: 
esi: c1282660   edi:    ebp:    esp: c7c95f08
ds: 0018   es: 0018   ss: 0018
Process aumix (pid: 65, stackpage=c7c95000)
Stack:  c1282660 c7d06500 c128e660  c1282660 c7d06500 c128e660 
   72616863 6a616d2d 312d726f c1280034 ffeb c0128394 c7d06500 c1282660 
   c1282660 c7d06500  c01276a9 c7d06500 c1282660 0002 0804ddb4 
Call Trace: [] [] [] [] [] 
Code: 8b 10 85 d2 74 1d 52 e8 cf cc 8b f7 83 c4 04 85 c0 74 14 8b 
:
:

This is the output of ksymoops:

ksymoops 2.3.4 on i586 2.4.0-test8.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test8/ (default)
 -m /usr/src/linux/System.map (specified)

Unable to handle kernel paging request at virtual address c8866060
c885844d
*pde = 012d8063
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: c8866060   ebx: c120cd20   ecx:    edx: 
esi: c1282660   edi:    ebp:    esp: c7c95f08
ds: 0018   es: 0018   ss: 0018
Process aumix (pid: 65, stackpage=c7c95000)
Stack:  c1282660 c7d06500 c128e660  c1282660 c7d06500 c128e660 
   72616863 6a616d2d 312d726f c1280034 ffeb c0128394 c7d06500 c1282660 
   c1282660 c7d06500  c01276a9 c7d06500 c1282660 0002 0804ddb4 
Call Trace: [] [] [] [] [] 
Code: 8b 10 85 d2 74 1d 52 e8 cf cc 8b f7 83 c4 04 85 c0 74 14 8b 

>>EIP; c885844d <[soundcore]soundcore_open+49/184>   <=
Trace; c0128394 
Trace; c01276a9 
Trace; c01275e3 
Trace; c01278d9 
Trace; c0108d23 
Code;  c885844d <[soundcore]soundcore_open+49/184>
 <_EIP>:
Code;  c885844d <[soundcore]soundcore_open+49/184>   <=
   0:   8b 10 mov(%eax),%edx   <=
Code;  c885844f <[soundcore]soundcore_open+4b/184>
   2:   85 d2 test   %edx,%edx
Code;  c8858451 <[soundcore]soundcore_open+4d/184>
   4:   74 1d je 23 <_EIP+0x23> c8858470 <[soundcore]sou
ndcore_open+6c/184>
Code;  c8858453 <[soundcore]soundcore_open+4f/184>
   6:   52push   %edx
Code;  c8858454 <[soundcore]soundcore_open+50/184>
   7:   e8 cf cc 8b f7call   f78bccdb <_EIP+0xf78bccdb> c0115128 
Code;  c8858459 <[soundcore]soundcore_open+55/184>
   c:   83 c4 04  add$0x4,%esp
Code;  c885845c <[soundcore]soundcore_open+58/184>
   f:   85 c0 test   %eax,%eax
Code;  c885845e <[soundcore]soundcore_open+5a/184>
  11:   74 14 je 27 <_EIP+0x27> c8858474 <[soundcore]sou
ndcore_open+70/184>
Code;  c8858460 <[soundcore]soundcore_open+5c/184>
  13:   8b 00 mov(%eax),%eax



This problem seems to be in since 2.4.0-test7. 




Please mail me if I can help to fix the problem. 


Regards

Harri
-- 
Harald Dunkel | [EMAIL PROTECTED] | If your operating system seems to
Synopsys GmbH | Kaiserstr. 100 | be made by Dr. Frankenstein, then
52134 Herzogenrath, Germany| it is time for a change.
+49 2407 9558 (fax? 44: 0) |Try Linux!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Ooops with 2.2.17

[Jens Hoffrichter]

Hi, 

On my Server just happenend a Kernel-Ooops, and afterwards some programs
crashed, e.g. "w" crashed with a Segmentation fault and "ps" crashed
with a Signal 11.

Recently I encountered Oopse on a regularly basis, but after upgrading
to 2.2.17, everything seemed to be alright, but now, 3 days later the
first oops after the upgrade occured.

The system is a AMD K5/PR100, 64 MB of RAM and a Debian Potato
installed.

I've included the decoded oops message and my kernel-config.

Thanks in advance,

Jens

 Output of ksymoops -

WARNING: This version of ksymoops is obsolete.
WARNING: The current version can be obtained from ftp://ftp.ocs.com.au/pub/ksymoops
Options used: -V (default)
  -o /lib/modules/2.2.17/ (default)
  -k /proc/ksyms (default)
  -l /proc/modules (default)
  -m /boot/System.map-2.2.17 (specified)
  -c 1 (default)

No modules in ksyms, skipping objects
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010206
eax: 0200   ebx: c36e4b60   ecx: c36e4fe0   edx: c36e4ddc
esi: 40074000   edi: c33e0140   ebp: 2000   esp: c18edefc
ds: 0018   es: 0018   ss: 0018
Process local (pid: 17436, process nr: 42, stackpage=c18ed000)
Stack:  b9ac c3655a20 c3197280  c36e47a0 c2b20990 0004
   c1858578 c0110f5c c33e0140 c1858578 ba20 c0110f53 c33e0140 
    c1634000 c33e0140 4014dddc  c0110f14 c33e0140 c18ec000
Call Trace: [] [] [] [] [] 
[] []
Code: 8b 40 08 85 c0 74 0b 83 c4 fc 55 56 53 ff d0 83 c4 10 8b 43

>>EIP: c011a692 
Trace: c0110f5c 
Trace: c0110f53 
Trace: c0110f14 
Trace: c011597a 
Trace: c0115971 
Trace: c0115b5d 
Trace: c0107a64 
Code:  c011a692   <_EIP>: <===
Code:  c011a692 0:8b 40 08mov
0x8(%eax),%eax <===
Code:  c011a695 3:85 c0   test   
%eax,%eax
Code:  c011a697 5:74 0b   je 
 c011a6a4 
Code:  c011a699 7:83 c4 fcadd
$0xfffc,%esp
Code:  c011a69c a:55  push   
%ebp
Code:  c011a69d b:56  push   
%esi
Code:  c011a69e c:53  push   
%ebx
Code:  c011a69f d:ff d0   call   
*%eax
Code:  c011a6a1 f:83 c4 10add
$0x10,%esp
Code:  c011a6a412:8b 43 00mov
0x0(%ebx),%eax


3 warnings issued.  Results may not be reliable.


 Kernel config ---

#
# Automatically generated make config: don't edit
#

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
CONFIG_M586=y
# CONFIG_M586TSC is not set
# CONFIG_M686 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
# CONFIG_PCI_OPTIMIZE is not set
CONFIG_PCI_OLD_PROC=y
# CONFIG_MCA is not set
# CONFIG_VISWS is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
# CONFIG_BINFMT_JAVA is not set
# CONFIG_PARPORT is not set
# CONFIG_APM is not set
# CONFIG_TOSHIBA is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_VIA82C586 is not set
# CONFIG_BLK_DEV_CMD646 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_IDE_CHIPSETS is not set

#
# Additional Block Devices
#
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_PARIDE_PARPORT=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_DEV_HD is not set

#
# Networking options
#
CONFIG_PACKET=y
# 

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Jamie Lokier]

[EMAIL PROTECTED] wrote:
> If we played some "zippy" music that would add to the "feel". Of
> course, we could actually use benchmarks instead.

Benchmarks, famed for their universal appeal :-)

> And, to me, if kernel compiles take longer, I don't care how fast it "feels".

A kernel compile _by itself_ should always run at full speed.

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

Re: 2.4.0-test8 tried to kill init! (addendum)

[Harley Anderson]

> This sounds like either some bit errors in memory
> (memtest86 will find those), or a device driver
> scribbling over memory, or the memory not being
> refreshed or operated at the right speed (memory
> to slow for the speed you're running it at?)...

Hmm, Andrew just informed me that the rtl8139 driver in test8 is pretty nasty. 
Does that sound like a probable suspect?
The card itself hasn't talked to anything in a few days, is it likely to mess
with memory if it isn't doing anything?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

VM comparison

[James Lewis Nance]

Hello All,
I am interested in Rik's new VM system so I am running some "How long does
it take to build mozilla" benchmarks.  I only have results for 2.2.17 and
2.4.0-test9-pre1 right now, but the results look very good and I wanted to
share them:

bessie> cat 2.2.17/time.*
4086.110u 544.630s 1:23:55.50 91.9% 0+0k 0+0io 4972913pf+8543w
4090.640u 524.060s 1:23:14.79 92.3% 0+0k 0+0io 4963086pf+4833w
4090.530u 516.750s 1:23:02.86 92.4% 0+0k 0+0io 4962276pf+2901w
4079.830u 523.390s 1:24:35.97 90.6% 0+0k 0+0io 4963914pf+3967w
bessie> cat 2.4.0-test9/time.*
3792.580u 354.240s 1:15:33.35 91.4% 0+0k 0+0io 4136435pf+0w
3813.200u 354.770s 1:15:17.04 92.2% 0+0k 0+0io 4136443pf+0w
3814.320u 356.090s 1:15:30.21 92.0% 0+0k 0+0io 4136452pf+0w

I want to add 2.4.0-test8 and 2.4.0-test-pre1+Rik'sfix to the list and I
also want to boot up with ram=48M to add more VM pressure.

Thanks,

Jim
-
To unsubscribe from this list: send the 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 2.2.18pre9

[Matthias Andree]

On Sat, 16 Sep 2000, Alan Cox wrote:

> Resynchronize the USB stuff and starting bringing the ARM into line
> 
> 2.2.18pre9
> o NFSv3 support and NFS updates   (Trond Myklebust and co)

Great. Will test.

-- 
Matthias Andree
-
To unsubscribe from this list: send the 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 Linux 2.4 Status/TODO list

[Marco d'Itri]

On Sep 15, Alexander Viro <[EMAIL PROTECTED]> wrote:

 >> I tried doing that for Andrea but I think it's not useful, active is
 >> mmapped and strace shows nothing interesting.
 >mmapped... Does mmap() go past the end of file?
I asked INN developers and they think it should not.
The file size is fixed and its fields are updated in place.

 >>  >BTW, how does test8+patch to block_truncate_page() behave?
There is no change, yesterday at shutdown the active file has not been
updated.

-- 
ciao,
Marco


-
To unsubscribe from this list: send the 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] Fix floppy ioctl (which were broken in 2.4.0-test5)

[Andries Brouwer]

On Sat, Sep 16, 2000 at 03:26:33PM +0200, Alain Knaff wrote:

> The following patch (against 2.4.0-test8) restores ioctl functionality,
> which has been broken in 2.4.0-test6-pre7:


> + /* Allow ioctls if we have write-permissions even if read-only open.
> +  * Needed so that programs such as fdrawcmd still can work on write
> +  * protected disks */
> + if ((filp->f_mode & 2) || (permission(inode,2) == 0))
> + filp->f_mode |= FD_IOCTL_MODE_BIT;


Strange obscure kludges.
In util-linux 2.10o fdformat was fixed to work with 2.4.0test6.
In util-linux 2.10p (not yet released) setfdprm is fixed.
Only if there are programs that cannot be fixed we should
look at the kernel code again. But not go back to the old state.

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