RE: ACPI Error on HP ProBook 430 G2

[Moore, Robert]

We have fixed this issue for the latest version of ACPICA that will happen this 
week, probably 22 december.


> -Original Message-
> From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
> a...@freebsd.org] On Behalf Of Edward Tomasz Napierala
> Sent: Wednesday, December 21, 2016 3:15 AM
> To: O. Hartmann <ohartm...@walstatt.org>
> Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> Zakharov <zakharov...@gmail.com>
> Subject: Re: ACPI Error on HP ProBook 430 G2
> 
> On 1220T1734, O. Hartmann wrote:
> > Am Tue, 20 Dec 2016 18:09:20 +0300
> > Vladimir Zakharov <zakharov...@gmail.com> schrieb:
> >
> > > Hello!
> > >
> > > Some time ago new ACPI messages appeared on console and in
> > > /var/log/messages. Like
> > > these:
> > >
> > > ACPI Error: Needed type [Reference], found [Processor]
> > > 0xf800043b8980
> > > (20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While
> > > resolving operands for [OpcodeName unavailable]
> > > (20161117/dswexec-498) ACPI Error: Method parse/execution failed
> > > [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640),
> > > AE_AML_OPERAND_TYPE
> > > (20161117/psparse-560) ACPI Error: Method parse/execution failed
> > > [\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40),
> > > AE_AML_OPERAND_TYPE
> > > (20161117/psparse-560) acpi_ec0: evaluation of query method _Q04
> failed:
> > > AE_AML_OPERAND_TYPE
> > >
> > > I'm sure that there were no such messages earlier. Suspend/resume
> > > works for me. But after disconnecting power line hw.acpi.acline
> > > still equals to 1. And powerd/powerdxx do not adjust CPU frequency
> anymore.
> > >
> > > System info:
> > > $ uname -a
> > > FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M:
> > > Tue Dec 20 16:42:21 MSK 2016
> > > root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > >
> > > dmesg: http://pastebin.com/cYD8cR0b
> > > hw.acpi: http://pastebin.com/Tht9B0FZ
> > > acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl
> > >
> > >
> > > PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.
> > >
> >
> > I see lots of ACPI errors also shortly on a Lenovo E540 UEFI notebook
> > running most recent CURRENT ...
> 
> +1, I see the same on Thinkpad T420.
> 
> ___
> freebsd-a...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI Error on HP ProBook 430 G2

[Alexandr Krivulya]

21.12.2016 13:14, Edward Tomasz Napierała пишет:

On 1220T1734, O. Hartmann wrote:

Am Tue, 20 Dec 2016 18:09:20 +0300
Vladimir Zakharov <zakharov...@gmail.com> schrieb:


Hello!

Some time ago new ACPI messages appeared on console and in /var/log/messages. 
Like
these:

ACPI Error: Needed type [Reference], found [Processor] 0xf800043b8980
(20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving 
operands
for [OpcodeName unavailable] (20161117/dswexec-498) ACPI Error: Method 
parse/execution
failed [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640), 
AE_AML_OPERAND_TYPE
(20161117/psparse-560) ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40), AE_AML_OPERAND_TYPE
(20161117/psparse-560) acpi_ec0: evaluation of query method _Q04 failed:
AE_AML_OPERAND_TYPE

I'm sure that there were no such messages earlier. Suspend/resume works
for me. But after disconnecting power line hw.acpi.acline still equals
to 1. And powerd/powerdxx do not adjust CPU frequency anymore.

System info:
$ uname -a
FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M: Tue Dec 20 
16:42:21
MSK 2016 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64

dmesg: http://pastebin.com/cYD8cR0b
hw.acpi: http://pastebin.com/Tht9B0FZ
acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl


PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.


I see lots of ACPI errors also shortly on a Lenovo E540 UEFI notebook running 
most recent
CURRENT ...

+1, I see the same on Thinkpad T420.
Same on Thinkpad E530, but hw.acpi.acline changes on ac lost and powerd 
works.


--
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI Error on HP ProBook 430 G2

[Edward Tomasz Napierała]

On 1220T1734, O. Hartmann wrote:
> Am Tue, 20 Dec 2016 18:09:20 +0300
> Vladimir Zakharov <zakharov...@gmail.com> schrieb:
> 
> > Hello!
> > 
> > Some time ago new ACPI messages appeared on console and in 
> > /var/log/messages. Like
> > these:
> > 
> > ACPI Error: Needed type [Reference], found [Processor] 0xf800043b8980
> > (20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving 
> > operands
> > for [OpcodeName unavailable] (20161117/dswexec-498) ACPI Error: Method 
> > parse/execution
> > failed [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640), 
> > AE_AML_OPERAND_TYPE
> > (20161117/psparse-560) ACPI Error: Method parse/execution failed
> > [\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40), AE_AML_OPERAND_TYPE
> > (20161117/psparse-560) acpi_ec0: evaluation of query method _Q04 failed:
> > AE_AML_OPERAND_TYPE
> > 
> > I'm sure that there were no such messages earlier. Suspend/resume works
> > for me. But after disconnecting power line hw.acpi.acline still equals
> > to 1. And powerd/powerdxx do not adjust CPU frequency anymore.
> > 
> > System info:
> > $ uname -a
> > FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M: Tue Dec 
> > 20 16:42:21
> > MSK 2016 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > 
> > dmesg: http://pastebin.com/cYD8cR0b
> > hw.acpi: http://pastebin.com/Tht9B0FZ
> > acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl
> > 
> > 
> > PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.
> > 
> 
> I see lots of ACPI errors also shortly on a Lenovo E540 UEFI notebook running 
> most recent
> CURRENT ...

+1, I see the same on Thinkpad T420.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI Error on HP ProBook 430 G2

[O. Hartmann]

Am Tue, 20 Dec 2016 18:09:20 +0300
Vladimir Zakharov <zakharov...@gmail.com> schrieb:

> Hello!
> 
> Some time ago new ACPI messages appeared on console and in /var/log/messages. 
> Like
> these:
> 
> ACPI Error: Needed type [Reference], found [Processor] 0xf800043b8980
> (20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving 
> operands
> for [OpcodeName unavailable] (20161117/dswexec-498) ACPI Error: Method 
> parse/execution
> failed [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640), 
> AE_AML_OPERAND_TYPE
> (20161117/psparse-560) ACPI Error: Method parse/execution failed
> [\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40), AE_AML_OPERAND_TYPE
> (20161117/psparse-560) acpi_ec0: evaluation of query method _Q04 failed:
> AE_AML_OPERAND_TYPE
> 
> I'm sure that there were no such messages earlier. Suspend/resume works
> for me. But after disconnecting power line hw.acpi.acline still equals
> to 1. And powerd/powerdxx do not adjust CPU frequency anymore.
> 
> System info:
> $ uname -a
> FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M: Tue Dec 20 
> 16:42:21
> MSK 2016 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> 
> dmesg: http://pastebin.com/cYD8cR0b
> hw.acpi: http://pastebin.com/Tht9B0FZ
> acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl
> 
> 
> PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.
> 

I see lots of ACPI errors also shortly on a Lenovo E540 UEFI notebook running 
most recent
CURRENT ...

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp5624aBcXSn.pgp
Description: OpenPGP digital signature

ACPI Error on HP ProBook 430 G2

[Vladimir Zakharov]

Hello!

Some time ago new ACPI messages appeared on console and in /var/log/messages. 
Like these:

ACPI Error: Needed type [Reference], found [Processor] 0xf800043b8980 
(20161117/exresop-111)
ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName 
unavailable] (20161117/dswexec-498)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 
0xf80004396640), AE_AML_OPERAND_TYPE (20161117/psparse-560)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC0._Q04] (Node 
0xf80004396c40), AE_AML_OPERAND_TYPE (20161117/psparse-560)
acpi_ec0: evaluation of query method _Q04 failed: AE_AML_OPERAND_TYPE

I'm sure that there were no such messages earlier. Suspend/resume works
for me. But after disconnecting power line hw.acpi.acline still equals
to 1. And powerd/powerdxx do not adjust CPU frequency anymore.

System info:
$ uname -a
FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M: Tue Dec 20 
16:42:21 MSK 2016 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64

dmesg: http://pastebin.com/cYD8cR0b
hw.acpi: http://pastebin.com/Tht9B0FZ
acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl


PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI errors when booting laptop

[K. Macy]

Have you checked for BIOS updates? The BIOS on recent Skylake laptops
have been a running disaster. At least the Dell XPS laptops had ACPI
errors be fixed by an update.

-M

On Sat, Jul 30, 2016 at 10:43 PM, Ben Woods <woods...@gmail.com> wrote:
> Hi everyone,
>
> I get the following ACPI errors in my dmesg when booting my NEC Lavie HZ750
> laptop with FreeBSD 12-current. I have noticed things not functioning
> correct (except suspend/resume not working), but then again I don't really
> know much about ACPI or what I should expect to see. Any ideas what the
> problem is?
>
> Full dmesg is also attached.
>
> acpi0:  on motherboard
> acpi_ec_ecdt_probe: can't get handle
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC._REG] (Node
> 0xf80005494980), AE_NOT_EXIST (20160527/psparse-559)
> acpi0: Power Button (fixed)
> ACPI Error: No handler for Region [EC__] (0xfffff8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320)
> ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
> (Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
> 0xfff

ACPI errors when booting laptop

[Ben Woods]

Hi everyone,

I get the following ACPI errors in my dmesg when booting my NEC Lavie HZ750
laptop with FreeBSD 12-current. I have noticed things not functioning
correct (except suspend/resume not working), but then again I don't really
know much about ACPI or what I should expect to see. Any ideas what the
problem is?

Full dmesg is also attached.

acpi0:  on motherboard
acpi_ec_ecdt_probe: can't get handle
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC._REG] (Node
0xf80005494980), AE_NOT_EXIST (20160527/psparse-559)
acpi0: Power Button (fixed)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler

Re: Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

[Jung-uk Kim]

On 05/ 3/16 03:55 PM, John Baldwin wrote:
> On Tuesday, May 03, 2016 12:18:22 AM Mark Millard wrote:
>> On 2016-May-2, at 11:04 PM, Mark Millard <mar...@dsl-only.net> wrote:
>>
>>> I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS 
>>> X to -r298793. This was via buildworld buildkernel then installing them, 
>>> like normal for me.
>>>
>>> The result is about 10-11 minutes after starting to boot FreeBSD shuts down 
>>> with (for example):
>>> (the root login line is just to give an idea of the time frame after the 
>>> login prompt)
>>>
>>>> May  2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0
>>>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
>>>> fixed event - PM_Timer (0), disabling (20160422/evevent-323)
>>>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
>>>> fixed event - RealTimeClock (4), disabling (20160422/evevent-323)
>>>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
>>>> GPE 01, disabling event (20160422/evgpe-834)
>>>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
>>>> GPE 03, disabling event (20160422/evgpe-834)
>>>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
>>>> GPE 04, disabling event (20160422/evgpe-834)
>>>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
>>>> GPE 05, disabling event (20160422/evgpe-834)
>>>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
>>>> GPE 06, disabling event (20160422/evgpe-834)
>>>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
>>>> GPE 07, disabling event (20160422/evgpe-834)
>>>> May  2 22:01:45 FreeBSDx64 kernel: .
>>>> May  2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down
>>>> May  2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM
>>>> May  2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting
>>>> May  2 22:01:46 FreeBSDx64 kernel: .
>>>> May  2 22:01:47 FreeBSDx64 kernel: , 576.
>>>> May  2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15
>>>
>>>
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>>
>> I had duplicated the directory tree that held the virtual machine on Mac OS 
>> X before booting FreeBSD in VirtualBox to install the kernel and world. This 
>> was running -r297769.
>>
>> When I boot the -r297769 11.0 virtual machine instead of the -r298793 one 
>> the problem does not occur.
>>
>> Both -r297769 and -r298793 11.0-'s have /usr/ports -r414369 and the ports 
>> were built before the -r298793 buildworld/buildkernel was done. And both 
>> -r297769 and -r298793 11.0's are running under the same vintage of Virtual 
>> Box (5.0.20 r106931).
>>
>> So what is different is just the FreeBSD vintage.
>>
>> 11.0's -r297769 virtual machine does contain the buildworld/buildkernel 
>> /usr/obj material for -r298793, it is just not installed.
> 
> This was already covered in an earlier thread.  r298838 has the fix /
> workaround.

FYI, the upstream was notified and a patch is available from here:

https://github.com/acpica/acpica/pull/138

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature

Re: Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

[John Baldwin]

On Tuesday, May 03, 2016 12:18:22 AM Mark Millard wrote:
> On 2016-May-2, at 11:04 PM, Mark Millard <mar...@dsl-only.net> wrote:
> 
> > I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS 
> > X to -r298793. This was via buildworld buildkernel then installing them, 
> > like normal for me.
> > 
> > The result is about 10-11 minutes after starting to boot FreeBSD shuts down 
> > with (for example):
> > (the root login line is just to give an idea of the time frame after the 
> > login prompt)
> > 
> >> May  2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
> >> fixed event - PM_Timer (0), disabling (20160422/evevent-323)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
> >> fixed event - RealTimeClock (4), disabling (20160422/evevent-323)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 01, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 03, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 04, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 05, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 06, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 07, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: .
> >> May  2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down
> >> May  2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM
> >> May  2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting
> >> May  2 22:01:46 FreeBSDx64 kernel: .
> >> May  2 22:01:47 FreeBSDx64 kernel: , 576.
> >> May  2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15
> > 
> > 
> > ===
> > Mark Millard
> > markmi at dsl-only.net
> 
> I had duplicated the directory tree that held the virtual machine on Mac OS X 
> before booting FreeBSD in VirtualBox to install the kernel and world. This 
> was running -r297769.
> 
> When I boot the -r297769 11.0 virtual machine instead of the -r298793 one the 
> problem does not occur.
> 
> Both -r297769 and -r298793 11.0-'s have /usr/ports -r414369 and the ports 
> were built before the -r298793 buildworld/buildkernel was done. And both 
> -r297769 and -r298793 11.0's are running under the same vintage of Virtual 
> Box (5.0.20 r106931).
> 
> So what is different is just the FreeBSD vintage.
> 
> 11.0's -r297769 virtual machine does contain the buildworld/buildkernel 
> /usr/obj material for -r298793, it is just not installed.

This was already covered in an earlier thread.  r298838 has the fix /
workaround.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

[Guillermo Garc?a Rojas]

Hi,

I'm having the same issue with downloaded ISO from Monday May 2nd under 
VirtualBox same version.

It happens at 10 minutes after system is started.

Thanks.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

[Mark Millard]

On 2016-May-2, at 11:04 PM, Mark Millard <mar...@dsl-only.net> wrote:

> I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS X 
> to -r298793. This was via buildworld buildkernel then installing them, like 
> normal for me.
> 
> The result is about 10-11 minutes after starting to boot FreeBSD shuts down 
> with (for example):
> (the root login line is just to give an idea of the time frame after the 
> login prompt)
> 
>> May  2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
>> fixed event - PM_Timer (0), disabling (20160422/evevent-323)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
>> fixed event - RealTimeClock (4), disabling (20160422/evevent-323)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 01, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 03, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 04, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 05, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 06, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 07, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: .
>> May  2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down
>> May  2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM
>> May  2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting
>> May  2 22:01:46 FreeBSDx64 kernel: .
>> May  2 22:01:47 FreeBSDx64 kernel: , 576.
>> May  2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net

I had duplicated the directory tree that held the virtual machine on Mac OS X 
before booting FreeBSD in VirtualBox to install the kernel and world. This was 
running -r297769.

When I boot the -r297769 11.0 virtual machine instead of the -r298793 one the 
problem does not occur.

Both -r297769 and -r298793 11.0-'s have /usr/ports -r414369 and the ports were 
built before the -r298793 buildworld/buildkernel was done. And both -r297769 
and -r298793 11.0's are running under the same vintage of Virtual Box (5.0.20 
r106931).

So what is different is just the FreeBSD vintage.

11.0's -r297769 virtual machine does contain the buildworld/buildkernel 
/usr/obj material for -r298793, it is just not installed.

===
Mark Millard
mar...@dsl-only.net

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

[Mark Millard]

I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS X 
to -r298793. This was via buildworld buildkernel then installing them, like 
normal for me.

The result is about 10-11 minutes after starting to boot FreeBSD shuts down 
with (for example):
(the root login line is just to give an idea of the time frame after the login 
prompt)

> May  2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for fixed 
> event - PM_Timer (0), disabling (20160422/evevent-323)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for fixed 
> event - RealTimeClock (4), disabling (20160422/evevent-323)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 01, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 03, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 04, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 05, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 06, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 07, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: .
> May  2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down
> May  2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM
> May  2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting
> May  2 22:01:46 FreeBSDx64 kernel: .
> May  2 22:01:47 FreeBSDx64 kernel: , 576.
> May  2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15


===
Mark Millard
markmi at dsl-only.net


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

failure with latest merged ACPI on virtualbox

[Kurt Lidl]

I have a virtual machine running freebsd-current under VirtualBox (on Mac OS X).

It's been running with no issue for the last month.  Today, I updated to the
current version.

# old version (worked well)
@(#)FreeBSD 11.0-CURRENT #0 991d92a(master): Sat Mar 26 08:59:33 EDT 2016
FreeBSD 11.0-CURRENT #0 991d92a(master): Sat Mar 26 08:59:33 EDT 2016
l...@testvm.pix.net:/usr/obj/usr/src/sys/GENERIC

Current version, which fails:
# uname -a
FreeBSD testvm.pix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1 88a00cf(blacklist): 
Wed Apr 13 00:39:24 EDT 2016 
l...@testvm.pix.net:/usr/obj/usr/src/sys/GENERIC  amd64

It's shutdown twice (without warning), logging the following to the messages 
file:

Apr 28 17:08:14 testvm kernel: ACPI Error: No installed handler for fixed event 
- PM_Timer (0), disabling (20160422/evevent-323)
Apr 28 17:08:14 testvm kernel: ACPI Error: No installed handler for fixed event 
- RealTimeClock (4), disabling (20160422/evevent-323)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 01, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 03, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 04, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 05, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 06, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: ACPI Error: No handler or method for GPE 07, 
disabling event (20160422/evgpe-834)
Apr 28 17:08:14 testvm kernel: .

In both cases, I was in the middle of running 'mergemaster', just after having
done a 'make installworld'.

-Kurt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Weird ACPI/DRM messages on -current

[Alexei Pastuchov]

Hi,
I'm using

11.0-CURRENT FreeBSD 11.0-CURRENT #0 r287497: Sun Sep  6 17:10:22 CEST 2015

on HP Folio 9470m.

After last ports upgrade in /var/log/messages appear weird messages:

Apr 28 06:31:10 dork kernel: error: [drm:pid9:i915_gem_object_unbind] *ERROR*
Attempting to unbind pinned buffer
Apr 28 07:04:47 dork kernel: error: [drm:pid9:i915_gem_object_unbind] *ERROR*
Attempting to unbind pinned buffer
Apr 28 20:20:40 dork kernel: error: [drm:pid1063:gen6_sanitize_pm] *ERROR* Power
management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1200
Apr 28 21:29:40 dork kernel: error: [drm:pid1063:gen6_sanitize_pm] *ERROR* Power
management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 0007, was 1700
 
The is a similar Issue:
http://lists.freebsd.org/pipermail/freebsd-current/2015-February/054368.html
but no solution.

Any help will be highly appreciated.

Sincerely yours,
Alexei
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Andriy Gapon]

On 31/08/2015 11:53, Adrian Chadd wrote:
> Try disabling hardware one at a time. Ie, unload usb; unload wifi;
> leave kms loaded for mostly obvious reasons.

Adrian, Garrett,

thank you very much for your tips.
Turned out that it was radeonkms that was causing the problem :-)

BTW, here is another tool for the toolkit: on sufficiently recent system devctl
suspend and devctl resume can be used to test individual drivers.

So, I noticed that I could suspend/resume drmn0 device just fine but with
vgapci0 I had a trouble suspending.  One thing led to another and here is a
patch that seems to fix the problem for me:
---
commit fecb5e8a90631f06600d87165cc8b6de3e035dfc
Author: Andriy Gapon 
Date:   Thu Sep 3 17:24:23 2015 +0300

radeon_suspend_kms: don't mess with pci state that's managed by the bus

The pci bus driver handles the power state and configuration state saving
and restoring for its child devices.

diff --git a/sys/dev/drm2/radeon/radeon_device.c
b/sys/dev/drm2/radeon/radeon_device.c
index e5c676b11ed47..73b2f4c51ada2 100644
--- a/sys/dev/drm2/radeon/radeon_device.c
+++ b/sys/dev/drm2/radeon/radeon_device.c
@@ -1342,14 +1342,10 @@ int radeon_suspend_kms(struct drm_device *dev)

radeon_agp_suspend(rdev);

-   pci_save_state(device_get_parent(dev->dev));
 #ifdef FREEBSD_WIP
if (state.event == PM_EVENT_SUSPEND) {
/* Shut down the device */
pci_disable_device(dev->pdev);
-#endif /* FREEBSD_WIP */
-   pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3);
-#ifdef FREEBSD_WIP
}
console_lock();
 #endif /* FREEBSD_WIP */
@@ -1380,10 +1376,6 @@ int radeon_resume_kms(struct drm_device *dev)

 #ifdef FREEBSD_WIP
console_lock();
-#endif /* FREEBSD_WIP */
-   pci_set_powerstate(device_get_parent(dev->dev), PCI_POWERSTATE_D0);
-   pci_restore_state(device_get_parent(dev->dev));
-#ifdef FREEBSD_WIP
if (pci_enable_device(dev->pdev)) {
console_unlock();
return -1;
---

However, I am not sure about an exact mechanism of the hard system hang that I
experienced without the patch.

BTW, I noticed that only very few drivers make explicit calls to
pci_set_powerstate and pci_save_state/pci_restore_state.
sys/dev/usb/controller/ohci_pci.c looks like a good use of pci_set_powerstate.
sys/dev/ixgbe/if_ix.c looks like an incorrect / redundant use of the functions.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Adrian Chadd]

oioo, would you please put that radeon patch into a review?

I have an older machine with a radeon card in it that doesn't yet
suspend/resume; I can now test it out!


-a


On 3 September 2015 at 10:50, Andriy Gapon  wrote:
> On 31/08/2015 11:53, Adrian Chadd wrote:
>> Try disabling hardware one at a time. Ie, unload usb; unload wifi;
>> leave kms loaded for mostly obvious reasons.
>
> Adrian, Garrett,
>
> thank you very much for your tips.
> Turned out that it was radeonkms that was causing the problem :-)
>
> BTW, here is another tool for the toolkit: on sufficiently recent system 
> devctl
> suspend and devctl resume can be used to test individual drivers.
>
> So, I noticed that I could suspend/resume drmn0 device just fine but with
> vgapci0 I had a trouble suspending.  One thing led to another and here is a
> patch that seems to fix the problem for me:
> ---
> commit fecb5e8a90631f06600d87165cc8b6de3e035dfc
> Author: Andriy Gapon 
> Date:   Thu Sep 3 17:24:23 2015 +0300
>
> radeon_suspend_kms: don't mess with pci state that's managed by the bus
>
> The pci bus driver handles the power state and configuration state saving
> and restoring for its child devices.
>
> diff --git a/sys/dev/drm2/radeon/radeon_device.c
> b/sys/dev/drm2/radeon/radeon_device.c
> index e5c676b11ed47..73b2f4c51ada2 100644
> --- a/sys/dev/drm2/radeon/radeon_device.c
> +++ b/sys/dev/drm2/radeon/radeon_device.c
> @@ -1342,14 +1342,10 @@ int radeon_suspend_kms(struct drm_device *dev)
>
> radeon_agp_suspend(rdev);
>
> -   pci_save_state(device_get_parent(dev->dev));
>  #ifdef FREEBSD_WIP
> if (state.event == PM_EVENT_SUSPEND) {
> /* Shut down the device */
> pci_disable_device(dev->pdev);
> -#endif /* FREEBSD_WIP */
> -   pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3);
> -#ifdef FREEBSD_WIP
> }
> console_lock();
>  #endif /* FREEBSD_WIP */
> @@ -1380,10 +1376,6 @@ int radeon_resume_kms(struct drm_device *dev)
>
>  #ifdef FREEBSD_WIP
> console_lock();
> -#endif /* FREEBSD_WIP */
> -   pci_set_powerstate(device_get_parent(dev->dev), PCI_POWERSTATE_D0);
> -   pci_restore_state(device_get_parent(dev->dev));
> -#ifdef FREEBSD_WIP
> if (pci_enable_device(dev->pdev)) {
> console_unlock();
> return -1;
> ---
>
> However, I am not sure about an exact mechanism of the hard system hang that I
> experienced without the patch.
>
> BTW, I noticed that only very few drivers make explicit calls to
> pci_set_powerstate and pci_save_state/pci_restore_state.
> sys/dev/usb/controller/ohci_pci.c looks like a good use of pci_set_powerstate.
> sys/dev/ixgbe/if_ix.c looks like an incorrect / redundant use of the 
> functions.
>
> --
> Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Andriy Gapon]

On 04/09/2015 01:29, Anthony Jenkins wrote:
> My Radeon card comes back from resume, but the backlight doesn't (it
> stays off).  Think this patch might help with that?

Likely not, but who knows.

> I was gonna start a
> separate thread to ask for help debugging my backlight issue...


-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Jung-uk Kim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/03/2015 13:50, Andriy Gapon wrote:
> On 31/08/2015 11:53, Adrian Chadd wrote:
>> Try disabling hardware one at a time. Ie, unload usb; unload
>> wifi; leave kms loaded for mostly obvious reasons.
> 
> Adrian, Garrett,
> 
> thank you very much for your tips. Turned out that it was radeonkms
> that was causing the problem :-)
> 
> BTW, here is another tool for the toolkit: on sufficiently recent
> system devctl suspend and devctl resume can be used to test
> individual drivers.
> 
> So, I noticed that I could suspend/resume drmn0 device just fine
> but with vgapci0 I had a trouble suspending.  One thing led to
> another and here is a patch that seems to fix the problem for me: 
> --
- -
>
> 
commit fecb5e8a90631f06600d87165cc8b6de3e035dfc
> Author: Andriy Gapon  Date:   Thu Sep 3 17:24:23
> 2015 +0300
> 
> radeon_suspend_kms: don't mess with pci state that's managed by the
> bus
> 
> The pci bus driver handles the power state and configuration state
> saving and restoring for its child devices.
> 
> diff --git a/sys/dev/drm2/radeon/radeon_device.c 
> b/sys/dev/drm2/radeon/radeon_device.c index
> e5c676b11ed47..73b2f4c51ada2 100644 ---
> a/sys/dev/drm2/radeon/radeon_device.c +++
> b/sys/dev/drm2/radeon/radeon_device.c @@ -1342,14 +1342,10 @@ int
> radeon_suspend_kms(struct drm_device *dev)
> 
> radeon_agp_suspend(rdev);
> 
> - pci_save_state(device_get_parent(dev->dev)); #ifdef FREEBSD_WIP 
> if (state.event == PM_EVENT_SUSPEND) { /* Shut down the device */ 
> pci_disable_device(dev->pdev); -#endif /* FREEBSD_WIP */ -
> pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3); -#ifdef
> FREEBSD_WIP } console_lock(); #endif /* FREEBSD_WIP */ @@ -1380,10
> +1376,6 @@ int radeon_resume_kms(struct drm_device *dev)
> 
> #ifdef FREEBSD_WIP console_lock(); -#endif /* FREEBSD_WIP */ -
> pci_set_powerstate(device_get_parent(dev->dev),
> PCI_POWERSTATE_D0); -
> pci_restore_state(device_get_parent(dev->dev)); -#ifdef
> FREEBSD_WIP if (pci_enable_device(dev->pdev)) { console_unlock(); 
> return -1; 
> --
- -
>
>  However, I am not sure about an exact mechanism of the hard system
> hang that I experienced without the patch.
> 
> BTW, I noticed that only very few drivers make explicit calls to 
> pci_set_powerstate and pci_save_state/pci_restore_state. 
> sys/dev/usb/controller/ohci_pci.c looks like a good use of
> pci_set_powerstate. sys/dev/ixgbe/if_ix.c looks like an incorrect /
> redundant use of the functions.

AFAICT, the whole suspend/resume code looks incomplete and very messy.
 In fact, I'll be very surprised if it ever worked. :-(

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV6MdGAAoJEHyflib82/FGJ68H/2W6IfhDrtciL2LmA67T0VHU
Nagp1Oghp+JDw/iVB28Sxf/EXptsZKUeKvSYYilIFHsl/d/+uPvhbaxLVWUSyhGe
C5vVCbSkyRwnz3I5iiMab9Ou+VFTVqHhNLgrCFfDvjeHssbIkD7+bEuldWyqOIFH
rvvvZ8qGebVV7jcfU3lVVUz3tNwLwgdtVPuZIohxc8M7n1pE185hnUa1b37pytC9
btrCYLstGRNBbaD530iMN0bXM02aWgUTbf9cVH31nYduQaYOPYe/JgNKLzbmJ0gL
JIhGh4eubyR4W2SonRsg1ahHHzSr1pe1o7TVuU+2G1fycz4GSLoFWzYnSTxDMc4=
=IAfV
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[David Wolfskill]

[Much trimming, both of older content and recipient addresses -- dhw]

On Thu, Sep 03, 2015 at 06:18:52PM -0400, Jung-uk Kim wrote:
> ...
> AFAICT, the whole suspend/resume code looks incomplete and very messy.
>  In fact, I'll be very surprised if it ever worked. :-(
> 
> Jung-uk Kim
> ...

While I bow to your expertise in the area, I point out that I
routinely suspend my laptop before putting it in my backpack, then
cycling between the shuttle stop and my house during my daily
commutes to & from work -- usually running stable/10, but I'm
sometimes running head at the time.

And I track both stable/10 and head daily on that laptop (in different
slices).

While I do encounter "issues" from time to time, those are rare enough
that I'd call them "unusual."  (To quantify that, I think I've had 3 - 5
such incidents since November 2014, while generally commuting 5
days/week.)

I'll be happy to test. :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp19ZWuLnU87.pgp
Description: PGP signature

Re: acpi suspend debugging techniques?

[Anthony Jenkins]

My Radeon card comes back from resume, but the backlight doesn't (it
stays off).  Think this patch might help with that?  I was gonna start a
separate thread to ask for help debugging my backlight issue...

Thanks,
Anthony

On 09/03/15 16:06, Adrian Chadd wrote:
> oioo, would you please put that radeon patch into a review?
>
> I have an older machine with a radeon card in it that doesn't yet
> suspend/resume; I can now test it out!
>
>
> -a
>
>
> On 3 September 2015 at 10:50, Andriy Gapon <a...@freebsd.org> wrote:
>> On 31/08/2015 11:53, Adrian Chadd wrote:
>>> Try disabling hardware one at a time. Ie, unload usb; unload wifi;
>>> leave kms loaded for mostly obvious reasons.
>> Adrian, Garrett,
>>
>> thank you very much for your tips.
>> Turned out that it was radeonkms that was causing the problem :-)
>>
>> BTW, here is another tool for the toolkit: on sufficiently recent system 
>> devctl
>> suspend and devctl resume can be used to test individual drivers.
>>
>> So, I noticed that I could suspend/resume drmn0 device just fine but with
>> vgapci0 I had a trouble suspending.  One thing led to another and here is a
>> patch that seems to fix the problem for me:
>> ---
>> commit fecb5e8a90631f06600d87165cc8b6de3e035dfc
>> Author: Andriy Gapon <a...@icyb.net.ua>
>> Date:   Thu Sep 3 17:24:23 2015 +0300
>>
>> radeon_suspend_kms: don't mess with pci state that's managed by the bus
>>
>> The pci bus driver handles the power state and configuration state saving
>> and restoring for its child devices.
>>
>> diff --git a/sys/dev/drm2/radeon/radeon_device.c
>> b/sys/dev/drm2/radeon/radeon_device.c
>> index e5c676b11ed47..73b2f4c51ada2 100644
>> --- a/sys/dev/drm2/radeon/radeon_device.c
>> +++ b/sys/dev/drm2/radeon/radeon_device.c
>> @@ -1342,14 +1342,10 @@ int radeon_suspend_kms(struct drm_device *dev)
>>
>> radeon_agp_suspend(rdev);
>>
>> -   pci_save_state(device_get_parent(dev->dev));
>>  #ifdef FREEBSD_WIP
>> if (state.event == PM_EVENT_SUSPEND) {
>> /* Shut down the device */
>> pci_disable_device(dev->pdev);
>> -#endif /* FREEBSD_WIP */
>> -   pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3);
>> -#ifdef FREEBSD_WIP
>> }
>> console_lock();
>>  #endif /* FREEBSD_WIP */
>> @@ -1380,10 +1376,6 @@ int radeon_resume_kms(struct drm_device *dev)
>>
>>  #ifdef FREEBSD_WIP
>> console_lock();
>> -#endif /* FREEBSD_WIP */
>> -   pci_set_powerstate(device_get_parent(dev->dev), PCI_POWERSTATE_D0);
>> -   pci_restore_state(device_get_parent(dev->dev));
>> -#ifdef FREEBSD_WIP
>> if (pci_enable_device(dev->pdev)) {
>> console_unlock();
>> return -1;
>> ---
>>
>> However, I am not sure about an exact mechanism of the hard system hang that 
>> I
>> experienced without the patch.
>>
>> BTW, I noticed that only very few drivers make explicit calls to
>> pci_set_powerstate and pci_save_state/pci_restore_state.
>> sys/dev/usb/controller/ohci_pci.c looks like a good use of 
>> pci_set_powerstate.
>> sys/dev/ixgbe/if_ix.c looks like an incorrect / redundant use of the 
>> functions.
>>
>> --
>> Andriy Gapon
> ___
> freebsd-a...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

-- 
Anthony Jenkins
Software Engineer
VTilt Digital, LLC

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Andriy Gapon]

On 04/09/2015 01:18, Jung-uk Kim wrote:
> AFAICT, the whole suspend/resume code looks incomplete and very messy.
>  In fact, I'll be very surprised if it ever worked. :-(

It does seem to work for me with the patch and other people report that the code
works for them even without the patch.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Jung-uk Kim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/03/2015 18:30, David Wolfskill wrote:
> [Much trimming, both of older content and recipient addresses --
> dhw]
> 
> On Thu, Sep 03, 2015 at 06:18:52PM -0400, Jung-uk Kim wrote:
>> ... AFAICT, the whole suspend/resume code looks incomplete and
>> very messy. In fact, I'll be very surprised if it ever worked.
>> :-(
>> 
>> Jung-uk Kim ...
> 
> While I bow to your expertise in the area, I point out that I 
> routinely suspend my laptop before putting it in my backpack, then 
> cycling between the shuttle stop and my house during my daily 
> commutes to & from work -- usually running stable/10, but I'm 
> sometimes running head at the time.
> 
> And I track both stable/10 and head daily on that laptop (in
> different slices).
> 
> While I do encounter "issues" from time to time, those are rare
> enough that I'd call them "unusual."  (To quantify that, I think
> I've had 3 - 5 such incidents since November 2014, while generally
> commuting 5 days/week.)
> 
> I'll be happy to test. :-)

I am not saying the patch is wrong.  Actually, it is in the right
direction.  If you can, please test the following patch, too.

- --- sys/dev/drm2/radeon/radeon_drv.c  (revision 287437)
+++ sys/dev/drm2/radeon/radeon_drv.c(working copy)
@@ -327,14 +327,14 @@ radeon_suspend(device_t kdev)
struct drm_device *dev;
int ret;

+   ret = bus_generic_suspend(kdev);
+   if (ret)
+   return (ret);
+
dev = device_get_softc(kdev);
ret = radeon_suspend_kms(dev);
- - if (ret)
- - return (-ret);

- - ret = bus_generic_suspend(kdev);
- -
- - return (ret);
+   return (-ret);
 }

 static int


Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV6M6cAAoJEHyflib82/FGX1UH/0BaQl+/e7Cqc2+3jdcmuusd
P8gJBGIFu89+6KsA2J1btQQYO2wwA9tJkpkZx4oi/pT+L+pIqZGx7/w7klsfXvXd
gfI0looWxzB5ZALCrzYq50Nk67E9s6iXymRMJ95oyZ2GLkbwLqY6gOStqld7vBuE
Z4iEBYHMrDtojd33w/9SRa8zNSpvwXZJliNjhpFd680ApkSO2xN/dIxI/z1JjlEw
oquRpvFlR4urqCdhYmKyjoXuR7rYdl0K2imfA7EjL2RFzlFyacS+ny4BqnbvMqzC
tMNxYFUOEvxMW+336DKZjiRWgAyfmJiOuoFxRoDiCq42zzjcLF+2gnLlcd4/j+4=
=/r95
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

acpi suspend debugging techniques?

[Andriy Gapon]

I would appreciate any pointers at how to debug an ACPI suspend problem that I 
have.

What I have so far.  The system hangs when I try to suspend it and it gets reset
by a watchdog.  Setting debug.acpi.suspend_bounce=1 does not make any
difference, so the hang happens before the final sleep code is executed.  I
think that the device suspend stage is executed, because disks get spun down and
video signals gets cut off.

I could enable / add some debug printfs, but I suppose that their output would
get lost due to the above.  RAM content unfortunately does not survive across
the resets.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Garrett Cooper]

> On Aug 30, 2015, at 23:13, Andriy Gapon <a...@freebsd.org> wrote:
> 
> 
> I would appreciate any pointers at how to debug an ACPI suspend problem that 
> I have.
> 
> What I have so far.  The system hangs when I try to suspend it and it gets 
> reset
> by a watchdog.  Setting debug.acpi.suspend_bounce=1 does not make any
> difference, so the hang happens before the final sleep code is executed.  I
> think that the device suspend stage is executed, because disks get spun down 
> and
> video signals gets cut off.
> 
> I could enable / add some debug printfs, but I suppose that their output would
> get lost due to the above.  RAM content unfortunately does not survive across
> the resets.

When I last had to do this to figure out what magic formula was required to get 
my netbook working, I did something like this:

1. Stripped down the kernel to just the storage driver and core pieces.
2. Loaded all other modules after boot, if necessary.
3. Called zzz with the appropriate ACPI tunables/sysctls set.

That got me pointed in the right direction (IIRC it was psm at the time). What 
I did to get a real smoking gun was I put printf statements in subr_bus.c 
(IIRC) to track device quiescing at suspend and reawakening at resume.

There’s `options BUS_DEBUG` too, which may or may not help.

FWIW I found debug.acpi.suspend_bounce less useful, but it still exercised the 
quiesce->reawaken cycle, sorta.

There’s also `hw.acpi.reset_video` and `debug.acpi.resume_beep`.

You might need to hack /etc/rc.resume and /etc/rc.suspend, BTW, depending on 
what you discover (switching my vty was definitely required in order for X11 to 
come back in a sane manner at resume).

Cheers,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi suspend debugging techniques?

[Adrian Chadd]

hi,

Try disabling hardware one at a time. Ie, unload usb; unload wifi;
leave kms loaded for mostly obvious reasons.

I hit a few of these which turned out to be an issue in the suspend
path of a driver - and once I found it was the USB hardware but the
BIOS itself that was hanging - FreeBSD put USB hardware into S3, but
the ACPI BIOS requested S2 and just hung if we had USB in S3. :(



-adrian


On 30 August 2015 at 23:33, Garrett Cooper <yaneurab...@gmail.com> wrote:
>
>> On Aug 30, 2015, at 23:13, Andriy Gapon <a...@freebsd.org> wrote:
>>
>>
>> I would appreciate any pointers at how to debug an ACPI suspend problem that 
>> I have.
>>
>> What I have so far.  The system hangs when I try to suspend it and it gets 
>> reset
>> by a watchdog.  Setting debug.acpi.suspend_bounce=1 does not make any
>> difference, so the hang happens before the final sleep code is executed.  I
>> think that the device suspend stage is executed, because disks get spun down 
>> and
>> video signals gets cut off.
>>
>> I could enable / add some debug printfs, but I suppose that their output 
>> would
>> get lost due to the above.  RAM content unfortunately does not survive across
>> the resets.
>
> When I last had to do this to figure out what magic formula was required to 
> get my netbook working, I did something like this:
>
> 1. Stripped down the kernel to just the storage driver and core pieces.
> 2. Loaded all other modules after boot, if necessary.
> 3. Called zzz with the appropriate ACPI tunables/sysctls set.
>
> That got me pointed in the right direction (IIRC it was psm at the time). 
> What I did to get a real smoking gun was I put printf statements in 
> subr_bus.c (IIRC) to track device quiescing at suspend and reawakening at 
> resume.
>
> There’s `options BUS_DEBUG` too, which may or may not help.
>
> FWIW I found debug.acpi.suspend_bounce less useful, but it still exercised 
> the quiesce->reawaken cycle, sorta.
>
> There’s also `hw.acpi.reset_video` and `debug.acpi.resume_beep`.
>
> You might need to hack /etc/rc.resume and /etc/rc.suspend, BTW, depending on 
> what you discover (switching my vty was definitely required in order for X11 
> to come back in a sane manner at resume).
>
> Cheers,
> -NGie
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Weird ACPI/DRM messages on -current

[Konstantin Belousov]

On Fri, Feb 06, 2015 at 05:10:24PM +, Poul-Henning Kamp wrote:
 Thinkpad T430s:
 
 11.0-CURRENT #15 r278283: Thu Feb  5 22:45:26 UTC 2015
 
 Anybody know what this means ?
There is no public documentation about renderer power and clock
management. It seems that NDA'ed doc does not contain it either, but I
am not sure if I am allowed to publically state what NDA doc does not
contain.

 
 Feb  6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 0007, was 
 1907
 Feb  6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 
 Feb  6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900

These are mostly informational messages, code was taken verbosely from
the Linux kernel.  It seems that later Linux code reorganized code and
get rid of the message.  Some next import will shut down the warnings.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Weird ACPI/DRM messages on -current

[Allan Jude]

On 2015-02-06 12:10, Poul-Henning Kamp wrote:
 Thinkpad T430s:
 
 11.0-CURRENT #15 r278283: Thu Feb  5 22:45:26 UTC 2015
 
 Anybody know what this means ?
 
 Feb  6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 0007, was 
 1907
 Feb  6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 
 Feb  6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 
 

I am pretty sure this is specific to the new drm code

I saw similar messages when testing the drm patch before it was committed

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Weird ACPI/DRM messages on -current

[Garrett Cooper]

On Feb 6, 2015, at 9:10, Poul-Henning Kamp p...@phk.freebsd.dk wrote:

 Thinkpad T430s:
 
 11.0-CURRENT #15 r278283: Thu Feb  5 22:45:26 UTC 2015
 
 Anybody know what this means ?
 
 Feb  6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 0007, was 
 1907
 Feb  6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 
 Feb  6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900
 Feb  6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
 Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
 1900

Please file a bug for the logspam.
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Weird ACPI/DRM messages on -current

[Adrian Chadd]

Can someone just go digging through the include files to see what the
difference in bits are?

This may be related to increased power usage that's been reported.


-a


On 6 February 2015 at 13:06, Allan Jude allanj...@freebsd.org wrote:
 On 2015-02-06 12:10, Poul-Henning Kamp wrote:
 Thinkpad T430s:

 11.0-CURRENT #15 r278283: Thu Feb  5 22:45:26 UTC 2015

 Anybody know what this means ?

 Feb  6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 1907, was 1900
 Feb  6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 1907, was 1900
 Feb  6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 1907, was 1900
 Feb  6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 1907, was 1900
 Feb  6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 1907, was 1900
 Feb  6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 0007, was 1907
 Feb  6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 1907, was 
 Feb  6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 1907, was 1900
 Feb  6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 1907, was 1900
 Feb  6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] 
 *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 
 1907, was 1900



 I am pretty sure this is specific to the new drm code

 I saw similar messages when testing the drm patch before it was committed

 --
 Allan Jude

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Weird ACPI/DRM messages on -current

[Kevin Oberman]

On Fri, Feb 6, 2015 at 2:00 PM, Adrian Chadd adr...@freebsd.org wrote:

 Can someone just go digging through the include files to see what the
 difference in bits are?

 This may be related to increased power usage that's been reported.


 -a


It's defined in /sys/dev/drm2/i915/i915_reg.h. Unfortunately, no breakdown
is shown. In i915_irq.c and intel_display I see:
I915_WRITE(GEN6_RP_INTERRUPT_LIMITS,
   18  24 |
   6  16);

The exact same code appears in both and these are the only references to
that  I can find. This leaves my with no more idea than I had before I
looked. maybe someone has more of a clue.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Weird ACPI/DRM messages on -current

[Poul-Henning Kamp]

Thinkpad T430s:

11.0-CURRENT #15 r278283: Thu Feb  5 22:45:26 UTC 2015

Anybody know what this means ?

Feb  6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 0007, was 
1907
Feb  6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 

Feb  6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Tomoaki AOKI]

+1.
ThinkPad T420 with nvidia discrete GPU, amd64 using memstick.img dd'ed
to USB memstick. (So UEFI boot.)

  *Vanilla r276247 doesn't boot. No panic, just hang in allocating
   resource for pcib. Sorry for not recording exact message.

  *Reverting r276064 alone from r276247 helped. All other parts are
   r276247.

  *Legacy boot in VirtualBox VM is OK with vanilla r276247.


On Sun, 28 Dec 2014 20:33:55 +0100 (CET)
Jakob Alvermark ja...@alvermark.net wrote:

 Ian Lepore ian at freebsd.org writes:
 
 
  On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote:
   On 26 December 2014 at 04:01, O. Hartmann ohartman at zedat.fu-
 berlin.de wrote:
Am Thu, 25 Dec 2014 11:40:47 -0800
Adrian Chadd adrian at freebsd.org schrieb:
   
Would you be able to narrow it down to a small range of commits?
that'll make it easier to chase down. :)
   
 Booting old kernel/modules (via boot kernel.old), at CURRENT
 r275896 is all right.

 What is happening here?

 Merry christmas day,

 oh
   
   
I narrowed down the culprit commit to be between r276060 (works) and
 r276075 (works not).
  
   Hi!
  
   Thanks for that. Would you please file a PR with the details and what
   you've done?
  
   I hope you can narrow it down further. You've done a great job
   already, I just can't see any clear winner there for a commit to back
   out :(
 
  r276064 looks like a candidate.  At least, it has 'efi' in the name. :)
 
 
 I can confirm that. The same happened when UEFI-booting on my Acer E3-112.
 Undoing r276064 makes it boot again.
 
 (I will post some more experiences with FreeBSD on this machine later.)
 
 Jakob
 
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 


-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Roger Pau Monné]

El 29/12/14 a les 23.49, Jakob Alvermark ha escrit:
 On Mon, December 29, 2014 20:12, Marius Strobl wrote:
 On Mon, Dec 29, 2014 at 05:55:28PM +0100, Roger Pau Monné wrote:

 El 29/12/14 a les 12.41, Roger Pau Monné ha escrit:

 Hello,


 Sorry for not noticing this earlier, I've been without a computer for
  some days. Do you get a panic message, or the system just freezes?

 Can you please post the full boot output with boot_verbose enabled?


 I'm not able to reproduce the problem with Qemu and OVMF, and I don't
 have any box right now that uses UEFI.

 I'm guessing that this is due to some memory reservation conflict, so
 I'm attaching a patch that should help diagnose it.


 You'll probably want to nuke RF_ACTIVE so the resources are marked
 as taken but in case of vt_efifb(4), the memory isn't mapped twice. I don't
 not know whether the latter actually is a problem for x86, though, it'll
 likely at least replace the VM_MEMATTR_WRITE_COMBINING mapping done in
 vt_efifb_remap(). Removing RF_ACTIVE in turn might not be sufficient for
 the Xen bits to mark the resource as reserved, this should be fixed in the
 FreeBSD/Xen code then, however.
 Also end = size - 1, see the attached patch.
 
 Hi, I tried this patch on my Acer. I does not help. Legacy boot (BIOS)
 still works.

I've reverted the EFI part of r276064 and committed it as r276405, I
will revisit it in a couple of days when I have an UEFI system setup in
order to test it on real hardware.

Roger.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Jakob Alvermark]

On Tue, December 30, 2014 13:39, Roger Pau Monné wrote:
 El 29/12/14 a les 23.49, Jakob Alvermark ha escrit:

 On Mon, December 29, 2014 20:12, Marius Strobl wrote:

 On Mon, Dec 29, 2014 at 05:55:28PM +0100, Roger Pau Monné wrote:


 El 29/12/14 a les 12.41, Roger Pau Monné ha escrit:


 Hello,



 Sorry for not noticing this earlier, I've been without a computer
 for some days. Do you get a panic message, or the system just
 freezes?

 Can you please post the full boot output with boot_verbose
 enabled?


 I'm not able to reproduce the problem with Qemu and OVMF, and I
 don't have any box right now that uses UEFI.

 I'm guessing that this is due to some memory reservation conflict,
 so I'm attaching a patch that should help diagnose it.



 You'll probably want to nuke RF_ACTIVE so the resources are marked
 as taken but in case of vt_efifb(4), the memory isn't mapped twice. I
 don't not know whether the latter actually is a problem for x86,
 though, it'll likely at least replace the VM_MEMATTR_WRITE_COMBINING
 mapping done in vt_efifb_remap(). Removing RF_ACTIVE in turn might not
 be sufficient for the Xen bits to mark the resource as reserved, this
 should be fixed in the FreeBSD/Xen code then, however.
 Also end = size - 1, see the attached patch.


 Hi, I tried this patch on my Acer. I does not help. Legacy boot (BIOS)
 still works.

 I've reverted the EFI part of r276064 and committed it as r276405, I
 will revisit it in a couple of days when I have an UEFI system setup in
 order to test it on real hardware.

It works fine. Both legacy and UEFI. Thanks! Now on to the other
interresting things with UEFI on this machine...

Jakob

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Roger Pau Monné]

El 28/12/14 a les 22.37, Adrian Chadd ha escrit:
 Hah sweet! You found the commit!
 
 Would you please file a PR so it doesn't get lost?
 
 Thanks!
 
 
 
 -adrian
 
 
 On 28 December 2014 at 12:09, Ian Lepore i...@freebsd.org wrote:
 On Sun, 2014-12-28 at 20:57 +0100, O. Hartmann wrote:
 Am Fri, 26 Dec 2014 12:23:42 -0700
 Ian Lepore i...@freebsd.org schrieb:

 On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote:
 On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de 
 wrote:
 Am Thu, 25 Dec 2014 11:40:47 -0800
 Adrian Chadd adr...@freebsd.org schrieb:

 Would you be able to narrow it down to a small range of commits?
 that'll make it easier to chase down. :)

 Thanks!



 -adrian


 On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de 
 wrote:

 Since 23rd's update of CURRENT, the kernel fails to boot on systems 
 that boot
 via EFI. Systems with legacy booting seem not to be affected.

 I just ran today into the problem updating a notebook with a Intel 
 Haswell Intel
 i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, 
 CURRENT
 r276200. The very same caode base is running on several other boxes 
 which boot
 via legacy method. The very same failure showed up at the lab on an 
 older HP
 Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge 
 CPU,
 booting also via EFI. That box stops at the exact same spot as the 
 notebook does.

 The systems in question, also the legacy booting systems (aka the 
 oldstyle
 loader boot method), load drm2, i915kms.

 Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 
 is all
 right.

 What is happening here?

Hello,

Sorry for not noticing this earlier, I've been without a computer for
some days. Do you get a panic message, or the system just freezes?

Can you please post the full boot output with boot_verbose enabled?

Thanks, Roger.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Roger Pau Monné]

El 29/12/14 a les 12.41, Roger Pau Monné ha escrit:
 Hello,
 
 Sorry for not noticing this earlier, I've been without a computer for
 some days. Do you get a panic message, or the system just freezes?
 
 Can you please post the full boot output with boot_verbose enabled?

I'm not able to reproduce the problem with Qemu and OVMF, and I don't
have any box right now that uses UEFI.

I'm guessing that this is due to some memory reservation conflict, so
I'm attaching a patch that should help diagnose it. Could you provide
the information requested above with this patch applied?

Thanks, Roger.

diff --git a/sys/x86/x86/nexus.c b/sys/x86/x86/nexus.c
index 0663602..d563c36 100644
--- a/sys/x86/x86/nexus.c
+++ b/sys/x86/x86/nexus.c
@@ -367,6 +367,10 @@ nexus_alloc_resource(device_t bus, device_t child, int 
type, int *rid,
struct  rman *rm;
int needactivate = flags  RF_ACTIVE;
 
+   if (type == SYS_RES_MEMORY)
+   printf(%s: RSV range 0x%lx - 0x%lx size %lu\n,
+   device_get_name(child), start, end, count);
+
/*
 * If this is an allocation of the default range for a given
 * RID, and we know what the resources for this device are
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Marius Strobl]

On Mon, Dec 29, 2014 at 05:55:28PM +0100, Roger Pau Monné wrote:
 El 29/12/14 a les 12.41, Roger Pau Monné ha escrit:
  Hello,
  
  Sorry for not noticing this earlier, I've been without a computer for
  some days. Do you get a panic message, or the system just freezes?
  
  Can you please post the full boot output with boot_verbose enabled?
 
 I'm not able to reproduce the problem with Qemu and OVMF, and I don't
 have any box right now that uses UEFI.
 
 I'm guessing that this is due to some memory reservation conflict, so
 I'm attaching a patch that should help diagnose it.

You'll probably want to nuke RF_ACTIVE so the resources are marked
as taken but in case of vt_efifb(4), the memory isn't mapped twice.
I don't not know whether the latter actually is a problem for x86,
though, it'll likely at least replace the VM_MEMATTR_WRITE_COMBINING
mapping done in vt_efifb_remap(). Removing RF_ACTIVE in turn might
not be sufficient for the Xen bits to mark the resource as reserved,
this should be fixed in the FreeBSD/Xen code then, however.
Also end = size - 1, see the attached patch.

Marius

Index: dev/vt/hw/efifb/efifb.c
===
--- dev/vt/hw/efifb/efifb.c	(revision 276343)
+++ dev/vt/hw/efifb/efifb.c	(working copy)
@@ -211,8 +211,8 @@
 	res_id = 0;
 	pseudo_phys_res = bus_alloc_resource(dev, SYS_RES_MEMORY,
 	res_id, local_info.fb_pbase,
-	local_info.fb_pbase + local_info.fb_size,
-	local_info.fb_size, RF_ACTIVE);
+	local_info.fb_pbase + local_info.fb_size - 1,
+	local_info.fb_size, 0);
 	if (pseudo_phys_res == NULL)
 		panic(Unable to reserve vt_efifb memory);
 	return (0);
Index: dev/vt/hw/vga/vt_vga.c
===
--- dev/vt/hw/vga/vt_vga.c	(revision 276343)
+++ dev/vt/hw/vga/vt_vga.c	(working copy)
@@ -1275,8 +1275,8 @@
 
 	res_id = 0;
 	pseudo_phys_res = bus_alloc_resource(dev, SYS_RES_MEMORY,
-	res_id, VGA_MEM_BASE, VGA_MEM_BASE + VGA_MEM_SIZE,
-	VGA_MEM_SIZE, RF_ACTIVE);
+	res_id, VGA_MEM_BASE, VGA_MEM_BASE + VGA_MEM_SIZE - 1,
+	VGA_MEM_SIZE, 0);
 	if (pseudo_phys_res == NULL)
 		panic(Unable to reserve vt_vga memory);
 	return (0);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Marius Strobl]

On Mon, Dec 29, 2014 at 08:12:42PM +0100, Marius Strobl wrote:
 On Mon, Dec 29, 2014 at 05:55:28PM +0100, Roger Pau Monné wrote:
  El 29/12/14 a les 12.41, Roger Pau Monné ha escrit:
   Hello,
   
   Sorry for not noticing this earlier, I've been without a computer for
   some days. Do you get a panic message, or the system just freezes?
   
   Can you please post the full boot output with boot_verbose enabled?
  
  I'm not able to reproduce the problem with Qemu and OVMF, and I don't
  have any box right now that uses UEFI.
  
  I'm guessing that this is due to some memory reservation conflict, so
  I'm attaching a patch that should help diagnose it.
 
 You'll probably want to nuke RF_ACTIVE so the resources are marked
 as taken but in case of vt_efifb(4), the memory isn't mapped twice.
 I don't not know whether the latter actually is a problem for x86,
 though, it'll likely at least replace the VM_MEMATTR_WRITE_COMBINING
 mapping done in vt_efifb_remap(). Removing RF_ACTIVE in turn might
 not be sufficient for the Xen bits to mark the resource as reserved,
 this should be fixed in the FreeBSD/Xen code then, however.
 Also end = size - 1, see the attached patch.

Err, end = start + size - 1 that is.

Marius
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Jakob Alvermark]

On Mon, December 29, 2014 20:12, Marius Strobl wrote:
 On Mon, Dec 29, 2014 at 05:55:28PM +0100, Roger Pau Monné wrote:

 El 29/12/14 a les 12.41, Roger Pau Monné ha escrit:

 Hello,


 Sorry for not noticing this earlier, I've been without a computer for
  some days. Do you get a panic message, or the system just freezes?

 Can you please post the full boot output with boot_verbose enabled?


 I'm not able to reproduce the problem with Qemu and OVMF, and I don't
 have any box right now that uses UEFI.

 I'm guessing that this is due to some memory reservation conflict, so
 I'm attaching a patch that should help diagnose it.


 You'll probably want to nuke RF_ACTIVE so the resources are marked
 as taken but in case of vt_efifb(4), the memory isn't mapped twice. I don't
 not know whether the latter actually is a problem for x86, though, it'll
 likely at least replace the VM_MEMATTR_WRITE_COMBINING mapping done in
 vt_efifb_remap(). Removing RF_ACTIVE in turn might not be sufficient for
 the Xen bits to mark the resource as reserved, this should be fixed in the
 FreeBSD/Xen code then, however.
 Also end = size - 1, see the attached patch.

Hi, I tried this patch on my Acer. I does not help. Legacy boot (BIOS)
still works.

Jakob

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[O. Hartmann]

Am Fri, 26 Dec 2014 12:23:42 -0700
Ian Lepore i...@freebsd.org schrieb:

 On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote:
  On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de 
  wrote:
   Am Thu, 25 Dec 2014 11:40:47 -0800
   Adrian Chadd adr...@freebsd.org schrieb:
  
   Would you be able to narrow it down to a small range of commits?
   that'll make it easier to chase down. :)
  
   Thanks!
  
  
  
   -adrian
  
  
   On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de 
   wrote:
   
Since 23rd's update of CURRENT, the kernel fails to boot on systems 
that boot
via EFI. Systems with legacy booting seem not to be affected.
   
I just ran today into the problem updating a notebook with a Intel 
Haswell Intel
i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, 
CURRENT
r276200. The very same caode base is running on several other boxes 
which boot
via legacy method. The very same failure showed up at the lab on an 
older HP
Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge 
CPU,
booting also via EFI. That box stops at the exact same spot as the 
notebook does.
   
The systems in question, also the legacy booting systems (aka the 
oldstyle
loader boot method), load drm2, i915kms.
   
Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 
is all
right.
   
What is happening here?
   
Merry christmas day,
   
oh
  
  
   I narrowed down the culprit commit to be between r276060 (works) and 
   r276075 (works
   not). To avoid interferences from rogue modules, I disabled all modules 
   loaded by
   the loader, including drm2 and i915kms, but the picture is always the 
   same. I'm
   sorry, I have some duties to perform, so intersecting further is possible 
   later
   only ... I performed the iterative search of the foul commit by svn 
   update -r
   276XXX and then build kernel only via make kernel - this just for the 
   record in
   case some world-dependencies might have effects.
  
  Hi!
  
  Thanks for that. Would you please file a PR with the details and what
  you've done?
  
  I hope you can narrow it down further. You've done a great job
  already, I just can't see any clear winner there for a commit to back
  out :(
 
 r276064 looks like a candidate.  At least, it has 'efi' in the name. :)
 
 -- Ian

Well, r276063 works, but r2766064 doesn't.

oh


pgpvj85PRaWFh.pgp
Description: OpenPGP digital signature

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Jakob Alvermark]

Ian Lepore ian at freebsd.org writes:


 On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote:
  On 26 December 2014 at 04:01, O. Hartmann ohartman at zedat.fu-
berlin.de wrote:
   Am Thu, 25 Dec 2014 11:40:47 -0800
   Adrian Chadd adrian at freebsd.org schrieb:
  
   Would you be able to narrow it down to a small range of commits?
   that'll make it easier to chase down. :)
  
Booting old kernel/modules (via boot kernel.old), at CURRENT
r275896 is all right.
   
What is happening here?
   
Merry christmas day,
   
oh
  
  
   I narrowed down the culprit commit to be between r276060 (works) and
r276075 (works not).
 
  Hi!
 
  Thanks for that. Would you please file a PR with the details and what
  you've done?
 
  I hope you can narrow it down further. You've done a great job
  already, I just can't see any clear winner there for a commit to back
  out :(

 r276064 looks like a candidate.  At least, it has 'efi' in the name. :)


I can confirm that. The same happened when UEFI-booting on my Acer E3-112.
Undoing r276064 makes it boot again.

(I will post some more experiences with FreeBSD on this machine later.)

Jakob


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Ian Lepore]

On Sun, 2014-12-28 at 20:57 +0100, O. Hartmann wrote:
 Am Fri, 26 Dec 2014 12:23:42 -0700
 Ian Lepore i...@freebsd.org schrieb:
 
  On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote:
   On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de 
   wrote:
Am Thu, 25 Dec 2014 11:40:47 -0800
Adrian Chadd adr...@freebsd.org schrieb:
   
Would you be able to narrow it down to a small range of commits?
that'll make it easier to chase down. :)
   
Thanks!
   
   
   
-adrian
   
   
On 25 December 2014 at 10:42, O. Hartmann 
ohart...@zedat.fu-berlin.de wrote:

 Since 23rd's update of CURRENT, the kernel fails to boot on systems 
 that boot
 via EFI. Systems with legacy booting seem not to be affected.

 I just ran today into the problem updating a notebook with a Intel 
 Haswell Intel
 i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, 
 CURRENT
 r276200. The very same caode base is running on several other boxes 
 which boot
 via legacy method. The very same failure showed up at the lab on an 
 older HP
 Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge 
 CPU,
 booting also via EFI. That box stops at the exact same spot as the 
 notebook does.

 The systems in question, also the legacy booting systems (aka the 
 oldstyle
 loader boot method), load drm2, i915kms.

 Booting old kernel/modules (via boot kernel.old), at CURRENT 
 r275896 is all
 right.

 What is happening here?

 Merry christmas day,

 oh
   
   
I narrowed down the culprit commit to be between r276060 (works) and 
r276075 (works
not). To avoid interferences from rogue modules, I disabled all modules 
loaded by
the loader, including drm2 and i915kms, but the picture is always the 
same. I'm
sorry, I have some duties to perform, so intersecting further is 
possible later
only ... I performed the iterative search of the foul commit by svn 
update -r
276XXX and then build kernel only via make kernel - this just for 
the record in
case some world-dependencies might have effects.
   
   Hi!
   
   Thanks for that. Would you please file a PR with the details and what
   you've done?
   
   I hope you can narrow it down further. You've done a great job
   already, I just can't see any clear winner there for a commit to back
   out :(
  
  r276064 looks like a candidate.  At least, it has 'efi' in the name. :)
  
  -- Ian
 
 Well, r276063 works, but r2766064 doesn't.
 
 oh

cc'ing the author of r276064, since spotting the fact that 'efi' was
involved in that revision used up 100% of my expertise in efi stuff. :)

-- Ian



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Adrian Chadd]

Hah sweet! You found the commit!

Would you please file a PR so it doesn't get lost?

Thanks!



-adrian


On 28 December 2014 at 12:09, Ian Lepore i...@freebsd.org wrote:
 On Sun, 2014-12-28 at 20:57 +0100, O. Hartmann wrote:
 Am Fri, 26 Dec 2014 12:23:42 -0700
 Ian Lepore i...@freebsd.org schrieb:

  On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote:
   On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de 
   wrote:
Am Thu, 25 Dec 2014 11:40:47 -0800
Adrian Chadd adr...@freebsd.org schrieb:
   
Would you be able to narrow it down to a small range of commits?
that'll make it easier to chase down. :)
   
Thanks!
   
   
   
-adrian
   
   
On 25 December 2014 at 10:42, O. Hartmann 
ohart...@zedat.fu-berlin.de wrote:

 Since 23rd's update of CURRENT, the kernel fails to boot on systems 
 that boot
 via EFI. Systems with legacy booting seem not to be affected.

 I just ran today into the problem updating a notebook with a Intel 
 Haswell Intel
 i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, 
 CURRENT
 r276200. The very same caode base is running on several other boxes 
 which boot
 via legacy method. The very same failure showed up at the lab on an 
 older HP
 Compaq 8300 system, based on H81 chipset equipted with an 
 Ivy-Bridge CPU,
 booting also via EFI. That box stops at the exact same spot as the 
 notebook does.

 The systems in question, also the legacy booting systems (aka the 
 oldstyle
 loader boot method), load drm2, i915kms.

 Booting old kernel/modules (via boot kernel.old), at CURRENT 
 r275896 is all
 right.

 What is happening here?

 Merry christmas day,

 oh
   
   
I narrowed down the culprit commit to be between r276060 (works) and 
r276075 (works
not). To avoid interferences from rogue modules, I disabled all 
modules loaded by
the loader, including drm2 and i915kms, but the picture is always the 
same. I'm
sorry, I have some duties to perform, so intersecting further is 
possible later
only ... I performed the iterative search of the foul commit by svn 
update -r
276XXX and then build kernel only via make kernel - this just for 
the record in
case some world-dependencies might have effects.
  
   Hi!
  
   Thanks for that. Would you please file a PR with the details and what
   you've done?
  
   I hope you can narrow it down further. You've done a great job
   already, I just can't see any clear winner there for a commit to back
   out :(
 
  r276064 looks like a candidate.  At least, it has 'efi' in the name. :)
 
  -- Ian

 Well, r276063 works, but r2766064 doesn't.

 oh

 cc'ing the author of r276064, since spotting the fact that 'efi' was
 involved in that revision used up 100% of my expertise in efi stuff. :)

 -- Ian



 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[O. Hartmann]

Am Thu, 25 Dec 2014 11:40:47 -0800
Adrian Chadd adr...@freebsd.org schrieb:

 Would you be able to narrow it down to a small range of commits?
 that'll make it easier to chase down. :)
 
 Thanks!
 
 
 
 -adrian
 
 
 On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
  Since 23rd's update of CURRENT, the kernel fails to boot on systems that 
  boot via EFI.
  Systems with legacy booting seem not to be affected.
 
  I just ran today into the problem updating a notebook with a Intel Haswell 
  Intel
  i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT 
  r276200.
  The very same caode base is running on several other boxes which boot via 
  legacy
  method. The very same failure showed up at the lab on an older HP Compaq 
  8300 system,
  based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. 
  That box
  stops at the exact same spot as the notebook does.
 
  The systems in question, also the legacy booting systems (aka the oldstyle 
  loader boot
  method), load drm2, i915kms.
 
  Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is 
  all right.
 
  What is happening here?
 
  Merry christmas day,
 
  oh


I narrowed down the culprit commit to be between r276060 (works) and r276075 
(works not).
To avoid interferences from rogue modules, I disabled all modules loaded by the 
loader,
including drm2 and i915kms, but the picture is always the same. I'm sorry, I 
have some
duties to perform, so intersecting further is possible later only ... I 
performed the
iterative search of the foul commit by svn update -r 276XXX and then build 
kernel only
via make kernel - this just for the record in case some world-dependencies 
might have
effects. 

oh


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Adrian Chadd]

On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 Am Thu, 25 Dec 2014 11:40:47 -0800
 Adrian Chadd adr...@freebsd.org schrieb:

 Would you be able to narrow it down to a small range of commits?
 that'll make it easier to chase down. :)

 Thanks!



 -adrian


 On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de 
 wrote:
 
  Since 23rd's update of CURRENT, the kernel fails to boot on systems that 
  boot via EFI.
  Systems with legacy booting seem not to be affected.
 
  I just ran today into the problem updating a notebook with a Intel Haswell 
  Intel
  i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, 
  CURRENT r276200.
  The very same caode base is running on several other boxes which boot via 
  legacy
  method. The very same failure showed up at the lab on an older HP Compaq 
  8300 system,
  based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via 
  EFI. That box
  stops at the exact same spot as the notebook does.
 
  The systems in question, also the legacy booting systems (aka the oldstyle 
  loader boot
  method), load drm2, i915kms.
 
  Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is 
  all right.
 
  What is happening here?
 
  Merry christmas day,
 
  oh


 I narrowed down the culprit commit to be between r276060 (works) and r276075 
 (works not).
 To avoid interferences from rogue modules, I disabled all modules loaded by 
 the loader,
 including drm2 and i915kms, but the picture is always the same. I'm sorry, I 
 have some
 duties to perform, so intersecting further is possible later only ... I 
 performed the
 iterative search of the foul commit by svn update -r 276XXX and then build 
 kernel only
 via make kernel - this just for the record in case some world-dependencies 
 might have
 effects.

Hi!

Thanks for that. Would you please file a PR with the details and what
you've done?

I hope you can narrow it down further. You've done a great job
already, I just can't see any clear winner there for a commit to back
out :(



-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Ian Lepore]

On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote:
 On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
  Am Thu, 25 Dec 2014 11:40:47 -0800
  Adrian Chadd adr...@freebsd.org schrieb:
 
  Would you be able to narrow it down to a small range of commits?
  that'll make it easier to chase down. :)
 
  Thanks!
 
 
 
  -adrian
 
 
  On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de 
  wrote:
  
   Since 23rd's update of CURRENT, the kernel fails to boot on systems that 
   boot via EFI.
   Systems with legacy booting seem not to be affected.
  
   I just ran today into the problem updating a notebook with a Intel 
   Haswell Intel
   i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, 
   CURRENT r276200.
   The very same caode base is running on several other boxes which boot 
   via legacy
   method. The very same failure showed up at the lab on an older HP Compaq 
   8300 system,
   based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via 
   EFI. That box
   stops at the exact same spot as the notebook does.
  
   The systems in question, also the legacy booting systems (aka the 
   oldstyle loader boot
   method), load drm2, i915kms.
  
   Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 
   is all right.
  
   What is happening here?
  
   Merry christmas day,
  
   oh
 
 
  I narrowed down the culprit commit to be between r276060 (works) and 
  r276075 (works not).
  To avoid interferences from rogue modules, I disabled all modules loaded by 
  the loader,
  including drm2 and i915kms, but the picture is always the same. I'm sorry, 
  I have some
  duties to perform, so intersecting further is possible later only ... I 
  performed the
  iterative search of the foul commit by svn update -r 276XXX and then 
  build kernel only
  via make kernel - this just for the record in case some 
  world-dependencies might have
  effects.
 
 Hi!
 
 Thanks for that. Would you please file a PR with the details and what
 you've done?
 
 I hope you can narrow it down further. You've done a great job
 already, I just can't see any clear winner there for a commit to back
 out :(

r276064 looks like a candidate.  At least, it has 'efi' in the name. :)

-- Ian


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[O. Hartmann]

Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot 
via EFI.
Systems with legacy booting seem not to be affected.

I just ran today into the problem updating a notebook with a Intel Haswell 
Intel i5-4200M
CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The 
very same
caode base is running on several other boxes which boot via legacy method. The 
very same
failure showed up at the lab on an older HP Compaq 8300 system, based on H81 
chipset
equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the 
exact same
spot as the notebook does.

The systems in question, also the legacy booting systems (aka the oldstyle 
loader boot
method), load drm2, i915kms.

Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all 
right.

What is happening here?

Merry christmas day,

oh


pgp_9ujRHrS91.pgp
Description: OpenPGP digital signature

Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0

[Adrian Chadd]

Would you be able to narrow it down to a small range of commits?
that'll make it easier to chase down. :)

Thanks!



-adrian


On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote:

 Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot 
 via EFI.
 Systems with legacy booting seem not to be affected.

 I just ran today into the problem updating a notebook with a Intel Haswell 
 Intel i5-4200M
 CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. 
 The very same
 caode base is running on several other boxes which boot via legacy method. 
 The very same
 failure showed up at the lab on an older HP Compaq 8300 system, based on H81 
 chipset
 equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the 
 exact same
 spot as the notebook does.

 The systems in question, also the legacy booting systems (aka the oldstyle 
 loader boot
 method), load drm2, i915kms.

 Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all 
 right.

 What is happening here?

 Merry christmas day,

 oh
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Sulev-Madis Silber (ketas)]

On 2014-11-17 08:58, Dag-Erling Smørgrav wrote:
 Dag-Erling Smørgrav d...@des.no writes:
 Steve Kargl s...@troutmask.apl.washington.edu writes:
 I'll try that tomorrow.  But, I now know that this is related to using
 hal from ports.  If I comment out both enable_dbus and enable_hal in
 /etc/rc.conf, the system works as I would expect (ie., usb now works
 for unplugging devices!).  I further suspect that the problems lies in
 hal_probe_storage, but haven't got too much further.
 HAL: the gift that keeps on giving.  It also has this wonderful feature
 where it prevents you from unmounting anything you've ever mounted,
 because it watches for new mountpoints in the system, opens them, and
 keeps the file descriptors open indefinitely.

 I know this isn't really germane, but I just couldn't pass up a chance
 to complain about HAL.
 
 Hold on.  It *is* germane: hal_probe_storage auto-mounted your USB stick
 and is holding on to it.  If this also happens with mice and keyboards
 etc., you're probably looking at two different issues.
 
 DES
 

I cursed at HAL a lot because it made uC inside r0ket to crap itself
partially... this thing can be USB device but apparently didn't like
black magic that HAL did. Maybe it tried to read from the beginning or
something. It took lot of time to figure out why it doesn't work. Now I
have set of ignore files to prevent grabbing for every single device in
system.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Sat, Nov 15, 2014 at 09:44:18PM -0800, Adrian Chadd wrote:
 On 15 November 2014 21:41, Steve Kargl s...@troutmask.apl.washington.edu 
 wrote:
  On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote:
  On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote:
   On 11/13/14 19:15, Steve Kargl wrote:
On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote:
On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote:
On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
I have a kernel/world from r274273 sources, which is exhibiting a 
new
issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r 
now'
work.  I get to the end of shutdown and see for example
   
All buffers synced
Uptime: 4h23m15s
   
and then the laptop just sits there.  It does not power off with
the -p option nor does it reboot with the -r.  Has anyone else
seen this behavior?
   
   
The problem appears to be related to a recent change in the
USB stack.  If I have the following drive plugged into a
usb port, the above behavior is observed on shutdown.
   
   
Adding
   
hw.usb.no_shutdown_wait: 1
   
to /boot/loader.conf appears to work around the 'shutdown -p now'
and 'shutdown -r now' issue.  Unfortunately, the bricking of the
laptop is not affected by this sysctl.  Once a device is plugged
into a usb, it must remain plugged in.
   
  
   Hi,
  
   Is using this sysctl/tunable a suitable solution for you?
  
 
  The sysctl is a suitable solution for the shutdown issues.
  It is not suitable solution for the general use of using
  a memory stick to for example quickly transfer files.  Once
  the memory stick is plugged into the usb port, it must
  remain there unless one wants to reboot the system.
 
  I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled.
  I need to wade through a rather large /var/log/messages
  to see if anything appears unusual.
 
 
  Well, this has been a waste of a day.  The problem is caused
  by r273872.  This is the recent random device patch.  I have no
  idea why removing a usb device would cause the system to lock
  up other than random is probably trying to harvest some entropy.
 
 + des / markm
 
 That's a good catch! It's not a waste of a day. Thankyou for digging
 into it and finding out what introduced the failure.
 
 Hopefully between Hans, des and markm a solution can be found.
 

Shooting into the dark.  I added 'options RANDOM_DEBUG' to my
kernel.  Plugging in a USB device shows

kernel: ugen6.2: USBest Technology at usbus6
kernel: umass0: USBest Technology USB Mass Storage Device, class 0/0, rev 
2.00/1.00, addr 2 on usbus6
kernel: random: device_attach(): feeding 4 bit(s) of entropy from umass0
kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
kernel: da0:   0.00 Removable Direct Access SCSI-2 device 
kernel: da0: Serial Number 08102201c42413
kernel: da0: 40.000MB/s transfers
kernel: da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C)
kernel: da0: quirks=0x2NO_6_BYTE

in /var/log/messages.  Now, when I immediately pull the device from
the USB port, I get

kernel: ugen6.2: USBest Technology at usbus6 (disconnected)
kernel: umass0: at uhub6, port 1, addr 2 (disconnected)
kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
kernel: da0:   0.00 s/n 08102201c42413 detached

followed by a bricked laptop, which requires a depression of the
power button.

Is there a 'random: device_detach():' missing between the 'umass0'
and 'da0' messages in the last 4 lines.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Mark R V Murray]

 On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu 
 wrote:
 
 Is there a 'random: device_detach():' missing between the 'umass0'
 and 'da0' messages in the last 4 lines.

No. At attach time, the RNG grabs some probe entropy. At detach time it does 
nothing.

M
-- 
Mark R V Murray

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Ian Lepore]

On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote:
  On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu 
  wrote:
  
  Is there a 'random: device_detach():' missing between the 'umass0'
  and 'da0' messages in the last 4 lines.
 
 No. At attach time, the RNG grabs some probe entropy. At detach time it does 
 nothing.
 
 M

And yet... Steve has gathered evidence that the system bricks when a
device is detached with the new entropy-gathering code and doesn't do so
prior to that code.  What else is the new code doing around detach time?

-- Ian


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Mark R V Murray]

 On 16 Nov 2014, at 18:21, Ian Lepore i...@freebsd.org wrote:
 
 On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote:
 On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu 
 wrote:
 
 Is there a 'random: device_detach():' missing between the 'umass0'
 and 'da0' messages in the last 4 lines.
 
 No. At attach time, the RNG grabs some probe entropy. At detach time it does 
 nothing.
 
 M
 
 And yet... Steve has gathered evidence that the system bricks when a
 device is detached with the new entropy-gathering code and doesn't do so
 prior to that code.  What else is the new code doing around detach time?

Nothing, except possibly harvesting interrupt entropy. I’ll promise to be
astonished if this is other-than-harmless.

I’d be more suspicious of the harvester thread, but I still can’t see how
its hurting :-(

M
-- 
Mark R V Murray

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Ian Lepore]

On Sun, 2014-11-16 at 18:23 +, Mark R V Murray wrote:
  On 16 Nov 2014, at 18:21, Ian Lepore i...@freebsd.org wrote:
  
  On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote:
  On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu 
  wrote:
  
  Is there a 'random: device_detach():' missing between the 'umass0'
  and 'da0' messages in the last 4 lines.
  
  No. At attach time, the RNG grabs some probe entropy. At detach time it 
  does nothing.
  
  M
  
  And yet... Steve has gathered evidence that the system bricks when a
  device is detached with the new entropy-gathering code and doesn't do so
  prior to that code.  What else is the new code doing around detach time?
 
 Nothing, except possibly harvesting interrupt entropy. I’ll promise to be
 astonished if this is other-than-harmless.
 
 I’d be more suspicious of the harvester thread, but I still can’t see how
 its hurting :-(
 
 M

The point I'm trying to make here is that you trimmed away the important
part of the prior messages and replied only to the part where Steve's
debugging efforts were somewhat speculating.  The non-speculative part
was where he bisected the failure to an exact commit:

   The problem is caused
   by r273872.  This is the recent random device patch.  I have no
   idea why removing a usb device would cause the system to lock
   up other than random is probably trying to harvest some entropy.

-- Ian


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Mark R V Murray]

 On 16 Nov 2014, at 18:31, Ian Lepore i...@freebsd.org wrote:
 
 The point I'm trying to make here is that you trimmed away the important
 part of the prior messages and replied only to the part where Steve's
 debugging efforts were somewhat speculating.  The non-speculative part
 was where he bisected the failure to an exact commit:
 
 The problem is caused
 by r273872.  This is the recent random device patch.  I have no
 idea why removing a usb device would cause the system to lock
 up other than random is probably trying to harvest some entropy.

I’m sorry my commit caused the problem.

I’m also trying to find out why, but I don’t know enough about USB or
mass-storage devices to know why, so this may take me a while. In the
meanwhile, I’ll try to help by pointing out things I do know.

M
-- 
Mark R V Murray

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Sun, Nov 16, 2014 at 06:34:42PM +, Mark R V Murray wrote:
 
  On 16 Nov 2014, at 18:31, Ian Lepore i...@freebsd.org wrote:
  
  The point I'm trying to make here is that you trimmed away the important
  part of the prior messages and replied only to the part where Steve's
  debugging efforts were somewhat speculating.  The non-speculative part
  was where he bisected the failure to an exact commit:
  
  The problem is caused
  by r273872.  This is the recent random device patch.  I have no
  idea why removing a usb device would cause the system to lock
  up other than random is probably trying to harvest some entropy.
 
 I?m sorry my commit caused the problem.
 

Nothing to be sorry about.  This is -current afterall.

 I?m also trying to find out why, but I don?t know enough about USB or
 mass-storage devices to know why, so this may take me a while. In the
 meanwhile, I?ll try to help by pointing out things I do know.

Yes, I did the bisection to find that r273872 exposes the problem.
What I don't know is if this is hardware specific to a Dell Latitude
D530 laptop, USB specific, or some weird interaction between the
random and USB.

What I also find odd is that I seem to be the only person seeing
this behavior when it is trivial for me to reproduce: boot laptop,
plug in usb device, wait usb recognizes the device, then unplug 
the device.

If you have not read the entire thread, once the laptop keyboard and
video output lock up, I can ssh into the laptop.  If I run usbconfig,
it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices
have not been destroyed. 

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Mark R V Murray]

 On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu 
 wrote:
 
 
 I?m sorry my commit caused the problem.
 
 
 Nothing to be sorry about.  This is -current after all.

Thanks :-)

 I?m also trying to find out why, but I don?t know enough about USB or
 mass-storage devices to know why, so this may take me a while. In the
 meanwhile, I?ll try to help by pointing out things I do know.
 
 Yes, I did the bisection to find that r273872 exposes the problem.
 What I don't know is if this is hardware specific to a Dell Latitude
 D530 laptop, USB specific, or some weird interaction between the
 random and USB.
 
 What I also find odd is that I seem to be the only person seeing
 this behavior when it is trivial for me to reproduce: boot laptop,
 plug in usb device, wait usb recognizes the device, then unplug 
 the device.

Strange for me too. I’m not exactly being bombarded with bug reports.

 If you have not read the entire thread, once the laptop keyboard and
 video output lock up, I can ssh into the laptop.  If I run usbconfig,
 it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices
 have not been destroyed.

Weirder and weirder :-(.

Something with SX locks? Hmm. I do use those for attach and detach for
RNG sources. Could it be that that stick of yours is somehow getting
involved in the RNG source locks?

M
-- 
Mark R V Murray

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote:
 
  On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu 
  wrote:
  
  If you have not read the entire thread, once the laptop keyboard and
  video output lock up, I can ssh into the laptop.  If I run usbconfig,
  it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices
  have not been destroyed.
 
 Weirder and weirder :-(.
 
 Something with SX locks? Hmm. I do use those for attach and detach for
 RNG sources. Could it be that that stick of yours is somehow getting
 involved in the RNG source locks?
 

It's not limited to a single usb device.  Plugging in/Unplugging
a logitech mouse dongle, the memstick, a Western Digital MY Passport
external usb hard drive, all lead to the locked keyboard and video.

I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the
mount of output is mind numbing.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Hans Petter Selasky]

On 11/16/14 20:03, Steve Kargl wrote:

On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote:



On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu wrote:

If you have not read the entire thread, once the laptop keyboard and
video output lock up, I can ssh into the laptop.  If I run usbconfig,
it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices
have not been destroyed.


Weirder and weirder :-(.

Something with SX locks? Hmm. I do use those for attach and detach for
RNG sources. Could it be that that stick of yours is somehow getting
involved in the RNG source locks?



It's not limited to a single usb device.  Plugging in/Unplugging
a logitech mouse dongle, the memstick, a Western Digital MY Passport
external usb hard drive, all lead to the locked keyboard and video.

I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the
mount of output is mind numbing.



Hi,

Can you enter kgdb when the usbconfig is froozen, and backtrace all 
kernel threads. You should see exactly what locks are the problem.


Maybe some lock didn't get properly unlocked!

Thank you!

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote:
 On 11/16/14 20:03, Steve Kargl wrote:
  On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote:
 
  On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu 
  wrote:
 
  If you have not read the entire thread, once the laptop keyboard and
  video output lock up, I can ssh into the laptop.  If I run usbconfig,
  it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices
  have not been destroyed.
 
  Weirder and weirder :-(.
 
  Something with SX locks? Hmm. I do use those for attach and detach for
  RNG sources. Could it be that that stick of yours is somehow getting
  involved in the RNG source locks?
 
 
  It's not limited to a single usb device.  Plugging in/Unplugging
  a logitech mouse dongle, the memstick, a Western Digital MY Passport
  external usb hard drive, all lead to the locked keyboard and video.
 
  I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the
  mount of output is mind numbing.
 
 
 
 Can you enter kgdb when the usbconfig is froozen, and backtrace all 
 kernel threads. You should see exactly what locks are the problem.
 
 Maybe some lock didn't get properly unlocked!
 

I haven't tried kgdb.  I did try to attach gdb to the usbconfig
process via its pid, but gdb dumped core.

I haven't looked at locks in kgdb, what command or commands should
I try.
 
-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Hans Petter Selasky]

On 11/16/14 20:29, Steve Kargl wrote:

On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote:

On 11/16/14 20:03, Steve Kargl wrote:

On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote:



On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu wrote:

If you have not read the entire thread, once the laptop keyboard and
video output lock up, I can ssh into the laptop.  If I run usbconfig,
it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices
have not been destroyed.


Weirder and weirder :-(.

Something with SX locks? Hmm. I do use those for attach and detach for
RNG sources. Could it be that that stick of yours is somehow getting
involved in the RNG source locks?



It's not limited to a single usb device.  Plugging in/Unplugging
a logitech mouse dongle, the memstick, a Western Digital MY Passport
external usb hard drive, all lead to the locked keyboard and video.

I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the
mount of output is mind numbing.




Can you enter kgdb when the usbconfig is froozen, and backtrace all
kernel threads. You should see exactly what locks are the problem.

Maybe some lock didn't get properly unlocked!



I haven't tried kgdb.  I did try to attach gdb to the usbconfig
process via its pid, but gdb dumped core.

I haven't looked at locks in kgdb, what command or commands should
I try.




Hi,

You enter:

thread apply all bt

That will give you the backtrace of all threads. Grep for usbconfig, and 
figure out which line is causing the problem in the kernel. Then look at 
the USB explore threads and see where they are stuck in the detach of umass!


--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Adrian Chadd]

 ... or since you can ssh into the thing, try as root:

procstat -ka



-adrian


On 16 November 2014 11:33, Hans Petter Selasky h...@selasky.org wrote:
 On 11/16/14 20:29, Steve Kargl wrote:

 On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote:

 On 11/16/14 20:03, Steve Kargl wrote:

 On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote:


 On 16 Nov 2014, at 18:51, Steve Kargl
 s...@troutmask.apl.washington.edu wrote:

 If you have not read the entire thread, once the laptop keyboard and
 video output lock up, I can ssh into the laptop.  If I run usbconfig,
 it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0*
 devices
 have not been destroyed.


 Weirder and weirder :-(.

 Something with SX locks? Hmm. I do use those for attach and detach for
 RNG sources. Could it be that that stick of yours is somehow getting
 involved in the RNG source locks?


 It's not limited to a single usb device.  Plugging in/Unplugging
 a logitech mouse dongle, the memstick, a Western Digital MY Passport
 external usb hard drive, all lead to the locked keyboard and video.

 I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the
 mount of output is mind numbing.



 Can you enter kgdb when the usbconfig is froozen, and backtrace all
 kernel threads. You should see exactly what locks are the problem.

 Maybe some lock didn't get properly unlocked!


 I haven't tried kgdb.  I did try to attach gdb to the usbconfig
 process via its pid, but gdb dumped core.

 I haven't looked at locks in kgdb, what command or commands should
 I try.



 Hi,

 You enter:

 thread apply all bt

 That will give you the backtrace of all threads. Grep for usbconfig, and
 figure out which line is causing the problem in the kernel. Then look at the
 USB explore threads and see where they are stuck in the detach of umass!

 --HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Sun, Nov 16, 2014 at 04:34:38PM -0800, Adrian Chadd wrote:
  ... or since you can ssh into the thing, try as root:
 
 procstat -ka
 

I'll try that tomorrow.  But, I now know that this is
related to using hal from ports.  If I comment out both
enable_dbus and enable_hal in /etc/rc.conf, the system
works as I would expect (ie., usb now works for unplugging
devices!).  I further suspect that the problems lies
in hal_probe_storage, but haven't got too much further.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Sun, Nov 16, 2014 at 08:33:15PM +0100, Hans Petter Selasky wrote:
 
 thread apply all bt
 
 That will give you the backtrace of all threads. Grep for usbconfig, and 
 figure out which line is causing the problem in the kernel. Then look at 
 the USB explore threads and see where they are stuck in the detach of umass!
 

I haven't tried the kgdb approach, yet.  I can say that the
problem is coming from sg device.  If I have 'device sg' in
my config file, the problems occur.  Removing 'device sg'
gives a working kernel.

If I do not start hald in /etc/rc.conf, everything works as 
expected.  Now, if hald was started at boot and I then stop
hald with '/usr/local/etc/rc.d/hald stop' then the one hald
relate process is not stopped. I've wrapped lines to keep this
short.

% ps axl | grep hald
 UID  PID PPID CPU PRI NI   VSZ   RSS MWCHAN   STAT TT  TIME  COMMAND
  0  10581 195  20  0 13180  3512  -  I  -  0:00.05
  hald-probe-storage: /dev/sg1 (hald-probe-storage)

Using the procstat as suggested by Adrian, I have

% procstat -ka 
1058 100157 hald-probe-storage hald-probe-stora mi_switch sleepq_switch
 sleepq_catch_signals sleepq_wait_sig _sleep sgread giant_read
 devfs_read_f dofileread kern_readv sys_read syscall Xint0x80_syscall 

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Dag-Erling Smørgrav]

Steve Kargl s...@troutmask.apl.washington.edu writes:
 I'll try that tomorrow.  But, I now know that this is related to using
 hal from ports.  If I comment out both enable_dbus and enable_hal in
 /etc/rc.conf, the system works as I would expect (ie., usb now works
 for unplugging devices!).  I further suspect that the problems lies in
 hal_probe_storage, but haven't got too much further.

HAL: the gift that keeps on giving.  It also has this wonderful feature
where it prevents you from unmounting anything you've ever mounted,
because it watches for new mountpoints in the system, opens them, and
keeps the file descriptors open indefinitely.

I know this isn't really germane, but I just couldn't pass up a chance
to complain about HAL.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Dag-Erling Smørgrav]

Dag-Erling Smørgrav d...@des.no writes:
 Steve Kargl s...@troutmask.apl.washington.edu writes:
  I'll try that tomorrow.  But, I now know that this is related to using
  hal from ports.  If I comment out both enable_dbus and enable_hal in
  /etc/rc.conf, the system works as I would expect (ie., usb now works
  for unplugging devices!).  I further suspect that the problems lies in
  hal_probe_storage, but haven't got too much further.
 HAL: the gift that keeps on giving.  It also has this wonderful feature
 where it prevents you from unmounting anything you've ever mounted,
 because it watches for new mountpoints in the system, opens them, and
 keeps the file descriptors open indefinitely.

 I know this isn't really germane, but I just couldn't pass up a chance
 to complain about HAL.

Hold on.  It *is* germane: hal_probe_storage auto-mounted your USB stick
and is holding on to it.  If this also happens with mice and keyboards
etc., you're probably looking at two different issues.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote:
 On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote:
  On 11/13/14 19:15, Steve Kargl wrote:
   On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote:
   On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote:
   On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
   I have a kernel/world from r274273 sources, which is exhibiting a new
   issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r 
   now'
   work.  I get to the end of shutdown and see for example
  
   All buffers synced
   Uptime: 4h23m15s
  
   and then the laptop just sits there.  It does not power off with
   the -p option nor does it reboot with the -r.  Has anyone else
   seen this behavior?
  
  
   The problem appears to be related to a recent change in the
   USB stack.  If I have the following drive plugged into a
   usb port, the above behavior is observed on shutdown.
  
  
   Adding
  
   hw.usb.no_shutdown_wait: 1
  
   to /boot/loader.conf appears to work around the 'shutdown -p now'
   and 'shutdown -r now' issue.  Unfortunately, the bricking of the
   laptop is not affected by this sysctl.  Once a device is plugged
   into a usb, it must remain plugged in.
  
  
  Hi,
  
  Is using this sysctl/tunable a suitable solution for you?
  
 
 The sysctl is a suitable solution for the shutdown issues.
 It is not suitable solution for the general use of using
 a memory stick to for example quickly transfer files.  Once
 the memory stick is plugged into the usb port, it must
 remain there unless one wants to reboot the system.
 
 I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled.
 I need to wade through a rather large /var/log/messages
 to see if anything appears unusual.
 

Well, this has been a waste of a day.  The problem is caused
by r273872.  This is the recent random device patch.  I have no
idea why removing a usb device would cause the system to lock
up other than random is probably trying to harvest some entropy.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Adrian Chadd]

On 15 November 2014 21:41, Steve Kargl s...@troutmask.apl.washington.edu 
wrote:
 On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote:
 On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote:
  On 11/13/14 19:15, Steve Kargl wrote:
   On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote:
   On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote:
   On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
   I have a kernel/world from r274273 sources, which is exhibiting a new
   issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r 
   now'
   work.  I get to the end of shutdown and see for example
  
   All buffers synced
   Uptime: 4h23m15s
  
   and then the laptop just sits there.  It does not power off with
   the -p option nor does it reboot with the -r.  Has anyone else
   seen this behavior?
  
  
   The problem appears to be related to a recent change in the
   USB stack.  If I have the following drive plugged into a
   usb port, the above behavior is observed on shutdown.
  
  
   Adding
  
   hw.usb.no_shutdown_wait: 1
  
   to /boot/loader.conf appears to work around the 'shutdown -p now'
   and 'shutdown -r now' issue.  Unfortunately, the bricking of the
   laptop is not affected by this sysctl.  Once a device is plugged
   into a usb, it must remain plugged in.
  
 
  Hi,
 
  Is using this sysctl/tunable a suitable solution for you?
 

 The sysctl is a suitable solution for the shutdown issues.
 It is not suitable solution for the general use of using
 a memory stick to for example quickly transfer files.  Once
 the memory stick is plugged into the usb port, it must
 remain there unless one wants to reboot the system.

 I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled.
 I need to wade through a rather large /var/log/messages
 to see if anything appears unusual.


 Well, this has been a waste of a day.  The problem is caused
 by r273872.  This is the recent random device patch.  I have no
 idea why removing a usb device would cause the system to lock
 up other than random is probably trying to harvest some entropy.

+ des / markm

That's a good catch! It's not a waste of a day. Thankyou for digging
into it and finding out what introduced the failure.

Hopefully between Hans, des and markm a solution can be found.



-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Sat, Nov 15, 2014 at 09:44:18PM -0800, Adrian Chadd wrote:
 On 15 November 2014 21:41, Steve Kargl s...@troutmask.apl.washington.edu 
 wrote:
  On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote:
  On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote:
   On 11/13/14 19:15, Steve Kargl wrote:
On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote:
On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote:
On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
I have a kernel/world from r274273 sources, which is exhibiting a 
new
issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r 
now'
work.  I get to the end of shutdown and see for example
   
All buffers synced
Uptime: 4h23m15s
   
and then the laptop just sits there.  It does not power off with
the -p option nor does it reboot with the -r.  Has anyone else
seen this behavior?
   
   
The problem appears to be related to a recent change in the
USB stack.  If I have the following drive plugged into a
usb port, the above behavior is observed on shutdown.
   
   
Adding
   
hw.usb.no_shutdown_wait: 1
   
to /boot/loader.conf appears to work around the 'shutdown -p now'
and 'shutdown -r now' issue.  Unfortunately, the bricking of the
laptop is not affected by this sysctl.  Once a device is plugged
into a usb, it must remain plugged in.
   
  
   Hi,
  
   Is using this sysctl/tunable a suitable solution for you?
  
 
  The sysctl is a suitable solution for the shutdown issues.
  It is not suitable solution for the general use of using
  a memory stick to for example quickly transfer files.  Once
  the memory stick is plugged into the usb port, it must
  remain there unless one wants to reboot the system.
 
  I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled.
  I need to wade through a rather large /var/log/messages
  to see if anything appears unusual.
 
 
  Well, this has been a waste of a day.  The problem is caused
  by r273872.  This is the recent random device patch.  I have no
  idea why removing a usb device would cause the system to lock
  up other than random is probably trying to harvest some entropy.
 
 + des / markm
 
 That's a good catch! It's not a waste of a day. Thankyou for digging
 into it and finding out what introduced the failure.
 
 Hopefully between Hans, des and markm a solution can be found.
 

It is a waste in that I was going to spend the day working on powl().
My next window of time for powl() hacking is probably sometime in
mid to late December.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
 I have a kernel/world from r274273 sources, which is exhibiting a new
 issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
 work.  I get to the end of shutdown and see for example
 
 All buffers synced
 Uptime: 4h23m15s
 
 and then the laptop just sits there.  It does not power off with
 the -p option nor does it reboot with the -r.  Has anyone else
 seen this behavior?
 

The problem appears to be related to a recent change in the
USB stack.  If I have the following drive plugged into a
usb port, the above behavior is observed on shutdown.

ugen6.2: Western Digital at usbus6
umass0: MSC Bulk-Only Transport on usbus6
da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
da0: WD My Passport 0748 1019 Fixed Direct Access SCSI-6 device 
da0: Serial Number 57584B314537324445595A31
da0: 40.000MB/s transfers
da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C)
da0: quirks=0x2NO_6_BYTE
ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1
ses1: WD SES Device 1019 Fixed Enclosure Services SCSI-6 device 
ses1: Serial Number 57584B314537324445595A31
ses1: 40.000MB/s transfers
ses1: SCSI-3 ENC Device

If this drive was never plugged into a usb port, 'shutdown -r now'
and 'shutdown -p now' work as expected.

If drive is plugged into a usb port, and I then unplug the drive the
laptop is turned into a brick.  In a vt(4) console, there is no keyboard 
and no output is displayed to the console.

Logging into the laptop with ssh works.  With the laptop
in a brick state, issuing 'usbconfig' yields a wedged process
with no output to the terminal and 'usbconfig' is unkillable. 
^T yields

load: 0.30  cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s 1884k.

Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :(

Logging into the laptop again with ssh works.  Issuing the command
'camcontrol rescan all' yields

Re-scan of bus 4 returned error 0xa
Re-scan of bus 0 was successful
Re-scan of bus 1 was successful
Re-scan of bus 2 was successful
Re-scan of bus 3 was successful

dmesg follows my sig.

-- 
Steve

Copyright (c) 1992-2014 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #0 r274456: Thu Nov 13 07:45:01 PST 2014
ka...@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
VT: running with driver vga.
CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.04-MHz 686-class CPU)
  Origin=GenuineIntel  Id=0x6fd  Family=0x6  Model=0xf  Stepping=13
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x2000LM
  AMD Features2=0x1LAHF
  VT-x: (disabled in BIOS) HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 3221225472 (3072 MB)
avail memory = 3136098304 (2990 MB)
Event timer LAPIC quality 400
ACPI APIC Table: DELL   M08
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 2
ioapic0 Version 2.0 irqs 0-23 on motherboard
random: entropy device infrastructure driver
random: selecting highest priority adaptor Dummy
kbd1 at kbdmux0
random: SOFT: yarrow init()
random: selecting highest priority adaptor Yarrow
module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19
acpi0: DELL M08 on motherboard
hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0
Timecounter HPET frequency 14318180 Hz quality 950
Event timer HPET frequency 14318180 Hz quality 450
Event timer HPET1 frequency 14318180 Hz quality 440
Event timer HPET2 frequency 14318180 Hz quality 440
acpi0: reservation of 0, 9f000 (3) failed
acpi0: reservation of 10, bf5c0400 (3) failed
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0
Event timer RTC frequency 32768 Hz quality 0
attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 2 on acpi0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
vgapci0: VGA-compatible display port 0xeff8-0xefff mem 
0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0
vgapci0: Boot video device
vgapci1: VGA-compatible display mem 0xfeb0-0xfebf at device 2.1 on 
pci0
uhci0: Intel 82801H (ICH8) USB controller USB-D port 0x6f20-0x6f3f irq 20 at 
device 26.0 on pci0
usbus0 on uhci0
uhci1

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Garrett Cooper]

CCing hps and mav..

 On Nov 13, 2014, at 09:25, Steve Kargl s...@troutmask.apl.washington.edu 
 wrote:
 
 On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
 I have a kernel/world from r274273 sources, which is exhibiting a new
 issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
 work.  I get to the end of shutdown and see for example
 
 All buffers synced
 Uptime: 4h23m15s
 
 and then the laptop just sits there.  It does not power off with
 the -p option nor does it reboot with the -r.  Has anyone else
 seen this behavior?
 
 The problem appears to be related to a recent change in the
 USB stack.  If I have the following drive plugged into a
 usb port, the above behavior is observed on shutdown.
 
 ugen6.2: Western Digital at usbus6
 umass0: MSC Bulk-Only Transport on usbus6
 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
 da0: WD My Passport 0748 1019 Fixed Direct Access SCSI-6 device 
 da0: Serial Number 57584B314537324445595A31
 da0: 40.000MB/s transfers
 da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C)
 da0: quirks=0x2NO_6_BYTE
 ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1
 ses1: WD SES Device 1019 Fixed Enclosure Services SCSI-6 device 
 ses1: Serial Number 57584B314537324445595A31
 ses1: 40.000MB/s transfers
 ses1: SCSI-3 ENC Device
 
 If this drive was never plugged into a usb port, 'shutdown -r now'
 and 'shutdown -p now' work as expected.
 
 If drive is plugged into a usb port, and I then unplug the drive the
 laptop is turned into a brick.  In a vt(4) console, there is no keyboard 
 and no output is displayed to the console.
 
 Logging into the laptop with ssh works.  With the laptop
 in a brick state, issuing 'usbconfig' yields a wedged process
 with no output to the terminal and 'usbconfig' is unkillable. 
 ^T yields
 
 load: 0.30  cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s 
 1884k.
 
 Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :(
 
 Logging into the laptop again with ssh works.  Issuing the command
 'camcontrol rescan all' yields
 
 Re-scan of bus 4 returned error 0xa
 Re-scan of bus 0 was successful
 Re-scan of bus 1 was successful
 Re-scan of bus 2 was successful
 Re-scan of bus 3 was successful
 
 dmesg follows my sig.
 
 -- 
 Steve
 
 Copyright (c) 1992-2014 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 11.0-CURRENT #0 r274456: Thu Nov 13 07:45:01 PST 2014
ka...@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386
 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
 VT: running with driver vga.
 CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.04-MHz 686-class 
 CPU)
  Origin=GenuineIntel  Id=0x6fd  Family=0x6  Model=0xf  Stepping=13
  
 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
  AMD Features=0x2000LM
  AMD Features2=0x1LAHF
  VT-x: (disabled in BIOS) HLT,PAUSE
  TSC: P-state invariant, performance statistics
 real memory  = 3221225472 (3072 MB)
 avail memory = 3136098304 (2990 MB)
 Event timer LAPIC quality 400
 ACPI APIC Table: DELL   M08
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 ioapic0: Changing APIC ID to 2
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 random: entropy device infrastructure driver
 random: selecting highest priority adaptor Dummy
 kbd1 at kbdmux0
 random: SOFT: yarrow init()
 random: selecting highest priority adaptor Yarrow
 module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19
 acpi0: DELL M08 on motherboard
 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0
 Timecounter HPET frequency 14318180 Hz quality 950
 Event timer HPET frequency 14318180 Hz quality 450
 Event timer HPET1 frequency 14318180 Hz quality 440
 Event timer HPET2 frequency 14318180 Hz quality 440
 acpi0: reservation of 0, 9f000 (3) failed
 acpi0: reservation of 10, bf5c0400 (3) failed
 cpu0: ACPI CPU on acpi0
 cpu1: ACPI CPU on acpi0
 atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0
 Event timer RTC frequency 32768 Hz quality 0
 attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 2 on acpi0
 Timecounter i8254 frequency 1193182 Hz quality 0
 Event timer i8254 frequency 1193182 Hz quality 100
 Timecounter ACPI-fast frequency 3579545 Hz quality 900
 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 vgapci0: VGA-compatible display port 0xeff8-0xefff mem 
 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0
 vgapci0: Boot video device

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote:
 On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
  I have a kernel/world from r274273 sources, which is exhibiting a new
  issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
  work.  I get to the end of shutdown and see for example
  
  All buffers synced
  Uptime: 4h23m15s
  
  and then the laptop just sits there.  It does not power off with
  the -p option nor does it reboot with the -r.  Has anyone else
  seen this behavior?
  
 
 The problem appears to be related to a recent change in the
 USB stack.  If I have the following drive plugged into a
 usb port, the above behavior is observed on shutdown.
 
 ugen6.2: Western Digital at usbus6
 umass0: MSC Bulk-Only Transport on usbus6
 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
 da0: WD My Passport 0748 1019 Fixed Direct Access SCSI-6 device 
 da0: Serial Number 57584B314537324445595A31
 da0: 40.000MB/s transfers
 da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C)
 da0: quirks=0x2NO_6_BYTE
 ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1
 ses1: WD SES Device 1019 Fixed Enclosure Services SCSI-6 device 
 ses1: Serial Number 57584B314537324445595A31
 ses1: 40.000MB/s transfers
 ses1: SCSI-3 ENC Device
 

The problem is not restricted to hte WD My Passport drive.  The
memstick

ugen6.2: USBest Technology at usbus6
umass0: USBest Technology USB Mass Storage Device, class 0/0, rev 2.00/1.00, 
addr 2 on usbus6
da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
da0:   0.00 Removable Direct Access SCSI-2 device 
da0: Serial Number 08102201c42413
da0: 40.000MB/s transfers
da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C)
da0: quirks=0x2NO_6_BYTE

will also cause the system to wedge when removed.  I failed to report
that /dev/da0, /dev/da0s1, /dev/da0s1a, etc were not destroyed when
the WD My Passport was removed.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote:
 On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote:
  On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
   I have a kernel/world from r274273 sources, which is exhibiting a new
   issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
   work.  I get to the end of shutdown and see for example
   
   All buffers synced
   Uptime: 4h23m15s
   
   and then the laptop just sits there.  It does not power off with
   the -p option nor does it reboot with the -r.  Has anyone else
   seen this behavior?
   
  
  The problem appears to be related to a recent change in the
  USB stack.  If I have the following drive plugged into a
  usb port, the above behavior is observed on shutdown.
  

Adding

hw.usb.no_shutdown_wait: 1

to /boot/loader.conf appears to work around the 'shutdown -p now'
and 'shutdown -r now' issue.  Unfortunately, the bricking of the
laptop is not affected by this sysctl.  Once a device is plugged
into a usb, it must remain plugged in.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Hans Petter Selasky]

On 11/13/14 19:15, Steve Kargl wrote:

On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote:

On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote:

On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:

I have a kernel/world from r274273 sources, which is exhibiting a new
issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
work.  I get to the end of shutdown and see for example

All buffers synced
Uptime: 4h23m15s

and then the laptop just sits there.  It does not power off with
the -p option nor does it reboot with the -r.  Has anyone else
seen this behavior?



The problem appears to be related to a recent change in the
USB stack.  If I have the following drive plugged into a
usb port, the above behavior is observed on shutdown.



Adding

hw.usb.no_shutdown_wait: 1

to /boot/loader.conf appears to work around the 'shutdown -p now'
and 'shutdown -r now' issue.  Unfortunately, the bricking of the
laptop is not affected by this sysctl.  Once a device is plugged
into a usb, it must remain plugged in.



Hi,

Is using this sysctl/tunable a suitable solution for you?

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: USB locks up system -- WAS Re: shutdown or acpi problem

[Steve Kargl]

On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote:
 On 11/13/14 19:15, Steve Kargl wrote:
  On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote:
  On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote:
  On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
  I have a kernel/world from r274273 sources, which is exhibiting a new
  issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
  work.  I get to the end of shutdown and see for example
 
  All buffers synced
  Uptime: 4h23m15s
 
  and then the laptop just sits there.  It does not power off with
  the -p option nor does it reboot with the -r.  Has anyone else
  seen this behavior?
 
 
  The problem appears to be related to a recent change in the
  USB stack.  If I have the following drive plugged into a
  usb port, the above behavior is observed on shutdown.
 
 
  Adding
 
  hw.usb.no_shutdown_wait: 1
 
  to /boot/loader.conf appears to work around the 'shutdown -p now'
  and 'shutdown -r now' issue.  Unfortunately, the bricking of the
  laptop is not affected by this sysctl.  Once a device is plugged
  into a usb, it must remain plugged in.
 
 
 Hi,
 
 Is using this sysctl/tunable a suitable solution for you?
 

The sysctl is a suitable solution for the shutdown issues.
It is not suitable solution for the general use of using
a memory stick to for example quickly transfer files.  Once
the memory stick is plugged into the usb port, it must
remain there unless one wants to reboot the system.

I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled.
I need to wade through a rather large /var/log/messages
to see if anything appears unusual.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

shutdown or acpi problem

[Steve Kargl]

I have a kernel/world from r274273 sources, which is exhibiting a new
issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
work.  I get to the end of shutdown and see for example

All buffers synced
Uptime: 4h23m15s

and then the laptop just sits there.  It does not power off with
the -p option nor does it reboot with the -r.  Has anyone else
seen this behavior?

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shutdown or acpi problem

[NGie Cooper]

On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
 I have a kernel/world from r274273 sources, which is exhibiting a new
 issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
 work.  I get to the end of shutdown and see for example

 All buffers synced
 Uptime: 4h23m15s

 and then the laptop just sits there.  It does not power off with
 the -p option nor does it reboot with the -r.  Has anyone else
 seen this behavior?

Are you upgrading from a pre-r273872 world, and if so, did you run
make delete-old first (
http://svnweb.freebsd.org/base?view=revisionrevision= )?
Cheers!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shutdown or acpi problem

[Steve Kargl]

On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote:
 I have a kernel/world from r274273 sources, which is exhibiting a new
 issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
 work.  I get to the end of shutdown and see for example
 
 All buffers synced
 Uptime: 4h23m15s
 
 and then the laptop just sits there.  It does not power off with
 the -p option nor does it reboot with the -r.  Has anyone else
 seen this behavior?
 

Note booting /boot/kernel.old/kernel and then using 'shutdown -p now'
works as expected.  The old kernel was bulit from r271492 sources.
Any guidance on where to start to debug this issue would be welcomed.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shutdown or acpi problem

[Steve Kargl]

On Wed, Nov 12, 2014 at 03:12:46PM -0800, NGie Cooper wrote:
 On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl
 s...@troutmask.apl.washington.edu wrote:
  I have a kernel/world from r274273 sources, which is exhibiting a new
  issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
  work.  I get to the end of shutdown and see for example
 
  All buffers synced
  Uptime: 4h23m15s
 
  and then the laptop just sits there.  It does not power off with
  the -p option nor does it reboot with the -r.  Has anyone else
  seen this behavior?
 
 Are you upgrading from a pre-r273872 world, and if so, did you run
 make delete-old first (
 http://svnweb.freebsd.org/base?view=revisionrevision= )?
 Cheers!
 ___

I run 'make delete-old' and 'make delete-old-libs' after 
each installworld.  In this case, I was upgrading from
r271492 to r274273.  The procedure I use is 

cd /usr/obj
rm -rf *
cd /usr/src
svn update
make buildworld
make buildkernel
make installkernel
mergemaster -p
(may or may not boot to single user mode here)
make installworld
mergemaster -iU
make delete-old
make delete-old-libs
shutdown -r +1

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shutdown or acpi problem

[Chris H]

On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl
s...@troutmask.apl.washington.edu wrote

 On Wed, Nov 12, 2014 at 03:12:46PM -0800, NGie Cooper wrote:
  On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl
  s...@troutmask.apl.washington.edu wrote:
   I have a kernel/world from r274273 sources, which is exhibiting a new
   issue on my old laptop.  Neither 'shutdown -p now' nor 'shutdown -r now'
   work.  I get to the end of shutdown and see for example
  
   All buffers synced
   Uptime: 4h23m15s
  
   and then the laptop just sits there.  It does not power off with
   the -p option nor does it reboot with the -r.  Has anyone else
   seen this behavior?
  
  Are you upgrading from a pre-r273872 world, and if so, did you run
  make delete-old first (
  http://svnweb.freebsd.org/base?view=revisionrevision= )?
  Cheers!
  ___
 
 I run 'make delete-old' and 'make delete-old-libs' after 
 each installworld.  In this case, I was upgrading from
 r271492 to r274273.  The procedure I use is 
 
 cd /usr/obj
Can I throw a

chflags -R noschg *

here first? Point being, you may well not have gotten
everything, otherwise. :)

 rm -rf *
 cd /usr/src
 svn update
 make buildworld
 make buildkernel
 make installkernel
 mergemaster -p
 (may or may not boot to single user mode here)
 make installworld
 mergemaster -iU
 make delete-old
 make delete-old-libs
 shutdown -r +1
 
 -- 
 Steve

--Chris

 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shutdown or acpi problem

[Steve Kargl]

On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote:
 On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl
 s...@troutmask.apl.washington.edu wrote
 
  I run 'make delete-old' and 'make delete-old-libs' after 
  each installworld.  In this case, I was upgrading from
  r271492 to r274273.  The procedure I use is 
  
  cd /usr/obj
 Can I throw a
 
 chflags -R noschg *
 
 here first? Point being, you may well not have gotten
 everything, otherwise. :)

It's not needed.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shutdown or acpi problem

[Chris H]

On Wed, 12 Nov 2014 18:08:52 -0800 Steve Kargl
s...@troutmask.apl.washington.edu wrote

 On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote:
  On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl
  s...@troutmask.apl.washington.edu wrote
  
   I run 'make delete-old' and 'make delete-old-libs' after 
   each installworld.  In this case, I was upgrading from
   r271492 to r274273.  The procedure I use is 
   
   cd /usr/obj
  Can I throw a
  
  chflags -R noschg *
  
  here first? Point being, you may well not have gotten
  everything, otherwise. :)
 
 It's not needed.
How so? It's been necessary for as long
as I can remember. Just to confirm, I looked to see if anything
had changed:
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
seems not. Do note; I'm not trying to be argumentative. Just
don't see where it's not true (needed). :)

--Chris
 
 -- 
 Steve


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shutdown or acpi problem

[NGie Cooper]

On Wed, Nov 12, 2014 at 6:27 PM, Chris H bsd-li...@bsdforge.com wrote:

...

 How so? It's been necessary for as long
 as I can remember. Just to confirm, I looked to see if anything
 had changed:
 https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
 seems not. Do note; I'm not trying to be argumentative. Just
 don't see where it's not true (needed). :)

It's technically not needed with -DNO_CLEAN (it's handled in
Makefile.inc1), however if you're doing that you might as well not
specify NO_CLEAN:

http://svnweb.freebsd.org/base/head/Makefile.inc1?view=annotate#l481

Cheers!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shutdown or acpi problem

[NGie Cooper]

On Wed, Nov 12, 2014 at 6:43 PM, NGie Cooper yaneurab...@gmail.com wrote:
 On Wed, Nov 12, 2014 at 6:27 PM, Chris H bsd-li...@bsdforge.com wrote:

 ...

 How so? It's been necessary for as long
 as I can remember. Just to confirm, I looked to see if anything
 had changed:
 https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
 seems not. Do note; I'm not trying to be argumentative. Just
 don't see where it's not true (needed). :)

 It's technically not needed with -DNO_CLEAN (it's handled in
 Makefile.inc1), however if you're doing that you might as well not
 specify NO_CLEAN:

 http://svnweb.freebsd.org/base/head/Makefile.inc1?view=annotate#l481

My apologies... I was thinking of another build process. Yes, it's
very much required according to the process noted in the handbook.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: shutdown or acpi problem

[Steve Kargl]

On Wed, Nov 12, 2014 at 06:27:13PM -0800, Chris H wrote:
 On Wed, 12 Nov 2014 18:08:52 -0800 Steve Kargl
 s...@troutmask.apl.washington.edu wrote
 
  On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote:
   On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl
   s...@troutmask.apl.washington.edu wrote
   
I run 'make delete-old' and 'make delete-old-libs' after 
each installworld.  In this case, I was upgrading from
r271492 to r274273.  The procedure I use is 

cd /usr/obj
   Can I throw a
   
   chflags -R noschg *
   
   here first? Point being, you may well not have gotten
   everything, otherwise. :)
  
  It's not needed.
 How so? It's been necessary for as long
 as I can remember. Just to confirm, I looked to see if anything
 had changed:
 https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
 seems not. Do note; I'm not trying to be argumentative. Just
 don't see where it's not true (needed). :)

It not needed.

% su root
% script

Script started on Wed Nov 12 18:54:16 2014
troutmask:root[201] cd /usr/obj
troutmask:root[202] ls
usr/
troutmask:root[203] rm -rf usr
troutmask:root[204] ls
troutmask:root[205] exit
exit

Script done on Wed Nov 12 18:54:40 2014

QED

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [Xen-devel] [PATCH RFC 09/13] xen: change quality of the MADT ACPI enumerator

[Roger Pau Monné]

On 14/02/14 18:51, John Baldwin wrote:
 On Thursday, February 13, 2014 8:49:24 pm Andrew Cooper wrote:
 On 08/02/2014 21:42, John Baldwin wrote:
 On Tuesday, December 24, 2013 12:20:58 PM Roger Pau Monne wrote:
 Lower the quality of the MADT ACPI enumerator, so on Xen Dom0 we can
 force the usage of the Xen mptable enumerator even when ACPI is
 detected.
 Hmm, so I think one question is why does the existing MADT parser
 not work with the MADT table provided by Xen?  This may very well
 be correct, but if it's only a small change to make the existing
 MADT parser work with Xen's MADT table, that route might be
 preferable.


 For dom0, the MADT seen is the system MADT, which does not bear any
 reality to dom0's topology.  For PV domU, no MADT will be found.  For
 HVM domU, the MADT seen ought to represent (virtual) reality.
 
 Hmm, the other changes suggested that you do want to use the I/O APIC
 entries and interrupt overrides from the system MADT for dom0?  Just
 not the CPU entries.  Is that correct?

Yes, we need the interrupt entries in order to interact with the
underlying hardware, but not the CPU entries/topology.

Roger.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [PATCH RFC 10/13] xen: add ACPI bus to xen_nexus when running as Dom0

[Roger Pau Monné]

On 08/02/14 22:50, John Baldwin wrote:
 On Tuesday, December 24, 2013 12:20:59 PM Roger Pau Monne wrote:
 Also disable a couple of ACPI devices that are not usable under Dom0.
 
 Hmm, setting debug.acpi.disabled in this way is a bit hacky.  It might
 be fine however if there's no way for the user to set it before booting
 the kernel (as opposed to haing the relevant drivers explicitly disable
 themselves under Xen which I think would be cleaner, but would also
 make your patch larger)

Thanks for the review, the user can pass parameters to FreeBSD when
booted as Dom0, I just find it uncomfortable to force the user into
always setting something on the command line in order to boot.

What do you mean with haing the relevant drivers explicitly disable
themselves under Xen? Adding a gate on every one of those devices like
if (xen_pv_domain()) return (ENXIO); in the identify/probe routine
seems even worse.

Roger.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [PATCH RFC 10/13] xen: add ACPI bus to xen_nexus when running as Dom0

[John Baldwin]

On Friday, February 14, 2014 5:38:15 am Roger Pau Monné wrote:
 On 08/02/14 22:50, John Baldwin wrote:
  On Tuesday, December 24, 2013 12:20:59 PM Roger Pau Monne wrote:
  Also disable a couple of ACPI devices that are not usable under Dom0.
  
  Hmm, setting debug.acpi.disabled in this way is a bit hacky.  It might
  be fine however if there's no way for the user to set it before booting
  the kernel (as opposed to haing the relevant drivers explicitly disable
  themselves under Xen which I think would be cleaner, but would also
  make your patch larger)
 
 Thanks for the review, the user can pass parameters to FreeBSD when
 booted as Dom0, I just find it uncomfortable to force the user into
 always setting something on the command line in order to boot.

Can the user set debug.acpi.disabled?  If so, you are overriding their
setting which would be bad.

 What do you mean with haing the relevant drivers explicitly disable
 themselves under Xen? Adding a gate on every one of those devices like
 if (xen_pv_domain()) return (ENXIO); in the identify/probe routine
 seems even worse.

A check like this in probe() is what I had in mind, though I agree it's
not perfect.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [Xen-devel] [PATCH RFC 09/13] xen: change quality of the MADT ACPI enumerator

[John Baldwin]

On Thursday, February 13, 2014 8:49:24 pm Andrew Cooper wrote:
 On 08/02/2014 21:42, John Baldwin wrote:
  On Tuesday, December 24, 2013 12:20:58 PM Roger Pau Monne wrote:
  Lower the quality of the MADT ACPI enumerator, so on Xen Dom0 we can
  force the usage of the Xen mptable enumerator even when ACPI is
  detected.
  Hmm, so I think one question is why does the existing MADT parser
  not work with the MADT table provided by Xen?  This may very well
  be correct, but if it's only a small change to make the existing
  MADT parser work with Xen's MADT table, that route might be
  preferable.
 
 
 For dom0, the MADT seen is the system MADT, which does not bear any
 reality to dom0's topology.  For PV domU, no MADT will be found.  For
 HVM domU, the MADT seen ought to represent (virtual) reality.

Hmm, the other changes suggested that you do want to use the I/O APIC
entries and interrupt overrides from the system MADT for dom0?  Just
not the CPU entries.  Is that correct?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [PATCH RFC 10/13] xen: add ACPI bus to xen_nexus when running as Dom0

[John Baldwin]

On Tuesday, December 24, 2013 12:20:59 PM Roger Pau Monne wrote:
 Also disable a couple of ACPI devices that are not usable under Dom0.

Hmm, setting debug.acpi.disabled in this way is a bit hacky.  It might
be fine however if there's no way for the user to set it before booting
the kernel (as opposed to haing the relevant drivers explicitly disable
themselves under Xen which I think would be cleaner, but would also
make your patch larger)

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [PATCH RFC 09/13] xen: change quality of the MADT ACPI enumerator

[John Baldwin]

On Tuesday, December 24, 2013 12:20:58 PM Roger Pau Monne wrote:
 Lower the quality of the MADT ACPI enumerator, so on Xen Dom0 we can
 force the usage of the Xen mptable enumerator even when ACPI is
 detected.

Hmm, so I think one question is why does the existing MADT parser
not work with the MADT table provided by Xen?  This may very well
be correct, but if it's only a small change to make the existing
MADT parser work with Xen's MADT table, that route might be
preferable.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [Xen-devel] [PATCH RFC 09/13] xen: change quality of the MADT ACPI enumerator

[Andrew Cooper]

On 08/02/2014 21:42, John Baldwin wrote:
 On Tuesday, December 24, 2013 12:20:58 PM Roger Pau Monne wrote:
 Lower the quality of the MADT ACPI enumerator, so on Xen Dom0 we can
 force the usage of the Xen mptable enumerator even when ACPI is
 detected.
 Hmm, so I think one question is why does the existing MADT parser
 not work with the MADT table provided by Xen?  This may very well
 be correct, but if it's only a small change to make the existing
 MADT parser work with Xen's MADT table, that route might be
 preferable.


For dom0, the MADT seen is the system MADT, which does not bear any
reality to dom0's topology.  For PV domU, no MADT will be found.  For
HVM domU, the MADT seen ought to represent (virtual) reality.

~Andrew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[PATCH RFC 09/13] xen: change quality of the MADT ACPI enumerator

[Roger Pau Monne]

Lower the quality of the MADT ACPI enumerator, so on Xen Dom0 we can
force the usage of the Xen mptable enumerator even when ACPI is
detected.
---
 sys/x86/acpica/madt.c |2 +-
 sys/x86/xen/mptable.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys/x86/acpica/madt.c b/sys/x86/acpica/madt.c
index 6f3b591..897189c 100644
--- a/sys/x86/acpica/madt.c
+++ b/sys/x86/acpica/madt.c
@@ -104,7 +104,7 @@ madt_probe(void)
madt_physaddr = acpi_find_table(ACPI_SIG_MADT);
if (madt_physaddr == 0)
return (ENXIO);
-   return (0);
+   return (-50);
 }
 
 /*
diff --git a/sys/x86/xen/mptable.c b/sys/x86/xen/mptable.c
index 46b03f3..a9704ab 100644
--- a/sys/x86/xen/mptable.c
+++ b/sys/x86/xen/mptable.c
@@ -76,7 +76,7 @@ static struct apic_enumerator xenpv_enumerator = {
 static int
 xenpv_probe(void)
 {
-   return (-100);
+   return (0);
 }
 
 /*
-- 
1.7.7.5 (Apple Git-26)

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[PATCH RFC 10/13] xen: add ACPI bus to xen_nexus when running as Dom0

[Roger Pau Monne]

Also disable a couple of ACPI devices that are not usable under Dom0.
---
 sys/x86/xen/xen_nexus.c |   24 +---
 1 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/sys/x86/xen/xen_nexus.c b/sys/x86/xen/xen_nexus.c
index 288e6b6..823b3bc 100644
--- a/sys/x86/xen/xen_nexus.c
+++ b/sys/x86/xen/xen_nexus.c
@@ -35,6 +35,10 @@ __FBSDID($FreeBSD$);
 #include sys/systm.h
 #include sys/smp.h
 
+#include contrib/dev/acpica/include/acpi.h
+
+#include dev/acpica/acpivar.h
+
 #include machine/nexusvar.h
 
 #include xen/xen-os.h
@@ -44,7 +48,6 @@ static const char *xen_devices[] =
xenstore, /* XenStore bus */
xen_et,   /* Xen PV timer (provides: tc, et, clk) */
xc,   /* Xen PV console */
-   isa,  /* Dummy ISA bus for sc to attach */
 };
 
 /*
@@ -56,13 +59,14 @@ nexus_xen_probe(device_t dev)
if (!xen_pv_domain())
return (ENXIO);
 
-   return (BUS_PROBE_DEFAULT);
+   return (BUS_PROBE_SPECIFIC);
 }
 
 static int
 nexus_xen_attach(device_t dev)
 {
int i, error = 0;
+   device_t acpi_dev;
 
nexus_init_resources();
bus_generic_probe(dev);
@@ -79,8 +83,22 @@ nexus_xen_attach(device_t dev)
if (BUS_ADD_CHILD(dev, 0, xen_devices[i], 0) == NULL)
panic(%s: could not add, xen_devices[i]);
}
+   if (xen_initial_domain()) {
+   /* Disable some ACPI devices that are not usable by Dom0 */
+   setenv(debug.acpi.disabled, cpu hpet timer);
+
+   acpi_dev = BUS_ADD_CHILD(dev, 10, acpi, 0);
+   if (acpi_dev == NULL)
+   panic(Unable to add ACPI bus to Xen Dom0);
+   } else {
+   /* Dummy ISA bus for sc to attach */
+   if (BUS_ADD_CHILD(dev, 0, isa, 0) == NULL)
+   panic(isa: could not add);
+   }
 
-   bus_generic_attach(dev);
+   error = bus_generic_attach(dev);
+   if (xen_initial_domain()  (error == 0))
+   acpi_install_wakeup_handler(device_get_softc(acpi_dev));
 
return (error);
 }
-- 
1.7.7.5 (Apple Git-26)

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: amd64/181357: LCD Brightness Control not working on Lenovo X121e (ACPI issue?)

[Matthias Petermann]

Hello,

regarding this PR I made some further observation. Even the 
acpi_ec_write seems to not have any effect on the brightness, the values 
set to the appropriate register (IBM_EC_BRIGHTNESS   0x31) survive a 
reboot.


Looks like the values are stored correctly, but EC doesn't care for them 
when setting brightness?


I'm not sure where to look next. Could this be a hardware issue with the 
Device?


Kind regards,
Matthias
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: amd64/181357: LCD Brightness Control not working on Lenovo X121e (ACPI issue?)

[Dominic Fandrey]

On 24/08/2013 17:08, Matthias Petermann wrote:
 regarding this PR I made some further observation. Even the acpi_ec_write 
 seems to not have any effect on the brightness, the values set to the 
 appropriate register (IBM_EC_BRIGHTNESS   0x31) survive a reboot.

My LCD brightness control stopped working when I switched to NEW_XORG
with Intel KMS (on stable/9).

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: amd64/181357: LCD Brightness Control not working on Lenovo X121e (ACPI issue?)

[Matthias Petermann]

Am 24.08.2013 20:02, schrieb Dominic Fandrey:
My LCD brightness control stopped working when I switched to NEW_XORG 
with Intel KMS (on stable/9). 


It's the same issue when I run in console only mode (without Xorg, 
without KMS kernel module loaded).

What Lenovo model are you using?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

amd64/181358: Suspend to RAM not working correctly on Lenovo X121e (ACPI issue?)

[Matthias Petermann]

Hello,

regarding the issue mentioned in the subject (Lenovo Thinkpad X121e not 
able to resume after suspend to ram) there is finally some progress. I 
found this few months old discussion[1] on freebsd-acpi (related to 
Thinkpad X201):


I had a similar problem. After syncing with FreeBSD 10-CURRENT and 
compiling a kernel without
VESA support, I was able to get graphics to work on resume, but only 
when running X. 


This works for the X121e too! It is now able to suspend and resume 
properly when running Xorg (with i915kms.ko). I'm really happy :-)


There is only a (very minor) problem: after the first resume Xorg 
graphics seem to slow down. When moving windows on the screen they leave 
some traces behind and it takes some milliseconds until they are wiped 
away and replaced with the background image.


Kind regards,
Matthias


[1]

http://freebsd.1045724.n5.nabble.com/Resume-failed-after-Suspend-on-Thinkpad-x201i-td5723622.html

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD-head hang when shutdown by ACPI with Intel GPU and new Xorg and SandyBridge

[Aleksandr Rybalko]

On Fri, 12 Jul 2013 18:05:47 +0200
Lars Engels lars.eng...@0x20.net wrote:

 On Fri, Jul 12, 2013 at 11:26:06AM +0100, David Chisnall wrote:
  On 12 Jul 2013, at 10:01, Lundberg, Johannes
  johan...@brilliantservice.co.jp wrote:
  
   As the KMS code does not switch the display mode back, once X
   with KMS
   starts, you can't get a console back.
   
   Is there any solution for this in the works?
  
  Yes.  ray@ is currently being funded by the FreeBSD Foundation to
  improve Newcons compatibility with KMS.  The Newcons framework is
  designed to improve layering in the console.  The machine-dependent
  part simply provides a framebuffer interface, the
  machine-independent part provides the terminal emulator (this also
  means things like unicode in the console will work, as will
  higher-resolution consoles). It's currently used on a few non-x86
  platforms, but it wasn't a priority for x86 because the PC BIOS
  text console mostly works and people who want a better terminal can
  just run X.  It's now become a priority because of the KMS
  integration with X.org.  Once this work is completed, we will
  switch to a new X.org by default and will use the KMS interface
  within the kernel for selecting the video mode.  
 
 Is there a rough ETA for this great improvement?

I hope first things to test will be available on begin of the August.
But it is just hope yet :)

Thanks.
-- 
Aleksandr Rybalko r...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD-head hang when shutdown by ACPI with Intel GPU and new Xorg and SandyBridge

[Lundberg, Johannes]

 As the KMS code does not switch the display mode back, once X with KMS
starts, you can't get a console back.

Is there any solution for this in the works?

Johannes Lundberg
BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp


On Wed, May 22, 2013 at 5:44 AM, Kevin Oberman rkober...@gmail.com wrote:

 On Tue, May 21, 2013 at 12:50 PM, Artyom Mirgorodskiy 
 artyom.mirgorod...@gmail.com wrote:

  Hi
  More than a month I can not shutdown FreeBSD on my laptop correctly when
  running Xorg with Intel GPU. However reboot work correctly. Shutdown work
  fine if I choose Vesa driver in xorg.conf. So I can run with intel, then
  edit xorg.conf, kill Xorg server and shutdown correctly. If I shut down
  immediately after loading Xorg - everything is fine too.
  Without the text console is difficult to provide any information :( Why
  would still not recover mode when kill Xorg?
 
  PS
  I try to disable RC6 states -without any changes.
  FreeBSD shutdown correctly before January.
 

 I am seeing similar issues on my Sandybridge running Xorg with KMS, but I
 see it on 9-Stable.

 The main difference between shutdown and reboot is that shutdown goes
 through the rc.d files and issues a 'stop' for each. reboot simply kills
 running processes, first by sending SIGTERM and then sending SIGKILL to
 those that still live. So something is failing to die and that something
 is probably X. The system still responds to ICMP ECHOREQUEST (i.e. ping),
 but I can't fire up an ssh session.

 As the KMS code does not switch the display mode back, once X with KMS
 starts, you can't get a console back.

 Since the system is deadlocked in this state, I suspect something bad is
 happening in the KMS code that leaves the system hung.

 I may try to run a firewire console. Never tried it, but it should work.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org