Patch for shared interrupts in PCI IDE

2001-05-04 Thread Pete Zaitcev

One of our customers has a Fujitsu laptop, poor thing...
It shares IRQ10 between Eepro, additional IDE for CD-ROM (CMD646),
and USB controllers. I talked this over with DaveM briefly,
and if I understood him right, something like the attached
patch may be in order. Anyone cares to comment?

Thank you,
-- Pete

diff -ur -X dontdiff linux-2.4.4/include/linux/ide.h 
linux-2.4.4-niph/include/linux/ide.h
--- linux-2.4.4/include/linux/ide.h Fri Apr 27 15:48:56 2001
+++ linux-2.4.4-niph/include/linux/ide.hThu May  3 23:03:27 2001
@@ -408,6 +408,10 @@
ide_pmac
 } hwif_chipset_t;
 
+#define IDE_CHIPSET_PCI_MASK   \
+((1ide_pci)|(1ide_cmd646)|(1ide_ali14xx))
+#define IDE_CHIPSET_IS_PCI(c)  ((IDE_CHIPSET_PCI_MASK  (c))  1)
+
 #ifdef CONFIG_BLK_DEV_IDEPCI
 typedef struct ide_pci_devid_s {
unsigned short  vid;
diff -ur -X dontdiff linux-2.4.4/drivers/ide/ide-probe.c 
linux-2.4.4-niph/drivers/ide/ide-probe.c
--- linux-2.4.4/drivers/ide/ide-probe.c Sun Mar 18 09:25:02 2001
+++ linux-2.4.4-niph/drivers/ide/ide-probe.cThu May  3 23:07:37 2001
@@ -681,9 +681,9 @@
 */
if (!match || match-irq != hwif-irq) {
 #ifdef CONFIG_IDEPCI_SHARE_IRQ
-   int sa = (hwif-chipset == ide_pci) ? SA_SHIRQ : SA_INTERRUPT;
+   int sa = IDE_CHIPSET_IS_PCI(hwif-chipset) ? SA_SHIRQ : SA_INTERRUPT;
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
-   int sa = (hwif-chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
+   int sa = IDE_CHIPSET_IS_PCI(hwif-chipset) ? SA_INTERRUPT|SA_SHIRQ : 
+SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
if (ide_request_irq(hwif-irq, ide_intr, sa, hwif-name, hwgroup)) {
if (!match)
-
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/



rtc: lost some interrupts / mga_flush_ioctl *ERROR* lock not held

2001-05-04 Thread thunder7

Should I be worried about these?

May  4 08:09:29 middle kernel: rtc: lost some interrupts at 256Hz.
May  4 08:09:38 middle last message repeated 2 times
May  4 08:09:56 middle kernel: rtc: lost some interrupts at 1024Hz.
May  4 08:10:05 middle kernel: [drm:mga_flush_ioctl] *ERROR* lock not held
May  4 08:14:39 middle kernel: rtc: lost some interrupts at 512Hz.
May  4 08:15:07 middle last message repeated 4 times
May  4 08:16:06 middle kernel: rtc: lost some interrupts at 256Hz.
May  4 08:16:09 middle kernel: [drm:mga_flush_ioctl] *ERROR* lock not held
May  4 08:17:33 middle kernel: rtc: lost some interrupts at 512Hz.
May  4 08:18:01 middle last message repeated 12 times

this is an X-session during heavy IDE-UDMA disk activity.
Linux 2.4.4, i86-SMP system (Abit VP6, via chipset), Matrox G400.

Thanks,
Jurriaan
-- 
These, then, were Srenki, men whose virtue was the excess of vice, who
with leaden zest performed quintessential evil and so redeemed their
fellows from turpitude.
Jack Vance - The Gray Prince.
GNU/Linux 2.4.4 SMP/ReiserFS 2x1743 bogomips load av: 0.05 0.02 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/



FS Structs

2001-05-04 Thread Anders Karlsson

Hello,

Many thanks for a very good and solid piece of software in the Linux
kernel. It has been very useful to me for several years now.

I am not subscribed to the list, so if I could be CC'd on eventual
replies I would be grateful.


I have a question regarding some of the parts of the overall
filesystem structure in the 2.4 kernel. (Kernel 2.4.[34].)
In the file fs/super.c the structure `sb' is used, that is the
superblock. As a part of that structure (reference include/linux/fs.h)
is `struct list_head s_locked_inodes;'.

The thing I can not understand at the moment is the `struct list_head'
(reference include/linux/list.h) which looks very odd. How can I find
which inodes are in the `s_locked_inodes' list?? All I want to do is
to loop through the list and see each open inode in turn, is there any
documentation for this, or is there any helpful soul out there that
could give me any pointers?

Many thanks in advance,

-- 
Anders Karlsson
e-mail: [EMAIL PROTECTED]

   *** PGP Encrypted E-Mail Is Prefered - PGP Key On Request ***
-
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/



PROBLEM: 2.4.5pre1 will not boot

2001-05-04 Thread Gordon Sadler

Please CC any replies.
Please refer to my previous post 'PROBLEM: 2.4.4 oops, will not boot'
for complete machine details/configuration.

I'm still working on different 2.4 kernels trying to get just one to
boot normally. Currently I've removed all modules and built everything
into the kernel, that seems to help a 'little'.

Just tried 2.4.5pre1...

1st boot. Got as far as Checking all file systems..., which is:
  fsck -C -R -A -a  (Debian Sid). This was followed by numerous (50)
  lines of the form:
  memory.c: 83  (something I couldn't read fast enough)
  followed by the machine auto-rebooting.

2nd boot. Trying to duplicate to read above memory.c ...
  Led to the attached oops.txt  ksym.out contained in the tarball.

3rd boot. I was actually able to login... for about 5 mins. I attempted
  to run the above oops through ksymoops while kernel was running. It
  appeared to work, just then machine froze, required my using reset
  button on case. This led to booting back into 2.2.19 with duplicate
  inodes, manual run of fsck.

4th boot. Led to the attached oops2.txt  ksym2.out which was just the
  first oops of approx. 20 or more before machine froze. All the
  remaining oops (that I looked at) were of the same type/address.

I really hope someone finds this, Andrew Morton(sp?) was looking into my
2.4.4 oops, says my slab is being corrupted? Would be kind of
interesting to find out it is hardware related. This m/b and CPU are
brand new, can still take them back -)

Thanks for your time.

Gordon Sadler

  

 2.4.5pre1.oops.tar.gz


OT: Alan Cox' response

2001-05-04 Thread Ronald Bultje


On 2001.05.04 03:20:46 +0200 Miles Lane wrote:
 Prepared Text of Remarks by Craig Mundie, Microsoft Senior Vice 
 President
 The Commercial Software Model
 The New York University Stern School of Business
 May 3, 2001

For the people who missed it, Alan Cox' response is at:
http://www2.usermagnet.com/cox/index.html

--
Ronald

-
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: 2.4.5pre1 will not boot

2001-05-04 Thread Seth Goldberg

Hi,

   What hardware are you running?

  --seth
 

 
 Please CC any replies.
 Please refer to my previous post 'PROBLEM: 2.4.4 oops, will not boot'
 for complete machine details/configuration.
 
 I'm still working on different 2.4 kernels trying to get just one to
 boot normally. Currently I've removed all modules and built everything
 into the kernel, that seems to help a 'little'.
 
 Just tried 2.4.5pre1...
 
 1st boot. Got as far as Checking all file systems..., which is:
   fsck -C -R -A -a  (Debian Sid). This was followed by numerous (50)
   lines of the form:
   memory.c: 83  (something I couldn't read fast enough)
   followed by the machine auto-rebooting.
 
 2nd boot. Trying to duplicate to read above memory.c ...
   Led to the attached oops.txt  ksym.out contained in the tarball.
 
 3rd boot. I was actually able to login... for about 5 mins. I attempted
   to run the above oops through ksymoops while kernel was running. It
   appeared to work, just then machine froze, required my using reset
   button on case. This led to booting back into 2.2.19 with duplicate
   inodes, manual run of fsck.
 
 4th boot. Led to the attached oops2.txt  ksym2.out which was just the
   first oops of approx. 20 or more before machine froze. All the
   remaining oops (that I looked at) were of the same type/address.
 
 I really hope someone finds this, Andrew Morton(sp?) was looking into my
 2.4.4 oops, says my slab is being corrupted? Would be kind of
 interesting to find out it is hardware related. This m/b and CPU are
 brand new, can still take them back -)
 
 Thanks for your time.
 
 Gordon Sadler
 
 
 
 
 Name: 2.4.5pre1.oops.tar.gz
2.4.5pre1.oops.tar.gzType: Unix Tape Archive (application/x-tar)
 Encoding: base64
-
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: Whether can we put our company's linux driver into linux kernel?

2001-05-04 Thread Matti Aarnio

On Thu, May 03, 2001 at 10:46:13PM +0800, Yiping Chen wrote:
 I want to contact with  the author of linux kernel. 
 Anybody knows how to contact with them?

   [EMAIL PROTECTED] list is quite good way for that.

 Our leader hope put our own driver into linux kernel.
 I am not sure whether it was permitted.

   It is even encouraged.  As has been mentioned here before, each
   Linux kernel source tarball (at least 2.4.* series) has file:

   Documentation/SubmittingDrivers

   which describes the method.


   Of course we (the fuzzy thing called user community) would prefer
   to have nice sourcecode with lots of comments telling why something
   is done in a way it is done, especially when it is a matter of poking
   some lowlevel things in the hardware.

   We see also highly obscured driver(s) appearing from various vendors,
   which support some single spot revision(s) of kernel(s).  This includes
   binary-only drivers...

   While vendors may have reasons not to publish some details of how to
   drive their hardware, usually it only makes their hardware less attractive
   for Linux users when the drivers are limited to i386 architecture and
   only some very few kernels by given vendors.

   While Linux kernels with even second number (2.4.* as an example)
   will TRY TO maintain internal API consistent, even down to BINARY
   format, that might not always be so.

   Especially there exists a radical difference in between multiprocesor
   kernels (SMP), and uniprocessor kernels.  So radical that they are
   binary incompatible.  (This is configuration option before compiling
   the kernel.)YOU (driver author) should always write SMP safe code
   with spinlocks protecting access to codepaths/data-areas needing
   consistent serialized access.  Compilation will optimize away the
   spinlocks in uniprocessor setups.


   A well written driver is supplied in source, and is easily readable
   by other people who need to go over the entire kernel for some subtle
   detail changes over the next development phases (such has happened
   before, and will likely happen again.)

   A well written driver will very likely work at hardware with different
   endianity than i386 architecture of PCs -- for example PowerPC machines.
   (Of course core-logic drivers don't need to work anything but i386 PC,
but PCI interfaced peripheral gizmo can be used anywhere.)


 So, I need to contact with the authors of linux kernel.
 If you know how to do it, please tell me.
 Thanks!!
 Yiping Chen

/Matti Aarnio [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: PROBLEM: 2.4.5pre1 will not boot

2001-05-04 Thread Gordon Sadler

On Fri, May 04, 2001 at 12:43:22AM -0700, Seth Goldberg wrote:
 Hi,
 
What hardware are you running?
 
AMD Duron 800
Epox 8KTA3 m/b
VIA KT133A AGPSet (KT133A+VT82C686B)
128 MB pc100 brandname SDRAM
Inter etherexpress100
Nvidia Riva TNT (orig.)
Quantum FB LP LM20.5

Full details available in previous oops report for 2.4.4. Didn't see
point of posting lspci -vvv, /proc/... again so soon. System here hasn't
changed.

Thanks

Gordon Sadler

-
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: X15 alpha release: as fast as TUX but in user space (fwd)

2001-05-04 Thread Pavel Machek

Hi!

   That means that for fooling closed-source statically-linked binary,
  
  If they are using glibc then you have the right to the object to link
  with the library and the library source under the LGPL. I dont know of any
  app using its own C lib
 
 Some don't use any libc at all, some just don't use it for the time call
 that were talking about substituting.
 
 Lying about the time is a hack, pure and simple. It will still be possible
 with magic pages. The fact that it will require more kernel hacking to
 accomplish it is irrelevant.

No. You are breaking self-virtualization here. That is not irrelevant.

It used to require no kernel support before. Now it will require
kernel support. That's step back. (Think uml).

Pavel
-- 
I'm [EMAIL PROTECTED] In my country we have almost anarchy and I don't care.
Panos Katsaloulis describing me w.r.t. patents at [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: iso9660 endianness cleanup patch

2001-05-04 Thread Pavel Machek

Hi!

  I was looking over the iso9660 code, and noticed that it was doing
  endianness conversion via ad hoc *functions*, not even inlines; nor did
  it take any advantage of the fact that iso9660 is bi-endian (has all
  data in both bigendian and littleendian format.)
  
  The attached patch fixes both.  It is against 2.4.4, but from the looks
  of it it should patch against -ac as well.
 
 Please beware: There is a can of worms you are openning up here, 
 since there are many broken CD producer programms out there, which
 only provide the little endian data and incorrect big endian
 entries. I had some CD's of this form myself. So the endian neutrality
 of the iso9660 is only in the theory present...

Hmm, perhaps there's time to fsck.iso9660?
Pavel
PS: It might be funny to *deliberately* create different filesystems;
one on little endian side and one on big endian side. That way windows
users would see macs suck and mac users PCs suck, and that with
just one cd ;-).
-- 
I'm [EMAIL PROTECTED] In my country we have almost anarchy and I don't care.
Panos Katsaloulis describing me w.r.t. patents at [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: Solution - AMI megaraid driver doesn't work with Linux 2.4.x kernels

2001-05-04 Thread Rafael Martinez

---Reply to mail from Venkatesh Ramamurthy about Solution - AMI  megaraid driver 
doesn't work with Linux 2.4.x kernels
 Can you provide the dmesg output of your system after loading the driver
 either successfully or unsucessfully.
 

Successfully: (Raid 5 4x18GB)
--
megaraid: v1.14g (Release Date: Feb 5, 2001; 11:42)
megaraid: found 0x101e:0x1960:idx 0:bus 9:slot 0:func 0
scsi3 : Found a MegaRAID controller at 0xf884e000, IRQ: 17
scsi3 : Enabling 64 bit support
megaraid: [G158:3.11] detected 1 logical drives
scsi3 : AMI MegaRAID G158 254 commands 16 targs 2 chans 40 luns
scsi3: scanning channel 1 for devices.
  Vendor: ESG-SHV   Model: SCA HSBP M9   Rev: 0.10
  Type:   Processor  ANSI SCSI revision: 02
scsi3: scanning channel 2 for devices.
scsi3: scanning virtual channel for logical drives.
  Vendor: MegaRAID  Model: LD0 RAID5 52527R  Rev: G158
  Type:   Direct-Access  ANSI SCSI revision: 02
Attached scsi disk sdb at scsi3, channel 2, id 0, lun 0
SCSI device sdb: 107575296 512-byte hdwr sectors (55079 MB)
 sdb: sdb1
---

When it was unsucessfully, it stoppet in the last line with:
sdb: unknown partition table 
(With kernel 2.4.2-2smp from redhat (RH7.1) and official 2.4.2, 2.4.3)

The only different between the to instalations is the firmware version
C158 -- G158 of the ami card.

The kernel is a 2.4.2-2smp from redhat (RH7.1). I will test the system with an
official ;-) kernel today.

Rafael Martinez

---End reply



-
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: 2.4.5pre1 will not boot

2001-05-04 Thread Seth Goldberg

Gordon Sadler wrote:
 
 On Fri, May 04, 2001 at 12:43:22AM -0700, Seth Goldberg wrote:
  Hi,
Hi,

 Have you tried compiling ther kernel with Athlon optimiztions turned
off (try
compiling for a K6-II[I])?  The has stopped the same thing from
happening on
my system and those of a few other people.

 --S


 
 What hardware are you running?
 
 AMD Duron 800
 Epox 8KTA3 m/b
 VIA KT133A AGPSet (KT133A+VT82C686B)
 128 MB pc100 brandname SDRAM
 Inter etherexpress100
 Nvidia Riva TNT (orig.)
 Quantum FB LP LM20.5
 
 Full details available in previous oops report for 2.4.4. Didn't see
 point of posting lspci -vvv, /proc/... again so soon. System here hasn't
 changed.
 
 Thanks
 
 Gordon Sadler
 
 -
 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: X15 alpha release

2001-05-04 Thread Ingo Molnar


Fabio,

i noticed another RFC anomaly in X15. It ignores the Connection: close
request header passed by a HTTP/1.1 client. This behavior is against RFC
2616, a server must not override the client's choice of non-persistent
connection. (there might be HTTP/1.1 clients that do not support
persistent connections and signal this via Connection: close.)

the rule is this: a request is either keepalive or non-keepalive. HTTP/1.0
requests default to non-keepalive. HTTP/1.1 requests default to keepalive.
The default can be overriden via the Connection: Keep-Alive or
Connection: close header fields.

if you fix this, does it impact SPECweb99 performance in any way?

Ingo

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



dhcp problem with realtek 8139 clone with rh 7.1

2001-05-04 Thread Rasmus Gunnar

Hi,

I have som problem with my realtek 8139 clone. It won't work with dhcp
against my isp. I've just installed redhat 7.1 on a i386 with to (exactly
the same) network cards, one that should be connected to my isp, and one
to
the local network. My local network works fine, but when I try to start
eth0
(which is the card connecting to my isp) I get

Determining IP configuration... Operation failed.
   failed.

If I manually try to run 'pump -i eth0' I also get Operation failed.

If I run 'mii-tool -v eth0' I get

eth0: autonegotiation failed, link ok
  product info: vendor 00:00:00, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

I've tried using the rtl8139 as well as the 8139too driver shipped with
linux kernel 2.4.4 which I'm using, and I'm trying to connect via a cable
modem.

My dmesg looks a bit strange too, I get som messages several times.

8139too Fast Ethernet driver 0.9.16
eth0: RealTek RTL8139 Fast Ethernet at 0xc4802000, 00:10:a7:08:2c:70, IRQ
11
eth0:  Identified 8139 chip type 'RTL-8139C'
eth1: RealTek RTL8139 Fast Ethernet at 0xc4804000, 00:10:a7:07:fc:83, IRQ
10
eth1:  Identified 8139 chip type 'RTL-8139C'
...
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth1: Setting half-duplex based on auto-negotiated partner ability .
IP-Config: Incomplete network configuration information.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 204k freed
Adding Swap: 265032k swap-space (priority -1)
keyboard: Timeout - AT keyboard not present?
parport0: PC-style at 0x378 [PCSPP(,...)]
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth1: Setting 100mbps full-duplex based on auto-negotiated partner ability
41e1.
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .
eth0: Setting half-duplex based on auto-negotiated partner ability .

Is this normal?

Can anybody please help getting the card to work properly?

Rgds,

/Rasmus



- The life which is unexamined is not worth living.
-Plato

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



Idea for Athlon/Duron failure testing...

2001-05-04 Thread Seth Goldberg

Hi,

   Do you think it would be a good idea to check the fast_copy
athlon mmx routine by putting in code that basically compares
the source  destination copies and checks if they are equal?
I realize that will slow down the system, but for testing,
it seems like a good idea...

 --S
-
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-fbdev-devel] Re: [PATCH] Penguin logos

2001-05-04 Thread Geert Uytterhoeven

On Thu, 3 May 2001, Geert Uytterhoeven wrote:
 Finally I found some time to incorporate the very nice logos contributed by
 Simon Budig. Thank you Simon!
 
 Patches (for both 2.4.5-pre1 and 2.4.4-ac4) can be downloaded from:
 
 http://home.tvd.be/cr26864/Linux/fbdev/logo.html

Sorry, I had forgotten to upload the new logo for SPARC. Fixed.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds

-
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: X15 alpha release: as fast as TUX but in user space (fwd)

2001-05-04 Thread bert hubert

On Thu, May 03, 2001 at 09:19:15PM +0100, Alan Cox wrote:

 If they are using glibc then you have the right to the object to link
 with the library and the library source under the LGPL. I dont know of any
 app using its own C lib

qmail is nearly there.

-- 
http://www.PowerDNS.com  Versatile DNS Services  
Trilab   The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
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: Memory management issues with 2.4.4

2001-05-04 Thread Jorge Nerín

Marcelo Tosatti wrote:

 
 On Wed, 2 May 2001, Jorge Nerin wrote:
 
 Short version:
 Under very heavy thrashing (about four hours) the system either lockups 
 or OOM handler kills a task even when there is swap space left.
 
 
 First of all, please try to reproduce the problem with 2.4.5-pre1. 
 
 If it still happens with pre1, please show us the output of cat
 /proc/slabinfo when the kernel is about to trigger the OOM killer.
 
 Thanks.
 
Well, I have tried with 2.4.5-pre1 compiled form SMP, and the result has been that 
this morning when I wake up the system has the console black (is there any way to 
prevent cons.saver from blanking the screen) and the disks where quiet, so I 
SysRQ-Sync, Umount, powerOff and then, at the last command the console wake up and I 
have been saluted with:

Kernel BUG in sched.c:709!
Invalid operand: 
Dump copied by hand, but not yet filtered by ksymoops (I'm at work now).
kernel panic Aiee, killing interrupt handler!
In interrupt not syncing.

This afternoon when I return home I will feed the stack dump to ksymoops and post the 
results, I mail this now just to see if someone sees the ligth.

-- 
Jorge Nerin
[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: X15 alpha release: as fast as TUX but in user space

2001-05-04 Thread Ingo Molnar


yet another anomaly i noticed. X15 does not appear to handle pipelined
HTTP/1.1 requests properly, it ignores the second request if two requests
arrive in the same packet.

SPECweb99 does not send pipelined requests, but a number of RL web clients
do. (Mozilla, apt-get, etc.)

Ingo

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



pdc20267 both channels share one IRQ

2001-05-04 Thread Hendrik Volker Brunn

Is it ok for an Promise Ultra 100 to have both channels
assigned the same IRQ?

I have one DTLA-307030 attached as master to each channel
and get transfer rates at around 12 - 16 MB/s.
As I have heard people reporting transfer rates of about 24 - 28 MB/s
I was wondering if there were some connections.

Is it me just being dumb and ignoring obvious facts or something 
misconfigured weirdly with my system?

Hendrik

I'm subscribed.

-- 
And I'm right. I'm always right, but in this case I'm just a bit more
right than I usually am -- Linus Torvald, Sunday Aug 27, 2000.
## Linux 2.4.4 running on an i586 ##
-
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 alpha semaphores optimization

2001-05-04 Thread Ivan Kokshaysky

On Thu, May 03, 2001 at 07:28:48PM +0200, Andrea Arcangeli wrote:
 I'd love if you could port it on top of this one and to fix it so that
 it can handle up to 2^32 sleepers and not only 2^16 like we have to do
 on the 32bit archs to get good performance:
 
   
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4aa3/00_rwsem-11

It could be done without much pain for both official and your rwsem
implementations.
However, there are 3 reasons why I prefer 16-bit counters:
a. max user processes ulimit is much lower than 64K anyway;
b. long count would cost extra 8 bytes in the struct rw_semaphore;
c. I can use existing atomic routines which deal with ints.

Actually I'm more anxious about a __builtin_expect() problem,
and I'd like to hear Richard's comment on this...

Ivan.
-
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 alpha semaphores optimization

2001-05-04 Thread David Howells

Hello Ivan,

One reason I picked signed long as the count type in the lib/rwsem.c is that
this would be 64 bits on a 64-bit arch such as the alpha.

So I've taken your idea for include/asm-alpha/rwsem.h and modified it a
little. You'll find it attached at the bottom.

I don't know whether it will (a) compile, or (b) work... I don't have an alpha
to play with.

I also don't know the alpha function calling convention, so I can't put direct
calls to the fallback routines in lib/rwsem.c from the .subsection 2
bits. Can you do that, or can you tell me how the calling convention works?

Cheers,
David

===
#ifndef _ALPHA_RWSEM_H
#define _ALPHA_RWSEM_H

/*
 * Written by Ivan Kokshaysky [EMAIL PROTECTED], 2001.
 * Based on asm-alpha/semaphore.h and asm-i386/rwsem.h
 */

#ifndef _LINUX_RWSEM_H
#error please dont include asm/rwsem.h directly, use linux/rwsem.h instead
#endif

#ifdef __KERNEL__

#include linux/list.h
#include linux/spinlock.h

struct rwsem_waiter;

extern struct rw_semaphore *rwsem_down_read_failed(struct rw_semaphore *sem);
extern struct rw_semaphore *rwsem_down_write_failed(struct rw_semaphore *sem);
extern struct rw_semaphore *rwsem_wake(struct rw_semaphore *);

/*
 * the semaphore definition
 */
struct rw_semaphore {
signed long count;
#define RWSEM_UNLOCKED_VALUE0x
#define RWSEM_ACTIVE_BIAS   0x0001
#define RWSEM_ACTIVE_MASK   0x
#define RWSEM_WAITING_BIAS  (-0x0001)
#define RWSEM_ACTIVE_READ_BIAS  RWSEM_ACTIVE_BIAS
#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
spinlock_t  wait_lock;
struct list_headwait_list;
#if RWSEM_DEBUG
int debug;
#endif
};

#if RWSEM_DEBUG
#define __RWSEM_DEBUG_INIT  , 0
#else
#define __RWSEM_DEBUG_INIT  /* */
#endif

#define __RWSEM_INITIALIZER(name) \
{ ATOMIC_INIT(RWSEM_UNLOCKED_VALUE), SPIN_LOCK_UNLOCKED, \
LIST_HEAD_INIT((name).wait_list) __RWSEM_DEBUG_INIT }

#define DECLARE_RWSEM(name) \
struct rw_semaphore name = __RWSEM_INITIALIZER(name)

static inline void init_rwsem(struct rw_semaphore *sem)
{
sem-count = RWSEM_UNLOCKED_VALUE;
spin_lock_init(sem-wait_lock);
INIT_LIST_HEAD(sem-wait_list);
#if RWSEM_DEBUG
sem-debug = 0;
#endif
}

static inline void __down_read(struct rw_semaphore *sem)
{
signed long oldcount, temp;
__asm__ __volatile__(
1: ldq_l %0,%1\n
   addq %0,%3,%2\n
   stq_c %2,%1\n
   beq %2,2f\n
#ifdef CONFIG_SMP
   mb\n
#endif
.subsection 2\n
2: br 1b\n
.previous
:=r (oldcount), =m (sem-count), =r (temp)
:Ir (RWSEM_ACTIVE_READ_BIAS), m (sem-count) : memory);

if (oldcount  0)
rwsem_down_read_failed(sem);
}

static inline void __down_write(struct rw_semaphore *sem)
{
signed long granted, temp;
__asm__ __volatile__(
1: ldq_l %0,%1\n
   addq %0,%3,%2\n
   stq_c %2,%1\n
   beq %2,2f\n
#ifdef CONFIG_SMP
   mb\n
   cmpeq %0,0,%0\n
#endif
.subsection 2\n
2: br 1b\n
.previous
:=r (granted), =m (sem-count), =r (temp)
:Ir (RWSEM_ACTIVE_WRITE_BIAS), m (sem-count) : memory);

if (!granted)
rwsem_down_write_failed(sem);
}

static inline void __up_read(struct rw_semaphore *sem)
{
signed long oldcount, temp;
__asm__ __volatile__(
1: ldq_l %0,%1\n
   subq %0,%3,%2\n
   stq_c %2,%1\n
   beq %2,2f\n
#ifdef CONFIG_SMP
   mb\n
#endif
.subsection 2\n
2: br 1b\n
.previous
:=r (oldcount), =m (sem-count), =r (temp)
:Ir (RWSEM_ACTIVE_READ_BIAS), m (sem-count) : memory);

if (oldcount  0)
if ((count  RWSEM_ACTIVE_MASK) == 0)
rwsem_wake(sem);
}

static inline void __up_write(struct rw_semaphore *sem)
{
signed long count, cmp;
__asm__ __volatile__(
1: ldq_l %0,%1\n
   subq %0,%3,%2\n
   stq_c %2,%1\n
   beq %2,2f\n
#ifdef CONFIG_SMP
   mb\n
   cmpeq %0,%3,%2\n
   subq %0,%3,%0\n
#endif
.subsection 2\n
2: br 1b\n
.previous
:=r (count), =m (sem-count), =r (cmp)
:Ir (RWSEM_ACTIVE_WRITE_BIAS), m (sem-count) : memory);

if (!cmp)
if ((count  RWSEM_ACTIVE_MASK) == 0)
rwsem_wake(sem);
}

#define rwsem_atomic_add(val, sem)  atomic_add(val, (sem)-count)
#define rwsem_atomic_update(val, sem)   atomic_add_return(val, (sem)-count)

#endif /* __KERNEL__ */
#endif /* 

Re: aic7xxx: first mount always fails

2001-05-04 Thread David Santinoli

On Mon, Apr 23, 2001 at 10:27:50PM -0600, Justin T. Gibbs wrote:
 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.
It was a hardware issue indeed - an upgrade of the drive firmware solved the
problem.

Cheers,
 David
-
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 alpha semaphores optimization

2001-05-04 Thread Ivan Kokshaysky

On Fri, May 04, 2001 at 10:22:53AM +0100, David Howells wrote:
 Hello Ivan,

Hello David!

 I don't know whether it will (a) compile, or (b) work... I don't have an alpha
 to play with.

It looks ok at a first glance, I can try it today.

 I also don't know the alpha function calling convention, so I can't put direct
 calls to the fallback routines in lib/rwsem.c from the .subsection 2
 bits. Can you do that, or can you tell me how the calling convention works?

Calling C routines from inline asm is quite painful on alpha. Lots of
registers will be clobbered, so you need some wrapper functions preserving
them. It was done in 2.2 this way, but that code was hardly maintainable...

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



Athlon/VIA Kernel Experimentation (mmx.c)

2001-05-04 Thread Seth Goldberg

Hi,

  I implemented a small check loop at the end of the fast_page_copy
routine in mmx.c for the Athlon.  Booting the resulting kernel
yields an interesting result. Every single time, the kernel
panics RIGHT AFTER it frees unused kernel memory from bootup.
I encourage those of you with the same problem to try this and report
when it panics.

Here is my patch to mmx.c: (sorry about the long lines)
-cut here
diff -r linux-ref/arch/i386/lib/mmx.c linux/arch/i386/lib/mmx.c
204a205,216

   {
   register int x = 0;
   /* do mem compares to ensure written == read */
   for ( /* initted above */; x  (4096/sizeof(int)); x++ )
   {
   if ( ((int *)to)[x] != ((int *)from)[x] ) {
   panic(fast_page_copy: dest value @ 0x%lx (%x) does 
not equal source value @ %lx (%x)!\n,
   (long) to, ((int *)to)[x], (long) 
from, ((int *) from)[x] );
   }
   }
   }  
-cut here

  Wouldn't it be correct to say that because it is panicking, the
page copy was not completed properly?  If that is so, the next step
is to find out why this copy is not working properly...

For me the output is:

...
Freeing unused kernel memory: 188k freed 
Kernel panic: fast_page_copy: dest value @ 0xcfed1000 (39312036) does
not equal source value @ cfed4000(79005b)!



It is interesting to note that these addresses are page aligned, meaning
that the copy of even
the first byte failed!

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



tmpfs doesn't update free memory stats?

2001-05-04 Thread Jacek Kopecky

 Hello. 8-)
 I'm not in the list, please cc your replies to me.
 After upgrading to 2.4.4 I started using tmpfs for /tmp and I
noticed a strange behavior:

 dd if=/dev/zero of=blah bs=1024 count=102400
# increased my used swap space by approx. 100MiB (correct)
 rm blah
# did not decrease it back

 Multiple retries showed what looked like a random behavior of
the used swap stats. Is this a correct behavior? Should the swap
stats be dismissed as 'unreliable'? I expected that when creating
a 100MiB file in memory it should increase the swap (or memory)
usage by cca 100MiB and that removing a file from tmpfs means
freeing the memory.
 Best regards

Jacek Kopecky
   Idoox



-
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: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4

2001-05-04 Thread Martin.Knoblauch

Alan Cox wrote:
 
   my DE-620 pccard stopped working after upgrading the kernel from
  2.4.3-ac7 to 2.4.4. This is on a Toshiba 4080XCDT. I used the good
  .config from the 2.4.3-ac7 build to do a make oldconfig. The symptoms
  at startup are:
 
 2.4.4 has older pcmcia than 2.4.3-ac7. It might be that. Does 2.4.4-ac work ?

 just some additional info. The card actually stopped working in
2.4.3-a11 upwards with the same symptoms as in my original request.

 2.4.3-ac9 is the last working one. Not sure about -ac10, because that
one crashes during boot (not related to pcmcia as far as I can
remember). So, what was added in ac11 or ac10 that could hurt pcmcia or
the i82365 module?

 I'll now try 2.4.4-ac4.

Martin
-- 
--
Martin Knoblauch |email:  [EMAIL PROTECTED]
TeraPort GmbH|Phone:  +49-89-510857-309
IT Services  |Fax:+49-89-510857-111
http://www.teraport.de   |Mobile: +49-170-4904759

begin:vcard 
n:Knoblauch;Martin
tel;cell:+49-170-4904759
tel;fax:+49-89-510857-111
tel;work:+49-89-510857-309
x-mozilla-html:FALSE
url:http://www.teraport.de
org:TeraPort GmbH;IT-Services
adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany
version:2.1
email;internet:[EMAIL PROTECTED]
title:Senior System Engineer
x-mozilla-cpt:;32160
fn:Martin Knoblauch
end:vcard



Re: [PATCH] strtok - strsep (The Easy Cases)

2001-05-04 Thread Rene Scharfe

Am Freitag,  4. Mai 2001 02:57 schrieb Rusty Russell:
 In message 01050120580701.01713@golmepha you write:
  Hello,

Hi!

 
  the patch at the bottom does the bulk job of strtok replacement. It's a
  very boring patch, containing easy cases, only. It became a bit big, too,
  but I trust you can digest it nevertheless. It's made against kernel
  version 2.4.4.

 There are two cases where the substitution is problematic:

Yes, but...

The cases which my patch modifies are of a different kind:

int parse_options(char *options)
{
char *p;

/* for (p = strtok(options, ,); p; p = strtok(NULL, ,)) { */
while (p = strsep(options, ,)) {
/* ... */
}
return 0;
}

No temporary array, no kfree(). Our variable options is used for strtsep,
only. Notice btw. how we destoy the string content to which options
points with both strtok and strsep.

That said, it's possible I made a stupid mistake, of course. Or two. Do
you agree on the correctness of the code above? If not, forget the whole
thing and I'll try again later.



 Array:
   char tmparray[500];
   strcpy(tmparray, str);

   /* for (p = strtok(tmparray, n); p; p = strtok(NULL, n)) { */
   while ((p = strsep(tmparray, ,))) {

 This is clearly wrong, and invokes a compiler warning.  tmparray ==
 tmparray (a cute C oddity I've never really liked).  You are blowing
 away the first few characters in tmparray, and your parser won't work
 properly.

 Dynamic:

   char *tmp = strdup(str);

   /* for (p = strtok(tmp, n); p; p = strtok(NULL, n)) { */
   while ((p = strsep(tmp, ,))) {
   ...
   }

   kfree(tmp);

 Here, tmp has changed in the strsep implementation, and kfree will do
 bad things.

 There is a real reason to avoid strtok, and that is SMP and multple
 threads calling it at once (that said, I don't know of a problem yet).
 But this patch is a step backwards.

 Rusty.
 --
 Premature optmztion is rt of all evl. --DK


René

-
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: Possible PCI subsystem bug in 2.4

2001-05-04 Thread Rogier Wolff

Linus Torvalds wrote:
 
 On Thu, 3 May 2001, Alan Cox wrote:
  
  Obvious one is to go to the next power of two clear. 
 
 The question is mainly _which_ power of two. 
 
 I don't think we can round up infinitely, as that might just end up
 causing us to not have any PCI space at all. Or we could end up deciding
 that real PCI space is memory, and then getting a clash when a real device
 tries to register its bios-allocated area that clashes with our extreme
 rounding.
 
 I suspect it would be safe to round up to the next megabyte, possibly up
 to 64MB or so. But much more would make me nervous.
 
 Any suggestions? 

The amount of RAM in a machine almost always has just one or two 1
bits. 

8, 16, 20, 24, 32, 36, 40, 48, 64, 80 Mb were the numbers that you'd
see in the early Pentium times, right?

So rounding up would mean: Add one until the number of 1-bits in the
address is less than 3. People with 3 or more differently sized DIMMS
in their machine will experience a slightly ineffcient round-up. 

Speed this up with: Find-lowest-1-bit, add that. 

Example you quoted:
nr of 1 bits. 
BIOS-proclaimed end-of-ram: 0x13fff 15
lowest 1-bit:   0x1  1
add:0x14000  2


long round_highmem (long val)
{
while (hweight32 (val)  2)
val += 1  ffs (val); 
return val;
}

Roger. 


-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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/



added a new feature: disable pc speaker

2001-05-04 Thread Nico Schottelius

Hi guys!

I have searched a long time for a method to disable the internal
speaker for every application, every daemon and so on.
With the help of [] I have found the right file :

drivers/char/vt.c

Now I have made some changes to this file (from 2.4.4 kernel).
I wanted to ask you whether you can/will put this feature into the next
kernel release (f.i. 2.4.5).
Below is a description of what I did, hope I changed the right
files and didn't brake any kernel structure...
That's also the reason I don't send a config.in diff.

Regards,

Nico


1. Changed vt.c (diff attached)
2. Changed arch/{i386,alpha,ppc,arm,mips}/config.in :

if [ $CONFIG_EXPERIMENTAL = y ]; then
   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
fi

(should be the last item of the 'General Setup' Menu)

3. Changed init/main.c (diff attached)
4. wrote text for Configure.help:

-

Disables the Internal (PC) speaker
CONFIG_DISABLE_PC_SPEAKER
  Whenever you don't want your computer to be able to beep,
  choose this option. Not selected, the computer will be able
  to beep.

  Attention: This will not catch the beeps made directly by the
  BIOS (mostly this happens when using a notebook and pressing
  special key codes). To disable this BIOS-beep enter the
  BIOS and change it there.

  If you are unsure, say N to this.

-

If you allow this thing to get into the kernel, could
Axel Bold ([EMAIL PROTECTED] as found in Configure.help)
put this text into the Configure.help file ?



 diffs.tar.gz


Re: [PATCH] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Rogier Wolff

Linus Torvalds wrote:
 
 On Thu, 3 May 2001, Alan Cox wrote:
  Ditto for some CD based stuff. You burn the important binaries to the front
  of the CD, then at boot dd 64Mb to /dev/null to prime the libraries and
  avoid a lot of seeking during boot up from the CD-ROM.
  
  However I could do that from an initrd before mounting
 
 Ehh. Doing that would be extremely stupid, and would slow down your boot
 and nothing more.

Ehhh, Linus, Linearly reading my harddisk goes at 26Mb per second. By
analyzing my boot process I determine that 50M of my disk is used
during boot. I can then reshuffle my disk to have that 50M of data at
the beginning and reading all that into 50M of cache, I can save
thousands of 10ms seeks. Boot time would go from several tens of
seconds to 2 seconds worth of DISK IO plus several seconds of pure CPU
time.

This doesn't work if I don't have the memory to cache 50M of
disk-blocks.

Is this simply: Don't try this then? 

Roger. 


-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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: added a new feature: disable pc speaker

2001-05-04 Thread Simon Richter

On Fri, 4 May 2001, Nico Schottelius wrote:

 I have searched a long time for a method to disable the internal
 speaker for every application, every daemon and so on.

It would be cool if that weren't a compile time option but configurable at
runtime (via sysctl).

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: DC26 EB8D 1F35 4F44 2934  7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

-
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] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Jens Axboe

On Fri, May 04 2001, Rogier Wolff wrote:
  On Thu, 3 May 2001, Alan Cox wrote:
   Ditto for some CD based stuff. You burn the important binaries to the front
   of the CD, then at boot dd 64Mb to /dev/null to prime the libraries and
   avoid a lot of seeking during boot up from the CD-ROM.
   
   However I could do that from an initrd before mounting
  
  Ehh. Doing that would be extremely stupid, and would slow down your boot
  and nothing more.
 
 Ehhh, Linus, Linearly reading my harddisk goes at 26Mb per second. By
 analyzing my boot process I determine that 50M of my disk is used
 during boot. I can then reshuffle my disk to have that 50M of data at
 the beginning and reading all that into 50M of cache, I can save
 thousands of 10ms seeks. Boot time would go from several tens of
 seconds to 2 seconds worth of DISK IO plus several seconds of pure CPU
 time.

Provided that the buffer cache and page cache are coherent, which they
are not. So at most you'll cache fs meta data by doing the dd trick,
which is hardly worth the effort.

Or you can rewrite block_read/write to use the page cache, in which case
you'd have more luck doing the above.

-- 
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: [PATCH] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Marc SCHAEFER

Rogier Wolff [EMAIL PROTECTED] wrote:
 during boot. I can then reshuffle my disk to have that 50M of data at
 the beginning and reading all that into 50M of cache, I can save

Wasn't that one of the goals of the LVM project, along snapshots and
block-level HSM ?

-
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: SMP races in proc with thread_struct

2001-05-04 Thread Todd Inglett

Ok, I've got this isolated.  Here's the sequence of events:

1.  Some process T (probably top) opens /proc/N/stat.
2.  While holding tasklist_lock the proc code does a get_task_struct()
to add a ref count to the page.
3.  Process N exits.
4.  The parent of process N exits.
5.  Process T reads from the open file.  This calls proc_pid_stat()
which dereferences N's task_struct.  This is ok as Alexander points out
because a reference is held.
6.  Using N's task_struct process T attempt to dereference the *parent*
task struct.  It assumes this is ok because:
A) it is holding tasklist_lock so N cannot be reparented in a race.
B) every process *always* has a valid parent.

But this is where hell breaks loose.  Every process has a valid parent
-- unless it is dead and nobody cares.  Process N has already exited and
released from the tasklist while its parent was still alive.  There was
no reason to reparent it.  It just got released.  So N's task_struct has
a dangling ptr to its parent.  Nobody is holding the parent task_struct,
either.  When the parent died memory for its task_struct was released. 
This is ungood.


My opinion here is that this is proc's problem.  When we free a
task_struct it could be cleaned up of dangling ptrs, but this is a
hack to cover a bug in proc.

This is not isolated to the parent task_struct, either.  The task_struct
mm is also dereferenced.  It is pretty easy to validate a parent
task_struct ptr (just hold tasklist_lock and run the list to check if it
is still valid -- might not be the *right* task, but it will still be
valid).  However, how do you validate the mm is ok?

It would be nice if there were an easy way to detect when the process
gets into this state.  Certainly it is in this state if the page
reference count is 1.  But multiple processes *could* be reading the
same proc file holding additional artificial ref counts.

Hmm...perhaps if I scan the tasklist for my own task?  If I am not in
the list I either return an error or faked info.  I'll try this

-- 
-todd

BTW, by adding code to validate the parent my test has now run for 18
hours on a 4-way without failure.  It otherwise would fail within the
first 5 minutes.
-
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: Swap space deallocation speed. (fwd)

2001-05-04 Thread Stephen C. Tweedie

Hi,

On Thu, May 03, 2001 at 12:03:39AM -0400, Dave Mielke wrote:

 unresponsive. The relevant line in the log, as you can find in the attached
 crash.log file, appears to be:
 
 Unable to handle kernel paging request at virtual address 00020024

 Apr 16 11:23:06 dave kernel: esi: 0002   edi: c14ff5d0   ebp: c3e6a6d0   esp: 
c142ff30 

This looks like a random bit flip in a page table.  That's almost
always a hardware problem.  Stop overclocking if you are doing that;
check that the CPU fan is still working, etc.

Cheers, 
 Stephen
-
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: added a new feature: disable pc speaker

2001-05-04 Thread Keith Owens

On Fri, 04 May 2001 13:37:08 +0200, 
Nico Schottelius [EMAIL PROTECTED] wrote:
I have searched a long time for a method to disable the internal
speaker for every application, every daemon and so on.

Userspace problem, userspace fix.

  setterm -blength 0 (text)
  xset b 0 (X11)

-
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: pcmcia problems after upgrading from 2.4.3-ac7 to 2.4.4

2001-05-04 Thread Martin.Knoblauch

Martin.Knoblauch wrote:
 
 Alan Cox wrote:
 
my DE-620 pccard stopped working after upgrading the kernel from
   2.4.3-ac7 to 2.4.4. This is on a Toshiba 4080XCDT. I used the good
   .config from the 2.4.3-ac7 build to do a make oldconfig. The symptoms
   at startup are:
 
  2.4.4 has older pcmcia than 2.4.3-ac7. It might be that. Does 2.4.4-ac work ?
 
  just some additional info. The card actually stopped working in
 2.4.3-a11 upwards with the same symptoms as in my original request.
 
  2.4.3-ac9 is the last working one. Not sure about -ac10, because that
 one crashes during boot (not related to pcmcia as far as I can
 remember). So, what was added in ac11 or ac10 that could hurt pcmcia or
 the i82365 module?
 
  I'll now try 2.4.4-ac4.
 

 done. Unfortunatelly, it fails with the same symptoms as posted
initially. 

Thanks
Martin
-- 
--
Martin Knoblauch |email:  [EMAIL PROTECTED]
TeraPort GmbH|Phone:  +49-89-510857-309
IT Services  |Fax:+49-89-510857-111
http://www.teraport.de   |Mobile: +49-170-4904759

begin:vcard 
n:Knoblauch;Martin
tel;cell:+49-170-4904759
tel;fax:+49-89-510857-111
tel;work:+49-89-510857-309
x-mozilla-html:FALSE
url:http://www.teraport.de
org:TeraPort GmbH;IT-Services
adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany
version:2.1
email;internet:[EMAIL PROTECTED]
title:Senior System Engineer
x-mozilla-cpt:;32160
fn:Martin Knoblauch
end:vcard



Re: SMP races in proc with thread_struct

2001-05-04 Thread Keith Owens

On Fri, 04 May 2001 07:34:20 -0500, 
Todd Inglett [EMAIL PROTECTED] wrote:
But this is where hell breaks loose.  Every process has a valid parent
-- unless it is dead and nobody cares.  Process N has already exited and
released from the tasklist while its parent was still alive.  There was
no reason to reparent it.  It just got released.  So N's task_struct has
a dangling ptr to its parent.  Nobody is holding the parent task_struct,
either.  When the parent died memory for its task_struct was released. 
This is ungood.

Wrap the reference to the parent task structure with exception table
recovery code, like copy_from_user().  If the dangling reference points
to valid memory the worst that will happen is that you read and report
gibberish for one output.  If the reference causes an exception then
recover and treat it as NULL.  For a read only case, the only important
thing is not to die, one occurrence of bad data is tolerable.

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



Question on mmap(2) with kernel alocated memory

2001-05-04 Thread Terry Barnaby

I am trying to mmap() into user space a kernel buffer  and am having
problems.
I have a simple test example, can someone please tell me what I have got
wrong ?

In a driver I do:
uint*kva;

kva = (uint*)kmalloc(4096, GFP_KERNEL);
*kva = 0x11223344;
printk(Address: %p %lx %x\n, kva, virt_to_phys(kva), *kva);

Now in some simple user program I do:

#include stdio.h
#include string.h
#include stdlib.h
#include sys/mman.h
#include fcntl.h

int main(int argc, char** argv){
 int fm;
 char* p;
 uint* pi;
 uint v;
 uint add = 0x74b000;

 if((fm = open(/dev/mem, O_RDWR))  0)
  return 1;

 p = mmap(0, 128 * 1024 * 1024, PROT_READ|PROT_WRITE, MAP_SHARED, fm,
0);
 printf(Mapped: %p\n, p);

 lseek(fm, add, SEEK_SET);
 read(fm, v, sizeof(v));
 printf(V: %x\n, v);

 pi = (uint*)(p + add);
 printf(Vmmap: %p %x\n, pi, *pi);

 close(fm);
 return 0;
}

The value of add is hardcoded to the value printed for the physical
address in the drivers prink routine.
The lseek/read from the /dev/mem device yields the value 0x11223344.
However the mmap method also on /dev/mem yields the value 0.

Whats wrong with my mmap() or kalloc() ?

Terry

--
  Dr Terry Barnaby BEAM Ltd
  Phone: +44 1454 324512   Northavon Business Center, Dean Rd
  Fax:   +44 1454 313172   Yate, Bristol, BS37 5NH, UK
  Email: [EMAIL PROTECTED]Web: www.beam.demon.co.uk
  BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software Dev
 Tandems are twice the 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: Linux 2.4.4-ac3, asm problem in asm-i386/rwsem.h using gcc 3.0 CVS

2001-05-04 Thread Christian Iseli


[EMAIL PROTECTED] said:
 Looks like if you remove the inline from the function definition
 this compiles OK. 

Yup, looks like a compiler bug.  I submitted a bug report to GCC-gnats.

Cheers,
Christian


-
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: Athlon/VIA Kernel Experimentation (mmx.c)

2001-05-04 Thread Brian Gerst

Seth Goldberg wrote:
 
 Hi,
 
   I implemented a small check loop at the end of the fast_page_copy
 routine in mmx.c for the Athlon.  Booting the resulting kernel
 yields an interesting result. Every single time, the kernel
 panics RIGHT AFTER it frees unused kernel memory from bootup.
 I encourage those of you with the same problem to try this and report
 when it panics.
 
 Here is my patch to mmx.c: (sorry about the long lines)
 -cut here
 diff -r linux-ref/arch/i386/lib/mmx.c linux/arch/i386/lib/mmx.c
 204a205,216
 
{
register int x = 0;
/* do mem compares to ensure written == read */
for ( /* initted above */; x  (4096/sizeof(int)); x++ )
{
if ( ((int *)to)[x] != ((int *)from)[x] ) {
panic(fast_page_copy: dest value @ 0x%lx (%x) does 
not equal source value @ %lx (%x)!\n,
(long) to, ((int *)to)[x], (long) 
from, ((int *) from)[x] );
}
}
}
 -cut here
 
   Wouldn't it be correct to say that because it is panicking, the
 page copy was not completed properly?

No, you are comparing the following two pages... from and to are
incremented as the copy proceeds.  Subtract PAGE_SIZE from them before
comparing.

--

Brian Gerst
-
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: SMP races in proc with thread_struct

2001-05-04 Thread Andreas Schwab

Keith Owens [EMAIL PROTECTED] writes:

| On Fri, 04 May 2001 07:34:20 -0500, 
| Todd Inglett [EMAIL PROTECTED] wrote:
| But this is where hell breaks loose.  Every process has a valid parent
| -- unless it is dead and nobody cares.  Process N has already exited and
| released from the tasklist while its parent was still alive.  There was
| no reason to reparent it.  It just got released.  So N's task_struct has
| a dangling ptr to its parent.  Nobody is holding the parent task_struct,
| either.  When the parent died memory for its task_struct was released. 
| This is ungood.
| 
| Wrap the reference to the parent task structure with exception table
| recovery code, like copy_from_user().

Exception tables only protect accesses to user virtual memory.  Kernel
memory references must always be valid in the first place.

Andreas.

-- 
Andreas Schwab  And now for something
SuSE Labscompletely different.
[EMAIL PROTECTED]
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
-
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: tmpfs doesn't update free memory stats?

2001-05-04 Thread Christoph Rohland

Hi Jacek,

On Fri, 4 May 2001, Jacek Kopecky wrote:
  I'm not in the list, please cc your replies to me.
  After upgrading to 2.4.4 I started using tmpfs for /tmp and I
 noticed a strange behavior:
 
  dd if=/dev/zero of=blah bs=1024 count=102400
   # increased my used swap space by approx. 100MiB (correct)
  rm blah
   # did not decrease it back
 
  Multiple retries showed what looked like a random behavior of
 the used swap stats. Is this a correct behavior? Should the swap
 stats be dismissed as 'unreliable'? I expected that when creating
 a 100MiB file in memory it should increase the swap (or memory)
 usage by cca 100MiB and that removing a file from tmpfs means
 freeing the memory.

It will be adjusted under memory pressure. At this time there is no
way to release swap cached pages without the potential of deadlocks.

This is not nice but the only short term solution and should not
affect anything besides stats.

Greetings
Christoph


-
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: SMP races in proc with thread_struct

2001-05-04 Thread Brian Gerst

Andreas Schwab wrote:
 
 Keith Owens [EMAIL PROTECTED] writes:
 
 | On Fri, 04 May 2001 07:34:20 -0500,
 | Todd Inglett [EMAIL PROTECTED] wrote:
 | But this is where hell breaks loose.  Every process has a valid parent
 | -- unless it is dead and nobody cares.  Process N has already exited and
 | released from the tasklist while its parent was still alive.  There was
 | no reason to reparent it.  It just got released.  So N's task_struct has
 | a dangling ptr to its parent.  Nobody is holding the parent task_struct,
 | either.  When the parent died memory for its task_struct was released.
 | This is ungood.
 |
 | Wrap the reference to the parent task structure with exception table
 | recovery code, like copy_from_user().
 
 Exception tables only protect accesses to user virtual memory.  Kernel
 memory references must always be valid in the first place.
 
 Andreas.

The virtual address being accessed is irrelevant.  It's the address of
the faulting instruction that determines what the kernel will do if it
can't deal with a page fault.  If the access was made from kernel mode
the exception handler (if there is one) always gets invoked, otherwise
it oopses.

--

Brian Gerst
-
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 syscall speed -- was X15 rootin-tootin webserver

2001-05-04 Thread Michael Rothwell

There seems to be a contingent of people on the LKML who think that it
is appropriate to flame people off-list, in order to bask in their own
superiority, or prove that they are smarter by pointing out that someone
is an idiot, etc. I would figure that most intelligent people would
simply ignore posts they don't like, rather than investing time and
bandwidth compounding the perceived offense. But I'm apparently too
optimistic on that point; any group of people the size of the LKML will
always contain some juviniles. A great many of us have suffered their
attention.

-M

On 04 May 2001 11:21:48 +1000, Rusty Russell wrote:
 In message 988856961.6355.1.camel@gromit you write:
  According to tests performed at IBM:
  
  http://www-106.ibm.com/developerworks/linux/library/l-rt1/
  
  Linux's sycalls are a little more than twice as fast as those of Windows
 
 This post was pretty much a waste of space, wasn't it?
 
  2000. 0.75usec vs 2.0msec.
 
 That would be 2,666 times.
 
 Rusty.
 --
 Premature optmztion is rt of all evl. --DK

-
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: Maximum files per Directory

2001-05-04 Thread Chris Mason



On Tuesday, May 01, 2001 04:57:02 PM -0600 Andreas Dilger
[EMAIL PROTECTED] wrote:

 H. Peter Anvin writes:
 Not correct, there can't be more than 2^15 *directories* in a single
 directory.  I belive this is an ext2 limitation.
 
 
 I see that reiserfs plays some tricks with the directory i_nlink count.
 If you exceed 64536 links in a directory, it reverts to 1 and no longer
 tracks the link count.

Correct.  The link count isn't used at all when deciding if the directory
is empty (we use the size instead), so we can just lie to VFS if someone
tries to make tons of subdirs.

-chris

-
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: Athlon/VIA Kernel Experimentation (mmx.c)

2001-05-04 Thread Alan Cox

 is to find out why this copy is not working properly...
 
 For me the output is:
 
 ...
 Freeing unused kernel memory: 188k freed 
 Kernel panic: fast_page_copy: dest value @ 0xcfed1000 (39312036) does
 not equal source value @ cfed4000(79005b)!

Swap the panic for a printk/BUG() and see who the caller was

-
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: FS Structs

2001-05-04 Thread Anton Altaparmakov

At 22:29 03/05/01, Anders Karlsson wrote:
I am not subscribed to the list, so if I could be CC'd on eventual
replies I would be grateful.

Sure.

I have a question regarding some of the parts of the overall
filesystem structure in the 2.4 kernel. (Kernel 2.4.[34].)
In the file fs/super.c the structure `sb' is used, that is the
superblock. As a part of that structure (reference include/linux/fs.h)
is `struct list_head s_locked_inodes;'.

The thing I can not understand at the moment is the `struct list_head'
(reference include/linux/list.h) which looks very odd. How can I find
which inodes are in the `s_locked_inodes' list?? All I want to do is
to loop through the list and see each open inode in turn, is there any
documentation for this, or is there any helpful soul out there that
could give me any pointers?

This is how Linux kernel implements generic, circular, doubly-linked lists. 
The struct list_head is used both as the beginning of the list - i.e. for 
example sb-s_dirty is the beginning of the list of dirty inodes - and also 
as the anchor into the list of each dirty inode - i.e. looking at the 
struct inode it contains a field struct list_head i_list. This is the 
anchor into the list.

To walk the list you usually use list_for_each(). In the above example you 
would use:

struct list_head *tmp;
struct inode *ino;

list_for_each(tmp, sb-s_dirty) {
 ino = list_entry(tmp, struct inode, i_list);
 /* do what you want with the inode */
}

If that wasn't clear enough you should consider reading up on this subject. 
For example Linux Kernel Internals contains a chapter on the Linux kernel 
linked list implementation. The URL for the online version 
is:  http://www.moses.uklinux.net/patches/lki.html

Hope this helps,

 Anton


-- 
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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



console=ttyS0 doesn't work 2.4.4

2001-05-04 Thread Nick Papadonis

I compiled the Linux kernel v2.4.4 and can't get 'console=ttyS0,115200
console=tty0' to work.  This appended line works fine when I boot
into my 2.2.x series kernel.

Anyone have similar problems?  Has anyone verified serial console
output works with the 2.4.x kernels?  Thanks.

- Nick

Here is my /etc/lilo.conf:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=linuxold
append=console=ttyS0,115200 console=tty0

image=/boot/vmlinuz-2.2.16-22
label=linuxold
read-only
root=/dev/hda6

image=/boot/vmlinuz-2.4.4
label=linux
read-only
root=/dev/hda6

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



expand_stack: small race

2001-05-04 Thread Manfred Spraul

expand_stack is only protected with down_read(mmap_sem), and thus 2
thread could grow a vma at the same time.

I think the spin_lock(page_table_lock) should be moved up before the
calculation of grow.

And map_user_kiobuf() doesn't honor VM_LOCKED for VM_GROWSDOWN segments.
Probably it should be switched to find_extend_vma instead of the
do-it-yourself implementation.

--
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: [PATCH] strtok - strsep (The Easy Cases)

2001-05-04 Thread Rusty Russell

In message 01050413055100.00907@golmepha you write:
 Am Freitag,  4. Mai 2001 02:57 schrieb Rusty Russell:
  There are two cases where the substitution is problematic:
 
 Yes, but...
 
 The cases which my patch modifies are of a different kind:

The very first hunk of your patch is wrong.  I didn't check the
others.  Note that the declaration of switches is:

char switches[len+1];

--- linux-2.4.4/arch/m68k/atari/config.cTue Nov 28 02:57:34 2000
+++ linux-2.4.4-rs/arch/m68k/atari/config.c Tue May  1 17:03:46 2001
@@ -206,13 +206,15 @@
 
 /* parse the options */
-for( p = strtok( switches, , ); p; p = strtok( NULL, , ) ) {
+while( p = strsep( switches, , ) ) {
+   if (!*p)
+   continue;
ovsc_shift = 0;
if (strncmp( p, ov_, 3 ) == 0) {
p += 3;

Cheers,
Rusty.
--
Premature optmztion is rt of all evl. --DK
-
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: SMP races in proc with thread_struct

2001-05-04 Thread Andreas Ferber

Hi,

On Fri, May 04, 2001 at 10:46:43PM +1000, Keith Owens wrote:

 For a read only case, the only important
 thing is not to die, one occurrence of bad data is tolerable.

Strong NACK. The pages where the bad data comes from may in some cases
already be reclaimed for other data, probably something security
relevant, which should never ever be given even read access by an
unauthorized user. Even if this event may be a very rare case, one
single occurrence of this is one to much.

Andreas
-- 
Ich nehm nicht mal Zucker in den den Kaffee.
Dafür nehm ich nichtmal Kaffee.
   (Peter Backof + Bernhard Schultz in detebe)

-
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 alpha semaphores optimization

2001-05-04 Thread Andrea Arcangeli

On Fri, May 04, 2001 at 01:15:28PM +0400, Ivan Kokshaysky wrote:
 However, there are 3 reasons why I prefer 16-bit counters:

I assume you mean 32bit counter. (that gives max 2^16 sleepers)

 a. max user processes ulimit is much lower than 64K anyway;

the 2^16 limit is not a per-user limit it is a global one so the max
user process ulimit is irrelevant.

Only the number of pid and the max number of tasks supported by the
architecture is a relevant limit for this.

 b. long count would cost extra 8 bytes in the struct rw_semaphore;

correct but that's the feature to be able to support 2^32 concurrent
sleepers at not relevant runtime cost 8).

 c. I can use existing atomic routines which deal with ints.

I was thinking at a dedicated routine that implements the slow path by
hand as well like x86 just do. Then using ldq instead of ldl isn't
really a big deal programmer wise.

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/



close()

2001-05-04 Thread Mike Harrold

Hi,

We have a server which runs on a machine that now runs the new 2.4 kernel.
Since upgrading we've seen periods where it seems to just hang for minutes
at a time (anywhere form 5 minutes to an hour). I was finally able to get
a core dump of the server during one of these periods and it appears that
the hang is occuring during a call to close().

Has anyone else seen anything like this? Kernel version is:

  Linux version 2.4.2-4GB ([EMAIL PROTECTED])

Thanks,

/Mike


-
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: dhcp problem with realtek 8139 clone with rh 7.1

2001-05-04 Thread Michael K. Johnson

In linux-kernel, you wrote:
I have som problem with my realtek 8139 clone. It won't work with dhcp
against my isp. I've just installed redhat 7.1 on a i386 with to (exactly
the same) network cards, one that should be connected to my isp, and one
to
the local network. My local network works fine, but when I try to start
eth0
(which is the card connecting to my isp) I get

Determining IP configuration... Operation failed.
   failed.

If I manually try to run 'pump -i eth0' I also get Operation failed.

This sounds more like pump failing to negotiate dhcp properly than
like a failure in the driver.  Let's check that possibility first
before assuming a driver bug.

Install dhcpcd, chmod a-x /sbin/pump, and see if it works better
(if pump is not there or not executable, the scripts fall back to
dhcpcd).  If so, please file a bug report against pump in buzilla
http://bugzilla.redhat.com/bugzilla/

michaelkjohnson

 He that composes himself is wiser than he that composes a book.
 Linux Application Development -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/
-
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/



modularized SYSENTER support

2001-05-04 Thread Andy Polyakov

Hi,

Below is the comment section from my SYSENTER module. Code itself (~20K)
can be found at the URL below. I want to point out that I'm not
subscribed to the linux-kernel list and would appreciate if you drop me
a CC when (or if:-) commenting.

http://fy.chalmers.se/~appro/linux/sysenter.c

Copyright (c) 2001 by [EMAIL PROTECTED]

This is Linux kernel module implementing support for Intel SYSENTER
Fast System Call facility (see IA-32 System Programming Guide for
further details). It's meant for research purposes and is subject to
usual no-warranty-don't-complain blah-blah...

As I figured after the module was almost ready the matter has already
been discussed on the kernel development list in late December, 1999
and the idea was basically condemned... Well, when I started I wanted
to learn kernel insights and I certainly did so that the project
goal was achieved. And then I felt like sharing it:-)

Note that it's not a patch, but a loadable module! Well, it does some
*run-time* patching to 2.2.x kernel by replacing first instructions of
the context switching procedure with jump instruction transferring the
control to equivalent procedure of own design, but there is no source
code patching involved...

If executed, this file (yes, this is self-compiling C-code:-) will
compile and install the module, compile shared object (to be preloaded
with LD_PRELOAD) overriding couple of system calls and benchmarks a
syscall hungry application, namely 'dd if=/dev/zero of=/dev/null':-)
On a 550MHz PIII the program exhibits 20% performance improvement when
tricked to take the SYSENTER path.

Pre-requirements. Up-to-date kernel headers in /usr/src/linux as well
as System.map (alternatively /boot/System.map) matching the current
/proc/ksyms. See the embedded script for details. I use UTS_RELEASE
and address of sock_register() function for fingerprinting in order to
prevent module compiled for another kernel from being loaded.

Questions and answers.

Q. Is the module SMP-safe?
A. Almost. When being compiled for 2.2.x the code can be compiled to
   be cruel (run-time patching, see above, default behavior) and
   gentle. Cruel version is SMP-safe, non-cruel is not (because
   it uses a global variable). Under 2.4.x the generated code is
   always SMP-safe (unlike 2.2.x 2.4.x doesn't flip the Task Register
   at context switch thus making pointer to TSS a perfect candidate
   for SYSENTER_ESP_MSR:-).

Q. How come the handler doesn't manage so called bottom halves or
   soft IRQs?
A. There is no need for this. Soft IRQs can only appear at exit from
   hardware interrupt handlers. Indeed, we can't count on user app.
   being around and performing a system call when it comes to
   interrupt handling, right?

Q. Where do you set up the pointer to the current task structure?
A. Normally it's done with %%esp  -8192, right? Here it's done with
   leal -8152(%esp),%ebp (i.e. with carefully chosen offset:-). It's
   possible because user originated system call is always executed
   from the very bottom of kernel stack. No, kernel can't use SYSENTER
   as SYSEXIT unconditionally drops CPL to 3.

Q. Why aren't there any fix-ups?
A. Well, 1: movl -4(%%ebp),%%edi # fetch the return address and
   2: movl (%%ebp),%%ebp # fetch 6-th argument should probably be
   guarded by fix-up code. On the other hand the arguments are
   expected to be passed through flat (stack) segment. As we can't
   possibly know if user stack segment was flat (and we basically
   shouldn't care as SYSEXIT unconditionally write 0x2B to %ss) there
   isn't much reasonable we can do, but to let it fail with segfault.
   Well, I could call do_exit() in order to kill the application with
   little more discretion... Give me a reason to...

Q. What about VM86?
A. VM86 task should never call SYSENTER. It it does it should simply
   be terminated. Right now I do nothing about it counting on that the
   user code will screw itself (see also previous question) at SYSEXIT
   which unconditionally overwrites %cs and %ss with predefined
   values.

Q. What about AMD's SYSCALL/SYSRET?
A. Adaptation is trivial. It's not done only because I don't have
   access to appropriate AMD box to play with. Keep in mind that AMD
   didn't bother to provide means for setting up %esp so that non-
   cruel code is the only option. Then it should also be noted that
   later AMD processors implement Intel's SYSENTER/SYSEXIT. 

Cheers! Andy.
-
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] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Andrea Arcangeli

On Fri, May 04, 2001 at 01:56:14PM +0200, Jens Axboe wrote:
 Or you can rewrite block_read/write to use the page cache, in which case
 you'd have more luck doing the above.

once block_dev is in pagecache there will obviously be no-way to share
cache between the block device and the filesystem, because all the
caches will be in completly different address spaces.

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: Possible PCI subsystem bug in 2.4

2001-05-04 Thread Eric W. Biederman

Alan Cox [EMAIL PROTECTED] writes:

  I suspect it would be safe to round up to the next megabyte, possibly up
  to 64MB or so. But much more would make me nervous.
  Any suggestions? 
 
 I'd go for 1MByte simply because I've not seen an EBDA/NVRAM area that large
 stuck at the top of RAM. 1Mb would fix the Dell. (It was only when I saw
 your email it suddenely clicked and I grabbed the bootup log)

There are a couple of options here.
1) read the MTRRs unless the BIOS is braindead it will set up that area as
   write-back.  At any rate we shouldn't ever try to allocate a pci region
   that is write-back cached.

2) read the memory locations from the northbridge.  It's not possible
   on every chipset (lack of documentation) but with the linuxBIOS
   project we code for a couple of them, and we are working on more
   all of the time.

Eric



-
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: close()

2001-05-04 Thread Mike Harrold

 
 
 What kind of file was it close()ing?
  - jim

Ah, good question. I should have specified this. It is a socket that is
being closed, not a regular file (the socket has nonblocking set).

 p.s. Are you familiar with the strace(1) utility? It might help you get
 more information the next time this happens... especially the -p pid
 option.

I didn't think about this. I'll give this a whirl next time.

/Mike

 
 
 Mike Harrold [EMAIL PROTECTED]@vger.kernel.org on 05/04/2001 07:44:53 AM
 
 Sent by:  [EMAIL PROTECTED]
 
 
 To:   [EMAIL PROTECTED]
 cc:
 Subject:  close()
 
 
 
 Hi,
 
 We have a server which runs on a machine that now runs the new 2.4 kernel.
 Since upgrading we've seen periods where it seems to just hang for minutes
 at a time (anywhere form 5 minutes to an hour). I was finally able to get
 a core dump of the server during one of these periods and it appears that
 the hang is occuring during a call to close().
 
 Has anyone else seen anything like this? Kernel version is:
 
   Linux version 2.4.2-4GB ([EMAIL PROTECTED])
 
 Thanks,
 
 /Mike
 
 
 -
 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: console=ttyS0 doesn't work 2.4.4

2001-05-04 Thread Nick Papadonis

Solved.  Disregard.  I didn't have serial console support compiled in.

Nick Papadonis [EMAIL PROTECTED] writes:

 I compiled the Linux kernel v2.4.4 and can't get 'console=ttyS0,115200
 console=tty0' to work.  This appended line works fine when I boot
 into my 2.2.x series kernel.
 
 Anyone have similar problems?  Has anyone verified serial console
 output works with the 2.4.x kernels?  Thanks.
 
 - Nick
-
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: Possible PCI subsystem bug in 2.4

2001-05-04 Thread Alan Cox

 There are a couple of options here.
 1) read the MTRRs unless the BIOS is braindead it will set up that area as
write-back.  At any rate we shouldn't ever try to allocate a pci region
that is write-back cached.

'unless the BIOS is braindead'. Right. We only got into this problem because
the BIOS _was_ braindead.

Alan

-
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 syscall speed -- was X15 rootin-tootin webserver

2001-05-04 Thread Dan Mann

I followed the link and read the article.  I am glad you sent the link.  I
am glad to see the Linux kernel doing so well.  Does anyone else have any
Linux Kernel benchmark related links that are interesting?

Thank You,

Dan

- Original Message -
From: Michael Rothwell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 04, 2001 9:38 AM
Subject: Re: Linux syscall speed -- was X15 rootin-tootin webserver


 There seems to be a contingent of people on the LKML who think that it
 is appropriate to flame people off-list, in order to bask in their own
 superiority, or prove that they are smarter by pointing out that someone
 is an idiot, etc. I would figure that most intelligent people would
 simply ignore posts they don't like, rather than investing time and
 bandwidth compounding the perceived offense. But I'm apparently too
 optimistic on that point; any group of people the size of the LKML will
 always contain some juviniles. A great many of us have suffered their
 attention.

 -M

 On 04 May 2001 11:21:48 +1000, Rusty Russell wrote:
  In message 988856961.6355.1.camel@gromit you write:
   According to tests performed at IBM:
  
   http://www-106.ibm.com/developerworks/linux/library/l-rt1/
  
   Linux's sycalls are a little more than twice as fast as those of
Windows
 
  This post was pretty much a waste of space, wasn't it?
 
   2000. 0.75usec vs 2.0msec.
 
  That would be 2,666 times.
 
  Rusty.
  --
  Premature optmztion is rt of all evl. --DK

 -
 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: smp_send_stop() and disable_local_APIC()

2001-05-04 Thread Eric W. Biederman

Matt D. Robinson [EMAIL PROTECTED] writes:

 It looks like around 2.3.30 or so, someone added the call
 disable_local_APIC() to smp_send_stop().  I'm not sure what the
 intention was, but I'm getting some strange behavior as a result
 based on some code I'm writing.
 
 Basically, I'm doing the following ...
 
 panic()
 {
 /* do whatever you want, notifier list, etc. */
 smp_send_stop();
 write_system_memory();
 /* then do whatever */
 }
 
 write_system_memory() does a write of all system memory pages to some
 block device.  It uses kiobufs as the way to get the pages to disk,
 doing brw_kiovec() on those pages (using either the IDE or SCSI
 driver to write the data).

IDE being less likely to hang than SCSI as it tends to use legacy isa
interrupt lines.
 
 The wierd behavior I see is that sometimes, smp_send_stop()
 being called causes the system to hang up (not every time). 

Doing event driver i/o after disabling the interrupt controller
hmm, I wonder why...

 If we don't call smp_send_stop() on those systems, everything works fine.
 This looks to be directly caused by the disabling of the APIC, which
 we may need to dump pages to local disk.  This only applies to some
 people's systems -- not everyone displays the same behavior.
 
 I'm sure it's good to disable the APIC, but there's no clean way to
 wait on disabling the APIC until after I'm done writing pages out.
 
 My questions are:
 
 1) Why was disable_local_APIC() added to stop_this_cpu()
and smp_send_stop()?  Completeness?
 
 2) Is there a better way around this to disable all the
other CPUs without disabling the APIC?
 

I don't know what a good way is, since there is a kernel panic it
should only be something truly fatal.  Given that reusing anything
that hasn't been designed to run in that situation is playing with
fire.

Eric
-
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: SMP races in proc with thread_struct

2001-05-04 Thread Alexander Viro



On Fri, 4 May 2001, Todd Inglett wrote:

 Ok, I've got this isolated.  Here's the sequence of events:
 
 1.  Some process T (probably top) opens /proc/N/stat.
 2.  While holding tasklist_lock the proc code does a get_task_struct()
 to add a ref count to the page.
 3.  Process N exits.
 4.  The parent of process N exits.
 5.  Process T reads from the open file.  This calls proc_pid_stat()
 which dereferences N's task_struct.  This is ok as Alexander points out
 because a reference is held.
 6.  Using N's task_struct process T attempt to dereference the *parent*
 task struct.  It assumes this is ok because:

Where?

   A) it is holding tasklist_lock so N cannot be reparented in a race.
   B) every process *always* has a valid parent.
 
 But this is where hell breaks loose.  Every process has a valid parent
 -- unless it is dead and nobody cares.  Process N has already exited and
 released from the tasklist while its parent was still alive.  There was
 no reason to reparent it.  It just got released.  So N's task_struct has
 a dangling ptr to its parent.  Nobody is holding the parent task_struct,
 either.  When the parent died memory for its task_struct was released. 
 This is ungood.

If N is dead all accesses should return -ENOENT. No matter what
happens with its parent.

 My opinion here is that this is proc's problem.  When we free a
 task_struct it could be cleaned up of dangling ptrs, but this is a
 hack to cover a bug in proc.
 
 This is not isolated to the parent task_struct, either.  The task_struct
 mm is also dereferenced.  It is pretty easy to validate a parent
 task_struct ptr (just hold tasklist_lock and run the list to check if it
 is still valid -- might not be the *right* task, but it will still be
 valid).  However, how do you validate the mm is ok?

exit_mm() cleans task-mm. _Before_ the process dies. And it should do
that, for a lot of reasons. General principle: if you are doing
garbage-collection upon removal of the last reference - _remove_
that reference. Before you call destructor. Anything else is simply
asking for races.

Besides, all the exit_foo() can be done by a very alive kernel threads.
Suppose that exit_mm() didn't clean -mm.  Well, here comes losetup(8).
It binds loop device to a file and starts a thread for handling requests.
Said thread is created by kernel_thread(9). Which is a wrapper for clone(2).
So far, so good, but that thread gets a VM of parent. I.e. losteup.
That is _not_ good. For one thing, it means full-blown MMU switch whenever
we switch to loop_thread. And that will cost you. Since loop_thread has
no business using the userland part of MMU state it calls exit_mm(9) (it
calls daemonize(9). which, in turn, calls exit_mm(9)).

That picture is typical for kernel threads. knfsd, drivers' helper threads,
you name it. And unlike the relatively tame case of loop_thread (there
we have serialization between loop_thread and parent that will not
let parent to exit before loop_thread will do up(lo-lo_sem) which is
after the daemonize() call) in general we can very well have parent
dead and gone by the time when child calls exit_mm().

See the problem? Child is very much alive, it's the sole owner of pointer
to mm_struct and it calls exit_mm(). Leaving the pointer around is _not_
a good idea.


-
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: Possible PCI subsystem bug in 2.4

2001-05-04 Thread Eric W. Biederman

Alan Cox [EMAIL PROTECTED] writes:

  There are a couple of options here.
  1) read the MTRRs unless the BIOS is braindead it will set up that area as
 write-back.  At any rate we shouldn't ever try to allocate a pci region
 that is write-back cached.
 
 'unless the BIOS is braindead'. Right. We only got into this problem because
 the BIOS _was_ braindead.

Well I did provide a suggestion so you don't have to second guess...
Usually it's actually easier to read the memory size from the northbridge
than to parse the E820 map.

However since it is different kinds of braindamage to mess up the MTRRs,
and the E820 memory map, it is worth a shot.  Personally I think MTRRs
are much easier to get right, because you don't need to take into
account what the BIOS is going to do just where your ram is.

As for braindead BIOS's in general any comments on totally nuking
them?  

Seriously.  With the general attitude of distrusting BIOS's I have
been amazed at the number of things linux expects the BIOS to get
right.  In practice windows seem to trust the BIOS much less than
linux does.

Eric
-
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-ac4 - oops on unload cdrom module

2001-05-04 Thread Pavel Roskin

Hello!

This oops happens when I run rmmod cdrom on a 2.4.4-ac4 kernel with
CONFIG_SYSCTL enabled. It doesn't happen if CONFIG_SYSCTL is disabled.

Full .config is here:
http://www.red-bean.com/~proski/linux/config

sr_mod isn't loaded at this point. Reference to sd_mod looks weird. After
this oops the cdrom module remains in memory in the deleted state.

$ /sbin/lsmod
Module  Size  Used by
hid11760   0 (unused)
keybdev 1632   0 (unused)
mga85312   1
agpgart13136   3
mousedev3936   1 (autoclean)
input   3296   0 (autoclean) [hid keybdev mousedev]
nfsd   67504   8 (autoclean)
lockd  48752   1 (autoclean) [nfsd]
sunrpc 56800   1 (autoclean) [nfsd lockd]
3c59x  24320   1 (autoclean)
ipx14496   1 (autoclean)
ramfs   3728   1 (autoclean)
cdrom  28864   0 (deleted)

ksymoops 2.3.4 on i686 2.4.4-ac4.  Options used
 -v vmlinux (specified)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.4-ac4/ (default)
 -m System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 0008
c0118051
Oops: 
CPU:0
EIP:0010:[c0118051]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax:    ebx:    ecx: d08c9000   edx: 
esi: d08c9000   edi:    ebp: bfffe968   esp: c181bf80
ds: 0018   es: 0018   ss: 0018
Process rmmod (pid: 11303, stackpage=c181b000)
Stack: d08c9000 d08cd92f  d08cd97a  d08cf5c0 c01157eb d08c9000
   fff0 c62dc000 c0114c87 d08c9000  c181a000 bb47 0001
   c0106af7 bb47 0805eee8 0100 bb47 0001 bfffe968 0081
Call Trace: [d08c9000] [d08cd92f] [d08cd97a] [d08cf5c0] [c01157eb]
   [d08c9000] [c0114c87] [d08c9000] [c0106af7]
Code: 8b 53 08 8b 43 04 89 50 04 89 02 a1 a0 46 27 c0 50 8b 03 50

EIP; c0118051 unregister_sysctl_table+5/2c   =
Trace; d08c9000 [sd_mod]__module_using_checksums+18cb/192b
Trace; d08cd92f [cdrom]cdrom_sysctl_unregister+b/10
Trace; d08cd97a [cdrom]cdrom_exit+1a/28
Trace; d08cf5c0 [cdrom].rodata.start+1a00/1a22
Trace; c01157eb free_module+1b/a0
Trace; d08c9000 [sd_mod]__module_using_checksums+18cb/192b
Trace; c0114c87 sys_delete_module+f3/1b0
Trace; d08c9000 [sd_mod]__module_using_checksums+18cb/192b
Trace; c0106af7 system_call+33/38
Code;  c0118051 unregister_sysctl_table+5/2c
 _EIP:
Code;  c0118051 unregister_sysctl_table+5/2c   =
   0:   8b 53 08  mov0x8(%ebx),%edx   =
Code;  c0118054 unregister_sysctl_table+8/2c
   3:   8b 43 04  mov0x4(%ebx),%eax
Code;  c0118057 unregister_sysctl_table+b/2c
   6:   89 50 04  mov%edx,0x4(%eax)
Code;  c011805a unregister_sysctl_table+e/2c
   9:   89 02 mov%eax,(%edx)
Code;  c011805c unregister_sysctl_table+10/2c
   b:   a1 a0 46 27 c0mov0xc02746a0,%eax
Code;  c0118061 unregister_sysctl_table+15/2c
  10:   50push   %eax
Code;  c0118062 unregister_sysctl_table+16/2c
  11:   8b 03 mov(%ebx),%eax
Code;  c0118064 unregister_sysctl_table+18/2c
  13:   50push   %eax


-- 
Regards,
Pavel Roskin

-
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: dhcp problem with realtek 8139 clone with rh 7.1

2001-05-04 Thread Adam

Michael K. Johnson wrote:
 
 In linux-kernel, you wrote:
 I have som problem with my realtek 8139 clone. It won't work with dhcp
 against my isp. I've just installed redhat 7.1 on a i386 with to (exactly
 the same) network cards, one that should be connected to my isp, and one
 to
 the local network. My local network works fine, but when I try to start
 eth0
 (which is the card connecting to my isp) I get
 
 Determining IP configuration... Operation failed.
failed.
 
 If I manually try to run 'pump -i eth0' I also get Operation failed.
 
 This sounds more like pump failing to negotiate dhcp properly than
 like a failure in the driver.  Let's check that possibility first
 before assuming a driver bug.
 
 Install dhcpcd, chmod a-x /sbin/pump, and see if it works better
 (if pump is not there or not executable, the scripts fall back to
 dhcpcd).  If so, please file a bug report against pump in buzilla
 http://bugzilla.redhat.com/bugzilla/
 
 michaelkjohnson
 
  He that composes himself is wiser than he that composes a book.
  Linux Application Development -- Ben Franklin
  http://people.redhat.com/johnsonm/lad/
 -
 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/

I've had the same problem with the 8139too drivers and DHCP.  The reason
I figure it must be the drivers is because in the 2.4.3 kernel, I'm able
to use the 8139too drivers with DHCP without any problems.  In 2.4.4 it
locks my system.

-- 
Adam
[EMAIL PROTECTED]
Linux user #190288
-
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: dhcp problem with realtek 8139 clone with rh 7.1

2001-05-04 Thread Enrico Scholz

Michael K. Johnson [EMAIL PROTECTED] writes:

 I have som problem with my realtek 8139 clone. It won't work with
 dhcp against my isp. [...]
  
 Determining IP configuration... Operation failed. 
 
 This sounds more like pump failing to negotiate dhcp properly than
 like a failure in the driver. Let's check that possibility first
 before assuming a driver bug.

It happens here also, but it does not seem to be a pump issue:

- I am using dhcpcd  ;)

- DHCP with 2.4.3 works fine

- The packages sent by the DHCP-server are having the correct destination
  MAC, but 'tcpdump' on the RTL8139 machine does not see them unless the
  promiscous mode ist enabled. When putting the NIC into promiscous mode,
  DHCP works fine[1].

- After the DHCP info are fetched and the IP is set, the promiscous mode
  can be turned off.

- When setting the IP statically things are working without turning on
  promiscous mode





Enrico
-
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 alpha semaphores optimization

2001-05-04 Thread Ivan Kokshaysky

On Fri, May 04, 2001 at 10:22:53AM +0100, David Howells wrote:
 I don't know whether it will (a) compile, or (b) work... I don't have an alpha
 to play with.

Neither (a) nor (b) ;-)  Corrected asm-alpha/rwsem.h attached.
Also small fix for lib/rwsem.c -- RWSEM_WAITING_BIAS-RWSEM_ACTIVE_BIAS
won't fit in the __s32 if counters are 64-bit.

--- linux/lib/rwsem.c.orig  Sat Apr 28 00:58:28 2001
+++ linux/lib/rwsem.c   Fri May  4 17:38:06 2001
@@ -112,7 +112,7 @@ static inline struct rw_semaphore *__rws
  */
 static inline struct rw_semaphore *rwsem_down_failed_common(struct rw_semaphore *sem,
 struct rwsem_waiter 
*waiter,
-__s32 adjustment)
+signed long 
+adjustment)
 {
struct task_struct *tsk = current;
signed long count;

Ivan.



#ifndef _ALPHA_RWSEM_H
#define _ALPHA_RWSEM_H

/*
 * Written by Ivan Kokshaysky [EMAIL PROTECTED], 2001.
 * Based on asm-alpha/semaphore.h and asm-i386/rwsem.h
 */

#ifndef _LINUX_RWSEM_H
#error please dont include asm/rwsem.h directly, use linux/rwsem.h instead
#endif

#ifdef __KERNEL__

#include linux/list.h
#include linux/spinlock.h

struct rwsem_waiter;

extern struct rw_semaphore *rwsem_down_read_failed(struct rw_semaphore *sem);
extern struct rw_semaphore *rwsem_down_write_failed(struct rw_semaphore *sem);
extern struct rw_semaphore *rwsem_wake(struct rw_semaphore *);

/*
 * the semaphore definition
 */
struct rw_semaphore {
longcount;
#define RWSEM_UNLOCKED_VALUE0xL
#define RWSEM_ACTIVE_BIAS   0x0001L
#define RWSEM_ACTIVE_MASK   0xL
#define RWSEM_WAITING_BIAS  (-0x0001L)
#define RWSEM_ACTIVE_READ_BIAS  RWSEM_ACTIVE_BIAS
#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
spinlock_t  wait_lock;
struct list_headwait_list;
#if RWSEM_DEBUG
int debug;
#endif
};

#if RWSEM_DEBUG
#define __RWSEM_DEBUG_INIT  , 0
#else
#define __RWSEM_DEBUG_INIT  /* */
#endif

#define __RWSEM_INITIALIZER(name) \
{ RWSEM_UNLOCKED_VALUE, SPIN_LOCK_UNLOCKED, \
LIST_HEAD_INIT((name).wait_list) __RWSEM_DEBUG_INIT }

#define DECLARE_RWSEM(name) \
struct rw_semaphore name = __RWSEM_INITIALIZER(name)

static inline void init_rwsem(struct rw_semaphore *sem)
{
sem-count = RWSEM_UNLOCKED_VALUE;
spin_lock_init(sem-wait_lock);
INIT_LIST_HEAD(sem-wait_list);
#if RWSEM_DEBUG
sem-debug = 0;
#endif
}

static inline void __down_read(struct rw_semaphore *sem)
{
long oldcount, temp;
__asm__ __volatile__(
1: ldq_l   %0,%1\n
   addq%0,%3,%2\n
   stq_c   %2,%1\n
   beq %2,2f\n
#ifdef CONFIG_SMP
   mb\n
#endif
.subsection 2\n
2: br  1b\n
.previous
:=r (oldcount), =m (sem-count), =r (temp)
:Ir (RWSEM_ACTIVE_READ_BIAS), m (sem-count) : memory);

if (oldcount  0)
rwsem_down_read_failed(sem);
}

static inline void __down_write(struct rw_semaphore *sem)
{
long granted, temp;
__asm__ __volatile__(
1: ldq_l   %0,%1\n
   addq%0,%3,%2\n
   stq_c   %2,%1\n
   beq %2,2f\n
#ifdef CONFIG_SMP
   mb\n
#endif
   cmpeq   %0,0,%0\n
.subsection 2\n
2: br  1b\n
.previous
:=r (granted), =m (sem-count), =r (temp)
:Ir (RWSEM_ACTIVE_WRITE_BIAS), m (sem-count) : memory);

if (!granted)
rwsem_down_write_failed(sem);
}

static inline void __up_read(struct rw_semaphore *sem)
{
long oldcount, temp;
__asm__ __volatile__(
#ifdef CONFIG_SMP
   mb\n
#endif
1: ldq_l   %0,%1\n
   subq%0,%3,%2\n
   stq_c   %2,%1\n
   beq %2,2f\n
.subsection 2\n
2: br  1b\n
.previous
:=r (oldcount), =m (sem-count), =r (temp)
:Ir (RWSEM_ACTIVE_READ_BIAS), m (sem-count) : memory);

if (oldcount  0)
if ((oldcount  RWSEM_ACTIVE_MASK) == 0)
rwsem_wake(sem);
}

static inline void __up_write(struct rw_semaphore *sem)
{
long count, cmp;
__asm__ __volatile__(
#ifdef CONFIG_SMP
   mb\n
#endif
1: ldq_l   %0,%1\n
   subq%0,%3,%2\n
   stq_c   %2,%1\n
   beq %2,2f\n
   cmpeq   %0,%3,%2\n
.subsection 2\n
2: br  1b\n
.previous
:=r (count), =m (sem-count), =r (cmp)
:Ir (RWSEM_ACTIVE_WRITE_BIAS), m (sem-count) : memory);

if (!cmp)
if 

Re: Athlon/VIA Kernel Experimentation (mmx.c)

2001-05-04 Thread Seth Goldberg


 Doh. I feel like a moron.  Thanks.. will do...

 --S


Brian Gerst wrote:
 
 Seth Goldberg wrote:
 
  Hi,
 
I implemented a small check loop at the end of the fast_page_copy
  routine in mmx.c for the Athlon.  Booting the resulting kernel
  yields an interesting result. Every single time, the kernel
  panics RIGHT AFTER it frees unused kernel memory from bootup.
  I encourage those of you with the same problem to try this and report
  when it panics.
 
  Here is my patch to mmx.c: (sorry about the long lines)
  -cut here
  diff -r linux-ref/arch/i386/lib/mmx.c linux/arch/i386/lib/mmx.c
  204a205,216
  
 {
 register int x = 0;
 /* do mem compares to ensure written == read */
 for ( /* initted above */; x  (4096/sizeof(int)); x++ )
 {
 if ( ((int *)to)[x] != ((int *)from)[x] ) {
 panic(fast_page_copy: dest value @ 0x%lx (%x) 
does not equal source value @ %lx (%x)!\n,
 (long) to, ((int *)to)[x], (long) 
from, ((int *) from)[x] );
 }
 }
 }
  -cut here
 
Wouldn't it be correct to say that because it is panicking, the
  page copy was not completed properly?
 
 No, you are comparing the following two pages... from and to are
 incremented as the copy proceeds.  Subtract PAGE_SIZE from them before
 comparing.
 
 --
 
 Brian Gerst
-
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: Possible PCI subsystem bug in 2.4

2001-05-04 Thread Alan Cox

 Seriously.  With the general attitude of distrusting BIOS's I have
 been amazed at the number of things linux expects the BIOS to get
 right.  In practice windows seem to trust the BIOS much less than
 linux does.

It becomes more and more obvious over time exactly why. One problem however
is that windows gets away with this because many vendors ship random extra
gunge for their box with the system. We dont yet have that power

Alan

-
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: dhcp problem with realtek 8139 clone with rh 7.1

2001-05-04 Thread Alan Cox

 I've had the same problem with the 8139too drivers and DHCP.  The reason
 I figure it must be the drivers is because in the 2.4.3 kernel, I'm able
 to use the 8139too drivers with DHCP without any problems.  In 2.4.4 it
 locks my system.

Multiple such reports - seems the 8139too update broke stuf - any ideas Jeff,
should I revert to the 2.4.3 one ?
-
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 alpha semaphores optimization

2001-05-04 Thread Ivan Kokshaysky

On Fri, May 04, 2001 at 04:33:59PM +0200, Andrea Arcangeli wrote:
 the 2^16 limit is not a per-user limit it is a global one so the max
 user process ulimit is irrelevant.
 
 Only the number of pid and the max number of tasks supported by the
 architecture is a relevant limit for this.

Thanks for the correction. I thought about a case where one user could
exhaust 2^16 limit.

  b. long count would cost extra 8 bytes in the struct rw_semaphore;
 
 correct but that's the feature to be able to support 2^32 concurrent
 sleepers at not relevant runtime cost 8).

But I can't imagine how this feature could be useful in a real life :-)

  c. I can use existing atomic routines which deal with ints.
 
 I was thinking at a dedicated routine that implements the slow path by
 hand as well like x86 just do. Then using ldq instead of ldl isn't
 really a big deal programmer wise.

You meant the fast path, I guess? Then it's true. However with those
atomic functions code is much more readable.

Anyway, I've attached asm-alpha/rwsem_xchgadd.h for your implementation.
However I got processes in D state early on boot with it -- maybe
I've made a typo somewhere...

Ivan.



#ifndef _ALPHA_RWSEM_XCHGADD_H
#define _ALPHA_RWSEM_XCHGADD_H

#include asm/types.h  /* BITS_PER_LONG */

static inline void __down_read(struct rw_semaphore *sem)
{
long count, temp;
__asm__ __volatile__(
1: ldq_l   %0,%1\n
   addq%0,1,%2\n
   stq_c   %2,%1\n
   beq %2,2f\n
#ifdef CONFIG_SMP
   mb\n
#endif
.subsection 2\n
2: br  1b\n
.previous
:=r (count), =m (sem-count), =r (temp)
:m (sem-count) : memory);

if (count  0)
rwsem_down_failed(sem, RWSEM_READ_BLOCKING_BIAS);
}

static inline void __down_write(struct rw_semaphore *sem)
{
long granted, temp = RWSEM_WRITE_BIAS + RWSEM_READ_BIAS;
__asm__ __volatile__(
1: ldq_l   %0,%1\n
   addq%0,%2,%2\n
   stq_c   %2,%1\n
   beq %2,2f\n
#ifdef CONFIG_SMP
   mb\n
#endif
   cmpeq   %0,0,%0\n
.subsection 2\n
2: br  1b\n
.previous
:=r (granted), =m (sem-count), =r (temp)
:2 (temp),m (sem-count) : memory);

if (!granted)
rwsem_down_failed(sem, RWSEM_WRITE_BLOCKING_BIAS);
}


static inline void __up_read(struct rw_semaphore *sem)
{
long oldcount, temp;
__asm__ __volatile__(
#ifdef CONFIG_SMP
   mb\n
#endif
1: ldq_l   %0,%1\n
   subq%0,1,%2\n
   stq_c   %2,%1\n
   beq %2,2f\n
   subl%0,1,%2\n
.subsection 2\n
2: br  1b\n
.previous
:=r (oldcount), =m (sem-count), =r (temp)
:m (sem-count) : memory);

if (oldcount  0  temp == 0)
rwsem_wake(sem);
}

static inline void __up_write(struct rw_semaphore *sem)
{
long count, temp = RWSEM_READ_BIAS + RWSEM_WRITE_BIAS;
__asm__ __volatile__(
#ifdef CONFIG_SMP
   mb\n
#endif
1: ldq_l   %0,%1\n
   subq%0,%2,%2\n
   mov %2,%0\n
   stq_c   %2,%1\n
   beq %2,2f\n
.subsection 2\n
2: br  1b\n
.previous
:=r (count), =m (sem-count), =r (temp)
:2 (temp), m (sem-count) : memory);

if (count  0)
rwsem_wake(sem);
}

static inline long rwsem_xchgadd(long value, long * count)
{
long ret, temp;
__asm__ __volatile__(
1: ldq_l   %0,%1\n
   addq%0,%3,%2\n
   stq_c   %2,%1\n
   beq %2,2f\n
.subsection 2\n
2: br  1b\n
.previous
:=r (ret), =m (count), =r (temp)
:Ir (value), m (count) : memory);

return ret;
}

#endif



Re: [patch] 2.4.4 alpha semaphores optimization

2001-05-04 Thread Andrea Arcangeli

On Fri, May 04, 2001 at 09:02:33PM +0400, Ivan Kokshaysky wrote:
 But I can't imagine how this feature could be useful in a real life :-)

It will be required by the time we can fork more than 2^16 tasks (which
I'm wondering if it could be just the case if you use CLONE_PID as
root, I didn't checked the code yet to be sure).

 You meant the fast path, I guess? Then it's true. However with those

Yes, I guess the slow path is quite painful to maintain, however I'd add
at least the __builtin_expect() so it gets optimized by 2.96 and 3.[01].

 atomic functions code is much more readable.

Your attached code is nice enough IMHO ;).

 Anyway, I've attached asm-alpha/rwsem_xchgadd.h for your implementation.

Sweet, thanks.

 However I got processes in D state early on boot with it -- maybe
 I've made a typo somewhere...

It has to be a bug in a non contention case then, or maybe you run some
threaded app during boot?  Note that my version is a bit different than
David's one, my fast path has less requirements in up_write and so it
can be implemented with less instructions. I will check and integrate
your code soon into my patch, thanks. If you find the bug meanwhile let
me know (to beat it hard you can use my userspace threaded app that
faults and mmap/munmap in loop from dozen of threads).

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: dhcp problem with realtek 8139 clone with rh 7.1

2001-05-04 Thread Jeff Garzik

Alan Cox wrote:
 
  I've had the same problem with the 8139too drivers and DHCP.  The reason
  I figure it must be the drivers is because in the 2.4.3 kernel, I'm able
  to use the 8139too drivers with DHCP without any problems.  In 2.4.4 it
  locks my system.
 
 Multiple such reports - seems the 8139too update broke stuf - any ideas Jeff,
 should I revert to the 2.4.3 one ?

I would say if Monday comes by without hearing from me, yes. It fixes
some people, breaks others :/

I've already got a fix on the dhcp breakage -- need to lock and unlock
EEprom before setting certain registers, and I am working on the other
problem (symptom: 'partner ability ' even when a link is present).

-- 
Jeff Garzik  | Game called on account of naked chick
Building 1024|
MandrakeSoft |
-
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/



REVISED: Experimentation with Athlon and fast_page_copy

2001-05-04 Thread Seth Goldberg

Hi,
 
 After removing my head from my a**, I revised the code that checks
the memory copy in the fast_page_copy routine.  The machine then
proceeded
not to stop at my panic, but I got my normal oopses.  I then had an
idea and removed all the prefetch instructions from the beginning of the
routine and tried the resultin kernel.  I now have no crashes.
What could this mean?

Here is a nother patch just so you can keep me honest if I
made another mistake:

-
diff -r ./arch/i386/lib/mmx.c ../lin2/linux/arch/i386/lib/mmx.c
149,150c149

 /*__asm__ __volatile__ (
---
   __asm__ __volatile__ (
158c157
   3: movw $0x1AEB, 1b\n
---
   3: movw $0x1AEB, 1b\n /* jmp on 26 bytes */
166c165
 */
---

170c169
   1: nop\n /* prefetch 320(%0)\n */
---
   1: prefetch 320(%0)\n 
-

  Please let me know if that makes sense :).

  Thank you,
   Seth
-
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] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Linus Torvalds


On Fri, 4 May 2001, Rogier Wolff wrote:

 Linus Torvalds wrote:
  
  Ehh. Doing that would be extremely stupid, and would slow down your boot
  and nothing more.
 
 Ehhh, Linus, Linearly reading my harddisk goes at 26Mb per second.

You obviously didn't read my explanation of _why_ it is stupid.

 By analyzing my boot process I determine that 50M of my disk is used
 during boot. I can then reshuffle my disk to have that 50M of data at
 the beginning and reading all that into 50M of cache, I can save
 thousands of 10ms seeks.

No. Have you _tried_ this?

What the above would do is to move 50M of the disk into the buffer cache.

Then, a second later, when the boot proceeds, Linux would start filling
the page cache.

BY READING THE CONTENTS FROM DISK AGAIN!

In short, by doing a dd from the disk, you would _not_ help anything at
all. You would only make things slower, by reading things twice.

The Linux buffer cache and page cache are two separate entities. They are
not synchronized, and they are indexed through totally different
means. The page cache is virtually indexed by inode,pagenr, while
the
buffer cache is indexed by dev,blocknr,blocksize. 

 Is this simply: Don't try this then? 

Try it. You will see. 

You _can_ actually try to optimize certain things with 2.4.x: all
meta-data is still in the buffer cache in 2.4.x, so what you could do is
to lay out the image so that the metadata is at the front of the disk,
and do the dd to cache just the metadata. Even then you need to be
careful, and make sure that the dd uses the same block size as the
filesystem will use.

And even that will largely stop working very early in 2.5.x when the
directory contents and possibly inode and bitmap metadata moves into the
page cache.

Now, you may ask why use the page cache at all then? The answer is that
the page cache is a _lot_ faster to look up, exactly because of the
virtual indexing (and also because the data structure is much better
designed - fixed-size entities with none of the complexities of the buffer
cache. The buffer cache needs to be able to do IO, while the page cache is
_only_ a cache and does that one thing really well - doing IO is a
completely separate issue with the page cache).

Now, if you want to speed up accesses, there are things you can do. You
can lay out the filesystem in the access order - trace the IO accesses at
bootup (which file, which offset, which metadata block?) and lay out the
blocks of the files in exactly the right order. Then you will get linear
reads _without_ doing any dd at all.

Now, laying out the filesystem that way is _hard_. No question about it.
It's kind of equivalent to doing a filesystem defreagment operation,
except you use a different sorting function (instead of sorting blocks
linearly within each file, you sort according to access order).

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/



Re: X15 alpha release: as fast as TUX but in user space (fwd)

2001-05-04 Thread dean gaudet

um, presumably this new magic page won't eliminate the old syscall entry
points.  so just use those for UML.

-dean

On Fri, 4 May 2001, Pavel Machek wrote:

 Hi!

That means that for fooling closed-source statically-linked binary,
  
   If they are using glibc then you have the right to the object to link
   with the library and the library source under the LGPL. I dont know of any
   app using its own C lib
 
  Some don't use any libc at all, some just don't use it for the time call
  that were talking about substituting.
 
  Lying about the time is a hack, pure and simple. It will still be possible
  with magic pages. The fact that it will require more kernel hacking to
  accomplish it is irrelevant.

 No. You are breaking self-virtualization here. That is not irrelevant.

 It used to require no kernel support before. Now it will require
 kernel support. That's step back. (Think uml).

   Pavel
 --
 I'm [EMAIL PROTECTED] In my country we have almost anarchy and I don't care.
 Panos Katsaloulis describing me w.r.t. patents at [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/


-
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: smp_send_stop() and disable_local_APIC()

2001-05-04 Thread Matt D. Robinson

Eric W. Biederman wrote:
 
 Matt D. Robinson [EMAIL PROTECTED] writes:
 
  It looks like around 2.3.30 or so, someone added the call
  disable_local_APIC() to smp_send_stop().  I'm not sure what the
  intention was, but I'm getting some strange behavior as a result
  based on some code I'm writing.
 
  Basically, I'm doing the following ...
 
  panic()
  {
  /* do whatever you want, notifier list, etc. */
  smp_send_stop();
  write_system_memory();
  /* then do whatever */
  }
 
  write_system_memory() does a write of all system memory pages to some
  block device.  It uses kiobufs as the way to get the pages to disk,
  doing brw_kiovec() on those pages (using either the IDE or SCSI
  driver to write the data).
 
 IDE being less likely to hang than SCSI as it tends to use legacy isa
 interrupt lines.

Actually, we see the problem more with IDE than SCSI, but that's
neither here nor there.

  The wierd behavior I see is that sometimes, smp_send_stop()
  being called causes the system to hang up (not every time).
 
 Doing event driver i/o after disabling the interrupt controller
 hmm, I wonder why...

It's an SMP (and only when your system crashes on a CPU other
than 0) problem.  I did some more checking of this to verify the
specifics of the behavior.  Thanks for the sarcasm, though. :)

  If we don't call smp_send_stop() on those systems, everything works fine.
  This looks to be directly caused by the disabling of the APIC, which
  we may need to dump pages to local disk.  This only applies to some
  people's systems -- not everyone displays the same behavior.
 
  I'm sure it's good to disable the APIC, but there's no clean way to
  wait on disabling the APIC until after I'm done writing pages out.
 
  My questions are:
 
  1) Why was disable_local_APIC() added to stop_this_cpu()
 and smp_send_stop()?  Completeness?
 
  2) Is there a better way around this to disable all the
 other CPUs without disabling the APIC?
 
 
 I don't know what a good way is, since there is a kernel panic it
 should only be something truly fatal.  Given that reusing anything
 that hasn't been designed to run in that situation is playing with
 fire.

Someone's sent me a suggestion as to how to get around this issue.
It goes back to turning off the disable_local_APIC() behavior for
one (if I'm writing pages out), but secondly to avoid doing any
TLB flushing of CPUs that are stopped.

The problem is, on SMP configurations where one CPU's
task causes a panic() condition to another CPU's task (let's say
they are playing with the same list of structures in the kernel),
I need to stop all CPUs except the one panic()ing, and let him
be responsible for dumping system memory, so I can at least try
to figure out what the other CPU's task did to cause the problem.

A hack way around this is to stop job scheduling, but it doesn't
help if you want to catch the state of the task that caused the
problem on another CPU just after it happens.  Secondly, because there
is no disk driver to dump raw to disk (I've written one, but
not for SCSI -- only for IDE), you require interrupts and must
use the current block driver.  Sure, brw_kiovec() is nice, but it
isn't raw I/O without kernel interrupts.

All I wanted was clarification as to why it was added in the first
place, and whether there was a better way around the scenario.
I think Ingo added the code, but I never heard back from him.
Thanks for the response.

 Eric

--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: [PATCH] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Linus Torvalds


On Fri, 4 May 2001, Andrea Arcangeli wrote:

 On Fri, May 04, 2001 at 01:56:14PM +0200, Jens Axboe wrote:
  Or you can rewrite block_read/write to use the page cache, in which case
  you'd have more luck doing the above.
 
 once block_dev is in pagecache there will obviously be no-way to share
 cache between the block device and the filesystem, because all the
 caches will be in completly different address spaces.

They already pretty much are.

I do want to re-write block_read/write to use the page cache, but not
because it would impact anything in this discussion. I want to do it early
in 2.5.x, because:

 - it will speed up accesses
 - it will re-use existing code better and conceptualize things more
   cleanly (ie it would turn a disk into a _really_ simple filesystem with
   just one big file ;).
 - it will make MM handling much better for things like fsck - the memory
   pressure is designed to work on page cache things.
 - it will be one less thing that uses the buffer cache as a cache (I
   want people to think of, and use, the buffer cache as an _IO_ entity,
   not a cache).

It will not make the cache at bootup thing change at all (because even
in the page cache, there is no commonality between a virtual mapping of a
_file_ (or metadata) and a virtual mapping of a _disk_). 

It would have hidden the problem with dd or dump touching buffer cache
blocks that the filesystem was using, so the original metadata corruption
that started this thread would not happen. But that's not a design issue
or a design goal, that would just have been a random result.

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/



Re: [PATCH] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Alexander Viro



On Fri, 4 May 2001, Linus Torvalds wrote:

 Now, if you want to speed up accesses, there are things you can do. You
 can lay out the filesystem in the access order - trace the IO accesses at
 bootup (which file, which offset, which metadata block?) and lay out the
 blocks of the files in exactly the right order. Then you will get linear
 reads _without_ doing any dd at all.
 
 Now, laying out the filesystem that way is _hard_. No question about it.
 It's kind of equivalent to doing a filesystem defreagment operation,
 except you use a different sorting function (instead of sorting blocks
 linearly within each file, you sort according to access order).

Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
* add pagecache access for block device
* put your real root on /dev/loop0 (setup from initrd)
* dd
The last step will populate pagecache for underlying device and later
access to root fs will ultimately hit said pagecache, be it from page
cache of files or buffer cache of /dev/loop0 - loop_make_request() will
take care of that, by copying data from pagecache of /dev/real_device.

Al, feeling sadistic today...

-
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: Possible PCI subsystem bug in 2.4

2001-05-04 Thread Linus Torvalds


On 4 May 2001, Eric W. Biederman wrote:
 
 There are a couple of options here.
 1) read the MTRRs unless the BIOS is braindead it will set up that area as
write-back.  At any rate we shouldn't ever try to allocate a pci region
that is write-back cached.

This one I'd really hesitate to use. We do _not_ want to trust the BIOS
any more than necessary (obviously trusting even the e820 was too much),
and especially wrt MTRR's we know that there are too many buggy bioses
already out there.

 2) read the memory locations from the northbridge.  It's not possible
on every chipset (lack of documentation) but with the linuxBIOS
project we code for a couple of them, and we are working on more
all of the time.

This will be easy.

In fact, we can easily mix different heuristics. Ie we'd do the simple
thing I suggested in setup_arch(), and use that as a base guess, and
then we can have incremental improvements on that guess that might be
chipset-specific or might depend on other information that is not
necessarily generic (things like existing PCI programming etc).

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/



[PATCH][RFC] Re: SMP races in proc with thread_struct

2001-05-04 Thread Alexander Viro

Linus, could you consider the patch below? As it is, access to
/proc/pid/status of dead process with dead parent is possible and
leads to access to freed memory. Besides, cd /proc/pid means
that even after pid is gone, readdir() _and_ lookup on /proc/pid work.
Patch makes sure that -p_pptr is NULL once the process is gone (fixes
readdir/lookup stuff) and adds obvious couple of checks in array.c.
Al

diff -urN S5-pre1/fs/proc/array.c S5-pre1-p_pptr/fs/proc/array.c
--- S5-pre1/fs/proc/array.c Sat Apr 28 02:12:56 2001
+++ S5-pre1-p_pptr/fs/proc/array.c  Fri May  4 13:15:47 2001
@@ -157,7 +157,9 @@
Uid:\t%d\t%d\t%d\t%d\n
Gid:\t%d\t%d\t%d\t%d\n,
get_task_state(p),
-   p-pid, p-p_opptr-pid, p-p_pptr-pid != p-p_opptr-pid ? 
p-p_pptr-pid : 0,
+   p-pid, p-p_opptr-pid,
+   p-p_pptr  p-p_pptr-pid != p-p_opptr-pid
+   ? p-p_pptr-pid : 0,
p-uid, p-euid, p-suid, p-fsuid,
p-gid, p-egid, p-sgid, p-fsgid);
read_unlock(tasklist_lock);
@@ -339,7 +341,7 @@
nice = task-nice;
 
read_lock(tasklist_lock);
-   ppid = task-p_opptr-pid;
+   ppid = task-p_pptr ? task-p_opptr-pid : 0;
read_unlock(tasklist_lock);
res = sprintf(buffer,%d (%s) %c %d %d %d %d %d %lu %lu \
 %lu %lu %lu %lu %lu %ld %ld %ld %ld %ld %ld %lu %lu %ld %lu %lu %lu %lu %lu \
diff -urN S5-pre1/kernel/exit.c S5-pre1-p_pptr/kernel/exit.c
--- S5-pre1/kernel/exit.c   Fri Feb 16 22:52:15 2001
+++ S5-pre1-p_pptr/kernel/exit.cFri May  4 13:18:33 2001
@@ -62,6 +62,9 @@
current-counter += p-counter;
if (current-counter = MAX_COUNTER)
current-counter = MAX_COUNTER;
+   write_lock_irq(tasklist_lock);
+   p-p_pptr = NULL;
+   write_unlock_irq(tasklist_lock);
free_task_struct(p);
} else {
printk(task releasing itself\n);


-
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] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Linus Torvalds


On Fri, 4 May 2001, Alexander Viro wrote:
 
 Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
   * add pagecache access for block device
   * put your real root on /dev/loop0 (setup from initrd)
   * dd

You're one sick puppy.

Now, the above is basically equivalent to using and populating a
dynamically sized ramdisk.

If you really want to go this way, I'd much rather see you using a real
ram-disk (that you populate at startup with something like a compressed
tar-file). THAT is definitly going to speed up booting - thanks to
compression you'll not only get linear reads, but you will get fewer reads
than the amount of data you need would imply.

Couple that with tmpfs, or possibly something like coda (to dynamically
move things between the ramdisk and the backing store filesystem), and
you can get a ramdisk approach that actually shrinks (and, in the case of
coda or whatever, truly grows) dynamically.

Think of it as an exercise in multi-level filesystems and filesystem
management. Others have done it before (usually between disk and tape, or
disk and network), and in these days of ever-growing memory it might just
make sense to do it on that level too.

(No, I don't seriously think it makes sense today. But if RAM keeps
growing and becoming ever cheaper, it might some day. At the point where
everybody has multi-gigabyte memories, and don't really need it for
anything but caching, you could think of it as just moving the caching to
a higher level - you don't cache blocks, you cache parts of the
filesystem).

   Al, feeling sadistic today...

Sadistic you are.

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/



Re: X15 alpha release

2001-05-04 Thread Fabio Riccardi

Ingo,

I'm really impressed by your feedback! How do you manage to discover so many
things?

I fixed the bug, and checked that it hadn't affected my specweb results.

Indeed specweb never issues closing 1.1 connections, it would use a 1.0
request with close in that case.

Moreover even if a client says that it will close the connection and the
server instead leaves it open, the client would just close the connection
anyway, unless there is a (very contrived) bug in the client which would let
itself be diverted from its original intention by an overly talkative
server...

X15 would be indeed negatively affected by these useless idle open
connections cluttering the file descriptor table and consuming resources for
nothing.

I'll post the corrected version later on today.

BTW: is there any _concise_ document specifying the HTTP protocol and its
variants?

 - Fabio

Ingo Molnar wrote:

 Fabio,

 i noticed another RFC anomaly in X15. It ignores the Connection: close
 request header passed by a HTTP/1.1 client. This behavior is against RFC
 2616, a server must not override the client's choice of non-persistent
 connection. (there might be HTTP/1.1 clients that do not support
 persistent connections and signal this via Connection: close.)

 the rule is this: a request is either keepalive or non-keepalive. HTTP/1.0
 requests default to non-keepalive. HTTP/1.1 requests default to keepalive.
 The default can be overriden via the Connection: Keep-Alive or
 Connection: close header fields.

 if you fix this, does it impact SPECweb99 performance in any way?

 Ingo

 -
 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: X15 alpha release: as fast as TUX but in user space

2001-05-04 Thread Fabio Riccardi

ok, I'm totally ignorant here, what is a pipelined request?

btw: please be kind with my mistakes, X15 _is_ alpha code anyway... :)

 - Fabio

Ingo Molnar wrote:

 yet another anomaly i noticed. X15 does not appear to handle pipelined
 HTTP/1.1 requests properly, it ignores the second request if two requests
 arrive in the same packet.

 SPECweb99 does not send pipelined requests, but a number of RL web clients
 do. (Mozilla, apt-get, etc.)

 Ingo

-
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: modularized SYSENTER support

2001-05-04 Thread Manfred Spraul

 Q. How come the handler doesn't manage so called bottom halves or 
soft IRQs? 
 A. There is no need for this. Soft IRQs can only appear at exit from 
hardware interrupt handlers. Indeed, we can't count on user app. 
being around and performing a system call when it comes to 
interrupt handling, right? 

That's probably a bug.
syscall
* spin_lock_bh()
* hardware interrupt arrives
* BH's are blocked, delayed
* spin_unlock_bh()
* return from syscall.

You must check for softirq's before returning.

--
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: [PATCH] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Richard Gooch

Linus Torvalds writes:
 Now, if you want to speed up accesses, there are things you can
 do. You can lay out the filesystem in the access order - trace the
 IO accesses at bootup (which file, which offset, which metadata
 block?) and lay out the blocks of the files in exactly the right
 order. Then you will get linear reads _without_ doing any dd at
 all.

A year ago I came up with an alternative approach for cache warming,
but I see that it wouldn't work with our current infrastructure.
However, maybe there is still a way to use the basic technique. If so,
please make suggestions.

The idea I had (motivated by the desire to eliminate random disc
seeks, which is the limiting factor in how fast my boxes boot) was:

- init(8) issues an ioctl(2) on the root FS block device which turns
  on recording of block reads (it records block numbers)

- at the end of the bootup process, init(8) issues another ioctl(2) to
  grab the buffered block numbers, and turn off recording

- init(8) then sorts this list in ascending order and saves the result
  in a file

- next boot, init(8) checks the file, and if it exists, opens the root
  FS block device and reads in each block listed in the file. The
  effect is to warm the buffer cache extremely quickly. The head will
  move in one direction, grabbing data as it flys by. I expect this
  will take around 1 second

- init(8) now continues the boot process (starting the magic ioctl(2)
  again so as to get a fresh list of blocks, in case something has
  changed)

- booting is now super fast, thanks to no disc activity.

The advantage of this scheme over blindly reading the first 50 MB is
that it only reads in what you *need*, and thus will work better on
low memory systems. It's also useful for other applications, not just
speeding up the boot process.

However, doing an ioctl(2) on the block device won't help. So the
question is, where to add the hook? One possibility is the FS, and
record inum,bnum pairs. But of course we don't have a way of accessing
via inum in user-space. So that's no good. Besides, we want to get
block numbers on the block device, because that's the only meaningful
number to resort.

So, what, then? Some kind of hook on the page cache? Ideas?

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: [PATCH] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Alexander Viro



On Fri, 4 May 2001, Linus Torvalds wrote:

 
 On Fri, 4 May 2001, Alexander Viro wrote:
  
  Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
   ^^^
  * add pagecache access for block device
  * put your real root on /dev/loop0 (setup from initrd)
  * dd
 
 You're one sick puppy.

[snip]
/me bows

Nice to see that imitation was good enough ;-) Seriously, I half-expected
Albert to show up at that point of thread and tried to anticipate what
he'd produce.

ObProcfs: I don't think that walking the page tables is a good way to
compute RSS, especially since VM maintains the thing. Mind if I rip
it out? In effect, implementation of /prc/pid/statm
* produces extremely bogus values (VMA is from library if it goes
  beyond 0x6000? Might be even true 7 years ago...) and nobody
  had cared about them for 6-7 years
* makes stuff like top(1) _walk_ _whole_ _page_ _tables_ _of_ _all_
  _processes_ each 5 seconds. No wonder it's slow like hell and eats
  tons of CPU time.

-
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: added a new feature: disable pc speaker

2001-05-04 Thread Oystein Viggen

Quoth Keith Owens: 

 Userspace problem, userspace fix.
 
   setterm -blength 0 (text)
   xset b 0 (X11)

Well, some buggy programs don't care about you turning off beeping in
X.  I think gnome-terminal or such has its own checkbox for turning
beeps on or off. 

I still agree that this is fixing userspace bugs in the kernel, and
probably not desirable, even if I think I'd disable the pc speaker if
the kernel actually asked me.  If nothing else, I figure it would make
my kernel 0.5k or so smaller  ;)

Oystein
-- 
When in doubt: Recompile.
-
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: X15 alpha release: as fast as TUX but in user space

2001-05-04 Thread Davide Libenzi


On 04-May-2001 Fabio Riccardi wrote:
 ok, I'm totally ignorant here, what is a pipelined request?



http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html

QUOTE
A pipelined application implementation buffers its output before writing it to
the underlying TCP stack, roughly equivalent to what the Nagle algorithm does
for telnet connections.
These two buffering algorithms tend to interfere, and using them together will
often cause very significant performance degradation. For each connection, the
server maintains a
response buffer that it flushes either when full, or when there is no more
requests coming in on that connection, or before it goes idle. This buffering
enables aggregating responses
(for example, cache validation responses) into fewer packets even on a
high-speed network, and saving CPU time for the server. 
/QUOTE





- Davide

-
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 for ymfpci in 2.4.4

2001-05-04 Thread Pete Zaitcev

Hello:

Here are updates from ALSA. The interrupt acknowledge has a
potential bug report for it in RH bugzilla. Power-up fix I include
just because, Alan bounced it to me from sound-hackers;
Also Jeff Garzik asked for it. I wanted to include it with
full PM support, but perhaps not.

-- Pete

--- linux-2.4.4/drivers/sound/ymfpci.c  Thu Apr 26 22:17:27 2001
+++ linux-2.4.4-niph/drivers/sound/ymfpci.c Fri May  4 11:02:56 2001
@@ -989,11 +989,6 @@
 
status = ymfpci_readl(codec, YDSXGR_STATUS);
if (status  0x8000) {
-   spin_lock(codec-reg_lock);
-   ymfpci_writel(codec, YDSXGR_STATUS, 0x8000);
-   mode = ymfpci_readl(codec, YDSXGR_MODE) | 2;
-   ymfpci_writel(codec, YDSXGR_MODE, mode);
-   spin_unlock(codec-reg_lock);
codec-active_bank = ymfpci_readl(codec, YDSXGR_CTRLSELECT)  1;
spin_lock(codec-voice_lock);
for (nvoice = 0; nvoice  64; nvoice++) {
@@ -1007,6 +1002,11 @@
ymf_cap_interrupt(codec, cap);
}
spin_unlock(codec-voice_lock);
+   spin_lock(codec-reg_lock);
+   ymfpci_writel(codec, YDSXGR_STATUS, 0x8000);
+   mode = ymfpci_readl(codec, YDSXGR_MODE) | 2;
+   ymfpci_writel(codec, YDSXGR_MODE, mode);
+   spin_unlock(codec-reg_lock);
}
 
status = ymfpci_readl(codec, YDSXGR_INTFLAG);
@@ -2106,6 +2106,8 @@
pci_write_config_byte(pci, PCIR_DSXGCTRL, cmd | 0x03);
pci_write_config_byte(pci, PCIR_DSXGCTRL, cmd  0xfc);
}
+   pci_write_config_word(pci, PCIR_DSXPWRCTRL1, 0);
+   pci_write_config_word(pci, PCIR_DSXPWRCTRL2, 0);
 }
 
 static void ymfpci_enable_dsp(ymfpci_t *codec)
-
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] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Richard Gooch

Alexander Viro writes:
 
 
 On Fri, 4 May 2001, Richard Gooch wrote:
 
  However, doing an ioctl(2) on the block device won't help. So the
  question is, where to add the hook? One possibility is the FS, and
  record inum,bnum pairs. But of course we don't have a way of accessing
  via inum in user-space. So that's no good. Besides, we want to get
  block numbers on the block device, because that's the only meaningful
  number to resort.
  
  So, what, then? Some kind of hook on the page cache? Ideas?
 
 Two of them: use less bloated shell (and link it statically) and
 clean your rc scripts.

No, because I'm not using the latest bloated version of bash, and I'm
not using the slow and bloated RedHat boot scripts. My boot scripts
are lean and mean. Oh. And I already have init(8) warming the cache
with these scripts.

The problem is all the various daemons and system utilities (mount,
hwclock, ifconfig and so on) that turn a kernel into a useful system.
And then of course there's X...

Sorry. A don't do that then answer isn't appropriate for this
problem space.

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: [PATCH] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Jens Axboe

On Fri, May 04 2001, Richard Gooch wrote:
 The idea I had (motivated by the desire to eliminate random disc
 seeks, which is the limiting factor in how fast my boxes boot) was:
 
 - init(8) issues an ioctl(2) on the root FS block device which turns
   on recording of block reads (it records block numbers)
 
 - at the end of the bootup process, init(8) issues another ioctl(2) to
   grab the buffered block numbers, and turn off recording
 
 - init(8) then sorts this list in ascending order and saves the result
   in a file
 
 - next boot, init(8) checks the file, and if it exists, opens the root
   FS block device and reads in each block listed in the file. The
   effect is to warm the buffer cache extremely quickly. The head will
   move in one direction, grabbing data as it flys by. I expect this
   will take around 1 second
 
 - init(8) now continues the boot process (starting the magic ioctl(2)
   again so as to get a fresh list of blocks, in case something has
   changed)
 
 - booting is now super fast, thanks to no disc activity.

I did 95% of what you need sometime last year, to do I/O scheduler
profiling (blocks requested, merge stats, request sent to disk). It was
a pretty gross hack, requiring a pretty big ring buffer of kernel memory
to be able to log at a sufficiently fast rate (you'd be amazed how much
output a single dbench 48 run produces :-). A user space app would read
data from a simple char device, save for later inspection.

A better approach would be to map the ring buffer from the user app, but
it was just a quick fix.

-- 
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: [PATCH] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Linus Torvalds



On Fri, 4 May 2001, Alexander Viro wrote:

 ObProcfs: I don't think that walking the page tables is a good way to
 compute RSS, especially since VM maintains the thing.

Well, the VM didn't always use to maintain the stuff it does now, so I bet
that most of the code is just old code that still works.

Feel free to rip it out.

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/



Re: REVISED: Experimentation with Athlon and fast_page_copy

2001-05-04 Thread Manfred Spraul

 ---
__asm__ __volatile__ (
 158c157
3: movw $0x1AEB, 1b\n
 ---
3: movw $0x1AEB, 1b\n /* jmp on 26 bytes */
 166c165
  */
 ---
 
 170c169
1: nop\n /* prefetch 320(%0)\n */
 ---
1: prefetch 320(%0)\n 
 -
   Please let me know if that makes sense :).

Very interesting.
You've removed only the prefetch 320(%0), not the other prefetch
instructions?

prefetch 320(%0) can fetch memory behind the end of the source page.
Perhaps it accesses memory in the ISA hole, or beyond the end of memory?
Could you post the e820 map from dmesg?

It's possible to build manually a memory map.
Could you build one with wide margins from dangerous areas? (untested:
mem=exactmap mem=620k@0 mem=your mem in MB-2M@1M)

Then boot with prefetch enabled.
--
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: Maximum files per Directory

2001-05-04 Thread Andreas Dilger

Chris writes:
 On Tuesday, May 01, 2001 04:57:02 PM -0600 Andreas Dilger
 [EMAIL PROTECTED] wrote:
  I see that reiserfs plays some tricks with the directory i_nlink count.
  If you exceed 64536 links in a directory, it reverts to 1 and no longer
  tracks the link count.
 
 Correct.  The link count isn't used at all when deciding if the directory
 is empty (we use the size instead), so we can just lie to VFS if someone
 tries to make tons of subdirs.

For that matter, ext2 doesn't use the link count on directories to determine
if they are empty either, so it shouldn't be too hard to do the same with
the ext2 indexed-directory code.  Is there a reason that reiserfs chose to
have large number of directories represented by 1 and not LINK_MAX+1?

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: [PATCH] SMP race in ext2 - metadata corruption.

2001-05-04 Thread Alexander Viro



On Fri, 4 May 2001, Richard Gooch wrote:

  Two of them: use less bloated shell (and link it statically) and
  clean your rc scripts.
 
 No, because I'm not using the latest bloated version of bash, and I'm

Umm... Last version of bash I could call not bloated was _long_ time
ago. Something like ash(1) might be a better idea for /bin/sh.

 The problem is all the various daemons and system utilities (mount,
 hwclock, ifconfig and so on) that turn a kernel into a useful system.
 And then of course there's X...

How do you partition the thing? I.e. what's the size of your root partition?
I'm usually doing something from 10Mb to 30Mb - that may be the reason of
differences.

-
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: DPT I2O RAID and Linux I2O

2001-05-04 Thread Patrick Allaire

 Ok thats nothing to do with I2O itself. Some hardware has the messaging
 layer built into it as the messenger is very simple and stuff
 like the 21554
 are using in I2O controllers.

 You might find i2o_pci.c and the i2o_core message passing code interesting
 but probably not that much. The I2O 1.5 specification covers the hardware
 interface briefly and that bit is worth reading. Ignore the rest.

Hi, its me again (c:

First of all, is it supposed to be working with 2.2.19 or should I take a
new 2.4.4-ac kernel for that support ?

Ok, i allready did look at those files (i2o_pci.c i2o_core), but I cant find
were to begin. I was doing i2o_install_controler, and after that i was
trying to do a i2o_pci_enable or i2o_pci_bind,because they are the only
fonction that seem to bind i2o with a pci_dev, but I get unresolved error
with those functions ... if I do a cat /proc/ksyms I dont see them listed
there. After that when I do i2o_delete_control, I receive a segmentation
fault !!! (Those test are done in 2.2.19)

I have built my kernel with i2o support and i2o_pci support !!!

As for the spec, I have the i2o spec 2.0 here. Is it supported ?

When I look at the source from the i2o driver, i find that my module will
have to primary create an handler to respond to the messages, but does the
configuration of the i2o should be done by my module or it is gonna be done
by the functions I cant use right now ? (i2o_pci_enable...)

Thank you very much !!!

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



  1   2   >