Aw: recent change to vim defaults?

[Carsten Kunze]

Julian Elischer  wrote:

> I noticed that suddenly vim is grabbing mouse movements, which makes 
> life really hard.
> 
> Was there a specific revision that brought in this change, and can it 
> be removed?

Of course this behavior can be disabled as suggested by others--or you give it 
a try.  IMHO using the mouse in vim has many advantages.  To temporarily 
disable the mouse you can press the SHIFT key.  As long as SHIFT is pressed vim 
ignores the mouse.  So you may use copy/paste with left and middle mouse 
buttons as before or you now use the mouse to position the cursor or select 
text--very useful IMHO (I actually have "set mouse=a" in .vimrc... ;)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WLAN hardware not recognized

[Carsten Kunze]

Adrian Chadd  wrote:

> Right, you need to create the interface:
> 
> ifconfig wlan0 create wlandev iwn0
> 
> then run wpa_spuplicant
> 
> (or do it all in /etc/rc.conf .. :)

That seems to work.  There seems to be something configured wrong for 
wpa_supplicant but WLAN does react.

Thank you for all your WLAN work!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WLAN hardware not recognized

[Carsten Kunze]

Conrad Meyer  wrote:

> "[1] iwn0:  mem 0xf7b0-0xf7b01fff
> irq 18 at device 0.0 on pci3" is fine; "module iwn already present!"
> is fine.
> 
> What makes you say it isn't recognized or doesn't work?

ifconfig iwn0  says "interface iwn0 does not exist".  Also starting 
wpa_supplicant doesn't work (I use a wpa setup that did work on my previous 
laptop on FreeBSD 10).

At install time I only "configured" ethernet, iwn0 I skipped since I intented 
to configure that later.  But that may not be relevant.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Aw: Re: WLAN hardware not recognized

[Carsten Kunze]

Adrian Chadd  wrote:

> sysctl net.wlan.devices
> 
> iwn0 no longer shows up in ifconfig -a .
> 
> 
> -a

Ok, "sysctl -a|grep iwn" gives quite some output.

Actually I tried to start wpa_supplicant, but WLAN didn't react.  Then--just 
for testing--I wrote "ifconfig iwn0 up", where ifconfig reported that iwn0 is 
unknown.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WLAN hardware not recognized

[Carsten Kunze]

Conrad Meyer  wrote:

> kldload iwn6000fw, iwn6000g2afw, iwn6000g2bfw.

This or edit loader.conf doesn't help, all these things had already been in the 
kernel.  dmesg stays the same.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WLAN hardware not recognized

[Carsten Kunze]

Larry Rosenman  wrote:

> Did you load the iwn firmware?

How do I do this?

I put "if_iwn_load="YES"" into /boot/loader.conf, now I get
"module iwn already present!" in dmesg...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Aw: Re: WLAN hardware not recognized

[Carsten Kunze]

Joe Nosay  wrote:

> Is the card removable? If so, have you tried plugging in one that would
> have the driver already included with the base - so to speak - system? Have
> you tried the card in another computer/laptop?

It is an integrated card.  Theoretical it is removeable, but this is by design 
intented only for repairing reasons.  I have never tried another card in this 
laptop.

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

WLAN hardware not recognized

[Carsten Kunze]

Hello,

the WLAN hardware of my Dell E6540 (intel 633ANHMW) is not recognized (or at 
least does not work).
The only message found in dmesg is:

[1] iwn0:  mem 0xf7b0-0xf7b01fff irq 18 at 
device 0.0 on pci3

Full dmesg is:

Copyright (c) 2013-2016 The HardenedBSD Project.
[1] Copyright (c) 1992-2016 The FreeBSD Project.
[1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
[1] The Regents of the University of California. All rights reserved.
[1] FreeBSD is a registered trademark of The FreeBSD Foundation.
[1] FreeBSD 11.0-CURRENT-HBSD #18 7affcca(HEAD): Fri Feb 19 03:41:41 EST 2016
[1] 
jenk...@nyi-01.build.hardenedbsd.org:/usr/obj/jenkins/workspace/HardenedBSD-CURRENT-i915kms-amd64/sys/HARDENEDBSD
 amd64
[1] FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
[1] WARNING: WITNESS option enabled, expect reduced performance.
[1] VT(vga): resolution 640x480
[1] HBSD: initialize and check HardenedBSD features (version 41).
[1] [HBSD LOG] logging to system: enabled
[1] [HBSD LOG] logging to user: disabled
[1] [HBSD ASLR] status: opt-out
[1] [HBSD ASLR] mmap: 30 bit
[1] [HBSD ASLR] exec base: 30 bit
[1] [HBSD ASLR] stack: 42 bit
[1] [HBSD ASLR] vdso: 28 bit
[1] [HBSD ASLR] map32bit: 18 bit
[1] [HBSD ASLR] disallow MAP_32BIT mode mmap: opt-out
[1] [HBSD PAGEEXEC] status: opt-out
[1] [HBSD MPROTECT] status: opt-out
[1] [HBSD HARDENING] procfs hardening: enabled
[1] [HBSD HARDENING] randomize pids: enabled
[1] [HBSD HARDENING] unset insecure init variables: enabled
[1] [HBSD SEGVGUARD] status: opt-in
[1] [HBSD SEGVGUARD] expiry: 120 sec
[1] [HBSD SEGVGUARD] suspension: 600 sec
[1] [HBSD SEGVGUARD] maxcrahes: 5
[1] CPU: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz (2594.05-MHz K8-class CPU)
[1]   Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c  Stepping=3
[1]   
Features=0xbfebfbff
[1]   
Features2=0x7ffafbff
[1]   AMD Features=0x2c100800
[1]   AMD Features2=0x21
[1]   Structured Extended 
Features=0x27ab
[1]   XSAVE Features=0x1
[1]   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
[1]   TSC: P-state invariant, performance statistics
[1] real memory  = 8589934592 (8192 MB)
[1] avail memory = 8158760960 (7780 MB)
[1] Event timer "LAPIC" quality 600
[1] ACPI APIC Table: 
[1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
[1] FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads
[1]  cpu0 (BSP): APIC ID:  0
[1]  cpu1 (AP): APIC ID:  1
[1]  cpu2 (AP): APIC ID:  2
[1]  cpu3 (AP): APIC ID:  3
[1] random: unblocking device.
[1] ioapic0  irqs 0-23 on motherboard
[1] random: entropy device external interface
[1] kbd1 at kbdmux0
[1] netmap: loaded module
[1] module_register_init: MOD_LOAD (vesa, 0x80eea620, 0) error 19
[1] random: registering fast source Intel Secure Key RNG
[1] random: fast provider: "Intel Secure Key RNG"
[1] vtvga0:  on motherboard
[1] cryptosoft0:  on motherboard
[1] aesni0:  on motherboard
[1] acpi0:  on motherboard
[1] acpi0: Power Button (fixed)
[1] cpu0:  on acpi0
[1] cpu1:  on acpi0
[1] cpu2:  on acpi0
[1] cpu3:  on acpi0
[1] hpet0:  iomem 0xfed0-0xfed003ff on acpi0
[1] Timecounter "HPET" frequency 14318180 Hz quality 950
[1] Event timer "HPET" frequency 14318180 Hz quality 550
[1] Event timer "HPET1" frequency 14318180 Hz quality 440
[1] Event timer "HPET2" frequency 14318180 Hz quality 440
[1] Event timer "HPET3" frequency 14318180 Hz quality 440
[1] Event timer "HPET4" frequency 14318180 Hz quality 440
[1] atrtc0:  port 0x70-0x77 irq 8 on acpi0
[1] atrtc0: Warning: Couldn't map I/O.
[1] Event timer "RTC" frequency 32768 Hz quality 0
[1] attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
[1] Timecounter "i8254" frequency 1193182 Hz quality 0
[1] Event timer "i8254" frequency 1193182 Hz quality 100
[1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
[1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
[1] acpi_ec0:  port 0x930,0x934 on acpi0
[1] pcib0:  port 0xcf8-0xcff on acpi0
[1] pci0:  on pcib0
[1] pcib1:  irq 16 at device 1.0 on pci0
[1] pci1:  on pcib1
[1] vgapci0:  port 0xe000-0xe0ff mem 
0xe000-0xefff,0xf7c0-0xf7c3 irq 16 at device 0.0 on pci1
[1] vgapci1:  port 0xf000-0xf03f mem 
0xf580-0xf5bf,0xd000-0xdfff irq 16 at device 2.0 on pci0
[1] agp0:  on vgapci1
[1] agp0: aperture size is 256M, detected 32764k stolen memory
[1] vgapci1: Boot video device
[1] hdac0:  mem 0xf7d24000-0xf7d27fff irq 16 at 
device 3.0 on pci0
[1] pci0:  at device 22.0 (no driver attached)
[1] uart2:  port 0xf0e0-0xf0e7 mem 
0xf7d2e000-0xf7d2efff irq 19 at device 22.3 on pci0
[1] em0: 

Aw: Re: Haswell graphics (i915) still not in CURRENT

[Carsten Kunze]

Shawn Webb  wrote:

> We at HardenedBSD have an experimental branch that is kept up-to-date
> with FreeBSD HEAD along with Jean-Sebastien's excellent work (and
> HardenedBSD's awesomeness on top of that).
> 
> The code is here:
> 
> https://github.com/HardenedBSD/hardenedBSD-playground/tree/hardened/experime
> ntal/master-i915
> 
> Latest builds are here:
> 
> http://jenkins.hardenedbsd.org/builds/HardenedBSD-CURRENT-i915kms-amd64-LATE
> ST/ISO-IMAGES/

Thank you for that suggestion, this works well!

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

Haswell graphics (i915) still not in CURRENT

[Carsten Kunze]

Hello,

Haswell graphics (i915) still seems not to be in CURRENT.  There is a suggested 
test procedure on

https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8

but currently I'm to busy with other projects to test this.

At the moment CURRENT can't be used on laptops with i915 graphics, so it may 
not harm to integrate a buggy i915 support in CURRENT.  The advantage would be 
that more users would test the driver and could give response.  This may speed 
up the debugging/testing of this driver.

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

Re: No X on Dell E6540

[Carsten Kunze]

Warren Block  wrote:
> The vesa driver can be run on most systems where the newer graphics are 
> not directly supported.  See the last example here:
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html#x-c
> onfig-video-cards-file

My experience from qemu is that vesa doesn't support resolution 1920x1080.  In 
this case I couldn't use it.  I'll test it.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Aw: Re: make .SUFFIXES bug?

[Carsten Kunze]

Thomas Dickey <dic...@his.com> wrote:
> On Tue, Dec 15, 2015 at 04:01:41PM +0100, Carsten Kunze wrote:
> > current groff doesn't build on FreeBSD.  I had noticed the same issue some
> > months ago on NetBSD and cross checked on FreeBSD and it had worked on
> > FreeBSD.  There must have somethig changed since then.  How to reproduce:
> > 
> > When there is a file "test.1.man" and a makefile:
> > 
> > .SUFFIXES:
> > .SUFFIXES: .roff .in .ps .mom .pdf .me .ms .ps .html .txt .texi .dvi .pdf
> > .xhtml .man .c .cpp .log .o .obj .sed .sin .test .test$(EXEEXT) .trs .ypp
 
> According to POSIX
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
> 
> .SUFFIXES
> Prerequisites of .SUFFIXES shall be appended to the list of known
> suffixes
> and are used in conjunction with the inference rules (see Inference
> Rules). 
> If .SUFFIXES does not have any prerequisites, the list of known
> suffixes
> shall be cleared.
> 
> and goes on to list the expected suffixes:
> 
> .SUFFIXES: .o .c .y .l .a .sh .f .c? .y? .l? .sh? .f?

Why is this relevant?  The first "empty" .SUFFIXES line in the example
above clears all default (or previously set) suffixes and the second one
sets the project relevant suffixes.  So I can assume that for the following
suffix rules *these* specified suffixes are used.

> > .man:
> > @echo Making $@ from $<
> > rm -f $@
> > @LC_ALL=C \
> >  sed -e "s|foo|bar|g" \
> >  $< >$@
> > 
> > "make test.1" results in "make: don't know how to make test.1. Stop".
> > 
> > When ".man" is put to the start of the list it works.  It also works when
> > the first .SUFFIXES line is removed.
> > 
> > The answer from NetBSD is that this is very likely a bug in make.  May
> > this
> > also be the case for FreeBSD?
 
> That's ironic, considering that a while back they were adamant that if
> the suffix wasn't in the list cited in POSIX, then it was a bug in the
> makefile.

I agree, but ".man" is in the list.
 
> Your example does not list a suffix for ".1".  It would be harmless to
> update groff's makefile to provide that, and a corresponding suffix-rule.

Please don't consider .1 as a suffix here.  The task is to make "test.1", it
could also be named test_1 or whatever.  So according to the known
suffixes make looks for a file "test.1" until it finds "test.1.man".
So the ".man:" rule generates a  from a .man, in this case
test.1 from test.1.man.  So I do not really see a bug in the makefile.

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

Aw: Re: make .SUFFIXES bug?

[Carsten Kunze]

Hello Simon, 

> > .SUFFIXES:
> > .SUFFIXES: .roff .in .ps .mom .pdf .me .ms .ps .html .txt .texi .dvi .pdf
> .xhtml .man .c .cpp .log .o .obj .sed .sin .test .test$(EXEEXT) .trs .ypp
> 
> What is the value of EXEEXT at this point?

You are right, the example is not as small as it could be for reproducing the 
issue.
These lines are just extracted from groff's makefile.  The issue does still 
occur
if .test$(EXEEXT) is removed.

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

Do keymaps need to be in /usr/...?

[Carsten Kunze]

Hello,

disk decryption works for me when I put

kbdcontrol -l /usr/share/syscons/keymaps/german.iso.kbd

into /etc/rc.d/geli.

But do the keymaps need to be in a file system which may be mounted delayed?  
If there is an error at boot time and something needs to be input to the 
console the keyboard can be considered as unusable until the correct keymap has 
been set.

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

keymap set after file system decryption

[Carsten Kunze]

Hello,

according to the boot messages the keymap is set after decryption of file 
systems.  I consider this as a bug.  The geli decryption script asks for the 
passphrase which can't of course be input if the kaymap is not set.

Handbook §17.12 does not mention the keymap setup.  What can I do to make this 
work?  (Of course I can call e.g. kbdmap in /etc/rc.d/geli, but this is kind of 
tinkering.)

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

Aw: Re: keymap set after file system decryption

[Carsten Kunze]

Trond Endrestøl  wrote:

> I guess we who live outside the US should take into account that PCs 
> are initialised by firmware to the US keyboard layout and the 437 code 
> page, courtesy of IBM, 1981.

In 1981 I had accepted this.  Now it's simply a bug and I wonder it has not 
been fixed in 22 years.  I'll file a bug report.

> I'm not sure if the creators of (U)EFI has considered other keyboard 
> layouts and/or code pages at boot time.

I don't care for the BIOS here, the OS has to take care of it.  It may be ok 
that at the boot prompt only US keymap is set.  But when the rc scripts are 
running the keymap must be set correctly (as one of the first actions).

> A bad workaround is to copy the suitable keymap from /usr/share... to 
> /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one 
> or either of /etc/rc.d/geli{,2}, e.g.:
> 
> /etc/kbdcontrol -l /etc/german.iso.kbd
> 
> kbdcontrol is linked only to libc:
> 
> $ ldd `which kbdcontrol`
> /usr/sbin/kbdcontrol:
> libc.so.7 => /lib/libc.so.7 (0x800827000)

In my case it's simpler since I have /usr in /, but as you descripted 
kbdcontrol must be in /sbin and the maps in /etc in the future.

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

Keyboard language not set before decrypting devices?

[Carsten Kunze]

Hello,

I have encrypted /home and want to decrypt it at boot time with 
'geli_devices="da2"' in /etc/rc.conf but the passphrase is not accepted.  Is it 
possible that the keymap is set *after* the decrypting of filesystems?

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

No X on Dell E6540

[Carsten Kunze]

Hello,

X does not start.  For the error message I get (Number of created screens does 
not match number of detected devices) there are many posts on 
https://forums.freebsd.org but this URL seems to not work currently.  Xorg log 
is (for dmesg see below):

[   369.089] 
X.Org X Server 1.17.4
Release Date: 2015-10-28
[   369.089] X Protocol Version 11, Revision 0
[   369.089] Build Operating System: FreeBSD 11.0-CURRENT amd64 
[   369.089] Current Operating System: FreeBSD pcdd146.dmosdesign.com 
11.0-CURRENT FreeBSD 11.0-CURRENT #0 r291495: Mon Nov 30 23:14:34 UTC 2015 
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
[   369.090] Build Date: 12 December 2015  01:25:52PM
[   369.090]  
[   369.090] Current version of pixman: 0.32.8
[   369.090]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   369.090] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   369.091] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 14 17:02:05 
2015
[   369.091] (II) Loader magic: 0x80a070
[   369.091] (II) Module ABI versions:
[   369.091]X.Org ANSI C Emulation: 0.4
[   369.091]X.Org Video Driver: 19.0
[   369.091]X.Org XInput driver : 21.0
[   369.091]X.Org Server Extension : 9.0
[   369.091] (!!) More than one possible primary device found
[   369.091] (--) PCI: (0:0:2:0) 8086:0416:1028:05be rev 6, Mem @ 
0xf580/4194304, 0xd000/268435456, I/O @ 0xf000/64, BIOS @ 
0x/65536
[   369.091] (--) PCI: (0:1:0:0) 1002:6606:1028:05be rev 0, Mem @ 
0xe000/268435456, 0xf7c0/262144, I/O @ 0xe000/256, BIOS @ 
0x/65536
[   369.092] List of video drivers:
[   369.092]nv
[   369.092]mach64
[   369.092]intel
[   369.092]ati
[   369.092]radeon
[   369.092]openchrome
[   369.092]r128
[   369.092]vesa
[   369.092]modesetting
[   369.092] (II) LoadModule: "nv"
[   369.093] (II) Loading /usr/local/lib/xorg/modules/drivers/nv_drv.so
[   369.093] (II) Module nv: vendor="X.Org Foundation"
[   369.093]compiled for 1.17.4, module version = 2.1.20
[   369.093]Module class: X.Org Video Driver
[   369.093]ABI class: X.Org Video Driver, version 19.0
[   369.093] (II) LoadModule: "mach64"
[   369.094] (II) Loading /usr/local/lib/xorg/modules/drivers/mach64_drv.so
[   369.094] (II) Module mach64: vendor="X.Org Foundation"
[   369.094]compiled for 1.17.4, module version = 6.9.5
[   369.094]Module class: X.Org Video Driver
[   369.094]ABI class: X.Org Video Driver, version 19.0
[   369.094] (II) LoadModule: "intel"
[   369.094] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so
[   369.095] (II) Module intel: vendor="X.Org Foundation"
[   369.095]compiled for 1.17.4, module version = 2.21.15
[   369.095]Module class: X.Org Video Driver
[   369.095]ABI class: X.Org Video Driver, version 19.0
[   369.095] (II) LoadModule: "ati"
[   369.096] (II) Loading /usr/local/lib/xorg/modules/drivers/ati_drv.so
[   369.096] (II) Module ati: vendor="X.Org Foundation"
[   369.096]compiled for 1.17.4, module version = 7.5.0
[   369.096]Module class: X.Org Video Driver
[   369.096]ABI class: X.Org Video Driver, version 19.0
[   369.096] (II) LoadModule: "radeon"
[   369.096] (II) Loading /usr/local/lib/xorg/modules/drivers/radeon_drv.so
[   369.097] (II) Module radeon: vendor="X.Org Foundation"
[   369.097]compiled for 1.17.4, module version = 7.5.0
[   369.097]Module class: X.Org Video Driver
[   369.097]ABI class: X.Org Video Driver, version 19.0
[   369.097] (II) LoadModule: "openchrome"
[   369.097] (II) Loading /usr/local/lib/xorg/modules/drivers/openchrome_drv.so
[   369.097] (II) Module openchrome: vendor="http://openchrome.org/;
[   369.098]compiled for 1.17.4, module version = 0.3.3
[   369.098]Module class: X.Org Video Driver
[   369.098]ABI class: X.Org Video Driver, version 19.0
[   369.098] (II) LoadModule: "r128"
[   369.098] (II) Loading /usr/local/lib/xorg/modules/drivers/r128_drv.so
[   369.098] (II) Module r128: vendor="X.Org Foundation"
[   369.098]compiled for 1.17.4, module version = 6.10.0
[   369.098]Module class: X.Org Video Driver
[   369.098]ABI class: X.Org Video Driver, version 19.0
[   369.098] (II) LoadModule: "vesa"
[   369.099] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so
[   369.099] (II) Module vesa: vendor="X.Org Foundation"
[   369.099]compiled for 1.17.4, module version = 2.3.4
[   369.099]Module class: X.Org Video Driver
[   369.099]ABI class: X.Org Video Driver, version 19.0
[   369.099] (II) LoadModule: "modesetting"
[   369.099] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
[   369.099] (II) Module modesetting: vendor="X.Org Foundation"
[   369.099]compiled for 

Aw: Re: No X on Dell E6540

[Carsten Kunze]

Hello Michael,

> It looks like that is a machine with Haswell integrated graphics.
> Haswell graphics has not yet landed in CURRENT but there is a
> development branch availible for testing.
> 
> https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20L
> inux%203.8

there is also an additional AMD graphics card in this laptop (AMD Radeon HD 
8790M).  Is this supported by CURRENT?

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

Aw: Re: No X on Dell E6540

[Carsten Kunze]

Hello David,

> I had a similar issue with my Dell M4800 until I entered BIOS
> configuration (vi F12 key at boot), selected "Video," then disabled
> "Switchable Graphics."

this option is unfortunately not available in "Video" (only display brightness 
can be set there in my BIOS).

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

make .SUFFIXES bug?

[Carsten Kunze]

Hello,

current groff doesn't build on FreeBSD.  I had noticed the same issue some 
months ago on NetBSD and cross checked on FreeBSD and it had worked on FreeBSD. 
 There must have somethig changed since then.  How to reproduce:

When there is a file "test.1.man" and a makefile:

.SUFFIXES:
.SUFFIXES: .roff .in .ps .mom .pdf .me .ms .ps .html .txt .texi .dvi .pdf 
.xhtml .man .c .cpp .log .o .obj .sed .sin .test .test$(EXEEXT) .trs .ypp

.man:
@echo Making $@ from $<
rm -f $@
@LC_ALL=C \
 sed -e "s|foo|bar|g" \
 $< >$@

"make test.1" results in "make: don't know how to make test.1. Stop".

When ".man" is put to the start of the list it works.  It also works when the 
first .SUFFIXES line is removed.

The answer from NetBSD is that this is very likely a bug in make.  May this 
also be the case for FreeBSD?

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

[Solved] Partitioning on a MBR table disk fails

[Carsten Kunze]

Hi Rick,

thank you for your help!  Using gpart in the shell did work well :)

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

Partitioning on a MBR table disk fails (and destroys my data...)

[Carsten Kunze]

Hello,

I had not been succesful in partitioning and MBR disk for FreeBSD.

I have only one free primary partition where I had installed NetBSD and OpenBSD 
alternatively since many years.  The free space on the disk is divided into 
three parts: one for NetBSD, one for OpenBSD and one left for FreeBSD. When I 
did change from one BSD to the other I edited the MBR (start sector, end sector 
and type a6/a9).

Before now installing FreeBSD for the first time (did use qemu in the past) I 
adjusted the sectorss to the FreeBSD range and changed to type a5, then erased 
the first sectors of that partition.

While NetBSD and OpenBSD autoselect their a9/a6 partitions, FreeBSD sees it's 
partition but doesn't allow to add BSD partitions for e.g. / or swap (no space 
left...). So I deleted the prepared partition and added a new one. The size the 
tool told me was too large (sum of free space on the disk) but after it was 
added a different size had been shown--that which I had reserved for FreeBSD 
(so there is a bug in the install tool). After installation I saw that it had 
overwritten the over BSDs data.

1) Why does FreeBSD not simply use the free partitoin that I had prepared for 
it? It had detected that it is erased, why just doesn't it allow to add / and 
swap?

2) Why doesn't FreeBSD doesn't show where (on which sector) it adds a new 
partition? This and the loss of my data is really disappointing.

At the moment installing FreeBSD is impossible at my disk while the over BSDs 
did work out of the box.

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

Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...)

[Carsten Kunze]

Rick Macklem  wrote:

> Did you use "Manual" when it gets to the partitioning screen?
> When I've done this, after selecting "Manual MBR" (or whatever it's called,
> one or two below "Auto"), it should show you the slices
> (what FreeBSD calls the 4 MBR partitions):
> - Then I select the "freebsd" (move around until it is highlighted one)
>   and create partitions within it with "Create" at the bottom of the
> screen.
>   (I always have "fun" with the interface, but repeated attempts with 
>and the arrow keys eventually get me to the right place on the screen;-)

I think I did select "auto" which brings me into the "manual" screen after few
steps. It does show the slices and does even show NTFS and Linux
partitions inside the extended partition (I have 3 primary MBR partitions,
first is freebsd, then two NTFS, then an extendet with further NTFS and
Linux).

The first 10MB of the first slice (freebsd) had been cleared with
"dd if=/dev/zero of=...".  When I put the cursor line on this slice and
select "create" it doesn't allow me to create the freebsd-ufs for "/".

> Good luck with it, rick
> ps: If it doesn't show the slices,I'm guessing the MBR doesn't make sense
> to
> FreeBSD's fdisk. You can go to "" instead of "" and
> then
> try typing "fdisk".

I did try the shell and typed "fdisk" and "disklabel" but this did not work as
known from other BSDs.

The actually issue is that I can't create something in the found freebsd
slice.  In the past I did simply remove this slice and added a new one
(since the free space on the disk had exactly been what I wanted to
use).  But now the seemingly free space is not actually completely free
so I'd like to not delete the slice.  The installer should support using
this slice.

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

Aw: Re: Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...)

[Carsten Kunze]

Rick Macklem  wrote:

> I don`t use it, but gpart is the preferred FreeBSD command. You might try
> that instead.

Does it work with MBR or only GPT? Anyway, I'll try it.

> Well, although installing is always a bit scary, if you don`t touch the
> other
> slices, I`d delete and create the freebsd one. It gets to a certain point
> when
> doing the `Manual MBR` before it asks you if you want to save it on disk.

At least creating by the (curses) GUI installer is not possible. It does create
somewhere instead of asking me and it doesn't even tell me where it
has created it. And there are numeric bugs in the tool. The numbers it
displayed changed without reason and became even negative ...
So the MBR I don't touch with FreeBSD anymore ...
A simple task for the installer developer: Please let me use an existing
empty slice. This is no rocket sience.

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

Partitioning on a MBR table disk fails (and destroys my data...)

[Carsten Kunze]

Hello,

how is it possible to install FreeBSD in an existing empty MBR partition with 
type "freebsd"?  The installer does not allow this (for unknown reason), it 
returns the error "no space left".  What steps would be necessary to add two 
freebsd-ufs and one freebsd-swap into the existing freebsd partition?  In no 
case I want to delete this partition since I do *not* want FreeBSD to edit the 
MBR (to not have data loss again).  There is unfortunately not much information 
in the handbook "2.6.5. Shell Mode Partitioning" (anyway I'd prefer to use the 
curses UI partition editor).

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

Aw: Re: [RFC] Replace gnu groff in base by heirloom doctools

[carsten . kunze]

Steffen Nurpmeso sdao...@yandex.com wrote:

 It seems you haven't checked at all.
 It seems to me that e.g. mdoc(7) of n-t-r seems to require quite
 a bit of work in order to be at all usable.

This is not completely true. It is usable, I did check it with all about 7000 
manpages in the base of OpenBSD. But it does indeed also require further work.

Please note that FreeBSD uses mandoc(1) for formatting manpages. Groff in the 
base (or a replacement) is only a fallback.

 The macros i use for myself don't work with n-t-r, too: once
 i truly looked (a few months ago) i found that i would have to
 rewrite all traps and other positioning in order to get that
 right.

Please make a bug report ;)

 Despite that you seem to do what you want to do anyway, n-t-r is
 possibly a usable troff, if you go its way and deal with it you
 may be able to gain a bit nicer output _faster_ and without
 converting your beloved special fonts first, but in no way is
 n-t-r a _replacement_ for groff.

The groff version in the base is quite old and is there to have a *roff 
toolchain in the base and as a fallback solution for mandoc(1).  If one does 
serious typesetting (and wants to use groff) it is recommended to use the 
up-to-date version from ports.

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