Re: hotmail not dealing with ECN

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> RFC793, where is lists the unused flag bits as "reserved".
> That is pretty clear to me.  It just has to say that
> they are reserved, and that is what it does.

Actually I read somehwre "must be 0", but I am afraid dont know where anymore.
anyway, it does not say "must be checked for zero".

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

2.4.0 uptime

[Hans Eric Sandström]

BP6/Dual Cel 400 (the 2.0 load is 
setiathome)
--
[root@zekeserv /root]# uptime  
8:28am  up 20 days, 13:04,  2 users,  load average: 2.00, 2.00, 
2.00[root@zekeserv /root]# uname -aLinux zekeserv 2.4.0 #2 SMP Fri Jan 5 
07:37:01 CET 2001 i686 unknown[root@zekeserv 
/root]#--

Possible Bug: drivers/sound/maestro.c

[Michael B. Trausch]

Hello,

I've been using this driver and this hardware since I started running
Kernel 2.2.16.  It _works_, however, whenever I have a program that I
compile that's especially large (the kernel, glibc, etc.), or copy/move
lots of files around, the driver starts to fuzz lots of the sound going to
the card - even after the activity causing the load has stopped.  It
happens in both the left and the right channel, and the only way to
resolve it is to kill the process with /dev/dsp open (typically mpg123),
and then start it again.

I attempted to see if I could get into it and maybe fix it and try things
out myself, however, I got into the driver file and *wow*.  I only know a
little bit of C, and I've never messed with anything that's not an
application program (I was attempting to write an OS for quite some time,
but I gave up... Intel is just too freakin' hard to write for, and I don't
have the money for anything else).

As it sits, I could not even start to make changes, I didn't understand
anything in the file, as to what it was or whatnot.  Otherwise, I'd have
attempted and maybe been successful enough to put a patch in to the list.

I don't know if anyone else here runs with that card, or whatnot.  This
one is brand new, it's PCI ID is as follows, from /proc/pci:

  Bus  0, device  10, function  0:
Multimedia audio controller: ESS Technology ES1978 Maestro 2E (rev 16).
  IRQ 11.
  Master Capable.  Latency=64.  Min Gnt=2.Max Lat=24.
  I/O at 0xec00 [0xecff].

I would be happy to place it in a static bag and small box if anyone cared
to work on it, if someone wanted to borrow it to write for it.  It is my
only sound board right now, I used to have an SB16 (ISA) but I couldn't
use that becuase my video board (ATI, see below) would make weird noises
on it whenever the display had major things going on in X.

Bus  1, device   0, function  0:
  VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 92).
Master Capable.  Latency=64.  Min Gnt=8.
Non-prefetchable 32 bit memory at 0xe000 [0xe0ff].
I/O at 0xc000 [0xc0ff].
Non-prefetchable 32 bit memory at 0xe200 [0xe2000fff].

Thank you much!

- Mike

===
Michael B. Trausch[EMAIL PROTECTED]
Avid Linux User since April, '96!   AIM:  ML100Smkr

  Contactable via IRC (DALNet) or AIM as ML100Smkr
===

-
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](s): Use spinlocks instead of STI/CLI in SoundBlaster

[Chris Rankin]

Hi,

I hear on the grapevine that 2.4 kernel modules should use spinlocks
in preference to cli() and sti(). Well I'm not sure how big a win it
is, particularly on a UP machine, but here's a patch for the
SoundBlaster. I've added a spinlock_t to the "struct b_devc" so that
multiple SoundBlasters each get their own lock. After all, each SB has
its own IRQ and IO, correct?

There also seems to be something here called a Jazz16. This has a
global lock because it looks like there can only be one of them.

--- linux-2.4.0/drivers/sound/sb.h.orig Fri Jan 26 13:57:40 2001
+++ linux-2.4.0/drivers/sound/sb.h  Fri Jan 26 13:58:42 2001
@@ -137,6 +137,8 @@
   void (*midi_input_intr) (int dev, unsigned char data);
   void *midi_irq_cookie;   /* IRQ cookie for the midi */
 
+  spinlock_t lock;
+
   struct sb_module_options sbmo;   /* Module options */
 
} sb_devc;
--- linux-2.4.0/drivers/sound/sb_audio.c.orig   Fri Jan 26 13:54:56 2001
+++ linux-2.4.0/drivers/sound/sb_audio.cFri Jan 26 15:16:59 2001
@@ -19,8 +19,11 @@
  * Daniel J. Rodriksson: Changes to make sb16 work full duplex.
  *   Maybe other 16 bit cards in this code could behave
  *   the same.
+ * Chris Rankin: Use spinlocks instead of CLI/STI
  */
 
+#include 
+
 #include "sound_config.h"
 
 #include "sb_mixer.h"
@@ -43,23 +46,22 @@
if (mode == OPEN_READ)
return -EPERM;
}
-   save_flags(flags);
-   cli();
+   spin_lock_irqsave(>lock, flags);
if (devc->opened)
{
- restore_flags(flags);
+ spin_unlock_irqrestore(>lock, flags);
  return -EBUSY;
}
if (devc->dma16 != -1 && devc->dma16 != devc->dma8 && !devc->duplex)
{
if (sound_open_dma(devc->dma16, "Sound Blaster 16 bit"))
{
-   restore_flags(flags);
+   spin_unlock_irqrestore(>lock, flags);
return -EBUSY;
}
}
devc->opened = mode;
-   restore_flags(flags);
+   spin_unlock_irqrestore(>lock, flags);
 
devc->irq_mode = IMODE_NONE;
devc->irq_mode_16 = IMODE_NONE;
@@ -182,8 +184,7 @@
 
devc->irq_mode = IMODE_OUTPUT;
 
-   save_flags(flags);
-   cli();
+   spin_lock_irqsave(>lock, flags);
if (sb_dsp_command(devc, 0x14)) /* 8 bit DAC using DMA */
{
sb_dsp_command(devc, (unsigned char) (count & 0xff));
@@ -191,7 +192,7 @@
}
else
printk(KERN_WARNING "Sound Blaster:  unable to start DAC.\n");
-   restore_flags(flags);
+   spin_unlock_irqrestore(>lock, flags);
devc->intr_active = 1;
 }
 
@@ -213,8 +214,7 @@
 
devc->irq_mode = IMODE_INPUT;
 
-   save_flags(flags);
-   cli();
+   spin_lock_irqsave(>lock, flags);
if (sb_dsp_command(devc, 0x24)) /* 8 bit ADC using DMA */
{
sb_dsp_command(devc, (unsigned char) (count & 0xff));
@@ -222,7 +222,7 @@
}
else
printk(KERN_ERR "Sound Blaster:  unable to start ADC.\n");
-   restore_flags(flags);
+   spin_unlock_irqrestore(>lock, flags);
 
devc->intr_active = 1;
 }
@@ -258,12 +258,11 @@
sb_devc *devc = audio_devs[dev]->devc;
unsigned long flags;
 
-   save_flags(flags);
-   cli();
+   spin_lock_irqsave(>lock, flags);
if (sb_dsp_command(devc, 0x40))
sb_dsp_command(devc, devc->tconst);
sb_dsp_command(devc, DSP_CMD_SPKOFF);
-   restore_flags(flags);
+   spin_unlock_irqrestore(>lock, flags);
 
devc->trigger_bits = 0;
return 0;
@@ -274,12 +273,11 @@
sb_devc *devc = audio_devs[dev]->devc;
unsigned long flags;
 
-   save_flags(flags);
-   cli();
+   spin_lock_irqsave(>lock, flags);
if (sb_dsp_command(devc, 0x40))
sb_dsp_command(devc, devc->tconst);
sb_dsp_command(devc, DSP_CMD_SPKON);
-   restore_flags(flags);
+   spin_unlock_irqrestore(>lock, flags);
devc->trigger_bits = 0;
return 0;
 }
@@ -327,10 +325,9 @@
unsigned long flags;
sb_devc *devc = audio_devs[dev]->devc;
 
-   save_flags(flags);
-   cli();
+   spin_lock_irqsave(>lock, flags);
sb_dsp_reset(devc);
-   restore_flags(flags);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 /*
@@ -353,8 +350,7 @@
 
devc->irq_mode = IMODE_OUTPUT;
 
-   save_flags(flags);
-   cli();
+   spin_lock_irqsave(>lock, flags);
if (sb_dsp_command(devc, 0x48)) /* DSP Block size */
{
sb_dsp_command(devc, (unsigned char) (count & 0xff));
@@ -370,7 +366,7 @@
}
else
printk(KERN_ERR "Sound Blaster: unable to start DAC.\n");
-   restore_flags(flags);

Re: hotmail can't deal with ECN

[Michael B. Trausch]

On Thu, 25 Jan 2001, Steven N. Hirsch wrote:

> On Thu, 25 Jan 2001, David S. Miller wrote:
> 
> Adelphia Communications just blew off my problem complaint (they have a
> router between me and the POP server that DENY's ECN), telling me that
> they "..won't upgrade the router on the basis of one complaint on a Linux
> (read: non-supported by them) system...".
> 

Don't they understand that Linux is actually a system that is growing to
be very popular?

And I would think they would want to support new things with TCP, with a
router and all.  If something is reserved, I would read that to be
reserved, not denied.  Interesting thing - Why would they go out of their
way to deny a few packets if they eventually make use of a few bits?

Eventually, Microsoft will start conforming, I would think, and when that
happens just *watch* everybody follow.

- Mike

===
Michael B. Trausch[EMAIL PROTECTED]
Avid Linux User since April, '96!   AIM:  ML100Smkr

  Contactable via IRC (DALNet) or AIM as ML100Smkr
===

-
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: Kernel 2.4.0 loop device still hangs

[qkholland]

In article <[EMAIL PROTECTED]>,
  Mark Bratcher <[EMAIL PROTECTED]> wrote:
> I saw a post dated last fall 2000 sometime about the
> loop device hanging when copying large amounts of data
> to a file mounted as, say, ext2fs.

I've recently reported a similar problem and told by
Jens Axboe at SUSE that it is still there, and appears
to be generic (not hardware nor kernel configuration
specific) problem.
-
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 sendfile all that sexy?

[Anton Blanchard]

 
> Do you have it at a URL?

The patch is small so I have attached it to this email. It should apply
to the samba CVS tree. Remember this is still a hack and I need to add
code to ensure the file is not truncated and we sendfile() less than we
promised. (After talking to tridge and davem, this should be fixed shortly.)

There is a lot more going on than in the web serving case, so
sendfile+zero copy is not going to help us as much as it did for the tux
guys. For example currently on 2.4.0 + zero copy patches:

anton@drongo:~/dbench$ ~anton/samba/source/bin/smbtorture //otherhost/netbench -U% -N 
15 NBW95

read/write:
Throughput 16.5478 MB/sec (NB=20.6848 MB/sec  165.478 MBit/sec)

sendfile:
Throughput 17.0128 MB/sec (NB=21.266 MB/sec  170.128 MBit/sec)

Of course there is still lots to be done :)

Cheers,
Anton


diff -u -u -r1.195 includes.h
--- source/include/includes.h   2000/12/06 00:05:14 1.195
+++ source/include/includes.h   2001/01/26 05:38:51
@@ -871,7 +871,8 @@
 
 /* default socket options. Dave Miller thinks we should default to TCP_NODELAY
given the socket IO pattern that Samba uses */
-#ifdef TCP_NODELAY
+
+#if 0
 #define DEFAULT_SOCKET_OPTIONS "TCP_NODELAY"
 #else
 #define DEFAULT_SOCKET_OPTIONS ""
diff -u -u -r1.257 reply.c
--- source/smbd/reply.c 2001/01/24 19:34:53 1.257
+++ source/smbd/reply.c 2001/01/26 05:38:53
@@ -2383,6 +2391,51 @@
 END_PROFILE(SMBreadX);
 return(ERROR(ERRDOS,ERRlock));
   }
+
+#if 1
+  /* We can use sendfile if it is not chained */
+  if (CVAL(inbuf,smb_vwv0) == 0xFF) {
+off_t tmpoffset;
+struct stat buf;
+int flags = 0;
+
+nread = smb_maxcnt;
+
+fstat(fsp->fd, );
+if (startpos > buf.st_size)
+  return(UNIXERROR(ERRDOS,ERRnoaccess));
+if (nread > (buf.st_size - startpos))
+   nread = (buf.st_size - startpos);
+
+SSVAL(outbuf,smb_vwv5,nread);
+SSVAL(outbuf,smb_vwv6,smb_offset(data,outbuf));
+SSVAL(smb_buf(outbuf),-2,nread);
+CVAL(outbuf,smb_vwv0) = 0xFF;
+set_message(outbuf,12,nread,False);
+
+#define MSG_MORE 0x8000
+if (nread > 0)
+   flags = MSG_MORE;
+if (send(smbd_server_fd(), outbuf, data - outbuf, flags) == -1)
+  DEBUG(0,("reply_read_and_X: send ERROR!\n"));
+
+tmpoffset = startpos;
+while(nread) {
+   int nwritten;
+   nwritten = sendfile(smbd_server_fd(), fsp->fd, , nread);
+   if (nwritten == -1)
+ DEBUG(0,("reply_read_and_X: sendfile ERROR!\n"));
+
+   if (!nwritten)
+   break;
+
+   nread -= nwritten;
+}
+
+return -1;
+  }
+#endif
+
   nread = read_file(fsp,data,startpos,smb_maxcnt);
   
   if (nread < 0) {
-
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: [UPDATE] Zerocopy patches, against 2.4.1-pre10

[Ion Badulescu]

On Thu, 25 Jan 2001, David S. Miller wrote:

> Ion Badulescu writes:
>  > I'm just wondering, if a card supports sg but *not* TX csum, is it worth
>  > it to make use of sg? eepro100 falls into this category..
>
> No, not worth it for now.  In fact I'm going to mark that combination
> (sg without csum) as illegal in the final zerocopy patch I end up
> sending to Linus.

Well, in the meantime I've ported the starfire driver to the zerocopy
framework, it now takes almost full advantage of the card sg+csum
capabilities. The patch is attached; I'd appreciate it if you could
include it into the main zerocopy patch.

I've tested the new driver using a dual-port starfire, and it survived all
my attempts to kill it with fragmented TCP, UDP and ICMP. More testers
would be welcome, though.

BTW, it looks like not many people are using this driver: the original had
a bug which made it spit out one printk per Tx packet, which was *not*
funny. Also, the module could not be unloaded and reloaded, as it failed
to release some of its resources (Alan already has a fix for that)..

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

--
diff -urNX diff_kernel_excludes /usr/src/local/linux-2.4/drivers/net/starfire.c 
linux-2.4/drivers/net/starfire.c
--- /usr/src/local/linux-2.4/drivers/net/starfire.c Fri Jan 12 12:52:48 2001
+++ linux-2.4/drivers/net/starfire.cThu Jan 25 21:23:18 2001
@@ -34,6 +34,10 @@

LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+   LK1.2.0 (Ion Badulescu <[EMAIL PROTECTED]>)
+   - Support hardware Rx/Tx checksumming
+   - Add GFP firmware taken from Adaptec's Netware driver
 */

 /* These identify the driver base version and may not be removed. */
@@ -43,7 +47,7 @@
 " Updates and info at http://www.scyld.com/network/starfire.html\n";

 static const char version3[] =
-" (unofficial 2.4.x kernel port, version 1.1.4, August 10, 2000)\n";
+" (unofficial 2.4.x kernel port, version 1.2.0, January 25, 2001)\n";

 /* The user-configurable values.
These may be modified when a driver module is loaded.*/
@@ -117,6 +121,8 @@
 #include 
 #include 

+#include "starfire_firmware.h"
+
 MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("Adaptec Starfire Ethernet driver");
 MODULE_PARM(max_interrupt_work, "i");
@@ -256,10 +262,10 @@
TxThreshold=0x500B0,
CompletionHiAddr=0x500B4, TxCompletionAddr=0x500B8,
RxCompletionAddr=0x500BC, RxCompletionQ2Addr=0x500C0,
-   CompletionQConsumerIdx=0x500C4,
+   CompletionQConsumerIdx=0x500C4, RxDMACtrl=0x500D0,
RxDescQCtrl=0x500D4, RxDescQHiAddr=0x500DC, RxDescQAddr=0x500E0,
RxDescQIdx=0x500E8, RxDMAStatus=0x500F0, RxFilterMode=0x500F4,
-   TxMode=0x55000,
+   TxMode=0x55000, TxGfpMem=0x58000, RxGfpMem=0x5a000,
 };

 /* Bits in the interrupt status/mask registers. */
@@ -288,8 +294,12 @@
 /* Completion queue entry.
You must update the page allocation, init_ring and the shift count in rx()
if using a larger format. */
+#define csum_rx_status
 struct rx_done_desc {
u32 status; /* Low 16 bits is length. */
+#ifdef csum_rx_status
+   u32 status2;/* Low 16 bits is csum */
+#endif
 #ifdef full_rx_status
u32 status2;
u16 vlanid;
@@ -307,8 +317,9 @@
u32 addr;
 };
 enum tx_desc_bits {
-   TxDescID=0xB101,/* Also marks single fragment, add CRC.  */
-   TxDescIntr=0x0800, TxRingWrap=0x0400,
+   TxDescID=0xB000,
+   TxCRCEn=0x0100, TxDescIntr=0x0800,
+   TxRingWrap=0x0400, TxCalTCP=0x0200,
 };
 struct tx_done_report {
u32 status; /* timestamp, index. */
@@ -318,9 +329,14 @@
 };

 #define PRIV_ALIGN 15  /* Required alignment mask */
-struct ring_info {
+struct rx_ring_info {
+   struct sk_buff *skb;
+   dma_addr_t mapping;
+};
+struct tx_ring_info {
struct sk_buff *skb;
dma_addr_t mapping;
+   int len;
 };

 struct netdev_private {
@@ -330,8 +346,8 @@
dma_addr_t rx_ring_dma;
dma_addr_t tx_ring_dma;
/* The addresses of rx/tx-in-place skbuffs. */
-   struct ring_info rx_info[RX_RING_SIZE];
-   struct ring_info tx_info[TX_RING_SIZE];
+   struct rx_ring_info rx_info[RX_RING_SIZE];
+   struct tx_ring_info tx_info[TX_RING_SIZE];
/* Pointers to completion queues (full pages).  I should cache line pad..*/
u8 pad0[100];
struct rx_done_desc *rx_done_q;
@@ -435,6 +451,9 @@
printk(KERN_INFO "%s: %s at 0x%lx, ",
   dev->name, netdrv_tbl[chip_idx].name, ioaddr);

+   /* Starfire can do SG and TCP/UDP checksumming */
+   dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM;
+
/* Serial EEPROM reads are hidden by the hardware. 

Re: hotmail not dealing with ECN

[Jeremy M. Dolan]

On Thu, 25 Jan 2001 18:10:21 +, David S. Miller wrote:
> It says "reserved for future use, must be zero".

While I've not checked the context yet, this seems to be terrible
wording. The context doesn't direct this towards hosts constructing
packets? What is the 'It' you refer to, the TCP RFC? Do any of the
following override this awful wording job?

RFC1122 / STD0003Requirements for Internet hosts (comm. layers)
RFC1123 / STD0003Requirements for Internet hosts (apps)
RFC1009 / STD0004Requirements for Internet gateways 
RFC1812  Requirements for IP Version 4 Routers 
RFC2979  Behavior of and Requirements for Internet Firewalls 

The last one seems it would have the most potential to clear up this
mess, unfortunatly it's only an informational RFC, and at a quick
glance, doesn't look like it addresses this issue. Regardless, the
intent of the author was clear... it'd just be nice to be able to
quote chapter and verse.

Besides, I'm MUCH more worried about all of .uk being behind an ECN
eating router then not being about to talk to some Microsoft webmail
service.

I fear this problem is doomed to repeat itself as well, as more of
IP's features become unreserved (Class E IP Address, anyone?)

/jmd

-- 
Jeremy M. Dolan <[EMAIL PROTECTED]>
OpenPGP key = http://turbogeek.org/openpgp-key
OpenPGP fingerprint = 494C 7A6E 19FB 026A 1F52  E0D5 5C5D 6228 DC43 3DEE
-
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 ppp_async.c

[Albert D. Cahalan]

Paul Mackerras writes:
> Albert D. Cahalan writes:

>> Even Red Hat 7 only has the 2.3.11 version.
>>
>> The 2.4.xx series is supposed to be stable. If there is
>> any way you could add a compatibility hack, please do so.
>
> Stable != backwards compatible to the year dot.

I know. It means that you don't break the API between 2.4.0
and 2.4.1 though. It means you don't break distributions that
were supposed to be ready for the 2.4.xx kernels.

> ppp-2.4.0 has been
> out for over 5 months now.

That is less than the typical time between releases of
a normal Linux distribution.

> Adding the compatibility stuff back in
> would make the PPP subsystem much more complicated and less robust.

I wouldn't be asking you to add it back if you hadn't
removed it. It was already there.

I don't trust that the new version will be a drop-in replacement
due to past experiences, and I wonder if my 2.0.xx kernel will
still be supported by the new user-space code. So this sucks.

> And pppd is not the only thing you would have to upgrade if you are
> using a 2.4.0 with Red Hat 7.0 - I would expect that you would also at
> least have to upgrade modutils, and switch over from ipchains to
> iptables if you use the netfilter stuff.

Nope, the network people even offer some Linux 2.0 compatibility.
That dates back many years! Hey, I like your example.

For modutils, there was a security problem anyway.
-
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/

mapping physical memory

[Dima Brodsky]

Hi,

I need to be able to obtain and pin approximately 8 MB of contiguous 
physical memory in user space.  How would I go about doing that under
Linux if it is at all possible?

Thanks
ttyl
Dima

-- 
Dima Brodsky   [EMAIL PROTECTED]
   http://www.cs.ubc.ca/~dima
201-2366 Main Mall (604) 822-6179 (Office)
Department of Computer Science (604) 822-2895 (DSG Lab)
University of British Columbia, Canada (604) 822-5485 (FAX)

Computers are like Old Testament gods; lots of rules and no mercy.
  (Joseph Campbell)
-
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/

Kernel 2.4.0 loop device still hangs

[Mark Bratcher]

Hello,

I saw a post dated last fall 2000 sometime about the loop device hanging
when copying large amounts of data to a file mounted as, say, ext2fs. It
was in regard to kernel 2.4.0test-something.

I have the latest 2.4.0 kernel loaded on my system and this bug appears
to be there, although I have seen other notes that claim that it is
fixed.

Can anyone confirm whether this bug is "officially" known to be in the
official 2.4.0 kernel? Currently I have to reboot to 2.2.17 to do my
CD-RW backups.

Thanks.
-- 
Mark Bratcher
mailto:[EMAIL PROTECTED]
-
Escape from Microsoft's proprietary tentacles: use Linux!
-
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: ECN and other sites

[David Ford]

"Michael B. Trausch" wrote:

> I've kinda been watching the ECN discussion there, and I have 2.4.0 and
> noticed that after I'd installed it, I couldn't get to my favorite search
> engine (Dogpile.com).  I'd assume they don't support it either, because
> when I "echo 0 > /proc/sys/net/ipv4/tcp_ecn" then it goes away.  I
> notified them about the problem and pointed them to a few webpages with
> information and links regarding ECN.
>
> Is there a kernel config option somewhere to disable that, or do I just
> need to make sure to put that echo line in my /etc/rc.d/rc.local?

Yes, you enabled it in the networking options.  CONFIG_INET_ECN.

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



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

ECN and other sites

[Michael B. Trausch]

I've kinda been watching the ECN discussion there, and I have 2.4.0 and
noticed that after I'd installed it, I couldn't get to my favorite search
engine (Dogpile.com).  I'd assume they don't support it either, because
when I "echo 0 > /proc/sys/net/ipv4/tcp_ecn" then it goes away.  I
notified them about the problem and pointed them to a few webpages with
information and links regarding ECN.

Is there a kernel config option somewhere to disable that, or do I just
need to make sure to put that echo line in my /etc/rc.d/rc.local?

- Mike

===
Michael B. Trausch[EMAIL PROTECTED]
Avid Linux User since April, '96!   AIM:  ML100Smkr

  Contactable via IRC (DALNet) or AIM as ML100Smkr
===

-
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: hotmail not dealing with ECN

[Brian May]

> "David" == David S Miller <[EMAIL PROTECTED]> writes:

David> It says "reserved for future use, must be zero".

Poor choice of wording.

If I was implementing this, I would assume that any packet with a
non-zero value is illegal by this RFC, and act accordingly.

I would assume that this "future use" may require handling of the
packet in a non-standard way, and packets with a non-zero value cannot
be used until the "future use" is better defined.

Also, the above statement should really clarify how routers should
cope if they receive a non-zero value. Drop it, pass it through
unchanged, or set it to zero?
-- 
Brian May <[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: hotmail can't deal with ECN

[Steven N. Hirsch]

On Thu, 25 Jan 2001, David S. Miller wrote:

> "test"?  I know exactly whats going to happen, and unless folks like
> hotmail.com and others get their act together I'll certainly end up
> removing *@*hotmail.com from the lists by the end of that day.
> 
> That is the whole point of this experiment.
> 
> Alan plans on doing similar things to ftp.linux.org.uk and other
> machines he maintains.
> 
> The behavior of these sites is simply intolerable, and I think
> this is a wonderful way to get our point across.  I cannot see it
> being argued that these entities have not been given enough notice
> of the problem.  If they cannot be bothered to get fixed an issue like
> this after nearly half a year, I cannot be bothered to feel bad for
> them when all users at their site lose access to the lists.

Adelphia Communications just blew off my problem complaint (they have a
router between me and the POP server that DENY's ECN), telling me that
they "..won't upgrade the router on the basis of one complaint on a Linux
(read: non-supported by them) system...".




-
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: named streams, extended attributes, and posix

[Steven N. Hirsch]

On Thu, 25 Jan 2001, Leif Sawyer wrote:

> [EMAIL PROTECTED] [[EMAIL PROTECTED]] wrote:
> > Here's an idea: streams/etc are reached by appending 
> > "/.../xxx" or some such to paths, thus:
> >   for streamname on /dir/file, we have "/dir/file/.../streamname" 
> >  for a directory /dir/dir, we get /dir/dir/.../streamname" 
> >-- "..." is a special subdirectory of any directories which have 
> 
> An interesting point to note here would be that
> the directory '...'  has been used for many years to 'hide' things
> from un-skilled sysadmins.
> 
> In other words, warez ftp sites pop up all over the place, and this
> directory name is pretty close to being the number one stash point,
> right next to ".. "

It's also the implicit root for the global DFS filesystem namespace (from
Transarc of AFS fame).





-
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.1-pre8 losing pages

[Xuan Baldauf]

Peter Horton wrote:

> I'm experiencing repeatable corruption whilst writing large volumes of
> data to disk. Kernel version is 2.4.1-pre8, on an 850MHz AMD Athlon on an
> ASUS A7V (VIA KT133 chipset) motherboard 128M RAM (tested with 'memtest86'
> for 10 hours).
>
> First, I realised that the fsck was noticing small corruptions on my ext2
> volume. My first suspect was the much discussed VIA IDE controller. As a
> test I created a 128M file from "urandom" and copied it to twenty six
> files. When I MD5 the files one or two of them are usually corrupt. The
> damage usually occurs in the 24th copy (thought not always). Inspecting
> the files shows a single 4K block (aligned on a 4K boundary) that is
> completely different from what it should be. The kernel logs no errors
> whilst writing the corrupt files.
>
> I've repeated the test on the other on-board IDE controller (Promise), a
> different hard disk, and on reiserfs. I see the corruption in all cases.
>
> I tried building the kernel for "Pentium-Classic", and I tried a few older
> kernels (2.4.0-test5 and 2.4.0-test12), still bad (all kernels built with
> GCC 2.95.2 - Debian potato).
>
> I really could do with some help as where to look next :-). I did try and
> come up with a test to see whether bad data is written or whether the
> damaged piece is just not written, but if I alter the testing procedure
> too much the problem seems to go away. It seems to just lose a single page
> under one very specific circumstance.

So what output does following bash script produce?

#!/bin/bash
uname -a
dd if=/dev/urandom of=test0 bs=1024k count=128
I=1
while test $I -lt 32; do
  echo $I
  cp test0 test$I
  I="$(($I+1))"
done
md5sum test*

I cannot reproduce your behaviour in 2.4.1-pre9.

Xuân.

>
>
> P.
>
> ( configs attached )
>
>   
>   Name: info.tar.gz
>info.tar.gzType: Unix Tape Archive (application/x-tar)
>   Encoding: base64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: hotmail not dealing with ECN

[Johannes Erdfelt]

On Thu, Jan 25, 2001, David S. Miller <[EMAIL PROTECTED]> wrote:
> 
> H. Peter Anvin writes:
>  > > RFC793, where is lists the unused flag bits as "reserved".
>  > > That is pretty clear to me.  It just has to say that
>  > > they are reserved, and that is what it does.
>  > > 
>  > 
>  > Is the definition of "reserved" defined anywhere?  In a lot of specs,
>  > "reserved" means MBZ.
>  > 
>  > Note, that I'm not arguing with you.  I'm trying to pick this apart.
> 
> It says "reserved for future use, must be zero".
> 
> I think the descrepency (and thus what the firewalls are doing) comes
> from the ambiguous "must be zero".  I cannot fathom the RFC authors
> meaning this to be anything other than "must be set to zero by current
> implementations" or else what is the purpose of the "reserved for
> future use part" right?
> 
> Honestly, is there anyone here who can tell me honestly that when they
> see the words "reserved" in the description of a bit field description
> (in a hardware programmers manual of some device, for example) that
> they think it's ok the read the value and interpret it in any way?
> 
> To me it's always meant "we want to do cool things in the future,
> things we haven't thought of now, so don't interpret these bits so we
> can do that and you will still work".

Generally it's to ensure that all implementations set those bit by
default to 0 as well.

Then in the future, 0 means "I don't support this feature either by
choice or by not implementing it yet".

JE

-
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: hotmail not dealing with ECN

[H. Peter Anvin]

"David S. Miller" wrote:
> 
> It says "reserved for future use, must be zero".
> 
> I think the descrepency (and thus what the firewalls are doing) comes
> from the ambiguous "must be zero".  I cannot fathom the RFC authors
> meaning this to be anything other than "must be set to zero by current
> implementations" or else what is the purpose of the "reserved for
> future use part" right?
> 
> Honestly, is there anyone here who can tell me honestly that when they
> see the words "reserved" in the description of a bit field description
> (in a hardware programmers manual of some device, for example) that
> they think it's ok the read the value and interpret it in any way?
> 
> To me it's always meant "we want to do cool things in the future,
> things we haven't thought of now, so don't interpret these bits so we
> can do that and you will still work".
> 

Think of yourself as a firewall author now.  You come across this, and
go, "these bits aren't used now; this means noone should be setting
them.  I have no guarantee that anything in the future isn't going to use
these bits for something that isn't going to override the security of my
system."

MBZ to me indicate that it is legitimate for the recipient to drop them
as invalid if they are not.  This is probably unfortunate; they really
need specific definition about what the sender should do (set the bits to
zero) and the recipient should do (ignore the bits.)

Unfortunately, it's hard to be "liberal in what you accept" when you're
trying to enforce a security policy.

-hpa

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

2.4 extreme slowdown and crash

[Vibol Hou]

Hi,

I've been testing 2.4 on one of my webservers and it seems to exhibit an
extreme case of slowdowns every 2-3 days.  It slows down to the point where
I can't really type anything into the telnet screen (remotely admin'd).
However, when I was able to get a few commands to the system (w, memstat,
ps, free), it showed absolutely nothing out of the ordinary.  The system
runs like a breeze and then just _slows_ to a complete crawl.  Needless to
say, all the services also slowed down.  It's the second time it happened
since I started testing this new kernel.

A little background on the server:  It's a webserver that runs Apache and
MySQL.  It has ~896MB RAM, and runs with an Adaptec 2940U2W SCSI card and
several SCSI drives.  The system experiences a load average of about 1-2
throughout the day with the new kernel.  It used to experience load averages
of 8-14 with 2.2.17.  I don't make very much use of shared memory, and from
what I can tell, the system never swaps to swap space.  Below are the last
stats I was able to retrieve before power-cycling the system (nothing else I
could do to fix it.  It was unresponsive to a shutdown -r now).

uptime:

  4:53pm  up 2 days, 15 min,  4 users,  load average: 2.57, 1.87, 2.26


free:

 total   used   free sharedbuffers cached
Mem:899712 896924   2788  0  24476 331660
-/+ buffers/cache: 540788 358924
Swap:  1052248  01052248


Peering through the aftermath, syslog contains this:

Jan 25 02:59:54 omega kernel: reset_xmit_timer sk=f00c9680 1 when=0x3744,
caller
=c0218172
Jan 25 02:59:58 omega kernel: reset_xmit_timer sk=f00c9680 1 when=0x3087,
caller
...skipping...
Jan 25 16:53:27 omega named[182]: ns_req: sendto([141.133.112.25].53):
Resource
temporarily unavailable

[... manually shortened ... ]

Jan 25 16:53:27 omega named[182]: ns_req: sendto([65.24.0.167].46484):
Resource
temporarily unavailable
Jan 25 16:53:27 omega named[182]: ns_req: sendto([198.77.116.8].37441):
Resource
 temporarily unavailable
Jan 25 16:53:27 omega named[182]: ns_req: sendto([64.59.128.213].2102):
Resource
 temporarily unavailable
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@

[... manually shortened ... ]

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@
^@^@^@^@^@^@^@^@Jan 25 18:01:02 omega syslogd 1.3-3#33.1: restart.
Jan 25 18:01:02 omega kernel: klogd 1.3-3#33.1, log source = /proc/kmsg
started.
Jan 25 18:01:02 omega kernel: Inspecting /boot/System.map-2.4.0
Jan 25 18:01:03 omega kernel: Loaded 15215 symbols from
/boot/System.map-2.4.0.
Jan 25 18:01:03 omega kernel: Symbols match kernel version 2.4.0.
Jan 25 18:01:03 omega kernel: No module symbols loaded.
Jan 25 18:01:03 omega kernel: Linux version 2.4.0 (root@omega) (gcc version
2.95
.2 2220 (Debian GNU/Linux)) #1 SMP Fri Jan 19 23:03:21 PST 2001

Does anyone have any ideas as to what is causing this?  I will likely be
taking 2.4 out of testing and replacing it with good old 2.2.17 if I can't
resolve this problem.

--
Vibol Hou
KhmerConnection, http://khmer.cc
"Connecting Cambodian Minds, Art, and Culture"

-
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: hotmail not dealing with ECN

[David S. Miller]

H. Peter Anvin writes:
 > > RFC793, where is lists the unused flag bits as "reserved".
 > > That is pretty clear to me.  It just has to say that
 > > they are reserved, and that is what it does.
 > > 
 > 
 > Is the definition of "reserved" defined anywhere?  In a lot of specs,
 > "reserved" means MBZ.
 > 
 > Note, that I'm not arguing with you.  I'm trying to pick this apart.

It says "reserved for future use, must be zero".

I think the descrepency (and thus what the firewalls are doing) comes
from the ambiguous "must be zero".  I cannot fathom the RFC authors
meaning this to be anything other than "must be set to zero by current
implementations" or else what is the purpose of the "reserved for
future use part" right?

Honestly, is there anyone here who can tell me honestly that when they
see the words "reserved" in the description of a bit field description
(in a hardware programmers manual of some device, for example) that
they think it's ok the read the value and interpret it in any way?

To me it's always meant "we want to do cool things in the future,
things we haven't thought of now, so don't interpret these bits so we
can do that and you will still work".

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: hotmail not dealing with ECN

[H. Peter Anvin]

"David S. Miller" wrote:
> 
> H. Peter Anvin writes:
>  > Last I communicated with them, I looked for a reference like that in the
>  > standards RFCs so I could quote chapter and verse at the Hotmail people,
>  > but I couldn't find it.
> 
> RFC793, where is lists the unused flag bits as "reserved".
> That is pretty clear to me.  It just has to say that
> they are reserved, and that is what it does.
> 

Is the definition of "reserved" defined anywhere?  In a lot of specs,
"reserved" means MBZ.

Note, that I'm not arguing with you.  I'm trying to pick this apart.

-hpa

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

Re: hotmail not dealing with ECN

[David S. Miller]

H. Peter Anvin writes:
 > Last I communicated with them, I looked for a reference like that in the
 > standards RFCs so I could quote chapter and verse at the Hotmail people,
 > but I couldn't find it.

RFC793, where is lists the unused flag bits as "reserved".
That is pretty clear to me.  It just has to say that
they are reserved, and that is what it does.

 > Right, but there is a whole mythos around which version of IOS does what
 > without breaking something.  I can certainly understand that people are
 > reluctant to upgrade if they don't have to.

As far as I understand it, the PIIX stuff doesn't run IOS but rather
some other system created for these firewall products.

Moot point.  I understand that upgrading can be a pain, but I think
it is in their best interest to do so (see better internet and "make
money" arguments).

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/

SERVERWORKS (READ ME) please....

[Andre Hedrick]

LMKL,

I have a meeting in the morning with their CTO.
I want a core dump of every issue that needs to be address in Linux to put
in his hand.

Cheers,

Andre Hedrick
Linux ATA Development

-
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: hotmail not dealing with ECN

[H. Peter Anvin]

"David S. Miller" wrote:
> 
> Secondly, the RFCs are pretty clear that the bits in question used for
> ECN are _reserved_ and to be ignored by implementations.  That means
> to not be interpreted, and more importantly not used to discard
> packets.
> 

Last I communicated with them, I looked for a reference like that in the
standards RFCs so I could quote chapter and verse at the Hotmail people,
but I couldn't find it.  If there is such a reference, someone should
point it out to them, as well as the Cisco patch you point out.  As I
said before, I have had good experience with getting them to fix things
if someone actually points the exact violation they're committing.

>  > In this case, though, they feel that they don't want to potentially
>  > destabilize their network over something that is labelled an
>  > experimental standard.  I can certainly understand their point.
> 
> That's respectible.
> 
> However, to my knowledge the fix in question is available from Cisco
> as a fully supported "safe" patch, rather than some haphazard beta
> patch.

Right, but there is a whole mythos around which version of IOS does what
without breaking something.  I can certainly understand that people are
reluctant to upgrade if they don't have to.

-hpa

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

Re: hotmail not dealing with ECN

[David S. Miller]

H. Peter Anvin writes:
 > I do think they have a point, though; ECN is listed as an
 > experimental standard at IETF, and I do think that it's not exactly
 > fair to *require* everyone to use it until it is standards-track.
 > It would be another thing if Linux could turn it off on a
 > per-connection basis if these packets get dropped.

Firstly, how do these things make standards status if everybody
twiddles their fingers and ignores the issues at the high volume sites
so the thing can't be effectively beta tested by researchers?

Secondly, the RFCs are pretty clear that the bits in question used for
ECN are _reserved_ and to be ignored by implementations.  That means
to not be interpreted, and more importantly not used to discard
packets.

It is specifically described in this way so that things like ECN _can_
be deployed without worrying about existing implementations being
confused.

These sites ignoring this issue, and the fix existing from the vendors
of products with the problem, are only exacerbating the situation.  A
better internet will take longer because they are doing this.  This
better internet with full blown ECN is in their best interest, it will
allow them to serve more connections, more customers, and make more
money.

Thirdly, it was widely discussed by the ECN reserachers on how to
"detect ECN blackholes" sort to speak.  All such schemes suggested
we unusable, it is not doable without impacting performance _and_
violating existing RFCs.  Basically, you have to ignore a valid TCP
reset to deal with some of the ECN holes out there, that is where such
workaround attempts become full crap and are unsatisfactory for
inclusion in any implementation much less an RFC.  Happily, we got the
ECN folks to agree with Alexey and myself on these points.

So turning it off on a per-connection basis is not really an option.

 > In this case, though, they feel that they don't want to potentially
 > destabilize their network over something that is labelled an
 > experimental standard.  I can certainly understand their point.

That's respectible.

However, to my knowledge the fix in question is available from Cisco
as a fully supported "safe" patch, rather than some haphazard beta
patch.

I think it's just a "fud to avoid a small burdon issue" on the hotmail
folks part.  Well, if this is the case they can just let me know how
many support mails at which the burdon of verifying installation of
the fix from Cisco will not see so bad in comparison :-)

Finally, regardless of whether ECN is a standard or not, making
any interpretation of the reserved bits is at best a violation
of the "be liberal of what you receive" mantra of the internet
standards committee which the hotmail person quoted seemed so
keen on mentioning :-)

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: 2.2.19pre6/7: why can't I dump core?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I've done a quick inspection of pre7 patch set and noticed about the
> same thing.  Is this an oversight, did someone intentionally turn off
> core dumping until some other widget is incorporated into the patches,
> or none of the above (a conspiracy, maybe? 8-).

what is ulimit -c telling you?

Greetings
Bernd
-
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: [UPDATE] Zerocopy patches, against 2.4.1-pre10

[Andrew Morton]

[EMAIL PROTECTED] wrote:
> 
> Hello!
> 
> > no problems.  I simply mounted an NFS server with rsize=wsize=8192
> > and read a few files - I assume this is sufficient?
> 
> This is orthogonal.
> 
> Only TCP uses this and you need not to do something special
> to test it. Any TCP connection going through 3c tests it.

OK.

> > rather than using the IS_CYCLONE stuff.  Then we can add cards
> > individually as confirmation comes in.
> 
> Seems, you meaned opposite way. To add this flag to all the chips,
> except for several, and to remove it as soon as it is "confirmed"
> that it does not work. 8)

errr..  Well that certainly ensures we'll hear about it quickly :)

Problem is, some of these NICs are very rare, and the driver could
be broken for quite some time before we hear about it.  Months.

I think what I'd prefer to do is this:

In vortex_close() we _know_ whether the NIC is doing hardware checksumming,
so we can add:

if (rx_csumhits && (dev->drv_flags_HWCKSM) == 0)
printk("this NIC supports hardware checksums!  Please see ")

This will work well - people are quite helpful.

> Also, please, reset the state. Until this snapshot, hw checksumming
> did not work due to bugs in netfilter, so that all the reports about
> failures to checksum are dubious.

That's good to hear.

It's possible that some devices in the device table are marked
as Cyclone when in fact they're Boomerangs.  It's pretty confusing.
So these will support scatter/gather but not checksumming.

Using rx_csumhits should be reliable.  It's a global counter at
present - I'll make it per-device.

-
-
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: hotmail not dealing with ECN

[Lincoln Dale]

Hi,

At 01:06 AM 25/01/2001 -0800, David S. Miller wrote:
>Juri Haberland writes:
>  > Forget it. I mailed them and this is the answer:
>  >
>  > "As ECN is not a widely used internet standard, and as Cisco does not
>  > have a stable OS for their routers that accepts ECN, anyone attempting
>  > to access our site through a gateway or from a computer that uses ECN
>  > will be unable to do so."
>
>The interesting bit is the "Cisco does not have a stable OS..." part.

Cisco _routers_ don't care whether packets have ECN set or not.

>I've been told repeatedly by the Cisco folks that a stable supported
>patch is available from them for their firewall products which were
>rejecting ECN packets.

nothing has changed since before --
both the cisco PIX and cisco LocalDirector didn't used to function 
correctly with ECN bits set.

both were fixed less than a week after a bug was opened and both have 
updates available for download ...
that was many many months ago ..

i wonder if some folk are being too quick to point the finger at just one 
vendor.  did some versions of solaris have problems with ECN too?

>I'd really like Cisco to reaffirm this and furthermore, and
>furthermore get in contact with and correct the hotmail folks
>if necessary.

if Juri can forward me (privately) the details of the hotmail person that 
said the above, i'd be happy to ensure that it is resolved ..

>I have in fact noticed that some sites that did have the problem have
>installed the fix and are now accessible with ECN enabled.

good to hear.


cheers,

lincoln.
NB. some cisco routers may start adding the ability to set ECN to indicate 
congestion 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: hotmail can't deal with ECN

[CaT]

On Thu, Jan 25, 2001 at 05:04:23PM -0800, David S. Miller wrote:
> 
> CaT writes:
>  > gozer:~# more /proc/sys/net/ipv4/tcp_ecn 
>  > 1
>  > 
>  > and I can contact hotmail just fine.
>  ...
>  > where should I go to on hotmail to see it fail?
> 
> Try telnetting to port 25 on one of their
> "*.hotmail.com" MX records.

Boom. Bingo:

gozer:~# telnet mc6.law5.hotmail.com 25
Trying 216.33.238.136...
telnet: Unable to connect to remote host: Connection refused

Big baddaboom :)

And it answers my question of wether or not it does ECN for non-ECN
boxes behind the firewall:

[11:29:31] root@theirongiant:/root>> telnet mc6.law5.hotmail.com 25
Trying 216.33.238.136...
Connected to mc6.law5.hotmail.com.
Escape character is '^]'.
220-HotMail (NO UCE) ESMTP server ready at Thu Jan 25 17:06:07 2001 
220 ESMTP spoken here
554 Transaction failed
Connection closed by foreign host.
[12:06:37] root@theirongiant:/root>> uname -a
Linux theirongiant 2.2.19pre7 #3 Tue Jan 16 18:07:56 EST 2001 i686 unknown

Thanks for that. :) I'll be leaving ECN turned on on the box regardless
I think.

-- 
CaT ([EMAIL PROTECTED])*** Jenna has joined the channel.
 speaking of mental giants..
 me, a giant, bullshit
 And i'm not mental
- An IRC session, 20/12/2000

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

Re: hotmail can't deal with ECN

[David S. Miller]

CaT writes:
 > gozer:~# more /proc/sys/net/ipv4/tcp_ecn 
 > 1
 > 
 > and I can contact hotmail just fine.
 ...
 > where should I go to on hotmail to see it fail?

Try telnetting to port 25 on one of their
"*.hotmail.com" MX records.

For example:
? host -a hostmail.com
...
hostmail.com651 IN  MX  10 mc6.law5.hotmail.com
...
mc6.law5.hotmail.com383 IN  A   216.33.238.136
? telnet 216.33.238.136 25
Trying 216.33.238.136...
telnet: Unable to connect to remote host: Connection refused
?

Some of the MX records that show up for hotmail.com go
to different machines, such as INKY.SOLINUS.COM which seems
to let ECN connections through just fine.

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: hotmail can't deal with ECN

[CaT]

On Fri, Jan 26, 2001 at 01:59:01AM +0100, Jan Niehusmann wrote:
> On Fri, Jan 26, 2001 at 11:50:57AM +1100, CaT wrote:
> > gozer:~# more /proc/sys/net/ipv4/tcp_ecn 
> > 1
> > 
> > and I can contact hotmail just fine. I also can ftp to your site
> > non-passively. where should I go to on hotmail to see it fail?
> 
> You may be located behind a firewall that zeroes out the ECN bits. This would
> mean that hotmail doesn't get ECN packets and the connection gets established
> just as if you were talking to a plain non-ECN server without a firewall.

gozer IS my firewall. :) beyond it is a modem and a dailup point, my ISPs
LAN and then the innanet. and I tried from it and from a box behind it.
I connected to hotmail just fine.

still, any way to test if the ECN bits are going through just fine?

-- 
CaT ([EMAIL PROTECTED])*** Jenna has joined the channel.
 speaking of mental giants..
 me, a giant, bullshit
 And i'm not mental
- An IRC session, 20/12/2000

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

Re: hotmail can't deal with ECN

[Jan Niehusmann]

On Fri, Jan 26, 2001 at 11:50:57AM +1100, CaT wrote:
> I'm not sure as to what the problem with hotmail may be. I have ECN
> turned on:
> 
> gozer:~# more /proc/sys/net/ipv4/tcp_ecn 
> 1
> 
> and I can contact hotmail just fine. I also can ftp to your site
> non-passively. where should I go to on hotmail to see it fail?

You may be located behind a firewall that zeroes out the ECN bits. This would
mean that hotmail doesn't get ECN packets and the connection gets established
just as if you were talking to a plain non-ECN server without a firewall.

Jan

-
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: hotmail can't deal with ECN

[CaT]

On Thu, Jan 25, 2001 at 04:37:37PM -0800, David S. Miller wrote:
> 
> James H. Cloos Jr. writes:
>  > Are there any well know sites using ECN we can test against?
> 
> Use non-passive FTP to my workstation and just do a directory listing
> which will make the FTP server create a TCP connection back to your
> machine for the transfer of the directory listing.
> 
> My workstation is pizda.ninka.net, please everyone be nice.

*screatches head*

I'm not sure as to what the problem with hotmail may be. I have ECN
turned on:

gozer:~# more /proc/sys/net/ipv4/tcp_ecn 
1

and I can contact hotmail just fine. I also can ftp to your site
non-passively. where should I go to on hotmail to see it fail?

-- 
CaT ([EMAIL PROTECTED])*** Jenna has joined the channel.
 speaking of mental giants..
 me, a giant, bullshit
 And i'm not mental
- An IRC session, 20/12/2000

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

Re: eepro100 problems in 2.4.0

[Andrey Savochkin]

Hi,

On Thu, Jan 25, 2001 at 04:19:27PM -0500, Jeff Garzik wrote:
> Oops, sorry guys.  Thanks to DaveM for correcting me -- my patch has
> nothing to do with the "card reports no resources" problem.  My
> apologies.

No problems.

However, there is a real problem with eepro100 when the system resumes
operations after a sleep.
May be, you could guess what's wrong in this case?

Best regards
Andrey


Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 5459 invoked by uid 577); 18 Jan 2001 01:39:41 -
Received: (qmail 5453 invoked from network); 18 Jan 2001 01:39:38 -
Received: from sea-pm3-10-p213.wolfenet.com (HELO mail.robhome.dyndns.org) 
(206.159.18.213)
  by saw.sw.com.sg with SMTP; 18 Jan 2001 01:39:38 -
Received: from tara.robhome.dyndns.org (tara.mvdomain [10.1.1.66])
by mail.robhome.dyndns.org (Postfix) with ESMTP id 16645BBE9
for <[EMAIL PROTECTED]>; Wed, 17 Jan 2001 17:39:18 -0800 (PST)
Received: by tara.robhome.dyndns.org (Postfix, from userid 1000)
id 5D43A17183E; Wed, 17 Jan 2001 17:39:10 -0800 (PST)
Date: Wed, 17 Jan 2001 17:39:08 -0800
From: Scott Robinson <[EMAIL PROTECTED]>
To: Andrey Savochkin <[EMAIL PROTECTED]>
Subject: Re: EEPRO100 Power Management problem?
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H"
User-Agent: Mutt/1.0.1i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Tue, Jan 
16, 2001 at 05:19:16PM +0800
X-Disclaimer: The contents of this e-mail, unless otherwise stated, are the property 
of David Ryland Scott Robinson. Copyright (C)2001, All Rights Reserved.
X-Operating-System: Linux tara 2.4.0-test10 
Sender: [EMAIL PROTECTED]


--4SFOXa2GPu3tIq4H
Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP"


--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Well, it appears *something* like that is happening. However, I can't think
of how to fix it. Everything goes "disabled".

Attached are the two 'lspci -v' executed pre and post-suspend. Also attached
is a diff file between them. If you have any further ideas, please e-mail me
back?

Scott.

* Andrey Savochkin translated into ASCII [Tue, Jan 16, 2001 at 05:19:16PM +=
0800][<[EMAIL PROTECTED]>]
> Hello,
>=20
> On Fri, Jan 05, 2001 at 03:18:23PM -0800, Scott Robinson wrote:
> > The following occurs when I suspend my Dell Inspiron 8000 with an inter=
nal
> > MiniPCI Actiontec MP100IM. I'm using 2.4.0-final with power-management
> > turned on and off. The logs below are with power-management turned on.
> >=20
> > I checked with a eepro100 diagnostic tool, and according to it, the ent=
ire
> > EEPROM has been FF'ed out. (and it's larger than before)
> >=20
> > I have tried unloading the driver before suspend. No dice. Is there a
> > hard-reset command for a card?
> >=20
> > I was looking at the source code and maybe if I suspend the pci card in
> > _suspend()? I'm not certain what power state I need to tell it, though.=
 D3?
> >=20
> > When I power-cycle the machine, I end up having to hard-reset otherwise=
 I
> > freeze in the bios startup. Something seriously harsh is happening.
>=20
> The first idea that comes to mind is an old issue of cleared PCI
> configuration on sleep.
> Run `lspci -v' after wakeup and compare how the output look with how it d=
id
> before the sleep.
>=20
> Best regards
>   Andrey V.
>   Savochkin
>=20

--=20
jabber:[EMAIL PROTECTED] - Universal ID (www.jabber.org)
http://dsn.itgo.com/   - Personal webpage
robhome.dyndns.org - Home firewall

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GAT dpu s+: a--- C++ UL P+ L+++ E- W+ N+ o+ K++ w++
O M V PS+ PE Y+ PGP++ t++ 5++ X+ R tv b DI D++
G+ e+ h! r-- y-
--END GEEK CODE BLOCK--

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="lspci.presuspend"

00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 02)
Flags: bus master, fast devsel, latency 0
Memory at e400 (32-bit, prefetchable) [size=64M]
Capabilities: [88] #09 [f104]
Capabilities: [a0] AGP version 2.0

00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) (prog-if 00 
[Normal decode])
Flags: bus master, 66Mhz, fast devsel, latency 32
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: c000-cfff
Memory behind bridge: fc00-fdff
Prefetchable memory behind bridge: e800-ebff

00:1e.0 PCI bridge: Intel Corporation: Unknown device 2448 (rev 02) (prog-if 00 
[Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, 

Re: hotmail can't deal with ECN

[David S. Miller]

James H. Cloos Jr. writes:
 > Are there any well know sites using ECN we can test against?

Use non-passive FTP to my workstation and just do a directory listing
which will make the FTP server create a TCP connection back to your
machine for the transfer of the directory listing.

My workstation is pizda.ninka.net, please everyone be nice.

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: x86 PAT errata

[Jeff Hartmann]

H. Peter Anvin wrote:

> Followup to:  <[EMAIL PROTECTED]>
> By author:Mikael Pettersson <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> 
>> Before people get too exited about the x86 Page Attribute Table ...
>> Does Linux use mode B (CR4.PSE=1) or mode C (CR4.PAE=1) paging?
>> If so, known P6 errata must be taken into account.
>> In particular, Pentium III errata E27 and Pentium II errata A56
>> imply that only the low four PAT entries are working for 4KB
>> pages, if CR4.PSE or CR4.PAE is enabled.
>> 
> 
> 
> All of the above.  Sounds like PAT should be declared broken on these
> chips.
> 
>   -hpa

We can do set PAT entry one to be write combined.  Currently it doesn't 
look like anyone is using write through page mapping anywhere in the 
kernel (Just PAGE_PWT set).  Am I correct in that assumption?

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

2.2.18 + VM-global + reiserfs + ext3 0.0.5e safe?

[Matthias Andree]

Hi,

Short story:

it's again the reiserfs + ext3 issue. I managed to get ext3 and reiserfs
into the same tree. Is that safe to use without further patching?

Long story:

I have a heavily patched kernel (mostly drivers like I²C, dc390 and
stuff), among the patches are VM-global-7 by Andrea Arcangeli and
ReiserFS 3.5.28. After that, I merged ext3 0.0.5e, there were no
conflicts in buffer code or anything (so I assume my last ext3 merge
failed for VM-global-7, not for reiserfs). 

However, the old symbol clashes (buffer_journaled and release_journal)
remain. I used perl to rename these symbols to reiserfs_buffer_journaled
and reiserfs_release_journal in fs/reiserfs/*.c and
include/linux/fs_reiserfs.h, cleaned up the Makefile and *.h rejects
(only "bad context" because reiserfs was already there, and
prototypes). 

Now, is there any reason for concern the kernel might cause fs
corruption beyond the risk that EITHER reiserfs OR ext3 ONE BY ITSELF
infer?

The kernel patched like this compiles without relevant warnings and
boots up ok, copying from a ro-mounted ext2 to either reiserfs or ext3
does not cause obvious problems, but is there a potential for failure
that I can't see at the moment?

-- 
Matthias Andree
-
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] Latest AMD & VIA IDE drivers with UDMA100 support

[David D.W. Downey]

LOL, I'm in Sunnyvale, CA right now. I work for Ensim.Com.



OK, here is all the technical info on my box. Sorry it took so long to
respond. Had a department meeting to attend.


MSI 694D Pro running Dual FC-PGA PIII-733 CPUs with 1GB of Corsair RAM.

HDD is a Western Digital WDC300BB-00AU1 ATA100 drive (running it on the
VIA controlled ATA33/66 controller since the kernel doesn't support the
ATA100 very well.)

Chipsets are the VIA VT82C686A and the Promise PDC20265

NIC is a NetGear FA-310TX

Advansys UW SCSI Card

Yamaha CRW8424S CDRW

Voodoo3 2000 AGP 16MB AGP video card.


APM/ACPI turned OFF in BIOS, NOT using the ATA100 controller


Symptoms: Consistantly recurring kernel deaths resulting in hard lock of
box.






 
On Thu, 25 Jan 2001, Andre Hedrick wrote:

> 
> Where the flip are you form this power starved portion of the world?
> Also the subject is AMD and VIA chipsets not AMD CPU's running on VIA
> chipsets.
> 
> What chipset or host is causing you the problem?
> 
> VIA pr Promise?
> 
> On Thu, 25 Jan 2001, David D.W. Downey wrote:
> 
> > 
> > 
> > OK, I see you guys releasing patches for the AMD + VIA problem, but this
> > problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s
> > and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When
> > are we going to see something for the MSI boards?
> > 
> > My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset
> > and the Promise PDC20265 ATA100 onbard controller.
> > 
> > I need some sort of help with this. I'm getting kernel deaths left and
> > right and no hope in sight here.
> > 
> > I though it might possibly be a mix of SCSI + IDE causing troubles so I
> > borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys
> > SCSI card (not sure of the make offhand. I can find the box when I get
> > home as I'm at work right now.)
> > 
> > I would code up a fix if I knew what the hell I was doing when it came to
> > coding which I do NOT.
> > 
> > Vojtech, can you please work with me on this issue? Or if you are too
> > busy, can you put me in contact with someone who can help? I've got a
> > $3000 machine sitting here that I can not do a damn thing with until I
> > stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation
> > not at the kernel or anyone involved with the VIA stuff. Please don't take
> > it that way.)
> > 
> > David Downey
> > 
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > Please read the FAQ at http://www.tux.org/lkml/
> > 
> 
> Andre Hedrick
> Linux ATA Development
> 

-
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: pcmcia delay causes bootp not to work

[Ookhoi]

Hi David,

> Er... no, don't try that patch. It'll oops. Try this instead.
> 
> --- drivers/pcmcia/yenta.c2000/12/05 13:30:42 1.1.2.23
> +++ drivers/pcmcia/yenta.c2001/01/25 23:10:35
> @@ -859,7 +859,8 @@
>   socket->tq_task.data = socket;
>  
>   MOD_INC_USE_COUNT;
> - schedule_task(>tq_task);
> + //  schedule_task(>tq_task);
> + yenta_open_bh(socket);
>  
>   return 0;
>  }

Thank you. :-)  Unfortunately, the bootp message "IP-Config: No network
devices available." still comes before the initialisation of the network
card, and thus the nf mount still failes. :-(

(this is with a clean untarred linux tree, edit and compile, and I
double checked the change in drivers/pcmcia/yenta.c)

Is there an other way to initialize the nic before bootp kickes in?

Ookhoi
-
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: limit on number of kmapped pages

[David Wragg]

"Stephen C. Tweedie" <[EMAIL PROTECTED]> writes:
> On Wed, Jan 24, 2001 at 12:35:12AM +, David Wragg wrote:
> > 
> > > And why do the pages need to be kmapped? 
> > 
> > They only need to be kmapped while data is being copied into them.
> 
> But you only need to kmap one page at a time during the copy.  There
> is absolutely no need to copy the whole chunk at once.

The chunks I'm copying are always smaller than a page.  Usually they
are a few hundred bytes.

Though because I'm copying into the pages in a bottom half, I'll have
to use kmap_atomic.  After a page is filled, it is put into the page
cache.  So they have to be allocated with page_cache_alloc(), hence
__GFP_HIGHMEM and the reason I'm bothering with kmap at all.


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

2.2.19pre6/7: why can't I dump core?

[Rafal Boni]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Folks:

Maybe I'm missing something, but nothing seems to be able to dump core
on my 2.2.19pre6 box.  It looks like a lot of things look for 'current->
dumpable == 1' (actually, != 1) but I don't see the dumpable parameter
being set to 1 anywhere.  Moreover, it does get set to non-zero in a
few places, but then gets reset if the binary is readable (not sure if
I read that code correctly)??

I've done a quick inspection of pre7 patch set and noticed about the
same thing.  Is this an oversight, did someone intentionally turn off
core dumping until some other widget is incorporated into the patches,
or none of the above (a conspiracy, maybe? 8-).

[BTW, I'd appreciate it if you CC'ed me on any answers, as I'm not on 
 the list due to high traffic...]

Thanks for any insight,
- --rafal

- 
Rafal Boni   [EMAIL PROTECTED]
 PGP key C7D3024C, print EA49 160D F5E4 C46A 9E91  524E 11E0 7133 C7D3 024C
Need to get a hold of me?  http:[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999

iD8DBQE6cLmsEeBxM8fTAkwRAtFkAKCl0yDb+6kN7xoUAi9JW9mAtIAMPQCfQnvX
3ZOwOmeMPX7kchQL9mXJGtU=
=TSbX
-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/

A NFS/LFS patch for kernel 2.4.0

[H . J . Lu]

Here is a patch for kernel 2.4.0. Without it, kernel 2.4.0 won't pass
the Connectathon Testsuite.

-- 
H.J. Lu ([EMAIL PROTECTED])
---
--- linux/fs/lockd/clntproc.c.lfs   Sun Dec  3 18:01:01 2000
+++ linux/fs/lockd/clntproc.c   Thu Jan 25 14:58:42 2001
@@ -142,7 +142,8 @@ nlmclnt_proc(struct inode *inode, int cm
 
/* If we're cleaning up locks because the process is exiting,
 * perform the RPC call asynchronously. */
-   if ((cmd == F_SETLK || cmd == F_SETLKW)
+   if ((cmd == F_SETLK || cmd == F_SETLKW
+|| cmd == F_SETLK64 || cmd == F_SETLKW64)
&& fl->fl_type == F_UNLCK
&& (current->flags & PF_EXITING)) {
sigfillset(>blocked);  /* Mask all signals */
@@ -166,13 +167,15 @@ nlmclnt_proc(struct inode *inode, int cm
/* Set up the argument struct */
nlmclnt_setlockargs(call, fl);
 
-   if (cmd == F_GETLK) {
+   if (cmd == F_GETLK || cmd == F_GETLK64) {
status = nlmclnt_test(call, fl);
-   } else if ((cmd == F_SETLK || cmd == F_SETLKW)
+   } else if ((cmd == F_SETLK || cmd == F_SETLKW
+   || cmd == F_SETLK64 || cmd == F_SETLKW64)
   && fl->fl_type == F_UNLCK) {
status = nlmclnt_unlock(call, fl);
-   } else if (cmd == F_SETLK || cmd == F_SETLKW) {
-   call->a_args.block = (cmd == F_SETLKW)? 1 : 0;
+   } else if (cmd == F_SETLK || cmd == F_SETLKW
+  || cmd == F_SETLK64 || cmd == F_SETLKW64) {
+   call->a_args.block = (cmd == F_SETLKW) || cmd == F_SETLKW64? 1 : 0;
status = nlmclnt_lock(call, fl);
} else {
status = -EINVAL;
--- linux/fs/locks.c.lfsSun Dec  3 10:24:07 2000
+++ linux/fs/locks.cThu Jan 25 15:12:31 2001
@@ -257,7 +257,7 @@ static int assign_type(struct file_lock 
 static int flock_to_posix_lock(struct file *filp, struct file_lock *fl,
   struct flock *l)
 {
-   loff_t start;
+   off_t start, end;
 
switch (l->l_whence) {
case 0: /*SEEK_SET*/
@@ -270,17 +270,16 @@ static int flock_to_posix_lock(struct fi
start = filp->f_dentry->d_inode->i_size;
break;
default:
-   return (0);
+   return -EINVAL;
}
 
if (((start += l->l_start) < 0) || (l->l_len < 0))
-   return (0);
-   fl->fl_end = start + l->l_len - 1;
-   if (l->l_len > 0 && fl->fl_end < 0)
-   return (0);
-   if (fl->fl_end > OFFT_OFFSET_MAX)
-   return 0;
+   return -EINVAL;
+   end = start + l->l_len - 1;
+   if (l->l_len > 0 && end < 0)
+   return -EOVERFLOW;
fl->fl_start = start;   /* we record the absolute position */
+   fl->fl_end = end;
if (l->l_len == 0)
fl->fl_end = OFFSET_MAX;

@@ -292,7 +291,7 @@ static int flock_to_posix_lock(struct fi
fl->fl_insert = NULL;
fl->fl_remove = NULL;
 
-   return (assign_type(fl, l->l_type) == 0);
+   return assign_type(fl, l->l_type);
 }
 
 #if BITS_PER_LONG == 32
@@ -312,14 +311,14 @@ static int flock64_to_posix_lock(struct 
start = filp->f_dentry->d_inode->i_size;
break;
default:
-   return (0);
+   return -EINVAL;
}
 
if (((start += l->l_start) < 0) || (l->l_len < 0))
-   return (0);
+   return -EINVAL;
fl->fl_end = start + l->l_len - 1;
if (l->l_len > 0 && fl->fl_end < 0)
-   return (0);
+   return -EOVERFLOW;
fl->fl_start = start;   /* we record the absolute position */
if (l->l_len == 0)
fl->fl_end = OFFSET_MAX;
@@ -339,10 +338,10 @@ static int flock64_to_posix_lock(struct 
fl->fl_type = l->l_type;
break;
default:
-   return (0);
+   return -EINVAL;
}
 
-   return (1);
+   return (0);
 }
 #endif
 
@@ -1352,8 +1351,8 @@ int fcntl_getlk(unsigned int fd, struct 
if (!filp)
goto out;
 
-   error = -EINVAL;
-   if (!flock_to_posix_lock(filp, _lock, ))
+   error = flock_to_posix_lock(filp, _lock, );
+   if (error)
goto out_putf;
 
if (filp->f_op && filp->f_op->lock) {
@@ -1442,8 +1441,8 @@ int fcntl_setlk(unsigned int fd, unsigne
}
}
 
-   error = -EINVAL;
-   if (!flock_to_posix_lock(filp, file_lock, ))
+   error = flock_to_posix_lock(filp, file_lock, );
+   if (error)
goto out_putf;

error = -EBADF;
@@ -1517,8 +1516,8 @@ int fcntl_getlk64(unsigned int fd, struc
if (!filp)
goto out;
 
-   error = -EINVAL;
-   if (!flock64_to_posix_lock(filp, _lock, ))
+   error = flock64_to_posix_lock(filp, _lock, );
+   if (error)
goto 

Re: [UPDATE] Zerocopy, last one today I promise :-)

[Anton Blanchard]

 
> o If sock_writepage is called on path via device without SG support,
>   the cooked up sock_sendmsg() call needs to switch to KERNEL_DS.
>   Discovered and fixed by Ingo Molnar.

Good catch.

> This does show that not too many people are testing this all that
> thoroughly :-) Basically, any sys_sendfile() over TCP using a network
> card other than loopback/3c59x/sunhme/acenic would fail with -EFAULT
> or even worse a kernel crash depending upon architecture.

Hey now, I was seeing it but I hadn't got around to chasing the bug down. :)

Anton
-
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: hotmail not dealing with ECN

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Jeremy Hansen <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Just curious if others have noticed that hotmail is unable to deal with
> ECN and wondering if this is a standard that should be encouraged, as in
> should I tell hotmail that perhaps they should look into supporting it, or
> should I not waste my breath and echo 0 > /proc/sys/net/ipv4/tcp_ecn?
> 

They are.  I do think they have a point, though; ECN is listed as an
experimental standard at IETF, and I do think that it's not exactly
fair to *require* everyone to use it until it is standards-track.  It
would be another thing if Linux could turn it off on a per-connection
basis if these packets get dropped.

In general, I have found the Hotmail people to be quite responsive to
problems as long as they gets pointed out that they violate
established standards.  In this case, though, they feel that they
don't want to potentially destabilize their network over something
that is labelled an experimental standard.  I can certainly understand
their point.

-hpa

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

Re: hotmail can't deal with ECN

[James H. Cloos Jr.]

> "alex" == alex  <[EMAIL PROTECTED]> writes:

alex> I think the point of a test address is that this could
alex> conceivably affect more providers than just Hotmail, and it
alex> would be useful for people to be able to check to make sure
alex> their own provider isn't also ECN brain damaged ...

I have to agree with this.

Are there any well know sites using ECN we can test against?

Doesn't have to be a mail server, of course.  Maybe a web server with
auth lookups turned on?  or an ftp server supporting only non-passive
xfers.  An open squid.  Several possibilities exist for the general
case.  (Although for some who want to test a mail autoresponder may be
the only useable option)

-JimC
-- 
James H. Cloos, Jr.   1024D/ED7DAEA6 
<[EMAIL PROTECTED]>  E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6

-
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: inode->i_dirty_buffers redundant ?

[Marcelo Tosatti]

On Thu, 25 Jan 2001, Daniel Phillips wrote:

> "Stephen C. Tweedie" wrote:
> > We also maintain the 
> > per-page buffer lists as caches of the virtual-to-physical mapping to
> > avoid redundant bmap()ping.
> 
> Could you clarify that one, please?

Daniel, 

With "physical mapping" Stephen means on-disk block number.

If the buffer(s) for a page are mapped with valid information (ie
BH_Mapped) we avoid calling get_block(). 

See?

-
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] 2.4.0-ac11: small NTFS fixes

[Anton Altaparmakov]

Alan,

Please apply attached ntfs patch for next 2.4.0-ac kernel release.

It fixes a long standing bug where values of lengths of runs were
considered unsigned when they are in fact signed numbers (both read and
write). Also it makes a correction to how negative mft_recordsizes are
handled. 

Thanks go to Yuri Per <[EMAIL PROTECTED]> for the initial patch (which
required only a tiny modification).

Best regards,

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


diff -ur linux-2.4.0-ac11-vanilla/fs/ntfs/inode.c linux/fs/ntfs/inode.c
--- linux-2.4.0-ac11-vanilla/fs/ntfs/inode.cWed Jan 24 23:23:46 2001
+++ linux/fs/ntfs/inode.c   Thu Jan 25 23:42:52 2001
@@ -444,16 +444,16 @@
*ctype = 0;
switch (type & 0xF) {
case 1: 
-   *length = NTFS_GETU8(*data);
+   *length = NTFS_GETS8(*data);
break;
case 2: 
-   *length = NTFS_GETU16(*data);
+   *length = NTFS_GETS16(*data);
break;
case 3: 
-   *length = NTFS_GETU24(*data);
+   *length = NTFS_GETS24(*data);
break;
 case 4: 
-   *length = NTFS_GETU32(*data);
+   *length = NTFS_GETS32(*data);
break;
/* Note: cases 5-8 are probably pointless to code, since how
 * many runs > 4GB of length are there? At the most, cases 5
@@ -463,6 +463,11 @@
ntfs_error("Can't decode run type field %x\n", type);
return -1;
}
+   if (*length < 0)
+   {
+   ntfs_error("Negative run length decoded\n");
+   return -1;
+   }
*data += (type & 0xF);
switch (type & 0xF0) {
case 0:
@@ -704,13 +709,14 @@
if (offset + 8 > size)
return -E2BIG; /* It might still fit, but this
* simplifies testing. */
-   if (len < 0x100) {
+   /* Run length is stored as signed number. */
+   if (len <= 0x7F) {
NTFS_PUTU8(rec + offset + 1, len);
coffs = 1;
-   } else if (len < 0x1) {
+   } else if (len < 0x7FFF) {
NTFS_PUTU16(rec + offset + 1, len);
coffs = 2;
-   } else if (len < 0x100) {
+   } else if (len < 0x7F) {
NTFS_PUTU24(rec + offset + 1, len);
coffs = 3;
} else {
@@ -720,21 +726,21 @@
*(rec + offset) |= coffs++;
if (rl[i].cluster == MAX_CLUSTER_T) /* Compressed run. */
/* Nothing */;
-   else if (rclus > -0x80 && rclus < 0x7F) {
+   else if (rclus >= -0x80 && rclus <= 0x7F) {
*(rec + offset) |= 0x10;
NTFS_PUTS8(rec + offset + coffs, rclus);
coffs += 1;
-   } else if(rclus > -0x8000 && rclus < 0x7FFF) {
+   } else if(rclus >= -0x8000 && rclus <= 0x7FFF) {
*(rec + offset) |= 0x20;
NTFS_PUTS16(rec + offset + coffs, rclus);
coffs += 2;
-   } else if(rclus > -0x80 && rclus < 0x7F) {
+   } else if(rclus >= -0x80 && rclus <= 0x7F) {
*(rec + offset) |= 0x30;
NTFS_PUTS24(rec + offset + coffs, rclus);
coffs += 3;
} else
 #if 0 /* In case ntfs_cluster_t ever becomes 64bit. */
-   if (rclus > -0x8000LL && rclus < 0x7FFF)
+   if (rclus >= -0x8000LL && rclus <= 0x7FFF)
 #endif
{
*(rec + offset) |= 0x40;
@@ -742,16 +748,17 @@
coffs += 4;
}
 #if 0 /* For 64-bit ntfs_cluster_t */
-   else if (rclus > -0x80 && rclus < 0x7F) {
+   else if (rclus >= -0x80 && rclus <= 0x7F) {
*(rec + offset) |= 0x50;
NTFS_PUTS40(rec + offset + coffs, rclus);
coffs += 5;
-   } else if (rclus > -0x8000 && rclus < 0x7FFF) {
+   } else if (rclus >= -0x8000 && 
+   rclus <= 0x7FFF) {
*(rec + offset) |= 0x60;
NTFS_PUTS48(rec + offset + coffs, rclus);
coffs += 6;
-   } else if (rclus > -0x80 && 
-   rclus < 0x7F) {
+   

2.4.1-pre8 losing pages

[Peter Horton]

I'm experiencing repeatable corruption whilst writing large volumes of
data to disk. Kernel version is 2.4.1-pre8, on an 850MHz AMD Athlon on an
ASUS A7V (VIA KT133 chipset) motherboard 128M RAM (tested with 'memtest86'
for 10 hours).

First, I realised that the fsck was noticing small corruptions on my ext2
volume. My first suspect was the much discussed VIA IDE controller. As a
test I created a 128M file from "urandom" and copied it to twenty six
files. When I MD5 the files one or two of them are usually corrupt. The
damage usually occurs in the 24th copy (thought not always). Inspecting
the files shows a single 4K block (aligned on a 4K boundary) that is
completely different from what it should be. The kernel logs no errors
whilst writing the corrupt files.

I've repeated the test on the other on-board IDE controller (Promise), a
different hard disk, and on reiserfs. I see the corruption in all cases.

I tried building the kernel for "Pentium-Classic", and I tried a few older
kernels (2.4.0-test5 and 2.4.0-test12), still bad (all kernels built with
GCC 2.95.2 - Debian potato).

I really could do with some help as where to look next :-). I did try and
come up with a test to see whether bad data is written or whether the
damaged piece is just not written, but if I alter the testing procedure
too much the problem seems to go away. It seems to just lose a single page
under one very specific circumstance.

P.

( configs attached )


 info.tar.gz

RE: named streams, extended attributes, and posix

[Leif Sawyer]

[EMAIL PROTECTED] [[EMAIL PROTECTED]] wrote:
> Here's an idea: streams/etc are reached by appending 
> "/.../xxx" or some such to paths, thus:
>   for streamname on /dir/file, we have "/dir/file/.../streamname" 
>  for a directory /dir/dir, we get /dir/dir/.../streamname" 
>-- "..." is a special subdirectory of any directories which have 

An interesting point to note here would be that
the directory '...'  has been used for many years to 'hide' things
from un-skilled sysadmins.

In other words, warez ftp sites pop up all over the place, and this
directory name is pretty close to being the number one stash point,
right next to ".. "



-
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: pcmcia delay causes bootp not to work

[David Woodhouse]

Er... no, don't try that patch. It'll oops. Try this instead.

--- drivers/pcmcia/yenta.c  2000/12/05 13:30:42 1.1.2.23
+++ drivers/pcmcia/yenta.c  2001/01/25 23:10:35
@@ -859,7 +859,8 @@
socket->tq_task.data = socket;
 
MOD_INC_USE_COUNT;
-   schedule_task(>tq_task);
+   //  schedule_task(>tq_task);
+   yenta_open_bh(socket);
 
return 0;
 }


--
dwmw2


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

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

"Richard B. Johnson" wrote:
> 
> On Thu, 25 Jan 2001, H. Peter Anvin wrote:
> 
> > Matthew Dharm wrote:
> > >
> > > It occurs to me that it might be a good idea to pick a different port for
> > > these things.  I know a lot of people who want to use port 80h for
> > > debugging data, especially in embedded x86 systems.
> > >
> >
> > Find a safe port, make sure it is tested the hell out of, and we'll
> > consider it.
> >
> >   -hpa
> >
> 
> You could use the DMA scratch register at 0x19. I'm sure Linux doesn't
> "save" stuff there when setting up the DMA controller.
> 

Does that break the BIOS in any way, shape, or form?  Again, someone gets
to make a patch and then test the hell out of it... and find the random
Olivetti which hooks the screen up to the A20M# signal and other weird
crap.

-hpa

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

Re: pcmcia delay causes bootp not to work

[David Woodhouse]

On Fri, 26 Jan 2001, Ookhoi wrote:

> And unfortunately, the guy who mailed me didn't respond at my cry
> for help, so now I try the list again. :-)

Sorry, try this patch.

Index: drivers/pcmcia/yenta.c
===
RCS file: /inst/cvs/linux/drivers/pcmcia/Attic/yenta.c,v
retrieving revision 1.1.2.23
diff -u -r1.1.2.23 yenta.c
--- drivers/pcmcia/yenta.c  2000/12/05 13:30:42 1.1.2.23
+++ drivers/pcmcia/yenta.c  2001/01/25 23:07:35
@@ -855,11 +855,12 @@
   initialisation later. We can't do this here,
   because, er, because Linus says so :)
*/
-   socket->tq_task.routine = yenta_open_bh;
-   socket->tq_task.data = socket;
+   //  socket->tq_task.routine = yenta_open_bh;
+   //  socket->tq_task.data = socket;
 
MOD_INC_USE_COUNT;
-   schedule_task(>tq_task);
+   //  schedule_task(>tq_task);
+   yenta_open_bh(socket);
 
return 0;
 }

-- 
dwmw2


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

Re: Linux Post codes during runtime, possibly OT

[Richard B. Johnson]

On Thu, 25 Jan 2001, H. Peter Anvin wrote:

> Matthew Dharm wrote:
> > 
> > It occurs to me that it might be a good idea to pick a different port for
> > these things.  I know a lot of people who want to use port 80h for
> > debugging data, especially in embedded x86 systems.
> > 
> 
> Find a safe port, make sure it is tested the hell out of, and we'll
> consider it.
> 
>   -hpa
> 

You could use the DMA scratch register at 0x19. I'm sure Linux doesn't
"save" stuff there when setting up the DMA controller.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 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: named streams, extended attributes, and posix

[alex]

On Thu, Jan 25, 2001 at 02:07:11PM -0700, Thunder from the hill wrote:
> Daniel Phillips wrote:
> > For some reason totally beyond my comprehension // inside a file name is
> > taken to be the same as /, but if it wasn't it could be the stream
> > separator.  *sigh*
> It seems that you mix up forward and backward slashes. a // means //,
> but a \\ means a single \. So if you want a double backslash, you have

No, he's referring to the fact that multiple path separators ("/") in a file 
specification are collapsed to be equivalent to one.  Thus "/some//file///path"
is equivalent to "/some/file/path" as far as the system is concerned.

This is actually a very handy thing, IMHO, and avoids tons of 
trailing-slash/leading-slash special-case logic in apps, not to mention subtle 
bugs resulting from lack of same as I have encountered way too many times on 
other platforms...

I agree however, that it would perhaps have been nice if POSIX hadn't been 
quite so gung-ho about any-character-under-the-sun-is-ok-in-filenames so we had a 
couple of reserved characters to play with down the line..

Here's an idea: streams/etc are reached by appending "/.../xxx" or some 
such to paths, thus:
  for streamname on /dir/file, we have "/dir/file/.../streamname" 
-- a few more characters to type but no big deal really,
  for a directory /dir/dir, we get /dir/dir/.../streamname" 
-- "..." is a special subdirectory of any directories which have 
attached streams.  If the name of such a directory is chosen well 
(personally, I think "..." is a good choice as it goes well with "." and 
".." as a filesystem-intrinsic name), this is much less likely to 
conflict with normal filesystem namespaces.

This also has the advantage of being extendable (using strings other than 
"...") for other applications or future additions.

-alex
-
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: inode->i_dirty_buffers redundant ?

[Marcelo Tosatti]

On Thu, 25 Jan 2001, Stephen C. Tweedie wrote:

> Hi,
> 
> On Thu, Jan 25, 2001 at 04:17:30PM +0530, V Ganesh wrote:
> 
> > so i_dirty_buffers contains buffer_heads of pages coming from write() as
> > well as metadata buffers from mark_buffer_dirty_inode(). a dirty MAP_SHARED
> > page which has been write()n to will potentially exist in both lists.
> > won't doing a set_dirty_page() instead of buffer_insert_inode_queue() in
> > __block_commit_write() make things much simpler ? then we'd have i_dirty_buffers
> > having _only_ metadata, and all data pages in the i_mapping->*_pages lists.
> 
> That would only complicate things: it would mean we'd have to scan
> both lists on fsync instead of just the one, for example.  There are a
> number of places where we need buffer lists for dirty data anyway,
> such as for bdflush's background sync to disk.  We also maintain the
> per-page buffer lists as caches of the virtual-to-physical mapping to
> avoid redundant bmap()ping.  

Btw, 

We probably want another kind of "IO buffer" abstraction for 2.5 which can
support buffer's bigger than PAGE_SIZE. 

Do you have any thoughts on that, Stephen? 


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

pcmcia delay causes bootp not to work

[Ookhoi]

Hi,

A few days ago I mailed that I can't get nfsroot to work because bootp
tries to do its job before the cardbus card gets initialized. I got a
message from somebody who said that the pcmcia devices are a bit delayed
at boottime, which is also mentioned in the source. Unfortunately I'm
too stupid to be able to change the source code, and get rid of the
delay. And unfortunately, the guy who mailed me didn't respond at my cry
for help, so now I try the list again. :-)

Btw, I use lilo to load the kernel, and also tried:
append="rootnfs=192.168.0.1:/usr/remote 
ip=192.168.0.4:192.168.0.1:192.168.0.1:255.255.255.0:vaio::"

Why doesn't the network card gets configured with ip-address
192.168.0.4 ? Can it also be due to the delay? It lookes like the light
on the nic lights up at the same time as the error message about nfs
server not found. I don't see any traffic at all at the lan.

(I'm now almost four weeks fighting my vaio to get linux on it. It is no
problem to boot from the usb floppy drive, but then nfsroot doesn't work
due to the pcmcia delay, and a root image on floppy doesn't work due to
some usb problems. The kernels seemes to find and accept the usb floppy
drive just fine, but then I can't make it to load the root image. It
seemes as if /dev/sda doesn't get 'connected' with the fdd. I appreciate
any help with this of course :-)

Ookhoi


Subject: Re: bootp starts before network device?

> [EMAIL PROTECTED] said:
> > It says: IP-Config: No network devices available.
> > a few lines below that the nic (3com 575) is detected.  Of course it
> > fails to do the nfs mount. 
> 
> The kernel delays the initialisation of CardBus sockets to prevent it
> from dying in an IRQ storm as soon as it registers the interrupt. The
> CardBus sockets don't actually get initialised until later (from
> keventd).
> 
> Can you try changing the end of yenta_open() to call yenta_open_bh()
> directly instead of queueing via schedule_task().

Thank you for your response. Unfortunately I'm no C expert at all, and I
don't understand what to do with this piece of code:

drivers/pcmcia/yenta.c:854

/* Get the PCMCIA kernel thread to complete the
   initialisation later. We can't do this here,
   because, er, because Linus says so :)
*/
socket->tq_task.routine = yenta_open_bh;
socket->tq_task.data = socket;

MOD_INC_USE_COUNT;
schedule_task(>tq_task);

return 0;

It makes perfect sense to what you said about the delay, and the delay
makes perfect sense in bootp's complaining. :-)  But now this is way
over my head.. :-(

Can you please help me with what to change? Thanks again!

Ookhoi
-
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: Subtle MM bug

[Daniel Phillips]

Rik van Riel wrote:
> 
> On Tue, 9 Jan 2001, Daniel Phillips wrote:
> > Linus Torvalds wrote:
> > > (This is why I worked so hard at getting the PageDirty semantics right in
> > > the last two months or so - and why I released 2.4.0 when I did. Getting
> > > PageDirty right was the big step to make all of the VM stuff possible in
> > > the first place. Even if it probably looked a bit foolhardy to change the
> > > semantics of "writepage()" quite radically just before 2.4 was released).
> >
> > On the topic of writepage, it's not symmetric with readpage at
> > the moment - it still takes (struct file *).  Is this in the
> > cleanup pipeline?  It looks like nfs_readpage already ignores
> > the struct file *, but maybe some other net filesystems are
> > still depending on it.
> 
> writepage() and readpage() will never be symmetric...
> 
> readpage()
> program can't continue until data is there
> reading in larger clusters eats (wastes?) more memory
> done when we think a process needs data
> 
> writepage()
> called after the process has written data and moved on
> writing larger clusters has no influence on memory use
> often done to free up memory
> 
> Since readpage() needs to tune readahead behaviour, we will
> always want to give it some information (eg. in the file *)
> so it can do the extra things it needs to do.

Which extra information did you have in mind?

--
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: VM subsystem bug in 2.4.0 ?

[Daniel Phillips]

Christoph Rohland wrote:
> As of 2.4.1-pre we pin the pages by increasing the page count for
> locked segments. No special list needed.

Sure no special list is needed.  But without a special list to park
those pages on they will just circulate on the active/inactive lists,
wasting CPU cycles and trashing cache.  A special list would be an
improvement, but is no burning issue.

--
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: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Matthew Dharm wrote:
> 
> Isn't that always the way in the Open Source world? :)
> 
> Seriously, tho... does anyone have some list of who is using what ports?
> At least, in general?
> 

There is one included in Ralf Brown's Interrupt List.  No list you're
going to find is going to be complete, though.

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

Re: Linux Post codes during runtime, possibly OT

[Matthew Dharm]

Isn't that always the way in the Open Source world? :)

Seriously, tho... does anyone have some list of who is using what ports?
At least, in general?

Matt

On Thu, Jan 25, 2001 at 02:32:41PM -0800, H. Peter Anvin wrote:
> Matthew Dharm wrote:
> > 
> > It occurs to me that it might be a good idea to pick a different port for
> > these things.  I know a lot of people who want to use port 80h for
> > debugging data, especially in embedded x86 systems.
> > 
> 
> Find a safe port, make sure it is tested the hell out of, and we'll
> consider it.
> 
>   -hpa
> 
> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

P:  How about "Web Designer"?
DP: I'd like a name that people won't laugh at.
-- Pitr and Dust Puppy
User Friendly, 12/6/1997

 PGP signature

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Matthew Dharm wrote:
> 
> It occurs to me that it might be a good idea to pick a different port for
> these things.  I know a lot of people who want to use port 80h for
> debugging data, especially in embedded x86 systems.
> 

Find a safe port, make sure it is tested the hell out of, and we'll
consider it.

-hpa

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

Re: Linux Post codes during runtime, possibly OT

[Matthew Dharm]

It occurs to me that it might be a good idea to pick a different port for
these things.  I know a lot of people who want to use port 80h for
debugging data, especially in embedded x86 systems.

Matt

On Thu, Jan 25, 2001 at 02:26:36PM -0800, H. Peter Anvin wrote:
> Followup to:  <[EMAIL PROTECTED]>
> By author:"Ian S. Nelson" <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > I'm curious.  Why does Linux make that friendly 98/9a/88 looking
> > postcode pattern when it's running?  DOS and DOS95 don't do that.
> > 
> > I'm begining to feel like I can tell the system health by observing it,
> > kind of like "seeing the matrix."
> > 
> 
> It output garbage to the 80h port in order to enforce I/O delays.
> It's one of the safe ports to issue outs to.
> 
>   -hpa
> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

I say, what are all those naked people doing?
-- Big client to Stef
User Friendly, 12/14/1997

 PGP signature

Re: x86 PAT errata

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Mikael Pettersson <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Before people get too exited about the x86 Page Attribute Table ...
> Does Linux use mode B (CR4.PSE=1) or mode C (CR4.PAE=1) paging?
> If so, known P6 errata must be taken into account.
> In particular, Pentium III errata E27 and Pentium II errata A56
> imply that only the low four PAT entries are working for 4KB
> pages, if CR4.PSE or CR4.PAE is enabled.
> 

All of the above.  Sounds like PAT should be declared broken on these
chips.

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

Re: Linux Post codes during runtime, possibly OT

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:"Ian S. Nelson" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> I'm curious.  Why does Linux make that friendly 98/9a/88 looking
> postcode pattern when it's running?  DOS and DOS95 don't do that.
> 
> I'm begining to feel like I can tell the system health by observing it,
> kind of like "seeing the matrix."
> 

It output garbage to the 80h port in order to enforce I/O delays.
It's one of the safe ports to issue outs to.

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

Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[Andre Hedrick]

Where the flip are you form this power starved portion of the world?
Also the subject is AMD and VIA chipsets not AMD CPU's running on VIA
chipsets.

What chipset or host is causing you the problem?

VIA pr Promise?

On Thu, 25 Jan 2001, David D.W. Downey wrote:

> 
> 
> OK, I see you guys releasing patches for the AMD + VIA problem, but this
> problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s
> and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When
> are we going to see something for the MSI boards?
> 
> My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset
> and the Promise PDC20265 ATA100 onbard controller.
> 
> I need some sort of help with this. I'm getting kernel deaths left and
> right and no hope in sight here.
> 
> I though it might possibly be a mix of SCSI + IDE causing troubles so I
> borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys
> SCSI card (not sure of the make offhand. I can find the box when I get
> home as I'm at work right now.)
> 
> I would code up a fix if I knew what the hell I was doing when it came to
> coding which I do NOT.
> 
> Vojtech, can you please work with me on this issue? Or if you are too
> busy, can you put me in contact with someone who can help? I've got a
> $3000 machine sitting here that I can not do a damn thing with until I
> stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation
> not at the kernel or anyone involved with the VIA stuff. Please don't take
> it that way.)
> 
> David Downey
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

Andre Hedrick
Linux ATA Development

-
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] Latest AMD & VIA IDE drivers with UDMA100 support

[Vojtech Pavlik]

On Thu, Jan 25, 2001 at 01:54:36PM -0800, David D.W. Downey wrote:
> 
> 
> OK, I see you guys releasing patches for the AMD + VIA problem, but this
> problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s
> and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When
> are we going to see something for the MSI boards?
> 
> My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset
> and the Promise PDC20265 ATA100 onbard controller.
> 
> I need some sort of help with this. I'm getting kernel deaths left and
> right and no hope in sight here.
> 
> I though it might possibly be a mix of SCSI + IDE causing troubles so I
> borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys
> SCSI card (not sure of the make offhand. I can find the box when I get
> home as I'm at work right now.)
> 
> I would code up a fix if I knew what the hell I was doing when it came to
> coding which I do NOT.
> 
> Vojtech, can you please work with me on this issue? Or if you are too
> busy, can you put me in contact with someone who can help? I've got a
> $3000 machine sitting here that I can not do a damn thing with until I
> stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation
> not at the kernel or anyone involved with the VIA stuff. Please don't take
> it that way.)

Sure, I'll need a more precise description, though.

-- 
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: [preview] Latest AMD & VIA IDE drivers with UDMA100 support

[David D.W. Downey]

OK, I see you guys releasing patches for the AMD + VIA problem, but this
problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s
and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When
are we going to see something for the MSI boards?

My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset
and the Promise PDC20265 ATA100 onbard controller.

I need some sort of help with this. I'm getting kernel deaths left and
right and no hope in sight here.

I though it might possibly be a mix of SCSI + IDE causing troubles so I
borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys
SCSI card (not sure of the make offhand. I can find the box when I get
home as I'm at work right now.)

I would code up a fix if I knew what the hell I was doing when it came to
coding which I do NOT.

Vojtech, can you please work with me on this issue? Or if you are too
busy, can you put me in contact with someone who can help? I've got a
$3000 machine sitting here that I can not do a damn thing with until I
stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation
not at the kernel or anyone involved with the VIA stuff. Please don't take
it that way.)

David Downey


-
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: "no such 386 instruction" with gcc 2.95.2

[Brian Gerst]

"David L. Nicol" wrote:
> 
> I think I must need to upgrade my assembler, but:
> 2.4.0/Documentation/Changes does not list an assembler version.

The gas assembler is part of binutils.

--

Brian Gerst
-
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] eliminate #ifdef in parport_pc.c by adding empty entry in pci.h (241p10)

[Rasmus Andersen]

Hi.

The following two patches removes an #ifdef CONFIG_PCI in 
drivers/parport/parport_pc.c by adding a nop definition of
pci_match_device to include/linux/pci.h. It incidentially
also removes a compiler warning when CONFIG_PCI is not
set.

Applies against ac11 and 241p10 (the latter with a bit of
fuzz in the parport_pc.c case).

Please comment.


--- linux-ac11-clean/include/linux/pci.hThu Jan  4 23:51:32 2001
+++ linux-ac11/include/linux/pci.h  Thu Jan 25 22:03:51 2001
@@ -596,6 +596,7 @@
 static inline void pci_unregister_driver(struct pci_driver *drv) { }
 static inline int scsi_to_pci_dma_dir(unsigned char scsi_dir) { return scsi_dir; }
 static inline int pci_find_capability (struct pci_dev *dev, int cap) {return 0; }
+const struct pci_device_id *pci_match_device(const struct pci_device_id *ids, const 
+struct pci_dev *dev) { return NULL; }
 
 #else
 

--- linux-ac11-clean/drivers/parport/parport_pc.c   Thu Jan 25 20:49:12 2001
+++ linux-ac11/drivers/parport/parport_pc.c Thu Jan 25 22:02:49 2001
@@ -2552,7 +2552,6 @@
 
 static int __init parport_pc_init_superio (void)
 {
-#ifdef CONFIG_PCI
const struct pci_device_id *id;
struct pci_dev *pdev;
 
@@ -2563,7 +2562,6 @@
 
return parport_pc_superio_info[id->driver_data].probe (pdev);
}
-#endif /* CONFIG_PCI */
 
return 0; /* zero devices found */
 }


-- 
Regards,
Rasmus([EMAIL PROTECTED])

We're going to turn this team around 360 degrees.
-Jason Kidd, upon his drafting to the Dallas Mavericks
-
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 such 386 instruction" with gcc 2.95.2

[David L. Nicol]

I think I must need to upgrade my assembler, but:
2.4.0/Documentation/Changes does not list an assembler version.




make[2]: Entering directory `/mnt/sdb2/src/linux-2.4.0/drivers/md'
gcc -D__KERNEL__ -I/mnt/sdb2/src/linux-2.4.0/include -Wall -Wstrict-proto
types -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-sta
ck-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include /mnt/sdb2/src/l
inux-2.4.0/include/linux/modversions.h   -DEXPORT_SYMTAB -c xor.c
{standard input}: Assembler messages:
{standard input}:996: Error: no such 386 instruction: `movups'
{standard input}:997: Error: no such 386 instruction: `movups'
{standard input}:998: Error: no such 386 instruction: `movups'
{standard input}:999: Error: no such 386 instruction: `movups'
{standard input}:1001: Error: no such 386 instruction: `prefetcht0'
{standard input}:1002: Error: no such 386 instruction: `prefetcht0'
{standard input}:1005: Error: no such 386 instruction: `movaps'
{sta...
...


-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
Five seconds of light is a lot of data.

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

Linux Post codes during runtime, possibly OT

[Ian S. Nelson]

I'm curious.  Why does Linux make that friendly 98/9a/88 looking
postcode pattern when it's running?  DOS and DOS95 don't do that.

I'm begining to feel like I can tell the system health by observing it,
kind of like "seeing the matrix."

Ian

-
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: [UPDATE] Zerocopy patches, against 2.4.1-pre10

[David S. Miller]

Steve Whitehouse writes:
 > Do you mean that devices will not be able to indicate support of SG seperately
 > from hw checksum or that the IP zerocopy will simply ignore devices which
 > do not have both ?

IP will ignore devices which do not have both.

 > DECnet assumes that the mac level checksum will detect all errors and does
 > not have a checksum of its own on data, so it would only need SG to benefit
 > from the zerocopy framework,

Which is just fine.

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: In kernel 2.4.0 in alloc_uhci when doing request_irq()

[Johannes Erdfelt]

On Thu, Jan 25, 2001, Thunder from the hill <[EMAIL PROTECTED]> wrote:
> I am using an usual VIA MPV3 onboard USB device (on a AMD K6-II 400
> machine), and it has ever worked fine on Linux (until including
> 2.4.0-test10). Now I wanted to use the "retail" 2.4.0-kernel, and USB
> gets stuck while booting. Last messages are:
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> usb-uhci.c: $Revision: 1.251 $time 07:06:37 Jan 14 2001
> usb-uhci.c: high bandwidth mode enabled
> PCI: Assigned IRQ 10 for device 00:07.2
> usb-uhci.c: USB UHCI at I/O 0xe400, IRQ 10
> usb-uhci.c: Detected 2 ports
> usb.c: new USB bus registered, assigned bus number 1
> 
> That's all.
> I debugged a while and noticed that the error occurs beyond
> drivers/usb/usb-uhci.c in the function alloc_uhci() after start_hc (s);
> when calling request_irq(), the line reads:
>   if (request_irq (irq, uhci_interrupt, SA_SHIRQ, MODNAME, s)) {
> The called function crashes somewhere on top, as I noticed.
> Is there a patch avariable, or should I do further investigation?

No patches that I've seen. It sounds more like you have an IRQ routing
problem and the IRQ isn't getting acknowledged correctly and is flooding
the machine.

You can try putting a printk in uhci_interrupt to see how often it gets
called.

Also, do you have a PnP setting in your BIOS? Can you try changing it?

JE

-
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: [UPDATE] Zerocopy patches, against 2.4.1-pre10

[Steve Whitehouse]

Hi,

Do you mean that devices will not be able to indicate support of SG seperately
from hw checksum or that the IP zerocopy will simply ignore devices which
do not have both ?

DECnet assumes that the mac level checksum will detect all errors and does
not have a checksum of its own on data, so it would only need SG to benefit
from the zerocopy framework,

Steve.

> 
> 
> Ion Badulescu writes:
>  > I'm just wondering, if a card supports sg but *not* TX csum, is it worth
>  > it to make use of sg? eepro100 falls into this category..
> 
> No, not worth it for now.  In fact I'm going to mark that combination
> (sg without csum) as illegal in the final zerocopy patch I end up
> sending to Linus.
> 
> 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/
> 

-
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.1-pre10 slowdown at boot.

[Grover, Andrew]

I think it is too. For now, remove ACPI support.

-- Andy
(ACPI maintainer)

> -Original Message-
> From: Terje Rosten [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 25, 2001 12:23 PM
> To: Ondrej Sury
> Cc: [EMAIL PROTECTED]
> Subject: Re: 2.4.1-pre10 slowdown at boot.
> Importance: High
> 
> 
> * Ondrej Sury
> | 
> | 2.4.1-pre10 slows down after printing those (maybe ACPI or 
> reiserfs issue),
> | and even SysRQ-(s,u,b) is not imediate and waits several 
> (two+) seconds
> | before (syncing,remounting,booting).
> 
> I'm also seeing this. I think it's ACPI related, I am not using
> reiserfs. I have similar hardware.
> 
> 
>  - terje
> -
> 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/

In kernel 2.4.0 in alloc_uhci when doing request_irq()

[Thunder from the hill]

Hi,

I am using an usual VIA MPV3 onboard USB device (on a AMD K6-II 400
machine), and it has ever worked fine on Linux (until including
2.4.0-test10). Now I wanted to use the "retail" 2.4.0-kernel, and USB
gets stuck while booting. Last messages are:
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.251 $time 07:06:37 Jan 14 2001
usb-uhci.c: high bandwidth mode enabled
PCI: Assigned IRQ 10 for device 00:07.2
usb-uhci.c: USB UHCI at I/O 0xe400, IRQ 10
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1

That's all.
I debugged a while and noticed that the error occurs beyond
drivers/usb/usb-uhci.c in the function alloc_uhci() after start_hc (s);
when calling request_irq(), the line reads:
if (request_irq (irq, uhci_interrupt, SA_SHIRQ, MODNAME, s)) {
The called function crashes somewhere on top, as I noticed.
Is there a patch avariable, or should I do further investigation?

Thunder
---
I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard god...
-
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] Re: eepro100 problems in 2.4.0

[Jeff Garzik]

Jeff Garzik wrote:
> 
> Micah Gorrell wrote:
> > Because of the problems we where having we are no longer using the machine
> > with 3 nics.  We are now using a machine with just one and it is going live
> > next week.  We do need kernel 2.4 because of the process limits in 2.2.
> > Does the 'Enable Power Management (EXPERIMENTAL)' option fix the no
> > resources problems?
> 
> Does the attached patch, against 2.4.1-pre10, help matters any?
> diff -u -r1.1.1.9.42.2 eepro100.c
> --- drivers/net/eepro100.c  2001/01/24 15:56:16 1.1.1.9.42.2
> +++ drivers/net/eepro100.c  2001/01/25 21:00:48
> @@ -560,6 +560,9 @@
> if (speedo_debug > 0  &&  did_version++ == 0)
> printk(version);
> 
> +   if (pci_enable_device(pdev))
> +   return -EIO;
> +

Oops, sorry guys.  Thanks to DaveM for correcting me -- my patch has
nothing to do with the "card reports no resources" problem.  My
apologies.

Jeff


-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
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: [UPDATE] Zerocopy patches, against 2.4.1-pre10

[David S. Miller]

Ion Badulescu writes:
 > I'm just wondering, if a card supports sg but *not* TX csum, is it worth
 > it to make use of sg? eepro100 falls into this category..

No, not worth it for now.  In fact I'm going to mark that combination
(sg without csum) as illegal in the final zerocopy patch I end up
sending to Linus.

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: Turning off ARP in linux-2.4.0

[Julian Anastasov]

Hello,

On Thu, 25 Jan 2001, Bernd Eckenfels wrote:

> On Thu, Jan 25, 2001 at 01:02:32PM +0200, Julian Anastasov wrote:
> > Hey, the world is not only Linux. Sometimes the people build
> > clusters using different hardware and software. If your solution works
> > for your setup we can't claim it is universal.
>
> It is a Linux News Group after all. So dont confuse us with Broken Operating
> Systems. And of course we don't need a Hidden flag in Linux to solve other
> Operating Systems Auto-Binding.

I'm talking about ARP. /etc/ethers is outdated. ARP is widely
used, especially in environments with many hosts on the LAN, for dynamic
setups, etc. And the clusters are not a static configurations.

> > You can't always use -arp!!! Read above. Fix the manual! BTW
> > in this thread I don't see wrong docs. Which ones claim this?
>
> The Manual is OK. It claims that -arp will work and it claims that on some
> Linux Sytems it wont (i am not sure why it should not work on old kernels
> but i accept it).

It can work only in old kernels. -arp does not work in
Linux 2.2+, in the way you want.

> > -arp can work if you maintain a fresh copy in /etc/ethers and
> > when you don't use ARP. But then you don't need to set -arp flag. The
> > setup will work without setting -arp to lo or eth, right? If you don't
> > use ARP why to stop it in the interface? In theory we will not see any
> > ARP packets, even from the uplink router.
>
> I am not sure about this, because of the neighbour alive discovery. I dont
> know if a hard wired ARP Address will stop that.

If we have static MAC entry in the requestor it is used, no
ARP probes are sent. If we receive ARP probes we reply them.

> > You are lucky to use Linux on all hosts. May be you have one
> > extra uplink router (a Linux box)?
>
> You can turn off arp discovery on every reasonable pwerfull router. And I
> dont see a situation where you want to build a HA/HP Cluster using you ISPs
> Router as a core component and the ISP is not cooperating with you.

But when VIP is moved on failover I'll need access to this
router in the ISP :) So, I'll need one of the following three things:
(1) the uplink router password (2) how can I send a page to the ISP
admin (3) put own router

> > They are not complicated more in 2.4. The current handling in 2.4
> > is same. I already said that the net maintainers are planning other
> > features for 2.4 and the hidden feature is not considered. Until then
> > there is no difference between the kernels and the hidden feature can
> > be used even in 2.4.
>
> There is no hidden Feature in 2.4, thats why we have started the thread. And
> for exactly this reason I suggested to use -arp.

There is a reason to apply -arp in Linux 2.2+ only to devices
that can talk ARP. So, your recommendation in Linux 2.2+ can be
formulated in this way: "Use ifconfig eth0 -arp and maintain fresh copy
in /etc/ethers on all hosts" :) Your suggestion can be valid may be for
Linux 2.0 only (not tested). In 2.2+ altering the arp flag for lo or
similar devices connected only to the host system is useless. An evidence
for this behavior is the fact that when you try

ifconfig lo -arp
ifconfig lo:0 A.B.C.D netmask 255.255.255.255

you can ping this address from another host :) It is replied. Yep,
I just tried it again in 2.4 for the test :)

> Greetings
> Bernd


Regards

--
Julian Anastasov <[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: [UPDATE] Zerocopy patches, against 2.4.1-pre10

[Ion Badulescu]

On Thu, 25 Jan 2001, David S. Miller wrote:

>
> Ion Badulescu writes:
>  > Well, yes and no. It's not quite orthogonal, because normally TCP
>  > will never transmit fragmented packets, and it's precisely fragmented
>  > packets that make the interesting case with a card that supports
>  > hardware TCP/UDP checksums.
>
> No it is not the interesting case for such cards.  I have a feeling
> you have no idea what you are talking about or who you are speaking
> to.  Alexey bascially implemented all of the zerocopy stuff in that
> patch, so it's a good bet that he has a good idea what is orthogonal
> or not.

Wrong feeling. :-) No, I know who Alexey is and I think I know what I'm
talking about, too. We're just talking about different things, RX vs TX.

Obviously there isn't much we can do with fragmented packets on TX. If
only the IP people had learned from Ethernet people about a good place for
a CRC/csum...

> On transmit, on transmit, that's all that matters on the hardware side
> with these changes, where the card does the checksumming for us.
> We've supported receive checksum verification from the hardware
> forever, long before these changes.

Hmm, I must have missed the CHECKSUM_HW stuff. Mea culpa. Not that many
drivers use it at this time, I see a grand total of 2 (hamachi and hme) in
2.4.0 -- and yes I know who wrote the hme driver, too. :)

>  > And, on a related note: what's involved in making a driver
>  > zerocopy-aware? I haven't looked too closely to the current patch,
>
> When you look closely at the current patch, you will see exactly what
> is required.  3 hardware drivers are ported there, and are to be used
> as examples.

Ok.

I'm just wondering, if a card supports sg but *not* TX csum, is it worth
it to make use of sg? eepro100 falls into this category..

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
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:sigcontext on Linux-ppc in user space, another hack.

[jekacur]

It appears you can just use the siginfo_t * as the struct sigcontext *
!!
ie
void *signal_handler(int signo, siginfo_t *siginfoptr, struct sigcontext
*scp)
{
 scp = (struct sigcontext_struct *)siginfoptr;
 /* the rest of your code, here */
}


John Kacur/Toronto/IBM@IBMCA
[EMAIL PROTECTED]
(416) 448-2584 (phone)
778-2584 (tie line)


"Kevin B. Hendricks" <[EMAIL PROTECTED]> on 01/25/2001 02:02:20 PM

Please respond to [EMAIL PROTECTED]

To:   John Kacur/Toronto/IBM@IBMCA
cc:
Subject:  Re: [Fwd: sigcontext on Linux-ppc in user space]


Hi,

Just in case this helps,  here is what I did to accomplish the same thing
in the green_threads jdk.  It definitely is not portable.

Kevin

Inside the signal handler:

#elif defined(__linux__) && defined(__powerpc__)
/* get the value of r1 (the stack pointer) */
long * p;
struct sigcontext_struct * scp;
__asm__ ( "addi %0,1,0" : "=r" (p) : /* no inputs */ );
/* follow it back up the chain */
p = *p;
/* from here the sigcontext struct is 64 bytes away */
p = p + 16;
scp = (struct sigcontext_struct *)p;

On Thursday, January 25, 2001, at 01:50 PM, [EMAIL PROTECTED] wrote:

>
> Ok, actually the segfault was for a more complicated function, but the
> simplified example still gives the wrong answer. i.e scp should point to
a
> struct sigcontext and scp->signal should be 10 in the sample program.
>
> John Kacur/Toronto/IBM@IBMCA
> [EMAIL PROTECTED]
> (416) 448-2584 (phone)
> 778-2584 (tie line)
>
>
> "Kevin B. Hendricks" <[EMAIL PROTECTED]> on 01/25/2001 01:10:40 PM
>
> Please respond to [EMAIL PROTECTED]
>
> To:   John Kacur/Toronto/IBM@IBMCA
> cc:   [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject:  Re: [Fwd: sigcontext on Linux-ppc in user space]
>
>
> Hi,
>
> Here is what I get from running it on my system (ppc linux with 2.2.15
> kernel with some mods and glibc-2.1.3).
>
> But no segfault.
>
> Kevin
>
>
> [kbhend@localhost ~]$ gcc -O2 -ojunk junk.c
> [kbhend@localhost ~]$ ./junk
> SIGUSR1 = 10
> scp = 7fffe9a4
> scp->signal = 0
> [kbhend@localhost ~]$
>
>
>
>
> On Thursday, January 25, 2001, at 10:09 AM, [EMAIL PROTECTED] wrote:
>
> > #include 
> > #include 
> >
> > /* Function Prototypes */
> > void install_sigusr1_handler(void);
> > void sigusr_handler(int , siginfo_t *, struct sigcontext * scp);
> >
> > int main(void)
> > {
> > install_sigusr1_handler();
> > printf("SIGUSR1 = %d\n", SIGUSR1);
> > raise(SIGUSR1);
> > exit(0);
> > }
> >
> > void install_sigusr1_handler(void)
> > {
> > struct sigaction newAct;
> >
> > if (sigemptyset(_mask) != 0) {
> > fprintf(stderr, "Warning, sigemptyset failed.\n");
> > }
> >
> > newAct.sa_flags = 0;
> > newAct.sa_flags |= SA_SIGINFO | SA_RESTART;
> >
> > newAct.sa_sigaction = (void
> > (*)(int,siginfo_t*,void*))sigusr_handler;
> >
> > if (sigaction(SIGUSR1, , NULL) != 0) {
> > fprintf(stderr, "Couldn't install SIGUSR1 handler.\n");

> > fprintf(stderr, "Exiting.\n");
> > exit(1);
> > }
> > }
> >
> > void sigusr_handler(int signo, siginfo_t *siginfp, struct sigcontext *
> scp)
> > {
> > printf("scp = %08x\n", scp);
> > printf("scp->signal = %d\n", scp->signal);
> > }
> >
> >
>
>
>
>




-
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: eepro100 problems in 2.4.0

[Sergey Kubushin]

On Thu, 25 Jan 2001, Micah Gorrell wrote:

I do have such a problem with the machines that have only one eepro100 nic.

> Because of the problems we where having we are no longer using the
> machine
> with 3 nics.  We are now using a machine with just one and it is going
> live
> next week.  We do need kernel 2.4 because of the process limits in 2.2.
> Does the 'Enable Power Management (EXPERIMENTAL)' option fix the no
> resources problems?
>
> Micah
> ___
> The irony is that Bill Gates claims to be making a stable operating
> system
> and Linus Torvalds claims to be trying to take over the world
> -Original Message-
> From: "Tom Sightler" <[EMAIL PROTECTED]>
> To: "Micah Gorrell" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Date: Thursday, January 25, 2001 1:48 PM
> Subject: Re: eepro100 problems in 2.4.0
>
>
> > > I have doing some testing with kernel 2.4 and I have had constant
> >problems
> >> with the eepro100 driver.  Under 2.2 it works perfectly but under
> 2.4 I
> am
> >> unable to use more than one card in a server and when I do use one
> card I
> >> get errors stating that eth0 reports no recources.  Has anyone else
> seen
> >> this kind of problem?
> >
> >I had a similar problem with a server that had dual embedded eepro100
> >adapters however selecting the 'Enable Power Management
> (EXPERIMENTAL)'
> >option for the eepro100 seemed to make the problem go away.  I don't
> really
> >know why but it might be worth trying if it wasn't already selected.
> >
> >Later,
> >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/
> >
> >
>
> -
> 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/
>
>

---
Sergey Kubushin Sr. Unix Administrator
CyberBills, Inc.Phone:  702-567-8857
874 American Pacific Dr,Fax:702-567-8890
Henderson, NV, 89014

-
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: named streams, extended attributes, and posix

[Thunder from the hill]

Daniel Phillips wrote:
> 
> Michael Rothwell wrote:
> > Unfortunately, unix allows everything but "/" in filenames. This was
> > probably a mistake, as it makes it nearly impossible to augment the
> > namespace, but it is the reality.
> 
> For some reason totally beyond my comprehension // inside a file name is
> taken to be the same as /, but if it wasn't it could be the stream
> separator.  *sigh*
It seems that you mix up forward and backward slashes. a // means //,
but a \\ means a single \. So if you want a double backslash, you have
to write . Thus, removing double backslashes from NETBIOS names via
perl is: $name =~ s///;
So what...?

Cheers!
Thunder
---
I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard god...
-
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] Re: eepro100 problems in 2.4.0

[Jeff Garzik]

Micah Gorrell wrote:
> Because of the problems we where having we are no longer using the machine
> with 3 nics.  We are now using a machine with just one and it is going live
> next week.  We do need kernel 2.4 because of the process limits in 2.2.
> Does the 'Enable Power Management (EXPERIMENTAL)' option fix the no
> resources problems?

Does the attached patch, against 2.4.1-pre10, help matters any?

pci_enable_device() must to be called before any accesses to the
pci_dev->irq and pci_dev->resource[] members.  Plug-n-play may fill in
those values.  I didn't see your original report, but "no resources"
sounds to me like pci_enable_device() needs to be called earlier in the
speedo_init_one function.  The attached patch does just that.

Jeff


> -Original Message-
> From: "Tom Sightler" <[EMAIL PROTECTED]>
> To: "Micah Gorrell" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Date: Thursday, January 25, 2001 1:48 PM
> Subject: Re: eepro100 problems in 2.4.0
[...]
> >I had a similar problem with a server that had dual embedded eepro100
> >adapters however selecting the 'Enable Power Management (EXPERIMENTAL)'
> >option for the eepro100 seemed to make the problem go away.  I don't really
> >know why but it might be worth trying if it wasn't already selected.


-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie

Index: drivers/net/eepro100.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/eepro100.c,v
retrieving revision 1.1.1.9.42.2
diff -u -r1.1.1.9.42.2 eepro100.c
--- drivers/net/eepro100.c  2001/01/24 15:56:16 1.1.1.9.42.2
+++ drivers/net/eepro100.c  2001/01/25 21:00:48
@@ -560,6 +560,9 @@
if (speedo_debug > 0  &&  did_version++ == 0)
printk(version);
 
+   if (pci_enable_device(pdev))
+   return -EIO;
+
if (!request_region(pci_resource_start(pdev, 1),
pci_resource_len(pdev, 1), "eepro100")) {
printk (KERN_ERR "eepro100: cannot reserve I/O ports\n");
@@ -597,9 +600,6 @@
pci_read_config_word(pdev, pm + PCI_PM_CTRL, _command);
acpi_idle_state = pwr_command & PCI_PM_CTRL_STATE_MASK;
}
-
-   if (pci_enable_device(pdev))
-   goto err_out_free_mmio_region;
 
pci_set_master(pdev);
 

Re: eepro100 problems in 2.4.0

[Micah Gorrell]

Because of the problems we where having we are no longer using the machine
with 3 nics.  We are now using a machine with just one and it is going live
next week.  We do need kernel 2.4 because of the process limits in 2.2.
Does the 'Enable Power Management (EXPERIMENTAL)' option fix the no
resources problems?

Micah
___
The irony is that Bill Gates claims to be making a stable operating system
and Linus Torvalds claims to be trying to take over the world
-Original Message-
From: "Tom Sightler" <[EMAIL PROTECTED]>
To: "Micah Gorrell" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Date: Thursday, January 25, 2001 1:48 PM
Subject: Re: eepro100 problems in 2.4.0


> > I have doing some testing with kernel 2.4 and I have had constant
>problems
>> with the eepro100 driver.  Under 2.2 it works perfectly but under 2.4 I
am
>> unable to use more than one card in a server and when I do use one card I
>> get errors stating that eth0 reports no recources.  Has anyone else seen
>> this kind of problem?
>
>I had a similar problem with a server that had dual embedded eepro100
>adapters however selecting the 'Enable Power Management (EXPERIMENTAL)'
>option for the eepro100 seemed to make the problem go away.  I don't really
>know why but it might be worth trying if it wasn't already selected.
>
>Later,
>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/
>
>

-
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: non-random IP IDs

[David S. Miller]

Alexandre Hautequest writes:
 > I was playing a bit on some of my machines with Nessus (www.nessus.org), and it
 > told me the following text:
 > 

Nessus is saying something bogus to you.

 > Is there some option to dinamically enable this random IP ID's, or I need to 
 > change something and recompile, or just "No way!"?

Ip IDs only matter when packets can be fragmented.  If the packet
cannot be fragmented, the Ip ID field serves no purpose.  Whatever the
nessus thing did to test this, it used a IP packet to/from the linux
box which had the "Don't Fragment" bit set in the IP header, which as
a consequence means the ID field is meaningless.

If the "don't fragment" bit were not set, and fragmentation was
possible, Linux will use a randomized ID field.  The nessus folks
need to fix their test.

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: eepro100 problems in 2.4.0

[Tom Sightler]

 > I have doing some testing with kernel 2.4 and I have had constant
problems
> with the eepro100 driver.  Under 2.2 it works perfectly but under 2.4 I am
> unable to use more than one card in a server and when I do use one card I
> get errors stating that eth0 reports no recources.  Has anyone else seen
> this kind of problem?

I had a similar problem with a server that had dual embedded eepro100
adapters however selecting the 'Enable Power Management (EXPERIMENTAL)'
option for the eepro100 seemed to make the problem go away.  I don't really
know why but it might be worth trying if it wasn't already selected.

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

Oops with bonding (2.4.0, 2.4.0-ac11)

[Pfenniger Daniel]

The kernel oops when the bond0 device is shut down (for example at reboot). 

Linux 2.4.0 and 2.4.0-ac11, gcc 2.9.5-2. 
Pentium II SMP, supplied tulip driver for tulip cards with 21140 or 21143 chips

This doesn't happen with 2.2.18

Daniel Pfenniger
-
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: [UPDATE] Zerocopy patches, against 2.4.1-pre10

[David S. Miller]

Ion Badulescu writes:
 > Well, yes and no. It's not quite orthogonal, because normally TCP
 > will never transmit fragmented packets, and it's precisely fragmented
 > packets that make the interesting case with a card that supports
 > hardware TCP/UDP checksums.

No it is not the interesting case for such cards.  I have a feeling
you have no idea what you are talking about or who you are speaking
to.  Alexey bascially implemented all of the zerocopy stuff in that
patch, so it's a good bet that he has a good idea what is orthogonal
or not.

 > If the packets are not fragmented, then the card can just verify the
 > checksums and be done with it. However, with fragments, all it can
 > do is report a partial checksum to the driver and let the driver
 > (or the stack) combine those partial checksums into one complete
 > checksum once all fragments have arrived. At least that's what the
 > Starfire card does, maybe the 3com is different. :-)

On transmit, on transmit, that's all that matters on the hardware side
with these changes, where the card does the checksumming for us.
We've supported receive checksum verification from the hardware
forever, long before these changes.

The only interesting new thing on receive is that we do not linearize
a fragmented packet before passing it on to UDP etc.  And this has
nothing to do with what the card can or cannot do, it is purely a
software issue.

 > And, on a related note: what's involved in making a driver
 > zerocopy-aware? I haven't looked too closely to the current patch,

When you look closely at the current patch, you will see exactly what
is required.  3 hardware drivers are ported there, and are to be used
as examples.

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: named streams, extended attributes, and posix

[Daniel Phillips]

Michael Rothwell wrote:
> Unfortunately, unix allows everything but "/" in filenames. This was
> probably a mistake, as it makes it nearly impossible to augment the
> namespace, but it is the reality.

For some reason totally beyond my comprehension // inside a file name is
taken to be the same as /, but if it wasn't it could be the stream
separator.  *sigh*

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

[Thunder from the hill]

Chris Wedgwood wrote:
> Kmail works fine.
Hmmm. Would be great, but could you get working beyond some proxy? I
couldn't, and so I have to use Netscape, since pine doesn't really
support proxies, too. Same with MS Outlook, which is - o horror - also
avariable for Linux (in one package with MS Internet Exploder)!
If there is a way, please tell me!

Thunder
---
I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard god...


-
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: make mrproper

[Thunder from the hill]

Ville Herva wrote:
> 
> On Thu, Jan 25, 2001 at 09:00:26AM -0500, you [James Lewis Nance] claimed:
> >
> > ( mrproper == Mr. Proper )
> >
> > I saw a post from Linus once about this.  It is Finnish for "Mr. Clean".
> 
> Just to be sure: 'proper' does not mean anything in Finnish (nor Swedish
> for that matter AFAIK) it just the European(?) product name for 'Mr
> Clean'. Possibly it's from German ('proper' = 'clean').
I wouldn't call all clean things proper, and I would really not call all
proper things clean. That's one thing I learned in europe.

Thunder
---
I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard god...

-
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: [UPDATE] Zerocopy patches, against 2.4.1-pre10

[kuznet]

Hello!

> Starfire card does, maybe the 3com is different. :-)

3com _is_ different. 8)

I is not an issue, we do not make zerocopy on IP fragments.


> Are we even bothering with the partial checksums at this point, or
> are we falling back to CPU checksumming if the packet is fragmented?

Of course, we are not bothering.



> And, on a related note: what's involved in making a driver
> zerocopy-aware? I haven't looked too closely to the current patch,
> but I was thinking of playing with the starfire driver, since I
> have all the chipset docs..

Nothing especially clever. Gather plus checksumming, as described
in comment in linux/netdevice.h. Well, just look into one of existing
drivers: better, sunhme. 3com and acenic are too stupid to learn something.

Alexey
-
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: fat32 corruption with 2.4.0

[Nathan Walp]

Heikki Lindholm wrote:
> 
> Hello,
> I haven't seen much vfat/fat32 complaints lately, so:
> 2.4.0 destroyed my windows partition. There seemed to be some trouble in
> 2.4.0-test9, too. I don't know if this was a known problem or not, but
> 2.4.0-test9 wrote filenames in a wrong way. It could be observed by
> running windows (98 in my case) file system checker (not scandisk, but the
> graphical one) after copying some files with non-8.3 names to a fat32
> partition. There was no noticable data loss, however.
> 
> Yesterday, with 2.4.0 release kernel, mounting a fat32 filesystem caused
> data loss. The filesystem seemed to mount ok at a first glance, but
> reported falsely 100% space usage. Then, after unmounting it, the oldest
> (probably at start of the partition) directories "windows" and "my
> documents" were mangled beyond recognition. I think, in this case, the
> filenames got written REALLY wrong and showed as something like
> "?   * ~ ?. ?  ?". Running scandisk caused most directories and files
> in root directory to change to FILE0xxx.CHK and DIR0xxx.CHK. Most of the
> data was intact, however - and subdirectories below DIR0xxx.CHK's were
> good, too. I had VIA (868B) UDMA enabled, but don't think that was the
> cause since it worked fine with ext2 partitions.
> 
> In addition, trying to write to vfat /floppy with 2.4.0 also didn't
> work. Kernel complained about (bad?) sectors. Whereas 2.2.0 did the job
> fine (obviously, to the same floppy).
> 

I just got through rebuilding my system (messy partition table, and
windoze wouldn't install w/o blowing away everything).  To backup, I
tarred everything up, and put it on a big vfat drive I share between win
and linux.  I also burnt a CD w/ those backup tars.  Being the moron
that I am, I didn't test the tars, and I got burned.  They got
corrupted.  At first I blamed the windows install scandisk that found
some errors on that huge drive, but then i realized that I had burnt the
backup CD before windows ever touched that drive.  So, the files must
have gotten corrupted as they were written to the vfat drive, or in the
5 minutes it took me to find my spindle ;-)  

This was under either kernel 2.4.0-ac10, or 2.4.1-pre10.  I honestly
don't remember which I was in at the time.  If you can fix a crc-messy
.tar.gz, I can find out for you ;-)

Nathan
-
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: [UPDATE] Zerocopy patches, against 2.4.1-pre10

[Ion Badulescu]

On Thu, 25 Jan 2001 22:29:14 +0300 (MSK), [EMAIL PROTECTED] wrote:
> Hello!
> 
>> no problems.  I simply mounted an NFS server with rsize=wsize=8192
>> and read a few files - I assume this is sufficient?
> 
> This is orthogonal.
> 
> Only TCP uses this and you need not to do something special
> to test it. Any TCP connection going through 3c tests it.

Well, yes and no. It's not quite orthogonal, because normally TCP
will never transmit fragmented packets, and it's precisely fragmented
packets that make the interesting case with a card that supports
hardware TCP/UDP checksums.

If the packets are not fragmented, then the card can just verify the
checksums and be done with it. However, with fragments, all it can
do is report a partial checksum to the driver and let the driver
(or the stack) combine those partial checksums into one complete
checksum once all fragments have arrived. At least that's what the
Starfire card does, maybe the 3com is different. :-)

Are we even bothering with the partial checksums at this point, or
are we falling back to CPU checksumming if the packet is fragmented?

And, on a related note: what's involved in making a driver
zerocopy-aware? I haven't looked too closely to the current patch,
but I was thinking of playing with the starfire driver, since I
have all the chipset docs..

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
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: vfat <-> vfat copying of ~700MB file, so slow!

[Gábor Lénárt]

On Thu, Jan 25, 2001 at 11:56:35AM -0700, Thunder from the hill wrote:
> Arkadiusz Miskiewicz wrote:
> > 
> > On/Dnia Wed, Jan 24, 2001 at 12:23:03PM -0600, Brad Felmey wrote/napisa?(a)
> > > > I/O support  =  0 (default 16-bit)
> > >
> > > hdparm -c1 /dev/hda, or are you running in 16-bit mode on purpose?
> > no purpose. Setting this can only speed up all operations a bit but it doesn't
> > change nothing in vfat <-> vfat copying. It still slows down while copying.
> I noticed the kernel to increase cache and let the buffers break down during long 
>file copies, it seems like this is the wrong way if only copying one large file. This 
>also happens on SMB connections. I don't know if this info is useful.

Hmmm, imho this is a more general problem. Of course kernel does not know
if this is a single copy or data should be cached since it will be used
frequently in the near future. I don't know kernel internals very well
but I think cache is block cache. On higher layer (fs) it would be possible
to check out that we simply read blocks of file linear (which means
something like you mentioned especially on big files). I met similar
problems when I copy a harddisk to another (same type), with simple dd'ing
/dev/hda to /dev/hdb. Even with 192Mbs of RAM, the system goes down to
a very uninteractive state :( This copy task may be implemented on raw devices
to avoid caching nowdays. Please correct me, because these are only feelings
or what :)

-- 
 --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]--[ [EMAIL PROTECTED] ]--
 U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
 ---[ +36 30 2270823 ]--> LGB <-[ Linux/UNIX/8bit 4ever ]-
-
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: eepro100 problems in 2.4.0

[Sergey Kubushin]

On Thu, 25 Jan 2001, Micah Gorrell wrote:

I have it too. Kernel spits a lot of "eepro100: wait_for_cmd_done timeout!"
and network doesn't work. 2.2 is fine. This behaviour is not persistent,
sometimes the eepro100 module is loaded without such an error and works fine
then.

The eepro100 in question is the built-in one based on 82559 chip.


> I have doing some testing with kernel 2.4 and I have had constant
> problems
> with the eepro100 driver.  Under 2.2 it works perfectly but under 2.4 I
> am
> unable to use more than one card in a server and when I do use one card
> I
> get errors stating that eth0 reports no recources.  Has anyone else
> seen
> this kind of problem?
>
> Micah
> ___
> The irony is that Bill Gates claims to be making a stable operating
> system
> and Linus Torvalds claims to be trying to take over the world
>
> -
> 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/
>
>

---
Sergey Kubushin Sr. Unix Administrator
CyberBills, Inc.Phone:  702-567-8857
874 American Pacific Dr,Fax:702-567-8890
Henderson, NV, 89014

-
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] make drivers/scsi/sym53c8xx.c check request_region's return code (241p9)]

[Rasmus Andersen]

Hi.

I apparently forgot to cc the lists on this one. Replies should be cc'ed
to [EMAIL PROTECTED] also.

Thanks.

- Forwarded message from Rasmus Andersen <[EMAIL PROTECTED]> -

Date: Tue, 23 Jan 2001 23:37:14 +0100
From: Rasmus Andersen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [PATCH] make drivers/scsi/sym53c8xx.c check request_region's return code 
(241p9)
User-Agent: Mutt/1.2.4i

Hi.

The following patch makes drivers/scsi/sym53c8xx.c check the return
code of request_region. It applies cleanly against ac10 and 241p9.

Please comment.



--- linux-ac10-clean/drivers/scsi/sym53c8xx.c   Mon Jan  1 19:23:21 2001
+++ linux-ac10/drivers/scsi/sym53c8xx.c Sun Jan 21 21:40:54 2001
@@ -5817,7 +5817,11 @@
*/
 
if (device->slot.io_port) {
-   request_region(device->slot.io_port, np->base_ws, NAME53C8XX);
+   if (!request_region(device->slot.io_port, np->base_ws, 
+   NAME53C8XX)) {
+   printk(KERN_ERR "Cannot mmap IO range.\n");
+   goto attach_error;
+   }
np->base_io = device->slot.io_port;
}

--- linux-ac10-clean/drivers/scsi/sym53c8xx_comm.h  Mon Oct 16 21:56:50 2000
+++ linux-ac10/drivers/scsi/sym53c8xx_comm.hMon Jan 22 21:56:46 2001
@@ -1799,7 +1799,8 @@
**Get access to chip IO registers
*/
 #ifdef NCR_IOMAPPED
-   request_region(devp->slot.io_port, 128, NAME53C8XX);
+   if (!request_region(devp->slot.io_port, 128, NAME53C8XX))
+   return;
devp->slot.base_io = devp->slot.io_port;
 #else
devp->slot.reg = (struct ncr_reg *) remap_pci_mem(devp->slot.base, 128);


-- 
Regards,
Rasmus([EMAIL PROTECTED])

It isn't pollution that's harming the environment. It's the impurities in
our air and water that are doing it.  -Former U.S. Vice-President Dan
Quayle

- End forwarded message -

-- 
Regards,
Rasmus([EMAIL PROTECTED])

Freedom of the press is limited to those who own one.
 - A.J. Liebling 
-
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/