r351680 kernel panic in login

2019-09-20 Thread KIRIYAMA Kazuhiko 
Hi,

I've installed r351680 in my note PC. But kernel panic at
login:

Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex axe0 (axe0) r = (0xf80003989ea0) locked 0 
/usr/src/sys/dev/usb/usb_transfer.c:2266
stack backtrace:
#0 0x80c3dac3 at winess_debugger+0x73
#1 0x80c3eae2 at winess_warn+0x442
#2 0x81191943 at trap_pfault+0x53
#3 0x81198f42 at trap+0x2b2
#4 0x8116886c at caltrap+0x8
#5 0x82f0dd82 at axe_bulk_read_callback+0x142
#6 0x80a1e52a at usbd_callback_wrapoer+0x7aa
#7 0x80a1c273 at usb_command_wrapper+0xb3
#8 0x80a1b0ae at usb_callback_proc+0x8e
#9 0x80a15dd5 at usb_process+0xe5
#10 0x80b8f794 at fork_exit+0x84
#11 0x811698ae at gork_trampoline+0xe


Fatal trap12: page fault while in kernel mode
cpuid = 3; apic id = 86
fault virtual address  = 0x0
fault code = supervisor write data,page not present
instruction pointer= 0x20:0x82f0df41
stack pointer  = 0x28:0xfe513a40
frame pointer  = 0x28:0xfe513a80
code segment   = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process= 15 (usbus0)
trap number= 12
panic: page fault
cpuid = 3
time = 1568969574
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe513700
vpanic() at vpanic+0x19d/frame 0xfe513750
panic() at panic+0x43/frame 0xfe5137b0
trap_fatal() at trap_fatal+0x39c/frame 0xfe513810
trap_pfault() at trap_pfault+0x62/frame 0xfe513860
trap() at trap+0x2b2/frame 0xfe513970
calltrap() at calltrap+0x8/frame 0xfe513970
--- trap 0xc, rip = 0x82f0d41, rsp = 0xfe513a40, rbp = 
0xfe513a80 ---
axe_rxeof() at axa_rxeof+0x151/frame 0xfe513a80
axe_bulk_read_callback() at axe_bulk_read_callback+0x142/frame 
0xfe513af0
usbd_callback_wrapper() at usbd_callback_wrapper+0x7aa/fram 0xfe513b30
usb_command_wrapper() at usb_command_wrapper+0xb3/frame 0xfe513b50
usb_callback_proc() at usb_callback_proc+0x8e/frame 0xfe513b70
usb_process() at usb_process+0xe5/frame 0xfe513bb0
fork_exit() at fork_exit+0x84/frame 0xfe513bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe513bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KBD: enter: panic
[ thread pid 15 tid 100047 ]
Stopped at  kbd_enter+0x3b: movq   $0,kbd_why
db>

I've rebooted and at single user mode I saved sevral specs
in usb as follows:

# umane -a
FreeBSD  13.0-CURRENT FreeBSD 13.0-CURRENT #0 r351680: Fri Sep 13 13:37:15 JST 
2019 admin@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
# dmesg
---<>---
Copyright (c) 1992-2019 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 13.0-CURRENT #0 r351680: Fri Sep 13 13:37:15 JST 2019
admin@tbedfc:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 
8.0.1)
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 800x600
CPU: Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz (1439.99-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x406c4  Family=0x6  Model=0x4c  Stepping=4
  
Features=0xbfebfbff
  
Features2=0x43d8e3bf
  AMD Features=0x28100800
  AMD Features2=0x101
  Structured Extended Features=0x2282
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 4294967296 (4096 MB)
avail memory = 3974008832 (3789 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0  irqs 0-114
Launching APs: 2 3 1
Timecounter "TSC" frequency 1439990442 Hz quality 1000
random: entropy device external interface
[ath_hal] loaded
kbd1 at kbdmux0
000.46 [4335] netmap_init   netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x811b9cc0, 0) error 19
nexus0
efirtc0: 
efirtc0: registered as a time-of-day clock, resolution 1.00s
cryptosoft0: 
acpi0: 
acpi0: Power Button (fixed)
unknown: I/O range not supported
cpu0:  on acpi0
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x77 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "RTC" frequency 32768 Hz

Re: Lockdown adaX numbers to allow booting ?

2019-09-20 Thread Slawa Olhovchenkov 
On Fri, Sep 20, 2019 at 01:06:29PM -0400, Garrett Wollman wrote:

> In article <20190920155304.gn3...@zxy.spb.ru>, s...@zxy.spb.ru writes:
> 
> >Location of device in multi-chassis storage system is different story.
> >I am don't know how to field engineer insert disks in chassis.
> >For me simple is find in /var/run/dmesg.boot S/N <=> daXY mapping and
> >turn ON led by sas2ircu.
> 
> sesutil does this for you!
> 
> # sesutil locate daXY on
> # sesutil locate daXY off
> 
> So long as your enclosure supports SES (all the modern ones I've seen
> do) and is enumerable by ses(4).

In theory there is no difference between theory and practice. But, in
practice, there is.

# sesutil map
ses0:
Enclosure Name: AHCI SGPIO Enclosure 
Enclosure ID:0
Element 0, Type: Array Device Slot
Status: Unsupported (0x00 0x00 0x00 0x00)
Element 1, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 000
Element 2, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 001
Element 3, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 002
Element 4, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 003
ses1:
Enclosure Name: AHCI SGPIO Enclosure 
Enclosure ID:0
Element 0, Type: Array Device Slot
Status: Unsupported (0x00 0x00 0x00 0x00)
Element 1, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 000
Element 2, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 001
Element 3, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 002
Element 4, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 003
Element 5, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 004
Element 6, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 005

# sesutil locate ada0 on
sesutil: Count not find the SES id of device 'ada0'
# sesutil locate da0 on
sesutil: Count not find the SES id of device 'da0'
# sas2ircu 0 DISPLAY
LSI Corporation SAS2 IR Configuration Utility.
Version 20.00.00.00 (2014.09.18) 
Copyright (c) 2008-2014 LSI Corporation. All rights reserved. 

Read configuration has been initiated for controller 0

Controller information

  Controller type : SAS2308_1
  BIOS version: 7.39.02.00
  Firmware version: 20.00.07.00
  Channel description : 1 Serial Attached SCSI
  Initiator ID: 0
  Maximum physical devices: 255
  Concurrent commands supported   : 8192
  Slot: 1
  Segment : 0
  Bus : 1
  Device  : 0
  Function: 0
  RAID Support: No

IR Volume information


Physical device information

Initiator at ID #0

Device is a Hard disk
  Enclosure # : 1
  Slot #  : 0
  SAS Address : 4433221-1-0300-
  State   : Ready (RDY)
  Size (in MB)/(in sectors)   : 7630885/15628053167
  Manufacturer: ATA 
  Model Number: TOSHIBA HDWN180 
  Firmware Revision   : GX2M
  Serial No   : 79HSK0PHFAVG
  GUID: N/A
  Protocol: SATA
  Drive Type  : SATA_HDD

Device is a Hard disk
  Enclosure # : 1
  Slot #  : 1
  SAS Address : 4433221-1-0200-
  State   : Ready (RDY)
  Size (in MB)/(in sectors)   : 7630885/15628053167
  Manufacturer: ATA

Re: Lockdown adaX numbers to allow booting ?

2019-09-20 Thread Slawa Olhovchenkov 
On Fri, Sep 20, 2019 at 08:29:08AM -0700, Freddie Cash wrote:

> On Fri, Sep 20, 2019 at 7:35 AM Slawa Olhovchenkov  wrote:
> 
> > On Thu, Sep 19, 2019 at 06:04:54PM +0200, Michael Gmelin wrote:
> > > What about gpart output of the pool drives?
> > >
> > > In general you would create zpools using gptids or gpt labels, not the
> > devices, so you’re independent of device numbering. The boot loader should
> > only be installed on drives that contain the boot pool (maybe you have old
> > boot loaders on data drives?).
> >
> > ZFS work w/ ZFS labels, not w/ device names/gptids/gpt labels.
> > You don't worry about changed device names aroud reboots.
> >
> 
> Very true, from ZFS' point of view.  It writes a ZFS label to whichever
> GEOM provider you hand it (file, iSCSI device, raw device, MBR partition,
> GPT partition, etc), and it will find it's pool members based on those
> labels.  ZFS doesn't care where the device is physically connected in the
> system, just that it is connected.
> 
> But the ZFS labels aren't what it will display in "zpool list -v" or "zpool
> status" output.  That will show the GEOM provider you gave it (and,
> depending on the order that GEOM tastes the devices, and what's
> enabled/disabled in loader.conf, that output can change).  That's where
> it's useful to have human-readable, descriptive labels (like GPT partition
> labels), and to disable all the GEOM ID systems you won't be using via
> loader.conf.  So that when things go sideways, and a disk dies, you can
> find it quickly and easily.  Much easier to replace "gpt/jbod3-a6" in a
> multi-chassis storage system with 100+ drives than to figure out which bay
> corresponds to "ada73" after a couple of reboots that may or may not have
> changed the PCI bus enumeration direction, or after replacing an HBA that

Location of device in multi-chassis storage system is different story.
I am don't know how to field engineer insert disks in chassis.
For me simple is find in /var/run/dmesg.boot S/N <=> daXY mapping and
turn ON led by sas2ircu.

> enumerates drives a different way (da vs ada), or after a BIOS/EFI upgrade
> that renumbers things, or any other number of situations.  (We've run into
> most of these, and have come to rely on GPT partition labels for just this
> reason; and we stick the drive serial number on the outside of the bay,
> just in case).

> It's not a ZFS requirement.  It just makes things easier for the admin down
> the road. Especially if the admin team changes or inherits systems.  :)

This is need many manual work at setup and build time.
DC field engineer make servers for me and don't do this work for me.
___
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: Lockdown adaX numbers to allow booting ?

2019-09-20 Thread Freddie Cash 
On Fri, Sep 20, 2019 at 7:35 AM Slawa Olhovchenkov  wrote:

> On Thu, Sep 19, 2019 at 06:04:54PM +0200, Michael Gmelin wrote:
> > What about gpart output of the pool drives?
> >
> > In general you would create zpools using gptids or gpt labels, not the
> devices, so you’re independent of device numbering. The boot loader should
> only be installed on drives that contain the boot pool (maybe you have old
> boot loaders on data drives?).
>
> ZFS work w/ ZFS labels, not w/ device names/gptids/gpt labels.
> You don't worry about changed device names aroud reboots.
>

Very true, from ZFS' point of view.  It writes a ZFS label to whichever
GEOM provider you hand it (file, iSCSI device, raw device, MBR partition,
GPT partition, etc), and it will find it's pool members based on those
labels.  ZFS doesn't care where the device is physically connected in the
system, just that it is connected.

But the ZFS labels aren't what it will display in "zpool list -v" or "zpool
status" output.  That will show the GEOM provider you gave it (and,
depending on the order that GEOM tastes the devices, and what's
enabled/disabled in loader.conf, that output can change).  That's where
it's useful to have human-readable, descriptive labels (like GPT partition
labels), and to disable all the GEOM ID systems you won't be using via
loader.conf.  So that when things go sideways, and a disk dies, you can
find it quickly and easily.  Much easier to replace "gpt/jbod3-a6" in a
multi-chassis storage system with 100+ drives than to figure out which bay
corresponds to "ada73" after a couple of reboots that may or may not have
changed the PCI bus enumeration direction, or after replacing an HBA that
enumerates drives a different way (da vs ada), or after a BIOS/EFI upgrade
that renumbers things, or any other number of situations.  (We've run into
most of these, and have come to rely on GPT partition labels for just this
reason; and we stick the drive serial number on the outside of the bay,
just in case).

It's not a ZFS requirement.  It just makes things easier for the admin down
the road. Especially if the admin team changes or inherits systems.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Lockdown adaX numbers to allow booting ?

2019-09-20 Thread Mark Martinec 

Kurt Jaeger writes:


The problem is that if all 10 disks are connected, the system
looses track from where it should boot and fails to boot (serial boot 
log):


Consoles: internal video/keyboard  serial port
BTX loader 1.00  BTX version is 1.02
Consoles: internal video/keyboard  serial port
BIOS drive C: is disk0
BIOS drive D: is disk1
BIOS drive E: is disk2
BIOS drive F: is disk3
BIOS drive G: is disk4
BIOS drive H: is disk5
BIOS drive I: is disk6
BIOS drive J: is disk7
BIOS drive K: is disk8
BIOS drive L: is disk9
//
[...]
The solution right now is this to unplug all disks of the 'bck' pool,
reboot, and re-insert the data disks after the boot is finished.
[...]
No gpart on the bck pool, raw drives.



This sounds very much like my experience:

  2018-11-29, Boot loader stuck after first stage upgrading 11.2 to 
12.0-RC2

https://lists.freebsd.org/pipermail/freebsd-stable/2018-November/090129.html

https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090159.html


I now have three SuperMicro machines which are unable to boot after
upgrading 11.2 to 12.0. After unsuccessfully fiddling with boot loaders,
I have reverted two back to 11.2 (which boots and works fine again),
and the third one is now at 12.0 but needs the boot hack as described
by Kurt, i.e. pull out half the disks (of the 'data' pool), boot the
system, plug the disks back in and zfs mount the remaining pool.

Considering that the 11.2 boots and works fine on these machines,
I consider it a btx loader failure and not a BIOS issue.

What is common with these three machines is that they have one pool
on raw devices for historical reasons (not on gpt partitions).
My guess is that the new loader gets confused by these raw disks.

  Mark
___
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: Lockdown adaX numbers to allow booting ?

2019-09-20 Thread Slawa Olhovchenkov 
On Thu, Sep 19, 2019 at 06:04:54PM +0200, Michael Gmelin wrote:

> 
> 
> > On 19. Sep 2019, at 17:57, Kurt Jaeger  wrote:
> > 
> > Hi!
> > 
> >>> We have a system with 10 SATA disks. 2 disks are for the system,
> >>> 8 disks drive a data pool 'bck', configured as raidz2, for backup 
> >>> purposes:
> >>> 
> >>> bck72.8T  38.7T  34.1T- - 1%53%  1.00x  
> >>> ONLINE  -
> > 
> >>> The problem is that if all 10 disks are connected, the system
> >>> looses track from where it should boot and fails to boot (serial boot 
> >>> log):
> > 
> >> Why this order does change?  One would expect disks 0 and 1 to be OS disks 
> >> and the rest for data???
> > 
> > 0+1 are 2.5", and the initial setup was:
> > - we installed system disks as zroot 
> > - shipped the box to the housing facility
> > - booted and added the drives
> > 
> > At that time we did not do additional tests about the disk/boot sequence
> > etc.
> > 
> >> Also the question is, what you mean with ???system looses track
> > 
> > I interpret the hang during boot as 'it looses track'. So I guess
> > it tries to read the kernel from the wrong drives.
> > 
> >> disk4 becomes adaX? why it matters, are you using ufs on boot disks?
> > 
> > No, zpool only.
> > 
> > I've made a few more details available here:
> > 
> > https://people.freebsd.org/~pi/host/dmesg.txt
> > https://people.freebsd.org/~pi/host/devlist.txt
> > https://people.freebsd.org/~pi/host/gpart.txt
> > https://people.freebsd.org/~pi/host/pciconf.txt
> > https://people.freebsd.org/~pi/host/zpool.txt
> 
> What about gpart output of the pool drives?
> 
> In general you would create zpools using gptids or gpt labels, not the 
> devices, so you’re independent of device numbering. The boot loader should 
> only be installed on drives that contain the boot pool (maybe you have old 
> boot loaders on data drives?).

ZFS work w/ ZFS labels, not w/ device names/gptids/gpt labels.
You don't worry about changed device names aroud reboots.
___
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: Firefox – GtkFileChooserNative – file selection dialogues

2019-09-20 Thread Greg V 
On September 19, 2019 8:02:35 PM GMT+03:00, Graham Perrin 
 wrote:
>Firefox does not use xdg-desktop-portal for file selection dialogs
>
>
> > This patch makes Firefox's GTK3 platform support use
> > GtkFileChooserNative when available. GtkFileChooserNative
> > transparently uses the desktop portals interface, which
> > enables Firefox to use native Qt file dialogs on KDE, or
> > sandboxed file dialogs in Flatpak.
>
>– RESOLVED FIXED, mozilla64
>
>Can I benefit from this patch on FreeBSD?
>
>(What am I missing?)

The dbus portal implementation itself, most likely.

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