Oops in remove_shared_vm_struct

[Julian Anastasov]

Hello,

The kernel is 2.2.18pre22 SMP + reiserfs 3.5.27. The activity
is on the reiserfs partition. The oops is at the end of the message.

There are no ksymoops texts but after analyzing the oops, the problem
is here, in inline remove_shared_vm_struct():

EIP:0010:[<8011f5dc>]

0x8011f5cf : testl  %eax,%eax
0x8011f5d1 : je 0x8011f5fa 
0x8011f5d3 : testb  $0x8,0x15(%ebx)
0x8011f5d7 : je 0x8011f5e5 
0x8011f5d9 : movl   0x8(%eax),%eax
EIP:
0x8011f5dc : movl   0x8(%eax),%eax
0x8011f5df : incl   0x94(%eax)
0x8011f5e5 : movl   0x20(%ebx),%edx
0x8011f5e8 : testl  %edx,%edx
0x8011f5ea : je 0x8011f5f2 


The source code: file->f_dentry->d_inode->i_writecount++;

It seems file->f_dentry is 0?

The Call Trace is:
Call Trace: [<8011519b>] [<8011a152>] [<8011a326>] [<80109404>]

0x80115195 :  pushl  %ebx
0x80115196 :  call   0x8011f554 
0x8011519b :  pushl  %ebx

0x8011a14c :   pushl  %ebx
0x8011a14d :   call   0x8011517c 
0x8011a152 :   addl   $0x4,%esp

0x8011a318 :  movzbl 0x4(%esp,1),%eax
0x8011a31d :shll   $0x8,%eax
0x8011a320 :pushl  %eax
0x8011a321 :call   0x8011a048 
0x8011a326 :   movl   %esi,%esi

0x801093f7 :testb  $0x20,0x4(%ebx)
0x801093fb :jne0x80109460 
0x801093fd :call   *0x802774e4(,%eax,4)
0x80109404 :movl   %eax,0x18(%esp,1)



The oops:

Unable to handle kernel NULL pointer dereference at virtual address 8
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 
Oops: 
CPU:0
EIP:0010:[<8011f5dc>]
EFLAGS: 00010202
eax:    ebx: 83dda740   ecx: 83dda680   edx: 83dda7fc
esi: 2aab5000   edi: 90c770c0   ebp: 1000   esp: 83cabf7c
ds: 0018   es: 0018   ss: 0018
Process sleep (pid: 10579, process nr: 42, stackpage=83cab000)
Stack:  7e3c 83dda680 8011519b 90c770c0 90c770c0 90c770c0 8011a152
   90c770c0 83caa000 2ab4f6b0  7e3c  83caa000 8011a326
    80109404  2ab4b2e8 2ab4f6cc 2ab4f6b0  7e3c
Call Trace: [<8011519b>] [<8011a152>] [<8011a326>] [<80109404>]
Code: 8b 40 08 ff 80 94 00 00 00 8b 53 20 85 d2 74 06 8b 43 24 89


Regards

--
Julian Anastasov <[EMAIL PROTECTED]>

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

Re: include conventions /usr/include/linux/sys ?

[Mitchell Blank Jr]

H. Peter Anvin wrote:
> I suggested include/kernel and include/arch with include/linux and
> include/asm being reserved for the kernel interfaces (ioctl and their
> structures mostly.)

That sounds good.  One other refinement I would like to see is that
architecture specific but always present header files don't get used
directly in architecture-independant .c flies.  Some common examples of
this are  and   The problem is that often there
is some code that is identical between some or all of the archs.  Then
one of two things happen:
  * The code gets duplicated in many *.h files with all the bad things that
comde duplication causes - especially since they're all under seperate
maintainership
  * We have a big ugly conversion like what happened with 'asm/spinlock.h' ->
'linux/spinlock.h'

If we only have arch-independant *.c files only include things out of
 (which may, of course, include things in ) we can
avoid these conversions in the future and promote code reuse between the
architectures.

Also we should probably consider implementing a reasonalbe hierarchy to
the proposed  directory - for instance .

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

Re: Patch(?): pci_device_id tables for drivers/scsi in 2.4.0-test11

[Keith Owens]

On Thu, 23 Nov 2000 02:25:33 -0500, 
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>> #define PCITBL(v,d,sv,sd) \
>>  { PCI_VENDOR_ID_##v, PCI_DEVICE_ID_##d, \
>>PCI_VENDOR_ID_##sv, PCI_DEVICE_ID_##sd }
>
>* your macro fails for the 'ANY' case, because the proper macro is
>PCI_ANY_ID not PCI_{VENDOR,DEVICE}_ID_ANY.

It was just a suggestion.  Actually getting it working was left as an
exercise for the reader ;).

#define PCI_VENDOR_ID_ANY PCI_ANY_ID
#define PCI_DEVICE_ID_ANY PCI_ANY_ID

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Pär-Ola Nilsson]

> 540028982 = 0x20303036 = " 336"
> 540024880 = 0x20302030 = " 3 3"
> 170926128 = 0x0a302030 = "\n3 3"
>
These should be:
540028982 = 0x20303036 = " 006"
540024880 = 0x20302030 = " 0 0"
170926128 = 0x0a302030 = "\n0 0"

/Pär-Ola Nilsson


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

boot failure since 2.4.0-test10

[bregor]

  Others have reported similar problems, i.e.
  NOTHING after the "booting kernel message".

  My case is:
  Dual P-II Xeons, Intel 440GX chipset.
  Booting with loadlin or syslinux-1.50
  root-partition: /dev/hdc3
  Kernel freatures:  
CPU set to Pentium-II
No module support
No plug "n" play
Nothing unusual at all.  (I've tried many variations)

  I've built many kernels in the past and can still boot
  linux-2.4.0-test10.pre??? versions.

  Any advice would be most welcome.

  Roger Brown  bregor at anusf dot anu dot edu dot au

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

Re: Patch(?): pci_device_id tables for drivers/scsi in 2.4.0-test11

[Keith Owens]

[Adam J. Richter]
> +static struct pci_device_id atp870u_pci_tbl[] __initdata = {
> +{vendor: 0x1191, device: 0x8002, subvendor: PCI_ANY_ID, subdevice: PCI_ANY_ID},
> +{vendor: 0x1191, device: 0x8010, subvendor: PCI_ANY_ID, subdevice: PCI_ANY_ID},

It would make it easier to read and safer to type if you used a macro
to generate the fields.

#define PCITBL(v,d,sv,sd) \
 { PCI_VENDOR_ID_##v, PCI_DEVICE_ID_##d, \
   PCI_VENDOR_ID_##sv, PCI_DEVICE_ID_##sd }

#define PCITBL_END {0,0,0,0}

static struct pci_device_id foo_pci_tbl[] __initdata = {
  PCITBL(INTEL, INTEL_82437VX, ANY, ANY),
  PCITBL_END
}

Shorter is easier to read.  Using a prefix on the fields makes it much
harder for somebody to accidentally swap device and vendor codes.  If
they swap the parameters and type
  PCITBL(INTEL_82437VX, INTEL, ANY, ANY),
by mistake then they get compile errors, PCI_VENDOR_ID_INTEL_82437VX
and PCI_DEVICE_ID_INTEL are undefined.

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Andreas Dilger]

Mohammad A. Haque writes:
> I just got these while doing many compiles on my box 
> 
> Nov 23 00:40:06 viper kernel: EXT2-fs warning (device ide0(3,3)):
> ext2_unlink: Deleting nonexistent file (622295), 0
> Nov 23 00:40:06 viper kernel: = 1
> Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
> ext2_free_blocks: Freeing blocks not in datazone - block = 540028982,
> count = 1
> Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
> ext2_free_blocks: Freeing blocks not in datazone - block = 540024880,
> count = 1
> Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
> ext2_free_blocks: Freeing blocks not in datazone - block = 170926128,
> count = 1

I'm not sure where the nonexistent file comes from.  According to the
printf statement, you're trying to unlink a file with no links, so it
would be interesting to see if 622295 is a valid inode number (it
should be, or there would have been more error messages).  Doing

dumpe2fs -h /dev/hda3

may help to find out where this bogus inode came from.

These block numbers decode to ASCII data:

540028982 = 0x20303036 = " 336"
540024880 = 0x20302030 = " 3 3"
170926128 = 0x0a302030 = "\n3 3"


There were problems like this quite a while ago (block numbers that are
really ASCII data)...  I can't recall what the problem turned out to be
at that time.

I would suggest a full fsck to start with (you have probably already
done so).  If you haven't done a full fsck on this filesystem in a long
time, there is a chance the corruption was from the old kernel bug.

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

Re: [BUG] 2.2.1[78] : RTNETLINK lock not properly locking ?

[Willy Tarreau]

> It is linux-2.2, guy. 8) "threads" are not threaded there.
> 
> Semaphores (rtnl_lock, particularly) protects only areas, which
> are going to _schedule_ excplicitly or implicitly.

ok, thanks a lot Alexey, now I understand.

> Please, read comments. People used to consider comments as something
> decorative, but they are not. 

I did read them again and again, but you know, when there's something
you don't understand, sometimes you interprete things badly.

> Any questions?
not anymore, of course :-)

> Sorry...
> 
> /* NOTE: these locks are not interrupt safe, are not SMP safe,
>  * they are even not atomic. 8)8)8) ... and it is not a bug.
> etc.
> 
> Do you call this "very precautios"? 8)

I spoke about the first ones :)

thanks a lot, now I know how to proceed.

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

Re: ext2 filesystem corruptions back from dead? 2.4.0-test11

[Neil Brown]

On Thursday November 23, [EMAIL PROTECTED] wrote:
> I just got these while doing many compiles on my box 
> 
> Nov 23 00:40:06 viper kernel: EXT2-fs warning (device ide0(3,3)):
> ext2_unlink: Deleting nonexistent file (622295), 0
> Nov 23 00:40:06 viper kernel: = 1
> Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
> ext2_free_blocks: Freeing blocks not in datazone - block = 540028982,
> count = 1
> Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
> ext2_free_blocks: Freeing blocks not in datazone - block = 540024880,
> count = 1
> Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
> ext2_free_blocks: Freeing blocks not in datazone - block = 170926128,
> count = 1

Oh, good.  It's not just me and Tigran then.  I was at first blaming
my raid5 code for this, but if you get it and Tigran gets it (reported 
  http://boudicca.tux.org/hypermail/linux-kernel/2000week48/0257.html
) then it's probably not me.

And interesting data point:
 my raid5 reports when it get a read or write request on a block that
 it currently has an outstanding read or write request.  This report
 gets triggered just after a spate of "Freeing blocks not in ...zone"
 messages - there appear to be multiple write requests for the same
 block.
 This seems to suggest that something in the buffer cache is getting
 corrupted.

Now if only we had a reliable way to reproduce it, we could start a
binary search for the offending patch... but I can only reproduce it
on a patched kernel after several hours of performance testing.

NeilBrown


> 
> 
> What else should I provide?
> 
> [mhaque@viper mhaque]$ uname -a
> Linux viper.haque.net 2.4.0-test11 #6 Sun Nov 19 22:17:33 EST 2000 i686
> unknown
> 
> Nov 16 19:03:15 viper kernel: Uniform Multi-Platform E-IDE driver
> Revision: 6.31
> Nov 16 19:03:15 viper kernel: ide: Assuming 33MHz system bus speed for
> PIO modes; override with idebus=xx 
> Nov 16 19:03:15 viper kernel: PIIX4: IDE controller on PCI bus 00 dev 39 
> Nov 16 19:03:15 viper kernel: PIIX4: chipset revision 1 
> Nov 16 19:03:15 viper kernel: PIIX4: not 100%% native mode: will probe
> irqs later 
> Nov 16 19:03:15 viper kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS
> settings: hda:DMA, hdb:DMA 
> Nov 16 19:03:15 viper kernel: ide1: BM-DMA at 0xf008-0xf00f, BIOS
> settings: hdc:DMA, hdd:DMA 
> 
> Nov 16 19:03:15 viper kernel: hda: IBM-DJNA-371350, ATA DISK drive 
> Nov 16 19:03:15 viper kernel: hdb: CREATIVEDVD-ROM DVD2240E 12/24/97,
> ATAPI CDROM drive 
> Nov 16 19:03:15 viper kernel: hdc: Maxtor 82160D2, ATA DISK drive 
> Nov 16 19:03:15 viper kernel: hdd: IBM-DTLA-307045, ATA DISK drive 
> 
> -- 
> 
> =
> Mohammad A. Haque  http://www.haque.net/ 
>[EMAIL PROTECTED]
> 
>   "Alcohol and calculus don't mix. Project Lead
>Don't drink and derive." --Unknown  http://wm.themes.org/
>[EMAIL PROTECTED]
> =
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[patch] 2.4.0-test11 Elf64_Word incorrectly defined

[Keith Owens]

This patch needs to be reviewed before it goes to Linus.

The ELF 64 bit spec defines

NameSizeAlignment   Purpose
Elf64_Addr8   8 Unsigned program address
Elf64_Off 8   8 Unsigned file offset
Elf64_Half2   2 Unsigned medium integer
Elf64_Word4   4 Unsigned integer
Elf64_Sword   4   4 Signed integer
Elf64_Xword   8   8 Unsigned long integer
Elf64_Sxword  8   8 Signed long integer
unsigned char 1   1 Unsigned small integer

Note that Elf64_Word and Elf64_Sword are 4 bytes, even on 64 bit
machines.  elf.h from glibc 2.1.92 correctly defines these types.  The
kernel incorrectly defines them as 8 bytes.  There is code in
linux/kernel/elf.h that defines a mixture of Elf32 and Elf64 types in
the same structure because the kernel types are wrong, there is even
code that uses __s32 instead of Elf64_Word.

The type mismatch between kernel and userspace causes field
misalignments if you copy a user space definition into the kernel or
vice versa.  One fix is to use different type names for structure
definitions in userspace and kernel to get the same mapping, but that
is a major kludge.  Instead this patch corrects Elf64_[S]Word to 4
bytes bits and adds the correct Elf64_[S]Xword where it really needs 8
bytes.  It also replaces __s32 with Elf64_Word and fixes a few other
incorrect types.

Unless I made an error, the existing structure mappings have not been
affected.  The patch just corrects the mismatched or incorrect types so
the kernel, userspace and the ELF spec agree, it will make it easier
and safer to copy definitions between kernel and user space.

Index: 0-test11.1/include/linux/elf.h
--- 0-test11.1/include/linux/elf.h Tue, 31 Oct 2000 08:28:16 +1100 kaos 
(linux-2.4/Y/0_elf.h 1.4 644)
+++ 0-test11.1(w)/include/linux/elf.h Thu, 23 Nov 2000 16:05:20 +1100 kaos 
+(linux-2.4/Y/0_elf.h 1.4 644)
@@ -16,8 +16,10 @@ typedef __u64Elf64_Addr;
 typedef __u16  Elf64_Half;
 typedef __s16  Elf64_SHalf;
 typedef __u64  Elf64_Off;
-typedef __s64  Elf64_Sword;
+typedef __s32  Elf64_Sword;
-typedef __u64  Elf64_Word;
+typedef __u32  Elf64_Word;
+typedef __u64  Elf64_Xword;
+typedef __s64  Elf64_Sxword;
 
 /* These constants are for the segment types stored in the image headers */
 #define PT_NULL0
@@ -176,10 +178,10 @@ typedef struct dynamic{
 } Elf32_Dyn;
 
 typedef struct {
-  Elf64_Word d_tag;/* entry tag value */
+  Elf64_Sxword d_tag;  /* entry tag value */
   union {
-Elf64_Word d_val;
+Elf64_Xword d_val;
-Elf64_Word d_ptr;
+Elf64_Addr d_ptr;
   } d_un;
 } Elf64_Dyn;
 
@@ -370,7 +372,7 @@ typedef struct elf32_rel {
 
 typedef struct elf64_rel {
   Elf64_Addr r_offset; /* Location at which to apply the action */
-  Elf64_Word r_info;   /* index and type of relocation */
+  Elf64_Xword r_info;  /* index and type of relocation */
 } Elf64_Rel;
 
 typedef struct elf32_rela{
@@ -381,8 +383,8 @@ typedef struct elf32_rela{
 
 typedef struct elf64_rela {
   Elf64_Addr r_offset; /* Location at which to apply the action */
-  Elf64_Word r_info;   /* index and type of relocation */
+  Elf64_Xword r_info;  /* index and type of relocation */
-  Elf64_Word r_addend; /* Constant addend used to compute value */
+  Elf64_Sxword r_addend;   /* Constant addend used to compute value */
 } Elf64_Rela;
 
 typedef struct elf32_sym{
@@ -395,12 +397,12 @@ typedef struct elf32_sym{
 } Elf32_Sym;
 
 typedef struct elf64_sym {
-  Elf32_Word st_name;  /* Symbol name, index in string tbl (yes, Elf32) */
+  Elf64_Word st_name;  /* Symbol name, index in string tbl */
   unsigned charst_info;/* Type and binding attributes */
   unsigned charst_other;   /* No defined meaning, 0 */
   Elf64_Half st_shndx; /* Associated section index */
   Elf64_Addr st_value; /* Value of the symbol */
-  Elf64_Word st_size;  /* Associated symbol size */
+  Elf64_Xword st_size; /* Associated symbol size */
 } Elf64_Sym;
 
 
@@ -425,19 +427,19 @@ typedef struct elf32_hdr{
 
 typedef struct elf64_hdr {
   unsigned chare_ident[16];/* ELF "magic number" */
-  Elf64_SHalf e_type;
+  Elf64_Half e_type;
   Elf64_Half e_machine;
-  __s32 e_version;
+  Elf64_Word e_version;
   Elf64_Addr e_entry;  /* Entry point virtual address */
   Elf64_Off e_phoff;   /* Program header table file offset */
   Elf64_Off e_shoff;   /* Section header table file offset */
-  __s32 e_flags;
+  Elf64_Word e_flags;
-  Elf64_SHalf e_ehsize;
+  Elf64_Half e_ehsize;
-  Elf64_SHalf e_phentsize;
+  Elf64_Half e_phentsize;
-  Elf64_SHalf e_phnum;
+  Elf64_Half e_phnum;
-  Elf64_SHalf e_shentsize;
+  Elf64_Half e_shentsize;
-  Elf64_SHalf e_shnum;
+  Elf64_Half e_shnum;
-  Elf64_SHalf e_shstrndx;
+  Elf64_Half e_shstrndx;
 } Elf64_Ehdr;
 
 /* 

ext2 filesystem corruptions back from dead? 2.4.0-test11

[Mohammad A. Haque]

I just got these while doing many compiles on my box 

Nov 23 00:40:06 viper kernel: EXT2-fs warning (device ide0(3,3)):
ext2_unlink: Deleting nonexistent file (622295), 0
Nov 23 00:40:06 viper kernel: = 1
Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
ext2_free_blocks: Freeing blocks not in datazone - block = 540028982,
count = 1
Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
ext2_free_blocks: Freeing blocks not in datazone - block = 540024880,
count = 1
Nov 23 00:40:06 viper kernel: EXT2-fs error (device ide0(3,3)):
ext2_free_blocks: Freeing blocks not in datazone - block = 170926128,
count = 1


What else should I provide?

[mhaque@viper mhaque]$ uname -a
Linux viper.haque.net 2.4.0-test11 #6 Sun Nov 19 22:17:33 EST 2000 i686
unknown

Nov 16 19:03:15 viper kernel: Uniform Multi-Platform E-IDE driver
Revision: 6.31
Nov 16 19:03:15 viper kernel: ide: Assuming 33MHz system bus speed for
PIO modes; override with idebus=xx 
Nov 16 19:03:15 viper kernel: PIIX4: IDE controller on PCI bus 00 dev 39 
Nov 16 19:03:15 viper kernel: PIIX4: chipset revision 1 
Nov 16 19:03:15 viper kernel: PIIX4: not 100%% native mode: will probe
irqs later 
Nov 16 19:03:15 viper kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS
settings: hda:DMA, hdb:DMA 
Nov 16 19:03:15 viper kernel: ide1: BM-DMA at 0xf008-0xf00f, BIOS
settings: hdc:DMA, hdd:DMA 

Nov 16 19:03:15 viper kernel: hda: IBM-DJNA-371350, ATA DISK drive 
Nov 16 19:03:15 viper kernel: hdb: CREATIVEDVD-ROM DVD2240E 12/24/97,
ATAPI CDROM drive 
Nov 16 19:03:15 viper kernel: hdc: Maxtor 82160D2, ATA DISK drive 
Nov 16 19:03:15 viper kernel: hdd: IBM-DTLA-307045, ATA DISK drive 

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [NEW DRIVER] firestream

[Peter Samuelson]

[Patrick van de Lageweg]
> diff -u -r --new-file linux-2.4.0-test11.clean/drivers/atm/firestream.c 
>linux-2.4.0-test11.fs50+atmrefcount/drivers/atm/firestream.c

Since you are submitting in the form of a source patch, you ought to
include the relevent bits of

  drivers/atm/Makefile
  drivers/atm/Config.in
  Documentation/Configure.help

> +int loopback = 0;
> +int fs_debug = 0;
> +struct fs_dev *fs_boards = NULL;

Aside from the 'static' issue already mentioned, these should be left
uninitialized.  ('gcc -fassume-bss-zero' would be nice, but then again
in userspace it rarely matters.)

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

{PATCH} isofs stuff

[Andries . Brouwer]

After Linus' recent changes there were many complaints
about bugs in the isofs handling. Still, his code is fine.
I know about some things that still need to be done, and
already corrected two flaws yesterday or so, but people
sent me their isofs images and their problem was not caused
by anything I knew about, and behaved like a Heisenbug.

I never read assembler, but looking at the code produced
by gcc (2.95.2) it seemed peculiar, maybe an attempt to
optimize something combining the
if (filp->f_pos >= inode->i_size)
with the
while (filp->f_pos < inode->i_size)
slightly later.
After removal of the superfluous test
if (filp->f_pos >= inode->i_size)
return 0;
all suddenly worked well.

Below a working patch for which the isofs images I got
all are OK. (There is still a lot of silliness here -
superfluous parentheses, a rename of isofs_cmp to isofs_comp
in one file to avoid confusion with the isofs_cmp in another file..)

I have seen that there were discussions on the right compiler to use.
Is 2.95.2 wrong? Have other things to do tomorrow, so it will be
24 hours before I can look at this again.
Note: this is not yet a confirmed compiler bug - would have to check
more details. But after the indicated change all works for me.
Hope that the same is true for the people reporting problems.

Andries



diff -r -u linux-2.4.0-test11/linux/fs/isofs/dir.c 
linux-2.4.0-test11a/linux/fs/isofs/dir.c
--- linux-2.4.0-test11/linux/fs/isofs/dir.c Wed Nov 22 16:39:32 2000
+++ linux-2.4.0-test11a/linux/fs/isofs/dir.cThu Nov 23 04:07:56 2000
@@ -115,11 +115,8 @@
char *p = NULL; /* Quiet GCC */
struct iso_directory_record *de;
 
-   if (filp->f_pos >= inode->i_size)
-   return 0;
- 
-   offset = filp->f_pos & (bufsize - 1);
-   block = filp->f_pos >> bufbits;
+   offset = (filp->f_pos & (bufsize - 1));
+   block = (filp->f_pos >> bufbits);
high_sierra = inode->i_sb->u.isofs_sb.s_high_sierra;
 
while (filp->f_pos < inode->i_size) {
@@ -132,7 +129,8 @@
}
 
de = (struct iso_directory_record *) (bh->b_data + offset);
-   if (first_de) inode_number = (bh->b_blocknr << bufbits) + offset;
+   if (first_de)
+   inode_number = (bh->b_blocknr << bufbits) + offset;
 
de_len = *(unsigned char *) de;
 
@@ -207,7 +205,7 @@
map = 1;
if (inode->i_sb->u.isofs_sb.s_rock) {
len = get_rock_ridge_filename(de, tmpname, inode);
-   if (len != 0) {
+   if (len != 0) { /* may be -1 */
p = tmpname;
map = 0;
}
diff -r -u linux-2.4.0-test11/linux/fs/isofs/inode.c 
linux-2.4.0-test11a/linux/fs/isofs/inode.c
--- linux-2.4.0-test11/linux/fs/isofs/inode.c   Wed Nov 22 16:39:32 2000
+++ linux-2.4.0-test11a/linux/fs/isofs/inode.c  Thu Nov 23 02:15:46 2000
@@ -45,14 +45,14 @@
 
 static int isofs_hashi(struct dentry *parent, struct qstr *qstr);
 static int isofs_hash(struct dentry *parent, struct qstr *qstr);
-static int isofs_cmpi(struct dentry *dentry, struct qstr *a, struct qstr *b);
-static int isofs_cmp(struct dentry *dentry, struct qstr *a, struct qstr *b);
+static int isofs_compi(struct dentry *dentry, struct qstr *a, struct qstr *b);
+static int isofs_comp(struct dentry *dentry, struct qstr *a, struct qstr *b);
 
 #ifdef CONFIG_JOLIET
 static int isofs_hashi_ms(struct dentry *parent, struct qstr *qstr);
 static int isofs_hash_ms(struct dentry *parent, struct qstr *qstr);
-static int isofs_cmpi_ms(struct dentry *dentry, struct qstr *a, struct qstr *b);
-static int isofs_cmp_ms(struct dentry *dentry, struct qstr *a, struct qstr *b);
+static int isofs_compi_ms(struct dentry *dentry, struct qstr *a, struct qstr *b);
+static int isofs_comp_ms(struct dentry *dentry, struct qstr *a, struct qstr *b);
 #endif
 
 static void isofs_put_super(struct super_block *sb)
@@ -84,20 +84,20 @@
 static struct dentry_operations isofs_dentry_ops[] = {
{
d_hash: isofs_hash,
-   d_compare:  isofs_cmp,
+   d_compare:  isofs_comp,
},
{
d_hash: isofs_hashi,
-   d_compare:  isofs_cmpi,
+   d_compare:  isofs_compi,
},
 #ifdef CONFIG_JOLIET
{
d_hash: isofs_hash_ms,
-   d_compare:  isofs_cmp_ms,
+   d_compare:  isofs_comp_ms,
},
{
d_hash: isofs_hashi_ms,
-   d_compare:  isofs_cmpi_ms,
+   d_compare:  isofs_compi_ms,
}
 #endif
 };
@@ -173,7 +173,7 @@
  * Case insensitive compare of two isofs names.
  */
 static int
-isofs_cmpi_common(struct dentry *dentry,struct qstr *a,struct qstr *b,int ms)

Re: Linux 2.4.0test11-ac2

[Peter Samuelson]

[Alan Cox]
> Changes in 2.4.0test11ac2
> o Work arounds for broken Dell laptop APM (me)
>   | If you have an Inspiron 5000e please send 
>   | me the dmesg of this kernel booting. Thanks

Inspiron 5000, is this close enough?

Linux version 2.4.0-test11-ac2 (peter@kendall) (gcc version 2.95.2 2220 (Debian 
GNU/Linux)) #3 Wed Nov 22 21:09:37 CST 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009f800 @  (usable)
 BIOS-e820: 0800 @ 0009f800 (reserved)
 BIOS-e820: 00015000 @ 000eb000 (reserved)
 BIOS-e820: 03ef @ 0010 (usable)
 BIOS-e820: fc00 @ 03ff (ACPI data)
 BIOS-e820: 0400 @ 03fffc00 (ACPI NVS)
 BIOS-e820: 0008 @ fff8 (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009f800 for 4096 bytes.
On node 0 totalpages: 16368
zone(0): 4096 pages.
zone(1): 12272 pages.
zone(2): 0 pages.
mapped APIC to e000 (0000)
Kernel command line: vga=normal noinitrd BOOT_IMAGE=linux root=/dev/hda2 vga=1
Initializing CPU#0
Detected 448.060 MHz processor.
Console: colour VGA+ 80x50
Calibrating delay loop... 894.57 BogoMIPS
Memory: 62436k/65472k available (1056k kernel code, 2648k reserved, 80k data, 192k 
init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
CPU: Before vendor init, caps: 0383f9ff  , vendor = 0
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383f9ff   
CPU: After generic, caps: 0383f9ff   
CPU: Common caps: 0383f9ff   
CPU: Intel Pentium III (Coppermine) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfd9ae, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 2: assuming transparent
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
PCI: Found IRQ 11 for device 00:04.0
PCI: The same IRQ used for device 00:04.1
PCI: The same IRQ used for device 01:00.0
PCI: Cannot allocate resource region 4 of device 00:07.1
  got res[1090:109f] for resource 4 of Intel Corporation 82371AB PIIX4 IDE
Limiting direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1090-0x1097, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1098-0x109f, BIOS settings: hdc:DMA, hdd:pio
hda: FUJITSU MHK2120AT, ATA DISK drive
hdc: TOSHIBA CD-ROM XM-7002B, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 23579136 sectors (12073 MB) w/512KiB Cache, CHS=1559/240/63, UDMA(33)
Partition check:
 hda: hda1 hda2 hda3
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
LVM version 0.8final  by Heinz Mauelshagen  (15/02/2000)
lvm -- Driver successfully initialized
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP 
enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Linux PCMCIA Card Services 3.1.22
  options:  [pci] [cardbus] [pm]
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Yenta IRQ list 0698, PCI irq11
Socket status: 3068
Yenta IRQ list 0698, PCI irq11
Socket status: 3006
cs: cb_alloc(bus 6): vendor 0x10b7, device 0x5257
  got res[3400:347f] for resource 0 of PCI device 10b7:5257
  got res[1100:117f] for resource 1 of PCI device 10b7:5257
  got res[1180:11ff] for resource 2 of PCI device 10b7:5257
  got res[10c0:10c1] for resource 6 of PCI device 10b7:5257
PCI: Enabling device 06:00.0 ( -> 0003)
PCI: Found IRQ 11 for device 06:00.0
PCI: The same IRQ used for device 00:04.0
PCI: The same IRQ used for device 00:04.1
PCI: The same IRQ used for 

2.4.0-test11 reports CPU inconsistent variable MTRR settings

[Yusuf Goolamabbas]

Hi, I installed 2.4.0-test11 on a Dual P3-550 [Tyan Tiger 133 with
S1834 BIOS]. I updated the mobo with the latest bios found on Tyan's
website

http://www.tyan.com/support/html/b_tg_133.html

Reading dmesg, I found the following

mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs

Am not sure if this is going to lead to bad juju. Anybody else seeing
this on a similar mobo

Regards, Yusuf

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

Re: silly [< >] and other excess

[Ragnar Hojland Espinosa]

On Thu, Nov 23, 2000 at 12:26:30AM +, Russell King wrote:
> Albert D. Cahalan writes:
> > > Function entered at [] from []
> > > Function entered at [] from []
> > > Code: e51f2024 e5923000 (e5813000) e3a0 e51f3030
> > 
> > All those numbers get looked up. Keep going for another 25 lines too.
> 
> Oh, missed this one.  Here you're wrong again.  The numbers in [< >]
> should be looked up, and no others.  The code can look exactly like
> a kernel address.  In this case you definitely do NOT want to have
> them converted.

Okay.  How about just using some prefix to the hex number, such as '>'?
It'll still save plenty of space, and would be trivial changes for the
tools.  

-- 
/|  Ragnar Højland Freedom - Linux - OpenGL  Fingerprint  94C4B
\ o.O|   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for  104B78C56 B72F0822
   U chaos and madness await thee at its end."   hkp://keys.pgp.com

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

Re: silly [< >] and other excess

[Keith Owens]

On Wed, 22 Nov 2000 21:54:48 -0500 (EST), 
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
>Under NO circumstances should klogd or ksymoops mangle the
>original oops. The raw oops data MUST be completely preserved.
>It is a serious bug that this is not what currently happens.

ksymoops prints the original data followed by the decode, it is clean.

 klogd only prints the decoded data, often gets it wrong and
leaves garbage for ksymoops.  I did a patch to klogd a couple
of years ago and sent it to the maintainer but neither the sysklogd
maintainer nor the distributors seem to care. 

>The hard part of klogd/ksymoops is decoding the code bytes AFAIK.
>The rest is a just a cross between grep and ps -- you search and
>you do symbol lookups. I could throw it together in a few hours,
>minus the disassembly part.

Take a look at the code in ksymoops oops.c before you make rash
statements like that.  It has to handle _all_ architecture messages,
including cross arch debugging.

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

Re: silly [< >] and other excess

[Albert D. Cahalan]

Russell King writes:
> Albert D. Cahalan writes:

>> All these numbers get looked up.
>
> These numbers should NOT get looked up - if they are, then very
> useful information will be lost;

WOAH, STOP!!!  You say "lost"???

Under NO circumstances should klogd or ksymoops mangle the
original oops. The raw oops data MUST be completely preserved.
It is a serious bug that this is not what currently happens.

> they are not only references to
> kernel functions, but also kernel data and read only data within
> the kernel text segment.

1. this is harmless
2. this is useful (you might get a variable's name)

> The result will be a totally undeciperal
> garbage.

Nope. You get the unmolested oops and some symbol data.
If there isn't any symbol for 0x424a5149, so what? It is
no big deal to look up a few opcodes in the symbol table
by accident.

> Again, care to put the effort into klogd/ksymoops to handle the
> architecture special cases?

That would be trading one design flaw for another.

The hard part of klogd/ksymoops is decoding the code bytes AFAIK.
The rest is a just a cross between grep and ps -- you search and
you do symbol lookups. I could throw it together in a few hours,
minus the disassembly part.

Hey, anybody ever think about splitting the kernel message buffer
to be per-CPU or keeping interrupt context separate from process
context? Not that I've looked at it, but locking might be reduced.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4.0test11-ac2

[Stephen Rothwell]

Hi Alan,

Alan Cox <[EMAIL PROTECTED]> writes:
> 
> Changes in 2.4.0test11ac2
> 
> o APM update  (Stephen Rothwell)
> o Work arounds for broken Dell laptop APM (me)

Here is (in my opinion) a better patch.  It also means that we can
use apm as a module and have the Dell workaround work.

Most of this patch is a change of mind on my part after I posted
my previous patch ... (sorry about that).

This patch also make unloading of the apm module impossible is
someone has /proc/apm open ...  (BUG FIX)

Patch against 2.4.0test11ac2.

Cheers,
Stephen
-- 
Stephen Rothwell, Open Source Researcher, Linuxcare, Inc.
+61-2-62628990 tel, +61-2-62628991 fax 
[EMAIL PROTECTED], http://www.linuxcare.com/ 
Linuxcare. Support for the revolution.

diff -ruN 2.4.0-test11-ac2/arch/i386/kernel/apm.c 
2.4.0-test11-ac2-APM.2/arch/i386/kernel/apm.c
--- 2.4.0-test11-ac2/arch/i386/kernel/apm.c Thu Nov 23 10:29:19 2000
+++ 2.4.0-test11-ac2-APM.2/arch/i386/kernel/apm.c   Thu Nov 23 12:47:02 2000
@@ -338,7 +338,6 @@
 #endif
 static int debug;
 static int apm_disabled;
-static int dell_crap;  /* Set for broken 5000e */
 #ifdef CONFIG_SMP
 static int power_off;
 #else
@@ -564,7 +563,7 @@
 #ifdef ALWAYS_CALL_BUSY
clock_slowed = 1;
 #else
-   clock_slowed = (apm_info.bios_info.flags & APM_IDLE_SLOWS_CLOCK) != 0;
+   clock_slowed = (apm_info.bios.flags & APM_IDLE_SLOWS_CLOCK) != 0;
 #endif
return 1;
 }
@@ -675,15 +674,15 @@
 {
u32 eax;
 
-   if ((enable == 0) && (apm_info.bios_info.flags & APM_BIOS_DISENGAGED))
+   if ((enable == 0) && (apm_info.bios.flags & APM_BIOS_DISENGAGED))
return APM_NOT_ENGAGED;
if (apm_bios_call_simple(APM_FUNC_ENABLE_PM, APM_DEVICE_BALL,
enable, ))
return (eax >> 8) & 0xff;
if (enable)
-   apm_info.bios_info.flags &= ~APM_BIOS_DISABLED;
+   apm_info.bios.flags &= ~APM_BIOS_DISABLED;
else
-   apm_info.bios_info.flags |= APM_BIOS_DISABLED;
+   apm_info.bios.flags |= APM_BIOS_DISABLED;
return APM_SUCCESS;
 }
 #endif
@@ -696,6 +695,8 @@
u32 edx;
u32 dummy;
 
+   if (apm_info.get_power_status_broken)
+   return APM_32_UNSUPPORTED;
if (apm_bios_call(APM_FUNC_GET_STATUS, APM_DEVICE_ALL, 0,
, , , , ))
return (eax >> 8) & 0xff;
@@ -739,15 +740,15 @@
u32 eax;
 
if ((enable == 0) && (device == APM_DEVICE_ALL)
-   && (apm_info.bios_info.flags & APM_BIOS_DISABLED))
+   && (apm_info.bios.flags & APM_BIOS_DISABLED))
return APM_DISABLED;
if (apm_bios_call_simple(APM_FUNC_ENGAGE_PM, device, enable, ))
return (eax >> 8) & 0xff;
if (device == APM_DEVICE_ALL) {
if (enable)
-   apm_info.bios_info.flags &= ~APM_BIOS_DISENGAGED;
+   apm_info.bios.flags &= ~APM_BIOS_DISENGAGED;
else
-   apm_info.bios_info.flags |= APM_BIOS_DISENGAGED;
+   apm_info.bios.flags |= APM_BIOS_DISENGAGED;
}
return APM_SUCCESS;
 }
@@ -1333,19 +1334,6 @@
return 0;
 }
 
-/*
- * This is called by the DMI code when it finds an Inspiron 5000e
- * (aka compal reference board). We actually do the check by the BIOS
- * vendor name, version and serial so we can extend it to try and catch
- * non Dell stuff later.
- */
- 
-void apm_battery_horked(void)
-{
-   dell_crap = 1;
-}
-
-
 static int apm_get_info(char *buf, char **start, off_t fpos, int length)
 {
char *  p;
@@ -1362,7 +1350,7 @@
 
p = buf;
 
-   if ((smp_num_cpus == 1) && !dell_crap &&
+   if ((smp_num_cpus == 1) &&
!(error = apm_get_power_status(, , ))) {
ac_line_status = (bx >> 8) & 0xff;
battery_status = bx & 0xff;
@@ -1417,9 +1405,9 @@
 
p += sprintf(p, "%s %d.%d 0x%02x 0x%02x 0x%02x 0x%02x %d%% %d %s\n",
 driver_version,
-(apm_info.bios_info.version >> 8) & 0xff,
-apm_info.bios_info.version & 0xff,
-apm_info.bios_info.flags,
+(apm_info.bios.version >> 8) & 0xff,
+apm_info.bios.version & 0xff,
+apm_info.bios.flags,
 ac_line_status,
 battery_status,
 battery_flag,
@@ -1448,7 +1436,7 @@
current->tty = NULL;/* get rid of controlling tty */
 
if (apm_info.connection_version == 0) {
-   apm_info.connection_version = apm_info.bios_info.version;
+   apm_info.connection_version = apm_info.bios.version;
if (apm_info.connection_version > 

Problems with Olicom OC-3136/3137 (rev 2) and RedHat 7.0

[Tony Lill]

I seem to be having a problem with dropped packets using Olicom's
driver v 1.37 in the linux 2.2.16-22 kernel. The system is a Dell
Poweredge 2400 server with 2 CPUs. The rest of the ring is Olicom
microchannel cards on NCR UNIX. These are running with an MTU of 4088
as opposed to linux' 2000.

Has anyone run into problems using these cards (or even successes)?

I'd like to try increasing the MTU to match the rest of the hosts to
see if this helps, since the packets I can sniff seem to be mostly
frags. Unfortunately, the current MAX mtu compiled into the driver is
in the neigbourhood of 3200.

The driver sets the max MTU so that the data and overhead fit in a
single page (according to the comments). Can I increase this simply by
changing the buffer size, or are there complications when the sku goes
over 1 page?
--
Tony Lill, [EMAIL PROTECTED]
President, A. J. Lill Consultantsfax/data (519) 650 3571
539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461
--- http://www.ajlc.waterloo.on.ca/ 
"Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel-2.4.0-test11 crashed again; this time i send you the Oops-message

[Peter Samuelson]

[Albert D. Cahalan]
> The infamous LINK_FIRST infrastructure was sort of half-way done.

I disagree: it could handle all cases I could see that we might
reasonably care about.  I challenge anyone to come up with a
non-pathological case that could not be taken care of with a single
LINK_FIRST and/or a single LINK_LAST.

The worst I can think of is something like "all PCI drivers must come
before all ISA drivers" which would require listing all of one set or
the other.  But when you see a case like that, it often means "this
directory really needs to be split", because you have two different
classes of things in a single directory.

> It would be best to cause drivers with an unspecified link order
> to move around a bit, so that errors may be discovered more quickly.

That was the plan -- in 2.5.  (The 2.4 version did not disturb any
order at all, unless you explicitly put a LINK_FIRST declaration in the
individual makefile.)  Now that LINK_FIRST is officially dead, none of
this will probably happen at all.

> LINK_FIRST is pretty coarse. One would want a topological sort, or at
> least LINK_0 through LINK_9 _without_ anything else.

Too complex, no easy upgrade path (read: too different from status
quo), very little benefit over LINK_FIRST + LINK_LAST.  For the
topological sort in particular I'm interestested in how it's even
possible to do in a non-intrusive and maintainable way.

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

Patch(?): linux-2.4.0-test11/drivers/char pci_device_id tables

[Adam J. Richter]

The following patch adds a pci_device_id table and a
MODULE_DEVICE_TABLE delcaration to each remaining PCI driver
in linux-2.4.0-test11/drivers/char/.  I have used the named initializer
format for drivers that have only one or two PCI entries, initialize from
anonymous integers or where the unlabelled format would still
result in more than one line per entry in spite of any spacing
tricks.

I believe I have now posted patches that completes pci_device_id
table coverage for the following directories:

drivers/block
drivers/char
drivers/net
drivers/scsi
drivers/sound

Here is a summary of the number of files in other kernel
directories remaining to be updated (generated by counting the number
of files with "pci_find" and without "MODULE_DEVICE_TABLE" and removing
some obviously inapplicable cases):

drivers/acpi1
drivers/atm 6
drivers/ide 5
drivers/ieee13943
drivers/isdn/avmb1  3
drivers/isdn/eicon  2
drivers/isdn/hisax 13
drivers/isdn/hysdn  1
drivers/media/radio 1
drivers/media/video 4
drivers/mtd 1
drivers/net/tokenring   1
drivers/pcmcia  1
drivers/sbus/char   1
drivers/telephony   1
drivers/video   7

As you can see, we are converging on complete MODULE_DEVICE_TABLE
coverage for all PCI drivers.

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


--- linux-2.4.0-test11/drivers/char/agp/agpgart_be.cThu Nov 16 13:59:53 2000
+++ linux/drivers/char/agp/agpgart_be.c Wed Nov 22 17:28:09 2000
@@ -56,6 +56,18 @@
 EXPORT_SYMBOL(agp_enable);
 EXPORT_SYMBOL(agp_backend_acquire);
 EXPORT_SYMBOL(agp_backend_release);
+static struct pci_device_id specialix_pci_tbl[] __initdata = {
+  {
+   vendor: PCI_ANY_ID,
+   device: PCI_ANY_ID,
+   subvendor: PCI_ANY_ID,
+   subdevice: PCI_ANY_ID,
+   class: PCI_CLASS_BRIDGE_PCI << 8,
+   class_mask: 0x00,
+  },
+  { }  /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, specialix_pci_tbl);
 
 static void flush_cache(void);
 
--- linux-2.4.0-test11/drivers/char/applicom.c  Wed Jul 12 21:58:42 2000
+++ linux/drivers/char/applicom.c   Wed Nov 22 16:54:48 2000
@@ -72,6 +72,31 @@
"PCI2000PFB"
 };
 
+#if LINUX_VERSION_CODE < 0x20300 
+static struct pci_device_id mxser_pci_tbl[] __initdata = {
+   {
+ vendor: PCI_VENDOR_ID_APPLICOM,
+ device: PCI_DEVICE_ID_APPLICOM_PCIGENERIC,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID
+   },
+   {
+ vendor: PCI_VENDOR_ID_APPLICOM,
+ device: PCI_DEVICE_ID_APPLICOM_PCI2000IBS_CAN,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID
+   },
+   {
+ vendor: PCI_VENDOR_ID_APPLICOM,
+ device: PCI_DEVICE_ID_APPLICOM_PCI2000PFB,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID
+   },
+   { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, mxser_pci_tbl);
+#endif
+
 MODULE_AUTHOR("David Woodhouse & Applicom International");
 MODULE_DESCRIPTION("Driver for Applicom Profibus card");
 MODULE_PARM(irq, "i");
--- linux-2.4.0-test11/drivers/char/cyclades.c  Wed Nov 15 00:41:03 2000
+++ linux/drivers/char/cyclades.c   Wed Nov 22 18:19:49 2000
@@ -877,6 +877,20 @@
PCI_DEVICE_ID_CYCLOM_Z_Hi,  /* Z PCI > 1Mb */
0   /* end of table */
};
+
+static struct pci_device_id cyclades_pci_tbl[] __initdata = {
+  {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_Y_Lo, PCI_ANY_ID, PCI_ANY_ID},
+  {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_Y_Hi, PCI_ANY_ID, PCI_ANY_ID},
+  {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_4Y_Lo, PCI_ANY_ID, PCI_ANY_ID},
+  {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_4Y_Hi, PCI_ANY_ID, PCI_ANY_ID},
+  {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_8Y_Lo, PCI_ANY_ID, PCI_ANY_ID},
+  {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_8Y_Hi, PCI_ANY_ID, PCI_ANY_ID},
+  {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_Z_Lo, PCI_ANY_ID, PCI_ANY_ID},
+  {PCI_VENDOR_ID_CYCLADES, PCI_DEVICE_ID_CYCLOM_Z_Hi, PCI_ANY_ID, PCI_ANY_ID},
+  { }  /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, cyclades_pci_tbl);
+
 #endif
 
 static void cy_start(struct tty_struct *);
--- linux-2.4.0-test11/drivers/char/i810-tco.c  Sun Oct  1 19:45:29 2000
+++ linux/drivers/char/i810-tco.c   Wed Nov 22 16:55:39 2000
@@ -51,6 +51,17 @@
 #define PCI_DEVICE_ID_INTEL_82801AA_0  0x2410
 #endif
 
+static struct pci_device_id i810_tco_pci_tbl[] __initdata = {
+  {
+   vendor: 

Re: silly [< >] and other excess

[Andries . Brouwer]

> Thats because too many things get put on a line then.
> And because we do [] []  not   [][] ?

In the good old times we had  foo bar  for a total of 8*(8+1) = 72
positions. Now we have [] [] which takes 8*(8+1+4) = 104
positions. If you turned this into 6 items per line instead of 8,
it would certainly improve matters a bit.
Still..

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

Re: kernel-2.4.0-test11 crashed again; this time i send you the Oops-message

[Keith Owens]

On Wed, 22 Nov 2000 20:58:28 -0500 (EST), 
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
>The infamous LINK_FIRST infrastructure was sort of half-way done.
>
>It would be best to cause drivers with an unspecified link order
>to move around a bit, so that errors may be discovered more quickly.

The "other" list in LINK_FIRST is sorted by name.  It could be changed
to a random sort, probably based on a hash of size and mtime.  It would
be relatively expensive so would have to be restricted to a "exercise
the kernel" CONFIG option.

>LINK_FIRST is pretty coarse. One would want a topological sort,
>or at least LINK_0 through LINK_9 _without_ anything else.

There is no need for multiple LINK_n entries, the objects partition
neatly into three groups.  LINK_FIRST objects, in the order they are
defined.  The rest of the objects (object list - (LINK_FIRST +
LINK_LAST), in an undefined order.  LINK_LAST objects, in the order
they are defined.

If you can come up with a concrete link order example that cannot be
handled by a three partition model then I will listen.  Otherwise it is
just over engineering.

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

Re: Patch(?): pci_device_id tables for linux-2.4.0-test11/drivers/block

[Adam J. Richter]

>"Adam J. Richter" wrote:
>> Just to avoid duplication of effort, I am posting this preliminary
>> patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
>> drivers in linux-2.4.0-test11/drivers/block.  In response to input from
>> Christoph Hellwig, I have reduced my threshhold on using named initializers
>> to three entries, although I think that may be going to far, as I would
>> really like to keep the number of files that initialize the pci_device_id
>> arrays this way low so that changing struct pci_device_id remains feasible.

>*This* is the over-engineering attitude I was talking about.  The only
>reason why you are preferring named initializers is because
>pci_device_id MIGHT be changed.  And if it is changed, it makes the
>changeover just tad easier.

It is also much easier to spot an initialization bug, if, say,
a class is being initialized with a class_mask.  It also make the
code much more self-documenting.  I frequently have to bring up a copy
of include/linux/pci.h to decipher usb_devicde_id tables.

>For that, you ugly up the code and make it
>more difficult to maintain.

I think this makes it easier to maintain, especially by
driver authors who want to think more about their pet hardware than
how a generic kernel data structure is ordered.

Also bear in mind that once these drivers are ported to the
new PCI interface, many will use pci_device_id->driver_data, which
will cause all of the entries that are not in "field:value" form to
no longer fit on one line anyhow. 


>_I_ am one of the people that works on maintaining these random PCI
>drivers that no one gives a shit about.

I don't believe that using "field:value" format makes centralized
maintenance harder, but, if you find it that way, you should consider
the position of driver author a driver author who is more
knowledgeable about the hardware and has less repetitive need to
memorize the arrangement of an obscure kernel data structure.  The
__initdata vs __devinitdata for the pci_device_id tables is the same
sort of issue.  I believe that named initializers also make it easier
for developers whose focus is not on the central kernel data structures
to spot and fix bugs and develop new drivers, and that this is a more
scalable approach to kernel development.

In any case, if you want, I would be happy to send you patches
that include only the changes that do the initilization anonymously.
Until those appear in Linus's releases, I see it is a more definitely
positive contribution on my part to focus on writing pci_device_id
tables for other drivers that lack them.

Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test11 + ALSA 0.6pre1 version is OOPSing

[Keith Owens]

On Thu, 23 Nov 2000 02:49:27 +0100, 
Frank van de Pol <[EMAIL PROTECTED]> wrote:
>After upgrade to 2.4.0-test11 my copy of ALSA 0.6pre1 (cvs version) stopped
>working (causing OOPS on module load of snd-card-sbawe). I reverted back to
>2.4.0-test10 and verified that the problem does not exist in that version.
>
>Could any of the changes between 2.4.0-test10 and 2.4.0-test11 cause this
>behaviour??? 

2.4.0-test11 incorrectly handles module initialization when the
userspace struct module is smaller than the kernel struct module.

Index: 0-test11-pre6.1/kernel/module.c
--- 0-test11-pre6.1/kernel/module.c Wed, 08 Nov 2000 11:52:15 +1100 kaos 
(linux-2.4/j/28_module.c 1.1.2.1.1.1.7.1.1.1 644)
+++ 0-test11-pre6.1(w)/kernel/module.c Thu, 23 Nov 2000 10:22:26 +1100 kaos 
+(linux-2.4/j/28_module.c 1.1.2.1.1.1.7.1.1.1 644)
@@ -480,7 +480,9 @@ sys_init_module(const char *name_user, s
 
/* Ok, that's about all the sanity we can stomach; copy the rest.  */
 
-   if (copy_from_user(mod+1, mod_user+1, mod->size-sizeof(*mod))) {
+   if (copy_from_user((char *)mod+mod_user_size,
+  (char *)mod_user+mod_user_size,
+  mod->size-mod_user_size)) {
error = -EFAULT;
goto err3;
}


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

Re: kernel-2.4.0-test11 crashed again; this time i send you the Oops-message

[Albert D. Cahalan]

Peter Samuelson writes:
> [Neil Brown]

>> In drivers/md/Makefile, swap the order of "raid5.o xor.o" to be
>> "xor.o raid5.o", recompile, install, reboot.
>
> Don't forget the part about adding a comment saying that xor.c does in
> fact need to come before raid5.c.  This is the part that most likely
> will not happen, so that two months from now nobody will remember it
> and eventually it will trip us up again.
>
> That's one of the things that our infamous LINK_FIRST infrastructure
> would have done: pointed out special cases automatically so that even
> *without* a comment people would look at it and immediately know "there
> is *something* link-order-dependent here".  Oh well.

The infamous LINK_FIRST infrastructure was sort of half-way done.

It would be best to cause drivers with an unspecified link order
to move around a bit, so that errors may be discovered more quickly.

LINK_FIRST is pretty coarse. One would want a topological sort,
or at least LINK_0 through LINK_9 _without_ anything else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test11 + ALSA 0.6pre1 version is OOPSing

[Frank van de Pol]

After upgrade to 2.4.0-test11 my copy of ALSA 0.6pre1 (cvs version) stopped
working (causing OOPS on module load of snd-card-sbawe). I reverted back to
2.4.0-test10 and verified that the problem does not exist in that version.

I'm running an SMP kernel in case that matters. Similar problem was also
reported by another ALSA user (might be irrelevant, but he's also using
SMP). Problem exists after fresh rebuild of both linux and ALSA, and is
reproducable between reboots.

The (source) code at which the OOPS occurs looks sane. 

Could any of the changes between 2.4.0-test10 and 2.4.0-test11 cause this
behaviour??? 

Thanks,
Frank.




I'm using kernel 2.4.0-test11, and the 20 nov 2000, 23:15 cvs version.

Unable to handle kernel NULL pointer dereference at virtual address 
c885d054
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax:    ebx: 0020   ecx: c0237fa0   edx: c105a114
esi: 0008   edi:    ebp: c885e944   esp: c7b09ef4
ds: 0018   es: 0018   ss: 0018
Process modprobe (pid: 109, stackpage=c7b09000)
Stack: c885dc18 c885e79c c885da9c  0299 c885d000 c885db90 0007 
   c011c2fd c7b08000   bfffdf90 0007 c882a000 c882a000 
   c7b08000 0054 c7b09f60 c885e8e8 c1531000 17b0 000e c1532000 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] 
Code: 00 00 00 00 00 00 00 00 00 00 00 00 8b 7c 24 14 74 1a 89 f6 

>>EIP; c885d054 <[snd-card-sbawe]snd_legacy_auto_probe+0/34>   <=
Trace; c885dc18 <[snd-card-sbawe]alsa_card_sb16_init+88/fc>
Trace; c885e79c <[snd-card-sbawe]possible_ports.5+0/13>
Trace; c885da9c <[snd-card-sbawe]snd_sb16_probe_legacy_port+0/80>
Trace; c885d000 <[snd-sb16-dsp]__kstrtab_snd_sb16dsp_interrupt+16fa/174e>
Trace; c885db90 <[snd-card-sbawe]init_module+0/0>
Trace; c011c2fd 
Trace; c882a000 <[soundcore]__kstrtab_mod_firmware_load+10a6/10fa>
Trace; c882a000 <[soundcore]__kstrtab_mod_firmware_load+10a6/10fa>
Trace; c885e8e8 <[snd-card-sbawe]__module_description+14/4b3>
Trace; c885a000 <[snd-pcm]__kstrtab_snd_pcm_lib_fragment_bytes+1730/1784>
Trace; c885d060 <[snd-card-sbawe]snd_legacy_auto_probe+c/34>
Trace; c010a723 
Code;  c885d054 <[snd-card-sbawe]snd_legacy_auto_probe+0/34>   <=
 <_EIP>:   <=
Code;  c885d060 <[snd-card-sbawe]snd_legacy_auto_probe+c/34>
   c:   8b 7c 24 14   mov0x14(%esp,1),%edi
Code;  c885d064 <[snd-card-sbawe]snd_legacy_auto_probe+10/34>
  10:   74 1a je 2c <_EIP+0x2c> c885d080 
<[snd-card-sbawe]snd_legacy_auto_probe+2c/34>
Code;  c885d066 <[snd-card-sbawe]snd_legacy_auto_probe+12/34>
  12:   89 f6 mov%esi,%esi


[root@idefix /root]# cat /proc/modules
binfmt_misc 3688   0
nfs53056   1 (autoclean)
nfsd   46536   8 (autoclean)
lockd  38856   1 (autoclean) [nfs nfsd]
sunrpc 62104   1 (autoclean) [nfs nfsd lockd]
de4x5  42644   1 (autoclean)
serial 43556   0 (autoclean)
agpgart14468   0 (unused)
st 27624   0 (unused)
nls_iso8859-1   2840   4 (autoclean)
nls_cp437   4352   4 (autoclean)
vfat   11596   4 (autoclean)
fat32216   0 (autoclean) [vfat]
snd-card-sbawe  6460 (initializing)
snd-sb16-dsp6428   0 [snd-card-sbawe]
snd-pcm34168   0 [snd-sb16-dsp]
snd-sb16-csp   16248   0 [snd-card-sbawe]
snd-sb-common   7308   0 [snd-card-sbawe snd-sb16-dsp snd-sb16-csp]
snd-opl36496   0 [snd-card-sbawe]
snd-hwdep   3852   0 [snd-sb16-csp snd-opl3]
snd-timer   9816   0 [snd-pcm snd-opl3]
snd-emu800011268   0 [snd-card-sbawe]
snd-mpu401-uart 3416   0 [snd-card-sbawe snd-sb16-dsp]
snd-rawmidi10584   0 [snd-mpu401-uart]
snd-seq-device  4336   0 [snd-opl3 snd-emu8000 snd-rawmidi]
snd28376   0 [snd-card-sbawe snd-sb16-dsp snd-pcm
snd-sb16-csp snd-sb-common snd-opl3 snd-hwdep snd-timer snd-emu8000
snd-mpu401-uart snd-rawmidi snd-seq-device]
soundcore   3812   0 [snd]
usb-uhci   23404   0 (unused)
usbcore53056   1 [usb-uhci]


-- 
+ --- -- -  -   -- 
|Frank van de Pol  -o)
| [EMAIL PROTECTED]   /\\
| _\_v
|Linux - Why use Windows, since there is a door?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: LKCD from SGI

[Peter Samuelson]

[Matt D. Robinson]
> Any way we can standardize 'make install' in the kernel?  It's
> disturbing to have different install mechanisms per platform ...
> I can make the changes for a few platforms.

2.5 material, already on the todo list.

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

Re: Inspiron 5000e dmesg from test11-ac2

[Alan Cox]

> along the dmesg output from bootup on a Dell Inspiron 5000e.  I have

Thanks a lot

> for the fixes to APM, and if there is any more information I can
> provide that would be useful in getting full APM support on the 5000e
> please e-mail me directly, as I do not normally read linux-kernel.

Thats all the info I needed to verify - the BIOS version strings being right
and to add the dates. As I understand it Compal will be issuing Dell with a 
BIOS update for this board 'at some point'. When the BIOS upgrade is done the
apm battery data should be back

Alan

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

Inspiron 5000e dmesg from test11-ac2

[Jeff Lessem]

Per the request in the 2.4.0-test11-ac2 announcement I am sending
along the dmesg output from bootup on a Dell Inspiron 5000e.  I have
also included the output of cat /proc/apm.  Reading /proc/apm no longer
causes an oops, but the battery information is disabled.  Many thanks
for the fixes to APM, and if there is any more information I can
provide that would be useful in getting full APM support on the 5000e
please e-mail me directly, as I do not normally read linux-kernel.

Linux version 2.4.0-test11-ac2 (root@celis) (gcc version 2.95.2 2220 (Debian 
GNU/Linux)) #1 Wed Nov 22 15:22:30 MST 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009f800 @  (usable)
 BIOS-e820: 0800 @ 0009f800 (reserved)
 BIOS-e820: 00019800 @ 000e6800 (reserved)
 BIOS-e820: 13ef @ 0010 (usable)
 BIOS-e820: fc00 @ 13ff (ACPI data)
 BIOS-e820: 0400 @ 13fffc00 (ACPI NVS)
 BIOS-e820: 0008 @ fff8 (reserved)
On node 0 totalpages: 81904
zone(0): 4096 pages.
zone(1): 77808 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda1 mem=327616K
Initializing CPU#0
Detected 497.844 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 992.87 BogoMIPS
Memory: 320464k/327616k available (875k kernel code, 6764k reserved, 67k data, 168k 
init, 0k highmem)
Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0383f9ff  , vendor = 0
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383f9ff   
CPU: After generic, caps: 0383f9ff   
CPU: Common caps: 0383f9ff   
CPU: Intel Pentium III (Coppermine) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfd9ae, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
PCI: Found IRQ 11 for device 00:04.0
PCI: The same IRQ used for device 00:04.1
PCI: The same IRQ used for device 01:00.0
PCI: Cannot allocate resource region 4 of device 00:07.1
  got res[1080:108f] for resource 4 of Intel Corporation 82371AB PIIX4 IDE
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
DMI 2.3 present.
50 structures occupying 1487 bytes.
DMI table at 0x000EBDB0.
BIOS Vendor: Phoenix Technologies LTD
BIOS Version: A04
BIOS Release: 08/24/2000
BIOS strings suggest APM bugs, disabling battery reporting.
System Vendor: Dell Computer Corporation.
Product Name: Inspiron 5000e.
Version Revision B0.
Serial Number 123456789.
Board Vendor: Compal Electronics, Inc..
Board Name: 440BX Desktop Reference Platform.
Board Version: None.
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1080-0x1087, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1088-0x108f, BIOS settings: hdc:pio, hdd:pio
hda: IBM-DJSA-230, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 58605120 sectors (30006 MB) w/1874KiB Cache, CHS=3876/240/63, UDMA(33)
Partition check:
 hda: [PTBL] [3648/255/63] hda1 hda2 hda3 hda4
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 168k freed
Adding Swap: 128512k swap-space (priority -1)
ip_conntrack (2559 buckets, 20472 max)
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 262M
agpgart: Detected Intel 440BX chipset
agpgart: AGP aperture is 64M @ 0xe000
[drm] AGP 0.99 on Intel 440BX @ 0xe000 64MB
[drm] Initialized r128 1.0.0 2928 on minor 63
reiserfs: checking transaction log (device 03:03) ...
Using r5 hash to sort names
ReiserFS version 3.6.18
maestro: version 0.14 time 

Re: include conventions /usr/include/linux/sys ?

[Andi Kleen]

On Wed, Nov 22, 2000 at 02:35:43PM -0800, H. Peter Anvin wrote:
> Followup to:  <[EMAIL PROTECTED]>
> By author:"LA Walsh" <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Linus has mentioned a desire to move kernel internal interfaces into
> > a separate kernel include directory.  In creating some code, I'm wondering
> > what the name of this should/will be.  Does it follow that convention
> > would point toward a linux/sys directory?
> > 
> 
> I suggested include/kernel and include/arch with include/linux and
> include/asm being reserved for the kernel interfaces (ioctl and their
> structures mostly.)

It would also be useful to put *32 structures for 32->64bit conversion
in there (to prepare for a generic 32->64bit conversion layer in 2.5) 


-Andi

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

Re: i82365 PCI-PCMCIA bridge still not working in 2.4.0-test11

[Michel Salim]

Thanks for the patch... but it does not quite work. It applies cleanly, 
but upon booting the patched kernel, the machine freezes completely upon 
PCMCIA initialisation (it got to the point where the init script said 
'Loading modules' then nothing). CTRL+ALT+DEL does not work, either.

Anyone got a clue? Would love to help debug this if someone would just 
walk me through it.

Michel

David Woodhouse wrote:

> [EMAIL PROTECTED] said:
> 
>>  Installed kernel 2.4.0-test11 on my Debian Woody box today. Had no
>> problem apart from getting PCMCIA to work. I have a PCI-PCMCIA adapter
>>  on my desktop PC, using the Cirrus Logic CL6729 chipset;
> 
> 
> Linus got a bit carried away when stripping out all the CardBus support 
> from i82365, and took out the support for PCI-PCMCIA bridges too.
> 
> Try this snapshot of my development tree, or use lspci to find the IO 
> address of the device and specify that to the existing module.
> 

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

Re: kernel-2.4.0-test11 crashed again; this time i send you the Oops-message

[Peter Samuelson]

[Neil Brown]
> In drivers/md/Makefile, swap the order of "raid5.o xor.o" to be
> "xor.o raid5.o", recompile, install, reboot.

Don't forget the part about adding a comment saying that xor.c does in
fact need to come before raid5.c.  This is the part that most likely
will not happen, so that two months from now nobody will remember it
and eventually it will trip us up again.

That's one of the things that our infamous LINK_FIRST infrastructure
would have done: pointed out special cases automatically so that even
*without* a comment people would look at it and immediately know "there
is *something* link-order-dependent here".  Oh well.

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

Re: Patch(?): pci_device_id tables for linux-2.4.0-test11/drivers/block

[Russell King]

Adam J. Richter writes:
> + { PCI_VENDOR_ID_DEC,   PCI_DEVICE_ID_DEC_21285,   PCI_ANY_ID, PCI_ANY_ID},

No no no no no no no.

This "device" should be identified by either the class code OR the
subsystem device/vendor IDs.

By using "PCI_VENDOR_ID_DEC" and "PCI_DEVICE_ID_DEC_21285" you are referring
to a chip which can be:

1. A host bridge
2. A non-I2O add in card performing non-I2O functions
3. An I2O card
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: silly [< >] and other excess

[Alan Cox]

> The EIP is not pushed out of sight horizontally, but vertically.
> (Maybe you never saw a i386 oops. With [<>] the call trace takes
> twice as many lines (on a 25x80 screen) as without.)

Thats because too many things get put on a line then. And because we
do [] []  not   [][] ?

> 

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

Re: silly [< >] and other excess

[Andries . Brouwer]

From [EMAIL PROTECTED] Thu Nov 23 00:17:21 2000

Well, in my experience, values of PC (or EIP is x86 speak) rarely
appear over column 50 on the screen.  Therefore, removing them is
only going to save width, not height.

The EIP is not pushed out of sight horizontally, but vertically.
(Maybe you never saw a i386 oops. With [<>] the call trace takes
twice as many lines (on a 25x80 screen) as without.)

Also, have you considered that not every oops is formatted exactly
the same way on every architecture?

Do you propose to teach klogd and ksymoops every single oops format style?

It is a triviality.
Besides, the patch only modified i386.

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

Re: Was:Defective Red Hat Distribution poorly represents Linux,running with failed hardware?

[Richard.Reynolds]

To change the topic a bit.

Just an interesting thought, I realize that for every pro there is a
con. But what about implimenting in some kind of background "process"(for
lack of a better word right now), and probibly in a duplicate copy 
of the current kernel. Checks on the system memory and redundant
processing of known to be problems, I have not, been keeping up to date on
the kernel but I imagine that there is a map into memory that bad areas
either are or could be blocked as bad. 

While testing this at startup would not seem to be advisable, for many
reasons, including some pc's are not restarted often enough to catch such
errors in time, I think the table could be saved, and reloaded on startup,
there would also be the need to maintain this table, but I dont see that
as being unreasionable.

It only interests me in that I enjoy the stability of my Linux box,
vs. any of my Win98/nt/2k  boxes, and as someone that uses Linux I would
think such a kernel would be of interest in more quasi mission critical
installations. 

Just my 2cents
Richard Reynolds
[EMAIL PROTECTED]


On Tue, 21 Nov 2000, David Riley wrote:

> Jeff Epler wrote:
> > 
> > On Tue, Nov 21, 2000 at 04:08:26PM -0500, David Riley wrote:
> > > Windoze is not the only OS to handle bad hardware better than Linux.  On
> > > my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept
> > > causing random bus-type errors in Linux.  Same as when I accidentally
> > > (long story) overclocked the bus on the CPU.  I think that more
> > > tolerance for faulty hardware (more than just poorly programmed BIOS or
> > > chipsets with known bugs) is something that might be worth looking into.
> > 
> > And how do you propose to do that?
> > 
> > For instance, in some other operating systems having the top bit flip
> > in a pointer will cause silent use of incorrect data.  On Linux, this
> > will cause a signal 11.  Which do you prefer, bad results or an error
> > message?
> > 
> > Can you suggest a specific way in which Linux can react correctly to
> > e.g. flipped bits in RAM or cache which cannot be detected at the hardware
> > level?  Or maybe tell me how Linux can react correctly when an overclocked
> > CPU starts producing incorrect results for right shifts once every few
> > thousand instructions?
> 
> Hmm... Good point.  That would be hard to do.  On that note, there
> should be some prominent note on things like user manuals (though Linux
> users shouldn't need *manuals* :-) that notes that common crashes like
> signal 11 or "cc: internal failure" messages are generally caused by
> hardware problems.  That sort of thing would keep spurious complaints
> and error messages from inappropriate boards like this and on newbie
> boards where they belong (I'm not saying it was a bad complaint, but
> generally questions like "Why does RH 6.2, known to be stable on
> thousands of machines, not install of this machine where NT worked
> before?" belong on newbie boards and not as a flame of RedHat on the
> kernel board).  Unfortunately, most people who get these error messages
> don't read the manuals.  Besides, where would you put it in a manual?  I
> know that error codes are a great mystery among us on the MacOS (even
> those of us that have been using it for 16 years only know that Error 11
> is usually hardware and [1|2|3] are software) since they aren't really
> clearly and understandably documented in prominent user-land documentation.
> 
> By the way, I have no idea how to implement a suggestion like I had. 
> That's why I posted here.  If I had a clue how to do that any better
> than a useless, inefficient kludge, I would have done it myself and
> submitted a patch.  As much as I like the "do it yourself" model of
> development here, I think a lot of people might appreciate it if more
> experienced coders wouldn't jump down the throats of people who suggest
> a feature they can't do themselves yet.  I speak for myself, but I don't
> think I'll find a dearth of support for that opinion.
> 
> Thanks,
>   David
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 
> 

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

Re: [PATCH] Speed up interrupt entry

[Andi Kleen]

On Wed, Nov 22, 2000 at 11:24:16PM +0100, Kurt Garloff wrote:
> On Sat, Nov 18, 2000 at 11:20:09AM +0100, Andi Kleen wrote:
> > Index: include/asm-i386/hw_irq.h
> > ===
> > RCS file: /cvs/linux/include/asm-i386/hw_irq.h,v
> > retrieving revision 1.11
> > diff -u -u -r1.11 hw_irq.h
> > --- include/asm-i386/hw_irq.h   2000/05/16 16:08:15 1.11
> > +++ include/asm-i386/hw_irq.h   2000/11/18 10:33:48
> > @@ -103,9 +107,12 @@
> > "pushl %edx\n\t" \
> > "pushl %ecx\n\t" \
> > "pushl %ebx\n\t" \
> > -   "movl $" STR(__KERNEL_DS) ",%edx\n\t" \
>  ^^^
> > -   "movl %edx,%ds\n\t" \
> > -   "movl %edx,%es\n\t"
> > +   "movl $" STR(__KERNEL_DS),%eax\n\t" \
>  ^
> 
> You missed a ' "'

It contained a wrong hunk that was not supposed to be included.

> Apart from that it
> (a) makes sense
> (b) survived real world usage ...

Please back it out, the patch has some strange problems. I'm working
on a better one.



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

Re: silly [< >] and other excess

[Russell King]

Albert D. Cahalan writes:
> > Function entered at [] from []
> > Function entered at [] from []
> > Code: e51f2024 e5923000 (e5813000) e3a0 e51f3030
> 
> All those numbers get looked up. Keep going for another 25 lines too.

Oh, missed this one.  Here you're wrong again.  The numbers in [< >]
should be looked up, and no others.  The code can look exactly like
a kernel address.  In this case you definitely do NOT want to have
them converted.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: uname

[David Schwartz]

> Little question about 'uname'. Does it read data from kernel, /proc or
> get its data from other source ?

'strace' was made to answer questions like this.

DS

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

Linux driver for c-media cm8x38 ver 4.12 released

[cmedia]

Hi all,

For those who has C-Media 8338/8738-based sound card or as on-board
sound chip and need to work with Linux or BeOS, please download the beta
driver at http://members.home.net/puresoft/cmedia.html. The Linux driver
can work with kernel 2.2 and 2.4.

For questions, please e-mail to [EMAIL PROTECTED], thanks a lot !

Sincerely,
ChenLi Tien

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

Re: uname

[Alex Belits]

On Thu, 23 Nov 2000, J . A . Magallon wrote:

> Little question about 'uname'. Does it read data from kernel, /proc or
> get its data from other source ?

uname(1) utility calls uname(2) syscall.

-- 
Alex

--
 Excellent.. now give users the option to cut your hair you hippie!
  -- Anonymous Coward

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

*** ANNOUNCEMENT *** LVM 0.8.1 and LVM 0.9 available at www.sistina.com

[Heinz J. Mauelshagen]

Hi all,

Linux Logical Volume Manager 0.8.1 (this is 0.8final plus patches)
and 0.9 are available for download at www.sistina.com.

Please see further information below, test it and help us
to make an even better LVM for Linux :-)


Regards,
Heinz  -- The LVM guy --




The Logical Volume Manager (LVM) is a subsystem for online disk storage
management which has become a de-facto standard for storage management
under Linux.

LVM 0.8.1 update to 0.8final:
-
Supported on:
   - Linux 2.2.17
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New features:
   - Enhance pvmove(8) to operate on single physical volumes
   - Added support for multiple ext2 resize commands via e2fsadm(8)
   - Changed device specials to belong to group "disk"
 to accomodate backup software
   - Initial support for DEVFS

Bug Fixes:
 - LV on disk metadata offset faults
 - Housekeeping for the metadata backup history file
 - lvdisplay(8) and pvdisplay(8) option -c and -v handling


LVM 0.9:

Supported on:
   - Linux 2.4.0-test10 (and previous 2.4.0 test kernels)

New Features:
   - Persistent snapshots for logical volumes
   - Resizable snapshot logical volumes
   - API to request the usage rate of a snapshot logical volume
   - Integration with VFS to consistently mount ReiserFS filesystems
 on snapshots (VFS patch necessary)
   - Physical Volume and Volume Group UUID support
   - lv*(8) commands now use the Default Volume Group specifed in environment
 variable LVM_VG_NAME
   - A /proc/lvm/ directory hierarchy for use in parsing VGDA information
   - Initial support for DEVFS

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

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: silly [< >] and other excess

[Russell King]

Albert D. Cahalan writes:
> > c1e97ee0:c00251f8 c280007c
> > c1e97f00: 6013  c1e97fac c1e97f18  c0026194 c280006c c1e37000 c1e38000
> 
> [ --- CHOP --- ]
> 
> All these numbers get looked up.

These numbers should NOT get looked up - if they are, then very
useful information will be lost; they are not only references to
kernel functions, but also kernel data and read only data within
the kernel text segment.  The result will be a totally undeciperal
garbage.

Again, care to put the effort into klogd/ksymoops to handle the
architecture special cases?
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Modutils 2.3.14 / Kernel 2.4.0-test11 incompatibility

[Russell King]

Keith Owens writes:
> On Wed, 22 Nov 2000 23:12:25 + (GMT), 
> Russell King <[EMAIL PROTECTED]> wrote:
> >if (copy_from_user(mod+1, mod_user+1, mod->size-sizeof(*mod))) {
> 
> Using sizeof(struct module) is a nono in sys_init_module(), the code
> has to use the user space size.  Does this untested patch fix the
> problem?  Against 2.4.0-test11-pre6 but should fit test11.
> 
> 
> Index: 0-test11-pre6.1/kernel/module.c
> --- 0-test11-pre6.1/kernel/module.c Wed, 08 Nov 2000 11:52:15 +1100 kaos 
>(linux-2.4/j/28_module.c 1.1.2.1.1.1.7.1.1.1 644)
> +++ 0-test11-pre6.1(w)/kernel/module.c Thu, 23 Nov 2000 10:22:26 +1100 kaos 
>(linux-2.4/j/28_module.c 1.1.2.1.1.1.7.1.1.1 644)
> @@ -480,7 +480,9 @@ sys_init_module(const char *name_user, s
>  
>   /* Ok, that's about all the sanity we can stomach; copy the rest.  */
>  
> - if (copy_from_user(mod+1, mod_user+1, mod->size-sizeof(*mod))) {
> + if (copy_from_user((char *)mod+mod_user_size,
> +(char *)mod_user+mod_user_size,
> +mod->size-mod_user_size)) {
>   error = -EFAULT;
>   goto err3;
>   }

This also works!
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [2.2.17] oops in /proc/scsi/scsi

[Kurt Garloff]

Hi Matthias,

On Wed, Nov 22, 2000 at 02:06:18AM +0100, Matthias Andree wrote:
> I ran that script several times since it did not collect all devices,

Strange.

> and at one time, I got two oopsen that I decoded.
> * dc390 2.0e3

> Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found 
>in System.map.  Ignoring ksyms_base entry
> Unable to handle kernel NULL pointer dereference at virtual address 0052
> current->tss.cr3 = 05463000, %%cr3 = 05463000
> EIP:0010:[sr_finish+112/388]
> Process rescan-scsi-bus (pid: 18301, process nr: 122, stackpage=c267b000)
> Call Trace: [scan_scsis+491/1076] [common_interrupt+24/32] [scan_scsis+559/1076] 
>[get_new_inode+147/312] [vsprintf+720/764] [wake_up_process+64/76] [__wake_up+59/68] 
> Code: 80 48 52 20 a1 ac 99 2a c0 80 4c 18 16 08 a1 ac 99 2a c0 80 
> Using defaults from ksymoops -t elf32-i386 -a i386
> 
> Code;   Before first symbol
>  <_EIP>:
???

While 2.0e3 contains a bug that can cause an OOps inside the driver (just
use the echo "INQUIRY 0" >/proc/scsi/tmscsim/?), the normal bus rescanning
should not be able to trigger it. The above looks like the bug is occuring
somewhere else.
Having said this, I'd like to ask you to try 2.0e6 of the tmscsim driver and
check whether you are able to reproduce the bug.
Thanks!

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security

 PGP signature

[PATCH] Latest preemptible kernel (low latency) patch available

[Nigel Gamble]

MontaVista Software's latest preemptible kernel patch,
preempt-2.4.0-test11-1.patch.bz2, is now available in
ftp://ftp.mvista.com/pub/Area51/preemptible_kernel/
Here is an extract from the README file:

The patches in this directory, when applied to the corresponding
kernel source, will define a new configure option, 'Preemptable Kernel',
under the 'Processor type and features' section.  When enabled, and the
kernel is rebuilt it will be fully preemptable, subject to SMP lock
areas (i.e. it uses SMP locking on a UP to control preemptability).

The patch can only be enabled for ix86 uniprocessor platforms.
(Stay tuned for other platforms and SMP support.)

Notes for preempt-2.4.0-test11-1.patch
--

 - Updated to kernel 2.4.0-test11

Notes for preempt-2.4.0-test10-1.patch
--

The main changes between this and previous patches are:

 - Updated to kernel 2.4.0-test10
 - Long held spinlocks changed into mutex locks, currently implemented
   using semaphores.  (We are working on a fast, priority inheriting,
   binary semaphore implementation of these locks.)

The patch gives good results on Benno's Audio-Latency test
http://www.gardena.net/benno/linux/audio/, with maximum
latencies less than a couple of milliseconds recorded
using a 750MHz PIII machine.  However, there are still
some >10ms non-preemptible paths that are not exercised
by this test.

The worst non-preemtible paths are now dominated by the big
kernel lock, which we hope can be completely eliminated in 2.5
by finer grained locks.

(I will be at the Linux Real-Time Workshop in Orlando next week, and
may not be able to access my work email address ([EMAIL PROTECTED]),
which is why I'm posting this from my personal address.)

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

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

uname

[J . A . Magallon]

Hi everyone.

Little question about 'uname'. Does it read data from kernel, /proc or
get its data from other source ?

uname info page:
$ uname -a
Linux hayley 1.0.4 #3 Thu May 12 18:06:34 1994 i486

my system:

uname -a
Linux werewolf 2.2.18-pre23-vm #3 SMP Wed Nov 22 22:33:53 CET 2000 i686 unknown

uname -m (machine)
i686

uname -p (processor)
unknown

Seems like swapping machine-processor.
Perhaps it can be changed to uname -m give the info in get_cpu_vendor(),
and uname -p give the ix86.
Or if some utility relays on uname -m being ix86, make uname -p give cpu_vendor+
cpu_model.

--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer

Linux 2.2.18-pre23-vm #3 SMP Wed Nov 22 22:33:53 CET 2000 i686 unknown

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

Re: silly [< >] and other excess

[Albert D. Cahalan]

Russell King writes:
> [EMAIL PROTECTED] writes:

>> Of course. But since there is no information in [< >]
>> (their presence is syntactically determined, not semantically)
>> the tools you mention can be trivially patched to work without
>> this [< >] kludge. On the other hand, when the system panics
>> often klogd and similar nice programs do not run at all, and
>> hence are unable to do any good. All information available
>> is the information on the screen, and it is really a pity
>> to lose EIP and get a few parentheses instead.
>
> Well, in my experience, values of PC (or EIP is x86 speak) rarely
> appear over column 50 on the screen.  Therefore, removing them is
> only going to save width, not height.

Lots of useful data goes over column 80, causing even the innocent
little lines to scroll.

> Also, have you considered that not every oops is formatted exactly
> the same way on every architecture?  In fact, an oops on ARM looks
> like:

Hey, no problem.

> Unable to handle kernel NULL pointer dereference at virtual address 

That  is an 8-digit hex number within 25 lines of things
that would suggest a problem, so it gets looked up. The text itself
counts as a hint too. ("kernel NULL pointer")

> pgd = c1e9

Same thing. The "pgd" counts as a hint.

> *pgd = 01e94001, *pmd = 01e94001, *pte = 308b, *ppte = 300a

All 4 get looked up. Sure, they might not be symbols, but it is
better to err on the side of looking up extra junk.

> Internal error: Oops: 0

The "0" is only 1 digit, so don't look it up. The "Oops" is an
obvious hint to the userspace tool.

> CPU: 0
> pc : []lr : []
> sp : c1e97f08  ip : c1e97ec0  fp : c1e97f14
> r10: c1e96000  r9 : 0004  r8 : ffea
> r7 : 02029220  r6 : c1e37000  r5 : c280  r4 : 
> r3 : ef9f  r2 :   r1 :   r0 : 01db

Gee, obvious register names and plenty of 8-digit hex numbers.

> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> Control: 1E9117D  Table: 01E9117D  DAC: 0015
> Process insmod (pid: 9, stackpage=c1e97000)

When you see "stackpage", you have a hint.

> Stack:

Oh look, another hint.

> c1e97ee0:c00251f8 c280007c
> c1e97f00: 6013  c1e97fac c1e97f18  c0026194 c280006c c1e37000 c1e38000

[ --- CHOP --- ]

All these numbers get looked up.

> Backtrace:

That is another hint.

> Function entered at [] from []
> Function entered at [] from []
> Code: e51f2024 e5923000 (e5813000) e3a0 e51f3030

All those numbers get looked up. Keep going for another 25 lines too.

> where each number in [< >] should be looked up in System.map.  Do you
> propose to teach klogd and ksymoops every single oops format style?

That isn't needed. When in doubt, look up a hex address.
Of course any decent tool will retain the unmolested oops
and just add a list of symbol names afterward.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Wrong/old text in Documentation/cpqarray.txt

[Michael Zieger]

The documentation for this driver seems to be old in v2.4.0-test11-pre5:


You need to build a new kernel to use this device, even if you want to
use a loadable module.  

Apply the patch to a 2.2.x kernel:

# cd linux
# patch -p1 http://www.tux.org/lkml/

Re: [NEW DRIVER] firestream

[Jeff Garzik]

Jes Sorensen wrote:
> I think the most important issue is when doing header files to make
> sure they go with the driver code and not in include/linux unless
> there really is a reason to expose them to user space. No reason to
> export register definitions for Ethernet cards down there.

Agreed, that there are some headers that IMHO need to be moved out of
include/linux because they aren't used in userspace, and they aren't
public interfaces, nor shared across directories.

-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

netatalk refuses to start with ethernet aliasing

[Jeffrey Hundstad]

Hello,

I'm using Debian Potato with linux-2.2.18pre22.  This version of Potato
uses netatalk (1.4b2+asun2.1.3).

Everything works just fine if I have the two interfaces:

lo
eth0

As soon as I alias eth0 and have the interfaces:

lo
eth0
eth0:0
eth0:1
eth0:2

netatalk refuses to start and I receive this in syslog:

Nov 22 17:01:23 files atalkd[177]: restart (1.4b2+asun2.1.3)
Nov 22 17:01:24 files atalkd[177]: zip_getnetinfo for eth0
Nov 22 17:01:25 files atalkd[177]: zip gnireply from 275.241 (eth0 12)
Nov 22 17:01:26 files atalkd[177]: zip_packet configured eth0 from
275.241
Nov 22 17:01:26 files atalkd[177]: setifaddr: eth0:0: No such device
Nov 22 17:01:26 files atalkd[177]: difaddr(65280.0): No such device
Nov 22 17:01:26 files atalkd[177]: difaddr(0.0): No such device
Nov 22 17:01:26 files atalkd[177]: difaddr(0.0): No such device
Nov 22 17:01:26 files atalkd: difaddr(0.0): No such device
Nov 22 17:01:26 files last message repeated 2 times
Nov 22 17:01:27 files afpd[180]: main: atp_open: Cannot assign requested
address


My current work around is:

1. start the interfaces:
lo
eth0

2. start netatalk

3. create my eth0 aliases.

This works fine... but is a little strange.

Thanks for your help,

Jeffrey Hundstad
[EMAIL PROTECTED]
Minnesota State University, Mankato
http://www.mnsu.edu/jeffrey/



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

Re: [NEW DRIVER] firestream

[Jes Sorensen]

> "Rogier" == Rogier Wolff <[EMAIL PROTECTED]> writes:

Rogier> Mitchell Blank Jr wrote:
>> First, I'd like to make a couple points about driver style that I'm
>> trying to move towards with the ATM drivers.  You're free to take
>> them or leave them, but I want to eventually move the tree in this
>> direction.  * I don't like header files that define the registers
>> of the chip - since the header file is only included in the
>> driver's .c file you might as well just put the definitions there
>> (unless, of course, there is good reason to think that the
>> registers will be used in multiple drivers - unlikely in this case)
>> Having a seperate header file just serves to hamper searching
>> around the driver and cluttering the directory.

Rogier> I disagree vehemently.

Rogier> The header file should have 'static things' that for example a
Rogier> competing driver for the same chip could also use. The "driver
Rogier> defines" should theoretically be in a separate file. This
Rogier> rarely happens.

I guess this boils down to personal preference, I like to stick
register definitions in a seperate file as well.

I think the most important issue is when doing header files to make
sure they go with the driver code and not in include/linux unless
there really is a reason to expose them to user space. No reason to
export register definitions for Ethernet cards down there.

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

Re: silly [< >] and other excess

[Albert D. Cahalan]

Keith Owens writes:
> Christian Gennerat <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] a =E9crit :

>>>  I also left something else
>>> that always annoyed me: valuable screen space (on a 24x80 vt)
>>> is lost by these silly [< >] around addresses in an Oops.
>>> They provide no information at all, but on the other hand
>>> cause loss of information because these lines no longer
>>> fit in 80 columns causing line wrap and the loss of the
>>> top of the Oops.]

> You just broke ksymoops.

You can fix it. Keeping useful info on the screen is more important.

> Removing the [< >] is a bad idea, they are
> one of the few things that identifies the addresses in the log,
> otherwise they just look like hex numbers.  ksymoops has to scan log
> files which can contain anything and somehow pick out the interesting
> lines, you need some identifier on the lines.

If you see register names followed by hex numbers, you have
some debug data. Scan forward and backward 25 lines, grabbing
all 8-digit and 16-digit hex numbers. Sort the numbers, then
look up all of them.

Crude solutions don't break as often as fancy solutions.

> There should be no need to restrict the number of lines printed, it is
> limited by the top of the kernel stack.  If there are more than 32
> trace entries on the stack then they should be printed.

It could fill the screen. There is an expansion of 4-to-13 when
using the silly brackets, and a PC stack can be 6 or 7 kB long,
or perhaps many megabytes due to stack overflow. The standard
VGA screen only allows 4000 bytes of data.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Alan Cox's e-mail address is hosed?

[Richard Gooch]

Jes Sorensen writes:
> > "Miles" == Miles Lane <[EMAIL PROTECTED]> writes:
> 
> Miles> I attempted to reply to a message from Alan and got the
> Miles> following response.
> 
> No it isn't, Alan uses ORBS and you are obviously black listed there
> (www.orbs.org).
> 
> This one seems to come up every now and then, and always turns into a
> flamewar. Now it's Alan's choice so if you want to argue over this,
> take it somewhere else please.
> 
> Who is maintaining the FAQ? this might be a good idea to add to
> under the mailing list section.

[Raises hand] Send me a patch. And see section 5.14, which has been
there for some time.

BTW: you never did get around to sending me a patch for why C++ in the
kernel was evil ;-)

Regards,

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

Re: Modutils 2.3.14 / Kernel 2.4.0-test11 incompatibility

[Keith Owens]

On Wed, 22 Nov 2000 23:12:25 + (GMT), 
Russell King <[EMAIL PROTECTED]> wrote:
>if (copy_from_user(mod+1, mod_user+1, mod->size-sizeof(*mod))) {

Using sizeof(struct module) is a nono in sys_init_module(), the code
has to use the user space size.  Does this untested patch fix the
problem?  Against 2.4.0-test11-pre6 but should fit test11.


Index: 0-test11-pre6.1/kernel/module.c
--- 0-test11-pre6.1/kernel/module.c Wed, 08 Nov 2000 11:52:15 +1100 kaos 
(linux-2.4/j/28_module.c 1.1.2.1.1.1.7.1.1.1 644)
+++ 0-test11-pre6.1(w)/kernel/module.c Thu, 23 Nov 2000 10:22:26 +1100 kaos 
+(linux-2.4/j/28_module.c 1.1.2.1.1.1.7.1.1.1 644)
@@ -480,7 +480,9 @@ sys_init_module(const char *name_user, s
 
/* Ok, that's about all the sanity we can stomach; copy the rest.  */
 
-   if (copy_from_user(mod+1, mod_user+1, mod->size-sizeof(*mod))) {
+   if (copy_from_user((char *)mod+mod_user_size,
+  (char *)mod_user+mod_user_size,
+  mod->size-mod_user_size)) {
error = -EFAULT;
goto err3;
}

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

Re: silly [< >] and other excess

[Russell King]

[EMAIL PROTECTED] writes:
> From [EMAIL PROTECTED] Wed Nov 22 19:20:52 2000
> They provide no information to the human reader, but they tell klogd
> (and other tools) that the enclosed value is a kernel address that
> should be looked up in the System.map file and decoded into name +
> offset.
> 
> Of course. But since there is no information in [< >]
> (their presence is syntactically determined, not semantically)
> the tools you mention can be trivially patched to work without
> this [< >] kludge. On the other hand, when the system panics
> often klogd and similar nice programs do not run at all, and
> hence are unable to do any good. All information available
> is the information on the screen, and it is really a pity
> to lose EIP and get a few parentheses instead.

Well, in my experience, values of PC (or EIP is x86 speak) rarely
appear over column 50 on the screen.  Therefore, removing them is
only going to save width, not height.

Also, have you considered that not every oops is formatted exactly
the same way on every architecture?  In fact, an oops on ARM looks
like:

Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c1e9
*pgd = 01e94001, *pmd = 01e94001, *pte = 308b, *ppte = 300a
Internal error: Oops: 0
CPU: 0
pc : []lr : []
sp : c1e97f08  ip : c1e97ec0  fp : c1e97f14
r10: c1e96000  r9 : 0004  r8 : ffea
r7 : 02029220  r6 : c1e37000  r5 : c280  r4 : 
r3 : ef9f  r2 :   r1 :   r0 : 01db
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 1E9117D  Table: 01E9117D  DAC: 0015
Process insmod (pid: 9, stackpage=c1e97000)
Stack:
c1e97ee0:c00251f8 c280007c
c1e97f00: 6013  c1e97fac c1e97f18  c0026194 c280006c c1e37000 c1e38000
c1e97f20: c01f3680 0060 c011d48c c2800060  5e00   
c1e97f40:         
c1e97f60:         
c1e97f80:  bfffec64 02021928 6010  c280 c00169e4 0080 0201bbe8
c1e97fa0:  c1e97fb0 c0016860 c0025acc  bfffec64 c001bb54 0201bbe8 02029220
c1e97fc0:  0038 bfffec64 02021928  02019f10 c280 5e00 0201bbe8
c1e97fe0: 0201bbe8 be60 400e4c90 bfffec28  020031e8 400e4c9c 6010 0201bbe8
Backtrace:
Function entered at [] from []
Function entered at [] from []
Code: e51f2024 e5923000 (e5813000) e3a0 e51f3030

where each number in [< >] should be looked up in System.map.  Do you
propose to teach klogd and ksymoops every single oops format style?

If no, then don't make this change to the kernel.  If yes, then you've
got a big job on your hands.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Modutils 2.3.14 / Kernel 2.4.0-test11 incompatibility

[Russell King]

Hi,

There appears to be an incompatibility between modutils 2.3.14 and kernel
2.4.0-test11.

This occurs because modutils knows only of an 84-byte struct module, but
the kernel knows about a 96-byte struct module.

Unfortunately, the kernel "forgets" about the 12 bytes, which are part of
the loading module text because in sys_init_module():

if ((error = get_user(mod_user_size, _user->size_of_struct)) != 0)
goto err1;
/* mod_user_size == 84 */
/* ... */
error = copy_from_user(mod, mod_user, mod_user_size);
/* we copy byte 0 to byte 83 of struct module */
/* ... */
if (copy_from_user(mod+1, mod_user+1, mod->size-sizeof(*mod))) {
/* we copy byte 96 to  */

And guess what?  We missed bytes 84 to 95!  Oh dear, the result is one
of these:

Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c1e9
*pgd = 01e94001, *pmd = 01e94001, *pte = 308b, *ppte = 300a
Internal error: Oops: 0
CPU: 0
pc : []lr : []
sp : c1e97f08  ip : c1e97ec0  fp : c1e97f14
r10: c1e96000  r9 : 0004  r8 : ffea
r7 : 02029220  r6 : c1e37000  r5 : c280  r4 : 
r3 : ef9f  r2 :   r1 :   r0 : 01db
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 1E9117D  Table: 01E9117D  DAC: 0015
Process insmod (pid: 9, stackpage=c1e97000)
Stack:
c1e97ee0:c00251f8 c280007c
c1e97f00: 6013  c1e97fac c1e97f18  c0026194 c280006c c1e37000 c1e38000
c1e97f20: c01f3680 0060 c011d48c c2800060  5e00   
c1e97f40:         
c1e97f60:         
c1e97f80:  bfffec64 02021928 6010  c280 c00169e4 0080 0201bbe8
c1e97fa0:  c1e97fb0 c0016860 c0025acc  bfffec64 c001bb54 0201bbe8 02029220
c1e97fc0:  0038 bfffec64 02021928  02019f10 c280 5e00 0201bbe8
c1e97fe0: 0201bbe8 be60 400e4c90 bfffec28  020031e8 400e4c9c 6010 0201bbe8
Backtrace:
Function entered at [] from []
Function entered at [] from []
Code: e51f2024 e5923000 (e5813000) e3a0 e51f3030

because both r2 and r1 are loaded from the first two words of module text
which forgot to be copied.  Therefore, please reverse the following change
in 2.4.0-test11 because it is NOT a security problem but a much needed
subtlety:


-   error = copy_from_user(mod, mod_user, sizeof(struct module));
+   error = copy_from_user(mod, mod_user, mod_user_size);
if (error) {

Better still, place a comment before it describing why it is so!
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] some cleanup in vgacon.c

[James Simmons]

>   this is a newer cleaning patch for vgacon.c against test11.
> It includes the one I sent a couple of days ago.Could you check this too
> and if OK send it to Linus?Unless of course it violates the code-freeze
> policy :-)

The changes look fine except I have to question the *_scroll_enable
changes. Could someone with a ia64 box with SoftSDV  similator please test
this patch? 

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

Re: [NEW DRIVER] firestream

[Rogier Wolff]

Mitchell Blank Jr wrote:
> First, I'd like to make a couple points about driver style that I'm trying
> to move towards with the ATM drivers.  You're free to take them or leave
> them, but I want to eventually move the tree in this direction.
>   * I don't like header files that define the registers of the chip - since
> the header file is only included in the driver's .c file you might as
> well just put the definitions there (unless, of course, there is good
> reason to think that the registers will be used in multiple drivers -
> unlikely in this case)  Having a seperate header file just serves to
> hamper searching around the driver and cluttering the directory.

I disagree vehemently. 

The header file should have 'static things' that for example a
competing driver for the same chip could also use. The "driver
defines" should theoretically be in a separate file. This rarely
happens. 

For SX I have an "sxboard.h" with the defines that are in the HARDWARE
for the board. An "sxwindow.h" with the defines that belong with the
shared memory window that the firmware for the card defines, and an
sx.h which defines the parameters and datastructures of the driver.

This is how I like it.

>   * Please use the new PCI interface for new drivers
>   (i.e. MODULE_DEVICE_TABLE and all that)

It's on our todo list to learn how to do this. OK. We'll figure it out. 
 
> These should be defined static.

Agreed. Sorry about this. Lots of cases. 

Quick scan: I agree with you in almost all cases. Will do!

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)

[Heinz J. Mauelshagen]

On Wed, Nov 22, 2000 at 04:27:51PM -0500, Brian Kress wrote:
> "Heinz J. Mauelshagen" wrote:
> > 
> > On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
> > >   Question about /proc/partitions and LVM.  LVM devices in
> > > /proc/partitions currently show up as lvma, lvmb, etc, depending on
> > > their device number.  This breaks things like mount by filesystem
> > > name.  Back when LVM existed as a patch, I believe there was some
> > > support in fs/partitions/check.c for showing the proper name for
> > > the device (something like /).
> > 
> > Yes.
> > It actually was /.
> > 
> > Linus didn't accept it though.
> > 
> > The code is still available in case he changes his mind.
> 
>   Yes, I can see that now looking through lvm.c.  (LVM_HD_NAME)
> I'm guessing why he didn't take it is the minor hack of adding a
> function pointer to genhd.c as a special case just for LVM.  
>   A general solution to this problem would be nice.  The
> big switch statement in disk_name in fs/paritions/check.c is kind
> of ugly as it has generic code have to know things about specific
> drivers.  

Yep.

>   How's this for an idea to generalize this.  Put a function
> pointer in the gendisk structure for a specific function to call
> for disk_name for disks for that gendisk.

Sounds resonable to me.

> That way, LVM gets its
> /, IDE gets its two disks per major (special cased
> right now), all the other special cases get what they need and future
> drivers can call their devices whatever they like without touching
> this file.  Makes the whole thing more modular.  Make a NULL for 
> this function default to the old a, b, etc.
>   What to people think about this?  If this sounds reasonable
> I can come up with a patch.

Very good. I'ld appreciate it.

> 
> 
> Brian Kress
> [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> 
> 
> 
> > 
> > >   Are their any plans for something like this to be added
> > > or is their a reason it was taken out?
> > >
> > >
> > >   BTW, 2.4.0-test11 is the first "perfect" kernel for me.  It
> > > finally has everything I use working correctly.  (well, with a
> > > small raid5 patch, anyway).
> > >
> > >
> > > Brian Kress
> > > [EMAIL PROTECTED]
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [EMAIL PROTECTED]
> > > Please read the FAQ at http://www.tux.org/lkml/
> > 
> > --
> > 
> > Regards,
> > Heinz  -- The LVM guy --
> > 
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > 
> > Heinz Mauelshagen Sistina Software Inc.
> > Senior Consultant/Developer   Bartningstr. 12
> >   64289 Darmstadt
> >   Germany
> > [EMAIL PROTECTED]   +49 6151 7103 86
> >FAX 7103 96
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-- 

Regards,
Heinz  -- The LVM guy --

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

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: linux-2.2.18-pre19 asm/delay.h problem?

[Alan Cox]

> > |> > > #define __bad_udelay() panic("Udelay called with too large a constant")
> > |> 
> > |> Can't we change that to :
> > |> #error "Udelay..."
> > 
> > No.
> 
> ?? I think I'm missing something here.

preprocessor stuff is done too early for this

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

Re: Alan Cox's e-mail address is hosed?

[Gary E. Miller]

Yo Miles!

Well I see 216.200.176.7 in ORBS:

$ chk-rly 216.200.176.7
rbl.maps.vix.com =>
rss.maps.vix.com =>
dul.maps.vix.com =>
relays.orbs.org => 127.0.0.4
relays.orbs.org => untestable - above.net has  multiple open relays and has blocked 
the ORBS tester.
outputs.orbs.org =>

RGDS
GARY
---
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Thu, 23 Nov 2000, Miles Lane wrote:

> Okay, please explain why ORBS tells me it does *not*
> identify my ISP's SMTP server as an open relay?
>
> mail.megapathdsl.net = 216.200.176.7

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

[PATCH] for /proc/cpuinfo MHz

[Kohtala Marko]

cat /proc/cpuinfo shows like this for 2.4.0-test11 (also in ac2)
cpu MHz : 132.000956

The "000" seems to be excess. linux/arch/i386/kernel/time.c has it
right in time_init().

diff -u linux/arch/i386/kernel/setup.c\~ linux/arch/i386/kernel/setup.c
--- linux/arch/i386/kernel/setup.c~ Wed Nov 22 21:43:15 2000
+++ linux/arch/i386/kernel/setup.c  Thu Nov 23 00:16:32 2000
@@ -2113,7 +2113,7 @@
p += sprintf(p, "stepping\t: unknown\n");
 
if ( test_bit(X86_FEATURE_TSC, >x86_capability) ) {
-   p += sprintf(p, "cpu MHz\t\t: %lu.%06lu\n",
+   p += sprintf(p, "cpu MHz\t\t: %lu.%03lu\n",
cpu_khz / 1000, (cpu_khz % 1000));
}

-- 

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

Re: Alan Cox's e-mail address is hosed?

[Miles Lane]

Alan Cox wrote:

>> Okay, please explain why ORBS tells me it does *not*
>> identify my ISP's SMTP server as an open relay?
>> 
>> mail.megapathdsl.net = 216.200.176.7
> 
> 
> Your mail goes out via your isps outgoing feed ns1.megapath.net
> which is in ORBS (216.200.176.4)

Thank you,

I will go pummel my ISP's technical staff into the
pavement until this is fixed.

Cheerio,

Miles

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

Re: PROBLEM: isofs crash on 2.4.0-test11-pre7 [1.] MAINTAINERS: ISO FILESYSTEM

[Heinz Diehl]

On Mon Nov 20 2000, Alessandro Suardi wrote:

> there is a buglet in fs/isofs/namei.c, corrected in test11-final.

Hmmm. 

/var/log/warn says 

Nov 21 23:07:06 elfie kernel: _isofs_bmap: block >= EOF (1633681408, 4096)
Nov 21 23:07:08 elfie kernel: _isofs_bmap: block >= EOF (559939584, 4096)
Nov 21 23:07:09 elfie kernel: _isofs_bmap: block < 0
Nov 21 23:07:33 elfie last message repeated 2 times
Nov 21 23:09:39 elfie kernel: _isofs_bmap: block < 0
Nov 21 23:11:25 elfie kernel: Freeing unused kernel memory: 176k freed
Nov 21 23:11:55 elfie kernel: _isofs_bmap: block < 0
Nov 21 23:11:59 elfie kernel: _isofs_bmap: block < 0
Nov 21 23:12:33 elfie kernel: _isofs_bmap: block >= EOF (1633681408, 4096)
Nov 21 23:12:38 elfie kernel: _isofs_bmap: block >= EOF (1633681408, 4096)
Nov 21 23:13:03 elfie kernel: _isofs_bmap: block >= EOF (559939584, 4096)

after I mounted the CD-ROM. Moving to the directory the CD-ROM
was mounted on, it is empty !

Going back to 2.4.0-test10-final cures the problem.

My system:

hd@elfie:~ > ver_linux
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux elfie 2.4.0-test10-final #1 Tue Nov 21 23:18:34 CET 2000 i586 unknown
Kernel modules 2.3.19
Gnu C  2.95.2
Gnu Make   3.79
Binutils   2.10.0.33
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Linux C++ Library  2.9.0
Procps 2.0.2
Mount  2.10o
Net-tools  1.46
Kbd0.96
Sh-utils   1.12
Modules Loaded serial

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

Re: include conventions /usr/include/linux/sys ?

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:"LA Walsh" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Linus has mentioned a desire to move kernel internal interfaces into
> a separate kernel include directory.  In creating some code, I'm wondering
> what the name of this should/will be.  Does it follow that convention
> would point toward a linux/sys directory?
> 

I suggested include/kernel and include/arch with include/linux and
include/asm being reserved for the kernel interfaces (ioctl and their
structures mostly.)

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

Re: linux-2.2.18-pre19 asm/delay.h problem?

[Igmar Palsenberg]

> |> > > #define __bad_udelay() panic("Udelay called with too large a constant")
> |> 
> |> Can't we change that to :
> |> #error "Udelay..."
> 
> No.

?? I think I'm missing something here.

 
> Andreas.


Igmar

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

Re: Patch(?): pci_device_id tables for linux-2.4.0-test11/drivers/block

[Jeff Garzik]

Andi Kleen wrote:
> 
> On Wed, Nov 22, 2000 at 05:14:38PM -0500, Jeff Garzik wrote:
> > *This* is the over-engineering attitude I was talking about.  The only
> > reason why you are preferring named initializers is because
> > pci_device_id MIGHT be changed.  And if it is changed, it makes the
> > changeover just tad easier.  For that, you ugly up the code and make it
> > more difficult to maintain.
> 
> The other reason is that it makes self documenting code -- no need to look
> up the structure definition to make sense out of the code.

For the general case, that is true.

But note that the general case is usually a -single- structure being
initialized, not an array of structures.  Unless the struct members
being initialized vary wildly from one array element to another, using
named initialized it redundant and -reduces- the ability of the
programmer to look at the pci_tbl[] and evaluate its contents at a
glance.

PCI tables do not use named initalizers on purpose.  It was not an
accident or design mistake.

Jeff


-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: e2fs performance as function of block size

[Michael Marxmeier]

Alan Cox wrote:
> I see higher performance with 4K block sizes. I should see higher 
> latency too but have never been able to measure it. Maybe it depends 
> on the file system.
> It certainly depends on the nature of requests

If the files get somewhat bigger (eg. > 1G) having a bigger block
size also greatly reduces the ext2 overhead. Especially fsync() 
used to be really bad on big file but choosing a bigger block
size changed a lot.

If the database used by the original poster is based on 
something like c-isam then (AFAIR) it is in fact using
1k blocks which may explain the better results of 1k block
size. With a 100 MB file size fs management overhead should
not be that visible. 


Michael

-- 
Michael Marxmeier   Marxmeier Software AG
E-Mail: [EMAIL PROTECTED]  Besenbruchstrasse 9
Phone : +49 202 2431440 42285 Wuppertal, Germany
Fax   : +49 202 2431420 http://www.marxmeier.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Alan Cox's e-mail address is hosed?

[Miles Lane]

Okay, please explain why ORBS tells me it does *not*
identify my ISP's SMTP server as an open relay?

mail.megapathdsl.net = 216.200.176.7

ORBS says:

Database Check - 216.200.176.7
216.200.176.7 is not in the main automated
open relay database

Thanks,
Miles

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

Re: Alan Cox's e-mail address is hosed?

[Alan Cox]

> Q: When I send private e-mail to Alan Cox, it bounces. Why?
> A: Alan has blocked all incoming e-mail except from a list of addresses
> known to be good.  You'll need to post to the list to be seen by him.

Try 

A: Alan like many people filters mail using the MAPS RBL, DUL and ORBS 
spam relay lists. See http://www.mail-abuse.org and http://www.orbs.org for
more information


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

Re: [PATCH] Speed up interrupt entry

[Kurt Garloff]

On Sat, Nov 18, 2000 at 11:20:09AM +0100, Andi Kleen wrote:
> Index: include/asm-i386/hw_irq.h
> ===
> RCS file: /cvs/linux/include/asm-i386/hw_irq.h,v
> retrieving revision 1.11
> diff -u -u -r1.11 hw_irq.h
> --- include/asm-i386/hw_irq.h 2000/05/16 16:08:15 1.11
> +++ include/asm-i386/hw_irq.h 2000/11/18 10:33:48
> @@ -103,9 +107,12 @@
>   "pushl %edx\n\t" \
>   "pushl %ecx\n\t" \
>   "pushl %ebx\n\t" \
> - "movl $" STR(__KERNEL_DS) ",%edx\n\t" \
 ^^^
> - "movl %edx,%ds\n\t" \
> - "movl %edx,%es\n\t"
> + "movl $" STR(__KERNEL_DS),%eax\n\t" \
 ^

You missed a ' "'
Apart from that it
(a) makes sense
(b) survived real world usage ...

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security

 PGP signature

Re: silly [< >] and other excess

[Keith Owens]

On Wed, 22 Nov 2000 14:42:05 +0100, 
Christian Gennerat <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] a écrit :
>
>>  I also left something else
>> that always annoyed me: valuable screen space (on a 24x80 vt)
>> is lost by these silly [< >] around addresses in an Oops.
>> They provide no information at all, but on the other hand
>> cause loss of information because these lines no longer
>> fit in 80 columns causing line wrap and the loss of the
>> top of the Oops.]

You just broke ksymoops.  Removing the [< >] is a bad idea, they are
one of the few things that identifies the addresses in the log,
otherwise they just look like hex numbers.  ksymoops has to scan log
files which can contain anything and somehow pick out the interesting
lines, you need some identifier on the lines.

>Moreover, there is another problem in Oops:
>the dumped stack is limited to 3 or 4 lines to prevent loss of information
>but the call trace is unlimited and can loose all information,
>and sometimes is printing forever!
>--- arch/i386/kernel/traps.c.orig Mon Oct  2 20:57:01 2000
>+++ arch/i386/kernel/traps.c Sun Nov  5 14:33:52 2000
>@@ -142,11 +142,12 @@
>* out the call path that was taken.
>*/
>   if (((addr >= (unsigned long) &_stext) &&
>+(i<32) &&
>(addr <= (unsigned long) &_etext)) ||
>   ((addr >= module_start) && (addr <= module_end))) {
>if (i && ((i % 8) == 0))
> printk("\n   ");
>-   printk("[<%08lx>] ", addr);
>+   printk("%08lx ", addr);
>i++;
>   }
>  }

There should be no need to restrict the number of lines printed, it is
limited by the top of the kernel stack.  If there are more than 32
trace entries on the stack then they should be printed.

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

Re: [patch] O_SYNC patch 3/3, add inode dirty buffer list support to ext2

[Josue Emmanuel Amaro]

Jeff,

>>Is this assumption correct, and does this comply with TPC rules for ORACLE and
>>other DBMS benchmarks?  It looks like a good patch that will perform
>>very fast for O_SYNC.

Why would that be a problem?  If you look at our benchmarks we normally use raw I/O
to bypass buffers altogether (We buffer in the SGA).
That said, we maintain consistency at the database, so as long as the data in the
buffers is consistent with the data on disk, which is only relevant to modified
buffers, which are being written directly to disk, there should not be a problem.

The effect of O_SYNC on the kernel buffer is that there should not be "any" dirty
buffers for that particular file, since all of them are written to disk
"immediately".

Am I missing something?

Regards,

"Jeff V. Merkey" wrote:

> On Wed, Nov 22, 2000 at 11:26:46AM +, Stephen C. Tweedie wrote:
> > Hi,
> >
> > This final part of the O_SYNC patches adds calls to ext2, and to
> > generic_commit_write, to record dirty buffers against the owning
> > inode.  It also removes most of fs/ext2/fsync.c, which now simply
> > calls the generic sync code.
> >
> > --Stephen
>
> Stephen,
>
> I have not implemented O_SYNC in NWFS, but it looks like I need to add it
> before posting the final patches.  This patch appears to force write-through
> of only dirty inodes, and allow reads to continue from cache.  Is this
> assumption correct, and does this comply with TPC rules for ORACLE and
> other DBMS benchmarks?  It looks like a good patch that will perform
> very fast for O_SYNC.
>
> Jeff
>
> >
> > 2.4.0test11.02.ext2-osync.diff :
> >
> >
> > --- linux-2.4.0-test11/fs/buffer.c.~1~Tue Nov 21 15:51:17 2000
> > +++ linux-2.4.0-test11/fs/buffer.cTue Nov 21 16:35:35 2000
> > @@ -1727,6 +1727,7 @@
> >   set_bit(BH_Uptodate, >b_state);
> >   if (!atomic_set_buffer_dirty(bh)) {
> >   __mark_dirty(bh);
> > + buffer_insert_inode_queue(bh, inode);
> >   need_balance_dirty = 1;
> >   }
> >   }
> > --- linux-2.4.0-test11/fs/ext2/fsync.c.~1~Tue Nov 21 15:47:48 2000
> > +++ linux-2.4.0-test11/fs/ext2/fsync.cTue Nov 21 16:01:15 2000
> > @@ -28,98 +28,6 @@
> >  #include 
> >
> >
> > -#define blocksize(EXT2_BLOCK_SIZE(inode->i_sb))
> > -#define addr_per_block   (EXT2_ADDR_PER_BLOCK(inode->i_sb))
> > -
> > -static int sync_indirect(struct inode * inode, u32 * block, int wait)
> > -{
> > - struct buffer_head * bh;
> > -
> > - if (!*block)
> > - return 0;
> > - bh = get_hash_table(inode->i_dev, le32_to_cpu(*block), blocksize);
> > - if (!bh)
> > - return 0;
> > - if (wait && buffer_req(bh) && !buffer_uptodate(bh)) {
> > - /* There can be a parallell read(2) that started read-I/O
> > -on the buffer so we can't assume that there's been
> > -an I/O error without first waiting I/O completation. */
> > - wait_on_buffer(bh);
> > - if (!buffer_uptodate(bh))
> > - {
> > - brelse (bh);
> > - return -1;
> > - }
> > - }
> > - if (wait || !buffer_uptodate(bh) || !buffer_dirty(bh)) {
> > - if (wait)
> > - /* when we return from fsync all the blocks
> > -must be _just_ stored on disk */
> > - wait_on_buffer(bh);
> > - brelse(bh);
> > - return 0;
> > - }
> > - ll_rw_block(WRITE, 1, );
> > - atomic_dec(>b_count);
> > - return 0;
> > -}
> > -
> > -static int sync_iblock(struct inode * inode, u32 * iblock,
> > - struct buffer_head ** bh, int wait)
> > -{
> > - int rc, tmp;
> > -
> > - *bh = NULL;
> > - tmp = le32_to_cpu(*iblock);
> > - if (!tmp)
> > - return 0;
> > - rc = sync_indirect(inode, iblock, wait);
> > - if (rc)
> > - return rc;
> > - *bh = bread(inode->i_dev, tmp, blocksize);
> > - if (!*bh)
> > - return -1;
> > - return 0;
> > -}
> > -
> > -static int sync_dindirect(struct inode * inode, u32 * diblock, int wait)
> > -{
> > - int i;
> > - struct buffer_head * dind_bh;
> > - int rc, err = 0;
> > -
> > - rc = sync_iblock(inode, diblock, _bh, wait);
> > - if (rc || !dind_bh)
> > - return rc;
> > -
> > - for (i = 0; i < addr_per_block; i++) {
> > - rc = sync_indirect(inode, ((u32 *) dind_bh->b_data) + i, wait);
> > - if (rc)
> > - err = rc;
> > - }
> > - brelse(dind_bh);
> > - return err;
> > -}
> > -
> > -static int sync_tindirect(struct inode * inode, u32 * tiblock, int wait)
> > -{
> > - int i;
> > - struct buffer_head * tind_bh;
> > - int rc, err = 0;
> > -
> > - rc = sync_iblock(inode, tiblock, _bh, wait);
> > -

Re: Patch(?): pci_device_id tables for linux-2.4.0-test11/drivers/block

[Andi Kleen]

On Wed, Nov 22, 2000 at 05:14:38PM -0500, Jeff Garzik wrote:
> *This* is the over-engineering attitude I was talking about.  The only
> reason why you are preferring named initializers is because
> pci_device_id MIGHT be changed.  And if it is changed, it makes the
> changeover just tad easier.  For that, you ugly up the code and make it
> more difficult to maintain.

The other reason is that it makes self documenting code -- no need to look
up the structure definition to make sense out of the code.


-Andi (who thinks easily readable code is good) 

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

Re: Patch(?): pci_device_id tables for linux-2.4.0-test11/drivers/block

[Jeff Garzik]

"Adam J. Richter" wrote:
> Just to avoid duplication of effort, I am posting this preliminary
> patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
> drivers in linux-2.4.0-test11/drivers/block.  In response to input from
> Christoph Hellwig, I have reduced my threshhold on using named initializers
> to three entries, although I think that may be going to far, as I would
> really like to keep the number of files that initialize the pci_device_id
> arrays this way low so that changing struct pci_device_id remains feasible.

*This* is the over-engineering attitude I was talking about.  The only
reason why you are preferring named initializers is because
pci_device_id MIGHT be changed.  And if it is changed, it makes the
changeover just tad easier.  For that, you ugly up the code and make it
more difficult to maintain.

_I_ am one of the people that works on maintaining these random PCI
drivers that no one gives a shit about.  And if applied, your patches
make my job just a little bit harder.

We -discourage- these kind of crap design decisions in the Linux kernel.

Don't over-engineer.



> --- linux-2.4.0-test11/drivers/block/DAC960.c   Thu Oct 26 23:35:47 2000
> +++ linux/drivers/block/DAC960.cWed Nov 22 12:42:23 2000

ok


> --- linux-2.4.0-test11/drivers/block/cciss.cThu Oct 26 23:35:47 2000
> +++ linux/drivers/block/cciss.c Wed Nov 22 12:29:27 2000
> @@ -50,6 +50,17 @@
>  /* Embedded module documentation macros - see modules.h */
>  MODULE_AUTHOR("Charles M. White III - Compaq Computer Corporation");
>  MODULE_DESCRIPTION("Driver for Compaq Smart Array Controller 5300");
> +static struct pci_device_id cciss_pci_tbl[] __initdata = {
> +   {
> + vendor: PCI_VENDOR_ID_COMPAQ,
> + device: PCI_DEVICE_ID_COMPAQ_CISS,
> + subvendor: PCI_ANY_ID,
> + subdevice: PCI_ANY_ID,
> +   },
> +   { } /* Terminating entry */
> +};
> +MODULE_DEVICE_TABLE(pci, cciss_pci_tbl);

hell no


> --- linux-2.4.0-test11/drivers/block/cpqarray.c Thu Nov 16 11:30:29 2000
> +++ linux/drivers/block/cpqarray.c  Wed Nov 22 12:34:53 2000

ok

-- 
Jeff Garzik |
Building 1024   | The chief enemy of creativity is "good" sense
MandrakeSoft|  -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Alan Cox's e-mail address is hosed?

[Alex Buell]

On Thu, 23 Nov 2000, Miles Lane wrote:

>   host lightning.swansea.uk.linux.org says:
>   550 rejected: administrative prohibition

I think this one needs to go into the FAQ!

Q: When I send private e-mail to Alan Cox, it bounces. Why?
A: Alan has blocked all incoming e-mail except from a list of addresses
known to be good.  You'll need to post to the list to be seen by him.

Cheers,
Alex
-- 
Run away!

http://www.tahallah.clara.co.uk

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

Re: Alan Cox's e-mail address is hosed?

[Rik van Riel]

On Thu, 23 Nov 2000, Miles Lane wrote:

> I attempted to reply to a message from Alan
> and got the following response.

> SMTP module(domain lxorguk.ukuu.org.uk) reports:
>   host lightning.swansea.uk.linux.org says:
>   550 rejected: administrative prohibition

You're in ORBS. Fix your open relay and get out of ORBS ...

cheers,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

http://www.conectiva.com/   http://www.surriel.com/


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

Re: Alan Cox's e-mail address is hosed?

[Jes Sorensen]

> "Miles" == Miles Lane <[EMAIL PROTECTED]> writes:

Miles> I attempted to reply to a message from Alan and got the
Miles> following response.

No it isn't, Alan uses ORBS and you are obviously black listed there
(www.orbs.org).

This one seems to come up every now and then, and always turns into a
flamewar. Now it's Alan's choice so if you want to argue over this,
take it somewhere else please.

Who is maintaining the FAQ? this might be a good idea to add to under
the mailing list section.

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

Re: PROBLEM: Cruft mounting option incorrect in ISOFS code

[Alan Cox]

> under 1 gig in size.  You can exhibit the problem by mounting the dvd movie
> "The World is Not Enough" as it contains a video_ts.vob which is larger than
> 1 gigabyte.  You will see that most of the file lengths are incorrect due to
> the "cruft mounting option" hacking off the high order byte.  There are
> certainly many more movies out there that exhibit this problem so it would
> be a good thing for someone to fix.

The cruft thing is correct in itself. The size being 4Gb is trivial to change
providing someone can provide a reference to the standards that say its ok.
So is the limit 4Gig, who documents it ?

Alan

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

Patch(?): pci_device_id tables for linux-2.4.0-test11/drivers/block

[Adam J. Richter]

Just to avoid duplication of effort, I am posting this preliminary
patch which adds PCI MODULE_DEVICE_TABLE declarations to the three PCI
drivers in linux-2.4.0-test11/drivers/block.  In response to input from
Christoph Hellwig, I have reduced my threshhold on using named initializers
to three entries, although I think that may be going to far, as I would
really like to keep the number of files that initialize the pci_device_id
arrays this way low so that changing struct pci_device_id remains feasible.

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

--- linux-2.4.0-test11/drivers/block/DAC960.c   Thu Oct 26 23:35:47 2000
+++ linux/drivers/block/DAC960.cWed Nov 22 12:42:23 2000
@@ -40,11 +40,22 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include "DAC960.h"
 
+
+static struct pci_device_id DAC960_pci_tbl[] __initdata = {
+ { PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_MYLEX_DAC960_BA, PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_MYLEX_DAC960_LP, PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_DEC,   PCI_DEVICE_ID_DEC_21285,   PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_MYLEX_DAC960_PG, PCI_ANY_ID, PCI_ANY_ID},
+ { PCI_VENDOR_ID_MYLEX, PCI_DEVICE_ID_MYLEX_DAC960_PD, PCI_ANY_ID, PCI_ANY_ID},
+ { }   /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, DAC960_pci_tbl);
 
 /*
   DAC960_ControllerCount is the number of DAC960 Controllers detected.
--- linux-2.4.0-test11/drivers/block/cciss.cThu Oct 26 23:35:47 2000
+++ linux/drivers/block/cciss.c Wed Nov 22 12:29:27 2000
@@ -50,6 +50,17 @@
 /* Embedded module documentation macros - see modules.h */
 MODULE_AUTHOR("Charles M. White III - Compaq Computer Corporation");
 MODULE_DESCRIPTION("Driver for Compaq Smart Array Controller 5300");
+static struct pci_device_id cciss_pci_tbl[] __initdata = {
+   {
+ vendor: PCI_VENDOR_ID_COMPAQ,
+ device: PCI_DEVICE_ID_COMPAQ_CISS,
+ subvendor: PCI_ANY_ID,
+ subdevice: PCI_ANY_ID,
+   },
+   { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, cciss_pci_tbl);
+
 
 #include "cciss_cmd.h"
 #include "cciss.h"
--- linux-2.4.0-test11/drivers/block/cpqarray.c Thu Nov 16 11:30:29 2000
+++ linux/drivers/block/cpqarray.c  Wed Nov 22 12:34:53 2000
@@ -52,6 +52,16 @@
 MODULE_AUTHOR("Compaq Computer Corporation");
 MODULE_DESCRIPTION("Driver for Compaq Smart2 Array Controllers");
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
+static struct pci_device_id cpqarray_pci_tbl[] __initdata = {
+  { PCI_VENDOR_ID_DEC,PCI_DEVICE_ID_COMPAQ_42XX,   PCI_ANY_ID, PCI_ANY_ID},
+  { PCI_VENDOR_ID_NCR,PCI_DEVICE_ID_NCR_53C1510,   PCI_ANY_ID, PCI_ANY_ID},
+  { PCI_VENDOR_ID_COMPAQ, PCI_DEVICE_ID_COMPAQ_SMART2P,PCI_ANY_ID, PCI_ANY_ID},
+  { }  /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, cpqarray_pci_tbl);
+#endif
+
 #define MAJOR_NR COMPAQ_SMART2_MAJOR
 #include 
 #include 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox's e-mail address is hosed?

[Miles Lane]

I attempted to reply to a message from Alan
and got the following response.

 Original Message 
Subject: Undeliverable mail: Re: Linux 2.4.0test11-ac2
Date: Wed, 22 Nov 2000 11:46:54 -0800
From: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>

Failed to deliver to '[EMAIL PROTECTED]'
SMTP module(domain lxorguk.ukuu.org.uk) reports:
  host lightning.swansea.uk.linux.org says:
  550 rejected: administrative prohibition


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

PROBLEM: Cruft mounting option incorrect in ISOFS code

[Peel, Jeffery S]

Hi all,

There is a pretty bad bug in the "/fs/isofs/inode.c" file under linux kernel
version 2.2.17.  Search the file for the word "dipshit" (not a joke) and
look at the cruft mounting code.  It assumes that the maximum size of a
dvd-rom file is 1 gigabyte.  This is certainly not a correct assumption when
talking about dvd-rom's with nothing but data on them as the maximum size of
an iso-9660 file is something like 2^32.  It is also incorrect if he is
referring to dvd movies as the maximum file size of any non title set file
is also only bounded by the iso-9660 file system limitations.  The dvd video
specification only limits title set files in the form of vts_0x_x.vob to
under 1 gig in size.  You can exhibit the problem by mounting the dvd movie
"The World is Not Enough" as it contains a video_ts.vob which is larger than
1 gigabyte.  You will see that most of the file lengths are incorrect due to
the "cruft mounting option" hacking off the high order byte.  There are
certainly many more movies out there that exhibit this problem so it would
be a good thing for someone to fix.

Here is the code in question.

/* There are defective discs out there - we do this to protect
   ourselves.  A cdrom will never contain more than 800Mb 
   .. but a DVD may be up to 1Gig (Ulrich Habel) */
if((inode->i_size < 0 || inode->i_size > 1073741824) &&
inode->i_sb->u.isofs_sb.s_cruft == 'n') {
  printk("Warning: defective cdrom.  Enabling \"cruft\" mount
option.\n");
  inode->i_sb->u.isofs_sb.s_cruft = 'y';
}

/* Some dipshit decided to store some other bit of information in the high
   byte of the file length.  Catch this and holler.  WARNING: this will make
   it impossible for a file to be > 16Mb on the CDROM!!!*/

if(inode->i_sb->u.isofs_sb.s_cruft == 'y' &&
   inode->i_size & 0xff00){
/*printk("Illegal format on cdrom.  Pester manufacturer.\n"); */
  inode->i_size &= 0x00ff;
}

--> I am not subscribed to the mailing list so any reply will have to be
made to my e-mail address <--

Jeff Peel

Senior Software Engineer
Intel IAL - Consumer Media Technology


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

Re: Address translation

[Keir Fraser]

> The reason that everyone else uses copy_{to,from}_user is that there
> is no way to guarantee that the userspace pointer is valid. That
> memory may have been swapped out. The copy macros are prepared to
> fault the memory in. The rest of the kernel is not.
>
> Jeff

I may be wrong on this, but I thought that copy_{to,from}_user are
only necessary if the address range you are accessing might cause a
fault which Linux cannot handle (ie. one which would cause the
application to segfault if it accessed that memory). If it is only a
matter of paging the memory in (and you are _sure_ the address range is
otherwise valid) I think the access macros are unnecessary. I would be
*very* glad if someone could confirm this, or shoot me down. :)

For instance, a kernel module I am writing allocates some memory in
the current process's address space as follows:

down(>mmap_sem);
s->table = (void **)get_unmapped_area(0, SIZEOF_TABLE);
if ( s->table != NULL )
do_brk((unsigned long)s->table, SIZEOF_TABLE);
up(>mmap_sem);

Some questions:
 (1) In a "top half" thread, can I now access this memory without the
 access macros (since I know the address range is valid)?
 (2) Can I also access this memory from an interrupt/exception
 context, or must I lock it? (ie. can faults be handled from such
 a context) 
 (3) Is the above code sensible at all, or barking? It took me a while
 to figure that the above would work, and I think/hope it is the
 most elegant way to share memory between kernel and a process.

 Thanks in advance for any info!
 -- Keir Fraser

PS. Please cc me directly ([EMAIL PROTECTED]) with any replies.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: user-mode port 0.34-2.4.0-test11

[Daniel Phillips]

Jeff Dike wrote:
> 
> The user-mode port of 2.4.0-test11 is available.
> 
> UML is now able to run as a daemon, i.e. with no stdin/stdout/stderr.
> 
> The hostfs filesystem now works as a readonly filesystem.  It's now
> configurable.  I'm using it as a module.  It ought to work compiled into the
> kernel, but I haven't checked this.
> 
> I fixed a number of bugs.
> 
> NOTE:  If you compile from source, you must put 'ARCH=um' on the make command
> line or in the environment, like:
> make linux ARCH=um
> or
> ARCH=um make linux
> or
> export ARCH=um
> make linux
> 
> This is because I've changed the top-level Makefile to build either a native
> kernel or a usermode kernel, with the default being native.  This is in
> preparation for submitting this port to the main pool.  The ARCH calculation
> is now this:
> 
> # SUBARCH tells the usermode build what the underlying arch is.  That is set
> # first, and if a usermode build is happening, the "ARCH=um" on the command
> # line overrides the setting of ARCH below.  If a native build is happening,
> # then ARCH is assigned, getting whatever value it gets normally, and
> # SUBARCH is subsequently ignored.
> 
> SUBARCH:= $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e
> s/arm.*/arm/ -e s/sa110/arm/)
> ARCH:= $(SUBARCH)
> 
> If anyone has any objections to this going in the main pool, let me know, and
> also let me know what you would suggest as a fix.

As you know, I'm making heavy use of uml for mm, vfs and fs development,
and I can't say enough good things about it.  With uml I have a
development cycle that looks roughly like this:

  20 secs make+gcc+ln
  10 secs boot new user mode linux
  6 secs fsck (if crashed before) :-)
  *tests go here*
  10 secs shutdown

And there are still a lot of ways to tighten that up.  The stability has
been impressive - so far, no crashes at all that weren't supposed to be
crashes, at least in the work I'm doing.

I think this is ready...

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

RFC: Modularize /proc/partitons (was Re: /proc/partitions for LVM)

[Brian Kress]

"Heinz J. Mauelshagen" wrote:
> 
> On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
> >   Question about /proc/partitions and LVM.  LVM devices in
> > /proc/partitions currently show up as lvma, lvmb, etc, depending on
> > their device number.  This breaks things like mount by filesystem
> > name.  Back when LVM existed as a patch, I believe there was some
> > support in fs/partitions/check.c for showing the proper name for
> > the device (something like /).
> 
> Yes.
> It actually was /.
> 
> Linus didn't accept it though.
> 
> The code is still available in case he changes his mind.

Yes, I can see that now looking through lvm.c.  (LVM_HD_NAME)
I'm guessing why he didn't take it is the minor hack of adding a
function pointer to genhd.c as a special case just for LVM.  
A general solution to this problem would be nice.  The
big switch statement in disk_name in fs/paritions/check.c is kind
of ugly as it has generic code have to know things about specific
drivers.  
How's this for an idea to generalize this.  Put a function
pointer in the gendisk structure for a specific function to call
for disk_name for disks for that gendisk.  That way, LVM gets its
/, IDE gets its two disks per major (special cased
right now), all the other special cases get what they need and future
drivers can call their devices whatever they like without touching
this file.  Makes the whole thing more modular.  Make a NULL for 
this function default to the old a, b, etc.
What to people think about this?  If this sounds reasonable
I can come up with a patch.


Brian Kress
[EMAIL PROTECTED]








> 
> >   Are their any plans for something like this to be added
> > or is their a reason it was taken out?
> >
> >
> >   BTW, 2.4.0-test11 is the first "perfect" kernel for me.  It
> > finally has everything I use working correctly.  (well, with a
> > small raid5 patch, anyway).
> >
> >
> > Brian Kress
> > [EMAIL PROTECTED]
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > Please read the FAQ at http://www.tux.org/lkml/
> 
> --
> 
> Regards,
> Heinz  -- The LVM guy --
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> Heinz Mauelshagen Sistina Software Inc.
> Senior Consultant/Developer   Bartningstr. 12
>   64289 Darmstadt
>   Germany
> [EMAIL PROTECTED]   +49 6151 7103 86
>FAX 7103 96
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: /proc/partitions for LVM

[Heinz J. Mauelshagen]

On Wed, Nov 22, 2000 at 04:05:39PM -0500, Brian Kress wrote:
>   Question about /proc/partitions and LVM.  LVM devices in 
> /proc/partitions currently show up as lvma, lvmb, etc, depending on
> their device number.  This breaks things like mount by filesystem
> name.  Back when LVM existed as a patch, I believe there was some
> support in fs/partitions/check.c for showing the proper name for
> the device (something like /).  

Yes.
It actually was /.

Linus didn't accept it though.

The code is still available in case he changes his mind.

>   Are their any plans for something like this to be added
> or is their a reason it was taken out?
> 
> 
>   BTW, 2.4.0-test11 is the first "perfect" kernel for me.  It
> finally has everything I use working correctly.  (well, with a 
> small raid5 patch, anyway).
> 
> 
> Brian Kress
> [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 

Regards,
Heinz  -- The LVM guy --

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

Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer   Bartningstr. 12
  64289 Darmstadt
  Germany
[EMAIL PROTECTED]   +49 6151 7103 86
   FAX 7103 96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

/proc/partitions for LVM

[Brian Kress]

Question about /proc/partitions and LVM.  LVM devices in 
/proc/partitions currently show up as lvma, lvmb, etc, depending on
their device number.  This breaks things like mount by filesystem
name.  Back when LVM existed as a patch, I believe there was some
support in fs/partitions/check.c for showing the proper name for
the device (something like /).  
Are their any plans for something like this to be added
or is their a reason it was taken out?


BTW, 2.4.0-test11 is the first "perfect" kernel for me.  It
finally has everything I use working correctly.  (well, with a 
small raid5 patch, anyway).


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

Re: include conventions /usr/include/linux/sys ?

[Arjan van de Ven]

In article <[EMAIL PROTECTED]> you wrote:
> Linus has mentioned a desire to move kernel internal interfaces into
> a separate kernel include directory.  In creating some code, I'm wondering
> what the name of this should/will be.  Does it follow that convention
> would point toward a linux/sys directory?

I would vote for

include/linux   -exported interfaces
include/kernel  -kernel internal interfaces
include/asm -kernel internal/archspecific interfaces

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

Re: [PATCH] Reserved root VM + OOM killer

[Szabolcs Szakacsits]

On Wed, 22 Nov 2000, Rik van Riel wrote:

> On Wed, 22 Nov 2000, Szabolcs Szakacsits wrote:
>
> >- OOM killing takes place only in do_page_fault() [no two places in
> > the kernel for process killing]
>
> ... disable OOM killing for non-x86 architectures.
> This doesn't seem like a smart move ;)
>
> > diff -urw linux-2.2.18pre21/arch/i386/mm/Makefile linux/arch/i386/mm/Makefile
> > --- linux-2.2.18pre21/arch/i386/mm/Makefile Fri Nov  1 04:56:43 1996
  ^
As I wrote, the OOM killer changes are x86 only at present. Other
arch's still use the default OOM killing defined in arch/*/mm/fault.c.

Szaka

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

include conventions /usr/include/linux/sys ?

[LA Walsh]

Linus has mentioned a desire to move kernel internal interfaces into
a separate kernel include directory.  In creating some code, I'm wondering
what the name of this should/will be.  Does it follow that convention
would point toward a linux/sys directory?
-l

--
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice/Vmail: (650) 933-5338

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

Re: [PATCH] Reserved root VM + OOM killer

[Rik van Riel]

On Wed, 22 Nov 2000, Szabolcs Szakacsits wrote:

>- OOM killing takes place only in do_page_fault() [no two places in
> the kernel for process killing]

... disable OOM killing for non-x86 architectures.
This doesn't seem like a smart move ;)

> diff -urw linux-2.2.18pre21/arch/i386/mm/Makefile linux/arch/i386/mm/Makefile
> --- linux-2.2.18pre21/arch/i386/mm/Makefile   Fri Nov  1 04:56:43 1996
> +++ linux/arch/i386/mm/Makefile   Tue Nov 21 03:03:15 2000
> @@ -8,6 +8,6 @@
>  # Note 2! The CFLAGS definition is now in the main makefile...
> 
>  O_TARGET := mm.o
> -O_OBJS:= init.o fault.o ioremap.o extable.o
> +O_OBJS:= init.o fault.o ioremap.o extable.o ../../../mm/oom_kill.o
> 
>  include $(TOPDIR)/Rules.make

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

http://www.conectiva.com/   http://www.surriel.com/

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

Re: Defective Red Hat Distribution poorly represents Linux

[David Riley]

Jeff Epler wrote:
> Well, a copy of that document *is* the first hit for a google search on
> 'linux signal 11 faq'
> http://www.google.com/search?q=linux+signal+11+faq
> 
> In other words, someone who does the slightest bit of research will
> find the answer.

Perhaps, but if a new user starts using linux and his/her machine is
randomly crashing (not always showing the number 11 anywhere in the
error messages, mind you) the first thing they look for won't be "linux
signal 11 faq".  They'd look for something like "random linux crashes"
or "constant linux crashes" or something to that effect.  Try these on
for size...


This one goes six entries before it even comes upon a similar hardware
problem (though to be fair, the report of this problem was far more
intelligent than the one that started this thread) and that is full of
stack traces and cryptic things that a newbie wouldn't even pretend to
understand.  A few years ago, I would have run away screaming from that report.


The first link from this search points to a forum on linuxsucks.org. 
Not what we want newbies looking at...  Some of the posts on the forum
bemoan the lack of documentation for linux.

I think the "slightest bit of research" is a lot different for
experienced Linux users than for those who come from Windoze or MacOS. 
Someone suggested to me that one could put such info on the default page
of the brower in the distribution (the one on the local disk in case of
RedHat, etc), perhaps in the "troubleshooting" section.  That sounds
like a good idea to me.

It also occurs to me that a discussion of documentation belongs on
another list unless it pertains to kernel documentation.  I'll try to
make this my last post.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

lmbench-2alpha12 and linux-2.4.0-test11

[Lorenzo Allegrucci]

It seems like lastest kernels cannot run lmbench successfully.
lmbench stops at "Local networking", between lat_connect
and bw_tcp, as far as I can see from 'top'.
No errors reported, lat_connect or bw_tcp exit silently.

All 2.4.0-test[5-11] seem to have this problem.
2.4.0-test1 and 2.2.x all run lmbench successfully instead.

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

PROBLEM: (U)DMA, hda: dma_intr status=0x51 ... error=0x84

[Christian Roessner]

Hello,

I tested many hours before I sent you this eMail. I never
sent Bug-Reports, so please be friendly if I did something
wrong :-)

I used the formular to produce a bug-report:

1.) See subject
2.) I have trouble using DMA mode with my Siemens Fujitsu
harddisk on a NMC 6vcx Motherboard. I compiled the kernel
with DMA support, multi mode VIA chipset support and booting
DMA by default when available.

I used the command "updatedb" and "find" and "bonnie" to have much
read access. No problem occurs.

I used xmms to convert mp3-files into wav. There I get many
errors of the following:

hda: dma_intr status=0x51 {DriveReadySeekComplete Error}
hda: dma_intr  error=0x84 {DriveStatusError BadCRC}

I do not want to run the harddisk in PIO mode. I used hdparm
to change some settings (infos from SuSE Support database)

hdparm -d 1 -c 0 -X66 /dev/hda (also without -X66)
and
hdparm -d 1 -c 1 -X66 /dev/hda (also without -X66)
at least
hdparm -d 0 /dev/hda

Nothing changed. (only performance maybe)

3.) Keywords: (U)DMA
4.) Linux version 2.4.0-test11 (root@informatik) (gcc
version 2.95.2 19991024 (release)) #15 Wed Nov 22 18:40:38
CET 2000
5.) No Oops Output available
6.) Xmms is able to produce the error by using the
diskwriter modul
7.) Environment:
-1.) Kernel modules 2.3.20
Gnu C  2.95.2
Gnu Make   3.79.1
Binutils   2.9.5.0.24
Linux C Libraryx   1 root root  4070406 Jul
30 21:41 /lib/libc.so.6
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount  2.10q
Net-tools  1.56
Kbd0.99
Sh-utils   2.0
Modules Loaded snd-pcm-oss snd-pcm-plugin
snd-mixer-oss tuner tvaudio bttv videodev ppp_deflate
bsd_comp ppp_async ppp_generic snd-card-via686a snd-pcm
snd-timer snd-mpu401-uart snd-rawmidi snd-seq-device
snd-ac97-codec snd-mixer snd ipv6 3c59x hisax isdn slhc
AM53C974 ide-scsi usb-uhci usbcore

-2.) processor  : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 5
model name  : Pentium II (Deschutes)
stepping: 2
cpu MHz : 350.000809
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
features: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge
mca cmov pat pse36 mmx fxsr
bogomips: 699.60

-3.) snd-pcm-oss18352   0 (autoclean)
snd-pcm-plugin 14672   0 (autoclean) [snd-pcm-oss]
snd-mixer-oss   5120   1 (autoclean) [snd-pcm-oss]
tuner   3232   1 (autoclean)
tvaudio 7792   0 (autoclean) (unused)
bttv   54768   1 (autoclean)
videodev4512   3 (autoclean) [bttv]
ppp_deflate39200   0 (autoclean)
bsd_comp4160   0 (autoclean)
ppp_async   6224   1 (autoclean)
ppp_generic13024   3 (autoclean) [ppp_deflate
bsd_comp ppp_async]
snd-card-via686a7408   1 (autoclean)
snd-pcm31776   0 (autoclean) [snd-pcm-oss
snd-pcm-plugin snd-card-via686a]
snd-timer   8512   0 (autoclean) [snd-pcm]
snd-mpu401-uart 2640   0 (autoclean) [snd-card-via686a]
snd-rawmidi10144   0 (autoclean) [snd-mpu401-uart]
snd-seq-device  3744   0 (autoclean) [snd-rawmidi]
snd-ac97-codec 24288   0 (autoclean) [snd-card-via686a]
snd-mixer  24208   0 (autoclean) [snd-mixer-oss snd-ac97-codec]
snd36384   1 [snd-pcm-oss snd-pcm-plugin
snd-mixer-oss snd-card-via686a snd-pcm snd-timer
snd-mpu401-uart snd-rawmidi snd-seq-device sc97-codec snd-mixer]
ipv6  113296  -1 (autoclean)
3c59x  22192   1 (autoclean)
hisax 146608   5
isdn   98912   6 [hisax]
slhc4592   2 [ppp_generic isdn]
AM53C974   12096   0 (unused)
ide-scsi7840   0
usb-uhci   21424   0 (unused)
usbcore49344   1 [usb-uhci]

-4.) -001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
0240-025f : avm PnP
02f8-02ff : serial(auto)
0320-0321 : VIA 82C686A - MPU401
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
c000-cfff : PCI Bus #01
  c000-c0ff : ATI Technologies Inc Rage 128 RF
d000-d00f : VIA Technologies, Inc. Bus Master IDE
  d000-d007 : ide0
  d008-d00f : ide1
d400-d41f : VIA Technologies, Inc. UHCI USB
  d400-d41f : usb-uhci
dc00-dcff : VIA Technologies, Inc. AC97 Audio Controller
  dc00-dcff : VIA 82C686A - AC'97
e000-e003 : VIA Technologies, 

Broken link in configure help

[Andrew Stubbs]

The link inside configure help for ip tunneling
"http://anchor.cs.binghamton.edu/~mobileip/LJ/index.html"
appears to be non-existent

Andrew

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

Re: Announce: modutils 2.3.21 is available

[Thomas Molina]

On Wed, 22 Nov 2000, David Ford wrote:

> > >   * Remove compile warnings in xstrcat.
> > >   * snprintf cleanups.
> > >   * Set safemode when uid != euid.
> > >   * Strip quotes from shell responses.
> > + add RedHat ism's with a --rhc (red hat compatible) -i -m (-F)
> >
> > RedHat kind of is the standard in the commercial world in the US.
>
> I don't think it's necessary or appropriate to taylor things for a particular
> distribution even if it may unfortunately be 'standard' for some people.

Zackerly.  My system will certainly look like a RedHat system; it's
based on one.  However (particularly with regards to kernels and
modules), I can almost guarantee it won't react like a RedHat system.

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

Re: Rik's bad process killer - how to kill _IT_?

[Daniel Stone]

> > Daniel Stone
> > Linux Kernel Developer
>   ^^
> 
> If you were, you'd have written something that makes sense.

Touche. I didn't claim to be a Linus, but I have got a few things in the
kernel (sb16 driver, netfilter). Plus you can't ask much when I've gone 5
days without sleep just studying. Better than being kicked out of #Linux
(Undernet) for trolling, though.
 
> 1. my OOM killer *always* spits out a message when it kills
>something

3 other people have pointed this out to me.

> 2. you haven't written what kernel version you're using;
>judging from your lack of error messages you're running
>2.2 (which has the nasty habit of killing processes under
>heavy load ... I have a patch out which fixes that)

2.4.0-test11.


--
Daniel Stone
Linux Kernel Developer
[EMAIL PROTECTED]

-BEGIN GEEK CODE BLOCK-
Version: 3.1
G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o
K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ 
D+ G e->++ h!(+) r+(%) y? UF++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/