Re: [PATCH] platform/x86: sony-laptop: Mark expected switch fall-through
On Fri, Jul 06, 2018 at 04:24:27PM -0700, Darren Hart wrote:
> On Thu, Jul 05, 2018 at 03:47:03PM -0500, Gustavo A. R. Silva wrote:
> > In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> > where we are expecting to fall through.
> >
> > Signed-off-by: Gustavo A. R. Silva
> > ---
> > drivers/platform/x86/sony-laptop.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/platform/x86/sony-laptop.c
> > b/drivers/platform/x86/sony-laptop.c
> > index b205b03..e614cb7 100644
> > --- a/drivers/platform/x86/sony-laptop.c
> > +++ b/drivers/platform/x86/sony-laptop.c
> > @@ -4427,6 +4427,7 @@ sony_pic_read_possible_resource(struct acpi_resource
> > *resource, void *context)
> > default:
> > dprintk("Resource %d isn't an IRQ nor an IO port\n",
> > resource->type);
> > + /* fall through */
>
> Here too, I wonder if this is intentional. Either way, from what I can see,
> the
> final line in the function:
>
> return AE_CTRL_TERMINATE;
>
> Is unreachable as there are no "break" statements in the switch, and the
> default
> falls through to return AE_OK. Something doesn't seem right here.
I think so too. Looks to me that the default case was meant to return
AE_CTRL_TERMINATE (i.e. swapping it to be last would do).
Having written that code aeons ago, I'm not sure if there is a good
reason to be like that, though it still looks like a bug (that
existed ever since...).
Want to fix it as part of this patch series? Or I can send a patch
myself, let me know.
--
mattia
:wq!
Re: [PATCH] platform/x86: sony-laptop: Mark expected switch fall-through
On Fri, Jul 06, 2018 at 04:24:27PM -0700, Darren Hart wrote:
> On Thu, Jul 05, 2018 at 03:47:03PM -0500, Gustavo A. R. Silva wrote:
> > In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> > where we are expecting to fall through.
> >
> > Signed-off-by: Gustavo A. R. Silva
> > ---
> > drivers/platform/x86/sony-laptop.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/platform/x86/sony-laptop.c
> > b/drivers/platform/x86/sony-laptop.c
> > index b205b03..e614cb7 100644
> > --- a/drivers/platform/x86/sony-laptop.c
> > +++ b/drivers/platform/x86/sony-laptop.c
> > @@ -4427,6 +4427,7 @@ sony_pic_read_possible_resource(struct acpi_resource
> > *resource, void *context)
> > default:
> > dprintk("Resource %d isn't an IRQ nor an IO port\n",
> > resource->type);
> > + /* fall through */
>
> Here too, I wonder if this is intentional. Either way, from what I can see,
> the
> final line in the function:
>
> return AE_CTRL_TERMINATE;
>
> Is unreachable as there are no "break" statements in the switch, and the
> default
> falls through to return AE_OK. Something doesn't seem right here.
I think so too. Looks to me that the default case was meant to return
AE_CTRL_TERMINATE (i.e. swapping it to be last would do).
Having written that code aeons ago, I'm not sure if there is a good
reason to be like that, though it still looks like a bug (that
existed ever since...).
Want to fix it as part of this patch series? Or I can send a patch
myself, let me know.
--
mattia
:wq!
Re: [PATCH] sony-laptop: add support for Sony Vaio Fit multi-flip laptop/presentation/tablet transformation
On Fri, Nov 21, 2014 at 10:55:04AM -0800, Darren Hart wrote:
> On Thu, Nov 20, 2014 at 11:51:12AM +0300, Alexander Gavrilenko wrote:
> > Current mode is exported via sysfs:
> > /sys/devices/platform/sony-laptop/tablet
> >
>
> Merging with your reply and a few updates from me, you OK with:
I'll piggy-back on this merged mail for some other comments.
>
> sony-laptop: Support Sony Vaio Fit multi-flip tablet transformations
>
> Transformation events are sent through the ACPI bus as sony/hotkey
> events. Tablet mode also triggers the SW_TABLET_MODE event via the
> Sony Vaio Keys input device.
>
could you send me (privately) the whole DSDT from a Vaio FIT? I think I
found one implementation, is it something like this?
If (LEqual (Local0, 0x0E))
{
And (Local1, 0x03, Local1)
If (LEqual (Local1, Zero))
{
Store (One, ^^EC0.STEN)
Return (Arg0)
}
If (LEqual (Local1, One))
{
Store (Zero, ^^EC0.STEN)
Return (Arg0)
}
If (LEqual (Local1, 0x02))
{
Store (Zero, Local5)
And (^^EC0.MDST, 0x03, Local5)
Return (Local5)
}
}
> Current mode is exported via sysfs:
> /sys/devices/platform/sony-laptop/tablet
>
> It's important to keep the subject under 72 characters or so, or it
> gets truncated for a lot of git users.
>
> > Signed-off-by: Alexander Gavrilenko
> > ---
> > --- linux-3.17.3/drivers/platform/x86/sony-laptop.c.orig2014-11-19
> > 13:15:35.965048636 +0300
> > +++ linux-3.17.3/drivers/platform/x86/sony-laptop.c 2014-11-19
> > 13:17:21.139166837 +0300
> > @@ -135,6 +135,13 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
> > "meaningful values vary from 0 to 3 and their meaning depends "
> > "on the model (default: no change from current value)");
> >
> > +static int tablet_mode = 2;
> > +module_param(tablet_mode, int, 0);
> > +MODULE_PARM_DESC(tablet_mode,
> > +"set this if your laptop have different tablet mode value, "
>
> s/have/has a/
>
> Generally speaking module params requied for normal usage a frowned upon.
>
> This looks like something we should be able to detect by the HID or at worst
> the
> DMI strings. Maybe I'm missing something, why is this needed?
I'd agree this parameter is unnecessary at the moment. In many cases,
different implementations of the same functionality end up having a
different handle (0x16f in this case). You may be able to use different
values based on that.
Also, how many other tablet_mode values are known so far? If only "2" then
I wouldn't bother using this module parameter.
...
> > +"default is 2 (Sony Vaio Fit multi-flip), "
> > +"only affects SW_TABLET_MODE events");
> > +
> > #ifdef CONFIG_PM_SLEEP
> > static void sony_nc_thermal_resume(void);
> > #endif
> > @@ -181,6 +188,11 @@ static int sony_nc_touchpad_setup(struct
> > unsigned int handle);
> > static void sony_nc_touchpad_cleanup(struct platform_device *pd);
> >
> > +static int sony_nc_tablet_mode_setup(struct platform_device *pd,
> > + unsigned int handle);
> > +static void sony_nc_tablet_mode_cleanup(struct platform_device *pd);
> > +static int sony_nc_tablet_mode_update(void);
> > +
> > enum sony_nc_rfkill {
> > SONY_WIFI,
> > SONY_BLUETOOTH,
> > @@ -1198,7 +1210,8 @@ static int sony_nc_hotkeys_decode(u32 ev
> > enum event_types {
> > HOTKEY = 1,
> > KILLSWITCH,
> > - GFX_SWITCH
> > + GFX_SWITCH,
> > + TABLET_MODE_SWITCH
> > };
> > static void sony_nc_notify(struct acpi_device *device, u32 event)
> > {
> > @@ -1273,6 +1286,10 @@ static void sony_nc_notify(struct acpi_d
> > ev_type = GFX_SWITCH;
> > real_ev = __sony_nc_gfx_switch_status_get();
> > break;
> > + case 0x016f:
> > + ev_type = TABLET_MODE_SWITCH;
> > + real_ev = sony_nc_tablet_mode_update();
> > + break;
> > default:
> > dprintk("Unknown event 0x%x for handle 0x%x\n",
> > event, handle);
> > @@ -1428,6 +1445,13 @@ static void sony_nc_function_setup(struc
> > pr_err("couldn't set up smart connect support
> > (%d)\n",
> > result);
> > break;
> > + case 0x016f:
> > + /* laptop/presentation/tablet transformation for Sony
> > Vaio Fit 11a/13a/14a/15a */
>
> The comment can wrap to meet line length guidelines.
>
> > + result = sony_nc_tablet_mode_setup(pf_device, handle);
> > + if (result)
> > + pr_err("couldn't set up tablet mode support
> > (%d)\n",
Re: [PATCH] sony-laptop: add support for Sony Vaio Fit multi-flip laptop/presentation/tablet transformation
On Fri, Nov 21, 2014 at 10:55:04AM -0800, Darren Hart wrote:
On Thu, Nov 20, 2014 at 11:51:12AM +0300, Alexander Gavrilenko wrote:
Current mode is exported via sysfs:
/sys/devices/platform/sony-laptop/tablet
Merging with your reply and a few updates from me, you OK with:
I'll piggy-back on this merged mail for some other comments.
sony-laptop: Support Sony Vaio Fit multi-flip tablet transformations
Transformation events are sent through the ACPI bus as sony/hotkey
events. Tablet mode also triggers the SW_TABLET_MODE event via the
Sony Vaio Keys input device.
could you send me (privately) the whole DSDT from a Vaio FIT? I think I
found one implementation, is it something like this?
If (LEqual (Local0, 0x0E))
{
And (Local1, 0x03, Local1)
If (LEqual (Local1, Zero))
{
Store (One, ^^EC0.STEN)
Return (Arg0)
}
If (LEqual (Local1, One))
{
Store (Zero, ^^EC0.STEN)
Return (Arg0)
}
If (LEqual (Local1, 0x02))
{
Store (Zero, Local5)
And (^^EC0.MDST, 0x03, Local5)
Return (Local5)
}
}
Current mode is exported via sysfs:
/sys/devices/platform/sony-laptop/tablet
It's important to keep the subject under 72 characters or so, or it
gets truncated for a lot of git users.
Signed-off-by: Alexander Gavrilenko alexander.gavrile...@gmail.com
---
--- linux-3.17.3/drivers/platform/x86/sony-laptop.c.orig2014-11-19
13:15:35.965048636 +0300
+++ linux-3.17.3/drivers/platform/x86/sony-laptop.c 2014-11-19
13:17:21.139166837 +0300
@@ -135,6 +135,13 @@ MODULE_PARM_DESC(kbd_backlight_timeout,
meaningful values vary from 0 to 3 and their meaning depends
on the model (default: no change from current value));
+static int tablet_mode = 2;
+module_param(tablet_mode, int, 0);
+MODULE_PARM_DESC(tablet_mode,
+set this if your laptop have different tablet mode value,
s/have/has a/
Generally speaking module params requied for normal usage a frowned upon.
This looks like something we should be able to detect by the HID or at worst
the
DMI strings. Maybe I'm missing something, why is this needed?
I'd agree this parameter is unnecessary at the moment. In many cases,
different implementations of the same functionality end up having a
different handle (0x16f in this case). You may be able to use different
values based on that.
Also, how many other tablet_mode values are known so far? If only 2 then
I wouldn't bother using this module parameter.
...
+default is 2 (Sony Vaio Fit multi-flip),
+only affects SW_TABLET_MODE events);
+
#ifdef CONFIG_PM_SLEEP
static void sony_nc_thermal_resume(void);
#endif
@@ -181,6 +188,11 @@ static int sony_nc_touchpad_setup(struct
unsigned int handle);
static void sony_nc_touchpad_cleanup(struct platform_device *pd);
+static int sony_nc_tablet_mode_setup(struct platform_device *pd,
+ unsigned int handle);
+static void sony_nc_tablet_mode_cleanup(struct platform_device *pd);
+static int sony_nc_tablet_mode_update(void);
+
enum sony_nc_rfkill {
SONY_WIFI,
SONY_BLUETOOTH,
@@ -1198,7 +1210,8 @@ static int sony_nc_hotkeys_decode(u32 ev
enum event_types {
HOTKEY = 1,
KILLSWITCH,
- GFX_SWITCH
+ GFX_SWITCH,
+ TABLET_MODE_SWITCH
};
static void sony_nc_notify(struct acpi_device *device, u32 event)
{
@@ -1273,6 +1286,10 @@ static void sony_nc_notify(struct acpi_d
ev_type = GFX_SWITCH;
real_ev = __sony_nc_gfx_switch_status_get();
break;
+ case 0x016f:
+ ev_type = TABLET_MODE_SWITCH;
+ real_ev = sony_nc_tablet_mode_update();
+ break;
default:
dprintk(Unknown event 0x%x for handle 0x%x\n,
event, handle);
@@ -1428,6 +1445,13 @@ static void sony_nc_function_setup(struc
pr_err(couldn't set up smart connect support
(%d)\n,
result);
break;
+ case 0x016f:
+ /* laptop/presentation/tablet transformation for Sony
Vaio Fit 11a/13a/14a/15a */
The comment can wrap to meet line length guidelines.
+ result = sony_nc_tablet_mode_setup(pf_device, handle);
+ if (result)
+ pr_err(couldn't set up tablet mode support
(%d)\n,
+ result);
+ break;
default:
continue;
Re: [PATCH 1/1] sony-laptop: SVS151290S kbd backlight and gfx switch support
On Sun, Mar 17, 2013 at 08:21:35PM +0100, Arthur Wirski wrote: > SVS151290S series uses handle 0x0163 for keyboard backlight and 0x015B for > the graphics switch. > > Signed-off-by: Arthur Wirski Acked-by: Mattia Dongili Matthew, could you pick this up for 3.10? Thanks -- mattia :wq! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] sony-laptop: SVS151290S kbd backlight and gfx switch support
On Sun, Mar 17, 2013 at 08:21:35PM +0100, Arthur Wirski wrote: SVS151290S series uses handle 0x0163 for keyboard backlight and 0x015B for the graphics switch. Signed-off-by: Arthur Wirski awir...@gmail.com Acked-by: Mattia Dongili malat...@linux.it Matthew, could you pick this up for 3.10? Thanks -- mattia :wq! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] x86 platform driver bugfixes for 3.8
On Wed, Jan 16, 2013 at 11:38:17AM +0100, Bjørn Mork wrote: > Matthew Garrett writes: > > > This set covers regressions and two obvious bugfixes. The rest can wait > > for 3.9. > > Hello Matthew, > > may I request that you include the patch > > sony-laptop: fully enable SNY controlled modems > > for 3.8 as well? I'd even like it to go to stable if you and Mattia > agree. Yes, my initial intent was to have it in 3.7 as a bugfix. The sony-laptop driver manages to disable the wwan device correctly but fails to re-enable it afterwards. -- mattia :wq! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] x86 platform driver bugfixes for 3.8
On Wed, Jan 16, 2013 at 11:38:17AM +0100, Bjørn Mork wrote: Matthew Garrett matthew.garr...@nebula.com writes: This set covers regressions and two obvious bugfixes. The rest can wait for 3.9. Hello Matthew, may I request that you include the patch sony-laptop: fully enable SNY controlled modems for 3.8 as well? I'd even like it to go to stable if you and Mattia agree. Yes, my initial intent was to have it in 3.7 as a bugfix. The sony-laptop driver manages to disable the wwan device correctly but fails to re-enable it afterwards. -- mattia :wq! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sony-laptop.c: fix off-by-one
On Wed, Feb 20, 2008 at 12:59:03AM +0200, Adrian Bunk wrote:
> This patch fixes an off-by-one spotted by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Mattia Dongili <[EMAIL PROTECTED]>
> ---
> --- linux-2.6/drivers/misc/sony-laptop.c.old 2008-02-20 00:26:21.0
> +0200
> +++ linux-2.6/drivers/misc/sony-laptop.c 2008-02-20 00:26:38.0
> +0200
> @@ -314,9 +314,9 @@ static void sony_laptop_report_input_eve
> kp.dev = jog_dev;
> break;
>
> default:
> - if (event > ARRAY_SIZE(sony_laptop_input_index)) {
> + if (event >= ARRAY_SIZE(sony_laptop_input_index)) {
> dprintk("sony_laptop_report_input_event, event not
> known: %d\n", event);
> break;
> }
> if (sony_laptop_input_index[event] != -1) {
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
mattia
:wq!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sony-laptop.c: fix off-by-one
On Wed, Feb 20, 2008 at 12:59:03AM +0200, Adrian Bunk wrote:
This patch fixes an off-by-one spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Mattia Dongili [EMAIL PROTECTED]
---
--- linux-2.6/drivers/misc/sony-laptop.c.old 2008-02-20 00:26:21.0
+0200
+++ linux-2.6/drivers/misc/sony-laptop.c 2008-02-20 00:26:38.0
+0200
@@ -314,9 +314,9 @@ static void sony_laptop_report_input_eve
kp.dev = jog_dev;
break;
default:
- if (event ARRAY_SIZE(sony_laptop_input_index)) {
+ if (event = ARRAY_SIZE(sony_laptop_input_index)) {
dprintk(sony_laptop_report_input_event, event not
known: %d\n, event);
break;
}
if (sony_laptop_input_index[event] != -1) {
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
mattia
:wq!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mysqld prevents s2ram [Re: 2.6.23-mm1]
On Sun, Oct 21, 2007 at 02:58:17PM +0900, Mattia Dongili wrote: > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > Ok, now that it boots let's go for more. > > I cannot suspend if mysqld is running. mysql isn't atually doing > anything useful anyway. ... > As suggested in a different post I'll try reverting > freezer-use-wait-queue-instead-of-busy-looping.patch and re-test great, that was the guilty patch in fact. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mysqld prevents s2ram [Re: 2.6.23-mm1]
On Sun, Oct 21, 2007 at 02:58:17PM +0900, Mattia Dongili wrote: On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Ok, now that it boots let's go for more. I cannot suspend if mysqld is running. mysql isn't atually doing anything useful anyway. ... As suggested in a different post I'll try reverting freezer-use-wait-queue-instead-of-busy-looping.patch and re-test great, that was the guilty patch in fact. -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mysqld prevents s2ram [Re: 2.6.23-mm1]
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Ok, now that it boots let's go for more. I cannot suspend if mysqld is running. mysql isn't atually doing anything useful anyway. This is the failed suspend tasks dump of mysql: [0.00] Linux version 2.6.23-mm1-1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-3)) #5 SMP PREEMPT Sun Oct 21 13:50:54 JST 2007 ... [ 271.736214] PM: Preparing system for mem sleep [ 271.738185] Freezing user space processes ... [ 291.918090] Freezing of tasks failed after 20.19 seconds (1 tasks refusing to freeze): [ 291.918156] taskPC stack pid father ... [ 292.043105] === [ 292.043175] mysqld_safe D c03d40c0 0 2393 1 [ 292.043343]c26b3eac 0082 c03d0eb0 c03d40c0 c011a850 c011a843 c2626aa0 c2626bd4 [ 292.043803]c17fd0c0 c26b3e88 c26cc380 c26b3ea8 c011b83a c26b3ea0 [ 292.044322]08104d08 08104d08 c26b3eb8 c0141de0 c26b3fb8 [ 292.044843] Call Trace: [ 292.044969] [] refrigerator+0xcf/0xdb [ 292.045091] [] get_signal_to_deliver+0x33/0x414 [ 292.045214] [] do_notify_resume+0x81/0x61e [ 292.045335] [] work_notifysig+0x13/0x19 [ 292.045456] === [ 292.045524] mysqldD c03d40c0 0 2430 2393 [ 292.045692]c25d0eac 0086 c03d0eb0 c03d40c0 c0119eb5 c1c98550 c1c98684 [ 292.046184]c18060c0 0001 c25d0e88 c2603000 c25d0ea8 c011b83a c25d0ea0 [ 292.046705] c25d0eb8 c0141de0 c25d0fb8 [ 292.047272] Call Trace: [ 292.049112] [] refrigerator+0xcf/0xdb [ 292.049234] [] get_signal_to_deliver+0x33/0x414 [ 292.049357] [] do_notify_resume+0x81/0x61e [ 292.049477] [] work_notifysig+0x13/0x19 [ 292.049598] === [ 292.049666] mysqldD c03d40c0 0 2433 2393 [ 292.049834]c3000eac 0086 c03d0eb0 c03d40c0 c1c98aa0 c1c98bd4 [ 292.050306]c17fd0c0 c3000e88 c2603000 c3000ea8 c011b83a c3000ea0 [ 292.050827] 0001 0001 c3000eb8 c0141de0 c3000fb8 [ 292.051353] Call Trace: [ 292.051479] [] refrigerator+0xcf/0xdb [ 292.051599] [] get_signal_to_deliver+0x33/0x414 [ 292.051721] [] do_notify_resume+0x81/0x61e [ 292.051842] [] work_notifysig+0x13/0x19 [ 292.051962] === [ 292.052031] mysqldD c03d40c0 0 2434 2393 [ 292.052198]c27b6eac 0086 c03d0eb0 c03d40c0 c02d95a9 c27b6e8c c1d76aa0 c1d76bd4 [ 292.052660]c17fd0c0 c27b6e88 c2603000 c27b6ea8 c011b83a c27b6ea0 [ 292.053179] 0007 0007 c27b6eb8 c0141de0 c27b6fb8 [ 292.053699] Call Trace: [ 292.053825] [] refrigerator+0xcf/0xdb [ 292.053958] [] get_signal_to_deliver+0x33/0x414 [ 292.054081] [] do_notify_resume+0x81/0x61e [ 292.054203] [] work_notifysig+0x13/0x19 [ 292.054323] === [ 292.054392] mysqldD c03d40c0 0 2435 2393 [ 292.054560]c26b2eac 0086 c03d0eb0 c03d40c0 c0119eb5 c1c42ff0 c1c43124 [ 292.055028]c18060c0 0001 c26b2e88 c2603000 c26b2ea8 c011b83a c26b2ea0 [ 292.055548] 0013 0013 c26b2eb8 c0141de0 c26b2fb8 [ 292.056087] Call Trace: [ 292.056214] [] refrigerator+0xcf/0xdb [ 292.056335] [] get_signal_to_deliver+0x33/0x414 [ 292.056458] [] do_notify_resume+0x81/0x61e [ 292.056579] [] work_notifysig+0x13/0x19 [ 292.056700] === [ 292.056769] mysqldD c03d40c0 0 2436 2393 [ 292.056937]c2776eac 0086 c03d0eb0 c03d40c0 c02d95a9 c2776e8c c26a7a90 c26a7bc4 [ 292.057398]c17fd0c0 c2776e88 c2603000 c2776ea8 c011b83a c2776ea0 [ 292.057930] 0003 0003 c2776eb8 c0141de0 c2776fb8 [ 292.058450] Call Trace: [ 292.058576] [] refrigerator+0xcf/0xdb [ 292.058696] [] get_signal_to_deliver+0x33/0x414 [ 292.058819] [] do_notify_resume+0x81/0x61e [ 292.058945] [] work_notifysig+0x13/0x19 [ 292.059065] === [ 292.059134] mysqldD c03d40c0 0 2438 2393 [ 292.059301]c254deac 0086 c03d0eb0 c03d40c0 c1c9fa90 c1c9fbc4 [ 292.059762]c18060c0 0001 c254de88 c2603000 c254dea8 c011b83a c254dea0 [ 292.060281] b3435390 b3435390 c254deb8 c0141de0 c254dfb8 [ 292.060801] Call Trace: [ 292.060927] [] refrigerator+0xcf/0xdb [ 292.061047] [] get_signal_to_deliver+0x33/0x414 [ 292.061169] [] do_notify_resume+0x81/0x61e [ 292.061290] [] work_notifysig+0x13/0x19 [ 292.061411] === [ 292.061479] mysqldD
Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]
On Sat, Oct 20, 2007 at 07:18:26AM -0500, Dave Kleikamp wrote: > On Fri, 2007-10-19 at 22:34 -0700, Andrew Morton wrote: > > On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > > > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ > > > > > > Hey there!! > > > fails to boot here with this friendly oops: > > > http://oioio.altervista.org/linux/dsc01702.jpg > > > > > > .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1 > > > > > > 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet > > > (no s2ram with mysql running and some net WARNING). > > > Let's see if .23-mm1 still has those first. > > > > > > I'm adding Cc: linux-scsi > > > > > > PS: I'll hardly be able to bisect in the next days... :P > > > > That looks like a Jens and Dave production to me. > > Yes, and it's been fixed: > http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d8fe64237646fdd2c2de2722ec4189a5999119d thanks this fixes it -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Hey there!! fails to boot here with this friendly oops: http://oioio.altervista.org/linux/dsc01702.jpg .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet (no s2ram with mysql running and some net WARNING). Let's see if .23-mm1 still has those first. I'm adding Cc: linux-scsi PS: I'll hardly be able to bisect in the next days... :P -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Hey there!! fails to boot here with this friendly oops: http://oioio.altervista.org/linux/dsc01702.jpg .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet (no s2ram with mysql running and some net WARNING). Let's see if .23-mm1 still has those first. I'm adding Cc: linux-scsi PS: I'll hardly be able to bisect in the next days... :P -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in lbmIODone, fails to boot [Re: 2.6.23-mm1]
On Sat, Oct 20, 2007 at 07:18:26AM -0500, Dave Kleikamp wrote: On Fri, 2007-10-19 at 22:34 -0700, Andrew Morton wrote: On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili [EMAIL PROTECTED] wrote: On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Hey there!! fails to boot here with this friendly oops: http://oioio.altervista.org/linux/dsc01702.jpg .config: http://oioio.altervista.org/linux/config-2.6.23-mm1-1 2.6.23-rc8-mm2 booted ok but had other problems I haven't reported yet (no s2ram with mysql running and some net WARNING). Let's see if .23-mm1 still has those first. I'm adding Cc: linux-scsi PS: I'll hardly be able to bisect in the next days... :P That looks like a Jens and Dave production to me. Yes, and it's been fixed: http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8d8fe64237646fdd2c2de2722ec4189a5999119d thanks this fixes it -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mysqld prevents s2ram [Re: 2.6.23-mm1]
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/ Ok, now that it boots let's go for more. I cannot suspend if mysqld is running. mysql isn't atually doing anything useful anyway. This is the failed suspend tasks dump of mysql: [0.00] Linux version 2.6.23-mm1-1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-3)) #5 SMP PREEMPT Sun Oct 21 13:50:54 JST 2007 ... [ 271.736214] PM: Preparing system for mem sleep [ 271.738185] Freezing user space processes ... [ 291.918090] Freezing of tasks failed after 20.19 seconds (1 tasks refusing to freeze): [ 291.918156] taskPC stack pid father ... [ 292.043105] === [ 292.043175] mysqld_safe D c03d40c0 0 2393 1 [ 292.043343]c26b3eac 0082 c03d0eb0 c03d40c0 c011a850 c011a843 c2626aa0 c2626bd4 [ 292.043803]c17fd0c0 c26b3e88 c26cc380 c26b3ea8 c011b83a c26b3ea0 [ 292.044322]08104d08 08104d08 c26b3eb8 c0141de0 c26b3fb8 [ 292.044843] Call Trace: [ 292.044969] [c0141de0] refrigerator+0xcf/0xdb [ 292.045091] [c012b4d2] get_signal_to_deliver+0x33/0x414 [ 292.045214] [c01034e8] do_notify_resume+0x81/0x61e [ 292.045335] [c0103f06] work_notifysig+0x13/0x19 [ 292.045456] === [ 292.045524] mysqldD c03d40c0 0 2430 2393 [ 292.045692]c25d0eac 0086 c03d0eb0 c03d40c0 c0119eb5 c1c98550 c1c98684 [ 292.046184]c18060c0 0001 c25d0e88 c2603000 c25d0ea8 c011b83a c25d0ea0 [ 292.046705] c25d0eb8 c0141de0 c25d0fb8 [ 292.047272] Call Trace: [ 292.049112] [c0141de0] refrigerator+0xcf/0xdb [ 292.049234] [c012b4d2] get_signal_to_deliver+0x33/0x414 [ 292.049357] [c01034e8] do_notify_resume+0x81/0x61e [ 292.049477] [c0103f06] work_notifysig+0x13/0x19 [ 292.049598] === [ 292.049666] mysqldD c03d40c0 0 2433 2393 [ 292.049834]c3000eac 0086 c03d0eb0 c03d40c0 c1c98aa0 c1c98bd4 [ 292.050306]c17fd0c0 c3000e88 c2603000 c3000ea8 c011b83a c3000ea0 [ 292.050827] 0001 0001 c3000eb8 c0141de0 c3000fb8 [ 292.051353] Call Trace: [ 292.051479] [c0141de0] refrigerator+0xcf/0xdb [ 292.051599] [c012b4d2] get_signal_to_deliver+0x33/0x414 [ 292.051721] [c01034e8] do_notify_resume+0x81/0x61e [ 292.051842] [c0103f06] work_notifysig+0x13/0x19 [ 292.051962] === [ 292.052031] mysqldD c03d40c0 0 2434 2393 [ 292.052198]c27b6eac 0086 c03d0eb0 c03d40c0 c02d95a9 c27b6e8c c1d76aa0 c1d76bd4 [ 292.052660]c17fd0c0 c27b6e88 c2603000 c27b6ea8 c011b83a c27b6ea0 [ 292.053179] 0007 0007 c27b6eb8 c0141de0 c27b6fb8 [ 292.053699] Call Trace: [ 292.053825] [c0141de0] refrigerator+0xcf/0xdb [ 292.053958] [c012b4d2] get_signal_to_deliver+0x33/0x414 [ 292.054081] [c01034e8] do_notify_resume+0x81/0x61e [ 292.054203] [c0103f06] work_notifysig+0x13/0x19 [ 292.054323] === [ 292.054392] mysqldD c03d40c0 0 2435 2393 [ 292.054560]c26b2eac 0086 c03d0eb0 c03d40c0 c0119eb5 c1c42ff0 c1c43124 [ 292.055028]c18060c0 0001 c26b2e88 c2603000 c26b2ea8 c011b83a c26b2ea0 [ 292.055548] 0013 0013 c26b2eb8 c0141de0 c26b2fb8 [ 292.056087] Call Trace: [ 292.056214] [c0141de0] refrigerator+0xcf/0xdb [ 292.056335] [c012b4d2] get_signal_to_deliver+0x33/0x414 [ 292.056458] [c01034e8] do_notify_resume+0x81/0x61e [ 292.056579] [c0103f06] work_notifysig+0x13/0x19 [ 292.056700] === [ 292.056769] mysqldD c03d40c0 0 2436 2393 [ 292.056937]c2776eac 0086 c03d0eb0 c03d40c0 c02d95a9 c2776e8c c26a7a90 c26a7bc4 [ 292.057398]c17fd0c0 c2776e88 c2603000 c2776ea8 c011b83a c2776ea0 [ 292.057930] 0003 0003 c2776eb8 c0141de0 c2776fb8 [ 292.058450] Call Trace: [ 292.058576] [c0141de0] refrigerator+0xcf/0xdb [ 292.058696] [c012b4d2] get_signal_to_deliver+0x33/0x414 [ 292.058819] [c01034e8] do_notify_resume+0x81/0x61e [ 292.058945] [c0103f06] work_notifysig+0x13/0x19 [ 292.059065] === [ 292.059134] mysqldD c03d40c0 0 2438 2393 [ 292.059301]c254deac 0086 c03d0eb0 c03d40c0 c1c9fa90 c1c9fbc4 [ 292.059762]c18060c0 0001 c254de88 c2603000 c254dea8 c011b83a c254dea0 [ 292.060281] b3435390 b3435390 c254deb8 c0141de0 c254dfb8 [ 292.060801] Call Trace: [ 292.060927] [c0141de0] refrigerator+0xcf/0xdb [ 292.061047]
Re: [PATCH] [446/2many] MAINTAINERS - SONY VAIO CONTROL DEVICE DRIVER
On Sun, Aug 12, 2007 at 11:36:11PM -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Acked-by: Mattia Dongili <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6175c77..ea4d9d9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4241,6 +4241,8 @@ M: [EMAIL PROTECTED] > L: [EMAIL PROTECTED] > W: http://www.linux.it/~malattia/wiki/index.php/Sony_drivers > S: Maintained > +F: drivers/char/sonypi.c > +F: drivers/misc/sony-laptop.c > > SOUND > P: Jaroslav Kysela > -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [446/2many] MAINTAINERS - SONY VAIO CONTROL DEVICE DRIVER
On Sun, Aug 12, 2007 at 11:36:11PM -0700, [EMAIL PROTECTED] wrote: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] Acked-by: Mattia Dongili [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 6175c77..ea4d9d9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4241,6 +4241,8 @@ M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.linux.it/~malattia/wiki/index.php/Sony_drivers S: Maintained +F: drivers/char/sonypi.c +F: drivers/misc/sony-laptop.c SOUND P: Jaroslav Kysela -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/char/sonypi.c: fix ids member of struct acpi_driver
On Thu, Aug 02, 2007 at 09:50:18AM +0200, Thomas Renninger wrote:
> On Thu, 2007-08-02 at 15:40 +0900, Mattia Dongili wrote:
> > On Wed, Aug 01, 2007 at 05:15:34PM +0800, Eugene Teo wrote:
> > > ids member of struct acpi_driver is of type struct acpi_device_id, not a
> > > character array.
> > >
> > > Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
> > > ---
> > > drivers/char/sonypi.c |8 +++-
> > > 1 files changed, 7 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/char/sonypi.c b/drivers/char/sonypi.c
> > > index 73037a4..ac0aeb0 100644
> > > --- a/drivers/char/sonypi.c
> > > +++ b/drivers/char/sonypi.c
> > > @@ -1147,10 +1147,16 @@ static int sonypi_acpi_remove(struct acpi_device
> > > *device, int type)
> > > return 0;
> > > }
> > >
> > > +const static struct acpi_device_id sonypi_device_ids[] = {
> > > + {"SNY6001", 0},
> > > + {"", 0},
> > > +};
> > > +MODULE_DEVICE_TABLE(acpi, sonypi_device_ids);
> >
> > how does it behave with the already existing id in sony-laptop?
> > I'd rather avoid the MODULE_DEVICE_TABLE for sonypi allowing sony-laptop
> > to take over automagically.
>
> Yes, sounds reasonable.
> The patch is needed, but MODULE_DEVICE_TABLE should be ripped out.
> AFAIK sonypi and sony-laptop cannot coexist together. But sony-acpi
> should be preferred. If someone needs sonypi, he needs to blacklist
> sony-apci in modprobe.conf and load sonypi manually.
Yes, that's what I meant.
> Shouldn't sony-acpi replace sonypi on longterm or at least addtional
> "SNY6001" functionality be merged to sony-acpi? Having two drivers for
> the same device is not a good idea.
yep, sony-laptop will replace sonypi. It still has some problems but
development is progressing in sony-laptop, not sonypi.
Eugene, I'll import the patch without the MODULE_DEVICE_TABLE line.
cheers
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] make struct sony_nc_ids[] static
On Sun, Jul 29, 2007 at 04:58:06PM +0200, Adrian Bunk wrote: > sony_nc_ids[] can become static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> imported locally, I'll send it to Len asap. Thanks -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/char/sonypi.c: fix ids member of struct acpi_driver
On Wed, Aug 01, 2007 at 05:15:34PM +0800, Eugene Teo wrote:
> ids member of struct acpi_driver is of type struct acpi_device_id, not a
> character array.
>
> Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
> ---
> drivers/char/sonypi.c |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/char/sonypi.c b/drivers/char/sonypi.c
> index 73037a4..ac0aeb0 100644
> --- a/drivers/char/sonypi.c
> +++ b/drivers/char/sonypi.c
> @@ -1147,10 +1147,16 @@ static int sonypi_acpi_remove(struct acpi_device
> *device, int type)
> return 0;
> }
>
> +const static struct acpi_device_id sonypi_device_ids[] = {
> + {"SNY6001", 0},
> + {"", 0},
> +};
> +MODULE_DEVICE_TABLE(acpi, sonypi_device_ids);
how does it behave with the already existing id in sony-laptop?
I'd rather avoid the MODULE_DEVICE_TABLE for sonypi allowing sony-laptop
to take over automagically.
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/char/sonypi.c: fix ids member of struct acpi_driver
On Wed, Aug 01, 2007 at 05:15:34PM +0800, Eugene Teo wrote:
ids member of struct acpi_driver is of type struct acpi_device_id, not a
character array.
Signed-off-by: Eugene Teo [EMAIL PROTECTED]
---
drivers/char/sonypi.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/char/sonypi.c b/drivers/char/sonypi.c
index 73037a4..ac0aeb0 100644
--- a/drivers/char/sonypi.c
+++ b/drivers/char/sonypi.c
@@ -1147,10 +1147,16 @@ static int sonypi_acpi_remove(struct acpi_device
*device, int type)
return 0;
}
+const static struct acpi_device_id sonypi_device_ids[] = {
+ {SNY6001, 0},
+ {, 0},
+};
+MODULE_DEVICE_TABLE(acpi, sonypi_device_ids);
how does it behave with the already existing id in sony-laptop?
I'd rather avoid the MODULE_DEVICE_TABLE for sonypi allowing sony-laptop
to take over automagically.
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] make struct sony_nc_ids[] static
On Sun, Jul 29, 2007 at 04:58:06PM +0200, Adrian Bunk wrote: sony_nc_ids[] can become static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] imported locally, I'll send it to Len asap. Thanks -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/char/sonypi.c: fix ids member of struct acpi_driver
On Thu, Aug 02, 2007 at 09:50:18AM +0200, Thomas Renninger wrote:
On Thu, 2007-08-02 at 15:40 +0900, Mattia Dongili wrote:
On Wed, Aug 01, 2007 at 05:15:34PM +0800, Eugene Teo wrote:
ids member of struct acpi_driver is of type struct acpi_device_id, not a
character array.
Signed-off-by: Eugene Teo [EMAIL PROTECTED]
---
drivers/char/sonypi.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/char/sonypi.c b/drivers/char/sonypi.c
index 73037a4..ac0aeb0 100644
--- a/drivers/char/sonypi.c
+++ b/drivers/char/sonypi.c
@@ -1147,10 +1147,16 @@ static int sonypi_acpi_remove(struct acpi_device
*device, int type)
return 0;
}
+const static struct acpi_device_id sonypi_device_ids[] = {
+ {SNY6001, 0},
+ {, 0},
+};
+MODULE_DEVICE_TABLE(acpi, sonypi_device_ids);
how does it behave with the already existing id in sony-laptop?
I'd rather avoid the MODULE_DEVICE_TABLE for sonypi allowing sony-laptop
to take over automagically.
Yes, sounds reasonable.
The patch is needed, but MODULE_DEVICE_TABLE should be ripped out.
AFAIK sonypi and sony-laptop cannot coexist together. But sony-acpi
should be preferred. If someone needs sonypi, he needs to blacklist
sony-apci in modprobe.conf and load sonypi manually.
Yes, that's what I meant.
Shouldn't sony-acpi replace sonypi on longterm or at least addtional
SNY6001 functionality be merged to sony-acpi? Having two drivers for
the same device is not a good idea.
yep, sony-laptop will replace sonypi. It still has some problems but
development is progressing in sony-laptop, not sonypi.
Eugene, I'll import the patch without the MODULE_DEVICE_TABLE line.
cheers
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq 'choice' Kconfig oddness in 2.6.22-rc6-mm1..
On Sat, Jul 07, 2007 at 12:35:10AM -0400, [EMAIL PROTECTED] wrote: > So I was looking at drivers/cpufreq/Kconfig, and wondering... > > Is there a specific reason why we have a 'choice' clause that allows selecting > 'performance' or 'userspace' as the default governor, and no obvious way to > select powersave, ondemand, or conservative as a default? Or was this an Yes, ondemand and conservative may refuse to load/work on systems with a high transition latency and that is sometimes discovered only at runtime. This makes them not selectable as default governors. > oversight I should cook up a patch for? Looks like the Kconfig and a bit > of cut-n-paste in include/linux/cpufreq.h is all that's needed? No, some more work is needed (e.g.: falling back to a different governor if the selected fails). Thomas Renninger has posted patches on cpufreq-devel to accomplish that. cheers -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq 'choice' Kconfig oddness in 2.6.22-rc6-mm1..
On Sat, Jul 07, 2007 at 12:35:10AM -0400, [EMAIL PROTECTED] wrote: So I was looking at drivers/cpufreq/Kconfig, and wondering... Is there a specific reason why we have a 'choice' clause that allows selecting 'performance' or 'userspace' as the default governor, and no obvious way to select powersave, ondemand, or conservative as a default? Or was this an Yes, ondemand and conservative may refuse to load/work on systems with a high transition latency and that is sometimes discovered only at runtime. This makes them not selectable as default governors. oversight I should cook up a patch for? Looks like the Kconfig and a bit of cut-n-paste in include/linux/cpufreq.h is all that's needed? No, some more work is needed (e.g.: falling back to a different governor if the selected fails). Thomas Renninger has posted patches on cpufreq-devel to accomplish that. cheers -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Tue, Jul 03, 2007 at 03:15:33AM -0400, Len Brown wrote:
>
> > BTW: I also saw a laptop (IIRC it was a sony) with asus and sony ACPI
> > device.
> > When both drivers got loaded things broke.
> > A solution was to only let the asus driver get active if the device is
> > known. Currently, not sure whether still (I sent a patch a while ago),
> > the Asus driver falls back to a default ("M6N"?) configuration. IMO this
> > is a bit too dangerous and instead a message like "unsupported ASUS
> > model found, please send acpidump to [EMAIL PROTECTED]".
>
> This is pretty scary.
> Can you drop the acpidump output into a bugzilla?
and add myself to the cc-list?
thanks
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Tue, Jul 03, 2007 at 03:15:33AM -0400, Len Brown wrote: BTW: I also saw a laptop (IIRC it was a sony) with asus and sony ACPI device. When both drivers got loaded things broke. A solution was to only let the asus driver get active if the device is known. Currently, not sure whether still (I sent a patch a while ago), the Asus driver falls back to a default (M6N?) configuration. IMO this is a bit too dangerous and instead a message like unsupported ASUS model found, please send acpidump to [EMAIL PROTECTED]. This is pretty scary. Can you drop the acpidump output into a bugzilla? and add myself to the cc-list? thanks -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
it's iwl3945 [Re: can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Fri, Jun 22, 2007 at 09:59:47AM -0400, Alan Stern wrote: > I've lost track of the start of this thread, so it would help to see a ... Hi, sorry for the previous spam about not suspending. It turns out it's actually due to iwl3945. Looking at the changelog there's been a recent fix for suspend/resume issues, I just tested the latest snapshot (0.0.32) which indeed works. apologies again, -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
it's iwl3945 [Re: can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Fri, Jun 22, 2007 at 09:59:47AM -0400, Alan Stern wrote: I've lost track of the start of this thread, so it would help to see a ... Hi, sorry for the previous spam about not suspending. It turns out it's actually due to iwl3945. Looking at the changelog there's been a recent fix for suspend/resume issues, I just tested the latest snapshot (0.0.32) which indeed works. apologies again, -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Fri, Jun 22, 2007 at 09:59:47AM -0400, Alan Stern wrote: > On Fri, 22 Jun 2007, Mattia Dongili wrote: > > > > Yes, the problem is not present after reverting this patch. > > > > Not for me, I had that patch already reverted. As I said there was a > > point when bisecting which the kernel came back to life instead of just > > hanging trying to suspend. > > I'll try to get a trace with that. May the usb_storage verbose debug > > help there? > > I've lost track of the start of this thread, so it would help to see a > dmesg log with CONFIG_USB_DEBUG turned on. CONFIG_USB_STORAGE_DEBUG > doesn't matter so much because the usb-storage suspend and resume > routines don't do a lot of work. Sorry, it was probably me who messed things up. It looks like it's not usb-storage who's preventing suspend here. I have this diff between a single user mode where I can suspend and a multiuser environment where suspend hangs, will go loading the missing modules one by one and get a better idea... Sorry for the noise. --- /root/lsmod-str.txt 2007-06-24 10:58:09.953207666 +0900 +++ /root/lsmod-str-nono.txt2007-06-24 14:21:33.354417422 +0900 @@ -1,10 +1,20 @@ +ac +acpi_cpufreq agpgart arc4 +auth_rpcgss backlight +battery blkcipher bluetooth +button cdrom cfg80211 +cpufreq_conservative +cpufreq_ondemand +cpufreq_powersave +cpufreq_stats +cpufreq_userspace dm_crypt dm_mirror dm_mod @@ -12,20 +22,39 @@ ecb ehci_hcd evdev +exportfs +fan firmware_class +freq_table fuse hci_usb i2c_i801 ide_cd +inet_diag intel_agp +iptable_filter +iptable_nat +ip_tables +ipt_MASQUERADE +ipv6 iwl3945 +l2cap +lockd loop mac80211 +nf_conntrack +nf_conntrack_ipv4 +nf_nat +nfnetlink +nfs +nfs_acl +nfsd pcmcia pcmcia_core psmouse r5u870 rc80211_simple +rfcomm rsrc_nonstatic rtc sky2 @@ -38,16 +67,22 @@ snd_timer sony_laptop soundcore +sunrpc +tcp_diag +thermal tifm_7xx1 tifm_core tpm tpm_bios tpm_infineon uhci_hcd -usb_storage usbcore +usb_storage v4l1_compat v4l2_common video_buf videodev +x_tables +xt_state +xt_tcpudp yenta_socket -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Fri, Jun 22, 2007 at 09:59:47AM -0400, Alan Stern wrote: On Fri, 22 Jun 2007, Mattia Dongili wrote: Yes, the problem is not present after reverting this patch. Not for me, I had that patch already reverted. As I said there was a point when bisecting which the kernel came back to life instead of just hanging trying to suspend. I'll try to get a trace with that. May the usb_storage verbose debug help there? I've lost track of the start of this thread, so it would help to see a dmesg log with CONFIG_USB_DEBUG turned on. CONFIG_USB_STORAGE_DEBUG doesn't matter so much because the usb-storage suspend and resume routines don't do a lot of work. Sorry, it was probably me who messed things up. It looks like it's not usb-storage who's preventing suspend here. I have this diff between a single user mode where I can suspend and a multiuser environment where suspend hangs, will go loading the missing modules one by one and get a better idea... Sorry for the noise. --- /root/lsmod-str.txt 2007-06-24 10:58:09.953207666 +0900 +++ /root/lsmod-str-nono.txt2007-06-24 14:21:33.354417422 +0900 @@ -1,10 +1,20 @@ +ac +acpi_cpufreq agpgart arc4 +auth_rpcgss backlight +battery blkcipher bluetooth +button cdrom cfg80211 +cpufreq_conservative +cpufreq_ondemand +cpufreq_powersave +cpufreq_stats +cpufreq_userspace dm_crypt dm_mirror dm_mod @@ -12,20 +22,39 @@ ecb ehci_hcd evdev +exportfs +fan firmware_class +freq_table fuse hci_usb i2c_i801 ide_cd +inet_diag intel_agp +iptable_filter +iptable_nat +ip_tables +ipt_MASQUERADE +ipv6 iwl3945 +l2cap +lockd loop mac80211 +nf_conntrack +nf_conntrack_ipv4 +nf_nat +nfnetlink +nfs +nfs_acl +nfsd pcmcia pcmcia_core psmouse r5u870 rc80211_simple +rfcomm rsrc_nonstatic rtc sky2 @@ -38,16 +67,22 @@ snd_timer sony_laptop soundcore +sunrpc +tcp_diag +thermal tifm_7xx1 tifm_core tpm tpm_bios tpm_infineon uhci_hcd -usb_storage usbcore +usb_storage v4l1_compat v4l2_common video_buf videodev +x_tables +xt_state +xt_tcpudp yenta_socket -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Thu, Jun 21, 2007 at 11:49:37PM +0200, Rafael J. Wysocki wrote: > On Thursday, 21 June 2007 21:39, Alan Stern wrote: > > On Thu, 21 Jun 2007, Rafael J. Wysocki wrote: > > > > > > I'll see if I can reproduce your problem here. > > > > > > Yes, I can. It's only necessary to load usb-storage (without any devices > > > actually using it) and it fails device_suspend() immediately (I don't > > > think > > > it's freezer-related). > > > > > > I've got the following trace from it: > > > > > > usb_endpoint usbdev3.2_ep81: PM: suspend 0->1, parent 3-1:1.0 already 2 > > > Suspending device 3-1:1.0 > > > Suspending device usbdev3.2_ep00 > > > Suspending device 3-1 > > > Suspending device eth1 > > > Suspending device eth0 > > > Suspending device usbdev3.1 > > > Suspending device usbdev3.1_ep81 > > > Suspending device 3-0:1.0 > > > Suspending device usbdev3.1_ep00 > > > Suspending device usb3 > > > hub 3-0:1.0: hub_suspend > > > ohci_hcd :00:02.1: needs reinit! > > > usb usb3: suspend fail, err -16 > > > usb usb3: 'global' suspend -16 > > > hub 3-0:1.0: hub_resume > > > hub 3-0:1.0: activate --> -108 > > > suspend_device(): usb_suspend+0x0/0x30() returns -16 > > > Could not suspend device usb3: error -16 > > > WARNING: at > > > /home/rafael/src/mm/linux-2.6.22-rc4-mm2/drivers/usb/core/urb.c:293 > > > usb_submit_urb() > > > > Well, a large part of the problem is that > > > > usb-try-to-debug-bug-8561.patch > > > > hasn't been reverted in 2.6.22-rc4-mm2. > > Yes, the problem is not present after reverting this patch. Not for me, I had that patch already reverted. As I said there was a point when bisecting which the kernel came back to life instead of just hanging trying to suspend. I'll try to get a trace with that. May the usb_storage verbose debug help there? -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Thu, Jun 21, 2007 at 11:49:37PM +0200, Rafael J. Wysocki wrote: On Thursday, 21 June 2007 21:39, Alan Stern wrote: On Thu, 21 Jun 2007, Rafael J. Wysocki wrote: I'll see if I can reproduce your problem here. Yes, I can. It's only necessary to load usb-storage (without any devices actually using it) and it fails device_suspend() immediately (I don't think it's freezer-related). I've got the following trace from it: usb_endpoint usbdev3.2_ep81: PM: suspend 0-1, parent 3-1:1.0 already 2 Suspending device 3-1:1.0 Suspending device usbdev3.2_ep00 Suspending device 3-1 Suspending device eth1 Suspending device eth0 Suspending device usbdev3.1 Suspending device usbdev3.1_ep81 Suspending device 3-0:1.0 Suspending device usbdev3.1_ep00 Suspending device usb3 hub 3-0:1.0: hub_suspend ohci_hcd :00:02.1: needs reinit! usb usb3: suspend fail, err -16 usb usb3: 'global' suspend -16 hub 3-0:1.0: hub_resume hub 3-0:1.0: activate -- -108 suspend_device(): usb_suspend+0x0/0x30() returns -16 Could not suspend device usb3: error -16 WARNING: at /home/rafael/src/mm/linux-2.6.22-rc4-mm2/drivers/usb/core/urb.c:293 usb_submit_urb() Well, a large part of the problem is that usb-try-to-debug-bug-8561.patch hasn't been reverted in 2.6.22-rc4-mm2. Yes, the problem is not present after reverting this patch. Not for me, I had that patch already reverted. As I said there was a point when bisecting which the kernel came back to life instead of just hanging trying to suspend. I'll try to get a trace with that. May the usb_storage verbose debug help there? -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Wed, Jun 20, 2007 at 07:47:23PM +0200, Thomas Renninger wrote:
> On Thu, 2007-06-21 at 02:06 +0900, Mattia Dongili wrote:
> > On Sun, Jun 17, 2007 at 10:24:23PM +0200, Thomas Renninger wrote:
...
> > > +static const struct acpi_device_id sony_device_ids[] = {
> > > + {SONY_NC_HID, 0},
> > > + {SONY_PIC_HID, 0},
> > > + {"", 0},
> > > +};
> > > +MODULE_DEVICE_TABLE(acpi, sony_device_ids);
> > > +
> > > +static const struct acpi_device_id sony_nc_device_ids[] = {
> > > + {SONY_NC_HID, 0},
> > > + {"", 0},
> > > +};
> > > +
> > ...
> > > +static const struct acpi_device_id sony_pic_device_ids[] = {
> > > + {SONY_PIC_HID, 0},
> > > + {"", 0},
> > > +};
> > > +
> >
> > is it really necessary to have those duplicate entries?
> In this case, yes.
>
> It's because two independent ACPI drivers are set up here.
> If you could put these together, only set up
> acpi_bus_register_driver(..) once in .init and get the pic and nc driver
> handled together it would work.
>
> I don't know whether this could be done.
probably, I guess the the acpi_device.pnp structs contain enough
informations to detect which one is being handled. I'll get to that
later.
> If not, IMO this driver should get split up in two separate drivers, one
> serving SONY_PIC_HID and one serving SONY_NC_HID.
Oh no, we just merged them :)
Anyway, please feel free to add
Acked-by: Mattia Dongili <[EMAIL PROTECTED]>
to this patch.
> > Also, I guess that when this patch set is applied we also should declare
> > sonypi obsolete as sony-laptop will grab the same device that sonypi
> > wants (the SPIC one). sony-laptop has options to avoid doing that would
> > make things clear to users.
> > I still haven't received reports of mafunctioning vaios using the new
> > sony-laptop instead of sonypi but 2.6.22 isn't final yet.
>
> Sounds sane.
> Another problem that could come up in future is that new laptops could
> make use of the ACPI video spec (Appendix B) and of these vendor
> specific devices (I already saw this on an ASUS).
> While autoloading should still be ok (both are tried, maybe even both
> are needed), we need to find out which one need to be used in which
> condition.
AFAIK as far as vaios are concerned the spic device (ioport) is mostly
disappearing from newer models and most of the platform specific
operations are gathered through the methods of the acpi only SNC.
I'm also trying to get as many reports as possible[1] from vaio users to
build dmi {black,white}list for functionalities.
So I guess we are going the right direction.
[1]: with the help of TJ who has setup this nice page:
http://tjworld.net/sony-laptop/
Cheers
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Sun, Jun 17, 2007 at 10:24:23PM +0200, Thomas Renninger wrote:
> Create __mod_acpi_device_table symbol for all acpi drivers.
>
> modpost is going to use this one to create modules.alias
>
> Hopefully thinkpad module still works.
> IMO this one should get restructured and make use of acpi_bus_register_driver
> and try to avoid to test for HIDs/CIDs for its own.
>
> Signed-off-by: Thomas Renninger <[EMAIL PROTECTED]>
Tested, except for the compile error already reported it does its job on
my vaios.
A question though:
> Index: linux-2.6.22-rc4/drivers/misc/sony-laptop.c
> ===
> --- linux-2.6.22-rc4.orig/drivers/misc/sony-laptop.c
> +++ linux-2.6.22-rc4/drivers/misc/sony-laptop.c
> @@ -890,10 +890,22 @@ static int sony_nc_remove(struct acpi_de
> return 0;
> }
>
> +static const struct acpi_device_id sony_device_ids[] = {
> + {SONY_NC_HID, 0},
> + {SONY_PIC_HID, 0},
> + {"", 0},
> +};
> +MODULE_DEVICE_TABLE(acpi, sony_device_ids);
> +
> +static const struct acpi_device_id sony_nc_device_ids[] = {
> + {SONY_NC_HID, 0},
> + {"", 0},
> +};
> +
...
> +static const struct acpi_device_id sony_pic_device_ids[] = {
> + {SONY_PIC_HID, 0},
> + {"", 0},
> +};
> +
is it really necessary to have those duplicate entries?
Also, I guess that when this patch set is applied we also should declare
sonypi obsolete as sony-laptop will grab the same device that sonypi
wants (the SPIC one). sony-laptop has options to avoid doing that would
make things clear to users.
I still haven't received reports of mafunctioning vaios using the new
sony-laptop instead of sonypi but 2.6.22 isn't final yet.
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ACPI autoloading - Create acpi alias interface
On Sun, Jun 17, 2007 at 10:27:27PM +0200, Thomas Renninger wrote:
> Create acpi alias interface
...
> Index: linux-2.6.22-rc4/drivers/pnp/pnpacpi/core.c
> ===
> --- linux-2.6.22-rc4.orig/drivers/pnp/pnpacpi/core.c
> +++ linux-2.6.22-rc4/drivers/pnp/pnpacpi/core.c
> @@ -21,7 +21,10 @@
>
> #include
> #include
> +#include
> #include
> +#include
> +
> #include "pnpacpi.h"
>
> static int num = 0;
> @@ -33,15 +36,17 @@ static int num = 0;
> * have irqs (PIC, Timer) because we call acpi_register_gsi.
> * Finaly only devices that have a CRS method need to be in this list.
> */
> -static char __initdata excluded_id_list[] =
> - "PNP0C09," /* EC */
> - "PNP0C0F," /* Link device */
> - "PNP," /* PIC */
> - "PNP0100," /* Timer */
> - ;
> +static __initdata struct acpi_device_id excluded_id_list[] ={
> + {"PNP0C09", 0}, /* EC */
> + {"PNP0C0F", 0}, /* Link device */
> + {"PNP", 0}, /* PIC */
> + {"PNP0100", 0}, /* Timer */
> + {"", 0};
^^^
eeek!
> +};
> +
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote: > On Wednesday, 20 June 2007 07:22, Mattia Dongili wrote: > > On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ > > > > Hello, > > on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting > > is becoming troublesome as different sets have slightly different > > problems. > > At one point (with the GREGKH usb stuff built) I had the kernel > > reporting it cannot stop the usb-storage thread so I guess that > > something later in the series made things worse (freezable workqueues?). > > > > Clues? > > Can you please try 2.6.22-rc5 with the patches from > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/ > > applied. That should allow us to eliminate some suspects. ;-) you're safe then! .22-rc5 + your suspend patch-set can suspend and resume happily. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wed, Jun 20, 2007 at 01:40:18PM +0200, Rafael J. Wysocki wrote: On Wednesday, 20 June 2007 07:22, Mattia Dongili wrote: On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ Hello, on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting is becoming troublesome as different sets have slightly different problems. At one point (with the GREGKH usb stuff built) I had the kernel reporting it cannot stop the usb-storage thread so I guess that something later in the series made things worse (freezable workqueues?). Clues? Can you please try 2.6.22-rc5 with the patches from http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc5/patches/ applied. That should allow us to eliminate some suspects. ;-) you're safe then! .22-rc5 + your suspend patch-set can suspend and resume happily. -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ACPI autoloading - Create acpi alias interface
On Sun, Jun 17, 2007 at 10:27:27PM +0200, Thomas Renninger wrote:
Create acpi alias interface
...
Index: linux-2.6.22-rc4/drivers/pnp/pnpacpi/core.c
===
--- linux-2.6.22-rc4.orig/drivers/pnp/pnpacpi/core.c
+++ linux-2.6.22-rc4/drivers/pnp/pnpacpi/core.c
@@ -21,7 +21,10 @@
#include linux/acpi.h
#include linux/pnp.h
+#include linux/mod_devicetable.h
#include acpi/acpi_bus.h
+#include acpi/actypes.h
+
#include pnpacpi.h
static int num = 0;
@@ -33,15 +36,17 @@ static int num = 0;
* have irqs (PIC, Timer) because we call acpi_register_gsi.
* Finaly only devices that have a CRS method need to be in this list.
*/
-static char __initdata excluded_id_list[] =
- PNP0C09, /* EC */
- PNP0C0F, /* Link device */
- PNP, /* PIC */
- PNP0100, /* Timer */
- ;
+static __initdata struct acpi_device_id excluded_id_list[] ={
+ {PNP0C09, 0}, /* EC */
+ {PNP0C0F, 0}, /* Link device */
+ {PNP, 0}, /* PIC */
+ {PNP0100, 0}, /* Timer */
+ {, 0};
^^^
eeek!
+};
+
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Sun, Jun 17, 2007 at 10:24:23PM +0200, Thomas Renninger wrote:
Create __mod_acpi_device_table symbol for all acpi drivers.
modpost is going to use this one to create modules.alias
Hopefully thinkpad module still works.
IMO this one should get restructured and make use of acpi_bus_register_driver
and try to avoid to test for HIDs/CIDs for its own.
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
Tested, except for the compile error already reported it does its job on
my vaios.
A question though:
Index: linux-2.6.22-rc4/drivers/misc/sony-laptop.c
===
--- linux-2.6.22-rc4.orig/drivers/misc/sony-laptop.c
+++ linux-2.6.22-rc4/drivers/misc/sony-laptop.c
@@ -890,10 +890,22 @@ static int sony_nc_remove(struct acpi_de
return 0;
}
+static const struct acpi_device_id sony_device_ids[] = {
+ {SONY_NC_HID, 0},
+ {SONY_PIC_HID, 0},
+ {, 0},
+};
+MODULE_DEVICE_TABLE(acpi, sony_device_ids);
+
+static const struct acpi_device_id sony_nc_device_ids[] = {
+ {SONY_NC_HID, 0},
+ {, 0},
+};
+
...
+static const struct acpi_device_id sony_pic_device_ids[] = {
+ {SONY_PIC_HID, 0},
+ {, 0},
+};
+
is it really necessary to have those duplicate entries?
Also, I guess that when this patch set is applied we also should declare
sonypi obsolete as sony-laptop will grab the same device that sonypi
wants (the SPIC one). sony-laptop has options to avoid doing that would
make things clear to users.
I still haven't received reports of mafunctioning vaios using the new
sony-laptop instead of sonypi but 2.6.22 isn't final yet.
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Wed, Jun 20, 2007 at 07:47:23PM +0200, Thomas Renninger wrote:
On Thu, 2007-06-21 at 02:06 +0900, Mattia Dongili wrote:
On Sun, Jun 17, 2007 at 10:24:23PM +0200, Thomas Renninger wrote:
...
+static const struct acpi_device_id sony_device_ids[] = {
+ {SONY_NC_HID, 0},
+ {SONY_PIC_HID, 0},
+ {, 0},
+};
+MODULE_DEVICE_TABLE(acpi, sony_device_ids);
+
+static const struct acpi_device_id sony_nc_device_ids[] = {
+ {SONY_NC_HID, 0},
+ {, 0},
+};
+
...
+static const struct acpi_device_id sony_pic_device_ids[] = {
+ {SONY_PIC_HID, 0},
+ {, 0},
+};
+
is it really necessary to have those duplicate entries?
In this case, yes.
It's because two independent ACPI drivers are set up here.
If you could put these together, only set up
acpi_bus_register_driver(..) once in .init and get the pic and nc driver
handled together it would work.
I don't know whether this could be done.
probably, I guess the the acpi_device.pnp structs contain enough
informations to detect which one is being handled. I'll get to that
later.
If not, IMO this driver should get split up in two separate drivers, one
serving SONY_PIC_HID and one serving SONY_NC_HID.
Oh no, we just merged them :)
Anyway, please feel free to add
Acked-by: Mattia Dongili [EMAIL PROTECTED]
to this patch.
Also, I guess that when this patch set is applied we also should declare
sonypi obsolete as sony-laptop will grab the same device that sonypi
wants (the SPIC one). sony-laptop has options to avoid doing that would
make things clear to users.
I still haven't received reports of mafunctioning vaios using the new
sony-laptop instead of sonypi but 2.6.22 isn't final yet.
Sounds sane.
Another problem that could come up in future is that new laptops could
make use of the ACPI video spec (Appendix B) and of these vendor
specific devices (I already saw this on an ASUS).
While autoloading should still be ok (both are tried, maybe even both
are needed), we need to find out which one need to be used in which
condition.
AFAIK as far as vaios are concerned the spic device (ioport) is mostly
disappearing from newer models and most of the platform specific
operations are gathered through the methods of the acpi only SNC.
I'm also trying to get as many reports as possible[1] from vaio users to
build dmi {black,white}list for functionalities.
So I guess we are going the right direction.
[1]: with the help of TJ who has setup this nice page:
http://tjworld.net/sony-laptop/
Cheers
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ Hello, on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting is becoming troublesome as different sets have slightly different problems. At one point (with the GREGKH usb stuff built) I had the kernel reporting it cannot stop the usb-storage thread so I guess that something later in the series made things worse (freezable workqueues?). Clues? -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/12] acpi: select ACPI_EC for SONY_LAPTOP
On Wed, Jun 20, 2007 at 12:52:25AM +0200, Andreas Herrmann wrote: > Fix kernel build problem as SONY_LAPTOP depends on ACPI_EC. The same questions about ACPI_SYSTEM and ACPI_POWER surviving oldconfig hold here. See also http://lkml.org/lkml/2007/5/15/168 and following for a previous report. In any case, Len if you're going apply such fixes feel free to add my Acked-By on this one. > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> > --- > drivers/misc/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 0d6f369..463fa41 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -119,6 +119,7 @@ config MSI_LAPTOP > config SONY_LAPTOP > tristate "Sony Laptop Extras" > depends on X86 && ACPI > + select ACPI_EC > select BACKLIGHT_CLASS_DEVICE > ---help--- > This mini-driver drives the SNC and SPIC devices present in the ACPI > -- > 1.5.0.7 -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Tue, Jun 19, 2007 at 02:53:27PM +0200, Thomas Renninger wrote: > On Sun, 2007-06-17 at 19:49 -0300, Henrique de Moraes Holschuh wrote: > > On Sun, 17 Jun 2007, Thomas Renninger wrote: > > > Create __mod_acpi_device_table symbol for all acpi drivers. ... > > model-specific drivers like thinkpad-acpi > Not in general, only if the driver provides additional functions and the > ACPI device does not appear on machines that need those additional > functions. > E.g. the asus driver AFAIK serves exactly the ACPI device it registers > for. and the sony-laptop as well. Thanks for doing that, will test as soon as possible on my vaios here. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ACPI autoloading - Create __mod_acpi_device_table symbol for all acpi drivers.
On Tue, Jun 19, 2007 at 02:53:27PM +0200, Thomas Renninger wrote: On Sun, 2007-06-17 at 19:49 -0300, Henrique de Moraes Holschuh wrote: On Sun, 17 Jun 2007, Thomas Renninger wrote: Create __mod_acpi_device_table symbol for all acpi drivers. ... model-specific drivers like thinkpad-acpi Not in general, only if the driver provides additional functions and the ACPI device does not appear on machines that need those additional functions. E.g. the asus driver AFAIK serves exactly the ACPI device it registers for. and the sony-laptop as well. Thanks for doing that, will test as soon as possible on my vaios here. -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/12] acpi: select ACPI_EC for SONY_LAPTOP
On Wed, Jun 20, 2007 at 12:52:25AM +0200, Andreas Herrmann wrote: Fix kernel build problem as SONY_LAPTOP depends on ACPI_EC. The same questions about ACPI_SYSTEM and ACPI_POWER surviving oldconfig hold here. See also http://lkml.org/lkml/2007/5/15/168 and following for a previous report. In any case, Len if you're going apply such fixes feel free to add my Acked-By on this one. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/misc/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 0d6f369..463fa41 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -119,6 +119,7 @@ config MSI_LAPTOP config SONY_LAPTOP tristate Sony Laptop Extras depends on X86 ACPI + select ACPI_EC select BACKLIGHT_CLASS_DEVICE ---help--- This mini-driver drives the SNC and SPIC devices present in the ACPI -- 1.5.0.7 -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
can't suspend on vaio sz (rc4 and rc5 are ok) [was Re: 2.6.22-rc4-mm2]
On Wed, Jun 06, 2007 at 10:03:13PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/ Hello, on this vaio sz72b I can't suspend if usb-storage is loaded. Bisecting is becoming troublesome as different sets have slightly different problems. At one point (with the GREGKH usb stuff built) I had the kernel reporting it cannot stop the usb-storage thread so I guess that something later in the series made things worse (freezable workqueues?). Clues? -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove sonypi_camera_command()
On Sat, Jun 02, 2007 at 09:09:42PM +0200, Adrian Bunk wrote:
> This patch removes the no longer used sonypi_camera_command().
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
>
> ---
>
> drivers/char/sonypi.c | 47 -
> include/linux/sonypi.h |2 -
> 2 files changed, 49 deletions(-)
>
> --- linux-2.6.22-rc3-mm1/include/linux/sonypi.h.old 2007-06-02
> 20:35:45.0 +0200
> +++ linux-2.6.22-rc3-mm1/include/linux/sonypi.h 2007-06-02
> 20:35:51.0 +0200
> @@ -153,8 +153,6 @@
> #define SONYPI_COMMAND_GETCAMERAROMVERSION 18 /* obsolete */
> #define SONYPI_COMMAND_GETCAMERAREVISION 19 /* obsolete */
>
> -int sonypi_camera_command(int command, u8 value);
> -
> #endif /* __KERNEL__ */
>
> #endif /* _SONYPI_H_ */
> --- linux-2.6.22-rc3-mm1/drivers/char/sonypi.c.old2007-06-02
> 20:35:58.0 +0200
> +++ linux-2.6.22-rc3-mm1/drivers/char/sonypi.c2007-06-02
> 20:36:16.0 +0200
> @@ -885,53 +885,6 @@
> return IRQ_HANDLED;
> }
>
> -/* External camera command (exported to the motion eye v4l driver) */
> -int sonypi_camera_command(int command, u8 value)
> -{
> - if (!camera)
> - return -EIO;
> -
> - mutex_lock(_device.lock);
> -
> - switch (command) {
> - case SONYPI_COMMAND_SETCAMERA:
> - if (value)
> - sonypi_camera_on();
> - else
> - sonypi_camera_off();
> - break;
> - case SONYPI_COMMAND_SETCAMERABRIGHTNESS:
> - sonypi_set(SONYPI_CAMERA_BRIGHTNESS, value);
> - break;
> - case SONYPI_COMMAND_SETCAMERACONTRAST:
> - sonypi_set(SONYPI_CAMERA_CONTRAST, value);
> - break;
> - case SONYPI_COMMAND_SETCAMERAHUE:
> - sonypi_set(SONYPI_CAMERA_HUE, value);
> - break;
> - case SONYPI_COMMAND_SETCAMERACOLOR:
> - sonypi_set(SONYPI_CAMERA_COLOR, value);
> - break;
> - case SONYPI_COMMAND_SETCAMERASHARPNESS:
> - sonypi_set(SONYPI_CAMERA_SHARPNESS, value);
> - break;
> - case SONYPI_COMMAND_SETCAMERAPICTURE:
> - sonypi_set(SONYPI_CAMERA_PICTURE, value);
> - break;
> - case SONYPI_COMMAND_SETCAMERAAGC:
> - sonypi_set(SONYPI_CAMERA_AGC, value);
> - break;
> - default:
> - printk(KERN_ERR "sonypi: sonypi_camera_command invalid: %d\n",
> -command);
> - break;
> - }
> - mutex_unlock(_device.lock);
> - return 0;
> -}
> -
> -EXPORT_SYMBOL(sonypi_camera_command);
> -
> static int sonypi_misc_fasync(int fd, struct file *filp, int on)
> {
> int retval;
>
>
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove sonypi_camera_command()
On Sat, Jun 02, 2007 at 09:09:42PM +0200, Adrian Bunk wrote:
This patch removes the no longer used sonypi_camera_command().
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Mattia Dongili [EMAIL PROTECTED]
---
drivers/char/sonypi.c | 47 -
include/linux/sonypi.h |2 -
2 files changed, 49 deletions(-)
--- linux-2.6.22-rc3-mm1/include/linux/sonypi.h.old 2007-06-02
20:35:45.0 +0200
+++ linux-2.6.22-rc3-mm1/include/linux/sonypi.h 2007-06-02
20:35:51.0 +0200
@@ -153,8 +153,6 @@
#define SONYPI_COMMAND_GETCAMERAROMVERSION 18 /* obsolete */
#define SONYPI_COMMAND_GETCAMERAREVISION 19 /* obsolete */
-int sonypi_camera_command(int command, u8 value);
-
#endif /* __KERNEL__ */
#endif /* _SONYPI_H_ */
--- linux-2.6.22-rc3-mm1/drivers/char/sonypi.c.old2007-06-02
20:35:58.0 +0200
+++ linux-2.6.22-rc3-mm1/drivers/char/sonypi.c2007-06-02
20:36:16.0 +0200
@@ -885,53 +885,6 @@
return IRQ_HANDLED;
}
-/* External camera command (exported to the motion eye v4l driver) */
-int sonypi_camera_command(int command, u8 value)
-{
- if (!camera)
- return -EIO;
-
- mutex_lock(sonypi_device.lock);
-
- switch (command) {
- case SONYPI_COMMAND_SETCAMERA:
- if (value)
- sonypi_camera_on();
- else
- sonypi_camera_off();
- break;
- case SONYPI_COMMAND_SETCAMERABRIGHTNESS:
- sonypi_set(SONYPI_CAMERA_BRIGHTNESS, value);
- break;
- case SONYPI_COMMAND_SETCAMERACONTRAST:
- sonypi_set(SONYPI_CAMERA_CONTRAST, value);
- break;
- case SONYPI_COMMAND_SETCAMERAHUE:
- sonypi_set(SONYPI_CAMERA_HUE, value);
- break;
- case SONYPI_COMMAND_SETCAMERACOLOR:
- sonypi_set(SONYPI_CAMERA_COLOR, value);
- break;
- case SONYPI_COMMAND_SETCAMERASHARPNESS:
- sonypi_set(SONYPI_CAMERA_SHARPNESS, value);
- break;
- case SONYPI_COMMAND_SETCAMERAPICTURE:
- sonypi_set(SONYPI_CAMERA_PICTURE, value);
- break;
- case SONYPI_COMMAND_SETCAMERAAGC:
- sonypi_set(SONYPI_CAMERA_AGC, value);
- break;
- default:
- printk(KERN_ERR sonypi: sonypi_camera_command invalid: %d\n,
-command);
- break;
- }
- mutex_unlock(sonypi_device.lock);
- return 0;
-}
-
-EXPORT_SYMBOL(sonypi_camera_command);
-
static int sonypi_misc_fasync(int fd, struct file *filp, int on)
{
int retval;
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic: rmmod/0x00000001/4568
Hello,
with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
following BUG:
[ 459.800033] BUG: scheduling while atomic: rmmod/0x0001/4568
[ 459.800045] [] dump_trace+0x63/0x1ec
[ 459.800055] [] show_trace_log_lvl+0x1a/0x30
[ 459.800066] [] show_trace+0x12/0x14
[ 459.800099] [] dump_stack+0x16/0x18
[ 459.800135] [] __sched_text_start+0x56/0x7db
[ 459.800142] [] wait_for_completion+0x65/0x9b
[ 459.800147] [] synchronize_rcu+0x2d/0x33
[ 459.800154] [] synchronize_srcu+0x23/0x5f
[ 459.800160] [] srcu_notifier_chain_unregister+0x43/0x4d
[ 459.800185] [] cpufreq_unregister_notifier+0x22/0x32
[ 459.800203] [] ehci_stop+0x4f/0xb7 [ehci_hcd]
[ 459.800248] [] usb_remove_hcd+0x97/0xd7 [usbcore]
[ 459.800280] [] usb_hcd_pci_remove+0x18/0x6a [usbcore]
[ 459.800317] [] pci_device_remove+0x1c/0x3d
[ 459.800324] [] __device_release_driver+0x74/0x90
[ 459.800332] [] driver_detach+0x81/0xc2
[ 459.800337] [] bus_remove_driver+0x5d/0x7c
[ 459.800342] [] driver_unregister+0xb/0xd
[ 459.800347] [] pci_unregister_driver+0x13/0x65
[ 459.800351] [] ehci_hcd_cleanup+0x10/0x12 [ehci_hcd]
[ 459.800360] [] sys_delete_module+0x187/0x1ae
[ 459.800367] [] sysenter_past_esp+0x5f/0x85
[ 459.800373] [] 0xe410
[ 459.800384] ===
static void ehci_stop (struct usb_hcd *hcd)
{
...
spin_lock_irq(>lock);
if (HC_IS_RUNNING (hcd->state))
ehci_quiesce (ehci);
#ifdef CONFIG_CPU_FREQ
cpufreq_unregister_notifier(>cpufreq_transition,
CPUFREQ_TRANSITION_NOTIFIER);
#endif
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sun, May 20, 2007 at 06:22:23PM -0700, David Brownell wrote: > On Sunday 20 May 2007, Mattia Dongili wrote: > > > > $ cat /proc/acpi/wakeup > > Device S-state Status Sysfs node > > PWRB S4*enabled > > S1F0 S4 disabled > > S1F1 S4 disabled > > S1F2 S4 disabled > > S1F3 S4 disabled > > S1F4 S4 disabled > > S1F5 S4 disabled > > S1F6 S4 disabled > > S1F7 S4 disabled > > TLAN S3 disabled pci::07:00.0 > > DLAN S3 disabled > > S6F0 S4 disabled > > S6F1 S4 disabled > > S6F2 S4 disabled > > S6F3 S4 disabled > > S6F4 S4 disabled > > S6F5 S4 disabled > > S6F6 S4 disabled > > S6F7 S4 disabled > > USB1 S3 disabled pci::00:1d.0 > > USB2 S3 disabled pci::00:1d.1 > > USB3 S3 disabled pci::00:1d.2 > > USB4 S3 disabled pci::00:1d.3 > > USB7 S3 disabled pci::00:1d.7 > > SLT0 S4 disabled > > LANC S3 disabled > > EC0 S5 disabled > > That's strangely busy ... what ARE all those devices? :) the S[16]F* are tons of acpi devices... don't know what they are, they are attached to the PCI-E port 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) if you're interested the DSDT is here: http://www.linux.it/~malattia/sony-laptop/DSDT.sz72b.type3.dsl > But only the PCI ones -- or certain devices connected to USB > root hubs -- could be affected by that patch. > > So another experiment you could do, if you want faster info > than "git bisect" can provide, is building drivers for those > PCI devices as modules (ehci-hcd, uhci-hcd, sky2) and then > finding which one causes the trouble by removing them before > STR. it's ehci-hcd! and apart from the fact that removing it causes a BUG in cpufreq no the system stays correctly asleep when suspended. ... > > > My suspicion, based on the dmesg and seeing what drivers actually > > > try to enable wakeup, would be the 'sky2' driver. The other two > > > > FWIW the sky2 is never functional upon resume, I need to ifdown, rmmod, > > modprobe and ifup again to get some networking... > > Try "rmmod sky2" *before* suspend, to see if that matters. > > Also "rmmod uhci-hcd", which will keep USB from doing anything > with that biometric thingie. > > I suspect one or the other of those will be the issue. very close :) -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sun, May 20, 2007 at 11:38:04AM -0700, David Brownell wrote:
> On Saturday 19 May 2007, Mattia Dongili wrote:
> > On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> > > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > After finally catching fw-{ohci,core} to be problematic during
> > > > > > resume,
> > > > > > I'm now experiencing an immediate resume after suspending.
> > > > > >
> > > > > > 2.6.21-rc7-mm* didn't even suspend, my last known
> > > > > > suspend-and-resuming
> > > > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR
> > > > > > with
> > > > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > > > >
> > > > > > my .config is:
> > > > > > http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > > > and a str cycle with PM_DEBUG=y:
> > > > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
>
> Can you also provide /proc/acpi/wakeup and /proc/bus/usb/devices?
> Plus "ethool eth0" and "ethtool -i eth0"?
here we go:
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PWRB S4*enabled
S1F0 S4 disabled
S1F1 S4 disabled
S1F2 S4 disabled
S1F3 S4 disabled
S1F4 S4 disabled
S1F5 S4 disabled
S1F6 S4 disabled
S1F7 S4 disabled
TLAN S3 disabled pci::07:00.0
DLAN S3 disabled
S6F0 S4 disabled
S6F1 S4 disabled
S6F2 S4 disabled
S6F3 S4 disabled
S6F4 S4 disabled
S6F5 S4 disabled
S6F6 S4 disabled
S6F7 S4 disabled
USB1 S3 disabled pci::00:1d.0
USB2 S3 disabled pci::00:1d.1
USB3 S3 disabled pci::00:1d.2
USB4 S3 disabled pci::00:1d.3
USB7 S3 disabled pci::00:1d.7
SLT0 S4 disabled
LANC S3 disabled
EC0 S5 disabled
$ cat /proc/bus/usb/devices
T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 45/900 us ( 5%), #Int= 1, #Iso= 1
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor= ProdID= Rev= 2.06
S: Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=:00:1d.3
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=054c ProdID=01bb Rev= 1.28
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=044e ProdID=300c Rev=19.15
S: Manufacturer=ALPS
S: Product=UGX
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us (
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sat, May 19, 2007 at 11:47:23PM -0700, Andrew Morton wrote: > On Sun, 20 May 2007 15:14:08 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote: > > > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[EMAIL PROTECTED]> > > > wrote: ... > > > > ok, git-acpi.patch is not the bad boy :) > > > > but very very close: > > acpi-driver-model-flags-and-platform_enable_wake.patch > > > > Thanks very much for working that out - it saves lots of people heaps of > pain. I dropped the patch. oh dear... and now, with the full series applied, I hit the immediately-resuspend-after-resume someone already reported... aargh -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:
>
> > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > I'm now experiencing an immediate resume after suspending.
> > > >
> > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > >
> > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > and a str cycle with PM_DEBUG=y:
> > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> > ...
> > > > Any idea where to start from? (bisecting is ok, but it'll take some
> > > > time...)
> > >
> > > Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
> >
> > ok, git-acpi.patch is not the bad boy :)
but very very close:
acpi-driver-model-flags-and-platform_enable_wake.patch
cheers
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili [EMAIL PROTECTED] wrote:
On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili [EMAIL PROTECTED]
wrote:
Hello,
After finally catching fw-{ohci,core} to be problematic during resume,
I'm now experiencing an immediate resume after suspending.
2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
2.6.21-rc6-mm* after the cpuidle fixes).
my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
and a str cycle with PM_DEBUG=y:
http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
...
Any idea where to start from? (bisecting is ok, but it'll take some
time...)
Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
ok, git-acpi.patch is not the bad boy :)
but very very close:
acpi-driver-model-flags-and-platform_enable_wake.patch
cheers
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sat, May 19, 2007 at 11:47:23PM -0700, Andrew Morton wrote: On Sun, 20 May 2007 15:14:08 +0900 Mattia Dongili [EMAIL PROTECTED] wrote: On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote: On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili [EMAIL PROTECTED] wrote: ... ok, git-acpi.patch is not the bad boy :) but very very close: acpi-driver-model-flags-and-platform_enable_wake.patch Thanks very much for working that out - it saves lots of people heaps of pain. I dropped the patch. oh dear... and now, with the full series applied, I hit the immediately-resuspend-after-resume someone already reported... aargh -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sun, May 20, 2007 at 11:38:04AM -0700, David Brownell wrote:
On Saturday 19 May 2007, Mattia Dongili wrote:
On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili [EMAIL PROTECTED]
wrote:
On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili [EMAIL PROTECTED]
wrote:
Hello,
After finally catching fw-{ohci,core} to be problematic during
resume,
I'm now experiencing an immediate resume after suspending.
2.6.21-rc7-mm* didn't even suspend, my last known
suspend-and-resuming
kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR
with
2.6.21-rc6-mm* after the cpuidle fixes).
my .config is:
http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
and a str cycle with PM_DEBUG=y:
http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
Can you also provide /proc/acpi/wakeup and /proc/bus/usb/devices?
Plus ethool eth0 and ethtool -i eth0?
here we go:
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PWRB S4*enabled
S1F0 S4 disabled
S1F1 S4 disabled
S1F2 S4 disabled
S1F3 S4 disabled
S1F4 S4 disabled
S1F5 S4 disabled
S1F6 S4 disabled
S1F7 S4 disabled
TLAN S3 disabled pci::07:00.0
DLAN S3 disabled
S6F0 S4 disabled
S6F1 S4 disabled
S6F2 S4 disabled
S6F3 S4 disabled
S6F4 S4 disabled
S6F5 S4 disabled
S6F6 S4 disabled
S6F7 S4 disabled
USB1 S3 disabled pci::00:1d.0
USB2 S3 disabled pci::00:1d.1
USB3 S3 disabled pci::00:1d.2
USB4 S3 disabled pci::00:1d.3
USB7 S3 disabled pci::00:1d.7
SLT0 S4 disabled
LANC S3 disabled
EC0 S5 disabled
$ cat /proc/bus/usb/devices
T: Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 45/900 us ( 5%), #Int= 1, #Iso= 1
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor= ProdID= Rev= 2.06
S: Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=:00:1d.3
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=054c ProdID=01bb Rev= 1.28
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=10ms
T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=044e ProdID=300c Rev=19.15
S: Manufacturer=ALPS
S: Product=UGX
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor= ProdID= Rev= 2.06
S: Manufacturer=Linux 2.6.22-rc1-mm1-bisect uhci_hcd
S: Product=UHCI Host Controller
S: SerialNumber=:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0483 ProdID=2016 Rev= 0.01
S
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sun, May 20, 2007 at 06:22:23PM -0700, David Brownell wrote: On Sunday 20 May 2007, Mattia Dongili wrote: $ cat /proc/acpi/wakeup Device S-state Status Sysfs node PWRB S4*enabled S1F0 S4 disabled S1F1 S4 disabled S1F2 S4 disabled S1F3 S4 disabled S1F4 S4 disabled S1F5 S4 disabled S1F6 S4 disabled S1F7 S4 disabled TLAN S3 disabled pci::07:00.0 DLAN S3 disabled S6F0 S4 disabled S6F1 S4 disabled S6F2 S4 disabled S6F3 S4 disabled S6F4 S4 disabled S6F5 S4 disabled S6F6 S4 disabled S6F7 S4 disabled USB1 S3 disabled pci::00:1d.0 USB2 S3 disabled pci::00:1d.1 USB3 S3 disabled pci::00:1d.2 USB4 S3 disabled pci::00:1d.3 USB7 S3 disabled pci::00:1d.7 SLT0 S4 disabled LANC S3 disabled EC0 S5 disabled That's strangely busy ... what ARE all those devices? :) the S[16]F* are tons of acpi devices... don't know what they are, they are attached to the PCI-E port 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) if you're interested the DSDT is here: http://www.linux.it/~malattia/sony-laptop/DSDT.sz72b.type3.dsl But only the PCI ones -- or certain devices connected to USB root hubs -- could be affected by that patch. So another experiment you could do, if you want faster info than git bisect can provide, is building drivers for those PCI devices as modules (ehci-hcd, uhci-hcd, sky2) and then finding which one causes the trouble by removing them before STR. it's ehci-hcd! and apart from the fact that removing it causes a BUG in cpufreq no the system stays correctly asleep when suspended. ... My suspicion, based on the dmesg and seeing what drivers actually try to enable wakeup, would be the 'sky2' driver. The other two FWIW the sky2 is never functional upon resume, I need to ifdown, rmmod, modprobe and ifup again to get some networking... Try rmmod sky2 *before* suspend, to see if that matters. Also rmmod uhci-hcd, which will keep USB from doing anything with that biometric thingie. I suspect one or the other of those will be the issue. very close :) -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.22-rc1-mm1] ehci-hcd - BUG: scheduling while atomic: rmmod/0x00000001/4568
Hello,
with gregkh-usb-usb-ehci-cpufreq-fix.patch removing ehci-hcd causes the
following BUG:
[ 459.800033] BUG: scheduling while atomic: rmmod/0x0001/4568
[ 459.800045] [c0104eb3] dump_trace+0x63/0x1ec
[ 459.800055] [c0105056] show_trace_log_lvl+0x1a/0x30
[ 459.800066] [c0105c82] show_trace+0x12/0x14
[ 459.800099] [c0105d0f] dump_stack+0x16/0x18
[ 459.800135] [c02eff66] __sched_text_start+0x56/0x7db
[ 459.800142] [c02f0768] wait_for_completion+0x65/0x9b
[ 459.800147] [c0132c38] synchronize_rcu+0x2d/0x33
[ 459.800154] [c0138387] synchronize_srcu+0x23/0x5f
[ 459.800160] [c012f6bf] srcu_notifier_chain_unregister+0x43/0x4d
[ 459.800185] [c0287b83] cpufreq_unregister_notifier+0x22/0x32
[ 459.800203] [f8e85713] ehci_stop+0x4f/0xb7 [ehci_hcd]
[ 459.800248] [f8dc48d4] usb_remove_hcd+0x97/0xd7 [usbcore]
[ 459.800280] [f8dcdf1d] usb_hcd_pci_remove+0x18/0x6a [usbcore]
[ 459.800317] [c01f1ca3] pci_device_remove+0x1c/0x3d
[ 459.800324] [c024fc46] __device_release_driver+0x74/0x90
[ 459.800332] [c025009f] driver_detach+0x81/0xc2
[ 459.800337] [c024f7f9] bus_remove_driver+0x5d/0x7c
[ 459.800342] [c025010a] driver_unregister+0xb/0xd
[ 459.800347] [c01f1e1d] pci_unregister_driver+0x13/0x65
[ 459.800351] [f8e858f8] ehci_hcd_cleanup+0x10/0x12 [ehci_hcd]
[ 459.800360] [c0143b11] sys_delete_module+0x187/0x1ae
[ 459.800367] [c0103e62] sysenter_past_esp+0x5f/0x85
[ 459.800373] [e410] 0xe410
[ 459.800384] ===
static void ehci_stop (struct usb_hcd *hcd)
{
...
spin_lock_irq(ehci-lock);
if (HC_IS_RUNNING (hcd-state))
ehci_quiesce (ehci);
#ifdef CONFIG_CPU_FREQ
cpufreq_unregister_notifier(ehci-cpufreq_transition,
CPUFREQ_TRANSITION_NOTIFIER);
#endif
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]
On Sun, May 20, 2007 at 12:11:10AM +0900, Mattia Dongili wrote: ... > I'm now seeing if avoiding the tifm stuff in -mm1 fixes the > immediately-resumes-after-str problem (unfortunately the commint doesn't > revert cleanly). as (almost) expected it is not related... tomorrow is another bisecting day... -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]
On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
> On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:
>
> > On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> > > On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > After finally catching fw-{ohci,core} to be problematic during resume,
> > > > I'm now experiencing an immediate resume after suspending.
> > > >
> > > > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > > > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > > > 2.6.21-rc6-mm* after the cpuidle fixes).
> > > >
> > > > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > > > and a str cycle with PM_DEBUG=y:
> > > > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
> > ...
> > > > Any idea where to start from? (bisecting is ok, but it'll take some
> > > > time...)
> > >
> > > Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
> >
> > ok, git-acpi.patch is not the bad boy :)
> > Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
> > suspend (it sits on the "Stopping tasks" console screen) while 2.6.21
> > can.
> > I'm now bisecting this, will come to -mm1 later when done with this one.
>
> OK, thanks.
>
> > Who is the regression-guy?
>
> Len, usually ;)But I think you meant Michal, cc'ed here.
LOL, not this time. We have the responsible commit for 2.6.22-rc1 (Cc
added):
3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5 is first bad commit
commit 3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5
Author: Alex Dubov <[EMAIL PROTECTED]>
Date: Thu Apr 12 16:59:15 2007 +1000
tifm: replace per-adapter kthread with freezeable workqueue
Freezeable workqueue makes sure that adapter work items (device insertions
and removals) would be handled after the system is fully resumed. Previously
this was achieved by explicit freezing of the kthread.
Signed-off-by: Alex Dubov <[EMAIL PROTECTED]>
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
I'm now seeing if avoiding the tifm stuff in -mm1 fixes the
immediately-resumes-after-str problem (unfortunately the commint doesn't
revert cleanly).
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
> On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > After finally catching fw-{ohci,core} to be problematic during resume,
> > I'm now experiencing an immediate resume after suspending.
> >
> > 2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
> > kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
> > 2.6.21-rc6-mm* after the cpuidle fixes).
> >
> > my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
> > and a str cycle with PM_DEBUG=y:
> > http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
...
> > Any idea where to start from? (bisecting is ok, but it'll take some
> > time...)
>
> Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
ok, git-acpi.patch is not the bad boy :)
Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
suspend (it sits on the "Stopping tasks" console screen) while 2.6.21
can.
I'm now bisecting this, will come to -mm1 later when done with this one.
Who is the regression-guy?
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili [EMAIL PROTECTED] wrote:
Hello,
After finally catching fw-{ohci,core} to be problematic during resume,
I'm now experiencing an immediate resume after suspending.
2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
2.6.21-rc6-mm* after the cpuidle fixes).
my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
and a str cycle with PM_DEBUG=y:
http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
...
Any idea where to start from? (bisecting is ok, but it'll take some
time...)
Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
ok, git-acpi.patch is not the bad boy :)
Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
suspend (it sits on the Stopping tasks console screen) while 2.6.21
can.
I'm now bisecting this, will come to -mm1 later when done with this one.
Who is the regression-guy?
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]
On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote:
On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili [EMAIL PROTECTED] wrote:
On Fri, May 18, 2007 at 12:22:40AM -0700, Andrew Morton wrote:
On Fri, 18 May 2007 16:15:24 +0900 Mattia Dongili [EMAIL PROTECTED]
wrote:
Hello,
After finally catching fw-{ohci,core} to be problematic during resume,
I'm now experiencing an immediate resume after suspending.
2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
2.6.21-rc6-mm* after the cpuidle fixes).
my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
and a str cycle with PM_DEBUG=y:
http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
...
Any idea where to start from? (bisecting is ok, but it'll take some
time...)
Bisecting isn't that bad ;) I'd pick git-acpi.patch as the starting point.
ok, git-acpi.patch is not the bad boy :)
Anyway what we have is a regression in 2.6.22-rc1 since the laptop can't
suspend (it sits on the Stopping tasks console screen) while 2.6.21
can.
I'm now bisecting this, will come to -mm1 later when done with this one.
OK, thanks.
Who is the regression-guy?
Len, usually ;)But I think you meant Michal, cc'ed here.
LOL, not this time. We have the responsible commit for 2.6.22-rc1 (Cc
added):
3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5 is first bad commit
commit 3540af8ffddcdbc7573451ac0b5cd57a2eaf8af5
Author: Alex Dubov [EMAIL PROTECTED]
Date: Thu Apr 12 16:59:15 2007 +1000
tifm: replace per-adapter kthread with freezeable workqueue
Freezeable workqueue makes sure that adapter work items (device insertions
and removals) would be handled after the system is fully resumed. Previously
this was achieved by explicit freezing of the kthread.
Signed-off-by: Alex Dubov [EMAIL PROTECTED]
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
I'm now seeing if avoiding the tifm stuff in -mm1 fixes the
immediately-resumes-after-str problem (unfortunately the commint doesn't
revert cleanly).
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1 regression: tifm prevents suspending [was: Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR]
On Sun, May 20, 2007 at 12:11:10AM +0900, Mattia Dongili wrote: ... I'm now seeing if avoiding the tifm stuff in -mm1 fixes the immediately-resumes-after-str problem (unfortunately the commint doesn't revert cleanly). as (almost) expected it is not related... tomorrow is another bisecting day... -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
Hello,
After finally catching fw-{ohci,core} to be problematic during resume,
I'm now experiencing an immediate resume after suspending.
2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
2.6.21-rc6-mm* after the cpuidle fixes).
my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
and a str cycle with PM_DEBUG=y:
http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
So this is on a vaio Sz72B,
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT
Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML
Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express
Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition
Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
(rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2
(rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3
(rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4
(rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev
02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev
02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev
02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev
02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge
(rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller
(rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA
Storage Controller IDE (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
06:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network
Connection (rev 02)
07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast
Ethernet Controller (rev 15)
09:04.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
09:04.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE
1394 Host Controller
09:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card
Reader (SD/MMC/MS/MS PRO/xD)
Any idea where to start from? (bisecting is ok, but it'll take some
time...)
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
Hello,
After finally catching fw-{ohci,core} to be problematic during resume,
I'm now experiencing an immediate resume after suspending.
2.6.21-rc7-mm* didn't even suspend, my last known suspend-and-resuming
kernel was 2.6.21-rc5-mm3 (I know one other vaio SZ user could STR with
2.6.21-rc6-mm* after the cpuidle fixes).
my .config is: http://oioio.altervista.org/linux/config-2.6.22-rc1-mm1-1
and a str cycle with PM_DEBUG=y:
http://oioio.altervista.org/linux/dmesg-SRT-immediately-resumes.txt
So this is on a vaio Sz72B,
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT
Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML
Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express
Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition
Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
(rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2
(rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3
(rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4
(rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev
02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev
02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev
02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev
02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge
(rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller
(rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA
Storage Controller IDE (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
06:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network
Connection (rev 02)
07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast
Ethernet Controller (rev 15)
09:04.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
09:04.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE
1394 Host Controller
09:04.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card
Reader (SD/MMC/MS/MS PRO/xD)
Any idea where to start from? (bisecting is ok, but it'll take some
time...)
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: Linux 2.6.22-rc1
On Tue, May 15, 2007 at 10:46:21AM -0700, Randy Dunlap wrote: > On Wed, 16 May 2007 00:42:08 +0900 Mattia Dongili wrote: ... > > Given the drivers/acpi/Kconfig portion > > > > if ACPI > > ... > > config ACPI_EC > > bool > > default y > > help > > ... > > > > config ACPI_POWER > > bool > > default y > > > > config ACPI_SYSTEM > > bool > > default y > > help > > ... > > ... > > endif > > > > I'd expect the 3 symbols to be all set when CONFIG_ACPI=y. > > What am I overseeing? > > I think that this is just 'make randconfig' throwing a curve ball. > ACPI depends on PM, but PM=n. In my experience, randconfig is a > good tool for testing oddball configs, but the results are not > always something that is fixable or needs to be fixed. It looks like Kconfig does the right thing on i386 though. Not the same on x84_64. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: Linux 2.6.22-rc1
On Mon, May 14, 2007 at 10:45:46AM -0700, Randy Dunlap wrote: > On Mon, 14 May 2007 07:49:31 +0200 (MEST) Jan Engelhardt wrote: > > > > > On May 14 2007 10:55, Mattia Dongili wrote: > > >On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote: > > >> On May 12 2007 20:20, Linus Torvalds wrote: > > >> > > > >> >Ok, the merge window has closed, and 2.6.22-rc1 is out there. > > >> > > >> I have hit a randconfig compile failure. .config attached. > > >> > > >> LD .tmp_vmlinux1 > > >> drivers/built-in.o: In function `acpi_bus_generate_event': > > >> (.text+0x233f7): undefined reference to `event_is_open' > > >> drivers/built-in.o: In function `acpi_bus_get_power': > > >> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state' > > >> drivers/built-in.o: In function `acpi_bus_set_power': > > >> (.text+0x237c3): undefined reference to `acpi_power_transition' > > >> drivers/built-in.o: In function `acpi_bus_set_power': > > >> (.text+0x23835): undefined reference to `acpi_power_transition' > > >> drivers/built-in.o: In function `sony_pic_fanspeed_store': > > >> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write' > > >> drivers/built-in.o: In function `sony_pic_fanspeed_show': > > >> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read' > > >> make: *** [.tmp_vmlinux1] Error 1 > > > > > >I actually can't reproduce it with your .config. > > > > But I can. Did you try it on x86_64? From 2.6.22-rc1 [ > > commit 39403865d2e4590802553370a56c9ab93131e4ee in /linux-2.6.git] ? > > > > bzip2 -cd randconfig-1.bz2 >.config > > make -j8 > > Yes, build easily fails for me also. ok, as far as sony-laptop is concerned a dependency on ACPI_EC suffices to fix the link failure, but I guess that would just hide the real issue. IOW: why does ACPI_EC, ACPI_SYSTEM and ACPI_POWER are not set when the ACPI symbol is? Given the drivers/acpi/Kconfig portion if ACPI ... config ACPI_EC bool default y help ... config ACPI_POWER bool default y config ACPI_SYSTEM bool default y help ... ... endif I'd expect the 3 symbols to be all set when CONFIG_ACPI=y. What am I overseeing? -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: Linux 2.6.22-rc1
On Mon, May 14, 2007 at 10:45:46AM -0700, Randy Dunlap wrote: On Mon, 14 May 2007 07:49:31 +0200 (MEST) Jan Engelhardt wrote: On May 14 2007 10:55, Mattia Dongili wrote: On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote: On May 12 2007 20:20, Linus Torvalds wrote: Ok, the merge window has closed, and 2.6.22-rc1 is out there. I have hit a randconfig compile failure. .config attached. LD .tmp_vmlinux1 drivers/built-in.o: In function `acpi_bus_generate_event': (.text+0x233f7): undefined reference to `event_is_open' drivers/built-in.o: In function `acpi_bus_get_power': (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x237c3): undefined reference to `acpi_power_transition' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x23835): undefined reference to `acpi_power_transition' drivers/built-in.o: In function `sony_pic_fanspeed_store': sony-laptop.c:(.text+0x91930): undefined reference to `ec_write' drivers/built-in.o: In function `sony_pic_fanspeed_show': sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read' make: *** [.tmp_vmlinux1] Error 1 I actually can't reproduce it with your .config. But I can. Did you try it on x86_64? From 2.6.22-rc1 [ commit 39403865d2e4590802553370a56c9ab93131e4ee in /linux-2.6.git] ? bzip2 -cd randconfig-1.bz2 .config make -j8 Yes, build easily fails for me also. ok, as far as sony-laptop is concerned a dependency on ACPI_EC suffices to fix the link failure, but I guess that would just hide the real issue. IOW: why does ACPI_EC, ACPI_SYSTEM and ACPI_POWER are not set when the ACPI symbol is? Given the drivers/acpi/Kconfig portion if ACPI ... config ACPI_EC bool default y help ... config ACPI_POWER bool default y config ACPI_SYSTEM bool default y help ... ... endif I'd expect the 3 symbols to be all set when CONFIG_ACPI=y. What am I overseeing? -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: Linux 2.6.22-rc1
On Tue, May 15, 2007 at 10:46:21AM -0700, Randy Dunlap wrote: On Wed, 16 May 2007 00:42:08 +0900 Mattia Dongili wrote: ... Given the drivers/acpi/Kconfig portion if ACPI ... config ACPI_EC bool default y help ... config ACPI_POWER bool default y config ACPI_SYSTEM bool default y help ... ... endif I'd expect the 3 symbols to be all set when CONFIG_ACPI=y. What am I overseeing? I think that this is just 'make randconfig' throwing a curve ball. ACPI depends on PM, but PM=n. In my experience, randconfig is a good tool for testing oddball configs, but the results are not always something that is fixable or needs to be fixed. It looks like Kconfig does the right thing on i386 though. Not the same on x84_64. -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: Linux 2.6.22-rc1
On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote: > On May 12 2007 20:20, Linus Torvalds wrote: > > > >Ok, the merge window has closed, and 2.6.22-rc1 is out there. > > I have hit a randconfig compile failure. .config attached. > > LD .tmp_vmlinux1 > drivers/built-in.o: In function `acpi_bus_generate_event': > (.text+0x233f7): undefined reference to `event_is_open' > drivers/built-in.o: In function `acpi_bus_get_power': > (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state' > drivers/built-in.o: In function `acpi_bus_set_power': > (.text+0x237c3): undefined reference to `acpi_power_transition' > drivers/built-in.o: In function `acpi_bus_set_power': > (.text+0x23835): undefined reference to `acpi_power_transition' > drivers/built-in.o: In function `sony_pic_fanspeed_store': > sony-laptop.c:(.text+0x91930): undefined reference to `ec_write' > drivers/built-in.o: In function `sony_pic_fanspeed_show': > sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read' > make: *** [.tmp_vmlinux1] Error 1 I actually can't reproduce it with your .config. >From a clean tree, running make fires up the oldconfig which fixes the many missing/garbled dependencies. In any case SONY_LAPTOP depends on ACPI which always build EC statically if selected. clues? -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: Linux 2.6.22-rc1
On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote: On May 12 2007 20:20, Linus Torvalds wrote: Ok, the merge window has closed, and 2.6.22-rc1 is out there. I have hit a randconfig compile failure. .config attached. LD .tmp_vmlinux1 drivers/built-in.o: In function `acpi_bus_generate_event': (.text+0x233f7): undefined reference to `event_is_open' drivers/built-in.o: In function `acpi_bus_get_power': (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x237c3): undefined reference to `acpi_power_transition' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x23835): undefined reference to `acpi_power_transition' drivers/built-in.o: In function `sony_pic_fanspeed_store': sony-laptop.c:(.text+0x91930): undefined reference to `ec_write' drivers/built-in.o: In function `sony_pic_fanspeed_show': sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read' make: *** [.tmp_vmlinux1] Error 1 I actually can't reproduce it with your .config. From a clean tree, running make fires up the oldconfig which fixes the many missing/garbled dependencies. In any case SONY_LAPTOP depends on ACPI which always build EC statically if selected. clues? -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] use mutex instead of semaphore in Sony PI driver
On Tue, Apr 24, 2007 at 10:02:35PM +0200, Matthias Kaehlcke wrote:
> the Sony Programmable I/O Control driver uses a semaphore as
> mutex. use the mutex API instead of the (binary) semaphore
>
> Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
Acked-by: Mattia Dongili <[EMAIL PROTECTED]>
> --
>
> diff --git a/drivers/char/sonypi.c b/drivers/char/sonypi.c
> index 7823757..878d8d0 100644
> --- a/drivers/char/sonypi.c
> +++ b/drivers/char/sonypi.c
> @@ -477,7 +477,7 @@ static struct sonypi_device {
> u16 evtype_offset;
> int camera_power;
> int bluetooth_power;
> - struct semaphore lock;
> + struct mutex lock;
> struct kfifo *fifo;
> spinlock_t fifo_lock;
> wait_queue_head_t fifo_proc_list;
> @@ -884,7 +884,7 @@ int sonypi_camera_command(int command, u8 value)
> if (!camera)
> return -EIO;
>
> - down(_device.lock);
> + mutex_lock(_device.lock);
>
> switch (command) {
> case SONYPI_COMMAND_SETCAMERA:
> @@ -919,7 +919,7 @@ int sonypi_camera_command(int command, u8 value)
> command);
> break;
> }
> - up(_device.lock);
> + mutex_unlock(_device.lock);
> return 0;
> }
>
> @@ -938,20 +938,20 @@ static int sonypi_misc_fasync(int fd, struct file
> *filp, int on)
> static int sonypi_misc_release(struct inode *inode, struct file *file)
> {
> sonypi_misc_fasync(-1, file, 0);
> - down(_device.lock);
> + mutex_lock(_device.lock);
> sonypi_device.open_count--;
> - up(_device.lock);
> + mutex_unlock(_device.lock);
> return 0;
> }
>
> static int sonypi_misc_open(struct inode *inode, struct file *file)
> {
> - down(_device.lock);
> + mutex_lock(_device.lock);
> /* Flush input queue on first open */
> if (!sonypi_device.open_count)
> kfifo_reset(sonypi_device.fifo);
> sonypi_device.open_count++;
> - up(_device.lock);
> + mutex_unlock(_device.lock);
> return 0;
> }
>
> @@ -1001,7 +1001,7 @@ static int sonypi_misc_ioctl(struct inode *ip, struct
> file *fp,
> u8 val8;
> u16 val16;
>
> - down(_device.lock);
> + mutex_lock(_device.lock);
> switch (cmd) {
> case SONYPI_IOCGBRT:
> if (sonypi_ec_read(SONYPI_LCD_LIGHT, )) {
> @@ -1101,7 +1101,7 @@ static int sonypi_misc_ioctl(struct inode *ip, struct
> file *fp,
> default:
> ret = -EINVAL;
> }
> - up(_device.lock);
> + mutex_unlock(_device.lock);
> return ret;
> }
>
> @@ -1330,7 +1330,7 @@ static int __devinit sonypi_probe(struct
> platform_device *dev)
> }
>
> init_waitqueue_head(_device.fifo_proc_list);
> - init_MUTEX(_device.lock);
> + mutex_init(_device.lock);
> sonypi_device.bluetooth_power = -1;
>
> if ((pcidev = pci_get_device(PCI_VENDOR_ID_INTEL,
>
> --
> Matthias Kaehlcke
> Linux Application Developer
> Barcelona
>
> If liberty means anything at all, it means the
>right to tell people what they do not want to hear
> (George Orwell)
> .''`.
> using free software / Debian GNU/Linux | http://debian.org : :' :
> `. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
>
--
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] use mutex instead of semaphore in Sony PI driver
On Tue, Apr 24, 2007 at 10:02:35PM +0200, Matthias Kaehlcke wrote:
the Sony Programmable I/O Control driver uses a semaphore as
mutex. use the mutex API instead of the (binary) semaphore
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
Acked-by: Mattia Dongili [EMAIL PROTECTED]
--
diff --git a/drivers/char/sonypi.c b/drivers/char/sonypi.c
index 7823757..878d8d0 100644
--- a/drivers/char/sonypi.c
+++ b/drivers/char/sonypi.c
@@ -477,7 +477,7 @@ static struct sonypi_device {
u16 evtype_offset;
int camera_power;
int bluetooth_power;
- struct semaphore lock;
+ struct mutex lock;
struct kfifo *fifo;
spinlock_t fifo_lock;
wait_queue_head_t fifo_proc_list;
@@ -884,7 +884,7 @@ int sonypi_camera_command(int command, u8 value)
if (!camera)
return -EIO;
- down(sonypi_device.lock);
+ mutex_lock(sonypi_device.lock);
switch (command) {
case SONYPI_COMMAND_SETCAMERA:
@@ -919,7 +919,7 @@ int sonypi_camera_command(int command, u8 value)
command);
break;
}
- up(sonypi_device.lock);
+ mutex_unlock(sonypi_device.lock);
return 0;
}
@@ -938,20 +938,20 @@ static int sonypi_misc_fasync(int fd, struct file
*filp, int on)
static int sonypi_misc_release(struct inode *inode, struct file *file)
{
sonypi_misc_fasync(-1, file, 0);
- down(sonypi_device.lock);
+ mutex_lock(sonypi_device.lock);
sonypi_device.open_count--;
- up(sonypi_device.lock);
+ mutex_unlock(sonypi_device.lock);
return 0;
}
static int sonypi_misc_open(struct inode *inode, struct file *file)
{
- down(sonypi_device.lock);
+ mutex_lock(sonypi_device.lock);
/* Flush input queue on first open */
if (!sonypi_device.open_count)
kfifo_reset(sonypi_device.fifo);
sonypi_device.open_count++;
- up(sonypi_device.lock);
+ mutex_unlock(sonypi_device.lock);
return 0;
}
@@ -1001,7 +1001,7 @@ static int sonypi_misc_ioctl(struct inode *ip, struct
file *fp,
u8 val8;
u16 val16;
- down(sonypi_device.lock);
+ mutex_lock(sonypi_device.lock);
switch (cmd) {
case SONYPI_IOCGBRT:
if (sonypi_ec_read(SONYPI_LCD_LIGHT, val8)) {
@@ -1101,7 +1101,7 @@ static int sonypi_misc_ioctl(struct inode *ip, struct
file *fp,
default:
ret = -EINVAL;
}
- up(sonypi_device.lock);
+ mutex_unlock(sonypi_device.lock);
return ret;
}
@@ -1330,7 +1330,7 @@ static int __devinit sonypi_probe(struct
platform_device *dev)
}
init_waitqueue_head(sonypi_device.fifo_proc_list);
- init_MUTEX(sonypi_device.lock);
+ mutex_init(sonypi_device.lock);
sonypi_device.bluetooth_power = -1;
if ((pcidev = pci_get_device(PCI_VENDOR_ID_INTEL,
--
Matthias Kaehlcke
Linux Application Developer
Barcelona
If liberty means anything at all, it means the
right to tell people what they do not want to hear
(George Orwell)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
--
mattia
:wq!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CPU_IDLE prevents resuming from STR [was: Re: 2.6.21-rc6-mm1]
On Sun, Apr 08, 2007 at 02:35:59PM -0700, Andrew Morton wrote: ... > git-acpi.patch after bisecting I can finally say what breaks resume from STR here: tada: CPU_IDLE. I first spotted the git-acpi.patch then reapplied it and disabled CPU_IDLE, now my laptop resumes. Any useful information I should add? $ cat /sys/devices/system/cpu/cpuidle/* acpi_idle no governors acpi_idle no governor $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz stepping: 6 cpu MHz : 1000.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3671.24 clflush size: 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz stepping: 6 cpu MHz : 1000.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 15805.85 clflush size: 64 -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc6
On Thu, Apr 12, 2007 at 09:26:44PM +0300, Maxim Levitsky wrote: > On Thursday 12 April 2007 18:14:02 Mattia Dongili wrote: > > On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: > > ... > > > Maxim Levitsky (1): > > > Add suspend/resume for HPET > > > > This one breaks resume for me (from STR) on a vaio SZ. Reverting this > > commit allows resuming again but leaves me with some periodic and > > unpleasant: > > > > [ 155.232000] BUG: soft lockup detected on CPU#1! > > [ 155.232000] [] show_trace_log_lvl+0x1a/0x2f > > [ 155.232000] [] show_trace+0x12/0x14 > > [ 155.232000] [] dump_stack+0x16/0x18 > > [ 155.232000] [] softlockup_tick+0xa7/0xb6 > > [ 155.232000] [] run_local_timers+0x12/0x14 > > [ 155.232000] [] update_process_times+0x3e/0x63 > > [ 155.232000] [] tick_sched_timer+0x50/0x95 > > [ 155.232000] [] hrtimer_interrupt+0x10b/0x18b > > [ 155.232000] [] smp_apic_timer_interrupt+0x6c/0x7e > > [ 155.232000] [] apic_timer_interrupt+0x28/0x30 > > [ 155.232000] [] cpu_idle+0x1b/0xc7 > > [ 155.232000] [] start_secondary+0x32b/0x333 > > [ 155.232000] [<>] run_init_process+0x3fefed10/0x19 > > [ 155.232000] === > > > > FWIW: I hit the same BUG() in -rc5. > > full boot+suspend+resume log: > > http://oioio.altervista.org/linux/kern-2.6.21-rc6.log > > .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 > > > > I'm available to test more patches or to provide other info. > > Strange,strange... Yes... strange. I can't reproduce the resume breakage anymore, with or without your patch. I still have the soft lockup anyway after resuming. I'll still keep trying, for now just disregard my previous mail. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc6
On Thu, Apr 12, 2007 at 09:26:44PM +0300, Maxim Levitsky wrote: On Thursday 12 April 2007 18:14:02 Mattia Dongili wrote: On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: ... Maxim Levitsky (1): Add suspend/resume for HPET This one breaks resume for me (from STR) on a vaio SZ. Reverting this commit allows resuming again but leaves me with some periodic and unpleasant: [ 155.232000] BUG: soft lockup detected on CPU#1! [ 155.232000] [c0104cf2] show_trace_log_lvl+0x1a/0x2f [ 155.232000] [c0105344] show_trace+0x12/0x14 [ 155.232000] [c01053c8] dump_stack+0x16/0x18 [ 155.232000] [c0147240] softlockup_tick+0xa7/0xb6 [ 155.232000] [c01284d3] run_local_timers+0x12/0x14 [ 155.232000] [c012887a] update_process_times+0x3e/0x63 [ 155.232000] [c0137656] tick_sched_timer+0x50/0x95 [ 155.232000] [c01340e0] hrtimer_interrupt+0x10b/0x18b [ 155.232000] [c01137b7] smp_apic_timer_interrupt+0x6c/0x7e [ 155.232000] [c0104840] apic_timer_interrupt+0x28/0x30 [ 155.232000] [c0102318] cpu_idle+0x1b/0xc7 [ 155.232000] [c011297a] start_secondary+0x32b/0x333 [ 155.232000] [] run_init_process+0x3fefed10/0x19 [ 155.232000] === FWIW: I hit the same BUG() in -rc5. full boot+suspend+resume log: http://oioio.altervista.org/linux/kern-2.6.21-rc6.log .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 I'm available to test more patches or to provide other info. Strange,strange... Yes... strange. I can't reproduce the resume breakage anymore, with or without your patch. I still have the soft lockup anyway after resuming. I'll still keep trying, for now just disregard my previous mail. -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CPU_IDLE prevents resuming from STR [was: Re: 2.6.21-rc6-mm1]
On Sun, Apr 08, 2007 at 02:35:59PM -0700, Andrew Morton wrote: ... git-acpi.patch after bisecting I can finally say what breaks resume from STR here: tada: CPU_IDLE. I first spotted the git-acpi.patch then reapplied it and disabled CPU_IDLE, now my laptop resumes. Any useful information I should add? $ cat /sys/devices/system/cpu/cpuidle/* acpi_idle no governors acpi_idle no governor $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz stepping: 6 cpu MHz : 1000.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3671.24 clflush size: 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz stepping: 6 cpu MHz : 1000.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 15805.85 clflush size: 64 -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc6
On Thu, Apr 12, 2007 at 05:14:02PM +0200, Mattia Dongili wrote: > On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: > ... > > Maxim Levitsky (1): > > Add suspend/resume for HPET > > This one breaks resume for me (from STR) on a vaio SZ. Reverting this > commit allows resuming again but leaves me with some periodic and unpleasant: > > [ 155.232000] BUG: soft lockup detected on CPU#1! A couple more info (probably useless but...): - I noticed the resume problem in -rc6-mm1 but reverting the same patch there doesn't make the laptop resume again - last known succesful resuming kernel: 2.6.21-rc5-mm3 (and without hitting the BUG() above after resume) -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc6
On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: ... > Maxim Levitsky (1): > Add suspend/resume for HPET This one breaks resume for me (from STR) on a vaio SZ. Reverting this commit allows resuming again but leaves me with some periodic and unpleasant: [ 155.232000] BUG: soft lockup detected on CPU#1! [ 155.232000] [] show_trace_log_lvl+0x1a/0x2f [ 155.232000] [] show_trace+0x12/0x14 [ 155.232000] [] dump_stack+0x16/0x18 [ 155.232000] [] softlockup_tick+0xa7/0xb6 [ 155.232000] [] run_local_timers+0x12/0x14 [ 155.232000] [] update_process_times+0x3e/0x63 [ 155.232000] [] tick_sched_timer+0x50/0x95 [ 155.232000] [] hrtimer_interrupt+0x10b/0x18b [ 155.232000] [] smp_apic_timer_interrupt+0x6c/0x7e [ 155.232000] [] apic_timer_interrupt+0x28/0x30 [ 155.232000] [] cpu_idle+0x1b/0xc7 [ 155.232000] [] start_secondary+0x32b/0x333 [ 155.232000] [<>] run_init_process+0x3fefed10/0x19 [ 155.232000] === FWIW: I hit the same BUG() in -rc5. full boot+suspend+resume log: http://oioio.altervista.org/linux/kern-2.6.21-rc6.log .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 I'm available to test more patches or to provide other info. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc6
On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: ... Maxim Levitsky (1): Add suspend/resume for HPET This one breaks resume for me (from STR) on a vaio SZ. Reverting this commit allows resuming again but leaves me with some periodic and unpleasant: [ 155.232000] BUG: soft lockup detected on CPU#1! [ 155.232000] [c0104cf2] show_trace_log_lvl+0x1a/0x2f [ 155.232000] [c0105344] show_trace+0x12/0x14 [ 155.232000] [c01053c8] dump_stack+0x16/0x18 [ 155.232000] [c0147240] softlockup_tick+0xa7/0xb6 [ 155.232000] [c01284d3] run_local_timers+0x12/0x14 [ 155.232000] [c012887a] update_process_times+0x3e/0x63 [ 155.232000] [c0137656] tick_sched_timer+0x50/0x95 [ 155.232000] [c01340e0] hrtimer_interrupt+0x10b/0x18b [ 155.232000] [c01137b7] smp_apic_timer_interrupt+0x6c/0x7e [ 155.232000] [c0104840] apic_timer_interrupt+0x28/0x30 [ 155.232000] [c0102318] cpu_idle+0x1b/0xc7 [ 155.232000] [c011297a] start_secondary+0x32b/0x333 [ 155.232000] [] run_init_process+0x3fefed10/0x19 [ 155.232000] === FWIW: I hit the same BUG() in -rc5. full boot+suspend+resume log: http://oioio.altervista.org/linux/kern-2.6.21-rc6.log .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 I'm available to test more patches or to provide other info. -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21-rc6
On Thu, Apr 12, 2007 at 05:14:02PM +0200, Mattia Dongili wrote: On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: ... Maxim Levitsky (1): Add suspend/resume for HPET This one breaks resume for me (from STR) on a vaio SZ. Reverting this commit allows resuming again but leaves me with some periodic and unpleasant: [ 155.232000] BUG: soft lockup detected on CPU#1! A couple more info (probably useless but...): - I noticed the resume problem in -rc6-mm1 but reverting the same patch there doesn't make the laptop resume again - last known succesful resuming kernel: 2.6.21-rc5-mm3 (and without hitting the BUG() above after resume) -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix cpufreq_stats attrs removal
On Fri, Mar 30, 2007 at 12:09:03PM +0400, Alexey Dobriyan wrote: > On Thu, Mar 22, 2007 at 06:02:01PM +0100, Mattia Dongili wrote: > > On Wed, Mar 21, 2007 at 08:10:42PM -0800, Andrew Morton wrote: > > > I ain't picky, but as a short-term thing it'd be kinda nice if it didn't > > > oops the kernel. > > > > There are other symptoms to this same bug: > > > > 1. unload p4-clockmod: /sys/.../cpu0/cpufreq is removed all together > > 2. load p4-clockmod: /sys/.../cpu0/cpufreq appears but no 'stats' subdir > >(yes, cpufreq_stats is loaded) > > 3. rmmod cpufreq_stats: Ooops! > > > > Call Trace: > > [] remove_dir+0x33/0xc4 > > [] remove_files+0x1a/0x28 > > [] sysfs_remove_group+0x63/0x71 > > [] cpufreq_stat_cpu_callback+0x51/0x8a [cpufreq_stats] > > [] cpufreq_stats_exit+0x47/0x4b [cpufreq_stats] > > [] sys_delete_module+0x190/0x1b7 > > [] do_wp_page+0x231/0x3e7 > > [] syscall_call+0x7/0xb > > > > The problem is cpufreq_stats doesn't know when a cpufreq driver is > > removed and doesn't cleanup. I guess this affects any setup with > > cpufreq_stats. > > The attached patch seems to solve both symptoms and yes... it's quite > > invasive as it introduce one more cpufreq policy notification (REMOVED). > > > > BTW: the patch is against .21-rc4-mm1 but applies with some fuzz to > > 2.6.20 too > > Also, it doesn't work. hmmm... odd. I did test that case. Also, using .21-rc5-mm3 (which has that patch applied) and acpi-cpufreq (I don't have that P4 handy now) I actually hit a WARN_ON in kref_get(), but no oops: # rmmod acpi-cpufreq [ 1839.895632] acpi-cpufreq: acpi_cpufreq_exit [ 1839.895637] cpufreq-core: unregistering driver acpi-cpufreq [ 1839.895642] cpufreq-core: unregistering CPU 0 [ 1839.895649] cpufreq-core: __cpufreq_governor for CPU 0, event 2 [ 1839.895661] cpufreq-stats: removing tables [ 1839.895714] cpufreq-core: last reference is dropped [ 1839.895716] cpufreq-core: waiting for dropping of refcount [ 1839.895718] cpufreq-core: wait complete [ 1839.895720] acpi-cpufreq: acpi_cpufreq_cpu_exit [ 1839.895723] freq-table: clearing show_table for cpu 0 [ 1839.895726] cpufreq-core: unregistering CPU 1 [ 1839.895728] cpufreq-core: __cpufreq_governor for CPU 1, event 2 [ 1839.895731] cpufreq-stats: removing tables<--- dprintk on CPUFREQ_REMOVE [ 1839.895741] cpufreq-core: last reference is dropped [ 1839.895744] cpufreq-core: waiting for dropping of refcount [ 1839.895746] cpufreq-core: wait complete [ 1839.895747] acpi-cpufreq: acpi_cpufreq_cpu_exit [ 1839.895749] freq-table: clearing show_table for cpu 1 # cat time_in_state [ 1853.932509] BUG: at lib/kref.c:32 kref_get() [ 1853.932567] [] show_trace_log_lvl+0x1a/0x30 [ 1853.932676] [] show_trace+0x12/0x14 [ 1853.932778] [] dump_stack+0x16/0x18 [ 1853.932880] [] kref_get+0x37/0x40 [ 1853.932986] [] kobject_get+0x15/0x1b [ 1853.933087] [] sysfs_open_file+0x40/0x209 [ 1853.933189] [] __dentry_open+0xc2/0x179 [ 1853.933293] [] nameidata_to_filp+0x27/0x38 [ 1853.933395] [] do_filp_open+0x33/0x3b [ 1853.933498] [] do_sys_open+0x43/0xc7 [ 1853.933600] [] sys_open+0x1c/0x1e [ 1853.933700] [] sysenter_past_esp+0x5d/0x81 [ 1853.933799] === [ 1853.934330] cpufreq-core: last reference is dropped -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix cpufreq_stats attrs removal
On Fri, Mar 30, 2007 at 12:09:03PM +0400, Alexey Dobriyan wrote: On Thu, Mar 22, 2007 at 06:02:01PM +0100, Mattia Dongili wrote: On Wed, Mar 21, 2007 at 08:10:42PM -0800, Andrew Morton wrote: I ain't picky, but as a short-term thing it'd be kinda nice if it didn't oops the kernel. There are other symptoms to this same bug: 1. unload p4-clockmod: /sys/.../cpu0/cpufreq is removed all together 2. load p4-clockmod: /sys/.../cpu0/cpufreq appears but no 'stats' subdir (yes, cpufreq_stats is loaded) 3. rmmod cpufreq_stats: Ooops! Call Trace: [c0183f5b] remove_dir+0x33/0xc4 [c0184fca] remove_files+0x1a/0x28 [c018503b] sysfs_remove_group+0x63/0x71 [f898c38d] cpufreq_stat_cpu_callback+0x51/0x8a [cpufreq_stats] [f898c477] cpufreq_stats_exit+0x47/0x4b [cpufreq_stats] [c012f145] sys_delete_module+0x190/0x1b7 [c0140073] do_wp_page+0x231/0x3e7 [c0102e17] syscall_call+0x7/0xb The problem is cpufreq_stats doesn't know when a cpufreq driver is removed and doesn't cleanup. I guess this affects any setup with cpufreq_stats. The attached patch seems to solve both symptoms and yes... it's quite invasive as it introduce one more cpufreq policy notification (REMOVED). BTW: the patch is against .21-rc4-mm1 but applies with some fuzz to 2.6.20 too Also, it doesn't work. hmmm... odd. I did test that case. Also, using .21-rc5-mm3 (which has that patch applied) and acpi-cpufreq (I don't have that P4 handy now) I actually hit a WARN_ON in kref_get(), but no oops: # rmmod acpi-cpufreq [ 1839.895632] acpi-cpufreq: acpi_cpufreq_exit [ 1839.895637] cpufreq-core: unregistering driver acpi-cpufreq [ 1839.895642] cpufreq-core: unregistering CPU 0 [ 1839.895649] cpufreq-core: __cpufreq_governor for CPU 0, event 2 [ 1839.895661] cpufreq-stats: removing tables [ 1839.895714] cpufreq-core: last reference is dropped [ 1839.895716] cpufreq-core: waiting for dropping of refcount [ 1839.895718] cpufreq-core: wait complete [ 1839.895720] acpi-cpufreq: acpi_cpufreq_cpu_exit [ 1839.895723] freq-table: clearing show_table for cpu 0 [ 1839.895726] cpufreq-core: unregistering CPU 1 [ 1839.895728] cpufreq-core: __cpufreq_governor for CPU 1, event 2 [ 1839.895731] cpufreq-stats: removing tables--- dprintk on CPUFREQ_REMOVE [ 1839.895741] cpufreq-core: last reference is dropped [ 1839.895744] cpufreq-core: waiting for dropping of refcount [ 1839.895746] cpufreq-core: wait complete [ 1839.895747] acpi-cpufreq: acpi_cpufreq_cpu_exit [ 1839.895749] freq-table: clearing show_table for cpu 1 # cat time_in_state [ 1853.932509] BUG: at lib/kref.c:32 kref_get() [ 1853.932567] [c0104b7a] show_trace_log_lvl+0x1a/0x30 [ 1853.932676] [c0105705] show_trace+0x12/0x14 [ 1853.932778] [c010575e] dump_stack+0x16/0x18 [ 1853.932880] [c01dcfba] kref_get+0x37/0x40 [ 1853.932986] [c01dc415] kobject_get+0x15/0x1b [ 1853.933087] [c019ff0b] sysfs_open_file+0x40/0x209 [ 1853.933189] [c01693bc] __dentry_open+0xc2/0x179 [ 1853.933293] [c01694f5] nameidata_to_filp+0x27/0x38 [ 1853.933395] [c0169539] do_filp_open+0x33/0x3b [ 1853.933498] [c0169584] do_sys_open+0x43/0xc7 [ 1853.933600] [c0169640] sys_open+0x1c/0x1e [ 1853.933700] [c0103d24] sysenter_past_esp+0x5d/0x81 [ 1853.933799] === [ 1853.934330] cpufreq-core: last reference is dropped -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix cpufreq_stats attrs removal
On Thu, Mar 22, 2007 at 06:02:01PM +0100, Mattia Dongili wrote: forgot... (should I resend the whole thing?) Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]> -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix cpufreq_stats attrs removal
On Wed, Mar 21, 2007 at 08:10:42PM -0800, Andrew Morton wrote:
> On Wed, 21 Mar 2007 21:00:06 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Mar 21, 2007 at 11:51:04PM -0400, Dave Jones wrote:
> > > On Wed, Mar 21, 2007 at 08:07:53PM -0700, Greg KH wrote:
> > >
> > > > > After modprobe/rmmod cpufreq/stats directory appears but doesn't get
> > > > > removed. Should it?
> > > > Well, one can argue that those stats should never be in sysfs at all
> > > > anyway, I mean come on, a histogram in sysfs? That's, not ok.
> > >
> > > Meh, it's only a cheesy debug thing, so it's not really that big a deal
> > > imo.
> > > it could probably move to debugfs (we didn't have that when it was merged
> > > iirc)
> > > I doubt anyone really cares enough to bother though I wouldn't
> > > be averse to a patch.
> >
> > Yeah, I realize this, I'm not trying to find fault, sorry if it came
> > across that way. And yes, it should move to debugfs some day, but if it
> > does, I'll loose my "what not to put in sysfs" example I use in
> > presentations :)
> >
>
> I ain't picky, but as a short-term thing it'd be kinda nice if it didn't
> oops the kernel.
There are other symptoms to this same bug:
1. unload p4-clockmod: /sys/.../cpu0/cpufreq is removed all together
2. load p4-clockmod: /sys/.../cpu0/cpufreq appears but no 'stats' subdir
(yes, cpufreq_stats is loaded)
3. rmmod cpufreq_stats: Ooops!
Call Trace:
[] remove_dir+0x33/0xc4
[] remove_files+0x1a/0x28
[] sysfs_remove_group+0x63/0x71
[] cpufreq_stat_cpu_callback+0x51/0x8a [cpufreq_stats]
[] cpufreq_stats_exit+0x47/0x4b [cpufreq_stats]
[] sys_delete_module+0x190/0x1b7
[] do_wp_page+0x231/0x3e7
[] syscall_call+0x7/0xb
The problem is cpufreq_stats doesn't know when a cpufreq driver is
removed and doesn't cleanup. I guess this affects any setup with
cpufreq_stats.
The attached patch seems to solve both symptoms and yes... it's quite
invasive as it introduce one more cpufreq policy notification (REMOVED).
BTW: the patch is against .21-rc4-mm1 but applies with some fuzz to
2.6.20 too
diff -rup linux-2.6.20/drivers/cpufreq/cpufreq.c
linux-2.6.20.dirty/drivers/cpufreq/cpufreq.c
--- linux-2.6.20/drivers/cpufreq/cpufreq.c 2007-03-22 17:00:38.0
+0100
+++ linux-2.6.20.dirty/drivers/cpufreq/cpufreq.c2007-03-22
16:51:09.0 +0100
@@ -989,6 +989,10 @@ static int __cpufreq_remove_dev (struct
unlock_policy_rwsem_write(cpu);
+ /* notify of policy cancellation */
+ blocking_notifier_call_chain(_policy_notifier_list,
+ CPUFREQ_REMOVE, data);
+
kobject_unregister(>kobj);
kobject_put(>kobj);
diff -rup linux-2.6.20/drivers/cpufreq/cpufreq_stats.c
linux-2.6.20.dirty/drivers/cpufreq/cpufreq_stats.c
--- linux-2.6.20/drivers/cpufreq/cpufreq_stats.c2007-03-22
17:00:38.0 +0100
+++ linux-2.6.20.dirty/drivers/cpufreq/cpufreq_stats.c 2007-03-22
17:06:24.0 +0100
@@ -257,18 +257,23 @@ static int
cpufreq_stat_notifier_policy (struct notifier_block *nb, unsigned long val,
void *data)
{
- int ret;
+ int ret = 0;
struct cpufreq_policy *policy = data;
struct cpufreq_frequency_table *table;
unsigned int cpu = policy->cpu;
- if (val != CPUFREQ_NOTIFY)
- return 0;
- table = cpufreq_frequency_get_table(cpu);
- if (!table)
- return 0;
- if ((ret = cpufreq_stats_create_table(policy, table)))
- return ret;
- return 0;
+ switch (val) {
+ case CPUFREQ_NOTIFY:
+ table = cpufreq_frequency_get_table(cpu);
+ if (!table)
+ break;
+ ret = cpufreq_stats_create_table(policy, table);
+ break;
+
+ case CPUFREQ_REMOVE:
+ cpufreq_stats_free_table(cpu);
+ break;
+ }
+ return ret;
}
static int
@@ -371,8 +376,7 @@ __exit cpufreq_stats_exit(void)
CPUFREQ_TRANSITION_NOTIFIER);
unregister_hotcpu_notifier(_stat_cpu_notifier);
for_each_online_cpu(cpu) {
- cpufreq_stat_cpu_callback(_stat_cpu_notifier,
- CPU_DEAD, (void *)(long)cpu);
+ cpufreq_stats_free_table(cpu);
}
}
--- linux-2.6.20/include/linux/cpufreq.h2007-03-22 17:00:47.0
+0100
+++ linux-2.6.20.dirty/include/linux/cpufreq.h 2007-03-22 16:10:37.0
+0100
@@ -96,6 +96,7 @@ struct cpufreq_policy {
#define CPUFREQ_ADJUST (0)
#define CPUFREQ_INCOMPATIBLE (1)
#define CPUFREQ_NOTIFY (2)
+#define CPUFREQ_REMOVE (3)
#define CPUFREQ_SHARED_TYPE_NONE (0) /* None */
#define CPUFREQ_SHARED_TYPE_HW (1) /* HW does needed coordination */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH] fix cpufreq_stats attrs removal
On Wed, Mar 21, 2007 at 08:10:42PM -0800, Andrew Morton wrote:
On Wed, 21 Mar 2007 21:00:06 -0700 Greg KH [EMAIL PROTECTED] wrote:
On Wed, Mar 21, 2007 at 11:51:04PM -0400, Dave Jones wrote:
On Wed, Mar 21, 2007 at 08:07:53PM -0700, Greg KH wrote:
After modprobe/rmmod cpufreq/stats directory appears but doesn't get
removed. Should it?
Well, one can argue that those stats should never be in sysfs at all
anyway, I mean come on, a histogram in sysfs? That's, not ok.
Meh, it's only a cheesy debug thing, so it's not really that big a deal
imo.
it could probably move to debugfs (we didn't have that when it was merged
iirc)
I doubt anyone really cares enough to bother though I wouldn't
be averse to a patch.
Yeah, I realize this, I'm not trying to find fault, sorry if it came
across that way. And yes, it should move to debugfs some day, but if it
does, I'll loose my what not to put in sysfs example I use in
presentations :)
I ain't picky, but as a short-term thing it'd be kinda nice if it didn't
oops the kernel.
There are other symptoms to this same bug:
1. unload p4-clockmod: /sys/.../cpu0/cpufreq is removed all together
2. load p4-clockmod: /sys/.../cpu0/cpufreq appears but no 'stats' subdir
(yes, cpufreq_stats is loaded)
3. rmmod cpufreq_stats: Ooops!
Call Trace:
[c0183f5b] remove_dir+0x33/0xc4
[c0184fca] remove_files+0x1a/0x28
[c018503b] sysfs_remove_group+0x63/0x71
[f898c38d] cpufreq_stat_cpu_callback+0x51/0x8a [cpufreq_stats]
[f898c477] cpufreq_stats_exit+0x47/0x4b [cpufreq_stats]
[c012f145] sys_delete_module+0x190/0x1b7
[c0140073] do_wp_page+0x231/0x3e7
[c0102e17] syscall_call+0x7/0xb
The problem is cpufreq_stats doesn't know when a cpufreq driver is
removed and doesn't cleanup. I guess this affects any setup with
cpufreq_stats.
The attached patch seems to solve both symptoms and yes... it's quite
invasive as it introduce one more cpufreq policy notification (REMOVED).
BTW: the patch is against .21-rc4-mm1 but applies with some fuzz to
2.6.20 too
diff -rup linux-2.6.20/drivers/cpufreq/cpufreq.c
linux-2.6.20.dirty/drivers/cpufreq/cpufreq.c
--- linux-2.6.20/drivers/cpufreq/cpufreq.c 2007-03-22 17:00:38.0
+0100
+++ linux-2.6.20.dirty/drivers/cpufreq/cpufreq.c2007-03-22
16:51:09.0 +0100
@@ -989,6 +989,10 @@ static int __cpufreq_remove_dev (struct
unlock_policy_rwsem_write(cpu);
+ /* notify of policy cancellation */
+ blocking_notifier_call_chain(cpufreq_policy_notifier_list,
+ CPUFREQ_REMOVE, data);
+
kobject_unregister(data-kobj);
kobject_put(data-kobj);
diff -rup linux-2.6.20/drivers/cpufreq/cpufreq_stats.c
linux-2.6.20.dirty/drivers/cpufreq/cpufreq_stats.c
--- linux-2.6.20/drivers/cpufreq/cpufreq_stats.c2007-03-22
17:00:38.0 +0100
+++ linux-2.6.20.dirty/drivers/cpufreq/cpufreq_stats.c 2007-03-22
17:06:24.0 +0100
@@ -257,18 +257,23 @@ static int
cpufreq_stat_notifier_policy (struct notifier_block *nb, unsigned long val,
void *data)
{
- int ret;
+ int ret = 0;
struct cpufreq_policy *policy = data;
struct cpufreq_frequency_table *table;
unsigned int cpu = policy-cpu;
- if (val != CPUFREQ_NOTIFY)
- return 0;
- table = cpufreq_frequency_get_table(cpu);
- if (!table)
- return 0;
- if ((ret = cpufreq_stats_create_table(policy, table)))
- return ret;
- return 0;
+ switch (val) {
+ case CPUFREQ_NOTIFY:
+ table = cpufreq_frequency_get_table(cpu);
+ if (!table)
+ break;
+ ret = cpufreq_stats_create_table(policy, table);
+ break;
+
+ case CPUFREQ_REMOVE:
+ cpufreq_stats_free_table(cpu);
+ break;
+ }
+ return ret;
}
static int
@@ -371,8 +376,7 @@ __exit cpufreq_stats_exit(void)
CPUFREQ_TRANSITION_NOTIFIER);
unregister_hotcpu_notifier(cpufreq_stat_cpu_notifier);
for_each_online_cpu(cpu) {
- cpufreq_stat_cpu_callback(cpufreq_stat_cpu_notifier,
- CPU_DEAD, (void *)(long)cpu);
+ cpufreq_stats_free_table(cpu);
}
}
--- linux-2.6.20/include/linux/cpufreq.h2007-03-22 17:00:47.0
+0100
+++ linux-2.6.20.dirty/include/linux/cpufreq.h 2007-03-22 16:10:37.0
+0100
@@ -96,6 +96,7 @@ struct cpufreq_policy {
#define CPUFREQ_ADJUST (0)
#define CPUFREQ_INCOMPATIBLE (1)
#define CPUFREQ_NOTIFY (2)
+#define CPUFREQ_REMOVE (3)
#define CPUFREQ_SHARED_TYPE_NONE (0) /* None */
#define CPUFREQ_SHARED_TYPE_HW (1) /* HW does needed coordination */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH] fix cpufreq_stats attrs removal
On Thu, Mar 22, 2007 at 06:02:01PM +0100, Mattia Dongili wrote: forgot... (should I resend the whole thing?) Signed-off-by: Mattia Dongili [EMAIL PROTECTED] -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 10:09:59PM +0100, Pavel Machek wrote: > Hi! > > > > > commit 4465857d5f99079bae00621626adf74ed8256296 > > > > Author: Mattia Dongili <[EMAIL PROTECTED]> > > > > Date: Sat Jan 13 23:04:39 2007 +0100 > > > > > > > > sony_acpi: Add lanpower and audiopower controls > > > > > > > > audiopower works well on my SZ72B so it's not marked has "debug" > > > > while lanpower > > > > has at least one report of not resuming power happily so morked as > > > > "debug" > > > > > > > > Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]> > > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > > > > > What is interface to these? It would be nice to automagically disable > > > audiopower when sound device is closed, and automagically power down > > > lan on ifconfig ... down. > > > > the audiopower is basically a _PS3/_PS0 switch for the device, while the > > lanpower plays with the embedded controller to powerdown/powerup. > > > > Now, unfortunately those methods are attached to a fake device in the > > DSDT and afaict there's no way to tell which real device they are > > playing with (except by inspecting the method implementations). > > > Well of course iff there's only _one_ sound card and _one_ nic you can > > easily guess it :) > > Hmm... you are on sony notebook... right? That means it is very likely > it has just one sound card, and just one ethernet, no? I was thinking about hotpluggable audio/nic (pcmcia, usb). Anyway I have a sky2 and ipw3945 and yes, just one sound card :) -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 01:17:53PM +, Matthew Garrett wrote: > On Tue, Mar 06, 2007 at 01:22:13PM +0100, Mattia Dongili wrote: > > > the audiopower is basically a _PS3/_PS0 switch for the device, while the > > lanpower plays with the embedded controller to powerdown/powerup. > > > > Now, unfortunately those methods are attached to a fake device in the > > DSDT and afaict there's no way to tell which real device they are > > playing with (except by inspecting the method implementations). > > Well of course iff there's only _one_ sound card and _one_ nic you can > > easily guess it :) > > > > Is there some way to hook into drivers for such kind of runtime power > > management? > > Before worrying, I think it would make more sense to instrument the > benefit gained against doing more "traditional" runtime management - > that is, simply shutting down the ethernet chipset or doing ac97 power > management. It's trivial to add those to the existing drivers, and if Can't tell about chipset specific management, but as far as ACPI is concerned, this Sony specific stuff is a nice way of hiding features behind an undocumented device. Eg: the sound card _PS3 is empty and only available through that AZPW method.[1] So I guess that the platform_pci_set_power_state for ACPI D3 is basically a no-op there. > the additional benefit of using the Sony-specific methods is small then > it's probably not really worth working out how to add it in. Yep, will try to get some measurement (by means of the acpi battery status, no better way currently available here) but given the above I suspect there's some benefit. > Plus, implementing the generic support benefits more people :) Yes, of course. [1]: if you want to make a an idea, one such DSDT is available here: http://oioio.altervista.org/linux/DSDT.sz72b.dsl sony-laptop basically exposes the Device(SNC) and AZPW/GAZP for the audio (an hda) and LNPW/GLNP for the nic (a sky2). Now see the audio device Device(HDEF) and its _PS0 and _PS3. PS: did I disappear from the Cc list? ;) -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Jan 01, 2002 at 04:57:52AM +, Pavel Machek wrote: > Hi! > > > commit 4465857d5f99079bae00621626adf74ed8256296 > > Author: Mattia Dongili <[EMAIL PROTECTED]> > > Date: Sat Jan 13 23:04:39 2007 +0100 > > > > sony_acpi: Add lanpower and audiopower controls > > > > audiopower works well on my SZ72B so it's not marked has "debug" while > > lanpower > > has at least one report of not resuming power happily so morked as > > "debug" > > > > Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]> > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > What is interface to these? It would be nice to automagically disable > audiopower when sound device is closed, and automagically power down > lan on ifconfig ... down. the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Is there some way to hook into drivers for such kind of runtime power management? PS: lanpower currently seems to be a little too invasive (or it's just ACPI that reacts badly) because switching off lanpower also disables the pic link and never comes back. I need to better diagnose what's happening and report to linux-acpi. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Jan 01, 2002 at 04:57:52AM +, Pavel Machek wrote: Hi! commit 4465857d5f99079bae00621626adf74ed8256296 Author: Mattia Dongili [EMAIL PROTECTED] Date: Sat Jan 13 23:04:39 2007 +0100 sony_acpi: Add lanpower and audiopower controls audiopower works well on my SZ72B so it's not marked has debug while lanpower has at least one report of not resuming power happily so morked as debug Signed-off-by: Mattia Dongili [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] What is interface to these? It would be nice to automagically disable audiopower when sound device is closed, and automagically power down lan on ifconfig ... down. the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Is there some way to hook into drivers for such kind of runtime power management? PS: lanpower currently seems to be a little too invasive (or it's just ACPI that reacts badly) because switching off lanpower also disables the pic link and never comes back. I need to better diagnose what's happening and report to linux-acpi. -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 01:17:53PM +, Matthew Garrett wrote: On Tue, Mar 06, 2007 at 01:22:13PM +0100, Mattia Dongili wrote: the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Is there some way to hook into drivers for such kind of runtime power management? Before worrying, I think it would make more sense to instrument the benefit gained against doing more traditional runtime management - that is, simply shutting down the ethernet chipset or doing ac97 power management. It's trivial to add those to the existing drivers, and if Can't tell about chipset specific management, but as far as ACPI is concerned, this Sony specific stuff is a nice way of hiding features behind an undocumented device. Eg: the sound card _PS3 is empty and only available through that AZPW method.[1] So I guess that the platform_pci_set_power_state for ACPI D3 is basically a no-op there. the additional benefit of using the Sony-specific methods is small then it's probably not really worth working out how to add it in. Yep, will try to get some measurement (by means of the acpi battery status, no better way currently available here) but given the above I suspect there's some benefit. Plus, implementing the generic support benefits more people :) Yes, of course. [1]: if you want to make a an idea, one such DSDT is available here: http://oioio.altervista.org/linux/DSDT.sz72b.dsl sony-laptop basically exposes the Device(SNC) and AZPW/GAZP for the audio (an hda) and LNPW/GLNP for the nic (a sky2). Now see the audio device Device(HDEF) and its _PS0 and _PS3. PS: did I disappear from the Cc list? ;) -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21 - part II (resend)
On Tue, Mar 06, 2007 at 10:09:59PM +0100, Pavel Machek wrote: Hi! commit 4465857d5f99079bae00621626adf74ed8256296 Author: Mattia Dongili [EMAIL PROTECTED] Date: Sat Jan 13 23:04:39 2007 +0100 sony_acpi: Add lanpower and audiopower controls audiopower works well on my SZ72B so it's not marked has debug while lanpower has at least one report of not resuming power happily so morked as debug Signed-off-by: Mattia Dongili [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] What is interface to these? It would be nice to automagically disable audiopower when sound device is closed, and automagically power down lan on ifconfig ... down. the audiopower is basically a _PS3/_PS0 switch for the device, while the lanpower plays with the embedded controller to powerdown/powerup. Now, unfortunately those methods are attached to a fake device in the DSDT and afaict there's no way to tell which real device they are playing with (except by inspecting the method implementations). Well of course iff there's only _one_ sound card and _one_ nic you can easily guess it :) Hmm... you are on sony notebook... right? That means it is very likely it has just one sound card, and just one ethernet, no? I was thinking about hotpluggable audio/nic (pcmcia, usb). Anyway I have a sky2 and ipw3945 and yes, just one sound card :) -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: Oops in generic_make_request
On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > Le 18.02.2007 06:51, Andrew Morton a écrit : > >Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > >Will appear later at > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > Hello, I've got a fully reproducible Oops. I just have to boot to > runlevel 2 and wait less than one minute. Maybe this oops is related too? Can't yet tell if it's easily reproducible, this is on a JFS filesystem. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c02206aa *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:00.0/class CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010297 (2.6.20-mm2-1 #1) EIP is at __make_request+0x13a/0x390 eax: ebx: ecx: 042b0dd8 edx: 00010485 esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 Call Trace: [] show_trace_log_lvl+0x1a/0x30 [] show_stack_log_lvl+0xa9/0xd0 [] show_registers+0x206/0x350 [] die+0x10e/0x210 [] do_page_fault+0x2d2/0x600 [] error_code+0x74/0x7c [] generic_make_request+0x15a/0x200 [] submit_bio+0x58/0xe0 [] metapage_writepage+0x18f/0x1b0 [] __writepage+0xb/0x30 [] write_cache_pages+0x22f/0x300 [] generic_writepages+0x23/0x30 [] do_writepages+0x5c/0x60 [] __filemap_fdatawrite_range+0x67/0x80 [] filemap_flush+0x25/0x30 [] lmLogSync+0x19d/0x230 [] lmLog+0x5e/0x190 [] txCommit+0x8c0/0x1010 [] jfs_create+0x324/0x370 [] vfs_create+0xaf/0x100 [] open_namei+0x58c/0x640 [] do_filp_open+0x2c/0x50 [] do_sys_open+0x47/0xe0 [] sys_open+0x1c/0x20 [] syscall_call+0x7/0xb === Code: 5d c3 8b 58 18 8b 43 04 0f 18 00 90 8b 7d e8 83 c7 14 39 fb 75 2 4 e9 2d ff ff ff 8d b6 00 00 00 00 48 0f 84 d9 00 00 00 8b 5b 04 <8b> 43 04 0f 18 00 90 39 fb 0f 84 0e ff ff ff 89 f2 89 d8 e8 2e EIP: [] __make_request+0x13a/0x390 SS:ESP 0068:c653dabc -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2: Oops in generic_make_request
On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: Le 18.02.2007 06:51, Andrew Morton a écrit : Temporarily at http://userweb.kernel.org/~akpm/2.6.20-mm2/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ Hello, I've got a fully reproducible Oops. I just have to boot to runlevel 2 and wait less than one minute. Maybe this oops is related too? Can't yet tell if it's easily reproducible, this is on a JFS filesystem. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c02206aa *pde = Oops: [#1] PREEMPT last sysfs file: /devices/pci:00/:00:00.0/class CPU:0 EIP:0060:[c02206aa]Not tainted VLI EFLAGS: 00010297 (2.6.20-mm2-1 #1) EIP is at __make_request+0x13a/0x390 eax: ebx: ecx: 042b0dd8 edx: 00010485 esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 Call Trace: [c01048ba] show_trace_log_lvl+0x1a/0x30 [c0104979] show_stack_log_lvl+0xa9/0xd0 [c0104ba6] show_registers+0x206/0x350 [c0104dfe] die+0x10e/0x210 [c0114652] do_page_fault+0x2d2/0x600 [c0351f84] error_code+0x74/0x7c [c021e0ca] generic_make_request+0x15a/0x200 [c0220318] submit_bio+0x58/0xe0 [c0205d0f] metapage_writepage+0x18f/0x1b0 [c014cc2b] __writepage+0xb/0x30 [c014d20f] write_cache_pages+0x22f/0x300 [c014d303] generic_writepages+0x23/0x30 [c014d36c] do_writepages+0x5c/0x60 [c0148307] __filemap_fdatawrite_range+0x67/0x80 [c0149785] filemap_flush+0x25/0x30 [c02080cd] lmLogSync+0x19d/0x230 [c020871e] lmLog+0x5e/0x190 [c020a360] txCommit+0x8c0/0x1010 [c01eecf4] jfs_create+0x324/0x370 [c016f38f] vfs_create+0xaf/0x100 [c017269c] open_namei+0x58c/0x640 [c0165b7c] do_filp_open+0x2c/0x50 [c0165be7] do_sys_open+0x47/0xe0 [c0165cbc] sys_open+0x1c/0x20 [c01041c0] syscall_call+0x7/0xb === Code: 5d c3 8b 58 18 8b 43 04 0f 18 00 90 8b 7d e8 83 c7 14 39 fb 75 2 4 e9 2d ff ff ff 8d b6 00 00 00 00 48 0f 84 d9 00 00 00 8b 5b 04 8b 43 04 0f 18 00 90 39 fb 0f 84 0e ff ff ff 89 f2 89 d8 e8 2e EIP: [c02206aa] __make_request+0x13a/0x390 SS:ESP 0068:c653dabc -- mattia :wq! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
