Re: [patch] USB after second suspend/resume on ThinkPads.

2014-06-19 Thread Alexandr Krivulya 
18.06.2014 12:29, Edward Tomasz Napierała пишет:
 On 0618T1108, Alexandr Krivulya wrote:
 16.06.2014 22:21, Edward Tomasz Napierała пишет:
 Hi.  Patch below should fix a problem where USB stops working after
 _second_ suspend/resume, which happens on various ThinkPad models.
 Please test, and report both success stories and failures.  If nothing
 comes up, I'll commit it in a week or so.

 (Btw, has anyone encountered the problem on hardware other than ThinkPads?)


 Index: sys/dev/acpi_support/acpi_ibm.c
 ===
 --- sys/dev/acpi_support/acpi_ibm.c (revision 267417)
 +++ sys/dev/acpi_support/acpi_ibm.c (working copy)
 @@ -169,6 +169,9 @@ struct acpi_ibm_softc {
 int light_get_supported;
 int light_set_supported;
  
 +   /* USB power workaround */
 +   ACPI_HANDLE power_handle;
 +
 /* led(4) interface */
 struct cdev *led_dev;
 int led_busy;
 @@ -365,6 +368,7 @@ acpi_ibm_attach(device_t dev)
  {
 struct acpi_ibm_softc   *sc;
 devclass_t  ec_devclass;
 +   ACPI_STATUS status;
  
 ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
  
 @@ -448,6 +452,17 @@ acpi_ibm_attach(device_t dev)
 if (sc-light_set_supported)
 sc-led_dev = led_create_state(ibm_led, sc, thinklight, 
 sc-light_val);
  
 +   /*
 +* Obtain a handle to the power resource available on many models.
 +* This must be turned on manually upon resume. Otherwise the system
 +* may, for instance, resume from S3 with usb(4) powered down.
 +*/
 +   status = AcpiGetHandle(sc-handle, \\_SB.PCI0.LPC.EC.PUBS, 
 sc-power_handle);
 +   if (ACPI_FAILURE(status)) {
 +   device_printf(dev, Failed to get power handle\n);
 +   return (status);
 +   }
 +
 return (0);
  }
  
 @@ -476,6 +491,7 @@ static int
  acpi_ibm_resume(device_t dev)
  {
 struct acpi_ibm_softc *sc = device_get_softc(dev);
 +   ACPI_STATUS status;
  
 ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
  
 @@ -495,6 +511,15 @@ acpi_ibm_resume(device_t dev)
  
 acpi_ibm_sysctl_set(sc, i, val);
 }
 +   if (sc-power_handle != NULL) {
 +   status = AcpiEvaluateObject(sc-power_handle,
 +   _ON, NULL, NULL);
 +   if (ACPI_FAILURE(status)) {
 +   device_printf(dev, failed to switch %s on - %s\n,
 +   acpi_name(sc-power_handle),
 +   AcpiFormatException(status));
 +   }
 +   }
 ACPI_SERIAL_END(ibm);
  
 return (0);
 Hi. I've never seen this problem before on my ThinkPad E530. However, I
 have applied this patch and after reboot all sysctl oids related to
 acpi_ibm disappeared.

 root@thinkpad:/home/shurik # kldstat|grep ibm
 9 1 0x8219 77e8 acpi_ibm.ko

 root@thinkpad:/home/shurik # sysctl dev.acpi_ibm
 root@thinkpad:/home/shurik #

 And in dmesg I see this errors:

 root@thinkpad:/home/shurik # dmesg -a|grep ibm
 acpi_ibm0: IBM ThinkPad ACPI Extras on acpi0
 acpi_ibm0: Failed to get power handle
 device_attach: acpi_ibm0 attach returned 5
 Ok, I'll make that attach problem non-fatal.

 Just to make sure: without the patch you don't have any problems
 with USB after multiple suspend/resume cycles, and you don't use
 any workarounds to make it work, eg. setting the dev.uhci.0.wake=1,
 or making USB ports always powered on in BIOS?

Exactly. I have no any problems with USB. Average uptime is two-three
weeks with everyday suspend/resume cycle. And I don't use any special
settings related to usb in loader.conf or sysctl.conf. The only
difference with GENERIC - all usb support built and loaded as modules.
In my BIOS i have turned on such settings:

- USB Support
- UEFI BIOS Support
- Always On USB


___
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] USB after second suspend/resume on ThinkPads.

2014-06-19 Thread Edward Tomasz Napierała 
On 0619T0935, Alexandr Krivulya wrote:
 18.06.2014 12:29, Edward Tomasz Napierała пишет:
  On 0618T1108, Alexandr Krivulya wrote:
  16.06.2014 22:21, Edward Tomasz Napierała пишет:
  Hi.  Patch below should fix a problem where USB stops working after
  _second_ suspend/resume, which happens on various ThinkPad models.
  Please test, and report both success stories and failures.  If nothing
  comes up, I'll commit it in a week or so.
 
  (Btw, has anyone encountered the problem on hardware other than 
  ThinkPads?)
 
 
  Index: sys/dev/acpi_support/acpi_ibm.c
  ===
  --- sys/dev/acpi_support/acpi_ibm.c   (revision 267417)
  +++ sys/dev/acpi_support/acpi_ibm.c   (working copy)
  @@ -169,6 +169,9 @@ struct acpi_ibm_softc {
int light_get_supported;
int light_set_supported;
   
  + /* USB power workaround */
  + ACPI_HANDLE power_handle;
  +
/* led(4) interface */
struct cdev *led_dev;
int led_busy;
  @@ -365,6 +368,7 @@ acpi_ibm_attach(device_t dev)
   {
struct acpi_ibm_softc   *sc;
devclass_t  ec_devclass;
  + ACPI_STATUS status;
   
ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
   
  @@ -448,6 +452,17 @@ acpi_ibm_attach(device_t dev)
if (sc-light_set_supported)
sc-led_dev = led_create_state(ibm_led, sc, thinklight, 
  sc-light_val);
   
  + /*
  +  * Obtain a handle to the power resource available on many models.
  +  * This must be turned on manually upon resume. Otherwise the system
  +  * may, for instance, resume from S3 with usb(4) powered down.
  +  */
  + status = AcpiGetHandle(sc-handle, \\_SB.PCI0.LPC.EC.PUBS, 
  sc-power_handle);
  + if (ACPI_FAILURE(status)) {
  + device_printf(dev, Failed to get power handle\n);
  + return (status);
  + }
  +
return (0);
   }
   
  @@ -476,6 +491,7 @@ static int
   acpi_ibm_resume(device_t dev)
   {
struct acpi_ibm_softc *sc = device_get_softc(dev);
  + ACPI_STATUS status;
   
ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
   
  @@ -495,6 +511,15 @@ acpi_ibm_resume(device_t dev)
   
acpi_ibm_sysctl_set(sc, i, val);
}
  + if (sc-power_handle != NULL) {
  + status = AcpiEvaluateObject(sc-power_handle,
  + _ON, NULL, NULL);
  + if (ACPI_FAILURE(status)) {
  + device_printf(dev, failed to switch %s on - %s\n,
  + acpi_name(sc-power_handle),
  + AcpiFormatException(status));
  + }
  + }
ACPI_SERIAL_END(ibm);
   
return (0);
  Hi. I've never seen this problem before on my ThinkPad E530. However, I
  have applied this patch and after reboot all sysctl oids related to
  acpi_ibm disappeared.
 
  root@thinkpad:/home/shurik # kldstat|grep ibm
  9 1 0x8219 77e8 acpi_ibm.ko
 
  root@thinkpad:/home/shurik # sysctl dev.acpi_ibm
  root@thinkpad:/home/shurik #
 
  And in dmesg I see this errors:
 
  root@thinkpad:/home/shurik # dmesg -a|grep ibm
  acpi_ibm0: IBM ThinkPad ACPI Extras on acpi0
  acpi_ibm0: Failed to get power handle
  device_attach: acpi_ibm0 attach returned 5
  Ok, I'll make that attach problem non-fatal.
 
  Just to make sure: without the patch you don't have any problems
  with USB after multiple suspend/resume cycles, and you don't use
  any workarounds to make it work, eg. setting the dev.uhci.0.wake=1,
  or making USB ports always powered on in BIOS?
 
 Exactly. I have no any problems with USB. Average uptime is two-three
 weeks with everyday suspend/resume cycle. And I don't use any special
 settings related to usb in loader.conf or sysctl.conf. The only
 difference with GENERIC - all usb support built and loaded as modules.
 In my BIOS i have turned on such settings:
 
 - USB Support
 - UEFI BIOS Support
 - Always On USB

The last one is off by default, right?  Turning it on actually
works around the problem in earlier Thinkpad models.  Could you
try to set it to default (disable) and see if the problem still
doesn't occur?

___
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] USB after second suspend/resume on ThinkPads.

2014-06-19 Thread Stefan Ehmann 

On 16.06.2014 21:21, Edward Tomasz Napierała wrote:

Hi.  Patch below should fix a problem where USB stops working after
_second_ suspend/resume, which happens on various ThinkPad models.
Please test, and report both success stories and failures.  If nothing
comes up, I'll commit it in a week or so.

(Btw, has anyone encountered the problem on hardware other than ThinkPads?)


Fixed USB resume issues on T410 for me.

At first I thought it didn't work, but then I noticed acpi_ibm needs to 
be loaded.


Thanks! This has been a long-standing and annoying bug.
___
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] USB after second suspend/resume on ThinkPads.

2014-06-19 Thread Alexandr Krivulya 
19.06.2014 13:44, Edward Tomasz Napierała пишет:
 On 0619T0935, Alexandr Krivulya wrote:
 18.06.2014 12:29, Edward Tomasz Napierała пишет:
 On 0618T1108, Alexandr Krivulya wrote:
 16.06.2014 22:21, Edward Tomasz Napierała пишет:
 Hi.  Patch below should fix a problem where USB stops working after
 _second_ suspend/resume, which happens on various ThinkPad models.
 Please test, and report both success stories and failures.  If nothing
 comes up, I'll commit it in a week or so.

 (Btw, has anyone encountered the problem on hardware other than 
 ThinkPads?)


 Index: sys/dev/acpi_support/acpi_ibm.c
 ===
 --- sys/dev/acpi_support/acpi_ibm.c   (revision 267417)
 +++ sys/dev/acpi_support/acpi_ibm.c   (working copy)
 @@ -169,6 +169,9 @@ struct acpi_ibm_softc {
   int light_get_supported;
   int light_set_supported;
  
 + /* USB power workaround */
 + ACPI_HANDLE power_handle;
 +
   /* led(4) interface */
   struct cdev *led_dev;
   int led_busy;
 @@ -365,6 +368,7 @@ acpi_ibm_attach(device_t dev)
  {
   struct acpi_ibm_softc   *sc;
   devclass_t  ec_devclass;
 + ACPI_STATUS status;
  
   ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
  
 @@ -448,6 +452,17 @@ acpi_ibm_attach(device_t dev)
   if (sc-light_set_supported)
   sc-led_dev = led_create_state(ibm_led, sc, thinklight, 
 sc-light_val);
  
 + /*
 +  * Obtain a handle to the power resource available on many models.
 +  * This must be turned on manually upon resume. Otherwise the system
 +  * may, for instance, resume from S3 with usb(4) powered down.
 +  */
 + status = AcpiGetHandle(sc-handle, \\_SB.PCI0.LPC.EC.PUBS, 
 sc-power_handle);
 + if (ACPI_FAILURE(status)) {
 + device_printf(dev, Failed to get power handle\n);
 + return (status);
 + }
 +
   return (0);
  }
  
 @@ -476,6 +491,7 @@ static int
  acpi_ibm_resume(device_t dev)
  {
   struct acpi_ibm_softc *sc = device_get_softc(dev);
 + ACPI_STATUS status;
  
   ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
  
 @@ -495,6 +511,15 @@ acpi_ibm_resume(device_t dev)
  
   acpi_ibm_sysctl_set(sc, i, val);
   }
 + if (sc-power_handle != NULL) {
 + status = AcpiEvaluateObject(sc-power_handle,
 + _ON, NULL, NULL);
 + if (ACPI_FAILURE(status)) {
 + device_printf(dev, failed to switch %s on - %s\n,
 + acpi_name(sc-power_handle),
 + AcpiFormatException(status));
 + }
 + }
   ACPI_SERIAL_END(ibm);
  
   return (0);
 Hi. I've never seen this problem before on my ThinkPad E530. However, I
 have applied this patch and after reboot all sysctl oids related to
 acpi_ibm disappeared.

 root@thinkpad:/home/shurik # kldstat|grep ibm
 9 1 0x8219 77e8 acpi_ibm.ko

 root@thinkpad:/home/shurik # sysctl dev.acpi_ibm
 root@thinkpad:/home/shurik #

 And in dmesg I see this errors:

 root@thinkpad:/home/shurik # dmesg -a|grep ibm
 acpi_ibm0: IBM ThinkPad ACPI Extras on acpi0
 acpi_ibm0: Failed to get power handle
 device_attach: acpi_ibm0 attach returned 5
 Ok, I'll make that attach problem non-fatal.

 Just to make sure: without the patch you don't have any problems
 with USB after multiple suspend/resume cycles, and you don't use
 any workarounds to make it work, eg. setting the dev.uhci.0.wake=1,
 or making USB ports always powered on in BIOS?

 Exactly. I have no any problems with USB. Average uptime is two-three
 weeks with everyday suspend/resume cycle. And I don't use any special
 settings related to usb in loader.conf or sysctl.conf. The only
 difference with GENERIC - all usb support built and loaded as modules.
 In my BIOS i have turned on such settings:

 - USB Support
 - UEFI BIOS Support
 - Always On USB
 The last one is off by default, right?  Turning it on actually
 works around the problem in earlier Thinkpad models.  Could you
 try to set it to default (disable) and see if the problem still
 doesn't occur?

This option is enabled by default on my laptop. It allows to charge
mobile devices when laptop in sleep state or powered off via USB 2.0 port.
Now, I reset BIOS to default settings and turned off Always on USB,
boot to my old kernel without patch and do suspend/resume three times.
Both 3.0 and 2.0 USB ports works fine after each resume.
___
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: Problems building FreeBSD 9.2 on FreeBSD 10

2014-06-19 Thread Julian Elischer 

On 6/18/14, 4:05 AM, Simon J. Gerraty wrote:

On Tue, 17 Jun 2014 11:35:42 -0700, Craig Rodrigues writes:

Do you know if there is some sort of patch that can be applied to
FreeBSD stable/9 sources so that it can be built on a FreeBSD
10/stable, or FreeBSD CURRENT
host with bmake?

You would likely need to apply many of the changes made in 10.
IIRC stable/9 has just enough bmake support to be able to build/install
bmake itself, so that ports can use it.

I'm not sure how many people would appreciate making such changes to
stable/9 at this point.

I just populate  a jail with 9.0 binaries from the DVD image.



I'm trying to build a FreeBSD stable/9 jail on a FreeBSD 10/stable host, so th
at
I can build ports inside the jail with poudriere.

Why not use fmake in that scenario?
___
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: [patch] USB after second suspend/resume on ThinkPads.

2014-06-19 Thread Edward Tomasz Napierała 
On 0618T1515, John Baldwin wrote:
 On Wednesday, June 18, 2014 2:46:09 pm Edward Tomasz Napierała wrote:
  On 0618T1303, John Baldwin wrote:
   On Wednesday, June 18, 2014 12:13:15 pm Edward Tomasz Napierała wrote:
On 0618T0947, John Baldwin wrote:
 On Monday, June 16, 2014 3:21:55 pm Edward Tomasz Napierała wrote:
  Hi.  Patch below should fix a problem where USB stops working after
  _second_ suspend/resume, which happens on various ThinkPad models.
  Please test, and report both success stories and failures.  If 
  nothing
  comes up, I'll commit it in a week or so.
 
 Good find.  Have you thought about a more generic fix for this 
 wherein you 
 track power resources and flip them on during resume in ACPI before 
 doing
 DEVICE_RESUME() on the root bus?

Thing is, after resume this device claims to be on already.  The 
following
simple hack was enough to make it work:
   
   Ahh, I think I see.  Try this instead:
   
   Index: sys/dev/acpica/acpi_powerres.c
   ===
   --- acpi_powerres.c   (revision 267550)
   +++ acpi_powerres.c   (working copy)
   @@ -645,7 +645,7 @@ acpi_pwr_switch_power(void)
   acpi_name(rp-ap_resource), status));
 /* XXX is this correct?  Always switch if in doubt? */
 continue;
   - } else if (rp-ap_state == ACPI_PWR_UNK)
   + } else
 rp-ap_state = cur;

 /*
   @@ -689,7 +689,7 @@ acpi_pwr_switch_power(void)
   acpi_name(rp-ap_resource), status));
 /* XXX is this correct?  Always switch if in doubt? */
 continue;
   - } else if (rp-ap_state == ACPI_PWR_UNK)
   + } else
 rp-ap_state = cur;

 /*
   
   (We were ignoring what _STA told us and believed it was ON because we had
cached that state previously.)
  
  Works!
 
 Hmmm.  If we go this route, ap_state is actually useless and should just be
 removed.  Here is an updated version that does that.  If this works as well

Works as well.

___
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

ucom_free Fatal trap on shutdown / module unload

2014-06-19 Thread Lundberg, Johannes 
Hi

I'm getting this error on 11-CURRENT amd64 (snapshot from June). (see
attached image)
Worked fine with 10 I think..

The ucom module is loaded as a dependency by the uhso module.

Any clues?
--
Johannes Lundberg


[image: Inline image 1]

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
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: Problems building FreeBSD 9.2 on FreeBSD 10

2014-06-19 Thread Warner Losh 

On Jun 18, 2014, at 4:32 PM, Craig Rodrigues rodr...@freebsd.org wrote:

 On Tue, Jun 17, 2014 at 11:59 PM, Dimitry Andric d...@freebsd.org wrote:
 
 See r257658 which had fixed this, but it was reverted by Warner,
 unfortunately.  This was one of the uses of the EARLY_BUILD flag which
 was *not* redundant. :-/
 
 
 Warner,
 
 Is there a way to bring back the behavior of r257658 but without
 the way it was implemented with the EARLY_BUILD flag?
 It would be handy, as we can see by this thread discussion.

OK. I must be daft, or maybe just missing something. But I can build 9.3 almost 
branch point on a current jail running on a 10.x system (to simulate the 9 on 
current case). I don’t see the problem being talked about at all. As for 9 on 
10, I was also able to do a build, but my 10.x system may not have been 
pristine.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Problems building FreeBSD 9.2 on FreeBSD 10

2014-06-19 Thread Glen Barber 
On Thu, Jun 19, 2014 at 10:00:03PM -0600, Warner Losh wrote:
 
 On Jun 18, 2014, at 4:32 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
  On Tue, Jun 17, 2014 at 11:59 PM, Dimitry Andric d...@freebsd.org wrote:
  
  See r257658 which had fixed this, but it was reverted by Warner,
  unfortunately.  This was one of the uses of the EARLY_BUILD flag which
  was *not* redundant. :-/
  
  
  Warner,
  
  Is there a way to bring back the behavior of r257658 but without
  the way it was implemented with the EARLY_BUILD flag?
  It would be handy, as we can see by this thread discussion.
 
 OK. I must be daft, or maybe just missing something. But I can build 9.3 
 almost branch point on a current jail running on a 10.x system (to simulate 
 the 9 on current case). I don’t see the problem being talked about at all. As 
 for 9 on 10, I was also able to do a build, but my 10.x system may not have 
 been pristine.
 

Removal of EARLY_BUILD is not the issue here, I have no idea where the
hell the came into play.

It is a race in the chain with what make(1) gets built for the stable/9
userland.  It is why the 'make make buildworld' thing I mentioned works.

Glen



pgpYeCFRFGObO.pgp
Description: PGP signature