Re: eepro100 + 2.2.18 + laptop problems

[CaT]

On Tue, Feb 20, 2001 at 11:31:52AM +1100, CaT wrote:
> On Mon, Feb 19, 2001 at 04:18:40PM -0800, Ion Badulescu wrote:
> > > In my experiments wait_for_cmd timeouts almost always were related to
> > > DumpStats command.
> > > I think, we need to investigate what time constraints are related to this
> > > command.
> > 
> > Nothing documented...
> > 
> > CaT, can you apply this debugging patch and let us know what you get in the
> > logs? It should allow us to pinpoint the error a bit more precisely.
> 
> patched, old removed, new installed, waiting for fubar. :)

Ok. this is what I got in my kern.log. this is on a fresh reboot.

Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!
Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0xff90) timedout 
with(0xff90)!
Feb 20 18:32:21 theirongiant last message repeated 29 times
Feb 20 18:33:15 theirongiant last message repeated 31 times
Feb 20 18:33:16 theirongiant kernel: eth0: Transmit timed out: status   0c90 at 
0/63 command 0001a000.
Feb 20 18:33:16 theirongiant kernel: eth0: Tx ring dump,  Tx queue 63 / 0:
Feb 20 18:33:16 theirongiant kernel: eth0:  *  0 0001a000.
Feb 20 18:33:16 theirongiant kernel: eth0: 1 0002.
Feb 20 18:33:16 theirongiant kernel: eth0: 2 0003.
Feb 20 18:33:16 theirongiant kernel: eth0: 3 0003.
Feb 20 18:33:16 theirongiant kernel: eth0: 4 0003.
Feb 20 18:33:16 theirongiant kernel: eth0: 5 0003.
Feb 20 18:33:16 theirongiant kernel: eth0: 6 0003.
Feb 20 18:33:16 theirongiant kernel: eth0: 7 0003.
Feb 20 18:33:16 theirongiant kernel: eth0: 8 0002.
Feb 20 18:33:16 theirongiant kernel: eth0: 9 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:10 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:11 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:12 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:13 000c.
Feb 20 18:33:16 theirongiant kernel: eth0:14 000c.
Feb 20 18:33:16 theirongiant kernel: eth0:15 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:16 200c.
Feb 20 18:33:16 theirongiant kernel: eth0:17 000c.
Feb 20 18:33:16 theirongiant kernel: eth0:18 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:19 000c.
Feb 20 18:33:16 theirongiant kernel: eth0:20 000c.
Feb 20 18:33:16 theirongiant kernel: eth0:21 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:22 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:23 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:24 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:25 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:26 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:27 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:28 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:29 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:30 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:31 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:32 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:33 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:34 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:35 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:36 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:37 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:38 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:39 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:40 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:41 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:42 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:43 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:44 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:45 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:46 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:47 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:48 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:49 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:50 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:51 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:52 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:53 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:54 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:55 000c.
Feb 20 18:33:16 theirongiant kernel: eth0:56 000c.
Feb 20 18:33:16 theirongiant kernel: eth0:57 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:58 000c.
Feb 20 18:33:16 theirongiant kernel: eth0:59 000c.
Feb 20 18:33:16 theirongiant kernel: eth0:60 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:61 0003.
Feb 20 18:33:16 theirongiant kernel: eth0:62 4003.
Feb 20 18:33:16 theirongiant kernel: eth0:   =63 .
Feb 20 18:

Re: eepro100.c, kernel 2.4.1

[Andrey Savochkin]

On Tue, Feb 20, 2001 at 03:30:48PM +0900, Augustin Vidovic wrote:
> On Mon, Feb 12, 2001 at 01:00:34AM -0800, Ion Badulescu wrote:
> > > Augustin, could you send the output of `lspci' and `eepro100-diag -ee', please?
> > > (The latter may be taken from ftp://scyld.com/pub/diag/)
> > 
> > I'd be curious to see them too.
> 
> Ok, here is the output (the status are displayed only if the interface
> is down, so I had to go execute this manually on the machines) :
> 
> 
> eepro100-diag.c:v2.02 7/19/2000 Donald Becker ([EMAIL PROTECTED])
>  http://www.scyld.com/diag/index.html
> Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xef00.
[snip]

What about lspci?

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

Re: Kernel executation from ROM

[Eric W. Biederman]

Peter Waltenberg <[EMAIL PROTECTED]> writes:

> Having a PC that booted Linux directly from the (ex-BIOS) ROM , now that
> would be "interesting".

Been there doing that.
http://www.linuxbios.org


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

Re: usb audio

[Landsberger Brian J]

No sound comes forth from them, not even so much as a whisper.

Thomas Sailer wrote:

> Landsberger Brian J wrote:
> 
>> Has anyone been able to get the Apple Pro (the round clear) speakers to
>> work in Linux? I've read the howto's and followed the various steps to
>> no avail. The various usb modules print the following to syslog:
> 
> 
> This looks ok. So what is wrong?
> 
> Tom


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

Re: eepro100.c, kernel 2.4.1

[Augustin Vidovic]

On Mon, Feb 12, 2001 at 01:00:34AM -0800, Ion Badulescu wrote:
> > Augustin, could you send the output of `lspci' and `eepro100-diag -ee', please?
> > (The latter may be taken from ftp://scyld.com/pub/diag/)
> 
> I'd be curious to see them too.

Ok, here is the output (the status are displayed only if the interface
is down, so I had to go execute this manually on the machines) :


eepro100-diag.c:v2.02 7/19/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xef00.
i82557 chip registers at 0xef00:
     00080002 182541e1 0600
  No interrupt sources are pending.
   The transmit unit state is 'Idle'.
   The receive unit state is 'Idle'.
  This status is unusual for an activated interface.
Index #2: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xee80.
i82557 chip registers at 0xee80:
     00080002 183f 
  No interrupt sources are pending.
   The transmit unit state is 'Idle'.
   The receive unit state is 'Idle'.
  This status is unusual for an activated interface.
eepro100-diag.c:v2.02 7/19/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xef00.
i82557 chip registers at 0xef00:
     00080002 182541e1 0600
  No interrupt sources are pending.
   The transmit unit state is 'Idle'.
   The receive unit state is 'Idle'.
  This status is unusual for an activated interface.
Index #2: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xee80.
i82557 chip registers at 0xee80:
     00080002 183f 
  No interrupt sources are pending.
   The transmit unit state is 'Idle'.
   The receive unit state is 'Idle'.
  This status is unusual for an activated interface.
eepro100-diag.c:v2.02 7/19/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xef00.
Intel EtherExpress Pro 10/100 EEPROM contents:
  Station address 00:D0:B7:00:BE:00.
  Board assembly 00-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
Index #2: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xee80.
Intel EtherExpress Pro 10/100 EEPROM contents:
  Station address 00:D0:B7:00:BE:01.
  Board assembly 00-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
eepro100-diag.c:v2.02 7/19/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xef00.
EEPROM contents, size 64x16:
00: d000 00b7 00be 0c03 0003 0201 4701 
  0x08:   40a2 3000 8086   
  ...
  0x38:        a315
 The EEPROM checksum is correct.
Intel EtherExpress Pro 10/100 EEPROM contents:
  Station address 00:D0:B7:00:BE:00.
  Board assembly 00-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
Index #2: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xee80.
EEPROM contents, size 64x16:
00: d000 00b7 01be 0c03 0003 0201 4701 
  0x08:   40a2 3000 8086   
  ...
  0x38:        a215
 The EEPROM checksum is correct.
Intel EtherExpress Pro 10/100 EEPROM contents:
  Station address 00:D0:B7:00:BE:01.
  Board assembly 00-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
eepro100-diag.c:v2.02 7/19/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xef00.
 MII PHY #1 transceiver registers:
  3000 782d 02a8 0154 05e1 41e1 0003 
         
  0203  0001   0001  0001
  0004       .
Index #2: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at 0xee80.
 MII PHY #1 transceiver registers:
  3000 7809 02a8 0154 05e1   
         
    0001     
         .
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: unresloved symbols in 2.4.1

[Bill Nottingham]

Eugene Danilchenko ([EMAIL PROTECTED]) said: 
> cd /lib/modules/2.4.1; \
> mkdir -p pcmcia; \
> find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.1; fi
> depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/fs/binfmt_elf.o
> depmod: get_pte_slow
> depmod: __handle_bad_pmd 
> 
> 
> System: RedHat 6.2 
> on system installed:
> modutils-2.4.2-1
> 
> What does it mean.

It means that compiling ELF binary support as a module doesn't work right.

> and what have i to do to avoid it?

Compile it in (CONFIG_BINFMT_ELF=y). If you're using Red Hat Linux 6.2,
compiling it as a module is an incredibly bad idea anyway.

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

unresloved symbols in 2.4.1

[Eugene Danilchenko]

Hello, 
i have problem. When i try to install compiled modules (make modules_install) with 
kernel 2.4.2, i get this message (tail -7): 

cd /lib/modules/2.4.1; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.4.1; fi
depmod: *** Unresolved symbols in /lib/modules/2.4.1/kernel/fs/binfmt_elf.o
depmod: get_pte_slow
depmod: __handle_bad_pmd   
   

System: RedHat 6.2 
on system installed:
modutils-2.4.2-1

What does it mean. and what have i to do to avoid it?
Eugene
 .config

Newbie ask for help: cramfs port to isofs

[zhaoway]

I've nearly no prior experience with kernel hacking (nor C if you have
to ask, haha), sorry in advance for the newbiesh looking. ;-)

See attach for a rough try to port cramfs to isofs which gave me lots
of oops and reboots and fscks this week. Please if you have some spare
time to give it a look with your experienced eyes to help me out of
this helpless state. Thanks alot!

I plan to automatically de-compressing ``*.cramed'' files made with
cramit.c (which is a simplified version of mkcramfs.c also attached
below) from within isofs.o. This indeed isn't a very clean idea I
agree. If you have better design, please let me know.

My problem is that when I after mount ``$ file somefile.not.cram.ed''
the kernel hangs. And my de-compression code surely has some thing
severely broken too. Please help! ;-)



--- vanilla-2.4.1/fs/isofs/dir.cSat Dec 30 01:13:45 2000
+++ cisofs/fs/isofs/dir.c   Mon Feb 19 18:40:16 2001
@@ -5,8 +5,11 @@
  *
  *  (C) 1991  Linus Torvalds - minix filesystem
  *
- *  Steve Beynon  : Missing last directory entries fixed
+ *  Steve Beynon  : Missing last directory entries fixed
  *  ([EMAIL PROTECTED])  : 21st June 1996
+ *
+ *  zhaoway   : Transparent *.cramed uncompressing
+ *  ([EMAIL PROTECTED])   : 15th February 2001
  * 
  *  isofs directory handling functions
  */
@@ -108,8 +111,7 @@
unsigned int block, offset;
int inode_number = 0;   /* Quiet GCC */
struct buffer_head *bh = NULL;
-   int len;
-   int map;
+   int len = 0;
int high_sierra;
int first_de = 1;
char *p = NULL; /* Quiet GCC */
@@ -181,8 +183,6 @@
continue;
}
 
-   len = 0;
-
/* Handle the case of the '..' directory */
if (de->name_len[0] == 1 && de->name[0] == 1) {
inode_number = filp->f_dentry->d_parent->d_inode->i_ino;
@@ -202,32 +202,37 @@
}
}
 
-   map = 1;
-   if (inode->i_sb->u.isofs_sb.s_rock) {
-   len = get_rock_ridge_filename(de, tmpname, inode);
-   if (len != 0) { /* may be -1 */
-   p = tmpname;
-   map = 0;
+   if (inode->i_sb->u.isofs_sb.s_rock &&
+   (len = get_rock_ridge_filename(de, tmpname, inode))) { /* may be 
+-1 */
+#ifdef CONFIG_CISOFS
+   /* Drop trailing '.cramed' */
+   if (len > 7 && (! strncmp(&tmpname[len - 7], ".cramed", 7))) {
+   len -= 7;
+   tmpname[len] = '\0';
}
-   }
-   if (map) {
-#ifdef CONFIG_JOLIET
-   if (inode->i_sb->u.isofs_sb.s_joliet_level) {
-   len = get_joliet_filename(de, tmpname, inode);
-   p = tmpname;
-   } else
 #endif
-   if (inode->i_sb->u.isofs_sb.s_mapping == 'a') {
-   len = get_acorn_filename(de, tmpname, inode);
-   p = tmpname;
-   } else
-   if (inode->i_sb->u.isofs_sb.s_mapping == 'n') {
-   len = isofs_name_translate(de, tmpname, inode);
-   p = tmpname;
-   } else {
-   p = de->name;
-   len = de->name_len[0];
+   p = tmpname;
+#ifdef CONFIG_JOLIET
+   } else if (inode->i_sb->u.isofs_sb.s_joliet_level) {
+   len = get_joliet_filename(de, tmpname, inode);
+# ifdef CONFIG_CISOFS
+   /* Drop trailing '.cramed' */
+   if (len > 7 && (! strncmp(&tmpname[len - 7], ".cramed", 7))) {
+   len -= 7;
+   tmpname[len] = '\0';
}
+# endif
+   p = tmpname;
+#endif
+   } else if (inode->i_sb->u.isofs_sb.s_mapping == 'a') {
+   len = get_acorn_filename(de, tmpname, inode);
+   p = tmpname;
+   } else if (inode->i_sb->u.isofs_sb.s_mapping == 'n') {
+   len = isofs_name_translate(de, tmpname, inode);
+   p = tmpname;
+   } else {
+   p = de->name;
+   len = de->name_len[0];
}
if (len > 0) {
if (filldir(dirent, p, len, filp->f_pos, inode_number, 
DT_UNKNOWN) < 0)


--- vanilla-2.4.1/fs/isofs/namei.c  Sat Dec 30 01:13:46 2000
+++ cisofs/fs/isofs/namei.c Mon Feb 19 18:42:05 2001
@@ -1,9 +1,9 @@
 /*
  *  linux/fs/isofs/namei.c
 

FC support for SCSI on Linux

[Sujit Kumar]

Hi  
How does SCSI subsystem interact with FC layers in Linux ?
If anyone could give a brief on this or some links or docs on this.
Ciao
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [IDE] meaningless #ifndef?

[Tom Leete]

Bill Wendling wrote:
> 
> The use of the ternary operator is superfluous, though...and makes the
> code look ugly IMNSHO :).
> 

You are correct. Please ignore my thinko.

Tom

-- 
The Daemons lurk and are dumb. -- Emerson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] new setprocuid syscall

[Peter Samuelson]

[BERECZ Szabolcs]
> Here is a new syscall. With this you can change the owner of a running
> procces.

> +   if (current->euid)
> +   return -EPERM;

Use capable().

> +   p = find_task_by_pid(pid);
> +   p->fsuid = p->euid = p->suid = p->uid = uid;

Race -- you need to make sure the task_struct doesn't disappear out
from under you.

Anyway, why not use the interface 'chown uid /proc/pid'?  No new
syscall, no arch-dependent part, no user-space tool, etc.

The following is untested and almost certainly broken (I'm a lousy
kernel hacker), but should be at least somewhat close

Peter


--- fs/proc/base.c.orig Thu Nov 16 22:11:22 2000
+++ fs/proc/base.c  Mon Feb 19 22:51:59 2001
@@ -873,6 +873,27 @@
return ERR_PTR(error);
 }
 
+static int proc_base_chown (struct dentry *dentry, struct iattr *attr)
+{
+   struct task_struct *task;
+
+   if (!capable (CAP_SETUID))
+   return -EPERM;
+
+   if (!(attr->ia_valid & ATTR_UID))
+   return -EINVAL;
+
+   read_lock (&tasklist_lock);
+   task = dentry->d_inode->u.proc_i.task;
+   if (task)
+   task->fsuid = task->euid = task->suid = task->uid = attr->ia_uid;
+   read_unlock (&tasklist_lock);
+   if (!task)
+   return -ENOENT;
+
+   return 0;
+}
+
 static struct file_operations proc_base_operations = {
read:   generic_read_dir,
readdir:proc_base_readdir,
@@ -880,6 +901,7 @@
 
 static struct inode_operations proc_base_inode_operations = {
lookup: proc_base_lookup,
+   setattr:proc_base_chown,
 };
 
 /*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] trylock for rw_semaphores: 2.4.1

[Ben LaHaise]

On Mon, 19 Feb 2001, Brian J. Watson wrote:

> Here is an x86 implementation of down_read_trylock() and down_write_trylock()
> for read/write semaphores. As with down_trylock() for exclusive semaphores, they
> don't block if they fail to get the lock. They just return 1, as opposed to 0 in
> the success case.

How about the following instead?  Warning: compiled, not tested.

-ben

diff -ur v2.4.2-pre3/include/asm-i386/semaphore.h trylock/include/asm-i386/semaphore.h
--- v2.4.2-pre3/include/asm-i386/semaphore.hMon Feb 12 16:04:59 2001
+++ trylock/include/asm-i386/semaphore.hMon Feb 19 23:50:03 2001
@@ -382,5 +382,32 @@
__up_write(sem);
 }

+/* returns 1 if it successfully obtained the semaphore for write */
+static inline int down_write_trylock(struct rw_semaphore *sem)
+{
+   int old = RW_LOCK_BIAS, new = 0;
+   int res;
+
+   res = cmpxchg(&sem->count.counter, old, new);
+   return (res == RW_LOCK_BIAS);
+}
+
+/* returns 1 if it successfully obtained the semaphore for read */
+static inline int down_read_trylock(struct rw_semaphore *sem)
+{
+   int ret = 1;
+   asm volatile(
+   LOCK "subl $1,%0
+   js 2f
+   1:
+   .section .text.lock,\"ax\"
+   2:" LOCK "inc %0
+   subl %1,%1
+   jmp 1b
+   .previous"
+   :"=m" (*(volatile int *)sem), "=r" (ret) : "1" (ret) : "memory");
+   return ret;
+}
+
 #endif
 #endif

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

Re: [IDE] meaningless #ifndef?

[Tom Leete]

Bill Wendling wrote:
> 
> Also sprach Andre Hedrick:
> } On Mon, 19 Feb 2001, Pozsar Balazs wrote:
> }
> } > from drivers/ide/ide-features.c:
> } >
> } > /*
> } >  *  All hosts that use the 80c ribbon mus use!
> } >  */
> } > byte eighty_ninty_three (ide_drive_t *drive)
> } > {
> } > return ((byte) ((HWIF(drive)->udma_four) &&
> } > #ifndef CONFIG_IDEDMA_IVB
> } > (drive->id->hw_config & 0x4000) &&
> } > #endif /* CONFIG_IDEDMA_IVB */
> } > (drive->id->hw_config & 0x6000)) ? 1 : 0);
> } > }
> } >
> } > If i see well, then this is always same whether CONFIG_IDEDMA_IVB is
> } > defined or not.
> } > What's the clue?
> }
> [snip...]
> 
> The use of the ternary operator is superfluous, though...and makes the
> code look ugly IMNSHO :).
> 

Check return type. 0 == ((byte) 0x6000).

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

Re: PROBLEM: pci bridge fails to wake up from suspend/resume( Inspiron 8000 )

[Doug Siebert]

Morten,

I'm not subscribed to linux-kernel, but I've been following the list archive
somewhat for the past month (watching 2.4 development so I can figure out
when it is safe to make the jump without too much hassle)

I just bought a Dell Inspiron 4000 laptop a month ago, and have the same
problem with suspend/resume, with both devices on the PCI bridge (both the
eepro100 ethernet as well as the LT winmodem) Same symptoms, both work fine
until suspend, after resume neither work at all.  I tried your fix, and it
worked for me.  I did the same thing you did, running 'lspci -vx' to see
the PCI registers before and after, and then use 'setpci' to fix them.
Since the i4000 uses a 440BX mobile chipset, it isn't exactly the same
commands, but I got it to work (I had to ifconfig eth0 down then 'ifup
eth0' to make it work)  Its a pretty general fix, as I'm running Redhat 6.2
with kernel 2.2.16.  Yeah, kind of old, but I hope to be running 2.4 pretty
soon!  (BTW, as you probably already know, your fix works fine for
re-enabling the winmodem after resume as well)

I'm cc:ing linux-kernel also, in case anyone working this problem can benefit
from the additional data point.  If anyone working this needs further info
from me (lspci results or whatever) feel free to email me at this address.

-- 
Douglas Siebert
[EMAIL PROTECTED]

A computer without Microsoft software is like chocolate cake without ketchup.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux OS boilerplate

[H. Peter Anvin]

Paul Gortmaker wrote:
> 
> Scott Long wrote:
> >
> > I've been poring over the x86 boot code for a while now and I've been
> > considering writing a FAQ on the boot process (mostly for my own use,
> 
> [...]
> 
> > Does there exist an outline (detailed or not) of the boot process from
> > the point of BIOS bootsector load to when the kernel proper begins
> 
> IIRC, there is some useful info contained within loadlin.  Also, I
> found a doc by hpa called "THE LINUX/I386 BOOT PROTOCOL" in my local
> archive of cruft -  I just assumed it was in Documentation/ but
> apparently it never made it there (yet).
> 

It's in there (Documentation/i386/boot.txt).

-hpa

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

about acpi problems

[michaelc]

Hi,
I found that acpi driver has some bugs, I compiled the 2.4.2-pre4
  kernel with the acpi support option and SMP enabled, it caused hang at the
  boot time, but when I disabled the SMP option, it 's OK , so I look
  into the acpi driver source code, and I found the acpi idle function
  don't support the SMP, is that cause the kernel hang at boot time.
  

-- 
Best regards,
 michaelc  mailto:[EMAIL PROTECTED]


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

[WISHLIST] Addition of suspend patch into 2.5?

[Shawn Starr]

Any idea if suspend/hybernation will be in future kernels?

Shawn.


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

Re: ethernet driver probs (tulip, de4x5, 3c509)

[Manfred Bartz]

Jeff Garzik <[EMAIL PROTECTED]> writes:

> On 20 Feb 2001, Manfred Bartz wrote:
> > I have 3 NICs (2*DEC, 1*3c509) in my gateway (P75, 40M RAM).
> > 
> > tulip.o in 2.4.1 insists on selecting 10baseT, no command
> > line option can convince it otherwise.  tulip.o in 2.2.16 auto
> > detected media and worked fine.
> 
> A little info on your cards would be helpful.  With well over 100
> different types of Tulip cards, I can't just read your mind :)

The problem seems to be generic.  It is always related to media
selection and occurs with at least 3 different NICs which are based 
on the 21040 and 21041 chips.

> lspci, tulip-diag, and dmesg output would all be helpful.

I have not got lspci but since the driver reports the correct IRQ and
IO-ports that should be no issue.  (I'll install lspci if necessary).

Outputs of dmesg, tulip-diag, and some other info is now at:


> > de4x5.o in 2.4.1 needs to be told the media, then works fine.
> > de4x5.o in 2.2.16 auto detected media and worked fine.
> 
> de4x5 is going away, anyway.

Pity.  It works and I really like the manual options interface...   :/

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

Re: [PATCH] exclusive wakeup for lock_buffer

[John Heil]

On Tue, 20 Feb 2001, Alan Cox wrote:

> Date: Tue, 20 Feb 2001 03:12:15 + (GMT)
> From: Alan Cox <[EMAIL PROTECTED]>
> To: Marcelo Tosatti <[EMAIL PROTECTED]>
> Cc: Linus Torvalds <[EMAIL PROTECTED]>,
> lkml <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] exclusive wakeup for lock_buffer
> 
> > --- linux/include/linux/locks.h.origMon Feb 19 23:16:50 2001
> > +++ linux/include/linux/locks.h Mon Feb 19 23:21:48 2001
> > @@ -13,6 +13,7 @@
> >   * lock buffers.
> >   */
> >  extern void __wait_on_buffer(struct buffer_head *);
> > +extern void __lock_buffer(struct buffer_head *);
> 
> So are we starting 2.5 now ?

If per chance it's so, what's actually in plan for 2.5 so far?


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

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

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

Re: [PATCH] exclusive wakeup for lock_buffer

[Alan Cox]

> --- linux/include/linux/locks.h.orig  Mon Feb 19 23:16:50 2001
> +++ linux/include/linux/locks.h   Mon Feb 19 23:21:48 2001
> @@ -13,6 +13,7 @@
>   * lock buffers.
>   */
>  extern void __wait_on_buffer(struct buffer_head *);
> +extern void __lock_buffer(struct buffer_head *);

So are we starting 2.5 now ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] trylock for rw_semaphores: 2.4.1

[Brian J. Watson]

Here is an x86 implementation of down_read_trylock() and down_write_trylock()
for read/write semaphores. As with down_trylock() for exclusive semaphores, they
don't block if they fail to get the lock. They just return 1, as opposed to 0 in
the success case.

The algorithm should be robust. It should be able to handle any race and clean
up properly if a task fails to get the lock, but I would appreciate comments if
anyone sees a flaw.

Admittedly, the code path for successfully grabbing the lock is longer than it
should be. I should have done the nested if tests in down_*_trylock() with js
and jc assembly instructions, rather than using sets and setc to copy the flags
to C variables. My excuse is that I'm unfamiliar with assembly programming, so I
took the path of least resistance.

I've only tested the code to make sure it compiles and works properly when the
lock is already held, but there are no waiters. This is the tricky case where it
has to weasel out of holding the bias. The success case and non-bias failure
case still need to be tested. Stress testing might also be a good idea. I don't
have the time to do this right now, but I thought I'd make the patch available
in case anyone else is interested the functionality.


Brian Watson
Compaq Computer
[EMAIL PROTECTED]

diff -Nar -u4 2.4.1/arch/i386/kernel/semaphore.c 
2.4.1-trylock/arch/i386/kernel/semaphore.c
--- 2.4.1/arch/i386/kernel/semaphore.c  Sat Nov 18 17:31:25 2000
+++ 2.4.1-trylock/arch/i386/kernel/semaphore.c  Fri Feb 16 18:13:16 2001
@@ -382,8 +382,41 @@
 
return sem;
 }
 
+/* We have the bias, but we can't sleep. We have to get rid of it
+ * as gracefully as we can.
+ *
+ * This routine does have the unfortunate side-effect that we could 
+ * spin for awhile if there's a lot of contention for this lock. If 
+ * that's the case, however, then it's less likely that we would hold 
+ * the bias and be running this code.
+ */
+void __up_biased(int val, struct rw_semaphore *sem)
+{
+   int count, newcount;
+repeat:
+   /* Does it look like we're racing with another contender? */
+   count = atomic_read(&sem->count);
+   newcount = count + val;
+   if (newcount < 0)
+   /* Yes: Try again. */
+   goto repeat;
+   else
+   /* No: Bump the count while no one's looking. Did we race? */
+   if (cmpxchg((volatile int *)&sem->count, count, newcount) 
+   != count)
+   /* Yes: Try again. */
+   goto repeat;
+   else
+   /* No: Let the real waiters duke it out for the bias.
+* FIXME: This has the same potential stampede problem 
+* as down_write_failed_biased().
+*/
+   if (atomic_read(&sem->count) >= 0)
+   wake_up(&sem->wait);
+}
+
 asm(
 "
 .align 4
 .globl __rwsem_wake
diff -Nar -u4 2.4.1/include/asm-i386/atomic.h 2.4.1-trylock/include/asm-i386/atomic.h
--- 2.4.1/include/asm-i386/atomic.h Thu Jan  4 14:50:46 2001
+++ 2.4.1-trylock/include/asm-i386/atomic.h Fri Feb 16 18:13:16 2001
@@ -52,8 +52,21 @@
:"ir" (i), "m" (v->counter) : "memory");
return c;
 }
 
+#define ATOMIC_SUB_SIGN_BIT0x1
+#define ATOMIC_SUB_CARRY_BIT   0x2
+static __inline__ int atomic_sub_sign_and_carry(int i, atomic_t *v)
+{
+   unsigned char s, c;
+
+   __asm__ __volatile__(
+   LOCK "subl %3,%0; sets %1; setc %2"
+   :"=m" (v->counter), "=qm" (s), "=qm" (c)
+   :"ir" (i), "m" (v->counter) : "memory");
+   return s | c<<1;
+}
+
 static __inline__ void atomic_inc(atomic_t *v)
 {
__asm__ __volatile__(
LOCK "incl %0"
diff -Nar -u4 2.4.1/include/asm-i386/semaphore.h 
2.4.1-trylock/include/asm-i386/semaphore.h
--- 2.4.1/include/asm-i386/semaphore.h  Thu Jan  4 14:50:46 2001
+++ 2.4.1-trylock/include/asm-i386/semaphore.h  Fri Feb 16 18:13:16 2001
@@ -381,6 +381,76 @@
 #endif
__up_write(sem);
 }
 
+extern void __up_biased(int val, struct rw_semaphore *sem);
+
+static inline int down_read_trylock(struct rw_semaphore *sem)
+{
+   int retval;
+#if WAITQUEUE_DEBUG
+   if (sem->__magic != (long)&sem->__magic)
+   BUG();
+#endif
+   retval = atomic_sub_sign_and_carry(1, &sem->count);
+   /* Did we get the lock? */
+   if (retval & ATOMIC_SUB_SIGN_BIT) {
+   /* No: Does someone else have the bias? */
+   if (retval & ATOMIC_SUB_CARRY_BIT)
+   /* No: Guess we have to do this the hard way. */
+   __up_biased(1, sem);
+   else
+   /* Yes: Fix the count and pretend nothing happened. */
+   __up_read(sem);
+   return 1;
+   }
+   else {
+   /* Yes: We got the lock!! */
+#if WAITQUEUE_DEBUG
+   if (sem->writ

Re: __lock_page calls run_task_queue(&tq_disk) unecessarily?

[Marcelo Tosatti]

Btw ___wait_on_page() does something similar.

Here goes the patch for both __lock_page() and ___wait_on_page().


--- linux/mm/filemap.c.orig Mon Feb 19 23:51:02 2001
+++ linux/mm/filemap.c  Mon Feb 19 23:51:33 2001
@@ -611,11 +611,11 @@
 
add_wait_queue(&page->wait, &wait);
do {
-   sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (!PageLocked(page))
break;
-   run_task_queue(&tq_disk);
+
+   sync_page(page);
schedule();
} while (PageLocked(page));
tsk->state = TASK_RUNNING;
@@ -633,10 +633,9 @@
 
add_wait_queue_exclusive(&page->wait, &wait);
for (;;) {
-   sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (PageLocked(page)) {
-   run_task_queue(&tq_disk);
+   sync_page(page);
schedule();
continue;
}


On Mon, 19 Feb 2001, Marcelo Tosatti wrote:

> 
> Hi Linus,
> 
> Take a look at __lock_page:
> 
> static void __lock_page(struct page *page)
> {
> struct task_struct *tsk = current;
> DECLARE_WAITQUEUE(wait, tsk);
> 
> add_wait_queue_exclusive(&page->wait, &wait);
> for (;;) {
> sync_page(page);
> set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> if (PageLocked(page)) {
> run_task_queue(&tq_disk);
> schedule();
> continue;
> }
> if (!TryLockPage(page))
> break;
> }
> tsk->state = TASK_RUNNING;
> remove_wait_queue(&page->wait, &wait);
> }
> 
> 
> Af a process sleeps in __lock_page, sync_page() will be called even if the
> page is already unlocked. (block_sync_page(), the sync_page routine for
> generic block based filesystem calls run_task_queue(&tq_disk)).
> 
> I don't see any problem if we remove the run_task_queue(&tq_disk) and put
> sync_page(page) there instead, removing the other sync_page(page) at the
> beginning of the loop.
> 
> Comments?
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with reiserfs + nfs using 2.4.2-pre4

[Roman Zippel]

Hi,

On Tue, 20 Feb 2001, Neil Brown wrote:

> 2/ lookup("..").

A small question:
Why exactly is this needed?

bye, Roman

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

Re: finding Tekram SCSI dc395U linux patch driver:

[Tim Wright]

I asked Kurt why it was not submitted to the mainstream kernel. He said that
some people are still experiencing problems with the card/driver and he doesn't
feel it's stable enough to go in. I'm personally using it with no issues, but
I'm only driving a CD-RW - not exactly stressing things.

It sounds like the people having issues need to debug the problems, or maybe
it could go in under CONFIG_EXPERIMENTAL ?

Tim

On Thu, Feb 15, 2001 at 10:46:22PM +0100, Juergen Schoew wrote:
> Hi,
> On 15-Feb-01 Thomas Lau wrote:
> > hey, I found this driver on mandrake kernel sources, it's ac3, but I
> > need ac14 code, also, why still not port this driver into kernel?
> > the patch file already released 1 years ago
> 
> Have you checked http://www.garloff.de/kurt/linux/dc395/index.html
> there ist a driver Version 1.32 (2000-12-02).
> 
> Regards 
> 
> Juergen Schoew
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] exclusive wakeup for lock_buffer

[Marcelo Tosatti]

On Mon, 19 Feb 2001, Linus Torvalds wrote:

> 
> 
> On Mon, 19 Feb 2001, Marcelo Tosatti wrote:
> > 
> > The following patch makes lock_buffer() use the exclusive wakeup scheme
> > added in 2.3.
> 
> Ugh, This is horrible.
> 
> You should NOT have one function that does two completely different things
> depending on a flag. That way lies madness and bad coding habits.
> 
> Just do two different functions - make one be "__wait_on_buffer()", and
> the other be "__lock_buffer()". See how the page functions work.
> 
>   Linus

Ok. 

--- linux/include/linux/locks.h.origMon Feb 19 23:16:50 2001
+++ linux/include/linux/locks.h Mon Feb 19 23:21:48 2001
@@ -13,6 +13,7 @@
  * lock buffers.
  */
 extern void __wait_on_buffer(struct buffer_head *);
+extern void __lock_buffer(struct buffer_head *);
 
 extern inline void wait_on_buffer(struct buffer_head * bh)
 {
@@ -22,8 +23,8 @@
 
 extern inline void lock_buffer(struct buffer_head * bh)
 {
-   while (test_and_set_bit(BH_Lock, &bh->b_state))
-   __wait_on_buffer(bh);
+   if (test_and_set_bit(BH_Lock, &bh->b_state))
+   __lock_on_buffer(bh);
 }
 
 extern inline void unlock_buffer(struct buffer_head *bh)
--- linux/fs/buffer.c.orig  Mon Feb 19 23:09:31 2001
+++ linux/fs/buffer.c   Mon Feb 19 23:31:25 2001
@@ -161,6 +161,30 @@
atomic_dec(&bh->b_count);
 }
 
+void __lock_on_buffer(struct buffer_head * bh)
+{
+   struct task_struct *tsk = current;
+   DECLARE_WAITQUEUE(wait, tsk);
+
+   atomic_inc(&bh->b_count);
+   add_wait_queue_exclusive(&bh->b_wait, &wait);
+   for(;;) { 
+   set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+   if (test_bit(BH_Lock, &bh->b_state)) {
+   run_task_queue(&tq_disk);
+   schedule();
+   continue;
+   }
+
+   if (!test_and_set_bit(BH_Lock, &bh->b_state))
+   break;
+   } 
+   tsk->state = TASK_RUNNING;
+   remove_wait_queue(&bh->b_wait, &wait);
+   atomic_dec(&bh->b_count);
+}
+
+
 /* Call sync_buffers with wait!=0 to ensure that the call does not
  * return until all buffer writes have completed.  Sync() may return
  * before the writes have finished; fsync() may not.

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

Re: problems with reiserfs + nfs using 2.4.2-pre4

[dek_ml]

Alan Cox writes:
>>  This may seem like a lot, but several of these are already
>>  requirements which most filesystems don't meet, and other are there
>>  to tidy-up interfaces and make locking more straight forward.
>
>As a 2.5 thing it sounds like a very sensible path. It will also provide
>some of the operations groundwork needed for file systems that can only use
>NFS4 temporary handles
>

OK so I think what I can take from this is: for kernel 2.4 in the foreseeable
future, reiserfs over NFS won't work without a special patch.  And, filesystems
other than ext2 in general might not support NFS.  This all has to do with
internal design decisions, results of people coding against those decisions,
possibly abusing the decisions to acheive their own goals, etc, etc, all
of which lead to problems when the underlying design decisions changed and broke
code which depended on the old decisions.  

For the foreseeable future I am going to stick with ext2 for my NFS-exported
directories.  I think these problems need to be carefully stated in the Configure.help
for each filesystem which does not support NFS ... Configure.help is often the
most authoritative and up-to-date technical description of a particular kernel's
capabilities.

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

Re: [PATCH] exclusive wakeup for lock_buffer

[Linus Torvalds]

On Mon, 19 Feb 2001, Marcelo Tosatti wrote:
> 
> The following patch makes lock_buffer() use the exclusive wakeup scheme
> added in 2.3.

Ugh, This is horrible.

You should NOT have one function that does two completely different things
depending on a flag. That way lies madness and bad coding habits.

Just do two different functions - make one be "__wait_on_buffer()", and
the other be "__lock_buffer()". See how the page functions work.

Linus

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

[PATCH] exclusive wakeup for lock_buffer

[Marcelo Tosatti]

Hi, 

The following patch makes lock_buffer() use the exclusive wakeup scheme
added in 2.3.

Against 2.4.2pre4.


--- linux/fs/buffer.c.orig  Mon Feb 19 23:13:08 2001
+++ linux/fs/buffer.c   Mon Feb 19 23:16:26 2001
@@ -142,13 +142,18 @@
  * if 'b_wait' is set before calling this, so that the queues aren't set
  * up unnecessarily.
  */
-void __wait_on_buffer(struct buffer_head * bh)
+void __wait_on_buffer(struct buffer_head * bh, int exclusive)
 {
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
 
atomic_inc(&bh->b_count);
-   add_wait_queue(&bh->b_wait, &wait);
+
+   if (exclusive)
+   add_wait_queue_exclusive(&bh->b_wait, &wait);
+   else
+   add_wait_queue(&bh->b_wait, &wait);
+
do {
run_task_queue(&tq_disk);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
@@ -2332,7 +2337,7 @@
tmp = tmp->b_this_page;
if (buffer_locked(p)) {
if (wait > 1)
-   __wait_on_buffer(p);
+   __wait_on_buffer(p, 0);
} else if (buffer_dirty(p))
ll_rw_block(WRITE, 1, &p);
} while (tmp != bh);
--- linux/include/linux/locks.h.origMon Feb 19 23:21:10 2001
+++ linux/include/linux/locks.h Mon Feb 19 23:17:42 2001
@@ -12,18 +12,18 @@
  * Buffer cache locking - note that interrupts may only unlock, not
  * lock buffers.
  */
-extern void __wait_on_buffer(struct buffer_head *);
+extern void __wait_on_buffer(struct buffer_head *, int);
 
 extern inline void wait_on_buffer(struct buffer_head * bh)
 {
if (test_bit(BH_Lock, &bh->b_state))
-   __wait_on_buffer(bh);
+   __wait_on_buffer(bh, 0);
 }
 
 extern inline void lock_buffer(struct buffer_head * bh)
 {
while (test_and_set_bit(BH_Lock, &bh->b_state))
-   __wait_on_buffer(bh);
+   __wait_on_buffer(bh, 1);
 }
 
 extern inline void unlock_buffer(struct buffer_head *bh)


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

Re: problems with reiserfs + nfs using 2.4.2-pre4

[Neil Brown]

On Tuesday February 20, [EMAIL PROTECTED] wrote:
> >  This may seem like a lot, but several of these are already
> >  requirements which most filesystems don't meet, and other are there
> >  to tidy-up interfaces and make locking more straight forward.
> 
> As a 2.5 thing it sounds like a very sensible path. It will also provide
> some of the operations groundwork needed for file systems that can only use
> NFS4 temporary handles

I had wanted to get it in before 2.4, but didn't quite make it.

I guess that means that, from your perspective, nfs exporting of
reiserfs remains an extra-kernel patch at least until 2.5 starts up
and the code has been tested extensively and it gets backported to
2.4, or maybe even until 2.6/3.0.  Such is life.

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

Re: problems with reiserfs + nfs using 2.4.2-pre4

[Neil Brown]

On Monday February 19, [EMAIL PROTECTED] wrote:
> 
> 
> On Tuesday, February 20, 2001 11:40:24 AM +1100 Neil Brown
> <[EMAIL PROTECTED]> wrote:
> > 
> >   When reiserfs came along, it abused this, and re-interpreted the
> >   opaque datum to contain information for recalling (locating) an
> >   inode - if read_inode2 was defined.  I think this is wrong.
> >
> 
> I suggested to Al Viro a while ago to break iget up into two calls, and
> then got sucked into something else and didn't follow up.  Independently,
> he came up with the below message during a thread on fs-devel about
> read_inode.  I think it is very similar to what you've described, and it
> should work.  I'm willing to help integrate/code once things settle down
> for 2.4.

I must have missed that thread...
Yes, what Al Viro suggests is exactly the same idea as mine, except
that I suggest leaving iget as it is and getting the filesystem to do
a bit of locking.

> 
> His last paragraph is also important, I'd rather see this as a new
> call...BTW, I believe XFS and GFS actually have 64 bit inode numbers, while
> reiserfs has a unique 32 bit inode number (objectid) and a unique 32 bit
> packing locality that are both required to find the object.

I think the particular need for a new call is to handle long inode
identifiers better.  The current iget4 is a bit ugly.
If/when a new iget is done to handle long identifiers elegantly, it
would probably be good to include the I_NEW stuff as well, but for now
(2.4) both long identifiers and delayed fill-in can be done without
changing iget.

NeilBrown

(what's happened to Al Viro anyway, he has been awfully quite lately?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

net packet queue scheduler, packet_type and proto handlers

[Krzysztof Halasa]

Hi,

What do you think about the following change?
We currently have the following structure used for registering protocol
handlers as well as bridges, wiretaps etc. (include/linux/netdevice.h):

struct packet_type 
{
unsigned short type; /* This is really htons(ether_type). */
struct net_device  *dev; /* NULL is wildcarded here   */
int(*func) (struct sk_buff *, struct net_device *,
struct packet_type *);
void   *data;/* Private to the packet type */
struct packet_type *next;
};

The func() is the protocol handler. It's required to free an skb or
to pass it elsewhere. Its return value is "int", but it's in fact unused,
and the handlers return values at random.


OTOH we have stacked protocol handlers which effectively strip headers
from an skb, retrieve protocol# and pass it to the next protocol handler
- either using netif_rx (which cause problems with a packet being sent
to taps twice, and other problems) or doing things like this
(net/ax25/ax25_in.c):

switch (skb->data[1]) {
#ifdef CONFIG_INET
case AX25_P_IP:
skb_pull(skb,2);/* drop PID/CTRL */
skb->h.raw= skb->data;
skb->nh.raw   = skb->data;
skb->dev  = dev;
skb->pkt_type = PACKET_HOST;
skb->protocol = htons(ETH_P_IP);
ip_rcv(skb, dev, ptype);
break;

case AX25_P_ARP:
skb_pull(skb,2);
skb->h.raw= skb->data;
skb->nh.raw   = skb->data;
skb->dev  = dev;
skb->pkt_type = PACKET_HOST;
skb->protocol = htons(ETH_P_ARP);
arp_rcv(skb, dev, ptype);
...

As the number of protocols grow and some of them can be modular it
doesn't seem wise to hardcode every protocol handler name in all such
stacked handlers, especially when we have the same info in ptype_base[]
table (net/core/dev.c).


What I think would be better is we should make the handler (func())
return a meaningful value: 0 if the skb has been freed/accepted and
non-0 if the handler has stripped a header from it and it should be

would read:

switch (skb->data[1]) {
#ifdef CONFIG_INET
case AX25_P_IP:
skb_pull(skb,2);/* drop PID/CTRL */
skb->protocol = htons(ETH_P_IP);
break;

case AX25_P_ARP:
skb_pull(skb,2);
skb->protocol = htons(ETH_P_ARP);
break;

...
}

skb->h.raw= skb->data;
skb->nh.raw   = skb->data;
skb->dev  = dev;
skb->pkt_type = PACKET_HOST;
return 1;   /* skb changed, returned to upper layer for
   re-inspection */


Of course, taps and bridges wouldn't be allowed to ask for re-inspection :-)


What do you think about this change? Does anything depend on the current
behavior?
-- 
Krzysztof Halasa
Network Administrator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: problems with reiserfs + nfs using 2.4.2-pre4

[Alan Cox]

>  This may seem like a lot, but several of these are already
>  requirements which most filesystems don't meet, and other are there
>  to tidy-up interfaces and make locking more straight forward.

As a 2.5 thing it sounds like a very sensible path. It will also provide
some of the operations groundwork needed for file systems that can only use
NFS4 temporary handles

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

Re: problems with reiserfs + nfs using 2.4.2-pre4

[Chris Mason]

On Tuesday, February 20, 2001 11:40:24 AM +1100 Neil Brown
<[EMAIL PROTECTED]> wrote:
> 
>   When reiserfs came along, it abused this, and re-interpreted the
>   opaque datum to contain information for recalling (locating) an
>   inode - if read_inode2 was defined.  I think this is wrong.
>

I suggested to Al Viro a while ago to break iget up into two calls, and
then got sucked into something else and didn't follow up.  Independently,
he came up with the below message during a thread on fs-devel about
read_inode.  I think it is very similar to what you've described, and it
should work.  I'm willing to help integrate/code once things settle down
for 2.4.

His last paragraph is also important, I'd rather see this as a new
call...BTW, I believe XFS and GFS actually have 64 bit inode numbers, while
reiserfs has a unique 32 bit inode number (objectid) and a unique 32 bit
packing locality that are both required to find the object.

Cut n' paste from Viro's mail, beware of newline munging:

> From: Alexander Viro <[EMAIL PROTECTED]>
> To: Steve Whitehouse <[EMAIL PROTECTED]>
> cc: [EMAIL PROTECTED]
> Subject: Re: read_inode() extra argument ?
> Date-Sent: Tuesday, December 19, 2000 06:41:42 AM -0500
>
[snip]
> Basically, read_inode() (and iget()) is _not_ a universal API. It's
> a conveniency thing for filesystems that are comfortable with it. Notice
> that quite a few filesystems do not have ->read_inode() at all.
> 
> If you need more than just an inumber to fill the inode - don't use
> iget() at all. It's just a wrong API for that kind of situations.
> 
> In all fairness, ->read_inode() should not be a method. Correct way to
> deal with that would be along the lines
> 
> --- fs/inode.cTue Dec 19 09:42:41 2000
> +++ fs/inode.c.newTue Dec 19 09:59:37 2000
> @@ -661,22 +661,10 @@
>inode->i_ino = ino;
>inode->i_flags = 0;
>atomic_set(&inode->i_count, 1);
> - inode->i_state = I_LOCK;
> + inode->i_state = I_LOCK | I_NEW;
>spin_unlock(&inode_lock);
>  
>clean_inode(inode);
> - sb->s_op->read_inode(inode);
> -
> - /*
> -  * This is special!  We do not need the spinlock
> -  * when clearing I_LOCK, because we're guaranteed
> -  * that nobody else tries to do anything about the
> -  * state of the inode when it is locked, as we
> -  * just created it (so there can be no old holders
> -  * that haven't tested I_LOCK).
> -  */
> - inode->i_state &= ~I_LOCK;
> - wake_up(&inode->i_wait);
>  
>return inode;
>}
> @@ -693,6 +681,20 @@
>wait_on_inode(inode);
>}
>return inode;
> +}
> +
> +void unlock_new_inode(struct inode *inode)
> +{
> + /*
> +  * This is special!  We do not need the spinlock
> +  * when clearing I_LOCK, because we're guaranteed
> +  * that nobody else tries to do anything about the
> +  * state of the inode when it is locked, as we
> +  * just created it (so there can be no old holders
> +  * that haven't tested I_LOCK).
> +  */
> + inode->i_state &= ~(I_LOCK|I_NEW);
> + wake_up(&inode->i_wait);
>  }
>  
>  static inline unsigned long hash(struct super_block *sb, unsigned long
>  i_ino) --- fs/ext2/namei.c   Tue Dec 19 09:59:54 2000
> +++ fs/ext2/namei.c.new   Tue Dec 19 10:01:22 2000
> @@ -175,9 +175,12 @@
>unsigned long ino = le32_to_cpu(de->inode);
>brelse (bh);
>inode = iget(dir->i_sb, ino);
> -
>if (!inode)
>return ERR_PTR(-EACCES);
> + if (inode->i_state & I_NEW) {
> + ext2_read_inode(inode);
> + unlock_new_inode(inode);
> + }
>}
>d_add(dentry, inode);
>return NULL;
> 
> (modulo obvious changes to fs.h, exporting (or inlining)
> unlock_new_inode(), etc.)
> 
> The point being: allow filesystems to use whatever means they find
> convenient for filling the inode. All we really need from icache is an
> analog of iget() that would leave new struct inode locked, recognizable
> as new and would _not_ do anything fs-specific. Quite possibly we want a
> new function for that leaving iget() as-is so that existing callers would
> stay intact - patch above just describes the general idea.




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

Re: Is this the ultimate stack-smash fix?

[Andreas Bombe]

On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
> Peter Samuelson <[EMAIL PROTECTED]> writes:
> > It also sounds like you will be
> > breaking the extremely useful C postulate that, at the ABI level at
> > least, arrays and pointers are equivalent.  I can't see *how* you plan
> > to work around that one.
> 
> Huh?  Pointers and arrays are clearly different at the ABI level.
> 
> A pointer is a word that contains an address of something.
> An array is an array.

An array is a word that contains the address of the first element.

Exercise 1:  What is the difference between the following two
declarations at the source level and at the ABI level?

a) int main(int argc, char *argv[])
b) int main(int argc, char **argv)


Exercise 2:  What would the following in hypothetical C startup code do?

char *args[10];
int count = 10;

...

exit(main(count - 1, args + 1));

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

sendfile64?

[Felix von Leitner]

Why isn't there a sendfile64?

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

__lock_page calls run_task_queue(&tq_disk) unecessarily?

[Marcelo Tosatti]

Hi Linus,

Take a look at __lock_page:

static void __lock_page(struct page *page)
{
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);

add_wait_queue_exclusive(&page->wait, &wait);
for (;;) {
sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (PageLocked(page)) {
run_task_queue(&tq_disk);
schedule();
continue;
}
if (!TryLockPage(page))
break;
}
tsk->state = TASK_RUNNING;
remove_wait_queue(&page->wait, &wait);
}


Af a process sleeps in __lock_page, sync_page() will be called even if the
page is already unlocked. (block_sync_page(), the sync_page routine for
generic block based filesystem calls run_task_queue(&tq_disk)).

I don't see any problem if we remove the run_task_queue(&tq_disk) and put
sync_page(page) there instead, removing the other sync_page(page) at the
beginning of the loop.

Comments?

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

any news on loop device patches?

[Ted Serreyn]

Have you heard anything more on the loop patches?  I'm not on the kernel
list anymore.  I need to be able to run 2.4 and use the loop devices to
mount cd images?

Ted

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

Re: problems with reiserfs + nfs using 2.4.2-pre4

[Neil Brown]

On Monday February 19, [EMAIL PROTECTED] wrote:
> > I hope to put out a patch set for testing in a day or so and possibly
> > suggest it to Alan for his -ac series.  I don't see it going into
> > 2.4.2, but 2.4.3 might be possible if Linus agrees.
> 
> Im not interested in a patch that requires NFS is hacked for each file system
> that tells me the implementation is wrong. The previous setup worked perfectly
> for everything but reiserfs, so why isnt the newer setup one allowing each fs
> to override a generic behaviour which is the current working behaviour, thereby
> meaning all the other fs's work.
> 
> FS authors shouldnt have to do extra work to support knfsd unless they are doing
> interesting and unusual things

A fair question (it was a question, wasn't it :-) and I will see if I
can provide a convincing answer.

My answer has three parts:
  1/ iget abuse
  2/ lookup("..")
  3/ requirements to support knfsd.

Part 1 also contains some comments about reiserfs for Chris Mason.

---
1/ The linux-2.4 Todo list has, in section
"10. To Do But Non Showstopper"

   - iget abuse in knfsd


  Part of the need for change to knfsd and filesystems is to fix this
  abuse.  But what is this abuse?  Well..

  iget is a (n often misunderstood I think) helper function for
  filesystems.   It helps maintain an inode cache.

  If a filesystem chooses, it may provide a read_inode super_operation
  and then call iget whenever it wants to find a particular inode.
  If iget finds the inode in the cache, it will return it.  If it
  doesn't it will create a new inode, set the i_ino field (and a few
  others) and pass this to read_inode for the filesystem to finish
  off.  iget handles any locking needed to make sure no inode gets
  created or read_inode'd twice.

  It is worth noting that read_inode does *not* have to actually read
  in the inode, though this is the typical (i.e. ext2fs) thing to do.
  nfs_read_inode, for example, just initialises a few extra fields in
  the inode.  After the call to iget completes, other parts of the nfs
  code fills in the rest of the inode from data received from the NFS
  server. 

  It is also worth noting that not all filesystems use
  iget/read_inode.  msdos/fat maintains it's own inode cache and so
  doesn't use the one provided by iget.

  A final point to note - and this is actually quite important - is
  that the value passed to iget (an inode number) needs to contain
  enough information to be able to answer "is this the right inode"
  (recognition) but does not need to be able to answer "where can I
  find this inode" (recall), though these two go together for ext2 and
  similar file systems.

  The case of nfs, already mentioned, shows this.  A filehandle is
  needed to find an inode, but a filehandle is not passed to iget.

  nfs did need an extension to iget though, and hence created iget4.
  The assumption that 4bytes is enough to recognise an inode is a bit
  dated.  NFSv3 needs at least 8bytes (because the fileid is 64bit)
  and Trond decided (quite reasonably) to use 16bytes (including the
  fsid).  Because these cannot be squeezed into a 32bit ino_t, he
  create iget4 which also had an opaque datum (arbitrary size) and an
  "actor" which would compare that datum against a given inode to see
  if there was a match.  This works fine, but is a bit awkward as the
  whole opaque datum is not available for hash calculations.  Maybe
  this can be tided up in 2.5.

  Note that this extension did not change the fact the iget has enough
  information to recognise, but not necessarily to recall an inode.

  When reiserfs came along, it abused this, and re-interpreted the
  opaque datum to contain information for recalling (locating) an
  inode - if read_inode2 was defined.  I think this is wrong.
  What reiserfs *should* do (I think) is:
   - Just pass the 32bit inode number to iget - this seems to be enough
  to recognise an inode in reiserfs.
   - have read_inode mark the inode as "incomplete" in some way.
   - In reiserfs_iget, after calling "iget", it should 
+  lock the inode,
+  check if it is incomplete or not
+  if it is incomplete, read in the inode
+  unlock the inode.

  This removes the need for read_inode2 and maintains the same
  concurrency controls.  Whether the locking can be done with
  I_LOCK/i_wait or not I am not sure.


  Anyway, back to nfsd:  nfsd currently gets an inode number out of
  the file handle and passes it to iget.  The above discussion of iget
  should show that this is the wrong thing to do.  In particular,
  knfsd needs to be able to recall (locate) an inode, and iget only
  guarantees being able to recognise one.  It happens to work
  for ext2fs, but it is an abuse of the interface and must change.

  If knfsd is not to use iget, it needs some other interface to use.
  My patch provides such an interface by defining an nfsd_operations
  str

Re: eepro100 + 2.2.18 + laptop problems

[CaT]

On Mon, Feb 19, 2001 at 04:18:40PM -0800, Ion Badulescu wrote:
> > In my experiments wait_for_cmd timeouts almost always were related to
> > DumpStats command.
> > I think, we need to investigate what time constraints are related to this
> > command.
> 
> Nothing documented...
> 
> CaT, can you apply this debugging patch and let us know what you get in the
> logs? It should allow us to pinpoint the error a bit more precisely.

patched, old removed, new installed, waiting for fubar. :)

still with 2.2.18

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

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

Re: pmap.c : Can you please try another name for it?

[Andy Isaacson]

On Mon, Feb 19, 2001 at 06:58:45PM -0500, Albert D. Cahalan wrote:
> Dieter =?iso-8859- writes:
> > /*
> >  * pmap.c: implementation of something like Solaris' /usr/proc/bin/pmap
> >  * for linux
> 
> I've been planning to implement that tool for procps. So, one way
> or another, it will be common on Linux systems. Where might I find
> the code you quoted from?

[Thanks for the CC, Dieter.]

My public domain pmap implementation has a new home at
http://web.hexapodia.org/~adi/pmap.c

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

Re: eepro100 + 2.2.18 + laptop problems

[Ion Badulescu]

On Mon, 19 Feb 2001 14:49:35 -0800, Andrey Savochkin <[EMAIL PROTECTED]> wrote:

> On Tue, Feb 20, 2001 at 09:21:06AM +1100, CaT wrote:
>> 
>> It happened again. Same deal. Once was after a reboot and this time
>> was after a resume. :/
> 
> In my experiments wait_for_cmd timeouts almost always were related to
> DumpStats command.
> I think, we need to investigate what time constraints are related to this
> command.

Nothing documented...

CaT, can you apply this debugging patch and let us know what you get in the
logs? It should allow us to pinpoint the error a bit more precisely.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
--
--- /mnt/3/linux-2.2.19pre/drivers/net/eepro100.c   Thu Feb 15 16:09:19 2001
+++ linux-2.2.18/drivers/net/eepro100.c Mon Feb 19 16:13:45 2001
@@ -368,9 +368,16 @@
 #define outl writel
 #endif
 
+static char *cmdwait_string = "wait_for_cmd_done timed out at %s:%d\n";
+#define wait_for_cmd_done(ioaddr) \
+  do { \
+if (do_wait_for_cmd_done(ioaddr)) \
+ printk(cmdwait_string, __FUNCTION__, __LINE__); \
+  } while (0)
+
 /* How to wait for the command unit to accept a command.
Typically this takes 0 ticks. */
-static inline void wait_for_cmd_done(long cmd_ioaddr)
+static inline int do_wait_for_cmd_done(long cmd_ioaddr)
 {
int wait = 2;
char cmd_reg1, cmd_reg2;
@@ -383,10 +390,10 @@
if(cmd_reg2){
printk(KERN_ALERT "eepro100: cmd_wait for(%#2.2x) timedout 
with(%#2.2x)!\n",
cmd_reg1, cmd_reg2);
-   
+   return 1;
}
}
-
+   return 0;
 }
 
 /* Offsets to the various registers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pmap.c : Can you please try another name for it?

[Jeremy Jackson]

Dieter Nützel wrote:

>  * Justification:  the formatting available in /proc//maps is less
>  * than optimal.  It's hard to figure out the size of a mapping from
>  * that information (unless you can do 8-digit hex arithmetic in your
>  * head) and it's just generally not friendly.  Hence this utility.

you may want to check sourceforge for xmlprocfs too.

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

Re: pmap.c : Can you please try another name for it?

[Albert D. Cahalan]

Dieter =?iso-8859- writes:

> Hello Rik,
> 
> there is a nice little toy called "pmap.c" around for several years, now.
> Should we consider?
> 
> /*
>  * pmap.c: implementation of something like Solaris' /usr/proc/bin/pmap
>  * for linux

I've been planning to implement that tool for procps. So, one way
or another, it will be common on Linux systems. Where might I find
the code you quoted from?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] run_task_queue(&tq_disk) only if we written data to disk

[Marcelo Tosatti]

Hi, 

This patch makes page_launder() do actual disk IO
(run_task_queue(&tq_disk)) only if IO was queued in the page freeing
loop.

If we freed enough clean pages without needing do to any disk IO, there is
no need to call run_task_queue(&tq_disk).

 
--- linux/mm/vmscan.c.orig  Mon Feb 19 20:46:23 2001
+++ linux/mm/vmscan.c   Mon Feb 19 20:47:21 2001
@@ -657,12 +657,13 @@
}
 
/*
-* We have to make sure the data is actually written to
-* the disk now, otherwise we'll never get enough clean
-* pages and the system will keep queueing dirty pages
+* If we written something to disk, we have to make sure the data
is 
+* actually written to the disk now, otherwise we'll never get
enough
+* clean pages and the system will keep queueing dirty pages
 * for flushing.
 */
-   run_task_queue(&tq_disk);
+   if (launder_loop)
+   run_task_queue(&tq_disk);
 
/*
 * Return the amount of pages we freed or made freeable.


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

pmap.c : Can you please try another name for it?

[Dieter Nützel]

Hello Rik,

there is a nice little toy called "pmap.c" around for several years, now.
Should we consider?

/*
 * pmap.c: implementation of something like Solaris' /usr/proc/bin/pmap
 * for linux
 *
 * Author: Andy Isaacson <[EMAIL PROTECTED]>
 * Fri Jun 18 1999
 *
 * Updated Mon Oct 25 1999
 *  - calculate total size of shared mappings
 *  - change output format to read "writable/private" rather than "writable"
 *
 * Justification:  the formatting available in /proc//maps is less
 * than optimal.  It's hard to figure out the size of a mapping from
 * that information (unless you can do 8-digit hex arithmetic in your
 * head) and it's just generally not friendly.  Hence this utility.
 *
 * I hereby place this work in the public domain.
 *
 * Compile with something along the lines of
 * gcc -O pmap.c -o pmap
 */

Regards,
Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

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

Re: [IDE] meaningless #ifndef?

[Andre Hedrick]

On Mon, 19 Feb 2001, Bill Wendling wrote:

> The use of the ternary operator is superfluous, though...and makes the
> code look ugly IMNSHO :).

What is ugly is that the commitee can not decide if there is going to be
host-side only, device-side only or both-side.

Cheers,

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

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

Re: [IDE] meaningless #ifndef?

[Bill Wendling]

Also sprach Andre Hedrick:
} On Mon, 19 Feb 2001, Pozsar Balazs wrote:
} 
} > from drivers/ide/ide-features.c:
} > 
} > /*
} >  *  All hosts that use the 80c ribbon mus use!
} >  */
} > byte eighty_ninty_three (ide_drive_t *drive)
} > {
} > return ((byte) ((HWIF(drive)->udma_four) &&
} > #ifndef CONFIG_IDEDMA_IVB
} > (drive->id->hw_config & 0x4000) &&
} > #endif /* CONFIG_IDEDMA_IVB */
} > (drive->id->hw_config & 0x6000)) ? 1 : 0);
} > }
} > 
} > If i see well, then this is always same whether CONFIG_IDEDMA_IVB is
} > defined or not.
} > What's the clue?
} 
[snip...]

The use of the ternary operator is superfluous, though...and makes the
code look ugly IMNSHO :).

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

[PATCH] make nfsroot accept server addresses from BOOTP root

[Ben LaHaise]

Hello,

Here's a handy little patch that makes the kernel parse out the ip
address of the nfs server from the bootp root path.  Otherwise it's
impossible to boot the kernel without command line options on diskless
workstations (I hate RPL).

-ben

diff -ur v2.4.1-ac18/fs/nfs/nfsroot.c work/fs/nfs/nfsroot.c
--- v2.4.1-ac18/fs/nfs/nfsroot.cMon Sep 25 16:13:53 2000
+++ work/fs/nfs/nfsroot.c   Mon Feb 19 18:05:24 2001
@@ -224,8 +224,7 @@
}
}
if (name[0] && strcmp(name, "default")) {
-   strncpy(buf, name, NFS_MAXPATHLEN-1);
-   buf[NFS_MAXPATHLEN-1] = 0;
+   root_nfs_parse_addr(name);
}
 }


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

Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up

[James A. Pattie]

I'm not subscribed to the kernel mailing list, so please cc any replies
to me.

I'm building a firewall on a P133 with 48 MB of memory using RH 7.0,
latest updates, etc. and kernel 2.4.1.
I've built a customized install of RH (~200MB)  which I untar onto the
system after building my raid arrays, etc. via a Rescue CD which I
created using Timo's Rescue CD project.  The booting kernel is
2.4.1-ac10, no networking, raid compiled in but raid1 as a module,
reiserfs as a module, ext2 and iso-9660 compiled in, using sg support
for cd-roms.  I had to strip the kernel down so it would fit on a floppy
as the system does not support booting off of CD-ROM.

After booting and getting my initial file system in memory (20+ MB
ramdisk), I created a partition for swap, format and then swapon so I
don't run out of memory.  At this point I usually have 3-5 MB free
memory, 128 MB swap.

I partitioned the 2 drives (on 1st and 2nd controller, both 1.3 GB each)
into 4 total partitions.  1st is swap and then the next 3, 1 primary, 2
extended are for raid 1 arrays.  I've given 20 MB to /boot (md0), 650MB
to / (md1) and the rest (400+MB) to /var (md2).  I format md0 as ext2
and md1 and md2 as reiserfs.  When I go to untar the image on the cd to
/mnt/slash (which has md1 mounted on it), the system extracts about 30MB
of data and then just stops responding.  No kernel output, etc.  I can
change to the other virtual consoles, but no other keyboard input is
accepted.  After resetting the machine, the raid arrays rebuild ok, and
reiserfs gives me no problems other than it usually replays 2 or 3
transactions.  If I tell tar to pickup on the last directory I saw
extracted, it gets about another 30MB of data and stops again.  I've
waited for the raid syncing to be finished or just started after the
arrays are available and it doesn't matter.

I first tried with 2.4.1 stock and then went to 2.4.1-ac10 (the latest
at the time I was playing with this) and it did exactly the same thing.
If I format md1 and md2 with ext2, then everything works fine.  I was
initially compiling 386 only support in and have tried with 586 support
(no difference).  I've tried both r5 and tea hashes with reiserfs.

One thing I did notice was that the syncing of the raid 1 arrays went in
sequence, md0, md1, md2 instead of in parrallel.  I assume it is because
the machine just doesn't have the horsepower, etc. or is it that I have
multiple raid arrays on the same drives?

This isn't a life or death issue at the moment, but I would like to be
able to use reiserfs in this scenario in the future.

I have tested the same rescue CD boot image on a K62, 450Mhz, 128 MB
system.  No raid, just one reiserfs partition and it untarred without
any issues.  I'm thinking this is something specific to older, lower
memory machines?

--
James A. Pattie
[EMAIL PROTECTED]

Linux  --  SysAdmin / Programmer
PC & Web Xperience, Inc.
http://www.pcxperience.com/



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

Re: PROBLEM: pci bridge fails to wake up from suspend/resume( Inspiron 8000 )

[Morten Stenseth]

 
> Did you enable eepro100 power management?
> 

i tried with and without power managment enabled and it fails either
way, but i have been playing with the setpci command and have
been able to restore all the pci cards/bridges to their original state
and now everything seems to work great, actually it fixed another
problem i have had with this machine , namely whenever i try
to insert agpgart after a suspend/resume the machine freezes,
but resetting the host bridge to it original seems to fix the problem.

I have included a bash script which sets the registers correct
on a inspiron 8000 ( well it works here anyways :-) ) . ,

please give me a howler if anybody want's me to
check out/test  this some more.








 



#!/bin/sh  
SETPCI=/sbin/setpci

#00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory
#Controller Hub (rev 02)
DEV=00:00.0
$SETPCI -s $DEV 12.w=0xe400

#02:06.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100 (rev 11) (prog-if 00 [Normal decode])
DEV=02:06.0
$SETPCI -s $DEV 20.w=0xf800
$SETPCI -s $DEV 22.w=0xf9f0
$SETPCI -s $DEV 24.w=0xfff0
$SETPCI -s $DEV 3e.w=0x0006

#08:04.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)Subsystem: Action Tec Electronics Inc: Unknown device 1100
DEV=08:04.0
$SETPCI -s $DEV c.w=0x2008
$SETPCI -s $DEV 4.w=0x0117
$SETPCI -s $DEV 10.w=0xf000
$SETPCI -s $DEV 12.w=0xf8ff
$SETPCI -s $DEV 14.w=0xecc1
$SETPCI -s $DEV 1a.w=0xf8e0
$SETPCI -s $DEV 3c.w=0x0b00
 

Re: [PATCH] change awe_wave initialization to match 2.2 better

[Alan Cox]

> It seem obvious that this change in behaviour is isapnptools related, but
> not detecting the whole three IO addresses is an unresolved problem (as of
> 2.2.18, not tried with built-in PnP support in 2.4.x).

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

Re: eepro100 + 2.2.18 + laptop problems

[Andrey Savochkin]

Hi,

On Tue, Feb 20, 2001 at 09:21:06AM +1100, CaT wrote:
> On Tue, Feb 13, 2001 at 03:14:09PM +1100, CaT wrote:
> > On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> > > On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> > > [snip]
> > > > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout 
>with(0x70)!
> > > 
> > > Please try the attached patch.
> > > Actually, it's designed to solve another problem, but may be your one has the
> > > same origin as that other.
> > 
> > Cool. Thanks. I recompiled the module and am trying it now. So far the
> > ethernet connection is fine but the above problem isn't reproducable with 
> > 100% accuracy and so it'll take me a wee while before I decide '
> > a... that rocks my boat. it's fixed.'. :)
> 
> It happened again. Same deal. Once was after a reboot and this time
> was after a resume. :/

In my experiments wait_for_cmd timeouts almost always were related to
DumpStats command.
I think, we need to investigate what time constraints are related to this
command.

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

Re: eepro100 + 2.2.18 + laptop problems

[CaT]

On Mon, Feb 19, 2001 at 03:44:10PM -0800, Dragan Stancevic wrote:
> On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote:
> ; 
> ; None. This is before any traffic gets put through it. At worst the
> ; card has the wrong IP for the network but that is not always the case
> ; from memory.
> 
> So where does that card get the address from, are you doing DHCP?

Set manually. In debian-speak: ifup eth0 where:

iface eth0 inet static
address 10.1.1.2
netmask 255.255.255.0
network 10.1.1.0
broadcast 10.1.1.255
gateway 10.1.1.1

So basically that does an ifconfig and route command I believe (or the 
equivalent)

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

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

Re: eepro100 + 2.2.18 + laptop problems

[Dragan Stancevic]

On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote:
; 
; None. This is before any traffic gets put through it. At worst the
; card has the wrong IP for the network but that is not always the case
; from memory.

So where does that card get the address from, are you doing DHCP?


-- 
No Kernel Hackers were harmed during writing of this email.

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

Re: [IDE] meaningless #ifndef?

[Andre Hedrick]

On Mon, 19 Feb 2001, Pozsar Balazs wrote:

> from drivers/ide/ide-features.c:
> 
> /*
>  *  All hosts that use the 80c ribbon mus use!
>  */
> byte eighty_ninty_three (ide_drive_t *drive)
> {
> return ((byte) ((HWIF(drive)->udma_four) &&
> #ifndef CONFIG_IDEDMA_IVB
> (drive->id->hw_config & 0x4000) &&
> #endif /* CONFIG_IDEDMA_IVB */
> (drive->id->hw_config & 0x6000)) ? 1 : 0);
> }
> 
> If i see well, then this is always same whether CONFIG_IDEDMA_IVB is
> defined or not.
> What's the clue?

(drive->id->hw_config & 0x4000)
mask off 0x4000 for presence.
(drive->id->hw_config & 0x6000) 
mask off 0x2000 ot 0x4000 for presence.

The first is true only if bit 14 is set.
The second is true if either bit 13 or 14 is set.

Togather they test for two bits.
The first test is exclusive to bit 14
The second test is inclusive of bits 13 and 14.

Because some older drives set only bit 13 for the device side cable-detect,
then newer drives than these did a supported mode bit 14 and no bits 13,
then others do both.

So in order to have a test that supports ATA-4/5/6 you have to allow
users the option to disable the newer sense code that is only valid for
ATA-5/6.  It will get messier still.

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

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

Re: eepro100 + 2.2.18 + laptop problems

[CaT]

On Mon, Feb 19, 2001 at 03:37:02PM -0800, Dragan Stancevic wrote:
> On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote:
> ; > 100% accuracy and so it'll take me a wee while before I decide '
> ; > a... that rocks my boat. it's fixed.'. :)
> ; 
> ; It happened again. Same deal. Once was after a reboot and this time
> ; was after a resume. :/
> 
> What kind of trafic are you running?

None. This is before any traffic gets put through it. At worst the
card has the wrong IP for the network but that is not always the case
from memory.

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

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

Re: Kernel executation from ROM

[Jeremy Jackson]

"Eric W. Biederman" wrote:

> No it forbids executing boot roms that way, by a standard pc bios.
> The system BIOS in a PC is normally on the ISA bus which is reached
> across via the PCI bus with a PCI->ISA bridge.

Son of a gun, I missed that... sure enough my PIIX4 docs beside me here
show a #BIOSCS pin on the southbridge... Can anybody clarify what
this restriction does and doesn't apply to ?  The MindShare PCI Arch.
book where I got that info from doesn't elaborate that much.

> The thing is slow it really doesn't matter, all you need to do is
> enable caching on that area of the physical address space.  You can't
> do this on the alpha currently but only because the alpha sucks that
> way.  You can on practically everything else.
>
> As for ROM being slow on x86 you can enable the MTRR to speed things

Don't MTRR's just do write combining?

>
> up.  Usually though ROMs are at least as expensive as RAM, so it is
> pointless.

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

Re: kernel_thread() & thread starting

[David Woodhouse]

On Mon, 19 Feb 2001, Philipp Rumpf wrote:

> No.  If kswapd oopses it's a bug in kswapd (or related code).  If keventd
> oopses most likely the broken code is actually the task queue you
> scheduled, which belongs to your driver.

If we're going to detect this case, we might as well just restart keventd.

-- 
dwmw2


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

Re: eepro100 + 2.2.18 + laptop problems

[Dragan Stancevic]

On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote:
; > 100% accuracy and so it'll take me a wee while before I decide '
; > a... that rocks my boat. it's fixed.'. :)
; 
; It happened again. Same deal. Once was after a reboot and this time
; was after a resume. :/

What kind of trafic are you running?

-- 
No Kernel Hackers were harmed during writing of this email.

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

trident.o module in kernel 2.4.1

[Seok H. Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm having some troubles with a Trident 4DWave NX sound card
(specifically the Hoontech Digital-NX model). I loaded the modules
soundcore.o, ac97_codec.o, and trident.o, in that order, and when I
try to use the devices /dev/dsp and /dev/audio, I *don't* get a "No
such device" error. But nevertheless, there is no sound coming out
from the speakers. What I hear instead, if I turn up the volume
control on the speakers all the way up, is a faint pulsing noise,
somewhat like a barely audible heartbeat. I've reproduced this
pulsing
noise using three methods:

1. By running "cat blah.wav > /dev/[audio|dsp]"
2. By running "play blah.wav" (using the program 'play' from the sox
package)
3. By playing an mp3 with XMMS in X-Windows

Using Windows 98 installed on the same machine, I've verified that
there is nothing wrong with either the sound card or the wave file.
In
fact, the PCI code in the linux kernel (2.4.1 in Debian potato w/
proposed updates and security updates installed) detects the same
memory address, I/O address, and IRQ that Windows 98 uses. You can
see
from the attached 'lspci -vvx' and 'dmesg' outputs that the card is
indeed initialized by the BIOS and detected by the kernel as well as
the trident module. I've tried adjusting the sound card's mixer
settings with a console program called 'aumix,' but turning the
volume
up on all the devices didn't help. Neither did fidgeting with the
volume control knob on my speakers. Yes, the speaker is plugged into
a
power outlet, and yes, it is turned on. Same goes for my computer. :P
During the last three days, I've been searching for a documentation
of
a similar problem and, more generally, any documentation I could find
on the trident driver. But it seems that the driver is relatively
new,
and not much has been written about it. I see nothing wrong with the
hardware or the kernel's detection of it, and after trying everything
from compiling a new kernel to upgrading my BIOS, I have come to the
conclusion that the problem must be in the module. I've tried to read
the source code in trident.c, and although I know C/C++ syntax pretty
well, I haven't written any programs dealing with hardware
interfacing
and therefore could not understand what was going on. If you are
knowledgeable in this area, please help. Otherwise, kindly ignore my
message.

Oh, and one last thing. Please CC any replies to my e-mail address,
[EMAIL PROTECTED] I am not subscribed to the mailing list and will
not see your reply otherwise. Thank you.

Regards,

Seok Lee

-BEGIN PGP SIGNATURE-
Version: PGP 6.5i

iQA/AwUBOpGdvC5tHmNGNoW0EQLoUgCg4nPoUeWxLewKWV0kLyV+FXr7ENMAn36c
yhu87t9DZfLPysYne1mOVBk+
=3Wcz
-END PGP SIGNATURE-
 DMESG
 interrupts
 IOMEM
 IOPORTS
 LSMOD
 LSPCI

Re: eepro100 + 2.2.18 + laptop problems

[CaT]

On Tue, Feb 13, 2001 at 03:14:09PM +1100, CaT wrote:
> On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> > On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> > [snip]
> > > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout 
>with(0x70)!
> > 
> > Please try the attached patch.
> > Actually, it's designed to solve another problem, but may be your one has the
> > same origin as that other.
> 
> Cool. Thanks. I recompiled the module and am trying it now. So far the
> ethernet connection is fine but the above problem isn't reproducable with 
> 100% accuracy and so it'll take me a wee while before I decide '
> a... that rocks my boat. it's fixed.'. :)

It happened again. Same deal. Once was after a reboot and this time
was after a resume. :/

Help?

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

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

Re: MTU and 2.4.x kernel

[Rick Jones]

the TCP code should be "honouring" the link-local MTU in its selection
of MSS.

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

[PATCH] new setprocuid syscall

[BERECZ Szabolcs]

Hi!

Here is a new syscall. With this you can change the owner of a running
procces.
I put the architecture dependent part (syscall NR, and function address)
only to the i386, becouse I'm not familiar with the other arch.
What do you think about it?
I think it's useful, but...
Now I'm writing the userspace prg, to use it.

Bye,
Szabolcs



diff -urN linux-2.4.1/arch/i386/kernel/entry.S
linux-2.4.1-setprocuid/arch/i386/kernel/entry.S
--- linux-2.4.1/arch/i386/kernel/entry.SThu Nov  9 02:09:50 2000
+++ linux-2.4.1-setprocuid/arch/i386/kernel/entry.S Mon Feb 19
22:12:00 2001
@@ -645,6 +645,7 @@
.long SYMBOL_NAME(sys_madvise)
.long SYMBOL_NAME(sys_getdents64)   /* 220 */
.long SYMBOL_NAME(sys_fcntl64)
+   .long SYMBOL_NAME(sys_setprocuid)
.long SYMBOL_NAME(sys_ni_syscall)   /* reserved for TUX */

/*
diff -urN linux-2.4.1/include/asm-i386/unistd.h
linux-2.4.1-setprocuid/include/asm-i386/unistd.h
--- linux-2.4.1/include/asm-i386/unistd.h   Fri Aug 11 23:39:23 2000
+++ linux-2.4.1-setprocuid/include/asm-i386/unistd.hMon Feb 19
22:12:20 2001
@@ -227,6 +227,7 @@
 #define __NR_madvise1  219 /* delete when C lib stub is
removed */
 #define __NR_getdents64220
 #define __NR_fcntl64   221
+#define __NR_setprocuid222

 /* user-visible error numbers are in the range -1 - -124: see
 */

diff -urN linux-2.4.1/kernel/sys.c linux-2.4.1-setprocuid/kernel/sys.c
--- linux-2.4.1/kernel/sys.cMon Oct 16 21:58:51 2000
+++ linux-2.4.1-setprocuid/kernel/sys.c Mon Feb 19 21:52:51 2001
@@ -582,6 +582,17 @@
return 0;
 }

+asmlinkage long sys_setprocuid(pid_t pid, uid_t uid)
+{
+   struct task_struct *p;
+
+   if (current->euid)
+   return -EPERM;
+
+   p = find_task_by_pid(pid);
+   p->fsuid = p->euid = p->suid = p->uid = uid;
+   return 0;
+}

 /*
  * This function implements a generic ability to update ruid, euid,


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

rsync on newer kernel does not quite work?

[Rasmus Andersen]

Hi.

For some time up through the testX kernels I used rsync to
update my "dirty" tree after applying the latest patches to the
clean tree. At some point this stopped working (more about that
later) but as new kernels were coming fast at that time I did
not think much of it, assuming that cleverer folk than me would
fix it soon. They did not, however, and I got kinda used to
working around the "bug".

The problem manifests itself in that rsync will complete syncing
two directories but will then hang (soft). It can be killed
with ^C and rerun with success. The amount of work that rsync
needs to do seems to be the trigger: rsyncing the drivers
directory (to a non-existent dir) will trigger the hang for
me, but drivers/[a-r]* will not.

Since Matthias Schniedermeyer reported the same problem in
http://marc.theaimsgroup.com/?l=linux-kernel&m=98157768131423&w=2
I have tried on and off to locate the kernel version where
the shift in behaviour happened, but after recompiling all
kernels down to test1 I have not gotten a successfull rsync
run yet. And I am sure that it worked once, well after test1.
I have upgraded my build environment from RH6.2 to RH7.0
in the meanwhile, but I even remembered to change 'gcc' to
'kgcc' in the makefile without luck :/ However, rsync behaves as
expected under 2.2.18 (compiled locally) and the 2.2.16-22
that comes with RH7.0. But not under any of the 2.4.X kernels
that I have tried (most of them incl. -acX).

rsyncs tried: 2.4.4-1 (rpm), 2.4.6 (local compile) and 2.4.1 
  (ditto).
kernels tried (not working) (partial list): 241, 241ac9, 
  242p4, 240-testX (1<=X<=12).
gccs tried (rsync and kernel compiles): kgcc (gcc version 
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)), gcc
(gcc version 2.96 2731 (Red Hat Linux 7.0)) (2.96-69)

If you need further information please let me know.


-- 
Regards,
Rasmus([EMAIL PROTECTED])

First snow, then silence.
This thousand dollar screen dies
so beautifully.   --- Error messages in haiku
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel executation from ROM

[Eric W. Biederman]

Jeremy Jackson <[EMAIL PROTECTED]> writes:

> Jaswinder Singh wrote:
> 
> > Dear Sirs,
> >
> > Thanks for your help,
> >
> > I see . The biggest negative point of running kernel from ROM is that ROM
> > speed is slow :(
> 
> Also, the PCI specification forbids executing code from ROMs over the PCI bus.
> The system BIOS in a PC is not on the PCI bus, bus, but everything else is.

No it forbids executing boot roms that way, by a standard pc bios.  
The system BIOS in a PC is normally on the ISA bus which is reached
across via the PCI bus with a PCI->ISA bridge.

The thing is slow it really doesn't matter, all you need to do is
enable caching on that area of the physical address space.  You can't
do this on the alpha currently but only because the alpha sucks that
way.  You can on practically everything else.

As for ROM being slow on x86 you can enable the MTRR to speed things
up.  Usually though ROMs are at least as expensive as RAM, so it is
pointless.

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

Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )

[Eric W. Biederman]

Mikulas Patocka <[EMAIL PROTECTED]> writes:

> Imagine that there is specification of mark_buffer_dirty. That
> specification says that
>   1. it may not block
>   2. it may block
> 
> In case 1. implementators wouldn't change it to block in stable kernel
>   relese because they don't want to violate the specification.
> 
> In case 2. implementators of ext2 wouldn't assume that it doesn't block
>   even if it doesn't in current implementation.

Whenever the question has been asked the answer is always assume anything
in the kernel outside of the current function blocks.  

> In both cases, the bug wouldn't be created.

Nope.  It looks like someone made a mistake in ext2...

> 
> Anytime you change implementation of syscalls, you gotta check all
> applications that use them ;-) Luckily not - because there is
> specification and you can check that syscalls conform to the
> specification, not apps. 

Not normally.  The rule is that syscall don't change period.  The
internal kernel interface is different.  It is allowed to change.

As for syscall changing auditing most apps did happen when the LFS
spec was put together.  So you would have an implementation that would
keep most apps from failing on large files.

> > > Saying "code is the specification" is not good.
> > 
> > I'm not arguing against documentation.  That is dumb.  But the code is
> > ALWAYS canonical.  Not docs.
> 
> Let's see:

> Who is right? If there is no specification

Hmm.  The developers should get together and pow wow when the problem
is noticed.  When it is finally talked out about how it should happen
then the code should get fixed accordingly.

It isn't about right and wrong it is about working code.  Not that
documenting things doesn't help.  And 2.4 is going in that direction...

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

Re: aic7xxx (and sym53c8xx) plans

[Justin T. Gibbs]

>BTW, is there really enough common ground between the whole series of
>AIC chips to justify a single huge driver?  I know they ship three
>separate NT drivers to cover this range..

The chips are very similar.  I think the single driver for Linux is
actually a smaller binary than any of the individual drivers for NT. 8-)

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

[IDE] meaningless #ifndef?

[Pozsar Balazs]

from drivers/ide/ide-features.c:

/*
 *  All hosts that use the 80c ribbon mus use!
 */
byte eighty_ninty_three (ide_drive_t *drive)
{
return ((byte) ((HWIF(drive)->udma_four) &&
#ifndef CONFIG_IDEDMA_IVB
(drive->id->hw_config & 0x4000) &&
#endif /* CONFIG_IDEDMA_IVB */
(drive->id->hw_config & 0x6000)) ? 1 : 0);
}

If i see well, then this is always same whether CONFIG_IDEDMA_IVB is
defined or not.
What's the clue?

-- 
pozsy.

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

Re: SO_SNDTIMEO: 2.4 kernel bugs

[Chris Evans]

On Mon, 19 Feb 2001 [EMAIL PROTECTED] wrote:

> Wakeup does not happen until _enough_ (1/3 of snbuf) of space in sndbuf
> is released, otherwise you will overschedule. So, as soon as
> write() goes to sleep, it will sleep waiting until 1/3 is released.

Of course. Thank you.

> If it is interrupted, it use all the released space immediately before
> exit. Again, to make more for in this context. This can be even wrong
> and, probably, we should return instantly with -EAGAIN/-EINTR/partial
> count, but it is most likely suboptimal (though I have already changed
> this to instant return). But this does not look essential from
> caller's viewpoint, except for sendfile() of course. 8)

Cool.

I think the proper fix, long term, is to fix our internal I/O routine APIs
so that they are capable of returning a byte count _and_ an error. One
day, that might be a useful thing to export to userspace.

Cheers
Chris

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

Re: [LONG RANT] Re: Linux stifles innovation...

[Keith Owens]

On Mon, 19 Feb 2001 10:58:36 -0500 (EST), 
"Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
>I was unable to use the new kernel because the drivers I need for
>`initrd` all had undefined symbols relating to some high memory stuff.
>This, in spite of the fact that I did:
>
>cp .config ..
>make clean
>make distclean
>cp ../.config
>make oldconfig
>make dep
>make bzImage
>make modules
>make modules_install

FAQ: http://www.tux.org/lkml/#s8-8

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

Re: Linux 2.4.1-ac15

[Keith Owens]

On Mon, 19 Feb 2001 16:04:07 + (GMT), 
Alan Cox <[EMAIL PROTECTED]> wrote:
>My spinlock based fix has almost no contention and doesnt require 64 processors
>grind to a halt on a big machine just to handle a module list change. Sorry
>I don't think it supports your argument

I am not proposing that the other cpus grind to a halt.  On the
contrary, they are allowed to continue running.  It is the current
process that is suspended until all other cpus have gone through at
least one schedule.

On Mon, 19 Feb 2001 16:23:09 +0100, 
Manfred Spraul <[EMAIL PROTECTED]> wrote:
>what about
>
>   spin_unlock_wait(&global_exception_lock);
>
>The actual exception table waker uses
>   spin_lock_irqsave(&global_exception_lock);
>
>   spin_unlock_irqsave(&global_exception_lock);
>
>Or a simple spinlock - the code shouldn't be performance critical.

All lock based fixes have the disadvantage that you penalise the entire
kernel all the time.  No matter how small the overhead of getting the
lock, it still exists - so we are slowing down the main kernel all the
time to handle the rare case of module unloading.

Also notice that we keep adding spinlocks.  One for the main module
list, another for the exception tables.  Then there is the architecture
specific module data, including unwind information for IA64; that also
needs to be locked.  Requiring more than one spinlock to handle module
unloading tells me that the design is wrong.

Using wait_for_at_least_one_schedule_on_every_cpu() has no penalty
except on the process running rmmod.  It does not require yet more
spinlocks and is architecture independent.  Since schedule() updates
sched_data->last_schedule, all the rmmod process has to do is wait
until the last_schedule value changes on all cpus, forcing a reschedule
if necessary.

Zero overhead in schedule, zero overhead in exception handling, zero
overhead in IA64 unwind code, architecture independent.  Sounds good to
me.

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

Re: Maybe a bug (unexpected IO-APIC)

[Pozsar Balazs]

>
> Feb 19 19:37:17 delphin kernel: testing the IO APIC...
> Feb 19 19:37:17 delphin kernel:
> Feb 19 19:37:17 delphin kernel:  WARNING: unexpected IO-APIC, please mail
> Feb 19 19:37:17 delphin kernel:   to [EMAIL PROTECTED]
> Feb 19 19:37:17 delphin kernel:  done.

This is the same for me on a Abit VP6 running 1 Intel Celeron 433
(mendocino).
Should i care about it?

pozsy.

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

Re: The lack of specification

[Eli Carter]

Russell King wrote:
> 
> Albert D. Cahalan writes:
> > The TCP maintainers do not seem to be sadistic bastards hell-bent on
> > breaking your drivers. API changes usually have a good reason.
> 
> And when the API does change, like it has between Linux 2.2 and Linux 2.4,
> an email gets sent to this list describing the change of API.  Search
> this lists archives to find out:
> 
> 1. the reasons for the change
> 2. a complete description of the new bits of the API
> 
> There are projects around to try to pick this stuff up and put it on the
> web in one place - its called the Kernel Wiki, and iirc it is on
> sourceforge.

It's here: http://kernelbook.sourceforge.net:80/wiki/?KernelWiki
BUT.. it's currently dead and has been since December.
I'd really like to see this brought back...

Eli
.  Rule of Accuracy: When working toward
Eli Carter  |   the solution of a problem, it always 
[EMAIL PROTECTED] `- helps if you know the answer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel_thread() & thread starting

[Philipp Rumpf]

On Mon, 19 Feb 2001, Russell King wrote:
> Philipp Rumpf writes:
> > That still won't catch keventd oopsing though - which I think might happen
> > quite easily in real life.
> 
> Maybe we should panic in that case?  For example, what happens if kswapd
> oopses?  kreclaimd?  bdflush?  kupdate?  All these have the same problem,

No.  If kswapd oopses it's a bug in kswapd (or related code).  If keventd
oopses most likely the broken code is actually the task queue you
scheduled, which belongs to your driver.

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

Re: aic7xxx (and sym53c8xx) plans

[Matthew Jacob]

> May-be this is the reason some UNIX vendors seem to love UDI. :)
> 
> If you also use SYMBIOS chips, you may give a try with SYM-2. For the
> moment, it replaces only 6 drivers :) as also seems to do, for the moment,
> Justin's AIC7XXX-6, by the way.
> 
> The plans seem clear to me. :-)
> Btw, I _do_ like a lot better the 'one driver' plan over the '12 or more'
> one.

Hmm. Well, it's good if it works. The joint Qlogic FC/SCSI driver of mine has
it's own plusses && minusses...


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

Re: The lack of specification

[Russell King]

Albert D. Cahalan writes:
> The TCP maintainers do not seem to be sadistic bastards hell-bent on
> breaking your drivers. API changes usually have a good reason.

And when the API does change, like it has between Linux 2.2 and Linux 2.4,
an email gets sent to this list describing the change of API.  Search
this lists archives to find out:

1. the reasons for the change
2. a complete description of the new bits of the API

There are projects around to try to pick this stuff up and put it on the
web in one place - its called the Kernel Wiki, and iirc it is on
sourceforge.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: Linux 2.4.1-ac15

[Keith Owens]

On Mon, 19 Feb 2001 14:25:39 +0100, 
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>You just reinvented the read-copy-update model
>(http://www.rdrop.com/users/paulmck/rclock/intro/rclock_intro.html)...
>
>The mail proposing that locking model for module unloading is not yet
>in the arvhices, sorry.

I did not reinvent it, I was following up on the discussion we already
had off list about using this model.

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

Maybe a bug

[Matthias Kleine]

Dear kernel-developers,

I do not have any experience in kernel programming, but I do have a message 
in my /var/log/messages file which advices me to post to this list. This is 
the first time for me to visit this list, so don't be too hard too me if this 
posting doesn't fit into the common list rules.

The problem appears on a machine using the pretty new ASUS CUVX-D Dual Socket 
370 Motherboard, so there may be a chance for an unknown bug ;-). With NMI 
watchdog activated, a 2.4.x Kernel is not willing to boot on this machine, it 
just stops booting at a very early time, giving the latest message 
"activating NMI watchdog ..." and then blocking completely. Therefore, I set 
nmi_watchdog = 0, when the system boots properly, but leaves some crucial 
message in /var/log/messages:

Feb 19 19:37:17 delphin kernel: testing the IO APIC...
Feb 19 19:37:17 delphin kernel: 
Feb 19 19:37:17 delphin kernel:  WARNING: unexpected IO-APIC, please mail
Feb 19 19:37:17 delphin kernel:   to [EMAIL PROTECTED]
Feb 19 19:37:17 delphin kernel:  done.

This is the reason for my posting in this list. This boot has been done with 
a self-compiled original 2.4.1 kernel, without any patches applied. With NMI 
watchdog activated, I could also reproduce the problem with a standard 
2.4-SMP kernel from the SuSE 7.1 distribution, but booting does not lock up 
each time. In one from 5 trials, the system boots even with NMI watchdog 
activated. Here is the output of dmesg after booting the kernel 2.4.1 with 
NMI watchdog activated:

Linux version 2.4.1 (root@delphin) (gcc version 2.95.3 19991030 (prerelease)) 
#1 SMP Sam Feb 17 19:51:27 CET 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 1fefc000 @ 0010 (usable)
 BIOS-e820: 3000 @ 1fffc000 (ACPI data)
 BIOS-e820: 1000 @ 1000 (ACPI NVS)
 BIOS-e820: 1000 @ fec0 (reserved)
 BIOS-e820: 1000 @ fee0 (reserved)
 BIOS-e820: 0001 @  (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
found SMP MP-table at 000f5460
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
On node 0 totalpages: 131068
zone(0): 4096 pages.
zone(1): 126972 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0
Processor #3 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
SEP present.
MTRR  present.
PGE  present.
MCA  present.
CMOV  present.
PAT  present.
PSE  present.
MMX  present.
FXSR  present.
XMM  present.
Bootup CPU
Processor #0 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
SEP present.
MTRR  present.
PGE  present.
MCA  present.
CMOV  present.
PAT  present.
PSE  present.
MMX  present.
FXSR  present.
XMM  present.
Bus #0 is PCI   
Bus #1 is PCI   
Bus #2 is ISA   
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 0, trig 0, 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 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 1, IRQ 00, APIC ID 2, APIC INT 10
Int: type 0, pol 3, trig 3, bus 2, IRQ 00, APIC ID 2, APIC INT 00
Int: type 0, pol 3, trig 3, bus 0, IRQ 13, APIC ID 2, APIC INT 12
Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 2, APIC INT 12
Int: type 0, pol 3, trig 3, bus 0, IRQ 2c, APIC ID 2, APIC INT 11
Lint: type 3, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 00
Lint: type 1, pol 1, trig 1, bus 2, IRQ 00, APIC ID ff, APIC LINT 01
Processors: 2
mapped APIC to e000 (fee0)
mapped IOAPIC to d000 (fec0)
Kernel command line: BOOT_IMAGE=linux24 ro

Re: aic7xxx (and sym53c8xx) plans

[Gérard Roudier]

On Mon, 19 Feb 2001, Peter Samuelson wrote:

> [Justin Gibbs]
> > I've verified the driver's functionality on 25 different cards thus
> > far covering the full range of chips from aic7770->aic7899.
> 
> That's very good to hear.  I know the temptation of only testing on new
> hardware; that's why I was concerned.
> 
> > Lots of people here at Adaptec look at me funny when I pull a PC from
> > the scrap-heap, or pull an old, discontinued card from an unused
> > marketing display for use in my lab
> 
> Heh. (:
> 
> BTW, is there really enough common ground between the whole series of
> AIC chips to justify a single huge driver?  I know they ship three
> separate NT drivers to cover this range..

LSILOGIC also ship 3 drivers to cover the 53C810 - 53C1010 range on NT.
And, btw, these chips are all PCI.

Doing so, 12 different drivers would be needed to cover 4 different O/Ses,
for example. These drivers (I spoke about both LSILOGIC and ADAPTEC
drivers for NT) obviously work for i386, but what about architecture
dependencies at source level?

May-be this is the reason some UNIX vendors seem to love UDI. :)

If you also use SYMBIOS chips, you may give a try with SYM-2. For the
moment, it replaces only 6 drivers :) as also seems to do, for the moment,
Justin's AIC7XXX-6, by the way.

The plans seem clear to me. :-)
Btw, I _do_ like a lot better the 'one driver' plan over the '12 or more'
one.

  Gérard.

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

Re: kernel_thread() & thread starting

[Russell King]

Philipp Rumpf writes:
> That still won't catch keventd oopsing though - which I think might happen
> quite easily in real life.

Maybe we should panic in that case?  For example, what happens if kswapd
oopses?  kreclaimd?  bdflush?  kupdate?  All these have the same problem,
and should probably have the same "fix" applied, whatever that fix may
be.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: [PATCH] change awe_wave initialization to match 2.2 better

[José Luis Domingo López]

On Monday, 19 February 2001, at 14:28:09 -0500,
Bill Nottingham wrote:

> The awe_wave driver in 2.2 looked at the common I/O ports for
> the card if no parameters were specified. The 2.4 driver currently
> does an ISAPnP probe, but doesn't fall back to the previous probing
> behavior, which means that users with working module configurations
> will have theirs broken on upgrade.
> 
Don't know if what follows has something to do with the patch you
submitted, but under kernel 2.2.x SB AWE 64 had a nasty problem. pnpdump
from the isapnptools (all versions I've tested) only reports one of a
total of three IO adresses for the Wavetable device:
(IO 0 (SIZE 4) (BASE 0x0620))
(IO 1 (SIZE 4) (BASE 0x0A20))  <-- not reported by pnpdump
(IO 2 (SIZE 4) (BASE 0x0E20))  <-- not reported by pnpdump

The latter two lines where manually added, as described in the
SB-AWE-HOWTO. Using isapnptools 1.21-2 (Debian Potato) the card configures
correctly, but with isapnptools 1.23-0.3 (Debian Woody) there is an error
trying to parse the first of the manually added lines (Don't know what to
do with A20)) on or around line 350).

It seem obvious that this change in behaviour is isapnptools related, but
not detecting the whole three IO addresses is an unresolved problem (as of
2.2.18, not tried with built-in PnP support in 2.4.x).

Would you need more information ?. I'm a totally kernel-devel newbie, but
with 3+ years using Linux, I think I can help with testing and triying
with kernel 2.4.x or patched 2.2.x.

-- 
José Luis Domingo López
Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM)
 
jdomingo EN internautas PUNTO org  => ¿ Spam ? Atente a las consecuencias
jdomingo AT internautas DOT   org  => Spam at your own risk

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

[OT] Re: Running Bind 9 on Redhat 7

[Stefan Smietanowski]

Hi.

> I am configuring Bind 9 on Redhat 7 but unable to start the named.
> Here is my /var/log message log:



Read the documentation and you shall notice that you must set a ttl for
each zone, which also your logs state that you have not done ...

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

Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )

[Mikulas Patocka]

> One of these things must happen:
> 
> a. follow the specification, even if that makes code slow and contorted
> b. change the specification
> c. ignore the specification
> d. get rid of the specification
> 
> Option "a" will not be accepted around here. Sorry.

It should be followed in stable releases. (and usually is - except for few
cases - and except that there is no specification, just unwritten rules).

> The best you can
> hope for is option "b". Since that is hard work (want to help?) we
> often end up not using a specification... hopefully by just not
> having one, instead of by ignoring one.


> > Now implementators of TCP will say: that driver is buggy. Everybody should
> > set state=TASK_RUNNING before calling schedule to yield the process. 
> > 
> > Implementators of driver will say: TCP is buggy - no one should call my
> > driver in TASK_[UN]INTERRUPTIBLE state.
> > 
> > Who is right? If there is no specification
> 
> The driver is buggy, unless the TCP maintainer can be convinced
> that TCP is buggy. TCP is a big chunk of code that most people use,
> while the driver is not so huge or critical.
> 
> The TCP maintainers do not seem to be sadistic bastards hell-bent on
> breaking your drivers. API changes usually have a good reason.

Why should block device developers read TCP/IP code? And only after
reading significant amount of it they realize that they can be called in
TASK_INTERRUPTIBLE state. 

They will most likely read other block drivers, find using schedule
without setting state and use it also that way. 

The only way to tell developers to always set state before using schedule
is to write it to specification.

Mikulas


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

Re: aic7xxx (and sym53c8xx) plans

[Peter Samuelson]

[Justin Gibbs]
> I've verified the driver's functionality on 25 different cards thus
> far covering the full range of chips from aic7770->aic7899.

That's very good to hear.  I know the temptation of only testing on new
hardware; that's why I was concerned.

> Lots of people here at Adaptec look at me funny when I pull a PC from
> the scrap-heap, or pull an old, discontinued card from an unused
> marketing display for use in my lab

Heh. (:

BTW, is there really enough common ground between the whole series of
AIC chips to justify a single huge driver?  I know they ship three
separate NT drivers to cover this range..

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

Re: Journaled FS on RAID stability..2.4?

[Jason Straight]

On Monday 19 February 2001 15:16, you wrote:
> what raid level?
>

Raid 0


> -Tony
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> Anthony J. Biacco   Network Administrator/Engineer
> [EMAIL PROTECTED]   Intergrafix Internet Services
>
> "Dream as if you'll live forever, live as if you'll die today"
> http://www.asteroid-b612.orghttp://www.intergrafix.net
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
>
> On Mon, 19 Feb 2001, Jason Straight wrote:
> > On Monday 19 February 2001 14:58, Admin Mailing Lists wrote:
> > > Can anyone give testimonials on a journaled FS on software-raid?
> > > I'd like to raid-0 2 SCSI 18Gers, adaptec 2940 u2w controller, kernel
> > > 2.4.x.
> > > Also pros and cons for reiser-fs/ext3 on this solution would be
> > > appreciated
> > >
> > > Thanx,
> > >
> > > -Tony
> > > .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> > > Anthony J. Biacco   Network Administrator/Engineer
> > > [EMAIL PROTECTED]   Intergrafix Internet Services
> > >
> > > "Dream as if you'll live forever, live as if you'll die today"
> > > http://www.asteroid-b612.orghttp://www.intergrafix.net
> > > .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> > >
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > > in the body of a message to [EMAIL PROTECTED]
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> >
> > I am running squid on a dual 533 celeron with 4 7200RPM 40GB IBM IDE
> > drives, using kernel 2.4.1 and reiserfs for a couple weeks now. Seems
> > good - only got 30GB on it right now.
> >
> >
> >
> > --
> > Jason Straight

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

Re: The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )

[Albert D. Cahalan]

Mikulas Patocka writes:

> Imagine that there is specification of mark_buffer_dirty. That
> specification says that
>   1. it may not block
>   2. it may block
> 
> In case 1. implementators wouldn't change it to block in stable kernel
>   relese because they don't want to violate the specification.

One of these things must happen:

a. follow the specification, even if that makes code slow and contorted
b. change the specification
c. ignore the specification
d. get rid of the specification

Option "a" will not be accepted around here. Sorry. The best you can
hope for is option "b". Since that is hard work (want to help?) we
often end up not using a specification... hopefully by just not
having one, instead of by ignoring one.

Not saying it doesn't suck to have things undocumented, but at least
you don't have to reverse-engineer a multi-megabyte binary kernel to
find out what is going on.

>> Anytime you change implementation, you gotta check all drivers that use
>> them.  I know, I'm one of the grunts that does such reviews and changes.
>
> Anytime you change implementation of syscalls, you gotta check all
> applications that use them ;-) Luckily not - because there is
> specification and you can check that syscalls conform to the
> specification, not apps. 

Syscalls are more stable, but they may be changed after many years
of a transition period. The C library hides some of this from users.

> Now implementators of TCP will say: that driver is buggy. Everybody should
> set state=TASK_RUNNING before calling schedule to yield the process. 
> 
> Implementators of driver will say: TCP is buggy - no one should call my
> driver in TASK_[UN]INTERRUPTIBLE state.
> 
> Who is right? If there is no specification

The driver is buggy, unless the TCP maintainer can be convinced
that TCP is buggy. TCP is a big chunk of code that most people use,
while the driver is not so huge or critical.

The TCP maintainers do not seem to be sadistic bastards hell-bent on
breaking your drivers. API changes usually have a good reason.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Journaled FS on RAID stability..2.4?

[Jason Straight]

On Monday 19 February 2001 14:58, Admin Mailing Lists wrote:
> Can anyone give testimonials on a journaled FS on software-raid?
> I'd like to raid-0 2 SCSI 18Gers, adaptec 2940 u2w controller, kernel
> 2.4.x.
> Also pros and cons for reiser-fs/ext3 on this solution would be
> appreciated
>
> Thanx,
>
> -Tony
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
> Anthony J. Biacco   Network Administrator/Engineer
> [EMAIL PROTECTED]   Intergrafix Internet Services
>
> "Dream as if you'll live forever, live as if you'll die today"
> http://www.asteroid-b612.orghttp://www.intergrafix.net
> .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I am running squid on a dual 533 celeron with 4 7200RPM 40GB IBM IDE drives, 
using kernel 2.4.1 and reiserfs for a couple weeks now. Seems good - only got 
30GB on it right now.



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

Journaled FS on RAID stability..2.4?

[Admin Mailing Lists]

Can anyone give testimonials on a journaled FS on software-raid?
I'd like to raid-0 2 SCSI 18Gers, adaptec 2940 u2w controller, kernel
2.4.x.
Also pros and cons for reiser-fs/ext3 on this solution would be
appreciated

Thanx,

-Tony
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco   Network Administrator/Engineer
[EMAIL PROTECTED]   Intergrafix Internet Services

"Dream as if you'll live forever, live as if you'll die today"
http://www.asteroid-b612.orghttp://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.


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

[PATCH] change awe_wave initialization to match 2.2 better

[Bill Nottingham]

The awe_wave driver in 2.2 looked at the common I/O ports for
the card if no parameters were specified. The 2.4 driver currently
does an ISAPnP probe, but doesn't fall back to the previous probing
behavior, which means that users with working module configurations
will have theirs broken on upgrade.

The attached fixes it to fall back to 2.2-style behavior if no
parameters are specified; if 'isapnp=1' is specified, it does
not try to look for cards if the ISAPnP probe fails.

Bill


--- linux/drivers/sound/awe_wave.c.foo  Mon Feb 19 14:05:47 2001
+++ linux/drivers/sound/awe_wave.c  Mon Feb 19 14:06:51 2001
@@ -206,7 +206,7 @@
 int io = AWE_DEFAULT_BASE_ADDR; /* Emu8000 base address */
 int memsize = AWE_DEFAULT_MEM_SIZE; /* memory size in Kbytes */
 #if defined CONFIG_ISAPNP || defined CONFIG_ISAPNP_MODULE
-static int isapnp = 1;
+static int isapnp = -1;
 #else
 static int isapnp = 0;
 #endif
@@ -4838,10 +4838,12 @@
if (isapnp) {
if (awe_probe_isapnp(&io) < 0) {
printk(KERN_ERR "AWE32: No ISAPnP cards found\n");
-   return 0;
+   if (isapnp != -1)
+ return 0;
+   } else {
+   setup_ports(io, 0, 0);
+   return 1;
}
-   setup_ports(io, 0, 0);
-   return 1;
}
 #endif /* isapnp */
 

Re: [LONG RANT] Re: Linux stifles innovation...

[Andre Hedrick]

On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote:

> And yes, there _is_ IMHO a difference in telling someone on LKM,
> especially someone without deeper knowledge that is lookin for help:
> 
> "You're using a non-open source driver, so we can't help you. Please
> ask your vendor for support."

Henning,

Lets be realistic here.  If I take my BMW (M series) into the shop because
it has problem yet I tell the German Mechanic that he may not look under
the hood because there is a secret "wonder blunder" inside.  Where do you
think that mechanic is going to tell you to go??

This is the motor(kernel-space) not the paint(user-space).
 
You have admitted that you are an "End-User"(of the kernel) and that you
generally write user-space packages.  I have yet to understand why you are
going out of bounds.  It is clear that you have read to many of my person
best flame-wars here on LKML where I know I must have earned :
"Arse of the Year, 2000 :: LKML"

> "Fuck off,  Luser".

And you slammed me for being rude and ugly??  In my defense of code and
work that I publish, but heavily enforce the license and terms of use.
Since I am aware that about 96% of all linux boxes today use some form of
ATA/ATAPI, it is important that I recover all know fixes public/private
to help everyone.

> ("Der Ton macht die Musik". Sorry don't know the equal english
> expression).

I now see the joy in watching someone go nuts here on LKML.

Respectfully,

Andre Hedrick
Linux ATA Development

ps. Please keep up the entertainment, I am getting a good belly-laugh
of what I must have looked like in the past.


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

Re: monitoring I/O

[Karim Yaghmour]

I caught this one a little bit late, but you might want to take
a peek at the Linux Trace Toolkit:

http://www.opersys.com/LTT

You'll be able to monitor I/O at will.

Best regards,

Karim

> Michael McLeod wrote:
> 
> Hello
> 
> I am hoping someone can give me a little information or point me in the right 
>direction.  I would like to write an application that monitors I/O on
> a linux machine, but I need some help in determining where to get the information 
>I'm looking for.  What I would like to do is 'hook' into the
> kernel and record information such as volume name, type of request (read or write), 
>the amount of data being read or written, how long each
> transaction takes
> 
> Any help would be greatly appreciated, or if there is something like this already 
>available that would be even better.  Thanx
> 
> Mike

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

bug in generic math-emu

[schwidefsky]

Hi,
I found a bug in the generic floating point emulation code. The glibc
math testcases showed errors for the nearbyint(0.5) test. The problem
is in the _FP_FRAC_SRS_2 macro. The expression to find out if some 1
bits have been shifted out is wrong. Try the _FP_FRAC_SRS_2 macro
with the following parameters: X_f1 = 0x0080, X_f0 = 0x,
N = 53, sz = 56. It comes back with 0x0005 instead of
0x0004. Now you can do the math ;-)
With the following patch test-float and test-double (both from glibc)
now run without errors on a S/390 without IEEE fpu.

diff -u -r1.1.1.1 op-2.h
--- include/math-emu/op-2.h   2000/02/04 13:53:47  1.1.1.1
+++ include/math-emu/op-2.h   2001/02/19 18:53:41
@@ -79,7 +79,7 @@
 else \
   {   \
 X##_f0 = (X##_f1 >> ((N) - _FP_W_TYPE_SIZE) |\
-   (((X##_f1 << (sz - (N))) | X##_f0) != 0));   \
+   (((X##_f1 << (2*_FP_W_TYPE_SIZE - (N))) | X##_f0) != 0)); \
 X##_f1 = 0;   \
   }   \
   } while (0)


blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: [EMAIL PROTECTED]


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

Linux 2.4.1ac19

[Alan Cox]

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

"An innovation a day keeps the monopolist away"


2.4.1-ac19
o   Fix second module/exception table race  (me)
| I hope ;)
o   Additional CPIA usb ident   (Adam J Richter)
o   Add SA1100 udc and also stall recovery to   (Oleg Drokin)
usbnet
o   Limit smbfs to 2Gig/file(Urban Widmark)
o   Config/doc update for the eicon driver  (Armin Schindler)
o   Update PMS driver to new request_region (Andrey Panin)
o   sys_semop bug check is overcareful  (Hugh Dickins)
o   Fix ipc off by one on checks in ipc (Hugh Dickins)
o   Allow exceptions during module init (Philipp Rumpf)
o   Driver namespace cleanup(Jeff Garzik)
o   Network driver cleanups (Jeff Garzik, 
o   PPC irq updates (Paul Mackerras)
o   SMP fixes for PPC boxes (Paul Mackerras)
o   Fix tmpfs block size reporting  (Christoph Rohland)
o   Update maintainers to add missing YAM maintainer(Jean-Paul Roubelat)
o   Add hooks for /proc/rtas(Paul Mackerras)
o   Fix wrong bogomip reporting on SMP ppc  (Paul Mackerras)
o   Remove unused dbcf inline function on PPC   (Paul Mackerras)
o   Update Cort Dougans email/urls  (Paul Mackerras)
o   Dont assume bit settings on pcnet/pci chips (Paul Mackerras)
o   Add mac ppc serial console hooks(Paul Mackerras)
o   Frame buffer driver updates for ppc (Paul Mackerras)
o   Fix devfs names for ppc serial  (Paul Mackerras)
o   Move some symbols out of net where they didnt   
belong, and into right export locations (Andrzej Krzysztofowicz)
o   Tidy and fix up syncppp drivers (Krzysztof Halasa)

2.4.1-ac18
o   Fix SO_SNDTIMEO bugs(Alexey Kuznetsov)
o   Fix tmpfs fsync (Lennert Buytenhek)
o   PPC now uses generic pci bus setup  (Paul Mackerras)
o   Remove PPC boot argument printing   (Paul Mackerras)
o   Jeff Tranter has moved  (Jeff Tranter)
o   ymf_pci driver cleanups (Pete Zaitcev)
o   Fix USB 2.0 compliance in hub.c (Brad Hards)
o   Fix usb hub device claim race   (Paul Mackerras)
o   Fix some bugs in mac_hid driver (Paul Mackerras)
o   Fix more typos  (Dag Wieers)
o   PPC compile warnings/symbol export fixes(Paul Mackerras)

2.4.1-ac17
o   Fix pegasus for bigendian   (Roman Weissgaerber)
o   Further smbfs fixes (Urban Widmark)
o   Update ISDN version tags(Kai Germaschewski)
o   Finish ISDN move to new style module_init   (Kai Germaschewski)
o   Small Eicon driver updates/fix license bug  (Armin Schindler)
o   Fix reiserfs tail packing problem   (Alexander Zarochentcev
 Chris Mason)
o   Export aci symbols from drivers/sound/aci.c (Alexandr Kanevskiy)
o   Merge Linus 2.4.2pre4
o   Starfire update (Ionu Badulescu)
o   Fix 3270 merge  (Richard Hitt)

2.4.1-ac16
o   Fix the exception table/unload race (me)
o   Further tulip fixup (Manfred Spraul)
o   Fix USB oops on traverse/delete race(Randy Dunlap)
o   Set max_sectors to 255 for hd/xd drivers(Paul Gortmaker)
| This should make them work again
o   Fix typo in USB makefile(Arjan van de Ven)
o   Fix accidental change to scsi_scan  (Steve Ralston)
o   Hid rollover/endian fixes   (Paul Mackerras)
o   Drop via pci fixup  (me)
o   Further hp5300 fixups   (Arjan van de Ven)
o   PCnet 32 init changes for non SEPROM cards  (Eli Carter)
o   Fix acpi idle reporting on SMP  (Philipp Hahn)
o   Add non PCI pci device list walk macro  (me)
| pointed out by Mikael Pettersson
o   IBM S/390 3270 drivers  (Richard Hitt)

2.4.1-ac15
o   Fix the non booting winchip/cyrix problem   (me)
| Nasty interaction with the vmalloc fix 
| wants a cleaner solution. This one is a hack
| to get people up and running again
o   Fix typo in vfat changes(OGAWA Hirofumi)
o   Update scsi blacklist table (Karsten H

The lack of specification (was Re: [LONG RANT] Re: Linux stifles innovation... )

[Mikulas Patocka]

> > > > I suspect part of the problem with commercial driver support on Linux is that
> > > > the Linux driver API (such as it is) is relatively poorly documented
> > > 
> > > In-kernel documentation, agreed.
> > > 
> > > _Linux Device Drivers_ is a good reference for 2.2 and below.
> > 
> > And do implementators of generic kernel functions and developers of device
> > drivers respect it? And how can they respect it if it's a commercial book?
> 
> _Linux Device Drivers_ documents the 2.2 (and previous) API, and
> thus refutes the argument that the kernel API is poorly documented.
> Since the publication of the book -succeeds- the publication of the
> APIs, your questions are not applicable.

What does it say about mark_buffer_dirty blocking or schedule and
TASK_[UN]INTERRUPTIBLE issues? If it says nothing, it is bad
documentation. If it says something, kernel developers do not respect it
and it is useless documentation...

> > > > and seems
> > > > to change almost on a week-by-week basis anyway. I've done my share of chasing
> > > > the current kernel revision with drivers that aren't part of the kernel tree:
> > > > by the time you update the driver to work with the current kernel revision,
> > > > there's a new one out, and the driver doesn't compile with it.
> > > 
> > > This is entirely in your imagination.  Driver APIs are stable across the
> > > stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18,
> > > 2.4.0 through whatever.
> > 
> > No true. Do you remember for example the mark_buffer_dirty change in some
> > 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was
> > changed so that it could block). 
> > 
> > Another example of bug that comes from the lack of specification is
> > calling of get_free_pages by non-running processes that caused lockups on
> > all kernels < 2.2.15. And it is still not cleaned up - see tcp_recvmsg(). 
> > 
> > Having documentation could prevent this kind of bugs.
> 
> Hardly.

Imagine that there is specification of mark_buffer_dirty. That
specification says that
1. it may not block
2. it may block

In case 1. implementators wouldn't change it to block in stable kernel
relese because they don't want to violate the specification.

In case 2. implementators of ext2 wouldn't assume that it doesn't block
even if it doesn't in current implementation.

In both cases, the bug wouldn't be created.

> No documentation is often -better- than bad documentation.

Of course. But good documentation is better than no documentation :-)

> > You don't need too
> > long texts, just a brief description: "this function may be called from
> > process/bh/interrupt context, it may/may not block, it may/may not be
> > called in TASK_[UN]INTERURPTIBLE state, it may take these locks."
> > 
> > With documentation developers would be able to change implementation of
> > kernel functions without the need to recheck all drivers that use them. 
> 
> Anytime you change implementation, you gotta check all drivers that use
> them.  I know, I'm one of the grunts that does such reviews and changes.

Anytime you change implementation of syscalls, you gotta check all
applications that use them ;-) Luckily not - because there is
specification and you can check that syscalls conform to the
specification, not apps. 

> > Saying "code is the specification" is not good.
> 
> I'm not arguing against documentation.  That is dumb.  But the code is
> ALWAYS canonical.  Not docs.

Let's see:

There are parts of code (1) that set state to TASK_[UN]INTERRUPTIBLE and
then call some other complex functions, like page fault handlers. (for
example tcp in 2.2)

There are parts of code (2) that call schedule to yield the process
assuming that the state is TASK_RUNNING. (including some drivers) 

Sooner or later will happen, that subroutine called from part (1) get
somehow to part (2) and the process locks up.


Now implementators of TCP will say: that driver is buggy. Everybody should
set state=TASK_RUNNING before calling schedule to yield the process. 

Implementators of driver will say: TCP is buggy - no one should call my
driver in TASK_[UN]INTERRUPTIBLE state.

Who is right? If there is no specification

Mikulas

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

Re: support for i815 audio ?

[Alan Cox]

> ac97_codec: AC97 Audio codec, vendor id1: 0x4144, id2: 0x5360 (Analog
> Devices AD1885)
> i810_audio: Codec refused to allow VRA, using 48Khz only.
> i810_audio: Found 1 audio device(s).
> 
> As seen above, playback is supported only for 48khz samples.

If the codec only supports 48Khz samples then so be it. We support that but
its up to the applications to honour the errors they get setting other
speeds.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

i82562ET LAN (i815) timeout/lockup with eepro100 driver

[Ionut Dumitrache]

The integrated LAN on Intel boards with i815 chipset 
apparently is not fully supported. In latest 2.2.x and 2.4.x,
with the EtherExpress Pro100 driver, after some network traffic,
it locks. The only way I can use the net again is either reboot,
or ifconfig eth0 down; ifconfig eth0 up. 
   I attached the syslog output;

The driver detects the chip as 82562EM although the mainboard
manual states that it has an integrated i82562ET chip.

Board: Intel D815EEA with onboard LAN, video,audio


eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V.
Savochkin <[EMAIL PROTECTED]> and others
eepro100.c: VA Linux custom, Dragan Stancevic <[EMAIL PROTECTED]>
2000/11/15
eth0: Intel PCI EtherExpress Pro100 82562EM, 00:03:47:48:7E:41, IRQ 11.
  Board assembly 00-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V.
Savochkin <[EMAIL PROTECTED]> and others
eepro100.c: VA Linux custom, Dragan Stancevic <[EMAIL PROTECTED]>
2000/11/15
---

Any idea why this happens?

P.S Please cc-me, I'm not subscribed to the list.


Feb 17 17:35:51 banica kernel: eepro100: wait_for_cmd_done timeout!
Feb 17 17:36:00 banica last message repeated 2 times
Feb 17 17:37:04 banica last message repeated 9 times
Feb 17 17:37:23 banica kernel: memory : c7a70720
Feb 17 17:37:23 banica kernel: memory : 
Feb 17 17:37:23 banica kernel: memory : c7a70760
Feb 17 17:39:27 banica kernel: eepro100: wait_for_cmd_done timeout!
Feb 17 17:39:37 banica last message repeated 7 times
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timed out: status 0050  0cf0 at 119493/119521 command 000c.
eth0: Tx ring dump,  Tx queue 119521 / 119493:
eth0: 0 600c.
eth0:   = 1 000ca000.
eth0: 2 000ca000.
eth0: 3 000ca000.
eth0: 4 000ca000.
eth0:  *  5 000c.
eth0: 6 000c.
eth0: 7 000c.
eth0: 8 200c.
eth0: 9 000c.
eth0:10 000c.
eth0:11 000c.
eth0:12 000c.
eth0:13 000c.
eth0:14 000c.
eth0:15 000c.
eth0:16 200c.
eth0:17 000c.
eth0:18 000c.
eth0:19 000c.
eth0:20 000c.
eth0:21 000c.
eth0:22 000c.
eth0:23 000c.
eth0:24 200c.
eth0:25 000c.
eth0:26 000c.
eth0:27 000c.
eth0:28 000c.
eth0:29 000c.
eth0:30 000c.
eth0:31 000c.
eth0: Printing Rx ring (next to receive into 161286, dirty index 161286).
eth0: 0 0001.
eth0: 1 0001.
eth0: 2 0001.
eth0: 3 0001.
eth0: 4 0001.
eth0: l   5 c001.
eth0:  *= 6 0001.
eth0: 7 0001.
eth0: 8 0001.
eth0: 9 0001.
eth0:10 0001.
eth0:11 0001.
eth0:12 0001.
eth0:13 0001.
eth0:14 0001.
eth0:15 0001.
eth0:16 0001.
eth0:17 0001.
eth0:18 0001.
eth0:19 0001.
eth0:20 0001.
eth0:21 0001.
eth0:22 0001.
eth0:23 0001.
eth0:24 0001.
eth0:25 0001.
eth0:26 0001.
eth0:27 0001.
eth0:28 0001.
eth0:29 0001.
eth0:30 0001.
eth0:31 0001.
eepro100: wait_for_cmd_done timeout!
-
Feb 17 17:49:39 banica kernel: eepro100: cmd_wait for(0xff80) timedout 
with(0xff80)!
Feb 17 17:50:12 banica last message repeated 29 times
Feb 17 17:50:53 banica last message repeated 8 times
Feb 17 17:52:26 banica last message repeated 4 times
Feb 17 17:52:37 banica kernel: eepro100: cmd_wait for(0xfff0) timedout 
with(0xfff0)!

support for i815 audio ?

[Ionut Dumitrache]

Should this onboard audio work with the i810 driver, in 2.2.x
and 2.4.x ?
  The card is detected as ICH2, although the driver supports only ICH.


Intel 810 + AC97 Audio, version 0.17, 17:24:05 Feb 17 2001
PCI: Increasing latency timer of device 00:fd to 64
i810: Intel ICH2 found at IO 0xef00 and 0xe800, IRQ 9
ac97_codec: AC97 Audio codec, vendor id1: 0x4144, id2: 0x5360 (Analog
Devices AD1885)
i810_audio: Codec refused to allow VRA, using 48Khz only.
i810_audio: Found 1 audio device(s).


As seen above, playback is supported only for 48khz samples.

 If this is supposed to happen, is there a plan to support this
version as well ?

P.S. Please cc-me, i'm not subscribed to this list.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: MTU and 2.4.x kernel

[kuznet]

Hello!

> We are implementing an IP stack.

Alan, please, tell me what is wrong. And we will repair this.

The implementation follows RFCs and even relaxes their requirements
in the cases, when they are far from reality.

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

where can I found AMD k6-2+ optimized gcc ?

[Thomas Lau]

anyone have idea?
I think someone was done before to optimizer AMD K6-2+ CPU in gcc patch.

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

Re: SO_SNDTIMEO: 2.4 kernel bugs

[kuznet]

Hello!

> You are right - our sendfile() implementation is broken. I have fixed it

Thank you!


> Investigation shows that the Linux network layer is behaving oddly. It
> seems that we are writing 4096 bytes to a socket. This proceeds in 4096
> byte chunks until the send buffer on the socket is full, and a 4096 byte
> write blocks. This blocking write is eventually interrupted by the
> timeout, and the write call returns.. wait for it.. 4096! This suggests
> there was socket space after all, and the call should not have blocked.

Wakeup does not happen until _enough_ (1/3 of snbuf) of space in sndbuf
is released, otherwise you will overschedule. So, as soon as
write() goes to sleep, it will sleep waiting until 1/3 is released.

If it is interrupted, it use all the released space immediately before exit.
Again, to make more for in this context. This can be even wrong and, probably,
we should return instantly with -EAGAIN/-EINTR/partial count, but it is most
likely suboptimal (though I have already changed this to instant return).
But this does not look essential from caller's viewpoint, except for
sendfile() of course. 8)

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