Dan Allen | 1 Jan 01:08 2012
Picon

Re: ACPI broke going from 8 to 9


On 31 Dec 2011, at 4:31 PM, Jeremy Chadwick wrote:

> 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
> please provide uname -a output from the system when it was running
> RELENG_8?  I'm looking specifically for the exact time when the kernel
> was built

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.

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... ;-)

Dan

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
(Continue reading)

Adrian Chadd | 1 Jan 01:16 2012
Picon

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)

Garrett Cooper | 1 Jan 03:14 2012
Picon

Re: ACPI broke going from 8 to 9

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
> please provide uname -a output from the system when it was running
(Continue reading)

Oleg Ginzburg | 1 Jan 13:18 2012
Picon

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)

Aleksandr Rybalko | 1 Jan 13:32 2012
Picon

Re: [patch] bsdbox changes for base system: add LOCAL_

On Fri, 23 Dec 2011 16:42:06 -0800
Adrian Chadd <adrian <at> freebsd.org> wrote:

> Hi,
> 
> Here are two patches which implement some useful features for crunch
> building:
> 
> * Add LOCAL_TOOLS_DIR in src/Makefile.inc1, which adds entries to the
> 'build-tools' target. This is needed for cross-building bsdbox (and
> any external directory added by LOCAL_DIRS)
That makes me happy :)

> * If CRUNCH_SUPPRESS_ALL_LINKS is set to 'yes', don't auto-populate
> the crunch-gen hard links.
> 
> I may end up changing the latter to CRUNCH_GENERATE_LINKS and default
> that to yes, then allow the bsdbox build system to change that to
> 'no', but the intent is the same.
> 
> I'd like to commit this tomorrow if possible, so I can then follow it
> up with the bsdbox import.
> 
> Thanks,
> 
> 
> Adrian

Do it Adrian :)

(Continue reading)

John Baldwin | 1 Jan 14:55 2012
Picon

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)

Garrett Cooper | 1 Jan 23:25 2012
Picon

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)

Peter Jeremy | 1 Jan 22:05 2012
Picon

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)

Randy Bush | 2 Jan 01:17 2012

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)

Florian Smeets | 2 Jan 19:35 2012
Picon

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


Gmane