On Sat, Feb 12, 2005 at 04:50:23PM +, Christian Heim wrote:
> Well, i have to setup ISDN here at home, and wanted to use both channels.
> I am able to add the second channel, but then the kernel (at least i think)
> starts to complain.
>
> >17:36:22 kraftwerk Badness in local_bh_enable at
On Sat, Feb 12, 2005 at 04:50:23PM +, Christian Heim wrote:
Well, i have to setup ISDN here at home, and wanted to use both channels.
I am able to add the second channel, but then the kernel (at least i think)
starts to complain.
17:36:22 kraftwerk Badness in local_bh_enable at
Well, i have to setup ISDN here at home, and wanted to use both channels.
I am able to add the second channel, but then the kernel (at least i think)
starts to complain.
>17:36:22 kraftwerk Badness in local_bh_enable at kernel/softirq.c:140
>17:36:22 kraftwerk [] local_bh_enable+0x71/0x80
Well, i have to setup ISDN here at home, and wanted to use both channels.
I am able to add the second channel, but then the kernel (at least i think)
starts to complain.
17:36:22 kraftwerk Badness in local_bh_enable at kernel/softirq.c:140
17:36:22 kraftwerk [c011b201] local_bh_enable+0x71/0x80
On a 12-way IA64, with ext3 filesystem on an Ramdisk, when attempting
to run the disk I/O load of OSDL's aim-7 benchmark, I see an oops when
the multiprogramming level reaches around 200.
Turning on CONFIG_JBD_DEBUG shows:
Assertion failure in __journal_file_buffer() at
aurelien francillon wrote:
> CONFIG_ACPI_DEBUG=y
This one is also bad for you. If you unset this, it will even run fast
even without the object cache (i'm recompiling right now with object
cache _and_ unset debug to see what i can gain from this :-)
Maybe a patch like the attached one for the
aurelien francillon wrote:
CONFIG_ACPI_DEBUG=y
This one is also bad for you. If you unset this, it will even run fast
even without the object cache (i'm recompiling right now with object
cache _and_ unset debug to see what i can gain from this :-)
Maybe a patch like the attached one for the
On a 12-way IA64, with ext3 filesystem on an Ramdisk, when attempting
to run the disk I/O load of OSDL's aim-7 benchmark, I see an oops when
the multiprogramming level reaches around 200.
Turning on CONFIG_JBD_DEBUG shows:
Assertion failure in __journal_file_buffer() at
Stefan Seyfried wrote:
aurelien francillon wrote:
hi,
since just before linux-2.6.11-rc3 ( i think it's rc2-bk10 ) there
seems to have a bug in the acpi part of the proc file system :
reading /proc/acpi/battery/BAT0/info takes a very long time and locks
up the computer, time gives:
cat /proc
aurelien francillon wrote:
> hi,
> since just before linux-2.6.11-rc3 ( i think it's rc2-bk10 ) there
> seems to have a bug in the acpi part of the proc file system :
> reading /proc/acpi/battery/BAT0/info takes a very long time and locks
> up the computer, time gives:
> cat
On Monday 07 February 2005 17:56, Jeffrey E. Hundstad wrote:
> Anders Saaby wrote:
> >Is this system running SMP og UP?
>
> UP
Ouch OK. Then I at least haven't seen it before.
--
Med venlig hilsen - Best regards - Meilleures salutations
Anders Saaby
Systems Engineer
On Monday 07 February 2005 17:56, Jeffrey E. Hundstad wrote:
Anders Saaby wrote:
Is this system running SMP og UP?
UP
Ouch OK. Then I at least haven't seen it before.
--
Med venlig hilsen - Best regards - Meilleures salutations
Anders Saaby
Systems Engineer
aurelien francillon wrote:
hi,
since just before linux-2.6.11-rc3 ( i think it's rc2-bk10 ) there
seems to have a bug in the acpi part of the proc file system :
reading /proc/acpi/battery/BAT0/info takes a very long time and locks
up the computer, time gives:
cat /proc/acpi/battery/BAT0
Stefan Seyfried wrote:
aurelien francillon wrote:
hi,
since just before linux-2.6.11-rc3 ( i think it's rc2-bk10 ) there
seems to have a bug in the acpi part of the proc file system :
reading /proc/acpi/battery/BAT0/info takes a very long time and locks
up the computer, time gives:
cat /proc
There are some corrections for my message... Sorry.
At Tue, 08 Feb 2005 12:53:29 +0900,
SATOH Fumiyasu wrote:
> Host3:
> --
> OS: Debian GNU/Linux testing version (sarge)
> Kernel: kernel-image-2.6.10-1-686-smp
> (compiled by gcc version 3.3.5 (Debian 1:3.3.5-6))
> Filesystem: /
At Mon, 07 Feb 2005 09:38:28 -0600,
Jeffrey E. Hundstad wrote:
> I'm sorry for this truncated report... but it's all I've got. If you
> need .config or system configuration, etc. let me know and I'll send'em
> ASAP. I don't believe this is hardware related; ide-smart shows all fine.
>
> From
Anders Saaby wrote:
Is this system running SMP og UP?
On Monday 07 February 2005 16:38, Jeffrey E. Hundstad wrote:
I'm sorry for this truncated report... but it's all I've got. If you
need .config or system configuration, etc. let me know and I'll send'em
ASAP. I don't believe this is
Is this system running SMP og UP?
On Monday 07 February 2005 16:38, Jeffrey E. Hundstad wrote:
> I'm sorry for this truncated report... but it's all I've got. If you
> need .config or system configuration, etc. let me know and I'll send'em
> ASAP. I don't believe this is hardware related;
I'm sorry for this truncated report... but it's all I've got. If you
need .config or system configuration, etc. let me know and I'll send'em
ASAP. I don't believe this is hardware related; ide-smart shows all fine.
From dmesg:
xfs_da_do_buf: bno 8388608
dir: inode 117526252
Filesystem "hda4":
hi,
since just before linux-2.6.11-rc3 ( i think it's rc2-bk10 ) there
seems to have a bug in the acpi part of the proc file system :
reading /proc/acpi/battery/BAT0/info takes a very long time and locks
up the computer, time gives:
cat /proc/acpi/battery/BAT0/info 0.00s user 6.76s system 12030
hi,
since just before linux-2.6.11-rc3 ( i think it's rc2-bk10 ) there
seems to have a bug in the acpi part of the proc file system :
reading /proc/acpi/battery/BAT0/info takes a very long time and locks
up the computer, time gives:
cat /proc/acpi/battery/BAT0/info 0.00s user 6.76s system 12030
I'm sorry for this truncated report... but it's all I've got. If you
need .config or system configuration, etc. let me know and I'll send'em
ASAP. I don't believe this is hardware related; ide-smart shows all fine.
From dmesg:
xfs_da_do_buf: bno 8388608
dir: inode 117526252
Filesystem hda4:
Is this system running SMP og UP?
On Monday 07 February 2005 16:38, Jeffrey E. Hundstad wrote:
I'm sorry for this truncated report... but it's all I've got. If you
need .config or system configuration, etc. let me know and I'll send'em
ASAP. I don't believe this is hardware related;
Anders Saaby wrote:
Is this system running SMP og UP?
On Monday 07 February 2005 16:38, Jeffrey E. Hundstad wrote:
I'm sorry for this truncated report... but it's all I've got. If you
need .config or system configuration, etc. let me know and I'll send'em
ASAP. I don't believe this is
At Mon, 07 Feb 2005 09:38:28 -0600,
Jeffrey E. Hundstad wrote:
I'm sorry for this truncated report... but it's all I've got. If you
need .config or system configuration, etc. let me know and I'll send'em
ASAP. I don't believe this is hardware related; ide-smart shows all fine.
From
There are some corrections for my message... Sorry.
At Tue, 08 Feb 2005 12:53:29 +0900,
SATOH Fumiyasu wrote:
Host3:
--
OS: Debian GNU/Linux testing version (sarge)
Kernel: kernel-image-2.6.10-1-686-smp
(compiled by gcc version 3.3.5 (Debian 1:3.3.5-6))
Filesystem: / (/dev/md0
sadely.
I have the same problem, but on x86, the attached patch fixed it for me.
--- linux-2.6.11-rc3/drivers/media/video/tda9887.c
+++ linux-2.6.11-rc3/drivers/media/video/tda9887.c
@@ -545,19 +553,21 @@
int rc;
memset(buf
-2.6.11-rc3/drivers/media/video/tda9887.c
+++ linux-2.6.11-rc3/drivers/media/video/tda9887.c
@@ -545,19 +553,21 @@
int rc;
memset(buf,0,sizeof(buf));
+ tda9887_set_tvnorm(t,buf);
buf[1] |= cOutputPort1Inactive;
buf[1] |= cOutputPort2Inactive;
- tda9887_set_tvnorm(t,buf);
if (UNSET != t
-2.6.11-rc3/drivers/media/video/tda9887.c
+++ linux-2.6.11-rc3/drivers/media/video/tda9887.c
@@ -545,19 +553,21 @@
int rc;
memset(buf,0,sizeof(buf));
+ tda9887_set_tvnorm(t,buf);
buf[1] |= cOutputPort1Inactive;
buf[1] |= cOutputPort2Inactive;
- tda9887_set_tvnorm(t,buf);
if (UNSET != t
sadely.
I have the same problem, but on x86, the attached patch fixed it for me.
--- linux-2.6.11-rc3/drivers/media/video/tda9887.c
+++ linux-2.6.11-rc3/drivers/media/video/tda9887.c
@@ -545,19 +553,21 @@
int rc;
memset(buf
Hello,
I am having the same kind of troubles (can't tune and mt_set_frequency
-121 errors) since 2.6.10 (it was working in 2.6.9) on amd64.
this patch did not help sadely.
log files attached if you have time to look at them :) (the non-working
one being 2.6.11-rc3+your patch)
Cheers,
Mik
Gerd
On Thu, 2005-02-03 at 12:30 +0100, Gerd Knorr wrote:
> Thanks, seems to be a initialization order bug which changes the default
> state of the tda9887 output ports. The patch below should fix that.
Everything is working fine now. Thank you.
__
Markus
-
To unsubscribe from this list: send the
> > > mt2032_set_if_freq failed with -121
>
> OK here you go.
Thanks, seems to be a initialization order bug which changes the default
state of the tda9887 output ports. The patch below should fix that.
Gerd
diff -u linux-2.6.11/drivers/media/video/tda9887.c
On Thu, 2005-02-03 at 11:17 +0100, Gerd Knorr wrote:
> > tuner: chip found at addr 0xc0 i2c-bus bt878 #0 [sw]
> > tuner: type set to 33 (MT20xx universal) by bt878 #0 [sw]
> > tuner: microtune: companycode=4d54 part=04 rev=04
> > tuner: microtune MT2032 found, OK
> > tda9885/6/7: chip found @
Markus Trippelsdorf <[EMAIL PROTECTED]> writes:
> tuner: chip found at addr 0xc0 i2c-bus bt878 #0 [sw]
> tuner: type set to 33 (MT20xx universal) by bt878 #0 [sw]
> tuner: microtune: companycode=4d54 part=04 rev=04
> tuner: microtune MT2032 found, OK
> tda9885/6/7: chip found @ 0x86
> ...
>
Markus Trippelsdorf [EMAIL PROTECTED] writes:
tuner: chip found at addr 0xc0 i2c-bus bt878 #0 [sw]
tuner: type set to 33 (MT20xx universal) by bt878 #0 [sw]
tuner: microtune: companycode=4d54 part=04 rev=04
tuner: microtune MT2032 found, OK
tda9885/6/7: chip found @ 0x86
...
On Thu, 2005-02-03 at 11:17 +0100, Gerd Knorr wrote:
tuner: chip found at addr 0xc0 i2c-bus bt878 #0 [sw]
tuner: type set to 33 (MT20xx universal) by bt878 #0 [sw]
tuner: microtune: companycode=4d54 part=04 rev=04
tuner: microtune MT2032 found, OK
tda9885/6/7: chip found @ 0x86
...
mt2032_set_if_freq failed with -121
OK here you go.
Thanks, seems to be a initialization order bug which changes the default
state of the tda9887 output ports. The patch below should fix that.
Gerd
diff -u linux-2.6.11/drivers/media/video/tda9887.c
linux/drivers/media/video/tda9887.c
On Thu, 2005-02-03 at 12:30 +0100, Gerd Knorr wrote:
Thanks, seems to be a initialization order bug which changes the default
state of the tda9887 output ports. The patch below should fix that.
Everything is working fine now. Thank you.
__
Markus
-
To unsubscribe from this list: send the
Hello,
I am having the same kind of troubles (can't tune and mt_set_frequency
-121 errors) since 2.6.10 (it was working in 2.6.9) on amd64.
this patch did not help sadely.
log files attached if you have time to look at them :) (the non-working
one being 2.6.11-rc3+your patch)
Cheers,
Mik
Gerd
On Wed, 2005-02-02 at 18:35 -0800, Linus Torvalds wrote:
> I'd _really_ like to calm down for a final 2.6.11 now, so please note
> anything really important I missed, but keep the rest pending. And give
> this a good testing..
...
> Gerd Knorr:
> o video/arv: remove casts
> o video/w9966:
Add 'f_maxcount' to allow filesystems to set a per-file maximum IO
size
o Fix permissions on drivers/scsi/a100u2w.c
o Linux 2.6.11-rc3
Manish Lachwani:
o kobject build fix
Marc Singer:
o [ARM PATCH] 2442/1: Simplifying NODES_SHIFT
Marcel Holtmann:
o [Bluetooth] Use wait_event_interrupt
/a100u2w.c
o Linux 2.6.11-rc3
Manish Lachwani:
o kobject build fix
Marc Singer:
o [ARM PATCH] 2442/1: Simplifying NODES_SHIFT
Marcel Holtmann:
o [Bluetooth] Use wait_event_interruptible_timeout()
o [Bluetooth] Use wait_event_timeout()
o [Bluetooth] Fix too many keys pressed error
o
On Wed, 2005-02-02 at 18:35 -0800, Linus Torvalds wrote:
I'd _really_ like to calm down for a final 2.6.11 now, so please note
anything really important I missed, but keep the rest pending. And give
this a good testing..
...
Gerd Knorr:
o video/arv: remove casts
o video/w9966: remove
44 matches
Mail list logo
