Re: Graphics open-source-friendliness, AMD Ryzen vs. Intel

[Johannes Dieterich]

On Sun, Nov 11, 2018 at 4:48 PM Johannes Lundberg  wrote:
>
> I have an AMD Ryzen 3 2200G (with Vega graphics) and it panics all the time
> with references to various memory access errors (use after free among
> other).
>
> Ubuntu is also unstable on this machine but Windows 10 works well after a
> windows update (I had to reinstall the previous motherboard with older cpu
> to be able to run Windows update without crash...)
>
> From my experience, stay away from this CPU.
To put this a little into perspective: the R3 2200G is part of the
most recent AMD APU generation and contains the most recent Vega
graphics IP ("Vega 8"). It was officially released only in February of
this year. The most recent DRM in ports is 4.16, which itself was
released only in April. Problems with the 2200G on "older" Linux
releases are unfortunately well known. However, kernel 4.18 with
latest firmwares and BIOSs is documented to be stable on this platform
(see phoronix, Ubuntu 18.10 "benchmark").

Johannes

> On Sun, Nov 11, 2018 at 18:57 Allan Jude  wrote:
>
> > On 2018-11-11 12:54, Greg V wrote:
> > >
> > >
> > > On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller 
> > > wrote:
> > >> I may need to buy parts for a new computer because of malfunctions on
> > >> current motherboard and CPU (Intel Sandy Bridge dating to May 2011).
> > >>
> > >> Question is whether I am better off, regarding
> > >> open-source-friendliness of graphics chips for running Xorg, with AMD
> > >> Ryzen or the newer Intel chipsets.  I know to avoid NVIDIA.
> > >
> >
> > My FreeBSD workstation use an nVidia Quadro K1200 and it works very well
> > under FreeBSD with the nVidia kernel driver from ports.
> >
> > > Both are great for open source friendliness in general.
> > >
> > > Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with
> > > kms-drm 4.16.
> > >
> > > If you're looking for high performance though, don't get an APU, get an
> > > 8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX
> > > 550/560/570/580 depending on how much you care about graphics
> > performance).
> > >
> > >> I am inclined to run FreeBSD-current and build Xorg from FreeBSD ports.
> > >>
> > >> When I boot into UEFI setup, I see the CPU temperature is or quickly
> > >> goes to 97 C and stays there.
> > >>
> > >> I tried replacing the thermal paste and installing a new case fan to
> > >> replace one that had quit, but CPU temperature still shows and stays
> > >> at 97 C.
> > >>
> > >> Now I have a replacement Arctic Cooler heatsink and fan on order to
> > >> replace the original Intel heatsink and fan whose connectors were
> > >> damaged in taking out and struggling to get back in.
> > >>
> > >> Currently, I boot into UEFI Setup, but after a couple minutes, the
> > >> computer powers off and then tries to power back on, then off again a
> > >> few seconds later, until I end the loop by turning off the power
> > >> supply switch.  I can guess CPU overheating.
> > >
> > > Yeah, a new CPU cooler should help.
> > >
> > >> I could transplant the current hard drive (Seagate NAS 4 TB) to get a
> > >> quicker start software-wise.
> > >
> > > An SSD might provide a quicker start too ;)
> > >
> > > ___
> > > 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"
> >
> >
> > --
> > Allan Jude
> >
> >
> ___
> 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: drm confusion / xorg / AMD RX580 GPU

[Johannes Dieterich]

On Tuesday, October 9, 2018, tech-lists wrote:
> On 10/10/2018 00:19, tech-lists wrote:
> > [unquote]
> > 
> > Is this incorrect?
> 
> ah or do you mean it won't work with BOINC?
ROCm will work if you have the ROCm stack. Currently it is Ubuntu and CentOS 
only.

Additionally, I don't know whether or not BOINC has a client supporting it.
___
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: drm confusion / xorg / AMD RX580 GPU

[Johannes Dieterich]

On Tuesday, October 9, 2018, tech-lists wrote:
> On 08/10/2018 19:55, Johannes Dieterich wrote:
> > Depends what the boinc client uses. OpenCL - you will need graphics/clover 
> > which is not officially supported by AMD but may work. ROCm/HIP - won't 
> > work.
> 
> Hi,
> 
> What is ROCm/HIP ?
https://github.com/RadeonOpenCompute/ROCm

Our open acceleration stack. HIP is a kernel language akin to CUDA.

Johannes
___
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: drm confusion / xorg / AMD RX580 GPU

[Johannes Dieterich]

On Monday, October 8, 2018, tech lists wrote:
> Hi,
> 
> On 08/10/2018 14:06, Warner Losh wrote:
> > You need "/boot/kernel/amdgpu.ko" here
> > 
> > Warner
> 
> The instructions in pkg-message (at the time, haven't updated ports in a
> day or so) contradict this:
> 
> $ cd /usr/ports/graphics/drm-next-kmod/
> $ ls
> Makefiledistinfopkg-descr   pkg-message
> pkg-plist   work
> $ less pkg-message
> 
> [snip]
> The drm-next-kmod port can be enabled for amdgpu (for AMD GPUs starting
> with the HD7000 series / Tahiti) or i915kms (for Intel APUs starting
> with HD3000 / Sandy Bridge) through kld_list in /etc/rc.conf. radeonkms
> for older AMD GPUs can be loaded and there are some positive reports if
> EFI boot is NOT enabled (similar to amdgpu).
> 
> For amdgpu: kld_list="amdgpu"
> For Intel: kld_list="/boot/modules/i915kms.ko"
> For radeonkms: kld_list="/boot/modules/radeonkms.ko"
> 
> Please ensure that all users requiring graphics are members of the
> "video" group.
> 
> Older generations are supported by the stable kms modules (radeonkms /
> i915kms) in base.
> [/snip]
> 
> svnlite info shows /usr/ports at r481442. Shall I make bug report?
No. Both ways work and as your earlier kldstat clearly shows the amdgpu kernel 
driver is correctly loaded alongside it's firmware files and your problem 
likely resides with the X11 DDX.

Johannes
 
 ___
> 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: drm confusion / xorg / AMD RX580 GPU

[Johannes Dieterich]

On Monday, October 8, 2018, tech-lists wrote:
> Hi,
> 
> context: 12-alpha8, amd64, xorg, AMD rx580 card
> 
> As per /usr/ports/UPDATING, I have installed graphics/drm-kmod which has
> installed drm-next-kmod-4.11.g20180822
> 
> As per pkg message, it's loaded with this line in /etc/rc.conf:
> 
> kld_list="amdgpu"
> 
> But even though I get a graphical display, this shows in the X.org.0.log:
> 
> [91.379] (II) LoadModule: "ati"
> [91.379] (II) Loading /usr/local/lib/xorg/modules/drivers/ati_drv.so
> [91.379] (II) Module ati: vendor="X.Org Foundation"
> [91.379]compiled for 1.18.4, module version = 18.1.0
> [91.379]Module class: X.Org Video Driver
> [91.379]ABI class: X.Org Video Driver, version 20.0
> [91.382] (II) LoadModule: "amdgpu"
> [91.383] (WW) Warning, couldn't open module amdgpu
> [91.383] (II) UnloadModule: "amdgpu"
> [91.383] (II) Unloading amdgpu
> [91.383] (EE) Failed to load module "amdgpu" (module does not exist, 0)
You are showing Xorg.log output that tells you it misses the amdgpu DDX. I.e., 
install and use xf86-video-amdgpu. 
 
> $ kldstat
> Id Refs AddressSize Name
>  1   86 0x8020  13341b0 kernel
>  21 0x81536000   3ace18 zfs.ko
>  32 0x818e3000 a500 opensolaris.ko
>  41 0x81a22000   159978 amdgpu.ko
>  51 0x81b7c00075d70 drm.ko
>  64 0x81bf200010570 linuxkpi.ko
>  73 0x81c0300011300 linuxkpi_gplv2.ko
>  82 0x81c15000  6c0 debugfs.ko
>  91 0x81c16000 80db amdgpu_polaris10_mc_bin.ko
> 101 0x81c1f000 441d amdgpu_polaris10_pfp_bin.ko
> 111 0x81c24000 441b amdgpu_polaris10_me_bin.ko
> 121 0x81c29000 241b amdgpu_polaris10_ce_bin.ko
> 131 0x81c2c000 5d3d amdgpu_polaris10_rlc_bin.ko
> 141 0x81c320004042d amdgpu_polaris10_mec_bin.ko
> 151 0x81c730004042f amdgpu_polaris10_mec2_bin.ko
> 161 0x81cb4000 331f amdgpu_polaris10_sdma_bin.ko
> 171 0x81cb8000 3321 amdgpu_polaris10_sdma1_bin.ko
> 181 0x81cbc0005bbfd amdgpu_polaris10_uvd_bin.ko
> 191 0x81d1800028d1d amdgpu_polaris10_vce_bin.ko
> 201 0x81d410001fe51 amdgpu_polaris10_k_smc_bin.ko
> 211 0x81d61000 1800 uhid.ko
> 221 0x81d63000 2368 ums.ko
> 231 0x81d66000399d8 linux.ko
> 242 0x81da 2d98 linux_common.ko
> 251 0x81da300034008 linux64.ko
The kernel module seems correctly loaded alongside it's firmware files.
 
> Need to know:
> 
> 1. is this the right/fastest/best driver for this card?
Yes, amdgpu kernel module and amdgpu DDX
 
> 2. how can I tell if it's using all its capability?
What do you mean?
 
> 3. I'd like this card to crunch with boinc. What determines if this is
> possible? is it freebsd, boinc, the card driver, the project boinc is on
> or something else?
Depends what the boinc client uses. OpenCL - you will need graphics/clover 
which is not officially supported by AMD but may work. ROCm/HIP - won't work.
 
HTH

Johannes
 
 ___
> 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: APU Bristol Ridge graphics support

[Johannes Dieterich]

On Sunday, September 30, 2018, Rozhuk Ivan wrote:
> On Sun, 30 Sep 2018 23:21:36 +
> Johannes Dieterich  wrote:
> 
>  
> > > drm-next requires FreeBSD 12, I do not try it yet.  
> > It requires a FreeBSD version equal or higher than 1101511, could you
> > provide sysctl kern.osrelease?
> 
> kern.osrelease: 11.2-STABLE
> 
> /usr/ports/graphics/drm-kmod
> /usr/ports/graphics/drm-stable-kmod
> /usr/ports/graphics/drm-legacy-kmod
> /usr/ports/graphics/drm-next-kmod
> /usr/ports/graphics/drm-devel-kmod
> 
> Too many drm...
Which is why there is graphics/drm-kmod which will install the most recent 
recommended DRM for your OS version. Could you try that?

___
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: APU Bristol Ridge graphics support

[Johannes Dieterich]

On Sunday, September 30, 2018, Rozhuk Ivan wrote:
> On Sun, 30 Sep 2018 20:37:07 +
> Johannes Dieterich  wrote:
> 
> > > finishing device. [TTM] Memory type 2 has not been initialized
> > > device_attach: drmn0 attach returned 22  
> > Just to make sure, the gpu-firmware port is installed
> > and /boot/modules contains these files the load is looking for? Which
> > drm port gets installed if you use the new graphics/drm-kmod
> > metaport? If it is next, could you try with that?
> 
> 
> # pkg version -v | grep gpu
> gpu-firmware-kmod-g20180825=   up-to-date with index
> xf86-video-amdgpu-1.3.0_3  =   up-to-date with index
> 
> # pkg version -v | grep kmod
> drm-stable-kmod-g20180822  =   up-to-date with index
> gpu-firmware-kmod-g20180825=   up-to-date with index
> 
> # ls /boot/modules/ | grep carrizo
> -r-xr-xr-x   1 root  wheel13K Aug 26 21:20:06 2018 
> amdgpu_carrizo_ce_bin.ko*
> -r-xr-xr-x   1 root  wheel21K Aug 26 21:20:06 2018 
> amdgpu_carrizo_me_bin.ko*
> -r-xr-xr-x   1 root  wheel   261K Aug 26 21:20:06 2018 
> amdgpu_carrizo_mec_bin.ko*
> -r-xr-xr-x   1 root  wheel   261K Aug 26 21:20:06 2018 
> amdgpu_carrizo_mec2_bin.ko*
> -r-xr-xr-x   1 root  wheel21K Aug 26 21:20:06 2018 
> amdgpu_carrizo_pfp_bin.ko*
> -r-xr-xr-x   1 root  wheel23K Aug 26 21:20:06 2018 
> amdgpu_carrizo_rlc_bin.ko*
> -r-xr-xr-x   1 root  wheel15K Aug 26 21:20:06 2018 
> amdgpu_carrizo_sdma_bin.ko*
> -r-xr-xr-x   1 root  wheel15K Aug 26 21:20:06 2018 
> amdgpu_carrizo_sdma1_bin.ko*
> -r-xr-xr-x   1 root  wheel   270K Aug 26 21:20:06 2018 
> amdgpu_carrizo_uvd_bin.ko*
> -r-xr-xr-x   1 root  wheel   176K Aug 26 21:20:06 2018 
> amdgpu_carrizo_vce_bin.ko*
Ok, this looks good. It may be that Bristol is not well supported on DRM 4.9 
yet, I need to check that.
 
> 
> drm-next requires FreeBSD 12, I do not try it yet.
It requires a FreeBSD version equal or higher than 1101511, could you provide 
sysctl kern.osrelease?

Johannes
___
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: APU Bristol Ridge graphics support

[Johannes Dieterich]

On Sunday, September 30, 2018, Rozhuk Ivan wrote:
> On Sun, 30 Sep 2018 18:12:01 +
> Johannes Dieterich  wrote:
> 
> > > I try drm-stable-kmod-g20180822 but it fail to load, as I
> > > understand.  
> > That should work, could you post the error messages? I assume you
> > followed the instructions in the port? 
> 
> 
> # kldload /boot/modules/amdgpu.ko
> 
> [drm] Initialized
> [drm] amdgpu kernel modesetting enabled.
> drmn0:  on vgapci0
> vgapci0: child drmn0 requested pci_enable_io
> vgapci0: child drmn0 requested pci_enable_io
> [drm] initializing kernel modesetting (CARRIZO 0x1002:0x9874 0x1002:0x1E20 
> 0xE2).
> [drm] register mmio base: 0xFE90
> [drm] register mmio size: 262144
> [drm] doorbell mmio base: 0xF000
> [drm] doorbell mmio size: 8388608
> [drm:amdgpu_device_init] 
> Unable to find PCI I/O BAR
> [drm] probing mlw for device 1002:9874 = 0
> [drm] UVD is enabled in physical mode
> [drm] VCE enabled in physical mode
> [drm:amdgpu_atombios_init] Unable to find PCI I/O BAR; using MMIO for ATOM IIO
> ATOM BIOS: BRISTOL
> [drm] GPU post is not needed
> Zone  kernel: Available graphics memory: 3104154 kiB
> Zone   dma32: Available graphics memory: 2097152 kiB
> [TTM] Initializing pool allocator
> drmn0: VRAM: 2048M 0x - 0x7FFF (2048M used)
> drmn0: GTT: 3031M 0x8000 - 0x00013D7667FF
> [drm] Detected VRAM RAM=2048M, BAR=256M
> [drm] RAM width 64bits UNKNOWN
> [drm] amdgpu: 2048M of VRAM memory ready
> [drm] amdgpu: 3031M of GTT memory ready.
> [drm] GART: num cpu pages 776038, num gpu pages 776038
> [drm] PCIE GART of 3031M enabled (table at 0x0004).
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] Driver supports precise vblank timestamp query.
> [drm] amdgpu: irq initialized.
> amdgpu: powerplay initialized
> [drm] Connector DP-1: get mode from tunables:
> [drm]   - kern.vt.fb.modes.DP-1
> [drm]   - kern.vt.fb.default_mode
> [drm] Connector HDMI-A-1: get mode from tunables:
> [drm]   - kern.vt.fb.modes.HDMI-A-1
> [drm]   - kern.vt.fb.default_mode
> [drm] Connector HDMI-A-2: get mode from tunables:
> [drm]   - kern.vt.fb.modes.HDMI-A-2
> [drm]   - kern.vt.fb.default_mode
> [drm] AMDGPU Display Connectors
> [drm] Connector 0:
> [drm]   DP-1
> [drm]   HPD1
> [drm]   DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b
> [drm]   Encoders:
> [drm] DFP1: INTERNAL_UNIPHY
> [drm] Connector 1:
> [drm]   HDMI-A-1
> [drm]   HPD2
> [drm]   DDC: 0x486c 0x486c 0x486d 0x486d 0x486e 0x486e 0x486f 0x486f
> [drm]   Encoders:
> [drm] DFP2: INTERNAL_UNIPHY
> [drm] Connector 2:
> [drm]   HDMI-A-2
> [drm]   HPD3
> [drm]   DDC: 0x4870 0x4870 0x4871 0x4871 0x4872 0x4872 0x4873 0x4873
> [drm]   Encoders:
> [drm] DFP3: INTERNAL_UNIPHY1
> amdgpu/carrizo_pfp.bin: could not load firmware image, error 2
> amdgpu/carrizo_pfp.bin: could not load firmware image, error 2
> amdgpu/carrizo_me.bin: could not load firmware image, error 2
> amdgpu/carrizo_me.bin: could not load firmware image, error 2
> amdgpu/carrizo_ce.bin: could not load firmware image, error 2
> amdgpu/carrizo_ce.bin: could not load firmware image, error 2
> amdgpu/carrizo_rlc.bin: could not load firmware image, error 2
> amdgpu/carrizo_rlc.bin: could not load firmware image, error 2
> amdgpu/carrizo_mec.bin: could not load firmware image, error 2
> amdgpu/carrizo_mec.bin: could not load firmware image, error 2
> amdgpu/carrizo_mec2.bin: could not load firmware image, error 2
> amdgpu/carrizo_mec2.bin: could not load firmware image, error 2
> drmn0: fence driver on ring 0 use gpu addr 0x8010, cpu addr 
> 0x0xf800444aa010
> drmn0: fence driver on ring 1 use gpu addr 0x8020, cpu addr 
> 0x0xf800444aa020
> drmn0: fence driver on ring 2 use gpu addr 0x8030, cpu addr 
> 0x0xf800444aa030
> drmn0: fence driver on ring 3 use gpu addr 0x8040, cpu addr 
> 0x0xf800444aa040
> drmn0: fence driver on ring 4 use gpu addr 0x8050, cpu addr 
> 0x0xf800444aa050
> drmn0: fence driver on ring 5 use gpu addr 0x8060, cpu addr 
> 0x0xf800444aa060
> drmn0: fence driver on ring 6 use gpu addr 0x8070, cpu addr 
> 0x0xf800444aa070
> drmn0: fence driver on ring 7 use gpu addr 0x8080, cpu addr 
> 0x0xf800444aa080
> drmn0: fence driver on ring 8 use gpu addr 0x8090, cpu addr 
> 0x0xf800444aa090
> amdgpu/carrizo_sdma.bin: could not load firmware image, error 2
> amdgpu/carrizo_sdma.bin: could not load firmware image, error 2
> amdgpu/carrizo_sdma1.bin: could not load firmware image, error 2
> amdgpu/carrizo_sdma

Re: APU Bristol Ridge graphics support

[Johannes Dieterich]

On Sunday, September 30, 2018, Rozhuk Ivan wrote:
> On Sun, 30 Sep 2018 17:04:26 +
> Johannes Dieterich  wrote:
> 
> > > A10-9700
> > > Bristol Ridge Radeon R7
> > > 
> > > vgapci0@pci0:0:1:0:   class=0x03 card=0x1e201002
> > > chip=0x98741002 rev=0xe2 hdr=0x00 vendor = 'Advanced Micro
> > > Devices, Inc. [AMD/ATI]' device = 'Wani [Radeon R5/R6/R7
> > > Graphics]' class  = display
> > > subclass   = VGA  
> 
> > Yes, I've had a Bristol Ridge as a daily driver until a few days ago.
> > Use the LinuxKPI based DRM from ports, if you are on CURRENT
> > graphics/drm-devel-kmod, and load amdgpu.ko.
> > 
> 
> I am on 11.2.
> 
> I try drm-stable-kmod-g20180822 but it fail to load, as I understand.
That should work, could you post the error messages? I assume you followed the 
instructions in the port?
 
> Is xf86-video-amdgpu must be used with drm-*-kmod* ?
Yes, you should use the amdgpu DDX with the amdgpu kernel DRM. I used it and it 
works well but you may also be able to use the modesetting DDX, I haven't tried 
that.

Johannes
___
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: APU Bristol Ridge graphics support

[Johannes Dieterich]

On Sunday, September 30, 2018, Rozhuk Ivan wrote:
> Hello!
> 
> Is this graphics supported?
> 
> A10-9700
> Bristol Ridge Radeon R7
> 
> vgapci0@pci0:0:1:0:   class=0x03 card=0x1e201002 chip=0x98741002 rev=0xe2 
> hdr=0x00
> vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
> device = 'Wani [Radeon R5/R6/R7 Graphics]'
> class  = display
> subclass   = VGA
Yes, I've had a Bristol Ridge as a daily driver until a few days ago. Use the 
LinuxKPI based DRM from ports, if you are on CURRENT graphics/drm-devel-kmod, 
and load amdgpu.ko.

Thanks,

Johannes

 ___
> freebsd-sta...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-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: pkg, drm-next-kmod and base packages

[Johannes Dieterich]

Hi

On Wednesday, May 9, 2018, Boris Samorodov wrote:
> Hi All,
> 
> I use self-built base packages. How can I test/use drm-next-kmod?
> Packages for kernel and drm-nex-kmod are in conflict:
> -
> ╰→ sudo pkg install drm-next-kmod-4.11.g20180224
> 
> Updating FreeBSD-base repository catalogue...
> FreeBSD-base repository is up to date.
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> Updating passap repository catalogue...
> passap repository is up to date.
> All repositories are up to date.
> Checking integrity... done (1 conflicting)
>   - drm-next-kmod-4.11.g20180224 [FreeBSD] conflicts with
> FreeBSD-kernel-pkg64x-12.0.s20180509041454 [installed] on
> /boot/modules/drm.ko
> Checking integrity... done (0 conflicting)
> The following 3 package(s) will be affected (of 0 checked):
> 
> Installed packages to be REMOVED:
> FreeBSD-kernel-pkg64x-12.0.s20180509041454
> 
> New packages to be INSTALLED:
> drm-next-kmod: 4.11.g20180224 [FreeBSD]
> gpu-firmware-kmod: g20180206_1 [FreeBSD]
> 
> Number of packages to be removed: 1
> Number of packages to be installed: 2
> 
> The operation will free 91 MiB.
> 
> Proceed with this action? [y/N]:
> -
Since I don't have a system with pkgbase configured, is there a way to figure 
out what files conflict? It surprises me that there are any since we do not 
override anything normally (some kernel modules are indeed overlapping but they 
get installed in different directories).

Thanks,

jmd
___
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: FreeBSD Current on a Compaq h050ng Notebook ( AMD Sea Islands )

[Johannes Dieterich]

Dear Frank,

On Sunday, March 5, 2017, Frank Honolka wrote:
> Hi Guys,
> 
> Few months ago, I've built and installed FreeBSD Current + drm 4.7 on a
> Compaq h050ng with an AMD Sea Island Graphics Card. At this time, the
> system wasn't very stable. I would like to know, how is the support for
> Sea Islands graphics now?
Some improvements were made to amdgpu KMS in drm-next. However, only 2D mode is 
stable for me,  3D still panics (I disable acceleration, Glamor, and GLX in 
xorg.conf). No work that I am aware of was done to radeon KMS (it may profit 
from general improvements though). I think you can run Sea Islands with amdgpu 
KMS, I'd give that a go if I was you.

Please report back if you try anything!

Hope this helps,

Johannes
___
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: problem with USB disks on ALPHA3 w/ recent AMD chipset

[Johannes Dieterich]

On Sat, Jun 18, 2016 at 3:07 PM, Hans Petter Selasky <h...@selasky.org> wrote:
> On 06/18/16 04:15, Johannes Dieterich wrote:
>>
>> Dear list,
>>
>> I observe the following when I try to write to any USB drive:
>>
>> Jun 17 22:02:35 manray kernel: (probe0:umass-sim0:0:0:0): INQUIRY.
>> CDB: 12 00 00 00 24 00
>> Jun 17 22:02:35 manray kernel: (probe0:umass-sim0:0:0:0): CAM status:
>> CCB request completed with an error
>> Jun 17 22:02:35 manray kernel: (probe0:umass-sim0:0:0:0): Retrying command
>> Jun 17 22:02:36 manray kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun
>> 0
>> Jun 17 22:02:36 manray kernel: da0: 
>> Removable Direct Access SPC-4 SCSI device
>> Jun 17 22:02:36 manray kernel: da0: Serial Number 4C530001090427108375
>> Jun 17 22:02:36 manray kernel: da0: 40.000MB/s transfers
>> Jun 17 22:02:36 manray kernel: da0: 15264MB (31260672 512 byte sectors)
>> Jun 17 22:02:36 manray kernel: da0: quirks=0x2
>> Jun 17 22:04:21 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
>> 2a 00 00 00 00 00 00 00 80 00
>> Jun 17 22:04:21 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
>> request completed with an error
>> Jun 17 22:04:21 manray kernel: (da0:umass-sim0:0:0:0): Retrying command
>> Jun 17 22:04:27 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
>> 2a 00 00 00 00 00 00 00 80 00
>> Jun 17 22:04:27 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
>> request completed with an error
>> Jun 17 22:04:27 manray kernel: (da0:umass-sim0:0:0:0): Retrying command
>> Jun 17 22:04:32 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
>> 2a 00 00 00 00 00 00 00 80 00
>> Jun 17 22:04:32 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
>> request completed with an error
>> Jun 17 22:04:32 manray kernel: (da0:umass-sim0:0:0:0): Retrying command
>> Jun 17 22:04:38 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
>> 2a 00 00 00 00 00 00 00 80 00
>> Jun 17 22:04:38 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
>> request completed with an error
>> Jun 17 22:04:38 manray kernel: (da0:umass-sim0:0:0:0): Retrying command
>> Jun 17 22:04:43 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
>> 2a 00 00 00 00 00 00 00 80 00
>> Jun 17 22:04:43 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
>> request completed with an error
>> Jun 17 22:04:43 manray kernel: (da0:umass-sim0:0:0:0): Error 5,
>> Retries exhausted
>> Jun 17 22:05:11 manray kernel: (da0:umass-sim0:0:0:0): got CAM status 0x44
>> Jun 17 22:05:11 manray kernel: (da0:umass-sim0:0:0:0): fatal error,
>> failed to attach to device
>> Jun 17 22:05:11 manray kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun
>> 0
>> Jun 17 22:05:11 manray kernel: da0:  s/n
>> 4C530001090427108375 detached
>> Jun 17 22:05:17 manray kernel: (da0:umass-sim0:0:0:0): Periph destroyed
>>
>> I.e., when I dd, the dd exists prematurely with an error.
>>
>> pciconf:
>>
>> hostb0@pci0:0:0:0: class=0x06 card=0x15761022 chip=0x15761022
>> rev=0x00 hdr=0x00
>> vendor = 'Advanced Micro Devices, Inc. [AMD]'
>> class = bridge
>> subclass = HOST-PCI
>> none0@pci0:0:0:2: class=0x080600 card=0x15771022 chip=0x15771022
>> rev=0x00 hdr=0x00
>> vendor = 'Advanced Micro Devices, Inc. [AMD]'
>> class = base peripheral
>> subclass = IOMMU
>> vgapci0@pci0:0:1:0: class=0x03 card=0x807e103c chip=0x98741002
>> rev=0xc4 hdr=0x00
>> vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
>> device = 'Carrizo'
>> class = display
>> subclass = VGA
>> hdac0@pci0:0:1:1: class=0x040300 card=0x807e103c chip=0x98401002
>> rev=0x00 hdr=0x00
>> vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
>> device = 'Kabini HDMI/DP Audio'
>> class = multimedia
>> subclass = HDA
>> hostb1@pci0:0:2:0: class=0x06 card=0x chip=0x157b1022
>> rev=0x00 hdr=0x00
>> vendor = 'Advanced Micro Devices, Inc. [AMD]'
>> class = bridge
>> subclass = HOST-PCI
>> pcib1@pci0:0:2:1: class=0x060400 card=0x12341022 chip=0x157c1022
>> rev=0x00 hdr=0x01
>> vendor = 'Advanced Micro Devices, Inc. [AMD]'
>> class = bridge
>> subclass = PCI-PCI
>> pcib2@pci0:0:2:3: class=0x060400 card=0x12341022 chip=0x157c1022
>> rev=0x00 hdr=0x01
>> vendor = 'Advanced Micro Devices, Inc. [AMD]'
>> class = bridge
>> subclass = PCI-PCI
>> pcib3@pci0:0:2:5: class=0x060400 card=0x12341022 chip=0x157c1022
>> rev=0x00 hdr=0x01
>> vendor = 'Advanced Micro Devices, Inc. [AMD]'
>> class = bridge
>> subclass = PCI-PCI
>&

problem with USB disks on ALPHA3 w/ recent AMD chipset

[Johannes Dieterich]

Dear list,

I observe the following when I try to write to any USB drive:

Jun 17 22:02:35 manray kernel: (probe0:umass-sim0:0:0:0): INQUIRY.
CDB: 12 00 00 00 24 00
Jun 17 22:02:35 manray kernel: (probe0:umass-sim0:0:0:0): CAM status:
CCB request completed with an error
Jun 17 22:02:35 manray kernel: (probe0:umass-sim0:0:0:0): Retrying command
Jun 17 22:02:36 manray kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
Jun 17 22:02:36 manray kernel: da0: 
Removable Direct Access SPC-4 SCSI device
Jun 17 22:02:36 manray kernel: da0: Serial Number 4C530001090427108375
Jun 17 22:02:36 manray kernel: da0: 40.000MB/s transfers
Jun 17 22:02:36 manray kernel: da0: 15264MB (31260672 512 byte sectors)
Jun 17 22:02:36 manray kernel: da0: quirks=0x2
Jun 17 22:04:21 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
2a 00 00 00 00 00 00 00 80 00
Jun 17 22:04:21 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
request completed with an error
Jun 17 22:04:21 manray kernel: (da0:umass-sim0:0:0:0): Retrying command
Jun 17 22:04:27 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
2a 00 00 00 00 00 00 00 80 00
Jun 17 22:04:27 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
request completed with an error
Jun 17 22:04:27 manray kernel: (da0:umass-sim0:0:0:0): Retrying command
Jun 17 22:04:32 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
2a 00 00 00 00 00 00 00 80 00
Jun 17 22:04:32 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
request completed with an error
Jun 17 22:04:32 manray kernel: (da0:umass-sim0:0:0:0): Retrying command
Jun 17 22:04:38 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
2a 00 00 00 00 00 00 00 80 00
Jun 17 22:04:38 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
request completed with an error
Jun 17 22:04:38 manray kernel: (da0:umass-sim0:0:0:0): Retrying command
Jun 17 22:04:43 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB:
2a 00 00 00 00 00 00 00 80 00
Jun 17 22:04:43 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB
request completed with an error
Jun 17 22:04:43 manray kernel: (da0:umass-sim0:0:0:0): Error 5,
Retries exhausted
Jun 17 22:05:11 manray kernel: (da0:umass-sim0:0:0:0): got CAM status 0x44
Jun 17 22:05:11 manray kernel: (da0:umass-sim0:0:0:0): fatal error,
failed to attach to device
Jun 17 22:05:11 manray kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
Jun 17 22:05:11 manray kernel: da0:  s/n
4C530001090427108375 detached
Jun 17 22:05:17 manray kernel: (da0:umass-sim0:0:0:0): Periph destroyed

I.e., when I dd, the dd exists prematurely with an error.

pciconf:

hostb0@pci0:0:0:0: class=0x06 card=0x15761022 chip=0x15761022
rev=0x00 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = bridge
subclass = HOST-PCI
none0@pci0:0:0:2: class=0x080600 card=0x15771022 chip=0x15771022
rev=0x00 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = base peripheral
subclass = IOMMU
vgapci0@pci0:0:1:0: class=0x03 card=0x807e103c chip=0x98741002
rev=0xc4 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
device = 'Carrizo'
class = display
subclass = VGA
hdac0@pci0:0:1:1: class=0x040300 card=0x807e103c chip=0x98401002
rev=0x00 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
device = 'Kabini HDMI/DP Audio'
class = multimedia
subclass = HDA
hostb1@pci0:0:2:0: class=0x06 card=0x chip=0x157b1022
rev=0x00 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = bridge
subclass = HOST-PCI
pcib1@pci0:0:2:1: class=0x060400 card=0x12341022 chip=0x157c1022
rev=0x00 hdr=0x01
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = bridge
subclass = PCI-PCI
pcib2@pci0:0:2:3: class=0x060400 card=0x12341022 chip=0x157c1022
rev=0x00 hdr=0x01
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = bridge
subclass = PCI-PCI
pcib3@pci0:0:2:5: class=0x060400 card=0x12341022 chip=0x157c1022
rev=0x00 hdr=0x01
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = bridge
subclass = PCI-PCI
hostb2@pci0:0:3:0: class=0x06 card=0x chip=0x157b1022
rev=0x00 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = bridge
subclass = HOST-PCI
none1@pci0:0:8:0: class=0x108000 card=0x15781022 chip=0x15781022
rev=0x00 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = encrypt/decrypt
hostb3@pci0:0:9:0: class=0x06 card=0x chip=0x157d1022
rev=0x00 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = bridge
subclass = HOST-PCI
hdac1@pci0:0:9:2: class=0x040300 card=0x807e103c chip=0x157a1022
rev=0x00 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
class = multimedia
subclass = HDA
xhci0@pci0:0:16:0: class=0x0c0330 card=0x807e103c chip=0x79141022
rev=0x20 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'FCH USB XHCI Controller'
class = serial bus
subclass = USB
ahci0@pci0:0:17:0: class=0x010601 card=0x807e103c chip=0x79011022
rev=0x49 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'FCH SATA Controller [AHCI mode]'
class = 

Re: extremely slow to get to loader

[Johannes Dieterich]

On Thu, Apr 21, 2016 at 12:16 PM, Allan Jude <allanj...@freebsd.org> wrote:
> On 2016-04-21 10:46, Johannes Dieterich wrote:
>> Dear all,
>>
>> with r298385, I observe extremely long times from turning on my laptop
>> to reach loader. This is a regression compared to a roughly 1 week old
>> CURRENT.
>>
>> This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup.
>>
>> Please let me know how I can help to solve this issue.
>>
>> Thanks,
>>
>> Johannes
>> ___
>> 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"
>>
>
> Can you describe where exactly it is slow?
Yes, it hangs after "BIOS drive C: is disk 0" for a good 3 minutes
before it eventually continues.

> Once you get to the loader menu (the beastie menu), can you choose the
> option to go to the loader prompt, and type:
> bcachestat
>
> And provide the output of that.
Here we go (w/o mistakes I hope...):
cache blocks: 32768
cache blocksz: 572
unit cache blocks: 32768
cached units: 1
1162 ops 0 bypasses 12109 hits 739 misses

Thanks so much for the response!

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

extremely slow to get to loader

[Johannes Dieterich]

Dear all,

with r298385, I observe extremely long times from turning on my laptop
to reach loader. This is a regression compared to a roughly 1 week old
CURRENT.

This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup.

Please let me know how I can help to solve this issue.

Thanks,

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

failure to enumerate AMD Carrizo boost states

[Johannes Dieterich]

Dear all,

I run CURRENT on a laptop with an AMD Carrizo (A12-8800B) which should
have multiple boost states (Pb) according to the official
specifications (see [1] and [2] pages 59 and 63). CURRENT fails to
enumerate them and therefore only runs at base clock.

A thread on freebsd-acpi [3] did unfortunately not help much, so I am
hoping that the wider audience here may help?

Thanks a lot for your time!

Johannes

[1] 
http://products.amd.com/en-us/search/APU/AMD-PRO-A-Series-Processors/AMD-PRO-A-Series-A12-APU-for-Laptops/AMD-PRO-A12-8800B-with-Radeon%E2%84%A2-R7-Graphics/164
[2] http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf
[3] 
http://freebsd.1045724.n5.nabble.com/AMD-A12-8800B-ACPI-questions-turbo-mode-temp-zones-td6059935.html
___
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: Intel Haswell support - Any updates?

[Johannes Dieterich]

Hi,

just chipping into the conversation for a detail Re: OpenCL

On Thu, Sep 17, 2015 at 1:21 PM, Shawn Webb  wrote:
> On Thu, Sep 17, 2015 at 07:00:15PM +0200, Jean-S??bastien P??dron wrote:
>> Now about other related tasks:
>> o  A Mesa update will be committed Real Soon Now?. It will unlock
>>GLAMOR and OpenCL support.
>
> OpenCL on FreeBSD would be stupendously amazing!
Not would: is! :-) You can already use OpenCL on radeon and Intel GPUs
(note, only single-precision for Intel, this is an upstream issue) or
on CPU as fallback when using the mesa-next branch from the
freebsd-graphics github. This does not require an update of the kernel
compared to CURRENT (of course only supported GPUs work). There are
some helper ports in the github as well (libraries, e.g.) if you write
your own OpenCL software and I have a few more in my pipeline. I
personally have an interest in excellent OpenCL support on FBSD.

Getting back to building the i915 update.

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

reproducible kernel panic on CURRENT, I/O related

[Johannes Dieterich]

Dear all,

since approximately three weeks I am seeing kernel panics on CURRENT
that are in so far reproducible as that they typically occur when I
run svn up on the ports tree. Hence, it seems I/O related to me. Sorry
that I only now got around to reporting it!

The system is a CURRENT amd64 running ZFS on root w/ GELI. It has the
aesni kernel module loaded. The world and kernel are on SVN r285764.

The kernel stack backtrace looks as follows (transcript):

db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe03d0394830
vpanic() at vpanic+0x189/frame 0xe03d03948b0
panic() at panic+0x43/frame 0xfe03d0394910
trash_ctor() at trash_ctor+0x48/frame 0xfe03d0394920
uma_zalloc_arg() at uma_zalloc_arg+0x573/frame 0xfe03d0394990
g_clone_bio() at g_clone_bio+0x1d/frame 0xfe03d03949b0
g_part_start() at g_part_start+0x8e/frame 0xfe03d0394a30
g_io_schedule_down() at g_io_schedule_down+0xe6/frame 0xfe03d0394a60
g_down_procbody() at g_down_procbody+0x7d/frame 0xfee03d0394a70
fork_exit() at fork_exit+0x84/frame 0xfe03d0394ab0
fork_trampoline at fork_trampoline+0xe/frame 0xfe03d0394ab0
--- trap 0, rip = 0, rsp =0xfe03d0394b90, rbp = 0---
KDB: enter: panic
[ thread pid 13 tid 100017 ]
Stopped at kdb_enter+0x3e: movq $0,kdb_why

Due to above setup, I cannot provide a core file, sorry.

Please let me know if there is any data you want me to obtain for
debugging. As I said above, it is fairly simple for me to hit the
panic.

Best

Johannes
___
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: [Call for testers] DRM device-independent code update to Linux 3.8

[Johannes Dieterich]

Dear Jean,

thanks for your work!

I built a recent git checkout of the kms38-branch on both a i5-3320M
(w/ HD4000) and an AMD FirePro V4900. Works absolutely fine, the only
minor issue is that there seemingly is a small performance regression
w/ clover. However, I didn't yet have time to dig into this and make
sure that indeed something is off.

HTH

Johannes

On Wed, Feb 18, 2015 at 12:45 AM, Jean-Sébastien Pédron
dumbb...@freebsd.org wrote:
 Hi!

 An update to the DRM subsystem, not including the drivers, is ready for
 wider testing!

 The patch against HEAD is here:
 https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch

 I'm interested in success/failure reports for amd64, powerpc and
 powerpc64 users, for i915 and Radeon GPUs. I already know there is a
 build issue on i386, please wait for the next patch if you are in this case.

 The changes brought by this patch are explained in a blog post:
 http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/

 This is working well for some Radeon users for more than a year.
 However, it only started to work with i915 a month ago, when the i915
 refresh was committed.

 Try your day-to-day applications, try suspend/resume, try all output
 connectors, try OpenGL stuff, try backlight controls, everything :)

 Thank you!

 --
 Jean-Sébastien Pédron

___
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: logged errors with current drm stuff

[Johannes Dieterich]

Hi,

On Thu, Jan 22, 2015 at 4:21 PM, Mikhail mp39...@gmail.com wrote:
 On 07:32 22-Jan 2015 Adrian Chadd wrote:
 Hi!

 I'm seeing this with your patch now:

 error: [drm:pid5:i915_gem_object_unbind] *ERROR* Attempting to unbind
 pinned buffer

 Nothing seems to be problematic at the moment; but it does seem to
 happen quite frequently.

 Any ideas?

 To add on this, with latest DRM I've lost ability to change my backlight
 on Lenovo E530.

 From /var/log/messages:

 error: [drm:pid790:gen6_sanitize_pm] *ERROR* Power management discrepancy: 
 GEN6_RP_INTERRUPT_LIMITS expected 1600, was 1200
 error: [drm:pid790:gen6_sanitize_pm] *ERROR* Power management discrepancy: 
 GEN6_RP_INTERRUPT_LIMITS expected 1607, was 1600
 error: [drm:pid790:gen6_sanitize_pm] *ERROR* Power management discrepancy: 
 GEN6_RP_INTERRUPT_LIMITS expected 0007, was 1607
That one has been in the patch since October for me (see:
http://permalink.gmane.org/gmane.os.freebsd.current/161187 ) on a
i5-3320M. I however could not observe any impact of the error for my
usage beyond the flooded messages. I am not sure if it has to do with
the backlight changes you triggered as I certainly didn't change mine
and still got them.

Johannes
___
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: nvidia-driver fails to load gui

[Johannes Dieterich]

Hi,

On Wed, Dec 10, 2014 at 5:31 PM, Shawn Webb latt...@gmail.com wrote:

 On Wed, Dec 10, 2014 at 11:27 AM, Henry Hu henry.hu...@gmail.com wrote:

 
 
  On Wed, Dec 10, 2014 at 11:25 AM, Shawn Webb latt...@gmail.com wrote:
 
  On Wed, Dec 10, 2014 at 11:22 AM, Henry Hu henry.hu...@gmail.com
 wrote:
 
 
 
  On Wed, Dec 10, 2014 at 11:17 AM, Shawn Webb latt...@gmail.com
 wrote:
 
  On Wed, Dec 10, 2014 at 11:14 AM, Henry Hu henry.hu...@gmail.com
  wrote:
 
 
 
  On Wed, Dec 10, 2014 at 11:02 AM, Shawn Webb latt...@gmail.com
  wrote:
 
  Hey All,
 
  More new laptop woes. The good-ish news is that the VESA driver
  works, but
  x11/nvidia-driver doesn't. I'm on a Lenovo Y50-70. When I run
  `startx`, it
  appears that xorg switches to a new vty, but doesn't actually bring
  up the
  UI. I see a new console (as in vty) with a cursor at the top left
  corner.
 
  xorg.conf is pasted here: http://ix.io/1Dr
  Xorg.0.log is pasted here: http://ix.io/1Dq
 
  I'll just use the VESA driver for now, but it'd be nice to be able
 to
  hook
  the laptop up to a second monitor or a projector, which I can't do
  with the
  VESA driver.
 
 
  Is it an optimus laptop? Have you tried uninstalling nvidia driver
 and
  try the intel driver?
 
 
  It's a Lenovo Y50-70, which is running Intel Haswell, so the intel
  driver won't work.
 
 
  I'm afrad that the nvidia card would not work either, at least for the
  internal LCD.
  Some optimus cards only provide 3d acceleration, and some are only
  connected to HDMI/DisplayPort outputs. Have you tried other outputs on
 the
  laptop?
 
 
  I haven't tried the other outputs. My primary output will be the
 internal
  LCD. What would it take to get it to work?
 
 
  Wait for the kernel driver update which would support Haswell graphics?
 

 Who's in charge of that? I've pinged kib@ privately with no reply. Is
 there
 a patchset that I can help test out on 11-current? What's the status? I'd
 love to help get the Haswell update out the door, especially now that I
 have multiple systems running Haswell.

you may be aware, there was
https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052532.html
(and v2 of the patch) from kib@ that I and others gave a spin. The second
version worked fine for me (including xorg-experimental repo w/ the Intel
3.0beta driver). Note however that this does not really include Haswell
support according to kib@  but he seems to run it on a Haswell system.
Maybe this helps?

Other than that, I have heard to news (and I am eager to test...).

HTH

Johannes
___
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: NVidia Tesla K40

[Johannes Dieterich]

Dear Jean-Sebastien,

just to chime in on one aspect I care about:

On Sun, Nov 2, 2014 at 11:25 AM, Jean-Sébastien Pédron dumbb...@freebsd.org
 wrote:

 On 31.10.2014 17:46, John Dison wrote:
  Hello!

 Hi!

  I want to use NVidia Tesla K40 GPU for parallel computing.Does
  FreeBSD support such a hardware?

 As O. Hartmann explained, we don't support GPGPU on NVIDIA hardware,
 neither with the binary driver because NVIDIA doesn't provide any
 libOpenCL.so for FreeBSD, nor with the FOSS driver because we don't have
 the kernel video driver.

 On the AMD front, GPGPU works with the open-source stack (libclc and
 Clover, Mesa's libOpenCL.so), but the Clover port isn't committed yet.
 We didn't have the time to polish it so far (only libclc is available in
 devel/libclc).

 Note that Clover is still a WIP. Here's a matrix of implemented and
 missing features:
 http://dri.freedesktop.org/wiki/GalliumCompute/

 When I tried it with simple programs found on the Net, it worked.
 However, I couldn't use it with graphics/darktable:
 1) Currently, the amount of memory reported by Clover is hard-coded
 2) darktable expects features not implemented

IMHO, a very good and relevant test is clBLAS (
https://github.com/clMathLibraries/clBLAS ). Anything HPC will require
these functions to work properly and (albeit computationally demanding)
they are well controllable for benchmarks (in terms of setup and memory
dimensioning).

Coming from a HPC background, the next step would be something like MAGMA (
http://icl.cs.utk.edu/magma/software/index.html ) which uses clBLAS and
adds some LAPACK-style functionality to it. Again, well controllable and
computationally challenging.

I am happy to act as tester, btw.

Looking forward to this landing in BSD, thanks so much for your and all of
the graphics teams work!

Johannes
___
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: Ver 2 of the patch [was: Re: i915 driver update testing]

[Johannes Dieterich]

Hi,

I can confirm v6 of the patch works for me with a r273559 kernel on a
i5-3320M notebook as well.

Only interesting new output to messages:

Oct 25 23:11:19 kernel: error: [drm:pid1159:gen6_sanitize_pm] *ERROR* Power
management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 0007, was
1807
Oct 25 23:11:28 kernel: error: [drm:pid1159:gen6_sanitize_pm] *ERROR* Power
management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1807, was

Oct 25 23:11:36 kernel: error: [drm:pid1159:gen6_sanitize_pm] *ERROR* Power
management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1807, was
1800
Oct 25 23:11:48 kernel: error: [drm:pid1159:gen6_sanitize_pm] *ERROR* Power
management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1807, was
1800

Thanks a lot!

Johannes

On Thu, Oct 23, 2014 at 9:03 PM, Konstantin Belousov kostik...@gmail.com
wrote:

 On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote:
  On 10/22/2014 08:26, Konstantin Belousov wrote:
   On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote:
   On 10/08/2014 13:05, Konstantin Belousov wrote:
   There are more occurences of the bug I fixed once in patch version 2.
   Also, since pmap changes were committed in modified form, please try
   the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch .
  
  
   No apparent change:
   http://www.egr.msu.edu/~mcdouga9/i915-patch3-1.txt
   cite (kgdb) p *(struct drm_i915_private *)(dev_private)
   cite No symbol dev_private in current context.
  
   This is p *(struct drm_i915_private *)(dev-dev_private)
 
  http://www.egr.msu.edu/~mcdouga9/dev_private.txt
 
  
   I regenerated patch after recent merges and changes in KPI on HEAD.
   https://www.kib.kiev.ua/kib/drm/i915.4.patch
  
   Please apply it, I think the issue should be there still.  Then apply
   the following debugging patch, and set
   kenv drm.debug=0x3
   before loading i915kms.ko.  I want to see the same debugging
 information,
   and dmesg from the moment of loading the driver.
  
 
   In fact, try
   https://www.kib.kiev.ua/kib/drm/i915.5.patch
 Due to my mistake during the patch generation, i915.5.patch is just
 a garbage.

 Use https://www.kib.kiev.ua/kib/drm/i915.6.patch.  I already have one
 private report of the patch worked from person who got the same panic
 in iicbb.
 ___
 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

___
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: i915 driver update testing

[Johannes Dieterich]

Dear all,

sorry for cross-posting (I am not subscribed to x11@).

Same behavior for me (i5-3320M on a Thinkpad T430s w/ Optimus support) as
reported by Maurizio.

When boot switches to graphics from text mode, display remains black with
backlight on. I am running the experimental xorg-stack from
https://trillian.chruetertee.ch/svn/ports/branches/experimental which works
with an unmodified r272482 w/o problem (minus the Optimus, obviously).

No entry in Xorg.0.log. /var/log/messages only contains output from
consolekit, saying it waits for a native display on tty 9.

Please let me know if you want me to test anything further.

Best

Johannes

On Fri, Oct 3, 2014 at 7:02 PM, Konstantin Belousov kostik...@gmail.com
wrote:

 Please find at the
 https://kib.kiev.ua/kib/drm/i915.1.patch
 a patch which provides some updates to the i915 driver. At large, this
 is import of the batch of Linux commits, and as such, it is interesting
 mostly as attempt to restart the race to get us more up to date Linux code
 imported. It might provide some bug fixes, most likely for IvyBridge.
 Interesting from the development PoV is the update of the GEM i/o ioctl
 code path to mimic Linux code structure.

 I am asking _only_ for reports of regressions with the patch applied,
 comparing with the code which is currently in HEAD. I will not debug
 any existing bugs, my goal right now is to commit this update, which is
 needed for further work. I.e., only when you get an issue with the patch
 applied, but cannot reproduce the problem without the patch, please
 prepare a bug report.

 FYI, the driver will attach to haswell gfx, but I am not interested in
 reports about this (see above paragraph). On my test box, which is Core
 i7 4770S, the mode-setting and front-buffer rendering works, but Mesa
 immediately cause renderer to bug out.

 Work was sponsored by The FreeBSD Foundation, both by time and hardware,
 and Intel provided access to the documentation.
 ___
 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

___
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

Missing /boot on ZFS+GEOM_ELI setup at boot time

[Johannes Dieterich]

Dear all,

there seems to be a regression in FBSD-10 w.r.t. ZFS+GELI setups again. For
a reference to the first time this happened:
http://lists.freebsd.org/pipermail/freebsd-fs/2013-July/017899.html . After
that time, I added (as recommended) the previously default lines on the
zpool caches to /boot/loader.conf.

zpool_cache_load=YES
zpool_cache_type=/boot/zfs/zpool.cache
zpool_cache_name=/boot/zfs/zpool.cache

The setup is as follows: one drive, two ZFS pools, one for /boot (bootdir)
and one on a GEOM_ELI layer for the rest of / (zroot). This setup is
probably very close to what e.g. pjd@ runs according to above reference (so
it is not quite the oddball config it was made to sound like in above
thread). /boot then is a softlink to the other pool (bootdir/boot)

After upgrading to r255479 from a maximum two weeks old CURRENT the
following happens:

* kernel loads and boots fine (including modules specified in loader.conf)
* DRM load fails, iwn firmware load fails
* VESA based Xorg works
* /boot is a broken symlink as bootdir vanished, zpool list only shows the
GELI based pool

Same happens in single user mode.

I can zpool import the missing pool (at least something) after that.

Could somebody help me to get my bootdir back permanently and at boot time?
That would be great since as of now, I am stuck with VESA mode graphics and
no WLAN.

Also, if this continues to break at random times: can I consider this setup
officially unsupported and advised against? If so, it would be great if
there was an officially recommended setup for this rather standard problem
(notebook: one drive, all ZFS, encryption wanted)?

Thanks a lot

Johannes
___
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: svn error during 'make buildkernel'?

[Johannes Dieterich]

Hi,

On 08/04/13 19:23, Steve Kargl wrote:

On Sat, Aug 03, 2013 at 05:43:13PM -0400, Glen Barber wrote:

On Sat, Aug 03, 2013 at 02:30:23PM -0700, Steve Kargl wrote:


Thanks.

Looks like an entry in /usr/src/UPDATING is missing if
/usr/bin/svn* is forcing an obsolscence of a functioning
installed port.



The port was at 1.8.x before I added the additional lookup of
svnlite to the script.  There really is no need for UPDATING entry,
since 1.7.9 is deprecated, and the behavior you have seen is not a fatal
error with the buildkernel process.

BTW, you should upgrade devel/subversion anyway, since there are
security vulnerabilities.



Here's a perfect example why chasing the bleeding edge ports
is a stupid idea.  After upgrading devel/subversion as you
suggested, I see

cd /usr/ports
% svn upgrade
% svn update
Updating '.':
svn: E17: Unrecognized URL scheme for 'http://svn.freebsd.org/ports/head'
% svn --version | grep version
svn, version 1.8.1 (r1503906)
% which svn
/usr/local/bin/svn
%which svnlite
/usr/bin/svnlite
% svnlite --version | grep version
svn, version 1.8.1 (r1503906)
Subversion is open source software, see http://subversion.apache.org/
% svnlite
% svnlite update
Updating '.':
Uwww/squid33/distinfo
Uwww/squid33/files/squid.in
Uwww/squid33/Makefile
Ucad/gmsh/Makefile
Ucad/gmsh/distinfo
Ucad/gmsh/pkg-plist
Ulang/gcc47/Makefile
Ulang/gcc47/distinfo
Ulang/gdc/Makefile
Ux11-clocks/xdaliclock/Makefile
Ux11-clocks/xdaliclock/distinfo
Unet-mgmt/virt-viewer/Makefile
Unet-mgmt/virt-viewer/distinfo
Unet-mgmt/virt-viewer/pkg-plist
Ux11/xfwp/Makefile
Ux11/xfwp/distinfo
Updated to revision 324253.

So, how do I fix svn, now?
You need to enable the SERF option for the port and rebuild, it is now 
required to be able to access http/https-type repositories.


Hope this helps

Johannes

___
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: openjdk6 broken on current

[Johannes Dieterich]

Hi,

On 05/13/13 14:20, Jung-uk Kim wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2013-05-11 05:25:41 -0400, O. Hartmann wrote:

On Thu, 2013-05-09 at 17:16 -0500, Larry Rosenman wrote:

On 2013-05-09 06:16, Damjan Jovanovic wrote:

On Wed, May 8, 2013 at 8:52 PM, Larry Rosenman l...@lerctr.org
wrote: On 2013-05-08 13:37, Larry Rosenman wrote:

On 2013-05-08 12:46, Larry Rosenman wrote: On 2013-05-08 12:00,
Daniel Eischen wrote: On Wed, 8 May 2013, Daniel Eischen
wrote:

On Wed, 8 May 2013, Larry Rosenman wrote:

Daniel Eischen deisc...@freebsd.org wrote: On Wed, 8 May
2013, Larry Rosenman wrote:

Can SOMEONE please look at this?

I have a real need to get java back on my -CURRENT server
soon.

Did/can you try just backing out r249606?

-- DE

How can I generate a patch to do that?

Go here:


http://svnweb.freebsd.org/base/head/lib/libthr/thread/thr_sig.c?sortby=dateview=log




then click on Diff to previous 249606, then click on Patch

at the top.  You can try backing out each/all of the recent
changes to thr_sig.c to see what the culprit is.

You'll have to use -R to reverse the patch I believe.

Or, if you have a checked out svn repo, you can always use svn
to generate the patch:

$ cd /path/to/svn/src $ svn diff -r249606:249605  # no need to
use -R on this patch I've done this, and dealt with a chunk
reject, and am recompiling the world.

Will let you know if this fixes it.. Still fails.

/bin/mkdir -p

/usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi



rm -f


/usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class



/usr/ports/java/openjdk6/work/build/bsd-amd64/bin/java  -Xmx896m

-Xms128m -cp
/usr/ports/java/openjdk6/work/build/bsd-amd64/classes
sun.rmi.rmic.Main -classpath
/usr/ports/java/openjdk6/work/build/bsd-amd64/classes\ -d
/usr/ports/java/openjdk6/work/build/bsd-amd64/classes
\ -v1.2   \ -keepgenerated
\ javax.management.remote.rmi.RMIConnectionImpl /bin/mkdir -p

/usr/ports/java/openjdk6/work/build/bsd-amd64/gensrc/javax/management/remote/rmi



/bin/cp


/usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.java



\


/usr/ports/java/openjdk6/work/build/bsd-amd64/gensrc/javax/management/remote/rmi



/usr/ports/java/openjdk6/work/build/bsd-amd64/bin/java  -Xmx896m

-Xms128m -cp
/usr/ports/java/openjdk6/work/build/bsd-amd64/classes
sun.rmi.rmic.Main -classpath
/usr/ports/java/openjdk6/work/build/bsd-amd64/classes\ -d
/usr/ports/java/openjdk6/work/build/bsd-amd64/classes
\ -iiop -v1.2 \
javax.management.remote.rmi.RMIConnectionImpl gmake[5]: ***

[/usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class]



Segmentation fault (core dumped)

gmake[5]: *** Deleting file

`/usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class'



gmake[5]: Leaving directory

`/usr/ports/java/openjdk6/work/jdk/make/com/sun/jmx' gmake[4]:
*** [all] Error 1 gmake[4]: Leaving directory
`/usr/ports/java/openjdk6/work/jdk/make/com/sun' gmake[3]: ***
[all] Error 1 gmake[3]: Leaving directory
`/usr/ports/java/openjdk6/work/jdk/make/com' gmake[2]: ***
[all] Error 1 gmake[2]: Leaving directory
`/usr/ports/java/openjdk6/work/jdk/make' gmake[1]: ***
[jdk-build] Error 2 gmake[1]: Leaving directory
`/usr/ports/java/openjdk6/work' gmake: ***
[build_product_image] Error 2 *** [do-build] Error code 1

Stop in /usr/ports/java/openjdk6. *** [build] Error code 1

Stop in /usr/ports/java/openjdk6.

=== make failed for java/openjdk6 === Aborting update

=== Killing background jobs Terminated

=== You can restart from the point of failure with this
command line: portmaster flags java/openjdk6

=== Exiting # #


I **CAN** give SSH/SUDO access to whoever.

(gdb) bt

#0  0x000801e2da93 in JVM_handle_bsd_signal () from
/usr/ports/java/openjdk6/work/build/bsd-amd64/lib/amd64/server/libjvm.so



#1  0x000800a49136 in swapcontext () from /lib/libthr.so.3


#2  0x000800a48d39 in sigaction () from /lib/libthr.so.3 #3
0x71d3 in ?? () #4  0x000800a48c20 in sigaction
() from /lib/libthr.so.3 #5  0x000801ba9540 in
Deoptimization::unpack_frames () from
/usr/ports/java/openjdk6/work/build/bsd-amd64/lib/amd64/server/libjvm.so



#6  0x000803869f7e in ?? ()

#7  0x7fbfa450 in ?? ()

#8  0x00080383b828 in ?? () #9  0x00080685e6e0 in ??
() #10 0x00080684f000 in ?? () #11 0x7fbfa4a0 in ??
() #12 0x7fbfa518 in ?? ()

#13 0x00080308f000 in ?? () #14 0x000806bac750 in ??
()

#15 0x000803869eb9 in ?? () #16 0x in ??
() (gdb)

That backtrace would probably be clearer if you got it from a
debug build of OpenJDK. Also you could find the exact commit
that broke it by doing a bisection-search in SVN like git
bisect would do.

Regards Damjan 

Headphone support on Thinkpad T430s

[Johannes Dieterich]

Dear list,

please see a patch to enable proper headphone support on Thinkpad T430s 
models. The quirk uses the same logic as the recent patch to CURRENT to 
enable some other Thinkpad models. Unfortunately, I cannot comment if 
this will work for other models (such as the regular T430) as well, 
therefore I used the T430S identifier.


Hope someone can commit this,

Johannes
Index: sys/dev/sound/pci/hda/hdaa_patches.c
===
--- sys/dev/sound/pci/hda/hdaa_patches.c(revision 248186)
+++ sys/dev/sound/pci/hda/hdaa_patches.c(working copy)
@@ -344,7 +344,8 @@
break;
}
} else if (id == HDA_CODEC_ALC269 
-   subid == LENOVO_X1CRBN_SUBVENDOR) {
+   (subid == LENOVO_X1CRBN_SUBVENDOR ||
+subid == LENOVO_T430S_SUBVENDOR)) {
switch (nid) {
case 21:
patch = as=1 seq=15;
Index: sys/dev/sound/pci/hda/hdac.h
===
--- sys/dev/sound/pci/hda/hdac.h(revision 248186)
+++ sys/dev/sound/pci/hda/hdac.h(working copy)
@@ -218,13 +218,14 @@
 #define LENOVO_VENDORID0x17aa
 #define LENOVO_3KN100_SUBVENDORHDA_MODEL_CONSTRUCT(LENOVO, 0x2066)
 #define LENOVO_3KN200_SUBVENDORHDA_MODEL_CONSTRUCT(LENOVO, 0x384e)
-#define LENOVO_B450_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x3a0d)
+#define LENOVO_B450_SUBVENDOR   HDA_MODEL_CONSTRUCT(LENOVO, 0x3a0d)
 #define LENOVO_TCA55_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x1015)
 #defineLENOVO_X1_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x21e8)
 #defineLENOVO_X1CRBN_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x21f9)
 #define LENOVO_X220_SUBVENDOR  HDA_MODEL_CONSTRUCT(LENOVO, 0x21da)
 #define LENOVO_X300_SUBVENDOR  HDA_MODEL_CONSTRUCT(LENOVO, 0x20ac)
 #defineLENOVO_T420_SUBVENDOR   HDA_MODEL_CONSTRUCT(LENOVO, 0x21ce)
+#define LENOVO_T430S_SUBVENDOR  HDA_MODEL_CONSTRUCT(LENOVO, 0x21fb)
 #defineLENOVO_T520_SUBVENDOR   HDA_MODEL_CONSTRUCT(LENOVO, 0x21cf)
 #define LENOVO_ALL_SUBVENDOR   HDA_MODEL_CONSTRUCT(LENOVO, 0x)
 
___
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: Headphone support on Thinkpad T430s

[Johannes Dieterich]

On 03/12/13 03:34, Sergey V. Dyatko wrote:

On Tue, 12 Mar 2013 00:28:45 -0700
hiren panchasara hiren.panchas...@gmail.com wrote:


On Tue, Mar 12, 2013 at 12:09 AM, Johannes Dieterich
dieterich@gmail.com wrote:

Dear list,

please see a patch to enable proper headphone support on Thinkpad
T430s models. The quirk uses the same logic as the recent patch to
CURRENT to enable some other Thinkpad models. Unfortunately, I
cannot comment if this will work for other models (such as the
regular T430) as well, therefore I used the T430S identifier.

For T430, the pins are at 0x21f3 so you assumed right. This patch
would not work on it.
T430S is the correct identifier.



and don't touch my B450 please :)

Sorry, just formatting. Otherwise it is unchanged. :-)

Best

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

new xorg segfault 11 with KMS

[Johannes Dieterich]

Dear all,

I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and
WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly
causes the segfault (log attached), gnome survives a bit longer but
starting any bigger application (e.g. firefox) causes it to crash with the
same log.

I have a Xorg.core file, but since it is without debug symbols the
backtrace makes little sense to me.

Unfortunately, I cannot tell what is the root cause of the problems as I
first got bitten by the pcre update and also did the world update to the
clang3.2 import. Needless to say that everything worked prior and the
configuration (no xorg.conf here) did not change.

uname -a:
FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13
09:46:06 EST 2012 root@X:/usr/obj/usr/src/sys/GENERIC  amd64.

Xorg.0.log:
[88.021]
X.Org X Server 1.10.6
Release Date: 2012-02-10
[88.021] X Protocol Version 11, Revision 0
[88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64
[88.021] Current Operating System: FreeBSD X 10.0-CURRENT
FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012
root@XXX:/usr/obj/usr/src/sys/GENERIC amd64
[88.021] Build Date: 13 December 2012  06:30:07AM
[88.021]
[88.021] Current version of pixman: 0.24.2
[88.021]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[88.021] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[88.022] (==) Log file: /var/log/Xorg.0.log, Time: Thu Dec 13
15:01:42 2012
[88.024] (II) Loader magic: 0x7c1930
[88.024] (II) Module ABI versions:
[88.024]X.Org ANSI C Emulation: 0.4
[88.024]X.Org Video Driver: 10.0
[88.024]X.Org XInput driver : 12.2
[88.024]X.Org Server Extension : 5.0
[88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @
0xf000/4194304, 0xe000/268435456, I/O @ 0x5000/64, BIOS @
0x/65536
[88.025] (==) Using default built-in configuration (30 lines)
[88.025] (==) --- Start of built-in configuration ---
[88.025]Section Device
[88.025]Identifier  Builtin Default intel Device 0
[88.025]Driver  intel
[88.025]EndSection
[88.025]Section Screen
[88.025]Identifier  Builtin Default intel Screen 0
[88.025]Device  Builtin Default intel Device 0
[88.025]EndSection
[88.025]Section Device
[88.025]Identifier  Builtin Default vesa Device 0
[88.025]Driver  vesa
[88.025]EndSection
[88.025]Section Screen
[88.025]Identifier  Builtin Default vesa Screen 0
[88.025]Device  Builtin Default vesa Device 0
[88.025]EndSection
[88.025]Section Device
[88.025]Identifier  Builtin Default fbdev Device 0
[88.025]Driver  fbdev
[88.025]EndSection
[88.025]Section Screen
[88.025]Identifier  Builtin Default fbdev Screen 0
[88.025]Device  Builtin Default fbdev Device 0
[88.026]EndSection
[88.026]Section ServerLayout
[88.026]Identifier  Builtin Default Layout
[88.026]Screen  Builtin Default intel Screen 0
[88.026]Screen  Builtin Default vesa Screen 0
[88.026]Screen  Builtin Default fbdev Screen 0
[88.026]EndSection
[88.026] (==) --- End of built-in configuration ---
[88.026] (==) ServerLayout Builtin Default Layout
[88.026] (**) |--Screen Builtin Default intel Screen 0 (0)
[88.026] (**) |   |--Monitor default monitor
[88.026] (**) |   |--Device Builtin Default intel Device 0
[88.026] (==) No monitor specified for screen Builtin Default intel
Screen 0.
Using a default monitor configuration.
[88.026] (**) |--Screen Builtin Default vesa Screen 0 (1)
[88.026] (**) |   |--Monitor default monitor
[88.026] (**) |   |--Device Builtin Default vesa Device 0
[88.026] (==) No monitor specified for screen Builtin Default vesa
Screen 0.
Using a default monitor configuration.
[88.026] (**) |--Screen Builtin Default fbdev Screen 0 (2)
[88.027] (**) |   |--Monitor default monitor
[88.027] (**) |   |--Device Builtin Default fbdev Device 0
[88.027] (==) No monitor specified for screen Builtin Default fbdev
Screen 0.
Using a default monitor configuration.
[88.027] (==) Automatically adding devices
[88.027] (==) Automatically enabling devices
[88.027] (WW) The directory /usr/local/lib/X11/fonts/misc/ does not
exist.
[88.027]Entry deleted from font path.
[88.028] (WW) The directory /usr/local/lib/X11/fonts/Type1/ does not
exist.
[88.029]Entry deleted from font 

Re: new xorg segfault 11 with KMS

[Johannes Dieterich]

On Thu, Dec 13, 2012 at 4:01 PM, George Liaskos geo.lias...@gmail.com wrote:

 Rebuilding xorg-server with gcc resolves the problem, bt points at libdrm2.
So basically this is a regression from the previous clang3.1 to the
clang3.2 import then?

Is anyone of the clang guys aware of this?

 On Thu, Dec 13, 2012 at 10:51 PM, Artyom Mirgorodskiy 
 art...@ijminteractive.net wrote:

 I have a similar problem when running firefox

 On Thursday 13 December 2012 15:49:38 Johannes Dieterich wrote:
  Dear all,
 
  I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and
  WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly
  causes the segfault (log attached), gnome survives a bit longer but
  starting any bigger application (e.g. firefox) causes it to crash with the
  same log.
 
  I have a Xorg.core file, but since it is without debug symbols the
  backtrace makes little sense to me.
 
  Unfortunately, I cannot tell what is the root cause of the problems as I
  first got bitten by the pcre update and also did the world update to the
  clang3.2 import. Needless to say that everything worked prior and the
  configuration (no xorg.conf here) did not change.
 
  uname -a:
  FreeBSD X 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13
  09:46:06 EST 2012 root@X:/usr/obj/usr/src/sys/GENERIC  amd64.
 
  Xorg.0.log:
  [88.021]
  X.Org X Server 1.10.6
  Release Date: 2012-02-10
  [88.021] X Protocol Version 11, Revision 0
  [88.021] Build Operating System: FreeBSD 10.0-CURRENT amd64
  [88.021] Current Operating System: FreeBSD X 10.0-CURRENT
  FreeBSD 10.0-CURRENT #6 r244180: Thu Dec 13 09:46:06 EST 2012
  root@XXX:/usr/obj/usr/src/sys/GENERIC amd64
  [88.021] Build Date: 13 December 2012  06:30:07AM
  [88.021]
  [88.021] Current version of pixman: 0.24.2
  [88.021]Before reporting problems, check http://wiki.x.org
  to make sure that you have the latest version.
  [88.021] Markers: (--) probed, (**) from config file, (==) default
  setting,
  (++) from command line, (!!) notice, (II) informational,
  (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  [88.022] (==) Log file: /var/log/Xorg.0.log, Time: Thu Dec 13
  15:01:42 2012
  [88.024] (II) Loader magic: 0x7c1930
  [88.024] (II) Module ABI versions:
  [88.024]X.Org ANSI C Emulation: 0.4
  [88.024]X.Org Video Driver: 10.0
  [88.024]X.Org XInput driver : 12.2
  [88.024]X.Org Server Extension : 5.0
  [88.025] (--) PCI:*(0:0:2:0) 8086:0166:17aa:2200 rev 9, Mem @
  0xf000/4194304, 0xe000/268435456, I/O @ 0x5000/64, BIOS @
  0x/65536
  [88.025] (==) Using default built-in configuration (30 lines)
  [88.025] (==) --- Start of built-in configuration ---
  [88.025]Section Device
  [88.025]Identifier  Builtin Default intel Device 0
  [88.025]Driver  intel
  [88.025]EndSection
  [88.025]Section Screen
  [88.025]Identifier  Builtin Default intel Screen 0
  [88.025]Device  Builtin Default intel Device 0
  [88.025]EndSection
  [88.025]Section Device
  [88.025]Identifier  Builtin Default vesa Device 0
  [88.025]Driver  vesa
  [88.025]EndSection
  [88.025]Section Screen
  [88.025]Identifier  Builtin Default vesa Screen 0
  [88.025]Device  Builtin Default vesa Device 0
  [88.025]EndSection
  [88.025]Section Device
  [88.025]Identifier  Builtin Default fbdev Device 0
  [88.025]Driver  fbdev
  [88.025]EndSection
  [88.025]Section Screen
  [88.025]Identifier  Builtin Default fbdev Screen 0
  [88.025]Device  Builtin Default fbdev Device 0
  [88.026]EndSection
  [88.026]Section ServerLayout
  [88.026]Identifier  Builtin Default Layout
  [88.026]Screen  Builtin Default intel Screen 0
  [88.026]Screen  Builtin Default vesa Screen 0
  [88.026]Screen  Builtin Default fbdev Screen 0
  [88.026]EndSection
  [88.026] (==) --- End of built-in configuration ---
  [88.026] (==) ServerLayout Builtin Default Layout
  [88.026] (**) |--Screen Builtin Default intel Screen 0 (0)
  [88.026] (**) |   |--Monitor default monitor
  [88.026] (**) |   |--Device Builtin Default intel Device 0
  [88.026] (==) No monitor specified for screen Builtin Default intel
  Screen 0.
  Using a default monitor configuration.
  [88.026] (**) |--Screen Builtin Default vesa Screen 0 (1)
  [88.026] (**) |   |--Monitor default monitor
  [88.026] (**) |   |--Device Builtin Default vesa Device 0
  [88.026] (==) No monitor specified for screen Builtin Default vesa
  Screen 0

Re: new xorg segfault 11 with KMS

[Johannes Dieterich]

On 12/13/12 16:36, Dimitry Andric wrote:

On 2012-12-13 21:49, Johannes Dieterich wrote:

I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and
WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly
causes the segfault (log attached), gnome survives a bit longer but
starting any bigger application (e.g. firefox) causes it to crash with
the
same log.

I have a Xorg.core file, but since it is without debug symbols the
backtrace makes little sense to me.


Please post the backtrace anyway. :-)  Or recompile xorg-server with
WITH_DEBUG=yes in your environment, and reproduce the crash.

Here we go:

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd.
Core was generated by `Xorg'.
Program terminated with signal 6, Aborted.
#0  0x000802c4520a in ?? ()
(gdb) bt
#0  0x000802c4520a in ?? ()
#1  0x000802cf72bc in ?? ()
#2  0x000802cf85ca in ?? ()
#3  0x007cdd5c in ?? ()
#4  0xffdf in ?? ()
#5  0x in ?? ()
#6  0x in ?? ()
#7  0x00575f06 in ?? ()
#8  0x7fffce50 in ?? ()
#9  0x00472c9e in ?? ()
#10 0x7fffce60 in ?? ()
#11 0x0047e034 in ?? ()
#12 0x7fffce70 in ?? ()
#13 0x004704ed in ?? ()
#14 0x7fffcf50 in ?? ()
#15 0x0046fd26 in ?? ()
#16 0x3246 in ?? ()
#17 0x000b in ?? ()
#18 0x000802f31a10 in ?? ()
#19 0xf801 in ?? ()
#20 0x0101010101010101 in ?? ()
#21 0x8080808080808080 in ?? ()
#22 0x in ?? ()
#23 0x0001 in ?? ()
#24 0x6e7dec389dd25e4d in ?? ()
#25 0x000802c60f9e in ?? ()
#26 0x000802f31a10 in ?? ()
#27 0x000802f31a10 in ?? ()
#28 0x in ?? ()
#29 0x000b in ?? ()
#30 0x7fffcf50 in ?? ()
#31 0x000802c19662 in ?? ()
#32 0x0006 in ?? ()
#33 0x00470e50 in ?? ()
#34 0x000b in ?? ()
#35 0x7fffd730 in ?? ()
#36 0x6e7dec389dd25e4d in ?? ()
#37 0x000b in ?? ()
#38 0x00300018 in ?? ()
#39 0x7fffcf60 in ?? ()
---Type return to continue, or q return to quit---
#40 0x7fffce80 in ?? ()
#41 0x000b in ?? ()
#42 0x7fffcf70 in ?? ()
#43 0x00470ee3 in ?? ()
#44 0x7fffd358 in ?? ()
#45 0x7fffd3c0 in ?? ()
#46 0x7fffd330 in ?? ()
#47 0x0008029ca2e6 in ?? ()
#48 0x in ?? ()

I also rebuild xorg with debug enabled. Interestingly, I cannot 
reproduce the crash anymore. Either I forgot to rebuild something (seems 
unlikely) or the crash has to do with optimizations or flags not present 
in a debug build.


Hope this helps.

Johannes
___
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: new xorg segfault 11 with KMS

[Johannes Dieterich]

On 12/13/12 16:53, David Chisnall wrote:

On 13 Dec 2012, at 21:48, Johannes Dieterich wrote:


GNU gdb 6.1.1 [FreeBSD]


You might try with gdb 7.x from ports.  gdb 6.1.1 from the base system doesn't 
do a good job of understanding the newer version of DWARF that clang emits.

Did that but it doesn't change much:

GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD]
Copyright (C) 2012 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-freebsd10.0.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
[New process 100714]
Core was generated by `Xorg'.
Program terminated with signal 6, Aborted.
#0  0x000802c4520a in ?? ()
(gdb) bt
#0  0x000802c4520a in ?? ()
#1  0x000802cf72bc in ?? ()
#2  0x000802cf85ca in ?? ()
#3  0x007cdd5c in ?? ()
#4  0xffdf in ?? ()
#5  0x in ?? ()
#6  0x in ?? ()
#7  0x00575f06 in ?? ()
#8  0x7fffce50 in ?? ()
#9  0x00472c9e in ?? ()
#10 0x7fffce60 in ?? ()
#11 0x0047e034 in ?? ()
#12 0x7fffce70 in ?? ()
#13 0x004704ed in ?? ()
#14 0x7fffcf50 in ?? ()
#15 0x0046fd26 in ?? ()
#16 0x3246 in ?? ()
#17 0x000b in ?? ()
#18 0x000802f31a10 in ?? ()
#19 0xf801 in ?? ()
#20 0x0101010101010101 in ?? ()
#21 0x8080808080808080 in ?? ()
#22 0x in ?? ()
#23 0x0001 in ?? ()
#24 0x6e7dec389dd25e4d in ?? ()
#25 0x000802c60f9e in ?? ()
#26 0x000802f31a10 in ?? ()
#27 0x000802f31a10 in ?? ()
#28 0x in ?? ()
#29 0x000b in ?? ()
#30 0x7fffcf50 in ?? ()
#31 0x000802c19662 in ?? ()
#32 0x0006 in ?? ()
#33 0x00470e50 in ?? ()
#34 0x000b in ?? ()
#35 0x7fffd730 in ?? ()
#36 0x6e7dec389dd25e4d in ?? ()
#37 0x000b in ?? ()
#38 0x00300018 in ?? ()
#39 0x7fffcf60 in ?? ()
---Type return to continue, or q return to quit---
#40 0x7fffce80 in ?? ()
#41 0x000b in ?? ()
#42 0x7fffcf70 in ?? ()
#43 0x00470ee3 in ?? ()
#44 0x7fffd358 in ?? ()
#45 0x7fffd3c0 in ?? ()
#46 0x7fffd330 in ?? ()
#47 0x0008029ca2e6 in ?? ()
#48 0x in ?? ()

I guess marking xorg-server to require USE_GCC=4.2+ would be a 
reasonable workaround for the time being?


Best

Johannes
___
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: new xorg segfault 11 with KMS

[Johannes Dieterich]

On Thu, Dec 13, 2012 at 6:51 PM, Artyom Mirgorodskiy
art...@ijminteractive.net wrote:
 This patch work for me. Thanks.
I can confirm that it also works for me. Thanks a lot!

 On Friday 14 December 2012 00:30:52 Niclas Zeising wrote:

 Can you please try the attached patch, against x11-servers/xorg-server.

 Apply it and recompile xorg-server with normal flags (that is, no

 debugging) and let me and the list know the result when starting X.

 Regards!



 --

 This message is for the person(s) named above only and may contain
 privileged, proprietary, or otherwise private information. If you received
 this transmission in error, please notify the sender immediately and delete
 the original. Any other use of the email by you is prohibited.
___
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: Samsung 830 and ZFS TRIM

[Johannes Dieterich]

On 11/29/12 04:40, Steven Hartland wrote:

Do you have any other disks in the machine if so its likely these are
the source of the unsupported increments.

No, not yet.

Best regards

Johannes


- Original Message - From: Johannes Dieterich
dieterich@gmail.com
To: freebsd-current@freebsd.org
Sent: Monday, November 26, 2012 7:48 PM
Subject: Samsung 830 and ZFS TRIM



Hello,

(initially posted this to -questions@ a week ago, w/o reply)

I installed CURRENT on a new Thinkpad equipped with a Samsung 830 SSD:

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: SAMSUNG SSD 830 Series CXM03B1Q ATA-9 SATA 3.x device
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C)
ada0: Previously was known as ad4

as the setup is ZFS+GELI based (on ada0), I enabled ZFS TRIM support
in loader.conf.

Interestingly, I encounter an IMHO strange behavior with the stats on
that:

kstat.zfs.misc.zio_trim.zio_trim_bytes: 755712
kstat.zfs.misc.zio_trim.zio_trim_success: 97
kstat.zfs.misc.zio_trim.zio_trim_unsupported: 7891
kstat.zfs.misc.zio_trim.zio_trim_failed: 0

It seems unintuitive to me why the unsupported counter first increases
(seems to stay constant after that each boot) and then slowly the
success counter increases as well.

Probably there is a trivial explanation (GELI?) and/or fix for this
that anyone is willing to share?

If you need further information, let me know.

Thanks a lot

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




This e.mail is private and confidential between Multiplay (UK) Ltd. and
the person or entity to whom it is addressed. In the event of
misdirection, the recipient is prohibited from using, copying, printing
or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission
please telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.



___
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

Samsung 830 and ZFS TRIM

[Johannes Dieterich]

Hello,

(initially posted this to -questions@ a week ago, w/o reply)

I installed CURRENT on a new Thinkpad equipped with a Samsung 830 SSD:

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: SAMSUNG SSD 830 Series CXM03B1Q ATA-9 SATA 3.x device
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C)
ada0: Previously was known as ad4

as the setup is ZFS+GELI based (on ada0), I enabled ZFS TRIM support in 
loader.conf.


Interestingly, I encounter an IMHO strange behavior with the stats on that:

kstat.zfs.misc.zio_trim.zio_trim_bytes: 755712
kstat.zfs.misc.zio_trim.zio_trim_success: 97
kstat.zfs.misc.zio_trim.zio_trim_unsupported: 7891
kstat.zfs.misc.zio_trim.zio_trim_failed: 0

It seems unintuitive to me why the unsupported counter first increases 
(seems to stay constant after that each boot) and then slowly the 
success counter increases as well.


Probably there is a trivial explanation (GELI?) and/or fix for this that 
anyone is willing to share?


If you need further information, let me know.

Thanks a lot

Johannes
___
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: panic: mutex pf task mtx owned at /usr/src/sys/contrib/pf/net/if_pfsync.c:3163

[Johannes Dieterich]

Hi Matthew,

On Fri, Aug 26, 2011 at 11:51 PM, Matthew Economou mxecono...@gmail.comwrote:

 I recently upgraded a firewall I'm using for performance testing from
 a March-ish 9-CURRENT to 9.0-BETA1 (csup run August 21 around 12:00 AM
 EDT).  It's basically a GENERIC kernel with debugging disabled and
 things like IPsec and ALTQ enabled.  Since the upgrade, after
 approximately an hour after it boots, the firewall stops passing any
 traffic (IPv4 and IPv6).  OpenVPN, for example, logs the following
 errors:

  write UDPv4: Operation not permitted (code=1)

 Quagga, for another example, logs something similar:

  ripd[1696]: can't send packet : Operation not permitted0
  ospfd[1702]: *** sendmsg in ospf_write failed to 172.30.0.3, id 0,
 off 0, len 76, interface tap0 mtu 1500: Operation not permitted

 If I try to ping something from the console, I get the same error message:

  # ping 4.2.2.2
  ping: sendto: Operation not permitted
 It appears that PF isn't removing any entries from the state table.
 Note that the state table size is at its default of 1 (which
 correlates to the amount of memory installed on the firewall - 256
 MB).

 State Table  Total Rate
  current entries10013
  searches  554801   13.4/s
  inserts100130.2/s
  removals   00.0/s

 I've tried both my current (unmodified and working prior to the
 upgrade) and experimental PF configurations, neither of which have any
 effect on the problem.  Reloading the PF configuration (/etc/rc.d/pf
 reload) or restarting PF altogether (/etc/rc.d/pf restart) also have
 no effect.  Only if I shut down PF completely (/etc/rc.d/pf stop) do I
 regain network connectivity - I can do things like ping hosts (IPv4
 and IPv6), browse the web, and pass traffic that's just routed through
 the firewall (i.e., not requiring NAT).  Clearing the state table
 (pfsync -F state) has no effect.

 The kernel I'm was running had debugging disabled for performance
 testing purposes, so I booted a proper debug kernel.  It panicked in
 pfsync_send_plus as soon as init enabled PF (backtrace included
 below).

 Starting pflog.
 pflog0: promiscuous mode enabled
 Aug 25 20:54:21 pflogd[1611]: [priv]: msg PRIV_OPEN_LOG received
 Enabling pfpanic: mutex pf task mtx owned at
 /usr/src/sys/contrib/pf/net/if_pfsync.c:3163
 cpuid = 0
 KDB: enter: panic
 [ thread pid 1619 tid 100053 ]
 Stopped at  kdb_enter+0x3a: movl$0,kdb_why
 db bt
 Tracing pid 1619 tid 100053 td 0xc23da2e0
 kdb_enter(c09777c9,c09777c9,c0975d7b,c6fd79e0,0,...) at kdb_enter+0x3a
 panic(c0975d7b,c0946080,c0944e87,c5b,c6fd7a0c,...) at panic+0x134
 _mtx_assert(c0a1b388,0,c0944e87,c5b,c6fd7a24,...) at _mtx_assert+0x127
 pfsync_send_plus(c6fd7a24,18,10,ad6,100,...) at pfsync_send_plus+0xf2
 pfsync_clear_states(a218d664,c236fb78,c0945f1c,635,c09ae167,...) at
 pfsync_clear_states+0x8d
 pfioctl(c22a0800,c0cc4412,c236fb00,3,c23da2e0,...) at pfioctl+0x1b90
 devfs_ioctl_f(c23ce578,c0cc4412,c236fb00,c216ce80,c23da2e0,...) at
 devfs_ioctl_f+0x10b
 kern_ioctl(c23da2e0,3,c0cc4412,c236fb00,1fd7cec,...) at kern_ioctl+0x21d
 ioctl(c23da2e0,c6fd7cec,c6fd7d28,c097d93a,0,...) at ioctl+0x134
 syscallenter(c23da2e0,c6fd7ce4,c6fd7ce4,0,0,...) at syscallenter+0x263
 syscall(c6fd7d28) at syscall+0x34
 Xint0x80_syscall() at Xint0x80_syscall+0x21
 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281e6263, esp =
 0xbfbfe8ac, ebp = 0xbfbfe998 ---
 db

 I'm at a loss as to how to proceed.  Is this a known problem with PF?
 Can anyone suggest a work-around?

I ran into the same problem on my NAT-box. According to ome other PRs
(kern/159390 and kern/158873) the problem lies in pfsync. The (still open)
PRs contain both a patch (didn't test that) and the assumption that pulling
a newer version to FreeBSD might help. Also, they suggest as a workaround to
not compile device pfsync into the kernel. Seems to work for me (not yet
tested in detail though), don't know if this is a feasable solution for you.

Hope this helps

Johannes
___
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: Boot halts on Thinkpad X220 (Sandy Bridge)

[Johannes Dieterich]

On Wed, May 18, 2011 at 7:40 PM, Xin LI delp...@delphij.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Try this patch?

The attached patch makes 9-CURRENT-amd64 boot on the X220 w/o any hints or
BIOS fixes needed. Thanks a lot! :-)




 (I'm still opted to disable the typematic rate detection by default at
 least for amd64, as we don't do it in the past for amd64)

What does this mean concerning getting the fix into CURRENT?

Best regards

Johannes Dieterich





 Cheers,
 - --
 Xin LI delp...@delphij.nethttp://www.delphij.net/
 FreeBSD - The Power to Serve!  Live free or die
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.17 (FreeBSD)

 iQEcBAEBCAAGBQJN1ASPAAoJEATO+BI/yjfBmsMH/0/VmxTyIAK2maoihg+/BhGR
 5hwWnlCrW7i8a5If77o9e6apishlIgUMuf71WBAIVG+BF71I2QyEWNz+NsR9A+DM
 N2YPok+oUVASyUIMHvvPC5gNEctcEnaFDOQ1fUWjPeQBoIZajxm0LYeRF7PDKA6R
 n3HfstrQRwfzzRms96gkwCXdmffOuokqPK0EMwub+Dd+1NkLcnv/VaaJFR9OwlBd
 cxayhNbTMSbW92x9GBz4O9HrQ1UBhYdi+jru2GBTbeNegh8bZGppoV8rfZQXvq5x
 MU37Wgt0DolJY05BB58TTVW8weKRPiqUkHBc1aCK9X0AojXo76aXSUwdk40xSfs=
 =+die
 -END PGP SIGNATURE-

 ___
 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

___
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: Boot halts on Thinkpad X220 (Sandy Bridge)

[Johannes Dieterich]

On 05/17/2011 06:31 PM, Daniel Staal wrote:
 
 (Sorry I can't reply to anyone, I just joined the list.  I saw this
 discussion in the archives and thought I should join in.)
 
 I've managed to boot a X220i using -CURRENT as of last night.  I got
 some help on -questions to get it done though.  From a blank machine,
 you'll need either a non-USB boot device with FreeBSD media (untested)
 or a USB keyboard.  If you are using a USB keyboard
 
 set hint.atkbd.0.disabled=1
 
 to install, and use the USB keyboard during installation.  Then on the
 first reboot in the BIOS set 'USB UEFI BIOS' to disabled.  (This means
 you can't boot from a USB device.)
 
 At that point, the machine will boot fine.  I've tried 8.2-RELEASE, the
 last amd64 -CURRENT I could find on the FreeBSD website, and -CURRENT as
 of 2011-05-16.
 
 I'm building a couple of ports at the moment, and want to reboot with a
 couple of config changes in the loader to see if I can get the WiFi
 recognized.  As soon as I do that I can post my dmesg someplace.
Thanks a lot for the very valuable hint! :-) Booting the amd64
installation medium works now, I will report after the install whether
the second part also works for me (but I am pretty sure of it).

Thanks a lot again! :-)

Johannes Dieterich
___
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: Boot halts on Thinkpad X220 (Sandy Bridge)

[Johannes Dieterich]

On Mon, May 16, 2011 at 3:40 PM, John Baldwin j...@freebsd.org wrote:

 On Sunday, May 15, 2011 8:09:21 pm Johannes Dieterich wrote:
  Hello everybody,
 
  on a Thinkpad X220 (Sandy Bridge/Cougar Point based) the installation
  medium loads but halts during boot. I tested the following versions of
  FreeBSD
 
  * 8.2-RELEASE
  * 9-CURRENT (latest official snapshot from 02/2011)
  * 9-CURRENT (latest snapshot from Nathan Whitehorn as of 20/04/2011 [1])
  * 9-CURRENT (own release medium as of today prepared with the
  generate-release script)
 
  With 8.2, I see the same error messages as [2] with PCBSD-8 (not
  surprising, of course, but please note that there is no Firewire in this
  notebook). I do not see what the error message is with 9.0 before it
  halts. Anyway, according to Kris Moore this is a known issue with
  FreeBSD. I have not found anything about such problem in the mailing
  list archives (apologies if I am wrong).
 
  Therefore my question simply is, whether this problem is known and (if
  yes) there is a fix or workaround available for CURRENT.
 
  If needed, I can post a dmesg of a successful boot of the
  openSUSE-11.4-LiveCD as reference (not doing so now because I assume the
  list will anyway eat the attachment). Also, I can provide whatever can
  be obtained using said Linux.
 
  Thanks a lot or any replies! :-)

 Hmm, is this booting amd64 or i386?  Can you try i386 if you haven't?  If
 i386
 doesn't work at first, you might need to try disabling APIC via 'set
 hint.apic.0.disabled=1' at the loader prompt.

Sorry, forgot to mention it. Machine has 8 GB of RAM so I have been using
amd64 images for all tests. I will try tonight with an i386 snapshot. Would
the one provided by Nathan Whitehorn be recent enough? Anything in
particular that you would be interested in if it should work (verbose dmesg,
...)?

Thanks a lot for the reply!

Johannes Dieterich
___
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: Boot halts on Thinkpad X220 (Sandy Bridge)

[Johannes Dieterich]

On 05/16/2011 03:40 PM, John Baldwin wrote:
 On Sunday, May 15, 2011 8:09:21 pm Johannes Dieterich wrote:
 Hello everybody,

 on a Thinkpad X220 (Sandy Bridge/Cougar Point based) the installation
 medium loads but halts during boot. I tested the following versions of
 FreeBSD

 * 8.2-RELEASE
 * 9-CURRENT (latest official snapshot from 02/2011)
 * 9-CURRENT (latest snapshot from Nathan Whitehorn as of 20/04/2011 [1])
 * 9-CURRENT (own release medium as of today prepared with the
 generate-release script)

 With 8.2, I see the same error messages as [2] with PCBSD-8 (not
 surprising, of course, but please note that there is no Firewire in this
 notebook). I do not see what the error message is with 9.0 before it
 halts. Anyway, according to Kris Moore this is a known issue with
 FreeBSD. I have not found anything about such problem in the mailing
 list archives (apologies if I am wrong).

 Therefore my question simply is, whether this problem is known and (if
 yes) there is a fix or workaround available for CURRENT.

 If needed, I can post a dmesg of a successful boot of the
 openSUSE-11.4-LiveCD as reference (not doing so now because I assume the
 list will anyway eat the attachment). Also, I can provide whatever can
 be obtained using said Linux.

 Thanks a lot or any replies! :-)
 
 Hmm, is this booting amd64 or i386?  Can you try i386 if you haven't?  If 
 i386 
 doesn't work at first, you might need to try disabling APIC via 'set 
 hint.apic.0.disabled=1' at the loader prompt.
The i386 image as of 11/04/2011 of Nathan Whitehorn booted into the live
system without problems. The hint was not needed.

Please find a verbose dmesg at http://pastebin.com/4UTHsg7F

Does this tell you anything?

If you (or anybody else) should need anything more, just let me know how
to obtain it! :-)

Best regards

Johannes Dieterich
___
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

Boot halts on Thinkpad X220 (Sandy Bridge)

[Johannes Dieterich]

Hello everybody,

on a Thinkpad X220 (Sandy Bridge/Cougar Point based) the installation
medium loads but halts during boot. I tested the following versions of
FreeBSD

* 8.2-RELEASE
* 9-CURRENT (latest official snapshot from 02/2011)
* 9-CURRENT (latest snapshot from Nathan Whitehorn as of 20/04/2011 [1])
* 9-CURRENT (own release medium as of today prepared with the
generate-release script)

With 8.2, I see the same error messages as [2] with PCBSD-8 (not
surprising, of course, but please note that there is no Firewire in this
notebook). I do not see what the error message is with 9.0 before it
halts. Anyway, according to Kris Moore this is a known issue with
FreeBSD. I have not found anything about such problem in the mailing
list archives (apologies if I am wrong).

Therefore my question simply is, whether this problem is known and (if
yes) there is a fix or workaround available for CURRENT.

If needed, I can post a dmesg of a successful boot of the
openSUSE-11.4-LiveCD as reference (not doing so now because I assume the
list will anyway eat the attachment). Also, I can provide whatever can
be obtained using said Linux.

Thanks a lot or any replies! :-)

Johannes Dieterich

[1] http://people.freebsd.org/~nwhitehorn/
[2] http://forums.pcbsd.org/showthread.php?p=87366
___
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