It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
--- i915_drv.o ---
In file included from i915_drv.c:30:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from
/usr/ports/graphics/drm-next-km
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler schrieb:
> It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
>
> --- i915_drv.o ---
> In file included from i915_drv.c:30:
> In file included from
> /usr/ports/graphics/drm-nex
On 7/2/2018 10:46 PM, Mark Millard wrote:
> -r335879 broke ci.freebsd.org's FreeBSD-head-amd64-build :
>
> https://ci.freebsd.org/job/FreeBSD-head-amd64-build/
>
> shows:
>
> --- ia32_genassym.o ---
> In file included from /usr/src/sys/compat/ia32/ia32_genassym.c:6:
> In file included from /usr/
On Tue, Jul 3, 2018 at 5:30 PM Bryan Drewery wrote:
>
> On 7/2/2018 10:46 PM, Mark Millard wrote:
> > -r335879 broke ci.freebsd.org's FreeBSD-head-amd64-build :
> >
> > https://ci.freebsd.org/job/FreeBSD-head-amd64-build/
> >
> > shows:
> >
> > --- ia32_genassym.o ---
> > In file included from /us
On June 1st, I was able to do my monthly laptop ZFS snap-shot/back-up
(using "zfs snapshot -r zroot@backup; zfs send -R >nfs-filesys"). Now I
can't without the em0 interface stalling :-(
On a guess, I tried reverting SVN r335303 but that didn't help.
em0: port 0xf080-0xf09f mem
0xf7e0-0xf7e1
On 2018-Jul-3, at 10:06 AM, Li-Wen Hsu wrote:
> On Tue, Jul 3, 2018 at 5:30 PM Bryan Drewery wrote:
>>
>> On 7/2/2018 10:46 PM, Mark Millard wrote:
>>> -r335879 broke ci.freebsd.org's FreeBSD-head-amd64-build :
>>>
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-build/
>>>
>>> shows:
>>>
Hi!
> On June 1st, I was able to do my monthly laptop ZFS snap-shot/back-up
> (using "zfs snapshot -r zroot@backup; zfs send -R >nfs-filesys"). Now I
> can't without the em0 interface stalling :-(
I had a similar case on a current r334918 and saw this in the kern syslog:
Jun 30 15:40:34 fc ker
On 07/03/18 17:02, O. Hartmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler schrieb:
It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
--- i915_drv.o ---
In file included from i915_drv.c:30:
In file included fro
On 07/03/18 11:47, Michael Butler wrote:
> On June 1st, I was able to do my monthly laptop ZFS snap-shot/back-up
> (using "zfs snapshot -r zroot@backup; zfs send -R >nfs-filesys"). Now I
> can't without the em0 interface stalling :-(
>
Can you tell what version of FreeBSD SVN was in use on "Jun
On 07/03/18 14:31, Sean Bruno wrote:
>
>
> On 07/03/18 11:47, Michael Butler wrote:
>> On June 1st, I was able to do my monthly laptop ZFS snap-shot/back-up
>> (using "zfs snapshot -r zroot@backup; zfs send -R >nfs-filesys"). Now I
>> can't without the em0 interface stalling :-(
>>
>
> Can you t
On 7/3/18 11:28 AM, Niclas Zeising wrote:
> On 07/03/18 17:02, O. Hartmann wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Am Tue, 3 Jul 2018 10:19:57 -0400
>> Michael Butler schrieb:
>>
>>> It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
>>>
>>> --- i915
On 7/3/18 14:47, I wrote:
> On 07/03/18 14:31, Sean Bruno wrote:
>>
>>
>> On 07/03/18 11:47, Michael Butler wrote:
>>> On June 1st, I was able to do my monthly laptop ZFS snap-shot/back-up
>>> (using "zfs snapshot -r zroot@backup; zfs send -R >nfs-filesys"). Now I
>>> can't without the em0 interfac
On 07/03/2018 15:02, John Baldwin wrote:
> On 7/3/18 11:28 AM, Niclas Zeising wrote:
>> On 07/03/18 17:02, O. Hartmann wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> Am Tue, 3 Jul 2018 10:19:57 -0400
>>> Michael Butler schrieb:
>>>
It seems recent changes (SVN r335873?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/03/2018 15:23, Jung-uk Kim wrote:
> On 07/03/2018 15:02, John Baldwin wrote:
>> On 7/3/18 11:28 AM, Niclas Zeising wrote:
>>> On 07/03/18 17:02, O. Hartmann wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512
Am Tue, 3 Jul 20
I updated the laptop to r335884 last night, and 'service wpa_supplicant
start wlan0' doesn't succeed any more.
kernel is supposed to create the network interface 'run0', but it
doesn't. This is the immediate reason why wpa_supplicant fails.
The non-creation of 'run0' is a regression. I don't
On 03.07.2018 22:45, Yuri wrote:
> I updated the laptop to r335884 last night, and 'service wpa_supplicant
> start wlan0' doesn't succeed any more.
>
> kernel is supposed to create the network interface 'run0', but it
> doesn't. This is the immediate reason why wpa_supplicant fails.
>
> The non-
On 07/03/18 12:50, Lev Serebryakov wrote:
No, it isn't.
https://lists.freebsd.org/pipermail/freebsd-wireless/2016-October/007232.html
I don't know, why is it not mentioned in UPDATING:-(
I may be mistaken about the interface creation.
But regardless of the cause, WiFi doesn't work any
On 07/03/18 13:53, Yuri wrote:
> On 07/03/18 12:50, Lev Serebryakov wrote:
>> No, it isn't.
>>
>>
>> https://lists.freebsd.org/pipermail/freebsd-wireless/2016-October/007232.html
>>
>>
>> I don't know, why is it not mentioned in UPDATING:-(
>
>
> I may be mistaken about the interface crea
On 07/03/2018 12:02, John Baldwin wrote:
On 7/3/18 11:28 AM, Niclas Zeising wrote:
On 07/03/18 17:02, O. Hartmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler schrieb:
It seems recent changes (SVN r335873?) may have broken drm-nex
On 07/03/18 13:54, Sean Bruno wrote:
Yuri:
If you're still having trouble, dump your rc.conf entries for your
wireless. Mine looks like this at the moment with iwn(4):
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
seam
Thank you, Sean!
rc.conf has:
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA
On 07/03/18 14:32, Yuri wrote:
rc.conf has:
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
wpa_supplicant_enable="YES"
wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
This got mixed up.
rc.conf has:
wlans_run0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"
wpa_supplicant_enable="YES"
wpa_
On 07/03/2018 14:17, Pete Wright wrote:
On 07/03/2018 12:02, John Baldwin wrote:
On 7/3/18 11:28 AM, Niclas Zeising wrote:
On 07/03/18 17:02, O. Hartmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler schrieb:
It seems recent chan
On 07/03/2018 15:12, Pete Wright wrote:
On 07/03/2018 14:17, Pete Wright wrote:
On 07/03/2018 12:02, John Baldwin wrote:
On 7/3/18 11:28 AM, Niclas Zeising wrote:
On 07/03/18 17:02, O. Hartmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Tue, 3 Jul 2018 10:19:57 -0400
Mic
> On 07/03/18 14:32, Yuri wrote:
> >
> >
> > rc.conf has:
> >
> > wlans_iwn0="wlan0"
> >
> > ifconfig_wlan0="WPA DHCP"
> >
> > wpa_supplicant_enable="YES"
> >
> > wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
^^
What wpa_supplicant is this?
The normal
On 7/3/18 3:20 PM, Pete Wright wrote:
>
>
> On 07/03/2018 15:12, Pete Wright wrote:
>>
>>
>> On 07/03/2018 14:17, Pete Wright wrote:
>>>
>>>
>>> On 07/03/2018 12:02, John Baldwin wrote:
On 7/3/18 11:28 AM, Niclas Zeising wrote:
> On 07/03/18 17:02, O. Hartmann wrote:
>> -BEGIN PG
On 07/03/2018 15:29, John Baldwin wrote:
That seems like kgdb is looking at the wrong CPU. Can you use
'info threads' and look for threads not stopped in 'sched_switch'
and get their backtraces? You could also just do 'thread apply
all bt' and put that file at a URL if that is easiest.
s
On 07/03/18 15:29, Rodney W. Grimes wrote:
wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
^^
What wpa_supplicant is this?
The normal system one lives in /sbin.
It's installed by the package wpa_supplicant-2.6_2 from
security/wpa_supplicant.
It is
On 7/3/18 3:34 PM, Pete Wright wrote:
>
>
> On 07/03/2018 15:29, John Baldwin wrote:
>> That seems like kgdb is looking at the wrong CPU. Can you use
>> 'info threads' and look for threads not stopped in 'sched_switch'
>> and get their backtraces? You could also just do 'thread apply
>> all bt'
On 7/3/18 3:40 PM, Matthew Macy wrote:
> This seems like a clang inline asm bug. Could you try building the port with
> a recent gcc against an unpatched HEAD?
I've already committed the patch to HEAD, but using 'e' is from the GCC docs,
not clang docs:
https://gcc.gnu.org/onlinedocs/gcc/Machin
This seems like a clang inline asm bug. Could you try building the port
with a recent gcc against an unpatched HEAD?
On Tue, Jul 3, 2018 at 15:38 Pete Wright wrote:
>
>
> On 07/03/2018 15:29, John Baldwin wrote:
> > That seems like kgdb is looking at the wrong CPU. Can you use
> > 'info threads
On 07/03/2018 15:56, John Baldwin wrote:
On 7/3/18 3:34 PM, Pete Wright wrote:
On 07/03/2018 15:29, John Baldwin wrote:
That seems like kgdb is looking at the wrong CPU. Can you use
'info threads' and look for threads not stopped in 'sched_switch'
and get their backtraces? You could also j
[ Charset UTF-8 unsupported, converting... ]
> On 07/03/18 15:29, Rodney W. Grimes wrote:
> >>> wpa_supplicant_program="/usr/local/sbin/wpa_supplicant"
> > ^^
> >
> > What wpa_supplicant is this?
> > The normal system one lives in /sbin.
>
> It's installed by t
In message , Niclas
Zeising w
rites:
> On 07/03/18 17:02, O. Hartmann wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Am Tue, 3 Jul 2018 10:19:57 -0400
> > Michael Butler schrieb:
> >
> >> It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
> >>
> >> -
33 matches
Mail list logo
