Re: 11.0-CURRENT and Lenovo ThinkPad E540: No LAN, no WiFI

2014-09-20 Thread O. Hartmann
Am Mon, 15 Sep 2014 18:19:32 -0700
Kevin Oberman rkober...@gmail.com schrieb:

 On Mon, Sep 15, 2014 at 2:38 PM, O. Hartmann ohart...@zedat.fu-berlin.de
 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

2014-09-20 Thread Huang Wen Hui
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 andersb...@icloud.com:

 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 ema...@freebsd.org:

  On 24 May 2014 19:39, Rafael Espíndola rafael.espind...@gmail.com
 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-current
 To unsubscribe, send any mail to freebsd-current-unsubscribe@
 freebsd.org


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

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

2014-09-20 Thread Warren Block

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

2014-09-20 Thread O. Hartmann
Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
Warren Block wbl...@wonkity.com 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

2014-09-20 Thread Larry Rosenman

On 2014-09-20 09:10, O. Hartmann wrote:

Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
Warren Block wbl...@wonkity.com 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

2014-09-20 Thread O. Hartmann
Am Sat, 20 Sep 2014 16:10:12 +0200
O. Hartmann ohart...@zedat.fu-berlin.de schrieb:

 Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
 Warren Block wbl...@wonkity.com 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

2014-09-20 Thread Warren Block

On Sat, 20 Sep 2014, O. Hartmann wrote:


Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
Warren Block wbl...@wonkity.com 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

2014-09-20 Thread Warren Block

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

2014-09-20 Thread Stefano Garzarella
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 fjwc...@gmail.com:

 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

2014-09-20 Thread Konstantin Belousov
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 k...@freebsd.org
+.\ 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 CPU time of the thread by
+.Xr 

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

2014-09-20 Thread O. Hartmann
Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
Warren Block wbl...@wonkity.com schrieb:

 On Sat, 20 Sep 2014, O. Hartmann wrote:
 
  Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
  Warren Block wbl...@wonkity.com 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

2014-09-20 Thread O. Hartmann
Am Sat, 20 Sep 2014 19:15:30 +0200
O. Hartmann ohart...@zedat.fu-berlin.de schrieb:

 Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
 Warren Block wbl...@wonkity.com schrieb:
 
  On Sat, 20 Sep 2014, O. Hartmann wrote:
  
   Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
   Warren Block wbl...@wonkity.com 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

2014-09-20 Thread Maxim V FIlimonov
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

2014-09-20 Thread Maxim V FIlimonov
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

2014-09-20 Thread Koop Mast
On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote:
 Am Sat, 20 Sep 2014 19:15:30 +0200
 O. Hartmann ohart...@zedat.fu-berlin.de schrieb:
 
  Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
  Warren Block wbl...@wonkity.com schrieb:
  
   On Sat, 20 Sep 2014, O. Hartmann wrote:
   
Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
Warren Block wbl...@wonkity.com 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

2014-09-20 Thread Ian Lepore
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

2014-09-20 Thread Tom Everett
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=0x1FPU
real memory  = 67108864 (64 MB)
avail memory = 47398912 (45 MB)
random device not loaded; using insecure entropy
random: Software, Yarrow 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: PCI bus on pcib0
sis0: NatSemi DP8381[56] 10/100BaseTX port 0xe000-0xe0ff mem
0xa000-0xafff irq 10 at device 18.0 on pci0
sis0: Silicon Revision: DP83816A
miibus0: MII bus on sis0
nsphyter0: DP83815 10/100 media interface PHY 0 on miibus0
nsphyter0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sis0: Ethernet address: 00:00:24:c8:d4:d4
sis1: NatSemi DP8381[56] 10/100BaseTX port 0xe100-0xe1ff mem
0xa0001000-0xa0001fff irq 11 at device 19.0 on pci0
sis1: Silicon Revision: DP83816A
miibus1: MII bus on sis1
nsphyter1: DP83815 10/100 media interface PHY 0 on miibus1
nsphyter1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sis1: Ethernet address: 00:00:24:c8:d4:d5
sis2: NatSemi DP8381[56] 10/100BaseTX port 0xe200-0xe2ff mem
0xa0002000-0xa0002fff irq 5 at device 20.0 on pci0
sis2: Silicon Revision: DP83816A
miibus2: MII bus on sis2
nsphyter2: DP83815 10/100 media interface 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: ISA bus on motherboard
pmtimer0 on isa0
orm0: ISA Option ROM at iomem 0xc8000-0xd0fff pnpid ORM on isa0
ata0: ATA channel at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
ata1: ATA channel at port 0x170-0x177,0x376 irq 15 on isa0
atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atrtc0: AT realtime clock at port 0x70 irq 8 on isa0
Event timer RTC frequency 32768 Hz quality 0
attimer0: AT timer 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: SanDisk SDCFX-016G HDX 7.03 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:

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

2014-09-20 Thread Nathan Whitehorn


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 wbl...@wonkity.com 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)

2014-09-20 Thread Oliver Pinter
pick

On 9/20/14, William Orr w...@worrbase.com 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 sys/types.h

 +#include ctype.h
   #include err.h
   #include errno.h
   #include inttypes.h
 @@ -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 (t = inp) {
 Index: dd.c
 ===
 --- dd.c(revision 270645)
 +++ dd.c(working copy)
 @@ -168,10 +168,10 @@
* 

Re: FreeBSD-11.0-CURRENT on ARM: performance and load average

2014-09-20 Thread Maxim V FIlimonov
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

2014-09-20 Thread O. Hartmann
Am Sat, 20 Sep 2014 21:21:46 +0200
Koop Mast k...@rainbow-runner.nl schrieb:

 On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote:
  Am Sat, 20 Sep 2014 19:15:30 +0200
  O. Hartmann ohart...@zedat.fu-berlin.de schrieb:
  
   Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
   Warren Block wbl...@wonkity.com schrieb:
   
On Sat, 20 Sep 2014, O. Hartmann wrote:

 Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
 Warren Block wbl...@wonkity.com 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

2014-09-20 Thread Julian Elischer

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 kostik...@gmail.com
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

2014-09-20 Thread Dmitry Marakasov
* 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

2014-09-20 Thread Tomoaki AOKI
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 ohart...@zedat.fu-berlin.de wrote:

Am Sat, 20 Sep 2014 21:21:46 +0200
Koop Mast kwm at rainbow-runner.nl schrieb:

 On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote:
  Am Sat, 20 Sep 2014 19:15:30 +0200
  O. Hartmann ohartman at zedat.fu-berlin.de schrieb:
  
   Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT)
   Warren Block wblock at wonkity.com schrieb:
   
On Sat, 20 Sep 2014, O. Hartmann wrote:

 Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT)
 Warren Block wblock at wonkity.com 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?

-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp