As Keith Owens pointed out klogd mangled the decode, I haev run it through
ksymoops and got the following decode:
ksymoops 2.3.4 on i686 2.4.0-test11. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test11/ (default)
As Keith Owens pointed out klogd mangled the decode, I haev run it through
ksymoops and got the following decode:
ksymoops 2.3.4 on i686 2.4.0-test11. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test11/ (default)
On Sun, 10 Dec 2000 17:44:06 + (GMT),
Tim <[EMAIL PROTECTED]> wrote:
>Dec 10 17:08:24 oxygen kernel: Call Trace: []
>[call_spurious_interrupt+33951/35940] [sprintf+20/28]
>[call_spurious_interrupt+33924/35940] [do_resource_list+77/132]
>[call_spurious_interrupt+33907/35940] []
Yet
Runing "modprobe megaraid" triggers this:
Dec 10 17:08:08 oxygen kernel: megaraid: v107 (December 22, 1999)
Dec 10 17:08:08 oxygen kernel: megaraid: found 0x101e:0x9010: in 00:0c.0
Dec 10 17:08:08 oxygen kernel: scsi0 : Found a MegaRAID controller at 0xe010, IRQ: 16
Dec 10 17:08:08 oxygen
Runing "modprobe megaraid" triggers this:
Dec 10 17:08:08 oxygen kernel: megaraid: v107 (December 22, 1999)
Dec 10 17:08:08 oxygen kernel: megaraid: found 0x101e:0x9010: in 00:0c.0
Dec 10 17:08:08 oxygen kernel: scsi0 : Found a MegaRAID controller at 0xe010, IRQ: 16
Dec 10 17:08:08 oxygen
On Sun, 10 Dec 2000 17:44:06 + (GMT),
Tim [EMAIL PROTECTED] wrote:
Dec 10 17:08:24 oxygen kernel: Call Trace: [d08925b7]
[call_spurious_interrupt+33951/35940] [sprintf+20/28]
[call_spurious_interrupt+33924/35940] [do_resource_list+77/132]
[call_spurious_interrupt+33907/35940] [d08925b7]
On Thursday 07 December 2000 06:28, Alan Cox wrote:
> > I copied the cs46xx.c driver from 2.4.0-test11 to 2.4.0-test11-ac1,
> > rebuilt, and I got a test11-ac1 kernel which works with KDE 2.0 and
> > sound.
>
> Excellent, that really narrows it down. Once 2.2.18 is out I will try and
> get to the
> I copied the cs46xx.c driver from 2.4.0-test11 to 2.4.0-test11-ac1,
> rebuilt, and I got a test11-ac1 kernel which works with KDE 2.0 and sound.
Excellent, that really narrows it down. Once 2.2.18 is out I will try and
get to the bottom of this
-
To unsubscribe from this list: send the line
I copied the cs46xx.c driver from 2.4.0-test11 to 2.4.0-test11-ac1,
rebuilt, and I got a test11-ac1 kernel which works with KDE 2.0 and sound.
Excellent, that really narrows it down. Once 2.2.18 is out I will try and
get to the bottom of this
-
To unsubscribe from this list: send the line
On Thursday 07 December 2000 06:28, Alan Cox wrote:
I copied the cs46xx.c driver from 2.4.0-test11 to 2.4.0-test11-ac1,
rebuilt, and I got a test11-ac1 kernel which works with KDE 2.0 and
sound.
Excellent, that really narrows it down. Once 2.2.18 is out I will try and
get to the bottom
On Wed, 06 Dec 2000, Steven Cole wrote:
> On Tuesday 05 December 2000 18:00, Alan Cox wrote:
> > > I did confirm that 2.4.0-test11(final) works properly with sound and KDE
> > > 2.0.
> > Ok. That sounds even more like its PCI changes
> I copied the cs46xx.c driver from 2.4.0-test11 to
On Wed, 6 Dec 2000, Giacomo Catenazzi wrote:
> On my box, with heavy load I saw:
> spurious 8259A interrupt: IRQ7.
> Newer seen this message before.
>
> Linux (2.4.0.11.4) or my old slow box ?
>
>
> giacomo
>
This is really "normal" occasionally, and probably should not be logged.
On my box, with heavy load I saw:
spurious 8259A interrupt: IRQ7.
Newer seen this message before.
Linux (2.4.0.11.4) or my old slow box ?
giacomo
My dmesg
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @
On Tuesday 05 December 2000 18:00, Alan Cox wrote:
> > I did confirm that 2.4.0-test11(final) works properly with sound and KDE
> > 2.0.
>
> Ok. That sounds even more like its PCI changes
>
Some new information:
I copied the cs46xx.c driver from 2.4.0-test11 to 2.4.0-test11-ac1,
rebuilt, and I
On Mon, Dec 04 2000, Borislav Deianov wrote:
> (cross-posted to linux-kernel and linux-scsi)
>
> Hi,
>
> The SCSI oops I reported last week is still present in test12-pre4.
> This is on a Dell PowerEdge 6300. It has two Adaptec AIC-7890, one
> Adaptec AIC-7860, and an AM
On Mon, Dec 04 2000, Borislav Deianov wrote:
(cross-posted to linux-kernel and linux-scsi)
Hi,
The SCSI oops I reported last week is still present in test12-pre4.
This is on a Dell PowerEdge 6300. It has two Adaptec AIC-7890, one
Adaptec AIC-7860, and an AMI MegaRAID controller. There's
On Tuesday 05 December 2000 18:00, Alan Cox wrote:
I did confirm that 2.4.0-test11(final) works properly with sound and KDE
2.0.
Ok. That sounds even more like its PCI changes
Some new information:
I copied the cs46xx.c driver from 2.4.0-test11 to 2.4.0-test11-ac1,
rebuilt, and I got a
On my box, with heavy load I saw:
spurious 8259A interrupt: IRQ7.
Newer seen this message before.
Linux (2.4.0.11.4) or my old slow box ?
giacomo
My dmesg
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @
On Wed, 06 Dec 2000, Steven Cole wrote:
On Tuesday 05 December 2000 18:00, Alan Cox wrote:
I did confirm that 2.4.0-test11(final) works properly with sound and KDE
2.0.
Ok. That sounds even more like its PCI changes
I copied the cs46xx.c driver from 2.4.0-test11 to 2.4.0-test11-ac1,
> I did confirm that 2.4.0-test11(final) works properly with sound and KDE 2.0.
Ok. That sounds even more like its PCI changes
> I do think its rather odd that these test12-pre3,4,5 kernels all work with
> GNOME and the CD player works then. KDE 2.0 is doing something different
> at the
On Tuesday 05 December 2000 15:02, Alan Cox wrote:
>
> > cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
> > cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
>
> This gets garbage back when it reads the vendor subids. I dont at this
> point see it being a sound
> Crystal 4280/461x + AC97 Audio, version 0.13, 08:56:46 Dec 5 2000
> cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
> cs461x: Unknown card (1028:0096) at 0xf8ffe000/0xf8e0, IRQ 18
> ac97_codec: AC97 Audio codec, vendor id1: 0x4352, id2: 0x5914 (Unknown)
This correctly sees the
Alexander Viro wrote:
>
> On Sun, 3 Dec 2000, Linus Torvalds wrote:
>
> >
> > Synching up with Alan and various other stuff. The most important one
> > being the fix to the inode dirty block list.
>
> It doesn't solve the problem. If you unlink a file with dirty metadata
> you have a nice
t;);
> + return -EIO;
> + }
> if ((card = kmalloc(sizeof(struct cs_card), GFP_KERNEL)) == NULL) {
> printk(KERN_ERR "cs461x: out of memory\n");
> return -ENOMEM;
OK, I patched in the above for both 2.4.0-test12-pre4 an
)) == NULL) {
printk(KERN_ERR "cs461x: out of memory\n");
return -ENOMEM;
OK, I patched in the above for both 2.4.0-test12-pre4 and pre5, but did not
get any "unable to enable" printk messages appearing in /var/log/messages.
The behavior of course is the same, that i
Alexander Viro wrote:
On Sun, 3 Dec 2000, Linus Torvalds wrote:
Synching up with Alan and various other stuff. The most important one
being the fix to the inode dirty block list.
It doesn't solve the problem. If you unlink a file with dirty metadata
you have a nice chance to hit
Crystal 4280/461x + AC97 Audio, version 0.13, 08:56:46 Dec 5 2000
cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
cs461x: Unknown card (1028:0096) at 0xf8ffe000/0xf8e0, IRQ 18
ac97_codec: AC97 Audio codec, vendor id1: 0x4352, id2: 0x5914 (Unknown)
This correctly sees the card
On Tuesday 05 December 2000 15:02, Alan Cox wrote:
cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
This gets garbage back when it reads the vendor subids. I dont at this
point see it being a sound bug but a
I did confirm that 2.4.0-test11(final) works properly with sound and KDE 2.0.
Ok. That sounds even more like its PCI changes
I do think its rather odd that these test12-pre3,4,5 kernels all work with
GNOME and the CD player works then. KDE 2.0 is doing something different
at the "Loading
Alan has it and Linus hasn't applied Alan's patch yet...
Linus said.
"[ Alan - I ahve your patches in my incoming queue still, I wanted to
get
an interim version out to check with Al on the block list and the VM
stuff with Rik and people. ]"
"Garst R. Reese" wrote:
>
> Did you send
[1.] One line summary of the problem:
During burning of CD onto SCSI driver (using cdrecord) crashes. during
the burn (10% or so) it crashes with "Unable to handle kernel null pointer"
[2.] Full description of the problem/report:
During burning of CD onto SCSI driver (using
Did you send it Linus?
It is not in pre5
Garst
"Mohammad A. Haque" wrote:
> Ok, so here's the proper patch for those who dont want to wait for t5 =)
> Ignore previous.
>
> On Mon, 4 Dec 2000, Jeff Garzik wrote:
>
> > the fix is in module.h which needs extra parens in the def of
> >
On Mon, 4 Dec 2000 20:39:29 -0500,
Wakko Warner <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote
>> Is there any chance of changing arch/alpha/kernel/traps.c to print
>> registers, trace and _raw_ code, in that order so it is more like other
>> architectures? You can print the decoded instructions
Alan Cox wrote:
>> > Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
>> > cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
>> > cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
>> > ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
>>
>>
ko/ksymoops-2.3.4] ./ksymoops -v
/usr/src/2.4.0-test12-pre4/vmlinux -K -L -O -m /usr/src/2.4.0-test12-pre4/System.map <
/rod/home/wakko/240t12p4-boot
ksymoops 2.3.4 on alpha 2.2.17-LVM-RAID. Options used
-v /usr/src/2.4.0-test12-pre4/vmlinux (specified)
-K (specified)
-L (specifie
(cross-posted to linux-kernel and linux-scsi)
Hi,
The SCSI oops I reported last week is still present in test12-pre4.
This is on a Dell PowerEdge 6300. It has two Adaptec AIC-7890, one
Adaptec AIC-7860, and an AMI MegaRAID controller. There's nothing on
the 7890s, a CDROM and a tape drive
> > Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
> > cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
> > cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
> > ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
>
> This is failing to
> Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
> cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
> cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
> ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
This is failing to detect the
6xx driver compiled either as a module or into
> the kernel, then 2.4.0-test12-pre4 locks up when KDE 2.0
> is started.
>
> The problem with dummy.o in 2.4.0-test12-pre4 allowed me
> to find the possible source of this lock-up which I have been
> seeing recently (since test11-ac2) whil
On Mon, 4 Dec 2000 14:27:10 -0700,
Steven Cole <[EMAIL PROTECTED]> wrote:
>If I have the cs46xx driver compiled either as a module or into
>the kernel, then 2.4.0-test12-pre4 locks up when KDE 2.0
>is started.
>[snip]
>When I say the system freezes, I mean it completely loc
On Mon, 4 Dec 2000 16:26:42 -0500,
Wakko Warner <[EMAIL PROTECTED]> wrote:
>PCI patches that were added between pre3 and pre4 allow me to boot the
>kernel on my noritake alpha. Once it boots, however, it oops's in the
>swapper. I've tried a few times in the past to use ksymoops on oops's on
If I have the cs46xx driver compiled either as a module or into
the kernel, then 2.4.0-test12-pre4 locks up when KDE 2.0
is started.
The problem with dummy.o in 2.4.0-test12-pre4 allowed me
to find the possible source of this lock-up which I have been
seeing recently (since test11-ac2) while
part of the debian potato dist)
I have attached the boot log.
Keep my name in the CC
--
Lab tests show that use of micro$oft causes cancer in lab animals
Linux version 2.4.0-test12-pre4 (wakko@kakarot) (gcc version 2.95.2 2220 (Debian
GNU/Linux)) #2 Mon Dec 4 09:07:20 EST 2000
Booting
On Mon, 4 Dec 2000, Stephen C. Tweedie wrote:
> Agreed. However, is there any reason to have this as a separate
> function? bforget() should _always_ remove the buffer from any inode
> queue. You can make that operation conditional on (bh->b_inode !=
> NULL) if you want to avoid taking the
On Mon, Dec 04, 2000 at 01:01:36AM -0500, Alexander Viro wrote:
>
> It doesn't solve the problem. If you unlink a file with dirty metadata
> you have a nice chance to hit the BUG() in inode.c:83. I hope that patch
> below closes all remaining holes. See analysis in previous posting
> (basically,
Ok, so here's the proper patch for those who dont want to wait for t5 =)
Ignore previous.
On Mon, 4 Dec 2000, Jeff Garzik wrote:
> the fix is in module.h which needs extra parens in the def of
> set_module_owner...
>
> Jeff
--
, tsk->comm);
show_stack(tsk->thread.esp);
printk("\n\n");
}
read_unlock(_lock);
BUG();
}
kmem_cache_free(inode_cachep, (inode));
}
So we get a full task dump. Otherwise this is vani
I had the same error, The .config file is attached.
Alan Cox wrote:
>> Was borking on dummy.c. This seemed to fix it. Verification please?
>>
>> gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall
>> -Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe
>>
> > dummy.c: In function `dummy_init_module':
> > dummy.c:103: invalid type argument of `->'
> > make[2]: *** [dummy.o] Error 1
>
> No, module.h needs fixing. I guess I didn't send that one to Alan...
You did send it, you just didnt tell me the dummy patch depended on it
and that I needed to
> Was borking on dummy.c. This seemed to fix it. Verification please?
>
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall
> -Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe
> -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include
>
Mike Galbraith wrote:
>
> Hi,
>
> When stressing swap (virgin test12-pre4), I encounter the repeatable
> oops below once load builds to heavy. The vmscan.c:UnlockPage(page)
> addition sets it off. Appears 100% repeatable.
>
Same here.
-
To unsubscribe from thi
Hi Linus,
This patch adds support for the latest member of Intel IA32 family -- the
Pentium 4 processor. Tested under 2.4.0-test12-pre4 -- still works.
Regards,
Tigran
diff -urN -X dontdiff linux/CREDITS ucode/CREDITS
--- linux/CREDITS Mon Dec 4 08:43:33 2000
+++ ucode/CREDITS Mon
Hi,
When stressing swap (virgin test12-pre4), I encounter the repeatable
oops below once load builds to heavy. The vmscan.c:UnlockPage(page)
addition sets it off. Appears 100% repeatable.
kernel BUG at swap.c:271!
invalid operand:
CPU:0
EIP:0010:[]
EFLAGS: 00010282
eax
Hi,
When stressing swap (virgin test12-pre4), I encounter the repeatable
oops below once load builds to heavy. The vmscan.c:UnlockPage(page)
addition sets it off. Appears 100% repeatable.
kernel BUG at swap.c:271!
invalid operand:
CPU:0
EIP:0010:[c012c144]
EFLAGS: 00010282
eax
Hi Linus,
This patch adds support for the latest member of Intel IA32 family -- the
Pentium 4 processor. Tested under 2.4.0-test12-pre4 -- still works.
Regards,
Tigran
diff -urN -X dontdiff linux/CREDITS ucode/CREDITS
--- linux/CREDITS Mon Dec 4 08:43:33 2000
+++ ucode/CREDITS Mon
Mike Galbraith wrote:
Hi,
When stressing swap (virgin test12-pre4), I encounter the repeatable
oops below once load builds to heavy. The vmscan.c:UnlockPage(page)
addition sets it off. Appears 100% repeatable.
Same here.
-
To unsubscribe from this list: send the line "unsubs
Was borking on dummy.c. This seemed to fix it. Verification please?
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall
-Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include
dummy.c: In function `dummy_init_module':
dummy.c:103: invalid type argument of `-'
make[2]: *** [dummy.o] Error 1
No, module.h needs fixing. I guess I didn't send that one to Alan...
You did send it, you just didnt tell me the dummy patch depended on it
and that I needed to send both
I had the same error, The .config file is attached.
Alan Cox wrote:
Was borking on dummy.c. This seemed to fix it. Verification please?
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall
-Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe
p);
printk("\n\n");
}
read_unlock(tasklist_lock);
BUG();
}
kmem_cache_free(inode_cachep, (inode));
}
So we get a full task dump. Otherwise this is vanilla test12-pre4 plus
your bforget_inode() patch. SMP kernel on
Ok, so here's the proper patch for those who dont want to wait for t5 =)
Ignore previous.
On Mon, 4 Dec 2000, Jeff Garzik wrote:
the fix is in module.h which needs extra parens in the def of
set_module_owner...
Jeff
--
On Mon, Dec 04, 2000 at 01:01:36AM -0500, Alexander Viro wrote:
It doesn't solve the problem. If you unlink a file with dirty metadata
you have a nice chance to hit the BUG() in inode.c:83. I hope that patch
below closes all remaining holes. See analysis in previous posting
(basically,
On Mon, 4 Dec 2000, Stephen C. Tweedie wrote:
Agreed. However, is there any reason to have this as a separate
function? bforget() should _always_ remove the buffer from any inode
queue. You can make that operation conditional on (bh-b_inode !=
NULL) if you want to avoid taking the lru
part of the debian potato dist)
I have attached the boot log.
Keep my name in the CC
--
Lab tests show that use of micro$oft causes cancer in lab animals
Linux version 2.4.0-test12-pre4 (wakko@kakarot) (gcc version 2.95.2 2220 (Debian
GNU/Linux)) #2 Mon Dec 4 09:07:20 EST 2000
Booting
If I have the cs46xx driver compiled either as a module or into
the kernel, then 2.4.0-test12-pre4 locks up when KDE 2.0
is started.
The problem with dummy.o in 2.4.0-test12-pre4 allowed me
to find the possible source of this lock-up which I have been
seeing recently (since test11-ac2) while
On Mon, 4 Dec 2000 16:26:42 -0500,
Wakko Warner [EMAIL PROTECTED] wrote:
PCI patches that were added between pre3 and pre4 allow me to boot the
kernel on my noritake alpha. Once it boots, however, it oops's in the
swapper. I've tried a few times in the past to use ksymoops on oops's on
the
On Mon, 4 Dec 2000 14:27:10 -0700,
Steven Cole [EMAIL PROTECTED] wrote:
If I have the cs46xx driver compiled either as a module or into
the kernel, then 2.4.0-test12-pre4 locks up when KDE 2.0
is started.
[snip]
When I say the system freezes, I mean it completely locks up, and
ALT-SYSRQ
compiled either as a module or into
the kernel, then 2.4.0-test12-pre4 locks up when KDE 2.0
is started.
The problem with dummy.o in 2.4.0-test12-pre4 allowed me
to find the possible source of this lock-up which I have been
seeing recently (since test11-ac2) while starting up KDE 2.0
Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
This is failing to detect the CS46xx.
Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
This is failing to detect the
(cross-posted to linux-kernel and linux-scsi)
Hi,
The SCSI oops I reported last week is still present in test12-pre4.
This is on a Dell PowerEdge 6300. It has two Adaptec AIC-7890, one
Adaptec AIC-7860, and an AMI MegaRAID controller. There's nothing on
the 7890s, a CDROM and a tape drive
bytes are also available.
In the meantime, this patch to ksymoops 2.3.5 will pick up the change
to the trace lines. It will still complain about a bad code line,
ksymoops is built for raw data.
Didn't help much:
[wakko@kakarot:/home/wakko/ksymoops-2.3.4] ./ksymoops -v
/usr/src/2.4.0-test12-pre4
Alan Cox wrote:
Crystal 4280/461x + AC97 Audio, version 0.14, 13:39:25 Dec 4 2000
cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18
cs461x: Unknown card (:) at 0xf8ffe000/0xf8e0, IRQ 18
ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown)
This is failing
On Mon, 4 Dec 2000 20:39:29 -0500,
Wakko Warner [EMAIL PROTECTED] wrote:
Keith Owens wrote
Is there any chance of changing arch/alpha/kernel/traps.c to print
registers, trace and _raw_ code, in that order so it is more like other
architectures? You can print the decoded instructions as well
Did you send it Linus?
It is not in pre5
Garst
"Mohammad A. Haque" wrote:
Ok, so here's the proper patch for those who dont want to wait for t5 =)
Ignore previous.
On Mon, 4 Dec 2000, Jeff Garzik wrote:
the fix is in module.h which needs extra parens in the def of
Alan has it and Linus hasn't applied Alan's patch yet...
Linus said.
"[ Alan - I ahve your patches in my incoming queue still, I wanted to
get
an interim version out to check with Al on the block list and the VM
stuff with Rik and people. ]"
"Garst R. Reese" wrote:
Did you send it
the fix is in module.h which needs extra parens in the def of
set_module_owner...
Jeff
On Mon, 4 Dec 2000, Mohammad A. Haque wrote:
> Patch posted here...
> http://marc.theaimsgroup.com/?l=linux-kernel=97590235825341=2
>
> "Garst R. Reese" wrote:
> >
> > Fails to compile module at
On Sun, 3 Dec 2000, Mohammad A. Haque wrote:
> Was borking on dummy.c. This seemed to fix it. Verification please?
>
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall
> -Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe
> -mpreferred-stack-boundary=2
Patch posted here...
http://marc.theaimsgroup.com/?l=linux-kernel=97590235825341=2
"Garst R. Reese" wrote:
>
> Fails to compile module at line 103,
> invalid type argument of ->
> Sorry if this well known.
> Garst
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Fails to compile module at line 103,
invalid type argument of ->
Sorry if this well known.
Garst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Sun, 3 Dec 2000, Linus Torvalds wrote:
>
> Synching up with Alan and various other stuff. The most important one
> being the fix to the inode dirty block list.
It doesn't solve the problem. If you unlink a file with dirty metadata
you have a nice chance to hit the BUG() in inode.c:83. I
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6
-Wa,-mev6-DEXPORT_SYMTAB -c pci.c
pci.c: In function `pci_read_bases':
pci.c:576: `tmp' undeclared (first use in this function)
pci.c:576:
Was borking on dummy.c. This seemed to fix it. Verification please?
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall
-Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include
Synching up with Alan and various other stuff. The most important one
being the fix to the inode dirty block list.
Linus
- pre4:
- Andries Brouwer: final isofs pieces.
- Kai Germaschewski: ISDN
- play CD audio correctly, don't stop after 12 minutes.
-
Synching up with Alan and various other stuff. The most important one
being the fix to the inode dirty block list.
Linus
- pre4:
- Andries Brouwer: final isofs pieces.
- Kai Germaschewski: ISDN
- play CD audio correctly, don't stop after 12 minutes.
-
Was borking on dummy.c. This seemed to fix it. Verification please?
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall
-Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6
-Wa,-mev6-DEXPORT_SYMTAB -c pci.c
pci.c: In function `pci_read_bases':
pci.c:576: `tmp' undeclared (first use in this function)
pci.c:576:
On Sun, 3 Dec 2000, Linus Torvalds wrote:
Synching up with Alan and various other stuff. The most important one
being the fix to the inode dirty block list.
It doesn't solve the problem. If you unlink a file with dirty metadata
you have a nice chance to hit the BUG() in inode.c:83. I hope
Fails to compile module at line 103,
invalid type argument of -
Sorry if this well known.
Garst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Patch posted here...
http://marc.theaimsgroup.com/?l=linux-kernelm=97590235825341w=2
"Garst R. Reese" wrote:
Fails to compile module at line 103,
invalid type argument of -
Sorry if this well known.
Garst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Sun, 3 Dec 2000, Mohammad A. Haque wrote:
Was borking on dummy.c. This seemed to fix it. Verification please?
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11/include -Wall
-Wstrict-prototypes -O6 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686
the fix is in module.h which needs extra parens in the def of
set_module_owner...
Jeff
On Mon, 4 Dec 2000, Mohammad A. Haque wrote:
Patch posted here...
http://marc.theaimsgroup.com/?l=linux-kernelm=97590235825341w=2
"Garst R. Reese" wrote:
Fails to compile module at line
92 matches
Mail list logo
