Re: [Semi-OT] Dual Athlon support in kernel

[Andrea Arcangeli]

On Tue, Apr 24, 2001 at 08:03:18AM +0200, Antwerpen, Oliver wrote:
> I am also highly interested in information about dual Athlon (which
> kernel/compiler/tools to use?), as we will get a dual Athlon sample before

kernel >= 2.4.3 (better >= 2.4.4pre2 for other rasons) compiled for K7 and
CONFIG_SMP=y, compiler as usual for the kernel gcc 2.95.[43] or egcs 1.1.2.

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

Re: [Semi-OT] Dual Athlon support in kernel

[Andrea Arcangeli]

On Tue, Apr 24, 2001 at 01:22:15AM -0400, Mike A. Harris wrote:
> Would the current state of athlon support be considered stable?

yes.

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

RE: [Semi-OT] Dual Athlon support in kernel

[Antwerpen, Oliver]

Moin Mike,

> From: Mike A. Harris [mailto:[EMAIL PROTECTED]]
> 
> Would the current state of athlon support be considered stable?
> I've got a colleague interested in getting a dual athlon box, and
> I'll be making the decision as to what hardware to purchase.  I'm
> wondering is dual Athlon viable for a business solution right
> now, or is it considered "experimental"?

I don't know if anyone can say if it's stable, as there are no dual Athlon
boxes out there yet.
 
> What hardware would be recommended for a dual CPU system that
> needs to be fairly rock solid?  Should I recommend to stay with
> the P-III Xeon?  Or something else?  What issues would I expect
> to have to deal with if going with a dual Athlon?

AFAIK Tyan is the only manufacturer building such a board (Thunder K7 /
S2562) right now. This will use AMD's 760MP Chipset with DDR memory support
up to 4GB, 5 64bit PCI slots, AGP pro, dual NIC (3c920), U160SCSI (aic7899).
The launch for dual Athlon is planned for June 4th.
If this will be rock-solid will be shown in the first weeks of Q3.
 
I am also highly interested in information about dual Athlon (which
kernel/compiler/tools to use?), as we will get a dual Athlon sample before
the launch.

Olli

-- 
Die Wahrheit liegt irgendwo da draußen...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUG: Global FPU corruption in 2.2

[alad]

Erik Paulson <[EMAIL PROTECTED]> on 04/24/2001 01:14:27 AM

To:   Christian Ehrhardt <[EMAIL PROTECTED]>
cc:   [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Amol Lad/HSS)

Subject:  Re: BUG: Global FPU corruption in 2.2




On 23 Apr 2001 18:11:48 +0200, Christian Ehrhardt wrote:
> On Thu, Apr 19, 2001 at 11:05:03AM -0500, Victor Zandy wrote:
> >
> > We have found that one of our programs can cause system-wide
> > corruption of the x86 FPU under 2.2.16 and 2.2.17.  That is, after we
> > run this program, the FPU gives bad results to all subsequent
> > processes.
>
<...>
>
> 3.) It might be interesting to know if the problem can be triggered:
> a) If pi doesn't fork, i.e. just one process calculating pi and
> another one doing the attach/detach.

Yes, we are still able to reproduce it without calling fork (the new
program just calls
do_pi() a bunch of times, and then we attach and detach to that process)

> b) If pi doesn't do FPU Operations, i.e. only the children call do_pi.
>

You seem to need to attach and detach to a program using the fpu -
running pt on a
process that is just busy-looping over and over some integer adds does
not seem to
while running pi on the machine at the same time, but not attaching to
it does not
seem to affect the floating point state.

 well... during context switching.. call to unlazy_fpu() does the following
if (current->flags & PF_USEDFPU)
  save_fpu();

somebody earlier pointed out, for the possible race when in sys_ptrace, at the
time of attach we modify child->flags.
It really looks again strange that it is software that is causing the problem as
the code to handle FPU looks pretty clean.
still can we check current->flags when the problem occurs ?


Amol


-Erik

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




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

Re: [lkml]Matrox FB console driver

[thunder7]

On Mon, Apr 23, 2001 at 08:06:11PM -0500, Andy Carlson wrote:
> I was playing around with a program that I was using to time differences
> between kernels (a silly prime program that puts out 100 primes).  I
> noticed a very strange behaviour.  On a fresh boot, with the Penguin
> pictures that the Matrox FB driver puts up, the prime program runs
> 1 minute, 30 seconds.  If I reset, it still runs 1M30S.  If I start X,
> and exit, it runs 48 seconds.  Is this a known behaviour?  Thanks.

is there any change in /proc/mtrr before and after X?

Good luck,
Jurriaan
-- 
BOFH excuse #176:

vapors from evaporating sticky-note adhesives
GNU/Linux 2.4.3-ac12 SMP/ReiserFS 2x1743 bogomips load av: 0.13 0.03 0.01
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Semi-OT] Dual Athlon support in kernel

[Mike A. Harris]

Would the current state of athlon support be considered stable?
I've got a colleague interested in getting a dual athlon box, and
I'll be making the decision as to what hardware to purchase.  I'm
wondering is dual Athlon viable for a business solution right
now, or is it considered "experimental"?

What hardware would be recommended for a dual CPU system that
needs to be fairly rock solid?  Should I recommend to stay with
the P-III Xeon?  Or something else?  What issues would I expect
to have to deal with if going with a dual Athlon?

Also, what is a good rock solid SCSI RAID controller?  Money is
no object.  Reliability, performance and Linux compatibility are
though.

Chipsets to avoid?

Any experiences/info good/bad would be greatly appreciated.



--
Mike A. Harris  -  Linux advocate  -  Free Software advocate
  This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--

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

rwsem benchmark [was Re: [PATCH] rw_semaphores, optimisations try #3]

[Andrea Arcangeli]

On Mon, Apr 23, 2001 at 11:34:35PM +0200, Andrea Arcangeli wrote:
> On Mon, Apr 23, 2001 at 09:35:34PM +0100, D . W . Howells wrote:
> > This patch (made against linux-2.4.4-pre6) makes a number of changes to the
> > rwsem implementation:
> > 
> >  (1) Everything in try #2
> > 
> > plus
> > 
> >  (2) Changes proposed by Linus for the generic semaphore code.
> > 
> >  (3) Ideas from Andrea and how he implemented his semaphores.
> 
> I benchmarked try3 on top of pre6 and I get this:
> 
> --
> RWSEM_GENERIC_SPINLOCK y in rwsem-2.4.4-pre6 + your latest #try3
> 
> rw
> 
> reads taken: 5842496
> writes taken: 3016649
> reads taken: 5823381
> writes taken: 3006773
> 
> r1
> 
> reads taken: 13309316
> reads taken: 13311722
> 
> r2
> 
> reads taken: 5010534
> reads taken: 5023185
> 
> ro
> 
> reads taken: 3850228
> reads taken: 3845954
> 
> w1
> 
> writes taken: 13012701
> writes taken: 13021716
> 
> wo
> 
> writes taken: 1825789
> writes taken: 1802560
> 
> --
> RWSEM_XCHGADD y in rwsem-2.4.4-pre6 + your latest #try3
> 
> rw
> 
> reads taken: 5789542
> writes taken: 2989478
> reads taken: 5801777
> writes taken: 2995669
> 
> r1
> 
> reads taken: 16922653
> reads taken: 16946132
> 
> r2
> 
> reads taken: 5650211
> reads taken: 5647272
> 
> ro
> 
> reads taken: 4956250
> reads taken: 4959828
> 
> w1
> 
> writes taken: 15431139
> writes taken: 15439790
> 
> wo
> 
> writes taken: 813756
> writes taken: 816005
> 
> graph updated attached. so in short my fast path is still quite faster (r1/w1),
> slow path is comparable now (I still win in all tests but wo which is probably
> the less interesting one in real life [write contention]). I still have room to
> improve the wo test [write contention] by spending more icache btw but it
> probably doesn't worth.

Ok I finished now my asm optimized rwsemaphores and I improved a little my
spinlock based one but without touching the icache usage.

Here it is the code against pre6 vanilla:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre6/rwsem-8

here the same but against David's try#2:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre6/rwsem-8-against-dh-try2

and here again the same but against David's latest try#3:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre6/rwsem-8-against-dh-try3

The main advantage of my rewrite are:

-   my x86 version is visibly faster than yours in the write fast path and it
also saves icache because it's smaller (read fast path is reproducibly a bit 
faster too)

-   my spinlock version is visibly faster in both read and write fast path and 
still
has smaller icache footprint (of course my version is completly out of line too
and I'm comparing apples to apples)

-   at least to me the slow path of my code seems to be much simpler
than yours (and I can actually understand it ;), for example I don't feel
any need of any atomic exchange anywhere, I admit now comparing
my code to yours I still don't know why you need it

-   the common code automatically extends itself to support 2^32 concurrent 
sleepers
on 64bit archs

-   there is no code duplication at all in supporting xchgadd common code logic
for other archs (and I prepared a skeleton to fill for the alpha)

Only disavantage is that sparc64 will have to fixup some bit again.

Here the numbers of the above patches on top of vanilla 2.4.4-pre6:

--
RWSEM_XCHGADD y in rwsem-2.4.4-pre6 + my latest rwsem

rw

reads taken: 5736978
writes taken: 2962325
reads taken: 5799163
writes taken: 2994404

r1

reads taken: 17044842
reads taken: 17053405

r2

reads taken: 5603085
reads taken: 5601647

ro

reads taken: 4831655
reads taken: 4833518

w1

writes taken: 16064773
writes taken: 16037018

wo

writes taken: 860791
writes taken: 864103

--
RWSEM_SPINLOCK y in rwsem-2.4.4-pre6 + my latest rwsem

rw

reads taken: 6061713
writes taken: 3129801
reads taken: 6099046
writes taken: 3148951

r1

reads taken: 14251500
reads taken: 14265389

r2

reads taken: 4972932
reads taken: 4936267

ro

reads taken: 4253814
reads taken: 4253432

w1

writes taken: 13652385
writes taken: 13632914

wo

writes taken: 1751857
writes taken: 1753608

I draw a graph with the above numbers compared to the previous quoted numbers I
generated a few hours ago with your latest try#3 (attached). (W1 and R1 are
respectively the benchmark of the write fast path and read fast path, only one
writer and only one reader and they're of course the most interesting ones)

So I'd suggest Linus to apply one of my above -8 patches for pre7. (I hope I
won't need any secondary try)

this is a diffstat of the rwsem-8 patch:

 arch/alpha/config.in  |1 
 

Re: USB problems since 2.4.2

[Johannes Erdfelt]

On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote:
> 
> > On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote:
> > > Kernel: 2.4.2 - latest (2.4.3-ac12)
> > > Platform: x86 on mangled Slack7.1
> > > Hardware: MSI 694D Pro-AR
> > > ( http://www.msicomputer.com/products/detail.asp?ProductID=150 )
> > > 
> > > Problem: USB devices timeout on address assignment. Course thats with the
> > > non JE driver, with the JE driver the bus doesnt even say that anything
> > > gets connected.
> > > 
> > > when any device is plugged in:
> > > *
> > > hub.c: USB new device connect on bus1/1, assigned device number 4
> > > usb_control/bulk_msg: timeout
> > > usb.c: USB device not accepting new address=4 (error=-110)
> > > hub.c: USB new device connect on bus1/1, assigned device number 5
> > > usb_control/bulk_msg: timeout
> > > usb.c: USB device not accepting new address=5 (error=-110)
> > > *
> > 
> > Can you try booting your kernel with the "noapic" option and see if it
> > still happens?
> 
> DING DING DING!  that did the trick. Thnx!

It's less than optimal however. You have an IRQ routing problem with
your I/O APIC's it seems. A BIOS upgrade may fix this, but I don't know
if it will in your particular case.

"noapic" will make things work atleast, but everything will be sent to
one CPU (assuming you have more than one CPU :)

JE

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

Re: USB problems since 2.4.2

[josh]

> On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote:
> > Kernel: 2.4.2 - latest (2.4.3-ac12)
> > Platform: x86 on mangled Slack7.1
> > Hardware: MSI 694D Pro-AR
> > ( http://www.msicomputer.com/products/detail.asp?ProductID=150 )
> > 
> > Problem: USB devices timeout on address assignment. Course thats with the
> > non JE driver, with the JE driver the bus doesnt even say that anything
> > gets connected.
> > 
> > when any device is plugged in:
> > *
> > hub.c: USB new device connect on bus1/1, assigned device number 4
> > usb_control/bulk_msg: timeout
> > usb.c: USB device not accepting new address=4 (error=-110)
> > hub.c: USB new device connect on bus1/1, assigned device number 5
> > usb_control/bulk_msg: timeout
> > usb.c: USB device not accepting new address=5 (error=-110)
> > *
> 
> Can you try booting your kernel with the "noapic" option and see if it
> still happens?
> 

DING DING DING!  that did the trick. Thnx!

  www.mammoth.org/~skulcap
**BEGIN GEEK CODE BLOCK
"Sometimes, if you're perfectly  * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- 
still, you can hear the virgin   * W+(++) N++ o+ K- w--(---) O- M- V- PS-- 
weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++  
 --DreamTheater, "Lines in the Sand" * G e h+ r-- y-   (www.geekcode.com)
**END GEEK CODE BLOCK**

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

Re: aic7xxx: first mount always fails

[Justin T. Gibbs]

>
>The first attempt at mounting a disc in my Traxdata CDR drive after
>boot always fails. From the second on, everything works flawlessly.
>Current setup is 2.2.18 kernel + 6.1.11-2.2.18 patch, but I've been
>experiencing this behaviour since I bought the adapter (around 2.2.12 or so).
>aic7xxx gets loaded as a module.
>Here's some diagnostic info from the failed mount. If more is needed,
>please let me know.  (of course, a disc _is_ present in the drive).

My guess is that your CDROM drive takes longer than most to perform
the initial read capacity.  There is little to be done for this other
than uping the timeout value in the CD driver.

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

SANE

[Jim M.]

Hi,
I have a scsi camera of unknown brand and type. No driver. It has CCD chip 
on it.
Can I use SANE as an interface to this camera?. I need to control it using 
my app that
talks to SANE.
J
_
Get your FREE download of MSN Explorer at http://explorer.msn.com

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

Re: hundreds of mount --bind mountpoints?

[Andreas Dilger]

Ed Tomlinson writes:
> > Consider, when I was doing some fs benchmark, my inode slab cache was
> > over 120k items on a 128MB machine.  At 480 butes per inode, this is
> > almost 58 MB, close to half of RAM.  Reducing this to exactly ext2
> > sized inodes would save (50 - 27) * 4 * 120k = 11MB of memory (on 32-bit
> > systems)!!! (This assumes nfs_inode_info is the largest).
> 
> Was this with a recient kernel (post Alexander Viro's dcache pressure fix)?  
> If not I suggest rerunning the benchmark.  I had/have a patch to apply
> pressure to the dcache and icache from kswapd but its not been needed here
> since the above fix.

Actually, it had the dcache patch but I'm not aware of a patch from Al to
change icache behaviour.  In any case, changing the icache behaviour is
not what I'm getting at here - having the union of all private inode
structs in the generic inode is a huge waste of RAM.  Even for filesystems
that are heavy NFS users, they will likely still have a considerable amount
of local filesystem space (excluding NFS root systems, which are very few).

Al posted a patch to the NFS code which removes nfs_inode_info from the
inode union.  Since it is (AFAIK) the largest member of the union, we
have just saved 24 bytes per inode (hfs_inode_info is also rather large).
If we removed hfs_inode_info as well, we would save 108 bytes per inode,
about 22% ({ext2,affs,ufs}_inode_info are all about the same size).

No point in punishing all users for filesystems they don't necessarily use.
Even for people that DO use NFS and/or HFS, they are probably still wasting
10k inodes * 108 bytes = 1MB of RAM for no good reason (because most of
their inodes are probably not NFS and/or HFS).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[Douglas Gilbert]

[EMAIL PROTECTED] wrote:
> 
> [snip]
> 
> Doug suggested looking at extending scsimon.  This is a fine idea, and I've
> made proposed changes available at http://domsch.com/linux/scsi/.  (Doug may
> want to clean this up).  However, this, like my earlier changes to
> /proc/scsi/scsi, doesn't actually show the relationship between /dev/sda and
> a particular PCI controller and SCSI channel,bus,lun tuple.

Changes look ok. One suggestion: if a #define SCSI_PCI_INFO
(or some such) is defined in driver/scsi/scsi.h as part of
the patch then code like Matt is suggesting can be safely 
added, protected by "#ifdef SCSI_PCI_INFO ... #endif" blocks. 
I have used this technique in sg to support the scsi 
"reset+reservation" patch which still hasn't made it into 
the mid level (but is available in many distros).

The scsimon driver is just a window through to the information
held in the mid level structures. The information printed by
'cat /proc/scsi/scsi' also comes from the mid level. The scsi 
minor device numbers (e.g. /dev/sda) are allocated by each upper 
level driver  (e.g. sd_attach() in the case of sd) and are held 
in upper level driver data structures. Hence they are not 
visible to the mid-level or to other upper level drivers.

As an example of the latter point, using st and sg on the same 
tape device at the same time will most likely confuse st 
(since it maintains a state machine). However there is no 
simple way for the sg or st drivers to detect (or supply
information flagging) this conflict.

Doug Gilbert

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

serial driver not properly detecting modem

[Steven Walter]

It would seem that I have a modem (hardware based, not winmodem) of
PCI_CLASS_COMMUNICATION_OTHER.  This, unfortunately, prevents it from
being automagically detected by the serial driver, which only looks for
devices of PCI_CLASS_COMMUNICATION_SERIAL.

I've fixed this here merely by adding an entry to the PCI table of
serial.c for PCI_CLASS_COMMUNICATION_OTHER.  Is this the best way to fix
this?  Is there some reason that this shouldn't be done in general?  If
not, I'd like to see it fix in the kernel proper.

It should be noted that the modem is listed in serial.c's pci_boards,
perhaps it would be best for the serial driver to list PCI_ID_ANY for a
class, and only use pci_boards to further identify serial ports?  Or
would this be too inefficient to correct for a few misguided hardware
makers?

Thanks
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: USB problems since 2.4.2

[Johannes Erdfelt]

On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote:
> Kernel: 2.4.2 - latest (2.4.3-ac12)
> Platform: x86 on mangled Slack7.1
> Hardware: MSI 694D Pro-AR
> ( http://www.msicomputer.com/products/detail.asp?ProductID=150 )
> 
> Problem: USB devices timeout on address assignment. Course thats with the
> non JE driver, with the JE driver the bus doesnt even say that anything
> gets connected.
> 
> when any device is plugged in:
> *
> hub.c: USB new device connect on bus1/1, assigned device number 4
> usb_control/bulk_msg: timeout
> usb.c: USB device not accepting new address=4 (error=-110)
> hub.c: USB new device connect on bus1/1, assigned device number 5
> usb_control/bulk_msg: timeout
> usb.c: USB device not accepting new address=5 (error=-110)
> *

Can you try booting your kernel with the "noapic" option and see if it
still happens?

JE

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

Re: [PATCH] Move __GFP_IO check in shrink_icache_memory to prune_icache()

[Marcelo Tosatti]

On Mon, 23 Apr 2001, Marcelo Tosatti wrote:

> 
> Linus,
> 
> With the prune_icache() modifications which were integrated in pre5 there
> is no more need to avoid non __GFP_IO allocations to go down to
> prune_icache().
> 
> The following patch moves the __GFP_IO check down to prune_icache(),
> allowing !__GFP_IO allocations to free clean unused inodes.

Forget about this. 

We may have to write quota information back to disk while freeing the
inode and then we are fucked. 

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

Re: Problem with i810_audio driver

[Doug Ledford]

Eugene Kuznetsov wrote:
> 
> Hello,
> 
>   I am a happy owner of Intel D815EEA2 mother board. This board
> comes with integrated AC-97 audio. When I try to load i810_audio
> driver for it, driver identifies the device as
> "Intel 810 + AC97 Audio, version 0.02, 19:43:23 Apr 20 2001
> i810: Intel ICH2 found at IO 0xef00 and 0xe800, IRQ 6
> ac97_codec: AC97 Audio codec, id: 0x4144:0x5360 (Analog Devices
> AD1885)"
> and later brings the system into one of three possible conditions.
> A) a bit later it says:
>i810_audio: 11168 bytes in 50 milliseconds
>i810_audio: setting clocking to 41260 to compensate
> In this case everything is fine ( 16-bit sound is played correctly, I
> don't need much more ... ).

Write that number down.  You can add it to your /etc/modules.conf file if you
like.  If the new driver sees that the clocking variable has been set to
anything other than 48000 it doesn't run the clocking autodetect routine.

> B) It says:
>i810_audio: 65528 bytes in 50 milliseconds
>i810_audio: setting clocking to 7032 to compensate
> In this case the sound does not work at all - sound card does not
> produce anything but silence. With versions of kernel up to 2.4.3 I
> also received a lot of "DMA buffer overrun on send" messages in dmesg
> when playing anything.
> C) Last condition is relatively rare. It says something similar to
> case A, but number of bytes is multiple of 11168 and clocking is lower
> ( e.g. 13753 = 41260/3 ). Sound card works, but output quality is
> quite low.
> Which of cases A)..C) takes place, seems to be random ( I haven't
> noticed any pattern ). However, attempts to do rmmod/insmod
> do not have any effect. I have to at least reboot the system a few
> times to bring the sound to working state.

Both B and C are cases of the whole chip acting flat busted.  I would suspect
that possibly Win2k drivers set this thing up some way that we don't recover
from.  Is there any pattern like maybe "I listen to X in Win2k then reboot to
linux and sound is screwed" or something like that?  Also, when it does
happen, does shutting down and then actually powering the machine off
(possibly by going so far as to unplug the machine for 5 seconds or so to
overcome any low power state savings on modern motherboards) make it reliably
come back instead of having to reboot multiple times?  Does this ever happen
if you just unload/reload the module without rebooting inbetween (aka, does
the linux driver module sometimes trigger the problem)?  Finally, when B or C
does happen, can you get the module to work by loading the module with the
clocking= option set to the correct clocking value from A?

> I tried driver from kernels 2.4.1, 2.4.3 and 2.4.4-pre4. All of them
> behave more or less in the same way.
> In Windows 2000 this motherboard/audio device works without any problems.
> I can provide any additional information if it helps to solve the bug.
> Please cc: me, because I am not subscribed to the list.
> 
> --
> Best regards,
>  Eugene
> mailto:[EMAIL PROTECTED]
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

 Doug Ledford <[EMAIL PROTECTED]>  http://people.redhat.com/dledford
  Please check my web site for aic7xxx updates/answers before
  e-mailing me about problems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Idea: Encryption plugin architecture for file-systems

[David L. Nicol]

Dale Amon wrote:
> 
> Talk about syncronicity... I had just last week asked
> about the pro's and con's on this on the crypto list and
> have heard nothing at all back. So I'll drop the body
> of that message in here:


why not port one of the twenty or thirty preexisting tools
that let you mount a filesystem from an encrypted file instead
of making a generic layer?  That way you could have inter-os 
portability.  The steganographic ones make really impressive
claims.  

Does linux have a truly generic plug-in file system module yet,
or are people still hacking around fake nfs servers? 




-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
"Described as awesome by users"

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

Re: hundreds of mount --bind mountpoints?

[Alexander Viro]

On Mon, 23 Apr 2001, Jan Harkes wrote:

> On Mon, Apr 23, 2001 at 10:45:05PM +0200, Ingo Oeser wrote:

> > BTW: Is it still less than one page? Then it doesn't make me
> >nervous. Why? Guess what granularity we allocate at, if we
> >just store pointers instead of the inode.u. Or do you like
> >every FS creating his own slab cache?

Oh, for crying out loud. All it takes is half an hour per filesystem.
Here - completely untested patch that does it for NFS. Took about that
long. Absolutely straightforward, very easy to verify correctness.

Some stuff may need tweaking, but not much (e.g. some functions
should take nfs_inode_info instead of inodes, etc.). From the look
of flushd cache it seems that we would be better off with cyclic
lists instead of single-linked ones for the hash, but I didn't look
deep enough.

So consider the patch below as proof-of-concept. Enjoy:

diff -urN S4-pre6/fs/nfs/flushd.c S4-pre6-nfs/fs/nfs/flushd.c
--- S4-pre6/fs/nfs/flushd.c Sat Apr 21 14:35:21 2001
+++ S4-pre6-nfs/fs/nfs/flushd.c Mon Apr 23 22:23:11 2001
@@ -162,11 +162,11 @@
 
if (NFS_FLAGS(inode) & NFS_INO_FLUSH)
goto out;
-   inode->u.nfs_i.hash_next = NULL;
+   NFS_I(inode)->hash_next = NULL;
 
q = >inodes;
while (*q)
-   q = &(*q)->u.nfs_i.hash_next;
+   q = _I(*q)->hash_next;
*q = inode;
 
/* Note: we increase the inode i_count in order to prevent
@@ -188,9 +188,9 @@
 
q = >inodes;
while (*q && *q != inode)
-   q = &(*q)->u.nfs_i.hash_next;
+   q = _I(*q)->hash_next;
if (*q) {
-   *q = inode->u.nfs_i.hash_next;
+   *q = NFS_I(inode)->hash_next;
NFS_FLAGS(inode) &= ~NFS_INO_FLUSH;
iput(inode);
}
@@ -238,8 +238,8 @@
cache->inodes = NULL;
 
while ((inode = next) != NULL) {
-   next = next->u.nfs_i.hash_next;
-   inode->u.nfs_i.hash_next = NULL;
+   next = NFS_I(next)->hash_next;
+   NFS_I(inode)->hash_next = NULL;
NFS_FLAGS(inode) &= ~NFS_INO_FLUSH;
 
if (flush) {
diff -urN S4-pre6/fs/nfs/inode.c S4-pre6-nfs/fs/nfs/inode.c
--- S4-pre6/fs/nfs/inode.c  Sat Apr 21 14:35:21 2001
+++ S4-pre6-nfs/fs/nfs/inode.c  Mon Apr 23 22:43:45 2001
@@ -40,11 +40,14 @@
 #define NFSDBG_FACILITYNFSDBG_VFS
 #define NFS_PARANOIA 1
 
+static kmem_cache_t *nfs_inode_cachep;
+
 static struct inode * __nfs_fhget(struct super_block *, struct nfs_fh *, struct 
nfs_fattr *);
 void nfs_zap_caches(struct inode *);
 static void nfs_invalidate_inode(struct inode *);
 
 static void nfs_read_inode(struct inode *);
+static void nfs_clear_inode(struct inode *);
 static void nfs_delete_inode(struct inode *);
 static void nfs_put_super(struct super_block *);
 static void nfs_umount_begin(struct super_block *);
@@ -52,6 +55,7 @@
 
 static struct super_operations nfs_sops = { 
read_inode: nfs_read_inode,
+   clear_inode:nfs_clear_inode,
put_inode:  force_delete,
delete_inode:   nfs_delete_inode,
put_super:  nfs_put_super,
@@ -96,23 +100,44 @@
 static void
 nfs_read_inode(struct inode * inode)
 {
+   struct nfs_inode_info *nfsi;
+
+   nfsi = kmem_cache_alloc(nfs_inode_cachep, GFP_KERNEL);
+   if (!nfsi)
+   goto Enomem;
+
inode->i_blksize = inode->i_sb->s_blocksize;
inode->i_mode = 0;
inode->i_rdev = 0;
+   inode->u.generic_ip = nfsi;
NFS_FILEID(inode) = 0;
NFS_FSID(inode) = 0;
NFS_FLAGS(inode) = 0;
-   INIT_LIST_HEAD(>u.nfs_i.read);
-   INIT_LIST_HEAD(>u.nfs_i.dirty);
-   INIT_LIST_HEAD(>u.nfs_i.commit);
-   INIT_LIST_HEAD(>u.nfs_i.writeback);
-   inode->u.nfs_i.nread = 0;
-   inode->u.nfs_i.ndirty = 0;
-   inode->u.nfs_i.ncommit = 0;
-   inode->u.nfs_i.npages = 0;
+   INIT_LIST_HEAD(>read);
+   INIT_LIST_HEAD(>dirty);
+   INIT_LIST_HEAD(>commit);
+   INIT_LIST_HEAD(>writeback);
+   nfsi->nread = 0;
+   nfsi->ndirty = 0;
+   nfsi->ncommit = 0;
+   nfsi->npages = 0;
NFS_CACHEINV(inode);
NFS_ATTRTIMEO(inode) = NFS_MINATTRTIMEO(inode);
NFS_ATTRTIMEO_UPDATE(inode) = jiffies;
+   return;
+
+Enomem:
+   make_bad_inode(inode);
+   return;
+}
+
+static void
+nfs_clear_inode(struct inode * inode)
+{
+   struct nfs_inode_info *p = NFS_I(inode);
+   inode->u.generic_ip = NULL;
+   if (p)
+   kmem_cache_free(nfs_inode_cachep, p);
 }
 
 static void
@@ -594,7 +619,7 @@
NFS_CACHE_ISIZE(inode) = fattr->size;
NFS_ATTRTIMEO(inode) = NFS_MINATTRTIMEO(inode);
NFS_ATTRTIMEO_UPDATE(inode) = jiffies;
-   memcpy(>u.nfs_i.fh, fh, sizeof(inode->u.nfs_i.fh));
+   memcpy(NFS_FH(inode), fh, sizeof(struct nfs_fh));
}

Re: i810_audio broken?

[Doug Ledford]

Chmouel Boudjnah wrote:
> 
> "Pawel Worach" <[EMAIL PROTECTED]> writes:
> 
> > I was using mpg123 (xmms and c/o does exactly the same)
> > if I run it like this Moby sounds very stupid... :)
> 
> i got the same problem when using mpg123 compiled with esd on my dell
> workstation (which has a need to have set explictely to a clocking of
> 41194 via ftsodell option), compiling without esd seems fix the prob
> for me.

The latest i810 driver does away with the ftsodell option entirely and should
work on your laptop without having to do anything special.

-- 

 Doug Ledford <[EMAIL PROTECTED]>  http://people.redhat.com/dledford
  Please check my web site for aic7xxx updates/answers before
  e-mailing me about problems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[Jeff Garzik]

[EMAIL PROTECTED] wrote:
> 
> > PCI ids can be derived from bus/slot/function.
> 
> Even better.  I'll remove the extraneous fields then, and only return those.
> 
> typedef struct scsi_pci {
> unsigned char   bus_number;
> unsigned intdevfn;  /* encoded device & function index
> */
> } Scsi_Pci;

Why not pci_dev::slot_name?  Presumeably the only reason you need this
is to export it to userspace...  We already have the ASCII text there,
please consider using that :)

-- 
Jeff Garzik  | The difference between America and England is that
Building 1024| the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC][PATCH] adding PCI bus information to SCSI layer

[Matt_Domsch]

> PCI ids can be derived from bus/slot/function.

Even better.  I'll remove the extraneous fields then, and only return those.

typedef struct scsi_pci {
unsigned char   bus_number;
unsigned intdevfn;  /* encoded device & function index
*/
} Scsi_Pci;

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux


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

USB problems since 2.4.2

[josh]

Kernel: 2.4.2 - latest (2.4.3-ac12)
Platform: x86 on mangled Slack7.1
Hardware: MSI 694D Pro-AR
( http://www.msicomputer.com/products/detail.asp?ProductID=150 )

Problem: USB devices timeout on address assignment. Course thats with the
non JE driver, with the JE driver the bus doesnt even say that anything
gets connected.

messages when driver loads:
*
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.251 $ time 00:58:23 Apr 23 2001
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: USB UHCI at I/O 0xb000, IRQ 19
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: USB UHCI at I/O 0xb400, IRQ 19
usb-uhci.c: Detected 2 ports
hub.c: USB new device connect on bus1/1, assigned device number 2
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver usblp
usb.c: registered new driver dc2xx
*
  
when any device is plugged in:
*
hub.c: USB new device connect on bus1/1, assigned device number 4
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=4 (error=-110)
hub.c: USB new device connect on bus1/1, assigned device number 5
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=5 (error=-110)
*



  www.mammoth.org/~skulcap
**BEGIN GEEK CODE BLOCK
"Sometimes, if you're perfectly  * GCS d- s: a-- C++ ULSC$ P+ L+++ E--- 
still, you can hear the virgin   * W+(++) N++ o+ K- w--(---) O- M- V- PS-- 
weeping for the savior of your will."* PE Y+ PGP t+ 5 X+ R !tv b+>+++ DI++ D++  
 --DreamTheater, "Lines in the Sand" * G e h+ r-- y-   (www.geekcode.com)
**END GEEK CODE BLOCK**

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

Re: hundreds of mount --bind mountpoints?

[Jan Harkes]

On Mon, Apr 23, 2001 at 10:45:05PM +0200, Ingo Oeser wrote:
> Last time we suggested this, people ended up with some OS trying
> it and getting worse performance. 
> 
> Why? You need to allocate the VFS-inode (vnode in other OSs) and
> the on-disk-inode anyway at the same time. You get better
> performance and less fragmentation, if you allocate them both
> together[1].
> 
> So that struct inode around is ok.
> 
> BTW: Is it still less than one page? Then it doesn't make me
>nervous. Why? Guess what granularity we allocate at, if we
>just store pointers instead of the inode.u. Or do you like
>every FS creating his own slab cache?

I've actually got the coda_inode_info (inode->u.u_coda_fs_i) split out
of the union in my development kernel. It doesn't shrink the size of the
struct inode yet, Coda isn't the biggest user at the moment.

But, it forced me to do several cleanups in the code, and it even has
resulted in fixing a 'leak'. Not a real memory loss leak one, but we
left uninitialized inodes around in the icache for no good reason. Also
changing a but in a coda specific header file does trigger an almost
complete rebuild of the whole kernel (coda.h -> coda_fs_i.h -> fs.h ->
everything?)

The allocation overhead really isn't that bad. kmalloc/kfree are also
using the slabcache, and a trivial variant using a 'private' slabcache
gave me the counters to find the 'leak' I mentioned before.

I can't really evaluate performance impacts. The struct inode is still
the same size, so for now there even is a little bit of additional
memory pressure. Also, Coda wasn't really developed to achieve high
performance but more to explore novel features.

Jan

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

Re: [upatch] lib/Makefile

[Peter Samuelson]

  [Peter Samuelson]
> > Introduced in 2.4.4pre4, I believe.  $(export-objs) need not be
> > conditional, and the if statement was not really correct either,
> > although in this case it probably worked.

[Tom Rini]
> Er, are you sure changing the test for !"nn" is correct here?  I
> _think_ at least that is intentional and correct (since you can have
> one on but not the other).

I understand the intent.  The point is that in our current makefiles
you are not allowed to assume that a negative value is "n", because it
could be "".

2.4.4pre probably works because each 'config.in' file explicitly sets
these variables to "y" or "n".  However, it would be perfectly legal
for a config.in to unset the variable, or for that matter not even
mention it.  In that case the !"nn" test fails.

This is the same reason you cannot use 'ifdef CONFIG_*' in the
Makefiles.  Lots of people do, but each instance is a bug.  They are
assuming the opposite: that a variable will be "" rather than "n".

(N.B. this issue will go away with Keith's 2.5 Makefiles.  And there
was much rejoicing.)

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

Got a Kernel OOPS, and the problem with OOPS itself.

[Ishikawa]

I got a kernel oops today.

I had oopses twice this month.

One thing I noticed about the latest kernel oopses in 2.4.3 and
2.4.4-pre4 which I am using:
while I manually tried to copy the OOPS dump info on the CRT
screen, somehow the interrupt was NOT disabled (!?) and
some stray interrupt from peripheral or something
triggered the oops process AGAIN.
So the information was scrolled up and new data
was dumped. The attached ksymoops output is
such output from the second oops.
The original screen dump was being recorded but  before
I came down to the Call Trace part, the screen scrolled
with the new oops message. Hmm...
This occured with the todays OOPS. The last OOPS a few weeks ago
was worse in that the machine then rebooted!?

I wonder if the interrupt can be totally disabled before
the OOPS message is printed.
Or maybe the kernel bug is such that the interrupt handling
is in a funny state when OOPS condition occurs.
I have never had this problem in recording oopses before.
I was no stranger to oopses while I had a scsi driver debugged
by the maintainer to handle multi-lun CD changer.
So I wrote down screenful of oops messages many times and
not a single problem like this on earlier kernel versions.

Will anyone kindly look into the possibility of loose
software/hardware
interrupt not disabled when OOPS dumping occurs?

Anyway, here is the output of
ksymoops for the second screenfull of dump when
an OOPS occured today.

(At the end, I attach the partial listing of the
first screenful of messages before it was scrolled and gone.)

Considering what happened as explained above, the original oops
probably came from do_page_fault.
The system crashed while I was typing something using emacs.

KERNEL :
Linux duron 2.4.4-pre4 #15 Thu Apr 19 01:58:23 JST 2001 i686 unknown
AMD Duron 750Mhz. 256MB memory, 80MB swap.


ishikawa@duron$ !ksy
ksymoops < oops-2001-04-24-b.txt
ksymoops 2.3.7 on i686 2.4.4-pre4.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.4-pre4/ (default)
 -m /boot/System.map-2.4.4-pre4 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

(*** CAUTION: The following line and up and EIP values are bogus
 for this screenful info. They were recorded from the first
screenful,
 but subsequently replaced by a new screenful as explained above.
***)

Unable to handle kernel NULL pointer reference at runtime address 0
(ditto for this line and the next eip!)
c01189e0

(*** The values below are valid for the second screenful of oops.
 Call trace grew from the first screenful, and so may have the
 original call trace PLUS whatever caused the second oops dump
 (probably some type of interrupt. )
  ***)

*pde = 
EFLAGS: 00010202
eax: 0010 ebx: 5000 ecx: 0020 edx: cff07144
esi: 0070 edi: 001c ebp: d080 esp: cefdbc80
Process (pid: 0, Stackpage=cefdb000)
Stack: 5000 cff07140 cff07000 d080 cff07144 5000 0001
0020
   cff07140 c0185969 cff07000 cfbf1d80 0401 000b cefdbd0c
5048
   0014 c0107f7f 000b cff07000 cefdbd0c 02c0 c028dbc0
000b
Call Trace: [][][][]
 [][][][]
 [][][][]
 [][][][]
 [][][][]
 [][][][]
 [][][][]
 [][]
Code: 8b 18 8b 48 0c 81 e1 ff 3f 00 00 89 4c 24 14 66 85 db 0f 8d
Using defaults from ksymoops -t elf32-i386 -a i386

Trace; d080 <_end+105467d0/105577d0>
Trace; c0107192 
Trace; c010f587 
Trace; c010f250 
Trace; c01195cc 
Trace; c0119705 
Trace; c0106d88 
Trace; c01189e0 
Trace; c0118a45 
Trace; c010ad46 
Trace; c0115fbb 
Trace; c0115ed8 
Trace; c0115dcf 
Trace; c0108131 
Trace; c0106d14 
Trace; c01120b0 
Trace; c0114c5f 
Trace; c010f250 
 Trace; c0107192 
Trace; c010f587 
Trace; c010f250 
Trace; c0106d88 
Trace; c0178b80 
Trace; c0178b9c 
Trace; c010f250 
Trace; c0178b9c 
Trace; c01fe086 
Trace; c0178b80 
Trace; c0178b80 
Trace; c010f2ae 
Code;   Before first symbol

(*** The objdump's address can't be trusted because
 EIP for the second screenful of OOPS scrolled up and could not
 be seen. Scrolling up probably occurred due to the longer
 call trace dump.
 But the code data itself is correct. ***)

 <_EIP>:
Code;   Before first symbol
   0:   8b 18 mov(%eax),%ebx
Code;  0002 Before first symbol
   2:   8b 48 0c  mov0xc(%eax),%ecx
Code;  0005 Before first symbol
   5:   81 e1 ff 3f 00 00 and$0x3fff,%ecx
Code;  000b Before first symbol
   b:   89 4c 24 14   mov%ecx,0x14(%esp,1)
Code;  000f Before first symbol
   f:   66 85 

Device Registry (DevReg) Patch 0.2.0

[Tim Jansen]

The Linux Device Registry (devreg) is a kernel patch that adds a device 
database in XML format to the /proc filesystem. It collects all information 
about the system's physical devices, creates persistent device ids and 
provides them in the file /proc/devreg.

Devreg has three purposes:
- collect all configuration data from drivers so the user can browse his 
hardware configuration. 
-allow an application to display all devices that provide a certain interface 
(for example all mice) so the user can chose one. 
-allow an application to find the device that the user has selected after a 
reboot or a hotplug action: the device files in /dev do not offer stable 
names, they depend on the order in that the devices have been plugged in or 
powered on. 

Changes since last release (0.1.1):
- converted file format to XML
- bus-specific information from pci and usb added
- fixed locking

The patch (for 2.4.3) can be found at 
http://www.tjansen.de/devreg/devreg-2.4.3-0.2.0.diff.gz
To test it, apply the patch, select CONFIG_DEVFS_FS and CONFIG_DEVREG and 
compile. Note that the patch will break binary drivers.

Supported hardware in version 0.2.0: PCI subsystem, USB subsystem, most PCI 
sound cards, USB HID devices, USB hubs, USB printers

Other information and a user-space library can be found at 
http://www.tjansen.de/devreg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Let init know user wants to shutdown

[John Fremlin]

Jamie Lokier <[EMAIL PROTECTED]> writes:

[...]

> Are you sure?  A suspend takes about 5-10 seconds on my laptop.

You mean when you tell the apm driver from userspace to suspend?

> (It was noticably faster with 2.3 kernels, btw.  Now it spends a second
> or two apparently not noticing the APM event (though the BIOS is making
> the speaker beep), then syncing the disk, 

The BIOS got the event, problem is in BIOS surely?

[...]

-- 

http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Matrox FB console driver

[Andy Carlson]

I was playing around with a program that I was using to time differences
between kernels (a silly prime program that puts out 100 primes).  I
noticed a very strange behaviour.  On a fresh boot, with the Penguin
pictures that the Matrox FB driver puts up, the prime program runs
1 minute, 30 seconds.  If I reset, it still runs 1M30S.  If I start X,
and exit, it runs 48 seconds.  Is this a known behaviour?  Thanks.

Andy Carlson   |\  _,,,---,,_
[EMAIL PROTECTED]ZZZzz /,`.-'`'-.  ;-;;,_
BJC Health System |,4-  ) )-,_. ,\ (  `'-'
St. Louis, Missouri  '---''(_/--'  `-'\_)
Cat Pics: http://andyc.dyndns.org

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

Re: Linux 2.4.3ac13

[David S. Miller]

Alan Cox writes:
 > 2.4.3-ac13
 > oSwitch to NOVERS symbols for rwsem  (me)
 >  | Called from asm blocks so they can't be versioned

Yes they most certainly can be versioned inside of an asm.  Use the
"i" constraint, we've been doing this on sparc64 for ages.

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: light weight user level semaphores

[Alexander Viro]

On 24 Apr 2001, David Wagner wrote:

> Linus Torvalds  wrote:
> >Ehh.. I will bet you $10 USD that if libc allocates the next file
> >descriptor on the first "malloc()" in user space (in order to use the
> >semaphores for mm protection), programs _will_ break.
> >
> >You want to take the bet?
> 
> Good point.  Speaking of which:
>   ioctl(fd, UIOCATTACHSEMA, ...);
> seems to act like dup(fd) if fd was opened on "/dev/usemaclone"
> (see drivers/sgi/char/usema.c).  According to usema(7), this is
> intended to help libraries implement semaphores.
> 
> Is this a bad coding?

Yes. Not to mention side effects, it's just plain ugly. Anyone who invents
identifiers of _that_ level of ugliness should be forced to read them
aloud for a week or so, until somebody will shoot him out of mercy.
Out of curiosity: who was the author? It looks unusually nasty, even for
SGI.

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

Re: compile error 2.4.4pre6: inconsistent operand constraints in an

[Jeff Chua]

On Mon, 23 Apr 2001, Alan Cox wrote:

> 2.4.4pre6 only builds with gcc 2.96. If you apply the __builtin_expect fixes
> it builds and runs fine with 2.95. Not tried egcs. The gcc 3.0 asm constraints
> one I've yet to see a fix for.

So, should I upgrade to 2.96 from 2.95.3?

But, from http://gcc.gnu.org/gcc-2.96.html ...

   Please note that both GCC 2.96 and 2.97 are development versions; we
   do not recommend using them for production purposes. Binaries built
   using any version of GCC 2.96 or 2.97 will not be portable to systems
   based on one of our regular releases.


Does this still hold?

Thanks,
Jeff

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

Re: comments on CML 1.1.0

[Oliver Xymoron]

On Sat, 14 Apr 2001, Eric S. Raymond wrote:

> > * the colors are hard to see (red/blue on black).  Probably
> >   matter of terminal settings.  I do not have any productive
> >   ideas tho...  Probably to get best experience to as much
> >   people as possible the less colors are used the better.
> >
> >   The 'blue: last visited submenu' is unnecessary.  Especially
> >   because it later turns green...  And the 'red' vs. 'green'
> >   thing.  I guess the green should be used for 'visited entries'
> >   too.  Now the red means like 'Doh.  So I should not have
> >   touched this?'.  Confusing.
> >
> >   In other words: if there are too much colors, they become
> >   a thing that should be separately learned, not a helpful
> >   aid.
> >
> >   All this IMHO ofcourse.  Colors are 'matter of taste' thing
> >   so there probably is not exact Rigth Thing.
>
> You make good points.  In the 1.1.1, blue and yellow/brown will be gone;
> it's just green for everything visited.

I haven't had a chance to take a look, but a heads-up about color
confusion issues. There may be no right thing, but there are plenty of
wrong things. For instance, for about 4% of people (8% of males), RGB
00 and 00FF00 are nearly indistiguishable, as are FF00FF and FF.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

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

Re: light weight user level semaphores

[David Wagner]

Linus Torvalds  wrote:
>Ehh.. I will bet you $10 USD that if libc allocates the next file
>descriptor on the first "malloc()" in user space (in order to use the
>semaphores for mm protection), programs _will_ break.
>
>You want to take the bet?

Good point.  Speaking of which:
  ioctl(fd, UIOCATTACHSEMA, ...);
seems to act like dup(fd) if fd was opened on "/dev/usemaclone"
(see drivers/sgi/char/usema.c).  According to usema(7), this is
intended to help libraries implement semaphores.

Is this a bad coding?  Should the kernel really support an ioctl()
that can silently allocate the next file descriptor?  This seems
like asking for trouble.  Or, maybe I just misunderstood something.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel hang on multi-threaded X process crash

[Don Dugger]

Alan-

I certainly care to fix it (since I wrote the patch).  Since `aviplay' seems
to be the easy way to trigger it I'll look into it.

On Mon, Apr 23, 2001 at 04:40:12PM +0100, Alan Cox wrote:
> > Both mozilla and aviplay (which are both multithreaded) trigger this - I
> > haven't tried with xmms. Simpler programs like xclock or cat don't trigger
> > it.
> 
> Thanks. I'll revert the core dump stuff for 2.4.4-ac unless anyone cares to
> fix the fix
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Let init know user wants to shutdown

[Jamie Lokier]

John Fremlin wrote:
> > > I'm wondering if that veto business is really needed. Why not reject
> > > *all* APM rejectable events, and then let the userspace event handler
> > > send the system to sleep or turn it off? Anybody au fait with the APM
> > > spec?
> > 
> > My thinkpad actually started blinking with some LED when you pressed
> > the button. LED went off when you rejected or when sleep was
> > completed.
> 
> Does the led start blinking when the system sends an apm suspend? In
> that case I don't think you'd notice the brief period between the
> REJECT and the following suspend from userspace ;-)

Are you sure?  A suspend takes about 5-10 seconds on my laptop.

(It was noticably faster with 2.3 kernels, btw.  Now it spends a second
or two apparently not noticing the APM event (though the BIOS is making
the speaker beep), then syncing the disk, then maybe another pause, then
maybe some more disk activity, then finally shutting down.  2.3 started
the disk activity immediately and didn't pause.  Perhaps 2.4.3 mm
problems?)

-- Jamie

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

Re: hundreds of mount --bind mountpoints?

[Ed Tomlinson]

Andreas Dilger wrote:

> Consider, when I was doing some fs benchmark, my inode slab cache was
> over 120k items on a 128MB machine.  At 480 butes per inode, this is
> almost 58 MB, close to half of RAM.  Reducing this to exactly ext2
> sized inodes would save (50 - 27) * 4 * 120k = 11MB of memory (on 32-bit
> systems)!!! (This assumes nfs_inode_info is the largest).

Was this with a recient kernel (post Alexander Viro's dcache pressure fix)?  
If not I suggest rerunning the benchmark.  I had/have a patch to apply pressure 
to the dcache and icache from kswapd but its not been needed here since the above 
fix.

Ed Tomlinson <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.4.3ac13

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

Intermediate diffs are available from

http://www.bzimage.org

This isnt a proper release as such, it should just deal with most of the 
compile failure/symbol failure problems.

2.4.3-ac13
o   Switch to NOVERS symbols for rwsem  (me)
| Called from asm blocks so they can't be versioned
o   Fix gcc 2.95 building on rwsem  (Niels Jensen)
o   Fix cmsfs build (Andrzej Krzysztofowicz)
o   Fix rio build/HZ setup  (Andrzej Krzysztofowicz)
o   Fix PPP filtering dependancy in config  (Andrzej Krzysztofowicz)

2.4.3-ac12
o   Rewrite the i2o post handling code to fix   (me)
DMA memory scribbles
o   Handle IOP constipation in the i2o_block layer  (me)
o   Fix bugs in the i2o table query causing reboots (me)
in i2o_proc on the DPT card
o   Add quirks for i2o cards that handle large I/O  (me)
queues badly [Promise supertrak100]
o   Add cache heuristics to the I2O block driver(me)
| We don't cache large writes (assume seq)
| We writeback small writes (random, metadata)
o   Disable use of writeback caching if there is(me)
no battery backup
o   Merge Linus 2.4.4pre6
o   Further semaphore fixes (David Howells)
o   Correct 'void main' to 'int main' in rtc doc(Jesper Juhl)
o   Hopefully fix bugtraq reported netfilter ftp
flaw
o   Fix unistd.h for ARM(Russell King)
o   Fix pre-emption of rt tasks (Nigel Gamble)
o   Fix revalidation bugs in cciss/cpqarray (Charles White)
when rereading partitions
o   Acenic updates  (Jes Sorensen)
o   Fix MAINTAINERS sort order  (David Woodhouse)
o   Restore DVDRAM fix with cdrom init fix too  (Jens Axboe)
o   Fix irda disconnect timeout bug (Dag Brattli)
o   Experimentally reap dead swap harder(Dave Miller)
o   Remove dead low mtu checks from drivers (Arnaldo Carvalho de
 Melo)
o   Add missing sk_chk_filter export(Byeong-ryeol Kim)
o   Quieten pci printks, send them to log   (Arjan van de Ven)
o   Hopefully fix fastrak oops  (me)

2.4.3-ac11
o   Merge Linus 2.4.4pre5
o   Back out problem dvdram changes
o   Make reiserfs use daemonize (Chris Mason)
o   Fix lvm map buglet  (Jens Axboe)
o   tms380 driver fixes (Adam Fritzler)
o   Fix up duplicate configs and other glitches (Steven Cole)
o   Fix pcnet32 printk format bug   (me)
o   ISDN driver further small update/fixes  (me)
o   Fix bounce buffer deadlock on bh allocs (Arjan van de Ven)
o   Fix fbmem merge glitch  (Geert Uytterhoeven)
o   Version string cleanups on net devices  (Jeff Garzik)
o   Update ext2 documentation   (Andreas Dilger)
o   Add MCE support for AMD Athlon/Duron(Dave Jones)
o   Further SDLA tidying(me)
o   Update Configure.help maintainers   (Steven Cole, Eric
 Raymond)
o   Tulip update(Jeff Garzik)
o   Fix sound config to use right symnames  (Eric Raymond)
o   Further dmfe fixes  (Tobias Ringstrom,
 Frank Davis
 Jeff Garzik)
o   Parport probe cleanups  (Tim Waugh)
o   Fix a few configure items   (Eric Raymond)
o   Fix cmsfs nonbuild  (me)


2.4.3-ac10
o   Merge Linus 2.4.4pre4
o   Apply the i960 quirk to the DPT I2O controllers (me)
o   Etrax100 updates(Bjorn Wesen)
o   Fix skge memory leak(Jes Sorensen)
o   Handle reiserfs log overflow error  (Chris Mason)
o   Merge JFFS2 (compressing log flash file system) (David Woodhouse)
o   Merge contributed help texts for options(Eric Raymond,
 Steven Cole)
o   Further screen blanking fixes   (Mikael Pettersson)
o   Further binfmt elf DLINFO fixes/alignment  (Benjamin Herrenschmidt)
o   Fix reboot notifier unregister in aic7xxx   (Arjan van de Ven)
o   Fix orinoco_cs build on powerpc (David Gibson)
o   Neomagic audio didn't 

Kernel make dependancies question

[Jeff Golds]

Hi folks,

I was looking at linux/drivers/Makefile and noticed that "sound" (among
others) was always put into the kernel whether it was configured on or
not.  Is there some reason for this?

Also, in linux/Rules.make, "fastdep:" is making dependancies on
"ALL_SUB_DIRS" which is "subdir-y", "subdir-m", "subdir-n" and
"subdir-", why is this?  It makes more sense that it just make
dependancies for "subdir-y" and "subdir-m" as the rest don't matter.

If these types of things are errors, I can make a patchfile, just let me
know what the proper behavior is.

Thanks,

-Jeff

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

Re: [patch] swap-speedup-2.4.3-A1, massive swapping speedup

[Marcelo Tosatti]

On Mon, 23 Apr 2001, Linus Torvalds wrote:

> 
> On Mon, 23 Apr 2001, Jonathan Morton wrote:
> > >There seems to be one more reason, take a look at the function
> > >read_swap_cache_async() in swap_state.c, around line 240:
> > >
> > >/*
> > > * Add it to the swap cache and read its contents.
> > > */
> > >lock_page(new_page);
> > >add_to_swap_cache(new_page, entry);
> > >rw_swap_page(READ, new_page, wait);
> > >return new_page;
> > >
> > >Here we add an "empty" page to the swap cache and use the
> > >page lock to protect people from reading this non-up-to-date
> > >page.
> > 
> > How about reversing the order of the calls - ie. add the page to the cache
> > only when it's been filled?  That would fix the race.
> 
> No. The page cache is used as the IO synchronization point, both for
> swapping and for regular IO. You have to add the page in _first_, because
> otherwise you may end up doing multiple IO's from different pages.
> 
> The proper fix is to do the equivalent of this on all the lookup paths
> that want a valid page:
> 
>   if (!PageUptodate(page)) {
>   lock_page(page);
>   if (PageUptodate(page)) {
>   unlock_page(page);
>   return 0;
>   }
>   rw_swap_page(page, 0);
>   wait_on_page(page);
>   if (!PageUptodate(page))
>   return -EIO;
>   }
>   return 0;
> 
> This is the whole point of the "uptodate" flag, and for all I know we may
> already do all of this (it's certainly the normal setup).
> 
> Note how we do NOT block on write-backs in the above: the page will be
> up-to-date from the bery beginning (it had _better_ be, it's hard to write
> back a swap page that isn't up-to-date ;).
> 
> The above is how all the file paths work. 

Please don't forget about swapin readahead. 

If the page is not uptodated and we are doing swapin readahead on it, we
want to fail if the page is already locked (which means its already under
IO).


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

Re: PATCH 2.4.4.3: 3rdparty driver support for kbuild

[Jonathan Lundell]

At 9:10 AM +1000 4/24/01, Keith Owens wrote:
> >I don't see how multiple source trees can be merged automatically with
>>100% accuracy. 
>
>I agree, multiple source trees only work 100% for non-overlapping code.
>It does not matter how you implement separate source, the moment it
>overlaps you need human intervention.  That is true for my makefile-2.5
>as well as your Perl method.

Where "non-overlapping" needs to be construed broadly to include "not logically 
conflicting", and not merely as overlapping diffs.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ioctl arg passing

[Jonathan Lundell]

At 11:09 PM +0100 4/23/01, Matt wrote:
>| struct instruction_t {
>|  __s16 code;
>|  __s16 rxlen;
>|  __s16 *rxbuf;
>|  __s16 txlen;
>|  __s16 *txbuf;
>| };
>
>So far, I now know I can grab stuff across the user <-> kernel divide as I
>planned. The only problem I'm left with, which was kindly pointed out to
>me, is a question of packing with respect to both kernel & user-space.
>
>Can anyone suggest a method of either assuring the above structure is
>always packed the same, or alterations so that the problem is
>minimised? Either splitting the one ioctl into many, etc.

struct instruction_t {
__s16 code;
__s16 rxlen;
__s16 txlen;
__s16 pad;
__s16 *rxbuf;
__s16 *txbuf;
};

This was it's always aligned and packed, regardless of compiler packing settings. This 
particular layout happens to work with 64-bit pointers as well (I'm assuming that 
__s16 is a signed 16-bit type).

You can move the pointers to the front, but it's not necessary in this case, so I 
tried to preserve some of your original ordering (code first, rx before tx).
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: generic rwsem [Re: Alpha "process table hang"]

[Andrea Arcangeli]

On Mon, Apr 23, 2001 at 06:27:23PM -0500, Bob McElrath wrote:
> Well, take that back, I just got it to hang.  Again, this is 2.4.4pre3
> with alpha-numa-3 and rwsem-generic-4.  I saw it upon starting mozilla.
> I also saw some scary filesystem errors that may or may not be related:
> Apr 23 18:09:40 draal kernel: EXT2-fs error (device sd(8,2)): 
> ext2_new_block: Free blocks count corrupted for block group 252 

That is probably unrelated to the ps hang. I suspect you are been bitten by the
ext2 metadata corruption (2.4.4pre2 was just fixed but previous kernel wasn't).

> rwsem-generic-6 is the latest from Andrea, I'll build a new 2.4.4pre4
> kernel with these patches and let you know the results.  Have you made

Yes, that's safe.

> changes between rwsem-generic-4 and rwsem-generic-6 that would
> fix/prevent a deadlock?

No, but I think they are two separate issues.

> Let me know if there are any useful tests I could perform.  Would it be
> useful for me to run the rwsem benchmarks you've been using?  Could
> these detect a deadlock situation?

yes to be sure you can run it without my patch and see if it hangs (I never
tried that myself, but I was able to reproduce the ps hang quite easily and it
was quite obviously due the rwsemaphores and it gone away completly after I
used the generic semaphores).

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

odd messages in dmesg (network I think)

[Byron Albert]

Hello,
 I am getting odd message in my dmesg
I am running
Linux extreme 2.4.2-ac28 #1 SMP Fri Apr 13 01:58:47 UTC 2001 i686
unknown
and the messages look like


Undo Hoe 64.22.x.x/4414 c3 l2 ss10/65535 p4
Undo Hoe 64.22.x.x/4414 c3 l1 ss10/65535 p3
Undo Hoe 64.22.x.x/4414 c3 l1 ss10/65535 p2
Undo retrans 64.22.x.x/4414 c2 l0 ss10/65535 p0
Undo partial loss 64.157.x.x/32831 c1 l1 ss2/65535 p1
Disorder3 1 4 f4 s2 rr0
Disorder3 1 4 f4 s2 rr0
Disorder3 1 4 f4 s2 rr0
Undo loss 64.108.x.x/2786 c2 l0 ss2/65535 p0
Undo partial loss 200.27.x.x/2374 c1 l1 ss2/65535 p1
Undo partial loss 213.228.x..x/32936 c2 l1 ss2/65535 p1
Undo partial loss 213.228.x.x/32937 c2 l1 ss2/65535 p1
Disorder3 3 5 f6 s2 rr0
Disorder1 3 6 f0 s0 rr1
Undo Hoe 202.75.x.x/34237 c7 l0 ss4/65535 p6
Undo Hoe 202.75.x.x/34237 c7 l0 ss4/65535 p5
Undo retrans 202.75.x.x/34237 c6 l0 ss4/65535 p5

On my webserver errors like this fill the dmesg in a day. I did repalce
some ips with x.x.

Thanks for any info
Byron

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

read perf improved by mounting ext2?

[Kurt Garloff]

Hi,

I have some memory reading some similar question somewhere (here?) but I'm
not sure there was an answer.

I do observe strange behaviour if read performance fo my IDE harddisk as
reported by hdparm (or doing linear reads with a self written program):
My FUJITSU MPG3409AT E is supposed to make slightly above 30MB/s. However,
it's connected to a PIIX4, which can only do UDMA33. So I expect something
between 25 and 30 MB/s maximumn speed.

I get it. But not over the whole disk.
Doing a read speed measurement on /dev/hda, I constantly get ~16 MB/s.
Not bad, but less than I'd expect. Measuring single partitions, some show
the same, some show significantly more, 26MB/s--18MB/s, depending on the
position of the partition on disk. Those look good!

There are enough partitions to see a clear pattern: Those with mounted ext2
filesystems perform better. Umounting them does not harm, they just need to
have been mounted once. reiser or (v)fat however don't improve anything.
swap does, as does a ext2 over raid5.

Kernel 2.4.3pre7; Dual iPIII-700 system; i440BX MoBo.

Is this to be expected? Blocksize issues? Readahead behaviour? What's
changed on ext2 mounting ... ?

Regards,
-- 
Kurt Garloff   <[EMAIL PROTECTED]> [Eindhoven, NL]
Physics: Plasma simulations  <[EMAIL PROTECTED]>  [TU Eindhoven, NL]
Linux: SCSI, Security  <[EMAIL PROTECTED]>   [SuSE Nuernberg, FRG]
 (See mail header or public key servers for PGP2 and GPG public keys.)

 PGP signature

Re: generic rwsem [Re: Alpha "process table hang"]

[Bob McElrath]

Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
> On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote:
> > I'm at 2 days uptime now, and have not seen the process-table-hang.
> > Looks like this fixed it.  Previously I would get a hang in the first
> > day or so.  I'm using your alpha-numa-3 and rwsem-generic-4 against
> > 2.4.4pre3.
> 
> good, thanks for the report.
> 
> BTW, if you upgrade to 2.4.4pre4 you can apply those two patches:
> 
>   
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre4aa1/00_alpha-numa-4
>   
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre4aa1/00_rwsem-generic-6
> 
> really the first is not necessary anymore unless you're using a wildfire. The
> second also resurrect the optimized rwsemaphores for all archs but alpha and
> ia32.

Well, take that back, I just got it to hang.  Again, this is 2.4.4pre3
with alpha-numa-3 and rwsem-generic-4.  I saw it upon starting mozilla.
I also saw some scary filesystem errors that may or may not be related:
Apr 23 18:09:40 draal kernel: EXT2-fs error (device sd(8,2)): 
ext2_new_block: Free blocks count corrupted for block group 252 

There has been a lot of discussion on the topic of rwsems (that,
admittedly, I haven't followed very closely).  It looks like
rwsem-generic-6 is the latest from Andrea, I'll build a new 2.4.4pre4
kernel with these patches and let you know the results.  Have you made
changes between rwsem-generic-4 and rwsem-generic-6 that would
fix/prevent a deadlock?

Let me know if there are any useful tests I could perform.  Would it be
useful for me to run the rwsem benchmarks you've been using?  Could
these detect a deadlock situation?

Cheers,
-- Bob

Bob McElrath ([EMAIL PROTECTED]) 
Univ. of Wisconsin at Madison, Department of Physics

 PGP signature

Re: hundreds of mount --bind mountpoints?

[Rik van Riel]

On Mon, 23 Apr 2001, Alexander Viro wrote:
> On Mon, 23 Apr 2001, Richard Gooch wrote:
>
> > - keep a separate VFSinode and FSinode slab cache
>
> Yup.

Would it make sense to unify these with the struct
address_space ?

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

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

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

[PATCH] Move __GFP_IO check in shrink_icache_memory to prune_icache()

[Marcelo Tosatti]

Linus,

With the prune_icache() modifications which were integrated in pre5 there
is no more need to avoid non __GFP_IO allocations to go down to
prune_icache().

The following patch moves the __GFP_IO check down to prune_icache(),
allowing !__GFP_IO allocations to free clean unused inodes.


diff --exclude-from=/home/marcelo/exclude -Nur linux.orig/fs/dquot.c linux/fs/dquot.c
--- linux.orig/fs/dquot.c   Mon Apr 23 19:15:23 2001
+++ linux/fs/dquot.cMon Apr 23 19:18:14 2001
@@ -554,7 +554,7 @@
if (shrink) {
printk(KERN_DEBUG "get_empty_dquot: pruning dcache and icache\n");
prune_dcache(128);
-   prune_icache(128);
+   prune_icache(128, GFP_USER);
shrink--;
goto repeat;
}
diff --exclude-from=/home/marcelo/exclude -Nur linux.orig/fs/inode.c linux/fs/inode.c
--- linux.orig/fs/inode.c   Mon Apr 23 19:15:23 2001
+++ linux/fs/inode.cMon Apr 23 19:18:04 2001
@@ -540,7 +540,7 @@
 !inode_has_buffers(inode))
 #define INODE(entry)   (list_entry(entry, struct inode, i_list))
 
-void prune_icache(int goal)
+void prune_icache(int goal, int gfp_mask)
 {
LIST_HEAD(list);
struct list_head *entry, *freeable = 
@@ -577,6 +577,16 @@
 
dispose_list(freeable);
 
+   /*
+* Nasty deadlock avoidance..
+*
+* We may hold various FS locks, and we don't
+* want to recurse into the FS that called us
+* in clear_inode() and friends..
+*/
+   if (!(gfp_mask & __GFP_IO))
+   return;
+
/* 
 * If we freed enough clean inodes, avoid writing 
 * dirty ones. Also giveup if we already tried to
@@ -596,20 +606,10 @@
 {
int count = 0;
 
-   /*
-* Nasty deadlock avoidance..
-*
-* We may hold various FS locks, and we don't
-* want to recurse into the FS that called us
-* in clear_inode() and friends..
-*/
-   if (!(gfp_mask & __GFP_IO))
-   return;
-
if (priority)
count = inodes_stat.nr_unused / priority;
 
-   prune_icache(count);
+   prune_icache(count, gfp_mask);
kmem_cache_shrink(inode_cachep);
 }
 
diff --exclude-from=/home/marcelo/exclude -Nur linux.orig/include/linux/dcache.h 
linux/include/linux/dcache.h
--- linux.orig/include/linux/dcache.h   Mon Apr 23 19:15:23 2001
+++ linux/include/linux/dcache.hMon Apr 23 19:18:31 2001
@@ -176,7 +176,7 @@
 
 /* icache memory management (defined in linux/fs/inode.c) */
 extern void shrink_icache_memory(int, int);
-extern void prune_icache(int);
+extern void prune_icache(int, int);
 
 /* only used at mount-time */
 extern struct dentry * d_alloc_root(struct inode *);


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

Re: i810_audio broken?t

[Alan Cox]

> Are you guys running esd with any special arguments?
> 
> esd needs a special argument, -r RATE [iirc], in order to tell esd that
> it is dealing with a locked rate codec.

48Khz esound support was fixed the day I got an i810 board 8). Its the
rate conversions it cant handle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i810_audio broken?

[Alan Cox]

> Ok building mpg123 without eSound worked for me too,
> so guess this is not a Linux kernel issue, sorry for this.

Excellent.

> eSound sux?

esound has very broken rate conversion support (it converts the audio but rather
damages it on the way). Gnome is moving towards using the KDE arts daemon which
currently seems to get it right.

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

Re: hundreds of mount --bind mountpoints?

[Alexander Viro]

On Mon, 23 Apr 2001, Richard Gooch wrote:

> - keep a separate VFSinode and FSinode slab cache

Yup.

> - allocate an enlarged VFSinode that contains the FSinode at the end,
>   with the generic pointer in the VFSinode part pointing to FSinode
>   part.

Please, don't. It would help with bloat only if you allocated these
beasts separately for each fs and then you end up with _many_ allocators
that can generate pointer to struct inode. 

"One type - one allocator" is a good rule - violating it turns into major
PITA couple of years down the road 9 times out of 10.

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

Re: hundreds of mount --bind mountpoints?

[Richard Gooch]

Alexander Viro writes:
> 
> 
> On Mon, 23 Apr 2001, Richard Gooch wrote:
> 
> > - keep a separate VFSinode and FSinode slab cache
> 
> Yup.
> 
> > - allocate an enlarged VFSinode that contains the FSinode at the end,
> >   with the generic pointer in the VFSinode part pointing to FSinode
> >   part.
> 
> Please, don't. It would help with bloat only if you allocated these
> beasts separately for each fs and then you end up with _many_ allocators
> that can generate pointer to struct inode. 
> 
> "One type - one allocator" is a good rule - violating it turns into
> major PITA couple of years down the road 9 times out of 10.

Agreed. The better option is the separate VFSinode and FSinode caches.
The enlarged inode scheme is also ugly, like the unions. It's just
less bloated :-)

Regards,

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

Re: i810_audio broken?

[Pawel Worach]

Ok i'll try :)

It's a little bit slow and the high tones get kind of very high
The first track of Moby Play sounds like you mixed Moby with
Donald Duck (but it not fast), like I said it's hard to describe sound
in text. :)

I can record it on another box and give You the result if You like? :)

- Original Message -
From: Alan Cox <[EMAIL PROTECTED]>
Date: Tuesday, April 24, 2001 1:02 am
Subject: Re: i810_audio broken?

> > I was using mpg123 (xmms and c/o does exactly the same)
> > if I run it like this Moby sounds very stupid... :)
> > [root@whyami mp3]# mpg123 -r 48000 Moby_01.wav.mp3 
> > unsupported playback rate: 44100
> > Audio device open for 44.1Khz, stereo, 16bit failed
> > Trying 44.1Khz, 8bit stereo.
> > unsupported sound format: 32
> > Audio device open for 44.1Khz, stereo, 8bit failed
> > Trying 48Khz, 16bit stereo.
> 
> Ok so its trying to do the right thing. Can you describe what it 
> sounds like
> better ?
> 
> 


begin:vcard
n:Worach;Pawel
fn:Pawel Worach
version:2.1
email;internet:[EMAIL PROTECTED]
end:vcard

Re: PATCH 2.4.4.3: 3rdparty driver support for kbuild

[Keith Owens]

On Mon, 23 Apr 2001 19:03:45 -0400, 
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> On Sun, 15 Apr 2001 05:25:24 -0400,
>> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>> >The attached patch, against kernel 2.4.4-pre3, adds a feature I call
>> >"3rd-party support."
>> 
>> Already covered by my 2.5 makefile rewrite[1] which has explicit
>> support for third party kernel source.
>
>I don't see how multiple source trees can be merged automatically with
>100% accuracy.  

I agree, multiple source trees only work 100% for non-overlapping code.
It does not matter how you implement separate source, the moment it
overlaps you need human intervention.  That is true for my makefile-2.5
as well as your Perl method.

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

Re: NWFS broken on 2.4.3 -- someone removed WRITERAW

[Jeff V. Merkey]

On Tue, Apr 24, 2001 at 12:58:09AM +0200, Jens Axboe wrote:
> On Mon, Apr 23 2001, Jeff V. Merkey wrote:
> > 
> > 
> > Hey guys,
> > 
> > Whomever removed WRITERAW has broken NWFS.  WRITE requests call
> > _refile_buffer() after the I/O request and take my locally created 
> > buffer heads and munge them back into the linux buffer cache, causing
> > massive memory corruption in the system.  These buffers don't belong 
> > in Linus' buffer cache, they are owned by my LRU and ll_rw_block 
> > should not be blindly filing them back into the buffer cache.
> > 
> > Please put something back in to allow me to write without the buffer
> > heads always getting filed into Linus' buffer cache.  This has 
> > broken NWFS on 2.4.3 and above.
> 
>   bh->b_end_io = my_end_io_handler;
>   submit_bh(WRITE, bh);


Jens,

Bless you.  I'll code the fix, test it, and get it out.  

Jeff

> 
> Be a happy camper.
> 
> -- 
> Jens Axboe
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH 2.4.4.3: 3rdparty driver support for kbuild

[Jeff Garzik]

Keith Owens wrote:
> On Sun, 15 Apr 2001 05:25:24 -0400,
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >The attached patch, against kernel 2.4.4-pre3, adds a feature I call
> >"3rd-party support."
> 
> Already covered by my 2.5 makefile rewrite[1] which has explicit
> support for third party kernel source.  Shadow trees are designed
> specifically to handle this problem.  I don't see the point of adding a
> script which will only be used in 2.4, especially when the vendors
> would have to change their tarball format for 2.5 formats.
> 
> (3) The kernel is constructed from multiple source trees and built in a
> separate object tree.

I don't see how multiple source trees can be merged automatically with
100% accuracy.  

What happens when you build with linus-tree, xfs-tree, and
reiserfs-tree, and both XFS and reiserfs touch struct file_operations,
in conflicting ways?  It takes human intervention to figure that stuff
out and resolve such conflicts.

If you support multiple source trees -> single build tree, it sounds
like are you trying to integrate cvs/diff/similar into the kernel build
system, which is whacky...

Jeff



-- 
Jeff Garzik  | The difference between America and England is that
Building 1024| the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i810_audio broken?

[David Woodhouse]

[EMAIL PROTECTED] said:
>  esd needs a special argument, -r RATE [iirc], in order to tell esd
> that it is dealing with a locked rate codec.

Isn't there an ioctl for that?

--
dwmw2


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

Re: compile error 2.4.4pre6: inconsistent operand constraints in an

[Alan Cox]

> after having had trouble with compilation due to old gcc version, i have
> updated to gcc 3.0 and received the following error:

2.4.4pre6 only builds with gcc 2.96. If you apply the __builtin_expect fixes
it builds and runs fine with 2.95. Not tried egcs. The gcc 3.0 asm constraints
one I've yet to see a fix for.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: hundreds of mount --bind mountpoints?

[Richard Gooch]

Albert D. Cahalan writes:
> Richard Gooch writes:
> 
> > We want to take out that union because it sucks for virtual
> > filesystems. Besides, it's ugly.
> 
> I hope you won't mind if people trash this with benchmarks.

But they can't. At least, not for a well designed patch. If there is a
real issue of fragmentation, then there are ways to fix that without
using a bloated union structure. Don't punish some filesystems just
because others have a problem.

Solutions to avoid fragmentation:

- keep a separate VFSinode and FSinode slab cache
- allocate an enlarged VFSinode that contains the FSinode at the end,
  with the generic pointer in the VFSinode part pointing to FSinode
  part.

It's simply wrong to bloat everyone because some random FS found it
easier to thow in a union.

Besides, for every benchmark that shows how fragmentation hurts, I can
generate a benchmark showing how inode bloat hurts. Lies, damn lies
and benchmarks.

Regards,

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

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

On Tue, 24 Apr 2001, Andrzej Krzysztofowicz wrote:

> So maybe make the original error message more informative ?
> Just something like:
>
> - extern void __buggy_fxsr_alignment(void);
> - __buggy_fxsr_alignment();
> + extern void 
>__BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy(void);
> + 
>__BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy();

1. People would probably still report that to l-k instead of reading it.
2. It's still not guaranteed to compile, even with correct compilers.

Maybe you can do a post-processing step - a sanity check which is run
_after_ build. But the runtime check is sufficient. People won't randomly
start compiling kernels for production boxen with silly compilers, then
booting them unattended. And if they do, they deserve the downtime.

I agree that a compile-time check would be kinder, but only if it can be
done properly. Show me one, and I'll be happy.

-- 
dwmw2


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

Re: hundreds of mount --bind mountpoints?

[Andreas Dilger]

Ingo Oeser writes:
> > We should get ext2 and friends to move the sucker _out_ of struct inode.
> > As it is, sizeof(struct inode) is way too large. This is 2.5 stuff, but
> > it really has to be done. More filesystems adding stuff into the union
> > is a Bad Thing(tm). If you want to allocates space - allocate if yourself;
> > ->clear_inode() is the right place for freeing it.
> 
> BTW: Is it still less than one page? Then it doesn't make me
>nervous. Why? Guess what granularity we allocate at, if we
>just store pointers instead of the inode.u. Or do you like
>every FS creating his own slab cache?

I would much rather we allocate a slab cache for each fs type (it
would be trivial at register_fs time).  Most people have only a limited
number of filesystems active at a single time, yet tens or hundreds of
thousands of inodes in the inode slab cache.  Making the per-fs private
inode data as small as possible would reduce memory wastage considerably,
and not impact performance (AFAICS) if we use a per-fs type slab cache
for fs private data.

Consider, when I was doing some fs benchmark, my inode slab cache was
over 120k items on a 128MB machine.  At 480 butes per inode, this is
almost 58 MB, close to half of RAM.  Reducing this to exactly ext2
sized inodes would save (50 - 27) * 4 * 120k = 11MB of memory (on 32-bit
systems)!!! (This assumes nfs_inode_info is the largest).

This also makes it possible to safely (and efficiently) use external
filesystem modules without the need to recompile the kernel.  Granted,
if the external filesystem doesn't use more than the largest .u struct,
then it is currently possible as well, but that number changes, so it
is not safe.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i810_audio broken?

[Pawel Worach]

Ok building mpg123 without eSound worked for me too,
so guess this is not a Linux kernel issue, sorry for this.

I tried the fstodell hack but it seems to be obsoluted.
Now it works without any tweaks.

eSound sux?

Thanks guys!
Back to work (with music :)

- Original Message -
From: Chmouel Boudjnah <[EMAIL PROTECTED]>
Date: Tuesday, April 24, 2001 1:34 am
Subject: Re: i810_audio broken?

> "Pawel Worach" <[EMAIL PROTECTED]> writes:
> 
> > I was using mpg123 (xmms and c/o does exactly the same)
> > if I run it like this Moby sounds very stupid... :)
> 
> i got the same problem when using mpg123 compiled with esd on my dell
> workstation (which has a need to have set explictely to a clocking of
> 41194 via ftsodell option), compiling without esd seems fix the prob
> for me.
> 
> -- 
> Chmouel
> 


begin:vcard
n:Worach;Pawel
fn:Pawel Worach
version:2.1
email;internet:[EMAIL PROTECTED]
end:vcard

Re: 3-Ware Raid driver fails to update GenDisk head

[Jeff V. Merkey]

On Tue, Apr 24, 2001 at 12:45:35AM +0200, Jens Axboe wrote:
> On Mon, Apr 23 2001, Jeff V. Merkey wrote:
> > On Mon, Apr 23, 2001 at 11:13:12PM +0200, Guest section DW wrote:
> > > On Mon, Apr 23, 2001 at 01:55:00PM -0600, Jeff V. Merkey wrote:
> > > > On Mon, Apr 23, 2001 at 09:47:01PM +0200, Guest section DW wrote:
> > > > > On Mon, Apr 23, 2001 at 12:08:52PM -0600, Jeff V. Merkey wrote:
> > > > > > 
> > > > > > I am still working on this, but would appreciate some help from
> > > > > > whomever owns this driver proper.  I have discovered that the 
> > > > > > 3Ware drivers are not updating the gendisk_head with devices
> > > > > > reported and exposed to user space as /dev/sda, sdb, etc.
> > > > > 
> > > > > But that is the job of sd.c, not of a driver.
> > > > 
> > > > These drivers are an IDE driver that simulates a SCSI interface.  It 
> > > > reported IDE devices as SCSI handles, so there's some holes.  I guess
> > > > you were not aware of this, or you would have known that standard sd.c
> > > > is not working.
> > > 
> > > Just like ide-scsi.c you mean?
> > 
> > No.  They're not that clean and well organized, though they are rather 
> > clever adapters and are pretty cool.
> 
> Come on Jeff, what Andries is saying is that it _works_ like ide-scsi.
> It registers itself as a SCSI hba like a "regular" SCSI card, hence it
> uses the SCSI infrastructure -- alas, disks driven by sd.c

OK, OK.  I get it.  Sorry for the digs 

:-)

Jeff


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

Re: 3-Ware Raid driver fails to update GenDisk head

[Jens Axboe]

On Mon, Apr 23 2001, Jeff V. Merkey wrote:
> On Mon, Apr 23, 2001 at 11:13:12PM +0200, Guest section DW wrote:
> > On Mon, Apr 23, 2001 at 01:55:00PM -0600, Jeff V. Merkey wrote:
> > > On Mon, Apr 23, 2001 at 09:47:01PM +0200, Guest section DW wrote:
> > > > On Mon, Apr 23, 2001 at 12:08:52PM -0600, Jeff V. Merkey wrote:
> > > > > 
> > > > > I am still working on this, but would appreciate some help from
> > > > > whomever owns this driver proper.  I have discovered that the 
> > > > > 3Ware drivers are not updating the gendisk_head with devices
> > > > > reported and exposed to user space as /dev/sda, sdb, etc.
> > > > 
> > > > But that is the job of sd.c, not of a driver.
> > > 
> > > These drivers are an IDE driver that simulates a SCSI interface.  It 
> > > reported IDE devices as SCSI handles, so there's some holes.  I guess
> > > you were not aware of this, or you would have known that standard sd.c
> > > is not working.
> > 
> > Just like ide-scsi.c you mean?
> 
> No.  They're not that clean and well organized, though they are rather 
> clever adapters and are pretty cool.

Come on Jeff, what Andries is saying is that it _works_ like ide-scsi.
It registers itself as a SCSI hba like a "regular" SCSI card, hence it
uses the SCSI infrastructure -- alas, disks driven by sd.c

-- 
Jens Axboe

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

Re: hundreds of mount --bind mountpoints?

[Albert D. Cahalan]

Richard Gooch writes:

> We want to take out that union because it sucks for virtual
> filesystems. Besides, it's ugly.

I hope you won't mind if people trash this with benchmarks.

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

Re: filp_open() in 2.2.19 causes memory corruption

[Jeff V. Merkey]

On Mon, Apr 23, 2001 at 11:03:48PM +0100, David Woodhouse wrote:
> 
> [EMAIL PROTECTED] said:
> > Are you sure the trace is decoded correctly?
> 
> > > CPU:0 
> > > EIP:0010:[sys_mremap+31/884]  
> 
> Probably not. It looks like it was munged by klogd. Some distributions are 
> still shipping with klogd configured to destroy the original information on 
> the way to the log, without even making it do a sanity check that the 
> System.map it's using actually matches the current kernel.
> 
> Jeff, please disable the broken klogd symbol munging and reproduce it,
> running the oops through ksymoops manually. Ksymoops should have built-in 
> sanity checks on the System.map it tries to use.
> 
> Also, please make sure you report this as a serious bug with the vendor of 
> whatever distribution you're running on this box.
> 


David,

I will comply and repost the oops.

Jeff

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

NWFS broken on 2.4.3 -- someone removed WRITERAW

[Jeff V. Merkey]

Hey guys,

Whomever removed WRITERAW has broken NWFS.  WRITE requests call
_refile_buffer() after the I/O request and take my locally created 
buffer heads and munge them back into the linux buffer cache, causing
massive memory corruption in the system.  These buffers don't belong 
in Linus' buffer cache, they are owned by my LRU and ll_rw_block 
should not be blindly filing them back into the buffer cache.

Please put something back in to allow me to write without the buffer
heads always getting filed into Linus' buffer cache.  This has 
broken NWFS on 2.4.3 and above.

As for using Linus' buffer cache, until you put in the ability to 
create logical block mapping instead of physical, I will not be 
able to use it.  Hopefully, this will make it in 2.5.  I have some 
folks trying to use this with 2.4.3 and they are dead in the water
until this gets addressed.

Thanks

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

Re: 3-Ware Raid driver fails to update GenDisk head

[Jeff V. Merkey]

On Mon, Apr 23, 2001 at 11:13:12PM +0200, Guest section DW wrote:
> On Mon, Apr 23, 2001 at 01:55:00PM -0600, Jeff V. Merkey wrote:
> > On Mon, Apr 23, 2001 at 09:47:01PM +0200, Guest section DW wrote:
> > > On Mon, Apr 23, 2001 at 12:08:52PM -0600, Jeff V. Merkey wrote:
> > > > 
> > > > I am still working on this, but would appreciate some help from
> > > > whomever owns this driver proper.  I have discovered that the 
> > > > 3Ware drivers are not updating the gendisk_head with devices
> > > > reported and exposed to user space as /dev/sda, sdb, etc.
> > > 
> > > But that is the job of sd.c, not of a driver.
> > 
> > These drivers are an IDE driver that simulates a SCSI interface.  It 
> > reported IDE devices as SCSI handles, so there's some holes.  I guess
> > you were not aware of this, or you would have known that standard sd.c
> > is not working.
> 
> Just like ide-scsi.c you mean?

No.  They're not that clean and well organized, though they are rather 
clever adapters and are pretty cool.

Jeff


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

Re: i810_audio broken?

[Pawel Worach]

It sounds like when you play music very loud with bad speakers
and it's kind of slow. It's kind of "clinking", describing sound via
e-mail can be very hard.

what value shall i put for the clocking parameter?
is it trial-and-error or is there some formula?

And no, the cut off output does not mean that it worked. :(
xmms says this:
Audio device open for 44.1Khz, stereo, 8bit failed
Trying 48Khz, 16bit stereo.
But it still sounds strange.


- Original Message -
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tuesday, April 24, 2001 0:07 am
Subject: Re: i810_audio broken?

> Pawel Worach wrote:
> > sorry the kernel version is 2.4.3-ac12, so it's kind of latest...
> > 
> > I was using mpg123 (xmms and c/o does exactly the same)
> > if I run it like this Moby sounds very stupid... :)
> 
> "very stupid" means "broken" obviously, but can you be more 
> specific? 
> music is faster? slower?  garbled?
> 
> > [root@whyami mp3]# mpg123 -r 48000 Moby_01.wav.mp3
> > unsupported playback rate: 44100
> > Audio device open for 44.1Khz, stereo, 16bit failed
> > Trying 44.1Khz, 8bit stereo.
> > unsupported sound format: 32
> > Audio device open for 44.1Khz, stereo, 8bit failed
> > Trying 48Khz, 16bit stereo.
> 
> so, since you provided no more output than this, I assume that
> 48Khz/16bit succeeded, which appears perfectly normal for a locked-
> ratecodec.
> 
> You may need the 'clocking' module option, not sure...
> 
> -- 
> Jeff Garzik  | The difference between America and England is that
> Building 1024| the English think 100 miles is a long distance and
> MandrakeSoft | the Americans think 100 years is a long time.
> |  (random fortune)
> 


begin:vcard
n:Worach;Pawel
fn:Pawel Worach
version:2.1
email;internet:[EMAIL PROTECTED]
end:vcard

Re: i810_audio broken?

[Chmouel Boudjnah]

"Pawel Worach" <[EMAIL PROTECTED]> writes:

> I was using mpg123 (xmms and c/o does exactly the same)
> if I run it like this Moby sounds very stupid... :)

i got the same problem when using mpg123 compiled with esd on my dell
workstation (which has a need to have set explictely to a clocking of
41194 via ftsodell option), compiling without esd seems fix the prob
for me.

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

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

[EMAIL PROTECTED] said:
>  Your patch (tries to) transform a compile and link time check into a
> runtime check. Not nice.

It transforms a broken and cryptic compile-time check into a correct and
informative runtime check.

If you can provide a correct and informative compile-time check, that would 
be wonderful.

--
dwmw2


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

Re: Can't compile 2.4.3 with agcc

[Andrzej Krzysztofowicz]

> It's known at compile time, but not at preprocessing time, so it can't be 
> done with #error. If you can come up with a way of doing it at compile time 
> such that:
> 
>  1. It's _guaranteed_ to work when the compiler does align the members 
>   of the structure as we desire.
>  2. It gives a message sufficiently informative that it prevents further
>   such reports getting to l-k.

So maybe make the original error message more informative ?
Just something like:

- extern void __buggy_fxsr_alignment(void);
- __buggy_fxsr_alignment();
+ extern void 
+__BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy(void);
+ 
+__BUG__task_struct__data_is_not_properly_alligned__Probably_your_compiler_is_buggy();

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

Re: [upatch] lib/Makefile

[Tom Rini]

On Mon, Apr 23, 2001 at 05:16:24PM -0500, Peter Samuelson wrote:

> Introduced in 2.4.4pre4, I believe.  $(export-objs) need not be
> conditional, and the if statement was not really correct either,
> although in this case it probably worked.

Er, are you sure changing the test for !"nn" is correct here?
I _think_ at least that is intentional and correct (since you can have
one on but not the other).

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can't compile 2.4.3 with agcc

[Horst von Brand]

David Woodhouse <[EMAIL PROTECTED]> said:

[...]

> Then the kernel should say so, rather than giving a cryptic message like 
> that, and containing code which isn't actually guaranteed to compile, even 
> with a compiler which _does_ align the structure as we want it.

Your patch (tries to) transform a compile and link time check into a
runtime check. Not nice.
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[Jeff Garzik]

[EMAIL PROTECTED] wrote:
> I've proposed a SCSI ioctl that returns PCI bus, slot, function, primary and
> subsystem vendor and device IDs.

PCI ids can be derived from bus/slot/function.

-- 
Jeff Garzik  | The difference between America and England is that
Building 1024| the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][CFT] (updated) ext2 directories in pagecache

[Alexander Viro]

On Thu, 12 Apr 2001, Alexander Viro wrote:

>   Folks, IMO ext2-dir-patch got to the stable stage. Currently
> it's against 2.4.4-pre2, but it should apply to anything starting with
> 2.4.2 or so.
> 
>   Ted, could you review it for potential inclusion into 2.4 once
> it gets enough testing? It's ext2-only (the only change outside of
> ext2 is exporting waitfor_one_page()), it doesn't change fs layout,
> it seriously simplifies ext2/dir.c and ext2/namei.c and it gives better
> VM behaviour.

Previous variant left junk in ->d_type of directory entries
on "old" filesystems (i.e. ones where it should be zeroed). Harmless
(on these filesystems readdir() returned DT_UNKNOWN anyway), but
it PO'd fsck and was the wrong thing anyway.

Fixed and rediffed against current tree (2.4.4-pre6). Folks,
please help with testing.

Patch is on ftp.math.psu.edu/pub/viro/ext2-dir-patch-S4-pre6.gz

Cheers,
Al

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

Re: [PATCH] rw_semaphores, optimisations try #3

[Linus Torvalds]

On Mon, 23 Apr 2001, D.W.Howells wrote:
>
> Linus, you suggested that the generic list handling stuff would be faster (2
> unconditional stores) than mine (1 unconditional store and 1 conditional
> store and branch to jump round it). You are both right and wrong. The generic
> code does two stores per _process_ woken up (list_del) mine does the 1 or 2
> stores per _batch_ of processes woken up. So the generic way is better when
> the queue is an even mixture of readers or writers and my way is better when
> there are far greater numbers of waiting readers. However, that said, there
> is not much in it either way, so I've reverted it to the generic list stuff.

Note that the generic list structure already has support for "batching".
It only does it for multiple adds right now (see the "list_splice"
merging code), but there is nothing to stop people from doing it for
multiple deletions too. The code is something like

static inline void list_remove_between(x,y)
{
n->next = y;
y->prev = x;
}

and notice how it's still just two unconditional stores for _any_ number
of deleted entries.

Anyway, I've already applied your #2, how about a patch relative to that?

Linus

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

pgd_alloc to include mm_struct

[rmk]

Hi,

This continues from my previous thread (subject line "All architecture
maintainers: pgd_alloc()" on lkml), and for Linus' sake, here is the
explaination I supplied:

| For ARM, I require pgd_alloc to take a struct mm_struct argument (so the
| pgd_alloc prototype becomes "pgd_t *pgd_alloc(struct mm_struct *)".
|   
| Why?  Because ARM must always have the first virtual page allocated and
| present - its used for the hardware vectors, and in order to allocate
| the page table for this page, I need a mm_struct (see the pte_alloc
| prototype and associated code in mm/memory.c).

Here is the patch - it does not contain the ARM changes; they are already
in the 2.4.4-pre tree.  It does however touch every single other
architecture.

The changes look ok, but obviously have only been run on ARM (other
architecture maintainers please help out here if Linus requires it to
be tested).

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

diff -u orig/include/asm-alpha/pgalloc.h linux/include/asm-alpha/pgalloc.h
--- orig/include/asm-alpha/pgalloc.hSun Apr 22 09:58:37 2001
+++ linux/include/asm-alpha/pgalloc.h   Mon Apr 23 23:06:17 2001
@@ -338,7 +338,7 @@
 #define pte_free(pte)  pte_free_fast(pte)
 #define pmd_free(pmd)  pmd_free_fast(pmd)
 #define pgd_free(pgd)  free_pgd_fast(pgd)
-#define pgd_alloc()get_pgd_fast()
+#define pgd_alloc(mm)  get_pgd_fast()
 
 extern int do_check_pgt_cache(int, int);
 
diff -u orig/include/asm-cris/pgalloc.h linux/include/asm-cris/pgalloc.h
--- orig/include/asm-cris/pgalloc.h Thu Feb 22 11:25:43 2001
+++ linux/include/asm-cris/pgalloc.hMon Apr 23 23:06:17 2001
@@ -191,7 +191,7 @@
 /* pgd handling */
 
 #define pgd_free(pgd)  free_pgd_slow(pgd)
-#define pgd_alloc()get_pgd_fast()
+#define pgd_alloc(mm)  get_pgd_fast()
 
 /* other stuff */
 
diff -u orig/include/asm-i386/pgalloc.h linux/include/asm-i386/pgalloc.h
--- orig/include/asm-i386/pgalloc.h Sat Mar 31 23:47:42 2001
+++ linux/include/asm-i386/pgalloc.hMon Apr 23 23:06:17 2001
@@ -130,7 +130,7 @@
 
 #define pte_free(pte)  pte_free_slow(pte)
 #define pgd_free(pgd)  free_pgd_slow(pgd)
-#define pgd_alloc()get_pgd_fast()
+#define pgd_alloc(mm)  get_pgd_fast()
 
 /*
  * allocating and freeing a pmd is trivial: the 1-entry pmd is
diff -u orig/include/asm-ia64/pgalloc.h linux/include/asm-ia64/pgalloc.h
--- orig/include/asm-ia64/pgalloc.h Sun Apr 22 09:58:41 2001
+++ linux/include/asm-ia64/pgalloc.hMon Apr 23 23:06:18 2001
@@ -48,7 +48,7 @@
 }
 
 static inline pgd_t*
-pgd_alloc (void)
+pgd_alloc (struct mm_struct *mm)
 {
/* the VM system never calls pgd_alloc_one_fast(), so we do it here. */
pgd_t *pgd = pgd_alloc_one_fast();
diff -u orig/include/asm-m68k/motorola_pgalloc.h 
linux/include/asm-m68k/motorola_pgalloc.h
--- orig/include/asm-m68k/motorola_pgalloc.hWed Dec 13 00:00:25 2000
+++ linux/include/asm-m68k/motorola_pgalloc.h   Mon Apr 23 23:08:43 2001
@@ -160,7 +160,7 @@
free_pmd_fast((pmd_t *)pgd);
 }
 
-extern inline pgd_t *pgd_alloc(void)
+extern inline pgd_t *pgd_alloc(struct mm_struct *mm)
 {
pgd_t *pgd = (pgd_t *)get_pmd_fast();
if (!pgd)
diff -u orig/include/asm-m68k/sun3_pgalloc.h linux/include/asm-m68k/sun3_pgalloc.h
--- orig/include/asm-m68k/sun3_pgalloc.hWed Dec 13 00:00:25 2000
+++ linux/include/asm-m68k/sun3_pgalloc.h   Mon Apr 23 23:07:47 2001
@@ -134,7 +134,7 @@
 free_page((unsigned long) pgd);
 }
 
-extern inline pgd_t * pgd_alloc(void)
+extern inline pgd_t * pgd_alloc(struct mm_struct *mm)
 {
  pgd_t *new_pgd;
 
diff -u orig/include/asm-mips/pgalloc.h linux/include/asm-mips/pgalloc.h
--- orig/include/asm-mips/pgalloc.h Fri May 26 11:56:30 2000
+++ linux/include/asm-mips/pgalloc.hMon Apr 23 23:06:18 2001
@@ -128,7 +128,7 @@
 #define pte_free_kernel(pte)free_pte_fast(pte)
 #define pte_free(pte)   free_pte_fast(pte)
 #define pgd_free(pgd)   free_pgd_fast(pgd)
-#define pgd_alloc() get_pgd_fast()
+#define pgd_alloc(mm)   get_pgd_fast()
 
 extern inline pte_t * pte_alloc_kernel(pmd_t * pmd, unsigned long address)
 {
diff -u orig/include/asm-mips64/pgalloc.h linux/include/asm-mips64/pgalloc.h
--- orig/include/asm-mips64/pgalloc.h   Wed Dec 13 00:00:25 2000
+++ linux/include/asm-mips64/pgalloc.h  Mon Apr 23 23:06:18 2001
@@ -151,7 +151,7 @@
 #define pte_free(pte)   free_pte_fast(pte)
 #define pmd_free(pte)   free_pmd_fast(pte)
 #define pgd_free(pgd)   free_pgd_fast(pgd)
-#define pgd_alloc() get_pgd_fast()
+#define pgd_alloc(mm)   get_pgd_fast()
 
 extern inline pte_t * pte_alloc(pmd_t * pmd, unsigned long address)
 {
diff -u orig/include/asm-parisc/pgalloc.h linux/include/asm-parisc/pgalloc.h
--- orig/include/asm-parisc/pgalloc.h   Wed Dec 13 00:00:27 2000

Re: Linux 2.4.3-ac12

[Byeong-ryeol Kim]

On Mon, 23 Apr 2001, Byeong-ryeol Kim wrote:

> On Sun, 22 Apr 2001, Alan Cox wrote:
>
> > > > Using /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
> > > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > > symbol rwsem_up_write_wake
> > > > /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o: unresolved
> > > > symbol rwsem_down_write_failed
> > >
> > > Same thing with tdfx.o...
> >
> > "Works for me" as ever. What configuration options are you using. This sounds
> > like some of the code is built with each kind of semaphore.
> 
>
> I use 2 PCs at home. One is unnamed desktop - AMD K6-II+, ASUS P/I-P55T2P4
> rev. 3.10, 128 MB EDO RAM, etc.), the other is IBM ThinkPad 600X(Pentium III
> 500, 192 MB PC100 RAM, etc.). But, the result of depmod under 2.4.3-ac12
> are the same.
> I use gcc-2.95.3 release + recommended patch about atexit from libc-alpha list
> which seemed to be applied in gcc-2.95.4 CVS tree).


I retried to compile 2.4.3-ac12 with Red Hat's 2.96-81(that of 7.1) without
the patch previously applied.
This time, I noticed strange thing.(I guess, it would not be a compiler
problem).
While doing 'depmod -ae -F /boot/System.map-2.4.3-ac12 2.4.3-ac12'
there was no error as far as rwsem_* is concerned, but when doing simply
'depmod -ae', the result was the same as before.( the same kernel
configuration, modutils is original 2.4.5-1 fetched from kernel site).

1) 'depmod -ae -F /boot/system.map-2.4.3-ac12 2.4.3-ac12'

depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/net/aironet4500_card.o
depmod: __bad_udelay
depmod: *** Unresolved symbols in /lib/modules/2.4.3-ac12/kernel/fs/cmsfs/cms.o
depmod: get_hardsect_size

2) 'depmod -ae'

depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/arch/i386/kernel/microcode.o
depmod: rwsem_up_write_wake
depmod: rwsem_up_read_wake
depmod: rwsem_down_write_failed
depmod: rwsem_down_read_failed
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/char/drm/gamma.o
depmod: rwsem_up_write_wake
depmod: rwsem_down_write_failed
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/char/drm/i810.o
depmod: rwsem_up_write_wake
depmod: rwsem_down_write_failed
depmod: *** Unresolved symbols in /lib/modules/2.4.3-ac12/kernel/drivers/char/drm/mga.o
depmod: rwsem_up_write_wake
depmod: rwsem_down_write_failed
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/char/drm/r128.o
depmod: rwsem_up_write_wake
depmod: rwsem_down_write_failed
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/char/drm/radeon.o
depmod: rwsem_up_write_wake
depmod: rwsem_down_write_failed
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/char/drm/tdfx.o
depmod: rwsem_up_write_wake
depmod: rwsem_down_write_failed
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/net/aironet4500_card.o
depmod: __bad_udelay
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/video/matrox/matroxfb_base.o
depmod: rwsem_up_read_wake
depmod: rwsem_down_read_failed
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/video/matrox/matroxfb_crtc2.o
depmod: rwsem_up_write_wake
depmod: rwsem_up_read_wake
depmod: rwsem_down_write_failed
depmod: rwsem_down_read_failed
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/video/matrox/matroxfb_g450.o
depmod: rwsem_up_write_wake
depmod: rwsem_down_write_failed
depmod: *** Unresolved symbols in 
/lib/modules/2.4.3-ac12/kernel/drivers/video/matrox/matroxfb_maven.o
depmod: rwsem_up_write_wake
depmod: rwsem_down_write_failed
depmod: *** Unresolved symbols in /lib/modules/2.4.3-ac12/kernel/fs/binfmt_aout.o
depmod: rwsem_up_write_wake
depmod: rwsem_down_write_failed
depmod: *** Unresolved symbols in /lib/modules/2.4.3-ac12/kernel/fs/cmsfs/cms.o
depmod: get_hardsect_size


>
> #
> # Automatically generated make config: don't edit
> #
> CONFIG_X86=y
> CONFIG_ISA=y
> # CONFIG_SBUS is not set
> CONFIG_UID16=y
>
> #
> # Code maturity level options
> #
> CONFIG_EXPERIMENTAL=y
>
> #
> # Loadable module support
> #
> CONFIG_MODULES=y
> CONFIG_MODVERSIONS=y
> CONFIG_KMOD=y
>
> #
> # Processor type and features
> #
> # CONFIG_M386 is not set
> # CONFIG_M486 is not set
> # CONFIG_M586 is not set
> # CONFIG_M586TSC is not set
> # CONFIG_M586MMX is not set
> # CONFIG_M686 is not set
> # CONFIG_MPENTIUMIII is not set
> # CONFIG_MPENTIUM4 is not set
> CONFIG_MK6=y
> # CONFIG_MK7 is not set
> # CONFIG_MCRUSOE is not set
> # CONFIG_MWINCHIPC6 is not set
> # CONFIG_MWINCHIP2 is not set
> # CONFIG_MWINCHIP3D is not set
> # CONFIG_MCYRIXIII is not set
> CONFIG_X86_WP_WORKS_OK=y
> 

Re: [PATCH] Longstanding elf fix (2.4.3 fix)

[Manfred Spraul]

> Well looking a little more closely than I did last night it looks like
> access_process_vm (called from ptrace) can cause what amounts to a
> page fault at pretty arbitrary times.

It's also used for several /proc/ files.

I remember that I got crashes with concurrent exec+cat
/proc//cmdline until down(mmap_sem) was added into
setup_arg_pages().

> I'm actually a little curious what the big kernel lock in ptrace buys
> us. I suspect it could be a performance issue with user mode linux.
> Where you have multiple processes being ptraced at the same time.

I checked it a few months ago, and the lock is only required to prevent
multiple concurrent attaches to the same process and concorrent
ptrace/suid exec (in fs/exec.c, compute_creds)

--
Manfred





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

RE: [RFC][PATCH] adding PCI bus information to SCSI layer

[Matt_Domsch]

Thanks everyone for your input.

Doug Gilbert said:
> SANE (and probably some other applications) parses the
> output of 'cat /proc/scsi/scsi' so any change to its
> format may trip SANE up. How about another entry in
> the /proc/scsi directory that has a more parsable format
> (e.g. xml :-) ).

This makes a lot of sense, but I don't want to fan the war over what kind of
information should be presented in /proc. :-)  Perhaps this can wait for
scsimon changes.

Doug Gilbert said: 
> Also ISA adapters are not the only non-PCI adapters,
> there are the growing band of pseudo adapters that
> may or may not have a PCI bus at the bottom of some
> other protocol stack.

Alan said:
> An ioctl might be better. We already have an ioctl for 
> querying the lun
> information for a disk. We could also return the bus 
> information for its
> controller(s) [remember multipathing]

If I understand multipathing properly, a /dev/mdX device is composed of
several block devices, and there are IOCTLs available to list the individual
devices that compose a block device.  Each multipath component shows up as
both /dev/sda and /dev/sdb, but you mount /dev/md0 for your I/Os.  BIOSs
don't know about multipath devices, they just see the same disk twice and
don't know it's really only one disk.  Hopefully BIOS only reads the boot
sector and jumps, so this is fine.

I've proposed a SCSI ioctl that returns PCI bus, slot, function, primary and
subsystem vendor and device IDs.  Equivalent /dev/hdX information is
available in /proc/ide/ide0, but not as an IOCTL.  It could then be a
user-space problem to decompose a mdX into component sdX or hdX devices, and
query them appropriately.

I'm still not sure if/how to handle:
1) non-PCI-bus devices

Here I'm going to need some help.  My original design was based on the
information presented by EDD 3.0 Rev 5a (www.t13.org), which only presents
x86 int13-type devices, and shows them to be either ISA or PCI-based, with
the goal of telling the OS which device BIOS thinks is the boot device.
Booting off, say, a parallel-port ZIP drive isn't really handled in EDD.  


2) Devices like i2o scsi disks
The i2o controller can be on any bus type (though I expect most are
PCI).  The i2o_controller struct has an i2o_hrt member, which does have bus
information, but the PCI struct doesn't include subsystem vendor and device
fields yet.  We'd need to add an IOCTL to retrieve this information,
possibly one at a generic i2o level.   The EDD 3.0 spec shows that a PCI i2o
device returns us a 64-bit Identity Tag, which I'm guessing is the same as a
32-bit target device ID and possibly the TID of the controller too.

3) other block devices (non-SCSI, i2o, or IDE).  I haven't investigated
these.


Doug suggested looking at extending scsimon.  This is a fine idea, and I've
made proposed changes available at http://domsch.com/linux/scsi/.  (Doug may
want to clean this up).  However, this, like my earlier changes to
/proc/scsi/scsi, doesn't actually show the relationship between /dev/sda and
a particular PCI controller and SCSI channel,bus,lun tuple.


I'd like to see the the PCI device information added to the Scsi_Host
structure, the ioctl, and the various PCI SCSI driver changes I mentioned
last week.  I've removed the changes to /proc/scsi/scsi and rebuilt it
against 2.4.4-pre6, available at
http://domsch.com/linux/scsi/linux-2.4.4-pre6-scsi-pci-info-noproc.patch

If/when this goes in, I'll also request the assistance of all of the SCSI
driver maintainers.  I've changed quite a few drivers, but couldn't easily
see how to change a few others.

Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux


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

[upatch] lib/Makefile

[Peter Samuelson]

Introduced in 2.4.4pre4, I believe.  $(export-objs) need not be
conditional, and the if statement was not really correct either,
although in this case it probably worked.

Peter


--- 2.4.4pre6/lib/Makefile~ Mon Apr 23 09:51:17 2001
+++ 2.4.4pre6/lib/Makefile  Mon Apr 23 17:11:04 2001
@@ -8,14 +8,12 @@
 
 L_TARGET := lib.a
 
-export-objs := cmdline.o
+export-objs := cmdline.o rwsem.o
 
 obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o
 
-ifneq ($(CONFIG_RWSEM_GENERIC_SPINLOCK)$(CONFIG_RWSEM_XCHGADD_ALGORITHM),nn)
-export-objs += rwsem.o
-obj-y += rwsem.o
-endif
+obj-$(CONFIG_RWSEM_GENERIC_SPINLOCK)   += rwsem.o
+obj-$(CONFIG_RWSEM_XCHGADD_ALGORITHM)  += rwsem.o
 
 ifneq ($(CONFIG_HAVE_DEC_LOCK),y) 
   obj-y += dec_and_lock.o
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ioctl arg passing

[Matt]

Matt mentioned the following:

| struct instruction_t {
|   __s16 code;
|   __s16 rxlen;
|   __s16 *rxbuf;
|   __s16 txlen;
|   __s16 *txbuf;
| };

So far, I now know I can grab stuff across the user <-> kernel divide as I
planned. The only problem I'm left with, which was kindly pointed out to
me, is a question of packing with respect to both kernel & user-space.

Can anyone suggest a method of either assuring the above structure is
always packed the same, or alterations so that the problem is
minimised? Either splitting the one ioctl into many, etc.

Thanks

Matt

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

Re: MO drives (2048 byte block vfat fs) in lk 2.4

[Daniel Kobras]

On Sun, Apr 22, 2001 at 10:59:18PM -0400, Douglas Gilbert wrote:
> One error report stated that a MO drive with a vfat
> fs based on 2048 byte sectors can be mounted and read

Read? I don't think so. bread, yes, but read follows a NULL pointer and
was never seen again.

> but any significant write causes a system lockup. I
> have been able to replicate this behaviour. Luckily
> Alt-SysRq-P did work. Pressing this sequence multiple
> times gave similar addresses. Rebooting the machine
> and rerunning the experiment multiple time gave 
> addresses in the same area.

bigblock_fat_bread() in fs/fat/buffer.c kmalloc()s 2k dummy bhs for each
512 byte buffer but only partly initialise them. This works as long as those
bogus bhs don't leave the fat realm. Unfortunately, generic_file_write and
friends call into the generic block layer that wants to do such evil things
on bhs as using their wait_queues or checking their state for BH_Locked.
None of which are initialised, and while I haven't checked in detail,
certainly lead the way into deadlock country. But even if these minor
disturbances magically didn't screw you yet, the fat layer will hand out
a buffer address calculated for 512 byte buffers for your 2k buffer, and your
data goes bye, bye.

The preferred fix seems to be to teach the loop device about reblocking and
rip all of the bigblock support from fat. I've spent this weekend to cure
my utter and complete ignorance of the blkdev layer, in order to be able to
implement a working set up at least. Please allow me another couple of days
to spare a little hacking time. I'll take care of the issue. Promised.

Regards,

Daniel.

-- 
GNU/Linux Audio Mechanics - http://www.glame.de
  Cutting Edge Office - http://www.c10a02.de
  GPG Key ID 89BF7E2B - http://www.keyserver.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.4-pre6 : THANKS! very snappy here [nt]

[Colonel]

NT = no text

but since you read it, system seems like it's running twice as fast

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

Re: hundreds of mount --bind mountpoints?

[Alexander Viro]

On Tue, 24 Apr 2001, Ingo Oeser wrote:

> We have this kind of stuff all over the place. If we allocate
> some small amount of memory and and need some small amount
> associated with this memory, there is no problem with a little
> waste.

Little? How about quarter of kilobyte per inode? sizeof(struct inode)
is nearly half-kilobyte. And icache can easily get to ~10 elements.

> Waste is better than fragmentation. This is the lesson people
> learned from segments in the ia32.
> 
> Objects are easier to manage, if they are the same size.

So don't keep them in the same cache. Notice that quite a few systems
keep vnode separately from fs-specific data. For a very good reason.

Al

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

Re: rwsem.o undefined reference to __builtin_expect

[Colonel]

In list.kernel, you wrote:
>
>
>cannot compile 2.4.4-pre6. This may have been reported, but I
>haven't seen it.

There was a solution mentioned Saturday.


>rwsem.o(.text+0x30): undefined reference to `__builtin_expect'
>rwsem.o(.text+0x73): undefined reference to `__builtin_expect'
>make: *** [vmlinux] Error 1

in asm-alpha/compiler.h you will find a definition.  The above
solution created a new file (asm-i386/compiler.h) with the definition,
I just added it to rwsem.c.


BTW: 2.4.4-pre6 is the fastest kernel yet!  YMMV

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

Re: i810_audio broken?

[Jeff Garzik]

Pawel Worach wrote:
> sorry the kernel version is 2.4.3-ac12, so it's kind of latest...
> 
> I was using mpg123 (xmms and c/o does exactly the same)
> if I run it like this Moby sounds very stupid... :)

"very stupid" means "broken" obviously, but can you be more specific? 
music is faster? slower?  garbled?

> [root@whyami mp3]# mpg123 -r 48000 Moby_01.wav.mp3
> unsupported playback rate: 44100
> Audio device open for 44.1Khz, stereo, 16bit failed
> Trying 44.1Khz, 8bit stereo.
> unsupported sound format: 32
> Audio device open for 44.1Khz, stereo, 8bit failed
> Trying 48Khz, 16bit stereo.

so, since you provided no more output than this, I assume that
48Khz/16bit succeeded, which appears perfectly normal for a locked-rate
codec.

You may need the 'clocking' module option, not sure...

-- 
Jeff Garzik  | The difference between America and England is that
Building 1024| the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[CFT][PATCH] namespaces patch (2.4.4-pre6)

[Alexander Viro]

Folks, updated namespace patch is on
ftp.math.psu.edu/pub/viro/namespaces-c-S4-pre6.gz
 
News:
* ported to 2.4.4-pre6
* fixes for d_flags races (already in -ac, hopefully will go into
the main tree soon)
* fixes for sync_inodes()/kill_super() races (submitted to Linus
and Alan, hopefully will go into the tree soon)
* killed low-memory deadlocks between {u,re,}mount and kswapd.
* further cleanup of fs/super.c

It works here. Please, help with testing. Patch had somewhat grown, but
new pieces are fixes for the bugs present in the main tree and these
fixes had been submitted for inclusion in 2.4, so hopefully it will
shrink again.
Cheers,
Al

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

Re: anybody home at device@lanana.org?

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Kipp Cannon <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> I've sent some messages to [EMAIL PROTECTED] but haven't received any
> responses.  Does anyone know if there's anybody home?
> 

Yes, but there are some issues with respect to device registration
right now.  I will be sending out a message explaining in detail to
the people who have pending registrations sometime this week.

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

Re: filp_open() in 2.2.19 causes memory corruption

[David Woodhouse]

[EMAIL PROTECTED] said:
> Are you sure the trace is decoded correctly?

> > CPU:0 
> > EIP:0010:[sys_mremap+31/884]  

Probably not. It looks like it was munged by klogd. Some distributions are 
still shipping with klogd configured to destroy the original information on 
the way to the log, without even making it do a sanity check that the 
System.map it's using actually matches the current kernel.

Jeff, please disable the broken klogd symbol munging and reproduce it,
running the oops through ksymoops manually. Ksymoops should have built-in 
sanity checks on the System.map it tries to use.

Also, please make sure you report this as a serious bug with the vendor of 
whatever distribution you're running on this box.

--
dwmw2


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

Re: hundreds of mount --bind mountpoints?

[Ingo Oeser]

On Mon, Apr 23, 2001 at 10:56:16PM +0200, Christoph Hellwig wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Last time we suggested this, people ended up with some OS trying
> > it and getting worse performance. 
> 
> Which OS? Neither BSD nor SVR4/SVR5 (or even SVR3) do that.

Don't remember. I think Larry McVoy told the story, so I cc'ed
him ;-)

> Because having an union in generic code that includes filesystem-specific
> memebers is ugly? It's one of those a little more performance for a lot of
> bad style optimizations.

We have this kind of stuff all over the place. If we allocate
some small amount of memory and and need some small amount
associated with this memory, there is no problem with a little
waste.

Waste is better than fragmentation. This is the lesson people
learned from segments in the ia32.

Objects are easier to manage, if they are the same size.

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i810_audio broken?

[Pawel Worach]

sorry the kernel version is 2.4.3-ac12, so it's kind of latest...

I was using mpg123 (xmms and c/o does exactly the same)
if I run it like this Moby sounds very stupid... :)
[root@whyami mp3]# mpg123 -r 48000 Moby_01.wav.mp3 
unsupported playback rate: 44100
Audio device open for 44.1Khz, stereo, 16bit failed
Trying 44.1Khz, 8bit stereo.
unsupported sound format: 32
Audio device open for 44.1Khz, stereo, 8bit failed
Trying 48Khz, 16bit stereo.

Cheers
Pawel Worach
PostGirot Bank AB
- Original Message -
From: Alan Cox <[EMAIL PROTECTED]>
Date: Monday, April 23, 2001 9:53 pm
Subject: Re: i810_audio broken?

> > The i810 audio driver is broken on my Fujitsu Lifebook
> > S-4546. All output is just noise. Here is a snip's from
> > the kernel log.
> > 
> > Intel 810 + AC97 Audio, version 0.02, 19:41:16 Apr 23 2001
> > PCI: Found IRQ 9 for device 00:00.1
> > PCI: The same IRQ used for device 00:00.2
> > PCI: The same IRQ used for device 00:13.1
> > PCI: Setting latency timer of device 00:00.1 to 64
> > i810: Intel 440MX found at IO 0x1cc0 and 0x1000, IRQ 9
> > ac97_codec: AC97 Audio codec, id: 0x594d:0x4800 (Unknown)
> > i810_audio: only 48Khz playback available
> 
> The dump looks fine. Its a cheap and cheeerful codec however by the 
> look of it.
> Make sure the applications you use properly handle 48Khz only 
> audio. That
> may be the problem or maybe not.
> 
> Also try the very latest kernels as a fair bit of work has been 
> done on them
> 
> 


begin:vcard
n:Worach;Pawel
fn:Pawel Worach
version:2.1
email;internet:[EMAIL PROTECTED]
end:vcard

Re: compile error 2.4.4pre6: inconsistent operand constraints in an `asm'

[Erik Mouw]

On Mon, Apr 23, 2001 at 11:11:14PM +0200, axel wrote:
> after having had trouble with compilation due to old gcc version, i have
> updated to gcc 3.0 and received the following error:

Although bug reports about a kernel compiled with gcc-3.0 are welcome,
this is still not the recommended compiler. The recommended compiler is
gcc-2.91.66 (aka egcs-1.1.2), but for most people gcc-2.95.2 works as
well.


Erik
 
-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rw_semaphores, optimisations try #3

[Andrea Arcangeli]

On Mon, Apr 23, 2001 at 09:35:34PM +0100, D . W . Howells wrote:
> This patch (made against linux-2.4.4-pre6) makes a number of changes to the
> rwsem implementation:
> 
>  (1) Everything in try #2
> 
> plus
> 
>  (2) Changes proposed by Linus for the generic semaphore code.
> 
>  (3) Ideas from Andrea and how he implemented his semaphores.

I benchmarked try3 on top of pre6 and I get this:

--
RWSEM_GENERIC_SPINLOCK y in rwsem-2.4.4-pre6 + your latest #try3

rw

reads taken: 5842496
writes taken: 3016649
reads taken: 5823381
writes taken: 3006773

r1

reads taken: 13309316
reads taken: 13311722

r2

reads taken: 5010534
reads taken: 5023185

ro

reads taken: 3850228
reads taken: 3845954

w1

writes taken: 13012701
writes taken: 13021716

wo

writes taken: 1825789
writes taken: 1802560

--
RWSEM_XCHGADD y in rwsem-2.4.4-pre6 + your latest #try3

rw

reads taken: 5789542
writes taken: 2989478
reads taken: 5801777
writes taken: 2995669

r1

reads taken: 16922653
reads taken: 16946132

r2

reads taken: 5650211
reads taken: 5647272

ro

reads taken: 4956250
reads taken: 4959828

w1

writes taken: 15431139
writes taken: 15439790

wo

writes taken: 813756
writes taken: 816005

graph updated attached. so in short my fast path is still quite faster (r1/w1),
slow path is comparable now (I still win in all tests but wo which is probably
the less interesting one in real life [write contention]). I still have room to
improve the wo test [write contention] by spending more icache btw but it
probably doesn't worth.

Andrea

 rwsem2.png

Re: ioctl arg passing

[Ingo Oeser]

On Mon, Apr 23, 2001 at 08:58:54PM +0100, Matt wrote:
> Matt aka Doofus festures mentioned the following:
> 
> | struct instruction_t local;
> | __s16 *temp;
> | 
> | copy_from_user( , ( struct instruction_t * ) arg, sizeof( struct 
>instruction_t ) );
> | temp = kmalloc( sizeof( __s16 ) * local.rxlen, GFP_KERNEL );
> | copy_from_user( temp, arg, sizeof( __s16 ) * local.rxlen );
> 
> I meant that last line to be:
> 
> copy_from_user( temp, local.rxbuf, sizeof( __s16 ) * local.rxlen );
>   ^^^
> That's the main crux of my query, can I retrieve the value of a pointer
> in some struct passed via ioctl? In this case, the struct/chunk of memory
> referenced by local.rxbuf, (which is rxlen x 2 bytes big).

Yes, that works (with the obvious note on checking argument sizes
and not kmallocing too much memory).

All "read" functions do the same. As you were clever enough to
copy the pointer itself into kernel space, too (which many driver
writes forget!), you have done the right thing here.

Congratulations! ;-)

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

anybody home at device@lanana.org?

[Kipp Cannon]

Hi.

I've sent some messages to [EMAIL PROTECTED] but haven't received any
responses.  Does anyone know if there's anybody home?

-Kipp

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

Re: high-res-timers start code.

[Robert H. de Vries]

On Monday 23 April 2001 22:43, George Anzinger wrote:
> "Robert H. de Vries" wrote:
> > On Monday 23 April 2001 19:45, you wrote:
> > > By the way, is the user land stuff the same for all "arch"s?
> >
> > Not if you plan to handle the CPU cycle counter in user space. That is at
> > least what I would propose.
>
> Just got interesting, lets let the world look in.
>
> What did you have in mind here?  I suspect that on some archs the cycle
> counter is not available to user code.  I know that on parisc it is
> optionally available (kernel can set a bit to make it available), but by
> it self it is only good for intervals.  You need to peg some value to a
> CLOCK to use it to get timeofday, for instance.
>
> On the other hand, if there is an area of memory that both users and
> system can read but only system can write, one might put the soft clock
> there.  This would allow gettimeofday (with the cycle counter) to work
> without a system call.  To the best of my knowledge the system does not
> have such an area as yet.

It obviously is an architecture dependent thing. I know of two archtictures
which have such a counter: your standard pentium and up and the SGI systems
from at least the Indy and up. I wouldn't be surprised if most CPU's have
such a counter. If you look at some of the architecture specific code for the
gettimeofday code you would quickly find out which architectures have such a
feature. I have some code for the intel in my user space library. For the SGI
I also have some code, but only for IRIX. I guess for Linux we could do
similar code.

Robert

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

Re: hundreds of mount --bind mountpoints?

[Richard Gooch]

Ingo Oeser writes:
> On Mon, Apr 23, 2001 at 11:36:24AM -0400, Alexander Viro wrote:
> > > Great idea. We allocate this space anyway. And we don't have to
> > > care about the internals of this union, because never have to use
> > > it outside the kernel ;-)
> > > 
> > > I like it. ext2fs does the same, so there should be no VFS
> > > hassles involved. Al?
> > 
> > We should get ext2 and friends to move the sucker _out_ of struct inode.
> > As it is, sizeof(struct inode) is way too large. This is 2.5 stuff, but
> > it really has to be done. More filesystems adding stuff into the union
> > is a Bad Thing(tm). If you want to allocates space - allocate if yourself;
> > ->clear_inode() is the right place for freeing it.
> 
> You need an inode anyway. So why not using the space in it? tmpfs
> would only use sizeof(*inode.u)-sizeof(struct shmem_inode_info) for
> this kind of symlinks.
> 
> Last time we suggested this, people ended up with some OS trying
> it and getting worse performance. 
> 
> Why? You need to allocate the VFS-inode (vnode in other OSs) and
> the on-disk-inode anyway at the same time. You get better
> performance and less fragmentation, if you allocate them both
> together[1].

We want to take out that union because it sucks for virtual
filesystems. Besides, it's ugly.

Regards,

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

Re: Can't compile 2.4.3 with agcc

[David Woodhouse]

[EMAIL PROTECTED] said:
>  This is known at compile time, right? Would it not be better to
> replace the printk with #error ? Why do I need to boot the bad kernel
> to find out that it does not work, when it is known when compiling? 

It's known at compile time, but not at preprocessing time, so it can't be 
done with #error. If you can come up with a way of doing it at compile time 
such that:

 1. It's _guaranteed_ to work when the compiler does align the members 
of the structure as we desire.
 2. It gives a message sufficiently informative that it prevents further
such reports getting to l-k.

... then I agree, it would be better to do it at compile time. If not, the 
runtime check is the best we can do.

We really ought to have learned by now that we shouldn't be relying on the 
observed behaviour of this week's compiler in this particular phase of the 
moon.

--
dwmw2


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