"Steven Hartland" <kill...@multiplay.co.uk> wrote:

> From: "Fabian Keil" <freebsd-lis...@fabiankeil.de>
> > After updating my laptop to yesterday's CURRENT (r265216),
> > I got the following fatal double fault on boot:
> > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r265216/
> > 
> > My previous kernel was based on r264721.
> >
> > I'm using a couple of custom patches, some of them are ZFS-related
> > and thus may be part of the problem (but worked fine for months).
> > I'll try to reproduce the panic without the patches tomorrow.
> >
> Your seeing a stack overflow in the new ZFS queuing code, which I
> believe is being triggered by lack of support for TRIM in one of
> your devices, something Xin reported to me yesterday.
> I commited a fix for failing TRIM requests processing slowly last
> night so you could try updating to after r265253 and see if that
> helps.

Thanks. The hard disk is indeed unlikely to support TRIM requests,
but I can still reproduce the problem with a kernel based on r265255.

> I still need to investigate the stack overflow more directly which
> appears to be caused by the new zfs queuing code when things are
> running slowly and there's a large backlog of IO's.
> I would be interested to know you config there so zpool layout and
> hardware in the mean time.

The system is a Lenovo ThinkPad R500:

I'm booting from UFS, the panic occurs while the pool is being imported.

The pool is located on a single geli-encrypted slice:

fk@r500 ~ $zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0 in 4h11m with 0 errors on Sat Mar 22 18:25:01 2014

        NAME           STATE     READ WRITE CKSUM
        tank           ONLINE       0     0     0
          ada0s1d.eli  ONLINE       0     0     0

errors: No known data errors

Maybe geli fails TRIM requests differently.


Attachment: signature.asc
Description: PGP signature

Reply via email to