В Tue, 29 Jul 2014 14:23:54 +0200
Michal Marek пишет:
> On 2014-07-29 12:18, Richard Weinberger wrote:
> > Hi!
> >
> > I'm not sure who to blame, but the below commit breaks the kernel binrpm
> > target for me.
> > It produces a faulty grub2 config.
> > After installing such a kernel grub2
В Tue, 29 Jul 2014 14:23:54 +0200
Michal Marek mma...@suse.cz пишет:
On 2014-07-29 12:18, Richard Weinberger wrote:
Hi!
I'm not sure who to blame, but the below commit breaks the kernel binrpm
target for me.
It produces a faulty grub2 config.
After installing such a kernel grub2
В Wed, 23 Oct 2013 16:07:38 +0200
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> > - Do the signature verification (hand-waving which one - probably both).
> Can someone throw me the link on the EFI signature specification? Can't
> really find it now.
It is in UEFI specs, specifically chapter
В Wed, 23 Oct 2013 16:07:38 +0200
Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com пишет:
- Do the signature verification (hand-waving which one - probably both).
Can someone throw me the link on the EFI signature specification? Can't
really find it now.
It is in UEFI specs,
В Mon, 21 Oct 2013 23:16:24 +0200
Vladimir 'φ-coder/phcoder' Serbinenko пишет:
> GRUB has generic support for signing kernels/modules/whatsoever using
> GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
> method doesn't have any controversy associated with EFI stuff but at
>
В Mon, 21 Oct 2013 23:16:24 +0200
Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com пишет:
GRUB has generic support for signing kernels/modules/whatsoever using
GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
method doesn't have any controversy associated with EFI
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0xec461): Section mismatch in reference from the
function pci_scan_child_bus() to the function .devinit.text:pcibios_fixup_bus()
The function pci_scan_child_bus() references
the function __devinit pcibios_fixup_bus().
This is often because
During compilation:
LD [M] drivers/pcmcia/pcmcia_core.o
WARNING: drivers/pcmcia/pcmcia_core.o(.data+0x1d4): Section mismatch in
reference from the variable pccard_sysfs_interface to the function
.devinit.text:pccard_sysfs_add_socket()
The variable pccard_sysfs_interface references
the
During compilation:
LD [M] drivers/pcmcia/pcmcia_core.o
WARNING: drivers/pcmcia/pcmcia_core.o(.data+0x1d4): Section mismatch in
reference from the variable pccard_sysfs_interface to the function
.devinit.text:pccard_sysfs_add_socket()
The variable pccard_sysfs_interface references
the
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0xec461): Section mismatch in reference from the
function pci_scan_child_bus() to the function .devinit.text:pcibios_fixup_bus()
The function pci_scan_child_bus() references
the function __devinit pcibios_fixup_bus().
This is often because
Subject: [PATCH] ACPI: add ACPI aliases to toshiba_acpi module
From: Andrey Borzenkov < [EMAIL PROTECTED]>
This adds aliases to enable autoloading of toishiba_acpi. Two aliases
are defined - TOS6200 (for \\_SB_.VALD.GHCI) and TSO1900 (for
\\_SB_.VALZ.GHCI). This allows toishib
Subject: [PATCH] ACPI: add ACPI aliases to toshiba_acpi module
From: Andrey Borzenkov [EMAIL PROTECTED]
This adds aliases to enable autoloading of toishiba_acpi. Two aliases
are defined - TOS6200 (for \\_SB_.VALD.GHCI) and TSO1900 (for
\\_SB_.VALZ.GHCI). This allows toishiba_acpi
Jeff Garzik wrote:
>> If this is the prefered driver these days, maybe it shouldn't be marked
>> experimental in the menu anymore?
>
> It's not marked experimental.
>
the comment on the very top of drivers/ata says:
tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers"
this is
Jeff Garzik wrote:
If this is the prefered driver these days, maybe it shouldn't be marked
experimental in the menu anymore?
It's not marked experimental.
the comment on the very top of drivers/ata says:
tristate Serial ATA (prod) and Parallel ATA (experimental) drivers
this is a bit
On Thursday 21 February 2008, Kok, Auke wrote:
> Kok, Auke wrote:
> > Kok, Auke wrote:
> >> Andrew Morton wrote:
> >>> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]>
> >>> wrote:
> >>>
> >>&g
On Thursday 21 February 2008, Kok, Auke wrote:
Kok, Auke wrote:
Kok, Auke wrote:
Andrew Morton wrote:
On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov [EMAIL PROTECTED]
wrote:
... and possibly reboot/poweroff (it flows by too fast to be legible).
[ 8803.850634] ACPI: Preparing
On Monday 18 February 2008, Andrew Morton wrote:
> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
>
> > ... and possibly reboot/poweroff (it flows by too fast to be legible).
> >
> > [ 8803.850634] ACPI: Preparing to enter system sl
On Monday 18 February 2008, Andrew Morton wrote:
On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov [EMAIL PROTECTED] wrote:
... and possibly reboot/poweroff (it flows by too fast to be legible).
[ 8803.850634] ACPI: Preparing to enter system sleep state S3
[ 8803.853141] Suspending
Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10002
> Subject : wpa_supplicant doens't work and froze the computer
> Submitter : François Valenduc <[EMAIL PROTECTED]>
> Date : 2008-02-16 08:25
>
[...]
> Bug-Entry :
On Sunday 17 February 2008, Rafael J. Wysocki wrote:
> On Sunday, 17 of February 2008, Andrey Borzenkov wrote:
> > In 2.6.25 I get stack trace immediately before system is switched off or
> > reboots. It is too fast to capture it on VGA; netconsole does not capture
> > it eith
In 2.6.25 I get stack trace immediately before system is switched off or
reboots. It is too fast to capture it on VGA; netconsole does not capture
it either - probably network is already shutdown at this point. I do
not have serial port on this system.
Any idea how could I capture it? Thank you.
In 2.6.25 I get stack trace immediately before system is switched off or
reboots. It is too fast to capture it on VGA; netconsole does not capture
it either - probably network is already shutdown at this point. I do
not have serial port on this system.
Any idea how could I capture it? Thank you.
On Sunday 17 February 2008, Rafael J. Wysocki wrote:
On Sunday, 17 of February 2008, Andrey Borzenkov wrote:
In 2.6.25 I get stack trace immediately before system is switched off or
reboots. It is too fast to capture it on VGA; netconsole does not capture
it either - probably network
Rafael J. Wysocki wrote:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10002
Subject : wpa_supplicant doens't work and froze the computer
Submitter : François Valenduc [EMAIL PROTECTED]
Date : 2008-02-16 08:25
[...]
Bug-Entry :
] (dev_base_lock){-.--}, at: [] do_setlink+0x327/0x3
[ 58.100672]
[ 58.100672] but task is already holding lock:
[ 58.100672] (dev_base_lock){-.--}, at: [] do_setlink+0x310/0x3
with final effect
[ 58.537509] Kernel panic - not syncing: Aiee, killing interrupt handler!
Signed-off-by: Andrey
-off-by: Andrey Borzenkov [EMAIL PROTECTED]
---
net/core/rtnetlink.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ecb02af..dd9e4da 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -853,7 +853,7 @@ static
Ondrej Zary wrote:
> On Tuesday 29 January 2008 11:43:53 Michael Tokarev wrote:
>> Stephen Hemminger wrote:
>> > On Tue, 29 Jan 2008 03:46:08 +0300
>> > Michael Tokarev <[EMAIL PROTECTED]> wrote:
>>
>> []
>>
>> >> There are 2 drivers for 8139-based NICs. For really different two
>> >> kinds
>>
Ondrej Zary wrote:
On Tuesday 29 January 2008 11:43:53 Michael Tokarev wrote:
Stephen Hemminger wrote:
On Tue, 29 Jan 2008 03:46:08 +0300
Michael Tokarev [EMAIL PROTECTED] wrote:
[]
There are 2 drivers for 8139-based NICs. For really different two
kinds
of hardware, which both
On Monday 28 January 2008, Gene Heskett wrote:
> On Monday 28 January 2008, Andrey Borzenkov wrote:
> >Richard Heck wrote:
> >> Daniel Barkalow wrote:
> >>> Can you switch back to old IDE to get your work done (and to make sure
> >>> it's not
Richard Heck wrote:
> Daniel Barkalow wrote:
>> Can you switch back to old IDE to get your work done (and to make sure
>> it's not a hardware issue that's developed recently)?
> I think it'd be really, REALLY helpful to a lot of people if you, or
> someone, could explain in moderate detail how
On Monday 28 January 2008, Gene Heskett wrote:
On Monday 28 January 2008, Andrey Borzenkov wrote:
Richard Heck wrote:
Daniel Barkalow wrote:
Can you switch back to old IDE to get your work done (and to make sure
it's not a hardware issue that's developed recently)?
I think it'd
Richard Heck wrote:
Daniel Barkalow wrote:
Can you switch back to old IDE to get your work done (and to make sure
it's not a hardware issue that's developed recently)?
I think it'd be really, REALLY helpful to a lot of people if you, or
someone, could explain in moderate detail how this
Michael Tokarev wrote:
> Dmitry Torokhov wrote:
>> Hi Michael,
>
> Hello!
>
> []
>> There are keyboards (USB, PS2) with Sleep and Suspend buttons
>> that are not related to ACPI nor APM. We had 2 options - add
>> an input handler that would translate input events into ACPI
>> events and feed
Michael Tokarev wrote:
Dmitry Torokhov wrote:
Hi Michael,
Hello!
[]
There are keyboards (USB, PS2) with Sleep and Suspend buttons
that are not related to ACPI nor APM. We had 2 options - add
an input handler that would translate input events into ACPI
events and feed
Andrew Morton wrote:
> On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote:
>
>>
>>
>> The second util-linux-ng 2.13.1 release candidate is available at
>>
>> ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/
>>
>
> Interesting. Thanks. Which distros are using
Andrew Morton wrote:
On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak [EMAIL PROTECTED] wrote:
The second util-linux-ng 2.13.1 release candidate is available at
ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/
Interesting. Thanks. Which distros are using this, or plan to do
On Friday 04 January 2008, Andrew Patterson wrote:
> On Thu, 2008-01-03 at 17:17 -0700, Andrew Patterson wrote:
> > On Fri, 2008-01-04 at 09:07 +0900, Tejun Heo wrote:
> > > Hello,
> > >
> > > Andrew Patterson wrote:
> > > > It looks like this is a shell issue. After looking through the sysfs
>
On Friday 04 January 2008, Andrew Patterson wrote:
On Thu, 2008-01-03 at 17:17 -0700, Andrew Patterson wrote:
On Fri, 2008-01-04 at 09:07 +0900, Tejun Heo wrote:
Hello,
Andrew Patterson wrote:
It looks like this is a shell issue. After looking through the sysfs
code, I
On Wednesday 02 January 2008, Alexey Starikovskiy wrote:
> Andrey Borzenkov wrote:
> > This is did not happen before; I am not sure right now what caused this
(i.e.
> > battery aging or some software change) nor whether this is
kernel/HAL/kpowersave
> > issue.
> &
This is did not happen before; I am not sure right now what caused this (i.e.
battery aging or some software change) nor whether this is
kernel/HAL/kpowersave
issue.
kpowersave is stuck at assuming battery is loading and at 94%. Sysfs displays
battery state as Full:
UEVENT[1199264702.345795]
This is did not happen before; I am not sure right now what caused this (i.e.
battery aging or some software change) nor whether this is
kernel/HAL/kpowersave
issue.
kpowersave is stuck at assuming battery is loading and at 94%. Sysfs displays
battery state as Full:
UEVENT[1199264702.345795]
On Wednesday 02 January 2008, Alexey Starikovskiy wrote:
Andrey Borzenkov wrote:
This is did not happen before; I am not sure right now what caused this
(i.e.
battery aging or some software change) nor whether this is
kernel/HAL/kpowersave
issue.
kpowersave is stuck at assuming
Jeff Garzik wrote:
> Neil Brown wrote:
>> I've been looking at use BIO_RW_FAILFAST in md/raid to improve
>> handling of some error cases.
>>
>> This is particularly significant for the DASD driver (s390 specific).
>> I believe it uses optic fibre to connect to the drives. When one of
>> these
Jeff Garzik wrote:
Neil Brown wrote:
I've been looking at use BIO_RW_FAILFAST in md/raid to improve
handling of some error cases.
This is particularly significant for the DASD driver (s390 specific).
I believe it uses optic fibre to connect to the drives. When one of
these paths is
On Sunday 25 November 2007, Robert Hancock wrote:
> Andrey Borzenkov wrote:
> > I have no COM port on notebook (without port replicator which I do not have)
> > so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
> > created) but I just noticed that ser
On Sunday 25 November 2007, Robert Hancock wrote:
Andrey Borzenkov wrote:
I have no COM port on notebook (without port replicator which I do not have)
so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
created) but I just noticed that serial modules are still loaded
: registering new device pcmcia0.0
[ 131.679901] wlags49_h1_cs v7.18 for PCMCIA, 03/31/2004 14:31:00 by Agere
Systems, http://www.agere.com
[ 131.679927] *** Modified for kernel 2.6 by Andrey Borzenkov <[EMAIL
PROTECTED]> $Revision: 39 $
[ 131.679936] *** Station Mode (STA) Support: YE
://www.agere.com
[ 131.679927] *** Modified for kernel 2.6 by Andrey Borzenkov [EMAIL
PROTECTED] $Revision: 39 $
[ 131.679936] *** Station Mode (STA) Support: YES
[ 131.679941] *** Access Point Mode (AP) Support: YES
[ 132.410786] eth1: PRI 31 variant 2 version 9.48
[ 132.410855] eth1: NIC 5 variant 2
On Sunday 09 September 2007, Rafael J. Wysocki wrote:
> On Sunday, 9 September 2007 16:00, Andrey Borzenkov wrote:
> > On Sunday 01 July 2007, Rafael J. Wysocki wrote:
> > > On Saturday, 30 June 2007 06:59, Andrey Borzenkov wrote:
> > > > Since 2.6.18 I do not
Pavel Machek wrote:
> Hi!
>
>> > > > It works. Subjectively I have relatively long pause after first
>> > > > Suspending console message (where it hangs otherwise), according to
>> > > > dmesg timestamp it is about 1 second before next messages appear.
>> > > > Also last two times I tried it
On Sunday 09 September 2007, Rafael J. Wysocki wrote:
On Sunday, 9 September 2007 16:00, Andrey Borzenkov wrote:
On Sunday 01 July 2007, Rafael J. Wysocki wrote:
On Saturday, 30 June 2007 06:59, Andrey Borzenkov wrote:
Since 2.6.18 I do not have suspend to RAM; now I am starting to lose
Pavel Machek wrote:
Hi!
It works. Subjectively I have relatively long pause after first
Suspending console message (where it hangs otherwise), according to
dmesg timestamp it is about 1 second before next messages appear.
Also last two times I tried it writeout of suspend image
On Sunday 11 November 2007, Rafael J. Wysocki wrote:
> On Sunday, 11 of November 2007, Andrey Borzenkov wrote:
> > On Sunday 11 November 2007, Rafael J. Wysocki wrote:
> > > On Sunday, 11 of November 2007, Andrey Borzenkov wrote:
> > > > On Monday 05 Novembe
Kristoffer Ericson wrote:
> Greetings,
>
> Ive been following your discussion and documentation efforts concerning pm
> in the kernel. This has in the past been a gray area which was hard to
> find information about so kudos.
>
> I maintain 2 handheld platforms that would benefit greatly from
>
Kristoffer Ericson wrote:
Greetings,
Ive been following your discussion and documentation efforts concerning pm
in the kernel. This has in the past been a gray area which was hard to
find information about so kudos.
I maintain 2 handheld platforms that would benefit greatly from
On Sunday 11 November 2007, Rafael J. Wysocki wrote:
On Sunday, 11 of November 2007, Andrey Borzenkov wrote:
On Sunday 11 November 2007, Rafael J. Wysocki wrote:
On Sunday, 11 of November 2007, Andrey Borzenkov wrote:
On Monday 05 November 2007, Andrey Borzenkov wrote:
Notice hung
On Friday 26 October 2007, Alan Cox wrote:
> On Fri, 26 Oct 2007 21:30:02 +0400
> Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
>
> > Running legacy IDE drivers apparently works in DMA mode for both:
>
> Thanks - can you send me an lspci -vvxxx off list
>
BT
On Sunday 11 November 2007, Rafael J. Wysocki wrote:
> On Sunday, 11 of November 2007, Andrey Borzenkov wrote:
> > On Monday 05 November 2007, Andrey Borzenkov wrote:
> > > Notice "hung" not "hangs". This happened so far only once - when low
> >
On Sunday 11 November 2007, Rafael J. Wysocki wrote:
On Sunday, 11 of November 2007, Andrey Borzenkov wrote:
On Monday 05 November 2007, Andrey Borzenkov wrote:
Notice hung not hangs. This happened so far only once - when low
battery
condition triggered suspend to disk. I
On Friday 26 October 2007, Alan Cox wrote:
On Fri, 26 Oct 2007 21:30:02 +0400
Andrey Borzenkov [EMAIL PROTECTED] wrote:
Running legacy IDE drivers apparently works in DMA mode for both:
Thanks - can you send me an lspci -vvxxx off list
BTW in rc2 it does not even boot - it babbles
Alexey, this fixes my patch that went into -rc2. Sorry for Oops.
Subject: [PATCH] 2.6.24-rc2: do not unregister power_supply in sysfs ->show
method
From: Andrey Borzenkov <[EMAIL PROTECTED]>
Currently unplugging battery oopses with call stack:
[ 2245.375393] [] show_trace_log_lvl+
Alexey, this fixes my patch that went into -rc2. Sorry for Oops.
Subject: [PATCH] 2.6.24-rc2: do not unregister power_supply in sysfs -show
method
From: Andrey Borzenkov [EMAIL PROTECTED]
Currently unplugging battery oopses with call stack:
[ 2245.375393] [c010488a] show_trace_log_lvl+0x1a
Notice "hung" not "hangs". This happened so far only once - when low battery
condition triggered suspend to disk. I was not able to reproduce it after
this running on AC.
Just in case it rings the bell for someone. This is not suspend regression
reported earlier by Jens - I do not even have
Notice hung not hangs. This happened so far only once - when low battery
condition triggered suspend to disk. I was not able to reproduce it after
this running on AC.
Just in case it rings the bell for someone. This is not suspend regression
reported earlier by Jens - I do not even have SATA
On Sunday 07 October 2007, Andrey Borzenkov wrote:
> This fixes oops when registering backlight device fails. Attached as I
> still cannot convince kmail to not mangle long lines ...
>
> -andrey
ping ...
Subject: [PATCH] Fix Oops in toshiba_acpi error return path
When backlight_dev
On Sunday 07 October 2007, Andrey Borzenkov wrote:
This fixes oops when registering backlight device fails. Attached as I
still cannot convince kmail to not mangle long lines ...
-andrey
ping ...
Subject: [PATCH] Fix Oops in toshiba_acpi error return path
When backlight_device_register
On Saturday 03 November 2007, Ingo Molnar wrote:
> * Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
> > > # CONFIG_ACPI_PROCFS is not set
> >
> > And if you enable it (ACPI_PROCFS)?
>
> ACPI_PROCFS was newly introduced i think but without a 'default y'
> Kc
On Saturday 03 November 2007, Ingo Molnar wrote:
* Andrey Borzenkov [EMAIL PROTECTED] wrote:
# CONFIG_ACPI_PROCFS is not set
And if you enable it (ACPI_PROCFS)?
ACPI_PROCFS was newly introduced i think but without a 'default y'
Kconfig entry. That was a mistake i think - it broke some
Thomas Meyer wrote:
> i just wanted to report this:
>
> in v2.6.24-rc1-497-gb1d08ac the kde battery icon is no longer displayed.
>
> with 2.6.23 shows the battery icon.
>
> current config:
>
> grep -i acpi .config
> # Power management options (ACPI, APM)
> CONFIG_ACPI=y
> CONFIG_ACPI_SLEEP=y
Thomas Meyer wrote:
i just wanted to report this:
in v2.6.24-rc1-497-gb1d08ac the kde battery icon is no longer displayed.
with 2.6.23 shows the battery icon.
current config:
grep -i acpi .config
# Power management options (ACPI, APM)
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
#
On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
> Andrey Borzenkov wrote:
> > On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
> >> Andrey Borzenkov wrote:
> >>> I suspect new ACPI AC adapter code but have to add some printk's to be
> >>
On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
Andrey Borzenkov wrote:
On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
Andrey Borzenkov wrote:
I suspect new ACPI AC adapter code but have to add some printk's to be
sure.
To reproduce - plug in AC cord, suspend
On Wednesday 31 October 2007, Rafael J. Wysocki wrote:
> On Tuesday, 30 October 2007 20:33, Andrey Borzenkov wrote:
> > Is it valid to send events from within ->resume device method?
>
> It is or at least it should be. The GPEs are supposed to be fully
> fun
On Wednesday 31 October 2007, Rafael J. Wysocki wrote:
> On Tuesday, 30 October 2007 21:24, Andrey Borzenkov wrote:
> > I suspect new ACPI AC adapter code but have to add some printk's to be
> > sure.
> >
> > To reproduce - plug in AC cord, suspend, unplug, resume - kpo
On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
> Andrey Borzenkov wrote:
> > I suspect new ACPI AC adapter code but have to add some printk's to be
> > sure.
> >
> > To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and
> > sysfs still
I suspect new ACPI AC adapter code but have to add some printk's to be sure.
To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and sysfs
still show AC adapter online. Or other way round.
-andrey
signature.asc
Description: This is a digitally signed message part.
Let's make it consistent with battery code; also it fixes HAL case of
duplicated adapters. Somebody will have to sort out HAL with ACPI_PROCFS
case ...
-andrey
Subject: [PATCH] 2.6.24: make /proc/acpi/ac_adapter dependent on ACPI_PROCFS
From: Andrey Borzenkov <[EMAIL PROTECTED]>
Do not p
Is it valid to send events from within ->resume device method? If not, what is
the proper way to notify user space about hardware changes during suspension?
Specifically it seems that new sysfs ACPI power supply interface sometimes
missing plugged in AC cord during suspend. I suspect that no
I realized that in patch for ACPI battery I created perfect example of
self-destructing sysfs attributes. Basically, on every access to battery
properties we check battery status. If ACPI reports battery not present, we
remove sysfs power_supply object. I.e.
-> user space queries e.g.
I realized that in patch for ACPI battery I created perfect example of
self-destructing sysfs attributes. Basically, on every access to battery
properties we check battery status. If ACPI reports battery not present, we
remove sysfs power_supply object. I.e.
- user space queries e.g.
Is it valid to send events from within -resume device method? If not, what is
the proper way to notify user space about hardware changes during suspension?
Specifically it seems that new sysfs ACPI power supply interface sometimes
missing plugged in AC cord during suspend. I suspect that no
Let's make it consistent with battery code; also it fixes HAL case of
duplicated adapters. Somebody will have to sort out HAL with ACPI_PROCFS
case ...
-andrey
Subject: [PATCH] 2.6.24: make /proc/acpi/ac_adapter dependent on ACPI_PROCFS
From: Andrey Borzenkov [EMAIL PROTECTED]
Do not provide
I suspect new ACPI AC adapter code but have to add some printk's to be sure.
To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and sysfs
still show AC adapter online. Or other way round.
-andrey
signature.asc
Description: This is a digitally signed message part.
On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
Andrey Borzenkov wrote:
I suspect new ACPI AC adapter code but have to add some printk's to be
sure.
To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and
sysfs still show AC adapter online. Or other way round
On Wednesday 31 October 2007, Rafael J. Wysocki wrote:
On Tuesday, 30 October 2007 20:33, Andrey Borzenkov wrote:
Is it valid to send events from within -resume device method?
It is or at least it should be. The GPEs are supposed to be fully
functional at this point.
If not, what
On Wednesday 31 October 2007, Rafael J. Wysocki wrote:
On Tuesday, 30 October 2007 21:24, Andrey Borzenkov wrote:
I suspect new ACPI AC adapter code but have to add some printk's to be
sure.
To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and
sysfs still show AC
On Sunday 28 October 2007, Andrey Borzenkov wrote:
> On Saturday 27 October 2007, Anton Vorontsov wrote:
> > On Sat, Oct 27, 2007 at 08:54:30PM +0400, Andrey Borzenkov wrote:
> > > I am not exactly sure about this one ... what other power_supply class
> > > drivers d
On Saturday 27 October 2007, Anton Vorontsov wrote:
> On Sat, Oct 27, 2007 at 08:54:30PM +0400, Andrey Borzenkov wrote:
> > I am not exactly sure about this one ... what other power_supply class
> > drivers do? Should I fix HAL instead (but then, I do not know whether HAL
On Saturday 27 October 2007, Anton Vorontsov wrote:
On Sat, Oct 27, 2007 at 08:54:30PM +0400, Andrey Borzenkov wrote:
I am not exactly sure about this one ... what other power_supply class
drivers do? Should I fix HAL instead (but then, I do not know whether HAL
is the only application
On Sunday 28 October 2007, Andrey Borzenkov wrote:
On Saturday 27 October 2007, Anton Vorontsov wrote:
On Sat, Oct 27, 2007 at 08:54:30PM +0400, Andrey Borzenkov wrote:
I am not exactly sure about this one ... what other power_supply class
drivers do? Should I fix HAL instead (but then, I
On Saturday 27 October 2007, Alexey Starikovskiy wrote:
> Andrey Borzenkov wrote:
> > I am not exactly sure about this one ... what other power_supply class
> > drivers do? Should I fix HAL instead (but then, I do not know whether HAL
> > is the only application that is
bsent
From: Andrey Borzenkov <[EMAIL PROTECTED]>
Ensure that we always have "present" attribute in sysfs. This is compatible
with procfs case where we had "present: no" if battery was not available.
This fixes HAL battery detection where it does pretend battery is
On Saturday 27 October 2007, Alexey Starikovskiy wrote:
> As you wish... :) Please check the attached patch.
>
Not sure why you need to reimplement acpi_extract_package, but ...
Tested-by: Andrey Borzenkov <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part.
manufacturer name :)
> Thanks,
> Alex.
>
> Andrey Borzenkov wrote:
> > On Friday 26 October 2007, Alexey Starikovskiy wrote:
> >> Your cat's "Bad address" means -EFAULT, according to "man errno".
> >> Please apply this patch to see what
On Friday 26 October 2007, Alexey Starikovskiy wrote:
>
> Your cat's "Bad address" means -EFAULT, according to "man errno".
> Please apply this patch to see what exactly failed...
[ 1191.471572] ACPI: element[12]->type = 1, expected string
[ 1196.640065] ACPI: element[12]->type = 1, expected
On Friday 26 October 2007, Alexey Starikovskiy wrote:
Your cat's Bad address means -EFAULT, according to man errno.
Please apply this patch to see what exactly failed...
[ 1191.471572] ACPI: element[12]-type = 1, expected string
[ 1196.640065] ACPI: element[12]-type = 1, expected string
[
:)
Thanks,
Alex.
Andrey Borzenkov wrote:
On Friday 26 October 2007, Alexey Starikovskiy wrote:
Your cat's Bad address means -EFAULT, according to man errno.
Please apply this patch to see what exactly failed...
[ 1191.471572] ACPI: element[12]-type = 1, expected string
On Saturday 27 October 2007, Alexey Starikovskiy wrote:
As you wish... :) Please check the attached patch.
Not sure why you need to reimplement acpi_extract_package, but ...
Tested-by: Andrey Borzenkov [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
: Andrey Borzenkov [EMAIL PROTECTED]
Ensure that we always have present attribute in sysfs. This is compatible
with procfs case where we had present: no if battery was not available.
This fixes HAL battery detection where it does pretend battery is present
but canot provide any value for it.
Signed
On Saturday 27 October 2007, Alexey Starikovskiy wrote:
Andrey Borzenkov wrote:
I am not exactly sure about this one ... what other power_supply class
drivers do? Should I fix HAL instead (but then, I do not know whether HAL
is the only application that is using this interface).
Hm, do
1 - 100 of 306 matches
Mail list logo
