Panic at shutdown

[Ranjan1018 .]

Hi,

sometimes I have the panic in the photo at shutdown:

http://imgur.com/mXrgFLp

Unfortunately this happens randomly.

I am running:

$ uname -a

FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r291160M: Sun Nov 22
17:10:38 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC  amd64

Regards,

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

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

On 11/27/2015 7:44 PM, Matthew Grooms wrote:
I spent the day looking over the FreeBSD cam and scsi_da source code. 
After sprinkling a bunch of printf's around to see what code paths 
were being called, It's obvious that Edward was correct in assuming 
that ESXi doesn't return any 'Unit Attention' sense information in 
response to a 'Read Capacity' request. This kinda makes sense as ESXi 
emulates SCSI-2 disk devices and, as far as I can tell, the 0x2A/0x09 
ASC/ASCQ sense code that denotes 'Capacity Data Has Changed' wasn't 
defined until the SCSCI-3 spec. It's frustrating that the only way to 
get the scsci_da code to call reprobe() is by receiving a command from 
the device. Would something like this work? ...


1) Register a callback using xpt_register_async( daasync, 
AC_REPROBE_DEVICE, path ) that calls reprobe()
2) Implement a new IOCTL in cam_xpt that camcontrol can call with the 
bus:target:lun as the argument
3) have cam_xpt capture the IOCTL request and call xpt_async( 
AC_REPROBE_DEVICE, path ) as a result


This way users would have the option of manually asking cam to 
communicate the new size to geom. The only option now is one or more 
reboots to gain access to the increased disk capacity. If this sounds 
like a reasonable approach, I'll take a stab at implementing it.




Here is a proof of concept patch. I'm a complete noob when it comes to 
cam, scsi or freebsd kernel development for that matter, so I'm sure it 
could have been done a better way. In any case, I added a new command to 
camcontrol that allows you to specify a bus, target and lun as an 
argument. For example ...


# camcontrol readcap da1 -h
Device Size: 32 G, Block Length: 512 bytes

# gpart show da1
=>  40  58720176  da1  GPT  (28G)
40  587201761  freebsd-ufs  (28G)

Note, I resized the VMDK disk in ESXi. The camcontrol output shows the 
size as 32G but geom thinks its 28G.


# camcontrol devlist
   at scbus1 target 0 lun 0 (cd0,pass0)
  at scbus2 target 0 lun 0 (pass1,da0)
  at scbus2 target 1 lun 0 (pass2,da1)
 at scbus3 target 0 lun 0 (da2,pass3)

# camcontrol reprobe 2:1:0

This generates an event that is captured by the scsci da device to 
forces a reprobe. The kernel output looks almost identical to when the 
'Unit Attention' sense data is received ...


Nov 28 17:46:13 iscsi-i kernel: (da1:mpt0:0:1:0): Re-probe requested
Nov 28 17:46:13 iscsi-i kernel: GEOM_PART: da1 was automatically resized.
Nov 28 17:46:13 iscsi-i kernel: Use `gpart commit da1` to save changes 
or `gpart undo da1` to revert them.


Now that geom knows about the increased disk capacity, I can increase 
the partition size and grow the fs ...


[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  67108784  da1  GPT  (32G)
40  587201761  freebsd-ufs  (28G)
  58720216   8388608   - free -  (4.0G)

# gpart resize -i 1 da1
da1p1 resized

# growfs da1p1
Device is mounted read-write; resizing will result in temporary write 
suspension for /var/data1.

It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/da1p1, mounted on /var/data1, from 28GB to 
32GB? [Yes/No] Yes

super-block backups (for fsck_ffs -b #) at:
 58983232, 60265472, 61547712, 62829952, 64112192, 65394432, 66676672

# df -h
FilesystemSizeUsed   Avail Capacity  Mounted on
/dev/da0p3 18G5.3G 12G31%/
devfs 1.0K1.0K  0B   100%/dev
/dev/da1p1 31G 32M 28G 0%/var/data1
/dev/da2p1 15G 32M 14G 0%/var/data2

Sure would be nice to have something like this in the tree. It's really 
a drag to have to reboot production VMs to increase disk capacity when 
it could be easily avoided. I'm not sure what the correct IOCTL should 
look like. Maybe CAMIOCOMMAND is a better way to go? If someone with 
some experience with the cam/scsi subsystems was willing to give me some 
direction I'd be willing to try and rewrite the patch in a way that 
would be commit worthy. I just need some direction.


Thanks,

-Matthew
Index: lib/libcam/camlib.c
===
--- lib/libcam/camlib.c (revision 291390)
+++ lib/libcam/camlib.c (working copy)
@@ -752,3 +752,41 @@
bcopy(src, dst, sizeof(struct cam_device));
 
 }
+
+/*
+ * Send a reprobe unit request for a given bus, target and lun
+ */
+int
+cam_reprobe_btl(path_id_t path_id, target_id_t target_id, lun_id_t target_lun)
+{
+   int fd;
+   char *func_name = "cam_reprobe_btl";
+   union ccb ccb;
+
+   if ((fd = open(XPT_DEVICE, O_RDWR)) < 0) {
+   snprintf(cam_errbuf, CAM_ERRBUF_SIZE,
+"%s: couldn't open %s\n%s: %s", func_name, XPT_DEVICE,
+func_name, strerror(errno));
+   return(-1);
+   }
+
+   /* Setup our request ccb */
+   bzero(_h, sizeof(struct ccb_hdr));
+   ccb.ccb_h.path_id = path_id;
+   

Re: Panic at shutdown

[Garrett Cooper]

> On Nov 28, 2015, at 12:32, Ranjan1018 . <21474...@gmail.com> wrote:
> 
> Hi,
> 
> sometimes I have the panic in the photo at shutdown:
> 
> http://imgur.com/mXrgFLp
> 
> Unfortunately this happens randomly.
> 
> I am running:
> 
> $ uname -a
> 
> FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r291160M: Sun Nov 22
> 17:10:38 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC  amd64

The panic is in the ZFS code.

Have you run memtest on the machine recently?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: EFI and i915kms questions

[Joe Maloney]

Thank you.  For what it’s worth I was able to grab a dump after setting that 
sysctl.  It looks like this maybe the culprit?

panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ 
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:362

Since it is to large for posting here.  I will include a link to the entire 
dump on pastebin if anyone is interesting in looking at it.

http://pastebin.com/mzS5svy8

In addition I did a little further testing to narrow down the issue.

10.1-RELEASE WORKS
10.2-RELEASE WORKS

I recall trying a 10.2-STABLE image that crashed as well.  I can tell you for 
sure that the following releases all the way back to August have the issue for 
CURRENT.

FreeBSD-11.0-CURRENT-amd64-20150804-r286285-memstick.img
FreeBSD-11.0-CURRENT-amd64-20150917-r287930-memstick.img
FreeBSD-11.0-CURRENT-amd64-20151001-r288459-memstick.img
FreeBSD-11.0-CURRENT-amd64-20151119-r291085-memstick.img

If there is an archive of older images for CURRENT I would be happy to try 
those to help further narrow down where things broke.

Joe Maloney


> On Nov 21, 2015, at 5:53 AM, Jean-Sébastien Pédron 
>  wrote:
> 
> On 13/11/2015 18:15, Joe Maloney wrote:
>> Hello,
> 
> Hi!
> 
>> Sometime after changes in FreeBSD 10-STABLE, 10.2 onwards, and 
>> recent 11 CURRENT the resolution no longer sets properly when using
>> UEFI boot. It now boots with a 640x480 resolution, and kldload
>> i915kms results in a black screen. I have not been able to grab a
>> debug log, or crash dump even with all of the debugging features
>> turned on. I cannot ssh into the laptop when this panic occurs, and
>> the screen is black so I can’t really see what happened. I’m curious
>> if there is anything else I can do besides enabling dumpdev or
>> kldload -v i915kms > output.txt that doesn’t give me any detail.
>> Nothing shows up in /var/crash or whatever the directory was.
> 
> You could try to set debug.debugger_on_panic=0 in /etc/sysctl.conf. It
> often helps to at least get core dumps when the crash happens in a video
> driver.
> 
> -- 
> Jean-Sébastien Pédron
> 

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

librt symbol versioning breakage (was Re: Build failure, undefined reference to __mq_oshandle)

[Daniel Eischen]

On Fri, 27 Nov 2015, Daniel Eischen wrote:


Damn, please use deisc...@freebsd.org for replies.

On Fri, 27 Nov 2015, Daniel Eischen wrote:


On Fri, 27 Nov 2015, Daniel Eischen wrote:


$ uname -a
FreeBSD vega 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r277320: Mon Jan 19 
09:02:50 EST 2015 
deischen@vega:/usr/FreeBSD/svn/obj/usr/FreeBSD/svn/src/sys/vega  amd64


Upgrading to today's current, 'rm -rf /usr/obj/*; make -j8 buildworld'
fails here:

===> lib/libc/tests/gen/execve (buildconfig)
--- all_subdir_tests ---
--- all_subdir_mqueue ---
mqtest3.o: In function `main':
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x139): undefined 
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x14c): undefined 
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x16c): undefined 
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3e6): undefined 
reference to `__mq_oshandle'
/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x3f9): undefined 
reference to `__mq_oshandle'
mqtest3.o:/usr/FreeBSD/svn/src/tests/sys/mqueue/mqtest3.c:(.text+0x40f): 
more undefined references to `__mq_oshandle' follow
cc: error: linker command failed with exit code 1 (use -v to see 
invocation)


Going to try make [-j1], next, but anyone come across this?


Still fails.

Why do the tests in tests/sys/mqueue/ try to use non-public APIs?


So I found out that sometime in the last year or so, symbol versioning
for librt was broken and leaking symbols that shouldn't have been
leaked.  I've just committed a fix for this.

Do a 'readelf -sw /usr/lib/librt.so.1 | grep GLOBAL | grep -v UND'
and see the non FBSD_foo symbols that shouldn't be there.

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

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

On 11/28/2015 6:10 PM, Matthew Grooms wrote:

On 11/27/2015 7:44 PM, Matthew Grooms wrote:
I spent the day looking over the FreeBSD cam and scsi_da source code. 
After sprinkling a bunch of printf's around to see what code paths 
were being called, It's obvious that Edward was correct in assuming 
that ESXi doesn't return any 'Unit Attention' sense information in 
response to a 'Read Capacity' request. This kinda makes sense as ESXi 
emulates SCSI-2 disk devices and, as far as I can tell, the 0x2A/0x09 
ASC/ASCQ sense code that denotes 'Capacity Data Has Changed' wasn't 
defined until the SCSCI-3 spec. It's frustrating that the only way to 
get the scsci_da code to call reprobe() is by receiving a command 
from the device. Would something like this work? ...


1) Register a callback using xpt_register_async( daasync, 
AC_REPROBE_DEVICE, path ) that calls reprobe()
2) Implement a new IOCTL in cam_xpt that camcontrol can call with the 
bus:target:lun as the argument
3) have cam_xpt capture the IOCTL request and call xpt_async( 
AC_REPROBE_DEVICE, path ) as a result


This way users would have the option of manually asking cam to 
communicate the new size to geom. The only option now is one or more 
reboots to gain access to the increased disk capacity. If this sounds 
like a reasonable approach, I'll take a stab at implementing it.




Here is a proof of concept patch. I'm a complete noob when it comes to 
cam, scsi or freebsd kernel development for that matter, so I'm sure 
it could have been done a better way. In any case, I added a new 
command to camcontrol that allows you to specify a bus, target and lun 
as an argument. For example ...


# camcontrol readcap da1 -h
Device Size: 32 G, Block Length: 512 bytes

# gpart show da1
=>  40  58720176  da1  GPT  (28G)
40  587201761  freebsd-ufs  (28G)

Note, I resized the VMDK disk in ESXi. The camcontrol output shows the 
size as 32G but geom thinks its 28G.


# camcontrol devlist
   at scbus1 target 0 lun 0 (cd0,pass0)
  at scbus2 target 0 lun 0 (pass1,da0)
  at scbus2 target 1 lun 0 (pass2,da1)
 at scbus3 target 0 lun 0 (da2,pass3)

# camcontrol reprobe 2:1:0

This generates an event that is captured by the scsci da device to 
forces a reprobe. The kernel output looks almost identical to when the 
'Unit Attention' sense data is received ...


Nov 28 17:46:13 iscsi-i kernel: (da1:mpt0:0:1:0): Re-probe requested
Nov 28 17:46:13 iscsi-i kernel: GEOM_PART: da1 was automatically resized.
Nov 28 17:46:13 iscsi-i kernel: Use `gpart commit da1` to save changes 
or `gpart undo da1` to revert them.


Now that geom knows about the increased disk capacity, I can increase 
the partition size and grow the fs ...


[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  67108784  da1  GPT  (32G)
40  587201761  freebsd-ufs  (28G)
  58720216   8388608   - free -  (4.0G)

# gpart resize -i 1 da1
da1p1 resized

# growfs da1p1
Device is mounted read-write; resizing will result in temporary write 
suspension for /var/data1.
It's strongly recommended to make a backup before growing the file 
system.
OK to grow filesystem on /dev/da1p1, mounted on /var/data1, from 28GB 
to 32GB? [Yes/No] Yes

super-block backups (for fsck_ffs -b #) at:
 58983232, 60265472, 61547712, 62829952, 64112192, 65394432, 66676672

# df -h
FilesystemSizeUsed   Avail Capacity  Mounted on
/dev/da0p3 18G5.3G 12G31%/
devfs 1.0K1.0K  0B   100%/dev
/dev/da1p1 31G 32M 28G 0%/var/data1
/dev/da2p1 15G 32M 14G 0%/var/data2

Sure would be nice to have something like this in the tree. It's 
really a drag to have to reboot production VMs to increase disk 
capacity when it could be easily avoided. I'm not sure what the 
correct IOCTL should look like. Maybe CAMIOCOMMAND is a better way to 
go? If someone with some experience with the cam/scsi subsystems was 
willing to give me some direction I'd be willing to try and rewrite 
the patch in a way that would be commit worthy. I just need some 
direction.




Ok, last post until I get some feedback. Here's a new version of the 
patch complete with man page updates. It communicates via CAMIOCOMMAND 
instead of introducing a new ioctl value. I tried to model it after the 
device reset option, hopefully with some degree of success. Functionally 
it should be the same as the first patch.


Thanks,

-Matthew
Index: sbin/camcontrol/camcontrol.8
===
--- sbin/camcontrol/camcontrol.8(revision 291390)
+++ sbin/camcontrol/camcontrol.8(working copy)
@@ -104,6 +104,9 @@
 .Ic reset
 .Aq all | bus Ns Op :target:lun
 .Nm
+.Ic reprobe
+.Aq bus:target:lun
+.Nm
 .Ic defects
 .Op device id
 .Op generic args
@@ -548,6 +551,9 @@
 connecting to that device.
 Note that this can have a destructive impact
 on the system.
+.It Ic reprobe
+Tell the kernel to re-probe the given 

FreeBSD_HEAD - Build #3583 - Failure

[jenkins-admin]

FreeBSD_HEAD - Build #3583 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3583/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3583/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/3583/console

Change summaries:

291440 by deischen:
Disable a couple of tests, perhaps temporarily, since they use private
symbols that are not exported from librt.

291439 by deischen:
Unbreak symbol versioning.  I have no idea when it was broken, but it's been
at least a few months if not a year or more.

291438 by adrian:
Add support for the integrated wifi for the QCA953x base config and
AP143.

Tested:

* AP143 reference design board

291437 by adrian:
Add initial support for the QCA953x SoC (honeybee) wifi.

This is a 2x2 2GHz 802.11n part.  It works enough at the moment to
bring up, scan and associate.  I haven't started using this as
a day to day AP.

The specifics:

* add honeybee initvals
* add in changes; a mix from the QCA HAL and ath9k;
* fix a bug in AR_SREV_AR9580_10_OR_LATER(), which is only used
  for one capability check and we don't even implement it - so it's
  a big no-op.

Shady things:

* ath9k has the "platform data" define the 25/40MHz clock.
  This HAL .. doesn't.  Honeybee gets hard-coded to 25MHz which
  it likely shouldn't be.  I'll have to go and identify/fix those.

Tested:

* Qualcomm Atheros AP143 reference design board.

Obtained from:  Qualcomm Atheros; Linux ath9k

291436 by arybchik:
sfxge: add prefast annotation to common code return types

Using a typedef for common code return types (rather than "int")
allows the Prefast static analyser to understand when a function
has been successful (and thus when its postconditions must hold).

This greatly reduces then number of false positives reported by
prefast for error paths in common code functions.

Submitted by:   Andy Moreton 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  2 days

291435 by adrian:
u32 -> uint32_t.

291434 by arybchik:
sfxge: cleanup: fix prefast annotations on mac stats updates

Submitted by:   Andy Moreton 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  2 days
X-MFC with: r291397

291433 by adrian:
[ath_hal] add AR9461 (jupiter) 2.1 support.

Obtained from:  Linux ath9k

291432 by arybchik:
sfxge: modify nvram update functions for uio platform to support 
RFID-selectable presets

Dynamic config partitions on boards that support RFID are divided into
a number of segments, each formatted like a partition, with header,
trailer and end tags. The first segment is the current active
configuration.

The segments are initialised by manftest and each contain a different
configuration e.g. firmware variant. The firmware can be instructed
via RFID to copy a segment over the first segment, hence changing the
active configuration. This allows ops to change the configuration of
a board prior to shipment using RFID.

Changes to the dynamic config may need to be written to all segments (in
particular firmware versions written by manftest) or just the first
segment (changes to the active configuration). See SF-111324-SW.
If only the first segment is written the code still needs to be aware of
the possible presence of subsequent segments as writing to a segment may
cause its size to increase, which would overwrite the subsequent
segments and invalidate them.

Boards that do not support RFID will only have one segment in their
dynamic config partition.

Submitted by:   Paul Fox 
Sponsored by:   Solarflare Communications, Inc.
MFC after:  2 days
Differential Revision: https://reviews.freebsd.org/D4302



The end of the build log:

[...truncated 275627 lines...]
--- modules-all ---
--- all_subdir_cmx ---
===> cmx (all)
--- cmx.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   
-DHAVE_KERNEL_OPTION_HEADERS -include 
/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/sys/GENERIC/opt_global.h -I. 
-I/builds/FreeBSD_HEAD/sys -fno-common -g -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer 
-I/builds/FreeBSD_HEAD/obj/builds/FreeBSD_HEAD/sys/GENERIC  -MD -MP 
-MF.depend.cmx.o -MTcmx.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  -mno-aes -mno-avx  
-std=iso9899:1999 -c /builds/
 FreeBSD_HEAD/sys/modules/cmx/../../dev/cmx/cmx.c -o cmx.o
--- all_subdir_cloudabi64 ---
ctfconvert -L VERSION -g cloudabi64_fd.o
--- cloudabi64_module.o ---
cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL