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,
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 =
> ZIO_COMPRES
2010/10/14 Robert N. M. Watson :
>
> 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
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 t
2010/10/14 Robert N. M. Watson :
>
> On 13 Oct 2010, at 18:46, Ryan Stone wrote:
>
>> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote:
>>> + /*
>>> + * get and fill a header mbuf, then chain data as an
>>> extended
>>> + * mbuf.
>>> +
On 13 Oct 2010, at 18:46, Ryan Stone wrote:
> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote:
>> + /*
>> +* get and fill a header mbuf, then chain data as an
>> extended
>> +* mbuf.
>> +*/
>> + MGETHDR(m, M_DONTWAIT
