http://bugzilla.kernel.org/show_bug.cgi?id=9167
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #34 from [EMAIL PROTECTED] 2008-01-08 01:07 ---
In sum: hpet=disabled did not cause major differences, except the wait
occurring at suspend instead of resume with s2disk. By the way, I also tried
with hpet=disabled
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #35 from [EMAIL PROTECTED] 2008-01-08 01:54 ---
$ cat /proc/cmdline
root=/dev/sda1 ro vga=791 printk.time=Y hpet=disabled nohz=off
$ zgrep -e NO_HZ -e HIGH_RES -e HPET /proc/config.gz
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
http://bugzilla.kernel.org/show_bug.cgi?id=8820
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|NEEDINFO
--
Configure bugmail:
http://bugzilla.kernel.org/show_bug.cgi?id=9558
--- Comment #34 from [EMAIL PROTECTED] 2008-01-08 02:19 ---
Hi,
it works perfectly now, thanks a lot!
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #36 from [EMAIL PROTECTED] 2008-01-08 04:01 ---
Apparently I can substitute highres=off with hpet=disabled.
Can you please provide the output of
# cat /proc/timer_list
with hpet=disable on the command line ?
Thanks,
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #37 from [EMAIL PROTECTED] 2008-01-08 04:16 ---
Created an attachment (id=14358)
-- (http://bugzilla.kernel.org/attachment.cgi?id=14358action=view)
Contents of /proc/timer_list; 2.6.24-rc6, hpet=disabled on cmdline
--
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #39 from [EMAIL PROTECTED] 2008-01-08 04:40 ---
Hmm, I notice that the correct syntax is hpet=disable, not hpet=disabled
(with an extra d after disable). I assume, however, that they make no
difference...?
No difference,
http://bugzilla.kernel.org/show_bug.cgi?id=9167
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
http://bugzilla.kernel.org/show_bug.cgi?id=9167
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #40 from [EMAIL PROTECTED] 2008-01-08 05:55 ---
No problems with nolapic_timer!
I tested by doing s2disk, s2ram, s2ram, s2ram, s2disk, s2disk, s2disk; no
problems so far. Need any further info?
--
Configure bugmail:
http://bugzilla.kernel.org/show_bug.cgi?id=9167
--- Comment #36 from [EMAIL PROTECTED] 2008-01-08 05:42 ---
(In reply to comment #34)
I would like to confirm what has been reported by Stephane on 32bit, using
kernel 2.6.22 and 2.6.23. Fans are not controlled by userspace, but they
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #41 from [EMAIL PROTECTED] 2008-01-08 06:51 ---
Can you please provide full boot logs with and without nolapic_timer on the
kernel command line? Please add apic=verbose in both cases.
Thanks,
tglx
--
Configure
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #42 from [EMAIL PROTECTED] 2008-01-08 07:12 ---
Can you please provide full boot logs with and without nolapic_timer on the
kernel command line? Please add apic=verbose in both cases.
I try to collect the info we have so
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #43 from [EMAIL PROTECTED] 2008-01-08 07:55 ---
Created an attachment (id=14360)
-- (http://bugzilla.kernel.org/attachment.cgi?id=14360action=view)
Bootlog with nolapic_timer on the cmdline; 2.6.24-rc6
--
Configure
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #44 from [EMAIL PROTECTED] 2008-01-08 07:55 ---
Created an attachment (id=14361)
-- (http://bugzilla.kernel.org/attachment.cgi?id=14361action=view)
Bootlog without nolapic_timer on the cmdline; 2.6.24-rc6
--
Configure
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #45 from [EMAIL PROTECTED] 2008-01-08 08:28 ---
1.) If you only do s2ram, then the problem never happens
Yes. I haven't tried this with all different options, but I have noticed
anything different either.
2.) It's never
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #46 from [EMAIL PROTECTED] 2008-01-08 08:38 ---
On Tue, 8 Jan 2008, [EMAIL PROTECTED] wrote:
3.) Problem goes away with one of the following command line option combos:
A) nohz=off highres=off
B) hpet=disable
http://bugzilla.kernel.org/show_bug.cgi?id=9341
--- Comment #10 from [EMAIL PROTECTED] 2008-01-08 09:17 ---
Created an attachment (id=14364)
-- (http://bugzilla.kernel.org/attachment.cgi?id=14364action=view)
Clear return value from space handler
Please check if this patch helps.
http://bugzilla.kernel.org/show_bug.cgi?id=9528
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|NEEDINFO
Summary|s2ram on
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #65 from [EMAIL PROTECTED] 2008-01-08 10:15 ---
also...
The reason that I don't think reverting Linux to ACPI 1.0
suspend order is the ultimate solution is because we'll
still be exposed to a hang if the USB were suspended
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #67 from [EMAIL PROTECTED] 2008-01-08 10:40 ---
Unless you're referring to autosuspend putting the USB device into D3?
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #66 from [EMAIL PROTECTED] 2008-01-08 10:30 ---
Created an attachment (id=14365)
-- (http://bugzilla.kernel.org/attachment.cgi?id=14365action=view)
/proc/acpi/wakeup from Abit KN9
Len - Please read the earlier comments
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #69 from [EMAIL PROTECTED] 2008-01-08 12:39 ---
Carlos, please
# echo USB0 /proc/acpi/wakeup
# echo USB2 /proc/acpi/wakeup
see if those lines in the wakeup file change to enabled from disabled
and see if that has any
http://bugzilla.kernel.org/show_bug.cgi?id=9528
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #47 from [EMAIL PROTECTED] 2008-01-08 13:26 ---
(In reply to comment #46)
And in all cases you can continue by pressing keys - if I understand
correctly it needs to be some special function key, right ?
No, only in the
http://bugzilla.kernel.org/show_bug.cgi?id=9313
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|
http://bugzilla.kernel.org/show_bug.cgi?id=9663
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--
Configure
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #48 from [EMAIL PROTECTED] 2008-01-08 13:29 ---
(In reply to comment #47)
(In reply to comment #46)
After that the kernel works fine (no strange behaviour, slowness, ...) ?
I meant to say - in general, no, but I don't
http://bugzilla.kernel.org/show_bug.cgi?id=9341
--- Comment #11 from [EMAIL PROTECTED] 2008-01-08 13:54 ---
Unfortunately, this patch doesn't fix the problem. Please find the result of
several consecutive cat /sys/class/power_supply/BAT1/* below. The AC adapter
was disconnected all
http://bugzilla.kernel.org/show_bug.cgi?id=9163
--- Comment #49 from [EMAIL PROTECTED] 2008-01-08 13:46 ---
After that the kernel works fine (no strange behaviour, slowness, ...) ?
I meant to say - in general, no, but I don't tax this box very much, so I
might
have missed
http://bugzilla.kernel.org/show_bug.cgi?id=9663
--- Comment #13 from [EMAIL PROTECTED] 2008-01-08 14:25 ---
Hi !
Apologies for my late reply.
I checked these builds now:
2.6.23-acpi.git (~ Sep 07) with _and_ without acpi=off - WORKS
2.6.24-rc6 from git with no cmdline-option -
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: crash loading acpi_cpufreq
https://bugzilla.redhat.com/show_bug.cgi?id=258641
[EMAIL PROTECTED] changed:
What|Removed |Added
http://bugzilla.kernel.org/show_bug.cgi?id=9663
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
Configure bugmail:
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #71 from [EMAIL PROTECTED] 2008-01-08 14:23 ---
(In reply to comment #69)
Carlos, please
# echo USB0 /proc/acpi/wakeup
# echo USB2 /proc/acpi/wakeup
see if those lines in the wakeup file change to enabled from disabled
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #72 from [EMAIL PROTECTED] 2008-01-08 14:39 ---
ACPI 1.0b doesn't make this so clear, but the comment in section 7.2.5 (_S0D):
This particular method is redundant since the device must support D0 while in
the S0 state.
http://bugzilla.kernel.org/show_bug.cgi?id=9663
--- Comment #15 from [EMAIL PROTECTED] 2008-01-08 15:22 ---
I also trid to start with acpi=off command and nothing happen! Mo over stops to
work all fn keys!
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
http://bugzilla.kernel.org/show_bug.cgi?id=8853
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--
Configure
http://bugzilla.kernel.org/show_bug.cgi?id=9663
--- Comment #14 from [EMAIL PROTECTED] 2008-01-08 15:02 ---
So I have mentioned one interesting thing
For keyboard we have such sequence:
drivers/input/serio/i8042.c:
static irqreturn_t i8042_interrupt(int irq, void *dev_id)
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: crash loading acpi_cpufreq
https://bugzilla.redhat.com/show_bug.cgi?id=258641
--- Additional Comments From [EMAIL PROTECTED] 2008-01-08 18:33 EST ---
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: crash loading acpi_cpufreq
https://bugzilla.redhat.com/show_bug.cgi?id=258641
[EMAIL PROTECTED] changed:
What|Removed |Added
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #73 from [EMAIL PROTECTED] 2008-01-08 15:55 ---
Len,
(In reply to comment #69)
Carlos, please
# echo USB0 /proc/acpi/wakeup
# echo USB2 /proc/acpi/wakeup
see if those lines in the wakeup file change to enabled from
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #74 from [EMAIL PROTECTED] 2008-01-08 16:10 ---
(In reply to comment #73)
Len,
(In reply to comment #69)
The offending device is USB0, which, as the DSDT points out, can, on XP or
above, be put into D3.
IMO the DSDT
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #75 from [EMAIL PROTECTED] 2008-01-08 16:31 ---
The ACPI 1.0b spec (page 200) says that _SxD specifies the highest D-state you
can go into for any given device when switching to state x, and that the OS is
free to choose a
http://bugzilla.kernel.org/show_bug.cgi?id=9663
--- Comment #16 from [EMAIL PROTECTED] 2008-01-08 16:31 ---
Test on 2.6.24-rc7: acpi=off Works !
2.6.24-rc7: no cmdline doesn't work ...
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #76 from [EMAIL PROTECTED] 2008-01-08 16:53 ---
(In reply to comment #75)
The ACPI 1.0b spec (page 200) says that _SxD specifies the highest D-state you
can go into for any given device when switching to state x, and that
http://bugzilla.kernel.org/show_bug.cgi?id=9700
--- Comment #6 from [EMAIL PROTECTED] 2008-01-08 17:15 ---
Thanks Len Brown, report in:
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/180678
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
---
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #78 from [EMAIL PROTECTED] 2008-01-08 17:17 ---
(In reply to comment #77)
That's how I read it as well, so I agree (I think any confusion boils down to
lower power state = higher D-state value) - this really hasn't changed
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #79 from [EMAIL PROTECTED] 2008-01-08 17:24 ---
To check on Windows; in 'Device Manager', for each of the devices named 'USB
Root Hub' (there are two listed on the Abit KN9), check their 'Power
Management' tab and see if the
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #77 from [EMAIL PROTECTED] 2008-01-08 17:08 ---
That's how I read it as well, so I agree (I think any confusion boils down to
lower power state = higher D-state value) - this really hasn't changed at all.
Basically, the
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #80 from [EMAIL PROTECTED] 2008-01-08 17:48 ---
I've now had a report from someone with a Shuttle SN25P (also running Vista)
that has an nForce 4 chipset, and Windows has also not enabled USB autosuspend
on that either.
So
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #81 from [EMAIL PROTECTED] 2008-01-08 19:10 ---
Carlos,
thanks for clarifying that unloading ohci (USB0)
makes the hang go away, and that unloading ehci (USB2)
has no effect on the problem at hand.
re: comment #71 and
http://bugzilla.kernel.org/show_bug.cgi?id=7829
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||acpi-
|
http://bugzilla.kernel.org/show_bug.cgi?id=8246
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|no acpi interrupts - battery|no acpi interrupts - IBM
http://bugzilla.kernel.org/show_bug.cgi?id=9528
--- Comment #83 from [EMAIL PROTECTED] 2008-01-08 20:11 ---
Well, by 'get into the tree' I mean having them in whichever branch goes up to
2.6.25 (since I see they're already in the suspend branch... I really shouldn't
be replying to
http://bugzilla.kernel.org/show_bug.cgi?id=9684
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugzilla.kernel.org/show_bug.cgi?id=9663
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #17 from
http://bugzilla.kernel.org/show_bug.cgi?id=9642
--- Comment #25 from [EMAIL PROTECTED] 2008-01-08 21:06 ---
re: comment #12
True that the DSDT invokes OSI.
However, it doesn't invoke OSI(Linux), which is why acpi_osi=!Linux is a NOP
on this system.
Sergio, if you boot with cmdline
http://bugzilla.kernel.org/show_bug.cgi?id=9277
--- Comment #14 from [EMAIL PROTECTED] 2008-01-08 21:21 ---
patch in comment #11 applied to acpi test
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
http://bugzilla.kernel.org/show_bug.cgi?id=9663
--- Comment #18 from [EMAIL PROTECTED] 2008-01-08 22:16 ---
Hmmm, my Laptop was affected by this my eth0 died issue between 2.6.24-rc2
and 2.6.24-rc5. Any Idea how i could exclude the problematic section ?
Hmmm or i could use a
http://bugzilla.kernel.org/show_bug.cgi?id=6001
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
http://bugzilla.kernel.org/show_bug.cgi?id=9313
--- Comment #43 from [EMAIL PROTECTED] 2008-01-08 22:49 ---
I looked at Bug 9528 and the same things happened to Carlos Corbacho. Same (or
very similar) chipset, unloading ohci module makes the error go away.
Please, could you tell
http://bugzilla.kernel.org/show_bug.cgi?id=8674
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|NEEDINFO
--
Configure bugmail:
http://bugzilla.kernel.org/show_bug.cgi?id=8734
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||acpi-
|
http://bugzilla.kernel.org/show_bug.cgi?id=8246
--- Comment #21 from [EMAIL PROTECTED] 2008-01-08 23:52 ---
Created an attachment (id=14376)
-- (http://bugzilla.kernel.org/attachment.cgi?id=14376action=view)
2.6.23-rc6 SMP i686 (cmdline: ro ec_intr=0 noapic) acpidump (Version
http://bugzilla.kernel.org/show_bug.cgi?id=8757
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED]
http://bugzilla.kernel.org/show_bug.cgi?id=8757
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|
http://bugzilla.kernel.org/show_bug.cgi?id=8246
--- Comment #22 from [EMAIL PROTECTED] 2008-01-08 23:54 ---
I have attached another acpidump output using pmtools-20071116.tar.gz. (It's
the same Thinkpad R51e A8043.)
--
Configure bugmail:
68 matches
Mail list logo
