On 13 Oct 2010, at 18:46, Ryan Stone wrote:
On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson rwat...@freebsd.org wrote:
+ /*
+* get and fill a header mbuf, then chain data as an
extended
+* mbuf.
+*/
+ MGETHDR(m,
2010/10/14 Robert N. M. Watson rwat...@freebsd.org:
On 13 Oct 2010, at 18:46, Ryan Stone wrote:
On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson rwat...@freebsd.org wrote:
+ /*
+ * get and fill a header mbuf, then chain data as an
extended
+ * mbuf.
On 14 Oct 2010, at 15:10, Attilio Rao wrote:
My concern is less about occasional lost dumps that destabilising the
dumping process: calls into the memory allocator can currently trigger a lot
of interesting behaviours, such as further calls back into the VM system,
which can then trigger
2010/10/14 Robert N. M. Watson rwat...@freebsd.org:
On 14 Oct 2010, at 15:10, Attilio Rao wrote:
My concern is less about occasional lost dumps that destabilising the
dumping process: calls into the memory allocator can currently trigger a
lot of interesting behaviours, such as further
on 13/10/2010 21:43 Andriy Gapon said the following:
Further walking child zio hierarchy we reach the one that looks like this:
$59 = {io_bookmark = {zb_objset = 400, zb_object = 0, zb_level = -1, zb_blkid
=
22437}, io_prop = {zp_checksum = ZIO_CHECKSUM_INHERIT, zp_compress =
Hi,
Anyone out there experiencing so-called EHCI-hangs, can try applying the
following patch by hand:
http://p4web.freebsd.org/@@184749?ac=10
//depot/projects/usb/src/sys/dev/usb/controller/ehci.c#62 (text+ko)
@@ -1589,6 +1589,10 @@
usb_callout_reset(sc-sc_tmo_pcd,
