Re: intel graphics regression? between r332432 and r333982
On 06.06.2018 00:04, Anton Shterenlikht wrote: > I built graphics/drm-next-kmod > and added kld_list="/boot/modules/i915kms.ko" > to /etc/rc.conf. > > However, on boot I see: > > KLD drm.ko: depends on kernel - not available or version mismatch > linker_load_file: /boot/modules/drm.ko - unsupported file type > KLD i915kms.ko: depends on drmn - not available or version mismatch > linker_load_file: /boot/modules/i915kms.ko - unsupported file type Hi! You need to make sure that the base sources you use to build graphics/drm-next-kmod match the kernel you are running. And currently, this is not the case according to the error. > I can still load these modules manually: > > root@z:~ # kldload drm > root@z:~ # kldload i915kms When you only specify the module name, as opposed the the absolute path like in /etc/rc.conf, you load the module compiled with the kernel (e.g. /boot/kernel/i915kms.ko), which is different from the one installed by drm-next-kmod. And the one built with the kernel doesn't support your GPU. -- Jean-Sébastien Pédron The FreeBSD Project signature.asc Description: OpenPGP digital signature
Re: Something between r333623 - r333670 locks up at start of boot
On 16.05.2018 14:42, David Wolfskill wrote: > After updating sources to r333670, build was OK; smoke-test came to a > screeching halt at: > > Booting... > / > > (...) > > One possibly-salient item: while the build machine uses the default > vt(4), I had switched the laptop to 'kern.vty="sc"' via /boot/loader.conf > no later than 23 August 2017 (mtime of the file) I broke syscons(4) yesterday and bde@ provided a patch which cem@ committed in r333683 [1]. It should work again for you now. Sorry for the breakage. [1] https://svnweb.freebsd.org/changeset/base/333683 -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: firefox/ rust failed to install on FreeBSD 12-CURRENT
On 03.06.2017 08:26, Tim Kientzle wrote: > You could add --format=ustar to the existing command line; that > would force bsdtar to use the older "ustar" format (without any > extensions that might confuse Python's tar file module). Even better! Thank you :) >> This will use GNU tar instead of BSD tar to recreate the bootstrap and >> GNU tar doesn't seem to produce sparse file entries in the archive. > > How ironic; using GNU tar in order to avoid having GNU sparse file entries. > ;-) Yes :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: firefox/ rust failed to install on FreeBSD 12-CURRENT
On 28.05.2017 19:21, blubee blubeeme wrote:
> ===> Building for rust-1.17.0
> ...
> extracting
> rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0/librustc_llvm-74a1be1110b5d4d0.so
> gmake[7]: Leaving directory '/usr/ports/lang/rust/work/rustc-1.17.0-src'
> *** Error code 1
Hi!
This failure is caused by Python 2's tarfile module not supporting
sparse files in archives. Python 3 supports them but the configure
script insists on using Python 2.
Before a proper fix is committed, you can change the following line in
lang/rust/Makefile:
https://github.com/freebsd/freebsd-ports/blob/master/lang/rust/Makefile#L159
to say (this is a single line):
gtar -c -C ${WRKSRC} -f -
rust-std-1.16.0-${RUST_ARCH_${ARCH}}-unknown-freebsd | gzip >
${WRKSRC}/rustc.tbz
Then, change the following line:
https://github.com/freebsd/freebsd-ports/blob/master/lang/rust/Makefile#L34
to say:
BUILD_DEPENDS= cmake:devel/cmake \
gtar:archivers/gtar
This will use GNU tar instead of BSD tar to recreate the bootstrap and
GNU tar doesn't seem to produce sparse file entries in the archive.
--
Jean-Sébastien Pédron
signature.asc
Description: OpenPGP digital signature
Re: Some locale data are broken
On 18.11.2016 15:32, Eric van Gyzen wrote: > Oh! I had thought France used '.' as a thousands separator. Thanks > for correcting me, Jean-Sébastien. FTR, while I was looking for a confirmation I was correct, I found another rule I never heard about: a space (a narrow non-breaking spaceto be exact) is used to separate thousands, but only when the number is a quantity (like "12 345 croissants"). But when the number represents an index, there should be no separator (like "croissant n°12345"). Languages are full of curious details :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Some locale data are broken
On 18.11.2016 10:03, Hajimu UMEMOTO wrote: > How about this patch? It fixes the issue, thank you! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Some locale data are broken
On 17.11.2016 23:33, Eric van Gyzen wrote: > $ LANG=fr_FR.UTF-8 locale -k thousands_sep > thousands_sep=" " > > lrwxr-xr-x 1 root wheel 25 Nov 2 13:41 > /usr/share/locale/fr_FR.UTF-8/LC_NUMERIC -> ../uk_UA.UTF-8/LC_NUMERIC > > $ cat /usr/share/locale/uk_UA.UTF-8/LC_NUMERIC > , > > 3 > > I'm not sure what Ukraine uses for a thousands separator, but this is > definitely wrong for France. Hi! What do you find broken exactly? In fr_FR (I don't know for other french-speaking countries), numbers are formatted like this: 12 345,67 Where the English equivalent would be: 12,345.67 Thus, this fr_FR LC_NUMERIC looks correct to me: decimal_point="," thousands_sep=" " grouping=3 What looks incorrect to me is the output of `locale -k` when no keyword is specified: $ LANG=fr_FR.UTF-8 LC_ALL=fr_FR.UTF-8 locale -k ... d_fmt="%m/%d/%y" ... altmon_1="January" ... $ LANG=fr_FR.UTF-8 LC_ALL=fr_FR.UTF-8 locale -k d_fmt d_fmt="%d.%m.%Y" $ LANG=fr_FR.UTF-8 LC_ALL=fr_FR.UTF-8 locale -k altmon_1 altmon_1="janvier" But it's possible this flag isn't meant to work like this, as I just discovered it with your mail :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: SVN r303890 breaks build
On 09/08/2016 23:24, Michael Butler wrote: > The switch to device_t breaks the user-space compilation with .. Ye, I saw that. I'm waiting for buildworld to finish before committing. I'm sorry, I was sure only the kernel used this structure. Thank you for the report! And sorry for the breakage. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: installworld failed by mounting other's /usr/obj
On 27/03/2016 09:07, Jia-Shiun Li wrote: > I have one machine which is faster to build world and export /usr/obj for > others to install. > > As of r297266 installworld would fail. It seems to be caused by r296921 > which would delete libc.ld. In this case libc.ld resides on a read-only > /usr/obj mount. Hi! This was fixed by Bryan Drewery in r297270. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r296548 breaks external DP and HDMI on HD4000
On 14/03/2016 18:59, Ian FREISLICH wrote: > Hi Hi! > With r296548 on the following hardware: > > vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 > > I get the following console messages when X starts and my external > monitor (Samsung U28E590) goes into epileptic fit attack mode. > > [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 > [drm:pid0:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting > [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off > [drm:pid0:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck > [drm:pid1100:ironlake_check_fdi_lanes] *ERROR* WARN ON: > I915_READ(SOUTH_CHICKEN1) & FDI_BC_BIFURCATION_SELECT > [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! > [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! On my Haswell laptop, the external DisplayPort doesn't work either. When using Ultra HD, I get garbage. When using Full HD, the image is correct for a few seconds, then the output connector is disabled (talking about Panel status timeout in dmesg). What resolution do you use with your monitor? If you're using Ultra HD, could you please try Full HD? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Crash with ZFS between r296491 and r296548
On 09/03/2016 12:23, Alexander Motin wrote: > Should be fixed by r296563. > > Illumos assumes full sync between kernel and world, so they are quietly > breaking ABI as often as they want for any new feature. One more set of > compat shim added helps for now. Thank you! I confirm world@296491 + kernel@296564 works fine. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Crash with ZFS between r296491 and r296548
Hi! I use Root on ZFS and my laptop doesn't boot with a kernel from r296548 and world from r296491 (so older than kernel). Ed hits a similar crash. Here are the dmesg and backtrace of zfs(8): https://gist.github.com/dumbbell/c9978ad4ac70214f0f47 With a kernel and world from r296491, everything is ok. I didn't have the time to bisect the bad commit yet, so this is mostly a warning for other. Maybe someone will know what's wrong :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Haswell graphics (i915) still not in CURRENT
On 24/02/2016 10:59, Carsten Kunze wrote: > Hello, Hi! > 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. The problem is not the stability of Haswell support, but more the regressions on already supported GPUs. Currently, there is one big regression: https://github.com/freebsd/freebsd-base-graphics/issues/2 It takes seconds to panic a Sandybridge or Haswell (so I suppose Ivy Bridge is impacted too). Once this is fixed (and so far my attempts failed), I believe the patch can go in -CURRENT. Haswell support won't be rock solid but anyway, Linux 3.8, the base we use, had only initial support. Many bugfixes came in Linux 3.9 and 3.10. Hopefully, we'll get there more quickly. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Thinkpad T410: resume broken
On 18/02/2016 16:47, Alexey Dokuchaev wrote: > On a related note, how does one configure sc(4) with old drm (vs. > drm2) shall I need to try that? Hi! xf86-video-intel and xf86-video-ati do not handle modesetting for a long time now (almost three years), so they can't be used with the old "drm" (only "drm2"). We don't have xf86-video-nouveau for the same reason. You can't use older versions of those xf86-video-* (ie. those doing user modesetting) because they are not supported anymore by the X.Org server. That was the whole WITH_NEW_XORG drama. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Unstable kernel (dumbbell) crashes
Le 20/12/2015 19:04, Beeblebrox a écrit : > Hello. Hi! > I have been away from my FreeBSD system for over 7 months. The first > on my return was to update world/kernel then do a full poudriere run > for all my packages. The process had many problems; I'm reporting > items below as FYI. I'm tracking > https://github.com/dumbbell/freebsd.git for my Radeon card. You should follow the official Git mirror instead of my own fork. I only update it every so often, therefore it's lagging behind the real HEAD. -- Jean-Sébastien Pédron ___ 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: EFI and i915kms questions
On 02/12/2015 02:00, John Baldwin wrote:
> Note that at the top of the function it invokes IICBUS_TRANSFER on a different
> device when force_bit_dev is true:
>
> 370 sx_xlock(&dev_priv->gmbus_sx);
> 371 if (sc->force_bit_dev) {
> 372 dumbbell282199 error =
> -IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
> 373 kib 235783 goto out;
> 374 }
>
> Hmm, I would try changing the line at 470 to match the line at 372.
>
> They used to match, and then this change:
You're right. This is something I fixed in my i915 update branch but
forgot to commit to HEAD...
Joe, could you please try what John suggests to confirm?
--
Jean-Sébastien Pédron
signature.asc
Description: OpenPGP digital signature
Re: EFI and i915kms questions
On 13/11/2015 18:15, Joe Maloney wrote: > Hello, Hi! > Sometime after changes in FreeBSD 10-STABLE, 10.2 onwards, and > recent 11 CURRENT the resolution no longer sets properly when using > UEFI boot. It now boots with a 640x480 resolution, and kldload > i915kms results in a black screen. I have not been able to grab a > debug log, or crash dump even with all of the debugging features > turned on. I cannot ssh into the laptop when this panic occurs, and > the screen is black so I can’t really see what happened. I’m curious > if there is anything else I can do besides enabling dumpdev or > kldload -v i915kms > output.txt that doesn’t give me any detail. > Nothing shows up in /var/crash or whatever the directory was. You could try to set debug.debugger_on_panic=0 in /etc/sysctl.conf. It often helps to at least get core dumps when the crash happens in a video driver. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Intel Haswell support - Any updates?
On 18.09.2015 08:30, Shane Ambler wrote: > A little off-topic but has anyone tried to get nvidia to return libcuda > to our drivers? While it was there a few years ago it was removed yet > again. From what I could tell we had to use the linux sdk to compile > cuda kernels which probably hindered freebsd using it so the sdk may > need porting to freebsd as well. During XDC last week, we talked about that with an NVIDIA developer (ie. working for NVIDIA, not on Nouveau). CUDA is a bit complex: it's not only a library but also a toolchain. This is a lot of effort and, as a company, they probably won't port/maintain it except if FreeBSD customers are asking for it. However, this developer will see if libOpenCL.so can be compiled on FreeBSD and shipped with nvidia-driver. It could just be a matter of enabling the build. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Intel Haswell support - Any updates?
On 17.09.2015 21:22, O. Hartmann wrote: >> Why does it take so much time to update? Once Konstantin committed his >> i915 update, I was busy with non-FreeBSD activities until last July, >> when I slowly started back to work on i915. My goal is to reduce the >> diff with Linux as much as possible. But, as opposed to OpenBSD and >> DragonFlyBSD, we do not use a Linux compatibility layer which would >> dramatically ease our life. > > My concerns are speed and performance. Isn't any kind of layer consuming > performance - > sometimes worse, sometimes negligible. But anyway, HPC isn't a FreeBSD > domain, so ... Like Nikola said, the layer shouldn't have any performance impact. Most of the functions are either macros wrapping the FreeBSD native functions or new implementations (for instance, linux/idr.h). > The spoken of facilities are "generic" or are they Linux-unique and have to > be adopted > for FreeBSD? Those facilities are generic tools. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Intel Haswell support - Any updates?
On 17.09.2015 19:21, Shawn Webb wrote: > I know there's a difference between "builds fine" and "runs fine". With > it building fine, is the driver at the point where we can start > rudimentary testing? I can't help out in the development efforts, but > I'd love to help test and give bug reports. This is one way the > community at large can help. Even if it means stuffing your Inbox with > bug spam. ;) There is no need to try it right now. I didn't even try it on my own i915 hardware (it's at home). When an X server runs, I will let you know. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Intel Haswell support - Any updates?
On 17.09.2015 20:44, Nikola Pajkovsky wrote: > Is it part of your huge patch or where can I found commits related to > linux compat layer? The Linux compat layer and the i915 update are separate projects. The layer is here: https://github.com/dumbbell/freebsd/tree/linux-api-shim -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Intel Haswell support - Any updates?
Hi everyone! I'm very sorry I didn't communicate at all on the i915 update project. So here is a status update: since this morning, the driver builds fine. I'm currently attending the XDC (X.Org Developers Conference) and don't have an Intel laptop to test with me. However, Johannes Dieterich (also attending the conference) offerred his help, so we will do that today. Obviously, do not expect something stable in the coming couple days. Thank you for your patience :) To answer various questions in this thread: Why does it take so much time to update? Once Konstantin committed his i915 update, I was busy with non-FreeBSD activities until last July, when I slowly started back to work on i915. My goal is to reduce the diff with Linux as much as possible. But, as opposed to OpenBSD and DragonFlyBSD, we do not use a Linux compatibility layer which would dramatically ease our life. This layer exists for the OFED/Infiniband drivers: we are almost ready to move it to a central place, so we can use it in the near future in the DRM subsystem. Another problem I will fix in the near future is the method I used: I worked on a giant patch instead of doing several incremental commits. This is unfriendly for external contributors and hard to review. DragonFly got that right for instance. Now about other related tasks: o A Mesa update will be committed Real Soon Now™. It will unlock GLAMOR and OpenCL support. o Once Mesa is updated, we can update xserver to 1.17.2. xserver 1.18 RC 1 works fine (at least for me :). It should be released for Halloween. o Wayland. The problem is NOT the output side of the graphics stack: it is the input part. We miss evdev (ported as a GSoC, waiting for review and commit), we miss udev, we miss libinput. This item deserves a dedicated email. Sorry, it's a bit short for such a large topic. It's difficult to expand more during a conference :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: panic: Stray timeout
On 03.09.2015 20:24, Andriy Gapon wrote: > On 30/08/2015 22:05, Andriy Gapon wrote: >> On 30/08/2015 21:37, Oliver Pinter wrote: >>> You have a running Xorg with radeonkms driver, and this issue >>> occurrence under high load (for example parallel buildworld)? >> >> I use radonkms indeed and judging from ta_func = ttm_bo_delayed_workqueue it >> was >> involved. But there was no steady system load before the crash, perhaps >> there >> was a spike though. >> > > BTW: https://svnweb.freebsd.org/changeset/base/287354 Hi! I saw that and built a new kernel earlier today. I will keep you posted if something happens or not. Thank you :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: panic: Stray timeout
On 31.08.2015 12:58, Oliver Pinter wrote: > I got this panic, and I have somewhere a kernel and a coredump on my > other machine. I got this panic only when I put my machine under heavy > load and use X with randonkms driver. > When I didn't use X and start the build under vt, I newer got this panic. The function called by this taskqueue cleans up graphical buffer objects. vt(4) relies on a single buffer object which doesn't change for its entire life, that's why this TTM task is unused with vt(4). However, buffer objects are heavily used by the X server and Mesa. The task is executed several times a second on my laptop. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: panic: Stray timeout
On 30.08.2015 21:05, Andriy Gapon wrote: > On 30/08/2015 21:37, Oliver Pinter wrote: >> You have a running Xorg with radeonkms driver, and this issue >> occurrence under high load (for example parallel buildworld)? > > I use radonkms indeed and judging from ta_func = ttm_bo_delayed_workqueue it > was > involved. But there was no steady system load before the crash, perhaps there > was a spike though. I get this panic several times a week since around February this year. It appeared without any commit to TTM or the Radeon driver. It happens no matter the load for me. So far, I never found the cause, even though I spent a lot of time reading TTM, subr_taskqueue.c and kern_timeout.c. So, this is a simple "me too" :-/ -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
[Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
Hi!
Here is a new patch to based on HEAD r279508:
https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch
You can apply it to a Subversion checkout using the following command:
svn patch drm-update-38.i.patch
There are few changes:
o The panic reported by J.R. Oldroyd is fixed, but not the CP init
problem.
o A lock assert was added, suggested by Konstantin Belousov
I had several panics ("Stray timeout") with a taskqueue used by TTM, but
it didn't occur in the past 6 days. Maybe it was a problem outside of DRM.
I would like people to test again and report :) If something fails,
please post a full dmesg, taken after loading the relevant *kms module,
or the core.txt.$N file if it's a panic.
Hans Petter and Ed, I couldn't reproduce neither of your problems (HDMI
hotplug events storm and VT-switch misbehaviour). However, they both
involve callouts, like the "Stray timeout" panic I had with TTM. I
suspect there was a transient problem with callouts in HEAD at the same
time. Could you please test again with this patch and a very recent HEAD?
Thank you to everyone!
--
Jean-Sébastien Pédron
signature.asc
Description: OpenPGP digital signature
Re: system failure: cannot kill webkit-gtk3 if using dumbell/radeon
Hi! Sorry for the delay to get back to you (including your private emails). I'll answer to all at once here, I hope you don't mind :) I'm not sure the issues you have with the 'h' letter in Midori, the flickering you see with some applications/desktop environments or the slim/GDM failure are related to this DRM update or the kernel video drivers in general. I CC'd Koop Mast, in case he can help debug GDM. You mentionned "ghost text" with nano in vt(4). Could you please file a bug in Bugzilla with a picture of what you get? Please join a dmesg too. However, the unkillable processes are interesting. If you can reproduce this, could you please post the output of "procstat -kk -a" when this happens? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
[Call for testers] DRM device-independent code update to Linux 3.8
Hi! An update to the DRM subsystem, not including the drivers, is ready for wider testing! The patch against HEAD is here: https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch I'm interested in success/failure reports for amd64, powerpc and powerpc64 users, for i915 and Radeon GPUs. I already know there is a build issue on i386, please wait for the next patch if you are in this case. The changes brought by this patch are explained in a blog post: http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/ This is working well for some Radeon users for more than a year. However, it only started to work with i915 a month ago, when the i915 refresh was committed. Try your day-to-day applications, try suspend/resume, try all output connectors, try OpenGL stuff, try backlight controls, everything :) Thank you! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: unbound crashes on bootup
On 06.02.2015 14:06, Poul-Henning Kamp wrote:
> I just updated my -current to r278283, and unbound (still) croaks
> during bootup:
Hi!
I have a similar problem. Also, unbound crashes each time I start/stop
OpenVPN. I suppose the problem is the same in both cases.
The crash happens in the config_lookup_uid() in
contrib/unbound/util/config_file.c. Here's the code:
struct passwd *pwd;
if((pwd = getpwnam(cfg->username)) == NULL)
log_err("user '%s' does not exist.", cfg->username);
cfg->uid = pwd->pw_uid;
getpwnam(3) returns NULL: an error message is logged but the function
doesn't return. Therefore, the program segfaults on "pwd->pw_uid" on the
next line.
But why did getpwnam(3) return NULL in the first place? It looks for the
"unbound" user which exists. getpwnam() calls _nsdispatch() which fails.
I have the default nsswitch.conf. I didn't look at the problem more
deeply yet, but could getpwnam()/_nsdispatch() be unhappy with the
absence of a working DNS resolver (unbound is being (re)started)?
--
Jean-Sébastien Pédron
signature.asc
Description: OpenPGP digital signature
Re: HEADS UP: Enabling vt(4) by default
Hello! As announced a week ago, vt(4) is now the default console driver in 11-CURRENT as of r274085. You may have to update your console settings in /etc/rc.conf. During boot, /etc/rc.d/syscons will indicate what you need to do. The original HEADS UP mentioned several known issues. Among them, the following were fixed: o A video mode can be selected using the following tunable in /boot/loader.conf: kern.vt.fb.default_mode="1024x768" This only works when using a KMS video driver. It's not supported by the VGA backend. See vt(4) man page for further documentation. o The keyboard was not working when kbdmux(4) was disabled. This is fixed. o After loading a KMS driver, the text cursor was in the middle of the kernel messages. The problem was that the cursor position was not updated after the change in window size. This is fixed. Up-to-date information can be found on the wiki page: https://wiki.freebsd.org/Newcons If you want to keep using syscons(4), you can add the following line to /boot/loader.conf: kern.vty=sc Thank you to everyone who tested and reported problems! Please continue to do so, especially if you find the need to go back to syscons. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: NVidia Tesla K40
On 31.10.2014 17:46, John Dison wrote: > Hello! Hi! > I want to use NVidia Tesla K40 GPU for parallel computing.Does > FreeBSD support such a hardware? As O. Hartmann explained, we don't support GPGPU on NVIDIA hardware, neither with the binary driver because NVIDIA doesn't provide any libOpenCL.so for FreeBSD, nor with the FOSS driver because we don't have the kernel video driver. On the AMD front, GPGPU works with the open-source stack (libclc and Clover, Mesa's libOpenCL.so), but the Clover port isn't committed yet. We didn't have the time to polish it so far (only libclc is available in devel/libclc). Note that Clover is still a WIP. Here's a matrix of implemented and missing features: http://dri.freedesktop.org/wiki/GalliumCompute/ When I tried it with simple programs found on the Net, it worked. However, I couldn't use it with graphics/darktable: 1) Currently, the amount of memory reported by Clover is hard-coded 2) darktable expects features not implemented -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: VT: NOT giving extended console
On 31.10.2014 20:25, Larry Rosenman wrote: >>> kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block >>> 0 invalid. >>> kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a >>> monitor but no|invalid EDID >> >> Yeah, the driver reprobe any output connectors every 10" by default. >> >> I think there's a setting to tune how/when connectors are probed but we >> don't expose it currently. Feel free to comment those messages, they >> are in: >> o sys/dev/drm2/drm_edid.c >> o sys/dev/drm2/radeon/radeon_connectors.c > > I think we had this before, and someone(I forget who) shut it up.. > > I really think it's the PROJECTS responsibility to shut this up, as I'm > sure I > won't be the only one whining... Yes, I fixed the previous invalid EDID spam. In general, I prefer to keep the diff with Linux to a minimum, but here, lacking a better solution, I just changed those two messages from DRM_ERROR to DRM_DEBUG (r273962). -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
r273910 build failure if is out-of-date
Hi! I have the following error when building HEAD: ---8<--- cc -O2 -pipe -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/include -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../include -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/sparc64 -DNLS -fexceptions -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib/gdtoa -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../libmd -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../contrib/tzcode/stdtime -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/stdtime -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/locale -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c cancelpoints_sem_new.c -o cancelpoints_sem_new.o In file included from cancelpoints_sem_new.c:47: /mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/../../include/semaphore.h:41: error: field '_kern' has incomplete type cancelpoints_sem_new.c:66: error: 'USEM_MAX_COUNT' undeclared here (not in a function) cc1: warnings being treated as errors cancelpoints_sem_new.c: In function '_sem_getvalue': cancelpoints_sem_new.c:335: warning: implicit declaration of function 'USEM_COUNT' cancelpoints_sem_new.c: In function 'usem_wake': cancelpoints_sem_new.c:342: error: 'UMTX_OP_SEM2_WAKE' undeclared (first use in this function) cancelpoints_sem_new.c:342: error: (Each undeclared identifier is reported only once cancelpoints_sem_new.c:342: error: for each function it appears in.) cancelpoints_sem_new.c: In function 'usem_wait': cancelpoints_sem_new.c:361: error: 'UMTX_OP_SEM2_WAIT' undeclared (first use in this function) cancelpoints_sem_new.c: In function '_sem_post': cancelpoints_sem_new.c:445: error: 'USEM_HAS_WAITERS' undeclared (first use in this function) *** Error code 1 Stop. make[4]: stopped in /mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc *** Error code 1 ---8<--- The problem is that the installed version of is out-of-date compared to the version in the source tree. I guess it's supposed to pick the version in the source tree, but I'm not sure what's the correct way of doing this. FYI, this is with base gcc on sparc64. World was updated on August 6. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: VT: NOT giving extended console
On 31.10.2014 12:59, Larry Rosenman wrote: > Thanks, now I get a constant stream of: > > kernel: error: [drm:pid0:drm_do_get_edid] *ERROR* DVI-I-1: EDID block 0 > invalid. > kernel: error: [drm:pid0:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor > but no|invalid EDID Yeah, the driver reprobe any output connectors every 10" by default. I think there's a setting to tune how/when connectors are probed but we don't expose it currently. Feel free to comment those messages, they are in: o sys/dev/drm2/drm_edid.c o sys/dev/drm2/radeon/radeon_connectors.c -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: VT: NOT giving extended console
On 31.10.2014 11:46, Tijl Coosemans wrote: >> Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build of >> the drm2 module. >> >> I'll connect it as soon as svn up is finished, except if Tijl beats me >> to it :) > > Done in r273902. Thanks :) And thank you very much for adding AGP support! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: VT: NOT giving extended console
On 31.10.2014 04:16, Larry Rosenman wrote: > 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 #4 r273876: Thu Oct 30 21:44:26 CDT 2014 > r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > VT: running with driver "vga". > link_elf_obj: symbol ttm_agp_tt_create undefined > KLD file radeonkms.ko - could not finalize loading Hmm, sys/dev/drm2/ttm/ttm_agp_backend.c isn't connected to the build of the drm2 module. I'll connect it as soon as svn up is finished, except if Tijl beats me to it :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
HEADS UP: Enabling vt(4) by default
Hello! vt(4) is fairly usable today and we would like to enable it by default in one week (Monday November 3, 2014). For those who never used vt(4), here are its benefits: o It supports Unicode and double-width characters. o It supports the kernel video drivers (KMS) and allows to switch to and from an X session. o It supports UEFI. Of course, there are still issues. A list is available on the wiki: https://wiki.freebsd.org/Newcons#Known_Issues And in Bugzilla: https://bugs.freebsd.org/bugzilla/buglist.cgi?resolution=---&keywords=vt Here's a summary of the major problems: o The keymap selection in bsdconfig(8), used by the installer, has not been updated to use the vt keymap list instead of the syscons one. o Only UTF-8 character maps. o The console resolution is currently fixed to the value chosen by the underlying graphics driver. o No support for several vidcontrol(1) features. o Graphics features such as mouse pointers and font setting work only in VGA graphics mode, not in VGA text mode. The goal is to fix remaining bugs in time before FreeBSD 11.0 release cycle. If you want to switch back to syscons, you may use the following line in /boot/loader.conf: kern.vty=sc And please tell us why! :) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: vt_suspend / vt_resume
On 09.10.2014 17:09, Andriy Gapon wrote: > I looked at the vt code and I was not able to figure out what would be the > proper place there. > Initially I thought that vt_allocate() would be it, but then it seems that > vt_allocate() might not be called. So, perhaps vtterm_cnprobe() ? Something > else? What about vt_upgrade()? It's called later in the boot process: /* Delay until all devices attached, to not waste time. */ SYSINIT(vt_early_cons, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_ANY, vt_upgrade, &vt_consdev); However, it's called from vt_allocate() too, so you would need a flag in struct vd_device->vd_flags to record the fact the handlers are registered. The core handlers would then call backend-specific handlers, if the backend provides them. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: UEFI boot failure: BIOS smap did not include a basemem segment!
On 11.09.2014 16:12, Ed Maste wrote: > The requirement for a usable memory range with physaddr 0 doesn't hold > for UEFI, and the md startup hasn't yet been reworked to accommodate > that. Thank you for the explanation! > Do you mind submitting a PR to keep track of this issue? Here it is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193564 -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
UEFI boot failure: BIOS smap did not include a basemem segment!
Hello! I tried the following FreeBSD snapshot on my Clevo W860CU with UEFI enabled: FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img The boot fails early with the following error: panic: BIOS smap did not include a basemem segment! The full picture of the panic is here: https://people.freebsd.org/~dumbbell/uefi/FreeBSD-Clevo-W860CU-UEFI-no-basemem-segment.jpg Here's a video of a verbose boot (the quality is really low, I can try to redo it if this one doesn't help): http://www.dumbbell.fr/~dumbbell/FreeBSD-Clevo-W860CU-UEFI-no-basemem-segment.mov When I tried UEFI a couple years ago (with Windows 7), it could boot. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: panic m_demote: m_nextpkt not NULL
On 05.09.2014 17:38, Mark Atkinson wrote: > r271093 GENERIC amd64. Received this panic in the tcp reassembly code: Gleb Smirnof fixed this in r271123. I had this same panic yesterday after around 3h of uptime each time, but today, everything's fine. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Recent vt(4) broke moused when hw.vga.textmode=1
On 23.08.2014 08:38, Xin Li wrote: Fatal trap 12: page fault while in kernel mode And the crash is fixed in r270390. Thank you for reporting this! -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CURRENT]: r270386: unusable console (question marks filling scrren) in vt(), crash/freeze
On 23.08.2014 07:16, O. Hartmann wrote: On different platforms with different graphics hardware, recent CURRENT r 270386 shows a screen filled with question marks when booting, The '?' filling screen issue is fixed in HEAD as of r270388. Again, sorry for that. Thank you for reporting the problem! -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CURRENT]: r270386: unusable console (question marks filling scrren) in vt(), crash/freeze
On 23.08.2014 07:16, O. Hartmann wrote: I expect at least the vga textmode console in vt() working. Can the inventor of this mess plaese revert the code to a working version? Hello! I'm responsible for that and currently working on fixing it. Sorry for the breakage :-/ -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Recent vt(4) broke moused when hw.vga.textmode=1
On 23.08.2014 08:38, Xin Li wrote: Hi, Hello! I have seen this panic via serial console, but the console is completely unusable at the time. VGA console is full of '?'. Oh crap, sorry for the breakage... I look into this right now. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r269471 make unusable VT console
On 19.08.2014 18:28, Jean-Sébastien Pédron wrote: Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch This is now in HEAD, as of r270322. Again, this is unfinished work, but it already brings improvements. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r269471 make unusable VT console
On 19.08.2014 21:20, Adrian Chadd wrote: > Hey, this is cool! > > So hm, why are you still doing any reading? Don't you now have all the > information you need to write out the font and cursor information for > each given set of 8 pixels? I read a lot about VGA in the past days but I'm new to this interface, so my reasonning may be wrong. Anyway, here it is: To write a group of 8 pixels with only 2 colors, I write a byte using background color in an offscreen memory, read it back to load it in the latches, put the foreground color in the Set/Reset register, then write the character/cursor to its final location in video memory. Because the background color almost never changes, only one read is made the first time we load the background color, and then only writes. This is fast. If the group of 8 pixels uses 3 or more colors, I can't use Write Mode 3 alone. I see two possibilities: 1. Set Write Mode 0, then for each plane, compute the byte to write (1 bit out of 4 of each pixel's color), activate one plane, write the byte (repeat for each plane), restore Write Mode 3 and the relevant registers. 2. Stay in Write Mode 3, do a read/write for each colors. The first solution has a constant time of execution. The second one depends on the number of colors. In the end, I guess both solutions are expensive, but hopefully are rarely used. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
On 19.08.2014 19:46, Nathan Whitehorn wrote: > On 08/19/14 09:28, Jean-Sébastien Pédron wrote: >> o vt_vga introduces a new callback, vd_bitblt_text_t, which takes >> as argument the text buffer, the dirty area, the font and the >> cursor (position, map, colors). > > Why is this necessary? I'd really prefer to avoid complicating this API. > One of the great things about writing newcons drivers is that there is > basically only one function you need to implement. If the current API > does not provide enough information to do this efficiently, I'd much > rather change it than add new callbacks. I don't want to have two callbacks for the same feature either, and I'd like to transition other drivers to this new one. The current bitbltchr callback only knows about one character. In the case of vt_vga, if this character (or the cursor) isn't aligned on 8-pixels boundaries, it needs to redraw several "blocks" of pixels. With this character-centric approach, if a block needs a redraw, it'll be refreshed for the character on its left side, then refreshed again for the character on its right side. The advantage of giving the callback the whole text/area is that it allows the driver to manipulate the pixels block by block, instead of character by character. The patch isn't finished yet. Meanwhile, I'll commit the bug fixes I made (especially the cursor handling in vt_flush()). But eventually, the plan is to convert all drivers to this new callback, if you find the new API sensible. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
On 19.08.2014 10:42, Jean-Sébastien Pédron wrote: > On 16.08.2014 01:51, Nathan Whitehorn wrote: >> It also has bad effects on boot time. My desktop takes something like 3 >> times as long to boot after r269471. If it can't be fixed quickly, it >> needs to be reverted. > > Just a quick note: I'm working on an update to vt_vga. Hello! Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch What's new/fixed: o vt_vga introduces a new callback, vd_bitblt_text_t, which takes as argument the text buffer, the dirty area, the font and the cursor (position, map, colors). With all this information at hand, it can redraw the dirty area with almost no read from the video memory. This greatly improves the performance. The implementation is quite naive and I put a lot of comments. This could probably be simplfied/improved. The cursor is drawn at the same time than the text: this avoids flickering of the mouse pointer. The patch reads from the video memory only when the byte to write uses more than 2 colors (fg/bg). But this only happens with colored text around the cursor or with fonts who's width isn't a multiple of 8. o In vt_flush(), handle the cursor position before getting the dirty area. This fixes a bug where, if we move the cursor too fast, its new location is outside the marked area and it disappears from the screen. While here, mark the new position of the cursor as dirty, not only the old one. For the cursor to be drawn, VWF_MOUSE_HIDE must not be set *and* VDF_MOUSECURSOR must be set! Before, only the former was checked when deciding if the cursor position should be marked as dirty. Finally, if the cursor didn't move, don't mark its position as dirty. Before, these two problems caused major redraw of a large part of the screen for nothing, due to a mouse pointer location of [0;0] (even if disabled) and its position always marked as dirty. o When the mouse state is changed, mark its position as dirty. o The flush timer is paused during a window switch. In the case of vt_vga, vga_initialize() is called and it messes with VGA registers and the video memory. If vt_flush() is triggered at the same time, unexpected data are displayed. This is fixed, though, there's still a annoying flickering, because the sync signal is temporarily stopped during vga_initialize(). o The patch includes another non-related patch, which tries to stabilize the refresh rate. Currently, we schedule the next redraw in 40 ms (25 Hz), but that doesn't count for the time taken to redraw. o Change how the mouse is enabled/disabled/shown/hidden. Now, the GETLEVEL and GETMODE ioctls don't touch this. Everything goes through the CONS_MOUSECTL ioctl. This fixes vidcontrol -m on|off. Known issues: o Instead of having an "if (bitblt_text != NULL)" check in vt_flush(), I'll add a generic bitblt_text callback which implements the old code, so that other drivers can be changed incrementally. o In vt_vga, the screen flickers during a window switch, because it stops the sync signal and zeroes the memory. It would be nice to avoid that. o Several issues when the font is changed: 1. The offset to center the text area is global, not per window. Therefore other window are not centered anymore. 2. There's a bug with my patch, where other windows have the top-left letter wrongly shifted. 3. When the text area changes (compared to the whole screen), there's garbage in the borders. 4. The text cursor (the square) may be broken on other windows. o The mouse pointer is somtimes not erased during a move. o The text square cursor handling in vt_vga could be improved: colors are just reversed, we shouldn't change the fg/bg colors, just write a 0x00 pattern instead. o The vt_flush() timer could maybe be stopped when there's nothing to draw. No need to wakeup a core for that. Any comments? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r269471 make unusable VT console
On 16.08.2014 01:51, Nathan Whitehorn wrote: > It also has bad effects on boot time. My desktop takes something like 3 > times as long to boot after r269471. If it can't be fixed quickly, it > needs to be reverted. Just a quick note: I'm working on an update to vt_vga. The current patch already fixes the draw speed problem, but I'm not finished yet (the mouse cursor is broken as well as some other small annoyances). -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI
On 20.07.2014 18:19, Anders Bolt-Evensen wrote: > Hello, everyone! Hi! > When I try to use the radeon driver, X exits because of BIOS errors > (since I do not use BIOS when in EFI mode), as can be seen from the > output of "dmesg -a" from a verbose boot (at the time dmesg -a was run, > I had commented out the line with the intel driver to force it to use > the radeon driver instead, since the intel driver caused the screen to > freeze). I can't comment on the Intel driver behavior, but I never tested the Radeon driver with UEFI yet. The BIOS errors you see mean that the driver failed to locate the Video BIOS. There no relation with the System BIOS or, in your case, UEFI. > info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... > info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table > info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND Those calls to get the "VFCT" ACPI table should succeed in an UEFI context. But as I said, this was never tested. > error: [drm:pid1363:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM > drmn0: error: Fatal error during GPU init > info: [drm] radeon: finishing device. > [TTM] Memory type 2 has not been initialized > device_attach: drmn0 attach returned 22 And here, without the Video BIOS, the driver misses too much information and abort the initialization of the card. I currently have no suggestion to make to debug and fix this situation. I need to study a bit what should be going on before. My laptop, which has UEFI available, doesn't boot FreeBSD for now (it fails to probe the system memory). I'll get back to you as soon as I can work on this. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Problems starting X on Mac using vesa, radeon or intel drivers when running FreeBSD-CURRENT in EFI
On 23.07.2014 22:18, Lokadamus wrote: > Am 20.07.2014 18:19, schrieb Anders Bolt-Evensen: >> info: [drm] Initialized i915 1.6.0 20080730 > 1.6.0 20080730 looks old for me. > Have a look at https://wiki.freebsd.org/Graphics section "Installing KMS > Ports" 1.6.0 is the version of the kernel driver, not xf86-video-intel. He is using the latest version available in FreeBSD. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Occasional GPU lockups
On 14.06.2014 12:59, Pawel Pekala wrote: > Hello, Hi! > I get those occasional GPU lockups and just want to know if this is > known problem. When they occur my monitor turn offs for few seconds and then > goes back on again. Did you build graphics/dri with WITH_GALLIUM=yes in your /etc/make.conf? If you don't have WITH_GALLIUM, try to define it and rebuild graphics/dri. If you already have it or if, after adding it, the problem is still there, could you please try with Mesa taken from the experimental branch of the xorg-dev Subversion repository? Here's the address: svn co https://trillian.chruetertee.ch/svn/ports/branches/experimental/ After the checkout, add WITH_NEW_MESA=yes to /etc/make.conf, remove WITH_GALLIUM (this is a standard port option in xorg-dev) and reinstall the following ports from the checkout (in this order): graphics/libdrm graphics/libglapi graphics/libGL graphics/libEGL (if you have it installed) graphics/dri -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: official pkg repo with WITHOUT_X11=true
On 28.05.2014 18:10, Dirk Engling wrote: > set during poudriere builds. Default options for some graphic related > ports like graphics/gd unfortunally litter all my jails with their libX* > dependencies. For those graphics libraries, the dependency to libX11 is only required to support the XPM image format, AFAIK. I believe this format isn't widely used nowadays. Would it make sense to disable this support by default? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Gallium debugging and crash dumps
On 15.05.2014 15:59, Michael Jung wrote: > I've started playing with VT and gallium. I boot on ZFS but have a > UFS drive and swap partition. Anyone with idea's why I'm not getting > any crash info? Were you able to get a kernel core dump? Or is your problem with X.Org gone? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Reboot with newcons (vt/vt_vga) + ATI Radeon HD 4350 on i386
On 01.03.2014 11:09, Alexey Dokuchaev wrote: > Hi there, Hi! > Following my previous more of less successful experience with newcons on > -CURRENT/amd64 and some ATI/AMD card, I've decided to give it a try here > on i386 with somewhat older HD 4350, also from ATI. Unfortunately, this > time newcons'ified GENERIC kernel + startx => reboot (core.txt attached). The list ate your attachment. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: newcons comming
On 10.02.2014 22:07, Alexey Dokuchaev wrote: > Also, even at native resolution, switching consoles takes LCD considerable > time to redraw screen contents. Looks like it's not accelerated at all... I used the following (hackish) patch which fixed the slow redraw problem for me, but I don't know if it still works: http://people.freebsd.org/~dumbbell/radeonkms/wr4-only-no-copy-vt_fb.c.patch I still need to take some time to discuss it with ray@. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Newcons radeonkms - Failed to load firmware "radeonkmsfw_TURKS_PFP"
On 25.01.2014 22:45, Mike C. wrote: > Worked but I'm still stuck in this case at 'vt_allocate: Replace existing VT > driver.' > > a few lines up I see: > No connectors reported connected with modes. Could you please boot without loading the Radeon driver from loader.conf, and run "kldload radeonkms", then post a full dmesg? > should I post to freebsd-...@freebsd.org? Yes, this will be more on topic. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Newcons radeonkms - Failed to load firmware "radeonkmsfw_TURKS_PFP"
On 25.01.2014 18:43, Mike C. wrote: > After rebuilding the kernel with newcons support (which is working) > I've placed radeonkms_load="YES" in boot loader and rebooted and get > this screen. > > what am I doing wrong? Hello! If you want to load radeonkms at boot time (from /boot/loader.conf), you need to load the required firmwares too, otherwise they can't be loaded automatically during boot (/ isn't mounted yet). To find the list of firmwares you need to load, you can read instructions on the wiki: https://wiki.freebsd.org/Graphics#Video_driver_loaded_at_boot_time -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: new Xorg (KMS, etc.) for Radeon 9600
On 18.12.2013 07:41, d...@gmx.com wrote: > Jean-Sébastien Pédron wrote, On 12/17/2013 22:20: >> On 16.12.2013 08:36, d...@gmx.com wrote: >>> Still nobody wants to apply Robert Noland's DRM patch? >> >> What problem(s) does this patch fix? > > It fixes non-deterministic lockups when the (old, drm1) r300 drivers are > used. > > According to John Baldwin [1]: "The drm code is doing a copyin() while > holding a mutex (which is not allowed)." The latest version of the patch > (also the one I used for years) is at [2], linked from [3]. > > [1] > http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005988.html > [2] http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch > [3] > http://lists.freebsd.org/pipermail/freebsd-current/2009-April/006080.html Oh, I didn't notice that the patch targets the old driver, not the new KMS one. I must admit this part isn't my priority and I'm already busy with the new driver. Robert, you worked on this patch a few years ago. Could you please look at it again and maybe commit? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: 11.0-CURRENT panic at (allegedly) a dpms signal (monitor off), in drm2
On 17.12.2013 13:19, Markiyan Kushnir wrote: > Left my desktop (new Xorg, newcons, radeonkms) for a couple of minutes > and found it rebooted after a panic. Never seen this kind of panic > before. That's weird: the code leading to this panic in unreachable, because there's no way currently (that I know of) to change the power management method of the driver to "dynamic". Can you reproduce the problem? If it helps, you can force your monitor off using xset(1): xset dpms force off -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: new Xorg (KMS, etc.) for Radeon 9600
On 16.12.2013 08:36, d...@gmx.com wrote: > Still nobody wants to apply Robert Noland's DRM patch? What problem(s) does this patch fix? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: vt-enabled 11.0-CURRENT + radeonkms boot load = direct rendering disabled in X
Le 13/12/2013 19:24, Adrian Chadd a écrit : Are you able to make it do delayed firmware loading? Delayed until / is mounted? In this case, doesn't loading radeonkms from rc.conf achieve the same result? Firmwares are loaded early during card initialization. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: vt-enabled 11.0-CURRENT + radeonkms boot load = direct rendering disabled in X
On 10.12.2013 12:21, Markiyan Kushnir wrote: > Hello, Hi! First, a quick note: freebsd-current@ and current@ are the same list. > There seems to be a difference in how Xorg server can use direct > rendering depending when radeonkms.ko was loaded: at boot time vs. at > a later time (but not necessarily at X startup time). The difference > is that direct rendering could not be enabled for X in the former > case. In the latter case, direct rendering was successfully enabled. The problem is that if you load radeonkms from the loader or you build it into your kernel, it can't load the relevant firmware(s): error: [drm:pid0:r600_init_microcode] *ERROR* r600_cp: Failed to load firmware "radeonkmsfw_RV710_pfp" error: [drm:pid0:rv770_startup] *ERROR* Failed to load firmware! This is because /boot isn't available at the time the card is initialized: / is not mounted yet. The solution is to load firmware(s) from the loader too (or build them into the kernel). To know which firmware(s) are used by your card, you can boot without radeonkms, kldload it after the computer booted, and run: kldstat | grep radeonkmsfw -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: svn commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
On 10.12.2013 00:49, Aleksandr Rybalko wrote: > It is not fatal in syscons case. We decide to mark this message as > error, to get more attention when run with newcons. For newcons it > indicate that vt will not be able to draw into framebuffer(memory > region which contain image you see on display). > But it have no impact on sc (syscons). Is there something we can check at build time or runtime to determine which of syscons or newcons is used, and consequently, avoid this error message? Because we'll probably have many reports of that in the future. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: svn commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
On 09.12.2013 09:59, Markiyan Kushnir wrote: > I'm on rev. 259102 and hitting drm not being able to attach to fbd > device at X startup (X freezing). I believe those issues are unrelated: I have the "Failed to attach fbd device" because I'm using syscons, however, X.Org works perfectly well. From your /var/log/messages, the driver properly initialized the card and logged no error. Can you post your Xorg.0.log please? How do you determine that X is frozen? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: [Newcons] EDID message every second or 2?
On 08.12.2013 00:14, Larry Rosenman wrote: > info: [drm] Loading R100 Microcode > error: [drm:pid0:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load > firmware "radeonkmsfw_R100_cp" > error: [drm:pid0:r100_cp_init] *ERROR* Failed to load firmware! Hi! I don't know if this could explain your EDID problem, but several users had this failure to load firmware and I couldn't reproduce it. Do you have a file called radeonkmsfw_R100_cp.ko in your kernel directory (eg. /boot/kernel/radeonkmsfw_R100_cp.ko)? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: new Xorg (KMS, etc.) for Radeon 9600
Le 14/11/2013 22:35, Tijl Coosemans a écrit : The attached patch should fix it, but I haven't been able to test it yet. The ai_aperture_size field is in bytes. So it doesn't work, but it gets a bit further: Thank Tijl, I committed your patch today. It looks like some support for AGP is missing in radeon_ttm.c. It's hidden behind #ifdef DUMBBELL_WIP. Yes. I looked at it today: the work is non-trivial and I don't have the required knowledge to do it alone. I'll talk about it to Konstantin Belousov as the time permits. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN r258549 breaks -current compiled with gcc
On 25.11.2013 15:13, Michael Butler wrote: > --- drm_linux_list_sort.o --- > cc1: warnings being treated as errors > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_linux_list_sort.c: > In function 'drm_le_cmp': > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_linux_list_sort.c:45: > warning: cast discards qualifiers from pointer target type Hello! Can you try the attached patch? I got rid of __DECONST() because clang didn't complain, sorry... -- Jean-Sébastien Pédron diff --git a/sys/dev/drm2/drm_linux_list_sort.c b/sys/dev/drm2/drm_linux_list_sort.c index ae4cd64..19c5c9e 100644 --- a/sys/dev/drm2/drm_linux_list_sort.c +++ b/sys/dev/drm2/drm_linux_list_sort.c @@ -42,8 +42,8 @@ drm_le_cmp(void *priv, const void *d1, const void *d2) struct drm_list_sort_thunk *thunk; thunk = priv; - le1 = *(struct list_head **)d1; - le2 = *(struct list_head **)d2; + le1 = *(__DECONST(struct list_head **, d1)); + le2 = *(__DECONST(struct list_head **, d2)); return ((thunk->cmp)(thunk->priv, le1, le2)); } signature.asc Description: OpenPGP digital signature
Re: new Xorg (KMS, etc.) for Radeon 9600
Le 10/11/2013 18:20, d...@gmx.com a écrit : drmn0: info: GTT: 0M 0xF000 - 0xEFFF Tijl Coosemans is right, the problem is this line. As I don't really now how AGP works and have no AGP hardware to reproduce the problem, can you post the output of the following commands as a start? pciconf -lvbce devinfo -vr Thanks! -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Radeon HD 6290 and radeonkms
Le 07/11/2013 20:14, KOT MATPOCKuH a écrit : Hi all! Hi! Is possible to use radeonkms on Radeon HD 6290 card? I tried to boot kernel with loaded radeonkms module, but amd64 and i386 kernels hangs while booting after messages like this: Your card is an integrated card (IGP), right? There's one known issue: we fail to detect that it's the default output at boot time. Try to put this line in your /boot/loader.conf, and reboot: hw.pci.default_vgapci_unit="0" Tell us if this fix your problem with both i386 and amd64. That silent reboot is not a known issue. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10.0-BETA2: LAPIC event timer and C2 c-state -> abnormal high load
I forgot the output of dmesg: http://people.freebsd.org/~dumbbell/lapic-high-load/dmesg-10.txt -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
10.0-BETA2: LAPIC event timer and C2 c-state -> abnormal high load
Hello! I partially upgraded my workstation from 9.2-RELEASE-p1 to 10.0-BETA2 using freebsd-update. Partially because I only performed the first pass (installing the kernel and rebooting). After the boot, the average load was around 5, with no activity on the computer. I tried again by disabling all services in rc.conf and rebooted: same load. Other symptoms are: o The display (syscons) is only redrawn when hitting random keys on a PS/2 or USB keyboard. o When all services are disabled (even NIC is not configured), the computer isn't able to boot or shutdown in a reasonable time without hitting the keyboard too (I guess to generate some interrupts). The chosen event timer is different between 9.2 and 10.0: 9.2: kern.eventtimer.timer: HPET kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(400) i8254(100) RTC(0) 10.0: kern.eventtimer.timer: LAPIC kern.eventtimer.choice: LAPIC(400) HPET(350) HPET1(340) HPET2(340) HPET3(340) i8254(100) RTC(0) I have hw.acpi.cpu.cx_lowest=C2 in sysctl.conf. I tested the following combinations: o HPET + cx_lowest=C1: normal load, computer responsive o HPET + cx_lowest=C2: normal load, computer responsive o LAPIC + cx_lowest=C1: normal load, computer responsive o LAPIC + cx_lowest=C2: high load /!\ Can someone help me track the problem down? :) Thanks! -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [patch] Re: drm2/radeon dfixed_trunc() warnings
On 07.10.2013 21:04, Sean Bruno wrote: > Proposed patch to eliminate this check. If I understand the macro > correctly, there's no way for these checks to ever do anything as bit > shifting an unsigned will simply clear out the value. So, the check for > <0 is completely bogus? Hello! I think you're right. I saw Clang reporting those warnings. Coverity has many more. I didn't want to fix them for now, to ease future merges from Linux. The plan is to submit patches to upstream at some point. Thanks for the patch! I should prepare a branch to store that kind of fixes. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Xorg-Radeon
On 17.09.2013 14:51, ajtiM wrote: > I bult Xorg on iMc, Radeon HD 4850 with ddvd support and "starts" > works :). The problem is when I exit it stay in black screen. There are > no errors in Xorg.log. This is a know issue: our current console implementation, "syscons", doesn't know about KMS (the new way to driver video cards from the kernel, not from X.Org itself). Therefore, once you start X.Org, the console can't use the display anymore, neither during your X session using Ctrl-Alt-Fx, nor after you exit from X.Org. However, even if your screen is blank after X exit, the computer doesn't crash and can be used remotely. This also means you don't have to force a shutdown: a short press on the power button will shut down the computer properly. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: FreeBSD 10.0 ALPHA1
On 17.09.2013 00:57, ajtiM wrote: > Thank you. I used portsnap and installed subversion. Than rm > /usr/ports and /vard/db/portsnap and use svn and it works :). Hi! Could you please explain the problem(s) you have with X.Org and Radeon? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: FreeBSD 10.0 ALPHA1
On 16.09.2013 23:16, Alexander Panyushkin wrote: > After rebuild world from svn, Xorg does not start and the box goes to > reboot. Is this still the same problem that you reported in the "i915kms.ko not loading" thread? Or this is a Radeon-based computer? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: i915kms.ko not loading
Le 04/09/2013 17:01, Alexander a écrit : > ... > #8 0x80319390 in drm_attach (kdev=, > idlist=) at /usr/src/sys/dev/drm/drm_drv.c:462 > ... In this stack trace, it appears that the "drm" code is used, not "drm2". Do you have "device drm" in your kernel config? If yes, please remove it, as well as "device i915" if you have it too, and retry. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: i915kms.ko not loading
On 02.09.2013 12:00, Alexander wrote: > (...) > #17 0x80462700 in sysctl_move_oid () > #18 0x80319070 in drm_attach () > (...) The kernel is missing debug symbols. Could you please rebuild your kernel with the following option: makeoptions DEBUG=-g (also found in GENERIC) Then reproduce the problem and send the output of kgdb again? Thanks! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: i915kms.ko not loading
Le 30/08/2013 19:45, Alexander a écrit : Hi I created the coredump files after create swap on new disk. But size very large. Great! Could you please run: kgdb /boot/kernel/kernel /var/crash/vmcore.0 And, at gdb prompt: bt Then send the whole output (from the moment you run "kgdb" to the end of "bt" output) and your /var/log/messages file? -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: i915kms.ko not loading
On 29.08.2013 19:51, Alexander wrote: > I have swapinfo on zfs partition I always heard that swap on ZFS is asking for trouble, because ZFS loves to use memory. So when the system is using swap space, ZFS has more work and therefore wants more RAM, whici is unavailable. Furthermore, I'm not sure if kernel core dumping on swap on ZFS is supported at all. The following discussion on the forum suggests it's not possible: http://forums.freebsd.org/showthread.php?t=37958 Can you plug another driver and setup swap on it? A USB drive/key should be fine. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: i915kms.ko not loading
On 29.08.2013 19:06, John Baldwin wrote: > On Thursday, August 29, 2013 11:39:45 am Jean-Sébastien Pédron wrote: >> On 29.08.2013 17:35, Alexander wrote: >>> in sysctl: >>> kern.coredump: 1 >>> kern.corefile: /var/coredumps/%U.%N.%P.core >>> >>> but coredump files not created. > > These control user process core dumps, not kernel crash dumps. You're right, thanks for correcting my answer. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: i915kms.ko not loading
On 29.08.2013 17:35, Alexander wrote: > in sysctl: > kern.coredump: 1 > kern.corefile: /var/coredumps/%U.%N.%P.core > > but coredump files not created. > > How to set for creating core files? You must add the following line to your /etc/rc.conf: dumpdev="AUTO" Also add this line to your /etc/sysctl.conf: debug.debugger_on_panic=0 The core dump is written to the swap device when the crash occurs. During the next boot, it's written to the specified kern.corefile path. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: i915kms.ko not loading
On 28.08.2013 21:42, Alexander Panyushkin wrote: > problem in load module i915kms.ko > if *kldload i915kms.ko* system is going to reboot Are you able to obtain a kernel core dump? They're saved in /var/crash during the next boot. If you have one, could you please send the last core.txt? This file contains a trace of the crash, the state of the computer at the time of the crash and dmesg's output. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: svn commit: r254021 - head/contrib/wpa/src/drivers
On 07.08.2013 15:48, Jean-Sébastien Pédron wrote: > On 07.08.2013 06:03, Rui Paulo wrote: >> -*status = ifmr.ifm_status & IFM_ACTIVE; >> +*status = ifmr.ifm_status & (IFM_ACTIVE|IFM_AVALID); > > The timing problem is back with this change. I guess because IFM_AVALID > is set but not IFM_ACTIVE. Maybe they must be both set? (sorry, typo in mailing-list address...) -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: 802.1X: dhclient started before the auth. process ends
On 29.07.2013 21:56, Rui Paulo wrote: > Disable all the configuration settings and run wpa_supplicant -ddd > I'm not sure I understand what you mean by "disable all the configuration settings" but I did some more tests by running wpa_supplicant manually (ie. not using netif script) with the same options. I found that when the interface (here, bge0) is already UP before running wpa_supplicant, the authentication process is fast. However, when the interface is DOWN, wpa_supplicant "associates" quickly but the authentication process starts between 5 and 20 seconds after. Here's a log with both run (with interface UP then DOWN): http://pastebin.com/f5ydiBpV This delay is new with the recent 10-CURRENT. A comment about the behavior I would expect (but keep in mind I'm a dumb user here, not a network expert at all). I see in the logs that when issueing "service netif restart bge0": 1. the interface is put DOWN, which terminates a previous dhclient 2. wpa_supplicant is stopped 3. wpa_supplicant is started again 4. wpa_supplicant associates with a remote peer, which puts the interface UP and triggers dhclient I guess that this works for a Wifi network because the association is only valid after the authentication finishes successfully. However, with 802.1X not involving Wifi (only wired), the association is made right at the beginning (see the logs I pasted), putting the interface UP (and triggering dhclient) before the authentication starts. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: 802.1X: dhclient started before the auth. process ends
On 29.07.2013 15:34, Adrian Chadd wrote: > I think you were lucky. I think you're right. It works perfectly on FreeBSD 9.1, because wpa_supplicant finishes the auth process really quickly, ie. before dhclient receives an answer from dhcpd from the unauthenticated network: Jul 29 15:39:46 - kernel: bge0: link state changed to UP Jul 29 15:39:46 - dhclient[46150]: DHCPREQUEST on bge0 to 255.255.255.255 port 67 Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-STARTED EAP authentication started ... Jul 29 15:39:47 - wpa_supplicant[46119]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Jul 29 15:39:48 - dhclient[46150]: DHCPREQUEST on bge0 to 255.255.255.255 port 67 Jul 29 15:39:48 - dhclient[46150]: DHCPACK from 192.168.200.224 Jul 29 15:39:48 - dhclient: New IP Address (bge0): 192.168.200.91 Jul 29 15:39:48 - dhclient: New Subnet Mask (bge0): 255.255.255.0 Jul 29 15:39:48 - dhclient: New Broadcast Address (bge0): 192.168.200.255 Jul 29 15:39:48 - dhclient: New Routers (bge0): 192.168.200.254 On -CURRENT, wpa_supplicant is started more than 10 seconds after the interface is UP and dhclient sent its request (http://pastebin.com/ZHcbHLQZ). Therefore, a lease from the unauthenticated network arrives first. It was working with a previous -CURRENT (buildworld from around April if memory serves). > dhclient shouldn't start running until wpa_supplicant has completed > authentication. Damn, I always thought it worked this way on FreeBSD and happily laughed at "Linux co-workers" who use some kind of rc.local script to work around this issue :-) In fact, we're all in the same boat! I may take a look at the issue. I guess the place to fix this is in the rc scripts. Does someone have a hint? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
802.1X: dhclient started before the auth. process ends
Hi! At $WORK, we use 802.1X to authenticate computers on the network. Authenticated computers receive a lease in the 192.168.X.X/24 network. Unauthenticated ones receive a lease in the 172.16.X.X/24 network. Today, I upgraded one computer running 10-CURRENT to latest HEAD and it seems that the interface is brought up to early now: dhclient is started before wpa_supplicant finishes. This was working perfectly before the upgrade. I don't have logs of the working case, but here are the logs of the non-working one: http://pastebin.com/ZHcbHLQZ Was I lucky with wpa_supplicant/dhclient timing? Or is there a real issue here? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: DTrace of radeonkms on 9.1
On 27.03.2013 23:07, J.R. Oldroyd wrote: > I've built a dtrace kernel per the instructions in the handbook and > on the DTrace wiki page. I would now like to do this: > > boot system > kldload dtraceall > kldload drm2 > dtrace -o dtrace.log -s script.d > (the script will use fbt probes on various > functions currently in the drm2 module) > kldload radeonkms > start xorg and do various things that provoke the leak > stop xorg > kldunload radeonkms > kill the dtrace script > kldunload drm2 > kldunload dtraceall > > then go look at the log results. > > But, the system is stopping dead shortly after the radeonkms load. I would like to add that the same scenario works perfectly on 10-CURRENT. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On 21.03.2013 09:04, Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 06:36:10PM -0700, David Wolfskill wrote: >> I elected to go ahead and try the bisection; here are my results: >> >> r248493M/248493: OK >> r248550M/248551: resets on X startup with nvidia.ko >> r248521M/248521: resets on X startup with nvidia.ko >> r248507M/248507: OK >> r248508M/248508: resets on X startup with nvidia.ko >> >> r248493M/248493 was my last working point (built yesterday morning). >> r248550M/248551 was what failed for me this morning. >> r248521M/248521 was a convenient mid-point between the above two. >> r248507M/248507 was the next natural test-point. >> r248508M/248508 was a guess on my part -- I would normally have gone to >> r248514, but since I had previously noted that r248508 touched some >> things that nvidia-driver uses, I thought that test might be worthwhile. >> >> I am, however, mildly concerned that no one else appears to be reporting >> similar symptoms (though I have it on good authority that someone is >> about to test). > > This gives me an idea. The only so to say 'vm' change in r248508 was an > addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed > tunable did not eliminated the submap creation. Please try r248569 > with vfs.unmapped_buf_allowed set to 0. > > If this combination allows the nvidia driver to start, please revert > the setting of vfs.unmapped_buf_allowed, and instead set > kern.bio_transient_maxcnt e.g. to 256 or even 128. > > Also, on the machine without the tunables customization, please show > the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show > the output of pciconf -lvb. To be able to have kernel core dumps while X.Org is running, I need to set the "debug.debugger_on_panic=0" sysctl. Otherwise, the computer only reboots (it doesn't honor the ddb script). Maybe it can help here? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r247835: drm2 code breaks buildkernel
On 05.03.2013 16:37, Konstantin Belousov wrote: > The patch below is supposed to fix double declaration (it is pathetic that > clang silently accepts this, while issuing countless useless warnings). > Also there is a usual workaround for the anonimous union/struct issue. What do you think about "-fms-extensions"? It avoids modifications to the code and works with both gcc and clang. There're several unnamed structs/unions in the radeon code too. I would like to keep the diff with Linux code as small as possible. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: drm GPU hung, resume no longer working
On 05.03.2013 16:07, Glen Barber wrote: > error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer > elapsed... GPU hung > info: [drm] capturing error event; look for more information in sysctl > hw.dri.0.info.i915_error_state > > hw.dri.0.info.i915_error_state output is at: > > http://people.freebsd.org/~gjb/i915.sysctl.txt It won't help much, but rpaulo@ posted a mail with a similar dmesg but different trigger on freebsd-x11@: http://lists.freebsd.org/pipermail/freebsd-x11/2013-March/012862.html -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r247835: drm2 code breaks buildkernel
On 05.03.2013 15:54, J.R. Oldroyd wrote: > A fix for these is in my big "get it to compile" patch that I emailed > you both the other day. Sorry, I didn't take the time to read it yet :-/ >>> dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declare >>> anything >>> dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declare >>> anything > > Experimentation shows that this warning is triggered because we use > -std=iso9899:1999. It can be turned off again by adding --ms-extensions > too. > > Alternatively, my big patch replaces all these anon unions with > named ones. There are lots of these in this code, though. Doing > this adds lots of patch bloat. Yes, the flag is preferable. I didn't have the time to test it earlier either, until now. I confirm that it works with both clang and gcc. > There is a further problem not mentioned here. Three of the files > make use of a pointer to a volatile int but later cast this to a > (void *). Because we also have -Wcast-qual, this cast triggers > "cast discards qualifier on pointer target type" warnings and because > of -Werror, this then aborts. What's the best way to fix that? Those warnings are in the radeon driver, not ttm, aren't they? At least, the build finishes properly on my computer with gcc and clang with just -fms-extensions. -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: r247835: drm2 code breaks buildkernel
On 05.03.2013 13:30, Glen Barber wrote:
> dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of
> 'ttm_write_unlock' [-Wredundant-decls]
> dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of
> 'ttm_write_unlock' was here
> dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of
> 'ttm_write_lock' [-Wredundant-decls]
> dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of
> 'ttm_write_lock' was here
Those redundant declarations weren't spotted by clang.
Konstantin, would you like me to commit the fix for this? And we need to
upstream it too.
> dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declare
> anything
> dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declare
> anything
These errors and the following are caused by unnamed structs and unions
inside another struct:
struct ttm_pool_manager {
...
union {
struct ttm_page_poolpools[NUM_POOLS];
struct {
...
} ;
};
};
With default options, clang accepts this but apparently, not gcc.
I would like an opinion from the toolchain gurus, because I don't know
what's the proper way to fix this one.
J.R. Oldroyd CC'd, because he started to work on radeonkms backport to 9
and faced exactly those issues.
--
Jean-Sébastien Pédron
signature.asc
Description: OpenPGP digital signature
Re: r247835: drm2 code breaks buildkernel
On 05.03.2013 11:20, Hartmann, O. wrote: > On r247835 build kernel fails: > > (...) > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_global.c:63:27: > error: unused variable 'item' [-Werror,-Wunused-variable] > struct drm_global_item *item = &glob[i]; Could you try the patch below? http://people.freebsd.org/~dumbbell/radeonkms/drm_global-unused-variable.a.patch -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Failed to switch consoles in 9.0-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.11.2012 17:53, Tomek CEDRO wrote: > Thanks for hint :-) For some reasons I need to have console usable > after/during xorg is active, for instance at the moment I have > problems with xfce4 and no console keeps me away from seeing what > is wrong and even getting back into xorg. Depending on the issues you have with XFCE, you should be able to dump the content of the console while in X.Org by using the following command: vidcontrol -P -H < /dev/ttyv0 This command dumps the whole console buffer (-P), including history (-H). - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEUEARECAAYFAlCc5icACgkQa+xGJsFYOlPNVQCXWFmbqAQ1z04u3hcLRbxpUQWI AQCgvbX9d45E3p9pQCwFgHGOzmGoQUw= =B55w -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after starting X with r238120
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.07.2012 15:06, Konstantin Belousov wrote: > You know, this is not much useful ? Backtrace is. Sorry, I forgot to mention that I had the same backtrace than Steve. I'll buildworld again (probably not today) and report back. - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/6kY4ACgkQa+xGJsFYOlMvHgCeNW76VSjVkf4/on2LYFKGR5Bs R7UAoNYkQtmvpzlblqd3mudp57Kg2K22 =oIqg -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after starting X with r238120
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.07.2012 05:14, Steve Wills wrote: > For what it's worth, I discovered that twm and xterm don't trigger > the issue, but konsole and other kde things do, which is what led > me to discover that setting kern.ipc.shm_use_phys back to default > fixed it. I encountered the same issue with x11-wm/awesome, but everything's ok with twm. A kernel from 2012-06-23 doesn't crash but a kernel from 2012-07-03 does crash. Here're the sysctls/tunables I have regarding shm: In /boot/loader.conf: kern.ipc.shmmni="1024" kern.ipc.shmseg="1024" In /etc/sysctl.conf: kern.ipc.shmmax=2147483648 kern.ipc.shm_use_phys=1 kern.ipc.shm_allow_removed=1 - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/5QesACgkQa+xGJsFYOlPRwQCcClck3824nWltHoIVzuzmLBLz dyUAoIhVeREUZH26QdcJkyyXfna9LYQQ =mKU0 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lang/gcc46: error when compiling with CLANG
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30.04.2012 08:11, O. Hartmann wrote: > Repeating the build ends up at the same "stage" as it stopped when > building on regular basis - for my understanding. You say you have two boxes running 10-CURRENT: do they run the same SVN revision? A recent change (r234585, 2012-04-22) in libc causes several softwares to segfault if the libc is built with clang. I just committed to HEAD (r234836) a patch that fixes this. Maybe it's related to your problem, you may want to try it. - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+eexEACgkQa+xGJsFYOlNvQgCgmOVXZiH5zv5T+RdVL25rdome +zAAoLR/deC5HhWwZgNi/8yK8wcYJ0AS =RUSU -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: segfault in vfscanf(3): clang and __restrict usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.04.2012 00:01, Boris Samorodov wrote: > I've rebuild the world (because I had to use gcc-built world for > obvious reason) and now smartd works (can't test cupsd for now). > BTW, the port devel/ORBit2 which segfaulted both with clang and gcc > is built fine now. Thanks! I committed the patch to HEAD r234836. Thank you both for your feedback and sorry for the delay. - -- Jean-Sébastien Pédron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+eePEACgkQa+xGJsFYOlMD5QCcDh/qLnHOysRjWjsR9o18FxHv oTkAnRoAXi4t3QCDk7tiQeVM7FDqB07c =1SPA -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
