On 1/30/11 10:31 PM, Eugene Grosbein wrote:
On 15.01.2011 01:37, John Baldwin wrote:
On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote:
On 14.01.2011 18:46, Mike Tancsa wrote:
I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE
concurrent sessions. Routers are
On 31.01.2011 14:20, Julian Elischer wrote:
>> # gdb kernel
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
Pyun YongHyeon (pyu...@gmail.com) [11.01.31 04:08] wrote:
> > The RTL8168/8111D sample board I have does not show this kind of
> > issue. This happens only when established link is 1000baseT, right?
> > I slightly changed PHY's link detection code so would you try that
> > patch at the following UR
On Mon, 31 Jan 2011, Eugene Grosbein wrote:
On 31.01.2011 14:20, Julian Elischer wrote:
# gdb kernel
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies
Hello,
I attach the latest version of the port randomization code as a patch
against RELENG_8.
Changelog:
1) sysctl variable names are changed to:
- 'net.inet.ip.portrange.randomalg.version' - representing the
algorithm of choice.
- 'net.inet.ip.portrange.randomalg.alg5_tradeoff' - representing t
On Fri, Jan 14, 2011 at 10:05:31AM +0100, Przemyslaw Frasunek wrote:
P> Hello,
P>
P> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE
P> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms
and
P> runs FreeBSD 7.3-RELEASE.
P>
P> I'm experiencing sta
> In this dump, can we seek for where did 0x74 came from? Can you look at
> ng_name_hash[hash]?
(kgdb) print hash
No symbol "hash" in current context.
(kgdb) info all
eax0xff9a -102
ecx0xe7ce6895 -405903211
edx0xff9a -102
ebx
On Mon, Jan 31, 2011 at 02:40:55PM +0100, Przemyslaw Frasunek wrote:
P> > In this dump, can we seek for where did 0x74 came from? Can you look at
P> > ng_name_hash[hash]?
P>
P> (kgdb) print hash
P> No symbol "hash" in current context.
P> (kgdb) info all
P> eax0xff9a -102
P> e
I might be fighting a losing battle, but any advice on getting the Broadcom
BCM4322 802.11a/b/g/n working? This chip is found in Apple's MacBook and
probably elsewhere.
I'm currently running amd64 8.2-RC2. As best as I can see, HEAD has nothing
that RELENG_8_2 doesn't have, as far as bwn(4) is co
On Monday, January 31, 2011 14:14:01 Fraser Tweedale wrote:
> I might be fighting a losing battle, but any advice on getting the
> Broadcom BCM4322 802.11a/b/g/n working? This chip is found in
> Apple's MacBook and probably elsewhere.
>
> I'm currently running amd64 8.2-RC2. As best as I can see,
> (kgdb) print *ng_name_hash[116].lh_first
It looks like this one is corrupted:
(kgdb) print
*ng_name_hash[116].lh_first.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next.nd_nodes.le_next
$19 = {nd_name = "ng258", '\0' , nd_type = 0xc61871a0,
nd_flags = 0, nd_refs = 1, nd_numhooks = 0, nd_priv
> And in this one, can you please show *hook->hk_peer ?
(kgdb) print *hook->hk_peer
$2 = {
hk_name = "\b\000\000\000
\000\000\000\004\000\000\000\001\000\000\000ŐRí\003\003ö\0248cmd4\000\000\000",
hk_private = 0x0, hk_flags = 0, hk_refs = 0,
hk_type = 0, hk_peer = 0x0, hk_node = 0x0, hk_hooks
On Monday 31 January 2011 03:07:02 Pyun YongHyeon wrote:
> On Sun, Jan 30, 2011 at 05:15:10PM -0800, Pyun YongHyeon wrote:
> > On Sun, Jan 30, 2011 at 02:53:15PM +0100, Milan Obuch wrote:
> > > On Sunday 30 January 2011 07:40:48 Zeus V Panchenko wrote:
> > > > another detail for this nic
> > > >
>
Milan Obuch (freebsd-...@dino.sk) [11.01.31 17:31] wrote:
>
> I checked my cables and one of them had bad pairing. Worked in 100 Mb mode,
> but not in 1 Gb mode. After I replaced it I check with flood ping, 1472 bytes
> packets again and no sign of problem here - one reply missing in almost 21
On 1/31/11 4:32 AM, Bjoern A. Zeeb wrote:
On Mon, 31 Jan 2011, Eugene Grosbein wrote:
On 31.01.2011 14:20, Julian Elischer wrote:
# gdb kernel
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are
we
On 1/31/11 7:13 AM, Przemyslaw Frasunek wrote:
And in this one, can you please show *hook->hk_peer ?
(kgdb) print *hook->hk_peer
$2 = {
hk_name = "\b\000\000\000
\000\000\000\004\000\000\000\001\000\000\000ŐRí\003\003ö\0248cmd4\000\000\000",
hk_private = 0x0, hk_flags = 0, hk_refs = 0,
hk_
On 1/31/11 8:58 AM, Julian Elischer wrote:
On 1/31/11 7:13 AM, Przemyslaw Frasunek wrote:
And in this one, can you please show *hook->hk_peer ?
(kgdb) print *hook->hk_peer
$2 = {
hk_name = "\b\000\000\000
\000\000\000\004\000\000\000\001\000\000\000ŐRí\003\003ö\0248cmd4\000\000\000",
hk_p
On 1/31/2011 12:10 PM, Julian Elischer wrote:
> On 1/31/11 8:58 AM, Julian Elischer wrote:
>> On 1/31/11 7:13 AM, Przemyslaw Frasunek wrote:
And in this one, can you please show *hook->hk_peer ?
>>> (kgdb) print *hook->hk_peer
>>> $2 = {
>>>hk_name = "\b\000\000\000
>>> \000\000\000\004\00
On Monday, January 31, 2011 1:31:54 am Eugene Grosbein wrote:
> On 15.01.2011 01:37, John Baldwin wrote:
> > On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote:
> >> On 14.01.2011 18:46, Mike Tancsa wrote:
> >>
> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300
PPP
Somewhat related fallout to the bug reported on security@ recently, I think
this KASSERT() in tcp_output() is bogus:
KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL),
("%s: mbuf chain shorter than expected", __func__));
Specifically, just a few lines earlier in tcp_outpu
On Mon, Jan 31, 2011 at 02:15:09PM +0200, Zeus V Panchenko wrote:
> Pyun YongHyeon (pyu...@gmail.com) [11.01.31 04:08] wrote:
> > > The RTL8168/8111D sample board I have does not show this kind of
> > > issue. This happens only when established link is 1000baseT, right?
> > > I slightly changed PHY
Synopsis: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in
7.0-RELEASE and 7.0-STABLE-042008
State-Changed-From-To: open->feedback
State-Changed-By: yongari
State-Changed-When: Mon Jan 31 21:38:47 UTC 2011
State-Changed-Why:
Is it still issue on more recent FreeBSD release?
Respon
The following reply was made to PR kern/153938; it has been noted by GNATS.
From: PseudoCylon
To: Juergen Lock
Cc: bug-follo...@freebsd.org, Juergen Lock
Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free
panic
Date: Mon, 31 Jan 2011 15:28:25 -0800 (PST)
- Orig
On 02/01/11 04:17, John Baldwin wrote:
> Somewhat related fallout to the bug reported on security@ recently, I think
> this KASSERT() in tcp_output() is bogus:
>
>
> KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL),
> ("%s: mbuf chain shorter than expected", __func__));
>
>
On Tue, 1 Feb 2011, Lawrence Stewart wrote:
On 02/01/11 04:17, John Baldwin wrote:
Somewhat related fallout to the bug reported on security@ recently, I think
this KASSERT() in tcp_output() is bogus:
KASSERT(len + hdrlen + ipoptlen == m_length(m, NULL),
("%s: mbuf chain sh
On 31.01.2011 22:46, John Baldwin wrote:
>># gdb kernel
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain
> conditions.
>>
Hi All,
I am not sure if anybody has asked it before. I could not find answer by
doing rough search on Internet, if it is duplicate question, sorry in
advance.
My question is that, for getting socket options in tcp_ctloutput() in
tcp_usrreq.c, why do we need to do lock with INP_WLOCK(inp) as sett
i want to run a whole bunch of dynamips virtualized ciscos inside a fbsd
8.x server. i want the virtual routers to have some interfaces which
are externally visible.
so i think i do something like
ifconfig tap0 147.28.224.41/30
ifconfig tap1 147.28.224.45/30
ifconfig tap2 147.28.22
> 1/ wow does that (dynamips ciscos) actually run on BSD?
yep
> 2/ "why?"
so we can have a routing research topology testbed of real cisco and
real juniper code.
> first you need to create them right?
> ifconfig tap0 create 192.168.3.1/28 up
>
> I think you do:
> in rc.conf:
> cloned_interface
On 1/31/11 11:10 PM, Randy Bush wrote:
i want to run a whole bunch of dynamips virtualized ciscos inside a fbsd
8.x server. i want the virtual routers to have some interfaces which
are externally visible.
so i think i do something like
ifconfig tap0 147.28.224.41/30
ifconfig tap1 147
31 matches
Mail list logo
