Re: failure to burn CDs under 2.4.0-test9

[Andre Hedrick]

On Thu, 5 Oct 2000, J. Dow wrote:

> For that matter Andre a 4 speed HP can certainly burn at 4 speed except
> that cdrecord and the OS conspire to prevent this through a mathematical
> error. It's rather a tad frustrating.

Explain, please

#!/bin/sh
#
# mkisofs -r -o cd_image -R -x $(object_path) $(target_path)
ISO9660_PATH=/home/iso9660

#
mkisofs -r -o $ISO9660_PATH/cd_image -R -x "$1" "$2"

#!/bin/sh
# checkit -- cd-rw loop mount and check
#
# mkisofs -r -o cd_image -R -x $(object_path) $(target_path)
# cdrecord -v speed=4 dev=0,0,0 -eject  -data cd_image
ISO9660_PATH=/home/iso9660
#
# cdrecord -v speed=4 dev=0,0,0 -eject -data $ISO9660_PATH/cd_image
mount -t iso9660 -o rw,loop=/dev/loop0 $ISO9660_PATH/cd_image /cdrom

#!/bin/sh
# burnit -- cd-rw write to media
#
# mkisofs -r -o cd_image -R -x $(object_path) $(target_path)
# cdrecord -v speed=4 dev=0,0,0 -eject  -data cd_image
ISO9660_PATH=/home/iso9660
#
cdrecord -v speed=4 dev=0,0,0 -eject -data $ISO9660_PATH/cd_image

This is my script series for a 4X burn

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

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

[PATCH] 2nd go for scsi upper layers + I2O

[Torben Mathiasen]

Ok this patch should be diffed correctly. Same things apply:

   apply patch
   copy sd.c st.c sg.c sr.c sr_ioctl.c sr_vendor.c from
   drivers/scsi to drivers/scsi/upper  

The EXPORT_SYMBOL has been removed as Jeff suggested.

TLAN will hopefully follow soon.

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk


diff -urN linux-test9/Makefile linux/Makefile
--- linux-test9/MakefileThu Oct  5 22:21:00 2000
+++ linux/Makefile  Thu Oct  5 22:24:11 2000
@@ -144,7 +144,13 @@
 DRIVERS-$(CONFIG_ARCNET) += drivers/net/arcnet/arcnet.a
 DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o
 DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o
+
+# Init ordering constraint:
+# scsidrv.o < !drivers/scsi < scsi_upper.o
 DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o
+DRIVERS-$(CONFIG_I2O) += drivers/i2o/i2o.o
+DRIVERS-$(CONFIG_SCSI) += drivers/scsi/upper/scsi_upper.o
+
 DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394.a
 
 ifneq 
($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),)
@@ -171,7 +177,6 @@
 DRIVERS-$(CONFIG_TC) += drivers/tc/tc.a
 DRIVERS-$(CONFIG_USB) += drivers/usb/usbdrv.o
 DRIVERS-$(CONFIG_INPUT) += drivers/input/inputdrv.o
-DRIVERS-$(CONFIG_I2O) += drivers/i2o/i2o.o
 DRIVERS-$(CONFIG_IRDA) += drivers/net/irda/irda.o
 DRIVERS-$(CONFIG_I2C) += drivers/i2c/i2c.o
 DRIVERS-$(CONFIG_PHONE) += drivers/telephony/telephony.o
diff -urN linux-test9/drivers/block/genhd.c linux/drivers/block/genhd.c
--- linux-test9/drivers/block/genhd.c   Thu Oct  5 22:21:03 2000
+++ linux/drivers/block/genhd.c Thu Oct  5 22:24:11 2000
@@ -27,7 +27,6 @@
 extern void console_map_init(void);
 extern int soc_probe(void);
 extern int atmdev_init(void);
-extern int i2o_init(void);
 extern int cpqarray_init(void);
 extern void ieee1394_init(void);
 
@@ -39,9 +38,6 @@
chr_dev_init();
blk_dev_init();
sti();
-#ifdef CONFIG_I2O
-   i2o_init();
-#endif
 #ifdef CONFIG_BLK_DEV_DAC960
DAC960_Initialize();
 #endif
diff -urN linux-test9/drivers/i2o/i2o_block.c linux/drivers/i2o/i2o_block.c
--- linux-test9/drivers/i2o/i2o_block.c Thu Oct  5 22:21:04 2000
+++ linux/drivers/i2o/i2o_block.c   Thu Oct  5 22:28:24 2000
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1591,11 +1592,7 @@
  *  (Just smiley confuses emacs :-)
  */
 
-#ifdef MODULE
-#define i2o_block_init init_module
-#endif
-
-int i2o_block_init(void)
+static int __init i2o_block_init(void)
 {
int i;
 
@@ -1611,9 +1608,8 @@
   MAJOR_NR);
return -EIO;
}
-#ifdef MODULE
+   
printk(KERN_INFO "i2o_block: registered device at major %d\n", MAJOR_NR);
-#endif
 
/*
 *  Now fill in the boiler plate
@@ -1694,13 +1690,7 @@
return 0;
 }
 
-#ifdef MODULE
-
-EXPORT_NO_SYMBOLS;
-MODULE_AUTHOR("Red Hat Software");
-MODULE_DESCRIPTION("I2O Block Device OSM");
-
-void cleanup_module(void)
+static void __exit i2o_block_exit(void)
 {
struct gendisk **gdp;
int i;
@@ -1760,4 +1750,10 @@
break;
 
 }
-#endif
+
+MODULE_AUTHOR("Red Hat Software");
+MODULE_DESCRIPTION("I2O Block Device OSM");
+
+module_init(i2o_block_init);
+module_exit(i2o_block_exit);
+
diff -urN linux-test9/drivers/i2o/i2o_config.c linux/drivers/i2o/i2o_config.c
--- linux-test9/drivers/i2o/i2o_config.cThu Oct  5 22:21:04 2000
+++ linux/drivers/i2o/i2o_config.c  Thu Oct  5 22:46:18 2000
@@ -910,11 +910,7 @@
&config_fops
 }; 
 
-#ifdef MODULE
-int init_module(void)
-#else
-int __init i2o_config_init(void)
-#endif
+static int __init i2o_config_init(void)
 {
printk(KERN_INFO "I2O configuration manager v 0.04.\n");
printk(KERN_INFO "  (C) Copyright 1999 Red Hat Software\n");
@@ -948,9 +944,7 @@
return 0;
 }
 
-#ifdef MODULE
-
-void cleanup_module(void)
+void __exit i2o_config_exit(void)
 {
misc_deregister(&i2o_miscdev);

@@ -961,9 +955,10 @@
if(i2o_buffer)
kfree(i2o_buffer);
 }
+
+module_init(i2o_config_init);
+module_exit(i2o_config_exit);
  
-EXPORT_NO_SYMBOLS;
 MODULE_AUTHOR("Red Hat Software");
 MODULE_DESCRIPTION("I2O Configuration");
 
-#endif
diff -urN linux-test9/drivers/i2o/i2o_core.c linux/drivers/i2o/i2o_core.c
--- linux-test9/drivers/i2o/i2o_core.c  Thu Oct  5 22:21:04 2000
+++ linux/drivers/i2o/i2o_core.cThu Oct  5 22:24:11 2000
@@ -19,7 +19,7 @@
  * Auvo Häkkinen <[EMAIL PROTECTED]> 
  * Deepak Saxena <[EMAIL PROTECTED]> 
  * Boji T Kannanthanam <[EMAIL PROTECTED]>
- * 
+ * Torben Mathiasen <[EMAIL PROTECTED]> 
  */
 
 #include 
@@ -119,7 +119,6 @@
  */
 static spinlock_t i2o_dev_lock = SPIN_LOCK_UNLOCKED;
 
-#ifdef MODULE
 /* 
  * Function table to send to bus specific layers
  * See  for explanation of this
@@ -134,12 +133,9 @@
i2o_delete_contro

Re: Tux 2 patents

[Daniel Phillips]

"Jeff V. Merkey" wrote:
> 
> Daniel Phillips wrote:
> >
> > "Jeff V. Merkey" wrote:
> > >
> > > > "Jeff V. Merkey" wrote:
> > > > >
> > > > > The patent attorneys at Malinkrodt received the materials Daniel sent
> > > > > yesterday on the Tux 2 patents via courier and are working on the
> > > > > analysis.  They said they would have something for us to post on LKML
> > > > > next week.
> > > >
> > > > I'll calm down and work on my magicpoint slides for now.
> > >
> > > I think you are ok based on our preliminary review, but the patent lawyers
> > > will go down each claim granted by the USPTO in related patents, and
> > > analyze them relative to your proposed methods.
> >
> > And if my method is OK, then is there a reason why we should not apply
> > for a "white hat" patent with a GPL-compatible licence?  And if my
> > method is not only OK, but superior in every way, then aren't we
> > winning?
> 
> Once you use the technique and it's documented as clear by a patent
> lawyer, it will be safe for you to use forever, particularly if it's 
> in the public domain. This is winning

This is good to know, but what I was talking about is taking it *out of
the closed source* domain.  The idea is to take our best ideas out of
the closed source domain.  After a few years of doing that, it's my
guess that the evil software patent system would keel over and die.

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

Re: Integrating Andre IDE patch into 2.2.18/19 kernel

[Bruno Boettcher]

On Thu, Oct 05, 2000 at 11:56:30PM +0200, Mikael Pettersson wrote:
> On Wed, 4 Oct 2000, Jeff Nguyen wrote:
> 
> >Hi Alan.
> >
> >I hope you will consider to integrate Andre IDE patche into the 2.2.18 or
> >2.2.19 kernel.
PLEASE NOT ! the 2.4 IDE driver isn't working for me at all!! at the
contrary i would rather see the 2.2 IDE driver in 2.4 :(


-- 
ciao bboett
==
[EMAIL PROTECTED]
http://inforezo.u-strasbg.fr/~bboett http://erm1.u-strasbg.fr/~bboett
===
the total amount of intelligence on earth is constant.
human population is growing
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: linux-2.4.0-test9

[Richard Henderson]

On Thu, Oct 05, 2000 at 09:59:08PM -0700, David S. Miller wrote:
>Compile with -fno-common and you'll get .bss, but not COMMON,
>variables.  It's the COMMON bits that are screwing your games.

Oh, I was just thinking too -- have you given any thought
to what happens on .sdata hosts even with your original
code?  Seems to me that if you want to play games and be
sure that they stay played, that you'd have to put all
the variables into a struct.


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

Re: hdparm settings: Can they be permanent?

[Thomas Dodd]

"Mike A. Harris" wrote:
> 
> On Thu, 5 Oct 2000, Harald Welte wrote:
> 
> >Some distributions already have the hdparm initscript.
> 
> I'm not sure about that one for RH..  I use my own script, but
> there might be one now..

rc.sysinit looks at /etc/sysconfig/harddisks
in pinstripe and guinness. harddisks comes from the hdparm
RPM.

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

Fw: failure to burn CDs under 2.4.0-test9

[J. Dow]

- Original Message - 
From: "J. Dow" <[EMAIL PROTECTED]>
To: "Andre Hedrick" <[EMAIL PROTECTED]>
Sent: Friday, October 06, 2000 0:35
Subject: Re: failure to burn CDs under 2.4.0-test9


> From: "Andre Hedrick" <[EMAIL PROTECTED]>
> 
> > On Thu, 5 Oct 2000, J. Dow wrote:
> > 
> > > For that matter Andre a 4 speed HP can certainly burn at 4 speed except
> > > that cdrecord and the OS conspire to prevent this through a mathematical
> > > error. It's rather a tad frustrating.
> > 
> > Explain, please
> 
> I skipped all the mkisofs stuff. I downloaded the 7.0 images and tried to
> burn them to CDROM on CDs rated for 6 speed and a drive, HP CDWriter+ 8100,
> rated for 4 speed on write. The system is an Athlon 700MHz with a K7M
> board. The CDWriter+ is IDE. The OS at the time was the -22 build from
> RedHat's pinstripe/.../preview directory recompiled in an attempt to
> make the via82cxxx_audio work. (It works right under 2.4.0-test8 I am
> running now.)
> 
> > cdrecord -v speed=4 dev=0,0,0 -eject -data $ISO9660_PATH/cd_image
> 
> Remarkably similar to the command I used. It still burned at 2 speed. I
> traced through the cdrecord code and three levels of OS driver finding
> several conversions from nominal speed ratings to "precise" speed ratings.
> The tool concluded that the drive had reported it could do 700kB/S while
> the software insisted it needed to be capable of at least705.6kB/S. It
> looked like in some places the kernel used a nominal 175kB/S as the
> conversion figure and in others 176.4kB/S. About then the maze of twisty
> little passages and the loss of time to persue it to a conclusion wore
> thin and I moved on to making money to pay for my food and housing and
> clothing by being a mercenary instead of philanthropist. I could have
> done a quick hack to cdrecord except it appears to be intimately tied
> to too many other things for which I'd have to install source and deal
> with. 'Sides, it looked like the kernel was slightly internally schizoid.
> That MIGHT be the proper place to repair things. And ide-scsi or ide-cd
> might be the proper place to start investigating.
> 
> This problem seems to have existed since 2.0.xx days when I first noticed
> I could not get cdrecord to even TRY to record at the drive and disc
> rated speeds. (Nor can I get it to do it with 2.2.16 on a machine with a
> SCSI HP CDWriter+ 9200 which won't do its rated speed, either.)
> 
> {^_^}
> 
> 

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

Re: The case for a standard kernel debugger

[richardj_moore]

Yes, we looked at that and it didn't seem to provide the generality we
needed - multipe exits registered per hook, ability to arm a set of hooks
atomically, ability to prioritise dispatching order of a hook exit, MP
complient. I may be wrong but the Linux Trace Toolkit hooks like like they
were specifically designed to cater for inserting static tracepoints into
the kernel.


Richard Moore -  RAS Project Lead - Linux Technology Centre (PISC).

http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK


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

Re: hdparm settings: Can they be permanent?

[Arjan van de Ven]

In article <[EMAIL PROTECTED]> you wrote:
> On Wed, Oct 04, 2000 at 02:57:54PM +, Stephen Torri wrote:
>> It was suggested to me that the way to make hdparm settings permanent was
>> to create a script to change the settings on startup. Is this the best
>> choice?

> Yes, indeed. It is the same for all kernel configurable parameters. Look
> at /proc/sys/net/ipv4/ip_forward, etc.

Powertweak (http://powertweak.sourceforge.net) restores those as well, and
provides a GUI to set/change those. It doesn't do the hdparm bits, that
is on our TODO list though. 

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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Integrating Andre IDE patch into 2.2.18/19 kernel

[Andre Hedrick]

2.2 and 2.4 are not the same anymore with ide-pci init.
2.4 got broken.

In case you have not read, the backport is suspended for now.
So you can not have you UltraDMA in 2.2 if you wanted.

Instead of bitching about the problem, way not attempt to narrow the scope
where you think is was broken.

OH, and to hell with laptops for a while!

On Fri, 6 Oct 2000, Bruno Boettcher wrote:

> On Thu, Oct 05, 2000 at 11:56:30PM +0200, Mikael Pettersson wrote:
> > On Wed, 4 Oct 2000, Jeff Nguyen wrote:
> > 
> > >Hi Alan.
> > >
> > >I hope you will consider to integrate Andre IDE patche into the 2.2.18 or
> > >2.2.19 kernel.
> PLEASE NOT ! the 2.4 IDE driver isn't working for me at all!! at the
> contrary i would rather see the 2.2 IDE driver in 2.4 :(
> 
> 
> -- 
> ciao bboett
> ==
> [EMAIL PROTECTED]
> http://inforezo.u-strasbg.fr/~bboett http://erm1.u-strasbg.fr/~bboett
> ===
> the total amount of intelligence on earth is constant.
> human population is growing
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

Andre Hedrick
The Linux ATA/IDE guy

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

Re: Status of ReiserFS + Journalling

[Daniel Phillips]

Neil Brown wrote:
> Suppose, for stripe X the parity device is device 1 and we were
> updating the block on device 0 at the time of system failure.
> What had happened was that the new parity block was written out, but
> the new data block wasn't.
> Suppose further than when the system come back, device 2 has failed.
> We now cannot recover the data that was on stripe X, device 2.  If we
> tried, we would xor all the blocks from working devices together and I
> hope that you can see that this would be the wrong answer.  This poor,
> innocent, block, which hasn't been modified for years, has just been
> corrupted.  Not good for PR.

Now that I'm getting better at thinking about this I can see that a very
simple journal will protect from this particular problem.  A phase-tree
style approach would likely to the job more efficiently, once again. 
Here's the ultimate simple approach: why not treat an entire stripe as
one block?  That way you never get 'innocent blocks' on your stripe.

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

Re: The case for a standard kernel debugger

[Karim Yaghmour]

Hello Richard,

Part of your analysis is correct. The hooks were designed to take care of
static tracepoints only. That said, dynamic allocation of event IDs was
next on my list and the hooking mechanism would have been modified consequently.

As for "multiple exits registered per hook", if you mean that you can have more
than one function called back for each event, then this is already possible.
The other items you mention such as atomicity and prioritization seem interesting
indeed, although I am not sure what you mean by MP compliant as the only
thing that stops the current generalized hooking mechanism to be MP compliant
is the insertion of correct locks during callback registration.

Please understand that the purpose wasn't to discredit your work, but rather
to stop duplication of work as efforts could be deployed elsewhere. I think
that your work and the work already done on LTT can be brought together in
a way that would profit all. This is what I was hinting to towards the end
of the posting. It was an invitation more than anything else.

Apart from the hooking mechanism, there were other items which I mentioned
that merit discussion, such as the ability to enable dynamic probes to log
events in normal LTT traces or the event-driven state machine engine. Hence,
if you are interested in joining forces to further enhance probing and tracing
capabilities in Linux, I think this would be a good opportunity.

Best regards

Karim

[EMAIL PROTECTED] wrote:
> 
> Yes, we looked at that and it didn't seem to provide the generality we
> needed - multipe exits registered per hook, ability to arm a set of hooks
> atomically, ability to prioritise dispatching order of a hook exit, MP
> complient. I may be wrong but the Linux Trace Toolkit hooks like like they
> were specifically designed to cater for inserting static tracepoints into
> the kernel.
> 
> Richard Moore -  RAS Project Lead - Linux Technology Centre (PISC).
> 
> http://oss.software.ibm.com/developerworks/opensource/linux
> Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
> IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK

-- 
===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

No Subject

[Diana Cionoiu]

list

--
K Free E-mail http://www.k.ro/
by KappaNet http://www.kappa.ro/



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

Re: failure to burn CDs under 2.4.0-test9

[Dennis K]

Henrik Størner wrote:
> Heh - the first drive I saw this on was an old HP IDE drive only
> capable of burning at double-speed. The second - a Yamaha SCSI
> drive - does support CDRW, but I rarely use it. The Yamaha does
> quad-speed, which is what I used when the burn faild.
> 
> Haven't had any problems prior to this with these drives running at
> their max speed, though. And the same drive burns the same image
> just fine while running 2.2.17.

I have (or to be fair, my work has) an old HP7200 parallel port CD-R
and CD-RW drive, and it runs perfectly under 2.4.0-test7... Haven't had
a single burn that has failed. It's max speed is 2x, but i always use
the
speed=2... Dunno why.. Just does... I'll try without, but I can't see
what it should change...

Regards,
Dennis Krøger

-- 
Thanks, and THIS time it really is fixed. I mean, how many times can we
get it wrong? At some point, we just have to run out of really bad
ideas..

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

Re: ack number in a connection-refused RST

[Peter H. Ruegg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 5 Oct 2000, Alan Curry wrote:

> Questions:
> 
> 1. Could/should the Linux kernel be patched to recognize the one-off sequence
>number and return ECONNREFUSED?

Nope, the sequence number could be correct for another Connection.

> 2. If the BADHOST behavior is incorrect, can a TCP expert please explain
>exactly why, so a bug report can be filed...

Quoting from W. Richard Stevens:
"Since every byte that is exchanged is numbered, the acknowledgment number
contains the next sequence number that the sender of the acknowledgment
expects to receive. This is therefore the sequence number plus 1 of the last
successfully received byte of data. This field is valid only if the ACK
flag is on."

> 3. Does anybody know where to file a bug report on the Sega Dreamcast TCP?

;-)

Greets

Peter H. Ruegg

- --8<-
main(){char*s="O_>>^PQAHBbPQAHBbPOOH^^PAAHBJPAAHBbPA_H>BB";int i,j,k=1,l,m,n;
for(j=0;j<7;j++)for(l=0;m=l-6+j,i=m/6,n=j*6+i,k=1

Re: [PATCH-2.2] Bonding Driver Enhancements - final

[willy tarreau]

> Donald's email server has been down for few days, my
> machine was not able to send him e-mail.
ok.

> Regarding your last patch -- it does not include the
> documentation update (ifenslave.c compile problem is
> solved).

yes, it's just what I've discovered yesterday evening.
I'll attach the complete bonding.txt here, and rebuild
the patch later.

> BAD RESULTS.
> It did not work with SMP kernel on Compaq (worked

ok, very interesting. IMHO, the only way to get into
this trouble is a problem when setting a link up. I'll
try to investigate, perhaps I'll have access to a
dual-ppro today.

> (the link detection worked fine and was reported
even
> when the network was dead).

so the MII in the interfaces drivers works correctly.

> As soon as packets were queued to be sent via the
> second NIC, the network would effectively die.

I believe the eepro driver can reset itself under
certain conditions (it includes its own timer for
this). I don't know exactly why, but if this happens,
I can imagine the trunk seeing the interface go down.

> saw a lot of messages like "eth1: transmit timeout,
> status..."

this tends to validate the last possibility.

> With both the old and the new patch, trying to bring
> the second ethernet down (either manually with
> ifconfig or at reboot) would freeze the
> machine.

ok, the problem checking for no active interface
came again.

> It was not a lock-up; machine would respond to
> keyboard, but all commands would get stuck.

you should have had only one CPU completely stuck in
the xmit loop, and the other one processing your
keyboard inputs.

> This could be a case of a Compaq that is not
> properly configured for Linux

nope, the problem should come from my code (very few
experience in SMP code, only multi-threading you
see:-)

> GOOD RESULTS.
> Both the old and the optimized patch work fine on UP

ok, that's all I could verify on my home PC.

> The new patch does indeed optimize the load.

So Thomas was right.

> Caveats.
.../...
> used, then I restore
> the link, IT IS NOT REPORTED but I see with ifconfig
> that both links are used again.

very interesting bug. This may explain the activation
problem at start time on SMP.

> change. No network performance loss (not even short
> time) was observed during a switch to a backup
> interface.

your switches are very interesting. My alteon AD3 take
between 1 and 40 seconds to understand that the MAC
address changed its port.

> A worse case is when a link is restored 

I've written a little about thus problem in the doc.
It
was in the TODO to add two timers : one for link down,
one for link up. My alteon take about 10 seconds to
reboot.

> If we are talking about features, we should remove
> the limitation of one bonding interface!!!

when compiled as a module, you're not limited anymore.

Thanks very very much for all your tests. I'll try to
investigate on the bugs (SMP and link loss). I'll
think
about adding an "up delay" and "down delay" per slave,
to avoid hurry detection.

will try SMP today and others bug this week-end.

Cheers,

Willy


___
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, 
Yahoo! Messenger : http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[preview] VIA v3.6 and AMD v1.2 IDE drivers

[Vojtech Pavlik]

Hi!

For those who like to try out the very latest developments, I'm
including my latest VIA and AMD IDE tuning drivers.

Just place all the files in drivers/ide of a 2.4 kernel and have fun.

Of course, I'm interested in all success/failure stories.

Thanks.

-- 
Vojtech Pavlik
SuSE Labs


#ifndef _IDE_TIMING_H
#define _IDE_TIMING_H

/*
 * $Id: ide-timing.h,v 1.4 2000/10/02 20:48:56 vojtech Exp $
 *
 *  Copyright (c) 1999-2000 Vojtech Pavlik
 *
 *  Sponsored by SuSE
 */

/*
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 *
 * Should you need to contact me, the author, you can do so either by
 * e-mail - mail your message to <[EMAIL PROTECTED]>, or by paper mail:
 * Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic
 */

#include 

#ifndef XFER_PIO_5
#define XFER_PIO_5  0x0d
#endif

struct ide_timing {
short mode;
short setup;/* t1 */
short act8b;/* t2 for 8-bit io */
short rec8b;/* t2i for 8-bit io */
short cyc8b;/* t0 for 8-bit io */
short active;   /* t2 or tD */
short recover;  /* t2i or tK */
short cycle;/* t0 */
short udma; /* t2CYCTYP/2 */
};

/*
 * PIO 0-5, MWDMA 0-2 and UDMA 0-5 timings (in nanoseconds).
 * These were taken from ATA/ATAPI-6 standard, rev 0a, except
 * for PIO 5, which is a nonstandard extension.
 */

static struct ide_timing ide_timing[] = {

{ XFER_UDMA_5, 0,   0,   0,   0,   0,   0,   0,  20 },
{ XFER_UDMA_4, 0,   0,   0,   0,   0,   0,   0,  30 },
{ XFER_UDMA_3, 0,   0,   0,   0,   0,   0,   0,  45 },

{ XFER_UDMA_2, 0,   0,   0,   0,   0,   0,   0,  60 },
{ XFER_UDMA_1, 0,   0,   0,   0,   0,   0,   0,  80 },
{ XFER_UDMA_0, 0,   0,   0,   0,   0,   0,   0, 120 },
  
{ XFER_MW_DMA_2,  25,   0,   0,   0,  70,  25, 120,   0 },
{ XFER_MW_DMA_1,  45,   0,   0,   0,  80,  50, 150,   0 },
{ XFER_MW_DMA_0,  60,   0,   0,   0, 215, 215, 480,   0 },
  
{ XFER_SW_DMA_2,  60,   0,   0,   0, 120, 120, 240,   0 },
{ XFER_SW_DMA_1,  90,   0,   0,   0, 240, 240, 480,   0 },
{ XFER_SW_DMA_0, 120,   0,   0,   0, 480, 480, 960,   0 },

{ XFER_PIO_5, 20,  50,  30, 100,  50,  30, 100,   0 },
{ XFER_PIO_4, 25,  70,  25, 120,  70,  25, 120,   0 },
{ XFER_PIO_3, 30,  80,  70, 180,  80,  70, 180,   0 },

{ XFER_PIO_2, 30, 290,  40, 330, 100,  90, 240,   0 },
{ XFER_PIO_1, 50, 290,  93, 383, 125, 100, 383,   0 },
{ XFER_PIO_0, 70, 290, 240, 600, 165, 150, 600,   0 },

{ XFER_PIO_SLOW, 120, 290, 240, 960, 290, 240, 960,   0 },

{ -1 }
};

#define IDE_TIMING_SETUP0x01
#define IDE_TIMING_ACT8B0x02
#define IDE_TIMING_REC8B0x04
#define IDE_TIMING_CYC8B0x08
#define IDE_TIMING_8BIT 0x0e
#define IDE_TIMING_ACTIVE   0x10
#define IDE_TIMING_RECOVER  0x20
#define IDE_TIMING_CYCLE0x40
#define IDE_TIMING_UDMA 0x80
#define IDE_TIMING_ALL  0xff

#define MIN(a,b)((a)<(b)?(a):(b))
#define MAX(a,b)((a)>(b)?(a):(b))
#define FIT(v,min,max)  MAX(MIN(v,max),min)
#define ENOUGH(v,unit)  (((v)-1)/(unit)+1)
#define EZ(v,unit)  ((v)?ENOUGH(v,unit):0)

#define XFER_MODE   0xf0
#define XFER_UDMA_100   0x44
#define XFER_UDMA_660x42
#define XFER_UDMA   0x40
#define XFER_MWDMA  0x20
#define XFER_SWDMA  0x10
#define XFER_EPIO   0x01
#define XFER_PIO0x00

static short ide_find_best_mode(ide_drive_t *drive, int map)
{
struct hd_driveid *id = drive->id;
short best = 0;

if (!id)
return XFER_PIO_SLOW;

if ((map & XFER_UDMA) && (id->field_valid & 4)) {   /* Want UDMA and UDMA 
bitmap valid */

if ((map & XFER_UDMA_100) == XFER_UDMA_100)
if ((best = (id->dma_ultra & 0x0020) ? XFER_UDMA_5 : 0)) 
return best;

if ((map & XFER_UDMA_66) == XFER_UDMA_66)
if ((best = (id->dma_ultra & 0x0010) ? XFER_UDMA_4 :
(id->dma_ultra & 0x0008) ? XFER_UDMA_3 : 0)) 
return best;

if ((best = (id->dma_ult

Re: Hot swap IDE

[Andre Hedrick]

Unless you have a special bay that tri-states the buss or a host that does
it for the requested channel (yes that disables both devices) you can do
this once per mainboard.

There was a proposal for tri-stating the buss, but that was held for 2.5.
There is a partial reset IOCTL in 2.4, but it needs more additions to
recover the drive state.

Regardless, it can/has/currently can be done, just the general kernels can
not do it yet.

There is a cool card by Iwill that is HPT368 based that does this nicely.

You stoke the card the right way and the drive power goes away, then
stroke it a different way to tri-state the channel...etc
Pull ribbon first then power connector and change drives.

Reconnect power first to set interface to tri-state (obviously the gound
lines define the state) then the ribbon, stroke channel active, then
stroke the power.

Init device rescan (missing), revalidation (present), etc ..

Forgot the rest but it is written somewhere in the cave.

 
On Thu, 5 Oct 2000, Mitchell Hicks wrote:

> Lots of great info on the list thank you all!!!
> after reading i think most of the software raid howto's and hardware one's 
> also..
> I've Built a box with 3 drives and a hot spare..
> 
> p iii 500 256meg ram aus mother board (i think via chip set)
> two promise ata66 cards and 5 30 gig maxtor drives in promise ata66 hot 
> swap drive bays.
> 
> windows nt... just kidding... linux2.4.0-test9 and it's working great... 
> worked in test8 test6 was not good
> I have not had to rebuild the array from scratch since moving to test8 (the 
> hotremove did not work)
> 
> if i compile the promise drivers then when i power off a drive for testing 
> a failure the system freezes(i might not have done the sysrq correctly) i 
> have to power off the system
> 
> if i don't compile the promise drivers i can enable DMA (and am very happy 
> very FAST).
> 
> there does not seem to be a command to reset the IDE buss(this is mentioned 
> in the raid howto's) can i compile the IDE drivers as a module and 
> remove/install then while the system is running on the raid(i think not)... 
> I'm booting from a 20 meg none raid drive (to be raid 1 in final production)
> 
> i can replace the drive but it must be with the same type of drive... but 
> the system's not really happy about the drive change and complains if the 
> drive was partioned ..
> 
> ide software raid seems soo close to ready for production...
> 
> I have turned the system OFF several times and just turned off one drive... 
> then the system while it's rebuilding the array... even booted with a 
> failed drive...
> 
> I tried some of this stuff with 2.2.16 redhat it was ugly..  as in 
> complete reinstall and the system could not boot  if a drive was failed (i 
> accepect that this could be me)
> 
> Thank you for your time... and a GREAT OS
> 
> Mitchell Hicks
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

Andre Hedrick
The Linux ATA/IDE guy

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

Re: [preview] VIA v3.6 and AMD v1.2 IDE drivers

[Andre Hedrick]

You are just having to much fun!


On Fri, 6 Oct 2000, Vojtech Pavlik wrote:

> Hi!
> 
> For those who like to try out the very latest developments, I'm
> including my latest VIA and AMD IDE tuning drivers.
> 
> Just place all the files in drivers/ide of a 2.4 kernel and have fun.
> 
> Of course, I'm interested in all success/failure stories.
> 
> Thanks.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> 

Andre Hedrick
The Linux ATA/IDE guy

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

Re: [preview] VIA v3.6 and AMD v1.2 IDE drivers

[Vojtech Pavlik]

On Fri, Oct 06, 2000 at 01:58:52AM -0700, Andre Hedrick wrote:

> You are just having to much fun!

Oh yes, I am. :) Just found yet-another-vt82c686a-bug. With heavy IDE disk
activity at UDMA66 speed the PIT (i8253) latch register gets reset to a
random value now and then. Seems like some interference inside the chip.

The time on the machine then behaves rather funny ... I wonder if this
affects other VIA chips as well or just my stepping CD silicon of the 686a.

By the way, any comments about the new VIA & AMD drivers, and the
ide-tuning.h include file?

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

Re: is there a limit on bss size?

[Petko Manolov]

Philipp Rumpf wrote:
> 
> On Thu, Oct 05, 2000 at 04:30:35PM +0100, Tigran Aivazian wrote:
> > Hi,
> >
> > I put a simple construct in kernel/sched.c like this:
> >
> > struct runq_log_s {
> > char comm[16];
> > int  pid;
> > } runq_log[1024*1024];
> >
> > and the kernel didn't boot. Yes, I understand it is 20M of bss - so what?


Is it impossible to allocate this array dynamically? I am not sure if we
have
to change too many things in startup code. If yes, we must have good
enough
arguments for Linus.


> Look at the code in arch/i386/kernel/entry.S that initializes our temporary
> page tables:


Actually this code is from arch/i386/kernel/head.S ;-) 

 
> /*
>  * Initialize page tables
>  */
> movl $pg0-__PAGE_OFFSET,%edi /* initialize page tables */
> movl $007,%eax  /* "007" doesn't mean with right to kill, but
>PRESENT+RW+USER */
> 2:  stosl
> add $0x1000,%eax
> cmp $empty_zero_page-__PAGE_OFFSET,%edi
> jne 2b


Actually when/where exactly mm init takes place should be checked first.


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

Re: Benchmark results for elv_test

[Robert Cohen]

Your point is taken to a certain extent.
Its true that the files here are not necessarily going to be laid our
sequentially on disk.
However, they will be laid out far enough apart to cause some seeking
which will put load on the elevator.

And even if this program isn't putting incredible stress on the
elevator, it is a simple program doing simple file operations and the
kernel should be able to handle it efficiently. Which current 2.4.0
kernels aren't doing.

Your right about the reads being synchronous, but the writes shouldnt be
synchronous. I dont do the fsync's until all the files are written. So
this should be testing the write elevator at least, which is where the
performance problem is showing.

This test was deliberately written as a single process so that the order
of operations is controlled.
If I use multiple threads, each working on a separate file, then each
thread tends to get an entire timeslice and so a lot of operations on
one file will be done sequentially which defeats the purpose.
I might try a version using asynch io calls.

I wanted to write it using standard IO paths as much as possible. If I
use esoteric technolgies like the NWFS stuff, then its not clear if
performance problems found are in the kernel or in the unusual libraries
used.

Robert Cohen
Australian National University

 J. Robert von Behren ([EMAIL PROTECTED]) write

>Looking over your test program, I don't think you are actually testing
>the elevator algorithm at all. There are a couple of key flaws:

>  * The reads and writes are synchronous, so the elevator algorithm
>at _most_ gets to effect the blocks within a single read or
>write (ie - inside the same file).

>  * The fact that you have written the files out all at once will not
>place all 240 megs of data consecutively on the disk. The file
>system spreads out data on disk to allow breathing room for
>adding new files, or appending to existing files. In particular,
>this means that although large subsections of blocks that are
>   adjacent in the logical file _will_ be close by on disk, you cannot
>generalize from this that these large subsections will be close to
>each other - either within a single file, or between the files
>created by the test program.

>  * Unless the partition is completely empty, existing file data will
>effect where new data is placed (and in particular how well
>co-located   it can be).

>A better approach to testing the elevator algorithm would be to write
>directly to a raw device, instead of going through the file system.
>This would allow you better control over actual disk placement of
>blocks, and let you know what you were testing. It would also allow you

>to make sure that subsequent re-tests would be repeatable, as they
>shouldn't be effected by existing data. Finally, to do this test right,

>you need to be able to issue multiple IO requests to the disk at
>essentially the same time. To do this, you'll probably need to go
>multithreaded, and use a barrier of some sort to make sure the threads
>stay synchronized.

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

Re: is there a limit on bss size?

[Tigran Aivazian]

On Fri, 6 Oct 2000, Petko Manolov wrote:

> Philipp Rumpf wrote:
> > 
> > On Thu, Oct 05, 2000 at 04:30:35PM +0100, Tigran Aivazian wrote:
> > > Hi,
> > >
> > > I put a simple construct in kernel/sched.c like this:
> > >
> > > struct runq_log_s {
> > > char comm[16];
> > > int  pid;
> > > } runq_log[1024*1024];
> > >
> > > and the kernel didn't boot. Yes, I understand it is 20M of bss - so what?
> 
> 
> Is it impossible to allocate this array dynamically? I am not sure if we
> have
> to change too many things in startup code. If yes, we must have good
> enough
> arguments for Linus.
> 

Nobody is suggesting to make any arguments for Linus. That code was just a
trivial "runq history log" thing I needed for finding out why the load on
my machine is always (at least) 1.0 and yet there is no apparent process
to be blamed for it.

What Philipp says is an interesting excercise and I might try it
today. (for my present purposes reducing the size of the log was
sufficient).

Regards,
Tigran

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

Re: is there a limit on bss size?

[Petko Manolov]

It is not so difficult as it looks.
The master pgd looking as:

.org 0x1000
ENTRY(swapper_pg_dir)
.long 0x00102007
.long 0x00103007
.fill BOOT_USER_PGD_PTRS-2,4,0
/* default: 766 entries */
.long 0x00102007
.long 0x00103007
/* default: 254 entries */
.fill BOOT_KERNEL_PGD_PTRS-2,4,0


should become:


.org 0x1000
ENTRY(swapper_pg_dir)
.long 0x00102007
.long 0x00103007
# every entry addresses 4 MB exactly
# so add as much as you want
.long 0x0010X007
.fill BOOT_USER_PGD_PTRS-X+2,4,0
/* default: 766-X entries */
.long 0x00102007
.long 0x00103007
# every entry addresses 4 MB exactly
# so add as much as you want
/* default: 254-X entries */
.fill BOOT_KERNEL_PGD_PTRS-X+2,4,0


empty_zero_page, empty_bad_page, etc... offsets should be also
appropriately changed and the corresponding code in mm init as
well.


But i honestly don't see the point of all that.


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

Re: Status of ReiserFS + Journalling

[Neil Brown]

On Friday October 6, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> > Suppose, for stripe X the parity device is device 1 and we were
> > updating the block on device 0 at the time of system failure.
> > What had happened was that the new parity block was written out, but
> > the new data block wasn't.
> > Suppose further than when the system come back, device 2 has failed.
> > We now cannot recover the data that was on stripe X, device 2.  If we
> > tried, we would xor all the blocks from working devices together and I
> > hope that you can see that this would be the wrong answer.  This poor,
> > innocent, block, which hasn't been modified for years, has just been
> > corrupted.  Not good for PR.
> 
> Now that I'm getting better at thinking about this I can see that a very
> simple journal will protect from this particular problem.  A phase-tree
> style approach would likely to the job more efficiently, once again. 
> Here's the ultimate simple approach: why not treat an entire stripe as
> one block?  That way you never get 'innocent blocks' on your stripe.

yyye. uttt...

There was a detail (one of many probably) that I skipped in my brief
description of raid5.
Every block on the raid5 array has a two dimensional address 
   (discnumber, blocknumber)
This needs to be mapped into the linear address space expected by a
filesystem (unless you have a clever filesystem that understand two
dimensional addressing and copes with holes where the parity blocks
are).
Two extremes of ways to do this are:

  abc-   afk-
  de-f   bg-o
  g-hi   c-lp
  -jkl   -hmq
  mno-   din-
  qp-r   ej-r

where letters are logical block addresses, hyphens are parity blocks,
columns are drives, and rows a physical block numbers.

What is typically done it to define a cluster size, and then address
down the drive for a cluster, and then step across to the next driver
for the next cluster, so with a cluster size of 3, the above array
would be

  adg-
  beh-
  cfi-
  jm-p
  hn-q
  lo-r

(notice that the parity blocks come in clusters like the data blocks).
There is a trade off when choosing cluster size.
A cluster size of 1 (as it in the very first picture above) means that
any sequential access will probably use all drives, and so you should
see appropriate speed ups for read, and you might be able to avoid
reading old data for writes (as when you write a whole stripe you
don't need to read old data to calculate parity).
This is good if you have just a single thread accessing the array.

A large cluster size (e.g. 64k) means that most accesses will use only
one drive (for read) or two drives (for write - data + parity).  This
means that multiple threads that access the array concurrently and not
always be tripping over each other (sometimes, but not always) (this
is called 'head contention').

There is a formular that I have seen, but cannot remember, which links
typical IO size, and typical number of concurrent threads to ideal
cluster size.  

Issues of drive geometry come into this too.  If you are going to read
any of a track, you may as well read all of it.  So having a cluster
size that was a multiple of the track size would be good (if only
drives have constant sized tracks!!).

Back to your idea.  Having each stripe be one filesystem block means
either having large filesystem blocks (meaning lots of wastage) or
having a cluster size of 1.

Unfortuately, with Linux Software Raid, the minimum cluster size is one
page, and the maximum filesystem block size is one page, so we cannot
try this out on linux to see how it actually works.


My understand of the way WOFL works is that it uses RAID4, so there are
no parity holes to worry about (RAID4 has all the parity on the one
drive) and WOFL knows about the 2-D structure.
It tries to lay out whole files (or large clusters of each file) on to
one disk each, but hopes to have enough files that need writing at one time
that it can write them all, one onto each disc, and thus keep all the
discs busy while writing, but still have reduced head contention when
reading. 

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

Re: The case for a standard kernel debugger

[richardj_moore]

Completely agree - co-operation+integration is the order of the day. They
other thing I didn't mention was that the GKHI was substantially coded
before we discovered your hook capability. Part of the GKHI is also to
allow hooks to be dynamicaly defined i.e. to allow kernel modules to
declare hooks themselves, though I haven't yet implemented that - the
design is done. The MP complient remark  refers to the fact that the hook
mechanism must work under MP. Our hooks are implemented by modifying code
dynamically - that has certain serialisation requrements: you need to
ensure that other processors see a consistent view of memory, which means
that you need to stop them while you're change code dynamically and also
flush their I-fetch caches. There are some very odd (H/W) behavious that
can occur with self-modifying code if the appropriate measures are not
taken.

Our uniprocessor version of GKHI is being tested as I write. We hope to
release it in the next couple of weeks. As soon as we are happy with it I
will send you a copy so you can evaluate it against you hook methodology
and we can see what ecconomies can be established.

And talking further of co-operation. I'd like to make DProbes drive your
trace facility. Did you see the announcement post I sent to LTT? The idea
is that DProbes is an enabler for other RAS facilities. We can dynamically
insert a probe anywhere into memory (user and kernel) without the need for
re-compilation of the source. From the RPN program that's driven by the
probe event handler we can initiate other facilities such as entering SGI's
kernel debugger or invoking Crash Dump or forcing a core dump. Now, DProbes
came from OS/2 and was called dynamic trace. Its original purpose was to
implement tracepoints on the fly. We can still do that with DProbes,
provided we have a tracing mechanism we can feed into. That's where you
come in. Can you provide an interface we can call from kernel space to log
a trace event with a variable length buffer?


Richard Moore -  RAS Project Lead - Linux Technology Centre (PISC).

http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK


Karim Yaghmour <[EMAIL PROTECTED]> on 06/10/2000 09:16:12

Please respond to Karim Yaghmour <[EMAIL PROTECTED]>

To:   Richard J Moore/UK/IBM@IBMGB
cc:   [EMAIL PROTECTED]
Subject:  Re: The case for a standard kernel debugger





Hello Richard,

Part of your analysis is correct. The hooks were designed to take care of
static tracepoints only. That said, dynamic allocation of event IDs was
next on my list and the hooking mechanism would have been modified
consequently.

As for "multiple exits registered per hook", if you mean that you can have
more
than one function called back for each event, then this is already
possible.
The other items you mention such as atomicity and prioritization seem
interesting
indeed, although I am not sure what you mean by MP compliant as the only
thing that stops the current generalized hooking mechanism to be MP
compliant
is the insertion of correct locks during callback registration.

Please understand that the purpose wasn't to discredit your work, but
rather
to stop duplication of work as efforts could be deployed elsewhere. I think
that your work and the work already done on LTT can be brought together in
a way that would profit all. This is what I was hinting to towards the end
of the posting. It was an invitation more than anything else.

Apart from the hooking mechanism, there were other items which I mentioned
that merit discussion, such as the ability to enable dynamic probes to log
events in normal LTT traces or the event-driven state machine engine.
Hence,
if you are interested in joining forces to further enhance probing and
tracing
capabilities in Linux, I think this would be a good opportunity.

Best regards

Karim

[EMAIL PROTECTED] wrote:
>
> Yes, we looked at that and it didn't seem to provide the generality we
> needed - multipe exits registered per hook, ability to arm a set of hooks
> atomically, ability to prioritise dispatching order of a hook exit, MP
> complient. I may be wrong but the Linux Trace Toolkit hooks like like
they
> were specifically designed to cater for inserting static tracepoints into
> the kernel.
>
> Richard Moore -  RAS Project Lead - Linux Technology Centre (PISC).
>
> http://oss.software.ibm.com/developerworks/opensource/linux
> Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
> IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK

--
===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m

Network connectivity /w 2.4.0-test9 ?

[Willis L. Sarka]

Greetings,

I just compiled kernel 2.4.0-test9 on my old HP Vectra 486/25NI.  I have
three 3c509 Etherlink III cards installed, and was wanting to play around
with netfilter on this box.  All of the cards are recognized and
configured on a stock RH 7.0 install, and I can ping other hosts on the
same subnet.

My first question is that I have compiled in 3c509 support into the
kernel, and supplied the appropriate append= line to lilo.conf, but yet,
the kernel is still only initializing 2 cards out of 3.  Perhaps I'm doing
someting wrong, if so, please let me know.

Even with the 2 cards that _do_ initialize and come up, I can then not
ping another host on the same subnet.  Again, perhaps I'm missing
something and someone can enlighten me :-).  I have some tcpdump output of
this host trying to ping another host on the same network.  I've included
the tcpdump output, my kernel config, and some other info below for
completeness.  


tcpdump output:

08:57:42.174001 eth0 > arp who-has 192.168.1.66 tell 192.168.1.253
(0:20:af:1e:0
:a0)
08:57:42.204001 eth0 > arp who-has 192.168.1.1 tell 192.168.1.253
(0:20:af:1e:0:
a0)
08:57:43.174001 eth0 > arp who-has 192.168.1.66 tell 192.168.1.253
(0:20:af:1e:0
:a0)
08:57:43.204001 eth0 > arp who-has 192.168.1.1 tell 192.168.1.253
(0:20:af:1e:0:
a0)
08:57:44.174001 eth0 > arp who-has 192.168.1.66 tell 192.168.1.253
(0:20:af:1e:0
:a0)
08:57:44.204001 eth0 > arp who-has 192.168.1.1 tell 192.168.1.253
(0:20:af:1e:0:
a0)
08:57:45.174001   lo > 192.168.1.253 > 192.168.1.253: icmp: host
192.168.1.66 un
reachable (DF) [tos 0xc0]
08:57:45.174001   lo > 192.168.1.253 > 192.168.1.253: icmp: host
192.168.1.66 un
reachable (DF) [tos 0xc0]
08:57:45.174001   lo > 192.168.1.253 > 192.168.1.253: icmp: host
192.168.1.66 un
reachable (DF) [tos 0xc0]
08:57:45.174001   lo < 192.168.1.253 > 192.168.1.253: icmp: host
192.168.1.66 un
reachable (DF) [tos 0xc0]


[root@kerberos /root]# cat /proc/cpuinfo

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 5
model   : 3
model name  : OverDrive PODP5V83
stepping: 2
cpu MHz : 0.00
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: yes
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr cx8
bogomips: 24.88

---

dmesg output:

Linux version 2.4.0-test9 ([EMAIL PROTECTED]) (gcc version
2.96 27
1 (Red Hat Linux 7.0)) #1 Fri Oct 6 02:03:51 GMT 2000
BIOS-provided physical RAM map:
 BIOS-88: 0009f000 @  (usable)
 BIOS-88: 0170 @ 0010 (usable)
On node 0 totalpages: 6144
zone(0): 4096 pages.
zone(1): 2048 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux.new ro root=301
BOOT_FILE=/boot/vmlinuz-2.4.0
test9 ether=11,0x320,eth0 ether=7,0x310,eth1 ether=5,0x300,eth2
Initializing CPU#0
Console: colour VGA+ 80x25
Calibrating delay loop... 24.88 BogoMIPS
Memory: 22536k/24576k available (945k kernel code, 1652k reserved, 54k
data, 48k in
t, 0k highmem)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
CPU: Intel OverDrive PODP5V83 stepping 02
Checking 'hlt' instruction... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
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 2048 bind 2048)
Initializing RT netlink socket
Starting kswapd v1.8
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=xx
hda: QUANTUM FIREBALL1080A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 2128896 sectors (1090 MB) w/83KiB Cache, CHS=528/64/63
Partition check:
 hda: hda1 hda2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
eth0: 3c509 at 0x320, BNC port, address  00 20 af 1e 00 a0, IRQ 11.
3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED]
eth2: 3c509 at 0x300, BNC port, address  00 20 af 23 6d e0, IRQ 5.
3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED]
Serial driver version 5.02 (2000-08-09) with no serial options enabled
Real Time Clock Driver v1.10c
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 48k freed
Adding Swap: 34264k swap-space (priority -1)
eth0: Setting Rx mode to 1 addre

Re: The case for a standard kernel debugger

[Karim Yaghmour]

Thought I'd let you know that I will reply to your suggestions (which
are quite interesting by the way) ... but I need to catch up some sleep
as it's close to 7AM here in Montreal and my brains are failing ... ;)

===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

lowish-latency patch for 2.4.0-test9

[Andrew Morton]

The little-low-latency patch for test9 is at

http://www.uow.edu.au/~andrewm/linux/2.4.0-test9-low-latency.patch

Notes:

- It now passes Benno's tests with 50% headroom (thanks to
  Ingo's scheduler race fix).

- Updated to follow the wandering ext2 truncate code.

- Updated for the new VM.  (I'll have to ask Rik to take a
  look at this part sometime).

- Set TASK_RUNNING in conditional_schedule().

  This is probably unnecessary - current->state appears to be
  always equal to TASK_RUNNING in the places I'm using it.

  So we test for this beforehand to avoid unnecessarily dirtying
  cache lines.

  (This optimisation should be done anyway, especially for SMP).

- net/ipv4/tcp_minisocks.c:tcp_twkill() can spend tens or even
  hundreds of milliseconds within a timer handler.  I have a
  fix for this, but Alexey agrees that this needs to be
  addressed independently of the low-latency patch.  So this file
  is untouched.

- This entire feature has been *disabled* for SMP.  This patch
  is now UP-only.

  It is completely stable on SMP and the scheduling latency is
  just grand, as long as you don't push things too hard.  It
  then comes unstuck.

  This is because of the following scenario:

  * CPU1 holds a long-lived spinlock such as dcache_lock
in select_parent().

  * CPU0 is spinning on the same lock.

  * An interrupt occurs and the kernel tries to wake up
your SCHED_FIFO task on CPU0.

  You lose.  Nothing happens until CPU1 releases the lock
  a week later.

  There are a number of ways of fixing this, but they're
  messy.

  One way is to identify those locks and to add a test for
  current->need_resched into the spin.  This gets nastier
  if the BKL is held at the same time.

  Another way is to write a fully-preemptible SMP kernel
  patch :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.2.18pre15 mouse problems (cont.)

[Steven N. Hirsch]

Alan,

Again, not sure if you are getting these reports (my mail to you is
bouncing), but 2.2.18pre15 is still insisting that I have a ps/2 mouse
connected to my machine (it uses a serial mouseman on COM2).

The sluggishness and missed button-down events are no longer present,
though.

Steve


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

Re: linux-2.4.0-test9

[Jamie Lokier]

Keith Owens wrote:
> >Put __attribute__ ((section (".data"))) into __tcp_clean_cacheline_pad
> >and it should do what you want.
> >
> >Heck, section ".bss" might give you the alignment without the allocation
> >but I'm not as confident about that.
> 
> Call me mad but you could actually try this instead of guessing.

I just tried it with "gcc 2.96" (RedHat 7's edition) and that _does_
work.  Good old egcs 1.1.2 gives the broken behaviour you describe.

int __attribute__ ((section (".data.init"))) x1;
int __attribute__ ((aligned (32), section (".data.init"))) x2;
int __attribute__ ((section (".data.init"))) x3 = 0;

$ gcc --version
2.96
$ as --version
GNU assembler 2.10.90
...
$ gcc -c test.c
$ objdump -h test.o
...
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text       0034  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data       0034  2**2
  CONTENTS, ALLOC, LOAD, DATA
  2 .bss        0034  2**2
  ALLOC
  3 .note 0014      0034  2**0
  CONTENTS, READONLY
  4 .data.init0024      0060  2**5
  CONTENTS, ALLOC, LOAD, DATA
  5 .comment  0029      0084  2**0
  CONTENTS, READONLY

Another one with .bss section gives a warning, but also works, even
preserving alignment in the .bss section:

int __attribute__ ((section (".bss"))) x1;
int __attribute__ ((aligned (32), section (".bss"))) x2;
int __attribute__ ((section (".bss"))) x3;

$ gcc test.c
/tmp/cc6KLZDY.s: Assembler messages:
/tmp/cc6KLZDY.s:5: Warning: Ignoring incorrect section type for .bss
$ objdump -h test.o
...
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text       0034  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data       0034  2**2
  CONTENTS, ALLOC, LOAD, DATA
  2 .bss  0028      0040  2**5
  ALLOC
  3 .note 0014      0040  2**0
  CONTENTS, READONLY
  4 .comment  0029      0054  2**0
  CONTENTS, READONLY

$ nm test.o
 t gcc2_compiled.
 B x1
0020 B x2
0024 B x3

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

2.4.0-test9 compile error (make dep) on Sun4m SparcSystem600

[Taco IJsselmuiden]

Hi,

When trying to compile 2.4.0-test9 on my Sun4m SparcSystem600 it gives an
error dring 'make dep':


galaxy:/usr/src/kernel-source-2.4.0-test9# make dep
make -C arch/sparc/kernel check_asm
make[1]: Entering directory
`/usr/src/kernel-source-2.4.0-test9/arch/sparc/kernel'
gcc272 -E -D__KERNEL__ -I/usr/src/kernel-source-2.4.0-test9/include tmp.c
-o tmp.i
/bin/sh ./check_asm.sh -data task tmp.i check_asm_data.c
/bin/sh ./check_asm.sh -data mm tmp.i check_asm_data.c
/bin/sh ./check_asm.sh -data thread tmp.i check_asm_data.c
gcc272 -D__KERNEL__ -I/usr/src/kernel-source-2.4.0-test9/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mno-fpu -fcall-used-g5
-fcall-used-g7  -S -o check_asm_data.s check_asm_data.c
/bin/sh ./check_asm.sh -ints check_asm_data.s check_asm.c
/bin/sh ./check_asm.sh -printf task tmp.i check_asm.c
/bin/sh ./check_asm.sh -printf mm tmp.i check_asm.c
/bin/sh ./check_asm.sh -printf thread tmp.i check_asm.c
gcc272 -o check_asm check_asm.c
check_asm.c:5: parse error before `0'
make[1]: *** [check_asm] Error 1
make[1]: Leaving directory
`/usr/src/kernel-source-2.4.0-test9/arch/sparc/kernel'
make: *** [check_asm] Error 2
galaxy:/usr/src/kernel-source-2.4.0-test9# 

It's the first 2.4.0-test I tried on this machine ;(

Anyone knows a fix ?

Greetz,
Taco.
---
"I was only 75 years old when I met her and I was still a kid"
  -- Duncan McLeod

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

Re: Status of ReiserFS + Journalling

[Helge Hafting]

Jeremy Fitzhardinge wrote:
> 
> On Thu, Oct 05, 2000 at 11:33:30AM +0200, Helge Hafting wrote:
> > A power failure might leave you with a corrupt disk block.  That is
> > detectable (read failure) and you may then reconstruct it using the
> > rest of the stripe.  This will get you data from either before
> > or after the update was supposed to happen.
> 
> How would you be able to tell which disk contains the bad stripe?
> RAID reconstruction relies on knowing which disk to reconstruct because
> it's obviously bad - there's out of band information in the form
> of I/O errors.  If you only have an incompletely updated stripe on
> a disk, you don't know which data to reconstruct from parity.
> 
Correct.  RAID won't help you if one disk is updated flawlessly
but not the others.  It is a guard against disk breakdown only.

> I think the only way of doing this properly is to either have
> battery-backed cache, or by having journalling at the RAID level.

Isn't this something a journalling _fs_ is supposed to fix?
You don't really need journalling at the raid level,
the raid should (on a dirty startup) notice the dirtiness, and
check every stripe for correct parity.  (In a raid check, or
by using a degraded mode where every stripe is read
completely and checked before access.)

The raid can then inform the fs that the entire stripe is corrupt
when parity is bad, and the fs can fix this by replaying
its journal (or using a fsck).

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

Compiling 2.2 on Pentium

[Ulrich Windl]

Hi,

I noticed that when compiling with gcc-2.95.2 for a Pentium the flag "-
m486" ist still passed to gcc. However gcc-2.95.2 generates different 
code if "-m586" is used (older versions ended at -m486).

Is the makefile intentionally not updated, or was it just forgotten?

Regards,
Ulrich

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

Re: v2.4.0test9 NFSv3 server woes Linux-->Solaris

[Trond Myklebust]

> " " == David Weinehall <[EMAIL PROTECTED]> writes:

>> 2.4.0-pre9 should default to rsize/wsize == whatever Solaris
>> asks for (32k in practice). It does on my setup...

 > I'm talking about the client, not the server. Thus, it's the
 > Linux machine that makes the request, not the Solaris machine.

So am I. For NFSv3, the server gets a say in what it would like you
(the client) to use both for rsize, wsize and dtsize (directories).

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

Re: locking user memory

[Eric Lowe]

Hello,

> My driver needs to do a large DMA in the user address. Is there a way i can
> ensure the user buffer is  not swapped out, while i am doing the IO.
> Please CC your mail to [EMAIL PROTECTED]
> 

Have a look at map_user_kiobuf() and friends in 2.4..  They're
available as part of the raw I/O patch for 2.2.  Replay if you
need a recent one against 2.2.17, I have it.

--
Eric Lowe
Software Engineer, Systran Corporation
[EMAIL PROTECTED]


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

[PATCH] PCI detection in 2.2.x and 2.4.0

[Rasmus Andersen]

Hi.

(This mail is a repeat from an earlier l-k mail.)

I recently had a problem with linux 2.2.x and 2.4.0 oopsing early
in the boot process on a old pentium I had gotten hold of. printk
investigation showed the problem to be in the PCI detection code,
specifically the part where linux tries to go through the BIOS to
get the PCI settings. Picking 'Direct' (CONFIG_PCI_GODIRECT) make
the boot succeed where 'Any' had not.

This stumped me since the help text had led me to believe
otherwise: The help text states that if CONFIG_PCI_GOANY is set
linux will first try to detect the settings directly and go
through BIOS if this fails. The code first goes through BIOS to
get the settings, then gets them directly and then pick the
direct settings (if valid) otherwise the BIOS settings (if
valid).

The following patches fixes the code to follow the help text.  I
am not sure if this is the correct fix (vs. changing the documen-
tation), but I prefer it since it makes my machine boot :)

Patches for both 2.4.0-test9-pre7 and 2.2.18pre10. Please comment.


2.4.0-test9-pre7:

--- linux-240test9-pre7-clean/arch/i386/kernel/pci-pc.c Mon Jul 31 21:03:10 2000
+++ linux/arch/i386/kernel/pci-pc.c Sat Sep 30 20:36:10 2000
@@ -962,15 +962,15 @@
struct pci_ops *bios = NULL;
struct pci_ops *dir = NULL;
 
+#ifdef CONFIG_PCI_DIRECT
+   if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
+   dir = pci_check_direct();
+#endif
 #ifdef CONFIG_PCI_BIOS
-   if ((pci_probe & PCI_PROBE_BIOS) && ((bios = pci_find_bios( {
+   if ((pci_probe & PCI_PROBE_BIOS) && (!dir) && ((bios = pci_find_bios( {
pci_probe |= PCI_BIOS_SORT;
pci_bios_present = 1;
}
-#endif
-#ifdef CONFIG_PCI_DIRECT
-   if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
-   dir = pci_check_direct();
 #endif
if (dir)
pci_root_ops = dir;



2.2.18-pre10:


--- linux-2.2.18pre10/arch/i386/kernel/bios32.c.org Mon Sep 25 16:37:03 2000
+++ linux-2.2.18pre10/arch/i386/kernel/bios32.c Mon Sep 25 16:39:28 2000
@@ -1267,15 +1267,15 @@
struct pci_access *bios = NULL;
struct pci_access *dir = NULL;
 
+#ifdef CONFIG_PCI_DIRECT
+   if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
+   dir = pci_check_direct();
+#endif
 #ifdef CONFIG_PCI_BIOS
-   if ((pci_probe & PCI_PROBE_BIOS) && ((bios = pci_find_bios( {
+   if ((pci_probe & PCI_PROBE_BIOS) && (!dir) ((bios = pci_find_bios( {
pci_probe |= PCI_BIOS_SORT;
pci_bios_present = 1;
}
-#endif
-#ifdef CONFIG_PCI_DIRECT
-   if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
-   dir = pci_check_direct();
 #endif
if (dir)
access_pci = dir;



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

ll_rw_block() changes buffer_heads to NULL?

[Matt_Domsch]

> I'm still trying to read physical sectors, and have made progress.  Thanks
> for the pointers on set_blocksize(), that seems to do the trick.
> 
> However, now I've got another problem.  When I read blocks "too quickly",
> I guess the elevator algorithm in ll_rw_block() kicks in and re-organizes
> my buffer_head structures?  I'm trying to read 1 sector (which succeeds
> just fine), then 32 sectors, one at a time, which fails.
> ReadLBA(2) - OK
> ReadLBA(3) - OK
> ReadLBA(4) - fails, kernel dereferences NULL, 
> 
> All calls to getblk() succeed, and none of my buffer heads are NULL.  I
> pass this array to ll_rw_block(), which rewrites my array, leaving most of
> my buffer_head pointers as NULL.  So, I thought, that for each buffer head
> that isn't NULL, maybe my next buffer head is in b_reqnext, but nope.
> It's NULL too.
> 
FWIW, this is the second version of my function.  Originally, I just looped,
calling bread(dev, lba++, blocksize), which oops in the same way.  Both
IA-32 and IA-64, kernel 2.4.0-test9.

> TIA for your help.
> -Matt
> 
> struct buffer_head ** my_bread(kdev_t dev, u64 lba, u64 blockstoread)
> {
>   struct buffer_head **bh, *thisbh;
> 
>   unsigned int blocksize = get_hardblocksize(dev);
>   unsigned int i;
>   if (!blocksize) blocksize = 512;
>   printk(KERN_INFO "about to getblk %d blocks\n", blockstoread);
>   
>   bh = kmalloc(GFP_KERNEL, blockstoread * sizeof(struct buffer_head *));
>   if (!bh) return NULL;
> 
>   for (i=0; i bh[i] = getblk(dev, lba+i, blocksize);
> if (!bh[i]) {
>   printk(KERN_WARNING, "getblk(lba=%x) failed.\n", lba);
> }
>   }
> 
>  /* at this point, none of the bh[i]s are NULL. */
> 
> ll_rw_block(READ, blockstoread, bh);
> 
>   /* now, all but the first 3 bh[i]s are NULL, and all bh[i]->b_reqnext ==
> NULL */
> 
>   /* Walk the chain */
>   for (i=0; i if (!bh[i]) continue;
> 
> thisbh = bh[i];
> do {
>   wait_on_buffer(thisbh);
>   if (!buffer_uptodate(thisbh)) {
> printk(KERN_WARNING "bh is not uptodate after waiting!\n");
>   }
>   thisbh = thisbh->b_reqnext;
>   if (thisbh) printk(KERN_INFO "my_bread walking the chain...\n");
> } while (thisbh);
>   }
> 
>   return bh;
> }
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] PCI detection in 2.2.x and 2.4.0

[Jeff Garzik]

On Fri, 6 Oct 2000, Rasmus Andersen wrote:
> This stumped me since the help text had led me to believe
> otherwise: The help text states that if CONFIG_PCI_GOANY is set
> linux will first try to detect the settings directly and go
> through BIOS if this fails. The code first goes through BIOS to
> get the settings, then gets them directly and then pick the
> direct settings (if valid) otherwise the BIOS settings (if
> valid).
> 
> Patches for both 2.4.0-test9-pre7 and 2.2.18pre10. Please comment.

The patch looks ok to me and I agree with the logic... I am also
interested in Martin's comments, though, just in case the existing code
is there for a reason.  (obviously an oops is a problem, though...)

Jeff





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

Re: [PATCH] Support for CS89x0 based PCMCIA cards

[Peter De Schrijver]

Hi,

> p2 wrote:
> > 
> > Hi *,
> > 
> > Attached you will find a patch which adds support for CS89x0 base PCMCIA
> > cards such as the IBM EtherJet.
> 
> Great work!
> 
> Did you know that Danilo Beuche has written a Card Services driver for
> this device? An old version of that driver currently resides somewhere
> in the `contrib' area of http://pcmcia-cs.sourceforge.net (sorry, I
> don't have the exact URL - the internet has stopped).  His current page
> is at http://www.first.gmd.de/~danilo/pc-driver/ and his driver seems
> fairly current for kernel 2.2.
> 

I knew about the existance of Danilo's driver, but I didn't know there was
a 2.4.x release. As I wanted to use the card under 2.4 and I thought it
would be better to share as much code as possible between drivers for different
cards based on the CS89x0 chipset, I made a driver based on the 2.4.0-test9
CS89x0 driver for ISA cards.

> Could I suggest that you review Danilo's driver against yours? He may
> have additional device support, etc.
> 

Ok. I will do so.

> Once you've done that I'd suggest that we use a common header file
> between the ISA and PCMCIA drivers.   I'm open to suggestions on whether
> you think a common .c file is appropriate.
> 

I think it is. Only a small part of the code is busdependant. Improvements
and bug fixes to the common part of the code are automatically available on 
all cards if we share this part. The CS89x0 chip is also used on a number of
embedded systems (eg. the Cirrus Logic EP7211 development board). In a
future version support for these implementations could be added easily
if we have a common part. A similar approach is used for the PCMCIA ibm 
tokenring driver.

> Unfortunately your work is based on an older version of the 2.4 driver
> and it doesn't include some EEPROM and IRQ work from Jason Gunthorpe.
> 

Ok. I didn't know of the existance of a new version. Where can I find it ?

> More unfortunately, the 2.4.0-test9 cs89x0.c isn't up-to-date.  I have a
> few minor changes here which I wasn't planning on submitting until
> post-2.4.0.
> 

I realize my code may not be included in 2.4.0, but I decided to release
it on LKM nonetheless to see if other people are interested.
 
> I'd also suggest that we ask David Hinds to review your driver - I'm not
> at all familiar with the Card Services interfaces.
> 

Ok. That's fine.

> Anyway, I'll send you the diffs against the current cs89x0.c and we can
> work this off-list a bit, see where it ends up.

Ok. That's fine.

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

Re: [preview] VIA v3.6 and AMD v1.2 IDE drivers

[Vojtech Pavlik]

On Fri, Oct 06, 2000 at 08:04:42AM -0400, Byron Stanoszek wrote:
> On Fri, 6 Oct 2000, Vojtech Pavlik wrote:
> 
> > Hi!
> > 
> > For those who like to try out the very latest developments, I'm
> > including my latest VIA and AMD IDE tuning drivers.
> > 
> > Just place all the files in drivers/ide of a 2.4 kernel and have fun.
> > 
> > Of course, I'm interested in all success/failure stories.
> 
> Hi there. I have not had a chance to test my kernel with your patch yet, but I
> couldn't help noticing a glob of timing code in your ide-timing.h file. Did I
> miss something one day, or is the general concensus now to put code in header
> files? I'd prefer to see them as a separate module (ide-timing.c) or something
> that is compiled in for both via82cxxx.c and amd7540.c. What if you wanted both
> drivers for some reason, the code would get entered into the kernel twice.
> 
> Well, I assume it is in the header file because it is used by both .c files. If
> not, then it makes sense to just stick that code into one of the .c files.
> (Perhaps I should take a closer look at the code :).

It's a .h file just for the ease-of-use sake now. I'm planning to turn
it into a .c library file. However, that requires modificating the
makefiles and I needed a drop-in replacement for the moment.

> Anyway, I'm planning on doing some pretty big tests later tonight with that
> driver. One thing that I noticed while using v1.2 of the via82cxxx.c driver is
> that with a pci bus rate of 37mhz and a 33mhz udma dvd-rom (Pioneer 16x),
> playing a cd will suddenly stop playing on certain songs. These 'stop points'
> seem to be evenly distributed across the cd (every 12 minutes or so). Not sure
> exactly what it is, but I thought I'd bring it to your attention. I don't have
> enough testing performed on that to determine if it is overclocking the pci bus
> that caused that, or your driver, or something else. I do know that it worked
> fine in test7 with the old non-existant drive timings.
> 
> I guess I'm just ranting for now, but I will have some results for you later
> tonight. Thanks for hearing me out. :)

Just make sure you specify idebus=37 to the kernel, so that the driver
has a chance to compute the correct timing.

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

Re: lowish-latency patch for 2.4.0-test9

[Andi Kleen]

On Fri, Oct 06, 2000 at 10:00:36PM +1100, Andrew Morton wrote:
> The little-low-latency patch for test9 is at
> 
>   http://www.uow.edu.au/~andrewm/linux/2.4.0-test9-low-latency.patch
> 
> Notes:
> 
> - It now passes Benno's tests with 50% headroom (thanks to
>   Ingo's scheduler race fix).

What was that race exactly ?

There is a scheduler race which may also hurt (and is harder to fix):
when the timer interrupt hits in syscall exit after the need_resched check
was done then you may lose a time slice. The window can be quite long
when signals are handled (after do_signal returned there is no reschedule
check). Without signals it is only a few instructions window.

I have not checked if it really is a problem in practice though. With
lots of signals it may be a problem.



-Andi

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

Quota fixes

[Jan Kara]

  Hello.

  I've updated the patch with quota fixes for test9. You can download
it at: ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4 as
quota-fix-2.4.0-test9-1.diff

If nobody complains I'll submit it to Linus so please test.

Honza

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

PATCH: Linux 2.2.17 not RFC1812 compliant

[Mario Lorenz]

Hi folks,

Linux 2.2.17 (only tested version, I assume all other 2.2 series suffer from
the same problem and possibly 2.4 as well - but I havent even looked at that).

Assuming a configuration with linuxbox1 eth0 has adresses 192.168.129.1 and
192.168.130.1, and IP forward being enabled, and another box on the same
ethernet with IP 192.168.129.10 and a route to 192.168.130.1 via 192.168.129.1
(eg that machine doesnt handle multiple logical nets on the same ether very
well). Now this machine pings eg 192.168.130.10.

The linux box will issue a redirect redirecting to 192.168.130.10, assuming
that 192.168.129.10 can talk directly to 192.168.130.10. Under RFC 1812
Rule 5.2.7.2 I think this is illegal (different IP networks...).

There actually is the "shared_media" sysctl, which is not properly documented
in Documentation/network/ip-sysctl.txt. Attached ip-sysctl.txt.patch fixes
that and also documents the behaviour of the ../all/.. and the ../default/..
sysctl directories as best to my knowledge (ie, I may be wrong)


That sysctl defaults to 1. It could be argued that it should be better turned
be 0 (so that RFC1812 compliance is the default).

But anyway, that sysctl does not work in the situation outlined above,
since the inet_addr_onlink check in net/ipv4/route.c will return true, because
FIB_RES_GW(res) will be 0 in that case (192.168.130.0 is directly connected).

Since I am not sure if patching that inet_addr_onlink routine may break other
stuff, I propose attached route.c.patch, which checks for this condition and
puts in the destination address (which is the next hop in this case) on that
check.

Comments ?

Greetings,

Mario


*** route.c.origFri Oct  6 13:41:50 2000
--- route.c Fri Oct  6 15:12:25 2000
***
*** 1215,1221 
  
if (out_dev == in_dev && err && !(flags&(RTCF_NAT|RTCF_MASQ)) &&
(IN_DEV_SHARED_MEDIA(out_dev)
!|| inet_addr_onlink(out_dev, saddr, FIB_RES_GW(res
flags |= RTCF_DOREDIRECT;
  
if (skb->protocol != __constant_htons(ETH_P_IP)) {
--- 1215,1222 
  
if (out_dev == in_dev && err && !(flags&(RTCF_NAT|RTCF_MASQ)) &&
(IN_DEV_SHARED_MEDIA(out_dev)
!|| inet_addr_onlink(out_dev, saddr, 
!FIB_RES_GW(res) ? FIB_RES_GW(res) : daddr)))
flags |= RTCF_DOREDIRECT;
  
if (skb->protocol != __constant_htons(ETH_P_IP)) {


*** ip-sysctl.txt.orig  Fri Oct  6 15:14:40 2000
--- ip-sysctl.txt   Fri Oct  6 15:22:41 2000
***
*** 136,142 
  
  conf/interface/*: 
  conf/all/* is special and changes the settings for all interfaces.
!   Change special settings per interface.
  
  log_martians - BOOLEAN
Log packets with impossible addresses to kernel log.
--- 136,149 
  
  conf/interface/*: 
  conf/all/* is special and changes the settings for all interfaces.
!   Change special settings per interface. Settings are logically
!   ORed with the device specific settings in conf//*,
!   so if you want to disable a feature on a specific device, you
!   may have to disable it in conf/all/* and reenable it on all
!   devices where you want that feature to be enabled.
!   
! conf/default/* is special. The settings here are used as the default settings
! for all newly created interfaces.
  
  log_martians - BOOLEAN
Log packets with impossible addresses to kernel log.
***
*** 165,172 
enabled both in specific device section and in "all" section.
  
  shared_media - BOOLEAN
!   undocumented.
! 
  secure_redirects - BOOLEAN
Accept ICMP redirect messages only for gateways,
listed in default gateway list.
--- 172,181 
enabled both in specific device section and in "all" section.
  
  shared_media - BOOLEAN
!   If it is set the kernel does assume that different subnets
!   on this device can communicate directly.
!   default TRUE
!   
  secure_redirects - BOOLEAN
Accept ICMP redirect messages only for gateways,
listed in default gateway list.

Re: lowish-latency patch for 2.4.0-test9

[Rik van Riel]

On Fri, 6 Oct 2000, Andrew Morton wrote:

> - Updated for the new VM.  (I'll have to ask Rik to take a
>   look at this part sometime).

I've taken a (very) quick look and it seems ok to me...

regards,

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

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

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

Re: Apache Overload Behavior Under Linux [Kernel-Centric Question]

[Rik van Riel]

On Fri, 6 Oct 2000, Stanislav Rost wrote:

> I am working on a research project involving the Linux kernel
> and Apache. Recently, I became puzzled by the overload behavior
> of Apache under cetrain conditions.

Search the linux-kernel archives for the terms
"wake one" and "wake all".

The 2.2.5 kernel you're using (why the hell are you using that?!?!)
only supports wake all semantics, meaning that ALL waiting httpd
processes get woken up on an incoming connection.

It would be interesting to see what happens if you also use a
2.4 kernel to do the same tests and compare the results...

regards,

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

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

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

Re: [PATCH] 2nd go for scsi upper layers + I2O

[Douglas Gilbert]

Torben Mathiasen wrote:

> Ok this patch should be diffed correctly. Same things apply:
>
>   apply patch
>   copy sd.c st.c sg.c sr.c sr_ioctl.c sr_vendor.c from
>   drivers/scsi to drivers/scsi/upper  
>
> The EXPORT_SYMBOL has been removed as Jeff suggested.
> 
> TLAN will hopefully follow soon.

[snipped most of patch, see lkml]

> +sg_mod.o: $(sg_mod-objs)
> +   $(LD) -r -o $@ $(sg_mod-objs)

Firstly, I just spent 2 months trying to get the sd module
name reverted to "sd_mod.o" as it is in lk 2.2 and 2.0 .Now 
this patch seems to rename the sg module to "sg_mod.o"! 
Since the vast majority of distributions build sg as a module,
there could be a lot of irate SANE and cdrecord users out
there. Also devfsd and other module loading software would 
need to be changed. Hopefully this is an oversight.

Secondly, do we really need the scsi Makefile and directory
structure changed this close to the lk 2.4 release?
What does it gain us? Could changes of this dimension be
sent to Eric Youngdale or at least the linux-scsi list
rather than just sent to the linux-kernel list?

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

Re: Apache Overload Behavior Under Linux [Kernel-Centric Question]

[Richard B. Johnson]

On Fri, 6 Oct 2000, Stanislav Rost wrote:

> Fellow Linux afficionados,
> 
> I am working on a research project involving the Linux kernel and Apache.
> Recently, I became puzzled by the overload behavior of Apache under
> cetrain conditions.  The processing in web servers is inherently
> kernel-heavy, so there is no doubt in my mind that the Linux kernel is in
> most part reponsible for this behavior.
> 
> However, I need to understand the underlying causes for this behavior.  I
> have a few hypotheses myself, but I seek your opinion on the matter and
> hope to verify these hypotheses.  Please help me to understand what
> happens in the kernel to cause such behavior.
> 
> Setup:  Pentium2 400, 128 MBs RAM, 100 MBps Ethernet, 
>   Linux 2.2.5, Apache 1.3.12
> 800 clients accessing the same 2 MB file
> simultaneously and continuously (in a closed-loop model)
>   [ so the file is likely cached in its entirety in the filesystem
>   cache ]
>   Maximums and minimums for number of concurrent server processes 
>   servicing requests is also 800 (so that no forking is required
>   and transient state is achieved faster).
> 
> Behavior:  At the beginning of the test, Apache quickly consumes most of
> the RAM and thrashing is evident (as expected).  CPU utilization
> grows to 100% procent and stays there (also as expected).
> 
>   But then, the thrashing stops and the network traffic (as seen
>   from the LEDs on the router) either stops or becomes negligible.
>   All the while, the CPU utilization stays at 100%.  After about a
>   minute of this behavior, the CPU utilization drops to 0%.
> 
>   After that, no clients are able to connect to the web server, and
> the web server does not repond to pings.
> 
> Thank you for your help.
> 
> Stan Rost
> 

Some of the most important information is not provided. Look at
/proc/interrupts and see if your ethernet board is still working. It looks
as though you have a problem with the ethernet driver hanging. The
fact that CPU usage drops to zero, seems to imply that you will see
all apache activity sleeping on the sockets, waiting for input.

I'd advise that you install linux-2.2.17 also. Linux-2.2.5 does not
have many driver fixes back-ported.


Cheers,
Dick Johnson

Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: [PATCH] 2nd go for scsi upper layers + I2O

[Torben Mathiasen]

On Fri, Oct 06 2000, Douglas Gilbert wrote:
> Torben Mathiasen wrote:
> 
> > Ok this patch should be diffed correctly. Same things apply:
> >
> >   apply patch
> >   copy sd.c st.c sg.c sr.c sr_ioctl.c sr_vendor.c from
> >   drivers/scsi to drivers/scsi/upper  
> >
> > The EXPORT_SYMBOL has been removed as Jeff suggested.
> > 
> > TLAN will hopefully follow soon.
> 
> [snipped most of patch, see lkml]
> 
> > +sg_mod.o: $(sg_mod-objs)
> > +   $(LD) -r -o $@ $(sg_mod-objs)
> 
> Firstly, I just spent 2 months trying to get the sd module
> name reverted to "sd_mod.o" as it is in lk 2.2 and 2.0 .Now 
> this patch seems to rename the sg module to "sg_mod.o"! 
> Since the vast majority of distributions build sg as a module,
> there could be a lot of irate SANE and cdrecord users out
> there. Also devfsd and other module loading software would 
> need to be changed. Hopefully this is an oversight.
> 

Sure, no problem.

> Secondly, do we really need the scsi Makefile and directory
> structure changed this close to the lk 2.4 release?
> What does it gain us? Could changes of this dimension be
> sent to Eric Youngdale or at least the linux-scsi list
> rather than just sent to the linux-kernel list?

First of all I _did_ send a patch off to linux-scsi, and this
issue _has_ been discussed with Eric. 

And yes its needed. The lowlevel scsi drivers needs to link
in before the high level ones. Alan posted this to l-k.

> You need to get the i2o scsi driver run last afte the low level and before
> the high level drivers despite being in drivers/i2o. There are some other
> drivers which arent in drivers/scsi too 
>

Maybe you should take a look at the archives before bitching.

Now I'm tired of fixes this and that. Can we agree on
this patch going in when I rename sg_mod.o to sg.o???

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

Re: v2.4.0test9 NFSv3 server woes Linux-->Solaris

[David Weinehall]

On Fri, Oct 06, 2000 at 02:08:27PM +0200, Trond Myklebust wrote:
> > " " == David Weinehall <[EMAIL PROTECTED]> writes:
> 
> >> 2.4.0-pre9 should default to rsize/wsize == whatever Solaris
> >> asks for (32k in practice). It does on my setup...
> 
>  > I'm talking about the client, not the server. Thus, it's the
>  > Linux machine that makes the request, not the Solaris machine.
> 
> So am I. For NFSv3, the server gets a say in what it would like you
> (the client) to use both for rsize, wsize and dtsize (directories).

Sorry to bother you then. Glad to hear this. Is this true for the 
v2.2 NFSv3 as well?


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: PATCH: Linux 2.2.17 not RFC1812 compliant

[Richard B. Johnson]

On Fri, 6 Oct 2000, Mario Lorenz wrote:

> Hi folks,
> 
> Linux 2.2.17 (only tested version, I assume all other 2.2 series suffer from
> the same problem and possibly 2.4 as well - but I havent even looked at that).
> 
> Assuming a configuration with linuxbox1 eth0 has adresses 192.168.129.1 and
> 192.168.130.1, and IP forward being enabled, and another box on the same
> ethernet with IP 192.168.129.10 and a route to 192.168.130.1 via 192.168.129.1
> (eg that machine doesnt handle multiple logical nets on the same ether very
> well). Now this machine pings eg 192.168.130.10.
> 
> The linux box will issue a redirect redirecting to 192.168.130.10, assuming
> that 192.168.129.10 can talk directly to 192.168.130.10. Under RFC 1812
> Rule 5.2.7.2 I think this is illegal (different IP networks...).
> 
[SNIPPED...]

You don't have to modify the kernel. You just have to provide the correct
netmasks. The ICMP redirect is proof enough that your netmask on one
or both of the interfaces is incorrect.


Cheers,
Dick Johnson

Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: [PATCH] cs89x0.c: get rid of check_region()

[Arnaldo Carvalho de Melo]

Em Thu, Sep 28, 2000 at 06:10:38AM -0500, Jeff Garzik escreveu:
> On Thu, 28 Sep 2000 [EMAIL PROTECTED] wrote:
> > this patch removes this old check_region() crap, also some lines are
> > changed to conform with /linux/drivers/Documentation/CodingStyle :)
> > 
> > If here is no objection, I'll walk through /linux/drivers/net 
> > and continue check_region removing.
> 
> Please post patches as text/plain, unless they are really huge.  (In
> which case, post them on a Web or FTP site, and tell us the URL)
> 
> Also, please work with Arnaldo (acme@connectiva), he is also working on
> eliminating check_region...

s/connectiva/conectiva/ :)

yap, I have lots of patches pending, that I'll resubmit after some time,
if you have interest, they are in http://bazar.conectiva.com.br/~acme/patches,
also take a look at my TODO at http://bazar.conectiva.com.br/~acme/TODO,
you'll surely find some more things to do :)

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

tty_[un]register_devfs putting 3K structures on the stack

[Jeff Dike]

tty_register_devfs and tty_unregister_devfs both declare "struct tty_struct" locals.

According to gdb:

(gdb) p sizeof(struct tty_struct)
$20 = 3084

This eats up most of a 4K page, and on UML this is causing the stack to flow off the 
page for some people.

Is it possible to make that tty_struct static or kmalloc it or something?

Jeff


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

Re: the new VM

[Rik van Riel]

[replying to a really old email now that I've started work
 on integrating the OOM handler]

On 25 Sep 2000, Christoph Rohland wrote:
> Rik van Riel <[EMAIL PROTECTED]> writes:
> 
> > > Because as you said the machine can lockup when you run out of memory.
> > 
> > The fix for this is to kill a user process when you're OOM
> > (you need to do this anyway).
> > 
> > The last few allocations of the "condemned" process can come
> > frome the reserved pages and the process we killed will exit just
> > fine.
> 
> It's slightly offtopic, but you should think about detached shm
> segments in yout OOM killer. As many of the high end
> applications like databases and e.g. SAP have most of the memory
> in shm segments you easily end up killing a lot of processes
> without freeing a lot of memory. I see this often in my shm
> tests.

Hmmm, could you help me with drawing up a selection algorithm
on how to choose which SHM segment to destroy when we run OOM?

The criteria would be about the same as with normal programs:

1) minimise the amount of work lost
2) try to protect 'innocent' stuff
3) try to kill only one thing
4) don't surprise the user, but chose something that
   the user will expect to be killed/destroyed

regards,

regards,

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

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

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

Re: [PATCH] PCI detection in 2.2.x and 2.4.0

[Martin Mares]

Hi!

> I recently had a problem with linux 2.2.x and 2.4.0 oopsing early
> in the boot process on a old pentium I had gotten hold of. printk
> investigation showed the problem to be in the PCI detection code,
> specifically the part where linux tries to go through the BIOS to
> get the PCI settings. Picking 'Direct' (CONFIG_PCI_GODIRECT) make
> the boot succeed where 'Any' had not.
> 
> This stumped me since the help text had led me to believe
> otherwise: The help text states that if CONFIG_PCI_GOANY is set
> linux will first try to detect the settings directly and go
> through BIOS if this fails. The code first goes through BIOS to
> get the settings, then gets them directly and then pick the
> direct settings (if valid) otherwise the BIOS settings (if
> valid).

Some years ago, the PCI routines have really used this strategy
(and the obsolete help text reflects this situation), but unfortunately,
there exist machines where the direct access detection gives bogus
results, so it's much better to ask the BIOS first. Also, it's conceptually
cleaner to use a well-defined BIOS interface than to probe random
ports (well, they are random on all non-PCI machines).

These are the reasons why I'd prefer keeping the current code and
just fixing the documentation.

Also, you can easily make your machine boot by specifying "pci=conf1"
at the kernel command line. I admit it isn't a nice solution, but I
don't know any way which would be 100% reliable on all machines
and your machine is the only case I know about where the current
algorithm breaks.

Have a nice fortnight
-- 
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
"Unexpected ';', expecting ';'."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Incorrect UDMA timing on VIA vt82c596b

[Jordan]

I have been using the 2.4..0 test series for quite some time now on a
machine with Redhat 6.2 and gcc 2.95.2 running on a Pentium III 733
Flip-Chip on a Tyan Trinity 400 (S1854) Motherboard.  Until the recent
kernels my IBM 75 GB 7200 RPM Deskstar would only use PIO transfer modes
and only my Kenwood CDROM would correctly turn on its DMA and come up as
UDMA(33).  With test8 and the test9 series I have been able to get all
of my drives (IBM, Kenwood, Zip and Plextor CDRW) to turn on DMA and the
IBM and Kenwood will come up as UDMA(33).  The only problem is that I
have as of test9 tried the stock ide drivers and ide-timing file for my
VIA vt82c596b controller and I can't get the IBM to come up as UDMA(66)
as it should.  This shouldn't be a problem in my mind as the drive is
ATA-100 compatible and the controller correctly gets recognized as a
UDMA(66) controller.  The other puzzling factor is that my friend has a
smillar VIA chipset on an Athlon board by Procomp and when I built his
2.4.0-test9 with the stock ide drivers his 40 GB Maxtor comes up as
UDMA(66) and his 15 GB Maxtor comes up as UDMA(33) which are the correct
values.  I have my IBM as master on the primary channel, my Zip as slave
on the primary channel, my Kenwood and Master on the secondary channel,
and my Plextor as slave on the secondary channel.  Is this a problem
with the code for my controller or do I need to re-order my drives on
the IDE cables.  Thanks for any help.

Here is the portion of my dmesg file that is pertinent:

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16 
VP_IDE: VIA vt82c596b (cf/cg) IDE UDMA66 controller on pci0:7.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: IBM-DTLA-307075, ATA DISK drive
hdb: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive
hdc: KENWOOD CD-ROM UCR-421 V226G, ATAPI CDROM drive
hdd: PLEXTOR CD-R PX-W1210A, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 150136560 sectors (76870 MB) w/1916KiB Cache, CHS=9345/255/63,
UDMA(33)
hdc: ATAPI 68X CD-ROM drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.11
hdb: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error
}
hdb: set_drive_speed_status: error=0x04
hdb: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
Partition check:
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 >

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

Re: Benchmark results for elv_test

[Jeff V. Merkey]

On Fri, Oct 06, 2000 at 08:18:57PM +1000, Robert Cohen wrote:
> 
> I wanted to write it using standard IO paths as much as possible. If I
> use esoteric technolgies like the NWFS stuff, then its not clear if
> performance problems found are in the kernel or in the unusual libraries
> used.

The NWFS stuff uses the standard ll_rw_block interface.  It was suggested
to save you the time of writing all the buffer head code, etc. to talk
to the disk elevator directly.  You'll notice the locking issues are also handled in 
it.  

Jeff


> 
> Robert Cohen
> Australian National University
> 
>  J. Robert von Behren ([EMAIL PROTECTED]) write
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[Fwd: failure to burn CDs under 2.4.0-test9]

[Roger Larsson]

To the right linux-kernel list this time.

/RogerL

Roger Larsson wrote:
> 
> Christoph Lameter wrote:
> >
> > Comparing CD contents with the original after burning showed mismatches 4
> > times in a row. Booted into linux 2.2.18 and everything is fine.
> >
> > Together with the events of freezing in pine I would suggest that there is
> > something in the kernel scribbling memory.
> >
> > I am back to 2.2 for good for now.
> >
> 
> Two issues:
> * __alloc_pages can get into a "dead lock" situation.
>   Please se my: "[PATCH] test9: another vm lockup bug - squashed"
> * it refers to Riels patch of freepages
> With these additions you get more pages free - less likely not to block
> on
> read (really: cp disk CD)
> 
> If this does not help consider trying Andrew Mortons
> "lowish-latency patch for 2.4.0-test9"
> * It avoids getting stuck in kernel loops when the CPU is better needed
>   for some other process.
> 
> /RogerL
> 
> --
> Home page:
>   http://www.norran.net/nra02596/

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

page->mapping == NULL recreated without vmware...

[Petr Vandrovec]

Hi,
  month ago I informed here that VMware causes oops on exit.
After some time, and tons of tweaking I was able to recreate
it without vmmon... 2.4.0-test9, no special patches, no
vmware modules loaded...

  Machine is dual PIII/450, 256MB RAM, 18GB IDE disk.

  Here it is... Adjust MSIZE so that it is almost all of your
memory, to cause swapping... (0x0E00 is for mine 256MB).

/*
Makefile:

CFLAGS = -W -Wall -O2 -D_GNU_SOURCE -D_BSD_SOURCE

oopsdemo:   oopsdemo.c
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

unsigned char zero;

#define MSIZE 0x0E00

int mfd;

void x4768(void) {
int fd;
pid_t pid;
int x4778_1[2];
int x4778_2[2];
int x4779_1[2];
int x4779_2[2];
int from4778;
int to4778;
int from4779;
int to4779;
char* mma[65536];
unsigned int mml[65536];
unsigned int mmi = 0;
unsigned int ln = 0;
unsigned int x;

#define MAL2(a,l) ftruncate(fd, ln+l); mml[mmi] = l; mma[mmi++] = mmap(a, l, 
PROT_READ|PROT_WRITE, MAP_SHARED, fd, ln); ln += l; mma[mmi-1][0] = 99;
#define MAL(l) MAL2(NULL,l)

fd = open("ram0", O_RDWR | O_CREAT, 0600);
unlink("ram0");
MAL(MSIZE);
pipe(x4778_1);
pipe(x4778_2);
pid = fork();
if (!pid) {
int from4768 = x4778_1[0];
int to4768 = x4778_2[1];
close(x4778_1[1]);
close(x4778_2[0]);
close(fd);
read(from4768, &zero, 1);
#if 1
for (x = 0; x < mml[mmi - 1]; x += 4096)
mma[mmi-1][x] = 98;
#endif
write(to4768, &zero, 1);
read(from4768, &zero, 1);
read(mfd, mma[mmi - 1], mml[mmi - 1]);
printf("1a: %02X\n", mma[mmi-1][0]);
fflush(stdout);
mma[mmi-1][0] = 99;
printf("1b: %02X\n", mma[mmi-1][0]);
/* well, now we have it... */
#if 1
{ char* p; int fda;
  fda = open("/dev/zero", O_RDONLY);
  p = mmap(NULL, MSIZE, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
  for (x = 0; x < MSIZE; x += 4096)
p[x] = 97;
  close(fda);
}
#endif

exit(0);

} else if (pid < 0) {
perror("fork failed");
exit(222);
}
to4778 = x4778_1[1];
from4778 = x4778_2[0];
close(x4778_1[0]);
close(x4778_2[1]);

#if 1
pipe(x4779_1);
pipe(x4779_2);
pid = fork();
if (!pid) {
int from4768 = x4779_1[0];
int to4768 = x4779_2[1];
close(x4779_1[1]);
close(x4779_2[0]);
close(to4778);
close(from4778);
close(fd);
read(from4768, &zero, 1);
#if 0
for (x = 0; x < mml[mmi - 1]; x += 4096)
mma[mmi-1][x] = 96;
#endif
write(to4768, &zero, 1);
read(from4768, &zero, 1);
read(mfd, mma[mmi - 1], mml[mmi - 1]);
printf("2a: %02X\n", mma[mmi-1][0]);
fflush(stdout);
mma[mmi-1][0] = 95;
printf("2b: %02X\n", mma[mmi-1][0]);
exit(0);

} else if (pid < 0) {
perror("fork failed");
exit(222);
}
to4779 = x4779_1[1];
from4779 = x4779_2[0];
close(x4779_1[0]);
close(x4779_2[1]);
#else
/* so that read/write to this fails... */
from4779 = -1;
to4779 = -1;
#endif
{
write(to4778, &zero, 1);
write(to4779, &zero, 1);
read(from4778, &zero, 1);
read(from4779, &zero, 1);

write(to4778, &zero, 1);
write(to4779, &zero, 1);
sleep(5);
ftruncate(fd, 0);
}
close(fd);
while (mmi--) {
munmap(mma[mmi], mml[mmi]);
}
exit(0);
}

int main(int argc, char* argv[]) {
struct stat stb;
int q;
char rawsubdev[100];
int min;

if (argc < 2) {
fprintf(stderr, "testit /dev/hda\n");
return 97;
}
q = stat(argv[1], &stb);
if (q != 0) {
fprintf(stderr, "%s: Cannot stat: %m\n", argv[1]);
return 98;
}
q = open("/dev/raw", O_RDWR);
if (q == -1) {
if (errno == ENOENT) {
q = mknod("/dev/raw", S_IFCHR | 0600, makedev(RAW_MAJOR, 0));
if (q != -1) {
q = open("/dev/raw", O_RDWR);
  

disk partition & RAID

[Anil kumar]

Hi,
 I want to setup the RAID.
 For this I am partitioning the disks .The following
 is the procedure:
  fdisk /dev/hde
  fdisk -n /dev/hde /*to add new partition*/
  I specify the first & last cylinder
  fdisk -w /dev/hde /*save & quit*/

  when I do so , I get following :
  The partition table has been altered!
  
  calling ioctl() to re-read partition table.
  hde:unknown partition table
  
  What does this mean?
  where am I wrong?
  
  I am creating a /etc/raidtab file for raid
configuration .
  Then # mkraid /dev/md0
  I get error : device too small(0KB).

  Surprisingly, while bootup itself the Partition
  check shows :
  hde : unknown partition table
  
  what does this mean & how it affects the RAID setup?
   hde is the externel disk I am using for RAID setup.

  I am not able to post any messages to :linux-raid
  group.

with regards,
   Anil

__
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

module reentrancy

[Al Peat]

  I could use a little advice on reentrancy issues for
modules.

  I have written a device driver that is nothing more
than a circular FIFO buffer in memory.  The read and
write methods access user space, so I know that those
sections of code need to be reentrant.  Since the
module represents one shared buffer, I use a couple of
global variables to keep track of the begin and end of
the buffer.  I understand that the filp->private field
provides some protection for reentrancy, but don't
know if that is appropriate in this case.  Would a
rwlock be a good solution?  The buffer is going to be
used to collect some information from a modified IDE
subsystem, so it will be written to many times in
short periods of time, and thus needs to have
efficient write methods.

  I've read all I could find on reentrancy in the
kernel docs and in Alessandro Rubini's excellent book.
 Any other pointers to things I could read (or good
examples of reentrant modules) would be appreciated.

  Thanks,
Al

__
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] PCI detection in 2.2.x and 2.4.0

[Aaron Tiensivu]

> at the kernel command line. I admit it isn't a nice solution, but I
> don't know any way which would be 100% reliable on all machines
> and your machine is the only case I know about where the current
> algorithm breaks.

Me me me me. :)
I have an odd situation.. in 2.4.x on my old P60, if I choose 'any', the
machine has ghost devices and all PCI cards stop working. If I choose
'direct', it almost works. If I choose 'BIOS', it works correctly. 

If you want an lspci from each various boot I can do so.. it is a strange
strange machine.



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

Re: test9-pre? lockups using pine

[davej]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

 > For me it locked up in pine, just after sending an Email, but not always.
 > (and sure i had to retype my emails serveral times)
 > And yes my mailfolders are large (may be relevant)
 > 
 > Global configuration:
 > AMDK6-2/256MB/scsi/ide
 > Almost anything as module,using raid* on LVM (ide/scsi), 3com 1Gbit
 > ethernet, netfilter,ipv6,ax.25,ppp, several different
 > (network) filesystems etc.
 > Distribution SuSE7.0,  PINE 4.21. and running MTA is qmail 1.03.

Odd how all these reports have been K6-2's so far.
(Including my own). It only happened to me in test9pre7.
Seems okay here now.

Did this happen to anyone on a CPU other than K6-2 ?

Dave.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

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

Re: 2.2.18pre and Duron detection

[davej]

> 2.2.18pre12 detects Duron 600 almost fine (even reports 64K cache) but
> fails to identify some cpu flags (6, 14, 17). /proc/cpuinfo output:
>
>flags: fpu vme de pse tsc msr 6 mce cx8 sep mtrr pge 14 cmov pat 17
>   psn mmxext mmx fxsr 3dnowext 3dnow

Try the patch below, this brings things up to date with 2.4

regards,

Dave.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

--- setup.c~Fri Oct  6 18:13:35 2000
+++ setup.c Fri Oct  6 18:19:13 2000
@@ -1142,10 +1142,10 @@
char *p = buffer;
int sep_bug;
static char *x86_cap_flags[] = {
-   "fpu", "vme", "de", "pse", "tsc", "msr", "6", "mce",
-   "cx8", "9", "10", "sep", "mtrr", "pge", "14", "cmov",
-   "16", "17", "psn", "19", "20", "21", "22", "mmx",
-   "24", "kni", "26", "27", "28", "29", "30", "31"
+   "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
+   "cx8", "apic", "10", "sep", "mtrr", "pge", "mca", "cmov",
+   "16", "pse36", "psn", "19", "20", "21", "22", "mmx",
+   "24", "xmm", "26", "27", "28", "29", "30", "31"
};
struct cpuinfo_x86 *c = cpu_data;
int i, n;
@@ -1200,17 +1200,11 @@
break;
   
   
   
   
case X86_VENDOR_INTEL:
-   x86_cap_flags[6] = "pae";
-   x86_cap_flags[9] = "apic";
-   x86_cap_flags[14] = "mca";
x86_cap_flags[16] = "pat";
-   x86_cap_flags[17] = "pse36";
-   x86_cap_flags[18] = "psn";
x86_cap_flags[19] = "cflush";
x86_cap_flags[21] = "dtrace";
x86_cap_flags[22] = "acpi";
x86_cap_flags[24] = "fxsr";
-   x86_cap_flags[25] = "xmm";
x86_cap_flags[26] = "xmm2";
x86_cap_flags[27] = "ssnp";
x86_cap_flags[29] = "acc";

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

Re: Tux 2 patents

[jesse]

On Fri, Oct 06, 2000 at 09:13:25AM +0200, Daniel Phillips wrote:
> > Once you use the technique and it's documented as clear by a patent
> > lawyer, it will be safe for you to use forever, particularly if it's 
> > in the public domain. This is winning
> 
> This is good to know, but what I was talking about is taking it *out of
> the closed source* domain.  The idea is to take our best ideas out of
> the closed source domain.  After a few years of doing that, it's my
> guess that the evil software patent system would keel over and die.

IANAL, but I believe that once you've implemented a method in a released
product, you have only one year to file the patents for it.  If you don't
file patents for it within this time period, it becomes public domain.  I
think it would be possible to invalidate their patents, but I don't think
it would be possible to get your own patent on it after the fact and refuse
to let them use it.

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

Protocol 0008 is buggy

[Ivan Passos]

Hello,

I have a customer who's getting tons of this msg in his LOGs:

kernel: protocol 0008 is buggy, dev hdlc0

The msg comes from net/core/dev.c, and this device is using the Frame
Relay protocol in drivers/net/hdlc.c .

What I'd like to know is:
- What exactly causes this msg?? It seems that it's printed when someone 
  sends a packet without the skb->nh.raw correctly set, but I couldn't
  find any driver under drivers/net that sets this.
- How can / should I solve this?? Should it be solved in the hdlc.c driver 
  or somewhere else in an upper level??

Thanks in advance for your help.

Later,
Ivan

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

Re: [PATCH] PCI detection in 2.2.x and 2.4.0

[Martin Mares]

Hi!

> I have an odd situation.. in 2.4.x on my old P60, if I choose 'any', the
> machine has ghost devices and all PCI cards stop working. If I choose
> 'direct', it almost works. If I choose 'BIOS', it works correctly. 

By the way, does 2.2.x behave in the same way?
 
> If you want an lspci from each various boot I can do so.. it is a strange
> strange machine.

I'm interested in lspci -vvx outputs for all the cases and also in effect
of "pci=bios", "pci=conf1" and "pci=conf2" switches.

Have a nice fortnight
-- 
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
"They'll release Windows 96 when 95 finishes loading."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: module reentrancy

[Eric Lowe]

Hello,

>   I could use a little advice on reentrancy issues for
> modules.
> 
>   I have written a device driver that is nothing more
> than a circular FIFO buffer in memory.  The read and
> write methods access user space, so I know that those
> sections of code need to be reentrant.  Since the
> module represents one shared buffer, I use a couple of
> global variables to keep track of the begin and end of
> the buffer.  I understand that the filp->private field
> provides some protection for reentrancy, but don't
> know if that is appropriate in this case.  Would a
> rwlock be a good solution?  The buffer is going to be
> used to collect some information from a modified IDE
> subsystem, so it will be written to many times in
> short periods of time, and thus needs to have
> efficient write methods.
> 
>   I've read all I could find on reentrancy in the
> kernel docs and in Alessandro Rubini's excellent book.
>  Any other pointers to things I could read (or good
> examples of reentrant modules) would be appreciated.
> 

If you only have a couple of integers to set, you can probably
get away with atomic operations.  Without knowing more though,
I'm not sure what else to suggest.  But here's my advice:

-if you are checking against these values often, a rwlock is
 probably the best choice (e.g. while(var < end) { foo() };)
-if you check begin+end once, atomic ops are the way to go
 (e.g. start = buf+begin ; count = end-start)
-if you have to update begin/end non-atomically and check them
 only once, use a spinlock, it's the least expensive lock

--
Eric Lowe
Software Engineer, Systran Corporation
[EMAIL PROTECTED]


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

Re: [PATCH] PCI detection in 2.2.x and 2.4.0

[Aaron Tiensivu]

> By the way, does 2.2.x behave in the same way?

No. 2.2.x and if I remember right, even 2.0.x all get it right.

> I'm interested in lspci -vvx outputs for all the cases and also in effect
> of "pci=bios", "pci=conf1" and "pci=conf2" switches.

Will do.

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

RE: Tux 2 patents

[Marty Fouts]

IANAL; this is not legal advice.

The 'one year'  you are referring to is from 'disclosure', not from released
product.  "disclosure" in this case is a legal term-of-art. Further, there
is a difference between US and European Union patent law, in that, IIRC, EU
law requires patent application before _public_ disclosure.  In effect,
"disclosure" means revealing the idea to anyone, inside your organization or
out, but there are all sorts of corner cases in the law.

Nolo Press had a good book that discusses copyright and patent law, although
they may not have had the chance to update it to reflect recent changes.

In any event, if you are serious about either getting or trying to overturn
a patent, you need to see a lawyer specializing in patent law, because case
law frequently changes the nuances in this area.

-Original Message-
From: jesse [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 10:53 AM
To: [EMAIL PROTECTED]
Subject: Re: Tux 2 patents

On Fri, Oct 06, 2000 at 09:13:25AM +0200, Daniel Phillips wrote:
> > Once you use the technique and it's documented as clear by a patent
> > lawyer, it will be safe for you to use forever, particularly if it's
> > in the public domain. This is winning
>
> This is good to know, but what I was talking about is taking it *out of
> the closed source* domain.  The idea is to take our best ideas out of
> the closed source domain.  After a few years of doing that, it's my
> guess that the evil software patent system would keel over and die.

IANAL, but I believe that once you've implemented a method in a released
product, you have only one year to file the patents for it.  If you don't
file patents for it within this time period, it becomes public domain.  I
think it would be possible to invalidate their patents, but I don't think
it would be possible to get your own patent on it after the fact and refuse
to let them use it.

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

RE: Why does everyone hate gcc 2.95?

[Purtell, Andrew]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is this a problem where the code produced by 2.95 was non-optimal in some
significant way or simply incorrect, or is it really just a subjective
"takes to long to compile XXX" thing?


Andrew Purtell
NAI Labs at Network Associates, Inc.Los Angeles, CA
PGP Keys: ldap://certserver.pgp.com
PGP Fingerprint: 5A21 10DB 92B0 CE20 80B4  90D7 A89C D464 AA0A A616

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1
Comment: Crypto Provided by Network Associates 

iQA/AwUBOd4bNaic1GSqCqYWEQJGHQCeNwodLtadXU+kwIXW0Q+6zQMl3c4AoLs6
3KKAuVzXn757Bsp5RrdGZsAT
=1uvj
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

TCP/IP User mode Port

[Ziad Sayegh]

Hi all,

I was told somebody ported the TCP/IP stack of 2.0 as a library in
user-mode. I cannot find the code for that, can anybody tell me where can I
get it? Also, is there any other user level port of the TCP/IP stack for
more recent kernels?

Thanks in advance,

Ziad Sayegh



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

Re: [PATCH] PCI detection in 2.2.x and 2.4.0

[Rasmus Andersen]

> Some years ago, the PCI routines have really used this strategy
> (and the obsolete help text reflects this situation), but unfortunately,
> there exist machines where the direct access detection gives bogus
> results, so it's much better to ask the BIOS first. Also, it's conceptually
> cleaner to use a well-defined BIOS interface than to probe random
> ports (well, they are random on all non-PCI machines).
> 
> These are the reasons why I'd prefer keeping the current code and
> just fixing the documentation.

Having had time to think, I think there is a discrepancy between
what you say here and the code: If CONFIG_PCI_GOANY=y the code
now goes through BIOS first and then (irrespectively of the
BIOS scan) directly. If going directly isn't nice, wouldn't we
be better off by checking on the return from the BIOS scan
before poking directly?

Examply patch below. If you concur, I will submit this along with
updated documentation to Linus later.


--- linux-240-test9-clean/arch/i386/kernel/pci-pc.c Mon Oct  2 22:28:26 2000
+++ linux/arch/i386/kernel/pci-pc.c Fri Oct  6 20:24:46 2000
@@ -969,7 +969,7 @@
}
 #endif
 #ifdef CONFIG_PCI_DIRECT
-   if (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2))
+   if (!bios && (pci_probe & (PCI_PROBE_CONF1 | PCI_PROBE_CONF2)))
dir = pci_check_direct();
 #endif
if (dir)

-- 
Regards,
Rasmus([EMAIL PROTECTED])

You know how dumb the average guy is?  Well, by  definition, half
of them are even dumber than that.
-- J.R. "Bob" Dobbs 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: tty_[un]register_devfs putting 3K structures on the stack

[Theodore Y. Ts'o]

   Date:Fri, 06 Oct 2000 12:01:34 -0500
   From: Jeff Dike <[EMAIL PROTECTED]>

   tty_register_devfs and tty_unregister_devfs both declare "struct tty_struct" locals.

   According to gdb:

   (gdb) p sizeof(struct tty_struct)
   $20 = 3084

   This eats up most of a 4K page, and on UML this is causing the stack to flow off 
the page for some people.

   Is it possible to make that tty_struct static or kmalloc it or
   something?

And it's allocating a tty_struct for a really dumb reason, too.  It's
just using it so it cna call tty_name.

Just replace the call to tty_name with something like this:

sprintf(buf, driver->name, idx + driver->name_base)

and make the obvious change to avoid using tty.device, and you can avoid
need to allocate a tty_struct altogether.

- Ted


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

Re: Tux 2 patents

[Jeff V. Merkey]

And you only get the year of protection **IF** you have filed a
provisional patent application, which expires 12 months after it's
issued.  You must then file a non-provisional patent application before
the year runs out, or you cannot patent the techniques.

Jeff

Marty Fouts wrote:
> 
> IANAL; this is not legal advice.
> 
> The 'one year'  you are referring to is from 'disclosure', not from released
> product.  "disclosure" in this case is a legal term-of-art. Further, there
> is a difference between US and European Union patent law, in that, IIRC, EU
> law requires patent application before _public_ disclosure.  In effect,
> "disclosure" means revealing the idea to anyone, inside your organization or
> out, but there are all sorts of corner cases in the law.
> 
> Nolo Press had a good book that discusses copyright and patent law, although
> they may not have had the chance to update it to reflect recent changes.
> 
> In any event, if you are serious about either getting or trying to overturn
> a patent, you need to see a lawyer specializing in patent law, because case
> law frequently changes the nuances in this area.
> 
> -Original Message-
> From: jesse [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 06, 2000 10:53 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Tux 2 patents
> 
> On Fri, Oct 06, 2000 at 09:13:25AM +0200, Daniel Phillips wrote:
> > > Once you use the technique and it's documented as clear by a patent
> > > lawyer, it will be safe for you to use forever, particularly if it's
> > > in the public domain. This is winning
> >
> > This is good to know, but what I was talking about is taking it *out of
> > the closed source* domain.  The idea is to take our best ideas out of
> > the closed source domain.  After a few years of doing that, it's my
> > guess that the evil software patent system would keel over and die.
> 
> IANAL, but I believe that once you've implemented a method in a released
> product, you have only one year to file the patents for it.  If you don't
> file patents for it within this time period, it becomes public domain.  I
> think it would be possible to invalidate their patents, but I don't think
> it would be possible to get your own patent on it after the fact and refuse
> to let them use it.
> 
> -Jesse
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] VM fix for 2.4.0-test9 & OOM handler

[Rik van Riel]

Hi Linus,

the following patch contains 2 fixes and one addition
to the VM layer:

1. Roger Larson's fix to make sure there is no
   "1 page gap" between the point where __alloc_pages()
   goes to sleep and kswapd() wakes up<== livelock fix

2. fix the calculation of freepages.{min,low,high} to better
   reflect the reality of having per-zone tunable free
   memory target  <== balancing fix

3. add the out of memory killer, which has been tuned with
   -test9 to be ran at exactly the right moment; process
   selection: "principle of least surprise"  <== OOM handling

regards,

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

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



--- linux-2.4.0-test9/fs/buffer.c.orig  Tue Oct  3 10:19:10 2000
+++ linux-2.4.0-test9/fs/buffer.c   Tue Oct  3 12:25:23 2000
@@ -706,7 +706,7 @@
 static void refill_freelist(int size)
 {
if (!grow_buffers(size)) {
-   wakeup_bdflush(1);
+   wakeup_bdflush(1);  /* Sets task->state to TASK_RUNNING */
current->policy |= SCHED_YIELD;
schedule();
}
--- linux-2.4.0-test9/mm/highmem.c.orig Tue Oct  3 10:20:41 2000
+++ linux-2.4.0-test9/mm/highmem.c  Tue Oct  3 12:25:44 2000
@@ -310,7 +310,7 @@
 repeat_bh:
bh = kmem_cache_alloc(bh_cachep, SLAB_BUFFER);
if (!bh) {
-   wakeup_bdflush(1);
+   wakeup_bdflush(1);  /* Sets task->state to TASK_RUNNING */
current->policy |= SCHED_YIELD;
schedule();
goto repeat_bh;
@@ -324,7 +324,7 @@
 repeat_page:
page = alloc_page(GFP_BUFFER);
if (!page) {
-   wakeup_bdflush(1);
+   wakeup_bdflush(1);  /* Sets task->state to TASK_RUNNING */
current->policy |= SCHED_YIELD;
schedule();
goto repeat_page;
--- linux-2.4.0-test9/mm/page_alloc.c.orig  Tue Oct  3 10:20:41 2000
+++ linux-2.4.0-test9/mm/page_alloc.c   Fri Oct  6 15:45:36 2000
@@ -268,7 +268,8 @@
water_mark = z->pages_high;
}
 
-   if (z->free_pages + z->inactive_clean_pages > water_mark) {
+   /* Use >= to have one page overlap with free_shortage() !! */
+   if (z->free_pages + z->inactive_clean_pages >= water_mark) {
struct page *page = NULL;
/* If possible, reclaim a page directly. */
if (direct_reclaim && z->free_pages < z->pages_min + 8)
@@ -795,21 +796,6 @@

printk("On node %d totalpages: %lu\n", nid, realtotalpages);
 
-   /*
-* Select nr of pages we try to keep free for important stuff
-* with a minimum of 10 pages and a maximum of 256 pages, so
-* that we don't waste too much memory on large systems.
-* This is fairly arbitrary, but based on some behaviour
-* analysis.
-*/
-   i = realtotalpages >> 7;
-   if (i < 10)
-   i = 10;
-   if (i > 256)
-   i = 256;
-   freepages.min += i;
-   freepages.low += i * 2;
-   freepages.high += i * 3;
memlist_init(&active_list);
memlist_init(&inactive_dirty_list);
 
@@ -875,6 +861,20 @@
zone->pages_min = mask;
zone->pages_low = mask*2;
zone->pages_high = mask*3;
+   /*
+* Add these free targets to the global free target;
+* we have to be SURE that freepages.high is higher
+* than SUM [zone->pages_min] for all zones, otherwise
+* we may have bad bad problems.
+*
+* This means we cannot make the freepages array writable
+* in /proc, but have to add a separate extra_free_target
+* for people who require it to catch load spikes in eg.
+* gigabit ethernet routing...
+*/
+   freepages.min += mask;
+   freepages.low += mask*2;
+   freepages.high += mask*3;
zone->zone_mem_map = mem_map + offset;
zone->zone_start_mapnr = offset;
zone->zone_start_paddr = zone_start_paddr;
--- linux-2.4.0-test9/mm/vmscan.c.orig  Tue Oct  3 10:20:41 2000
+++ linux-2.4.0-test9/mm/vmscan.c   Fri Oct  6 15:46:14 2000
@@ -837,8 +837,9 @@
for(i = 0; i < MAX_NR_ZONES; i++) {
zone_t *zone = pgdat->node_zones+ i;
if (zone->size && (zone->inactive_clean_pages +
-   zone->free_pages < zone->pages_min)) {
-   sum += zone->pages_min;
+   zone->free_pages < zone->pages_min+1)) {
+   /* + 1 to have overlap with alloc_pages

Re: v2.4.0test9 NFSv3 server woes Linux-->Solaris

[Trond Myklebust]

> " " == David Weinehall <[EMAIL PROTECTED]> writes:

 > Sorry to bother you then. Glad to hear this. Is this true for
 > the v2.2 NFSv3 as well?

If you use tcp mounts then yes. If you use udp, then the default is
1k. Alan has said that he prefers that as it causes less breakage on
existing setups.

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

Re: Tux 2 patents

[Daniel Phillips]

jesse wrote:
> IANAL, but I believe that once you've implemented a method in a released
> product, you have only one year to file the patents for it.  If you don't
> file patents for it within this time period, it becomes public domain.  I
> think it would be possible to invalidate their patents, but I don't think
> it would be possible to get your own patent on it after the fact and refuse
> to let them use it.

Ah, but there is plenty patentable in the current phase tree design,
implemented in Tux2 since early last year.  Have you ever seen a
three-root atomic commit before?  So if you're right then there is still
time.  On the other hand, I've heard that as soon as I disclose it
publicly it's not patentable.

Read 'white hat patent' in all of the above, IOW, GPL-compatible
licence.

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

Re: Tux 2 patents

[Daniel Phillips]

Marty Fouts wrote:
>> IANAL, but I believe that once you've implemented a method in a released
> product, you have only one year to file the patents for it.  If you don't
> file patents for it within this time period, it becomes public domain.  I
> think it would be possible to invalidate their patents, but I don't think
> it would be possible to get your own patent on it after the fact and refuse
> to let them use it.

No, that was never under consideration (I guess I just don't have the
right mindset for this:)  I'm looking at the ways in which the phase
tree algorithm is superior to what they're doing.  And actually, I'm not
worried about NetApp, I'm worried about Sauron^H^H^H^H^H^H Bill.

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

Re: Tux 2 patents

[Daniel Phillips]

"Jeff V. Merkey" wrote:
> 
> And you only get the year of protection **IF** you have filed a
> provisional patent application, which expires 12 months after it's
> issued.  You must then file a non-provisional patent application before
> the year runs out, or you cannot patent the techniques.

IOW, there is *no chance* to get a white-hat patent on anything I've
described on these lists recently.  That doesn't bother me a lot since
there is still a lot I haven't described.  What should I do, put it all
in the totally-public domain and let evildoers have it too, or should I
do interim patent applications from now on?

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

Small Bug

[Claudia Moroder]

I did send this small bug to the mantainer of 
Multipple Device SCSI, but did get no answer after a week so I put it at the 
linux-kernel.
 
 
I have found a small bug in 
raid5.c
 
static int __check_consistency (mddev_t *mddev, int 
row)
{
raid5_conf_t *conf = mddev->private;
kdev_t dev;
struct buffer_head *bh[MD_SB_DISKS], *tmp = 
NULL;
int i, ret = 0, nr = 0, count;
struct buffer_head *bh_ptr[MAX_XOR_BLOCKS];
if (conf->working_disks != 
conf->raid_disks)
goto out;
 
//    THE BUG IS IN THE FOLLOWING TWO 
LINES
 
tmp = kmalloc(sizeof(*tmp), 
GFP_KERNEL);   
tmp->b_size = 4096;
 
// tmp is used without check if it is null;
 
Best regards
 
Andreas Moroder

Re: Tux 2 patents

[Per Jessen]

On Fri, 06 Oct 2000 21:18:08 +0200, Daniel Phillips wrote:

>jesse wrote:
>> IANAL, but I believe that once you've implemented a method in a released
>> product, you have only one year to file the patents for it.  If you don't
>> file patents for it within this time period, it becomes public domain.  I
>> think it would be possible to invalidate their patents, but I don't think
>> it would be possible to get your own patent on it after the fact and refuse
>> to let them use it.
>
>Ah, but there is plenty patentable in the current phase tree design,
>implemented in Tux2 since early last year.  Have you ever seen a
>three-root atomic commit before?  So if you're right then there is still
>time.  On the other hand, I've heard that as soon as I disclose it
>publicly it's not patentable.

This my belief too - we looked into patenting a while back, and in general
you cannot patent something that is already public knowledge. Ie. if you
have already published information, one way or another, no patenting.
This certainly applies to hardware (of any kind) - whether the same
rule is applied to software - no idea - but it seems probable.
Also, our information originates at the EPO - the US regulations/laws
might be different.



regards,
Per Jessen, Principal Engineer, ENIDAN Technologies
http://www.enitek.com - home of the J1 serial console



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

Re: Tux 2 patents

[Alexander Viro]

On Fri, 6 Oct 2000, Daniel Phillips wrote:

> "Jeff V. Merkey" wrote:
> > 
> > And you only get the year of protection **IF** you have filed a
> > provisional patent application, which expires 12 months after it's
> > issued.  You must then file a non-provisional patent application before
> > the year runs out, or you cannot patent the techniques.
> 
> IOW, there is *no chance* to get a white-hat patent on anything I've

There is no such thing as white-hat patent.

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

Re: Tux 2 patents

[Daniel Phillips]

Alexander Viro wrote:
> 
> On Fri, 6 Oct 2000, Daniel Phillips wrote:
> 
> > "Jeff V. Merkey" wrote:
> > >
> > > And you only get the year of protection **IF** you have filed a
> > > provisional patent application, which expires 12 months after it's
> > > issued.  You must then file a non-provisional patent application before
> > > the year runs out, or you cannot patent the techniques.
> >
> > IOW, there is *no chance* to get a white-hat patent on anything I've
> 
> There is no such thing as white-hat patent.

Flow with me on this, there is: it's a patent that helps destroy the
patent system.  If BSD gets hurt then we have to fix it somehow.

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

wait_queue_head_t vs. wait_queue_t

[Timur Tabi]

Could someone explain to me the difference between wait_queue_head_t and
wait_queue_t?  I'm trying to port some code from 2.2 to 2.4, and I'm getting
these two structures confused.  What makes it worse is that the drivers in the
2.4 kernel which use these structures don't seem to explain their usage it.
For instance, I see this code a lot (from
/usr/src/linux-2.4.0-test2/drivers/usb/serial/digi_acceleport.c):

wait_queue_t wait;

init_waitqueue_entry( &wait, current );

add_wait_queue( q, &wait );

...

remove_wait_queue( q, &wait );

Why doesn't the code initialize the "struct list_head task_list" element in
wait_queue_t? 




-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll
just get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: TCP/IP User mode Port

[Jeff Dike]

> I was told somebody ported the TCP/IP stack of 2.0 as a library in
> user-mode. I cannot find the code for that, can anybody tell me where
> can I get it? Also, is there any other user level port of the TCP/IP
> stack for more recent kernels?

This is probably not what you heard about, but it might work for you.  I've 
ported the entire kernel to userspace (including the TCP stack, obviously).

See http://user-mode-linux.sourceforge.net for details.

Jeff


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

Re: 2.4.0-test9-pre8

[Pavel Machek]

Hi!

> * Following a suggestion from Jeff Garzik to save the disk from heavy
>   trashing during my mem=8M test, I've tried to use a ramdisk for
>   swapping - Yes, I know, this is pretty stupid in normal use and might
>   even be illegal (i.e. not expected to work by design). Anyway, I've
>   tried it and was working when used as a swapdevice (size=64M, bs=4k).
>   Added with priority 0 and the normal swap partition kept for fallback
>   with prio=-1. No problems. It did even gracefully swapoff the ramdisk
>   while it was already filled and the box was swapping to disk.
>   To make thinks even more stupid, I've tried a second thing: create
>   an ext2-fs (bs=4k) on the ramdisk, mount it, and use a swapfile on
>   top of it. This deadlocks (with kswapd being current forever) at the
>   very moment the swapfile ist filled and swapping has to go to the
>   fallback raw swap partition.
>   As already said, I wouldn't be surprised, if swapping to rd were
>   broken. But swapping to a rd-partition appears solid while a rd-based
>   swapfile deadlocks. Could the difference be explained somehow or might
>   it indicate some deadlock path due to VM-fs interaction not
>   covered otherwise - so far?

This really should be documented, somewhere.

For example swapping over nbd to localhost can not work.

Swapping over nbd to any other host can not work, too; but it might be
fixable.

Swapping to /dev/loop* probably can not work.

Swapping to file on nfs does not work.

Perhaps this should be added to Documentation/swap.txt?

(Rik, you know about this issues... Do you feel like creating
Documentation/swap.txt?)

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]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test9-pre8

[Rik van Riel]

On Fri, 6 Oct 2000, Pavel Machek wrote:

> This really should be documented, somewhere.

Indeed ;)

> For example swapping over nbd to localhost can not work.
> 
> Swapping over nbd to any other host can not work, too; but it
> might be fixable.

This is one of the next things on my TODO list, actually.

For example, take a look at http://www.ltsp.org/ and in
our office here we have >50 disless workstations. I really
want to fix swap over network to work correctly...

> Swapping to /dev/loop* probably can not work.

Probably not no ... we really need to rework /dev/loop into
an md-like thing ;)

> Swapping to file on nfs does not work.

Any fundamental reasons, or is this in the "fixable"
category?  If it is fixable, I'd like to fix it ;)

(but I haven't taken a look at the hairy parts yet,
so I'd like to hear from the people who have tried)

> Perhaps this should be added to Documentation/swap.txt?
> 
> (Rik, you know about this issues... Do you feel like creating
> Documentation/swap.txt?)

I don't really have the opportunity to write documentation
right now - BIG lack of time ;(...

regards,

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

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

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

Re: tty_[un]register_devfs putting 3K structures on the stack

[Jeff Dike]

[EMAIL PROTECTED] said:
> And it's allocating a tty_struct for a really dumb reason, too.  It's
> just using it so it cna call tty_name.

> Just replace the call to tty_name with something like this:

>   sprintf(buf, driver->name, idx + driver->name_base)

> and make the obvious change to avoid using tty.device, and you can
> avoid need to allocate a tty_struct altogether. 

Are you willing to consider this a critical bug that deserves to be fixed 
before 2.4.0?

If so, I'm willing to make the fix and send it to whoever wants it.

Jeff


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

Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler

[Byron Stanoszek]

On Fri, 6 Oct 2000, Rik van Riel wrote:

> 3. add the out of memory killer, which has been tuned with
>-test9 to be ran at exactly the right moment; process
>selection: "principle of least surprise"  <== OOM handling

In the OOM killer, shouldn't there be a check for PID 1 just to enforce that
INIT will not be the victim? Sure its total_vm might be small, but if there was
a memory leak in the kernel somewhere, it might eventually become the target.
I suppose, if it ever were to become the victim, your system wouldn't be too
usable anyway...

Can you give me your rationale for selecting 'nice' processes as being badder?
Do you think it would be a good idea to scale the amount of badness according
to how nice the process is (a nice value of 20 could get the full *2, otherwise
a smaller multiplier)?

How about using the current process priority level instead of nicety. If a
process was deprioritized (or auto-niced) because it was starting to eat up CPU
time, AND its memory is abnormally high, then should that be our #1 victim? We
also don't want to kill things like benchmarks either, but hopefully they
wouldn't start eating up more than the available system memory.

Just some thoughts.

 -Byron

-- 
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer  Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]

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

Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler

[Rik van Riel]

On Fri, 6 Oct 2000, Byron Stanoszek wrote:
> On Fri, 6 Oct 2000, Rik van Riel wrote:
> 
> > 3. add the out of memory killer, which has been tuned with
> >-test9 to be ran at exactly the right moment; process
> >selection: "principle of least surprise"  <== OOM handling
> 
> In the OOM killer, shouldn't there be a check for PID 1 just to
> enforce that INIT will not be the victim? Sure its total_vm
> might be small, but if there was a memory leak in the kernel
> somewhere, it might eventually become the target. I suppose, if
> it ever were to become the victim, your system wouldn't be too
> usable anyway...

Indeed, if init is chosen for some reason, something really
strange is going on and there's not much hope for rescueing
it ;)

> Can you give me your rationale for selecting 'nice' processes as
> being badder?

They are niced because the user thinks them a bit less
important. This includes stuff like cron jobs that _just_
push a system over the edge ...

> Do you think it would be a good idea to scale the amount of
> badness according to how nice the process is (a nice value of 20
> could get the full *2, otherwise a smaller multiplier)?

I've thought about this, but the algorithms used are so
coarse that this makes little sense. Also, a nice+20
process is often more "important" than the nice+4 cron
job ... ;)

> How about using the current process priority level instead of
> nicety. If a process was deprioritized (or auto-niced) because
> it was starting to eat up CPU time, AND its memory is abnormally
> high, then should that be our #1 victim?

Not really. In the first place, the dynamic priority changes
so fast that it means almost nothing. Furthermore, once a process
has used a lot of CPU time, killing it means you're potentially
throwing away a lot of useful work that's been done.

(same for a process which has been running a long time)

> We also don't want to kill things like benchmarks either, but
> hopefully they wouldn't start eating up more than the available
> system memory.

*grin*

regards,

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

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

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

Re: 2.4.0-test9-pre8

[Pavel Machek]

Hi!

> > Swapping to /dev/loop* probably can not work.
> 
> Probably not no ... we really need to rework /dev/loop into
> an md-like thing ;)
> 
> > Swapping to file on nfs does not work.
> 
> Any fundamental reasons, or is this in the "fixable"
> category?  If it is fixable, I'd like to fix it ;)

> (but I haven't taken a look at the hairy parts yet,
> so I'd like to hear from the people who have tried)

There were some pathces to do that, used to be at
http://www.math1.rwth-aachen.de/~heine/nfs-swap/.

> > Perhaps this should be added to Documentation/swap.txt?
> > 
> > (Rik, you know about this issues... Do you feel like creating
> > Documentation/swap.txt?)
> 
> I don't really have the opportunity to write documentation
> right now - BIG lack of time ;(...

Just put your todolist inside Documentation/swap.txt :-)
Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: Tux 2 patents

[Marty Fouts]

Please be careful with attributions.  I did not write the paragraph
attributed to me below, which contains information I believe is incorrect.

-Original Message-
From: Daniel Phillips
[mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 12:24 PM
To: Marty Fouts; [EMAIL PROTECTED]
Subject: Re: Tux 2 patents

Marty Fouts wrote:
>> IANAL, but I believe that once you've implemented a method in a released
> product, you have only one year to file the patents for it.  If you don't
> file patents for it within this time period, it becomes public domain.  I
> think it would be possible to invalidate their patents, but I don't think
> it would be possible to get your own patent on it after the fact and
refuse
> to let them use it.

No, that was never under consideration (I guess I just don't have the
right mindset for this:)  I'm looking at the ways in which the phase
tree algorithm is superior to what they're doing.  And actually, I'm not
worried about NetApp, I'm worried about Sauron^H^H^H^H^H^H Bill.

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

RE: Tux 2 patents

[Marty Fouts]

This is not correct.  There is a lot of partially correct information being
passed around in this thread, and I strongly suggest that people who are
interested not rely on what is being said here, but read the NOLO press book
as a starter, and talk to an IP lawyer if you need to know the details.

Marty

-Original Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 11:52 AM
To: Marty Fouts
Cc: 'jesse'; [EMAIL PROTECTED]
Subject: Re: Tux 2 patents


And you only get the year of protection **IF** you have filed a
provisional patent application, which expires 12 months after it's
issued.  You must then file a non-provisional patent application before
the year runs out, or you cannot patent the techniques.

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

Re: ack number in a connection-refused RST

[David Wagner]

David S. Miller wrote:
>Linux should not honor the incorrect sequence number.  If the sequence
>number is incorrect, the RST could legitimately be for another
>connection.

How could it be for another connection, if it has source and destination
port numbers?  I thought the sequence number was there to prevent denial
of service attacks, i.e., to prevent unauthorized third parties from
tearing down established TCP connections; since third parties will not
know (or be able to guess) the current 32-bit sequence number, they will 
be unable to forge a valid RST packet.  Of course, this argument is still
valid even if you accept off-by-one errors in the sequence number; the
attacker still has to guess from a 31-bit space, which is slightly smaller
than the original 32-bit space but still likely large enough for security.
What am I missing?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] Removing __initfunc from drivers/video/sun3fb.c (240-test9)

[Rasmus Andersen]

Hi.

(I hope that you are the current maintainer for the Sun3 framebuffer.
If not, please redirect me if you are able to.)

It is my understanding that __initfunc is deprecate in 2.4.0. So this
patch exchanges __initfunc with __init.


--- linux-240-test9-clean/drivers/video/sun3fb.cMon Oct  2 22:31:14 2000
+++ linux/drivers/video/sun3fb.cFri Oct  6 22:47:28 2000
@@ -334,7 +334,7 @@
  *  Setup: parse used options
  */
 
-__initfunc(void sun3fb_setup(char *options))
+void __init sun3fb_setup(char *options)
 {
char *p;

@@ -521,7 +521,7 @@
 /*
  *  Initialisation
  */
-__initfunc(static void sun3fb_init_fb(int fbtype, unsigned long addr))
+static void __init sun3fb_init_fb(int fbtype, unsigned long addr)
 {
static struct linux_sbus_device sdb;
struct fb_fix_screeninfo *fix;
@@ -648,7 +648,7 @@
 }
 
 
-__initfunc(int sun3fb_init(void))
+int __init sun3fb_init(void)
 {
extern int con_is_present(void);
unsigned long addr;


-- 
Regards,
Rasmus([EMAIL PROTECTED])

"Women are like a beer. They look good,
they taste good, and as soon as you've
had one, you want another." -Homer Simpson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ack number in a connection-refused RST

[Andi Kleen]

On Fri, Oct 06, 2000 at 09:06:31PM +, David Wagner wrote:
> David S. Miller wrote:
> >Linux should not honor the incorrect sequence number.  If the sequence
> >number is incorrect, the RST could legitimately be for another
> >connection.
> 
> How could it be for another connection, if it has source and destination
> port numbers?  I thought the sequence number was there to prevent denial
> of service attacks, i.e., to prevent unauthorized third parties from
> tearing down established TCP connections; since third parties will not
> know (or be able to guess) the current 32-bit sequence number, they will 
> be unable to forge a valid RST packet.  Of course, this argument is still
> valid even if you accept off-by-one errors in the sequence number; the
> attacker still has to guess from a 31-bit space, which is slightly smaller
> than the original 32-bit space but still likely large enough for security.
> What am I missing?

You're missing dynamic IPs, NAT and reboot of hosts.


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

Re: ack number in a connection-refused RST

[David S. Miller]

   From: [EMAIL PROTECTED] (David Wagner)
   Date:6 Oct 2000 21:06:31 GMT

   How could it be for another connection, if it has source and
   destination port numbers?

Consider previously existing connections with the same src/dst/ports
and the effects of massive packet reordering and other transmission
delays.

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

Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler

[David Weinehall]

On Fri, Oct 06, 2000 at 04:19:55PM -0400, Byron Stanoszek wrote:
> On Fri, 6 Oct 2000, Rik van Riel wrote:
> 
> > 3. add the out of memory killer, which has been tuned with
> >-test9 to be ran at exactly the right moment; process
> >selection: "principle of least surprise"  <== OOM handling

I've tested v2.4.0test9+RielVMpatch now, together with the
memory_static program. It works terrific. No innocent process got
killed, just the offending one. And not until the memory was completely
depleted.

> In the OOM killer, shouldn't there be a check for PID 1 just to enforce that
> INIT will not be the victim? Sure its total_vm might be small, but if there
> was a memory leak in the kernel somewhere, it might eventually become the
> target.

If INIT has a memory-leak, it deserves to die. We have bigger problems
then anyway... And certainly, if INIT gets killed, we quickly notice
that something is wrong.

> I suppose, if it ever were to become the victim, your system wouldn't
> be too usable anyway...

Correct.

> Can you give me your rationale for selecting 'nice' processes as being
> badder?  Do you think it would be a good idea to scale the amount of
> badness according to how nice the process is (a nice value of 20 could
> get the full *2, otherwise a smaller multiplier)?
> 
> How about using the current process priority level instead of nicety.
> If a process was deprioritized (or auto-niced) because it was starting
> to eat up CPU time, AND its memory is abnormally high, then should
> that be our #1 victim? We also don't want to kill things like
> benchmarks either, but hopefully they wouldn't start eating up more
> than the available system memory.

I wouldn't care a least bit if a benchmark I'm running gets killed if
the memory runs out, but if my dnetc client which has low priority and
neatly works in the background without disturbing anything suddenly
gets killed when another program starts eating memory, I'd be dang
angry...


Standing ovations for Rik van Riel. You've managed to get the VM in
good shape, at least for my machine... Now I'll test it for some machines
with less and more memory (4MB and 64MB ram, with 16MB swap and 
0/256/512/1024/2048 MB swap respectively.)


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: ack number in a connection-refused RST

[David Wagner]

Andi Kleen wrote:
>On Fri, Oct 06, 2000 at 09:06:31PM +, David Wagner wrote:
>> David S. Miller wrote:
>> >Linux should not honor the incorrect sequence number.  If the sequence
>> >number is incorrect, the RST could legitimately be for another
>> >connection.
>> 
>> How could it be for another connection, if it has source and destination
>> port numbers?
>
>You're missing dynamic IPs, NAT and reboot of hosts.

Ok, but with dynamic IP, NAT, and reboots, you can also get incorrect
results with today's implementation, if you see a RST with the correct
sequence number (not the off-by-one incorrect one).  It's just a
probabilistic argument that this is unlikely to happen in practice --
namely, it only happens with probability 1/2^32 (you hope).

There's no fundamental reason why you couldn't accept off-by-one sequence
numbers as well, if it was deemed important for interoperability;
the probability would just increase to 1/2^31, which is still small
(albeit not as small as 1/2^32).

Right?  Or am I still missing something?  I'm not a TCP expert.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/