Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI
Am Mon, 15 Sep 2014 18:19:32 -0700 Kevin Oberman schrieb: > On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann > wrote: > > > > > Trying to install and run FreeBSD 11.0-CURRENT > > (FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img) on a new Lenovo > > E540 notebook > > fails in activating the NIC (Realtek RTL8111/8168B, driver re[0]). The NIC > > shows up as > > active and with carrier when issuing "ifconfig re0". > > > > From a desktop machine, I tried to ping the system in question and I get a > > result with > > missing packets: > > > > ping: sendto: Host is down > > ping: sendto: Host is down > > ping: sendto: Host is down > > 64 bytes from 192.168.0.130: icmp_seq=26 ttl=64 time=0.114 ms > > 64 bytes from 192.168.0.130: icmp_seq=41 ttl=64 time=0.130 ms > > 64 bytes from 192.168.0.130: icmp_seq=60 ttl=64 time=0.119 ms > > 64 bytes from 192.168.0.130: icmp_seq=80 ttl=64 time=0.119 ms > > 64 bytes from 192.168.0.130: icmp_seq=100 ttl=64 time=0.105 ms > > 64 bytes from 192.168.0.130: icmp_seq=116 ttl=64 time=0.135 ms > > 64 bytes from 192.168.0.130: icmp_seq=136 ttl=64 time=0.091 ms > > > > DHCP configuration fails, since no DHCP offer is discovered. > > > > I swapped the switches, the cabling and I had always the same results. I > > used another > > Laptop, Dell Latitude E6510 with the same configuration (/etc/rc.conf) and > > that system > > gets DHCP offer and is online. > > > > Since the notebook is brandnew, the last thing I'll "suspect" is a > > defective NIC, so I'll > > ask whether this phenomenon is known - or, if not, the results > > definititely would > > indicate a broken NIC. > > > > Another point is the WiFI adaptor. This notebook is supposed to have a > > WiFi NIC, but it > > doesn't get revealed by FreeBSD (I tried iwn/iwi without success). > > > > pciconf output below, sorry for the messy shape, it is a copy-and-paste > > from that immature > > vt() terminal. > > > > Has anyone successfully installed that type of Notebook with FreeBSD > > CURRENT using NIC > > and Wifi? > > > > Please CC me. > > > > > > Regards > > oh > > > > > > [...] > > > > none1@pci0:3:0:0: class=0xff card=0x502817aa chip=0x522710ec > > rev=0x01 hdr=0x00 > > > > > > vendor = 'Realtek Semiconductor Co., Ltd.' > > > > > > bar [10] = type Memory, range 32, base 0xf1e0, size 4096, enabled > > > > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > > > > cap 05[50] = MSI supports 1 message, 64 bit > > > > > > cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) > > > > > > speed 2.5(2.5) ASPM L0s/L1(L0s/L1) > > > > > > ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected > > > > > > ecap 0003[140] = Serial 1 0001004ce000 > > > > > > re0@pci0:4:0:0: class=0x02 card=0x502817aa chip=0x816810ec rev=0x10 > > hdr=0x00 > > > > > > subclass = ethernet > > > > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current > > D0 > > di sabled(L0s/L1) > > > > > > cap 11[b0] = MSI-X supports 4 messages, enabled > > > > ecap 0001[100] = AER 2 0 fatal 0 non-fatal 4 corrected > > > > > > > > ecap 001e[178] = unknown 1 > > > > > > class = network > > > > > > cap 05[d0] = MSI supports 1 message, 64 bit > > > > > > ecap 0003[140] = Serial 1 ac7ba1a06fd6 > > > > I can't comment on the WiFi, I have little Asus box using an 8111/8168B and > it works fine with the driver in 10.1-BETA. The driver in 10.0 recognizes > the device, but did not work. I do notice that your NIC has a rev of 0x10 > while mine is 0x0c. > -- > Kevin Oberman, Network Engineer, Retired I tried a 10.1-BETA also and it shows the very same symptomes as in 11.0-CURRENT. As Guido Falsi stated later in this thread, the device gets recognized but is inoperable after initialized and setup by the OS until the administrator takes some strange actions. In Guido's case a setting/resetting of NIC features helps, in my case I have to bring down the device first via "ifconfig re0 down" and then bring it up. After that, the NIC works as expected. This seems clearly to be a bug in the driver code and it might indeed have to do something with a new revision used, but the NIC is since at least a year on the market and floating around (my laptop was manufactured in April of this year). Well, I hope this report doesn't get lost, so I filed a PR. Oliver signature.asc Description: PGP signature
Re: uefi boot on Apple Mac
I finally make MacBookPro 11,3 UEFI boot successfully: 1. copy boot1.efi to /EFI/boot/BOOTx64.efi in EFI partition 2. Create a small UFS partition in internal SSD, and installworld and installkernel. 3. Without USB stick, then system really can boot, although the loader still stop at: Start @ 0x802d9000... 4. I can ssh log in and found that culprit is XHCI USB controller does not work in UEFI mode. 5. Xorg and nvidia driver also works. 6. verbose boot log can be found at: http://sw.gddsn.org.cn/freebsd/uefi-messages.txt Cheers, Huang Wen Hui 2014-08-10 16:44 GMT+08:00 Anders Bolt Evensen : > If you're interested, you can try out the following ISO: > https://www.dropbox.com/s/srbunx0agrokcs3/freebsd- > current-uefi-bios-amd64.iso > > The image was built on Friday 8th of August for the amd64 platform. > > I tested out the EFI part on VirtualBox (UEFI 2.X) and my MacBook Pro 17 > inch from 2011 (EFI 1.10), and as far as EFI goes, I successfully booted > the image on both my Mac and VirtualBox (however, booting the image from > BIOS using my Mac was a different story). > > So, as I said, as far as (U)EFI goes, the image should work on UEFI 2.X > based PC's and EFI 1.10 based Macs. > > On 12/07/14 19:22, Nathan Whitehorn wrote: > >> I'd point out that, as of last week, the standard -CURRENT ISOs (and >> generate-release.sh script) make EFI-bootable media by default. All the >> snapshots should have this done already, for instance. >> -Nathan >> > I wasn't aware of that, but thanks for the info. :) > > >> On 07/12/14 03:09, Anders Bolt-Evensen wrote: >> >>> I also got a message like that when I booted from a USB stick on a >>> MacBookPro8,3 (17 inch, late 2011). >>> >>> I fixed it by creating a custom ISO image and burned that onto a DVD >>> using an external DVD drive. >>> The UEFI installer boots fine from this external DVD drive. >>> >>> Here is how I did it: >>> >>> Genereste an ISO with the FreeBSD-CURRENT kernel, mount the ISO and copy >>> all files from the root directory in the ISO and unmount >>> > cd /usr/src/release >>> > sh ./generate-release.sh # You may have to run “make buildworld” >>> and be connected to the internet to install required ports. >>> > mount -t cd9660 /scratch/R/release/FreeBSD-something-disc1.iso >>> /mnt >>> > mkdir freebsd_generic_installer >>> #Files copied to the directory in the next command will be copied to >>> a new ISO in step 3 >>> > cp -R /mnt/ freebsd_generic_installer/ >>> > umount /mnt >>> 2. Create a FAT filesystem image and place the loader in it in the >>> default path that UEFI will look for (the following steps are copied from >>> https://wiki.freebsd.org/UEFI#CD.2FDVD_Boot_under_UEFI): >>> > dd if=/dev/zero of=efiboot.img bs=4k count=100 >>> > mdconfig -a -t vnode -f efiboot.img >>> > newfs_msdos -F 12 -m 0xf8 /dev/md0 >>> > mount -t msdosfs /dev/md0 /mnt >>> > mkdir -p /mnt/efi/boot >>> > cp loader.efi /mnt/efi/boot/bootx64.efi >>> > umount /mnt >>> > mdconfig -d -u 0 >>> >>> 3. Create the custom ISO image. Please make sure that the entry in >>> freebsd_generic_installer/etc/fstab matches the label you choose in the >>> command below. >>> > makefs -t cd9660 -o bootimage='i386;efiboot.img' -o no-emul-boot >>> -o rockridge -o label=“FREEBSD_UEFI_INSTALL" -o publisher="test" >>> uefi-test.iso freebsd_generic_installer/ >>> >>> To get the example in the command above to work, please make sure that >>> the entry in freebsd_generic_installer/etc/fstab reads >>> "/dev/iso9660/FREEBSD_UEFI_INSTALL/cd9660ro0 0" >>> >>> 4. Burn the image to DVD, reboot your system and choose “EFI Boot”. Note >>> that unless you are using a EFI console like rEFIt or rEFInd, you may have >>> to kind of wait a couple of minutes while the kernel is loading before >>> anything appears on the screen. >>> >>> >>> On 04/07/14 16:34, Huang Wen Hui wrote: >>> Hi, On my MacbookPro11,3, I got this error message: http://sw.gddsn.org.cn/freebsd/uefi.jpg cheers, Huang WenHui 2014-07-04 22:13 GMT+08:00 Ed Maste : On 24 May 2014 19:39, Rafael Espíndola > wrote: > >> Yes, I got that in the mac laptops I tried, it worked on a Mac Pro. It >> might be the frame buffer corruption that Ed Maste was mentioning. >> > I purchased a new MacBook Air yesterday (model identifier > MacBookAir6,2). UEFI boot and vt(4) worked correctly. (My image > included Rafael's patch; I haven't tried a boot without.) > > I also committed a change to display the framebuffer parameters > (address, dimensions, etc.) on boot, in order to help identify the > source of this issue. If you have a moment can you build a new USB > stick image and give it a try? > > -Ed > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On Fri, 19 Sep 2014, O. Hartmann wrote: nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated nVidia GT 740M (Optimus) working correctly. Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The extra GPU uses the same display memory and can be enabled to speed up the Intel graphics or disabled for power saving. I don't know if versions where the Nvidia section is a full discrete video adapter that can be used alone are still called "Optimus". Some Optimus owners have reported being able to use the Intel drivers after disabling the Nvidia GPU in the BIOS or UEFI. If an option to disable the Nvidia GPU is not present, some people have reported success with an xorg.conf that uses only the intel driver and ignores the Nvidia hardware. ___ 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: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) Warren Block schrieb: > On Fri, 19 Sep 2014, O. Hartmann wrote: > > > nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD > > 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo > > ThinkPad Edge > > E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU > > and > > dedicated nVidia GT 740M (Optimus) working correctly. > > Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The > extra GPU uses the same display memory and can be enabled to speed up > the Intel graphics or disabled for power saving. I don't know if > versions where the Nvidia section is a full discrete video adapter that > can be used alone are still called "Optimus". > > Some Optimus owners have reported being able to use the Intel drivers > after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > disable the Nvidia GPU is not present, some people have reported success > with an xorg.conf that uses only the intel driver and ignores the Nvidia > hardware. Thanks Warren. But this sounds even more frustrating now. I look around the web even at Lenovo's support forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor with Optimus technology and everything sounds to me like it can be selected exclusively. What you describes is that I definitely need to use the HD4600 iGPU on FreeBSD in the first place since the nVidia hardware is a kind of "appendix" to the HD4600. Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work properly: it doesn't even start up and loading the "intel" driver complains about a missing device - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv manner, that this HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: entry in the kernel log when enabling "Integrated Graphics" only in the laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized vga0: device shows up. From my server, equipted with a IvyBridge i3-class CPU with integrated iGPU, I even get this message from 11.0-CURRENT: vgapci0@pci0:0:2:0: class=0x03 card=0x01521849 chip=0x01528086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller' class = display subclass = VGA bar [10] = type Memory, range 64, base 0xf780, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xe000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0xf000, size 64, enabled cap 05[90] = MSI supports 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP The very same CURRENT (most recent as I built world on all system today) doesn't recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to me that people can report having this GPU working if even the most recent FreeBSD CURRENT doesn't recognize it. signature.asc Description: PGP signature
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On 2014-09-20 09:10, O. Hartmann wrote: Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) Warren Block schrieb: On Fri, 19 Sep 2014, O. Hartmann wrote: > nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD > 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge > E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and > dedicated nVidia GT 740M (Optimus) working correctly. Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The extra GPU uses the same display memory and can be enabled to speed up the Intel graphics or disabled for power saving. I don't know if versions where the Nvidia section is a full discrete video adapter that can be used alone are still called "Optimus". Some Optimus owners have reported being able to use the Intel drivers after disabling the Nvidia GPU in the BIOS or UEFI. If an option to disable the Nvidia GPU is not present, some people have reported success with an xorg.conf that uses only the intel driver and ignores the Nvidia hardware. Thanks Warren. But this sounds even more frustrating now. I look around the web even at Lenovo's support forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor with Optimus technology and everything sounds to me like it can be selected exclusively. What you describes is that I definitely need to use the HD4600 iGPU on FreeBSD in the first place since the nVidia hardware is a kind of "appendix" to the HD4600. Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work properly: it doesn't even start up and loading the "intel" driver complains about a missing device - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv manner, that this HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: entry in the kernel log when enabling "Integrated Graphics" only in the laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized vga0: device shows up. From my server, equipted with a IvyBridge i3-class CPU with integrated iGPU, I even get this message from 11.0-CURRENT: vgapci0@pci0:0:2:0: class=0x03 card=0x01521849 chip=0x01528086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller' class = display subclass = VGA bar [10] = type Memory, range 64, base 0xf780, size 4194304, enabled bar [18] = type Prefetchable Memory, range 64, base 0xe000, size 268435456, enabled bar [20] = type I/O Port, range 32, base 0xf000, size 64, enabled cap 05[90] = MSI supports 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP The very same CURRENT (most recent as I built world on all system today) doesn't recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to me that people can report having this GPU working if even the most recent FreeBSD CURRENT doesn't recognize it. for the record, on my Thinkpad W520+Docking Station, I get two HDMI / DVI outputs off the Nvidia GPU, in addition to the Intel graphics on the local LCD. This is under Windows, but. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ 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: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
Am Sat, 20 Sep 2014 16:10:12 +0200 "O. Hartmann" schrieb: > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > Warren Block schrieb: > > > On Fri, 19 Sep 2014, O. Hartmann wrote: > > > > > nVidia's BLOB from port x11/nvidia-driver seems to have problems in > > > FreeBSD > > > 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo > > > ThinkPad > > > Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel > > > iGPU and > > > dedicated nVidia GT 740M (Optimus) working correctly. > > > > Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The > > extra GPU uses the same display memory and can be enabled to speed up > > the Intel graphics or disabled for power saving. I don't know if > > versions where the Nvidia section is a full discrete video adapter that > > can be used alone are still called "Optimus". > > > > Some Optimus owners have reported being able to use the Intel drivers > > after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > > disable the Nvidia GPU is not present, some people have reported success > > with an xorg.conf that uses only the intel driver and ignores the Nvidia > > hardware. > > Thanks Warren. > > But this sounds even more frustrating now. I look around the web even at > Lenovo's > support forum. Many people report the GT 740M nVidia adaptor as a discrete > adaptor with > Optimus technology and everything sounds to me like it can be selected > exclusively. > What you describes is that I definitely need to use the HD4600 iGPU on > FreeBSD in the > first place since the nVidia hardware is a kind of "appendix" to the HD4600. > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work > properly: it > doesn't even start up and loading the "intel" driver complains about a > missing device - > preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv > manner, that this > HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: > entry in > the kernel log when enabling "Integrated Graphics" only in the laptop's > UEFI/Firmware. > When enabling "nVidia Optimus", a recognized vga0: device shows up. > > From my server, equipted with a IvyBridge i3-class CPU with integrated iGPU, > I even get > this message from 11.0-CURRENT: > > vgapci0@pci0:0:2:0: class=0x03 card=0x01521849 chip=0x01528086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller' > class = display > subclass = VGA > bar [10] = type Memory, range 64, base 0xf780, size 4194304, enabled > bar [18] = type Prefetchable Memory, range 64, base 0xe000, size > 268435456, > enabled bar [20] = type I/O Port, range 32, base 0xf000, size 64, enabled > cap 05[90] = MSI supports 1 message > cap 01[d0] = powerspec 2 supports D0 D3 current D0 > cap 13[a4] = PCI Advanced Features: FLR TP > > > The very same CURRENT (most recent as I built world on all system today) > doesn't > recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to me > that > people can report having this GPU working if even the most recent FreeBSD > CURRENT > doesn't recognize it. Sorry, on the laptop in question the integrated HD4600 does show up as a vga0: device in the pciconf-listing (it is very early and I stoped looking at the very end ...). signature.asc Description: PGP signature
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On Sat, 20 Sep 2014, O. Hartmann wrote: Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) Warren Block schrieb: On Fri, 19 Sep 2014, O. Hartmann wrote: nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated nVidia GT 740M (Optimus) working correctly. Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The extra GPU uses the same display memory and can be enabled to speed up the Intel graphics or disabled for power saving. I don't know if versions where the Nvidia section is a full discrete video adapter that can be used alone are still called "Optimus". Some Optimus owners have reported being able to use the Intel drivers after disabling the Nvidia GPU in the BIOS or UEFI. If an option to disable the Nvidia GPU is not present, some people have reported success with an xorg.conf that uses only the intel driver and ignores the Nvidia hardware. Thanks Warren. But this sounds even more frustrating now. I look around the web even at Lenovo's support forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor with Optimus technology and everything sounds to me like it can be selected exclusively. What you describes is that I definitely need to use the HD4600 iGPU on FreeBSD in the first place since the nVidia hardware is a kind of "appendix" to the HD4600. Optimus started out that way, but they might use the same name now for models where the additional GPU is a full discrete adapter. Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work properly: it doesn't even start up and loading the "intel" driver complains about a missing device - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv manner, that this HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: entry in the kernel log when enabling "Integrated Graphics" only in the laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized vga0: device shows up. Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not support Haswell video yet. ___ 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: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On Sat, 20 Sep 2014, O. Hartmann wrote: The very same CURRENT (most recent as I built world on all system today) doesn't recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to me that people can report having this GPU working if even the most recent FreeBSD CURRENT doesn't recognize it. Sorry, on the laptop in question the integrated HD4600 does show up as a vga0: device in the pciconf-listing (it is very early and I stoped looking at the very end ...). At this point, it's worth trying the vesa driver, which should work on Haswell. ___ 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: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD
Hi Freddie, this is a preliminary version and, for now, we have not analyzed all aspects. Thanks for your suggestion. We will try to analyze how the GSO affects IPFW as soon as possible. Cheers, Stefano 2014-09-18 17:27 GMT+02:00 Freddie Cash : > On Thu, Sep 18, 2014 at 7:16 AM, Stefano Garzarella < > stefanogarzare...@gmail.com> wrote: > >> I saw the discussion about TSO, but the GSO is a software >> implementation unrelated with the hardware. >> Furthermore, if the TSO is enabled (and supported by the NIC), the GSO is >> not executed, because is useless. >> >> After the execution of the GSO, the packets, that are passed to the device >> driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For >> this reason the GSO doesn't look neither "ifp->if_hw_tsomax" nor hardware >> segment limits. >> >> The GSO is very useful when you can't use the TSO. >> > > How does GSO affect IPFW, specifically the libalias(3)-based, in-kernel > NAT? The ipfw(8) man page mentions that it doesn't play nicely with > hardware-based TSO, and that one should disable TSO when using IPFW NAT. > > Will the software-based GSO play nicely with IPFW NAT? Will it make any > difference to packet throughput through IPFW? > > Or is it still way too early in development to be worrying about such > things? :) > > -- > Freddie Cash > fjwc...@gmail.com > -- *Stefano Garzarella* stefano.garzare...@gmail.com ___ 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: libthr and main thread stack size
On Fri, Sep 19, 2014 at 03:27:25PM -0400, John Baldwin wrote:
> I suspect it was done out of reasons of being overly conservative in
> interpreting RLIMIT_STACK. I think it is quite surprising behavior
> though and would rather we make your option the default and implement
> what the Open Group says above.
Ok, below is the patch. I felt bad about adding yet another magic and
undocumented tunable to our libthr. Since there seems to be no
alternative than a tunable to enforce old behaviour, I documented
the quirks I am aware of.
Doc people, please review the man page in the patch.
diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c
index 9bf0e29..72a067a 100644
--- a/lib/libthr/thread/thr_init.c
+++ b/lib/libthr/thread/thr_init.c
@@ -445,7 +445,7 @@ init_private(void)
struct rlimit rlim;
size_t len;
int mib[2];
- char *env;
+ char *env, *env_bigstack, *env_splitstack;
_thr_umutex_init(&_mutex_static_lock);
_thr_umutex_init(&_cond_static_lock);
@@ -473,8 +473,9 @@ init_private(void)
len = sizeof (_usrstack);
if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) == -1)
PANIC("Cannot get kern.usrstack from sysctl");
- env = getenv("LIBPTHREAD_BIGSTACK_MAIN");
- if (env != NULL) {
+ env_bigstack = getenv("LIBPTHREAD_BIGSTACK_MAIN");
+ env_splitstack = getenv("LIBPTHREAD_SPLITSTACK_MAIN");
+ if (bigstack != NULL || env_splitstack == NULL) {
if (getrlimit(RLIMIT_STACK, &rlim) == -1)
PANIC("Cannot get stack rlimit");
_thr_stack_initial = rlim.rlim_cur;
diff --git a/share/man/man7/libthr.7 b/share/man/man7/libthr.7
new file mode 100644
index 000..16d916f
--- /dev/null
+++ b/share/man/man7/libthr.7
@@ -0,0 +1,254 @@
+.\" Copyright (c) 2014 The FreeBSD Foundation, Inc.
+.\" All rights reserved.
+.\"
+.\" This documentation was written by Konstantin Belousov
+.\" under sponsorship from the FreeBSD Foundation.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd September 20, 2014
+.Dt libthr
+.Os
+.Sh NAME
+.Nm libthr
+.Nd FreeBSD implementation of the Posix threading library
+.Sh LIBRARY
+.Lb libpthread
+.Sh DESCRIPTION
+The man page documents the quirks and tunables of the
+.Fx
+implementation for the
+.Lb libpthread .
+When linking with the
+.Li -lpthread ,
+the run-time dependency
+.Dv libthr.so.3
+library is recorded in the produced object.
+.Pp
+The library is tigthly integrated with the Run-time Link-editor
+.Xr ld-elf.so.1 1
+and
+.Lb libc ,
+all three components must be built from the same source tree.
+Mixing
+.Dv libc.so
+and
+.Nm
+libraries from different versions of
+.Fx
+is not supported.
+The run-time linker
+.Li ld-elf.so.1
+has some code to ensure backward-compatibility with older
+.Nm .
+.Sh MUTEX ACQUISITION
+The locked mutex (see
+.Xr pthread_mutex_lock 3 )
+is represented by a volatile variable of type
+.Dv lwpid_t ,
+which records the global system identifier of the thread
+owning the lock.
+The
+.Nm
+performs a congested mutex acquisition in three stages, each of which
+is more resource-consuming than the previous.
+.Pp
+First, the
+.Li spin loop
+is performed, where the library attempts to acquire the lock by
+.Xr atomic 9
+operations.
+The loop count is controlled by the
+.Ev LIBPTHREAD_SPINLOOPS
+environment variable.
+.Pp
+If the
+.Li spin loop
+was unable to acquire the mutex, the
+.Li yield loop
+is executed, performing the same
+.Xr atomic 9
+acquisition attempts as
+.Li spin loop ,
+but each attempt is followed by yield of the C
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) Warren Block schrieb: > On Sat, 20 Sep 2014, O. Hartmann wrote: > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > Warren Block schrieb: > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > >> > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in > >>> FreeBSD > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo > >>> ThinkPad > >>> Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel > >>> iGPU and > >>> dedicated nVidia GT 740M (Optimus) working correctly. > >> > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The > >> extra GPU uses the same display memory and can be enabled to speed up > >> the Intel graphics or disabled for power saving. I don't know if > >> versions where the Nvidia section is a full discrete video adapter that > >> can be used alone are still called "Optimus". > >> > >> Some Optimus owners have reported being able to use the Intel drivers > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > >> disable the Nvidia GPU is not present, some people have reported success > >> with an xorg.conf that uses only the intel driver and ignores the Nvidia > >> hardware. > > > > Thanks Warren. > > > > But this sounds even more frustrating now. I look around the web even at > > Lenovo's > > support forum. Many people report the GT 740M nVidia adaptor as a discrete > > adaptor > > with Optimus technology and everything sounds to me like it can be selected > > exclusively. What you describes is that I definitely need to use the HD4600 > > iGPU on > > FreeBSD in the first place since the nVidia hardware is a kind of > > "appendix" to the > > HD4600. > > Optimus started out that way, but they might use the same name now for > models where the additional GPU is a full discrete adapter. I tried to retrieve informations about the settings and implementations in the lenovo E540, but I guess the only answer can be given by developer documentation. I can not figure out how the GPU is attached to the system. The technical specifications do not mention the requirement of a iGPU and shared memory - as Optimus would require. But extrapolating from that "shit-covering" public relations talking at nVidia's site I guess the GT 740M is definitely a shared memory solution and requires the presence of the iGPU. That would explain why the nvidia BLOB is detecting the GPU, but can not find any physical display socket, not even the built-in LCD. They're maybe wired all throught the Haswell's HD4600 iGPU? > > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work > > properly: it > > doesn't even start up and loading the "intel" driver complains about a > > missing device > > - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv > > manner, that > > this HD4600 isn't recodnized by the kernel, either. I do not see any kind > > of vga0: > > entry in the kernel log when enabling "Integrated Graphics" only in the > > laptop's > > UEFI/Firmware. When enabling "nVidia Optimus", a recognized vga0: device > > shows up. > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not support > Haswell video yet. I suspected that :-( Thanks anyway, Oliver signature.asc Description: PGP signature
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
Am Sat, 20 Sep 2014 19:15:30 +0200 "O. Hartmann" schrieb: > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) > Warren Block schrieb: > > > On Sat, 20 Sep 2014, O. Hartmann wrote: > > > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > > Warren Block schrieb: > > > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > > >> > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in > > >>> FreeBSD > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo > > >>> ThinkPad > > >>> Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 > > >>> Intel iGPU and > > >>> dedicated nVidia GT 740M (Optimus) working correctly. > > >> > > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The > > >> extra GPU uses the same display memory and can be enabled to speed up > > >> the Intel graphics or disabled for power saving. I don't know if > > >> versions where the Nvidia section is a full discrete video adapter that > > >> can be used alone are still called "Optimus". > > >> > > >> Some Optimus owners have reported being able to use the Intel drivers > > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > > >> disable the Nvidia GPU is not present, some people have reported success > > >> with an xorg.conf that uses only the intel driver and ignores the Nvidia > > >> hardware. > > > > > > Thanks Warren. > > > > > > But this sounds even more frustrating now. I look around the web even at > > > Lenovo's > > > support forum. Many people report the GT 740M nVidia adaptor as a > > > discrete adaptor > > > with Optimus technology and everything sounds to me like it can be > > > selected > > > exclusively. What you describes is that I definitely need to use the > > > HD4600 iGPU on > > > FreeBSD in the first place since the nVidia hardware is a kind of > > > "appendix" to the > > > HD4600. > > > > Optimus started out that way, but they might use the same name now for > > models where the additional GPU is a full discrete adapter. > > I tried to retrieve informations about the settings and implementations in > the lenovo > E540, but I guess the only answer can be given by developer documentation. I > can not > figure out how the GPU is attached to the system. The technical > specifications do not > mention the requirement of a iGPU and shared memory - as Optimus would > require. > > But extrapolating from that "shit-covering" public relations talking at > nVidia's site I > guess the GT 740M is definitely a shared memory solution and requires the > presence of > the iGPU. That would explain why the nvidia BLOB is detecting the GPU, but > can not find > any physical display socket, not even the built-in LCD. They're maybe wired > all throught > the Haswell's HD4600 iGPU? > > > > > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work > > > properly: > > > it doesn't even start up and loading the "intel" driver complains about a > > > missing > > > device > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv > > > manner, > > > that this HD4600 isn't recodnized by the kernel, either. I do not see any > > > kind of > > > vga0: entry in the kernel log when enabling "Integrated Graphics" only in > > > the > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized > > > vga0: device > > > shows up. > > > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not support > > Haswell video yet. > > > I suspected that :-( > > Thanks anyway, > > Oliver Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find x11-drivers/xf86-video-nv, which covers old hardware and it is not applicable to the GT 740M (complains, rightfully, that the found device isn't supported by the "nv" driver). I face a mess here ... :-( signature.asc Description: PGP signature
FreeBSD-11.0-CURRENT on ARM: performance and load average
Hello everyone, Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 to be precise). The problem was that the load average was above 2. Including the fact that the board has 2 CPU cores, that's strange. Also, the network throughput was way too slow: from 3 kilobytes per second earlier to 20..50 about now. Here's a workaround for that: > sysctl kern.eventtimer.periodic=1 With that, the network performance increased while LA decreased to a decent 0.3..0.5. -- wbr, Maxim Filimonov c...@bein.link ___ 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-11.0-CURRENT on ARM: performance and load average
Hello everyone, Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 to be precise). The problem was that the load average was above 2. Including the fact that the board has 2 CPU cores, that's strange. Also, the network throughput was way too slow: from 3 kilobytes per second earlier to 20..50 about now. Here's a workaround for that: > sysctl kern.eventtimer.periodic=1 With that, the network performance increased while LA decreased to a decent 0.3..0.5. -- wbr, Maxim Filimonov c...@bein.link ___ 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: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote: > Am Sat, 20 Sep 2014 19:15:30 +0200 > "O. Hartmann" schrieb: > > > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) > > Warren Block schrieb: > > > > > On Sat, 20 Sep 2014, O. Hartmann wrote: > > > > > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > > > Warren Block schrieb: > > > > > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > > > >> > > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in > > > >>> FreeBSD > > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on > > > >>> Lenovo ThinkPad > > > >>> Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 > > > >>> Intel iGPU and > > > >>> dedicated nVidia GT 740M (Optimus) working correctly. > > > >> > > > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The > > > >> extra GPU uses the same display memory and can be enabled to speed up > > > >> the Intel graphics or disabled for power saving. I don't know if > > > >> versions where the Nvidia section is a full discrete video adapter that > > > >> can be used alone are still called "Optimus". > > > >> > > > >> Some Optimus owners have reported being able to use the Intel drivers > > > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > > > >> disable the Nvidia GPU is not present, some people have reported > > > >> success > > > >> with an xorg.conf that uses only the intel driver and ignores the > > > >> Nvidia > > > >> hardware. > > > > > > > > Thanks Warren. > > > > > > > > But this sounds even more frustrating now. I look around the web even > > > > at Lenovo's > > > > support forum. Many people report the GT 740M nVidia adaptor as a > > > > discrete adaptor > > > > with Optimus technology and everything sounds to me like it can be > > > > selected > > > > exclusively. What you describes is that I definitely need to use the > > > > HD4600 iGPU on > > > > FreeBSD in the first place since the nVidia hardware is a kind of > > > > "appendix" to the > > > > HD4600. > > > > > > Optimus started out that way, but they might use the same name now for > > > models where the additional GPU is a full discrete adapter. > > > > I tried to retrieve informations about the settings and implementations in > > the lenovo > > E540, but I guess the only answer can be given by developer documentation. > > I can not > > figure out how the GPU is attached to the system. The technical > > specifications do not > > mention the requirement of a iGPU and shared memory - as Optimus would > > require. > > > > But extrapolating from that "shit-covering" public relations talking at > > nVidia's site I > > guess the GT 740M is definitely a shared memory solution and requires the > > presence of > > the iGPU. That would explain why the nvidia BLOB is detecting the GPU, but > > can not find > > any physical display socket, not even the built-in LCD. They're maybe wired > > all throught > > the Haswell's HD4600 iGPU? > > > > > > > > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't > > > > work properly: > > > > it doesn't even start up and loading the "intel" driver complains about > > > > a missing > > > > device > > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in a > > > > naiv manner, > > > > that this HD4600 isn't recodnized by the kernel, either. I do not see > > > > any kind of > > > > vga0: entry in the kernel log when enabling "Integrated Graphics" only > > > > in the > > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized > > > > vga0: device > > > > shows up. > > > > > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not support > > > Haswell video yet. > > > > > > I suspected that :-( > > > > Thanks anyway, > > > > Oliver > > Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find > x11-drivers/xf86-video-nv, which covers old hardware and it is not applicable > to the GT > 740M (complains, rightfully, that the found device isn't supported by the > "nv" driver). > > I face a mess here ... :-( It was removed, because we missing kernel support for the nouveau driver. ___ 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: FreeBSD-11.0-CURRENT on ARM: performance and load average
On Sat, 2014-09-20 at 22:44 +0400, Maxim V FIlimonov wrote: > Hello everyone, > > Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 > to be precise). The problem was that the load average was above 2. Including > the fact that the board has 2 CPU cores, that's strange. Also, the network > throughput was way too slow: from 3 kilobytes per second earlier to 20..50 > about now. > > Here's a workaround for that: > > sysctl kern.eventtimer.periodic=1 > With that, the network performance increased while LA decreased to a decent > 0.3..0.5. Since it's happening only on that hardware, there's a good chance the problem is in the allwinner a10/a20 clock driver, not in the general eventtimer code. In fact, looking at the code it appears that a divide-by-16 is being set in the hardware, but not accounted for when setting the frequency of the eventtimer. Hmm, it should affect the timecounter too, in which case you'd see time-of-day advancing 16x too fast. If ntpd is running it would need to step the clock pretty frequently, which would show up in syslog. I don't have hardware to test on, please see if the attached patch makes a difference. -- Ian Index: sys/arm/allwinner/timer.c === --- sys/arm/allwinner/timer.c (revision 271909) +++ sys/arm/allwinner/timer.c (working copy) @@ -199,7 +199,7 @@ a10_timer_attach(device_t dev) val |= TIMER_ENABLE; timer_write_4(sc, SW_TIMER_IRQ_EN_REG, val); - sc->timer0_freq = SYS_TIMER_CLKSRC; + sc->timer0_freq = SYS_TIMER_CLKSRC / 16; /* Set desired frequency in event timer and timecounter */ sc->et.et_frequency = sc->timer0_freq; ___ 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"
Crash in GEOM, booting on Soekris
I am seeing this crash on r271882, booting a Soekris 4501. POST: 012345689bcefghipsajklnopqr,,,tvwxy comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 Soekris Engineering. net45xx 0064 Mbyte MemoryCPU Elan SC520 133 Mhz Pri Mas SanDisk SDCFX-016G LBA Xlt 1024--63 15625 Mbyte Slot Vend Dev ClassRev Cmd Stat CL LT HT Base1Base2 Int --- 0:00:0 1022 3000 0600 0006 2280 00 00 00 0:18:0 100B 0020 0200 0107 0290 00 3F 00 E001 A000 10 0:19:0 100B 0020 0200 0107 0290 00 3F 00 E101 A0001000 11 0:20:0 100B 0020 0200 0107 0290 00 3F 00 E201 A0002000 05 1 Seconds to automatic boot. Press Ctrl-P for entering Monitor. /boot/config: -h Consoles: serial port BIOS drive C: is disk0 BIOS 639kB/64512kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (tom@bernice, Fri Sep 19 19:39:16 MDT 2014) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x790cd5 data=0x5e2a0+0x2f0eb8 syms=[0x4+0x89480+0x4+0xebe59] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r271882M: Fri Sep 19 20:21:03 MDT 2014 tom@bernice:/storage/home/tom/crochet-kientzle/crochet-freebsd/work/obj/i386.i386/storage/home/tom/crochet/src/FreeBSDHead/head/sys/SOEKRIS i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD Enhanced Am486DX4/Am5x86 Write-Back (486-class CPU) Origin="AuthenticAMD" Id=0x494 Family=0x4 Model=0x9 Stepping=4 Features=0x1 real memory = 67108864 (64 MB) avail memory = 47398912 (45 MB) random device not loaded; using insecure entropy random: initialized module_register_init: MOD_LOAD (vesa, 0xc0a447c0, 0) error 19 kbd1 at kbdmux0 ACPI BIOS Error (bug): A valid RSDP was not found (20130823/tbxfroot-223) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. sysctl machdep.i8254_freq=1189161 returns 0 Timecounter "ELAN" frequency 833 Hz quality 1000 pcib0 pcibus 0 on motherboard pci0: on pcib0 sis0: port 0xe000-0xe0ff mem 0xa000-0xafff irq 10 at device 18.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:c8:d4:d4 sis1: port 0xe100-0xe1ff mem 0xa0001000-0xa0001fff irq 11 at device 19.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: on sis1 nsphyter1: PHY 0 on miibus1 nsphyter1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:c8:d4:d5 sis2: port 0xe200-0xe2ff mem 0xa0002000-0xa0002fff irq 5 at device 20.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: on sis2 nsphyter2: PHY 0 on miibus2 nsphyter2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:c8:d4:d6 cpu0 on motherboard isa0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc8000-0xd0fff pnpid ORM on isa0 ata0: at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1: at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1189161 Hz quality 0 Event timer "i8254" frequency 1189161 Hz quality 100 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 Timecounters tick every 1.000 msec interrupt storm detected on "irq5:"; throttling interrupt source Elan-mmcr driver: MMCR at 0xc37ff000. Elan-mmcr Soekris net45xx comBIOS ver. 1.33 20080103 Copyright (C) 2000-2007 random: unblocking device. ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: CFA-0 device ada0: Serial Number AJZ061813191928 ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 15259MB (31250432 512 byte sectors: 16H 63S/T 31002C) ada0: Previously was known as ad0 panic: Bio not on queue bp=0xc2aaa4c0 target 0xc0c0f8bc KDB: stack backtrace: db_trace_self_wrapper(c0b3f07a,c29eb800,c2689be4,c06231d1,c29eb830,...) at db_trace_self_wrapper+0x2d/frame 0xc2689bb8 kdb_backtrace(c0b3a646,c0c11888,c0b277fe,c2689c70,c0b277fe,...) at kdb_backtrace+0x30/frame 0xc2689c1c vpanic(c0c11728,100,c0b277fe,c2689c70,c2689c70,...) at vpanic+0x80/frame 0xc2689c40 kassert_panic(c0b277fe,c2aaa4c0,c0c0f8bc,0,c28cfc40,...) at kas
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On 09/20/14 07:27, Warren Block wrote: On Sat, 20 Sep 2014, O. Hartmann wrote: Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) Warren Block schrieb: On Fri, 19 Sep 2014, O. Hartmann wrote: nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated nVidia GT 740M (Optimus) working correctly. Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The extra GPU uses the same display memory and can be enabled to speed up the Intel graphics or disabled for power saving. I don't know if versions where the Nvidia section is a full discrete video adapter that can be used alone are still called "Optimus". Some Optimus owners have reported being able to use the Intel drivers after disabling the Nvidia GPU in the BIOS or UEFI. If an option to disable the Nvidia GPU is not present, some people have reported success with an xorg.conf that uses only the intel driver and ignores the Nvidia hardware. Thanks Warren. But this sounds even more frustrating now. I look around the web even at Lenovo's support forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor with Optimus technology and everything sounds to me like it can be selected exclusively. What you describes is that I definitely need to use the HD4600 iGPU on FreeBSD in the first place since the nVidia hardware is a kind of "appendix" to the HD4600. Optimus started out that way, but they might use the same name now for models where the additional GPU is a full discrete adapter. Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work properly: it doesn't even start up and loading the "intel" driver complains about a missing device - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv manner, that this HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: entry in the kernel log when enabling "Integrated Graphics" only in the laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized vga0: device shows up. Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not support Haswell video yet. Is there any kind of status update on Haswell? The wiki has the last update 11 months ago and it's becoming a major useability issue for the operating system. -Nathan ___ 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"
memo: Re: [PATCH] Fix integer overflow handling in dd(1)
pick
On 9/20/14, William Orr wrote:
> Hey,
>
> I've submitted this patch before, and it's gotten comments and fixes,
> but still hasn't been merged. Any thoughts? Does it need more work?
>
> Thanks,
> William Orr
>
> Index: args.c
> ===
> --- args.c(revision 270645)
> +++ args.c(working copy)
> @@ -41,6 +41,7 @@
>
> #include
>
> +#include
> #include
> #include
> #include
> @@ -171,8 +172,7 @@
>*/
> if (in.offset > OFF_MAX / (ssize_t)in.dbsz ||
> out.offset > OFF_MAX / (ssize_t)out.dbsz)
> -errx(1, "seek offsets cannot be larger than %jd",
> -(intmax_t)OFF_MAX);
> +errx(1, "seek offsets cannot be larger than %jd", OFF_MAX);
> }
>
> static int
> @@ -186,37 +186,28 @@
> static void
> f_bs(char *arg)
> {
> -uintmax_t res;
>
> -res = get_num(arg);
> -if (res < 1 || res > SSIZE_MAX)
> -errx(1, "bs must be between 1 and %jd", (intmax_t)SSIZE_MAX);
> -in.dbsz = out.dbsz = (size_t)res;
> +in.dbsz = out.dbsz = get_num(arg);
> +if (out.dbsz < 1 || out.dbsz > SSIZE_MAX)
> +errx(1, "bs must be between 1 and %jd", SSIZE_MAX);
> }
>
> static void
> f_cbs(char *arg)
> {
> -uintmax_t res;
>
> -res = get_num(arg);
> -if (res < 1 || res > SSIZE_MAX)
> -errx(1, "cbs must be between 1 and %jd", (intmax_t)SSIZE_MAX);
> -cbsz = (size_t)res;
> +cbsz = get_num(arg);
> +if (cbsz < 1 || cbsz > SSIZE_MAX)
> +errx(1, "cbs must be between 1 and %jd", SSIZE_MAX);
> }
>
> static void
> f_count(char *arg)
> {
> -intmax_t res;
>
> -res = (intmax_t)get_num(arg);
> -if (res < 0)
> -errx(1, "count cannot be negative");
> -if (res == 0)
> -cpy_cnt = (uintmax_t)-1;
> -else
> -cpy_cnt = (uintmax_t)res;
> +cpy_cnt = get_num(arg);
> +if (cpy_cnt == 0)
> +cpy_cnt = -1;
> }
>
> static void
> @@ -225,7 +216,7 @@
>
> files_cnt = get_num(arg);
> if (files_cnt < 1)
> -errx(1, "files must be between 1 and %jd", (uintmax_t)-1);
> +errx(1, "files must be between 1 and %ju", SIZE_MAX);
> }
>
> static void
> @@ -241,14 +232,11 @@
> static void
> f_ibs(char *arg)
> {
> -uintmax_t res;
>
> if (!(ddflags & C_BS)) {
> -res = get_num(arg);
> -if (res < 1 || res > SSIZE_MAX)
> -errx(1, "ibs must be between 1 and %jd",
> -(intmax_t)SSIZE_MAX);
> -in.dbsz = (size_t)res;
> +in.dbsz = get_num(arg);
> +if (in.dbsz < 1 || in.dbsz > SSIZE_MAX)
> +errx(1, "ibs must be between 1 and %ju", SSIZE_MAX);
> }
> }
>
> @@ -262,14 +250,11 @@
> static void
> f_obs(char *arg)
> {
> -uintmax_t res;
>
> if (!(ddflags & C_BS)) {
> -res = get_num(arg);
> -if (res < 1 || res > SSIZE_MAX)
> -errx(1, "obs must be between 1 and %jd",
> -(intmax_t)SSIZE_MAX);
> -out.dbsz = (size_t)res;
> +out.dbsz = get_num(arg);
> +if (out.dbsz < 1 || out.dbsz > SSIZE_MAX)
> +errx(1, "obs must be between 1 and %jd", SSIZE_MAX);
> }
> }
>
> @@ -378,11 +363,17 @@
> uintmax_t num, mult, prevnum;
> char *expr;
>
> +while (isspace(val[0]))
> +val++;
> +
> +if (val[0] == '-')
> +errx(1, "%s: cannot be negative", oper);
> +
> errno = 0;
> -num = strtouq(val, &expr, 0);
> +num = strtoull(val, &expr, 0);
> if (errno != 0)/* Overflow or underflow. */
> err(1, "%s", oper);
> -
> +
> if (expr == val)/* No valid digits. */
> errx(1, "%s: illegal numeric value", oper);
>
> Index: conv.c
> ===
> --- conv.c(revision 270645)
> +++ conv.c(working copy)
> @@ -133,7 +133,7 @@
>*/
> ch = 0;
> for (inp = in.dbp - in.dbcnt, outp = out.dbp; in.dbcnt;) {
> -maxlen = MIN(cbsz, in.dbcnt);
> +maxlen = MIN(cbsz, (size_t)in.dbcnt);
> if ((t = ctab) != NULL)
> for (cnt = 0; cnt < maxlen && (ch = *inp++) != '\n';
> ++cnt)
> @@ -146,7 +146,7 @@
>* Check for short record without a newline. Reassemble the
>* input block.
>*/
> -if (ch != '\n' && in.dbcnt < cbsz) {
> +if (ch != '\n' && (size_t)in.dbcnt < cbsz) {
> (void)memmove(in.db, in.dbp - in.dbcnt, in.dbcnt);
> break;
> }
> @@ -228,7 +228,7 @@
>* translation has to already be done or we might not recognize the
>* spaces.
>*/
> -for (inp = in.db; in.dbcnt >= cbsz; inp += cbsz, in.dbcnt -= cbsz) {
> +for (inp = in.db; (size_t)in.dbcnt >= cbsz; inp += cbsz, in.dbcnt
> -= cbsz) {
> for (t = inp + cbsz - 1; t >= inp && *t == ' '; --t)
> ;
> if (
Re: FreeBSD-11.0-CURRENT on ARM: performance and load average
On Saturday 20 September 2014 13:24:08 Ian Lepore wrote: > Since it's happening only on that hardware, there's a good chance the > problem is in the allwinner a10/a20 clock driver, not in the general > eventtimer code. In fact, looking at the code it appears that a > divide-by-16 is being set in the hardware, but not accounted for when > setting the frequency of the eventtimer. > > Hmm, it should affect the timecounter too, in which case you'd see > time-of-day advancing 16x too fast. If ntpd is running it would need to > step the clock pretty frequently, which would show up in syslog. > I'm running FreeBSD-current on the board right now, the time is just fine. > I don't have hardware to test on, please see if the attached patch makes > a difference. > Well, it did: with the patch applied, the time ran about 60 times as fast as it should have. I didn't notice any changes with load average, though: maybe it's because I forgot to turn that sysctl setting I set before back to 0. wbr, Maxim Filimonov c...@bein.link ___ 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: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
Am Sat, 20 Sep 2014 21:21:46 +0200 Koop Mast schrieb: > On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote: > > Am Sat, 20 Sep 2014 19:15:30 +0200 > > "O. Hartmann" schrieb: > > > > > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) > > > Warren Block schrieb: > > > > > > > On Sat, 20 Sep 2014, O. Hartmann wrote: > > > > > > > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > > > > Warren Block schrieb: > > > > > > > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > > > > >> > > > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems in > > > > >>> FreeBSD > > > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on > > > > >>> Lenovo > > > > >>> ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with > > > > >>> integrated HD4600 > > > > >>> Intel iGPU and dedicated nVidia GT 740M (Optimus) working correctly. > > > > >> > > > > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU. > > > > >> The > > > > >> extra GPU uses the same display memory and can be enabled to speed up > > > > >> the Intel graphics or disabled for power saving. I don't know if > > > > >> versions where the Nvidia section is a full discrete video adapter > > > > >> that > > > > >> can be used alone are still called "Optimus". > > > > >> > > > > >> Some Optimus owners have reported being able to use the Intel drivers > > > > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option to > > > > >> disable the Nvidia GPU is not present, some people have reported > > > > >> success > > > > >> with an xorg.conf that uses only the intel driver and ignores the > > > > >> Nvidia > > > > >> hardware. > > > > > > > > > > Thanks Warren. > > > > > > > > > > But this sounds even more frustrating now. I look around the web even > > > > > at > > > > > Lenovo's support forum. Many people report the GT 740M nVidia adaptor > > > > > as a > > > > > discrete adaptor with Optimus technology and everything sounds to me > > > > > like it > > > > > can be selected exclusively. What you describes is that I definitely > > > > > need to > > > > > use the HD4600 iGPU on FreeBSD in the first place since the nVidia > > > > > hardware is > > > > > a kind of "appendix" to the HD4600. > > > > > > > > Optimus started out that way, but they might use the same name now for > > > > models where the additional GPU is a full discrete adapter. > > > > > > I tried to retrieve informations about the settings and implementations > > > in the > > > lenovo E540, but I guess the only answer can be given by developer > > > documentation. I > > > can not figure out how the GPU is attached to the system. The technical > > > specifications do not mention the requirement of a iGPU and shared memory > > > - as > > > Optimus would require. > > > > > > But extrapolating from that "shit-covering" public relations talking at > > > nVidia's > > > site I guess the GT 740M is definitely a shared memory solution and > > > requires the > > > presence of the iGPU. That would explain why the nvidia BLOB is detecting > > > the GPU, > > > but can not find any physical display socket, not even the built-in LCD. > > > They're > > > maybe wired all throught the Haswell's HD4600 iGPU? > > > > > > > > > > > > Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't > > > > > work > > > > > properly: it doesn't even start up and loading the "intel" driver > > > > > complains > > > > > about a missing device > > > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in a > > > > > naiv manner, > > > > > that this HD4600 isn't recodnized by the kernel, either. I do not see > > > > > any kind > > > > > of vga0: entry in the kernel log when enabling "Integrated Graphics" > > > > > only in the > > > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized > > > > > vga0: > > > > > device shows up. > > > > > > > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not > > > > support > > > > Haswell video yet. > > > > > > > > > I suspected that :-( > > > > > > Thanks anyway, > > > > > > Oliver > > > > Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find > > x11-drivers/xf86-video-nv, which covers old hardware and it is not > > applicable to the > > GT 740M (complains, rightfully, that the found device isn't supported by > > the "nv" > > driver). > > > > I face a mess here ... :-( > > It was removed, because we missing kernel support for the nouveau > driver. So, every new GPU not supported by xf86-video-nv has to use nVidia's BLOB then? signature.asc Description: PGP signature
Re: libthr and main thread stack size
On 9/20/14, 3:27 AM, John Baldwin wrote: On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote: On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote: On Aug 8, 2014, at 5:22 AM, Konstantin Belousov wrote: ? Below is the patch which adds environment variable LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the main thread stack left as is, and other threads allocate stack below the area of RLIMIT_STACK. Try it. I do not want to set this behaviour as default. Is there a reason this should not be the default? Looking at the getrlimit() page on the OpenGroup?s site they say: RLIMIT_STACK This is the maximum size of the initial thread's stack, in bytes. The implementation does not automatically grow the stack beyond this limit. If this limit is exceeded, SIGSEGV shall be generated for the thread. If the thread is blocking SIGSEGV, or the process is ignoring or catching SIGSEGV and has not made arrangements to use an alternate stack, the disposition of SIGSEGV shall be set to SIG_DFL before it is generated. Does posix say something different? I ran into this issue when debugging a segfault on Postgres when running an (arguably quite bogus) query that should have fit within both the configured stack rlimit and Postgres? configured stack limit. The Postgres backend is really just single threaded, but happens to pull in libpthread due to the threading support in some of the libraries it uses. The segfault definitely violates POLA. ? Justin I am conservative to not disturb the address space layout in single go. If enough people test this setting, I can consider flipping the default to the reverse. I am still curious why the things were done in this way, but nobody replied. I suspect it was done out of reasons of being overly conservative in interpreting RLIMIT_STACK. I think it is quite surprising behavior though and would rather we make your option the default and implement what the Open Group says above. that is my memory.. The transition from a non threaded app to a threaded app with one thread is sort of an undefined area. Feel free to change it if Dan agrees.. ___ 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: FreeBSD-11.0-CURRENT on ARM: performance and load average
* Maxim V FIlimonov (c...@bein.link) wrote: > Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 > to be precise). The problem was that the load average was above 2. Including > the fact that the board has 2 CPU cores, that's strange. Also, the network > throughput was way too slow: from 3 kilobytes per second earlier to 20..50 > about now. > > Here's a workaround for that: > > sysctl kern.eventtimer.periodic=1 > With that, the network performance increased while LA decreased to a decent > 0.3..0.5. I'm just started to experiment with cubieboard (1) as well. I've also noticed poor network performance at first, however later (without any tuning) it gave out 111 kBps. kern.eventtimer.periodic doesn't seem to affect it. I've also played with clocks a bit, and was able to increase CPU rate 3x by configuring PLL1. I've experienced some instability later (board doesn't always boot from USB, perl build fails), and now I'm checking if reclocking was the cause. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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"
x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
Hi. Very preliminary question, but not mentioned before if I haven't missed it. Have you disabled Optimus? If not, you need to disable it (or definately select nvidia discrete GPU) in BIOS / UEFI firmware, as currently any version of nvidia proprietary driver for FreeBSD does NOT support Optimus. Please read /usr/local/share/doc/NVIDIA_GLX-1.0/README for detail. (The location could be different if you installed nvidia driver WITHOUT using ports nor pkg.) At least, my ThinkPad T420 has an option to select Optimus / internal intel GPU / nvidia discrete GPU, and I need to select nvidia discrete GPU to use x11/nvidia-driver. Sat Sep 20 23:11:54 UTC 2014 O. Hartmann wrote: >Am Sat, 20 Sep 2014 21:21:46 +0200 >Koop Mast schrieb: > >> On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote: >> > Am Sat, 20 Sep 2014 19:15:30 +0200 >> > "O. Hartmann" schrieb: >> > >> > > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) >> > > Warren Block schrieb: >> > > >> > > > On Sat, 20 Sep 2014, O. Hartmann wrote: >> > > > >> > > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) >> > > > > Warren Block schrieb: >> > > > > >> > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: >> > > > >> >> > > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problems >> > > > >>> >in FreeBSD >> > > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on >> > > > >>> >Lenovo >> > > > >>> ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with >> > > > >>> >integrated HD4600 >> > > > >>> Intel iGPU and dedicated nVidia GT 740M (Optimus) working >> > > > >>> >correctly. >> > > > >> >> > > > >> Optimus is supposed to be full Intel graphics plus an Nvidia >GPU. >> > > > >> The >> > > > >> extra GPU uses the same display memory and can be enabled to >speed >> > > > >> up >> > > > >> the Intel graphics or disabled for power saving. I don't know if >> > > > >> versions where the Nvidia section is a full discrete video >adapter >> > > > >> that >> > > > >> can be used alone are still called "Optimus". >> > > > >> >> > > > >> Some Optimus owners have reported being able to use the Intel >> > > > >> >drivers >> > > > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an option >> > > > >> >to >> > > > >> disable the Nvidia GPU is not present, some people have reported >> > > > >> >success >> > > > >> with an xorg.conf that uses only the intel driver and ignores the >> > > > >> >Nvidia >> > > > >> hardware. >> > > > > >> > > > > Thanks Warren. >> > > > > >> > > > > But this sounds even more frustrating now. I look around the web >> > > > > >even at >> > > > > Lenovo's support forum. Many people report the GT 740M nVidia >> > > > > >adaptor as a >> > > > > discrete adaptor with Optimus technology and everything sounds to >> > > > > >me like it >> > > > > can be selected exclusively. What you describes is that I >> > > > > >definitely need to >> > > > > use the HD4600 iGPU on FreeBSD in the first place since the nVidia >> > > > > >hardware is >> > > > > a kind of "appendix" to the HD4600. >> > > > >> > > > Optimus started out that way, but they might use the same name now >> > > > >for >> > > > models where the additional GPU is a full discrete adapter. >> > > >> > > I tried to retrieve informations about the settings and >> > > >implementations in the >> > > lenovo E540, but I guess the only answer can be given by developer >> > > >documentation. I >> > > can not figure out how the GPU is attached to the system. The technical >> > > specifications do not mention the requirement of a iGPU and shared >> > > >memory - as >> > > Optimus would require. >> > > >> > > But extrapolating from that "shit-covering" public relations talking >at >> > > nVidia's >> > > site I guess the GT 740M is definitely a shared memory solution and >> > > >requires the >> > > presence of the iGPU. That would explain why the nvidia BLOB is >> > > >detecting the GPU, >> > > but can not find any physical display socket, not even the built-in >> > > >LCD. They're >> > > maybe wired all throught the Haswell's HD4600 iGPU? >> > > >> > > > >> > > > > Anyway, I also tried to configure X11 as HD4600 only and X11 >> > > > > >doesn't work >> > > > > properly: it doesn't even start up and loading the "intel" driver >> > > > > >complains >> > > > > about a missing device >> > > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in >a >> > > > > naiv manner, >> > > > > that this HD4600 isn't recodnized by the kernel, either. I do not >> > > > > >see any kind >> > > > > of vga0: entry in the kernel log when enabling "Integrated >> > > > > >Graphics" only in the >> > > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a >> > > > > >recognized vga0: >> > > > > device shows up. >> > > > >> > > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not >> > > > >support >> > > > Haswell video yet. >> > > >> > > >> > > I suspected that :-( >> > > >> > > Thanks anyway, >> > > >> > > Olive
