This commit broke my master volume control:
5d5d3bc3eddf2ad97b2cb090b92580e7fed6cee1 is first bad commit
commit 5d5d3bc3eddf2ad97b2cb090b92580e7fed6cee1
Author: Ivan N. Zlatev <[EMAIL PROTECTED]>
Date: Tue May 29 16:03:00 2007 +0200
[ALSA] hda-codec - Fix pin configs for Intel Macs
*
This commit broke my master volume control:
5d5d3bc3eddf2ad97b2cb090b92580e7fed6cee1 is first bad commit
commit 5d5d3bc3eddf2ad97b2cb090b92580e7fed6cee1
Author: Ivan N. Zlatev [EMAIL PROTECTED]
Date: Tue May 29 16:03:00 2007 +0200
[ALSA] hda-codec - Fix pin configs for Intel Macs
*
Stephen Hemminger schrieb:
> Thomas Meyer <[EMAIL PROTECTED]> wrote:
>
>
>> Today i did a git pull to be up to date again and i noticed in the
>> powertop tool that i'll get this new entry
>>
>> 14,2% ( 9,1) : sky2_probe (sky2_idle)
>>
>
Stephen Hemminger schrieb:
Thomas Meyer [EMAIL PROTECTED] wrote:
Today i did a git pull to be up to date again and i noticed in the
powertop tool that i'll get this new entry
14,2% ( 9,1) kernel core : sky2_probe (sky2_idle)
with around 10 interrupts per second.
i think (i.e
Original-Nachricht
Hi.
Today i did a git pull to be up to date again and i noticed in the
powertop tool that i'll get this new entry
14,2% ( 9,1) : sky2_probe (sky2_idle)
with around 10 interrupts per second.
i think (i.e. i don't know and just guessing!) this commit
Original-Nachricht
Hi.
Today i did a git pull to be up to date again and i noticed in the
powertop tool that i'll get this new entry
14,2% ( 9,1) kernel core : sky2_probe (sky2_idle)
with around 10 interrupts per second.
i think (i.e. i don't know and just guessing!)
head: f653c34dd3d8bde2c918316fd5ba2e2c4f95afcf
May 15 23:02:07 [kernel] BUG: at include/linux/slub_def.h:89 kmalloc_index()
May 15 23:02:07 [kernel] [] get_slab+0x43/0x1cc
May 15 23:02:07 [kernel] [] usb_get_configuration+0x93f/0xd06
[usbcore]
May 15 23:02:07 [kernel] []
head: f653c34dd3d8bde2c918316fd5ba2e2c4f95afcf
May 15 23:02:07 [kernel] BUG: at include/linux/slub_def.h:89 kmalloc_index()
May 15 23:02:07 [kernel] [c015fc10] get_slab+0x43/0x1cc
May 15 23:02:07 [kernel] [f934b101] usb_get_configuration+0x93f/0xd06
[usbcore]
May 15 23:02:07 [kernel]
With current git head from linus' tree
and LOCALVERSION_AUTO [=y] and USB_APPLETOUCH [=m]
find /lib/modules/ -name apple*
/lib/modules/2.6.20/kernel/drivers/usb/input/appletouch.ko
/lib/modules/2.6.21/kernel/drivers/usb/input/appletouch.ko
uname -a
Linux hotzenplotz 2.6.21-gdc87c398
Any ideas?
With current git head from linus' tree
and LOCALVERSION_AUTO [=y] and USB_APPLETOUCH [=m]
find /lib/modules/ -name apple*
/lib/modules/2.6.20/kernel/drivers/usb/input/appletouch.ko
/lib/modules/2.6.21/kernel/drivers/usb/input/appletouch.ko
uname -a
Linux hotzenplotz 2.6.21-gdc87c398
Any ideas?
Thomas Gleixner schrieb:
> On Sat, 2007-04-28 at 18:27 +0200, Michal Piotrowski wrote:
>
>> Subject: Bad interaction between dynticks and amarok?
>> References : http://lkml.org/lkml/2007/4/26/307
>> Submitter : Thomas Meyer <[EMAIL PROTECTED]>
>> St
Michal Piotrowski schrieb:
> Subject: Bad interaction between dynticks and amarok?
> References : http://lkml.org/lkml/2007/4/26/307
> Submitter : Thomas Meyer <[EMAIL PROTECTED]>
> Status : Unknow
>
>
Please remove this from the regression list. This seems
Michal Piotrowski schrieb:
Subject: Bad interaction between dynticks and amarok?
References : http://lkml.org/lkml/2007/4/26/307
Submitter : Thomas Meyer [EMAIL PROTECTED]
Status : Unknow
Please remove this from the regression list. This seems to be an
userspace only problem
Thomas Gleixner schrieb:
On Sat, 2007-04-28 at 18:27 +0200, Michal Piotrowski wrote:
Subject: Bad interaction between dynticks and amarok?
References : http://lkml.org/lkml/2007/4/26/307
Submitter : Thomas Meyer [EMAIL PROTECTED]
Status : Unknow
Michal,
I don't think
Hi.
here a vmstat of my laptop with my favorite song player amarok running
and not running:
procs ---memory-- ---swap-- -io -system--
cpu
r b swpd free buff cache si sobibo in cs us sy
id wa
0 0 0 39476 62640 64102800
Hi.
here a vmstat of my laptop with my favorite song player amarok running
and not running:
procs ---memory-- ---swap-- -io -system--
cpu
r b swpd free buff cache si sobibo in cs us sy
id wa
0 0 0 39476 62640 64102800
The kexec-tools check for "System RAM".
diff --git a/arch/i386/kernel/efi.c b/arch/i386/kernel/efi.c
index 8f9c624..307156d 100644
--- a/arch/i386/kernel/efi.c
+++ b/arch/i386/kernel/efi.c
@@ -638,8 +638,13 @@ efi_initialize_iomem_resources(struct resource
*code_resource,
res->name =
The kexec-tools check for System RAM.
diff --git a/arch/i386/kernel/efi.c b/arch/i386/kernel/efi.c
index 8f9c624..307156d 100644
--- a/arch/i386/kernel/efi.c
+++ b/arch/i386/kernel/efi.c
@@ -638,8 +638,13 @@ efi_initialize_iomem_resources(struct resource
*code_resource,
res-name =
dmesg output:
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel paging request at virtual address 080e
printing eip:
c015cc98
*pde = 3741d067
*pte =
Oops: [#1]
SMP
Modules linked in: nls_iso8859_15 nls_cp850 vfat fat appletouch dummy
genrtc binfmt_misc tun
dmesg output:
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel paging request at virtual address 080e
printing eip:
c015cc98
*pde = 3741d067
*pte =
Oops: [#1]
SMP
Modules linked in: nls_iso8859_15 nls_cp850 vfat fat appletouch dummy
genrtc binfmt_misc tun
On my pc i encounter a strange error:
the pktsetup is started during system start and set my dvd driver to
packet writing mode. then i insert a dvd movie and start xine. and
sometimes xine says that it can't play the dvd. BUT after
stoping/removing the pktsetup from the dvd drive again, xine plays
On my pc i encounter a strange error:
the pktsetup is started during system start and set my dvd driver to
packet writing mode. then i insert a dvd movie and start xine. and
sometimes xine says that it can't play the dvd. BUT after
stoping/removing the pktsetup from the dvd drive again, xine plays
Dmitry Torokhov schrieb:
> On 3/28/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
>> On Tue, 27 Mar 2007, Thomas Meyer wrote:
>>
>> > It seems, that after the resume all usb devices gets removed and
>> plug in
>> > again (virtually!). This results in a n
Dmitry Torokhov schrieb:
On 3/28/07, Jiri Kosina [EMAIL PROTECTED] wrote:
On Tue, 27 Mar 2007, Thomas Meyer wrote:
It seems, that after the resume all usb devices gets removed and
plug in
again (virtually!). This results in a new input device name:
Yes, this is what actually happens
Adrian Bunk schrieb:
> It's now in Linus' tree.
>
> Thomas (Meyer), are there any regressions left with the latest -git tree
> plus the MSI fix?
>
No, not for me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Jiri Kosina schrieb:
> On Sun, 18 Mar 2007, Thomas Meyer wrote:
>
>
>> Appletouch is bound to the device:
>>
>
> OK, so the quirk actually works fine ...
>
Yes, it works fine, but...
>
>> But the X server touchpad driver doesn't work anymore
Adrian Bunk schrieb:
It's now in Linus' tree.
Thomas (Meyer), are there any regressions left with the latest -git tree
plus the MSI fix?
No, not for me.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
Jiri Kosina schrieb:
On Sun, 18 Mar 2007, Thomas Meyer wrote:
Appletouch is bound to the device:
OK, so the quirk actually works fine ...
Yes, it works fine, but...
But the X server touchpad driver doesn't work anymore, that means i
can't emulte a right click by tapping
Adrian Bunk schrieb:
> On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
>
>> ...
>> The first suspend to disk is ok. The second suspend to disk has a
>> strange behaviour:
>> 1.) write pm image
>> 2.) the system disable the non-boot cpus again (i
Rafael J. Wysocki schrieb:
> On Sunday, 25 March 2007 14:03, Eric W. Biederman wrote:
>
>> Thomas Meyer <[EMAIL PROTECTED]> writes:
>>
>>
>>> Eric W. Biederman schrieb:
>>>
>>>> Thomas could you v
Eric W. Biederman schrieb:
> Sounds possible. You could probably verify it isn't my patch but running
> an unpatched kernel without msi support. As I think the crash you saw should
> only be reproducible when using devices that support msi.
>
Without your patch and with pci=nomsi option the
Eric W. Biederman schrieb:
>
> Thomas could you verify the patch below makes the problem go away
> for you.
>
The patch solves the problem. I'm writing this after the third suspend
and resume cycle.
msi irq stays enabled for libata device:
cat /sys/devices/pci\:00/\:00\:1f.2/irq
218
Eric W. Biederman schrieb:
Thomas could you verify the patch below makes the problem go away
for you.
The patch solves the problem. I'm writing this after the third suspend
and resume cycle.
msi irq stays enabled for libata device:
cat /sys/devices/pci\:00/\:00\:1f.2/irq
218
cat
Eric W. Biederman schrieb:
Sounds possible. You could probably verify it isn't my patch but running
an unpatched kernel without msi support. As I think the crash you saw should
only be reproducible when using devices that support msi.
Without your patch and with pci=nomsi option the same
Rafael J. Wysocki schrieb:
On Sunday, 25 March 2007 14:03, Eric W. Biederman wrote:
Thomas Meyer [EMAIL PROTECTED] writes:
Eric W. Biederman schrieb:
Thomas could you verify the patch below makes the problem go away
for you.
The patch solves the problem. I'm
Adrian Bunk schrieb:
On Sun, Mar 25, 2007 at 01:41:33PM +0200, Thomas Meyer wrote:
...
The first suspend to disk is ok. The second suspend to disk has a
strange behaviour:
1.) write pm image
2.) the system disable the non-boot cpus again (i guess this happens in
power_down())
3
Eric W. Biederman schrieb:
>
> Odd. I would have thought the oops happened in the first resume, not
> the second.
>
> Hmm. It may have something to do with the ``managed'' driver
> aspect of this as well..
>
No. I don't think so. The problem is caused by this sequence: (the info
is always
Eric W. Biederman schrieb:
> Thomas Meyer <[EMAIL PROTECTED]> writes:
>
>
>> Adrian Bunk schrieb:
>>
>>> Subject: second suspend to disk in a row results in an oops (libata?)
>>> References : http://lkml.org/lkml/2007/3/17/43
&g
Adrian Bunk schrieb:
> Subject: second suspend to disk in a row results in an oops (libata?)
> References : http://lkml.org/lkml/2007/3/17/43
> Submitter : Thomas Meyer <[EMAIL PROTECTED]>
> Status : unknown
>
The problem is identified: http://lkml.o
Eric W. Biederman schrieb:
Thomas Meyer [EMAIL PROTECTED] writes:
Adrian Bunk schrieb:
Subject: second suspend to disk in a row results in an oops (libata?)
References : http://lkml.org/lkml/2007/3/17/43
Submitter : Thomas Meyer [EMAIL PROTECTED]
Status : unknown
Adrian Bunk schrieb:
Subject: second suspend to disk in a row results in an oops (libata?)
References : http://lkml.org/lkml/2007/3/17/43
Submitter : Thomas Meyer [EMAIL PROTECTED]
Status : unknown
The problem is identified: http://lkml.org/lkml/2007/3/22/150
-
To unsubscribe
Eric W. Biederman schrieb:
Odd. I would have thought the oops happened in the first resume, not
the second.
Hmm. It may have something to do with the ``managed'' driver
aspect of this as well..
No. I don't think so. The problem is caused by this sequence: (the info
is always before
The commit f5f2b13129a6541debf8851bae843cbbf48298b7 broke suspend/resume
to disk two or more times in a row. This patches fixes the problem:
This patch should be included in 2.6.21
Signed-off-by: Thomas Meyer <[EMAIL PROTECTED]>
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d
The commit f5f2b13129a6541debf8851bae843cbbf48298b7 broke suspend/resume
to disk two or more times in a row. This patches fixes the problem:
This patch should be included in 2.6.21
Signed-off-by: Thomas Meyer [EMAIL PROTECTED]
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d3eab05
Pekka Enberg schrieb:
> On 3/17/07, Thomas Meyer <[EMAIL PROTECTED]> wrote:
>> Hello everybody.
>>
>> I get this bug after suspending to disk twice:
>>
>> http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png
>>
>> This happens with current g
Pekka Enberg schrieb:
On 3/17/07, Thomas Meyer [EMAIL PROTECTED] wrote:
Hello everybody.
I get this bug after suspending to disk twice:
http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png
This happens with current git head
cd05a1f818073a623455a58e756c5b419fc98db9.
If you know a kernel
Jiri Kosina schrieb:
> On Sun, 18 Mar 2007, Adrian Bunk wrote:
>
>
> Thomas, could you please provide more information? Did it ever work for
> you after suspend/resume cycle and it just broke at some point in the
> past, or you are not sure whether it ever worked?
>
I'm not sure whether
This happens with cd05a1f818073a623455a58e756c5b419fc98db9:
BUG: unable to handle kernel NULL pointer dereference at virtual address
00a4
printing eip:
c021ca33
*pde =
Oops: [#1]
SMP
Modules linked in: snd_seq snd_seq_device wlan_wep nls_iso8859_15
nls_cp850 vfat fat appletouch
This happens with cd05a1f818073a623455a58e756c5b419fc98db9:
BUG: unable to handle kernel NULL pointer dereference at virtual address
00a4
printing eip:
c021ca33
*pde =
Oops: [#1]
SMP
Modules linked in: snd_seq snd_seq_device wlan_wep nls_iso8859_15
nls_cp850 vfat fat appletouch
Jiri Kosina schrieb:
On Sun, 18 Mar 2007, Adrian Bunk wrote:
Thomas, could you please provide more information? Did it ever work for
you after suspend/resume cycle and it just broke at some point in the
past, or you are not sure whether it ever worked?
I'm not sure whether this ever
Pekka Enberg schrieb:
> On 3/17/07, Thomas Meyer <[EMAIL PROTECTED]> wrote:
>> Hello everybody.
>>
>> I get this bug after suspending to disk twice:
>>
>> http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png
>>
>> This happens with current g
Hello everybody.
I get this bug after suspending to disk twice:
http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png
This happens with current git head cd05a1f818073a623455a58e756c5b419fc98db9.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Thomas Gleixner schrieb:
> I finally found a dual core box, which survives suspend/resume without
> crashing in the middle of nowhere. Sigh, I never figured out from the
> code and the bug reports what's going on.
>
> The observed hangs are caused by a stale state transition of the clock
> event
Thomas Gleixner schrieb:
I finally found a dual core box, which survives suspend/resume without
crashing in the middle of nowhere. Sigh, I never figured out from the
code and the bug reports what's going on.
The observed hangs are caused by a stale state transition of the clock
event
Hello everybody.
I get this bug after suspending to disk twice:
http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png
This happens with current git head cd05a1f818073a623455a58e756c5b419fc98db9.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Pekka Enberg schrieb:
On 3/17/07, Thomas Meyer [EMAIL PROTECTED] wrote:
Hello everybody.
I get this bug after suspending to disk twice:
http://m3y3r.de/bilder/Bug-pci_restore_msi_state.png
This happens with current git head
cd05a1f818073a623455a58e756c5b419fc98db9.
If you know a kernel
Thomas Gleixner schrieb:
On Sun, 2007-03-11 at 22:09 +0100, Rafael J. Wysocki wrote:
update_sched_domains
detach_destroy_domains
[waits here] --> synchronize_sched (==synchronize_rcu)
Well, I think the call to wait_for_completion() does not return,
Milan Broz schrieb:
Thomas Meyer napsal(a):
Rafael J. Wysocki schrieb:
On Sunday, 11 March 2007 21:23, Milan Broz wrote:
Rafael J. Wysocki:
Ah, NO_HZ. Thomas Gleixner's address added to the Cc list.
short printk trace
enable_nonboot_cpus
Rafael J. Wysocki schrieb:
Okay, but could you please compile the kernel without NO_HZ and retest?
Sure.
But i get the same behaviour:
Mar 11 21:42:07 [kernel] processor ACPI0007:00: freeze
Mar 11 21:42:07 [kernel] button button_power:00: freeze
Mar 11 21:42:07 [kernel] acpi
Rafael J. Wysocki schrieb:
On Sunday, 11 March 2007 21:23, Milan Broz wrote:
Rafael J. Wysocki:
Ah, NO_HZ. Thomas Gleixner's address added to the Cc list.
short printk trace
enable_nonboot_cpus
_cpu_up
raw_notifier_callchain (CPU_UP_PREPARE)
...
Sorry the systems hangs here:
Mar 11 20:55:46 [kernel] CPU 1 is now offline
Mar 11 20:55:46 [kernel] SMP alternatives: switching to UP code
Mar 11 20:55:46 [kernel] PM: Removing info for No Bus:cpu1
Mar 11 20:55:46 [kernel] PM: Removing info for No Bus:msr1
Mar 11 20:55:46 [kernel] CPU1 is down
Milan Broz schrieb:
Rafael J. Wysocki napsal(a):
On Sunday, 11 March 2007 19:08, Thomas Meyer wrote:
Suspend to disk doesn't work on my laptop.
The suspend seems to hang while enabling the non-boot cpus again.
with platform = "test" and state = "disk" i get thi
Rafael J. Wysocki schrieb:
Could you please put some printk()s in kernel/cpu.c:_cpu_up() to see where
it gets stuck? I bet one of the notifiers goes to sleep (cpufreq, maybe).
Here we go (ok. i forgot __FUNCTION__ ...):
Mar 11 19:31:33 [kernel] ac ACPI0003:00: freeze
Mar 11 19:31:33
Suspend to disk doesn't work on my laptop.
The suspend seems to hang while enabling the non-boot cpus again.
with platform = "test" and state = "disk" i get this:
"
[cut]
acpi device:02: freeze
video video:00: freeze
acpi device:01: freeze
acpi PNP0C02:00: freeze
pci_root PNP0A08:00: freeze
Suspend to disk doesn't work on my laptop.
The suspend seems to hang while enabling the non-boot cpus again.
with platform = test and state = disk i get this:
[cut]
acpi device:02: freeze
video video:00: freeze
acpi device:01: freeze
acpi PNP0C02:00: freeze
pci_root PNP0A08:00: freeze
button
Rafael J. Wysocki schrieb:
Could you please put some printk()s in kernel/cpu.c:_cpu_up() to see where
it gets stuck? I bet one of the notifiers goes to sleep (cpufreq, maybe).
Here we go (ok. i forgot __FUNCTION__ ...):
Mar 11 19:31:33 [kernel] ac ACPI0003:00: freeze
Mar 11 19:31:33
Milan Broz schrieb:
Rafael J. Wysocki napsal(a):
On Sunday, 11 March 2007 19:08, Thomas Meyer wrote:
Suspend to disk doesn't work on my laptop.
The suspend seems to hang while enabling the non-boot cpus again.
with platform = test and state = disk i get this:
Hi,
I see
Sorry the systems hangs here:
Mar 11 20:55:46 [kernel] CPU 1 is now offline
Mar 11 20:55:46 [kernel] SMP alternatives: switching to UP code
Mar 11 20:55:46 [kernel] PM: Removing info for No Bus:cpu1
Mar 11 20:55:46 [kernel] PM: Removing info for No Bus:msr1
Mar 11 20:55:46 [kernel] CPU1 is down
Rafael J. Wysocki schrieb:
On Sunday, 11 March 2007 21:23, Milan Broz wrote:
Rafael J. Wysocki:
Ah, NO_HZ. Thomas Gleixner's address added to the Cc list.
short printk trace
enable_nonboot_cpus
_cpu_up
raw_notifier_callchain (CPU_UP_PREPARE)
...
Rafael J. Wysocki schrieb:
Okay, but could you please compile the kernel without NO_HZ and retest?
Sure.
But i get the same behaviour:
Mar 11 21:42:07 [kernel] processor ACPI0007:00: freeze
Mar 11 21:42:07 [kernel] button button_power:00: freeze
Mar 11 21:42:07 [kernel] acpi
Milan Broz schrieb:
Thomas Meyer napsal(a):
Rafael J. Wysocki schrieb:
On Sunday, 11 March 2007 21:23, Milan Broz wrote:
Rafael J. Wysocki:
Ah, NO_HZ. Thomas Gleixner's address added to the Cc list.
short printk trace
enable_nonboot_cpus
Thomas Gleixner schrieb:
On Sun, 2007-03-11 at 22:09 +0100, Rafael J. Wysocki wrote:
update_sched_domains
detach_destroy_domains
[waits here] -- synchronize_sched (==synchronize_rcu)
Well, I think the call to wait_for_completion() does not return,
1.) My kde klaptopdaemon icon is gone. This icon displayed the remaining
battery time. This is maybe a kde problem?
2.) I get these new messages in the kernel log buffer:
[...]
ACPI: bus type pci registered
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI Exception (evregion-0420):
1.) My kde klaptopdaemon icon is gone. This icon displayed the remaining
battery time. This is maybe a kde problem?
2.) I get these new messages in the kernel log buffer:
[...]
ACPI: bus type pci registered
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI Exception (evregion-0420):
with 93bbad8fe13a25dcf7f3bc628a71d1a7642ae61b:
drivers/video/Kconfig:1604:warning: 'select' used by config symbol
'FB_PS3' refer to undefined symbol 'PS3_PS3AV'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
with 93bbad8fe13a25dcf7f3bc628a71d1a7642ae61b:
drivers/video/Kconfig:1604:warning: 'select' used by config symbol
'FB_PS3' refer to undefined symbol 'PS3_PS3AV'
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
Hi.
I have a few of these entries in my log buffer:
vmwrite error: reg 6802 value d19e0464 (err 26626)
[] kvm_mmu_zap_page+0x8f/0x1d7
[] __pagevec_free+0x18/0x22
[] free_mmu_pages+0x10/0x81
[] kvm_mmu_destroy+0x3c/0x56
[] kvm_free_vcpu+0x8/0x15
[] kvm_dev_release+0x13/0x37
[] __fput+0xa5/0x14d
Hi.
I have a few of these entries in my log buffer:
vmwrite error: reg 6802 value d19e0464 (err 26626)
[c02413bf] kvm_mmu_zap_page+0x8f/0x1d7
[c014c2cb] __pagevec_free+0x18/0x22
[c0241517] free_mmu_pages+0x10/0x81
[c02415c4] kvm_mmu_destroy+0x3c/0x56
[c023f3a3] kvm_free_vcpu+0x8/0x15
[c023f429]
I got this OOPS while shuting down my computer in function
shrink_dcache_for_umount_subtree.
For call trace see this picture: m3y3r.de/bilder/img_0359.jpg
I hope somebody can fix this error?!
With kind regards
Thomas
--
-
To unsubscribe from this list: send the line "unsubscribe
I got this OOPS while shuting down my computer in function
shrink_dcache_for_umount_subtree.
For call trace see this picture: m3y3r.de/bilder/img_0359.jpg
I hope somebody can fix this error?!
With kind regards
Thomas
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Len Brown schrieb:
The bigger question is why you get "tons of these" --
as EC events are usually infrequent.
Do you have a big number next to "acpi" in /proc/interrupts?
If so, at what rate is it growing?
maybe tons were a bit to overstated... After a fresh reboot, i count 110
_q10 and
Vivek Goyal schrieb:
What's your ld version. I don't remember but some particular versions
of ld will have this problem. These ld versions do some optimizations
and if a section size is zero then linker gets rid of that section and
any symbol defined w.r.t removed section, ld makes that symbol
Len Brown schrieb:
The bigger question is why you get "tons of these" --
as EC events are usually infrequent.
Do you have a big number next to "acpi" in /proc/interrupts?
If so, at what rate is it growing?
thanks,
-Len
maybe tons were a bit to overstated... After a fresh reboot, i count 110
Len Brown schrieb:
The bigger question is why you get tons of these --
as EC events are usually infrequent.
Do you have a big number next to acpi in /proc/interrupts?
If so, at what rate is it growing?
thanks,
-Len
maybe tons were a bit to overstated... After a fresh reboot, i count 110
Len Brown schrieb:
The bigger question is why you get tons of these --
as EC events are usually infrequent.
Do you have a big number next to acpi in /proc/interrupts?
If so, at what rate is it growing?
maybe tons were a bit to overstated... After a fresh reboot, i count 110
_q10 and one
Vivek Goyal schrieb:
What's your ld version. I don't remember but some particular versions
of ld will have this problem. These ld versions do some optimizations
and if a section size is zero then linker gets rid of that section and
any symbol defined w.r.t removed section, ld makes that symbol
I know this topic was already on the list. But 2.6.20-rc3 still gives me
tons of these messages in the log buffer:
"ACPI: EC: evaluating _Q10
ACPI: EC: evaluating _Q10
ACPI: EC: evaluating _Q10
ACPI: EC: evaluating _Q10
ACPI: EC: evaluating _Q10
[and so on]"
Is this an error at all?
With kind
I know this topic was already on the list. But 2.6.20-rc3 still gives me
tons of these messages in the log buffer:
ACPI: EC: evaluating _Q10
ACPI: EC: evaluating _Q10
ACPI: EC: evaluating _Q10
ACPI: EC: evaluating _Q10
ACPI: EC: evaluating _Q10
[and so on]
Is this an error at all?
With kind
Again current git head:
I guess this should be fixed by someone!
WARNING: "test_clear_page_dirty" [fs/cifs/cifs.ko] undefined!
make[1]: *** [__modpost] Fehler 1
make: *** [modules] Fehler 2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hello.
What kind of problem is this:
1.) the one that should be fixed, but also can be ignored or
2.) the one that have to be fixed and ignorance is a bad idea?
WARNING: vmlinux - Section mismatch: reference to .init.data:boot_params
from .text between '_text' (at offset 0xc0100029) and
Subject: [PATCH] Add .gitignore file for relocs in arch/i386
From: Thomas Meyer <[EMAIL PROTECTED]>
Due the changes to make the kernel relocateable a new file is created
during the build process.
Signed-Off-By: Thomas Meyer <[EMAIL PROTECTED]>
---
This makes my git stauts command
More warnings on current git head:
OBJCOPY arch/i386/boot/compressed/vmlinux.bin
RELOCS arch/i386/boot/compressed/vmlinux.relocs
WARNING: Absolute relocations present
Offset Info Type Sym.Value Sym.Name
c0107bd7 00636601 R_386_32 c034f000 __smp_alt_instructions
c0107bff
More warnings on current git head:
OBJCOPY arch/i386/boot/compressed/vmlinux.bin
RELOCS arch/i386/boot/compressed/vmlinux.relocs
WARNING: Absolute relocations present
Offset Info Type Sym.Value Sym.Name
c0107bd7 00636601 R_386_32 c034f000 __smp_alt_instructions
c0107bff
Subject: [PATCH] Add .gitignore file for relocs in arch/i386
From: Thomas Meyer [EMAIL PROTECTED]
Due the changes to make the kernel relocateable a new file is created
during the build process.
Signed-Off-By: Thomas Meyer [EMAIL PROTECTED]
---
This makes my git stauts command happy again
Hello.
What kind of problem is this:
1.) the one that should be fixed, but also can be ignored or
2.) the one that have to be fixed and ignorance is a bad idea?
WARNING: vmlinux - Section mismatch: reference to .init.data:boot_params
from .text between '_text' (at offset 0xc0100029) and
Again current git head:
I guess this should be fixed by someone!
WARNING: test_clear_page_dirty [fs/cifs/cifs.ko] undefined!
make[1]: *** [__modpost] Fehler 1
make: *** [modules] Fehler 2
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
head: d916faace3efc0bf19fe9a615a1ab8fa1a24cd93
Here a sequential probe, that boots fine:
"
[cut]
ata_piix :00:1f.1: version 2.00ac6
ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device :00:1f.1 to 64
ata1: PATA max UDMA/133 cmd 0x1F0
head: d916faace3efc0bf19fe9a615a1ab8fa1a24cd93
Here a sequential probe, that boots fine:
[cut]
ata_piix :00:1f.1: version 2.00ac6
ACPI: PCI Interrupt :00:1f.1[A] - GSI 18 (level, low) - IRQ 18
PCI: Setting latency timer of device :00:1f.1 to 64
ata1: PATA max UDMA/133 cmd 0x1F0 ctl
601 - 698 of 698 matches
Mail list logo
