Re: intel graphics regression? between r332432 and r333982

2018-06-16 Thread Jean-Sébastien Pédron
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

2018-05-17 Thread Jean-Sébastien Pédron
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

2017-06-05 Thread Jean-Sébastien Pédron
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

2017-06-01 Thread Jean-Sébastien Pédron
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

2016-11-18 Thread Jean-Sébastien Pédron
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

2016-11-18 Thread Jean-Sébastien Pédron
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

2016-11-18 Thread Jean-Sébastien Pédron
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

2016-08-09 Thread Jean-Sébastien Pédron
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

2016-03-29 Thread Jean-Sébastien Pédron
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

2016-03-19 Thread Jean-Sébastien Pédron
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

2016-03-09 Thread Jean-Sébastien Pédron
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

2016-03-08 Thread Jean-Sébastien Pédron
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

2016-02-24 Thread Jean-Sébastien Pédron
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

2016-02-19 Thread Jean-Sébastien Pédron
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

2015-12-20 Thread Jean-Sébastien Pédron
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

2015-12-01 Thread Jean-Sébastien Pédron
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

2015-11-21 Thread Jean-Sébastien Pédron
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?

2015-09-22 Thread Jean-Sébastien Pédron
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?

2015-09-22 Thread Jean-Sébastien Pédron
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?

2015-09-17 Thread Jean-Sébastien Pédron
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?

2015-09-17 Thread Jean-Sébastien Pédron
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?

2015-09-17 Thread Jean-Sébastien Pédron
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

2015-09-03 Thread Jean-Sébastien Pédron
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

2015-08-31 Thread Jean-Sébastien Pédron
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

2015-08-31 Thread Jean-Sébastien Pédron
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)

2015-03-03 Thread Jean-Sébastien Pédron
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

2015-03-03 Thread Jean-Sébastien Pédron
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

2015-02-17 Thread Jean-Sébastien Pédron
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

2015-02-11 Thread Jean-Sébastien Pédron
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

2014-11-04 Thread Jean-Sébastien Pédron
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

2014-11-02 Thread Jean-Sébastien Pédron
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

2014-11-02 Thread Jean-Sébastien Pédron
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

2014-10-31 Thread Jean-Sébastien Pédron
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

2014-10-31 Thread Jean-Sébastien Pédron
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

2014-10-31 Thread Jean-Sébastien Pédron
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

2014-10-31 Thread Jean-Sébastien Pédron
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

2014-10-27 Thread Jean-Sébastien Pédron
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

2014-10-20 Thread Jean-Sébastien Pédron
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!

2014-09-11 Thread Jean-Sébastien Pédron
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!

2014-09-10 Thread Jean-Sébastien Pédron
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

2014-09-05 Thread Jean-Sébastien Pédron
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

2014-08-23 Thread Jean-Sébastien Pédron

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

2014-08-23 Thread Jean-Sébastien Pédron

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

2014-08-22 Thread Jean-Sébastien Pédron

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

2014-08-22 Thread Jean-Sébastien Pédron

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

2014-08-22 Thread Jean-Sébastien Pédron

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

2014-08-19 Thread Jean-Sébastien Pédron
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

2014-08-19 Thread Jean-Sébastien Pédron
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

2014-08-19 Thread Jean-Sébastien Pédron
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

2014-08-19 Thread Jean-Sébastien Pédron
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

2014-07-25 Thread Jean-Sébastien Pédron
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

2014-07-25 Thread Jean-Sébastien Pédron
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

2014-06-16 Thread Jean-Sébastien Pédron
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

2014-06-06 Thread Jean-Sébastien Pédron
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

2014-05-21 Thread Jean-Sébastien Pédron
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

2014-03-05 Thread Jean-Sébastien Pédron
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

2014-02-11 Thread Jean-Sébastien Pédron
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"

2014-01-25 Thread Jean-Sébastien Pédron
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"

2014-01-25 Thread Jean-Sébastien Pédron
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

2013-12-18 Thread Jean-Sébastien Pédron
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

2013-12-17 Thread Jean-Sébastien Pédron
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

2013-12-17 Thread Jean-Sébastien Pédron
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

2013-12-13 Thread Jean-Sébastien Pédron

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

2013-12-13 Thread Jean-Sébastien Pédron
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

2013-12-10 Thread Jean-Sébastien Pédron
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

2013-12-09 Thread Jean-Sébastien Pédron
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?

2013-12-09 Thread Jean-Sébastien Pédron
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

2013-12-08 Thread Jean-Sébastien Pédron

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

2013-11-25 Thread Jean-Sébastien Pédron
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

2013-11-13 Thread Jean-Sébastien Pédron

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

2013-11-07 Thread Jean-Sébastien Pédron

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

2013-10-29 Thread Jean-Sébastien Pédron

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

2013-10-29 Thread Jean-Sébastien Pédron

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

2013-10-08 Thread Jean-Sébastien Pédron
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

2013-09-17 Thread Jean-Sébastien Pédron
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

2013-09-17 Thread Jean-Sébastien Pédron
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

2013-09-17 Thread Jean-Sébastien Pédron
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

2013-09-14 Thread Jean-Sébastien Pédron

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

2013-09-02 Thread Jean-Sébastien Pédron
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

2013-08-30 Thread Jean-Sébastien Pédron

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

2013-08-30 Thread Jean-Sébastien Pédron
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

2013-08-30 Thread Jean-Sébastien Pédron
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

2013-08-29 Thread Jean-Sébastien Pédron
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

2013-08-29 Thread Jean-Sébastien Pédron
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

2013-08-07 Thread Jean-Sébastien Pédron
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

2013-07-30 Thread Jean-Sébastien Pédron
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

2013-07-29 Thread Jean-Sébastien Pédron
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

2013-07-26 Thread Jean-Sébastien Pédron
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

2013-03-28 Thread Jean-Sébastien Pédron
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

2013-03-21 Thread Jean-Sébastien Pédron
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

2013-03-05 Thread Jean-Sébastien Pédron
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

2013-03-05 Thread Jean-Sébastien Pédron
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

2013-03-05 Thread Jean-Sébastien Pédron
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

2013-03-05 Thread Jean-Sébastien Pédron
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

2013-03-05 Thread Jean-Sébastien Pédron
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

2012-11-09 Thread Jean-Sébastien Pédron
-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

2012-07-09 Thread Jean-Sébastien Pédron
-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

2012-07-08 Thread Jean-Sébastien Pédron
-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

2012-04-30 Thread Jean-Sébastien Pédron
-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

2012-04-30 Thread Jean-Sébastien Pédron
-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"


  1   2   >