Re: Problems building FreeBSD 9.2 on FreeBSD 10
On 18 Jun 2014, at 01:33, Craig Rodrigues wrote: > On Tue, Jun 17, 2014 at 2:54 PM, Craig Rodrigues wrote: >> On Tue, Jun 17, 2014 at 2:14 PM, Glen Barber wrote: >>> >>> For what it is worth, I'm working around this problem by running: >>> >>># make make buildworld -jN [...] >>> >>> Note the extra 'make', which rather than relying on the bootstrap-tools >>> to determine which make to build, I am specifically telling it to build >>> fmake. >> >> >> Nice! That works! >> Thanks. >> >> -- >> Craig > > > Oops, that got me a bit farther, but further along, things failed for me with: ... > echo gperf: /usr/lib/libstdc++.a >> .depend > ===> gnu/usr.bin/gperf/doc (depend) > make: don't know how to make /usr/lib/libstdc++.a. Stop 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. :-/ -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [patch] USB after second suspend/resume on ThinkPads.
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: on acpi0
acpi_ibm0: Failed to get power handle
device_attach: acpi_ibm0 attach returned 5
sysctl: unknown oid 'dev.acpi_ibm.0.events' at line 22: No such file or
directory
sysctl: unknown oid 'dev.acpi_ibm.0.fan' at line 23: No such file or
directory
sysctl: unknown oid 'dev.acpi_ibm.0.bluetooth' at line 24: No such file
or directory
acpi_ibm0: on acpi0
#5 0x8260766c at acpi_ibm_attach+0x5bc
acpi_ibm0: on acpi0
acpi_ibm0: Failed to get power handle
device_attach: acpi_ibm0 attach returned 5
All Fn keys and usb ports still work fine before/after suspend/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: [patch] USB after second suspend/resume on ThinkPads.
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: 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?
___
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.
On Mon, Jun 16, 2014 at 09:21:55PM +0200, 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?) You, Sir, are officially my hero of the month! I applied the patch and it works flawlessly on my Thinkpad X200 (4 resumes so far). Thanks a lot! Lars pgp0wJKMMXJGm.pgp Description: PGP signature
[RFC] Huge sysctl patch for the kernel coming - work in progress
Hi,
Sometimes sysctl's default value needs to be setup at boot time and not
when the rc.d/sysctl is running. Currently this is done by having two
statements in the kernel:
TUNABLE_INT("net.graph.mppe.log_max_rekey", &mppe_log_max_rekey);
SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RW,
I want to simplify this to:
SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RWTUN,
In other words if the existing CTLFLAG_TUN is set, the sysctl will
automatically be pre-loaded with values from /boot/loader.conf.
The reason we don't want the current approach is:
1) It duplicates the sysctl path in the TUNABLE statement.
2) It does not work very well for dynamically attached sysctls. There is
a lot of code overhead computing the TUNABLE() path before the TUNABLE()
can be fetched.
Here is a work in progress:
http://home.selasky.org:8192/sysctl_tunable.diff
In most cases my patch is fine, but in some other cases I need some
input, like in the VM subsystem when doing init, I'm not sure if the
SYSINIT() for subsystem SI_SUB_KMEM, which sysctl's are using, has
already been executed.
--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: [patch] USB after second suspend/resume on ThinkPads.
On 0616T1241, Adrian Chadd wrote: > Hey cool! > > I'll go test this out soon. > > Would you mind throwing it in a bugzilla ticket? It's 191155. ___ 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.
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? Alternatively, this probably meshes well with Justin's work on multipass suspend/resume in that ACPI buses (e.g. acpi_pci and acpi0 itself) should be turning on any power sources associated with an ACPI device during the bus_resume_child() callback. -- 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: [RFC] Huge sysctl patch for the kernel coming - work in progress
On Wednesday, June 18, 2014 7:36:53 am Hans Petter Selasky wrote:
> Hi,
>
> Sometimes sysctl's default value needs to be setup at boot time and not
> when the rc.d/sysctl is running. Currently this is done by having two
> statements in the kernel:
>
> TUNABLE_INT("net.graph.mppe.log_max_rekey", &mppe_log_max_rekey);
> SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RW,
>
> I want to simplify this to:
>
> SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RWTUN,
>
> In other words if the existing CTLFLAG_TUN is set, the sysctl will
> automatically be pre-loaded with values from /boot/loader.conf.
>
> The reason we don't want the current approach is:
>
> 1) It duplicates the sysctl path in the TUNABLE statement.
> 2) It does not work very well for dynamically attached sysctls. There is
> a lot of code overhead computing the TUNABLE() path before the TUNABLE()
> can be fetched.
>
> Here is a work in progress:
>
> http://home.selasky.org:8192/sysctl_tunable.diff
>
> In most cases my patch is fine, but in some other cases I need some
> input, like in the VM subsystem when doing init, I'm not sure if the
> SYSINIT() for subsystem SI_SUB_KMEM, which sysctl's are using, has
> already been executed.
I think this is a good idea, but it's also true you can just leave separate
TUNABLE_ statements without setting the CTLFLAG_TUN flag for cases you aren't
sure about for now. It probably makes sense to do these changes in stages.
I was going to suggest using sbuf() for building the tunable name, but that
doesn't work since you have to build it in reverse.
--
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] USB after second suspend/resume on ThinkPads.
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:
Index: sys/dev/acpica/acpi_powerres.c
===
--- sys/dev/acpica/acpi_powerres.c (revision 267417)
+++ sys/dev/acpica/acpi_powerres.c (working copy)
@@ -653,7 +653,7 @@ acpi_pwr_switch_power(void)
* effort; we don't know what to do if it fails, so checking wouldn't
* help much.
*/
- if (rp->ap_state != ACPI_PWR_ON) {
+ if (rp->ap_state != ACPI_PWR_ON || 1) {
status = AcpiEvaluateObject(rp->ap_resource, "_ON", NULL, NULL);
if (ACPI_FAILURE(status)) {
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS,
___
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.
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.) -- 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] USB after second suspend/resume on ThinkPads.
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! ___ 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: [RFC] Huge sysctl patch for the kernel coming - work in progress
On 06/18/14 15:44, John Baldwin wrote:
On Wednesday, June 18, 2014 7:36:53 am Hans Petter Selasky wrote:
Hi,
Sometimes sysctl's default value needs to be setup at boot time and not
when the rc.d/sysctl is running. Currently this is done by having two
statements in the kernel:
TUNABLE_INT("net.graph.mppe.log_max_rekey", &mppe_log_max_rekey);
SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RW,
I want to simplify this to:
SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RWTUN,
In other words if the existing CTLFLAG_TUN is set, the sysctl will
automatically be pre-loaded with values from /boot/loader.conf.
The reason we don't want the current approach is:
1) It duplicates the sysctl path in the TUNABLE statement.
2) It does not work very well for dynamically attached sysctls. There is
a lot of code overhead computing the TUNABLE() path before the TUNABLE()
can be fetched.
Here is a work in progress:
http://home.selasky.org:8192/sysctl_tunable.diff
In most cases my patch is fine, but in some other cases I need some
input, like in the VM subsystem when doing init, I'm not sure if the
SYSINIT() for subsystem SI_SUB_KMEM, which sysctl's are using, has
already been executed.
I think this is a good idea, but it's also true you can just leave separate
TUNABLE_ statements without setting the CTLFLAG_TUN flag for cases you aren't
sure about for now. It probably makes sense to do these changes in stages.
I was going to suggest using sbuf() for building the tunable name, but that
doesn't work since you have to build it in reverse.
Hi,
After going through a lot of existing code, I've decided to make a new
flag, CTLFLAG_FETCH rather than overload CTLFLAG_TUN, so that the new
functionality can be added to drivers and tested. For example sysctls
which implement function callbacks and are not trivial, this might cause
locking of non-initialized mutexes and so on. And also I see some
dependencies, that values are fetched at a certain point in the boot
process and that existing CTLFLAG_TUN might confuse existing logic.
I've updated my patch (same link):
http://home.selasky.org:8192/sysctl_tunable.diff
BTW: Can someone which have a beefy machine run a universe with this
patch applied?
I'll probably put it into the tree next week.
--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: [patch] USB after second suspend/resume on ThinkPads.
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
then this is probably a commit candidate.
Index: acpi_powerres.c
===
--- acpi_powerres.c (revision 267550)
+++ acpi_powerres.c (working copy)
@@ -64,7 +64,6 @@ ACPI_MODULE_NAME("POWERRES")
/* Return values from _STA on a power resource */
#define ACPI_PWR_OFF 0
#define ACPI_PWR_ON1
-#define ACPI_PWR_UNK (-1)
/* A relationship between a power resource and a consumer. */
struct acpi_powerreference {
@@ -90,7 +89,6 @@ struct acpi_powerresource {
ACPI_HANDLEap_resource;
UINT64 ap_systemlevel;
UINT64 ap_order;
-intap_state;
};
static TAILQ_HEAD(acpi_powerresource_list, acpi_powerresource)
@@ -173,7 +171,6 @@ acpi_pwr_register_resource(ACPI_HANDLE res)
}
rp->ap_systemlevel = obj->PowerResource.SystemLevel;
rp->ap_order = obj->PowerResource.ResourceOrder;
-rp->ap_state = ACPI_PWR_UNK;
/* Sort the resource into the list */
status = AE_OK;
@@ -638,7 +635,6 @@ acpi_pwr_switch_power(void)
continue;
}
- /* We could cache this if we trusted it not to change under us */
status = acpi_GetInteger(rp->ap_resource, "_STA", &cur);
if (ACPI_FAILURE(status)) {
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "can't get status of %s - %d\n",
@@ -645,8 +641,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)
- rp->ap_state = cur;
+ }
/*
* Switch if required. Note that we ignore the result of the switch
@@ -653,7 +648,7 @@ acpi_pwr_switch_power(void)
* effort; we don't know what to do if it fails, so checking wouldn't
* help much.
*/
- if (rp->ap_state != ACPI_PWR_ON) {
+ if (cur != ACPI_PWR_ON) {
status = AcpiEvaluateObject(rp->ap_resource, "_ON", NULL, NULL);
if (ACPI_FAILURE(status)) {
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS,
@@ -661,7 +656,6 @@ acpi_pwr_switch_power(void)
acpi_name(rp->ap_resource),
AcpiFormatException(status)));
} else {
- rp->ap_state = ACPI_PWR_ON;
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "switched %s on\n",
acpi_name(rp->ap_resource)));
}
@@ -682,7 +676,6 @@ acpi_pwr_switch_power(void)
continue;
}
- /* We could cache this if we trusted it not to change under us */
status = acpi_GetInteger(rp->ap_resource, "_STA", &cur);
if (ACPI_FA
Re: [RFC] Huge sysctl patch for the kernel coming - work in progress
On Wednesday, June 18, 2014 4:36:24 pm Hans Petter Selasky wrote:
> On 06/18/14 15:44, John Baldwin wrote:
> > On Wednesday, June 18, 2014 7:36:53 am Hans Petter Selasky wrote:
> >> Hi,
> >>
> >> Sometimes sysctl's default value needs to be setup at boot time and not
> >> when the rc.d/sysctl is running. Currently this is done by having two
> >> statements in the kernel:
> >>
> >> TUNABLE_INT("net.graph.mppe.log_max_rekey", &mppe_log_max_rekey);
> >> SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RW,
> >>
> >> I want to simplify this to:
> >>
> >> SYSCTL_INT(_net_graph_mppe, OID_AUTO, log_max_rekey, CTLFLAG_RWTUN,
> >>
> >> In other words if the existing CTLFLAG_TUN is set, the sysctl will
> >> automatically be pre-loaded with values from /boot/loader.conf.
> >>
> >> The reason we don't want the current approach is:
> >>
> >> 1) It duplicates the sysctl path in the TUNABLE statement.
> >> 2) It does not work very well for dynamically attached sysctls. There is
> >> a lot of code overhead computing the TUNABLE() path before the TUNABLE()
> >> can be fetched.
> >>
> >> Here is a work in progress:
> >>
> >> http://home.selasky.org:8192/sysctl_tunable.diff
> >>
> >> In most cases my patch is fine, but in some other cases I need some
> >> input, like in the VM subsystem when doing init, I'm not sure if the
> >> SYSINIT() for subsystem SI_SUB_KMEM, which sysctl's are using, has
> >> already been executed.
> >
> > I think this is a good idea, but it's also true you can just leave separate
> > TUNABLE_ statements without setting the CTLFLAG_TUN flag for cases you
> > aren't
> > sure about for now. It probably makes sense to do these changes in stages.
> >
> > I was going to suggest using sbuf() for building the tunable name, but that
> > doesn't work since you have to build it in reverse.
> >
>
> Hi,
>
> After going through a lot of existing code, I've decided to make a new
> flag, CTLFLAG_FETCH rather than overload CTLFLAG_TUN, so that the new
> functionality can be added to drivers and tested. For example sysctls
> which implement function callbacks and are not trivial, this might cause
> locking of non-initialized mutexes and so on. And also I see some
> dependencies, that values are fetched at a certain point in the boot
> process and that existing CTLFLAG_TUN might confuse existing logic.
>
> I've updated my patch (same link):
>
> http://home.selasky.org:8192/sysctl_tunable.diff
>
> BTW: Can someone which have a beefy machine run a universe with this
> patch applied?
>
> I'll probably put it into the tree next week.
I think having CTLFLAG_TUN do this by default is probably correct in the
long term. The vast majority of places that use a tunable to prime a sysctl
are safe. Why not do this for the initial patch:
- Add your change to auto-fetch values when CTLFLAG_TUN is set.
- Instead of adding a CTLFLAG_FETCH, add a CTLFLAG_NOFETCH to disable
getenv().
- Make a pass over the existing places that use CTLFLAG_TUN seeing which
ones are safe (so TUNABLE_* can just be removed), and which ones aren't
(in which case add CTLFLAG_NOFETCH).
Followup changes can work on converting other places that don't currently
use CTLFLAG_TUN but have a SYSCTL + TUNABLE to use CTLFLAG_TUN instead as
well as fixing places that use CTLFLAG_NOFETCH to not need them.
I would suggest you commit some of the style changes (like using explicit
initializers in SYSCTL_OID()) as a separate change beforehand.
--
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: Problems building FreeBSD 9.2 on FreeBSD 10
On Tue, Jun 17, 2014 at 11:59 PM, Dimitry Andric 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. -- Craig ___ 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: fsck bug in replaying partial frag truncate journal on UFS SU+J?
Hello,
I kept analysis of the problem which I reported previously and found how to fix
this problem.
(patch in my previou report is wrong.).
My understanding is there is a rule that blkno of JOP_FREEBLK or JOP_NEWBLK
must be the first
position in UFS block for each inode, for fsck_ffs's suj.c seems to support
only such a case. But
there is a case that kernel does create a JOP_FREEBLK journal which is not in
this rule. The case is
small file's partial frag truncation.
Bellow I attached a patch to fix this problem.
Adding new argument frags_offset for newfreework() to adjust for calling
newjfreeblk(). New argument
frags_offset is used by only softdep_journal_freeblocks()
diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
index 4d0442b..2f2f063 100644
--- a/sys/ufs/ffs/ffs_softdep.c
+++ b/sys/ufs/ffs/ffs_softdep.c
@@ -1012,7 +1012,7 @@ staticvoid cancel_jfreeblk(struct freeblks *,
ufs2_daddr_t);
static struct jfreefrag *newjfreefrag(struct freefrag *, struct inode *,
ufs2_daddr_t, long, ufs_lbn_t);
static struct freework *newfreework(struct ufsmount *, struct freeblks *,
- struct freework *, ufs_lbn_t, ufs2_daddr_t, int, int, int);
+ struct freework *, ufs_lbn_t, ufs2_daddr_t, int, int, int, int);
static int jwait(struct worklist *, int);
static struct inodedep *inodedep_lookup_ip(struct inode *);
static int bmsafemap_backgroundwrite(struct bmsafemap *, struct buf *);
@@ -3996,7 +3996,7 @@ free_freedep(freedep)
* is visible outside of softdep_setup_freeblocks().
*/
static struct freework *
-newfreework(ump, freeblks, parent, lbn, nb, frags, off, journal)
+newfreework(ump, freeblks, parent, lbn, nb, frags, off, journal, frags_offset)
struct ufsmount *ump;
struct freeblks *freeblks;
struct freework *parent;
@@ -4005,6 +4005,7 @@ newfreework(ump, freeblks, parent, lbn, nb, frags, off,
journal)
int frags;
int off;
int journal;
+ int frags_offset;
{
struct freework *freework;
@@ -4022,7 +4023,7 @@ newfreework(ump, freeblks, parent, lbn, nb, frags, off,
journal)
? 0 : NINDIR(ump->um_fs) + 1;
freework->fw_start = freework->fw_off = off;
if (journal)
- newjfreeblk(freeblks, lbn, nb, frags);
+ newjfreeblk(freeblks, lbn, nb - frags_offset, frags +
frags_offset);
if (parent == NULL) {
ACQUIRE_LOCK(&lk);
WORKLIST_INSERT(&freeblks->fb_freeworkhd, &freework->fw_list);
@@ -5958,7 +5959,7 @@ setup_freedirect(freeblks, ip, i, needj)
DIP_SET(ip, i_db[i], 0);
frags = sblksize(ip->i_fs, ip->i_size, i);
frags = numfrags(ip->i_fs, frags);
- newfreework(ip->i_ump, freeblks, NULL, i, blkno, frags, 0, needj);
+ newfreework(ip->i_ump, freeblks, NULL, i, blkno, frags, 0, needj, 0);
}
static inline void
@@ -5977,7 +5978,7 @@ setup_freeext(freeblks, ip, i, needj)
ip->i_din2->di_extb[i] = 0;
frags = sblksize(ip->i_fs, ip->i_din2->di_extsize, i);
frags = numfrags(ip->i_fs, frags);
- newfreework(ip->i_ump, freeblks, NULL, -1 - i, blkno, frags, 0, needj);
+ newfreework(ip->i_ump, freeblks, NULL, -1 - i, blkno, frags, 0, needj,
0);
}
static inline void
@@ -5995,7 +5996,7 @@ setup_freeindir(freeblks, ip, i, lbn, needj)
return;
DIP_SET(ip, i_ib[i], 0);
newfreework(ip->i_ump, freeblks, NULL, lbn, blkno, ip->i_fs->fs_frag,
- 0, needj);
+ 0, needj, 0);
}
static inline struct freeblks *
@@ -6111,7 +6112,7 @@ setup_trunc_indir(freeblks, ip, lbn, lastlbn, blkno)
if (off + 1 == NINDIR(ip->i_fs))
goto nowork;
freework = newfreework(ip->i_ump, freeblks, NULL, lbn, blkno, 0, off+1,
- 0);
+ 0, 0);
/*
* Link the freework into the indirdep. This will prevent any new
* allocations from proceeding until we are finished with the
@@ -6437,7 +6438,8 @@ softdep_journal_freeblocks(ip, cred, length, flags)
oldfrags = numfrags(ip->i_fs, oldfrags);
blkno += numfrags(ip->i_fs, frags);
newfreework(ip->i_ump, freeblks, NULL, lastlbn,
- blkno, oldfrags, 0, needj);
+ blkno, oldfrags, 0, needj,
+ numfrags(ip->i_fs, frags));
} else if (blkno == 0)
allocblock = 1;
}
@@ -7737,7 +7739,7 @@ handle_workitem_freeblocks(freeblks, flags)
FREE_LOCK(&lk);
freework = newfreework(ump, freeblks, NULL,
aip->ai_lbn, aip->ai_newblkno,
- ump->um_fs->fs_frag, 0, 0);
+ ump->um_fs->fs_frag, 0, 0, 0);
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 18, 2014, at 12:59 AM, Dimitry Andric wrote: > On 18 Jun 2014, at 01:33, Craig Rodrigues wrote: >> On Tue, Jun 17, 2014 at 2:54 PM, Craig Rodrigues wrote: >>> On Tue, Jun 17, 2014 at 2:14 PM, Glen Barber wrote: For what it is worth, I'm working around this problem by running: # make make buildworld -jN [...] Note the extra 'make', which rather than relying on the bootstrap-tools to determine which make to build, I am specifically telling it to build fmake. >>> >>> >>> Nice! That works! >>> Thanks. >>> >>> -- >>> Craig >> >> >> Oops, that got me a bit farther, but further along, things failed for me >> with: > ... >> echo gperf: /usr/lib/libstdc++.a >> .depend >> ===> gnu/usr.bin/gperf/doc (depend) >> make: don't know how to make /usr/lib/libstdc++.a. Stop > > 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. :-/ Really? I thought I’d prevent to myself that it was redundant in all cases, at least in -current. I didn’t think I’d merged back any of the early_build stuff into 10... I’ll take a look at this though... Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 18, 2014, at 4:32 PM, Craig Rodrigues wrote: > On Tue, Jun 17, 2014 at 11:59 PM, Dimitry Andric 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. The EARLY_BUILD flag tightly coupled the bsd.*.mk files to the build system, so I’l like to see it stay dead. 9.x assumes that by defining it, it can affect the system installed .mk files in a specific way. This is an unwise assumption, as this thread demonstrates. The real problem, imho, is that the construct in bsd.prog.mk is generating a dependency on the wrong C++ standard library. Why is it generating for the g++ library when the compiler is clang? That seems like the real bug here. I’ll also note that building release X-2 on head isn’t generally supported by the project, but having said that, I’ll see what I can do. Surprisingly, I don’t have a good -current environment setup on my fast build boxes, so I’ll setup a quick jail and see if I can recreate. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [RFC] Huge sysctl patch for the kernel coming - work in progress
On 06/18/14 23:13, John Baldwin wrote: On Wednesday, June 18, 2014 4:36:24 pm Hans Petter Selasky wrote: On 06/18/14 15:44, John Baldwin wrote: On Wednesday, June 18, 2014 7:36:53 am Hans Petter Selasky wrote: Hi, I'll probably put it into the tree next week. I think having CTLFLAG_TUN do this by default is probably correct in the long term. The vast majority of places that use a tunable to prime a sysctl are safe. Why not do this for the initial patch: - Add your change to auto-fetch values when CTLFLAG_TUN is set. - Instead of adding a CTLFLAG_FETCH, add a CTLFLAG_NOFETCH to disable getenv(). - Make a pass over the existing places that use CTLFLAG_TUN seeing which ones are safe (so TUNABLE_* can just be removed), and which ones aren't (in which case add CTLFLAG_NOFETCH). Followup changes can work on converting other places that don't currently use CTLFLAG_TUN but have a SYSCTL + TUNABLE to use CTLFLAG_TUN instead as well as fixing places that use CTLFLAG_NOFETCH to not need them. I would suggest you commit some of the style changes (like using explicit initializers in SYSCTL_OID()) as a separate change beforehand. Hi, See: http://svnweb.freebsd.org/changeset/base/267633 And updated patch: http://home.selasky.org:8192/sysctl_tunable.diff --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: [patch] USB after second suspend/resume on ThinkPads.
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: 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"
