-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached is some hokey magic, which will cause your system to panic if you
have a device plugged in a being access when you go into suspend. The panic
will be on resume. I think it is because the usb interrupts change at least
that is what i gathe
In message: <[EMAIL PROTECTED]>
Nate Lawson <[EMAIL PROTECTED]> writes:
: Please send me your patch for reseting USB on resume. I will test it and
: commit it.
Acutally, I have some generic resume stuff in the pipeline, so please
run it by me too. Too many drivers do too many bogus t
On Sat, 5 Jul 2003, Anish Mistry wrote:
> I applied it on my Fujitsu P-2110 and rebuilt world, but didn't see any
> changes or regression.
> Outstanding issues:
> - - Battery still drains uncontrollably in S3
> - - USB devices dead on resume (working a usb code patch for this)
Please send me your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > Outstanding issues:
> > - - Battery still drains uncontrollably in S3
>
> No idea on this.
>
I seem to be getting this answer from everyone. Is there some specific
debugging info that I could provide the list to help with fixing this?
> > - - U
On Sat, 5 Jul 2003, Anish Mistry wrote:
> > The patch is not a complete implementation but it should help identify any
> > hw problems in burst mode support. I won't put it into the tree without
> > making sure it can fall back correctly.
> >
> > Also, since I forgot the URL the second time:
> > h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> The patch is not a complete implementation but it should help identify any
> hw problems in burst mode support. I won't put it into the tree without
> making sure it can fall back correctly.
>
> Also, since I forgot the URL the second time:
> http:
"M. Warner Losh" wrote:
> In message: <[EMAIL PROTECTED]>
> Nate Lawson <[EMAIL PROTECTED]> writes:
> : On Wed, 2 Jul 2003, Florian Smeets wrote:
> : > I set hw.acpi.ec.burst_mode=0 in loader.conf but when i was trying to
> : > chek if it was set to 0 with sysctl hw.acpi.ec.burst_mode i
> Date: Tue, 1 Jul 2003 01:07:53 -0700 (PDT)
> From: Nate Lawson <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> Please download and try the new version. It correctly implements burst
> mode to the best of the 2.0 spec. Like the previous message, please
> report the appropriate dmesgs ("acpi
In message: <[EMAIL PROTECTED]>
Nate Lawson <[EMAIL PROTECTED]> writes:
: On Thu, 3 Jul 2003, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > Nate Lawson <[EMAIL PROTECTED]> writes:
: > : On Wed, 2 Jul 2003, Florian Smeets wrote:
: > : > I set hw.acpi.ec.burst_
On Thursday, July 3, 2003, at 10:59 AM, Julian Elischer wrote:
It makes sense to export the values set by tunables into the sysctl
MIB, but by their
very nature they're not suitable for conversion to sysctls.
= Mike
So is what you are saying...
"tuneables should be converted at boot to read-onl
On 03-Jul-2003 Florian Smeets wrote:
> Nate Lawson wrote:
>> On Thu, 3 Jul 2003, John Baldwin wrote:
>>
>>>On 03-Jul-2003 Nate Lawson wrote:
>>>
On Thu, 3 Jul 2003, M. Warner Losh wrote:
>I personally think that all tunable should be read-only (or rw if
>possible) sysctls...
On Thu, 3 Jul 2003, Michael Smith wrote:
>
[...]
>
> No.
>
> The two are different things, although arguably there should be more
> integration.
>
> The tunable mechanism exists to allow parameters to be set before the
> kernel starts.
> Things that are set with tunables tend to be things
On Thursday, July 3, 2003, at 10:28 AM, Nate Lawson wrote:
I personally think that all tunable should be read-only (or rw if
possible) sysctls...
I'm still not sure why we have both mechanisms. Perhaps a useful
approach
would be to sweep the tree for tunables and change them to sysctls with
appr
Nate Lawson wrote:
On Thu, 3 Jul 2003, John Baldwin wrote:
On 03-Jul-2003 Nate Lawson wrote:
On Thu, 3 Jul 2003, M. Warner Losh wrote:
I personally think that all tunable should be read-only (or rw if
possible) sysctls...
I'm still not sure why we have both mechanisms. Perhaps a useful approach
On Thu, 3 Jul 2003, Koop Mast wrote:
> My machine an ASUS L3800S laptop.
> Before the burst_ec patch I am using the hw.acpi.ec.event_driven sysctl.
> This "fixed" the panic that occurred when switching to battery power.
> When using the patch I get same behavior as in the pre-event_driven="1"
> day
On Thu, 3 Jul 2003, John Baldwin wrote:
> On 03-Jul-2003 Nate Lawson wrote:
> > On Thu, 3 Jul 2003, M. Warner Losh wrote:
> >> I personally think that all tunable should be read-only (or rw if
> >> possible) sysctls...
> >
> > I'm still not sure why we have both mechanisms. Perhaps a useful approa
On 03-Jul-2003 Nate Lawson wrote:
> On Thu, 3 Jul 2003, M. Warner Losh wrote:
>> In message: <[EMAIL PROTECTED]>
>> Nate Lawson <[EMAIL PROTECTED]> writes:
>> : On Wed, 2 Jul 2003, Florian Smeets wrote:
>> : > I set hw.acpi.ec.burst_mode=0 in loader.conf but when i was trying to
>> : >
On Thu, 3 Jul 2003, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Nate Lawson <[EMAIL PROTECTED]> writes:
> : On Wed, 2 Jul 2003, Florian Smeets wrote:
> : > I set hw.acpi.ec.burst_mode=0 in loader.conf but when i was trying to
> : > chek if it was set to 0 with sysctl hw.ac
On 02-Jul-2003 Nate Lawson wrote:
> On Wed, 2 Jul 2003, John Baldwin wrote:
>> On 01-Jul-2003 Nate Lawson wrote:
>> > Please download and try the new version. It correctly implements burst
>> > mode to the best of the 2.0 spec. Like the previous message, please
>> > report the appropriate dmesgs
In message: <[EMAIL PROTECTED]>
Nate Lawson <[EMAIL PROTECTED]> writes:
: On Wed, 2 Jul 2003, Florian Smeets wrote:
: > I set hw.acpi.ec.burst_mode=0 in loader.conf but when i was trying to
: > chek if it was set to 0 with sysctl hw.acpi.ec.burst_mode i got :
: >
: > [EMAIL PROTECTED] [
On Wed, 2 Jul 2003, John Baldwin wrote:
> On 01-Jul-2003 Nate Lawson wrote:
> > Please download and try the new version. It correctly implements burst
> > mode to the best of the 2.0 spec. Like the previous message, please
> > report the appropriate dmesgs ("acpi_ec0*" and "EC Waited*") and any
>
On 01-Jul-2003 Nate Lawson wrote:
> Please download and try the new version. It correctly implements burst
> mode to the best of the 2.0 spec. Like the previous message, please
> report the appropriate dmesgs ("acpi_ec0*" and "EC Waited*") and any
> errors or regression. I've tested "du -a /" w
On Wed, 2 Jul 2003, Andrea Campi wrote:
> On Tue, Jul 01, 2003 at 10:25:36AM -0700, Nate Lawson wrote:
> > Would you please turn on "hw.acpi.verbose=1" in loader.conf? It should
> > explain the cause of those errors. Also, I would like the output of
> > "dmesg | egrep acpi_ec0\|EC\ Wait".
>
> I t
On Tue, Jul 01, 2003 at 10:25:36AM -0700, Nate Lawson wrote:
> Would you please turn on "hw.acpi.verbose=1" in loader.conf? It should
> explain the cause of those errors. Also, I would like the output of
> "dmesg | egrep acpi_ec0\|EC\ Wait".
I tested your patch on my IBM Thinkpad 570E and didn't
Nate Lawson wrote:
On Wed, 2 Jul 2003, Florian Smeets wrote:
I set hw.acpi.ec.burst_mode=0 in loader.conf but when i was trying to
chek if it was set to 0 with sysctl hw.acpi.ec.burst_mode i got :
[EMAIL PROTECTED] [~] 15 #sysctl hw.acpi.ec.burst_mode
sysctl: unknown oid 'hw.acpi.ec.burst_mode'
> On my aging fujistu-siemens E-series p2-366, this patch works just
> fine. I was previously getting tons of errors from the acpi_thermal
> thread, similar to other reports i have seen. with this, no errors
> occur, and things like screen blanking and disk spindown actually
> work :)
I forgot to
On Tuesday 01 July 2003 10:07, Nate Lawson wrote:
> Please download and try the new version. It correctly implements
> burst mode to the best of the 2.0 spec. Like the previous message,
> please report the appropriate dmesgs ("acpi_ec0*" and "EC Waited*")
> and any errors or regression. I've tes
On Wed, 2 Jul 2003, Florian Smeets wrote:
> I set hw.acpi.ec.burst_mode=0 in loader.conf but when i was trying to
> chek if it was set to 0 with sysctl hw.acpi.ec.burst_mode i got :
>
> [EMAIL PROTECTED] [~] 15 #sysctl hw.acpi.ec.burst_mode
> sysctl: unknown oid 'hw.acpi.ec.burst_mode'
It's a tuna
Nate Lawson wrote:
Also, please report how adding "hw.acpi.ec.burst_mode=0" to loader.conf
changes things (but turn on hw.acpi.verbose first so we get good msgs).
Well with hw.acpi.verbose=1 the messages look like this:
Jul 2 00:30:39 lappi kernel: ACPI-0432: *** Error: Handler for
[EmbeddedContr
On Tue, 1 Jul 2003, Florian Smeets wrote:
> with this patch i get a lot of these errors:
>
> ACPI-0432: *** Error: Handler for [EmbeddedControl] returned AE_ERROR
> ACPI-1287: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node
> 0xc2502760), AE_ERROR
> ACPI-0175: *** Error: Method executio
On Tue, 1 Jul 2003, Eirik Oeverby wrote:
> Can you be a bit more specific as to which other problems it fixes? I
> would love to try, because I have had some pretty nasty ACPI problems in
> the past, but I only have this one box to test on (my workstation) so I
> don't feel like going through the c
On Tue, 1 Jul 2003, Florian Smeets wrote:
> with this patch i get a lot of these errors:
>
> ACPI-0432: *** Error: Handler for [EmbeddedControl] returned AE_ERROR
> ACPI-1287: *** Error: Method execution failed [\\_SB_.BAT0._STA] (Node
> 0xc2502760), AE_ERROR
> ACPI-0175: *** Error: Method executio
Hi,
Can you be a bit more specific as to which other problems it fixes? I
would love to try, because I have had some pretty nasty ACPI problems in
the past, but I only have this one box to test on (my workstation) so I
don't feel like going through the compile/install/fail/restore process
if there
33 matches
Mail list logo
