Re: vt(4) odd scrolling behavior
Looks like video driver reports double buffer as single frame buffer, so vt draw it as big screen, but video card draw it as two layers. ___ 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: vt(4) sysctl inconsistency question
On Wed, 04 Feb 2015 22:56:57 +0100 Michal Varga wrote: > I have a quick question regarding the vt driver which hopefully someone > involved in its design could answer for me. > > Roughly 4 months ago, vt gained the ability to listen to a set of > keyboard combinations controlling power/debug situations and the ability > to control (or more precisely, turn off) their behavior via sysctls: > > http://svnweb.freebsd.org/base/head/sys/dev/vt/vt_core.c?r1=271380&r2=271381&; > > Interestingly, two cases in particular (excluding SPSC which isn't > implemented yet) were left out of this configuration, namely the standby > and suspend modes (STBY, SUSP), making use of those keys completely > non-optional. > > If anyone could tell me, what was the reason for not including sysctls > for those two modes? > > m. > > > -- > Michal Varga, > Stonehenge > > > > > ___ > 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" Hi Michal! When I was work on vt(4) due to lack of knowledge about kbd(4) internals I decide to not touch it a lot, so I mostly just copy sc(4) things :) IIRC support of such keys/combinations will require some updates to kbd(4). Think, if somebody will prepare patch for such things, guys and maybe me, will be happy to review and possibly commit it. Thanks! WBW -- Aleksandr Rybalko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r269471 make unusable VT console
On Tue, 12 Aug 2014 23:28:07 +0200 Carlos Jacobo Puga Medina wrote: > > I believe it's still broken. There's a related PR at > > http://bugs.freebsd.org/192452 and, I suspect, 192456. Aleksandr, would > > you mind reverting this reversion? It seems to have created a lot of > > problems. > > -Nathan > > Yes, I think that ray@ is around here somewhere to fix this :P > > Regards, > -- > Carlos Jacobo Puga Medina Hi guys! Sorry for delay. Carlos, can you please share picture of such bad behaviuor? Looks like this mode almost unused novadays, so modern hardware have problems in implementations of this mode. Thanks! WBW -- Aleksandr Rybalko ___ 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: build failure on 10-stable
On Mon, 7 Jul 2014 14:55:33 -0500 (CDT) Dan Mack wrote: > FYI. > > This is from : 268370 during 'make buildkernel' with GENERIC options: > > --- buildkernel --- > --- buildkernel --- > -- > >>> Kernel build for GENERIC started on Mon Jul 7 14:42:57 CDT 2014 > -- > ===> GENERIC > mkdir -p /usr/obj/usr/src/sys > -- > >>> stage 1: configuring the kernel > -- > cd /usr/src/sys/amd64/conf; > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > config -d /usr/obj/usr/src/sys/GENERIC -I '/usr/src/sys/amd64/conf' > '/usr/src/sys/amd64/conf/GENERIC' > config: Error: device "vt_efifb" is unknown > config: 1 errors > *** [buildkernel] Error code 1 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [buildkernel] Error code 2 > > make: stopped in /usr/src > 1 error > > make: stopped in /usr/src > > > > dan > -- > Dan Mack > > ___ > 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" Ok, removed. Dan, now you can update sources again or just remove "device vt_efifb" lin from sys/amd64/conf/GENERIC. Of course no UEFI graphic will be supported. Just not yet for STABLE-10. Thanks for report. WBW -- Aleksandr Rybalko ___ 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: build failure on 10-stable
On 7 липня 2014 р. 22:55:33 GMT+03:00, Dan Mack wrote: >FYI. > >This is from : 268370 during 'make buildkernel' with GENERIC options: > >--- buildkernel --- >--- buildkernel --- >-- >>>> Kernel build for GENERIC started on Mon Jul 7 14:42:57 CDT 2014 >-- >===> GENERIC >mkdir -p /usr/obj/usr/src/sys >-- >>>> stage 1: configuring the kernel >-- >cd /usr/src/sys/amd64/conf; >PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin >config -d /usr/obj/usr/src/sys/GENERIC -I '/usr/src/sys/amd64/conf' >'/usr/src/sys/amd64/conf/GENERIC' >config: Error: device "vt_efifb" is unknown >config: 1 errors >*** [buildkernel] Error code 1 > >make[1]: stopped in /usr/src >1 error > >make[1]: stopped in /usr/src >*** [buildkernel] Error code 2 > >make: stopped in /usr/src >1 error > >make: stopped in /usr/src > > > >dan >-- >Dan Mack > >___ >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" Hi Den, That one is fixed, but we have onother one. Ed, do we will have efi headers MFCed to 10, or should I remove efifb driver from GENERIC config? Thanks. P.S. Sorry for breakage. WBW -- Aleksandr Rybalko ___ 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: uefi boot on Apple Mac
On Mon, 7 Jul 2014 08:18:37 +0800 Huang Wen Hui wrote: > I got the same result from Fedora-20: > > [liveuser@localhost ~]$ dmesg|grep efifb > [2.665017] efifb: probing for efifb > [2.667915] efifb: framebuffer at 0x8002, mapped to > 0xc9000b98, using 28800k, total 28800k > [2.667916] efifb: mode is 2880x1800x32, linelength=16384, pages=1 > [2.667916] efifb: scrolling: redraw > [2.667917] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > > stride(4096) *4 = linelength No, stride >= line_width * bytes_per_pixel. It is just step size in bytes, to skip into next line. (sometime it contain gaps related to blank parts of screen, sometime related to round screen line to page size). So if it have mode - 2880x1800x32, it have to be 2880 * (32 / 8) = 11520 or 11520 + (4096 - 1) & 0x_f000 = 12288 (0x03000, 3 4k_pages) > 28800k=stride(4096) *4*1800=0x1c2 > > > 2014-07-07 2:59 GMT+08:00 Adrian Chadd : > > > The linux UEFI peeps have the same problem(s): > > > > http://mjg59.dreamwidth.org/10014.html > > > > Look for "stride". > > > > > > -a > > > > > > On 6 July 2014 06:40, Aleksandr Rybalko wrote: > > > On Fri, 4 Jul 2014 22:34:30 +0800 > > > Huang Wen Hui wrote: > > > > > >> Hi, > > >> On my MacbookPro11,3, I got this error message: > > >> > > >> http://sw.gddsn.org.cn/freebsd/uefi.jpg > > > > > > Hmmm, really weird. > > > Looks like wrong info about UEFI framebuffer. > > > Picture said: > > > 1. 2880 x 1800 > > > 2. 4 bytes per pixel (masks cover whole 32bit) > > > 3. but same time stride eq to 4096 (but have to be (width * > > bytes_per_pixel) 4 * 2880) > > > > > >> > > >> cheers, > > >> > > >> Huang WenHui > > >> > > >> 2014-07-04 22:13 GMT+08:00 Ed Maste : > > >> > > >> > On 24 May 2014 19:39, Rafael Esp'indola > > wrote: > > >> > > > > >> > > Yes, I got that in the mac laptops I tried, it worked on a Mac Pro. > > It > > >> > > might be the frame buffer corruption that Ed Maste was mentioning. > > >> > > > >> > I purchased a new MacBook Air yesterday (model identifier > > >> > MacBookAir6,2). UEFI boot and vt(4) worked correctly. (My image > > >> > included Rafael's patch; I haven't tried a boot without.) > > >> > > > >> > I also committed a change to display the framebuffer parameters > > >> > (address, dimensions, etc.) on boot, in order to help identify the > > >> > source of this issue. If you have a moment can you build a new USB > > >> > stick image and give it a try? > > >> > > > >> > -Ed > > >> > > > >> ___ > > >> freebsd-current@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > > >> To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > > > > > > Thanks. > > > WBW > > > -- > > > Aleksandr Rybalko > > > ___ > > > 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" > > -- Aleksandr Rybalko ___ 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: uefi boot on Apple Mac
On Fri, 4 Jul 2014 22:34:30 +0800 Huang Wen Hui wrote: > Hi, > On my MacbookPro11,3, I got this error message: > > http://sw.gddsn.org.cn/freebsd/uefi.jpg Hmmm, really weird. Looks like wrong info about UEFI framebuffer. Picture said: 1. 2880 x 1800 2. 4 bytes per pixel (masks cover whole 32bit) 3. but same time stride eq to 4096 (but have to be (width * bytes_per_pixel) 4 * 2880) > > cheers, > > Huang WenHui > > 2014-07-04 22:13 GMT+08:00 Ed Maste : > > > On 24 May 2014 19:39, Rafael Esp'indola wrote: > > > > > > Yes, I got that in the mac laptops I tried, it worked on a Mac Pro. It > > > might be the frame buffer corruption that Ed Maste was mentioning. > > > > I purchased a new MacBook Air yesterday (model identifier > > MacBookAir6,2). UEFI boot and vt(4) worked correctly. (My image > > included Rafael's patch; I haven't tried a boot without.) > > > > I also committed a change to display the framebuffer parameters > > (address, dimensions, etc.) on boot, in order to help identify the > > source of this issue. If you have a moment can you build a new USB > > stick image and give it a try? > > > > -Ed > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Thanks. WBW -- Aleksandr Rybalko ___ 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: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Thu, 3 Jul 2014 18:20:59 +0200 (CEST)
Trond Endrestol wrote:
> On Thu, 3 Jul 2014 17:50+0200, Trond Endrestol wrote:
>
> > On Thu, 3 Jul 2014 12:48+0300, Aleksandr Rybalko wrote:
> >
> > > On Thu, 3 Jul 2014 08:31:45 +0200 (CEST)
> > > Trond Endrestol wrote:
> > >
> > > > On Thu, 3 Jul 2014 08:21+0200, Trond Endrestol wrote:
> > > >
> > > > > On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
> > > > >
> > > > > > On 2 July 2014 17:09, Trond Endrestol
> > > > > > wrote:
> > > > > > > On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
> > > > > > >
> > > > > > >> On 2 July 2014 14:51, Trond Endrestol
> > > > > > >> wrote:
> > > > > > >> > Hi,
> > > > > > >> >
> > > > > > >> > Is it just me or is there something wrong with vidcontrol(1) in
> > > > > > >> > base/head, amd64, sc console, r268165?
> > > > > > >>
> > > > > > >> Should be fixed in r268175.
> > > > > > >
> > > > > > > Looks good, thanks.
> > > > > >
> > > > > > Thanks for the report, and sorry for the trouble.
> > > > >
> > > > > No trouble at all, I follow base/head (and stable/{8,9,10}) on
> > > > > various
> > > > > VMs at home only to know what's ahead. ;-)
> > > > >
> > > > > Since neither kbdcontrol(1) nor I mind using the old syscons keymap
> > > > > file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
> > > > > vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
> > > > > after searching for them in /usr/share/vt/keymaps?
> > > > >
> > > > > E.g.:
> > > > >
> > > > > Index: usr.sbin/kbdcontrol/kbdcontrol.c
> > > > > ===
> > > > > --- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
> > > > > +++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
> > > > > @@ -804,7 +804,7 @@
> > > > > char*postfix[] = {blank, dotkbd, NULL};
> > > > >
> > > > > if (is_vt4())
> > > > > - prefix[2] = vt_keymap_path;
> > > > > + prefix[1] = vt_keymap_path;
> > > > > cp = getenv("KEYMAP_PATH");
> > > > > if (cp != NULL)
> > > > > asprintf(&(prefix[0]), "%s/", cp);
> > > >
> > > > Or maybe this patch is even better, as it leaves one instance of blank
> > > > in the array when KEYMAP_PATH is set in the environment, at prefix[1],
> > > > and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not
> > > > set in the environment.
> > > >
> > > > Index: usr.sbin/kbdcontrol/kbdcontrol.c
> > > > ===
> > > > --- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
> > > > +++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
> > > > @@ -800,7 +800,7 @@
> > > > char*name, *cp;
> > > > charblank[] = "", keymap_path[] = KEYMAP_PATH;
> > > > charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = ".kbd";
> > > > - char*prefix[] = {blank, blank, keymap_path, NULL};
> > > > + char*prefix[] = {blank, blank, blank, keymap_path, NULL};
> > > > char*postfix[] = {blank, dotkbd, NULL};
> > > >
> > > > if (is_vt4())
> > > >
> > > > For now I could just stick to using an absolute pathname for keymap=
> > > > in /etc/rc.conf.
> > >
> > > Hi Trond,
> > >
> > > It is not so good idea to fallback to syscons keymaps, because vt(4)
> > > works with Unicode only char codes. So fallback will make input with
> > > non-English characters - unreadable.
> > >
> > > Instead of that fallback you can convert keymaps you can verify by
> > > follow instructions in [1], then please check it and send it to list,
> > > so me or someone else will commit it.
> > >
> > > Thank you for reports!
> > >
> > &
Re: vidcontrol(1) complains about Bad magic, in base/head, amd64, sc console, r268165
On Thu, 3 Jul 2014 08:31:45 +0200 (CEST)
Trond Endrestøl wrote:
> On Thu, 3 Jul 2014 08:21+0200, Trond Endrestøl wrote:
>
> > On Wed, 2 Jul 2014 17:37-0400, Ed Maste wrote:
> >
> > > On 2 July 2014 17:09, Trond Endrestøl
> > > wrote:
> > > > On Wed, 2 Jul 2014 16:43-0400, Ed Maste wrote:
> > > >
> > > >> On 2 July 2014 14:51, Trond Endrestøl
> > > >> wrote:
> > > >> > Hi,
> > > >> >
> > > >> > Is it just me or is there something wrong with vidcontrol(1) in
> > > >> > base/head, amd64, sc console, r268165?
> > > >>
> > > >> Should be fixed in r268175.
> > > >
> > > > Looks good, thanks.
> > >
> > > Thanks for the report, and sorry for the trouble.
> >
> > No trouble at all, I follow base/head (and stable/{8,9,10}) on various
> > VMs at home only to know what's ahead. ;-)
> >
> > Since neither kbdcontrol(1) nor I mind using the old syscons keymap
> > file norwegian.iso.kbd, wouldn't it be nice if kbdcontrol(1), while in
> > vt(4) mode, would search for keymaps in /usr/share/syscons/keymaps
> > after searching for them in /usr/share/vt/keymaps?
> >
> > E.g.:
> >
> > Index: usr.sbin/kbdcontrol/kbdcontrol.c
> > ===
> > --- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
> > +++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
> > @@ -804,7 +804,7 @@
> > char*postfix[] = {blank, dotkbd, NULL};
> >
> > if (is_vt4())
> > - prefix[2] = vt_keymap_path;
> > + prefix[1] = vt_keymap_path;
> > cp = getenv("KEYMAP_PATH");
> > if (cp != NULL)
> > asprintf(&(prefix[0]), "%s/", cp);
>
> Or maybe this patch is even better, as it leaves one instance of blank
> in the array when KEYMAP_PATH is set in the environment, at prefix[1],
> and sadly add a redundant blank at prefix[2] when KEYMAP_PATH is not
> set in the environment.
>
> Index: usr.sbin/kbdcontrol/kbdcontrol.c
> ===
> --- usr.sbin/kbdcontrol/kbdcontrol.c(revision 268203)
> +++ usr.sbin/kbdcontrol/kbdcontrol.c(working copy)
> @@ -800,7 +800,7 @@
> char*name, *cp;
> charblank[] = "", keymap_path[] = KEYMAP_PATH;
> charvt_keymap_path[] = VT_KEYMAP_PATH, dotkbd[] = ".kbd";
> - char*prefix[] = {blank, blank, keymap_path, NULL};
> + char*prefix[] = {blank, blank, blank, keymap_path, NULL};
> char*postfix[] = {blank, dotkbd, NULL};
>
> if (is_vt4())
>
> For now I could just stick to using an absolute pathname for keymap=
> in /etc/rc.conf.
>
> --
> +---++
> | Vennlig hilsen, | Best regards, |
> | Trond Endrestøl, | Trond Endrestøl, |
> | IT-ansvarlig, | System administrator, |
> | Fagskolen Innlandet, | Gjøvik Technical College, Norway, |
> | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, |
> | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. |
> +---++
> ___
> 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"
Hi Trond,
It is not so good idea to fallback to syscons keymaps, because vt(4)
works with Unicode only char codes. So fallback will make input with
non-English characters - unreadable.
Instead of that fallback you can convert keymaps you can verify by
follow instructions in [1], then please check it and send it to list,
so me or someone else will commit it.
Thank you for reports!
1.
http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html
WBW
--
Aleksandr Rybalko
___
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: RFT vidcontrol for vt(4)
On Thu, 29 May 2014 09:11:04 -0700 Kevin Oberman wrote: > On Thu, May 29, 2014 at 7:56 AM, Claude Buisson > wrote: > > > On 05/29/2014 15:17, Aleksandr Rybalko wrote: > > > >> On Mon, 12 May 2014 17:10:54 +0200 > >> Claude Buisson wrote: > >> > >> On 05/12/2014 16:14, Aleksandr Rybalko wrote: > >>> > >>>> On Mon, 12 May 2014 15:35:48 +0200 > >>>> Claude Buisson wrote: > >>>> > >>>> On 03/11/2014 15:27, Aleksandr Rybalko wrote: > >>>>> > >>>>>> Hello hackers! > >>>>>> > >>>>>> Here is link to the patch[1] for vidcontrol that makes it to > >>>>>> know if it > >>>>>> run w/ or w/o vt(4) and if vt(4) is present, then: > >>>>>> 1. screen map feature disabled (vt(4) use Unicode, so screen > >>>>>> map not needed). > >>>>>> 2. enable to load fornt from /usr/share/vt/fonts/ dir. PLease > >>>>>> put "gallant" font[2] to /usr/share/vt/fonts/. > >>>>>> > >>>>>> Looks like it works fine, but maybe I forgot something :) > >>>>>> So please test it in your own environment. > >>>>>> > >>>>>> Big thanks to Ed for preparing that font file! > >>>>>> > >>>>>> 1. > >>>>>> http://people.freebsd.org/~ray/newcons/vidcontrol_for_vt_ > >>>>>> 2014-03-11.patch > >>>>>> 2. http://people.freebsd.org/~emaste/newcons/gallant.fnt > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>>> WBW > >>>>>> > >>>>>> > >>>>> Hi, > >>>>> > >>>>> I applied this patch on a 10.0-STABLE r264390 with a Radeon > >>>>> Mobility X300 (M22) > >>>>> 5460, and DRM2. > >>>>> > >>>>> I could load an home made terminus 16x32 font (my eyes are too > >>>>> old to work with > >>>>> a 8x16 font on a 1920x1200 17" screen), by > >>>>> > >>>>> - looping on each ttyvN in a rc.local script > >>>>> > >>>>> or > >>>>> > >>>>> - adding allscreens_flags="-f terminus-u32" to rc.conf (for > >>>>> /etc/rc.d/syscons > >>>>> consumption) > >>>>> > >>>> > >>>> Cool! > >>>> Are you like to share that font? > >>>> > >>>> > >>> Off course. > >>> In fact I generated 12x24, 14x28 and 16x32 fonts from > >>> terminus-font-4.38 by > >>> using the tools/tools/vt/fontcvt utility. > >>> I will send you these fonts offlist (because the FreeBSD lists do > >>> not like > >>> attachments). > >>> > >>> > >>>>> I just discovered than scrolling back in console mode works > >>>>> ONLY on ttyv0. > >>>>> > >>>> > >>>> Huh, it's surprising me. Before your mail I think we have > >>>> problem with scrollback on vty0, but not on others. :) > >>>> Looks like I have to concentrate and fix them all at once. > >>>> > >>>> > >>> I confirm that scrollback works on ttyv0, but not on others ttyv > >>> when a font is > >>> loaded. > >>> > >>> > >>>>> What I have to do to get scrolling on every ttyvN ? > >>>>> > >>>>> The only way to get the system working in normal VGA mode > >>>>> (640x480) (not loading > >>>>> the drm2 and radeon kms modules by loader.conf) is by > >>>>> configuring the BIOS to > >>>>> not do display expansion - which leads to the same ridiculously > >>>>> small font.. > >>>>> > >>>>> And of course, kbdmux keeps being mandatory to be able to load a > >>>>> keymap. > >>>>> > >>>> > >>>> Yeah, I still remember. :) > >>>> > >>>> > >>> This could be noted in the newly born vt(4) man page .. > >>> > >>> > >>>>> TIA > >>>>> > >>>>> Claude Buisson > >>>>> > >>>>> > >>>> Many thanks Claude! > >>>> > >>>> WBW > >>>> > >>>> > >>> CBu > >>> > >>> > >> Hello Claude! > >> > >> Looks like nobody care about this patch, only you did test for > >> it :) So I commit it to HEAD, if you need it to be MFCed, I will > >> do it a week later. > >> > >> Many thanks for your help!!! > >> > >> WBW > >> > >> > > Hello ! > > > > I (sort of) solved the scroll problem by patching > > sys/dev/vt/font/vt_font_default.c > > to compile my 16x32 font into the kernel. > > > > Clearly some more work is needed to make the modified vidcontrol a > > finished utility and to have the proper rc.conf knob to load a > > custom font at boot. And it must also be possible to generate a > > kernel with a custom font, without > > having to patch the source. > > > > I also found that > > tools/tools/vt/mkkfont/mkkfont.c > > does not put a comma after the final "}" of .vf_map, so one must > > apply the attached patch. > > > > Keep the work going ! > > > > CBu > > > > Actually, I did test vidcontrol patches, but everything just seemed > to work fine, so I failed to report anything. I guess reporting that > nothing happened is a bit boring, but still important. > > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkober...@gmail.com Late is better than never :) Thanks Kevin! WBW -- Aleksandr Rybalko ___ 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: RFT vidcontrol for vt(4)
On Mon, 12 May 2014 17:10:54 +0200 Claude Buisson wrote: > On 05/12/2014 16:14, Aleksandr Rybalko wrote: > > On Mon, 12 May 2014 15:35:48 +0200 > > Claude Buisson wrote: > > > >> On 03/11/2014 15:27, Aleksandr Rybalko wrote: > >>> Hello hackers! > >>> > >>> Here is link to the patch[1] for vidcontrol that makes it to know if it > >>> run w/ or w/o vt(4) and if vt(4) is present, then: > >>> 1. screen map feature disabled (vt(4) use Unicode, so screen map not > >>> needed). > >>> 2. enable to load fornt from /usr/share/vt/fonts/ dir. PLease put > >>> "gallant" font[2] to /usr/share/vt/fonts/. > >>> > >>> Looks like it works fine, but maybe I forgot something :) > >>> So please test it in your own environment. > >>> > >>> Big thanks to Ed for preparing that font file! > >>> > >>> 1. > >>> http://people.freebsd.org/~ray/newcons/vidcontrol_for_vt_2014-03-11.patch > >>> 2. http://people.freebsd.org/~emaste/newcons/gallant.fnt > >>> > >>> Thanks! > >>> > >>> WBW > >>> > >> > >> Hi, > >> > >> I applied this patch on a 10.0-STABLE r264390 with a Radeon Mobility X300 > >> (M22) > >> 5460, and DRM2. > >> > >> I could load an home made terminus 16x32 font (my eyes are too old to work > >> with > >> a 8x16 font on a 1920x1200 17" screen), by > >> > >> - looping on each ttyvN in a rc.local script > >> > >> or > >> > >> - adding allscreens_flags="-f terminus-u32" to rc.conf (for > >> /etc/rc.d/syscons > >> consumption) > > > > Cool! > > Are you like to share that font? > > > > Off course. > In fact I generated 12x24, 14x28 and 16x32 fonts from terminus-font-4.38 by > using the tools/tools/vt/fontcvt utility. > I will send you these fonts offlist (because the FreeBSD lists do not like > attachments). > > >> > >> I just discovered than scrolling back in console mode works ONLY on ttyv0. > > > > Huh, it's surprising me. Before your mail I think we have problem with > > scrollback on vty0, but not on others. :) > > Looks like I have to concentrate and fix them all at once. > > > > I confirm that scrollback works on ttyv0, but not on others ttyv when a font > is > loaded. > > >> > >> What I have to do to get scrolling on every ttyvN ? > >> > >> The only way to get the system working in normal VGA mode (640x480) (not > >> loading > >> the drm2 and radeon kms modules by loader.conf) is by configuring the BIOS > >> to > >> not do display expansion - which leads to the same ridiculously small > >> font.. > >> > >> And of course, kbdmux keeps being mandatory to be able to load a keymap. > > > > Yeah, I still remember. :) > > > > This could be noted in the newly born vt(4) man page .. > > >> > >> TIA > >> > >> Claude Buisson > >> > > > > Many thanks Claude! > > > > WBW > > > > CBu > Hello Claude! Looks like nobody care about this patch, only you did test for it :) So I commit it to HEAD, if you need it to be MFCed, I will do it a week later. Many thanks for your help!!! WBW -- Aleksandr Rybalko ___ 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: newcons and beeping X
On Sat, 17 May 2014 08:59:14 -0700 (PDT) Jakub Lach wrote: > Hello, > > as of FreeBSD 10.0-STABLE #0 r266216 I still have > a mute console in X (which isn't surprising, as there > was no MFC) > > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/newcons-and-beeping-X-tp5906883p5913086.html > Sent from the freebsd-current mailing list archive at Nabble.com. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Hi Jakub, Yes, I'm did not MFC it yet. Will do it in next few days. WBW -- Aleksandr Rybalko ___ 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 on vt / kms rv610
() at > May 12 23:42:06 moby kernel: __mtx_lock_flags+0xa8/frame > 0xfe011a1612e0 > May 12 23:42:06 moby kernel: terminal_mute() at > May 12 23:42:06 moby kernel: terminal_mute+0x52/frame > 0xfe011a161300 > May 12 23:42:06 moby kernel: vt_allocate() at > May 12 23:42:06 moby kernel: vt_allocate+0x113/frame > 0xfe011a161360 > May 12 23:42:06 moby kernel: vt_fb_attach() at > vt_fb_attach+0x16/frame 0xfe011a161370 > May 12 23:42:06 moby kernel: fbd_register() at > May 12 23:42:06 moby kernel: fbd_register+0x19d/frame > 0xfe011a1613b0 > May 12 23:42:06 moby kernel: device_attach() at > May 12 23:42:06 moby kernel: device_attach+0x3a5/frame > 0xfe011a161410 > May 12 23:42:06 moby kernel: > drm_fb_helper_single_fb_probe() at > drm_fb_helper_single_fb_probe+0x2b6/frame 0xfe011a161460 > May 12 23:42:06 moby kernel: > drm_fb_helper_initial_config() at > drm_fb_helper_initial_config+0xc4/frame 0xfe011a1614a0 > May 12 23:42:06 moby kernel: radeon_fbdev_init() at > May 12 23:42:06 moby kernel: radeon_fbdev_init+0xb9/frame > 0xfe011a1614d0 > May 12 23:42:06 moby kernel: radeon_modeset_init() at > May 12 23:42:06 moby kernel: > radeon_modeset_init+0x95a/frame 0xfe011a161540 > May 12 23:42:06 moby kernel: radeon_driver_load_kms() at > radeon_driver_load_kms+0xc9/frame 0xfe011a161580 > May 12 23:42:06 moby kernel: drm_attach() at > May 12 23:42:06 moby kernel: drm_attach+0x935/frame > 0xfe011a161610 > May 12 23:42:06 moby kernel: device_attach() at > device_attach+0x3a5/frame 0xfe011a161670 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (FreeBSD) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlNzi9wACgkQrDN5kXnx8ybezACgjCy7rhuj12GvOYsqlEpU78dV > DdoAn1HSlcVohZbukRNyAvMkQKCJZ7ZV > =x8fL > -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" Thanks! WBW -- Aleksandr Rybalko ___ 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: RFT vidcontrol for vt(4)
On Mon, 12 May 2014 19:51:21 -0400 George Mitchell wrote: > On 05/12/14 11:25, Nathan Whitehorn wrote: > > [...] > > > > Is there any reason not to have kbdmux be mandatory at this point? > > [...] > > Does this mean mandatory in the sense that the kbdmux driver always > gets built and loaded, or that the kbdmux driver must always be in > operation (treating all keyboard-like devices as a single unified > source of keystrokes)? I could live with the first, but there are > definitely times that I want multiple independent keyboards on a > system to be considered unrelated to one another. -- George kbdmux able to manage keyboard set, so you can attach and detach some keyboards. (But I did not test it long ago for vt(4)) > > ___ > 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" Thanks! WBW -- Aleksandr Rybalko ___ 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: In r265803 i915kms.ko must be loaded in /boot/loader.conf
On 10 травня 2014 р. 22:39:59 GMT+03:00, "Ranjan1018 ." <21474...@gmail.com> wrote: >Hi all, > >in r265172 I was able to load the i915kms.ko driver in /etc/rc.conf via >kld_list. eg. kld_list='i915kms'. > >Today I have update to r265803 in my laptop, but loading the driver >with >kld_list result in a blank screen. I need to add the line >i915kms_load="YES" >in /boot/loader.conf > >Regards, >Maurizio >___ >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" Hi, It have to be fixed in r265927. Sorry for inconvenience. Thanks for testing. WBW -- Aleksandr Rybalko ___ 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(4) and i915kms doesn't work as a post-boot module
On 12 травня 2014 р. 01:28:52 GMT+03:00, Adrian Chadd wrote: >Hi guys, > >vt(4) doesn't work now as a post-boot loaded module. > >It panics, saying > >panic: vtbuf_fill_locked end.tp_row 50 must be <= screen width 30 > >Ray, have you tried your vt(4) changes on an i915 machine but without >loading i915kms at boot? > > >-a Hi Adrian, Looks like it fixed now. Sorry for breakage. Thanks. WBW -- Aleksandr Rybalko ___ 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: RFT vidcontrol for vt(4)
On 12 травня 2014 р. 18:25:52 GMT+03:00, Nathan Whitehorn wrote: >On 05/12/14 08:10, Claude Buisson wrote: >>>> >>>> What I have to do to get scrolling on every ttyvN ? >>>> >>>> The only way to get the system working in normal VGA mode (640x480) > >>>> (not loading >>>> the drm2 and radeon kms modules by loader.conf) is by configuring >>>> the BIOS to >>>> not do display expansion - which leads to the same ridiculously >>>> small font.. >>>> >>>> And of course, kbdmux keeps being mandatory to be able to load a >>>> keymap. >>> >>> Yeah, I still remember. :) >>> >> >> This could be noted in the newly born vt(4) man page .. > >Is there any reason not to have kbdmux be mandatory at this point? >Having it be non-optional would simplify a lot of code and most of the >code for the non-kbdmux case is heavily bitrotten at this point (see >here). >-Nathan Looks like we should just add vt as of dependency to kbdmux. Thanks. WBW -- Aleksandr Rybalko ___ 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: RFT vidcontrol for vt(4)
On Mon, 12 May 2014 15:35:48 +0200 Claude Buisson wrote: > On 03/11/2014 15:27, Aleksandr Rybalko wrote: > > Hello hackers! > > > > Here is link to the patch[1] for vidcontrol that makes it to know if it > > run w/ or w/o vt(4) and if vt(4) is present, then: > > 1. screen map feature disabled (vt(4) use Unicode, so screen map not > > needed). > > 2. enable to load fornt from /usr/share/vt/fonts/ dir. PLease put > > "gallant" font[2] to /usr/share/vt/fonts/. > > > > Looks like it works fine, but maybe I forgot something :) > > So please test it in your own environment. > > > > Big thanks to Ed for preparing that font file! > > > > 1. > > http://people.freebsd.org/~ray/newcons/vidcontrol_for_vt_2014-03-11.patch > > 2. http://people.freebsd.org/~emaste/newcons/gallant.fnt > > > > Thanks! > > > > WBW > > > > Hi, > > I applied this patch on a 10.0-STABLE r264390 with a Radeon Mobility X300 > (M22) > 5460, and DRM2. > > I could load an home made terminus 16x32 font (my eyes are too old to work > with > a 8x16 font on a 1920x1200 17" screen), by > > - looping on each ttyvN in a rc.local script > > or > > - adding allscreens_flags="-f terminus-u32" to rc.conf (for /etc/rc.d/syscons > consumption) Cool! Are you like to share that font? > > I just discovered than scrolling back in console mode works ONLY on ttyv0. Huh, it's surprising me. Before your mail I think we have problem with scrollback on vty0, but not on others. :) Looks like I have to concentrate and fix them all at once. > > What I have to do to get scrolling on every ttyvN ? > > The only way to get the system working in normal VGA mode (640x480) (not > loading > the drm2 and radeon kms modules by loader.conf) is by configuring the BIOS to > not do display expansion - which leads to the same ridiculously small font.. > > And of course, kbdmux keeps being mandatory to be able to load a keymap. Yeah, I still remember. :) > > TIA > > Claude Buisson > Many thanks Claude! WBW -- Aleksandr Rybalko ___ 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: newcons and beeping X
On Thu, 1 May 2014 03:31:21 -0500 "Matthew D. Fuller" wrote: > > A little investigation showed that the KDMKTONE ioctl handler was a > > complete stub, so anything X tried to do to ring the bell was > > completely unavailing. > > Sub'd as http://www.freebsd.org/cgi/query-pr.cgi?pr=189170 > > > -- > Matthew Fuller (MF4839) | fulle...@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ >On the Internet, nobody can hear you scream. Hello Matthew, sorry for delay, been busy with other part of vt(4). I've just commit your patch. Thank you very much for your help! WBW -- Aleksandr Rybalko ___ 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: need info about newcons in jails
On Sat, 03 May 2014 07:15:14 -0400 Fbsd8 wrote: > Hello list. Hi, > > Looking for information about using newcons as the terminal driver in > xorg for desktop in a jail. I don't really understand how that can be related. software running in jail doing output to same terminal in which jail started. So if you open xterm, and start jail from it, jailed s/w will output into xterm window. If you run jail from system virtual terminal syscons or vt(a.k.a. newcons), jailed s/w will output to that virtual terminal, no matter which one it is (syscons or vt(4)) > > Can only find this https://wiki.freebsd.org/Newcons > > Has anybody gotten it to work in a jail? > > Thanks > > > ___ > 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" Just try what you want to try, and if it will behave bad, report it to us. And we will try to help you. Thanks! WBW -- Aleksandr Rybalko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD compile with VT / Newcons... can we disable the "bell" / "beep" hardware sound?
On Fri, 11 Apr 2014 10:48:33 +0100 "Mike C." wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > > On 11 April 2014 08:30:36 WEST, Andreas Nilsson wrote: > >On Fri, Apr 11, 2014 at 8:24 AM, Aleksandr Rybalko > >wrote: > > > >> On Fri, 11 Apr 2014 02:07:43 +0100 > >> Miguel Clara wrote: > >> > >> > Hum... I've found this: > >> > > >> > >http://lists.freebsd.org/pipermail/svn-src-head/2013-December/054676.html > >> > > >> > Does this mean that it should actually be disabled by default? > >> > >> Hello Miguel, > >> > >> No, it's mean you can try with: > >> kbdcontrol -b quiet > >> > >> Good luck! > >> > > > >I also have annoying beeps with vt, but > > > >$ kbdcontrol -b quiet > >kbdcontrol: argument to -b must be duration.pitch or > >[quiet.]visual|normal|off > > > >However kbdcontrol -b quiet.off is accepted. > > > >Best regards > >Andreas > > > > Good to know I was not alone :) > > thanks both for the hint, had no idea I could do that. Ohhh, sorry. I never use it, so forget how to do it in the right way :) > > > > > >> > >> > > >> > > >> > On Fri, Apr 11, 2014 at 2:06 AM, Miguel Clara > >> > wrote: > >> > > >> > > TTYs and even using the console in Xfce terminal > >> > > > >> > > > >> > > On Fri, Apr 11, 2014 at 2:05 AM, Glen Barber > >> > > wrote: > >> > > > >> > >> On Fri, Apr 11, 2014 at 02:02:01AM +0100, Miguel Clara wrote: > >> > >> > On Fri, Apr 11, 2014 at 1:56 AM, Glen Barber > >> > >> > wrote: > >> > >> > > >> > >> > > On Fri, Apr 11, 2014 at 01:52:34AM +0100, Miguel Clara > >wrote: > >> > >> > > > WIth syscons this can be done with > >> > >> > > > > >> > >> > > > > >> > >> > > > # sysctl hw.syscons.bell=0 > >> > >> > > > > >> > >> > > > But after kernel is compiled with VT this systcl is of > >> > >> > > > course not > >> > >> > > possible > >> > >> > > > anymore! > >> > >> > > > > >> > >> > > > Any alternative? > >> > >> > > > >> > >> > > I have yet to hear any bell sounds with vt(4). > >> > >> > > > >> > >> > > Can you clarify the problem, and where this happens? > >> > >> > > > >> > >> > When I for example use "TAB" to complete and there's more than > >> > >> > one result... or none! > >> > >> > > >> > >> > > >> > >> > Happens to me both in FreeBSD 11 current (HP Laptop) and with > >10 > >> > >> > +VT > >> > >> > > >> > >> > >> > >> SSH? Serial console? X? > >> > >> > >> > >> Glen > >> > >> > >> > >> > >> > > > >> > ___ > >> > 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" > >> > >> WBW > >> -- > >> Aleksandr Rybalko > >> ___ > >> 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" > >> > > - -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -BEGIN PGP SIGNATURE- > Version: APG v1.1.1 > > iQJDBAEBCgAtBQJTR7pxJhxNaWd1ZWwgQ2xhcmEgPG1pZ3VlbG1jbGFyYUBnbWFp > bC5jb20+AAoJEGKyFhaKt9g3PrYQANUW192wpLzMj0fXP6Xu/Thy0V/I9s6c4DZm > u+7CwEb8leMJZZ9Dvrqa6bXISZXvi4xmPchoBtuLSmtnHXkgQzE5DARkSOLzv2EO > NNiqe4/OhV1mivM1ehWHGczIl0T0qTJAo1fgcSLLIG5PTN5FADvj2nlsPBNl9NIW > mnZgTS6O8+mJoYvf/S9WaXvwefe5fROgKrGmC297Bqt+9vv2fmECzvxyoYI4skLI > QAnzO8IT8yzhjgpce5tJBPo+GJmYhaI9HFJWlhJ4Zkq03KQXGpX5BM2TJ88nFmQg > nA2JO0KaQm2E6Hj4sIWocR7Ovk+2HFbc9ceYaKmruRCxFDCthmjrx4cb7mw/wHJb > LIt1XRxyeK4p0x7S6YM78VPKJQcosvedKtJ95/XdiVZERRErgl8kLx/hNgqK7fX0 > MtkgGc253p0880ukUOhPOzJAYpsCYHCu4m7qP/JiYfMYQMi1vz4rmIGt+vn5rZmE > PDxB/nYSiety3Sh7Bmqw/cqvSkegZMkaJuMKkAUCQ2A8y7V0DJZ48y+1MMgzD2/S > Y8RlUwwJorMWBMbnG401JytY8RUykeaobCRzVpUdLfy2+QpTSQ94TlAZEedp9VkA > /TYM+uq6/mbhSpKD7QcHFbHA9vk+m1KaG2pF1NcoYwiHOZwwZS2TMq5mtKYavKjV > UtTIJZk9 > =G+q9 > -END PGP SIGNATURE- > Thank you! WBW -- Aleksandr Rybalko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD compile with VT / Newcons... can we disable the "bell" / "beep" hardware sound?
On Fri, 11 Apr 2014 02:07:43 +0100 Miguel Clara wrote: > Hum... I've found this: > http://lists.freebsd.org/pipermail/svn-src-head/2013-December/054676.html > > Does this mean that it should actually be disabled by default? Hello Miguel, No, it's mean you can try with: kbdcontrol -b quiet Good luck! > > > On Fri, Apr 11, 2014 at 2:06 AM, Miguel Clara > wrote: > > > TTYs and even using the console in Xfce terminal > > > > > > On Fri, Apr 11, 2014 at 2:05 AM, Glen Barber > > wrote: > > > >> On Fri, Apr 11, 2014 at 02:02:01AM +0100, Miguel Clara wrote: > >> > On Fri, Apr 11, 2014 at 1:56 AM, Glen Barber > >> > wrote: > >> > > >> > > On Fri, Apr 11, 2014 at 01:52:34AM +0100, Miguel Clara wrote: > >> > > > WIth syscons this can be done with > >> > > > > >> > > > > >> > > > # sysctl hw.syscons.bell=0 > >> > > > > >> > > > But after kernel is compiled with VT this systcl is of > >> > > > course not > >> > > possible > >> > > > anymore! > >> > > > > >> > > > Any alternative? > >> > > > >> > > I have yet to hear any bell sounds with vt(4). > >> > > > >> > > Can you clarify the problem, and where this happens? > >> > > > >> > When I for example use "TAB" to complete and there's more than > >> > one result... or none! > >> > > >> > > >> > Happens to me both in FreeBSD 11 current (HP Laptop) and with 10 > >> > +VT > >> > > >> > >> SSH? Serial console? X? > >> > >> Glen > >> > >> > > > ___ > 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" WBW -- Aleksandr Rybalko ___ 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 text cursor invisible in reverse video
On Thu, 3 Apr 2014 00:38:23 -0500 Mark Linimon wrote: > On Wed, Apr 02, 2014 at 01:01:11PM +0200, Claude Buisson wrote: > > After 19 years of FreeBSD use and not being part of any chapel/coterie/mafia > > I don't keep much illusion about the outcome.. > > I'm sorry that you feel that way. > > Rest assured that a large number of those of us that work on FreeBSD do > try to improve the software. We also try to figure out ways to get more > people involved as contributors, to keep things from becoming stagnant. > > Yes, I know we're not always successful. > > 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" Hi guys! Claude, sorry for delay. Can you please try now? WBW -- Aleksandr Rybalko ___ 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: (more) screen distortion with intel GPU / xorg on recent -HEAD?
On Sun, 23 Mar 2014 13:36:29 -0700 Adrian Chadd wrote: > Less information-poor response: > > * when it happens, the FB will resume correctly for a little bit, then > once everything comes back, it flips to being distorted. So, it's > likely something is misconfiguring stuff during resume. > * I can flip to VTs fine; I can login and do things fine; > * When I flip back to xorg, things still remain distorted; > * If I ctrl-C xorg and start it again, it starts back up correctly. > > So hm, maybe the vt save/resume code learnt something buggy? > No, vt(9) and syscons have nothing to do with FB used by Xorg. With new DRM Xorg allocate own FB and only Xorg and DRM know about it. It seems Xorg's PM events handling is works wrong. Or maybe drm2 should care better about that FB objects. > > -a > > > On 23 March 2014 01:27, Adrian Chadd wrote: > > Hi, > > > > I know this is an information-poor message. > > > > The last time i updated my two test laptops was around the middle of > > last month. Back then, xorg would occasionally get distorted, but > > typically would come back from suspend fine. > > > > Lately, it seems a 50% chance that coming back from suspend that xorg > > will be not only distorted, but further screen redraws are wrong. It's > > like the framebuffer configuration is wrong and persists to be wrong. > > I have to exit out of xorg and restart it. > > > > Has anyone else seen this? > > > > > > -a -- Aleksandr Rybalko ___ 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"
RFT vidcontrol for vt(4)
Hello hackers! Here is link to the patch[1] for vidcontrol that makes it to know if it run w/ or w/o vt(4) and if vt(4) is present, then: 1. screen map feature disabled (vt(4) use Unicode, so screen map not needed). 2. enable to load fornt from /usr/share/vt/fonts/ dir. PLease put "gallant" font[2] to /usr/share/vt/fonts/. Looks like it works fine, but maybe I forgot something :) So please test it in your own environment. Big thanks to Ed for preparing that font file! 1. http://people.freebsd.org/~ray/newcons/vidcontrol_for_vt_2014-03-11.patch 2. http://people.freebsd.org/~emaste/newcons/gallant.fnt Thanks! WBW -- Aleksandr Rybalko ___ 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(9) r261654 with preloaded i915kms -- hangs 9 times out of 10 on boot
On Sat, 15 Feb 2014 19:56:33 +0400 Lev Serebryakov wrote: > Hello, Freebsd-x11. > > $subj. Loading modules via X.org works. > > It is not Lenovo X, it is old Sony Vaio (VGN-SZ340P) and video is > i945GM... > > -- > // Black Lion AKA Lev Serebryakov > > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org" Hi Lev, can you please test same setup but w/o vt(9). I understand you will not see kernel output, but Xorg should show up if problem related to vt(9). Or at least you can do ping test. But way with connected serial cable is best :) Thanks! WBW -- Aleksandr Rybalko ___ 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(9): couple of small issues
On 17 лютого 2014 р. 12:08:09 GMT+02:00, Andriy Gapon wrote: > >I used to have mousechar_start="3" in my r.conf. To be honest I can >not even >recall why. But this worked fine with syscons without any glitches. >With vt I get the following during boot up: >vidcontrol: setting mouse character: Inappropriate ioctl for device >And mouse cursor is never drawn, apparently vidcontrol -m on -M >just fails. > >Looks like with syscons MOUSE_MOUSECHAR ioctl is handled by a terminal >device >and consolectl device while with vt it is handled only by sysmouse >device. > > >Another issue is that I see the following messages appearing during >boot and >from time to time afterwards in the system log: >kernel: sysmouse: unknown ioctl: t:40007413 >kernel: sysmouse: unknown ioctl: t:80007410 > >The ioctls seem to be TIOCFLUSH and TIOCGETA, so I am not sure why >sysmouse gets >involved. Maybe the same issue exists with syscons's sysmouse as well, >but it >is just silent about it. > >Seems like ioctls are called by X server. For example: >sysmouse_ioctl:entry > kernel`devfs_ioctl_f+0x11c > kernel`kern_ioctl+0x1db > kernel`sys_ioctl+0x142 > kernel`amd64_syscall+0x3c9 > kernel`0x8080e6db > > libc.so.7`ioctl+0xa > Xorg`xf86OpenSerial+0x221 > mouse_drv.so`MouseProc+0x2f3 > Xorg`EnableDevice+0x214 > Xorg`xf86Wakeup+0x57b > Xorg`WakeupHandler+0x42 > Xorg`WaitForSomething+0x317 > Xorg`Dispatch+0x92 > Xorg`main+0x475 > Xorg`_start+0x14f > >sysmouse_ioctl:entry > kernel`devfs_ioctl_f+0x11c > kernel`kern_ioctl+0x1db > kernel`sys_ioctl+0x142 > kernel`amd64_syscall+0x3c9 > kernel`0x8080e6db > > libc.so.7`ioctl+0xa > Xorg`xf86FlushInput+0x21 > mouse_drv.so`MouseProc+0x376 > Xorg`EnableDevice+0x214 > Xorg`xf86Wakeup+0x57b > Xorg`WakeupHandler+0x42 > Xorg`WaitForSomething+0x317 > Xorg`Dispatch+0x92 > Xorg`main+0x475 > Xorg`_start+0x14f > ld-elf.so.1`0x8007d5000 Hello Andriy! I remember we were discussed that problem before, can you please check if moused enabled (in rc.conf or by devd for USB mouse) and do you use Kern.vt.textmode (IIRC its name)? Mousecharstart is a first char of 4 to replace its bitmap with parts of mouse pointer. You can see its job by defining it to some of frequently used chars, then mouse pointer will be moved over many chars on the screen :-) About second question - there is no problem to just remove that warning, but think better to left it to make an idea for developers about what term ioctls doing with sysmuse devfs node. Thanks for testing! WBW -- Aleksandr Rybalko ___ 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: newcons comming
On Tue, 11 Feb 2014 10:51:26 +0100 Jean-Sébastien Pédron wrote: > 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 > Hi Jean! currently vt(9) do not blank screen on each vt switch. About your patch, think we will better malloc line size buffer (when VM become ready) to not trap into "slow read from video mem" problem. Before VM come up, we have only one screen blank and since modern system mostly use main memory, it will be viable only for devices with separate video memory and only at boot time (or even use wr4 before VM became ready). Thanks! WBW -- Aleksandr Rybalko ___ 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: newcons comming
Hi Adrian! On Mon, 10 Feb 2014 13:24:18 -0800 Adrian Chadd wrote: > [snip] > > My experiences with newcons/drm2: > > * suspend/resume occasionally throws up a panic in the softclock code, > with some vaguely invalid looking newcons timer entry. THis happens > after it comes out of suspend, after af ew seconds. It sucks and makes > things rather unusable. Are you have some data to investigate who is culprit? You can try also kernel with syscons, of course console will be black after kms load, but you still able to input commands. > * Occasionally a resume results in control not going back to xorg > correctly. I have to vt switch to vty0 and back to xorg yeah, dunno why, but xorg's framebuffer damaged in many cases, and not restored on resume. But how it is related to newcons? > * Occasionally the text drawing is garbage - the text cells are > correct (ie spaces where there's spaces, text where there's text) but > the character contents are totally different/garbage. I have to switch > vts to fix this. Can you please take a picture of that? I can't imaging it yet. :) It is related to previous paragraph or another issue? > > > -a Thanks for report Adrian! WBW -- Aleksandr Rybalko ___ 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"
[CFT] updated ofwfb driver vt(9)
Hello hackers!
I did updated version of vt's ofwfb driver, but have no HW to test.
It will be very nice if someone try it on ppc/sparc device.
Instructions on how to enable vt(9) (newcons) can be found here:
https://wiki.freebsd.org/Newcons
Patch to HEAD in attachment. (hope it will not be stripped)
xf86-video-scfb expected to work too :)
Many-many thanks!
WBW
--
Aleksandr Rybalko
Index: ofwfb.c
===
--- ofwfb.c (revision 260753)
+++ ofwfb.c (working copy)
@@ -30,8 +30,10 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
@@ -47,25 +49,19 @@
#include
struct ofwfb_softc {
+ struct fb_info info;
+
+ /* Own variables. */
phandle_t sc_node;
-
- intptr_t sc_addr;
- int sc_depth;
- int sc_stride;
-
- bus_space_tag_t sc_memt;
-
- uint32_t sc_colormap[16];
+ bus_space_tag_t sc_memt;
};
static vd_init_t ofwfb_init;
-static vd_blank_t ofwfb_blank;
-static vd_bitbltchr_t ofwfb_bitbltchr;
static const struct vt_driver vt_ofwfb_driver = {
.vd_init = ofwfb_init,
- .vd_blank = ofwfb_blank,
- .vd_bitbltchr = ofwfb_bitbltchr,
+ .vd_blank = vt_fb_blank,
+ .vd_bitbltchr = vt_fb_bitbltchr,
.vd_priority = VD_PRIORITY_GENERIC+1,
};
@@ -75,86 +71,8 @@
/* XXX: hardcoded max size */
static void
-ofwfb_blank(struct vt_device *vd, term_color_t color)
+ofwfb_initialize(struct ofwfb_softc *sc)
{
- struct ofwfb_softc *sc = vd->vd_softc;
- u_int ofs;
- uint32_t c;
-
- switch (sc->sc_depth) {
- case 8:
- for (ofs = 0; ofs < sc->sc_stride*vd->vd_height; ofs++)
- *(uint8_t *)(sc->sc_addr + ofs) = color;
- break;
- case 32:
- c = sc->sc_colormap[color];
- for (ofs = 0; ofs < sc->sc_stride*vd->vd_height; ofs++)
- *(uint32_t *)(sc->sc_addr + 4*ofs) = c;
- break;
- default:
- /* panic? */
- break;
- }
-}
-
-static void
-ofwfb_bitbltchr(struct vt_device *vd, const uint8_t *src, const uint8_t *mask,
-int bpl, vt_axis_t top, vt_axis_t left, unsigned int width,
-unsigned int height, term_color_t fg, term_color_t bg)
-{
- struct ofwfb_softc *sc = vd->vd_softc;
- u_long line;
- uint32_t fgc, bgc;
- int c;
- uint8_t b, m;
-
- fgc = sc->sc_colormap[fg];
- bgc = sc->sc_colormap[bg];
- b = m = 0;
-
- /* Don't try to put off screen pixels */
- if (((left + width) > vd->vd_width) || ((top + height) >
- vd->vd_height))
- return;
-
- line = (sc->sc_stride * top) + left * sc->sc_depth/8;
- for (; height > 0; height--) {
- for (c = 0; c < width; c++) {
- if (c % 8 == 0)
-b = *src++;
- else
-b <<= 1;
- if (mask != NULL) {
-if (c % 8 == 0)
- m = *mask++;
-else
- m <<= 1;
-/* Skip pixel write, if mask has no bit set. */
-if ((m & 0x80) == 0)
- continue;
- }
- switch(sc->sc_depth) {
- case 8:
-*(uint8_t *)(sc->sc_addr + line + c) =
-b & 0x80 ? fg : bg;
-break;
- case 32:
-*(uint32_t *)(sc->sc_addr + line + 4*c) =
-(b & 0x80) ? fgc : bgc;
-break;
- default:
-/* panic? */
-break;
- }
- }
- line += sc->sc_stride;
- }
-}
-
-static void
-ofwfb_initialize(struct vt_device *vd)
-{
- struct ofwfb_softc *sc = vd->vd_softc;
char name[64];
ihandle_t ih;
int i;
@@ -170,16 +88,16 @@
* Set up the color map
*/
- switch (sc->sc_depth) {
+ switch (sc->info.fb_bpp) {
case 8:
- vt_generate_vga_palette(sc->sc_colormap, COLOR_FORMAT_RGB, 255,
+ vt_generate_vga_palette(sc->info.fb_cmap, COLOR_FORMAT_RGB, 255,
0, 255, 8, 255, 16);
for (i = 0; i < 16; i++) {
OF_call_method("color!", ih, 4, 1,
- (cell_t)((sc->sc_colormap[i] >> 16) & 0xff),
- (cell_t)((sc->sc_colormap[i] >> 8) & 0xff),
- (cell_t)((sc->sc_colormap[i] >> 0) & 0xff),
+ (cell_t)((sc->info.fb_cmap[i] >> 16) & 0xff),
+ (cell_t)((sc->info.fb_cmap[i] >> 8) & 0xff),
+ (cell_t)((sc->info.fb_cmap[i] >> 0) & 0xff),
(cell_t)i, &retval);
}
break;
@@ -192,24 +110,22 @@
* endianness slightly different. Figure out the host-view
* endianness of the frame buffer.
*/
- oldpix = bus_space_read_4(sc->sc_memt, sc->sc_addr, 0);
- bus_space_write_4(sc->sc_memt, sc->sc_addr, 0, 0xff00);
- if (*(uint8_t *)(sc->sc_addr) == 0xff)
- vt_generate_vga_palette(sc->sc_colormap,
+ oldpix = bus_space_read_4(sc->sc_memt, sc->info.fb_vbase, 0);
+ bus_space_write_4(sc->sc_memt, sc->info.fb_vbase, 0, 0xff00);
+ if (*(uint8_t *)(sc->info.fb_vbase) == 0xff)
+ vt_generate_vga_palette(sc->info.fb_cmap,
COLOR_FORMAT_RGB, 255, 16, 255, 8, 255, 0);
else
- vt_generate_vga_palette(sc->sc_colormap,
+ vt_generate_vga_palette(sc->info.fb_cmap,
COLOR_FORMAT_RGB, 255, 0, 255, 8, 255, 16);
- bus_space_write_4(sc->sc_
Re: [CFT] xboxfb with vt(9) (a.k.a. newcons)
On Wed, 15 Jan 2014 23:35:39 + Ed Schouten wrote: > Hello there, > > On Wed Jan 15 2014 at 1:43:56 PM, Aleksandr Rybalko > wrote: > > > I've just committed update to xboxfb driver for vt(9). But I have > > no HW to test on. So if anybody have HW and time/wish to test it, > > please help me. > > > As I also mentioned to you privately, I think it might actually be > wiser to just drop Xbox support entirely. The Xbox support was a > funny thing back then, but I suspect it has actually outlived its > usefulness. > > The original Xbox only has a 733 MHz Celeron CPU, 64 MB of RAM and a > 10 GB harddisk. I don't think there are that many people left who > want to run FreeBSD 11 on it. > > Thoughts? > > Ed Hi folks! Ed, Raspberry-Pi has more RAM, almost same CPU clock and no HDD at all and people use it :) Since it already in HEAD I would prefer to left it here for some time. So other will be able to use it as example. But even for that better to know if it works, to not waste time of users or hackers who will try to use it. :) Thanks! WBW -- Aleksandr Rybalko ___ 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"
[CFT] xboxfb with vt(9) (a.k.a. newcons)
Hello friends! I've just committed update to xboxfb driver for vt(9). But I have no HW to test on. So if anybody have HW and time/wish to test it, please help me. What you need to do that: 1. Update sources to latest HEAD; 2. In XBOX kernel config file replace that devices: -device xboxfb -device sc -device fb with those: +device vt_xboxfb +device vt +device fbd 3. rebuild/reinstall your kernel. Thanks a lot! WBW -- Aleksandr Rybalko ___ 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: newcons(vt) can't work at Intel HD4400
On Fri, 03 Jan 2014 17:26:09 +0100 Claude Buisson wrote: > On 01/03/2014 16:27, 乔楚 wrote: > > As you said, it's used vesa driver, and error on drm. > > > > > > According to https://wiki.freebsd.org/Graphics, Haswell GPU are not > supported by FreeBSD DRM/KMS drivers. > > Claude Buisson > > > Right. Thank you Claude for comment. And thanks 乔楚 for report. (Not sure I use your name right way :) ) Anyway you should wait for vt(9) VESA driver or drm2 Haswell support, whatever come first. Thanks! WBW -- Aleksandr Rybalko ___ 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: newcons(vt) can't work at Intel HD4400
"乔楚" написав(ла): >Upgrade from ThinkPad x201i to ThinkPad E430C, newcons work well. >Video card is Intel HD4000. > >Upgrade from E430C to x240, newcons can;t work. >Video card is Intel HD4400. > >I can press Alt+Ctrl+F1 to switch tty1, but there only has one cursor >blinking, no other content. >I can press Alt_Ctrl+F7 to switch X. > >#uname -a >FreeBSD x201i.honestqiao.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 >r260159: Wed Jan 1 17:10:24 CST 2014 >r...@x201i.honestqiao.com:/usr/obj/usr/src/sys/HonestQiaoKernel11 >amd64 > >#pciconv -lv >vgapci0@pci0:0:2:0: class=0x03 card=0x221417aa chip=0x0a168086 >rev=0x09 hdr=0x00 >vendor = 'Intel Corporation' >device = 'Haswell-ULT Integrated Graphics Controller' >class = display >subclass = VGA > >#dmesg >vgapci0: port 0x4000-0x403f mem >0xf000-0xf03f,0xe000-0xefff irq 16 at device 2.0 on >pci0 >acpi_video0: on vgapci0 >found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head >#0 >vgapci0: Boot video device > >#kldstat >101 0x8131f000 7488 acpi_video.ko >171 0x81385000 6be8 acpi_ibm.ko >181 0x8138c000 d28 acpi_call.ko >331 0x81449000 5eff7i915kms.ko > >#sysctl -a >kern.vt.enable_altgr: 1 >kern.vt.debug: 0 >kern.vt.deadtimer: 15 >kern.vt.suspendswitch: 1 >device vt >device vt_vga >___ >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" Hi 乔楚, Can you please send dmesg and XOrg log to me? Think it is due XOrg use vesa driver, but not drm2. Thanks! WBW -- Aleksandr Rybalko ___ 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: newcons + device.hints
On Wed, 11 Dec 2013 14:10:32 +0400 "Vladimir A. Noskov" wrote: > > On 11.12.2013 14:06, Vladimir A. Noskov wrote: > Thanks. > I waiting set :) > > > > > On 11.12.2013 00:54, Ed Schouten wrote: > >> > >> Hey Vladimir, > >> > >> You'd better ask this question on the lists. I've added current@ > >> and ray@ to the cc. > >> > >> Thanks, > >> Ed > >> > >> Am 11.12.2013 03:09 schrieb "Vladimir A. Noskov" >> <mailto:woc...@hotbox.ru>>: > >> > >> Hello, Ed! > >> > >> I compiled FreeBSD nbw001 11.0-CURRENT FreeBSD 11.0-CURRENT # 0 > >> r259137: Tue Dec 10 02:57:07 MSK 2013 root @ nbw001 :/ > >> usr/obj/usr/home/wocson/devel/src.newcons/sys/W20131213 amd64 > >> This is my Toshiba laptop on CPU AMD E -450 : > >> > >> # Sysctl-a | egrep-i 'hw.machine | hw.model | hw.ncpu' > >> hw.machine: amd64 > >> hw.model: AMD E- 450 APU with Radeon (tm) HD Graphics > >> hw.ncpu: 2 > >> hw.machine_arch: amd64 > >> Radeon HD 6320 > >> > >> This kernel was launched in FreeBSD 10 Beta 4 (build 10 PCBSD > >> -Stable http://iso.cdn.pcbsd.org/10-STABLE/amd64/) > >> > >> Everything is working fine . > >> I have one question : Is it possible to install the OS at > >> startup console mode 1366x768px ? For sc was done editing > >> device.hints. hint.sc.0.at <http://hint.sc.0.at> = "isa" > >> hint.sc.0.flags = "0x180" > >> hint.sc.0.vesa_mode = "0x11b" > >> > >> If you need any more information I will inform you . > >> > >> Thank you. > >> > -- > > *Vladimir A. Noskov* > Hi! Sorry for such huge delay. Vladimir, things you have described with syscons hints related to VESA driver. But you can preload radeonkms/radeon firmware modules/drm2 in the loader(8), then drm_fb_helper (part of drm2) will initialize screen to display maximum resolution. Thanks! -- Aleksandr Rybalko ___ 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: [HEADS UP] xorg version switch in CURRENT
On 18.12.2013 01:27, Nathan Whitehorn wrote: > On 12/17/13 15:32, Aleksandr Rybalko wrote: >> On Tue, 17 Dec 2013 14:12:05 -0600 >> Nathan Whitehorn wrote: >> >>> On 12/17/13 14:07, Steve Kargl wrote: >>>> On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: >>>>> To get VT switching when using KMS drivers (ATI, Intel) please use >>>>> newcons: https://wiki.freebsd.org/Newcons or if that is not >>>>> possible, force the use of the vesa driver for xorg. >>>>> >>>> It appears that newcons is unusable with a static kernel. >>>> Adding 'device drm2' and 'device i915kms' to my kernel >>>> config results in a quick death to 'make buldkernel'. >>>> >>> You may not want it either. The radeon KMS driver, if loaded with >>> newcons before X, replaces your console with snow (or at least it did >>> the last time I tried it). >> Nathan, on which h/w you did that test? 3 different systems with Intel >> graphic works fine for me. > > This is on the following graphics card on amd64: > > vgapci0@pci0:3:0:0: class=0x03 card=0x10022f43 chip=0x95cc1002 > rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices [AMD] nee ATI' > device = 'RV620 [ATI FireGL V3700]' > > I'll run the test again today or tomorrow and see if it still happens. > -Nathan Please do. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] [patch] do not stop watchdog on shutdown
On Tue, 17 Dec 2013 14:03:43 -0800
Maksim Yevmenkin wrote:
> Hello Aleksandr
>
> >> would anyone object to this patch?
> >
> > It is good idea, but sometimes shutdown sequence longer than some
> > H/W watchdogs even support.
> > I have one board which can do only 20sec maximum time.
>
> yes. its up to the user to configure appropriate watchdog timeout.
> this features is mostly for "light-out" type of environments where
> remote hands are not easily available.
Totally agree :)
>
> thanks
> max
>
> >> Index: src/etc/rc.d/watchdogd
> >> ===
> >> --- src/etc/rc.d/watchdogd (revision 2999)
> >> +++ src/etc/rc.d/watchdogd (working copy)
> >> @@ -39,4 +39,7 @@
> >> pidfile="/var/run/${name}.pid"
> >>
> >> load_rc_config $name
> >> +
> >> +sig_stop="${watchdogd_sig_stop:-TERM}"
> >> +
> >> run_rc_command "$1"
> >> ___
--
Aleksandr Rybalko
___
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: [HEADS UP] xorg version switch in CURRENT
On Tue, 17 Dec 2013 12:07:56 -0800
Steve Kargl wrote:
> On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote:
> >
> > To get VT switching when using KMS drivers (ATI, Intel) please use
> > newcons: https://wiki.freebsd.org/Newcons or if that is not
> > possible, force the use of the vesa driver for xorg.
> >
>
> It appears that newcons is unusable with a static kernel.
> Adding 'device drm2' and 'device i915kms' to my kernel
> config results in a quick death to 'make buldkernel'.
Hi Steve!
Don't panic :)
drm2/i915kms/radeonkms can't be built as part of static kernel.
at least no definitions for that (sys/conf/files or sys/conf/files.
${ARCH} should contain instructions which modules to include).
and newcons is unrelated here :)
You can try it with just preload modules.
1. Build/install kernel with vt and vt_vga.
2. reboot and break in the loader.
3. do: load i915kms
4. do: boot
Have a nice day!
>
> --
> Steve
> ___
> 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"
WBW
--
Aleksandr Rybalko
___
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: [HEADS UP] xorg version switch in CURRENT
On Tue, 17 Dec 2013 14:12:05 -0600 Nathan Whitehorn wrote: > On 12/17/13 14:07, Steve Kargl wrote: > > On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: > >> To get VT switching when using KMS drivers (ATI, Intel) please use > >> newcons: https://wiki.freebsd.org/Newcons or if that is not > >> possible, force the use of the vesa driver for xorg. > >> > > It appears that newcons is unusable with a static kernel. > > Adding 'device drm2' and 'device i915kms' to my kernel > > config results in a quick death to 'make buldkernel'. > > > > You may not want it either. The radeon KMS driver, if loaded with > newcons before X, replaces your console with snow (or at least it did > the last time I tried it). Nathan, on which h/w you did that test? 3 different systems with Intel graphic works fine for me. > -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" -- Aleksandr Rybalko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] [patch] do not stop watchdog on shutdown
On Tue, 17 Dec 2013 10:53:02 -0800
Maksim Yevmenkin wrote:
> hello,
Hi Maksim!
>
> would anyone object to this patch?
It is good idea, but sometimes shutdown sequence longer than some H/W
watchdogs even support.
I have one board which can do only 20sec maximum time.
>
> max
>
> Index: src/etc/rc.d/watchdogd
> ===
> --- src/etc/rc.d/watchdogd (revision 2999)
> +++ src/etc/rc.d/watchdogd (working copy)
> @@ -39,4 +39,7 @@
> pidfile="/var/run/${name}.pid"
>
> load_rc_config $name
> +
> +sig_stop="${watchdogd_sig_stop:-TERM}"
> +
> run_rc_command "$1"
> ___
> 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"
--
Aleksandr Rybalko
___
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: r259286 panic
Hi guys!
I've investigate problem a bit. And can say that callout initialized with
callout_int(), w/o mpsafe flag:
callout_init(&vw->vw_proc_dead_timer, 0);
[sys/dev/vt/vt_core.c:1714]
And callout_init did not set CALLOUT_RETURNUNLOCKED flag, and assign it's
lock object to Giant, but where Giant lost on exit from callout I dunno :)
seems some bug somewhere much deep.
Eitan, do this 100% reproducible? If so, can you please try to replace
callout_init(&vw->vw_proc_dead_timer, 0);
with
callout_init(&vw->vw_proc_dead_timer, CALLOUT_MPSAFE);
at [sys/dev/vt/vt_core.c:1714] ?
Thanks!
2013/12/16 Alexander Motin
> On 15.12.2013 22:22, Eitan Adler wrote:
>
>> On Sun, Dec 15, 2013 at 3:23 AM, Eitan Adler
>> wrote:
>>
>>> FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r259286:
>>> Fri Dec 13 00:33:37 EST 2013
>>> eitan@gravity.local:/usr/obj/usr/src/sys/EADLER amd64
>>>
>>> Complete textdump here: http://people.freebsd.org/~
>>> eadler/files/core.txt.1
>>>
>>> My kernel is built with complete debug symbols, INVARIANTS, ddb, etc.
>>> but no WITNESS.
>>>
>>> I have vt and vt_vga enabled but not sc and vga (newcons, but not
>>> syscons).
>>>
>>
>>
>> Replying to myself with more data:
>>
>> gdb$ list kern_timeout.c
>> Can't find member of namespace, class, struct, or union named
>> "kern_timeout.c"
>> Hint: try 'kern_timeout.c or 'kern_timeout.c
>> (Note leading single quote.)
>> gdb$ list kern_timeout.c:700
>> 695 lastfunc = c_func;
>> 696 }
>> 697 #endif
>> 698 CTR1(KTR_CALLOUT, "callout %p finished", c);
>> 699 if ((c_flags & CALLOUT_RETURNUNLOCKED) == 0)
>> 700 class->lc_unlock(c_lock);
>> 701 skip:
>> 702 CC_LOCK(cc);
>> 703 KASSERT(cc->cc_exec_entity[direct].cc_curr == c,
>> ("mishandled cc_curr"));
>> 704 cc->cc_exec_entity[direct].cc_curr = NULL;
>> gdb$ p c
>> $1 = (struct callout *) 0x812121f8
>> gdb$ p *c
>> $2 = {
>>c_links = {
>> le = {
>>le_next = 0xfe0005f00318,
>>le_prev = 0x813aa690
>> },
>> sle = {
>>sle_next = 0xfe0005f00318
>> },
>> tqe = {
>>tqe_next = 0xfe0005f00318,
>>tqe_prev = 0x813aa690
>> }
>>},
>>c_time = 0x2c0d9170f2f51,
>>c_precision = 0xeeea,
>>c_arg = 0x81212148,
>>c_func = 0x8067e6e0 ,
>>c_lock = 0x0,
>>c_flags = 0x80,
>>c_cpu = 0x0
>> }
>>
>>
>> From the 'vt_switch_timer' function it appears that something is wrong
>> with vt.
>>
>>
>> In addition avg@ mentioned that he wonders why class->lc_lock(c_lock,
>> ...) is protected by if (c_lock != NULL) but class->lc_unlock(c_lock)
>> does not have that guard.
>>
>
> It worked so far because callout_init() sets CALLOUT_RETURNUNLOCKED flag
> if there is no callout lock. I am not sure whether we should better add
> check or assertion to _callout_init_lock().
>
> So either VT passes something odd/NULL pointer to callout_init_mtx(), or
> something overwrites the callout structure after scheduling the callout.
>
> --
> Alexander Motin
>
--
WBW
---
Rybalko Aleksandr
aka Alex RAY
D-Link.ua
___
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 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
"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. Yep, committed in r259179. Thanks! WBW -- Aleksandr Rybalko ___ 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 commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
On Mon, 9 Dec 2013 19:48:44 +0200 Markiyan Kushnir wrote: > 2013/12/9 Aleksandr Rybalko : > > On Mon, 9 Dec 2013 10:59:14 +0200 > > Markiyan Kushnir wrote: > > > >> Hello, > >> > >> I'm on rev. 259102 and hitting drm not being able to attach to fbd > >> device at X startup (X freezing). > >> > >> Attaching /var/log/messages, pciconf output and kern.conftxt. > >> Please let me know if there is something I'm missing here. Posting > >> in this thread since I thought it might be relevant to this commit? > >> > >> Thanks, > >> Markiyan > >> > >> > >> 2013/12/8 Marc UBM : > >> > Hiho! :-) > >> > > >> > Thanks a lot for working on this! > >> > > >> > As soon as X is started, things work fine. Before that (as soon > >> > as vt is initialized after the boot menu), output on all ttys is > >> > flickering, resolution is at 640x480 (guessing here) and > >> > changing anything via vidcontrol fails with "inappropriate ioctl > >> > for device". Also, screen output starts overlapping, but a > >> > "clear" command fixes that temporarily. The "Alt-Gr" key does > >> > nothing, manually entering ascii keycodes via alt+number (e.g. > >> > alt-124 for |) works. > >> > > >> > Relevant pciconf output: > >> > > >> > vgapci0@pci0:0:2:0: class=0x03 card=0x40011297 > >> > chip=0x2e328086 rev=0x03 hdr=0x00 vendor = 'Intel > >> > Corporation' device = '4 Series Chipset Integrated Graphics > >> > Controller' class = display > >> > subclass = VGA > >> > > >> > vgapci1@pci0:0:2:1: class=0x038000 card=0x40011297 > >> > chip=0x2e338086 rev=0x03 hdr=0x00 vendor = 'Intel > >> > Corporation' device = '4 Series Chipset Integrated Graphics > >> > Controller' class = display > >> > > >> > Best regards, > >> > Marc > >> > > >> > > > [[CUT]] > >> > > >> > > >> > -- > >> > Marc "UBM" Bocklet > >> > ___ > >> > 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" > > > > Hi Markiyan! > > > > According to attached kernel config you run system with syscons > > (device sc). > > > > If you want to test it with vt (newcons), follow instructions on the > > wiki page. > > https://wiki.freebsd.org/Newcons > > > > Ah, thanks! I'll give it a try. I simply was curious of testing X > running on a Radeon card on CURRENT. Testing vt is a bit different > thing, and I will try it separately as well. Yet how about this error > with drm_fb_helper_single_fb_probe? Does it mean I cannot use the old > sc and vga devices now? 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). > > > > > Thanks. > > > > WBW > > -- > > Aleksandr Rybalko Thanks! -- Aleksandr Rybalko ___ 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 with -CURRENT @Boot [r259130]
On Mon, 9 Dec 2013 10:36:34 -0600 Larry Rosenman wrote: > > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 259130 > Node Kind: directory > Schedule: normal > Last Changed Author: ray > Last Changed Rev: 259130 > Last Changed Date: 2013-12-09 09:28:34 -0600 (Mon, 09 Dec 2013) > [[cut]] Can you please share core and kernel with modules. I'm not sure, but looks like it is related to vt (newcons). So I have to investigate. Thanks! WBW -- Aleksandr Rybalko ___ 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 commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
On Sun, 8 Dec 2013 16:36:10 +0100 Marc UBM wrote: > Hiho! :-) > > Thanks a lot for working on this! > > As soon as X is started, things work fine. Before that (as soon as vt > is initialized after the boot menu), output on all ttys is flickering, > resolution is at 640x480 (guessing here) and changing anything via > vidcontrol fails with "inappropriate ioctl for device". Also, screen > output starts overlapping, but a "clear" command fixes that > temporarily. The "Alt-Gr" key does nothing, manually entering ascii > keycodes via alt+number (e.g. alt-124 for |) works. > > Relevant pciconf output: > > vgapci0@pci0:0:2:0: class=0x03 card=0x40011297 chip=0x2e328086 > rev=0x03 hdr=0x00 vendor = 'Intel Corporation' > device = '4 Series Chipset Integrated Graphics Controller' > class = display > subclass = VGA > > vgapci1@pci0:0:2:1: class=0x038000 card=0x40011297 chip=0x2e338086 > rev=0x03 hdr=0x00 vendor = 'Intel Corporation' > device = '4 Series Chipset Integrated Graphics Controller' > class = display > > Best regards, > Marc > > > > > -- > Marc "UBM" Bocklet > ___ > 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" Hi Marc, yeah I seen same at the test board vgapci0@pci0:0:2:0: class=0x03 card=0x00368086 chip=0x00428086 First thought was about firmware(BIOS) bug related to VGA graphic mode. Are your board made by Intel too (mine is INTEL DH55HC)? WBW -- Aleksandr Rybalko ___ 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: [Newcons] EDID message every second or 2?
On Sat, 07 Dec 2013 18:12:03 -0600 Larry Rosenman wrote: > On 2013-12-07 18:07, Aleksandr Rybalko wrote: > > > > > Hi Larry, > > > > Looks like you have display with broken info block (a.k.a. EDID). > > That message come from drm2 code, so you can to try to remove DRM > > debug flag from kernel config (if it there). > > > > Otherwise we have to find way to preload correct EDID. XOrg able to do > > that, but we still no, IIRC. > > > > Thanks! > > WBW > > -- > > Aleksandr Rybalko > I don't see a DRM debug flag in GENERIC or my config. > > Ideas? > > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org > US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 Hi again Larry! :) Looks like your problem fixed in r259104 by Jean (dumbbell) today. So you can try to update and rebuild. WBW -- Aleksandr Rybalko ___ 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 commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
On Mon, 9 Dec 2013 10:59:14 +0200 Markiyan Kushnir wrote: > Hello, > > I'm on rev. 259102 and hitting drm not being able to attach to fbd > device at X startup (X freezing). > > Attaching /var/log/messages, pciconf output and kern.conftxt. Please > let me know if there is something I'm missing here. Posting in this > thread since I thought it might be relevant to this commit? > > Thanks, > Markiyan > > > 2013/12/8 Marc UBM : > > Hiho! :-) > > > > Thanks a lot for working on this! > > > > As soon as X is started, things work fine. Before that (as soon as vt > > is initialized after the boot menu), output on all ttys is flickering, > > resolution is at 640x480 (guessing here) and changing anything via > > vidcontrol fails with "inappropriate ioctl for device". Also, screen > > output starts overlapping, but a "clear" command fixes that > > temporarily. The "Alt-Gr" key does nothing, manually entering ascii > > keycodes via alt+number (e.g. alt-124 for |) works. > > > > Relevant pciconf output: > > > > vgapci0@pci0:0:2:0: class=0x03 card=0x40011297 chip=0x2e328086 > > rev=0x03 hdr=0x00 vendor = 'Intel Corporation' > > device = '4 Series Chipset Integrated Graphics Controller' > > class = display > > subclass = VGA > > > > vgapci1@pci0:0:2:1: class=0x038000 card=0x40011297 chip=0x2e338086 > > rev=0x03 hdr=0x00 vendor = 'Intel Corporation' > > device = '4 Series Chipset Integrated Graphics Controller' > > class = display > > > > Best regards, > > Marc > > > > [[CUT]] > > > > > > -- > > Marc "UBM" Bocklet > > ___ > > 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" Hi Markiyan! According to attached kernel config you run system with syscons (device sc). If you want to test it with vt (newcons), follow instructions on the wiki page. https://wiki.freebsd.org/Newcons Thanks. WBW -- Aleksandr Rybalko ___ 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: [R259114/Newcons] Compile failure
On Sun, 8 Dec 2013 21:05:47 -0600 Larry Rosenman wrote: > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables > -ffreestanding -fno-strict-overflow -fstack-protector -Werror > /usr/src/sys/dev/vt/vt_core.c > /usr/src/sys/dev/vt/vt_core.c:1313:9: error: implicit declaration of function > 'IOCPARM_IVAL' is invalid in C99 [-Werror,-Wimplicit-function-declaration] > ival = IOCPARM_IVAL(data); >^ > 1 error generated. > *** Error code 1 > > Stop. > make[2]: stopped in /usr/obj/usr/src/sys/BORG-DTRACE > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > ^C > [1] Done(1) nohup make -DNO_CLEAN buildworld buildkernel > >>make.noc.out 2>&1 > # svn up > Updating '.': > At revision 259114. > # svn info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 259114 > Node Kind: directory > Schedule: normal > Last Changed Author: alfred > Last Changed Rev: 259114 > Last Changed Date: 2013-12-08 20:06:52 -0600 (Sun, 08 Dec 2013) > > # > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org > US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Hello Larry! It is now fixed (r259130). Thanks a lot! WBW -- Aleksandr Rybalko --- Begin Message --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fno-strict-overflow -fstack-protector -Werror /usr/src/sys/dev/vt/vt_core.c /usr/src/sys/dev/vt/vt_core.c:1313:9: error: implicit declaration of function 'IOCPARM_IVAL' is invalid in C99 [-Werror,-Wimplicit-function-declaration] ival = IOCPARM_IVAL(data); ^ 1 error generated. *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/BORG-DTRACE *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src ^C [1] Done(1) nohup make -DNO_CLEAN buildworld buildkernel >>make.noc.out 2>&1 # svn up Updating '.': At revision 259114. # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 259114 Node Kind: directory Schedule: normal Last Changed Author: alfred Last Changed Rev: 259114 Last Changed Date: 2013-12-08 20:06:52 -0600 (Sun, 08 Dec 2013) # -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" --- End Message --- ___ 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: [Newcons] EDID message every second or 2?
;info: [drm] Initialized radeon 2.29.0 20080528 >isab0: at device 31.0 on pci0 >isa0: on isab0 >atapci0: port >0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on >pci0 >ata0: at channel 0 on atapci0 >ahci0: port >0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f >mem 0xd9600800-0xd9600bff irq 19 at device 31.2 on pci0 >ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported >ahcich0: at channel 0 on ahci0 >ahcich1: at channel 1 on ahci0 >ahcich2: at channel 2 on ahci0 >ahcich3: at channel 3 on ahci0 >ahcich4: at channel 4 on ahci0 >ahcich5: at channel 5 on ahci0 >ichsmb0: port >0x1100-0x111f irq 19 at device 31.3 on pci0 >smbus0: on ichsmb0 >acpi_button0: on acpi0 >ipmi0: port 0xca2-0xca3 on acpi0 >ipmi0: KCS mode found at io 0xca2 on acpi >atkbdc0: port 0x60,0x64 irq 1 on acpi0 >atkbd0: irq 1 on atkbdc0 >kbd0 at atkbd0 >atkbd0: [GIANT-LOCKED] >psm0: irq 12 on atkbdc0 >psm0: [GIANT-LOCKED] >psm0: model IntelliMouse Explorer, device ID 4 >uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on >acpi0 >fd0: <1440-KB 3.5" drive> on fdc0 drive 0 >ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 >ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode >ppc0: FIFO with 16/16/9 bytes threshold >ppbus0: on ppc0 >lpt0: on ppbus0 >lpt0: Interrupt-driven port >ppi0: on ppbus0 >ichwd0 on isa0 >orm0: at iomem 0xc-0xcafff on isa0 >coretemp0: on cpu0 >est0: on cpu0 >p4tcc0: on cpu0 >coretemp1: on cpu1 >est1: on cpu1 >p4tcc1: on cpu1 >coretemp2: on cpu2 >est2: on cpu2 >p4tcc2: on cpu2 >coretemp3: on cpu3 >est3: on cpu3 >p4tcc3: on cpu3 >coretemp4: on cpu4 >est4: on cpu4 >p4tcc4: on cpu4 >coretemp5: on cpu5 >est5: on cpu5 >p4tcc5: on cpu5 >coretemp6: on cpu6 >est6: on cpu6 >p4tcc6: on cpu6 >coretemp7: on cpu7 >est7: on cpu7 >p4tcc7: on cpu7 >ZFS filesystem version: 5 >ZFS storage pool version: features support (5000) >Timecounters tick every 1.000 msec >vboxdrv: fAsync=0 offMin=0x3bf offMax=0x501 >hdacc0: at cad 0 on hdac0 >hdaa0: at nid 1 on hdacc0 >pcm1: at nid 4 on hdaa0 >pcm2: at nid 5 on hdaa0 >random: unblocking device. >usbus0: 12Mbps Full Speed USB v1.0 >usbus1: 12Mbps Full Speed USB v1.0 >usbus2: 12Mbps Full Speed USB v1.0 >usbus3: 480Mbps High Speed USB v2.0 >ugen3.1: at usbus3 >uhub0: on >usbus3 >ugen2.1: at usbus2 >uhub1: on >usbus2 >ugen1.1: at usbus1 >uhub2: on >usbus1 >ugen0.1: at usbus0 >uhub3: on >usbus0 >ipmi0: IPMI device rev. 1, firmware rev. 1.64, version 2.0 >ata0: DMA limited to UDMA33, controller found non-ATA66 cable >ipmi0: Number of channels 8 >ipmi0: Attached watchdog >uhub2: 2 ports with 2 removable, self powered >uhub1: 2 ports with 2 removable, self powered >uhub3: 2 ports with 2 removable, self powered >ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 >ada0: ATA-8 SATA 3.x device >ada0: Serial Number 5YD6FPLG >ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >ada0: quirks=0x1<4K> >ada0: Previously was known as ad4 >ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 >ada1: ATA-8 SATA 3.x device >ada1: Serial Number 5YDA1ZL4 >ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >ada1: quirks=0x1<4K> >ada1: Previously was known as ad6 >ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 >ada2: ATA-8 SATA 3.x device >ada2: Serial Number 5YDA3PC5 >ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >ada2: quirks=0x1<4K> >ada2: Previously was known as ad8 >ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 >ada3: ATA-8 SATA 3.x device >ada3: Serial Number 5YD9Y0P4 >ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >ada3: quirks=0x1<4K> >ada3: Previously was known as ad10 >ada4 at ahcich4 bus 0 scbus5 target 0 lun 0 >ada4: ATA-8 SATA 3.x device >ada4: Serial Number 5YDA1R5W >ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >ada4: quirks=0x1<4K> >ada4: Previously was known as ad12 >ada5 at ahcich5 bus 0 scbus6 target 0 lun 0 >ada5: ATA-8 SATA 3.x device >ada5: Serial Number 5YD5RBS8 >ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >ada
Re: newcons comming
On Sat, 26 Oct 2013 15:37:25 -0400 Sean Bruno wrote: > On Sat, 2013-10-26 at 22:32 +0300, Aleksandr Rybalko wrote: > > On Sat, 26 Oct 2013 10:45:32 +0200 > > d...@gmx.com wrote: > > > > > Suppose that Newcons gets in quickly. I use a Radeon 9600 card. Will > > > I see something useful on my screen (with KMS and the new Xorg and > > > things like that), or will my screen be black? > > > > Yup, you will get normal virtual terminal, but a bit bigger than > > 640x480. It is main reason why x11 team ask me to merge newcons ASAP. > > Newcons can use framebuffer provided by DRM. > > > > Try it yourself. > > > > WBW > > > So, I'm running NEW Xorg now and KMS with an NVidia card. What should I > do to test this? What are the expected results? > > sean Spend several hours to try to bring nvidia unit in my laptop. But it is "Optimus". It looks like working, but both output show same picture :))) And this is right-side of desktop (if you run xorg) :) So I can't answer your question yet. Think we have to ask nvidia to share some info on how to call their KMS inside kernel (not via /dev/card/dri node). WBW -- Aleksandr Rybalko ___ 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: newcons comming
On Sat, 26 Oct 2013 00:49:10 +0800 Julian Elischer wrote: > On 10/25/13 9:29 PM, Adrian Chadd wrote: > > Erm, I don't think this is really ready for -HEAD yet? > > certainly not ready for 10.. > but that doesn't mean it can not be in 10.1 > the existing console will still be there as default, and if this > truely is a big step forward, people will start using it in 10.1 and > it can be in 11 as a default. Yeah! Stability is more important than new features. (and I found one more bug rising on some load :-D) So ray leaving race. :) Thanks for comments! > > I think it's too late for this to be in 10.0 > > > > > > > > -adrian > > > > > > > > On 25 October 2013 06:04, Aleksandr Rybalko wrote: > > > >> On Fri, 25 Oct 2013 15:18:47 +0300 > >> Aleksandr Rybalko wrote: > >> > >>> Hello fellow hackers! > >>> > >>> I finally reach the point when I can work with newcons instead of > >>> syscons on my laptop. Yes, I know it still buggy and have a lot of > >>> style(9) problems. But we really have to get it into HEAD and 10.0 to > >>> enable shiny new Xorg features, drivers, etc. > >>> > >>> So I ask everyone to look "hard" into that[1] and tell me your opinion. > >>> I expect a lot of opinions, since it have to affect almost all good > >>> guys, as result I have to ask to split "bug reports" into two parts: > >>> 1. Should be done before merge to 10.0; > >>> 2. Can be done later. > >>> > >>> If it possible, please do it(review - report) ASAP. > >>> I have plan to done it that way: > >>> 1. Merge newcons to head (in a few days); > >>> 2. Fix a lot of reported bugs (2 hrs :-D ); > >>> 3. Persuade re@ about we need it in 10.0 (one week, maybe two); > >>> 4. Merge to 10.0; > >>> 5. One year AFK somewhere on Bahamas;^W^W^W^W^W^W^W > >>> 5. Add mouse cut-paste support; > >>> 6. Fix new bugs; > >>> 7. Some drinks. > >>> > >>> What do we will have with newcons: > >>> * (Think it is main) Allow us to switch to fresh Xorg, which require > >>> KMS. > >>> * Graphic devices which can provide framebuffer access can be easily > >>> used as virtual terminals (someone may have pixel-LCD on front of PC > >>> tower, may found it useful :-D ) > >>> * See [2]. > >>> > >>> TODO: > >>> * Lack of key mapping files, everyone can help with that using > >>> instructions on [3]; > >>> * A bit slow (mostly scrolling affected). > >>> * Other bugs :) > >>> * See [2]. > >>> > >>> Thanks! > >>> > >>> [1] - http://svnweb.freebsd.org/base/user/ed/newcons/ > >>> [2] - > >>> > >> http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Continuation-of-the-Newcons-Project > >>> [3] - > >>> > >> http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html > >>> Hope you will love newcons! > >>> And maybe me too :) > >>> > >>> WBW > >>> -- > >>> Aleksandr Rybalko > >> Forget to give a patch to HEAD, here it is: > >> > >> > >> http://people.freebsd.org/~ray/newcons/newcons_to_head_r257107_2013-10-25_1542.diff.gz > >> > >> Thanks to all! > >> > >> WBW > >> -- > >> Aleksandr Rybalko > >> ___ > >> 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" > > > -- Aleksandr Rybalko ___ 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: newcons comming
On Fri, 25 Oct 2013 11:55:26 -0700 Adrian Chadd wrote: > I think the best thing to do is address kib's issues and whatever > else pops up in the review, then add it into -HEAD as the non-default > console type. > > What I'd hate to see is some build time dependency where xorg > _requires_ you to run newcons in order to run X. Well, at least just > right now. > > I have a whole bunch of older hardware that I won't have access to > for a couple more weeks (old netbooks, thinkpads, etc) that I'd like > to run newcons and the latest xorg builds on, just to make sure we > haven't broken things for stuff circa 2005-2006. There's still a lot > of that stuff out there and right now xorg+console works fine for > those. Ok awaiting for report how it run on your old boxes :) > > Thanks, > > > > -adrian > > > > On 25 October 2013 07:18, Aleksandr Rybalko wrote: > > > On Fri, 25 Oct 2013 15:10:44 +0100 > > symbol...@gmx.com wrote: > > > > > On Fri, Oct 25, 2013 at 06:43:54AM -0700, Adrian Chadd wrote: > > > > 3) Realise it's not yet ready for 10.0 or HEAD, and target it > > > > to be > > ready > > > > for MFC for a 10.1 release. > > > > 4) Delay 10.0 until this has matured enough in HEAD, then > > > > release it. > > > > > > > > I really want to see more updated xorg support but the timing > > > > of it all feels a little overly rushed for a 10.0 release > > > > target. > > > > > > > > What do others think? > > > > > > > > > > FWIW, I'm really looking forward to newcons but I don't think it > > > should be rushed into a release. (3) Seems prudent. > > > > Anyway it is optional. > > > > s/device vt/#device vt/ > > s/#device sc/device sc/ > > > > and you in the old, well known world :) > > > > > > > > --sym > > > ___ > > > 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" > > > > > > -- > > Aleksandr Rybalko > > ___ > > 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" > > -- Aleksandr Rybalko ___ 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: newcons comming
On Fri, 25 Oct 2013 18:46:02 +0300 Konstantin Belousov wrote: > On Fri, Oct 25, 2013 at 04:04:10PM +0300, Aleksandr Rybalko wrote: > > On Fri, 25 Oct 2013 15:18:47 +0300 > > Aleksandr Rybalko wrote: > > > > > Hello fellow hackers! > > > > > > I finally reach the point when I can work with newcons instead of > > > syscons on my laptop. Yes, I know it still buggy and have a lot of > > > style(9) problems. But we really have to get it into HEAD and > > > 10.0 to enable shiny new Xorg features, drivers, etc. > > > > > > So I ask everyone to look "hard" into that[1] and tell me your > > > opinion. I expect a lot of opinions, since it have to affect > > > almost all good guys, as result I have to ask to split "bug > > > reports" into two parts: > > > 1. Should be done before merge to 10.0; > > > 2. Can be done later. > > > > > > If it possible, please do it(review - report) ASAP. > > > I have plan to done it that way: > > > 1. Merge newcons to head (in a few days); > > > 2. Fix a lot of reported bugs (2 hrs :-D ); > > > 3. Persuade re@ about we need it in 10.0 (one week, maybe two); > > > 4. Merge to 10.0; > > > 5. One year AFK somewhere on Bahamas;^W^W^W^W^W^W^W > > > 5. Add mouse cut-paste support; > > > 6. Fix new bugs; > > > 7. Some drinks. > > > > > > What do we will have with newcons: > > > * (Think it is main) Allow us to switch to fresh Xorg, which > > > require KMS. > > > * Graphic devices which can provide framebuffer access can be > > > easily used as virtual terminals (someone may have pixel-LCD on > > > front of PC tower, may found it useful :-D ) > > > * See [2]. > > > > > > TODO: > > > * Lack of key mapping files, everyone can help with that using > > > instructions on [3]; > > > * A bit slow (mostly scrolling affected). > > > * Other bugs :) > > > * See [2]. > > > > > > Thanks! > > > > > > [1] - http://svnweb.freebsd.org/base/user/ed/newcons/ > > > [2] - > > > http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Continuation-of-the-Newcons-Project > > > [3] - > > > http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html > > > > > > Hope you will love newcons! > > > And maybe me too :) > > > > > > WBW > > > -- > > > Aleksandr Rybalko > > > > Forget to give a patch to HEAD, here it is: > > > > http://people.freebsd.org/~ray/newcons/newcons_to_head_r257107_2013-10-25_1542.diff.gz > > Was the code reviewed by anybody ? Was technical reviewer assigned by > the project sponsor ? Yes, technical reviewer assigned, but project code is not reviewed yet. That why I'm not commit it to HEAD right now :) I will cleanup it few days, then will ask for review and do CFT call too. > > I looked very quickly over the whole patch, I only enumerate the > things that catched my eye: > > dev/vt/hw/intel.c is sort of joke, it should be removed. It is more than joke! :) Leftover from old project. I've already remove it after your notice. > > I am very suspicious to what you do in the drm_fb_helper.c with > enqueuing, but I need to do much more reading of the code to say > something definitive. I think you mean use of EVENTHANDLER. Describe a little why it here first: Since some time both VTs must be present (syscons and newcons), but framebuffer born inside drm2 module, I have to make it completely independent from presence of newcons. Few days ago I already collect some opinions in that case. And "public opinion" give me answer - "best to use newbus here", but I recall more simple way - EVENTHANDLER. I did implement it. Later, I found more and more argument that points to newbus. F.e.: after suspend it Xorg draws better if machine suspend/resume in terminal(Xorg on inactive terminal), it is just because Xorg after resume gets notification about activation of its terminal window, so it redraw screen. So I have to use newbus's _suspend/_resume to notify clients. > > Intel GPU might provide relatively wide range of the pixel formats, I > do not see a code to parse and use these formats. Yes, but nobody use anything than RGB+ARGB, maybe with exception of TV output. Newcons's have infrastructure support for that, so required format can be easily added. > > Overall code looks relatively self-contained, so I think you indeed > might merge it to head after some public testing and review. But I > very much doubt that 10.0 is feasible for any efforts. Ok, lets do everything sane, then to decide :) Looks like I can even make it coexistent with syscons, so if user load KMS enabled module, newcons will attach over syscons. Think it is good way to HEAD users/developers to see what happen on xorg crash. So no rush, just work. :) Many thanks for opinion! WBW -- Aleksandr Rybalko ___ 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: newcons comming
On Fri, 25 Oct 2013 20:52:27 +0400 Andrey Fesenko wrote: > On Fri, Oct 25, 2013 at 4:18 PM, Aleksandr Rybalko > wrote: > > Hello fellow hackers! > > > > I finally reach the point when I can work with newcons instead of > > syscons on my laptop. Yes, I know it still buggy and have a lot of > > ... > > Yes, it's build and work Nice > > # uname -a > FreeBSD x220.local 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r257111M: Fri > Oct 25 19:27:50 MSK 2013 > andrey@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64 > > :) > > In the single user ugly > Can not read termcap database: > Using dumb terminal settings termcap is out of newcons's care :) > > In the multy user mode: > > Switch Xorg to consol and back is correct. > > spam log > % tail /var/log/messages > Oct 25 20:47:29 x220 kernel: [drm:pid1444:drm_ioctl] pid=1444, > cmd=0xc0086457, nr=0x57, dev 0xf80006682800, auth=1 > Oct 25 20:47:29 x220 kernel: [drm:pid1444:drm_ioctl] pid=1444, > cmd=0x20006458, nr=0x58, dev 0xf80006682800, auth=1 > Oct 25 20:47:29 x220 last message repeated 5 times > Oct 25 20:47:29 x220 kernel: [drm:pid1444:drm_ioctl] pid=1444, > cmd=0x800c645f, nr=0x5f, dev 0xf80006682800, auth=1 > Oct 25 20:47:29 x220 kernel: [drm:pid1444:drm_ioctl] pid=1444, > cmd=0x8020645d, nr=0x5d, dev 0xf80006682800, auth=1 > Oct 25 20:47:29 x220 kernel: [drm:pid1444:drm_ioctl] pid=1444, > cmd=0x80406469, nr=0x69, dev 0xf80006682800, auth=1 > Oct 25 20:47:29 x220 kernel: [drm:pid1444:i915_gem_execbuffer2] > buffers_ptr 80340a400 buffer_count 2 len 0058 > Oct 25 20:47:29 x220 kernel: [drm:pid1444:drm_ioctl] pid=1444, > cmd=0x800c645f, nr=0x5f, dev 0xf80006682800, auth=1 > Oct 25 20:47:29 x220 kernel: [drm:pid1444:drm_ioctl] pid=1444, > cmd=0xc0086457, nr=0x57, dev 0xf80006682800, auth=1 > Oct 25 20:47:29 x220 kernel: [drm:pid1444:drm_ioctl] pid=1444, > cmd=0x20006458, nr=0x58, dev 0xf80006682800, auth=1 Turn off DRM_DEBUG option in kernel config. > > In the console login jumps up, but it works correctly. If ScrlLk > console blink. Thanks! WBW -- Aleksandr Rybalko ___ 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: newcons comming
On Sat, 26 Oct 2013 10:45:32 +0200 d...@gmx.com wrote: > Suppose that Newcons gets in quickly. I use a Radeon 9600 card. Will > I see something useful on my screen (with KMS and the new Xorg and > things like that), or will my screen be black? Yup, you will get normal virtual terminal, but a bit bigger than 640x480. It is main reason why x11 team ask me to merge newcons ASAP. Newcons can use framebuffer provided by DRM. Try it yourself. WBW -- Aleksandr Rybalko ___ 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: newcons comming
On Fri, 25 Oct 2013 16:27:49 +0200 Tijl Coosemans wrote: > On Fri, 25 Oct 2013 17:18:15 +0300 Aleksandr Rybalko wrote: > > On Fri, 25 Oct 2013 15:10:44 +0100 symbol...@gmx.com wrote: > >> On Fri, Oct 25, 2013 at 06:43:54AM -0700, Adrian Chadd wrote: > >>> 3) Realise it's not yet ready for 10.0 or HEAD, and target it to be ready > >>> for MFC for a 10.1 release. > >>> 4) Delay 10.0 until this has matured enough in HEAD, then release it. > >>> > >>> I really want to see more updated xorg support but the timing of it all > >>> feels a little overly rushed for a 10.0 release target. > >>> > >>> What do others think? > >> > >> FWIW, I'm really looking forward to newcons but I don't think it should > >> be rushed into a release. (3) Seems prudent. > > > > Anyway it is optional. > > > > s/device vt/#device vt/ > > s/#device sc/device sc/ > > > > and you in the old, well known world :) > > I think you need to remove the kernel config changes from the patch > and keep syscons the default for now. There's no problem with putting > experimental code in HEAD but it can't be the default from day 1. Yeah, exact, it is enabled in patch just for easy testing. Thanks! WBW -- Aleksandr Rybalko ___ 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: newcons comming
On Fri, 25 Oct 2013 15:10:44 +0100 symbol...@gmx.com wrote: > On Fri, Oct 25, 2013 at 06:43:54AM -0700, Adrian Chadd wrote: > > 3) Realise it's not yet ready for 10.0 or HEAD, and target it to be ready > > for MFC for a 10.1 release. > > 4) Delay 10.0 until this has matured enough in HEAD, then release it. > > > > I really want to see more updated xorg support but the timing of it all > > feels a little overly rushed for a 10.0 release target. > > > > What do others think? > > > > FWIW, I'm really looking forward to newcons but I don't think it should > be rushed into a release. (3) Seems prudent. Anyway it is optional. s/device vt/#device vt/ s/#device sc/device sc/ and you in the old, well known world :) > > --sym > ___ > 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" -- Aleksandr Rybalko ___ 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: newcons comming
On Fri, 25 Oct 2013 06:29:37 -0700 Adrian Chadd wrote: > Erm, I don't think this is really ready for -HEAD yet? > Lets do it "really ready" :))) I'am free on that, I can merge or not merge it to 10.0. But x11 team depend on newcons presence, otherwise no new Xorg, no KMS drivers, no new cairo (IIRC), no new .. So we have two way: 1. delay it to 11.0 2. make it ready to 10.0 Select one you like more! :) Thanks! > > > -adrian > > > > On 25 October 2013 06:04, Aleksandr Rybalko wrote: > > > On Fri, 25 Oct 2013 15:18:47 +0300 > > Aleksandr Rybalko wrote: > > > > > Hello fellow hackers! > > > > > > I finally reach the point when I can work with newcons instead of > > > syscons on my laptop. Yes, I know it still buggy and have a lot of > > > style(9) problems. But we really have to get it into HEAD and 10.0 to > > > enable shiny new Xorg features, drivers, etc. > > > > > > So I ask everyone to look "hard" into that[1] and tell me your opinion. > > > I expect a lot of opinions, since it have to affect almost all good > > > guys, as result I have to ask to split "bug reports" into two parts: > > > 1. Should be done before merge to 10.0; > > > 2. Can be done later. > > > > > > If it possible, please do it(review - report) ASAP. > > > I have plan to done it that way: > > > 1. Merge newcons to head (in a few days); > > > 2. Fix a lot of reported bugs (2 hrs :-D ); > > > 3. Persuade re@ about we need it in 10.0 (one week, maybe two); > > > 4. Merge to 10.0; > > > 5. One year AFK somewhere on Bahamas;^W^W^W^W^W^W^W > > > 5. Add mouse cut-paste support; > > > 6. Fix new bugs; > > > 7. Some drinks. > > > > > > What do we will have with newcons: > > > * (Think it is main) Allow us to switch to fresh Xorg, which require > > > KMS. > > > * Graphic devices which can provide framebuffer access can be easily > > > used as virtual terminals (someone may have pixel-LCD on front of PC > > > tower, may found it useful :-D ) > > > * See [2]. > > > > > > TODO: > > > * Lack of key mapping files, everyone can help with that using > > > instructions on [3]; > > > * A bit slow (mostly scrolling affected). > > > * Other bugs :) > > > * See [2]. > > > > > > Thanks! > > > > > > [1] - http://svnweb.freebsd.org/base/user/ed/newcons/ > > > [2] - > > > > > http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Continuation-of-the-Newcons-Project > > > [3] - > > > > > http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html > > > > > > Hope you will love newcons! > > > And maybe me too :) > > > > > > WBW > > > -- > > > Aleksandr Rybalko > > > > Forget to give a patch to HEAD, here it is: > > > > > > http://people.freebsd.org/~ray/newcons/newcons_to_head_r257107_2013-10-25_1542.diff.gz > > > > Thanks to all! > > > > WBW > > -- > > Aleksandr Rybalko > > ___ > > 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" > > WBW -- Aleksandr Rybalko ___ 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: newcons comming
On Fri, 25 Oct 2013 15:18:47 +0300 Aleksandr Rybalko wrote: > Hello fellow hackers! > > I finally reach the point when I can work with newcons instead of > syscons on my laptop. Yes, I know it still buggy and have a lot of > style(9) problems. But we really have to get it into HEAD and 10.0 to > enable shiny new Xorg features, drivers, etc. > > So I ask everyone to look "hard" into that[1] and tell me your opinion. > I expect a lot of opinions, since it have to affect almost all good > guys, as result I have to ask to split "bug reports" into two parts: > 1. Should be done before merge to 10.0; > 2. Can be done later. > > If it possible, please do it(review - report) ASAP. > I have plan to done it that way: > 1. Merge newcons to head (in a few days); > 2. Fix a lot of reported bugs (2 hrs :-D ); > 3. Persuade re@ about we need it in 10.0 (one week, maybe two); > 4. Merge to 10.0; > 5. One year AFK somewhere on Bahamas;^W^W^W^W^W^W^W > 5. Add mouse cut-paste support; > 6. Fix new bugs; > 7. Some drinks. > > What do we will have with newcons: > * (Think it is main) Allow us to switch to fresh Xorg, which require > KMS. > * Graphic devices which can provide framebuffer access can be easily > used as virtual terminals (someone may have pixel-LCD on front of PC > tower, may found it useful :-D ) > * See [2]. > > TODO: > * Lack of key mapping files, everyone can help with that using > instructions on [3]; > * A bit slow (mostly scrolling affected). > * Other bugs :) > * See [2]. > > Thanks! > > [1] - http://svnweb.freebsd.org/base/user/ed/newcons/ > [2] - > http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Continuation-of-the-Newcons-Project > [3] - > http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html > > Hope you will love newcons! > And maybe me too :) > > WBW > -- > Aleksandr Rybalko Forget to give a patch to HEAD, here it is: http://people.freebsd.org/~ray/newcons/newcons_to_head_r257107_2013-10-25_1542.diff.gz Thanks to all! WBW -- Aleksandr Rybalko ___ 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"
newcons comming
Hello fellow hackers! I finally reach the point when I can work with newcons instead of syscons on my laptop. Yes, I know it still buggy and have a lot of style(9) problems. But we really have to get it into HEAD and 10.0 to enable shiny new Xorg features, drivers, etc. So I ask everyone to look "hard" into that[1] and tell me your opinion. I expect a lot of opinions, since it have to affect almost all good guys, as result I have to ask to split "bug reports" into two parts: 1. Should be done before merge to 10.0; 2. Can be done later. If it possible, please do it(review - report) ASAP. I have plan to done it that way: 1. Merge newcons to head (in a few days); 2. Fix a lot of reported bugs (2 hrs :-D ); 3. Persuade re@ about we need it in 10.0 (one week, maybe two); 4. Merge to 10.0; 5. One year AFK somewhere on Bahamas;^W^W^W^W^W^W^W 5. Add mouse cut-paste support; 6. Fix new bugs; 7. Some drinks. What do we will have with newcons: * (Think it is main) Allow us to switch to fresh Xorg, which require KMS. * Graphic devices which can provide framebuffer access can be easily used as virtual terminals (someone may have pixel-LCD on front of PC tower, may found it useful :-D ) * See [2]. TODO: * Lack of key mapping files, everyone can help with that using instructions on [3]; * A bit slow (mostly scrolling affected). * Other bugs :) * See [2]. Thanks! [1] - http://svnweb.freebsd.org/base/user/ed/newcons/ [2] - http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Continuation-of-the-Newcons-Project [3] - http://raybsd.blogspot.com/2013/10/newcons-international-keyboard-input.html Hope you will love newcons! And maybe me too :) WBW -- Aleksandr Rybalko ___ 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: what is the status of KMS support in newcons?
On Wed, 18 Sep 2013 21:46:50 -0700 John Reynolds wrote: > Hello all, > > I was just wondering what the status of KMS support with newcons is? > About 6 weeks ago I got some help on x11@ and much was said about KMS > (and the lack of support for the 'newer' Haswell graphics). somebody > mentioned that one of the problems where the "console goes away" once > you fire up X was that the console driver didn't support KMS, so you > could never really successfully alt-Ctrl-bksp and kill X (or exit > cleanly) and get back to your VT. Word was said that this problem was > being worked on and hopefully would get brought in towards the "tail > end of august." > > So, am just wondering what the status of that project is? > > thanks, > > -Jr > > ___ > 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" Hello John! I can't say anything about Haswell support, but newcons works, sometimes :) Just not now. I've currently doing some redesign, so it is broken last week. Hope I will done something for wide testing in a week or so, but I'm afraid it will not be fully done to be shipped with 10.0. I will let you and others to know when something will happen :) Thanks! -- Aleksandr Rybalko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-head hang when shutdown by ACPI with Intel GPU and new Xorg and SandyBridge
On Fri, 12 Jul 2013 18:05:47 +0200 Lars Engels wrote: > On Fri, Jul 12, 2013 at 11:26:06AM +0100, David Chisnall wrote: > > On 12 Jul 2013, at 10:01, "Lundberg, Johannes" > > wrote: > > > > >> As the KMS code does not switch the display mode back, once X > > >> with KMS > > > starts, you can't get a console back. > > > > > > Is there any solution for this in the works? > > > > Yes. ray@ is currently being funded by the FreeBSD Foundation to > > improve Newcons compatibility with KMS. The Newcons framework is > > designed to improve layering in the console. The machine-dependent > > part simply provides a framebuffer interface, the > > machine-independent part provides the terminal emulator (this also > > means things like unicode in the console will work, as will > > higher-resolution consoles). It's currently used on a few non-x86 > > platforms, but it wasn't a priority for x86 because the PC BIOS > > text console mostly works and people who want a better terminal can > > just run X. It's now become a priority because of the KMS > > integration with X.org. Once this work is completed, we will > > switch to a new X.org by default and will use the KMS interface > > within the kernel for selecting the video mode. > > Is there a rough ETA for this great improvement? I hope first things to test will be available on begin of the August. But it is just hope yet :) Thanks. -- Aleksandr Rybalko ___ 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: mounting root from NFS via ROOTDEVNAME
On Mon, 3 Jun 2013 00:06:44 -0700
Craig Rodrigues wrote:
> On Tue, May 28, 2013 at 8:13 AM, Eggert, Lars wrote:
>
> > Hi,
> >
> > to conclude this thread, the patch below allows one to specify an nfs
> > rootfs via the ROOTDEVNAME kernel option, which will be mounted when BOOTP
> > does not return a root-path option.
> >
> > Lars
> >
> >
> > diff --git a/sys/nfs/bootp_subr.c b/sys/nfs/bootp_subr.c
> > index 2c57a91..972fb12 100644
> > --- a/sys/nfs/bootp_subr.c
> > +++ b/sys/nfs/bootp_subr.c
> > @@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$");
> >
> > #include "opt_bootp.h"
> > #include "opt_nfs.h"
> > +#include "opt_rootdevname.h"
> >
> > #include
> > #include
> > @@ -870,8 +871,20 @@ bootpc_call(struct bootpc_globalcontext *gctx, struct
> > thread *td)
> > rtimo = time_second +
> > BOOTP_SETTLE_DELAY;
> > printf(" (got root path)");
> > - } else
> > + } else {
> > printf(" (no root path)");
> > +#ifdef ROOTDEVNAME
> > + /*
> > +* If we'll mount rootfs from
> > +* ROOTDEVNAME, we can accept
> > +* offers without root paths.
> > +*/
> > + gotrootpath = 1;
> > + rtimo = time_second +
> > + BOOTP_SETTLE_DELAY;
> > + printf(" (ROOTDEVNAME)");
> > +#endif
> > + }
> > printf("\n");
> > }
> > } /* while secs */
> > @@ -1440,6 +1453,16 @@ bootpc_decode_reply(struct nfsv3_diskless *nd,
> > struct bootpc_ifcontext *ifctx,
> >
> > p = bootpc_tag(&gctx->tag, &ifctx->reply, ifctx->replylen,
> >TAG_ROOT);
> > +#ifdef ROOTDEVNAME
> > + /*
> > +* If there was no root path in BOOTP, use the one in ROOTDEVNAME.
> > +*/
> > + if (p == NULL) {
> > + p = strdup(ROOTDEVNAME, M_TEMP);
> > + if (strcmp(strsep(&p, ":"), "nfs") != 0)
> > + panic("ROOTDEVNAME is not an NFS mount point");
> > + }
> > +#endif
> > if (p != NULL) {
> > if (gctx->setrootfs != NULL) {
> > printf("rootfs %s (ignored) ", p);
> >
>
>
> Sorry for not responding, I've been busy for the past few days.
>
> Thank you for persisting with this, and trying to clean this up.
> This is relatively old code that hasn't been touched in about 15 years,
> so not that many people have worked on it.
>
> I don't like things like ROOTDEVNAME which need to be specified in
> the kernel config and are not part of the GENERIC kernel.
> This usually ends up where code which is behind #ifdef ROOTDEVNAME
> will bitrot because not everyone uses it.
>
> I would like to see the ROOTDEVNAME kernel option go away,
> in favor of a variable that can be specified in loader.conf.
Please don't do that. We still have some amount of systems for which we
can't get boot device name and we can't modify boot process, very
often situation is a embedded system with U-Boot on board and no sources
published anywhere for it. So if we want to be able to continue work
with such systems - we must have, at least similar way to specify
rootdev.
Thanks!
>
> If I search the code via Opengrok, I with this:
> http://bxr.su/s?n=25&start=25&sort=relevancy&q=ROOTDEVNAME&project=FreeBSD
>
> there already seems to be a variable "rootdev" that is checked in a bunch
> of places in the loader, so it would be nice if we could use that.
>
> My personal preference would be to delete ROOTDEVNAME from all the kernel
> configs
> and deprecate the kernel option, and instead use a tunable variable
> which could be set in loader.conf.
>
> This may not be practical. Do you think it would be doable if
> we can have something like this in the kernel code:
>
> const char *rootdevname =
> #ifdef ROOTDEVNAME
> rootdevname = ROOTDEVNAME;
> #else
> rootdevname = NULL
> #endif
>
> if (rootdevname == NULL) {
> rootdevname = getenv("rootdev");
> }
>
>
> or something like that?
> --
> Craig
> ___
> 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"
--
Aleksandr Rybalko
___
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: Any objections/comments on axing out old ATA stack?
On Wed, 27 Mar 2013 17:43:07 -0700 Adrian Chadd wrote: > My main concern with the new stuff is that it requires CAM and that's > reasonably big compared to the standalone ATA code. > > It'd be nice if we could slim down the CAM stack a bit first; it makes > embedding it on the smaller devices really freaking painful. /me never seen embedded devices with ATA/SATA and less than 64MB of RAM. (i386/i486 old machines does not count :) ) I'm missing something? > > Thanks, > > > > adrian > ___ > 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" -- Aleksandr Rybalko ___ 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: kernel boot failier
On Wed, 13 Feb 2013 06:15:07 -0500 Yasir hussan wrote: > hi, > > i am have make some changes in my freebsd acutally have replaced mii bus > with my own switch bus and have put some code of switch but after i > successfully build kernel and world when i try to run it on machine it just > hangs up at boot time after this > > ar7100> bootm > change bootargs > console=ttyS0,115200 root=31:03 rootfstype=jffs2 init=/sbin/init > mtdparts=ar7100-nor0:256k(u-boot),64k(u-boot-env),1152k@384k > (uImage),6592k@1536k(rootfs),64k@320k(ART),64k@8128M > ## Booting image at 8400 ... >Image Name: FreeBSD-9.0-Paxym AR7161 >Created: 2013-02-01 7:54:28 UTC >Image Type: MIPS NetBSD Kernel Image (gzip compressed) >Data Size:2301863 Bytes = 2.2 MB >Load Address: 80050120 >Entry Point: 80050120 >Verifying Checksum ... crc32_fw: 8440 - 84231fe6 (len:00231fa7) > calc... > OK >Uncompressing Kernel Image ... OK > ## Transferring control to NetBSD stage-2 loader (at address 80050120) ... > > One method is that i should revert all changes which will take time, Is > there is other way to debug my code, and can identify correct problem > > thanks > ___ > 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" Hi Yasir, at first check if kernel entrypoint is equal `readelf -a kernel` to get it from kernel and compare it to entrypoint value passed to uboot's mkimage utility. If you want to debug early startup, you need simple UART driver. Boot goes in the following order: 1. mips/mips/locore.S 2. mips/atheros/ar71xx_machdep.c (from platform_start(...)) second one initialize UART and start printing messages to you, if everything ok of course. so to get to know if locore is ok, you need to put ASM block which will put some chars into UART TX reg. Thanks god, MIPS have mapped devices since boot (unlike ARM where you need to map devices before enable MMU). Device segment mapped to 0xa000 as uncached and to 0x8000 as cached. So to use UART without cache you have to add UART physical address to 0xa000 and you will get base address which you can use to access UART controller. 0xa000 + 0x1802 = 0xb802 >From possible problems what I know: 1. You may have different UART unit as console (don't remember if your SoC have more than one UART) 2. platform_start try to parse command line passed by uboot to find mem size. But it can have broken format, or may not have mem size variable. So try to disable argv/envp parsing and set realmem manually. 3. UART can be disabled, then you have to set correct value to AR71XX_GPIO_FUNCTION register. Good luck! WBW -- Aleksandr Rybalko ___ 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 guid
On Mon, 11 Feb 2013 08:36:04 -0500 Yasir hussan wrote: > hi, > > can anyone help me how i can download this code, i tried to downlaod > differnect id by using svn but still fail, i think i am missing something > from basics > > http://zrouter.org/hg/FreeBSD/head/file/a7c552e1ed7f/head/sys/dev/switch/ar8x16_switch.c > > Thanks > ___ > 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" Hello Yasir! Heh, I glad to know what somebody use zrouter.org repo for something :) But have to say: 1. http://zrouter.org/hg/FreeBSD/ is not FreeBSD official repository 2. It is in Mercurial (hg), but not Subversion (svn) If you want to look into FreeBSD ar8216/ar8316 driver, get it by: svn co http://svn.freebsd.org/base/head/sys/dev/etherswitch/ If you want to get ZRouter.org one, you will need to fetch whole repo: hg clone http://zrouter.org/hg/FreeBSD/head/ Thanks. WBW -- Aleksandr Rybalko ___ 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: devel/gobject-introspection failure on ARM
On Sun, 27 Jan 2013 10:57:19 -0500 George Mitchell wrote: > System: Raspberry Pi > uname: r245840M (Alie Tan's image from 25 January) > ports: svnversion 308518 > > Build dies with message "sizeof(ArrayTypeBlob) is expected to be 8 but > is 12." (Complete build log attached.) I made a naive attempt to fix > it by rearranging the order of the structure members, but obviously I > don't understand structure packing on the ARM and it didn't help. It > also didn't get rid of the huge number of "cast increases required > alignment of target type" warnings. > > I note we're at version 0.10.8 of this package, but upstream is at > 1.34.2. (It requires glib 2.34.1, though, and we're only at 2.28.8). > > What's the best way to proceed? -- George Mitchell Hi, It can be fixed by just change gitypelib.c: CHECK_SIZE (ArrayTypeBlob, 8); to gitypelib.c: CHECK_SIZE (ArrayTypeBlob, 12); But problem not in gobject-introspection, but in old ARM ABI. I was ask andrew@, and he test it with ARM EABI, and it compiled fine with size 8. So if somebody will fix it, please #ifdef that fix to make it only with old ARM ABI. Or, better help with EABI testing :-D Thanks! WBW -- Aleksandr Rybalko ___ 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: Customizing ubldr build...
On Thu, 24 May 2012 12:31:04 +0200 Damjan Marion wrote: >> >> On May 24, 2012, at 12:03 PM, Aleksandr Rybalko wrote: >> >> > both with FreeScale i.MX515 ARM SoC + 4M NOR for loader (I put >> > second uboot + ubldr into it) + 8G SSD >> >> Didn't know that we have support for i.MX515. Is it in svn? Heh, no. I have only ubldr for it yet :) WBW -- Aleksandr Rybalko ___ 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: Customizing ubldr build...
On Thu, 24 May 2012 11:40:19 +0200 Damjan Marion wrote: >> >> On May 24, 2012, at 10:25 AM, Aleksandr Rybalko wrote: >> >> > On Thu, 24 May 2012 10:16:42 +0200 >> > Damjan Marion wrote: >> > >> >>> >> >>> On May 24, 2012, at 6:35 AM, Tim Kientzle wrote: >> >>> >> >>>> I think the PandaBoard ES is fully supported by U-Boot, >> >>>> so it should be possible to use ubldr as part of the boot >> >>>> chain for that just like I've been doing with BeagleBone. >> >>> >> >>> What are the benefits of using ubldr compared to what we are >> >>> doing today(load; go)? >> > >> > Preload modules for example. (if it accessible of course) >> >> I was looking into this few months ago but I didn't found a value in >> doing this in embedded world where we already have custom kernel for >> each SoC/board. >> >> Maybe we will have GENERIC arm kernel one day, but there is long >> road Agree with you. Most of my devices load kernel from just mapped flash chip partition. But now I have two PC style boxes: 1. Efika MX Smartbook 2. Efika MX Smarttop both with FreeScale i.MX515 ARM SoC + 4M NOR for loader (I put second uboot + ubldr into it) + 8G SSD Which must be controllable by user, just like we do on PC. Of course it is not urgent feature, but "good to have" :) >> >> Damjan___ >> 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" WBW -- Aleksandr Rybalko ___ 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: Customizing ubldr build...
On Thu, 24 May 2012 10:16:42 +0200 Damjan Marion wrote: >> >> On May 24, 2012, at 6:35 AM, Tim Kientzle wrote: >> >> > I think the PandaBoard ES is fully supported by U-Boot, >> > so it should be possible to use ubldr as part of the boot >> > chain for that just like I've been doing with BeagleBone. >> >> What are the benefits of using ubldr compared to what we are doing >> today(load; go)? Preload modules for example. (if it accessible of course) >> >> Damjan___ >> freebsd-...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to >> "freebsd-arm-unsubscr...@freebsd.org" -- Alexandr Rybalko aka Alex RAY ___ 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: : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
e a make.conf
> +echo "MALLOC_PRODUCTION=" > ${X_DESTDIR}/../make.conf.${BUILDNAME}
> +
> while [ "x$1" != "x" ]; do
> if [ "$1" = "installworld" ]; then
> mkdir -p ${X_DESTDIR}/usr/local/bin/
> @@ -63,7 +66,8 @@
> ${X_TARGET_CPUTYPE} KERNCONF=${KERNCONF}
> DESTDIR=${X_DESTDIR} \
> KODIR=/boot/kernel.${KERNCONF}/
> \
> KMODDIR=/boot/kernel.${KERNCONF}/
> \
> - __MAKE_CONF=/dev/null SRCCONF=/dev/null
> \
> + __MAKE_CONF=${X_DESTDIR}/../make.conf.${BUILDNAME}
> \
> + SRCCONF=/dev/null
> \
> LOCAL_DIRS="${LOCAL_DIRS}"
> \
> LOCAL_TOOL_DIRS="${LOCAL_TOOL_DIRS}" $1
> \
> || exit 1
> @@ -74,3 +78,6 @@
> fi
> shift
> done
> +
> +# __MAKE_CONF=/dev/null
> \
> +# SRCCONF=${X_DESTDIR}/../src.conf.${BUILDNAME}
> \
>
>
>
> adrian
Hi,
confirm, same for zrouter builds, at least for MIPS32EB and MIPS32EL.
In short, MALLOC_PRODUCTION flag for MIPS32EL used this way:
make \
TARGET=mips \
TARGET_ARCH=mipsel \
TARGET_CPUARCH=mips \
... \
MALLOC_PRODUCTION=yes toolchain
make \
TARGET=mips \
TARGET_ARCH=mipsel \
TARGET_CPUARCH=mips \
... \
MALLOC_PRODUCTION=yes buildworld
Just s/mipsel/mips/ for MIPS32EB.
WBW
--
Aleksandr Rybalko
___
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: : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
On Sat, 28 Apr 2012 11:29:01 -0700
Jason Evans wrote:
> On Apr 28, 2012, at 5:09 AM, Aleksandr Rybalko wrote:
> >>> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
> >>>>
> >>>> But contrib/jemalloc/src/arena.c contains a function,
> >>>> arena_chunk_validate_zeroed():
> >>>>
> >>>> 175 static inline void
> >>>> 176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t
> >>>> run_ind) 177 {
> >>>> 178 size_t i;
> >>>> 179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk +
> >>>> (run_ind << LG_PAGE)); 180
> >>>> 181 for (i = 0; i < PAGE / sizeof(size_t); i++)
> >>>> 182 assert(p[i] == 0);
> >>>> 183 }
> >
> > maybe it somehow related to low count of free memory, because I see
> > that very frequently on my box. (Atheros AR7242 mips32be with 32M of
> > RAM)
> >
> > After "#ifdef" of that function body, box behave good (seems) :)
>
> Yes, arena_chunk_validate_zeroed() (which is debug-only code) has the
> side effect of faulting in untouched pages, so it potentially
> increases physical memory usage. In practice, this sanity checking
> has saved jemalloc from regressions that would otherwise manifest as
> mysterious application memory corruption (and would have prevented
> even more regressions, had it existed earlier). You can disable it
> and many other performance-sacrificing debug features by defining
> MALLOC_PRODUCTION in /etc/make.conf.
Yeah, found it. Thank you.
It is possible to hide such debug code under debug macro, so embedded
guys will be more happy about sizes? :)
Thank you for that big job!
>
> Jason___
> 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"
--
Aleksandr Rybalko
___
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: : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
On Sat, 21 Apr 2012 13:11:16 -0700
Jason Evans wrote:
>> On Apr 21, 2012, at 11:54 AM, David Wolfskill wrote:
>> > After applying Dimitry Andric's patches to contrib/jemalloc and
>> > replacing /usr/bin/as with one built last Sunday, I was finally(!)
>> > able to rebuild head as of 234536:
>> >
>> > FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT
>> > #797 234536M: Sat Apr 21 10:23:33 PDT 2012
>> > #r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386
>> >
>> > However, as I was copying a /usr/obj hierarchy via tar -- e.g.:
>> >
>> > root@freebeast:/common/home/david # (cd /var/tmp && rm -fr obj &&
>> > mkdir obj) && (cd /usr && tar cpf - obj) | (cd /var/tmp && tar xpf
>> > -)
>> >
>> > it ran for a while, then:
>> >
>> > : jemalloc_arena.c:182: Failed assertion: "p[i] == 0"
>> > Abort (core dumped)
>> > root@freebeast:/common/home/david # echo $?
>> > 134
>> > root@freebeast:/common/home/david # ls -lTio *.core
>> > ls: No match.
>> > root@freebeast:/common/home/david #
>> >
>> > So ... no core file, apparently.
>> >
>> > freebeast(10.0-C)[2] find /usr/src/contrib/jemalloc -type f -name
>> > jemalloc_arena.c freebeast(10.0-C)[3]
>> >
>> > No file named "jemalloc_arena.c", either.
>> >
>> > But contrib/jemalloc/src/arena.c contains a function,
>> > arena_chunk_validate_zeroed():
>> >
>> >175 static inline void
>> >176 arena_chunk_validate_zeroed(arena_chunk_t *chunk, size_t
>> > run_ind) 177 {
>> >178 size_t i;
>> >179 UNUSED size_t *p = (size_t *)((uintptr_t)chunk +
>> > (run_ind << LG_PAGE)); 180
>> >181 for (i = 0; i < PAGE / sizeof(size_t); i++)
>> >182 assert(p[i] == 0);
>> >183 }
>> >
>> > Thoughts?
>>
>> I received a similar report yesterday in the context of filezilla,
>> but didn't get as far as reproducing it. I think the problem is in
>> chunk_alloc_dss(), which dangerously claims that newly allocated
>> memory is zeroed. It looks like I formalized this bad assumption in
>> early 2010, though the bug existed before that. It's a bigger deal
>> now because sbrk() is preferred over mmap(), so the bug has
>> languished for a couple of years. I'll get a fix committed today
>> (and revert the order of preference between sbrk() and mmap()).
>>
>> By the way, I wonder why not everyone hits this (I don't).
>>
>> Thanks,
>> Jason___
>> 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"
Hi,
maybe it somehow related to low count of free memory, because I see
that very frequently on my box. (Atheros AR7242 mips32be with 32M of
RAM)
After "#ifdef" of that function body, box behave good (seems) :)
WBW
--
Alexandr Rybalko
aka Alex RAY
___
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: build with KTR and KTR_CPUMASK
On Fri, 13 Apr 2012 14:53:41 +0100 Attilio Rao wrote: >> Please read NOTES. It is really my fault, but with different source :) Sorry for noise. P.S. It was wrong kernel config generated by zrouter. WBW -- Aleksandr Rybalko ___ 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"
build with KTR and KTR_CPUMASK
Hi, When kernel build with option KTR_CPUMASK, build failed with following error: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/1/MIPS_FreeBSD/HEAD/head/sys -I/usr/1/MIPS_FreeBSD/HEAD/head/sys/contrib/altq -I/usr/1/MIPS_FreeBSD/HEAD/head/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1 --param large-function-growth=10 --param max-inline-insns-single=1 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x80001000 -march=mips32 -msoft-float -ffreestanding -Werror /usr/1/MIPS_FreeBSD/HEAD/head/sys/kern/kern_ktr.c cc1: warnings being treated as errors /usr/1/MIPS_FreeBSD/HEAD/head/sys/kern/kern_ktr.c: In function 'ktr_cpumask_initializer': /usr/1/MIPS_FreeBSD/HEAD/head/sys/kern/kern_ktr.c:112: warning: passing argument 2 of 'cpusetobj_strscan' makes pointer from integer without a cast *** Error code 1 SVN revision 234222. WBW -- Alexandr Rybalko aka Alex RAY ___ 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: SeaMonkey eats the CPU as of r232144
On Sat, 3 Mar 2012 00:20:09 +0200 Aleksandr Rybalko wrote: >> On Fri, 02 Mar 2012 20:52:06 +0100 >> Florian Smeets wrote: >> >> > On 02.03.12 20:08, Aleksandr Rybalko wrote: >> > > On Fri, 2 Mar 2012 09:01:25 -0800 >> > > Adrian Chadd wrote: >> > > >> > >> Ok. So it's that exact commit? >> > >> >> > >> david, what did you break? :) >> > >> >> > > >> > > I bet it is old enough :) >> > > I'm on 9.0-PRERELEASE #3 r227950 and when Seamonkey can't reach >> > > some document it get 100% cpu. one time I even attach to it and >> > > found what seamonkey polling socket very-very fast, but no I'm >> > > have not so much free time to found what really broken. IIRC >> > > same happen in FF also. >> > > >> > >> > Aleksandr, >> > >> > please upgrade your nspr to the latest version. This should have >> > been fixed by >> > http://lists.freebsd.org/pipermail/cvs-ports/2011-September/225460.html >> > >> > Florian >> > >> >> Will update it asap. >> >> Thank you very much Florian! Indeed. Works fine now! Thanks again Florian! >> >> WBW >> -- >> Aleksandr Rybalko -- Alexandr Rybalko aka Alex RAY ___ 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: SeaMonkey eats the CPU as of r232144
On Fri, 02 Mar 2012 20:52:06 +0100 Florian Smeets wrote: > On 02.03.12 20:08, Aleksandr Rybalko wrote: > > On Fri, 2 Mar 2012 09:01:25 -0800 > > Adrian Chadd wrote: > > > >> Ok. So it's that exact commit? > >> > >> david, what did you break? :) > >> > > > > I bet it is old enough :) > > I'm on 9.0-PRERELEASE #3 r227950 and when Seamonkey can't reach some > > document it get 100% cpu. one time I even attach to it and found > > what seamonkey polling socket very-very fast, but no I'm have not > > so much free time to found what really broken. IIRC same happen in > > FF also. > > > > Aleksandr, > > please upgrade your nspr to the latest version. This should have been > fixed by > http://lists.freebsd.org/pipermail/cvs-ports/2011-September/225460.html > > Florian > Will update it asap. Thank you very much Florian! WBW -- Aleksandr Rybalko ___ 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: SeaMonkey eats the CPU as of r232144
On Fri, 2 Mar 2012 09:01:25 -0800 Adrian Chadd wrote: > Ok. So it's that exact commit? > > david, what did you break? :) > I bet it is old enough :) I'm on 9.0-PRERELEASE #3 r227950 and when Seamonkey can't reach some document it get 100% cpu. one time I even attach to it and found what seamonkey polling socket very-very fast, but no I'm have not so much free time to found what really broken. IIRC same happen in FF also. > > > Adrian > ___ > 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" -- Aleksandr Rybalko ___ 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: kernel config files outside of sys/${ARCH}/conf ?
On Thu, 12 Jan 2012 12:17:57 +0100
Luigi Rizzo wrote:
>> On Thu, Jan 12, 2012 at 12:22:50PM +0200, Aleksandr Rybalko wrote:
>> > On Thu, 12 Jan 2012 11:17:39 +0100
>> > Luigi Rizzo wrote:
>> >
>> > >> On Thu, Jan 12, 2012 at 01:55:39AM -0800, Garrett Cooper wrote:
>> > >> > On Thu, Jan 12, 2012 at 2:06 AM, Luigi Rizzo
>> > >> > wrote:
>> > >> > > On Thu, Jan 12, 2012 at 10:16:53AM +0100, Gary Jennejohn
>> > >> > > wrote:
>> > >> > >> On Thu, 12 Jan 2012 09:11:39 +0100
>> > >> > >> Luigi Rizzo wrote:
>> > >> > >>
>> > >> > >> > usr/sbin/config assumes that the kernel config file
>> > >> > >> > lives in ${src_base}/sys/${arch}/conf , which means that
>> > >> > >> > if you need to build a custom kernel one needs RW
>> > >> > >> > access to that directory.
>> > >> > >> >
>> > >> > >> > Any idea on how we can enable config to work in a
>> > >> > >> > generic directory ?
>> > >> > >> >
>> > >> > >> > I scanned the source code usr.sbin/config and found that
>> > >> > >> > it uses hardwired paths -- specifically, it looks for
>> > >> > >> > the kernel source tree in "../.." and has multiple
>> > >> > >> > hardwired paths such as "../../conf/".
>> > >> > >> > There is also a somewhat undocumented access to a
>> > >> > >> > file called DEFAULTS that extends the configuration you
>> > >> > >> > pass.
>> > >> > >> >
>> > >> > >> > Any objections to the addition of a "-s" option to config
>> > >> > >> > (8) to specify the location of the source tree ?
>> > >> > >> >
>> > >> > >>
>> > >> > >> Seems like a good idea to me as long as the old behavior is
>> > >> > >> kept.
>> > >> > >
>> > >> > > of course :)
>> > >> >
>> > >> > Why not just set KERNCONFDIR?
>> > >>
>> > >> The variable does not seem to be used by usr/sbin/config
>> > >>
>> > >> cheers
>> > >> luigi
>> > >> ___
>> > >> 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"
>> >
>> > Hi,
>> >
>> > ZRouter.org use just full path to config file
>> > make KERNCONF=/path/to/config buildkernel
>>
>> It does not work:
>>
>> > ls -l /home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64
>> -rw-r--r-- 1 luigi wheel 4285 Jan 12
>> 11:32 /home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64
>> > make KERNCONF=/home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64
>> > buildkernel
>> ERROR: Missing kernel configuration file(s)
>> (/home/luigi/FreeBSD/pico9/qemu/PICOBSD.amd64).
>>
>> As i said, the hardwired paths in config suggest that there is
>> a requirement that the config lives under the source tree and
>> cannot be in a completely arbitrary position. My tests confirm that.
>> So, KERNCONF=/path/to/config only works for certain values of
>> /path/to/config .
>>
>> Of course i may be wrong but if you have direct experience
>> in building a kernel whose config file name is /tmp/NOT_GENERIC
>> please let me know how you do it.
>>
>> cheers
>> luigi
>> ___
>> 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"
Oh, yes, sorry, I forgot about Makefile.inc1 changes.
Her it is:
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 229577)
+++ Makefile.inc1 (working copy)
@@ -29,6 +29,7 @@
# /usr/share/mk. These include:
# obj depend all install clean cleandepend cleanobj
+SRC_ROOT=${.CURDIR}
# You are supposed to define both of these when call
Re: kernel config files outside of sys/${ARCH}/conf ?
On Thu, 12 Jan 2012 11:17:39 +0100
Luigi Rizzo wrote:
>> On Thu, Jan 12, 2012 at 01:55:39AM -0800, Garrett Cooper wrote:
>> > On Thu, Jan 12, 2012 at 2:06 AM, Luigi Rizzo
>> > wrote:
>> > > On Thu, Jan 12, 2012 at 10:16:53AM +0100, Gary Jennejohn wrote:
>> > >> On Thu, 12 Jan 2012 09:11:39 +0100
>> > >> Luigi Rizzo wrote:
>> > >>
>> > >> > usr/sbin/config assumes that the kernel config file
>> > >> > lives in ${src_base}/sys/${arch}/conf , which means that
>> > >> > if you need to build a custom kernel one needs RW
>> > >> > access to that directory.
>> > >> >
>> > >> > Any idea on how we can enable config to work in a
>> > >> > generic directory ?
>> > >> >
>> > >> > I scanned the source code usr.sbin/config and found that
>> > >> > it uses hardwired paths -- specifically, it looks for
>> > >> > the kernel source tree in "../.." and has multiple
>> > >> > hardwired paths such as "../../conf/".
>> > >> > There is also a somewhat undocumented access to a
>> > >> > file called DEFAULTS that extends the configuration you pass.
>> > >> >
>> > >> > Any objections to the addition of a "-s" option to config(8)
>> > >> > to specify the location of the source tree ?
>> > >> >
>> > >>
>> > >> Seems like a good idea to me as long as the old behavior is
>> > >> kept.
>> > >
>> > > of course :)
>> >
>> > Why not just set KERNCONFDIR?
>>
>> The variable does not seem to be used by usr/sbin/config
>>
>> cheers
>> luigi
>> ___
>> 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"
Hi,
ZRouter.org use just full path to config file
make KERNCONF=/path/to/config buildkernel
Main difference in: zrouter.org config don't use includes, but generate
full config.
WBW
--
Alexandr Rybalko
aka Alex RAY
___
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] bsdbox changes for base system: add LOCAL_
On Fri, 23 Dec 2011 16:42:06 -0800
Adrian Chadd wrote:
> Hi,
>
> Here are two patches which implement some useful features for crunch
> building:
>
> * Add LOCAL_TOOLS_DIR in src/Makefile.inc1, which adds entries to the
> 'build-tools' target. This is needed for cross-building bsdbox (and
> any external directory added by LOCAL_DIRS)
That makes me happy :)
> * If CRUNCH_SUPPRESS_ALL_LINKS is set to 'yes', don't auto-populate
> the crunch-gen hard links.
>
> I may end up changing the latter to CRUNCH_GENERATE_LINKS and default
> that to yes, then allow the bsdbox build system to change that to
> 'no', but the intent is the same.
>
> I'd like to commit this tomorrow if possible, so I can then follow it
> up with the bsdbox import.
>
> Thanks,
>
>
> Adrian
Do it Adrian :)
>
> [adrian@pcbsd-macvm] ~/work/freebsd/head/src> svn diff Makefile.inc1
> share/mk Index: Makefile.inc1
> ===
> --- Makefile.inc1 (revision 228757)
> +++ Makefile.inc1 (working copy)
> @@ -15,6 +15,8 @@
> # -DNO_WWWUPDATE do not update www in ${MAKE} update
> # -DNO_CTF do not run the DTrace CTF conversion tools on built
> # objects LOCAL_DIRS="list of dirs" to add additional dirs to the
> # SUBDIR list
> +# LOCAL_TOOL_DIRS="list of dirs" to add additional dirs to the
> build-tools +# list
> # TARGET="machine" to crossbuild world for a different machine
> # type TARGET_ARCH= may be required when a TARGET supports multiple
> # endians
>
> @@ -104,6 +106,8 @@
> CLEANDIR= cleandir
> .endif
>
> +LOCAL_TOOL_DIRS?= ''
> +
> CVS?= cvs
> CVSFLAGS?= -A -P -d -I!
> SVN?= svn
> @@ -1102,6 +1106,7 @@
> bin/csh \
> bin/sh \
> ${_rescue} \
> +${LOCAL_TOOL_DIRS} \
> lib/ncurses/ncurses \
> lib/ncurses/ncursesw \
> ${_share} \
> Index: share/mk/bsd.crunchgen.mk
> ===
> --- share/mk/bsd.crunchgen.mk (revision 228757)
> +++ share/mk/bsd.crunchgen.mk (working copy)
> @@ -22,6 +22,8 @@
> # Specific links can be suppressed by setting
> # CRUNCH_SUPPRESS_LINK_$(NAME) to 1.
> #
> +# If CRUNCH_SUPPRESS_ALL_LINKS is set to yes, no links will be
> generated. +#
>
> # $FreeBSD$
>
> @@ -39,6 +41,7 @@
> .else
> CANONICALOBJDIR:= /usr/obj${.CURDIR}
> .endif
> +CRUNCH_SUPPRESS_ALL_LINKS?=no
>
> CLEANFILES+= $(CONF) *.o *.lo *.c *.mk *.cache *.a *.h
>
> @@ -51,6 +54,7 @@
> .else
> $(OUTPUTS): $(.CURDIR)/../../$(D)/$(P)/Makefile
> .endif
> +.if ${CRUNCH_SUPPRESS_ALL_LINKS} != "yes"
> .ifndef CRUNCH_SUPPRESS_LINK_${P}
> LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(P)
> .endif
> @@ -59,6 +63,7 @@
> LINKS+= $(BINDIR)/$(PROG) $(BINDIR)/$(A)
> .endif
> .endfor
> +.endif
> .endfor
> .endfor
> ___
> freebsd-a...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to
> "freebsd-arch-unsubscr...@freebsd.org"
--
Aleksandr Rybalko
___
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"
9.0-RC2 - bsdinstall - ifconfig
Hi peoples who stay current! Several days ago I made fresh installation of 9.0-RC2. I found that new installer is very easy and very usable. But found small problem: When I doing interface configuration, I press instead of and then for return press , after that dialog was closed with only IP field filled. So it is not a problem that not supported, but problem is that unexpected keys combinations close the dialog box. Thank you! WBW -- Alexandr Rybalko aka Alex RAY ___ 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: request: merging if_ath_tx branch to HEAD
On Mon, 31 Oct 2011 14:17:28 -0700 Adrian Chadd wrote: > Hi all, > > I'd like to merge the if_ath_tx code into -HEAD so it gets some wider > testing. This includes a couple of net80211 changes but it > overwhelmingly is if_ath driver changes. > > The code is a bit messy and it's still a work in progress but I'd > rather tidy it up in -HEAD. Otherwise I'm stuck in the unfortunate > situation of having to keep merging between the if_ath_tx branch and > -HEAD. > > Please let me know if you have any feelings/comments about this. I'll > look to start doing this over the next few days. > > Thanks, > Hi, I think it will make driver update process faster and easier, so +1 > > > Adrian > ___ > 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" -- Aleksandr Rybalko ___ 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: SPI rework
On Wed, 19 Oct 2011 19:14:07 +0800 Adrian Chadd wrote: > .. what's wrong with your first suggestion? I liked it. :) > > > Adrian Because we can't do duplex operations in that way. But if we use old struct, we will be able send and receive in the same time. I don't know if such device exists. But if we implement "SPI device" then we will be able to communicate between two FreeBSD boxes in a duplex manner! :) -- Aleksandr Rybalko ___ 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: SPI rework
On Tue, 18 Oct 2011 06:17:46 +0800 Adrian Chadd wrote: >> Hi, >> >> That sounds logical to me. Maybe getting it done before 9.0-RELEASE >> is a bit rushed? >> >> I can help you test out the flash side of things on my atheros SoC >> boards. >> >> >> Adrian More thinking give me a better way to fix that. We leave same structure, but remove KASSERT(cmd->tx_cmd_sz == cmd->rx_cmd_sz,""); and fix SPI controllers drivers to care about possible different sizes. And of course will fix consumers to set exact what they need. (dev/flash: cmd_tx_sz=1, data_rx_sz=3 for "device ID" call) That way better because we will have ability to duplex SPI transfers on controllers that able to do that, RT305x SPI will return error in case when sizes specified for both directions. Comments? WBW -- Alexandr Rybalko aka Alex RAY ___ 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"
SPI rework
Hi all!
I implement new SPI controller driver (for RT305XF) and found interest
problem: our current SPI implementation based on transfer data in
structure spi_command:
struct spi_command {
void*tx_cmd;
uint32_t tx_cmd_sz;
void*rx_cmd;
uint32_t rx_cmd_sz;
void*tx_data;
uint32_t tx_data_sz;
void*rx_data;
uint32_t rx_data_sz;
};
There is the problem 1, because all SPI requests I know use only two
transaction parts:
1 - write command (or read command if SPI slave)
2 - read/write device data
so something like:
{
void*cmd;
size_t cmd_sz;
uint32_tcmd_flags;
#define SPI_DIRECTION_READ (0<<0)
#define SPI_DIRECTION_WRITE (1<<0)
void*data;
size_t data_sz;
uint32_tdata_flags;
};
will be more accurate.
And the problem number 2: most controllers verify tx_cmd_sz ==
rx_cmd_sz, so seems `cmd` part must contain only request, and `data`
must contain only payload.
And the problem number 3: SPI flash driver for example:
set buf[0] = 0x9f; /* SPI flash identify query */
then
tx_cmd = buf;
tx_cmd_sz = rx_cmd_sz = 4;
And expect to receive device id in buf[1], buf[2], buf[3].
S, how controller will decide which part of `buf` is a command, and
which part is a data? And again which part should be to write, which
to read?
Somebody maybe ask me: Why you need it? Answer: because RT305XF spi
controller can't do bidirectional transfer, that controller can only
write or read.
Currently we have spi controllers for arm/at91 and mips/atheros (I have
also GPIO spi controller) and only one consumer for spibus -
dev/flash
I "swear" to take care about mips/atheros, dev/flash and dev/spibus,
but seems will need some help from someone who work with Atmel's.
It will be very nice to have it discussed and done before 9.0.
Will wait for any comments and suggestions.
WBW
--
Aleksandr Rybalko
___
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: [CFT]RT28xx/RT30xx wireless was [CFR]RT305xF support, w/o attachment
On Thu, 31 Mar 2011 23:44:03 -0700 (PDT) PseudoCylon wrote: >> > > rt28600: mem 0xf7f0-0xf7f0 irq 17 at >> > > device 0.0 on pci3 >> > > rt28600: invalid EEPROM LNA gain #2: 0x00 >> > > rt28600: invalid EEPROM LNA gain #3: 0x00 >> > > rt28600: invalid EEPROM powersave level >> > > rt28600: MAC/BBP RT2860 (rev 0x28720200), RF RT3022 2.4G 2T2R >> > Wow, your device have same revision 0x28720200 like embedded into >> > RT3052F system on chip. >> > So now I understand, why driver won't work with your card. >> > I previously expect that this id related only for SoC version, but SoC >> > version don't have many things that PCI version have (MCU, EEPROM, >> > etc.) >> > >> >> Hi, >> >> I have 0x28720200 calling rt2872_rf_set_chan() instead of >> rt2860_rf_set_chan(). >> And, 0x2000 for initial RT2860_REG_MAX_LEN value in rt2860_init_locked(). >> >> If these are correct I can patch the driver up. Basic problem here is a usage external EEPROM data(instead read from real EEPROM) and direct BBP control(instead use MCU). So currently prefer to use Alexander Egorenkov version, until we done porting OpenBSD one and join it with ral(4) code. >> >> AK >> -- Alexandr Rybalko aka Alex RAY ___ 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: [CFT]RT28xx/RT30xx wireless was [CFR]RT305xF support, w/o attachment
On Thu, 31 Mar 2011 16:50:16 +0100 "Sevan / Venture37" wrote: > On 31 March 2011 10:07, Aleksandr Rybalko wrote: > > Now good peoples help me with rework of driver, then this driver > > will be available under ral(4). So you need to wait some time. > > Excellent, I'm happy to be a tester for patches, the card is a > Azurewave RT2700E out of a EEPC if I remember right > > > >>> I will post dmesg & pciconf output tomorrow once I have an > >>> ethernet cable or removable media near me if you need more info. > > > > Yeah, post please. at minimum I've interesting which RF used in > > your device. > > rt28600: mem 0xf7f0-0xf7f0 irq 17 at > device 0.0 on pci3 > rt28600: invalid EEPROM LNA gain #2: 0x00 > rt28600: invalid EEPROM LNA gain #3: 0x00 > rt28600: invalid EEPROM powersave level > rt28600: MAC/BBP RT2860 (rev 0x28720200), RF RT3022 2.4G 2T2R Wow, your device have same revision 0x28720200 like embedded into RT3052F system on chip. So now I understand, why driver won't work with your card. I previously expect that this id related only for SoC version, but SoC version don't have many things that PCI version have (MCU, EEPROM, etc.) I will fix it behavior in new driver. > rt28600: skip channel 10, could not find extension channel > rt28600: skip channel 11, could not find extension channel > rt28600: skip channel 12, could not find extension channel > rt28600: skip channel 13, could not find extension channel > rt28600: skip channel 14, could not find extension channel > > > rt28600@pci0:3:0:0: class=0x028000 card=0x27901814 > chip=0x07811814 rev=0x00 hdr=0x00 > vendor = 'Ralink Technology, Corp.' > device = 'Wireless (RT2860/RT2890)' > class = network > > > Sevan -- Aleksandr Rybalko ___ 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: [CFT]RT28xx/RT30xx wireless was [CFR]RT305xF support, w/o attachment
Hi Sevan, On Thu, 31 Mar 2011 01:49:04 +0100 "Sevan / Venture37" wrote: >> On 20 March 2011 13:36, Aleksandr Rybalko wrote: >> > Hi folks, >> > >> > new version of patch for wireless card based on Ralink RT2860 plus >> > RT3090 that required testing. >> > >> > Main part: >> > http://my.ddteam.net/files/2011-03-20_rt2860.patch >> > >> > sys/conf/(files|options), same as last: >> > http://my.ddteam.net/files/2011-03-18_rt2860_invoking.patch >> > >> > Who use Ralink PCI/miniPCI/PCIE wireless cards, please test driver and >> > send info about success or failures. >> > >> > Thanks. >> > >> > -- >> > Aleksandr Rybalko >> >> Many thanks for this Aleksandr >> I've just compiled & installed a new kernel + rt2860 module with success. >> kernel module loads fine & my RT2790 (chip=0x07811814) is detected. >> ifconfig wlan0 create wlandev rt28600 up >> shows wlan0: with my ethernet address but from there ifconfig wlan0 >> scan or list scan result in nothing >> configuring the ssid manually & trying to connect to the AP doesn't work >> either. >> As I hadn't checked this mailing list before starting out this >> evening, I was doomed to stw & came across >> http://repo.or.cz/w/ralink_drivers.git via the freebsd forum, before >> trying your patch, I had successfully build the freebsd 8 driver from >> there on current & managed to get the card working, using csup to >> update src as a test of connectivity. Now good peoples help me with rework of driver, then this driver will be available under ral(4). So you need to wait some time. >> >> I will post dmesg & pciconf output tomorrow once I have an ethernet >> cable or removable media near me if you need more info. Yeah, post please. at minimum I've interesting which RF used in your device. >> >> Sevan >> ___ >> 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" Thank you! WBW -- Alexandr Rybalko aka Alex RAY ___ 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: Fix softdep_request_cleanup difference w/ and w/o SOFTUPDATES
On Mon, 28 Mar 2011 11:32:12 -0400
Ryan Stone wrote:
> On Mon, Mar 28, 2011 at 6:19 AM, Aleksandr Rybalko
> wrote:
> > Hi,
> >
> > I found a difference of definition softdep_request_cleanup.
> > when SOFTUPDATES undefined softdep_request_cleanup take only two
> > arguments.
> >
> > Patch to fix this:
> >
> > Index: sys/ufs/ffs/ffs_softdep.c
> > ===
> > --- sys/ufs/ffs/ffs_softdep.c (revision 220095)
> > +++ sys/ufs/ffs/ffs_softdep.c (working copy)
> > @@ -514,9 +514,10 @@
> > }
> >
> > int
> > -softdep_request_cleanup(fs, vp)
> > +softdep_request_cleanup(fs, vp, resource)
> > struct fs *fs;
> > struct vnode *vp;
> > + int resource;
> > {
> >
> > return (0);
>
> If we need to change the definition, shouldn't we convert it to a C89
> declaration at the same time?
Yeah, I agree with you, but think peoples who made nice things for UFS
have they own plan what to do with this.
I only fix problem for building without SOFTUPDATES flag set.
BTW, if someone interest I can convert all declaration of this file to
C89 :)
--
Aleksandr Rybalko
___
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"
Fix softdep_request_cleanup difference w/ and w/o SOFTUPDATES
Hi,
I found a difference of definition softdep_request_cleanup.
when SOFTUPDATES undefined softdep_request_cleanup take only two arguments.
Patch to fix this:
Index: sys/ufs/ffs/ffs_softdep.c
===
--- sys/ufs/ffs/ffs_softdep.c (revision 220095)
+++ sys/ufs/ffs/ffs_softdep.c (working copy)
@@ -514,9 +514,10 @@
}
int
-softdep_request_cleanup(fs, vp)
+softdep_request_cleanup(fs, vp, resource)
struct fs *fs;
struct vnode *vp;
+ int resource;
{
return (0);
--
Alexandr Rybalko
aka Alex RAY
___
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: [CFR]RT305xF support, w/o attachment
On Mon, 21 Mar 2011 11:00:49 +0100
Bernhard Schmidt wrote:
>> On Monday, March 21, 2011 10:29:11 Aleksandr Rybalko wrote:
>> > Hi,
>> >
>> > On Mon, 21 Mar 2011 07:04:22 +0100
>> > Bernhard Schmidt wrote:
>> >
>> > >> On Monday 21 March 2011 00:16:01 Aleksandr Rybalko wrote:
>> > >> > On Mon, 21 Mar 2011 05:59:45 +0800
>> > >> > Adrian Chadd wrote:
>> > >> >
>> > >> > > On 21 March 2011 04:28, Sergey V. Dyatko
>> > >> > > wrote:
>> > >> > >
>> > >> > >
>> > >> > > > Last patch from Aleksandr 'works fine for me', so... may be rt2860
>> > >> > > > should be replaced to 'rt' for example ?
>> > >> > > > rt0: flags= blah-blah-blah IHMO looks more .nice(?) than
>> > >> > > > rt28600: flags=
>> > >> > > >
>> > >> > >
>> > >> > > Yup, that's a good idea. Aleksandr, can you please do that?
>> > >> >
>> > >> > Off-course I can, but seems better name will be rtw or rtn, because we
>> > >> > already have if_rt (for RT3052 ether) which have iface name "rt".
>> > >> >
>> > >> > I think "rtn" is best.
>> > >> >
>> > >> > Maybe someone have better?
>> > >>
>> > >> rtw is a name for a Realtek driver.
>> > Realtek driver called urtw, but I agree with you to avoid confusion.
>>
>> That rtw driver I'm speaking of is for older Realtek 8180/8185 PCI
>> based chips. Granted, not in our tree, but it exists. urtw(4) is for
>> 8187B/L USB chipsets.
>>
>> > >>
>> > >> I'd prefer if can keep this driver in sync with the OpenBSD one where
>> > >> it is clearly derived from. So, rt28xx and rt30xx support has to be an
>> > >> extension to ral(4). That shouldn't be to hard to do, just throw in the
>> > >> code into dev/ral/ and hook it to the pci/ops code.
>> > This driver closer to USB run(4), but this use USB and difference still
>> > big.
>> >
>> > In future, not so closer, I will try to join run, ral and my rt2860. But
>> > there is too much work and I need to find time for
>> > it.
>>
>> Please don't. There is a reason the PCI and USB chipsets, even if
>> derived from the same base chipset, have different drivers. The BUS
>> specific implementation/restrictions are way too different/important.
>> Trying to merge those will only make your head ache :)
>>
>> >
>> > >>
>> >
>> > So for now, best name is "rtn".
>> >
>> > If no objections, I send updated patch with new name.
>>
>> I still don't think this is the way to go. Adding a totally independent
>> driver now and replacing (or merging) it later simple won't work. Also,
>> it is quite annoying from user point of view.
>>
>> I urge you to have a closer look at ral(4) and it's way of handling
>> RT2500 and RT2600 specific differences. In it's simplest form you can
>> copy the OpenBSD code 1:1 without any functional changes, heck, it's
>> the source of this driver anyway.
>>
>> --
>> Bernhard
I've look on difference between RT2[56]00 and RT2860 some time ago, but done it
again, and found that we can only place
RT2860/RT3090 support under same name (ral), but hardware have too big
difference. And in case I do this patch for RT3052F SoC,
when I placing RT2860 into ral, i get completely different driver (because SoC
don't use PCI interface).
So can You (or someone else) hint me, how to done this?
switch (what to do) {
case 'Remake run to support PCI and SoC interface':
Much work to make driver bus independent;
case 'Port OpenBSD one':
driver do not support SoC (SoC device don't have MCU);
break;
case 'Place my RT2860 under dev/ral':
different device in same driver;
break;
}
Hint me please.
WBW
--
Alexandr Rybalko
aka Alex RAY
___
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: [CFR]RT305xF support, w/o attachment
Hi, On Mon, 21 Mar 2011 07:04:22 +0100 Bernhard Schmidt wrote: >> On Monday 21 March 2011 00:16:01 Aleksandr Rybalko wrote: >> > On Mon, 21 Mar 2011 05:59:45 +0800 >> > Adrian Chadd wrote: >> > >> > > On 21 March 2011 04:28, Sergey V. Dyatko >> > > wrote: >> > > >> > > >> > > > Last patch from Aleksandr 'works fine for me', so... may be rt2860 >> > > > should be replaced to 'rt' for example ? >> > > > rt0: flags= blah-blah-blah IHMO looks more .nice(?) than >> > > > rt28600: flags= >> > > > >> > > >> > > Yup, that's a good idea. Aleksandr, can you please do that? >> > >> > Off-course I can, but seems better name will be rtw or rtn, because we >> > already have if_rt (for RT3052 ether) which have iface name "rt". >> > >> > I think "rtn" is best. >> > >> > Maybe someone have better? >> >> rtw is a name for a Realtek driver. Realtek driver called urtw, but I agree with you to avoid confusion. >> >> I'd prefer if can keep this driver in sync with the OpenBSD one where >> it is clearly derived from. So, rt28xx and rt30xx support has to be an >> extension to ral(4). That shouldn't be to hard to do, just throw in the >> code into dev/ral/ and hook it to the pci/ops code. This driver closer to USB run(4), but this use USB and difference still big. In future, not so closer, I will try to join run, ral and my rt2860. But there is too much work and I need to find time for it. >> >> -- >> Bernhard So for now, best name is "rtn". If no objections, I send updated patch with new name. Thank you Bernhard! WBW -- Alexandr Rybalko aka Alex RAY ___ 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: [CFR]RT305xF support, w/o attachment
On Mon, 21 Mar 2011 05:59:45 +0800 Adrian Chadd wrote: > On 21 March 2011 04:28, Sergey V. Dyatko > wrote: > > > > Last patch from Aleksandr 'works fine for me', so... may be rt2860 > > should be replaced to 'rt' for example ? > > rt0: flags= blah-blah-blah IHMO looks more .nice(?) than > > rt28600: flags= > > > > Yup, that's a good idea. Aleksandr, can you please do that? Off-course I can, but seems better name will be rtw or rtn, because we already have if_rt (for RT3052 ether) which have iface name "rt". I think "rtn" is best. Maybe someone have better? > > > Adrian -- Aleksandr Rybalko ___ 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"
[CFT]RT28xx/RT30xx wireless was [CFR]RT305xF support, w/o attachment
Hi folks, new version of patch for wireless card based on Ralink RT2860 plus RT3090 that required testing. Main part: http://my.ddteam.net/files/2011-03-20_rt2860.patch sys/conf/(files|options), same as last: http://my.ddteam.net/files/2011-03-18_rt2860_invoking.patch Who use Ralink PCI/miniPCI/PCIE wireless cards, please test driver and send info about success or failures. Thanks. -- Aleksandr Rybalko ___ 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: [CFR]rt2860 driver with kld module
Hi, updated patch: http://my.ddteam.net/files/2011-03-18_rt2860.patch http://my.ddteam.net/files/2011-03-18_rt2860_invoking.patch I made separate part of patch that invoke rt2860 driver into build process because I have plan to import rt3090 support into driver, but have too much changes to sys/conf files, and it's hard to move it always when I made new patch. current rt2860 support including support EEPROM reading subrouting for rt3090 like wireless cards. Please test it, and send me part of dmesg related to card. On Fri, 18 Mar 2011 09:34:56 +0200 "Sergey V. Dyatko" wrote: > On Thu, 17 Mar 2011 17:53:21 +0200 > Aleksandr Rybalko wrote: > > > On Thu, 17 Mar 2011 17:17:17 +0200 > > "Sergey V. Dyatko" wrote: > > --->8--- > > > > new patch with kld support > > http://my.ddteam.net/files/2011-03-17_1_rt2860.patch > > > > I don't expect so much interest for this device on a PCI bus. And > > forget to include useful parts like kld Makefile. Seems now this can > > compile and work :) > > > > panic: > http://tiger.ipfw.ru/files/core_rt2860.txt > > > Thank you. > > > > > > -- > wbr, tiger Thanks to all! WBW -- Aleksandr Rybalko ___ 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: [CFR]rt2860 driver with kld module
On Thu, 17 Mar 2011 17:17:17 +0200
"Sergey V. Dyatko" wrote:
>> On Thu, 17 Mar 2011 13:26:16 +0200
>> Aleksandr Rybalko wrote:
>>
>> > Hi again!
>> >
>> > On Wed, 16 Mar 2011 20:44:05 +0200
>> > Aleksandr Rybalko wrote:
>> >
>> > >> Hi,
>> > >>
>> > >> On Wed, 16 Mar 2011 18:06:59 +0100
>> > >> Jan Henrik Sylvester wrote:
>> > >>
>> > >> > Hello!
>> > >> >
>> > >> > On 01/-10/-28163 20:59, Aleksandr Rybalko wrote:
>> > >> > > 3. RT2860 802.11n controller authors Damien Bergamini and
>> > >> > > Alexander Egorenkov
>> > >> > > http://my.ddteam.net/files/2011-03-14_rt2860.patch only
>> > >> > > modification to work with RT2872 (embedded to RT305[02] F)
>> > >> > > wrote by me.
>> > >> >
>> > >> > Is this supposed to work on its own bringing support for Ralink
>> > >> > 2860 to FreeBSD? (The one in the Asus EeePC 901/1000H according
>> > >> > to http://wiki.freebsd.org/AsusEee .)
>> > >> >
>> > >> > > Remaining issues:
>> > >> > > RT2860 support only Open(no crypto) mode for RT305[02]F
>> > >> >
>> > >> > Does this mean WPA should work for RT2860? (Just not for the
>> > >> > chips you added support for?)
>> > >>
>> > >> As I know this driver support WPA, but best place to read/ask about
>> > >> this on this thread http://forums.freebsd.org/showthread.php?t=7010
>> > >>
>> > >> >
>> > >> > If this is supposed to bring RT2860 support to FreeBSD in
>> > >> > general:
>> > >> >
>> > >> > - Should it work on amd64 and i386?
>> > >> > - Should it work on 8.2-RELEASE?
>> > >> > - Should it work as a module?
>> > >> >
>> > >> > In case this is all supposed to work: I tried to create a module
>> > >> > on 8.2-RELEASE/amd64 by adding a simple
>> > >> > sys/modules/rt2860/Makefile (as I did not want to modify my
>> > >> > stock 8.2-RELEASE kernel). I only got to:
>> > >> >
>> > >> > In file included from
>> > >> > /usr/src/sys/modules/rt2860/../../dev/rt2860/rt2860.c:19:
>> > >> > @/dev/rt2860/rt2860_softc.h:52:24: error: opt_rt2860.h: No such
>> > >> > file or directory
>> > >> >
>> > >> > I do not find opt_rt2860.h anywhere in your patches. Assuming it
>> > >> > was optional, I have commented it out only to get to:
>> > >> >
>> > >> > cc1: warnings being treated as errors
>> > >> > /usr/src/sys/modules/rt2860/../../dev/rt2860/rt2860_pci.c:63:
>> > >> > warning: 'rt2860_pci_detach' declared 'static' but never defined
>> > >> >
>> > >> > Probably, I am doing something unsupported here (especially as
>> > >> > there is no if_rt2860_pci.c, which I would expect).
>> > >>
>> > >> No, it's me. Too much data, so I a little confused here.
>> > >> Patch targeting to start support RT3052F/RT3050F System on Chip.
>> > >> Which main part for embedded systems like routers, AP etc.
>> > >>
>> > >> To get it compiled need remove 'rt2860_pci_detach' declaration,
>> > >> because pci and obio interfaces have same detach device methods
>> > >> (rt2860_detach in rt2860.c)
>> > >>
>> > >> And opt_rt2860.h must be defined in sys/conf/options
>> > >>
>> > >> # options for the Ralink RT286x driver (rt2860)
>> > >> RT2860_DEBUGopt_rt2860.h
>> > >>
>> > >>
>> > >> >
>> > >> > Cheers,
>> > >> > Jan Henrik
>> > >>
>> > >> I will remake patch tomorrow.
>> >
>> > Fixed patch here http://my.ddteam.net/files/2011-03-17_rt2860.patch
>> >
>> include "opt_rt2860.h" still here (rt2860_softc.h), I removed it, write
>> simple Makefile:
>>
>> laptop# cat Makefile
>> # $FreeBSD$
>>
>> .PATH: ${.CURDIR}/../../dev/rt2860
>>
>> KMOD= if_rt2860
>> SRCS=
Re: [CFR]RT305xF support, w/o attachment
Hi again! On Wed, 16 Mar 2011 20:44:05 +0200 Aleksandr Rybalko wrote: >> Hi, >> >> On Wed, 16 Mar 2011 18:06:59 +0100 >> Jan Henrik Sylvester wrote: >> >> > Hello! >> > >> > On 01/-10/-28163 20:59, Aleksandr Rybalko wrote: >> > > 3. RT2860 802.11n controller authors Damien Bergamini and Alexander >> > > Egorenkov http://my.ddteam.net/files/2011-03-14_rt2860.patch >> > > only modification to work with RT2872 (embedded to RT305[02] >> > > F) wrote by me. >> > >> > Is this supposed to work on its own bringing support for Ralink 2860 >> > to FreeBSD? (The one in the Asus EeePC 901/1000H according to >> > http://wiki.freebsd.org/AsusEee .) >> > >> > > Remaining issues: >> > > RT2860 support only Open(no crypto) mode for RT305[02]F >> > >> > Does this mean WPA should work for RT2860? (Just not for the chips >> > you added support for?) >> >> As I know this driver support WPA, but best place to read/ask about >> this on this thread http://forums.freebsd.org/showthread.php?t=7010 >> >> > >> > If this is supposed to bring RT2860 support to FreeBSD in general: >> > >> > - Should it work on amd64 and i386? >> > - Should it work on 8.2-RELEASE? >> > - Should it work as a module? >> > >> > In case this is all supposed to work: I tried to create a module on >> > 8.2-RELEASE/amd64 by adding a simple sys/modules/rt2860/Makefile (as >> > I did not want to modify my stock 8.2-RELEASE kernel). I only got to: >> > >> > In file included from >> > /usr/src/sys/modules/rt2860/../../dev/rt2860/rt2860.c:19: >> > @/dev/rt2860/rt2860_softc.h:52:24: error: opt_rt2860.h: No such file >> > or directory >> > >> > I do not find opt_rt2860.h anywhere in your patches. Assuming it was >> > optional, I have commented it out only to get to: >> > >> > cc1: warnings being treated as errors >> > /usr/src/sys/modules/rt2860/../../dev/rt2860/rt2860_pci.c:63: >> > warning: 'rt2860_pci_detach' declared 'static' but never defined >> > >> > Probably, I am doing something unsupported here (especially as there >> > is no if_rt2860_pci.c, which I would expect). >> >> No, it's me. Too much data, so I a little confused here. >> Patch targeting to start support RT3052F/RT3050F System on Chip. >> Which main part for embedded systems like routers, AP etc. >> >> To get it compiled need remove 'rt2860_pci_detach' declaration, >> because pci and obio interfaces have same detach device methods >> (rt2860_detach in rt2860.c) >> >> And opt_rt2860.h must be defined in sys/conf/options >> >> # options for the Ralink RT286x driver (rt2860) >> RT2860_DEBUGopt_rt2860.h >> >> >> > >> > Cheers, >> > Jan Henrik >> >> I will remake patch tomorrow. Fixed patch here http://my.ddteam.net/files/2011-03-17_rt2860.patch >> >> Thanks for your report and questions? >> >> -- >> Aleksandr Rybalko Many thanks for help. -- Alexandr Rybalko aka Alex RAY ___ 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: [CFR]RT305xF support, w/o attachment
Hi, On Wed, 16 Mar 2011 18:06:59 +0100 Jan Henrik Sylvester wrote: > Hello! > > On 01/-10/-28163 20:59, Aleksandr Rybalko wrote: > > 3. RT2860 802.11n controller authors Damien Bergamini and Alexander > > Egorenkov http://my.ddteam.net/files/2011-03-14_rt2860.patch > > only modification to work with RT2872 (embedded to RT305[02] > > F) wrote by me. > > Is this supposed to work on its own bringing support for Ralink 2860 > to FreeBSD? (The one in the Asus EeePC 901/1000H according to > http://wiki.freebsd.org/AsusEee .) > > > Remaining issues: > > RT2860 support only Open(no crypto) mode for RT305[02]F > > Does this mean WPA should work for RT2860? (Just not for the chips > you added support for?) As I know this driver support WPA, but best place to read/ask about this on this thread http://forums.freebsd.org/showthread.php?t=7010 > > If this is supposed to bring RT2860 support to FreeBSD in general: > > - Should it work on amd64 and i386? > - Should it work on 8.2-RELEASE? > - Should it work as a module? > > In case this is all supposed to work: I tried to create a module on > 8.2-RELEASE/amd64 by adding a simple sys/modules/rt2860/Makefile (as > I did not want to modify my stock 8.2-RELEASE kernel). I only got to: > > In file included from > /usr/src/sys/modules/rt2860/../../dev/rt2860/rt2860.c:19: > @/dev/rt2860/rt2860_softc.h:52:24: error: opt_rt2860.h: No such file > or directory > > I do not find opt_rt2860.h anywhere in your patches. Assuming it was > optional, I have commented it out only to get to: > > cc1: warnings being treated as errors > /usr/src/sys/modules/rt2860/../../dev/rt2860/rt2860_pci.c:63: > warning: 'rt2860_pci_detach' declared 'static' but never defined > > Probably, I am doing something unsupported here (especially as there > is no if_rt2860_pci.c, which I would expect). No, it's me. Too much data, so I a little confused here. Patch targeting to start support RT3052F/RT3050F System on Chip. Which main part for embedded systems like routers, AP etc. To get it compiled need remove 'rt2860_pci_detach' declaration, because pci and obio interfaces have same detach device methods (rt2860_detach in rt2860.c) And opt_rt2860.h must be defined in sys/conf/options # options for the Ralink RT286x driver (rt2860) RT2860_DEBUGopt_rt2860.h > > Cheers, > Jan Henrik I will remake patch tomorrow. Thanks for your report and questions? -- Aleksandr Rybalko ___ 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: [CFT][patch]cfi driver support for NOR flash arrays
Hi Andrew, Marcel and list readers, On Tue, 15 Mar 2011 14:41:09 -0400 Andrew Duane wrote: > Marcel Moolenaar wrote: > > On Mar 14, 2011, at 8:09 AM, Aleksandr Rybalko wrote: > > > >> Hi, all. > >> > >> proposed patch add support of NOR flash arrays to cfi driver > >> http://my.ddteam.net/files/2011-03-11_cfi_flash_array_support.patch > > > > Hi Aleksandr, > > > > The patch is interesting, but combines a whole bunch of different > > changes. Some of the changes are similar to the fixes we have at > > Juniper ourselves, so getting the driver sync'd up is a good idea. > > Not to mention that we have added support for the SPI interface. > > > > Just a quick question: is an array different from 2 independent > > CFI devices on the same bus? I mean: can we support an array by > > having 2 driver instances? > > > > Thanks, > > Arrays can be horizontal or vertical. A vertical array is just two > chips, 0->X and X+1->YY. This would work with 2 driver > instances. > > Horizontal (interleaved) is two chips that share a single address > space and provide alternating bits/bytes/words. This would not work > with two instances. > > -- > > Andrew Duane Juniper Networks > 978-589-0551 10 Technology Park Dr > adu...@juniper.net Westford, MA 01886-3418 > Driver designed to handle "any" array configuration (limitation only 1,2,4,8 for interleaved), only one rule must be applied - flash chips must be same type, since driver don't handle different timing or sizes of other chips. So if for example we have: chip 1 at 0x1f00 size 4M - CS rise on A22=0 and A23=0 chip 2 at 0x1f40 size 4M - CS rise on A22=1 and A23=0 chip 3 at 0x1f80 size 4M - CS rise on A22=0 and A23=1 as result we get 12M array. If Marcel question in "can driver support more than one flash chip" - answer yes, that why I wrote this patch. But if you need join two devices located not back-to-back on bus - answer is no. For that case I think best choice strip down one of geom RAID modules like geom_strip or geom_concat. Maybe I misunderstand something, sorry for my English then. :) -- Aleksandr Rybalko ___ 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"
