Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks

[Gary Palmer]

On Thu, Jan 06, 2011 at 05:42:49PM -0800, Jeremy Chadwick wrote:
> On Fri, Jan 07, 2011 at 12:29:17PM +1100, Jean-Yves Avenard wrote:
> > On 6 January 2011 22:26, Chris Forgeron  wrote:
> > > You know, these days I'm not as happy with SSD's for ZIL. I may blog 
> > > about some of the speed results I've been getting over the last 6mo-1yr 
> > > that I've been running them with ZFS. I think people should be using 
> > > hardware RAM drives. You can get old Gigabyte i-RAM drives with 4 gig of 
> > > memory for the cost of a 60 gig SSD, and it will trounce the SSD for 
> > > speed.
> > >
> > > I'd put your SSD to L2ARC (cache).
> > 
> > Where do you find those though.
> > 
> > I've looked and looked and all references I could find was that
> > battery-powered RAM card that Sun used in their test setup, but it's
> > not publicly available..
> 
> DDRdrive:
>   http://www.ddrdrive.com/
>   http://www.engadget.com/2009/05/05/ddrdrives-ram-based-ssd-is-snappy-costly/
> 
> ACard ANS-9010:
>   http://techreport.com/articles.x/16255

There is also

https://www.hyperossystems.co.uk/07042003/hardware.htm

which I believe is a rebadged ACard drive.  They should be SATA-300, but
the test results I saw were not that impressive to be honest.  I think
whatever FPGA they use for the SATA interface and DRAM controller is
either underpowered or the gate layout needs work.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS - moving from a zraid1 to zraid2 pool with 1.5tb disks

[Gary Palmer]

On Thu, Jan 06, 2011 at 08:20:00PM -0800, Jeremy Chadwick wrote:
> HyperDrive 5M (DDR2-based; US$299)
> 
> 1) Product documentation claims that "the drive has built-in ECC so you
> can use non-ECC DDR2 DIMMs" -- this doesn't make sense to me from a
> technical perspective.  How is this device doing ECC on a per-DIMM
> basis?  And why can't I just buy ECC DIMMs and use those instead (they
> cost, from Crucial, $1 more than non-ECC)?
> 
> 2) Monitoring capability -- how?  Does it support SMART?  If so, are the
> vendor-specific attributes documented in full?  What if a single DIMM
> goes bad?  How would you know which DIMM it is?  Is there even an LED
> indicator of when there's a hard failure on a DIMM?  What about checking
> its status remotely?
> 
> 3) Use of DDR2; DDR2 right now is significantly more expensive then
> DDR3, and we already know DDR2 is on its way out.
> 
> 4) Claims 175MB/s read, 145MB/s write; much slower than 500MB/s, so
> maybe you're talking about a different product?  I don't know.
> 
> 5) Uses 2x SATA ports; why?  Probably because it uses SATA-150 ports,
> and thus 175MB/s would exceed that.  Why not just go with SATA-300,
> or even SATA-600 these days?

FAQ 2:

Q Why does the HyperDrive5 have two SATA ports?

A So that you can split one 8 DIMM slot device into two 4 DIMM slot deivces and 
run them both in RAID0 using a RAID controller for even faster performance.

It claims SATA-300 (or SATA2 in the incorrect terminology from their website)

Note, I have no relation to hyperos systems and don't use their gear.  I did
look at it for a while for journal/log type applications but to me the
price/performance wasn't there.

As it relates to the ACard, from memory the HyperDrive4 was ditched and
then HyperOS came out with the HyperDrive 5 which looks remarkably similar
to the ACard product. I was told by someone (or read somewhere) that
HyperOS outsourced it to or OEMd it from some Asian country, which
would fit if ACard was the manufacturer as they're in Taiwan.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: geom_label, fstab without device names & swap partition?

[Gary Palmer]

On Wed, Jan 12, 2011 at 09:02:01PM +0300, Lev Serebryakov wrote:
> Hello, Stable.
> 
>   Now, with "newfs -L name", geom_label and /dev/ufs/* it is possible
> to not use device names for FSes in "/etc/fstab" at all. But what to
> do with swap partitions? How to say, that I want swap on
> "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now?

Have you tried using glabel(8)?  It allows you to assign a name
to a slice.  The slice should not be in use at the time, and if it has
a filesystem on it you may have problems as glabel(8) uses the last block
for a data store.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Strange performance issue with grep -r -i as non-root user

[Gary Palmer]

On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote:
> This is a strange one, and the more I started debugging it (starting
> with truss, comparing fast vs. slow results, where all that appears
> different is read() operations are taking a lot longer -- I haven't had
> time to check with ktrace yet), the more strange it got: that's when I
> found out the behaviour changes depending on if you're a user or root.
> 
> Easy to reproduce:
> 
> - grep -r string /usr/src, as non-root, is fast
> - grep -r -i string /usr/src, as non-root, is 8x slower than without -i
> - grep -r string /usr/src, as root, is fast
> - grep -r -i string /usr/src, as root, is fast

This is a stab in the dark, but are there any differences in your
shell environment variables between root and non-root?  Specifically
LANG or LC_ style variables.  I ran into issues in the past with grep
being horrendously slow and traced it to LANG or LC_* in the environment
causing a much longer code path than without the settings.

Regards,

Gary

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Gary Palmer]

On Sat, Apr 02, 2011 at 12:55:15PM -0400, David Magda wrote:
> On Apr 1, 2011, at 23:35, Matthew Dillon wrote:
> 
> >The solution to this first item is for the OS/filesystem to issue a
> >disk flush command to the drive at appropriate times.  If I recall the
> >ZFS implementation in FreeBSD *DOES* do this for transaction groups,
> >which guarantees that a prior transaction group is fully synced before
> >a new ones starts running (HAMMER in DragonFly also does this).
> >(Just getting an 'ack' from the write transaction over the SATA bus only
> >means the data made it to the drive's cache, not that it made it to
> >the platter).
> 
> It should also be noted that some drives ignore or lie about these flush 
> commands: i.e., they say they flushed the buffers but did not in fact do so. 
> This is sometimes done on cheap SATA drives, but also on expensive SANS. If 
> the former's case it's often to help with benchmark numbers. In the latter's 
> case, it's usually okay because the buffers are actually NVRAM, and so are 
> safe across power cycles. There are also some USB-to-SATA chipsets that don't 
> handle flush commands and simply ACK them without passing them to the drive, 
> so yanking a drive can cause problems.

SANs are *theoretically* safer because of their battery backed caches, however
it's not guaranteed - I've seen an array controller crash and royally screw
the data sets as a result, even when the cache was allegedly mirrored to
the redundant controller in the array.

NVRAM/battery backed cache protects against certain failures but introduces
other failures in their place.  You have to do your own risk/benefit
analysis before seeing which is the best solution for your usage scenario.
As long as it is "in transit" to permanent storage, it's at risk.  All the
disk redundancy/battery backed caches in the world is no replacement for
a comprehensive *and regularly tested* backup strategy.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Status of support for 4KB disk sectors

[Gary Palmer]

On Tue, Jul 19, 2011 at 08:48:54PM -0700, Chuck Swiger wrote:
> On Jul 19, 2011, at 8:14 PM, Jeremy Chadwick wrote:
> > On Wed, Jul 20, 2011 at 02:39:28AM -0700, per...@pluto.rain.com wrote:
> >> IIRC, Plextor (and maybe some others) had a switch to select 512 or
> >> 2048 as the default transfer size, precisely so that they could be
> >> used as boot devices with systems that supported only 512.
> 
> Come to think of it, I do remember that switch, yes.
> 
> Do you happen to know whether this limitation was part of the Sun hardware,
> or of SunOS?  CMU had a lot of Sun3 machines and NeXT clusters, so I ended
> up mixing NeXT CD-ROM and the Canon? magneto-optical drives with Sun H/W,
> and vice versa.

My memory is a bit fuzzy but I beleive it is at least partly because they
used ufs on the CDs rather than ISO 9660 based filesystems so they could
boot from the CD and have the device nodes there as well as all the other
features a ufs filesystem supports but ISO 9660 doesn't.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: OS X Lion time machine => (afpd|iSCSI) => ZFS question

[Gary Palmer]

On Thu, Jul 21, 2011 at 02:56:17PM -0700, Bakul Shah wrote:
> I am in no hurry to upgrade my MBP to OS X Lion but given Lion
> time machine and netatalk issues, I got wondering if iSCSI on
> FreeBSD is stable enough for time machine use. How much duct
> tape and baling wire are needed to make it work?!

Just a word of caution - I read somewhere that using iSCSI for Time
Machine means that you cannot use TM during an OS reinstall to
restore your files from the Time Machine archive as iSCSI isn't
available at that point.  It seems you have to use a locally 
attached disk or AFP for the support to be there during 
reinstall.  Not sure if thats still the case in Lion or not, I
would tend to suspect they still don't consider iSCSI a top tier
transport.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 9.0 B1 Panic

[Gary Palmer]

On Tue, Aug 02, 2011 at 02:58:09PM +0400, Lystopad Olexandr wrote:
>  Hello, Martin Wilke!
> 
> On Tue, Aug 02, 2011 at 12:41:29PM +0800
> m...@freebsd.org wrote about "9.0 B1 Panic":
> > 9.0 Beta1 Panic
> > 
> > Hi guys,
> > 
> > I just downloaded and install  9.0 BETA1 but it panics on ACPI. Please view 
> > attached screenshot for the error. If you need more information, do let us 
> > know.
> 
> There no attachments in your mail.

The mailing list strips all non-text attachments.  Please post the
attachments (like screen shots) on a web site and post the URL

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ZFS directory with a large number of files

[Gary Palmer]

On Fri, Aug 05, 2011 at 08:56:36PM -0700, Doug Barton wrote:
> On 08/05/2011 20:38, Daniel O'Connor wrote:
> 
> > Ahh, but OP had moved these files away and performance was still poor.. 
> > _that_ is the bug.
> 
> I'm no file system expert, but it seems to me the key questions are; how
> long does it take the system to recover from this condition, and if it's
> more than N $periods is that a problem? We can't stop users from doing
> wacky stuff, but the system should be robust in the face of this.

Its been quite a while since I worked on the filesystem stuff in any
detail but I believe, at least for UFS, it doesn't GC the directory,
just truncate it if enough of the entries at the end are deleted
to free up at least one fragment or block.  If you create N files and
then a directory and move the N files into the directory, the directory
entry will still be N+1 records into the directory and the only way to
"recover" is to recreate the directory that formerly contained the N
files.  It is theoretically possible to compat the directory but since 
the code to do that wasn't written when I last worked with UFS I suspect
its non trivial.

I don't know what ZFS does in this situation

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 7-stable: Root mount problem (mpt, probing / timing related)

[Gary Palmer]

On Tue, Sep 20, 2011 at 03:41:58PM +0200, Oliver Fromme wrote:
> Hi,
> 
> I've updated a server with mpt controller to the latest
> 7-stable (ok, it's 7-stable from last week).  During the
> boot sequence, the disk connected to the mpt controller (da0)
> seems to be probed too late, i.e. just _after_ the kernel
> tries to mount the root file system.  It's just a fraction
> of a second too late.
> 
> This is a screen shot of the situation:
> 
> http://www.secnetix.de/olli/tmp2/screenshot-boot.jpg
> 
> Of course, I can enter "ufs:da0s1a" at the rootmount prompt,
> and the machine continues to boot fine.  But this is a
> server that should be able to boot unattended, so I need
> this to be fixed.
> 
> What's the "official" way to fix this?  I think someone else
> had a similar problem some time ago, but a quick search of
> the lists doesn't yield anything.
> 
> (BTW:  Interestingly, the same machine boots fine without
> hickup when booting 8-stable which is installed on another
> Slice of the same disk.  This could be just coincidence,
> maybe the timing of probing is slightly different between
> 7-stable and 8-stable.)

Does increasing the 

kern.cam.scsi_delay

loader tunable help at all?

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: valgrind on FreeBSD?

[Gary Palmer]

On Wed, Oct 05, 2011 at 11:06:04PM +0200, V??clav Zeman wrote:
> Hi.
> 
> No matter what I try, valgrind on 7.3-STABLE is giving me this, both Valgrind
> ports:
> 
> valgrind: Startup or configuration error:
>Can't establish current working directory at startup
> valgrind: Unable to start up properly.  Giving up.
> 
> What do I need to do to make it work?

I just tried it on 7.4 and it appeared to work for me.  

Your error message suggests a permissions problem.  If you ran

pwd

from your shell in the directory you were trying to run valgrind from
and as the user you were trying to run valgrind from, does pwd give
an error also?

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: re unix browser problem

[Gary Palmer]

On Sat, Oct 15, 2011 at 10:36:00AM -0400, Jason Hellenthal wrote:
> 
> 
> On Sat, Oct 15, 2011 at 04:04:43PM +0200, kapral wrote:
> > On Sat, 15 Oct 2011 09:46:57 -0400, Jason Hellenthal 
> > wrote:
> > > On Sat, Oct 15, 2011 at 02:39:43PM +0200, kapral wrote:
> > >> it might be caused by insecure dns ipv4 because this domain le100
> > resolvs
> > >> for ip that belong to seedo not to google i dont know i fought seedo is
> > >> not
> > >> owned by google but i am a newbie sorry for a problem
> > > 
> > > I would take a educated guess that your search provideer in FF is
> > > Google. And when you open a new browser window and just start to type
> > > something within the search box is when your seeing this traffic occur.
> > > This is traffic you are seeing from search suggestions. If you do not
> > > want to see that traffic then turn off search suggestions and continue
> > > on because as someone else already noted this is not a FreeBSD problem.
> > no the same happends when i type in konquerror and epifany so it is a bsd
> > problem or rather browsers problem the only browser thet dont have this
> > problem is lynx all other have it in FreeBSD and Open BSD i had this
> > connection to 1e100.net this domains dont resolvs via nslookup i dont know
> > what is going on but the connection is from my port 21131 to www port
> > foreign host there shouldn't be this connection because i use blank page as
> > start page and dont use a search provider in other browsers
> 
> This is not a problem... This is called search suggestions and like I
> said turn them off and you wont see this happening.

Also if you have Safe Search enabled, I believe Firefox downloads the 
databases from Google on startup.  I don't run Firefox on FreeBSD to know
for sure but I see it hitting http://safebrowsing.clients.google.com and
http://safebrowsing-cache.google.com in my cache logs from other OSs

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FLAME - security advisories on the 23rd ? uncool idea is uncool

[Gary Palmer]

On Fri, Dec 23, 2011 at 08:55:35PM +0200, George Kontostanos wrote:
> On Fri, Dec 23, 2011 at 8:40 PM, Matthew Seaman
>  wrote:
> > On 23/12/2011 18:05, George Kontostanos wrote:
> >> Are all cvs mirror servers updated regarding these changes ?
> >>
> >> ANYBODY 
> >
> > Should have by now. ?Commits usually take about an hour to propagate to
> > the official cvsup servers.
> >
> > Easy enough to tell though -- the advisories have all the version
> > numbers in, and you'ld only need to check a file or two from each of
> > them to be reasonably sure you'ld got all the updates.
> >
> > ? ? ? ?Cheers,
> >
> > ? ? ? ?Matthew
> >
> > --
> > Dr Matthew J Seaman MA, D.Phil. ? ? ? ? ? ? ? ? ? 7 Priory Courtyard
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Flat 3
> > PGP: http://www.infracaninophile.co.uk/pgpkey ? ? Ramsgate
> > JID: matt...@infracaninophile.co.uk ? ? ? ? ? ? ? Kent, CT11 9PW
> >
> 
> Thanks for the info Matthew. I think though that it is best for all to
> first make sure that the servers all updated before sending out all
> those security advisories.

I don't believe they're monitored like that.  If you want the updates
quickly, download the files referenced in the advisories.  My build was
done before my local cvsup server picked up the changes.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Panic on 7.4-RELEASE-p5

[Gary Palmer]

Hi,

My Soekris firewall just panic'd

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x14001d
fault code  = supervisor write, page not present
instruction pointer = 0x20:0xc06fd2d3
stack pointer   = 0x28:0xd63557bc
frame pointer   = 0x28:0xd63558a4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1869 (tcpdump)
trap number = 12
panic: page fault
KDB: stack backtrace:
db_trace_self_wrapper(c079bbfc,c07fb800,c078d680,d6355660,d6355660,...) at db_tr
ace_self_wrapper+0x26
panic(c078d680,c07b829c,c36d6d24,1,1,...) at panic+0xed
trap_fatal(c2c352d0,14,2,8,d63556c8,...) at trap_fatal+0x234
trap_pfault(c2b13620,0,c368f460,4,c36d6b00,...) at trap_pfault+0x27a
trap(d635577c) at trap+0x34e
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0xc06fd2d3, esp = 0xd63557bc, ebp = 0xd63558a4 ---
softdep_disk_io_initiation(c2ade474,1000,c3003738,1,c2aab9b8,...) at softdep_dis
k_io_initiation+0xb3
ffs_geom_strategy(c3003738,c2aab9b8,1000,edb000,0,...) at ffs_geom_strategy+0x10
c
ufs_strategy(d6355910,d6355910,c07f3980,c378bbdc,c2aab9b8,...) at ufs_strategy+0
x64
bufstrategy(c378bc9c,c2aab9b8,c368f460,c2aab9b8,c2bd46b4,...) at bufstrategy+0x2
e
bufwrite(c2aab9b8,c2aabb04,20,c368f460,0,...) at bufwrite+0xf4
cluster_wbuild(c378bbdc,4000,3b7,0,8,...) at cluster_wbuild+0x6c9
cluster_write(c378bbdc,c2bd46b4,edc000,0,7f,...) at cluster_write+0x715
ffs_write(d6355bc0,c07091e4,c378bc34,0,c378bc64,...) at ffs_write+0x837
VOP_WRITE_APV(c07e9500,d6355bc0,c368f460,c07a2aec,252,...) at VOP_WRITE_APV+0xa0
vn_write(c2e2adf4,d6355c54,c36d7500,0,c368f460,...) at vn_write+0x26f
dofilewrite(d6355c54,,,0,c2e2adf4,...) at dofilewrite+0x84
kern_writev(c368f460,4,d6355c54,d6355c74,1,...) at kern_writev+0x58
write(c368f460,d6355cf8,c,c0798e1b,39bfbd8f,...) at write+0x50
syscall(d6355d38) at syscall+0x1b9
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (4, FreeBSD ELF32, write), eip = 0x28354663, esp = 0xbfbfe85c, ebp =
 0xbfbfe878 ---
Uptime: 11d5h5m49s
Physical memory: 503 MB
Dumping 112 MB: 97 81 65 49 33 17 1
Dump complete
Automatic reboot in 1 seconds - press a key on the console to abort

fsck prevented the box from coming up automatically

/dev/ufs/varlog: PARTIALLY TRUNCATED INODE I=1496123
/dev/ufs/varlog: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY.
THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
ufs: /dev/ufs/varlog (/var/log)

Anyone seen this before?  Any clues?

I think this has happened on this box before (or a similar incident anyway,
I didn't have the console wired up the last time so I didn't get the above
trace).

I have a crash dump, although since this is a soekris box I don't have
debugging symbols available on the flash card.

Thanks,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Panic on 7.4-RELEASE-p5

[Gary Palmer]

On Thu, Jan 26, 2012 at 09:48:15PM -0500, Gary Palmer wrote:
> Hi,
> 
> My Soekris firewall just panic'd
> 

[snip]

> I think this has happened on this box before (or a similar incident anyway,
> I didn't have the console wired up the last time so I didn't get the above
> trace).

Just found old daily security e-mail with the last panic

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xc34b6a08
fault code  = supervisor write, page not present
instruction pointer = 0x20:0xc06faa58
stack pointer   = 0x28:0xd5096a34
frame pointer   = 0x28:0xd5096b18
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 38 (syncer)
trap number = 12
panic: page fault
KDB: stack backtrace:
db_trace_self_wrapper(c079803d,c07f6fa0,c0789da0,d50968e0,d50968e0,...) at 
db_trace_self_wrapper+0x26
panic(c0789da0,c07b423e,c2d087a4,1,1,...) at panic+0xed
trap_fatal(c1154000,c34b6000,2,0,c2b5985c,...) at trap_fatal+0x240
trap_pfault(d5096960,d5096964,0,173a,c2d08580,...) at trap_pfault+0x27a
trap(d50969f4) at trap+0x35e
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0xc06faa58, esp = 0xd5096a34, ebp = 0xd5096b18 ---
softdep_disk_io_initiation(c2b96730,1000,c302d84c,9,c2b96730,...) at 
softdep_disk_io_initiation+0xd8
ffs_geom_strategy(c302d84c,c2b96730,1000,f9fd3000,,...) at 
ffs_geom_strategy+0x13b
ufs_strategy(d5096b84,d5096b84,c07ef140,c37e29b4,c2b96730,...) at 
ufs_strategy+0x64
bufstrategy(c37e2a74,c2b96730,4000,0,c37e29b4,...) at bufstrategy+0x2e
bufwrite(c2b96730,,4ab2de0,0,d5096c1c,10,8,4000,0,1,d5096c04,e7f4,,4000,d5096c24,c0706a53,c37e2a0c,0,4000,0,0)
 at bufwrite+0xfe
vfs_bio_awrite(c2b96730,200012,0,c2cb7d20,0,...) at vfs_bio_awrite+0x51
ffs_syncvnode(c37e29b4,3,c37e2a74,d5096cf0,c05f5083,...) at ffs_syncvnode+0x2c5
ffs_fsync(d5096cd0,d5096cd0,c2cb7d20,c079e9a0,681,...) at ffs_fsync+0x1c
sched_sync(0,d5096d38,aa55aa55,aa55aa55,aa55aa55,...) at sched_sync+0x6f3
fork_exit(c05f4990,0,d5096d38) at fork_exit+0x8d
fork_trampoline() at fork_trampoline+0x8

Main difference seems to be the above panic came via the syncer but from
bufwrite on up the stack is the same

Was on 7.3-RELEASE back in July last year.

Thanks,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Panic on 7.4-RELEASE-p5

[Gary Palmer]

On Thu, Jan 26, 2012 at 07:09:06PM -0800, Jeremy Chadwick wrote:
> On Thu, Jan 26, 2012 at 09:48:15PM -0500, Gary Palmer wrote:
> > Hi,
> > 
> > My Soekris firewall just panic'd
> > 
> > Fatal trap 12: page fault while in kernel mode
> > fault virtual address   = 0x14001d
> > fault code  = supervisor write, page not present
> > instruction pointer = 0x20:0xc06fd2d3
> > stack pointer   = 0x28:0xd63557bc
> > frame pointer   = 0x28:0xd63558a4
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, def32 1, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 1869 (tcpdump)
> > trap number = 12
> > panic: page fault
> > KDB: stack backtrace:
> > db_trace_self_wrapper(c079bbfc,c07fb800,c078d680,d6355660,d6355660,...) at 
> > db_tr
> > ace_self_wrapper+0x26
> > panic(c078d680,c07b829c,c36d6d24,1,1,...) at panic+0xed
> > trap_fatal(c2c352d0,14,2,8,d63556c8,...) at trap_fatal+0x234
> > trap_pfault(c2b13620,0,c368f460,4,c36d6b00,...) at trap_pfault+0x27a
> > trap(d635577c) at trap+0x34e
> > calltrap() at calltrap+0x6
> > --- trap 0xc, eip = 0xc06fd2d3, esp = 0xd63557bc, ebp = 0xd63558a4 ---
> > softdep_disk_io_initiation(c2ade474,1000,c3003738,1,c2aab9b8,...) at 
> > softdep_dis
> > k_io_initiation+0xb3
> > ffs_geom_strategy(c3003738,c2aab9b8,1000,edb000,0,...) at 
> > ffs_geom_strategy+0x10
> > c
> > ufs_strategy(d6355910,d6355910,c07f3980,c378bbdc,c2aab9b8,...) at 
> > ufs_strategy+0
> > x64
> > bufstrategy(c378bc9c,c2aab9b8,c368f460,c2aab9b8,c2bd46b4,...) at 
> > bufstrategy+0x2
> > e
> > bufwrite(c2aab9b8,c2aabb04,20,c368f460,0,...) at bufwrite+0xf4
> > cluster_wbuild(c378bbdc,4000,3b7,0,8,...) at cluster_wbuild+0x6c9
> > cluster_write(c378bbdc,c2bd46b4,edc000,0,7f,...) at cluster_write+0x715
> > ffs_write(d6355bc0,c07091e4,c378bc34,0,c378bc64,...) at ffs_write+0x837
> > VOP_WRITE_APV(c07e9500,d6355bc0,c368f460,c07a2aec,252,...) at 
> > VOP_WRITE_APV+0xa0
> > vn_write(c2e2adf4,d6355c54,c36d7500,0,c368f460,...) at vn_write+0x26f
> > dofilewrite(d6355c54,,,0,c2e2adf4,...) at dofilewrite+0x84
> > kern_writev(c368f460,4,d6355c54,d6355c74,1,...) at kern_writev+0x58
> > write(c368f460,d6355cf8,c,c0798e1b,39bfbd8f,...) at write+0x50
> > syscall(d6355d38) at syscall+0x1b9
> > Xint0x80_syscall() at Xint0x80_syscall+0x20
> > --- syscall (4, FreeBSD ELF32, write), eip = 0x28354663, esp = 0xbfbfe85c, 
> > ebp =
> >  0xbfbfe878 ---
> > Uptime: 11d5h5m49s
> > Physical memory: 503 MB
> > Dumping 112 MB: 97 81 65 49 33 17 1
> > Dump complete
> > Automatic reboot in 1 seconds - press a key on the console to abort
> > 
> > fsck prevented the box from coming up automatically
> > 
> > /dev/ufs/varlog: PARTIALLY TRUNCATED INODE I=1496123
> > /dev/ufs/varlog: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY.
> > THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
> > ufs: /dev/ufs/varlog (/var/log)
> > 
> > Anyone seen this before?  Any clues?
> 
> Please shed some light as to your filesystem and disk setup.
> Partitioning details, any GEOM layers you use, you get the idea.
> The more verbose the better.  Please be sure to state which filesystems
> use softupdates and which do not (this matters a lot in this situation).

kryten# mount
/dev/ad0s1a on / (ufs, local, read-only)
devfs on /dev (devfs, local)
/dev/md0 on /etc (ufs, local)
/dev/md1 on /etc (ufs, local)
/dev/ufs/home on /home (ufs, local, soft-updates)
/dev/ufs/var on /var (ufs, local, soft-updates)
/dev/ufs/varlog on /var/log (ufs, local, soft-updates)
devfs on /var/db/dhcpd/dev (devfs, local)

(note the second md on /etc is an anomaly - there is normally only one and
 the daily security report already flagged that up as being different. 
 Haven't looked into where / why that happened yet.  This is a nanobsd
 build)

kryten# glabel list
Geom name: ad0s2a
Providers:
1. Name: ufsid/4ef571bfcc16bfa6
   Mediasize: 1015636480 (969M)
   Sectorsize: 512
   Mode: r0w0e0
   secoffset: 0
   offset: 0
   seclength: 1983665
   length: 1015636480
   index: 0
Consumers:
1. Name: ad0s2a
   Mediasize: 1015636480 (969M)
   Sectorsize: 512
   Mode: r0w0e0

Geom name: ad1s1d
Providers:
1. Name: ufs/varlog
   Mediasize: 107374182912 (100G)
   Sectorsize: 512
   Mode: r1w1e1
   secoffset: 0
   offset: 0
   seclength: 209715201
   length: 107374182912
   index: 0
Consumers:
1. Name: ad1s1d
   Mediasize: 107374182912 (100G)
   Sectorsize: 512
   Mode: r1w1e2

Geom name: ad1s1e
P

Re: Panic on 7.4-RELEASE-p5

[Gary Palmer]

On Thu, Jan 26, 2012 at 07:13:51PM -0800, Jeremy Chadwick wrote:
> On Thu, Jan 26, 2012 at 07:09:06PM -0800, Jeremy Chadwick wrote:
> > On Thu, Jan 26, 2012 at 09:48:15PM -0500, Gary Palmer wrote:
> > > Hi,
> > > 
> > > My Soekris firewall just panic'd
> > > 
> > > Fatal trap 12: page fault while in kernel mode
> > > fault virtual address   = 0x14001d
> > > fault code  = supervisor write, page not present
> > > instruction pointer = 0x20:0xc06fd2d3
> > > stack pointer   = 0x28:0xd63557bc
> > > frame pointer   = 0x28:0xd63558a4
> > > code segment= base 0x0, limit 0xf, type 0x1b
> > > = DPL 0, pres 1, def32 1, gran 1
> > > processor eflags= interrupt enabled, resume, IOPL = 0
> > > current process = 1869 (tcpdump)
> > > trap number = 12
> > > panic: page fault
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper(c079bbfc,c07fb800,c078d680,d6355660,d6355660,...) 
> > > at db_tr
> > > ace_self_wrapper+0x26
> > > panic(c078d680,c07b829c,c36d6d24,1,1,...) at panic+0xed
> > > trap_fatal(c2c352d0,14,2,8,d63556c8,...) at trap_fatal+0x234
> > > trap_pfault(c2b13620,0,c368f460,4,c36d6b00,...) at trap_pfault+0x27a
> > > trap(d635577c) at trap+0x34e
> > > calltrap() at calltrap+0x6
> > > --- trap 0xc, eip = 0xc06fd2d3, esp = 0xd63557bc, ebp = 0xd63558a4 ---
> > > softdep_disk_io_initiation(c2ade474,1000,c3003738,1,c2aab9b8,...) at 
> > > softdep_dis
> > > k_io_initiation+0xb3
> > > ffs_geom_strategy(c3003738,c2aab9b8,1000,edb000,0,...) at 
> > > ffs_geom_strategy+0x10
> > > c
> > > ufs_strategy(d6355910,d6355910,c07f3980,c378bbdc,c2aab9b8,...) at 
> > > ufs_strategy+0
> > > x64
> > > bufstrategy(c378bc9c,c2aab9b8,c368f460,c2aab9b8,c2bd46b4,...) at 
> > > bufstrategy+0x2
> > > e
> > > bufwrite(c2aab9b8,c2aabb04,20,c368f460,0,...) at bufwrite+0xf4
> > > cluster_wbuild(c378bbdc,4000,3b7,0,8,...) at cluster_wbuild+0x6c9
> > > cluster_write(c378bbdc,c2bd46b4,edc000,0,7f,...) at cluster_write+0x715
> > > ffs_write(d6355bc0,c07091e4,c378bc34,0,c378bc64,...) at ffs_write+0x837
> > > VOP_WRITE_APV(c07e9500,d6355bc0,c368f460,c07a2aec,252,...) at 
> > > VOP_WRITE_APV+0xa0
> > > vn_write(c2e2adf4,d6355c54,c36d7500,0,c368f460,...) at vn_write+0x26f
> > > dofilewrite(d6355c54,,,0,c2e2adf4,...) at dofilewrite+0x84
> > > kern_writev(c368f460,4,d6355c54,d6355c74,1,...) at kern_writev+0x58
> > > write(c368f460,d6355cf8,c,c0798e1b,39bfbd8f,...) at write+0x50
> > > syscall(d6355d38) at syscall+0x1b9
> > > Xint0x80_syscall() at Xint0x80_syscall+0x20
> > > --- syscall (4, FreeBSD ELF32, write), eip = 0x28354663, esp = 
> > > 0xbfbfe85c, ebp =
> > >  0xbfbfe878 ---
> > > Uptime: 11d5h5m49s
> > > Physical memory: 503 MB
> > > Dumping 112 MB: 97 81 65 49 33 17 1
> > > Dump complete
> > > Automatic reboot in 1 seconds - press a key on the console to abort
> > > 
> > > fsck prevented the box from coming up automatically
> > > 
> > > /dev/ufs/varlog: PARTIALLY TRUNCATED INODE I=1496123
> > > /dev/ufs/varlog: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY.
> > > THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
> > > ufs: /dev/ufs/varlog (/var/log)
> > > 
> > > Anyone seen this before?  Any clues?
> > 
> > Please shed some light as to your filesystem and disk setup.
> > Partitioning details, any GEOM layers you use, you get the idea.
> > The more verbose the better.  Please be sure to state which filesystems
> > use softupdates and which do not (this matters a lot in this situation).
> 
> I forgot to mention -- if the storage disk is physical and isn't
> something like a CF card or similar, if you could provide smartctl -a
> output from any attached disks (please be sure to state which output
> correlates with which disk), I can review that to ensure there isn't an
> underlying disk issue.

kryten# smartctl -a /dev/ad1
smartctl 5.42 2011-10-20 r3458 [FreeBSD 7.4-RELEASE-p5 i386] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family: Hitachi Travelstar 5K250
Device Model: Hitachi HTS542512K9SA00
Serial Number:071202BB0200WBHGW9XC
LU WWN Device Id: 5 000cca 530d4db41
Firmware Version: BB2OC31P
User Capacity:120,034,123,776 bytes [120 GB]

Re: Panic on 7.4-RELEASE-p5

[Gary Palmer]

On Fri, Jan 27, 2012 at 01:29:23PM +0100, Peter Maloney wrote:
> On 01/27/2012 04:43 AM, Gary Palmer wrote:
> >
> >   After scanning selected spans, do NOT read-scan remainder of disk.
> > If Selective self-test is pending on power-up, resume after 0 minute delay.
> >
> > I noticed a while ago that there were some "bad" sectors on the disk, and
> > at the time they were under the swap partition if my math was correct,
> > and the box never swaps so it wasn't a problem.  I don't know if
> > the errors above are the same ones I saw earlier or not.
> >
> > There were no read or write errors on the console prior to the panic
> > earlier today.  In fact the previos output on the console relates to
> > the last reboot for a software upgrade (fixing some packages) 11
> > days prior.  The only thing in logs going back to November relating
> > to ad1 are boot messages.
> >
> > Thanks,
> >
> > Gary
> >
> 
> Unmount your swap, and then write zeros to it to relocate the bad sectors.
> 
> in one shell:
> gstat -I 100ms -f da#p#
> 
> in another:
> swapoff /dev/da#p#
> sysctl kern.geom.debugflags=0x10
> dd if=/dev/zero of=/dev/da#p# bs=1M
> (eventually it stops saying end of device or no space left; at this
> point I am not sure if you should then continue writing where it stopped
> in 512 byte blocks, or if it wrote a partial 1M in the last 1M)
> 
> Watch first shell. If the speed goes up, settles at a certain number,
> then wildly goes down low and back up to that number, it is possibly
> working.
> 
> Then repeat. If the same wild fluctuations happen, then the drive didn't
> relocate enough, because it is trying to keep some semi-bad ones, or
> they are only bad when reading. If it is just settling at a speed and
> staying there, then it is probably successful. I don't know how reliable
> it is. I have found it to be 100% reliable in my testing though. But
> some/most disks lie to you on the "relocated sector count".
> 
> And then remount the swap and change that kernel parameter back.
> sysctl kern.geom.debugflags=0
> swapon /dev/da#p#
> 
> 
> Your relocated sector count:
> 
>   5 Reallocated_Sector_Ct   0x0033   100   100   005Pre-fail  Always  
>  -   0
> 
> 
> 
> However, this does not fix your disk. eg. If you have heads grinding the
> platter, you have dust flying around, and your disk will get worse.
> 
> Be VERY careful using dd to write directly to disks. If you use the
> wrong slice, or you use the main device without slices and miscalculate,
> bad things happen. This is why that kernel parameter was set to stop you.

Hi Peter,

I did things a little differently.  When I checked swapinfo, apparently I
set the swap partition up just purely to act as a dump device - it wasn't
used as swap.  So I tested it:

# recoverdisk /dev/ad1s1b /dev/ad1s1b
startsize block-len state  done remaining% done
628097024 1040384   1040384 0 629137408 0 100.0
Completed

smartctl still reports:

  5 Reallocated_Sector_Ct   0x0033   100   100   005Pre-fail  Always   
-   0

I then did a read test across the whole disk with no errors

# recoverdisk /dev/ad1 /dev/null
startsize block-len state  done remaining% done
 120033640448  483328483328 0  120034123776 0 100.0
Completed

Reallocated_Sector_Ct is still the same

I dunno where the problems are/were, but apparently I cannot hit them now
through just reading the disk or writing to swap.

Thanks,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Panic on 7.4-RELEASE-p5

[Gary Palmer]

On Sun, Jan 29, 2012 at 08:41:38PM -0500, Gary Palmer wrote:
> On Fri, Jan 27, 2012 at 01:29:23PM +0100, Peter Maloney wrote:
> > On 01/27/2012 04:43 AM, Gary Palmer wrote:
> > >
> > >   After scanning selected spans, do NOT read-scan remainder of disk.
> > > If Selective self-test is pending on power-up, resume after 0 minute 
> > > delay.
> > >
> > > I noticed a while ago that there were some "bad" sectors on the disk, and
> > > at the time they were under the swap partition if my math was correct,
> > > and the box never swaps so it wasn't a problem.  I don't know if
> > > the errors above are the same ones I saw earlier or not.
> > >
> > > There were no read or write errors on the console prior to the panic
> > > earlier today.  In fact the previos output on the console relates to
> > > the last reboot for a software upgrade (fixing some packages) 11
> > > days prior.  The only thing in logs going back to November relating
> > > to ad1 are boot messages.
> > >
> > > Thanks,
> > >
> > > Gary
> > >
> > 
> > Unmount your swap, and then write zeros to it to relocate the bad sectors.
> > 
> > in one shell:
> > gstat -I 100ms -f da#p#
> > 
> > in another:
> > swapoff /dev/da#p#
> > sysctl kern.geom.debugflags=0x10
> > dd if=/dev/zero of=/dev/da#p# bs=1M
> > (eventually it stops saying end of device or no space left; at this
> > point I am not sure if you should then continue writing where it stopped
> > in 512 byte blocks, or if it wrote a partial 1M in the last 1M)
> > 
> > Watch first shell. If the speed goes up, settles at a certain number,
> > then wildly goes down low and back up to that number, it is possibly
> > working.
> > 
> > Then repeat. If the same wild fluctuations happen, then the drive didn't
> > relocate enough, because it is trying to keep some semi-bad ones, or
> > they are only bad when reading. If it is just settling at a speed and
> > staying there, then it is probably successful. I don't know how reliable
> > it is. I have found it to be 100% reliable in my testing though. But
> > some/most disks lie to you on the "relocated sector count".
> > 
> > And then remount the swap and change that kernel parameter back.
> > sysctl kern.geom.debugflags=0
> > swapon /dev/da#p#
> > 
> > 
> > Your relocated sector count:
> > 
> >   5 Reallocated_Sector_Ct   0x0033   100   100   005Pre-fail  Always
> >-   0
> > 
> > 
> > 
> > However, this does not fix your disk. eg. If you have heads grinding the
> > platter, you have dust flying around, and your disk will get worse.
> > 
> > Be VERY careful using dd to write directly to disks. If you use the
> > wrong slice, or you use the main device without slices and miscalculate,
> > bad things happen. This is why that kernel parameter was set to stop you.
> 
> Hi Peter,
> 
> I did things a little differently.  When I checked swapinfo, apparently I
> set the swap partition up just purely to act as a dump device - it wasn't
> used as swap.  So I tested it:
> 
> # recoverdisk /dev/ad1s1b /dev/ad1s1b
> startsize block-len state  done remaining% 
> done
> 628097024 1040384   1040384 0 629137408 0 
> 100.0
> Completed
> 
> smartctl still reports:
> 
>   5 Reallocated_Sector_Ct   0x0033   100   100   005Pre-fail  Always  
>  -   0
> 
> I then did a read test across the whole disk with no errors
> 
> # recoverdisk /dev/ad1 /dev/null
> startsize block-len state  done remaining% 
> done
>  120033640448  483328483328 0  120034123776 0 
> 100.0
> Completed
> 
> Reallocated_Sector_Ct is still the same
> 
> I dunno where the problems are/were, but apparently I cannot hit them now
> through just reading the disk or writing to swap.


FYI I just ran both

smartctl -t short /dev/ad1

and

smartctl -t long /dev/ad1

and neither found any problems

SMART Self-test log structure revision number 1
Num  Test_DescriptionStatus  Remaining  LifeTime(hours)  
LBA_of_first_error
# 1  Extended offlineCompleted without error   00% 33819 -
# 2  Short offline   Completed without error   00% 33818 -

Thanks,

Gary

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs arc and amount of wired memory

[Gary Palmer]

On Wed, Feb 08, 2012 at 11:18:02PM +0200, Andriy Gapon wrote:
> on 08/02/2012 22:50 Jeremy Chadwick said the following:
> > Politely -- recommending this to a user is a good choice of action, but
> > the problem is that no user, even an experienced user, is going to know
> > what all of the "Types" (vmstat -m) or "ITEMs" (vmstat -z) correlate
> > with on the system.
> 
> I see no problem with users sharing the output and asking for help 
> interpreting
> it.  I do not know of any easier way to analyze problems like this one.

Also, since we are looking for gigs of memory it should be relatively easy
to look down the 'Size' or 'MemUse' columns and identify likely candidates
for "eating gobs of memory".  The user doesn't need to know what the rest
of the data means, and can ask what that line means and how to fix it

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: siisch1: Error while READ LOG EXT

[Gary Palmer]

On Thu, Feb 09, 2012 at 07:22:40AM -0800, Jeremy Chadwick wrote:
> I have to assume that devices connected on a port multiplier show up on
> a separate scbusX number.  This is from your original mail:
> 
> > # camcontrol devlist
> >at scbus0 target 0 lun 0 (pass0,ada0)
> >at scbus0 target 1 lun 0 (pass1,ada1)
> >at scbus0 target 2 lun 0 (pass2,ada2)
> >at scbus0 target 3 lun 0 (pass3,ada3)
> > at scbus0 target 15 lun 0 (pass4,pmp1)
> >at scbus1 target 0 lun 0 (pass5,ada4)
> >at scbus1 target 1 lun 0 (pass6,ada5)
> >at scbus1 target 2 lun 0 (pass7,ada6)
> >at scbus1 target 3 lun 0 (pass8,ada7)
> >at scbus1 target 4 lun 0 (pass9,ada8)
> > at scbus1 target 15 lun 0 (pass10,pmp0)
> > at scbus4 target 0 lun 0 (pass11,da0)
> >at scbus4 target 0 lun 1 (pass12,da1)
> >at scbus4 target 16 lun 0 (pass13)
> > at scbus5 target 0 lun 0 (pass14,da2)
> > at scbus6 target 0 lun 0 (pass15,ada9)
> > at scbus7 target 0 lun 0 (pass16,ada10)
> > at scbus8 target 0 lun 0 (pass17,ada11)
> >at scbus11 target 0 lun 0 (pass18,ada12)
> 
> Based on this, and assuming my understanding of how this setup works --
> and please note I could be wrong, these port multiplier things I have no
> familiarity with personally -- but it looks (to me) like this:
> 
> scbus5
>   --> Not sure what this thing is
>   --> Disk or "thing" da2

3ware 9650SE controller (twa driver I beleive)

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: disk devices speed is ugly

[Gary Palmer]

On Mon, Feb 13, 2012 at 07:36:25AM +0100, Alex Samorukov wrote:
> On 02/13/2012 06:27 AM, Adrian Chadd wrote:
> >On 12 February 2012 09:34, Alex Samorukov  wrote:
> >
> >>Yes. But it will nit fix non-cached access to the disk (raw) devices. And
> >>this is the main reason why ntfs-3g and exfat are much slower then working
> >>on Linux.
> >But _that_ can be fixed with the appropriate application of a sensible
> >caching layer.
> With every application?  :) Are you know anyone who wants to do this? At 
> least for 3 fuse filesystems.

The filesystem is the *BEST* place to do caching.  It knows what metadata
is most effective to cache and what other data (e.g. file contents) doesn't
need to be cached.  Any attempt to do this in layers between the FS and
the disk won't achieve the same gains as a properly written filesystem. 
e.g. in a UFS implementation the disk layer may see a lot of I/Os for 
blocks, not necessarily sequential, as a program lists a directory and stats
all the files which pulls in the inode tables.  The filesystem knows that it
needs the inode tables and is likely to need not only the current inode table
disk block but subsequent ones also, and instead of requesting the disk sector
that it needs to service the immediate stat(2) request but maybe the next few
also.  Without that insight into whats going on it is difficult to see how a
highly effective cache could be done at the geom layer.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: disk devices speed is ugly

[Gary Palmer]

On Mon, Feb 13, 2012 at 03:50:36PM +0100, Alex Samorukov wrote:
> On 02/13/2012 02:28 PM, Gary Palmer wrote:
> >>>
> >>>>Yes. But it will nit fix non-cached access to the disk (raw) devices. 
> >>>>And
> >>>>this is the main reason why ntfs-3g and exfat are much slower then 
> >>>>working
> >>>>on Linux.
> >>>But _that_ can be fixed with the appropriate application of a sensible
> >>>caching layer.
> >>With every application?  :) Are you know anyone who wants to do this? At
> >>least for 3 fuse filesystems.
> >The filesystem is the *BEST* place to do caching.  It knows what metadata
> >is most effective to cache and what other data (e.g. file contents) doesn't
> >need to be cached.  Any attempt to do this in layers between the FS and
> >the disk won't achieve the same gains as a properly written filesystem.
> >e.g. in a UFS implementation the disk layer may see a lot of I/Os for
> >blocks, not necessarily sequential, as a program lists a directory and 
> >stats
> >all the files which pulls in the inode tables.  The filesystem knows that 
> >it
> >needs the inode tables and is likely to need not only the current inode 
> >table
> >disk block but subsequent ones also, and instead of requesting the disk 
> >sector
> >that it needs to service the immediate stat(2) request but maybe the next 
> >few
> >also.  Without that insight into whats going on it is difficult to see how 
> >a
> >highly effective cache could be done at the geom layer.
> I think we are playing in a "captain obvious".
> 
> I have nothing against statement that FS is a "best place for caching". 
> Also - i am absolutely sure that its better to have kernel space fs 
> driver then FUSE one.
> 
> But unfortunately there is no kernel space driver for the exfat, kernel 
> driver for ntfs is ugly and buggy (and r/o) and i don`t think that 
> anyone is going to change this.
> 
> And i really don`t understand why are you trying to tell that it cannot 
> be effective when its so easy to proof that it can. Just try this with 
> fuse based filesystems in Linux, and you will get speed compared to 
> underlying device (especially on relatively slow USB devices). Then try 
> the same code on FreeBSD to see how ugly things are.
> 
> And yes, in ideal world ever fs needs to have good written cache 
> implementation and kernel should not care about caching raw devices at 
> all. But as i mentioned before - there is no kernel-space drivers with a 
> good cache implementation for this 2 widely used systems (and probably 
> not only). Linux is a good example that device-level caching works, and 
> works fine.

Please re-read my message.  At no time did I say that caching below the
FS could not provide speed improvements.  I said it could not be as
effective as a properly implemented filesystem.  I'm sure if you throw
memory at it, a geom layer cache can provide substantial speed ups.  However
I strongly suspect that a proper FS cache would provide a better memory/hit
ratio than a geom layer cache.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 157k interrupts per second causing 60% CPU load on idle system

[Gary Palmer]

On Tue, Mar 20, 2012 at 11:10:10PM +1030, Matt Thyer wrote:
> On 20 March 2012 22:24, Ivan Voras  wrote:
> 
> > On 20 March 2012 12:52, Matt Thyer  wrote:
> > > On 20 March 2012 21:12, Ivan Voras  wrote:
> > >>
> > >> On 20/03/2012 06:26, Matt Thyer wrote:
> > >> > I've upgraded my FreeBSD-STABLE NAS from r225723 (22nd Sept 2011) to
> > >> > r232477 (4th Mar 2012) and am finding that a system process called
> > >> > "intr"
> > >> > is now constantly using about 60% of 1 CPU starting a short time after
> > >> > reboot (possibly triggered by use of the samba server).
> > >> >
> > >> > When this starts, systat -vm 1 says that the system is 85% idle and
> > 14%
> > >> > interrupt handling.
> > >> > It says that there's around 157k interrupts per second.
> > >> >
> > >>
> > >> Ok, but *which* interrupt is getting triggered? Please send the output
> > >> of "vmstat -i".
> > >>
> > >>
> > > interrupt  total   rate
> > > irq16: uhci0+ 3392184862 126692
> >
> > Ok, something's probably wrong with USB. Can you disable it in BIOS?
> >
> >
> > > cpu0: timer 53549677   1999
> > > irq256: mps0 2643187 98
> > > irq257: re0  5508108205
> > > irq258: ahci0 160717  6
> > > cpu1: timer 53525300   1999
> > > cpu2: timer 53525300   1999
> > > cpu3: timer 53525296   1999
> > > Total 3614622447 134999
> > >
> >
> 
> I did just update the BIOS at about the same time so the difference may be
> due to that change.
> 
> I'll try a few things such as:
> 
> - Unplugging any USB things (I've only got a keyboard plugged in).
> - Downgrade BIOS.
> 
> I'll get back to you all soon.

It would be interesting to know if there are other devices on irq16 also.

grep 'irq 16' /var/run/dmesg.boot

I think the '+' on the irq16 line from vmstat means the interrupt is
shared, but the man page doesn't mention it so I'm not 100% sure

Thanks,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.0 hangs on heavy I/O

[Gary Palmer]

On Tue, May 29, 2012 at 09:26:32PM +0200, Kees Jan Koster wrote:
> Dear All,
> 
> I seem to have a problem where really heavy disk I/O is drowning my machine. 
> I see hangs in the shell where I am logged on using ssh. Network connections 
> get dropped for no apparent reason and some HTTP requests are served really 
> slowly. Profiling the app code shows that the hangs are in completely random 
> places. Operations that are no more than a few lines of code apart suddenly 
> take seconds to complete.
> 
> In my search I seem to find that my machine is quite slow on the disk. I find 
> that rather odd, given that the device in question is an SSD drive and it is 
> a good bit faster than the WD drive that used to carry the data set that is 
> accessed heavily. This drive is doing 1.5 times the throughput, but the hangs 
> have not gone away.
> 
> To clarify, the data set used to live on ada2 (see the devlist below) which 
> is a spinning disk. When I experienced intermittent hangs I plugged in an SSD 
> drive (ada3 on the devlist) and moved the data there. This improved the MB's 
> per second that are being written (it is mostly-write data) but has not 
> changed the hangs. If anything, they got worse since.
> 
> Using gstat I notice that I/O service time is quite high. From the gstat 
> below you can see that it takes just over 2s to servr the requests. The L(q) 
> seems to never drop far below 100 and %busy hovers around 100% all day long. 
> Can someone please help me troubleshoot that further? What can I do to make 
> the underlying problem visible?
> 
> I should mention all data is referenced through cross-mountpoint symlinks, 
> would that make a difference? Should I use canonical paths in the code 
> instead?
> 
> All file systems are mounted "noatime, soft-updates".
> 
> Details:
> 
> # uname -a 
> FreeBSD cumin.java-monitor.com 9.0-STABLE FreeBSD 9.0-STABLE #0: Mon Mar 26 
> 14:30:19 UTC 2012 
> kjkos...@cumin.java-monitor.com:/usr/obj/usr/src/sys/CUMIN  amd64
> # gstat -f 'ada[0-3]$' -b
> dT: 1.001s  w: 1.000s  filter: ada[0-3]$
>  L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/w   %busy Name
> 0  0  0  00.0  0  00.00.0  ada0
> 0  0  0  00.0  0  00.00.0  ada1
> 0  0  0  00.0  0  00.00.0  ada2
>   103273  0  00.0273  34630   2062  121.9  ada3
> # camcontrol devlist
> at scbus1 target 0 lun 0 (pass0,ada0)
>   at scbus2 target 0 lun 0 (pass1,ada1)
>   at scbus3 target 0 lun 0 (pass2,ada2)
>   at scbus4 target 0 lun 0 (pass3,ada3)
>   at scbus7 target 0 lun 0 (pass4,cd0)
>   at scbus8 target 0 lun 0 (pass5,cd1)


Check the SSD for its internal block size and make sure your filesystem
and partitions are aligned with the disk block size.  Unless there
is something wrong with your SATA controller I'd expect a lot more than
273 IOPS/sec and ~30MByte/sec from a SSD.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9.0 hangs on heavy I/O

[Gary Palmer]

On Tue, May 29, 2012 at 10:59:58PM +0200, Kees Jan Koster wrote:
> Dear Gary,
> 
> >> # camcontrol devlist
> >> at scbus1 target 0 lun 0 (pass0,ada0)
> >>   at scbus2 target 0 lun 0 (pass1,ada1)
> >>   at scbus3 target 0 lun 0 (pass2,ada2)
> >>   at scbus4 target 0 lun 0 (pass3,ada3)
> >>   at scbus7 target 0 lun 0 (pass4,cd0)
> >>   at scbus8 target 0 lun 0 (pass5,cd1)
> > 
> > Check the SSD for its internal block size and make sure your filesystem
> > and partitions are aligned with the disk block size.  Unless there
> > is something wrong with your SATA controller I'd expect a lot more than
> > 273 IOPS/sec and ~30MByte/sec from a SSD.
> 
> 
> Thank you for suggesting this. However, I recently went through my file 
> systems to fix disk alignment. I ended up aligning them to 1M blocks, which 
> raised the throughput from 6M/s to about 60-80MB/s which is what I am seeing 
> today.
> 
> # gpart show
> ...
> =>   34  250069613  ada3  GPT  (119G)
>  34   2014- free -  (1M)
>2048  250067599 1  freebsd-ufs  (119G)
> 
> Do you think I need to revisit alignment?

I don't have the specific device you have, but looking at the test results
from a random site for the same drive and firmware, they got 465 random IOPS
for a 0.5KB block size and a lot more than 60-80MB/sec.  I get 60-80MB/sec
from a WD green drive in a pure write situation (admitedly using ZFS),
so I'm a bit surprised you're seeing similar performance from your SSD, 
although now I look at it, the drive appears to be an older model.  It could
be that you're running into issues where the drive is working hard as
all the flash blocks need to be erased before reuse.  You may get some
improvement if you tweak the filesystem block size to the SSD block size.
TRIM may also help if the drive supports it.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Why Are You Using FreeBSD?

[Gary Palmer]

On Thu, May 31, 2012 at 04:22:37PM +0200, Damien Fleuriot wrote:
> On 5/31/12 4:01 PM, Jim Ohlstein wrote:
> > To add others, in no particular order:
> > 
> > Ease of upgrade. While some have noted that binary upgrades are easier
> > on Debian, it's far and away superior, IMMHO, to have a locally compiled
> > system. Many Linux distros have no upgrade path short of a wipe and
> > re-install.
> > 
> 
> Far superior, check, FAR MORE TIME CONSUMING, check as well !
> 
> 
> Also, I don't get your "linux distros have no upgrade path short of a
> full reinstall" bit ?

I don't know about "many", but RHEL specifically states that upgrading
from RHEL4.x to 5.x, or 5.x to 6.x, is not supported and that you should
wipe and reinstall the system.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Why Are You NOT Using FreeBSD ?

[Gary Palmer]

On Fri, Jun 01, 2012 at 05:12:14PM -0700, Dave Hayes wrote:
> Mehmet Erol Sanliturk  writes:
> > If you are NOT using FreeBSD for any area or some areas , would you please
> > list those areas with most important first to least important last ?
> 
> 1) I don't use FreeBSD for virtualization as the host OS. I really want
> to, becaus I want to be able to somewhat trust the kernel hosting my
> virtual machines. FreeBSD technology, support, and documentation for
> this idea appears unavailable. 

Have you looked at VirtualBox?  /usr/ports/emulators/virtualbox-ose

Its not a fully featured replacement for vSphere (e.g. no equivalent
of vMotion) but it is a perfectly workable virtualisation solution
for a number of situations.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 8-STABLE on R620 w/ X520-DA2/Intel 82599

[Gary Palmer]

On Fri, Jun 29, 2012 at 10:50:52AM -0400, Rick Miller wrote:
> Hi All,
> 
> I have 2 hosts, HP DL360 G8 and Dell R620.  Both have the
> X520-DA2/Intel 82599 10G Fiber NIC.  Both also have the same FreeBSD
> 8-STABLE image.  The Dell displays the following in dmesg and we are
> unable to configure the ix0 or ix1 interfaces where the HP works just
> fine.  Wondering if anyone else has experienced this?
> 
> pci4:  at device 0.0 (no driver attached)
> pci4:  at device 0.1 (no driver attached)

Please see

http://lists.freebsd.org/pipermail/freebsd-net/2012-June/032579.html

it may be of some assistance.  It looks like adding the Dell specific
PCI IDs may be all thats required.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Make ZFS auto-destroy snapshots when the out of space?

[Gary Palmer]

On Sun, May 30, 2010 at 08:33:40PM -0400, David Magda wrote:
> On May 29, 2010, at 16:07, Kirk Strauser wrote:
> 
> >I'd propose standardizing on an attribute like  
> >org.freebsd:allowautodestroy. Modify ZFS's disk full behavior [...]   
> >Also run a daily periodic script to ensure that the free space stays  
> >below a configurable threshold each day so that ZFS isn't constantly  
> >butting up against completely full drives.
> 
> 
> Why not simply have a script that runs and checks for pool usage and  
> then deletes snapshots with that attribute if necessary? Why do you  
> need to have have it built into ZFS?

Suggestion: zfs can have settings that trigger an event to be delivered
to devd when a filesystem hits a certain percentage full (or under a
certain percentage free space left).  That way you can have the event
triggered at the filesystem level, which I believe is the correct thing
to do (so you're not polling), and also delivers the level of control
you want.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Upcoming Releases Schedule...

[Gary Palmer]

On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote:
>  Without input from the current release team extending the support  
> schedule is not possible.

Inquiry - is release team the constraint?

Or to put it another way, what to you is "support" in terms of
FreeBSD releases?

As far as I am aware, if you stick on a RELENG_X_Y_Z_RELEASE tag 
then the most you get is security fixes.  No new features,
no new drivers, no bugfixes.  So if I am interpreting things
correctly, you are asking for security fixes to be ported to
RELEASE tagged branches for longer?

So is release team the contrained resource in your problem?
I am not denying that *any* part of the FreeBSD team is not
resource constrained, but I'm wondering if you're examining
the correct area. 

Note: I am not up on the internals of modern FreeBSD
release engineering and maintenance nor the relationship
between "staff" functions, so I may be barking up the wrong
telephone pole.

Regards,

Gary

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Upcoming Releases Schedule...

[Gary Palmer]

On Sat, Sep 20, 2008 at 11:37:25AM +0100, Robert Watson wrote:
> You already identified the end goal: extend support lifetimes.  You placed 
> constraint on how that could be accomplished: you were going to do the 
> work.

Actually Robert, to be fair to Jo, I suspect it is more proper to say
"$COMPANY wants extended support lifetimes.  What can I, or $COMPANY,
 do to help make that happen?".  I think its been misinterpreted as
Jo saying "Let me do the work".  He has offered to see if his company
will let him help on company time, but I do not believe the constraint
is quite as you phrased it above.  The goal is the same, but throw it
open to a wider contraint set - what resources does the project need
to make it happen?  Money?  Test labs?  Server hosting?  Twinkies?

Rgeards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: buildworld fails immediately

[Gary Palmer]

On Wed, Sep 24, 2008 at 08:43:20PM -0700, Jeremy Chadwick wrote:
> On Wed, Sep 24, 2008 at 07:03:15PM -0700, Jason C. Wells wrote:
> > I am trying to build RELENG_6.  I receive the following errors.
> >
> > [EMAIL PROTECTED] /usr/src]# make buildworld
> > "/dev/null", line 4: Need an operator
> > "/dev/null", line 6: Need an operator
> > "/dev/null", line 8: Need an operator
> > "/dev/null", line 9: Need an operator
> > "/dev/null", line 11: Need an operator
> > "/dev/null", line 12: Need an operator
> > "/dev/null", line 13: Need an operator
> > "/dev/null", line 15: Need an operator
> > "/dev/null", line 16: Need an operator
> > "/dev/null", line 18: Need an operator
> >
> >
> > I figured I got a partial update or something.  Re-supping didn't help.   
> > I am building on 6.2-RELEASE inside a jail.  Jails are new for me so  
> > maybe I missed something there.
> 
> Your previous mail (Subject: CPUTYPE Now Required?) answers what's
> happening quite clearly.  Look closely at the -f argument being
> passed to make.
> 
> I cannot help you with jails, as I know nothing about them.  But it
> appears to me you have a very broken make.conf or build environment.

Actually, this is in Makefile.inc1

_CPUTYPE!=  MAKEFLAGS= CPUTYPE=${_TARGET_CPUTYPE} ${MAKE} \
-f /dev/null -m ${.CURDIR}/share/mk -V CPUTYPE

(line 141 in my 6.3 era source tree)

Which I think you'll find ends up with the make command the user
posted in the other e-mail.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sysctl maxfiles

[Gary Palmer]

On Sat, Sep 27, 2008 at 07:05:08PM +1000, Aristedes Maniatis wrote:
> 
> On 27/09/2008, at 1:02 PM, Jeremy Chadwick wrote:
> 
> >Anyway, I'd like to know why you have so many fds open  
> >simultaneously in
> >the first place.  We're talking over 11,000 fds actively open at  
> >once --
> >this is not a small number.  What exactly is this machine doing?  Are
> >you absolutely certain tuning this higher is justified?  Have you  
> >looked
> >into the possibility that you have a program which is exhausting fds  
> >by
> >not closing them when finished?  (Yes, this is quite common; I've seen
> >bad Java code cause this problem on Solaris.)
> 
> 
> Well, there was a runaway process which looks like it is leaking fds.  
> We haven't solved it yet, but the fact that the maxfiles per machine  
> and the maxfiles per process were so close together was really causing  
> us grief for a while.
> 
> 
> 
> >You're asking for trouble setting these values to the equivalent of
> >unlimited.  Instead of asking "what would happen", you should be  
> >asking
> >"why would I need to do that".
> >
> >Regarding memory implications, the Handbook goes over it.
> 
> Unfortunately I've been unable to find it.  While we fix the fd leak  
> I'd like to know how high I can push these numbers and not cause other  
> problems.

At least one port recommends you set

kern.maxfiles="4"

in /boot/loader.conf.  I think its one of the GNOME ports.  I'm pretty
confident you can run that without too many problems, and maybe go higher,
but if you really want to know the limit its probably kernel memory and
that will depend on your workload.

Solving the fd leak is by far the safest path.  Note that tracking
that many files is probably affecting your application performance
in addition to hurting the system.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 7.1-PRERELEASE : bad network performance (nfe0)

[Gary Palmer]

On Sun, Sep 28, 2008 at 01:43:12PM -0400, [EMAIL PROTECTED] wrote:
> I have the same problem on a Dell Poweredge SC440 when I transferred over
> 50GB
> from a FreeBSD 5.4 box to my new Dell running 7.1.  Used a crossover cable
> and
> the link was 1000 full duplex, but could only get about 10M/s.  Very odd.
> Did a
> tcpdump and saw lots of bad checksum errors.
> 
> What other troubleshooting steps can we take?  What could be the problem?

Please post the first few lines of ifconfig for bge0.  I'm suspecting
you'll see something like

em1: flags=8843 mtu 1500
options=1b

(yes, I know thats an em, not bge, but I don't have any bge's around
 here)

Note that the options line say that receive and transmit checksum
offloading is enabled.  This means that for packets transmitted
by this system, tcpdump will show checksum errors as the kernel
is not generating the checksums, the ethernet card will.  Since
tcpdump is seeting the packet before the ethernet card does its
magic, you get the checksum errors on transmit.  Received packets
should be fine though.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: recommended setup for amd64 7-STABLE with ZFS, Samba 3.2 and possibly ACLs?

[Gary Palmer]

On Tue, Sep 30, 2008 at 03:46:05AM -0700, Jeremy Chadwick wrote:
> > - email (imap)
> 
> I've had good experience with dovecot; I tend to stay away from Cyrus
> products (disgusting code with a history of security issues), and
> Courier (no interest).

Also avoid /usr/ports/mail/imap-uw.  I'm not sure if it can be configured
to do otherwise, but by default it turns every file in the users home
directory into an IMAP folder which can be opened and read.  It might
sound fine, but if you ever want to migrate off onto something else
it becomes an issue.

Regards,

Gary

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: resource leak

[Gary Palmer]

On Wed, Oct 01, 2008 at 04:50:46AM -0700, Jeremy Chadwick wrote:
> On Wed, Oct 01, 2008 at 07:41:56AM -0400, Stephen Clark wrote:
> > Hello List,
> >
> > I am running into a strange problem that points to a resource leak. The 
> > problem manifests itself after one of our remote systems has been up 
> > around 100 days.
> > The symptom is that it appears no new processes can be spawned. If I try to
> > ssh to the unit, I can see the 3-way tcp handshake and then no more traffic.
> > Examining log files, like cron, etc show that when this happens no more 
> > entries
> > are written into the cron log. The unit is acting as a firewall, router 
> > and vpn appliance these functions continue to work. We have a C 
> > application that is periodically started out of a shell script that 
> > reports various information about the system, it stops reporting, while 
> > vpns, ospf routing, and ipfilter firewalling continue to work and write 
> > into their logfiles.
> >
> > My question is how do I monitor the various resources in the system that 
> > could
> > prevent the spawning of a new process?
> 
> Periodically logging "ps -auxw" output to a file would be useful, as
> ideally you'd gradually see the list get longer and longer over time;
> it's possible you have many zombie processes as a result of a parent
> which is not reaping its children (calling waitpid(2) or its friends).

"ps alxw" may be of interest in addition to "ps auxw" as it displays what
the processes are waiting on.  It could conceivably be a problem of some
kind at the filesystem level.  I've seen situations before where a problem
escalates to the point where "ls /" hangs, and at that point you're stuck
with an unresponsive box.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: pf rules not being loaded during boot on 7.1-PRERELEASE

[Gary Palmer]

On Fri, Oct 03, 2008 at 04:17:03AM -0700, Jeremy Chadwick wrote:
> On Thu, Oct 02, 2008 at 09:57:55PM +0100, Bruce Cran wrote:
> > I recently upgraded my i386 router from 7.0 to 7.1-PRERELEASE.  I  
> > rebooted it today but despite pf_enable="YES" being in /etc/rc.conf no  
> > rules got loaded during boot, despite pf itself having been enabled:
> >
> > router# pfctl -s rules
> > router# pfctl -e -f /etc/pf.conf
> > pfctl: pf already enabled
> > [connection is closed due to new rules being loaded]
> > router# pfctl -s rules
> > scrub in all fragment reassemble
> > [... lots of rules listed]
> >
> > Has anyone else seen this problem, or have I just missed something  
> > that's changed between 7.0 and 7.1 in the way pf works?
> 
> I was seeing something similar on my own box which I just upgraded from
> a 150-day-old RELENG_6 to present RELENG_6.  pfctl -s rules output no
> rules.  pfctl -s info showed packet counters, but no interface stats
> (due to the rules not being loaded, e.g. no loginterface).
> 
> kldstat showed pflog.ko and pf.ko loaded.
> 
> If I did /etc/rc.d/pf start, the rules would loaded, and everything
> starts working as expected.
> 
> I rebooted the box and saw the following on serial console, which I'm
> pretty sure is what's responsible for the breakage:
> 
> Enabling pf.
> Oct  3 04:14:51 pflogd[374]: [priv]: msg PRIV_OPEN_LOG received
> cannot determine interface bandwidth for bge0, specify an absolute
> bandwidth
> altq not defined on bge0
> altq not defined on bge0
> /conf/ME/pf.conf:52: errors in queue definition
> altq not defined on bge0
> /conf/ME/pf.conf:53: errors in queue definition
> altq not defined on bge0
> /conf/ME/pf.conf:54: errors in queue definition
> pfctl: Syntax error in config file: pf rules not loaded
> pf enabled
> 
> I'd recommend you check your kernel console log on boot-up and see if
> anything is showing up there.  I'm about to go digging to find out
> what's wrong with my ALTQ rules.

I noticed the last time I rebooted my gateway to patch the latest
v6 hole that vr0 (in my case) had not negotiated link by the time
pf started (even tho its a static IP address, not DHCP).  This meant
that there was no link speed for altq to base its queueing on, and
the entire pf load failed (I think).  

I changed my vr0 altq line to hardcode the speed at 100mbit and I think
that should fix it

Why this is an issue now and it wasn't previously I'm not sure.  The
current failure mode is certainly not helpful.  I'm not sure if we
should force pf to wait for link on altq interfaces or not.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Problem with dump stalling

[Gary Palmer]

On Thu, Oct 09, 2008 at 01:58:39PM +0200, David Peall wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:owner-freebsd-
> > [EMAIL PROTECTED] On Behalf Of Jeremy Chadwick
> > Sent: 09 October 2008 12:45 PM
> > To: Christoph Schug
> > Cc: freebsd-stable@freebsd.org; David Peall
> > Subject: Re: Problem with dump stalling
> > 
> > This was fixed on HEAD in revision 1.48 (March 13th), with the comment
> > "MFC: 1 week".
> > 
> > The commit to RELENG_7 did not happen until April 19th, see revision
> > 1.39.2.3:
> > 
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/subr_sleepqueue.c
> > 
> > The PR referenced in the CVS commit is PR 117603.
> > 
> > David, can you verify you're using a version of
> > src/sys/kern/subr_sleepqueue.c that is 1.39.2.3 or newer?
> > 
> > If so, the problem David is experiencing is different.  If not, David
> > will need to csup and then rebuild world and kernel (do NOT just do
> > one; do both) to pick up the changes.
> > 
> 
> I'm using stable:
> FreeBSD ochre.school.za 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #0: Tue
> Sep  2 18:48:24 UTC 2008
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> I don't update via source only via binaries, how would I tell?
> 
> Regards

Try running:

ident /boot/kernel/kernel | grep subr_sleepqueue

That should give you the CVS id for the appropriate file

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Broken loader on 7.1-STABLE?

[Gary Palmer]

On Tue, Jan 20, 2009 at 06:22:00PM -0700, John Rushford wrote:
> Hello,
> 
> Perhaps mine is a different issue but I ran into this today.
> 
> I loaded FreeBSD 7.1-RELEASE from a DVD onto an Apple Mac Pro after
> partitioning a drive with bootcamp.  The install went quite well and the
> machine came up with no issues.  I configured networking, X, and got gnome
> working.  I setup cvsup and loaded the STABLE sources, ran make buildworld,
> make kernel, etc...
> 
> I attempted to boot into single user to run mergemaster, installworld, etc..
> But the machine will not boot, I now get the following errror and prompt:
> 
> Trying to mount root from ufs:/dev/ad9s1a
> 
> Manual root filesystem specification:
> :   Mount  using filesystem 
> e.g. ufs:da0s1a
> ?   List valid disk boot devices
> Abort manual input
> 
> I input ufs:/dev/ad9s1a to no avail and ? Does not list any other devices.
> 
> I've booted from the DVD and gone into Fixit mode and can mount /dev/ad9s1a
> just fine.  I thought that I'd try putting back loader.old on the off chance
> that might solve the problem but, I do not see a loader.old, just loader.
> The kernel.old directory is there.
> 
> Any ideas on what the issue might be and how to fix?
> 
> Appreciate the help as I'd like to get 7.1-STABLE running on this machine.

Did the kernel probe messages prior to the mountroot prompt indicate that
the appropriate disk controllers were found/probed and that the 
disk devices were found on the disk controllers?  The lack of
any devices listed when you asked might indicate a kernel configuration
problem.

Regards,

Gary

P.S. Please do not top post.

> 
> Regards
> John
> 
> 
> 
> 
> On 1/20/09 3:56 AM, "Mark Kirkwood"  wrote:
> 
> > Reuben wrote:
> >> 
> >> I was wondering if anyone else was seeing loader (v1.02) break after 
> >> updating
> >> from 7.1-RELEASE to 7.1-STABLE.  After performing the prescribed updating
> >> procedure (via the handbook), the system will go through the normal steps 
> >> and
> >> after the boot menu will present the following error:
> >> 
> >> Can't work out which disk we are booting from.
> >> Guessed BIOS device 0x not found by probes, defaulting to disk0
> >> 
> >> According to the bugbusting page on the FreeBSD wiki there's two issues at
> >> work that cause this behavior; patches were committed to HEAD/RELENG 
> >> earlier
> >> last year in Mar and Aug.  Up until now I've never come across this problem
> >> in 6.x or 7.0.  In doing a little research I've come across a few older
> >> threads via google where it was believed that the problem was caused by
> >> improper CFLAGS in make.conf.  I've commented mine out and rebuilt things..
> >> with the same end result.  In fact, if it's any help, my CFLAGS declaration
> >> in make.conf is taken verbatim from the /usr/share/examples/etc/make.conf.
> >> Furthermore, on selecting option 6 from the boot menu (escape to loader
> >> prompt), the system [I'm assuming] crashes displaying a blinking ASCII
> >> pattern from which only a hard reboot will work.
> >> 
> >> FWIW, this is a fairly plain system.. nothing special in sysctl.conf or
> >> loader.conf, and the kernel is pretty stock as well (more or less GENERIC
> >> with my sound device and pf).
> >> 
> >> A temporary fix for me was to copy over loader.old to loader in /boot.
> >> 
> >> 
> >>   
> > 
> > I am getting this too - update from RELENG_7 @12 Jan src to 20 Jan and I
> > have:
> > 
> > panic: free: guard1 fail @ 0x511d
> > from /usr/src/sys/boot/i386/loader/../../common/module.c:959
> > 
> > Can't work out which disk we are booting from.
> > Guessed BIOS device 0x not found by probes, defaulting to disk0
> > 
> > 
> > 
> > Copying loader.old to loader did not work around this for me - I had to
> > empty loader.conf too.
> > 
> > Here is what *was* in there:
> > 
> > ---> begin loader.conf
> > # Sound
> > sound_load="YES"
> > snd_hda_load="YES"
> > 
> > # IPC
> > kern.ipc.semmni=500
> > kern.ipc.semmns=500
> > 
> > 
> > # CD/DVD DMA
> > atapicam_load="YES"
> > hw.ata.atapi_dma=0
> > --> end loader.conf
> > 
> > 
> > At this point I am not sure which if are the bad guys...
> > 
> > 
> > The machine is an Asus a8vx.
> > 
> > regards
> > 
> > Mark
> > ___
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
> 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...

Re: 7.1, mpt and slow writes

[Gary Palmer]

On Thu, Jan 29, 2009 at 11:43:11PM -0500, Charles Sprickman wrote:

[ snip ]

> Any idea what happened to the sysctl?  Is there some other method to 
> verify the loader tunable took (other than testing the throughput)?

Boot with -v.  If the loader tunable took effect, you should see
"Enabling SATA WC on phy " instead of "Disabling SATA ..."

Regards,

Gary

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 7.1, mpt and slow writes

[Gary Palmer]

On Sat, Jan 31, 2009 at 01:48:46AM -0500, Charles Sprickman wrote:
> On Fri, 30 Jan 2009, Gary Palmer wrote:
> 
> >On Thu, Jan 29, 2009 at 11:43:11PM -0500, Charles Sprickman wrote:
> >
> >[ snip ]
> >
> >>Any idea what happened to the sysctl?  Is there some other method to
> >>verify the loader tunable took (other than testing the throughput)?
> >
> >Boot with -v.  If the loader tunable took effect, you should see
> >"Enabling SATA WC on phy " instead of "Disabling SATA ..."
> 
> Cool, it works then.  Why was the info removed from the sysctl mib?
> 
> mpt0: Enabling SATA WC on phy 0
> mpt0: Enabling SATA WC on phy 1
> 
> Bonnie++ is showing me about 24MB/s writes and 70MB/s reads.
> 
> Is any of this verbose stuff problematic?
> 
> mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required).
> mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not 
> required).
> mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not 
> required).
> mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not 
> required).
> mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not 
> required).
> mpt0: No Handlers For Any Event Notify Frames. Event 0xb (ACK not required).
> 
> And is any of this info found at boot-time accessible while the system is 
> running?

Hi,

Sorry, I can't answer your questions - all I did to find the
boot -v information was to look in the kernel source code.  Grepping
through the CVS history I don't actually see a point in CVS history
where there was a sysctl MIB value for the SATA WC status, although I
might be mistaken.  Perhaps you are remembering using kenv to get
at hw.mpt.enable_sata_wc instead of sysctl?

Regards,

Gary

> mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync )
> mpt0:vol0(mpt0:0:0): Using Spare Pool: 0
> mpt0:vol0(mpt0:0:0): 2 Members:
>   (mpt0:1:32:0): Primary Online
>   (mpt0:1:1:0): Secondary Online
> mpt0:vol0(mpt0:0:0): RAID-1 - Optimal
> mpt0:vol0(mpt0:0:0): Status ( Enabled )
> (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0)
> (mpt0:vol0:1): Online
> (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0)
> (mpt0:vol0:0): Online
> 
> Thanks,
> 
> Charles
> 
> ps - would it kill Dell to make a damn ISO of a bootable media for RAID 
> controller firmware upgrades???  I don't even own anything with a floppy 
> drive anymore.
> 
> >Regards,
> >
> >Gary
> >
> >___
> >freebsd-stable@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> >
> 
> 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: immense delayed write to file system (ZFS and UFS2), performance issues

[Gary Palmer]

On Tue, Jan 19, 2010 at 03:24:49AM -0800, Jeremy Chadwick wrote:
> WD2001FAAS - WD Caviar Black,   2TB, 64MB, 7200rpm

Do you mean WD2001FASS?  I can't find a WD2001FAAS.

Thanks,

Gary

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Dell PowerEdge Virtual Media

[Gary Palmer]

On Thu, Feb 18, 2010 at 09:26:41PM +, Scott Mitchell wrote:
> So it appears to work if I force the starting sector to be zero.  I see the 
> same result with an RHEL5 DVD image:
> 
> (504) ~ $ sudo umount /mnt
> (505) ~ $ sudo mount_cd9660 -v /dev/cd0 /mnt
> using starting sector 512
> mount_cd9660: /dev/cd0: Invalid argument
> (506) ~ $ sudo mount_cd9660 -s0 /dev/cd0 /mnt

Hi,

I'm no expert at this code, but it might be interesting to see the
results of

cdcontrol -v info

The code in mount_cd9660 in 7.x reads the CD/DVD table of contents
to figure out where the data segment starts.  The only thing I can
guess is that the TOC data is getting munged somehow.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Incorrect super block

[Gary Palmer]

On Sat, Mar 06, 2010 at 12:43:24PM +0100, Harald Weis wrote:
> > I solved this problem for myself by installing MacFuse
> 
> MacFuse is not yet available for Snow Leopard (10.6).

Not entirely correct.  MacFuse is not available for Snow Leopard when
booting a 64 bit kernel.  Apparently it works fine if you are using
the 32 bit kernel.  

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: /usr/bin/objformat is missing

[Gary Palmer]

On Tue, Jan 29, 2008 at 05:53:35PM +0100, Eirik ?verby wrote:
> On Jan 29, 2008, at 4:49 PM, Chris H. wrote:
> 
> >Quoting pluknet <[EMAIL PROTECTED]>:
> >
> >>On 29/01/2008, Chris H. <[EMAIL PROTECTED]> wrote:
> >>>Quoting Peter Jeremy <[EMAIL PROTECTED]>:
> >>>
>  On Mon, Jan 28, 2008 at 02:41:56PM -0800, Chris H. wrote:
> > In case you're wondering, objformat /is/ required - at leas for
> > www/apache13-ssl.
> 
> >>
> >>touching objformat is not a good way. Try this instead, last time it
> >>helped me (taken from memory):
> >>
> >>--- Makefile.orig   2008-01-29 13:38:43.0 +0300
> >>+++ Makefile2008-01-29 13:41:19.0 +0300
> >>@@ -5,7 +5,7 @@
> >>#  and apache-ssl port by Mark Murray 
> >><[EMAIL PROTECTED] >.
> >>#  Oh, and with a little bit of help from Ben :)
> >>#
> >>-# $FreeBSD: ports/www/apache13-ssl/Makefile,v 1.121 2007/06/17
> >>16:59:26 anders Exp $
> >>+# $FreeBSD$
> >>
> >>PORTNAME=  apache+ssl
> >>PORTVERSION=   ${APACHE_VERSION}.${APACHE_SSL_VERSION}
> >>@@ -48,7 +48,7 @@
> >>
> >>APACHE_HARD_SERVER_LIMIT?= 512
> >>
> >>-CFLAGS+=   -I${OPENSSLINC}/openssl
> >>+CFLAGS+=   -I${OPENSSLINC}/openssl -Wl,
> >
> >I noticed this arg in another thread regarding this issue:
> >--export-dynamic
> >
> >Thank you for posting this. Although I had success building and
> >running the apache13-ssl port after applying my objformat /hackery/.
> >I'm now running into troubles adding all of the php5 extensions I
> >need to use. I had no difficulties with php5 itself. But after a
> >certain point in the list, apache exits on signal 11 (core dumped).
> >Ermm... this was exactly the same trouble I started with, with the
> >exception that it was on signal 10.
> 
> I have had problems with PHP modules in the past; often they can end  
> up crashing when loaded in the wrong order, for instance. I also had  
> major trouble getting the imagick module to work at all lately.
> 
> Try re-ordering things in your extensions.ini, maybe commenting out  
> all modules and re-enabling one at a time.
> 
> /Eirik

If you have compiled the PHP SSL module and are loading it, make sure
that it uses the same SSL library as the Apache module.  Likewise for any
other libraries that PHP might be linking in that Apache also uses.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: gjournal panic 7.0-RC1

[Gary Palmer]

On Sun, Feb 03, 2008 at 09:35:44PM +0100, Ivan Voras wrote:
> Chris wrote:
> 
> >Came back to see box had rebooted itself from a journal related panic.
> >
> >panic: Journal overflow (joffset=49905408 active=499691355136 
> >inactive=4990$
> >cpuid = 0
> 
> AFAIK this means that the journal is too small for your machine - try 
> doubling it until there are no more panics.
> 
> If so, this is the same class of errors as ZFS (some would call it 
> "tuning errors"), only this time the space reserved for the on-disk 
> journal is too small, and the fast drives fill it up before data can be 
> transfered from the journal to the data area.

Is there something stopping gjournal from temporarily blocking writes
to the journal to allow it to flush the journaled data to the provider?

Thanks,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3

[Gary Palmer]

On Wed, Jun 11, 2008 at 07:36:28PM +0100, Robert Watson wrote:
> 
> On Wed, 11 Jun 2008, Paul Schmehl wrote:
> 
> >From a security standport, backporting fixes to previous versions of ports 
> >creates a difficulty.  It's much harder to tell, for example, if a RedHat 
> >"port" is vulnerable or not, because RedHat uses their own proprietary 
> >versioning system to define "where" a particular "port" is at.
> >
> >So, while your system might *say* it's running php version 5.2, it's 
> >really *not* vulnerable because in RedHatese it's version 
> >5.2.1.6.92000.p-2.1 (I'm just making that up.)
> >
> >If this idea ever gets off the ground, I *hope* the folks involved with 
> >find a rational, logical way to define the versioning so that it's not 
> >hieroglyphics to the average person.
> 
> I hope not to offend the ports folks in saying this, but it seems clear to 
> me that the narrower scope and better-defined components of the base system 
> have (over time) lead to a much easier incremental upgrade path than ports 
> and packages.
> 
> It's not clear to me how you could apply the same level of attention to 
> something as large as the ports collection, except perhaps to select a 
> subset of ports you care "more" about, and provide a higher quality of 
> service for them.  In effect, try to find a semantically richer middle 
> ground between "it's someone else's problem, our role is primarily to 
> bundle" and "it's entirely our problem and in revision control".  We 
> already do this for some ports, in that the people involved in adapting and 
> maintaining some of the larger/more critical parts, such as X.org, KDE, 
> Gnome, and quite a few others, spend vast amounts of time ensuring that 
> things work well, but largely without the help of revision control in the 
> ports tree.  I'm not proposing we incorporate X.org into CVS (SVN?) or the 
> like, but perhaps there is a way we could better present the choices 
> reflected there.  That doesn't help users of random tiny software packages, 
> and I'm not sure anything can, but perhaps we can provide a smoother 
> incremental maintenance path for some key packages.
> 
> Mind you, ports really isn't my area, so I am at significant risk 
> speculating in this area.  Experience with the base system shows that the 
> real work is always in the details, and hardly ever in the big ideas, and 
> so only by truly implementing a system and trying it out can you determine 
> whether it really works in practice.  It's easy to wave ones hands at a 
> high level (as I've done), but it's the proof-of-concept that matters.

I think a large part of the shortcomings of the ports infrastructure when
it comes to security releases could be mitigated if there was a rapid
building and availability of packages on FTP mirrors to prevent everyone
from doing "portupgrade -P" and then having to wait for the build as
the packages don't show up for  days, and people can't wait that long
for the fix.

I know a discussion was recently started about package distribution
and how to address its shortcomings and hopefully the need for rapid
security package distribution will be taken into account

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD 7.1 and BIND exploit

[Gary Palmer]

On Sun, Jul 20, 2008 at 09:44:31AM -0700, Kevin Oberman wrote:

[ snip ]

> Second, RELENG_7_0 has the patch plus two other security patches. IT IS
> NOT STABLE! It is 7.0 with exactly three important security patches and
> nothing else.

[ snip ]

I believe the second sentence could be better written as

IT IS NOT -STABLE!

which is an important difference ;)

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: possibly silly question regarding freebsd-update

[Gary Palmer]

On Tue, Mar 30, 2021 at 11:55:24AM -0400, Karl Denninger wrote:
> 
> On 3/30/2021 11:22, Guido Falsi via freebsd-stable wrote:
> > On 30/03/21 15:35, tech-lists wrote:
> > > Hi,
> > > 
> > > Recently there was
> > > https://lists.freebsd.org/pipermail/freebsd-security/2021-March/010380.html
> > > 
> > > about openssl. Upgraded to 12.2-p5 with freebsd-update and rebooted.
> > > 
> > > What I'm unsure about is the openssl version.
> > > Up-to-date 12.1-p5 instances report OpenSSL 1.1.1h-freebsd? 22 Sep 2020
> > > 
> > > Up-to-date stable/13-n245043-7590d7800c4 reports OpenSSL 1.1.1k-freebsd
> > > 25 Mar 2021
> > > 
> > > shouldn't the 12.2-p5 be reporting openssl 1.1.1k-freebsd as well?
> > > 
> > 
> > No, as you can see in the commit in the official git [1] while for
> > current and stable the new upstream version of openssl was imported for
> > the release the fix was applied without importing the new release and
> > without changing the reported version of the library.
> > 
> > So with 12.2p5 you do get the fix but don't get a new version of the
> > library.
> > 
> > 
> > [1] 
> > https://cgit.freebsd.org/src/commit/?h=releng/12.2&id=af61348d61f51a88b438d41c3c91b56b2b65ed9b
> > 
> > 
> Excuse me
> 
> $ uname -v
> FreeBSD 12.2-RELEASE-p4 GENERIC
> $ sudo sh
> # freebsd-update fetch
> Looking up update.FreeBSD.org mirrors... 3 mirrors found.
> Fetching metadata signature for 12.2-RELEASE from update4.freebsd.org...
> done.
> Fetching metadata index... done.
> Inspecting system... done.
> Preparing to download files... done.
> 
> No updates needed to update system to 12.2-RELEASE-p5.
> 
> I am running 12.2-RELEASE-p4, so says uname -v
> 
> IMHO it is an *extraordinarily* bad practice to change a library that in
> fact will result in a revision change while leaving the revision number
> alone.
> 
> How do I *know*, without source to go look at, whether or not the fix is
> present on a binary system?
> 
> If newvers.sh gets bumped then a build and -p5 release should have resulted
> from that, and in turn a fetch/install (and reboot of course since it's in
> the kernel) should result in uname -v returning "-p5"
> 
> Most of my deployed "stuff" is on -STABLE but I do have a handful of
> machines on cloud infrastructure that are binary-only and on which I rely on
> freebsd-update and pkg to keep current with security-related items.

What does "freebsd-version -u" report?  The fix was only to a userland
library, so I would not expect the kernel version as reported by uname
to change.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Portsnap no updates since 3/31/2021 ?

[Gary Palmer]

On Tue, Apr 06, 2021 at 06:49:17AM -0400, Robert Blayzor via freebsd-stable 
wrote:
> I have several servers running 11.4 and 12.2 that do nightly portsnap
> updates and the last time they've seen anything new is 3/31/2021, since
> then, nothing.
> 
> This seems highly unusual since seems like there was always SOMETHING
> updated daily now nothing.

git transition

https://wiki.freebsd.org/git

Regular service should resume soon

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Clang as default compiler

[Gary Palmer]

On Wed, Sep 19, 2012 at 07:12:50PM +0200, Roland Smith wrote:
> On Tue, Sep 18, 2012 at 12:02:20AM +0200, Dimitry Andric wrote:
> > On 2012-09-17 21:43, Roland Smith wrote:
> > > On Wed, Sep 12, 2012 at 01:04:20AM -0500, Mark Linimon wrote:
> > ...
> > >> For most of the failures, we are already aware of them, as a result of
> > >> our periodic runs.  So, just filing a PR to say "broken on clang" doesn't
> > >> really help us all that much.
> > >
> > > Those are build failures. What about crashes? E.g. I've recently had
> > > crashes with x11-wm/i3 and x11/rxvt-unicode. Both problems disappeared 
> > > after
> > > recompiling them with gcc46.
> > 
> > We can't figure them all out without *your* help. :-)  Please attempt to
> > run the program in a debugger, gather core dumps, etc.  Or at least, try
> > to make it into a reproducible case, so somebody else can attempt to
> > diagnose it.  And please specify the exact version of clang you used.
> 
> I was using the clang that is in base in 9.0-RELEASE-p3:
> 
> FreeBSD clang version 3.0 (branches/release_30 142614) 20111021
> Target: x86_64-unknown-freebsd9.0
> Thread model: posix
> 
> I was thinking of installing the most recent clang-devel since it seemed to
> have a lot of improvements, but I was wondering what is the correct way of
> makeing sure that it is used in preference to the one in base? I thought about
> moving /usr/local/bin before /usr/bin in $PATH, but I'm not sure that is a
> good idea.
> 
> > Now, most of the time this is because programs contain bugs, or
> > undefined behavior, which happens to go unnoticed with gcc, for example
> > because it optimized by accident in such a way to mask the bug.  In a
> > few other cases, real clang bugs are found, and most of the time, those
> > can be fixed quickly.
> > 
> > That said, in these cases specifically, how do the applications crash?
> > Right at startup, or after specific inputs or user actions?
> 
> Rxvt-unicode seemed to crash reliably whenever I was scrolling through a
> document with less(1). If I reached the end of the document, and pressed Page
> Down (keysim Next), it would crash. It was quite weird. 
> 

That sounds like the bell was doing it.  If you do CTRL-G (or something
else that makes a beep) from the shell prompt in rxvt-unicode does it
also crash?

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 9.1-RC2 - could it be that the installer does not write the MBR?

[Gary Palmer]

On Fri, Oct 19, 2012 at 10:38:41PM +0200, Rainer Duffner wrote:
> Am Fri, 19 Oct 2012 11:32:49 -0700
> schrieb Adrian Chadd :
> 
> > Guys/girls/etc,
> > 
> > I do suggest that someone actually spends some time coming up with a
> > table of "what the current state is", "what we could do", "what would
> > happen if we did that."
> > 
> > Right now there's a lot of possibilities (new drive, drive with
> > windows, drive with linux, drive with linux/windows, drive with legacy
> > freebsd MBR, etc) and as an outsider trying to figure out what is
> > actually the "right" sounding behaviour, it's difficult for me to sit
> > down and digest all these emails that chip away at a bit of the
> > problem at a time.
> > 
> > So if you'd like to see this fixed, I really do suggest that one of
> > you dumps some time into coming up with a basic table like I said
> > above, work with others who can correct/flesh out the various options
> > to take into account, and then we can come up with a real solution.
> > Then 9.1 can go out the door.
> > 
> 
> 
> If I select the "entire disk" for FreeBSD, I think it's a reasonable
> assumption that the MBR should replaced, too.

I think it should still prompt clearly for permission to splat the boot
record.  There could be an OS (or multiple OSs) on other disks which the
boot loader can reference.  Just because you have complete ownership of
*one* disk is not indicative of being able to take over the entire boot
record.  There are probably too many edge cases here to make a reliable
automated decision, hence the necessity of a question.

> Please don't make people install FreeBSD 9.0 first on disks with
> non-FreeBSD MRRs and then upgrade to 9.1.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [patch] Re: SU+J on 9.1-RC2 ISO

[Gary Palmer]

On Fri, Nov 02, 2012 at 07:41:31PM +0100, Mateusz Guzik wrote:
> On Fri, Nov 02, 2012 at 07:30:04PM +0100, Bas Smeelen wrote:
> > On 11/02/2012 07:17 PM, Bas Smeelen wrote:
> > > On 11/02/2012 07:08 PM, Bas Smeelen wrote:
> > >> On 11/02/2012 06:27 PM, Adam Strohl wrote:
> > >>> On 11/3/2012 0:13, Mike Jakubik wrote:
> >  You can disable SU+J after installing, though it would be nice if the
> >  installer gave you a choice.
> > >>> This assumes that you know about this flaw, which most people do not.
> > >>>
> > >>> I didn't until I discovered it by panic-ing a perfectly fine running
> > >>> server.  Getting burned by a known bug like this shouldn't be "SOP"
> > >>> for users of FreeBSD.
> > >>>
> > >>> If anything it should be turned off by default, and people can turn it
> > >>> on if they want given the landmine it plants.  If they know how to
> > >>> turn it on they're much more likely to be aware of the issue.
> > >>>
> > >>>
> > >>>
> > To sum it up
> > SU+J should be turned off by default because of
> > 1. It does not work with dumping a live system e.g. snapshot
> > 2. it is not recommended for SSD installs
> > 3. "Smart" admins can turn it on if they want
> > 
> > root@sys:/usr/src/usr.sbin/bsdinstall/partedit # diff -u gpart_ops.c 
> > gpart_ops.cnew
> > --- gpart_ops.c2012-08-06 01:54:33.0 +0200
> > +++ gpart_ops.cnew2012-11-02 19:07:45.0 +0100
> > @@ -90,8 +90,8 @@
> >   {"SU", "Softupdates",
> >   "Enable softupdates (default)", 1 },
> >   {"SUJ", "Softupdates journaling",
> > -"Enable file system journaling (default - "
> > -"turn off for SSDs)", 1 },
> > +"Disable file system journaling (default - "
> > +"turn on for adventurish admins)", 0 },
> >   {"TRIM", "Enable SSD TRIM support",
> >   "Enable TRIM support, useful on solid-state drives",
> >   0 },
> > 
> > Please comment, then I can file a PR or not
> 
> As was noted in my another mail, the kernel will no longer crash when an
> attempt to take a snapshot is made. Also AFAIR SUJ can be disabled
> later.
> 
> Given that I prefer the following:
> 
> diff --git a/usr.sbin/bsdinstall/partedit/gpart_ops.c 
> b/usr.sbin/bsdinstall/partedit/gpart_ops.c
> index 479365a..80296c2 100644
> --- a/usr.sbin/bsdinstall/partedit/gpart_ops.c
> +++ b/usr.sbin/bsdinstall/partedit/gpart_ops.c
> @@ -91,7 +91,7 @@ newfs_command(const char *fstype, char *command, int 
> use_default)
>   "Enable softupdates (default)", 1 },
>   {"SUJ", "Softupdates journaling",
>   "Enable file system journaling (default - "
> - "turn off for SSDs)", 1 },
> + "turn off for SSDs or if you use snapshots)", 1 },
>   {"TRIM", "Enable SSD TRIM support",
>   "Enable TRIM support, useful on solid-state drives",
>   0 },
> 
> http://people.freebsd.org/~mjg/patches/suj-snapshot-comment.diff

How many people realise that snapshots are needed for dump based backups
(and other related features)?

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge on the new Mac Mini

[Gary Palmer]

On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote:
> On 11/16/12 10:41, Alfred Perlstein wrote:
> > Often that is all that is needed.  It's worth a shot and reporting back.
> > 
> > Do you know how to update the table in the driver, rebuild/install 
> > kernel and check?
> > 
> > -Alfred
> > 
> 
> I'm afraid not. I grepped for the hex value reported on the one that works
> (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I
> don't know what to add :-(
> 
> I don't have any problem with rebuilding and installing a new kernel, though.

14e4 is the ID for Broadcom
16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip

http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list
of the BCM PCI ID values

There is a (frequently incomplete) database of user reported PCI values at
http://www.pcidatabase.com.  It has the BCM ID (14e4), but not your chip

Linux uses the tg3 driver for that chipset apparently, but I think thats
a general dumping ground for a lot of Broadcom products.  Not sure what the
appropriate FreeBSD driver to add the ID code to would be.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge on the new Mac Mini

[Gary Palmer]

On Fri, Nov 16, 2012 at 11:27:17AM -0500, Richard Kuhns wrote:
> On 11/16/12 11:20, Gary Palmer wrote:
> > On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote:
> >> On 11/16/12 10:41, Alfred Perlstein wrote:
> >>> Often that is all that is needed.  It's worth a shot and reporting back.
> >>>
> >>> Do you know how to update the table in the driver, rebuild/install 
> >>> kernel and check?
> >>>
> >>> -Alfred
> >>>
> >>
> >> I'm afraid not. I grepped for the hex value reported on the one that works
> >> (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. 
> >> So I
> >> don't know what to add :-(
> >>
> >> I don't have any problem with rebuilding and installing a new kernel, 
> >> though.
> > 
> > 14e4 is the ID for Broadcom
> > 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip
> > 
> > http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list
> > of the BCM PCI ID values
> > 
> > There is a (frequently incomplete) database of user reported PCI values at
> > http://www.pcidatabase.com.  It has the BCM ID (14e4), but not your chip
> > 
> > Linux uses the tg3 driver for that chipset apparently, but I think thats
> > a general dumping ground for a lot of Broadcom products.  Not sure what the
> > appropriate FreeBSD driver to add the ID code to would be.
> > 
> > Regards,
> > 
> > Gary
> > 
> 
> Sorry, I should have been more clear. I grepped for those values in
> /usr/src/sys/dev/bge/*, since that's the driver that's used on the older 
> minis.
> I assume that's where the table is that Alfred mentioned; I just don't know 
> what
> to add to it.
> 

The probe table appears to be bge_devs in if_bge.c.  The values there are
#define'd in if_bgereg.h, but for a quick hack you just need to add the value
to the table

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Increasing the DMESG buffer....

[Gary Palmer]

On Thu, Nov 22, 2012 at 02:14:59PM -0800, Kevin Oberman wrote:
> On Thu, Nov 22, 2012 at 2:05 PM, Adrian Chadd  wrote:
> > On 22 November 2012 06:30, Alexander Motin  wrote:
> >
> >> Neither ICH, nor any other driver I know have amount of information
> >> comparable to what HDA hardware provides. So the analogy is not good.
> >> Respecting that most CODECs have no published datasheets, that information
> >> is the only input for debugging.
> >>
> >> snd_hda also uses hw.snd.verbose=3. But it is used for even deeper driver
> >> debugging. It also enables a lot of debugging in sound(4), that can be too
> >> verbose for HDA debugging.
> >>
> >> I will recheck again how can it be reorganized, but I think that the real
> >> problem is not in HDA. We need some way to structure and filter the output.
> >
> > I honestly would like to just see it spat out using a userland tool,
> > rather than having the kernel print that level of topology data out.
> >
> > It's highly unlikely that a topology problem is going to cause a
> > system to not boot, right? So the kernel itself doesn't need to be
> > able to spit that data out.
> 
> Maybe I'm missing something, but the data needed to adjust HDAC is
> available from 'sysctl dev.hdaa'. I have not looked at the verbose
> output in quite a while, but I think it is mstly or entirely hte
> information in that and 'sysctl dev.hdac'. I never needed to look
> elsewhere to get mine set up properly.
> 
> Also, isn't the entire verbose boot captured in /var/run/dmesg?

Only if the message buffer hasn't overflowed before the utility runs to
populate the file

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Library Problem

[Gary Palmer]

On Wed, Nov 28, 2012 at 10:46:51PM -0800, Doug Hardie wrote:
> 
> On 28 November 2012, at 20:01, Devin Teske wrote:
> 
> > 
> > On Nov 28, 2012, at 7:36 PM, Doug Hardie wrote:
> > 
> >> I have installed 4 systems from the same FreeBSD 9.1-RC3 disk.  Three of 
> >> them worked just fine.  The last one is causing a problem.  It will not 
> >> look in /usr/local/lib/ for shared libraries.  I did the standard install, 
> >> moved in some source, compiled it and tried to run it.  The library is 
> >> there.  On the working systems ktrace shows:
> >> 
> >> 2259 introCALL  access(0x28066000,0)
> >> 2259 introNAMI  "/lib/libsermons.so"
> >> 2259 introRET   access -1 errno 2 No such file or directory
> >> 2259 introCALL  access(0x28066000,0)
> >> 2259 introNAMI  "/usr/lib/libsermons.so"
> >> 2259 introRET   access -1 errno 2 No such file or directory
> >> 2259 introCALL  access(0x28066000,0)
> >> 2259 introNAMI  "/usr/lib/compat/libsermons.so"
> >> 2259 introRET   access -1 errno 2 No such file or directory
> >> 2259 introCALL  access(0x28066000,0)
> >> 2259 introNAMI  "/usr/local/lib/libsermons.so"
> >> 2259 introRET   access 0
> >> 
> >> 
> >> On the failing system ktrace shows:
> >> 
> >> 6746 introNAMI  "/lib/libsermons.so"
> >> 6746 introRET   access -1 errno 2 No such file or directory
> >> 6746 introCALL  access(0x28066000,0)
> >> 6746 introNAMI  "/usr/lib/libsermons.so"
> >> 6746 introRET   access -1 errno 2 No such file or directory
> >> 6746 introCALL  access(0x28066000,0)
> >> 6746 introNAMI  "/usr/lib/compat/libsermons.so"
> >> 6746 introRET   access -1 errno 2 No such file or directory
> >> 6746 introCALL  access(0x28066000,0)
> >> 6746 introNAMI  "/lib/libsermons.so"
> >> 6746 introRET   access -1 errno 2 No such file or directory
> >> 6746 introCALL  access(0x28066000,0)
> >> 6746 introNAMI  "/usr/lib/libsermons.so"
> >> 6746 introRET   access -1 errno 2 No such file or directory
> >> 6746 introCALL  write(0x2,0x28060080,0x3c)
> >> 6746 introGIO   fd 2 wrote 60 bytes
> >>  "Shared object "libsermons.so" not found, required by "intro""
> >> 
> >> 
> >> It never attempts to check /usr/local/lib.  I can't find any configuration 
> >> item that affects that.  How can this be fixed?
> >> 
> > 
> > What's the value of "ldconfig_paths" in rc.conf(5)?
> > 
> > That includes:
> > /etc/rc.conf
> > /etc/rc.conf.local (if it exists)
> > /etc/defaults/rc.conf
> > 
> > Here on my 9.0-R system it has the following in /etc/defaults/rc.conf:
> > /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg
> 
> 
> /etc/defaults/rc.conf has:
> 
> ldconfig_paths="/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg"
> 
> 
> /etc/rc.conf has nothing for ldconfig_paths.

Check that /usr/local/lib doesn't have group or other write perms.
ldconfig ignores directories that are group/world writable.

To fix:

chmod go-w /usr/local/lib
sh /etc/rc.d/ldconfig start

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Will we get a RELEASE-9.1 for Christmas?

[Gary Palmer]

On Mon, Dec 10, 2012 at 08:06:24PM -0800, Kevin Oberman wrote:
> On Mon, Dec 10, 2012 at 3:52 PM, Brett Glass  wrote:
> > At 04:29 PM 12/10/2012, Adrian Chadd wrote:
> >
> >> There's politics in every organisation. There are ego clashes in every
> >> organisation. Sometimes you'll fit in, sometimes you won't. If you
> >> feel there are issues, find people inside the community who you do get
> >> along well with and talk with them about it.
> >>
> >> It sucks, yes. I'm one of those "shut up and code already" types and I
> >> deal badly with politics.
> >
> >
> > Me, too. That's why I have been contributing code quietly through others
> > rather than putting myself out in the front lines.
> >
> > In any event -- back to the original topic -- there should indeed be better
> > communications between the Release Engineering team and the community.
> > The time it takes to post updates -- especially as it gets close to release
> > time -- would be recovered many times over because folks like me wouldn't
> > have any need to e-mail regarding status and projected schedules. ;-)
> 
> I whole-heatedly agree... but I know a little about release
> engineering for a large project, especially when the release team is
> unpaid and has to honor commitments to $real_job. Release engineering
> is very detail-oriented and unforgiving.  This is not really
> compatible with part-time work.
> 
> The RE must be focused, first ans foremost, on getting a release out
> the door as quickly as possible and not to have any serious problems
> with that release. This makes it very had to pull bakc and make
> announcements or even update posted schedules. That is made even worse
> by hte desire to make such communication accurate or at least useful.
> Since there is a LOT of guessing involved in pulling together a
> release (how long will "Joe" take to fix this problem or why are there
> half a dozen reports of a serious issue with the RC, when no one else
> can reproduce it or even figure out what part of the system is causing
> it), RE folks are usually reticent about trying to give out any
> information since it will most likely be inaccurate.
> 
> This is why I accept the line that it will be released when it is
> ready. I really think it's about ready, but not even the head of the
> 9.1 RE team KNOWS when it will be ready, even if the  ISO builds are
> started. "There is many a slip twixt the cup and the lip."

I don't remember seeing any updates in e-mail, but the 

http://www.freebsd.org/news/2012-compromise.html

url has been updated.  Its a litle out of date now (last update about 2
weeks ago), but it does include information on the release of 9.1 and what
is holding it up (specifically getting a minimal set of packages built).
With the 2 branches tagged (ports and src) it is likely still a matter
of getting stuff built in a known clean environment.

Gary

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Will we get a RELEASE-9.1 for Christmas?

[Gary Palmer]

Short summary:

http://lists.freebsd.org/pipermail/freebsd-stable/2012-December/071023.html

On Tue, Dec 11, 2012 at 11:18:44AM -0500, Mark Saad wrote:
> So what is the short summary ? From what I can see, the wiki is out of date
> again. the ISO are on the master server, and working out to the mirrors.
> FreeBSD update is still not updated.  Does someone just need to just update
> the wiki with the relevant info ?
> 
> 
> On Tue, Dec 11, 2012 at 9:00 AM, Gary Palmer  wrote:
> 
> > On Mon, Dec 10, 2012 at 08:06:24PM -0800, Kevin Oberman wrote:
> > > On Mon, Dec 10, 2012 at 3:52 PM, Brett Glass  wrote:
> > > > At 04:29 PM 12/10/2012, Adrian Chadd wrote:
> > > >
> > > >> There's politics in every organisation. There are ego clashes in every
> > > >> organisation. Sometimes you'll fit in, sometimes you won't. If you
> > > >> feel there are issues, find people inside the community who you do get
> > > >> along well with and talk with them about it.
> > > >>
> > > >> It sucks, yes. I'm one of those "shut up and code already" types and I
> > > >> deal badly with politics.
> > > >
> > > >
> > > > Me, too. That's why I have been contributing code quietly through
> > others
> > > > rather than putting myself out in the front lines.
> > > >
> > > > In any event -- back to the original topic -- there should indeed be
> > better
> > > > communications between the Release Engineering team and the community.
> > > > The time it takes to post updates -- especially as it gets close to
> > release
> > > > time -- would be recovered many times over because folks like me
> > wouldn't
> > > > have any need to e-mail regarding status and projected schedules. ;-)
> > >
> > > I whole-heatedly agree... but I know a little about release
> > > engineering for a large project, especially when the release team is
> > > unpaid and has to honor commitments to $real_job. Release engineering
> > > is very detail-oriented and unforgiving.  This is not really
> > > compatible with part-time work.
> > >
> > > The RE must be focused, first ans foremost, on getting a release out
> > > the door as quickly as possible and not to have any serious problems
> > > with that release. This makes it very had to pull bakc and make
> > > announcements or even update posted schedules. That is made even worse
> > > by hte desire to make such communication accurate or at least useful.
> > > Since there is a LOT of guessing involved in pulling together a
> > > release (how long will "Joe" take to fix this problem or why are there
> > > half a dozen reports of a serious issue with the RC, when no one else
> > > can reproduce it or even figure out what part of the system is causing
> > > it), RE folks are usually reticent about trying to give out any
> > > information since it will most likely be inaccurate.
> > >
> > > This is why I accept the line that it will be released when it is
> > > ready. I really think it's about ready, but not even the head of the
> > > 9.1 RE team KNOWS when it will be ready, even if the  ISO builds are
> > > started. "There is many a slip twixt the cup and the lip."
> >
> > I don't remember seeing any updates in e-mail, but the
> >
> > http://www.freebsd.org/news/2012-compromise.html
> >
> > url has been updated.  Its a litle out of date now (last update about 2
> > weeks ago), but it does include information on the release of 9.1 and what
> > is holding it up (specifically getting a minimal set of packages built).
> > With the 2 branches tagged (ports and src) it is likely still a matter
> > of getting stuff built in a known clean environment.
> >
> > Gary
> >
> > ___
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> >
> 
> 
> 
> -- 
> mark saad | nones...@longcount.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge numbering

[Gary Palmer]

On Fri, Jan 25, 2013 at 05:47:39PM +0200, Daniel Braniss wrote:
> > On Friday, January 25, 2013 3:46:10 am Daniel Braniss wrote:
> > > Hi,
> > > this server, a Dell R720 has 4 bge on board,
> > >  Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572
> > >  bge0: APE FW version: NCSI v1.1.7.0
> > >  bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E
> > >  miibus0:  on bge0
> > >  ...
> > > 
> > > I have connected the ethernet to port labeled 0, but it appears
> > > as bge2, how can this be corrected?
> > 
> > It can't really.  The order of PCI devices is determined by the layout of 
> > the 
> > PCI device hierarchy which is generally determined by the physical traces 
> > on 
> > your motherboard.
> 
> so you are saying that Dell screwed up yet again?
> the 4 bges have consecutive macs, bge1 = bge0 +1, bge2 = bge1 + 1, etc. It's
> only the # 'outside' that is wrong? I will try the usual trial and error
> to find the mapping, but will have to wait till Sunday.

bge0 = port 2
bge1 = port 3
bge2 = port 0
bge3 = port 1

would be my suspicion

The R720 Broadcom chips are dual port, so bge0 & 1 are paired and bge2 & 3
are paired.

You can force this to be corrected by renaming the devices I believe.

Dell "fixed" this in Linux by using DMI/SMBIOS type 41 data to reorder
the NICs.  The code is in RHEL 6 and later.  The Dell white paper is

http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf

>From an R720 I have access to:


Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Integrated NIC 1
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: :01:00.0

Handle 0x2901, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Integrated NIC 2
Type: Ethernet
Status: Enabled
Type Instance: 2
Bus Address: :01:00.1

Handle 0x2902, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Integrated NIC 3
Type: Ethernet
Status: Enabled
Type Instance: 3
Bus Address: :02:00.0

Handle 0x2903, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Integrated NIC 4
Type: Ethernet
Status: Enabled
Type Instance: 4
Bus Address: :02:00.1


You can theoretically work from the bus address back to the way Dell
wants the NICs ordered.  Why on earth they can't get the hardware to do
it instead I have *no* idea

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: some issues with /usr/sbin/service

[Gary Palmer]

On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
> On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
> > we want to use this script for server administration purposes. After
> > doing some testing, for now there are following issues left:
> > 
> > 1) every execution of "service -e"  casts a bunch of unnecessary
> > warnings into /var/log/messages:
> > "... /usr/sbin/service: WARNING: $_enable is not set
> > properly - see rc.conf(5)."
> >This is caused by calling "checkyesno()", provided by /etc/subr. It
> > could be solved by using a local function, named "checkyes" or similar.
> > 
> > The following patch prohibits these annoying messages:
> > {snip}
> 
> Your patch, in effectively, "rewrites" checkyesno() to remove the warn()
> call in cases where xxx_enable variables are set to values other than
> yes/true/on/1 or no/false/off/0.
> 
> Here's a better idea:
> 
> Fix your /etc/rc.conf xxx_enable variables which contain values that
> aren't permitted.  That's what the warn() is for -- to tell you to fix
> them.  :-)

It also warns if xxx_enable isn't set.  I have a number of ports installed
which I don't want to run by default but may run later, or which have
daemons but I don't want the daemon but some other functionality.  
rsync and fetchmail are two perfect examples of the latter.

If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
Should I really have to go through and explicitly set the xxx_enable flags
to "no"?  Or should the code be smart enough to recognise that the variable
not being present is equivalent to "no"?

If the requirement is that all installed rc.d scripts have a xxx_enable flag
set to yes or no at all times, then the current ports infrastructure is sadly
lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
that is even a valid location).  And I'd prefer ports not try and automagically
frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
xxx_enable lines as that can go wrong.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: some issues with /usr/sbin/service

[Gary Palmer]

On Fri, Feb 15, 2013 at 01:20:20PM -0800, Jeremy Chadwick wrote:
> On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote:
> > On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
> > > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
> > > > we want to use this script for server administration purposes. After
> > > > doing some testing, for now there are following issues left:
> > > > 
> > > > 1) every execution of "service -e"  casts a bunch of unnecessary
> > > > warnings into /var/log/messages:
> > > > "... /usr/sbin/service: WARNING: $_enable is not set
> > > > properly - see rc.conf(5)."
> > > >This is caused by calling "checkyesno()", provided by /etc/subr. It
> > > > could be solved by using a local function, named "checkyes" or similar.
> > > > 
> > > > The following patch prohibits these annoying messages:
> > > > {snip}
> > > 
> > > Your patch, in effectively, "rewrites" checkyesno() to remove the warn()
> > > call in cases where xxx_enable variables are set to values other than
> > > yes/true/on/1 or no/false/off/0.
> > > 
> > > Here's a better idea:
> > > 
> > > Fix your /etc/rc.conf xxx_enable variables which contain values that
> > > aren't permitted.  That's what the warn() is for -- to tell you to fix
> > > them.  :-)
> > 
> > It also warns if xxx_enable isn't set.  I have a number of ports installed
> > which I don't want to run by default but may run later, or which have
> > daemons but I don't want the daemon but some other functionality.  
> > rsync and fetchmail are two perfect examples of the latter.
> > 
> > If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
> > Should I really have to go through and explicitly set the xxx_enable flags
> > to "no"?  Or should the code be smart enough to recognise that the variable
> > not being present is equivalent to "no"?
> >
> > If the requirement is that all installed rc.d scripts have a xxx_enable flag
> > set to yes or no at all times, then the current ports infrastructure is 
> > sadly
> > lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
> > that is even a valid location).  And I'd prefer ports not try and 
> > automagically
> > frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
> > xxx_enable lines as that can go wrong.
> 
> This is the first I've heard of something called /usr/local/etc/rc.conf.

Sorry, my brain was ahead of where my fingers were and got the path
wrong.  I of course meant /etc/rc.conf.

> Regardless, I can't confirm that behaviour:

As you found, it gets logged rather than output to stdout or stderr.

Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $xfs_enable is not 
set properly - see rc.conf(5).
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rsyncd_enable is 
not set properly - see rc.conf(5).
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rrdcached_enable 
is not set properly - see rc.conf(5).

(etc)

I've come across something else outputing that error, but it probably
all comes from the same place.  Either the rc processor needs to treat
the flag not being set as equal to "no", or the ports infrastructure needs
to start installing something to make foo_enable="no" appear in the
defaults system somewhere

Gary

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: some issues with /usr/sbin/service

[Gary Palmer]

On Sat, Feb 16, 2013 at 05:38:56PM +, Chris Rees wrote:
> On 16 February 2013 17:05, Paul Mather  wrote:
> > On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote:
> >
> >> On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote:
> >>> 16.02.2013 01:32, Jeremy Chadwick ??:
> >>>
>  Follow up -- I read Alfred's most recent mail.  Lo and behold, I find
>  this in /var/log/messages (but such did not come to my terminal):
> 
>  Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable 
>  is not set properly - see rc.conf(5).
>  Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable 
>  is not set properly - see rc.conf(5).
>  Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable 
>  is not set properly - see rc.conf(5).
>  Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: 
>  $htcacheclean_enable is not set properly - see rc.conf(5).
>  Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: 
>  $fetchmail_enable is not set properly - see rc.conf(5).
> 
>  Cute.  Agreed -- this is unacceptable on two levels (as I see it):
> 
>  1) These messages should be going to stdout or stderr in some way, so
>  honestly logger(8) should be called with the "-s" flag (IMO).
> >>>
> >>> Fully agreed here.
> >>
> >> It turns out logger -s has no effect, just like how the echo 1>&2
> >> statements in warn() and err() have no effect either (these should be
> >> outputting the warnings in question to stderr) -- see rc.subr's source
> >> for what I'm referring to.
> >>
> >> Gary and I have been discussing this off-list and the reason has been
> >> found: service(8) has this code in it:
> >>
> >>   checkyesno $rcvar 2>/dev/null && echo $file
> >>
> >> This explains why there's no warn() or err() output on the terminal --
> >> it's being redirected to /dev/null prior.
> >>
> >> I do not know who maintains the rc(8) and rc.subr(8) framework, but
> >> they've got their work cut out for them.
> >>
> >> (Note: the echo statements in warn() and err() could be replaced with
> >> "logger -s" as I said; this would allow the "echo 1>&2" to be removed)
> >>
>  2) These messages should not be displayed at all (i.e. lack of an
>  xxx_enable variable should imply xxx_enable="no").
> >>>
> >>> I see this message as one more level of supervision.
> >>>
> >>> If undefined at /etc/make.conf the value of xxx_enable is "no" from the
> >>> system's POV (i.e. the service is not strarted). From the
> >>> admininstrators's POV the port was installed BUT is not used. It's up
> >>> to admininstrator whether it's OK or not -- just let him remind.
> >>
> >> I believe the point you're trying to make is that the warning in
> >> question should 'act as a reminder to the administrator that they need
> >> to set xxx_enable="yes" in rc.conf'.
> >>
> >> If not: please explain if you could what you mean, because I don't
> >> understand.
> >>
> >> If so: I strongly disagree with this method of approach, as what you've
> >> proposed is a borderline straw man argument.
> >>
> >> Reminding the admin to set xxx_enable is presently done inside most
> >> ports' pkg-message.  IMO, this should really be done inside bsd.port.mk
> >> when USE_RC_SUBR is used, emitting a message during install that says
> >> something like:
> >>
> >> To enable the xxx service, please add the following to /etc/rc.conf:
> >> xxx_enable="yes"
> >>
> >> Of course, I don't know if this would work for packages.
> >>
> >> The current message for  is this:
> >>
> >> WARNING: $xxx_enable is not set properly - see rc.conf(5).
> >>
> >> The message is entirely misleading for this specific situation; it isn't
> >> "reminding" an administrator -- if anything it's confusing them (thread
> >> is case in point).  If we're going to cater to ignorance, then the
> >> message should reflect the situation.
> >>
> >> Thus IMO, this is what ***should*** happen:
> >>
> >> Definition in rc.confBehaviour/result
> >> ---  ---
> >> myprog_enable="yes"  emit no warnings, service should run
> >> myprog_enable="no"   emit no warnings, service should not run
> >> myprog_enable="abc123"   emit a warning,   service should not run
> >>   emit no warnings, service should not run
> >
> >
> > I think case 4 ("") is a case where a warning should be 
> > emitted because it is arguably not immediately apparent what will actually 
> > happen if no definition is present.  In the case of services in the base OS 
> > it is well-defined: every service should have an explicit default in 
> > /etc/defaults/rc.conf that you can easily consult to know definitively what 
> > will happen with that service.  (If it doesn't, that is a bug, IMHO.)
> >
> > For ports, the case is not so clear.  There is a general trend for the port 
> > rc.d script to default its respective xxx_enable explicitly to "NO".  But 
> > it i

Re: ZFS "stalls" -- and maybe we should be talking about defaults?

[Gary Palmer]

On Tue, Mar 05, 2013 at 12:40:38AM -0500, Garrett Wollman wrote:
> In article <8c68812328e3483ba9786ef155911...@multiplay.co.uk>,
> kill...@multiplay.co.uk writes:
> 
> >Now interesting you should say that I've seen a stall recently on ZFS
> >only box running on 6 x SSD RAIDZ2.
> >
> >The stall was caused by fairly large mysql import, with nothing else
> >running.
> >
> >Then it happened I thought the machine had wedged, but minutes (not
> >seconds) later, everything sprung into action again.
> 
> I have certainly seen what you might describe as "stalls", caused, so
> far as I can tell, by kernel memory starvation.  I've seen it take as
> much as a half an hour to recover from these (which is too long for my
> users).  Right now I have the ARC limited to 64 GB (on a 96 GB file
> server) and that has made it more stable, but it's still not behaving
> quite as I would like, and I'm looking to put more memory into the
> system (to be used for non-ARC functions).  Looking at my munin
> graphs, I find that backups in particular put very heavy pressure on,
> doubling the UMA allocations over steady-state, and this takes about
> four or five hours to climb back down.  See
>  for an example.
> 
> Some of the stalls are undoubtedly caused by internal fragmentation
> rather than actual data in use.  (Solaris used to have this issue, and
> some hooks were added to allow some amount of garbage collection with
> the cooperation of the filesystem.)

Just as a note that there was a page I read in the past few months
that pointed out that having a huge ARC may not always be in the best
interests of the system.  Some operation on the filesystem (I forget
what, apologies) caused the system to churn through the ARC and discard
most of it, while regular I/O was blocked

Unfortunately I cannot remember where I found that page now and I don't
appear to have bookmarked it

>From what has been said in this thread I'm not convinced that people
are hitting this issue, however I would like to raise it for
consideration

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems booting into ZFS on recent stable/9

[Gary Palmer]

On Mon, Jul 01, 2013 at 02:49:35PM -0400, Chris Ross wrote:
> 
>   I had a sparc64 (Netra X1) running a stable/9 from late March 2013.  
> Actually, the kernel may've been a bit newer than that as I was working with 
> folks to diagnose and repair some Netra-X1 specific issues.  But, ZFS worked 
> fine.  I have two pools, zroot as a RAID1 (using equally sized partitions at 
> the front of two large disks), and a zdata that is a large pool of the 
> remaining space of both disks concatenated together.
> 
>   After installing a kernel from a build of [yesterday's] stable/9 today, I 
> now get a failure when trying to boot, which can be seen at the end of this 
> clip from the end of the boot messages below.
> 
>   Is anyone aware of a change in recent months that might've caused this, or 
> have any idea what I may've done wrong?  In google'ing I've seen a few posts 
> talking about ways to import the zfs pool to adjust the cache file, but I'm 
> not sure if that is or isn't my problem.  I don't think I did anything 
> specific with configuring cache files for either pool.
> 
>   Thoughts are welcome.  I don't have physical access to the machine for 
> quite a few more hours, but when I do should be able to net-boot into the 
> earlier freebsd stable/9 that I originally installed onto this host, and can 
> try a few more things.
> 
> - Chris
> 
> 
> atapci0:  port 
> 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x1022f
>  at device 13.0 on pci0
> atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access 
> bug, expect reduced performance
> ata2:  at channel 0 on atapci0
> ata3:  at channel 1 on atapci0
> rtc0:  at port 0x70-0x71 on isa0
> uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 43 on isa0
> uart0: console (9600,n,8,1)
> uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 on isa0
> ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is 
> present;
> to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf.
> ZFS filesystem version: 5
> ZFS storage pool version: features support (5000)
> Timecounter "tick" frequency 5 Hz quality 1000
> Event timer "tick" frequency 5 Hz quality 1000
> Timecounters tick every 1.000 msec
> usbus0: 12Mbps Full Speed USB v1.0
> Root mount waiting for: usbus0
> ugen0.1:  at usbus0
> uhub0:  on usbus0
> uhub0: 2 ports with 2 removable, self powered
> Trying to mount root from zfs:zroot []...
> Mounting from zfs:zroot failed with error 2.
> 
> Loader variables:
>   vfs.root.mountfrom=zfs:zroot

What is the interface that the disk(s) that ZFS are on?  If it's the
AcerLabs ATA controller, then there are no disks found.  There is an
earlier ATA bus (at a guess from the fact ata2 and ata3 are shown above),
however I don't see any disks detected.  Normally ATA and SCSI/SAS disks
are probed asynchronously near the end of the boot and that appears
to be missing

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Interpreting MCA error output

[Gary Palmer]

On Tue, Jul 16, 2013 at 05:47:43PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> Approx. two years ago there was a thread on -stable about MCA output.
> 
> See
> 
> http://lists.freebsd.org/pipermail/freebsd-stable/2011-October/064083.html
> 
> for a post from Jeremy Chadwick with a link to a AMD paper on
> that topic ?
> 
> http://www.amd.com/us/Documents/47644A_ecc_embedded.pdf
> 
> which is no longer available 8-( Anyone has a copy ?


Check archive.org

e.g.

http://web.archive.org/web/2012020100*/http://www.amd.com/us/Documents/47644A_ecc_embedded.pdf

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Listen queue overflow

[Gary Palmer]

On Thu, Aug 01, 2013 at 10:47:40AM -0400, Mike Tancsa wrote:
> After upgrading from a RELENG9 kernel from June 18th to July 27th, I am
> seeing this odd new message.  Is this a new bug, or just a new
> diagnostic message ? I am guessing it happened after r253035 ?
> 
> 
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance

If you run 

netstat -naA | grep fe001ac76930

you should be able to identify which socket is producing the warning
messages.  That should give you a better understanding of what is
triggering the messages

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9-Stable + Atom D510 Freeze

[Gary Palmer]

On Fri, Sep 20, 2013 at 09:12:09AM -0400, Thomas Laus wrote:
> > Tom,
> > I have had multiple D510's and now D525's that are part of my test
> > systems, all are 4GB machines and all run the latest (ie 2 days old) 9.X
> > Stable.  They're faultless.  I have a D510 in production serving 30
> > users - yes its a 1G system running, sendmail, squid, samba as PDC. 
> > It's been in place for at least 7 months and runs without any hiccups.
> > 
> > Though I would point out that the Atom processor does NOT do out of
> > order processing, so a VIA motherboard that is of lower GHz builds
> > worlds/ports in less time that a supposedly faster Atom. 
> > 
> > Your question re HT, yes HT introduces some additional latency, but is
> > unlikely to be the problem.
> >
> Thanks for the information about the HT CPU's.  I asked the question to the 
> group because I did not know if they were functionally any different than a 
> traditional CPU.  I successfully built my problem port, Tshark, yesterday 
> while monitoring 'top' on another console.  I observed that all 4 cpu's were 
> in service for the build and at times were running at 100 percent each.  The 
> State column on all 4 occasionally showed a 'pfault' on all 4 but recovered 
> and the build continued to successful completion.
>  
> > When I experience something like spurious reboots and it is definately
> > not hardware, then I delete /usr/src and /usr/ports and perform a
> > complete rebuild.  (Yes seriously, and on the Atom's we're talking days,
> > aren't we :)  )
> >
> I have been using this Atom D510 since it was released about 3 years ago.  It 
> ran on FreeBSD 8-Stable until about a month ago.  I installed an Intel 520 
> SSD and loaded a fresh copy of a FreeBSD 9 Snapshot.  After getting the 
> source and ports tarballs, I used svnup to bring both up to date.  I built 
> and installed world and the kernel to bring me up to Stable.  I rebuilt all 
> of my ports using Portmaster.
> 
> The spurious reboot issue existed for the last 3 years when running FreeBSD-8 
> Stable.  I never had the problem building world or kernel.  It only occurred 
> when building some ports.  Subversion and Tshark more often than others.  
> FreeBSD 9-Stable was frozen when I tried to build tshark, but I was able to 
> build it OK yesterday.  Everything hardware related other than the Atom 
> microprocessor and the Intel motherboard itself is new.  The OS is now a 
> different version and all of the source was rebuilt monthly.  The ports have 
> been been built many times in the last 3 years.

When building kernel & world do you use the '-j' argument to do parallel
builds?  AFAIK thats not done by default, but it is for some ports.

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 9-Stable + Atom D510 Freeze

[Gary Palmer]

On Fri, Sep 20, 2013 at 10:49:28AM -0400, Thomas Laus wrote:
> Gary Palmer [gpal...@freebsd.org] wrote:
> > 
> > When building kernel & world do you use the '-j' argument to do parallel
> > builds?  AFAIK thats not done by default, but it is for some ports.
> >
> Gary:
> 
> I just use the system defaults when building anything.  If there is a
> '-j' argument passed to the compiler, I was not the one that did it.
> Does this mean that the port building process needs to determine the
> processor type in the configure stage?  I only use portmaster to keep
> the ports updated.  I don't know of a global hook that will change the
> compiler build flags in portmaster.

Hi Tim,

It's not a compiler flag, it's a make flag.  make -j n will fork off up to
n compilers to do the build.  If you just do "make buildworld" then there
is no parallel compilation.

It used to be that ports had MAKE_JOBS_SAFE in the Makefile to mark that
the port could be built using parallel compiles with the '-j' argument
to make.  It appears that the logic has been switched and now you have
to mark them as MAKE_JOBS_UNSAFE to say that parallel builds shouldn't be
done, indicating that parallel builds are the default now (unless I'm
misreading the code)

You can try putting

DISABLE_MAKE_JOBS=yes

into /etc/make.conf to see if that stops the problem on port builds.
Alternatively I think you could do

portmaster -m DISABLE_MAKE_JOBS=yes 

However you'd have to do that each time you run portmaster.  I think
putting

PM_MAKE_ARGS="DISABLE_MAKE_JOBS=yes"

in your .portmasterrc may do the same thing (not tried it).

Note: this is NOT a fix.  If it works, it merely stops the ports builder
from triggering the problem by not doing parallel compiles.  The compiles
will also take longer.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Is there a linux_base available for RELENG_9?

[Gary Palmer]

On Mon, Mar 09, 2015 at 05:44:55PM -0700, Chris H wrote:
> I performed av svn update for both src (r279796),
> and ports (r380829) last night. building/installing
> world/kernel, went as one would hope. Upgrading ports
> was a different story. Given this box has an nVidia card.
> I usually start by upgrading emulators/linux_base; which
> according to UPDATING; meant linux_base-f10 --> linux_base-c6.
> I deinstalled x11/nvidia-driver, followed by
> emulators/linux_base-f10. I then attempted to make install
> emulators/linux_base-c6, which resulted in a message
> that it wasn't supported. So I simply cd'd to
> emulators/linux_base-f10, followed by make install. Which
> resulted in a CVE message; indicating it was vulnerable
> to glib issues. I'm now stuck w/o hardware support for
> my video card, and unable to effectively follow
> a safe port upgrade path, that enables me to keep the
> options I have chosen for my currently installed ports.
> Is there a *safe* linux_base available?
> 
> Thank you for all your time, and consideration.

If you set

sysctl compat.linux.osrelease=2.6.18

you can install linux_base-c6 on RELENG_9

It works well enough at least for nvidia-driver, as my main desktop
is 9.3-RELEASE-p9 and has nvidia-driver and linux_base-c6-6.6_3 
installed

Remember to put

compat.linux.osrelease=2.6.18

into /etc/sysctl.conf so it's preserved on startup

I believe if you read the message from linux_base-c6 that's basically
what it told you to do.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Is there a linux_base available for RELENG_9?

[Gary Palmer]

On Mon, Mar 09, 2015 at 06:09:04PM -0700, Chris H wrote:
> On Tue, 10 Mar 2015 00:51:06 +0000 Gary Palmer  wrote
> 
> > On Mon, Mar 09, 2015 at 05:44:55PM -0700, Chris H wrote:
> > > I performed av svn update for both src (r279796),
> > > and ports (r380829) last night. building/installing
> > > world/kernel, went as one would hope. Upgrading ports
> > > was a different story. Given this box has an nVidia card.
> > > I usually start by upgrading emulators/linux_base; which
> > > according to UPDATING; meant linux_base-f10 --> linux_base-c6.
> > > I deinstalled x11/nvidia-driver, followed by
> > > emulators/linux_base-f10. I then attempted to make install
> > > emulators/linux_base-c6, which resulted in a message
> > > that it wasn't supported. So I simply cd'd to
> > > emulators/linux_base-f10, followed by make install. Which
> > > resulted in a CVE message; indicating it was vulnerable
> > > to glib issues. I'm now stuck w/o hardware support for
> > > my video card, and unable to effectively follow
> > > a safe port upgrade path, that enables me to keep the
> > > options I have chosen for my currently installed ports.
> > > Is there a *safe* linux_base available?
> > > 
> > > Thank you for all your time, and consideration.
> > 
> > If you set
> > 
> > sysctl compat.linux.osrelease=2.6.18
> > 
> > you can install linux_base-c6 on RELENG_9
> > 
> > It works well enough at least for nvidia-driver, as my main desktop
> > is 9.3-RELEASE-p9 and has nvidia-driver and linux_base-c6-6.6_3 
> > installed
> > 
> > Remember to put
> > 
> > compat.linux.osrelease=2.6.18
> > 
> > into /etc/sysctl.conf so it's preserved on startup
> > 
> > I believe if you read the message from linux_base-c6 that's basically
> > what it told you to do.
> Thanks for the reply, Gary.
> Right you are. That's exactly what I did to stage for the upgrade;
> entered 'compat.linux.osrelease=2.6.18' into etc/sysctl.conf
> rebooted, deinstalled x11/nvidia-driver, emulators/linux_base-f10,
> cd emulators/linux_base-c6; make install
> which led to:
> ===>  linux_base-c6-6.6_3 compat.linux.osrelease: 2.6.16 is not supported,
> please use 2.6.18, BEWARE this is highly experimental.
> *** [all] Error code 1
> 
> Stop in /usr/ports/emulators/linux_base-c6.
> 
> Thanks! and sorry for not being more detailed in the first place.

For some reason your sysctl.conf setting didn't take.  You should
investigate why and resolve that and then the port should work.

A temporary work around would be to run

sysctl compat.linux.osrelease=2.6.18

from a root shell, but it won't last past reboot.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Many core dumps in pthread_getspecific.

[Gary Palmer]

On Sat, Jun 06, 2015 at 06:08:21PM +0300, Konstantin Belousov wrote:
> On Sat, Jun 06, 2015 at 09:50:22AM +0200, Andre Meiser wrote:
> > On Wed, Jun 03, 2015 at 16:58 +0200, Konstantin Belousov wrote:
> > > You should recompile both libc and libthr with debugging symbols, like
> > > cd /usr/src
> > > (cd lib/libc && make all install DEBUG_FLAGS=-g)
> > > (cd lib/libthr && make all install DEBUG_FLAGS=-g)
> > > then obtain the core dump and post backtraces.
> > 
> > Thank you, that was exactly what I was looking for. Now I like FreeBSD
> > even more. ;)
> >
> > I made this short after and also rebooted the entire system to make
> > all programmes use those debug libs. Since than I had not a single
> > core dump.
> Which means, most likely, that your installation was corrupted.
> 
> >
> > I experienced something similar in the past, that with activated
> > debugging some errors can't be triggered any longer.
> >
> > At the moment I'm happy without crashes and I can work with this
> > system. As soon as I'm getting a new core dump, I'll post the
> > backtrace. If this won't happen for weeks, I may recompile the libs
> > again, try to find a way to trigger the bug on purpose, enable the
> > debug flag again and than provide the info.
> >
> > In the meantime, maybe a core developer may think about the lines
> > of code I'd provided. Why is _get_curthread() compared to NULL at
> > thr_kern.c (line 601) but not at thr_spec.c (line 224)? Either
> > _get_curthread() never ever returns NULL, than it's pointless to test
> > it or it's missing [not only] at thr_spec.c.
> Whole thr_kern.c file is 213 lines long in the HEAD.
> Might be, a core developer has a 601-lines long thr_kern.c.

lib/libkse/thread/thr_kern.c is longer and has a 
_get_curthread() call around line 601.

Regards,

Gary
 
> The only way for _get_curthread() to return NULL or, more likely, a
> garbage, is for the call to _get_curthread() to happens before the
> threading machinery was initialized. WRT the thr_spec.c, correct code
> must call pthread_key_create(3) at least once before calling any other
> pthread_key_*(3) functions. The implementation of pthread_key_create(3)
> interface, the function _pthread_key_create(), calls _thr_check_init()
> as the first action, and this helper initializes threading. So if
> _get_curthread() in any pthread_key_*() function returns NULL or
> garbage, this is an application' bug.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Interesting Boot failure on HEAD with a large number of IGB nics

[Gary Palmer]

On Wed, Jul 22, 2015 at 12:11:09PM -0400, Mark Saad wrote:
> All
>  I am wondering if anyone has run into this issue before , and if there is
> a fix.
> I have a Scalable Informatics siRouter with 24 Intel I350 igb nics and 8
> intel 82599ES ixgbe/ix nic . The SiRouter is a Supermicro X9DRX+-F with a
> bunch of intel nics.
> 
> On Head I run into a boot panic out of the box while plumbing the usb
> controller . The box crashes with
> 
> ehci0:  mem 0xdd923000-0xdd9233ff irq 16
> at device 26.0 on pci0
> panic: Couldn't find an APIC vector for IRQ 16
> 
> However it has only probed 8 of the 24 igb when is crashes. Here is the
> complete boot up with some additional info.
> 
> http://pastebin.com/MfbEwwg4
> 
> Now the interesting thing.
> 
>  DragonFly 4.2x boots fine  see the dmesg here
> http://dmesgd.nycbug.org/index.cgi?action=dmesgd&do=view&id=2778
> 
> OpenBSD boots and finds the nics as well see dmesg here
> http://dmesgd.nycbug.org/index.cgi?action=dmesgd&do=view&id=2777
> 
> NetBSD Pukes while probing something out of the box and I cant get the
> serial console to work.
> 
> Linux 2.6 CentOS 6.6 works
> 
> OmniOS / Illumos-gate and Illumos-joyent work out of the box
> 
> 
> 
> So my goal here is to make the box boot FreeBSD . It had been used prior
> running OmniOS and CentOS and well now I want to make it work. :)
> 
> Any ideas here ?


I'm no expert, but you may want to try setting

hw.igb.num_queues=1

and maybe

hw.ixgbe.num_queues=1

in the boot loader and trying that.

Regards,

Gary

P.S. freebsd-net@ may be a better list than either -stable or -hackers.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Interesting Boot failure on HEAD with a large number of IGB nics

[Gary Palmer]

On Wed, Jul 22, 2015 at 02:20:06PM -0400, Mark Saad wrote:
> On Wed, Jul 22, 2015 at 1:54 PM, Garrett Cooper 
> wrote:
> 
> >
> > > On Jul 22, 2015, at 10:14, Gary Palmer  wrote:
> >
> > ...
> >
> > > I'm no expert, but you may want to try setting
> > >
> > > hw.igb.num_queues=1
> > >
> > > and maybe
> > >
> > > hw.ixgbe.num_queues=1
> > >
> > > in the boot loader and trying that.
> >
> > There was another discussion that took place around June on current that
> > might be helpful. I think the solution boiled down to what Gary described
> > above, because the driver auto tuning was broken...
> > Thanks!
> > -NGie
> 
> 
> NGie
>  I'll try the queues option but; why was does that kill my ehci hub ? Note
> 
> ehci0:  mem 0xdd923000-0xdd9233ff irq 16
> at device 26.0 on pci0
> panic: Couldn't find an APIC vector for IRQ 16

I believe the error message could be better written as "Couldn't find a
free APIC vector".  The IGB cards allocted multiple MSI-X interrupts for
multi-queue use and exhausted the available pool, and the USB hub (ehci0)
just happened to be the next thing probed by the PCI bus and tripped the
panic.

At least that is my understanding.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Trouble booting from EFI with 12-stable

[Gary Palmer]

On Fri, Jan 11, 2019 at 01:18:35PM -0600, Kyle Evans wrote:
> On Fri, Jan 11, 2019 at 1:15 PM Jonathan Chen  wrote:
> >
> > On Sat, 12 Jan 2019 at 07:55, Stefan Bethke  wrote:
> > [...]
> > > The UEFI man page has a good explanation of which files are involved in 
> > > booting:
> > > https://www.freebsd.org/cgi/man.cgi?query=uefi&sektion=8&manpath=freebsd-release-ports
> > >
> > > I mounted the ESP and copied /boot/boot1.efi to 
> > > /boot/efi/EFI/BOOT/BOOTX64.EFI. Surprisingly, the new boot1.efi is much 
> > > smaller than what I had before (according to the timestamp from 
> > > November), but using that, booting seems to be restored.
> > >
> > > # grep efi /etc/fstab
> > > /dev/ada0p2 /boot/efi   msdos   rw,noauto   0   0
> > > # mount /boot/efi
> > > # ls -l /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/bak/BOOTX64.EFI
> > > -rwxr-xr-x  1 root  wheel   81920 Jan 11 18:43 
> > > /boot/efi/EFI/BOOT/BOOTX64.EFI*
> > > -rwxr-xr-x  1 root  wheel  410112 Nov 25 16:27 
> > > /boot/efi/EFI/BOOT/bak/BOOTX64.EFI*
> >
> > While the uefi(8) man page suggests that boot1.efi should be used,
> > loader.efi can also substituted. I believe the release images use
> > loader.efi instead of boot1.efi, as it's slightly more efficient.
> >
> 
> Indeed, boot1.efi is a hack that's going to get kicked out of the tree
> in due time.

Can I request a clarification in the man page?  At least in 11.2 the
uefi(8) man page state

-- QUOTE --
   2.   boot1.efi reads boot configuration from /boot.config or
/boot/config.  Unlike other first-stage boot loaders,
boot1.efi passes the configuration to the next stage boot
loader and does not itself act on the contents of the file.
-- QUOTE --

It's not 100% clear, although implied by the fact that the next step
looks for freebsd-ufs or freebsd-zfs partitions, that the boot.config is
loaded from the ESP (at least I'm guessing that's where it's loaded
from).  Could the location of where boot.config is loaded from be
clarified please?

Thanks,

Gary

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Trouble booting from EFI with 12-stable

[Gary Palmer]

On Fri, Jan 11, 2019 at 03:47:45PM -0700, Warner Losh wrote:
> On Fri, Jan 11, 2019 at 3:22 PM Gary Palmer  wrote:
> 
> > On Fri, Jan 11, 2019 at 01:18:35PM -0600, Kyle Evans wrote:
> > > On Fri, Jan 11, 2019 at 1:15 PM Jonathan Chen  wrote:
> > > >
> > > > On Sat, 12 Jan 2019 at 07:55, Stefan Bethke  wrote:
> > > > [...]
> > > > > The UEFI man page has a good explanation of which files are involved
> > in booting:
> > > > >
> > https://www.freebsd.org/cgi/man.cgi?query=uefi&sektion=8&manpath=freebsd-release-ports
> > > > >
> > > > > I mounted the ESP and copied /boot/boot1.efi to
> > /boot/efi/EFI/BOOT/BOOTX64.EFI. Surprisingly, the new boot1.efi is much
> > smaller than what I had before (according to the timestamp from November),
> > but using that, booting seems to be restored.
> > > > >
> > > > > # grep efi /etc/fstab
> > > > > /dev/ada0p2 /boot/efi   msdos   rw,noauto   0
> >0
> > > > > # mount /boot/efi
> > > > > # ls -l /boot/efi/EFI/BOOT/BOOTX64.EFI
> > /boot/efi/EFI/BOOT/bak/BOOTX64.EFI
> > > > > -rwxr-xr-x  1 root  wheel   81920 Jan 11 18:43
> > /boot/efi/EFI/BOOT/BOOTX64.EFI*
> > > > > -rwxr-xr-x  1 root  wheel  410112 Nov 25 16:27
> > /boot/efi/EFI/BOOT/bak/BOOTX64.EFI*
> > > >
> > > > While the uefi(8) man page suggests that boot1.efi should be used,
> > > > loader.efi can also substituted. I believe the release images use
> > > > loader.efi instead of boot1.efi, as it's slightly more efficient.
> > > >
> > >
> > > Indeed, boot1.efi is a hack that's going to get kicked out of the tree
> > > in due time.
> >
> > Can I request a clarification in the man page?  At least in 11.2 the
> > uefi(8) man page state
> >
> > -- QUOTE --
> >2.   boot1.efi reads boot configuration from /boot.config or
> > /boot/config.  Unlike other first-stage boot loaders,
> > boot1.efi passes the configuration to the next stage boot
> > loader and does not itself act on the contents of the file.
> > -- QUOTE --
> >
> > It's not 100% clear, although implied by the fact that the next step
> > looks for freebsd-ufs or freebsd-zfs partitions, that the boot.config is
> > loaded from the ESP (at least I'm guessing that's where it's loaded
> > from).  Could the location of where boot.config is loaded from be
> > clarified please?
> >
> 
> In 11.2, boot1.efi was used to load the next stage of the boot process
> (which was /boot/loader.efi off either a UFS or ZFS filesystem based on a
> number of heuristics). The boot.config was loaded from the same filesystem
> loader.efi was loaded from, and not the ESP.

Hi Warner,

OK, how does boot1.efi know where to look for boot.config?  Are steps
2 and 3 reversed in the man page?

Thanks,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Cisco 12G SAS RAID support (FreeBSD 12.1-RELEASE) ?

[Gary Palmer]

On Sat, Nov 09, 2019 at 11:38:54AM -0500, Chris Ross wrote:
> On Fri, Nov 08, 2019 at 02:28:17PM -0800, Doug Ambrisko wrote:
> > On Tue, Nov 05, 2019 at 09:44:36PM +0100, Miroslav Lachman wrote:
> > | Chris Ross wrote on 11/05/2019 21:19:
> > | > On Tue, Nov 05, 2019 at 08:20:15PM +0100, Miroslav Lachman wrote:
> > | >> Chris Ross wrote on 11/05/2019 19:34:
> > | >>> Hello.  I have a Cisco UCS C220-M5 with a RAID controller.  It calls 
> > itself
> > | >>> "Cisco 12G Modular Raid Controller with 2GB cache", PPID UCSC-RAID-M5.
> > | >>> Looking at the CIMC, it shows the PCI vendor/device ids 1000:0014, 
> > which
> > | >>> looks to be an LSI MegaRAID Tri-Mode SAS3516.  It looks like this 
> > should
> > | >>> be supported by the mpr(4) driver, but it doesn't seem to recognize it
> > | >>> at boot time.
> > | 
> > | mpr_load="YES" goes to /etc/loader.conf
> > | 
> > | If you need to load mpr manually in boot prompt I am not sure if it 
> > | should be:
> > | load mpr
> > | or
> > | load mpr.ko
> > | of full path
> > | load /boot/kernel/mpr.ko
> > 
> > This should be a mrsas card and not an HBA!  mrsas supports all current
> > UCS RAID cards ... and the next unreleased UCS system :-)  You might need
> > the one in -current for that.  I'm not sure what is in 12.1.
> 
> Hi Doug!  Thanks.  Okay, I infer from that that the mpr driver is for
> HBAs that aren't raid?  Grepping through the sources for 3516 found me
> only mpr.  Looking more carefully, at mrsas while knowing specifically
> what I'm looking for, I find the PCI device ID (0x0014) as "AVAGO Ventura
> SAS Controller".  And, that code (mrsas) is about the same in stable-12 as
> is it in -current.
> 
> Can you provide some guidance of what I need to do to get the mrsas
> driver to identify it when booting the install ISO?

See the "PRIORITY" section of

https://www.freebsd.org/cgi/man.cgi?query=mrsas&sektion=4

You can also set that tunable via the loader

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: A little story of failed raid5 (3ware 8000 series)

[Gary Palmer]

On Sun, Aug 26, 2007 at 11:38:19AM -0700, Darren Pilgrim wrote:
> Tom Judge wrote:
> >Tom Samplonius wrote:
> >>The real solution is RAID scrubbing:  a low level background process
> >>that reads every sector of every disk.  All of the real RAID systems
> >>do this (usually scheduled weekly, or every other week).  Most 3ware
> >>RAID card don't have this feature.
> >>
> >>So rather than not using RAID5 or RAID6 again, you should just not
> >>use 3ware anymore.
> >
> >If you use the 3dm2 management interface you can schedule verify and
> >rebuild tasks to run on a regular basis.  I think that 7500 series
> >controllers can do this, 9500 and 9550's definitely can.
> 
> Actually it's all 7/8/9xxx series cards.  The 9xxx series cards also do 
> auto-verify so there's no need to schedule the task.

Sorry, I do not believe that is the case.  I have a 8506-4LP and if
I click on Management -> Scheduling in the 3dm web interface it says

(0x0C:0x0017): Scheduling is not supported on this controller model

However you might be able to cheat using the tw_cli port to run
the schedules out of cron rather than native on the card
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Freebsd.org is down

[Gary Palmer]

On Fri, Sep 14, 2007 at 01:26:33PM -0700, Jon wrote:
> Check the freebsd-questions list for more info

For those, like me, who are not subscribed to freebsd-questions,
the list archives can be accessed at:

http://lists.freebsd.org/pipermail/freebsd-questions/2007-September/thread.html#158022

That URL appears to still be answering presently.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Some processes stay active after killing its PID

[Gary Palmer]

On Tue, Nov 27, 2007 at 08:59:06PM +0100, Roland Smith wrote:
> On Tue, Nov 27, 2007 at 01:24:56PM -0600, Stephen Montgomery-Smith wrote:
> > 
> > 
> > On Tue, 27 Nov 2007, Honza Holakovsky wrote:
> > 
> >> Well, didn't know that, "/bin/kill -9 wdfs_PID" works, great
> >> 
> >> Thanks a lot, after your advice I read an article about csh built-in
> >> commands, never heard of it from any fbsd handbook...
> > 
> > I am completely baffled why this worked.  Why would /bin/kill -9 work when 
> > the built in csh kill -9 wouldn't?
> 
> According to the manual page for the built-in kill command, it
> recognizes 'kill -s 9', but not 'kill -9'.

The man page is wrong

% xcalc &
[1] 4730
% kill -BUS 4730
% 
[1]Bus error xcalc
% xcalc &
[1] 4731
% kill -10 4731
% 
[1]Bus error xcalc
% echo $SHELL
/bin/tcsh
% 

LSOF shows I'm using the system tcsh, and AFAIK it behaves
the same for being invoked as both /bin/csh and /bin/tcsh

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RELENG_6 kernel panic + savecore(8) problem

[Gary Palmer]

On Sat, Dec 01, 2007 at 03:28:56AM -0800, Jeremy Chadwick wrote:
> On Sun, Nov 25, 2007 at 06:21:36PM -0800, Jeremy Chadwick wrote:
> > Tracing pid 3 tid 11 td 0xc7c6ed80
> > kdb_enter(c06e475e,c073ade0,c06efb55,e6876bc8,100,...) at kdb_enter+0x30
> > panic(c06efb55,ce04b280,100,c07156c0,0,...) at panic+0xce
> > handle_written_inodeblock(c858d200,dbda0a70,c07388e4,c06a3e4a,e6876c30,...) 
> > at handle_written_inodeblock+0x5df
> > softdep_disk_write_complete(dbda0a70,c0652591,c80e65ac,e6876c94,c04e16c4,...)
> >  at softdep_disk_write_complete+0xf1
> > bufdone(dbda0a70,0,e6876ca8,c04e3e06,c80e65ac,...) at bufdone+0x7e
> > g_vfs_done(c80e65ac,0,0,c7d28200,c80a418c) at g_vfs_done+0xc6
> > biodone(c80e65ac,c0738808,24c,c06dff1c,64,...) at biodone+0xb2
> > g_io_schedule_up(c7c6ed80,4c,c7c6d218,c04e1bbc,e6876d24,...) at 
> > g_io_schedule_up+0x89
> > g_up_procbody(0,e6876d38,0,0,0,...) at g_up_procbody+0x7a
> > fork_exit(c04e1bbc,0,e6876d38) at fork_exit+0x7a
> > fork_trampoline() at fork_trampoline+0x8
> 
> To anyone who's familiar with the functions in the above backtrace:
> 
> Could the above panic be caused by exhaustion of memory allocated to the
> dirhash code (UFS_DIRHASH)?  I can provide details if needed, but
> thought I'd ask something somewhat vague for starters.  :-)

The panic message that you cut from the above text is

panic: handle_written_inodeblock: live inodedep

In version 1.181.2.17 of ffs_softdep.c (the current copy I have) that panic
happens at line 4664 when it attempts to free an inodedep structure
and fails because the structure is still needed for some reason.  From
the comments in the softdep.h file:

 * The "inodedep" structure tracks the set of dependencies associated
 * with an inode. 

So its a softupdates related panic relating to an I/O to an inode that
has completed.  I can't see how dirhash could have caused this.

To see why savecore() isn't saving your cores you might want to check
syslog.  savecore() should log to syslog at LOG_ERR priority in the
DAEMON facility.  Changing 

savecore_flags

in /etc/rc.conf to be "-vv" might show up what the problem is if the
box panic's and fails to save core again (it might also make boot
a lot messier on the console)

Regards,

Gary

P.S. I'm no softupates expert so I don't know what circumstances
caused the panic in the first place.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: magic disappearing coredumps

[Gary Palmer]

On Sat, Apr 25, 2009 at 01:21:18AM +1000, Horst G?nther Burkhardt III wrote:
> I'm trying to debug a piece of software. It dumps a core file which
> mysteriously vanishes. it's not in the program directory, nor my $HOME,
> nor /var/crash nor /var/core ...
> 
> Deliberately crashing /bin/sh also results in a core file which turns up
> nowhere on my filesystem.
> 
> Crossposting to -stable and -ppc because i'm uncertain whether this is a
> ppc issue or a bsd issue or simple operator incompetence.
> 
> I apologise if the answer is something that was a google away.

Did you check your ulimit limits to see if your login session
actually allows for coredumps to be created?

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: cvsup.uk.freebsd.org appears to not be serving

[Gary Palmer]

On Mon, May 04, 2009 at 09:26:57AM +0100, John wrote:
> Hi list, hopefully this is the right one and not -questions
> 
> cvsup.uk.freebsd.org appears to have not been serving these last few
> weeks. I get, variously, in my logs:
> 
> Parsing supfile "/etc/cvsupfile"
> Connecting to cvsup.uk.freebsd.org
> Connected to cvsup.uk.freebsd.org
> Rejected by server: Access limit exceeded; try again later
> Will retry at 03:08:08
> Retrying
> Connecting to cvsup.uk.freebsd.org
> Connected to cvsup.uk.freebsd.org
> Server software version: SNAP_16_1h
> Negotiating file attribute support
> Exchanging collection information
> Establishing passive-mode data connection
> Cannot connect to data port: Connection refused
> Will retry at 03:18:04
> Retrying
> Connecting to cvsup.uk.freebsd.org
> Connected to cvsup.uk.freebsd.org
> Server software version: SNAP_16_1h
> Negotiating file attribute support
> Exchanging collection information
> Establishing passive-mode data connection
> Cannot connect to data port: Connection refused
> Will retry at 03:37:33
> Retrying
> 
> ... on and on and on, continuously, 24/7.

Datapoint: I've been running cvsup daily against cvsup.uk.freebsd.org
without issue for a lot longer than a few weeks.  cvsup ends up running
somewhere between 6am and 8am and its been a while since I saw any
access limit problems.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Vulnerability question

[Gary Palmer]

On Tue, Jun 30, 2009 at 07:32:37PM +0200, Roland Smith wrote:
> On Tue, Jun 30, 2009 at 05:08:32PM +0200, Harald Weis wrote:
> > On Mon, Jun 29, 2009 at 08:40:52PM +0200, Roland Smith wrote:
> > > On Sun, Jun 28, 2009 at 10:56:54PM +0200, Harald Weis wrote:
> > > > Building lxdvdrip stops because linux-pango has known
> > > > vulnerabilities.
> > > 
> > > You can ignore vulnerabilities by setting the environment variable
> > > DISABLE_VULNERABILITIES. See ports(7).
> > 
> > Yes, I've done this already, but I've stepped back because I cannot
> > evaluate the risk.
> > 
> > > Are you running a linux binary of mplayer? Because a native mplayer
> > > binary does not require linux-pango! It just uses the native pango.
> > 
> > In fact, it's lxdvdrip which requires linux-pango [via linux-gtk2].
> > lxdvdrip is happy with the native mplayer.
> 
> Looking at the port Makefile [/usr/ports/multimedia/lxdvdrip/Makefile]
> and Freshports entries [http://www.freshports.org/multimedia/lxdvdrip/]
> for lxdvdrip, there is no sign of it directly requiring pango, let alone
> the Linux version. It is mplayer that depends on pango:
> 
> # cd /usr/ports/multimedia/lxdvdrip
> # make run-depends-list
> /usr/ports/misc/buffer
> /usr/ports/multimedia/dvdauthor
> /usr/ports/multimedia/libdvdnav
> /usr/ports/multimedia/libdvdread
> /usr/ports/multimedia/mpgtx
> /usr/ports/multimedia/mplayer
> /usr/ports/multimedia/transcode
> /usr/ports/sysutils/dvd+rw-tools
> 
> # cd /usr/ports/multimedia/mplayer
> # make run-depends-list
> /usr/ports/accessibility/atk
> /usr/ports/audio/cdparanoia
> /usr/ports/audio/esound
> /usr/ports/audio/libvorbis
> /usr/ports/converters/libiconv
> /usr/ports/devel/gio-fam-backend
> /usr/ports/devel/glib20
> /usr/ports/devel/pkg-config
> /usr/ports/devel/sdl12
> /usr/ports/graphics/aalib
> /usr/ports/graphics/png
> /usr/ports/multimedia/libtheora
> /usr/ports/multimedia/mplayer-skins
> /usr/ports/multimedia/x264
> /usr/ports/print/freetype2
> /usr/ports/x11-toolkits/gtk20
> /usr/ports/x11-toolkits/pango
> /usr/ports/x11/libX11
> /usr/ports/x11/libXv
> /usr/ports/x11/libXxf86vm
> 
> No linux-pango! I suspect that there is something wrong with your
> ports. Do you have the native version of pango installed? 
> 

I am not the OP, however I also ran into warnings about mplayer and
linux-pango.  I believe the problem comes from linux-realplayer

# cd /usr/ports/multimedia/mplayer
# make run-depends-list
/usr/ports/accessibility/atk
/usr/ports/audio/arts
/usr/ports/audio/libvorbis
/usr/ports/converters/libiconv
/usr/ports/devel/gio-fam-backend
/usr/ports/devel/glib20
/usr/ports/devel/pkg-config
/usr/ports/graphics/libGL
/usr/ports/graphics/libungif
/usr/ports/graphics/png
/usr/ports/multimedia/libdv
/usr/ports/multimedia/linux-realplayer
/usr/ports/multimedia/mplayer-skins
/usr/ports/multimedia/win32-codecs
/usr/ports/multimedia/x264
/usr/ports/multimedia/xvid
/usr/ports/print/freetype2
/usr/ports/x11-toolkits/gtk20
/usr/ports/x11-toolkits/pango
/usr/ports/x11/libX11
/usr/ports/x11/libXinerama
/usr/ports/x11/libXv
/usr/ports/x11/libXxf86dga
/usr/ports/x11/libXxf86vm
# grep REAL /var/db/ports/mplayer/options 
WITH_REALPLAYER=true

I don't have lxdvdrip installed so I don't think thats involved, at least
in my case.  There may be more than one path to the linux-pango
dependency however :-(

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: LSI SAS2008 mps driver preferred firmware version

[Gary Palmer]

On Sat, Nov 14, 2015 at 01:18:14PM +0100, Kai Gallasch wrote:
> On 12.11.2015 23:20 Royce Williams wrote:
> > Firmware should match driver, e.g.:
> > 
> > mps0: Firmware: 19.00.00.00, Driver: 19.00.00.00-fbs
> > 
> > 
> > Some of this may help -- not yet updated for 10.2, but may still be useful:
> > 
> > http://roycebits.blogspot.com/2015/01/freebsd-lsi-sas9211-8i-hba-firmware.html
> 
> Thanks! Lots of information about reflashing the 9211-8i.
> So I upgraded the old firmare of the controller from
> 
> mps0: Firmware: 05.00.17.00, Driver: 20.00.00.00-fbsd
> to mps0: Firmware: 20.00.04.00, Driver: 20.00.00.00-fbsd
> (FreeBSD 10.2)
> 
> As I understand it the firmware 20.00.00.00 was pulled by avago and
> replaced with the fixed version 20.00.04.00
> 
> I will give feedback if I notice any problems with this FW version.
> 
> As a side note: Flashing the 9211-8i to the new firmware version changed
> the way FreeBSD orders the disk devices on this server:
> 
> With the old firmware it looked like this:
> 
> root@:~ # camcontrol devlist
>  at scbus0 target 10 lun 0 (pass0,da0)
>  at scbus0 target 11 lun 0 (pass1,da1)
>  at scbus0 target 12 lun 0 (pass2,da2)
>  at scbus0 target 13 lun 0 (pass3,da3)
>  at scbus0 target 14 lun 0 (pass4,da4)
>  at scbus0 target 15 lun 0 (pass5,da5)
>  at scbus0 target 16 lun 0 (pass6,da6)
>  at scbus0 target 17 lun 0 (pass7,da7)
>  at scbus0 target 18 lun 0 (pass8,da8)
>  at scbus0 target 19 lun 0 (pass9,da9)
>  at scbus0 target 20 lun 0 (pass10,da10)
>  at scbus0 target 21 lun 0 (pass11,da11)
>  at scbus0 target 22 lun 0 (pass12,ses0)
>  at scbus7 target 0 lun 0 (pass13,ses1)
> 
> The order is according to the order the disks are placed in the drive
> bays: (da0, bay1; da1, bay2, ..)
> 
> 
> With the new firmware it now looks like this:
> 
>  at scbus0 target 8 lun 0 (pass0,da0)
>  at scbus0 target 9 lun 0 (pass1,da1)
>  at scbus0 target 10 lun 0 (pass2,da2)
>  at scbus0 target 11 lun 0 (pass3,da3)
>  at scbus0 target 12 lun 0 (pass4,da4)
>  at scbus0 target 13 lun 0 (pass5,da5)
>  at scbus0 target 14 lun 0 (pass6,da6)
>  at scbus0 target 15 lun 0 (pass7,da7)
>  at scbus0 target 16 lun 0 (pass8,da8)
>  at scbus0 target 17 lun 0 (pass9,da9)
>  at scbus0 target 18 lun 0 (pass10,da10)
>  at scbus0 target 19 lun 0 (pass11,da11)
>  at scbus0 target 20 lun 0 (pass12,ses0)
>  at scbus7 target 0 lun 0 (pass13,ses1)
> 
> So now the drive stuck in the last drive bay is seen as da0 and the
> drive in the first drive bay as da11
> 
> But: In the controller BIOS the scan order of the drives did not change
> at all with the new firmware! So the change is only in the way FreeBSD
> sees the drives.
> 
> My explanation for this change in drive ordering is, that my 9211-8i is
> a SUN branded one (SGX-SAS6-INT-Z) and the server is a SUN server. So
> maybe the original firmware contained some adaptations for this server,
> that are missing in the new firmware.
> 
> Can the way FreeBSD orders scanned SAS drives be changed? If not, no
> problem, as I use partition labels for my zfs pools and the disks are
> also labeled on the server as well.

You can do thinks in /boot/loader.conf to hard code bus and drive
assignments.  

e.g.

hint.da.0.at="scbus0"
hint.da.0.target="19"
hint.da.0.unit="0"
hint.da.1.at="scbus0"
hint.da.1.target="18"
hint.da.1.unit="0"

See scsi(4) or cam(4) for more hints.

You're probably better off using GPT labels though, as they will
survive any future disk order changes. The fact the target numbers 
changed means that loader.conf changes will fix the current issue
but may not work properly after any future firmware updates.

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with piped tar

[Gary Palmer]

On Tue, Aug 23, 2016 at 09:35:12AM +0200, Gerhard Schmidt wrote:
> Am 23.08.2016 um 09:18 schrieb Daniel Braniss:
> > 
> >> On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:
> >>
> >> Hi,
> >>
> >> i'm quite often use tar to copy files using
> >>
> >> tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
> > the ???new??? way:
> > tar cf - /some/dir | tar xvvd - -C /dest/dir
> > which of course does not explain way your version hangs, but this one is 
> > cleaner, and btw, don???t
> > include /.
> 
> that's very strange. It's working, but doesn't solve another related
> problem. When i pipe the tar thru nc a have the same problem as my
> version. And it's no difference if there is a tar c an the receiving end
> of nc or just a '> file.tar'

Is the sending side using nc -N ?  If not, the sending socket is not being
shut down.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with piped tar

[Gary Palmer]

On Tue, Aug 23, 2016 at 02:27:46PM +0200, Gerhard Schmidt wrote:
> Am 23.08.2016 um 13:31 schrieb Gary Palmer:
> > On Tue, Aug 23, 2016 at 09:35:12AM +0200, Gerhard Schmidt wrote:
> >> Am 23.08.2016 um 09:18 schrieb Daniel Braniss:
> >>>
> >>>> On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> i'm quite often use tar to copy files using
> >>>>
> >>>> tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
> >>> the ???new??? way:
> >>>   tar cf - /some/dir | tar xvvd - -C /dest/dir
> >>> which of course does not explain way your version hangs, but this one is 
> >>> cleaner, and btw, don???t
> >>> include /.
> >>
> >> that's very strange. It's working, but doesn't solve another related
> >> problem. When i pipe the tar thru nc a have the same problem as my
> >> version. And it's no difference if there is a tar c an the receiving end
> >> of nc or just a '> file.tar'
> > 
> > Is the sending side using nc -N ?  If not, the sending socket is not being
> > shut down.
> 
> Is that something new? Because it worked on freebsd9 without the -N option.

Yes.  It was introduced in 10.x for some reason.  It caught me out a few
times

> The problem seams to be that tar c doesn't terminate after the last File
> is send. I think it send the EOF (because nc -N terminates and therefor
> terminates the pipe) but the tar process doesn't terminate.

nc -N will terminate when the input pipe is closed AFAIK (i.e. the
process feeding into the pipe exits)

I presume you mean the tar process on the receiving side doesn't 
terminate?  Most odd.  I haven't tried tar across nc in a while,
I normally use dd or zfs send/receive

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 11.0 stuck on high network load

[Gary Palmer]

On Thu, Sep 15, 2016 at 01:13:35AM +0300, Slawa Olhovchenkov wrote:
> On Wed, Sep 14, 2016 at 03:04:20PM -0700, hiren panchasara wrote:
> 
> > On 09/15/16 at 12:57P, Slawa Olhovchenkov wrote:
> > > On Wed, Sep 14, 2016 at 02:43:06PM -0700, hiren panchasara wrote:
> > > 
> > > > On 09/15/16 at 12:35P, Slawa Olhovchenkov wrote:
> > > > > On Sun, Sep 04, 2016 at 06:46:12PM -0700, hiren panchasara wrote:
> > > > > 
> > > > > > On 09/05/16 at 12:57P, Slawa Olhovchenkov wrote:
> > > > > > > I am try using 11.0 on Dual E5-2620 (no X2APIC).
> > > > > > > Under high network load and may be addtional conditional system 
> > > > > > > go to
> > > > > > > unresponsible state -- no reaction to network and console (USB 
> > > > > > > IPMI
> > > > > > > emulation). INVARIANTS give to high overhad. Is this exist some 
> > > > > > > way to
> > > > > > > debug this?
> > > > > > 
> > > > > > Can you panic it from console to get to db> to get backtrace and 
> > > > > > other
> > > > > > info when it goes unresponsive?
> > > > > 
> > > > > ipmi console don't respond (chassis power diag don't react)
> > > > > login on sol console stuck on *tcp.
> > > > 
> > > > I assume you tried ~^b (tilda followed by ctrl+b) without success?
> > > 
> > > ~B, as in man ipmitool
> > 
> > No, not shift-b but ctrl-b.
> > 
> > I am not aware of ipmitool reference. On unresponsive console, try
> > ~^b (tilda followed by ctrl+b)
> 
> ipmitool ~B send break, do you talk about break or about special
> serial console keystroke to enter debuger, distinct from break?

A lot of old console servers used to send break when they reset or
on boot, so the FreeBSD console does not break to debugger when
a break command is received.  That's why the tidla CTRL-b is
required as it's sufficiently unlikely to be accidentally sent by
equipment connected to the serial console.

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs/raidz: seems like I'm failing with math

[Gary Palmer]

On Sun, Oct 16, 2016 at 09:56:10PM +0500, Eugene M. Zheganin wrote:
> Hi.
> 
> FreeBSD 11.0-RC1 r303979, zfs raidz1:
> 
> ===Cut===
> 
> # zpool status gamestop
>pool: gamestop
>   state: ONLINE
>scan: none requested
> config:
> 
>  NAMESTATE READ WRITE CKSUM
>  gamestopONLINE   0 0 0
>raidz1-0  ONLINE   0 0 0
>  da0 ONLINE   0 0 0
>  da1 ONLINE   0 0 0
>  da2 ONLINE   0 0 0
>  da3 ONLINE   0 0 0
>  da4 ONLINE   0 0 0
>  da5 ONLINE   0 0 0
> 
> ===Cut===
> 
> 6 disks 960 Gbs each:
> 
> ===Cut===
> 
> # smartctl -a /dev/da0
> smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-RC1 amd64] (local build)
> Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> === START OF INFORMATION SECTION ===
> Model Family: Samsung based SSDs
> Device Model: SAMSUNG MZ7KM960HAHP-5
> Serial Number:S2HTNX0H507466
> LU WWN Device Id: 5 002538 c402bdac1
> Firmware Version: GXM1003Q
> User Capacity:960 197 124 096 bytes [960 GB]

You're confusing disk manufacturer gigabytes with real (power of two)
gigabytes.  The below turns 960 197 124 096 into real gigabytes

% bc
scale = 4
960197124096 / 1024 / 1024 / 1024
894.2532


> Sector Size:  512 bytes logical/physical
> 
> [...]
> 
> ===Cut===
> 
> But:
> 
> ===Cut===
> 
> # zpool list gamestop
> NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAGCAP  DEDUP HEALTH  ALTROOT
> gamestop  5,22T  4,38T   861G -24%83%  1.00x ONLINE  -
> 
> ===Cut===
> 
> Why 5.22T ? If zpool is displaying raw size, it should be 960 x 6 = 5760 
> Gb = 5.65 T. If it's displaying the actual data, then it should be 960 x 
> 5 = 4800 Gb = 4.68 T. 5.22 T is neither of these. I'm stuck, please 
> explain. :)

Take 6 disks, size calculated above, and turn that into power of two TB:

894.2532 * 6 / 1024
5.2397

Close enough to 5.22, especially after ZFS has some overhead for it's
own data structures

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 11.0 Install Question

[Gary Palmer]

On Wed, Oct 19, 2016 at 01:55:23PM -0400, Kevin P. Neal wrote:
> On Wed, Oct 19, 2016 at 10:08:04AM +0100, Matthew Seaman wrote:
> > On 2016/10/19 09:55, Matt Smith wrote:
> > > On Oct 19 10:38, Miroslav Lachman wrote:
> > >> Jonathan Haack wrote on 2016/10/19 10:09:
> > >>> Awe geez ... pkg won't work ... says "shared object "libssl.so.7" not
> > >>> found, required by "pkg"
> > >>
> > >> Do not panic, just run pkg-static to upgrade pkg it-self
> > >>
> > >> /usr/local/sbin/pkg-static install -f pkg
> > >>
> > > 
> > > I think that these instructions should be in the announcement release
> > > notes as this question comes up a lot. The notes just say something like
> > > "upgrade all your packages". Most people will then just try and run pkg
> > > upgrade and get that error without knowing how to solve it. It's not
> > > intuitive unless you have come across this before.
> > 
> > pkg(8) does have a built-in warning when it detects an OS major version
> > upgrade, which is to do a forced upgrade of pkg(8) so it matches the ABI
> > versions of system shlibs.  Did that warning appear in this case?
> 
> Loading of shared libraries generally happens before main() is entered.
> It follows that pkg wouldn't have a chance to do anything useful before
> dying if a library is missing.

Hi,

I don't think this is strictly true

On one of my systems at least (10.x), the main pkg binary is in
/usr/sbin which is a shim which either offers to install a full
pkg binary or calls the full pkg binary with whatever arguments you
passed it.  The main pkg binary lives in /usr/local/sbin/pkg.

It seems it should be possible to add some kind of check to the
shim to "do the right thing" and offer to use pkg-static to
upgrade the main pkg binary if the dynamically linked one is
broken.  Or maybe it should default to calling pkg-static instead
of pkg, which would prevent the problem in the first place.

Of course this assumes the user has /usr/sbin before /usr/local/sbin
on their path, but I suspect that is true in most cases

Regards,

Gary

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Help! two machines ran out of swap and corrupted their zpools!

[Gary Palmer]

On Mon, Nov 21, 2016 at 05:47:29PM +, Pete French wrote:
> So, I am off sick and my colleagues decided to load test our set of five
> servers excesively. All ran out of swap. So far so irritating, but whats has
> happened is that twoof them now will not boot, as it appears the ZFS pool
> they are booting from has become corrupted.
> 
> One starts to boot, then crases importing the root pool. The other doenst
> even get that far with gptzfsboot saying it can't find the pool to boot from!
> 
> Now I can recover these, but I am a bit worried, that it got like this at
> all, as I havent ever seen ZFS corrupt a pool like this. Anyone got any 
> insights,
> or suggstions as to how to stop it happening again ?
> 
> We are swapping to a separate partition, not to the pool by theway.

Silly question - have you checked that the swap partition does not
overlap your boot pool partition?  It could well be that the end of
the swap partition intrudes into the affected ZFS pool

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: sonewconn: pcb [...]: Listen queue overflow to human-readable form

[Gary Palmer]

On Thu, Dec 15, 2016 at 05:27:02PM +0200, Artem Viklenko wrote:
> 2016-12-15 14:28, Eugene Grosbein ??:
> > On 15.12.2016 19:23, Eugene M. Zheganin wrote:
> > 
> >> but at the time of investigation the socket is already closed and lsof
> >> cannot show me the owner. I wonder if the kernel can itself decode 
> >> this
> >> output and write it in the human-readable form ?
> > 
> > Until that's not implemented, you can monitor "netstat -Lan" output and
> > continuously save it for later analisys and/or draw graphs.
> > 
> 
> netstat -LanA -f inet ?

That's only IPv4 sockets (or sockets that are listening on both families
at the same time).  If you are dual stack with IPv6, you'd probably also
need to capture

netstat -LanA -f inet6

Regards,

Gary

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [ZFS] files in a weird situtation

[Gary Palmer]

On Sat, Dec 17, 2016 at 11:25:41PM +0100, David Marec wrote:
> On 17.12.2016 22:15, Brandon Allbery wrote:
> >
> > You have a directory entry pointing at a freed inode (or zfs equivalent).
> 
> ZFS may have mapped this inode  that points to nowhere. That makes sense.
> 
> In this case, what should be the best solution to clean this up ?
> 
> As I said, as far scrubbing the pool didn't show any error, it didn't 
> solve the issue.

Have you tried deleting the /lib directory, or at least renaming it to
/lib.bad (or something similar)?

You'll need to boot from a rescue disc or boot single user with /rescue/sh
as your shell, and then reinstall /lib from known good media (or 
"make installworld" in /usr/src)

That may leave problems in the ZFS metadata still, but it should (in theory)
let you continue using the system

Gary

P.S. I haven't tried any of this myself so be careful
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: usb 3.0 thumb drive speed limit

[Gary Palmer]

On Mon, Jan 02, 2017 at 11:27:49AM +0300, Marat N.Afanasyev wrote:
> I wonder is there a speed limit on usb 3.0? I've bought
> 
> ugen0.4:  at usbus0
> umass2 on uhub7
> umass2:  on usbus0
> da2 at umass-sim2 bus 2 scbus9 target 0 lun 0
> da2:  Removable Direct Access SPC-4 SCSI device
> da2: Serial Number AA010808161609220143
> da2: 40.000MB/s transfers
> da2: 59840MB (122552320 512 byte sectors)
> da2: quirks=0x2
> 
> that claims 'Up to 245 MBytes/sec read speed'

I don't think the speed reported by the SCSI layer (CAM) is correct
for USB, although it seems from an experiment here that if you 
plug a USB3 drive into a USB2 port it reports "40.000MB/s transfers"
and on a USB3 port it reports "400.000MB/s transfers".  SCSI doesn't
really have any direct mapping to the USB speeds so I suspect the
USB stack uses the closest value.  The tests I did were with 10.3.
Other releases may behave differently.

Check with usbconfig what the negotiated USB speed is (the "spd=" value
with the Mbps or Gbps value in brackets afterwards)

FULL = USB1
HIGH = USB2
SUPER = USB3

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Boot partition size

[Gary Palmer]

On Sun, Jan 29, 2017 at 03:15:19PM +1100, Aristedes Maniatis wrote:
> As recently as last October, the best official advice was to make a 64kB boot 
> partition.
> 
> https://wiki.freebsd.org/action/diff/RootOnZFS/GPTZFSBoot/Mirror?action=diff&rev1=16&rev2=17
> 
> 
> Now that turns out to be absolutely terrible advice and some people (like me) 
> have dozens of machines that will never be upgradable to FreeBSD 11 or 
> higher. It looks like there is no reasonable method of upgrade that doesn't 
> involve replacing every hard disk on every machine (that's hundred of disks) 
> with larger models. I use a zvol for swap, so I can't make swap smaller to 
> solve the problem.
> 
> I started with FreeBSD 4.1 and in 16 years... sigh...
> 
> The ashift pain some years ago was also caused by FreeBSD default 
> recommendations and settings not anticipating future needs quickly enough. 
> But this mess now is completely self-inflicted foot shooting.
> 
> 
> 1. Why is the recommendation now 128kB and not much much higher? When that 
> limit is broken in a couple of years, will there be another round of annoyed 
> users? Is someone concerned that ZFS users are running hard disks over under 
> 500Mb and need to save space? Surely the recommendation should be 512kB?
> 
> 2. Is there any possible short term future where ZFS volumes can be shrunk, 
> or will I be replacing every hard disk (or rebuilding the machine from 
> scratch)?


It is highly unlikely that ZFS volumes will be able to be reduced in size
even in the long term.  I believe that requires a piece of work that has
been rated as very difficult to do without violating layering policies 
inside the ZFS code.

The alternative is, assuming you have a pool with redundancy (e.g. mirror)
is to do a backup, drop one half of the mirror, create a new pool on the
now unused disk, zfs send | zfs receive, boot from the new pool and then
drop the old pool and add the disk to the mirror

It's a pain and a bit of a shuffle but it's possible.  I did it on my
server once when I found that FreeBSD 9 didn't detect the disks as 4k
and the alignment was all wrong.  I worked through the procedure in a
VM to validate it first, but found that in production I'd managed to 
hard code the boot pool name in /boot/loader.conf which meant that
it didn't reboot and use the bootfs flag on the pool, it just sat at
the "Cannot mount root" prompt.  Took me a while to find that 
loader.conf setting and kill it.

Regards,

Gary

> 
> 3. Is there any possibility of getting a gptzfsboot which is 64kB but missing 
> certain features I might not need? eg. a RAIDZ2 version that skips support 
> for RAIDZ3
> 
> 4. Will support be added to freebsd-update to warn users BEFORE they try to 
> upgrade and kill their system?
> 
> 
> 
> Please cc me, I'm not subscribed.
> 
> 
> Ari Maniatis
> 
> 
> -- 
> -->
> Aristedes Maniatis
> CEO, ish
> https://www.ish.com.au
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> 



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs snapshot_limit is not respected

[Gary Palmer]

On Thu, Feb 02, 2017 at 09:31:58PM -0500, Ultima wrote:
> I recently moved some data on a box with limited space. I decided I should
> limit the snapshots so that space would not become an issue. I just check
> back a week later to find out the box is hitting the borderline. Doing I
> quick check I realized that the snapshot_limit is not being respected.
> 
> # uname -a
> FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15 10:59:10
> EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/MYKERNEL
>  amd64
> 
> # zfs create zroot/bhyve/test
> # zfs set snapshot_limit=0 zroot/bhyve/test
> # zfs snapshot zroot/bhyve/test@1
> 
> 
> # zfs snapshot zroot/bhyve/test@2
> # zfs snapshot zroot/bhyve/test@3
> # zfs list -t snapshot | grep zroot/bhyve/test
> zroot/bhyve/test@1   0  -
>  88K  -
> zroot/bhyve/test@2   0  -
>  88K  -
> zroot/bhyve/test@3   0  -
>  88K  -
> # zfs get all zroot/bhyve/test | grep snapshot
> zroot/bhyve/test  usedbysnapshots   0  -
> zroot/bhyve/test  snapshot_limit0  local
> zroot/bhyve/test  snapshot_count3  local
> 
> Also wanted to verify 0 was not being mistaken for none.
> 
> # for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk
> '{print $1}'`; do zfs destroy $snapshot ; done
> 
> # zfs get all zroot/bhyve/test | grep snapshot
> zroot/bhyve/test  usedbysnapshots   0  -
> zroot/bhyve/test  snapshot_limit0  local
> zroot/bhyve/test  snapshot_count0  local
> 
> # zfs set snapshot_limit=1 zroot/bhyve/test
> # zfs snapshot zroot/bhyve/test@1
> # zfs snapshot zroot/bhyve/test@2
> # zfs snapshot zroot/bhyve/test@3
> # zfs get all zroot/bhyve/test | grep snapshot
> zroot/bhyve/test  usedbysnapshots   0  -
> zroot/bhyve/test  snapshot_limit1  local
> zroot/bhyve/test  snapshot_count3  local
> 
> 
> Also tested on head
> FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18
> 12:38:52 EST 2017
> root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG
>  amd64

Hi,

I suspect this line from the manpage is key:

The limit is not enforced if the user is allowed to change the limit

Regards,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs snapshot_limit is not respected

[Gary Palmer]

On Fri, Feb 03, 2017 at 10:27:48AM -0500, Ultima wrote:
> Hey Gary,
> 
> You are probably right. Do you know how to "lock" this property by chance?
> I'v read this exact line several times trying to understand the exact
> meaning. The "user is allowed to change the limit" I *think* is referring
> to the zfs allow command. The problem is that I checked the dataset and it
> is showing no permissions granted to a user. So I guess user in this case
> is also including the root user, but how does one lock the property from
> root? I keep going through the manpage looking for something I may have
> missed but keep coming up empty.

Hi,

I suspect you can't lock root out, but you could allow a different user
to create snapshots.  If you use that user to create snapshots, they
should be subject to the snapshot limit, assuming you don't let them
change that property.

Regards,

Gary

> Thanks for replying,
> Ultima
> 
> On Fri, Feb 3, 2017 at 7:42 AM, Gary Palmer  wrote:
> 
> > On Thu, Feb 02, 2017 at 09:31:58PM -0500, Ultima wrote:
> > > I recently moved some data on a box with limited space. I decided I
> > should
> > > limit the snapshots so that space would not become an issue. I just check
> > > back a week later to find out the box is hitting the borderline. Doing I
> > > quick check I realized that the snapshot_limit is not being respected.
> > >
> > > # uname -a
> > > FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15
> > 10:59:10
> > > EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/
> > MYKERNEL
> > >  amd64
> > >
> > > # zfs create zroot/bhyve/test
> > > # zfs set snapshot_limit=0 zroot/bhyve/test
> > > # zfs snapshot zroot/bhyve/test@1
> > >
> > >
> > > # zfs snapshot zroot/bhyve/test@2
> > > # zfs snapshot zroot/bhyve/test@3
> > > # zfs list -t snapshot | grep zroot/bhyve/test
> > > zroot/bhyve/test@1   0  -
> > >  88K  -
> > > zroot/bhyve/test@2   0  -
> > >  88K  -
> > > zroot/bhyve/test@3   0  -
> > >  88K  -
> > > # zfs get all zroot/bhyve/test | grep snapshot
> > > zroot/bhyve/test  usedbysnapshots   0  -
> > > zroot/bhyve/test  snapshot_limit0  local
> > > zroot/bhyve/test  snapshot_count3  local
> > >
> > > Also wanted to verify 0 was not being mistaken for none.
> > >
> > > # for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk
> > > '{print $1}'`; do zfs destroy $snapshot ; done
> > >
> > > # zfs get all zroot/bhyve/test | grep snapshot
> > > zroot/bhyve/test  usedbysnapshots   0  -
> > > zroot/bhyve/test  snapshot_limit0  local
> > > zroot/bhyve/test  snapshot_count0  local
> > >
> > > # zfs set snapshot_limit=1 zroot/bhyve/test
> > > # zfs snapshot zroot/bhyve/test@1
> > > # zfs snapshot zroot/bhyve/test@2
> > > # zfs snapshot zroot/bhyve/test@3
> > > # zfs get all zroot/bhyve/test | grep snapshot
> > > zroot/bhyve/test  usedbysnapshots   0  -
> > > zroot/bhyve/test  snapshot_limit1  local
> > > zroot/bhyve/test  snapshot_count3  local
> > >
> > >
> > > Also tested on head
> > > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18
> > > 12:38:52 EST 2017
> > > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG
> > >  amd64
> >
> > Hi,
> >
> > I suspect this line from the manpage is key:
> >
> > The limit is not enforced if the user is allowed to change the limit
> >
> > Regards,
> >
> > Gary
> >
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Jailed periodic daily scripts smashing CPU

[Gary Palmer]

On Fri, Feb 17, 2017 at 10:47:23AM -0600, Dustin Wenz wrote:
> If I needed to go down the road of spreading out the daily maintenance over a 
> longer period of time, I'd probably use your solution of building in a delay 
> based on the jail id, or possibly Guy Tabrar's extreme jitter example.
> 
> The pkg-backup job appears somewhat flawed, in my view. The xz compressor is 
> totally CPU bound for a moderate number of jails . Sure, running it at low 
> priority isn't as cache friendly, but it's certainly better then the host 
> becoming unresponsive. The other issue is that in most cases the package 
> archive doesn't change, and so running a daily backup without checking for 
> changes is wasteful. In my case, ZFS handles all the rolling backups that I 
> could ever need, so using pkg-backup for that purpose is redundant.
> 

Hi,

At least in my copy of the /usr/local/etc/periodic/daily/411.pkg-backup
script, there is an option to enable backing up the pkg db in the
jails from the host OS.  If you put daily_backup_pkgng_enable=NO
into the periodic.conf in the jails and daily_backup_pkg_jails=YES in
the host there should be no more than a single thread consuming CPU
doing the pkg backups as they're done sequentially rather than in
parallel.

In general I think a method of forcing a jail to start it's jobs
later based on JID (or some other metric as JID could get rather
large and sparse if you stop/start jails a lot) is a good idea that
should be looked at for inclusion in base

Regards,

Gary


> 
> > On Feb 16, 2017, at 5:44 PM, Walter Cramer  wrote:
> > 
> > Adding something like:
> > 
> > 'sleep $(( $(sysctl -n security.jail.param.jid) * 15 )) && '
> > 
> > in front of more resource-intensive commands in /etc/crontab can reliably 
> > spread out the load from a larger number of jails.
> > 
> > (But if you start and stop jails frequently enough to spread out the 
> > current list of jail id numbers, this method degrades.)
> > 
> > Low priority for 'periodic daily' jobs might not help much, due to disk 
> > saturation, CPU cache thrashing, etc.
> > -Walter
> > 
> > On Thu, 16 Feb 2017, Dustin Wenz wrote:
> > 
> >> The biggest offender that I see is 
> >> /usr/local/etc/periodic/daily/411.pkg-backup
> >> 
> >> During the high CPU event, my process list contains hundreds of these:
> >> 
> >>83811  -  RJ 0:03.42 xz -c
> >>83816  -  S  0:00.02 /usr/local/sbin/pkg shell .dump
> >>83818  -  SJ 0:00.02 /usr/local/sbin/pkg shell .dump
> >>83820  -  SJ 0:00.03 /usr/local/sbin/pkg shell .dump
> >>83824  -  RJ 0:03.41 xz -c
> >>83831  -  RJ 0:03.58 xz -c
> >> 
> >> I could probably get away with disabling that in my case.
> >> 
> >> However, instead of jitter, I think I'd prefer if the periodic jobs ran at 
> >> a lower priority than my user processes. Either through nice, or idprio. I 
> >> want them to get done as fast as possible, but I don't want them to affect 
> >> my application.
> >> 
> >>- .Dustin
> >> 
> >> 
> >>> On Feb 16, 2017, at 4:20 PM, Alan Somers  wrote:
> >>> 
> >>> Is the problem caused by newsyslog or by the periodic scripts?
> >>> Newsyslog normally runs from cron directly, not through periodic.  In
> >>> any case, here are a few suggestions:
> >>> 1) Turn on cron jitter, as you suggested.  Even if 60s isn't enough,
> >>> it can't hurt.
> >>> 2) Try gz compression instead of xz compression to see if it's faster
> >>> 3) Manually edit the jails' /etc/crontab files to hardcode some
> >>> variability into their newsyslog and/or periodic run times
> >>> 4) If the problem is actually being caused by periodic instead of
> >>> newsyslog, tell me which script it is and how much jitter you want.  I
> >>> am coincidentally changing how periodic manages jitter right now.
> >>> 
> >>> -Alan
> >>> 
> >>> On Thu, Feb 16, 2017 at 2:47 PM, Dustin Wenz  
> >>> wrote:
>  I have a number of servers with roughly 60 jails running on each of 
>  them. On these hosts, I've had to disable the periodic security scans 
>  due to overly high disk load when they run (which is redundant in jails 
>  anyway). However, I still have an issue at 3:01am where the CPU is 
>  consumed by dozens of 'xz -c' processes. This is apparently daily log 
>  rolling, which I can't exactly disable.
>  
>  The effect is that our processing applications experience a major 
>  slowdown for about 15 seconds every morning, which is just enough that 
>  it's starting to get people's attention.
>  
>  What is the best way to mitigate this? I'm aware of the cron jitter 
>  feature, but I'm not sure of the 60-second jitter maximum would be 
>  enough (especially if I wanted to start utilizing more jails).
>  
>    - .Dustin
>  ___
>  freebsd-stable@freebsd.org mailing list
>  https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>  To unsubscri

Re: 11.0 and tw_cli fail

[Gary Palmer]

% file tw_cli
tw_cli: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically 
linked, for FreeBSD 5.4, stripped

Try COMPAT_FREEBSD5

Regards,

Gary

On Tue, May 30, 2017 at 03:55:03PM -0600, CBL wrote:
> Yeah, I have a custom kernel with COMPAT_FREEBSD10 already in it and no
> joy. However, I checked GENERIC and it works. Then I tried COMPAT_FREEBSD9
> too and no go.. guess I'll keep playing.
> 
> On Tue, May 30, 2017 at 3:33 PM, Alan Somers  wrote:
> 
> > Was the tw_cli utility built for FreeBSD 10?  If so, you need to
> > either rebuilt it, or build your kernel with COMPAT_FREEBSD10 in the
> > config file.  It's in the GENERIC config file, so you'll have it if
> > you don't use a custom kernel.
> > -Alan
> >
> > On Tue, May 30, 2017 at 3:19 PM, CBL  wrote:
> > > Updated a box to 11.0 with a legacy 3ware 9690SA using the twe driver.
> > > Now the tw_cli utility is now throwing "Bad system call (core dumped).
> > >
> > > Anybody have any suggestions?  Was working fine on 10.3.
> > >
> > > Thanks
> > > ___
> > > freebsd-stable@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org
> > "
> >
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"