On Monday 03 February 2003 00:38, Karl Heyes wrote:> On Sun, 2003-02-02 at 22:48, Marc Remijn wrote: > > The only module I know about that is 'tainted' is the philips webcam > > compression module pwcx, which I forced loaded with 'insmod -f'. But > > unloading that didn't change the problem. Anyway the 'tainted' issue has > > to do with no being in order with the GNU licence isn't it? > > No the best thing to do, is not load the module to start with, unloading > the module may mean nothing as it's already had access to the kernel.<p><p>I disabled the startup script that loaded the kernel modules. I rebooted the system (obviously with lots of error messages by things that depend on some module or other being loaded). I loaded the Soundblaster live module by hand (emu10k1). I started icecast. I started ices with the live-line-in config and: Same problem. kernel: invalid operand: 0000 CPU: 0 EIP: 0010:[<d08895b1>] Not tainted EFLAGS: 00010006 eax: 0000000e ebx: 00003556 ecx: cff5b6b8 edx: cff5b6b8 esi: 0000e000 edi: 00000007 ebp: cd351f64 esp: cd351f4c ds: 0018 es: 0018 ss: 0018 Process ices (pid: 278, stackpage=cd351000) Stack: 00000202 cd582c10 00008000 cff5b670 cff5b6b8 0000ffff 00018000 0001c000 00010000 00014000 d088711c cff5b670 00000000 cd582c10 ffffffea 00008000 00000000 00000000 ce4cdde0 00000000 c012db45 cd582c10 0805a720 00008000 Call Trace: [<d088711c>] [<c012db45>] [<c0106d7b>] Code: 0f 0b 5b 5e 5f 5d 83 c4 18 c3 90 83 ec 04 56 53 8b 44 24 10 <p>lsmod: Module Size Used by Not tainted emu10k1 55680 1 sound 52876 0 [emu10k1] ac97_codec 9568 0 [emu10k1] soundcore 3236 7 (autoclean) [emu10k1 sound] iptable_nat 12660 1 (autoclean) ip_conntrack 12684 1 (autoclean) [iptable_nat] ip_tables 10432 3 [iptable_nat] <p>Marc --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Mon, 2003-02-03 at 21:02, Marc Remijn wrote:> Same problem. > > kernel: > invalid operand: 0000 > CPU: 0 > EIP: 0010:[<d08895b1>] Not tainted > EFLAGS: 00010006 > eax: 0000000e ebx: 00003556 ecx: cff5b6b8 edx: cff5b6b8 > esi: 0000e000 edi: 00000007 ebp: cd351f64 esp: cd351f4c > ds: 0018 es: 0018 ss: 0018 > Process ices (pid: 278, stackpage=cd351000) > Stack: 00000202 cd582c10 00008000 cff5b670 cff5b6b8 0000ffff 00018000 0001c000 > 00010000 00014000 d088711c cff5b670 00000000 cd582c10 ffffffea 00008000 > 00000000 00000000 ce4cdde0 00000000 c012db45 cd582c10 0805a720 00008000 > Call Trace: [<d088711c>] [<c012db45>] [<c0106d7b>] > > Code: 0f 0b 5b 5e 5f 5d 83 c4 18 c3 90 83 ec 04 56 53 8b 44 24 10 > > > lsmod: > Module Size Used by Not taintedok, now you've eliminated both the memory and module cases, try an updated kernel, latest stable is 2.4.20, although there are some interim patches which will become 2.4.21 eventually. If 2.4.20 also shows the same problem then you'll have to report it to the kernel mailing list or maintainer of the code in question. You'll need to decode the oops (above) with ksymoops to get a stack trace. You can try to isolate certain things, ices (in your case) mainly reads from dsp and writes on network sockets. The encoding part of ices is very unlikely to cause the panic but the ksymoops output is more likely to indicate the area of concern. If you need more help email me directly, as this is not really an ices or icecast issue. karl. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> On Mon, 2003-02-03 at 21:02, Marc Remijn wrote: > >> Same problem. >> >> kernel: >> invalid operand: 0000 >> CPU: 0 >> EIP: 0010:[<d08895b1>] Not tainted >> EFLAGS: 00010006 >> eax: 0000000e ebx: 00003556 ecx: cff5b6b8 edx: cff5b6b8 >> esi: 0000e000 edi: 00000007 ebp: cd351f64 esp: cd351f4c >> ds: 0018 es: 0018 ss: 0018 >> Process ices (pid: 278, stackpage=cd351000) >> Stack: 00000202 cd582c10 00008000 cff5b670 cff5b6b8 0000ffff 00018000 >> 0001c000 >> 00010000 00014000 d088711c cff5b670 00000000 cd582c10 ffffffea >> 00008000 00000000 00000000 ce4cdde0 00000000 c012db45 cd582c10 >> 0805a720 00008000 >> Call Trace: [<d088711c>] [<c012db45>] [<c0106d7b>] >> >> Code: 0f 0b 5b 5e 5f 5d 83 c4 18 c3 90 83 ec 04 56 53 8b 44 24 10 >> >> >> lsmod: >> Module Size Used by Not tainted > > ok, now you've eliminated both the memory and module cases, try an > updated kernel, latest stable is 2.4.20, although there are some interim > patches which will become 2.4.21 eventually. > > If 2.4.20 also shows the same problem then you'll have to report it to > the kernel mailing list or maintainer of the code in question. You'll > need to decode the oops (above) with ksymoops to get a stack trace.Well I got fresh sources of 2.4.20. I configured only options I really need, I compiled the kernel and the modules, installed them and YES!! Ices now works without any problem. Even when I load the 'tainted' pwcx (Philips Webcam compression module) I don't have any problems. I think the problems with the 2.4.18 kernel might be due to the fact that this Slackware kernel was compiled with almost every other option compiled in. Even development stuff was enabled. So maybe recompiling the 2.4.18 being a bit more conservative with the options enabled might produce a stabler kernel. Also I think the Adaptec Scsi driver has changed in the 2.4.20 release. Anyway I saw an old and a new one. I think the 'old' one was compiled in the 2.4.18 kernel. Anyway to return on topic of Ices / Ogg Vorbis. I am very satisfied with the quality. I steam the sound of my sat receiver, so I can listen in at work. I have adsl with 128 kbit/s upstream. Quality 3 sometimes breaks on this link, but q2 works fine. I found the managed bitrate not to work very well. With the q settings on a local lan even 6 works fine. <p><p><p>>> You can try to isolate certain things, ices (in your case) mainly reads > from dsp and writes on network sockets. The encoding part of ices is > very unlikely to cause the panic but the ksymoops output is more likely > to indicate the area of concern. > > If you need more help email me directly, as this is not really an ices > or icecast issue. > > karl. > > > --- >8 ---- > List archives: http://www.xiph.org/archives/ > icecast project homepage: http://www.icecast.org/ > To unsubscribe from this list, send a message to > 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the > body. No subject is needed. Unsubscribe messages sent to the list will > be ignored/filtered.<p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.