On Tue, Jun 21, 2011 at 07:55:37AM +0100, David Laight wrote:
> On Mon, Jun 20, 2011 at 04:29:05PM -0700, Brian Buhrow wrote:
>
> > For reference, I used the ktrcanset() function from kern_ktrace.c from
> > NetBSD-3.0 sources because it was easier to read than following the chain
> > of layers dow
On Tue, 21 Jun 2011, der Mouse wrote:
> It does, however, appear to have something to do with the hardware
> (personally, I suspect the disk driver); if I try it on another 4.0.1
> machine on vnd0d backed by an ordinary file, it doesn't misbehave, and
> if I try it on a real disk partition on that
>> It does, however, appear to have something to do with the hardware
>> [...]
> It's most likely the controller hardware (or firmware). The driver
> doesn't seem at all interested in the data alignment, and I don't
> recall other parts of the I/O stack caring.
That sounds reasonable.
> To verif
On Tue, Jun 21, 2011 at 02:16:18AM -0400, der Mouse wrote:
> I've just run into something (on 4.0.1) which looks to me as though
> write() buffer alignment matters. This sounds to me like a bug, but it
> appears to have something to do with the hardware, and I'd appreciate
> any thoughts on how I
On Tue, Jun 21, 2011 at 12:03:10PM -0400, der Mouse wrote:
>
> Actually, I got the machine from a friend-of-a-friend who was a pretty
> hardcore SCSI geek in a former life (he now repairs organs, the musical
> kind). He would probably be the right person to ask about this; it's
> not totally impl
Hello. I agree. AFter I figured out what was where, I think the
secmodel code is far easier to maintain. But, getting my head around
things in a hurry for this one case meant it was easier for me to look at
the code when it was in a simpler state.
-Brian
On Jun 21, 9:19am, Thor Lancelot
> It's a 53c8xx: we load the "firmware" into it from our own driver.
I just had a look at esiop.ss, and it looks high-level enough that it's
plausible to me that the problem is with whatever's backing that code,
whether silicon or ROMed firmware or whatever.
I've sent an email to the relevant pe
On Fri, Jun 17, 2011 at 12:34:53PM +0200, Manuel Bouyer wrote:
> On Fri, Jun 17, 2011 at 12:24:13PM +0200, Adam Hamsik wrote:
> >
> > On Jun,Thursday 16 2011, at 5:30 PM, Mindaugas Rasiukevicius wrote:
> > > - DDB_ONPANIC=1 and DDB_COMMANDONENTER="bt;show regsisters" and perhaps
> > > also "call
On Thu, Jun 16, 2011 at 07:49:43PM +0200, Manuel Bouyer wrote:
> > I'm not in favor of LOCKDEBUG by default, for reasons already stated here.
>
> Also, could LOCKDEBUG have ABI issues with modules ?
> I've only ever used LOCKDEBUG with non-MODULAR kernels ...
The whole reason LOCKDEBUG is aby
We got a new NFS server at work over the weekend, and it's been a bit
flaky and causing my machines to hang left and right. In the course of
poking about with ddb and crash I've found no less than three
problems:
(1) The syncer holds syncer_mutex while calling VOP_FSYNC. If
VOP_FSYNC goes off to p
On Tue, 21 Jun 2011, der Mouse wrote:
It's a 53c8xx: we load the "firmware" into it from our own driver.
I just had a look at esiop.ss, and it looks high-level enough that it's
plausible to me that the problem is with whatever's backing that code,
whether silicon or ROMed firmware or whatever
>>> It's a 53c8xx: we load the "firmware" into it from our own driver.
>> I just had a look at esiop.ss, and it looks high-level enough that
>> it's plausible to me that the problem is with whatever's backing
>> that code, whether silicon or ROMed firmware or whatever.
> I just verified that I see
FWIW, i much prefer using DDB_ONPANIC=2 than setting the enter command
to "bt". unfortunately only options(4) meantions this, not sysctl(4)
or ddb(4).
.mrg.
13 matches
Mail list logo
