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)
-m
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 another
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 kernel:
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 "un
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
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.
This
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 @ 0
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 g
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
> 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 "Loadin
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
> 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
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 chanc
61x: unable to enable\n");
> + 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-
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
[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 cd
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
> > set_
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)
>>
>> T
[wakko@kakarot:/home/wakko/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 (spe
(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 dri
> > 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 det
> 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 CS46
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
>th
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
using the ksymoops
that's 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
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 l
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
--
for_each_task(tsk) {
printk("[%s]\n", tsk->comm);
show_stack(tsk->thread.esp);
printk("\n\n");
}
read_unlock(&tasklist_lock);
BUG();
}
kmem_cache_free(ino
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
>> -mpreferred
> > 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 se
> 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
> /usr/src/li
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
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&m=97590235825341&w=2
>
> "Garst R. Reese" wrote:
> >
> > Fails to compile module
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=i6
Patch posted here...
http://marc.theaimsgroup.com/?l=linux-kernel&m=97590235825341&w=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"
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 ho
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
/usr/src/linux-2.4.0-te
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.
- Anto
47 matches
Mail list logo
