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.tgz<https://iwebmail.emulex.com/OWA/redir.aspx?C=fc4deb7ba3ea44aa8034c6a14f2f59f6&
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.tgz<https://iwebmail.emulex.com/OWA/redir.aspx?C=fc4deb7ba3ea44aa8034c6a14f2f59f6&URL=http%3a%2f%2finfo.iet.u
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 syscal
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 .
W
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 occ
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,
>
On Monday, February 06, 2012 10:12:11 pm David Xu wrote:
> On 2012/1/26 7:48, Dmitry Mikulin wrote:
> >
>
> > 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 gd
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;
>
>
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
> -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
>
> So
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 no
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 w
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,
> (
13 matches
Mail list logo
