Re: authentication errors on 'make fetchindex' in /usr/ports

[Sean C. Farley]

On Thu, 3 Dec 2020, Bob Willcox wrote:

I am trying to upgrade a 12.1-stable system installed back in July to 
12.2-stable.  I downloaded the new ports hierarchy and now when I 
attempt to run 'make fetchindex'

I get these errors:

/usr/bin/env  fetch -am -o /usr/ports/INDEX-12.bz2 
https://www.FreeBSD.org/ports/INDEX-12.bz2
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
Authority X3
546533376:error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify 
failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
fetch: https://www.FreeBSD.org/ports/INDEX-12.bz2: Authentication error
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt 
Authority X3
546533376:error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify 
failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:

Can someone help?

Thanks,
Bob


That looks like you need to run certctl(8):  certctl rehash.

This is the commit that brought it into 11-STABLE and 12-STABLE: 
https://svnweb.freebsd.org/base?view=revision=357082


However, I recommend reading the man page for it first in case you have 
cert hashes already in a place like /etc/ssl/certs.  It took me a bit by 
surprise because my hashes that were linked from a separate directory 
were removed.


Sean
--
s...@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"

System unresponsive upon panic

[Sean C. Farley]

Occasionally, I do something (i.e., attempt to run VirtualBox) that 
provokes a panic on my workstation.  When this happens, the system 
becomes completely unresponsive where not even a shutdown signal from 
pressing the power button works.  It is probably a kernel panic, but 
there is no dump and no reboot.  There is only a hard freeze.


Due to running GEOM_RAID, this leads to a nice long synchronization 
compared to if it did reboot, so I am trying to figure out how to fix 
that problem.  I suspect the Nvidia driver (v440.100 built from ports) 
is somehow related to this, I am not certain.


System details:
FreeBSD 12-STABLE (r365263), but this has been happening for awhile
nvidia-driver-440.100
GeForce GTX 960
UFS + Intel ICH8+ RAID1
Dump disabled or enabled matters not.

To see if it mattered if X was the active console or the type of panic 
mattered, I forced a panic from the console (ttyv0) while X was running. 
This is all it gave me before becoming unresponsive.


-
panic: kdb_sysctl_panic
cpuid = 1
time = 1599367793
KDB: stack backtrace
#0 0x80731ec5 at kdb_backtrace+0x65
#1 0x806e615b at vpanic+0x17b
#2 0x806e5fd3 at panic+0x43
#3 0x80732891 at kdb_sysctl_panic+0x61
#4 0x806f503a at sysctl_root_handler_locked+0x8a
#5 0x806f4469 at sysctl_root+0x249
#6 0x806f4ad8 at userland_sysctl+0x178
#7 0x806f491f at sys___sysctl+0x5f
#8 0x80a324c7 at amd64_syscall+0x387
#9 0x80a0995e at fast_syscall_common+0xf8
Uptime: 1m52s
-

Now, if I do the same without X running, then it spits out a stacktrace 
and reboots.


Should the system at least reboot when this happens?  Does it matter 
what options are used to build the Nvidia driver such as ACPI, which I 
have enabled?


Sean
--
s...@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: 12.1 release symbol incompatibility? [disregard report]

[Sean Bruno]

On 2019-09-19 00:21, Konstantin Belousov wrote:
> On Wed, Sep 18, 2019 at 03:05:34PM -0600, Sean Bruno wrote:
>> If one installs 12.1 and tries to run a 12.0 release package (postgresql
>> server for instance), it fails due to a missing symbol:
>>
>>  # service postgresql start
>> /usr/local/bin/pg_ctl: Undefined symbol "stat@FBSD_1.5"
>>
>> I think this is a bug as we are supposed to support this kind of thing,
>> right?
> 
> I do not think it is a bug in the base system.  You seems to install
> stable/11 libc.  How did you get that libc, is a different question.
> 
> The stat@FBSD_1.5 symbol was added during the CURRENT-12 lifecycle due
> to the ino64 work, and was there at the branch point for 12. Of course
> nobody removed it from libc since then.
> 

This is definitely the case here.  Somehow I had this jail running 11.x,
even though the host was 12.x.  This report is noise, and I apologize
for wasting everyone's brain cycles.

sean



signature.asc
Description: OpenPGP digital signature

12.1 release symbol incompatibility?

[Sean Bruno]

If one installs 12.1 and tries to run a 12.0 release package (postgresql
server for instance), it fails due to a missing symbol:

 # service postgresql start
/usr/local/bin/pg_ctl: Undefined symbol "stat@FBSD_1.5"

I think this is a bug as we are supposed to support this kind of thing,
right?

sean



signature.asc
Description: OpenPGP digital signature

Re: efi and serial console

[Sean Bruno]

On 2019-07-19 13:58, mike tancsa wrote:
> I installed a RELENG12 snapshot from July 11th and having a hard time
> getting serial console to work. In the past, I would have something
> simple like
> 
> 
> ttyu0   "/usr/libexec/getty std.115200  vt100   on secure
> 
> in /etc/ttys
> 
> and in /boot/loader.conf
> 
> console="comconsole,vidconsole"
> comconsole_speed="115200"   # Set the current serial console speed
> 
> With some googling, I did find I now have to use  in /boot/loader.conf
> 
> boot_multicons="YES"
> boot_serial="YES"
> console="comconsole,efi"
> comconsole_speed="115200"  
> 
> However, I can never get getty to automatically start up. I have
> 
> 
> # grep u0 /etc/ttys
> ttyu0   "/usr/libexec/getty std.115200  vt100   on secure
> #
> 
> but at boot up time, I can see on my serial connection the boot loader
> etc and everything prints out to
> 
> Configuring vt: blanktime.
> Performing sanity check on sshd configuration.
> Starting sshd.
> Starting sendmail_submit.
> igb0: link state changed to UP
> Starting sendmail_msp_queue.
> Starting cron.
> Starting backgrou
> 
> 
> and then nothing.  No login prompt and I dont see getty running on the
> serial port. If I ssh in and then do a
> 
> /usr/libexec/getty std.115200 ttyu0
> 
> 
> up pops the login prompt and I can login over serial. However, I have to
> login as a non root user first.  Any idea what I am missing ?
> 
>     ---Mike
> 
> 
> ___
> 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"
> 



I assume that you changed the default here as my machine's /etc/ttys
looks different?

sbruno@alice:~ % grep ttyu0 /etc/ttys
ttyu0   "/usr/libexec/getty 3wire"  vt100   onifconsole secure


sean



signature.asc
Description: OpenPGP digital signature

Urgent Please.

[Sean Kim]

Hello dear,

Did you receive my email message to you? Please, get back to me ASAP as the 
matter is becoming late. Expecting your urgent response.

Regards,

Sean 


---
This email has been checked for viruses by AVG.
https://www.avg.com

___
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: r334229 breaks build kernel

[Sean Bruno]

On 05/27/18 00:18, Tomoaki AOKI wrote:
> Looks simple mis-merge.
> On hunk 1, original (head) r323831 has "hz / isc->quanta" at 2nd arg,
> while r334229 (stable/11) has "hz / isc->quanta1".
> 
> r334228 and before had "hz / isc->quanta - 1", so missingly removed
> " - " instead of " - 1".
> 
> Any other hunks looks fine.
> 
> Regards.
> 
> On Sat, 26 May 2018 10:37:34 -0600
> Warner Losh <i...@bsdimp.com> wrote:
> 
>> Looks like sean's merge was incomplete somehow.
>>
>> Warner
>>
>> On Sat, May 26, 2018 at 9:02 AM, Dmitriy Makarov <suppor...@ukr.net> wrote:
>>
>>> Hi,
>>>
>>> probably this last changes https://svnweb.freebsd.org/
>>> base?view=revision=334229 breaks buildkernel in stable/11
>>>
>>> If it is related my kernel config contains IOSCHED option:
>>> options CAM_IOSCHED_DYNAMIC
>>>
>>>
>>> cc -target x86_64-unknown-freebsd11.2 --sysroot=/usr/obj/usr/src/tmp
>>> -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing  -g
>>> -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL
>>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer
>>> -mno-omit-leaf-frame-pointer -MD  -MF.depend.cam_iosched.o -MTcam_iosched.o
>>> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
>>> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
>>> -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
>>> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
>>> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
>>> -fdiagnostics-show-option -Wno-unknown-pragmas 
>>> -Wno-error-tautological-compare
>>> -Wno-error-empty-body -Wno-error-parentheses-equality
>>> -Wno-error-unused-function -Wno-error-pointer-sign
>>> -Wno-error-shift-negative-value -Wno-error-address-of-packed-member
>>> -mno-aes -mno-avx  -std=iso9899:1999 -W
>>>  error  /usr/src/sys/cam/cam_iosched.c
>>>
>>> /usr/src/sys/cam/cam_iosched.c:513:40: error: no member named 'quanta1'
>>> in 'struct cam_iosched_softc'; did you mean 'quanta'?
>>> callout_reset(>ticker, hz / isc->quanta1, cam_iosched_ticker,
>>> isc);
>>>   ^~~
>>>   quanta
>>> /usr/src/sys/sys/callout.h:115:28: note: expanded from macro
>>> 'callout_reset'
>>> callout_reset_on((c), (on_tick), (fn), (arg), -1)
>>>^
>>> /usr/src/sys/sys/callout.h:112:43: note: expanded from macro
>>> 'callout_reset_on'
>>> callout_reset_sbt_on((c), tick_sbt * (to_ticks), 0, (fn), (arg),\
>>>   ^
>>> /usr/src/sys/cam/cam_iosched.c:267:7: note: 'quanta' declared here
>>> int quanta; /* Number of quanta per
>>> second */
>>> ^
>>> 1 error generated.
>>> ___
>>> 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"
>>
> 
> 


I'm looking at this.

sean



signature.asc
Description: OpenPGP digital signature

Re: ftpd in base

[Sean Bruno]

On 05/20/18 05:49, tech-lists wrote:
> Hi,
> 
> context: 11.2-BETA2 #0 r333924/amd64
> 
> I'm trying to get chrooted ftpd (in base) to write files uploaded to the
> user dir as mode 666 (umask 111). I have a line in inetd.conf that looks
> like this:
> 
> ftp stream tcp nowait  root /usr/libexec/ftpd ftpd -l -u 111
> 
> The user logs in OK and uploads OK but the perms are always 644. There
> is no login.conf overriding this. The users shell is /usr/sbin/nologin
> as these are ftp-only accounts. This exact config works fine on linux
> (specifically ubuntu)
> 
> Why is ftpd ignoring -u ? How can I fix?
> 
> thanks,


Is it possible that you have 644 in login.conf?  The man page for ftpd
seems to indicate that -u XXX will be overriden by login.conf settings.

sean



signature.asc
Description: OpenPGP digital signature

[Solved] Bind9 + TCP_FASTOPEN => no rndc

[Christopher Sean Hilton]

On Thu, Sep 28, 2017 at 03:28:17PM +, Christopher Sean Hilton wrote:
> On Thu, Sep 28, 2017 at 02:20:47PM +, Christopher Sean Hilton wrote:
> > Great,
> > 
> > I assumed that the FASTOPEN failure was related to the inablity to
> > open the rndc socket. I'll have to debug the rndc socket seperately.
> > 
> > 
> > Thanks for help!
> > 
> 


Just a note for future readers to say that the fix from the previous
message solved this problem.

-- 
Chris

  __o  "All I was trying to do was get home from work."
_`\<,_   -Rosa Parks
___(*)/_(*).___o..___..o...ooO..._
Christopher Sean Hilton[chris/at/vindaloo/dot/com]
___
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: Bind9 + TCP_FASTOPEN => no rndc

[Christopher Sean Hilton]

On Thu, Sep 28, 2017 at 02:20:47PM +, Christopher Sean Hilton wrote:
> Great,
> 
> I assumed that the FASTOPEN failure was related to the inablity to
> open the rndc socket. I'll have to debug the rndc socket seperately.
> 
> 
> Thanks for help!
> 

This had nothing to do with FASTOPEN and everything to do with moving
named from the base system to ports. The solution is to explicitly
configure the location of the rndc.key file in named.conf. Otherwise
named looks in the wrong directory to find it and then fails.

Simple when you know what's wrong.

-- 
Chris

  __o  "All I was trying to do was get home from work."
_`\<,_   -Rosa Parks
___(*)/_(*).___o..___..o...ooO..._
Christopher Sean Hilton[chris/at/vindaloo/dot/com]
___
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: Bind9 + TCP_FASTOPEN => no rndc

[Christopher Sean Hilton]

On Wed, Sep 27, 2017 at 09:17:29PM +, Dimitry Andric wrote:
> On 27 Sep 2017, at 19:35, Christopher Sean Hilton <ch...@vindaloo.com> wrote:
> > 
> > I'm trying to configure bind 9.11 as a nameserver on FreeBSD
> > 11-STABLE. When the bind9 port compile it enables TCP_FASTOPEN but the
> > changes haven't yet been baked into the GENERIC Kernel. I can't find a
> > way to disable the use of TCP_FASTOPEN in bind at startup. Is the only
> > way to fix this problem to build a new kernel with TCP_FASTOPEN
> > enabled?
> 
> It looks like bind enables use of TCP_FASTOPEN whenever its configure
> script finds the define in the system headers.  But it does not check
> whether the functionality actually works with setsockopt.
> 
> In any case, the message is harmless noise, as any errors are ignored:
> 
> #if defined(ISC_PLATFORM_HAVETFO) && defined(TCP_FASTOPEN)
> #ifdef __APPLE__
> backlog = 1;
> #else
> backlog = backlog / 2;
> if (backlog == 0)
> backlog = 1;
> #endif
> if (setsockopt(sock->fd, IPPROTO_TCP, TCP_FASTOPEN,
>(void *), sizeof(backlog)) < 0) {
> isc__strerror(errno, strbuf, sizeof(strbuf));
> UNEXPECTED_ERROR(__FILE__, __LINE__,
>  "setsockopt(%d, TCP_FASTOPEN) failed with 
> %s",
>  sock->fd, strbuf);
> /* TCP_FASTOPEN is experimental so ignore failures */
> }
> #endif
> 

Great,

I assumed that the FASTOPEN failure was related to the inablity to
open the rndc socket. I'll have to debug the rndc socket seperately.


Thanks for help!

-- Chris

-- 
Chris

  __o  "All I was trying to do was get home from work."
_`\<,_   -Rosa Parks
___(*)/_(*).___o..___..o...ooO..._
Christopher Sean Hilton[chris/at/vindaloo/dot/com]
___
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: Bind9 + TCP_FASTOPEN => no rndc

[Christopher Sean Hilton]

On Wed, Sep 27, 2017 at 05:51:31PM +, David Wolfskill wrote:
> On Wed, Sep 27, 2017 at 01:35:25PM -0400, Christopher Sean Hilton wrote:
> > I'm trying to configure bind 9.11 as a nameserver on FreeBSD
> > 11-STABLE. When the bind9 port compile it enables TCP_FASTOPEN but the
> > changes haven't yet been baked into the GENERIC Kernel. I can't find a
> > way to disable the use of TCP_FASTOPEN in bind at startup. Is the only
> > way to fix this problem to build a new kernel with TCP_FASTOPEN
> > enabled?
> > 
> > -- Chris
> > 
> 
> ?  I'm running bind99-9.9.11 (dns/bind99) on a couple systems running
> stable/11 (amd64; currently r323950).  The kernels are (lightly)
> customized, based on GENERIC.  I don't recall setting anything involving
> TCP_FASTOPEN on anything, and have used rndc without issue
> 
> Perhaps you could elaborate a bit on exactly what you are trying to do
> and how the system responds?  (The systems in question run kernels that
> are built on a dedicated "build machine" -- which is presently powered
> off for the day.  I can bring it up for a reality check, should that be
> wanted.)
> 

Good afternoon David,

Thanks for the help! I'm running ports ?net?/bind911 of FreeBSD
11-STABLE with the GENERIC kernel. When I start bind, I get this in my
logs:

Sep 27 13:16:13 alderaan named[30169]: starting BIND 9.11.2 
Sep 27 13:16:13 alderaan named[30169]: running on FreeBSD amd64 11.1-PRERELEASE 
FreeBSD 11.1-PRERELEASE #2 r321128: Tue Jul 18 11:30:08 EDT 2017 
root@freebsd-mule:/usr/obj/usr/src/sys/GENERIC
Sep 27 13:16:13 alderaan named[30169]: built with '--localstatedir=/var' 
'--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' 
'--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' 
'--with-dlopen=yes' '--sysconfdir=/usr/local/etc/namedb' '--disable-dnstap' 
'--disable-filter-' '--disable-fixed-rrset' '--without-geoip' 
'--with-idn=/usr/local' '--enable-ipv6' '--with-libjson' '--disable-largefile' 
'--with-lmdb' '--without-python' '--disable-querytrace' '--enable-rpz-nsdname' 
'--enable-rpz-nsip' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-threads' 
'--without-gssapi' '--with-openssl=/usr' '--disable-native-pkcs11' 
'--with-dlz-filesystem=yes' '--without-gost' '--prefix=/usr/local' 
'--mandir=/usr/local/man' '--infodir=/usr/local/info/' 
'--build=amd64-portbld-freebsd11.0' 'build_alias=amd64-portbld-freebsd11.0' 
'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector -isystem 
/usr/local/include -fno-strict-aliasing' 'LDFLAGS= -fstack-protector' 'LIBS
 =-L/usr/local/lib' 'CPPFLAGS=-D
Sep 27 13:16:13 alderaan named[30169]: running as: named -t /var/named -u bind 
-c /etc/namedb/named.conf
Sep 27 13:16:13 alderaan named[30169]: 

Sep 27 13:16:13 alderaan named[30169]: BIND 9 is maintained by Internet Systems 
Consortium,
Sep 27 13:16:13 alderaan named[30169]: Inc. (ISC), a non-profit 501(c)(3) 
public-benefit 
Sep 27 13:16:13 alderaan named[30169]: corporation.  Support and training for 
BIND 9 are 
Sep 27 13:16:13 alderaan named[30169]: available at https://www.isc.org/support
Sep 27 13:16:13 alderaan named[30169]: 

Sep 27 13:16:13 alderaan named[30169]: socket.c:5695: unexpected error:
Sep 27 13:16:13 alderaan named[30169]: setsockopt(21, TCP_FASTOPEN) failed with 
Protocol not available
Sep 27 13:16:13 alderaan named[30169]: socket.c:5695: unexpected error:
Sep 27 13:16:13 alderaan named[30169]: setsockopt(22, TCP_FASTOPEN) failed with 
Protocol not available
Sep 27 13:16:13 alderaan named[30169]: socket.c:5695: unexpected error:
Sep 27 13:16:13 alderaan named[30169]: setsockopt(23, TCP_FASTOPEN) failed with 
Protocol not available
Sep 27 13:16:13 alderaan named[30169]: socket.c:5695: unexpected error:
Sep 27 13:16:13 alderaan named[30169]: setsockopt(24, TCP_FASTOPEN) failed with 
Protocol not available
Sep 27 13:16:13 alderaan named[30169]: couldn't add command channel 
127.0.0.1#953: file not found
Sep 27 13:16:13 alderaan named[30169]: couldn't add command channel ::1#953: 
file not found
Sep 27 13:16:13 alderaan named[30169]: all zones loaded


I haven't read the bind source code yet but I'm assuming that the
inability to start rndc at 127.0.0.1#953 is related to the
TCP_FASTOPEN error from the log above. Not much Google reveals this
thread: 

 https://forums.freebsd.org/threads/59367/

Which talks about the problem and mentions one, and only one, solution
of rebuilding the kernel to support TCP_FASTOPEN.

That solution is kind of heavyweight for me. If you read more about
tcp_fastopen, you'll get indications that the code may be too green
right now to be enabled by default. Please pardon any file blunders
here, I'm at work so it's not easy to research this completely. From
what I can see though, with the option id def

Bind9 + TCP_FASTOPEN => no rndc

[Christopher Sean Hilton]

I'm trying to configure bind 9.11 as a nameserver on FreeBSD
11-STABLE. When the bind9 port compile it enables TCP_FASTOPEN but the
changes haven't yet been baked into the GENERIC Kernel. I can't find a
way to disable the use of TCP_FASTOPEN in bind at startup. Is the only
way to fix this problem to build a new kernel with TCP_FASTOPEN
enabled?

-- Chris


-- 
Chris

  __o  "All I was trying to do was get home from work."
_`\<,_   -Rosa Parks
___(*)/_(*).___o..___..o...ooO..._
Christopher Sean Hilton[chris/at/vindaloo/dot/com]
___
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"

Slow CD access until primed by readcd (cdrtools)

[Sean C. Farley]

I ran into an issue with at least a few CD's where the access to them 
mounted as cd9660 was very slow.  dd of /dev/cd0 was also slow.


However, if I run readcd (from cdrtools-devel-3.02a06,1) at least once, 
which would run at full speed, then any access to the disc whether 
mounted or not is at full speed.  I do not recall this happening in the 
past, but this is with a newer computer (i.e., newer drive).  It appears 
to be that something is determining the full speed correctly when readcd 
is run and is keeping that state until the disc is removed while 
mounting or running dd against the drive does not.


OS:  10.3-STABLE (r304921) amd64.

pass0:  Removable CD-ROM SCSI device
pass0: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes)

Any ideas?

Sean
--
s...@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"

ZFS, SSDs, and TRIM performance

[Sean Kelly]

Me again. I have a new issue and I’m not sure if it is hardware or software. I 
have nine servers running 10.2-RELEASE-p5 with Dell OEM’d Samsung XS1715 NVMe 
SSDs. They are paired up in a single mirrored zpool on each server. They 
perform great most of the time. However, I have a problem when ZFS fires off 
TRIMs. Not during vdev creation, but like if I delete a 20GB snapshot.

If I destroy a 20GB snapshot or delete large files, ZFS fires off tons of TRIMs 
to the disks. I can see the kstat.zfs.misc.zio_trim.success and 
kstat.zfs.misc.zio_trim.bytes sysctls skyrocket. While this is happening, any 
synchronous writes seem to block. For example, we’re running PostgreSQL which 
does fsync()s all the time. While these TRIMs happen, Postgres just hangs on 
writes. This causes reads to block due to lock contention as well.

If I change sync=disabled on my tank/pgsql dataset while this is happening, it 
unblocks for the most part. But obviously this is not an ideal way to run 
PostgreSQL.

I’m working with my vendor to get some Intel SSDs to test, but any ideas if 
this could somehow be a software issue? Or does the Samsung XS1715 just suck at 
TRIM and SYNC?

We’re thinking of just setting the vfs.zfs.trim.enabled=0 tunable for now since 
WAL segment turnover actually causes TRIM operations a lot, but unfortunately 
this is a reboot. But disabling TRIM does seem to fix the issue on other 
servers I’ve tested with the same hardware config.

-- 
Sean Kelly
smke...@smkelly.org
http://smkelly.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"

Dell NVMe issues

[Sean Kelly]

Back in May, I posted about issues I was having with a Dell PE R630 with 
4x800GB NVMe SSDs. I would get kernel panics due to the inability to assign all 
the interrupts because of 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321>. Jim Harris helped 
fix this issue so I bought several more of these servers, Including ones with 
4x1.6TB drives…

while the new servers with 4x800GB drives still work, the ones with 4x1.6TB 
drives do not. When I do a
zpool create tank mirror nvd0 nvd1 mirror nvd2 nvd3
the command never returns and the kernel logs:
nvme0: resetting controller
nvme0: controller ready did not become 0 within 2000 ms

I’ve tried several different things trying to understand where the actual 
problem is.
WORKS: dd if=/dev/nvd0 of=/dev/null bs=1m
WORKS: dd if=/dev/zero of=/dev/nvd0 bs=1m
WORKS: newfs /dev/nvd0
FAILS: zpool create tank mirror nvd[01]
FAILS: gpart add -t freebsd-zfs nvd[01] && zpool create tank mirror nvd[01]p1
FAILS: gpart add -t freebsd-zfs -s 1400g nvd[01[ && zpool create tank nvd[01]p1
WORKS: gpart add -t freebsd-zfs -s 800g nvd[01] && zpool create tank nvd[01]p1

NOTE: The above commands are more about getting the point across, not validity. 
I wiped the disk clean between gpart attempts and used GPT.

So it seems like zpool works if I don’t cross past ~800GB. But other things 
like dd and newfs work.

When I get the kernel messages about the controller resetting and then not 
responding, the NVMe subsystem hangs entirely. Since my boot disks are not 
NVMe, the system continues to work but no more NVMe stuff can be done. Further, 
attempting to reboot hangs and I have to do a power cycle.

Any thoughts on what the deal may be here?

10.2-RELEASE-p5

nvme0@pci0:132:0:0: class=0x010802 card=0x1f971028 chip=0xa820144d rev=0x03 
hdr=0x00
vendor = 'Samsung Electronics Co Ltd'
class  = mass storage
subclass   = NVM

-- 
Sean Kelly
smke...@smkelly.org
http://smkelly.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: Dell NVMe issues

[Sean Kelly]

> On Oct 6, 2015, at 10:29 AM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> 
> On Tue, Oct 06, 2015 at 10:18:11AM -0500, Sean Kelly wrote:
> 
>> Back in May, I posted about issues I was having with a Dell PE R630 with 
>> 4x800GB NVMe SSDs. I would get kernel panics due to the inability to assign 
>> all the interrupts because of 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321 
>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321> 
>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321 
>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321>>. Jim Harris 
>> helped fix this issue so I bought several more of these servers, Including 
>> ones with 4x1.6TB drives...
>> 
>> while the new servers with 4x800GB drives still work, the ones with 4x1.6TB 
>> drives do not. When I do a
>>  zpool create tank mirror nvd0 nvd1 mirror nvd2 nvd3
>> the command never returns and the kernel logs:
>>  nvme0: resetting controller
>>  nvme0: controller ready did not become 0 within 2000 ms
>> 
>> I've tried several different things trying to understand where the actual 
>> problem is.
>> WORKS: dd if=/dev/nvd0 of=/dev/null bs=1m
>> WORKS: dd if=/dev/zero of=/dev/nvd0 bs=1m
>> WORKS: newfs /dev/nvd0
>> FAILS: zpool create tank mirror nvd[01]
>> FAILS: gpart add -t freebsd-zfs nvd[01] && zpool create tank mirror nvd[01]p1
>> FAILS: gpart add -t freebsd-zfs -s 1400g nvd[01[ && zpool create tank 
>> nvd[01]p1
>> WORKS: gpart add -t freebsd-zfs -s 800g nvd[01] && zpool create tank 
>> nvd[01]p1
>> 
>> NOTE: The above commands are more about getting the point across, not 
>> validity. I wiped the disk clean between gpart attempts and used GPT.
> 
> Just for purity of the experiment: do you try zpool on raw disk, w/o
> GPT? I.e. zpool create tank mirror nvd0 nvd1
> 

Yes, that was actually what I tried first. I headed down the path of GPT 
because it allowed me a way to restrict how much disk zpool touched. zpool on 
the bare NVMe disks also triggers the issue.

>> So it seems like zpool works if I don't cross past ~800GB. But other things 
>> like dd and newfs work.
>> 
>> When I get the kernel messages about the controller resetting and then not 
>> responding, the NVMe subsystem hangs entirely. Since my boot disks are not 
>> NVMe, the system continues to work but no more NVMe stuff can be done. 
>> Further, attempting to reboot hangs and I have to do a power cycle.
>> 
>> Any thoughts on what the deal may be here?
>> 
>> 10.2-RELEASE-p5
>> 
>> nvme0@pci0:132:0:0: class=0x010802 card=0x1f971028 chip=0xa820144d 
>> rev=0x03 hdr=0x00
>>vendor = 'Samsung Electronics Co Ltd'
>>class  = mass storage
>>subclass   = NVM
>> 
>> -- 
>> Sean Kelly
>> smke...@smkelly.org
>> http://smkelly.org
>> 
>> ___
>> freebsd-stable@freebsd.org <mailto:freebsd-stable@freebsd.org> mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable 
>> <https://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
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Dell NVMe issues

[Sean Kelly]

> On Oct 6, 2015, at 11:06 AM, Eric van Gyzen  wrote:
> 
> Try this:
> 
>sysctl vfs.zfs.vdev.trim_on_init=0
>zpool create tank mirror nvd[01]
> 

That worked. So my guess is the controller/FreeBSD is timing out while zpool 
asks the drive to TRIM all 1.6TB?
___
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: Silent data corruption on em(4) interfaces

[Sean Bruno]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 08/20/15 02:57, KOT MATPOCKuH wrote:
 Hello!
 
 I got silent data corruption when transferring data via em(4)
 interface on 10.2-STABLE r286912. 1. I got broken large file
 transferred via ftp (MD5 checksum mismatched); 2. I got disconnects
 when transferring large data via ssh with messages: Corrupted MAC
 on input. Disconnecting: Packet corrupt
 
 Problem occurs only after few hours of uptime. Immediately after
 reboot I transferred same file via ftp without any errors.
 
 I tried to use: - em0 and em2 interfaces in link aggregation - em1
 as clean interface But I got same problem in both cases.
 
 Also one time when transferring file I got this messages: em0:
 Interface stopped DISTRIBUTING, possible flapping em0: Watchdog
 timeout -- resetting em2: Interface stopped DISTRIBUTING, possible
 flapping em2: Watchdog timeout -- resetting
 
 netstat -in does not see any problems: NameMtu Network
 Address  Ipkts Ierrs IdropOpkts Oerrs  Coll em0
 1500 Link#1  00:14:4f:01:3f:7a  6689452 0 0 146720
 0 0 em11500 Link#2  00:14:4f:01:3f:7b  5732168 0
 0 2865912 0 0 em21500 Link#3  00:14:4f:01:3f:7c
 501817 0 0 3392333 0 0
 
 Network adapters is build in to the Sun Fire X4100 mother board: 
 em0@pci0:1:1:0: class=0x02 card=0x10118086 chip=0x10108086
 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device =
 '82546EB Gigabit Ethernet Controller (Copper)' class  =
 network subclass   = ethernet
 
 TCP_OFFLOAD disabled in kernel's config.
 
 Any ideas?
 


Can you file a bugzilla report for this with all possible information
from your report?

sean
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQF8BAEBCgBmBQJV25vFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kyC8H+QFLXz2hbRmkBhTlxExfZpUw
ZtWDvrwJAnLXXsMVPi+E3icGLX2YYljw/MCpD8LqxJTs2jQOc+X3wIjI4nt5WEHI
ve/KTpsdYjdxvLrIFRgUbt+oCv8C0NFfmQNsLqFRCe2Cz3tUtdwQsFGUXH6NkKxN
Xj3tC1yBRwwVoywhmaU5uahaBtv4IC6x00iDkbjrX9GZKiBZD11HcGYyNMoCUFsP
Njz1UZjtuztuy1IuDXbVn+HMm90VOsRziMgU2LQmsWTp6sSw+T/45ce0UYzrlhEl
n/50fboUdS8k8kfjjyxid2kaskOAfe/qWZB59qdiKFDdgBFz7/oBRwN/yq6Ww1U=
=fy/H
-END PGP SIGNATURE-
___
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: Possible Error in the FreeBSD 10.2 Release Notes/Man page for TCP

[Sean Bruno]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/12/15 15:43, Glen Barber wrote:
 On Wed, Aug 12, 2015 at 03:41:21PM -0700, Sean Bruno wrote:
 On 08/12/15 15:15, Glen Barber wrote:
 On Wed, Aug 12, 2015 at 01:09:31PM -0500, dweimer wrote:
 I was reading through the Release notes, and decided to
 enable net.inet.tcp.pmtud_blackhole_detection in my test
 environment. It appears that the monitoring tunable 
 net.inet.tcp.pmtud_blackhole_min_activated is incorrectly
 listed. Using sysctl -a | grep net.inet.tcp.pmtud, doesn't
 show it as a result. The test system is running RC3 built on
 the 7th from revision 286391 of the
 https://svn.freebsd.org/base/releng/10.2 tree.
 
 root@freebsd:/usr/src # sysctl -a | grep net.inet.tcp.pmtud 
 net.inet.tcp.pmtud_blackhole_mss: 1200 
 net.inet.tcp.pmtud_blackhole_failed: 0 
 net.inet.tcp.pmtud_blackhole_activated_min_mss: 0 
 net.inet.tcp.pmtud_blackhole_activated: 0 
 net.inet.tcp.pmtud_blackhole_detection: 1
 
 I did confirm that the pmtud_blackhole_min_activated option
 is also listed in the tcp(4) man page page as well.
 
 If anyone is more familiar with this than I am can they look
 into seeing if there is indeed an error, or if I am missing
 something here.
 
 
 This appears to be an error based on the content of the commit 
 log. I will confirm with the person that committed the code,
 and will note the findings in the 10.2-RELEASE errata
 document.
 
 
 This looks like I failed to MFC r276345 to stable 10 in order to 
 update tcp.4 leading to this confusion.
 
 
 Thank you for confirming.  I'll update the 10.2-RELEASE errata 
 accordingly.
 
 What should the proper sysctls be, for completeness?
 
 Glen
 

% sysctl -a|grep pmtud
net.inet.tcp.v6pmtud_blackhole_mss: 1220
net.inet.tcp.pmtud_blackhole_mss: 1200
net.inet.tcp.pmtud_blackhole_failed: 0
net.inet.tcp.pmtud_blackhole_activated_min_mss: 0
net.inet.tcp.pmtud_blackhole_activated: 0
net.inet.tcp.pmtud_blackhole_detection: 0


These are correct.  The man page is now updated as of svn r286706.

sean
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQF8BAEBCgBmBQJVy86vXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kyVMIAMPN8pFIgeGRX3bvqfZv5F8C
qt3hhZGKWXqsAd4Ij+74rmZQP/7bBGC6jQCyztnHyLy7zN6zKtEKaznP5kjOmsrw
96ovaOKskfTL4cBUUb8KSyvoyZ/v2JBlnc56loFsfJBJ1vG+7LfQKjYkCfMyhPh0
JWr0LzkNKve46yfZr84I9VXux5Y0lsIWxvaDJ+zA4ISzb6tWEZMuC+yxY6v6ubQk
zgkyrXUyFRs6taUWn3Mm3EdJKjbC0tOHwD1fAebRSZbmA0ZmkONWJlm3mshkU5Yd
nxfUYCs0n1let9cQ7QaKA+czkl3BV7oUfZ7QDcc54D5fb8AG1z8nehPfq2LGOL4=
=wVa0
-END PGP SIGNATURE-
___
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: Possible Error in the FreeBSD 10.2 Release Notes/Man page for TCP

[Sean Bruno]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/12/15 15:15, Glen Barber wrote:
 On Wed, Aug 12, 2015 at 01:09:31PM -0500, dweimer wrote:
 I was reading through the Release notes, and decided to enable 
 net.inet.tcp.pmtud_blackhole_detection in my test environment. It
 appears that the monitoring tunable
 net.inet.tcp.pmtud_blackhole_min_activated is incorrectly listed.
 Using sysctl -a | grep net.inet.tcp.pmtud, doesn't show it as a
 result. The test system is running RC3 built on the 7th from 
 revision 286391 of the https://svn.freebsd.org/base/releng/10.2
 tree.
 
 root@freebsd:/usr/src # sysctl -a | grep net.inet.tcp.pmtud 
 net.inet.tcp.pmtud_blackhole_mss: 1200 
 net.inet.tcp.pmtud_blackhole_failed: 0 
 net.inet.tcp.pmtud_blackhole_activated_min_mss: 0 
 net.inet.tcp.pmtud_blackhole_activated: 0 
 net.inet.tcp.pmtud_blackhole_detection: 1
 
 I did confirm that the pmtud_blackhole_min_activated option is
 also listed in the tcp(4) man page page as well.
 
 If anyone is more familiar with this than I am can they look into
 seeing if there is indeed an error, or if I am missing something
 here.
 
 
 This appears to be an error based on the content of the commit
 log. I will confirm with the person that committed the code, and
 will note the findings in the 10.2-RELEASE errata document.
 
 Glen
 


This looks like I failed to MFC r276345 to stable 10 in order to
update tcp.4 leading to this confusion.

sean
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQF8BAEBCgBmBQJVy8uPXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kfV0H/jluKnznRLif5znvcy/4yNuE
1uP2pG3dyxJXK2GgCSb8gmyO3bM4Wn3C+BVYcPt3hC86koudyAB3edNUYKQ3qjzg
H3cYWK/IY6mCzblBKm1WRRpleISjWtQgfjAXwJs1VlSgobtIIqmGqj2ksOiye1FB
1okLFqCMq/Gb2arHVD7jiRyVU8RqRLagCu9xNfKcn+xo79ietluAdpxZosW+wovJ
RqNLLy55O7tW7c97KGCi/Rot6eb5tLotGJxjwnkMkxecizfGc26WIZVWZSF+9B4g
ctYFiyZ1mL2sRmH+nhV7tbDyzoCA++yj3jLzbysnziXmicBeAchyjwvhJ2Xp1Oo=
=Q+HE
-END PGP SIGNATURE-
___
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: 10.1 NVMe kernel panic

[Sean Kelly]

Jim,

Thanks for the reply. I set hw.nvme.force_intx=1 and get a new form of kernel 
panic:
http://smkelly.org/stuff/nvme_crash_force_intx.txt 
http://smkelly.org/stuff/nvme_crash_force_intx.txt

It looks like the NVMes are just failing to initialize at all now. As long as 
that tunable is in the kenv, I get this behavior. If I kldload them after boot, 
the init fails as well. But if I kldunload, kenv -u, kldload, it then works 
again. The only difference is kldload doesn’t result in a panic, just timeouts 
initializing them all.

I also compiled and tried stable/10 and it crashed in a similar way, but i’ve 
not captured the panic yet. It crashes even without the tunable in place. I’ll 
see if I can capture it.

-- 
Sean Kelly
smke...@smkelly.org
http://smkelly.org

 On Jun 2, 2015, at 6:10 PM, Jim Harris jim.har...@gmail.com wrote:
 
 
 
 On Thu, May 21, 2015 at 8:33 AM, Sean Kelly smke...@smkelly.org 
 mailto:smke...@smkelly.org wrote:
 Greetings.
 
 I have a Dell R630 server with four of Dell’s 800GB NVMe SSDs running FreeBSD 
 10.1-p10. According to the PCI vendor, they are some sort of rebranded 
 Samsung drive. If I boot the system and then load nvme.ko and nvd.ko from a 
 command line, the drives show up okay. If I put
 nvme_load=“YES”
 nvd_load=“YES”
 in /boot/loader.conf, the box panics on boot:
 panic: nexus_setup_intr: NULL irq resource!
 
 If I boot the system with “Safe Mode: ON” from the loader menu, it also boots 
 successfully and the drives show up.
 
 You can see a full ‘boot -v’ here:
 http://smkelly.org/stuff/nvme-panic.txt 
 http://smkelly.org/stuff/nvme-panic.txt 
 http://smkelly.org/stuff/nvme-panic.txt 
 http://smkelly.org/stuff/nvme-panic.txt
 
 Anyone have any insight into what the issue may be here? Ideally I need to 
 get this working in the next few days or return this thing to Dell.
 
 Hi Sean,
 
 Can you try adding hw.nvme.force_intx=1 to /boot/loader.conf?
 
 I suspect you are able to load the drivers successfully after boot because 
 interrupt assignments are not restricted to CPU0 at that point - see 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321 for a related 
 issue.  Your logs clearly show that vectors were allocated for the first 2 
 NVMe SSDs, but the third could not get its full allocation.  There is a bug 
 in the INTx fallback code that needs to be fixed - you do not hit this bug 
 when loading after boot because bug #199321 only affects interrupt allocation 
 during boot.
 
 If the force_intx test works, would you able to upgrade your nvme drivers to 
 the latest on stable/10?  There are several patches (one related to interrupt 
 vector allocation) that have been pushed to stable/10 since 10.1 was 
 released, and I will be pushing another patch for the issue you have reported 
 shortly.
 
 Thanks,
 
 -Jim
 
 
   
 
 Thanks!
 
 --
 Sean Kelly
 smke...@smkelly.org mailto:smke...@smkelly.org
 http://smkelly.org http://smkelly.org/
 
 ___
 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

10.1 NVMe kernel panic

[Sean Kelly]

Greetings.

I have a Dell R630 server with four of Dell’s 800GB NVMe SSDs running FreeBSD 
10.1-p10. According to the PCI vendor, they are some sort of rebranded Samsung 
drive. If I boot the system and then load nvme.ko and nvd.ko from a command 
line, the drives show up okay. If I put
nvme_load=“YES”
nvd_load=“YES”
in /boot/loader.conf, the box panics on boot:
panic: nexus_setup_intr: NULL irq resource!

If I boot the system with “Safe Mode: ON” from the loader menu, it also boots 
successfully and the drives show up.

You can see a full ‘boot -v’ here:
http://smkelly.org/stuff/nvme-panic.txt 
http://smkelly.org/stuff/nvme-panic.txt

Anyone have any insight into what the issue may be here? Ideally I need to get 
this working in the next few days or return this thing to Dell.

Thanks!

-- 
Sean Kelly
smke...@smkelly.org
http://smkelly.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: Device timeout from mfi(9) while booting 9.2-RELEASE

[Sean Bruno]

On Fri, 2013-10-04 at 18:27 +1000, Jan Mikkelsen wrote:
  mfi0: 14299 (boot + 4s/0x0020/info) - Firmware version 3.190.05-1669
  mfi0: 14300 (boot + 5s/0x0020/info) - Package version 23.7.0-0029
  mfi0: 14301 (boot + 5s/0x0020/info) - Board Revision 

Does it make sense then, to take a survey and add a recommended minium
f/w for cards that we know about to the man page?

sean


signature.asc
Description: This is a digitally signed message part

Re: Intel 10Gb network card

[Sean Bruno]

On Wed, 2013-09-04 at 09:25 +0300, Daniel Braniss wrote:
 no man ix, no mention of /dev/ix%d in man ixgbe

If you have a moment, can you submit a diff on this fact?  It seems
REALLY confusing to me.

Sean


signature.asc
Description: This is a digitally signed message part

Re: [ATH] 9.2-PRERELEASE and wlan0 device disconnection

[Sean Bruno]

On Sat, 2013-08-17 at 17:42 +0530, Tj wrote:
 (Sorry emailed from wrong address, re emailing)
 
 Hi, I just upgraded to 9.2-PRERELEASE from 9.1-RELEASE, I have not had this
 problem before with any version of freebsd however. I have an ATHEROS card
 (AR928X according to pciconf), things go fine except every few
 minutes/hours (randomly) I get the following
 http://bpaste.net/show/123755/ type
 of error, and  the network is no longer connected, however, beyond the fact
 that I can't even reach my router there's no obvious other sign, I.e
 ifconfig still shows a valid output with ip address etc as if it were still
 connected. Restarting the netif service fixes it, until it happens again -
 which it does in a short while (though sometimes I have to restart netif
 twice).
 
 As I said, this happened just as I upgraded from 9.1 to 9.2. Anyone have
 any idea what's causing this?
 
 -Tj Hariharan


Can you submit a PR for this so the maintainer can track it?

Sean


signature.asc
Description: This is a digitally signed message part

Re: bce and Warning: bootcode thinks driver is absent.

[Sean Bruno]

On Wed, 2013-07-17 at 11:55 -0400, Larry Baird wrote:
 Recently under amd64 and 9.1-STABLE I am seeing issues with the bce
 driver.  Message is Warning: bootcode thinks driver is absent.  After
 this message, the box appears to be wedged.  After rebooting, it got the
 same message during fsck.  So we installed 9.2 pre-release using a snapshot
 iso from 7/13/13.  Shortly after boot we got the same message.  We are now in
 the process of installing 9.1 release to verify this is a driver issue and
 not hardware flaking out.  Anybody else seen this issue?
 
 Thank you for your time,
 Larry
 


Hey, looks like we might be seeing similar things.  I've been
investigating the fact that FreeBSD appears to be smashing the mangement
firmware because of the ipmi(4) code attempting to attach to the ACPI
and ISA versions of the BMC.  

Do you see attempts to attach to ipmi1 and do you see various cases
where you get a NMI of some kind on an ifconfig up of your network
interfaces?

Sean


signature.asc
Description: This is a digitally signed message part

Re: Intel 82574 issue reported on Slashdot

[Sean Bruno]

On Fri, 2013-02-08 at 10:16 -0800, Jack Vogel wrote:
 For those that may have run across the story on Slashdot about this NIC,
 here is our statement:
 
 Recently there were a few stories published, based on a blog post by an
 end-user, suggesting specific network packets may cause the Intel® 82574L
 Gigabit Ethernet Controller to become unresponsive until corrected by a
 full platform power cycle.
 
 Intel was made aware of this issue in September 2012 by the blogs author.
 Intel worked with the author as well as the original motherboard
 manufacturer to investigate and determine root cause. Intel root caused the
 issue to the specific vendor’s mother board design where an incorrect
 EEPROM image was programmed during manufacturing.  We communicated the
 findings and recommended corrections to the motherboard manufacturer.
 
 It is Intel’s belief that this is an implementation issue isolated to a
 specific manufacturer, not a design problem with the Intel 82574L Gigabit
 Ethernet controller.  Intel has not observed this issue with any
 implementations which follow Intel’s published design guidelines.  Intel
 recommends contacting your motherboard manufacturer if you have continued
 concerns or questions whether your products are impacted.
 Here is the link:
 
 http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement
 
 Any questions or concerns may be sent to me.
 
 Cheers,
 
 Jack

Thanks for the info.  I'm sure there were some *interesting* debugging
sessions during this.  

Sean

___
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: RELENG_9 panic with PERC 6/i (mfi)

[Sean Kelly]

No, it remains an outstanding issue. We've begun moving services to a spare 
server to give us more time to investigate it.


From: Wiley, Glen [gwi...@verisign.com]
Sent: Wednesday, January 02, 2013 9:52 AM
To: Sean Kelly; Daniel Braniss
Cc: freebsd-stable@freebsd.org
Subject: Re: RELENG_9 panic with PERC 6/i (mfi)

Did you guys end up identifying the cause of that panic?

--
Glen Wiley
Systems Architect
Verisign Inc.




On 12/23/12 12:56 PM, Sean Kelly smke...@flightaware.com wrote:

Greetings.

All I have to do to panic it is boot it. As you can see from the dump, it
died after about 30 seconds without me doing anything. I can't provide
those sysctl values easily, as it panics too quickly. I suppose I can
convince it to drop to DDB and pick them out if that would be helpful.

Here they are from the working 8.2-R kernel.
vm.kmem_map_free: 49870348288
vm.kmem_map_size: 68964352

This box, unlike most of our others, doesn't even utilizing ZFS.
root@papa:~# gpart show
=63  1141899192  mfid0  MBR  (545G)
  63  1141884072  1  freebsd  [active]  (544G)
  1141884135   15120 - free -  (7.4M)

= 0  1141884072  mfid0s1  BSD  (544G)
   0 83886081  freebsd-ufs  (4.0G)
 8388608167772164  freebsd-ufs  (8.0G)
25165824335544325  freebsd-ufs  (16G)
58720256671088642  freebsd-swap  (32G)
   125829120671088647  freebsd-swap  (32G)
   192937984671088648  freebsd-swap  (32G)
   260046848   8818372246  freebsd-ufs  (420G)


From: Daniel Braniss [da...@cs.huji.ac.il]
Sent: Sunday, December 23, 2012 1:43 AM
To: Sean Kelly
Subject: Re: RELENG_9 panic with PERC 6/i (mfi)

btw:
sysctl -a | grep kmem_map
vm.kmem_map_free: 8859570176
vm.kmem_map_size: 6037008384


danny


___
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: RELENG_9 panic with PERC 6/i (mfi)

[Sean Kelly]

Greetings.

All I have to do to panic it is boot it. As you can see from the dump, it died 
after about 30 seconds without me doing anything. I can't provide those sysctl 
values easily, as it panics too quickly. I suppose I can convince it to drop to 
DDB and pick them out if that would be helpful.

Here they are from the working 8.2-R kernel.
vm.kmem_map_free: 49870348288
vm.kmem_map_size: 68964352

This box, unlike most of our others, doesn't even utilizing ZFS.
root@papa:~# gpart show
=63  1141899192  mfid0  MBR  (545G)
  63  1141884072  1  freebsd  [active]  (544G)
  1141884135   15120 - free -  (7.4M)

= 0  1141884072  mfid0s1  BSD  (544G)
   0 83886081  freebsd-ufs  (4.0G)
 8388608167772164  freebsd-ufs  (8.0G)
25165824335544325  freebsd-ufs  (16G)
58720256671088642  freebsd-swap  (32G)
   125829120671088647  freebsd-swap  (32G)
   192937984671088648  freebsd-swap  (32G)
   260046848   8818372246  freebsd-ufs  (420G)


From: Daniel Braniss [da...@cs.huji.ac.il]
Sent: Sunday, December 23, 2012 1:43 AM
To: Sean Kelly
Subject: Re: RELENG_9 panic with PERC 6/i (mfi)

btw:
sysctl -a | grep kmem_map
vm.kmem_map_free: 8859570176
vm.kmem_map_size: 6037008384


danny


___
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

RELENG_9 panic with PERC 6/i (mfi)

[Sean Kelly]

Greetings.

I have a Dell R710 with a mfi device (PERC 6/i Integrated) that panics almost 
immediately on FreeBSD 9. It works fine on FreeBSD 8.2-RELEASE, but I've now 
had it panic in FreeBSD 9.0-STABLE and 9.1-RELEASE.

Output of mfiutil show adapter and panic backtrace below. Anybody seen this or 
have any ideas?

# mfiutil show adapter:
mfi0 Adapter:
Product Name: PERC 6/i Integrated
   Serial Number: redacted
Firmware: 6.3.1-0003
 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50
  Battery Backup: present
   NVRAM: 32K
  Onboard Memory: 256M
  Minimum Stripe: 8K
  Maximum Stripe: 1M

# kgdb -n 5
panic: kmem_malloc(-8192): kmem_map too small: 82677760 total allocated
cpuid = 2
KDB: stack backtrace:
#0 0x809208a6 at kdb_backtrace+0x66
#1 0x808ea8be at panic+0x1ce
#2 0x80b44930 at vm_map_locked+0
#3 0x80b3b41a at uma_large_malloc+0x4a
#4 0x808d5a69 at malloc+0xd9
#5 0x805b2985 at mfi_user_command+0x35
#6 0x805b2f2d at mfi_ioctl+0x2fd
#7 0x807db28b at devfs_ioctl_f+0x7b
#8 0x80932325 at kern_ioctl+0x115
#9 0x8093255d at sys_ioctl+0xfd
#10 0x80bd7ae6 at amd64_syscall+0x546
#11 0x80bc3447 at Xfast_syscall+0xf7
Uptime: 35s
Dumping 2032 out of 49122 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

(kgdb) lis *0x805b2985
0x805b2985 is in mfi_user_command (/usr/src/sys/dev/mfi/mfi.c:2836).
2831 int error = 0, locked;
2832
2833
2834 if (ioc-buf_size  0) {
2835 ioc_buf = malloc(ioc-buf_size, M_MFIBUF, M_WAITOK);
2836 if (ioc_buf == NULL) {
2837 return (ENOMEM);
2838 }
2839 error = copyin(ioc-buf, ioc_buf, ioc-buf_size);
2840 if (error) {

___
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

[stable 9]devd parse.y change

[Sean Bruno]

Bah, found a nit when buildworlding stable/9 on pc-bsd9 that Bruce
pointed out 6 months ago?  

http://comments.gmane.org/gmane.os.freebsd.current/142170

I'll patch this if there are no objections?


Index: sbin/devd/parse.y
===
--- sbin/devd/parse.y   (revision 241362)
+++ sbin/devd/parse.y   (working copy)
@@ -29,9 +29,9 @@
  * $FreeBSD$
  */
 
-#include devd.h
 #include stdio.h
 #include string.h
+#include devd.h
 
 %}


___
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

stable/9 compile on pc-bsd9

[Sean Bruno]

this doesn't make any sense to me, but a buildworld seems to fail on
pc-bsd9, but not on freebsd9.  I wonder what's going on here?


=== usr.sbin/zzz (installincludes)

--
 stage 4.2: building libraries
--
=== gnu/lib/libssp/libssp_nonshared (obj,depend,all,install)
=== gnu/lib/libgcc (obj,depend,all,install)
=== lib/libcompiler_rt (obj,depend,all,install)
=== gnu/lib/csu (obj,depend,all,install)
=== lib/csu/amd64 (obj,depend,all,install)
=== lib/libcompiler_rt (obj,depend,all,install)
=== lib/libc (obj,depend,all,install)
cc1: warnings being treated as errors
/usr/home/seanbru/bsd/9/lib/libc/net/nsparser.y: In function
'_nsaddsrctomap':
/usr/home/seanbru/bsd/9/lib/libc/net/nsparser.y:169: warning: implicit
declaration of function 'free'
In file included from nsparser.c:398:
/usr/home/seanbru/bsd/9/lib/libc/../../include/stdlib.h: At top level:
/usr/home/seanbru/bsd/9/lib/libc/../../include/stdlib.h:93: warning:
conflicting types for 'free'
/usr/home/seanbru/bsd/9/lib/libc/net/nsparser.y:169: warning: previous
implicit declaration of 'free' was here
cc1: warnings being treated as errors
/usr/home/seanbru/bsd/9/lib/libc/net/nsparser.y: In function
'_nsaddsrctomap':
/usr/home/seanbru/bsd/9/lib/libc/net/nsparser.y:169: warning: implicit
declaration of function 'free'
In file included from nsparser.c:398:
*** [nsparser.o] Error code 1
/usr/home/seanbru/bsd/9/lib/libc/../../include/stdlib.h: At top level:
/usr/home/seanbru/bsd/9/lib/libc/../../include/stdlib.h:93: warning:
conflicting types for 'free'
/usr/home/seanbru/bsd/9/lib/libc/net/nsparser.y:169: warning: previous
implicit declaration of 'free' was here
*** [nsparser.So] Error code 1
2 errors
*** [lib/libc__L] Error code 2
1 error
*** [libraries] Error code 2
1 error
*** [_libraries] Error code 2
1 error
*** [buildworld] Error code 2
1 error



___
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: stable/9 panic Bad tailq NEXT(0xffffffff80e52660-tqh_last) != NULL

[Sean Bruno]

On Mon, 2012-10-01 at 05:47 -0700, John Baldwin wrote:
 Can you add extra printfs to see where exactly attach is failing?  I
 would
 start with the attach routine in sys/dev/acpica/acpi_pcib_pci.c:
 
 

hrm ... interesting side effects.  After adding my printf's I don't hit
the panic any more.  :-)

I changed the ret val of acpi_pcib_pci_attach() and put in some
instrumentation in acpi_pcib_attach().  The key value is that
acpi_DeviceIsPresent() appears to be returning FALSE in this case.

patch used --http://people.freebsd.org/~sbruno/acpi_pcib.txt

Resulted in the following relevant output:

pcib7: ACPI PCI-PCI bridge at device 28.0 on pci0
pcib7:   domain0
pcib7:   secondary bus 7
pcib7:   subordinate bus   7
pcib7:   no prefetched decode
pcib7: This device is not present
pcib7: acpi_pcib_pci_attach: err_attach(6)
device_attach: pcib7 attach returned 6
pcib7: ACPI PCI-PCI bridge irq 19 at device 28.7 on pci0
pcib0: allocated type 3 (0xde00-0xdf7f) for rid 20 of pcib7
pcib0: allocated type 3 (0xd800-0xd8ff) for rid 24 of pcib7
pcib7:   domain0
pcib7:   secondary bus 8
pcib7:   subordinate bus   12
pcib7:   memory decode 0xde00-0xdf7f
pcib7:   prefetched decode 0xd800-0xd8ff
pci8: ACPI PCI bus on pcib7
pci8: domain=0, physical bus=8
found- vendor=0x1912, dev=0x0013, revid=0x00
domain=0, bus=8, slot=0, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords)
lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x00 (0 ns)
powerspec 3  supports D0 D3  current D0
MSI supports 1 message, 64 bit
pcib8: PCI-PCI bridge at device 0.0 on pci8
pcib7: allocated memory range (0xde00-0xdf7f) for rid 20 of
pcib8
pcib7: allocated prefetch range (0xd800-0xd8ff) for rid 24 of
pcib8
pcib8:   domain0
pcib8:   secondary bus 9
pcib8:   subordinate bus   12
pcib8:   memory decode 0xde00-0xdf7f
pcib8:   prefetched decode 0xd800-0xd8ff
pci9: PCI bus on pcib8
pci9: domain=0, physical bus=9




___
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: stable/9 panic Bad tailq NEXT(0xffffffff80e52660-tqh_last) != NULL

[Sean Bruno]

On Tue, 2012-10-02 at 14:06 -0700, John Baldwin wrote:
 On Tuesday, October 02, 2012 3:05:30 pm Sean Bruno wrote:
  On Mon, 2012-10-01 at 05:47 -0700, John Baldwin wrote:
   Can you add extra printfs to see where exactly attach is failing?  I
   would
   start with the attach routine in sys/dev/acpica/acpi_pcib_pci.c:
   
   
  
  hrm ... interesting side effects.  After adding my printf's I don't hit
  the panic any more.  :-)
  
  I changed the ret val of acpi_pcib_pci_attach() and put in some
  instrumentation in acpi_pcib_attach().  The key value is that
  acpi_DeviceIsPresent() appears to be returning FALSE in this case.
  
  patch used --http://people.freebsd.org/~sbruno/acpi_pcib.txt
 
 What happens if you just comment out the acpi_DeviceIsPresent() check?
 


wow, it booted up and seems to be fine.  huh ...
pcib7: ACPI PCI-PCI bridge at device 28.0 on pci0
pcib7:   domain0
pcib7:   secondary bus 7
pcib7:   subordinate bus   7
pcib7:   no prefetched decode
pci7: ACPI PCI bus on pcib7
pci7: domain=0, physical bus=7



___
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: stable/9 panic Bad tailq NEXT(0xffffffff80e52660-tqh_last) != NULL

[Sean Bruno]

 
  pcib7: ACPI PCI-PCI bridge irq 19 at device 28.7 on pci0
  panic: Bad tailq NEXT(0x80e52660-tqh_last) != NULL
  cpuid = 0
  KDB: stack backtrace:
  db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
  kdb_backtrace() at kdb_backtrace+0x37
  panic() at panic+0x1d8
  rman_init() at rman_init+0x17c
  pcib_alloc_window() at pcib_alloc_window+0x9f
  pcib_attach_common() at pcib_attach_common+0x457
  acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x1c
  device_attach() at device_attach+0x72
  bus_generic_attach() at bus_generic_attach+0x1a
  acpi_pci_attach() at acpi_pci_attach+0x164
  device_attach() at device_attach+0x72
  bus_generic_attach() at bus_generic_attach+0x1a
  acpi_pcib_attach() at acpi_pcib_attach+0x1a7
  acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x1f6
  device_attach() at device_attach+0x72
  bus_generic_attach() at bus_generic_attach+0x1a
  acpi_attach() at acpi_attach+0xbc1
  device_attach() at device_attach+0x72
  bus_generic_attach() at bus_generic_attach+0x1a
  nexus_acpi_attach() at nexus_acpi_attach+0x69
  device_attach() at device_attach+0x72
  bus_generic_new_pass() at bus_generic_new_pass+0xd6
  bus_set_pass() at bus_set_pass+0x7a
  configure() at configure+0xa
  mi_startup() at mi_startup+0x77
  btext() at btext+0x2c
  Uptime: 1s
  Automatic reboot in 15 seconds - press a key on the console to abort
  -- Press a key on the console to reboot,
  -- or switch off the system now.
 
 
 --
 Andriy Gapon
 

resurrecting this thread from my sent items folder, not sure if 
mailman will thread this correctly or not

Anyway, after disabling the broken pci bridge via some hackery
that jhb and eadler had lying around, I was able to get the r620 up 
on the new BIOS and get an acpidump before and after the firmware update.

I can poke a the machines, but I don't quite see in this nonsense where 
it breaks acpi_pcib_pci_attach().  Where should I start poking next?


http://people.freebsd.org/~sbruno/acpi_112_r620.txt

http://people.freebsd.org/~sbruno/acpi_126_r620.txt





___
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: stable/9 panic Bad tailq NEXT(0xffffffff80e52660-tqh_last) != NULL

[Sean Bruno]

On Thu, 2012-09-27 at 10:52 -0700, Sean Bruno wrote:
  
   pcib7: ACPI PCI-PCI bridge irq 19 at device 28.7 on pci0
   panic: Bad tailq NEXT(0x80e52660-tqh_last) != NULL
   cpuid = 0
   KDB: stack backtrace:
   db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
   kdb_backtrace() at kdb_backtrace+0x37
   panic() at panic+0x1d8
   rman_init() at rman_init+0x17c
   pcib_alloc_window() at pcib_alloc_window+0x9f
   pcib_attach_common() at pcib_attach_common+0x457
   acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x1c
   device_attach() at device_attach+0x72
   bus_generic_attach() at bus_generic_attach+0x1a
   acpi_pci_attach() at acpi_pci_attach+0x164
   device_attach() at device_attach+0x72
   bus_generic_attach() at bus_generic_attach+0x1a
   acpi_pcib_attach() at acpi_pcib_attach+0x1a7
   acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x1f6
   device_attach() at device_attach+0x72
   bus_generic_attach() at bus_generic_attach+0x1a
   acpi_attach() at acpi_attach+0xbc1
   device_attach() at device_attach+0x72
   bus_generic_attach() at bus_generic_attach+0x1a
   nexus_acpi_attach() at nexus_acpi_attach+0x69
   device_attach() at device_attach+0x72
   bus_generic_new_pass() at bus_generic_new_pass+0xd6
   bus_set_pass() at bus_set_pass+0x7a
   configure() at configure+0xa
   mi_startup() at mi_startup+0x77
   btext() at btext+0x2c
   Uptime: 1s
   Automatic reboot in 15 seconds - press a key on the console to abort
   -- Press a key on the console to reboot,
   -- or switch off the system now.
  
  
  --
  Andriy Gapon
  
 
 resurrecting this thread from my sent items folder, not sure if 
 mailman will thread this correctly or not
 
 Anyway, after disabling the broken pci bridge via some hackery
 that jhb and eadler had lying around, I was able to get the r620 up 
 on the new BIOS and get an acpidump before and after the firmware update.
 
 I can poke a the machines, but I don't quite see in this nonsense where 
 it breaks acpi_pcib_pci_attach().  Where should I start poking next?
 
 
 http://people.freebsd.org/~sbruno/acpi_112_r620.txt
 
 http://people.freebsd.org/~sbruno/acpi_126_r620.txt
 
 

For fun, I added the pciconf output to see if there's anything obviously
wrong with pcib7.  But, as usual, I have no idea how to interpret this.

http://people.freebsd.org/~sbruno/r620_pciconf.txt

Sean



___
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: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)

[Sean Bruno]

  igb+lagg worked for us on 8.3.  Haven't tried it since moving to 9.0
  and 9-STABLE on those three boxes.
 
  igb+lagg doesn't work for him on 9.0.  Although, I don't recall if
  non-LACP options were tried earlier in this thread, or if it's just
  the LACP mode that's failing.  If one mode works (say failover) and
  LACP mode doesn't, that seems to point to lagg.
 
  I'll see if I can free up an igb port on my 9.0 and 9-STABLE boxes to
  test this with as well.
 
 
 
 I wouldn't use 9.0, go with 9.1 RC or whatever has the latest igb code,
 if you see the issue there I can see about getting some time to look into
 it here.
 
 Jack


We're running igb + lagg on two interfaces here at Yahoo without issues
like this.  We're using LACP exclusively with Cisco switches.  If you're
seeing failover issues, I wonder if its the switch you're using as
opposed to the host and ethernet card?  Just a shot in the dark here.


Sean

___
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: [stable 9] panic on reboot: ipmi_wd_event()

[Sean Bruno]

On Thu, 2012-08-02 at 13:34 -0700, John Baldwin wrote:
 On Wednesday, August 01, 2012 6:48:48 pm Sean Bruno wrote:
  On Wed, 2012-08-01 at 05:53 -0700, John Baldwin wrote:
   Index: vfs_subr.c
   ===
   --- vfs_subr.c  (revision 238969)
   +++ vfs_subr.c  (working copy)
   @@ -1868,8 +1868,11 @@ sched_sync(void)
   continue;
   }

   -   if (first_printf == 0)
   +   if (first_printf == 0) {
   +   mtx_unlock(sync_mtx);
   wdog_kern_pat(WD_LASTVAL);
   +   mtx_lock(sync_mtx);
   +   }

   }
   if (!LIST_EMPTY(gslp)) {
   
   
   -- 
   John Baldwin 
  
  This definitely makes the panic go away on reboot.
 
 Do you have watchdogd enabled at all?
 

No, we never had it enabled.

Sean

___
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: [stable 9] panic on reboot: ipmi_wd_event()

[Sean Bruno]

On Wed, 2012-08-01 at 05:53 -0700, John Baldwin wrote:
 Index: vfs_subr.c
 ===
 --- vfs_subr.c  (revision 238969)
 +++ vfs_subr.c  (working copy)
 @@ -1868,8 +1868,11 @@ sched_sync(void)
 continue;
 }
  
 -   if (first_printf == 0)
 +   if (first_printf == 0) {
 +   mtx_unlock(sync_mtx);
 wdog_kern_pat(WD_LASTVAL);
 +   mtx_lock(sync_mtx);
 +   }
  
 }
 if (!LIST_EMPTY(gslp)) {
 
 
 -- 
 John Baldwin 

This definitely makes the panic go away on reboot.

Sean

___
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: Regression in stable for ThinkPad T520 with Intel GPU (Sandybridge) between June 22 and July 18

[Sean Bruno]

On Tue, 2012-07-24 at 18:35 -0700, Kevin Oberman wrote:
 I will shortly spend a bit of time tracking down the breakage more
 closely, but my 9-Stable system of June 22 runs fine. After an update
 on about July 10, I noted that it would hang after Xorg was started,
 but usually worked. After an upgrade to July 18, my system could no
 longer start Gnome. It would start Xorg and Gnome would start
 normally, getting many apps started, but about 10 seconds after the
 wallpaper loaded, the system would freeze solid. No network access and
 no response to mouse or keyboard.
 
 I have looked into commits to 9-STABLE during the time at issue and
 very little seems to have changed due to the pre-9.1 freeze.
 Similarly, nothing much has changed in any of the X11 ports.
 
 This really smells a lot like a race condition. I can trigger the same
 behavior by enabling VT-x (not VT-d) in BIOS. In all cases where it
 was intermittent, if my desktop completed startup, the system runs
 fine until re-booted. This is probably the primary reason I might not
 have realized that there was a problem as I don't boot the system
 often except when traveling, which I was between July 1 and July 6 and
 again July 18 when the system died.
 
 Any idea what I might try looking at?


Oh good, its not just me.  I note that this is happens when I'm not
hardwired in at my docking station as the system doesn't get a routeable
IP addr, until much later if on wireless.

When watching the system boot, I think I might ctrl-c the sendmail
startup or something when it starts to keep this from happening.

Sean

___
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

dell r420/r320 stable/9

[Sean Bruno]

For the time being I had to revert the following from my stable/9 tree.
Otherwise I would get a kernel panic on shutdown from ipmi(4).

http://svnweb.freebsd.org/base?view=revisionrevision=237839
http://svnweb.freebsd.org/base?view=revisionrevision=221121

I suspect that the ipmi device isn't detatching early or properly in
this configuration, but I have only just now discovered these changesets
as a clue to what's going on here.

The panic looks like this when you see it:

Sleeping thread (tid 100107, pid 9) owns a non-sleepable lock
KDB: stack backtrace of thread 100107:
sched_switch() at sched_switch+0x19f
mi_switch() at mi_switch+0x208
sleepq_switch() at sleepq_switch+0xfc
sleepq_wait() at sleepq_wait+0x4d
_sleep() at _sleep+0x3f6
ipmi_submit_driver_request() at ipmi_submit_driver_request+0x97
ipmi_set_watchdog() at ipmi_set_watchdog+0xb1
ipmi_wd_event() at ipmi_wd_event+0xaa
kern_do_pat() at kern_do_pat+0x10f
sched_sync() at sched_sync+0x1ea
fork_exit() at fork_exit+0x135
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff869b177bb0, rbp = 0 ---



___
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: Broadcom NetXtreme bcm5720 in the 9.1 beta

[Sean Bruno]

On Tue, 2012-07-24 at 18:46 -0700, Hiroki Sato wrote:
 Peter Feger magick...@gmail.com wrote
   in CAD_3y4wAPp+8ZSveB6mbOF7M1Ne-zAvz4Uf=vv9quohuu23...@mail.gmail.com:
 
 ma I just got done installing FreeBSD-9.0 on a Dell R720.  I can tell you
 ma that none of the broadcom products will work.  There is no driver that
 ma I have been able to find.  I wound up having to replace them with
 ma Intel nics.  I used the i350 quad-port 1G  and the x520 for 10G Fiber.
 
  I recently bought a Dell R420 which had BCM 5720 as the LOM.  The
  output of pciconf was the following:
 
 bge0@pci0:2:0:0:class=0x02 card=0x04f81028 chip=0x165f14e4 
 rev=0x00 hdr=0x00
 vendor = 'Broadcom Corporation'
 device = 'NetXtreme BCM5720 Gigabit Ethernet PCIe'
 class  = network
 subclass   = ethernet
 
  On 9.1-PRERELEASE as of Jul 23, it was recognized but did not work
  properly first (the link-status went back and forth between up and
  down).  However, after setting dev.bge.0.msi=0 it worked.  I am not
  sure of whether it had decent communication speed or not, but I saw
  it worked with 50MB/s or so at least.
 
  IPMI over LAN did not work even if hw.bge.allow_asf was set to 1.
 
 -- Hiroki



For the r420/320 ... grab Pyun's latest updates and give it a whirl.
They seem to work for us at yahoo:

http://people.freebsd.org/~yongari/bge/

Sean

___
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: Broadcom NetXtreme bcm5720 in the 9.1 beta

[Sean Bruno]

On Tue, 2012-07-24 at 17:44 -0700, Jurgen Weber wrote:
 yes, it is only the NIC's I want/need. I have an Intel card in it right 
 now, but its just a single port the onboard NIC's would be a nice to have.
 
 The raid worked out of the box for me, please remember 9.1beta thou.
 
 Thanks

For the r620/720 the ethernet board is a replaceable unit on the mother
board.  You can get your Dell rep to replace the Broadcom for an Intel
that works if you ask nicely.

Sean

___
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

HPET broken on Dell 1950's?

[Sean Chittenden]

I have an old Dell 1950 that I've rescued from Linux and tossed a copy of 
-STABLE on it, but am seeing a constant 0.5 load average. With the system 
completely idle, and kern.eventtimer.timer=LACPI, the load drops to the 
expected value of zero.

This feels like it should be an FAQ, but short of noting that the load is 
non-zero, is there a programatic way to determine if the event timer is 
broken? The system was functioning just fine, but it always had a constant 
load even when doing absolutely nothing. ?

FreeBSD ops05.internal 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #3: Tue Jul 24 
17:56:59 UTC 2012 root@ops05.internal:/usr/obj/usr/src/sys/GENERIC  amd64

kern.eventtimer.et.HPET.flags: 3
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.quality: 450
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.quality: 440
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.quality: 440
kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(400) i8254(100) 
RTC(0)
kern.eventtimer.timer: HPET
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.HPET.counter: 749769877
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.hardware: HPET
kern.timecounter.choice: TSC(-1000) ACPI-fast(900) HPET(950) i8254(0) 
dummy(-100)
dev.hpet.0.%desc: High Precision Event Timer
dev.hpet.0.%driver: hpet
dev.hpet.0.%location: handle=\_SB_.HPET
dev.hpet.0.%pnpinfo: _HID=PNP0103 _UID=0
dev.hpet.0.%parent: acpi0




--
Sean Chittenden
se...@freebsd.org






signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Broadcom NetXtreme bcm5720 in the 9.1 beta

[Sean Bruno]

On Tue, 2012-07-24 at 12:16 -0700, Peter Feger wrote:
 I just got done installing FreeBSD-9.0 on a Dell R720.  I can tell you
 that none of the broadcom products will work.  There is no driver that
 I have been able to find.  I wound up having to replace them with
 Intel nics.  I used the i350 quad-port 1G  and the x520 for 10G Fiber.
 
Confirmed over here at Yahoo.  The intel replacement board seems to just
work with stable/9 for me.  

 I also had an issue with the perc h710 raid controller. ( it uses the
 LSI SAS 2208 controller chip ) The FreeBSD hardware compatibility list
 shows that it uses the mtp driver which is incorrect.
 
Yeah, we should get that corrected.  This card is supported by stable/9
mfi(4)



Sean

___
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

[stable 9] panic on reboot: ipmi_wd_event()

[Sean Bruno]

Working on the Dell R420 today, got most of it working, even the
broadcom ethernet cards!  However, I get the following when I reboot the
system:

Syncing disks, vnodes remaining...4 Sleeping thread (tid 100107, pid 9)
owns a non-sleepable lock
KDB: stack backtrace of thread 100107:
sched_switch() at sched_switch+0x19f
mi_switch() at mi_switch+0x208
sleepq_switch() at sleepq_switch+0xfc
sleepq_wait() at sleepq_wait+0x4d
_sleep() at _sleep+0x3f6
ipmi_submit_driver_request() at ipmi_submit_driver_request+0x97
ipmi_set_watchdog() at ipmi_set_watchdog+0xb1
ipmi_wd_event() at ipmi_wd_event+0x8f
kern_do_pat() at kern_do_pat+0x10f
sched_sync() at sched_sync+0x1ea
fork_exit() at fork_exit+0x135
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff869b172bb0, rbp = 0 ---
panic: sleeping thread
cpuid = 26
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
panic() at panic+0x1d8
propagate_priority() at propagate_priority+0x223
turnstile_wait() at turnstile_wait+0x252
_mtx_lock_sleep() at _mtx_lock_sleep+0x124
_mtx_lock_flags() at _mtx_lock_flags+0xae
vn_syncer_add_to_worklist() at vn_syncer_add_to_worklist+0x3d
reassignbuf() at reassignbuf+0x12c
bdirty() at bdirty+0x50
softdep_disk_write_complete() at softdep_disk_write_complete+0x19f
bufdone_finish() at bufdone_finish+0x2d
bufdone() at bufdone+0x6c
g_io_schedule_up() at g_io_schedule_up+0xce
g_up_procbody() at g_up_procbody+0x72
fork_exit() at fork_exit+0x135
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff85d8a93bb0, rbp = 0 ---
Uptime: 1m59s
Dumping 1219 out of 24477 MB:panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep

Fatal double fault
rip = 0x807ac9d5
rsp = 0xff85d8a9
rbp = 0xff85d8a90020
cpuid = 26; apic id = 2a
panic: double fault
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
panic: msleep
cpuid = 26
Uptime: 1m59s
Rebooting...
cpu_reset: Restarting BSP
cpu_reset_proxy: Stopped CPU 26


___
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: stable/9 panic Bad tailq NEXT(0xffffffff80e52660-tqh_last) != NULL

[Sean Bruno]

On Mon, 2012-07-16 at 02:39 -0700, Andriy Gapon wrote:
 on 13/07/2012 19:31 Sean Bruno said the following:
  Well this is new.  I haven't a clue what Dell has done on this R620, but
  this popped up today after I did a boat load of BIOS updates and tried
  to install stable/9 from our yahoo tree.  If anyone sees the obvious
  solution here, I'd love to figure it out.
 
  found- vendor=0x14e4, dev=0x165f, revid=0x00
  domain=0, bus=2, slot=0, func=1
  class=02-00-00, hdrtype=0x00, mfdev=1
  cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords)
  lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
  intpin=b, irq=6
  powerspec 3  supports D0 D3  current D0
  MSI supports 8 messages, 64 bit
  MSI-X supports 17 messages in map 0x20
  map[10]: type Prefetchable Memory, range 64, base 0xd50d,
  size 16, enabled
  pcib1: allocated prefetch range (0xd50d-0xd50d) for rid 10 of
  pci0:2:0:1
  map[18]: type Prefetchable Memory, range 64, base 0xd50e,
  size 16, enabled
  pcib1: allocated prefetch range (0xd50e-0xd50e) for rid 18 of
  pci0:2:0:1
  map[20]: type Prefetchable Memory, range 64, base 0xd50f,
  size 16, enabled
  pcib1: allocated prefetch range (0xd50f-0xd50f) for rid 20 of
  pci0:2:0:1
  pcib1: matched entry for 2.0.INTB
  pcib1: slot 0 INTB hardwired to IRQ 36
  bge0: Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 mem
  0xd50a-0xd50a,0xd50b-0xd50b,0xd50c-0xd50c irq 34
  at device 0.0 on pci2
  bge0: APE FW version: NCSI v1.0.80.0
  bge0: attempting to allocate 1 MSI vectors (8 supported)
  msi: routing MSI IRQ 264 to local APIC 0 vector 59
  bge0: using IRQ 264 for MSI
  bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E
  bge0: Disabling fastboot
  bge0: Disabling fastboot
  miibus0: MII bus on bge0
  brgphy0: BCM5720C 1000BASE-T media interface PHY 1 on miibus0
  brgphy0: OUI 0x001be9, model 0x0036, rev. 0
  brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
  1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
  bge0: bpf attached
  bge0: Ethernet address: 18:03:73:fd:9e:36
  bge1: Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 mem
  0xd50d-0xd50d,0xd50e-0xd50e,0xd50f-0xd50f irq 36
  at device 0.1 on pci2
  bge1: APE FW version: NCSI v1.0.80.0
  bge1: attempting to allocate 1 MSI vectors (8 supported)
  msi: routing MSI IRQ 265 to local APIC 0 vector 60
  bge1: using IRQ 265 for MSI
  bge1: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E
  bge1: Disabling fastboot
  bge1: Disabling fastboot
  miibus1: MII bus on bge1
  brgphy1: BCM5720C 1000BASE-T media interface PHY 2 on miibus1
  brgphy1: OUI 0x001be9, model 0x0036, rev. 0
  brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
  1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
  bge1: bpf attached
  bge1: Ethernet address: 18:03:73:fd:9e:37
  pcib2: ACPI PCI-PCI bridge irq 53 at device 1.1 on pci0
  pcib0: allocated type 3 (0xd880-0xd8ff) for rid 20 of pcib2
  pcib0: allocated type 3 (0xd510-0xd51f) for rid 24 of pcib2
  pcib2:   domain0
  pcib2:   secondary bus 1
  pcib2:   subordinate bus   1
  pcib2:   memory decode 0xd880-0xd8ff
  pcib2:   prefetched decode 0xd510-0xd51f
  pci1: ACPI PCI bus on pcib2
  pci1: domain=0, physical bus=1
  found- vendor=0x14e4, dev=0x165f, revid=0x00
  domain=0, bus=1, slot=0, func=0
  class=02-00-00, hdrtype=0x00, mfdev=1
  cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords)
  lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
  intpin=a, irq=15
  powerspec 3  supports D0 D3  current D0
  MSI supports 8 messages, 64 bit
  MSI-X supports 17 messages in map 0x20
  map[10]: type Prefetchable Memory, range 64, base 0xd51a,
  size 16, enabled
  pcib2: allocated prefetch range (0xd51a-0xd51a) for rid 10 of
  pci0:1:0:0
  map[18]: type Prefetchable Memory, range 64, base 0xd51b,
  size 16, enabled
  pcib2: allocated prefetch range (0xd51b-0xd51b) for rid 18 of
  pci0:1:0:0
  map[20]: type Prefetchable Memory, range 64, base 0xd51c,
  size 16, enabled
  pcib2: allocated prefetch range (0xd51c-0xd51c) for rid 20 of
  pci0:1:0:0
  pcib2: matched entry for 1.0.INTA
  pcib2: slot 0 INTA hardwired to IRQ 35
  found- vendor=0x14e4, dev=0x165f, revid=0x00
  domain=0, bus=1, slot=0, func=1
  class=02-00-00, hdrtype=0x00, mfdev=1
  cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords)
  lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
  intpin=b, irq=6
  powerspec 3  supports D0 D3  current D0
  MSI supports 8 messages, 64 bit
  MSI-X supports 17 messages in map 0x20

stable/9 panic Bad tailq NEXT(0xffffffff80e52660-tqh_last) != NULL

[Sean Bruno]

Well this is new.  I haven't a clue what Dell has done on this R620, but
this popped up today after I did a boat load of BIOS updates and tried
to install stable/9 from our yahoo tree.  If anyone sees the obvious
solution here, I'd love to figure it out.

found- vendor=0x14e4, dev=0x165f, revid=0x00
domain=0, bus=2, slot=0, func=1
class=02-00-00, hdrtype=0x00, mfdev=1
cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=6
powerspec 3  supports D0 D3  current D0
MSI supports 8 messages, 64 bit
MSI-X supports 17 messages in map 0x20
map[10]: type Prefetchable Memory, range 64, base 0xd50d,
size 16, enabled
pcib1: allocated prefetch range (0xd50d-0xd50d) for rid 10 of
pci0:2:0:1
map[18]: type Prefetchable Memory, range 64, base 0xd50e,
size 16, enabled
pcib1: allocated prefetch range (0xd50e-0xd50e) for rid 18 of
pci0:2:0:1
map[20]: type Prefetchable Memory, range 64, base 0xd50f,
size 16, enabled
pcib1: allocated prefetch range (0xd50f-0xd50f) for rid 20 of
pci0:2:0:1
pcib1: matched entry for 2.0.INTB
pcib1: slot 0 INTB hardwired to IRQ 36
bge0: Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 mem
0xd50a-0xd50a,0xd50b-0xd50b,0xd50c-0xd50c irq 34
at device 0.0 on pci2
bge0: APE FW version: NCSI v1.0.80.0
bge0: attempting to allocate 1 MSI vectors (8 supported)
msi: routing MSI IRQ 264 to local APIC 0 vector 59
bge0: using IRQ 264 for MSI
bge0: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E
bge0: Disabling fastboot
bge0: Disabling fastboot
miibus0: MII bus on bge0
brgphy0: BCM5720C 1000BASE-T media interface PHY 1 on miibus0
brgphy0: OUI 0x001be9, model 0x0036, rev. 0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bge0: bpf attached
bge0: Ethernet address: 18:03:73:fd:9e:36
bge1: Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 mem
0xd50d-0xd50d,0xd50e-0xd50e,0xd50f-0xd50f irq 36
at device 0.1 on pci2
bge1: APE FW version: NCSI v1.0.80.0
bge1: attempting to allocate 1 MSI vectors (8 supported)
msi: routing MSI IRQ 265 to local APIC 0 vector 60
bge1: using IRQ 265 for MSI
bge1: CHIP ID 0x0572; ASIC REV 0x5720; CHIP REV 0x57200; PCI-E
bge1: Disabling fastboot
bge1: Disabling fastboot
miibus1: MII bus on bge1
brgphy1: BCM5720C 1000BASE-T media interface PHY 2 on miibus1
brgphy1: OUI 0x001be9, model 0x0036, rev. 0
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
bge1: bpf attached
bge1: Ethernet address: 18:03:73:fd:9e:37
pcib2: ACPI PCI-PCI bridge irq 53 at device 1.1 on pci0
pcib0: allocated type 3 (0xd880-0xd8ff) for rid 20 of pcib2
pcib0: allocated type 3 (0xd510-0xd51f) for rid 24 of pcib2
pcib2:   domain0
pcib2:   secondary bus 1
pcib2:   subordinate bus   1
pcib2:   memory decode 0xd880-0xd8ff
pcib2:   prefetched decode 0xd510-0xd51f
pci1: ACPI PCI bus on pcib2
pci1: domain=0, physical bus=1
found- vendor=0x14e4, dev=0x165f, revid=0x00
domain=0, bus=1, slot=0, func=0
class=02-00-00, hdrtype=0x00, mfdev=1
cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=15
powerspec 3  supports D0 D3  current D0
MSI supports 8 messages, 64 bit
MSI-X supports 17 messages in map 0x20
map[10]: type Prefetchable Memory, range 64, base 0xd51a,
size 16, enabled
pcib2: allocated prefetch range (0xd51a-0xd51a) for rid 10 of
pci0:1:0:0
map[18]: type Prefetchable Memory, range 64, base 0xd51b,
size 16, enabled
pcib2: allocated prefetch range (0xd51b-0xd51b) for rid 18 of
pci0:1:0:0
map[20]: type Prefetchable Memory, range 64, base 0xd51c,
size 16, enabled
pcib2: allocated prefetch range (0xd51c-0xd51c) for rid 20 of
pci0:1:0:0
pcib2: matched entry for 1.0.INTA
pcib2: slot 0 INTA hardwired to IRQ 35
found- vendor=0x14e4, dev=0x165f, revid=0x00
domain=0, bus=1, slot=0, func=1
class=02-00-00, hdrtype=0x00, mfdev=1
cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=6
powerspec 3  supports D0 D3  current D0
MSI supports 8 messages, 64 bit
MSI-X supports 17 messages in map 0x20
map[10]: type Prefetchable Memory, range 64, base 0xd51d,
size 16, enabled
pcib2: allocated prefetch range (0xd51d-0xd51d) for rid 10 of
pci0:1:0:1
map[18]: type Prefetchable Memory, range 64, base 0xd51e,
size 16, enabled
pcib2: allocated prefetch range (0xd51e-0xd51e) for rid 18 

Re: bge problems in RELENG_9, bge0: watchdog timeout -- resetting

[Sean Bruno]

On Thu, 2012-07-12 at 12:06 -0700, Sean Bruno wrote:
 On Thu, 2012-07-12 at 14:59 -0700, YongHyeon PYUN wrote:
   I grabbed these updates and applied them cleanly to stable/9 on a
  Dell
   R620 with a quad port BCM5720, I still see watchdog timeouts and
  reset
   indications.  I am able to ping out of the box for a short amount of
   time before the device hangs and times out.
   
  
  Sean, sorry for late reply.
  Given that I have no problems on sample 5720 controller I still
  have no clue yet.
  
 
 No problems ... :-)
 
   
   
   -bash-4.2# ping XXX.XXX.XXX.1
   PING XXX.XXX.XXX.1 (XXX.XXX.XXX.XXX): 56 data bytes
   ping: sendto: Network is down
   ping: sendto: Network is down
   ping: sendto: Network is down
   ping: sendto: Network is down
   ping: sendto: Network is down
   Jul  9 17:31:41 kern.crit x89 kernel: bge2: watchdog timeout --
   resetting
   Jul  9 17:31:41 kern.notice x89 kernel: bge2: link state changed
  to
   DOWN
   Jul  9 17:31:41 kern.notice x89 kernel: bge2: link state changed
  to
  
  Two link state change message indicates there is an issue in state
  tracking. I'm experimenting a different approach but it seems it
  takes too long due to lack of time. Any way, I've uploaded updated
  bge(4)(URL is the same as before).
 
 I see a bunch of firmware updates for this host along with an update to
 the BCM firmware package for this Dell box.
 
 I'll update my system's driver first, validate pass/fail, if fail, then
 I'll update the firmware bits and validate some more.
 
 sean
 

No real change.  I suspect something else is going on here that I don't
understand.  I note that when the system malfunctions now, the system
cannot boot and requires me to enter the bios to check my settings.

Sean


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

Re: bge problems in RELENG_9, bge0: watchdog timeout -- resetting

[Sean Bruno]

On Thu, 2012-07-12 at 14:59 -0700, YongHyeon PYUN wrote:
  I grabbed these updates and applied them cleanly to stable/9 on a
 Dell
  R620 with a quad port BCM5720, I still see watchdog timeouts and
 reset
  indications.  I am able to ping out of the box for a short amount of
  time before the device hangs and times out.
  
 
 Sean, sorry for late reply.
 Given that I have no problems on sample 5720 controller I still
 have no clue yet.
 

No problems ... :-)

  
  
  -bash-4.2# ping XXX.XXX.XXX.1
  PING XXX.XXX.XXX.1 (XXX.XXX.XXX.XXX): 56 data bytes
  ping: sendto: Network is down
  ping: sendto: Network is down
  ping: sendto: Network is down
  ping: sendto: Network is down
  ping: sendto: Network is down
  Jul  9 17:31:41 kern.crit x89 kernel: bge2: watchdog timeout --
  resetting
  Jul  9 17:31:41 kern.notice x89 kernel: bge2: link state changed
 to
  DOWN
  Jul  9 17:31:41 kern.notice x89 kernel: bge2: link state changed
 to
 
 Two link state change message indicates there is an issue in state
 tracking. I'm experimenting a different approach but it seems it
 takes too long due to lack of time. Any way, I've uploaded updated
 bge(4)(URL is the same as before).

I see a bunch of firmware updates for this host along with an update to
the BCM firmware package for this Dell box.

I'll update my system's driver first, validate pass/fail, if fail, then
I'll update the firmware bits and validate some more.

sean

___
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: Recommendation for Hyervisor to host FreeBSD

[Sean Bruno]

On Thu, 2012-07-05 at 04:43 -0700, Pete French wrote:
 So, my work surprise for a Thursday morning is an urgent requirement to
 see if we can run a set of FreeBSD machines under virtualised servers.
 I have not done this before personally, but I notice from post here
 that it doesnt seem uncommon, and I see Xen related commits flowing
 past, so I am guessing it is doable.
 
 So, for running 8 or 9 STABLE can anyone recommend which hypervisor
 works best, and is 8 or 9 better as the OS to run ? Am doing a bit
 of research myself, but nothing beats persoanl experience in these
 matters!
 
 cheers,
 
 -pete.

Just a few notes from clusteradm@ about this.

I've been running a CentOS 5 machine with xen3 pretty successfully with
PV 32 bit and 64 bit HVM vms for a while now.

I install CentOS 5 and then go to the gitco repo here:
http://www.gitco.de/repo/

Pretty straight forward stuff.  I install the VMs in full HVM mode using
VNC redirection and then switch them over to PV or HVM mode and setup
serial consoles.

If you have any questions, let me know.  I can dump some of the
configurations to help you out if you wish.

Sean

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

Re: bge problems in RELENG_9, bge0: watchdog timeout -- resetting

[Sean Bruno]

On Wed, 2012-07-04 at 18:01 -0700, YongHyeon PYUN wrote:
 here is a WIP version at the following URL.
 http://people.freebsd.org/~yongari/bge/if_bge.c
 http://people.freebsd.org/~yongari/bge/if_bgereg.h
 http://people.freebsd.org/~yongari/bge/brgphy.c
 
 I have a couple of positive feedbacks but it seems it still has
 some issues. Let me know whether it makes any difference on your
 box. 

I grabbed these updates and applied them cleanly to stable/9 on a Dell
R620 with a quad port BCM5720, I still see watchdog timeouts and reset
indications.  I am able to ping out of the box for a short amount of
time before the device hangs and times out.



-bash-4.2# ping XXX.XXX.XXX.1
PING XXX.XXX.XXX.1 (XXX.XXX.XXX.XXX): 56 data bytes
ping: sendto: Network is down
ping: sendto: Network is down
ping: sendto: Network is down
ping: sendto: Network is down
ping: sendto: Network is down
Jul  9 17:31:41 kern.crit x89 kernel: bge2: watchdog timeout --
resetting
Jul  9 17:31:41 kern.notice x89 kernel: bge2: link state changed to
DOWN
Jul  9 17:31:41 kern.notice x89 kernel: bge2: link state changed to
DOWN
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
64 bytes from XXX.XXX.XXX.1: icmp_seq=9 ttl=64 time=1.408 ms
Jul  9 17:31:45 kern.notice x89 kernel: bge2: link state changed to UP
Jul  9 17:31:45 kern.notice x89 kernel: bge2: link state changed to UP
64 bytes from 10.73.149.1: icmp_seq=10 ttl=64 time=1.697 ms
64 bytes from XXX.XXX.XXX.1: icmp_seq=11 ttl=64 time=1.835 ms
64 bytes from XXX.XXX.XXX.1: icmp_seq=12 ttl=64 time=1.390 ms
64 bytes from XXX.XXX.XXX.1: icmp_seq=13 ttl=64 time=1.392 ms
64 bytes from XXX.XXX.XXX.1: icmp_seq=14 ttl=64 time=1.392 ms
64 bytes from XXX.XXX.XXX.1: icmp_seq=15 ttl=64 time=1.848 ms
64 bytes from XXX.XXX.XXX.1: icmp_seq=16 ttl=64 time=1.389 ms
64 bytes from XXX.XXX.XXX.1: icmp_seq=17 ttl=64 time=1.541 ms
64 bytes from XXX.XXX.XXX.1: icmp_seq=18 ttl=64 time=1.575 ms

The stats counters don't really show much here, but here they are
regardless.
dev.bge.2.%desc: Broadcom NetXtreme Gigabit Ethernet, ASIC rev.
0x572
dev.bge.2.%driver: bge
dev.bge.2.%location: slot=0 function=0 handle=\_SB_.PCI0.PE1C.NDX0
dev.bge.2.%pnpinfo: vendor=0x14e4 device=0x165f subvendor=0x1028
subdevice=0x1f5b class=0x02
dev.bge.2.%parent: pci1
dev.bge.2.forced_collapse: 0
dev.bge.2.msi: 1
dev.bge.2.forced_udpcsum: 0
dev.bge.2.stats.FramesDroppedDueToFilters: 0
dev.bge.2.stats.DmaWriteQueueFull: 0
dev.bge.2.stats.DmaWriteHighPriQueueFull: 0
dev.bge.2.stats.NoMoreRxBDs: 0
dev.bge.2.stats.InputDiscards: 0
dev.bge.2.stats.InputErrors: 0
dev.bge.2.stats.RecvThresholdHit: 0
Jul  9 17:33:35 kern.notice x89 kernel: bge2: link state changed to
DOWN
dev.bge.2.stats.rx.ifHCInOctets: 109580
dev.bge.2.stats.rx.Fragments: 0
dev.bge.2.stats.rx.UnicastPkts: 212
dev.bge.2.stats.rx.MulticastPkts: 282
dev.bge.2.stats.rx.BroadcastPkts: 543
dev.bge.2.stats.rx.FCSErrors: 0
dev.bge.2.stats.rx.AlignmentErrors: 0
dev.bge.2.stats.rx.xonPauseFramesReceived: 0
dev.bge.2.stats.rx.xoffPauseFramesReceived: 0
dev.bge.2.stats.rx.ControlFramesReceived: 0
dev.bge.2.stats.rx.xoffStateEntered: 0
dev.bge.2.stats.rx.FramesTooLong: 0
dev.bge.2.stats.rx.Jabbers: 0
dev.bge.2.stats.rx.UndersizePkts: 0
dev.bge.2.stats.tx.ifHCOutOctets: 30916
dev.bge.2.stats.tx.Collisions: 0
dev.bge.2.stats.tx.XonSent: 0
dev.bge.2.stats.tx.XoffSent: 0
dev.bge.2.stats.tx.InternalMacTransmitErrors: 0
dev.bge.2.stats.tx.SingleCollisionFrames: 0
dev.bge.2.stats.tx.MultipleCollisionFrames: 0
dev.bge.2.stats.tx.DeferredTransmissions: 0
dev.bge.2.stats.tx.ExcessiveCollisions: 0
dev.bge.2.stats.tx.LateCollisions: 0
dev.bge.2.stats.tx.UnicastPkts: 203
dev.bge.2.stats.tx.MulticastPkts: 0
dev.bge.2.stats.tx.BroadcastPkts: 3




___
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 running too often

[Sean]

On 23/06/2012, at 7:47 AM, Leonardo M. Ramé wrote:

 Hi, since a few of days ago, I noticed my home server turns very slow more 
 than once a day, so every time I run top to see what's processes are 
 running, I can see fsck_ufs at the very top, and the hard drive working like 
 mad.
 
 I've checked my crontab and there's nothing related to fsck_ufs, where can I 
 start searching for the cause of the problem?, I thought this process should 
 run only at boot or shutdown, but this time it is running -apparently- 
 without a cause.
 
  

Background fsck. Your server crashed, rebooted, started up and fsck is running 
in the background while everything else continues.

Ways to avoid background fsck:

* Disable it completely in /etc/rc.conf: background_fsck=NO. Then fsck 
finishes completely before the OS continues booting, so there may be extended 
delays if a crash occurs.
* Use gjournal so fsck doesn't need to churn over the disks
* Turn on softupdates-journaling for a similar effect.

The more important thing is to find out why it crashed - if there was a power 
outage, hardware or software issue.



 uname -a:
 FreeBSD server.my.local 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 
 07:46:30 UTC 2012 
 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
 
 
 Regards,
 Leonardo M. Ramé
 http://leonardorame.blogspot.com
 ___
 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: Network unavailable when booting directly to FreeBSD.

[Sean Bruno]

On Thu, 2012-06-21 at 12:05 -0700, Pedro Giffuni wrote:
 Hello;
 
 I noticed a regression from 9.0 and I cannot boot directly FreeBSD
 and access the network. Unfortunately I cannot recall the exact
 commit where this started happening.
 
 uname -a
 FreeBSD pcbsd-8555 9.0-STABLE FreeBSD 9.0-STABLE #12: Wed May 30 
 11:16:35 PDT 2012 
 r...@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC
  
 amd64
 
  From my dmesg
 __
 ...
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pcib0: Length mismatch for 4 range: 81 vs 7f
 pci0: ACPI PCI bus on pcib0
 pci0: memory, RAM at device 0.0 (no driver attached)
 pci0: memory, RAM at device 0.1 (no driver attached)
 pci0: memory, RAM at device 0.2 (no driver attached)
 pci0: memory, RAM at device 0.3 (no driver attached)
 pci0: memory, RAM at device 0.4 (no driver attached)
 pci0: memory, RAM at device 0.5 (no driver attached)
 pci0: memory, RAM at device 0.6 (no driver attached)
 pci0: memory, RAM at device 0.7 (no driver attached)
 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0
 pci1: ACPI PCI bus on pcib1
 pcib2: ACPI PCI-PCI bridge at device 3.0 on pci0
 pci2: ACPI PCI bus on pcib2
 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 
 0x00b002 mem 0xfdef-0xfdef irq 16 at device 0.0 on pci2
 bge0: CHIP ID 0xb002; ASIC REV 0x0b; CHIP REV 0xb0; PCI-E
 miibus0: MII bus on bge0
 brgphy0: BCM5754/5787 1000BASE-T media interface PHY 1 on miibus0
 brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
 bge0: Ethernet address: 00:18:8b:76:a4:1e
 pcib3: ACPI PCI-PCI bridge at device 4.0 on pci0
 pci3: ACPI PCI bus on pcib3
 
 
 Cuse4BSD v0.1.23 @ /dev/cuse
 bge0: watchdog timeout -- resetting
 bge0: watchdog timeout -- resetting
 WARNING: attempt to domain_add(bluetooth) after domainfinalize()
 fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8
 bge0: watchdog timeout -- resetting
 bge0: link state changed to DOWN
 bge0: link state changed to UP
 bge0: watchdog timeout -- resetting
 bge0: link state changed to DOWN
 bge0: link state changed to UP
 bge0: watchdog timeout -- resetting
 bge0: link state changed to DOWN
 bge0: link state changed to UP
 _
 
 Iff I boot Windows first and then reboot to start FreeBSD the network
 works fine.
 
 Pedro.

I wonder if this is the one that caused your problems?

http://svnweb.freebsd.org/base?view=revisionrevision=233495

Can you post the full verbose dmesg and the output of pciconf -lvb for
review?

Sean

___
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: ATI Mobility Radeon HD 5470

[Sean Bruno]

On Thu, 2012-06-07 at 14:25 -0700, Vladimir Vasilenko wrote:
 Hello.
 
 Can I use this video card with FreeBSD? If yes so, where I can driver 
 download?
 
 
 Best regards,
 Vladimir Vasilenko vladi...@shumbely.com

I don't know if anyone responded to your question here.  I suspect that
the latest updates to xorg that have occured in freebsd will support
your video card.

There is no driver to download for this, it is provided via the xorg
installation, but you will have to update your system.  You may want to
try pc-bsd  http://pcbsd.org if you're looking to setup a fully
functional desktop-like PC.

Sean

ref.  http://miwi.bsdcrew.de/2012/06/cft-xorg-7-7-ready-for-testing/

___
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 and IPMI how-to (was Re: su problem)

[Sean Bruno]

On Thu, 2012-06-14 at 18:27 -0700, Matthew X. Economou wrote:
 Daniel Braniss writes:
 
  just for the record, serial on 8.x works fine! the device naming
  has changed from sio to uart, and maybe some features. We use it
  on all our servers, even redirecting it where possible via
  ILO,IMPI,DRAC.  and is great for debuging or saving long trips :-)
 
 Would some kind soul point me to a howto for configuring IPMI on
 FreeBSD?  I have a Dell PowerEdge 840 that supports IPMI, but I have
 no idea how to set it up - either in the BIOS or in FreeBSD.  I've
 messed around with ipmitools a little, but I haven't gotten it to
 work.
 
 Best wishes,
 Matthew
 


I would start with installing the ipmitool port.  Other may suggest
freeipmi and openipmi for great justice.

try poking around with sudo ipmitool shell and see if you can figure
out what's going on.

Sean

___
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: [stable 9] broken hwpstate calls

[Sean Bruno]

On Wed, 2012-06-06 at 16:02 -0700, Jung-uk Kim wrote:
 Buy me a Bulldozer and I'll fix it for you! :-P

Since I have one (FX-8150), do you want me to expose it to the internet
and let you play with it?

Sean

___
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 Intel 82599ES?

[Sean Bruno]

On Fri, 2012-06-01 at 10:45 -0700, Rick Miller wrote:
 BCM5720

I haven't gotten this working on my Dell R620 via bge(4), but we are
actively working on it.

Sean

___
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: bash 4.2 patchlevel 28

[Sean Bruno]

On Wed, 2012-05-30 at 20:19 -0700, David O'Brien wrote:
 On Thu, May 24, 2012 at 01:07:55PM -0700, Sean Bruno wrote:
  Noted that the following syntax is broken somewhere between 4.2
  patchlevel 10 and 28.  I'm sure its because we shouldn't be doing that
  over here at big purple, but we do ... and its a PITA.  I'm bisecting to
  find out what is going on.
 
 Hi Sean,
 Were you able to track down which patch 10-28 broke this for you?
 
 thanks,

After reverting back to patchlevel 10, I applied patches sequentially.
something about patchlevel 12 caused issues for our homebrew builds via
m4/bison that I haven't investigated.

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

Re: Dell R620 Ethernet Ordering

[Sean Bruno]

On Mon, 2012-05-28 at 13:52 -0700, sth...@nethelp.no wrote:
  Incidentally, does the broadcom driver in either 8 or 9 work for anyone? 
  When I try
  to use an 8 or 9 compiled in the past week I get unusable networking that 
  bounces up
  and down. I'm using an R620 with the quad-port broadcom daughtercard.
 
 I'm using several Dell servers with FreeBSD 8.2-STABLE and the bge
 driver. No problems that I can see.
 

You are using R620/720 machines with the 5720 add on board?

If you are, can you post a verbose dmesg?

Sean


___
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

[stable 9]Dell R620 Ethernet Ordering

[Sean Bruno]

I'm trying to understand the newbus and acpi interactions on this Dell
R620 that result in the Broadcom adapter board being probed backwards
or just plain out of order in comparison to the connector layout and the
linux tg3 driver. 

We seem to be detecting PCI0:2:0 before PCI0:1:0.  This seems odd to me.
When I replace the broadcom daughter card with an intel daughter card,
this does not show up, so I assume either a malfunction of the Dell ACPI
tables or the bge(4) driver.

http://people.freebsd.org/~sbruno/dell_12g_pciconf.txt

http://people.freebsd.org/~sbruno/r620_acpidump.txt

___
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

stable/9 sandybridge reboot panic

[Sean Bruno]

Dell R620, getting pretty reliable panics here everytime I reboot.

http://people.freebsd.org/~sbruno/sandybridge_reboot_panic.txt


Sean


___
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: stable/9 sandybridge reboot panic

[Sean Bruno]

On Fri, 2012-05-25 at 14:04 -0700, Sean Bruno wrote:
 Dell R620, getting pretty reliable panics here everytime I reboot.
 
 http://people.freebsd.org/~sbruno/sandybridge_reboot_panic.txt
 
 
 Sean
 
 
 ___

Verbose console boot ... interesting stuff about ioapic in there.

http://people.freebsd.org/~sbruno/dell_r620_fbsd9.txt

Sean

___
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

ports devel/tkcvs

[Sean Bruno]

Probably doing something wrong, but when I install tkcvs to get tkdiff
on my box, the only thing it does is fire up and display a wish
window.

Did I do it wrong?  :-)

sean

pkg_info |grep ^tk
tk-8.5.11   Graphical toolkit for Tcl
tk-wrapper-1.1_1Shell wrapper for wish (Tk)
tkcvs-8.2.3 Tcl/Tk frontends to CVS and Subversion
tkdiff-4.2  A Tk frontend for diff(1)


___
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

bash 4.2 patchlevel 28

[Sean Bruno]

Noted that the following syntax is broken somewhere between 4.2
patchlevel 10 and 28.  I'm sure its because we shouldn't be doing that
over here at big purple, but we do ... and its a PITA.  I'm bisecting to
find out what is going on.

test:
VARIABLE=$(uname)
bash: command substitution: line 3: syntax error near unexpected token
`)'
bash: command substitution: line 3: `uname)'

Odd, but his works at patchlevel 10

sean

___
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: bash 4.2 patchlevel 28

[Sean Bruno]

On Thu, 2012-05-24 at 13:07 -0700, Sean Bruno wrote:
 Noted that the following syntax is broken somewhere between 4.2
 patchlevel 10 and 28.  I'm sure its because we shouldn't be doing that
 over here at big purple, but we do ... and its a PITA.  I'm bisecting to
 find out what is going on.
 
 test:
 VARIABLE=$(uname)
 bash: command substitution: line 3: syntax error near unexpected token
 `)'
 bash: command substitution: line 3: `uname)'
 
 Odd, but his works at patchlevel 10
 
 sean

At least that was easy.  It's patch level 12.  Sequential sort pays
dividends today.

Sean

___
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: bash 4.2 patchlevel 28

[Sean Bruno]

On Thu, 2012-05-24 at 13:14 -0700, Sean Bruno wrote:
 
 On Thu, 2012-05-24 at 13:07 -0700, Sean Bruno wrote:
  Noted that the following syntax is broken somewhere between 4.2
  patchlevel 10 and 28.  I'm sure its because we shouldn't be doing that
  over here at big purple, but we do ... and its a PITA.  I'm bisecting to
  find out what is going on.
  
  test:
  VARIABLE=$(uname)
  bash: command substitution: line 3: syntax error near unexpected token
  `)'
  bash: command substitution: line 3: `uname)'
  
  Odd, but his works at patchlevel 10
  
  sean
 
 At least that was easy.  It's patch level 12.  Sequential sort pays
 dividends today.
 
 Sean
 


Hrm ... and it also appears that if I use bison + m4 I don't have this
issue, but if I let the configure scripts use /usr/bin/yacc alone this
problem manifests itself.  odd.

sean

___
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: [stable 9] broken hwpstate calls

[Sean Bruno]

On Fri, 2012-05-18 at 09:18 -0700, Jung-uk Kim wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 2012-05-18 01:32:09 -0400, Sean Bruno wrote:
  Looks like my AMD box isn't quite working correctly with regards
  to P-states.I noted this repeating periodically: hwpstate0: set
  freq failed, err 6
  
  
  I noted these errors when setting the hwpstate verbose systctl on:
  
  May 17 22:28:32 Alice kernel: hwpstate0: set freq failed, err 6 May
  17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu0 May
  17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu0 May
  17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu1 May
  17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu1 May
  17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu2 May
  17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu2 May
  17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu3 May
  17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu3 May
  17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu4 May
  17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu4 May
  17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu5 May
  17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu5 May
  17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu6 May
  17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu6 May
  17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu7 May
  17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu7
  
  
  Sean
  
  ref this machine:  http://forums.pcbsd.org/showthread.php?t=16733
 
 I briefly looked at the dmesg.  You have a Family 15h processor
 (Bulldozer with Turbo Core) and I believe it isn't supported (yet).
 It won't be too hard to implement, though.
 
 Jung-uk Kim


I'm assuming, something like this to start?

http://people.freebsd.org/~sbruno/bulldozer.txt

I'm reading the AMD spec, and that *seems* to be right?  But, chances
are I have no idea what I'm doing.  :-)

Sean

___
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: [stable-9] Touchpad mouse stopped working

[Sean Bruno]

On Thu, 2012-05-17 at 04:01 -0700, A.J. Fonz van Werven wrote:
 After moving from 9.0-RELEASE to 9-STABLE yesterday, the touchpad mouse on
 my netbook stopped working. When I do
 # /etc/rc.d/moused onestart
 the pointer appears and can be moved for a second or two, then it stops
 responding. Any thoughts?
 
 $ uname -a
 FreeBSD ace.skysmurf.nl 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu May 17 10:49:00 
 CEST 2012 r...@ace.skysmurf.nl:/usr/obj/usr/src/sys/GENERIC  i386
 
 Fonz
 

Just a me too from my perspective.  I'm currently trying to rebuild
ports/x11-drivers/xf86-input-[mouse|keyboard] as that seems to have
failed to have been rebuilt properly during a recent portupgrade.

Sean

___
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

[stable 9] broken hwpstate calls

[Sean Bruno]

Looks like my AMD box isn't quite working correctly with regards to
P-states.I noted this repeating periodically:
hwpstate0: set freq failed, err 6


I noted these errors when setting the hwpstate verbose systctl on:

May 17 22:28:32 Alice kernel: hwpstate0: set freq failed, err 6
May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu0
May 17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu0
May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu1
May 17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu1
May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu2
May 17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu2
May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu3
May 17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu3
May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu4
May 17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu4
May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu5
May 17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu5
May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu6
May 17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu6
May 17 22:28:32 Alice kernel: hwpstate0: setting P1-state on cpu7
May 17 22:28:32 Alice kernel: hwpstate0: result  P1-state on cpu7


Sean

ref this machine:  http://forums.pcbsd.org/showthread.php?t=16733

___
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: ATI Radeon 4250 in Dual Head Config?

[Sean Bruno]

On Mon, 2012-04-16 at 08:29 -0700, Sean Bruno wrote:
 My xorg.conf foo is pretty weak today.
 
 Does anyone have an ATI 4250 in a dual head config?  I'd be interested
 in looking over your xorg.conf.
 
 Sean
 

I note that xrandr just works now with this card after updating my
ports of xorg.  thanks to the xorg team for making this update!

Sean

___
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

ATI Radeon 4250 in Dual Head Config?

[Sean Bruno]

My xorg.conf foo is pretty weak today.

Does anyone have an ATI 4250 in a dual head config?  I'd be interested
in looking over your xorg.conf.

Sean

p.s.  Mine at the moment, that doesn't work very well:
http://people.freebsd.org/~sbruno/4250_xorg_conf.txt

___
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: [stable-ish 9] Dell R815 ipmi(4) attach failure

[Sean Bruno]

On Fri, 2012-03-30 at 09:29 -0700, John Baldwin wrote:
 On Thursday, March 29, 2012 12:48:39 pm Sean Bruno wrote:
  Noting a failure to attach to the onboard IPMI controller with this dell
  R815.  Not sure what to start poking at and thought I'd though this over
  here for comment.
  
  -bash-4.2$ dmesg |grep ipmi
  ipmi0: KCS mode found at io 0xca8 on acpi
  ipmi1: IPMI System Interface on isa0
  device_attach: ipmi1 attach returned 16
  ipmi1: IPMI System Interface on isa0
  device_attach: ipmi1 attach returned 16
  ipmi0: Timed out waiting for GET_DEVICE_ID
  
  
  -bash-4.2$ sysctl -a|grep ipmi
  device  ipmi# IPMI
  hw.ipmi.on: 1
  dev.ipmi.0.%desc: IPMI System Interface
  dev.ipmi.0.%driver: ipmi
  dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM
  dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5
  dev.ipmi.0.%parent: acpi0
 
 Can you get dmidecode output?
 


http://people.freebsd.org/~sbruno/dmidecode_r815.txt

http://people.freebsd.org/~sbruno/pciconf_r815.txt

Sean

___
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: [stable-ish 9] Dell R815 ipmi(4) attach failure

[Sean Bruno]

 This is the relevant bits:
 
 Handle 0x2600, DMI type 38, 18 bytes
 IPMI Device Information
   Interface Type: KCS (Keyboard Control Style)
   Specification Version: 2.0
   I2C Slave Address: 0x10
   NV Storage Device: Not Present
   Base Address: 0x0CA8 (I/O)
   Register Spacing: 32-bit Boundaries
 
 Note the '32-bit' boundaries.  I think ACPI doesn't support that for its 
 attachment (well, it does if they specify each port as a separate thing in 
 _CRS).  Can you get acpidump -d output?
 

Aye, here ya go. 

http://people.freebsd.org/~sbruno/acpidump_r815.txt

sean

___
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

[stable-ish 9] Dell R815 ipmi(4) attach failure

[Sean Bruno]

Noting a failure to attach to the onboard IPMI controller with this dell
R815.  Not sure what to start poking at and thought I'd though this over
here for comment.

-bash-4.2$ dmesg |grep ipmi
ipmi0: KCS mode found at io 0xca8 on acpi
ipmi1: IPMI System Interface on isa0
device_attach: ipmi1 attach returned 16
ipmi1: IPMI System Interface on isa0
device_attach: ipmi1 attach returned 16
ipmi0: Timed out waiting for GET_DEVICE_ID


-bash-4.2$ sysctl -a|grep ipmi
device  ipmi# IPMI
hw.ipmi.on: 1
dev.ipmi.0.%desc: IPMI System Interface
dev.ipmi.0.%driver: ipmi
dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM
dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5
dev.ipmi.0.%parent: acpi0


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

Re: FreeBSD 9.0 release - memstick installation fails

[Sean Bruno]

You may want to try playing around with BIOS settings regarding USB.

Sean

On Fri, 2012-03-02 at 13:01 -0800, Kai Gallasch wrote:
 Hi list.
 
 Trying to install 9.0 release with a USB stick.
 I use FreeBSD-9.0-RELEASE-amd64-memstick.img
 
 At first the bootup looks promising, but in the end it stops with Root mount 
 waiting for: usbus2 usbus1 usbus
 
 To single out a bad USB stick I tried FreeBSD-8.3-BETA1-amd64-memstick.img 
 with the same stick and there are no problems.
 
 The hardware is an older HP/Compaq DL145-G3, but why toss it in the trash?
 
 How can I debug this further?
 Any hints?
 
   Kai.
 
 
   snip 
 
 SMAP type=01 base= len=0009c000
 SMAP type=02 base=0009c000 len=4000
 SMAP type=02 base=000ce000 len=00032000
 SMAP type=01 base=0010 len=dbe6
 SMAP type=03 base=dbf6 len=7000
 SMAP type=04 base=dbf67000 len=00019000
 SMAP type=02 base=dbf8 len=0008
 SMAP type=02 base=e000 len=1000
 SMAP type=02 base=fec0 len=3000
 SMAP type=02 base=fee0 len=1000
 SMAP type=02 base=fff8 len=0008
 SMAP type=01 base=0001 len=00012400
 Table 'FACP' at 0xdbf62be7
 Table 'SPMI' at 0xdbf66bf5
 Table 'SSDT' at 0xdbf66c35
 Table 'HPET' at 0xdbf66e7d
 Table 'SSDT' at 0xdbf66eb5
 Table 'MCFG' at 0xdbf66efe
 Table 'SPCR' at 0xdbf66f3a
 Table 'APIC' at 0xdbf66f8a
 APIC: Found table at 0xdbf66f8a
 APIC: Using the MADT enumerator.
 MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
 SMP: Added CPU 0 (AP)
 MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
 SMP: Added CPU 1 (AP)
 Copyright (c) 1992-2012 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.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012
r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
 Table 'FACP' at 0xdbf62be7
 Table 'SPMI' at 0xdbf66bf5
 Table 'SSDT' at 0xdbf66c35
 Table 'HPET' at 0xdbf66e7d
 Table 'SSDT' at 0xdbf66eb5
 Table 'MCFG' at 0xdbf66efe
 Table 'SPCR' at 0xdbf66f3a
 Table 'APIC' at 0xdbf66f8a
 ACPI: No SRAT table found
 Preloaded elf kernel /boot/kernel/kernel at 0x813cf000.
 Calibrating TSC clock ... TSC clock: 2394059007 Hz
 CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-MHz K8-class CPU)
  Origin = AuthenticAMD  Id = 0x40f13  Family = f  Model = 41  Stepping = 3
  
 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT
  Features2=0x2001SSE3,CX16
  AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!
  AMD Features2=0x1fLAHF,CMP,SVM,ExtAPIC,CR8
 L1 2MB data TLB: 8 entries, fully associative
 L1 2MB instruction TLB: 8 entries, fully associative
 L1 4KB data TLB: 32 entries, fully associative
 L1 4KB instruction TLB: 32 entries, fully associative
 L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
 L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
 L2 2MB unified TLB: 0 entries, disabled/not present
 L2 4KB data TLB: 512 entries, 4-way associative
 L2 4KB instruction TLB: 512 entries, 4-way associative
 L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative
 real memory  = 8589934592 (8192 MB)
 Physical memory chunk(s):
 0x1000 - 0x00097fff, 618496 bytes (151 pages)
 0x0010 - 0x001f, 1048576 bytes (256 pages)
 0x01403000 - 0xdbf5, 3669348352 bytes (895837 pages)
 0x0001 - 0x000213e45fff, 4628701184 bytes (1130054 pages)
 avail memory = 8244486144 (7862 MB)
 Event timer LAPIC quality 400
 ACPI APIC Table: PTLTDAPIC  
 INTR: Adding local APIC 1 as a target
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 x86bios:  IVT 0x00-0x0004ff at 0xfe00
 x86bios: SSEG 0x001000-0x001fff at 0xff800022
 x86bios: EBDA 0x09c000-0x09 at 0xfe09c000
 x86bios:  ROM 0x0a-0x0fefff at 0xfe0a
 APIC: CPU 0 has ACPI ID 0
 APIC: CPU 1 has ACPI ID 1
 ULE: setup cpu 0
 ULE: setup cpu 1
 ACPI: RSDP 0xf8510 00024 (v02 PTLTD )
 ACPI: XSDT 0xdbf62b83 00064 (v01 PTLTD  ? XSDT   0604  LTP )
 ACPI: FACP 0xdbf62be7 00084 (v02 HP TREX 0604 MSFT 0201)
 ACPI: DSDT 0xdbf62c6b 03F8A (v01 HP TREX 0604 MSFT 0202)
 ACPI: FACS 0xdbf6ffc0 00040
 ACPI: SPMI 0xdbf66bf5 00040 (v05 HP TREX 0604 PTL  0001)
 ACPI: SSDT 0xdbf66c35 00248 (v01 PTLTD  POWERNOW 0604  LTP 0001)
 ACPI: HPET 0xdbf66e7d 00038 (v01 BRCM   EXPLOSN  0604 BRCM 0201)
 ACPI: SSDT 0xdbf66eb5 00049 (v01

Re: Odd reboot problems with 9.0-RELEASE i386

[Sean Bruno]

On Thu, 2012-01-19 at 14:06 -0800, Dwayne MacKinnon wrote:
 Hi all,
 
 I recently upgraded my 8.2-RELEASE box to 9.0-RELEASE using the old-fashioned 
 cvsup way. I've run into a really strange situation.
 
 Everything went smoothly with the upgrade. I then deleted all my installed 
 ports and started reinstalling. I noticed the problem when trying to compile 
 openjdk6.
 
 The box would spontaneously reboot. All the time.
 
 So, I put the following into /etc/rc.conf. I'll repost here, it's entirely 
 possible I did something wrong:
 
 dumpdev=/dev/ada0s1b  # Device to crashdump to (device name, AUTO, or 
 NO).
 dumpdir=/usr/crash/# Directory where crash dumps are to be stored
 
 I made sure /usr/crash was created and had permissions wide open. Yet, I 
 never 
 got any crash dumps (I recreated the reboot several times over.)
 
 I tried compiling a GENERIC kernel; that failed as well. So I got the DVD 
 iso, 
 and copied over the /boot/kernel directory from it. 
 
 Once I did that, i was able to compile a new GENERIC kernel no problem. (I 
 need to take out the pcn driver; I need le and pcn jumps it.) 
 
 With the slightly-modified GENERIC kernel, the problem has disappeared. I've 
 compiled openjdk no problem. I tried recompiling my custom kernel and 
 reinstalled it; the problem reappeared.
 
 I've attached my kernel config file; there's nothing revolutionary about it. 
 It's almost identical to the one I used for 8.2-RELEASE, but based on the new 
 9.0 GENERIC.  Maybe someone here will find it useful.
 
 A cc would be appreciated as I don't follow -stable.
 
 Cheers,
 DMK


This sounds suspciously like a bug the ports team found on the the 9 RC
series.  I can't recall where it got fixed, but I'm pretty sure it did
*not* make it to the release.

You may have better luck with stable/9 instead of 9.0-RELEASE if you can
do that.

Sean

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

panic in bios32 ... stable/7

[Sean Bruno]

This probably applies to all releases, but for now I'm concentrating on
stable/7.

We have beta Dell r720 (12g) gear in the office and I suspect a broken
EFI wrapped BIOS thing here, but freebsd definitely panics on startup.  

OK boot -v
KDB: debugger backends: ddb
KDB: current backend: ddb
SMAP type=01 base= len=000a
SMAP type=01 base=0010 len=cd20
SMAP type=02 base=cd30 len=0002c000
SMAP type=03 base=cd32c000 len=0003f000
SMAP type=02 base=cd36b000 len=02c95000
SMAP type=02 base=e000 len=1000
SMAP type=02 base=fe00 len=0200
SMAP type=01 base=0001 len=000f3000
Physical memory use set to 2097152K
Copyright (c) 1992-2011 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 7.4-YAHOO-20111021 #0 ybsd_7@307778: Thu Dec 15 23:31:18 UTC 2011
sean...@x85.klab.corp.yahoo.com:/home/src/sys/i386/compile/NETBOOT i386
Preloaded elf kernel /boot/kernel at 0xa92c9000.
Preloaded mfs_root /boot/build.dsk at 0xa92c917c.
Calibrating clock(s) ... i8254 clock: 1193157 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2700021228 Hz
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz (2700.02-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x206d6  Family = 6  Model = 2d  Stepping = 6
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  
Features2=0x17bee3ffSSE3,b1,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,b17,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,b24,b25,XSAVE,b28
  AMD Features=0x2c10NX,Page1GB,RDTSCP,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant
  Cores per package: 16
  Logical CPUs per core: 2

Data TLB: 4 KB pages, 4-way set associative, 64 entries
L2 cache: 256 kbytes, 8-way associative, 64 bytes/line
real memory  = 2147483648 (2048 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x0960a000 - 0x7d995fff, 1949876224 bytes (476044 pages)
avail memory = 1942470656 (1852 MB)
Table 'FACP' at 0xcd35119c
Table 'APIC' at 0xcd350478
APIC: Found table at 0xcd350478
MP Configuration Table version 1.4 found at 0xa00f
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 32 ACPI ID 2: enabled
SMP: Added CPU 32 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 3: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 34 ACPI ID 4: enabled
SMP: Added CPU 34 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 5: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 36 ACPI ID 6: enabled
SMP: Added CPU 36 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 7: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 38 ACPI ID 8: enabled
SMP: Added CPU 38 (AP)
MADT: Found CPU APIC ID 8 ACPI ID 9: enabled
SMP: Added CPU 8 (AP)
MADT: Found CPU APIC ID 40 ACPI ID 10: enabled
SMP: Added CPU 40 (AP)
MADT: Found CPU APIC ID 10 ACPI ID 11: enabled
SMP: Added CPU 10 (AP)
MADT: Found CPU APIC ID 42 ACPI ID 12: enabled
SMP: Added CPU 42 (AP)
MADT: Found CPU APIC ID 12 ACPI ID 13: enabled
SMP: Added CPU 12 (AP)
MADT: Found CPU APIC ID 44 ACPI ID 14: enabled
SMP: Added CPU 44 (AP)
MADT: Found CPU APIC ID 14 ACPI ID 15: enabled
SMP: Added CPU 14 (AP)
MADT: Found CPU APIC ID 46 ACPI ID 16: enabled
SMP: Added CPU 46 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 17: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 33 ACPI ID 18: enabled
SMP: Added CPU 33 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 19: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 35 ACPI ID 20: enabled
SMP: Added CPU 35 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 21: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 37 ACPI ID 22: enabled
SMP: Added CPU 37 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 23: enabled
SMP: Added CPU 7 (AP)
MADT: Found CPU APIC ID 39 ACPI ID 24: enabled
SMP: Added CPU 39 (AP)
MADT: Found CPU APIC ID 9 ACPI ID 25: enabled
SMP: Added CPU 9 (AP)
MADT: Found CPU APIC ID 41 ACPI ID 26: enabled
SMP: Added CPU 41 (AP)
MADT: Found CPU APIC ID 11 ACPI ID 27: enabled
SMP: Added CPU 11 (AP)
MADT: Found CPU APIC ID 43 ACPI ID 28: enabled
SMP: Added CPU 43 (AP)
MADT: Found CPU APIC ID 13 ACPI ID 29: enabled
SMP: Added CPU 13 (AP)
MADT: Found CPU APIC ID 45 ACPI ID 30: enabled
SMP: Added CPU 45 (AP)
MADT: Found CPU APIC ID 15 ACPI ID 31: enabled
SMP: Added CPU 15 (AP)
MADT: Found CPU APIC ID 47 ACPI ID 32: enabled
SMP: Added CPU 47 (AP)
ACPI APIC Table: DELL   PE_SC3  
INTR: Adding local APIC 2 as a target
INTR: Adding local APIC 4 as a target
INTR: Adding

Re: FreeBSD at Amazon EC2 status

[Sean Bruno]

On Tue, 2012-01-03 at 09:07 -0800, Alexandre Biancalana wrote:
 Hi lists,
 
  What´s is the current state of FreeBSD running on Amazon EC2 ? Is
 this stable ? Looking at Colin's status page
 (http://www.daemonology.net/freebsd-on-ec2/) looks like there´s no
 active development on that.
 
  Does someone running production workload with FreeBSD on EC2 ?
 
  I'm interested in running network (dns and http with accept filter)
 and memory/buffer cache intensive applications on m1.small, m1.large
 and m2.xlarge instances.
 
  Any thoughts ?
 
  (I had posted this message to -question list, sorry for whom already
 received this)
 
 Best Regards and Happy New Year !
 Alexandre

I suspect that the folks on x...@freebsd.org could comment on this.
FreeBSD on EC2 is working fine as far as I know, however I don't
personally use it at this time.

Sean

___
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: (Possible fix for sbp(4)) Re: Comment out sbp driver from GENERIC

[Sean Bruno]

On Thu, 2011-10-27 at 06:16 -0700, Wojciech A. Koszek wrote:
 Dnia 18-10-2011 o 14:12:56 Alberto Villa avi...@freebsd.org napisał(a):
 
  On Tue, Oct 18, 2011 at 1:48 PM, Wojciech A. Koszek
  wkos...@freebsd.czest.pl wrote:
  Commenting a driver out is almost always a bad idea and should
  be done as a last step.
 
  Well, few weeks prior to -RELEASE can be considered a last step. :)
 
  If you are impacted by sbp(4) hangs please follow this thread:
 
 
   
  http://lists.freebsd.org/pipermail/freebsd-current/2007-December/081411.html
 
  And please let me know if a fix explained in this thread works for you.
 
  Thank you, will test it in few days.
 
 Any updates?
 

I wish I could get access to one of these hosts or laptops that have
issues with firewire.  If there's anyway I can play with a machine
remotely that has this issue, please contact me.

Probably what I'd want, is ssh access and sudo access to kldload sbp.ko 

Sean

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

Re: ZFS directory with a large number of files

[Sean Rees]

On Aug 6, 2011, at 07:24, Gary Palmer wrote:

 On Fri, Aug 05, 2011 at 08:56:36PM -0700, Doug Barton wrote:
 On 08/05/2011 20:38, Daniel O'Connor wrote:
 
 Ahh, but OP had moved these files away and performance was still poor.. 
 _that_ is the bug.
 
 I'm no file system expert, but it seems to me the key questions are; how
 long does it take the system to recover from this condition, and if it's
 more than N $periods is that a problem? We can't stop users from doing
 wacky stuff, but the system should be robust in the face of this.
 
 Its been quite a while since I worked on the filesystem stuff in any
 detail but I believe, at least for UFS, it doesn't GC the directory,
 just truncate it if enough of the entries at the end are deleted
 to free up at least one fragment or block.  If you create N files and
 then a directory and move the N files into the directory, the directory
 entry will still be N+1 records into the directory and the only way to
 recover is to recreate the directory that formerly contained the N
 files.  It is theoretically possible to compat the directory but since 
 the code to do that wasn't written when I last worked with UFS I suspect
 its non trivial.
 
 I don't know what ZFS does in this situation

It sounds like it does something similar.

I re-ran the experiment to see if I could narrow down the problem.

% mkdir foo
% cd foo  for i in {1..1000}; do touch $i; done
% ls  list
% for file in $(cat list); do rm -f $file; done
% time ls
(slow!)
% rm -f list
% time ls
(slow!)

I would like to dig into this a bit more, I suppose it's probably a good enough 
reason to explore how DTrace works :)

Sean___
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

[Sean]

On Thu, 21 Jul 2011, Bakul Shah wrote:


On Thu, 21 Jul 2011 15:28:08 PDT Chuck Swiger cswi...@mac.com  wrote:

On Jul 21, 2011, at 2:56 PM, Bakul Shah wrote:

I am in no hurry to upgrade my MBP to OS X Lion but given Lion
time machine and netatalk issues,


Which issues?  (And did you file a bug report?  :-)


Google `os x lion netatalk time machine'! But briefly, a newer
version of the appletalk protocol is used with lion time
machine which is not supported by netatalk in the ports.
netafp.com (I think that is the right name) has a new version
but at least for now it is closed source (only their customers
get it -- whether they are breaking the GPL or not is a
discussion belongs elsehere). The version in sourceforge is
not quite upto snuff from what I hear.


The 2.2beta apparently supports AFP 3.3, but it's not in the ports
tree yet.




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


There was a fine discussion about this here:

  http://freebsd.1045724.n5.nabble.com/ZFS-vs-OSX-Time-Machine-td4346562.html


Thanks. I think I saw it back then Nothing new since then?
___
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: em0 hangs without any messages like Watchdog timeout only down/up reset it.

[Sean Bruno]

On Thu, 2011-02-24 at 03:03 -0800, Pete French wrote:
 I havent investigated far enough yet to see if this is the same problem, but
 I am also seeing hangs on em0 when under heavy load. This is 8-STABLE from
 the 17 at around 3pm.
 
 em0@pci0:0:25:0:class=0x02 card=0x281e103c chip=0x10bd8086 
 rev=0x02 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)'
 class  = network
 subclass   = ethernet
 
 What I am doing here is using ggated/ggatec to provide drives to another
 machine which is adding them into a ZFS pool. This locks up the ethernet
 in about 20 minutes. Going to concole on the machine all looks fine,
 but it is not possible to ping anything through the em0 interface.
 
 I have no special tunings for em0, though I do have expanded buffer
 space to improve the ggated performance
 
 kern.ipc.maxsockbuf=1048576
 net.inet.tcp.sendspace=131072
 net.inet.tcp.recvspace=131072
 
 Machine is amd64 with 6 gig of RAM.
 
 -pete.
 _
If you ifconfig down/up the interface does it come back to life?

Sean

___
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: cdrtools /devel and wodim broken

[Sean C. Farley]

On Tue, 26 Oct 2010, Paul B Mahol wrote:


On 10/26/10, Jakub Lach jakub_l...@mailplus.pl wrote:

Joerg Schilling-3 wrote:


wodim is a dead end from a 6 year old version of cdrecord with the 
DVD support ripped off and replaced by something broken. But there 
have been even more bugs added to wodim and it is not under 
development since May 2007.


If cdrecord gives the same message, I encourage you to make a kernel 
bug report.  This message is a hint to a serious kernel problem. A 
sense key value -1 cannot happen, so you need to find out why the 
SCSI command has not been transported correctly by the kernel.




Hi Joerg.

I usually prefer cdrtools, wodim was convenient way to
try old code.

After booting GENERIC kernel + ahci driver and compiling
cdrtools release problem is still present.


*snip*


I burned bunch of DVD-R, DVD+R and DVD+R DL on FreeBSD 9.0 without any
problems, using growisofs from ports.

Only problem I ever had was mounting multi-sesion after 4GB (but -r
flag is nice workaround).


Personally, I have had trouble burning to a DVD+R using cdrecord. 
DVD+RW has generally worked for me on my workstation, however, I noticed 
something interesting last night.  When trying to burn a recovery disc 
using my laptop onto a DVD-RW, a pause occurred near the start of the 
burn, maybe after two blocks were written, with the disc completing the 
burn successfully.  I use quotes because the disc did not boot.


I am not sure why exactly it would fail (the disc may have been blank, 
but I do not recall), but here is my observation:

1. cdrecord starts examining the disc.
2. Drive spins up.
3. During grace time before burn the drive starts to slow.
4. Burn starts.
5. cdrecord (or driver or drive) pauses a brief amount of time.  I think
   this is what happened with the DVD+R on my workstation when the drive
   increased its speed.
6. Drive spins up.
7. Burn continues until end.

For me, the solution appeared to be setting the grace time to three 
seconds to avoid the slowdown of the drive:  gracetime=3
At least, the disc worked on subsequent burns this way.  Jakub, you may 
try to see if this setting helps.


Sean
--
s...@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: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]

[Sean Bruno]

On Thu, 2010-10-21 at 12:06 -0700, Kostik Belousov wrote:
 On Thu, Oct 21, 2010 at 09:50:03AM -0700, Sean Bruno wrote:
  On Thu, 2010-10-21 at 05:48 -0700, Andriy Gapon wrote:
   on 20/10/2010 21:28 Sean Bruno said the following:
I guess, I could replace the kernel on the CD and have them reburn it?
   
   That should work.
   BTW, here I described yet another way of building custom 
   recovery/installation
   CDs that I use:
   http://wiki.freebsd.org/AvgLiveCD
   
  
  Before I get started on this, it looks like something else is going on.
  
  Here is a panic + trace on the latest 9-current snap shot.  hammer
  time indeed.  
  
  Suggestions are welcome!
  
  
  http://people.freebsd.org/~sbruno/9-current-panic.png
  
  http://people.freebsd.org/~sbruno/9-current-trace-panic.png
 
 It feels like msgbufp variable has absurd value. Can you arrange
 to get the output of verbose boot, esp. the SMAP lines ?
 Also, you could add printfs near amd64/amd64/machdep.c:1517
   /* Map the message buffer. */
   msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);
 to show the values of all participants, i.e. msgbufp, pa_indx
 and phys_avail[pa_indx].


I've been trying to anything useful after the SMAP printed out, and have
failed.  I assume that because of the place where the system is throwing
a panic.  

Here is the SMAP output, I had to capture it twice to get it all on the
screen.  

http://people.freebsd.org/~sbruno/smap1.png

http://people.freebsd.org/~sbruno/smap2.png

Immediately after, it jumps into the panic.  I assume that this means
more to you folks than it means to me.  I'm still working on the printf.

sean

___
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: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]

[Sean Bruno]

On Fri, 2010-10-22 at 02:46 -0700, Ivan Voras wrote:
 On 10/21/10 21:06, Kostik Belousov wrote:
  On Thu, Oct 21, 2010 at 09:50:03AM -0700, Sean Bruno wrote:
  On Thu, 2010-10-21 at 05:48 -0700, Andriy Gapon wrote:
  on 20/10/2010 21:28 Sean Bruno said the following:
  I guess, I could replace the kernel on the CD and have them reburn it?
 
  That should work.
  BTW, here I described yet another way of building custom 
  recovery/installation
  CDs that I use:
  http://wiki.freebsd.org/AvgLiveCD
 
 
  Before I get started on this, it looks like something else is going on.
 
  Here is a panic + trace on the latest 9-current snap shot.  hammer
  time indeed.  
 
  Suggestions are welcome!
 
 
  http://people.freebsd.org/~sbruno/9-current-panic.png
 
  http://people.freebsd.org/~sbruno/9-current-trace-panic.png
  
  It feels like msgbufp variable has absurd value. Can you arrange
  to get the output of verbose boot, esp. the SMAP lines ?
 
 This is probably completely wrong for this problem but in the tiny case
 it isn't, maybe it will give someone an idea: I remember in the old
 times (tm) that there was a trick by which the msgbuf is supposed to be
 preserved across soft reboots. I don't know the details, and it might
 just be valid for i386 but part of that deal could be that some code
 tries to parse that memory area for valid msgbuf and due to some
 garbage, fails with such a panic.

Strange you should mention this.  Peter@ and I just had a 30 minute
driveway conversation about just this issue.

Sean


___
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: kpanic on install on HP DL980/580

[Sean Bruno]

On Thu, 2010-10-21 at 12:06 -0700, Kostik Belousov wrote:
 On Thu, Oct 21, 2010 at 09:50:03AM -0700, Sean Bruno wrote:
  On Thu, 2010-10-21 at 05:48 -0700, Andriy Gapon wrote:
   on 20/10/2010 21:28 Sean Bruno said the following:
I guess, I could replace the kernel on the CD and have them reburn it?
   
   That should work.
   BTW, here I described yet another way of building custom 
   recovery/installation
   CDs that I use:
   http://wiki.freebsd.org/AvgLiveCD
   
  
  Before I get started on this, it looks like something else is going on.
  
  Here is a panic + trace on the latest 9-current snap shot.  hammer
  time indeed.  
  
  Suggestions are welcome!
  
  
  http://people.freebsd.org/~sbruno/9-current-panic.png
  
  http://people.freebsd.org/~sbruno/9-current-trace-panic.png
 
 It feels like msgbufp variable has absurd value. Can you arrange
 to get the output of verbose boot, esp. the SMAP lines ?
 Also, you could add printfs near amd64/amd64/machdep.c:1517
   /* Map the message buffer. */
   msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);
 to show the values of all participants, i.e. msgbufp, pa_indx
 and phys_avail[pa_indx].

[subject change and thread breaking]

Working on it.  The RTT on getting tests is going to be long though.

Apparently, I'll have to push ISO images for test *somewhere* that the
HP folks can download, burn to a disk and boot the machines from.

However, they have let me have access for another week and added the
DL580 G7 to the testing as well.  I'll update as I get progress and
debugging.

Sean

___
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: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]

[Sean Bruno]

On Thu, 2010-10-21 at 05:48 -0700, Andriy Gapon wrote:
 on 20/10/2010 21:28 Sean Bruno said the following:
  I guess, I could replace the kernel on the CD and have them reburn it?
 
 That should work.
 BTW, here I described yet another way of building custom 
 recovery/installation
 CDs that I use:
 http://wiki.freebsd.org/AvgLiveCD
 

Before I get started on this, it looks like something else is going on.

Here is a panic + trace on the latest 9-current snap shot.  hammer
time indeed.  

Suggestions are welcome!


http://people.freebsd.org/~sbruno/9-current-panic.png

http://people.freebsd.org/~sbruno/9-current-trace-panic.png

Sean

___
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

Spurious reboot in 8.1-RELEASE when reading from ZFS pool with 9 disks

[Sean Thomas Caron]

Hi folks,

I've been playing with ZFS in 8.1-RELEASE (amd64) on a Sun Fire X4500  
with 16 GB RAM and in general it seems to work well when used as  
recommended.


BUT...

In spite of the suggestion of Sun and FreeBSD developers to the  
contrary, I have been trying to create some zraid pools of size  
greater than 9 disks and it seems to give some trouble.


If I try to create a pool containing more than 9 [500 GB] disks,  
doesn't matter if it is zraid1 or zraid2, the system seems to reboot  
given any amount of sustained reads from the pool (haven't tested  
mirrored pools). Now, I am not sure of:


- Whether the reboot in the zraid1 case is caused by exactly the same  
issue as the reboot in the zraid2 case


- Whether this is an issue of total number of member disks, or total  
amount of disk space in the pool. All I have to work with at the  
moment is 500 GB drives.


I am not doing any sysctl tuning; just running with the defaults or  
what the system automatically sizes. I tried playing around with  
tuning some sysctl parameters including setting arc_max to be very  
small and it didn't seem to help any; pools of greater than 9 disks in  
size are always unstable.


Writes seem to work OK; I can, say, pull stuff from over the network  
and save it to the pool, or I can do something like,


dd if=/dev/random of=/mybigpool/bigfile bs=1024 size=10M

and it will write data all day pretty happily. But if I try to read  
back from the pool, for example,


dd if=/mybigpool/bigfile of=/dev/null bs=1024

or even to just do something like,

cp /mybigpool/bigfile /mybigpool/bigfile_2

the system reboots pretty much immediately. I never see anything on  
the console at all; it just reboots.


Even if I build a new kernel with debugging options:

options KDB
options DDB

the system still just reboots; I never see anything on the console and  
I never get to the debugger.


So, as I say, very easy to reproduce the problem, just create a zraid  
pool of any type with more than 9 member disks, dump some data to it,  
then try to read it back, and the machine will reboot.


If I create a pool with 9 or fewer disks, the system seems perfectly  
stable. I was never able to reproduce the reboot behavior as long as  
the pools contained 9 or fewer drives, beating on it fairly hard with  
iozone and multiple current dd operations writing large files to and  
from memory.


Just wondering if anyone's seen this problem before and as to whether  
or not it is a known bug and may have been fixed in STABLE or CURRENT?  
Should I report this as a bug? Should I just create pools of 9 or  
fewer drives? Not sure if my customer is going to want to use STABLE  
or CURRENT in production but I wanted to run this by the list just to  
see.


Best,

-Sean
___
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: Spurious reboot in 8.1-RELEASE when reading from ZFS pool with 9 disks

[Sean Thomas Caron]

Hi Lawrence,

Interesting; have you tried this for raidz2 as well?

I just created a raidz2 pool with 5 disks and then added another 5  
disk raidz2 to it, so, total of 10 disks in the pool (though this is  
ultimately a losing strategy unless the number of disks is  9  
because two drives are lost for parity in each sub-raid in the pool).


It (seemed) just slightly more stable than creating a single raidz2  
pool with  9 disks but it still crashes.


I guess this does allow me to say its more an issue of number of  
devices in the pool versus capacity of the pool because with the  
parity drives taken out, the pool with two 5-disk raidz2s has less  
total capacity than a pool with a single 9-disk raidz2.


Just out of idle curiousity, I also tried it with raidz1 on my system.  
Again, I created a 5-disk pool, raidz1 this time, then added another  
5-disk raidz1 to the pool for, again, total of 10 disks.


Again, a bit of a losing strategy versus creating one great big raidz  
unless the number of disks is  9 because of losing a disk in each  
sub-raidz1 in the pool for parity but less so of course than raidz2.


This seemed to crash too, same behavior.

Are you using 8.1-RELEASE or STABLE or ...?

Best,

-Sean



I have a 16 disk pool, if you create it with

zpool create poolname raidz disk1 disk2 disk3 etc

then

zpool add poolname raidz disk8 disk9 disk10 etc

You get the full size pool and no issues.

  pool: tank
 state: ONLINE
 scan: scrub repaired 0 in 0h0m with 0 errors on Wed Oct 20 14:54:08 2010
config:

NAMESTATE READ WRITE CKSUM
tankONLINE   0 0 0
  raidz1-0  ONLINE   0 0 0
da0 ONLINE   0 0 0
da1 ONLINE   0 0 0
da2 ONLINE   0 0 0
da3 ONLINE   0 0 0
da4 ONLINE   0 0 0
da5 ONLINE   0 0 0
da6 ONLINE   0 0 0
da7 ONLINE   0 0 0
  raidz1-1  ONLINE   0 0 0
da8 ONLINE   0 0 0
da9 ONLINE   0 0 0
da10ONLINE   0 0 0
da11ONLINE   0 0 0
da12ONLINE   0 0 0
da13ONLINE   0 0 0
da14ONLINE   0 0 0
da15ONLINE   0 0 0

errors: No known data errors



___
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: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]

[Sean Bruno]

On Tue, 2010-10-19 at 06:01 -0700, John Baldwin wrote:
 On Tuesday, October 19, 2010 1:16:07 am Andriy Gapon wrote:
  on 19/10/2010 06:11 Wilkinson, Alex said the following:
   Will it work something like http://freshmeat.net/projects/mcelog/ ?
  
  jhb has a port of this, yes.
 
 The relevant bits are at http://www.FreeBSD.org/~jhb/mcelog/
 
 I should probably make this into a port, but I really need to e-mail the 
 mcelog folks about integrating the patches into their tree.
 


Q:  Has anyone installed any version of FreeBSD on a DL980 G7 from HP
yet?  Has anyone installed any version of FreeBSD on a DL580 G7 from HP?

HP testers report that 7 nor 8 install without the kernel
'insta-panicing' across all CPUS at the same time.

I'm going to ask that they try the latest 9 snap shot and then kill the
project at this time.

sean

___
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: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]

[Sean Bruno]

On Wed, 2010-10-20 at 11:11 -0700, Andriy Gapon wrote:
 on 20/10/2010 21:05 Sean Bruno said the following:
  HP testers report that 7 nor 8 install without the kernel
  'insta-panicing' across all CPUS at the same time.
  
  I'm going to ask that they try the latest 9 snap shot and then kill the
  project at this time.
 
 So you are not willing to try the patch?
 


Huh ... did I miss it?  I'm willing to try a lot.

sean

___
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: kpanic on install 32GB of RAM [SEC=UNCLASSIFIED]

[Sean Bruno]

On Wed, 2010-10-20 at 11:20 -0700, Andriy Gapon wrote:
 on 20/10/2010 21:16 Sean Bruno said the following:
  Huh ... did I miss it?  I'm willing to try a lot.
 
 Perhaps then :-)
 This was my post:
 http://thread.gmane.org/gmane.os.freebsd.stable/72450/focus=72515
 
 It had a link to a parallel discussion on current:
 http://thread.gmane.org/gmane.os.freebsd.current/128099/focus=128576
 
 Which had a link to:
 http://people.freebsd.org/~avg/uma-many-cpus.diff
 
 Which is the patch :)

So here's the problem.

Machine in in Houston, can't netboot/nfsboot it.  The basic installers
all will get me to the Beastie loader, but fail after loading the kernel
and attempting to boot.

I guess, I could replace the kernel on the CD and have them reburn it?

Sean

___
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: Spurious reboot in 8.1-RELEASE when reading from ZFS pool with 9 disks

[Sean Thomas Caron]

Hi Jeremy,

Thanks for the very helpful response!

I added all debugging options that you specified to my kernel and  
rebuilt; then set the kernel parameters as you mention (I was being a  
bit lazy earlier when I called them sysctls; I always tuned them in  
loader.conf; just that you can view their values with sysctl).


Rebooted the system with the new kernel and set up a 11-disk zraid2  
pool again then started beating on it. At first it seemed to be a bit  
more resilient with this set of kernel parameters but eventually it  
too failed out.


Again I just got a straight up reboot, no debugger, no output to the  
console flashed by as far as I can tell.


I don't have a serial console hooked up right now but it's probably  
possible to do so through the ILOM or equivalent; I will have to look  
into that further.


This is pretty wierd.

I am thinking there might be some memory starting to go in this  
system; never seen failing memory in an ECC box cause reboots this  
consistently and only under such specific conditions but I suppose it  
isn't completely out of the question. I'll talk to my customer and see  
what they can do about the hardware; maybe they have some spares.


I will also try 8.1-STABLE when I have a chance and see if that works better.

But it's definitely helpful to know that folks have  9 disk raidz  
pools up and running on FreeBSD 8.x with no trouble - that it should  
work. And the list of tunables is very useful; nice to have something  
to work with that I can have a bit more confidence in outside of my  
own guessing :)


I will report back to the list when I have more information.

Thanks!

-Sean


Quoting Jeremy Chadwick free...@jdc.parodius.com:


There are users here using FreeBSD ZFS with *lots* of disks (I think
someone was using 32 disks at one point) reliably.  Some of them post
here regularly (with other issues that don't consist of sporadic
reboots).

The kernel options may not be sufficient.  I'm used to using these:

# Debugging options
options BREAK_TO_DEBUGGER   # Sending a serial BREAK drops to DDB
options KDB # Enable kernel debugger support
options KDB_TRACE   # Print stack trace  
automatically on panic

options DDB # Support DDB
options GDB # Support remote GDB

And in /etc/rc.conf, setting:

ddb_enable=yes

Next: arc_max isn't technically a sysctl, meaning it can't be changed
in real-time, so I'm not sure how you managed to do that.  Validation:

sysctl: oid 'vfs.zfs.arc_max' is a read only tunable
sysctl: Tunable values are set in /boot/loader.conf

Your system may be reporting something relating to kmem exhaustion but
is then auto-rebooting so fast that you can't see the message on VGA
console.  Do you have serial console?

Please try setting the following tunables in /boot/loader.conf and
reboot the machine, then see if the same problem persists.

vm.kmem_size=16384M
vfs.zfs.arc_max=14336M
vfs.zfs.prefetch_disable=1
vfs.zfs.zio.use_uma=0
vfs.zfs.txg.timeout=5

I would also advocate you try 8.1-STABLE as there have been many changes
in ZFS since then (and I'm not just referring to the v15 import),
including how the ARC gets sized/adjusted.  CURRENT is highly
bleeding-edge, so I would start or stick with STABLE.

Finally, there's always the possibility that the PSU has some sort of
load problem with that many disks all being accessed at the same time.
I imagine the power draw of that system is quite high.  I can't imagine
Sun shipping a box with a insufficient PSU, but then again power draw
changes depending on the RPM of the disks used and many other things.

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

___
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: No disks found on FreeBSD 8.1-STABLE on Sun X4500

[Sean Caron]

Hi Florian,

I gave that a try and it worked perfectly; the system comes right up and 
sees all my Marvell controllers and disks. I remember reading about the 
Highpoint driver issue of grabbing onto some non-Highpoint Marvell based 
controllers but for some reason thought it was fixed in the STABLE images 
that I was using (guess not!). Now off to play with ZFS...


Thanks so much!

-Sean

On Tue, 12 Oct 2010, Florian Smeets wrote:



On 8.1 try

set hw.hptrr.attach_generic=0
load mvs
boot

After I set hw.hptrr.attach_generic to 0 mvs found all my disk. Without
it I had the same problem you describe.

HTH,
Florian


___
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

Which disk devices boot on Sun Fire X4500?

[Sean Caron]

Hi folks,

Another quick question regarding FreeBSD on the X4500...

Does anyone know off the top of their head the device nodes that correspond
to the two bootable disks on the Sun Fire X4500 (slot 0 and slot 1) aka SATA
06C0 S00 and SATA 06C4 S01 in the BIOS? I'm thinking in the analogous sense
to /dev/sdy and /dev/sdac in Linux per Sun's documentation [1].

I did the facile thing and installed to /dev/ada0 and /dev/ada1 (mirrored 
ZFS) and they do not seem to be the ones that the system is trying to boot 
from.


Thanks,

-Sean

[1] http://docs.sun.com/source/820-0642-10/index.html
___
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: kpanic on install 32GB of RAM

[Sean Bruno]

On Mon, 2010-10-18 at 14:29 -0700, Andriy Gapon wrote:
 on 16/10/2010 02:41 Andriy Gapon said the following:
  on 15/10/2010 19:04 Sean Bruno said the following:
  So, trying to get a massively overpowered HP box up with 7.3 amd64
  version up and running.
 
  I can't tell at the moment, but it looks like the installer kernel is
  having issues with 32GB of RAM in this box.
 
  Are we using the i386 kernel on amd64 installs?
 
 So, just in case:
 
  Is there anything else peculiar about this system besides RAM?
 

Looking over the DL980, it's 64 core w/HT, 10G ethernet and apparently
is throwing Machine Check Exceptions very hard.

http://people.freebsd.org/~sbruno/dl980_Machcheck_exceptions.png

Sean

___
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: kpanic on install 32GB of RAM

[Sean Bruno]

 We've successfully installed RHEL 5u4 on it, I'll fire that up and post
 the boot output shortly.
 
 Sean


Perhaps this is something as simple as a hardware failure?  HP DL980
looks sick, but I'm not sure.  Here's the hardware logs, from the iLO on
the box as screen scraping on the console is pointless as it's garbled
too badly.

Bad CPU, Bad Ram or other?

http://people.freebsd.org/~sbruno/dl980_Machcheck_exceptions.png

Sean

___
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: kpanic on install 32GB of RAM

[Sean Bruno]

On Fri, 2010-10-15 at 09:38 -0700, Sean Bruno wrote:
 On Fri, 2010-10-15 at 09:30 -0700, Boris Kochergin wrote:
  On 10/15/10 12:27, Jeremy Chadwick wrote:
   On Fri, Oct 15, 2010 at 09:04:53AM -0700, Sean Bruno wrote:
   So, trying to get a massively overpowered HP box up with 7.3 amd64
   version up and running.
  
   I can't tell at the moment, but it looks like the installer kernel is
   having issues with32GB of RAM in this box.
  
   Are we using the i386 kernel on amd64 installs?
   If you booted a FreeBSD image that has amd64 in the ISO name, then the
   kernel is actually 64-bit (amd64).  The only i386 piece would be the
   bootloader.
  
   There's probably someone here who can help with the issue you describe,
   as there's occasional posts here and there from people who experience
   issues/problems when using very large amounts of RAM.
  
  I've got an amd64 machine with 48 GB of RAM that has run 7, 8, and now 
  9, which leads me to believe that your issue is not solely related to 
  the amount of memory.
  
  -Boris
  __
 
 Edge case at 64G perhaps?  That's the minimum you can get in the HP
 DL980 apparently.
 
 Sean

Hrm, no success today setting available RAM to 32G and reducing the
number of processors to 8.

I've disabled and tweaked pretty much everything available to me here
and have tried to boot up the fbsd 8 install media with the same result
as using the fbsd 7 media:  Repeated and continuous panics on all
processors simultaneously after selecting install method from the boot
menu.

Not sure what to do at this point to get the system up and running.
Suggestions?

Sean

___
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