[PATCH] Minor spelling error in sound/pci/hda
Only a simple spelling error, but it's been driving me nuts...
--- a/sys/dev/sound/pci/hda/hdaa.c
+++ b/sys/dev/sound/pci/hda/hdaa.c
@@ -557,7 +557,7 @@ hdaa_presence_handler(struct hdaa_widget *w)
HDA_BOOTVERBOSE(
if (connected || old != 2) {
device_printf(devinfo-dev,
- Pin sense: nid=%d sence=0x%08x (%sconnected)\n,
+ Pin sense: nid=%d sense=0x%08x (%sconnected)\n,
w-nid, res, !connected ? dis : );
}
);
@@ -706,7 +706,7 @@ hdaa_eld_handler(struct hdaa_widget *w)
}
HDA_BOOTVERBOSE(
device_printf(devinfo-dev,
- Pin sense: nid=%d sence=0x%08x
+ Pin sense: nid=%d sense=0x%08x
(%sconnected, ELD %svalid)\n,
w-nid, res,
(res HDA_CMD_GET_PIN_SENSE_PRESENCE_DETECT) ? : dis,
--
Sorry for the following...
The information contained in this message is confidential and intended for the
addressee only. If you have received this message in error, or there are any
problems with its content, please contact the sender.
iCritical is a trading name of Critical Software Ltd. Registered in England:
04909220.
Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH.
This message has been scanned for security threats by iCritical.
www.icritical.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
[PATCH] USB power usage reporting
The following patch adds the ability to read power draw on usb devices.
I have used ioctl 135. I don't know what the protocol is for assigning
numbers, so this may be unacceptable?
ugen is patched to export the data via ioctl
libusb20 and usbconfig are patched to make use of it (end-of-line):
[mattb@falcon ~]$ usbconfig
ugen0.1: EHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen1.1: XHCI root HUB 0x1b21 at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=SAVE (0mA)
ugen2.1: XHCI root HUB 0x1b21 at usbus2, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=SAVE (0mA)
ugen3.1: EHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen0.2: product 0x0024 vendor 0x8087 at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen3.2: product 0x0024 vendor 0x8087 at usbus3, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen3.3: Dell USB Keyboard Dell at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps)
pwr=ON (70mA)
ugen3.4: Gaming Mouse G400 Logitech at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (98mA)
ugen3.5: Dell 1130 Laser Printer Dell at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (0mA)
ugen3.6: product 0x3000 vendor 0x0cf3 at usbus3, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON (100mA)
diff --git a/lib/libusb/libusb20.3 b/lib/libusb/libusb20.3
index af80c6c..8753e06 100644
--- a/lib/libusb/libusb20.3
+++ b/lib/libusb/libusb20.3
@@ -149,6 +149,8 @@ USB access library (libusb -lusb)
.Fn libusb20_dev_set_power_mode struct libusb20_device *pdev uint8_t
power_mode
.Ft uint8_t
.Fn libusb20_dev_get_power_mode struct libusb20_device *pdev
+.Ft uint16_t
+.Fn libusb20_dev_get_power_usage struct libusb20_device *pdev
.Ft int
.Fn libusb20_dev_set_alt_index struct libusb20_device *pdev uint8_t
iface_index uint8_t alt_index
.Ft struct LIBUSB20_DEVICE_DESC_DECODED *
@@ -740,6 +742,11 @@ USB device.
.
.Pp
.
+.Fn libusb20_dev_get_power_usage
+returns the reported power usage in milliamps for the given USB device.
+.
+.Pp
+.
.Fn libusb20_dev_set_alt_index
will try to set the given alternate index for the given
USB interface index.
diff --git a/lib/libusb/libusb20.c b/lib/libusb/libusb20.c
index aa45991..ce75511 100644
--- a/lib/libusb/libusb20.c
+++ b/lib/libusb/libusb20.c
@@ -71,6 +71,7 @@ dummy_callback(struct libusb20_transfer *xfer)
#definedummy_check_connected (void *)dummy_int
#definedummy_set_power_mode (void *)dummy_int
#definedummy_get_power_mode (void *)dummy_int
+#definedummy_get_power_usage (void *)dummy_int
#definedummy_kernel_driver_active (void *)dummy_int
#definedummy_detach_kernel_driver (void *)dummy_int
#definedummy_do_request_sync (void *)dummy_int
@@ -717,6 +718,18 @@ libusb20_dev_get_power_mode(struct libusb20_device *pdev)
return (power_mode);
}
+uint16_t
+libusb20_dev_get_power_usage(struct libusb20_device *pdev)
+{
+ int error;
+ uint16_t power_usage;
+
+ error = pdev-methods-get_power_usage(pdev, power_usage);
+ if (error)
+ power_usage = 0;
+ return (power_usage);
+}
+
int
libusb20_dev_set_alt_index(struct libusb20_device *pdev, uint8_t ifaceIndex,
uint8_t altIndex)
{
diff --git a/lib/libusb/libusb20.h b/lib/libusb/libusb20.h
index 87e0572..81928b1 100644
--- a/lib/libusb/libusb20.h
+++ b/lib/libusb/libusb20.h
@@ -255,6 +255,7 @@ int libusb20_dev_reset(struct libusb20_device *pdev);
intlibusb20_dev_check_connected(struct libusb20_device *pdev);
intlibusb20_dev_set_power_mode(struct libusb20_device *pdev, uint8_t
power_mode);
uint8_tlibusb20_dev_get_power_mode(struct libusb20_device *pdev);
+uint16_t libusb20_dev_get_power_usage(struct libusb20_device *pdev);
intlibusb20_dev_set_alt_index(struct libusb20_device *pdev, uint8_t
iface_index, uint8_t alt_index);
intlibusb20_dev_get_info(struct libusb20_device *pdev, struct
usb_device_info *pinfo);
intlibusb20_dev_get_iface_desc(struct libusb20_device *pdev, uint8_t
iface_index, char *buf, uint8_t len);
diff --git a/lib/libusb/libusb20_int.h b/lib/libusb/libusb20_int.h
index 0251c5f..6705c63 100644
--- a/lib/libusb/libusb20_int.h
+++ b/lib/libusb/libusb20_int.h
@@ -105,6 +105,7 @@ typedef int (libusb20_process_t)(struct libusb20_device
*pdev);
typedef int (libusb20_reset_device_t)(struct libusb20_device *pdev);
typedef int (libusb20_set_power_mode_t)(struct libusb20_device *pdev, uint8_t
power_mode);
typedef int (libusb20_get_power_mode_t)(struct libusb20_device *pdev, uint8_t
*power_mode);
+typedef int (libusb20_get_power_usage_t)(struct libusb20_device *pdev,
uint16_t *power_usage);
typedef int (libusb20_set_alt_index_t)(struct libusb20_device *pdev, uint8_t
iface_index, uint8_t alt_index);
typedef int (libusb20_set_config_index_t)(struct libusb20_device *pdev,
uint8_t index);
typedef int (libusb20_check_connected_t)(struct libusb20_device *pdev);
@@ -127,6 +128,7 @@ typedef void
[patch] Userland DTrace
I've been spending some time trying to get the fasttrap provider to work
on FreeBSD without panicing. I believe I have succeeded, at least to the
point where it's no longer panicing.
There were two panic causes. The first was
http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
fasttrap.c caused ftp_rcount to be left 0. To fix this I've got rid of
the early return and reverted to the opensolaris way.
A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
was run while something in userland had locks. Using sx_try_xlock calls
has stopped the panics and shouldn't affect operation AFAICT.
This is against r246454.
Although this has fixed the panics for me, I'm finding a lot of stuff just
isn't actually working, with dtrace and the traced process just chewing
CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
have no idea what the target is doing... CPU time is split 2:1
dtrace:target
Also noteworthy is the LOR on the first time you try to use the fasttrap
provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479
The lock order there seems right, so I'm guessing something else must
have done it wrong first? How can I find out what the something else
is?
Thanks
--- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
@@ -7536,9 +7536,23 @@ dtrace_unregister(dtrace_provider_id_t id)
return (EBUSY);
}
} else {
+#if defined(sun)
mutex_enter(dtrace_provider_lock);
mutex_enter(mod_lock);
mutex_enter(dtrace_lock);
+#else
+ if (sx_try_xlock(dtrace_provider_lock) == 0)
+ return (EBUSY);
+ if (sx_try_xlock(mod_lock) == 0) {
+ mutex_exit(dtrace_provider_lock);
+ return (EBUSY);
+ }
+ if (sx_try_xlock(dtrace_lock) == 0) {
+ mutex_exit(mod_lock);
+ mutex_exit(dtrace_provider_lock);
+ return (EBUSY);
+ }
+#endif
}
/*
--- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
@@ -1116,23 +1116,28 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
ASSERT(id == probe-ftp_id);
- mutex_enter(provider-ftp_mtx);
-
/*
* We won't be able to acquire a /proc-esque lock on the process
* iff the process is dead and gone. In this case, we rely on the
* provider lock as a point of mutual exclusion to prevent other
* DTrace consumers from disabling this probe.
*/
- if ((p = pfind(probe-ftp_pid)) == NULL) {
- mutex_exit(provider-ftp_mtx);
- return;
+
+#if defined(sun)
+ if ((p = sprlock(probe-ftp_pid)) != NULL) {
+ ASSERT(!(p-p_flag SVFORK));
+ mutex_exit(p-p_lock);
+ }
+#else
+ if ((p = pfind(probe-ftp_pid)) != NULL) {
+ _PHOLD(p);
+ PROC_UNLOCK(p);
}
-#ifdef __FreeBSD__
- _PHOLD(p);
- PROC_UNLOCK(p);
#endif
+ mutex_enter(provider-ftp_mtx);
+
+
/*
* Disable all the associated tracepoints (for fully enabled probes).
*/
@@ -1154,6 +1159,13 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
if (provider-ftp_retired !provider-ftp_marked)
whack = provider-ftp_marked = 1;
mutex_exit(provider-ftp_mtx);
+
+#if defined(sun)
+ mutex_enter(p-p_lock);
+ sprunlock(p);
+#else
+ PRELE(p);
+#endif
} else {
/*
* If the process is dead, we're just waiting for the
@@ -1167,9 +1179,6 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
if (whack)
fasttrap_pid_cleanup();
-#ifdef __FreeBSD__
- PRELE(p);
-#endif
if (!probe-ftp_enabled)
return;
--
Sorry for the following...
The information contained in this message is confidential and intended for the
addressee only. If you have received this message in error, or there are any
problems with its content, please contact the sender.
iCritical is a trading name of Critical Software Ltd. Registered in England:
04909220.
Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH.
This message has been scanned for security threats by iCritical.
www.icritical.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
Re: installworld failure due to cross-device links
On 01/02/13 13:26, Nathan Whitehorn wrote: Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. Similarly, 'make distribution' fails when /root is a separate filesystem: cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.profile /tmproot/root/.profile; rm -f /tmproot/.profile; ln /tmproot/root/.profile /tmproot/.profile ln: /tmproot/.profile: Cross-device link *** [distribution] Error code 1 Is there any real advantage of hard links over symlinks nowadays? -- Sorry for the following... The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.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
Re: ZFS boot fails with two pools
On 07/06/11 16:44, Berczi Gabor wrote: For some reason FreeBSD can't boot automatically: ... I have two pools, pool2 which is a mirrored zpool, and data being a raid-z pool. Note how the default should be pool2:/boot/zfsloader. How can I fix this? The following applies to 8-STABLE from 2011-06-29. I believe -CURRENT may be identical, but don't know for certain. From what I could tell from researching my similar problem (*), you can ignore the zpool bootfs property as well as the gpt bootme flag - they're not looked at by the boot process, at least not before the stage 3 loader. What happens is gptzfsboot simply tries to boot from the first zfs pool it finds. The only control you have is that the first drive it scans is the one it boots from. If the BIOS booted from the disk with the raid-z pool, or if there is something like a log partition for your raid-z pool before your boot pool on the disk (fixed with my patch), then gptzfsboot will try to load /boot/zfsloader from the raid-z pool, whether or not it can see enough vdevs to actually use the pool. If it can't run zfsloader it'll pointlessly try /boot/kernel/kernel from it before dumping you at the boot: prompt. That is why you see the Default showing as it does - it's more Last tried than Default. My advice is to double-check which drive your BIOS is booting from (make sure it's one with 'pool2' on it), and if you've got a partition belonging to your 'data' pool on the disk (log, cache, etc), you could try rebuilding gptzfsboot with my patch providing you're aware that it's untested by anyone other than myself and by using it you risk causing irreparable damage to your pools. I hope not seeing as I'm running it myself, but I've had no feedback on it. (*) http://lists.freebsd.org/pipermail/freebsd-fs/2011-June/011882.html HTH, Matt. ___ 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
