Re: CDROMPLAYTRKIND causes an oops on aic7xxx

2000-11-26 Thread Jens Axboe

On Sun, Nov 26 2000, Brian Gerst wrote:
> I get an oops from aic7xxx_buildscb() when CDROMPLAYTRKIND is used. 
> I've tracked it down to sr_audio_ioctl() using SCSI_DATA_NONE for the
> direction of the command, which gets changed to PCI_DMA_NONE, which then
> triggers a BUG() in pci_map_single().  Is SCSI_DATA_NONE the correct
> direction code, or is there a problem further down the code?  Oops
> attached.

NONE is the right direction, but buflen needs to be 0 too. The
patch is here

*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0-test11/cd-1.bz2


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



Re: initdata for modules?

2000-11-26 Thread Jakub Jelinek

On Mon, Nov 27, 2000 at 09:54:57AM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 07:30:44 -0800, 
> "Adam J. Richter" <[EMAIL PROTECTED]> wrote:
> > In reading include/linux/init.h, I was surprised to discover
> >that __init{,data} expands to nothing when compiling a module.
> >I was wondering if anyone is contemplating adding support for
> >__init{,data} in module loading, to reduce the memory footprints
> >of modules after they have been loaded.
> 
> It has been discussed a few times but nothing was ever done about it.

Well, I've actually implemented it few years ago and even current modutils
you maintain support that already (see runsize member of struct module and
how is it assigned). __init stuff was not stored in a separate page and was
initially vmalloced together with the whole module, the only vm addition was
a shrink for a vmalloc area where it would free some pages from the end of
the area.
It lived in sparclinux-cvs for quite some time, but Linus have not accepted
it (I've posted several times).
I can dig the patch out of sparclinux CVS if anyone is interested.

Jakub
-
To unsubscribe from this list: send the 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] removal of "static foo = 0"

2000-11-26 Thread Adam J. Richter

Michael Meissner wrote:
>On Sat, Nov 25, 2000 at 11:55:11PM +, Tim Waugh wrote:
>> On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:
>> 
>> > Which is silly. The variable is explicitly defined to be zero
>> > anyway, whether you put this in your code or not.
>> 
>> Why doesn't the compiler just leave out explicit zeros from the
>> 'initial data' segment then?  Seems like it ought to be tought to..
>
>Because sometimes it matters.  For example, in kernel mode (and certainly for
>embedded programs that I'm more familiar with), the kernel does go through and
>zero out the so called BSS segment, so that normally uninitialized static
>variables will follow the rules as laid out under the C standards (both C89 and
>C99).  I can imagine however, that the code that is executed before the BSS
>area is zeroed out needs to be extra careful in terms of statics that it
>references, and those must be hand initialized.

Since that code is already careful to hand initialize what
it needs and explicitly zeroes the BSS, that sounds like an argument
that it *is* safe to change gcc to move data that is intialized to
all zeroes into bss, either as a compiler option or even not
optionally.

I am not a gcc hacker, but it looks to me like one could
copy the code from output_constant and the functions that it
calls (in gcc-2.95.2/gcc/gcc/varasm.c) to walk the tree to figure
out if the data was all zeroes.  I even started writing a routine
for assemble_variable to call to try to test just for the integer case
(basically just by cutting and pasting code).  I include it here just
to illustrate.  Note: this code doesn't even type check properly when
I try to compile it, so I know it's very wrong, but it's as good as
posting pseudo code to explain my thinking).

void
clear_zero_initialization(tree decl)
{
tree exp = DECL_INITIAL(decl);
enum tree_code code;

if (exp == NULL)
return;

code = TREE_CODE (TREE_TYPE (exp));
if (lang_expand_constant)
exp = (*lang_expand_constant) (exp);

while ((TREE_CODE (exp) == NOP_EXPR
&& (TREE_TYPE (exp) == TREE_TYPE (TREE_OPERAND (exp, 0))
|| AGGREGATE_TYPE_P (TREE_TYPE (exp
   || TREE_CODE (exp) == NON_LVALUE_EXPR)
exp = TREE_OPERAND (exp, 0);

if (code == INTEGER_TYPE && exp == const0_rtx)
DECL_INITIAL(decl) = NULL;
}


At the moment, I have started daydreaming about instead
writing an "elf squeezer" to do this and other space optimizations
by modifying objdump.  However, I do think that such an improvement
to gcc would be at least a bit useful to the larger user base than
just those people who use binutils-based systems.

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: ext2 filesystem corruptions back from dead? 2.4.0-test11

2000-11-26 Thread Neil Brown

On Friday November 24, [EMAIL PROTECTED] wrote:
> 
> 
> On Fri, 24 Nov 2000, Neil Brown wrote:
> 
> > I ran my test script, which builds a variety of raid5 arrays with
> > varying numbers of drives and chunk sizes, and runs mkfs/bonnie/dbench
> > on each array, and it got through about 8 file systems but choked on
> > the 9th by trying to allocate lots of blocks in the system zone (after
> > running for about an hour). 
> 
> Bloody interesting. I don't see anything recent that could affect the
> areas in question. Intersting versions to check: 11-pre5 and 11-pre6.
> It smells like buffer cache corruption, but I don't see anything
> relevant. __generic_unplug_device() change loock pretty innocent,
> ditto for bh_kmap() ones in raid5 and on ext2 side we had two obviously
> equivalent replacements (pre5->pre6). No buffer.c changes, no VM ones.
> Urgh.

Turns out my data is a false alarm.  It was a bug in my raid5 code -
and not a recent bug either - that was causing my filesystem
corruption.

So if your earlier patches work for everybody else then they look like
a good way to go.  I have fixed my fatal flaw and I cannot reproduce
the problems any more.  Patch has gone to Alan.

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



Re: Universal debug macros.

2000-11-26 Thread Michael Meissner

On Sun, Nov 26, 2000 at 08:25:38PM -0800, H. Peter Anvin wrote:
> Followup to:  <[EMAIL PROTECTED]>
> By author:Elmer Joandi <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> > 
> > Red Hat will ship two kernels. Well, they actually ship now about 4 ones
> > or something. So they will ship 8.
> > 
> 
> Something RedHat & co may want to consider doing is providing a basic
> kernel and have, as part of the install procedure or later, an
> automatic recompile and install kernel procedure.  It could be
> automated very easily, and on all but the very slowest of machines, it
> really doesn't take that long.

(Note, I work in the GCC group, not the Linux group, so the following is MHO,
and not Red Hat gospel).

Assuming you've installed the compiler/other relevant tools, installed the
kernel source, and have enough disk space to build the kernel.  This would
screw people wanting to install Linux on their old 386/486/pentium for use as a
firewall or web server.  For example, the machine I'm planning on moving a web
server to only has 2 gig of disk.  Right now, I have barely enough space to
hold the compiler tools plus web pages I want to serve.  If I was serving much
more content, I would probably chuck the compiler tools/kernel source.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: syslinux and 2.4.0 initrd size problems

2000-11-26 Thread Jeff V. Merkey

On Sun, Nov 26, 2000 at 08:22:54PM -0800, H. Peter Anvin wrote:

> Why are you posting this to the kernel list?  See the SYSLINUX
> documentation for the SYSLINUX mailing list address.

Never mind.  I am rewriting the install init program instead and 
restructuring the driver organization to do what I need.  

Jeff

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



Re: Universal debug macros.

2000-11-26 Thread H. Peter Anvin

Followup to:  <[EMAIL PROTECTED]>
By author:Elmer Joandi <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Red Hat will ship two kernels. Well, they actually ship now about 4 ones
> or something. So they will ship 8.
> 

Something RedHat & co may want to consider doing is providing a basic
kernel and have, as part of the install procedure or later, an
automatic recompile and install kernel procedure.  It could be
automated very easily, and on all but the very slowest of machines, it
really doesn't take that long.

-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: syslinux and 2.4.0 initrd size problems

2000-11-26 Thread H. Peter Anvin

Followup to:  <[EMAIL PROTECTED]>
By author:"Jeff V. Merkey" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> I am having trouble getting a 2.4 vmlinuz (bzImage) and initrd 
> image onto a 1.44 floppy with all the new stuff.  Even a stipped 
> down kernel compiled under 2.4 is @ 600K compressed, and I need 
> about 800K for the initrd image.  I noticed that syslinux 
> has some comments about not allowing initrd to span media.  
> 
> I there something more current that does or will allow me to
> load the inittrd off a CD-ROM device (with vmlinuz and syslinux
> on the floppy).   I know how to do this with GRUB (Grand 
> Unified Boot Loader), but I want to use syslinux if possible. 
> 

Why are you posting this to the kernel list?  See the SYSLINUX
documentation for the SYSLINUX mailing list address.

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



CDROMPLAYTRKIND causes an oops on aic7xxx

2000-11-26 Thread Brian Gerst

I get an oops from aic7xxx_buildscb() when CDROMPLAYTRKIND is used. 
I've tracked it down to sr_audio_ioctl() using SCSI_DATA_NONE for the
direction of the command, which gets changed to PCI_DMA_NONE, which then
triggers a BUG() in pci_map_single().  Is SCSI_DATA_NONE the correct
direction code, or is there a problem further down the code?  Oops
attached.

-- 

Brian Gerst

ksymoops 2.3.4 on i686 2.4.0-test11-ac2.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test11-ac2/ (default)
 -m /boot/System.map-2.4.0-test11-ac2 (specified)

invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210086
eax: 0030   ebx:    ecx:    edx: 0008
esi: c14fee62   edi: c14fee00   ebp: cff2c000   esp: ca667960
ds: 0018   es: 0018   ss: 0018
Process heretic2 (pid: 859, stackpage=ca667000)
Stack: c02502c2 c025035f 003d cff2e800 c14fee00 cff2c000 c147b878 0001 
   0200 c1470002 c147b8d8 c01bb79c c147b878 c14fee00 cff2e800 00200246 
   cf59cdd4 c147b800 c14fee00 c019afa0 c019b006 c14fee00 c019fba0 c14fee00 
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] 
Code: 0f 0b 83 c4 0c 8d b4 26 00 00 00 00 8d 93 00 00 00 40 8b 4c 

>>EIP; c01bb654<=
Trace; c02502c2 
Trace; c025035f 
Trace; c01bb79c 
Trace; c019afa0 
Trace; c019b006 
Trace; c019fba0 
Trace; c01a141c 
Trace; c01a089a 
Trace; c019b1c2 
Trace; c019b0c2 
Trace; c019ab90 
Trace; c01c1e2c 
Trace; c01c25c6 
Trace; c01c9ede 
Trace; c0120f40 
Trace; c0111320 
Trace; c0111320 
Trace; c012239b 
Trace; c0196708 
Trace; c01908c4 
Trace; c0196708 
Trace; c01908c4 
Trace; c0196708 
Trace; c0196050 
Trace; c0196550 
Trace; c019ab30 
Trace; c019ab4e 
Trace; c01908c4 
Trace; c0196708 
Trace; c0196050 
Trace; c0196550 
Trace; c019ab30 
Trace; c019ab4e 
Trace; c0195128 
Trace; c019ab30 
Trace; c01919e0 
Trace; c0191a39 
Trace; c017fad9 
Trace; c0120dc0 
Trace; c0120f40 
Trace; c0111320 
Trace; c0121849 
Trace; c0171714 
Trace; c017e9f9 
Trace; c011212c 
Trace; c011223a 
Trace; c0112292 
Trace; c011b260 
Trace; c011254d 
Trace; c011b2a0 
Trace; c011ecec 
Trace; c010f016 
Trace; c011befb 
Trace; c01363b6 
Trace; c013cb56 
Trace; c0136390 
Trace; c010ae37 
Code;  c01bb654 
 <_EIP>:
Code;  c01bb654<=
   0:   0f 0b ud2a  <=
Code;  c01bb656 
   2:   83 c4 0c  add$0xc,%esp
Code;  c01bb659 
   5:   8d b4 26 00 00 00 00  lea0x0(%esi,1),%esi
Code;  c01bb660 
   c:   8d 93 00 00 00 40 lea0x4000(%ebx),%edx
Code;  c01bb666 
  12:   8b 4c 00 00   mov0x0(%eax,%eax,1),%ecx




Re: [PATCH] removal of "static foo = 0"

2000-11-26 Thread Michael Meissner

On Sat, Nov 25, 2000 at 11:55:11PM +, Tim Waugh wrote:
> On Sat, Nov 25, 2000 at 10:53:00PM +, James A Sutherland wrote:
> 
> > Which is silly. The variable is explicitly defined to be zero
> > anyway, whether you put this in your code or not.
> 
> Why doesn't the compiler just leave out explicit zeros from the
> 'initial data' segment then?  Seems like it ought to be tought to..

Because sometimes it matters.  For example, in kernel mode (and certainly for
embedded programs that I'm more familiar with), the kernel does go through and
zero out the so called BSS segment, so that normally uninitialized static
variables will follow the rules as laid out under the C standards (both C89 and
C99).  I can imagine however, that the code that is executed before the BSS
area is zeroed out needs to be extra careful in terms of statics that it
references, and those must be hand initialized.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send 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] (test11-ac4) unbelievably silly (fatal) typo in raid5.c

2000-11-26 Thread Neil Brown


Alan,
 raid5 rebuild has been fatally flawed ever since it got into 2.4, and
 my recent testing has been looking at speed more than correctness, so
 I didn't notice until now.

 raid5_sync_request is handed a block number in 1K units and needs to 
 convert to 512byte sector units.
 I could have used   (block_nr*2)
 I could have used   (block_nr<<1)
 but instead I used  (block_nr<<2)    :-(

Please apply the following patch.

Thanks, 
NeilBrown

--- ./drivers/md/raid5.c2000/11/27 02:46:45 1.1
+++ ./drivers/md/raid5.c2000/11/27 02:47:37 1.2
@@ -1516,8 +1516,8 @@
raid5_conf_t *conf = (raid5_conf_t *) mddev->private;
struct stripe_head *sh;
int sectors_per_chunk = conf->chunk_size >> 9;
-   unsigned long stripe = (block_nr<<2)/sectors_per_chunk;
-   int chunk_offset = (block_nr<<2) % sectors_per_chunk;
+   unsigned long stripe = (block_nr<<1)/sectors_per_chunk;
+   int chunk_offset = (block_nr<<1) % sectors_per_chunk;
int dd_idx, pd_idx;
unsigned long first_sector;
int raid_disks = conf->raid_disks;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



access() says EROFS even for device files if /dev is mounted RO

2000-11-26 Thread Peter Cordes


 While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
that open(1) doesn't work when / is mounted read only.  It complains that it
"Cannot open /dev/tty2 read/write"...

 I straced it:
 
execve("/usr/bin/open", ["open"], [/* 13 vars */]) = 0
...
brk(0x804c000)  = 0x804c000
open("/dev/tty", O_RDWR)= -1 ENXIO (No such device or address)
open("/dev/tty0", O_RDWR)   = 4
ioctl(4, KDGKBTYPE, 0xbcdb) = 0
ioctl(4, VT_GETSTATE, 0xbda4)   = 0
ioctl(4, VT_OPENQRY, 0xbd90)= 0
open("/dev/tty2", O_RDWR)   = 5
close(5)= 0


access("/dev/tty2", R_OK|W_OK)  = -1 EROFS (Read-only file system)


write(2, "Cannot open /dev/tty2 read/write"..., 57) = 57
_exit(5)= ?


 However, this is wrong.  You _can_ write to device files on read-only
filesystems.  (open shouldn't bother calling access(), but the kernel should
definitely give the right answer!)  Running
(bash < /dev/tty2 &>/dev/tty2 &)
will work (but for reasons unknown to me it won't do job control or handle
^C, etc.)

 I'm pretty sure the problem is in linux/fs/open.c, in sys_access():
...
int res = -EINVAL;
...
dentry = namei(filename);
res = PTR_ERR(dentry);
if (!IS_ERR(dentry)) {
res = permission(dentry->d_inode, mode);
/* SuS v2 requires we report a read only fs too */

if(!res && (mode & S_IWOTH) && IS_RDONLY(dentry->d_inode))

res = -EROFS;
dput(dentry);
}
...
return res;
 
 I think the  if( !res ... )  line is the problem.  I think the fix is to
add a check that the file is not a device file, socket, named pipe, or a
symlink to a file on a non-readonly FS (unless permission already follow
links?  There's probably some file type I didn't think of that needs to get
checked, too.).  

 I'm don't know what macro to use, since I don't have much kernel hacking
experience (yet ;), so I'll leave the fix for someone who knows what
they're doing :->

 BTW, this is in a 2.2.17 kernel on an IA32 machine.
 
 Please CC me on any replies, since I'm not subscribed to the list.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X([EMAIL PROTECTED] , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



syslinux and 2.4.0 initrd size problems

2000-11-26 Thread Jeff V. Merkey



I am having trouble getting a 2.4 vmlinuz (bzImage) and initrd 
image onto a 1.44 floppy with all the new stuff.  Even a stipped 
down kernel compiled under 2.4 is @ 600K compressed, and I need 
about 800K for the initrd image.  I noticed that syslinux 
has some comments about not allowing initrd to span media.  

I there something more current that does or will allow me to
load the inittrd off a CD-ROM device (with vmlinuz and syslinux
on the floppy).   I know how to do this with GRUB (Grand 
Unified Boot Loader), but I want to use syslinux if possible. 

Thanks

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



Re: [PATCH] modutils 2.3.20 and beyond

2000-11-26 Thread Jeff V. Merkey

On Mon, Nov 27, 2000 at 02:11:49AM +, Alan Cox wrote:
> > > Anaconda will barf and require over 850+ changes to the scripts without
> > > it.  If you look at the patch, you will note that it's a silent switch
> > > that's only there to avoid a noisy error message from depmod.  It
> > > actually does nothing other than set a flag that also does nothing.
> > > -m simply maps to -F.
> > 
> > It's still a bad precedent.  Anaconda should have been written correctly in
> > the first place.
> 
> I don't know if its an Anaconda issue or a limitation in the tools. Keith is
> the modutils maintainer and its up to the Anaconda hackers to prove to him that
> he has a problem so I think he is absolutely right in refusing to change it
> until that is proven

Oddly, the tools already provide the capability needed by anaconda, just 
not in the format the anaconda scripts and code expect.  i.e., anaconda 
is using -m in place of -F, and somewhere down the line someone needed 
to force depmod checks of modules against mismatched kernels (???) which is
probably left over from some point when RedHat was shipping default
kernels "naked" (without modversions).  That's the only justification
I can see for having -i at all, and since I come from a binary compatible
world, I can kindof understand why someone would have needed this 
to support loading of binary modules accross versions (before modversions 
became widely used).  I don't know how to take the "anaconda hacker" moniker.

Jeff






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



Re: initdata for modules?

2000-11-26 Thread Jeff V. Merkey

On Mon, Nov 27, 2000 at 01:06:04PM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 19:49:43 -0700, 
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Microsoft drivers have an .INIT code section that is initialization 
> >ccode that get's chunked after it's loaded.  Their model allows 
> >memory segments to be defined as DISCARDABLE, which tells the loader
> >to chunk them after they get loaded in portable executable format.  
> 
> The loader is insmod, which does all its own reloaction and loading.
> The problem is that ancillary tools like ksymoops, gdb, kdb and
> possibly others do not expect sections to be discarded after load.
> Adding the feature to insmod is fairly easy, fixing the ancillary tools
> to understand that some sections are discarded after load is a bit
> harder.  Debugging is particularly messy, when an oops occurs how do we
> tell if the __init data been discarded yet or not?
> 
> I have added this to my investigation list for modutils, ksymoops and
> kdb 2.5, no promises.


:-)

Jeff

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



Re: [BUG] 2.4.0-test11-ac3 breaks raid autodetect (was Re: [BUG] raid5 link error? (was [PATCH] raid5 fix after xor.c cleanup))

2000-11-26 Thread Neil Brown

On Sunday November 26, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> >
> > The following patch changes the link order in the Makefile so that xor
> > is initiailised before md tries to autostart anything.
> > It also takes the theme a bit further and uses module_init/module_exit
> > to init and shutdown the raid personalities.  This allows us to remove
> > the explicit calls to raidXX_init from md.c, which is nice.
> > 
> > I have tested this patch both
> >1/ monolithic kernel and autodetecting an array
> >2/ md and all personalities modules
> > 
> > and it works fine.
> 
> Sorry to tell you that I just tried linux-2.4.0-test11-ac3 (which has this
> patch) and I couldn't boot because the kernel detects the raid1 devices
> but kicks the shortly after. I had to back out this code.

Thanks for this

I have looked more deeply, and discovered the error of my ways.
As the Makefiles now stand, all export-objs (OX_OBJS) get linked
before non-export-objs (O_OBJS) in the same directory, independantly
of any ordering imposed within the Makefile.
This caused md.o to get linked before raid?.o.
Due to carelessness on my part I didn't notice this happening when I
was testing.

The following patch fixes it.  I hope the change to Rules.make is
acceptable - I have CCed to linux-kbuild incase anyone there has an
issue with it.

Even allowing for that though, some of the boot-time messages look
very strange.  Friedrich: could you let me know how the various
partitions were expected to be combined into raid arrays - from the
boot log, it looks like there are three single drive raid1 arrays, and
that doesn't seem to make much sense.

NeilBrown

--- ./drivers/md/Makefile   2000/11/27 02:05:52 1.1
+++ ./drivers/md/Makefile   2000/11/27 02:09:42 1.2
@@ -28,6 +28,9 @@
 # Translate to Rules.make lists.
 O_OBJS := $(filter-out $(export-objs), $(obj-y))
 OX_OBJS:= $(filter $(export-objs), $(obj-y))
+# Need to maintain ordering between O_ and OX_ objects, so define ALL_O our selves
+ALL_O  := $(obj-y)
+
 M_OBJS := $(sort $(filter-out $(export-objs), $(obj-m)))
 MX_OBJS:= $(sort $(filter  $(export-objs), $(obj-m)))
 
--- ./Rules.make2000/11/27 02:08:52 1.1
+++ ./Rules.make2000/11/27 02:09:42 1.2
@@ -85,7 +85,9 @@
 # Rule to compile a set of .o files into one .o file
 #
 ifdef O_TARGET
+ifndef ALL_O
 ALL_O = $(OX_OBJS) $(O_OBJS)
+endif # ALL_O
 $(O_TARGET): $(ALL_O)
rm -f $@
 ifneq "$(strip $(ALL_O))" ""
-
To unsubscribe from this list: send the 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] modutils 2.3.20 and beyond

2000-11-26 Thread Alan Cox

> > Anaconda will barf and require over 850+ changes to the scripts without
> > it.  If you look at the patch, you will note that it's a silent switch
> > that's only there to avoid a noisy error message from depmod.  It
> > actually does nothing other than set a flag that also does nothing.
> > -m simply maps to -F.
> 
> It's still a bad precedent.  Anaconda should have been written correctly in
> the first place.

I don't know if its an Anaconda issue or a limitation in the tools. Keith is
the modutils maintainer and its up to the Anaconda hackers to prove to him that
he has a problem so I think he is absolutely right in refusing to change it
until that is proven

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



Re: initdata for modules?

2000-11-26 Thread Keith Owens

On Sun, 26 Nov 2000 19:49:43 -0700, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Microsoft drivers have an .INIT code section that is initialization 
>ccode that get's chunked after it's loaded.  Their model allows 
>memory segments to be defined as DISCARDABLE, which tells the loader
>to chunk them after they get loaded in portable executable format.  

The loader is insmod, which does all its own reloaction and loading.
The problem is that ancillary tools like ksymoops, gdb, kdb and
possibly others do not expect sections to be discarded after load.
Adding the feature to insmod is fairly easy, fixing the ancillary tools
to understand that some sections are discarded after load is a bit
harder.  Debugging is particularly messy, when an oops occurs how do we
tell if the __init data been discarded yet or not?

I have added this to my investigation list for modutils, ksymoops and
kdb 2.5, no promises.

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

2000-11-26 Thread Tom Rini

On Sun, Nov 26, 2000 at 07:46:43PM -0700, Jeff V. Merkey wrote:

> Anaconda is open sourced, so it's not technically tied to any one 
> distributor any more

Technically, yes it is opensourced.  But one of the things that does kinda
distinguish one distro from another is the installer[1].

So yes, it is opensource.  So, counter-question.  Why should this non
distro owned program require a specific distro's program? :)   But this all
of course a moot point.

[1] The sum difference between YellowDogLinux 1.0, LinuxPPC, Inc 1999 and
LinuxPPC Reference Release was that two changed/help port the installer the
3rd did, which was RedHat's newt-based installer.  Some confusion ensused.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: initdata for modules?

2000-11-26 Thread Jeff V. Merkey

On Sun, Nov 26, 2000 at 03:47:30PM -0800, Adam J. Richter wrote:
> Keith Owens <[EMAIL PROTECTED]> wrote:
> >"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
> >>In reading include/linux/init.h, I was surprised to discover
> >>that __init{,data} expands to nothing when compiling a module.
> >>I was wondering if anyone is contemplating adding support for
> >>__init{,data} in module loading, to reduce the memory footprints
> >>of modules after they have been loaded.
> 
> >It has been discussed a few times but nothing was ever done about it.
> >AFAIK the savings were not seen to be that important because modules
> >occupy complete pages.  __init would have to be stored in a separate
> >page which was then discarded. [...]
> 
>   No, you could just discard the part after the next page
> boundary.  The expected savings would be about the same, since
> the cases where the original code had just creeped over a page
> boundary in many cases would result in dropping more memory savings
> that the actual init size, from dropping those unused bytes
> between the very end of the init section and the end of that page.
> I say "about" the same becuase the distribution of text and data
> sizes is not uniformly random within some fixed interval.
> 
>   Since you would not have to bump the start address of a
> section to the next page boundary, I wonder if it would still
> complicate insmod et al.
> 
>   In case there is any confusion, I am not suggesting that
> this should go into the stock 2.4.0 releases.
> 
>   However, I do find it helpful in allocating my time to
> cosider that saving one page by something like this or by enhancing
> gcc's variable placement saves as much space as 1024 eliminations
> of "= 0" or "= NULL" static variable initializations.


Microsoft drivers have an .INIT code section that is initialization 
ccode that get's chunked after it's loaded.  Their model allows 
memory segments to be defined as DISCARDABLE, which tells the loader
to chunk them after they get loaded in portable executable format.  

If ELF has something like it, perhaps it should go in the loader?

Jeff





> 
> 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/
-
To unsubscribe from this list: send the 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] modutils 2.3.20 and beyond

2000-11-26 Thread Jeff V. Merkey

On Sun, Nov 26, 2000 at 04:16:26PM -0800, David Ford wrote:
> "Jeff V. Merkey" wrote:
> 
> > On Sun, Nov 26, 2000 at 06:02:35PM -0500, Mohammad A. Haque wrote:
> > > I'd rather have Anaconda changed rather than special casing standard
> > > utils to account for distro handling.
> >
> > Great.  Then tell RedHat to rewrite it without the need for these switches.
> > They will say NO.  It's a trivial change, and would save me a lot of hours
> > rewriting scripts.  I did it once, but if RedHat has standardized on this
> > set of switches, why not add them as alias commands?  It's a trivial
> > patch.
> 
> Then let RedHat maintain their version of modutils.  RedHat isn't the
> standard, nor should RedHat dictate to authors, nor should other distributions
> and persons be affected by RedHat's methods.
> 
> If you don't like it, replace your depmod with a script that strips that flag
> before calling the original depmod.

Anaconda is open sourced, so it's not technically tied to any one 
distributor any more

Jeff

> 
> -d
> 

Content-Description: Card for David Ford

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



Re: initdata for modules?

2000-11-26 Thread Jeff V. Merkey

On Mon, Nov 27, 2000 at 10:45:34AM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 17:01:35 -0700, 
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >insmod ppp_deflate (should trigger load of all these modules).  I 
> >know it's works this way if there's a modules.dep file laying 
> >around, but it would be nice for it to work this way without 
> >needing the external text file.
> 
> There is a clean split between modprobe and insmod, modprobe is the
> high level command that does all the fancy checking for inter module
> dependencies, handling aliases and extracting options from
> modules.conf.  insmod is the low level command that does exactly what
> you tell it to do, no more, no less.  The only smarts that insmod has
> is the ability to take a module name without '/' and find it using the
> patchs in modules.conf.  That split between high and low level commands
> is too useful to contaminate.
> 
> modules.conf already supports "above" and "below" commands for
> non-standard dependencies.  The problem of not having a module.dep on
> the first boot of a new kernel was addressed in kernel 2.4.0-test5 or
> thereabouts, make modules_install runs depmod to build modules.dep
> ready for the first boot.


Good.  I am glad this is being addressed.

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



Re: [PATCH] modutils 2.3.20 and beyond

2000-11-26 Thread Jeff V. Merkey

On Mon, Nov 27, 2000 at 10:23:08AM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 16:36:55 -0700, 
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Keith,
> >
> >Please consider the attached patch for inclusion in all future versions
> >of the modutils depmod program for compatiblity with RedHat and 
> >RedHat derived Linux distributions.
> 
> I have a big problem with Redhat.  They make incompatible changes to
> utilities, do not feed patches back to maintainers then expect the rest
> of the world to follow their lead.  The -i and -m flags to modutils are
> not the only example, I recently found IA64 and Sparc patches they had
> added to modutils code and not bothered to tell me.  Other distributors
> are much better about sending me patches, Debian and SuSe in particular
> do the right thing.
> 
> Since "-F System.map" in modutils is equivalent to "-m System.map -i"
> and works on all distributions, not just Redhat, the "-m -i" patch is
> unnecessary.  Consider this my protest against bad habits by
> distributors, they created the mess with their lack of communication
> and they have to fix it.

Well Keith, I will never fail to post back changes to you, as evidenced
by the fact I did send you one.  Anconda is open sourced, and as such,
is no longer owned by any distributor.  The question is whether to 
diverge it from theirs.  I would like to not do this, since, as you
point out, it generates changes back the other way.   

It's your call.  I can keep the patch around because I really don't 
want to diverge anaconda any more than I have to.  At some point,
perhaps they will get changes to you more timely.  

:-)

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



Re: [PATCH] modutils 2.3.20 and beyond

2000-11-26 Thread Jeff V. Merkey

On Sun, Nov 26, 2000 at 04:15:02PM -0700, Tom Rini wrote:
> On Sun, Nov 26, 2000 at 05:03:34PM -0700, Jeff V. Merkey wrote:
> 
> > Great.  Then tell RedHat to rewrite it without the need for these switches.
> > They will say NO.  It's a trivial change, and would save me a lot of hours
> > rewriting scripts.  I did it once, but if RedHat has standardized on this
> > set of switches, why not add them as alias commands?  It's a trivial 
> > patch.
> 
> I hate to jump in here in the middle of a perfectly good argument but I'd like
> to point out a few things:
> a) If RedHat/RedHat-like distros needs these changes they can include this
> patch.  The plus side is it won't piss off the people that seem to care and
> don't use said distros the down side is that if/when another security update
> comes out people will have to hope this patch applies easily still, if they
> update themselves.
> b) Are these switches which used to be valid in modutils 2.3.x?  If so, why?
> It makes perfect sense to keep this patch around until modutils 2.4 (or 2.5
> if modutils version is still supposed to match kernel version).  If these
> are old modutils 2.2.x switches, see part a).
> And c) Why does it matter if RedHat/etc would have to adapt their scripts.
> There's always part a, or what debian does for stable sometimes, backporting
> fixes.  Or even lots of sed & awk magic.

Oh well.  Look like %patch -p1 in the rpm for now.

Jeff

> 
> -- 
> Tom Rini (TR1265)
> http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



RTlinux & Linux Question

2000-11-26 Thread Mastoras

Hello,

I'm trying to use RTlinux to make a unix process wakeup 
periodicaly, in terms of "real time".

1) the unix process uses 2 system calls, one to make it self periodic, and
one to suspend its self until the next period.

2) The system call that makes the unix process periodic, creates a Rtlinux
thread, which is periodic with the same period.

3) The periodic RT linux thread, sets a flag & sends fakes IRQ0 to linux,
in order to force its scheduling as soon as possible and then suspends it
self. (i know that this advances time, but this is not the question right
now).

4) The unix process wakeups perfectely when there is no disk activity, but
when there is some disk activity ("find /" and/or "updatedb") or the
period is too small (300us) i noticed that sometimes it loses one or two
periods. This is very rare, i mean 14 loses in 5000 executions at 5ms
period.

5) The unix process isn't scheduled the appropriate time although that
every IRQ is received by linux correctly, the myprocess->counter is
initialized to a very high value (in each period) and
current->need_resched is set to 1.

6) I don't want to use PSC.


I believe that there is somekind of race conditions during the
bottom halves or something else that i haven't though. Your help would be
very valuable, though this might not be a strictly RT linux question.

TIA
[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: ATA-4, ATA-5 TCQ status

2000-11-26 Thread Andre Hedrick

On Mon, 27 Nov 2000, Jens Axboe wrote:

> On Mon, Nov 27 2000, Sasi Peter wrote:
> > Hi!
> > 
> > I would like to ask if the tagged command queueing capability in the
> > decent ATA standards is utilized in the linux IDE driver (2.2 2.2ide
>   ^^
> > patches, or 2.4 maybe...)?
> 
> I hope that is supposed to be 'recent', because with the current TCQ
> implementation listed in the specs Linux might as well not support it :)
> It's simply not worth it.

Exactly, Jens has seen the ugly beast because I have worked on coding it.
I am working to get IBM to change the method of doing this to make it
sane, but its not now.

Cheers,

Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development

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



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

2000-11-26 Thread Andre Hedrick

On Sun, 26 Nov 2000, Christian Roessner wrote:

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

This is what it tells you directly.  You have dirty crosstalk on your
ribbon.  Basically nothing is wrong, except you can not safely support
that transfer rate.

Cheers,

Andre Hedrick
Linux ATA Development

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



Re: Universal debug macros.

2000-11-26 Thread Elmer Joandi



On Mon, 27 Nov 2000, Rogier Wolff wrote:

> Now, how is say "Red Hat" (*) going to ship kernels? Of course they are
> going to turn off debugging. Then I'll be stuck with a non-recompiling
> user-in-trouble with a non-debugging-enabled kernel. 

Red Hat will ship two kernels. Well, they actually ship now about 4 ones
or something. So they will ship 8.

Plus they will ship a script that recompiles kernel without user crawling
in documentation.
It should be an option in linuxconf: recompile local kernel:
debug-nodebug-optimized-localized-nonmodular-server-router-workstation
which compiles and installs 2  hardware/situation optimized/configured
kernels: debug and production.
I am sure company like redhat can ship a little new linuxconf module.

Don't worry, people can make good use of multiple options.
If you provide orthogonal tools they will provide orthogonal solutions.


elmer.


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



Re: ATA-4, ATA-5 TCQ status

2000-11-26 Thread Jens Axboe

On Mon, Nov 27 2000, Sasi Peter wrote:
> > implementation listed in the specs Linux might as well not support it :)
> > It's simply not worth it.
> 
> But seriously, how come?
> 
> I thought they just somewhat like copied the SCSI implementation...

I wish they would have, and based it on atapi. But they didn't...
Basically it requires you to poll for completion of tags with
a service command.

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



Re: Universal debug macros.

2000-11-26 Thread Rogier Wolff

Elmer Joandi wrote:
> 
> 
> On Sun, 26 Nov 2000, Rogier Wolff wrote:
> > Sure it will slow the driver down a bit, because of all those bit-test
> > instructions in the driver. If it bothers you, you get to turn it
> > off. If you are capable of that, you are also capable enough to turn
> > it back on when neccesary.
> 
> Now if there would be simple _unified_ system for switching debug code
> on/off, it would be a real win. That  recompilation-capable enduser would
> not need much knowledge to go "General Setup" or newly created
> "Optimization" section and switch debugging off/on for _all_ network
> drivers or ide drivers for example.

Now, how is say "Red Hat" (*) going to ship kernels? Of course they are
going to turn off debugging. Then I'll be stuck with a non-recompiling
user-in-trouble with a non-debugging-enabled kernel. 

Clients whom I have to tell "please read the kernel-howto" and
recompile your kernel. It's not that hard will not feel "good" about
this. It may seem easy to you, but from some people it is not.


Roger.

(*) Even if I manage to convince Red Hat not to do this, some
distribution is going to claim that they distribute the "performance"
kernel, and disable debugging in the field. 

-- 
** [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: ATA-4, ATA-5 TCQ status

2000-11-26 Thread Sasi Peter

On Mon, 27 Nov 2000, Jens Axboe wrote:

> > I would like to ask if the tagged command queueing capability in the
> > decent ATA standards is utilized in the linux IDE driver (2.2 2.2ide
>   ^^
> > patches, or 2.4 maybe...)?
> I hope that is supposed to be 'recent', because with the current TCQ

If you think I should have...

> implementation listed in the specs Linux might as well not support it :)
> It's simply not worth it.

But seriously, how come?

I thought they just somewhat like copied the SCSI implementation...

PS: Anybody knowing about a multi (>2) channel UATA host adapter?

-- 
SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.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/



"hda lost interrupt" in 2.4-test11, fat32 corruption

2000-11-26 Thread Toby Jaffey

Full description:
Using 2.4-test11 compiled with SMP support on my Abit BP6 (dual celeron
500s) I get consistent lost interrupt errors on hda (my only disk). My test
condition is untarring a 600mb archive of small files onto a FAT32
partition, which consistently fails. This usually results in processes
refusing to die, followed by the keyboard locking up. The machine is
still pingable, but remote logins fail. My test works fine in all 2.2
kernels I have tried and also in 2.4-test10.  My IDE chipset is the
PIIX4. At one point, I was forced to remove a FAT32 partition which
became severely corrupted, so I'm not willing to do any further testing,
sorry.

Keywords:
kernel, ide, smp, piix4

Environment:
Debian woody GNU/Linux, kernel 2.4-test11-smp, Abit BP6 (celeron 500s),
128mb, 1 0GB IDE disk.

-- 
(o_   | Toby Jaffey : www.nott.ac.uk/~psystrj/
//\   | "You're bound to be unhappy if you optimize everything." -- Donald E.
V_/_  | Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: ATA-4, ATA-5 TCQ status

2000-11-26 Thread Jens Axboe

On Mon, Nov 27 2000, Sasi Peter wrote:
> Hi!
> 
> I would like to ask if the tagged command queueing capability in the
> decent ATA standards is utilized in the linux IDE driver (2.2 2.2ide
  ^^
> patches, or 2.4 maybe...)?

I hope that is supposed to be 'recent', because with the current TCQ
implementation listed in the specs Linux might as well not support it :)
It's simply not worth it.

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



Re: problem with hp C1537A tape drives

2000-11-26 Thread Phil Randal


>   Hello Paul & Phil ,  Ouch !,  is this media that loose on the
>   substrate that it leaves that much behind ?  Or is it something
>   else ?  I'd really like to know what the problem is  ,  as I am
>   seriously looking at putting DDS-III & IV 's into my backup
>   schemes .  Tia ,  JimL

Apparently yes - the Compaq manual says that new tapes shed a 
lot, and that cleaning has to be more frequent with them.  They
recommend (this is from memory) cleaning the tape drive after
just 6 hours use of a new tape, then less frequently thereafter.

I figured after reading the manual that a weekly clean should
normally suffice.

Phil


Phil

Phil Randal   Home: [EMAIL PROTECTED]
Worcester, UK   http://www.rebee.clara.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: [PATCH] modutils 2.3.20 and beyond

2000-11-26 Thread David Ford

"Jeff V. Merkey" wrote:

> On Sun, Nov 26, 2000 at 06:02:35PM -0500, Mohammad A. Haque wrote:
> > I'd rather have Anaconda changed rather than special casing standard
> > utils to account for distro handling.
>
> Great.  Then tell RedHat to rewrite it without the need for these switches.
> They will say NO.  It's a trivial change, and would save me a lot of hours
> rewriting scripts.  I did it once, but if RedHat has standardized on this
> set of switches, why not add them as alias commands?  It's a trivial
> patch.

Then let RedHat maintain their version of modutils.  RedHat isn't the
standard, nor should RedHat dictate to authors, nor should other distributions
and persons be affected by RedHat's methods.

If you don't like it, replace your depmod with a script that strips that flag
before calling the original depmod.

-d



begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard



Re: [PATCH] modutils 2.3.20 and beyond

2000-11-26 Thread David Ford

"Jeff V. Merkey" wrote:

> On Sun, Nov 26, 2000 at 10:46:35PM +, Alan Cox wrote:
> > > +   {"ignore-versions", 0, 0, 'i'},
> >
> > I dont think we should encourage anyone to ignore symbol versions
>
> Anaconda will barf and require over 850+ changes to the scripts without
> it.  If you look at the patch, you will note that it's a silent switch
> that's only there to avoid a noisy error message from depmod.  It
> actually does nothing other than set a flag that also does nothing.
> -m simply maps to -F.

It's still a bad precedent.  Anaconda should have been written correctly in
the first place.

-d



begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard



ATA-4, ATA-5 TCQ status

2000-11-26 Thread Sasi Peter

Hi!

I would like to ask if the tagged command queueing capability in the
decent ATA standards is utilized in the linux IDE driver (2.2 2.2ide
patches, or 2.4 maybe...)?

Another question, a little bit offtopic is if anybody on this list is able
to point me to some pci UltraATA controller card, which has more than 2
channels (more than 4 drives w/o cascade magic) (preferrably 6 or 8
channels)? If the exists one, I do not need no HW RAID or anything like
that... I only need a lot of channels, in only one PCI slot.
There have been a lot of rant around here, and why I am addressing Andre
personally too is that in that debate his stated, that because such cards
exist, IDE can fall into line with SCSI in drives possible / PCI slot.

Your help is very much appreciated,

-- 
SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/


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



Re: initdata for modules?

2000-11-26 Thread Adam J. Richter

Keith Owens <[EMAIL PROTECTED]> wrote:
>"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
>>  In reading include/linux/init.h, I was surprised to discover
>>that __init{,data} expands to nothing when compiling a module.
>>I was wondering if anyone is contemplating adding support for
>>__init{,data} in module loading, to reduce the memory footprints
>>of modules after they have been loaded.

>It has been discussed a few times but nothing was ever done about it.
>AFAIK the savings were not seen to be that important because modules
>occupy complete pages.  __init would have to be stored in a separate
>page which was then discarded. [...]

No, you could just discard the part after the next page
boundary.  The expected savings would be about the same, since
the cases where the original code had just creeped over a page
boundary in many cases would result in dropping more memory savings
that the actual init size, from dropping those unused bytes
between the very end of the init section and the end of that page.
I say "about" the same becuase the distribution of text and data
sizes is not uniformly random within some fixed interval.

Since you would not have to bump the start address of a
section to the next page boundary, I wonder if it would still
complicate insmod et al.

In case there is any confusion, I am not suggesting that
this should go into the stock 2.4.0 releases.

However, I do find it helpful in allocating my time to
cosider that saving one page by something like this or by enhancing
gcc's variable placement saves as much space as 1024 eliminations
of "= 0" or "= NULL" static variable initializations.

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: initdata for modules?

2000-11-26 Thread Keith Owens

On Sun, 26 Nov 2000 17:01:35 -0700, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>insmod ppp_deflate (should trigger load of all these modules).  I 
>know it's works this way if there's a modules.dep file laying 
>around, but it would be nice for it to work this way without 
>needing the external text file.

There is a clean split between modprobe and insmod, modprobe is the
high level command that does all the fancy checking for inter module
dependencies, handling aliases and extracting options from
modules.conf.  insmod is the low level command that does exactly what
you tell it to do, no more, no less.  The only smarts that insmod has
is the ability to take a module name without '/' and find it using the
patchs in modules.conf.  That split between high and low level commands
is too useful to contaminate.

modules.conf already supports "above" and "below" commands for
non-standard dependencies.  The problem of not having a module.dep on
the first boot of a new kernel was addressed in kernel 2.4.0-test5 or
thereabouts, make modules_install runs depmod to build modules.dep
ready for the first boot.

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

2000-11-26 Thread Andrea Arcangeli

On Sun, Nov 26, 2000 at 11:29:32PM +0100, Pavel Machek wrote:
> Is this different on x86-64 in long mode?

Yes, in 64bit mode ss:rsp is restore unconditionally. In compatibility and
legacy modes it's restored only if the CPL changes.

kernel never runs in compatibility mode (and userspace never runs iret) so in
kernel_thread we know x86-64 always restores ss:rsp from the stack.

You should find this as a familiar behaviour as you just tried to pass a stack
via kernel_thread in your latest patch against cvs :).

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




Re: PROBLEM: cannot ls cdroms (_isofs_bmap block >= EOF)

2000-11-26 Thread Andries Brouwer

On Mon, Nov 27, 2000 at 12:16:41AM +0100, Stefan Frings wrote:
> [1.] One line summary of the problem:  
> 
> cannot ls cdroms (_isofs_bmap block >= EOF)

Yes, a well-known problem.
Delete two lines around line 118 of fs/isofs/dir.c:

-   if (filp->f_pos >= inode->i_size)
-   return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Universal debug macros.

2000-11-26 Thread Elmer Joandi



On Sun, 26 Nov 2000, Rogier Wolff wrote:
> Sure it will slow the driver down a bit, because of all those bit-test
> instructions in the driver. If it bothers you, you get to turn it
> off. If you are capable of that, you are also capable enough to turn
> it back on when neccesary.

Now if there would be simple _unified_ system for switching debug code
on/off, it would be a real win. That  recompilation-capable enduser would
not need much knowledge to go "General Setup" or newly created
"Optimization" section and switch debugging off/on for _all_ network
drivers or ide drivers for example.


> The debug asserts that trigger during normal operation are what make
> the Linux kernel stable. Problems get spotted at an early
> stage. Problems get fixed.

Yess


Lets say LDBG_* namespace, 
macros being in general form:
 LDBG_OPERATION(OPTIMIZATION_LEVEL,SUBSYSTEM,MODULE,ACTION, operation params..)

OPERATIONS would be first likely:
ASSERT_PRINT, PRINT, ASSERT_PANIC

OPTIMIZATION_LEVELs would be first:
DEVELOP, ALPHA, BETA, TEST, RELEASE, PRODUCTION, FINETUNED, EMBEDDED 

SUBSYSTEMS:
memory, fs, network, drivers(network, fs,...), 
divided to about 20 sections or so.
MODULE: would be current module

ACTION: division inside module :
DATA_UP, DATA_DOWN, INIT, CLEANUP, CONFIGURE, ToUserpace,FromUserSpace
... etc. about 15-25 divisions.

LDBG_DECLARE_DEBUG_VAR(OPTIMIZATION_LEVEL, SUBSYSTEM, MODULE)
woudl declare a global unsigned int subsystem_module_debug = 0 and
also sysctl interface to change it.
the var would have ACTION bitfields, so user can control debug output
runtime for the module.


elmer.


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

2000-11-26 Thread H. Peter Anvin

Followup to:  <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > +   {"ignore-versions", 0, 0, 'i'},
> 
> I dont think we should encourage anyone to ignore symbol versions
> 

No, but sometimes you really want to be able to.

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



Re: [PATCH] modutils 2.3.20 and beyond

2000-11-26 Thread Keith Owens

On Sun, 26 Nov 2000 16:36:55 -0700, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Keith,
>
>Please consider the attached patch for inclusion in all future versions
>of the modutils depmod program for compatiblity with RedHat and 
>RedHat derived Linux distributions.

I have a big problem with Redhat.  They make incompatible changes to
utilities, do not feed patches back to maintainers then expect the rest
of the world to follow their lead.  The -i and -m flags to modutils are
not the only example, I recently found IA64 and Sparc patches they had
added to modutils code and not bothered to tell me.  Other distributors
are much better about sending me patches, Debian and SuSe in particular
do the right thing.

Since "-F System.map" in modutils is equivalent to "-m System.map -i"
and works on all distributions, not just Redhat, the "-m -i" patch is
unnecessary.  Consider this my protest against bad habits by
distributors, they created the mess with their lack of communication
and they have to fix it.

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



Re: [PATCH] modutils 2.3.20 and beyond

2000-11-26 Thread Tom Rini

On Sun, Nov 26, 2000 at 05:03:34PM -0700, Jeff V. Merkey wrote:

> Great.  Then tell RedHat to rewrite it without the need for these switches.
> They will say NO.  It's a trivial change, and would save me a lot of hours
> rewriting scripts.  I did it once, but if RedHat has standardized on this
> set of switches, why not add them as alias commands?  It's a trivial 
> patch.

I hate to jump in here in the middle of a perfectly good argument but I'd like
to point out a few things:
a) If RedHat/RedHat-like distros needs these changes they can include this
patch.  The plus side is it won't piss off the people that seem to care and
don't use said distros the down side is that if/when another security update
comes out people will have to hope this patch applies easily still, if they
update themselves.
b) Are these switches which used to be valid in modutils 2.3.x?  If so, why?
It makes perfect sense to keep this patch around until modutils 2.4 (or 2.5
if modutils version is still supposed to match kernel version).  If these
are old modutils 2.2.x switches, see part a).
And c) Why does it matter if RedHat/etc would have to adapt their scripts.
There's always part a, or what debian does for stable sometimes, backporting
fixes.  Or even lots of sed & awk magic.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send 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: cannot ls cdroms (_isofs_bmap block >= EOF)

2000-11-26 Thread Stefan Frings

[1.] One line summary of the problem:  

cannot ls cdroms (_isofs_bmap block >= EOF)

[2.] Full description of the problem/report:

I cannot run ls on cdroms with kernel 2.4.0-test11. I get the 
message "_isofs_bmap block >= EOF". Kernel 2.0.4-test8 and test10 
work fine for me. I did not test other 2.4.0 versions. It makes no
difference if I compile isofs as "M" or "Y".

[3.] Keywords (i.e., modules, networking, kernel):

kernel, isofs, cdrom, bmap, mount, ls

[4.] Kernel version (from /proc/version):

2.4.0-test11

[6.] A small shell script or example program which triggers the
 problem (if possible)
 
mount /dev/hdc1 /mnt
dir /mnt
 
[7.1.] Software (add the output of the ver_linux script here)

Kernel modules  2.3.21
Gnu C   2.95.2
Gnu Make3.79.1
Binutils2.9.5.0.24
Dynamic Linker  ldd (GNU libc) 2.1.13
Procps  2.0.6
Mount   2.10q
Net-tools   1.56
Kbd 0.99
Sh-utils2.0
Modules loaded  no modules loaded

[7.2.] Processor information (from /proc/cpuinfo):

AMD K6-2 366

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)

Intel 82371AB PIIX 4 ACPI

[X.] Other notes, patches, fixes, workarounds:

I tried to use the isofs sources from version 2.4.0-test10 in 2.4.0-test11
they are not compatible. 
-
To unsubscribe from this list: send the 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 with hp C1537A tape drives

2000-11-26 Thread Mr. James W. Laferriere


Hello Paul & Phil ,  Ouch !,  is this media that loose on the
substrate that it leaves that much behind ?  Or is it something
else ?  I'd really like to know what the problem is  ,  as I am
seriously looking at putting DDS-III & IV 's into my backup
schemes .  Tia ,  JimL

On Sun, 26 Nov 2000, Paul Jakma wrote:
> On Sun, 26 Nov 2000, Phil Randal wrote:
> > Ah, have you tried cleaning the tape heads?
> the drive gets a run of a cleaning tape on a weekly basis.
> > far more frequently than you'd expect.  I've found it needs
> > two cleaning tape passes to clear this one.
> uhmmm ok. I've now done multiple cleanning runs with multiple
> cleaning tapes. let's see what happens when i try the amflush.
> > Cleaning solves a similar problem I get with these drives
> > and Backup Exec for Netware.
> and guess what... it's worked for me too. doh! guess once a week is
> not enough then.
> apologies to the list my tape cluelessness.
> > Phil
> thanks,
> --paulj
   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

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

2000-11-26 Thread Jeff V. Merkey

On Sun, Nov 26, 2000 at 06:02:35PM -0500, Mohammad A. Haque wrote:
> I'd rather have Anaconda changed rather than special casing standard
> utils to account for distro handling.

Great.  Then tell RedHat to rewrite it without the need for these switches.
They will say NO.  It's a trivial change, and would save me a lot of hours
rewriting scripts.  I did it once, but if RedHat has standardized on this
set of switches, why not add them as alias commands?  It's a trivial 
patch.

Jeff

> 
> "Jeff V. Merkey" wrote:
> > 
> > Anaconda will barf and require over 850+ changes to the scripts without
> > it.  If you look at the patch, you will note that it's a silent switch
> > that's only there to avoid a noisy error message from depmod.  It
> > actually does nothing other than set a flag that also does nothing.
> > -m simply maps to -F.
> > 
> 
> -- 
> 
> =
> 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: initdata for modules?

2000-11-26 Thread Jeff V. Merkey

On Mon, Nov 27, 2000 at 09:54:57AM +1100, Keith Owens wrote:
> On Sun, 26 Nov 2000 07:30:44 -0800, 
> "Adam J. Richter" <[EMAIL PROTECTED]> wrote:
> > In reading include/linux/init.h, I was surprised to discover
> >that __init{,data} expands to nothing when compiling a module.
> >I was wondering if anyone is contemplating adding support for
> >__init{,data} in module loading, to reduce the memory footprints
> >of modules after they have been loaded.
> 
> It has been discussed a few times but nothing was ever done about it.
> AFAIK the savings were not seen to be that important because modules
> occupy complete pages.  __init would have to be stored in a separate
> page which was then discarded.  It would complicate insmod, rmmod,
> ksymoops and gdb.  gdb against the kernel already gets confused by
> vmlinux data that is discarded and gdb has problems with modules at the
> best of times.  Definitely 2.5 material, if at all.


One really nice addition to the modutils would be to allow module 
dependencies to be stored in the headers of modules.  i.e. NetWare
NLMs have a "module depends" field where you can list modules you
have dependencies on, and so does NT with DLL's, and the loader auto
loads these modules when you load any module.  What's troublesome
about modutils in their current form is if you don't have a 
modules.dep file, insmod isn't smart enough to read the depenency
modules from a binary header, and load them without doing a lot 
of needless checking with modprobe.  Having to depend on an external
text file for this looks tacky to customers and is error prone.

I understand that it's nice to be able to change modules around 
and have the flexibilty to do this dynamically, but since modules
that use this are complied from the kernel, and the kernel 
build always knows "who owns the APIs" there's no reason it could
or should not be done this way.  i.e.

when loading ppp and it's modules:

slhc
ppp
ppp_deflate
bsd_comp

There's no reason that ppp could not have in it's binary header the 
name "slhc" and any other modules it is dependent on so insmod 
will load all of them if someone types

insmod ppp_deflate (should trigger load of all these modules).  I 
know it's works this way if there's a modules.dep file laying 
around, but it would be nice for it to work this way without 
needing the external text file.

Jeff



> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the 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] modutils 2.3.20 and beyond

2000-11-26 Thread Mohammad A. Haque

I'd rather have Anaconda changed rather than special casing standard
utils to account for distro handling.

"Jeff V. Merkey" wrote:
> 
> Anaconda will barf and require over 850+ changes to the scripts without
> it.  If you look at the patch, you will note that it's a silent switch
> that's only there to avoid a noisy error message from depmod.  It
> actually does nothing other than set a flag that also does nothing.
> -m simply maps to -F.
> 

-- 

=
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: initdata for modules?

2000-11-26 Thread Keith Owens

On Sun, 26 Nov 2000 07:30:44 -0800, 
"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
>   In reading include/linux/init.h, I was surprised to discover
>that __init{,data} expands to nothing when compiling a module.
>I was wondering if anyone is contemplating adding support for
>__init{,data} in module loading, to reduce the memory footprints
>of modules after they have been loaded.

It has been discussed a few times but nothing was ever done about it.
AFAIK the savings were not seen to be that important because modules
occupy complete pages.  __init would have to be stored in a separate
page which was then discarded.  It would complicate insmod, rmmod,
ksymoops and gdb.  gdb against the kernel already gets confused by
vmlinux data that is discarded and gdb has problems with modules at the
best of times.  Definitely 2.5 material, if at all.

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

2000-11-26 Thread Jeff V. Merkey

On Sun, Nov 26, 2000 at 10:46:35PM +, Alan Cox wrote:
> > +   {"ignore-versions", 0, 0, 'i'},
> 
> I dont think we should encourage anyone to ignore symbol versions

Anaconda will barf and require over 850+ changes to the scripts without
it.  If you look at the patch, you will note that it's a silent switch
that's only there to avoid a noisy error message from depmod.  It 
actually does nothing other than set a flag that also does nothing.  
-m simply maps to -F.

:-)

Jeff

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



Re: [PATCH] removal of "static foo = 0"

2000-11-26 Thread Rogier Wolff

Elmer Joandi wrote:
> 
> Nice to see again a two cutting-edge-killing opinions.
> 
> Every time I really wonder, how such brilliant hackers can be that stupid
> that they can not have cake and eat it the same time, and have to scratch
> each-others eyes every time.
> 
> Use macros.
> 
> Kernel has become so big that it really needs universal  debugging macros
> instead of comments. Comments are waste of brain&fingerpower, if the same
> can be explained by long variable names and debug macros.
> 
> static Subsystem_module_LocalVariableForThisPurpose;
> 
> int Subsytem_module_function_this_and_that(){
>   DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose  == 0 );
>   DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node != 
>NULL )
> }
> 
> 
> Those macros would be acceptable if they are unified and taken to
> kernel configuration level, so it would be easy to switch them in/out 
> not only as boolean option but systematically for different levels,
> subsystems and modules.

I leave "debugging" enabled in the drivers I submit. This allows me to
tell customers who are having "It won't detect my card" problems to
enable the debugging output. Most of the time this leads to a resolution
within minutes of me getting the debugging output log. 

Sure it will slow the driver down a bit, because of all those bit-test
instructions in the driver. If it bothers you, you get to turn it
off. If you are capable of that, you are also capable enough to turn
it back on when neccesary.

The debug asserts that trigger during normal operation are what make
the Linux kernel stable. Problems get spotted at an early
stage. Problems get fixed. Microsoft disables all debugging before
shipping stuff. That means they don't get useful bugreports from the
field ("When I do this, the system sometimes locks" compared to
"my system crashes with: 'panic: sk buff underrun at 0xc0123456'"). 

This was discussed and a decision was taken that we're on the good
track around 5 years ago. I guess that there is some new blood to be
convinced nowadays...

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: [PATCH] modutils 2.3.20 and beyond

2000-11-26 Thread Alan Cox

> + {"ignore-versions", 0, 0, 'i'},

I dont think we should encourage anyone to ignore symbol versions
-
To unsubscribe from this list: send the 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 [< >]

2000-11-26 Thread Pavel Machek

Hi!

You complain that most important information is on begging of OOps. So what
about moving most important info to the end? I.e. stack trace first, EIP next;
or even print EIP twice. Than s to [<, ksymoops will not break ;-)
Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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



Re: [PATCH] removal of "static foo = 0"

2000-11-26 Thread Pavel Machek

Hi!

> Sorry, John, I _have_ to [give good example to others]. The above says
> that _you_ my dear friend, do not know where the BSS clearing code is. It
> is not in setup.S. It is not even in the same directory, where setup.S is.
> It is in arch/i386/kernel/head.S, starting from line 120:
> 
> /*
>  * Clear BSS first so that there are no surprises...
>  */
> xorl %eax,%eax
> movl $ SYMBOL_NAME(__bss_start),%edi
> movl $ SYMBOL_NAME(_end),%ecx
> subl %edi,%ecx
> cld
> rep
> stosb
> 
> ... speaking of which (putting asbesto on and hiding from Andries ;) can't
> we optimize this code to move words at a time and not bytes ;)

There's better way: put bss clearing code at beggining of .C code and
do it with memset. [x86-64 does it this way.] It is both more obvious
[no assembly] and faster [memset is optimized].
Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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



[PATCH] modutils 2.3.20 and beyond

2000-11-26 Thread Jeff V. Merkey



Keith,

Please consider the attached patch for inclusion in all future versions
of the modutils depmod program for compatiblity with RedHat and 
RedHat derived Linux distributions.  This patch only requires 
4 very short changes to depmod.c as opposed to thousands of
changes necessary in anaconda and other RedHat compatible 
programs and scripts to work with your standard depmod
programs without these changes.  

Thanks

Jeff

 


--- modutils-2.3.20/depmod/depmod.c.chmou   Thu Nov 16 01:40:09 2000
+++ modutils-2.3.20/depmod/depmod.c Wed Nov 22 05:18:09 2000
@@ -188,6 +188,7 @@
 static SYMBOL *symavail;
 static SYMBOL *maxsyms;
 static LIST_SYMBOL *chunk;
+static int ignore_symbol_versions;

 static int quiet;  /* Don't print errors */
 static int showerror;  /* Shows undefined symbols */
@@ -1098,7 +1099,9 @@
{"errsyms", 0, 0, 'e'},
{"filesyms", 1, 0, 'F'},
{"help", 0, 0, 'h'},
+   {"ignore-versions", 0, 0, 'i'},
{"show", 0, 0, 'n'},
+   {"system-map", 1, 0, 'm'}, /* backward compatibility, same as 'F' */
{"quiet", 0, 0, 'q'},
{"syslog", 0, 0, 's'},
{"verbose", 0, 0, 'v'},
@@ -1109,7 +1112,7 @@
 
error_file = "depmod";
 
-   while ((o = getopt_long(argc, argv, "aAb:C:eF:hnqsvVr",
+   while ((o = getopt_long(argc, argv, "aAb:C:eF:him:nqsvVr",
&long_opts[0], NULL)) != EOF) {
switch (o) {
case 'A':
@@ -1132,11 +1135,16 @@
return 0;
break;
 
+   case 'i':
+   ignore_symbol_versions = 1;
+   break;
+
case 'C':
conf_file = optarg;
break;
 
case 'F':
+   case 'm':
file_syms = optarg;
break;



Re: kernel_thread bogosity

2000-11-26 Thread Pavel Machek

Hi!

> > How can that work? restore_args ends with iret, anyway, and iret does
> > reload esp afaics...
> 
> ... only if there's an IPL change during the iret. Page 3-321 of 24319102.pdf
> from Intel:
> 
>   [..] If the return is to another privilege level, the IRET instruction
>   also pops the stack pointer and SS from the stack, before resuming
>   program execution. [..]

Is this different on x86-64 in long mode?
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



[patch] patch-2.4.0-test11-irda1

2000-11-26 Thread Dag Brattli

Linus,

Please apply this patch to your latest 2.4 code. The patch have been 
tested by users at the Linux-IrDA mailing-list which confirms that
it fixes the specific problems listed below.

Changes:

o Devfs support with IrCOMM (pmhahn?)

o IrLAN connection failures with DHCP (me)

o NSC FIR dongle fixes (Pontus Fuchs)

o Fixes IrLAP discovery problems with some devices (me)

o Updates to some doc files (me)

-- Dag

diff -urpN linux-2.4.0-test11-pre6/Documentation/networking/irda.txt 
linux/Documentation/networking/irda.txt
--- linux-2.4.0-test11-pre6/Documentation/networking/irda.txt   Tue Sep  7 19:14:36 
1999
+++ linux/Documentation/networking/irda.txt Fri Nov 17 23:23:39 2000
@@ -1,10 +1,10 @@
 To use the IrDA protocols within Linux you will need to get a suitable copy
 of the IrDA Utilities. More detailed information about these and associated
-programs can be found on http://www.cs.uit.no/linux-irda/
+programs can be found on http://irda.sourceforge.net/
 
 For more information about how to use the IrDA protocol stack, see the
-IR-HOWTO (http://www.snafu.de/~wehe/IR-HOWTO.html) written by Werner Heuser
-<[EMAIL PROTECTED]>
+IR-HOWTO (http://www.mobilix.org/Infrared-HOWTO/Infrared-HOWTO.html) written by 
+Werner Heuser
+<[EMAIL PROTECTED]>
 
 There is an active mailing list for discussing Linux-IrDA matters called
 linux-irda. To subscribe to it, visit:
diff -urpN linux-2.4.0-test11-pre6/MAINTAINERS linux/MAINTAINERS
--- linux-2.4.0-test11-pre6/MAINTAINERS Thu Nov 23 13:17:15 2000
+++ linux/MAINTAINERS   Fri Nov 17 23:25:14 2000
@@ -645,9 +645,9 @@ S:  Maintained
 
 IRDA SUBSYSTEM
 P:  Dag Brattli
-M:  Dag Brattli <[EMAIL PROTECTED]>
+M:  Dag Brattli <[EMAIL PROTECTED]>
 L:  [EMAIL PROTECTED]
-W:  http://www.cs.uit.no/linux-irda/
+W:  http://irda.sourceforge.net/
 S:  Maintained
 
 ISAPNP
diff -urpN linux-2.4.0-test11-pre6/drivers/net/irda/irtty.c 
linux/drivers/net/irda/irtty.c
--- linux-2.4.0-test11-pre6/drivers/net/irda/irtty.cThu Nov 23 13:17:18 2000
+++ linux/drivers/net/irda/irtty.c  Sun Nov 19 20:41:00 2000
@@ -960,7 +960,7 @@ static int irtty_net_ioctl(struct net_de
ASSERT(self != NULL, return -1;);
ASSERT(self->magic == IRTTY_MAGIC, return -1;);
 
-   IRDA_DEBUG(2, __FUNCTION__ "(), %s, (cmd=0x%X)\n", dev->name, cmd);
+   IRDA_DEBUG(3, __FUNCTION__ "(), %s, (cmd=0x%X)\n", dev->name, cmd);

/* Disable interrupts & save flags */
save_flags(flags);
diff -urpN linux-2.4.0-test11-pre6/drivers/net/irda/nsc-ircc.c 
linux/drivers/net/irda/nsc-ircc.c
--- linux-2.4.0-test11-pre6/drivers/net/irda/nsc-ircc.c Thu Nov 23 13:17:18 2000
+++ linux/drivers/net/irda/nsc-ircc.c   Wed Nov 22 23:01:34 2000
@@ -708,9 +708,12 @@ static int nsc_ircc_setup(chipio_t *info
switch_bank(iobase, BANK0);

/* Set FIFO threshold to TX17, RX16, reset and enable FIFO's */
-   switch_bank(iobase, BANK0); 
+   switch_bank(iobase, BANK0);
outb(FCR_RXTH|FCR_TXTH|FCR_TXSR|FCR_RXSR|FCR_FIFO_EN, iobase+FCR);
-   
+
+   outb(0x03, iobase+LCR); /* 8 bit word length */
+   outb(MCR_SIR, iobase+MCR);  /* Start at SIR-mode, also clears LSR*/
+
/* Set FIFO size to 32 */
switch_bank(iobase, BANK2);
outb(EXCR2_RFSIZ|EXCR2_TFSIZ, iobase+EXCR2);
@@ -723,7 +726,7 @@ static int nsc_ircc_setup(chipio_t *info
switch_bank(iobase, BANK6);
outb(0x20, iobase+0); /* Set 32 bits FIR CRC */
outb(0x0a, iobase+1); /* Set MIR pulse width */
-   outb(0x0d, iobase+2); /* Set SIR pulse width */
+   outb(0x0d, iobase+2); /* Set SIR pulse width to 1.6us */
outb(0x2a, iobase+4); /* Set beginning frag, and preamble length */
 
MESSAGE("%s, driver loaded (Dag Brattli)\n", driver_name);
@@ -804,8 +807,6 @@ static void nsc_ircc_init_dongle_interfa
   dongle_types[dongle_id]); 
break;
case 0x04: /* Sharp RY5HD01 */
-   IRDA_DEBUG(0, __FUNCTION__ "(), %s not supported yet\n",
-  dongle_types[dongle_id]); 
break;
case 0x05: /* Reserved, but this is what the Thinkpad reports */
IRDA_DEBUG(0, __FUNCTION__ "(), %s not defined by irda yet\n",
@@ -892,8 +893,7 @@ static void nsc_ircc_change_dongle_speed
   dongle_types[dongle_id]); 
break;
case 0x04: /* Sharp RY5HD01 */
-   IRDA_DEBUG(0, __FUNCTION__ "(), %s not supported yet\n",
-  dongle_types[dongle_id]); 
+   break;
case 0x05: /* Reserved */
IRDA_DEBUG(0, __FUNCTION__ "(), %s not defined by irda yet\n",
   dongle_types[dongle_id]); 
diff -urpN linux-2.4.0-test11-pre6/net/irda/ircomm/ircomm_core.c 
linux/net/irda/ircomm/ircomm_core.c
--- linux-2.4.0-test11-pre6/net/irda/ircomm/ircomm_core.c   Thu Nov 23 13:17:28 
2000
+++ linux/n

PCMCIA 3.1.22 needs patch for kernels > 2.2.18-23

2000-11-26 Thread Jeff V. Merkey



David Hinds/Linux,

PCMCIA 3.1.22 requires that the defines in /include/pcmcia/k_compat.h
for init_waitqueue_head(n) and set_current_state(n) be removed in order
to build correctly against 2.2.18-23.  

Offending code attached.  This probably needs somethig better than the 
LINUX_KERNEL_VERSION macro to avoid this problem in the future.

:-)

Jeff

in /include/pcmcia/k_compat.h

/*
#if (LINUX_VERSION_CODE < VERSION(2,2,18))
#if (LINUX_VERSION_CODE < VERSION(2,0,16))
#define init_waitqueue_head(p)  (*(p) = NULL)
#else
#define init_waitqueue_head(p)  init_waitqueue(p)
#endif
typedef struct wait_queue *wait_queue_head_t;
#endif
***/

and


#if (LINUX_VERSION_CODE < VERSION(2,1,0))
#define __set_current_state(n) \
do { current->state = TASK_INTERRUPTIBLE; } while (0)
#elif (LINUX_VERSION_CODE < VERSION(2,2,18))
//#define __set_current_state(n)  do { current->state = (n); } while (0)
#endif
 

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



netfilter, nat & packet floods?

2000-11-26 Thread Tuomas Heino

Anyone know how to properly filter packet floods using iptables w/ nat?

>From my point of view 2.4.x:ish connection tracking seems to be quite
a bit more vulnerable to packet flooding than the 2.2.x:ish
IP Masquerading used to be (when using default configuration that is).

First we try to make both input & output flood-filtered:
iptables -t nat -I PREROUTING -j floodprot
iptables -t nat -I OUTPUT -j floodprot

For example the following rule seems to match no packets:
iptables -t nat -A floodprot -p tcp --tcp-flags ALL NONE -j DROP

(According to the documentation --tcp-flags ALL NONE should match the
so-called "Null scan", aka nmap -sN)

The following rules seem to rate-limit ping & traceroute properly:

iptables -t nat -A floodprot -p icmp --icmp-type echo-request -m limit \
 --limit 4/s ! -f -j RETURN
iptables -t nat -A floodprot -p icmp --icmp-type echo-request -j DROP
iptables -t nat -A floodprot -p udp --dport 33400:33499 --sport \
 5:65535 -m limit --limit 4/s ! -f -j RETURN
iptables -t nat -A floodprot -p udp --dport 33400:33499 --sport \
 5:65535 -j DROP

But is there a better (=simpler) way to do that?

Also if I happen to have a bunch of interfaces that are not supposed to
get any routing and/or nat from this box, tracking connections on them
seems to be waste of resources to me - there probably is no way to turn
connection tracking off for some interface pairs?

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



Re: OOPS on bringing down ppp

2000-11-26 Thread Mark Ellis


Nope that didn't help. I'm using gcc 2.95.2, didn't think of it before
since it has never caused me any problems. I'll get around to trying
2.91.66 at some point.

A quick aside, anyone know of a problem with the list, I seem to be being
cut off at random intervals :)

Mark

On Fri, 24 Nov 2000 12:28:44 Andrew Morton wrote:
> Mark Ellis wrote:
> > 
> > Hi all, consistently getting the following when pppd is terminated.
> 
> When pppd downs the ppp0 device, unregister_netdevice() is
> trying to run /sbin/hotplug in a new kernel thread.  That
> thread's `files' structure is copied from pppd, but it is
> NULL.  Presumably pppd's files pointer was also NULL.
> 
> Try this:
> 
> --- linux-2.4.0-test11-ac2/kernel/kmod.c  Tue Nov 21 20:11:21 2000
> +++ linux-akpm/kernel/kmod.c  Fri Nov 24 23:03:34 2000
> @@ -99,8 +99,10 @@
>   flush_signal_handlers(current);
>   spin_unlock_irq(¤t->sigmask_lock);
>  
> - for (i = 0; i < current->files->max_fds; i++ ) {
> - if (current->files->fd[i]) close(i);
> + if (current->files) {
> + for (i = 0; i < current->files->max_fds; i++ ) {
> + if (current->files->fd[i]) close(i);
> + }
>   }
>  
>   /* Drop the "current user" thing */
> 
> 
> Not my area, but I don't think exec_usermodehelper() should assume
> that current->files is always valid.
> 
> Al, is this correct?  If so, does daemonize() also need this test?
> If not, then how did this thread get (current->files == NULL)?
> 

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



Oops on 2.2.18-21(23) with pppd dial-in

2000-11-26 Thread root



I had backreved this system to 2.2.18-21 but I can reproduce this Oops on
both 2.2.18-21 and 2.2.18-23.  I am providing the Oops information from 
kernel 2.2.18-21 since this is what was running on the system at the time
the pppd dial in server crashed.  

The server crashes after several dial clients who are routing both
IPX and IP attach and disconnect several times, then you attempt 
to telnet or ssh into the box over the ethernet link.  The oops 
is actually occurring when a telnet session is attempted after 
someone disconnects from a pppd session.  

This Oops was created against the System.map file for a 2.2.18-21 
build.  This bug takes about two days to reproduce, and also 
requires that the local gateway system be misconfigured to point
a non-existent network route to the target machine.  It's very 
difficult to reproduce, but is very annoying.

Jeff
  



ksymoops 0.7c on i686 2.2.18pre21.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.2.18pre21/ (default)
 -m /usr/src/linux/System.map (default)

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

No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
unable to handle kernel paing request virtual address 90c16C24
Oops: 0002
CPU:  0
EIP:  0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax:  90c16c20  ebx:  c16c6145  ecx:  edx: c0226e2c 
esi:  c0259200  edi:  c16c614d  ebp: c0259200 esp: c17f9ee8
ds: 18  es: 18  ss: 18
Call Trace: [] [] [] [] [] 
[] [] []
Warning (Oops_read): Code line not seen, dumping what data is available

>>EIP; c0137596<=
Trace; c01377fe 
Trace; c0137816 
Trace; c0144bbc 
Trace; c0131238 
Trace; c0131434 
Trace; c013151c 
Trace; c012f532 
Trace; c010a2fc 


3 warnings issued.  Results may not be reliable.



Oops with ACPI on test11-ac4

2000-11-26 Thread Adam Huffman

The Oops happens during startup immediately after:

ACPI: System description tables loaded

It's definitely using the correct System.map.

This is on RedHat 7.0, Athlon 800, Abit KA7-100 m/b

ksymoops 2.3.4 on i686 2.4.0-test11-ac4.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test11-ac4/ (default)
 -m /boot/System.map (specified)

Warning (compare_maps): ksyms_base symbol acpi_clear_event_R__ver_acpi_clear_event not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_cm_memcpy_R__ver_acpi_cm_memcpy not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_cm_memset_R__ver_acpi_cm_memset not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_cm_strncmp_R__ver_acpi_cm_strncmp not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_dbg_layer_R__ver_acpi_dbg_layer not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_dbg_level_R__ver_acpi_dbg_level not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_disable_event_R__ver_acpi_disable_event 
not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_enable_event_R__ver_acpi_enable_event 
not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_evaluate_object_R__ver_acpi_evaluate_object not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_current_resources_R__ver_acpi_get_current_resources not found in System.map.  
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_get_handle_R__ver_acpi_get_handle not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_get_name_R__ver_acpi_get_name not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_next_object_R__ver_acpi_get_next_object not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_object_info_R__ver_acpi_get_object_info not found in System.map.  Ignoring 
ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_get_parent_R__ver_acpi_get_parent not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_possible_resources_R__ver_acpi_get_possible_resources not found in 
System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_processor_cx_info_R__ver_acpi_get_processor_cx_info not found in System.map.  
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_processor_throttling_info_R__ver_acpi_get_processor_throttling_info not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_get_processor_throttling_state_R__ver_acpi_get_processor_throttling_state not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_get_type_R__ver_acpi_get_type not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_install_address_space_handler_R__ver_acpi_install_address_space_handler not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_install_gpe_handler_R__ver_acpi_install_gpe_handler not found in System.map.  
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_install_notify_handler_R__ver_acpi_install_notify_handler not found in 
System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_os_breakpoint_R__ver_acpi_os_breakpoint 
not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_os_callocate_R__ver_acpi_os_callocate 
not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_os_free_R__ver_acpi_os_free not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_os_in8_R__ver_acpi_os_in8 not found in 
System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_os_out8_R__ver_acpi_os_out8 not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_os_printf_R__ver_acpi_os_printf not 
found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol 
acpi_os_queue_for_execution_R__ver_acpi_os_queue_for_execution not found in 
System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_os_sleep_R__ver_acpi_os_sleep not found 
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol acpi_os_sleep_usec_R__ver_acpi_os_sleep_usec 
not found in System.map.  Ignoring ksyms_base entry
Warning (compare_m

KERNEL BUG: console not working in linux

2000-11-26 Thread Gianluca Anzolin

Hello
sorry if I'm mailing this twice, but there is a kernel bug in
linux 2.2 and linux 2.4. Linux 2.0 is not affected. I tested also
FreeBSD, OpenBSD, Windows 95 and DOS and they all work.

The problem is that linux doesn't find the video card: after
lilo has loaded the kernel the screen becomes black. The system boots
regularily but the screen stays black forever.

In this PC I haven't configured any framebuffer and there isn't
X Window. The video card is a TRIDENT 9660 and it is integrated on the
mainboard.

I tried to access the system via ssh and I tried to issue the
lspci -xvv command. You can find the output (along with the output of
pciconf -l from FreeBSD) on http://www.gest.unipd.it/~iig0573/lspci.txt
lspci can't find the video card; FreeBSD finds it on 0:9.0

I tried then to boot with pci=direct, bios & conf1 (as somebody
told me) but anything changed. I tried also vga framebuffer and to pass
the vga=ask argument to the kernel. Nothing changed. 

With vga=ask the system asks to choose a video mode. The system
can also scan all the video modes of the card. But if I choose any of
them the screen becomes black. After some investigation I think the
problem is in arch/i386/boot/video.S but I haven't the skills to debug &
solve.

Please, help me, I really hope to use linux on this PC...
otherwise I must use something else.

Thank you,

Gianluca
-
To unsubscribe from this list: send the 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] removal of "static foo = 0"

2000-11-26 Thread H. Peter Anvin

Followup to:  <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> That isnt what Andries is arguing about. Read harder. Its semantic differences
> rather than code differences.
> 
>   static int a=0;
> 
> says 'I thought about this. I want it to start at zero. I've written it this
> way to remind of the fact'
> 
> Sure it generates the same code
> 

The problem is that it doesn't.  One could argue this is a gcc bug or
rather missed optimization.

One can, of course, also write:

static int a /* = 0 */;

... to make it clear to human programmers without making gcc make bad
code.

-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: 2.4.0-test5 bug: invalid "shmid_kernel" passed to "shm_nopage_core"

2000-11-26 Thread Kevin Buhr

Christoph Rohland <[EMAIL PROTECTED]> writes:
> 
> > I use a SysReq patch to do an oops-style dump instead of the usual
> > "showPc" function, so I was able to copy a stack dump down.
> 
> Could you send me the patch? Does it do the dump on all cpus?

You can grab it at:

ftp://mozart.stat.wisc.edu/pub/misc/patch-2.4.0-test5-sysreq

It doesn't dump all CPUs; it just dumps whichever one handles the
SysReq request, so I just keep doing it until I get them both.

> I would be happy to help debug the shm code if you find a way to
> reproduce it. 

Okay.  I've actually determined that my window manager (Enlightenment)
creates a shared memory segment for the X server to map and unmap
anywhere from 25 to 100 times a second; the segment appears in the X
server's memory map at the address 0x40014000 that "shm_nopage" was
trying to fault in when my lockup occurred.

I didn't notice it before because the time the page is mapped is
small.  To catch it, I had to do

while true; do egrep 40014000 /proc/xxx/maps; done

and wait a bit.  A "printk" for shm_mmapping at address 0x40014004
gave me the 25-100 times per second figure.

The fact that this has crashed once in all the time I've been using
this setup would seem to imply a very subtle race condition.  Ugh.

Can you offer me a tutorial on the SHM locking?  What's supposed to
protect against what?

In the meantime, I'll keep plugging away at it.

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



ISSUE: usb-storage causes system freeze on large transfers

2000-11-26 Thread John Margaglione

1.  usb-storage causes system freeze on large transfers.

2.  When transferring data from a SanDisk ImageMate SDDR-31 loaded with
an IBM Microdrive, I get random system freezes.  

In the first case, using 2.4.0-test10 with a 50MB transfer, the system
dropped out of X with a console freeze and a message about the watchdog
timer.  Sorry, but I didn't have paper around to write out the whole
message.

In the second and third cases, using 2.4.0-test11 with 10-20MB
transfers, the system became non-responsive and required a hard reboot. 
No messages were given in the log files.

All of the cases were within a three hour period on the same machine
(see description below).  In each case, the command "cp /mnt/camera/* ."
was issued.

Note that I have had a half-dozen successfully completed transfers of
10-40MB in between these errors.  The words "race condition" come to
mind.

3. Keywords: usb usb-storage

4. Kernel version: 2.4.0-test10/2.4.0-test11

5. No OOPS available.

6. "cp /mnt/camera/* ." will cause the error.  In this case, I mounted
/mnt/camera on /dev/sdd1, where the usb-storage driver had provided
/dev/sdd1 for the SanDisk device.

7. Environment
7.1  Software
  Linux wopr 2.4.0-test11 #9 SMP Sat Nov 25 18:52:11 CST 2000 i686
unknown
  Kernel modules 2.3.14
  Gnu C  2.96
  Binutils   2.10.0.18
  Linux C Library1.94.so
  ldd: missing file arguments
  Try `ldd --help' for more information.
  ls: /usr/lib/libg++.so: No such file or directory
  Procps 2.0.7
  Mount  2.10m
  Net-tools  (2000-05-21)
  Kbd[option...]
  Sh-utils   2.0
  Sh-utils   Parker.
  Sh-utils   
  Sh-utils   Inc.
  Sh-utils   NO
  Sh-utils   PURPOSE.

  Running under latest HelixGnome with Enlightenment window manager. 
Open applications included Netscape, GMC and a half-dozen xterms. 

7.2 Processor Information
  processor   : 0
  vendor_id   : GenuineIntel
  cpu family  : 6
  model   : 6
  model name  : Celeron (Mendocino)
  stepping: 5
  cpu MHz : 451.28
  cache size  : 128 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 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr  
  bogomips: 897.84

  processor   : 1
  vendor_id   : GenuineIntel
  cpu family  : 6
  model   : 6
  model name  : Celeron (Mendocino)
  stepping: 5
  cpu MHz : 451.28
  cache size  : 128 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 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr
  bogomips: 901.12

7.3 Module info
nls_cp437   4384   1 (autoclean)
vfat   11500   1 (autoclean)
fat32504   0 (autoclean) [vfat]
usb-storage43428   1
agpgart15172   0 (unused)

7.4 SCSI info
  Attached devices: 
  Host: scsi1 Channel: 00 Id: 02 Lun: 00
Vendor: SEAGATE  Model: ST39173WCRev: 6244
Type:   Direct-AccessANSI SCSI revision: 02
  Host: scsi1 Channel: 00 Id: 04 Lun: 00
Vendor: SEAGATE  Model: ST39173WCRev: 6244
Type:   Direct-AccessANSI SCSI revision: 02
  Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: IOMEGA   Model: ZIP 100  Rev: 23.D
Type:   Direct-AccessANSI SCSI revision:

  Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: SanDisk  Model: ImageMate II Rev: 1.30
Type:   Direct-AccessANSI SCSI revision: 02

7.5 Other info
  Please CC me in reference to this issue, as I do not subscribe to the
list.

John Margaglione
[EMAIL PROTECTED]

_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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



Re: gcc-2.95.2-51 is buggy

2000-11-26 Thread J . A . Magallon


On Sun, 26 Nov 2000 16:33:25 Olaf Dietsche wrote:
> 
> A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as
> well. So, if you configure your kernel with `CONFIG_M686=y' the problem
> should be gone.
> 

That does not work for 2.2 kernels. Always compile for -m486. To use
the -march flag you need to modify arch/i386/kernel/Makefile. Patch
follows:

= PATCH patch-gcc-arch:
--- linux-2.2.17/arch/i386/Makefile.origWed Nov 22 20:42:49 2000
+++ linux-2.2.17/arch/i386/Makefile Wed Nov 22 20:44:40 2000
@@ -24,23 +24,23 @@
 CFLAGS := $(CFLAGS) $(CFLAGS_PIPE) $(CFLAGS_NSR)
 
 ifdef CONFIG_M386
-CFLAGS := $(CFLAGS) -m386 -DCPU=386
+CFLAGS := $(CFLAGS) -march=i386 -DCPU=386
 endif
 
 ifdef CONFIG_M486
-CFLAGS := $(CFLAGS) -m486 -DCPU=486
+CFLAGS := $(CFLAGS) -march=i486 -DCPU=486
 endif
 
 ifdef CONFIG_M586
-CFLAGS := $(CFLAGS) -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
-DCPU=586
+CFLAGS := $(CFLAGS) -march=i586 -malign-loops=2 -malign-jumps=2
-malign-functions=2 -DCPU=586
 endif
 
 ifdef CONFIG_M586TSC
-CFLAGS := $(CFLAGS) -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
-DCPU=586
+CFLAGS := $(CFLAGS) -march=i586 -malign-loops=2 -malign-jumps=2
-malign-functions=2 -DCPU=586
 endif
 
 ifdef CONFIG_M686
-CFLAGS := $(CFLAGS) -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
-DCPU=686
+CFLAGS := $(CFLAGS) -march=i686 -malign-loops=2 -malign-jumps=2
-malign-functions=2 -DCPU=686
 endif
 
 HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o


-- 
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: problem with hp C1537A tape drives

2000-11-26 Thread Phil Randal

> uhmmm ok. I've now done multiple cleanning runs with multiple
> cleaning tapes. let's see what happens when i try the amflush.
> 
> and guess what... it's worked for me too. doh! guess once a week is
> not enough then.
> 
> apologies to the list my tape cluelessness.

No problem - it's a relief to confirm that it's not Backup Exec's fault
on Netware.

Phil


Phil Randal   Home: [EMAIL PROTECTED]
Worcester, UK   http://www.rebee.clara.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: gcc-2.95.2-51 is buggy

2000-11-26 Thread Russell King

Mike Castle writes:
> Btw, was this ever tested on other arch's?  I don't remember seeing
> anything come across this list.

Well, I've tested it on egcs-1.1.2 and RH's gcc 2.96 on ARM, both of
which appear ok.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: 2.4.0-test11(-ac4)/i386 configure bug

2000-11-26 Thread David Woodhouse

On Sun, 26 Nov 2000, Jeff Epler wrote:

> How can you have the console on a modularized device?

You can have more than one console device. Only the primary device needs
to be present at boot time. Actually, I'm not sure even that has to be
present.

Since I added unregister_console() a long time ago, you can dynamically
add and remove console devices.

> Above, this is correctly forbidden for serial console.
>
> Or can I dynamically change the console device after bootup?

Not change. Add a new one. console != preferred_console.

And in this case, it's exactly what you want.  You don't want all the
normal bootup cruft, you want to load the driver after the boot is
finished, and only catch oopsen.


--
dwmw2


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



Re: gcc-2.95.2-51 is buggy

2000-11-26 Thread Mike Castle

On Sun, Nov 26, 2000 at 04:33:25PM +0100, Olaf Dietsche wrote:
> A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as
> well. So, if you configure your kernel with `CONFIG_M686=y' the problem
> should be gone.

Btw, was this ever tested on other arch's?  I don't remember seeing
anything come across this list.

mrc
-- 
   Mike Castle   Life is like a clock:  You can work constantly
  [EMAIL PROTECTED]  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
We are all of us living in the shadow of Manhattan.  -- Watchmen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: setrlimit() and 2.4.0-test11

2000-11-26 Thread Jan Rekorajski

On Wed, 22 Nov 2000, Arkadiusz Miskiewicz wrote:

> 
> Is probably broken (I didnt't saw any disscusion about this here,
> I missed it?).
> 
> when I try to start first user process I get:
> 4366  fork()= -1 EAGAIN (Resource temporarily 
>unavailable)
> but strace show proper value passed to setrlimit() -- 40 max number of processes:
> 4366  setrlimit(0x6 /* RLIMIT_??? */, {rlim_cur=40, rlim_max=40}) = 0
> 
> On test10 everything is ok.

No, you are just lucky.
The problem is that root (uid=0) is not a special case anymore, and you can't
do something like this:

setrlimit(NPROC)
fork()
setuid(user)

setrlimit() and fork() are executed in root context, so sterlimit
apllies to root, not the user you're setuid to :(

Why is this so? root should be able to do fork() regardless of any limits,
and IMHO the following patch is the right thing.

--- linux/kernel/fork.c~Tue Sep  5 23:48:59 2000
+++ linux/kernel/fork.c Sun Nov 26 20:22:20 2000
@@ -560,7 +560,8 @@
*p = *current;
 
retval = -EAGAIN;
-   if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
+   if (p->user->uid &&
+  (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur))
goto bad_fork_free;
atomic_inc(&p->user->__count);
atomic_inc(&p->user->processes);

Jan
-- 
Jan Rękorajski|  ALL SUSPECTS ARE GUILTY. PERIOD!
bagginsmimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, type MANIAC |   -- TROOPS by Kevin Rubio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



number of open fds?

2000-11-26 Thread Tigran Aivazian

Hi,

The kernel/exit.c:put_files_struct() and close_files() are very nice as
they show how to walk open fds (and close them) and how to free the fd
array/sets in one go. But is there a _very fast_ way of getting the number
of fds currently open (without having to walk the sets and test the bits)?

Regards,
Tigran

-
To unsubscribe from this list: send the 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 with hp C1537A tape drives

2000-11-26 Thread Paul Jakma

On Sun, 26 Nov 2000, Phil Randal wrote:

> Ah, have you tried cleaning the tape heads?
>

the drive gets a run of a cleaning tape on a weekly basis.

> far more frequently than you'd expect.  I've found it needs
> two cleaning tape passes to clear this one.
>

uhmmm ok. I've now done multiple cleanning runs with multiple
cleaning tapes. let's see what happens when i try the amflush.

> Cleaning solves a similar problem I get with these drives
> and Backup Exec for Netware.
>

and guess what... it's worked for me too. doh! guess once a week is
not enough then.

apologies to the list my tape cluelessness.

> Phil

thanks,

--paulj

-
To unsubscribe from this list: send 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, dma_intr status=0x51, error=0x84

2000-11-26 Thread Christian Roessner

Hello,

I recently sent an eMail to you, reporting a bug. I got two
answers. One talking about a wrong used cable. Another
talking about problems with ATI graphic cards and (U)DMA. My
ATI is an AGP-card so the answer couldn´t help me.

I changed the cable, although I used the correct cable before
and nothing has changed. I still have problems using DMA
Mode (33 and 66 MB/sec). So I think there must be an other
reason for the DMA problem. The anser-eMails are at the end
of this mail.

I compiled the kernel with CONFIG_BLK_DEV_VIA82CXXX=yes, but
this does not help anything.

Do you think it is the hardware or the kernel? Can I damage
my system using (U)DMA mode although I get errors?

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 : 

Re: [PATCH] removal of "static foo = 0"

2000-11-26 Thread Elmer Joandi



On Sun, 26 Nov 2000, Alexander Viro wrote:

> I would suggest you to read through the following book and files:
>   * Kernighan & Pike, "The Practice of Programming"
>   * Documentation/CodingStyle
>   * drivers/net/aironet4500_proc.c
> and consider, erm, discrepancies. On the second thought, reading K&R
> might also be useful. IOW, no offense, but your C is bad beyond belief.

Yep, very true.
aironet4500_proc.c is ugly. And is because there is quickly handwirtten
something that should have been generic for kernel for some long time, not
for every driver-writer to reinvent a wheel.
Note that there is something that virtually elliminates need for
exact user<->kernel level interfaces and userlevel kerneldata manipulation 
programs and lots of other maintenance pains.
And it does it in quite short sentences. Plus, half of that file is direct
repeating of some non-exported kernel functions. But, if you think you can
do better, then look into aironet4500_rid.c and handcode it (like real K&R
people do), instead of using aironet4500_proc.c to operate on it.
Also, pcmcia/aironet4500_cs.c has lots of ugly parts. Those which are
related to stupid masohistic code repetitions due to pcmcia package
interface being "cutting edge optimal stupid"

The same true is that 2.4 kernel is, in commercial production sense, late
for 6 months. And reason being that the codebase and testing becomes
unmanageable. And it becomes unmanageable, because some people only read
K&R and try to optimize last bit out of it with using and old book.

I'd really propose again:
1. universal debug macros
2. universalt user-kernelspace configuration interface via proc/sys

I'd really like C++, but it can be done with C and macros.
Some years ago I even managed to write something like stl container 
withing C and with macros. That was really screwy thing.

elmer.


-
To unsubscribe from this list: send the 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: Trying to free nonexistent resource <000003e0-000003e1>

2000-11-26 Thread Alan Cox

> > Nov 25 23:15:14 mimas kernel: Trying to free nonexistent resource 
><03e0-03e1>
> > Nov 25 23:15:14 mimas kernel: unloading PCMCIA Card Services
> 
> This is normal behaviour. It's buggy but it's harmless. It'll go away when
> the i82365 driver is rewritten in 2.5.

Why not fix it for 2.4. It doesnt actually seem hard ?


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



Re: readonly /proc/sys/vm/freepages (was: Re: PROBLEM: crashingkernels)

2000-11-26 Thread Rik van Riel

On Sun, 26 Nov 2000, Ingo Oeser wrote:
> On Sun, Nov 26, 2000 at 10:49:50AM +1100, Andrew Morton wrote:
> > You may also get some benefit from running:
> > 
> > # echo "512 1024 1536" > /proc/sys/vm/freepages
> > 
> > after booting.
> 
> ... which is a NOOP on recent 2.4.0-testX-kernels. So please
> complain at Rik for this (CC'ed him) ;-)

I wasn't aware I studied at tu-chemnitz ;)

> It's simply not that easy to set in the new VM since we count
> the inactive_clean and/or inactive_dirty pages like free pages
> in some cases.

And also, because HIGHMEM pages are not at all usable for kernel
things, so simply reserving 20MB for network bursts isn't going
to help you when it's all in highmem pages ...

> > The default values are a little too low for
> > applications which are very network intensive.
> 
> Especially for low memory machines, which are dedicated only for
> this purpose. Many people use (embedded) Linux and a (embedded)
> PC to cheaply fill functionality gaps in industrial
> environments.

Indeed, I agree that we want this tunable back...

regards,

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

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

-
To unsubscribe from this list: send the 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] removal of "static foo = 0"

2000-11-26 Thread Alexander Viro



On Sun, 26 Nov 2000, Elmer Joandi wrote:

> 
> Kernel has become so big that it really needs universal  debugging macros
> instead of comments. Comments are waste of brain&fingerpower, if the same
> can be explained by long variable names and debug macros.
> 
> static Subsystem_module_LocalVariableForThisPurpose;
> 
> int Subsytem_module_function_this_and_that(){
>   DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose  == 0 );
>   DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node != 
>NULL )
> }

I would suggest you to read through the following book and files:
* Kernighan & Pike, "The Practice of Programming"
* Documentation/CodingStyle
* drivers/net/aironet4500_proc.c
and consider, erm, discrepancies. On the second thought, reading K&R
might also be useful. IOW, no offense, but your C is bad beyond belief.

-
To unsubscribe from this list: send the 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: Trying to free nonexistent resource <000003e0-000003e1>

2000-11-26 Thread David Woodhouse

On Sun, 26 Nov 2000, Frank van Maarseveen wrote:

> Nov 25 23:15:12 mimas cardmgr[342]: exiting
> Nov 25 23:15:14 mimas kernel: Trying to free nonexistent resource <03e0-03e1>
> Nov 25 23:15:14 mimas kernel: unloading PCMCIA Card Services

This is normal behaviour. It's buggy but it's harmless. It'll go away when
the i82365 driver is rewritten in 2.5.

On which subject - anyone who has, or can get, a datasheet for the Intel
82092AA PCI-PCMCIA bridge, please drop me a line.

-- 
dwmw2


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



Re: problem with hp C1537A tape drives

2000-11-26 Thread Phil Randal

Date sent:  Sun, 26 Nov 2000 15:33:00 + (GMT)
From:   Paul Jakma <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject:problem with hp C1537A tape drives

> I have a problem with the aforementioned DDS-3 tape drives. I'm using
> one with amanda for backups. But every now and then the nightly backup
> fails with "I/O error" and i see the following in the system logs:
> 
> st0: Error with sense data: [valid=0] Info fld=0x0, Current st09:00:
> sense key Aborted Command
> Additional Sense indicates Data phase error
> 
> I try various things to get the drive to work again -> mt rewind, mt
> retension, load and unload the tape. "scsi remove-single-device" ->
> power off drive -> power up -> "scsi add-single-device". (it's not the
> tape cause i've tried replacing tapes).
>
> but nothing helps. now it mightn't be unreasonable to say the drive is
> faulty, so i replaced the drive with an identical C1537A. And... same
> thing happens again: after a couple of weeks of good backups i get the
> same problem again.
> 
> Is there a known problem with SCSI tape drives? or with HP DDS-3
> drives? What does the kernel error message mean? (it's all 0's so not
> much i guess). What is a "Data Phase error"?

Ah, have you tried cleaning the tape heads?

The Compaq tape drive manuals have interesting cleaning
instructions...  With new tapes, the heads nead cleaning
far more frequently than you'd expect.  I've found it needs
two cleaning tape passes to clear this one. 

Cleaning solves a similar problem I get with these drives
and Backup Exec for Netware.

Phil


Phil Randal   Home: [EMAIL PROTECTED]
Worcester, UK   http://www.rebee.clara.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



[PATCH] 2.4.0-test11 - drivers/net/epic100.c - use of DMA mapping

2000-11-26 Thread Francois ROMIEU

Hello,

  the following updates the epic100.c driver to the DMA mapping api.
It compiles. It survives ping flood (small/big sizes), insmod/rmmod and seems
to work as it should on an intel machine. Big-endian testers welcome.

--- linux-2.4.0-test11.orig/drivers/net/epic100.c   Sun Nov 26 11:41:47 2000
+++ linux-2.4.0-test11/drivers/net/epic100.cSun Nov 26 13:57:01 2000
@@ -73,6 +73,8 @@
 #define TX_RING_SIZE   16
 #define TX_QUEUE_LEN   10  /* Limit ring entries actually used.  */
 #define RX_RING_SIZE   32
+#define TX_TOTAL_SIZE  TX_RING_SIZE*sizeof(struct epic_tx_desc)
+#define RX_TOTAL_SIZE  RX_RING_SIZE*sizeof(struct epic_rx_desc)
 
 /* Operational parameters that usually are not changed. */
 /* Time in jiffies before concluding the transmitter is hung. */
@@ -172,8 +174,6 @@
 #define EPIC_IOTYPE PCI_USES_MASTER|PCI_USES_MEM|PCI_ADDR1
 #endif
 
-#define virt_to_le32desc(addr)  cpu_to_le32(virt_to_bus(addr))
-
 typedef enum {
SMSC_83C170_0,
SMSC_83C170,
@@ -276,14 +276,16 @@
 
 
 struct epic_private {
-   /* Tx and Rx rings first so that they remain paragraph aligned. */
-   struct epic_rx_desc rx_ring[RX_RING_SIZE];
-   struct epic_tx_desc tx_ring[TX_RING_SIZE];
+   struct epic_rx_desc *rx_ring;
+   struct epic_tx_desc *tx_ring;
/* The saved address of a sent-in-place packet/buffer, for skfree(). */
struct sk_buff* tx_skbuff[TX_RING_SIZE];
/* The addresses of receive-in-place skbuffs. */
struct sk_buff* rx_skbuff[RX_RING_SIZE];
 
+   dma_addr_t tx_ring_dma;
+   dma_addr_t rx_ring_dma;
+
/* Ring pointers. */
spinlock_t lock;/* Group with Tx control cache 
line. */
unsigned int cur_tx, dirty_tx;
@@ -342,6 +344,8 @@
struct epic_chip_info *ci = &epic_chip_info[ent->driver_data];
long ioaddr;
int chip_idx = (int) ent->driver_data;
+   void *ring_space;
+   dma_addr_t ring_dma;
 
card_idx++;

@@ -392,6 +396,21 @@
}
 #endif
 
+   pdev->driver_data = dev;
+   ep = dev->priv;
+
+   ring_space = pci_alloc_consistent(pdev, TX_TOTAL_SIZE, &ring_dma);
+   if (!ring_space)
+   goto err_out_iounmap;
+   ep->tx_ring = (struct epic_tx_desc *)ring_space;
+   ep->tx_ring_dma = ring_dma;
+
+   ring_space = pci_alloc_consistent(pdev, RX_TOTAL_SIZE, &ring_dma);
+   if (!ring_space)
+   goto err_out_unmap_tx;
+   ep->rx_ring = (struct epic_rx_desc *)ring_space;
+   ep->rx_ring_dma = ring_dma;
+
if (dev->mem_start) {
option = dev->mem_start;
duplex = (dev->mem_start & 16) ? 1 : 0;
@@ -402,12 +421,10 @@
duplex = full_duplex[card_idx];
}
 
-   pdev->driver_data = dev;
 
dev->base_addr = ioaddr;
dev->irq = pdev->irq;
 
-   ep = dev->priv;
ep->pci_dev = pdev;
ep->chip_flags = ci->drv_flags;
spin_lock_init (&ep->lock);
@@ -493,14 +510,18 @@
 
return 0;
 
-#ifndef USE_IO_OPS
-err_out_free_mmio:
-   release_mem_region (pci_resource_start (pdev, 1),
-   pci_resource_len (pdev, 1));
+err_out_unmap_tx:
+   pci_free_consistent(pdev, TX_TOTAL_SIZE, ep->tx_ring, ep->tx_ring_dma);
+err_out_iounmap:
+#ifdef USE_IO_OPS
+   iounmap(ioaddr);
 #endif
+err_out_free_mmio:
+   release_mem_region(pci_resource_start(pdev, 1),
+  pci_resource_len(pdev, 1));
 err_out_free_pio:
-   release_region (pci_resource_start (pdev, 0),
-   pci_resource_len (pdev, 0));
+   release_region(pci_resource_start(pdev, 0),
+  pci_resource_len(pdev, 0));
 err_out_free_netdev:
unregister_netdev(dev);
kfree(dev);
@@ -668,8 +689,8 @@
}
 
outl(ep->full_duplex ? 0x7F : 0x79, ioaddr + TxCtrl);
-   outl(virt_to_bus(ep->rx_ring), ioaddr + PRxCDAR);
-   outl(virt_to_bus(ep->tx_ring), ioaddr + PTxCDAR);
+   outl(ep->rx_ring_dma, ioaddr + PRxCDAR);
+   outl(ep->tx_ring_dma, ioaddr + PTxCDAR);
 
/* Start the chip's Rx process. */
set_rx_mode(dev);
@@ -755,9 +776,10 @@
ep->tx_threshold = TX_FIFO_THRESH;
outl(ep->tx_threshold, ioaddr + TxThresh);
outl(ep->full_duplex ? 0x7F : 0x79, ioaddr + TxCtrl);
-   outl(virt_to_bus(&ep->rx_ring[ep->cur_rx%RX_RING_SIZE]), ioaddr + PRxCDAR);
-   outl(virt_to_bus(&ep->tx_ring[ep->dirty_tx%TX_RING_SIZE]),
-ioaddr + PTxCDAR);
+   outl(ep->rx_ring_dma + (ep->cur_rx%RX_RING_SIZE)*
+   sizeof(struct epic_rx_desc), ioaddr + PRxCDAR);
+   outl(ep->tx_ring_dma + (ep->dirty_tx%TX_RING_SIZE)*
+sizeof(struct epic_tx_desc), ioaddr + PTxCDAR);
 
/* Start the chip's Rx process. */
set_rx_mode(dev);
@@ -852,11 +874,12 @@
for (i = 0; i < RX_RING_SIZE; i++) {
ep->rx_ring[i].rxs

Re: 2.4.0-test11(-ac4)/i386 configure bug

2000-11-26 Thread Jeff Epler

On Sun, Nov 26, 2000 at 04:38:01PM +, Tim Waugh wrote:
> On Sun, Nov 26, 2000 at 10:11:15AM -0600, Jeff Epler wrote:
> 
> > (not affected by the -ac4 patch, the file in question is not touched)
> > 
> > Parallel printer support (CONFIG_PRINTER) [N/m/?] (NEW) m
> >   Support for console on line printer (CONFIG_LP_CONSOLE) [N/y/?] (NEW)
> > 
> > Suggested change:
> 
> What's wrong with it?

How can you have the console on a modularized device?

Above, this is correctly forbidden for serial console.

Or can I dynamically change the console device after bootup?

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



Re: [PATCH] removal of "static foo = 0"

2000-11-26 Thread Elmer Joandi


Nice to see again a two cutting-edge-killing opinions.

Every time I really wonder, how such brilliant hackers can be that stupid
that they can not have cake and eat it the same time, and have to scratch
each-others eyes every time.

Use macros.

Kernel has become so big that it really needs universal  debugging macros
instead of comments. Comments are waste of brain&fingerpower, if the same
can be explained by long variable names and debug macros.

static Subsystem_module_LocalVariableForThisPurpose;

int Subsytem_module_function_this_and_that(){
DEBUG_ASSERT( Subsystem_module_LocalVariableForThisPurpose  == 0 );
DEBUG_ASSERT(MOST_OF_TIME,FS_AREA,MYFS_MODULE, somethingaboutIndodes->node != 
NULL )
}


Those macros would be acceptable if they are unified and taken to
kernel configuration level, so it would be easy to switch them in/out 
not only as boolean option but systematically for different levels,
subsystems and modules.

elmer.


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



Re: gcc-2.95.2-51 is buggy

2000-11-26 Thread Rik van Riel

On 26 Nov 2000, Olaf Dietsche wrote:

> A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as
> well. So, if you configure your kernel with `CONFIG_M686=y' the
> problem should be gone.

Except for the fact that it'll no longer boot on Pentiums
and 486es ;)

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

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

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

2000-11-26 Thread Tim Waugh

On Sat, Nov 25, 2000 at 05:36:58PM -0500, John Cavan wrote:

> Just so I understand the differences, for learning purposes... Tim
> did this a little different than I did and I'd just like to
> understand the "whys" of it.

It's Douglas Gilbert's modified patch; Douglas explained that he
didn't find that dropping the io_request_lock for just
parport_enumerate was enough during his testing.

Tim.
*/

 PGP signature


Re: 2.4.0-test11(-ac4)/i386 configure bug

2000-11-26 Thread Tim Waugh

On Sun, Nov 26, 2000 at 10:11:15AM -0600, Jeff Epler wrote:

> (not affected by the -ac4 patch, the file in question is not touched)
> 
> Parallel printer support (CONFIG_PRINTER) [N/m/?] (NEW) m
>   Support for console on line printer (CONFIG_LP_CONSOLE) [N/y/?] (NEW)
> 
> Suggested change:

What's wrong with it?

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



Re: 2.4.0-test5 bug: invalid "shmid_kernel" passed to "shm_nopage_core"

2000-11-26 Thread Christoph Rohland

Hi Kevin,

[EMAIL PROTECTED] (Kevin Buhr) writes:

> I know no way to reproduce it.  I've been using "test5" reliably since
> just after its release, and I've triggered this bug only the one time.

That's what I feared :-(

> I use a SysReq patch to do an oops-style dump instead of the usual
> "showPc" function, so I was able to copy a stack dump down.

Could you send me the patch? Does it do the dump on all cpus?

> I'll fiddle around a bit more and see if I can find a way to reproduce
> it reliably.

I would be happy to help debug the shm code if you find a way to
reproduce it. 

Christoph

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



Re: kernel_thread bogosity

2000-11-26 Thread Andrea Arcangeli

On Fri, Nov 24, 2000 at 08:52:47PM +0100, Pavel Machek wrote:
> How can that work? restore_args ends with iret, anyway, and iret does
> reload esp afaics...

... only if there's an IPL change during the iret. Page 3-321 of 24319102.pdf
from Intel:

[..] If the return is to another privilege level, the IRET instruction
also pops the stack pointer and SS from the stack, before resuming
program execution. [..]

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



2.4.0-test11(-ac4)/i386 configure bug

2000-11-26 Thread Jeff Epler

(not affected by the -ac4 patch, the file in question is not touched)

Parallel printer support (CONFIG_PRINTER) [N/m/?] (NEW) m
  Support for console on line printer (CONFIG_LP_CONSOLE) [N/y/?] (NEW)

Suggested change:

--- linux-2.4.0-test11/drivers/char/Config.in.orig  Sun Nov 26 10:05:10 2000
+++ linux-2.4.0-test11/drivers/char/Config.in   Sun Nov 26 10:05:38 2000
@@ -75,7 +75,7 @@
 fi
 if [ "$CONFIG_PARPORT" != "n" ]; then
dep_tristate 'Parallel printer support' CONFIG_PRINTER $CONFIG_PARPORT
-   if [ "$CONFIG_PRINTER" != "n" ]; then
+   if [ "$CONFIG_PRINTER" = "y" ]; then
   bool '  Support for console on line printer' CONFIG_LP_CONSOLE
fi
dep_tristate 'Support for user-space parallel port device drivers' CONFIG_PPDEV 
$CONFIG_PARPORT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: gcc 2.95.2 is buggy

2000-11-26 Thread Alessandro Suardi

(cough) doesn't reproduce on my 2.95.2...

[asuardi@princess misc]$ vi bug.c

(cut'n'paste from Andries' email)

[asuardi@princess misc]$ gcc -Wall -O2 -o bug bug.c
[asuardi@princess misc]$ ./bug
0x0
[asuardi@princess misc]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)

'bug' binary available upon request.


Ciao,

--alessandro  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Linux:  kernel 2.2.18p22/2.4.0-t11 glibc-2.1.94 gcc-2.95.2 binutils-2.10.0.33
Oracle: Oracle8i 8.1.6.1.0 Enterprise Edition for Linux
motto:  Tell the truth, there's less to remember.
-
To unsubscribe from this list: send the 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: crashing kernels

2000-11-26 Thread Mr. Big


Previous day I followed the hint of Alan, and made a 2.2.14 kernel, with
the DAC960 driver taken from the 2.2.17, for these changes I've copied
the:
drivers/block/DAC960.c
drivers/block/DAC960.h
drivers/pci/oldrpoc.c
include/linux/pci.h
from the 2.2.17 sourcetree into the 2.2.14. Ok, it compiled.
We also borrowed another mainboard, cpu's and ram for test. We changed
them all, but the borrowed ram was just 512Mb, so we had to do a hard cut
back on the services, for could fit into it. I think I didn't mention yet,
we're using an intel L440GX+ mainboard. For the CPU's see my original
mail. The new CPU's were the same speed (550Mhz) but Katmai's insted of
the Coppermine's.
We removed the Eepros also, just left a 3Com, and a dlink card. This one
isn't the best, but with it's own driver in another computer it's working
with the 2.2.14 kernel since months ago without any troubles.

The kernel booted up. Just the 3Com driver throwed some errors, and warned
that the cheksum isn't good, so I decided to take the driver from the
2.2.17 also, for this I copied the
drivers/net/3c59x.c

For the boot I also followed Andrew's hint, and booted with the noapic
option.
This one is much newer, and this way the 2.2.14 worked well the whole
night.

In the afternoon we decided to put back the original mainboard+ram+cpu.
We booted the kernel described above.
I just noticed then, that all the interrupts went to the CPU1, while the
CPU0 didn't get any. Is this because of the noapic option?

The worst is, that after two hours same black crash again. (no ping, no
console, no keyboard leds)

I believe we face a kind of hardware problem, or some hardware specific
software problem. Any idea wich of the hardware components could be bad,
or wich are badly supported by some drivers?

> This is caused by the APIC(s) forgetting how to deliver interrupts
> for a particular IRQ.  Normally, reloading the driver doesn't help.
> But in your case it did.  This is odd.

How could an APIC 'forget' how to deliver the interrupts? Could this mean
a problem with the mainboard, or with the CPU?

Thanks for Your help.

++
| Nagy Attila|
|   mailto:[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: problem with hp C1537A tape drives

2000-11-26 Thread Mr. James W. Laferriere


Hello Paul ,  Is the tape drive the only drive on that controller ?

 -  If it is the only drive then , I have just one suggestion
-verify- all cables are seated correctly & -verify- that there
is proper termination on the bus .

 -  If it is Not the only drive then ,
Try grabbing an pci scsi card of known goodness & place the tape
drive on that all by itself (just as a test) , making sure of
proper termination .
If that works then reveiw the configurations of the other
drives/tapes/... that are on the bus causing problems .
Hth ,  JimL

On Sun, 26 Nov 2000, Paul Jakma wrote:
> Ooops.. yes.. that info might have been useful. :)
> The box is a Compaq PL3000. Chipset is the onboard Sym 53c876, driven
> by the ncr53c8xx driver. Drive is external.
> Kernel is RH6.2 default 2.2.14-5.0smp.

> On Sun, 26 Nov 2000, Mr. James W. Laferriere wrote:
> > Hello Paul ,  Could you add a little more info like which scsi
> > chipset you are using & what the driver version is & what kernel
> > version you are running also (One more )& how you have the drive
> > chained to the scsi-bus .  Someplace there is a pointer on howto
> > reset the scsi-bus from the /proc system , BUT the method is
> > highly not recommended .  Hth ,  JimL
   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

-
To unsubscribe from this list: send the 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 with hp C1537A tape drives

2000-11-26 Thread Paul Jakma

Ooops.. yes.. that info might have been useful. :)

The box is a Compaq PL3000. Chipset is the onboard Sym 53c876, driven
by the ncr53c8xx driver. Drive is external.

Kernel is RH6.2 default 2.2.14-5.0smp.

On Sun, 26 Nov 2000, Mr. James W. Laferriere wrote:

>
>   Hello Paul ,  Could you add a little more info like which scsi
>   chipset you are using & what the driver version is & what kernel
>   version you are running also (One more )& how you have the drive
>   chained to the scsi-bus .  Someplace there is a pointer on howto
>   reset the scsi-bus from the /proc system , BUT the method is
>   highly not recommended .  Hth ,  JimL

-
To unsubscribe from this list: send the 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 with hp C1537A tape drives

2000-11-26 Thread Mr. James W. Laferriere


Hello Paul ,  Could you add a little more info like which scsi
chipset you are using & what the driver version is & what kernel
version you are running also (One more )& how you have the drive
chained to the scsi-bus .  Someplace there is a pointer on howto
reset the scsi-bus from the /proc system , BUT the method is
highly not recommended .  Hth ,  JimL

On Sun, 26 Nov 2000, Paul Jakma wrote:
> I have a problem with the aforementioned DDS-3 tape drives. I'm using
> one with amanda for backups. But every now and then the nightly backup
> fails with "I/O error" and i see the following in the system logs:
> st0: Error with sense data: [valid=0] Info fld=0x0, Current st09:00:
> sense key Aborted Command
> Additional Sense indicates Data phase error
> I try various things to get the drive to work again -> mt rewind, mt
> retension, load and unload the tape. "scsi remove-single-device" ->
> power off drive -> power up -> "scsi add-single-device". (it's not the
> tape cause i've tried replacing tapes).
> but nothing helps. now it mightn't be unreasonable to say the drive is
> faulty, so i replaced the drive with an identical C1537A. And... same
> thing happens again: after a couple of weeks of good backups i get the
> same problem again.
> Is there a known problem with SCSI tape drives? or with HP DDS-3
> drives? What does the kernel error message mean? (it's all 0's so not
> much i guess). What is a "Data Phase error"?
> thanks in advance,
> Paul Jakma.
   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

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



Re: How to transfer memory from PCI memory directly to user space safely and portable?

2000-11-26 Thread Anders Torger

On Sun, 26 Nov 2000, you wrote:
> On Sun, Nov 26, 2000 at 02:21:31PM +0100, Anders Torger wrote:
> > memcpy_toio(iobase, user_space_src, count);
>
> I hope count isn't provided by userspace here ?

Fortunately, 'count' is controlled by the driver architecture (ALSA), and not 
the user.

> > 1. What happens if the user space memory is swapped to disk? Will
> > verify_area() make sure that the memory is in physical RAM when it
> > returns, or will it return -EFAULT, or will something even worse happen?
>
> On i386, you'll sleep implicitly waiting for the page fault to be handled; 
> in the generic case, anything could happen.

Do you know of an architecture that will not do like i386 in this case?

> > 2. Is this code really portable? I currently have an I386 architecture,
> > and I could use copy_to/from_user on that instead, but that is not
> > portable. Now, by using memcpy_to/fromio instead, is this code fully
> > portable?
>
> No.  It would be portable if you were using memcpy_fromuser_toio and it
> existed.

Oh, I see. Again, I wonder, do you know of any architecture, currently 
supported by Linux, where my code would fail? It would be helpful to know.

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



Re: gcc-2.95.2-51 is buggy

2000-11-26 Thread Olaf Dietsche

Rik van Riel <[EMAIL PROTECTED]> writes:

> On Sat, 25 Nov 2000, Andries Brouwer wrote:
> > On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote:
> > 
> > > The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.
> > 
> > Yes. Probably you have seen it by now, but the difference between
> > good and bad versions of gcc-2.95.2 did not lie in the applied patches,
> > but was the difference between compilation for 686 or 386.
> > It is not your (SuSE's, Debian's) fault. A fix already exists.
> 
> Indeed, this should be fixed soon.
> 
> I'm sure a simple 'apt-get upgrade' will install a new
> gcc RPM on my workstation soon ;)

A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as
well. So, if you configure your kernel with `CONFIG_M686=y' the problem
should be gone.

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



problem with hp C1537A tape drives

2000-11-26 Thread Paul Jakma

I have a problem with the aforementioned DDS-3 tape drives. I'm using
one with amanda for backups. But every now and then the nightly backup
fails with "I/O error" and i see the following in the system logs:

st0: Error with sense data: [valid=0] Info fld=0x0, Current st09:00:
sense key Aborted Command
Additional Sense indicates Data phase error

I try various things to get the drive to work again -> mt rewind, mt
retension, load and unload the tape. "scsi remove-single-device" ->
power off drive -> power up -> "scsi add-single-device". (it's not the
tape cause i've tried replacing tapes).

but nothing helps. now it mightn't be unreasonable to say the drive is
faulty, so i replaced the drive with an identical C1537A. And... same
thing happens again: after a couple of weeks of good backups i get the
same problem again.

Is there a known problem with SCSI tape drives? or with HP DDS-3
drives? What does the kernel error message mean? (it's all 0's so not
much i guess). What is a "Data Phase error"?

thanks in advance,

Paul Jakma.

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



  1   2   >