2.4.3 aic7xxx nevermind

[George Bonser]

I grabbed a complete 2.4.3 tarball and that seems to have fixed the problem.
Something must have gotten borked in the patching process somewhere.

And the sad part is that I know to do that before posting ... :-(




-
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] New video4linux device driver announcement.

[Jakob Kemi]

Hi.

Ok, don't fry me. I'm not sure if this mail reached you some days ago, coz' I wasn't 
subscribing
to the list back then. I've encountered mailproblems lately with my ISP so I don't 
trust that my mail
gets through until I actually see them on the list.

I've created a video4linux driver for the Lifeview Flycam Supra Webcam.
It should be pretty common in Sweden at least since it was bundled with an ISP-package.
It uses the Winbond's w9966cf parport Webcam interface chip and the Phillips saa7111 
ccd-control chip.
(The w9966cf interface chip can be implemented with other ccd-controller chips but I 
don't know any other
combination.) My plan is however to support other ccd-controller chips when I've heard 
of any.

This patch is against linux-2.4.2 and have been tested on a couple of computer systems 
(one SMP) without
any problems.

I would appreciate if anyone could give me input on it. It would be nice if it could 
make it to the kernel
sourcetree

/Jakob

 PATCH BEGIN 

diff -urN -X dontdiff linux-vanilla/Documentation/Configure.help 
linux-2.4.2/Documentation/Configure.help
--- linux-vanilla/Documentation/Configure.help  Thu Feb 22 20:24:07 2001
+++ linux-2.4.2/Documentation/Configure.helpTue Mar 27 00:49:21 2001
@@ -16322,6 +16322,23 @@
   monochrome Quickcam, Quickcam VC or QuickClip. It is also available
   as a module (c-qcam.o). Read Documentation/video4linux/CQcam.txt for
   more information.
+  
+Winbond W9966CF Webcam Video For Linux
+CONFIG_VIDEO_W9966
+  Video4linux driver for Winbond's w9966 based Webcams.
+  Currently tested with the LifeView FlyCam Supra.
+  If you have one of these cameras, say Y here
+  otherwise say N.
+  This driver is also available as a module (w9966.o)
+  
+  Checkout Documentation/video4linux/w9966.txt and w9966.c
+  for more information.
+CONFIG_VIDEO_W9966_RGB
+  Some programs might have problems with 16bit YUV422 data.
+  Use this option to allow 24bit RGB capturing.
+  
+  If this option is set and w9966 is built as a module
+  you have the option to override it with module option rgb=0
 
 CPiA Video For Linux
 CONFIG_VIDEO_CPIA
diff -urN -X dontdiff linux-vanilla/Documentation/video4linux/w9966.txt 
linux-2.4.2/Documentation/video4linux/w9966.txt
--- linux-vanilla/Documentation/video4linux/w9966.txt   Thu Jan  1 01:00:00 1970
+++ linux-2.4.2/Documentation/video4linux/w9966.txt Tue Mar 27 01:02:00 2001
@@ -0,0 +1,37 @@
+
+W9966 Camera driver, written by Jakob Kemi ([EMAIL PROTECTED])
+
+Ok, after a lot of work in softice, wdasm, reading pdf-files
+and trial-and-error work I've finally got everything to work.
+Since I needed some vision for a robotics project I borrowed
+this camera from a friend and started hacking. Anyway I've
+converted my original code from the AVR 8bit RISC C/asm
+into a working linux driver. I would really appreciate _any_
+kind of feedback regarding this driver.
+
+To get it working quickly configure your kernel
+to support parport, ieee1284, video4linux, experimental drivers
+and w9966
+
+If w9966 is statically linked it will perform aggressive probing
+for the camera. If built as a module you have more configuration options.
+
+Options:
+modprobe w9966.o pardev=parport0(or whatever) parmode=0 rgb=1(or 0 if
+ your programs can handle 16bit yuv422, which is faster)
+ 
+voila!
+
+you can also type 'modinfo -p w9966.o' for option usage
+(or checkout w9966.c)
+
+I've only tested it with custom built testprograms and with gqcam.
+(you'll need to change the w9966_v4l_ioctl function to report max
+dimensions of 200x200 for gqcam to work)
+
+The slow framerate is due to missing DMA ECP read support in the 
+parport drivers. I might add EPP support later.
+
+Good luck!
+
+/Jakob
diff -urN -X dontdiff linux-vanilla/drivers/media/video/Config.in 
linux-2.4.2/drivers/media/video/Config.in
--- linux-vanilla/drivers/media/video/Config.in Thu Feb 22 20:24:14 2001
+++ linux-2.4.2/drivers/media/video/Config.in   Tue Mar 27 00:20:52 2001
@@ -21,6 +21,17 @@
   dep_tristate '  QuickCam Colour Video For Linux (EXPERIMENTAL)' 
CONFIG_VIDEO_CQCAM $CONFIG_VIDEO_DEV $CONFIG_PARPORT
fi
 fi
+if [ "$CONFIG_PARPORT" != "n" ]; then
+   if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
+  if [ "$CONFIG_PARPORT_1284" != "n" ]; then
+ dep_tristate '  Winbond W9966CF Webcam Video For Linux (EXPERIMENTAL)' 
+CONFIG_VIDEO_W9966 $CONFIG_VIDEO_DEV $CONFIG_PARPORT
+  fi
+  if [ "$CONFIG_VIDEO_W9966" != "n" ]; then
+ bool 'Enable 24bit RGB support for w9966cf' CONFIG_VIDEO_W9966_RGB
+  fi
+
+   fi
+fi
 dep_tristate '  CPiA Video For Linux' CONFIG_VIDEO_CPIA $CONFIG_VIDEO_DEV
 if [ "$CONFIG_VIDEO_CPIA" != "n" ]; then
   if [ "$CONFIG_PARPORT_1284" != "n" ]; then
diff -urN -X dontdiff linux-vanilla/drivers/media/video/Makefile 
linux-2.4.2/drivers/media/video/Makefile
--- linux-vanilla/drivers/media/video/Makefile  Tue Jan  9 19:34:15 2001
+++ linux-2.4.2/drivers/media/video/MakefileMon Mar 26 21:10:06 

Re: memcpy in 2.2.19

[Keith Owens]

On Fri, 30 Mar 2001 08:04:17 +0100, 
"Chris Funderburg" <[EMAIL PROTECTED]> wrote:
>drivers/scsi/scsi.a(aic7xxx.o): In function `aic7xxx_load_seeprom':
>aic7xxx.o(.text+0x116bf): undefined reference to `memcpy'

Under some circumstances gcc will generate an internal call to
memcpy().  Alas this bypasses the pre-processor so memcpy is not
converted to the kernel's internal memcpy code.  The cause is normally
a structure assignment, probably this line.

  struct seeprom_config *sc = (struct seeprom_config *) scarray;

Try this replacement

  struct seeprom_config *sc;
  memcpy(sc, scarray, sizeof(*sc));

The other possibility I can see is

p->sc = *sc;

try

memcpy(&(p->sc), sc, sizeof(*sc));

-
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.3 aic7xxx wont compile

[George Bonser]

Just tried to build 2.4.3, got:

make[6]: Entering directory
`/usr/local/src/linux/drivers/scsi/aic7xxx/aicasm'
gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
aicasm_symbol.c -o aicasm
aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory
aicasm/aicasm_gram.y:50: aicasm.h: No such file or directory
aicasm/aicasm_gram.y:51: aicasm_symbol.h: No such file or directory
aicasm/aicasm_gram.y:52: aicasm_insformat.h: No such file or directory
aicasm/aicasm_scan.l:44: ../queue.h: No such file or directory
aicasm/aicasm_scan.l:49: aicasm.h: No such file or directory
aicasm/aicasm_scan.l:50: aicasm_symbol.h: No such file or directory
aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory
make[6]: *** [aicasm] Error 1
make[6]: Leaving directory
`/usr/local/src/linux/drivers/scsi/aic7xxx/aicasm'
...

Looks like something's missing here. Had 2.4.2 patched to 2.4.3-pre7, backed
out pre7 and applied 2.4.3.

A patch has not hit the archive I use and I have just subscribed. Anyone
have a fix for this? I gotta have aic7xxx support, its my boot disk
controller.

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

memcpy in 2.2.19

[Chris Funderburg]

What's wrong with this picture:

ld -m elf_i386 -T /usr/src/kernel/stable/linux/arch/i386/vmlinux.lds -e
stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o
fs/fs.o ipc/ipc.o \
fs/filesystems.a \
net/network.a \
drivers/block/block.a drivers/char/char.o drivers/misc/misc.a
drivers/net/net.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a
drivers/pci/pci.a drivers/pnp/pnp.a drivers/video/video.a \
/usr/src/kernel/stable/linux/arch/i386/lib/lib.a
/usr/src/kernel/stable/linux/lib/lib.a
/usr/src/kernel/stable/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
drivers/scsi/scsi.a(aic7xxx.o): In function `aic7xxx_load_seeprom':
aic7xxx.o(.text+0x116bf): undefined reference to `memcpy'
make: *** [vmlinux] Error 1

Is this something outside the kernel tree that I've lost?  Seems a bit weird
since memcpy must be
used in thousands of other place.


-
'E's not pinin'!
'E's passed on!
This parrot is no more!
He has ceased to be!
'E's expired and gone to meet 'is maker!
'E's a stiff!
Bereft of life, 'e rests in peace!
If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies!
'Is metabolic processes are now 'istory!
'E's off the twig!
'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run
down the curtain and joined the bleedin' choir invisibile!!
THIS IS AN EX-PARROT!!

-
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: Larger dev_t

[Kai Henningsen]

[EMAIL PROTECTED] (Martin Dalecki)  wrote on 28.03.01 in 
<[EMAIL PROTECTED]>:

> Alan Cox wrote:
> >
> > > Exactly. It's just that for historical reasons, I think the major for
> > > "disk" should be either the old IDE or SCSI one, which just can show
> > > more devices. That way old installers etc work without having to
> > > suddenly start knowing about /dev/disk0.
> >
> > They will mostly break. Installers tend to parse /proc/scsi and have
> > fairly complex ioctl based relationships based on knowing ide v scsi.
> >
> > /dev/disc/ is a little un-unix but its clean
>
> Why do you worry about installers? New distro - new kernel - new
> installer
> that's they job to worry about it. They will change the installer anyway
> and this kind of change actually is going to simplyfy the code there, I
> think,
> a bit.
>
> Just kill the old device major suddenly and place it in the changelog
> of the new kernel that the user should mknod and add it to /dev/fstab
> before rebooting into the new kernel. Hey that's developement anyway :-)
> If the developer boots back into the old kernel just other mounts
>  in /dev/fstab will fail no problem for transition here in sight...

Make them finally use UUIDs and /proc/partitions. Except for the root fs,  
problem solved. (Well ok, someone needs to create the right device nodes.)

As for the root fs, even that part isn't hard with an initrd.

MfG Kai
-
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 scheduler limitations?

[Giuliano Pochini]

On 29-Mar-01 Fabio Riccardi wrote:
> Hello,
> 
> I'm working on an enhanced version of Apache and I'm hitting my head
> against something I don't understand.
> 
> I've found a (to me) unexplicable system behaviour when the number of
> Apache forked instances goes somewhere beyond 1050, the machine
> suddently slows down almost top a halt and becomes totally unresponsive,
> until I stop the test (SpecWeb).

Are you using 2.2.x ?  I had the same problem here until I switched
to 2.4.x. 2.2 internal locks are not fine grained enough.


Bye.
Giuliano Pochini ->)|(<- Shiny Network {AS6665} ->)|(<-

-
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: EXT2-fs error

[Rogier Wolff]

khromy wrote:
> Linux vingeren.girl 2.4.3-pre7 #5 Mon Mar 26 23:33:59 EST 2001 i686 unknown
> 
> EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 
>1048576
> EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 
>1048576
> 
> ^
> I got the following while rm -rf'ing my mozilla cvs checkout.  Deadly or not deadly?

Highly deadly. 

Your disk is dropping bits, or, more likely, your RAM. This is very,
very bad.

Can you compile 100 kernes without error?

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: [ISDN-ERR]

[Ronald Jeninga]

Hello,

man isdn_cause 
says
E  = EDSS1
00 = User Message
1B = Destination out of order

The other end seems to have a problem
Doesn't seem to be a kernel issue though

Ronald Jeninga

hugang wrote:
> 
> Hello all:
> 
> ---
> OPEN: 10.0.0.2 -> 202.99.16.1 UDP, port: 1024 -> 53
> ippp0: dialing 1 86310163...
> isdn: HiSax,ch0 cause: E001B<--- error !!
> isdn_net: local hangup ippp0
> ippp0: Chargesum is 0
> ---
> Can someone tell me ,howto fix it ??
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH for 2.5] preemptible kernel

[Keith Owens]

On Wed, 28 Mar 2001 12:51:02 -0800, 
george anzinger <[EMAIL PROTECTED]> wrote:
>Dipankar Sarma wrote:
>> 1. Disable pre-emption during the time when references to data
>> structures
>> updated using such Two-phase updates are held.
>
>Doesn't this fly in the face of the whole Two-phase system?  It seems to
>me that the point was to not require any locks.  Preemption disable IS a
>lock.  Not as strong as some, but a lock none the less.

The aim is to remove all module locks from the main kernel path and
move the penalty for module unloading into the task doing the unload.
Only the unload code needs to worry about preemption, not the main
kernel code paths, so main line code runs faster and scales better.  I
don't care how long (within reason) it takes to unload a module, it is
such a rare event.  I want module unload to be race free with zero
impact on the fast code paths, the current design penalizes the fast
code paths.

-
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: Original destination of transparent proxied connections?

[Rob Landley]

Yeah, I found it.

While researching replacing the 2.2 kernel with 2.4 to
get my proxy-oid to work, I stumbled accross the
following section in the unofficial NAT-HOWTO (which
is not on linuxdoc's website as far as I can tell). 
At this address:

http://netfilter.kernelnotes.org/unreliable-guides/NAT-HOWTO/NAT-HOWTO.linuxdoc-4.html

Under section four ("quick translation from 2.0 and
2.2 kernels"), under the heading "Hackers may also
notice:", item two in the list:

>The (undocumented) `getsockname' hack, which
>transparent proxy programs could use to find out the
>real destinations of connections no longer works. 

Ah!  A clue!  But no idea how to make it work under
2.4, and no mention of what replaces it!  (I read the
rest of the howto carefully.  Never mentioned this
topic again.)  But there IS a way to get it to work
under 2.2, if I can learn an undocumented (but
functional) hack.

So I jump to the contents page to see who the HOWTO
maintainer is to ask rather pointed questions.  His
email address isn't listed, but I do I find out that
the netfilter mailing list is at
[EMAIL PROTECTED]  http://list.samba.org
turns out to have a page of hosted lists, with a link
that eventually leads to an archive, which is not
easily searchable except by date.  Fun.

This brings us to google, which can find anything if
you just know what to ask for.  I search for
"lists.samba.org netfilter getsockname".  The first
hit is just that silly howto again, but the second
hit:

http://lists.samba.org/pipermail/netfilter/2000-September/005317.html

An explanation, complete with example code.  From
september of last year.

And there was much rejoicing.

If I were to perhaps send linuxdoc.org a check or
something, might a day come to pass when learning to
do seemingly obvious things under linux does NOT
require fairly good forensic investigation skills?  I
ask merely for information.

I need to get more caffiene now.  I'm going to be up
REALLY late coding. :)

Rob

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: configuring net interfaces

[Jeff Garzik]

On 29 Mar 2001, Krzysztof Halasa wrote:

> Jeff Garzik <[EMAIL PROTECTED]> writes:
> 
> > > Maybe it's a better idea to have just two ioctl's here (GET and SET), and
> > > have "subioctl's" inside the structure passed to the HDLC layer (and
> > > defined by the HDLC layer). This would allow changes in the HDLC layer
> > > without having to change sockios.h (you'd still have to change HDLC's
> > > code and definitions, but this would be more self-contained). Again, this
> > > may be better, or maybe not. What do you think?
> > 
> > That's essentially what's happening with ethtool
> > (include/linux/ethtool.h in 2.4.3-pre8)
> 
> Right. While I don't think ethernet-only interface is our ultimate goal,
> I'll look at it again to see if I can stole some idea there.

I'm not suggesting you modify ethtool for your needs :)   But ethtool
perfectly illustrates the technique of using a single socket ioctl
(SIOCETHTOOL) to extend a set of standard, domain-specific ioctls
(ETHTOOL_xxx) to Linux networking drivers.

Jeff



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

bug in natsemi driver 1.07 for linux 2.4.2

[Sebastian Klemke]

Hi!

The driver for the natsemi NIC does not properly filter out requested
multicast groups when in multicast mode.  Multicast groups I joined
are simply dropped by the MAC address filter of the card, the kernel
filters them correctly in allmulti or promiscuous mode. I've tested
driver versions 1.05 which comes with linux 2.4.2, an older version
that came with linux-2.4.0test12 and 1.07 which came with 2.4.2-ac20.

I contacted Donald Becker and he told me to post it here.


Read U!

packet
-
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 leak in the ramfs file system

[Amit D Chaudhary]

 >(none):/mnt/ramfs/root# df -h /mnt/ramfs/
 >FilesystemSize  Used Avail Use% Mounted on
 >ramfs0 0 0   -  /mnt/ramfs
I am not sure, how related this is, but we have / on ramfs and using rpm 
to install(-iUvh) fails with the mesages, need 12K on /


Amit

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

EXT2-fs error

[khromy]

Linux vingeren.girl 2.4.3-pre7 #5 Mon Mar 26 23:33:59 EST 2001 i686 unknown

EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 
1048576
EXT2-fs error (device ide2(33,3)): ext2_free_blocks: bit already cleared for block 
1048576

^
I got the following while rm -rf'ing my mozilla cvs checkout.  Deadly or not deadly?

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

Re: OOM killer???

[Michael Peddemors]

Looking over the last few weeks of postings, there are just WAY to many
conflicting ways that people want the OOM to work..  Although an
incredible amount of good work has gone into this, people are definetely
not happy about the benifits of OOM ...  About 10 different approaches
are being made to change the rule based systems pertaining to WHEN the
OOM will fire, but in the end, still not everyone will be happy..

The old way of having a machien crash when you asked too much of it
seemed acceptable.. People then either chose to run the mem hog, and
upgrade their boxes, or they stopped running the memhog.

Maybe its time to hear from on high whether OOM capability outweighs the
problems that seem to be associated with it?

Either that or we should be able to allow the end user/and the distros
to decide what gets killed by OOM.

Some people might like to just say to heck with it, and not let anything
get killed, while others may just want to protect certain things.. 

Speaking completely where I don't belong, and don't know enough about..
Just a thought, can we come up with a new form of execute bit that would
define whether OOM should affect the process?  Then the app can be made
to be killable if not as root etc...  As well as being applied simply at
a per application basis, because we KNOW that not all applications will
ever be completely system friendly..
There will always be useful programs that might not fit into a OOM model
well.

Linus has been notably quite of late about this issue, given the amount
of contention on this issue..

On 29 Mar 2001 07:41:44 -0800, David Konerding wrote:

> Now, if you're going to implement OOM, when it is absolutely necessary, at the very
> least, move the policy implementation out of the kernel.  One of the general
> philosophies of Linux has been to move policy out of the kernel.  In this case, you'd
> just have a root owned process with locked pages that can't be pre-empted, which
> implemented the policy.  You'll never come up with an OOM policy that will fit
> everybody's needs unless it can be tuned for  particular system's usage, and it's
> going to be far easier to come up with that policy if it's not in the kernel.

-- 
"Catch the Magic of Linux..."

Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
WizardInternet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com

(604)589-0037 Beautiful British Columbia, Canada

-
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 scheduler limitations?

[Fabio Riccardi]

Hi Mike,

somebody else on the list already pointed me at your stuff and I quickly
downloaded your multiqueue patch for 2.4.1 to try it out.

It works great! I finally manage to have 100% CPU utilization and keep the
machine decently responsive.

On a two 1GHz pentium box i went from 1300 specweb to 1600. That's pretty
amazing.

There is a bit more overhead though, I'd say arount 5%, when the CPU is not
fully loaded.

What is the status of your code? Is it going to end-up in the mainstream
kernel?

Do you have a port to the 2.4.2x kernels?

In my enthousiasm I tried to port the patch to 2.4.2-ac26 but I broke
something and it didn't work anymore... :)

I havent't tried the pooling patch yet, it didn't seem to make much sense on a
2-way box. I have an 8-way on which I'm planning to bench my web server
enhancements, I'll try the pooling stuff on it.

BTW: interested in the fastest linux web server?

BTW2: what about the HP scheduler patches?

Thanks, ciao,

 - Fabio

Mike Kravetz wrote:

> On Thu, Mar 29, 2001 at 01:55:11PM -0800, Fabio Riccardi wrote:
> > I'm using 2.4.2-ac26, but I've noticed the same behavior with all the 2.4
> > kernels I've seen so far.
> >
> > I haven't even tried on 2.2
> >
> >  - Fabio
>
> Fabio,
>
> Just for fun, you might want to try out some of our scheduler patches
> located at:
>
> http://lse.sourceforge.net/scheduling/
>
> I would be interested in your observations.
>
> --
> Mike Kravetz [EMAIL PROTECTED]
> IBM Linux Technology Center

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

Re: Bug in the file attributes ?

[Tim Wright]

On Thu, Mar 29, 2001 at 10:51:18AM -0800, Justin Carlson wrote:
> You don't need write perms on a file to remove it, you need write perms on the
> directory.  If you've got write permissions on the directory, you can remove
> any file in the directory, regardless of the permissions.
> 
> -Justin

Except when the "sticky" bit is set. This is useful for shared temporary
directories. Files can be created by anyone, but they can only be unlinked
by the owner or by the superuser. Take a look at the permissions of /var/tmp.

Tim

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
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/

[ISDN-ERR]

[hugang]

Hello all:

---
OPEN: 10.0.0.2 -> 202.99.16.1 UDP, port: 1024 -> 53
ippp0: dialing 1 86310163...
isdn: HiSax,ch0 cause: E001B<--- error !!
isdn_net: local hangup ippp0
ippp0: Chargesum is 0
---
Can someone tell me ,howto fix it ??
-
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/

[OT] Re: Linux connectivity trashed.

[David]

Might I suggest seeking a new employer whose IT department doesn't seek 
the smell of fresh fertilizer compounds about their head and neck.

-d

Richard B. Johnson wrote:

> This is for information only.
> 
> Last week a standard RH distribution of  Linux was rooted from what looks
> like a Russian invasion. The penetration used the method taught in the CERT
> Advisory CA-2000-17.
> [...]


-
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 scheduler limitations?

[Mike Kravetz]

On Thu, Mar 29, 2001 at 01:55:11PM -0800, Fabio Riccardi wrote:
> I'm using 2.4.2-ac26, but I've noticed the same behavior with all the 2.4
> kernels I've seen so far.
> 
> I haven't even tried on 2.2
> 
>  - Fabio

Fabio,

Just for fun, you might want to try out some of our scheduler patches
located at:

http://lse.sourceforge.net/scheduling/

I would be interested in your observations.

-- 
Mike Kravetz [EMAIL PROTECTED]
IBM Linux Technology Center
-
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 leak in the ramfs file system

[Jaswinder Singh]

There is some problem in my computer's clock . please do not mind .

I am sorry for inconvenience.

Jaswinder.

- Original Message -
From: "Jaswinder Singh" <[EMAIL PROTECTED]>
To: "Linus Torvalds" <[EMAIL PROTECTED]>; "Jamey Hicks"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: "Stephen L Johnson" <[EMAIL PROTECTED]>; "Jaswinder Singh"
<[EMAIL PROTECTED]>
Sent: Monday, March 12, 2001 5:03 PM
Subject: Fw: Memory leak in the ramfs file system


> I am sorry, i am sending this mail again because earlier my Computer's
time
> was not set properly.
>
> Jaswinder
>
> - Original Message -
> From: "Jaswinder Singh" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Linus Torvalds"
> <[EMAIL PROTECTED]>; "Jamey Hicks" <[EMAIL PROTECTED]>
> Cc: "Stephen L Johnson" <[EMAIL PROTECTED]>; "Jaswinder Singh"
> <[EMAIL PROTECTED]>
> Sent: Monday, June 12, 2000 12:50 PM
> Subject: Re: Memory leak in the ramfs file system
>
>
> > Dear Linus,
> >
> >
> > > What does /proc/slabinfo say? The most likely leak is a dentry leak or
> > > an inode leak, and both of those should be fairly easy to see in the
> > > slab info (dentry_cache and inode_cache respectively).
> > >
> >
> > I am attaching details before and during  my application .
> >
> > Mainly changes are in dentry_cache and inode_cache , but i am attaching
> > whole /proc/slabinfo for your reference.
> >
> >
> > > Obviously, it could be a data page leak too, but such a leak should be
> > > easy to see by creating a few big files and deleting them..
> > >
> > > Linus
> >
> > I am also facing one more problem with ramfs.
> >
> > du and df shows 0 , so i am also attaching its output.
> >
> > Thanks for your help,
> >
> > Best Regards,
> >
> > Jaswinder.
> > --
> > These are my opinions not 3Di.
> >
> >
> >
> >
>

-
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: How to debug an oops?

[Tony Hoyle]

Sorry, came across a bit strong on that message.  It's 2am and I'm tired.

Stupid thing is I fixed the bug...

Tony

-- 
Don't click on this sig - a cyberwoozle will eat your underwear.

[EMAIL PROTECTED]http://www.nothing-on.tv

-
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] Fix SMP lockup in usbdevfs

[Tony Hoyle]

This fixes a lockup when calling the USBDEVFS_SUBMITURB ioctl in an SMP 
kernel.

Tony

-- 
Don't click on this sig - a cyberwoozle will eat your underwear.

[EMAIL PROTECTED]http://www.nothing-on.tv


--- devio.c.old Fri Mar 30 02:22:32 2001
+++ devio.c Fri Mar 30 02:12:09 2001
@@ -175,6 +175,7 @@
 return NULL;
 memset(as, 0, assize);
 as->urb.number_of_packets = numisoframes;
+spin_lock_init(>urb.lock);
 return as;
 }
 
@@ -250,7 +251,7 @@
 struct dev_state *ps = as->ps;
struct siginfo sinfo;
 
-#if 1
+#if 0
printk(KERN_DEBUG "usbdevfs: async_completed: status %d errcount %d actlen %d 
pipe 0x%x\n", 
   urb->status, urb->error_count, urb->actual_length, urb->pipe);
 #endif

Fw: Memory leak in the ramfs file system

[Jaswinder Singh]

I am sorry, i am sending this mail again because earlier my Computer's time
was not set properly.

Jaswinder

- Original Message -
From: "Jaswinder Singh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Linus Torvalds"
<[EMAIL PROTECTED]>; "Jamey Hicks" <[EMAIL PROTECTED]>
Cc: "Stephen L Johnson" <[EMAIL PROTECTED]>; "Jaswinder Singh"
<[EMAIL PROTECTED]>
Sent: Monday, June 12, 2000 12:50 PM
Subject: Re: Memory leak in the ramfs file system


> Dear Linus,
>
>
> > What does /proc/slabinfo say? The most likely leak is a dentry leak or
> > an inode leak, and both of those should be fairly easy to see in the
> > slab info (dentry_cache and inode_cache respectively).
> >
>
> I am attaching details before and during  my application .
>
> Mainly changes are in dentry_cache and inode_cache , but i am attaching
> whole /proc/slabinfo for your reference.
>
>
> > Obviously, it could be a data page leak too, but such a leak should be
> > easy to see by creating a few big files and deleting them..
> >
> > Linus
>
> I am also facing one more problem with ramfs.
>
> du and df shows 0 , so i am also attaching its output.
>
> Thanks for your help,
>
> Best Regards,
>
> Jaswinder.
> --
> These are my opinions not 3Di.
>
>
>
>


Before my Application Start
---
(none):/mnt/ramfs/root# cat /proc/meminfo 
total:used:free:  shared: buffers:  cached:
Mem:  31571968 18669568 12902400024576 12156928
Swap:000
MemTotal:30832 kB
MemFree: 12600 kB
MemShared:   0 kB
Buffers:24 kB
Cached:  11872 kB
Active:   4456 kB
Inact_dirty:   508 kB
Inact_clean:  6932 kB
Inact_target:8 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:30832 kB
LowFree: 12600 kB
SwapTotal:   0 kB
SwapFree:0 kB
(none):/mnt/ramfs/root# free
 total   used   free sharedbuffers cached
Mem: 30832  18284  12548  0 24  11916
-/+ buffers/cache:   6344  24488
Swap:0  0  0
(none):/mnt/ramfs/root# cat /proc/slabinfo 
slabinfo - version: 1.1
kmem_cache53 78100221
tcp_tw_bucket  0 40 96011
tcp_bind_bucket5113 32111
tcp_open_request   0 59 64011
inet_peer_cache0  0 64001
ip_fib_hash8113 32111
ip_dst_cache  11 24160111
arp_cache  2 30128111
blkdev_requests  256280 96771
dnotify cache  0  0 20001
file lock cache0 42 92011
fasync cache   2202 16111
uid_cache  1113 32111
skbuff_head_cache 84120160451
sock  30 35800671
inode_cache 2218   2220384  222  2221
bdev_cache48 59 64111
sigqueue   0 29132011
kiobuf 0  0128001
dentry_cache2351   2370128   79   791
filp 125160 96441
names_cache0  2   4096021
buffer_head9 40 96111
mm_struct 13 24160111
vm_area_struct   268354 64561
fs_cache  12 59 64111
files_cache   12 18416221
signal_act14 15   1312551
size-131072(DMA)   0  0 13107200   32
size-1310720  0 13107200   32
size-65536(DMA)0  0  6553600   16
size-65536 0  0  6553600   16
size-32768(DMA)0  0  32768008
size-32768 1  1  32768118
size-16384(DMA)0  0  16384004
size-16384 0  0  16384004
size-8192(DMA) 0  0   8192002
size-8192  0  0   8192002
size-4096(DMA) 0  0   4096001
size-4096  3  4   4096341
size-2048(DMA) 0  0   2048001
size-2048  6  8   2048341
size-1024(DMA) 0  0   1024001
size-1024  9 16   1024341
size-512(DMA)  0  0512001
size-512  23 32512341
size-256(DMA)  0  0256001
size-256  20 60256241
size-128(DMA)  0  0128001
size-128 366450128   13   151
size-64(DMA)   0  0 64001
size-64   43 59 64 

Re: how can I send a signal like kill

[hugang]

On Thu, 29 Mar 2001 11:46:42 +0200
Cedric Lienart <[EMAIL PROTECTED]> wrote:

> how can I send a signal like 'kill (pid_t pid, int sig);' from a driver
> module to a user program. When I include signal.h in my module I have

Try use force_sig(int sig, struct task_struct *p), Can read mm/oom_kill.c .
-
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/

Original destination of transparent proxied connections?

[Rob Landley]

Help.

I thought transparent proxying would allow some means
for the recipient of the proxied connections to find
out what their original destination port and socket
address were.  This does not seem to be the case.  The
socket structure only has one address and one socket,
and those have the source address, not the destination
address.

How do forward connections to a given address range to
a user space program that then has the opportunity to
bidirectionally munge the data in them and forward
them on?  Transparent proxying works just fine
assuming I only ever want to forward a single port to
just one other machine...

IPCHAINS isn't up to it.  Before I go and upgrade to
the 2.4 kernel on production systems that ship Real
Soon Now, could somebody give me at least an opinion
on whether or not iptables and the 2.4 nat stuff can
do this kind of thing without me having to modify the
kernel to fill out a larger socket-oid structure?  (Is
2.4 iptables documented anywhere yet?)

I've got everything else.  If I could just get a
destination address and port out of transparently
proxied connections I'd be home free.  I'm amazed this
data isn't there already, I must have missed something
stupid.  How do sockets bound to multiple interfaces
figure out which interface the connection came from?

Rob

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text
-
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 leak in the ramfs file system

[Jaswinder Singh]

Dear Linus,


> What does /proc/slabinfo say? The most likely leak is a dentry leak or
> an inode leak, and both of those should be fairly easy to see in the
> slab info (dentry_cache and inode_cache respectively).
>

I am attaching details before and during  my application .

Mainly changes are in dentry_cache and inode_cache , but i am attaching
whole /proc/slabinfo for your reference.


> Obviously, it could be a data page leak too, but such a leak should be
> easy to see by creating a few big files and deleting them..
>
> Linus

I am also facing one more problem with ramfs.

du and df shows 0 , so i am also attaching its output.

Thanks for your help,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.





Before my Application Start
---
(none):/mnt/ramfs/root# cat /proc/meminfo 
total:used:free:  shared: buffers:  cached:
Mem:  31571968 18669568 12902400024576 12156928
Swap:000
MemTotal:30832 kB
MemFree: 12600 kB
MemShared:   0 kB
Buffers:24 kB
Cached:  11872 kB
Active:   4456 kB
Inact_dirty:   508 kB
Inact_clean:  6932 kB
Inact_target:8 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:30832 kB
LowFree: 12600 kB
SwapTotal:   0 kB
SwapFree:0 kB
(none):/mnt/ramfs/root# free
 total   used   free sharedbuffers cached
Mem: 30832  18284  12548  0 24  11916
-/+ buffers/cache:   6344  24488
Swap:0  0  0
(none):/mnt/ramfs/root# cat /proc/slabinfo 
slabinfo - version: 1.1
kmem_cache53 78100221
tcp_tw_bucket  0 40 96011
tcp_bind_bucket5113 32111
tcp_open_request   0 59 64011
inet_peer_cache0  0 64001
ip_fib_hash8113 32111
ip_dst_cache  11 24160111
arp_cache  2 30128111
blkdev_requests  256280 96771
dnotify cache  0  0 20001
file lock cache0 42 92011
fasync cache   2202 16111
uid_cache  1113 32111
skbuff_head_cache 84120160451
sock  30 35800671
inode_cache 2218   2220384  222  2221
bdev_cache48 59 64111
sigqueue   0 29132011
kiobuf 0  0128001
dentry_cache2351   2370128   79   791
filp 125160 96441
names_cache0  2   4096021
buffer_head9 40 96111
mm_struct 13 24160111
vm_area_struct   268354 64561
fs_cache  12 59 64111
files_cache   12 18416221
signal_act14 15   1312551
size-131072(DMA)   0  0 13107200   32
size-1310720  0 13107200   32
size-65536(DMA)0  0  6553600   16
size-65536 0  0  6553600   16
size-32768(DMA)0  0  32768008
size-32768 1  1  32768118
size-16384(DMA)0  0  16384004
size-16384 0  0  16384004
size-8192(DMA) 0  0   8192002
size-8192  0  0   8192002
size-4096(DMA) 0  0   4096001
size-4096  3  4   4096341
size-2048(DMA) 0  0   2048001
size-2048  6  8   2048341
size-1024(DMA) 0  0   1024001
size-1024  9 16   1024341
size-512(DMA)  0  0512001
size-512  23 32512341
size-256(DMA)  0  0256001
size-256  20 60256241
size-128(DMA)  0  0128001
size-128 366450128   13   151
size-64(DMA)   0  0 64001
size-64   43 59 64111
size-32(DMA)   0  0 32001
size-32  116226 32221


when my Application is running : i am able to take only 11 slabinfo details then my 
machine hanged
--
(none):/mnt/ramfs/root# free
 total   used   free sharedbuffers cached
Mem: 30832  20792  10040  0 24  13992
-/+ buffers/cache:   6776  24056
Swap:0  0   

How to debug an oops?

[Tony Hoyle]

Nobody seems interested in the spinlock bugs in usb so I'm trying to 
track it down myself.  I have a copy of an oops (posted earlier) but it 
doesn't give the line number of the error, so it's impossible to find 
out where it's failing.

Will kdb be any help?  Is it a source debugger or just a glorified hex 
editor?   I need to be able to break into the kernel and single step 
through the calls to work out what is going on.

I'm really out of my depth trying to debug this, but I hate having to 
boot a UP kernel just to use usb.

Tony

--
Don't click on this sig - a cyberwoozle will eat your underwear.

[EMAIL PROTECTED]http://www.nothing-on.tv

-
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 for 2.5] preemptible kernel

[Nigel Gamble]

On Tue, 20 Mar 2001, Nigel Gamble wrote:
> On Tue, 20 Mar 2001, Rusty Russell wrote:
> > Thoughts?
> 
> Perhaps synchronize_kernel() could take the run_queue lock, mark all the
> tasks on it and count them.  Any task marked when it calls schedule()
> voluntarily (but not if it is preempted) is unmarked and the count
> decremented.  synchronize_kernel() continues until the count is zero.

Hi Rusty,

Here is an attempt at a possible version of synchronize_kernel() that
should work on a preemptible kernel.  I haven't tested it yet.


static int sync_count = 0;
static struct task_struct *syncing_task = NULL;
static DECLARE_MUTEX(synchronize_kernel_mtx);

void
synchronize_kernel()
{
struct list_head *tmp;
struct task_struct *p;

/* Guard against multiple calls to this function */
down(_kernel_mtx);

/* Mark all tasks on the runqueue */
spin_lock_irq(_lock);
list_for_each(tmp, _head) {
p = list_entry(tmp, struct task_struct, run_list);
if (p == current)
continue;
if (p->state == TASK_RUNNING ||
(p->state == (TASK_RUNNING|TASK_PREEMPTED))) {
p->flags |= PF_SYNCING;
sync_count++;
}
}
if (sync_count == 0)
goto out;

syncing_task = current;
spin_unlock_irq(_lock);

/*
 * Cause a schedule on every CPU, as for a non-preemptible
 * kernel
 */

/* Save current state */
cpus_allowed = current->cpus_allowed;
policy = current->policy;
rt_priority = current->rt_priority;

/* Create an unreal time task. */
current->policy = SCHED_FIFO;
current->rt_priority = 1001 + sys_sched_get_priority_max(SCHED_FIFO);

/* Make us schedulable on all CPUs. */
current->cpus_allowed = (1ULcpus_allowed = cpus_allowed;
current->policy = policy;
current->rt_priority = rt_priority;

/*
 * Wait, if necessary, until all preempted tasks
 * have reached a sync point.
 */

spin_lock_irq(_lock);
for (;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
if (sync_count == 0)
break;
spin_unlock_irq(_lock);
schedule();
spin_lock_irq(_lock);
}
current->state = TASK_RUNNING;
syncing_task =  NULL;
out:
spin_unlock_irq(_lock);

up(_kernel_mtx);
}

And add this code to the beginning of schedule(), just after the
runqueue_lock is taken (the flags field is probably not be the right
place to put the synchronize mark; and the test should be optimized for
the fast path in the same way as the other tests in schedule(), but you
get the idea):

if ((prev->flags & PF_SYNCING) && !(prev->state & TASK_PREEMPTED)) {
prev->flags &= ~PF_SYNCING;
if (--sync_count == 0) {
syncing_task->state = TASK_RUNNING;
if (!task_on_runqueue(syncing_task))
add_to_runqueue(syncing_task);
syncing_task = NULL;
}

}

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [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/

IRQ routing conflict & ressource assignment on Thinkpad

[Andreas Bombe]

Something that was itching me for a while (and I had a bad conscience
for not reporting a bug for so long):

I have an IBM Thinkpad i1200 (1161-267, Celeron 550, see lspci below).

The PCI code in 2.4 always complains about an IRQ routing conflict wrt
the CardBus controller.  That used to make it crash when hotplug is
configured, since loading the i810 sound module would change the
controller's IRQ, then a inserting a card blows it up.  Doesn't seem to
happen anymore, but the warnings are still there.

Another (possibly related) problem is that the controller does not get
IO resources assigned, so the Tulip driver won't work.  This
specifically happens only with kernel hotplug code, pcmcia-cs modules
3.1.22 work for me.  The IRQ crashes also happened only with kernel
hotplug, the conflict report is always on.

Oh, and sometimes the i810 audio driver can hang the system, games seem
to trigger that, sound output from e.g. mp3 player don't hurt.  But I
don't have much data on that yet.

Following data is collected from the kernel with PCI hotplug configured
in.  If someone needs the .config, please ask.

This is what dump_pirq says:

Interrupt routing table found at address 0xfbdb0:
  Version 1.0, size 0x0070
  Interrupt router is device 00:07.0
  PCI exclusive interrupt mask: 0x []
  Compatible router: vendor 0x8086 device 0x7198

Device 00:02.0 (slot 0): VGA compatible controller
  INTA: link 0x60, irq mask 0x0400 [10]

Device 00:07.0 (slot 0): ISA bridge
  INTD: link 0x63, irq mask 0x0400 [10]

Device 00:06.0 (slot 0): 
  INTA: link 0x62, irq mask 0x8000 [15]

Device 00:03.0 (slot 0): CardBus bridge
  INTA: link 0x61, irq mask 0x0400 [10]
  INTB: link 0x62, irq mask 0x0400 [10]

Device 00:00.0 (slot 0): Host bridge
  INTB: link 0x61, irq mask 0x0800 [11]

Interrupt router at 00:07.0: Intel 82443MX PCI-to-ISA bridge
  PIRQ1 (link 0x60): irq 10
  PIRQ2 (link 0x61): irq 11
  PIRQ3 (link 0x62): unrouted
  PIRQ4 (link 0x63): irq 10
  Serial IRQ: [enabled] [continuous] [frame=21] [pulse=12]
  Level mask: 0x0c00 [10,11]



The relevant lines from dmesg for both problems:

Linux version 2.4.2 (root@merv) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 
Die Feb 27 21:45:50 CET 2001
[...]
PCI: PCI BIOS revision 2.10 entry at 0xf0200, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7198] at 00:07.0
  got res[1000:1fff] for resource 0 of O2 Micro, Inc. OZ6812 Cardbus Controller
[...]
Linux PCMCIA Card Services 3.1.22
  options:  [pci] [cardbus] [pm]
PCI: Found IRQ 11 for device 00:03.0
PCI: The same IRQ used for device 00:00.1
PCI: The same IRQ used for device 00:00.2
IRQ routing conflict in pirq table for device 00:03.0
Intel PCIC probe: not found.
[...]
Yenta IRQ list 02b8, PCI irq10
Socket status: 3821
[...]
PCI: Found IRQ 10 for device 00:07.2
usb-uhci.c: USB UHCI at I/O 0x8000, IRQ 10
usb-uhci.c: Detected 2 ports
[...]

Removed and reinserted ethernet pccard here:

cs: cb_alloc(bus 1): vendor 0x1011, device 0x0019
PCI: Failed to allocate resource 0 for PCI device 1011:0019
  got res[1080:108003ff] for resource 1 of PCI device 1011:0019
  got res[1040:1043] for resource 6 of PCI device 1011:0019
PCI: Enabling device 01:00.0 ( -> 0003)
Linux Tulip driver version 0.9.13a (January 20, 2001)
tulip: eth0: I/O region (0x0@0x1000) too small, aborting


And that's lspci -vvv with the ethernet card inserted:

00:00.0 Host bridge: Intel Corporation 82440MX I/O Controller (rev 01)
Subsystem: IBM: Unknown device 01ab
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- 16bInt- PostWrite+
16-bit legacy interface ports at 0001

00:07.0 ISA bridge: Intel Corporation 82440MX PCI to ISA Bridge (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Memory leak in the ramfs file system

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Stephen L Johnson  <[EMAIL PROTECTED]> wrote:
>
>A group of us from the handhelds.org site think that we have found a memory 
>leak in the ramfs file system. After a long period of create and deleting 
>small files in a mounted ramfs partition we have substantially less freemem.  
>The problem has been confirmed on 2.4.2 on an i386 and StormARM ports.

What does /proc/slabinfo say? The most likely leak is a dentry leak or
an inode leak, and both of those should be fairly easy to see in the
slab info (dentry_cache and inode_cache respectively).

Obviously, it could be a data page leak too, but such a leak should be
easy to see by creating a few big files and deleting them..

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: Bug in the file attributes ?

[Brian Beattie]

On Thu, 29 Mar 2001, Andreas Dilger wrote:

> Xavier Ordoquy writes:
> > I just made a manipulation that disturbs me. So I'm asking whether it's a
> > bug or a features.
> > 
> > user> su
> > root> echo "test" > test
> > root> ls -l
> > -rw-r--r--   1 root root5 Mar 29 19:14 test
> > root> exit
> > user> rm test
> > rm: remove write-protected file `test'? y
> > user> ls test
> > ls: test: No such file or directory
> > 
> > This is in the user home directory.
> > Since the file is read only for the user, it should not be able to remove
> > it. Moreover, the user can't write to test.
> 
> This is definitely not a bug.  Deleting a file (under *nix) does not
> "modify" the file at all, it is modifying the directory where the file
> resides.

To be correct and pedantic, in a traditional Unix type filesystem, one
does not remove a file...one dereferences it, i.e. "unlink", as part of
this process garbage collection is performed which checks the reference
count. If the inode's reference count is zero, the inode and data blocks
are returned to their respective free lists.  All the rm command does, is
to remove the directory entry and decrement the reference count :).  This
is why Unix has a rm (remove link) as opposed to a del (delete file)
command.

Brian...just being pedantic :-^

Brian Beattie
[EMAIL PROTECTED]
503.578.5899  Des2-3C-5

-
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: WG: 2.4 on COMPQ Proliant

[Mr. James W. Laferriere]

Hello Frank ,  Highly recommend the sym53c* .  JimL

On Thu, 29 Mar 2001, Butter, Frank wrote:
> 2.2.16 claimes to find a ncr53c1510D-chipset, supported by
> the driver ncr53c8xx. Which kernel-param would be the correct one for this?
> Frank
> > -Ursprüngliche Nachricht-
> > Von: Butter, Frank
> > Gesendet: Donnerstag, 29. März 2001 17:11
> > An: '[EMAIL PROTECTED]'
> > Betreff: 2.4 on COMPQ Proliant
> > Has anyone experiences with 2.4.x on recent Compaq Proliant
> > Servers (e.g. ML570)?
> >
> > I've installed RedHat7 and it worked fine out of the box.
> > Except that the SMP-enabled kernel stated there was no
> > SMP-board detected ;-/
> > For some reasons (Fibrechannel drivers and so on) I've compiled
> > 2.4.2 and installed it. Although I've compiled the support
> > in, the NCR-SCSI-chip was not found and therefore no
> > root-partition. It is a model supported by 53c8xx - detected
> > by the original RedHat-kernel.
> >
> > For testing I compiled a kernel with all (!) scsi-low-level-drivers -
> > with the same result. The SMP-board also was NOT detected by 2.4.2.
> >
> > Any hint?
> >
> > Frank
> >
> -
> 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/
>

   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

-
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] pcnet32 compilation fix for 2.4.3pre6

[Tom Leete]

Ulrich Drepper wrote:
> 
> [EMAIL PROTECTED] writes:
> 
> > with the new ansi standard, this use of __inline__ is no longer
> > necessary,
> 
> This is not correct.  Since the semantics of inline in C99 and gcc
> differ all code which depends on the gcc semantics should continue to
> use __inline__ since this keyword will hopefully forever signal the
> gcc semantics.

Unfortunately, it seems that gcc will define __inline__ as a synonym for
inline, whatever inline is currently in use. I asked this on the gcc list a
while ago. The archive there should have the replies.

Regards,
Tom

-- 
The Daemons lurk and are dumb. -- Emerson
-
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 scheduler limitations?

[Fabio Riccardi]

"J . A . Magallon" wrote:

> It all depends on your app, as every parallel algorithm. In a web-ftp-whatever
> server, you do not need any synchro. You can start threads in free run and
> let them die alone.

even if you don't need synchronization you pay for it anyway, since you will have
to use the pthread version of libc that is reentrant. Moreover many calls (i.e.
accept) are "scheduling points" for pthreads, whenever you call them the runtime
will perform quite a bit of bookeeping.

it is instructive to use a profiler on your application and see what happens when
you use pthreads...

> You said, 'mapped'.
> AFAIK, that is the advantage, you can avoid the VM switch by sharing memory.

If your application uses lots of memory than I agree, Apache only uses a tiny
amount of RAM per instance though, so I don't think that that is my case.

 - Fabio


-
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: how mmap() works?

[J . A . Magallon]

On 03.30 Jerry Hong wrote:
> Hi, 
>   mmap() creates a mmaped memory associated with a
> physical file. If a process updates the mmaped memory,
> Linux will updates the file "automatically". If this
> is the case, why do we need msync()? If this is not

Where did you heard that ?

man mmap(2):
..
   MAP_SHARED Share this mapping  with  all  other  processes
  that map this object.  Storing to the region is
  equivalent to writing to the  file.   The  file
  may  not  actually be updated until msync(2) or
  munmap(2) are called.
..
man msync(2):
..
DESCRIPTION
   msync  flushes  changes made to the in-core copy of a file
   that was mapped into memory using mmap(2)  back  to  disk.
   Without  use  of  this  call  there  is  no guarantee that
   changes are written back before munmap(2) is  called.   To
.

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.2-ac28 #1 SMP Thu Mar 29 16:41:17 CEST 2001 i686

-
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 scheduler limitations?

[J . A . Magallon]

On 03.30 Fabio Riccardi wrote:
> 
> Despite of all apparences this method performs beautifully on Linux, pthreads
> are
> actually slower in many cases, since you will incur some additional overhead
> due
> to thread synchronization and scheduling.
>

It all depends on your app, as every parallel algorithm. In a web-ftp-whatever
server, you do not need any synchro. You can start threads in free run and
let them die alone.

> The problem is that beyond a certain number of processes the scheduler just
> goes
> bananas, or so it seems to me.
> 
> Since Linux threads are mapped on processes, I don't think that (p)threads
> woud
> help in any way, unless it is the VM context switch overhead that is playing a
> role here, which I wouldn't think is the case.
> 

You said, 'mapped'.
AFAIK, that is the advantage, you can avoid the VM switch by sharing memory.

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.2-ac28 #1 SMP Thu Mar 29 16:41:17 CEST 2001 i686

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

how mmap() works?

[Jerry Hong]

Hi, 
  mmap() creates a mmaped memory associated with a
physical file. If a process updates the mmaped memory,
Linux will updates the file "automatically". If this
is the case, why do we need msync()? If this is not
the case, what is the interval between 2 "WRITE" (IO
request operation) request to the physical file
because it really updates the physical file somehow
even without msync().
  Any comments about how mmap() works will be
appreciated.
  Thanks.
  
  Jerry
  

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text
-
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 scheduler limitations?

[Fabio Riccardi]

Apache uses a pre-fork "threading" mechanism, it spawns (fork()s) new instances
of itself whenever it finds out that the number of idle "threads" is below a
certain (configurable) threshold.

Despite of all apparences this method performs beautifully on Linux, pthreads are
actually slower in many cases, since you will incur some additional overhead due
to thread synchronization and scheduling.

The problem is that beyond a certain number of processes the scheduler just goes
bananas, or so it seems to me.

Since Linux threads are mapped on processes, I don't think that (p)threads woud
help in any way, unless it is the VM context switch overhead that is playing a
role here, which I wouldn't think is the case.

 - Fabio

"J . A . Magallon" wrote:

> On 03.29 Fabio Riccardi wrote:
> >
> > I've found a (to me) unexplicable system behaviour when the number of
> > Apache forked instances goes somewhere beyond 1050, the machine
> > suddently slows down almost top a halt and becomes totally unresponsive,
> > until I stop the test (SpecWeb).
> >
>
> Have you though about pthreads (when you talk about fork, I suppose you
> say literally 'fork()') ?
>
> I give a course on Parallel Programming at the university and the practical
> work was done with POSIX threads. One of my students caught the idea and
> used it to modify his assignment from one other matter on Networks, and
> changed the traditional 'fork()' in a simple ftp server he had to implement
> by 'pthread_create' and got a 10-30 speedup (conns per second).
>
> And you will get rid of some process-per-user limit. But you will fall into
> an threads-per-user limit, if there is any.
>
> And you cal also control its scheduling, to make each thread fight against
> the whole system or only its siblings.
>
> --
> J.A. Magallon  #  Let the source
> mailto:[EMAIL PROTECTED]  #  be with you, Luke...
>
> Linux werewolf 2.4.2-ac28 #1 SMP Thu Mar 29 16:41:17 CEST 2001 i686

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

Memory leak in the ramfs file system

[Stephen L Johnson]

A group of us from the handhelds.org site think that we have found a memory 
leak in the ramfs file system. After a long period of create and deleting 
small files in a mounted ramfs partition we have substantially less freemem.  
The problem has been confirmed on 2.4.2 on an i386 and StormARM ports.

The problem was found by a developer running an application on an iPAQ that 
quickly writes a 4K file to the ramfs, does some editing of the file and it 
then deleted. The application will quickly eat up all free memory and cause 
the platform to fail within 5 minutes.

Test case: from a shell, run this short script for a long period of time (over 
1 hour):

   i=0 ; while : ; do echo 1 >$i ; rm $i ; i=`expr $i + 1` ; done

This test was run  on an Compaq iPAQ 3650 using the 2.4.2-rmk1-np3 kernel from 
the CVS repository on cvs.handhelds.org.

The following two data points are the output from /proc/meminfo.  The first  
'cat' was done about 1 minute after the loop has been running. The second 
'cat' was done 10 minutes after the script loop had been killed.

# cat /proc/meminfo
total:used:free:  shared: buffers:  cached:
Mem:  31686656 21446656 102400 11264000
Swap:000
MemTotal:30944 kB
MemFree: 1 kB
MemShared:   0 kB
Buffers: 0 kB
Cached:  11000 kB
Active:   4656 kB
Inact_dirty:  4220 kB
Inact_clean:  2124 kB
Inact_target:0 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:30944 kB
LowFree: 1 kB
SwapTotal:   0 kB
SwapFree:0 kB

# cat /proc/meminfo
total:used:free:  shared: buffers:  cached:
Mem:  31686656 24178688  750796800 12357632
Swap:000
MemTotal:30944 kB
MemFree:  7332 kB
MemShared:   0 kB
Buffers: 0 kB
Cached:  12068 kB
Active:   4560 kB
Inact_dirty:  5384 kB
Inact_clean:  2124 kB
Inact_target:   16 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:30944 kB
LowFree:  7332 kB
SwapTotal:   0 kB
SwapFree:0 kB

--
Stephen L Johnson  <[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: linux scheduler limitations?

[Fabio Riccardi]

I'm using 2.4.2-ac26, but I've noticed the same behavior with all the 2.4
kernels I've seen so far.

I haven't even tried on 2.2

 - Fabio

David Lang wrote:

> 2.2 or 2.4 kernel?
>
> the 2.4 does a MUCH better job of dealing with large numbers of processes.
>
> David Lang
>
> On Thu, 29 Mar 2001, Fabio Riccardi wrote:
>
> > Date: Thu, 29 Mar 2001 13:19:05 -0800
> > From: Fabio Riccardi <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: linux scheduler limitations?
> >
> > Hello,
> >
> > I'm working on an enhanced version of Apache and I'm hitting my head
> > against something I don't understand.
> >
> > I've found a (to me) unexplicable system behaviour when the number of
> > Apache forked instances goes somewhere beyond 1050, the machine
> > suddently slows down almost top a halt and becomes totally unresponsive,
> > until I stop the test (SpecWeb).
> >
> > Profiling the kernel shows that the scheduler and the interrupt handler
> > are taking most of the CPU time.
> >
> > I understand that there must be a limit to the number of processes that
> > the scheduler can efficiently handle, but I would expect some sort of
> > gradual performance degradation when increasing the number of tasks,
> > instead I observe that by increasing Apache's MaxClient linit by as
> > little as 10 can cause a sudden transition between smooth working with
> > lots (30-40%) of CPU idle to a total lock-up.
> >
> > Moreover the max number of processes is not even constant. If I increase
> > the server load gradually then I manage to have 1500 processes running
> > with no problem, but if the transition is sharp (the SpecWeb case) than
> > I end-up having a lock up.
> >
> > Anybody seen this before? Any clues?
> >
> >  - Fabio
> >
> >
> > -
> > 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: linux scheduler limitations?

[J . A . Magallon]

On 03.29 Fabio Riccardi wrote:
> 
> I've found a (to me) unexplicable system behaviour when the number of
> Apache forked instances goes somewhere beyond 1050, the machine
> suddently slows down almost top a halt and becomes totally unresponsive,
> until I stop the test (SpecWeb).
> 

Have you though about pthreads (when you talk about fork, I suppose you
say literally 'fork()') ?

I give a course on Parallel Programming at the university and the practical
work was done with POSIX threads. One of my students caught the idea and
used it to modify his assignment from one other matter on Networks, and
changed the traditional 'fork()' in a simple ftp server he had to implement
by 'pthread_create' and got a 10-30 speedup (conns per second).

And you will get rid of some process-per-user limit. But you will fall into
an threads-per-user limit, if there is any.

And you cal also control its scheduling, to make each thread fight against
the whole system or only its siblings.

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.2-ac28 #1 SMP Thu Mar 29 16:41:17 CEST 2001 i686

-
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 scheduler limitations?

[David Lang]

2.2 or 2.4 kernel?

the 2.4 does a MUCH better job of dealing with large numbers of processes.

David Lang

On Thu, 29 Mar 2001, Fabio Riccardi wrote:

> Date: Thu, 29 Mar 2001 13:19:05 -0800
> From: Fabio Riccardi <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: linux scheduler limitations?
>
> Hello,
>
> I'm working on an enhanced version of Apache and I'm hitting my head
> against something I don't understand.
>
> I've found a (to me) unexplicable system behaviour when the number of
> Apache forked instances goes somewhere beyond 1050, the machine
> suddently slows down almost top a halt and becomes totally unresponsive,
> until I stop the test (SpecWeb).
>
> Profiling the kernel shows that the scheduler and the interrupt handler
> are taking most of the CPU time.
>
> I understand that there must be a limit to the number of processes that
> the scheduler can efficiently handle, but I would expect some sort of
> gradual performance degradation when increasing the number of tasks,
> instead I observe that by increasing Apache's MaxClient linit by as
> little as 10 can cause a sudden transition between smooth working with
> lots (30-40%) of CPU idle to a total lock-up.
>
> Moreover the max number of processes is not even constant. If I increase
> the server load gradually then I manage to have 1500 processes running
> with no problem, but if the transition is sharp (the SpecWeb case) than
> I end-up having a lock up.
>
> Anybody seen this before? Any clues?
>
>  - Fabio
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

Re: [PATCH] pcnet32 compilation fix for 2.4.3pre6

[Ulrich Drepper]

[EMAIL PROTECTED] writes:

> with the new ansi standard, this use of __inline__ is no longer
> necessary,

This is not correct.  Since the semantics of inline in C99 and gcc
differ all code which depends on the gcc semantics should continue to
use __inline__ since this keyword will hopefully forever signal the
gcc semantics.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pcnet32 compilation fix for 2.4.3pre6

[Eli Carter]

Ulrich Drepper wrote:
> 
> [EMAIL PROTECTED] writes:
> 
> > with the new ansi standard, this use of __inline__ is no longer
> > necessary,
> 
> This is not correct.  Since the semantics of inline in C99 and gcc
> differ all code which depends on the gcc semantics should continue to
> use __inline__ since this keyword will hopefully forever signal the
> gcc semantics.

So what are the differences?  (Or, what would I read to learn the
differences?)
When are they important to us?

TIA,

Eli
---.   Rule of Accuracy: When working toward
Eli Carter |the solution of a problem, it always 
eli.carter(at)inet.com `-- helps if you know the answer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux scheduler limitations?

[Fabio Riccardi]

Hello,

I'm working on an enhanced version of Apache and I'm hitting my head
against something I don't understand.

I've found a (to me) unexplicable system behaviour when the number of
Apache forked instances goes somewhere beyond 1050, the machine
suddently slows down almost top a halt and becomes totally unresponsive,
until I stop the test (SpecWeb).

Profiling the kernel shows that the scheduler and the interrupt handler
are taking most of the CPU time.

I understand that there must be a limit to the number of processes that
the scheduler can efficiently handle, but I would expect some sort of
gradual performance degradation when increasing the number of tasks,
instead I observe that by increasing Apache's MaxClient linit by as
little as 10 can cause a sudden transition between smooth working with
lots (30-40%) of CPU idle to a total lock-up.

Moreover the max number of processes is not even constant. If I increase
the server load gradually then I manage to have 1500 processes running
with no problem, but if the transition is sharp (the SpecWeb case) than
I end-up having a lock up.

Anybody seen this before? Any clues?

 - Fabio


-
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] pcnet32 compilation fix for 2.4.3pre6

[dank]

Eli Carter wrote:
> Hmm... I used __inline__ because the other function in the same
> headerfile used it...  What is the difference between the two, and is
> one depricated now?  (And what about in 2.2.x?)

the inline keyword was not added into the c language until the ansi/iso
c99 revision, echoing its use in c++.  prior to that time, gcc supplied
__inline__ as a vendor extension simulating this behavior which could be
compiled without violating checks for strict ansi conformance. 

with the new ansi standard, this use of __inline__ is no longer
necessary, although for gcc to grok it as legal ansi requires (iirc) the
macro _ISOC99_SOURCE_ must be defined.

-- 
nick black * head developer, trellis network security * www.trellisinc.com
"the tao gave birth to machine language.  machine language gave birth to the
 assembler.  the assembler gave rise to the compiler.  now there are ten
 thousand languages.  each has its place, but avoid cobol if you can." - ttop
-
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.2 IDE data point

[Mike Castle]

I like to play with old junky hardware.  Except for disk drives.  I like
the storage.  As a result, I have a P5/233 with 250G across 5 IDE's.  It's
kludgy, yes, but it's fun.

Anyway, the 5th IDE drive (and cdrom) is on an old sound blaster card.
Depending on configuration, linux times out reading the partition table on
this drive.  I had the same problem with later 2.2.* kernels with recent
IDE patches.

The following table describes two items I have tracked it down to:

CONFIG_IDEPCI_SHARE_IRQ
   YESNO
+++
BIOSYES | fails  | fails  |
PNP-OS  NO  | fails  | works  |
+++

Below are the output of dmesg and my .config.  I can do just about any
other testing asked.

Oh, and even with this, it's not surprising to get:
hdd: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdd: irq timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdd: DMA disabled
ide1: reset: success
hdb: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdb: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdb: timeout waiting for DMA

Though I *suspect* this may be caused by bad cables.

mrc

30 BogoMIPS
Memory: 78320k/81920k available (938k kernel code, 3212k reserved, 364k data, 216k 
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 008001bf  , vendor = 0
Intel Pentium with F0 0F bug - workaround enabled.
CPU: After vendor init, caps: 008001bf   
CPU: After generic, caps: 008001bf   
CPU: Common caps: 008001bf   
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: none
CPU: Before vendor init, caps: 008001bf  , vendor = 0
CPU: After vendor init, caps: 008001bf   
CPU: After generic, caps: 008001bf   
CPU: Common caps: 008001bf   
CPU0: Intel Pentium MMX stepping 03
per-CPU timeslice cutoff: 159.61 usecs.
SMP motherboard not detected. Using dummy APIC emulation.
Setting commenced=1, go go go
PCI: PCI BIOS revision 2.10 entry at 0xfb000, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7000] at 00:07.0
Limiting direct PCI/PCI transfers.
Activating ISA DMA hang workarounds.
isapnp: Scanning for Pnp cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Calling quirk for 01:02
isapnp: AWE32 quirk - adding two ports
isapnp: Card 'Creative SB32 PnP'
isapnp: 1 Plug & Play card detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
block: queued sectors max/low 51872kB/17290kB, 192 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX3: IDE controller on PCI bus 00 dev 39
PIIX3: chipset revision 0
PIIX3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
ide3: Creative SB32 PnP IDE interface
hda: Maxtor 91303D6, ATA DISK drive
hdb: Maxtor 53073U6, ATA DISK drive
hdc: Maxtor 93652U8, ATA DISK drive
hdd: Maxtor 92048U8, ATA DISK drive
hdg: probing with STATUS(0x50) instead of ALTSTATUS(0xd0)
hdg: Maxtor 53073H6, ATA DISK drive
hdh: probing with STATUS(0x00) instead of ALTSTATUS(0x80)
hdh: HITACHI CDR-7930, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide3 at 0x168-0x16f,0x36e on irq 10
hda: 25450992 sectors (13031 MB) w/512KiB Cache, CHS=12624/32/63, (U)DMA
hdb: 60030432 sectors (30736 MB) w/2048KiB Cache, CHS=59554/16/63, (U)DMA
hdc: 71346240 sectors (36529 MB) w/2048KiB Cache, CHS=70780/16/63, (U)DMA
hdd: 39876480 sectors (20417 MB) w/2048KiB Cache, CHS=39560/16/63, (U)DMA
hdg: 60030432 sectors (30736 MB) w/2048KiB Cache, CHS=59554/16/63
Partition check:
 hda: hda1 hda2 hda3 hda4
 hdb: hdb1 hdb2 hdb3
 hdc: [PTBL] [4441/255/63] hdc1 hdc2 hdc3 hdc4 < hdc5 hdc6 hdc7 hdc8 >
 hdd: hdd1 hdd2 hdd3
 hdg: hdg1 hdg2 hdg3 hdg4 < hdg5 hdg6 hdg7 >
Real Time Clock Driver v1.10d
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
ACPI: System description tables not found
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel 

Re: Linux connectivity trashed.

[Roger Larsson]

Hi,

I assume that it is ok to sue any company that forwards viruses too...
(not only the author...)

Are Raytheon suing the company were you work, or some
unknown/unnamed company made up by Microsoft?
(you were not specific about this)

/RogerL

On Thursday 29 March 2001 15:34, Richard B. Johnson wrote:
> This is for information only.
>
> Last week a standard RH distribution of  Linux was rooted from what looks
> like a Russian invasion. The penetration used the method taught in the CERT
> Advisory CA-2000-17.
>
> The intruder(s) then attempted  to perform additional penetrations from
> this site. One of  the sites attacked was alleged to be Raytheon. Raytheon
> makes products for national security such as guided missiles.
>
> I was told that Raytheon is now suing this company.  Therefore all Linux
> machines
> are being denied access to the Internet.

>
> The penetration occurred because somebody changed our  firewall
> configuration
> so that all of the non-DHCP addresses, i.e., all the real IP addresses had
> complete
> connectivity to the outside world. This meant that every Linux and Sun
> Workstation
> in this facility was exposed to tampering from anywhere in the world. This
> appears
> to be part of a plan to remove all non-DHCP machines by getting them
> trashed.
> In other words, we were set up to take a hard fall because no machine that
> allows
> NFS mounts  can be safely exposed to the outside world without blocking
> portmap.
>
> There is a concerted effort to eliminate both Sun Workstations and Linux
> machines
> as tools in this facility. This happens as the "yuppies",  who have never,
> ever, contributed
> to product development are Peter-Principled into positions of authority.
>
> The email addresses of  those who have declared that only Windows machines
> will
> be allowed access to the outside world are:
>
> Thor T. Wallace   [EMAIL PROTECTED]
> David Pothier   [EMAIL PROTECTED]
>
> David Pothier was a beta tester for Windows/NT. Of course he wants all
> machines to
> be Windows and,  naturally, under his control.
>
> Thor Wallace is our new "security" administrator so I am told.
>
> The only  Linux  advocate in a position of authority is:
>
>Alex Shekhel[EMAIL PROTECTED]
>
> So,  now I hooked up my lap-top,  installed Windows and here I am. 
> Only windows
> machines are allowed to access the outside world.
>
>
> Cheers,
>
> Richard B. Johnson
> Formally [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/

-- 
Roger Larsson
Skellefteå
Sweden
-
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: WG: 2.4 on COMPQ Proliant

[Gérard Roudier]

On Thu, 29 Mar 2001, Butter, Frank wrote:

> 2.2.16 claimes to find a ncr53c1510D-chipset, supported by
> the driver ncr53c8xx. Which kernel-param would be the correct one for this?

There is no specific kernel option apart configuring the NCR53C8XX and/or
the SYM53C8XX driver. (And not the 53c7,8xx driver as I have to repeat
since 5 years).

For the 53c1510D, you must ensure that the chip is configured for behaving
as a 53c8xx chip (and not as an intelligent controller).
To know about the 1510 configuration, you may check the PCI device id
claimed by the chip. Value 0xa is the expected value if the chip is
configured for 53c8xx mode.

Btw, I donnot know how to change the 1510 from intelligent mode to 53c8xx
mode and vice-versa. You may ask your vendor for that.

  Gérard.

> Frank
> 
> > -Ursprüngliche Nachricht-
> > Von: Butter, Frank 
> > Gesendet: Donnerstag, 29. März 2001 17:11
> > An: '[EMAIL PROTECTED]'
> > Betreff: 2.4 on COMPQ Proliant
> > 
> > 
> > 
> > Has anyone experiences with 2.4.x on recent Compaq Proliant 
> > Servers (e.g. ML570)?
> > 
> > I've installed RedHat7 and it worked fine out of the box.
> > Except that the SMP-enabled kernel stated there was no 
> > SMP-board detected ;-/
> > For some reasons (Fibrechannel drivers and so on) I've compiled
> > 2.4.2 and installed it. Although I've compiled the support 
> > in, the NCR-SCSI-chip was not found and therefore no 
> > root-partition. It is a model supported by 53c8xx - detected 
> > by the original RedHat-kernel.  
> > 
> > For testing I compiled a kernel with all (!) scsi-low-level-drivers -
> > with the same result. The SMP-board also was NOT detected by 2.4.2.
> > 
> > Any hint?
> > 
> > Frank
> > 
> -
> 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: Mount locks on bad ISO image?

[Aaron Lunansky]

I'm running 2.4.2 so it's probably just the broken loop device.


Thanks,
Aaron


-Original Message-
From: Guest section DW [mailto:[EMAIL PROTECTED]]
Sent: March 29, 2001 15:13
To: Aaron Lunansky; [EMAIL PROTECTED]
Subject: Re: Mount locks on bad ISO image?


On Thu, Mar 29, 2001 at 02:16:03PM -0500, Aaron Lunansky wrote:
> I tried mounting a file as an ISO image (turns out it was corrupted) -
after
> running mount file.iso /cdrom -o loop
> mount hung and did not respond.. I could not ^Z it into the background, or
> kill, or kill -9 it...
> 
> I'm certain that I have ISO and loopback support compiled into my kernel.
> 
> Anyone know what might be going on?

Answer 1: in 2.4.2 the loop device does not work
 (but things are better in the -ac patches).
Answer 2: the kernel tends to believe filesystem data,
 and a corrupted filesystem can seriously confuse the kernel.

If you make sure that the problem does not lie in loop
(you can mount other images without problems), then
I wouldnt mind seeing your image (or rather, the first
MB or two of it) to see whether the isofs code must be
improved. (In that case, put some smallish fragment up for ftp
and mail the URL to [EMAIL PROTECTED] Don't mail cd images.)

Andries
-
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: Mount locks on bad ISO image?

[Guest section DW]

On Thu, Mar 29, 2001 at 02:16:03PM -0500, Aaron Lunansky wrote:
> I tried mounting a file as an ISO image (turns out it was corrupted) - after
> running mount file.iso /cdrom -o loop
> mount hung and did not respond.. I could not ^Z it into the background, or
> kill, or kill -9 it...
> 
> I'm certain that I have ISO and loopback support compiled into my kernel.
> 
> Anyone know what might be going on?

Answer 1: in 2.4.2 the loop device does not work
 (but things are better in the -ac patches).
Answer 2: the kernel tends to believe filesystem data,
 and a corrupted filesystem can seriously confuse the kernel.

If you make sure that the problem does not lie in loop
(you can mount other images without problems), then
I wouldnt mind seeing your image (or rather, the first
MB or two of it) to see whether the isofs code must be
improved. (In that case, put some smallish fragment up for ftp
and mail the URL to [EMAIL PROTECTED] Don't mail cd images.)

Andries
-
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: opl3sa2 in 2.4.2 on Toshiba Tecra 8000

[Klaus Reimer]

Hi,

> > Hm, OK, then never mind. :) I don't have an opl3sa2 here to test
> > how well the current driver works.
> I have the feeling that there is going something wrong with the parameters.
> I modified the opl3sa2 driver and manually set the hw_config->io_base
> variable to 0x538 and now THIS part of the sound card initialization is
> working. But now it says that there is an I/O conflict with MSS. Maybe this
> parameter is also 0x0 and not  0x530 as I specified with the mss_io
> parameter... I will investigate further...

Hm... I found this somewhere near line 920 in opl3sa2.c. I am not a kernel 
hacker and this is first time I took a look into a kernel source code but 
this first "if" statement is not looking right to me. The initialization of 
the cfg[card] struct is what I need to be executed, but it is never executed 
because the variable "io" is never -1. I have removed the io == -1 condition 
from the first if-statement and now the driver is working. But it's still not 
the same quality as the one in kernel 2.2.17: I have no access to the mixer 
settings "bass" and "treble". But better than nothing and better than the 
8Bit-Soundblaster emulation. I hope this is working better in the next 
release.

if(!isapnp && io == -1 ) {
if(io == -1 || irq == -1 || dma == -1 ||
   dma2 == -1 || mss_io == -1) {
printk(KERN_ERR
   "opl3sa2: io, mss_io, irq, dma,  [...]
return -EINVAL;
}
 
cfg[card].io_base = io;
cfg[card].irq = 0;
cfg[card].dma = -1;
cfg[card].dma2= -1;
[]

-- 
Bye, K
[a735 47ec d87b 1f15 c1e9 53d3 aa03 6173 a723 e391]
(Finger [EMAIL PROTECTED] to get public key)
-
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/

Obtaining new Device Numbers

[tom_gall]

Hi All,

  According to Documentation/devices.txt to request new major / numbers, all you
should have to do is get ahold of H. Peter Anvin.

  Does anybody know if he is still doing this? Perhaps has he passed this duty
on to someone else? It would appear he isn't answering requests mailed to
[EMAIL PROTECTED]

  I'm trying to get the major / minor number issues resolved for the Linux port
to the IBM AS/400 aka iSeries. We have released our first set of patches and
before we put out the next set we'd like to get this nailed down as we're using
bogus major / minor numbers that we just grabbed out of mid-air... obviously not
the right thing.

  For those interested in the patches, take a gander to
oss.software.ibm.com/developerworks/opensource/linux/projects/ppc/iSeries_notes.php

  Thanks much for any info!

  Regards,

  Tom
-- 
Tom Gall - PowerPC Linux Team"Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://oss.software.ibm.com/developerworks/opensource/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OOM killer???

[Jesse Pollard]

avid Lang <[EMAIL PROTECTED]>:
>one of the key places where the memory is 'allocated' but not used is in
>the copy on write conditions (fork, clone, etc) most of the time very
>little of the 'duplicate' memory is ever changed (in fact most of the time
>the program that forks then executes some other program) on a lot of
>production boxes this would be a _very_ significant additional overhead in
>memory (think a busy apache server, it forks a bunch of processes, but
>currently most of that memory is COW and never actually needs to be
>duplicated)

So? If the requirement is no-overcommit, then assume it WILL be overwritten.
Allocate sufficient swap for the requirement.

Now, it shouldn't be necessary to include the text segment - after all
this should be marked RX.

Actually just X would do, but on Intel systems that also means R. and if W
is set it also means RWX. I hope that Intel gets a better clue about memory
protection sometime soon.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

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

Re: Bug in the file attributes ?

[Jesse Pollard]

-  Received message begins Here  -

> 
> 
> Hi,
> 
> I just made a manipulation that disturbs me. So I'm asking whether it's a
> bug or a features.
> 
> user> su
> root> echo "test" > test
> root> ls -l
> -rw-r--r--   1 root root5 Mar 29 19:14 test
> root> exit
> user> rm test
> rm: remove write-protected file `test'? y
> user> ls test
> ls: test: No such file or directory
> 
> This is in the user home directory.
> Since the file is read only for the user, it should not be able to remove
> it. Moreover, the user can't write to test.
> So I think this is a bug.

Nope - rm only updates the directory, which the user owns; not the file.
The prompt is just being nice.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
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/

Mount locks on bad ISO image?

[Aaron Lunansky]

I tried mounting a file as an ISO image (turns out it was corrupted) - after
running mount file.iso /cdrom -o loop
mount hung and did not respond.. I could not ^Z it into the background, or
kill, or kill -9 it...

I'm certain that I have ISO and loopback support compiled into my kernel.

Anyone know what might be going on?


Regards,
Aaron
-
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: opl3sa2 in 2.4.2 on Toshiba Tecra 8000

[Klaus Reimer]

Hi,

> > Control I/O: 0x538
> > MPU I/O: 0x330
> Hm, OK, then never mind. :) I don't have an opl3sa2 here to test
> how well the current driver works.

I have the feeling that there is going something wrong with the parameters. I 
modified the opl3sa2 driver and manually set the hw_config->io_base variable 
to 0x538 and now THIS part of the sound card initialization is working. But 
now it says that there is an I/O conflict with MSS. Maybe this parameter is 
also 0x0 and not  0x530 as I specified with the mss_io parameter... I will 
investigate further...

-- 
Bye, K
[a735 47ec d87b 1f15 c1e9 53d3 aa03 6173 a723 e391]
(Finger [EMAIL PROTECTED] to get public key)
-
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 connectivity trashed.

[Doug Ledford]

John Jasen wrote:
> 
> On Thu, 29 Mar 2001, Richard B. Johnson wrote:
> 
> >snipped<

>more snippage<

> In short, your security administrator needs to be dragged out, shot, and
> left hanging by the front door as a warning to his replacement.
> 
> Or, at least fired.

That, or have all the Unix using/loving people at Analogic turn in their
resignations.  When IS takes on too much of a Gestapo air about them, the only
thing to do is leave them to do not only all the administration, but all the
development as well.  It's usually about then that CEOs actually pay attention
to how much distress IS is causing the rest of the company and give them a
swift kick in the ass to straighten things out (assuming you have a CEO worth
a damn, that assumption could be totally wrong).

-- 

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

Re: Bug in the file attributes ?

[John Jasen]

On Thu, 29 Mar 2001, Xavier Ordoquy wrote:

> OK, thanks for the answer.
> I've spoken to a few people before and they hadn't heard about it.
> Since once upon the time on a solaris system I've had a root file that I
> couldn't remove even if I hold the rights of the directory.
> This is why I figured out this was a bug.
> Anyway, thanks for that.

I think, I could very easily be mistaken, tho', that being able to do this
is part of posix compliance.

--
-- John E. Jasen ([EMAIL PROTECTED])
-- In theory, theory and practise are the same. In practise, they aren't.

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

Re: Bug in the file attributes ?

[Justin Carlson]

On Thu, 29 Mar 2001, Xavier Ordoquy wrote:
> Hi,
> 
> I just made a manipulation that disturbs me. So I'm asking whether it's a
> bug or a features.
> 
> user> su
> root> echo "test" > test
> root> ls -l
> -rw-r--r--   1 root root5 Mar 29 19:14 test
> root> exit
> user> rm test
> rm: remove write-protected file `test'? y
> user> ls test
> ls: test: No such file or directory
> 
> This is in the user home directory.
> Since the file is read only for the user, it should not be able to remove
> it. Moreover, the user can't write to test.
> So I think this is a bug.

You don't need write perms on a file to remove it, you need write perms on the
directory.  If you've got write permissions on the directory, you can remove
any file in the directory, regardless of the permissions.

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

Re: Bug in the file attributes ?

[Xavier Ordoquy]

OK, thanks for the answer.
I've spoken to a few people before and they hadn't heard about it.
Since once upon the time on a solaris system I've had a root file that I 
couldn't remove even if I hold the rights of the directory.
This is why I figured out this was a bug.
Anyway, thanks for that.

---
 Xavier Ordoquy, Aurora-linux
 If NT is the answer, you didn't understand the question.

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

Re: Bug in the file attributes ?

[Andreas Dilger]

Xavier Ordoquy writes:
> I just made a manipulation that disturbs me. So I'm asking whether it's a
> bug or a features.
> 
> user> su
> root> echo "test" > test
> root> ls -l
> -rw-r--r--   1 root root5 Mar 29 19:14 test
> root> exit
> user> rm test
> rm: remove write-protected file `test'? y
> user> ls test
> ls: test: No such file or directory
> 
> This is in the user home directory.
> Since the file is read only for the user, it should not be able to remove
> it. Moreover, the user can't write to test.

This is definitely not a bug.  Deleting a file (under *nix) does not
"modify" the file at all, it is modifying the directory where the file
resides.  In this case, a user _will_ have permission to write into
their home directory, so they can delete the file, but not modify it.

Why do such a thing?  If you have group/world write permission on a
directory, then people who have write permission to the _directory_
should be able to delete files even if they don't own them.  However,
if you set the "sticky" bit on the directory (chmod +t /dir), then only
the owner of the file can delete it, like in /tmp.

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/

insmod message explanation

[clock]

insmod g_NCR5380 ncr_addr=0xcc000 ncr_irq=255 ncr_53c400a=1

Using /lib/modules/2.2.19/scsi/g_NCR5380.o
scsi : 0 hosts.
/lib/modules/2.2.19/scsi/g_NCR5380.o: init_module: Device or resource busy
Hint: this error can be caused by incorrect module parameters, including invalid IO or 
IRQ parameters

Which device is busy? Or which resource is busy? Printer? hard drive? Or what?
is init_module some kind of device or even maybe a resource?

What stage did the process of inserting the module get into? Has the init_module
been completed?

Thanks in advance for answering these questions.

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

Re: Bug in the file attributes ?

[Stephen Clouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Mar 29, 2001 at 08:20:32PM +, Xavier Ordoquy wrote:
> This is in the user home directory.
> Since the file is read only for the user, it should not be able to remove
> it. Moreover, the user can't write to test.
> So I think this is a bug.

You have failed to RTFM.  There is no bug here.

http://www.linuxdoc.org/FAQ/Linux-FAQ/x1955.html#AEN2242

- -- 
Stephen Clouse <[EMAIL PROTECTED]>
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8

iQA/AwUBOsOC1gOGqGs0PadnEQJtVwCgm23nRu0O14SwWvxjZDulld8m24YAn2vb
yHGvzJR10oC1dabikTezfX+3
=TlMz
-END PGP SIGNATURE-
-
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: opl3sa2 in 2.4.2 on Toshiba Tecra 8000

[Bill Nottingham]

Klaus Reimer ([EMAIL PROTECTED]) said: 
> Hi,
> 
> > > modprobe opl3sa2 io=0x538 mss_io=0x530 mpu_io=0x330 irq=5 dma=1 dma2=0
> > > isapnp=0
> > It would be what you put in the io= parameter. 0x538 does *not* look
> > right.
> 
> These are the sound-settings in the BIOS:
> 
> WSS I/O: 0x530
> SBPro I/O: 0x220
> Synth I/O: 0x388
> IRQ: 5
> WSS (Play) DMA: 1
> WSS (Rec) DMA & SBPro-DMA: 0
> Control I/O: 0x538
> MPU I/O: 0x330

Hm, OK, then never mind. :) I don't have an opl3sa2 here to test
how well the current driver works.

Bill
-
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: Incorrect mdelay() results on Power Managed Machines x86

[Woller, Thomas]

i talked with Keith Frechette at IBM, he is in charge of Linux for IBM.  he
indicated that they are working issues with INTEL speedstep and Linux for
their newer laptops, albeit not at a swift pace.  he will probably contact
the linux community at some point to help solve issues with SpeedStep, but
he affirms that INTEL treats this information as proprietary, so not sure
how much work can be done for linux.  he also indicated that some of the
older IBM models did some non-standard manipulation with the CPU speed at
runtime, e.g. what I am seeing with mdelay failing if booting on a 600X on
battery power.  most likely, no event notification would be available for
any of these CPU speed manipulations.  
I am going to send some info on the issue to Keith, and he is going to
forward to the technical IBM folks somewhere at IBM, but any solution would
most likely be specific to IBM for the cs46xx audio driver.  
It does sound like the PM timer is the best idea so far.
Tom
[EMAIL PROTECTED]

> -Original Message-
> From: Alan Cox [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 10:11 PM
> To:   [EMAIL PROTECTED]
> Cc:   [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject:  Re: Incorrect mdelay() results on Power Managed Machines x86
> 
> > I know on ACPI systems you are guaranteed a PM timer running at ~3.57
> Mhz.
> > Could udelay use that, or are there other timers that are better (maybe
> > without the ACPI dependency)? 
> 
> We could use that if ACPI was present. It might be worth exploring. Is
> this
> PM timer well defined for accesses  ?
-
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: opl3sa2 in 2.4.2 on Toshiba Tecra 8000

[Klaus Reimer]

Hi,

> > modprobe opl3sa2 io=0x538 mss_io=0x530 mpu_io=0x330 irq=5 dma=1 dma2=0
> > isapnp=0
> It would be what you put in the io= parameter. 0x538 does *not* look
> right.

These are the sound-settings in the BIOS:

WSS I/O: 0x530
SBPro I/O: 0x220
Synth I/O: 0x388
IRQ: 5
WSS (Play) DMA: 1
WSS (Rec) DMA & SBPro-DMA: 0
Control I/O: 0x538
MPU I/O: 0x330

The BIOS does not let me modify the I/O settings for Synth, Control and MPU. 
And as I said: The opl3sa2 module was working perfectly in kernel 2.2.17 with 
these settings. And I wonder why the message in syslog says "0x0", no matter 
what I/O address I have specified with the io= parameter.

-- 
Bye, K
[a735 47ec d87b 1f15 c1e9 53d3 aa03 6173 a723 e391]
(Finger [EMAIL PROTECTED] to get public key)
-
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/

Bug in the file attributes ?

[Xavier Ordoquy]

Hi,

I just made a manipulation that disturbs me. So I'm asking whether it's a
bug or a features.

user> su
root> echo "test" > test
root> ls -l
-rw-r--r--   1 root root5 Mar 29 19:14 test
root> exit
user> rm test
rm: remove write-protected file `test'? y
user> ls test
ls: test: No such file or directory

This is in the user home directory.
Since the file is read only for the user, it should not be able to remove
it. Moreover, the user can't write to test.
So I think this is a bug.

---
 Xavier Ordoquy, Aurora-linux
 If NT is the answer, you didn't understand the question.

-
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: 2.4.3-p8 pci_fixup_vt8363 + ASUS A7V "Optimal" = IDE diskcorruption

[Wayne Whitney]

On 29 Mar 2001, Juan Quintela wrote:

> Hi I have the same motherboard and BIOS version.  I was having
> filesystem corruption.  There is a bugfix (from Arjan van der Ven) in
> the ac tree (around ac20 I think), could you test the last ac patch
> and test if the filesystem corruption persist??

I took a look at 2.4.2-ac28; rather than test the kernel itself, I used
setpci to duplicate what the fixup function does.  The upshot is that
2.4.2-ac28 does not cause any corruption with the ASUS A7V 1007 "Optimal".
Its pci_fixup_vt8363 function has a subset of the tests from 2.4.3-pre8,
namely it omits:

pci_read_config_byte(d, 0x54, );
if(tmp & (1)) {
printk("PCI: Fast Write to Read turnaround disabled\n");
pci_write_config_byte(d, 0x54, tmp & ~(1));
}
pci_read_config_byte(d, 0x70, );
if(tmp & (1<<2)) {
printk("PCI: Disabled Master Read Caching\n");
pci_write_config_byte(d, 0x70, tmp & ~(1<<2));
}

This second test was part of the 2.4.3-pre8 pci_fixup_vt8363 subset from
my previous email which causes corruption on the ASUS A7V 1007 for both
Optimal and Normal settings.  I verified that if I add it back in, I do
get corruption with ASUS A7V 1007 "Optimal".  By omitting it, I guess
2.4.2-ac28 avoids the corruption of 2.4.3-pre8.

Perhaps 2.4.3-pre9 should adopt the pci_fixup_vt8363 from 2.4.2-ac28?
Below is a patch.

Cheers,
Wayne

--- linux-2.4.3-pre8/arch/i386/kernel/pci-pc.c  Wed Mar 28 22:56:04 2001
+++ linux-2.4.2-ac28/arch/i386/kernel/pci-pc.c  Wed Mar 28 22:51:00 2001
@@ -968,23 +971,13 @@
printk("PCI: Bus master Pipeline request disabled\n");
pci_write_config_byte(d, 0x54, tmp & ~(1<<2));
}
-   pci_read_config_byte(d, 0x54, );
-   if(tmp & (1)) {
-   printk("PCI: Fast Write to Read turnaround disabled\n");
-   pci_write_config_byte(d, 0x54, tmp & ~(1));
-   }
pci_read_config_byte(d, 0x70, );
if(tmp & (1<<3)) {
printk("PCI: Disabled enhanced CPU to PCI writes\n");
pci_write_config_byte(d, 0x70, tmp & ~(1<<3));
}
-   pci_read_config_byte(d, 0x70, );
-   if(tmp & (1<<2)) {
-   printk("PCI: Disabled Master Read Caching\n");
-   pci_write_config_byte(d, 0x70, tmp & ~(1<<2));
-   }
pci_read_config_byte(d, 0x71, );
-   if ((tmp & (1<<3))==0) {
+   if((tmp & (1<<3)) == 0) {
printk("PCI: Bursting cornercase bug worked around\n");
pci_write_config_byte(d, 0x71, tmp | (1<<3));
}

-
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: OOM killer???

[David Lang]

one of the key places where the memory is 'allocated' but not used is in
the copy on write conditions (fork, clone, etc) most of the time very
little of the 'duplicate' memory is ever changed (in fact most of the time
the program that forks then executes some other program) on a lot of
production boxes this would be a _very_ significant additional overhead in
memory (think a busy apache server, it forks a bunch of processes, but
currently most of that memory is COW and never actually needs to be
duplicated)

David Lang


 On Thu, 29 Mar
2001, David Konerding wrote:

> Date: Thu, 29 Mar 2001 07:41:44 -0800
> From: David Konerding <[EMAIL PROTECTED]>
> To: Guest section DW <[EMAIL PROTECTED]>
> Cc: Dr. Michael Weller <[EMAIL PROTECTED]>,
>  Andreas Dilger <[EMAIL PROTECTED]>,
>  Szabolcs Szakacsits <[EMAIL PROTECTED]>,
>  Martin Dalecki <[EMAIL PROTECTED]>,
>  Ingo Oeser <[EMAIL PROTECTED]>,
>  Jonathan Morton <[EMAIL PROTECTED]>,
>  Rogier Wolff <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: OOM killer???
>
> I would tend to agree, I'm not a fan of the OOM killer's behavior.  The OOM is forced
> because of the policy of overcommitting of memory.  The reason for that policy is
> based on an observation:
> many programs allocate far more memory than they ever use, and most people don't want
> their program to crash just because it malloc()s memory it isn't going to use.
> Having to activate the pages for memory that never gets used feels wasteful to some
> people.  On the other hand, having my two-week-running scientific app killed because
> it did a whole bunch of disk reads that fill up 600MB of my 768MB RAM, then tried to
> allocate a whole bunch more memory (that it *will* use) is obviously a fault of the
> OOM killer policy. At the very least the entire disk cache, or a goodly portion of
> it, should be drained before ever invoking the OOM.  I'm more than glad to pay the
> performance hit of no disk buffers for the privilege of having my job finish.
>
> Now, if you're going to implement OOM, when it is absolutely necessary, at the very
> least, move the policy implementation out of the kernel.  One of the general
> philosophies of Linux has been to move policy out of the kernel.  In this case, you'd
> just have a root owned process with locked pages that can't be pre-empted, which
> implemented the policy.  You'll never come up with an OOM policy that will fit
> everybody's needs unless it can be tuned for  particular system's usage, and it's
> going to be far easier to come up with that policy if it's not in the kernel.
>
>
>
> Guest section DW wrote:
>
>
> > Two things are wrong.
>
> > 1. Linux has an OOM killer.
> > 2. The OOM killer has a bad behaviour.
> >
> > Presently, with the proper kind of load, one can see a process killed
> > by OOM almost daily. That is totally unacceptable.
> > People are working on refining the algorithm so that blatant idiocies
> > where processes are killed while there is plenty of resources
> > are avoided. Good. Suppose it done. Then one thing is wrong.
> >
> > 1. Linux has an OOM killer.
> >
> > A system with an OOM killer is unreliable. Linux must have a reliable
> > mode of operation, and that must be the default mode.
> >
> > Now you assume that adding SIGDANGER would make people happy.
> > But it would be a rather unimportant addition.
> > It might help in some cases, but it falls in the category
> > of improving the OOM killer a little.
> >
> > People will be happy when Linux is reliable by default.
> >
> > Andries
> >
> > [Never use planes where the company's engineers spend their
> > time designing algorithms for selecting which passenger
> > must be thrown out when the plane is overloaded.]
> > -
> > 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/
>

-
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: question on ip_masq_irc.c

[S. Shore]

On Thu, 29 Mar 2001, Deja User wrote:
> I am working on a NAT product and trying provide mIRC support in it. I am looking 
>into ip_masq_irc.c file of Linux 2.2.12 for reference, and have some doubts.
> 1. In 2.2.12 ip_masq_irc.c, DCC RESUME protocol is not supported. In which patch can 
>I find it?
> 2. I have pre-patch-2.2.18-5 linux.18p5/net/ipv4/ip_masq_irc.c, which has support 
>for DCC RESUME. Is this the final patch? I have checked with documentation in mIRC 
>help files about DCC RESUME command string. It says the command string in the pay 
>load looks
>DCC RESUME filename port position
>But, in the above file, the string hunted is
>"\1DCC RESUME chat  P\1\n"

You're right, it's broken. I submitted a patch for people to test, but
somehow it got into the production kernel without testing.

I created a second patch shortly after realizing the problem, tested and
submitted it, but it doesn't look like it ever made it in.

I'm including the patch. It's a diff against the ip_masq_irc.c from 2.2.17
(which was current at the time), so you may have to get this file
seperately if you're not using 2.2.17. Many apologies.

Scottie Shore| "Experience is the worst teacher -
<[EMAIL PROTECTED]>   |  it teaches you what you need to know
 |  after you needed to know it."

--- ip_masq_irc.c.orig  Wed Sep 27 22:07:15 2000
+++ ip_masq_irc.c   Sun Oct  1 21:30:41 2000
@@ -20,9 +20,11 @@
  * Juan Jose Ciarlante :  put new ms entry to listen()
  * Scottie Shore   :  added support for clients that add extra args
  *   <[EMAIL PROTECTED]>
+ * Scottie Shore   :  added support for mIRC DCC resume negotiation
+ *   <[EMAIL PROTECTED]>
  *
- * FIXME:
- * - detect also previous "PRIVMSG" string ?.
+ * FIXME: take common code from ip_masq_in and ip_masq_out, put into seperate
+ *function
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -78,22 +80,24 @@
  * List of supported DCC protocols
  */

-#define NUM_DCCPROTO 5
+#define NUM_DCCPROTO 6

 struct dccproto
 {
   char *match;
   int matchlen;
+  int addr;
 };

 struct dccproto dccprotos[NUM_DCCPROTO] = {
- { "SEND ", 5 },
- { "CHAT ", 5 },
- { "MOVE ", 5 },
- { "TSEND ", 6 },
- { "SCHAT ", 6 }
+ { "SEND ", 5, 1 },
+ { "CHAT ", 5, 1 },
+ { "MOVE ", 5, 1 },
+ { "TSEND ", 6, 1 },
+ { "SCHAT ", 6, 1 },
+ { "ACCEPT ", 7, 0 },
 };
-#define MAXMATCHLEN 6
+#define MAXMATCHLEN 7

 static int
 masq_irc_init_1 (struct ip_masq_app *mapp, struct ip_masq *ms)
@@ -118,7 +122,7 @@
char *data, *data_limit;
__u32 s_addr;
__u16 s_port;
-   struct ip_masq *n_ms;
+   struct ip_masq *n_ms = NULL;
char buf[20];   /* "m_addr m_port" (dec base)*/
 unsigned buf_len;
int diff;
@@ -137,16 +141,18 @@
 *  strlen("\1DCC SEND F  P S\1\n")=26
 *  strlen("\1DCC MOVE F  P S\1\n")=26
 *  strlen("\1DCC TSEND F  P S\1\n")=27
+*  strlen("\1DCC ACCEPT F P O\1\n")=19
 *  A: bound addr (1.0.0.0==16777216, min 8 digits)
 *  P: bound port (min 1 d )
 *  F: filename   (min 1 d )
 *  S: size   (min 1 d )
+*  O: offset (min 1 d )
 *  0x01, \n:  terminators
  */

 data_limit = skb->h.raw + skb->len;

-   while (data < (data_limit - ( 22 + MAXMATCHLEN ) ) )
+   while (data < (data_limit - ( 12 + MAXMATCHLEN ) ) )
{
int i;
if (memcmp(data,"\1DCC ",5))  {
@@ -171,52 +177,60 @@
 *  skip next string.
 */

-   while( *data++ != ' ')
+   while ( *data++ != ' ')
+   if (data > (data_limit-5)) return 0;
+   addr_beg_p = data;

+   if (dccprotos[i].addr == 1)
+   {
/*
-*  must still parse, at least, " 
P\1\n",
-*  12 bytes left.
+*  client bound address in dec base
 */
-   if (data > (data_limit-12)) return 0;
-
-
-   addr_beg_p = data;

-   /*
-*  client bound address in dec base
-*/
-
-   s_addr = simple_strtoul(data,,10);
-   if (*data++ !=' ')
- 

[PATCH] Support for "mode" parameter in ramfs

[Pavel Roskin]

Hello!

This patch adds support for the "mode" parameter in ramfs. This parameter
only affects one inode - the top-level directory (since you can specify
mode in open() and mkdir() for everything else) and thus eliminates the
race condition between "mount" and "chmod" by eliminating the need to use
"chmod".

Like other filesystems, the "mode" is parsed as an octal number.

It is now possible to put the following line in /etc/fstab:

none  /tmp ramfs mode=1777 0 0

but please make sure that untrusted users cannot kill your system by
creating huge files in /tmp!

The patch is also available online at
http://www.red-bean.com/~proski/linux/root_mode.diff

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/

[ANNOUNCE] Linux Trace Toolkit 0.9.5pre1

[Karim Yaghmour]

LTT 0.9.5pre1 is out.

As the name says, this is a development version and should be
treated as such. Only one kernel is supported with 0.9.5pre1,
linux 2.4.0-test10.

What it includes:
-Cross-platform reading capability submitted by Andy Lowe
-Visualizer enhancements submitted by Rocky Craig
-Patch fixes by Peng Dai and Bob Montgomery
-Many bug fixes seen using the "-Wall" flag to build the user tools

The trace format has changed again to support cross-platform
reading capabilities.

0.9.5pre1 has no support for RTAI. pre2 will include the cross-
platform capabilities for RTAI.

Here's what should be in pre2:
-Support for 2.2.18/2.4.2
-Support for the latest RTAI, including cross-platform capabilities
-Benchmark fixes from Rocky Craig
-SH support by Greg Banks

Check the project's web-site for details on 0.9.5pre1:
http://www.opersys.com/LTT

Cheers,

Karim

===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Embedded and Real-Time Linux Expert
===
-
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/

Panic after using bonding driver

[Jeff Golds]

I have been working on a driver similar to the bonding driver and have
come across a bug in the bonding driver code.  When the bonding driver
enslaves a device, it modifies the slave's multicast list to be the
master's multicast list.  Later, after the master is downed, the kernel
gets a panic if you try to down the slave device.

To get around this problem, there are two solutions that I see:

1)  Don't do multicasting for bonding devices
While this works (I've tested) some peple might call this a serious
limitation.
2)  Keep track of the slave's multicast list
This would require keeping a copy of the slave's pointer and restoring
it when the bonding
device is downed.  Not sure if this would even work since the slave's
multicast list might
be stale by the time it is restored.

I'd like to get this fixed in the best possible way.  What are your
folks comments in regard to the matter?


-Jeff


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

Re: OOM killer???

[Stephen Satchell]

At 07:41 AM 3/29/01 -0800, David Konerding wrote:
>Now, if you're going to implement OOM, when it is absolutely necessary, at 
>the very
>least, move the policy implementation out of the kernel.  One of the general
>philosophies of Linux has been to move policy out of the kernel.  In this 
>case, you'd
>just have a root owned process with locked pages that can't be pre-empted, 
>which
>implemented the policy.  You'll never come up with an OOM policy that will fit
>everybody's needs unless it can be tuned for  particular system's usage, 
>and it's
>going to be far easier to come up with that policy if it's not in the kernel.

SUMMARY OF COMMENT:  We need kernel support for such a userland 
process.  At a minimum, I believe we would need a means to steer term 
signals and kill signals to the correct process in a process tree, a means 
for processes to receive notification that the system is in trouble, and 
that the policy be set and the OOM killer be implemented in a daemon that 
accepts input directly from the admin in a config file, from the memory 
system via suitable interfaces, and from the processes via communications 
(probably through the process control block).  SIGDANGER needs to be 
defined, but never raised by the kernel.  There also needs to be a means 
for the OOM daemon to request the release of non-critical cache buffers

Comment follows:

I'm in basic agreement with your sentiments, but I'm concerned about how a 
userland policy system will work without some support within the 
kernel.  The support also needs to be well-enough defined that applications 
can be written to work with the policy manager.

Let's start with Oracle, as one of the examples that keeps being brought 
up.  How does Oracle deal with the problem?  Part of the problem is that we 
have a late-commit policy and no way to clean up when the processes that 
are running exceed the capacity of the machine they are running on.  The 
AIX solution at first glance seems reasonable:  give the running processes 
a chance to "become part of the solution" by freeing memory space they have 
reserved but are not using, or that can be decommissioned [cached 
information] without destroying the process work.  The policy 
implementation can by default reward those processes by lowering their 
chances of being killed if the condition is not corrected.

Another characteristic of Oracle (shared by other mission-critical systems) 
is that the thing is not implemented as a single process, but as a 
collection of running processes working together.  Arbitrarily killing one 
process can corrupt the process work of several processes.  Currently there 
is no mechanism for a process to inform the system that any kills should 
really be directed at *this* parent, so that the whole thing shuts down 
reasonably.  If such a mechanism were to be provided, any signals to ANY 
process would be steered to the "top" process.  To prevent any subtle 
attacks, we would have to define bounds on which process is identified as 
the "top" process.  (Non-root process in the process tree would probably be 
fine for non-root subprocesses; any process in the process tree except init 
would be suitable for root subprocesses.)

Several people have identified that one of the current versions of the OOM 
killer doesn't cause the release of cache buffers within the Linux 
kernel.  I've seen mention of patches to correct this problem, but if you 
move the implementation of memory overcommittment recovery from the kernel 
to userland, you will need to have some way for that userland daemon to 
tell the various subsystems to release cached information that can be 
safely released.  This lets the daemon used a structured recovery technique 
where it does (A), check to see if that opens up enough room, does (B), 
check to see if that opens enough room, and so forth.  Note that some 
method needs to tell malloc() to fail all subsequent memory requests so 
that when the daemon takes a corrective action there isn't further 
overcommittment.

Which brings up another point:  why SIGKILL?  SIGTERM would appear to be 
the proper signal at a "yellow alert" so that the process has a chance of 
going through an orderly shutdown -- which might include check-pointing 
that week-long calculation of the 6,839,294,763,900,034th prime 
number.  This is especially important for process sets -- the first time 
that the top-level ORACLE module finds out there is trouble is to get a 
SIGCHILD signal from a troop when it isn't expecting one?

Finally, I want to bring up a sore subject:  beancounting.  When I was 
taking CS 306 (Operating System Principles) at UIUC in 1972 one issue that 
came up is the management of over-committment.  Our term project, a system 
resource manager, had to deal with a load that included just the behavior 
that has been discussed here:  programs that reserved resources that it 
never uses.  In our resource monitors, we were expected to keep track of 
allocations, 

Re: rate limiting error messages

[Khalid Aziz]

Eli Carter wrote:
> 
> Can someone point me to a "standard way" of doing rate limiting of error
> messages in the kernel?
> 
> TIA,
> 
> Eli
> ---.   Rule of Accuracy: When working toward
> Eli Carter |the solution of a problem, it always
> eli.carter(at)inet.com `-- helps if you know the answer.

Here is how it is done in IA-64 kernel:

static int
within_logging_rate_limit (void)
{
static unsigned long count, last_time;

if (count > 5 && jiffies - last_time > 5*HZ)
count = 0;
if (++count < 5) {
last_time = jiffies;
return 1;
}
return 0;

}

If this fundction returns 0, error messages have been rate limited. This
code is not MP-safe. So, if you need your code to be MP-safe, you may
need to rewrite it somewhat.

-- 
Khalid


Khalid Aziz Linux Development Laboratory
(970)898-9214Hewlett-Packard
[EMAIL PROTECTED]Fort Collins, CO
-
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: [WISHLIST] Addition of suspend patch into 2.5?

[Shawn Starr]

Not only for laptops :)

It's nice for PCs too also.

On Thu, 29 Mar 2001, Robert-Velisav MICIOVICI wrote:

>
> Just a small adition to the 2.5 whislist:
> Is "hibernation" on linux possible? Ideally it should write out on the /
> running on ext2fs and the new journaling fs's like reiserfs, xfs, etx3 etc
> and not some special filesystem or unpartiotioned space etc. I mean that
> this should be working without the need to repartiotion/reinstall.
> This is something **very** useful for laptop owners, not having to shut
> down (all) applications when need to grab the laptop and travel.
> Id' like to see this working nice in 2.6.
>
> Best regards,
> r
>
> On Thu, 22 Feb 2001, Pavel Machek wrote:
>
> > Date: Thu, 22 Feb 2001 21:43:08 +0100
> > From: Pavel Machek <[EMAIL PROTECTED]>
> > To: Shawn Starr <[EMAIL PROTECTED]>, lkm <[EMAIL PROTECTED]>
> > Subject: Re: [WISHLIST] Addition of suspend patch into 2.5?
> >
> > Hi!
> >
> > > Any idea if suspend/hybernation will be in future kernels?
> >
> > I'd like it included, too. Some toshiba laptops support sleep but not
> > suspend, and battery runs out within few hours if it was low before
> > suspend. That's bad.
> >
> > And the patch was pretty clean last time I checked.
> > 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/
>
>

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

At Last, Herbal V, the all Natural Alternative!

[HV]

Herbal V: An Incredible All-Natural Healthy Alternative To Va


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
  — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY 

Re: Disturbing news..

[Jesse Pollard]

Walter Hofmann <[EMAIL PROTECTED]>:
> On Wed, 28 Mar 2001, Jesse Pollard wrote:
[snip]
> > Now, if ELF were to be modified, I'd just add a segment checksum
> > for each segment, then put the checksum in the ELF header as well as
> > in the/a segment header just to make things harder. At exec time a checksum
> > verify could (expensive) be done on each segment. A reduced level could be
> > done only on the data segment or text segment. This would at least force
> > the virus to completly read the file to regenerate the checksum.
> 
> So? The virus will just redo the checksum. Sooner or later their will be a
> routine to do this in libbfd and this all reduces to a single additional
> line of code. 

true.

> > That change would even allow for signature checks of the checksum if the
> > signature was stored somewhere else (system binaries/setuid binaries...).
> > But only in a high risk environment. This could even be used for a scanner
> > to detect ANY change to binaries (and fast too - signature check of checksums
> > wouldn't require reading the entire file).
> 
> One sane way to do this is to store the sig on a ro medium and make the
> kernel check the sig of every binary before it is run.

Only for trusted binaries. (extreme paranoia now).
 
> HOWEVER, this means no compilers will work, and you have to delete all
> script languages like perl or python (or make all of them check the
> signature).

Compilers should work normally, the link phase is what would generate
the checksums, though if each object file contained a checksum for the
segment then the interpreters/dynamic loaders would have the choice.

The only applications I see as really needing to check such signatures
are those using PAM. These should do it anyway. The dynamic linking programs
should do so only if they are configured to do so.

> Useless again, IMO.
> 
> > In any case, the problem is limited to one user, even if nothing is done.
> 
> Your best bet is to educate your users.

User eduation is a reasonable substitute as long as they can be directed
to follow the rules.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
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: [OT] fb programming documentation

[James Simmons]

Take a look at http://linux-fbdev.sourceforge.net and are mailing is
[EMAIL PROTECTED] If you go to the web site you
will see a link to join the mailing list.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [[EMAIL PROTECTED]]   /|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org   =(_)=
http://linuxgfx.sourceforge.netU
http://linuxconsole.sourceforge.net

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

rate limiting error messages

[Eli Carter]

Can someone point me to a "standard way" of doing rate limiting of error
messages in the kernel?

TIA,

Eli 
---.   Rule of Accuracy: When working toward
Eli Carter |the solution of a problem, it always 
eli.carter(at)inet.com `-- helps if you know the answer.
-
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 connectivity trashed.

[John Jasen]

On Thu, 29 Mar 2001, Richard B. Johnson wrote:

>snipped<

First mistake:
your security administrator relied on the firewall for protection.
It is an _aid_ to security; not the 'be all and end all'. IOW, the hosts
weren't hardened to resist penetration in case the firewall didn't cover
it.

Second mistake:
your security administrator didn't make known the changes taking
place, so that clueful users could have taken some preventative steps on
their UNIX boxes.

Third mistake:
your security administrator either didn't know about; didn't care
about; or didn't act on security problems for linux and solaris -- which
have been posted, discussed, and addressed on many general or OS-specific
security lists.

Fourth mistake:
your security administrator, rather than address the problems, is
sticking his head in the sand and mumbling 'Windows' -- which, as an OS,
is a christmas tree where every bauble says 'please hack me!'.

In short, your security administrator needs to be dragged out, shot, and
left hanging by the front door as a warning to his replacement.

Or, at least fired.

-- 
-- John E. Jasen ([EMAIL PROTECTED])
-- In theory, theory and practise are the same. In practise, they aren't.

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

Re: kernel apm code

[John Fremlin]

 David Balazic <[EMAIL PROTECTED]> writes:

> John Fremlin wrote:

[...]

> > > To implement off-button you only need the APM_IOC_REJECT ioctl and
> > 
> > The problem on my computer with my (re)implementation of
> > APM_IOC_REJECT is that the screen goes into powersaving when the user
> > suspend is received, then turns it back on when APM_IOC_REJECT is sent
> > by apmd.
> 
> What is wrong with that ?

> Suspend is requested -> suspend is executed

> Suspend is canceled (rejected) -> suspend is canceled
> 
> Seems perfectly OK to me.

The sequence is in fact: suspend requested by BIOS -> suspend accepted
by kernel -> SUSPEND -> suspend rejected by apmd which is passed on by
kernel to BIOS -> REJECT=RESUME (if I understand correctly, this is
what seems to happen).

Sequence should be as in pmpolicy patch: suspend requested by BIOS ->
/sbin/powermanger decides to reject -> REJECT

[...]

> > Anyway it is fixed in my pmpolicy patch, and I don't need no
> > daemon so the code is a lot cleaner and simpler (no binary magic
> > number interfaces).
> 
> But there should be no policy in the kernel ! ;-)

Read the patch. Read the webpage:

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

There is no policy in kernel.

-- 

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

Re: OOM killer???

[Szabolcs Szakacsits]

On Thu, 29 Mar 2001, Dr. Michael Weller wrote:

> Applications forking and then dirtying their shared data pages
> madly? OOps.. nothing.. Why? It cannot be done!

In eager mode Solaris, Tru64, Irix, non-overcommit patch for Linux by
Eduardo Horvath from last year can do (you get ENOMEM at fork).

Szaka

-
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: opl3sa2 in 2.4.2 on Toshiba Tecra 8000

[Klaus Reimer]

Hi,

> > 2001-03-29 10:02:50.054774500 {kern|info} kernel: ad1848/cs4248 codec
> > driver Copyright (C) by Hannu Savolainen 1993-1996
> > 2001-03-29 10:02:50.070692500 {kern|notice} kernel: opl3sa2: No cards
> > found 2001-03-29 10:02:50.070703500 {kern|notice} kernel: opl3sa2: 0 PnP
> > card(s) found.
> Add 'isapnp=0' to the end of the options in your modules.conf.
> I *believe* this is fixed in a later kernel (2.4.3pre or 2.4.2ac).

If I am doing this, I can't even load the module and I get the following 
message in syslog:

2001-03-29 18:13:14.184156500 {kern|err} kernel: opl3sa2: Control I/O port 
0x0 not free

What is that "control i/o port"? Is this normally 0x100? What is the module 
parameter to specify this io port? The documentation only mentions "io", 
"mpu_io" and "mss_io" but I have specified these parameters already:

modprobe opl3sa2 io=0x538 mss_io=0x530 mpu_io=0x330 irq=5 dma=1 dma2=0 
isapnp=0

-- 
Bye, K
[a735 47ec d87b 1f15 c1e9 53d3 aa03 6173 a723 e391]
(Finger [EMAIL PROTECTED] to get public key)
-
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 connectivity trashed.

[Jesse Pollard]

"J . A . Magallon" <[EMAIL PROTECTED]>:
> On 03.29 Richard B. Johnson wrote:
> > 
> > The penetration occurred because somebody changed our  firewall
> > configuration
> > so that all of the non-DHCP addresses, i.e., all the real IP addresses had
> > complete
> > connectivity to the outside world. This meant that every Linux and Sun
> > Workstation
> > in this facility was exposed to tampering from anywhere in the world. This
> > appears
> > to be part of a plan to remove all non-DHCP machines by getting them
> > trashed.
> >
> 
> See the cleverness of his network admins, that spent their time configuring
> a firewall to MAKE HOLES where there are not any...

And obviously not tell anyone they were doing so

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
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: menuconfig snafu?

[Dennis]

At 05:35 PM 03/28/2001, Steve VanDevender wrote:
>Dennis writes:
>  > I KNOW this..my point is that menuconfig is not intuitive in providing 
> the
>  > choices.
>
>Linux kernel configuration isn't intuitive.  menuconfig isn't there to
>handhold newbies through the process.

Arguing that something clearly wrong doesnt matter because is sucks in 
general is brilliant. Congrats.


-
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: OOM killer???

[Szabolcs Szakacsits]

On Thu, 29 Mar 2001, Dr. Michael Weller wrote:
> On Thu, 29 Mar 2001, Szabolcs Szakacsits wrote:
> > The point is AIX *can* guarantee [even for an ordinary process] that
> > your signal handler will be executed, Linux can *not*. It doesn't matter
> No it can't... and the reason is...

So AIX is buggy in eager mode not reserving a couple of extra pages [per
process] to be able to run the handler. What AIX version(s) you use?
Anyway, as you probably noticed at present I'm not a big supporter of
introducing SIGDANGER, too many things can be messed up for little
or no gain.

> Note that there are nasty users like me, which provide a no_op function
> as SIGDANGER handler.

For example this.

> Joe blow user can code a SIGDANGER exploiting prog that will kill the
> whole concept by allocating memory in SIGDANGER.

And this. Moreover it shouldn't be malicious, people write happily
sighandlers that would blowup thing even without they realise ...

And admin still have no control over the things ;) Sure it could be
worked around these but I feel it just doesn't worth for the added
complexity.

> About this early alloction myths: Did you actually read the page?
> The fact its controlled by a silly environment variable shows it
> is a mere user space issue.

This is my question as well ;) Although I didn't read the AIX source but
guessed kernel sets a bit in the task structure for eager mode during
the exec() syscall and takes care about everything, at least this is
what the document suggests ;) [see the bottom of the page]

Szaka

-
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: OOM killer???

[Jesse Pollard]

Guest section DW <[EMAIL PROTECTED]>:
> 
> On Thu, Mar 29, 2001 at 01:02:38PM +0100, Sean Hunter wrote:
> 
> > The reason the aero engineers don't need to select a passanger to throw out
> > when the plane is overloaded is simply that the plane operators do not allow
> > the plane to become overloaded.
> 
> Yes. But today Linux willing overcommits. It would be better if
> the default was not to.

Preferably, the default should be a configure option, with runtime
alterations.

> > Furthermore, why do you suppose an aeroplane has more than one altimeter,
> > artifical horizon and compass?  Do you think it's because they are unable to
> > make one of each that is reliable?  Or do you think its because they are
> > concerned about what happens if one fails _however unlikely that is_.
> 
> Unix V6 did not overcommit, and panicked if is was out of swap
> because that was a cannot happen situation.

Ummm... no. The user got "ENOMEM" or "insufficient memory for fork", or
"swap error". The system didn't panic unless there was an I/O error on
the swap device.

> If you argue that we must design things so that there is no overcommit
> and still have an OOM killer just in case, I have no objections at all.

good.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
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: opl3sa2 in 2.4.2 on Toshiba Tecra 8000

[Bill Nottingham]

Klaus Reimer ([EMAIL PROTECTED]) said: 
> If I am doing this, I can't even load the module and I get the following 
> message in syslog:
> 
> 2001-03-29 18:13:14.184156500 {kern|err} kernel: opl3sa2: Control I/O port 
> 0x0 not free
> 
> What is that "control i/o port"? Is this normally 0x100?

I believe it can be, but I remember it usually being something
like 0x370 or so.

> What is the module 
> parameter to specify this io port? The documentation only mentions "io", 
> "mpu_io" and "mss_io" but I have specified these parameters already:
> 
> modprobe opl3sa2 io=0x538 mss_io=0x530 mpu_io=0x330 irq=5 dma=1 dma2=0 
> isapnp=0

It would be what you put in the io= parameter. 0x538 does *not* look
right.

Bill
-
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: 2.4.3-p8 pci_fixup_vt8363 + ASUS A7V "Optimal" = IDE disk corruption

[Arjan van de Ven]

On Wed, Mar 28, 2001 at 09:29:46PM -0800, Wayne Whitney wrote:

> I'm running kernel 2.4.3-pre8 on an ASUS A7V (BIOS 1007) motherboard and
> recently noticed that it sometimes corrupts my hard disk, an IBM 75GXP on
> the onboard PDC20265 IDE controller.  The corruption is detectable with a
> simple 'dd if=/dev/urandom of=test bs=16384 count=32768; cp test test2 ;
> diff test test2'.


/me throws arms in the air in despiration
It seems that the exact same settings corrupt a lot on one board and not on
another. But if you remove the quirk, the corruption is the
other way around 

Greetings,
  Arjan van de Ven

-
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: Newbie to Kernel Development

[Guennadi Liakhovetski]

On Thu, 29 Mar 2001, George Wright wrote:

> Hi all,
> 
> I am a newbie to Linux Kernel Development, with a very basic knowledge of C, 

...and there is a kernel-newbies mailing list:
[EMAIL PROTECTED]

> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive:   http://mail.nl.linux.org/
> IRC Channel:   irc.openprojects.net / #kernelnewbies
> Web Page:  http://www.surriel.com/kernelnewbies.shtml


___

Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [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: [OOPS] 2.2.19 USB and Digianswer/Tektronix sniffer

[Dave Airlie]

And of course the olibgatory self-followup...

usb-uhci.c: USB UHCI at I/O 0x1080, IRQ 9
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
usb.c: USB new device connect, assigned device number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: USB new device connect, assigned device number 2
usb-uhci.c: interrupt, status 2, frame# 879
usb-uhci.c: interrupt, status 2, frame# 881
usb-uhci.c: interrupt, status 2, frame# 883
usb-uhci.c: interrupt, status 2, frame# 885
usb-uhci.c: interrupt, status 2, frame# 887
usb.c: couldn't get all of config descriptors
usb.c: unable to get configuration (error=-84)
usb.c: USB new device connect, assigned device number -1
usb.c: USB device not responding, giving up (error=-90)
usb.c: USB disconnect on device -1
kmem_free: Bad obj addr (objp=c1f69120, name=size-32)

forgot people might want to see this bit as well..

Dave.


On Thu, 29 Mar 2001, Dave Airlie wrote:

>
> when boot Linux 2.2.19 with a Digianswer Bluetooth Sniffer plugged into
> the USB I get the following oops ... I know the device isn't supported but
> I'd like to be able to leave it plugged in without oopsen between
> Linux/Windows..
>
> Regards,
>   Dave.
>
> ksymoops 0.7c on i686 2.2.19.  Options used
>  -V (default)
>  -k /proc/ksyms (default)
>  -l /proc/modules (default)
>  -o /lib/modules/2.2.19/ (default)
>  -m /usr/src/linux/System.map (default)
>
> Warning: You did not tell me where to find symbol information.  I will
> assume that the log matches the kernel and modules that are running
> right now and I'll use the default options above for symbol resolution.
> If the current kernel and/or modules do not match the log, you can get
> more accurate output by telling me the kernel version and where to find
> map, modules, ksyms etc.  ksymoops -h explains the options.
>
> Unable to handle kernel NULL pointer dereference at virtual address 
> current->tss.cr3 = 00101000, %cr3 = 00101000
> *pde = 
> Oops: 0002
> CPU:0
> EIP:0010:[]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010202
> eax: 0039   ebx: c40fc080   ecx: c01a2c68   edx: cf422000
> esi: c1f69120   edi: 0202   ebp:    esp: c6f95f1c
> ds: 0018   es: 0018   ss: 0018
> Process khubd (pid: 1646, process nr: 100, stackpage=c6f95000)
> Stack:   c1f6915c c01bed26 d09695ea c1f69120 ce79c600 0010
>  cf73d25c d0976b8d  ce79c600 d0968ad0 ce79c600
>ce79c600  d096993e ce79c600 ce79c600   0001
> Call Trace: [] [] [] [] [] 
>[] []
>[] [] [] [] [] []
> Code: c7 05 00 00 00 00 00 00 00 00 eb 1b 8d 76 00 56 68 22 b0 18
>
> >>EIP; c0120825<=
> Trace; d09695ea <[usbcore]usb_destroy_configuration+66/1a8>
> Trace; d0976b8d <[usb-uhci]uhci_free_dev+29/30>
> Trace; d0968ad0 <[usbcore]usb_free_dev+24/30>
> Trace; d096993e <[usbcore]usb_disconnect+ea/f4>
> Trace; d096b659 <[usbcore]usb_hub_port_connect_change+2f9/324>
> Trace; d096b719 <[usbcore]usb_hub_events+95/1f0>
> Trace; d09710e7 <[usbcore]usb_bandwidth_option+18a7/20b4>
> Trace; d0970001 <[usbcore]usb_bandwidth_option+7c1/20b4>
> Trace; d097253c <[usbcore]__ksymtab_usb_inc_dev_use+4/8>
> Trace; d096b8bd <[usbcore]usb_hub_thread+49/6c>
> Trace; d0968050 <[usbcore].text.start+4/8c>
> Trace; c0107b8b 
> Trace; d0968000 <[serial].bss.end+778d/77d9>
> Code;  c0120825 
>  <_EIP>:
> Code;  c0120825<=
>0:   c7 05 00 00 00 00 00  movl   $0x0,0x0   <=
> Code;  c012082c 
>7:   00 00 00
> Code;  c012082f 
>a:   eb 1b jmp27 <_EIP+0x27> c012084c 
> Code;  c0120831 
>c:   8d 76 00  lea0x0(%esi),%esi
> Code;  c0120834 
>f:   56push   %esi
> Code;  c0120835 
>   10:   68 22 b0 18 00push   $0x18b022
>
>
> 1 warning issued.  Results may not be reliable.
>
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
pam_smb / Linux DecStation / Linux VAX / ILUG person


-
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: OOPS: reiserfs, 2.4.2-ac26 SMP

[Elmer Joandi]

Chris Mason wrote:

>
> Most likely compiled with redhat gcc 2.96.  Please upgrade to their latest,
> or use kgcc.

Ok, after
1. upgrading redhat gcc
2. applying that BKL in vmtruncate minipatch

now it copies about 50MB before cp gets stuck on do_journal



2.4.0 with reiserfs patch and reiserfs quota patch just works (not the quota
part yet).



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

[OOPS] 2.2.19 USB and Digianswer/Tektronix sniffer

[Dave Airlie]

when boot Linux 2.2.19 with a Digianswer Bluetooth Sniffer plugged into
the USB I get the following oops ... I know the device isn't supported but
I'd like to be able to leave it plugged in without oopsen between
Linux/Windows..

Regards,
Dave.

ksymoops 0.7c on i686 2.2.19.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.2.19/ (default)
 -m /usr/src/linux/System.map (default)

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

Unable to handle kernel NULL pointer dereference at virtual address 
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 0039   ebx: c40fc080   ecx: c01a2c68   edx: cf422000
esi: c1f69120   edi: 0202   ebp:    esp: c6f95f1c
ds: 0018   es: 0018   ss: 0018
Process khubd (pid: 1646, process nr: 100, stackpage=c6f95000)
Stack:   c1f6915c c01bed26 d09695ea c1f69120 ce79c600 0010
     cf73d25c d0976b8d  ce79c600 d0968ad0 ce79c600
   ce79c600  d096993e ce79c600 ce79c600   0001
Call Trace: [] [] [] [] [] 
[] []
   [] [] [] [] [] []
Code: c7 05 00 00 00 00 00 00 00 00 eb 1b 8d 76 00 56 68 22 b0 18

>>EIP; c0120825<=
Trace; d09695ea <[usbcore]usb_destroy_configuration+66/1a8>
Trace; d0976b8d <[usb-uhci]uhci_free_dev+29/30>
Trace; d0968ad0 <[usbcore]usb_free_dev+24/30>
Trace; d096993e <[usbcore]usb_disconnect+ea/f4>
Trace; d096b659 <[usbcore]usb_hub_port_connect_change+2f9/324>
Trace; d096b719 <[usbcore]usb_hub_events+95/1f0>
Trace; d09710e7 <[usbcore]usb_bandwidth_option+18a7/20b4>
Trace; d0970001 <[usbcore]usb_bandwidth_option+7c1/20b4>
Trace; d097253c <[usbcore]__ksymtab_usb_inc_dev_use+4/8>
Trace; d096b8bd <[usbcore]usb_hub_thread+49/6c>
Trace; d0968050 <[usbcore].text.start+4/8c>
Trace; c0107b8b 
Trace; d0968000 <[serial].bss.end+778d/77d9>
Code;  c0120825 
 <_EIP>:
Code;  c0120825<=
   0:   c7 05 00 00 00 00 00  movl   $0x0,0x0   <=
Code;  c012082c 
   7:   00 00 00
Code;  c012082f 
   a:   eb 1b jmp27 <_EIP+0x27> c012084c 
Code;  c0120831 
   c:   8d 76 00  lea0x0(%esi),%esi
Code;  c0120834 
   f:   56push   %esi
Code;  c0120835 
  10:   68 22 b0 18 00push   $0x18b022


1 warning issued.  Results may not be reliable.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
pam_smb / Linux DecStation / Linux VAX / ILUG person


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

WG: 2.4 on COMPQ Proliant

[Butter, Frank]

2.2.16 claimes to find a ncr53c1510D-chipset, supported by
the driver ncr53c8xx. Which kernel-param would be the correct one for this?

Frank

> -Ursprüngliche Nachricht-
> Von: Butter, Frank 
> Gesendet: Donnerstag, 29. März 2001 17:11
> An: '[EMAIL PROTECTED]'
> Betreff: 2.4 on COMPQ Proliant
> 
> 
> 
> Has anyone experiences with 2.4.x on recent Compaq Proliant 
> Servers (e.g. ML570)?
> 
> I've installed RedHat7 and it worked fine out of the box.
> Except that the SMP-enabled kernel stated there was no 
> SMP-board detected ;-/
> For some reasons (Fibrechannel drivers and so on) I've compiled
> 2.4.2 and installed it. Although I've compiled the support 
> in, the NCR-SCSI-chip was not found and therefore no 
> root-partition. It is a model supported by 53c8xx - detected 
> by the original RedHat-kernel.  
> 
> For testing I compiled a kernel with all (!) scsi-low-level-drivers -
> with the same result. The SMP-board also was NOT detected by 2.4.2.
> 
> Any hint?
> 
> Frank
> 
-
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: opl3sa2 in 2.4.2 on Toshiba Tecra 8000

[Bill Nottingham]

Klaus Reimer ([EMAIL PROTECTED]) said: 
> 2001-03-29 10:02:50.054774500 {kern|info} kernel: ad1848/cs4248 codec driver 
> Copyright (C) by Hannu Savolainen 1993-1996
> 2001-03-29 10:02:50.070692500 {kern|notice} kernel: opl3sa2: No cards found
> 2001-03-29 10:02:50.070703500 {kern|notice} kernel: opl3sa2: 0 PnP card(s) 
> found.

Add 'isapnp=0' to the end of the options in your modules.conf.
I *believe* this is fixed in a later kernel (2.4.3pre or 2.4.2ac).

Bill
-
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: Solved with MTRR was: ISSUE: very slow (factor 100) 4-way 16GByte server, with 2.4.2

[David Wragg]

Robert Suetterlin <[EMAIL PROTECTED]> writes:
> 2. I was not allowed to do `base=0 size=0x4
> type=write-back`, because of the overlap with the memory range at
> base=0x0fb00. 

/proc/mtrr does allow overlapping regions in some cases, but the
conditions turned out to be stricter than I remembered.  You have to
create the enclosing range first, which makes the facility useless in
this case (perhaps in all potentially useful cases).

> So what I do is only disable 3-7, and then
> base=0x4 size=0x4.

Yes, that solution should be safe.

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