On Thu 2007-07-05 20:43:44, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 01:25, Pavel Machek wrote:
> >
> > > > > > > Beep_flags should be removed too if you're sticking with /proc.
> > > > > >
> > > > > > Fixed.
> > > > >
> > > > > Ta. But you didn't answer the question - why /proc and
Hi!
> > > > Here's the version that uses just one variable, relative to Nigel's
> > > > patch. Hmm, and it also closes nasty trap for the user in
> > > > acpi_sleep_setup; order of parameters actually mattered there,
> > > > acpi_sleep=s3_bios,s3_mode doing something different from
> > > >
On Thursday, 5 July 2007 00:46, Pavel Machek wrote:
> Hi!
>
> > > Here's the version that uses just one variable, relative to Nigel's
> > > patch. Hmm, and it also closes nasty trap for the user in
> > > acpi_sleep_setup; order of parameters actually mattered there,
> > >
On Thursday, 5 July 2007 01:25, Pavel Machek wrote:
>
> > > > > > Beep_flags should be removed too if you're sticking with /proc.
> > > > >
> > > > > Fixed.
> > > >
> > > > Ta. But you didn't answer the question - why /proc and not sysfs?
> > >
> > > Do you seriously advocate setting two bits
On Thursday, 5 July 2007 01:25, Pavel Machek wrote:
Beep_flags should be removed too if you're sticking with /proc.
Fixed.
Ta. But you didn't answer the question - why /proc and not sysfs?
Do you seriously advocate setting two bits of one variable from /proc,
On Thursday, 5 July 2007 00:46, Pavel Machek wrote:
Hi!
Here's the version that uses just one variable, relative to Nigel's
patch. Hmm, and it also closes nasty trap for the user in
acpi_sleep_setup; order of parameters actually mattered there,
acpi_sleep=s3_bios,s3_mode doing
Hi!
Here's the version that uses just one variable, relative to Nigel's
patch. Hmm, and it also closes nasty trap for the user in
acpi_sleep_setup; order of parameters actually mattered there,
acpi_sleep=s3_bios,s3_mode doing something different from
acpi_sleep=s3_mode,s3_bios
On Thu 2007-07-05 20:43:44, Rafael J. Wysocki wrote:
On Thursday, 5 July 2007 01:25, Pavel Machek wrote:
Beep_flags should be removed too if you're sticking with /proc.
Fixed.
Ta. But you didn't answer the question - why /proc and not sysfs?
Do you
> > > > > Beep_flags should be removed too if you're sticking with /proc.
> > > >
> > > > Fixed.
> > >
> > > Ta. But you didn't answer the question - why /proc and not sysfs?
> >
> > Do you seriously advocate setting two bits of one variable from /proc,
> > and one more bit from /sys?
>
>
Hi.
On Thursday 05 July 2007 09:01:09 Pavel Machek wrote:
> Hi!
>
> > > > > @@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
> > > > >
> > > > > __setup("acpi_sleep=", acpi_sleep_setup);
> > > > >
> > > > > +/* Ouch, we want to delete this. We already have better version in
> >
Hi!
> > > > @@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
> > > >
> > > > __setup("acpi_sleep=", acpi_sleep_setup);
> > > >
> > > > +/* Ouch, we want to delete this. We already have better version in
> > > userspace, in
> > > > + s2ram from suspend.sf.net project */
> > >
Hi.
On Thursday 05 July 2007 08:48:59 Pavel Machek wrote:
> Hi!
>
> > Documentation is also an issue. Your patch should update the
kernel_parameters
> > file so users can know how to get the beeping to happen. It would be nice
if
> > it mentioned the proc entry too.
>
> Fixed the docs.
Ta.
Hi!
> Documentation is also an issue. Your patch should update the
> kernel_parameters
> file so users can know how to get the beeping to happen. It would be nice if
> it mentioned the proc entry too.
Fixed the docs.
> > @@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
> >
> >
Hi!
> > Here's the version that uses just one variable, relative to Nigel's
> > patch. Hmm, and it also closes nasty trap for the user in
> > acpi_sleep_setup; order of parameters actually mattered there,
> > acpi_sleep=s3_bios,s3_mode doing something different from
> > acpi_sleep=s3_mode,s3_bios
Hi.
On Thursday 05 July 2007 07:29:07 Pavel Machek wrote:
> Here's the version that uses just one variable, relative to Nigel's
> patch. Hmm, and it also closes nasty trap for the user in
> acpi_sleep_setup; order of parameters actually mattered there,
> acpi_sleep=s3_bios,s3_mode doing something
Hi,
On Wednesday, 4 July 2007 23:29, Pavel Machek wrote:
> Hi!
>
> > > > > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > > > > >
> > > > > > Seriously, though, I'd prefer not to. If we rename that acpi video
> > > > > > flags
> > > > > > variable (I assume this is
Hi!
> > > > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > > > >
> > > > > Seriously, though, I'd prefer not to. If we rename that acpi video
> > > > > flags
> > > > > variable (I assume this is what you're thinking of), we only create
> > > > > cause for
> > > > >
Hi!
Sorry, but I can't resist the opportunity to say Send a patch! :)
Seriously, though, I'd prefer not to. If we rename that acpi video
flags
variable (I assume this is what you're thinking of), we only create
cause for
confusion. A variable should for
Hi,
On Wednesday, 4 July 2007 23:29, Pavel Machek wrote:
Hi!
Sorry, but I can't resist the opportunity to say Send a patch! :)
Seriously, though, I'd prefer not to. If we rename that acpi video
flags
variable (I assume this is what you're thinking of), we only
Hi.
On Thursday 05 July 2007 07:29:07 Pavel Machek wrote:
Here's the version that uses just one variable, relative to Nigel's
patch. Hmm, and it also closes nasty trap for the user in
acpi_sleep_setup; order of parameters actually mattered there,
acpi_sleep=s3_bios,s3_mode doing something
Hi!
Here's the version that uses just one variable, relative to Nigel's
patch. Hmm, and it also closes nasty trap for the user in
acpi_sleep_setup; order of parameters actually mattered there,
acpi_sleep=s3_bios,s3_mode doing something different from
acpi_sleep=s3_mode,s3_bios . It
Hi!
Documentation is also an issue. Your patch should update the
kernel_parameters
file so users can know how to get the beeping to happen. It would be nice if
it mentioned the proc entry too.
Fixed the docs.
@@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
Hi.
On Thursday 05 July 2007 08:48:59 Pavel Machek wrote:
Hi!
Documentation is also an issue. Your patch should update the
kernel_parameters
file so users can know how to get the beeping to happen. It would be nice
if
it mentioned the proc entry too.
Fixed the docs.
Ta.
@@
Hi!
@@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
__setup(acpi_sleep=, acpi_sleep_setup);
+/* Ouch, we want to delete this. We already have better version in
userspace, in
+ s2ram from suspend.sf.net project */
Do we? This version has
Hi.
On Thursday 05 July 2007 09:01:09 Pavel Machek wrote:
Hi!
@@ -80,9 +82,11 @@ static int __init acpi_sleep_setup(char
__setup(acpi_sleep=, acpi_sleep_setup);
+/* Ouch, we want to delete this. We already have better version in
userspace, in
+ s2ram
Beep_flags should be removed too if you're sticking with /proc.
Fixed.
Ta. But you didn't answer the question - why /proc and not sysfs?
Do you seriously advocate setting two bits of one variable from /proc,
and one more bit from /sys?
That's partly why I had a
Hi,
On Saturday, 30 June 2007 12:11, Pavel Machek wrote:
> Hi!
>
> > > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > > >
> > > > Seriously, though, I'd prefer not to. If we rename that acpi video
> > > > flags
> > > > variable (I assume this is what you're thinking
Hi!
> > > Sorry, but I can't resist the opportunity to say "Send a patch!" :)
> > >
> > > Seriously, though, I'd prefer not to. If we rename that acpi video flags
> > > variable (I assume this is what you're thinking of), we only create cause
> > > for
> > > confusion. A variable should for
Hi,
On Saturday, 30 June 2007 00:35, Pavel Machek wrote:
> Hi!
>
> > > > ALIGN
> > > > .align 4096
> > > > @@ -31,6 +46,11 @@ wakeup_code:
> > > > movw%cs, %ax
> > > > movw%ax, %ds# Make
> > > > ds:0 point to wakeup_start
Hi,
On Saturday, 30 June 2007 00:35, Pavel Machek wrote:
Hi!
ALIGN
.align 4096
@@ -31,6 +46,11 @@ wakeup_code:
movw%cs, %ax
movw%ax, %ds# Make
ds:0 point to wakeup_start
movw%ax,
Hi!
Sorry, but I can't resist the opportunity to say Send a patch! :)
Seriously, though, I'd prefer not to. If we rename that acpi video flags
variable (I assume this is what you're thinking of), we only create cause
for
confusion. A variable should for debugging or for
Hi,
On Saturday, 30 June 2007 12:11, Pavel Machek wrote:
Hi!
Sorry, but I can't resist the opportunity to say Send a patch! :)
Seriously, though, I'd prefer not to. If we rename that acpi video
flags
variable (I assume this is what you're thinking of), we only create
Hi!
> > > ALIGN
> > > .align 4096
> > > @@ -31,6 +46,11 @@ wakeup_code:
> > > movw%cs, %ax
> > > movw%ax, %ds# Make ds:0
> > > point to wakeup_start
> > > movw%ax, %ss
> > > +
> > > + testl $1, beep_flags - wakeup_code
> > > + jz
On Fri, Jun 29, 2007 at 08:27:12AM +1000, Nigel Cunningham wrote:
> > Can we rename/reuse existing flag variable?
>
> Sorry, but I can't resist the opportunity to say "Send a patch!" :)
>
> Seriously, though, I'd prefer not to. If we rename that acpi video flags
> variable (I assume this is
On Fri, Jun 29, 2007 at 08:27:12AM +1000, Nigel Cunningham wrote:
Can we rename/reuse existing flag variable?
Sorry, but I can't resist the opportunity to say Send a patch! :)
Seriously, though, I'd prefer not to. If we rename that acpi video flags
variable (I assume this is what you're
Hi!
ALIGN
.align 4096
@@ -31,6 +46,11 @@ wakeup_code:
movw%cs, %ax
movw%ax, %ds# Make ds:0
point to wakeup_start
movw%ax, %ss
+
+ testl $1, beep_flags - wakeup_code
+ jz 1f
+ BEEP
+1:
Hi.
On Friday 29 June 2007 00:25:32 Pavel Machek wrote:
> Hi!
>
> > Hi all
> >
> > Here's what I have after today's work.
> >
> > I haven't yet been able to test on x86, but can confirm that it works okay
on x86_64. I'm currently working towards testing it on my old Omnibook. My P4
desktop
Hi!
> Hi all
>
> Here's what I have after today's work.
>
> I haven't yet been able to test on x86, but can confirm that it works okay on
> x86_64. I'm currently working towards testing it on my old Omnibook. My P4
> desktop won't resume from suspend to ram at all, and hasn't produced any
>
Hi!
Hi all
Here's what I have after today's work.
I haven't yet been able to test on x86, but can confirm that it works okay on
x86_64. I'm currently working towards testing it on my old Omnibook. My P4
desktop won't resume from suspend to ram at all, and hasn't produced any
beeps.
Hi.
On Friday 29 June 2007 00:25:32 Pavel Machek wrote:
Hi!
Hi all
Here's what I have after today's work.
I haven't yet been able to test on x86, but can confirm that it works okay
on x86_64. I'm currently working towards testing it on my old Omnibook. My P4
desktop won't resume
Hi,
On Thursday, 21 June 2007 00:24, Nigel Cunningham wrote:
> On Thursday 21 June 2007 08:09:26 Rafael J. Wysocki wrote:
> > On Tuesday, 19 June 2007 23:33, Rafael J. Wysocki wrote:
> > > On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
> > > > Hi all
> > > >
> > > > Here's what I have
Hi,
On Thursday, 21 June 2007 00:24, Nigel Cunningham wrote:
On Thursday 21 June 2007 08:09:26 Rafael J. Wysocki wrote:
On Tuesday, 19 June 2007 23:33, Rafael J. Wysocki wrote:
On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
Hi all
Here's what I have after today's work.
Hi.
On Thursday 21 June 2007 08:09:26 Rafael J. Wysocki wrote:
> Hi,
>
> On Tuesday, 19 June 2007 23:33, Rafael J. Wysocki wrote:
> > On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
> > > Hi all
> > >
> > > Here's what I have after today's work.
> > >
> > > I haven't yet been able to
Hi,
On Tuesday, 19 June 2007 23:33, Rafael J. Wysocki wrote:
> On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
> > Hi all
> >
> > Here's what I have after today's work.
> >
> > I haven't yet been able to test on x86, but can confirm that it works okay
> > on
> > x86_64. I'm currently
Hi,
On Tuesday, 19 June 2007 23:33, Rafael J. Wysocki wrote:
On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
Hi all
Here's what I have after today's work.
I haven't yet been able to test on x86, but can confirm that it works okay
on
x86_64. I'm currently working towards
Hi.
On Thursday 21 June 2007 08:09:26 Rafael J. Wysocki wrote:
Hi,
On Tuesday, 19 June 2007 23:33, Rafael J. Wysocki wrote:
On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
Hi all
Here's what I have after today's work.
I haven't yet been able to test on x86, but can
Hi Nigel,
On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
> Hi all
>
> Here's what I have after today's work.
>
> I haven't yet been able to test on x86, but can confirm that it works okay on
> x86_64. I'm currently working towards testing it on my old Omnibook. My P4
> desktop won't
Hi all
Here's what I have after today's work.
I haven't yet been able to test on x86, but can confirm that it works okay on
x86_64. I'm currently working towards testing it on my old Omnibook. My P4
desktop won't resume from suspend to ram at all, and hasn't produced any beeps.
I needed to
Hi all
Here's what I have after today's work.
I haven't yet been able to test on x86, but can confirm that it works okay on
x86_64. I'm currently working towards testing it on my old Omnibook. My P4
desktop won't resume from suspend to ram at all, and hasn't produced any beeps.
I needed to
Hi Nigel,
On Tuesday, 19 June 2007 13:18, Nigel Cunningham wrote:
Hi all
Here's what I have after today's work.
I haven't yet been able to test on x86, but can confirm that it works okay on
x86_64. I'm currently working towards testing it on my old Omnibook. My P4
desktop won't resume
50 matches
Mail list logo
