Re: iso9660 endianness cleanup patch
On Mon, 30 Apr 2001, H. Peter Anvin wrote: > > The attached patch fixes both. It is against 2.4.4, but from the looks > of it it should patch against -ac as well. Btw, please use "static inline" instead of "extern inline", as gcc may decide not to inline the latter at all, leading to confusing link-time errors. (Gcc may also decide not to inline "static inline", but then gcc will output the actual body of the function out-of-line if it gets used, so you don't get the link-time failure). Right now only certain broken versions of gcc will actually show this behaviour, I think, but it's at least in theory going to be an issue. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about /proc/kmsg semantics..
Followup to: <[EMAIL PROTECTED]> By author:Michael Bacarella <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > I've seen a couple of patches in the archives to make open()/close() > on /proc/kmsg do more than NOP. As of 2.4.4, klogd still needs to > run as root since access is checked on read() rather than once at > open(). I can't find the rationale as to why they're rejected. > > Also, why is reading /proc/kmsg a privileged operation, yet dmesg > can happily print out the entire ring via (do_)syslog() ? > Probably because reading /proc/kmsg may cause syslogd to miss messages. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
iso9660 endianness cleanup patch
Hi guys,
I was looking over the iso9660 code, and noticed that it was doing
endianness conversion via ad hoc *functions*, not even inlines; nor did
it take any advantage of the fact that iso9660 is bi-endian (has "all"
data in both bigendian and littleendian format.)
The attached patch fixes both. It is against 2.4.4, but from the looks
of it it should patch against -ac as well.
-hpa
--- linux-2.4.4/include/linux/iso_fs.h Fri Apr 27 15:48:20 2001
+++ linux-2.4.4-ciso/include/linux/iso_fs.h Mon Apr 30 20:09:31 2001
@@ -165,14 +165,51 @@
#define ISOFS_SUPER_MAGIC 0x9660
#ifdef __KERNEL__
-extern int isonum_711(char *);
-extern int isonum_712(char *);
-extern int isonum_721(char *);
-extern int isonum_722(char *);
-extern int isonum_723(char *);
-extern int isonum_731(char *);
-extern int isonum_732(char *);
-extern int isonum_733(char *);
+/* Number conversion inlines, named after the section in ISO 9660
+ they correspond to. */
+
+#include
+
+extern inline int isonum_711(char *p)
+{
+ return *(u8 *)p;
+}
+extern inline int isonum_712(char *p)
+{
+ return *(s8 *)p;
+}
+extern inline int isonum_721(char *p)
+{
+ return le16_to_cpu(*(u16 *)p);
+}
+extern inline int isonum_722(char *p)
+{
+ return be16_to_cpu(*(u16 *)p);
+}
+extern inline int isonum_723(char *p)
+{
+#ifdef __BIG_ENDIAN
+ return be16_to_cpu(*(u16 *)(p+2));
+#else
+ return le16_to_cpu(*(u16 *)p);
+#endif
+}
+extern inline int isonum_731(char *p)
+{
+ return le32_to_cpu(*(u32 *)p);
+}
+extern inline int isonum_732(char *p)
+{
+ return be32_to_cpu(*(u32 *)p);
+}
+extern inline int isonum_733(char *p)
+{
+#ifdef __BIG_ENDIAN
+ return be32_to_cpu(*(u32 *)(p+4));
+#else
+ return le32_to_cpu(*(u32 *)p);
+#endif
+}
extern int iso_date(char *, int);
extern int parse_rock_ridge_inode(struct iso_directory_record *, struct inode *);
--- linux-2.4.4/fs/isofs/util.c Wed Nov 29 10:11:38 2000
+++ linux-2.4.4-ciso/fs/isofs/util.cMon Apr 30 20:04:24 2001
@@ -1,90 +1,9 @@
/*
* linux/fs/isofs/util.c
- *
- * The special functions in the file are numbered according to the section
- * of the iso 9660 standard in which they are described. isonum_733 will
- * convert numbers according to section 7.3.3, etc.
- *
- * isofs special functions. This file was lifted in its entirety from
- * the 386BSD iso9660 filesystem, by Pace Willisson <[EMAIL PROTECTED]>.
*/
#include
-
-int
-isonum_711 (char * p)
-{
- return (*p & 0xff);
-}
-
-int
-isonum_712 (char * p)
-{
- int val;
-
- val = *p;
- if (val & 0x80)
- val |= 0xff00;
- return (val);
-}
-
-int
-isonum_721 (char * p)
-{
- return ((p[0] & 0xff) | ((p[1] & 0xff) << 8));
-}
-
-int
-isonum_722 (char * p)
-{
- return (((p[0] & 0xff) << 8) | (p[1] & 0xff));
-}
-
-int
-isonum_723 (char * p)
-{
-#if 0
- if (p[0] != p[3] || p[1] != p[2]) {
- fprintf (stderr, "invalid format 7.2.3 number\n");
- exit (1);
- }
-#endif
- return (isonum_721 (p));
-}
-
-int
-isonum_731 (char * p)
-{
- return ((p[0] & 0xff)
- | ((p[1] & 0xff) << 8)
- | ((p[2] & 0xff) << 16)
- | ((p[3] & 0xff) << 24));
-}
-
-int
-isonum_732 (char * p)
-{
- return (((p[0] & 0xff) << 24)
- | ((p[1] & 0xff) << 16)
- | ((p[2] & 0xff) << 8)
- | (p[3] & 0xff));
-}
-
-int
-isonum_733 (char * p)
-{
-#if 0
- int i;
-
- for (i = 0; i < 4; i++) {
- if (p[i] != p[7-i]) {
- fprintf (stderr, "bad format 7.3.3 number\n");
- exit (1);
- }
- }
-#endif
- return (isonum_731 (p));
-}
+#include
/*
* We have to convert from a MM/DD/YY format to the Unix ctime format.
Re: 2.4.4 sluggish under fork load
On Mon, Apr 30, 2001 at 11:38:23PM -0300, Rik van Riel wrote:
> On Mon, 30 Apr 2001, Andrea Arcangeli wrote:
> > On Sun, Apr 29, 2001 at 10:26:57AM +0200, Peter Osterlund wrote:
>
> > > - p->counter = current->counter;
> > > - current->counter = 0;
> > > + p->counter = (current->counter + 1) >> 1;
> > > + current->counter >>= 1;
> > > + current->policy |= SCHED_YIELD;
> > > current->need_resched = 1;
> >
> > please try to reproduce the bad behaviour with 2.4.4aa2. There's a bug
> > in the parent-timeslice patch in 2.4 that I fixed while backporting it
> > to 2.2aa and that I now forward ported the fix to 2.4aa. The fact
> > 2.4.4 gives the whole timeslice to the child just gives more light to
> > such bug.
>
> The fact that 2.4.4 gives the whole timeslice to the child
> is just bogus to begin with.
>
> The problem people tried to solve was "make sure the kernel
> runs the child first after a fork", this has just about
> NOTHING to do with how the timeslice is distributed.
>
> Now, since we are in a supposedly stable branch of the kernel,
> why mess with the timeslice distribution between parent and
> child? The timeslice distribution that has worked very well
> for the last YEARS...
I'm running with this below patch applied since a some time (I didn't
submitted it because for some reason unless I do p->policy &=
~SCHED_YIELD ksoftirqd deadlocks at boot and I didn't yet investigated
why, and I'd like to have the whole picture on it first):
diff -urN z/include/linux/sched.h z1/include/linux/sched.h
--- z/include/linux/sched.h Mon Apr 30 04:22:25 2001
+++ z1/include/linux/sched.hMon Apr 30 02:45:07 2001
@@ -301,7 +301,7 @@
* all fields in a single cacheline that are needed for
* the goodness() loop in schedule().
*/
- int counter;
+ volatile int counter;
int nice;
unsigned int policy;
struct mm_struct *mm;
diff -urN z/kernel/fork.c z1/kernel/fork.c
--- z/kernel/fork.c Mon Apr 30 04:22:25 2001
+++ z1/kernel/fork.cMon Apr 30 03:49:26 2001
@@ -666,17 +666,17 @@
p->pdeath_signal = 0;
/*
-* Give the parent's dynamic priority entirely to the child. The
-* total amount of dynamic priorities in the system doesn't change
-* (more scheduling fairness), but the child will run first, which
-* is especially useful in avoiding a lot of copy-on-write faults
-* if the child for a fork() just wants to do a few simple things
-* and then exec(). This is only important in the first timeslice.
-* In the long run, the scheduling behavior is unchanged.
+* Scheduling the child first is especially useful in avoiding a
+* lot of copy-on-write faults if the child for a fork() just wants
+* to do a few simple things and then exec().
*/
- p->counter = current->counter;
- current->counter = 0;
- current->need_resched = 1;
+ {
+ int counter = current->counter >> 1;
+ current->counter = p->counter = counter;
+ p->policy &= ~SCHED_YIELD;
+ current->policy |= SCHED_YIELD;
+ current->need_resched = 1;
+ }
/* Tell the parent if it can get back its timeslice when child exits */
p->get_child_timeslice = 1;
The only point of my previous email is that if a fork loop has very
invasive effect on the rest of the system that more probably indicates
people got bitten by the bug in the parent-timeslice logic, furthmore I
never noticed any sluggish behaviour on my systems and before posting my
previous email I had 1 definitive feedback that the bad beahviour
observed on vanilla 2.4.4 with parallel compiles in the background got
cured *completly* by my tree (that in the tested revision didn't
included the above inlined change yet). So I thought it was worth
mentioning about the effect of the parent-timeslice bugfix here too.
This doesn't mean I don't want something like the above inlined patch
integrated.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
More!! Kernel NULL pointer, over my head...
OK... a 'tar xvfz myFile.tar.gz' results in the following in /var/log/syslog May 1 05:58:11 mnemosyne kernel: Unable to handle kernel NULL pointer dereference at virtual address May 1 05:58:11 mnemosyne kernel: current->tss.cr3 = 01e55000, %cr3 = 01e55000 May 1 05:58:11 mnemosyne kernel: *pde = however this time I'm using a different file. I can however sucessfully do the following gzip -d ; tar xvf myFile.tar.gz Don't know if that gives anyone any hints... I haven't changed any software on the system recently so I don't think it can be a bad tar or gzip binary. I get the same for root and non-privileged users. thanks again. Jamie... On Tue, 1 May 2001, Jamie Harris wrote: > Morning all, > > Sorry for the big cross post but I don't have the first clue about where > to send this one. I get this from my stock 2.2.18 kernel in > /var/log/syslog: > > May 1 05:27:36 mnemosyne kernel: Unable to handle kernel NULL pointer > dereference at virtual address > May 1 05:27:36 mnemosyne kernel: current->tss.cr3 = 00362000, %cr3 = > 00362000 > May 1 05:27:36 mnemosyne kernel: *pde = > May 1 05:29:36 mnemosyne kernel: Unable to handle kernel NULL pointer > dereference at virtual address > May 1 05:29:36 mnemosyne kernel: current->tss.cr3 = 036dc000, %cr3 = > 036dc000 > May 1 05:29:36 mnemosyne kernel: *pde = > May 1 05:30:28 mnemosyne kernel: Unable to handle kernel NULL pointer > dereference at virtual address > May 1 05:30:28 mnemosyne kernel: current->tss.cr3 = 00ca7000, %cr3 = > 00ca7000 > May 1 05:30:28 mnemosyne kernel: *pde = > > > This time it seemed to be caused by running tar on a file, but I've > noticed a similar error in the past but they've never made anything fall > over. The tar process appeared to die but then again so did the telnet > session so I don't know in what order they went down. I tried 3 times > just to check it wasn't a fluke... What other details would be useful?? > > Cheers Jamie... > > PS I'm not on the linux-kernel list so please post to me directly... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ***Slowly and surely the UNIX crept up on the Nintendo user...*** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/ED d-(++) s:+ a- C+++>$ U+++>$ P L+++>+ E+(---) W++ N o? K? w() O- M V? PS PE? Y PGP- t+ 5 X- R- tv- b++ DI++ D+++ G e++ h* r++>+++ y+++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 locks up on SMP
On Mon, 30 Apr 2001, Ion Badulescu wrote: > Ok, so onto the binary search through the 2.2.19pre series... I think it started in 2.2.19pre10. I can reproduce the hang on pre10, quite easily, but I couldn't reproduce it on pre5, pre7 and pre9. I'll try a few other pre versions, just to make sure. One of the things that are different between pre10 and the others is NFS: the client is broken in all versions except pre10. I'm not sure how much it matters, since I wasn't pounding on NFS. Anyway, that's why I want to try a few other kernels -- maybe it does matter after all. Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question about /proc/kmsg semantics..
Two pronged: I've seen a couple of patches in the archives to make open()/close() on /proc/kmsg do more than NOP. As of 2.4.4, klogd still needs to run as root since access is checked on read() rather than once at open(). I can't find the rationale as to why they're rejected. Also, why is reading /proc/kmsg a privileged operation, yet dmesg can happily print out the entire ring via (do_)syslog() ? Thanks -- Michael Bacarella <[EMAIL PROTECTED]> Technical Staff / System Development, New York Connect.Net, Ltd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel NULL pointer, over my head...
Morning all, Sorry for the big cross post but I don't have the first clue about where to send this one. I get this from my stock 2.2.18 kernel in /var/log/syslog: May 1 05:27:36 mnemosyne kernel: Unable to handle kernel NULL pointer dereference at virtual address May 1 05:27:36 mnemosyne kernel: current->tss.cr3 = 00362000, %cr3 = 00362000 May 1 05:27:36 mnemosyne kernel: *pde = May 1 05:29:36 mnemosyne kernel: Unable to handle kernel NULL pointer dereference at virtual address May 1 05:29:36 mnemosyne kernel: current->tss.cr3 = 036dc000, %cr3 = 036dc000 May 1 05:29:36 mnemosyne kernel: *pde = May 1 05:30:28 mnemosyne kernel: Unable to handle kernel NULL pointer dereference at virtual address May 1 05:30:28 mnemosyne kernel: current->tss.cr3 = 00ca7000, %cr3 = 00ca7000 May 1 05:30:28 mnemosyne kernel: *pde = This time it seemed to be caused by running tar on a file, but I've noticed a similar error in the past but they've never made anything fall over. The tar process appeared to die but then again so did the telnet session so I don't know in what order they went down. I tried 3 times just to check it wasn't a fluke... What other details would be useful?? Cheers Jamie... PS I'm not on the linux-kernel list so please post to me directly... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ***Slowly and surely the UNIX crept up on the Nintendo user...*** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/ED d-(++) s:+ a- C+++>$ U+++>$ P L+++>+ E+(---) W++ N o? K? w() O- M V? PS PE? Y PGP- t+ 5 X- R- tv- b++ DI++ D+++ G e++ h* r++>+++ y+++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
On Tue, 1 May 2001, Keith Owens wrote: > On Mon, 30 Apr 2001 18:10:56 -0400, > "Michael H. Warfield" <[EMAIL PROTECTED]> wrote: > >On Mon, Apr 30, 2001 at 01:22:59PM -0700, Francois Gouget wrote: > >> Apr 30 13:19:34 oleron cardmgr[148]: initializing socket 0 > >> Apr 30 13:19:34 oleron cardmgr[148]: socket 0: Aironet PC4800 > >> Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_core' > >> Apr 30 13:19:34 oleron cardmgr[148]: + Warning: >/lib/modules/2.4.4/kernel/drivers/net/aironet4500_core.o > >> symbol for parameter rx_queue_len not found > > Bug in drivers/net/aironet4500_core.c. It has > MODULE_PARM(rx_queue_len,"i"); > but rx_queue_len is never defined. Only a warning. Ok, so a fix would be: --- cut here --- --- aironet4500_core.c.orig Mon Apr 30 19:14:38 2001 +++ aironet4500_core.c Mon Apr 30 19:14:47 2001 @@ -2564,10 +2564,9 @@ #if LINUX_VERSION_CODE >= 0x20100 MODULE_PARM(awc_debug,"i"); -MODULE_PARM(rx_queue_len,"i"); MODULE_PARM(tx_rate,"i"); MODULE_PARM(channel,"i"); -MODULE_PARM(tx_full_rate,"i"); +//MODULE_PARM(tx_full_rate,"i"); MODULE_PARM(adhoc,"i"); MODULE_PARM(master,"i"); MODULE_PARM(slave,"i"); --- cut here --- And if someone knows that tx_full_rate will never be used again then there's 2 other commented lines to remove. > >> Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_proc' > >> Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_cs' > >> Apr 30 13:19:35 oleron cardmgr[148]: get dev info on socket 0 > >> failed: Resource temporarily unavailable > > Separate problem, the aironet4500_cs driver could not get its > resources. I thought it was supposed to display more messages if it cannot get its resources. From the pcmcia-howto: RequestIO: Resource in use RequestIRQ: Resource in use RequestWindow: Resource in use GetNextTuple: No more items could not allocate nn IO ports for CardBus socket n could not allocate nnK memory for CardBus socket n could not allocate interrupt for CardBus socket n -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux: the choice of a GNU generation - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 sluggish under fork load
>The fact that 2.4.4 gives the whole timeslice to the child >is just bogus to begin with. I only did that because I could not find another way to make the child run first that worked in practice. I tried other things before that. Since Peter Osterlund's SCHED_YIELD thing works, we no longer have to give all of the CPU to the child. The scheduler time slices are currently enormous, so as long as the child gets even one clock tick before the parent runs, it should reach the exec() if that is its plan. 1 tick = 10ms = 10 million cycles on a 1GHz CPU, which should be enough time to encrypt my /boot/vmlinux in twofish if it's in RAM. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops during fsck.ext2, Linux 2.4.3
I had my computer go down hard the other day, while it was sitting idle (some time during the night). This was while in X, so no messages was visible on the screen, and nothing was recorded in the logs. When rebooting, Linux oopsed several times while running ext2.fsck, requiring reboots every time, on different partitions attached to different IDE-controllers. I only recorded one of the oopses (by hand, so there may be mistakes although I did proof-read it). Since then the kernel has been rock-solid, and I have been running the same 2.4.3-kernel since then. I am running Debian unstable, current every day. The system is a dual Pentium III 800EB on an MSI 6321 mainboard (MSI 694D Pro AI), only IDE drives: Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:pio, hdd:pio PDC20267: IDE controller on PCI bus 00 dev 60 PDC20267: chipset revision 2 PDC20267: not 100% native mode: will probe irqs later PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0xac00-0xac07, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0xac08-0xac0f, BIOS settings: hdg:pio, hdh:DMA hda: IBM-DTLA-307030, ATA DISK drive hde: WDC WD200BB-00AUA1, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide2 at 0x9c00-0x9c07,0xa002 on irq 18 hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(66) hde: 39102336 sectors (20020 MB) w/2048KiB Cache, CHS=38792/16/63, UDMA(100) Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 > /dev/ide/host2/bus0/target0/lun0: [PTBL] [2434/255/63] p1 /dev/hde has since been repartitioned. Any other information available upon request. Config attached at end of mail. Unable to handle kernel NULL pointer dereference at virtual address 0020 c0131d80 *pde = Oops: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 0306 ebx: ecx: d6dd4800 edx: 0008 esi: 0004f141 edi: ebp: esp: d7b41f28 ds: 0018 es: 0018ss: 0018 Process fsck.ext2 (pid: 45, stackpage=d7b41000) Stack: 0306 c64e4fa0 0306 03060306 c01382a0 0306 d7c05e00 d7e89920 d7b4f860 d7d928e0 c0138352 c64e4fa0 c0131231 d7b4f860 d7c05e00 d7c05e00 0805c658 Call Trace: [] [] [] [] [] [] Code: 8b 7b 20 0f b7 44 24 1a 66 39 43 0c 0f 85 9e 00 00 00 8b 43 >>EIP; c0131d80 <__invalidate_buffers+50/138> <= Trace; c01382a0 Trace; c0138352 Trace; c0131231 Trace; c01301e2 Trace; c0130247 Trace; c0106f5b Code; c0131d80 <__invalidate_buffers+50/138> <_EIP>: Code; c0131d80 <__invalidate_buffers+50/138> <= 0: 8b 7b 20 mov0x20(%ebx),%edi <= Code; c0131d83 <__invalidate_buffers+53/138> 3: 0f b7 44 24 1amovzwl 0x1a(%esp,1),%eax Code; c0131d88 <__invalidate_buffers+58/138> 8: 66 39 43 0c cmp%ax,0xc(%ebx) Code; c0131d8c <__invalidate_buffers+5c/138> c: 0f 85 9e 00 00 00 jneb0 <_EIP+0xb0> c0131e30 <__invalidate_buffers+100/138> Code; c0131d92 <__invalidate_buffers+62/138> 12: 8b 43 00 mov0x0(%ebx),%eax .config -- Håvard Lygre, [EMAIL PROTECTED] Bergen IT-Teknikk ANS, Conrad Mohrsvei 11, 5068 Bergen Tlf: 55 360773 Fax: 55 360774
CDROM? oops in 2.2.19
Hi all
We are currently running 2.2.19 on an 900MHz athlon (not overclocked). Late
last night one of our users tried to umount a CDROM. The process hung in
the "D" state, as did subsequent runs of the umount program. According to
/etc/mtab the drive is still mounted and indeed you can't eject the CD.
Running "mount" also causes a "D" state mount process.
dmesg reported two oopses associated with these umount and mount actions.
The result of running them through ksymoops are included below.
Some other potentially interesting system info follows.
auster:src>cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 4
model name : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 900.068
cache size : 256 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36
psn mmxext mmx fxsr 3dnowext 3dnow
bogomips: 1795.68
The kernel is NOT SMP, and the machine has 512MB RAM and 512MB swap. The
CDROM is an IDE drive. I can provide further information as required.
Also, please CC me followups; I regularly lurk on a mailing list archive,
but it is easy to miss posts.
ksymoops output:
ksymoops 2.4.1 on i686 2.2.19. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.19/ (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.
Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found in
System.map. Ignoring ksyms_base entry
Unable to handle kernel NULL pointer dereference at virtual address 001c
current->tss.cr3 = 02448000, %cr3 = 02448000
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ebx: ecx: 1600 edx: 1600
esi: 0e7a edi: ebp: esp: cc279f20
ds: 0018 es: 0018 ss: 0018
Process umount (pid: 8526, process nr: 52, stackpage=cc279000)
Stack: 1600 0001 1600d160 c01c2685 1600 c0244600
d9dfac40 d9dfac40 1600 1600 c0197d59 d9dfac40 c0187c20
d9dfac40 c0244600 d9dfac40 c0125267 d9dfac40
Call Trace: [] [] [] [] []
[] []
[]
Code: 8b 6b 1c 66 8b 54 24 16 66 39 53 0c 75 3c 8b 43 18 a8 04 74
>>EIP; c0125e8c <__invalidate_buffers+38/98> <=
Trace; c01c2685
Trace; c0197d59
Trace; c0187c20
Trace; c0125267
Trace; c01283cc
Trace; c012849f
Trace; c01284b8
Trace; c0109054
Code; c0125e8c <__invalidate_buffers+38/98>
<_EIP>:
Code; c0125e8c <__invalidate_buffers+38/98> <=
0: 8b 6b 1c movl 0x1c(%ebx),%ebp <=
Code; c0125e8f <__invalidate_buffers+3b/98>
3: 66 8b 54 24 16movw 0x16(%esp,1),%dx
Code; c0125e94 <__invalidate_buffers+40/98>
8: 66 39 53 0c cmpw %dx,0xc(%ebx)
Code; c0125e98 <__invalidate_buffers+44/98>
c: 75 3c jne4a <_EIP+0x4a> c0125ed6
<__invalidate_buffers+82/98>
Code; c0125e9a <__invalidate_buffers+46/98>
e: 8b 43 18 movl 0x18(%ebx),%eax
Code; c0125e9d <__invalidate_buffers+49/98>
11: a8 04 testb $0x4,%al
Code; c0125e9f <__invalidate_buffers+4b/98>
13: 74 00 je 15 <_EIP+0x15> c0125ea1
<__invalidate_buffers+4d/98>
Unable to handle kernel NULL pointer dereference at virtual address 001c
current->tss.cr3 = 11dd5000, %cr3 = 11dd5000
*pde =
Oops:
CPU:0
EIP:0010:[]
EFLAGS: 00010202
eax: ebx: ecx: c0201fe8 edx: 1600
esi: 0ea4 edi: ebp: esp: dd373ec8
ds: 0018 es: 0018 ss: 0018
Process mount (pid: 8555, process nr: 40, stackpage=dd373000)
Stack: 1600 08051600 16001600 c01251e8 1600 0001 dffecc20
1600 c01c2146 1600 dffecb60 c0244600 c0187b68 c0197d39
deb26c40 dd373f68 c0244600 deb26c40 c0187bbc deb26c40 dd373f68 c0244600
Call Trace: [] [] [] [] []
[] []
[]
Code: 8b 6b 1c 66 8b 54 24 16 66 39 53 0c 75 3c 8b 43 18 a8 04 74
>>EIP; c0125e8c <__invalidate_buffers+38/98> <=
Trace; c01251e8
Trace; c01c2146
Trace; c0187b68
Trace; c0197d39
Trace; c0187bbc
Trace; c01289ec
Trace; c0187b68
Trace; c0109054
Code; c0125e8c
Re: Cardbus conflicts...
> exclude port 0x2f8-0x2ff This exclusion is to block out the port range used by the IBM MWave DSP chip; this is your modem, not your sound card. Whatever your sound problem is, I don't think it is related to this specific item. I would recommend going to the linux-laptops site and checking out the pages devoted to the IBM TP 600E; it is likely that for a common model like this, people have put together detailed recipies for how to get sound, pcmcia, etc working. As for your specific questions, there are several better ways of handling this sort of thing automatically. If you build the PCMCIA drives with "PnP BIOS support" enabled, they will discover this and any other resource conflicts automatically. I think this option is also available in the newest 2.4.X kernels. PnP BIOS support is not enabled by default because there are compatibility problems on some systems. In the longer term ACPI support should also be able to handle this sort of conflict detection but I don't think it is sufficiently mature at this stage. -- Dave Hinds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 sluggish under fork load
On Mon, 30 Apr 2001, Andrea Arcangeli wrote: > On Sun, Apr 29, 2001 at 10:26:57AM +0200, Peter Osterlund wrote: > > - p->counter = current->counter; > > - current->counter = 0; > > + p->counter = (current->counter + 1) >> 1; > > + current->counter >>= 1; > > + current->policy |= SCHED_YIELD; > > current->need_resched = 1; > > please try to reproduce the bad behaviour with 2.4.4aa2. There's a bug > in the parent-timeslice patch in 2.4 that I fixed while backporting it > to 2.2aa and that I now forward ported the fix to 2.4aa. The fact > 2.4.4 gives the whole timeslice to the child just gives more light to > such bug. The fact that 2.4.4 gives the whole timeslice to the child is just bogus to begin with. The problem people tried to solve was "make sure the kernel runs the child first after a fork", this has just about NOTHING to do with how the timeslice is distributed. Now, since we are in a supposedly stable branch of the kernel, why mess with the timeslice distribution between parent and child? The timeslice distribution that has worked very well for the last YEARS... I agree when people want to fix problems, but I really don't think 2.4 is the time to also "fix" non-problems. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4: USB HC TakeOver failed!
Does anyone has any suggestions on fixing 'USB HC TakeOver failed!' problem. thanks. syslog -- usb.c: registered new driver usbdevfs usb.c: registered new driver hub PCI: Setting latency timer of device 01:04.0 to 64 usb-ohci.c: USB OHCI at membase 0xc8914000, IRQ 8 usb-ohci.c: usb-01:04.0, CMD Technology Inc USB0670 usb-ohci.c: USB HC TakeOver failed! usb.c: USB bus -1 deregistered usb.c: deregistering driver usbdevfs usb.c: deregistering driver hub lspci -vv -s 01:04 -- 01:04.0 USB Controller: CMD Technology Inc USB0670 (rev 06) (prog-if 10 [OHCI]) Subsystem: CMD Technology Inc USB0670 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac1
On Tue, 1 May 2001, Alan Cox wrote: > This release is mostly meant for further eyes to check for merge > errors. It boots but thats about all I'd guarantee. I plan to do just > the fixups for 2.4.4 bugs and then back out some of the existing > changes that don't help much - notably some of the VM tuning isnt > gaining us anything but multiple bad implementations. Later this week I'll have some time to look at the VM things again. I suspect a lot of the code that was merged into the -ac kernels either only helped one specific test case by accident or only works if you think about it from the "right" point of view ;) One thing I've noted with many of the VM patches for 2.4 is that the author goes into great detail describing a VM problem that occurs and then attaches a patch which "fixes" something only losely related to the problem described... ;) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
[EMAIL PROTECTED] (Alexander Viro) wrote on 30.04.01 in <[EMAIL PROTECTED]>: > On Mon, 30 Apr 2001, Eric S. Raymond wrote: > > > I don't think I've heard anyone invoke the 4-line rule since about > > 1992, though. I didn't start generating short random quotes into my sig > > until about 1996, well after the "standard" was effectively dead. > > We hang in different parts of USENET > > Last time I've seen it invoked was probably a couple of weeks ago. I think I see it at least once a week on average. And that's gone *up* from earlier; in my first Usenet days (pre-Deja), I saw much less of it. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] adding PCI bus information to SCSI layer
Jonathan Lundell writes: > On the subject of the Subject, Jeff Garzik recently (21 March) > suggested adding geographic information to the ethtool interface, > pci_dev->slot_name in the case of a PCI-based interface. There's > something to be said for having a uniform method of identifying the > location of devices, or at least a uniform parsable format. (A > potential shortcoming of Jeff's scheme, perhaps, is that it needs to > identify the slot_name as a PCI slot_name, though I could be missing > something there.) > > Consider, instead of /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3 > something like > > /dev/bus/pci0d1f0/scsi0t1l2p3 > or > /dev/bus/pci0:d1:f0/scsi0:t1:l2:p3 Nope. Linus hates the idea of "compressed" names. He wants them to be obvious at first glance. My original devfs patch (before it went into the kernel) had compressed names, and he made me change them (there were other changes as well). I know it's a bit much to type in, but he's probably right. If people need it, I can add compressed names to devfsd, just like I did to preserve the names in the original devfs patch. > A related idea would be the ability to translate from a logical PCI > slot number, as above, and a physically meaningful description that > the user could use to identify an actual slot. Unfortunately the > proper place for such a translation function is in the > (hardware-specific) BIOS. Nope. It's cleaner to do this in a vendor-specific "fixup" layer. Alan asked me a similar question privately, so I've included my reponse to his email (quoting bits of his email for context) below. In his reply, Alan said "it makes sense". I take that as a good omen. = > How do you intend to handle pci busses that are below other busses - eg gsc > /dev/bus/gsc/bus/pci0/ .. ? > Im just thinking it gets very cumbersome. It could. And if you play with the upcoming SGI IA-64 boxes, where they have a deep /dev/hw, it would appear even more so. However, I came up with a scheme while I was visiting them after the workshop, which I believe will handle an arbitrarily complex vendor tree. I'm actually quite proud of this idea :-) The basic idea is that /dev/bus contains a *logical* enumeration of all busses in the system. This contains the generic Linux view of busses. We already have this enumeration within struct pci_dev and friends. Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0 into symlinks to something like /dev/hw/PBrick/00AA3415/bus1/pci3 (or similar, I forget just how deep SGI's tree went). This scheme is really just an extension of the approach Linus took in the Great Name Change he forced upon me a year and a half ago. Back then, he wanted /dev/discs to answer the question "what discs do I have", and "/dev/scsi" to answer "what SCSI devices do I have, and what's the layout". So now, I'm adding "/dev/bus" for "what logical busses do I have" and "/dev/hw" for "what is the exact hardware topology". Where we have "generic" hardware (i.e. a vendor doesn't provide their own PCI fixups), and there is a need to show the bus topology, we can write generic fixups that parse the struct pci_dev and friends. For example, most x86 machines would fall in this "generic" category. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] yet another knfsd-reiserfs patch
On Monday, April 23, 2001 10:45:14 AM -0400 Chris Mason <[EMAIL PROTECTED]> wrote:
>
> Hi guys,
>
> This patch is not meant to replace Neil Brown's knfsd ops stuff, the
> goal was to whip up something that had a chance of getting into 2.4.x,
> and that might be usable by the AFS guys too. Neil's patch tries to
> address a bunch of things that I didn't, and looks better for the
> long run.
>
Ok, here it is updated to 2.4.4. The only change was to adapt to the usage
of comp_short_keys in reiserfs_iget under 2.4.4.
-chris
diff -Nru a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
--- a/fs/nfsd/nfsfh.c Sun Apr 29 18:01:04 2001
+++ b/fs/nfsd/nfsfh.c Sun Apr 29 18:01:04 2001
@@ -116,40 +116,12 @@
return error;
}
-/* this should be provided by each filesystem in an nfsd_operations interface as
- * iget isn't really the right interface
- */
-static struct dentry *nfsd_iget(struct super_block *sb, unsigned long ino, __u32
generation)
+static struct dentry *dentry_from_inode(struct inode *inode)
{
-
- /* iget isn't really right if the inode is currently unallocated!!
-* This should really all be done inside each filesystem
-*
-* ext2fs' read_inode has been strengthed to return a bad_inode if the inode
-* had been deleted.
-*
-* Currently we don't know the generation for parent directory, so a generation
-* of 0 means "accept any"
-*/
- struct inode *inode;
struct list_head *lp;
struct dentry *result;
- inode = iget(sb, ino);
- if (is_bad_inode(inode)
- || (generation && inode->i_generation != generation)
- ) {
- /* we didn't find the right inode.. */
- dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
- inode->i_ino,
- inode->i_nlink, atomic_read(>i_count),
- inode->i_generation,
- generation);
-
- iput(inode);
- return ERR_PTR(-ESTALE);
- }
- /* now to find a dentry.
-* If possible, get a well-connected one
+ /*
+* If possible, get a well-connected dentry
*/
spin_lock(_lock);
for (lp = inode->i_dentry.next; lp != >i_dentry ; lp=lp->next) {
@@ -172,6 +144,92 @@
return result;
}
+static struct inode *__inode_from_fh(struct super_block *sb, int ino,
+int generation)
+{
+ struct inode *inode ;
+
+ inode = iget(sb, ino);
+ if (is_bad_inode(inode)
+ || (generation && inode->i_generation != generation)
+ ) {
+ /* we didn't find the right inode.. */
+ dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
+ inode->i_ino,
+ inode->i_nlink, atomic_read(>i_count),
+ inode->i_generation,
+ generation);
+
+ iput(inode);
+ return ERR_PTR(-ESTALE);
+ }
+ return inode ;
+}
+
+static struct inode *inode_from_fh(struct super_block *sb,
+ __u32 *datap,
+ int len)
+{
+ if (sb->s_op->inode_from_fh)
+ return sb->s_op->inode_from_fh(sb, datap, len) ;
+ return __inode_from_fh(sb, datap[0], datap[1]) ;
+}
+
+static struct inode *parent_from_fh(struct super_block *sb,
+ __u32 *datap,
+ int len)
+{
+ if (sb->s_op->parent_from_fh)
+ return sb->s_op->parent_from_fh(sb, datap, len) ;
+
+ if (len >= 3)
+ return __inode_from_fh(sb, datap[2], 0) ;
+ return ERR_PTR(-ESTALE);
+}
+
+/*
+ * two iget funcs, one for inode, and one for parent directory
+ *
+ * this should be provided by each filesystem in an nfsd_operations interface as
+ * iget isn't really the right interface
+ *
+ * If the filesystem doesn't provide funcs to get inodes from datap,
+ * it must be: inum, generation, dir inum. Length of 2 means the
+ * dir inum isn't there.
+ *
+ * iget isn't really right if the inode is currently unallocated!!
+ * This should really all be done inside each filesystem
+ *
+ * ext2fs' read_inode has been strengthed to return a bad_inode if the inode
+ * had been deleted.
+ *
+ * Currently we don't know the generation for parent directory, so a generation
+ * of 0 means "accept any"
+ */
+static struct dentry *nfsd_iget(struct super_block *sb, __u32 *datap, int len)
+{
+
+ struct inode *inode;
+
+ inode = inode_from_fh(sb, datap, len) ;
+ if (IS_ERR(inode)) {
+ return ERR_PTR(PTR_ERR(inode)) ;
+ }
+ return dentry_from_inode(inode) ;
+}
+
+static struct dentry *nfsd_parent_iget(struct super_block *sb, __u32 *datap,
+
DPT I2O RAID and Linux I2O
A few people have asked about the dpt_i2o driver recently. If you have a DPT I2O card please try a late 2.4.3-ac kernel. It should now work when you do 'modprobe i2o_scsi' After a lot of reviewing of the dpt driver I figured out what command was upsetting the beast and added a workaround for it. I also fixed a pile of bugs in the drivers that caused failed table queries to corrupt memory in some cases (the DPT tended to trigger these and so made the box reboot if you used i2oproc or i2oconfig. I'd also like to say thanks to DPT (now Adaptec) for supplying me with a card which meant that in combination with their driver I was eventually able to figure out the cure. More feedback from DPT i2o raid card users would be useful Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel Debuggers, KDB or KGDB?
On Mon, 30 Apr 2001 16:17:22 -0500, Paul J Albrecht <[EMAIL PROTECTED]> wrote: >Where can I find an analysis of the relative strengths and weaknesses of KDB >and KGDB for kernel debug? Has the linux community come to any consensus >regarding the utility one or the other? kdb is a really low level debugger which understands the kernel structures. It does its utmost to stop all kernel activity while it is running and to use as few kernel services as possible so it can run even when the kernel is dead. It (currently) has no source level debugging. kgdb relies on gdb so you loose the knowledge of kernel internals (no, I am *not* going to teach gdb about kernel stacks, out of line lock code etc.). kgdb has more of a dependency on a working kernel. It provides source level debugging, although stack backtrace tends not to work unless you compile the kernel with frame pointers. UML is great for debugging generic kernel code such as filesystems, but cannot be used for most arch code or hardware drivers. My ideal debugger is one that combines the internal knowledge of kdb with the source level debugging of gdb. I know how to do this over a serial line, finding time to write the code is the problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 locks up on SMP
On Mon, 30 Apr 2001, Mohammad A. Haque wrote: > Just to give another data point... > > 2.2.19 + LVM patches - dual P3 550 > 1 GB RAM > eepro100 > ncr53c8xx scsi > mylex accelRAID 1100 RAID controller > > We've transferred around 1 GB of stuff over the network and about 200 GB > between two raids w/o problems in a little under 3 days. > > We've only scratched into swap. Free show 128K being used. Ok. Have you tried running a large bonnie (1GB) while at the same time pummeling the network? That's how I trigger it, quite reliably. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+lndir problem [was: 2.4.4 SMP: spurious EOVERFLOW"Value too large for defined data type"]
On Monday, April 30, 2001 10:55:57 PM +0200 Daniel Elstner <[EMAIL PROTECTED]> wrote: > Hi all, > > unfortunately I have to correct me again. > The problem seems unrelated to the kernel version or SMP/UP > (though only 2.4.[34] tried yet). > > Apparently it's a reiserfs/symlink problem. > I tried doing the lndir on an ext2 partition, sources still > on reiserfs. And it worked just fine! Neat, thanks for the extra details. Does that mean you can consistently repeat on reiserfs now? What happens when you do the lndir on reiserfs and diff the directories? Any useful messages in /var/log/messages? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
On Mon, 30 Apr 2001 18:10:56 -0400, "Michael H. Warfield" <[EMAIL PROTECTED]> wrote: >On Mon, Apr 30, 2001 at 01:22:59PM -0700, Francois Gouget wrote: >> Apr 30 13:19:34 oleron cardmgr[148]: initializing socket 0 >> Apr 30 13:19:34 oleron cardmgr[148]: socket 0: Aironet PC4800 >> Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_core' >> Apr 30 13:19:34 oleron cardmgr[148]: + Warning: >/lib/modules/2.4.4/kernel/drivers/net/aironet4500_core.o >> symbol for parameter rx_queue_len not found Bug in drivers/net/aironet4500_core.c. It has MODULE_PARM(rx_queue_len,"i"); but rx_queue_len is never defined. Only a warning. >> Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_proc' >> Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_cs' >> Apr 30 13:19:35 oleron cardmgr[148]: get dev info on socket 0 >> failed: Resource temporarily unavailable Separate problem, the aironet4500_cs driver could not get its resources. > Seen this before. What version are your modutils at? Latest are >2.4.5 on kernel.org and there have been several times where I've had >them slip out of rev and ended up with missing symbols. The version of modutils does not affect missing symbols, it just reports kernel bugs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.4-ac1
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org This release is mostly meant for further eyes to check for merge errors. It boots but thats about all I'd guarantee. I plan to do just the fixups for 2.4.4 bugs and then back out some of the existing changes that don't help much - notably some of the VM tuning isnt gaining us anything but multiple bad implementations. 2.4.4-ac1 o Merge with Linus 2.4.4 | This wasnt entirely trivial so this is the only | stuff in this patch | The following stuff has been switched to the Linus branch | in the merge: uhci, dcache atomicity, raw I/O 2.4.3-ac14 o Merge read-only vxfs reading support(Christoph Hellwig) o Fix missing return in broken_apm_power (Alex Riesen) o Remove bogus rwsem hacks from usbdevice_fs.h(Alex Riesen) o Fix umount/sync_inodes race (Al Viro) o Make new xircom driver report when promisc used (Arjan van de Ven) o Fix acenic PCI flag set up (Phil Copeland) o Make nfs smart about passing max file sizes (Trond Myklebust) o Add initrd support to User Mode Linux (Jeff Dike) o Fix timer irq race in User Mode Linux (Jeff Dike) o Fix UML for semaphore changes (Jeff Dike) o Update thw W9966 parallel port camera driver(Jakob Kemi) o Further dmfe SMP fixups (Tobias Ringstrom) o Kernel manual pages in man9 (Tim Waugh) o Work around BIOSes that implement E801 sizing but don't implement the CX/DX values part (Michael Miller) o Fix atp driver build(Arjan van de Ven) o Fix irda poll handling (Dag Brattli) o Remove unused buggy pdc202xx code (Arjan van de Ven) o Clean up iphase ATM (Arnaldo Carvalho de Melo) o Setup slave PDC20265 controller on fasttrak (Arjan van de Ven) as normal IDE o Add __init/__initdata to most net driver (Andrzej Krzysztofowicz) version info o SDDR09 config entry was missing (Phil Stracchino) o Configure.help NFS updates (Andrzej Krzysztofowicz) o Netfilter updates (Rusty Russell and co) o Update 2.4 ipconfig to support dhcp (Eric Biederman) o es1371 setup updates/error check/pci bits (Marcus Meissner) o Fix buzzing ymfpci (Nick Brown) o Update nm256 audio driver (Marcus Meissner) o Blacklist updates (Arjan van de Ven) 2.4.3-ac13 o Switch to NOVERS symbols for rwsem (me) | Called from asm blocks so they can't be versioned o Fix gcc 2.95 building on rwsem (Niels Jensen) o Fix cmsfs build (Andrzej Krzysztofowicz) o Fix rio build/HZ setup (Andrzej Krzysztofowicz) o Fix PPP filtering dependancy in config (Andrzej Krzysztofowicz) 2.4.3-ac12 o Rewrite the i2o post handling code to fix (me) DMA memory scribbles o Handle IOP constipation in the i2o_block layer (me) o Fix bugs in the i2o table query causing reboots (me) in i2o_proc on the DPT card o Add quirks for i2o cards that handle large I/O (me) queues badly [Promise supertrak100] o Add cache heuristics to the I2O block driver(me) | We don't cache large writes (assume seq) | We writeback small writes (random, metadata) o Disable use of writeback caching if there is(me) no battery backup o Merge Linus 2.4.4pre6 o Further semaphore fixes (David Howells) o Correct 'void main' to 'int main' in rtc doc(Jesper Juhl) o Hopefully fix bugtraq reported netfilter ftp flaw o Fix unistd.h for ARM(Russell King) o Fix pre-emption of rt tasks (Nigel Gamble) o Fix revalidation bugs in cciss/cpqarray (Charles White) when rereading partitions o Acenic updates (Jes Sorensen) o Fix MAINTAINERS sort order (David Woodhouse) o Restore DVDRAM fix with cdrom init fix too (Jens Axboe) o Fix irda disconnect timeout bug (Dag Brattli) o Experimentally reap dead swap harder(Dave Miller) o Remove dead low mtu checks from drivers (Arnaldo Carvalho de Melo) o
Re: Can eject mounted zip disk after suspend/resume (2.4.4)
> If I hit an eject button on internal IDE IOMEGA zip drive after > resume/suspend to memory on my Dell Inspiron 7500 notebook, then the > disk will be ejected even if it is mounted. This behavior happens ONLY > if I suspend my system with the mounted zip. Could I fix this somehow? Its an Inspiron bios bug - they fail to preserve the locked stat of the zip drive across a suspend. Its not the worst bug in the world. In theory the scsi/ide layer could use a PM notifier to check the locked stat is right and force the drive into the right state. I'd take patches for it but lets say its not high on my 'urgent problem' list - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can eject mounted zip disk after suspend/resume (2.4.4)
If I hit an eject button on internal IDE IOMEGA zip drive after resume/suspend to memory on my Dell Inspiron 7500 notebook, then the disk will be ejected even if it is mounted. This behavior happens ONLY if I suspend my system with the mounted zip. Could I fix this somehow? I tried to use both ide-floppy and ide-scsi drivers to access the disk with no difference. My settings for 2.4.4 kernel APM options are CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_RTC_IS_GMT=y # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set Regards, Igor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 doesn't like my .config
Hey, Just gave CLM2 (1.3.3) a go with linux-2.4.3-ac14 Results: ISA=y (deduced from X86) This configuration violates the following constraints: '((NET_PCMCIA <= PCMCIA) and (NET_PCMCIA <= NET_ETHERNET))' erm... OK. Relevant bits of .config # egrep CONFIG_PCMCIA\|NET_PCMCIA\|NET_ETHERNET .config CONFIG_PCMCIA=y # CONFIG_NET_ETHERNET is not set CONFIG_NET_PCMCIA=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set # CONFIG_PCMCIA_PCNET is not set # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set CONFIG_PCMCIA_XIRC2PS=m # CONFIG_PCMCIA_IBMTR is not set # CONFIG_NET_PCMCIA_RADIO is not set # CONFIG_PCMCIA_SERIAL_CS is not set Is this really a problem ??? I gather its saying "you have support for a pcmcia network card, but not for pcmcia" (which i do) ... and "you have support for a pcmcia network card, but not for ethernet (quite true). This .config has worked fine for me for countless kernels. Do i _really_ need to manually put in ethernet support ... I just assumed that didn't cover pcmcia, as it has its own section in the network device screen. More .config available on request. Machine is a Toshiba 100CS lappy. No PCI bus, and a xircom ceIIps pcmcia 10baseT card. thanks, / Brett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 maintainer?
> Is there someone who considers himself maintainer of the iso9660 > filesystem these days? Not me. But recently and not so recently I fixed some stuff in that area. If you have problems I am certainly willing to look at them. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oopses under 2.4.4pre8 with Tbird 1.2GHz/Epox 8kta3
> > This problem is only seen on VIA chipsets so far. Never on AMD ones. > > This leads me to the current tentative diagnosis of 'VIA chipset bug' > > Thanks, at least that clears up some of the mystery. Do you foresee any > problems with running on this setup using a kernel compiled for Athlon but > with the 3DNOW line commented out in arch/i386/config.in? Should I go one The VIA PCI bugs should be properly worked around in 2.4.3+ so it should be ok > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
> Elmer Joandi wrote: > > the whole pcmcia does not work in 2.4. > > Prove it. > It works for people with correct 2.4 kernel configurations. Except on a few boxes where it doesnt. The Palmax is one of them but that seems to be irq routing - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001 01:31:20 +0200, "J . A . Magallon" <[EMAIL PROTECTED]> wrote: >On 05.01 Keith Owens wrote: >> The patch appears to work but is it worth applying now? The existing >> 2.4 rules work fine and the entire kbuild system will be rewritten for >> 2.5 > >We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. >2.4 will be the stable and non "brain damaged" kernel in distros. >So every thing that can make 2.4 more clean, better. Think in 2.4.57, >and we still are in 4. And feature backports, and new drivers... >The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. But 2.4 kbuild for multi part objects already works, there is no bug to fix or live with. 2.4 is supposed to be bug fixes only. IMHO keeping the existing boilerplate method for multi part objects in 2.4 is the safer approach, don't rock the boat. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On 05.01 Keith Owens wrote: > > The patch appears to work but is it worth applying now? The existing > 2.4 rules work fine and the entire kbuild system will be rewritten for > 2.5, including the case you identified here. It struck me as a decent > change but for no benefit and, given that the 2.4 kbuild system is so > fragile, why not live with something we know works until 2.5 is > available? > We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable. 2.4 will be the stable and non "brain damaged" kernel in distros. So every thing that can make 2.4 more clean, better. Think in 2.4.57, and we still are in 4. And feature backports, and new drivers... The 2.5 rewrite is not excuse. The knowledge on the actual state, yes. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.4 #1 SMP Sat Apr 28 11:45:02 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x APM interferes with FA311TX/natsemi.o
> When the call > apm_bios_call_simple(APM_FUNC_SET_STATE, 0x100, APM_STATE_READY, ) > is made, the PMEEN (PME enable) bit in the CCSR register on my FA311 > mysteriously changes from 0 to 1, causing the card to stop processing The Linux driver set the power management of the card off. The BIOS then rudely fiddled with it. If its not a laptop seriously consider just turning off APM support. The Linux idle loop halts will do a fair job of power saving anyway - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] linux likes to kill bad inodes
On Mon, 30 Apr 2001, Alan Cox wrote: > > Any reason a bad inode can't have its i_sb changed to a bad_inode_fs ? That would be my personal preference too, this was just the quick hack version. Changing superblocks might have other consequences (like getting the superblock inode lists right etc). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 breaks dhcpcd with Realtek 8139
Garett Spencley <[EMAIL PROTECTED]> writes: > On Sat, 28 Apr 2001, Michael F Gordon wrote: > > > dhcpcd stops working if I install 2.4.4. Replacing the 2.4.4 version of > > 8139too.c with the 2.4.3 version and leaving everything else exactly > > the same gets things working again. Configuring the interface by hand > > after dhcpcd has timed out also works. Has anyone else seen this? > > I noticed this in 2.4.3-acX series as well. But here's the funny part: > When dhcp starts up during bootup it doesn't work. But as > soon as I log in and do a su -c '/etc/rc.d/init.d/network restart' there's > instant success! > > This is on Mandrake 8.0 > > It doesn't make much sense to me. you may want to report the bug at : https://qa.mandrakesoft.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel Debuggers, KDB or KGDB?
[EMAIL PROTECTED] said: > Where can I find an analysis of the relative strengths and weaknesses > of KDB and KGDB for kernel debug? Has the linux community come to any > consensus regarding the utility one or the other? You ought to add UML to the list, since it is useful for debugging any part of the kernel that's not arch code or a hardware device driver (except that there's now USB support for UML). Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)
On Tue, 1 May 2001 00:43:42 +0200 (CEST), Kai Germaschewski <[EMAIL PROTECTED]> wrote: >I sent this to the kbuild list about a week ago, and I received exactly >zero replies, so I'm posting to l-k now. This may mean that the idea is >totally stupid (but I'd like to know) or unquestionably good (that's what >I'd prefer :), well, maybe I'll get some feedback this time. The patch appears to work but is it worth applying now? The existing 2.4 rules work fine and the entire kbuild system will be rewritten for 2.5, including the case you identified here. It struck me as a decent change but for no benefit and, given that the 2.4 kbuild system is so fragile, why not live with something we know works until 2.5 is available? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] automatic multi-part link rules (fwd)
I sent this to the kbuild list about a week ago, and I received exactly
zero replies, so I'm posting to l-k now. This may mean that the idea is
totally stupid (but I'd like to know) or unquestionably good (that's what
I'd prefer :), well, maybe I'll get some feedback this time.
SHORT VERSION:
The attached patch allows to get rid of the "list-multi := ..." lines and
link-rules for multi-part objects in all the Makefiles without breaking
any current Makefile.
-- Forwarded message --
Date: Tue, 24 Apr 2001 15:05:07 +0200 (CEST)
From: Kai Germaschewski <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [kbuild-devel] [PATCH] automatic multi-part link rules
Hi!
I'd like to get some comments on the appended patch. It removes the need
to put explicit link rules for multi-part objects in the individual
Makefiles in the subdirectores and leaves them to Rules.make instead.
I know that 2.5 kbuild will look entirely differently, but I consider this
patch useful for 2.4 as well, it's a cleanup which IMO can be applied
(after checking) to a stable kernel. (BTW: I have a lot of comments and
some code for kbuild-2.5 as well, but later).
To guarantee a smooth transition, the patch to Rules.make doesn't change
current behavior, at least with correct Makefiles. Today, a Makefile which
may build multi-part modules looks like the following:
list-multi := foo.o
foo-objs := foo_bar1.o foo_bar2.o
obj-$(CONFIG_FOO) += foo.o
include $(TOPDIR)/Rules.make
foo.o: $(foo-objs)
$(LD) -r -o $@ $(foo-objs)
The patch ensures that for multi-part objects, which are listed in
list-multi, no automatic link rules is generated, so nothing changes
there. However, you now can remove the list-multi line and the link rule,
foo-objs := foo_bar1.o foo_bar2.o
obj-$(CONFIG_FOO) += foo.o
include $(TOPDIR)/Rules.make
and everything will still work. Actually, there is one further advantage,
i.e. the link rule is subject to the usual flags handling now. That means
that we'll recognize when the command line changes and relink the
composite module, even if the individual parts were not touched.
There is also one minor drawback, due to make limitations: Even if only
one of the composite modules in a given directory needs to be rebuilt
(because e.g. one of its sources were touched), all the others get
relinked as well. That's not much of a problem, though, since linking is
really fast, as compared to compiling.
The patch shows the needed Rules.make adaption and demonstrates the
achievable cleanup in drivers/isdn/{,*/}Makefile. It works fine here.
--Kai
Index: linux_2_4/Rules.make
diff -u linux_2_4/Rules.make:1.1.1.4 linux_2_4/Rules.make:1.1.1.4.2.1
--- linux_2_4/Rules.make:1.1.1.4Sat Apr 28 18:17:43 2001
+++ linux_2_4/Rules.makeTue May 1 00:39:40 2001
@@ -118,6 +118,24 @@
) > $(dir $@)/.$(notdir $@).flags
endif
+#
+# Rule to link composite objects
+#
+
+# for make >= 3.78 the following is cleaner:
+# multi-used := $(foreach m,$(obj-y) $(obj-m), $(if $($(basename $(m))-objs), $(m)))
+multi-used := $(sort $(foreach m,$(obj-y) $(obj-m),$(patsubst %,$(m),$($(basename
+$(m))-objs
+ld-multi-used := $(filter-out $(list-multi),$(multi-used))
+ld-multi-objs := $(foreach m, $(ld-multi-used), $($(basename $(m))-objs))
+
+$(ld-multi-used) : %.o: $(ld-multi-objs)
+ rm -f $@
+ $(LD) $(EXTRA_LDFLAGS) -r -o $@ $(filter $($(basename $@)-objs), $^)
+ @ ( \
+ echo 'ifeq ($(strip $(subst $(comma),:,$(LD) $(EXTRA_LDFLAGS) $($(basename
+$@)-objs)),$$(strip $$(subst $$(comma),:,$$(LD) $$(EXTRA_LDFLAGS) $$($(basename
+$@)-objs)' ; \
+ echo 'FILES_FLAGS_UP_TO_DATE += $@' ; \
+ echo 'endif' \
+ ) > $(dir $@)/.$(notdir $@).flags
#
# This make dependencies quickly
@@ -198,8 +216,7 @@
#
ifdef CONFIG_MODULES
-multi-used := $(filter $(list-multi), $(obj-y) $(obj-m))
-multi-objs := $(foreach m, $(multi-used), $($(basename $(m))-objs))
+multi-objs := $(foreach m, $(obj-y) $(obj-m), $($(basename $(m))-objs))
active-objs:= $(sort $(multi-objs) $(obj-y) $(obj-m))
ifdef CONFIG_MODVERSIONS
Index: linux_2_4/drivers/isdn/Makefile
diff -u linux_2_4/drivers/isdn/Makefile:1.1.1.2
linux_2_4/drivers/isdn/Makefile:1.1.1.2.24.1
--- linux_2_4/drivers/isdn/Makefile:1.1.1.2 Tue Apr 24 00:50:53 2001
+++ linux_2_4/drivers/isdn/Makefile Tue May 1 00:39:58 2001
@@ -10,7 +10,6 @@
# Multipart objects.
-list-multi := isdn.o
isdn-objs := isdn_net.o isdn_tty.o isdn_v110.o isdn_common.o
# Optional parts of multipart objects.
@@ -49,8 +48,3 @@
# The global Rules.make.
include $(TOPDIR)/Rules.make
-
-# Link rules for multi-part drivers.
-
-isdn.o: $(isdn-objs)
- $(LD) -r -o $@ $(isdn-objs)
Index: linux_2_4/drivers/isdn/act2000/Makefile
diff -u linux_2_4/drivers/isdn/act2000/Makefile:1.1.1.1
linux_2_4/drivers/isdn/act2000/Makefile:1.1.1.1.28.1
---
Re: SCSI-Multipath driver for 2.4?
> I wondered whether thera are already effrots to por the Multipath-driver > for FibreChannel (http://t3.linuxcare.org) to the 2.4 kernel? This patch > allows a transparent failover to another path to FC-attached > disk in case the primary path fails. Please dont put the multipathing in the scsi layer. Its not uncommon to have raid controllers or other smart devices as the primary FC connection and a dumb scsi layer device as slave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: USB/Reboot
> I'm not familiar with that option, where would I be setting it? Or even
> better, where is it documented?
Documentation/kernel-parameters.txt
and arch/i386/kernel/boot.c
switch (*str) {
case 'w': /* "warm" reboot (no memory testing etc) */
reboot_mode = 0x1234;
break;
case 'c': /* "cold" reboot (with memory testing etc) */
reboot_mode = 0x0;
break;
case 'b': /* "bios" reboot by jumping through the BIOS */
reboot_thru_bios = 1;
break;
case 'h': /* "hard" reboot by toggling RESET and/or crashing th
reboot_thru_bios = 0;
break;
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] compilation warning fixes
Newer gcc's (particularly the RH 7.0/7.1 2.96 versions) complain about implicit declaration of the function abs, and AFAICS they're right. What do people think about the appended patch to fix this? (There's more users than just isdn_audio.c, that's why I added a common header file). --Kai Index: linux_2_4/drivers/isdn/isdn_audio.c diff -u linux_2_4/drivers/isdn/isdn_audio.c:1.1.1.1 linux_2_4/drivers/isdn/isdn_audio.c:1.1.1.1.26.1 --- linux_2_4/drivers/isdn/isdn_audio.c:1.1.1.1 Tue Apr 24 00:13:47 2001 +++ linux_2_4/drivers/isdn/isdn_audio.c Mon Apr 30 21:42:11 2001 @@ -25,6 +25,7 @@ #define __NO_VERSION__ #include #include +#include #include "isdn_audio.h" #include "isdn_common.h" Index: linux_2_4/include/linux/stdlib.h diff -u /dev/null linux_2_4/include/linux/stdlib.h:1.1.4.3 --- /dev/null Mon Apr 30 23:28:11 2001 +++ linux_2_4/include/linux/stdlib.hMon Apr 30 23:27:46 2001 @@ -0,0 +1,6 @@ +#ifndef __STDLIB_H__ +#define __STDLIB_H__ + +extern int abs (int i); + +#endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] linux likes to kill bad inodes
Alan Cox writes: > Any reason a bad inode can't have its i_sb changed to a bad_inode_fs ? I believe this is what Linus suggested. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] linux likes to kill bad inodes
> {
> - if (inode->i_sb && inode->i_sb->s_op && inode->i_sb->s_op->write_inode)
> + if (inode->i_sb && inode->i_sb->s_op && inode->i_sb->s_op->write_inode &&
>!is_bad_inode(inode))
> inode->i_sb->s_op->write_inode(inode, sync);
> }
Any reason a bad inode can't have its i_sb changed to a bad_inode_fs ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: where can I find the IP address ?
> pa_addr in the struct device. but it doesn't exist on my computer. > > so I don't understand why ? Is anybody could tell me where finding the > IP address in the kernel ? A driver may not even have an IP address and it may change dynamically. One side effect of this (and support for multiple addresses per node) is that the addresses are now a chain attached to the device struct. You might find [EMAIL PROTECTED] a much better place to ask Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: buz.c of 2.4.4
> > Come to think of it .. then we'd start getting "buz drivers missing" > > reports. > > So what? > Refer them to [EMAIL PROTECTED] and we'll explain them how > to use the new zoran driver until it's in the official kernel... #warning "outdated, see http://whatever for current devel versions" Gerd -- Man muß die Software wacker hüten weil in der Welt die Hacker wüten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux Kernel Debuggers, KDB or KGDB?
Where can I find an analysis of the relative strengths and weaknesses of KDB and KGDB for kernel debug? Has the linux community come to any consensus regarding the utility one or the other? -- Paul J Albrecht [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
On Mon, 30 Apr 2001, Michael H. Warfield wrote: [...] > >But now I get the same missing symbols I initially had in 2.4.3: > > > Apr 30 13:19:34 oleron cardmgr[148]: initializing socket 0 > > Apr 30 13:19:34 oleron cardmgr[148]: socket 0: Aironet PC4800 > > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_core' > > Apr 30 13:19:34 oleron cardmgr[148]: + Warning: >/lib/modules/2.4.4/kernel/drivers/net/aironet4500_core.o > > symbol for parameter rx_queue_len not found > > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_proc' > > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_cs' > > Apr 30 13:19:35 oleron cardmgr[148]: get dev info on socket 0 > > failed: Resource temporarily unavailable > > Seen this before. What version are your modutils at? Latest are > 2.4.5 on kernel.org and there have been several times where I've had > them slip out of rev and ended up with missing symbols. Here I have modutils 2.4.2. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
Hello, I'm tunning into this discussion a little late, but... On Mon, Apr 30, 2001 at 01:22:59PM -0700, Francois Gouget wrote: > On Mon, 30 Apr 2001, Jeff Garzik wrote: > > Francois Gouget wrote: > > > CONFIG_PCMCIA=y > > > CONFIG_CARDBUS=y > > > CONFIG_I82365=y > > > > Not correct -- you do not need I82365 if you have CardBus. However, if > > you are running 2.4.4 you should be ok. >Ok. I upgraded to 2.4.4 and modified my config file to be: > CONFIG_PCMCIA=y > CONFIG_CARDBUS=y > # CONFIG_I82365 is not set >But now I get the same missing symbols I initially had in 2.4.3: > Apr 30 13:19:34 oleron cardmgr[148]: initializing socket 0 > Apr 30 13:19:34 oleron cardmgr[148]: socket 0: Aironet PC4800 > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_core' > Apr 30 13:19:34 oleron cardmgr[148]: + Warning: >/lib/modules/2.4.4/kernel/drivers/net/aironet4500_core.o > symbol for parameter rx_queue_len not found > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_proc' > Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_cs' > Apr 30 13:19:35 oleron cardmgr[148]: get dev info on socket 0 > failed: Resource temporarily unavailable Seen this before. What version are your modutils at? Latest are 2.4.5 on kernel.org and there have been several times where I've had them slip out of rev and ended up with missing symbols. > -- > Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ > 1 + e ^ ( i * pi ) = 0 Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch(?): bash-2.05/jobs.c loses interrupts
>> Linux-2.4.4 has a change, for which I must accept blame, >> where fork() runs the child first, reducing unnecessary copy-on-write >> page duplications, because the child will usually promptly do an >> exec(). I understand this is pretty standard in most unixes. >> >> Peter Osterlund noticed an annoying side effect of this, >> which I think is a bash bug. He wrote: >> >> > Another thing is that the bash loop "while true ; do /bin/true ; done" is >> > not possible to interrupt with ctrl-c. >> >> I have reproduced this problem on a single CPU system. >> I also modified my kernel to sometimes run the fork child first >> and sometimes not. In that case, that loop would sometimes >> abort on a control-C and sometimes ignore it, but ignoring it >> would not make the loop less likely to abort on another control-C. >> I'm pretty sure the control-C was being delivered only to the child >> due to a race condition in bash, which may be mandated by posix. >Did you reconfigure and rebuild bash on your machine running the 2.4 >kernel, or just use a bash binary built on a previous kernel version? >Bash has an autoconf test that will, if it detects the need to do so, >force the job control code to synchronize between parent and child >when setting up the process group for a new pipeline. It may be the >case that you have to reconfigure and rebuild bash to enable that code. >Look for PGRP_PIPE in config.h. Rebuilding bash from pristine 2.05 sources under such a kernel does *not* solve the problem. PGRP_PIPE is undef'ed in the resulting config.h. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 sluggish under fork load
On Mon, 30 Apr 2001, Andrea Arcangeli wrote: > please try to reproduce the bad behaviour with 2.4.4aa2. There's a bug > in the parent-timeslice patch in 2.4 that I fixed while backporting it > to 2.2aa and that I now forward ported the fix to 2.4aa. The fact > 2.4.4 gives the whole timeslice to the child just gives more light to > such bug. Unfortunately the fix doesn't apply cleanly to 2.4.4 (it's > incremental with the numa-scheduler patch) and I need to finish a few > more things before I can backport it myself. I applied the 10_parent-timeslice-5 patch to 2.4.4 and tested. (If I understood correctly, the idea of that patch is to give the remaining child time-slice back to the parent when the child exits, but only if there have been no time-slice recalculation since the child was created.) It is somewhat better than plain 2.4.4, but not much. I still see scheduling delays in the range 30-120ms when running "./fork 0.4". (fork is a program that starts a child, the child busy waits some time (0.4s) and then exits. The parent then immediately respawns another child, etc. See one of my previous messages.) -- Peter Österlund [EMAIL PROTECTED] Sköndalsvägen 35http://home1.swipnet.se/~w-15919 S-128 66 Sköndal+46 8 942647 Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X15 alpha release: as fast as TUX but in user space
dean gaudet writes: > On Sun, 29 Apr 2001, David S. Miller wrote: > > > If you do the TCP_CORK thing, what you end up with is a scatter gather > > entry in the SKB for the header bits, then the page cache segments. > > so then the NIC would be sent a 3 entry gather list -- 1 entry for TCP/IP > headers, 1 for HTTP headers, and 1 for the initial page cache segment? Basically. It's weird because we could change tcp_sendmsg() to grab a "little bit" of space in skb->data after the TCP headers area, but that would screw all the memory allocation advantages carving up pages gives us. TCP used to be really rough on the memory subsystem, and in particular going to a page carving scheme helped a lot in this area. > are there any NICs which take only 2 entry lists? (boo hiss and curses > on such things if they exist!) Tulip I think falls into this category, I could be wrong. It has two buffer pointers in the RX descriptor, but one might be able to chain them. Alexey added SG support to Tulip at some point, and I can probably dig up the patch. It doesn't do hw csumming, though. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X15 alpha release: as fast as TUX but in user space
On Mon, 30 Apr 2001, Fabio Riccardi wrote: > Ok I fixed it, the header date timestamp is updated with every request. > > Performance doesn't seem to have suffered significantly (less than 1%). rad! > BTW: Don't call me slime, I wasn't trying to cheat, I just didn't know that > the date stamp was required to be really up-to-date. sorry, i meant to put a smily on there :) On Sun, 29 Apr 2001, David S. Miller wrote: > If you do the TCP_CORK thing, what you end up with is a scatter gather > entry in the SKB for the header bits, then the page cache segments. so then the NIC would be sent a 3 entry gather list -- 1 entry for TCP/IP headers, 1 for HTTP headers, and 1 for the initial page cache segment? are there any NICs which take only 2 entry lists? (boo hiss and curses on such things if they exist!) -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and 2GB swap partition limit
Hi, On Mon, Apr 30, 2001 at 03:14:25PM -0400, Richard B. Johnson wrote: > > mv /wherever/exeimage /usr/bin/exeimage [...] > > This is also basically how things like libc get installed. > > A single mv is not only preserves currently referenced contents, > > it is atomic. One restriction: /wherever and /usr/bin must be on the same partition, otherwise the mv will be the same as "rm /usr/bin/exeimage && cp /wherever/exeimage /usr/bin/exeimage && rm /wherever/exeimage", which is for sure not atomic. > Sure, but now you can't get back if the new software doesn't run. > This is why I recommended the two steps and cautioned about testing > the new stuff first. Then create a hardlink first, to keep a backup _and_ atomically replace the file. Andreas -- Build a system that even a fool can use and only a fool will want to use it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: buz.c of 2.4.4
On 2001.04.30 20:37:39 +0200 Mohammad A. Haque wrote: > On Mon, 30 Apr 2001, Alan Cox wrote: > > > Buz.c doesnt work build or anything. Once the zoran merge is done it > will > > go away, until then I simply dont care. At least its obviously broken > right > > now > > Can't we just remove it then? > > Come to think of it .. then we'd start getting "buz drivers missing" > reports. So what? Refer them to [EMAIL PROTECTED] and we'll explain them how to use the new zoran driver until it's in the official kernel... I mean, it be worse if they _used_ the old buz-thing, they'd start bugging you with "how do I fix it?" A broken driver in the kernel basically means a broken kernel - so it'd be better to just remove it I guess... What do you think, Alan? -- Ronald Bultje - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
AC97/es1371 detection problem
Linux won't detect my AC97 (Cirrus Logic, er something I forget exactly) soundcard from a cold start. Reset the machine and it loads up fine. Ideas? VIA KX133 motherboard BTW. mtrr: 0xe000,0x200 overlaps existing 0xe000,0x100 es1371: version v0.30 time 14:11:05 Apr 28 2001 es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08 PCI: Found IRQ 10 for device 00:0b.0 es1371: found es1371 rev 8 at io 0xa400 irq 10 es1371: features: joystick 0x0 ac97_codec: AC97 codec, id: 0x:0x (Unknown) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
reproducable hangup with 2.4.3-ac14, when swap is on a fs
Hi!
if the kernel writes swaps out something to a swapfile, which is on
a filesystem the kernel hangs up. (the Oops is below)
I tried it with kernel 2.4.3-ac14 and 2.4.3-ac10, and it works perfectly
with 2.4.3-ac10.
the filesystem type does not matter, at least it hangs with ext2, and
reiserfs. the swapfile is correct.
I didn't type in the call trace, but if you need it, just let me know.
(there are lot's of adresses, so the first few lines scrolled out.)
Code: 03 4a 0c8b 1d 0c da 1e c0 01 c3 8b 11 f6 c2 01 7 4e 81 e2
<0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
than I hit ALT-SysRq-s
<6> SysRq: Emergency Sync
Syncing device 03:41 ... OK
Syncing device 03:42 ... OK
Syncing device 03:45 ... OK
Syncing device 03:46 ... kernel BUG at sched.c:541!
Invalid operand:
CPU: 0
EIP: 0010:[]
EFLAGS: 00010282
eax: 001b ebx: c1ab1e78 ecx: c01eee9c edx: 91d0
esi: c0525a20 edi: c1ab ebp: c1ab1e64 esp: c1ab1e38
ds: 0018 es: 0018 ss: 0018
process (pid:0, stackpage=c1ab1000)
Stack: c01c1096 021d c1ab1e78 c0525a20 c1ab c0113c14 c025e9ac c1ab1e78
c0525a20 c025ea10 c025ea10 c012b4ba c1b69620 0346 0001
c1ab c0525a6c c0525a6c c012b638 c0525a20 0346
Call trace: [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] []
Code: 0f 0b 83 c4 08 89 f6 bf 00 e0 ff ff 21 e7 8b 47 34 89 45 f8
<0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
from System.map:
c0113c14 __run_task_queue
c012b4ba __wait_on_buffer
c012b638 sync_buffers
c012b75c fsync_dev
c016dc9a go_sync
c016dcf8 do_emergency_sync
c010fd4e panic
c011282b do_exit
c0106fe9 die
c010d5b8 do_page_fault
c010d683 do_page_fault
c010d2c4 do_page_fault
cf042b68 ???
c0106ba4 error_code
c010d2c4 do_page_fault
cf042b68 ???
than I hit ALT-SysRq-s again several times, and all the filesystems got
synced (in theory. really it messed up hdb6. the swapfile was on hdb2)
after this I tried it again.
it did the same, but after the Oops I saw this:
Printing EIP:
d67c
pgd entry c1731000:
pmd entry c1731000:
... pmd not present!
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] Acenic tigon 1 support fix
A typo prevents the tigon 1 firmware to be included when tigon 1 support is active. Null pointer dereference in ace_load_firmware->ace_copy as a result. Patch trivial and even tested (aka, the module loads without oopsing with a tigon 1 inside). OG. --- linux/drivers/net/acenic_firmware.h Tue Mar 6 22:28:33 2001 +++ linux-2.4.4/drivers/net/acenic_firmware.h Mon Apr 30 16:51:25 2001 @@ -17,7 +17,7 @@ #define tigonFwSbssLen 0x38 #define tigonFwBssAddr 0x00015dd0 #define tigonFwBssLen 0x2080 -#ifndef CONFIG_ACENIC_OMIT_TIGON_I +#ifdef CONFIG_ACENIC_OMIT_TIGON_I #define tigonFwText 0 #define tigonFwData 0 #define tigonFwRodata 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
reiserfs+lndir problem [was: 2.4.4 SMP: spurious EOVERFLOW "Value too large for defined data type"]
Hi all, unfortunately I have to correct me again. The problem seems unrelated to the kernel version or SMP/UP (though only 2.4.[34] tried yet). Apparently it's a reiserfs/symlink problem. I tried doing the lndir on an ext2 partition, sources still on reiserfs. And it worked just fine! Sorry for the rather large amount of noise, I hope it's finally correct now :) -- Daniel > the problem occurs only after setting up a parallel build tree with > lndir, removing the whole symlink tree, and running lndir again. > Maybe an reiserfs bug? > > -- Daniel > > > With kernel 2.4.4 SMP, I get some spurios errors from several > > user-space programs. Unfortunately it's hard to reproduce, I had most > > luck with the XFree86-4.0.3 build. When doing `make World', soon cpp0 > > (called by imake) dies with the following error message: > > > > cpp0: : Value too large for defined data type > > > > The message seems to correspond to EOVERFLOW in gcc's libiberty. > > When calling imake directly, it fails 1 out of 10-20 times. > > I couldn't reproduce this with calling cpp directly. > > > > I also got a lot of that messages once at shutdown, > > as init was trying to umount /proc. > > > > The error occurs neither with 2.4.3 SMP nor with 2.4.4 UP. > > (I'm using reiserfs, too.) > > > > ABIT VP6 > > dual P3 866 > > gcc version 2.95.4 20010319 (prerelease) > > binutils 2.11 > > glibc 2.2.3 > > > > Could you please give me further advice how to track this down? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CANBus driver.
Hi. Some of my fellow students and I, have started a project in which we have to implement a linux driver for a CANbus ISA card ( AROS: A-858D PCCAN -x ver. 1.12). Does there exist any work on a CANBus driver for linux already? Also, is there any interrest for this kind of driver, or would something like this end up on a useless outdated website? Any comments welcome. Thanks in advance. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.4: Via audio fixes
Would it be possible for you to make a code change and send me the dmesg output? Update linux/arch/i386/kernel/pci-i386.h and change -#undef DEBUG +#define DEBUG 1 Recompile, and privately e-mail me "dmesg -s 16384" output... -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: PATCH 2.4.4: Via audio fixes
On 30-Apr-01 Jeff Garzik wrote: > The attached patch includes fixes to the Via audio driver for which I'm > interested finding testers. Testing and a private "it works" (hopefully >:)) or "it doesn't work, is what breaks for me" would be > appreciated. > -- > Jeff Garzik | Game called on account of naked chick > Building 1024| > MandrakeSoft | it doesn't work. configuration: SMP, ac'97, IRQ gets assigned to 18. problem: interrupts appear to not be firing. Neither PRINTK() in via_intr_channel() or via_interrupt() ever get called (suggesting that the interrupt is either not firing, or not connected to the service routine). I've enabled debug, and have more information in the logs, but the short answer is "the interrupts aren't firing". in single processor more, no problem. (but that was always the case). -Greg +-+ "DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and millions of others are by far the most popular, with about 70 million machines in use wordwide. Macintosh fans, on the other hand, may note that cockroaches are far more numerous than humans, and that numbers alone do not denote a higher life form." (New York Times, November 26, 1991) | Greg Hosler i-net: [EMAIL PROTECTED]| +-+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4 + gcc 3 compile error
Hi, I tried compiling the 2.4.4 release with a gcc 3 snapshot and it failed with following error: gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c sys.c sys.c: In function `sys_gethostname': /usr/src/linux/include/asm/rwsem.h:152: inconsistent operand constraints in an `asm' make[3]: *** [sys.o] Error 1 make[3]: Leaving directory `/usr/src/linux/kernel' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/kernel' make[1]: *** [_dir_kernel] Error 2 make[1]: Leaving directory `/usr/src/linux' make: *** [stamp-build] Error 2 lucretia:/usr/src/linux$ Regards, Filip -- My opinions may have changed, but not the fact that I am right -- Daniel Vogel PGP signature
Re: 2.2.19 locks up on SMP
On Mon, 30 Apr 2001, Ion Badulescu wrote: > Except that the only driver I'm using is eepro100, and the only change to > that driver was the patch I submitted myself and which is also in 2.4. > > Also, another data point: those two SMP boxes have been running 2.2.18 + > Andrea's VM-global patch since January, without a hitch. > > Ok, so onto the binary search through the 2.2.19pre series... Just to give another data point... 2.2.19 + LVM patches - dual P3 550 1 GB RAM eepro100 ncr53c8xx scsi mylex accelRAID 1100 RAID controller We've transferred around 1 GB of stuff over the network and about 200 GB between two raids w/o problems in a little under 3 days. We've only scratched into swap. Free show 128K being used. -- = 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
On Mon, 30 Apr 2001, Jeff Garzik wrote: > Francois Gouget wrote: > > CONFIG_PCMCIA=y > > CONFIG_CARDBUS=y > > CONFIG_I82365=y > > Not correct -- you do not need I82365 if you have CardBus. However, if > you are running 2.4.4 you should be ok. Ok. I upgraded to 2.4.4 and modified my config file to be: CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_I82365 is not set But now I get the same missing symbols I initially had in 2.4.3: Apr 30 13:19:34 oleron cardmgr[148]: initializing socket 0 Apr 30 13:19:34 oleron cardmgr[148]: socket 0: Aironet PC4800 Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_core' Apr 30 13:19:34 oleron cardmgr[148]: + Warning: /lib/modules/2.4.4/kernel/drivers/net/aironet4500_core.o symbol for parameter rx_queue_len not found Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_proc' Apr 30 13:19:34 oleron cardmgr[148]: executing: 'modprobe aironet4500_cs' Apr 30 13:19:35 oleron cardmgr[148]: get dev info on socket 0 failed: Resource temporarily unavailable -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 SMP: spurious EOVERFLOW "Value too large for defined data type"
Hi again, the problem occurs only after setting up a parallel build tree with lndir, removing the whole symlink tree, and running lndir again. Maybe an reiserfs bug? -- Daniel > With kernel 2.4.4 SMP, I get some spurios errors from several > user-space programs. Unfortunately it's hard to reproduce, I had most > luck with the XFree86-4.0.3 build. When doing `make World', soon cpp0 > (called by imake) dies with the following error message: > > cpp0: : Value too large for defined data type > > The message seems to correspond to EOVERFLOW in gcc's libiberty. > When calling imake directly, it fails 1 out of 10-20 times. > I couldn't reproduce this with calling cpp directly. > > I also got a lot of that messages once at shutdown, > as init was trying to umount /proc. > > The error occurs neither with 2.4.3 SMP nor with 2.4.4 UP. > (I'm using reiserfs, too.) > > ABIT VP6 > dual P3 866 > gcc version 2.95.4 20010319 (prerelease) > binutils 2.11 > glibc 2.2.3 > > Could you please give me further advice how to track this down? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DMA support in cs5530 IDE driver? (repost)
> Can anyone report success or failure with enabling DMA for > the CS5530 IDE driver? I can get my system to crash or at > least hang pretty reliably by using hdparm to turn on DMA > while reading an MPEG-2 movie from my hard disk drive. My palmtop is a CS5530/MediaGX233 and seems stable with 2.4.*-ac. Im probably not hitting the disk as hard as you though - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Common GUI Config for All Users
To whom are you referring? -M On 30 Apr 2001 10:11:04 -0600, [EMAIL PROTECTED] wrote: > Thank you for the =constructive= answer Mohammad. I have thusfar only received >criticism for my question, with no further information, which I think is destructive >to the spirit of the list, and to the culture. > > Those who act like pricks toward newcomers should be treated as such, and I will >remember them. > -- > C. > > The best way out is always through. > - Robert Frost A Servant to Servants, 1914 > > > "Mohammad A. Haque" wrote: > > > On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote: > > > > > Looking for the best way to give all users a common desktop, which comes from >one source (for easy administration). > > > > This list doesn't deal with what you are asking. Try > > http://www.linux.com and see if anything/anyone there can help you. > > > > -- > > > > = > > 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] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announcing Journaled File System (JFS) beta 3 release 0.3.0 available
The beta 3 release 0.3.0 of JFS was made available today. The file system has fixes included. Both the file system and the utilities have been changed to use the system endian macros,so that JFS will now store the meta-data as little endian when running on all architectures. For more details about the problems fixed, please see the README. Steve JFS for Linux http://oss.software.ibm.com/developerworks/opensource/jfs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 maintainer?
On 30 Apr 2001, H. Peter Anvin wrote: > Is there someone who considers himself maintainer of the iso9660 > filesystem these days? -ENOENT, last time I checked. Do you volunteer? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 maintainer?
Alexander Viro wrote: > > On 30 Apr 2001, H. Peter Anvin wrote: > > > Is there someone who considers himself maintainer of the iso9660 > > filesystem these days? > > -ENOENT, last time I checked. Do you volunteer? > I was hoping to avoid it. I don't really have the cycles. However, I might be doing some enhancement work. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 locks up on SMP
On Mon, 30 Apr 2001, Alan Cox wrote: > > I also have reports but related to the network driver updates. So I > > suggest to try again with 2.2.19 but with the drivers/net/* of 2.2.18. > > Thats probably a better starting point. Its easier to back out than the VM > changes and it would also explain the reports I saw. Except that the only driver I'm using is eepro100, and the only change to that driver was the patch I submitted myself and which is also in 2.4. Also, another data point: those two SMP boxes have been running 2.2.18 + Andrea's VM-global patch since January, without a hitch. Ok, so onto the binary search through the 2.2.19pre series... Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 locks up on SMP
> On Mon, Apr 30, 2001 at 06:55:54PM +0100, Alan Cox wrote: > > A couple. It looks lik the VM changes may have upset something (based on > > reports saying it began at that point). Can you see if 2.2.19pre stuff is > > stable ? > > I also have reports but related to the network driver updates. So I > suggest to try again with 2.2.19 but with the drivers/net/* of 2.2.18. Thats probably a better starting point. Its easier to back out than the VM changes and it would also explain the reports I saw. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."
I'm fairly sure if he attached the BZ2'd sigs (exact same sigs, just bz2'd and tacked on like they are currently) would offend at least three camps, and have the benifit of showing up many broken mailers, filters, and various other mail related items. Nick On Mon, 30 Apr 2001, Gerhard Mack wrote: > On Mon, 30 Apr 2001, Eric S. Raymond wrote: > > > [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > > I think ppl are recommending you BZ2 all your sigs.. > > > > Yes, I got that. Except for the people saying they like them as-is. > > > > In the absence of a clear consensus on the matter, I'm going to do > > as I please. Especially since I have a strong suspicion that neither > > camp would change their evaluation of my sigs if I did compress them. > > Put them all on one long line and you can piss off a third camp. > > Gerhard > > PS I have a long rant on the topics your sigs cover but I would hate to > see the resulting flamewar. > > > -- > Gerhard Mack > > [EMAIL PROTECTED] > > <>< As a computer I find your faith in technology amusing. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
iso9660 maintainer?
Is there someone who considers himself maintainer of the iso9660 filesystem these days? -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."
On Mon, 30 Apr 2001, Eric S. Raymond wrote: > [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > I think ppl are recommending you BZ2 all your sigs.. > > Yes, I got that. Except for the people saying they like them as-is. > > In the absence of a clear consensus on the matter, I'm going to do > as I please. Especially since I have a strong suspicion that neither > camp would change their evaluation of my sigs if I did compress them. Put them all on one long line and you can piss off a third camp. Gerhard PS I have a long rant on the topics your sigs cover but I would hate to see the resulting flamewar. -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: make bzlilo seems to ignore non-standard kernel path in lilo.conf (/boot)
Followup to: <[EMAIL PROTECTED]> By author:Keith Owens <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > On Mon, 30 Apr 2001 12:16:24 +0200, > Olaf Stetzer <[EMAIL PROTECTED]> wrote: > >when I tried to get rid of the problem I wrote about two days ago in > >this list I compiled the kernel several times but unfortunately it was > >not installed correctly by the make target bzlilo. > > make INSTALL_PATH=/boot bzlilo > Or better yet, set up /sbin/installkernel for your system and do "make install". -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X15 alpha release: as fast as TUX but in user space
Ok I fixed it, the header date timestamp is updated with every request. Performance doesn't seem to have suffered significantly (less than 1%). You can find the new release at: http://www.chromium.com/X15-Alpha-2.tgz BTW: Don't call me slime, I wasn't trying to cheat, I just didn't know that the date stamp was required to be really up-to-date. - Fabio dean gaudet wrote: > On Sun, 29 Apr 2001, Fabio Riccardi wrote: > > > I can disable header caching and see what happens, I'll add an option > > for this in the next X15 release. > > heh, well to be honest, i'd put the (permanent) caching of the Date header > into the very slimy, benchmark-only trick category. (right up there > alongside running the HTTP and TCP stacks inside the NIC interrupt > handler, which folks have done to get even better scores.) > > > Nevertheless I don't know how much this is interesting in real life, > > since on the internet most static pages are cached on proxies. I agree > > that the RFC asks for a date for the original response, but once the > > response is cached what does this date mean? > > the Date is always the time the response was generated on the origin > server. (there are exceptions for clockless servers, but such servers > have other limitations you wouldn't want -- notably they MUST NOT generate > Last-Modified.) > > one example oddity you might experience with a non-increasing Date > surrounds Last-Modified and Date, see section 13.3.3. note that the rfc > indicates that if Last-Modified is less than 60 seconds earlier than Date > then Last-Modified is only a weak validator rather than a strong > validator. this would complicate range requests -- because weak > validators can't be used with range requests. if your server never > updates the Date after the first time it serves an object then you'd > potentially never get out of this 60 second window. > > (strong validators are guaranteed to change whenever the object changes... > and Last-Modified isn't strong until some time has passed -- consider NFS > mounted docroots, clock skew in the origin network, multiple file updates > within a second, etc.) > > there are a bunch of other things that Date is used for, all of them are > related to caching heuristics and rules. > > in theory you could claim that you're implementing a cache server rather > than an origin server... i dunno what the SPEC committee will think when > you try to submit results though :) > > so way back when sendfile() was being created i brought up the Date issue > and pointed out that we needed more than a single "void *, size_t" to take > care of headers. eventually this discussion lead creation of TCP_CORK -- > so that a http server could use writev() to send a two element iov for the > headers -- one element with everything that doesn't need to change, the > next element with the Date. > > i also kind of expected the high performance servers to rebuild a Date: > header every second for all of its threads to use. (of course it's not > that simple, you really want to keep a circular list of N dates... and > just assume that after N seconds no thread could still be accessing an old > Date.) > > is this too slow for some reason? (does it play well with zero-copy?) > > -dean > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
Peter Samuelson <[EMAIL PROTECTED]>: > [esr] > > Besides, right now the configurator has a simple invariant. It will > > only accept consistent configurations > > So you are saying that the old 'vi .config; make oldconfig' trick is > officially unsupported? That's too bad, it was quite handy. Depends on how you define `unsupported'. Make oldconfig will tell you exactly and unambiguously what was wrong with the configuration. I think if you're hard-core enough to vi your config, you're hard-core enough to interpret and act on This configuration violates the following constraints: (X86 and SMP==y) implies RTC!=n without needing some wussy GUI holding your hand :-). -- http://www.tuxedo.org/~esr/;>Eric S. Raymond The end move in politics is always to pick up a gun. -- R. Buckminster Fuller - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
[esr] > Besides, right now the configurator has a simple invariant. It will > only accept consistent configurations So you are saying that the old 'vi .config; make oldconfig' trick is officially unsupported? That's too bad, it was quite handy. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: Athlon/VIA/2.4.4 kernel BUG at page_alloc.c:73!
Apr 30 12:51:00 pollux kernel: kernel BUG at page_alloc.c:73! Apr 30 12:51:00 pollux kernel: invalid operand: This begins a cascade of similar messages, after which almost anything I try to do results in a segfault. The system is an Athlon on an Epox 8KTA3, with BIOS flashed up to 17-Apr-2001. The kernel is 2.4.4, compiled as a PIII (since I still can't get an Athlon kernel to boot.) I'm subscribed now, so I'll see any requests for more information. = % ksymoops oops.txt # File contains only the first in the cascade. ksymoops 2.4.0 on i686 2.4.4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.4/ (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. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Apr 30 12:51:00 pollux kernel: kernel BUG at page_alloc.c:73! Apr 30 12:51:00 pollux kernel: invalid operand: Apr 30 12:51:00 pollux kernel: CPU:0 Apr 30 12:51:00 pollux kernel: EIP:0010:[__free_pages_ok+34/776] Apr 30 12:51:00 pollux kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Apr 30 12:51:00 pollux kernel: EFLAGS: 00010292 Apr 30 12:51:00 pollux kernel: eax: 001f ebx: c1ca2960 ecx: edx: fff6 Apr 30 12:51:00 pollux kernel: esi: 0002 edi: 0002e000 ebp: esp: d9423f08 Apr 30 12:51:00 pollux kernel: ds: 0018 es: 0018 ss: 0018 Apr 30 12:51:00 pollux kernel: Process run-parts (pid: 1064, stackpage=d9423000) Apr 30 12:51:00 pollux kernel: Stack: c01d4a8b c01d4b80 0049 2f914025 0002 0002e000 c1044010 Apr 30 12:51:00 pollux kernel:c0202d60 0216 00016224 c012ad92 c011faaa ec70f660 efd40e20 Apr 30 12:51:00 pollux kernel:4002e000 3000 c1ca2960 2f914025 c1fbe0bc 00031000 c5221400 Apr 30 12:51:00 pollux kernel: Call Trace: [__free_pages+26/28] [zap_page_range+466/620] [exit_mmap+181/284] [mmput+38/68] [do_exit+161/552] [sys_exit+14/16] [system_call+51/56] Apr 30 12:51:00 pollux kernel: Call Trace: [] [] [] [] [] [] [] Apr 30 12:51:00 pollux kernel: Code: 0f 0b 83 c4 0c 83 7b 08 00 74 16 6a 4b 68 80 4b 1d c0 68 8b >>EIP; c012a462 <__free_pages_ok+22/308> <= Trace; c012ad92 <__free_pages+1a/1c> Trace; c011faaa Trace; c0122185 Trace; c0112d76 Trace; c01169cd Trace; c0116b7e Trace; c0106ae7 Code; c012a462 <__free_pages_ok+22/308> <_EIP>: Code; c012a462 <__free_pages_ok+22/308> <= 0: 0f 0b ud2a <= Code; c012a464 <__free_pages_ok+24/308> 2: 83 c4 0c add$0xc,%esp Code; c012a467 <__free_pages_ok+27/308> 5: 83 7b 08 00 cmpl $0x0,0x8(%ebx) Code; c012a46b <__free_pages_ok+2b/308> 9: 74 16 je 21 <_EIP+0x21> c012a483 <__free_pages_ok+43/308> Code; c012a46d <__free_pages_ok+2d/308> b: 6a 4b push $0x4b Code; c012a46f <__free_pages_ok+2f/308> d: 68 80 4b 1d c0push $0xc01d4b80 Code; c012a474 <__free_pages_ok+34/308> 12: 68 8b 00 00 00push $0x8b 2 warnings issued. Results may not be reliable. = % cat /proc/version Linux version 2.4.4 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #4 Sat Apr 28 19:54:44 GMT-6 2001 = % cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 1202.738 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 2398.61 = % cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 3). Master Capable. Latency=8. Prefetchable 32 bit memory at 0xd000 [0xd3ff]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (rev 0). Master Capable. No bursts. Min Gnt=12. Bus 0, device 7, function 0: ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 64). Bus 0, device 7, function 1: IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 6).
RE: 2.4 and 2GB swap partition limit
On Mon, 30 Apr 2001, David S. Miller wrote: > > Richard B. Johnson writes: > > On Mon, 30 Apr 2001, Torrey Hoffman wrote: > > > In general, is there a safe way to replace executable files for > > > programs that might be running while their on-disk images are > > > replaced? > > > > Yes. Perfectly safe: > > > > mv /usr/bin/exeimage /usr/bin/exeimage.sav > > cp /wherever/exeimage /usr/bin/exeimage > > > > > > The executing task will continue to use the old image until it exits. > > Even more effective is: > > mv /wherever/exeimage /usr/bin/exeimage > > The kernel keeps around the contents of the old file while > the executing process still runs. > > This is also basically how things like libc get installed. > A single mv is not only preserves currently referenced contents, > it is atomic. > > Later, > David S. Miller > [EMAIL PROTECTED] Sure, but now you can't get back if the new software doesn't run. This is why I recommended the two steps and cautioned about testing the new stuff first. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 and 2GB swap partition limit
Richard B. Johnson writes: > On Mon, 30 Apr 2001, Torrey Hoffman wrote: > > In general, is there a safe way to replace executable files for > > programs that might be running while their on-disk images are > > replaced? > > Yes. Perfectly safe: > > mv /usr/bin/exeimage /usr/bin/exeimage.sav > cp /wherever/exeimage /usr/bin/exeimage > > > The executing task will continue to use the old image until it exits. Even more effective is: mv /wherever/exeimage /usr/bin/exeimage The kernel keeps around the contents of the old file while the executing process still runs. This is also basically how things like libc get installed. A single mv is not only preserves currently referenced contents, it is atomic. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 and 2GB swap partition limit
On Mon, 30 Apr 2001, Torrey Hoffman wrote: > > In general, is there a safe way to replace executable files for > programs that might be running while their on-disk images are > replaced? > Yes. Perfectly safe: mv /usr/bin/exeimage /usr/bin/exeimage.sav cp /wherever/exeimage /usr/bin/exeimage The executing task will continue to use the old image until it exits. New tasks will use the new image. You can even replace `mv` and `cp` this way. It is best to test new programs first, though, so you know that it's linked with a runtime library that you have on your system. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4 SMP: spurious EOVERFLOW "Value too large for defined data type"
Hi, With kernel 2.4.4 SMP, I get some spurios errors from several user-space programs. Unfortunately it's hard to reproduce, I had most luck with the XFree86-4.0.3 build. When doing `make World', soon cpp0 (called by imake) dies with the following error message: cpp0: : Value too large for defined data type The message seems to correspond to EOVERFLOW in gcc's libiberty. When calling imake directly, it fails 1 out of 10-20 times. I couldn't reproduce this with calling cpp directly. I also got a lot of that messages once at shutdown, as init was trying to umount /proc. The error occurs neither with 2.4.3 SMP nor with 2.4.4 UP. (I'm using reiserfs, too.) ABIT VP6 dual P3 866 gcc version 2.95.4 20010319 (prerelease) binutils 2.11 glibc 2.2.3 Could you please give me further advice how to track this down? Thanks, -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4 and 2GB swap partition limit
Kenneth Johansson wrote: > Jonathan Lundell wrote: > > > > (Does Linux swap out text, by the way, he asks ignorantly?) > > .text is just droped and read back from the actuall file it's > not put into the swap Is this always true, even for init? Can init be swapped out? In general, is there a safe way to replace executable files for programs that might be running while their on-disk images are replaced? Thanks for any hints... Torrey Hoffman [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
Francois Gouget wrote: > CONFIG_PCMCIA=y > CONFIG_CARDBUS=y > CONFIG_I82365=y Not correct -- you do not need I82365 if you have CardBus. However, if you are running 2.4.4 you should be ok. Linux 2.4.4 includes a patch from me that fixes such configurations so that they don't conflict anymore, but running 2.4.3 or previous with such a configuration, you are likely to run into a partially-useable system (pcmcia but not cardbus cards work) or a completely unusable hotplug system (no cards work). -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: buz.c of 2.4.4
On Mon, 30 Apr 2001, Alan Cox wrote: > Buz.c doesnt work build or anything. Once the zoran merge is done it will > go away, until then I simply dont care. At least its obviously broken right > now Can't we just remove it then? Come to think of it .. then we'd start getting "buz drivers missing" reports. -- = 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can the kernel access /?
> Can the driver pull the file from the filesystem if I were to pass the > path of the file as an argument on loading the module? Yes but its a bad idea. You dont want to force pathnames into the kernel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
On Mon, 30 Apr 2001, Jeff Garzik wrote: > Elmer Joandi wrote: > > the whole pcmcia does not work in 2.4. > > Prove it. > > It works for people with correct 2.4 kernel configurations. What is a 'correct 2.4 kernel configuration'? Or more importantly how do I tell if mine is correct? Here's what I have in my config file: CONFIG_HOTPLUG=y CONFIG_PCMCIA=y CONFIG_CARDBUS=y CONFIG_I82365=y CONFIG_NET_ETHERNET=y CONFIG_NET_RADIO=y # CONFIG_STRIP is not set CONFIG_WAVELAN=m CONFIG_ARLAN=m CONFIG_AIRONET4500=m CONFIG_AIRONET4500_NONCS=m # CONFIG_AIRONET4500_PNP is not set # CONFIG_AIRONET4500_PCI is not set # CONFIG_AIRONET4500_ISA is not set # CONFIG_AIRONET4500_I365 is not set CONFIG_AIRONET4500_PROC=m CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m CONFIG_NET_PCMCIA_RADIO=y CONFIG_PCMCIA_RAYCS=m CONFIG_PCMCIA_HERMES=m CONFIG_PCMCIA_NETWAVE=m CONFIG_PCMCIA_WAVELAN=m CONFIG_AIRONET4500_CS=m Is there any important setting that I might have missed? I noticed that I was not loading the module aironet4500_proc. But loading it does not change anything except that I now have stuff in /proc/sys/aironet4500. But it doesn't really give me much more information. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: continued ext2fs corruption
Rob Todd <[EMAIL PROTECTED]> wrote: > I am using RH 7.1 with the stock 2.4.2-2 kernel (although the same behavior > shows up in 2.4.4 also compiled using gcc 2.96). Not quite sure about > hardware we share... it is a 1GHz P3 ServerWorks LE board (with the OSB4 > chipset) connecting to a Seagate ST320414A 20GB HD (UDMA 33). We have > several hundred other machines (including older ServerWorks boards) running > 2.4.4 with no problem so I was extremely surprised to receive these 32 > machines and have every single one of them experience some sort of file > system corruption. I am running 2.2.19 right now on these 32 machines with > no problems whatsoever. > > Rob Todd <[EMAIL PROTECTED]> wrote: > > If you receive an answer please let me know... I've been seeing the same > > problems on a 1GHz P3 with a ServerWorks OSB4 chipset. on the surface, it looks like your systems don't have anything in common with mine. i'm running rh71 too, but that's only because running kernel 2.4.2 on my previous rh62 system corrupted the filesystem so badly that i had to format and reinstall. i admit i'm somewhat glad to hear i'm not the only one having these problems, but it obviously isn't particularly widespread. are you also getting errors like this: EXT2-fs error (device ide0(3,3)): ext2_readdir: bad entry in directory #508411: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 the disk that becomes corrupted for me is an IBM Deskstar (UDMA 33), and it's on an intel 440BX chipset. does anyone here have any thoughts? thanks, ian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via VT82C686 data sheet
Via Product Datasheet Page http://www.via.com.tw/support/datasheets.htm Via Apollo Pro 82C686A http://www.via.com.tw/pdf/productinfo/686a.pdf VIA Document Request Form http://www.via.com.tw/contact/datasheets.htm -J. Greg Hosler wrote: > > Does anyone have, or know where I can get a copy of the above ? > > The onboard AC97 sound driver (via82cxxx_audio) was rewritten from legacy > (which works both in UP and SMP kernels), to do w/o the legacy support, > and go native. The problem is that the new driver doesn't properly handle > enabling interrupts for the case when the IRQ has been reassigned (by > the I/O APIC, which is typical under SMP). (actually the via82cxxx_audio > has code to try to handle the reassignment of the IRQ, but it doesn't work). > > I'm looking to see a copy of the datasheet on the 82C686, to see if I can > debug this further. > > thx for any pointers, and rgds, > > -Greg > > +-+ > "DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and > millions of others are by far the most popular, with about 70 million > machines in use wordwide. Macintosh fans, on the other hand, may note that > cockroaches are far more numerous than humans, and that numbers alone do > not denote a higher life form." (New York Times, November 26, 1991) > | Greg Hosler i-net: [EMAIL PROTECTED]| > +-+ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- John P. Silva[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 locks up on SMP
On Mon, Apr 30, 2001 at 08:15:47PM +0200, Andrea Arcangeli wrote: > suggest to try again with 2.2.19 but with the drivers/net/* of 2.2.18. even better try vanilla 2.2.19aa2 and if it crashes too, try 2.2.19aa2 plus the drivers/net/* of 2.2.18. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Common GUI Config for All Users
Hi yeah but i did not see those posts anyway you can either run X as a nice window system adn run gtk or kde on it i prefere gtk for my needs because i find kde a bit heavy On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote: > This was my point... Mohammad WAS the only one to help and not criticize. > > I did not pass along the crap I got from the 'bad attitudes', like Jasper Jans, Mark >Hahn, & Paul Dunne. All grief, no guidance nor respect. Tough to be a newbie. > -- > C. > > The best way out is always through. > - Robert Frost A Servant to Servants, 1914 > > > James Stevenson wrote: > > > Hi > > > > >Thank you for the =constructive= answer Mohammad. I have thusfar only received >criticism for my question, with no further > > > information, which I think is destructive to the spirit of the list, and to the >culture. > > > > i belive he did give you extra information look at the section below > > is it just me or is there a web site address in there. > > also dont expect information to be handed to you on a plate. > > > > >> This list doesn't deal with what you are asking. Try > > >> http://www.linux.com and see if anything/anyone there can help you. > > > > -- > > - > > Check Out: http://stev.org > > E-Mail: [EMAIL PROTECTED] > > 6:50pm up 6 days, 5:38, 4 users, load average: 0.95, 1.13, 0.83 > > > > -- - Check Out: http://stev.org E-Mail: [EMAIL PROTECTED] 7:30pm up 6 days, 6:18, 4 users, load average: 0.58, 0.98, 1.11 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Common GUI Config for All Users
On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote: > This was my point... Mohammad WAS the only one to help and not criticize. > > I did not pass along the crap I got from the 'bad attitudes', like Jasper Jans, Mark >Hahn, & Paul Dunne. All grief, no guidance nor respect. Tough to be a newbie. grief: no need for that if you can do what you want guidance: source, archive, RFC, FAQ, README respect: decide what you want to do, do it, be happy Vladimir Dergachev > -- > C. > > The best way out is always through. > - Robert Frost A Servant to Servants, 1914 > > > James Stevenson wrote: > > > Hi > > > > >Thank you for the =constructive= answer Mohammad. I have thusfar only received >criticism for my question, with no further > > > information, which I think is destructive to the spirit of the list, and to the >culture. > > > > i belive he did give you extra information look at the section below > > is it just me or is there a web site address in there. > > also dont expect information to be handed to you on a plate. > > > > >> This list doesn't deal with what you are asking. Try > > >> http://www.linux.com and see if anything/anyone there can help you. > > > > -- > > - > > Check Out: http://stev.org > > E-Mail: [EMAIL PROTECTED] > > 6:50pm up 6 days, 5:38, 4 users, load average: 0.95, 1.13, 0.83 > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 locks up on SMP
On Mon, Apr 30, 2001 at 06:55:54PM +0100, Alan Cox wrote: > A couple. It looks lik the VM changes may have upset something (based on > reports saying it began at that point). Can you see if 2.2.19pre stuff is > stable ? I also have reports but related to the network driver updates. So I suggest to try again with 2.2.19 but with the drivers/net/* of 2.2.18. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AC'97 (VT82C686A) & IRQ reassignment (I/O APIC)
Richard B. Johnson wrote: > Woof... More GAWDAUFULL junk. You mean that if I write 0xff to the R/W > interrupt line register and read it back, it's only 0x0f? Yes, and that disables generation of audio interrupts. > This didn't > save any money. There are only 4 interrupt 'pins', i.e., interrupt lines > that go to the PCI bus (A thru D). What these lines connect to for > actual IRQs is known only to the motherboard manufacturer hence the > BIOS has to check the pin value and write the appropriate IRQ value > into the interrupt line register. This register is used only as a > scratch-pad so that a driver "knows" what IRQ goes to the board. The > board, itself, never accesses this register. The board only gets one > interrupt connected (A thru D), and to the board, all interrupts are > the same. I'm currently writing the BIOS for a PowerPC embedded system using the 686B southbridge. On the 686 the 8259 interrupt controller and the audio system are inside the same physical device. The value you write to offset 0x3c actually makes the internal connection between the audio interrupt and the PIC. There is a trick to route that interrupt to an external APIC involving config register 0x58 in function 0, but I've not used it. Most southbridge functions work this way. The USB on the 686B is like this, and the the IDE controller always generates the legacy IRQ 14/15. - Adrian Cox - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DMA support in cs5530 IDE driver? (repost)
Hi, My apologies if you've seen this already. I sent this out last week but have not seen any replies; perhaps no one has any suggestions, but perhaps it didn't go out properly for some reason. -- . -- Can anyone report success or failure with enabling DMA for the CS5530 IDE driver? I can get my system to crash or at least hang pretty reliably by using hdparm to turn on DMA while reading an MPEG-2 movie from my hard disk drive. I don't think the movie playing is the relevent part; rather that it is heavily using the disk and driver. The hard disk drive is the only rotating drive on the system. Hardware: GCT Allwell set top box CPU: National Geode 266MHz GXM IDE controller: CS5530 Geode companion chip Linux: 2.4.3 Disk: IBM Deskstar, 46.1 GByte Any comments or suggestions appreciated Thanks, Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
I2O behaviour ...
Hi all, This is my first post on this list, I have been reading you all for quite a while. But now I have my Module to do... I have compiled the kernel (2.2.19) with I2O support, but when I try to compile my module, I get an unresolved error with the : i2o_pci_scan function. Is there a special way to compile the kernel to get those calls ? If I do a : cat /proc/ksyms, I get a bunch of I20 functions but I dont have : i2o_pci_scan i2o_pci_install ... those functions are defined in drivers/i2o/i2o_pci.c Here is a short description of what I need to do. I have a host PC and a local PC, both a separated by an INTEL (DEC) 21554. This is a non-transparent pci-to-pci bridge. I need to do a module for both computer to make them communicate by the mean of the PCI. The 21554 is supporting I2O. Maybe I am not at all going in the right direction ... If can someone point me out in this good direction ! Thank for your time and help. = Patrick Allaire mailto:[EMAIL PROTECTED] #define QUESTION ((bb) || !(bb)) - Shakespeare. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and 2GB swap partition limit
> > The swap I have is 2 partitions, one on each drive both with a priority of > > 0. Personally, I like the way it's done on my box. > > So you've spent almost $200 for RAM, and refuse to spend $4 for 1Gb of > swap space. Fine with me. Stupid argument. Very stupid argument. Take a 16Gb server. You now want to buy 64Gb of hard disk for the swap. Only because of partition limits you'll beed at least 2 disks entirely dedicated to it, which also means a controller a larger PSU and a bigger case. The swap behaviour of 2.4 is a bug. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
