On Thu, May 14, 2009 at 03:32:34PM -0700, Chris Timmons wrote:
>
>
> >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 ha
Following up to myself, I experienced a watchdog timout followed by
lockuup again early this morning. Strangely, rather than happening at
a time of heavy activity, it seems to have occurred when there was
very little activity.
I was running 'systat' in a window when the watchdog timeout occurred
On Thu, May 14, 2009 at 11:28:43AM +0300, Lars Eggert wrote:
> 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 relat
The property sernum is not very reliable. Sometimes devd knows about it
and sometimes not.
I removed the match on it and know it works.
Ronald.
On Wed, 06 May 2009 12:03:14 +0200, Ronald Klop
wrote:
Hello,
Running 7.2-STABLE/amd64. I have a USB-disk and added stuff to devd to
mount it
#8 0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c,
dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
89 *dswp = devvn_refthread(fp->f_vnode, devp);
(kgdb) p *(struct file *)0xc78fadf4
$1 = {f_list = {le_next = 0xc78ab5f0, le_prev = 0xc789e5f0}, f_type = 1,
On Fri, May 15, 2009 at 05:32:49AM -0700, Chris Timmons wrote:
>
> #8 0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c,
> dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
> 89*dswp = devvn_refthread(fp->f_vnode, devp);
>
> (kgdb) p *(struct file *)0xc78fadf4
>
On Thursday 14 May 2009 1:10:26 pm Martin wrote:
> 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
On Friday 15 May 2009 1:10:12 am Bruce Simpson wrote:
> 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 have
TB --- 2009-05-15 13:43:29 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-15 13:43:29 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-15 13:43:29 - cleaning the object tree
TB --- 2009-05-15 13:43:41 - cvsupping the source tree
TB --- 2009-05-15 13:43:41 - /usr/
Am Fri, 15 May 2009 08:15:19 -0400
schrieb John Baldwin :
Hi John,
> When I have seen this, it has often been due to a hardware failure
> such as bad RAM.
hmmm... I will check this next week.
> > cpuid = 2; apic id = 02
> > instruction pointer = 0x8:0x805bbc66
>
> Can you do 'x/i 0xfff
on 07/05/2009 17:17 Helmut Schneider said the following:
> Andriy Gapon wrote:
>> on 06/05/2009 14:43 Helmut Schneider said the following:
>>> kbd1 at kbdmux0
>> [snip]
>>> atkbdc0: at port 0x60,0x64 on isa0 atkbd0:
>>> irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED]
>>> atkbd0: [ITHREAD
On Friday 15 May 2009 10:57:27 am Martin wrote:
> Am Fri, 15 May 2009 08:15:19 -0400
> schrieb John Baldwin :
>
> Hi John,
>
> > When I have seen this, it has often been due to a hardware failure
> > such as bad RAM.
>
> hmmm... I will check this next week.
>
> > > cpuid = 2; apic id = 02
> > >
Hi John,
one more thing that I noticed. It seems that the netmask passed to the
procedure rt_maskedcopy is invalid. Cannot dereference the pointer.
I went one frame up and I've looked at the control flow of the parent
routine rtrequest1_fib. This routine passes the netmask, but before it
does th
Am Fri, 15 May 2009 11:09:20 -0400
schrieb John Baldwin :
> x/i please. The /i decodes it as an instruction so I can see which
> registers it was attempting to dereference.
Oh sorry...
(kgdb) x/i 0x805bbc66
0x805bbc66 : movzbl (%rdx),%edx
--
Martin
___
On Friday 15 May 2009 11:36:18 am Martin wrote:
>
> Hi John,
>
> one more thing that I noticed. It seems that the netmask passed to the
> procedure rt_maskedcopy is invalid. Cannot dereference the pointer.
>
> I went one frame up and I've looked at the control flow of the parent
> routine rtrequ
Kostik,
Looking good after applying your patch and rebuilding the kernel. I've
been exercising the machine for a couple of hours under the same load
which crashed it in short order yesterday.
I will report back if any problems appear.
Thank you for your help!
Regards,
-Chris
last pid: 4
Never only set one end manually, always set both the machine and the
switch.
Regards
Steve
- Original Message -
From: "James Tanis"
To: "FreeBSD Questions" ;
Sent: Thursday, May 14, 2009 4:12 PM
Subject: issues with Intel Pro/1000 and 1000baseTX
I have a FreeBSD v7.0 box it
Better yet, just let them autoneg and you won't have these problems :)
Jack
On Fri, May 15, 2009 at 9:15 AM, Steven Hartland wrote:
> Never only set one end manually, always set both the machine and the
> switch.
>
> Regards
> Steve
>
> - Original Message - From: "James Tanis"
> To
All in subject. I could see the particular line where install is
called on the newly built copy, but even though the system copy's file
flags are cleared (noschg), the overwriting fails. I managed to
overwrite it by (cp -f)-ing) the fresh copy over the old one.
Regards,
Vlad
__
On Friday 15 May 2009 11:38:00 am Martin wrote:
> Am Fri, 15 May 2009 11:09:20 -0400
> schrieb John Baldwin :
>
> > x/i please. The /i decodes it as an instruction so I can see which
> > registers it was attempting to dereference.
>
> Oh sorry...
>
> (kgdb) x/i 0x805bbc66
> 0x80
Am Fri, 15 May 2009 12:05:47 -0400
schrieb John Baldwin :
> > (kgdb) x/i 0x805bbc66
> > 0x805bbc66 : movzbl (%rdx),%edx
>
> Hmm, your %rdx is garbage. :(
>
> rdx0xef3fdf377db53afa -1207000745686779142
>
> That should at least be
>
>0x
On 2009-05-15 18:42, Vlad GALU wrote:
> All in subject. I could see the particular line where install is
> called on the newly built copy, but even though the system copy's file
> flags are cleared (noschg), the overwriting fails. I managed to
> overwrite it by (cp -f)-ing) the fresh copy over the
- This mail is a HTML mail. Not all elements could be shown in plain text
mode. -
Caso nao esteja visualizando este email,
visualize aqui
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscrib
On Fri, May 15, 2009 at 9:49 PM, Dimitry Andric wrote:
> On 2009-05-15 18:42, Vlad GALU wrote:
>> All in subject. I could see the particular line where install is
>> called on the newly built copy, but even though the system copy's file
>> flags are cleared (noschg), the overwriting fails. I manag
On 2009-05-15 22:25, Vlad GALU wrote:
>>> called on the newly built copy, but even though the system copy's file
>>> flags are cleared (noschg), the overwriting fails. I managed to
>>> overwrite it by (cp -f)-ing) the fresh copy over the old one.
>> Are you running in single-user mode during instal
On Fri, May 15, 2009 at 11:37 PM, Dimitry Andric wrote:
> On 2009-05-15 22:25, Vlad GALU wrote:
called on the newly built copy, but even though the system copy's file
flags are cleared (noschg), the overwriting fails. I managed to
overwrite it by (cp -f)-ing) the fresh copy over the
On Thu, May 14, 2009 12:53, Tim Judd wrote:
> 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
TB --- 2009-05-15 22:42:23 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2009-05-15 22:42:23 - starting RELENG_6 tinderbox run for amd64/amd64
TB --- 2009-05-15 22:42:23 - cleaning the object tree
TB --- 2009-05-15 22:42:37 - cvsupping the source tree
TB --- 2009-05-15 22:42:38 - /usr/
I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can.
http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/
The standard disclaimers apply. This has only been lightly tested in a
VM. Please do not use it with data you care about at this time.
Thanks,
Kip
--
When bad men combine,
On Fri, May 15, 2009 at 05:02:22PM -0700, Kip Macy wrote:
I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can.
http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/
The standard disclaimers apply. This has only been lightly tested in a
VM. Please do not use it with data
30 matches
Mail list logo
