Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
Hi,
Without the attached kernel patch(es), Xorg starts consuming alot of CPU
and becomes very unresponsive and unusable.
Using ktrace reveals that X-org is issuing DRM_IOCTL_MODE_GETCONNECTOR
over and over again with no apparent reason. It doesn't happen when
using a simple window manager like blackbox. I was not able to use XFCE4
(9-stable userland) with 11-current kernel at all, after the latest DRM2
kernel updates. It worked fine before the update.
I'm not sure what is causing it. Going through the new DRM2 code
revealed that a mode sorting function did not take all parameters like
interlaced or not into account, causing the mode list to be reshuffelled
every time a new mode scan was done. Not sure if Xorg cares about this
though.
I can test patches if you have other suggestions.
--HPS
diff --git a/sys/dev/drm2/drm_crtc.c b/sys/dev/drm2/drm_crtc.c
index 318a764..d368e83 100644
--- a/sys/dev/drm2/drm_crtc.c
+++ b/sys/dev/drm2/drm_crtc.c
@@ -1499,15 +1499,18 @@ int drm_mode_getconnector(struct drm_device *dev, void *data,
}
}
- if (out_resp->count_modes == 0) {
+ list_for_each_entry(mode, &connector->modes, head)
+ mode_count++;
+
+ if (mode_count == 0) {
connector->funcs->fill_modes(connector,
dev->mode_config.max_width,
dev->mode_config.max_height);
- }
- /* delayed so we get modes regardless of pre-fill_modes state */
- list_for_each_entry(mode, &connector->modes, head)
- mode_count++;
+ /* delayed so we get modes regardless of pre-fill_modes state */
+ list_for_each_entry(mode, &connector->modes, head)
+ mode_count++;
+ }
out_resp->connector_id = connector->base.id;
out_resp->connector_type = connector->connector_type;
diff --git a/sys/dev/drm2/drm_modes.c b/sys/dev/drm2/drm_modes.c
index 4df8cb1..db06176 100644
--- a/sys/dev/drm2/drm_modes.c
+++ b/sys/dev/drm2/drm_modes.c
@@ -928,6 +928,10 @@ static int drm_mode_compare(void *priv, struct list_head *lh_a, struct list_head
if (diff)
return diff;
diff = b->clock - a->clock;
+ if (diff)
+ return diff;
+ diff = ((b->flags & DRM_MODE_FLAG_INTERLACE) != 0) -
+ ((a->flags & DRM_MODE_FLAG_INTERLACE) != 0);
return diff;
}
___
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: Time to be real
Hi, Joe has indicated in the past that SPAM was sent from his account: https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095407.html We (postmaster@) contacted Joe and are looking into the issue. Please do not reply to the thread anymore. Florian signature.asc Description: OpenPGP digital signature
Re: Time to be real
On Mon, 23 Mar 2015 14:26:26 -0400 Joe Nosay wrote _ //| |___ || | /__/||| | PLEASE | |||| | | |||| | DO NOT FEED | |||| | |__|/|| | THE TROLLS ___ || | /__/||| | |__|/|| ||/ | || | ||/| |\|/\||/| /\// /\/ |_ > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-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: Time to be real
Thank you for your troll. For your convenience, we will do our best not to reply to you any further, to waste either your time, or valuable electrons. mcl ___ 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: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working
No, it's something in the ath driver and ath_hal code. I'm sorry, I've been busy debugging other things in my limited spare time; I just haven't had the chance to sit down and look at the rfkill code. :( -a ___ 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"
Time to be real
Go to hell. Go fuck yourselves. ___ 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: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working
On 3/22/2015 7:22 AM, Adrian Chadd wrote: ok, then hm, where's the gpio pin configured.. -a How do I check where this gpio pin is configured? I guess I have to enable gpio in the kernel in order to somehow do that? On 21 March 2015 at 21:55, Miguel Clara wrote: On March 22, 2015 4:19:23 AM WET, Adrian Chadd wrote: Ok, so I'd cycle that rfkill gpio from 1 -> uhm, whatever the max for that thing is (16?) Each time: ifconfig wlan0 down sysctl dev.ath.0.rfkill=X ifconfig wlan0 up ifconfig wlan0 list scan See if it sees anything. It seems to accept only 0 and 1. I'll have to play with that tomorrow as its almost 5am here. But it seems to show no scan results with either 0 or 1 (when running just scan... list scan works the first time.. but its not really re-scaning) -adrian -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ 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: bsdinstall and current (possible stable) snapshots
On Mon, 23 Mar 2015 10:46:32 -0700
Nathan Whitehorn wrote:
>
> On 03/23/15 09:47, Sergey V. Dyatko wrote:
> > On Mon, 23 Mar 2015 09:15:57 -0700
> > Nathan Whitehorn wrote:
> >
> >> On 03/23/15 09:06, Devin Teske wrote:
> On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko
> wrote:
>
> Hi Devin,
>
> Recently I'm trying to install FreeBSD CURRENT from bootonly image
> ( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
> on IBM HS22 blade via bladecenter's kvm but I faced with problem on
> checksum stage, bootonly doesn't contain base, kernel,etc distributions
> but it contain manifest file.
> On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
> MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
> fetched files. I suppose it will be fine with RELEASE bootonly iso but
> not with stable/current.
> there is 2 ways how we can handle it:
> 1) download remote MANIFEST if spotted checksum mismatch and trying to
> use it 2) allow user to continue installation with 'broken' distributions
>
> I had to first put 10.1 then update it to HEAD :(
>
> What do you think ?
> >>> When I get some time I’ll have a look and see what I can do.
> >>> —
> >>> Cheers,
> >>> Devin
> >>>
> >>>
> >> Using the local manifest is a security feature -- there is otherwise
> >> zero protection against a man-in-the-middle attack. Ideally, you'd use
> >> the ISO that matches the posted files. There are three options here:
> >> 1. Add a dialog that lets you move ahead in the event of checksum
> >> failure, which makes me very nervous.
> >> 2. Use the boot1 disk.
> >> 2a. For release engineering: if the posted tarballs change too fast, the
> >> bootonly disk isn't actually useful for -CURRENT and should probably be
> >> removed from the FTP server.
> > I don't think so. I use only bootonly ISOs when I (rare) setup new
> > fbsd instances, disk1 contain to much useless (for me) things. I
> > haven't fast internet (in 2015, yes) so download data1 image is a pain.
>
> What useless things, out of curiousity? If you want source (which you
> probably do if you are running -CURRENT), boot1 + downloading kernel,
> base, and source code is 80% the size of disc1 for amd64. It's just not
> a huge difference.
>
~55 vs ~360 MB (FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso.xz VS
FreeBSD-11.0-CURRENT-amd64-20150302-r279514-disc1.iso.xz)
I do fetch src/ports (both HEAD) from svn so _in my case_ it is useless
(tarballs a bit outdated as minimum). Main purpose of ISOs (for me) is allow to
install minimal FreeBSD on new server. Than I can ssh into it and setup useful
stuff
> > What about STABLE images/tarballs ? If I understand correctly it is also
> > uploaded too fast...
>
> The same issue applies there, yes.
>
> >> 3. You could reroll the ISO (just untar and run makefs again),
> >> commenting out line 180 of /usr/libexec/bsdinstall/scripts/auto.
> >> -Nathan
> > sure I can.
> > Idea with a dialog is a good idea, IMO :)
> >
>
> That's so@'s lookout. I'd prefer actual signatures to checksum
> verification + an option to skip.
> -Nathan
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
--
wbr, tiger
___
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: bsdinstall and current (possible stable) snapshots
On 03/23/15 09:47, Sergey V. Dyatko wrote:
On Mon, 23 Mar 2015 09:15:57 -0700
Nathan Whitehorn wrote:
On 03/23/15 09:06, Devin Teske wrote:
On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko
wrote:
Hi Devin,
Recently I'm trying to install FreeBSD CURRENT from bootonly image
( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
on IBM HS22 blade via bladecenter's kvm but I faced with problem on
checksum stage, bootonly doesn't contain base, kernel,etc distributions
but it contain manifest file.
On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
fetched files. I suppose it will be fine with RELEASE bootonly iso but not
with stable/current.
there is 2 ways how we can handle it:
1) download remote MANIFEST if spotted checksum mismatch and trying to use
it 2) allow user to continue installation with 'broken' distributions
I had to first put 10.1 then update it to HEAD :(
What do you think ?
When I get some time I’ll have a look and see what I can do.
—
Cheers,
Devin
Using the local manifest is a security feature -- there is otherwise
zero protection against a man-in-the-middle attack. Ideally, you'd use
the ISO that matches the posted files. There are three options here:
1. Add a dialog that lets you move ahead in the event of checksum
failure, which makes me very nervous.
2. Use the boot1 disk.
2a. For release engineering: if the posted tarballs change too fast, the
bootonly disk isn't actually useful for -CURRENT and should probably be
removed from the FTP server.
I don't think so. I use only bootonly ISOs when I (rare) setup new
fbsd instances, disk1 contain to much useless (for me) things. I
haven't fast internet (in 2015, yes) so download data1 image is a pain.
What useless things, out of curiousity? If you want source (which you
probably do if you are running -CURRENT), boot1 + downloading kernel,
base, and source code is 80% the size of disc1 for amd64. It's just not
a huge difference.
What about STABLE images/tarballs ? If I understand correctly it is also
uploaded too fast...
The same issue applies there, yes.
3. You could reroll the ISO (just untar and run makefs again),
commenting out line 180 of /usr/libexec/bsdinstall/scripts/auto.
-Nathan
sure I can.
Idea with a dialog is a good idea, IMO :)
That's so@'s lookout. I'd prefer actual signatures to checksum
verification + an option to skip.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall and current (possible stable) snapshots
On Mon, 23 Mar 2015 09:15:57 -0700
Nathan Whitehorn wrote:
>
> On 03/23/15 09:06, Devin Teske wrote:
> >> On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko
> >> wrote:
> >>
> >> Hi Devin,
> >>
> >> Recently I'm trying to install FreeBSD CURRENT from bootonly image
> >> ( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
> >> on IBM HS22 blade via bladecenter's kvm but I faced with problem on
> >> checksum stage, bootonly doesn't contain base, kernel,etc distributions
> >> but it contain manifest file.
> >> On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
> >> MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
> >> fetched files. I suppose it will be fine with RELEASE bootonly iso but not
> >> with stable/current.
> >> there is 2 ways how we can handle it:
> >> 1) download remote MANIFEST if spotted checksum mismatch and trying to use
> >> it 2) allow user to continue installation with 'broken' distributions
> >>
> >> I had to first put 10.1 then update it to HEAD :(
> >>
> >> What do you think ?
> > When I get some time I’ll have a look and see what I can do.
> > —
> > Cheers,
> > Devin
> >
> >
>
> Using the local manifest is a security feature -- there is otherwise
> zero protection against a man-in-the-middle attack. Ideally, you'd use
> the ISO that matches the posted files. There are three options here:
> 1. Add a dialog that lets you move ahead in the event of checksum
> failure, which makes me very nervous.
> 2. Use the boot1 disk.
> 2a. For release engineering: if the posted tarballs change too fast, the
> bootonly disk isn't actually useful for -CURRENT and should probably be
> removed from the FTP server.
I don't think so. I use only bootonly ISOs when I (rare) setup new
fbsd instances, disk1 contain to much useless (for me) things. I
haven't fast internet (in 2015, yes) so download data1 image is a pain.
What about STABLE images/tarballs ? If I understand correctly it is also
uploaded too fast...
> 3. You could reroll the ISO (just untar and run makefs again),
> commenting out line 180 of /usr/libexec/bsdinstall/scripts/auto.
> -Nathan
sure I can.
Idea with a dialog is a good idea, IMO :)
--
wbr, tiger
___
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"
buildworld failure on 10.1 - Please advise
Hello everyone I beg to be advised on what I should do to solve why my attempts at buildworld on 10.1-RELEASE fail as follows: ===> gnu/usr.bin/gperf (obj,depend,all,install) ===> gnu/usr.bin/gperf/doc (obj) /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/gperf/doc created for /usr/src/gnu/usr.bin/gperf/doc rm -f .depend CC='clang' mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr .bin/gperf /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.c c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc /usr/src/gnu/us r.bin/gperf/../../../contrib/gperf/src/keyword.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc /usr/src/gnu/usr.bin/gperf/../../../co ntrib/gperf/src/options.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/posit ions.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/search.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc /usr/src/gnu/ usr.bin/gperf/../../../contrib/gperf/lib/getline.cc /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc echo gperf: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend echo gperf: /usr/lib/libc++.a >> .depend ===> gnu/usr.bin/gperf/doc (depend) clang++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c / usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc clang++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c / usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc clang++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c / usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/input.cc clang++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c / usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword-list.cc clang++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c / usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/keyword.cc clang++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c / usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc clang++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c / usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc *** Error code 1 Stop. make[3]: stopped in /usr/src/gnu/usr.bin/gperf *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 "I can't hear you -- I'm using the scrambler." ___ 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: bsdinstall and current (possible stable) snapshots
On 03/23/15 09:06, Devin Teske wrote:
On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko wrote:
Hi Devin,
Recently I'm trying to install FreeBSD CURRENT from bootonly image
( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
stage, bootonly doesn't contain base, kernel,etc distributions but it contain
manifest file.
On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
fetched files. I suppose it will be fine with RELEASE bootonly iso but not with
stable/current.
there is 2 ways how we can handle it:
1) download remote MANIFEST if spotted checksum mismatch and trying to use it
2) allow user to continue installation with 'broken' distributions
I had to first put 10.1 then update it to HEAD :(
What do you think ?
When I get some time I’ll have a look and see what I can do.
—
Cheers,
Devin
Using the local manifest is a security feature -- there is otherwise
zero protection against a man-in-the-middle attack. Ideally, you'd use
the ISO that matches the posted files. There are three options here:
1. Add a dialog that lets you move ahead in the event of checksum
failure, which makes me very nervous.
2. Use the boot1 disk.
2a. For release engineering: if the posted tarballs change too fast, the
bootonly disk isn't actually useful for -CURRENT and should probably be
removed from the FTP server.
3. You could reroll the ISO (just untar and run makefs again),
commenting out line 180 of /usr/libexec/bsdinstall/scripts/auto.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall and current (possible stable) snapshots
> On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko
> wrote:
>
> Hi Devin,
>
> Recently I'm trying to install FreeBSD CURRENT from bootonly image
> ( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
> on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
> stage, bootonly doesn't contain base, kernel,etc distributions but it contain
> manifest file.
> On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
> MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
> fetched files. I suppose it will be fine with RELEASE bootonly iso but not
> with
> stable/current.
> there is 2 ways how we can handle it:
> 1) download remote MANIFEST if spotted checksum mismatch and trying to use it
> 2) allow user to continue installation with 'broken' distributions
>
> I had to first put 10.1 then update it to HEAD :(
>
> What do you think ?
When I get some time I’ll have a look and see what I can do.
—
Cheers,
Devin
___
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: Broadwell Support FreeBSD 10.1
Brendan Inglese wrote on 03/23/2015 05:33: [...] If not for a while are discrete Nvidia cards such as the 760 ( Which another model has ) which I can find in http://www.gigabyte.com.au/products/product-page.aspx?pid=5156#ov stable? Last time I used X with a GTX680 it would crash twice a week. I am running PC-BSD 10.1.1 on Dell PowerEdge T20 (Haswell with E3-1225v3) with nVidia GT 630. It is running fine, no crashes at all. Miroslav Lachman ___ 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: Broadwell Support FreeBSD 10.1
On 03/22/2015 19:49, Glen Barber wrote: > On Sun, Mar 22, 2015 at 04:32:06PM -0700, Marek Novotny wrote: >> New to this group, and new to FreeBSD via PC-BSD. Really like it so far. >> Sorry if this has been asked to death already. Levono has their new T450 >> with the 5th gen intel Broadwell i5 processor. I bought it with the hopes of >> running PC-BSD latest version on it. It uses intel 5500 graphics as well. >> Any potential issues using this?? >> > > You won't be able to use accelerated graphics. > > I have the T540p which has the i7-4800MQ, and am quite happy with > running FreeBSD CURRENT on it. I don't care about accelerated graphics > too much, though. > > One nit with the laptop is I needed to use an external USB flash drive > to store /boot on an MBR partition, because my hard drives are > GPT-partitioned using ZFS on '/' on GELI-encrypted providers. > Otherwise, I have noticed that using the /boot on the GPT disk enforces > low resolution graphics (640x480 IIRC). > > By using a USB flash drive for /boot, I can get 1920x1080 resolution > (one of the many reasons for choosing this laptop). > > (I've been meaning to put this into the FreeBSD Wiki, but EBUSY.) > > Glen > Glen, in the past I briefly tested the uefi bootloader on a Lenovo T440s including with scfb and I believe the default resolution would raise to native if I also disabled CSM mode in the "bios". This affected the console mode as well as scfb which both inherit the framebuffer from the uefi GOP as I understand it. Have you tried that? You should be able to demonstrate it while booted from a uefi boot stick, no permanent system changes necessary. I've also been looking forward to see if this trick works with uefi since xf86-video-scfb performance was perfectly usable on a uefi booted mac but not the lenovo: https://forums.freebsd.org/threads/xorg-vesa-driver-massive-speedup-using-mtrr-write-combine.46723/ ___ 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: Use of chunksize before initialization
On Mon, Mar 23, 2015 at 01:50:26PM +0200, Ivan A. Kosarev wrote: > > On 03/21/2015 11:31 PM, Konstantin Belousov wrote: > > On Sat, Mar 21, 2015 at 11:20:26AM +0200, Ivan A. Kosarev wrote: > >> On 03/21/2015 03:02 AM, Konstantin Belousov wrote: > >>> On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote: > #12 0x0008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698 > #13 malloc_init () at jemalloc_jemalloc.c:296 > #14 0x000801243ea2 in ?? () from /lib/libc.so.7 > #15 0x0008006a5400 in ?? () > #16 0x00080089e5b0 in ?? () from /libexec/ld-elf.so.1 > #17 0x7fffe0b0 in ?? () > #18 0x000801139d06 in _init () from /lib/libc.so.7 > #19 0x7fffe0b0 in ?? () > >>> The backtrace is strange. Did you compiled malloc with the debugging > >>> symbols, while keep rest of libc without -g ? > >> I've just added the -g flag to CC_FLAGS in the Makefile and made sure to > >> install an unstripped version of the .so . I could investigate more on > >> why the early calls omit debug symbols, if it does any matter. > > I want to understand at what stage of the initialization the access happens. > > This is why I want to see the complete backtrace. > > It is jemalloc_constructor() that calls malloc_init(), so it should be > called directly by the loader. Do you mean rtld by loader ? Dynamic linker does not explicitely call into libc. The possible situations when such call occurs, is either execution of the initializers, or calls into the libthr-provided rtld locks, where libthr itself calls malloc to allocate the lock's backing store. The appearance of _init on the unparsed stack is indicative, but not conclusive, since gdb shows the nearest dynamic symbol, which could be _init just by chance. I need to know exact sequence of events causing the problem. Or, in other words, I cannot debug by retelling. ___ 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: Use of chunksize before initialization
On 03/21/2015 11:31 PM, Konstantin Belousov wrote: On Sat, Mar 21, 2015 at 11:20:26AM +0200, Ivan A. Kosarev wrote: On 03/21/2015 03:02 AM, Konstantin Belousov wrote: On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote: #12 0x0008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698 #13 malloc_init () at jemalloc_jemalloc.c:296 #14 0x000801243ea2 in ?? () from /lib/libc.so.7 #15 0x0008006a5400 in ?? () #16 0x00080089e5b0 in ?? () from /libexec/ld-elf.so.1 #17 0x7fffe0b0 in ?? () #18 0x000801139d06 in _init () from /lib/libc.so.7 #19 0x7fffe0b0 in ?? () The backtrace is strange. Did you compiled malloc with the debugging symbols, while keep rest of libc without -g ? I've just added the -g flag to CC_FLAGS in the Makefile and made sure to install an unstripped version of the .so . I could investigate more on why the early calls omit debug symbols, if it does any matter. I want to understand at what stage of the initialization the access happens. This is why I want to see the complete backtrace. It is jemalloc_constructor() that calls malloc_init(), so it should be called directly by the loader. -- ___ 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: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On 22 Mar 2015, at 22:01, Craig Rodrigues wrote: > >> Volatile is not the solution, it is completely orthogonal. The correct >> way would be to use unsigned integers, for which wrapping is defined, >> then convert those back and forth when presenting the results to the >> user. >> > > OK, converting expr.y to use unsigned integers would require a bit of work. Note that clang has, for a few releases, had builtins that allow overflow-checked operations and will generate very efficient code. In op_times, I believe the following should work: long long mul; #if __has_builtin(__builtin_smulll_overflow) if (__builtin_smulll_overflow(a->u.i, b->u.i, &mul)) errx(ERR_EXIT, "overflow"); #else mul = a->u.i * b->u.i; #endif r = make_integer(mul); I don't know if recent versions of gcc implement these builtins yet. I think they were added to clang around 3.4, possibly slightly earlier. David ___ 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"
