on 06/02/2012 07:52 Julian Elischer said the following:
so if I'm sitting still in the debugger for too long, a hardclock
event happens that goes into ULE, which then hits the following KASSERT.
KASSERT(pri = PRI_MIN_BATCH pri = PRI_MAX_BATCH,
On Mon, Feb 06, 2012 at 01:19:30PM -0800, Dmitry Mikulin wrote:
I see what is going on. The wait loop for P_PPWAIT in do_fork() simply
do not allow the ptracestop() in the syscall return path to be reached.
There seems to be more problems. In particular, I do not see anything
which would
On 06/02/2012 18:24, JD wrote:
dmesg no longer outputs the kernel messages.
$ dmesg
$
$ which dmesg
/sbin/dmesg
$what /sbin/dmesg
/sbin/dmesg:
So, I have no idea what version of dmesg got installed.
Anyone on 9.0 Release have this problem? How to fix it?
I thought this was by design, I've
-Original Message-
From: Stas Orlov [mailto:senn...@gmail.com]
Sent: Monday, February 06, 2012 11:54 PM
To: Desai, Kashyap
Cc: Kenneth D. Merry; freebsd-s...@freebsd.org; freebsd-
curr...@freebsd.org; Dennis Glatting
Subject: Re: LSI supported mps(4) driver available
Sorry for
Can you to reproduce issue with below mentioned changes..
In mps.c
mps_get_tunables(struct mps_softc *sc)
{
char tmpstr[80];
/* XXX default to some debugging for now */
sc-mps_debug = MPS_FAULT;
Instead of above line make
sc-mps_debug = 0xd;
This will dump debug prints on
On Tue, Feb 07, 2012 at 21:00:28 +0530, Desai, Kashyap wrote:
Can you to reproduce issue with below mentioned changes..
In mps.c
mps_get_tunables(struct mps_softc *sc)
{
char tmpstr[80];
/* XXX default to some debugging for now */
sc-mps_debug = MPS_FAULT;
Instead of
On Monday, February 06, 2012 10:12:11 pm David Xu wrote:
On 2012/1/26 7:48, Dmitry Mikulin wrote:
snip
The debugger needs to intercept fork() in both parent and child so it
can detach from the old process and attach to the new one. Maybe it'll
make more sense in the context of gdb
On Monday, February 06, 2012 12:52:58 am Julian Elischer wrote:
so if I'm sitting still in the debugger for too long, a hardclock
event happens that goes into ULE, which then hits the following KASSERT.
KASSERT(pri = PRI_MIN_BATCH pri = PRI_MAX_BATCH,
So, do you in fact need to distinguish exec stops from syscall exit
against exec stops from PT_FOLLOW_EXEC,
This is pretty much what I need. It's the same stop in syscall return right? I
don't want to change when the stop happens, I want to have an lwpinfo flag that
tells me when a stop
Dear All ,
At present ,
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/
is empty ,
and ,
http://pub.allbsd.org/FreeBSD-snapshots/
amd64 , head is prepared without
ports.txz .
To download a snapshot and test Current ( 10.0 ) , without ports seems to
be not possible .
Well, that didn't work... Not sure why since it broke existing gdb. My guess is
we're not getting the exec stops we used to get. Might have to wait till
tomorrow to get more details.
On 02/07/2012 12:45 PM, Dmitry Mikulin wrote:
So, do you in fact need to distinguish exec stops from
Hi All,
Please find the 10Gb Ethernet NIC driver for Emulex OneConnect
(BladeEngine) and Lancer family of network adapters at
http://info.iet.unipi.it/~luigi/20120207-emulex-nic.tgzhttps://iwebmail.emulex.com/OWA/redir.aspx?C=fc4deb7ba3ea44aa8034c6a14f2f59f6URL=http%3a%2f%2finfo.iet.unipi.it
Any plans for iscsi, fcoe?
Hi All,
Please find the 10Gb Ethernet NIC driver for Emulex OneConnect
(BladeEngine) and Lancer family of network adapters at
http://info.iet.unipi.it/~luigi/20120207-emulex-nic.tgzhttps://iwebmail.emulex.com/OWA/redir.aspx?C=fc4deb7ba3ea44aa8034c6a14f2f59f6URL
13 matches
Mail list logo
