Re: When did pkg(8) drop support for 12-stable?

[Paul Mather]

> On Feb 23, 2021, at 9:02 PM, Chris  wrote:
> 
> On 2021-02-23 17:07, Brian W. wrote:
>> 12-stable is not what you're running if you got that error.
> # uname -apKU
> FreeBSD fbsd12dev 12.1-STABLE FreeBSD 12.1-STABLE r363918 GENERIC  amd64 
> amd64 1201522 1201522
> Looks pretty STABLE to me.


It may be -STABLE but it apparently hasn't been updated in a while.  You're 
running FreeBSD version 1201522, which is some flavour of 12.1.  As Warner 
pointed out, FreeBSD 12.1 has reached EOL, and is no longer officially 
supported by ports.

By way of comparison, here is a 12-STABLE system I updated yesterday:

gromit ~% uname -a
FreeBSD gromit.dlib.vt.edu 12.2-STABLE FreeBSD 12.2-STABLE 
stable/12-n232755-dfb372f5d38c GENERIC  amd64
gromit ~% uname -U
1202505


If you want to continue to use ports on that system I suggest you do a source 
upgrade to at least 12.2-STABLE (or else install a 12.2-STABLE snapshot).

Cheers,

Paul.


> 
> --Chris
>> Run freebsd-update with appropriate args to get to a later release is the
>> easiest option.
>> Brian
>> On Tue, Feb 23, 2021, 5:04 PM Warner Losh  wrote:
>>> On Tue, Feb 23, 2021, 4:51 PM Chris  wrote:
>>> > Given this is a pkg(8) error, I brought it up on ports@
>>> > but it was suggested I (also?) bring it up here on stable@
>>> >
>>> > OK awhile back I installed a copy of 12 stable from the
>>> > usb stick image. I tweaked it to my wishes then got called
>>> > away and haven't been able to get back to it until the other
>>> > day. This is still a fresh install which has a populated /usr/src.
>>> > So I
>>> > svnlite co svn://svn.freebsd.org/ports/head /usr/ports
>>> > followed by a
>>> > cd /usr/ports/ports-mgmt/pkg/ && make install clean
>>> > which returns
>>> > make
>>> > /!\ ERROR: /!\
>>> >
>>> > Ports Collection support for your FreeBSD version has ended, and no ports
>>> > are
>>> > guaranteed to build on this system. Please upgrade to a supported
>>> release.
>>> >
>>> > No support will be provided if you silence this message by defining
>>> > ALLOW_UNSUPPORTED_SYSTEM.
>>> >
>>> > *** Error code 1
>>> >
>>> > Stop.
>>> > Err what? Ok while I think this was from stable 12.1, it's still still
>>> 12,
>>> > and it's on stable. So what gives?
>>> >
>>> 12.1 has reached EOL now that 12.2 has been out a while.
>>> Warner
>>> Thanks in advance for any enlightenment.
>>> >
>>> > --Chris
> ___
> 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"

Re: 13-stable default boot options problem

[Paul Mather]

On Feb 7, 2021, at 4:33 AM, Alex V. Petrov  wrote:

> I still don't resolved my problem.
> How change default Cons=Serial  to Cons=Video?
> 
> Screenshot: https://imgur.com/SNXUrZH.png
> 
> My system:
> FreeBSD 13.0-STABLE #79 stable/13-n244485-6136a10e355: Sat Feb  6
> 22:05:30 +07 2021 amd64


It's not clear to me what problem you are having or attempting to solve.

The "5" option in the boot menu lets you cycle through the different console 
options (all four in total).  In my case, it has no effect because I set 
"comconsole" and "boot_multicons" explicitly in /boot/loader.conf (since a long 
time ago), and no matter what I select via the console loader, it is overridden 
by what is loaded from /boot/loader.conf during loading and booting the kernel.

Do you similarly have something in /boot/loader.conf that is overriding the 
console setting?

Cheers,

Paul.

___
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: FreeBSD disable any automated outgoing connections

[Paul Mather]

On Nov 2, 2020, at 2:15 AM, free...@tango.lu wrote:

> Hello,
> 
> I have these connections 4-5 am in the morning going to bytemark, cloudfare 
> and other cloud providers:
> 
>  - Connections  2.0 - Payload 5.0k -
> Ports| Sources   | Destinations  | 
> Services   | Protocols | States|
> 443   100.0% | 192.168.1.5#1100.0% | 104.16.45.99#2  50.0% | 
> -   100.0% | 6  100.0% | SHR100.0% |
>  |   | 104.16.44.99#3  50.0% |
> |   |   |
> 


This is likely to be the /etc/periodic/daily/480.leapfile-ntpd daily periodic 
job.  It checks for an updated NTP leapfile from $ntp_leapfile_sources.  This 
periodic job defaults to "YES" in /etc/defaults/rc.conf and the default for  
$ntp_leapfile_sources is 
"https://www.ietf.org/timezones/data/leap-seconds.list;.  A current DNS lookup 
of www.ietf.org shows it uses the Cloudflare CDN.


> This machine is an IDS it should never make outgoing connections ever. How to 
> disable this?


You might set "daily_ntpd_leapfile_enable=NO" in your local periodic.conf file 
to override the default.

Alternatively, if you have a strict rule that the machine should not initiate 
any outbound connections, you could add a firewall rule dropping any such 
traffic originating there (i.e., not belonging to an established connection) 
going out on the external ("WAN") interface.

Cheers,

Paul.

___
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: swap space issues

[Paul Mather]

On Jun 26, 2020, at 6:58 AM, Stefan Eßer  wrote:

> Am 26.06.20 um 12:23 schrieb Peter Jeremy:
>> On 2020-Jun-25 11:30:31 -0700, Donald Wilde  wrote:
>>> Here's 'pstat -s' on the i3 (which registers as cpu HAMMER):
>>> 
>>> Device  1K-blocks UsedAvail Capacity
>>> /dev/ada0s1b 335544320 33554432 0%
>>> /dev/ada0s1d 335544320 33554432 0%
>>> Total671088640 67108864 0%
>> 
>> I strongly suggest you don't have more than one swap device on spinning
>> rust - the VM system will stripe I/O across the available devices and
>> that will give particularly poor results when it has to seek between the
>> partitions.
> 
[[...]]
>> As a further piece of arcana, vm.pageout_oom_seq is a count that controls
>> the number of passes before the pageout daemon gives up and starts killing
>> processes when it can't free up enough RAM.  "out of swap space" messages
>> generally mean that this number is too low, rather than there being a
>> shortage of swap - particularly if your swap device is rather slow.
> 
> I'm not sure that this specific sysctl is documented in such a way
> that it is easy to find by people suffering from out-of-memory kills.
> 
> Perhaps it could be mentioned as a parameter that may need tuning in
> the OOM message?
> 
> And while it does not come up that often in the mail list, it might
> be better for many kinds of application if the default was increased
> (a longer wait for resources might be more acceptable than the loss
> of all results of a long running computation).


The OOM issue is more pressing on platforms like FreeBSD/arm that tend to have 
low RAM and slow writable storage such as SD card.  There have been several 
threads on the issues this creates (e.g., 
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=228789+0+archive/2018/freebsd-arm/20180819.freebsd-arm
 
)
 that have led to some insight into how to tune the OOM killer.  One thing that 
becomes clear is that the "Out of swap space" error message is misleading as 
often it really means "Couldn't obtain RAM in a timely fashion."  On hardware 
such as the Raspberry Pi, it's often the case that the system has enough swap 
space: it's just that it can't write to swap on SD card before the default 
vm.pageout_oom_seq passes are exhausted and so the OOM killer starts reaping 
active processes (like the clang trying to build clang:), and all sorts of 
things start to break. :-)

Cheers,

Paul.
___
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: swap space issues

[Paul Mather]

On Jun 24, 2020, at 11:34 PM, Donald Wilde  wrote:

> Meant that I upgraded from 12.1-RELEASE to 12-STABLE. When I
> configured the -RELEASE install, I manually messed with the MBR disk
> partitions. This is nominally a half-TB HDD which showed up as a total
> of 446 G available (IIRC, gpart should show it's actual size). I did
> auto partitioning, looked at the sizes, and manually set my partitions
> to give me 40G of swap instead of the auto-generated size of 4G.
> 
> This is an old Dell i3 laptop. It's really generic, picked
> specifically as something I could use for Ubuntu or FreeBSD. Dell
> SERVICE TAG is 5K8W162, but it's a generic i3 with 4G of RAM.


I think I've missed in this thread where you said which FreeBSD arch you are 
running: is it FreeBSD/amd64 or FreeBSD/i386?  (With an "old" machine, 4 GB 
RAM, and an install still using MBR, it could potentially be FreeBSD/i386.)

If it is FreeBSD/i386, there is a precedent for it having problems with 
configuring large amounts of swap.  However, it is usually related to having 
relatively little RAM, too (large amounts of swap space means the OS needs to 
use more RAM to keep track of it).

Cheers,

Paul.

___
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: Issue with gpart "Device Busy"

[Paul Mather]

On Apr 15, 2020, at 2:35 PM, i...@dijix.com wrote:

I have an issue with gpart, it will not let me delete partition ada0p2  
responding with “Device Busy”
The man page gpart(8) says this may be shown if a partition exists but I  
cannot seem to delete partition 2 in my case via gpart delete or gpart  
destroy


This is a used disk but new to the machine, I can modify the partition  
type and create partitions before and after partition 2 but I cannot  
delete it.


Here’s what I have tried so far:


root@beastie:~ # gpart show
=>34  1250263661  ada0  GPT  (596G)
   34  409606- free -  (200M)
   409640  1249591904 2  freebsd-ufs  (596G)
1250001544  262151- free -  (128M)

=>   40  976773088  ada1  GPT  (466G)
  40   1024 1  freebsd-boot  (512K)
1064984- free -  (492K)
20484194304 2  freebsd-swap  (2.0G)
 4196352  972576768 3  freebsd-zfs  (464G)
976773120  8- free -  (4.0K)

root@beastie:~ # gpart delete -i2 ada0
gpart: Device busy

root@beastie:~ # gpart add -t freebsd-boot ada0
ada0p1 added

root@beastie:~ # gpart show
=>34  1250263661  ada0  GPT  (596G)
   34  409606 1  freebsd-boot  (200M)
   409640  1249591904 2  freebsd-ufs  (596G)
1250001544  262151- free -  (128M)

=>   40  976773088  ada1  GPT  (466G)
  40   1024 1  freebsd-boot  (512K)
1064984- free -  (492K)
20484194304 2  freebsd-swap  (2.0G)
 4196352  972576768 3  freebsd-zfs  (464G)
976773120  8- free -  (4.0K)

root@beastie:~ # gpart delete -i2 ada0
gpart: Device busy

root@beastie:~ # gpart delete -i1 ada0
ada0p1 deleted

root@beastie:~ # gpart show
=>34  1250263661  ada0  GPT  (596G)
   34  409606- free -  (200M)
   409640  1249591904 2  freebsd-ufs  (596G)
1250001544  262151- free -  (128M)

=>   40  976773088  ada1  GPT  (466G)
  40   1024 1  freebsd-boot  (512K)
1064984- free -  (492K)
20484194304 2  freebsd-swap  (2.0G)
 4196352  972576768 3  freebsd-zfs  (464G)
976773120  8- free -  (4.0K)

root@beastie:~ # gpart destroy -F ada0
gpart: Device busy

root@beastie:~ # gpart modify -i2 -t freebsd-boot ada0
ada0p2 modified
root@beastie:~ # gpart show
=>34  1250263661  ada0  GPT  (596G)
   34  409606- free -  (200M)
   409640  1249591904 2  freebsd-boot  (596G)
1250001544  262151- free -  (128M)

=>   40  976773088  ada1  GPT  (466G)
  40   1024 1  freebsd-boot  (512K)
1064984- free -  (492K)
20484194304 2  freebsd-swap  (2.0G)
 4196352  972576768 3  freebsd-zfs  (464G)
976773120  8- free -  (4.0K)


I’m not sure where to go from here, I’m tempted to pull the drive and  
reformat elsewhere


I have all tried dd’ing the disk as root but dd /dev/ada0 errors with  
unauthorised.


Am I missing something obvious?



I don't know whether it can be considered obvious, but, in my experience,  
this sort of inability to delete a partition can happen because another  
GEOM layer has that partition open under some other guise.  Typical  
culprits are the various "label" classes and other GEOM classes that  
"autodetect" things belonging to them.


A case in point that happened to me recently: I was trying to install on  
what I thought were two empty drives.  Unfortunately, when it came to  
actually partitioning ada0 and ada1 it failed.  It turned out that the  
drives were previously used in a "fake RAID" setup and GEOM_RAID was  
detecting an old RAID volume on the drives because the RAID metadata/label  
was being detected.  This meant I couldn't directly access the underlying  
devices, ada0 and ada1.


My solution was to use graid to destroy the errant RAID volume, after which  
I was able to write/partition ada0 and ada1 directly.


Sometimes it is sufficient to disable autodetection of various label  
classes in /boot/loader.conf to be able to access the lower devices.


Cheers,

Paul.

___
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: Running FreeBSD on M.2 SSD

[Paul Mather]

On Feb 25, 2020, at 9:03 AM, Daniel Kalchev  wrote:


> FreeBSD does not technically have driver for different disks. People asked 
> whether it is an NVMe device or SATA device, because those interfaces have 
> different drivers.
> 
> But for FreeBSD, an mechanical SATA, hybrid SATA or SSD SATA will use exactly 
> the same SATA driver. It depends on the chipset.
> 
> It is possible however, that the timing between the drive and the SATA 
> controller might be different and that is causing the problem.


In a similar vein, I had an old MacBook Pro 2011 model.  Its SATA chipset would 
negotiate SATA III speeds but any disk I/O at that speed would soon lead to 
widespread data corruption.  SATA II drives and slower would be fine: no 
corruption.

The funny thing was that this wasn't an issue when I used earlier versions of 
macOS: the problem only seemed to manifest when I "upgraded" to Mojave (IIRC).  
I surmised that maybe at that time period, whatever quirks or workarounds in 
the earlier OS versions no longer applied, and so whatever had caused the SATA 
III replacement drive to work (e.g., by force-negotiating at the slower speed) 
no longer did. :-(

So, maybe a quirk/workaround that is in Linux and Windows but not in FreeBSD 
for you hardware *might* be a possibility?

Cheers,

Paul.

___
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: bhyve memory leak in stable/11

[Paul Mather]

On Nov 18, 2019, at 8:06 AM, Eugene Grosbein  wrote:


18.11.2019 19:03, Eugene Grosbein wrote:


Please point me to right direction for debugging this.


Is it normal that over 1/3rd of 360G total physical RAM is in "Laundry"  
category in addition to 173G Wired?


last pid: 20372;  load averages:  8.04,  7.73,   
7.84   up 2+05:55:29  16:04:02

130 processes: 3 running, 126 sleeping, 1 zombie
CPU:  1.1% user,  0.0% nice, 13.2% system,  0.1% interrupt, 85.7% idle
Mem: 42G Active, 8325M Inact, 112G Laundry, 173G Wired, 7809M Free
ARC: 131G Total, 28G MFU, 90G MRU, 11M Anon, 2442M Header, 10G Other
 107G Compressed, 363G Uncompressed, 3.41:1 Ratio
Swap: 64G Total, 16G Used, 48G Free, 24% Inuse

  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAND
78042 root 34  200 54328M 52867M kqread  7  81.4H 210.63%  
bhyve: sappdev (bhyve)
59085 root 20  200 31512M 25256M kqread  6 490:16  16.25%  
bhyve: sdc01 (bhyve)
59568 root 28  200 28549M 24270M kqread  6 143:32   1.22%  
bhyve: sfile01 (bhyve)
60011 root 20  200 30262M 23697M kqread 27 121:22   1.08%  
bhyve: skms01 (bhyve)
63676 root 34  200 16418M 12799M kqread  3 113:06  19.92%  
bhyve: solap (bhyve)
26819 root 26  200 12321M 10472M kqread 28 151:43  10.12%  
bhyve: srdapp01 (bhyve)
63662 root 34  200  8226M  6969M kqread  4 114:52  20.36%  
bhyve: ssql01 (bhyve)



I wondered the same back in late March this year:  
https://www.mail-archive.com/freebsd-stable@freebsd.org/msg137556.html


I have a 12-STABLE system that has 16 GB RAM yet regularly shows hundred of  
megabytes of "Laundry."  To be fair, it's also showing a good chunk of free  
memory, so maybe the philosophy is "why bother to do ANYTHING unless you  
absolutely have to?"  (There's also a lower amount of "Inactive" memory,  
but still amounting to a couple of hundred megabytes.)


My concern is that when I do need to grab a lot of free memory in a hurry  
(like when I do a Poudriere bulk run, or when I use the GitLab instance  
that runs in a jail on the machine), then there is a mad scramble to obtain  
memory.  It seems increasingly that "idle" processes get pushed out to swap  
at these times.  Oftentimes, when doing a Poudriere run, this means the  
GitLab processes get swapped out, which means when I next access GitLab  
there's a long latency whilst it gets paged back in to memory.


Given there's normally a lot of idle CPU time on this system, why doesn't  
the laundry ever seem to get done?  Is it just a matter that it is being  
done, but, also, more laundry is being created at an equally fast rate by  
something else running on the system?  (Is there a way of finding out what  
is generating laundry?)  Or, does laundry processing (and other memory  
reclamation) stop when the system believes there is "enough" free memory to  
warrant not doing any more reclamation work?  (If so, how much is "enough",  
and is it possible to alter what the system considers to be "enough?")


Cheers,

Paul.

___
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 with 32-bit, non-x86 kernel

[Paul Mather]

On Oct 4, 2019, at 4:05 PM, Andriy Gapon  wrote:

> Does anyone use ZFS with a 32-bit kernel, that is also not i386 ?
> If you do, could you please let me know?  Along with uname -rmp output.
> Thank you!


I am using a Root-on-ZFS setup on a FreeBSD/arm 12-STABLE Raspberry Pi 2 system 
(as well as on arm64 on a Raspberry Pi 3):

# uname -rmp
12.1-STABLE arm armv7

It has two ZFS pools, one of which I use as a destination for various local 
backups:

# zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAGCAP  DEDUP  HEALTH  
ALTROOT
data  3.62T   778G  2.86T- - 0%20%  1.00x  ONLINE  -
sys   7.50G   460M  7.05G- - 5% 5%  1.00x  ONLINE  -


I have vfs.zfs.arc_max="384M" set in /boot/loader.conf.  The Pi 2 has 1 GB RAM.

The system has worked very well so far---it seems more stable than the 
UFS-based system it started out life as.  I converted it using the writeup that 
Bernd Walter posted to freebsd-arm back in late February, 2019: 
https://lists.freebsd.org/pipermail/freebsd-arm/2019-February/019455.html

Scrubbing the "data" pool takes quite a while, though.  The last one (completed 
on 2019-09-23) took 12 days 18:26:31. :-)

Cheers,

Paul.
___
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: haproxy syslog comptible

[Paul Mather]

On Jun 24, 2019, at 10:42 AM, Slawa Olhovchenkov  wrote:


On Mon, Jun 24, 2019 at 10:35:03AM -0400, Paul Mather wrote:


On Jun 24, 2019, at 10:17 AM, Slawa Olhovchenkov  wrote:


I am use haproxy logged to syslog and have log lines like this:

Jun 24 17:04:25 ha01 haproxy[32508]: 193.34.87.146:57625
[24/Jun/2019:17:04:23.277] balancer~ default-pool/main 0/0/0/-1/2012 504
194 - - sH-- 888/888/4/4/0 0/0 "POST /vs HTTP/1.1"

Is this posible to learn syslogd to use mileseconds timestamps?
___
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"



Run syslogd with "-O syslog" to get timestamps logged with microsecond
precision (as well as time zones).  You can add that to your
"syslogd_flags" setting in /etc/rc.conf.  (See man syslogd for details.)

Note that the format of syslog entries changes with "-O syslog".  You get
logs like this:

<38>1 2019-04-12T10:43:56.525458-04:00 x.x.net sshd 1253 - -
Received signal 15; terminating.
<38>1 2019-04-12T10:48:05.058693-04:00 x.x.net sshd 1238 - -  
Server

listening on :: port 22.


(Note that the precision also depends upon the client application logging
to syslog.)


I mean you talk about different syslogd, not from FreeBSD:

syslogd: illegal option -- O
usage: syslogd [-468ACcdFknosTuv] [-a allowed_peer]
   [-b bind_address] [-f config_file]
   [-l [mode:]path] [-m mark_interval]
   [-P pid_file] [-p log_socket]



I guess this works only on FreeBSD 12 and later, then.  What version are  
you running?


Cheers,

Paul.
___
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: haproxy syslog comptible

[Paul Mather]

On Jun 24, 2019, at 10:17 AM, Slawa Olhovchenkov  wrote:


I am use haproxy logged to syslog and have log lines like this:

Jun 24 17:04:25 ha01 haproxy[32508]: 193.34.87.146:57625  
[24/Jun/2019:17:04:23.277] balancer~ default-pool/main 0/0/0/-1/2012 504  
194 - - sH-- 888/888/4/4/0 0/0 "POST /vs HTTP/1.1"


Is this posible to learn syslogd to use mileseconds timestamps?
___
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"



Run syslogd with "-O syslog" to get timestamps logged with microsecond  
precision (as well as time zones).  You can add that to your  
"syslogd_flags" setting in /etc/rc.conf.  (See man syslogd for details.)


Note that the format of syslog entries changes with "-O syslog".  You get  
logs like this:


<38>1 2019-04-12T10:43:56.525458-04:00 x.x.net sshd 1253 - -  
Received signal 15; terminating.
<38>1 2019-04-12T10:48:05.058693-04:00 x.x.net sshd 1238 - - Server  
listening on :: port 22.



(Note that the precision also depends upon the client application logging  
to syslog.)


Cheers,

Paul.
___
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"

em0 82579LM loses link under load

[Paul Mather]

I'm running a FreeBSD/amd64 12-STABLE r348161 GENERIC kernel.  Yesterday,  
when doing bulk data transfer from the system to offsite I noticed that the  
system would drop off the network.  The em0 NIC would regularly report this  
to the console:


em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
em0: TX(0) desc avail = 1024, pidx = 0
[[etc.]]


An "ifconfig em0" would show "no carrier" and ifconfig down/up would not  
bring the system back onto the network.  To do that a reboot was necessary.


(Speeds weren't terribly high either, load-wise, topping out at ~25  
MBytes/s on a gigabit link.)


This issue appears to have been reported as a regression in 12.0-RELEASE  
(e.g., https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234766).  A  
comment in another bug report concerning em performance  
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235031#c22) mentions  
Errata Note updates being in the works to address em regressions post-iflib  
restructuring of the driver.


Does anyone know whether this issue is fixed in em, at least for "older"  
devices like the 82579LM??  This used to be rock solid and fast for me  
under FreeBSD 11.  For now, I've adopted the route of the bug reporters and  
am using the net/intel-em-kmod driver from ports.  I can't afford to have  
this box drop off the network due to "load" and so stability is paramount.


Cheers,

Paul.
___
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: trying to expand a zvol-backed bhyve guest which is UFS

[Paul Mather]

On May 20, 2019, at 5:09 AM, tech-lists  wrote:


On Sun, May 19, 2019 at 10:17:35PM -0500, Adam wrote:

On Sun, May 19, 2019 at 9:47 PM tech-lists  wrote:


Thanks very much to you both, all sorted now. I didn't realise there was
a 2TB limit for MBR either. Can I shrink the 4TB to 2TB on the zfs side
without scrambling the ufs on the guest?


You can snapshot the zvol to be safe, but you should be able to shrink it
to the existing partition size.  If it's a sparse zvol, it may not may  
that

much difference.


The zvol has about 515GB data. Hopefully zfs is smart enough to shrink
to the MBR boundary.



A ZVOL is just a container.  ZFS has no implicit knowledge of what you are  
using it for or whether it has any particular partition table inside it.   
It's your responsibility to size the ZVOL appropriately.  (TL;DR: ZVOLs  
have no concept of an "MBR boundary.")


Cheers,

Paul.

___
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: trying to expand a zvol-backed bhyve guest which is UFS

[Paul Mather]

On May 19, 2019, at 9:46 PM, tech-lists  wrote:


Hi,

context is 12-stable, zfs, bhyve

I have a zvol-backed bhyve guest. Its zvol size was initially 512GB
It needed to be expanded to 4TB. That worked fine.

The problem is the freebsd guest is UFS and I can't seem to make it see
the new size. But zfs list -o size on the host shows that as far as zfs is
concerned, it's 4TB

On the guest, I've tried running growfs / but it says requested size is
the same as the size it already is (508GB)

gpart show on the guest has the following

# gpart show
=>63  4294967232  vtbd0  MBR  (4.0T)
 63   1 - free -  (512B)
 64  4294967216  1  freebsd  [active]  (2.0T)
4294967280  15 - free -  (7.5K)

=> 0  4294967216  vtbd0s1  BSD  (2.0T)
  0  10653532161  freebsd-ufs (508G)
 1065353216 83885442  freebsd-swap  (4.0G)
 1073741760  3221225456   - free -  (1.5T)

I'm not understanding the double output, or why growfs hasn't worked on
the guest ufs. Can anyone help please?



Given the above, the freebsd-ufs partition can't grow because there is a  
freebsd-swap partition between it and the free space you've added at the  
end of the volume.


You'd need to delete the swap partition (or otherwise move it to the end of  
the partition on the volume) before you could successfully growfs the  
freebsd-ufs partition.


Cheers,

Paul.

___
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...

[Paul Mather]

On May 8, 2019, at 9:59 AM, Michelle Sullivan  wrote:


Paul Mather wrote:
due to lack of space.  Interestingly have had another drive die in the  
array - and it doesn't just have one or two sectors down it has a *lot*  
- which was not noticed by the original machine - I moved the drive to  
a byte copier which is where it's reporting 100's of sectors damaged...  
could this be compounded by zfs/mfi driver/hba not picking up errors  
like it should?



Did you have regular pool scrubs enabled?  It would have picked up  
silent data corruption like this.  It does for me.
Yes, every month (once a month because, (1) the data doesn't change much  
(new data is added, old it not touched), and (2) because to complete it  
took 2 weeks.)



Do you also run sysutils/smartmontools to monitor S.M.A.R.T. attributes?   
Although imperfect, it can sometimes signal trouble brewing with a drive  
(e.g., increasing Reallocated_Sector_Ct and Current_Pending_Sector counts)  
that can lead to proactive remediation before catastrophe strikes.


Unless you have been gathering periodic drive metrics, you have no way of  
knowing whether these hundreds of bad sectors have happened suddenly or  
slowly over a period of time.


Cheers,

Paul.
___
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...

[Paul Mather]

On May 7, 2019, at 8:25 PM, Michelle Sullivan  wrote:


Paul Mather wrote:

On May 7, 2019, at 1:02 AM, Michelle Sullivan  wrote:

[[...]]




Umm.. well I install by memory stick images and I had a 10.2 and an  
11.0 both of which had root on zfs as the default.. I had to manually  
change them.  I haven’t looked at anything later... so did something  
change?  Am I in cloud cookoo land?



I don't know about that, but you may well be misremembering.  I just  
pulled down the 10.2 and 11.0 installers from  
http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases and in  
both cases the choices listed in the "Partitioning" step are the same as  
in the current 12.0 installer: "Auto (UFS)  Guided Disk Setup" is listed  
first and selected by default.  "Auto (ZFS) Guided Root-on-ZFS" is  
listed last (you have to skip past other options such as manually  
partitioning by hand to select it).


I'm confident in saying that ZFS is (or was) not the default  
partitioning option in either 10.2 or 11.0 as officially released by  
FreeBSD.


Did you use a custom installer you made yourself when installing 10.2 or  
11.0?


it was an emergency USB stick.. so downloaded straight from the website.

My process is boot, select "manual" (so I can set single partition and a  
swap partition as historically it's done other things) select the whole  
disk and create partition - this is where I saw it... 'freebsd-zfs' as  
the default. Second 'create' defaults to 'freebsd-swap' which is always  
correct.  Interestingly the -CURRENT installer just says, "freebsd" and  
not either -ufs or -zfs ... what ever that defaults to I don't know.



I still fail to see from where you are getting the ZFS default idea.  Using  
the 10.2 installer, for example, when you select "Manual" partitioning, and  
click through the defaults, the "Type" you are offered when creating the  
first file system is "freebsd-ufs".  If you want to edit that, the help  
text says "Filesystem type (e.g. freebsd-ufs, freebsd-zfs, freebsd-swap)"  
(i.e., freebsd-ufs is listed preferentially to freebsd-zfs).


That is all aside from the fact that by choosing to skip past the default  
"Auto (UFS)  Guided Disk Setup" and choose "Manual  Manual Disk Setup  
(experts)" you are choosing an option that assumes you are an "expert" and  
thus are knowledgeable and responsible for the choices you make, whatever  
the subsequent menus may offer.


Again, I suggest there's no basis for the allegation that it's bad that  
FreeBSD is defaulting to ZFS because that is NOT what it's doing (and I'm  
unaware of any plans for 13 to do so).



I don't see how any of this leads to the conclusion that ZFS is  
"dangerous" to use as a file system.


For me 'dangerous' threshold is when it comes to 'all or nothing'. UFS -  
even when trashed (and I might add I've never had it completely trashed  
on a production image) there are tools to recover what is left of the  
data.  There are no such tools for zfs (barring the one I'm about to test  
- which will be interesting to see if it works... but even then,  
installing windows to recover freebsd :D )


You're saying that ZFS is dangerous because it has no tools for  
catastrophic data recovery... other than the one you are in the process of  
trying to use, and the ones that others on this thread have suggested to  
you. :-\


I'm having a hard time grappling with this logic.




What I believe is dangerous is relying on a post-mortem crash data  
recovery methodology as a substitute for a backup strategy for data  
that, in hindsight, is considered important enough to keep. No matter  
how resilient ZFS or UFS may be, they are no substitute for backups when  
it comes to data you care about.  (File system resiliency will not  
protect you, e.g., from Ransomware or other malicious or accidental acts  
of data destruction.)


True, but nothing is perfect, even  backups (how many times have we seen  
or heard of stories when Backups didn't actually work - and the problem  
was only identified when trying to recover from a problem?)


This is the nature of disaster recovery and continuity planning.  The  
solutions adopted are individualistic and are commensurate with the  
anticipated risk/loss.  I agree that backups are themselves subject to risk  
that must be managed.  Yet I don't consider backups "dangerous".


I don't know what the outcome of your risk assessment was and what you  
determined to be your RPO and RTO for disaster recovery so I can't comment  
whether it was realistic or not.  Whatever you chose was based on your  
situation, not mine, and it is a choice you have to live with.  (Bear in  
mind that "not to decide is to decide.")



My situation has been made worse by the fact I was reorganising  
everything when it went down - so my backups (of the impo

Re: ZFS...

[Paul Mather]

On May 7, 2019, at 1:02 AM, Michelle Sullivan  wrote:


On 07 May 2019, at 10:53, Paul Mather  wrote:

On May 6, 2019, at 10:14 AM, Michelle Sullivan   
wrote:


My issue here (and not really what the blog is about) FreeBSD is  
defaulting to it.


You've said this at least twice now in this thread so I'm assuming  
you're asserting it to be true.


As of FreeBSD 12.0-RELEASE (and all earlier releases), FreeBSD does NOT  
default to ZFS.


The images distributed by freebsd.org, e.g., Vagrant boxes, ARM images,  
EC2 instances, etc., contain disk images where FreeBSD resides on UFS.   
For example, here's what you end up with when you launch a 12.0-RELEASE  
instance using defaults on AWS (us-east-1 region: ami-03b0f822e17669866):


root@freebsd:/usr/home/ec2-user # gpart show
=>   3  20971509  ada0  GPT  (10G)
3   123 1  freebsd-boot  (62K)
  126  20971386 2  freebsd-ufs  (10G)

And this is what you get when you "vagrant up" the  
freebsd/FreeBSD-12.0-RELEASE box:


root@freebsd:/home/vagrant # gpart show
=>   3  65013755  ada0  GPT  (31G)
3   123 1  freebsd-boot  (62K)
  126   2097152 2  freebsd-swap  (1.0G)
  2097278  62914560 3  freebsd-ufs  (30G)
 65011838  1920- free -  (960K)


When you install from the 12.0-RELEASE ISO, the first option listed  
during the partitioning stage is "Auto (UFS)  Guided Disk Setup".  The  
last option listed---after "Open a shell and partition by hand" is "Auto  
(ZFS)  Guided Root-on-ZFS".  In other words, you have to skip over UFS  
and manual partitioning to select the ZFS install option.


So, I don't see what evidence there is that FreeBSD is defaulting to  
ZFS.  It hasn't up to now. Will FreeBSD 13 default to ZFS?


Umm.. well I install by memory stick images and I had a 10.2 and an 11.0  
both of which had root on zfs as the default.. I had to manually change  
them.  I haven’t looked at anything later... so did something change?  Am  
I in cloud cookoo land?



I don't know about that, but you may well be misremembering.  I just pulled  
down the 10.2 and 11.0 installers from  
http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases and in both  
cases the choices listed in the "Partitioning" step are the same as in the  
current 12.0 installer: "Auto (UFS)  Guided Disk Setup" is listed first and  
selected by default.  "Auto (ZFS)  Guided Root-on-ZFS" is listed last (you  
have to skip past other options such as manually partitioning by hand to  
select it).


I'm confident in saying that ZFS is (or was) not the default partitioning  
option in either 10.2 or 11.0 as officially released by FreeBSD.


Did you use a custom installer you made yourself when installing 10.2 or  
11.0?





FreeBSD used to be targeted at enterprise and devs (which is where I  
found it)... however the last few years have been a big push into the  
consumer (compete with Linux) market.. so you have an OS that concerns  
itself with the desktop and upgrade after upgrade after upgrade (not  
just patching security issues, but upgrades as well.. just like windows  
and OSX)... I get it.. the money is in the keeping of the user base..  
but then you install a file system which is dangerous on a single disk  
by default... dangerous because it’s trusted and “can’t fail” .. until  
it goes titsup.com and then the entire drive is lost and all the data  
on it..  it’s the double standard... advocate you need ECC ram,  
multiple vdevs etc, then single drive it.. sorry.. which one is it?  
Gaarrrhhh!



As people have pointed out elsewhere in this thread, it's false to claim  
that ZFS is unsafe on consumer hardware.  It's no less safe than UFS on  
single-disk setups.


Because anecdote is not evidence, I will refrain from saying, "I've lost  
far more data on UFS than I have on ZFS (especially when SUJ was shaking  
out its bugs)..." >;-)


What I will agree with is that, probably due to its relative youth, ZFS  
has less forensics/data recovery tools than UFS.  I'm sure this will  
improve as time goes on.  (I even posted a link to an article describing  
someone adding ZFS support to a forensics toolkit earlier in this  
thread.)


The problem I see with that statement is that the zfs dev mailing lists  
constantly and consistently following the line of, the data is always  
right there is no need for a “fsck” (which I actually get) but it’s used  
to shut down every thread... the irony is I’m now installing windows 7  
and SP1 on a usb stick (well it’s actually installed, but sp1 isn’t  
finished yet) so I can install a zfs data recovery tool which reports to  
be able to “walk the data” to retrieve all the files...  the irony eh...  
install windows7 on a usb stick to recover a FreeBSD installed zfs  
filesystem...  will let you know if the tool works, but as it was  
recommended by a dev I’m hopeful... h

Re: ZFS...

[Paul Mather]

On May 6, 2019, at 10:14 AM, Michelle Sullivan  wrote:

My issue here (and not really what the blog is about) FreeBSD is  
defaulting to it.


You've said this at least twice now in this thread so I'm assuming you're  
asserting it to be true.


As of FreeBSD 12.0-RELEASE (and all earlier releases), FreeBSD does NOT  
default to ZFS.


The images distributed by freebsd.org, e.g., Vagrant boxes, ARM images, EC2  
instances, etc., contain disk images where FreeBSD resides on UFS.  For  
example, here's what you end up with when you launch a 12.0-RELEASE  
instance using defaults on AWS (us-east-1 region: ami-03b0f822e17669866):


root@freebsd:/usr/home/ec2-user # gpart show
=>   3  20971509  ada0  GPT  (10G)
 3   123 1  freebsd-boot  (62K)
   126  20971386 2  freebsd-ufs  (10G)

And this is what you get when you "vagrant up" the  
freebsd/FreeBSD-12.0-RELEASE box:


root@freebsd:/home/vagrant # gpart show
=>   3  65013755  ada0  GPT  (31G)
 3   123 1  freebsd-boot  (62K)
   126   2097152 2  freebsd-swap  (1.0G)
   2097278  62914560 3  freebsd-ufs  (30G)
  65011838  1920- free -  (960K)


When you install from the 12.0-RELEASE ISO, the first option listed during  
the partitioning stage is "Auto (UFS)  Guided Disk Setup".  The last option  
listed---after "Open a shell and partition by hand" is "Auto (ZFS)  Guided  
Root-on-ZFS".  In other words, you have to skip over UFS and manual  
partitioning to select the ZFS install option.


So, I don't see what evidence there is that FreeBSD is defaulting to ZFS.   
It hasn't up to now. Will FreeBSD 13 default to ZFS?




 FreeBSD used to be targeted at enterprise and devs (which is where I found 
it)... however the last few years have been a big push into the consumer 
(compete with Linux) market.. so you have an OS that concerns itself with the 
desktop and upgrade after upgrade after upgrade (not just patching security 
issues, but upgrades as well.. just like windows and OSX)... I get it.. the 
money is in the keeping of the user base.. but then you install a file system 
which is dangerous on a single disk by default... dangerous because it’s 
trusted and “can’t fail” .. until it goes titsup.com and then the entire drive 
is lost and all the data on it..  it’s the double standard... advocate you need 
ECC ram, multiple vdevs etc, then single drive it.. sorry.. which one is it? 
Gaarrrhhh!



As people have pointed out elsewhere in this thread, it's false to claim  
that ZFS is unsafe on consumer hardware.  It's no less safe than UFS on  
single-disk setups.


Because anecdote is not evidence, I will refrain from saying, "I've lost  
far more data on UFS than I have on ZFS (especially when SUJ was shaking  
out its bugs)..." >;-)


What I will agree with is that, probably due to its relative youth, ZFS has  
less forensics/data recovery tools than UFS.  I'm sure this will improve as  
time goes on.  (I even posted a link to an article describing someone  
adding ZFS support to a forensics toolkit earlier in this thread.)


Cheers,

Paul.
___
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...

[Paul Mather]

On Apr 30, 2019, at 11:17 PM, Michelle Sullivan  wrote:


 I have had it happen
several times over my IT career.  If that happens to you the odds are
that it's absolutely unrecoverable and whatever gets corrupted is
*gone.*


Every drive corruption I have suffered in my career I have been able to  
recover, all or partial data except where the hardware itself was totally  
hosed (Ie clean room options only available)... even with brtfs.. yuk..  
puck.. yuk.. oh what a mess that was...  still get nightmares on that  
one...  but I still managed to get most of the data off... in fact I put  
it onto this machine I currently have problems with.. so after the  
nightmare of brtfs looks like zfs eventually nailed me.



It sounds from reading this thread that FreeBSD's built-in tools for ZFS  
recovery were insufficient for the corruption your pool suffered.  Have you  
looked at the digital forensics realm to see whether those tools might help  
you?  This article claims to extend The Sleuth Kit to support pooled  
storage such as ZFS, and they even describe recovering the bulk of an image  
file from a pool that has a disk missing (Evaluation Section, "Scenario C:  
reconstructing an incomplete pool"):


"Extending The Sleuth Kit and its underlying model for pooled storage file 
system forensic analysis"
https://www.sciencedirect.com/science/article/pii/S1742287617301901



 If said software has no tools to "walk" said
data or if it's impractical to have it do so you're at severe risk of
being hosed.


Umm what?  I’m talking about a userland (libzfs) tool (Ie doesn’t need  
the pool imported) such as zfs send (which requires the pool to be  
imported - hence me not calling it a userland tool) to allow a sending of  
data that can be found to other places where it can be either blindly  
recovered (corruption might be present) or can be used to locate  
files/paths etc that are known to be good (checksums match etc).. walk  
the structures, feed the data elsewhere where it can be  
examined/recovered... don’t alter it it’s a last resort tool when you  
don’t have working backups..



See above.



BTW if you've never had a UFS volume unlink all the blocks within a file
on an fsck and then recover them back into the free list after a crash
you're a rare bird indeed.  If you think a corrupt ZFS volume is fun try
to get your data back from said file after that happens.


Been there done that though with ext2 rather than UFS..  still got all my  
data back... even though it was a nightmare..



Is that an implication that had all your data been on UFS (or ext2:) this  
time around you would have got it all back?  (I've got that impression  
through this thread from things you've written.)  That sort of makes it  
sound like UFS is bulletproof to me.


There are levels of corruption.  Maybe what you suffered would have taken  
down UFS, too?  I guess there's no way to know unless there's some way you  
can recreate exactly the circumstances that took down your original system  
(but this time your data on UFS). ;-)


Cheers,

Paul.

___
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...

[Paul Mather]

On Apr 30, 2019, at 8:14 PM, Michelle Sullivan  wrote:




Michelle Sullivan
http://www.mhix.org/
Sent from my iPad


On 01 May 2019, at 01:15, Karl Denninger  wrote:


IMHO non-ECC memory systems are ok for personal desktop and laptop
machines where loss of stored data requiring a restore is acceptable
(assuming you have a reasonable backup paradigm for same) but not for
servers and *especially* not for ZFS storage.  I don't like the price of
ECC memory and I really don't like Intel's practices when it comes to
only enabling ECC RAM on their "server" class line of CPUs either but it
is what it is.  Pay up for the machines where it matters.


And the irony is the FreeBSD policy to default to zfs on new installs  
using the complete drive.. even when there is only one disk available and  
regardless of the cpu or ram class...  with one usb stick I have around  
here it attempted to use zfs on one of my laptops.



ZFS has MUCH more to recommend it than just the "self-healing" properties  
discussed in this thread.  Its pooled storage model, good administration  
and snapshot/clone support (enabling features such as boot environments)  
make it preferable over UFS as a default file system.  You can even gain  
the benfits of self-healing (for silent data corruption) for single-drive  
systems via "copies=2" or "copies=3" on file sets.




Damned if you do, damned if you don’t comes to mind.



Not really.  Nobody is forcing anyone only to use ZFS as a choice of file  
system.  As you say above, it is a default (a very sensible one, IMHO, but  
even then, it's not really a default).  If you believe ZFS is not right for  
you, do a UFS installation instead.


BTW, I disagree that you need top-notch server-grade hardware to use ZFS.   
Its design embodies the notion of being distrustful of the hardware on  
which it is running, and it is targeted to be able to survive consumer  
hardware (as has been pointed out elsewhere in this thread), e.g., HBAs  
without BBUs.


I am using ZFS on a Raspberry Pi with an external USB drive.  How's that  
for server-grade hardware? :-)


Cheers,

Paul.

___
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: Issues starting unbound on boot

[Paul Mather]

On Apr 30, 2019, at 3:44 PM, Markus Wipp  wrote:


Hi all,

I currently face an issue, where I don’t know further on why this happens  
and what I could do about it.
I hope that this is the correct list to ask my question. If not please  
let me know where else I might try my luck.
I installed unbound from ports, configured it and can start / stop it  
from command line with service unbound start without any problems.
But whenever I reboot the machine it just doesn’t get started. The only  
information I was able to find out so far can be found in  
/var/log/messages:

root: /etc/rc: WARNING: failed to start unbound

I tried to run with rc_debug=“YES” and got the following:
root: /etc/rc: DEBUG: checkyesno: unbound_enable is set to YES.
root: /etc/rc: DEBUG: run_rc_command: start_precmd: start_precmd
root: /etc/rc: DEBUG: checkyesno: rc_startmsgs is set to YES.
root: /etc/rc: DEBUG: run_rc_command: doit:  limits -C daemon  
/usr/local/sbin/unbound  -c /usr/local/etc/unbound/unbound.conf

root: /etc/rc: WARNING: failed to start unbound

uname -a:
FreeBSD h01dc01 11.2-RELEASE-p9 FreeBSD 11.2-RELEASE-p9 #0: Tue Feb  5  
15:30:36 UTC 2019  
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64


Thanks for any useful hints in advance



I don't know how useful this is, but depending upon how the unbound startup  
script is defined to start (e.g., the REQUIRE: and BEFORE: lines in the  
startup script), maybe it is set to start up too early, e.g., before  
/usr/local is mounted?  This at least would be one reason why it doesn't  
start up at boot but will start up manually from the command line.


Cheers,

Paul.


___
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...

[Paul Mather]

On Apr 30, 2019, at 5:05 AM, Michelle Sullivan  wrote:




Michelle Sullivan
http://www.mhix.org/
Sent from my iPad


On 30 Apr 2019, at 18:44, rai...@ultra-secure.de wrote:

Am 2019-04-30 10:09, schrieb Michelle Sullivan:


Now, yes most production environments have multiple backing stores so
will have a server or ten to switch to whilst the store is being
recovered, but it still wouldn’t be a pleasant experience... not to
mention the possibility that if one store is corrupted there is a
chance that the other store(s) would also be affected in the same way
if in the same DC... (Eg a DC fire - which I have seen) .. and if you
have multi DC stores to protect from that.. size of the pipes between
DCs comes clearly into play.



I have one customer with about 13T of ZFS - and because it would take a  
while to restore (actual backups), it zfs-sends delta-snapshots every  
hour to a standby-system.


It was handy when we had to rebuild the system with different HBAs.


I wonder what would happen if you scaled that up by just 10 (storage) and  
had the master blow up where it needs to be restored from backup.. how  
long would one be praying to higher powers that there is no problem with  
the backup...? (As in no outage or error causing a complete outAge.)...  
don’t get me wrong.. we all get to that position at sometime, but in my  
recent experience 2 issues colliding at the same time results in  
disaster.  13T is really not something I have issues with as I can  
usually cobble something together with 16T.. (at least until 6T drives  
became a viable (cost and availability at short notice) option...  even  
10T is becoming easier to get a hold of now.. but I have a measly 96T  
here and it takes weeks even with gigabit bonded interfaces when I need  
to restore.



Such is the curse of large-scale storage when disaster befalls it.

I guess you need to invent a home brew version of Amazon Snowball or Amazon  
Snowmobile. ;-)


Cheers,

Paul.

___
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: CFT: FreeBSD Package Base

[Paul Mather]

On Apr 28, 2019, at 3:52 PM,   wrote:


FreeBSD Community,



I'm pleased to announce a CFT for builds of FreeBSD 12-stable and  
13-current

using "TrueOS-inspired" packaged base. These are stock FreeBSD images which
will allow users to perform all updating via the 'pkg' command directly.
Rather than trying to answer all questions in this announcement, we've
created a FAQ page with more details. Please refer to this page, and let us
know if you have additional questions that we can include on that page  
going

forward.



I currently keep my FreeBSD/arm and FreeBSD/arm64 systems up to date via  
PkgBase in FreeBSD 12.  It works well for me (crossbuilding and hosting the  
PkgBase repository on a FreeBSD/amd64 system).


What is the difference between the above CFT-created PkgBase and one  
created via "make packages" using the native build system  
(https://wiki.freebsd.org/PkgBase)?  Looking at the FAQ you linked  
(https://trueos.github.io/pkgbase-docs/), it seems the above CFT system is  
less granular than the one currently produced via the in-tree "make  
packages" (which could be a good thing from a simplicity standpoint).  Is  
there anything else?


Is the above CFT-produced packages the system that will ultimately become  
the way packaged base is produced in FreeBSD 13.0-RELEASE, or is it just an  
alternative you want people to try out and evaluate?  I guess I'm not clear  
what "TrueOS-inspired" packaged base means. :-)


Cheers,

Paul.

___
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: Problem with STABLE-12

[Paul Mather]

On Apr 25, 2019, at 10:07 AM, Filippo Moretti  wrote:

Did you build world yesterday and now drm-kmod is working again?The only  
problem I have with legacy both drm and ati is that smplayer crashes the  
system and I have to reset via power switch.



I updated and installed kernel and world on Tuesday, mainly to bring in the  
clang 8.0.0 changes.  Then, yesterday, I saw graphics/drm-fbsd12.0-kmod  
listed when I did a portsnap update and so built it on the off-chance  
whatever had been updated in it would cause it to work again on my system.   
I replaced my existing graphics/drm-legacy-kmod with it, and the system did  
not hang in multiuser when trying to load the kmod.  The resultant console  
worked like before (when I used graphics/drm-kmod).


I just looked at the graphics/drm-kmod Makefile and  
graphics/drm-fbsd12.0-kmod is the port selected for my OSVERSION (1200507)  
when installing.


Cheers,

Paul.

PS: I am only using graphics/drm-kmod for the system console, to get more  
text columns than the built-in 640x480 VGA console would otherwise allow.



Filippo

On Thursday, April 25, 2019, 4:00:00 PM GMT+2, Paul Mather  
 wrote:



On Apr 18, 2019, at 8:01 AM, Pete French  wrote:

>
>> I have a radeon graphics card, too.  Recently, I had a problem with the
>> graphics/drm-kmod hanging on boot in multi-user.  My fix was to switch
>> to graphics/drm-legacy-kmod, which at least lets the system boot again.
>> I figure the newer graphics/drm-kmod no longer supports my old radeon
>> card.
>
> So, I was about to post about this, and then saw this thread. I too ave
> had to go back to the legacy-kmod because something broke it in the last
> couple of weeks. Was using the new one fine until then. Unfortunately I
> didnt know it was broken as have been working remotely and thus not in
> front of the machine. But I doubt that the Radeon stopped being supported
> soehow - that would be mentioned somewhere surely ? It looks like a hang
> on loading the module to me.


As of yesterday, the graphics/drm-fbsd12.0-kmod port is working for me[1].
This is good news because a) the video quality is better, and, b) it
supports colour, which graphics/drm-legacy-kmod didn't seem to.  (So now I
get a green status bar again in tmux.)

In other words, it may be that whatever broke in graphics/drm-kmod has now
been fixed?

Cheers,

Paul.

[1] At least working in FreeBSD 12.0-STABLE r346597.


___
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"

Re: Problem with STABLE-12

[Paul Mather]

On Apr 18, 2019, at 8:01 AM, Pete French  wrote:



I have a radeon graphics card, too.  Recently, I had a problem with the  
graphics/drm-kmod hanging on boot in multi-user.  My fix was to switch  
to graphics/drm-legacy-kmod, which at least lets the system boot again.   
I figure the newer graphics/drm-kmod no longer supports my old radeon  
card.


So, I was about to post about this, and then saw this thread. I too ave  
had to go back to the legacy-kmod because something broke it in the last  
couple of weeks. Was using the new one fine until then. Unfortunately I  
didnt know it was broken as have been working remotely and thus not in
front of the machine. But I doubt that the Radeon stopped being supported  
soehow - that would be mentioned somewhere surely ? It looks like a hang  
on loading the module to me.



As of yesterday, the graphics/drm-fbsd12.0-kmod port is working for me[1].   
This is good news because a) the video quality is better, and, b) it  
supports colour, which graphics/drm-legacy-kmod didn't seem to.  (So now I  
get a green status bar again in tmux.)


In other words, it may be that whatever broke in graphics/drm-kmod has now  
been fixed?


Cheers,

Paul.

[1] At least working in FreeBSD 12.0-STABLE r346597.

___
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: Problem with STABLE-12

[Paul Mather]

On Apr 17, 2019, at 9:44 AM, Filippo Moretti via freebsd-stable  
 wrote:


I previously reported that I was unable to boot my system with STABLE-12  
of april 13 the system stop at Loading kernel modules.I installed  
stable-12 snapshot of april 11 on a second disc to try to rescue the  
first one.I could go on with my plan until I installed drm kmodand addedd  
kld_list=/boot/modules/radeonkms.ko in /etc/rc.conf



I have a radeon graphics card, too.  Recently, I had a problem with the  
graphics/drm-kmod hanging on boot in multi-user.  My fix was to switch to  
graphics/drm-legacy-kmod, which at least lets the system boot again.  I  
figure the newer graphics/drm-kmod no longer supports my old radeon card.



now also this second disk no longer boots,it stops in Loading kernel  
modules.Further how can I mount ada0p3 partition rw on this second disc  
considering that bot are zfs?(I could not figure this out mysel)I plan to  
reinstall on the second disksincerelyFilippo



The easiest way to be able to edit the configuration of the existing system  
to fix things is to boot it in single user mode (press "2" from the loader  
menu).


When you get to the single user prompt, you can then mount your ZFS file  
systems for writing as follows:


mount -uw /
/etc/rc.d/zfsbe start
/etc/rc.d/zfs start


You can then, e.g., edit /etc/rc.conf and remove the problematic kld_list  
entry.


Cheers,

Paul.
___
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.2-STABLE kernel wired memory leak

[Paul Mather]

On Mar 29, 2019, at 5:52 AM, Robert Schulze  wrote:

> Hi,
> 
> I just want to report a similar issue here with 11.2-RELEASE-p8.
> 
> The affected machine has 64 GB ram and does daily backups from several
> machines in the night, at daytime there a parallel runs of clamav on a
> specific dataset.
> 
> One symtom is basic I/O-performance: After upgrading from 11.1 to 11.2
> backup times have increased, and are even still increasing. After one
> week of operation, backup times have doubled - without having changed
> anything else.
> 
> Then there is this wired memory and way too lazy reclaim of memory for
> user processes: The clamav scans start at 10:30 and get swapped out
> immediatly. Although vfs.zfs.arc_max=48G, wired is at 62 GB before the
> scans and it takes about 10 minutes for the scan processes to actually
> run on system ram, not swap.
> 
> There is obviously something broken, as there are several threads with
> similar observations.


I am using FreeBSD 12 (both -RELEASE and -STABLE) and your comment about "way 
too lazy reclaim of memory" struck a chord with me.  On one system I regularly 
have hundreds of MB identified as being in the "Laundry" queue but FreeBSD 
hardly ever seems to do the laundry.  I see the same total for days.

When does FreeBSD decide to do its laundry?  Right now "top" is showing 835M in 
"Laundry" and the system is >99% idle.

How can I get the system to be more proactive about doing its housekeeping when 
it has idle time?

It would be much nicer to have it do laundry during a calm time rather than get 
all flustered when it's down to its last pair of socks (metaphorically 
speaking) and page even more stuff out to swap. :-)

Cheers,

Paul.

___
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: poudriere(-devel) ports updating question

[Paul Mather]

On Mar 6, 2019, at 3:58 PM, tech-lists  wrote:

> On Wed, Mar 06, 2019 at 06:23:49PM +0100, Stefan Bethke wrote:
>>> Am 05.03.2019 um 15:09 schrieb tech-lists :
> 
>>> Basically I'm looking for exclude mask functionality when updating a
>>> ports tree with poudriere ports.
>>> 
>>> Do I need to do this manually or have I missed something?
>> 
>> I don’t think it’s easy to do that. How would you handle dependencies? (For 
>> example, some ports require X11 libs and stuff, even though they’re in a 
>> different category.)
> 
> You're right of course. My logic was wrong, and wrong premise[1] because I
> was stuck on thinking a bulk -a build. But I found how to do it (to remove 
> categories) in case anyone is interested. The key is in the
> method used to update the tree, which is svn+https.
> 
> so, from the top of the ports tree, svn update --set-depth=exclude biology 
> would exclude the biology category permanently. svn update 
> --set-depth=infinity biology would re-add it.
> svn update --set-depth=infinity would make it be like nothing was
> excluded in the first place.
> 
> but on reflection, it breaks a little of the ports infrastructure and I
> don't want to do that.


That's correct: omitting parts of the ports hierarchy might break a particular 
ports build catastrophically.

If you're looking to exclude certain functionality when building ports you 
should investigate using ports options to achieve that.

For example, I have a poudriere jail called "trurl" that is a headless system 
on which I don't want to use X11.  I also don't want to use CUPS for that 
matter.  So, in its "trurl-make.conf" file I include this line:

OPTIONS_UNSET_FORCE= X11 CUPS


That will force those options off for all ports.  The result is I don't get any 
ports built supporting those options.

I guess it's not foolproof, but it seems to work well enough for me.

I hope this helps.

Cheers,

Paul.
___
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: Problem building kernel STABLE12 amd64 arch

[Paul Mather]

On Feb 17, 2019, at 4:11 AM, Filippo Moretti via freebsd-stable 
 wrote:

> I tried to update stable to yesterday build and I get the following error on 
> amd64 arch
> linking kernel
> ld: error: undefined symbol: iflib_get_softc
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_legacy_intr)
> 
> ld: error: undefined symbol: iflib_admin_intr_deferred
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_legacy_intr)
> 
> ld: error: undefined symbol: iflib_get_softc
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_tx_queues_alloc)
> 
> ld: error: undefined symbol: iflib_dma_alloc_align
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_tx_queues_alloc)
> ld: error: undefined symbol: iflib_get_softc
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_rx_queues_alloc)
> 
> ld: error: undefined symbol: iflib_dma_alloc_align
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_rx_queues_alloc)
> 
> ld: error: undefined symbol: iflib_get_softc
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_queues_free)
> 
> ld: error: undefined symbol: iflib_dma_free
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_queues_free)
> 
> ld: error: undefined symbol: iflib_get_dev
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_pre)>>>   
 if_vmx.o:(vmxnet3_attach_pre)
> 
> ld: error: undefined symbol: iflib_get_sctx
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_pre)
> 
> ld: error: undefined symbol: iflib_get_softc_ctx
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_pre)
> 
> ld: error: undefined symbol: iflib_get_ifp
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_pre)
> 
> ld: error: undefined symbol: iflib_get_media
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_pre)
> 
> ld: error: undefined symbol: iflib_set_mac
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_pre)
> ld: error: undefined symbol: iflib_get_softc_ctx
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_post)
> 
> ld: error: undefined symbol: iflib_get_softc
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_post)
> 
> ld: error: undefined symbol: iflib_dma_alloc_align
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_post)
> 
> ld: error: undefined symbol: iflib_dma_alloc_align
 referenced by if_vmx.c
if_vmx.o:(vmxnet3_attach_post)
> 
> ld: error: too many errors emitted, stopping now (use -error-limit=0 to see 
> all errors)
> *** Error code 1
> 
> Stop.
> Stop.
> make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/STING_VT
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src
> 
> Any help appreciatedsincerelyFilippo


Please see the 20190214 entry in /usr/src/UPDATING to fix this problem.

Cheers,

Paul.

___
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: "sockstat: struct xinpgen size mismatch" in 11.2-p4 jail on 12-STABLE host

[Paul Mather]

On Nov 26, 2018, at 6:44 PM, Brooks Davis  wrote:

> On Sat, Nov 24, 2018 at 09:17:23AM -0500, Paul Mather wrote:
>> I updated a system yesterday to the latest 12-STABLE as part of the upcoming 
>> 12-RELEASE cycle. I've installed several BETA and at least one RC of 12 
>> since updating from 11-STABLE as part of the 12 cycle and have had no 
>> problems up to now.  Currently, I am at FreeBSD 12.0-PRERELEASE r340834 
>> GENERIC amd64.
>> 
>> Since the most recent update, I have been getting this error when I invoke 
>> "sockstat" in any of the jails running on the system:
>> 
>>  sockstat: struct xinpgen size mismatch
>> 
>> The jails are managed via iocage and all are running 11.2-RELEASE-p4, which 
>> is the most up-to-date version of 11.2-RELEASE.
>> 
>> Has anyone encountered this error?  Unfortunately, it means that it breaks 
>> Salt, which is what I use to help manage the jails.  Sockstat works fine on 
>> the host, just not in the jails.
>> 
>> I am using a GENERIC kernel which includes "options COMPAT_FREEBSD11".  I 
>> assumed this would allow FreeBSD 11 binaries to work on a FreeBSD 12 kernel, 
>> which it has done up to now.
> 
> We broke this system management ABI months ago.  I'm not sure why you're
> only bumping into this now.
> 
> We don't provide backward compatibility for these interfaces.  To make
> this configuration work, I'd suggest replacing the sockstat in
> the jail with a statically linked version built for FreeBSD 12.


Thank you for the response and the advice.

I'm not sure why/if I'm only bumping into this now.  It may be that I only 
looked deeper into why Salt was breaking this time around and saw the problem 
to be an invocation of "sockstat" by a Python module.  Salt has temporarily 
broken for me in the past due to updates, but usually mends itself on a 
subsequent rebuild/reinstall of the packages.

When the 12.0-RC2 announcement came out shortly after I reported the above I 
decided to upgrade to it.  That seemed to fix the problem with Salt (or at 
least coincide with the problem going away), which is my main concern.  I still 
get the same error as reported above when I invoke "sockstat" in the 11.2 jail, 
but as long as Salt is working again then that's all I really need. :-)

When 12.0-RELEASE comes out I will most likely just upgrade the 11.2 jails to 
12.0.  The main reason for not updating now is that iocage doesn't appear to 
recognise the existence of any release more recent than 11.2.

Thanks again.

Cheers,

Paul.

___
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"

"sockstat: struct xinpgen size mismatch" in 11.2-p4 jail on 12-STABLE host

[Paul Mather]

I updated a system yesterday to the latest 12-STABLE as part of the upcoming 
12-RELEASE cycle.  I've installed several BETA and at least one RC of 12 since 
updating from 11-STABLE as part of the 12 cycle and have had no problems up to 
now.  Currently, I am at FreeBSD 12.0-PRERELEASE r340834 GENERIC amd64.

Since the most recent update, I have been getting this error when I invoke 
"sockstat" in any of the jails running on the system:

sockstat: struct xinpgen size mismatch

The jails are managed via iocage and all are running 11.2-RELEASE-p4, which is 
the most up-to-date version of 11.2-RELEASE.

Has anyone encountered this error?  Unfortunately, it means that it breaks 
Salt, which is what I use to help manage the jails.  Sockstat works fine on the 
host, just not in the jails.

I am using a GENERIC kernel which includes "options COMPAT_FREEBSD11".  I 
assumed this would allow FreeBSD 11 binaries to work on a FreeBSD 12 kernel, 
which it has done up to now.

Cheers,

Paul.
___
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: FreeBSD Quarterly Status Report - Fourth Quarter 2016

[Paul Mather]

On Feb 14, 2017, at 2:53 AM, Kai Gallasch  wrote:

> On 14.02.2017 05:20 Benjamin Kaduk wrote:
>> Core requested the removal of the misc/jive port, on the grounds that
>>   it had no function other than to turn text into an offensively racist
>>   parody. This proved controversial, with many seeing this as a first
>>   step in bowdlerizing the entire ports tree. That is certainly not
>>   Core's intention. Core's aim here is to help secure the future of the
>>   FreeBSD project by making it welcoming to all contributors, regardless
>>   of ethnicity, gender, sexuality or other improper bases for
>>   discrimintation. While misc/jive may once have been seen as harmless
>>   fun, today the implicit approval implied by having it in the ports tree
>>   sends a message at odds with the project's aims.
> 
> 
> Am I dreaming? Has this "disease" finally reached my beloved FreeBSD
> after all this years?
> 
> In my opinion it is just not Cores business making decisions besides the
> technical and organizational aspect. As long as any port has a handful
> of users and someone is willing to support it, its existence in the tree
> is justified. And basically I don't care if there is a port in the tree,
> where little harmless kittens are being shot at.
> 
> Thank you Core!
> You made my day!


If they lifted your day so much, you should send them a donation. :-)

Cheers,

Paul.

PS: Thank you Core, IMHO you did the right thing.

___
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: how can I make freebsd wait for usb to become active? Or delay mountroot?

[Paul Mather]

On Feb 13, 2017, at 2:00 PM, tech-lists  wrote:

> Hello stable@,
> 
> system: 11-stable r313553
> 
> In the kernel there is an option for scsi delay. Is there also one for
> usb? Perhaps not in the kernel but elsewhere. I can't find it.
> 
> The problem is seen especially where the bootable device is usb. The
> boot process starts and dumps me at mountroot where I wait for a short
> time until the usb stick is properly detected (bright white writing at
> the console). The usb stick is plugged into a usb3 port. For example:
> 
> [snip]
> 
> usbus0: 5.0Gbps Super Speed USB v3.0
> usbus1: 12Mbps Full Speed USB v1.0
> usbus2: 480Mbps High Speed USB v2.0
> usbus3: 12Mbps Full Speed USB v1.0
> ugen0.1: <0x1022 XHCI root HUB> at usbus0
> uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
> ugen1.1:  at usbus1
> uhub1:  on usbus1
> ugen2.1:  at usbus2
> uhub2:  on usbus2
> ugen3.1:  at usbus3
> uhub3:  on usbus3
> usbus4: 480Mbps High Speed USB v2.0
> ugen4.1:  at usbus4
> uhub4:  on usbus4
> acpi_tz0: _CRT value is absurd, ignored (255.1C)
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ada0:  ACS-2 ATA SATA 3.x device
> cd0 at ahcich1 bus 0 scbus1 target 0 lun 0
> cd0:  Removable CD-ROM SCSI device
> cd0: Serial Number 1415TP277450E0H6H
> cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
> cd0: Attempt to query device size failed: NOT READY, Medium not present
> - tray open
> ada0: Serial Number JA1006103G0ALV
> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
> ada0: Command Queueing enabled
> ada0: 953869MB (1953525168 512 byte sectors)
> SMP: AP CPU #3 Launched!
> SMP: AP CPU #1 Launched!
> SMP: AP CPU #2 Launched!
> Timecounter "TSC" frequency 1597045198 Hz quality 1000
> Trying to mount root from ufs:/dev/da0p2 [rw]...
> uhub3: 5 ports with 5 removable, self powered
> uhub1: 5 ports with 5 removable, self powered
> uhub0: 4 ports with 4 removable, self powered
> Root mount waiting for: usbus4 usbus2 usbus0
> ugen0.2:  at usbus0
> umass0 on uhub0
> umass0: 
> on usbus0
> umass0:  SCSI over Bulk-Only; quirks = 0x8100
> umass0:3:0: Attached to scbus3
> uhub2: 5 ports with 5 removable, self powered
> uhub4: 5 ports with 5 removable, self powered
> ugen0.3:  at usbus0
> ukbd0 on uhub0
> ukbd0:  on usbus0
> kbd2 at ukbd0
> Root mount waiting for: usbus4
> ugen4.2:  at usbus4
> mountroot: waiting for device /dev/da0p2...
> Mounting from ufs:/dev/da0p2 failed with error 19.
> 
> Loader variables:
>  vfs.root.mountfrom=ufs:/dev/da0p2
>  vfs.root.mountfrom.options=rw
> 
> Manual root filesystem specification:
>  : [options]
>  Mount  using filesystem 
>  and with the specified (optional) option list.
> 
>eg. ufs:/dev/da0s1a
>zfs:tank
>cd9660:/dev/cd0 ro
>  (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> 
>  ?   List valid disk boot devices
>  .   Yield 1 second (for background tasks)
>  Abort manual input
> 
> mountroot> Trying to mount root from ufs:/dev/da0p2 []...
> mountroot: waiting for device /dev/da0p2...
> Mounting from ufs:/dev/da0p2 failed with error 19.
> 
> mountroot>
> 
> [snip]
> 
> Then this happens:
> 
> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> (probe0:umass-sim0:0:0:0): Retrying command
> da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
> da0: < USB DISK 3.0 PMAP> Removable Direct Access SPC-4 SCSI device
> da0: Serial Number 070B4722335D3288
> da0: 400.000MB/s transfers
> da0: 30176MB (61800448 512 byte sectors)
> da0: quirks=0x3
> 
> so now at the mountroot prompt I enter ufs:/dev/da0p2 (which is a value
> that mountroot already had) and carry on booting:
> 
> mountroot> Trying to mount root from ufs:/dev/da0p2 []...
> re0: link state changed to DOWN
> re0: link state changed to UP
> ums0 on uhub0
> ums0:  on usbus0
> ums0: 16 buttons and [XYZT] coordinates ID=2
> uhid0 on uhub0
> uhid0:  on usbus0
> 
> [...]
> 
> The same sort of thing happens on an 11-stable r313043 desktop, only
> this time I'm not booting from usb. The system comes up, I get a login
> prompt, then five or ten seconds later usb wakes up having detected the
> usb3 external HD.
> 
> How can I fix this?


This topic cropped up on the freebsd-arm mailing list very recently.  One 
solution is to add this to /boot/loader.conf:

kern.cam.boot_delay="1"

That instructs the system to wait 10 seconds (1 milliseconds) during boot 
to give time for the CAM subsystem probes to complete.  (USB storage devices 
use the CAM subsystem.)

It was also noted by Konstantin Belousov in that thread 
(https://lists.freebsd.org/pipermail/freebsd-arm/2017-February/015626.html 
) 
that a newer option is available:

> Right solution after r313350 is to set
>   vfs.root_mount_always_wait=1

Re: Does building linux packages under poudriere require linux compatibility emulation?

[Paul Mather]

On Jan 14, 2017, at 9:11 AM, Tijl Coosemans  wrote:

> On Sat, 14 Jan 2017 01:07:09 +0100 Mark Martinec 
>  wrote:
>> When building packages under poudriere on 11.0-RELEASE-p7 (from a 
>> command line in a terminal window) I'm noticing occasional streams of
>> diagnostic:
>> 
>>   ELF binary type "3" not known.
>> 
>> which seem to be related to building some linux packages (example below,
>> parallel builds). Poudriere still reports success for these builds.
>> 
>> The host where poudriere is running does not have linux.ko loaded.
>> 
>> Does building such packages really require linuxilator configured
>> on the build host ???
> 
> To build a package, its dependencies need to be installed and on
> installation some packages may need to run certain commands and for
> linux packages these commands may be linux programs.  So, yes, if you
> need to build linux packages the build host should have USE_LINUX=yes
> in /etc/rc.conf.


The only thing you need on the host is to have the linux kernel module loaded.  
(You don't need to have any Linux packages installed there.)  The default 
setting in /usr/local/etc/poudriere.conf is to have NOLINUX=yes commented out, 
i.e., Linux support in Poudriere is enabled unless you explicitly disable it.

The easiest way to load the linux kernel module on the host for use with 
Poudriere is to add it to the "kld_list" setting in /etc/rc.conf, e.g.,

kld_list="linux"


Cheers,

Paul.
___
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: pkg upgrade wants to install old postgresql-client-version. why?

[Paul Mather]

On Jan 13, 2017, at 10:19 AM, Holger Kipp <holger.k...@alogis.com> wrote:

> Dear Paul,
> 
>> Am 13.01.2017 um 15:49 schrieb Paul Mather <p...@gromit.dlib.vt.edu 
>> <mailto:p...@gromit.dlib.vt.edu>>:
>> 
>> On Jan 13, 2017, at 9:24 AM, Holger Kipp <holger.k...@alogis.com 
>> <mailto:holger.k...@alogis.com>> wrote:
>> 
>>> Dear all,
>>> 
>>> I have a little FreeBSD system upgraded from 10.2-p24 to 10.3-p11. GENERIC 
>>> Kernel.
>>> This also included upgrading postgresql from 9.5.4 to 9.5.5_1. and about 
>>> 220 other ports.
>>> Most were upgraded using pkg upgrade, but postgresql had to be upgraded 
>>> using the manual
>>> make, make package, make deinstall && make reinstall.
>>> 
>>> root@gw2:~ # pkg info | grep postgresql
>>> postgresql95-client-9.5.5_1PostgreSQL database (client)
>>> postgresql95-contrib-9.5.5 The contrib utilities from the PostgreSQL 
>>> distribution
>>> postgresql95-server-9.5.5_1PostgreSQL is the most advanced open-source 
>>> database available anywhere
>>> root@gw2:~ #
>>> 
>>> All Ports were originally installed from source but with default config.
>>> 
>>> 
>>> 
>>> Now pkg upgrade wants to install postgresql-client 9.3.15_1:
>>> 
>>> root@gw2:~ # pkg upgrade
>>> Updating FreeBSD repository catalogue...
>>> FreeBSD repository is up-to-date.
>>> All repositories are up-to-date.
>>> Checking for upgrades (28 candidates): 100%
>>> Processing candidates (28 candidates): 100%
>>> The following 3 package(s) will be affected (of 0 checked):
>>> 
>>> New packages to be INSTALLED:
>>>   postgresql93-client: 9.3.15_1
>>> 
>>> Installed packages to be REINSTALLED:
>>>   p5-Pg-2.1.1_4,1 (direct dependency changed: perl5)
>>>   p5-DBD-Pg-3.5.3 (direct dependency changed: p5-DBI)
>>> 
>>> Number of packages to be installed: 1
>>> Number of packages to be reinstalled: 2
>>> 
>>> The process will require 9 MiB more space.
>>> 2 MiB to be downloaded.
>>> 
>>> Proceed with this action? [y/N]:
>>> 
>>> 
>>> My programs using p5-Pg or p5-DBD-Pg seem to work just fine, and perl5 has 
>>> current version perl5-5.24.1.r4_1.
>>> However I had to reinstall both packages manually because they were not 
>>> properly working after upgrade via pkg upgrade.
>> 
>> 
>> You are using the official FreeBSD packages for your upgrade.  They are 
>> built with postgresql93 as the default version of PostgreSQL. Thus, p5-Pg 
>> and p5-DBD-Pg will both have a dependency on the postgresql-client packages 
>> (for libraries allowing them to interface with PostgreSQL servers), which, 
>> in the FreeBSD repository, is postgresql93-client.
>> 
>> Because postgresql93-client conflicts with postgresql95-client, it will try 
>> and uninstall the latter when trying to satisfy the postgresql93-client 
>> dependency.  The same will be true of any other package you try and use from 
>> the FreeBSD repository that has a dependency upon PostgreSQL.
>> 
>> 
>>> How can I check where from pkg upgrade gets the idea to install old 
>>> 9.3.15_1 postgresql client?
>>> And is there a way to rectify this?
>> 
>> 
>> I would imagine that, like you did with the PostgreSQL 9.5 ports, you would 
>> also have to build and reinstall p5-Pg and p5-DBD-Pg manually, too.  Be sure 
>> to add "DEFAULT_VERSIONS+= pgsql=9.5" or otherwise amend your 
>> DEFAULT_VERSIONS setting in /etc/make.conf before building so that p5-Pg and 
>> p5-DBD-Pg depend upon the version of PostgreSQL you want.
>> 
>> Mixing custom local ports and stock ports from the FreeBSD official packages 
>> repository will often lead to these sorts of problems, due to differences in 
>> build options and such.
>> 
>> Another way to rectify it is to build your own ports using something like 
>> Poudriere.
> 
> Thank you very much for the good explanation. I’ll go with the 
> DEFAULT_VERSIONS-Setting in make.conf then.
> Is there a list of dependencies for the FreeBSD repository so I can check if 
> my system is also affected there?


I'm not sure if this is what you're asking, but one thing you can do is query 
the FreeBSD packages repository for such information.  See "pkg help rquery" 
for details.  E.g., to see what packages (and versions) the p5-DBD-Pg package 
depends upo

Re: pkg upgrade wants to install old postgresql-client-version. why?

[Paul Mather]

On Jan 13, 2017, at 9:24 AM, Holger Kipp  wrote:

> Dear all,
> 
> I have a little FreeBSD system upgraded from 10.2-p24 to 10.3-p11. GENERIC 
> Kernel.
> This also included upgrading postgresql from 9.5.4 to 9.5.5_1. and about 220 
> other ports.
> Most were upgraded using pkg upgrade, but postgresql had to be upgraded using 
> the manual
> make, make package, make deinstall && make reinstall.
> 
> root@gw2:~ # pkg info | grep postgresql
> postgresql95-client-9.5.5_1PostgreSQL database (client)
> postgresql95-contrib-9.5.5 The contrib utilities from the PostgreSQL 
> distribution
> postgresql95-server-9.5.5_1PostgreSQL is the most advanced open-source 
> database available anywhere
> root@gw2:~ #
> 
> All Ports were originally installed from source but with default config.
> 
> 
> 
> Now pkg upgrade wants to install postgresql-client 9.3.15_1:
> 
> root@gw2:~ # pkg upgrade
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
> Checking for upgrades (28 candidates): 100%
> Processing candidates (28 candidates): 100%
> The following 3 package(s) will be affected (of 0 checked):
> 
> New packages to be INSTALLED:
>postgresql93-client: 9.3.15_1
> 
> Installed packages to be REINSTALLED:
>p5-Pg-2.1.1_4,1 (direct dependency changed: perl5)
>p5-DBD-Pg-3.5.3 (direct dependency changed: p5-DBI)
> 
> Number of packages to be installed: 1
> Number of packages to be reinstalled: 2
> 
> The process will require 9 MiB more space.
> 2 MiB to be downloaded.
> 
> Proceed with this action? [y/N]:
> 
> 
> My programs using p5-Pg or p5-DBD-Pg seem to work just fine, and perl5 has 
> current version perl5-5.24.1.r4_1.
> However I had to reinstall both packages manually because they were not 
> properly working after upgrade via pkg upgrade.


You are using the official FreeBSD packages for your upgrade.  They are built 
with postgresql93 as the default version of PostgreSQL.  Thus, p5-Pg and 
p5-DBD-Pg will both have a dependency on the postgresql-client packages (for 
libraries allowing them to interface with PostgreSQL servers), which, in the 
FreeBSD repository, is postgresql93-client.

Because postgresql93-client conflicts with postgresql95-client, it will try and 
uninstall the latter when trying to satisfy the postgresql93-client dependency. 
 The same will be true of any other package you try and use from the FreeBSD 
repository that has a dependency upon PostgreSQL.


> How can I check where from pkg upgrade gets the idea to install old 9.3.15_1 
> postgresql client?
> And is there a way to rectify this?


I would imagine that, like you did with the PostgreSQL 9.5 ports, you would 
also have to build and reinstall p5-Pg and p5-DBD-Pg manually, too.  Be sure to 
add "DEFAULT_VERSIONS+= pgsql=9.5" or otherwise amend your DEFAULT_VERSIONS 
setting in /etc/make.conf before building so that p5-Pg and p5-DBD-Pg depend 
upon the version of PostgreSQL you want.

Mixing custom local ports and stock ports from the FreeBSD official packages 
repository will often lead to these sorts of problems, due to differences in 
build options and such.

Another way to rectify it is to build your own ports using something like 
Poudriere.

Cheers,

Paul.

___
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: freebsd-update

[Paul Mather]

On Dec 8, 2016, at 4:13 PM, Randy Bush  wrote:

> Basic symptom:
> 
>#  /usr/sbin/freebsd-update fetch
>Looking up update.FreeBSD.org mirrors... none found.
>Fetching metadata signature for 10.3-STABLE from update.FreeBSD.org... 
> failed.
>No mirrors remaining, giving up.


I had this problem a while ago.  In my case, it turned out that my upstream DNS 
was filtering out SRV requests, which breaks freebsd-update mirror handling.  
My upstream DNS was via an OpenWRT box.  According to their documentation 
(https://wiki.openwrt.org/doc/howto/dhcp.dnsmasq) in the "SIP-Phones and 
dnsmasq" section they say, "By default, the option filterwin2k in dnsmasq is 
activated, which seems to cause to block queries for SRV records."  True 
enough, disabling "filterwin2k" in /etc/config/dhcp "fixed" my problem.

I don't know if this is related to your problem, but in my case I wasn't 
getting *any* SRV records returned for _http._tcp.update.FreeBSD.org... :-(

I believe freebsd-update falls back to a standard server if no mirrors can be 
enumerated, but this server tends to get overloaded when security advisories 
come out (at least that was my experience when I had the SRV records problem) 
and so freebsd-update can fail.

Cheers,

Paul.
___
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: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2

[Paul Mather]

On Aug 3, 2015, at 2:15 PM, Paul Mather freebsd-li...@gromit.dlib.vt.edu 
wrote:

 On Aug 3, 2015, at 12:17 PM, Jack Vogel jfvo...@gmail.com wrote:
 
 Have you tried it on HEAD, and have you tried it on the same system with some
 recent flavor of Linux?
 
 No, and no.  It's a good idea, though.  I can try it this weekend, if I can 
 run each OS via a USB memstick.


Just to follow up on myself, I tried this external USB drive on a 
20150804-r286285 snapshot of FreeBSD/amd64 11-CURRENT on the same system, as 
well as under Ubuntu 15.04.

The 4 TB Western Digital My Book 1230 works under both those operating systems.

The drive is detected and works reliably when plugged in to a USB 2 port on 
either 11-CURRENT or Ubuntu 15.04.  It also works reliably when plugged in to a 
USB 3 port on either OS, however, it isn't always detected reliably under 
FreeBSD 11-CURRENT when unplugged and plugged in again (2 times out of 3 
attempts), but was detected every time without fail under Ubuntu 15.04.

So, it appears the hardware is okay; it seems the problem may lie with FreeBSD 
10.2.

Cheers,

Paul.


 
 With this being such a commonplace drive, I'd hoped someone might pipe up and 
 say something along the lines of, oh, you have to add USB quirk XYZ to get 
 that model working under FreeBSD.  No such luck, it seems.
 
 Cheers,
 
 Paul.
 
 
 
 Jack
 
 
 On Mon, Aug 3, 2015 at 8:35 AM, Paul Mather 
 freebsd-li...@gromit.dlib.vt.edu mailto:freebsd-li...@gromit.dlib.vt.edu 
 wrote:
 On Aug 3, 2015, at 11:09 AM, Alban Hertroys haram...@gmail.com 
 mailto:haram...@gmail.com wrote:
 
 On 3 August 2015 at 15:01, Paul Mather freebsd-li...@gromit.dlib.vt.edu 
 mailto:freebsd-li...@gromit.dlib.vt.edu wrote:
 On Aug 2, 2015, at 9:34 PM, Adam McDougall mcdou...@egr.msu.edu 
 mailto:mcdou...@egr.msu.edu wrote:
 
 On 08/02/2015 21:22, Paul Mather wrote:
 I have a 4TB external USB drive (Western Digital My Book 1230) that I am 
 trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed 
 Jul 29 20:59:39 EDT 2015).  This system has a MSI 760GMA-P34 (FX) 
 motherboard.
 
 The drive probes unreliably when plugged in to a USB 3 port.  It 
 reliably probes when plugged into a USB 2 port.  However, it works in 
 neither cases.  Attempting to dd from the drive results in a dd: 
 /dev/da0: Invalid argument.
 
 FYI: I had been experiencing the same with a 2 TB WD MyBook on OS X
 (Mavericks). The drive was being used for Time Machine backups, but it
 would at irregular intervals it would just 'disconnect' itself. My
 guess is that there's a firmware problem in the USB3 chip in those
 drives.
 
 After trying to get the issue fixed for almost half a year I returned
 it and replaced it by a Seagate, which has been working flawlessly
 ever since.
 
 I'm just saying, perhaps the problem isn't with FreeBSD but with the drive.
 
 
 I'd love just to get to the randomly disconnects stage under FreeBSD at 
 this point. :-)
 
 Up to now, I have been unable to read ANY data off the drive under FreeBSD, 
 either via USB 2 or USB 3. :-(
 
 However, you have given me something to think about: does anyone know of a 4 
 TB USB 2 or 3 drive that will work reliably under FreeBSD 10-STABLE right 
 now?
 
 Cheers,
 
 Paul.
 
 ___
 freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable 
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org 
 mailto: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...@freebsd.org

Re: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2

[Paul Mather]

On Aug 3, 2015, at 11:09 AM, Alban Hertroys haram...@gmail.com wrote:

 On 3 August 2015 at 15:01, Paul Mather freebsd-li...@gromit.dlib.vt.edu 
 wrote:
 On Aug 2, 2015, at 9:34 PM, Adam McDougall mcdou...@egr.msu.edu wrote:
 
 On 08/02/2015 21:22, Paul Mather wrote:
 I have a 4TB external USB drive (Western Digital My Book 1230) that I am 
 trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed 
 Jul 29 20:59:39 EDT 2015).  This system has a MSI 760GMA-P34 (FX) 
 motherboard.
 
 The drive probes unreliably when plugged in to a USB 3 port.  It reliably 
 probes when plugged into a USB 2 port.  However, it works in neither 
 cases.  Attempting to dd from the drive results in a dd: /dev/da0: 
 Invalid argument.
 
 FYI: I had been experiencing the same with a 2 TB WD MyBook on OS X
 (Mavericks). The drive was being used for Time Machine backups, but it
 would at irregular intervals it would just 'disconnect' itself. My
 guess is that there's a firmware problem in the USB3 chip in those
 drives.
 
 After trying to get the issue fixed for almost half a year I returned
 it and replaced it by a Seagate, which has been working flawlessly
 ever since.
 
 I'm just saying, perhaps the problem isn't with FreeBSD but with the drive.


I'd love just to get to the randomly disconnects stage under FreeBSD at this 
point. :-)

Up to now, I have been unable to read ANY data off the drive under FreeBSD, 
either via USB 2 or USB 3. :-(

However, you have given me something to think about: does anyone know of a 4 TB 
USB 2 or 3 drive that will work reliably under FreeBSD 10-STABLE right now?

Cheers,

Paul.

___
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: pkg clean question

[Paul Mather]

On Aug 3, 2015, at 11:39 AM, Zoran Kolic zko...@sbb.rs wrote:

 Amd64, 9.3. Updated few times, packages also. At first I
 found on laptop that /var directory was at 102%. Using
 pkg clean i removed about 400mb of cache packages from
 /var/cache/pkg. Tried to clean desktop cache and the out-
 put of the command was nothing to do. I see about 400
 mb of files in the cache directory. Is it safe to remove
 them by the hand?


Use pkg clean -ay to delete all cached packages, not just the ones that are 
no longer current or provided by the upstream repository.

Cheers,

Paul.

___
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: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2

[Paul Mather]

On Aug 3, 2015, at 12:17 PM, Jack Vogel jfvo...@gmail.com wrote:
 
 Have you tried it on HEAD, and have you tried it on the same system with some
 recent flavor of Linux?

No, and no.  It's a good idea, though.  I can try it this weekend, if I can run 
each OS via a USB memstick.

With this being such a commonplace drive, I'd hoped someone might pipe up and 
say something along the lines of, oh, you have to add USB quirk XYZ to get 
that model working under FreeBSD.  No such luck, it seems.

Cheers,

Paul.

  
 
 Jack
 
 
 On Mon, Aug 3, 2015 at 8:35 AM, Paul Mather freebsd-li...@gromit.dlib.vt.edu 
 mailto:freebsd-li...@gromit.dlib.vt.edu wrote:
 On Aug 3, 2015, at 11:09 AM, Alban Hertroys haram...@gmail.com 
 mailto:haram...@gmail.com wrote:
 
  On 3 August 2015 at 15:01, Paul Mather freebsd-li...@gromit.dlib.vt.edu 
  mailto:freebsd-li...@gromit.dlib.vt.edu wrote:
  On Aug 2, 2015, at 9:34 PM, Adam McDougall mcdou...@egr.msu.edu 
  mailto:mcdou...@egr.msu.edu wrote:
 
  On 08/02/2015 21:22, Paul Mather wrote:
  I have a 4TB external USB drive (Western Digital My Book 1230) that I am 
  trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed 
  Jul 29 20:59:39 EDT 2015).  This system has a MSI 760GMA-P34 (FX) 
  motherboard.
 
  The drive probes unreliably when plugged in to a USB 3 port.  It 
  reliably probes when plugged into a USB 2 port.  However, it works in 
  neither cases.  Attempting to dd from the drive results in a dd: 
  /dev/da0: Invalid argument.
 
  FYI: I had been experiencing the same with a 2 TB WD MyBook on OS X
  (Mavericks). The drive was being used for Time Machine backups, but it
  would at irregular intervals it would just 'disconnect' itself. My
  guess is that there's a firmware problem in the USB3 chip in those
  drives.
 
  After trying to get the issue fixed for almost half a year I returned
  it and replaced it by a Seagate, which has been working flawlessly
  ever since.
 
  I'm just saying, perhaps the problem isn't with FreeBSD but with the drive.
 
 
 I'd love just to get to the randomly disconnects stage under FreeBSD at 
 this point. :-)
 
 Up to now, I have been unable to read ANY data off the drive under FreeBSD, 
 either via USB 2 or USB 3. :-(
 
 However, you have given me something to think about: does anyone know of a 4 
 TB USB 2 or 3 drive that will work reliably under FreeBSD 10-STABLE right now?
 
 Cheers,
 
 Paul.
 
 ___
 freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable 
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org 
 mailto: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: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2

[Paul Mather]

On Aug 2, 2015, at 9:34 PM, Adam McDougall mcdou...@egr.msu.edu wrote:

 On 08/02/2015 21:22, Paul Mather wrote:
 I have a 4TB external USB drive (Western Digital My Book 1230) that I am 
 trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed Jul 
 29 20:59:39 EDT 2015).  This system has a MSI 760GMA-P34 (FX) motherboard.
 
 The drive probes unreliably when plugged in to a USB 3 port.  It reliably 
 probes when plugged into a USB 2 port.  However, it works in neither cases.  
 Attempting to dd from the drive results in a dd: /dev/da0: Invalid 
 argument.
 
 When plugged in to a USB 2 port, this is how the drive is probed:
 
 ugen6.2: Western Digital at usbus6
 umass0: Western Digital My Book 1230, class 0/0, rev 2.10/10.65, addr 2 on 
 usbus6
 umass0:  SCSI over Bulk-Only; quirks = 0xc001
 umass0:9:0:-1: Attached to scbus9
 da0 at umass-sim0 bus 0 scbus9 target 0 lun 0
 da0: WD My Book 1230 1065 Fixed Direct Access SPC-4 SCSI device
 da0: Serial Number 57434334453056594A4C4A4A
 da0: 40.000MB/s transfers
 da0: 3815415MB (976746240 4096 byte sectors: 255H 63S/T 60799C)
 da0: quirks=0x2NO_6_BYTE
 ses0 at umass-sim0 bus 0 scbus9 target 0 lun 1
 ses0: WD SES Device 1065 Fixed Enclosure Services SPC-4 SCSI device
 ses0: Serial Number 57434334453056594A4C4A4A
 ses0: 40.000MB/s transfers
 ses0: SCSI-3 ENC Device
 
 When booting with it connected to a USB 3 port, this is what is output:
 
 xhci0: XHCI (generic) USB 3.0 controller mem 0xfeafe000-0xfeaf irq 18 
 at device 0.0 on pci3
 xhci0: 64 bytes context size, 64-bit DMA
 usbus0 on xhci0
 [[...]]
 ohci0: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fe000-0xfe7fefff irq 
 16 at device 18.0 on pci0
 usbus1 on ohci0
 ohci1: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fd000-0xfe7fdfff irq 
 16 at device 18.1 on pci0
 usbus2 on ohci1
 ehci0: AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller mem 0xfe7ff800-0xfe7ff8ff 
 irq 17 at device 18.2 on pci0
 usbus3: EHCI version 1.0
 usbus3 on ehci0
 ohci2: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fc000-0xfe7fcfff irq 
 18 at device 19.0 on pci0
 usbus4 on ohci2
 ohci3: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7f7000-0xfe7f7fff irq 
 18 at device 19.1 on pci0
 usbus5 on ohci3
 ehci1: AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller mem 0xfe7ff400-0xfe7ff4ff 
 irq 19 at device 19.2 on pci0
 usbus6: EHCI version 1.0
 usbus6 on ehci1
 [[...]]
 ohci4: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7f6000-0xfe7f6fff irq 
 18 at device 20.5 on pci0
 usbus7 on ohci4
 [[...]]
 usbus0: 5.0Gbps Super Speed USB v3.0
 usbus1: 12Mbps Full Speed USB v1.0
 usbus2: 12Mbps Full Speed USB v1.0
 usbus3: 480Mbps High Speed USB v2.0
 usbus4: 12Mbps Full Speed USB v1.0
 usbus5: 12Mbps Full Speed USB v1.0
 usbus6: 480Mbps High Speed USB v2.0
 usbus7: 12Mbps Full Speed USB v1.0
 ugen7.1: ATI at usbus7
 uhub0: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus7
 ugen6.1: ATI at usbus6
 uhub1: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus6
 ugen5.1: ATI at usbus5
 uhub2: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus5
 ugen4.1: ATI at usbus4
 uhub3: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus4
 ugen3.1: ATI at usbus3
 uhub4: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus3
 ugen2.1: ATI at usbus2
 uhub5: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
 ugen1.1: ATI at usbus1
 uhub6: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
 ugen0.1: 0x1912 at usbus0
 uhub7: 0x1912 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1 on usbus0
 uhub0: 2 ports with 2 removable, self powered
 uhub2: 3 ports with 3 removable, self powered
 uhub3: 3 ports with 3 removable, self powered
 uhub5: 3 ports with 3 removable, self powered
 uhub6: 3 ports with 3 removable, self powered
 uhub7: 8 ports with 8 removable, self powered
 [[...]]
 Root mount waiting for: usbus6 usbus3 usbus0
 Root mount waiting for: usbus6 usbus3 usbus0
 uhub1: 6 ports with 6 removable, self powered
 uhub4: 6 ports with 6 removable, self powered
 ugen0.2: vendor 0x1058 at usbus0
 umass0: vendor 0x1058 product 0x1230, class 0/0, rev 3.00/10.65, addr 1 on 
 usbus0
 umass0:  SCSI over Bulk-Only; quirks = 0x8000
 Root mount waiting for: usbus0
 [[...]]
 Root mount waiting for: usbus0
 Root mount waiting for: usbus0
 umass0: Get Max Lun not supported (USB_ERR_TIMEOUT)
 umass0:9:0:-1: Attached to scbus9
 [[...]]
 da0 at umass-sim0 bus 0 scbus9 target 0 lun 0
 da0:Fixed Direct Access SCSI device
 da0: Serial Number WCC4E0VYJLJJ
 da0: 400.000MB/s transfers
 da0: 3815415MB (976746240 4096 byte sectors: 255H 63S/T 60799C)
 da0: quirks=0x2NO_6_BYTE
 
 
 This external USB drive works fine under OSX Yosemite and also when plugged 
 in to my Raspberry Pi 2 running OSMC.
 
 Is there anyone using this model of USB drive under FreeBSD/amd64 10.2?  Is 
 it a matter of finding the correct quirk to get it working?
 
 Cheers,
 
 Paul.
 
 The trouble detecting is probably related to
 https://bugs.freebsd.org

4TB Western Digital My Book 1230 USB hard drive not working on 10.2

[Paul Mather]

I have a 4TB external USB drive (Western Digital My Book 1230) that I am trying 
to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed Jul 29 
20:59:39 EDT 2015).  This system has a MSI 760GMA-P34 (FX) motherboard.

The drive probes unreliably when plugged in to a USB 3 port.  It reliably 
probes when plugged into a USB 2 port.  However, it works in neither cases.  
Attempting to dd from the drive results in a dd: /dev/da0: Invalid argument.

When plugged in to a USB 2 port, this is how the drive is probed:

ugen6.2: Western Digital at usbus6
umass0: Western Digital My Book 1230, class 0/0, rev 2.10/10.65, addr 2 on 
usbus6
umass0:  SCSI over Bulk-Only; quirks = 0xc001
umass0:9:0:-1: Attached to scbus9
da0 at umass-sim0 bus 0 scbus9 target 0 lun 0
da0: WD My Book 1230 1065 Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 57434334453056594A4C4A4A
da0: 40.000MB/s transfers
da0: 3815415MB (976746240 4096 byte sectors: 255H 63S/T 60799C)
da0: quirks=0x2NO_6_BYTE
ses0 at umass-sim0 bus 0 scbus9 target 0 lun 1
ses0: WD SES Device 1065 Fixed Enclosure Services SPC-4 SCSI device
ses0: Serial Number 57434334453056594A4C4A4A
ses0: 40.000MB/s transfers
ses0: SCSI-3 ENC Device

When booting with it connected to a USB 3 port, this is what is output:

xhci0: XHCI (generic) USB 3.0 controller mem 0xfeafe000-0xfeaf irq 18 at 
device 0.0 on pci3
xhci0: 64 bytes context size, 64-bit DMA
usbus0 on xhci0
[[...]]
ohci0: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fe000-0xfe7fefff irq 16 
at device 18.0 on pci0
usbus1 on ohci0
ohci1: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fd000-0xfe7fdfff irq 16 
at device 18.1 on pci0
usbus2 on ohci1
ehci0: AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller mem 0xfe7ff800-0xfe7ff8ff irq 
17 at device 18.2 on pci0
usbus3: EHCI version 1.0
usbus3 on ehci0
ohci2: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7fc000-0xfe7fcfff irq 18 
at device 19.0 on pci0
usbus4 on ohci2
ohci3: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7f7000-0xfe7f7fff irq 18 
at device 19.1 on pci0
usbus5 on ohci3
ehci1: AMD SB7x0/SB8x0/SB9x0 USB 2.0 controller mem 0xfe7ff400-0xfe7ff4ff irq 
19 at device 19.2 on pci0
usbus6: EHCI version 1.0
usbus6 on ehci1
[[...]]
ohci4: AMD SB7x0/SB8x0/SB9x0 USB controller mem 0xfe7f6000-0xfe7f6fff irq 18 
at device 20.5 on pci0
usbus7 on ohci4
[[...]]
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 12Mbps Full Speed USB v1.0
usbus3: 480Mbps High Speed USB v2.0
usbus4: 12Mbps Full Speed USB v1.0
usbus5: 12Mbps Full Speed USB v1.0
usbus6: 480Mbps High Speed USB v2.0
usbus7: 12Mbps Full Speed USB v1.0
ugen7.1: ATI at usbus7
uhub0: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus7
ugen6.1: ATI at usbus6
uhub1: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus6
ugen5.1: ATI at usbus5
uhub2: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus5
ugen4.1: ATI at usbus4
uhub3: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus4
ugen3.1: ATI at usbus3
uhub4: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus3
ugen2.1: ATI at usbus2
uhub5: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2
ugen1.1: ATI at usbus1
uhub6: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
ugen0.1: 0x1912 at usbus0
uhub7: 0x1912 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1 on usbus0
uhub0: 2 ports with 2 removable, self powered
uhub2: 3 ports with 3 removable, self powered
uhub3: 3 ports with 3 removable, self powered
uhub5: 3 ports with 3 removable, self powered
uhub6: 3 ports with 3 removable, self powered
uhub7: 8 ports with 8 removable, self powered
[[...]]
Root mount waiting for: usbus6 usbus3 usbus0
Root mount waiting for: usbus6 usbus3 usbus0
uhub1: 6 ports with 6 removable, self powered
uhub4: 6 ports with 6 removable, self powered
ugen0.2: vendor 0x1058 at usbus0
umass0: vendor 0x1058 product 0x1230, class 0/0, rev 3.00/10.65, addr 1 on 
usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x8000
Root mount waiting for: usbus0
[[...]]
Root mount waiting for: usbus0
Root mount waiting for: usbus0
umass0: Get Max Lun not supported (USB_ERR_TIMEOUT)
umass0:9:0:-1: Attached to scbus9
[[...]]
da0 at umass-sim0 bus 0 scbus9 target 0 lun 0
da0:Fixed Direct Access SCSI device
da0: Serial Number WCC4E0VYJLJJ
da0: 400.000MB/s transfers
da0: 3815415MB (976746240 4096 byte sectors: 255H 63S/T 60799C)
da0: quirks=0x2NO_6_BYTE


This external USB drive works fine under OSX Yosemite and also when plugged in 
to my Raspberry Pi 2 running OSMC.

Is there anyone using this model of USB drive under FreeBSD/amd64 10.2?  Is it 
a matter of finding the correct quirk to get it working?

Cheers,

Paul.



___
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

10.2-RC1/STABLE VIMAGE memory leak progress?

[Paul Mather]

I'm running 10-STABLE (which currently identifies itself as 10.2-PRERELEASE) 
and lately I've started experimenting with using iocage for Jail management.  
(I really like it so far.)  In particular, I've been trying out iocage's 
support for VNET networking that relies on VIMAGE and uses bridge and epair for 
the network.

I find that when I stop a VNET Jail using iocage that I get something akin to 
the following in my console logs:

=
Jul 27 10:59:47 chumby kernel: vnet0:1: link state changed to DOWN
Jul 27 10:59:47 chumby kernel: vnet0: link state changed to DOWN
Jul 27 10:59:47 chumby kernel: re0: link state changed to DOWN
Jul 27 10:59:47 chumby kernel: bridge0: link state changed to DOWN
Jul 27 10:59:47 chumby kernel: vnet1:1: link state changed to DOWN
Jul 27 10:59:47 chumby kernel: vnet1: link state changed to DOWN
Jul 27 10:59:47 chumby kernel: bridge1: link state changed to DOWN
Jul 27 10:59:47 chumby kernel: ifa_del_loopback_route: deletion failed: 48
Jul 27 10:59:47 chumby kernel: Freed UMA keg (udp_inpcb) was not empty (120 
items).  Lost 12 pages of memory.
Jul 27 10:59:47 chumby kernel: Freed UMA keg (udpcb) was not empty (1169 
items).  Lost 7 pages of memory.
Jul 27 10:59:47 chumby kernel: hhook_vnet_uninit: hhook_head type=1, id=1 
cleanup required
Jul 27 10:59:47 chumby kernel: hhook_vnet_uninit: hhook_head type=1, id=0 
cleanup required
=

I found a PR (kern/164763) dating back to 2012-02-04 describing the problem.  
The last update on that PR was on 2014-10-17, which made reference to some 
unmerged fixes that would be good to merge into HEAD.

Does anyone know whether this was done?

One of the entries in that PR states, Our current rule of thumb is 'if you 
need to shutdown one vimage jail then you need to reboot the host.'  It then 
goes on to observe, Of course this is far from optimal.

Is it safe to say, then, that dynamic VNET Jails are not recommended still 
under FreeBSD?

Judging by that PR, this is not likely to be fixed for 10.2-RELEASE?

Cheers,

Paul.


___
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: Circular dependency between local_unbound and ntpd?

[Paul Mather]

On Jul 14, 2015, at 10:33 AM, krad kra...@gmail.com wrote:
 
 As
 
 $ grep REQUIRE /etc/rc.d/ntpd
 # REQUIRE: DAEMON ntpdate FILESYSTEMS devfs
 
 
 You could set something similar to the following in the rc.conf
 
 ntpdate_hosts=a.b.c.d w.x.y.z
 ntpdate_enable=yes

Thanks for that suggestion.  I assume the a.b.c.d w.x.y.z are IP addresses, 
not hostnames, otherwise we'd have the same problem.

The /etc/rc.d/ntpdate startup script has a REQUIRE: NETWORKING ... and 
/etc/rc.d/local_unbound has a BEFORE: NETWORKING in it, meaning it will be 
running before ntpdate runs.  That means DNS resolution will require an 
accurate clock and, I assume, mean that ntpdate will require IP addresses, too?

So, it still comes down to this: do I need to know the IP address of an NTP 
server to be able to use local_unbound safely with NTP?

Cheers,

Paul.


 
 
 
 
 On 14 July 2015 at 14:43, Paul Mather p...@gromit.dlib.vt.edu 
 mailto:p...@gromit.dlib.vt.edu wrote:
 I believe I ran afoul of a circular dependency between local_unbound and ntpd 
 on my 10.2-PRERELEASE system.  I use a stock /etc/ntp.conf and use 
 ntpd_sync_on_start=YES.
 
 Last night, a BIOS settings reset cause my CMOS clock to go WAY out of synch 
 for the first time.  No problem, I thought: NTP will correct it at boot.
 
 Wrong!
 
 When my system booted, the time was not corrected.  Also, DNS resolution was 
 not working.  I figured out it was because local_unbound relies on an 
 accurately set clock, but the clock could not be set accurately because my 
 stock ntp.conf requires working DNS resolution to reach the NTP servers.
 
 That sounds like a potential circular dependency to me.
 
 My workaround at the time was to look up 0.freebsd.pool.ntp.org 
 http://0.freebsd.pool.ntp.org/ on another system; stop ntpd; then do a 
 ntpdate using the IP addresses to set the clock. Once the clock was set 
 accurately, things were all hunky dory.
 
 Does anyone have any suggestion for an automatic way around this?  I guess 
 one way would be to put the IP address of an NTP server into my ntp.conf 
 file, so at least one would be reachable without needing a working DNS?
 
 My main concern is for those systems like my Raspberry Pi and Beaglebone 
 Black that don't have a battery-backed clock.  I currently don't use 
 local_unbound on those, but it seems like I'd encounter this problem 
 routinely if I did.
 
 Cheers,
 
 Paul.
 ___
 freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable 
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org 
 mailto: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

Circular dependency between local_unbound and ntpd?

[Paul Mather]

I believe I ran afoul of a circular dependency between local_unbound and ntpd 
on my 10.2-PRERELEASE system.  I use a stock /etc/ntp.conf and use 
ntpd_sync_on_start=YES.

Last night, a BIOS settings reset cause my CMOS clock to go WAY out of synch 
for the first time.  No problem, I thought: NTP will correct it at boot.

Wrong!

When my system booted, the time was not corrected.  Also, DNS resolution was 
not working.  I figured out it was because local_unbound relies on an 
accurately set clock, but the clock could not be set accurately because my 
stock ntp.conf requires working DNS resolution to reach the NTP servers.

That sounds like a potential circular dependency to me.

My workaround at the time was to look up 0.freebsd.pool.ntp.org on another 
system; stop ntpd; then do a ntpdate using the IP addresses to set the clock. 
Once the clock was set accurately, things were all hunky dory.

Does anyone have any suggestion for an automatic way around this?  I guess one 
way would be to put the IP address of an NTP server into my ntp.conf file, so 
at least one would be reachable without needing a working DNS?

My main concern is for those systems like my Raspberry Pi and Beaglebone Black 
that don't have a battery-backed clock.  I currently don't use local_unbound on 
those, but it seems like I'd encounter this problem routinely if I did.

Cheers,

Paul.
___
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, cam sticking on failed disk

[Paul Mather]

On May 7, 2015, at 8:00 AM, Steven Hartland kill...@multiplay.co.uk wrote:

 On 07/05/2015 11:46, Slawa Olhovchenkov wrote:
 On Thu, May 07, 2015 at 11:38:46AM +0100, Steven Hartland wrote:
 
 How I can cancel this 24 requst?
 Why this requests don't timeout (3 hours already)?
 How I can forced detach this disk? (I am lready try `camcontrol reset`, 
 `camconrol rescan`).
 Why ZFS (or geom) don't timeout on request and don't rerouted to da18?
 
 If they are in mirrors, in theory you can just pull the disk, isci will
 report to cam and cam will report to ZFS which should all recover.
 Yes, zmirror with da18.
 I am surprise that ZFS don't use da18. All zpool fully stuck.
 A single low level request can only be handled by one device, if that
 device returns an error then ZFS will use the other device, but not until.
 Why next requests don't routed to da18?
 Current request stuck on da19 (unlikely, but understund), but why
 stuck all pool?
 
 Its still waiting for the request from the failed device to complete. As far 
 as ZFS currently knows there is nothing wrong with the device as its had no 
 failures.


Maybe related to this, but if the drive stalls indefinitely, is it what leads 
to the panic: I/O to pool 'poolname' appears to be hung on vdev guid GUID-ID 
at '/dev/somedevice'.?

I have a 6-disk RAIDZ2 pool that is used for nightly rsync backups from various 
systems.  I believe one of the drives is a bit temperamental.  Very 
occasionally, I discover the backup has failed and the machine actually paniced 
because of this drive, with a panic message like the above.  The panic 
backtrace includes references to vdev_deadman, which sounds like some sort of 
dead man's switch/watchdog.

It's a bit counter-intuitive that a single drive wandering off into la-la land 
can not only cause an entire ZFS pool to wedge, but, worse still, panic the 
whole machine.

If I'm understanding this thread correctly, part of the problem is that an I/O 
never completing is not the same as a failure to ZFS, and hence ZFS can't call 
upon various resources in the pool and mechanisms at its disposal to correct 
for that.  Is that accurate?

I would think that never-ending I/O requests would be a type of failure that 
ZFS could sustain.  It seems from the hung on vdev panic that it does detect 
this situation, though the resolution (panic) is not ideal. :-)

Cheers,

Paul.
___
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: protecting some processes from out-of-swap killer

[Paul Mather]

On Apr 28, 2015, at 5:51 AM, Ronald Klop ronald-li...@klop.ws wrote:

 On Sat, 25 Apr 2015 13:15:32 +0200, Dmitry Morozovsky ma...@rinet.ru wrote:
 
 On Sat, 25 Apr 2015, Baptiste Daroussin wrote:
 
  However, sometimes postgres processes got killed by 'out of swap space'.
  I suppose the source of problem could be that VSZ size of postgres 
  processes
  (8-9 G) is bigger than swap congigured (4G).
 
  Is there any way to prevent this, besides reallocating space for swap?
 
 protect(1) ?
 
 Of course.  I really do not understand how google hides the man page from me.
 
 Thanks, and sorry fot the noise.
 
 
 
 The OS trying to kill a process is probably not what you want. So when you 
 protect(1) postgres the OS will kill another process, which I hope is not 
 running without reason.
 My advice would be to
 - or increase your swap space
 - or tune postgresql to use less memory
 - or limit tmpfs (tmpfs uses swap if RAM is short)
 - or tune zfs to use less memory


That is good advice, although I do think protect has its place for preventing 
unforeseen accidents as mentioned above.  I believe it's good to be able to 
designate certain processes as more valuable than others if you know that to be 
the case.

A case in point: We have an Omeka instance on a fairly low-resource system.  
Omeka uses ImageMagick to generate thumbnails for items added to collections.  
In one case, we had a very large TIFF file added, who, when having a thumbnail 
generated, caused its thumbnail-generating process to consume large amounts of 
memory and swap.  When swap was exhausted, the OS decided it needed to kill off 
something and settled upon Apache (under which Omeka runs), causing Omeka to 
stop running.  In other times, the out-of-swap killer has chosen to kill the 
SSH daemon, making it harder subsequently to access the box and fix problems.

Being able to protect httpd---or even just sshd---served as a handy safety belt 
after that happened. :-)

I guess the proper way to address this would be to set limits on Apache or the 
thumbnail generation so it doesn't go hog wild in the future...

Cheers,

Paul.

___
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

Enabling pf in 9-STABLE guest on KVM triggers abrt crash report

[Paul Mather]

I have been using 9-STABLE as a guest under KVM on RHEL 6 for several months 
now without incident.  I am using the virtio drivers and using bridged 
networking on the host to attach my guests.

Recently, I enabled pf in one of my 9-STABLE (r253579) guests and subsequently 
started to receive intermittent crash reports from abrt on the KVM host.  Has 
anyone else encountered problems using pf under KVM virtualisation?

A typical crash report from the host goes like this:

=
abrt_version:   2.0.8
cmdline:ro root=/dev/mapper/chumby-root rd_LVM_LV=chumby/root 
rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=chumby/swap SYSFONT=latarcyrheb-sun16 
crashkernel=137M@0M rd_MD_UUID=b7338ac5:b08fdc1b:34d0fcf1:cf28da17  
KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet console=tty0 
console=ttyS1,115200
kernel: 2.6.32-358.14.1.el6.x86_64
not-reportable: A kernel problem occurred, but your kernel has been tainted 
(flags:GW  ). Kernel maintainers are unable to diagnose tainted reports.
time:   Wed 07 Aug 2013 11:41:22 AM EDT

sosreport.tar.xz: Binary file, 2114408 bytes

backtrace:
:WARNING: at net/core/dev.c:1759 skb_gso_segment+0x1df/0x2b0() (Tainted: G  
  W  --- )
:Hardware name: AX1204-819-R700UB
:igb: caps=(0x12114bb3, 0x0) len=2084 data_len=0 ip_summed=0
:Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 
iptable_filter ip_tables ebtable_nat ebtables xt_CHECKSUM cpufreq_ondemand 
powernow_k8 freq_table mperf bridge stp llc ipt_REJECT ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter 
ip6_tables ipv6 ext2 vhost_net macvtap macvlan tun kvm_amd kvm igb dca ptp 
pps_core microcode sg serio_raw fam15h_power k10temp amd64_edac_mod edac_core 
edac_mce_amd i2c_piix4 i2c_core shpchp ext4 mbcache jbd2 raid1 sr_mod cdrom 
sd_mod crc_t10dif pata_acpi ata_generic pata_atiixp ahci dm_mirror 
dm_region_hash dm_log dm_mod [last unloaded: nf_defrag_ipv4]
:Pid: 3262, comm: vhost-3242 Tainted: GW  ---
2.6.32-358.14.1.el6.x86_64 #1
:Call Trace:
:IRQ  [8106e307] ? warn_slowpath_common+0x87/0xc0
:[8106e3f6] ? warn_slowpath_fmt+0x46/0x50
:[a01b7d62] ? igb_get_drvinfo+0x82/0xe0 [igb]
:[81448c2f] ? skb_gso_segment+0x1df/0x2b0
:[81449010] ? dev_hard_start_xmit+0x1b0/0x530
:[814674ea] ? sch_direct_xmit+0x15a/0x1c0
:[8144ce70] ? dev_queue_xmit+0x3b0/0x550
:[a02fd64c] ? br_dev_queue_push_xmit+0x6c/0xa0 [bridge]
:[a02fd6d8] ? br_forward_finish+0x58/0x60 [bridge]
:[a02fd78a] ? __br_forward+0xaa/0xd0 [bridge]
:[81474ce4] ? nf_hook_slow+0x74/0x110
:[a02fd80d] ? br_forward+0x5d/0x70 [bridge]
:[a02fe5e9] ? br_handle_frame_finish+0x179/0x2a0 [bridge]
:[81063536] ? rebalance_domains+0x1a6/0x5a0
:[a02fe8ba] ? br_handle_frame+0x1aa/0x250 [bridge]
:[814486d9] ? __netif_receive_skb+0x529/0x750
:[8144899a] ? process_backlog+0x9a/0x100
:[8144d203] ? net_rx_action+0x103/0x2f0
:[81076fd1] ? __do_softirq+0xc1/0x1e0
:[8100c1cc] ? call_softirq+0x1c/0x30
:[8100c1cc] ? call_softirq+0x1c/0x30
:EOI  [8100de05] ? do_softirq+0x65/0xa0
:[8144d688] ? netif_rx_ni+0x28/0x30
:[a0079739] ? tun_sendmsg+0x229/0x4ec [tun]
:[a024acf5] ? handle_tx+0x275/0x5e0 [vhost_net]
:[a024b095] ? handle_tx_kick+0x15/0x20 [vhost_net]
:[a024855c] ? vhost_worker+0xbc/0x140 [vhost_net]
:[a02484a0] ? vhost_worker+0x0/0x140 [vhost_net]
:[81096956] ? kthread+0x96/0xa0
:[8100c0ca] ? child_rip+0xa/0x20
:[810968c0] ? kthread+0x0/0xa0
:[8100c0c0] ? child_rip+0x0/0x20
=

I get these crash reports even with a simple firewall rule set like this:

=
#   $FreeBSD: stable/9/share/examples/pf/pf.conf 218854 2011-02-19 
14:57:00Z brucec $
#   $OpenBSD: pf.conf,v 1.34 2007/02/24 19:30:59 millert Exp $
#
# See pf.conf(5) and /usr/share/examples/pf for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.

ext_if=vtnet0

set skip on lo

scrub in

block in
pass out

pass in on $ext_if proto tcp to ($ext_if) port ssh
pass in on $ext_if inet proto icmp from any to ($ext_if) icmp-type { unreach, 
redir, timex }
=

Does anyone know of any problems using pf with the virtio vtnet driver, or 
indeed in using pf at all under KVM virtualisation?  For now, I've turned off 
pf, but I would like to be able to enable it in future to do firewalling on the 
virtual guest.  I have no problems using iptables for firewalling on my Linux 
KVM guests.

Cheers,

Paul.
___
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 Panic after freebsd-update

[Paul Mather]

On Jul 1, 2013, at 11:49 AM, Jeremy Chadwick j...@koitsu.org wrote:

 On Mon, Jul 01, 2013 at 11:35:30AM -0400, Scott Sipe wrote:
 *** Sorry for partial first message! (gmail sent after multiple returns
 apparently?) ***
 
 Hello,
 
 I have not had much time to research this problem yet, so please let me
 know what further information I might be able to provide.
 [[...]]
 Any thoughts?
 
 Thoughts:
 
 [[..]]
 Of course when I see lines like this:
 
  Trying to mount root from zfs:zroot
 
  ...this greatly diminishes any chances of live debugging on the
  system.  It amazes me how often I see this come up on the lists -- people
  who have ZFS problems but use ZFS for their root/var/tmp/usr.  I wish
  that behaviour would stop, as it makes debugging ZFS a serious PITA.
  This comes up on the list almost constantly, sad panda.


I'm not sure why it amazes you that people are making widespread use of ZFS.  
You could make the same argument that people shouldn't use UFS2 journaling on 
their file systems because bugs in the implementation might make debugging 
journaled UFS2 file systems a serious PITA.  The point is that there are VERY 
compelling reasons why people might want to use ZFS for root/var/tmp/usr/etc. 
(pooled storage; easy snapshots; etc.) and there should come a time when a 
given file system is generally regarded as safe.  I'd say the time for ZFS 
came when they removed the big disclaimer from the boot messages.  If ZFS is 
dangerous, they should reinstate the not ready for production warning.  Until 
they do, I think it's unfair to castigate people for using ZFS universally.

Isn't it a recurring theme on freebsd-current and freebsd-stable that more 
people need to use features so they can be debugged in realistic environments?  
If you're telling them, don't use that because it makes debugging harder, how 
are they supposed to get debugged and hence improved? :-)

Cheers,

Paul.
___
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: Virtio and GEOM labels

[Paul Mather]

On Mar 25, 2013, at 1:46 PM, John Nielsen li...@jnielsen.net wrote:

 On Mar 22, 2013, at 8:14 AM, Paul Mather p...@gromit.dlib.vt.edu wrote:
 
 I'm running FreeBSD 9-STABLE as a guest under RHEL 6.4 KVM virtualisation.  
 I have networking and storage in the FreeBSD guest using the Virtio drivers 
 (with the virtual disk set to Virtio in the definition on the host).  
 Everything is working nicely: I have a vtnet network adapter and see vtbd 
 devices for my virtual disks in FreeBSD.  Performance is much better 
 compared with an emulated IDE device.
 
 I've had the same experience.
 
 The odd thing is that I don't see GEOM labels reflected in /dev.  For 
 example, I have GPT labels defined in the guest, but I don't see them show 
 up under /dev/gpt.  Similarly, my UFS labels don't show up under /dev/ufs.  
 I *do* see a /dev/gptid.  That appears to be the only label that shows up.
 
 I have not encountered this issue. I use virtio block devices and GPT labels 
 exclusively in multiple FreeBSD 9.1 guests and all mount/function without 
 issue. How are you referring to your filesystems in /etc/fstab? IIRC GEOM 
 makes not-in-use labels disappear when a device is in use (e.g. mounted). If 
 you take a new device, put a labeled GPT partition on it and a labeled UFS 
 partition on that but don't mount anything, what happens?


Thanks for the reply.

My apologies: this is a case of pilot error on my part.  I was mounting the 
devices as /dev/vtbd...  I hadn't realised that the present-but-unused labels 
were being suppressed when the device was mounted.  Has this always been the 
case?  For some reason I had a distinct recollection stuck in my mind that all 
labels showed up in /dev.

Anyway, many thanks for pointing the way to the solution.  I now have GPT- and 
UFS-labelled devices mounted in my FreeBSD guest system.


 
 Is there something special I need to do to get GPT and UFS labels to appear 
 when using Virtio?  It seems to me that Virtio block devices appear to be 
 somewhat unusual.  Unlike regular ATA and SCSI devices, my vtbd devices 
 don't appear in the boot dmesg (although a vtblk device does), and 
 camcontrol devlist does not list them.  It's not clear to me how I am 
 supposed to interact with them other than via basic device I/O through 
 /dev/vtbdX.  I thought that the virtio_scsi module might make them appear as 
 da devices and able to interacted with via camcontrol, but this doesn't 
 seem to be the case.
 
 Virtio block devices and virtio SCSI devices are not the same. If you want to 
 use the virtio_scsi module in FreeBSD you should expose a virtio SCSI device 
 from the host.


Thank you for the explanation.  I've been using virt-manager up to now for 
setting up KVM guests and it seems that virtio-scsi isn't exposed through that 
interface---only through the command line.  I'll have to investigate...

Cheers,

Paul.

___
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

Virtio and GEOM labels

[Paul Mather]

I'm running FreeBSD 9-STABLE as a guest under RHEL 6.4 KVM virtualisation.  I 
have networking and storage in the FreeBSD guest using the Virtio drivers (with 
the virtual disk set to Virtio in the definition on the host).  Everything is 
working nicely: I have a vtnet network adapter and see vtbd devices for my 
virtual disks in FreeBSD.  Performance is much better compared with an emulated 
IDE device.

The odd thing is that I don't see GEOM labels reflected in /dev.  For example, 
I have GPT labels defined in the guest, but I don't see them show up under 
/dev/gpt.  Similarly, my UFS labels don't show up under /dev/ufs.  I *do* see a 
/dev/gptid.  That appears to be the only label that shows up.

Is there something special I need to do to get GPT and UFS labels to appear 
when using Virtio?  It seems to me that Virtio block devices appear to be 
somewhat unusual.  Unlike regular ATA and SCSI devices, my vtbd devices don't 
appear in the boot dmesg (although a vtblk device does), and camcontrol 
devlist does not list them.  It's not clear to me how I am supposed to 
interact with them other than via basic device I/O through /dev/vtbdX.  I 
thought that the virtio_scsi module might make them appear as da devices and 
able to interacted with via camcontrol, but this doesn't seem to be the case.

I've included my system dmesg at the end of this message.

Cheers,

Paul.

=
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.1-STABLE #0 r248465: Mon Mar 18 11:19:23 EDT 2013
pmat...@freebsd9.virtual.lib.vt.edu:/usr/obj/usr/src/sys/KVMTEST amd64
FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221
CPU: QEMU Virtual CPU version (cpu64-rhel6) (2100.15-MHz K8-class CPU)
  Origin = AuthenticAMD  Id = 0x6d3  Family = 0x6  Model = 0xd  Stepping = 3
  
Features=0x783f3ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2
  Features2=0x80002001SSE3,CX16,HV
  AMD Features=0x22500800SYSCALL,NX,MMX+,FFXSR,LM
  AMD Features2=0x73LAHF,CMP,CR8,ABM,SSE4A
real memory  = 8589934592 (8192 MB)
avail memory = 8255410176 (7872 MB)
Event timer LAPIC quality 400
ACPI APIC Table: BOCHS  BXPCAPIC
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 Version 1.1 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: BOCHS BXPCRSDT on motherboard
acpi0: Power Button (fixed)
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0
Event timer RTC frequency 32768 Hz quality 0
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 24-bit timer at 3.579545MHz port 0xb008-0xb00b on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci_link4: Unable to route IRQs: AE_NOT_FOUND
isab0: PCI-ISA bridge at device 1.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX3 WDMA2 controller port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0
ata0: ATA channel at channel 0 on atapci0
ata1: ATA channel at channel 1 on atapci0
uhci0: Intel 82371SB (PIIX3) USB controller port 0xc020-0xc03f irq 11 at 
device 1.2 on pci0
usbus0: controller did not stop
usbus0 on uhci0
pci0: bridge at device 1.3 (no driver attached)
vgapci0: VGA-compatible display mem 
0xf000-0xf1ff,0xf200-0xf2000fff at device 2.0 on pci0
virtio_pci0: VirtIO PCI Network adapter port 0xc040-0xc05f mem 
0xf202-0xf2020fff irq 11 at device 3.0 on pci0
vtnet0: VirtIO Networking Adapter on virtio_pci0
virtio_pci0: host features: 0x711fffe3 
EventIdx,RingIndirect,NotifyOnEmpty,RxModeExtra,VLanFilter,RxMode,ControlVq,Status,MrgRxBuf,TxUFO,TxTSOECN,TxTSOv6,TxTSOv4,RxUFO,RxECN,RxTSOv6,RxTSOv4,TxAllGSO,MacAddress,RxChecksum,TxChecksum
virtio_pci0: negotiated features: 0x110fbba3 
RingIndirect,NotifyOnEmpty,VLanFilter,RxMode,ControlVq,Status,MrgRxBuf,TxTSOECN,TxTSOv6,TxTSOv4,RxECN,RxTSOv6,RxTSOv4,MacAddress,RxChecksum,TxChecksum
vtnet0: Ethernet address: 52:54:00:3e:48:94
virtio_pci1: VirtIO PCI Balloon adapter port 0xc060-0xc07f irq 10 at device 
5.0 on pci0
vtballoon0: VirtIO Balloon Adapter on virtio_pci1
virtio_pci1: host features: 0x7102 
EventIdx,RingIndirect,NotifyOnEmpty,StatsVq
virtio_pci1: negotiated features: 0x0
virtio_pci2: VirtIO PCI Block adapter port 0xc080-0xc0bf mem 
0xf204-0xf2040fff irq 10 at device 6.0 on pci0
vtblk0: VirtIO Block Adapter on virtio_pci2
virtio_pci2: host features: 0x71000654 
EventIdx,RingIndirect,NotifyOnEmpty,Topology,FlushCmd,BlockSize,DiskGeometry,MaxNumSegs
virtio_pci2: negotiated features: 0x1254 
RingIndirect,FlushCmd,BlockSize,DiskGeometry,MaxNumSegs
vtblk0: 8192MB (16777216 512 byte sectors)
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on 

Re: IPMI serial console

[Paul Mather]

On Feb 21, 2013, at 11:29 PM, Jeremy Chadwick j...@koitsu.org wrote:

 On Fri, Feb 22, 2013 at 02:22:52PM +1030, Daniel O'Connor wrote:
 On 22/02/2013, at 12:02, Jeremy Chadwick j...@koitsu.org wrote:
 Hmm I tried putting '-S 115200' in /boot.config and it broke - the boot 
 process didn't run the loader (or kernel).
 
 I'll talk a bit about this -- again, sorry for the verbosity.  I'll
 explain what I've historically used/done, then speculate a bit about
 your IPMI stuff:
 
 For me, on systems without IPMI, all I had to do was this (and nothing
 else):
 
 * Put the following in /boot.config:
 
 -S115200 -Dh
 
 This breaks the boot for me, boot.config has to contain more than just
 flags it seems. In any case I believe setting boot_multicons and
 boot_serial is the same as -Dh. Not sure about the baud rate though.
 
 Then someone broke something (parser or something else).  This has
 always, *always* worked (just flags).  The last time I verified it was
 with the release of 9.0-RELEASE.  I do have a system I could test this
 on, but I'd need to find a null modem cable first.
 
 I have seen some MFCs that touch those bits in the bootloader, but from
 my memory it didn't touch anything other than supporting /boot/config as
 an alternate location to the classic /boot.config file.  I would be very
 surprised if this broke it.
 
 I can assure you that those were the only flags that were needed, and in
 exactly that syntax.  Even the Handbook has this in it, as well as
 boot(8).
 
 I believe your explanation of boot_multicons and boot_serial are correct
 and do correlate with -D and -h.  I could look at the bootstrap code to
 verify.  The options are described in loader(8) but not loader.conf(5).


I think something did break back at the start of the year that caused 
/boot.config contents to render the system completely unbootable.  At least 
that is what happened to me on RELENG_8: 
http://lists.freebsd.org/pipermail/freebsd-stable/2013-January/071579.html

Bruce A. Mah reports later in the same thread that his happened to him on 
8.3-RELEASE.  I don't know if this was fixed.

Cheers,

Paul.
___
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: IPMI serial console

[Paul Mather]

On Feb 21, 2013, at 7:14 PM, Daniel O'Connor docon...@gsoft.com.au wrote:

 
 On 22/02/2013, at 10:40, Jeremy Chadwick j...@koitsu.org wrote:
 X9SIL-F BIOS version 1.1 (05/27/10)
 IPMI firmware is 2.01.
 
 I can't find this motherboard listed on Supermicro's site.
 
 kenv | grep smbios output please?
 
 
 Sorry, brainfart, it's an X8SIL-F 
 http://www.supermicro.com/xeon_3400/Motherboard/X8SIL.cfm?IPMI=Y


I am also using that motherboard and currently IPMI is working for me under 
9.1-STABLE (r246366).  My system has BIOS version 1.2 and IPMI firmware version 
2.66.  I have both the VGA KVM console and SOL console working (though the VGA 
console seems sensitive to the version of Java you have installed). I am using 
sysutils/ipmitool to access the system via IPMI SOL console.

Here is what my IPMI SOL setup looks like in the BIOS setup screen:

  Advanced  

* Advanced - Remote Access Configuration  * Select Remote Access   *
* *** * type.  *
* Remote Access  [Enabled]**
* **
* Serial Port Number [COM3 *] **
*  Base Address, IRQ [3E8h, 5]**
* Serial Port Mode   [115200 8,n,1]   **
* Flow Control   [None]   **
* Redirection After BIOS POST[Always] **
* Terminal Type  [ANSI]   **
* VT-UTF8 Combo Key Support  [Enabled]**
* Sredir Memory Display Delay[No Delay]   **
* *   :Move*
* *   Enter:Select *
* *   +/-/:Value   *
* *   F10:Save *
* *   ESC:Exit *
* *   F1:General Help  *
* *   F8:Fail-Safe Defaults*
* *   F9:Optimized Defaults*



Here is what I have in /boot/loader.conf regarding a serial console:

=
# Enable IPMI serial console
#console=comconsole
# Give preference to VGA console
console=vidconsole,comconsole
# Uncomment below and comment above to give serial console preference
#console=comconsole,vidconsole
comconsole_speed=115200
boot_multicons=YES
hint.uart.0.flags=0x0
hint.uart.2.at=isa
hint.uart.2.port=0x3E8
#hint.uart.2.disabled=0
hint.uart.2.flags=0x30
=

I don't know whether all of that is needed, but, as you can see from the 
various commented-out lines, it was a configuration I arrived at that works. 
:-)

I don't have a /boot.config on this system.

Usually, I have the VGA console take precedence.  In that case, I get messages 
on both the VGA console and the IPMI SOL console during the BIOS screen, 
loader, and kernel boot messages but then only messages on the VGA console 
during the rc.d boot phase.  I have a serial console enabled in /etc/ttys, so I 
get output (e.g., getty login) on the IPMI SOL when that is eventually spawned. 
 If I want to have the serial console take precedence, I usually escape to the 
loader prompt (via ESC at the loader menu) and issue a set 
console=comconsole,vidconsole command.  Then, the rc.d boot output goes to 
the serial console and not the VGA console.  (It would be nice to have rc.d 
init scripts output go to both consoles, but I don't know whether that is 
possible.)

Cheers,

Paul.
___
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: ask about stable

[Paul Mather]

On Feb 20, 2013, at 4:29 AM, Fleuriot Damien m...@my.gd wrote:

 Here, I think this is what you're looking for:
 
 http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html
 
 
 You should be able to move from 9.1-RELEASE to 9-STABLE with freebsd-update :)


Except that the freebsd-update(8) man page includes the following:

DESCRIPTION

 The freebsd-update tool is used to fetch, install, and rollback binary
 updates to the FreeBSD base system.  Note that updates are only available
 if they are being built for the FreeBSD release and architecture being
 used; in particular, the FreeBSD Security Team only builds updates for
 releases shipped in binary form by the FreeBSD Release Engineering Team,
 e.g., FreeBSD 7.3-RELEASE and FreeBSD 8.0-RELEASE, but not FreeBSD
 6.3-STABLE or FreeBSD 9.0-CURRENT.


In other words, you can't use it to track -STABLE or -CURRENT.

Cheers,

Paul.


 
 
 
 On Feb 20, 2013, at 9:57 AM, Nurhermansyah eka ekanoti...@gmail.com wrote:
 
 hi,
 oh ya .. true .. I'm running 9.1-RELEASE and I want to update to 9-STABLE
 
 it's how to update to 9-STABLE?
 
 thank you
 
 sorry if my english is bad, i from indonesia.. 
 
 
 2013/2/20 Damien Fleuriot m...@my.gd
 
 On 20 Feb 2013, at 06:03, Nurhermansyah eka ekanoti...@gmail.com wrote:
 
 hi all..
 
 if I could make a stable version for freebsd 9.1-release ??
 
 thanks
 
 
 Hi,
 
 Did you mean I'm running 9.1-RELEASE and I want to update it to 9-STABLE ?
 
 If not, kindly clarify...
 
 
 ___
 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: some issues with /usr/sbin/service

[Paul Mather]

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 12
 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 12 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 missing xxx_enable in rc.conf 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
 no definition  emit no warnings, service should not run


I think case 4 (no definition) 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 is 
not a universal rule that no definition = default to NO.  The net/avahi-app 
port, for example, doesn't default to NO if xxx_enable is not set: it 
defaults to whatever the gnome_enable setting is defined to be.

For the base OS, I agree with your case 4; for the land of ports, I don't think 
the answer is so cut and dried.  That is why I think the warning is useful: it 
reminds admins to look at the service in question and make a firm decision of 
their own as to whether it should explicitly be turned on or off.  It 

Re: pkgng and updated packages

[Paul Mather]

On Jan 28, 2013, at 1:59 PM, Rainer Duffner rai...@ultra-secure.de wrote:

   
 Am 28.01.2013 um 18:31 schrieb Glen Barber g...@freebsd.org:
 
 On Mon, Jan 28, 2013 at 06:28:02PM +0100, Rainer Duffner wrote:
 I go from PERL 5.10 to PERL 5.16, for example and it complains that
 perl5.16 conflicts with perl5.10...
 
 This I needed, too:
 
 pkg set -o long/perl5.10:lang/perl5.16
 pkg remove perl 
 pkg set -o devel/pkg-config:devel/pkgconf
 pkg remove -f pkg-config
 
 
 Hmm, you should not have needed to remove perl or pkg-config.  They
 should have been upgraded as any other package.
 
 
 
 I tried it without and it said it conflicted. It wanted to install perl5.16, 
 without doing anything to 5.10.


The lang/perl5.10 and lang/perl5.16 ports are separate ports that are marked in 
their respective Makefiles as conflicting (because they install files into 
common places).  Perl 5.16 is not an upgrade of Perl 5.10 in the standard 
ports sense.  That is why both the Makefile and pkgng will complain if you try 
and install both (e.g., installing Perl 5.16 when Perl 5.10 is still installed).

If you want to switch to lang/perl5.16 from lang/perl5.10 you could follow a 
procedure like that outlined in the 20120630 entry of /usr/ports/UPDATING.

Cheers,

Paul.
___
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: Solved?: Re: Upgrade of RELENG_8 ZFS boot pool leads to unbootable system

[Paul Mather]

On Jan 4, 2013, at 5:39 AM, Vincent Hoffman vi...@unsane.co.uk wrote:

 On 03/01/2013 21:18, Paul Mather wrote:
 
 
 It turns out it was my /boot.config that was preventing booting.  The system 
 is usually always headless, so I have -S115200 -Dh as the sole line in 
 /boot.config to enable a 115200 baud serial console.  This has been working 
 fine for me up until I did a {build,install} {kernel,world} on 1st January 
 2013.  I was pretty sure my woes began after I did the zpool upgrade -a 
 and subsequently rebooted again, but now I can't be sure whether I 
 successfully rebooted at all after the make installworld and mergemaster 
 step.
 
 Does anyone know a sure-fire way of getting a dual console setup (high-speed 
 serial + VGA).  The recipe I had been using had worked well for a long time. 
  I had -S115200 -Dh in /boot.config and the following entries in 
 /boot/loader.conf:
 
  boot_multicons=YES
  comconsole_speed=115200
  console=comconsole,vidconsole
 
 Now, though, if I have -S115200 -Dh then the system locks up at boot.  
 Removing /boot.config gets me dual console, but only at 9600 baud. :-(
 I have
 root@copia:/root # more /boot.config
 -Dh
 
 and
 root@copia:/root # grep 'cons' /boot/loader.conf
 console=comconsole,vidconsole
 comconsole_speed=19200
 boot_multicons=yes
 
 Which works fine for ipmi based serial over lan console in a generic
 9.1-RELEASE.
 Not sure thats that helpful but 19200 is better than 9600 ;)


That's weird.  I have the same basic /boot/loader.conf entries (except for a 
speed of 115200) and even just putting -Dh into /boot.config leads to the 
same unbootable system behaviour. :-(

Maybe something broke recently in the RELENG_8 boot loader?  Like I said 
originally, that /boot.config entry had been working for me without problems 
for a long time.

Cheers,

Paul.
___
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

Solved?: Re: Upgrade of RELENG_8 ZFS boot pool leads to unbootable system

[Paul Mather]

On Jan 2, 2013, at 2:10 PM, Matthew Seaman m.sea...@infracaninophile.co.uk 
wrote:

 On 02/01/2013 17:49, Paul Mather wrote:
 Yesterday, I updated my RELENG_8 ZFS-only system that has worked like a 
 champ for ages.  After a successful install{kernel,world} and reboot, I 
 noticed the 20121130 entry in /usr/src/UPDATING and upgraded my ZFS pool via 
 zfs upgrade -a.  I also upgraded my boot blocks as requested, and as per 
 the ZFS notes section of /usr/src/UPDATING.
 
 Unfortunately rebooting with the upgraded pool failed.  The windmill boot 
 spinner spins for a tiny amount of time and then stops dead. :-(  I don't 
 get to the boot loader menu at all.
 
 I downloaded a very recent RELENG_8 snapshot 
 (FreeBSD-8.3-RELENG_8-r244923-JPSNAP-amd64-amd64-memstick.img) from 
 pub.allbsd.org and was able to boot successfully from USB using that.  I 
 entered Fixit Mode and tried to write the boot blocks on the memstick image 
 onto my hard drives but the resultant system still wouldn't boot.  The 
 commands I used (from Fixit Mode) are these:
 
  gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad4
  gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad6
 
 (ad4 and ad6 are my two hard drives.)
 
 If I load zfs before booting the USB memstick then I can see my old pool 
 listed when I do zfs import.  I haven't tried importing the pool because 
 I'm not sure if that would make the problem worse.
 
 Does anyone have any advice in restoring this system to bootability?  I 
 followed the standard root on ZFS recipe using a two drive mirror when 
 installing the system initially.  Each drive uses GPT with three partitions: 
 freebsd-boot, freebsd-swap, and freebsd-zfs in that order.  Like I said at 
 the start, all this worked for a long time until just now when I upgraded 
 the pool to enable feature flags support. :-(
 
 Any help is appreciated.
 
 I think you may be running into problems with zpool.cache.  This has
 been fixed in current, which now has the ability to find the root zpool
 without a valid zpool.cache, but that I suspect is faint comfort for you.


It turns out it was my /boot.config that was preventing booting.  The system is 
usually always headless, so I have -S115200 -Dh as the sole line in 
/boot.config to enable a 115200 baud serial console.  This has been working 
fine for me up until I did a {build,install} {kernel,world} on 1st January 
2013.  I was pretty sure my woes began after I did the zpool upgrade -a and 
subsequently rebooted again, but now I can't be sure whether I successfully 
rebooted at all after the make installworld and mergemaster step.

Does anyone know a sure-fire way of getting a dual console setup (high-speed 
serial + VGA).  The recipe I had been using had worked well for a long time.  I 
had -S115200 -Dh in /boot.config and the following entries in 
/boot/loader.conf:

boot_multicons=YES
comconsole_speed=115200
console=comconsole,vidconsole

Now, though, if I have -S115200 -Dh then the system locks up at boot.  
Removing /boot.config gets me dual console, but only at 9600 baud. :-(

Cheers,

Paul.

PS: Is the BOOT_COMCONSOLE_SPEED entry in /etc/make.conf needed?  I was under 
the impression it has been obsolete for a while and took it out of my 
/etc/make.conf file.


___
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

Upgrade of RELENG_8 ZFS boot pool leads to unbootable system

[Paul Mather]

Yesterday, I updated my RELENG_8 ZFS-only system that has worked like a champ 
for ages.  After a successful install{kernel,world} and reboot, I noticed the 
20121130 entry in /usr/src/UPDATING and upgraded my ZFS pool via zfs upgrade 
-a.  I also upgraded my boot blocks as requested, and as per the ZFS notes 
section of /usr/src/UPDATING.

Unfortunately rebooting with the upgraded pool failed.  The windmill boot 
spinner spins for a tiny amount of time and then stops dead. :-(  I don't get 
to the boot loader menu at all.

I downloaded a very recent RELENG_8 snapshot 
(FreeBSD-8.3-RELENG_8-r244923-JPSNAP-amd64-amd64-memstick.img) from 
pub.allbsd.org and was able to boot successfully from USB using that.  I 
entered Fixit Mode and tried to write the boot blocks on the memstick image 
onto my hard drives but the resultant system still wouldn't boot.  The commands 
I used (from Fixit Mode) are these:

gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad4
gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad6

(ad4 and ad6 are my two hard drives.)

If I load zfs before booting the USB memstick then I can see my old pool 
listed when I do zfs import.  I haven't tried importing the pool because I'm 
not sure if that would make the problem worse.

Does anyone have any advice in restoring this system to bootability?  I 
followed the standard root on ZFS recipe using a two drive mirror when 
installing the system initially.  Each drive uses GPT with three partitions: 
freebsd-boot, freebsd-swap, and freebsd-zfs in that order.  Like I said at the 
start, all this worked for a long time until just now when I upgraded the pool 
to enable feature flags support. :-(

Any help is appreciated.

Cheers,

Paul.


___
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: Upgrade of RELENG_8 ZFS boot pool leads to unbootable system

[Paul Mather]

On Jan 2, 2013, at 2:10 PM, Matthew Seaman m.sea...@infracaninophile.co.uk 
wrote:

 On 02/01/2013 17:49, Paul Mather wrote:
 Yesterday, I updated my RELENG_8 ZFS-only system that has worked like a 
 champ for ages.  After a successful install{kernel,world} and reboot, I 
 noticed the 20121130 entry in /usr/src/UPDATING and upgraded my ZFS pool via 
 zfs upgrade -a.  I also upgraded my boot blocks as requested, and as per 
 the ZFS notes section of /usr/src/UPDATING.
 
 Unfortunately rebooting with the upgraded pool failed.  The windmill boot 
 spinner spins for a tiny amount of time and then stops dead. :-(  I don't 
 get to the boot loader menu at all.
 
 I downloaded a very recent RELENG_8 snapshot 
 (FreeBSD-8.3-RELENG_8-r244923-JPSNAP-amd64-amd64-memstick.img) from 
 pub.allbsd.org and was able to boot successfully from USB using that.  I 
 entered Fixit Mode and tried to write the boot blocks on the memstick image 
 onto my hard drives but the resultant system still wouldn't boot.  The 
 commands I used (from Fixit Mode) are these:
 
  gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad4
  gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptzfsboot -i 1 ad6
 
 (ad4 and ad6 are my two hard drives.)
 
 If I load zfs before booting the USB memstick then I can see my old pool 
 listed when I do zfs import.  I haven't tried importing the pool because 
 I'm not sure if that would make the problem worse.
 
 Does anyone have any advice in restoring this system to bootability?  I 
 followed the standard root on ZFS recipe using a two drive mirror when 
 installing the system initially.  Each drive uses GPT with three partitions: 
 freebsd-boot, freebsd-swap, and freebsd-zfs in that order.  Like I said at 
 the start, all this worked for a long time until just now when I upgraded 
 the pool to enable feature flags support. :-(
 
 Any help is appreciated.
 
 I think you may be running into problems with zpool.cache.  This has
 been fixed in current, which now has the ability to find the root zpool
 without a valid zpool.cache, but that I suspect is faint comfort for you.
 
 To recover from a toasted zpool.cache, you need to boot from alternate
 media and then import your root zpool.  It's easiest to do that to a
 temporary directory.  The important bit is to copy the zpool.cache onto
 your actual zroot device:
 
 -- Boot from install media to 'Live CD' and log in as root (no password)

Given the above, does this need to be a -CURRENT Live CD?  I've been using the 
RELENG_8 snapshot memstick.img mentioned in my original message above.


 
 # kldload zfs   -- should load opensolaris.ko automatically
 # cd /tmp   -- this should be a writable MFS; you'll
   need to arrange something similar if
   not.
 # zpool import -o cachefile=/tmp/zpool.cache -R /tmp/zroot zroot
-- this should create a zpool.cache file


I tried this and it complained about the pool being in use by another 
system---the original system that won't boot any more.  I expected this, and 
added -f to force an import.

 # cp zpool.cache /tmp/zroot/boot/zfs/


This part also failed for me.  My zroot fileset has a mountpoint property set 
to legacy.  I had to mount this manually, via mount -t zfs zroot /tmp/zroot 
to make the /tmp/zroot/boot/zfs directory accessible.


 # zfs umount -a
 # shutdown -r
 
 Eject the install media, and the system should boot up from your root spool.


Unfortunately, it didn't boot from the root pool.  I get the same thing 
happening: the windmill spins for a very short time and then stops dead.  I 
don't even make it to the BTX Loader output, let alone the boot loader menu 
options. :-(

Thank you for the suggestions.

Cheers,

Paul.


___
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: virtio for 9.1-R

[Paul Mather]

On Nov 27, 2012, at 3:49 PM, Joe Holden li...@rewt.org.uk wrote:

 On 27/11/2012 19:25, Sergey Kandaurov wrote:
 On 27 November 2012 22:12, Joe Holden li...@rewt.org.uk wrote:
 Hi guys,
 
 I can't see virtio in releng/9.1, is there any particular reason why it
 isn't going to be included given that it works reasonable well (and is
 optional anyway, so not likely to be detrimental)?
 
 virtio appeared in stable/9 a bit after 9.1 cut off,
 and it is too late now regardless of virtio shape.
 Anyway you can installed it from ports.
 
 Ah I see, doesn't really help all the people who can't install it in KVM and 
 such though unfortunately, seems silly making them wait even
 longer and having to use Linux :)


FWIW, I installed FreeBSD 9-STABLE (pre-virtio in src) in KVM, initially using 
the emulated devices and then, post-install, installed the 
emulators/virtio-kmod port and switched over to vtbd/vtnet devices without 
problem.  When virtio appeared in src, I ditched the virtio-kmod port, again, 
without issues.

I found making the transition to virtio devices no harder than the ad - ada 
device transition.

Cheers,

Paul.


___
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

uhci0 excessive interrupts---how can I disable or reset specific USB port?

[Paul Mather]

I am running FreeBSD/amd64 9-STABLE (built Mon Jul 23 10:45:51 EDT 2012) on a 
Dell Optiplex 760 and, today, noticed I had almost 30% system CPU load in top 
even when the system was idle.  A perusal of vmstat revealed the cause to be 
excessive interrupts on uhci0, even though nothing was plugged into that USB 
port:

# vmstat -i
interrupt  total   rate
irq4: uart0   22  0
irq16: uhci0617002282738 310969
irq23: uhci3 ehci183  0
irq256: hpet0:t0   135818421 68
irq257: hpet0:t1  659301   1120
irq264: em0 29529304 14
irq265: ahci0   11132506  5
Total   619401422375 312178


Because I am only using the front USB ports on that hardware, I thought I would 
disable the other (rear) USB ports in the BIOS.  I rebooted and duly disabled 
them.  However, when FreeBSD booted, it appeared to ignore the BIOS setting: 
all the USB ports were probed as usual.  (The high interrupts had vanished, 
though that might have been due to FreeBSD correctly shutting down the 
controllers at shutdown, or just the act of rebooting itself.)

I added hint.uhci.0.disabled=1 to /boot/loader.conf (hoping it would disable 
uhci0), but, again all the USB ports appeared in the boot probes.  (However, it 
*appears* as if uhci0 has been disabled because the irq16: uhci0 line no 
longer appears in vmstat -i.  However, all the same ugen devices appear in 
/dev.)

Is there a way of disabling a specific USB controller that you don't want to 
use?  If so, how?  I looked at usbconfig, but that appears to me to be more 
about controlling devices plugged in to a USB port rather than the port itself. 
 The reset command of usbconfig appears to be about resetting USB devices, 
not ports.

If I can't disable a specific USB port, is there a way to reset it without 
rebooting?  If I ever get another crazy interrupt storm like I noticed today it 
would be nice to be able to stop it without having to do a reboot.

Cheers,

Paul.

___
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: PF to Preventing SMTP Brute Force Attacks

[Paul Mather]

On Jun 15, 2012, at 12:55 PM, Shiv. Nath wrote:

 # START
 table bruteforce persist
 block in log quick from bruteforce
 
 pass in on $ext_if proto tcp \
 from any to $ext_if port $trusted_tcp_ports \
 flags S/SA keep state \
 (max-src-conn-rate 3/300, overload bruteforce flush global)
 
 # END
 
 AND CRON:
 */12 * * * *  /sbin/pfctl -t ssh-bruteforce -T expire 604800 /dev/null
 21
 
 What is the function expire 604800 are they entries in the table?
 should it be -t bruteforce or -t ssh-bruteforce


It refers to entries in the table specified by the -t option and instructs pf 
to expire (remove from the table) all entries older than the specified time (in 
seconds).  Basically, the value 604800 will expire entries older than 1 week.

For the above pf rules, the cron entry should be -t bruteforce (although in 
the pf rules you should be using bruteforce).

Cheers,

Paul.

___
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?

[Paul Mather]

On Jun 2, 2012, at 2:56 PM, Chris Nehren wrote:

 On Sat, Jun 02, 2012 at 14:11:06 -0400 , Paul Mather wrote:
 I'm not sure what the solution is for the end user.  I know I get
 somewhat leery of updating my ports if I see a large number of changes
 coming via portsnap (like the 4000+ that accompanied the recent libpng
 upgrade) and there is nothing new in UPDATING (which, happily wasn't
 the case with the libpng upgrade).  Usually, I wait a while for the
 dust to clear and an UPDATING entry potentially to appear.
 
 If you're concerned about things breaking, don't follow the bleeding
 edge. This seems to be common sense.

Unfortunately, unlike the base operating system, which has -CURRENT, -STABLE, 
and -RELEASE, there is no well-defined bleeding edge in the case of ports.  
(Although there is a strong case to be made that it is analogous to -CURRENT.)  
So, as I said above, you have to fall back on heuristics to determine when it 
is best to update (with the caveat that waiting too long to update can also be 
as troublesome as updating too quickly).  Certainly, it's far from a case of 
read UPDATING and you'll be okay, as someone in this thread was seeming to 
imply.

NetBSD's pkgsrc has a nice feature: the quarterly package branches.  These 
follow a quarterly release cycle and receive only security updates.  It makes 
pkgsrc more akin to -CURRENT and -STABLE (or -RELEASE) instead of just -CURRENT.

 Maybe the solution is to track the freebsd-ports mailing list get get
 advanced warning of large changes, but that would mean following
 another high-volume list. :-(
 
 And any decent mailer setup can filter those messages for you, leaving
 only the messages relevant to ports you're interested in. There are also
 systems like gmane which provide an NNTP feed for mailing lists.
 Combined with a newsreader with good killfile / scoring features, it
 shouldn't be hard to keep up.


Probably not, but then again you're still relying on it breaking for someone 
else (and thereby being reported) to avoid it breaking for you. :-)

I'm not saying these are insurmountable problems, and, in my experience, most 
of the time ports updates go smoothly.  But, it can present more of a challenge 
for those that are running an individual FreeBSD system (as their 
desktop/laptop system, say), and especially if they are using non-default port 
options in the ports they install, as these don't get the benefit of widespread 
testing.

Cheers,

Paul.

___
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?

[Paul Mather]

On Jun 2, 2012, at 1:31 PM, Chris Rees wrote:

 On Jun 2, 2012 3:19 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 
 On 06/02/12 14:47, Daniel Kalchev wrote:
 
 
 On 02.06.12 15:32, Erich wrote:
 I know that the ports tree is a moving target. But it stops moving
 during the release period. This could be used to give a fall back
 solution.
 
 Or do I see this really too simple?
 
 The ports tree is a moving target during release periods still, although
 there are efforts to make movements smaller. This is why, after a
 release it suddenly moves more :)
 
 Daniel
 
 Even IF the ports tree IS a moving target, updating of UPDATING, for
 instance, follows most times AFTER the critical ports has been
 changed/updated and folks started updating their ports without realizing
 that they have shot themselfs into the foot!
 
 
 Not reading UPDATING until there are problems is not the fault of the ports
 tree; it should be checked every time you update.
 
 Of course, many of us forget, but that still doesn't make it anyone else's
 problem when we do!


The point he made was actually not a matter of people not reading UPDATING but 
that UPDATING is oftentimes not updated until after the disruptive/potentially 
dangerous change has already hit the ports tree.  So, even though people check 
UPDATING, it won't help them because there will be nothing apropos there until 
maybe days later when someone has decided an UPDATING entry was merited in 
retrospect.

I'm not sure what the solution is for the end user.  I know I get somewhat 
leery of updating my ports if I see a large number of changes coming via 
portsnap (like the 4000+ that accompanied the recent libpng upgrade) and there 
is nothing new in UPDATING (which, happily wasn't the case with the libpng 
upgrade).  Usually, I wait a while for the dust to clear and an UPDATING entry 
potentially to appear.

Maybe the solution is to track the freebsd-ports mailing list get get advanced 
warning of large changes, but that would mean following another high-volume 
list. :-(

Cheers,

Paul.

___
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, 1 gig of RAM and periodic weekly

[Paul Mather]

On Feb 27, 2012, at 11:10 PM, Eugene M. Zheganin wrote:

 Hi.
 
 On 28.02.2012 01:02, Nenhum_de_Nos wrote:
 regardless of the pool size ?
 
 I was planning on making an atom board a file server for my home, and I have 
 two options: soekris
 net6501 2GB RAM and intel board powered by the 330 atom (says 2GB limited as 
 well). My plans are
 to use from 4 up to 8 disks, and they should be 2TB at least.
 
 As its for home use, some p2p software and mostly music listening and 
 sometimes movie streaming.
 
 should 2GB be that bad, that I should drop it and use UFS instead ?
 
 I may run any version of FreeBSD on it, was planning on 9-STABLE or 9.1.
 
 In the same time I have a couple of hosts successfully running zfs on 768 
 Megs and on 1 Gig of RAM. Both i386.
 And they aren't affected by the periodic weekly for some reason. And they are 
 used only as fileservers.


Basically the same story here: I am using a FreeBSD/i386 system with 768 MB of 
RAM running RELENG_8 with 4 x 1 TB drives arranged as a RAIDZ1 vdev.  It is 
used as a Bacula server, backing up to the ZFS pool (with ZFS compression 
enabled).  It has been rock solid, and I've had no problems with any of the 
periodic jobs.

Here are the ZFS-related tunings I have in /boot/loader.conf:

vm.kmem_size=640M
vm.kmem_size_max=640M
vfs.zfs.arc_max=512M
vfs.zfs.txg.timeout=5


If you are planning on using P2P a lot, I had heard that large files fetched 
via Bittorrent can become very fragmented under ZFS (due to the COW nature of 
ZFS and the way Bittorrent fetches files), especially if the pool is very full, 
and so ZFS might not be the best thing to use if you are also planning on 
streaming these files, especially on modest hardware.  UFS might be preferable 
in these circumstances.

Cheers,

Paul.


___
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 + nullfs + Linuxulator = panic?

[Paul Mather]

On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote:

 On Thu, Feb 16, 2012 at 12:07:46PM -0500, Paul Mather wrote:
 On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:
 
 On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
 On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
 
 On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
 I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, 
 last built 2012-02-08).  It will panic during the daily periodic scripts 
 that run at 3am.  Here is the most recent panic message:
 
 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 0; apic id = 00
 instruction pointer = 0x20:0x8069d266
 stack pointer   = 0x28:0xff8094b90390
 frame pointer   = 0x28:0xff8094b903a0
 code segment= base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= resume, IOPL = 0
 current process = 72566 (ps)
 trap number = 9
 panic: general protection fault
 cpuid = 0
 KDB: stack backtrace:
 #0 0x8062cf8e at kdb_backtrace+0x5e
 #1 0x805facd3 at panic+0x183
 #2 0x808e6c20 at trap_fatal+0x290
 #3 0x808e715a at trap+0x10a
 #4 0x808cec64 at calltrap+0x8
 #5 0x805ee034 at fill_kinfo_thread+0x54
 #6 0x805eee76 at fill_kinfo_proc+0x586
 #7 0x805f22b8 at sysctl_out_proc+0x48
 #8 0x805f26c8 at sysctl_kern_proc+0x278
 #9 0x8060473f at sysctl_root+0x14f
 #10 0x80604a2a at userland_sysctl+0x14a
 #11 0x80604f1a at __sysctl+0xaa
 #12 0x808e62d4 at amd64_syscall+0x1f4
 #13 0x808cef5c at Xfast_syscall+0xfc
 
 Please look up the line number for the fill_kinfo_thread+0x54.
 
 
 Is there a way for me to do this from the above information? As
 I said in the original message, I failed to get a crash dump after
 reboot (because, it turns out, I hadn't set up my gmirror swap device
 properly). Alas, with the latest panic, it appears to have hung[1]
 during the Dumping phase, so it looks like I won't get a saved crash
 dump this time, either. :-(
 
 Load the kernel.debug into kgdb, and from there do
 list *fill_kinfo_thread+0x54.
 
 
 gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (kgdb) list *fill_kinfo_thread+0x54
 0x805ee034 is in fill_kinfo_thread 
 (/usr/src/sys/kern/kern_proc.c:854).
 849 thread_lock(td);
 850 if (td-td_wmesg != NULL)
 851 strlcpy(kp-ki_wmesg, td-td_wmesg, 
 sizeof(kp-ki_wmesg));
 852 else
 853 bzero(kp-ki_wmesg, sizeof(kp-ki_wmesg));
 854 strlcpy(kp-ki_ocomm, td-td_name, sizeof(kp-ki_ocomm));
 855 if (TD_ON_LOCK(td)) {
 856 kp-ki_kiflag |= KI_LOCKBLOCK;
 857 strlcpy(kp-ki_lockname, td-td_lockname,
 858 sizeof(kp-ki_lockname));
 (kgdb) 
 
 This is indeed strange. It can only occur if td pointer is damaged.
 
 Please, try to get a core and at least print the content of *td in this case.



Another panic last night, after reverting dsmc schedule scripts to use 
/bin/sh (actually /compat/linux/bin/sh):

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x308
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x806026ef
stack pointer   = 0x28:0xff8094af02d0
frame pointer   = 0x28:0xff8094af0350
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 90872 (df)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0x8062cf8e at kdb_backtrace+0x5e
#1 0x805facd3 at panic+0x183
#2 0x808e6c20 at trap_fatal+0x290
#3 0x808e6f71 at trap_pfault+0x201
#4 0x808e742f at trap+0x3df
#5 0x808cec64 at calltrap+0x8
#6 0x80602e1e at _sx_xlock+0x4e
#7 0x80f9ca35 at rrw_enter+0xa5
#8 0x80f9ce86 at zfs_statfs+0x46
#9 0x80681258 at __vfs_statfs+0x28
#10 0x81476521 at nullfs_statfs+0x51
#11 0x80681258 at __vfs_statfs+0x28
#12 0x80690b22 at kern_statfs+0x1b2
#13 0x80690c77 at statfs+0x37
#14 0x808e62d4 at amd64_syscall+0x1f4
#15 0x808cef5c at Xfast_syscall+0xfc


Alas, the system became hung here: there is no further

Re: ZFS + nullfs + Linuxulator = panic?

[Paul Mather]

On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote:

 On Thu, Feb 16, 2012 at 12:07:46PM -0500, Paul Mather wrote:
 On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:
 
 On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
 On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
 
 On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
 I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, 
 last built 2012-02-08).  It will panic during the daily periodic scripts 
 that run at 3am.  Here is the most recent panic message:
 
 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 0; apic id = 00
 instruction pointer = 0x20:0x8069d266
 stack pointer   = 0x28:0xff8094b90390
 frame pointer   = 0x28:0xff8094b903a0
 code segment= base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= resume, IOPL = 0
 current process = 72566 (ps)
 trap number = 9
 panic: general protection fault
 cpuid = 0
 KDB: stack backtrace:
 #0 0x8062cf8e at kdb_backtrace+0x5e
 #1 0x805facd3 at panic+0x183
 #2 0x808e6c20 at trap_fatal+0x290
 #3 0x808e715a at trap+0x10a
 #4 0x808cec64 at calltrap+0x8
 #5 0x805ee034 at fill_kinfo_thread+0x54
 #6 0x805eee76 at fill_kinfo_proc+0x586
 #7 0x805f22b8 at sysctl_out_proc+0x48
 #8 0x805f26c8 at sysctl_kern_proc+0x278
 #9 0x8060473f at sysctl_root+0x14f
 #10 0x80604a2a at userland_sysctl+0x14a
 #11 0x80604f1a at __sysctl+0xaa
 #12 0x808e62d4 at amd64_syscall+0x1f4
 #13 0x808cef5c at Xfast_syscall+0xfc
 
 Please look up the line number for the fill_kinfo_thread+0x54.
 
 
 Is there a way for me to do this from the above information? As
 I said in the original message, I failed to get a crash dump after
 reboot (because, it turns out, I hadn't set up my gmirror swap device
 properly). Alas, with the latest panic, it appears to have hung[1]
 during the Dumping phase, so it looks like I won't get a saved crash
 dump this time, either. :-(
 
 Load the kernel.debug into kgdb, and from there do
 list *fill_kinfo_thread+0x54.
 
 
 gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (kgdb) list *fill_kinfo_thread+0x54
 0x805ee034 is in fill_kinfo_thread 
 (/usr/src/sys/kern/kern_proc.c:854).
 849 thread_lock(td);
 850 if (td-td_wmesg != NULL)
 851 strlcpy(kp-ki_wmesg, td-td_wmesg, 
 sizeof(kp-ki_wmesg));
 852 else
 853 bzero(kp-ki_wmesg, sizeof(kp-ki_wmesg));
 854 strlcpy(kp-ki_ocomm, td-td_name, sizeof(kp-ki_ocomm));
 855 if (TD_ON_LOCK(td)) {
 856 kp-ki_kiflag |= KI_LOCKBLOCK;
 857 strlcpy(kp-ki_lockname, td-td_lockname,
 858 sizeof(kp-ki_lockname));
 (kgdb) 
 
 This is indeed strange. It can only occur if td pointer is damaged.
 
 Please, try to get a core and at least print the content of *td in this case.


Alas, I was unable to obtain a crash dump (or even a panic) last night, but I 
have learned more about the circumstances that lead to this panic.

In attempting to find a workaround for this panic (because having nightly 
backups instead of panics is a good thing:) I discovered two successful 
approaches.  In the original situation that causes a reliable panic I have a 
daemonised Tivoli dsmc schedule job running.  This communicates with the 
Tivoli TSM server to determine when it should run its scheduled backup.  When 
the backup is run, there is defined  in a Tivoli client config file (in 
/compat/linux/opt/tivoli/tsm/client/ba/bin/dsm.sys) a preschedulecmd and a 
postschedulecmd, which are /usr/local/bin/make_zfs_backup_snapshot and 
/usr/local/bin/remove_zfs_backup_snapshot respectively.  The preschedulecmd 
script (run prior to the actual backup) basically makes ZFS snapshots of all 
filesets and nullfs-mounts them under /backup.  It then creates 
/compat/linux/etc/mtab to list these nullfs filesystems as ext2 file systems, 
so that the Tivoli backup client can know about them to back them up.  The 
postschedulecmd (run after the actual backup) unmounts all the nullfs-mounted 
filesystems corresponding to the ZFS backup snapshots and then destroys all the 
backup snapshots.

The first workaround that doesn't lead to a panic is this: Do not run dsmc 
schedule.  Instead, via cron, run this simple script:

#!/bin/sh
/usr/local/bin

Re: ZFS + nullfs + Linuxulator = panic?

[Paul Mather]

On Feb 17, 2012, at 8:27 PM, Konstantin Belousov wrote:

 On Thu, Feb 16, 2012 at 12:07:46PM -0500, Paul Mather wrote:
 On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:
 
 On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
 On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
 
 On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
 I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, 
 last built 2012-02-08).  It will panic during the daily periodic scripts 
 that run at 3am.  Here is the most recent panic message:
 
 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 0; apic id = 00
 instruction pointer = 0x20:0x8069d266
 stack pointer   = 0x28:0xff8094b90390
 frame pointer   = 0x28:0xff8094b903a0
 code segment= base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= resume, IOPL = 0
 current process = 72566 (ps)
 trap number = 9
 panic: general protection fault
 cpuid = 0
 KDB: stack backtrace:
 #0 0x8062cf8e at kdb_backtrace+0x5e
 #1 0x805facd3 at panic+0x183
 #2 0x808e6c20 at trap_fatal+0x290
 #3 0x808e715a at trap+0x10a
 #4 0x808cec64 at calltrap+0x8
 #5 0x805ee034 at fill_kinfo_thread+0x54
 #6 0x805eee76 at fill_kinfo_proc+0x586
 #7 0x805f22b8 at sysctl_out_proc+0x48
 #8 0x805f26c8 at sysctl_kern_proc+0x278
 #9 0x8060473f at sysctl_root+0x14f
 #10 0x80604a2a at userland_sysctl+0x14a
 #11 0x80604f1a at __sysctl+0xaa
 #12 0x808e62d4 at amd64_syscall+0x1f4
 #13 0x808cef5c at Xfast_syscall+0xfc
 
 Please look up the line number for the fill_kinfo_thread+0x54.
 
 
 Is there a way for me to do this from the above information? As
 I said in the original message, I failed to get a crash dump after
 reboot (because, it turns out, I hadn't set up my gmirror swap device
 properly). Alas, with the latest panic, it appears to have hung[1]
 during the Dumping phase, so it looks like I won't get a saved crash
 dump this time, either. :-(
 
 Load the kernel.debug into kgdb, and from there do
 list *fill_kinfo_thread+0x54.
 
 
 gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 (kgdb) list *fill_kinfo_thread+0x54
 0x805ee034 is in fill_kinfo_thread 
 (/usr/src/sys/kern/kern_proc.c:854).
 849 thread_lock(td);
 850 if (td-td_wmesg != NULL)
 851 strlcpy(kp-ki_wmesg, td-td_wmesg, 
 sizeof(kp-ki_wmesg));
 852 else
 853 bzero(kp-ki_wmesg, sizeof(kp-ki_wmesg));
 854 strlcpy(kp-ki_ocomm, td-td_name, sizeof(kp-ki_ocomm));
 855 if (TD_ON_LOCK(td)) {
 856 kp-ki_kiflag |= KI_LOCKBLOCK;
 857 strlcpy(kp-ki_lockname, td-td_lockname,
 858 sizeof(kp-ki_lockname));
 (kgdb) 
 
 This is indeed strange. It can only occur if td pointer is damaged.
 
 Please, try to get a core and at least print the content of *td in this case.


Hopefully, I will be able to get a crash dump tonight.  I disabled the Tivoli 
dsmc schedule job over the weekend, because I don't have ready physical 
access to the machine and prefer it not to be down for very extended periods of 
time.  (As I reported previously, for some reason the system seems to get stuck 
saving the crash dump.  If this persists, maybe it might be better to get the 
system to drop into the debugger on panic instead of hoping forlornly for a 
successful crash dump.)

Cheers,

Paul.

___
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 + nullfs + Linuxulator = panic?

[Paul Mather]

On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:

 On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
 I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, last 
 built 2012-02-08).  It will panic during the daily periodic scripts that run 
 at 3am.  Here is the most recent panic message:
 
 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 0; apic id = 00
 instruction pointer = 0x20:0x8069d266
 stack pointer   = 0x28:0xff8094b90390
 frame pointer   = 0x28:0xff8094b903a0
 code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= resume, IOPL = 0
 current process = 72566 (ps)
 trap number = 9
 panic: general protection fault
 cpuid = 0
 KDB: stack backtrace:
 #0 0x8062cf8e at kdb_backtrace+0x5e
 #1 0x805facd3 at panic+0x183
 #2 0x808e6c20 at trap_fatal+0x290
 #3 0x808e715a at trap+0x10a
 #4 0x808cec64 at calltrap+0x8
 #5 0x805ee034 at fill_kinfo_thread+0x54
 #6 0x805eee76 at fill_kinfo_proc+0x586
 #7 0x805f22b8 at sysctl_out_proc+0x48
 #8 0x805f26c8 at sysctl_kern_proc+0x278
 #9 0x8060473f at sysctl_root+0x14f
 #10 0x80604a2a at userland_sysctl+0x14a
 #11 0x80604f1a at __sysctl+0xaa
 #12 0x808e62d4 at amd64_syscall+0x1f4
 #13 0x808cef5c at Xfast_syscall+0xfc
 
 Please look up the line number for the fill_kinfo_thread+0x54.


Is there a way for me to do this from the above information?  As I said in the 
original message, I failed to get a crash dump after reboot (because, it turns 
out, I hadn't set up my gmirror swap device properly).  Alas, with the latest 
panic, it appears to have hung[1] during the Dumping phase, so it looks like 
I won't get a saved crash dump this time, either. :-(

Speaking of the latest panic, here it is:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x308
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x806026ef
stack pointer   = 0x28:0xff8094acd2d0
frame pointer   = 0x28:0xff8094acd350
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 20992 (df)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0x8062cf8e at kdb_backtrace+0x5e
#1 0x805facd3 at panic+0x183
#2 0x808e6c20 at trap_fatal+0x290
#3 0x808e6f71 at trap_pfault+0x201
#4 0x808e742f at trap+0x3df
#5 0x808cec64 at calltrap+0x8
#6 0x80602e1e at _sx_xlock+0x4e
#7 0x80f9ca35 at rrw_enter+0xa5
#8 0x80f9ce86 at zfs_statfs+0x46
#9 0x80681258 at __vfs_statfs+0x28
#10 0x81476521 at nullfs_statfs+0x51
#11 0x80681258 at __vfs_statfs+0x28
#12 0x80690b22 at kern_statfs+0x1b2
#13 0x80690c77 at statfs+0x37
#14 0x808e62d4 at amd64_syscall+0x1f4
#15 0x808cef5c at Xfast_syscall+0xfc


Cheers,

Paul.

[1] Not quite hung solid: when I press the power button I get this appearing on 
the console:

acpi0: suspend request ignored (not ready yet)
acpi0: request to enter state S5 failed (err 6)

___
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 + nullfs + Linuxulator = panic?

[Paul Mather]

On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote:

 On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
 On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
 
 On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
 I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, 
 last built 2012-02-08).  It will panic during the daily periodic scripts 
 that run at 3am.  Here is the most recent panic message:
 
 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 0; apic id = 00
 instruction pointer = 0x20:0x8069d266
 stack pointer   = 0x28:0xff8094b90390
 frame pointer   = 0x28:0xff8094b903a0
 code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= resume, IOPL = 0
 current process = 72566 (ps)
 trap number = 9
 panic: general protection fault
 cpuid = 0
 KDB: stack backtrace:
 #0 0x8062cf8e at kdb_backtrace+0x5e
 #1 0x805facd3 at panic+0x183
 #2 0x808e6c20 at trap_fatal+0x290
 #3 0x808e715a at trap+0x10a
 #4 0x808cec64 at calltrap+0x8
 #5 0x805ee034 at fill_kinfo_thread+0x54
 #6 0x805eee76 at fill_kinfo_proc+0x586
 #7 0x805f22b8 at sysctl_out_proc+0x48
 #8 0x805f26c8 at sysctl_kern_proc+0x278
 #9 0x8060473f at sysctl_root+0x14f
 #10 0x80604a2a at userland_sysctl+0x14a
 #11 0x80604f1a at __sysctl+0xaa
 #12 0x808e62d4 at amd64_syscall+0x1f4
 #13 0x808cef5c at Xfast_syscall+0xfc
 
 Please look up the line number for the fill_kinfo_thread+0x54.
 
 
 Is there a way for me to do this from the above information? As
 I said in the original message, I failed to get a crash dump after
 reboot (because, it turns out, I hadn't set up my gmirror swap device
 properly). Alas, with the latest panic, it appears to have hung[1]
 during the Dumping phase, so it looks like I won't get a saved crash
 dump this time, either. :-(
 
 Load the kernel.debug into kgdb, and from there do
 list *fill_kinfo_thread+0x54.


gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd...
(kgdb) list *fill_kinfo_thread+0x54
0x805ee034 is in fill_kinfo_thread (/usr/src/sys/kern/kern_proc.c:854).
849 thread_lock(td);
850 if (td-td_wmesg != NULL)
851 strlcpy(kp-ki_wmesg, td-td_wmesg, 
sizeof(kp-ki_wmesg));
852 else
853 bzero(kp-ki_wmesg, sizeof(kp-ki_wmesg));
854 strlcpy(kp-ki_ocomm, td-td_name, sizeof(kp-ki_ocomm));
855 if (TD_ON_LOCK(td)) {
856 kp-ki_kiflag |= KI_LOCKBLOCK;
857 strlcpy(kp-ki_lockname, td-td_lockname,
858 sizeof(kp-ki_lockname));
(kgdb) 


Cheers,

Paul.

___
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 + nullfs + Linuxulator = panic?

[Paul Mather]

On Feb 14, 2012, at 7:23 PM, Jeremy Chadwick wrote:

 On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
 I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, last 
 built 2012-02-08).  It will panic during the daily periodic scripts that run 
 at 3am.  Here is the most recent panic message:
 
 Fatal trap 9: general protection fault while in kernel mode
 cpuid = 0; apic id = 00
 instruction pointer = 0x20:0x8069d266
 stack pointer   = 0x28:0xff8094b90390
 frame pointer   = 0x28:0xff8094b903a0
 code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= resume, IOPL = 0
 current process = 72566 (ps)
 trap number = 9
 panic: general protection fault
 cpuid = 0
 KDB: stack backtrace:
 #0 0x8062cf8e at kdb_backtrace+0x5e
 #1 0x805facd3 at panic+0x183
 #2 0x808e6c20 at trap_fatal+0x290
 #3 0x808e715a at trap+0x10a
 #4 0x808cec64 at calltrap+0x8
 #5 0x805ee034 at fill_kinfo_thread+0x54
 #6 0x805eee76 at fill_kinfo_proc+0x586
 #7 0x805f22b8 at sysctl_out_proc+0x48
 #8 0x805f26c8 at sysctl_kern_proc+0x278
 #9 0x8060473f at sysctl_root+0x14f
 #10 0x80604a2a at userland_sysctl+0x14a
 #11 0x80604f1a at __sysctl+0xaa
 #12 0x808e62d4 at amd64_syscall+0x1f4
 #13 0x808cef5c at Xfast_syscall+0xfc
 Uptime: 3d19h6m0s
 Dumping 1308 out of 2028 MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91%
 Dump complete
 Automatic reboot in 15 seconds - press a key on the console to abort
 Rebooting...
 
 
 The reason for the subject line is that I have another RELENG_8 system that 
 uses ZFS + nullfs but doesn't panic, leading me to believe that ZFS + nullfs 
 is not the problem.  I am wondering if it is the combination of the three 
 that is deadly, here.
 
 Both RELENG_8 systems are root-on-ZFS installs.  Each night there is a 
 separate backup script that runs and completes before the regular periodic 
 daily run.  This script takes a recursive snapshot of the ZFS pool and then 
 mounts these snapshots via mount_nullfs to provide a coherent view of the 
 filesystem under /backup.  The only difference between the two RELENG_8 
 systems is that one uses rsync to back up /backup to another machine and the 
 other uses the Linux Tivoli TSM client to back up /backup to a TSM server.  
 After the backup is completed, a script runs that unmounts the nullfs file 
 systems and then destroys the ZFS snapshot.
 
 The first (rsync backup) RELENG_8 system does not panic.  It has been 
 running the ZFS + nullfs rsync backup job without incident for weeks now.  
 The second (Tivoli TSM) RELENG_8 will reliably panic when the subsequent 
 periodic daily job runs.  (It is using the 32-bit TSM 6.2.4 Linux client 
 running dsmc schedule via the linux_base-f10-10_4 package.)  The actual 
 ZFS + nullfs Tivoli TSM backup job appears to run successfully, making me 
 wonder if perhaps it has some memory leak or other subtle corruption that 
 sets up the ensuing panic when the periodic daily job later gives the 
 system a workout.
 
 If I can provide more information about the panic, please let me know.  
 Despite the message about dumping in the panic output above, when the system 
 reboots I get a No core dumps found message during boot.  (I have 
 dumpdev=AUTO set in /etc/rc.conf.)  My swap device is on separate 
 partitions but is mirrored using geom_mirror as /dev/mirror/swap.  Do crash 
 dumps to gmirror devices work on RELENG_8?
 
 See gmirror(8) man page, section NOTES.  Read the full thing.


Thanks!  I've changed the balance algorithm to prefer, so hopefully I'll get 
saved crash dumps to examine from now on.


 Does anyone have any idea what is to blame for the panic, or how I can fix 
 or work around it?
 
 Does the panic always happen when ps is run?  That's what's shown in
 the above panic message.  Quoting:
 
 current process = 72566 (ps)
 
 And I'm inclined to think it does, based on the backtrace:
 
 #5 0x805ee034 at fill_kinfo_thread+0x54
 #6 0x805eee76 at fill_kinfo_proc+0x586
 #7 0x805f22b8 at sysctl_out_proc+0x48
 #8 0x805f26c8 at sysctl_kern_proc+0x278
 
 But if you can go through the previous panics and confirm that, it would
 be helpful to developers in tracking down the problem.


Just going by memory, at least one other time it did a panic during df.  But, 
most of the time I remember the panic occurring during ps.

Cheers,

Paul.


___
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

ZFS + nullfs + Linuxulator = panic?

[Paul Mather]

I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, last 
built 2012-02-08).  It will panic during the daily periodic scripts that run at 
3am.  Here is the most recent panic message:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8069d266
stack pointer   = 0x28:0xff8094b90390
frame pointer   = 0x28:0xff8094b903a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 72566 (ps)
trap number = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0x8062cf8e at kdb_backtrace+0x5e
#1 0x805facd3 at panic+0x183
#2 0x808e6c20 at trap_fatal+0x290
#3 0x808e715a at trap+0x10a
#4 0x808cec64 at calltrap+0x8
#5 0x805ee034 at fill_kinfo_thread+0x54
#6 0x805eee76 at fill_kinfo_proc+0x586
#7 0x805f22b8 at sysctl_out_proc+0x48
#8 0x805f26c8 at sysctl_kern_proc+0x278
#9 0x8060473f at sysctl_root+0x14f
#10 0x80604a2a at userland_sysctl+0x14a
#11 0x80604f1a at __sysctl+0xaa
#12 0x808e62d4 at amd64_syscall+0x1f4
#13 0x808cef5c at Xfast_syscall+0xfc
Uptime: 3d19h6m0s
Dumping 1308 out of 2028 MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91%
Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...


The reason for the subject line is that I have another RELENG_8 system that 
uses ZFS + nullfs but doesn't panic, leading me to believe that ZFS + nullfs is 
not the problem.  I am wondering if it is the combination of the three that is 
deadly, here.

Both RELENG_8 systems are root-on-ZFS installs.  Each night there is a separate 
backup script that runs and completes before the regular periodic daily run.  
This script takes a recursive snapshot of the ZFS pool and then mounts these 
snapshots via mount_nullfs to provide a coherent view of the filesystem under 
/backup.  The only difference between the two RELENG_8 systems is that one uses 
rsync to back up /backup to another machine and the other uses the Linux Tivoli 
TSM client to back up /backup to a TSM server.  After the backup is completed, 
a script runs that unmounts the nullfs file systems and then destroys the ZFS 
snapshot.

The first (rsync backup) RELENG_8 system does not panic.  It has been running 
the ZFS + nullfs rsync backup job without incident for weeks now.  The second 
(Tivoli TSM) RELENG_8 will reliably panic when the subsequent periodic daily 
job runs.  (It is using the 32-bit TSM 6.2.4 Linux client running dsmc 
schedule via the linux_base-f10-10_4 package.)  The actual ZFS + nullfs Tivoli 
TSM backup job appears to run successfully, making me wonder if perhaps it has 
some memory leak or other subtle corruption that sets up the ensuing panic when 
the periodic daily job later gives the system a workout.

If I can provide more information about the panic, please let me know.  Despite 
the message about dumping in the panic output above, when the system reboots I 
get a No core dumps found message during boot.  (I have dumpdev=AUTO set in 
/etc/rc.conf.)  My swap device is on separate partitions but is mirrored using 
geom_mirror as /dev/mirror/swap.  Do crash dumps to gmirror devices work on 
RELENG_8?

Does anyone have any idea what is to blame for the panic, or how I can fix or 
work around it?

Cheers,

Paul.

PS: The uptime of three days in the panic message is because I disabled the 
Tivoli TSM backup job on Friday so it would not run over the weekend.

___
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: fsck_ufs out of swapspace

[Paul Mather]

On Dec 17, 2011, at 3:36 PM, Michiel Boland wrote:

 FreeBSD 9.0-PRERELEASE locked up while into some heavy I/O and failed to shut 
 down properly, so I had to power-cycle. After it came back up it said
 
 Starting file system checks:
 ** SU+J Recovering /dev/ada0a
 ** Reading 33554432 byte journal from inode 4.
 swap_pager: out of swap space
 swap_pager_getswapspace(16): failed
 pid 67 (fsck_ufs), uid 0, was killed: out of swap space
 fsck: /dev/ada0a: Killed: 9
 Script /etc/rc.d/fsck running
 Unknown error; help!
 ERROR: ABORTING BOOT (sending SIGTERM to parent)!
 
 The only way to continue was to do a full fsck (with no journal)
 
 This is a Sun Blade 100 (sparc64) with 768M of RAM.
 So the fsck is taking up all of this? That can't be right.
 
 What can I do to troubleshoot this further?


FWIW, I had this happen to me several weeks ago on FreeBSD/powerpc64 9-CURRENT. 
 I had to get the machine up and running so I simply abandoned use of SU+J and 
went back to using just UFS+SU.  (Not very helpful, I know, but there you go.)  
I figure it is likely to be some kind of endianness problem in the SU+J code, 
given the lack of complaints on FreeBSD/i386 and FreeBSD/amd64.

Cheers,

Paul.

PS: The system I was using is an Apple Xserve G5 with 4 GB of RAM and 5 GB of 
swap space.  As you say, surely fsck can't be using that much 
memory...___
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: usbus is seen as network interface - Fwd: sjakie.klop.ws daily run output

[Paul Mather]

On Sep 20, 2011, at 6:11 AM, Ronald Klop wrote:

 Hello,
 
 Why is usbus seen as a network interface since some time?
 I'm running 9-CURRENT on amd64.

I've been wondering this, too.  It also started happening sometime in the 
lifetime of 8-STABLE some months ago, with netstat -i showing usbus network 
interfaces despite no ethernet NIC being attached.  It appears that ifconfig 
is smart enough to omit these in output, as was netstat in former times on 
RELENG_8 (and still is on RELENG_7), so why include them now?  Just wondering...

Cheers,

Paul.___
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

[Paul Mather]

On Jul 25, 2011, at 2:51 PM, Bakul Shah wrote:

 On Mon, 25 Jul 2011 14:15:06 EDT Gary Palmer gpal...@freebsd.org  wrote:
 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.
 
 I read you can create a boot dvd from one of the files in the
 upgrade.


The problem is that the Boot DVD or Recovery Partition does not have an iSCSI 
initiator.  In fact, the Mac does not ship with an iSCSI initiator, and the 
common solution to obtaining one is to install the free globalSAN iSCSI 
Initiator for OS X.

Without an installed iSCSI initiator, you won't be able to mount the LUNs upon 
which is located the Time Machine volume from which you are trying to restore 
files.

Cheers,

Paul.


___
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: umass: AutoSense failed

[Paul Mather]

On Dec 9, 2010, at 5:11 PM, Jeremy Chadwick wrote:

 On Thu, Dec 09, 2010 at 10:35:56PM +0100, Harald Weis wrote:
 What could be the reason for the following failure?
 
 ugen2.2: Sony at usbus2
 umass0: Sony Sony DSC, class 0/0, rev 1.10/4.50, addr 2 on usbus2
 umass0:  RBC over CBI; quirks = 0x
 umass0:1:0:-1: Attached to scbus1
 (probe0:umass-sim0:0:0:0): AutoSense failed
 
 This occurs on 4 different boxes, all on 8.1-RELEASE.
 Never happened on previous releases.
 The camera works on an Ubuntu system.
 
 Please try a 8.1-STABLE or 8.2-PRERELEASE snapshot (you can boot the
 livefs CD or USB memstick image to test) and see if things are different
 (improved) there.
 
 ftp://ftp4.freebsd.org/pub/FreeBSD/snapshots/201011/
 
 8.x uses a newer/different USB stack than 7.x.


I get something similar to this happening on 8.2-PRERELEASE.  In my case, it's 
not during boot probing or device attachment.  Instead, it happens occasionally 
after boot.  The devices concerned are Maxtor OneTouch external USB hard 
drives.  Every now and then, I will get something akin to the following crop up 
in the console log:

(da1:umass-sim1:1:0:0): AutoSense failed

I have three of these Maxtor OneTouch drives attached to the system as part of 
a ZFS pool.  When I get an AutoSense failed message, it is usually 
accompanied by the ZFS pool being marked as faulted.

The Maxtor OneTouch drives are wont to spin down and go into a deep sleep after 
a period of inactivity and appear very slow to wake up again when I/O occurs.  
I have always assumed that the AutoSense failed is associated with 
this---that there is some kind of timeout in the FreeBSD stack that this device 
is exceeding.  In fact, sometimes the devices fail to probe properly during 
boot when they are asleep.

This is what the OneTouch normally probes as:

da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: Maxtor OneTouch 0121 Fixed Direct Access SCSI-4 device 
da0: 40.000MB/s transfers
da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)


Cheers,

Paul.

___
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: Supported SAS controllers (single port)

[Paul Mather]

On Dec 7, 2010, at 8:36 PM, Daniel O'Connor wrote:

 
 On 08/12/2010, at 3:51, Mike Andrews wrote:
 On 12/7/2010 8:00 AM, Daniel O'Connor wrote:
 Does anyone have a recommendation for one?
 
 I am looking to connect a LTO tape drive to a FreeBSD 7 or 8 box and I've 
 only ever used Adaptec 19160 and similar cards and LVDS SCSI.
 
 Our supplier has an LSI SAS3081E-R which is not outrageously expensive, has 
 anyone used one?
 
 Yes, I've got one, it works fine :)
 
 Ahh, good news, thanks :)
 
 Have you used it with a tape drive?
 
 You may want to flash the non-raid firmware from LSI onto it.
 
 OK thanks.
 
 I just realised it doesn't have any external connectors so I'll have to find 
 another candidate.
 
 However I do see the LSI spec sheet for it lists the chip which is listed in 
 mpt(4) so I should be able to find something.

I have a LSI SAS3801E (note lack of -R suffix) in a FreeBSD 8 box that is 
hooked up to a Quantum SuperLoader LTO-4 tape drive.  It's not in production 
yet, and I haven't done extensive testing, but so far it probes the tape drive 
and autochanger correctly.

The LSI SAS3801E itself attaches as a mpt device.  It has two external 
connectors but no internal ones.

I had intended to use an Areca ARC-1300-4X external SAS controller to drive 
this tape unit but, alas, I discovered that there is as yet no FreeBSD driver 
for that card. :-(

Cheers,

Paul.


___
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 Security Advisory FreeBSD-SA-10:10.openssl

[Paul Mather]

On Dec 2, 2010, at 4:54 AM, Gareth de Vaux wrote:

 On Thu 2010-12-02 (00:05), jhell wrote:
 Try that with a ( make includes ) in that same directory and if it works
 then the advisory will have to be revised.
 
 Ah awesome, that works thanx.
 
 (I don't see why though, since it was only half complaining about
 a missing definition, even when I manually included dtls1.h. Also,
 I tried on a different system and the advisory instructions worked
 as is).

The advisory instructions worked as-is for me on a 7.3-RELEASE-p3 system but 
failed on my 8.1-STABLE systems.  However, a make buildworld followed by a 
make install in the appropriate directory work successfully on the 8.1-STABLE 
machines.

Cheers,

Paul.


___
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: Support for Areca ARC-1300-4X on 8-STABLE?

[Paul Mather]

On Nov 24, 2010, at 12:32 AM, Jeremy Chadwick wrote:

 On Tue, Nov 23, 2010 at 09:41:43PM -0500, Paul Mather wrote:
 Does anyone know whether the Areca ARC-1300-4X external SAS HBA is
 currently supported under FreeBSD/amd64 8-STABLE?  I just fired up a
 system that has one of these cards that is running 8.0-RELEASE and the
 HBA is not being detected properly by FreeBSD.  (It is being
 misidentified by the arcmsr driver.)  I'm hoping that once I upgrade
 from 8.0-RELEASE to a contemporary 8-STABLE that it'll be supported.
 I found a posting on the Web that indicated a driver would be
 available in the first quarter of 2010
 (http://lists.freebsd.org/pipermail/freebsd-hardware/2009-December/006115.html).
 
 I'm really hoping I can use this card, though I'm somewhat discouraged
 by the fact that the Areca Web site lists only drivers for Windows,
 Linux, and Mac OS X for this particular model. :-(
 
 Have you contacted Areca about this?  Their Technical Support folks
 would be able to tell you why this is, and if there is work being done
 to provide a driver for FreeBSD.  A hardware vendor that is known to
 support FreeBSD is more authoritative about their drivers than the
 FreeBSD Project.  :-)

I'll concede the latter point, but I'd also hope that such a vendor would be 
contributing its drivers directly into the source tree rather than having a 
separate set of patches or downloads for end-users to fiddle about with.  I 
prefer my updates to come via csup. :-)

The only Areca port I can see is the one for the CLI for their RAID cards 
(sysutils/areca-cli).

I have contacted their support e-mail address asking what the situation is, 
from the horse's mouth, so to speak.  I hope the news is good.

 Also, please see this thread (which is very recent):
 
 http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/059985.html

Thanks for the link!  I'm not sure whether Fixed arcmsr driver prevent arcsas 
support for Areca SAS HBA ARC13x0 in the Bug fixes list is good news or bad 
news for me.  It suggests that the arcmsr driver has been fixed to prevent it 
attaching to the ARC-13X0 cards, implying that it is not supported.  This entry 
about OS support on the Areca official page for the ARC-1300 product 
(http://www.areca.us/products/sasnoneraid.htm) is also not inspiring: 
BSD/FreeBSD (will be available with 6Gb/s Host Adapter).  Does this mean only 
their 6 Gb/s cards will be supported under FreeBSD, or that support for the 3 
Gb/s cards will appear alongside the 6 Gb/s cards, whenever they are released?

I have to say all this has left a sour taste in my mouth.  I chose Areca 
because of their solid FreeBSD support. :-(

Cheers,

Paul.


___
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: Support for Areca ARC-1300-4X on 8-STABLE?

[Paul Mather]

On Nov 24, 2010, at 7:06 PM, Xin LI wrote:

 On Wed, Nov 24, 2010 at 7:01 AM, Paul Mather p...@gromit.dlib.vt.edu wrote:
 Thanks for the link!  I'm not sure whether Fixed arcmsr driver prevent 
 arcsas support for Areca SAS HBA ARC13x0 in the Bug fixes list is good 
 news or bad news for me.  It suggests that the arcmsr driver has been fixed 
 to prevent it attaching to the ARC-13X0 cards, implying that it is not 
 supported.  This entry about OS support on the Areca official page for the 
 ARC-1300 product (http://www.areca.us/products/sasnoneraid.htm) is also not 
 inspiring: BSD/FreeBSD (will be available with 6Gb/s Host Adapter).  Does 
 this mean only their 6 Gb/s cards will be supported under FreeBSD, or that 
 support for the 3 Gb/s cards will appear alongside the 6 Gb/s cards, 
 whenever they are released?
 
 The 6Gb/s cards are not released yet.  The updated driver resolved a
 conflict with the newer ARC13x0 cards, without it one will have to
 update arcmsr(4) before installing the SAS card driver.

So, to clarify, does this mean the 3 Gb/s ARC-1300 cards are not currently 
supported under 8-STABLE?  Or, are they supported by a different driver to 
arcmsr (if so, which one?), but arcmsr must be updated so it doesn't probe and 
claim the card instead?

Cheers,

Paul.

___
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

Support for Areca ARC-1300-4X on 8-STABLE?

[Paul Mather]

Does anyone know whether the Areca ARC-1300-4X external SAS HBA is currently 
supported under FreeBSD/amd64 8-STABLE?  I just fired up a system that has one 
of these cards that is running 8.0-RELEASE and the HBA is not being detected 
properly by FreeBSD.  (It is being misidentified by the arcmsr driver.)  I'm 
hoping that once I upgrade from 8.0-RELEASE to a contemporary 8-STABLE that 
it'll be supported.  I found a posting on the Web that indicated a driver would 
be available in the first quarter of 2010 
(http://lists.freebsd.org/pipermail/freebsd-hardware/2009-December/006115.html).

I'm really hoping I can use this card, though I'm somewhat discouraged by the 
fact that the Areca Web site lists only drivers for Windows, Linux, and Mac OS 
X for this particular model. :-(

Cheers,

Paul.

___
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: mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)

[Paul Mather]

On Sep 30, 2010, at 3:56 AM, Jeremy Chadwick wrote:

 The diff is pretty obvious/simple (2 line change), so the other
 databases/mysqlXX-server ports can be upgraded in the same manner.
 
 --- files/mysql-server.sh.in.orig 2010-03-27 03:24:53.0 -0700
 +++ files/mysql-server.sh.in  2010-09-30 00:45:38.0 -0700
 @@ -35,8 +35,8 @@
 mysql_user=mysql
 mysql_limits_args=-e -U ${mysql_user}
 pidfile=${mysql_dbdir}/`/bin/hostname`.pid
 -command=%%PREFIX%%/bin/mysqld_safe
 -command_args=--defaults-extra-file=${mysql_dbdir}/my.cnf 
 --user=${mysql_user} --datadir=${mysql_dbdir} --pid-file=${pidfile} 
 ${mysql_args}  /dev/null 21 
 +command=/usr/sbin/daemon
 +command_args=-c -f /usr/local/bin/mysqld_safe 
 --defaults-extra-file=${mysql_dbdir}/my.cnf --user=${mysql_user} 
 --datadir=${mysql_dbdir} --pid-file=${pidfile} ${mysql_args}

Shouldn't this be -c -f %%PREFIX%%/bin/mysqld_safe ... rather than 
hard-coding /usr/local?

 procname=%%PREFIX%%/libexec/mysqld
 start_precmd=${name}_prestart
 start_postcmd=${name}_poststart
 
 -- 
 | Jeremy Chadwick   j...@parodius.com |
 | Parodius Networking   http://www.parodius.com/ |
 | UNIX Systems Administrator  Mountain View, CA, USA |
 | Making life hard for others since 1977.  PGP: 4BD6C0CB |

Cheers,

Paul.___
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: MFC of ZFSv15

[Paul Mather]

On Sep 17, 2010, at 8:37 AM, Paul Mather wrote:

 On Sep 16, 2010, at 1:44 AM, Martin Matuska wrote:
 
 I have fixed the missing bits in r212688.
 
 Thanks for the notice.
 
 Dňa 15. 9. 2010 21:12, Xin LI  wrote / napísal(a):
 On 2010/09/15 11:30, Mike Tancsa wrote:
 At 02:07 PM 9/15/2010, Pascal Stumpf wrote:
 First of all, a great thanks to mm@ and pjd@ for the excellent work on
 ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.
 
 [...]
 here too.  RELENG_8 AMD64.  The tinderboxes havent hit that branch yet
 (http://tinderbox.freebsd.org/http://tinderbox.freebsd.org/), so it
 will be a few hrs before they get to test RELENG_8
 [...]
 -lsbuf  -lm -lnvpair -luutil -lutil
 /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent'
 *** Error code 1
 
 Sorry for that, it seems to be caused by a partial merge
 (cddl/compat/opensolaris/misc/mnttab.c).  mm@ is going to fix that ASAP.
 
 Cheers,
 
 I am getting a build failure on 8.1-STABLE:
 
 =
 [[...]]
 cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
 -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
 -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
 -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
 -finline-limit=8000 --param inline-unit-growth=100 --param 
 large-function-growth=1000  -mno-align-long-strings 
 -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
 -mno-sse3 -ffreestanding -fstack-protector -Werror  
 /usr/src/sys/kern/p1003_1b.c
 cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
 -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
 -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
 -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
 -finline-limit=8000 --param inline-unit-growth=100 --param 
 large-function-growth=1000  -mno-align-long-strings 
 -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
 -mno-sse3 -ffreestanding -fstack-protector -Werror  
 /usr/src/sys/kern/posix4_mib.c
 cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
 -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
 -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
 -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
 -finline-limit=8000 --param inline-unit-growth=100 --param 
 large-function-growth=1000  -mno-align-long-strings 
 -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
 -mno-sse3 -ffreestanding -fstack-protector -Werror  
 /usr/src/sys/kern/sched_ule.c
 cc1: warnings being treated as errors
 /usr/src/sys/kern/sched_ule.c: In function 'sched_switch':
 /usr/src/sys/kern/sched_ule.c:1807: warning: implicit declaration of function 
 'sched_pickcpu'
 /usr/src/sys/kern/sched_ule.c:1807: warning: nested extern declaration of 
 'sched_pickcpu'
 *** Error code 1
 
 Stop in /usr/obj/usr/src/sys/BACKUP.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 =
 
 Unfortunately (for me, I guess), GENERIC will build successfully on this 
 system.  It's only my custom kernel config file that is failing make 
 buildkernel.  The custom kernel config is GENERIC with various inapplicable 
 drivers removed, plus some non-GENERIC things added in (such as ALTQ support 
 options).  I am building via the standard make buildworld followed by make 
 buildkernel method.  Can anyone spot anything obviously awry?  I've included 
 my config file at the end.

Just to follow up myself, here: I added options SMP to my custom kernel 
config file and that allowed me successfully to finish make buildkernel ... 
without error.

So, is options SMP mandatory now on FreeBSD/i386 (even on uniprocessor 
systems), and, if so, shouldn't it be included in DEFAULTS?

Cheers,

Paul.

Re: MFC of ZFSv15

[Paul Mather]

On Sep 16, 2010, at 1:44 AM, Martin Matuska wrote:

 I have fixed the missing bits in r212688.
 
 Thanks for the notice.
 
 Dňa 15. 9. 2010 21:12, Xin LI  wrote / napísal(a):
 On 2010/09/15 11:30, Mike Tancsa wrote:
 At 02:07 PM 9/15/2010, Pascal Stumpf wrote:
 First of all, a great thanks to mm@ and pjd@ for the excellent work on
 ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.
 
 [...]
 here too.  RELENG_8 AMD64.  The tinderboxes havent hit that branch yet
 (http://tinderbox.freebsd.org/http://tinderbox.freebsd.org/), so it
 will be a few hrs before they get to test RELENG_8
 [...]
 -lsbuf  -lm -lnvpair -luutil -lutil
 /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent'
 *** Error code 1
 
 Sorry for that, it seems to be caused by a partial merge
 (cddl/compat/opensolaris/misc/mnttab.c).  mm@ is going to fix that ASAP.
 
 Cheers,

I am getting a build failure on 8.1-STABLE:

=
[[...]]
cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mno-align-long-strings 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-ffreestanding -fstack-protector -Werror  /usr/src/sys/kern/p1003_1b.c
cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mno-align-long-strings 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-ffreestanding -fstack-protector -Werror  /usr/src/sys/kern/posix4_mib.c
cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mno-align-long-strings 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-ffreestanding -fstack-protector -Werror  /usr/src/sys/kern/sched_ule.c
cc1: warnings being treated as errors
/usr/src/sys/kern/sched_ule.c: In function 'sched_switch':
/usr/src/sys/kern/sched_ule.c:1807: warning: implicit declaration of function 
'sched_pickcpu'
/usr/src/sys/kern/sched_ule.c:1807: warning: nested extern declaration of 
'sched_pickcpu'
*** Error code 1

Stop in /usr/obj/usr/src/sys/BACKUP.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
=

Unfortunately (for me, I guess), GENERIC will build successfully on this 
system.  It's only my custom kernel config file that is failing make 
buildkernel.  The custom kernel config is GENERIC with various inapplicable 
drivers removed, plus some non-GENERIC things added in (such as ALTQ support 
options).  I am building via the standard make buildworld followed by make 
buildkernel method.  Can anyone spot anything obviously awry?  I've included 
my config file at the end.

Cheers,

Paul.

#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.19 2009/07/15 08:32:19 ed Exp $

cpu I586_CPU
cpu I686_CPU
ident   BACKUP

# To statically compile in device wiring instead of /boot/device.hints
#hints  GENERIC.hints # Default places to look for devices.

#makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols

#optionsSCHED_4BSD  # 4BSD scheduler
options SCHED_ULE   # ULE scheduler
options 

Re: Using GTP and glabel for ZFS arrays

[Paul Mather]

On Jul 21, 2010, at 11:05 PM, Dan Langille wrote:

 I hope my terminology is correct
 
 I have a ZFS array which uses raw devices.  I'd rather it use glabel and 
 supply the GEOM devices to ZFS instead.  In addition, I'll also partition the 
 HDD to avoid using the entire HDD: leave a little bit of space at the start 
 and end.
 
 Why use glabel?
 
 * So ZFS can find and use the correct HDD should the HDD device ever
   get renumbered for whatever reason.  e.g. /dev/da0 becomes /dev/da6
   when you move it to another controller.

I have created ZFS pools using this strategy.  However, about a year ago I 
still fell foul of the drive shuffling problem, when GEOM labels appeared not 
to be detected properly:

http://lists.freebsd.org/pipermail/freebsd-geom/2009-July/003654.html

This was using RELENG_7, and the problem was provoked by external USB drives.

The same issue might not occur with FreeBSD 8.x, but I thought I'd point out my 
experience as a possible warning about using glabel.

Nowadays, I use GPT labels (gpart ... -l somelabel, referenced via 
/dev/gpt/somelabel).

 Why use partitions?
 
 * Primarily: two HDD of a given size, say 2TB, do not always provide
   the same amount of available space.  If you use a slightly smaller
   partition instead of the entire physical HDD, you're much more
   likely to have a happier experience when it comes time to replace an
   HDD.
 
 * There seems to be a consensus amongst some that leaving the start and
   and of your HDD empty.  Give the rest to ZFS.

You should also try and accommodate 4K sector size drives these days.  
Apparently, the performance boosts from hitting 4K-aligned sectors can be very 
good.

Cheers,

Paul.___
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: 8.x grudges

[Paul Mather]

On Jul 7, 2010, at 5:39 PM, Garrett Cooper wrote:

 On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
 07.07.2010 14:59, Jeremy Chadwick ???(??):
 
  FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and
  thus not an option) -- the kernel-config files, that worked with
  7.x, break without this option in them (in addition to all the
  nuisance, that's documented in UPDATING -- which, somehow, makes
  the breakage acceptable). config(8) would not warn about this, but
  kernel build fails.
 
 
 We don't use this option (meaning it's removed from our kernels).  It's
 definitely not required.  All it does is ensure your kernel can
 comprehend executables/binaries built on 7.x.
 
 
 Attached is the kernel config-file (i386), that worked fine under 7.x. The
 kernel-compile will break (some *freebsd7* structs undefined), without the
 COMPAT_FREEBSD7 option. Try it for yourself...
 
 options   SYSVSHM # SYSV-style shared memory
 options   SYSVMSG # SYSV-style message queues
 options   SYSVSEM # SYSV-style semaphores
 
 Those require COMPAT_FREEBSD7. 

I have an FreeBSD/amd64 8.1-PRERELEASE system with all COMPAT_FREEBSDx options 
except COMPAT_FREEBSD32 commented out in my kernel config file and it builds 
fine.  So, unless I am misunderstanding you, I don't think options 
SYSV{SHM,MSG,SEM} requires COMPAT_FREEBSD7.

Cheers,

Paul.

___
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 with ATA_CAM support in RELENG_8

[Paul Mather]

On Jun 30, 2010, at 5:18 PM, Alexander Motin wrote:

 Paul Mather wrote:
 PS: ATA_STATIC_ID is useless when ATA_CAM option enabled.
 
 Thank you (and Jeremy Chadwick) for the help and information.  The kernel 
 configuration options I used above were taken from a VirtualBox 
 FreeBSD/amd64 install I have that I converted over to ATA_CAM when the code 
 first went into RELENG_8 and it wasn't exactly clear at the time what 
 options were absolutely required.  (I'm not even sure that options ATA_CAM 
 is needed any more, given device ahci implies it.)
 
 `options ATA_CAM` enables CAM wrapper for legacy drivers, which gave you
 adaX devices instead of adX. It doesn't give major benefits, just
 unifies behavior.

So, does that mean if you omit options ATA_CAM and have device ahci you 
will get adX devices, not adaX devices?  In other words, if you have device 
ahci (or device siis or device mvs) will you will always get adaX devices, 
whether or not you have options ATA_CAM in your kernel config file?

Does options ATA_CAM work with device ata or the modular ATA subsystem?  Is 
that the intended use of options ATA_CAM: to provide adaX devices and a CAM 
interface for accessing ATA devices?

Cheers,

Paul.___
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

Problems with ATA_CAM support in RELENG_8

[Paul Mather]

I am running FreeBSD/amd64 RELENG_8 on a Dell Optiplex 745.  The hard drive in 
the system is SATA and I have Normal, not Legacy SATA support enabled in 
the BIOS.  (BIOS is V2.6.4.)  I am assuming this will enable native AHCI mode 
for the drive.

I built a kernel with ATA_CAM support, but for some reason the SATA drive is 
probing at slow, UDMA2, speeds:

ada0 at ata2 bus 0 scbus0 target 0 lun 0
ada0: ST3160812AS 3.ADJ ATA-7 SATA 2.x device
ada0: 33.300MB/s transfers (UDMA2, PIO 8192bytes)
ada0: 152587MB (31250 512 byte sectors: 16H 63S/T 16383C)

When I run camcontrol identify on the drive, it states the drive is capable 
of UDMA6 speeds:

backup# camcontrol identify ada0
pass0: ST3160812AS 3.ADJ ATA-7 SATA 2.x device
pass0: 33.300MB/s transfers (UDMA2, PIO 8192bytes)

protocol  ATA/ATAPI-7 SATA 2.x
device model  ST3160812AS
firmware revision 3.ADJ
serial number 5LS8PPDD
cylinders 16383
heads 16
sectors/track 63
sector size   logical 512, physical 512, offset 0
LBA supported 268435455 sectors
LBA48 supported   31250 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA6 

Feature  Support  EnableValue   Vendor
read ahead yes  yes
write cacheyes  yes
flush cacheyes  yes
overlapno
Tagged Command Queuing (TCQ)   no   no
Native Command Queuing (NCQ)   yes  32 tags
SMART  yes  yes
microcode download yes  yes
security   yes  no
power management   yes  yes
advanced power management  no   no  65278/0xFEFE
automatic acoustic management  yes  yes 254/0xFE208/0xD0
media status notification  no   no
power-up in Standbyno   no
write-read-verify  no   no  0/0x0
unload no   no
free-fall  no   no
data set management (TRIM) no


So, why the slower speed?  Also, camcontrol identify states the drive 
supports NCQ with up to 32 tags supported, yet camcontrol tags ada0 reports 
only 1 device opening, not 32 as I would expect:

backup# camcontrol tags ada0
(pass0:ata2:0:0:0): device openings: 1

To enable ATA_CAM AHCI support, I included this in my kernel config file:

# ATA and ATAPI devices
options ATA_CAM
device  ahci
device  atacore
device  atapci
options ATA_STATIC_ID   # Static device numbering

Is this the correct way to enable ATA_CAM AHCI support?  I tried initially 
including just options ATA_CAM and device ahci but the resultant kernel 
would not probe my disk drive as ada0.

Does my problem lie with my kernel config or is the Dell Optiplex 745 BIOS 
brain dead when it comes to AHCI native support?  The only option it appears to 
have in the BIOS is Normal and Legacy when it comes to the SATA controller 
mode.

I've attached my full kernel config and dmesg at the end of this e-mail.

Cheers,

Paul.

Kernel config:

#
# GENERIC -- Generic kernel configuration file for FreeBSD/amd64
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.13 2010/05/02 06:24:17 imp Exp 
$

cpu HAMMER
ident   VPN

# To statically compile in device wiring instead of /boot/device.hints
#hints  GENERIC.hints # Default places to look for devices.

# Use the following to compile in values accessible to the kernel
# through getenv() (or kenv(1) in userland). The format of the file
# is 'variable=value', see kenv(1)
#
# env   GENERIC.env

#makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols

options SCHED_ULE   # ULE scheduler
options PREEMPTION  # Enable kernel thread preemption
options INET# InterNETworking
options INET6   # IPv6 communications protocols
options SCTP# Stream Control Transmission Protocol
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # 

Re: Problems with ATA_CAM support in RELENG_8

[Paul Mather]

On Jun 30, 2010, at 1:38 PM, Alexander Motin wrote:

 To enable ATA_CAM AHCI support, I included this in my kernel config file:
 
 # ATA and ATAPI devices
 options ATA_CAM
 device  ahci
 device  atacore
 device  atapci
 options ATA_STATIC_ID   # Static device numbering
 
 Is this the correct way to enable ATA_CAM AHCI support?  I tried
 initially including just options ATA_CAM and device ahci but the
 resultant kernel would not probe my disk drive as ada0.
 
 Your controller seems to not report AHCI support. In such case legacy
 mode driver attaches to it. But as soon as you have no `device ataintel`
 line, only generic driver was there, limited by UDMA2 mode.
 
 PS: ATA_STATIC_ID is useless when ATA_CAM option enabled.

Thank you (and Jeremy Chadwick) for the help and information.  The kernel 
configuration options I used above were taken from a VirtualBox FreeBSD/amd64 
install I have that I converted over to ATA_CAM when the code first went into 
RELENG_8 and it wasn't exactly clear at the time what options were absolutely 
required.  (I'm not even sure that options ATA_CAM is needed any more, given 
device ahci implies it.)

 Does my problem lie with my kernel config or is the Dell Optiplex 745
 BIOS brain dead when it comes to AHCI native support?  The only option
 it appears to have in the BIOS is Normal and Legacy when it comes
 to the SATA controller mode.
 
 Your controller is not identified as AHCI:
 
 atapci0: Intel ATA controller port
 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfecf,0xecc0-0xeccf
 irq 20 at device 31.2 on pci0
 atapci0: [ITHREAD]
 ata2: ATA channel 0 on atapci0
 ata2: [ITHREAD]
 ata3: ATA channel 1 on atapci0
 ata3: [ITHREAD]
 atapci1: Intel ATA controller port
 0xfe40-0xfe47,0xfe50-0xfe53,0xfe60-0xfe67,0xfe70-0xfe73,0xfed0-0xfedf,0xecd0-0xecdf
 irq 20 at device 31.5 on pci0
 atapci1: [ITHREAD]
 ata4: ATA channel 0 on atapci1
 ata4: [ITHREAD]
 ata5: ATA channel 1 on atapci1
 ata5: [ITHREAD]
 
 You may check `pciconf -lvcb` output. For ICH8 with AHCI you should see
 there something like:
 ah...@pci0:0:31:2:  class=0x010601 card=0xa00c14ff chip=0x28298086
 rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile SATA AHCI Controller'
class  = mass storage
subclass   = SATA
bar   [10] = type I/O Port, range 32, base 0xe880, size  8, enabled
bar   [14] = type I/O Port, range 32, base 0xe800, size  4, enabled
bar   [18] = type I/O Port, range 32, base 0xe480, size  8, enabled
bar   [1c] = type I/O Port, range 32, base 0xe400, size  4, enabled
bar   [20] = type I/O Port, range 32, base 0xe080, size 32, enabled
bar   [24] = type Memory, range 32, base 0xfeaff800, size 2048, enabled
cap 05[80] = MSI supports 4 messages enabled with 4 messages
cap 01[70] = powerspec 3  supports D0 D3  current D0
cap 12[a8] = SATA Index-Data Pair
 
 Pay attention to subclass = SATA.

Then that's where my problem lies:

atap...@pci0:0:31:2:class=0x01018f card=0x01da1028 chip=0x28208086 rev=0x02 
hdr=0x00
vendor = 'Intel Corporation'
device = 'SATA IDE Controller:4 port (82801HB/HR/HH/HO)'
class  = mass storage
subclass   = ATA
bar   [10] = type I/O Port, range 32, base 0xfe00, size  8, enabled
bar   [14] = type I/O Port, range 32, base 0xfe10, size  4, enabled
bar   [18] = type I/O Port, range 32, base 0xfe20, size  8, enabled
bar   [1c] = type I/O Port, range 32, base 0xfe30, size  4, enabled
bar   [20] = type I/O Port, range 32, base 0xfec0, size 16, enabled
bar   [24] = type I/O Port, range 32, base 0xecc0, size 16, enabled
cap 01[70] = powerspec 3  supports D0 D3  current D0

atap...@pci0:0:31:5:class=0x010185 card=0x01da1028 chip=0x28258086 rev=0x02 
hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) 2 port SATA Controller'
class  = mass storage
subclass   = ATA
bar   [10] = type I/O Port, range 32, base 0xfe40, size  8, enabled
bar   [14] = type I/O Port, range 32, base 0xfe50, size  4, enabled
bar   [18] = type I/O Port, range 32, base 0xfe60, size  8, enabled
bar   [1c] = type I/O Port, range 32, base 0xfe70, size  4, enabled
bar   [20] = type I/O Port, range 32, base 0xfed0, size 16, enabled
bar   [24] = type I/O Port, range 32, base 0xecd0, size 16, enabled
cap 01[70] = powerspec 3  supports D0 D3  current D0


I thought ICH8 supported AHCI, but maybe it's only ICH8R that does?  I'm 
assuming that subclass = ATA means the controller can't operate in AHCI mode. 
 The BIOS setting is also confusing.  It has two options, Normal and 
Legacy.  Normal mode says, The hard drive controller is configured for 
native mode.  This mode provides the highest drive performance and most 
flexibility.  I guess I misinterpreted native mode to be AHCI mode.

Thanks again for the help and for clearing things up.

Cheers,

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

[Paul Mather]

On May 30, 2010, at 10:35 PM, David Magda wrote:

 An event framework would certainly be helpful in a general sense (Linux has 
 event(3) AFAIK), and that could certainly be useful for purging snapshots 
 during resource constrained situations. But even if we don't have it, I doubt 
 a fork(2) from cron(8) and a statfs(2) would be onerous on a system. :)

Devd already receives several ZFS-based events (failed vdev, I/O error, 
checksum mismatch, etc.), so perhaps it would be useful to add another, e.g., 
space which is set to be triggered when a pool attains a certain percentage 
full.  This could default to 100%, but be capable of being set lower by an 
associated kernel sysctl.  You could then have any auto-pruning/snapshot 
management script triggered from devd.  (You'd probably also have to figure out 
some kind of throttling mechanism for this devd event, too.)

Cheers,

Paul.

___
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 world fails in usr.sbin/config?

[Paul Mather]

On May 24, 2010, at 8:29 AM, Jeremy Chadwick wrote:

 For added posterity, it looks like usr.sbin/config has been mostly
 untouched for quite some time, sans mkoptions.c and mkmakefile.c:
 
 http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/config/

Having said that, there is this entry in /usr/src/UPDATING dating from early 
May:

20100502:
The config(8) command has been updated to maintain compatibility
with config files from 8.0-RELEASE.  You will need a new version
of config to build kernels (this version can be used from 8.0-RELEASE
forward).  The buildworld target will generate it, so following
the instructions in this file for updating will work glitch-free.
Merely doing a make buildkernel without first doing a make buildworld
(or kernel-toolchain), or attempting to build a kernel using
traidtional methods will generate a config version warning, indicating
you should update.


Stefan's kernel looks to have last been built on 20th February 2010.  It isn't 
explicit in the first posting of this thread how Stefan is doing his build, so 
there is a possibility that he's being affected by the above UPDATING entry.

Cheers,

Paul.

___
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 world fails in usr.sbin/config?

[Paul Mather]

On May 24, 2010, at 9:27 AM, Stefan Bethke wrote:

 I've just moved from a root on UFS plus data on ZFS setup, to root on ZFS; 
 that's the only real difference I can think of.  Although I don't see how 
 that would affect building world, especially since I've had src and obj on 
 ZFS before.

FWIW, I successfully completed buildworld + buildkernel for 8-STABLE on a 
root-on-ZFS system yesterday.

Cheers,

Paul.

___
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

ZFS pool upgrade to v14 broke ZFS booting

[Paul Mather]

I have a FreeBSD guest running under VirtualBox 3.1.2 on Mac OS X.  It's 
running a recent 8-STABLE and is a ZFS-only install booting via gptzfsboot.  I 
use this VirtualBox guest as a test install.

A day or so ago I noticed zpool status report that my pool could be upgraded 
from v13 to v14.  I did this, via zfs upgrade -a.

Today, when attempting to fire up this FreeBSD guest in VirtualBox I get this 
on the console:

=
ZFS: unsupported ZFS version 14 (should be 13)
No ZFS pools located, can't boot
_
=

and the boot halts at that point.  I don't see the boot menu I normally see 
that lists the opportunity to boot single-user; disable ACPI; and so on.

Has anyone else experienced this?  Is this a mismatch between gptzfsboot and my 
current pool version?  (Gptzfsboot includes the message I'm seeing.)  Am I 
supposed to rebuild and replace gptzfsboot every time the pool version is 
updated?  (There was no advisory in /usr/src/UPDATING concerning this, nor do I 
remember seeing it elsewhere.)

Now I have to figure out how to dig out from this.  Well, I guess that's what 
test installations are for... :-)

Cheers,

Paul.___
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: dumping large partition to USB drive fails

[Paul Mather]

On 28 Jun 2007, at 9:06 PM, Roland Smith wrote:


On Thu, Jun 28, 2007 at 12:24:15PM -0700, Jeremy Chadwick wrote:

On Thu, Jun 28, 2007 at 08:55:46PM +0200, Roland Smith wrote:
A tip from Paul Mather pointed to problems with USB/firewire  
chipset,
the PL-3507, which was what I found in my enclosure. Most likely  
this is

the culprit. I'm going to buy a new enclosure.


Can you provide these details (forward what Paul sent you, etc.)?  It
would be nice to have this info somewhere in the archives in case
someone mails about similar...


Here it is;


I don't have your original posting, so I don't know what model of
chipset you have, though I do dimly recall it being a Prolific,  
which is

why I thought I'd e-mail you.  Given that the PL3507 had an early
history of problems when writing to it using large transfers (and  
that
GELI uses large transfers, IIRC), and you say that enclosure is  
old, you

might want to see if chipset bugs are the source of your problem.

Here is a link I had bookmarked when I was looking for firmware  
updates for

the Prolific PL3507:
http://missig.org/julian/blog/2004/06/10/prolific-pl3507-firewire- 
device/


Here is a link to the corruption issue that plagued various chipsets,
including the Prolific PL3507:
http://www.bustrace.com/delayedwrite/index.htm


My apologies for not doing a reply all when responding to Roland  
initially.  As a bit of extra context to the above, a while ago I  
bought a cheap external FireWire/USB DVD writer for my iBook G4.  I  
was disappointed to discover upon using it that its read performance  
when using the FireWire interface was much poorer than when using its  
USB connector.  (It annoyed me especially because I had bought  
something that supported FireWire because I wanted to daisy-chain it  
with my Western Digital MyBook external hard drive to avoid using up  
one of the two USB ports on my iBook.)


Because the FireWire and USB performance of my MyBook external hard  
drive is good, I doubted the problem lay with the iBook, and  
suspected the enclosure chipset instead.  When I began searching the  
Web for information about the Prolific PL3507 chipset, used in the  
enclosure, I quickly began discovering horror stories (see above  
links for a taste).  I realised that, if I had my time over and had  
known this DVD writer's enclosure used that chipset, I would not have  
bought it and would have looked for something whose enclosure used a  
different one (e.g., Oxford).  I also realised that not all  
enclosures are created equal, and it's definitely worthwhile to know  
what chipset it uses beforehand and make sure you avoid the bad ones  
(like the Prolific). :-)


Somewhat fortunately, revisions B and C of the Prolific PL3507 can  
have their firmware upgraded via USB.  (Unfortunately, Prolific only  
appear to make a Windows flash writer application available.)  It  
seems that the latest firmware at least appears to correct the worst  
excesses of the chipset, though people do still seem to harbour  
mistrust over the hardware and complain of performance problems.


Although I have no plans to buy another enclosure for this DVD writer  
(because it works well enough for the task in hand), I think I  
would were it housing a hard drive, if nothing else because of the  
poor performance relative to the WD MyBook.


Cheers,

Paul.

e-mail: [EMAIL PROTECTED]

Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid.
--- Frank Vincent Zappa


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

Re: bge watchdog timeouts still happening

[Paul Mather]

On Fri, 2006-09-15 at 12:33 -0700, Kent Stewart wrote:
 On Friday 15 September 2006 09:28, Herve Boulouis wrote:
  Le 15/09/2006  18:05, Gleb Smirnoff a écrit:
   H bge0: Broadcom BCM5700 B2, ASIC rev. 0x7102 mem
   0xfeb0-0xfeb0 irq 17 at device 8.0 on pci1 H miibus0: MII
   bus on bge0
   H brgphy0: BCM5401 10/100/1000baseTX PHY on miibus0
   H brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
   1000baseTX, 1000baseTX-FDX, auto H bge0: Ethernet address:
   00:06:5b:1a:7f:4a
  
   Is it integrated or not? I've got exactly the same NIC and I can
   try to reproduce the problem if you describe the workload.
 
  Yes, it's the onboard bge. Workload is 10-25 Mbit/s of web hosting.
 
 It seems to be at the top of the tree somewhere because people are also 
 seeing the watchdog timeouts on em and I get them on the gigabit re's.
 
 I got them downloading the kde-3.5.4 distfiles on a 768kb DSL line. I 
 had setiathome running, which keeps the cpu useage close to 100%.

FWIW, I get repeated watchdog timeout errors on 6-STABLE with a
dc-based Cardus NIC (Netgear FA511).  The worst behaviour I observed was
under heavy NFS load, with the link being unavailable for extended
periods of time.  Mostly, though, the problem manifests itself when the
card is inserted and the interface is trying to be brought up via DHCP
using dhclient, as if the NIC is not being initialised properly,
perhaps.

I don't know if this is the same problem, but I thought I'd mention it.

Cheers,

Paul.
-- 
e-mail: [EMAIL PROTECTED]

Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid.
--- Frank Vincent Zappa
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

cardbus0: Resource not specified in CIS: id=14, size=400?????

[Paul Mather]

I have a Netgear FA511 Cardbus NIC that I am trying to use in a Dell
Inspiron 8600 laptop running 6.1-STABLE, but with limited success.  When
I insert it, I get the message cardbus0: Resource not specified in CIS:
id=14, size=400 appear as part of the cardbus probe.  The card
superficially works, but very unreliably (e.g., quite a few dc0:
watchdog timeout messages and no network traffic at times).

What does cardbus0: Resource not specified in CIS: id=14, size=400
mean?  Is this a hardware or a firmware or a driver issue?

When I insert the NIC into the Dell Inspiron 8600 laptop, the MAC
address that gets assigned to the interface is 00-00-00-00-00-00.  This
happens both under FreeBSD and Windows XP.  However, when I tried the
NIC in a friend's Acer laptop, the MAC address was correctly reported by
Windows XP (couldn't try FreeBSD), and corresponds with the one printed
on the underside of the NIC.  So, it seems that the Cardbus NIC itself
is okay, just not in the Dell laptop. :-(

Is this something that is fixable, e.g., with a suitable device.hints or
sysctl setting?

Here's what is output on the Dell Inspiron 8600 when I insert the
Netgear FA511 NIC (extra cardbus debugging enabled):

cbb0: card inserted: event=0x, state=3920
cbb0: cbb_power: 3V
TUPLE: LINKTARGET [3]: 43 49 53
Product version: 5.0
Product name: NETGEAR, Inc. | FA511 | CardBus Mobile Adapter | 1.00 | 
Manufacturer ID: 2d021a51
Functions: Network Adaptor, Multi-Functioned
Function Extension: 0102
Function Extension: 0280969800
Function Extension: 0200e1f505
Function Extension: 0301
cardbus0: Opening BAR: type=IO, bar=10, len=0100
TUPLE: Unknown(0x04) [7]: 03 01 00 00 00 00 ff
TUPLE: Unknown(0x05) [5]: 41 80 fb 00 ff
CIS reading done
cardbus0: Resource not specified in CIS: id=14, size=400
cardbus0: Non-prefetchable memory at f6001000-f60013ff
cardbus0: IO port at d000-d0ff
dc0: Netgear FA511 10/100BaseTX port 0xd000-0xd0ff mem 0xf6001000-0xf60013ff 
irq 11 at device 0.0 on cardbus0
miibus0: MII bus on dc0
ukphy0: Generic IEEE 802.3u media interface on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: link state changed to DOWN
dc0: link state changed to UP


Here is how the Cardbus adapter is probed during boot:

pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pci_link1: BIOS IRQ 11 for 2.3.INTA is invalid
pci2: ACPI PCI bus on pcib2
cbb0: TI4510 PCI-CardBus Bridge at device 1.0 on pci2
cbb0: Found memory at f600
cbb0: Secondary bus is 0
cbb0: Setting primary bus to 2
cbb0: Secondary bus set to 3 subbus 4
cardbus0: CardBus bus on cbb0
pccard0: 16-bit PCCard bus on cbb0


Finally, here is the output of pciconf -vl for the laptop (the
PCI4510SDFSDFSD PC Card Controller SDFSDAFSADFSDAFSDAF description for
the Cardbus bridge looks highly suspicious to me):

[EMAIL PROTECTED]:0:0:class=0x06 card=0x016a1028 chip=0x33408086 
rev=0x03 hdr=0x00
vendor   = 'Intel Corporation'
device   = '82855PM Host-Hub Interface Bridge'
class= bridge
subclass = HOST-PCI
[EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x33418086 rev=0x03 
hdr=0x01
vendor   = 'Intel Corporation'
device   = '82855PM AGP Bridge'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x016a1028 chip=0x24c28086 
rev=0x01 hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x016a1028 chip=0x24c48086 
rev=0x01 hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:2:class=0x0c0300 card=0x016a1028 chip=0x24c78086 
rev=0x01 hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x016a1028 chip=0x24cd8086 
rev=0x01 hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB 2.0 EHCI Controller'
class= serial bus
subclass = USB
[EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x24488086 
rev=0x81 hdr=0x01
vendor   = 'Intel Corporation'
device   = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge'
class= bridge
subclass = PCI-PCI
[EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x24cc8086 
rev=0x01 hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DBM (ICH4-M) LPC Interface Bridge'
class= bridge
subclass = PCI-ISA
[EMAIL PROTECTED]:31:1:  class=0x01018a card=0x016a1028 chip=0x24ca8086 
rev=0x01 hdr=0x00
vendor   = 'Intel Corporation'
device   = '82801DBM (ICH4-M) UltraATA/100 EIDE Controller'
class= mass storage
subclass = ATA
[EMAIL 

Re: portsnap mirror servers

[Paul Mather]

On Fri, 2006-04-21 at 14:40 +0200, Benjamin Lutz wrote:
 On Wednesday 19 April 2006 00:44, Colin Percival wrote:
  I have a list of people who have offered mirrors, but so far I haven't
  seen any need for additional mirrors -- the two which already exist are
  showing no signs of slowing down.
 
 Hm, but I see a quite noticeable speed difference between portsnap1 and 
 portsnap2. The second one is quite a bit faster.

I notice that on 4.x portsnap never finds any mirrors because the grep
of the output returned by host -t srv ... is not appropriate for 4.x's
version of /usr/bin/host, which produces output different to that of 5.x
onwards (a BIND8 vs BIND9 issue, I guess).  So, maybe because of this,
all of the portsnaps running on 4.x machines are hitting the same server
each time instead of randomly choosing a mirror, thereby causing that
mirror to be a bit more loaded?

Cheers,

Paul.
-- 
e-mail: [EMAIL PROTECTED]

Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid.
--- Frank Vincent Zappa


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

Re: opinion on which software RAID to use

[Paul Mather]

On Thu, 2006-03-02 at 14:11 -0500, Vivek Khera wrote:

 Anyhow, I see at least three ways to set up a mirror of these drives  
 and/or partitions:
 
   gvinum
   gmirror
   atacontrol
 
 Any opinions on which has both qualities: easy to configure/manage  
 (ie, recover after failure) and performance?  The handbook RAID page  
 doesn't even mention gmirror.  The atacontrol seems very simple to  
 use, at least.
 
 Let me know what you think.  Thanks!

For basic mirroring, I'd say go for gmirror.  I've been using it
successfully for a long time.  I migrated to it from vinum/gvinum
because it offered more flexible read load-balancing (you can choose
between various policies) and easier recovery.  It can even do N-way
mirroring.

I tried atacontrol in the past, but could never get it to reconstruct
after a simulated failure.  With gmirror, you have the option of
automatic or manual reconstruction for failed/stale providers.

You might want to consider gvinum if you think you might want to use
RAID 5 or LVM-type aggregations in the future, but if you are just
planning on mirroring I'd strongly suggest going with gmirror.

Cheers,

Paul.
-- 
e-mail: [EMAIL PROTECTED]

Without music to decorate it, time is just a bunch of boring production
 deadlines or dates by which bills must be paid.
--- Frank Vincent Zappa
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]