Re: CDROMPLAYTRKIND causes an oops on aic7xxx
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?
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"
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
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.
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
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.
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
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
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"
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
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
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
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
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?
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))
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
> > 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?
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
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?
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
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?
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
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
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
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
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
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.
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
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.
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
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
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
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
> 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
"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
"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
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?
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?
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
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)
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.
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
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
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
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)
[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
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
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?
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
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?
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
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"
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
> + {"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 [< >]
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"
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
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
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
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
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?
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
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
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
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
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"
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"
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
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
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
> 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
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
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
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
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?
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
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
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"
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>
> > 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)
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"
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>
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
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
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
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"
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
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
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
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"
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
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
(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
(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
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
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
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
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?
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
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
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/
