lp with kernel 2.2.18

[LAMBERT Bernard]

Hi,

i don't know if it is a bug but I report it
Mother board gigabytes GA 7ZX (via chipset)
Duron 700 Mhz
I have attached file which give information to kernel, modules and so
on
The initial version of kernel whas built with Suse 6.4 distrib and it
is a 2.2.14 kernel patched for Dvd
Kde is 1.1
XFree is 4.01
description of bug :
If i use kernel 2.2.14 at boot i can use lpd without problems, all queues
are working
if i use my new kernel 2.2.18 , i can print and /dev/lp0, lp1 are présent
It looks like kernel  dont communicate with the socket printer
?
the error message at boot time is in the attached file boot.txt
regards
 

Jan 14 07:53:47 bl modprobe: modprobe: Can't locate module char-major-5
Jan 14 08:00:51 bl modprobe: modprobe: Can't locate module char-major-6 


processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 3
model name  : AMD Athlon(tm) Processor
stepping: 0
cpu MHz : 701.614
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 
psn mmxext mmx fxsr 3dnowext 3dnow
bogomips: 1399.19



-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux bl 2.2.18 #13 sam jan 13 21:46:04 CET 2001 i686 unknown
Kernel modules 2.3.9
Gnu C  2.95.2
Binutils   2.9.5.0.24
Linux C Libraryx   1 root root  4060896 Sep  5 13:57 /lib/libc.so.6
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount  2.10f
Net-tools  1.54
Kbd0.99
Sh-utils   2.0
Modules Loaded usb-uhci usbcore ne2k-pci 8390 hisax isdn slhc apci97 audiobuf 
pnp midi ac97 soundbase sndshield


usb-uhci   19044   0 (unused)
usbcore26436   0 [usb-uhci]
ne2k-pci4232   1 (autoclean)
83906228   0 (autoclean) [ne2k-pci]
hisax 135488   3
isdn  113716   4 [hisax]
slhc4500   1 [isdn]
apci97 13784   0
audiobuf   10792   0 [apci97]
pnp49552   0 [apci97]
midi   28228   0 [apci97 pnp]
ac975256   0 [apci97]
soundbase 313956   0 [apci97 audiobuf pnp midi ac97]
sndshield   5684   0 [apci97 audiobuf pnp midi ac97 soundbase]


Attached devices: 
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: Seagate  Model: STT8000N Rev: 3.22
  Type:   Sequential-AccessANSI SCSI revision: 02


Linux version 2.2.18 (root@bl) (gcc version 2.95.2 19991024 (release)) #13 sam jan 13 
21:46:04 CET 2001


begin:vcard 
n:LAMBERT;Bernard
tel;cell:0680177210
tel;home:0169833795
x-mozilla-html:FALSE
adr:;;4 rue des primeveres;YERERS;;91330;FRANCE
version:2.1
email;internet:[EMAIL PROTECTED]
note;quoted-printable:Close the windows and the gate,=0D=0AOpen you mind ,=0D=0Athink innovation=0D=0Athink linux or Unix
x-mozilla-cpt:;-16160
fn:LAMBERT bernard
end:vcard

Re: Ingo's RAID patch for 2.2.18 final?

[junio]

> "GL" == Godfrey Livingstone <[EMAIL PROTECTED]> writes:

GL> There is as yet no official patch for raid 0.90 for 2.2.18

GL> This question would be better asked on  linux raid list
GL> [EMAIL PROTECTED]

What is at 
look official enough to me...

raid-2.2.18-B0  12-Jan-2001 10:18   392k

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

eth1: Transmit timed out, status 0000, PHY status 0000

[Mike A. Harris]

What might be a reason I'm seeing this?

Becker's latest via-rhine driver ontop 2.2.18..

...
eth1: Transmit timed out, status , PHY status ,
resetting...
eth1: Transmit timed out, status , PHY status ,
resetting...
eth1: Transmit timed out, status , PHY status ,
resetting...
eth1: Transmit timed out, status , PHY status ,
resetting...
eth1: Transmit timed out, status , PHY status ,
resetting...
eth1: Transmit timed out, status , PHY status ,
resetting...

Keeps going nonstop until I ifdown eth1.

Card worked fine 2 days ago...


--
Mike A. Harris  -  Linux advocate  -  Free Software advocate
  This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--


Windows 95(n) - 32-bit extensions and graphical shell for a 16-bit patch
to an 8-bit operating system originally coded for a 4-bit microprocessor,
written by a 2-bit company that can't stand 1 bit of competition. 

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

set_page_dirty/page_launder deadlock

[Marcelo Tosatti]

Hi,

While taking a look at page_launder()...

 /* And re-start the thing.. */
 spin_lock(_lru_lock);  <--
 if (result != 1)
continue;
 /* writepage refused to do anything */
 set_page_dirty(page);
 
 goto page_active;
}


set_page_dirty() may lock the pagecache_lock which means potential
deadlock since we have the pagemap_lru_lock locked.


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

Re: Ingo's RAID patch for 2.2.18 final?

[Godfrey Livingstone]

There is as yet no official patch for raid 0.90 for 2.2.18

This question would be better asked on  linux raid list
[EMAIL PROTECTED]

You can apply the patches below.

If you apply the following you get the raid patched kernel.

 
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre25/VM-global-2.2.18pre25-7.bz2

You MUST apply this patch before the two raid patches. The VM patch stablises
the 2.2.18 virtual memory system and if you don't apply my two repackaged
patches will fail. The above VM patch has been accepted into 2.2.19pre3 and
many people are using it so is not untested.

Raid patches.

 http://www.hattaway-associates.com/raidpatches/raid-2.2.18-A2.bz2

For faster raid 1

 http://www.hattaway-associates.com/raidpatches/raid1readbalance-2.2.18.bz2

Hope this helps

Godfrey Livingstone



Jens Petersohn wrote:

> My appologies if this has been asked before. I'm looking for
> Ingo Molnar's RAID patch for 2.2.18-final. I tried applying A2, but
> it has a number of conflicts in raid1.c which I cannot resolve in
> my meager spare time.
>
> Thanks in advance,
>
> --Jens Petersohn
> -
> To unsubscribe from this list: send 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: Where did vm_operations_struct->unmap in 2.4.0 go?

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
David Woodhouse  <[EMAIL PROTECTED]> wrote:
>
>We don't need to overdesign it. get_module_symbol() basically provided
>this for us. The only thing really wrong with it was the lack of use
>count handling, which I fixed a while ago.

NO NO NO!

You miss _entirely_ the reason why "get_module_symbol()" was removed,
and why I will not _ever_ accept it coming back.

Hint #1: get_MODULE_symbol().

Hint #2: compiled in functionality.

The fact is, that get_module_symbol() was seriously and totally
mis-designed from the very beginning, and it was removed for THAT
reason, and it had nothing at all to do with the count handling.

So stop this discussion. It's not coming back. Live with the current
interfaces.

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

[Tony Parsons]

In-Reply-To: <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
(Bryan O'Sullivan) wrote:

>   /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 { 
> DriveReady SeekComplete Error }   hda: dma_intr: error=0x84 { 
> DriveStatusError BadCRC }   hda: dma_intr: status=0x51 { DriveReady 
> SeekComplete Error }   hda: dma_intr: error=0x84 { DriveStatusError 
> BadCRC }   hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } 
...
>   00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 
> 02)
>   00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
>   00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] 
> (rev 22)
>   00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] 
> (rev 10)
>   00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
>   00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
>   00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super 
> ACPI] (rev 30)
It's not an Abit KT7 or similar is it?
I was just helping my dad upgrade a machine based with one of those to 2.4 
today and until we turned off Generic PCI bus-master DMA Support and the 
VIA82CXXX drivers we kept getting the same messages the second the system 
booted up. 
It was rather annoying, as I'm not sure if it was because of this or 
something else, but we ended up with some minor disk corruption mainly 
around /usr/src/linux where I made the mistake of doing a make mrproper 
while it was like this. Went back to 2.2 temporarily and it was fine.
Can dig out/try anything on request.

TonyP
[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: Linux 2.4.0-ac9

[Steven Cole]

On Saturday 13 January 2001 20:05, Karsten Hopp wrote:
> You need to enable CONFIG_SWAPFS.
> Those functions are enclosed by #ifdef CONFIG_SWAPFS and #endif, but
> the references to them aren't.
>
>   Karsten
>
> On Sat, Jan 13, 2001 at 06:40:40PM -0700, Steven Cole wrote:
> > I got the following error while building 2.4.0-ac9:
> >
> > shmem.c:971: `shmem_readlink' undeclared here (not in a function)
> > shmem.c:971: initializer element is not constant
> > shmem.c:971: (near initialization for
> > `shmem_symlink_inode_operations.readlink')
> > shmem.c:972: `shmem_follow_link' undeclared here (not in a function)
> > shmem.c:972: initializer element is not constant
> > shmem.c:972: (near initialization for
> > `shmem_symlink_inode_operations.follow_link')
> > shmem.c:973: initializer element is not constant
> > shmem.c:973: (near initialization for `shmem_symlink_inode_operations')
> > shmem.c:973: initializer element is not constant
> > shmem.c:973: (near initialization for `shmem_symlink_inode_operations')
> > make[2]: *** [shmem.o] Error 1
> >

Yes, enabling CONFIG_SWAPFS works just fine:

[scole@localhost scole]$ uname -a
Linux localhost.localdomain 2.4.0-ac9 #2 Sat Jan 13 20:23:00 MST 2001 i686 
unknown

Here is a little patch which also fixes the symptoms of the build problem, and
makes a kernel 1510 bytes smaller (without CONFIG_SWAPFS).  Someone more 
knowlegable than I will have to verify its correctness.  

This patch is against 2.4.0-ac9.

--- linux/mm/shmem.c.orig   Sat Jan 13 20:23:36 2001
+++ linux/mm/shmem.cSat Jan 13 20:27:32 2001
@@ -968,8 +968,10 @@
 
 static struct inode_operations shmem_symlink_inode_operations = {
truncate:   shmem_truncate,
+#ifdef CONFIG_SWAPFS
readlink:   shmem_readlink,
follow_link:shmem_follow_link,
+#endif
 };
 
 static struct file_operations shmem_dir_operations = {
-
To unsubscribe from this list: send the 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

[TimO]

Vojtech Pavlik wrote:
> 
> Ok, here goes the patch.
> 
> Note that with this patch, all VIA users will get IDE transferrates
> about 3 MB/sec as opposed to about 20 MB/sec without it (and with
> UDMA66).
> 
> This patch disables automatic DMA on all VIA chipsets, including the
> ancient 82c561 for 486's, and up to the 686a UDMA66 chipset.
> 
> Also note that enabling the DMA later with hdparm -X66 -d1 or similar
> command is not safe, and usually works by pure luck on VIA chipsets.
> This however, would need some non-minor changes to the generic code to
> fix.
> 
> But perhaps it's still worth ...
> 
> --
> Vojtech Pavlik
> SuSE Labs
> 
>

_ouch_  Will -X66 -d1c1m16 be as stable with this patch as version 2.1e
has been for me??  It has always (auto)set transfer speeds properly and
I have never seen corruption with my 686a -- 'cept when patching from
test11-pre7 to test12-pre1, and I'm pretty sure that was from other
factors.

===
-- Tim
-
To unsubscribe from this list: send 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: patch for range support + accumulated patches

[Christoph Lameter]

The following patch adds the following functionality to khttpd:

- Range support. Only simple ranges (from-to) are supported. Range suport
  enables the debian apt tool to resume aborted http file-transfers. Very
  important if one plans to run a kernel/debian mirror with khttpd.

- Virtual Host support (see docs in patch)

- Persistant connections

- simple logging via printk if /proc/sys/net/khttpd/logging is set to 1.

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/datasending.c linux/net/khttpd/datasending.c
--- linux-orig/net/khttpd/datasending.c Fri Nov 17 11:36:27 2000
+++ linux/net/khttpd/datasending.c  Sat Jan 13 17:58:21 2001
@@ -105,7 +105,7 @@

Space = sock_wspace(CurrentRequest->sock->sk);

-   ReadSize = min(4*4096,CurrentRequest->FileLength - 
CurrentRequest->BytesSent);
+   ReadSize = min(4*4096,CurrentRequest->End - 
+(CurrentRequest->BytesSent+CurrentRequest->Offset));
ReadSize = min(ReadSize , Space );
 
if (ReadSize>0)
@@ -119,7 +119,7 @@
read_descriptor_t desc;
loff_t *ppos;

-   CurrentRequest->filp->f_pos = 
CurrentRequest->BytesSent;
+   CurrentRequest->filp->f_pos = 
+CurrentRequest->BytesSent+CurrentRequest->Offset;
 
ppos = >filp->f_pos;
 
@@ -137,7 +137,7 @@
else  /* FS doesn't support sendfile() */
{
mm_segment_t oldfs;
-   CurrentRequest->filp->f_pos = 
CurrentRequest->BytesSent;
+   CurrentRequest->filp->f_pos = 
+CurrentRequest->BytesSent+CurrentRequest->Offset;

oldfs = get_fs(); set_fs(KERNEL_DS);
retval = 
CurrentRequest->filp->f_op->read(CurrentRequest->filp, Block[CPUNR], ReadSize, 
>filp->f_pos);
@@ -160,7 +160,7 @@
   If end-of-file or closed connection: Finish this request 
   by moving it to the "logging" queue. 
*/
-   if ((CurrentRequest->BytesSent>=CurrentRequest->FileLength)||
+   if 
+((CurrentRequest->BytesSent+CurrentRequest->Offset>=CurrentRequest->End)||
(CurrentRequest->sock->sk->state!=TCP_ESTABLISHED
 && CurrentRequest->sock->sk->state!=TCP_CLOSE_WAIT))
{
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");
+   
+   

Re: Linux 2.4.0-ac9

[Karsten Hopp]

You need to enable CONFIG_SWAPFS.
Those functions are enclosed by #ifdef CONFIG_SWAPFS and #endif, but 
the references to them aren't.

  Karsten


On Sat, Jan 13, 2001 at 06:40:40PM -0700, Steven Cole wrote:
> I got the following error while building 2.4.0-ac9:
> 
> shmem.c:971: `shmem_readlink' undeclared here (not in a function)
> shmem.c:971: initializer element is not constant
> shmem.c:971: (near initialization for 
> `shmem_symlink_inode_operations.readlink')
> shmem.c:972: `shmem_follow_link' undeclared here (not in a function)
> shmem.c:972: initializer element is not constant
> shmem.c:972: (near initialization for 
> `shmem_symlink_inode_operations.follow_link')
> shmem.c:973: initializer element is not constant
> shmem.c:973: (near initialization for `shmem_symlink_inode_operations')
> shmem.c:973: initializer element is not constant
> shmem.c:973: (near initialization for `shmem_symlink_inode_operations')
> make[2]: *** [shmem.o] Error 1
> 
> It looks like changes were recently made to linux/mm/shmem.c.
> 

--
 Karsten Hopp| Mail: [EMAIL PROTECTED] |
 Red Hat Deutschland |[EMAIL PROTECTED] | SAP-AG LinuxLab
 Hauptstaetterstr.58 | Tel: +49-711-96437-0| Neurottstrasse 16
 D-70178 Stuttgart   | http://www.redhat.de| 69190 Walldorf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0-ac9 (shmem.c errors)

[Mark Orr]

On 14-Jan-2001 Steven Cole wrote:
> I got the following error while building 2.4.0-ac9:
> 
> shmem.c:971: `shmem_readlink' undeclared here (not in a function)
> shmem.c:971: initializer element is not constant
> shmem.c:971: (near initialization for 
> `shmem_symlink_inode_operations.readlink')
> shmem.c:972: `shmem_follow_link' undeclared here (not in a function)
> shmem.c:972: initializer element is not constant
> shmem.c:972: (near initialization for 
> `shmem_symlink_inode_operations.follow_link')
> shmem.c:973: initializer element is not constant
> shmem.c:973: (near initialization for `shmem_symlink_inode_operations')
> shmem.c:973: initializer element is not constant
> shmem.c:973: (near initialization for `shmem_symlink_inode_operations')
> make[2]: *** [shmem.o] Error 1
> 
> It looks like changes were recently made to linux/mm/shmem.c.

I'm getting the same errors here.  Christoph Rohland submitted
a series of shm patches to the list -- I tried --dry-run reapplying
them and at least a couple of them partially applied.  Looks like
it didnt all get integrated.

--
Mark Orr
[EMAIL PROTECTED]

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

RE: 2.4.0 oops bdflush

[Matt_Domsch]

> From: Stephen Clouse [mailto:[EMAIL PROTECTED]]
> We have a development SMP machine which runs a myriad of 
> server applications for
> our development purposes -- Apache, Oracle, several others.  
> Under 2.4.0 the
> machine locks up, seemingly at random.  Usually it simply 
> stops responding
> without fanfare -- you can, oddly enough, switch consoles 
> with Alt+F?, but
> typing gets no response and all network services have stopped
> responding.

I've seen exactly this same behavior, on an 8-way Xeon (Dell PowerEdge
8450), with 8GB RAM, but never with either 512MB or 1GB, running 20
instances of a copy-and-compare script using /usr/share/doc from Red Hat
Linux 7 as the data source.  I see you're using IDE disks, which makes me
feel better, as I was testing the new megaraid driver.  Magic sysrq works in
my case.  I've never gotten the oops though, I used magic sysrq to print the
IP several times and then tried to look it up.  For me, lockup happens in
the first few minutes of running this test.  I'm happy to try to reproduce
it if anyone has suggestions.

Thanks,
Matt






-
To unsubscribe from this list: send 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 oops bdflush

[Stephen Clouse]

We have a development SMP machine which runs a myriad of server applications for
our development purposes -- Apache, Oracle, several others.  Under 2.4.0 the
machine locks up, seemingly at random.  Usually it simply stops responding
without fanfare -- you can, oddly enough, switch consoles with Alt+F?, but
typing gets no response and all network services have stopped
responding.  However, on the most recent failure I was lucky enough to find that
it had managed to spit out a kernel oops message before biting it, which I have 
(hopefully) decoded (properly):

root@fs1:/usr/src/linux.2.4.0# ksymoops -v /usr/src/linux.2.4.0/vmlinux -m \
 /usr/src/linux.2.4.0/System.map -o /lib/modules/2.4.0/
ksymoops 2.3.7 on i686 2.2.18.  Options used
 -v /usr/src/linux.2.4.0/vmlinux (specified)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0/ (specified)
 -m /usr/src/linux.2.4.0/System.map (specified)

Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Reading Oops report from the terminal
invalid operand: 
CPU:0
EIP:0010:[]
EFLAGS: 00010296
eax: 001c   ebx: c1068518   ecx:    edx: 0026
esi: c10684fc   edi: 021c   ebp: 0001   esp: c14f9fa4
ds: 0018   es: 0018   ss: 0018
Process bdflush (pid: 5, stackpage=c14f9000)
Stack: c01f9865 c01f9a24 0299 c14f8000 c01fb96e  0008e000 
   0004 0040  0110 c01369c2 0007  00010f00
   cff93f84 cff93fd0 0008e000 c0107507 cff93fbc cff93fbc cff93fbc
Call Trace: [] []
Code: 0f 0b 83 c4 0c 90 8b 46 14 85 c0 75 19 68 99 02 00 00 68 24
invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010296
eax: 001c   ebx: c1068518   ecx:    edx: 0026
esi: c10684fc   edi: 021c   ebp: 0001   esp: c14f9fa4
ds: 0018   es: 0018   ss: 0018
Process bdflush (pid: 5, stackpage=c14f9000)
Stack: c01f9865 c01f9a24 0299 c14f8000 c01fb96e  0008e000 
   0004 0040  0110 c01369c2 0007  00010f00
   cff93f84 cff93fd0 0008e000 c0107507 cff93fbc cff93fbc cff93fbc
Call Trace: [] []
Code: 0f 0b 83 c4 0c 90 8b 46 14 85 c0 75 19 68 99 02 00 00 68 24

>>EIP; c012c37e<=
Trace; c01369c2 
Trace; c0107507 
Code;  c012c37e 
 <_EIP>:
Code;  c012c37e<=
   0:   0f 0b ud2a  <=
Code;  c012c380 
   2:   83 c4 0c  addl   $0xc,%esp
Code;  c012c383 
   5:   90nop
Code;  c012c384 
   6:   8b 46 14  movl   0x14(%esi),%eax
Code;  c012c387 
   9:   85 c0 testl  %eax,%eax
Code;  c012c389 
   b:   75 19 jne26 <_EIP+0x26> c012c3a4 
Code;  c012c38b 
   d:   68 99 02 00 00pushl  $0x299
Code;  c012c390 
  12:   68 24 00 00 00pushl  $0x24

This machine has been running flawlessly on 2.2.18 for weeks now, which seems to
preclude a hardware issue.  And since I've been personally running 2.4.0 on my
uniprocessor machine since day one without incident, I suspect some bizarre
interaction in SMP-land.  But I'm hardly a kernel programmer

Unforunately I can't find exact specs on the machine; it's a Dell Precision 420,
most likely built with the hardware du jour about six months ago.  The config
options used are below:

CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_M686FXSR=y
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_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_BLK_DEV_FD=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_SYN_COOKIES=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
CONFIG_RTC=y
CONFIG_QUOTA=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_MINIX_FS=y

Re:2.4.1-pre3 compile problems

[Garst R. Reese]

Thanks Keith,
I did a make mrproper and that solved the problem.
I thought I had done that already, but must have screwed up somewhere.
Garst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Call for testers: ne2k-pci and io apic

[J . A . Magallon]

On 2001.01.13 Manfred Spraul wrote:
> 
> Any volunteers with ne2k-pci cards and other motherboards that include
> an io apic (e.g. all Intel motherboards that use an IO Controller Hub,
> Via Apollo Pro133, Pro133A, KX133)?
> 

In my case, (440GX/BX, PIIX4), network goes off (both with a ping-flood
or some web browsing) with a message:

Jan 14 03:01:25 werewolf kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jan 14 03:01:57 werewolf last message repeated 19 times


-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.0-ac9 #2 SMP Sun Jan 14 01:46:07 CET 2001 i686

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

Re: Linux 2.4.0-ac9

[Steven Cole]

I got the following error while building 2.4.0-ac9:

shmem.c:971: `shmem_readlink' undeclared here (not in a function)
shmem.c:971: initializer element is not constant
shmem.c:971: (near initialization for 
`shmem_symlink_inode_operations.readlink')
shmem.c:972: `shmem_follow_link' undeclared here (not in a function)
shmem.c:972: initializer element is not constant
shmem.c:972: (near initialization for 
`shmem_symlink_inode_operations.follow_link')
shmem.c:973: initializer element is not constant
shmem.c:973: (near initialization for `shmem_symlink_inode_operations')
shmem.c:973: initializer element is not constant
shmem.c:973: (near initialization for `shmem_symlink_inode_operations')
make[2]: *** [shmem.o] Error 1

It looks like changes were recently made to linux/mm/shmem.c.

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

IO-APIC and ne2000 PCI [Manfred's test]

[Alessandro Suardi]

Hi Manfred,

  patch applied, enabled IO-APIC UP support but it doesn't show for my
  ne2k PCI card... this is on 2.4.1-pre3 (plus your patch obviously).

[asuardi@wish asuardi]$ cat /proc/interrupts
   CPU0   
  0:  39630  XT-PIC  timer
  1:916  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  9:1321915  XT-PIC  usb-uhci, usb-uhci, eth0
 11:  0  XT-PIC  acpi
 12: 48  XT-PIC  PS/2 Mouse
 14:  14020  XT-PIC  ide0
 15:  6  XT-PIC  ide1
NMI:  0 
ERR:  0

Only stuff I get at boot is this:

[root@wish /root]# dmesg | grep APIC
mapped APIC to e000 (01222000)

ping -f for 1 minute to my laptop, ~190K pings per session, eth0 works.
[so it's a Yes]

Board is a Gigabyte GA7ZM with a K7-800.

00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
Flags: bus master, medium devsel, latency 0
Memory at e000 (32-bit, prefetchable) [size=4M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00: 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00
10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00

00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal 
decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 9000-9fff
Memory behind bridge: dbe0-dbef
Prefetchable memory behind bridge: d7c0-d7cf
00: 06 11 05 83 07 00 30 22 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 90 90 00 00
20: e0 db e0 db c0 d7 c0 d7 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Flags: bus master, stepping, medium devsel, latency 0
00: 06 11 86 06 87 00 10 02 22 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 86 06
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 
8a [Master SecP PriP])
Flags: bus master, medium devsel, latency 32
I/O ports at ffa0 [size=16]
Capabilities: [c0] Power Management version 2
00: 06 11 71 05 07 00 90 02 10 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: a1 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 00 00

00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 
[UHCI])
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 64, IRQ 9
I/O ports at c800 [size=32]
Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 22 10 00 03 0c 08 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 c8 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 09 04 00 00

00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 
[UHCI])
Subsystem: Unknown device 0925:1234
Flags: bus master, medium devsel, latency 64, IRQ 9
I/O ports at cc00 [size=32]
Capabilities: [80] Power Management version 2
00: 06 11 38 30 17 00 10 22 10 00 03 0c 08 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 cc 00 00 00 00 00 00 00 00 00 00 25 09 34 12
30: 00 00 00 00 80 00 00 00 00 00 00 00 09 04 00 00

00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
Flags: medium devsel
Capabilities: [68] Power Management version 2
00: 06 11 57 30 00 00 90 02 30 00 05 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00

00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super 
AC97/Audio] (rev 20)
Subsystem: Giga-byte Technology: Unknown device 5348
Flags: medium devsel, IRQ 10
I/O ports at d800 [size=256]
I/O ports at d400 [size=4]
I/O ports at d000 [size=4]
Capabilities: [c0] Power Management version 2
00: 06 11 58 30 01 00 10 02 20 00 01 04 00 00 00 00
10: 01 d8 00 00 01 d4 00 00 01 d0 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 48 53
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0a 03 00 00

00:09.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 
00 [VGA])
Subsystem: 3Dfx Interactive, Inc.: Unknown device 0057
Flags: fast devsel, IRQ 11
Memory at de00 (32-bit, non-prefetchable) [size=32M]
Memory at 

Re: sparc10 with 512M of RAM hangs on boot

[Anton Blanchard]

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

Yep I know about this but need to iron out another bug with the patches
before I commit them.

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: [PATCH] plan9 partition support

[Andries . Brouwer]

> the patch locates partitions inside the plan9

> i can't find anyone with plan9 to test,

I'll have a look.
A week ago you sent almost the same patch.
Was there a reason to change __u32 into unsigned long?

Andries
-
To unsubscribe from this list: send the 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-lvm] Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Anton Blanchard]

 
> The longs are the biggest problem AFAICS.
> long is 64bit on sparc64 and 32bit on sparc32...

Embedding pointers in ioctls is much worse. When this happens we basically
end up duplicating the ioctl parsing code (this code courtesy of jakub's
sharp mind, but it would be nice not to require this :)

Anton

case VG_CREATE:
v = kmalloc(sizeof(vg_t), GFP_KERNEL);
if (!v) return -ENOMEM;
if (copy_from_user(v, (void *)arg, (long)&((vg32_t *)0)->proc) ||
__get_user(v->proc, &((vg32_t *)arg)->proc)) {
kfree(v);
return -EFAULT;
}
karg = v;
memset(v->pv, 0, sizeof(v->pv) + sizeof(v->lv));
if (v->pv_max > ABS_MAX_PV || v->lv_max > ABS_MAX_LV)
return -EPERM;
for (i = 0; i < v->pv_max; i++) {
err = __get_user(ptr, &((vg32_t *)arg)->pv[i]);
if (err) break;
if (ptr) {
v->pv[i] = kmalloc(sizeof(pv_t), GFP_KERNEL);
if (!v->pv[i]) {
err = -ENOMEM;
break;
}
err = copy_from_user(v->pv[i], (void *)A(ptr), 
sizeof(pv32_t) - 8);
if (err) {
err = -EFAULT;
break;
}
v->pv[i]->pe = NULL; v->pv[i]->inode = NULL;
}
}
if (!err) {
for (i = 0; i < v->lv_max; i++) {
err = __get_user(ptr, &((vg32_t *)arg)->lv[i]);
if (err) break;
if (ptr) {
v->lv[i] = get_lv_t(ptr, );
if (err) break;
}
}
}
break;
-
To unsubscribe from this list: send the 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

[Mike A. Harris]

On Fri, 12 Jan 2001, Shawn Starr wrote:

Snoop through /proc, and you'll find a file where you can disable
"ecn" support.

echo 0 > /proc



>Date: Fri, 12 Jan 2001 16:37:35 -0500
>From: Shawn Starr <[EMAIL PROTECTED]>
>To: Donald Becker <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> [EMAIL PROTECTED]
>Content-Type: text/plain; charset=iso-8859-15
>Subject: [PROBLEM]: Strange network problems with 2.4.0 and 3c59x.o
>
>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/
>



--
Mike A. Harris  -  Linux advocate  -  Free Software advocate
  This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--

VMS is a text-only adventure game. If you win you can use unix.

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

Re: Latency: allowing resheduling while holding spin_locks

[george anzinger]

Nigel Gamble wrote:
> 
> On Sat, 13 Jan 2001, Roger Larsson wrote:
> > A rethinking of the rescheduling strategy...
> 
> Actually, I think you have more-or-less described how successful
> preemptible kernels have already been developed, given that your
> "sleeping spin locks" are really just sleeping mutexes (or binary
> semaphores).
> 
> 1.  Short critical regions are protected by spin_lock_irq().  The maximum
> value of "short" is therefore bounded by the maximum time we are happy
> to disable (local) interrupts - ideally ~100us.
> 
> 2.  Longer regions are protected by sleeping mutexes.
> 
> 3.  Algorithms are rearchitected until all of the highly contended locks
> are of type 1, and only low contention locks are of type 2.
> 
> This approach has the advantage that we don't need to use a no-preempt
> count, and test it on exit from every spinlock to see if a preempting
> interrupt that has caused a need_resched has occurred, since we won't
> see the interrupt until it's safe to do the preemptive resched.

I agree that this was true in days of yore.  But these days the irq
instructions introduce serialization points and, me thinks, may be much
more time consuming than the "++, --, if (false)" that a preemption
count implemtation introduces.  Could some one with a knowledge of the
hardware comment on this?

I am not suggesting that the "++, --, if (false)" is faster than an
interrupt, but that it is faster than cli, sti.  Of course we are
assuming that there is  between the cli and the sti as there is
between the ++ and the -- if (false).

George

> 
> 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: HP Pavilion 8290 HANGS on boot 2.4/2.4-test9

[Keith Owens]

On Sat, 13 Jan 2001 16:12:13 -0500 (EST), 
Werner Puschitz <[EMAIL PROTECTED]> wrote:
>Is there a safe way to add debug information like simple string prints in
>arch/i386/boot/compressed/head.s and in arch/i386/kernel/head.S
>so that I can see at the console where the boot process hangs?

Time for another version of my VIDEO_CHAR patch.

-

If a kernel hangs early in the boot process (before the console has
been initialized) then printk is no use because you never see the
output.  There is a technique for using the video display to indicate
boot progress so you can localize the problem.  Reporting "my kernel
hangs during boot at line nnn in routine xyz" is a lot better than "my
kernel hangs during boot".

The idea is to write characters direct to the video screen during
booting using a macro called VIDEO_CHAR.  This macro takes a character
position and a single character value to be displayed.  Use different
positions on the screen for different levels of code and use different
characters in one position to indicate which stage that level is up to.
For example, with the patch below, the string EAC at hang indicates
parse_options(), checksetup().

The patch below is generic, except for the definition of VIDEO_CHAR
which is ix86 specific.  If this patch ever becomes part of the main
kernel then VIDEO_CHAR needs to be moved to an arch specific header.
If any arch other than ix86 uses this technique, please mail
[EMAIL PROTECTED] with your definition of VIDEO_CHAR.

You can plant VIDEO_CHAR calls anywhere you like, up to the call to
mem_init().  After mem_init has done its work and memory has been
remapped, VIDEO_CHAR cannot write to video memory, it will oops.
However by then the console has been initialized so you can use printk.

Demonstration patch against 2.4.0.  This only uses screen positions 0,
1, 2.  If you want to drill down into lower level routines, just use
screen positions 3 onwards.  To activate the debugging, add

#define DEBUG_VIDEO_CHAR

to the start of init/main.c.

Index: 0.1/init/main.c
--- 0.1/init/main.c Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/k/11_main.c 1.1 
644)
+++ 0.1(w)/init/main.c Sun, 14 Jan 2001 11:27:20 +1100 kaos (linux-2.4/k/11_main.c 1.1 
+644)
@@ -77,6 +77,13 @@ extern int con3215_activate(void);
 #error Sorry, your GCC is too old. It builds incorrect kernels.
 #endif
 
+#ifdef DEBUG_VIDEO_CHAR
+/* ix86 specific */
+#define VIDEO_CHAR(c, v) (*((volatile char *)(0xb8000 + 2*(c))) = (v))
+#else
+#define VIDEO_CHAR(c, v)
+#endif
+
 extern char _stext, _etext;
 extern char *linux_banner;
 
@@ -432,12 +439,14 @@ static void __init parse_options(char *l
char *next,*quote;
int args, envs;
 
+   VIDEO_CHAR(1, 'A');
if (!*line)
return;
args = 0;
envs = 1;   /* TERM is set to 'linux' by default */
next = line;
while ((line = next) != NULL) {
+   VIDEO_CHAR(2, 'A');
 quote = strchr(line,'"');
 next = strchr(line, ' ');
 while (next != NULL && quote != NULL && quote < next) {
@@ -450,9 +459,11 @@ static void __init parse_options(char *l
 next = strchr(next+1, ' ');
 }
 }
+   VIDEO_CHAR(2, 'B');
 if (next != NULL)
 *next++ = 0;
if (!strncmp(line,"init=",5)) {
+   VIDEO_CHAR(3, 'A');
line += 5;
execute_command = line;
/* In case LILO is going to boot us with default command line,
@@ -463,8 +474,10 @@ static void __init parse_options(char *l
args = 0;
continue;
}
+   VIDEO_CHAR(2, 'C');
if (checksetup(line))
continue;
+   VIDEO_CHAR(2, 'D');

/*
 * Then check if it's an environment variable or
@@ -480,9 +493,12 @@ static void __init parse_options(char *l
if (*line)
argv_init[++args] = line;
}
+   VIDEO_CHAR(2, 'E');
}
+   VIDEO_CHAR(1, 'B');
argv_init[args+1] = NULL;
envp_init[envs+1] = NULL;
+   VIDEO_CHAR(1, 'C');
 }
 
 
@@ -526,16 +542,27 @@ asmlinkage void __init start_kernel(void
  * Interrupts are still disabled. Do necessary setups, then
  * enable them
  */
+   VIDEO_CHAR(0, 'A');
lock_kernel();
+   VIDEO_CHAR(0, 'B');
printk(linux_banner);
+   VIDEO_CHAR(0, 'C');
setup_arch(_line);
+   VIDEO_CHAR(0, 'D');
printk("Kernel command line: %s\n", saved_command_line);
+   VIDEO_CHAR(0, 'E');
parse_options(command_line);
+   VIDEO_CHAR(0, 'F');
trap_init();
+   VIDEO_CHAR(0, 'G');
init_IRQ();
+   VIDEO_CHAR(0, 'H');

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

[Frank de Lange]

On Sun, Jan 14, 2001 at 12:13:58AM +, Roeland Th. Jansen wrote:
> On Fri, Jan 12, 2001 at 09:03:49PM +0100, Ingo Molnar wrote:
> > well, some time ago i had an ne2k card in an SMP system as well, and found
> > this very problem. Disabling/enabling focus-cpu appeared to make a
> > difference, but later on i made experiments that show that in both cases
> > the hang happens. I spent a good deal of time trying to fix this problem,
> > but failed - so any fresh ideas are more than welcome.
> 
> for the record. my BP6, non OC, apic smp system with ne2k fails within
> 24 hours here too. if I can be of any help. (2.4.0. kernel. no
> vmware or opensound)

You can help yourself by applying Manfred's patch to 8390.c (in preference to
my own patch to the same file). This will sove the hanging-network problem. If
your entire box hangs, that's another story which will probably not be fixed by
that patch. You can find the patch in Manfred's posting to the list from Fri
Jan 12 2001 - 14:04:24 EST.

I've been running a patched driver for more than a day now, under heavy network
load, without problems.

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: Call for testers: ne2k-pci and io apic (was: Re: QUESTION: Network hangs with BP6...)

[J . A . Magallon]

On 2001.01.13 Manfred Spraul wrote:
> 
> Please:
> * apply the attached patch.
> --
>   Manfred
> --- linux/arch/i386/kernel/apic.c Tue Dec  5 21:43:48 2000
> +++ linux/arch/i386/kernel/apic.c.new Sat Jan 13 15:54:56 2001
> @@ -270,7 +270,7 @@
>*   PCI Ne2000 networking cards and PII/PIII processors, dual
>*   BX chipset. ]
>*/
> -#if 0
> +#if 1
>   /* Enable focus processor (bit==0) */
>   value &= ~(1<<9);
>  #else
> 

In my 2.4.0-ac9, that code goes to line 315 and looks like:

 *   BX chipset. ]
 */
#if 0
/* Enable focus processor (bit==0) */
value &= ~APIC_SPIV_FOCUS_DISABLED;
#else
/* Disable focus processor (bit==1) */
value |= APIC_SPIV_FOCUS_DISABLED;
#endif
/*
 * Set spurious IRQ vector

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.0-ac8 #1 SMP Fri Jan 12 18:02:50 CET 2001 i686

-
To unsubscribe from this list: send the 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 Sat, 13 Jan 2001 15:09:40 + (GMT), 
David Woodhouse <[EMAIL PROTECTED]> wrote:
>Lack of [module symbol] runtime typechecking isn't a showstopper.

It is when users try to insert modules from kernel A into kernel B when
the ABI changed between A and B.  This is not type checking to catch
kernel programmers, it is ABI checking to catch user errors.

This is becoming more important as the kernel moves towards hot
plugging devices, especially for binary only drivers.  It is far better
for the kernel community if modutils can say "cannot load module foo
because its interfaces do not match the kernel, upgrade module foo".
That forces the maintenance load back onto the binary supplier and
removes the questions from l-k, including many of the oops reports with
binary only drivers in the module list.

Module symbol versions are the only way to catch ABI changes.  I do not
want to add a mechanism for accessing symbols dynamically if it cannot
detect ABI changes, it leaves the kernel open to difficult to diagnose
user errors.  I'm doing the hard work now to save everybody time later.

Ignore the fact that the existing module symbol version implementation
is broken as designed.  http://gear.torque.net/kbuild/archive/1280.html
lists the major problems with make dep, genksyms has all those problems
plus several of its own.  As part of the Makefile rewrite for 2.5, I am
redesigning module symbol versions from scratch.

I agree that inter_module_xxx does not check ABI.  That was not for
lack of trying, but it cannot be done in 2.4, it needs a major redesign
of module symbols and the makefiles.  It will be possible in 2.5.

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

Re: Call for testers: ne2k-pci and io apic

[J . A . Magallon]

On 2001.01.13 Manfred Spraul wrote:
> 
> Any volunteers with ne2k-pci cards and other motherboards that include
> an io apic (e.g. all Intel motherboards that use an IO Controller Hub,
> Via Apollo Pro133, Pro133A, KX133)?
> 
> Please:
> * apply the attached patch.
> * compile the kernel for SMP, or at least enable uniprocessor io apic
> support.
> * reboot..
> * flood ping the computer with 2 concurrent flood pings from a second
> computer.
> * wait one minute.
> 

Volunteer. Mine is a Realtek 8029:
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
Subsystem: Realtek Semiconductor Co., Ltd. RT8029(AS)
Flags: medium devsel, IRQ 11
I/O ports at ef40 [size=32]

Board: SuperMicro P6DGU (440GX,PIIX4), 256Mb, 2xPII@400(Deschutes,512Kb).
The only problem is that I just have a cable connection. Is it enough
a 'loopback' connection (ie, ping myself) ? Does it goes at least until
the card and generates interrupts or stops at the kernel soft level ?
Anyways, if a 128K connection can generate enough flood for you, i'll send
you my results. I am going to test it anyways...

dmesg selected info:
I/O APIC #2 Version 17 at 0xFEC0.
Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00
Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01
Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02
Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03
Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04
Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06
Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07
Int: type 0, pol 1, trig 1, bus 2, IRQ 08, APIC ID 2, APIC INT 08
Int: type 0, pol 0, trig 0, bus 2, IRQ 09, APIC ID 2, APIC INT 09
Int: type 0, pol 0, trig 0, bus 2, IRQ 0c, APIC ID 2, APIC INT 0c
Int: type 0, pol 0, trig 0, bus 2, IRQ 0d, APIC ID 2, APIC INT 0d
Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e
Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f
Int: type 0, pol 3, trig 3, bus 2, IRQ 0a, APIC ID 2, APIC INT 10
Int: type 0, pol 3, trig 3, bus 2, IRQ 0b, APIC ID 2, APIC INT 11
Int: type 0, pol 3, trig 3, bus 2, IRQ 0b, APIC ID 2, APIC INT 12
Int: type 0, pol 3, trig 3, bus 2, IRQ 05, APIC ID 2, APIC INT 13
Int: type 2, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 17
Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00
Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01
Processors: 2
mapped APIC to e000 (fee0)
mapped IOAPIC to d000 (fec0)
..
ENABLING IO-APIC IRQs
..changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-20, 2-21, 2-22, 2-23 not connected
.
.TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
testing NMI watchdog ... OK.
number of MP IRQ sources: 18.
number of IO-APIC #2 registers: 24.
testing the IO APIC...

IO APIC #2..
... register #00: 0200
..: physical APIC id: 02
... register #01: 00170011
.. : max redirection entries: 0017
.. : IO APIC version: 0011
... register #02: 
.. : arbitration: 00
... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  100   0   00000
 01 003 03  000   0   01139
 02 003 03  000   0   01131
 03 003 03  000   0   01141
 04 003 03  000   0   01149
 05 000 00  100   0   00000
 06 003 03  000   0   01151
 07 003 03  000   0   01159
 08 003 03  000   0   01161
 09 003 03  000   0   01169
 0a 000 00  100   0   00000
 0b 000 00  100   0   00000
 0c 003 03  000   0   01171
 0d 000 00  100   0   00000
 0e 003 03  000   0   01179
 0f 003 03  000   0   01181
 10 003 03  110   1   01189
 11 003 03  110   1   01191
 12 003 03  110   1   01191
 13 003 03  110   1   01199
 14 000 00  100   0   00000
 15 000 00  100   0   00000
 16 000 00  100   0   00000
 17 000 00  100   0   00000
IRQ to pin mappings:
IRQ0 -> 2
IRQ1 -> 1
IRQ3 -> 3
IRQ4 -> 4
IRQ5 -> 19
IRQ6 -> 6
IRQ7 -> 7
IRQ8 -> 8
IRQ9 -> 9
IRQ10 -> 16
IRQ11 -> 17-> 18
IRQ12 -> 12
IRQ13 -> 13
IRQ14 -> 14
IRQ15 -> 15
... done.
calibrating APIC timer ...
 CPU clock speed is 400.9147 MHz.
 host bus clock speed is 100.2284 MHz.
cpu: 0, clocks: 1002284, slice: 334094
CPU0
cpu: 1, clocks: 1002284, slice: 334094
CPU1
checking TSC synchronization across CPUs: passed.
Setting commenced=1, go go go
..
Board Vendor: 

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

[Roeland Th. Jansen]

On Fri, Jan 12, 2001 at 09:03:49PM +0100, Ingo Molnar wrote:
> well, some time ago i had an ne2k card in an SMP system as well, and found
> this very problem. Disabling/enabling focus-cpu appeared to make a
> difference, but later on i made experiments that show that in both cases
> the hang happens. I spent a good deal of time trying to fix this problem,
> but failed - so any fresh ideas are more than welcome.

for the record. my BP6, non OC, apic smp system with ne2k fails within
24 hours here too. if I can be of any help. (2.4.0. kernel. no
vmware or opensound)

-- 
Grobbebol's Home   |  Don't give in to spammers.   -o)
http://www.xs4all.nl/~bengel   | Use your real e-mail address   /\
Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v  
-
To unsubscribe from this list: send the 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-floppy [Fwd: Updated ATAPI FORMAT_UNIT patch.]

[Alan Cox]

> One of my concerns is that we don't take the ide-floppy driver in a
> different direction to the other removeable media drives.

In general the others do it raw via scsi commands and sg.

> For Alan Cox, could you back out Sam's patch for now. It will be back
> soon.

When the new one is sorted. I'm not going to feed it to Linus anyhow. For
the moment there are quite a few people glad of it 

> > > > * Ability to open the device even if there's no disk in the drive.  This
> > > > is needed by the userspace app to probe the device.  The open path sends a


Other devices allow this for O_NDELAY only.


> > 1) A separate minor device that will open whether or not there's a
> > formatted disk in the drive.  I don't like this approach.

Ugly. Thats a lot of extra devices.

> > The O_EXCL trick seems the cleanest way to be able to access the device

Use the same O_NDELAY cdroms do

> > Suppose that two months from now the Clik drive gets new firmware that
> > reports a slightly different model ID, say "IOMEGA Clik! 80 CZ ATAPI".
> > Or, perhaps, it's a new model of the Clik drive, that shares the same
> > shortcomings.
> 
> Yep. Looks extremely possible.  

Nod. I've already suggested a seperate blacklist table of device id/flaws
as SCSI does

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

Re: Call for testers: ne2k-pci and io apic (was: Re: QUESTION: Network hangs with BP6...)

[Manfred Spraul]

It seems that noone uses a Ne2000 compatible pci NIC with a newer
motherboard (every K7 board, Intel 8xx boards, via apollo pro 133), but
I've set up a tiny web site that describes my problem:

colorfullife.com/~manfred/io_apic

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

[PATCH] pcnet32 one liner

[Anton Blanchard]

Hi,

The code below is suspect.

Anton

diff -r -u --new-file --exclude-from=/home/anton/kernel/exclude 
linux/drivers/net/pcnet32.c linux_work/drivers/net/pcnet32.c
--- linux/drivers/net/pcnet32.c Tue Dec 12 14:27:56 2000
+++ linux_work/drivers/net/pcnet32.cTue Jan  9 15:12:20 2001
@@ -809,7 +809,7 @@
val |= 0x10;
 lp->a.write_csr (ioaddr, 124, val);
 
-if (lp->mii & !(lp->options & PORT_ASEL)) {
+if (lp->mii && !(lp->options & PORT_ASEL)) {
val = lp->a.read_bcr (ioaddr, 32) & ~0x38; /* disable Auto Negotiation, set 
10Mpbs, HD */
if (lp->options & PORT_FD)
val |= 0x10;
-
To unsubscribe from this list: send the 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

[Andrzej Krzysztofowicz]

>From kufel!ankry  Sun Jan 14 00:30:25 2001
Return-Path: 
Received: from kufel.UUCP (uucp@localhost)
by green.mif.pg.gda.pl (8.9.3/8.9.3) with UUCP id AAA00889
for green.mif.pg.gda.pl!ankry; Sun, 14 Jan 2001 00:30:25 +0100
Received: (from ankry@localhost)
by kufel.dom (8.9.3/8.9.3) id WAA01107
for green!ankry; Sat, 13 Jan 2001 22:00:40 +0100
From: Andrzej Krzysztofowicz 
Message-Id: <[EMAIL PROTECTED]>
Subject: Re: ide.2.4.1-p3.01112001.patch
To: kufel!green.mif.pg.gda.pl!ankry
Date: Sat, 13 Jan 2001 22:00:40 +0100 (CET)
In-Reply-To: <[EMAIL PROTECTED]> from "Vojtech Pavlik" at Jan 13, 2001 
02:42:36 PM
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[EMAIL PROTECTED] (Vojtech Pavlik)

> > 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.
> 
> This doesn't do anything but change the ID so that Linux drivers are not
> confused anymore. This caused a lot of trouble in 2.2, especially with
> the old VIA IDE driver.
[...]
> Fortunately all these chips use PIIX-compatible extensions to the PCI
> bus, so they are all interchangeable to some degree.
> 
> > I'm curious if all of the other boards in Alans bug reports also
> > fall into the stranger category.
> 
> It's possible. I have a board (VA-503A), which has a masqueraded 598,
> which identifies itself as 597, and a 686a southbridge. This got the
> 2.2 ide driver completely confused, for example. 

Maybe the VIA IDE chipset support option should depend on PCI quirks now ?



-- 
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  tel.  (0-58) 347 14 61
Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej
-
To unsubscribe from this list: send the 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 ate my filesystem on rw-mount, getting closer

[Tobias Ringstrom]

I have now tried the SAMSUNG VG34323A disk with two other controllers at
home (Promise ATA100 an VIA vt82c686a rev 0x22, both on an ASUS A7V
motherboard), and there are no problems to be found with DMA enabled.
Streaming 10 MB/s without glitches.

However, writing to the SAMSUNG VG34323A disk with DMA enabled on either
this machine [1] (at work, using the VIA IDE driver version 3.11)

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 23)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)

or this machine [2] (at work, using the VIA IDE driver version 2.1e)

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 1b)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)

I get exactly the following errors on both machines

hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }

no matter what cable I use.  When I get this, the machine does not recover
most of the time, and I have to reset or power cycle.  This disc works
flawlessly on two other IDE controllers, so I do not think that the disk
is completely broken. It must be either these chipsets or the driver in
combination with this disk.  Note that I _can_ use another UDMA66 disk
_with_ DMA enabled on both machine [1] and [2] above without problems.
Also, 2.2.16-22 seems to work with DMA enabled on machine [1].  I have not
tried 2.2.16-22 with DMA enabled on machine [2].

The problem I reported at first, hence the nasty subject, was a hang and a
nasty fs corruption when RH7 tried to remount the root fs read-write.  I
examined the RH7 init scripts, or more precisely /etc/rc.sysinit, and
discovered, to my great disgust, that the stupid thing disables the dmesg
output on the console very early in the script.  It is thus entirely
possible that I do get the above mentioned errors when the computer seems
to hang, and my fs gets corrupted.  I will fix the script tomorrow to see
if my assumption is correct.

SUMMARY:  I have a disk that with DMA enabled give me CRC errors on two
machines, but not on two other, independent on the cable.  Both troubling
machines do not recover from these errors.  Linux 2.2.16-22 from RedHat
works fine with DMA enabled on machine [1], [2] is unknown.

I hope this makes things a lot clearer.

/Tobias

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

ide-floppy [Fwd: Updated ATAPI FORMAT_UNIT patch.]

[Paul Bristow]

Dear LKML,

Sam & I have been discussing his patch for formatting 1.44MB floppies in
an LS-120 drive, and we decided to move the discussion out in the open. 
One of my concerns is that we don't take the ide-floppy driver in a
different direction to the other removeable media drives.

For Alan Cox, could you back out Sam's patch for now. It will be back
soon.

[Note to Richard Gooch, I haven't forgotten the devfs support]

Sams patches, and the userspace formatting utility are available at
http://www.email-scan.com/idefloppy/floppy-0.03.tar.gz

Comments, suggestions etc would be welcome.

This is the latest mail from Sam...

Sam Varshavchik wrote:
> 
> On Fri, 12 Jan 2001, Paul Bristow wrote:
> 
> > > There are a couple of things that are new:
> > >
> > > * Ability to open the device even if there's no disk in the drive.  This
> > > is needed by the userspace app to probe the device.  The open path sends a
> > > START UNIT packet to the drive, and it looks like most LS-120 drives
> > > report a sense error if there's no disk present.  After thinking about it,
> > > what I ended up doing is checking if the device is opened with O_EXCL flag
> > > set, if so the open path will ignore a START UNIT failure.  Everything is
> > > still initialized correctly, and I've tested it -- this appears to work
> > > quite well.  I would prefer for the open path to always work without any
> > > monkey business, like you can open /dev/fd even if there's no disk in the
> > > drive.  However, I'm not comfortable with that approach -- I'm pretty sure
> > > lots of stuff in ide and hd drivers depend on open failing if there's no
> > > actual disk present.  I see this approach as the best compromise, since it
> > > only affects the userland format utility, and nothing else.
> >
> > Let's put this suggestion out to the kernel mailing list.  There are
> > lots of other removeable media types out there and users will be
> > terribly confused if they behave differently.
> 
> Ok, but the alternatives are:
> 
> 1) A separate minor device that will open whether or not there's a
> formatted disk in the drive.  I don't like this approach.
> 
> 2) Forget the whole thing.  This means that with some drives you will not
> be able to format completely unformatted floppies, only reformat floppies
> that are already formatted.
> 
> The O_EXCL trick seems the cleanest way to be able to access the device
> when you know what you're doing.  The end result is that there needs to be
> a way to access device with or without formattable media.
> 
> > > * An additional flag bit on the packet structure to suppress logging an
> > > error if the packet fails.  The aforementioned dumb Matsushita drive
> > > returns a sense error in response to IDEFLOPPY_CAPABILITIES_PAGE request.
> > > This packet is only sent by my new code, and although this is not defined
> > > as an optional feature of LS-120 drives, Matsushita does not appear to
> > > implement it.  Something like that normally results in the driver
> > > reporting an I/O error to syslog.  There isn't an actual problem, it's a
> > > spurious error, so I'd rather suppress it instead of having people scream
> > > about I/O errors in syslog.  The new packet flag bit will only be used by
> > > the format code.
> >
> > Hmm, isn't this only useful for debugging, and therefore belongs in
> > IDEFLOPPY_DEBUG instead?
> 
> See below.
> 
> > > * Smarter handling of format progress reporting.  Format progress
> > > reporting is defined as optional in INF-8070.  Something has to be done if
> > > the drive doesn't support it.  After sending FORMAT_UNIT to the drive, if
> > > there's nothing else to be done the device will be closed from userland.
> > > The close path sends an unlock packet to the drive.  However, the drive
> > > has just begun formatting the floppy, and it's going to be busy for a
> > > while.  ide.c will wait for the drive to become available, then give up
> > > and do a bus reset.  No good.
> >
> > Agreed.
> 
> To check whether the device supports format progress reporting you need to
> send a MODE_SENSE packet for the IDEFLOPPY_CAPABILITIES_PAGE.  The deal is
> that IDEFLOPPY_CAPABILITIES_PAGE itself appears to be optional (see last
> paragraph on page 43 of INF-8070).  This explains why this packet is
> rejected by the drive.  As I mentioned before, this error condition
> results in the default error handler reporting an I/O error to syslog,
> unless it's suppressed by that portion of my patch.
> 
> One remote possibility is that I screwed up IDEFLOPPY_CAPABILITIES_PAGE,
> and the drive is rejecting it for that reason.  However, I note that the
> definition of that packet already existed in 0.9, and Gabi's ChangeLog
> mentions that he removed the code for that packet.  I suspect the reason
> was the same -- some drives reject it, causing errors logged to syslog.
> 
> > My suggestion would be that we ask Alan Cox to reverse the patch he
> > applied in ac4 for now, and then put some of these 

Linux 2.4.0-ac9

[Alan Cox]

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

2.4.0-ac9
o   Remove duplicated 8139 fixes(Jeff Garzik)
o   Drop out PS/2 mouse changes (me)
o   Fix raid5 bug   (Neil Brown)
o   Fix mmio reservation leak in starfire   (Ion Badulescu)
o   Update gmac driver to new style (Hans Grobler)
o   Fix misuse of dev_kfree_skb on cycx_x25 (Arnaldo Carvalho 
 de Melo)
o   IPDDP cleanup/fixes (Hans Grobler)
o   Remove = 0 inits from epic100   (Arnaldo Carvalho
 de Melo)
o   Fix resource failure leaks on depca (Arnaldo Carvalho
 de Melo)
o   Document ultrix partition option(Steven Cole)
o   Fixed unused config option on cadet radio   (Russell Kroll)
o   Lose static = 0 inits on bmac   (Arnaldo Carvalho
 de Melo)
o   Fix eql driver to use save/restore flags(Arnaldo Carvalho
 de Melo)
o   Document sysctl interfaces  (John Levon)
o   Clean up 6pack and reduce default footprint (Hans Grobler)
o   Fix the handle alignment issues in NFS  (Trond Myklebust)
o   Chkconfig fixes (Niels Jensen)
o   fusion driver updates   (Steve Ralston)
o   Clean up com20020-pci driver leaks  (Hans Grobler)
o   tmpfs/shmfs (Christoph Rohland)


2.4.0-ac8
o   Fix PS/2 mouse ack/echo handling behaviour  (Julian Bradfield)
| Let me know if you see 'odd' ps/2 stuff   (Chris Hanson)
| in 2.4.0ac8 not in ac7
o   Merge Linus 1pre3. Drop out some of my vm
diffs in favour of his
o   PC110 pad move to new driver style  (Hans Grobler)
o   Clean up/fix leaks in ncr885e   (Hans Grobler)
o   Move dsp56k to new style module stuff   (Hans Grobler)
o   check->request_region, resource leak fixes  (Hans Grobler)
for qlogicisp
o   Fix iounmap leak in iphase  (Hans Grobler)
o   Fix iounmap leaks in ymf_pci(Hans Grobler)
o   Fix s390mach.c for non SMP  (Ulrich Weigand)
o   Export queued_sectors   (Jens Axboe)
o   Fix raid5 build after Linus merge   (Andrea Arcangeli)
o   Documentation and chkconfig update  (Niels Jensen)
o   Fix iounmap leaks in oaknet (Arnaldo Carvalho de Melo)
o   Clean up mac89x0(Arnaldo Carvalho de Melo)
o   Fix leaks on error in myri_sbus (Arnaldo Carvalho de Melo)
o   Convert macsonic.c to new style (Arnaldo Carvalho de Melo)
o   RCPCI further fixes (Rasmus Andersen)

2.4.0-ac7
o   Export a KMALLOC_MAXSIZE for drivers to check   (Hans Grobler)
| this is needed to verify things like firmware
| sizes passed by users
o   Fix highmem compile issues  (Ingo Molnar)
o   Fix kmalloc check missing in hades-pci  (Hans Grobler)
o   Fix kmalloc fail crash in sdla_ppp  (Hans Grobler)
o   cfi locking fixes   (Hans Grobler)
o   Fix missing spin_unlock_irq in hd6457x.c(Hans Grobler)
o   Fix lmc_main missing skb_unlock on error case   (Hans Grobler)
o   Handle out of memory on lanstreamer (Hans Grobler)
o   Bring cs46xx.c into working state for non   (Hans Grobler)
module. Fix locking
o   Fix filesystem locking documentation(Al Viro)
o   Fusion driver updates   (Steve Ralston)
o   Correct netfilter url   (Rusty Russell)
o   rcpci45 fix the pci_table name (again)  (Hans Grobler)
o   Fix scsi option ordering bug noted by   (Michael Zieger)
o   Config.h include updates(Niels Jensen)
o   LFS handling cleanup, move some checks to   (Al Viro)
vmtruncate
o   Fix missing s->maxbytes setup for procfs(me)
o   Replace epic100 patches with alternatives   (Jeff Garzik)
o   eepro fixes for older cards (Aristeu Sergio
 Rozanski Filho)
o   Buz error handling fix  (Hans Grobler)
o   DGRS driver cleanups/kmalloc checks (Arnaldo Carvalho 
de 

Re: [PATCH] sparc64 compile fix

[Alan Cox]

> What does this fix?  Things compile just fine without
> it and looking at the code it was intended to be of
> the original type.

2.4.0-ac has quota fixes (there are bad quota races in 2.4.0) and changes
to support 32bit uid. They aren't in the sparc64 diffs yet and until Linus
has the major bugs out they probably arent a major worry.

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

Re: Spinlocking patch for in xprt.c

[David S. Miller]

Trond, did you actually look at how this code works before
you made modifications to my fixes?

xprt_lock serializes sleep/wakeup sequences in the xprt code, so you
cannot remove xprt_lock from the sections where I added holding of
xprt_sock_lock to protect the state of xprt->snd_task.  So for
example, this part of your patch is completely bogus and will create
new corruptions and crashes:

@@ -1143,10 +1143,10 @@
struct rpc_xprt *xprt = task->tk_rqstp->rq_xprt;
 
if (xprt->snd_task && xprt->snd_task == task) {
-   spin_lock(_lock);
+   spin_lock_bh(_sock_lock);
xprt->snd_task = NULL;
rpc_wake_up_next(>sending);
-   spin_unlock(_lock);
+   spin_unlock_bh(_sock_lock);
}
 }

You _must_ hold both xprt_lock and xprt_sock_lock in this
section of code, not just one or just the other.

Linus, please do not apply this patch until these issues
are addressed.

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

Re: [PATCH] sparc64 compile fix

[Petru Paler]

On Sat, Jan 13, 2001 at 02:55:42PM -0800, David S. Miller wrote:
> Petru Paler writes:
>  > -   struct dqblk d;
>  > +   struct dqblk32 d;
> 
> What does this fix?  Things compile just fine without
> it and looking at the code it was intended to be of
> the original type.
> 
> Please explain exactly what submitted patches fix in
> the future, thanks.

Sorry, my fingers slipped and I sent the mail too fast :(

Trying to compile 2.4.0-ac8 resulted in an error about
storage size of variable d not being known (I don't have the
exact error at hand, the network connectivity to that server
is down right now). Changing it to dqblk32 got it to compile.

Am I doing something else wrong ?

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

Re: [PATCH] sparc64 compile fix

[David S. Miller]

Petru Paler writes:
 > -   struct dqblk d;
 > +   struct dqblk32 d;

What does this fix?  Things compile just fine without
it and looking at the code it was intended to be of
the original type.

Please explain exactly what submitted patches fix in
the future, thanks.

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

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

[David Ford]

David Santinoli wrote:

> On Fri, Jan 12, 2001 at 07:53:14PM -0800, 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.
> And it's the same under 2.2.x, too.
>
> > dd says it completes happily even when copying from
> > random.  0+100 records in, 0+100 records out.  It
> It's not a fault of dd, or of the read() system call, either. It's just the way
> /dev/random works - you can't read more bytes than those available in the
> entropy pool. And if you try, you'll just fail with no error.

It won't fail, it will block, then continue reading when more bytes are
available.  The application may time out however.

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

Re: shmem or swapfs? was: [Patch] make shm filesystem part configurable

[David Ford]

Christoph Rohland wrote:

> What do you think about "vmfs"? This probably reflects its nature
> better than swapfs.

That sounds applicable and pretty good.

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

Re: ide.2.4.1-p3.01112001.patch

[junio]

With vt86c686b (AOpen AK73Pro) I am having a strange problem.
When accessing disks old-fashioned way (/dev/hdaN or /dev/hdcN)
I do not see corruption, but writing to a RAID-1 made out of
them produces corrupted results.

Does RAID code access the underlying block device the same way
as single partitions are accessed from the userland?

My test goes like this:

cd /
raidstop /dev/md2

# Baseline: single device case seem to work OK
# with both 2.1e and 3.11
for dev in a7 c7
do
mke2fs /dev/hd$dev
mount /dev/hd$dev /mnt
tar cf - usr | ( cd /mnt && tar xfp - )
sync
umount /mnt
mount -o ro /dev/hd$dev /mnt
tar cf - usr | ( cd /mnt && tar df - )
# no problem reported from `tar df'
umount /mnt
done

# RAID-1 /dev/md2 is built out of /dev/hda7 and /dev/hdc7

# not quite, but exact `force' switch withheld :-)
mkraid /dev/md2
# wait until /proc/mdstat says /dev/md2 is fully reconstructed

mke2fs /dev/md2
mount /dev/md2 /mnt
tar cf - usr | ( cd /mnt && tar xfp - )
sync
umount /mnt
mount -o ro /dev/md2 /mnt
tar cf - usr | ( cd /mnt && tar df - )
# many errors.
umount /mnt
raidstop /dev/md2
sync
mkdir -p /mnt/1 /mnt/2
mount -o ro /dev/hda7 /mnt/1
mount -o ro /dev/hdc7 /mnt/2
tar cf - usr | ( cd /mnt/1 && tar df - )
# many differences.
tar cf - usr | ( cd /mnt/2 && tar df - )
# many differences.

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

Re: Latency: allowing resheduling while holding spin_locks

[Nigel Gamble]

On Sat, 13 Jan 2001, Roger Larsson wrote:
> A rethinking of the rescheduling strategy...

Actually, I think you have more-or-less described how successful
preemptible kernels have already been developed, given that your
"sleeping spin locks" are really just sleeping mutexes (or binary
semaphores).

1.  Short critical regions are protected by spin_lock_irq().  The maximum
value of "short" is therefore bounded by the maximum time we are happy
to disable (local) interrupts - ideally ~100us.

2.  Longer regions are protected by sleeping mutexes.

3.  Algorithms are rearchitected until all of the highly contended locks
are of type 1, and only low contention locks are of type 2.

This approach has the advantage that we don't need to use a no-preempt
count, and test it on exit from every spinlock to see if a preempting
interrupt that has caused a need_resched has occurred, since we won't
see the interrupt until it's safe to do the preemptive resched.

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: 2.4.0 (w/XFS) & reset_xmit_timer

[Andi Kleen]

On Sat, Jan 13, 2001 at 10:11:42PM +0100, Krzysztof Rusocki wrote:
> 
> Hi,
> 
> Since 2.4.0 (from XFS CVS source tree) i get such things from kernel:
> 
> Jan 13 20:55:48 main kernel: reset_xmit_timer sk=c299b9a0 1 when=0x6061, 
>caller=c0218f88 

It's harmless. Just ignore them or comment out the printk if it bothers
you.


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

Re: HP Pavilion 8290 HANGS on boot 2.4/2.4-test9

[Werner Puschitz]

On Sat, 13 Jan 2001, Andre Hedrick wrote:

> On Sat, 13 Jan 2001, Werner wrote:
> 
> > The first and last message I get is: 
> > "Uncompressing Linux... OK, booting the kernel"
> 
> > # lspci
> > 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge(rev 02)
> > 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge(rev 02)
> > 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
> > 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
> 
> It is to early to be caught by a DMA engine fault, but you have one of the
> award winning systems that designed flaw in the hardware.  Only if the
> BIOS with INT13 calls are performing DMA stuff until the OS takes over
> could this be a player.
> 
> If you disable DMA in the BIOS does that help?

No, it didn't make any difference.

Is there a safe way to add debug information like simple string prints in
arch/i386/boot/compressed/head.s and in arch/i386/kernel/head.S
so that I can see at the console where the boot process hangs?

Thanks
Werner


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

-
To unsubscribe from this list: send 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 (w/XFS) & reset_xmit_timer

[Krzysztof Rusocki]

Hi,

Since 2.4.0 (from XFS CVS source tree) i get such things from kernel:

Jan 13 20:55:48 main kernel: reset_xmit_timer sk=c299b9a0 1 when=0x6061, 
caller=c0218f88 
Jan 13 20:58:09 main kernel: reset_xmit_timer sk=c49aa040 1 when=0x594b, 
caller=c0218f88 
Jan 13 21:01:30 main kernel: reset_xmit_timer sk=c0a25040 1 when=0x2f24, 
caller=c0218f88 
Jan 13 21:22:33 main kernel: reset_xmit_timer sk=c6ce99a0 1 when=0x337a, 
caller=c0218f88 
Jan 13 21:32:15 main kernel: reset_xmit_timer sk=c2fb5680 1 when=0x58ef, 
caller=c0218f88 
Jan 13 21:34:49 main kernel: reset_xmit_timer sk=c46bccc0 1 when=0x2fcf, 
caller=c0218f88 
Jan 13 21:34:52 main kernel: reset_xmit_timer sk=c2a949a0 1 when=0x3724, 
caller=c0218f88 
Jan 13 21:36:42 main kernel: reset_xmit_timer sk=c49aa040 1 when=0x8fbf, 
caller=c0218f88 
Jan 13 21:41:42 main kernel: reset_xmit_timer sk=c49aa040 1 when=0x4c4e, 
caller=c0218f88 
Jan 13 21:45:51 main kernel: reset_xmit_timer sk=c398f360 1 when=0x552b, 
caller=c0218f88 
Jan 13 21:50:38 main kernel: reset_xmit_timer sk=c7c979a0 1 when=0x3caf, 
caller=c0218f88 
Jan 13 21:50:38 main kernel: reset_xmit_timer sk=c7c979a0 1 when=0x38d3, 
caller=c0218f88 
Jan 13 21:50:38 main kernel: reset_xmit_timer sk=c7c979a0 1 when=0x3432, 
caller=c0218f88 

On 2.4.0-test13-pre3 (patched with XFS patch from SGI) there was _NO_ such
things... I ain't kernel developer, so i have no idea of possible cause...

My 2.4.0-t13-pre3 and 2.4.0 kernel configs does _NOT_ practically differ.

I use DM9102 ethernet driver together with QoS (CBQ & TBF queues and U32
classifier).

I didn't find this problem related stuff in LKML archives, so i decided to
write this down here...

- Krzysztof

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

Re: shmem or swapfs? was: [Patch] make shm filesystem part configurable

[Dan Kegel]

Albert D. Cahalan ([EMAIL PROTECTED]) wrote:
> Christoph Rohland writes: 
> > I am quite open about naming, but "shm" is not appropriate any more 
> > since the fs does a lot more than shared memory. Solaris calles this 
> > "tmpfs" but I did not want to 'steal' their name and I also do not 
> > think that it's a very good name. 
> 
> Admins already know what "tmpfs" means, so you should just call 
> your filesystem that. I know it isn't a pretty name, but in the 
> interest of reducing confusion, you should use the existing name. 
> 
> Don't think of it as just "for /tmp". It is for temporary storage. 
> The name is a reminder that you shouldn't store archives in tmpfs. 
> 
> Again for compatibility, Sun's size option would be useful. 

I agree with Albert; if it does the same thing as Sun's tmpfs,
let's call it tmpfs, and use the same options.

- Dan
-
To unsubscribe from this list: send the 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 Santinoli]

On Fri, Jan 12, 2001 at 07:53:14PM -0800, 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.
And it's the same under 2.2.x, too.

> dd says it completes happily even when copying from
> random.  0+100 records in, 0+100 records out.  It
It's not a fault of dd, or of the read() system call, either. It's just the way
/dev/random works - you can't read more bytes than those available in the
entropy pool. And if you try, you'll just fail with no error.

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

Re: PPC 2.4 ?

[Cort Dougan]

} When will the powerpc tree be merged ?  Neither the
} official 2.4 nor the -ac8 work. They don't even compile.

Grab a tree from www.fsmlabs.com/linuxppcbk.html.  Those always compile and
are up-to-date.

I send patches, but they don't always make it into the main tree.  In the
mean time, you have a consistent source of kernels with the above web site.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.19pre6aa1 weird error

[Andrea Arcangeli]

On Sat, Jan 13, 2001 at 08:10:33PM +0100, Sasi Peter wrote:
> Jan 13 01:58:17 iq kernel: probable hardware bug: clock timer
> configuration lost - probably a VIA686a.
> Jan 13 01:58:17 iq kernel: probable hardware bug: restoring chip
> configuration.
> 
> I get these, do not know why. MB is abit BH6, IDE controllers are the
> onboard and a WinFast CMD648.
> 
> Have never seen such before (2.0.x and 2.2.x up till now).
> 
> Bug rather in SW maybe?

That's a new check in the 2.2.19pre kernels (not part of the aa patchkit).

It means your timer chip didn't resetted itself to the timeout value (LATCH)
after triggering the irq and in turn it means you are losing system time (you
lose more time the the higher is the irq latency). I don't know the details of
the hardware bug though, maybe somebody else can give more details on it.

It doesn't look like a sw problem (previous kernel would malfunction silenty if
that would happen without such a new sanity check).

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

Re: HP Pavilion 8290 HANGS on boot 2.4/2.4-test9

[Andre Hedrick]

On Sat, 13 Jan 2001, Werner wrote:

> The first and last message I get is: 
> "Uncompressing Linux... OK, booting the kernel"

> # lspci
> 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge(rev 02)
> 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge(rev 02)
> 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
> 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)

It is to early to be caught by a DMA engine fault, but you have one of the
award winning systems that designed flaw in the hardware.  Only if the
BIOS with INT13 calls are performing DMA stuff until the OS takes over
could this be a player.

If you disable DMA in the BIOS does that help?

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: shmem or swapfs? was: [Patch] make shm filesystem part configurable

[Albert D. Cahalan]

Christoph Rohland writes:

> I am quite open about naming, but "shm" is not appropriate any more
> since the fs does a lot more than shared memory. Solaris calles this
> "tmpfs" but I did not want to 'steal' their name and I also do not
> think that it's a very good name.

Admins already know what "tmpfs" means, so you should just call
your filesystem that. I know it isn't a pretty name, but in the
interest of reducing confusion, you should use the existing name.

Don't think of it as just "for /tmp". It is for temporary storage.
The name is a reminder that you shouldn't store archives in tmpfs.

Again for compatibility, Sun's size option would be useful.

-o size=111222333  Size in bytes, rounded up by page size.
-o size=111222kSize in kilobytes (base-2 or ISO standard?)
-o size=111m   Size in megabytes (base-2 or ISO standard?)

I'd prefer k for ISO standard and K for base-2.
Of course m isn't millibytes, but that isn't horrible.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: HP Pavilion 8290 HANGS on boot 2.4/2.4-test9

[Werner Puschitz]

I guess I confused some people. I didn't copy the kernel from PIII to
PII etc.. I compiled the kernel on all my PCs separately.
I just have problems with one PC, the HP Pavilion.


On Sat, 13 Jan 2001, Werner wrote:

> 
> HP Pavilion 8290, PII 400MHz, 256MB hangs on boot 2.4 and 2.4-test9 on RH7.0.
> I tried to compile 2.4-test9 on RH 7.0 with gcc versions 2.96-54, 2.96-69,
> and with kgcc 1.1.2-40 (egcs-2.91.66) without success.
> 
> The first and last message I get is: 
> "Uncompressing Linux... OK, booting the kernel"
> 
> I never get to the start_kernel() function in main.c
> I had no problems to get 2.4 (testx) running on IBM 300PL (PIII 500MHz, 192MB).
> After running 'make mrproper' and 'make xconfig' I changed only SMP to No.
> 
> Can you please tell me how I can print debug information to the console in
> arch/i386/boot/compressed/head.s and in arch/i386/kernel/head.S
> _without_ impacting the rest of the assembly code?
> 
> # lspci
> 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge(rev 02)
> 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge(rev 02)
> 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
> 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
> 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
> 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
> 00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI]
> 00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74)
> 00:0c.0 Ethernet controller: National Semiconductor Corporation: Unknown device 0020
> 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 
>5c)
> 
> Let me know what I can do.
> 
> Thanks
> Werner
> 
> 
> 
> 
> -
> To unsubscribe from this list: send 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: ide.2.4.1-p3.01112001.patch

[Andre Hedrick]

COOL!

This will kill the VIA problem and allow us to clobber the timeout.
I know where and what to do but it is the how with the current mess of the
driver held togather with duct tape and paper clips and a little bit of
spit here and there.

I can not wait for 2.5 to get started to begin with "rm -rf ./drivers/ide"
and start with "mkdir ./drivers/ata" ;-))  Okay not quite that radical but
very close

On Sat, 13 Jan 2001, Alan Cox wrote:

> > if (IDE_PCI_DEVID_EQ(d->devid, DEVID_SIS5513) ||
> > IDE_PCI_DEVID_EQ(d->devid, DEVID_AEC6260) ||
> > IDE_PCI_DEVID_EQ(d->devid, DEVID_PIIX4NX) ||
> > -   IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X))
> > +   IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X)  ||
> > +   IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
> > +   IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
> > autodma = 0;
> > if (autodma)
> > hwif->autodma = 1;
> 
> How about
> 
>   && !force_dma)
> 
> 
> __setup("force_dma") ...
> 
> So those who want to play fast can
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

Andre Hedrick
Linux ATA Development

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

HP Pavilion 8290 HANGS on boot 2.4/2.4-test9

[Werner]

HP Pavilion 8290, PII 400MHz, 256MB hangs on boot 2.4 and 2.4-test9 on RH7.0.
I tried to compile 2.4-test9 on RH 7.0 with gcc versions 2.96-54, 2.96-69,
and with kgcc 1.1.2-40 (egcs-2.91.66) without success.

The first and last message I get is: 
"Uncompressing Linux... OK, booting the kernel"

I never get to the start_kernel() function in main.c
I had no problems to get 2.4 (testx) running on IBM 300PL (PIII 500MHz, 192MB).
After running 'make mrproper' and 'make xconfig' I changed only SMP to No.

Can you please tell me how I can print debug information to the console in
arch/i386/boot/compressed/head.s and in arch/i386/kernel/head.S
_without_ impacting the rest of the assembly code?

# lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge(rev 02)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge(rev 02)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:0a.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI]
00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74)
00:0c.0 Ethernet controller: National Semiconductor Corporation: Unknown device 0020
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c)

Let me know what I can do.

Thanks
Werner




-
To unsubscribe from this list: send the 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]

>   if (IDE_PCI_DEVID_EQ(d->devid, DEVID_SIS5513) ||
>   IDE_PCI_DEVID_EQ(d->devid, DEVID_AEC6260) ||
>   IDE_PCI_DEVID_EQ(d->devid, DEVID_PIIX4NX) ||
> - IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X))
> + IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X)  ||
> + IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
> + IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
>   autodma = 0;
>   if (autodma)
>   hwif->autodma = 1;

How about

&& !force_dma)


__setup("force_dma") ...

So those who want to play fast can
-
To unsubscribe from this list: send the 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

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> If I do the dd line in the title under 2.4.0 I get an
> out.txt file of 591 bytes.
/dev/random will only give you as much bytes as are available. and even then
you should not do it cause you drain the random pool. Use /dev/urandom
instead.

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

2.2.19pre6aa1 weird error

[Sasi Peter]

Jan 13 01:58:17 iq kernel: probable hardware bug: clock timer
configuration lost - probably a VIA686a.
Jan 13 01:58:17 iq kernel: probable hardware bug: restoring chip
configuration.

I get these, do not know why. MB is abit BH6, IDE controllers are the
onboard and a WinFast CMD648.

Have never seen such before (2.0.x and 2.2.x up till now).

Bug rather in SW maybe?

SaPE

-
To unsubscribe from this list: send the 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?

[Russell King]

David Woodhouse writes:
> We don't need to overdesign it. get_module_symbol() basically provided
> this for us. The only thing really wrong with it was the lack of use
> count handling, which I fixed a while ago.

And the fact that it doesn't work if you turn module support off, which
you'd want to do on an embedded kernel.  Unfortunately, this is one of
the times when you do want the MTD stuff.  You either have to put up
with no MTD support, write your own, or put up with the extra space of
module symbols.

Therefore, get_module_symbol() as it stood was the wrong interface to
use, and I completely agree with Keiths decision to remove it.  However,
I'm not sure that the inter_* stuff that replaced it is much better for
the reasons David has highlighted previously wrt link ordering.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Russell King]

David Woodhouse writes:
> Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA
> drives, while we're at it? I don't care if it's done by blacklisting the
> DTLA drives, as was done by the patch I resent numerous times, or if it's
> done the other way round by putting known-compatible drives (include
> "FUJITSU MPE3136AT") into a whitelist. But it needs doing.

I've been wondering recently why there isn't an option to tell the kernel
"even if you've been configured to use dma by default, please don't on this
IDE interface".  There is an option for tuning the interface up, but
nothing to tune down.

It strikes me that this might be a good thing to have.  Comments?
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0: Raw devices ?

[Douglas Gilbert]

Meino Cramer wrote:
> 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.

There doesn't seem to be any config option for raw
devices in lk 2.4.0 , they are just there. However
the raw (8) utility expects them in a different place
from where Documentation/devices.txt currently says 
they are. You may have to set up these char devices:

$ ls -l /dev/rawctl 
crw-r--r--1 root root 162,   0 Jan 13 05:12 /dev/rawctl

$ ls -l /dev/raw/*  
crw-r--r--1 root root 162,   1 Jan 13 05:12 /dev/raw/raw1
crw-r--r--1 root root 162,   2 Jan 13 05:12 /dev/raw/raw2
crw-r--r--1 root root 162,   3 Jan 13 05:12 /dev/raw/raw3
crw-r--r--1 root root 162,   4 Jan 13 05:12 /dev/raw/raw4
etc.

Recent versions of dd meet the alignment requirements
of raw devices as does lmdd (from the lmbench package).
I have done some timings of disk to disk copies using
raw devices compared to other devices. See:
http://www.torque.net/sg/fst_copy.html

> And where can I find the "raw" utility...

In both RH 6.2 and 7.0 the raw (8) utility is in the 
util-linux package (RH have applied a "raw" patch for 
those two lk 2.2 versions). Read man (8) raw to find 
out how to bind a raw device to an existing block device.
Example:
$ raw /dev/raw/raw1 /dev/sda3

Doug Gilbert

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

Re: ide.2.4.1-p3.01112001.patch

[David Woodhouse]

On 12 Jan 2001, Linus Torvalds wrote:

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

Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA
drives, while we're at it? I don't care if it's done by blacklisting the
DTLA drives, as was done by the patch I resent numerous times, or if it's
done the other way round by putting known-compatible drives (include
"FUJITSU MPE3136AT") into a whitelist. But it needs doing.

-- 
dwmw2


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

Re: ide.2.4.1-p3.01112001.patch

[Linus Torvalds]

On Sat, 13 Jan 2001, David Woodhouse wrote:
> 
> Please can we also stop HPT366 from attempting UDMA66 on the IBM DTLA
> drives, while we're at it? I don't care if it's done by blacklisting the
> DTLA drives, as was done by the patch I resent numerous times, or if it's
> done the other way round by putting known-compatible drives (include
> "FUJITSU MPE3136AT") into a whitelist. But it needs doing.

Somebody who can test it needs to send me a patch - I'm NOT going to apply
patches that haven't been tested and that I cannot test myself.

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/

ipppd == pppd? (was: Re: New features in Linux 2.4 - Wonderful Wor...)

[Kai Henningsen]

[EMAIL PROTECTED] (Joe Pranevich)  wrote on 06.01.01 in 
<[EMAIL PROTECTED]>:

>much of the code, including a long awaited combination of the PPP
>layers from the ISDN layer and the serial device PPP layer, such as

I've heard about that before, but I can find no hint about that in  
Documentation/. The separate ipppd is still mentioned there.

Plus, looking at the ISDN PPP sources also gives no hint.

What's up?

MfG Kai
-
To unsubscribe from this list: send the 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

[Vojtech Pavlik]

Hi!

This is not the case I'm looking for. You have a 686b, a chip that is
not supported in 2.4.0 yet. You can try the via 3.11 driver I posted a
while ago, it adds support for this chip, including UDMA100.

Thanks anyway,
Vojtech

On Sat, Jan 13, 2001 at 09:09:05AM -0800, Bryan O'Sullivan wrote:
> v> I can make one for you, but first I'd like to find out what exactly are
> v> the problem cases.
> 
> I have a VT82C686 motherboard.  It has one UDMA-100 slot and two
> regular IDE slots.  I have an IBM DTTA-371440 (about 18 months old) as
> hda (only fat32 filesystems), and an IBM DTLA-307030 as hde
> (i.e. plugged into the UDMA-100 slot).  I've never seen any problems
> with DMA on the newer drive, but if I turn on DMA and do anything with
> the older drive, I get stuff like this:
> 
>   /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 { DriveReady 
>SeekComplete Error } 
>   hda: dma_intr: error=0x84 { DriveStatusError BadCRC } 
>   hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } 
>   hda: dma_intr: error=0x84 { DriveStatusError BadCRC } 
>   hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } 
>   hda: dma_intr: error=0x84 { DriveStatusError BadCRC } 
>   hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } 
>   hda: dma_intr: error=0x84 { DriveStatusError BadCRC } 
> 
> The driver attempts to reset ide0 a few times, gets more of the above,
> then gives up with an I/O error.
> 
> I've been seeing these problems as long as I've been tracking the 2.3
> series, up to and including 2.4.0.  I can't boot a 2.2 kernel on this
> machine to compare, as it doesn't recognise hde (which is where Linux
> lives).
> 
> Here's the output of lspci under 2.4.0, in case it's useful:
> 
>   00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
>   00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
>   00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
>   00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
>   00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
>   00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
>   00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
>   00:09.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
>   00:09.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
>   00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
>   00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08)
>   00:0b.1 Input device controller: Creative Labs SB Live! (rev 08)
>   00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 
>0d30 (rev 02)
>   01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0150 (rev a3)
> 
> If you need any more information, I can dig it out.
> 
>   http://www.tux.org/lkml/

2.4.0 + iproute2

[Igmar Palsenberg]

Hi,

kernel : 2.4.0 vanilla
iproute2 version : ss001007

After building I've got a few problems :

./ip rule list
RTNETLINK answers: Invalid argument
Dump terminated

Version should be OK according to the Changes file.

config is attached


Regards,


Igmar

-- 

--
Igmar Palsenberg
JDI Media Solutions

Jansplaats 11
6811 GB Arnhem
The Netherlands

mailto: [EMAIL PROTECTED]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar


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

#
# Processor type and features
#
CONFIG_M586TSC=y
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_USE_STRING_486=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_TSC=y
CONFIG_NOHIGHMEM=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y

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

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETFILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_SYN_COOKIES=y

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_LOG=y

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDE_MODES=y

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_NET_PCI=y
CONFIG_8139TOO=y

#
# Ethernet (1000 Mbit)
#
CONFIG_PPP=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_DEFLATE=y

#
# ISDN subsystem
#
CONFIG_ISDN=y

#
# Passive ISDN cards
#
CONFIG_ISDN_DRV_HISAX=y
CONFIG_HISAX_EURO=y
CONFIG_HISAX_16_3=y

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# Mice
#
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y

#
# File systems
#
CONFIG_QUOTA=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y

#
# Partition Types
#
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_ISO8859_1=y

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y

Re: 2.4 ate my filesystem on rw-mount

[Tobias Ringstrom]

On Sat, 13 Jan 2001, Vojtech Pavlik wrote:

> On Sat, Jan 13, 2001 at 09:12:27AM +0100, Tobias Ringstrom wrote:
> > > 2) What's in /proc/ide/via?
> >
> > It's not there since I disabled the VIA driver.
>
> Ok. Could you send me this file when you boot with fs r-o?

Ok, but this is with the wrong disc.  Withe the bad disc, drive0 looks
exacly like drive2, i.e. normal UDMA(33).  Sorry about that.

--VIA BusMastering IDE Configuration
Driver Version: 2.1e
South Bridge:   VIA vt82c686a rev 0x1b
Command register:   0x7
Latency timer:  32
PCI clock:  33MHz
Master Read  Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
FIFO Output Data 1/2 Clock Advance: off
BM IDE Status Register Read Retry:  on
Max DRDY Pulse Width:   No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush:   on  on
End Sect. FIFO flush:  on  on
Prefetch Buffer:   on  on
Post Write Buffer: on  on
FIFO size:  8   8
Threshold Prim.:  1/2 1/2
Bytes Per Sector: 512 512
Both channels togth:  yes yes
---drive0drive1drive2drive3-
BMDMA enabled:yes   yes   yes   yes
Transfer Mode:   UDMA   DMA/PIO  UDMA   DMA/PIO
Address Setup:   30ns 120ns  30ns 120ns
Active Pulse:90ns 330ns  90ns 330ns
Recovery Time:   30ns 270ns  30ns 270ns
Cycle Time:  30ns 600ns  60ns 600ns
Transfer Rate:   66.0MB/s   3.3MB/s  33.0MB/s   3.3MB/s

> > > 4) If you mount your filesystem read-only, does it read garbage?
> >
> > Now here's a strange part, or possibly a crusial clue.  When I booted a
> > 2.4.0 kernel (from floppy using the excellent syslinux) with "ro
> > init=/bin/sh", I could access the filesystem just fine.  I could even
> > remount the root filesystem rw, and there were no problems.  But I did not
> > write anything to the disk, since I was convinced that the problem was
> > gone (this was the second try).  After this I rebooted with
> > ctrl-alt-delete, forgetting how bad an idea that is with init=/bin/sh,
> > booted up the RH7 2.2.16 kernel, and fsck was run with no errors.
>
> So far no problem. Rebooting with c-a-d with fs r-o is OK.
>
> > Now I
> > though all was well, rebooted from floppy again, but without the init=
> > part, and poof, it hang.
>
> Where? It could be a different reason than IDE setup ...

Don't think so.  It happens on the "Remounting root read-write".

> > More interesting may be that I had to turn the computer off and on again
> > to get BIOS to find the hard drive. Repeated long reset button presses
> > did not help.  It is possible that it hung during BIOS hd detection - I
> > wish I could remember.
>
> I fear this isn't much of a clue, sorry.

The clue is that the VIA driver messed up either the chipset or the drive
quite a lot, but maybe that is already obvious.

> > I suspect that I could have hung the drive with init=/bin/sh if I would
> > have done some reading and writing to the device, besides ls.
>
> Please try it. Best mke2fs your swap partition and try reading & writing
> to that. You can mkswap it back after you finish.

After more testing, I think I have isolated the problem to this disk, or
at least this disk with this controller.  With another (UDMA66) disk,
there are no problems.  Details at the end.

> > I think I can spend some more time today trying it out some more.
>
> Please do. 'lspci -vvxxx' data for the case without a driver, with 2.4.0
> driver and with 3.11 driver would help me find the problem.

Ok, I'll do that later.

> Make sure you *don't* have any hdparm -d1 or hdparm -X66 or similar
> stuff in your init scripts.

I'm sure I don't.  This happens with a clean fresh RH7 installation.

> > I will
> > also try your 3.11 driver, which seems to be an enormous cleanup.
>
> the 2.1e driver is an enormous cleanup of the original driver from the
> 2.2 kernels. the 3.11 is an enormous cleanup of 2.1e, yes.

I have not had a chance to try the 3.11 driver yet.

Now for the new details.  When writing to the disk with DMA enabled, I get
the following errors, in two different machines.  Both are VIA IDE
machines.  I is NOT a cable error.  I have tries with several cables.
Possibly a connector or soldering problem.  I'll try the disk in more
machines an get back with more info.  I have to run now.

hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }

/Tobias


-
To unsubscribe from this list: send the 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-lvm] Re: *** ANNOUNCEMENT *** LVM 0.9.1 beta1 available at www.sistina.com

[Christoph Hellwig]

On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> 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.

The longs are the biggest problem AFAICS.
long is 64bit on sparc64 and 32bit on sparc32...

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send 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:reiserfs 3.6.25 + LVM

[hugang]

--- reiserfs_fs.h   Sat Jan 13 22:46:42 2001
+++ reiserfs_fs.h.old   Sat Jan 13 22:17:45 2001
@@ -1420,7 +1420,7 @@
 #define op_is_left_mergeable(key,bsize)  item_ops[le_key_k_type 
(le_key_version (key), key)]->is_left_mergeable (key, bsize)
 #define op_print_item(ih,item)   item_ops[le_ih_k_type 
(ih)]->print_item (ih, item)
 #define op_check_item(ih,item)   item_ops[le_ih_k_type 
(ih)]->check_item (ih, item)
-#define op_create_vi(vn,vi,is_affected,insert_size)  
item_ops[le_ih_k_type(vi->vi_ih)]->create_vi > 0 ? item_ops[le_ih_k_type 
(vi->vi_ih)]->create_vi(vn,vi,is_affected,insert_size) : 0
+#define op_create_vi(vn,vi,is_affected,insert_size)  item_ops[le_ih_k_type 
+(vi->vi_ih)]->create_vi (vn,vi,is_affected,insert_size)
 #define op_check_left(vi,free,start_skip,end_skip)   
item_ops[(vi)->vi_index]->check_left (vi, free, start_skip, end_skip)
 #define op_check_right(vi,free)  
item_ops[(vi)->vi_index]->check_right (vi, free)
 #define op_part_size(vi,from,to) 
item_ops[(vi)->vi_index]->part_size (vi, from, to)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre2/3 and Pentium-III not stable

[Pierre Rousselet]

Andrzej Krzysztofowicz wrote:
> 
> "Pierre Rousselet wrote:"
> > Pentium-III 256Mo
> > For testing, I try to compile glibc. The start is good.
> > When the process PID reaches a value around 22000
> > (variable), all goes wrong. Make gives error messages
> > such as :
> >
> > make[2]: *** No rule to make target
> > `../sysdeps/wordsize-32/bits/wordsi:e.h'
> > make[2]: *** No rule to make target
> > `/usr/lib/g#c-lib/i686-pc-linux-gnu/2.95.2/include/stddef.h'
> 
> As "z" / ":" and "c" / "#" differ only on a single bit
> it looks like a bad memory problem.

I got the attached kernlog in an other compiling test
writing Kernel BUG at page_alloc.c and swap.c. The PID of
as is then 26349.


 Pierre Rousselet <[EMAIL PROTECTED]>

 bug.gz

sparc32 hangs on boot 2.4.0

[Patrick Mauritz]

on boot the following happens:
--
SILO boot: linux2.4
Uncompressing image...
PROMLIB: obio_ranges 5
bootmem_init: Scan sp_banks,  init_bootmem(spfn[211],bpfn[211],mlpfn[c000])
free_bootmem: base[0] size[100]
free_bootmem: base[200] size[10]
free_bootmem: base[400] size[10]
free_bootmem: base[600] size[10]
free_bootmem: base[800] size[10]
free_bootmem: base[a00] size[10]
reserve_bootmem: base[0] size[211000]
reserve_bootmem: base[211000] size[1800]

Level 15 Interrupt
-
that's it, I'm on OpenFirmware prompt again

The machine is a SS20 with 2 SuperSPARC-II processors and 256MB RAM

Patrick Mauritz 
-- 
-
To unsubscribe from this list: send 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] enable K7 nmi watchdog

[Mikael Pettersson]

This patch (against 2.4.0-ac8) _may_ enable the NMI watchdog on
some K7 systems. It won't help if you have an old K7 without a
local APIC, or if your BIOS disables it.

This is a quick hack to test the mechanism -- I'll submit a
cleaner patch later if this one works.

If you try this, please cc: me the result (positive or negative)
and a copy of the kernel's boot log.

/Mikael

--- linux-2.4.0-ac8/arch/i386/kernel/nmi.c.~1~  Sat Jan 13 14:57:09 2001
+++ linux-2.4.0-ac8/arch/i386/kernel/nmi.c  Sat Jan 13 16:00:27 2001
@@ -64,6 +64,10 @@
(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) &&
(boot_cpu_data.x86 == 6))
nmi_watchdog = nmi;
+   if ((nmi == NMI_LOCAL_APIC) &&
+   (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+   (boot_cpu_data.x86 == 6))
+   nmi_watchdog = nmi;
/*
 * We can enable the IO-APIC watchdog
 * unconditionally.
@@ -80,10 +84,34 @@
  * Original code written by Keith Owens.
  */
 
+#define MSR_K7_EVNTSEL0 0xC001000
+#define MSR_K7_PERFCTR0 0xC001004
+
 void setup_apic_nmi_watchdog (void)
 {
int value;
 
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
+   boot_cpu_data.x86 == 6) {
+   unsigned evntsel = (1<<20)|(3<<16); /* INT, OS, USR */
+#if 1  /* listed in old docs */
+   evntsel |= 0x76;/* CYCLES_PROCESSOR_IS_RUNNING */
+#else  /* try this if the above doesn't work */
+   evntsel |= 0xC0;/* RETIRED_INSTRUCTIONS */
+#endif
+   wrmsr(MSR_K7_EVNTSEL0, 0, 0);
+   wrmsr(MSR_K7_PERFCTR0, 0, 0);
+   wrmsr(MSR_K7_EVNTSEL0, evntsel, 0);
+   printk("setting K7_PERFCTR0 to %08lx\n", -(cpu_khz/HZ*1000));
+   wrmsr(MSR_K7_PERFCTR0, -(cpu_khz/HZ*1000), 0);
+   printk("setting K7 LVTPC to DM_NMI\n");
+   apic_write(APIC_LVTPC, APIC_DM_NMI);
+   evntsel |= (1<<22); /* ENable */
+   printk("setting K7_EVNTSEL0 to %08x\n", evntsel);
+   wrmsr(MSR_K7_EVNTSEL0, evntsel, 0);
+   return;
+   }
+
/* clear performance counters 0, 1 */
 
wrmsr(MSR_IA32_EVNTSEL0, 0, 0);
@@ -162,7 +190,14 @@
last_irq_sums[cpu] = sum;
alert_counter[cpu] = 0;
}
-   if (cpu_has_apic && (nmi_watchdog == NMI_LOCAL_APIC))
-   wrmsr(MSR_IA32_PERFCTR1, -(cpu_khz/HZ*1000), 0);
+   if (cpu_has_apic && (nmi_watchdog == NMI_LOCAL_APIC)) {
+   /* XXX: nmi_watchdog should carry this info */
+   unsigned msr;
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+   msr = MSR_K7_PERFCTR0;
+   else
+   msr = MSR_IA32_PERFCTR1;
+   wrmsr(msr, -(cpu_khz/HZ*1000), 0);
+   }
 }
 
--- linux-2.4.0-ac8/arch/i386/kernel/setup.c.~1~Sat Jan 13 14:57:09 2001
+++ linux-2.4.0-ac8/arch/i386/kernel/setup.cSat Jan 13 14:57:48 2001
@@ -1926,14 +1926,6 @@
c->x86 = 4;
}
 
-   /*
-* Athlons have an APIC, but the APIC-programming
-* MSRs are in different places. If you want NMI-watchdog
-* on Athlons, please fix setup_apic_nmi_watchdog().
-*/
-   if (c->x86_vendor == X86_VENDOR_AMD)
-   clear_bit(X86_FEATURE_APIC, >x86_capability);
-
/* AMD-defined flags: level 0x8001 */
xlvl = cpuid_eax(0x8000);
if ( (xlvl & 0x) == 0x8000 ) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

VIA IDE corruption - anyone experiencing it with 2.4.0?

[Vojtech Pavlik]

On Sat, Jan 13, 2001 at 06:03:11AM -0600, Thomas Molina wrote:

> Are you looking for specific chipsets or configurations?  Following is
> my VP3/MVP3 chipset lspci output if you are gathering a group of
> testers.  I've enabled autoDMA at various points in the testing cycle
> (not consistently) but haven't noticed any fs corruption.

Ok. So what I'm exactly looking for:

Cases of harddrive corruption (that is, trashing your fs,
reading/writing bad data) on VIA chipsets. UDMA-caused CRC errors don't
fall into this category, they're harmless to the data.

Preferably with the driver from the 2.4.0 kernel. If possible, try also
the VIA 3.11 driver posted to the list earlier. If you don't have it, I
can e-mail it to you.

Don't use any hdparm command in your init scripts (this is important)
with the VIA driver and 2.4.0, setting the speed or dma usage with
hdparm would interfere with the driver autotuning.

If you fear to test, you can mount your fs readonly (no corruption can
happen) and use your swap partition for read-write test. You can even
mke2fs the swap for a while.

Anyone who experienced this kind of problems with 2.4 and the VIA
driver, please speak up, so I can fix it.

I'm not currently looking for success reports, I've already got success
reports for every type VIA IDE chip out there. 

I'll need the motherboard type and revision, lspci -vvxxx, dmesg,
hdparm -i and /proc/ide/via listings ...

Thanks.

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

[BUG] [240-ac8] loop device hangs and sync does not return

[Tilmann Bitterberg]

I know there is something about loop device hangs in the 2.4
TODO list and I don't know if that is supposed to be fixed.

If this BUG is known, please appreciate

[1.] One line summary of the problem:
[240-ac8] loop device hangs and sync does not return any more

[2.] Full description of the problem/report:
When I copy data to a ext2 filesystem mounted via loop0 the 'cp'
command stops after a while. The system is not dead but very
unusuable and I can't reboot because 'sync' is not working.
I am in single user mode on a 2way Pentium 166 w/o mmx SMP
system. 2.2.X is stable. The loop dev is compiled as a module.

I tried with 'noapic', 'maxcpus=1' and combination of both. I
have not tried a UP kernel. Same happens with 2.4.0-prerelease.
Copying (a lot of) data between "normal" mounted filesystems
works fine.

[3.] Keywords (i.e., modules, networking, kernel):
loop device, sync, module, SMP. 

[4.] Kernel version (from /proc/version):
Linux version 2.4.0-ac8 ([EMAIL PROTECTED])
(gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) 
#7 SMP Sat Jan 13 14:05:38 CET 2001

[5.] Output of Oops.. message (if applicable) with symbolic information 
not available
 
[6.] A small shell script or example program which triggers the
 problem (if possible)
  dd if=/dev/zero of=file bs=1M count=500
  mke2fs file
  mount -o loop=/dev/loop0 file /mnt/loop
  cd $_
  cp -av /bin/ /etc/ /sbin/ .
  mkdir usr && cp -av /usr/bin usr/

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Kernel modules 2.4.1
Gnu C  egcs-2.91.66
Gnu Make   3.77
Binutils   2.10.0.18
Linux C Library2.1.2
Dynamic linker ldd (GNU libc) 2.1.2
Procps 2.0.6
Mount  2.10r
Net-tools  1.53
Console-tools  1999.03.02
Sh-utils   2.0
Modules Loaded loop 3c59x sb sb_lib uart401 sound soundcore

[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 5
model   : 2
model name  : Pentium 75 - 200
stepping: 12
cpu MHz : 167.048
fdiv_bug: no
hlt_bug : no
f00f_bug: yes
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 apic
bogomips: 333.41

processor   : 1
... (same)

[7.3.] Module information (from /proc/modules):
loop7808   0 (unused)
3c59x  24672   1 (autoclean)
sb  7712   0 (autoclean)
sb_lib 36192   0 (autoclean) [sb]
uart401 6640   0 (autoclean) [sb_lib]
sound  63024   0 (autoclean) [sb_lib uart401]
soundcore   4208   5 (autoclean) [sb_lib sound]

[7.4.] Loaded driver and hardware information
I am on an SCSI only system with aic7xxx and 2 4Gig IBM UW disk.

-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0220-022f : soundblaster
02f8-02ff : serial(auto)
0330-0333 : MPU-401 UART
03c0-03df : vga+
  03c0-03df : matrox
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
6000-60ff : Adaptec AIC-7880U
  6000-60fe : aic7xxx
6400-647f : 3Com Corporation 3c905B 100BaseTX [Cyclone]
  6400-647f : eth0
f000-f00f : Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]

[X.] Other notes, patches, fixes, workarounds:
For what it's worth:
Data is copied from sda1 to sdb1 where the loop device is
located

I have a lot of NMI interrupts, nearly twice as much as from the
timer. Same is true for LOC.
Sometimes I even have some ERR but usually not more than 10.

When using sysrq to do an emergency sync and a killall I get:
(from memory)
NMI Watchdog detected LOOKUP on CPU0
and the calltrace (resolved)
do_exitdo_signaldo_pollfd   signal_return

Thanks in advance
Tilmann

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

Call for testers: ne2k-pci and io apic (was: Re: QUESTION: Network hangs with BP6...)

[Manfred Spraul]

Russell King wrote:
> 
> Doesn't the NCR53C9x SCSI drivers use disable_irq() a lot?  Do they have
> any problems?
>

It seems that a certain timing is necessary: one flood ping or a single
ncp usually doesn't trigger any problems, but 2 concurrent flood pings
hang the network after 5-10 seconds. It's not multi processor specific,
both I and Frank can trigger it when we boot with one cpu.

So far it seems that only the io apic for the BX chipset is affected
(only SMP BX boards contain an io apic).

Any volunteers with ne2k-pci cards and other motherboards that include
an io apic (e.g. all Intel motherboards that use an IO Controller Hub,
Via Apollo Pro133, Pro133A, KX133)?

Please:
* apply the attached patch.
* compile the kernel for SMP, or at least enable uniprocessor io apic
support.
* reboot.
* flood ping the computer with 2 concurrent flood pings from a second
computer.
* wait one minute.

According to the ICH2 documentation the IRR bit on the IO APIC is
writable - that's either a docu error, or could cause further problems.

--
Manfred

--- linux/arch/i386/kernel/apic.c   Tue Dec  5 21:43:48 2000
+++ linux/arch/i386/kernel/apic.c.new   Sat Jan 13 15:54:56 2001
@@ -270,7 +270,7 @@
 *   PCI Ne2000 networking cards and PII/PIII processors, dual
 *   BX chipset. ]
 */
-#if 0
+#if 1
/* Enable focus processor (bit==0) */
value &= ~(1<<9);
 #else

Re: 2.4 ate my filesystem on rw-mount

[Vojtech Pavlik]

On Sat, Jan 13, 2001 at 09:12:27AM +0100, Tobias Ringstrom wrote:

> > Wow. Ok, I'm maintaining the 2.4.0 VIA driver, so I'd like to know more
> > about this:
> >
> > 1) What's the ISA bridge revision?
> 
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8501 (rev 02)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8501
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 1b)
> 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
> 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 0e)
> 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 20)
> 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super 
>AC97/Audio] (rev 21)
> 00:0a.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine 10/100] (rev 06)
> 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i7 (rev 5b)

Ok, your IDE chip is a vt82c686a/ce.

> > 2) What's in /proc/ide/via?
> 
> It's not there since I disabled the VIA driver.

Ok. Could you send me this file when you boot with fs r-o?

> > 3) What says hdparm -i on your devices?
> 
> /dev/hda:
> 
>  Model=SAMSUNG VG34323A (4.32GB), FwRev=GQ200, SerialNo=dW1921060033c8
>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
>  RawCHS=14896/9/63, TrkSize=32256, SectSize=512, ECCbytes=21
>  BuffType=DualPortCache, BuffSize=496kB, MaxMultSect=16, MultSect=off
>  CurCHS=14896/9/63, CurSects=-531627904, LBA=yes, LBAsects=8446032
>  IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes: pio0 pio1 pio2 pio3 pio4
>  DMA modes: sdma0 sdma1 sdma2 *mdma0 mdma1 mdma2 udma0 udma1 *udma2

Looks good, too. An UDMA33 drive.

> > 4) If you mount your filesystem read-only, does it read garbage?
> 
> Now here's a strange part, or possibly a crusial clue.  When I booted a
> 2.4.0 kernel (from floppy using the excellent syslinux) with "ro
> init=/bin/sh", I could access the filesystem just fine.  I could even
> remount the root filesystem rw, and there were no problems.  But I did not
> write anything to the disk, since I was convinced that the problem was
> gone (this was the second try).  After this I rebooted with
> ctrl-alt-delete, forgetting how bad an idea that is with init=/bin/sh,
> booted up the RH7 2.2.16 kernel, and fsck was run with no errors.

So far no problem. Rebooting with c-a-d with fs r-o is OK.

> Now I
> though all was well, rebooted from floppy again, but without the init=
> part, and poof, it hang.

Where? It could be a different reason than IDE setup ...

> More interesting may be that I had to turn the computer off and on again
> to get BIOS to find the hard drive. Repeated long reset button presses
> did not help.  It is possible that it hung during BIOS hd detection - I
> wish I could remember.

I fear this isn't much of a clue, sorry.

> I suspect that I could have hung the drive with init=/bin/sh if I would
> have done some reading and writing to the device, besides ls.

Please try it. Best mke2fs your swap partition and try reading & writing
to that. You can mkswap it back after you finish.

> I think I can spend some more time today trying it out some more.

Please do. 'lspci -vvxxx' data for the case without a driver, with 2.4.0
driver and with 3.11 driver would help me find the problem.

Make sure you *don't* have any hdparm -d1 or hdparm -X66 or similar
stuff in your init scripts.

> I will
> also try your 3.11 driver, which seems to be an enormous cleanup.

the 2.1e driver is an enormous cleanup of the original driver from the
2.2 kernels. the 3.11 is an enormous cleanup of 2.1e, yes.

> Btw, do
> you have a home page for the VIA driver?  A CVS perhaps?  If not, please
> consider using sourceforge or something similar.

No, not yet, but working on that.

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

Re: Where did vm_operations_struct->unmap in 2.4.0 go?

[David Woodhouse]

On Sat, 13 Jan 2001, Keith Owens wrote:

> BTW, modutils cannot automatically fill in upward references when a
> module is loaded.  A reference is a use count, an automatic reference
> would be an automatic use count with no way of removing it.  Code that
> calls upwards to a symbol must perform an overt action to get the
> reference and cope with the case when the symbol is not there.  Think
> of it as a probe, "do I have facility XXX yet?".  It is up to the
> caller to probe as often as required.  Hot plugging for symbols, wheee!

We don't need to overdesign it. get_module_symbol() basically provided
this for us. The only thing really wrong with it was the lack of use
count handling, which I fixed a while ago.

Lack of runtime typechecking isn't a showstopper. Otherwise we'd have
thrown out GCC by now and rewritten the kernel in Modula-3.

That leaves the IA64 problem.

> Fixing this would mean tweaking get_module_symbol() on IA64 to
> recognise that the symbol is a function, build a function descriptor on
> the fly and return the address of the descriptor.  But the information
> about the types of symbols is not available in the kernel nor in
> modules after they are loaded, get_module_symbol() cannot differentiate
> between functions and anything else.  There is also the small matter of
> grubbing around in the arch dependent bit of struct modules to find the
> global pointer for the target function, more complexity.

This is already handled by modutils, presumably. How? By 'grubbing arouund
in the arch dependent bit of struct modules'? There's already a handful of
gp handling surrounded by #ifdef __alpha__ in module.c which doesn't seem
too unreasonable.

The caller knows what it's expecting to find. How about separate
get_module_function() and get_module_data() routines? Which are identical
on most architectures, but on (Alpha and?) IA64 could be defined to return
an appropriate structure.

> get_module_symbol() was usually used with a cast from unsigned long to
> some type that was defined in the calling .c file.  That made the
> caller code responsible for using the correct declaration.  It is
> better to define interfaces as shared data in a shared header.  Not
> perfect, but better.

We could quite happily define the function type in a shared header file,
and coding the original function and the subsequent cast from
get_module_symbol() using that definition.

Conversely, nothing stops you from using only local definitions for
the inter_module_xxx objects, rather than a single shared definition.

Nothing's changed. You just changed the users to use shared definitions
while you converted them to inter_module_xxx. But there's no fundamental
difference in the interface used, in this respect.

> With inter_module_xxx you have no type checking on the registered data.
> But you do not have to use EXPORT_SYMBOL_NOVERS on the shared symbols
> which means that any other users of the symbols will still get type
> checking.  Again, not perfect, but better.

Slightly. But for the cases where inter_module_xxx or get_module_symbol
are used,

A. AFAIK there are no such 'direct' users who get the
benefit of the runtime typechecking.

B. The authors are already having to pay attention to any
changes in the type of the exported data, rather than
just pretending that they're writing Java code and
expecting the runtime system to wipe the dribble
from their chins.

-- 
dwmw2


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

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

[yodaiken]

FWIW: POSIX mq_send does not promise that the buffer is safe, it only
promises that the message is queued. Interesting interface.



On Wed, Jan 10, 2001 at 09:41:24AM +0100, Manfred Spraul wrote:
> > > In user space, how do you know when its safe to reuse the buffer that 
> > > was handed to sendmsg() with the MSG_NOCOPY flag? Or does sendmsg() 
> > > with that flag block until the buffer isn't needed by the kernel any 
> > > more? If it does block, doesn't that defeat the use of non-blocking 
> > > I/O? 
> > 
> > sendmsg() marks those pages COW and copies the original page into a new 
> > one for further usage. (the old page is used until the packet is 
> > released.) So for maximum performance user-space should not reuse such 
> > buffers immediately. 
> >
> That means sendmsg() changes the page tables? I measures
> smp_call_function on my Dual Pentium 350, and it took around 1950 cpu
> ticks.
> I'm sure that for an 8 way server the total lost time on all cpus (multi
> threaded server) is larger than the time required to copy the complete
> page.
> (I've attached my patch, just run "insmod dummy p_shift=0")
> 
> 
> --
>   Manfred
> --- 2.4/drivers/net/dummy.c   Mon Dec  4 02:45:22 2000
> +++ build-2.4/drivers/net/dummy.c Wed Jan 10 09:15:20 2001
> @@ -95,9 +95,168 @@
>  
>  static struct net_device dev_dummy;
>  
> +/* * */
> +int p_shift = -1;
> +MODULE_PARM (p_shift, "1i");
> +MODULE_PARM_DESC(p_shift, "Shift for the profile buffer");
> +
> +int p_size = 0;
> +MODULE_PARM (p_size, "1i");
> +MODULE_PARM_DESC(p_size, "size");
> +
> +
> +#define STAT_TABLELEN16384
> +static unsigned long totals[STAT_TABLELEN];
> +static unsigned int overflows;
> +
> +static unsigned long long stime;
> +static void start_measure(void)
> +{
> +  __asm__ __volatile__ (
> + ".align 64\n\t"
> + "pushal\n\t"
> + "cpuid\n\t"
> + "popal\n\t"
> + "rdtsc\n\t"
> + "movl %%eax,(%0)\n\t"
> + "movl %%edx,4(%0)\n\t"
> + : /* no output */
> + : "c"()
> + : "eax", "edx", "memory" );
> +}
> +
> +static void end_measure(void)
> +{
> +static unsigned long long etime;
> + __asm__ __volatile__ (
> + "pushal\n\t"
> + "cpuid\n\t"
> + "popal\n\t"
> + "rdtsc\n\t"
> + "movl %%eax,(%0)\n\t"
> + "movl %%edx,4(%0)\n\t"
> + : /* no output */
> + : "c"()
> + : "eax", "edx", "memory" );
> + {
> + unsigned long time = (unsigned long)(etime-stime);
> + time >>= p_shift;
> + if(time < STAT_TABLELEN) {
> + totals[time]++;
> + } else {
> + overflows++;
> + }
> + }
> +}
> +
> +static void clean_buf(void)
> +{
> + memset(totals,0,sizeof(totals));
> + overflows = 0;
> +}
> +
> +static void print_line(unsigned long* array)
> +{
> + int i;
> + for(i=0;i<32;i++) {
> + if((i%32)==16)
> + printk(":");
> + printk("%lx ",array[i]); 
> + }
> +}
> +
> +static void print_buf(char* caption)
> +{
> + int i, other = 0;
> + printk("Results - %s - shift %d",
> + caption, p_shift);
> +
> + for(i=0;i + int j;
> + int local = 0;
> + for(j=0;j<32;j++)
> + local += totals[i+j];
> +
> + if(local) {
> + printk("\n%3x: ",i);
> + print_line([i]);
> + other += local;
> + }
> + }
> + printk("\nOverflows: %d.\n",
> + overflows);
> + printk("Sum: %ld\n",other+overflows);
> +}
> +
> +static void return_immediately(void* dummy)
> +{
> + return;
> +}
> +
> +static void just_one_page(void* dummy)
> +{
> + __flush_tlb_one(0x12345678);
> + return;
> +}
> +
> +
>  static int __init dummy_init_module(void)
>  {
>   int err;
> +
> + if(p_shift != -1) {
> + int i;
> + void* p;
> + kmem_cache_t* cachep;
> + /* empty test measurement: */
> + printk(" kernel cpu benchmark started **\n");
> + clean_buf();
> + set_current_state(TASK_UNINTERRUPTIBLE);
> + schedule_timeout(200);
> + for(i=0;i<100;i++) {
> + start_measure();
> + return_immediately(NULL);
> + return_immediately(NULL);
> + return_immediately(NULL);
> + return_immediately(NULL);
> + end_measure();
> + }
> + print_buf("zero");
> + clean_buf();
> +
> + set_current_state(TASK_UNINTERRUPTIBLE);
> + schedule_timeout(200);
> + for(i=0;i<100;i++) {
> +   

[Patch] symlink fix for shm/swap fs

[Christoph Rohland]

Hi Alan,

Here comes a patch which fixes the totally broken symlink support in
shm/swapfs. It is additional to my former patches for read and write
support.

It survives now a parallel kernel make on my 8way.

Greetings
Christoph

diff -uNr 2.4.0-shm_vm_locked-truncate-rw-swapfs/mm/shmem.c 
2.4.0-shm_vm_locked-truncate-rw-swapfs-symlink/mm/shmem.c
--- 2.4.0-shm_vm_locked-truncate-rw-swapfs/mm/shmem.c   Sat Jan 13 13:22:59 2001
+++ 2.4.0-shm_vm_locked-truncate-rw-swapfs-symlink/mm/shmem.c   Sat Jan 13 16:29:53 
+2001
@@ -39,6 +39,7 @@
 static struct inode_operations shmem_inode_operations;
 static struct file_operations shmem_dir_operations;
 static struct inode_operations shmem_dir_inode_operations;
+static struct inode_operations shmem_symlink_inode_operations;
 static struct vm_operations_struct shmem_vm_ops;
 
 LIST_HEAD (shmem_inodes);
@@ -127,7 +128,7 @@
 
spin_lock (>lock);
index = (inode->i_size + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
-   if (index >= info->max_index)
+   if (index > info->max_index)
goto out;
 
start = shmem_truncate_part (info->i_direct, SHMEM_NR_DIRECT, index, );
@@ -419,7 +420,7 @@
inode->i_fop = _dir_operations;
break;
case S_IFLNK:
-   inode->i_op = _symlink_inode_operations;
+   inode->i_op = _symlink_inode_operations;
break;
}
spin_lock (_ilock);
@@ -787,14 +788,63 @@
 static int shmem_symlink(struct inode * dir, struct dentry *dentry, const char * 
symname)
 {
int error;
+   int len;
+   struct inode *inode;
+   struct page *page;
+   char *kaddr;
 
error = shmem_mknod(dir, dentry, S_IFLNK | S_IRWXUGO, 0);
-   if (!error) {
-   int l = strlen(symname)+1;
-   struct inode *inode = dentry->d_inode;
-   error = block_symlink(inode, symname, l);
-   }
-   return error;
+   if (error)
+   return error;
+
+   len = strlen(symname);
+   if (len > PAGE_SIZE)
+   return -ENAMETOOLONG;
+   
+   inode = dentry->d_inode;
+   down(>i_sem);
+   page = shmem_getpage_locked(inode, 0);
+   if (IS_ERR(page))
+   goto fail;
+   kaddr = kmap(page);
+   memcpy(kaddr, symname, len);
+   kunmap(page);
+   inode->i_size = len;
+   SetPageDirty(page);
+   UnlockPage(page);
+   page_cache_release(page);
+   up(>i_sem);
+   return 0;
+fail:
+   up(>i_sem);
+   return PTR_ERR(page);
+}
+
+static int shmem_readlink(struct dentry *dentry, char *buffer, int buflen)
+{
+   struct page * page;
+   int res = shmem_getpage(dentry->d_inode, 0, );
+
+   if (res)
+   return res;
+
+   res = vfs_readlink(dentry,buffer,buflen, kmap(page));
+   kunmap(page);
+   page_cache_release(page);
+   return res;
+}
+
+static int shmem_follow_link(struct dentry *dentry, struct nameidata *nd)
+{
+   struct page * page;
+   int res = shmem_getpage(dentry->d_inode, 0, );
+   if (res)
+   return res;
+
+   res = vfs_follow_link(nd, kmap(page));
+   kunmap(page);
+   page_cache_release(page);
+   return res;
 }
 
 static int shmem_parse_options(char *options, int *mode, unsigned long * blocks, 
unsigned long *inodes)
@@ -912,6 +962,12 @@
 
 static struct inode_operations shmem_inode_operations = {
truncate:   shmem_truncate,
+};
+
+static struct inode_operations shmem_symlink_inode_operations = {
+   truncate:   shmem_truncate,
+   readlink:   shmem_readlink,
+   follow_link:shmem_follow_link,
 };
 
 static struct file_operations shmem_dir_operations = {

-
To unsubscribe from this list: send 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:reiserfs 3.6.25 + LVM(Fix oops reiserfs filesystem)

[hugang]

--- reiserfs_fs.h.old   Sat Jan 13 22:17:45 2001
+++ reiserfs_fs.h   Sat Jan 13 22:46:42 2001
@@ -1420,7 +1420,7 @@
 #define op_is_left_mergeable(key,bsize)  item_ops[le_key_k_type 
(le_key_version (key), key)]->is_left_mergeable (key, bsize)
 #define op_print_item(ih,item)   item_ops[le_ih_k_type 
(ih)]->print_item (ih, item)
 #define op_check_item(ih,item)   item_ops[le_ih_k_type 
(ih)]->check_item (ih, item)
-#define op_create_vi(vn,vi,is_affected,insert_size)  item_ops[le_ih_k_type 
(vi->vi_ih)]->create_vi (vn,vi,is_affected,insert_size)
+#define op_create_vi(vn,vi,is_affected,insert_size)  
+item_ops[le_ih_k_type(vi->vi_ih)]->create_vi > 0 ? item_ops[le_ih_k_type 
+(vi->vi_ih)]->create_vi(vn,vi,is_affected,insert_size) : 0
 #define op_check_left(vi,free,start_skip,end_skip)   
item_ops[(vi)->vi_index]->check_left (vi, free, start_skip, end_skip)
 #define op_check_right(vi,free)  
item_ops[(vi)->vi_index]->check_right (vi, free)
 #define op_part_size(vi,from,to) 
item_ops[(vi)->vi_index]->part_size (vi, from, to)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ide.2.4.1-p3.01112001.patch

[Bryan O'Sullivan]

v> I can make one for you, but first I'd like to find out what exactly are
v> the problem cases.

I have a VT82C686 motherboard.  It has one UDMA-100 slot and two
regular IDE slots.  I have an IBM DTTA-371440 (about 18 months old) as
hda (only fat32 filesystems), and an IBM DTLA-307030 as hde
(i.e. plugged into the UDMA-100 slot).  I've never seen any problems
with DMA on the newer drive, but if I turn on DMA and do anything with
the older drive, I get stuff like this:

  /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 { DriveReady 
SeekComplete Error } 
  hda: dma_intr: error=0x84 { DriveStatusError BadCRC } 
  hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } 
  hda: dma_intr: error=0x84 { DriveStatusError BadCRC } 
  hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } 
  hda: dma_intr: error=0x84 { DriveStatusError BadCRC } 
  hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } 
  hda: dma_intr: error=0x84 { DriveStatusError BadCRC } 

The driver attempts to reset ide0 a few times, gets more of the above,
then gives up with an I/O error.

I've been seeing these problems as long as I've been tracking the 2.3
series, up to and including 2.4.0.  I can't boot a 2.2 kernel on this
machine to compare, as it doesn't recognise hde (which is where Linux
lives).

Here's the output of lspci under 2.4.0, in case it's useful:

  00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
  00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
  00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
  00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
  00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
  00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
  00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
  00:09.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
  00:09.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
  00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
  00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08)
  00:0b.1 Input device controller: Creative Labs SB Live! (rev 08)
  00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 
0d30 (rev 02)
  01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0150 (rev a3)

If you need any more information, I can dig it out.

http://www.tux.org/lkml/

Re: shmem or swapfs? was: [Patch] make shm filesystem part configurable

[Christoph Rohland]

David Ford <[EMAIL PROTECTED]> writes:

> Hmm, ok, what are the activities that use this other than shm?

You can e.g. use it for your /tmp filesystem. there seem to be some
people out there which used ramfs for that...

What do you think about "vmfs"? This probably reflects its nature
better than swapfs.

Greetings
Christoph

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

PS/2 mouse access kills keyboard

[Igmar Palsenberg]

Hi,

on plain 2.4.0 vanilla any mouse access kills the keyboard. Only way to
restore functionality is to kill gpm.

gpm writes 'protocol error' to syslog. I have access to this machine on
monday, so I can post details then.

Changing the IRQ is totally unrelated, machine works in 2.2.x with the
same config.


regards,


Igmar


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

blk-13B

[Giuliano Pochini]

Hi!

I found the time to make some tests with 2.4 and the blk-13B patch.
It performs very well, no process starvation, no missed merges,
etc., but sometimes it happens dbflush and kswapd start eating
100% CPU for about 20-30 secs.:

 11:02am  up 18 min,  5 users,  load average: 2.74, 1.97, 1.15
66 processes: 60 sleeping, 6 running, 0 zombie, 0 stopped
CPU states:  2.7% user, 97.2% system,  0.0% nice,  0.0% idle
Mem:  189568K av, 188520K used,   1048K free, 209144K shrd,   1168K buff
Swap: 262136K av,  0K used, 262136K free122764K cached

 PID USER   PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
   3 root20   0 00 0 SW  0 45.1  0.0   0:21 kswapd
   5 root14   0 00 0 RW  0 44.5  0.0   0:29 bdflush
 606 Giu  9   0   464  464   352 R   0  3.6  0.2   0:02 cp
 543 Giu  9   0   604  604   472 S   0  1.9  0.3   0:14 vmstat


vmstat doesn't show anything strange at the same time:

   procsmemoryswap  io system cpu
 r  b  w  swpd  free   buff  cache  si  sobibo   incs  us  sy  id
 2  0  00   1048   1304 122564   0   0  8960  4486  156   771  11  25  64
 3  0  00   1048   1304 122564   0   0  9856  4996  123   622   3  30  67
 1  0  10   1048   1304 122564   0   0  4096  1867   62   431   1  76  23
 2  0  10   1048   1304 122560   0   0  1920   963   26   130   1  99   0
 4  1  20   1048   1304 122564   0   0  1536   647  164   271   3  97   0
 2  0  20   1048   1304 122564   0   0   760   516  139   482   6  94   0
 1  1  20   1048   1304 122560   0   0   896   461  275   932  10  90   0
 1  0  20   1048   1304 122552   0   0   672   452  130   988   7  93   0
 1  0  20   1048   1304 122552   0   0   896   520  180  1905  11  89   0
 2  0  20   1052   1304 122552   0   0   512   515   26   462   4  96   0
 1  1  20   1048   1304 122556   0   0   740   519  109   428   1  99   0
 3  0  10   1048   1228 122624   0   0  1052   516   23   175   4  96   0

The scsi driver reported it was writing large contiguous blocks and, 30secs
later, a few 10s of smaller non mergeable block. It's ok IMO.
ps doesn't show anything useful:

[Giu@Jay Giu]$ ps -xao cmd,wchan
CMD  WCHAN
init do_select
[keventd]context_thread
[kswapd] -
[kreclaimd]  kreclaimd
[bdflush]-
[kupdate]kupdate
[khubd]  usb_hub_thread


The test is a large file copy from the HD to my MO. During the cp and
now there's nothing on the swap.
My config:

PowerPC 750, 192MB ram, 256MB swap, kernel 2.4.0-bitkeeper (the official
2.4 doesn't compile) + blk-13B, Adaptec 2930U, gcc 2.95.3. The rest is a
2.2.x distribution.


Bye.

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

PPC 2.4 ?

[Giuliano Pochini]

When will the powerpc tree be merged ?  Neither the
official 2.4 nor the -ac8 work. They don't even compile.

Bye.


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

video drivers hog pci bus ? [was:[linux-audio-dev] low-latency scheduling patch for 2.4.0]

[Jörn Nettingsmeier]

[alsa folks, i'd appreciate a comment on this thread from
linux-audio-dev]

hello everyone !

in a post related to his latest low-latency patch, andrew morton
gave a pointer to
http://www.zefiro.com/vgakills.txt , which addresses the problem of
dropped samples due to agressive video drivers hogging the pci bus
with retry attempts to optimize benchmark results while producing a
"zipper" noise, e.g. when moving windows around with the mouse while
playing a soundfile.
some may have tried fiddling with the "pci retry" option in the
XF86Config (see the linux audio quality howto by paul winkler at
http://www.linuxdj.com/audio/quality for details).

i recall some people having reported mysterious l/r swaps w/ alsa
drivers on some cards, and iirc, most of these reports were not
easily reproduced and explained. 
the zefiro paper states that the zefiro cards would swap channels
occasionally under the circumstances mentioned. it sounds probable
to me that all drivers using interleaved data would suffer from this
problem.

can some more experienced people comment on this ?
is my assumption correct that the bus hogging behaviour is affected
by the pci_retry option ?

btw: the text only mentions pci video cards. will agp cards also
clog the pci bus ?

please give some detail in your answers - i would like to include
this in the linux-audio-dev faq and resources pages. (so chances are
you will only have to answer this once :)


sorry if this has been dealt with before, i seem to have trouble to
follow all my mailing lists...


regards,

jörn


Andrew Morton wrote:
> 
> >
> > > A patch against kernel 2.4.0 final which provides low-latency
> > > scheduling is at
> > >
> > >   http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads
> > >
> > > Some notes:
> > >
> > > - Worst-case scheduling latency with *very* intense workloads is now
> > >   0.8 milliseconds on a 500MHz uniprocessor.
> Neither, I think.
> 
> We can't apply some patch and say "there; it's low-latency".
> 
> 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 to which must beard-scratching must
> be put.  It goes way beyond the preemptive-kernel patches which have
> thus far been proposed.
> 
> 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).
> 
> That would probably be a great and sufficient improvement for
> the HA heartbeat monitoring apps, the database TP monitors,
> the QuakeIII players and, of course, people who are only
> interested in audio record and playback - I'd need advice
> from the audio experts for that.
> 
> 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, and that they decide to offer
> a low-latency kernel for the other 99.99% of Linux users.
> >
> > Well it's extremely nice to see NFS included at least.  I was really
> > worried about that one.  What about Samba?  (Keeping in mind that
> > serious "professional" musicians will likely have their Linux systems
> > networked to a Windows box, at least until they have all the necessary
> > tools on Linux.
> 
> > > - If you care about latency, be *very* cautious about upgrading to
> > >   XFree86 4.x.  I'll cover this issue in a separate email, copied
> > >   to the XFree team.
> 
> I haven't gathered the energy to send it.
> 
> The basic problem with many video cards is this:
> 
> Video adapters have on-board command FIFOs.  They also
> have a "FIFO has spare room" control bit.
> 
> If you write to the FIFO when there is no spare room,
> the damned thing busies the PCI bus until there *is*
> room.  This can be up to twenty *milliseconds*.
> 
> This will screw up realtime operating systems,
> will cause network receive overruns, will screw
> up isochronous protocols such as USB and 1394
> and will of course screw up scheduling latency.
> 
> In xfree3 it was OK - the drivers polled the "spare room"
> bit before writing.  But in xfree4 the drivers are starting
> to take advantage of this misfeature.  I am told that
> a significant number of people are backing out xfree4
> upgrades because of this.  For audio.
> 
> The manufacturers got caught out by the trade press
> in '98 and '99 and they added registry flags to their
> drivers to turn off this obnoxious behaviour.
> 
> What needs to happen is for the xfree guys to add a
> control flag to XF86Config for this.  I believe they
> have - it's called `PCIRetry'.
> 
> I believe PCIRetry defaults to `off'.  This is bad.
> It should default to `on'.
> 
> You can read about this minor scandal at the following
> URLs:
> 
> http://www.zefiro.com/vgakills.txt
> 

$B=K!*$4@.?M(B**

[Over Twenty]

$B$4@.?M%*%a%G%H%&%4%6%$%^%9(B
http://www.gem.hi-ho.ne.jp/p-head/tobi/infdex.htm
$B$4@.?M0J30$O:o=|$7$F$/$@$5$$(B
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Latency: allowing resheduling while holding spin_locks

[Roger Larsson]

Hi,

A rethinking of the rescheduling strategy...

I have come to this conclusion.

A spinlock prevents other processes to enter that specific region.
But interrupts are allowed they might delay 
execution of a spin locked
reqion for a undefined (small but anyway) time.

Code with critical maximum times should use spin_lock_irq !

=> spin_locks are not about disallowing reschedules.


Prior to the introduction of spin locks it did not make sense to
allow reschedules in kernel since the big kernel lock was so big...
Any code that wanted do any non pure computation task would
hit it very quickly.

Now with spin locks the situation is quite different...

[First assume UP kernel for simplicity]

Suppose you have two processes one that normal (P) and one high priority 
(RTP).

P runs user code, makes a system call, enters a spin lock region.

Interrupt!

The interrupt service routine wakes up RTP, which marks P as need_reschedule, 
and returns, on return from interrupt it detects that P needs_reschedule -
do it even if it is executing in kernel and holding a spin_lock.

RTP starts, and if it does not hit the same spin_lock there is nothing 
special happening until it goes to sleep again. But suppose it does!

RTP tries to get the spin_lock but fails, since it is the currently highest 
prio process and P is running it wants to reschedule to P to get its own 
stuff done.

P runs the final part of its spin_locked region, upon spin_unlock it needs to
get RTP running.

Something like this:

spin_lock(lock)
{
while (test_and_set(lock->lock)) {
schedule_spinlock(); /* kind of yield, giving low goodness, sticky */
}
}

spin_unlock(lock)
{
clear(lock);

/* note: someone with higher prio than me,
   might steal the lock from even higher prio waiters here */

if (lock->queue)
wakeup_spinlock_yielder(lock);
}


schedule_spinlock()
{
/* note: owner can not run here, it has lower prio */

addqueue(lock->queue, current);

p->policy |= SCHED_SPINLOCK;
schedule();
}

wakeup_spinlock_yielder(lock)
{
int need_resched = 0;

int my_goodness = goodness(current);

forall p in lock->queue
p->policy &= ~SCHED_SPINLOCK;
if (goodness(p) > my_goodness)
need_resched = 1;
}

if (need_resched)
schedule();
}


A final note on spin_lock_irq, since they prevent IRQs there will be no 
requests to wakeup any process during their locked region => no problems.

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

Re: shmem or swapfs? was: [Patch] make shm filesystem part configurable

[David Ford]

> It is a filesystem which lives in RAM and can swap out. SYSV shm and
> shared anonymous maps are still build on top of this (The config
> option only disables the part not needed for this).
>
> I am quite open about naming, but "shm" is not appropriate any more
> since the fs does a lot more than shared memory. Solaris calles this
> "tmpfs" but I did not want to 'steal' their name and I also do not
> think that it's a very good name.
>
> So any suggestions for a better name?

Hmm, ok, what are the activities that use this other than shm?

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

Re: sparc10 with 512M of RAM hangs on boot

[Jan-Benedict Glaw]

On Fri, Jan 12, 2001 at 07:48:09PM -0800, Ron Calderon wrote:
> every kernel after 2.4.0-test5 hangs my sparc10
> at the same spot. Has anyone looked into this?

Well, that's when highmen support was introduced into sparc32, right?

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

That's quite the same output I get. However, supplying mem=128M
(I have got 128MB) at least allows me to boot up with about
25MB of RAM (sparc has holes...):

CVS_Root  DIFF_f  REMOVE  scsi-gui
jbglaw@sparcling:~$ cat /proc/cmdline 
ro root=/dev/sda1 mem=128M console=ttya
jbglaw@sparcling:~$ free
 total   used   free sharedbuffers cached
Mem: 26564  21720   4844  0720  12104
-/+ buffers/cache:   8896  17668
Swap:49840  0  49840
jbglaw@sparcling:~$ uname -a
Linux sparcling 2.4.0-test12 #2 SMP Sat Dec 16 02:25:25 CET 2000 sparc unknown

It's a SparcStation 10 w/ 2 CPUs.

Anton, do you have any clue where changes could have broke SS10 support?

MfG, JBG

-- 
Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!!
/* Jan-Benedict Glaw <[EMAIL PROTECTED]> -- +49-177-5601720 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
 "insmod vi.o and there we go..." (Alexander Viro on linux-kernel)

 PGP signature

[patch] symlink creation broken in shmem.c

[Christoph Rohland]

Hi Linus,

The shmem_symlink function is completely broken in 2.4.0 and never
worked.

This patch removes the function from 2.4.0

Greetings
Christoph

P.S.: For those which test read/write support patch: I will post patch
  for my swapfs soon which will make it working on top of that


diff -uNr 2.4.0/mm/shmem.c 2.4.0-nosymlink/mm/shmem.c
--- 2.4.0/mm/shmem.cSat Jan 13 14:20:51 2001
+++ 2.4.0-nosymlink/mm/shmem.c  Sat Jan 13 14:18:26 2001
@@ -374,8 +374,7 @@
inode->i_fop = _dir_operations;
break;
case S_IFLNK:
-   inode->i_op = _symlink_inode_operations;
-   break;
+   BUG();
}
spin_lock (_ilock);
list_add (>u.shmem_i.list, _inodes);
@@ -528,19 +527,6 @@
return error;
 }
 
-static int shmem_symlink(struct inode * dir, struct dentry *dentry, const char * 
symname)
-{
-   int error;
-
-   error = shmem_mknod(dir, dentry, S_IFLNK | S_IRWXUGO, 0);
-   if (!error) {
-   int l = strlen(symname)+1;
-   struct inode *inode = dentry->d_inode;
-   error = block_symlink(inode, symname, l);
-   }
-   return error;
-}
-
 static int shmem_mmap(struct file * file, struct vm_area_struct * vma)
 {
struct vm_operations_struct * ops;
@@ -677,7 +663,6 @@
lookup: shmem_lookup,
link:   shmem_link,
unlink: shmem_unlink,
-   symlink:shmem_symlink,
mkdir:  shmem_mkdir,
rmdir:  shmem_rmdir,
mknod:  shmem_mknod,

-
To unsubscribe from this list: send the 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

[Vojtech Pavlik]

On Fri, Jan 12, 2001 at 11:43:23PM +, Alan Cox wrote:
> > 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 ?

As far as I know the same as on FIC VA-503+, that is vt82c598 north and
vt82c586b south - the MVP3 chipset. I've got the VA-503+ here and it
works really well. the 503+ and the 2013 differ only in form factor, one
is Baby AT (503+) and the other is ATX.

It's vt82c586b, and most probably 3041 silicon - the most bugless VIA
southbridge I know of ...

Weird. Could the person who reported it test the 2.4.0 kernel? I think
the 2.2 drivers had some MVP3 (and 3041 silicon)  related bugs. 3041 has
some registers layed out differently from all other chips.

Btw, this is not the 586 nor 586a, so changing the test to test for just
these two probably won't be the right thing to do ...

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

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

On Sat, Jan 13, 2001 at 02:43:30AM +, [EMAIL PROTECTED] 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).

598 + 586b

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

Windows driver compatibility, so that VP3 drivers would work on MVP3 as
well.

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

This doesn't do anything but change the ID so that Linux drivers are not
confused anymore. This caused a lot of trouble in 2.2, especially with
the old VIA IDE driver.

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

Actually, the definitions of what's a 'true VIA xxx chipset' change over
time, as VIA upgrades the southbridges in the specs. You'll now fing
that the VPX chipset is 587vpx + 586b, but when released the 587vpx was
coupled with the old 586 south.

Fortunately all these chips use PIIX-compatible extensions to the PCI
bus, so they are all interchangeable to some degree.

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

It's possible. I have a board (VA-503A), which has a masqueraded 598,
which identifies itself as 597, and a 686a southbridge. This got the
2.2 ide driver completely confused, for example. 

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

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

On Fri, Jan 12, 2001 at 04:09:22PM -0800, Linus Torvalds wrote:

> 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

Ok, here goes the patch.

Note that with this patch, all VIA users will get IDE transferrates
about 3 MB/sec as opposed to about 20 MB/sec without it (and with
UDMA66). 

This patch disables automatic DMA on all VIA chipsets, including the
ancient 82c561 for 486's, and up to the 686a UDMA66 chipset.

Also note that enabling the DMA later with hdparm -X66 -d1 or similar
command is not safe, and usually works by pure luck on VIA chipsets.
This however, would need some non-minor changes to the generic code to
fix.

But perhaps it's still worth ...

-- 
Vojtech Pavlik
SuSE Labs


diff -urN linux-old/drivers/ide/ide-pci.c linux/drivers/ide/ide-pci.c
--- linux-old/drivers/ide/ide-pci.c Wed Jan  3 01:58:45 2001
+++ linux/drivers/ide/ide-pci.c Sat Jan 13 14:54:53 2001
@@ -663,7 +663,9 @@
if (IDE_PCI_DEVID_EQ(d->devid, DEVID_SIS5513) ||
IDE_PCI_DEVID_EQ(d->devid, DEVID_AEC6260) ||
IDE_PCI_DEVID_EQ(d->devid, DEVID_PIIX4NX) ||
-   IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X))
+   IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X)  ||
+   IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
+   IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
autodma = 0;
if (autodma)
hwif->autodma = 1;
diff -urN linux-old/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
--- linux-old/drivers/ide/via82cxxx.c   Tue Nov  7 20:02:24 2000
+++ linux/drivers/ide/via82cxxx.c   Sat Jan 13 14:52:26 2001
@@ -602,7 +602,6 @@
 #ifdef CONFIG_BLK_DEV_IDEDMA
if (hwif->dma_base) {
hwif->dmaproc = _dmaproc;
-   hwif->autodma = 1;
}
 #endif /* CONFIG_BLK_DEV_IDEDMA */
 }

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

On Fri, Jan 12, 2001 at 04:52:00PM -0800, 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.
> > 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, but this is a different problem. No corruption was happening here.

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

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

Hi!

I think that with 2.4.0 your board will operate just fine at UDMA33. If
you can, please do test that. Best mount your drives read only at first,
but I doubt there will be any problems.

Vojtech

On Fri, Jan 12, 2001 at 08:03:49PM -0700, Tkil wrote:
> 
> 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, 

Re: ide.2.4.1-p3.01112001.patch

[Vojtech Pavlik]

On Fri, Jan 12, 2001 at 11:47:41PM +, Alan Cox 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.
> 
> I have no reports of problems with the later stuff

At least the one you sent to me is about 586b. Which is 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

I can make one for you, but first I'd like to find out what exactly are
the problem cases.

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

Re: shmem or swapfs? was: [Patch] make shm filesystem part configurable

[Christoph Rohland]

David Ford <[EMAIL PROTECTED]> writes:

> Now...is this shared memory or swap?  If it's swap, why is it
> different than a swapfile?  If you are intending the shmem be called
> swapfs, I personally thing that it'll cause a significant amount of
> confusion.

It is a filesystem which lives in RAM and can swap out. SYSV shm and
shared anonymous maps are still build on top of this (The config
option only disables the part not needed for this).

I am quite open about naming, but "shm" is not appropriate any more
since the fs does a lot more than shared memory. Solaris calles this
"tmpfs" but I did not want to 'steal' their name and I also do not
think that it's a very good name.

So any suggestions for a better name?

Greetings
Christoph

-
To unsubscribe from this list: send the 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

[Christoph Lameter]

On Fri, 12 Jan 2001, dean gaudet wrote:

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

Well as Arjan says: khttpd starves userspace and that might cause the
latency. I dont have the ability to really test it over a 100mbs link.

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

Its a Cyrix 150. So 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/