Re: [PATCH] console palette fix

[Dan Aloni]

On Sat, 7 Oct 2000, James Simmons wrote:

> 
> > Although this patch is correct, and was accepted in 2.4.*, it creates a
> > secondary problem after applying it - A dark textmode console for some
> > cards, unrelated to the frame buffer mode. An *additional* patch is needed
> > in order to fix it:
> 
> Yes their was this problem with a earlier patch but I was under the
> impression that the most recent patch (below) fixed this problem. Do you
> know which cards have this problem? I like to get a list of them to see
> what could be causing the problem. I believe it is a X server problem. My
> theory is that the problem occurs for video cards whose X servers use the
> gamma ramp. I personally have never seen this problem but if you can tell
> which cards specifically I can get that card and track down the problem.
> Has your patch been tested with all the cards avaliable with this problem?

I've seen the problem on both of my computers with Creative Riva TNT2. On
this card the palette turns darker. On other cards the palette turns to
rubbish or corrupted in another fashionable ways. It's a bug in those
cards - switching to video mode and back to text mode doesn't preserve the
text mode palette so the OS must restore it by itself.

It's not an X server problem, since the problem doesn't appear on 2.2.16
for instance, no mather which X-server you are using. Search lkml archives
for "dark console" you'll see a thread from 2 months ago that discusses
about this problem exactly. Read the console.c of 2.4 - Linus already
patched it this way (your patch and then my patch), so I suggest we do the
same in 2.2.

-- 
Dan Aloni 
[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/

No SCSI burning problem (was: Bug in "ide-pci.c")

[Dax Kelson]

Jeff V. Merkey said once upon a time (Fri, 6 Oct 2000):

> 
> Andre,
> 
> BTW, how did your testing of the speed=4 problem with ide-scsi turn
> out.  We are still seeing the speed=2 problem on 2.4.0-pre9.  I cannot
> get the drive to burn clean unless the speed setting is cranked down to
> speed=2.
> 
> Jeff 

I just burned Red Hat 7.0 disk1 iso image at on a SCSI 4x burner without
any problems.  I have an IDE Plextor 12x burner at work, Monday I'll try a
burn under 2.4.0-test9.

distro: Red Hat 7.0
kernel: 2.4.0-test9-pre8
Cdrecord 1.9
True SCSI Yamaha 4x burner

(scsi0)  found at PCI 0/16/0
(scsi0:0:4:0) Synchronous at 8.0 Mbyte/sec, offset 15.
  Vendor: YAMAHAModel: CRW4416S  Rev: 1.0j
  Type:   CD-ROM ANSI SCSI revision: 02
Detected scsi CD-ROM sr1 at scsi0, channel 0, id 4, lun 0
Uniform CD-ROM driver Revision: 3.11
sr1: scsi3-mmc drive: 16x/16x writer cd/rw xa/form2 cdda tray


[root@localhost burn]# md5sum redhat-7.0-disc1.iso 
626b7d18033e320c27c8cd58cc37a288  redhat-7.0-disc1.iso

[did a 4x burn]

[root@localhost dkelson]# md5sum /dev/scd1
626b7d18033e320c27c8cd58cc37a288  /dev/scd1


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

PCI function docs

[daniel sheltraw]

Hello Kernel list

Would someone please tell me where I can find docs/info on using
the kernel PCI functions under linux 2.2 and 2.4 (2.2 is my immediate
concern). I found Alan Cox article in Linux Magazine and the pci.txt
file in my /usr/src/linux/Documentation directory. Is there more?
Who has been writing the direct PCI functions (not BIOS PCI) and
do they/you have a web page with docs?

Thank you very much,
Daniel Sheltraw
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

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

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

No Subject

[daniel sheltraw]

Hello Kernel list

Would someone please tell me where I can find docs/info on using
the kernel PCI functions under linux 2.2 and 2.4 (2.2 is my immediate
concern). I found Alan Cox article in Linux Magazine and the pci.txt
file in my /usr/src/linux/Documentation directory. Is there more?
Who has been writing the direct PCI functions (not BIOS PCI) and
do they/you have a web page with docs?

Thank you very much,
Daniel Sheltraw
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

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

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

Re: Bug in "ide-pci.c"

[Sean Estabrooks]

Andre,
(Thanks for calling my bluff) && (I was wrong).  

  Sean


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

Re: Bug in "ide-pci.c"

[Tom Leete]

Sean Estabrooks wrote:
> 
> Hi Andre,
> 
>   The if() logic must then rely on implementation specific compiler
> details and not have any optimizations which break this code.   While it may
> "WORK" it isn't particularly reliable code.
> 
>   Sean

Nope, the logical ops are sequence points required by
standard to lazy evaluate left to right. For ||, that means
they operate in order till they find a true.

Tom
-
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]

I don't know a lawyer I would trust who would give free legal advice on a
mailing list without the usual disclaimers.

And I don't care what you've done elsewhere, you have, here, been misleading
about patent law. I stand by my recommendation that people who are
interested should read the Nolo Press book and then, if they have specific
issues, consult an IP lawyer on those particular issues.

In addition to the Nolo press, by the way, the US Patent Office now has a
web site with good general information for those people who are interested
in US patent issues.  (http://www.uspto.gov/) I suppose there is a similar
web site for people interested in EU patent specifics as well.  One of the
serveral ways in which you were mistaken in your assertions is that you've
neglected to clarify where US Patent Law differs from Patent Law in other
jurisdictions.  You may be in Utah, but not everyone on this mailing list
is.




> -Original Message-
> From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 06, 2000 3:40 PM
> To: Marty Fouts
> Cc: 'jesse'; [EMAIL PROTECTED]
> Subject: Re: Tux 2 patents
> 
> 
> 
> 
> Marty Fouts wrote:
> > 
> > I don't do pissing matches, Jeff, and won't compare the 
> quality of the IP
> > experts I have access to to the quality of those you have access to.
> > 
> > I will say that you are wrong about disclosure because you 
> have overly
> > simplified, and again recommend that people who care should 
> discuss their
> > specific cases with real lawyers, which neither you no or I are.
> 
> Excuse me -- I was one of the attorneys on the Novell/TRG lawsuit --
> check my motions
> and filings.  In fact, check the 4th District Court in general for my
> filings in other cases.  You can check the Texas courts for 1980's as
> well.  Just because I have been a software 
> engineer for the past 20 years does not mean I did something else in a
> previous life. 
> 
> Since all my friends are lawyers and TRG runs a law firm out of here
> should say something.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Bug in "ide-pci.c"

[Andre Hedrick]

On Fri, 6 Oct 2000, Sean Estabrooks wrote:

> Hi Andre,
> 
>   The if() logic must then rely on implementation specific compiler
> details and not have any optimizations which break this code.   While it may
> "WORK" it isn't particularly reliable code.

If that is the case and it is proven then there is more code than mine
that will fail.  Also if the compiler is allowed in optimizations to break
specific test order, then it is a bad compiler.

Order of operation is critical in writing code.

In my world of ATA, you dork the order of a command and you get crap on
your drive.  So since there is not crap on the drive in general, I am
accounting for stupid programmer errors in the past, I call your bluff.

If you issue the command register first the the rest of the register will
execute on the next command register.  This is doing thing bass-ackwards.

void go_take_a_dump (float load)
{
  if (pull_down_pants() && purge_bowles() && wipe_anus() && pull_up_pants())
 flush(load);
  else
 wear(load);
}

You do this out of order and this is more descriptive.

Now if you are complaining about logical operators in the test and how
these get optimized then you point is noted.

Since I was an astronomer and +/- one AU (93,000,000 miles) is critical,
feel free to check the rules for order.  Then you can call my bluff.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

FYI, I have a new baby-girl and thus the diaper-humor!

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

will ip 6 in ip4 tunnelling be fixed anytime soon ?

[Gerhard Mack]

Is there an ETA on having ip6 in ip4 tunnelling working with the latest
net-utils??

--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.

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

Re: Bug in "ide-pci.c"

[Sean Estabrooks]

Hi Andre,

  The if() logic must then rely on implementation specific compiler
details and not have any optimizations which break this code.   While it may
"WORK" it isn't particularly reliable code.

  Sean


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

RedHat 7.0 anaconda installer doesn't support devfs

[Joseph Fannin]

Jeff Merkey wrote:

>On Sat, Oct 07, 2000 at 12:31:05AM -0400, jeff millar wrote: 
>> Redhat support got back to me today and said 7.0 doesnt support
>> upgrades to systems running devfs. But I thought sure than Linus
>> blessed it! :-) 
>> Does anyone have a fix? 
>
>Good question. I noticed this as well. 


 I couldn't run devfs on a fresh install of RedHat 7 either; the
use of labels in fstab to identify partitions seems to preclude this.
 Well, I *could* have hacked all the necessary scripts if I knew what
they were, I guess.

 Is there any means of using devfs and disk/partition levels together?

  P.S.  Sorry if this breaks the threading.

--
Joseph Fannin
fannin.30 *at* osu.edu


___
To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax,
all in one place - sign up today at http://www.zdnetonebox.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: Hot swap IDE

[Andre Tomt]

I know, replying "to the wrong person" is a little weak, but I lost the
original post in a hardware lockup on my workstation (2.4-test9, latest DRI
CVS code, mga HALlib), so this has to go. And please forgive me about
posting from MS Outlook Express this time, it's only temp :-)

> On Thu, 5 Oct 2000, Mitchell Hicks wrote:

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

A utility called "idectl" is bundled in the contrib directory of the hdparm
source. With this utility you can disable, enable and reset IDE channels
without rebooting or doing module inserts/removals. But I have to warn you -
it's highly experimental.

At home I have a RAID 1 setup, two IDE drives and one SCSI in my
coda/nfs/smb server. It's set up to have a spare MBR/bootblock on all
drives, so the BIOS can do failover to the next drive on failure. I have a
lilo.conf for each drive, with some tricks to make lilo happy when
installing the bootloader. It's working like a charm, using a RAID patch for
Linux 2.2 (2.4 RAID code mostly)

I did test hotswapping (alough the chipset or disks does not support it
native, standard VIA UDMA33 chipset), pulling random drives while the server
was running, with raidhotadd and idectl, it went along without a hitch. I DO
NOT hotswap IDE drives usually, this was only a test of what the setup was
able to handle. :)

--
André Tomt
[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: RedHat 7.0 anaconda installer doesn't support devfs

[Jeff V. Merkey]

On Sat, Oct 07, 2000 at 12:31:05AM -0400, jeff millar wrote:
> Redhat support got back to me today and said 7.0 doesnt support
> upgrades to systems running devfs.  But I thought sure than Linus blessed
> it! :-)
> Does anyone have a fix?

Good question.  I noticed this as well.  

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/
-
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: Window Scale Option broken in 2.2.x

[David S. Miller]

You need to set your /proc/sys/net/core/{w,r}mem* values large enough
for the window scale to have any reason to have a non-zero value.

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/

RedHat 7.0 anaconda installer doesn't support devfs

[jeff millar]

Redhat support got back to me today and said 7.0 doesnt support
upgrades to systems running devfs.  But I thought sure than Linus blessed
it! :-)
Does anyone have a fix?

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

Re: Bug in "ide-pci.c"

[Jeff V. Merkey]

Andre,

BTW, how did your testing of the speed=4 problem with ide-scsi turn
out.  We are still seeing the speed=2 problem on 2.4.0-pre9.  I cannot
get the drive to burn clean unless the speed setting is cranked down to
speed=2.

Jeff 

Andre Hedrick wrote:
> 
> On Fri, 6 Oct 2000, Sean Estabrooks wrote:
> 
> > ide-pci.c bug:
> >
> > ide_setup_pci_baseregs() may inappropriately report device as not capable of full 
>native PCI:
> >
> > //  BUGGY LINE: 
> > if (pci_read_config_byte(dev, PCI_CLASS_PROG, &progif) || (progif & 5) != 5) {
> > //  =   TWO CONDITIONS USING PROGIF
> >if ((progif & 0xa) != 0xa) {
> >   printk("%s: device not capable of full native PCI mode\n", name);
> >   return 1;
> >}
> >
> >  ...
> >
> > In the first line of code above there is no guarantee that the first condition 
>will be executed
> > before the second.  As progif is set to 0 before this block of code, the second 
>test will always
> > be true if it is executed prior to the first.
> 
> if () are serial in test.
> 
> >
> >
> >
> 
> 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/
-
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] STRIP support for new Metricom modems

[Alex Belits]

  I have made changes in STRIP address handling to accomodate new 128Kbps
Ricochet GS "modems" that Metricom makes now. There is no official
maintainer of STRIP code (maybe I should become one, however folks at
Stanford who work on the original project probably will be more
appropriate), so I am only sending it here.

  The patch was tested on 2.2.17 (original tested with Metricom modem with
serial link and patched for USB to test the same modem with USB link), and
2.4.0-test9 (unchanged), in all tests I had old modems (Original
Ricochet and Ricochet SE) talking to each other and old modems talking
with Ricochet GS.

Explanations are at http://phobos.illtel.denver.co.us/~abelits/metricom/

diff -u linux-2.2.17-orig/drivers/net/strip.c linux-2.2.17/drivers/net/strip.c
--- linux-2.2.17-orig/drivers/net/strip.c   Sun Nov  8 13:48:06 1998
+++ linux-2.2.17/drivers/net/strip.cThu Sep 28 11:06:46 2000
@@ -14,7 +14,7 @@
  * for kernel-based devices like TTY.  It interfaces between a
  * raw TTY, and the kernel's INET protocol layers (via DDI).
  *
- * Version:@(#)strip.c 1.3 July 1997
+ * Version:@(#)strip.c 1.4 September 2000
  *
  * Author: Stuart Cheshire <[EMAIL PROTECTED]>
  *
@@ -66,12 +66,15 @@
  *  It is no longer necessarily to manually set the radio's
  *  rate permanently to 115200 -- the driver handles setting
  *  the rate automatically.
+ *
+ *  v1.4 September 2000 (AB)
+ *  Added support for long serial numbers.
  */
 
 #ifdef MODULE
-static const char StripVersion[] = "1.3-STUART.CHESHIRE-MODULAR";
+static const char StripVersion[] = "1.4-STUART.CHESHIRE-MODULAR";
 #else
-static const char StripVersion[] = "1.3-STUART.CHESHIRE";
+static const char StripVersion[] = "1.4-STUART.CHESHIRE";
 #endif
 
 #define TICKLE_TIMERS 0
@@ -897,20 +900,37 @@
  * Convert a string to a Metricom Address.
  */
 
-#define IS_RADIO_ADDRESS(p) ( \
+#define IS_RADIO_ADDRESS_1(p) (   \
   isdigit((p)[0]) && isdigit((p)[1]) && isdigit((p)[2]) && isdigit((p)[3]) && \
   (p)[4] == '-' &&\
   isdigit((p)[5]) && isdigit((p)[6]) && isdigit((p)[7]) && isdigit((p)[8]))
 
+#define IS_RADIO_ADDRESS_2(p) (   \
+  isdigit((p)[0]) && isdigit((p)[1]) &&   \
+  (p)[2] == '-' &&\
+  isdigit((p)[3]) && isdigit((p)[4]) && isdigit((p)[5]) && isdigit((p)[6]) && \
+  (p)[7] == '-' &&\
+  isdigit((p)[8]) && isdigit((p)[9]) && isdigit((p)[10]) && isdigit((p)[11])  )
+
 static int string_to_radio_address(MetricomAddress *addr, __u8 *p)
 {
-if (!IS_RADIO_ADDRESS(p)) return(1);
+if (IS_RADIO_ADDRESS_2(p))
+{
+addr->c[0] = 0;
+addr->c[1] = (READHEX(p[0]) << 4 | READHEX(p[1])) ^ 0xFF;
+addr->c[2] = READHEX(p[3]) << 4 | READHEX(p[4]);
+addr->c[3] = READHEX(p[5]) << 4 | READHEX(p[6]);
+addr->c[4] = READHEX(p[8]) << 4 | READHEX(p[9]);
+addr->c[5] = READHEX(p[10]) << 4 | READHEX(p[11]);
+}else{
+if(!IS_RADIO_ADDRESS_1(p)) return(1);
 addr->c[0] = 0;
 addr->c[1] = 0;
 addr->c[2] = READHEX(p[0]) << 4 | READHEX(p[1]);
 addr->c[3] = READHEX(p[2]) << 4 | READHEX(p[3]);
 addr->c[4] = READHEX(p[5]) << 4 | READHEX(p[6]);
 addr->c[5] = READHEX(p[7]) << 4 | READHEX(p[8]);
+}
 return(0);
 }
 
@@ -920,6 +940,9 @@
 
 static __u8 *radio_address_to_string(const MetricomAddress *addr, 
MetricomAddressString *p)
 {
+if(addr->c[1])
+sprintf(p->c, "%02X-%02X%02X-%02X%02X", addr->c[1] ^ 0xFF, addr->c[2], 
+addr->c[3], addr->c[4], addr->c[5]);
+else
 sprintf(p->c, "%02X%02X-%02X%02X", addr->c[2], addr->c[3], addr->c[4], 
addr->c[5]);
 return(p->c);
 }
@@ -1481,6 +1504,12 @@
 
 *ptr++ = 0x0D;
 *ptr++ = '*';
+if(haddr.c[1])
+{
+*ptr++ = hextable[(haddr.c[1] >> 4) ^ 0xF];
+*ptr++ = hextable[(haddr.c[1] & 0xF) ^ 0xF];
+*ptr++ = '-';
+}
 *ptr++ = hextable[haddr.c[2] >> 4];
 *ptr++ = hextable[haddr.c[2] & 0xF];
 *ptr++ = hextable[haddr.c[3] >> 4];

-
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: RedHat 7.0 sets /var/named to root.root

[Jeff V. Merkey]

Reposted to RedHat list (thanks to the person who provided the list
address).

Jeff

"Jeff V. Merkey" wrote:
> 
> Heads up.  The anaconda Installer on 7.0 is setting /var/named to
> root.root instead of named.named which causes zone transfers to fail
> until you chown -R the directory with bind-8.  Does it in 6.2 as well.
> 
> 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/
-
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: Window Scale Option broken in 2.2.x

[bert hubert]

On Sat, Oct 07, 2000 at 02:53:27AM +0200, bert hubert wrote:
> On Fri, Oct 06, 2000 at 07:56:15PM -0400, Lawrence MacIntyre wrote:
> > Hi:
> > 
> > The window scale option doesn't appear to work in 2.2.16, 2.2.17, and
> > 2.2.18.  I've got an old 2.2.5 machine and it doesn't work either.  Is
> > this supposed to work?  There is code in the kernel to do the window
> > scale option, but it always sends a 0 value.  It does, however, work
> > correctly in 2.4.0-test9-pre9.  I have tested it using ttcp -r -s
> > -b131072 (the -b flag does a setsockopt to increase the receive buffer,
> > and therefore the window size).
> > 
> > p.s.  Yes, /proc/sys/net/ipv4/tcp_window_scaling is 1
> 
> Userspace programs do need to suggest to the kernel that they want a larger
> window - this is documented somewhere.

Don't mind me, I'm donning my brown paper bag.

-- 
PowerDNS Versatile DNS Services  
Trilab   The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

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

Re: Bug in "ide-pci.c"

[Andre Hedrick]

On Fri, 6 Oct 2000, Sean Estabrooks wrote:

> ide-pci.c bug:
> 
> ide_setup_pci_baseregs() may inappropriately report device as not capable of full 
>native PCI:
> 
> //  BUGGY LINE: 
> if (pci_read_config_byte(dev, PCI_CLASS_PROG, &progif) || (progif & 5) != 5) {
> //  =   TWO CONDITIONS USING PROGIF 
>if ((progif & 0xa) != 0xa) {
>   printk("%s: device not capable of full native PCI mode\n", name);
>   return 1;
>}
> 
>  ...
> 
> In the first line of code above there is no guarantee that the first condition 
>will be executed
> before the second.  As progif is set to 0 before this block of code, the second test 
>will always
> be true if it is executed prior to the first.

if () are serial in test.

> 
> 
> 

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: Window Scale Option broken in 2.2.x

[bert hubert]

On Fri, Oct 06, 2000 at 07:56:15PM -0400, Lawrence MacIntyre wrote:
> Hi:
> 
> The window scale option doesn't appear to work in 2.2.16, 2.2.17, and
> 2.2.18.  I've got an old 2.2.5 machine and it doesn't work either.  Is
> this supposed to work?  There is code in the kernel to do the window
> scale option, but it always sends a 0 value.  It does, however, work
> correctly in 2.4.0-test9-pre9.  I have tested it using ttcp -r -s
> -b131072 (the -b flag does a setsockopt to increase the receive buffer,
> and therefore the window size).
> 
> p.s.  Yes, /proc/sys/net/ipv4/tcp_window_scaling is 1

Userspace programs do need to suggest to the kernel that they want a larger
window - this is documented somewhere.

-- 
PowerDNS Versatile DNS Services  
Trilab   The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

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

Window Scale Option broken in 2.2.x

[Lawrence MacIntyre]

Hi:

The window scale option doesn't appear to work in 2.2.16, 2.2.17, and
2.2.18.  I've got an old 2.2.5 machine and it doesn't work either.  Is
this supposed to work?  There is code in the kernel to do the window
scale option, but it always sends a 0 value.  It does, however, work
correctly in 2.4.0-test9-pre9.  I have tested it using ttcp -r -s
-b131072 (the -b flag does a setsockopt to increase the receive buffer,
and therefore the window size).

p.s.  Yes, /proc/sys/net/ipv4/tcp_window_scaling is 1
-- 
 Lawrence
~

Lawrence MacIntyre  Center for Information Infrastructure Technology
[EMAIL PROTECTED]   http://www.ciit.y12.doe.gov/~lpz 865.574.8696
-
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/

RedHat 7.0 sets /var/named to root.root

[Jeff V. Merkey]

Heads up.  The anaconda Installer on 7.0 is setting /var/named to
root.root instead of named.named which causes zone transfers to fail
until you chown -R the directory with bind-8.  Does it in 6.2 as well.  

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: Quota fixes and a few questions

[Stephen C. Tweedie]

Hi Jan,

On Wed, Sep 27, 2000 at 02:56:20PM +0200, Jan Kara wrote:
> 
>   So I've been thinking about fixes in quota (and also writing some parts).

While we're at it, I've attached a patch which I was sent which simply
teaches quota about ext3 as a valid fs type in fstab.  It appears to
work fine for me --- let me know if you want me to validate a new
quotautils on ext3.

Cheers,
 Stephen


--- quota-2.00-pre3/hasquota.c.ext3 Sun Jul 25 16:08:47 1999
+++ quota-2.00-pre3/hasquota.c  Fri Sep  8 17:57:43 2000
@@ -28,7 +28,7 @@
 #define min(x,y) ((x) < (y)) ? (x) : (y)
 
 #define CORRECT_FSTYPE(type) \
-(!strcmp(type,MNTTYPE_EXT2))
+(!strcmp(type,MNTTYPE_EXT2) || !strcmp(type,MNTTYPE_EXT3))
 
 char *qfextension[] = INITQFNAMES;
 static char *qfname = QUOTAFILENAME;
--- quota-2.00-pre3/mntent.h.ext3   Sun Jul 25 16:08:47 1999
+++ quota-2.00-pre3/mntent.hFri Sep  8 17:57:43 2000
@@ -11,6 +11,7 @@
 #define MNTTYPE_COHERENT   "coherent"  /* Coherent file system */
 #define MNTTYPE_EXT"ext"   /* Extended file system */
 #define MNTTYPE_EXT2   "ext2"  /* Second Extended file system */
+#define MNTTYPE_EXT3   "ext3"  /* Second Extended file system w/ 
+journaling */
 #define MNTTYPE_HPFS   "hpfs"  /* OS/2's high performance file system 
*/
 #define MNTTYPE_ISO9660"iso9660"   /* ISO CDROM file system */
 #define MNTTYPE_MINIX  "minix" /* MINIX file system */
--- quota-2.00-pre3/quotacheck.c.ext3   Fri Sep  8 17:57:43 2000
+++ quota-2.00-pre3/quotacheck.cFri Sep  8 17:58:26 2000
@@ -292,7 +292,7 @@
st.st_nlink, st.st_blocks);
 
 #if defined(EXT2_DIRECT)
-   if (!strcmp(mnt->mnt_type, MNTTYPE_EXT2)) {
+   if (!strcmp(mnt->mnt_type, MNTTYPE_EXT2) || !strcmp(mnt->mnt_type, 
+MNTTYPE_EXT3)) {
   ext2_direct_scan(mnt_fsname);
} else if (mnt->mnt_dir) {
 #else

Bug in "ide-pci.c"

[Sean Estabrooks]

ide-pci.c bug:
 
ide_setup_pci_baseregs() may inappropriately 
report device as not capable of full native PCI:
 
//  BUGGY LINE: 
    if (pci_read_config_byte(dev, 
PCI_CLASS_PROG, &progif) || (progif & 5) != 5) 
{//  =   TWO CONDITIONS USING PROGIF 

       if ((progif & 
0xa) != 0xa) {      printk("%s: 
device not capable of full native PCI mode\n", 
name);      return 
1;   }
 
 ...
 
In the first line of code above there is no 
guarantee that the first condition will be executed
before the second.  As progif is set to 0 before this block of code, 
the second test will always
be true if it is executed prior to the first.
 
 

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

[David Weinehall]

On Fri, Oct 06, 2000 at 11:27:18PM +0200, David Weinehall wrote:
> 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.

More tests conducted:

16MB memory, 32MB swapfile + 64MB swappartition (in that order)
16MB memory, 64MB swappartition + 32MB swapfile
16MB memory, 64MB swappartition
16MB memory, 32MB swapfile
16MB memory, NO swap

64MB memory, 256MB swappartition
64MB memory, NO swap

All survives just fine.

I can't do anything else while running the memory-eater program
(this is via ssh; haven't tried locally), but when it finally gets
killed, everything works ok again.


/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: BUG in tcp.c ?

[David S. Miller]

   Date:   Fri, 6 Oct 2000 17:45:47 -0200 (BRST)
   From: Marcelo Tosatti <[EMAIL PROTECTED]>

   2.2.17 is broken too. 

I've fixed it in my 2.2.x sources as well.
Thanks.

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: BUG in tcp.c ?

[Marcelo Tosatti]

On Fri, 6 Oct 2000, David S. Miller wrote:

>Date:   Fri, 6 Oct 2000 19:25:38 -0300 (BRST)
>From: Rik van Riel <[EMAIL PROTECTED]>
> 
>Is this an actual bug, or am I overlooking something?
> 
> It is a bug and I'll change TCP's sendmsg to use sk->allocation as it
> should.  Thanks for pointing this out.
 

2.2.17 is broken too. 

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

Marty Fouts wrote:
> 
> I don't do pissing matches, Jeff, and won't compare the quality of the IP
> experts I have access to to the quality of those you have access to.
> 
> I will say that you are wrong about disclosure because you have overly
> simplified, and again recommend that people who care should discuss their
> specific cases with real lawyers, which neither you no or I are.

Excuse me -- I was one of the attorneys on the Novell/TRG lawsuit --
check my motions
and filings.  In fact, check the 4th District Court in general for my
filings in other cases.  You can check the Texas courts for 1980's as
well.  Just because I have been a software 
engineer for the past 20 years does not mean I did something else in a
previous life. 

Since all my friends are lawyers and TRG runs a law firm out of here
should say something.


Jeff

> 
> As a starting point I recommend Nolo press' "Patent Copyright & Trademark"
> book and that an individual see a lawyer for their specific case.
> 
> (The Nolo press book can be bought online at
> http://www.nolo.com/product/pct.html?t=0023003202000)
> 
> -Original Message-
> From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 06, 2000 2:35 PM
> To: Marty Fouts
> Cc: 'jesse'; [EMAIL PROTECTED]
> Subject: Re: Tux 2 patents
> 
> I've filed lots of patents in my day Marty -- this is correct.  I have
> two patent lawyers on staff.  Want to try again..
> 
>
-
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]

David Schwartz wrote:
> 
> > I've filed lots of patents in my day Marty -- this is correct.  I have
> > two patent lawyers on staff.  Want to try again..
> >
> > Jeff
> 
> > > 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.
> 
> No, it's incorrect and misleading. See for example
> http://www.uspto.gov/web/offices/pac/doc/general/novelty.htm which states:
> 
> "In order for an invention to be patentable it must be new as defined in the
> patent law, which provides that an invention cannot be patented if: "(a) the
> invention was known or used by others in this country, or patented or
> described in a printed publication in this or a foreign country, before the
> invention thereof by the applicant for patent," or "(b) the invention was
> patented or described in a printed publication in this or a foreign country
> or in public use or on sale in this country more than one year prior to the
> application for patent in the United States . . .""
> 
> The "year of protection" has nothing whatsoever to do with provisional
> patent applications which are something else entirely.
> 
> DS

Which is what I described in previous postings on this thread.  Go read
them.  

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: BUG in tcp.c ?

[David S. Miller]

   Date:   Fri, 6 Oct 2000 19:25:38 -0300 (BRST)
   From: Rik van Riel <[EMAIL PROTECTED]>

   Is this an actual bug, or am I overlooking something?

It is a bug and I'll change TCP's sendmsg to use sk->allocation as it
should.  Thanks for pointing this out.

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: is there a limit on bss size?

[Philipp Rumpf]

On Fri, Oct 06, 2000 at 12:32:35PM +0300, Petko Manolov wrote:
> It is not so difficult as it looks.

I don't see it being difficult at all ...

> 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

I'm unconvinced we need to map more than 4 MB into low virtual addresses;
nothing seems to break with

ENTRY(swapper_pg_dir)
.long 0x00102007
.fill BOOT_USER_PGD_PTRS-1,4,0

here and I don't see anything that would break unless we moved head.S ...

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

Arbitrary kernel size limits are bad.  Not complaining about a kernel
that definitely won't boot while building is even worse, and I think
the latter is actually pretty easy to fix ...
-
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/

BUG in tcp.c ?

[Rik van Riel]

Hi,

I found the following lines in tcp.c, after trying to identify
and track down what I thought to be an nbd bug...

net/ipv4/tcp.c:

   1028   if (tcp_memory_free(sk))
   1029   skb = tcp_alloc_skb(sk, tmp, GFP_KERNEL)

While this looks ok at first glance, it rather conflicts with
the following lines of code from net/core/sock.c:

785   skb = alloc_skb(try_size, sk->allocation);

And from drivers/block/nbd.c:

109   sock->sk->allocation = GFP_ATOMIC;
..
121   if (send)
122   result = sock_sendmsg(sock, &msg, size);


Here we see that the nbd driver sets the allocation type to
GFP_ATOMIC (and for a good reason), sock.c honours this field,
but for some reason tcp.c doesn't ...

Is this an actual bug, or am I overlooking something?

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: Tux 2 patents

[David Schwartz]

> I've filed lots of patents in my day Marty -- this is correct.  I have
> two patent lawyers on staff.  Want to try again..
>
> Jeff

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

No, it's incorrect and misleading. See for example
http://www.uspto.gov/web/offices/pac/doc/general/novelty.htm which states:

"In order for an invention to be patentable it must be new as defined in the
patent law, which provides that an invention cannot be patented if: "(a) the
invention was known or used by others in this country, or patented or
described in a printed publication in this or a foreign country, before the
invention thereof by the applicant for patent," or "(b) the invention was
patented or described in a printed publication in this or a foreign country
or in public use or on sale in this country more than one year prior to the
application for patent in the United States . . .""

The "year of protection" has nothing whatsoever to do with provisional
patent applications which are something else entirely.

DS

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

I don't do pissing matches, Jeff, and won't compare the quality of the IP
experts I have access to to the quality of those you have access to.

I will say that you are wrong about disclosure because you have overly
simplified, and again recommend that people who care should discuss their
specific cases with real lawyers, which neither you no or I are.

As a starting point I recommend Nolo press' "Patent Copyright & Trademark"
book and that an individual see a lawyer for their specific case.

(The Nolo press book can be bought online at
http://www.nolo.com/product/pct.html?t=0023003202000)



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


I've filed lots of patents in my day Marty -- this is correct.  I have
two patent lawyers on staff.  Want to try again..

 
-
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: sys_mlock/sys_munlock

[Petr Vandrovec]

On  6 Oct 00 at 17:45, Atul Mukker. wrote:
> Hi,
> Can i use sys_mlock and sys_munlock in my driver module to lock/unlock the
> user address pages.
> 
> Thanks
> 
> P.S.Please mark your mail CC to [EMAIL PROTECTED]

VMware's vmmon and in-kernel raw devices (and kiobufs) use simple
incrementing/decrementing page count - first cause pagein (vmmon uses
get_user(), kiobufs something more sophisticated), then use get_page
on that page. To release, use put_page().

But do not forget to look at my today's report about page->mapping == NULL...
If you'll do it with shared-mapped pages, and someone truncates file
they are mapped from, bad things can happen under 2.4.0 :-(
Best regards,
Petr Vandrovec
[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/

sys_mlock/sys_munlock

[Atul Mukker.]

Hi,
Can i use sys_mlock and sys_munlock in my driver module to lock/unlock the
user address pages.

Thanks

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

Re: Tux 2 patents

[Jeff V. Merkey]

I've filed lots of patents in my day Marty -- this is correct.  I have
two patent lawyers on staff.  Want to try again..

Jeff

Marty Fouts wrote:
> 
> 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]

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/

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

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

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

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

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

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

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]

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

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

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

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

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: [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: 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

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

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

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

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/

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);
  

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/

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

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/

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

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/

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

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

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

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.

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/

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/

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