headers
Adrian Chadd | 1 Jan 2012 01:16
Picon
Favicon

Re: ACPI broke going from 8 to 9

On 31 December 2011 16:08, Dan Allen <danallen46 <at> airwired.net> wrote:

> Almost every day I csup from RELENG_x and build.  The traces of RELENG_8 are gone, so no, unfortunately I
cannot give you a uname -a from those days.

Would you consider having a small partition to do the same for HEAD? :P

> However, I have a build log file, and I see that I moved from RELENG_8 to RELENG_9 on Friday, Dec 23, 2011.  I
csup'd at 12:24:26 MST and discovered the failure at 15:41 MST.
>
> This "nooptions NEW_PCIB" fix does seem rather tenuous if it is not documented.  Wouldn't a better route
be something like
>
>  if (ACPI < 2.0)
>    oldCode();
>  else
>    newCodeForNewACPI();
>
> so that it will always work for everyone without having to build a special kernel?  After all, I went from a
working system to a hung system which is not the best upgrade path... ;-)

Well it's hard to test stuff out without the hardware. :) And it's
quite possible a lot of silly looking issues are actually working
around real bugs in the hardware.

I'm glad this issue was solved so quickly for you. Let's hope we can
get you onto testing out HEAD (in a separate partition!) so we can
ensure we don't break the basic stuff. :)

Adrian
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oleg Ginzburg | 1 Jan 2012 13:18
Picon
Gravatar

Re: segfault from php/freebsd/dtrace

On Saturday 31 December 2011 23:25:51 Ryan Stone wrote:
> On Thu, Dec 29, 2011 at 12:37 PM, Oleg Ginzburg <olevole <at> olevole.ru> wrote:
> > Hi maillist,
> > 
> > I try to use dtrace + php/dtrace on the freebsd. In certain cases ive get
> > Segmentation fault and don't understand what of subsystem has a problem.
> 
> Yes, Userland DTrace is unfortunately still very experimental at this
> point.  I've got a list of at least 10 outstanding bugs that I hope to
> start addressing early in the new year.
> 
> In your case, dtrace(1) and/or libproc does not clean up after itself
> properly in the case of an error.  

I can assume that it is:

--//Cut of /usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c//--
 if (fbsd_thread_active)
       {
         gdb_assert (proc_handle.pid == 0); <<   Here is 484 string mentioned 
by backtrace <<
         fbsd_thread_active = 0;
       }
---

related with the first process php which I start for providing php dtrace 
probes. Thanks to this process other code passes through php/dtrace and this 
process doesn't stop.

Last action by backtrace is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Baldwin | 1 Jan 2012 14:55
Picon
Favicon

Re: ACPI broke going from 8 to 9

On 12/31/11 9:14 PM, Garrett Cooper wrote:
> On Sat, Dec 31, 2011 at 3:31 PM, Jeremy Chadwick
> <freebsd <at> jdc.parodius.com>  wrote:
>> On Sat, Dec 31, 2011 at 04:17:16PM -0700, Dan Allen wrote:
>>> On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote:
>>>
>>>> Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and
>>>> try booting the new kernel. See if this works.
>>>
>>> It worked!  No hang, power button works.  Nice.  I hope this experimental option stays in.
>>>
>>> Thank you everyone for your help.  Happy New Years!
>>
>> This option isn't documented **anywhere** in the entire src tree.  It's
>> purely #ifdef all over.
>>
>> The code in question was committed 7 months ago.  It was MFC'd to
>> RELENG_8 6 months ago.  Here's the HEAD commit message:
>>
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c#rev1.420
>>
>> The RELENG_8 MFC is revision 1.386.2.15.
>>
>> The committer is jhb <at> , with mav <at>  being the individual who tested it, so
>> I imagine either of these folks will have some excellent insights as to
>> what's causing Dan's problem.  I'm CC'ing them both directly on this
>> thread.
>>
>> In the meantime: Dan, when you say in your original mail, "I just
>> upgraded my Dell OptiPlex GX270 from RELENG_8 to RELENG_9", can you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Garrett Cooper | 1 Jan 2012 23:25
Picon
Gravatar

Re: [patch] Cleaning up amd64 kernel optimization options

On Fri, Dec 23, 2011 at 12:34 PM, Garrett Cooper <yanegomi <at> gmail.com> wrote:
> On Fri, Dec 23, 2011 at 6:37 AM, John Baldwin <jhb <at> freebsd.org> wrote:
>> On Thursday, December 22, 2011 9:51:47 pm Garrett Cooper wrote:
>>> On Dec 22, 2011, at 4:59 PM, Alexander Best <arundel <at> freebsd.org> wrote:
>>>
>>> > On Thu Dec 22 11, Benjamin Kaduk wrote:
>>> >> On Thu, 22 Dec 2011, Alexander Best wrote:
>>> >>
>>> >>> On Thu Dec 22 11, Dimitry Andric wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>> I would like to ask some feedback on the attached patch, which cleans up
>>> >>>> the kernel optimization options for amd64.  This was touched upon
>>> >>>> earlier by Alexander Best in freebsd-toolchain, here:
>>> >>>
>>> >>> i've been using such settings for a few months now and haven't noticed any
>>> >>> problems.
>>> >>>
>>> >>> however bruce evans raised a good point (in a private mail). when you
>>> >>> compile a
>>> >>> kernel without debugging enabled, -O2 is the default. if you experience
>>> >>> issues,
>>> >>> and enable debugging, -O0 now becomes the default. in case the problems
>>> >>> with
>>> >>> the kernel were caused by the -O2 option and aren't present with the -O0
>>> >>> option, the newly built kernel with debugging enabled will not help you
>>> >>> fix the
>>> >>> problems. in that case you would need to set -O2 explicitly in CFLAGS. his
>>> >>> exact words were:
>>> >>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Jeremy | 1 Jan 2012 22:05
Picon
Favicon

Re: lost inode, no backup

I know it's been a week but no-one else has offered any input.

On 2011-Dec-25 08:39:02 -0500, Randy Bush <randy <at> psg.com> wrote:
>FreeBSD ran.psg.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Sat Dec 24 12:33:51 UTC 2011    
root <at> ran.psg.com:/usr/obj/usr/src/sys/RAN  amd64
...
>on reboot, /usr/home was empty, as iff the inode had been lost.  but no
>lost+found and fsck found no problem.
...
>/dev/da0s1f    138G    111G     15G    88%    /usr
...
># 4 - /usr
>/sbin/dump 0Luaf - /dev/da0s1f | $SSH $USYS "/bin/cat > $DDIR/usr"
>
>and which had run quite happily a few hours before
...
>  DUMP: DUMP: 56980137 tape blocks
...
>except that on all backups since the system moved to 10-current, home is
>empty in the usr file!!!  all other directories there are good.

It's not explicitly specified but I presume /usr/home is a directory
within /usr.  (Not a symlink or mountpoint).

What version were you running before 10-current?
Is /usr UFS2 with softupdates+journalling?
Is userland (specifically /sbin/dump and fsck) aligned with the kernel?
Any idea what SVN revision your system corresponds to?
Have there been any unclean shutdowns of the system?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Randy Bush | 2 Jan 2012 01:17

Re: lost inode, no backup

[ i fear that, at this point, this only serves as a oddity i have seen
  and reported just in case someone else sees something similar and the
  two clues can be summed ]

> I know it's been a week but no-one else has offered any input.

no blame, was very very strange.  never seen anything like it before.
and i pieced my world back together, with very little loss, as there
were other modes of backup in place, belt and braces.  i only actually
lost some months of mail in imap folders of procmail mailing list spew,
such as freebsd-current.

> It's not explicitly specified but I presume /usr/home is a directory
> within /usr.  (Not a symlink or mountpoint).

indeed.

> What version were you running before 10-current?

9-[then-]current.  the machine is the one server which only has my
personal crud, so it is the bleeding edge.  it converted to -10 about
when the problems with backup content seem to have started last
(northern hemispheric) summer.  so the issue could have been some file
state that happened long ago and just did not surface until the much
later upgrade.

> Is /usr UFS2 with softupdates+journalling?

/dev/da0s1f on /usr (ufs, local, soft-updates)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Smeets | 2 Jan 2012 19:35
Picon
Favicon

Re: dogfooding over in clusteradm land

On 29.12.11 01:04, Kirk McKusick wrote:
> Rather than changing BKVASIZE, I would try running the cvs2svn
> conversion on a 16K/2K filesystem and see if that sorts out the
> problem. If it does, it tells us that doubling the main block
> size and reducing the number of buffers by half is the problem.
> If that is the problem, then we will have to increase the KVM
> allocated to the buffer cache.
> 

This does not make a difference. I tried on 32K/4K with/without journal
and on 16K/2K all exhibit the same problem. At some point during the
cvs2svn conversion the sycer starts to use 100% CPU. The whole process
hangs at that point sometimes for hours, from time to time it does
continue doing some work, but really really slow. It's usually between
revision 210000 and 220000, when the resulting svn file gets bigger than
about 11-12Gb. At that point an ls in the target dir hangs in state ufs.

I broke into ddb and ran all commands which i thought could be useful.
The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt

The machine is still in ddb and i could run any additional commands, the
kernel is from Attilio's vmcontention branch, which was MFCed yesterday,
and updated after the MFC. The same problem happens on 9.0-RC3.

If i run the same test on a zfs filesystem i don't see any problems.

Florian
Permalink | Reply | 12 comments |
headers
Don Lewis | 2 Jan 2012 21:47
Picon
Favicon

Re: dogfooding over in clusteradm land

On  2 Jan, Florian Smeets wrote:
> On 29.12.11 01:04, Kirk McKusick wrote:
>> Rather than changing BKVASIZE, I would try running the cvs2svn
>> conversion on a 16K/2K filesystem and see if that sorts out the
>> problem. If it does, it tells us that doubling the main block
>> size and reducing the number of buffers by half is the problem.
>> If that is the problem, then we will have to increase the KVM
>> allocated to the buffer cache.
>> 
> 
> This does not make a difference. I tried on 32K/4K with/without journal
> and on 16K/2K all exhibit the same problem. At some point during the
> cvs2svn conversion the sycer starts to use 100% CPU. The whole process
> hangs at that point sometimes for hours, from time to time it does
> continue doing some work, but really really slow. It's usually between
> revision 210000 and 220000, when the resulting svn file gets bigger than
> about 11-12Gb. At that point an ls in the target dir hangs in state ufs.
> 
> I broke into ddb and ran all commands which i thought could be useful.
> The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt

Tracing command syncer pid 9 tid 100183 td 0xfffffe00120e9000
cpustop_handler() at cpustop_handler+0x2b
ipi_nmi_handler() at ipi_nmi_handler+0x50
trap() at trap+0x1a8
nmi_calltrap() at nmi_calltrap+0x8
--- trap 0x13, rip = 0xffffffff8082ba43, rsp = 0xffffff8000270fe0, rbp = 0xffffff88c97829a0 ---
_mtx_assert() at _mtx_assert+0x13
pmap_remove_write() at pmap_remove_write+0x38
vm_object_page_remove_write() at vm_object_page_remove_write+0x1f
(Continue reading)

Permalink | Reply | 11 comments |
headers
Bjoern A. Zeeb | 2 Jan 2012 22:29

periodic emails

Hi,

why do we send all these empty headings for periodic emails or given there is
no output to this one can we

1) suppress the empty sections (to me that sounds a bit like a wrong
   return code or something maybe?), and
2) add an option to suppress "empty" periodic emails entirely?

Sample:
-------
Removing stale files from /var/preserve:

Cleaning out old system announcements:

Removing stale files from /var/rwho:

Backup passwd and group files:

Verifying group file syntax:
/etc/group is fine

Security check:
   (output mailed separately)

Checking for denied zone transfers (AXFR and IXFR):

-- End of daily output --
-------
(Continue reading)

Permalink | Reply | 21 comments |
headers
Kostik Belousov | 2 Jan 2012 22:45
Picon

Re: dogfooding over in clusteradm land

On Mon, Jan 02, 2012 at 12:47:03PM -0800, Don Lewis wrote:
> On  2 Jan, Florian Smeets wrote:
> > On 29.12.11 01:04, Kirk McKusick wrote:
> >> Rather than changing BKVASIZE, I would try running the cvs2svn
> >> conversion on a 16K/2K filesystem and see if that sorts out the
> >> problem. If it does, it tells us that doubling the main block
> >> size and reducing the number of buffers by half is the problem.
> >> If that is the problem, then we will have to increase the KVM
> >> allocated to the buffer cache.
> >> 
> > 
> > This does not make a difference. I tried on 32K/4K with/without journal
> > and on 16K/2K all exhibit the same problem. At some point during the
> > cvs2svn conversion the sycer starts to use 100% CPU. The whole process
> > hangs at that point sometimes for hours, from time to time it does
> > continue doing some work, but really really slow. It's usually between
> > revision 210000 and 220000, when the resulting svn file gets bigger than
> > about 11-12Gb. At that point an ls in the target dir hangs in state ufs.
> > 
> > I broke into ddb and ran all commands which i thought could be useful.
> > The output is at http://tb.smeets.im/~flo/giant-ape_syncer.txt
> 
> Tracing command syncer pid 9 tid 100183 td 0xfffffe00120e9000
> cpustop_handler() at cpustop_handler+0x2b
> ipi_nmi_handler() at ipi_nmi_handler+0x50
> trap() at trap+0x1a8
> nmi_calltrap() at nmi_calltrap+0x8
> --- trap 0x13, rip = 0xffffffff8082ba43, rsp = 0xffffff8000270fe0, rbp = 0xffffff88c97829a0 ---
> _mtx_assert() at _mtx_assert+0x13
> pmap_remove_write() at pmap_remove_write+0x38
(Continue reading)

Permalink | Reply | 0 comments |

Gmane