lots of reset_xmit_timer message log

[rtviado]

Hello kernel gurus,

updating to 2.4.0 final i get a lot of this in my logs

reset_xmit_timer sk=c07929a0 1 when=0x3c61, caller=c01b68c5
reset_xmit_timer sk=c85d8360 1 when=0x3c87, caller=c01b68c5
reset_xmit_timer sk=c29309a0 1 when=0x3ce7, caller=c01b68c5
sending pkt_too_big to self

I think this is related to ne2k-pci driver.



-- 
Rodel


-
To unsubscribe from this list: send 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: khttpd beats boa with persistent patch

[dean gaudet]

a few comments...

- localhost is a meaningless benchmark.  it's useful to catch some low
hanging fruit, but it really doesn't help in the long run.

- contrast the max connection times between kHTTPd and Boa.  if that 9
second maximum for kHTTPd is any indication of its latency performance on
a real network benchmark then... it kind of sucks hard.

latency is as important, or even more important than raw throughput.
anything beyond a second or two is the point where humans start giving up
on the server.  if you study a real benchmark such as specweb99 you'll
find that if you don't have good response latency then your score is not
valid.  they actually have a minimum throughput that each connection must
meet or else it's considered an error -- it's similar to having a latency
budget, with some slight differences.

anyhow a real network benchmark might show that kHTTPd latency is actually
not as broken as this one indicates.  i'd however really hesitate to call
this a win.

btw is your CPU slow or something?  'cause istr getting numbers at least
this good from apache across localhost several years ago even under
2.0.x... and boa and khttpd should both beat apache in this.

-dean

On Fri, 12 Jan 2001, Christoph Lameter wrote:

> I applied the persistent khttpd patch + my vhost patch and now khttpd
> beats boa!!! (patch against 2.4.0 follows at the end of the message)
>
> The connection times of boa are still better but khttpd wins in transfers.
>
> Re: TUX: Way WAAAYYY too much overkill.
>
> clameter@melchi:~$ ./zb localhost /index.html -k -c 215 -n 2
>
> ---
> Server: kHTTPd/0.1.6
> Doucment Length:1666
> Concurency Level:   215
> Time taken for tests:   17.486 seconds
> Complete requests:  2
> Failed requests:0
> Keep-Alive requests:20097
> Bytes transfered:   37400517
> HTML transfered:33481602
> Requests per seconds:   1143.77
> Transfer rate:  2138.88 kb/s
>
> Connnection Times (ms)
>min   avg   max
> Connect: 028  9313
> Total:  20   185  9607
> ---
>
> clameter@melchi:~$ ./zb localhost /index.html -k -c 215 -n 2 -p 6000
>
> ---
> Server: Boa/0.94.8.3
> Doucment Length:1666
> Concurency Level:   215
> Time taken for tests:   33.865 seconds
> Complete requests:  2
> Failed requests:0
> Keep-Alive requests:20001
> Bytes transfered:   37882109
> HTML transfered:33321666
> Requests per seconds:   590.58
> Transfer rate:  1118.62 kb/s
>
> Connnection Times (ms)
>min   avg   max
> Connect: 0 2   346
> Total: 258   360   485
> ---

-
To unsubscribe from this list: send 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 boot failure on Micronic W6Li

[Isaac Connor]

2.4.0 doesn't seem to want to boot on my W6Li with two PPRO 150's.  
THis machine has no problems with 2.2 kernels, and is currently running
2.2.17.

It uncompresses, and prints that it is booting, then locks hard.  Must
reset.

I have tried the noapic option, with no effect.

I have searched for information on this problem, but I can't seem to find
anything.  I guess no one else is having this problem ona W6Li.

Please help.

Isaac Connor
[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: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

On 12 Jan 2001, Linus Torvalds wrote:

> In article <[EMAIL PROTECTED]>,
> Andre Hedrick  <[EMAIL PROTECTED]> wrote:
> >
> >Well that "experimental patch" is designed to get out of the dreaded
> >"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the
> >Intel 440*X Chipset groups.  Since it appears that their bug was copied
> >but other chipset makers..you see the picture clearly, right?
> 
> No.

Oh, then I need to explainbut later.

> That experimental patch is _experimental_, and has not been reported by
> anybody to fix anything at all.  Also, the DMA timeout on PIIX4 seems to
> have nothing at all to do with the very silent corruption on VIA. At
> least nobody has reported any error messages being produced on the VIA
> corruption cases.

Yes corruption verses deadlock that can wack superblockhummm
Two evils, mame or kill one or leave both active...

> In short, let's leave it out of a stable kernel for now, and add
> blacklisting of auto-DMA. Alan has a list. We can play around with
> trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport
> the thing once it has been sufficiently battletested that people believe
> it truly will work).

Linus we are talking about blacklisting every PIIX4 that is 440BX/GX/LX/NX 
in this case and that is a major list.  VIA has its own problems and that
need special cases attention by one person work on always, thus the
poor^H^H^H^H bold sucker^H^H^H^H^H^H guy known as Vojtech Pavlik from SuSE
is having to much fun

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: Updated zerocopy patch up on kernel.org

[Anton Blanchard]

 
> > Nothing interesting or new, just merges up with the latest 2.4.1-pre1
> > patch from Linus.
> >
> > ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p1-1.diff.gz
> >
> > I haven't had any reports from anyone, which must mean that it is
> > working perfectly fine and adds no new bugs, testers are thus in
> > nirvana and thus have nothing to report.  :-)
> 
> (works like a charm here.)

Likewise here running a sendfile hacked samba :)

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/

khttpd beats boa with persistent patch

[Christoph Lameter]

I applied the persistent khttpd patch + my vhost patch and now khttpd
beats boa!!! (patch against 2.4.0 follows at the end of the message)

The connection times of boa are still better but khttpd wins in transfers.

Re: TUX: Way WAAAYYY too much overkill.

clameter@melchi:~$ ./zb localhost /index.html -k -c 215 -n 2
 
---
Server: kHTTPd/0.1.6
Doucment Length:1666
Concurency Level:   215
Time taken for tests:   17.486 seconds
Complete requests:  2
Failed requests:0
Keep-Alive requests:20097
Bytes transfered:   37400517
HTML transfered:33481602
Requests per seconds:   1143.77
Transfer rate:  2138.88 kb/s
 
Connnection Times (ms)
   min   avg   max
Connect: 028  9313
Total:  20   185  9607
---

clameter@melchi:~$ ./zb localhost /index.html -k -c 215 -n 2 -p 6000
 
---
Server: Boa/0.94.8.3
Doucment Length:1666
Concurency Level:   215
Time taken for tests:   33.865 seconds
Complete requests:  2
Failed requests:0
Keep-Alive requests:20001
Bytes transfered:   37882109
HTML transfered:33321666
Requests per seconds:   590.58
Transfer rate:  1118.62 kb/s
 
Connnection Times (ms)
   min   avg   max
Connect: 0 2   346
Total: 258   360   485
---

diff -urN linux-orig/net/khttpd/accept.c linux/net/khttpd/accept.c
--- linux-orig/net/khttpd/accept.c  Sat Jan 22 11:54:58 2000
+++ linux/net/khttpd/accept.c   Fri Jan 12 21:19:55 2001
@@ -107,6 +107,7 @@
memset(NewRequest,0,sizeof(struct http_request));  

NewRequest->sock = NewSock;
+   NewRequest->LastActive = jiffies;

NewRequest->Next = threadinfo[CPUNR].WaitForHeaderQueue;

diff -urN linux-orig/net/khttpd/logging.c linux/net/khttpd/logging.c
--- linux-orig/net/khttpd/logging.c Wed Aug 18 09:45:10 1999
+++ linux/net/khttpd/logging.c  Fri Jan 12 21:27:05 2001
@@ -29,6 +29,8 @@
 #include 
 #include "structure.h"
 #include "prototypes.h"
+#include "sysctl.h"
+
 
 /*
 
@@ -58,9 +60,22 @@
while (CurrentRequest!=NULL)
{
 
+   CurrentRequest->ReqCount++; 
+   CurrentRequest->LastActive = jiffies;
+
+   if (sysctl_khttpd_logging) {
+   CurrentRequest->FileName[CurrentRequest->FileNameLength]=0;
+   printk(KERN_NOTICE "File=%s Host=%s Length=%d 
+Userspace=%d\n",CurrentRequest->FileName,CurrentRequest->Host,CurrentRequest->FileLength,CurrentRequest->IsForUserspace);
+   }
Req = CurrentRequest->Next;
 
-   CleanUpRequest(CurrentRequest);
+   if (CurrentRequest->Persistent) {
+   sanitize_request(CurrentRequest);
+   CurrentRequest->Next = threadinfo[CPUNR].WaitForHeaderQueue;
+   threadinfo[CPUNR].WaitForHeaderQueue = CurrentRequest;
+   }
+   else
+   CleanUpRequest(CurrentRequest);

threadinfo[CPUNR].LoggingQueue = Req;

diff -urN linux-orig/net/khttpd/misc.c linux/net/khttpd/misc.c
--- linux-orig/net/khttpd/misc.cThu Sep  2 11:47:20 1999
+++ linux/net/khttpd/misc.c Fri Jan 12 21:19:55 2001
@@ -132,6 +132,89 @@
LeaveFunction("CleanUpRequest");
 }
 
+static char Buffer[1024];
+
+static void DummyRead(struct socket *sock, int Size)
+{
+   struct msghdr   msg;
+   struct ioveciov;
+   int len,totalbytes=0;
+
+   mm_segment_toldfs;
+   
+   
+   EnterFunction("DummyRead");
+   
+   
+   if (sock->sk==NULL)
+   return;
+
+   len = 1;
+   
+   totalbytes = 0;
+   
+   while ((len>0)&&(totalbytesiov_base = [0];
+   msg.msg_iov->iov_len  = (__kernel_size_t)max(1024,Size-totalbytes);
+   
+   len = 0;
+   oldfs = get_fs(); set_fs(KERNEL_DS);
+   len = sock_recvmsg(sock,,1024,MSG_DONTWAIT);
+   set_fs(oldfs);
+   if (len>0)
+   totalbytes+=len;
+   }
+   LeaveFunction("DummyRead");
+}
+
+
+
+/*
+sanitize_request
+@request: the request to clean
+
+sanitize_requests cleans all URL specific parts of a request, while
+saving the connection specific parts in order to do persistent connections.
+  
+*/
+void sanitize_request(struct http_request *request)
+{
+   EnterFunction("sanitize_request");
+   /* Close the file-pointer */
+   if (request->filp!=NULL)
+   {
+   fput(request->filp);
+   request->filp = NULL;
+   }
+   
+   DummyRead(request->sock,request->Headersize);
+
+   request->FileLength = 0;
+   request->Time = 0;
+   request->BytesSent = 0;
+   request->FileName[0]=0;
+   

[PATCH] CPP ## string concatination is for the token

[NIIBE Yutaka]

I think that `##' operator for string concatination produces the token.

In pci.h, we have bogus `##' operator which doesn't produce valid
token.  We don't need (must not) have ## between `s' and the open
paren.

Here's the patch.
 
diff -ruN v2.4.1-pre3/include/linux/pci.h linux/include/linux/pci.h
--- v2.4.1-pre3/include/linux/pci.h Fri Jan  5 07:51:32 2001
+++ linux/include/linux/pci.h   Mon Jan  8 17:36:44 2001
@@ -565,9 +565,9 @@
 {  return PCIBIOS_DEVICE_NOT_FOUND; }
 
 #define _PCI_NOP(o,s,t) \
-   static inline int pcibios_##o##_config_##s## (u8 bus, u8 dfn, u8 where, t val) 
\
+   static inline int pcibios_##o##_config_##s (u8 bus, u8 dfn, u8 where, t val) \
{ return PCIBIOS_FUNC_NOT_SUPPORTED; } \
-   static inline int pci_##o##_config_##s## (struct pci_dev *dev, int where, t 
val) \
+   static inline int pci_##o##_config_##s (struct pci_dev *dev, int where, t val) 
+\
{ return PCIBIOS_FUNC_NOT_SUPPORTED; }
 #define _PCI_NOP_ALL(o,x)  _PCI_NOP(o,byte,u8 x) \
_PCI_NOP(o,word,u16 x) \
-- 
-
To unsubscribe from this list: send 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 2.4.0: dd if=/dev/random of=out.txt bs=10000 count=100

[Rob Landley]

--- David Ford <[EMAIL PROTECTED]> wrote:
> Rob Landley wrote:
> 
> > If I do the dd line in the title under 2.4.0 I get
> an
> > out.txt file of 591 bytes.
> 
> It isn't broken, you have no more entropy.  You must
> have some system
> activity of various sorts before you regain some
> entropy.  Moving the mouse
> around, hitting keys, etc, will slowly add more
> entropy.
> 
> -d

I'd wondered what urandom was for.  Thanks.

Rob


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

2.4.0+reiserfs+lvm oops

[hugang]

hello all.
-
ksymoops 2.3.4 on i686 2.4.0-prerelease.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-prerelease/ (default)
 -m /usr/src/linux/System.map (default)

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

Unable to handle kernel paging request at virtual address 702d3042
c4919998
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010213
eax: 702d302e   ebx: c28afc68   ecx: ffe4   edx: 
esi: c060a000   edi: c060a07c   ebp: 0004   esp: c28afb68
ds: 0018   es: 0018   ss: 0018
Process tar (pid: 954, stackpage=c28af000)
Stack: c060a000 c060a07c  ffe4 0060  c3df38a0 c1d02018 
   c28afc68 03b0   c491bc33 c28afc68  c28afc68 
    c28afc68  c060a000   c28afc68 0130 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] 
Code: 8b 40 14 ff d0 89 c2 8b 06 83 c4 10 01 c2 89 16 8b 83 8c 01 

>>EIP; c4919998 <[reiserfs]create_virtual_node+298/490>   <=
Trace; c491bc33 <[reiserfs]dc_check_balance_leaf+53/150>
Trace; c491c555 <[reiserfs]fix_nodes+115/450>
Trace; c4925dec <[reiserfs]reiserfs_cut_from_item+1fc/430>
Trace; c4934930 <[reiserfs]reiserfs_mounted_fs_count+0/4>
Trace; c49263ae <[reiserfs]reiserfs_do_truncate+32e/470>
Trace; c4947044 <.data.end+128d/???
Trace; c49182d4 <[reiserfs]reiserfs_truncate_file+b4/1a0>
Trace; c492f244 <[reiserfs].rodata.start+1184/654e>
Trace; c493382f <[reiserfs].rodata.start+576f/654e>
Trace; c4919011 <[reiserfs]reiserfs_file_release+1b1/320>
Trace; c491915c <[reiserfs]reiserfs_file_release+2fc/320>
Trace; c492f384 <[reiserfs].rodata.start+12c4/654e>
Trace; c493382f <[reiserfs].rodata.start+576f/654e>
Trace; c0130456 
Trace; c012f5b5 
Trace; c012f603 
Trace; c0108f47 
Trace; c010002b 
Code;  c4919998 <[reiserfs]create_virtual_node+298/490>
 <_EIP>:
Code;  c4919998 <[reiserfs]create_virtual_node+298/490>   <=
   0:   8b 40 14  mov0x14(%eax),%eax   <=
Code;  c491999b <[reiserfs]create_virtual_node+29b/490>
   3:   ff d0 call   *%eax
Code;  c491999d <[reiserfs]create_virtual_node+29d/490>
   5:   89 c2 mov%eax,%edx
Code;  c491999f <[reiserfs]create_virtual_node+29f/490>
   7:   8b 06 mov(%esi),%eax
Code;  c49199a1 <[reiserfs]create_virtual_node+2a1/490>
   9:   83 c4 10  add$0x10,%esp
Code;  c49199a4 <[reiserfs]create_virtual_node+2a4/490>
   c:   01 c2 add%eax,%edx.
Code;  c49199a6 <[reiserfs]create_virtual_node+2a6/490>
   e:   89 16 mov%edx,(%esi)
Code;  c49199a8 <[reiserfs]create_virtual_node+2a8/490>
  10:   8b 83 8c 01 00 00 mov0x18c(%ebx),%eax


1 warning issued.  Results may not be reliable.

---
I thinks the bug in fs/reiserfs/fix_node.c,line 181. 
-
To unsubscribe from this list: send 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: Raw devices ?

[Meino Christian Cramer]

Hi,

 short question: How cabn I activate/where can I find the raw devices
 often described as /dev/raw[12]* in/with kernel linux-2.4.0.

 And where can I find the "raw" utility...
 
 Thank you very much in advance for any help!

 Kind regards,
 Meino Cramer

-
To unsubscribe from this list: send 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 2.4.0: dd if=/dev/random of=out.txt bs=10000 count=100

[John Heffner]

> dd says it completes happily even when copying from
> random.  0+100 records in, 0+100 records out.  It

This means that dd completed 100 reads, and none of them were of the
requested length (1 bytes).

> takes about thirty seconds to finish on the dual
> gigahertz processor intel box I'm using to test it,
> which implies it's actually performing the truly
> impressive waste of CPU cycles I'm requesting from it.
>  I'm just not getting the data in my file.

/dev/random generates (hopefully) truly random values, and relies on
receiving interrupts.  It doesn't spend very many CPU cycles.  For most
purposes, /dev/urandom is adequate, and will be much faster for such large
quantities of data.

  -John

-
To unsubscribe from this list: send 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 2.4.0: dd if=/dev/random of=out.txt bs=10000 count=100

[David Ford]

Rob Landley wrote:

> If I do the dd line in the title under 2.4.0 I get an
> out.txt file of 591 bytes.

It isn't broken, you have no more entropy.  You must have some system
activity of various sorts before you regain some entropy.  Moving the mouse
around, hitting keys, etc, will slowly add more entropy.

-d


-- ---NOTICE

-- fwd: fwd: fwd: type emails will be deleted automatically.
  "There is a natural aristocracy among men. The grounds of this are
  virtue and talents", Thomas Jefferson [1742-1826], 3rd US President



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

BUG in 2.4.0: dd if=/dev/random of=out.txt bs=10000 count=100

[Rob Landley]

If I do the dd line in the title under 2.4.0 I get an
out.txt file of 591 bytes.

If I do the same thing from /dev/zero, I get the
expected 1,000,000 byte file.

I've shoehorned 2.4.0 into a fresh red hat 7.0 install
which could quite easily be a bad thing, yes ripped
out their strange gcc and symlinked kgcc->gcc to do
the compile.  But other than this it seems to be
working.  (So far...)

dd says it completes happily even when copying from
random.  0+100 records in, 0+100 records out.  It
takes about thirty seconds to finish on the dual
gigahertz processor intel box I'm using to test it,
which implies it's actually performing the truly
impressive waste of CPU cycles I'm requesting from it.
 I'm just not getting the data in my file.

Am I doing something wrong?

My dd is from fileutils-4.0x-3.  (Straight Red Hat
7.0, I think...)  Didn't see anything about that in
Documentation/Changes...

I'll be happy to try one of the prepatches if anybody
thinks they've addressed this problem already.

Anybody?  Need more debugging info?  Want me to wave a
dead chicken at something specific?  Stick printk's
into the kernel?...

Rob

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

sparc10 with 512M of RAM hangs on boot

[Ron Calderon]

every kernel after 2.4.0-test5 hangs my sparc10
at the same spot. Has anyone looked into this?
here is screen output:

SPARCstation 10  (1 X 390Z50), No Keyboard
ROM Rev. 2.12, 512 MB memory installed, Serial
#6299671.
Ethernet address 

Boot device: /iommu/sbus/espdma/esp/sd@3,0:c   File
and args: 
SILO boot: 
Uncompressing image...
PROMLIB: obio_ranges 5
bootmem_init: Scan sp_banks, 
init_bootmem(spfn[121],bpfn[121],mlpfn[c000])
free_bootmem: base[0] size[c00]
reserve_bootmem: base[0] size[121000]
reserve_bootmem: base[121000] size[1800]

the last kernel I tried was cvs'ed from vger last
night. I beleive it was 2.4.1-pre2.

ron

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

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Andrew Morton]

Linus Torvalds wrote:
> 
> I'm also nervous about the complete lack of locking in vortex_timer():
> disabling interrupts doesn't mean that transmits couldn't be
> pending. But maybe the hardware is ok with changing status concurrently.
> 

mm..  It's a little racy wrt vortex_ioctl(), but otherwise OK.
del_timer_sync() in vortex_ioctl() seems to be needed.

disable_irq() is very useful in functions such as this.  It
would be a shame to have to stop using it.
-
To unsubscribe from this list: send 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: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Anton Blanchard]

 
Hi,

> What is the reason for all this?  Alignment/wordsize/other?  If you look
> at the IOP10 code, much of the in-core data structs were changed to int
> or long, so this sparc code may not be necessary.  It may in fact be
> damaging, because I don't know if any of the LVM developers even know it
> is there, and surely it will be out of sync...

Two things:

Structures used in ioctls should have explicit sizes (eg u32, not unsigned
long). Remember on sparc64 we have a 32 bit userspace and 64 bit kernel.

Having pointers to other structures is considered bad form again due to the
32bit/64bit differences. Think 32 bit pointers vs 64 bit pointers :)

When either of these happen we have to write up translation code. Of
the two, having pointers to other structs is definitely the worst. 

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: ide.2.4.1-p3.01112001.patch

[Tkil]

Alan asked:
> I think its significant that two reports I have are FIC PA-2013 but
> not all.  What combination of chips is on the 2013 ?

My board here is a FIC PA-2013A (if I recall correctly; the
motherboard only has "PA-2013" on it, no "A") rev 1.1.

It's worth noting that there is at least another full revision level
(2.x), and the BIOSes for these different revisions are *not*
compatible (as I found out to my chagrin ;-).

Also, the FIC PA-513 (maybe 512?) should be a very similar board, only
wired for an AT power supply where the PA-2013 is an ATX board.

I've never seen the DMA data corruption on this box, but I'd really
really like to get something better than 3MB/s off my UDMA/66-capable
drives.  I'm pretty sure that (prior to the 2.2.18 squelching of all
VIA IDE UDMA) that hda and hdc would come up with DMA enabled, at the
very least.  Is there a safe way to test various hdparm settings?  I'm 
even willing to buy a scratch disk if that would help...

Looking at the chips, I have:

1. VIA
   VT82C598MVP
   9828CE Taiwan
   13G003900

2. VIA
   VT82C586B
   S7-SB
   9826CD Taiwan
   14B013511

It has an Award BIOS with a variety of WinBond support chips (looks
like at least 4 on-board cache chips, and one near the BIOS EEPROM).

Here's the relevant dmesg bits:

| PCI: PCI BIOS revision 2.10 entry at 0xfb490
| PCI: Using configuration type 1
| PCI: Probing PCI hardware
| PCI: 00:38 [1106/0586]: Work around ISA DMA hangs (00)
| Activating ISA DMA hang workarounds.
| Detected PS/2 Mouse Port.
| Serial driver version 4.27 with no serial options enabled
| ttyS00 at 0x03f8 (irq = 4) is a 16550A
| ttyS01 at 0x02f8 (irq = 3) is a 16550A
| Real Time Clock Driver v1.09
| VP_IDE: IDE controller on PCI bus 00 dev 39
| VP_IDE: not 100% native mode: will probe irqs later
| ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
| ide0: VIA Bus-Master (U)DMA Timing Config Success
| ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
| ide1: VIA Bus-Master (U)DMA Timing Config Success
| hda: WDC WD307AA, ATA DISK drive
| hdc: Maxtor 96147H8, ATA DISK drive
| ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
| ide1 at 0x170-0x177,0x376 on irq 15
| hda: WDC WD307AA, 29333MB w/2048kB Cache, CHS=59598/16/63
| hdc: Maxtor 96147H8, 58623MB w/2048kB Cache, CHS=7473/255/63
| Floppy drive(s): fd0 is 1.44M
| FDC 0 is a post-1991 82077
| Partition check:
|  sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
|  hda: [PTBL] [3739/255/63] hda1
|  hdc: hdc1
| apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)

Short version of lspci:

| 00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04)
| 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
| 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586 ISA [Apollo VP] (rev 41)
| 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
| 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02)
| 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
| 00:08.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03)
| 00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] 
|(rev 22)
| 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP [Millennium 
|G200 AGP] (rev 01)

I've included "hdparm" and "lspci -vvxxx" output below, omitting
non-chipset related things (SCSI, Ethernet, and VGA).  If it matters,
this board is running 100MHz FSB with a 450MHz K6-3 CPU and 384MB (3 x
128MB DIMMs) of PC-100 SDRAM.

If I can provide any more information, please don't hesitate to ask.

Thanks,
t.

hdparm output:

| # for i in hda hdc ; do hdparm /dev/$i ; hdparm -i /dev/$i ; done
| 
| /dev/hda:
|  multcount=  0 (off)
|  I/O support  =  0 (default 16-bit)
|  unmaskirq=  0 (off)
|  using_dma=  0 (off)
|  keepsettings =  0 (off)
|  nowerr   =  0 (off)
|  readonly =  0 (off)
|  readahead=  8 (on)
|  geometry = 3739/255/63, sectors = 60074784, start = 0
| 
| /dev/hda:
| 
|  Model=WDC WD307AA, FwRev=05.05B05, SerialNo=WD-WMA11
|  Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
|  RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
|  BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
|  DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
|  CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=60074784
|  tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2 
|  IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4 
| 
| 
| /dev/hdc:
|  multcount=  0 (off)
|  I/O support  =  0 (default 16-bit)
|  unmaskirq=  0 (off)
|  using_dma=  0 (off)
|  keepsettings =  0 (off)
|  nowerr   =  0 (off)
|  readonly =  0 (off)
|  readahead=  8 (on)
|  geometry = 7473/255/63, sectors = 120060864, start = 0
| 
| /dev/hdc:
| 
|  Model=Maxtor 96147H8, FwRev=BAC51KJ0, SerialNo=N80CP5KC
|  Config={ Fixed }
|  RawCHS=16383/16/63, TrkSize=0, 

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Linus Torvalds]

On Sat, 13 Jan 2001, Andrew Morton wrote:
> 
> 3c59x calls disable_irq() once per minute, and seems to be
> one of the most-affected drivers.

The ne2k thing seems to be the _most_ affected one, as far as I can tell.

However, it could easily be a matter of timing - for example, if the
driver does something to trigger an interrupt _just_ before (or after,
considering the asynchronous nature of writing to the IO-APIC) doing the
enable_irq(), then..

I'm also nervous about the complete lack of locking in vortex_timer():
disabling interrupts doesn't mean that transmits couldn't be
pending. But maybe the hardware is ok with changing status concurrently.

Linus

-
To unsubscribe from this list: send 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-audio-dev] low-latency scheduling patch for 2.4.0

[Jay Ts]

Andrew Morton wrote:
> 
> Jay Ts wrote:
> > 
> > Now about the only thing left is to get it included
> > in the standard kernel.  Do you think Linus Torvalds is more likely
> > to accept these patches than Ingo's?  I sure hope this one works out.
> 
> We (or "he") need to decide up-front that Linux is to become
> a low latency kernel. Then we need to decide the best way of
> doing that.
> 
> Making the kernel internally preemptive is probably the best way of
> doing this.  But it's a *big* task

Ouch.  Yes, I agree that the ideal path is for Linus and the other
kernel developers and ... well, just about everyone ... is to create
a long-range strategy and 'roadmap' that includes support for low-latency.

And making the kernel preemptive might be the best way to do that
(and I'm saying "might"...).

But all that can take years, if it happens at all, and we may have
a short-term approach that will satisfy almost everyone, at least for
now, and maybe even allow for the development and maybe even (?) commercial
distribution ("shrink wrap") of audio software for Linux.  (Er, assuming
that the ALSA drivers become the standard audio drivers.  Mustn't forget
that.)

As for actually desiring a preemptive kernel, I'm not a complete expert
in this area, but I will say that no one has ever managed to explain to
me why the extra complexity is vital, necessary, or just worth the 
bother.  Sure, it would help with the implementation and OS support of
the multithreaded and realtime code that I'm developing.  So far, I haven't
run into any major limitations yet related to lack of a preemtive kernel,
but maybe I will later. (?)

> I could propose a simple patch for 2.4 (say, the ten most-needed
> scheduling points).  This would get us down to maybe 5-10 milliesconds
> under heavy load (10-20x improvement).

5-10 ms wouldn't be great, but would at least be better than nothing.
It would be a good start, perhaps, especially if it were understood that
things will get better later on.  As with the development of SMP support
for Linux.

> That would probably be a great and sufficient improvement for [...]
> people who are only interested in audio record and playback - I'd need advice
> from the audio experts for that.

Well, call me an audio expert, then. :)  What sort of advice do you
want?  You can send your comments to the LAD (linux audio development)
mailing list, and there are a bunch of smart audio/music programmers
who I'm pretty sure will be happy to comment.

One thing I'd like to say is that simple recording and playback of audio
is hardly the complete picture!  Try recording and playback of *many*
channels of audio, while at the same time running multiple software
synthesizers and effects plugins, and recording and playing back MIDI
sequences.  And other things, too.  One thing I ask of anyone who's developing
Linux is to please think in an open-ended manner regarding audio/music.
This is really still a pretty new and immature field, and the software
(when the Real Stuff gets to Linux, that is) will be happy to absorb
whatever hardware resources are thrown at it for years to come.

> I hope that one or more of the desktop-oriented Linux distributors
> discover that hosing HTML out of gigE ports is not really the
> One True Appplication of Linux,

I agree approximately 110.111%. :)  Really, I find servers to be
pretty boring.  "Linux is supposed to be fun", right? :)

> > What's the prob with XF86 4.0?
>   [snipped longish explanation] 
> So,  we need to talk to the xfree team.
> 
> Whoops!  I accidentally Cc'ed them :-)

Thank you.  A low-latency kernel would be meaningless if the X server
creates delays of 20ms!  This just plain needs to be fixed.

- Jay Ts
[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: ide.2.4.1-p3.01112001.patch

[davej]

On Fri, 12 Jan 2001, Alan Cox wrote:

> |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks.  The
> |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is
> |1.2 GB.  Hdd is an IDE CDROM drive
>
> I think its significant that two reports I have are FIC PA-2013 but not all.
> What combination of chips is on the 2013 ?

The FIC PA-2013 is one of the stranger types of MVP3.
(A mixture of 82c597 host bridge and 82c598 PCI bridge).

As discussed some time ago on this list, there are some of these
boards, which initially seem to be an MVP3, but have the host bridge ID
set to an VP3. (Real reasoning behind this never figured out).

2.4 has code in the pci quirks to disable the register which makes
the chip masquerade as a VP3, and forces it to identify itself as
an MVP3 part.  I'm curious whether this has an interaction here.

I have a list of known 'hybrid' boards, and known true (both halves) MVP3
boards and also a collection of lspci -xxx outputs from a selection of
them. If anyone wants any of this stuff, shout and I'll put it up
for ftp/www.

I'm curious if all of the other boards in Alans bug reports also
fall into the stranger category.

regards,

Davej.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

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

Re: [eepro100] Ok, I'm fed up now

[Dragan Stancevic]

On Fri, Jan 12, 2001, Dan B <[EMAIL PROTECTED]> wrote:
; Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet?  What 
; about their e100-ANS driver that supports FEC 800mbps?

I don't think the intels driver is using pci_dma yet so it's
going to take a while before they port all that stuff over,
but than again that is just a guess, maybe they have stuff
done alredy it's just waiting for a new release.



-- 
I knew I was alone, I was scared, it was getting dark and
it was a hardware problem.

-Dragan
-
To unsubscribe from this list: send 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: 1.1 ideas

[Scott James Remnant]

Apologies for this.  I have absolutely no idea what happened, but
somehow I managed to post this to three groups when it was only
mean't for one.

*gets more coffee*

Scott
-- 
Scott James Remnant Have you ever, ever felt like this?  Had strange
http://netsplit.com/  things happen?  Are you going round the twist?
-
To unsubscribe from this list: send 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: NETDEV WATCHDOG: eth0: transmit timed out

[Darryl Miles]

I am getting complete lockups of the NIC, up/down the interface doesn't
restore it.  rmmod/insmod of ne2k-pci and 8390 doesn't restore it.  A
reboot does.

The m/c with this card in isn't normally highly loaded on the network,
but under heavy load it will lockup completely (fairly reliably I
suspect).  I have also had this problem with 2.4.0-test11, I had traced
it to ei_tx_intr() in so much as it was calling the
"ei_local->stat.collisions += 16;" line.  This is 8390.c:635 in 2.4.0.


The log below shows the time I had reloaded the modules trying to bring
it back to life.

Jan 13 01:46:24 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:46:24 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=951.
Jan 13 01:46:26 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:46:26 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=100.
Jan 13 01:47:14 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:47:14 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=106.
Jan 13 01:47:15 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:47:15 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=26.
Jan 13 01:47:17 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:47:17 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=105.
Jan 13 01:47:24 thehostname kernel: RPC: sendmsg returned error 101
Jan 13 01:47:24 thehostname kernel: nfs: RPC call returned error 101
Jan 13 01:47:24 thehostname kernel: nfs_statfs: statfs error = 101
Jan 13 01:47:37 thehostname kernel: ne2k-pci.c:v1.02 10/19/2000 D.
Becker/P. Gortmaker
Jan 13 01:47:37 thehostname kernel:  
http://www.scyld.com/network/ne2k-pci.html
Jan 13 01:47:37 thehostname kernel: eth0: RealTek RTL-8029 found at
0xe800, IRQ 19, 48:54:E8:21:15:56.
Jan 13 01:47:47 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:47:47 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=111.
Jan 13 01:47:58 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:47:58 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=1031.
Jan 13 01:48:00 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:48:00 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x1, ISR=0x3, t=107.
Jan 13 01:48:04 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:48:04 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=106.
Jan 13 01:48:08 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:48:08 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=306.
Jan 13 01:48:10 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:48:10 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x3, t=105.
Jan 13 01:48:24 thehostname kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Jan 13 01:48:24 thehostname kernel: eth0: Tx timed out, lost interrupt?
TSR=0x3, ISR=0x2, t=72.

$ uname -r
2.4.0


lsmod bits:

ne2k-pci4448   1  (autoclean)
83906544   0  (autoclean) [ne2k-pci]


/proc/pci:
  Bus  0, device  11, function  0:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
(rev 0).
  IRQ 19.
  I/O at 0xe800 [0xe81f].

-- 
Darryl Miles
-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Frank de Lange]

On Sat, Jan 13, 2001 at 02:51:54AM +0100, Manfred Spraul wrote:
> Frank de Lange wrote:
> > 
> > It could be that people using those cards are not the ones who tend
> > to go for the (somewhat tricky) BP6 board...
> > 
> 
> I doubt that it's BP6 specific: I have the problem with a Gigabyte BXD
> board and I doubt that Ingo used an BP6. Perhaps 82093AA specific (the
> IO APIC chip used for SMP 440BX board)

It isn't. But I just meant to indicate that the mere fact that I could not find
any problem-report for that combination does not indicate that there ARE no
problems...

> I can't find any spec updates for that chip: either it's the first
> perfect chip Intel ever produced, or ...

:-)

Well, the BX chipset is one of their better attempts I think...

Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

1.1 ideas

[Scott James Remnant]

It's not gonna be started on for a while yet, but if you've got any
ideas you wanna throw around, now's the time.

Scott
-- 
Scott James Remnant Have you ever, ever felt like this?  Had strange
http://netsplit.com/  things happen?  Are you going round the twist?
-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Andrew Morton]

Linus Torvalds wrote:
> 
> On Sat, 13 Jan 2001, Frank de Lange wrote:
> 
> > On Fri, Jan 12, 2001 at 04:36:33PM -0800, Linus Torvalds wrote:
> > > It may well not be disable_irq() that is buggy. In fact, there's good
> > > reason to believe that it's a hardware problem.
> >
> > I am inclined to believe it IS a hardware problem... If disable_irq were buggy,
> > wouldn't the problem occur more frequently in other irq-heavy areas? A quick
> > count shows that disable_irq* is used in 84 sourcefiles in the driver/*
> > directory. This includes drivers which generate many interrupts in a short
> > timeframe (like ide).
> 
> IDE is not my favourite example of a "known stable driver". Also, in many
> cases IDE is for historical reasons connected to an EDGE io-apic pin (ie
> it's still considered an ISA interrupt). Which probably wouldn't show this
> problem anyway.
> 

3c59x calls disable_irq() once per minute, and seems to be
one of the most-affected drivers.
-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Andrew Morton]

Alan Cox wrote:
> 
> > Could you disable both bandaids? I disabled them, no problems so far.
> > Now back to the disable_irq_nosync().
> 
> Ok so it looks like the disable_irq code is buggy. Unfortunately its not
> just used for these drivers they are just the heaviest users.
> 
> Given that we can see the IRQ is still set on the APIC can we fake an IRQ in
> that condition ?

As you think about this problem, please bear in mind that
this loss of APIC interrupts also occurs in 2.2 kernels.

Donald may have more details.

-
-
To unsubscribe from this list: send 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: can't build small enough zImage for floppy

[Jens Axboe]

On Fri, Jan 12 2001, Jordan wrote:
> 1st, the Sony Vaio Z505HS appears to be an example of a machine which
> will not boot a bzImage correctly, compaining about the compression
> format.

I have this exact model too, and it boots bzImage just fine. In fact,
I've never booted anything but bzImage's on it. Maybe a BIOS issue
that a fw upgrade will fix?

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* 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: [eepro100] Ok, I'm fed up now

[George R . Kasica]

I'm using the following and its been flawless under 2.4x:

eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/driv
ers/eepro100.html
eepro100.c: $Revision: 1.35 $ 2000/11/17 Modified by Andrey V.
Savochkin  and others
PCI: Found IRQ 11 for device 00:0b.0
eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:02:B3:1C:53:67,
IRQ 11.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 721383-016, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).


>Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet?  What 
>about their e100-ANS driver that supports FEC 800mbps?

George

===[George R. Kasica]===+1 262 513 8503
President   +1 206 374 6482 FAX 
Netwrx Consulting Inc.  Waukesha, WI USA 
http://www.netwrx1.com
[EMAIL PROTECTED]
ICQ #12862186
-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Manfred Spraul]

Frank de Lange wrote:
> 
> It could be that people using those cards are not the ones who tend
> to go for the (somewhat tricky) BP6 board...
> 

I doubt that it's BP6 specific: I have the problem with a Gigabyte BXD
board and I doubt that Ingo used an BP6. Perhaps 82093AA specific (the
IO APIC chip used for SMP 440BX board)

I can't find any spec updates for that chip: either it's the first
perfect chip Intel ever produced, or ...

--
Manfred
-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Jens Axboe]

On Fri, Jan 12 2001, Linus Torvalds wrote:
> [...] With disks it is very hard
> to get the same kind of irq load - Linux will merge the requests and do at
> least 1kB worth of transfer per interrupt etc. On a ne2k 100Mbps PCI card,

Actually, without mult count you will do only 512b of I/O per interrupt
on IDE. Regardless of merging etc. Still doesn't reach nic levels, but
it's _bad_ anyway :-)

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* 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: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> 
> 
> On Fri, 12 Jan 2001, Andre Hedrick wrote:
> > 
> > It works perfectly and exactly as it is defined to work by the rules.
> > Getting the rules correct == 'the concept of "working"'.
> 
> Don't be silly.
> 
> You're entirely ignoring the concept of hardware bugs. Which is one very
> likely reason for this whole discussion in the first place.

First you get the access correct and assume no bugs, round one.
After this is fixed, then you address the "hardware bugs" by execption
rules and not the basic premis, the endless round.

Regards,

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: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> 
> 
> On Fri, 12 Jan 2001, Andre Hedrick wrote:
> > 
> > It works perfectly and exactly as it is defined to work by the rules.
> > Getting the rules correct == 'the concept of "working"'.
> 
> Don't be silly.
> 
> You're entirely ignoring the concept of hardware bugs. Which is one very
> likely reason for this whole discussion in the first place.
> 
> ANYBODY who does driver development without taking the real world into
> account is a dangerous person. Stacks of papers, diagrams and rules are
> absolutely WORTHLESS if you can't just understand the fact that
> documentation is nothing more than a guide-line.
> 
> Once you realize that documentation should be laughed at, peed upon, put
> on fire, and just ridiculed in general, THEN, and only then, have you
> reached the level where you can safely read it and try to use it to
> actually implement a driver.
> 
> I'm continually amazed and absolutely scared silly by your blind trust in
> paperwork, whether it be standards or committees or vendor documentation.

Test and Verify!  It has been abused on an ATA-Analyzer!
It was written while running on an ATA-Analyzer!
The real world does not get any more real than on an ATA-Analyzer!
Since this was a done by direct access with out the FS/VM mess it is an
exact method of operation, it is a perfect data-signal trace.
Perfect == fits exactly in the boundaries of the state-diagrams.

This is how you write code, LT.

Follow the rules, and the verify the rules are correct.
If they are not, fix it until it is correct and see what happened in the
rules.  I have offered to get you signed letters of technical
certification by the drive makers, and you have declined.

The idea of just banging code to get the desired result regardless of
public methods published to insure comman design/correctness is all but
silly.  What do you think timing tables are for, wallpaper or to line the
bottom of a bird cage?  Sheesh  You have to access a PCI-bus, CPU, AGP
and all these other things in the correct event windows, or do you?

Regards,

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: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Andreas Dilger]

Anton, you write:
> Have a look at 2.4, arch/sparc64/kernel/ioctl32.c

Yuk.

> Would it be possible to clean up the ioctl interface so we dont need
> such large hacks for LVM support? I can do the work but I want to be
> sure you guys will agree to it.

What is the reason for all this?  Alignment/wordsize/other?  If you look
at the IOP10 code, much of the in-core data structs were changed to int
or long, so this sparc code may not be necessary.  It may in fact be
damaging, because I don't know if any of the LVM developers even know it
is there, and surely it will be out of sync...

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Manfred Spraul]

Linus Torvalds wrote:
> 
> It may well not be disable_irq() that is buggy. In fact, there's good
> reason to believe that it's a hardware problem.
> 
Perhaps a problem with the 82093AA external IO APIC used for 440BX
board? I haven't seen any reports from newer Intel boards (the ICH2
includes an IO APIC) or from Via boards.

The problem is not SMP specific: Frank wrote that it also occured when
he booted with "max_cpus=1".

--
Manfred
-
To unsubscribe from this list: send 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: USB Mass Storage in 2.4.0

[Robert J. Bell]

No luck using the standard UHCI driver, attached logs.

Matthew Dharm wrote:

> Do you have an OHCI controller or an UHCI controller?  I noticed that
> you're using the "alternate" UHCI driver... can you try this with the
> standard UHCI driver?
> 
> Matt
> 
> On Fri, Jan 12, 2001 at 03:34:41PM -0800, Robert J. Bell wrote:
> 
>> Unfortunately I lost everything on my system (the one that worked) and I 
>> don't believe I ever looked in /proc/scsi/scsi because It was working 
>> and I didn't feel the need to go poking around.  I had this problem 
>> initially the first time I compiled 2.4.0 but I went back and added SCSI 
>> Generic "on" and that seemed to fix it.  I am just confused why it 
>> thinks this is a scanner. IS there any way to force it to detect it as a 
>> scsi disk?
>> 
>> I must have recompiled this kernel 50 times trying to recreate the the 
>> scenario where this worked. I can send you my .config if you think that 
>> will help.
>> 
>> Robert
>> 
>> 
>> 
>> 
>> 
>> Matthew Dharm wrote:
>> 
>>> Hrm... from these logs, everything looks okay, except for the fact that the
>>> device refuses to return any INQUIRY data.
>>> 
>>> Can you reproduce the conditions under which it was working and send logs
>>> from that?  Or at least remember what the /proc/scsi/scsi info looked like?
>>> 
>>> Matt
>>> 
>>> On Fri, Jan 12, 2001 at 03:19:36PM -0800, Robert J. Bell wrote:
>>> 
 Matthew here is the info you requested, thanks for your help.
 
 


 dmesg2.out
 mesg.out

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

On Fri, 12 Jan 2001, Andre Hedrick wrote:
> 
> It works perfectly and exactly as it is defined to work by the rules.
> Getting the rules correct == 'the concept of "working"'.

Don't be silly.

You're entirely ignoring the concept of hardware bugs. Which is one very
likely reason for this whole discussion in the first place.

ANYBODY who does driver development without taking the real world into
account is a dangerous person. Stacks of papers, diagrams and rules are
absolutely WORTHLESS if you can't just understand the fact that
documentation is nothing more than a guide-line.

Once you realize that documentation should be laughed at, peed upon, put
on fire, and just ridiculed in general, THEN, and only then, have you
reached the level where you can safely read it and try to use it to
actually implement a driver.

I'm continually amazed and absolutely scared silly by your blind trust in
paperwork, whether it be standards or committees or vendor documentation.

Linus

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Frank de Lange]

On Fri, Jan 12, 2001 at 04:56:24PM -0800, Linus Torvalds wrote:
> IDE is not my favourite example of a "known stable driver". Also, in many
> cases IDE is for historical reasons connected to an EDGE io-apic pin (ie
> it's still considered an ISA interrupt). Which probably wouldn't show this
> problem anyway.

They (ide interrupts) are indeed EDGE-triggered on my box. I have not enabled
the HPT366 (ATA66) controller on this board, so I can not tell if that
controller is EDGE-triggered as well.

> Also, IDE doesn't generate all that many interrupts. You can make a
> network driver do a _lot_ more interrupts than just about any disk driver
> by simply sending/receiving a lot of packets. With disks it is very hard
> to get the same kind of irq load - Linux will merge the requests and do at
> least 1kB worth of transfer per interrupt etc. On a ne2k 100Mbps PCI card,
> you can probably _easily_ generate a much higher stream of interrupts.

There's sound... The msnd.c (Turtle Beach MultiSound) driver (and its
derivatives, like msnd_pinnacle) uses disable_irq.  Running esd (esound
daemon), sound can easily generate > 1000 interrupts/second, since esd uses
small dma transfers. This can be seen quite clearly from /proc/interrupts on my
soundserver:

   CPU0   
  0:  276867328  XT-PIC  timer
  1:  2  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  3:7631519  XT-PIC  eth1
  4:2751419  XT-PIC  serial
  5: 1907346678  XT-PIC  soundblaster
  8:  1  XT-PIC  rtc
  9:   45022986  XT-PIC  eth0
 13:  1  XT-PIC  fpu
 14:4320643  XT-PIC  ide0
 15:4409193  XT-PIC  ide1
NMI:  0

OK, this is an ageing P166, and it uses a different driver, etc. I have not
found any problems with hanging sound drivers in Google query for 'linux msnd
bp6' or 'linux multisound bp6'. Of course, this is no conclusive evidence, far
from it... It could be that people using those cards are not the ones who tend
to go for the (somewhat tricky) BP6 board...

Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> 
> 
> On Fri, 12 Jan 2001, Andre Hedrick wrote:
> > 
> > I told you that I have the new code that is scheduled for 2.5 certified on
> > analizers to be technically correct as it relates to the "state diagrams"
> > in the standard.
> 
> "Technically correct" and "state diagrams as in the standard" mean less
> that nothing to me.
> 
> They have very little to do with the concept of "working", which is all I
> really personally care about.

Translation:

You can do a bit level tracking of data and verify that what went down you
get it back across the entire disk.  This can be done in a random-pattern
that does not over-write (obvious) or from head->tail or tail->head.

It works perfectly and exactly as it is defined to work by the rules.
Getting the rules correct == 'the concept of "working"'.

However that model of IO is not complete yet. :-((

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: [BUG] 2.4.0-ac8 PS/2 mouse woes

[Forever shall I be.]

On Sat, Jan 13, 2001 at 12:02:35AM +, Alan Cox wrote:
> > pc_keyb.c..   I also have the cuecat patch applied, and use it over
> > the PS/2 mouse port, but I don't think it's interfering..  I doubt
> > this will be noticable to people not using the "Resolution" option to
> > speed up the mouse, and mine's rather insane:
> 
> Can you tell me if the problem can be duplicated without the cuecat patch
> applied. It is quite possible the ps/2 mouse patch is buggy

Yes, and I tried out 2.4.0-ac7 too, just for kicks, and it doesn't break
with ac7..

> 
> > Anyway, just letting you know, and very sorry for the lack of
> > information..
> 
> Its most of the info I need. Since I churn through patches fast we can normally
> get a good guess at the culprit.
> 
> Alan
> 

Also, the Oops I got is apparently due to my own code, so I'll be trying
to fumble my way through fixing it :)

-- 
Zinx Verituse   (See headers for gpg key info)
-
To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

On Fri, 12 Jan 2001, Andre Hedrick wrote:
> 
> I told you that I have the new code that is scheduled for 2.5 certified on
> analizers to be technically correct as it relates to the "state diagrams"
> in the standard.

"Technically correct" and "state diagrams as in the standard" mean less
that nothing to me.

They have very little to do with the concept of "working", which is all I
really personally care about.

Linus

-
To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

On Fri, 12 Jan 2001, John Heil wrote:
> 
> Yes, initially the 686a was problematic, now with an 80 wire cable its
> fine. 
> 
> One point of clarification... I started out with a simple hdparm -d1
> which failed 85% of the time. I added the other stuff only to enhance the
> -d0 state I was left with.

This sounds like a totally different thing than the DMA corruption - this
sounds like you just got CRC error messages, and the driver still did the
right thing? 

The 82c586 corruption seems to be silently just writing (and maybe
reading) bad data to the disk.

The case of CRC errors and recivering from them (or fixing them with a
good cable) is different - when the CRC errors are noticed, they cause the
command to be re-tried and thus no data corruption should occur.

Basically it's the difference between being "silently bad" and "noisily
good". Sounds like you are in the "noisily good" category - a category
that I don't worry about ;)

Linus

-
To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> 
> 
> On Fri, 12 Jan 2001, John Heil wrote:
> 
> > On Sat, 13 Jan 2001, Alan Cox wrote:
> > 
> > > Date: Sat, 13 Jan 2001 00:25:28 + (GMT)
> > > From: Alan Cox <[EMAIL PROTECTED]>
> > > To: Linus Torvalds <[EMAIL PROTECTED]>
> > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > > Subject: Re: ide.2.4.1-p3.01112001.patch
> > > 
> > > > what the bug is, and whether there is some other work-around, and whether
> > > > it is 100% certain that it is just those two controllers (maybe the other
> > > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too
> > > > and peopl ehaven't reported them because they are "fixed").
> > > 
> > > I've not seen reports on the later chips. If they had been buggy and then 
> > > fixed I'd have expected much unhappy ranting before the change
> > 
> > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda.
 ^^
There no chipset calls that allow one to envoke 32-bit data access on the
data-taskfile register.  This may bite you in the arse! (see below)

> > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon.
> 
> Careful. It may be that your fix just avoids the corruption because the
> other changes make it ok - like the 16-sector multi-count thing maybe
> hides a problem that might still exist - it just changes the "normal"
> timing so that you won't ever see it in practice any more.

This is why it is better to do on paper the timings and not create code
that is varible based on the "ide-bus-clock" not the "pci-bus-clock".
You can only run timings at 33MHz clocking, period.  The exceptions are
for those that can report from the chipset that a clocking-base other than
33 is detected.

I told you that I have the new code that is scheduled for 2.5 certified on
analizers to be technically correct as it relates to the "state diagrams"
in the standard.

> These kinds of magic interactions is why I'm not at all happy about driver
> changes until people really know what it was that caused it, and _know_
> that it's gone.

Linus I know how the driver is to work and how it behaves in
non-multimodes, but I am not sure that even Mark Lord could tells you or
me about the true nature of the current multimode with various chipsets.

Sheesh some of them are now documenting that special bits must be set to
do 32-bit word access on the dataport.

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: Where did vm_operations_struct->unmap in 2.4.0 go?

[Keith Owens]

On Fri, 12 Jan 2001 20:11:30 +0100, 
Christian Zander <[EMAIL PROTECTED]> wrote:
>Saying that I should have made use of this mechanism for the specific
>code in the Nvidia driver that we are talking about clearly shows that
>you didn't look at it. The module used get_module_symbol to search its
>own symbol table for parameters that may have been passed to it at load
>time.

My apologies.  I read the patch, not the full source code and the patch
does not have enough programming context to show that the driver is
only searching its own symbol space.  In my own defense, the references
to spinlock_t unload_lock and MOD_CAN_QUERY(mp) in the patch are highly
misleading, those statements only make sense when you are looking at a
symbol table for another module.  When searching your own symbol table
the current module must be live with a non-zero use count, not being
unloaded and it can always be queried.

>Contrary to what you're saying, the patch does not just inline the old
>get_module_symbol algorithm nor does it access any of module.c's internal
>data.

unload_lock and MOD_CAN_QUERY were copied verbatim from the old
get_module_symbol, even though they are completely unnecessary.  That
looks like inlining the old algorithm to me.

struct module_symbol, mp->nsyms and mp->syms are module.c internal
data.  If it is ever necessary to change those structures, nothing
outside module.c, the 32/64 handlers for module system calls and
modutils should be affected.  Now if I change module_symbol, other bits
of the kernel will unexpectedly break, this is not good.

>> Whoever coded that patch should be taken out and shot, hung, drawn and
>> quartered then forced to write COBOL for the rest of their natural
>> life.
>
>Excellent comment - it is just as appropriate as it is helpful.

Over emphasis for humorous effect.  Must remember to add smiley.


What this patch and David Woodhouse's comments show is that I need to
look at a generic and safe mechanism for kernel/module symbol lookup.
The existing static mechanism works for fixed symbol names but does not
work for symbol names that are generated at run time nor for symbols
that may or may not be present.

get_module_symbol() "worked" but was horribly unsafe.  It broke with
module versions, it did zero type checking which left the code open to
version skew and it assumed that all addresses are equivalent to an
unsigned long.

That last point is especially important for IA64 where function
pointers do not reference the function directly, instead they point to
a function descriptor with two fields, one of which is the function
address.  Casting the unsigned long address of a function into a
function pointer fails miserably on IA64, and gcc does not even give
any warnings.  foo = (int (*)(int))get_module_symbol(NULL, "funcname")
is architecture dependent.

Using EXPORT_SYMBOL_NOVERS() to "fix" the modversions problem for
get_module_symbol() removes all inter module checks on the relevant
symbols.  Not just for the caller of get_module_symbol for all modules
that access those symbols.  This leaves too much code open to version
skew and is not acceptable.

inter_module_xxx is modversions safe.  It still does no type checking
because it uses void * for the data structure, but the exporter and
user have to declare their common data area which reduces the chance of
version skew.  I am still not happy about this possibility of skew but
anything is better than no checks at all.  Passing a data structure
which contains real declarations for function pointers instead of
assuming you can cast a number to a function pointer makes
inter_module_xxx architecture independent.


I will look at a general kernel and module symbol lookup routine that
does the job properly.  The hard part is making sure that the provider
and consumer have exactly the same types for a symbol.  Both
get_module_symbol and inter_module_xxx completely bypass the
modversions checks and are wide open to undetectable version skew,
although inter_module_xxx is a little bit safer.  Any replacement for
these functions must be able to do type checking at run time, which
probably means it is 2.5 code.  And yes, David, it should be able to
handle static 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/

Re: ide.2.4.1-p3.01112001.patch

[John Heil]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> Date: Fri, 12 Jan 2001 16:52:00 -0800 (PST)
> From: Linus Torvalds <[EMAIL PROTECTED]>
> To: John Heil <[EMAIL PROTECTED]>
> Cc: Alan Cox <[EMAIL PROTECTED]>, Vojtech Pavlik <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Subject: Re: ide.2.4.1-p3.01112001.patch
> 
> 
> 
> On Fri, 12 Jan 2001, John Heil wrote:
> 
> > On Sat, 13 Jan 2001, Alan Cox wrote:
> > 
> > > Date: Sat, 13 Jan 2001 00:25:28 + (GMT)
> > > From: Alan Cox <[EMAIL PROTECTED]>
> > > To: Linus Torvalds <[EMAIL PROTECTED]>
> > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > > Subject: Re: ide.2.4.1-p3.01112001.patch
> > > 
> > > > what the bug is, and whether there is some other work-around, and whether
> > > > it is 100% certain that it is just those two controllers (maybe the other
> > > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too
> > > > and peopl ehaven't reported them because they are "fixed").
> > > 
> > > I've not seen reports on the later chips. If they had been buggy and then 
> > > fixed I'd have expected much unhappy ranting before the change
> > 
> > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda.
> > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon.
> 
> Careful. It may be that your fix just avoids the corruption because the
> other changes make it ok - like the 16-sector multi-count thing maybe
> hides a problem that might still exist - it just changes the "normal"
> timing so that you won't ever see it in practice any more.
> 
> These kinds of magic interactions is why I'm not at all happy about driver
> changes until people really know what it was that caused it, and _know_
> that it's gone.
> 
> Anyway, for you the problem apparently happened even on a 686a, but just
> the 586 series. Correct?

Yes, initially the 686a was problematic, now with an 80 wire cable its
fine. 

One point of clarification... I started out with a simple hdparm -d1
which failed 85% of the time. I added the other stuff only to enhance the
-d0 state I was left with.

I then changed to the 80 wire cables and retried with only -d1 again, 
and to my surprise, the problems never came back and DMA stayed on.
A while later, I added -X66 and it too worked great. Then lastly came
the re-add of the rest giving current state.

> 
>   Linus
> 

-
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.sc-software.com
-

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

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Linus Torvalds]

On Sat, 13 Jan 2001, Frank de Lange wrote:

> On Fri, Jan 12, 2001 at 04:36:33PM -0800, Linus Torvalds wrote:
> > It may well not be disable_irq() that is buggy. In fact, there's good
> > reason to believe that it's a hardware problem.
> 
> I am inclined to believe it IS a hardware problem... If disable_irq were buggy,
> wouldn't the problem occur more frequently in other irq-heavy areas? A quick
> count shows that disable_irq* is used in 84 sourcefiles in the driver/*
> directory. This includes drivers which generate many interrupts in a short
> timeframe (like ide).

IDE is not my favourite example of a "known stable driver". Also, in many
cases IDE is for historical reasons connected to an EDGE io-apic pin (ie
it's still considered an ISA interrupt). Which probably wouldn't show this
problem anyway.

Also, IDE doesn't generate all that many interrupts. You can make a
network driver do a _lot_ more interrupts than just about any disk driver
by simply sending/receiving a lot of packets. With disks it is very hard
to get the same kind of irq load - Linux will merge the requests and do at
least 1kB worth of transfer per interrupt etc. On a ne2k 100Mbps PCI card,
you can probably _easily_ generate a much higher stream of interrupts.

Linus

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

Re: 2.4.0: ieee1394: got invalid ack 3 from node 65473 (tcode 4)

[Andreas Bombe]

On Wed, Jan 10, 2001 at 04:48:42AM +0100, Wolfgang Spraul wrote:
> Incompatibility with "Sarotech FHD-352F/U Rev 1.0"
> 
> Using an external IDE drive in the Sarotech FireWire enclosure fails, even
> though the Sarotech unit works with Win2K and other SBP2 drives work for me
> (with Linux).
> 
> I'm using 2.4.0 together with sbp2_1394_122300.tar.gz.
> ACK code 3 is not even mentioned in ieee1394.h.

That's because it's defined as reserved in the standard and therefore it
says "invalid ack".  The interesting would be whether we really get
that code or if there is a bug in the driver somewhere.

> I understand that the SBP2 driver is not (yet) included, but it will be shortly.
> Also, I guess the same problem applies to raw1394.o together with the Sarotech
> enclosure.

Could you test that with testlibraw?  (This program is built with libraw
and not installed currently.)

-- 
 Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Andrew Morton]

Tim Wright wrote:
> 
> Hmmm...
> if  is very quick, and is guaranteed not to sleep, then a semaphore
> is the wrong way to protect it. A spinlock is the correct choice. If it's
> always slow, and can sleep, then a semaphore makes more sense, although if
> it's highly contented, you're going to serialize and throughput will die.
> At that point, you need to redesign :-)
> If it's mostly quick but occasionally needs to sleep, I don't know what the
> correct idiom would be in Linux. DYNIX/ptx has the concept of atomically
> releasing a spinlock and going to sleep on a semaphore, and that would be
> the solution there e.g.
> 
> p_lock(lock);
> retry:
> ...
> if (condition where we need to sleep) {
> p_sema_v_lock(sema, lock);
> /* we got woken up */
> p_lock(lock);
> goto retry;
> }
> ...

That's an interesting concept.  How could this actually be used
to protect a particular resource?  Do all users of that
resource have to claim both the lock and the semaphore before
they may access it?


There are a number of locks (such as pagecache_lock) which in the
great majority of cases are held for a short period, but are 
occasionally held for a long period.  So these locks are not
a performance problem, they are not a scalability problem but
they *are* a worst-case-latency problem.

> 
> I'm stating the obvious here, and re-iterating what you said, and that is that
> we need to carefully pick the correct primitive for the job. Unless there's
> something very unusual in the Linux implementation that I've missed, a
> spinlock is a "cheaper" method of protecting a short critical section, and
> should be chosen.
> 
> I know the BKL is a semantically a little unusual (the automatic release on
> sleep stuff), but even so, isn't
> 
> lock_kernel()
> down(sem)
> 
> up(sem)
> unlock_kernel()
> 
> actually equivalent to
> 
> lock_kernel()
> 
> unlock_kernel()
> 
> If so, it's no great surprise that performance dropped given that we replaced
> a spinlock (albeit one guarding somewhat more than the critical section) with
> a semaphore.

Yes.

-
-
To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

On Fri, 12 Jan 2001, John Heil wrote:

> On Sat, 13 Jan 2001, Alan Cox wrote:
> 
> > Date: Sat, 13 Jan 2001 00:25:28 + (GMT)
> > From: Alan Cox <[EMAIL PROTECTED]>
> > To: Linus Torvalds <[EMAIL PROTECTED]>
> > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> > Subject: Re: ide.2.4.1-p3.01112001.patch
> > 
> > > what the bug is, and whether there is some other work-around, and whether
> > > it is 100% certain that it is just those two controllers (maybe the other
> > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too
> > > and peopl ehaven't reported them because they are "fixed").
> > 
> > I've not seen reports on the later chips. If they had been buggy and then 
> > fixed I'd have expected much unhappy ranting before the change
> 
> The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda.
> Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon.

Careful. It may be that your fix just avoids the corruption because the
other changes make it ok - like the 16-sector multi-count thing maybe
hides a problem that might still exist - it just changes the "normal"
timing so that you won't ever see it in practice any more.

These kinds of magic interactions is why I'm not at all happy about driver
changes until people really know what it was that caused it, and _know_
that it's gone.

Anyway, for you the problem apparently happened even on a 686a, but just
the 586 series. Correct?

Linus

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Linus Torvalds]

On Sat, 13 Jan 2001, Alan Cox wrote:

> > interrupt_handler()
> > {
> > status = readl(dev->status);
> > if (status & MY_IRQ_DISABLE)
> > return;
> 
> Unfortunately on the 8390 the IRQ statud register is on page 0. The code
> on the other CPU might not be on page 0. That means we can't even safely
> check if there is an irq pending or clear it down (bad news on ne2k-pci)
> without getting that lock.

Alan.

THINK.

The "synchronous channel" can be _memory_. I just used the above as an
example of using a synchronous channel to make sure that the asynchronous
buses aren't screwing us.

You only need one bit of synchronous information. The example used the
very same bit that the irq flag on the device is anyway - which works on a
lot of devices simply because they need to read the status flags anyway
in order to handle the interrupt.

But if you have problems with that, just use an atomic flag off
"dev->private" instead. Big deal.

Linus

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Frank de Lange]

On Fri, Jan 12, 2001 at 04:36:33PM -0800, Linus Torvalds wrote:
> It may well not be disable_irq() that is buggy. In fact, there's good
> reason to believe that it's a hardware problem.

I am inclined to believe it IS a hardware problem... If disable_irq were buggy,
wouldn't the problem occur more frequently in other irq-heavy areas? A quick
count shows that disable_irq* is used in 84 sourcefiles in the driver/*
directory. This includes drivers which generate many interrupts in a short
timeframe (like ide).

Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[John Heil]

On Sat, 13 Jan 2001, Alan Cox wrote:

> Date: Sat, 13 Jan 2001 00:25:28 + (GMT)
> From: Alan Cox <[EMAIL PROTECTED]>
> To: Linus Torvalds <[EMAIL PROTECTED]>
> Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: ide.2.4.1-p3.01112001.patch
> 
> > what the bug is, and whether there is some other work-around, and whether
> > it is 100% certain that it is just those two controllers (maybe the other
> > ones are buggy too, but the 2.2.x tests basically cured their symptoms too
> > and peopl ehaven't reported them because they are "fixed").
> 
> I've not seen reports on the later chips. If they had been buggy and then 
> fixed I'd have expected much unhappy ranting before the change

The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda.
Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon.

Interestingly, initially feeding that chip 40 wire cables (w/o the
-X66 of course) would result in the crc errors followed by DMA turn off,
about 85% of time... Other 15% was fine and DMA worked great.

I then switched to the 80 wire cable and DMA became rock solid at
which point the -X66 was added.

Just thought I'd add some data points :) 

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

-
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.sc-software.com
-

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

Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Anton Blanchard]

 
Hi,

> a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at
>
> for download (Follow the "LVM download page" link).

Have a look at 2.4, arch/sparc64/kernel/ioctl32.c

Would it be possible to clean up the ioctl interface so we dont need
such large hacks for LVM support? I can do the work but I want to be
sure you guys will agree to it.

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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Alan Cox]

>   interrupt_handler()
>   {
>   status = readl(dev->status);
>   if (status & MY_IRQ_DISABLE)
>   return;

Unfortunately on the 8390 the IRQ statud register is on page 0. The code
on the other CPU might not be on page 0. That means we can't even safely
check if there is an irq pending or clear it down (bad news on ne2k-pci)
without getting that lock.

That means we have to be able to just block that one irq source to avoid
horrible SMP latency problems. 

Alan

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Linus Torvalds]

On Fri, 12 Jan 2001, Alan Cox wrote:

> > Could you disable both bandaids? I disabled them, no problems so far.
> > Now back to the disable_irq_nosync().
> 
> Ok so it looks like the disable_irq code is buggy. Unfortunately its not
> just used for these drivers they are just the heaviest users.

It may well not be disable_irq() that is buggy. In fact, there's good
reason to believe that it's a hardware problem.

Linus

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Linus Torvalds]

On Fri, 12 Jan 2001, Alan Cox wrote:

> > interrupt controllers (io-apic definitely included).  Drivers would
> > generally be better off if they disabled their own chip from sending
> > interrupts, rather than disabling the interrupt line the chip is on. 
> 
> That doesn't work very well because the device irq can arrive a measurable
> number of clocks after you disable it on the source and there is no way to
> say 'and be sure the stupid thing has propogated the apic bus'

I agree. Asynchronous buses are nasty that way. However, if your "locking"
is based on device state, you can still do it: you just have to have an
internal device protocol. The simplest example of this is:

interrupt_handler()
{
status = readl(dev->status);
if (status & MY_IRQ_DISABLE)
return;

}


{
status = readl(dev->status);
writel(dev->status, status | MY_IRQ_DISABLE);
spin_lock();
.. critical region ..
spin_unlock();
writel(dev->status, status);
}


Notice how the above does NOT guarantee that the physical interrupt might
not be "in flight". It does, however, synchronize other ways, simply by
virtue of using the _synchronous_ bus (PCI, in this case) to figure out
when the asynchronous bus (interrupts) has a bogus event.

Linus

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Alan Cox]

> > The spin_lock_irqsave() is absolutely my preferred fix, and if I remember
> > correctly this is in fact how some early 2.1.x code fixed the ne2000
> > driver when the original irq scalability stuff happened (for some time
> > during development we did not have a working "disable_irq()" AT ALL
> > because the irq-disabling counters etc logic hadn't been done).
> 
> And that's the patch I meant... Manfred's
> spin_lock_irqsave/spin_unlock_irqrestore based one, not my
> (spin_lock_irq/spin_unlock_irq) based patch. That is also the one I'm running
> now.

The old code did it with #ifdef __SMP__ tests so it only screwed up SMP boxes,
which at the time was quite acceptable because real people didnt have them
and certainly at the price didnt put ne2000's in them 8)

The basic problem is that you cannot allow

-   set multicast list
-   open/close
-   irq
-   transmit

to occur except when serialized because of the indirection and register
gunge on the chip. The copies are slow and long enough that they prevent
28.8 modem sessions being usable.

I'd have to check the chip manual to be sure you even disable the irqs
without corrupting an in progress transfer

-
To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[Alan Cox]

> what the bug is, and whether there is some other work-around, and whether
> it is 100% certain that it is just those two controllers (maybe the other
> ones are buggy too, but the 2.2.x tests basically cured their symptoms too
> and peopl ehaven't reported them because they are "fixed").

I've not seen reports on the later chips. If they had been buggy and then 
fixed I'd have expected much unhappy ranting before the change

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Frank de Lange]

On Fri, Jan 12, 2001 at 04:15:37PM -0800, Linus Torvalds wrote:
> On Fri, 12 Jan 2001, Frank de Lange wrote:
> > 
> > Gentleman, this (the patch to 8390.c) seems to fix the problem.
> 
> The problem with this patch is that anybody with a slow ISA ne2000 clone
> will basically have absolutely _horrible_ interrupt latency because we
> hold the irq lock over some quite expensive operations.
> 
> The spin_lock_irqsave() is absolutely my preferred fix, and if I remember
> correctly this is in fact how some early 2.1.x code fixed the ne2000
> driver when the original irq scalability stuff happened (for some time
> during development we did not have a working "disable_irq()" AT ALL
> because the irq-disabling counters etc logic hadn't been done).

And that's the patch I meant... Manfred's
spin_lock_irqsave/spin_unlock_irqrestore based one, not my
(spin_lock_irq/spin_unlock_irq) based patch. That is also the one I'm running
now.

Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

*** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at

   

for download (Follow the "LVM download page" link).


This release fixes several bugs including the vgextend(8) related oops.
See the CHANGELOG file contained in the tarball for further information.

We'ld appreciate a couple of days for test feedback before pushing a 2.4.0
patch to Linus.

Please test and feed back related information to <[EMAIL PROTECTED]>.

Thanks a lot for your support of LVM.

-- 

Regards,
Heinz-- The LVM Guy --

*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Am Sonnenhang 11
  56242 Marienrachdorf
  Germany
[EMAIL PROTECTED]   +49 2626 141200
   FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Linus Torvalds]

On Fri, 12 Jan 2001, Frank de Lange wrote:
> 
> Gentleman, this (the patch to 8390.c) seems to fix the problem.

The problem with this patch is that anybody with a slow ISA ne2000 clone
will basically have absolutely _horrible_ interrupt latency because we
hold the irq lock over some quite expensive operations.

The spin_lock_irqsave() is absolutely my preferred fix, and if I remember
correctly this is in fact how some early 2.1.x code fixed the ne2000
driver when the original irq scalability stuff happened (for some time
during development we did not have a working "disable_irq()" AT ALL
because the irq-disabling counters etc logic hadn't been done).

The spinlock was changed to "disable_irq()" by a patch from Alan, if I
remember correctly, exactly because people couldn't access serial lines at
any kind of high speeds otherwise - even on "reasonable" hardware.

Alan may remember details better. The fact is that as a general design
principle we should _not_ be using "disable_irq/enable_irq" anyway. BUT
that there are some real-world concerns that make the "better" spinlock
handling have some problems too.

So yes, I bet the spinlock fixes it. But..

Linus

-
To unsubscribe from this list: send 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: USB Mass Storage in 2.4.0

[Matthew Dharm]

Do you have an OHCI controller or an UHCI controller?  I noticed that
you're using the "alternate" UHCI driver... can you try this with the
standard UHCI driver?

Matt

On Fri, Jan 12, 2001 at 03:34:41PM -0800, Robert J. Bell wrote:
> Unfortunately I lost everything on my system (the one that worked) and I 
> don't believe I ever looked in /proc/scsi/scsi because It was working 
> and I didn't feel the need to go poking around.  I had this problem 
> initially the first time I compiled 2.4.0 but I went back and added SCSI 
> Generic "on" and that seemed to fix it.  I am just confused why it 
> thinks this is a scanner. IS there any way to force it to detect it as a 
> scsi disk?
> 
> I must have recompiled this kernel 50 times trying to recreate the the 
> scenario where this worked. I can send you my .config if you think that 
> will help.
> 
> Robert
> 
> 
> 
> 
> 
> Matthew Dharm wrote:
> 
> > Hrm... from these logs, everything looks okay, except for the fact that the
> > device refuses to return any INQUIRY data.
> > 
> > Can you reproduce the conditions under which it was working and send logs
> > from that?  Or at least remember what the /proc/scsi/scsi info looked like?
> > 
> > Matt
> > 
> > On Fri, Jan 12, 2001 at 03:19:36PM -0800, Robert J. Bell wrote:
> > 
> >> Matthew here is the info you requested, thanks for your help.
> >> 
> >> 

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

It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998

 PGP signature

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
> 
> However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
> That's because all VIA chipsets starting from vt82c586 to vt82c686b
> (UDMA100), share the same PCI ID.
> 
> Would you prefer to filter just vt82c586 and vt82c586a as the comment in
> Alan's code says or simply unconditionally kill autodma on all of VIA
> chipsets, as Alan's code does?

Right now, for 2.4.1, I'd rather have the patch to just do the same as
2.2.x. We can figure it out better when we get a better idea of exactly
what the bug is, and whether there is some other work-around, and whether
it is 100% certain that it is just those two controllers (maybe the other
ones are buggy too, but the 2.2.x tests basically cured their symptoms too
and peopl ehaven't reported them because they are "fixed").

Linus

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Manfred Spraul]

Alan Cox wrote:
> 
> > Could you disable both bandaids? I disabled them, no problems so far.
> > Now back to the disable_irq_nosync().
> 
> Ok so it looks like the disable_irq code is buggy. Unfortunately its not
> just used for these drivers they are just the heaviest users.
> 
> Given that we can see the IRQ is still set on the APIC can we fake an IRQ in
> that condition ?

Switch to edge triggered, wait , switch back to level triggered - I've
added that to my sysrq commands, and it clears the IRR bit in the IO
APIC. Sometimes 2 or 3 attempts are required.

I tried several changes to the ioapic code, but without success.

I found:
* the io_apic_sync() in __mask_IO_APIC_irq() is probably wrong, I'd say
it should be _after_ the io_apic_modify, but currently it is before the
io_apic_modify(). 2.2 uses the same code, that doesn't explain the
problem.

* this comment in
http://oss.sgi.com/www.linux.sgi.com/intel/visws/visws.2210.28jul99.patch

+/* XXX ouch... is this really our only choice for masking this
interrupt? */
+/* XXX not fully safe for 2 reasons:
+ * 1) should not touch an apic entry while (whole) apic is enabled
+ * 2) careful about storing to IRR bit (unless we know this intr is
idle)
+ */
+static void disable_cobalt_irq(unsigned int irq)   /* disable_irq()
*/
+{
+   int ent = is_co_apic(irq);
+   if (ent == -1) {
+   return; /* could actually be a panic */
+   }
+
+   /* Note: h/w nada like read-mod-write!  Vec saved in
IRQ_VECTOR() */
+   co_apic_write(CO_APIC_LO(ent), CO_APIC_MASK);
+   (void)co_apic_read(CO_APIC_LO(ent)); /* sync cpu to cobalt apic
*/
+}
+
It's possible that the comment is about an cobalt specific problem, the
IRR bit is - according the Intel documentation - read only.


--
Manfred
-
To unsubscribe from this list: send 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] Ok, I'm fed up now

[Florin Andrei]

Dan B wrote:
> 
> Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet?  What
> about their e100-ANS driver that supports FEC 800mbps?

My system at home has an Intel 815 motherboard (video, sound and network are
included into the motherboard), and works quite well with 2.4.0. I was able to
use its graphics card (obviously, because it's an i815), sound (with ALSA)
and... surprise!... network card!
You just have to use the eepro100 driver (from the mainstream 2.4.0 kernel),
and the netcard will work (i use the eepro100 driver compiled as a module). I
posted this tip few days ago to the Intel netcards newsgroup.

Previously, with 2.2 kernels, i had to use Intel's non-GPL e100 driver,
because the eepro100 driver from 2.2 kernels didn't worked with my card.

-- 
Florin Andrei
-
To unsubscribe from this list: send 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] 2.4.0-ac8 PS/2 mouse woes

[Alan Cox]

> pc_keyb.c..   I also have the cuecat patch applied, and use it over
> the PS/2 mouse port, but I don't think it's interfering..  I doubt
> this will be noticable to people not using the "Resolution" option to
> speed up the mouse, and mine's rather insane:

Can you tell me if the problem can be duplicated without the cuecat patch
applied. It is quite possible the ps/2 mouse patch is buggy

> Anyway, just letting you know, and very sorry for the lack of
> information..

Its most of the info I need. Since I churn through patches fast we can normally
get a good guess at the culprit.

Alan


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

Re: 2.4.0 bug - X doesn't start

[Alan Cox]

>   When i boot the system, X Window doesn't start automatically (but if i boot a
> 2.2 kernel, it does). This is very strange.
>   Also, seems like Sendmail waits forever until it starts. But this might be a
> network card driver problem (not sure, though).

Its the behaviour changes in 2.4 with regard to UDP error messages. Glibc doesnt
yet have the code to adapt.

However: It does imply your resolv.conf may reference a server that doesnt
exist or is unreachable. Unfortunately if your server is across a dialup
or other link brought up after boot then 2.4 + glibc isnt going to be happy
until that work is completed and you get a newer glibc

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

[Alan Cox]

> WITH. patched 8390.c, patched apic.c, sock io_apic.c. My very strong
> feeling is that this will be a stable combination, and that this is what
> we want as a final solution.

If you do that please #ifdef SMP all the changes. Its impossible to use a modem
and an ne2K together on a typical PC otherwise. The copy from the NE2K with
irq disabled is just _SO_ slow you drop bytes continually.

I did all the horrible magic in the ne2k driver for a reason. The other 
alternative is to provide a way to force the system back out of apic mode
so the ne2K driver can do a

goodbye_apic_crap()

type call

-
To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[Alan Cox]

> However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
> That's because all VIA chipsets starting from vt82c586 to vt82c686b
> (UDMA100), share the same PCI ID.

I have no reports of problems with the later stuff

> Would you prefer to filter just vt82c586 and vt82c586a as the comment in
> Alan's code says or simply unconditionally kill autodma on all of VIA
> chipsets, as Alan's code does?

I'd take a 2.2 patch to cut down the range 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/

[BUG] 2.4.0-ac8 PS/2 mouse woes

[Forever shall I be.]

I just booted to 2.4.0-ac8 (from 2.4.0-ac6) and noticed the mouse was
going rather slow in X, so I pumped up the "Resolution" a bit more and
restarted it.. Didn't help, and when I exited the kernel gave a nice
big OOPS in kapm-idled (sorry, i don't have the output), and don't
know if it's related to the mouse problem, but I do know the mouse
problem goes away when I back out the changes in the ac8 patch to
pc_keyb.c..   I also have the cuecat patch applied, and use it over
the PS/2 mouse port, but I don't think it's interfering..  I doubt
this will be noticable to people not using the "Resolution" option to
speed up the mouse, and mine's rather insane:

(zinx@bliss)/etc/X11$ cat XF86Config | grep Resolution
Option "Resolution" "5"

Anyway, just letting you know, and very sorry for the lack of
information..

-- 
Zinx Verituse   (See headers for gpg key info)
-
To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[Alan Cox]

> I'd like to hear about such reports so that I can start debugging (and
> perhaps get me one of those failing boards, they must be quite cheap
> these days).

This is one of the most precise reports I have

|The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks.  The
|size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is
|1.2 GB.  Hdd is an IDE CDROM drive

I think its significant that two reports I have are FIC PA-2013 but not all.
What combination of chips is on the 2013 ?

Alan

-
To unsubscribe from this list: send 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: USB Mass Storage in 2.4.0

[Robert J. Bell]

Unfortunately I lost everything on my system (the one that worked) and I 
don't believe I ever looked in /proc/scsi/scsi because It was working 
and I didn't feel the need to go poking around.  I had this problem 
initially the first time I compiled 2.4.0 but I went back and added SCSI 
Generic "on" and that seemed to fix it.  I am just confused why it 
thinks this is a scanner. IS there any way to force it to detect it as a 
scsi disk?

I must have recompiled this kernel 50 times trying to recreate the the 
scenario where this worked. I can send you my .config if you think that 
will help.

Robert





Matthew Dharm wrote:

> Hrm... from these logs, everything looks okay, except for the fact that the
> device refuses to return any INQUIRY data.
> 
> Can you reproduce the conditions under which it was working and send logs
> from that?  Or at least remember what the /proc/scsi/scsi info looked like?
> 
> Matt
> 
> On Fri, Jan 12, 2001 at 03:19:36PM -0800, Robert J. Bell wrote:
> 
>> Matthew here is the info you requested, thanks for your help.
>> 
>> 

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Alan Cox]

> Could you disable both bandaids? I disabled them, no problems so far.
> Now back to the disable_irq_nosync().

Ok so it looks like the disable_irq code is buggy. Unfortunately its not
just used for these drivers they are just the heaviest users.

Given that we can see the IRQ is still set on the APIC can we fake an IRQ in
that condition ?

-
To unsubscribe from this list: send 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] Ok, I'm fed up now

[Dan B]

Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet?  What 
about their e100-ANS driver that supports FEC 800mbps?

Dan Browning, Cyclone Computer Systems, 
[EMAIL PROTECTED]

At 02:14 PM 1/11/2001 -0800, you wrote:
>On Tue, Jan 09, 2001, Kambo Lohan <[EMAIL PROTECTED]> wrote:
>; I am having the same problems, I have duplicated the hard lockups / 
>ethernet
>; hangs on two intel 815EE boards.  It happens when send traffic through the
>; onboard eepro100 is high, and sometimes running something like vmstat 1 in
>; the background triggers the lockup faster.  When it locks up there is
>; nothing in the log, no oops or anything.  Sometimes it just hangs eth0 with
>; the (cmd timeout) msgs and an ifconfig down/up fixes it temporarily.
>;
>
>
>Kambo,
>
>can you run the driver with a high debug flag and log what is going on,
>make sure you have alot of space since it talks alot.
>
>The card seems to be locking up with a couple of commands in the register that
>are not known to me, my specs don't list them, hopefully the new specs talk
>about it. At this time it's not known where the command comes from, I am
>working on a patch that will tell a bit more about that...

-
To unsubscribe from this list: send 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: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

[Alan Cox]

> interrupt controllers (io-apic definitely included).  Drivers would
> generally be better off if they disabled their own chip from sending
> interrupts, rather than disabling the interrupt line the chip is on. 

That doesn't work very well because the device irq can arrive a measurable
number of clocks after you disable it on the source and there is no way to
say 'and be sure the stupid thing has propogated the apic bus'

Alan

-
To unsubscribe from this list: send 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: USB Mass Storage in 2.4.0

[Matthew Dharm]

Hrm... from these logs, everything looks okay, except for the fact that the
device refuses to return any INQUIRY data.

Can you reproduce the conditions under which it was working and send logs
from that?  Or at least remember what the /proc/scsi/scsi info looked like?

Matt

On Fri, Jan 12, 2001 at 03:19:36PM -0800, Robert J. Bell wrote:
> Matthew here is the info you requested, thanks for your help.
> 
> 



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

What the hell are you?
-- Pitr to Dust Puppy 
User Friendly, 12/3/1997

 PGP signature

Re: USB Mass Storage in 2.4.0

[Robert J. Bell]

Matthew here is the info you requested, thanks for your help.



 dmsg.out

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[george anzinger]

Andrew Morton wrote:
> 
> Nigel Gamble wrote:
> >
> > Spinlocks should not be held for lots of time.  This adversely affects
> > SMP scalability as well as latency.  That's why MontaVista's kernel
> > preemption patch uses sleeping mutex locks instead of spinlocks for the
> > long held locks.
> 
> Nigel,
> 
> what worries me about this is the Apache-flock-serialisation saga.
> 
> Back in -test8, kumon@fujitsu demonstrated that changing this:
> 
> lock_kernel()
> down(sem)
> 
> up(sem)
> unlock_kernel()
> 
> into this:
> 
> down(sem)
> 
> up(sem)
> 
> had the effect of *decreasing* Apache's maximum connection rate
> on an 8-way from ~5,000 connections/sec to ~2,000 conn/sec.
> 
> That's downright scary.
> 
> Obviously,  was very quick, and the CPUs were passing through
> this section at a great rate.

If  was that fast, maybe the down/up should have been a spinlock
too.  But what if it is changed to:

  BKL_enter_mutx()
  down(sem)
  
  up(sem)
  BKL_exit_mutex()
> 
> How can we be sure that converting spinlocks to semaphores
> won't do the same thing?  Perhaps for workloads which we
> aren't testing?

The key is to keep the fast stuff on the spinlock and the slow stuff on
the mutex.  Otherwise you WILL eat up the cpu with the overhead.
> 
> So this needs to be done with caution.
> 
> As davem points out, now we know where the problems are
> occurring, a good next step is to redesign some of those
> parts of the VM and buffercache.  I don't think this will
> be too hard, but they have to *want* to change :)

They will *want* to change if they pop up due to other work :)
> 
> Some of those algorithms are approximately O(N^2), for huge
> values of N.
> 
> -
> -
> To unsubscribe from this list: send 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: USB Mass Storage in 2.4.0

[Matthew Dharm]

Please turn on USB Mass Storage debugging and send me the dmesg output from
when you attach the device and load the drivers.

Matt

On Fri, Jan 12, 2001 at 02:46:46PM -0800, Robert J. Bell wrote:
> I know there has been some talk arround this topic on this list so If I 
> missed the answer I apologize, i just joined the list today. I read 
> through the archive and all I could find relative to mass storage is the 
> scsi dependancy, which I am aware of. Here is my situation.
> 
> I have a Fujufilm FX-1400 digital camera that uses the USB Mass Storage 
> driver. I know it works because I had it working in 2.4.0-test12, and in 
> 2.4.0 however I had a major system failure and lost my new kernel. This 
> time arround I can not get USB Mass Storage to work. I have tried 
> various combinations of the scsi and usb options. I thought maybe I 
> needed SCSI Disk support as well but it didnt seem to matter. I have 
> tried with scsi and usb mass storage as modules and as part of the 
> kernel, still no luck. Here is what happens when I connect the camera :
> 
> Jan 10 18:49:05 t20 kernel: hub.c: USB new device connect on bus1/1, 
> assigned device number 3
> Jan 10 18:49:05 t20 kernel: Product: USB Mass Storage
> Jan 10 18:49:05 t20 kernel: SerialNumber: Y-170^000810X003005237
> Jan 10 18:49:06 t20 kernel: scsi0 : SCSI emulation for USB Mass Storage 
> devices
> Jan 10 18:49:06 t20 kernel:   Vendor:  `.À ÀòÏ  Model: \206   Ø\177.À¡# 
> À ÝòÏ  Rev: 
> Jan 10 18:49:06 t20 kernel:   Type:   Scanner
> ANSI SCSI revision: 02
> 
> Now this used to detect a scsi disk and all I had to do was mount it. I 
> am sure there must be other conflicting config options but I just dont 
> know what it could be. Any help would be greatly appreciated.
> 
> Robert.
> 
> -
> To unsubscribe from this list: send 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

Oh great modem, why hast thou forsaken me?
-- Dust Puppy
User Friendly, 3/2/1998

 PGP signature

USB Mass Storage in 2.4.0

[Robert J. Bell]

I know there has been some talk arround this topic on this list so If I 
missed the answer I apologize, i just joined the list today. I read 
through the archive and all I could find relative to mass storage is the 
scsi dependancy, which I am aware of. Here is my situation.

I have a Fujufilm FX-1400 digital camera that uses the USB Mass Storage 
driver. I know it works because I had it working in 2.4.0-test12, and in 
2.4.0 however I had a major system failure and lost my new kernel. This 
time arround I can not get USB Mass Storage to work. I have tried 
various combinations of the scsi and usb options. I thought maybe I 
needed SCSI Disk support as well but it didnt seem to matter. I have 
tried with scsi and usb mass storage as modules and as part of the 
kernel, still no luck. Here is what happens when I connect the camera :

Jan 10 18:49:05 t20 kernel: hub.c: USB new device connect on bus1/1, 
assigned device number 3
Jan 10 18:49:05 t20 kernel: Product: USB Mass Storage
Jan 10 18:49:05 t20 kernel: SerialNumber: Y-170^000810X003005237
Jan 10 18:49:06 t20 kernel: scsi0 : SCSI emulation for USB Mass Storage 
devices
Jan 10 18:49:06 t20 kernel:   Vendor:  `.À ÀòÏ  Model: \206   Ø\177.À¡# 
À ÝòÏ  Rev: 
Jan 10 18:49:06 t20 kernel:   Type:   Scanner
ANSI SCSI revision: 02

Now this used to detect a scsi disk and all I had to do was mount it. I 
am sure there must be other conflicting config options but I just dont 
know what it could be. Any help would be greatly appreciated.

Robert.

-
To unsubscribe from this list: send 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-audio-dev] low-latency scheduling patch for 2.4.0

[Nigel Gamble]

On Sat, 13 Jan 2001, Andrew Morton wrote:
> Nigel Gamble wrote:
> > Spinlocks should not be held for lots of time.  This adversely affects
> > SMP scalability as well as latency.  That's why MontaVista's kernel
> > preemption patch uses sleeping mutex locks instead of spinlocks for the
> > long held locks.
> 
> Nigel,
> 
> what worries me about this is the Apache-flock-serialisation saga.
> 
> Back in -test8, kumon@fujitsu demonstrated that changing this:
> 
>   lock_kernel()
>   down(sem)
>   
>   up(sem)
>   unlock_kernel()
> 
> into this:
> 
>   down(sem)
>   
>   up(sem)
> 
> had the effect of *decreasing* Apache's maximum connection rate
> on an 8-way from ~5,000 connections/sec to ~2,000 conn/sec.
> 
> That's downright scary.
> 
> Obviously,  was very quick, and the CPUs were passing through
> this section at a great rate.

Yes, this demonstrates that spinlocks are preferable to sleep locks for
short sections.  However, it looks to me like the implementation of up()
may be partly to blame.  It looks to me as if it tends to prefer to
context switch to the woken up process, instead of continuing to run the
current process.  Surrounding the semaphore with the BKL has the effect
of enforcing the latter behavior, because the semaphore itself will
never have any waiters.

> How can we be sure that converting spinlocks to semaphores
> won't do the same thing?  Perhaps for workloads which we
> aren't testing?
> 
> So this needs to be done with caution.
> 
> As davem points out, now we know where the problems are
> occurring, a good next step is to redesign some of those
> parts of the VM and buffercache.  I don't think this will
> be too hard, but they have to *want* to change :)

Yes, wherever the code can be redesigned to avoid long held locks, that
would definitely be my preferred solution.  I think everyone would be
happy if we could end up with a maintainable solution using only
spinlocks that are held for no longer than a couple of hundred
microseconds.

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

-
To unsubscribe from this list: send 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: can't build small enough zImage for floppy

[Manfred Bartz]

Jordan <[EMAIL PROTECTED]> writes:

> 1st, the Sony Vaio Z505HS appears to be an example of a machine which
> will not boot a bzImage correctly, compaining about the compression
> format.

Maybe you need to upgrade to a newer version of lilo?

> 2nd, trying to build kernel 2.4.0, I stripped out or module-ized
> everything I could (I think) including SCSCI support, the smallest I've
> gotten zImage (under 600k) is still too big!

Don't use ``make zImage'', use ``make bzImage'' (big zImage) amd the
size will be fine.
-- 
Manfred

-
To unsubscribe from this list: send 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-pre3] [prePATCH] mmap grows downward on i386

[Wayne Whitney]

As suggested in the thread "Subtle MM bug (really 830MB barrier
question)", it would be beneficial on 32-bit hardware for mmap()
allocations without MAP_FIXED to grow downward from TASK_SIZE, rather than
upwards from TASK_UNMAPPED_BASE.  This would allow both brk()-using and
mmap()-using programs to access almost 3GB (TASK_SIZE - some overhead).

So here is my first ever attempt at a kernel patch.  It compiles and boots
and seems to work OK.  Any comments would be very welcome, but please
excuse my ignorance of many things. :-)

A few comments:

(1) I have no idea how much room to allow for the stack on i386, so I
arbitrarily picked 128MB.

(2) I also have no idea what happens on architectures other than i386, so
I defined TASK_UNMAPPED_CEILING in include/asm-i386/processor.h.  Then in
mm/mmap.c, if TASK_UNMAPPED_CEILING is undefined, get_unmapped_area()
behaves as before.  I used #ifdef to do this, is that an OK style?

(3) The (original) search upwards version of get_unmapped_area() only
calls find_vma() once, and then it uses ->vm_next in the main loop to get
the next vm_area_struct.  My search downwards version calls find_vma()
once every loop, as there is no ->vm_previous member in vm_area_struct.
Is the overhead of calling find_vma() every loop a problem, and if so, is
there a better solution than modifying vm_area_struct to make it a doubly
linked list?

(4) Lastly, there is the question of when get_unmapped_area() should just
fail.  I notice that executables on i386 are loaded at 128MB, so I defined
TASK_UNMAPPED_FLOOR to be 128MB and I stop there.  Is this the right place
to stop, and if so is there some other #define I should be referencing
instead of adding one?

Cheers,
Wayne


diff -ru linux-2.4.0-pre3/include/asm-i386/processor.h 
linux-2.4.0-pre3-hack/include/asm-i386/processor.h
--- linux-2.4.0-pre3/include/asm-i386/processor.h   Thu Jan 11 12:56:05 2001
+++ linux-2.4.0-pre3-hack/include/asm-i386/processor.h  Fri Jan 12 13:51:16 2001
@@ -260,10 +260,22 @@
  */
 #define TASK_SIZE  (PAGE_OFFSET)

-/* This decides where the kernel will search for a free chunk of vm
- * space during mmap's.
+/*
+ * When looking for a free chunk of vm space during mmap's, the kernel
+ * will search upwards from TASK_UNMAPPED_BASE (the usual algorithm),
+ * unless TASK_UNMAPPED_CEILING is defined, in which case it will
+ * search downwards from TASK_UNMAPPED_CEILING to TASK_UNMAPPED_FLOOR.
  */
 #define TASK_UNMAPPED_BASE (TASK_SIZE / 3)
+
+/*
+ * We need to allow room for the stack to grow downard from TASK_SIZE,
+ * I really have no idea how large it can get, so I arbitrarily picked
+ * 128MB.  Also, I'm not so sure where to stop searching and give up,
+ * so I pick 128MB, which seems to be where exectuables get loaded.
+ */
+#define TASK_UNMAPPED_CEILING   (TASK_SIZE - 128 * 1024 * 1024)
+#define TASK_UNMAPPED_FLOOR (128 * 1024 * 1024)

 /*
  * Size of io_bitmap in longwords: 32 is ports 0-0x3ff.
diff -ru linux-2.4.0-pre3/mm/mmap.c linux-2.4.0-pre3-hack/mm/mmap.c
--- linux-2.4.0-pre3/mm/mmap.c  Sat Dec 30 12:35:19 2000
+++ linux-2.4.0-pre3-hack/mm/mmap.c Fri Jan 12 13:54:02 2001
@@ -382,6 +382,22 @@

if (len > TASK_SIZE)
return 0;
+#ifdef TASK_UNMAPPED_CEILING
+   if (!addr)
+   addr = TASK_UNMAPPED_CEILING - len;
+
+   do {
+   /* align addr downards; PAGE_ALIGN aligns it upwards */
+   addr = addr_MASK;
+   vmm = find_vma(current->mm,addr);
+   /* At this point:  (!vmm || addr < vmm->vm_end). */
+   if (!vmm || addr + len <= vmm->vm_start)
+   return addr;
+   addr = vmm->vm_start - len;
+   } while (addr >= TASK_UNMAPPED_FLOOR);
+
+   return 0;
+#else
if (!addr)
addr = TASK_UNMAPPED_BASE;
addr = PAGE_ALIGN(addr);
@@ -394,6 +410,7 @@
return addr;
addr = vmm->vm_end;
}
+#endif
 }
 #endif


-
To unsubscribe from this list: send 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 bug - X doesn't start

[Florin Andrei]

Using 2.4.0 on Red Hat Linux 7.0 with most updates applied. Modified the
Makefile to use kgcc.
My system is an SGI 1200 (something like a VALinux 2xxx), dual PIII/700, 512
MB RAM, Intel L440GX+ motherboard, 2 x Intel Pro/100 netcards

When i boot the system, X Window doesn't start automatically (but if i boot a
2.2 kernel, it does). This is very strange.
Also, seems like Sendmail waits forever until it starts. But this might be a
network card driver problem (not sure, though).

Here is the .config file:

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_M686FXSR=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_FXSR=y
CONFIG_X86_XMM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_PM is not set
# CONFIG_ACPI is not set
# CONFIG_APM is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
CONFIG_BLK_DEV_DAC960=y
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_BLK_DEV_LVM is not set
# CONFIG_LVM_PROC_FS is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_LARGE_TABLES=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=m
# CONFIG_NET_IPGRE_BROADCAST is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
# CONFIG_IPV6 is not set
CONFIG_KHTTPD=m
# CONFIG_ATM is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# 

Re: PRoblem with pcnet32 under 2.4.0 , was :Drivers under 2.4

[Thomas Bogendoerfer]

On Fri, Jan 12, 2001 at 12:50:10PM +0100, Danny ter Haar wrote:
> eth0: PCnet/FAST III 79C973 at 0xfce0, 00 00 e2 24 41 1d
> pcnet32: pcnet32_private lp=c3c42000 lp_dma_addr=0x3c42000 assigned IRQ 9. 
> pcnet32.c:v1.25kf 26.9.1999 [EMAIL PROTECTED] 

same chip works for me von my P5 SMP box.

> irq  0: 16840 timer  irq  9: 0 acpi, PCnet/FAST III  

no interrupts for PCnet driver sounds more like interrupt routing problem to
me.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ Alexander Viro on linux-kernel ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

problem with a copy (cdrom to disk) under 2.4.0

[andre lourenco]

i have a problem:

when i try to copy a big (maybe >200MB) from my CDROM to my disk the system
gives me an input/output error...

if I run dmesg i have this:

[root@localhost andyrock]# dmesg
Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version 2.95.3
19991030 (prerelease)) #1 Qui Jan 11 12:22:42 WET 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 0001 @  (reserved)
 BIOS-e820: 07f0 @ 0010 (usable)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 32768
zone(0): 4096 pages.
zone(1): 28672 pages.
zone(2): 0 pages.
mapped APIC to e000 (01223000)
Kernel command line: mem=131072K  root=/dev/hdb5  ide1=autotune
ide0=autotune
ide_setup: ide1=autotune
ide_setup: ide0=autotune
Initializing CPU#0
Detected 334.095 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 666.82 BogoMIPS
Memory: 126340k/131072k available (1215k kernel code, 4344k reserved, 472k
data, 220k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
CPU: Before vendor init, caps: 0183f9ff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183f9ff   
CPU: After generic, caps: 0183f9ff   
CPU: Common caps: 0183f9ff   
CPU: Intel Pentium II (Deschutes) stepping 01
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb2b0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 2: assuming transparent
Limiting direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: Card 'ESS ES1868 Plug and Play AudioDrive'
isapnp: 1 Plug & Play card detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
DMI 2.0 present.
32 structures occupying 792 bytes.
DMI table at 0x000F0800.
BIOS Vendor: Award Software International, Inc.
BIOS Version: 4.51 PG
BIOS Release: 08/10/98
Starting kswapd v1.8
vesafb: framebuffer at 0xe540, mapped to 0xc880, size 4096k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: protected mode interface info at c000:1759
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
ide3: ESS ES1868 Plug and Play AudioDrive IDE interface
hda: FUJITSU MPE3170AT, ATA DISK drive
hdb: QUANTUM FIREBALL EX3.2A, ATA DISK drive
hdc: TOSHIBA CD-ROM XM-6402B, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 33360580 sectors (17081 MB) w/512KiB Cache, CHS=2076/255/63
hdb: 6306048 sectors (3229 MB) w/418KiB Cache, CHS=782/128/63, UDMA(33)
hdc: ATAPI 32X CD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1 hda2 < hda5 > hda3 hda4
 hdb: hdb1 hdb2 < hdb5 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
udf: registering filesystem
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI
ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
PPP generic driver version 2.4.1
PPP Deflate Compression module registered
PPP BSD Compression module registered
[drm] Initialized tdfx 1.0.0 2928 on minor 63
es1371: version v0.27 time 12:26:33 Jan 11 2001
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
uhci.c: USB UHCI at I/O 0xe000, IRQ 9
uhci.c: detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash 

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Nigel Gamble]

On Fri, 12 Jan 2001, Tim Wright wrote:

> On Sat, Jan 13, 2001 at 12:30:46AM +1100, Andrew Morton wrote:
> > what worries me about this is the Apache-flock-serialisation saga.
> > 
> > Back in -test8, kumon@fujitsu demonstrated that changing this:
> > 
> > lock_kernel()
> > down(sem)
> > 
> > up(sem)
> > unlock_kernel()
> > 
> > into this:
> > 
> > down(sem)
> > 
> > up(sem)
> > 
> > had the effect of *decreasing* Apache's maximum connection rate
> > on an 8-way from ~5,000 connections/sec to ~2,000 conn/sec.
> > 
> > That's downright scary.
> > 
> > Obviously,  was very quick, and the CPUs were passing through
> > this section at a great rate.
> > 
> > How can we be sure that converting spinlocks to semaphores
> > won't do the same thing?  Perhaps for workloads which we
> > aren't testing?
> > 
> > So this needs to be done with caution.
> > 
> 
> Hmmm...
> if  is very quick, and is guaranteed not to sleep, then a semaphore
> is the wrong way to protect it. A spinlock is the correct choice. If it's
> always slow, and can sleep, then a semaphore makes more sense, although if
> it's highly contented, you're going to serialize and throughput will die.
> At that point, you need to redesign :-)
> If it's mostly quick but occasionally needs to sleep, I don't know what the
> correct idiom would be in Linux. DYNIX/ptx has the concept of atomically
> releasing a spinlock and going to sleep on a semaphore, and that would be
> the solution there e.g.
> 
> p_lock(lock);
> retry:
> ...
> if (condition where we need to sleep) {
> p_sema_v_lock(sema, lock);
> /* we got woken up */
> p_lock(lock);
> goto retry;
> }
> ...
> 
> I'm stating the obvious here, and re-iterating what you said, and that is that
> we need to carefully pick the correct primitive for the job. Unless there's
> something very unusual in the Linux implementation that I've missed, a
> spinlock is a "cheaper" method of protecting a short critical section, and
> should be chosen.
> 
> I know the BKL is a semantically a little unusual (the automatic release on
> sleep stuff), but even so, isn't
> 
>   lock_kernel()
>   down(sem)
>   
>   up(sem)
>   unlock_kernel()
> 
> actually equivalent to
> 
>   lock_kernel()
>   
>   unlock_kernel()
> 
> If so, it's no great surprise that performance dropped given that we replaced
> a spinlock (albeit one guarding somewhat more than the critical section) with
> a semaphore.
> 
> Tim
> 
> --
> Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
> IBM Linux Technology Center, Beaverton, Oregon
> "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
> 

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

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

Bug report on 2.4.0 release

[A.P.R., a.k.a. Stupendous Man]

This is to report a possible 2.4.0 bug in either the kernel or
in pppd regarding wakeup after an apmsleep command.

The problem is as follows:

After successful return from an apmsleep command, issued the night
before, ppp does not seem to work. The fix is to rmmod slhc, ppp_generic,
and ppp_ttysync and then insmod them again. Then everything works as expected.
Note that I use rp-pppoe so this is ppp over an ethernet card for DSL.

The errors I get from ppp version 2.4.0 are:

   Jan 12 11:55:44 manic pppd[6173]: No response to 3 echo-requests
   Jan 12 11:55:44 manic pppd[6173]: Serial link appears to be disconnected.

Note that just bringing down and restarting my eth0 card does not solve the problem,
so I do not believe it is an ethernet card wakeup issue.

Note that this works just fine under kernel version 2.2.18 without the need
to rmmod and insmod anything.

My machine info: Asus p3bf motherboard, 500 MHz PIII PC, RH 7.0 + kernel 2.4.0,
ppp-2.4.0-2.rpm.

-- tony


Surrender to the void.
-- John Lennon

-
To unsubscribe from this list: send 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: APIC ERRor on CPU0: 00(02) ...

[Dr. Kelsey Hudson]

This is due to your piece of trash motherboard. The reason that the older
kernel didn't catch these errors is because (IIRC) it wasn't looking for
them; they were there even then. The BP6 is a low-end mainboard and was
engineered very poorly; these errors are due to that fact alone.

Talk to you later,

-Kelsey

On Fri, 12 Jan 2001, V.P. wrote:

> I have a Motherboard BP6 with two Celeron 500 (Not overclocked) and
> Linux Kernel-2.4
> 
> and I have de message
> 
> APIC error on CPU0: 00(02)
> APIC error on CPU1: 00(08)
> APIC error on CPU1: 08(04)
> APIC error on CPU0: 02(08)
> APIC error on CPU0: 08(08)
> APIC error on CPU1: 04(04)
> APIC error on CPU0: 08(02)
> APIC error on CPU1: 04(02)
> 
> 
> What wrongs ?
> 
>  This message doesn 't  appears in Kernel-2.2.17 only in Kernel-2.4
> 
>   Any Help is apreciated
> 
> 
>   V.P. ***  Linux **  Porto *** Portugal
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

-- 
 Kelsey Hudson   [EMAIL PROTECTED] 
 Software Engineer
 Compendium Technologies, Inc   (619) 725-0771
--- 

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

Latest status of IDE patches from Andre

[Jeff Nguyen]

Hi Alan,

Will you incorporate Andre IDE patches into the 2.2.19preXX
kernel? If not, do you have any plan to do so in the very near future? 
I know this issue has been discussed before. But there has not been
any progress.

I have been following the kernel development for years. I have seen
many drivers added to the kernel. Some weren't working properly
and had to be removed quickly. Strangely, the IDE patches drag on
and on after all the kernel releases.

Are you still concern about the stability of the driver?  

Regards,

Jeff

ASL Inc.

 

-
To unsubscribe from this list: send 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: can't build small enough zImage for floppy

[alex]

On Fri, Jan 12, 2001 at 03:48:23PM -0600, Jordan wrote:
> 1st, the Sony Vaio Z505HS appears to be an example of a machine which
> will not boot a bzImage correctly, compaining about the compression
> format.

I can say from experience that this is not the case.  In fact, the kernel 
binaries (RPM) I provide on my Z505 page (http://www.foogod.com/z505_linux) are 
bzImages (currently those are still test5, though I have used later ones on my 
own machine as well, and will probably be upgrading the page to 2.4.0 final 
eventually).  I will admit that I haven't tried booting them from a floppy.. 
perhaps this is where the problem lies.

The Z505HS does have a USB floppy drive, which is the only thing I can think 
of that's different from most other machines which might affect this, but I do 
know that that doesn't stop a 2.2 kernel from booting off of it (though there 
are problems accessing the floppy after the initial boot without USB drivers, 
of course)

I will look into building a 2.4.0 floppy-bootable kernel on my Z505 and see if 
I can reproduce the problems you're having.

-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: [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o

[Stefan Smietanowski]

Hi.

> Here's something strange that i've been noticing with 2.4.0. Some websites I am
> unable to access now. For example:



This is a FAQ. Check if you compiled with ECN enabled (CONFIG_INET_ECN).
Some sites have broken firewalls that drop packets of that type. Either
don't surf to those sites or disable ECN. This will all work when all
sites upgrade their firewalls *cough*.

// Stefan
-
To unsubscribe from this list: send 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: [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o

[Shawn Starr]

Oh, hrm Guess I shouldn't have turned that on ;)
Sorry. nevermind :)


Miles Lane wrote:

> Make sure your kernel build .config file contains the line:
>
> # CONFIG_INET_ECN is not set
>
> not
>
> CONFIG_INET_ECN=y
>
> Here's what the kernel configuration help has to say:
>
>   Explicit Congestion Notification (ECN) allows routers to notify
>   clients about network congestion, resulting in fewer dropped packets
>   and increased network performance. This option adds ECN support to the
>   Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which
>   allows ECN support to be disabled at runtime.
>
>   Note that, on the Internet, there are many broken firewalls which
>   refuse connections from ECN-enabled machines, and it may be a while
>   before these firewalls are fixed. Until then, to access a site behind
>   such a firewall (some of which are major sites, at the time of this
>   writing) you will have to disable this option, either by saying N now
>   or by using the sysctl.
>
> Shawn Starr wrote:
> >
> > Here's something strange that i've been noticing with 2.4.0. Some websites I am
> > unable to access now. For example:
> >
> > http://www.scotiabank.ca/simplify/index.html
>
> 
> -
> To unsubscribe from this list: send 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: [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o

[Matti Aarnio]

On Fri, Jan 12, 2001 at 04:37:35PM -0500, Shawn Starr wrote:
> Here's something strange that i've been noticing with 2.4.0. Some
> websites I am unable to access now. For example:

  This is FAQish thing.  DON'T USE TCP_ECN unless you want trouble!

# echo 0 > /proc/sys/net/ipv4/tcp_ecn

> Shawn S.

/Matti Aarnio
-
To unsubscribe from this list: send 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: [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o

[Miles Lane]

Make sure your kernel build .config file contains the line:

# CONFIG_INET_ECN is not set

not

CONFIG_INET_ECN=y

Here's what the kernel configuration help has to say:

  Explicit Congestion Notification (ECN) allows routers to notify
  clients about network congestion, resulting in fewer dropped packets
  and increased network performance. This option adds ECN support to the
  Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which
  allows ECN support to be disabled at runtime.

  Note that, on the Internet, there are many broken firewalls which
  refuse connections from ECN-enabled machines, and it may be a while
  before these firewalls are fixed. Until then, to access a site behind
  such a firewall (some of which are major sites, at the time of this
  writing) you will have to disable this option, either by saying N now
  or by using the sysctl.


Shawn Starr wrote:
> 
> Here's something strange that i've been noticing with 2.4.0. Some websites I am
> unable to access now. For example:
> 
> http://www.scotiabank.ca/simplify/index.html


-
To unsubscribe from this list: send 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: `rmdir .` doesn't work in 2.4

[Pavel Machek]

Hi!

> The bottom line: rmdir(".") is gone. Replace it with portable equivalent,
> namely
>   p = getcwd(pwd, sizeof(pwd));
>   if (!p)
>   /* handle error - ERANGE or ENOENT */
>   rmdir(p);
> Shell equivalent is rmdir `pwd`. Also portable.

...when you are lucky and all directories up to your path are
readable... Which is not always so. With old glibc, it will fail.
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Patch(?): linux-2.4.1-pre3/include/asm-i386/xor.h referenced undefined HAVE_XMM

[Adam J. Richter]

linux-2.4.1-pre2 changed cpu_has_xmm references in
include/asm-i386/xor.h into HAVE_XMM references, which it that
patch also defined.  linux-2.4.1-pre3 removed the definition of
HAVE_XMM but did not revert the references in include/asm-i386/xor.h.
My guess is that cpu_has_xmm is the prefered name, so here is a patch
fixing include/asm-i386/xor.h.

-- 
Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."


--- linux-2.4.1-pre3/include/asm-i386/xor.h Fri Jan 12 05:29:00 2001
+++ linux/include/asm-i386/xor.hFri Jan 12 13:46:23 2001
@@ -843,7 +843,7 @@
do {\
xor_speed(_block_8regs);\
xor_speed(_block_32regs);   \
-   if (HAVE_XMM)   \
+   if (cpu_has_xmm)\
xor_speed(_block_pIII_sse); \
if (md_cpu_has_mmx()) { \
xor_speed(_block_pII_mmx);  \
@@ -855,4 +855,4 @@
We may also be able to load into the L1 only depending on how the cpu
deals with a load to a line that is being prefetched.  */
 #define XOR_SELECT_TEMPLATE(FASTEST) \
-   (HAVE_XMM ? _block_pIII_sse : FASTEST)
+   (cpu_has_xmm ? _block_pIII_sse : FASTEST)

Re: generic_file_write change in 2.4.0-ac8

[Chris Mason]

On Friday, January 12, 2001 04:30:44 PM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:

> 
> 
> On Fri, 12 Jan 2001, Chris Mason wrote:
> 
>> 
>> Hi guys,
>> 
>> This code for generic_file_write calls vmtruncate without i_sem held.  Is
>> that intentional?  It should cause problems for reiserfs at least...
> 
> Erm... generic_file_write() grabs i_sem upon entry and drops it on exit.
> This call of vmtruncate() is deep inside the protected area.
> 

Yup, I'm trying to track down a different problem, and saw what I wanted to
instead of what was really there.  Sigh.  

-chris

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

can't build small enough zImage for floppy

[Jordan]

1st, the Sony Vaio Z505HS appears to be an example of a machine which
will not boot a bzImage correctly, compaining about the compression
format.

2nd, trying to build kernel 2.4.0, I stripped out or module-ized
everything I could (I think) including SCSCI support, the smallest I've
gotten zImage (under 600k) is still too big!

I don't know what else to try.

Thanks for any suggestions.

Jordan



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

[PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o

[Shawn Starr]

Here's something strange that i've been noticing with 2.4.0. Some websites I am
unable to access now. For example:

http://www.scotiabank.ca/simplify/index.html

if your in Canada and you have Scotia banking online, try and access their
banking sites. It will just hang. However upon trying the same in Windows 2000
(cough). The site works fine.

Could there be a network driver issue as even trying with telnet port 80 fails
as well?

Im not sure on this one this seems bizarre. I have the same problem with
www.workopolis.com, theglobeandmail.com, perhaps there's some sort of packet or
frame not being processed properly?

I can ICMP ping all the sites fine and i can access them from other shells.
I have spoken to some of their engineers and they say that there is nothing
blocking/no firewalls configured to deny access to theses sites.

If there's any information you need I'd be glad to try and figure this one out.

Shawn S.



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