Hi,
I've been seeing similar issues ("IP bad-len 0" packets in tcpdump
traces") since 7.2-STABLE and em interfaces. Turning off TSO seems to
do the trick here, too. So at least from where I'm sitting, this is
not only an fxp problem.
Lars
Dear All ,
To the Intel DG965WH main board
http://www.intel.com/support/motherboards/desktop/dg965wh/
I attached a Samsung Syncmaster 2233SN 1920 x 1080 21.5 inches LCD analog
monitor
http://www.samsung.com/uk/consumer/detail/detail.do?group=itbusiness&type=monitors&subtype=lcd&model_cd=LS22CMYK
On Thu, May 14, 2009 at 10:10:12AM +0300, Lars Eggert wrote:
> Hi,
>
> I've been seeing similar issues ("IP bad-len 0" packets in tcpdump
> traces") since 7.2-STABLE and em interfaces. Turning off TSO seems to
> do the trick here, too. So at least from where I'm sitting, this is
> not only a
Hi,
On 2009-5-14, at 11:27, Pyun YongHyeon wrote:
Then you're seeing different problem on em(4). Last time I checked
em(4) TSO code in em(4) didn't use m_pullup and just returned
ENXIO to caller. I'm not sure that is related with your issue but
would you tell us your network configuration?
thi
In my case, it's a
e...@pci0:12:0:0: class=0x02 card=0x135e8086 chip=0x105e8086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'PRO/1000 PT'
class = network
subclass = ethernet
Lars
On 2009-5-14, at 11:46, Lev Serebryakov wrote:
Hello, Lars.
You w
FYI
I have installed 7.2 on a EEEBOX B202
Everything I need works to make this my next home server (mail/http/nfs)
Not working:
- wifi
Not tested:
- X
- sound
more info on http://martenvijn.nl/trac/wiki/EEEBOXB202
Kind regards,
Marten
--
http://martenvijn.nl Marten Vijn
ht
Hi,
I've received a panic today on RELEASE 7.2 with bge(4). We have got
an apache 2.2 running that mounts an NFS share from a file server.
We have put some load on it, because we
have downloaded big files (700MB) for installation on two
workstations, about 15 of files were downloaded at the same t
on 13/05/2009 23:46 Andrew Snow said the following:
> Pat Wendorf wrote:
>> I spoke too soon I guess: A buddy of mine at the hosting provider took
>> down
>> the box and did a fsck -y on the var partition, this seems to have
>> cleaned
>> it up. It looks like the regular fsck -p could not repair i
[1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More
[5]At Gold Crown
You have recieved A Hallmark E-Card.
Hello!
You have recieved a Hallmark E-Card.
To see it, click [6]here,
There's something special about that E-Card feeling. We invite you to
I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in
question is:
em1: port
0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 19 at
device 0.1 on pci4
what we get after boot is:
em1: flags=8943 metric 0
mtu 1500
options=19b
ether 00:30:48:xx:
On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
> Hi,
>
> I've received a panic today on RELEASE 7.2 with bge(4). We have got
> an apache 2.2 running that mounts an NFS share from a file server.
> We have put some load on it, because we
> have downloaded big files (700MB) for installati
In response to James Tanis :
> I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in
> question is:
>
> em1: port
> 0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 19 at
> device 0.1 on pci4
>
> what we get after boot is:
>
> em1: flags=8943 metric 0
> mtu
On Thu, May 14, 2009 at 9:12 AM, James Tanis wrote:
> I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in
> question is:
>
> em1: port
> 0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 19 at
> device 0.1 on pci4
>
> what we get after boot is:
>
> em1: flags=894
Bill Moran wrote:
In response to James Tanis :
<.. snip ..>
Attempting to force 1000baseTX via:
ifconfig em1 media 1000baseTX mediaopt full-duplex
gets me:
status: no carrier
After forcing the NIC to go 1000baseTX the LEDs on the backpane are both
off. I can only come to the conclusion
(kgdb) list *0xc07a4dac
0xc07a4dac is in devvn_refthread (/usr/src/sys/kern/kern_conf.c:209).
204 struct cdev_priv *cdp;
205
206 mtx_assert(&devmtx, MA_NOTOWNED);
207 csw = NULL;
208 dev_lock();
209 *devp = vp->v_rdev;
210 if
Yesterday I updated a rock-solid machine (uptime hundreds of days) from
7-stable circa July, 2008, to the latest stable. I run Nessus on this
machine, with about 60 concurrent scans. It pushes the load average up as
high as 20 for short periods of time, but overall is reasonably efficient.
Am Thu, 14 May 2009 09:16:40 -0400
schrieb John Baldwin :
> On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
> [...]
> > kernel trap 12 with interrupts disabled
> >
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 0
> > fault virtual address = 0x8
[1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More
[5]At Gold Crown
You have recieved A Hallmark E-Card.
Hello!
You have recieved a Hallmark E-Card.
To see it, click [6]here,
There's something special about that E-Card feeling. We invite you to
TB --- 2009-05-14 19:44:15 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-14 19:44:15 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-14 19:44:15 - cleaning the object tree
TB --- 2009-05-14 19:44:58 - cvsupping the source tree
TB --- 2009-05-14 19:44:58 - /usr/
On Thursday 14 May 2009 12:30:31 pm Chris Timmons wrote:
>
> (kgdb) list *0xc07a4dac
> 0xc07a4dac is in devvn_refthread (/usr/src/sys/kern/kern_conf.c:209).
> 204 struct cdev_priv *cdp;
> 205
> 206 mtx_assert(&devmtx, MA_NOTOWNED);
> 207 csw = NULL;
> 208 de
Can you get a stack trace? Your panic is quite different then the original
one.
Let me know if there is any other information which would be helpful. I
rebooted the 7.0 kernel from July, and the machine has been happily
chugging along running Nessus under load for almost 6 hours.
Boris Samorodov wrote:
> On Mon, 11 May 2009 15:56:11 +1000 Graham Menhennitt wrote:
>
>
>> touch: not found
>>
>
> Please check it the system time was changed between
> c(v)sup -> buildworld. I case yes, just redo the process.
>
I don't know how the time changed, but redoing the buildwo
> Well, I don't have any verified working cable of the appropriate length
> so I simply switched out the cables for the main server and the backup
> server. They are both cat6 cables crimped with cat5e modules by me. For
> what reason (bad crimp job?) that seemed to fix the issue.
On stranded c
On Thu, May 14, 2009 at 11:54:00AM -0400, Bill Moran wrote:
> In response to James Tanis :
>
> > I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in
> > question is:
> >
> > em1: port
> > 0x2020-0x203f mem 0xd806-0xd807,0xd804-0xd805 irq 19 at
> > device 0.1 o
On Thu, May 14, 2009 at 12:29:17PM -0400, James Tanis wrote:
> Bill Moran wrote:
> >In response to James Tanis :
> >
> >
> >
> >><.. snip ..>
> >>Attempting to force 1000baseTX via:
> >>
> >>ifconfig em1 media 1000baseTX mediaopt full-duplex
> >>
> >>gets me:
> >>
> >>status: no carrier
> >>
> >>
TB --- 2009-05-15 04:42:27 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-15 04:42:27 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-15 04:42:27 - cleaning the object tree
TB --- 2009-05-15 04:42:41 - cvsupping the source tree
TB --- 2009-05-15 04:42:41 - /usr/
Hi,
Since upgrading sources on RELENG_7 yesterday, my amd64 system panics
right after this line in dmesg:
ata4: on atapci1
panic: resource_list_alloc: resource entry is busy
This machine uses an ALi SATA controller. I haven't had any problems
with this controller's support for most of the 7
Bruce Simpson wrote:
Since upgrading sources on RELENG_7 yesterday, my amd64 system panics
right after this line in dmesg:
ata4: on atapci1
panic: resource_list_alloc: resource entry is busy
...
I see there have recently been commits in this area which may have
broken ATA driver support in so
28 matches
Mail list logo
