Kernel with INVARIANTS panicing if drm is loaded

[Oleg V. Nauman]

 I am observing kernel panic when entering multiuser mode after sucessful 
system boot. It happens when I load CURRENT kernel with INVARIANTS and drm 
module loaded ( drm-515-kmod-5.15.118_1 in particular ) . drm module and kenel 
are in sync


FreeBSD moonset.home 15.0-CURRENT FreeBSD 15.0-CURRENT #3 main-n266267-
e116e040f309: Sun Nov  5 10:00:51 EET 2023 r...@moonset.home:/usr/obj/usr/
src/amd64.amd64/sys/moonset  amd64

panic: sleepq_add: td 0xf8000203c000 to sleep on wchan 0xf800021d8648 
with sleeping prohibited
...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
panic: malloc(M_WAITOK) with sleeping prohibited
cpuid = 0
time = 1699171621
.
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
57  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
#1  doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:405
#2  0x81e2ec53 in vt_kms_postswitch () from /boot/modules/drm.ko
#3  0x8043ad6e in vt_window_switch (vw=0xf800021d8640)
at /usr/src/sys/dev/vt/vt_core.c:595
#4  0x804ec583 in kern_reboot (howto=4)
at /usr/src/sys/kern/kern_shutdown.c:501
#5  0x804eccfa in vpanic (
fmt=0x808263fb "malloc(M_WAITOK) with sleeping prohibited",
ap=ap@entry=0xfe00ce259850) at /usr/src/sys/kern/kern_shutdown.c:970
#6  0x804ecb03 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:894
#7  0x804c8a04 in malloc_dbg (vap=,
sizep=, mtp=, flags=)
at /usr/src/sys/kern/kern_malloc.c:540
#8  0x804c885c in malloc (size=,
mtp=0x81e931c0 , flags=)
at /usr/src/sys/kern/kern_malloc.c:641
#9  0x81c5a750 in intel_atomic_state_alloc ()
   from /boot/modules/i915kms.ko
#10 0x81dfe404 in drm_client_modeset_commit_atomic ()
   from /boot/modules/drm.ko
#11 0x81dfe614 in drm_client_modeset_commit_locked ()
   from /boot/modules/drm.ko
#12 0x81dfe7a1 in drm_client_modeset_commit ()
   from /boot/modules/drm.ko
#13 0x81e41ab3 in drm_fb_helper_restore_fbdev_mode_unlocked ()
   from /boot/modules/drm.ko
#14 0x81e2ed91 in vt_kms_postswitch () from /boot/modules/drm.ko
#15 0x8043ac31 in vt_window_switch (vw=0xf80001d3a600,
vw@entry=0x80a47178 )
at /usr/src/sys/dev/vt/vt_core.c:612
#16 0x8043be0f in vtterm_cngrab (tm=,
tm@entry=)
at /usr/src/sys/dev/vt/vt_core.c:1863
#17 0x804893f6 in cngrab () at /usr/src/sys/kern/kern_cons.c:385
#18 0x804ecc79 in vpanic (
fmt=0x808799a9 "%s: td %p to sleep on wchan %p with sleeping 
prohibited", ap=ap@entry=0xfe00ce259c20)
at /usr/src/sys/kern/kern_shutdown.c:942
#19 0x804ecb03 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:894
#20 0x805465b3 in sleepq_add (wchan=wchan@entry=0xf800021d8648,
lock=lock@entry=0xf80001823340,
wmesg=wmesg@entry=0x808b194e "tq_drain", flags=0,
flags@entry=, queue=queue@entry=0)
at /usr/src/sys/kern/subr_sleepqueue.c:326
#21 0x804f8efe in _sleep (ident=ident@entry=0xf800021d8648,
lock=lock@entry=0xf80001823340, priority=priority@entry=0,
wmesg=0x808b194e "tq_drain", sbt=sbt@entry=0, pr=pr@entry=0,
flags=256) at /usr/src/sys/kern/kern_synch.c:207
#22 0x8054cffb in TQ_SLEEP (tq=0xf80001823300,
p=0xf800021d8648, wm=)
at /usr/src/sys/kern/subr_taskqueue.c:124
#23 taskqueue_drain (queue=0xf80001823300, task=0xf800021d8648)
at /usr/src/sys/kern/subr_taskqueue.c:614
#24 0x81e2ed35 in vt_kms_postswitch () from /boot/modules/drm.ko
#25 0x8043ac31 in vt_window_switch (vw=0xf800021d8648,
vw@entry=0xf800038fb180) at /usr/src/sys/dev/vt/vt_core.c:612
#26 0x8043b3b2 in vt_late_window_switch (vw=0xf800038fb180)
at /usr/src/sys/dev/vt/vt_core.c:468
#27 vt_proc_window_switch (vw=0xf800038fb180)
at /usr/src/sys/dev/vt/vt_core.c:553
#28 0x8043e318 in vt_processkey (
kbd=0x80cef898 , vd=0x80a472c8 ,
c=) at /usr/src/sys/dev/vt/vt_core.c:903
#29 vt_kbdevent (kbd=0x80cef898 , event=,
arg=0x80a472c8 ) at /usr/src/sys/dev/vt/vt_core.c:1018
#30 0x8078ffcf in atkbd_intr (kbd=0x80cef898 ,
arg=) at /usr/src/sys/dev/atkbdc/atkbd.c:565
#31 0x804b1376 in intr_event_execute_handlers (ie=0xf800010ece00,
p=) at /usr/src/sys/kern/kern_intr.c:1205
#32 ithread_execute_handlers (ie=0xf800010ece00, p=)
at /usr/src/sys/kern/kern_intr.c:1218
#33 ithread_loop (arg=arg@entry=0xf80001c5aea0)
at /usr/src/sys/kern/kern_intr.c:1306
#34 0x804adae2 in fork_exit (
callout=0x804b1120 , arg=0xf80001c5aea0,
frame=0xfe00ce259f40) at 

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Oleg V. Nauman]

On 2021 M09 6, Mon 20:31:33 EEST Cy Schubert wrote:
> One last favour to ask, can you try this with the wpa_supplicant-devel
> port, please? I'm trying to narrow down if this is related to the options
> in usr.sbin/wpa/Makefile.inc or an upstream problem. If this behaves the
> same using wpa_supplicant-devel, this tells me to look at the code instead
> of Makefiles.
> 
> I can reproduce the service netif restart problem using the old
> wpa_supplicant 2.9, so at least here there is no change in behaviour.
> Though on my sandbox machine the ifconfig dow/up is not required -- though
> even the older wpa_supplicant 2.9 behaves the same on my laptop, (no
> regression experienced here).
> 
> To help point to either Makefile.inc or contrib/wpa, can you please try the
> wpa_supplicant-devel port. This will tell me where to look next.

 I can confirm that wpa_supplicant from security/wpa_supplicant-devel port 
demonstrating the same behavior as wpa_supplicant from base - "ifconfig wlan0 
down ; sleep 5 ; ifconfig wlan0 up" mitigate wlan association issue.

> 
> Fifteen seconds isn't needed. Two or three, even no wait, will do.

 Thank you

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Oleg V. Nauman]

On 2021 M09 6, Mon 18:41:13 EEST Cy Schubert wrote:
> I changed mine to be the same as yours. I can connect. (I use iwn(4) and
> ath(4) here.)

 a ) regular reboot - wlan can not associate
 b ) service netif restart - wlan can not associate
 c ) service netif stop wlan0 ; service netif start wlan0 - wlan can not 
associate
 d ) ifconfig wlan0 down; sleep 15 ; ifconfig wlan0 up - wlan associated
 e ) regular reboot with ifconfig wlan0 down; sleep 15 ; ifconfig wlan0 up 
added to /etc/rc.local - wlan associated

Thank you.

> 
> Do you reboot every time you test or simply this?
> 
>   service netif stop wlan0
>   service netif start wlan0
> 
> If simply above, does a reboot have it work again?
> 
> The reason I ask is, I discovered, today, a quirk in 14-CURRENT, regardless
> of the wpa_supplicant installed. It will always associate following a
> reboot however when running the above two commands to stop and start wlan0
> I can reproduce your problem. The workaround for now is when running the
> above two commands to also ifconfig wlan0 down; ifconfig wlan0 up.
> 
> Can you try ifconfig wlan0 down; ifconfig wlan0 up after stopping/starting
> wlan0? You may need to wait 2-3 seconds between down and up.

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Oleg V. Nauman]

On 2021 M09 6, Mon 08:50:21 EEST Cy Schubert wrote:
> In message <2838567.hhqauc6...@sigill.theweb.org.ua>, "Oleg V. Nauman"
> 
> writes:
> > On 2021 M09 5, Sun 15:52:50 EEST David Wolfskill wrote:
> > > Sorry I hadn't noticed this yesterday (so I could have repported it
> > > then), but after updating the "head" slice of my laptopp from:
> > > 
> > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340
> > > main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021
> > > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > amd64 1400032 1400032
> > > 
> > > to:
> > > 
> > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341
> > > main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021
> > > r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> > > amd64 1400032 1400032
> > > 
> > > I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does not:
> > > the WLAN LED doesn't light up.
> >  
> >  I am also experiencing issues with wlan after my current update to
> > 
> > 1f7a6325fe1b. I have checked ath(4) , run(4), rtwn(4) and all of them
> > demonstrating the same behavior  - wlan can not associate.
> > You can mitigate it by using security/wpa_supplicant from ports as
> > replacemen t
> > of wpa_supplicant in base.
> > 
> > .
> > 
> > > I note that exactly the same hardware works OK in stable/12 and
> > > stable/13.
> > > 
> > > Peace,
> > > david
> 
> Can you grep wpa_supplicant in /var/log/messages? This will give us a clue.

/var/log/messages:Sep  6 15:21:55 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:21:56 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:21:57 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:22:44 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:30:11 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:30:32 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:30:34 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1
/var/log/messages:Sep  6 15:30:50 asus wpa_supplicant[310]: wlan0: CTRL-EVENT-
SCAN-FAILED ret=-1 retry=1

Compare it to successful association attempt while I was using wpa_supplicant 
from ports:

/var/log/messages:Sep  6 15:19:21 asus wpa_supplicant[326]: wlan0: 
Authentication with MAC timed out.
/var/log/messages:Sep  6 15:19:21 asus wpa_supplicant[326]: wlan0: CTRL-EVENT-
DISCONNECTED bssid=MAC reason=3 locally_generated=1
/var/log/messages:Sep  6 15:19:21 asus wpa_supplicant[326]: wlan0: CTRL-EVENT-
SSID-TEMP-DISABLED id=0 ssid="..." auth_failures=1 duration=10 
reason=CONN_FAILED
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: CTRL-EVENT-
SSID-REENABLED id=0 ssid="..."
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: Trying to 
associate with MAC (SSID='...' freq=2447 MHz)
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: Failed to add 
supported operating classes IE
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: Associated 
with MAC
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: WPA: Key 
negotiation completed with MAC [PTK=CCMP GTK=CCMP]
/var/log/messages:Sep  6 15:19:31 asus wpa_supplicant[326]: wlan0: CTRL-EVENT-
CONNECTED - Connection to MAC completed [id=0 id_str=]

wlan related settings from /etc/rc.conf

wlans_ath0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"


Thank you

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Oleg V. Nauman]

On 2021 M09 6, Mon 16:23:21 EEST Cy Schubert wrote:
> In message  om>
> 
> , Idwer Vollering writes:
> > Op ma 6 sep. 2021 om 07:53 schreef Cy Schubert 
:
> > > In message <2838567.hhqauc6...@sigill.theweb.org.ua>, "Oleg V. Nauman"
> > > 
> > > writes:
> > > > On 2021 M09 5, Sun 15:52:50 EEST David Wolfskill wrote:
> > > > > Sorry I hadn't noticed this yesterday (so I could have repported it
> > > > > then), but after updating the "head" slice of my laptopp from:
> > > > > 
> > > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340
> > > > > main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021
> > > > > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CAN
> > > > > ARY
> > > > > amd64 1400032 1400032
> > > > > 
> > > > > to:
> > > > > 
> > > > > FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341
> > > > > main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021
> > > > > r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CAN
> > > > > ARY
> > > > > amd64 1400032 1400032
> > > > > 
> > > > > I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does
> > > > > not:
> > > > > the WLAN LED doesn't light up.
> > > >  
> > > >  I am also experiencing issues with wlan after my current update to
> > > > 
> > > > 1f7a6325fe1b. I have checked ath(4) , run(4), rtwn(4) and all of them
> > > > demonstrating the same behavior  - wlan can not associate.
> > > > You can mitigate it by using security/wpa_supplicant from ports as
> > > > replac
> > 
> > emen
> > 
> > > > t
> > > > of wpa_supplicant in base.
> > > > 
> > > > .
> > > > 
> > > > > I note that exactly the same hardware works OK in stable/12 and
> > > > > stable/
> > 
> > 13.
> > 
> > > > > Peace,
> > > > > david
> > > 
> > > Can you grep wpa_supplicant in /var/log/messages? This will give us a
> > > clue.
> > 
> > wpa_supplicant stops in wpa_driver_bsd_scan() -
> > https://github.com/freebsd/freebsd-src/blob/bd452dcbede69b1862c769f244948f
> > 94b 86448b5/contrib/wpa/src/drivers/driver_bsd.c#L1315
> > 
> > Here's some selected output from /var/log/messages.
> > 
> > Before (built from commit a0c64a443e4cae67a5eea3a61a47d746866de3ee):
> > 
> > Sep  6 13:29:40  wpa_supplicant[45348]: Successfully
> > initialized wpa_supplicant
> > Sep  6 13:29:40  wpa_supplicant[45348]: ioctl[SIOCS80211,
> > op=20, val=0, arg_len=7]: Invalid argument
> > Sep  6 13:29:40  syslogd: last message repeated 1 times
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Trying to
> > associate with  (SSID='' freq=2447 MHz)
> > Sep  6 13:29:46  wpa_supplicant[45349]: Failed to add
> > supported operating classes IE
> > Sep  6 13:29:46  kernel: wlan1: link state changed to UP
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: Associated with
> >  > 
> > Sep  6 13:29:46  dhclient[45401]: send_packet: No buffer
> > space available
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1: WPA: Key
> > negotiation completed with  [PTK=CCMP GTK=CCMP]
> > Sep  6 13:29:46  wpa_supplicant[45349]: wlan1:
> > CTRL-EVENT-CONNECTED - Connection to  completed [id=0 id_str=]
> > 
> > After (built from main):
> > 
> > Sep  6 12:19:50  wpa_supplicant[1236]: Successfully
> > initialized wpa_supplicant
> > Sep  6 12:19:50  kernel: wlan1: Ethernet address: 
> > Sep  6 12:19:50  wpa_supplicant[1236]: ioctl[SIOCS80211,
> > op=20, val=0, arg_len=7]: Invalid argument
> > Sep  6 12:19:50  syslogd: last message repeated 1 times
> > Sep  6 12:19:50  wpa_supplicant[1237]: wlan1:
> > CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
> 
> Is there a wpa_supplicant.core dump in / ?

 No

> 
> Can you also send me a sanitized copy of wpa_supplicant.conf, please? I'm
> interested in the lines proto=, key_mgmt=, pairwise=, group=, eap=, and
> phase2=. You may not be using eap= or phase2=, which is fine.

# grep -E -2 "proto=|key_mgmt=|pairwise=|group=|eap=|phase2=" /etc/
wpa_supplicant.conf
network={
priority=0
key_mgmt=NONE
}

Config of active wireless network looks like 

network={
ssid=",,,"
scan_ssid=0
psk="..."
priority=4
}


Global section of /etc/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant
eapol_version=2
ap_scan=1
fast_reauth=1




> I'd like to
> see if there are any differences from what was tested. Though, looking at
> your outputs above you're probably using something like:
> 
> proto=RSN WPA
> key_mgmt=WPA-PSK
> pairwise=CCMP
> group=CCMP
> 
> Is this correct?
> 
> If you try ports/securitiy/wpa_supplicant-devel (same codebase as in
> 14-CURRENT), does it work? 
 
 No it fals to associate with same symptoms as wpa_supplicant from base.

> (ports/security/wpa_supplicant is the old 2.9
> codebase.)
> 
> What is your AP set for? 802.11g, 802.11n, 802.11ac?

 802.11gn

Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0

[Oleg V. Nauman]

On 2021 M09 5, Sun 15:52:50 EEST David Wolfskill wrote:
> Sorry I hadn't noticed this yesterday (so I could have repported it
> then), but after updating the "head" slice of my laptopp from:
> 
> FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #340
> main-n249128-a0c64a443e4c: Fri Sep  3 04:06:12 PDT 2021
> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY 
> amd64 1400032 1400032
> 
> to:
> 
> FreeBSD g1-51.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #341
> main-n249146-cb5c07649aa0: Sat Sep  4 04:28:27 PDT 2021
> r...@g1-51.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY 
> amd64 1400032 1400032
> 
> I find that while the em0 NIC still works, wlan0 (iwn(4) HW) does not:
> the WLAN LED doesn't light up.

 I am also experiencing issues with wlan after my current update to 
1f7a6325fe1b. I have checked ath(4) , run(4), rtwn(4) and all of them 
demonstrating the same behavior  - wlan can not associate.
You can mitigate it by using security/wpa_supplicant from ports as replacement 
of wpa_supplicant in base.

.
> 
> I note that exactly the same hardware works OK in stable/12 and stable/13.
> 
> Peace,
> david

run(4) fails to associate Re: wlan0 (iwn(4)) needed encouragement to associate

[Oleg V. Nauman]

On 2021 M01 17, Sun 15:19:56 EET David Wolfskill wrote:
> After this morning's update of head from:
> 
> FreeBSD g1-55.catwhisker.org 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #124
> main-c256006-g8ca9ff4f28d2-dirty: Sat Jan 16 05:47:48 PST 2021
> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY 
> amd64 1300135 1300135
> 
> 
> to:
> 
> FreeBSD g1-55.catwhisker.org 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #125
> main-c256026-gb7ab6832cd98-dirty: Sun Jan 17 04:49:26 PST 2021
> r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY 
> amd64 1300135 1300135
> 
> on my laptop, the wireless link failed to associate by the time the
> xdm login screen came up.  But when I logged in (on vty1) and issued:
> 
>   service netif restart wlan0
> 
> it associated right away.  (There was no issue with the corresponding
> update for stable/12, so I have no reason to believe that there is an
> issue with the access point or the laptop -- with respect to associating
> properly, at least).  And whether in head or stable/12, the woreless
> link has (for the past several months of daily tracking both head and
> stable/12) almost always associated by the time the xdm login screen
> comes up.
> 
> I tried it 3 times; each time, it failed to associate.  (I only tried
> the "service netif restart wlan0" the last 2 times -- the first time,
> vty1 wasn't usable because I had experimented with a /boot/loader.conf
> setting, which (as far as I know) is not relevant to this issue.)


 I can confirm that run(4) fails to associate on FreeBSD 13.0-ALPHA1 #38 main-
c256026-gb7ab6832cd98-dirty Jan 17

kernel: ugen0.3:  at usbus0
kernel: run0 on uhub0
kernel: run0:  on usbus0
kernel: run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 
00:26:5a:0a:cb:fa
kernel: run0: [HT] Enabling 802.11n
webcamd[5382]: webcamd: Cannot find USB device
kernel: wlan0: Ethernet address: 00:26:5a:0a:cb:fa
root[6113]: /etc/rc.d/dhclient: WARNING: failed to start dhclient

while it works with with one week old kernel
FreeBSD 13.0-CURRENT #37 main-c255825-g2a4b22514635-dirty Jan 10

kernel: run0 on uhub0
kernel: run0:  on usbus0
kernel: run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 
00:26:5a:0a:cb:fa
kernel run0: [HT] Enabling 802.11n
kernel run0: firmware RT2870 ver. 0.33 loaded
kernel: wlan0: link state changed to UP


> 
> Peace,
> david


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

Current amd64 main-c255825-g2a4b22514635-dirty panic triggered by ure(4) detach

[Oleg V. Nauman]

 


__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=)
at /usr/src/sys/kern/kern_shutdown.c:399
#2  0x804a3b3e in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:486
#3  0x804a3f2b in vpanic (fmt=, ap=0xfe00eb7d3130)
at /usr/src/sys/kern/kern_shutdown.c:919
#4  0x804a3d83 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:843
#5  0x807009cc in trap_fatal (frame=frame@entry=0xfe00eb7d3330,
eva=1088) at /usr/src/sys/amd64/amd64/trap.c:915
#6  0x80700d68 in trap_pfault (frame=frame@entry=0xfe00eb7d3330,
usermode=false, signo=, signo@entry=0x0,
ucode=, ucode@entry=0x0)
at /usr/src/sys/amd64/include/cpufunc.h:433
#7  0x807001c9 in trap (frame=0xfe00eb7d3330)
at /usr/src/sys/amd64/amd64/trap.c:398
#8  
#9  __mtx_lock_sleep (c=0xf8023a13beb8, v=)
at /usr/src/sys/kern/kern_mutex.c:590
#10 0x80400304 in usbd_do_request_flags (udev=,
udev@entry=0xf802f632e000, mtx=0xf8023a13bea0,
req=req@entry=0xfe00eb7d3558, data=data@entry=0xfe00eb7d3564,
flags=flags@entry=0, actlen=actlen@entry=0x0, timeout=)
at /usr/src/sys/dev/usb/usb_request.c:714
#11 0x804003e0 in usbd_do_request_proc (udev=0xf802f632e000,
pproc=pproc@entry=0xf8023a13bc40, req=req@entry=0xfe00eb7d3558,
data=data@entry=0xfe00eb7d3564, flags=flags@entry=0,
actlen=actlen@entry=0x0, timeout=1000)
at /usr/src/sys/dev/usb/usb_request.c:759
#12 0x81648499 in ure_ctl (sc=0xf8023a13bc00, rw=1 '\001',
val=45056, index=256, buf=0xfe00eb7d3564, len=4)
at /usr/src/sys/dev/usb/net/if_ure.c:303
#13 ure_read_mem (sc=0xf8023a13bc00, addr=45056, index=256,
buf=0xfe00eb7d3564, len=4) at /usr/src/sys/dev/usb/net/if_ure.c:311
#14 ure_read_2 (sc=0xf8023a13bc00, reg=45056, index=256)
at /usr/src/sys/dev/usb/net/if_ure.c:349
#15 ure_ocp_reg_read (sc=0xf8023a13bc00, addr=8192)
at /usr/src/sys/dev/usb/net/if_ure.c:424
#16 ure_miibus_readreg (dev=, phy=,
reg=) at /usr/src/sys/dev/usb/net/if_ure.c:457
#17 0x81660535 in MIIBUS_READREG (dev=0xf8027ee1c900, phy=0,
reg=0) at ./miibus_if.h:27
#18 rgephy_status (sc=0xf801bdce6880) at /usr/src/sys/dev/mii/rgephy.c:325
#19 0x81660427 in rgephy_service (sc=0xf801bdce6880,
mii=, cmd=)
at /usr/src/sys/dev/mii/rgephy.c:265
#20 0x8165c8d6 in mii_pollstat (mii=mii@entry=0xf801bc043700)
at /usr/src/sys/dev/mii/mii.c:627
#21 0x8164b165 in ure_ifmedia_sts (ifp=,
ifmr=0xfe00eb7d3910) at /usr/src/sys/dev/usb/net/if_ure.c:1272
#22 0x8059fbca in ifmedia_ioctl (ifp=0xf8023a13beb8,
ifr=0xfe00eb7d3910, ifm=0xf801bc043700, cmd=)
at /usr/src/sys/net/if_media.c:294
#23 0x80597875 in ifhwioctl (cmd=cmd@entry=3224398136,
ifp=ifp@entry=0xf80268a3,
data=data@entry=0xfe00eb7d3910 "ue0", td=td@entry=0xfe00eb4aea00)
at /usr/src/sys/net/if.c:2840
#24 0x805992e6 in ifioctl (so=0xf8031252b3b0, cmd=3224398136,
data=0xfe00eb7d3910 "ue0", td=0xfe00eb4aea00)
at /usr/src/sys/net/if.c:3049
#25 0x80505caa in fo_ioctl (fp=0xf80030644e10, com=3224398136,
data=0xfe00eb7d3910, active_cred=0xf8023a13bea0,
td=0xfe00eb4aea00) at /usr/src/sys/sys/file.h:354
#26 kern_ioctl (td=0xfe00eb4aea00, fd=,
com=com@entry=3224398136, data=data@entry=0xfe00eb7d3910 "ue0")
at /usr/src/sys/kern/sys_generic.c:803
#27 0x805059f6 in sys_ioctl (td=,
uap=0xfe00eb4aede8) at /usr/src/sys/kern/sys_generic.c:711
#28 0x807012a0 in syscallenter (td=0xfe00eb4aea00)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189
#29 amd64_syscall (td=0xfe00eb4aea00, traced=0)
at /usr/src/sys/amd64/amd64/trap.c:1156
#30 
#31 0x0008026d8b6a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdf7f8ed8
(kgdb)

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

linker_load_file: /boot/kernel/ipfw.ko - unsupported file type

[Oleg V. Nauman]

 

 Hello,


kernel: link_elf_obj: symbol fib6_lookup_rt undefined
kernel: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type

It seems ipf.ko unconditionally perform IPV6 lookup even on system built with  
WITHOUT_INET6=YES defined


FreeBSD 13.0-CURRENT r368604 amd64

Thank you
___
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: kernel: linux: pid 2867 (java): cannot fill /proc/self/maps; consider bumping PFS_MAXBUFSIZ

[Oleg V. Nauman]

 Hello,

On 2020 M11 4, Wed 17:27:46 EET Ed Maste wrote:
> On Sun, 1 Nov 2020 at 11:15, Oleg V. Nauman  wrote:
> > It is davmail ( mail/davmail from ports collection ) application that
> > executed by linux java interpreter ( java/linux-oracle-jdk18 from ports )
> 
> If you're set up to test a patch you can give
> https://reviews.freebsd.org/D27047 a try. There's some small detail to
> work out but this should be solved soon.

Kernel error message disappeared, thank you



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

kernel: linux: pid 2867 (java): cannot fill /proc/self/maps; consider bumping PFS_MAXBUFSIZ

[Oleg V. Nauman]

 Hello,

It is davmail ( mail/davmail from ports collection ) application that executed 
by linux java interpreter ( java/linux-oracle-jdk18 from ports )

davmail 2867   0.0  1.3 6441720  163900  -  I09:40  1:01.20 /usr/
local/linux-oracle-jdk1.8.0/bin/java -cp /usr/local/share/java/davmail/
davmail.jar:/usr/local/share/java/davmail/lib/* davmail.DavGateway /usr/local/
etc/davmail.properties


# uname -mr
13.0-CURRENT amd64


Thank you

___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Oleg V. Nauman]

On 2020 M09 23, Wed 01:51:28 EEST Mark Johnston wrote:
> On Tue, Sep 22, 2020 at 01:13:29AM +0300, Konstantin Belousov wrote:
> > On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 31; apic id = 1f
> > > fault virtual address   = 0x25407efa
> > 
> > This address is very suspicious.
> > 
> > I cannot claim it as the fact, but most likely cause for such garbage
> > pointer value is mismatched ABI between kernel and module.  In other
> > words, the module was built against headers from different kernel.
> 
> For some reason clang is not complaining about a missing declaration for
> vm_pager_allocate(), despite -Wmissing-prototypes in the CFLAGS...
> 
> This patch is required on top of a patched extract of the vbox sources:
> 
> --- the-freebsd-kernel.h.orig 2020-09-22 18:49:26.499329000 -0400
> +++ the-freebsd-kernel.h  2020-09-22 18:49:55.317615000 -0400
> @@ -68,6 +68,7 @@
>  #include 
>  #include /* KERN_SUCCESS ++ */
>  #include 
> +#include 
>  #include  /* vm_phys_alloc_* */
>  #include/* kmem_alloc_attr */
>  #include   /* vm_contig_grow_cache */
> --- memobj-r0drv-freebsd.c.orig   2020-09-22 18:49:25.010456000 -0400
> +++ memobj-r0drv-freebsd.c2020-09-22 18:49:47.462276000 -0400
> @@ -323,7 +323,8 @@
>  size_t  cPages = atop(pMemFreeBSD->Core.cb);
>  int rc;
> 
> -pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages);
> +pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL,
> +pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred);
> 
>  /* No additional object reference for auto-deallocation upon unmapping.
> */ #if __FreeBSD_version >= 155
> @@ -457,7 +458,8 @@
>  return VERR_NO_MEMORY;
>  }
> 
> -pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb));
> +pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL,
> +pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred);
> 
>  if (PhysHighest != NIL_RTHCPHYS)
>  VmPhysAddrHigh = PhysHighest;

 This fixed the issue with panic, thank you


___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Oleg V. Nauman]

On 2020 M09 22, Tue 19:45:25 EEST Rainer Hurling wrote:
> On 22.09.20 07:06, Rainer Hurling wrote:
> > Am 22.09.20 um 00:13 schrieb Konstantin Belousov:
> >> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 31; apic id = 1f
> >>> fault virtual address   = 0x25407efa
> >> 
> >> This address is very suspicious.
> >> 
> >> I cannot claim it as the fact, but most likely cause for such garbage
> >> pointer value is mismatched ABI between kernel and module.  In other
> >> words, the module was built against headers from different kernel.
> > 
> > Hmm, thanks for the pointer. I will double check this evening and
> > reporting back.
> > 
> > Normally, this module should have been built and installed with the
> > kernel build.
> 
> As I said, the module was rebuild and reinstalled with the kernel build,
> and I double checked, the module was the patched version.
> 
> So the boot messages about the page fault should be created by the
> rebuild, patched module.
> 
> >>> fault code  = supervisor read data, page not present
> >>> instruction pointer = 0x20:0x80ec0b63
> >>> stack pointer   = 0x28:0x826018b0
> >>> frame pointer   = 0x28:0x82601940
> >>> 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 = 0 (swapper)
> >>> trap number = 12
> >>> panic: page fault
> >>> cpuid = 31
> >>> time = 1
> >>> KDB: stack backtrace:
> >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> >>> 0x82601560
> >>> vpanic() at vpanic+0x182/frame 0x826015b0
> >>> panic() at panic+0x43/frame 0x82601610
> >>> trap_fatal() at trap_fatal+0x387/frame 0x82601670
> >>> trap_pfault() at trap_pfault+0x97/frame 0x826016d0
> >>> trap() at trap+0x2ab/frame 0x826017e0
> >>> calltrap() at calltrap+0x8/frame 0x826017e0
> >>> --- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp =
> >>> 0x82601940 ---
> >>> vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940
> >>> vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00
> >>> rtR0MemObjFreeBSDAllocHelper() at
> >>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70
> >>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
> >>> 0x82601ac0
> >>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
> >>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
> >>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
> >>> 0x82601bf0
> >>> module_register_init() at module_register_init+0xbd/frame
> >>> 0x82601c20
> >>> mi_startup() at mi_startup+0xec/frame 0x82601c70
> >>> btext() at btext+0x2c
> >>> KDB: enter: panic
> >>> [ thread pid 0 tid 10 ]
> >>> Stopped at  kdb_enter+0x37: movq$0,0x10b5616(%rip)
> >>> db>
> >>> 
> >>> 
> >>> Perhaps this gives some more insight into the problem? I can't assess,
> >>> sorry.


 I am experiencing the same issue with panic caused by 'kldload vboxdrv'
Below is the stack strace , with both virtualbox-ose and virtualbox-ose-kmod 
patched:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x1e419ada
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80731b0d
stack pointer   = 0x28:0xfe008223b4d0
frame pointer   = 0x28:0xfe008223b550
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 = 2194 (kldload)
trap number = 12
panic: page fault
cpuid = 0
time = 1600808943
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe008223b1b0
vpanic() at vpanic+0x182/frame 0xfe008223b200
panic() at panic+0x43/frame 0xfe008223b260
trap_fatal() at trap_fatal+0x387/frame 0xfe008223b2c0
trap_pfault() at trap_pfault+0x49/frame 0xfe008223b2f0
trap() at trap+0x259/frame 0xfe008223b400
calltrap() at calltrap+0x8/frame 0xfe008223b400
--- trap 0xc, rip = 0x80731b0d, rsp = 0xfe008223b4d0, rbp = 
0xfe008223b550 ---
vm_map_insert() at vm_map_insert+0x24d/frame 0xfe008223b550
vm_map_find() at vm_map_find+0x539/frame 0xfe008223b630
rtR0MemObjFreeBSDAllocHelper() at rtR0MemObjFreeBSDAllocHelper+0x96/frame 
0xfe008223b6a0
rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame 
0xfe008223b6f0
supdrvGipCreate() at supdrvGipCreate+0x97/frame 0xfe008223b790
supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0xfe008223b800
VBoxDrvFreeBSDModuleEvent() at 

HEAD i386 r336217 : wireless connection fails ( ath(4) )

[Oleg V. Nauman]

 I'm experiencing wireless connection failure after HEAD/i386 update performed 
today.
Below is relevant portion of dmesg buffer:


Jul 12 18:43:39 desktop kernel: wlan0: Ethernet address: 18:a6:f7:8a:b1:52
Jul 12 18:43:39 desktop kernel: wlan0: link state changed to UP
Jul 12 18:43:39 desktop kernel: wlan0: link state changed to DOWN
Jul 12 18:43:41 desktop wpa_supplicant[257]: wlan0: Trying to associate with 
f8:1a:67:56:16:16 (SSID='' freq=2412 MHz)
Jul 12 18:43:41 desktop wpa_supplicant[257]: wlan0: Associated with f8:1a:
67:56:16:16
Jul 12 18:43:41 desktop kernel: wlan0: link state changed to UP
Jul 12 18:43:41 desktop dhclient[641]: New IP Address (wlan0): 192.168.0.50
Jul 12 18:43:41 desktop dhclient[642]: New Subnet Mask (wlan0): 255.255.255.0
Jul 12 18:43:41 desktop dhclient[643]: New Broadcast Address (wlan0): 
192.168.0.255
Jul 12 18:43:41 desktop dhclient[644]: New Routers (wlan0): 192.168.0.1
Jul 12 18:43:42 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED 
bssid=f8:1a:67:56:16:16 reason=1 locally_generated=1
Jul 12 18:43:42 desktop kernel: wlan0: link state changed to DOWN
Jul 12 18:43:42 desktop wpa_supplicant[257]: ioctl[SIOCS80211, op=20, val=0, 
arg_len=7]: Can't assign requested address
Jul 12 18:43:45 desktop wpa_supplicant[257]: wlan0: Trying to associate with 
f8:1a:67:56:16:16 (SSID='' freq=2412 MHz)
Jul 12 18:43:45 desktop wpa_supplicant[257]: wlan0: Associated with f8:1a:
67:56:16:16
Jul 12 18:43:45 desktop kernel: wlan0: link state changed to UP
Jul 12 18:43:45 desktop dhclient[269]: send_packet: No buffer space available
Jul 12 18:43:46 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED 
bssid=f8:1a:67:56:16:16 reason=1 locally_generated=1
Jul 12 18:43:46 desktop kernel: wlan0: link state changed to DOWN
Jul 12 18:43:46 desktop wpa_supplicant[257]: ioctl[SIOCS80211, op=20, val=0, 
arg_len=7]: Can't assign requested address
Jul 12 18:43:49 desktop wpa_supplicant[257]: wlan0: Trying to associate with 
f8:1a:67:56:16:16 (SSID='' freq=2412 MHz)
Jul 12 18:43:49 desktop kernel: wlan0: link state changed to UP
Jul 12 18:43:49 desktop wpa_supplicant[257]: wlan0: Associated with f8:1a:
67:56:16:16
Jul 12 18:43:49 desktop dhclient[269]: send_packet: No buffer space available
Jul 12 18:43:50 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-DISCONNECTED 
bssid=f8:1a:67:56:16:16 reason=1 locally_generated=1
Jul 12 18:43:50 desktop kernel: wlan0: link state changed to DOWN
Jul 12 18:43:50 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-SSID-TEMP-
DISABLED id=22 ssid="" auth_failures=1 duration=10 reason=CONN_FAILED
Jul 12 18:43:50 desktop wpa_supplicant[257]: ioctl[SIOCS80211, op=20, val=0, 
arg_len=7]: Can't assign requested address
Jul 12 18:43:53 desktop wpa_supplicant[257]: wlan0: Trying to associate with 
SSID 'test adhoc'
Jul 12 18:43:53 desktop wpa_supplicant[257]: bsd_set_if_media: SIOCSIFMEDIA 
Device not configured
Jul 12 18:43:53 desktop wpa_supplicant[257]: wpa_driver_bsd_associate: failed 
to set operation mode
Jul 12 18:43:53 desktop wpa_supplicant[257]: wlan0: Association request to the 
driver failed
Jul 12 18:43:53 desktop wpa_supplicant[257]: wlan0: CTRL-EVENT-CONNECTED - 
Connection to 00:00:00:00:00:00 completed [id=-1 id_str=]
Jul 12 18:43:56 desktop dhclient[269]: send_packet: Network is down
Jul 12 18:44:04 desktop dhclient[269]: send_packet: Network is down
Jul 12 18:45:01 desktop dhclient[269]: send_packet: Network is down
Jul 12 18:45:05 desktop dhclient[1739]: New IP Address (wlan0): 192.168.0.50
Jul 12 18:45:05 desktop dhclient[1740]: New Subnet Mask (wlan0): 255.255.255.0
Jul 12 18:45:05 desktop dhclient[1741]: New Broadcast Address (wlan0): 
192.168.0.255
Jul 12 18:45:05 desktop dhclient[1742]: New Routers (wlan0): 192.168.0.1
Jul 12 18:45:06 desktop dhclient[1744]: New Routers (wlan0): 192.168.0.1
___
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"

r324684 amd64 buildworld failed if WITHOUT_ZFS is defined

[Oleg V. Nauman]

===> sys/boot/efi/boot1 (all)
cc -target x86_64-unknown-freebsd12.0 --
sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin  -O2 
-pipe -ffreestanding -Wformat -mno-mmx -mno-sse -mno-avx -msoft-
float -fshort-wchar -mno-red-zone -mno-aes -march=nehalem  -
DLOADER_UFS_SUPPORT -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -
DLOADER_MBR_SUPPORT -DLOADER_GELI_SUPPORT -
I/usr/src/sys/boot/libsa -I/usr/src/sys/boot/common -I. -
I/usr/src/sys/boot/efi/boot1/../include -
I/usr/src/sys/boot/efi/boot1/../include/amd64 -
I/usr/src/sys/boot/efi/boot1/../../../contrib/dev/acpica/include 
-I/usr/src/sys/boot/efi/boot1/../../.. -DEFI_UFS_BOOT -
I/usr/src/sys/boot/efi/boot1/../../common -fPIC -ffreestanding -
Wformat -mno-mmx -mno-sse -mno-avx -msoft-float -fshort-wchar -
mno-red-zone -mno-aes -g -MD  -MF.depend.boot1.o -MTboot1.o -
std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -
Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -
Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-
body -Wno-string-plus-int -Wno-unused-const-variable -Wno-
tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-
typedef -Wno-address-of-packed-member -Wno-format -Qunused-
arguments  -c /usr/src/sys/boot/efi/boot1/boot1.c -o boot1.o
/usr/src/sys/boot/efi/boot1/boot1.c:269:1: error: no previous 
prototype for function 'efi_zfs_is_preferred'
  [-Werror,-Wmissing-prototypes]
efi_zfs_is_preferred(EFI_HANDLE *h)
^
/usr/src/sys/boot/efi/boot1/boot1.c:381:2: error: unknown type 
name 'zfsinfo_list_t'; did you mean
  'pdinfo_list_t'?
zfsinfo_list_t *zfsi_list;
^~
pdinfo_list_t   
 
/usr/src/sys/boot/efi/boot1/../include/efilib.h:49:42: note: 
'pdinfo_list_t' declared here
typedef STAILQ_HEAD(pdinfo_list, pdinfo) pdinfo_list_t;
 ^
/usr/src/sys/boot/efi/boot1/boot1.c:382:2: error: use of 
undeclared identifier 'zfsinfo_t'
zfsinfo_t *zi;
^
/usr/src/sys/boot/efi/boot1/boot1.c:382:13: error: use of 
undeclared identifier 'zi'
zfsinfo_t *zi;
   ^
4 errors generated.
*** Error code 1

Stop.
make[6]: stopped in /usr/src/sys/boot/efi/boot1
*** Error code 1

___
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: r324421 amd64 kernel panics when entering multiuser mode

[Oleg V. Nauman]

On Monday 09 October 2017 05:05:14 Alan Cox wrote:
> On Mon, Oct 9, 2017 at 4:22 AM, Oleg V. Nauman 
<o...@theweb.org.ua> wrote:
> > panic: freeing invalid range
> > cpuid = 0
> > time = 1507550062
> > Uptime: 2s
> > .
> > #0  doadump (textdump=) at pcpu.h:232
> > 232 pcpu.h: No such file or directory.
> > 
> > in pcpu.h
> > 
> > (kgdb) #0  doadump (textdump=) at
> > pcpu.h:232
> > #1  0x804d68b6 in kern_reboot (howto=260)
> > 
> > at /usr/src/sys/kern/kern_shutdown.c:386
> > 
> > #2  0x804d6cdc in vpanic (fmt=,
> > 
> > ap=) at
> > 
> > /usr/src/sys/kern/kern_shutdown.c:779
> > #3  0x804d6b33 in panic (fmt=)
> > 
> > at /usr/src/sys/kern/kern_shutdown.c:710
> > 
> > #4  0x80504013 in blst_meta_free
> > (scan=0xfe00016e3048,
> > 
> > freeBlk=, count=0, radix= > 
> > optimized out>)
> > 
> > at /usr/src/sys/kern/subr_blist.c:869
> > 
> > #5  0x80503fbf in blst_meta_free
> > (scan=0xfe00016e3038,
> > 
> > freeBlk=, count=,
> > radix=) at
> > 
> > /usr/src/sys/kern/subr_blist.c:926
> > #6  0x80503fbf in blst_meta_free
> > (scan=0xfe00016e3028,
> > 
> > freeBlk=, count=,
> > radix=) at
> > 
> > /usr/src/sys/kern/subr_blist.c:926
> > #7  0x80503fbf in blst_meta_free
> > (scan=0xfe00016e3018,
> > 
> > freeBlk=, count=,
> > radix=) at
> > 
> > /usr/src/sys/kern/subr_blist.c:926
> > #8  0x8067568f in swaponsomething (vp= > out>,
> > 
> > id=0xf800052ad000, nblks=986109,
> > strategy=0x80675900 ,
> > close=0x80675b30 , dev=87, 
flags=1)
> > at /usr/src/sys/vm/swap_pager.c:2199
> > 
> > #9  0x80673aac in sys_swapon (td=,
> > 
> > uap=) at
> > 
> > /usr/src/sys/vm/swap_pager.c:2728
> > #10 0x806bc512 in amd64_syscall 
(td=0xf80005387560,
> > traced=0)
> > 
> > at subr_syscall.c:132
> > 
> > #11 0x806a170b in Xfast_syscall ()
> > 
> > at /usr/src/sys/amd64/amd64/exception.S:419
> > 
> > #12 0x000800a888ba in ?? ()
> > Previous frame inner to this frame (corrupt stack?)
> > Current language:  auto; currently minimal
> 
> Please try the patch at https://reviews.freebsd.org/D12627

 This patch fixes kernel panic.

Thank you!


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

r323694 amd64 - crash in linsysfs: Was: svn commit: r323692 - in head/sys/compat: linsysfs linux

[Oleg V. Nauman]

On Sunday 17 September 2017 23:40:16 Conrad Meyer wrote:
> Author: cem
> Date: Sun Sep 17 23:40:16 2017
> New Revision: 323692
> URL: https://svnweb.freebsd.org/changeset/base/323692
> 
> Log:
>   linsysfs(5): Add support for recent libdrm
> 
>   Expose more information about PCI devices (and GPUs in 
particular) via
>   linsysfs to libdrm.
> 
>   This allows unmodified modern 64-bit Linux libdrm to work, 
which allows
>   modern Linux Mesa to work.  The submitter reports that he 
tested the
> change with an Ubuntu 16.04 chroot + amdgpu from graphics/drm-
next-kmod.
> 
>   PR: 222375
>   Submitted by:   Greg V 
> 
> Modified:
>   head/sys/compat/linsysfs/linsysfs.c
>   head/sys/compat/linux/linux_util.c
> 
> Modified: head/sys/compat/linsysfs/linsysfs.c
> 

 Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x3f
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x81027779
stack pointer   = 0x28:0xfe034bc66e70
frame pointer   = 0x28:0xfe034bc66f00
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 = 65 (mount)
trap number = 12
panic: page fault
cpuid = 0
time = 1505752282
Uptime: 2s
...
#0  doadump (textdump=) at pcpu.h:232
232 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=) at 
pcpu.h:232
#1  0x804d74f6 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:386
#2  0x804d791c in vpanic (fmt=, 
ap=) at 
/usr/src/sys/kern/kern_shutdown.c:779
#3  0x804d7773 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:710
#4  0x806bc877 in trap_fatal (frame=0xfe034bc66db0, 
eva=63)
at /usr/src/sys/amd64/amd64/trap.c:799
#5  0x806bca59 in trap_pfault (frame=, 
usermode=) at pcpu.h:247
#6  0x806bc1c3 in trap (frame=0xfe034bc66db0)
at /usr/src/sys/amd64/amd64/trap.c:420
#7  0x806a2363 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:237
#8  0x81027779 in linsysfs_run_bus (dir=)
at /usr/src/sys/compat/linsysfs/linsysfs.c:357
#9  0x810278a1 in linsysfs_run_bus 
(dir=0xf8000e028600)
at /usr/src/sys/compat/linsysfs/linsysfs.c:382
#10 0x810278a1 in linsysfs_run_bus 
(dir=0xf8000e028600)
at /usr/src/sys/compat/linsysfs/linsysfs.c:382
#11 0x810278a1 in linsysfs_run_bus 
(dir=0xf80004c8fe00)
at /usr/src/sys/compat/linsysfs/linsysfs.c:382
#12 0x810278a1 in linsysfs_run_bus 
(dir=0xf80004c8fe00)
at /usr/src/sys/compat/linsysfs/linsysfs.c:382
#13 0x810278a1 in linsysfs_run_bus 
(dir=0xf80004c8fe00)
at /usr/src/sys/compat/linsysfs/linsysfs.c:382
#14 0x810278a1 in linsysfs_run_bus 
(dir=0xf80004c8fe00)
at /usr/src/sys/compat/linsysfs/linsysfs.c:382
#15 0x810278a1 in linsysfs_run_bus 
(dir=0xf80004c8fe00)
at /usr/src/sys/compat/linsysfs/linsysfs.c:382
#16 0x81027194 in linsysfs_init (pi=, 
vfc=) at 
/usr/src/sys/compat/linsysfs/linsysfs.c:478
#17 0x80462773 in pfs_init (pi=0x810285e8, 
vfc=0x810284e0) at 
/usr/src/sys/fs/pseudofs/pseudofs.c:395
#18 0x805792b0 in vfs_modevent (mod=, 
type=, data=0x810284e0)
at /usr/src/sys/kern/vfs_init.c:281
#19 0x804c09a8 in module_register_init 
(arg=0x810284c8)
at /usr/src/sys/kern/kern_module.c:123
#20 0x804b5df6 in linker_load_module (kldname=, 
modname=0xf80004062a70 "linsysfs", parent=0x0, 
verinfo=, lfpp=)
at /usr/src/sys/kern/kern_linker.c:234
#21 0x804b731f in kern_kldload (td=, 
file=, fileid=0xfe034bc677c4)
at /usr/src/sys/kern/kern_linker.c:1042
#22 0x80578e1d in vfs_byname_kld (
fstype=0xf80004062a70 "linsysfs", td=0xf80004c1f560, 
error=0xfe034bc679ec) at 
/usr/src/sys/kern/vfs_init.c:147
#23 0x8057c44f in vfs_donmount (td=, 
fsflags=, fsoptions=0xf80004ca2400)
at /usr/src/sys/kern/vfs_mount.c:1088
#24 0x8057ba70 in sys_nmount (td=0xf80004c1f560, 
uap=) at 
/usr/src/sys/kern/vfs_mount.c:421
#25 0x806bd2a2 in amd64_syscall (td=0xf80004c1f560, 
traced=0)
at subr_syscall.c:132
#26 0x806a26bb in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:419
#27 0x000800a88b3a in ?? ()
Previous frame inner to this frame (corrupt stack?)

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

Buildworld failure in sys/boot/efi/loader/main.c if WITHOUT_ZFS is defined

[Oleg V. Nauman]

===> sys/boot/efi/loader (all)
cc -target x86_64-unknown-freebsd12.0 --
sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin  -O2 
-pipe -march=nehalem  -
I/usr/src/sys/boot/efi/loader/../../../../lib/libstand -fPIC -
DTERM_EMU -I/usr/src/sys/boot/efi/loader -
I/usr/src/sys/boot/efi/loader/arch/amd64 -
I/usr/src/sys/boot/efi/loader/../include -
I/usr/src/sys/boot/efi/loader/../include/amd64 -
I/usr/src/sys/boot/efi/loader/../../../contrib/dev/acpica/include 
-I/usr/src/sys/boot/efi/loader/../../.. -
I/usr/src/sys/boot/efi/loader/../../i386/libi386 -DNO_PCI -DEFI 
-DSMBIOS_SERIAL_NUMBERS -DBOOT_FORTH -
I/usr/src/sys/boot/efi/loader/../../ficl -
I/usr/src/sys/boot/efi/loader/../../ficl/amd64 -
DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -
DLOADER_GELI_SUPPORT -fPIC -I/usr/src/sys/boot/ficl -
I/usr/src/sys/boot/ficl/amd64  -
I/usr/src/sys/boot/ficl/../common -
I/usr/src/sys/boot/efi/loader/../../common -ffreestanding -
Wformat -mno-mmx -mno-sse -mno-avx -msoft-float -fshort-wchar -
mno-red-zone -mno-aes -g -MD  -MF.depend.main.o -MTmain.o -
std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -
Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -
Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-
body -Wno-string-plus-int -Wno-unused-const-variable -Wno-
tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-
typedef -Wno-address-of-packed-member -Wno-format -Qunused-
arguments  -c /usr/src/sys/boot/efi/loader/main.c -o main.o
/usr/src/sys/boot/efi/loader/main.c:883:8: error: implicit 
declaration of function
  'efizfs_get_handle_by_guid' is invalid in C99 [-Werror,-
Wimplicit-function-declaration]
efizfs_get_handle_by_guid(z_dev-
>pool_guid);
^
/usr/src/sys/boot/efi/loader/main.c:883:8: error: this function 
declaration is not a prototype
  [-Werror,-Wstrict-prototypes]
/usr/src/sys/boot/efi/loader/main.c:883:39: error: incomplete 
definition of type 'struct zfs_devdesc'
efizfs_get_handle_by_guid(z_dev-
>pool_guid);
  ~^
/usr/src/sys/boot/efi/loader/main.c:875:10: note: forward 
declaration of 'struct zfs_devdesc'
struct zfs_devdesc *z_dev;
   ^
3 errors generated.
*** Error code 1

Stop.
make[6]: stopped in /usr/src/sys/boot/efi/loader
*** Error code 1

___
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: HEAD/i386 r320212: three reproducible panics [see also bugzilla 220404 about a type of problem introduced in head -r329722 ]

[Oleg V. Nauman]

On Friday 30 June 2017 22:45:39 Mark Millard wrote:
> [Just for the 3rd backtrace example. . .]
> 
> Oleg V. Nauman oleg at theweb.org.ua wrote on
> Fri Jun 23 16:58:07 UTC 2017 :
> 
> .. . .
> 
> > __curthread () at ./machine/pcpu.h:225
> > 225  __asm("movl %%fs:%1,%0" : "=r" (td)
> > (kgdb) #0  __curthread () at ./machine/pcpu.h:225
> > #1  doadump (textdump=-968633856) at ../../../kern/kern_shutdown.c:318
> > #2  0xc06e88c4 in kern_reboot (howto=)
> > 
> > at ../../../kern/kern_shutdown.c:386
> > 
> > #3  0xc06e8c5b in vpanic (fmt=,
> > 
> > ap=0xefd5c73c "\340\334\235\300\310\370\266\306\001")
> > at ../../../kern/kern_shutdown.c:779
> > 
> > #4  0xc06e8b1b in panic (fmt=0xc092e18e "%s")
> > 
> > at ../../../kern/kern_shutdown.c:710
> > 
> > #5  0xc08eed21 in trap_fatal (frame=0xefd5c878, eva=)
> > 
> > at ../../../i386/i386/trap.c:978
> > 
> > #6  0xc08eea38 in trap (frame=)
> > 
> > at ../../../i386/i386/trap.c:704
> > 
> > #7  
> > #8  0xc6bcda1b in ?? ()
> > #9  0xc0770281 in unp_connect2 (so=, so2=,
> > 
> > req=) at ../../../kern/uipc_usrreq.c:1497
> > 
> > #10 0xc076ff17 in unp_connectat (fd=, so=,
> > 
> > nam=, td=)
> > at ../../../kern/uipc_usrreq.c:1446
> > 
> > #11 0xc076d510 in unp_connect (so=0xc71c9400, nam=0xc662d500,
> > 
> > td=) at ../../../kern/uipc_usrreq.c:1310
> > 
> > #12 uipc_connect (so=0xc71c9400, nam=0xc662d500, td=)
> > 
> > at ../../../kern/uipc_usrreq.c:587
> > 
> > #13 0xc076a042 in kern_connectat (td=, dirfd=-100,
> > 
> > fd=, sa=0xc662d500) at
> > ../../../kern/uipc_syscalls.c:505
> > 
> > #14 0xc0769f49 in sys_connect (td=0xc6bcda18, uap=0xc6b6f988)
> > 
> > at ../../../kern/uipc_syscalls.c:470
> > 
> > #15 0xc08ef679 in syscallenter (td=)
> > 
> > at ../../../i386/i386/../../kern/subr_syscall.c:132
> > 
> > #16 syscall (frame=) at ../../../i386/i386/trap.c:1103
> > #17 
> > #18 0x283a4747 in ?? ()
> > Backtrace stopped: Cannot access memory at address 0xbfbfe794
> 
> There are problems with a union having fields
> that interfere with each other. The details of
> the layout and interference likely vary from
> TARGET_ARCH to TARGET_ARCH. This is from
> new material added in head -r319722 and
> involves /head/sys/sys/socketvar.h and
> the new union in struct socket.
> 
> See bugzilla 220404 and its analysis of a
> repeatable crash on 32-bit powerpc for
> head -r320482 (I'd made a large jump from
> well before -r319722):
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220404
> 
> It also involves unp_connect2, unp_connect,
> kern_connectat, sys_connect and is likely
> involved. But different aliasing in the
> union across architectures likely lead to
> varying details for the behavior that results
> from the bad handling of union use.

 Subscribed, thank you.

> 
> ===
> Mark Millard
> markmi at dsl-only.net


___
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: HEAD/i386 r320212: three reproducible panics

[Oleg V. Nauman]

On Friday 30 June 2017 12:44:37 Hans Petter Selasky wrote:

 Hello Hans,

> On 06/30/17 11:01, Oleg V. Nauman wrote:
> > On Friday 23 June 2017 19:42:55 Oleg V. Nauman wrote:
> >>   a) Panic on shutdown:
> >> Fatal trap 1: privileged instruction fault while in kernel mode
> >> cpuid = 1; apic id = 01
> >> instruction pointer  = 0x20:0xc6be2023
> >> stack pointer  = 0x28:0xe13c39f4
> >> frame pointer  = 0x28:0xe13c3a20
> >> code segment  = base 0x0, limit 0xf, type 0x1b
> >> 
> >>   = DPL 0, pres 1, def32 1, gran 1
> >> 
> >> processor eflags  = interrupt enabled, resume, IOPL = 0
> >> current process  = 11 (swi1: netisr 0)
> >> trap number= 1
> >> panic: privileged instruction fault
> >> cpuid = 1
> >> time = 1498206262
> >> Uptime: 6m19s
> >> 
> >>   The trace is:
> >> __curthread () at ./machine/pcpu.h:225
> >> 225  __asm("movl %%fs:%1,%0" : "=r" (td)
> >> (kgdb) #0  __curthread () at ./machine/pcpu.h:225
> >> #1  doadump (textdump=-968633472) at ../../../kern/kern_shutdown.c:318
> >> #2  0xc06e88c4 in kern_reboot (howto=)
> >> 
> >>  at ../../../kern/kern_shutdown.c:386
> >> 
> >> #3  0xc06e8c5b in vpanic (fmt=,
> >> 
> >>  ap=0xe13c3874 "}\334\235\300H\254 \306\001")
> >>  at ../../../kern/kern_shutdown.c:779
> >> 
> >> #4  0xc06e8b1b in panic (fmt=0xc092e18e "%s")
> >> 
> >>  at ../../../kern/kern_shutdown.c:710
> >> 
> >> #5  0xc08eed21 in trap_fatal (frame=0xe13c39b4, eva=)
> >> 
> >>  at ../../../i386/i386/trap.c:978
> >> 
> >> #6  0xc08eea38 in trap (frame=)
> >> 
> >>  at ../../../i386/i386/trap.c:704
> >> 
> >> #7  
> >> #8  0xc6be2023 in ?? ()
> >> #9  0xc082ed53 in tcp_do_segment (m=, th=,
> >> 
> >>  so=, tp=, drop_hdrlen=,
> >>  tlen=, iptos=,
> >>  ti_locked= >>  0x1>)
> >> 
> >> at ../../../netinet/tcp_input.c:2444
> >> #10 0xc082c181 in tcp_input (mp=, offp=,
> >> 
> >>  proto=) at ../../../netinet/tcp_input.c:1191
> >> 
> >> #11 0xc0820878 in ip_input (m=0x0) at ../../../netinet/ip_input.c:823
> >> #12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=,
> >> 
> >>  proto=) at ../../../net/netisr.c:899
> >> 
> >> #13 swi_net (arg=) at ../../../net/netisr.c:946
> >> #14 0xc06bb3c5 in intr_event_execute_handlers (p=0x109, ie= >> out>)
> >> 
> >>  at ../../../kern/kern_intr.c:1336
> >> 
> >> #15 0xc06bb5f0 in ithread_execute_handlers (ie=,
> >> 
> >>  p=) at ../../../kern/kern_intr.c:1349
> >> 
> >> #16 ithread_loop (arg=0xc60e6d00) at ../../../kern/kern_intr.c:1430
> >> #17 0xc06b8a76 in fork_exit (callout=0xc06bb560 ,
> >> 
> >>  arg=, frame=)
> >>  at ../../../kern/kern_fork.c:1038
> >> 
> >> #18 
> >> (kgdb)
> >> 
> >   Interesting enough that panic triggered by named shutdown ( well, 'rndc
> > 
> > flush' is triggering this panic too )
> > 
> >   rndc calling isc__app_ctxrun function and finally panics the system:
> >  lib/isc/unix/app.c ---
> > 
> >  return (ISC_R_UNEXPECTED);
> >   
> >   }
> > 
> > #ifndef HAVE_UNIXWARE_SIGWAIT
> > 
> >   result = sigwait(, ); <--- panic
> >   if (result == 0) {
> > 
> > 
> > 
> > variables are set to:
> >   sset= {__bits = {16387, 0, 0, 0}}
> >   sig = 134533280
> 
> Here:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220358

 Subscribed && updated.

> 
> Try to turn off hyperthreading to get a more sensible panic.

 Done.

> 
> Migh-t look like an issue with 32-bit systems and iflib.

 I do not know if this related to iflib ; iflib functions were not mentioned 
in backtraces.

> 
> --HPS

-- 
Науман Олег

___
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: HEAD/i386 r320212: three reproducible panics

[Oleg V. Nauman]

On Friday 23 June 2017 19:42:55 Oleg V. Nauman wrote:
>  a) Panic on shutdown:
> 
> 
> Fatal trap 1: privileged instruction fault while in kernel mode
> cpuid = 1; apic id = 01
> instruction pointer  = 0x20:0xc6be2023
> stack pointer  = 0x28:0xe13c39f4
> frame pointer  = 0x28:0xe13c3a20
> code segment  = base 0x0, limit 0xf, type 0x1b
>  = DPL 0, pres 1, def32 1, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process  = 11 (swi1: netisr 0)
> trap number= 1
> panic: privileged instruction fault
> cpuid = 1
> time = 1498206262
> Uptime: 6m19s
> 
>  The trace is:
> 
> __curthread () at ./machine/pcpu.h:225
> 225  __asm("movl %%fs:%1,%0" : "=r" (td)
> (kgdb) #0  __curthread () at ./machine/pcpu.h:225
> #1  doadump (textdump=-968633472) at ../../../kern/kern_shutdown.c:318
> #2  0xc06e88c4 in kern_reboot (howto=)
> at ../../../kern/kern_shutdown.c:386
> #3  0xc06e8c5b in vpanic (fmt=,
> ap=0xe13c3874 "}\334\235\300H\254 \306\001")
> at ../../../kern/kern_shutdown.c:779
> #4  0xc06e8b1b in panic (fmt=0xc092e18e "%s")
> at ../../../kern/kern_shutdown.c:710
> #5  0xc08eed21 in trap_fatal (frame=0xe13c39b4, eva=)
> at ../../../i386/i386/trap.c:978
> #6  0xc08eea38 in trap (frame=)
> at ../../../i386/i386/trap.c:704
> #7  
> #8  0xc6be2023 in ?? ()
> #9  0xc082ed53 in tcp_do_segment (m=, th=,
> so=, tp=, drop_hdrlen=,
> tlen=, iptos=,
> ti_locked=)
> at ../../../netinet/tcp_input.c:2444
> #10 0xc082c181 in tcp_input (mp=, offp=,
> proto=) at ../../../netinet/tcp_input.c:1191
> #11 0xc0820878 in ip_input (m=0x0) at ../../../netinet/ip_input.c:823
> #12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=,
> proto=) at ../../../net/netisr.c:899
> #13 swi_net (arg=) at ../../../net/netisr.c:946
> #14 0xc06bb3c5 in intr_event_execute_handlers (p=0x109, ie=)
> at ../../../kern/kern_intr.c:1336
> #15 0xc06bb5f0 in ithread_execute_handlers (ie=,
> p=) at ../../../kern/kern_intr.c:1349
> #16 ithread_loop (arg=0xc60e6d00) at ../../../kern/kern_intr.c:1430
> #17 0xc06b8a76 in fork_exit (callout=0xc06bb560 ,
> arg=, frame=)
> at ../../../kern/kern_fork.c:1038
> #18 
> (kgdb)

 Interesting enough that panic triggered by named shutdown ( well, 'rndc 
flush' is triggering this panic too )

 rndc calling isc__app_ctxrun function and finally panics the system:

 lib/isc/unix/app.c ---
return (ISC_R_UNEXPECTED);
 }

#ifndef HAVE_UNIXWARE_SIGWAIT
 result = sigwait(, ); <--- panic
 if (result == 0) {


variables are set to:
 sset= {__bits = {16387, 0, 0, 0}}
 sig = 134533280


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

HEAD/i386 r320212: three reproducible panics

[Oleg V. Nauman]

 a) Panic on shutdown:


Fatal trap 1: privileged instruction fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer  = 0x20:0xc6be2023
stack pointer  = 0x28:0xe13c39f4
frame pointer  = 0x28:0xe13c3a20
code segment  = base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
processor eflags  = interrupt enabled, resume, IOPL = 0
current process  = 11 (swi1: netisr 0)
trap number= 1
panic: privileged instruction fault
cpuid = 1
time = 1498206262
Uptime: 6m19s

 The trace is:

__curthread () at ./machine/pcpu.h:225
225  __asm("movl %%fs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:225
#1  doadump (textdump=-968633472) at ../../../kern/kern_shutdown.c:318
#2  0xc06e88c4 in kern_reboot (howto=)
at ../../../kern/kern_shutdown.c:386
#3  0xc06e8c5b in vpanic (fmt=,
ap=0xe13c3874 "}\334\235\300H\254 \306\001")
at ../../../kern/kern_shutdown.c:779
#4  0xc06e8b1b in panic (fmt=0xc092e18e "%s")
at ../../../kern/kern_shutdown.c:710
#5  0xc08eed21 in trap_fatal (frame=0xe13c39b4, eva=)
at ../../../i386/i386/trap.c:978
#6  0xc08eea38 in trap (frame=)
at ../../../i386/i386/trap.c:704
#7  
#8  0xc6be2023 in ?? ()
#9  0xc082ed53 in tcp_do_segment (m=, th=,
so=, tp=, drop_hdrlen=,
tlen=, iptos=,
ti_locked=)
at ../../../netinet/tcp_input.c:2444
#10 0xc082c181 in tcp_input (mp=, offp=,
proto=) at ../../../netinet/tcp_input.c:1191
#11 0xc0820878 in ip_input (m=0x0) at ../../../netinet/ip_input.c:823
#12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=,
proto=) at ../../../net/netisr.c:899
#13 swi_net (arg=) at ../../../net/netisr.c:946
#14 0xc06bb3c5 in intr_event_execute_handlers (p=0x109, ie=)
at ../../../kern/kern_intr.c:1336
#15 0xc06bb5f0 in ithread_execute_handlers (ie=,
p=) at ../../../kern/kern_intr.c:1349
#16 ithread_loop (arg=0xc60e6d00) at ../../../kern/kern_intr.c:1430
#17 0xc06b8a76 in fork_exit (callout=0xc06bb560 ,
arg=, frame=)
at ../../../kern/kern_fork.c:1038
#18 
(kgdb)

b) Panic on accepting incoming SSH connection:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xa4c6f47f
fault code = supervisor read, page not present
instruction pointer  = 0x20:0xc6bd0418
stack pointer  = 0x28:0xea66b6a4
frame pointer  = 0x28:0xea66b6d0
code segment  = base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
processor eflags  = interrupt enabled, resume, IOPL = 0
current process  = 0 (ath0 taskq)
trap number= 12
panic: page fault
cpuid = 0
time = 1498233591
Uptime: 1m2s

 The trace is:

__curthread () at ./machine/pcpu.h:225
225  __asm("movl %%fs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:225
#1  doadump (textdump=-968633856) at ../../../kern/kern_shutdown.c:318
#2  0xc06e88c4 in kern_reboot (howto=)
at ../../../kern/kern_shutdown.c:386
#3  0xc06e8c5b in vpanic (fmt=,
ap=0xea66b504 "\353\334\235\300H)
at ../../../i386/i386/trap.c:978
#6  0xc08eee5d in trap_pfault (frame=0xea66b664, usermode=0,
eva=) at ../../../i386/i386/trap.c:786
#7  0xc08ee48e in trap (frame=)
at ../../../i386/i386/trap.c:512
#8  
#9  0xc6bd0418 in ?? ()
#10 0xc082ed53 in tcp_do_segment (m=, th=,
so=, tp=, drop_hdrlen=,
tlen=, iptos=,
ti_locked=)
at ../../../netinet/tcp_input.c:2444
#11 0xc082c181 in tcp_input (mp=, offp=,
proto=) at ../../../netinet/tcp_input.c:1191
#12 0xc0820878 in ip_input (m=0x0) at ../../../netinet/ip_input.c:823
#13 0xc07d55bb in netisr_dispatch_src (proto=,
source=, m=0xc6bd0418) at ../../../net/netisr.c:1120
#14 0xc07d5880 in netisr_dispatch (proto=1, m=0xc6cc6000)
at ../../../net/netisr.c:1211
#15 0xc07c7292 in ether_demux (ifp=0xc6860800, m=0x0)
at ../../../net/if_ethersubr.c:848
#16 0xc07c7f20 in ether_input_internal (ifp=0xc6860800, m=0xc6bd0418)
at ../../../net/if_ethersubr.c:637
#17 ether_nh_input (m=) at ../../../net/if_ethersubr.c:667
#18 0xc07d55bb in netisr_dispatch_src (proto=,
source=, m=0xc6bd0418) at ../../../net/netisr.c:1120
#19 0xc07d5880 in netisr_dispatch (proto=5, m=0xc6cc6000)
at ../../../net/netisr.c:1211
#20 0xc07c751a in ether_input (ifp=0xc6860800, m=0x0)
at ../../../net/if_ethersubr.c:757
#21 0xc07efc2e in ieee80211_deliver_data (vap=0xc6a97000, ni=,
m=0xc6cc6000) at ../../../net80211/ieee80211_input.c:291
#22 0xc08070e5 in sta_input (ni=, m=0xc6cc6000,
rxs=, rssi=, nf=)
at ../../../net80211/ieee80211_sta.c:891
#23 0xc07ef824 in ieee80211_input_mimo (ni=0x0, m=)
at ../../../net80211/ieee80211_input.c:99
#24 0xc053439a in ath_rx_pkt (sc=, rs=,
status=, tsf=, nf=,
qtype=, bf=, m=)
at ../../../dev/ath/if_ath_rx.c:950
#25 0xc05350f5 in ath_rx_proc (sc=0xc63f9000, resched=1)
at ../../../dev/ath/if_ath_rx.c:1150
#26 0xc07359cc in taskqueue_run_locked (queue=0xc63d3b80)
at ../../../kern/subr_taskqueue.c:454
#27 0xc07368b7 in 

Re: INO64 Effecting Firefox

[Oleg V. Nauman]

On Sunday 28 May 2017 18:09:19 O. Hartmann wrote:
> Am Sun, 28 May 2017 08:54:35 -0700
> 
> Pete Wright  schrieb:
> > Hi all,
> > 
> > I can't imagine that this is related to INO64, but since upgrading my
> > world and kernel on drm-next (which merged upstream CURRENT as of May 27
> > which should include the ino64 work) I am having segfaults running
> > firefox.  Previous to this firefox was very stable for work/personal
> > daily use.
> > 
> > The error I'm seeing is:
> > Full message: TypeError: malformed UTF-8 character sequence at offset 0
> > 
> > Firefox does start and I can load a page or two before it sefaults.
> > 
> > The full console output is here:
> > 
> > https://gist.github.com/anonymous/555202b1452503ad9e26750168f87d5f
> > 
> > 
> > Posting this here in the off chance that it's either related to ino64,
> > or some other recent change has caused this problem.
> > 
> > Cheers!
> > 
> > -pete
> 
> I see similar problems. Out of the blue, firefox crashes.
> But in my case, firefox is "old", since it doesn't compile with
> WITH_LLD_IS_LD due to a very strange error (Bug 218808).
> 
> The binary I run und CURRENT (FreeBSD 12.0-CURRENT #8 r319001: Sun May 28
> 00:21:16 CEST 2017 amd64, WITH_LLD_IS_LD=yes) if as of
> 
> firefox-53.0_2,1
> Name   : firefox
> Version: 53.0_2,1
> Installed on   : Sun Apr 16 10:17:14 2017 CEST
> Origin : www/firefox
> Architecture   : FreeBSD:12:amd64
> 
> I got a kind of relief (means: the frequence of crashes is reduced) when
> starting to rebuild all ports again (I'm staying with make and portmaster)
> to meet ABI requirements after ino64 has been introduced.
> 
> Another strange behaviour is: firefox crashes very likely very often when
> started. Once it has run a while, I can consider it "stable". It doen not
> crash then.

 Please try to rebuild firefox. It helps me today with firefox-esr segfaulting 
on my desktop running 12.0-CURRENT r318856
 From my limited understanding of stacktraces it was related to libthr 
changes.

___
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: Buildworld fails if WITHOUT_INET6=YES defined

[Oleg V. Nauman]

On Thursday 02 March 2017 22:40:05 Alex Deiter wrote:
> Hello,

 Hello,

> 
> Please apply patch from upstream:
> 
> https://github.com/the-tcpdump-group/libpcap/pull/541
> 
> Fix compilation if INET6 isn't defined.
> Addresses GitHub issue #541, but differently from the pull request (it
> defines gen_gateway() with a function prototype rather than using a
> pre-prototype-style definition).
> 
> https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390df7
> 448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2

 I can confirm that it fixes the issue.

> 
> Thank you!
> 
> Alex Deiter
> alex.dei...@gmail.com
> 
> > On 18 Feb 2017, at 00:09, Bryan Drewery <bdrew...@freebsd.org> wrote:
> > 
> > On 2/17/2017 1:03 PM, Bryan Drewery wrote:
> >> On 2/16/2017 10:07 AM, Ngie Cooper (yaneurabeya) wrote:
> >>>> On Feb 16, 2017, at 07:30, Oleg V. Nauman <o...@opentransfer.com>
> >>>> wrote:
> >>>> 
> >>>> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
> >>>> B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=core2  -DHAVE_CONFIG_H
> >>>> -
> >>>> I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
> >>>> D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
> >>>> DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
> >>>> MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99
> >>>> -fstack-protector-strong -Wno- pointer-sign -Wno-empty-body
> >>>> -Wno-string-plus-int -Wno-unused-const-variable -
> >>>> Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> >>>> -Wno- unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> >>>> -Wno-switch - Wno-switch-enum -Wno-knr-promoted-parameter
> >>>> -Wno-parentheses  -Qunused- arguments  -c
> >>>> /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
> >>>> cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
> >>>> B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=core2  -DHAVE_CONFIG_H
> >>>> -
> >>>> I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
> >>>> D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
> >>>> DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
> >>>> MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong
> >>>> -Wno-
> >>>> pointer-sign -Wno-empty-body -Wno-string-plus-int
> >>>> -Wno-unused-const-variable - Wno-tautological-compare
> >>>> -Wno-unused-value -Wno-parentheses-equality -Wno- unused-function
> >>>> -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
> >>>> Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
> >>>> -Qunused- arguments  -c /usr/src/contrib/libpcap/gencode.c -o
> >>>> gencode.o
> >>>> /usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai'
> >>>> in
> >>>> 'struct _compiler_state'
> >>>> 
> >>>>   cstate.ai = NULL;
> >>>>   ~~ ^
> >>>> 
> >>>> /usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared
> >>>> identifier 'cstate'
> >>>> 
> >>>>   bpf_error(cstate, "direction applied to 'gateway'");
> >>>>   
> >>>> ^
> >>>> 
> >>>> /usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared
> >>>> identifier 'cstate'
> >>>> 
> >>>>   switch (cstate->linktype) {
> >>>>   
> >>>>   ^
> >>>> 
> >>>> /usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared
> >>>> identifier 'cstate'
> >>>> 
> >>>>   b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR,
> >>>> 
> >>>> Q_HOST);
> >>>> 
> >>>> ^
> >>>> 
> >>>> /usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared
> >>>> identifier 'cstate'
> >>>> 
> >>>>   tmp = gen_host(cstate, **alist++, 0x,
> >>>>   proto,
> >>>> 
> >>>&g

Buildworld fails if WITHOUT_INET6=YES defined

[Oleg V. Nauman]

cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=core2  -DHAVE_CONFIG_H -
I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
MF.depend.fad-getad.o -MTfad-getad.o -std=gnu99 -fstack-protector-strong -Wno-
pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -
Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
arguments  -c /usr/src/contrib/libpcap/fad-getad.c -o fad-getad.o
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=core2  -DHAVE_CONFIG_H -
I/usr/src/lib/libpcap -I/usr/obj/usr/src/lib/libpcap -
D_U_="__attribute__((unused))" -DHAVE_SNPRINTF -DHAVE_VSNPRINTF -
DBUILDING_PCAP -DHAVE_NET_PFVAR_H -I/usr/src/contrib/libpcap -MD  -
MF.depend.gencode.o -MTgencode.o -std=gnu99 -fstack-protector-strong -Wno-
pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -
Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-
unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -
Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-
arguments  -c /usr/src/contrib/libpcap/gencode.c -o gencode.o
/usr/src/contrib/libpcap/gencode.c:695:9: error: no member named 'ai' in 
'struct _compiler_state'
cstate.ai = NULL;
~~ ^
/usr/src/contrib/libpcap/gencode.c:4916:13: error: use of undeclared 
identifier 'cstate'
bpf_error(cstate, "direction applied to 'gateway'");
  ^
/usr/src/contrib/libpcap/gencode.c:4923:11: error: use of undeclared 
identifier 'cstate'
switch (cstate->linktype) {
^
/usr/src/contrib/libpcap/gencode.c:4961:17: error: use of undeclared 
identifier 'cstate'
b1 = gen_host(cstate, **alist++, 0x, proto, Q_OR, 
Q_HOST);
  ^
/usr/src/contrib/libpcap/gencode.c:4963:19: error: use of undeclared 
identifier 'cstate'
tmp = gen_host(cstate, **alist++, 0x, proto, 
Q_OR,
   ^
/usr/src/contrib/libpcap/gencode.c:4972:12: error: use of undeclared 
identifier 'cstate'
bpf_error(cstate, "illegal modifier of 'gateway'");
  ^
6 errors generated.
*** Error code 1

Stop.
make[5]: stopped in /usr/src/lib/libpcap
*** Error code 1


___
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: 'Protocol not supported' on linux socket call ( r313313 amd64 )

[Oleg V. Nauman]

On Wednesday 08 February 2017 09:06:43 Conrad Meyer wrote:
> Hi Oleg,

 Hello Conrad,

> 
> It seems likely it is related to r313284.

 I have reverted both r313285 and r313284, it makes linux socket happy.
skype is working now.

Thank you!

> 
> Best,
> Conrad
> 
> On Wed, Feb 8, 2017 at 7:44 AM, Oleg V. Nauman <o...@opentransfer.com> 
wrote:
> >  After upgrading of current on amd64 box to r313313 I noticed that skype
> >  has
> > 
> > stopped working.
> > 
> >  Below is the end of 'truss' output for skype:
> > 36723: linux_socketcall(1,{ LINUX_SOCKET, 0x0 }) ERR#-93 'Protocol not
> > supported'
> > 36723: write(6,"@",1) = 1 (0x1)
> > 36723: close(6)= 0 (0x0)
> > 36723: close(5)= 0 (0x0)
> > 36723: linux_rt_sigaction(0x11,0xbaf8,0xba6c,0x8) = 0 (0x0)
> > 36723: linux_exit_group(0x1)
> > 36723: process exit, rval = 1
> > 
> >  My second current box ( r313090 i386 ) runs skype successfully.
> > 
> > ___
> > 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"

___
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: 'Protocol not supported' on linux socket call ( r313313 amd64 )

[Oleg V. Nauman]

On Wednesday 08 February 2017 09:06:43 Conrad Meyer wrote:
> Hi Oleg,
> 
> It seems likely it is related to r313284.

 Kernel compilation fails 

cc  -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32 -march=nehalem  -fno-strict-
aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -
DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/src/sys/amd64/compile/oleg3/opt_global.h -I. -I/usr/src/sys -fno-common -
g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -
I/usr/src/sys/amd64/compile/oleg3  -MD  -MF.depend.linux32_dummy.o -
MTlinux32_dummy.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 
/usr/src/sys/modules/linux/../../amd64/linux32/linux32_dummy.c -o 
linux32_dummy.o
/usr/src/sys/modules/linux/../../amd64/linux32/linux32_dummy.c:117:1: error: 
declaration of
  'struct linux_rt_tsigqueueinfo_args' will not be visible outside of this 
function
  [-Werror,-Wvisibility]
DUMMY(rt_tsigqueueinfo);
^
/usr/src/sys/compat/linux/linux_util.h:79:39: note: expanded from macro 
'DUMMY'
linux_ ## s(struct thread *td, struct linux_ ## s ## _args *args)   \
  ^
:162:1: note: expanded from here
linux_rt_tsigqueueinfo_args
^
/usr/src/sys/modules/linux/../../amd64/linux32/linux32_dummy.c:117:1: error: 
no previous
  prototype for function 'linux_rt_tsigqueueinfo' [-Werror,-Wmissing-
prototypes]
/usr/src/sys/compat/linux/linux_util.h:78:13: note: expanded from macro 
'DUMMY'
int \
^
:160:1: note: expanded from here
linux_rt_tsigqueueinfo
^
2 errors generated.
*** Error code 1

 It is sources revision 313313 with reverted 313284.


> 
> Best,
> Conrad
> 
> On Wed, Feb 8, 2017 at 7:44 AM, Oleg V. Nauman <o...@opentransfer.com> 
wrote:
> >  After upgrading of current on amd64 box to r313313 I noticed that skype
> >  has
> > 
> > stopped working.
> > 
> >  Below is the end of 'truss' output for skype:
> > 36723: linux_socketcall(1,{ LINUX_SOCKET, 0x0 }) ERR#-93 'Protocol not
> > supported'
> > 36723: write(6,"@",1) = 1 (0x1)
> > 36723: close(6)= 0 (0x0)
> > 36723: close(5)= 0 (0x0)
> > 36723: linux_rt_sigaction(0x11,0xbaf8,0xba6c,0x8) = 0 (0x0)
> > 36723: linux_exit_group(0x1)
> > 36723: process exit, rval = 1
> > 
> >  My second current box ( r313090 i386 ) runs skype successfully.
> > 
> > ___
> > 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"

___
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: 'Protocol not supported' on linux socket call ( r313313 amd64 )

[Oleg V. Nauman]

On Wednesday 08 February 2017 08:39:50 Ngie Cooper wrote:
> > On Feb 8, 2017, at 07:44, Oleg V. Nauman <o...@opentransfer.com> wrote:
> > 
> > After upgrading of current on amd64 box to r313313 I noticed that skype
> > has
> > stopped working.
> > Below is the end of 'truss' output for skype:
> > 
> > 36723: linux_socketcall(1,{ LINUX_SOCKET, 0x0 }) ERR#-93 'Protocol not
> > supported'
> > 36723: write(6,"@",1) = 1 (0x1)
> > 36723: close(6)= 0 (0x0)
> > 36723: close(5)= 0 (0x0)
> > 36723: linux_rt_sigaction(0x11,0xbaf8,0xba6c,0x8) = 0 (0x0)
> > 36723: linux_exit_group(0x1)
> > 36723: process exit, rval = 1
> > 
> > My second current box ( r313090 i386 ) runs skype successfully.
> 
> Hi,
> Please try reverting r312988.

 skype still fails, unfortunately.

 2024: linux_socketcall(1,{ LINUX_SOCKET, 0x0 }) ERR#-93 'Protocol not 
supported'
 2024: write(6,"@",1) = 1 (0x1)
 2024: close(6)= 0 (0x0)
 2024: close(5)= 0 (0x0)
 2024: linux_rt_sigaction(0x11,0xbaf8,0xba6c,0x8) = 0 (0x0)
 2024: linux_exit_group(0x1)
 2024: process exit, rval = 1




> Thanks!
> -Ngie

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

'Protocol not supported' on linux socket call ( r313313 amd64 )

[Oleg V. Nauman]

 After upgrading of current on amd64 box to r313313 I noticed that skype has 
stopped working.
 Below is the end of 'truss' output for skype:

36723: linux_socketcall(1,{ LINUX_SOCKET, 0x0 }) ERR#-93 'Protocol not 
supported'
36723: write(6,"@",1) = 1 (0x1)
36723: close(6)= 0 (0x0)
36723: close(5)= 0 (0x0)
36723: linux_rt_sigaction(0x11,0xbaf8,0xba6c,0x8) = 0 (0x0)
36723: linux_exit_group(0x1)
36723: process exit, rval = 1

 My second current box ( r313090 i386 ) runs skype successfully.
___
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: 'make buildworld' failure

[Oleg V. Nauman]

On Thursday 05 January 2017 12:26:58 Hiroki Sato wrote:
> hiren panchasara <hi...@strugglingcoder.info> wrote
>   in <20170104180954.gv17...@strugglingcoder.info>:
> 
> hi> + hrs@
> hi> On 01/04/17 at 12:43P, Oleg V. Nauman wrote:
> hi> > ===> usr.sbin/inetd (all)
[skip]
> hi> > 4 errors generated.
> hi> > *** Error code 1
> hi> >
> hi> >
> hi> >
> hi> > root@asus:/usr/src # svnlite info|grep Rev:
> hi> > Last Changed Rev: 311250
> hi> >
> hi> > My current system revision is r310560
> hi> >
> hi> >  It possible that it is due to WITHOUT_INET6 defined in /etc/src.conf
> hi>
> hi> r310921 could be it.
> 
>  Thank you for the report and sorry for the breakage.  Should be fixed
>  at r311354.

 Yes if fixes buildworld on i386 at least.

Thank you!

> 
> -- Hiroki


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

'make buildworld' failure

[Oleg V. Nauman]

===> usr.sbin/inetd (all)
cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -
B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -march=nehalem  -DLOGIN_CAP -DIPSEC -
g -MD  -MF.depend.inetd.o -MTinetd.o -std=gnu99 -fstack-protector-strong -
Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -
Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -
Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-
variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  -Qunused-
arguments  -c /usr/src/usr.sbin/inetd/inetd.c -o inetd.o
/usr/src/usr.sbin/inetd/inetd.c:319:28: error: implicit declaration of 
function 'satosin6' is
  invalid in C99 [-Werror,-Wimplicit-function-declaration]
IN6_IS_ADDR_V4MAPPED((sa)->sin6_addr))
  ^
/usr/src/usr.sbin/inetd/inetd.c:319:42: error: member reference type 'int' is 
not a pointer
IN6_IS_ADDR_V4MAPPED((sa)->sin6_addr))
    ^
/usr/obj/usr/src/tmp/usr/include/netinet6/in6.h:266:4: note: expanded from 
macro
  'IN6_IS_ADDR_V4MAPPED'
((a)->__u6_addr.__u6_addr32[0] == 0 &&  \
  ^
/usr/src/usr.sbin/inetd/inetd.c:319:42: error: member reference type 'int' is 
not a pointer
IN6_IS_ADDR_V4MAPPED((sa)->sin6_addr))
    ^
/usr/obj/usr/src/tmp/usr/include/netinet6/in6.h:267:4: note: expanded from 
macro
  'IN6_IS_ADDR_V4MAPPED'
 (a)->__u6_addr.__u6_addr32[1] == 0 &&  \
  ^
/usr/src/usr.sbin/inetd/inetd.c:319:42: error: member reference type 'int' is 
not a pointer
IN6_IS_ADDR_V4MAPPED((sa)->sin6_addr))
    ^
/usr/obj/usr/src/tmp/usr/include/netinet6/in6.h:268:4: note: expanded from 
macro
  'IN6_IS_ADDR_V4MAPPED'
 (a)->__u6_addr.__u6_addr32[2] == ntohl(0x))
  ^
4 errors generated.
*** Error code 1



root@asus:/usr/src # svnlite info|grep Rev:
Last Changed Rev: 311250

My current system revision is r310560

 It possible that it is due to WITHOUT_INET6 defined in /etc/src.conf


___
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: CURRENT: frequent crashes if mpd5 is running

[Oleg V. Nauman]

On Thursday 14 July 2016 14:38:15 Allan Jude wrote:
> On 2016-07-14 13:13, Oleg V. Nauman wrote:
> >  I'm experiencing frequent CURRENT ( 12.0-CURRENT r302535 amd64 ) crashes
> > 
> > triggered by mpd5:
> > 
> > Fatal trap 12: page fault while in kernel mode
[skip]
> 
> There is a patch for this issue:
> 
> https://reviews.freebsd.org/D7209
> 
> You might try seeing if it solves your problem, and reporting that to
> the author

 It was stable during 24 hours after applying this patch, thank you.
I have updated a patch review with comment that it solves issue for me.

Thank you

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

CURRENT: frequent crashes if mpd5 is running

[Oleg V. Nauman]

 I'm experiencing frequent CURRENT ( 12.0-CURRENT r302535 amd64 ) crashes 
triggered by mpd5:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x10
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x814f6162
stack pointer   = 0x28:0xfe011b06d640
frame pointer   = 0x28:0xfe011b06d670
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 = 901 (mpd5)
trap number = 12
panic: page fault
cpuid = 0

#0  doadump (textdump=) at pcpu.h:221
221 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=) at pcpu.h:221
#1  0x80749169 in kern_reboot (howto=260)
at ../../../kern/kern_shutdown.c:366
#2  0x807496e1 in vpanic (fmt=,
ap=) at ../../../kern/kern_shutdown.c:759
#3  0x80749553 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:690
#4  0x80a5aca1 in trap_fatal (frame=0xfe011b06d590, eva=16)
at ../../../amd64/amd64/trap.c:841
#5  0x80a5af51 in trap_pfault (frame=0x0, usermode=0)
at ../../../amd64/amd64/trap.c:716
#6  0x80a5a430 in trap (frame=0xfe011b06d590)
at ../../../amd64/amd64/trap.c:442
#7  0x80a3e161 in calltrap () at ../../../amd64/amd64/exception.S:236
#8  0x814f6162 in ng_uncallout (c=0xf80004842460,
node=0xf80004c79a00)
at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3815
#9  0x8151bbab in ng_pptpgre_disconnect (hook=)
at 
/usr/src/sys/modules/netgraph/pptpgre/../../../netgraph/ng_pptpgre.c:966
#10 0x814f2928 in ng_destroy_hook (hook=0xf8000487ad80)
at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1219
#11 0x814f2635 in ng_rmnode (node=,
dummy1=, dummy2=,
dummy3=)
at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:744
#12 0x814f4832 in ng_apply_item (node=0xf80004c79a00,
item=0xf80004e72600, rw=1)
at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2523
#13 0x814f41a3 in ng_snd_item (item=,
flags=)
at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2320
#14 0x814eec4e in ngc_send (so=,
flags=, m=,
addr=, control=,
td=)
at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:338
#15 0x807dee17 in sosend_generic (so=,
addr=, uio=,
top=, control=,
flags=, td=)
at ../../../kern/uipc_socket.c:1359
#16 0x807e66b8 in kern_sendit (td=,
s=, mp=, flags=0, control=0x0,
segflg=) at ../../../kern/uipc_syscalls.c:848
#17 0x807e6abf in sendit (td=0xf800047caa00,
s=, mp=0xfe011b06da60,
flags=) at ../../../kern/uipc_syscalls.c:775
#18 0x807e690d in sys_sendto (td=0x0, uap=)
at ../../../kern/uipc_syscalls.c:899
#19 0x80a5b618 in amd64_syscall (td=, traced=0)
at subr_syscall.c:135
#20 0x80a3e44b in Xfast_syscall ()
at ../../../amd64/amd64/exception.S:396
#21 0x0008025d284a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal

___
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: ATA? related trouble with r300299

[Oleg V. Nauman]

On Tuesday 24 May 2016 16:17:33 you wrote:
> Okay, I've got a basic idea of what may be going on.  The resets that are
> getting sent are triggering another probe, which then triggers a reset,
> which triggers a probe...and so on.
> 
> So here is another patch that should work for you:
> 
> https://people.freebsd.org/~ken/cam_smr_ada_patch.20160524.2.txt
> 
> I have commented out the quirk for this drive, and the driver will now only
> start the SMR probe on drives that claim to be SMR-capable.  So, for the
> vast majority of drives out there right now, it won't even start the extra
> probe steps.

 It fixes this issue. I was able to boot with your latest patch.

Thank you!

> 
> Ken

___
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: ATA? related trouble with r300299

[Oleg V. Nauman]

On Tuesday 24 May 2016 13:13:29 Kenneth D. Merry wrote:
> On Tue, May 24, 2016 at 18:21:19 +0300, Oleg V. Nauman wrote:
> > On Tuesday 24 May 2016 10:02:09 you wrote:
> > > On Tue, May 24, 2016 at 16:38:40 +0300, Oleg V. Nauman wrote:
> > > > On Tuesday 24 May 2016 09:21:17 Kenneth D. Merry wrote:
> > > > > On Tue, May 24, 2016 at 08:04:21 +0300, Oleg V. Nauman wrote:
> > > > > > On Monday 23 May 2016 19:08:16 Kenneth D. Merry wrote:
> > > > > > > On Tue, May 24, 2016 at 00:59:34 +0300, Oleg V. Nauman wrote:
> > > > > > > > On Monday 23 May 2016 17:30:45 you wrote:
> > > > > > > > > On Tue, May 24, 2016 at 00:15:25 +0300, Oleg V. Nauman 
wrote:
> > > > > > > > > > On Monday 23 May 2016 17:11:34 Kenneth D. Merry wrote:
> > > > > > > > > > > On Tue, May 24, 2016 at 00:05:49 +0300, Oleg V. Nauman
> > 
> > wrote:
> > > > > > > > > > > > On Monday 23 May 2016 16:53:55 Kenneth D. Merry wrote:
> > > > > > > > > > > > > On Mon, May 23, 2016 at 23:21:32 +0300, Oleg V.
> > > > > > > > > > > > > Nauman
> > > > 
> > > > wrote:
> > > > > > > > > > > > > > On Monday 23 May 2016 15:25:39 Kenneth D. Merry 
wrote:
> > > > > > > > > > > > > > > On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V.
> > > > > > > > > > > > > > > Nauman
> > > > > > 
> > > > > > wrote:
> > > > > > > > > > > > > > > >  I have faced the issue with fresh CURRENT
> > > > > > > > > > > > > > > >  stopped
> > > > > > > > > > > > > > > >  to
> > > > > > > > > > > > > > > >  boot
> > > > > > > > > > > > > > > >  on
> > > > > > > > > > > > > > > >  my
> > > > > > > > > > > > > > > >  old
> > > > > > > > > > > > > > > >  desktop
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > after update to r300299
> > > > > > > > > > > > > > > > Verbose boot shows the endless cycle of
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > ata2: SATA reset: ports status=0x05
> > > > > > > > > > > > > > > > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > > > > > > > > > > > > > > > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > > > > > > > > > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > > > > > > > > > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > > > > > > > > > > > > > > > messages logged to console.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Below is the relevant portion of ATA
> > > > > > > > > > > > > > > > controller/devices
> > > > > > > > > > > > > > > > probed/attached
> > > > > > > > > > > > > > > > during the boot:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > atapci0:  port
> > > > > > > > > > > > > > > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xf
> > > > > > > > > > > > > > > > faf
> > > > > > > > > > > > > > > > at
> > > > > > > > > > > > > > > > device
> > > > > > > > > > > > > > > > 31.1
> > > > > > > > > > > > > > > > on
> > > > > > > > > > > > > > > > pci0
> > > > >

Re: ATA? related trouble with r300299

[Oleg V. Nauman]

On Tuesday 24 May 2016 10:02:09 you wrote:
> On Tue, May 24, 2016 at 16:38:40 +0300, Oleg V. Nauman wrote:
> > On Tuesday 24 May 2016 09:21:17 Kenneth D. Merry wrote:
> > > On Tue, May 24, 2016 at 08:04:21 +0300, Oleg V. Nauman wrote:
> > > > On Monday 23 May 2016 19:08:16 Kenneth D. Merry wrote:
> > > > > On Tue, May 24, 2016 at 00:59:34 +0300, Oleg V. Nauman wrote:
> > > > > > On Monday 23 May 2016 17:30:45 you wrote:
> > > > > > > On Tue, May 24, 2016 at 00:15:25 +0300, Oleg V. Nauman wrote:
> > > > > > > > On Monday 23 May 2016 17:11:34 Kenneth D. Merry wrote:
> > > > > > > > > On Tue, May 24, 2016 at 00:05:49 +0300, Oleg V. Nauman 
wrote:
> > > > > > > > > > On Monday 23 May 2016 16:53:55 Kenneth D. Merry wrote:
> > > > > > > > > > > On Mon, May 23, 2016 at 23:21:32 +0300, Oleg V. Nauman
> > 
> > wrote:
> > > > > > > > > > > > On Monday 23 May 2016 15:25:39 Kenneth D. Merry wrote:
> > > > > > > > > > > > > On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V.
> > > > > > > > > > > > > Nauman
> > > > 
> > > > wrote:
> > > > > > > > > > > > > >  I have faced the issue with fresh CURRENT stopped
> > > > > > > > > > > > > >  to
> > > > > > > > > > > > > >  boot
> > > > > > > > > > > > > >  on
> > > > > > > > > > > > > >  my
> > > > > > > > > > > > > >  old
> > > > > > > > > > > > > >  desktop
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > after update to r300299
> > > > > > > > > > > > > > Verbose boot shows the endless cycle of
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ata2: SATA reset: ports status=0x05
> > > > > > > > > > > > > > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > > > > > > > > > > > > > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > > > > > > > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > > > > > > > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > > > > > > > > > > > > > messages logged to console.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Below is the relevant portion of ATA
> > > > > > > > > > > > > > controller/devices
> > > > > > > > > > > > > > probed/attached
> > > > > > > > > > > > > > during the boot:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > atapci0:  port
> > > > > > > > > > > > > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf
> > > > > > > > > > > > > > at
> > > > > > > > > > > > > > device
> > > > > > > > > > > > > > 31.1
> > > > > > > > > > > > > > on
> > > > > > > > > > > > > > pci0
> > > > > > > > > > > > > > ata0:  at channel 0 on atapci0
> > > > > > > > > > > > > > atapci1:  port
> > > > > > > > > > > > > > 0xd080-0xd087,
> > > > > > > > > > > > > > 0xd000-0xd003,
> > > > > > > > > > > > > > 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19
> > > > > > > > > > > > > > at
> > > > > > > > > > > > > > device
> > > > > > > > > > > > > > 31.2 on
> > > > > > > > > > > > > > pci0
> > > > > > > > > > > > > > ata2:  at channel 0 on atapci1
> > > > > > > > > > > >

Re: ATA? related trouble with r300299

[Oleg V. Nauman]

On Tuesday 24 May 2016 09:21:17 Kenneth D. Merry wrote:
> On Tue, May 24, 2016 at 08:04:21 +0300, Oleg V. Nauman wrote:
> > On Monday 23 May 2016 19:08:16 Kenneth D. Merry wrote:
> > > On Tue, May 24, 2016 at 00:59:34 +0300, Oleg V. Nauman wrote:
> > > > On Monday 23 May 2016 17:30:45 you wrote:
> > > > > On Tue, May 24, 2016 at 00:15:25 +0300, Oleg V. Nauman wrote:
> > > > > > On Monday 23 May 2016 17:11:34 Kenneth D. Merry wrote:
> > > > > > > On Tue, May 24, 2016 at 00:05:49 +0300, Oleg V. Nauman wrote:
> > > > > > > > On Monday 23 May 2016 16:53:55 Kenneth D. Merry wrote:
> > > > > > > > > On Mon, May 23, 2016 at 23:21:32 +0300, Oleg V. Nauman 
wrote:
> > > > > > > > > > On Monday 23 May 2016 15:25:39 Kenneth D. Merry wrote:
> > > > > > > > > > > On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V. Nauman
> > 
> > wrote:
> > > > > > > > > > > >  I have faced the issue with fresh CURRENT stopped to
> > > > > > > > > > > >  boot
> > > > > > > > > > > >  on
> > > > > > > > > > > >  my
> > > > > > > > > > > >  old
> > > > > > > > > > > >  desktop
> > > > > > > > > > > > 
> > > > > > > > > > > > after update to r300299
> > > > > > > > > > > > Verbose boot shows the endless cycle of
> > > > > > > > > > > > 
> > > > > > > > > > > > ata2: SATA reset: ports status=0x05
> > > > > > > > > > > > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > > > > > > > > > > > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > > > > > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > > > > > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > > > > > > > > > > > messages logged to console.
> > > > > > > > > > > > 
> > > > > > > > > > > > Below is the relevant portion of ATA
> > > > > > > > > > > > controller/devices
> > > > > > > > > > > > probed/attached
> > > > > > > > > > > > during the boot:
> > > > > > > > > > > > 
> > > > > > > > > > > > atapci0:  port
> > > > > > > > > > > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at
> > > > > > > > > > > > device
> > > > > > > > > > > > 31.1
> > > > > > > > > > > > on
> > > > > > > > > > > > pci0
> > > > > > > > > > > > ata0:  at channel 0 on atapci0
> > > > > > > > > > > > atapci1:  port
> > > > > > > > > > > > 0xd080-0xd087,
> > > > > > > > > > > > 0xd000-0xd003,
> > > > > > > > > > > > 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at
> > > > > > > > > > > > device
> > > > > > > > > > > > 31.2 on
> > > > > > > > > > > > pci0
> > > > > > > > > > > > ata2:  at channel 0 on atapci1
> > > > > > > > > > > > ata3:  at channel 1 on atapci1
> > > > > > > > > > > > ada0 at ata2 bus 0 scbus1 target 0 lun 0
> > > > > > > > > > > > ada0:  ATA-7 SATA 2.x device
> > > > > > > > > > > > ada1 at ata2 bus 0 scbus1 target 1 lun 0
> > > > > > > > > > > > ada1:  ATA8-ACS SATA 3.x
> > > > > > > > > > > > device
> > > > > > > > > > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0
> > > > > > > > > > > > cd0: <_NEC DVD_RW ND-3570A 1.11> Removable CD-ROM SCSI
> > > > > > > > > > > > device
> > > > > > > > > > > 
> > > > > > > > > > > I'm not entirely sure what is causing the problem wi

Re: ATA? related trouble with r300299

[Oleg V. Nauman]

On Tuesday 24 May 2016 06:42:18 you wrote:
> Not sure, but maybe related.
> I had 5 old ata systems running, doing ntp and dns cache (running since 5.0
> lifted over time to 10.x) The systems showed no smart or any other defects.
> Last year they began stop working with strange messages like adaX not found
> where in fstab still was ataX (back from 5.x) ... Meanwhile the systems are
> replaced and thrown away.
> If from interest i can look for old logs.

 I have performed device entries name transition when compatibility shims were 
removed in CURRENT.

 Thank you.


> 
> 
> On 23/05/2016, 21:25 "Kenneth D. Merry" <k...@freebsd.org> wrote:
> 
> On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V. Nauman wrote:
> > I have faced the issue with fresh CURRENT stopped to boot on my old
> > desktop
> > after update to r300299
> > Verbose boot shows the endless cycle of
> > 
> > ata2: SATA reset: ports status=0x05
> > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > messages logged to console.
> > 
> > Below is the relevant portion of ATA controller/devices probed/attached
> > during the boot:
> > 
> > atapci0:  port
> > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
> > ata0:  at channel 0 on atapci0
> > atapci1:  port 0xd080-0xd087,
> > 0xd000-0xd003,
> > 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at device 31.2 on pci0
> > ata2:  at channel 0 on atapci1
> > ata3:  at channel 1 on atapci1
> > ada0 at ata2 bus 0 scbus1 target 0 lun 0
> > ada0:  ATA-7 SATA 2.x device
> > ada1 at ata2 bus 0 scbus1 target 1 lun 0
> > ada1:  ATA8-ACS SATA 3.x device
> > cd0 at ata0 bus 0 scbus0 target 0 lun 0
> > cd0: <_NEC DVD_RW ND-3570A 1.11> Removable CD-ROM SCSI device
> 
> I'm not entirely sure what is causing the problem with your system, but
> hopefully we can narrow it down a bit.
> 
> There is a bug that came in with my SMR changes in revision 300207 that
> broke the quirk functionality in the ada(4) driver. I don't think that is
> the problem you're seeing, though.
> 
> Can you try out this patch:
> 
> https://people.freebsd.org/~ken/cam_smr_ada_patch.20160523.1.txt
> 
> In /boot/loader.conf, put the following:
> 
> kern.cam.ada.0.quirks="0x04"
> kern.cam.ada.1.quirks="0x04"
> 
> If you're able to boot with those quirk entries in the loader.conf, try
> taking one of them out, and reboot. If that works, try taking the other
> one out and reboot.
> 
> What I'm trying to figure out here is where the problem lies:
> 
> 1. The bug with the ada(4) driver (in where it loaded the quirks).
> 2. The extra probe steps in the ada(4) driver might be causing a problem
> with ada0 (Samsung drive).
> 3. The extra probe steps in the ada(4) driver might be causing a problem
> with ada1 (Seagate drive).
> 4. Something else.
> 
> So, if you can try the patch and try to eliminate a few possibilities, we
> may be able to narrow it down.
> 
> Thanks,
> 
> Ken
> --
> Kenneth Merry
> k...@freebsd.org
> ___
> 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"

___
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: ATA? related trouble with r300299

[Oleg V. Nauman]

On Monday 23 May 2016 19:08:16 Kenneth D. Merry wrote:
> On Tue, May 24, 2016 at 00:59:34 +0300, Oleg V. Nauman wrote:
> > On Monday 23 May 2016 17:30:45 you wrote:
> > > On Tue, May 24, 2016 at 00:15:25 +0300, Oleg V. Nauman wrote:
> > > > On Monday 23 May 2016 17:11:34 Kenneth D. Merry wrote:
> > > > > On Tue, May 24, 2016 at 00:05:49 +0300, Oleg V. Nauman wrote:
> > > > > > On Monday 23 May 2016 16:53:55 Kenneth D. Merry wrote:
> > > > > > > On Mon, May 23, 2016 at 23:21:32 +0300, Oleg V. Nauman wrote:
> > > > > > > > On Monday 23 May 2016 15:25:39 Kenneth D. Merry wrote:
> > > > > > > > > On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V. Nauman 
wrote:
> > > > > > > > > >  I have faced the issue with fresh CURRENT stopped to boot
> > > > > > > > > >  on
> > > > > > > > > >  my
> > > > > > > > > >  old
> > > > > > > > > >  desktop
> > > > > > > > > > 
> > > > > > > > > > after update to r300299
> > > > > > > > > > Verbose boot shows the endless cycle of
> > > > > > > > > > 
> > > > > > > > > > ata2: SATA reset: ports status=0x05
> > > > > > > > > > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > > > > > > > > > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > > > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > > > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > > > > > > > > > messages logged to console.
> > > > > > > > > > 
> > > > > > > > > > Below is the relevant portion of ATA controller/devices
> > > > > > > > > > probed/attached
> > > > > > > > > > during the boot:
> > > > > > > > > > 
> > > > > > > > > > atapci0:  port
> > > > > > > > > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at
> > > > > > > > > > device
> > > > > > > > > > 31.1
> > > > > > > > > > on
> > > > > > > > > > pci0
> > > > > > > > > > ata0:  at channel 0 on atapci0
> > > > > > > > > > atapci1:  port
> > > > > > > > > > 0xd080-0xd087,
> > > > > > > > > > 0xd000-0xd003,
> > > > > > > > > > 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at device
> > > > > > > > > > 31.2 on
> > > > > > > > > > pci0
> > > > > > > > > > ata2:  at channel 0 on atapci1
> > > > > > > > > > ata3:  at channel 1 on atapci1
> > > > > > > > > > ada0 at ata2 bus 0 scbus1 target 0 lun 0
> > > > > > > > > > ada0:  ATA-7 SATA 2.x device
> > > > > > > > > > ada1 at ata2 bus 0 scbus1 target 1 lun 0
> > > > > > > > > > ada1:  ATA8-ACS SATA 3.x device
> > > > > > > > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0
> > > > > > > > > > cd0: <_NEC DVD_RW ND-3570A 1.11> Removable CD-ROM SCSI
> > > > > > > > > > device
> > > > > > > > > 
> > > > > > > > > I'm not entirely sure what is causing the problem with your
> > > > > > > > > system,
> > > > > > > > > but
> > > > > > > > > hopefully we can narrow it down a bit.
> > > > > > > > > 
> > > > > > > > > There is a bug that came in with my SMR changes in revision
> > > > > > > > > 300207
> > > > > > > > > that
> > > > > > > > > broke the quirk functionality in the ada(4) driver.  I don't
> > > > > > > > > think
> > > > > > > > > that
> > > > > > > > > is
> > > > > > > > > the problem you're seeing, though.
> > > > > > > > > 
> > > > > > > > > Can you try out this patch:
> > > > > &

Re: ATA? related trouble with r300299

[Oleg V. Nauman]

On Monday 23 May 2016 17:30:45 you wrote:
> On Tue, May 24, 2016 at 00:15:25 +0300, Oleg V. Nauman wrote:
> > On Monday 23 May 2016 17:11:34 Kenneth D. Merry wrote:
> > > On Tue, May 24, 2016 at 00:05:49 +0300, Oleg V. Nauman wrote:
> > > > On Monday 23 May 2016 16:53:55 Kenneth D. Merry wrote:
> > > > > On Mon, May 23, 2016 at 23:21:32 +0300, Oleg V. Nauman wrote:
> > > > > > On Monday 23 May 2016 15:25:39 Kenneth D. Merry wrote:
> > > > > > > On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V. Nauman wrote:
> > > > > > > >  I have faced the issue with fresh CURRENT stopped to boot on
> > > > > > > >  my
> > > > > > > >  old
> > > > > > > >  desktop
> > > > > > > > 
> > > > > > > > after update to r300299
> > > > > > > > Verbose boot shows the endless cycle of
> > > > > > > > 
> > > > > > > > ata2: SATA reset: ports status=0x05
> > > > > > > > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > > > > > > > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > > > > > > > messages logged to console.
> > > > > > > > 
> > > > > > > > Below is the relevant portion of ATA controller/devices
> > > > > > > > probed/attached
> > > > > > > > during the boot:
> > > > > > > > 
> > > > > > > > atapci0:  port
> > > > > > > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device
> > > > > > > > 31.1
> > > > > > > > on
> > > > > > > > pci0
> > > > > > > > ata0:  at channel 0 on atapci0
> > > > > > > > atapci1:  port 0xd080-0xd087,
> > > > > > > > 0xd000-0xd003,
> > > > > > > > 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at device
> > > > > > > > 31.2 on
> > > > > > > > pci0
> > > > > > > > ata2:  at channel 0 on atapci1
> > > > > > > > ata3:  at channel 1 on atapci1
> > > > > > > > ada0 at ata2 bus 0 scbus1 target 0 lun 0
> > > > > > > > ada0:  ATA-7 SATA 2.x device
> > > > > > > > ada1 at ata2 bus 0 scbus1 target 1 lun 0
> > > > > > > > ada1:  ATA8-ACS SATA 3.x device
> > > > > > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0
> > > > > > > > cd0: <_NEC DVD_RW ND-3570A 1.11> Removable CD-ROM SCSI device
> > > > > > > 
> > > > > > > I'm not entirely sure what is causing the problem with your
> > > > > > > system,
> > > > > > > but
> > > > > > > hopefully we can narrow it down a bit.
> > > > > > > 
> > > > > > > There is a bug that came in with my SMR changes in revision
> > > > > > > 300207
> > > > > > > that
> > > > > > > broke the quirk functionality in the ada(4) driver.  I don't
> > > > > > > think
> > > > > > > that
> > > > > > > is
> > > > > > > the problem you're seeing, though.
> > > > > > > 
> > > > > > > Can you try out this patch:
> > > > > > > 
> > > > > > > https://people.freebsd.org/~ken/cam_smr_ada_patch.20160523.1.txt
> > > > > > > 
> > > > > > > In /boot/loader.conf, put the following:
> > > > > > > 
> > > > > > > kern.cam.ada.0.quirks="0x04"
> > > > > > > kern.cam.ada.1.quirks="0x04"
> > > > > > > 
> > > > > > > If you're able to boot with those quirk entries in the
> > > > > > > loader.conf,
> > > > > > > try
> > > > > > > taking one of them out, and reboot.  If that works, try taking
> > > > > > > the
> > > > > > > other
> > > > > > > one out and reboot.
> > > > > > > 
> > > > > > > W

Re: ATA? related trouble with r300299

[Oleg V. Nauman]

On Monday 23 May 2016 17:11:34 Kenneth D. Merry wrote:
> On Tue, May 24, 2016 at 00:05:49 +0300, Oleg V. Nauman wrote:
> > On Monday 23 May 2016 16:53:55 Kenneth D. Merry wrote:
> > > On Mon, May 23, 2016 at 23:21:32 +0300, Oleg V. Nauman wrote:
> > > > On Monday 23 May 2016 15:25:39 Kenneth D. Merry wrote:
> > > > > On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V. Nauman wrote:
> > > > > >  I have faced the issue with fresh CURRENT stopped to boot on my
> > > > > >  old
> > > > > >  desktop
> > > > > > 
> > > > > > after update to r300299
> > > > > > Verbose boot shows the endless cycle of
> > > > > > 
> > > > > > ata2: SATA reset: ports status=0x05
> > > > > > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > > > > > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > > > > > messages logged to console.
> > > > > > 
> > > > > > Below is the relevant portion of ATA controller/devices
> > > > > > probed/attached
> > > > > > during the boot:
> > > > > > 
> > > > > > atapci0:  port
> > > > > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1
> > > > > > on
> > > > > > pci0
> > > > > > ata0:  at channel 0 on atapci0
> > > > > > atapci1:  port 0xd080-0xd087,
> > > > > > 0xd000-0xd003,
> > > > > > 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at device 31.2 on
> > > > > > pci0
> > > > > > ata2:  at channel 0 on atapci1
> > > > > > ata3:  at channel 1 on atapci1
> > > > > > ada0 at ata2 bus 0 scbus1 target 0 lun 0
> > > > > > ada0:  ATA-7 SATA 2.x device
> > > > > > ada1 at ata2 bus 0 scbus1 target 1 lun 0
> > > > > > ada1:  ATA8-ACS SATA 3.x device
> > > > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0
> > > > > > cd0: <_NEC DVD_RW ND-3570A 1.11> Removable CD-ROM SCSI device
> > > > > 
> > > > > I'm not entirely sure what is causing the problem with your system,
> > > > > but
> > > > > hopefully we can narrow it down a bit.
> > > > > 
> > > > > There is a bug that came in with my SMR changes in revision 300207
> > > > > that
> > > > > broke the quirk functionality in the ada(4) driver.  I don't think
> > > > > that
> > > > > is
> > > > > the problem you're seeing, though.
> > > > > 
> > > > > Can you try out this patch:
> > > > > 
> > > > > https://people.freebsd.org/~ken/cam_smr_ada_patch.20160523.1.txt
> > > > > 
> > > > > In /boot/loader.conf, put the following:
> > > > > 
> > > > > kern.cam.ada.0.quirks="0x04"
> > > > > kern.cam.ada.1.quirks="0x04"
> > > > > 
> > > > > If you're able to boot with those quirk entries in the loader.conf,
> > > > > try
> > > > > taking one of them out, and reboot.  If that works, try taking the
> > > > > other
> > > > > one out and reboot.
> > > > > 
> > > > > What I'm trying to figure out here is where the problem lies:
> > > > > 
> > > > > 1. The bug with the ada(4) driver (in where it loaded the quirks).
> > > > > 2. The extra probe steps in the ada(4) driver might be causing a
> > > > > problem
> > > > > 
> > > > >with ada0 (Samsung drive).
> > > > > 
> > > > > 3. The extra probe steps in the ada(4) driver might be causing a
> > > > > problem
> > > > > 
> > > > >with ada1 (Seagate drive).
> > > > > 
> > > > > 4. Something else.
> > > > > 
> > > > > So, if you can try the patch and try to eliminate a few
> > > > > possibilities,
> > > > > we
> > > > > may be able to narrow it down.
> > > >  
> > > >  I was able to boot after applying the patch ;
> > > > 
> > > > kern.cam.ada.0.quirks="0x04"
> > > > was the q

Re: ATA? related trouble with r300299

[Oleg V. Nauman]

On Monday 23 May 2016 16:53:55 Kenneth D. Merry wrote:
> On Mon, May 23, 2016 at 23:21:32 +0300, Oleg V. Nauman wrote:
> > On Monday 23 May 2016 15:25:39 Kenneth D. Merry wrote:
> > > On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V. Nauman wrote:
> > > >  I have faced the issue with fresh CURRENT stopped to boot on my old
> > > >  desktop
> > > > 
> > > > after update to r300299
> > > > Verbose boot shows the endless cycle of
> > > > 
> > > > ata2: SATA reset: ports status=0x05
> > > > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > > > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > > > messages logged to console.
> > > > 
> > > > Below is the relevant portion of ATA controller/devices
> > > > probed/attached
> > > > during the boot:
> > > > 
> > > > atapci0:  port
> > > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on
> > > > pci0
> > > > ata0:  at channel 0 on atapci0
> > > > atapci1:  port 0xd080-0xd087,
> > > > 0xd000-0xd003,
> > > > 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at device 31.2 on
> > > > pci0
> > > > ata2:  at channel 0 on atapci1
> > > > ata3:  at channel 1 on atapci1
> > > > ada0 at ata2 bus 0 scbus1 target 0 lun 0
> > > > ada0:  ATA-7 SATA 2.x device
> > > > ada1 at ata2 bus 0 scbus1 target 1 lun 0
> > > > ada1:  ATA8-ACS SATA 3.x device
> > > > cd0 at ata0 bus 0 scbus0 target 0 lun 0
> > > > cd0: <_NEC DVD_RW ND-3570A 1.11> Removable CD-ROM SCSI device
> > > 
> > > I'm not entirely sure what is causing the problem with your system, but
> > > hopefully we can narrow it down a bit.
> > > 
> > > There is a bug that came in with my SMR changes in revision 300207 that
> > > broke the quirk functionality in the ada(4) driver.  I don't think that
> > > is
> > > the problem you're seeing, though.
> > > 
> > > Can you try out this patch:
> > > 
> > > https://people.freebsd.org/~ken/cam_smr_ada_patch.20160523.1.txt
> > > 
> > > In /boot/loader.conf, put the following:
> > > 
> > > kern.cam.ada.0.quirks="0x04"
> > > kern.cam.ada.1.quirks="0x04"
> > > 
> > > If you're able to boot with those quirk entries in the loader.conf, try
> > > taking one of them out, and reboot.  If that works, try taking the other
> > > one out and reboot.
> > > 
> > > What I'm trying to figure out here is where the problem lies:
> > > 
> > > 1. The bug with the ada(4) driver (in where it loaded the quirks).
> > > 2. The extra probe steps in the ada(4) driver might be causing a problem
> > > 
> > >with ada0 (Samsung drive).
> > > 
> > > 3. The extra probe steps in the ada(4) driver might be causing a problem
> > > 
> > >with ada1 (Seagate drive).
> > > 
> > > 4. Something else.
> > > 
> > > So, if you can try the patch and try to eliminate a few possibilities,
> > > we
> > > may be able to narrow it down.
> >  
> >  I was able to boot after applying the patch ;
> > 
> > kern.cam.ada.0.quirks="0x04"
> > was the quirk in effect. It is quirk for my Samsung HD200HJ KF100-06 hard
> > drive.
> 
> Okay.  Just so we can narrow it down a little more, can you try this:
> 
> First, let's try getting an ATA Log directory using the PIO version of the
> command:
> 
> camcontrol cmd ada0 -v -a "2f 0 0 0 0 0 0 0 0 0 1 0" -i 512 - |hd
> 
> If that works (you should get hexdump output), try the DMA version of the
> command:
> 
> camcontrol cmd ada0 -v -d -a "47 0 0 0 0 0 0 0 0 0 1 0" -i 512 - |hd

"Expecting a character pointer argument." error for both commands.


> 
> My hope is that we can confirm whether or not this is what is causing the
> Samsung drive to have issues.  It is certainly possible to put in a quirk,
> but I'd rather not make it unnecessarily broad.
> 
> Thanks,
> 
> Ken

___
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: ATA? related trouble with r300299

[Oleg V. Nauman]

On Monday 23 May 2016 15:25:39 Kenneth D. Merry wrote:
> On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V. Nauman wrote:
> >  I have faced the issue with fresh CURRENT stopped to boot on my old
> >  desktop
> > 
> > after update to r300299
> > Verbose boot shows the endless cycle of
> > 
> > ata2: SATA reset: ports status=0x05
> > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > messages logged to console.
> > 
> > Below is the relevant portion of ATA controller/devices probed/attached
> > during the boot:
> > 
> > atapci0:  port
> > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
> > ata0:  at channel 0 on atapci0
> > atapci1:  port 0xd080-0xd087,
> > 0xd000-0xd003,
> > 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at device 31.2 on pci0
> > ata2:  at channel 0 on atapci1
> > ata3:  at channel 1 on atapci1
> > ada0 at ata2 bus 0 scbus1 target 0 lun 0
> > ada0:  ATA-7 SATA 2.x device
> > ada1 at ata2 bus 0 scbus1 target 1 lun 0
> > ada1:  ATA8-ACS SATA 3.x device
> > cd0 at ata0 bus 0 scbus0 target 0 lun 0
> > cd0: <_NEC DVD_RW ND-3570A 1.11> Removable CD-ROM SCSI device
> 
> I'm not entirely sure what is causing the problem with your system, but
> hopefully we can narrow it down a bit.
> 
> There is a bug that came in with my SMR changes in revision 300207 that
> broke the quirk functionality in the ada(4) driver.  I don't think that is
> the problem you're seeing, though.
> 
> Can you try out this patch:
> 
> https://people.freebsd.org/~ken/cam_smr_ada_patch.20160523.1.txt
> 
> In /boot/loader.conf, put the following:
> 
> kern.cam.ada.0.quirks="0x04"
> kern.cam.ada.1.quirks="0x04"
> 
> If you're able to boot with those quirk entries in the loader.conf, try
> taking one of them out, and reboot.  If that works, try taking the other
> one out and reboot.
> 
> What I'm trying to figure out here is where the problem lies:
> 
> 1. The bug with the ada(4) driver (in where it loaded the quirks).
> 2. The extra probe steps in the ada(4) driver might be causing a problem
>with ada0 (Samsung drive).
> 3. The extra probe steps in the ada(4) driver might be causing a problem
>with ada1 (Seagate drive).
> 4. Something else.
> 
> So, if you can try the patch and try to eliminate a few possibilities, we
> may be able to narrow it down.

 I was able to boot after applying the patch ;
kern.cam.ada.0.quirks="0x04"
was the quirk in effect. It is quirk for my Samsung HD200HJ KF100-06 hard 
drive.

> 
> Thanks,

 Thanks to you.

> 
> Ken

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

ATA? related trouble with r300299

[Oleg V. Nauman]

 I have faced the issue with fresh CURRENT stopped to boot on my old desktop 
after update to r300299
Verbose boot shows the endless cycle of 

ata2: SATA reset: ports status=0x05
ata2: reset tp1 mask=03 ostat0=50 ostat1=50
ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
ata2: reset tp2 stat0=50 stat1=50 devices=0x3
messages logged to console.

Below is the relevant portion of ATA controller/devices probed/attached during 
the boot:

atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
ata0:  at channel 0 on atapci0
atapci1:  port 0xd080-0xd087, 0xd000-0xd003, 
0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at device 31.2 on pci0
ata2:  at channel 0 on atapci1
ata3:  at channel 1 on atapci1
ada0 at ata2 bus 0 scbus1 target 0 lun 0
ada0:  ATA-7 SATA 2.x device
ada1 at ata2 bus 0 scbus1 target 1 lun 0
ada1:  ATA8-ACS SATA 3.x device
cd0 at ata0 bus 0 scbus0 target 0 lun 0
cd0: <_NEC DVD_RW ND-3570A 1.11> Removable CD-ROM SCSI device


Thank you
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Monday 21 March 2016 13:22:58 you wrote:
> On Mon, Mar 21, 2016 at 12:15:15PM +0200, Oleg V. Nauman wrote:
[skip]
> 
> In other words, there is no virtualization involved.
> 
> I think that the problem at hands is not related to clang update. You
> recently rebuilt kde libs, which probably triggered detection of the new
> feature, process-shared locks in our libthr.  Before that, older HEAD
> does not exposed p/shared as implemented option.  Somehow the implementation
> and KDE expectations do not match, and asserts in libthr catch that.
> 
> Anyway, please apply the debugging patch I posted in the previous mail.


 After applying the patch:

Mar 22 07:34:37 asus kernel: pid 1928 creating existing key 1
Mar 22 07:34:58 asus kernel: pid 1928 (akonadi_baloo_index), uid 1001: exited 
on signal 6 (core dumped)

> /usr/local/bin/gdb /usr/local/bin/akonadi_baloo_indexer 
akonadi_baloo_index.core
GNU gdb (GDB) 7.11 [GDB v7.11 for FreeBSD]
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/akonadi_baloo_indexer...(no debugging 
symbols found)...done.

warning: core file may not match specified executable file. 
   
[New LWP 100294]
   
Core was generated by `akonadi_baloo_index'.
   
Program terminated with signal SIGABRT, Aborted.
   
#0  0x000805617d6a in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x000805617d6a in thr_kill () from /lib/libc.so.7
#1  0x000805617d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x000805617ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3  0x00080533d484 in _thread_exit (
fname=0x80533eb66 "/usr/src/lib/libthr/thread/thr_mutex.c", lineno=150,
msg=0x7fffd300 "mutex 0x80064d000 own 0x187c6 0x187c6 is on list 0x0 
0x80933ca80")
at /usr/src/lib/libthr/thread/thr_exit.c:182
#4  0x000805333e76 in mutex_assert_not_owned (m=0x80064d000)
at /usr/src/lib/libthr/thread/thr_mutex.c:150
#5  0x000805334049 in enqueue_mutex (curthread=0x80e015000, m=0x80064d000)
at /usr/src/lib/libthr/thread/thr_mutex.c:395
#6  0x0008053342a3 in mutex_lock_common (m=0x80064d000, 
abstime=0x7fffd448,
cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:545
#7  0x0008053336fe in __pthread_mutex_timedlock (mutex=0x811c8,
abstime=0x7fffd448) at /usr/src/lib/libthr/thread/thr_mutex.c:578
#8  0x00080443c4b0 in pthreadTimedLock::lock (this=0x80e164910)
at 
/usr/ports/x11/kdelibs4/work/kdelibs-4.14.3/kdecore/util/kshareddatacache_p.h:252
#9  0x00080443c8a8 in KSharedDataCache::Private::CacheLocker::cautiousLock 
(
this=0x7fffd5e0)

(gdb) f 5
#5  0x000805334049 in enqueue_mutex (curthread=0x80e015000, m=0x80064d000)
at /usr/src/lib/libthr/thread/thr_mutex.c:395
395 mutex_assert_not_owned(m);
(gdb) p *curthread
$1 = {tid = 100294, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0, 0}, 
m_spare = {0, 0,
  0, 0}}, cycle = 0, locklevel = 0, critical_count = 0, sigblock = 0, tle 
= {
tqe_next = 0x0, tqe_prev = 0x805544e90 <_thread_list>}, gcle = {tqe_next = 
0x0,
tqe_prev = 0x0}, hle = {le_next = 0x0, le_prev = 0x80554f240}, wle = 
{tqe_next = 0x0,
tqe_prev = 0x0}, refcount = 0, start_routine = 0x0, arg = 0x0, attr = 
{sched_policy = 2,
sched_inherit = 4, prio = 0, suspend = 0, flags = 258, stackaddr_attr = 
0x7dfff000,
stacksize_attr = 33554432, guardsize_attr = 4096, cpuset = 0x0, cpusetsize 
= 0},
  cancel_enable = 1, cancel_pending = 0, cancel_point = 0, no_cancel = 0, 
cancel_async = 0,
  cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel = 0,
  in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0, si_code = 
0, si_pid = 0,
si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, 
sival_ptr = 0x0,
  sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, 
_timer = {
_timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, 
__spare__ =

Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Monday 21 March 2016 09:07:10 you wrote:
> On Mon, Mar 21, 2016 at 07:21:02AM +0200, Konstantin Belousov wrote:
> > On Sun, Mar 20, 2016 at 09:28:13AM +0200, Oleg V. Nauman wrote:
> > > Fatal error 'mutex 0x800632000 own 0x1885c 0x1885c is on list 0x0
> > > 0x80d46ebc0' at line 155 in file /usr/src/lib/libthr/thread/thr_mutex.c
> > > (errno = 2 )> > 
> > >  What I have got after applying this patch:
> > > #0  0x000805913d6a in thr_kill () from /lib/libc.so.7
> > > #1  0x000805913d3b in __raise (s=6) at
> > > /usr/src/lib/libc/gen/raise.c:52
> > > #2  0x000805913ca9 in abort () at
> > > /usr/src/lib/libc/stdlib/abort.c:65
> > > #3  0x000805639554 in _thread_exit (
> > > 
> > > fname=0x80563ac36 "/usr/src/lib/libthr/thread/thr_mutex.c",
> > > lineno=155,
> > > msg=0x7fffd1c0 "mutex 0x800632000 own 0x1885c 0x1885c is on list
> > > 0x0
> > > 
> > > 0x80d46ebc0")
> > > 
> > > at /usr/src/lib/libthr/thread/thr_exit.c:182
> > > 
> > > #4  0x00080562fe36 in mutex_assert_not_owned (m=0x800632000)
> > > 
> > > at /usr/src/lib/libthr/thread/thr_mutex.c:155
> > > 
> > > #5  0x000805630009 in enqueue_mutex (curthread=0x80cc15000,
> > > m=0x800632000)> > 
> > > at /usr/src/lib/libthr/thread/thr_mutex.c:400
> > > 
> > > #6  0x000805631665 in mutex_lock_sleep (curthread=0x80cc15000,
> > > m=0x800632000,
> > > 
> > > abstime=0x7fffd358) at
> > > /usr/src/lib/libthr/thread/thr_mutex.c:535
> > > 
> > > #7  0x000805630280 in mutex_lock_common (m=0x800632000,
> > > abstime=0x7fffd358,
> > > 
> > > cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:553
> > > 
> > > #8  0x00080562f6be in __pthread_mutex_timedlock (mutex=0x810a8,
> > > 
> > > abstime=0x7fffd358) at
> > > /usr/src/lib/libthr/thread/thr_mutex.c:583
> > > 
> > > ...
> > > gdb) f 6
> > > #6  0x000805631665 in mutex_lock_sleep (curthread=0x80cc15000,
> > > m=0x800632000,
> > > 
> > > abstime=0x7fffd358) at
> > > /usr/src/lib/libthr/thread/thr_mutex.c:535
> > > 
> > > 535 enqueue_mutex(curthread, m);
> > > (gdb) p *curthread
> > > $1 = {tid = 100444, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0,
> > > 0},
> > > m_spare = {0, 0,
> > > 
> > >   0, 0}}, cycle = 0, locklevel = 0, critical_count = 0, sigblock =
> > >   0, tle
> > > 
> > > = {
> > > 
> > > tqe_next = 0x0, tqe_prev = 0x805841000 <_thread_list>}, gcle =
> > > {tqe_next =
> > > 
> > > 0x0,
> > > 
> > > tqe_prev = 0x0}, hle = {le_next = 0x0, le_prev = 0x80584b3c0}, wle =
> > > 
> > > {tqe_next = 0x0,
> > > 
> > > tqe_prev = 0x0}, refcount = 0, start_routine = 0x0, arg = 0x0, attr
> > > =
> > > 
> > > {sched_policy = 2,
> > > 
> > > sched_inherit = 4, prio = 0, suspend = 0, flags = 258,
> > > stackaddr_attr =
> > > 
> > > 0x7dfff000,
> > > 
> > > stacksize_attr = 33554432, guardsize_attr = 4096, cpuset = 0x0,
> > > cpusetsize
> > > 
> > > = 0},
> > > 
> > >   cancel_enable = 1, cancel_pending = 0, cancel_point = 0, no_cancel =
> > >   0,
> > > 
> > > cancel_async = 0,
> > > 
> > >   cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel =
> > >   0,
> > >   in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0,
> > >   si_code => > 
> > > 0, si_pid = 0,
> > > 
> > > si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0,
> > > 
> > > sival_ptr = 0x0,
> > > 
> > >   sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno =
> > >   0},
> > > 
> > > _timer = {
> > > 
> > > _timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band
> > > = 0},
> > > 
> > > __spare__ = {
> > > 
> > > __spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0,
> > > 
> > > deferred_sigmask = {__bits = {
> > > 
> > >   0, 0, 0, 0}}, deferred_sigact = {__sigactio

Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Saturday 19 March 2016 21:47:57 Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 04:03:06PM +0200, Oleg V. Nauman wrote:
> > Core was generated by `akonadi_baloo_index'.
> > Program terminated with signal SIGABRT, Aborted.
> > #0  0x000805630d6a in thr_kill () from /lib/libc.so.7
> > (gdb) bt
> > #0  0x000805630d6a in thr_kill () from /lib/libc.so.7
> > #1  0x000805630d3b in __raise (s=6) at
> > /usr/src/lib/libc/gen/raise.c:52
> > #2  0x000805630ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> > #3  0x0008053564b4 in _thread_exit (
> > 
> > fname=0x805357b70 "/usr/src/lib/libthr/thread/thr_mutex.c",
> > lineno=139,
> > msg=0x805357b97 "mutex is on list") at
> > 
> > /usr/src/lib/libthr/thread/thr_exit.c:182
> > #4  0x00080534cddc in mutex_assert_not_owned (m=0x80064d000)
> > 
> > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > 
> > #5  0x00080534cfb9 in enqueue_mutex (curthread=0x80e015000,
> > m=0x80064d000)> 
> > at /usr/src/lib/libthr/thread/thr_mutex.c:383
> > 
> > #6  0x00080534d213 in mutex_lock_common (m=0x80064d000,
> > abstime=0x7fffd4e8,
> > 
> > cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:533
> > 
> > #7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
> > 
> > abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > (gdb) f 7
> > #7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
> > 
> > abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > 566 ret = mutex_lock_common(m, abstime, 0);
> > (gdb) p *mutex
> > $1 = (pthread_mutex_t) 0x8001
> > (gdb) p m
> > $2 = (struct pthread_mutex *) 0x80064d000
> > (gdb) p *m
> > $3 = {m_lock = {m_owner = -2147383372, m_flags = 1, m_ceilings = {0, 0},
> > m_spare = {0, 0, 0,
> > 
> >   0}}, m_flags = 1, m_owner = 100276, m_count = 0, m_spinloops = 0,
> > 
> > m_yieldloops = 0,
> > 
> >   m_qe = {tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0,
> >   tqe_prev => 
> > 0x0}}
> > (gdb) p *curthread
> > No symbol "curthread" in current context.
> > (gdb)
> 
> curthread is available e.q. in the frame 5.
> 
> The content from the printout is reasonable, but now it contradicts to the
> assertion fired, since both checked pointers are NULL, as reported by gdb.
> 
> Please add the following debugging patch on top of the previous change
> and reproduce the issue.  I need the same info, but please also provide
> exact gasp message from libthr, which is enchanced in the patch below.
> 
> diff --git a/lib/libthr/thread/thr_mutex.c b/lib/libthr/thread/thr_mutex.c
> index 30a8be2..3342c9f 100644
> --- a/lib/libthr/thread/thr_mutex.c
> +++ b/lib/libthr/thread/thr_mutex.c
> @@ -124,8 +124,14 @@ mutex_assert_is_owned(struct pthread_mutex *m)
>  {
> 
>  #if defined(_PTHREADS_INVARIANTS)
> - if (__predict_false(m->m_qe.tqe_prev == NULL))
> - PANIC("mutex is not on list");
> + if (__predict_false(m->m_qe.tqe_prev == NULL)) {
> + char msg[128];
> + snprintf(msg, sizeof(msg),
> + "mutex %p own %#x %#x is not on list %p %p",
> + m, m->m_lock.m_owner, m->m_owner, m->m_qe.tqe_prev,
> + m->m_qe.tqe_next);
> + PANIC(msg);
> + }
>  #endif
>  }
> 
> @@ -135,8 +141,14 @@ mutex_assert_not_owned(struct pthread_mutex *m)
> 
>  #if defined(_PTHREADS_INVARIANTS)
>   if (__predict_false(m->m_qe.tqe_prev != NULL ||
> - m->m_qe.tqe_next != NULL))
> - PANIC("mutex is on list");
> + m->m_qe.tqe_next != NULL)) {
> + char msg[128];
> + snprintf(msg, sizeof(msg),
> + "mutex %p own %#x %#x is on list %p %p",
> + m, m->m_lock.m_owner, m->m_owner, m->m_qe.tqe_prev,
> + m->m_qe.tqe_next);
> + PANIC(msg);
> + }
>  #endif
>  }

Fatal error 'mutex 0x800632000 own 0x1885c 0x1885c is on list 0x0 0x80d46ebc0' 
at line 155 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 2 )

 What I have got after applying this patch:

#0  0x000805913d6a in thr_kill () from /lib/libc.so.7
#1  0x000805913d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x000805913ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3  0x000805639554 in _thread_exit (
fn

Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Saturday 19 March 2016 21:47:57 Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 04:03:06PM +0200, Oleg V. Nauman wrote:
> > Core was generated by `akonadi_baloo_index'.
> > Program terminated with signal SIGABRT, Aborted.
> > #0  0x000805630d6a in thr_kill () from /lib/libc.so.7
> > (gdb) bt
> > #0  0x000805630d6a in thr_kill () from /lib/libc.so.7
> > #1  0x000805630d3b in __raise (s=6) at
> > /usr/src/lib/libc/gen/raise.c:52
> > #2  0x000805630ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> > #3  0x0008053564b4 in _thread_exit (
> > 
> > fname=0x805357b70 "/usr/src/lib/libthr/thread/thr_mutex.c",
> > lineno=139,
> > msg=0x805357b97 "mutex is on list") at
> > 
> > /usr/src/lib/libthr/thread/thr_exit.c:182
> > #4  0x00080534cddc in mutex_assert_not_owned (m=0x80064d000)
> > 
> > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > 
> > #5  0x00080534cfb9 in enqueue_mutex (curthread=0x80e015000,
> > m=0x80064d000)> 
> > at /usr/src/lib/libthr/thread/thr_mutex.c:383
> > 
> > #6  0x00080534d213 in mutex_lock_common (m=0x80064d000,
> > abstime=0x7fffd4e8,
> > 
> > cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:533
> > 
> > #7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
> > 
> > abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > (gdb) f 7
> > #7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
> > 
> > abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > 566 ret = mutex_lock_common(m, abstime, 0);
> > (gdb) p *mutex
> > $1 = (pthread_mutex_t) 0x8001
> > (gdb) p m
> > $2 = (struct pthread_mutex *) 0x80064d000
> > (gdb) p *m
> > $3 = {m_lock = {m_owner = -2147383372, m_flags = 1, m_ceilings = {0, 0},
> > m_spare = {0, 0, 0,
> > 
> >   0}}, m_flags = 1, m_owner = 100276, m_count = 0, m_spinloops = 0,
> > 
> > m_yieldloops = 0,
> > 
> >   m_qe = {tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0,
> >   tqe_prev => 
> > 0x0}}
> > (gdb) p *curthread
> > No symbol "curthread" in current context.
> > (gdb)
> 
> curthread is available e.q. in the frame 5.

(gdb) f 5
#5  0x00080534cfb9 in enqueue_mutex (curthread=0x80e015000, m=0x80064d000)
at /usr/src/lib/libthr/thread/thr_mutex.c:383
383 mutex_assert_not_owned(m);
(gdb) p *curthread
$4 = {tid = 100276, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0, 0}, 
m_spare = {0, 0,
  0, 0}}, cycle = 0, locklevel = 0, critical_count = 0, sigblock = 0, tle 
= {
tqe_next = 0x0, tqe_prev = 0x80555df40 <_thread_list>}, gcle = {tqe_next = 
0x0,
tqe_prev = 0x0}, hle = {le_next = 0x0, le_prev = 0x805568340}, wle = 
{tqe_next = 0x0,
tqe_prev = 0x0}, refcount = 0, start_routine = 0x0, arg = 0x0, attr = 
{sched_policy = 2,
sched_inherit = 4, prio = 0, suspend = 0, flags = 258, stackaddr_attr = 
0x7dfff000,
stacksize_attr = 33554432, guardsize_attr = 4096, cpuset = 0x0, cpusetsize 
= 0},
  cancel_enable = 1, cancel_pending = 0, cancel_point = 0, no_cancel = 0, 
cancel_async = 0,
  cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel = 0,
  in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0, si_code = 
0, si_pid = 0,
si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, 
sival_ptr = 0x0,
  sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, 
_timer = {
_timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, 
__spare__ = {
__spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0, 
deferred_sigmask = {__bits = {
  0, 0, 0, 0}}, deferred_sigact = {__sigaction_u = {__sa_handler = 0x0,
  __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}},
  deferred_run = 0, force_exit = 0, state = PS_RUNNING, error = 0, joiner = 
0x0, flags = 0,
  tlflags = 2, mq = {{tqh_first = 0x0, tqh_last = 0x80e0151a0}, {tqh_first = 
0x0,
  tqh_last = 0x80e0151b0}, {tqh_first = 0x0, tqh_last = 0x80e0151c0}, 
{tqh_first = 0x0,
  tqh_last = 0x80e0151d0}}, ret = 0x0, specific = 0x80064c000, 
specific_data_count = 4,
  rdlock_count = 0, rtld_bits = 0, tcb = 0x8006fd158, cleanup = 0x0, ex = {
exception_class = 0, exception_cleanup = 0x0, private_1 = 0, private_2 = 
0},
  unwind_stackend = 0x7000, unwind_disabled = 0, magic = 3499860245,
  report_events = 0, event_mask = 0, event_buf = {event = TD_EVENT_NONE, th_p 
= 0, data = 0},
  wchan = 0x0, mutex_obj = 0x0, will_sleep = 0, nwaiter_defer = 0, 
defer_waiters = {
0x0 }, 

Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > Yes, please.  It would be significantly easier to diagnose the problem if
> > the minimal example is provided.  If not, please pack one crashing app
> > and all it non-system libraries and provide the tarball to me.
> 
> Meantime you could also try the following change.  I doubt that it would
> fix your issue, but it is possibly related.  Only libthr needs to be
> rebuilt.

 I will try it tomorrow morning and will send the report.

Thank you!

> 
> diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
> index 7256b68..531e09c 100644
> --- a/lib/libthr/thread/thr_fork.c
> +++ b/lib/libthr/thread/thr_fork.c
> @@ -168,6 +168,7 @@ __thr_fork(void)
>   if (_thr_isthreaded() != 0) {
>   was_threaded = 1;
>   _malloc_prefork();
> + __thr_pshared_atfork_pre();
>   _rtld_atfork_pre(rtld_locks);
>   } else {
>   was_threaded = 0;
> @@ -202,8 +203,10 @@ __thr_fork(void)
> 
>   _thr_signal_postfork_child();
> 
> - if (was_threaded)
> + if (was_threaded) {
>   _rtld_atfork_post(rtld_locks);
> + __thr_pshared_atfork_post();
> + }
>   _thr_setthreaded(0);
> 
>   /* reinitalize library. */
> @@ -236,6 +239,7 @@ __thr_fork(void)
> 
>   if (was_threaded) {
>   _rtld_atfork_post(rtld_locks);
> + __thr_pshared_atfork_post();
>   _malloc_postfork();
>   }
> 
> diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c
> index 3c81299..5e7f01c 100644
> --- a/lib/libthr/thread/thr_init.c
> +++ b/lib/libthr/thread/thr_init.c
> @@ -466,7 +466,6 @@ init_private(void)
>   _thr_once_init();
>   _thr_spinlock_init();
>   _thr_list_init();
> - __thr_pshared_init();
>   _thr_wake_addr_init();
>   _sleepq_init();
>   _single_thread = NULL;
> @@ -477,6 +476,7 @@ init_private(void)
>* e.g. after a fork().
>*/
>   if (init_once == 0) {
> + __thr_pshared_init();
>   /* Find the stack top */
>   mib[0] = CTL_KERN;
>   mib[1] = KERN_USRSTACK;
> diff --git a/lib/libthr/thread/thr_private.h
> b/lib/libthr/thread/thr_private.h index 31f8e6c..7ee1fbf 100644
> --- a/lib/libthr/thread/thr_private.h
> +++ b/lib/libthr/thread/thr_private.h
> @@ -952,6 +952,8 @@ void  _tcb_dtor(struct tcb *);
>  void __thr_pshared_init(void) __hidden;
>  void *__thr_pshared_offpage(void *key, int doalloc) __hidden;
>  void __thr_pshared_destroy(void *key) __hidden;
> +void __thr_pshared_atfork_pre(void) __hidden;
> +void __thr_pshared_atfork_post(void) __hidden;
> 
>  __END_DECLS
> 
> diff --git a/lib/libthr/thread/thr_pshared.c
> b/lib/libthr/thread/thr_pshared.c index e8ccf1c..8371478 100644
> --- a/lib/libthr/thread/thr_pshared.c
> +++ b/lib/libthr/thread/thr_pshared.c
> @@ -252,3 +252,17 @@ __thr_pshared_destroy(void *key)
>   pshared_clean(key, val);
>   pshared_gc(curthread);
>  }
> +
> +void
> +__thr_pshared_atfork_pre(void)
> +{
> +
> + _thr_rwl_rdlock(_lock);
> +}
> +
> +void
> +__thr_pshared_atfork_post(void)
> +{
> +
> + _thr_rwl_unlock(_lock);
> +}

___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Saturday 19 March 2016 12:32:56 Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 12:24:11PM +0200, Oleg V. Nauman wrote:
> > On Saturday 19 March 2016 12:14:33 Konstantin Belousov wrote:
> > > On Sat, Mar 19, 2016 at 09:03:56AM +0200, Oleg V. Nauman wrote:
> > > > On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> > > > > On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > > > > > Yes, please.  It would be significantly easier to diagnose the
> > > > > > problem
> > > > > > if
> > > > > > the minimal example is provided.  If not, please pack one crashing
> > > > > > app
> > > > > > and all it non-system libraries and provide the tarball to me.
> > > > > 
> > > > > Meantime you could also try the following change.  I doubt that it
> > > > > would
> > > > > fix your issue, but it is possibly related.  Only libthr needs to be
> > > > > rebuilt.
> > > > > 
> > > > > diff --git a/lib/libthr/thread/thr_fork.c
> > > > > b/lib/libthr/thread/thr_fork.c
> > > > > index 7256b68..531e09c 100644
> > > > > --- a/lib/libthr/thread/thr_fork.c
> > > > > +++ b/lib/libthr/thread/thr_fork.c
> > > >  
> > > >  No it is still coredumping.
> > > > 
> > > > The only positive effect is that segfaults are quite occasional
> > > > comparing
> > > > to stock libthr
> > > > 
> > > > Loaded symbols for /libexec/ld-elf.so.1
> > > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > > [New Thread 809215000 (LWP 100253/)]
> > > > (gdb) bt
> > > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > > #1  0x0008041b2d3b in __raise (s=6) at
> > > > /usr/src/lib/libc/gen/raise.c:52
> > > > #2  0x0008041b2ca9 in abort () at
> > > > /usr/src/lib/libc/stdlib/abort.c:65
> > > > #3  0x000803eda67c in _thread_exit (fname=,
> > > > 
> > > > lineno=, msg=)
> > > > at /usr/src/lib/libthr/thread/thr_exit.c:182
> > > > 
> > > > #4  0x000803ed56fc in mutex_lock_common (m=,
> > > > 
> > > > abstime=, cvattach=)
> > > > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > > > 
> > > > #5  0x000803ed4c20 in __pthread_mutex_timedlock
> > > > (mutex=0x81828,
> > > > 
> > > > abstime=0x7fffc468) at
> > > > /usr/src/lib/libthr/thread/thr_mutex.c:566
> > > 
> > > Again, please show me
> > > p *mutex
> > > p m
> > > p *m
> > > from the frame 5.
> >  
> >  #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > 
> > [New Thread 809215000 (LWP 100253/)]
> > (gdb) f 5
> > #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> > 
> > abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > 566 ret = mutex_lock_common(m, abstime, 0);
> > Current language:  auto; currently minimal
> > (gdb) p *mutex
> > $1 = 0x8001
> > (gdb) p m
> > $2 = 
> > (gdb) p *m
> > Cannot access memory at address 0x130049
> > (gdb)
> 
> Try devel/gdb.  Also, you could recompile libthr with DEBUG_FLAGS="-O0 -g"
> to get rid of optimizations.

Core was generated by `akonadi_baloo_index'.
Program terminated with signal SIGABRT, Aborted.
#0  0x000805630d6a in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x000805630d6a in thr_kill () from /lib/libc.so.7
#1  0x000805630d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x000805630ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3  0x0008053564b4 in _thread_exit (
fname=0x805357b70 "/usr/src/lib/libthr/thread/thr_mutex.c", lineno=139,
msg=0x805357b97 "mutex is on list") at 
/usr/src/lib/libthr/thread/thr_exit.c:182
#4  0x00080534cddc in mutex_assert_not_owned (m=0x80064d000)
at /usr/src/lib/libthr/thread/thr_mutex.c:139
#5  0x00080534cfb9 in enqueue_mutex (curthread=0x80e015000, m=0x80064d000)
at /usr/src/lib/libthr/thread/thr_mutex.c:383
#6  0x00080534d213 in mutex_lock_common (m=0x80064d000, 
abstime=0x7fffd4e8,
cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:533
#7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_m

Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Friday 18 March 2016 03:30:51 Konstantin Belousov wrote:
> On Thu, Mar 17, 2016 at 09:40:11PM +0200, Oleg V. Nauman wrote:
> >  I'm experiencing issue with threaded applications ( including many KDE
> > 
> > applications ) after recent CURRENT update. Attempt to start application
> > cause Abort trap (6) with "Fatal error 'mutex is on list' at line 139 in
> > file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)" output on
> > console.
> > 
> > FreeBSD 11.0-CURRENT amd64 r296887
> > 
> > Backtrace from application looks like
> > 
> > Application: KGpg (kgpg), signal: Abort trap
> > [Switching to Thread 810815000 (LWP 100865/kgpg)]
> > [KCrash Handler]
> > #8  0x000807176d6a in thr_kill () from /lib/libc.so.7
> > #9  0x000807176d3b in __raise (s=6) at
> > /usr/src/lib/libc/gen/raise.c:52
> > #10 0x000807176ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> > #11 0x000806e9e62c in _thread_exit (fname=,
> > lineno=, msg=) at
> > /usr/src/lib/libthr/thread/thr_exit.c:182
> > #12 0x000806e996fc in mutex_lock_common (m=,
> > abstime=, cvattach=) at
> > /usr/src/lib/libthr/thread/thr_mutex.c:139
> > #13 0x000806e98c20 in __pthread_mutex_timedlock (mutex=0x81468,
> > abstime=0x7fff5a58) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> 
> From the frame 13, please do
> p *mutex
> p *m
> p **mutex

 Got few cores today morning, for example:

gdb /usr/local/bin/akonadi_notes_agent akonadi_notes_agent.core
 ( list of many shared libraries loaded by application )

0  0x000805d08d6a in thr_kill () from /lib/libc.so.7
[New Thread 817615000 (LWP 100295/)]
(gdb) bt
#0  0x000805d08d6a in thr_kill () from /lib/libc.so.7
#1  0x000805d08d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x000805d08ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3  0x000805a3062c in _thread_exit (fname=, 
lineno=, msg=)
at /usr/src/lib/libthr/thread/thr_exit.c:182
#4  0x000805a2b6fc in mutex_lock_common (m=, 
abstime=, cvattach=)
at /usr/src/lib/libthr/thread/thr_mutex.c:139
#5  0x000805a2ac20 in __pthread_mutex_timedlock (mutex=0x81b28,
abstime=0x7fffd4f8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
#6  0x00080448b560 in KSharedDataCache::setTimestamp ()
   from /usr/local/lib/libkdecore.so.5
#7  0x00080448b7df in KSharedDataCache::setTimestamp ()
   from /usr/local/lib/libkdecore.so.5
#8  0x000804487192 in KSharedDataCache::insert () from 
/usr/local/lib/libkdecore.so.5
#9  0x000802c1912e in KIconLoader::drawOverlays () from 
/usr/local/lib/libkdeui.so.5
#10 0x000802c15e3b in KIconLoader::loadIcon () from 
/usr/local/lib/libkdeui.so.5
#11 0x000802c14366 in KIconEffect::overlay () from 
/usr/local/lib/libkdeui.so.5
#12 0x0008034aff3d in QIcon::pixmap () from 
/usr/local/lib/qt4/libQtGui.so.4
#13 0x00080349d2d6 in QWidgetPrivate::setWindowIcon_sys ()
   from /usr/local/lib/qt4/libQtGui.so.4
#14 0x0008034590e7 in QWidget::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#15 0x00080340a43c in QApplicationPrivate::notify_helper ()
   from /usr/local/lib/qt4/libQtGui.so.4
#16 0x00080340ca61 in QApplication::notify () from 
/usr/local/lib/qt4/libQtGui.so.4
#17 0x000802c724b7 in KApplication::notify () from 
/usr/local/lib/libkdeui.so.5
#18 0x000804d8eaa6 in QCoreApplication::notifyInternal ()
   from /usr/local/lib/qt4/libQtCore.so.4
#19 0x0008034084e1 in QApplication::setWindowIcon () from 
/usr/local/lib/qt4/libQtGui.so.4
#20 0x000802c74725 in KApplication::iceIOErrorHandler () from 
/usr/local/lib/libkdeui.so.5
#21 0x000802c72a9b in KApplication::KApplication () from 
/usr/local/lib/libkdeui.so.5
#22 0x000802c728f7 in KApplication::KApplication () from 
/usr/local/lib/libkdeui.so.5
#23 0x0040b10c in ?? ()
#24 0x0040a74f in ?? ()
#25 0x00080063a000 in ?? ()
#26 0x in ?? ()
(gdb) f 5
#5  0x000805a2ac20 in __pthread_mutex_timedlock (mutex=0x81b28,
abstime=0x7fffd4f8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
566 ret = mutex_lock_common(m, abstime, 0);
Current language:  auto; currently minimal
(gdb) p *mutex
$1 = 0x8001
(gdb) p *m
$2 = {m_lock = {m_owner = 1, m_flags = 2147483648, m_ceilings = 0x81b200010,
m_spare = 0x81b200018}, m_flags = 0, m_owner = 0, m_count = 0, m_spinloops 
= 0,
  m_yieldloops = 0, m_qe = {tqe_next = 0x0, tqe_prev = 0x1}, m_pqe = {
tqe_next = 0x71100a0, tqe_prev = 0x1000}}
(gdb) p **mutex
Cannot access memory at address 0x8001


> 
> What non-KDE apps exhibit the behaviour ?

 I will try to find some simple application experiencing the same issue.
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Saturday 19 March 2016 12:23:45 Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 12:14:33PM +0200, Konstantin Belousov wrote:
> > On Sat, Mar 19, 2016 at 09:03:56AM +0200, Oleg V. Nauman wrote:
> > > On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> > > > On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > > > > Yes, please.  It would be significantly easier to diagnose the
> > > > > problem if
> > > > > the minimal example is provided.  If not, please pack one crashing
> > > > > app
> > > > > and all it non-system libraries and provide the tarball to me.
> > > > 
> > > > Meantime you could also try the following change.  I doubt that it
> > > > would
> > > > fix your issue, but it is possibly related.  Only libthr needs to be
> > > > rebuilt.
> > > > 
> > > > diff --git a/lib/libthr/thread/thr_fork.c
> > > > b/lib/libthr/thread/thr_fork.c
> > > > index 7256b68..531e09c 100644
> > > > --- a/lib/libthr/thread/thr_fork.c
> > > > +++ b/lib/libthr/thread/thr_fork.c
> > >  
> > >  No it is still coredumping.
> > > 
> > > The only positive effect is that segfaults are quite occasional
> > > comparing to stock libthr
> > > 
> > > Loaded symbols for /libexec/ld-elf.so.1
> > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > [New Thread 809215000 (LWP 100253/)]
> > > (gdb) bt
> > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > #1  0x0008041b2d3b in __raise (s=6) at
> > > /usr/src/lib/libc/gen/raise.c:52
> > > #2  0x0008041b2ca9 in abort () at
> > > /usr/src/lib/libc/stdlib/abort.c:65
> > > #3  0x000803eda67c in _thread_exit (fname=,
> > > 
> > > lineno=, msg=)
> > > at /usr/src/lib/libthr/thread/thr_exit.c:182
> > > 
> > > #4  0x000803ed56fc in mutex_lock_common (m=,
> > > 
> > > abstime=, cvattach=)
> > > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > > 
> > > #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> > > 
> > > abstime=0x7fffc468) at
> > > /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > Again, please show me
> > p *mutex
> > p m
> > p *m
> > from the frame 5.
> 
> and also please do
> p *curthread

(gdb) p *curthread
No symbol "curthread" in current context.

___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Saturday 19 March 2016 12:14:33 Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 09:03:56AM +0200, Oleg V. Nauman wrote:
> > On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> > > On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > > > Yes, please.  It would be significantly easier to diagnose the problem
> > > > if
> > > > the minimal example is provided.  If not, please pack one crashing app
> > > > and all it non-system libraries and provide the tarball to me.
> > > 
> > > Meantime you could also try the following change.  I doubt that it would
> > > fix your issue, but it is possibly related.  Only libthr needs to be
> > > rebuilt.
> > > 
> > > diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
> > > index 7256b68..531e09c 100644
> > > --- a/lib/libthr/thread/thr_fork.c
> > > +++ b/lib/libthr/thread/thr_fork.c
> >  
> >  No it is still coredumping.
> > 
> > The only positive effect is that segfaults are quite occasional comparing
> > to stock libthr
> > 
> > Loaded symbols for /libexec/ld-elf.so.1
> > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > [New Thread 809215000 (LWP 100253/)]
> > (gdb) bt
> > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > #1  0x0008041b2d3b in __raise (s=6) at
> > /usr/src/lib/libc/gen/raise.c:52
> > #2  0x0008041b2ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> > #3  0x000803eda67c in _thread_exit (fname=,
> > 
> > lineno=, msg=)
> > at /usr/src/lib/libthr/thread/thr_exit.c:182
> > 
> > #4  0x000803ed56fc in mutex_lock_common (m=,
> > 
> > abstime=, cvattach=)
> > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > 
> > #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> > 
> > abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> 
> Again, please show me
> p *mutex
> p m
> p *m
> from the frame 5.

 #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
[New Thread 809215000 (LWP 100253/)]
(gdb) f 5
#5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
566 ret = mutex_lock_common(m, abstime, 0);
Current language:  auto; currently minimal
(gdb) p *mutex
$1 = 0x8001
(gdb) p m
$2 = 
(gdb) p *m
Cannot access memory at address 0x130049
(gdb)

Thank you!


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

Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

 I'm experiencing issue with threaded applications ( including many KDE 
applications ) after recent CURRENT update. Attempt to start application cause 
Abort trap (6) with "Fatal error 'mutex is on list' at line 139 in file 
/usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)" output on console. 

FreeBSD 11.0-CURRENT amd64 r296887

Backtrace from application looks like

Application: KGpg (kgpg), signal: Abort trap
[Switching to Thread 810815000 (LWP 100865/kgpg)]
[KCrash Handler]
#8  0x000807176d6a in thr_kill () from /lib/libc.so.7
#9  0x000807176d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#10 0x000807176ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#11 0x000806e9e62c in _thread_exit (fname=, 
lineno=, msg=) at 
/usr/src/lib/libthr/thread/thr_exit.c:182
#12 0x000806e996fc in mutex_lock_common (m=, 
abstime=, cvattach=) at 
/usr/src/lib/libthr/thread/thr_mutex.c:139
#13 0x000806e98c20 in __pthread_mutex_timedlock (mutex=0x81468, 
abstime=0x7fff5a58) at /usr/src/lib/libthr/thread/thr_mutex.c:566
#14 0x00080568b560 in KSharedDataCache::setTimestamp () from 
/usr/local/lib/libkdecore.so.5
#15 0x00080568b7df in KSharedDataCache::setTimestamp () from 
/usr/local/lib/libkdecore.so.5
#16 0x00080568802e in KSharedDataCache::find () from 
/usr/local/lib/libkdecore.so.5
#17 0x0008038192db in KIconLoader::drawOverlays () from 
/usr/local/lib/libkdeui.so.5
#18 0x00080381596a in KIconLoader::loadIcon () from 
/usr/local/lib/libkdeui.so.5
#19 0x000803814366 in KIconEffect::overlay () from 
/usr/local/lib/libkdeui.so.5
#20 0x0008040aff3d in QIcon::pixmap () from 
/usr/local/lib/qt4/libQtGui.so.4
#21 0x00080431e9df in QCommonStyle::drawControl () from 
/usr/local/lib/qt4/libQtGui.so.4
#22 0x00080437011f in QPlastiqueStyle::drawControl () from 
/usr/local/lib/qt4/libQtGui.so.4
#23 0x00080431be51 in QCommonStyle::drawControl () from 
/usr/local/lib/qt4/libQtGui.so.4
#24 0x00080437011f in QPlastiqueStyle::drawControl () from 
/usr/local/lib/qt4/libQtGui.so.4
#25 0x00080396151b in KPushButton::paintEvent () from 
/usr/local/lib/libkdeui.so.5
#26 0x00080405916c in QWidget::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#27 0x0008043b7fd0 in QAbstractButton::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#28 0x00080400a43c in QApplicationPrivate::notify_helper () from 
/usr/local/lib/qt4/libQtGui.so.4
#29 0x00080400ca61 in QApplication::notify () from 
/usr/local/lib/qt4/libQtGui.so.4
#30 0x0008038724b7 in KApplication::notify () from 
/usr/local/lib/libkdeui.so.5
#31 0x000805f8eaa6 in QCoreApplication::notifyInternal () from 
/usr/local/lib/qt4/libQtCore.so.4
#32 0x000804053eaa in QWidgetPrivate::drawWidget () from 
/usr/local/lib/qt4/libQtGui.so.4
#33 0x000804054657 in QWidgetPrivate::paintSiblingsRecursive () from 
/usr/local/lib/qt4/libQtGui.so.4
#34 0x00080405404e in QWidgetPrivate::drawWidget () from 
/usr/local/lib/qt4/libQtGui.so.4
#35 0x000804054657 in QWidgetPrivate::paintSiblingsRecursive () from 
/usr/local/lib/qt4/libQtGui.so.4
#36 0x00080405404e in QWidgetPrivate::drawWidget () from 
/usr/local/lib/qt4/libQtGui.so.4
#37 0x00080422d7b6 in QWidgetPrivate::scrollRect () from 
/usr/local/lib/qt4/libQtGui.so.4
#38 0x0008040590cb in QWidget::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#39 0x00080400a43c in QApplicationPrivate::notify_helper () from 
/usr/local/lib/qt4/libQtGui.so.4
#40 0x00080400ca61 in QApplication::notify () from 
/usr/local/lib/qt4/libQtGui.so.4
#41 0x0008038724b7 in KApplication::notify () from 
/usr/local/lib/libkdeui.so.5
#42 0x000805f8eaa6 in QCoreApplication::notifyInternal () from 
/usr/local/lib/qt4/libQtCore.so.4
#43 0x00080422ae07 in QPrinterInfo::supportedPaperSizes () from 
/usr/local/lib/qt4/libQtGui.so.4
#44 0x00080405b44f in QWidget::repaint () from 
/usr/local/lib/qt4/libQtGui.so.4
#45 0x00080405b384 in QWidget::repaint () from 
/usr/local/lib/qt4/libQtGui.so.4
#46 0x0008043b804c in QAbstractButton::mousePressEvent () from 
/usr/local/lib/qt4/libQtGui.so.4
#47 0x0008040590be in QWidget::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#48 0x0008043b7fd0 in QAbstractButton::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#49 0x00080400a43c in QApplicationPrivate::notify_helper () from 
/usr/local/lib/qt4/libQtGui.so.4
#50 0x00080400bdbc in QApplication::notify () from 
/usr/local/lib/qt4/libQtGui.so.4
#51 0x0008038724b7 in KApplication::notify () from 
/usr/local/lib/libkdeui.so.5
#52 0x000805f8eaa6 in QCoreApplication::notifyInternal () from 
/usr/local/lib/qt4/libQtCore.so.4
#53 0x00080400ae87 in QApplicationPrivate::sendMouseEvent () from 
/usr/local/lib/qt4/libQtGui.so.4
#54 0x000804081cf5 in qt_try_modal () from 
/usr/local/lib/qt4/libQtGui.so.4
#55 0x00080408043b in QApplication::x11ProcessEvent () from 
/usr/local/lib/qt4/libQtGui.so.4
#56 

Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > Yes, please.  It would be significantly easier to diagnose the problem if
> > the minimal example is provided.  If not, please pack one crashing app
> > and all it non-system libraries and provide the tarball to me.
> 
> Meantime you could also try the following change.  I doubt that it would
> fix your issue, but it is possibly related.  Only libthr needs to be
> rebuilt.
> 
> diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
> index 7256b68..531e09c 100644
> --- a/lib/libthr/thread/thr_fork.c
> +++ b/lib/libthr/thread/thr_fork.c

 No it is still coredumping.
The only positive effect is that segfaults are quite occasional comparing to 
stock libthr

Loaded symbols for /libexec/ld-elf.so.1
#0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
[New Thread 809215000 (LWP 100253/)]
(gdb) bt
#0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
#1  0x0008041b2d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x0008041b2ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3  0x000803eda67c in _thread_exit (fname=,
lineno=, msg=)
at /usr/src/lib/libthr/thread/thr_exit.c:182
#4  0x000803ed56fc in mutex_lock_common (m=,
abstime=, cvattach=)
at /usr/src/lib/libthr/thread/thr_mutex.c:139
#5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566


___
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: r287197: wlan interfaces aren't brought up at boot or u

[Oleg V. Nauman]

On Saturday 29 August 2015 11:02:02 Gleb Smirnoff wrote:
 On Sat, Aug 29, 2015 at 01:19:40AM +0200, Idwer Vollering wrote:
 I Manually running 'service netif restart' works around this.
 I
 I /etc/network.subr and /etc/rc.d/netif have been updated by mergemaster
 I -p and mergemaster -iF
 I
 I I can provide the, rather lengthy, output of 'sh -x /etc/rc.d/netif
 I restart' when required.
 I
 I Note that I'm not subscribed to freebsd-current.
 
 Yes, please provide 'sh -x /etc/rc.d/netif restart'.
 
 And please also check the revisions of your files:
 
 # ident /etc/rc.d/netif /etc/network.subr

 I have faced the same issue today. wlan interface is not  brought up at boot,
sh -x /etc/rc.d/netif restart does the trick.


# ident  /etc/rc.d/netif /etc/network.subr
/etc/rc.d/netif:
 $FreeBSD: head/etc/rc.d/netif 287197 2015-08-27 08:56:39Z glebius $
/etc/network.subr:
 $FreeBSD: head/etc/network.subr 287197 2015-08-27 08:56:39Z glebius $


___
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: r287197: wlan interfaces aren't brought up at boot or u

[Oleg V. Nauman]

On Saturday 29 August 2015 15:53:31 Gleb Smirnoff wrote:
 On Sat, Aug 29, 2015 at 12:56:39PM +0300, Oleg V. Nauman wrote:
 O On Saturday 29 August 2015 11:02:02 Gleb Smirnoff wrote:
 O  On Sat, Aug 29, 2015 at 01:19:40AM +0200, Idwer Vollering wrote:
 O  I Manually running 'service netif restart' works around this.
 O  I
 O  I /etc/network.subr and /etc/rc.d/netif have been updated by
 mergemaster O  I -p and mergemaster -iF
 O  I
 O  I I can provide the, rather lengthy, output of 'sh -x /etc/rc.d/netif
 O  I restart' when required.
 O  I
 O  I Note that I'm not subscribed to freebsd-current.
 O 
 O  Yes, please provide 'sh -x /etc/rc.d/netif restart'.
 O 
 O  And please also check the revisions of your files:
 O 
 O  # ident /etc/rc.d/netif /etc/network.subr
 O
 O  I have faced the same issue today. wlan interface is not  brought up at
 boot, O sh -x /etc/rc.d/netif restart does the trick.
 
 Have you got any error or strange messages during boot?

 No

Aug 29 17:38:32 asus kernel: Trying to mount root from ufs:/dev/ada0s1a 
[rw]...
Aug 29 17:38:32 asus kernel: re0: link state changed to DOWN
Aug 29 17:38:32 asus kernel: run0: Ralink 11n Adapter, class 0/0, rev 
2.00/1.01, addr 1 on usbus0
Aug 29 17:38:32 asus kernel: run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 
(MIMO 1T1R), address 00:26:5a:0a:cb:fa
Aug 29 17:38:34 asus kernel: re0: link state changed to UP
Aug 29 17:38:36 asus kernel: font8x16
Aug 29 17:38:37 asus kernel: blanktime allscreens.

sh /etc/rc.d/netif restart issued

Aug 29 17:40:26 asus kernel: ifa_del_loopback_route: deletion failed: 3
Aug 29 17:40:27 asus kernel: wlan1: Ethernet address: 00:26:5a:0a:cb:fa
Aug 29 17:40:27 asus kernel: re0: link state changed to DOWN
Aug 29 17:40:28 asus kernel: run0: firmware RT2870 ver. 0.33 loaded
Aug 29 17:40:30 asus kernel: re0: link state changed to UP
Aug 29 17:40:32 asus kernel: wlan1: link state changed to UP


 
 What does net.wlan.devices sysctl say?

# sysctl net.wlan.devices
net.wlan.devices: run0
# sh /etc/rc.d/netif restart /dev/null
wlan1: no link ... got link
DHCPREQUEST on wlan1 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.102 -- renewal in 3600 seconds.
# sysctl net.wlan.devices
net.wlan.devices: run0

 
 
___
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: Recent HEAD: buildworld is broken with clang

[Oleg V. Nauman]

Quoting Garrett Cooper yaneg...@gmail.com:


On Aug 14, 2011, at 11:58 AM, Oleg V. Nauman o...@opentransfer.com wrote:

...

There was an issue with file descriptor handling introduced with the  
capsicum work. Please update your src, rebuild your kernel, install,  
or use an older kernel, and try again.


 Thanks. Installing the new kernel fixes the issue so I was able to  
complete buildworld.



-Garrett



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

Recent HEAD: buildworld is broken with clang

[Oleg V. Nauman]

=== libexec (all)
=== libexec/atrun (all)
clang -O -pipe -march=i686 -mtune=i686  -DATJOB_DIR=\/var/at/jobs/\   
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5  
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1  
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'  
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at  
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99  
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k  
-Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c
clang -O -pipe -march=i686 -mtune=i686  -DATJOB_DIR=\/var/at/jobs/\   
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5  
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1  
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'  
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at  
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99  
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k  
-Wno-uninitialized -Wno-pointer-sign -c  
/usr/src/libexec/atrun/gloadavg.c
clang -O -pipe -march=i686 -mtune=i686  -DATJOB_DIR=\/var/at/jobs/\   
-DLFILE=\/var/at/jobs/.lockfile\  -DLOADAVG_MX=1.5  
-DATSPOOL_DIR=\/var/at/spool\  -DVERSION=\2.9\ -DDAEMON_UID=1  
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'  
-DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at  
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99  
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k  
-Wno-uninitialized -Wno-pointer-sign  -o atrun atrun.o gloadavg.o  
-lpam -lutil

clang: warning: argument unused during compilation: '-std=gnu99'
/usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylex'
/usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyin'
/usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyytext'
/usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror'
/usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno'
clang: error: linker command failed with exit code 1 (use -v to see  
invocation)

*** Error code 1

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

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

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

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

Stop in /usr/src.

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

Re: sendmail: no local mailer

[Oleg V. Nauman]

On Wed, Apr 02, 2003 at 03:18:18PM -0700, Nate Williams wrote:
evantd Sendmail has not been working on my system for some time now. I
evantd can't say exactly how long, but my guess is that it broke when I
evantd upgraded to RELENG_5_0. This is how sendmail is invoked (by
evantd default) and it's output.

evantd # sendmail -L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost
evantd 451 4.0.0 No local mailer defined: Bad address
evantd 554 5.0.0 QueueDirectory (Q) option must be set

/etc/mail/sendmail.cf is a bogus (empty?) file.  One way to fix this is:

cd /etc/mail
mv sendmail.cf sendmail.cf~bogus
make
make restart
   
   This happened on one of my -stable boxes lately when doing a upgrade
   using buildworld.  For some (unknown) reason m4 bombed out and created
   an empty .cf file.
   
   I fixed it by doing something similar to what was done above, although
   why m4 failed is a mystery
  
  Some patch:
  
  --- /usr/src/etc/sendmail/Makefile.orig Wed Apr  2 23:51:19 2003
  +++ /usr/src/etc/sendmail/Makefile Wed Apr  2 23:51:50 2003
   -1,7 +1,7 
   # (#)Makefile 8.19 (Berkeley) 1/14/97
   # $FreeBSD: src/etc/sendmail/Makefile,v 1.21 2002/07/29 09:40:06 ru Exp $
  
  -M4=  m4
  +M4=  /usr/bin/m4
   CHMOD=   chmod
   ROMODE=444
   RM=  rm -f
  
 
 This shouldn't be necessary, since m4 is in the path in buildworld, is

installworld, you meant?

 it not?  Otherwise, we wouldn't be able to run make, cc, or any other
 tools.

ok...

this was under slightly patched /usr/src/etc/sendmail/Makefile:
--- /usr/src/etc/sendmail/Makefile.orig Thu Apr  3 19:47:54 2003
+++ /usr/src/etc/sendmail/Makefile  Thu Apr  3 21:18:23 2003
 -18,6 +18,7 
 .mc.cf:${M4FILES}
${RM} ${.TARGET}
(cd ${.CURDIR}  \
+   set | /usr/bin/grep PATH  /tmp/installworld.path 21 ; \
${M4} -D_CF_DIR_=${CFDIR}/ ${SENDMAIL_M4_FLAGS} \
${CFDIR}/m4/cf.m4 ${:R}.mc)  ${.TARGET}
${CHMOD} ${ROMODE} ${.TARGET}

So, after some installworld's activity:

rm -f /etc/mail/vega.cf
(cd /usr/src/etc/sendmail   set | /usr/bin/grep PATH  /tmp/installworld.path 21 ; 
 m4 -D_CF_DIR_=/usr/src/etc/sendmail/../../contrib/sendmail/cf/   
/usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /etc/mail/vega.mc)  
/etc/mail/vega.cf
m4: not found
^
*** Error code 127

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

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

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

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

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

Stop in /usr/src.

# more /tmp/installworld.path
GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font
PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/s
rc/i386/usr/games:/tmp/install.84736
GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac
GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin
OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec
#sh
# export PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr
/obj/usr/src/i386/usr/games:/tmp/install.84736
# /usr/bin/which m4
#
^D
# which m4
/usr/bin/m4
# ls -al /etc/mail/*.cf
-rw-r--r--  1 root  wheel  57079 Apr  3 20:45 /etc/mail/sendmail.cf
-rw-r--r--  1 root  wheel  0 Apr  3 21:33 /etc/mail/vega.cf

# uname -a
FreeBSD vega.reis.zp.ua 4.8-RC FreeBSD 4.8-RC #1: Sun Mar 30 12:52:49 EEST 2003 
[EMAIL PROTECTED]:/usr/src/sys/compile/Vega  i386

Yes, this was attempt to 'make installworld' from NFS-mounted /usr/src and
/usr/obj. So, /usr/src/etc/sendmail/Makefile definitely should define
M4 as /usr/bin/m4.


 
 
 
 Nate

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

Re: sendmail: no local mailer

[Oleg V. Nauman]

On Wed, Apr 02, 2003 at 10:26:03AM -0700, Nate Williams wrote:
  evantd Sendmail has not been working on my system for some time now. I
  evantd can't say exactly how long, but my guess is that it broke when I
  evantd upgraded to RELENG_5_0. This is how sendmail is invoked (by
  evantd default) and it's output.
  
  evantd # sendmail -L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost
  evantd 451 4.0.0 No local mailer defined: Bad address
  evantd 554 5.0.0 QueueDirectory (Q) option must be set
  
  /etc/mail/sendmail.cf is a bogus (empty?) file.  One way to fix this is:
  
  cd /etc/mail
  mv sendmail.cf sendmail.cf~bogus
  make
  make restart
 
 This happened on one of my -stable boxes lately when doing a upgrade
 using buildworld.  For some (unknown) reason m4 bombed out and created
 an empty .cf file.
 
 I fixed it by doing something similar to what was done above, although
 why m4 failed is a mystery

Some patch:

--- /usr/src/etc/sendmail/Makefile.orig Wed Apr  2 23:51:19 2003
+++ /usr/src/etc/sendmail/Makefile Wed Apr  2 23:51:50 2003
 -1,7 +1,7 
 # (#)Makefile 8.19 (Berkeley) 1/14/97
 # $FreeBSD: src/etc/sendmail/Makefile,v 1.21 2002/07/29 09:40:06 ru Exp $

-M4=  m4
+M4=  /usr/bin/m4
 CHMOD=   chmod
 ROMODE=444
 RM=  rm -f

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

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