Re: CFT: FreeBSD Package Base

[Joe Maloney]

With CFT version you chose to build, and package individual components such as 
sendmail with a port option.  That does entirely solve the problem of being 
able to reinstall sendmail after the fact without a rebuild of the userland 
(base) port but perhaps base flavors could solve that problem assuming flavors 
could extend beyond python.

Joe Maloney
Quality Engineering Manager / iXsystems
Enterprise Storage & Servers Driven By Open Source

> On Apr 29, 2019, at 3:31 PM, Cy Schubert  wrote:
> 
> In message <201904291441.x3tefmid072...@gndrsh.dnsmgr.net>, "Rodney W. 
> Grimes"
> writes:
>>> On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes <
>>> freebsd-...@gndrsh.dnsmgr.net> wrote:
>>> 
>>>>> 
>>>>> Correct, this is ZFS only. And it's something we're using specific to
>>>> FreeNAS / TrueOS, which is why I didn't originally mention it as apart of
>>>> our CFT.
>>>> 
>>>> Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only",
>>>> calling this FreeBSD pkg base when it is not was wrong,
>>>> and miss leading.
>>>> 
>>> 
>>> Sorry, I disagree.
>> Which is fine.
>> 
>>> This pkg base is independent of the ZFS tool we're using
>>> to wrangle boot-environments. Hence why it wasn't mentioned in the CFT.
>>> These base packages work the same as existing in-tree pkg base on UFS, no
>>> difference. If anything are probably safer due to being able to update all
>>> of userland in single extract operation, so you don't have out of order
>>> extraction of libc or some such.
>> 
>> You missed the major string change and focused on the edge,
>> No comment on calling iXsystems :stuff: FreeBSD instead of FreeNAS/TrueOS?
>> 
>> That was the major point of my statement, your miss leading the user
>> community, you yourself said this would never be imported into FreeBSD
>> base, so I see no reason that it should be called "FreeBSD package Base",
>> as it is not, that is a different project.
> 
> Taking the last comment on this thread to ask a question and maybe 
> refocus a little.
> 
> The discussion about granularity begs the question, why pkgbase in the 
> first place? My impression was that it allowed people to select which 
> components they wanted to either create a lean installation or mix and 
> match base packages and ports (possibly with flavours to install in 
> /usr rather than $LOCALBASE) such that maybe person A wanted a stock 
> install while person B wanted to replace, picking a random example, BSD 
> tar with GNU tar. Isn't that the real advantage of pkgbase?
> 
> If OTOH it's binary updates V 2.0, what's the point? I'm a little 
> rhetorical here but you get my point. If I want ipfw instead pf or 
> ipfilter instead of the others I should have the freedom. Similarly if 
> I want vim instead of vi I should have the choice to install vim as 
> /usr/bin/vi. Otherwise all the effort to replace binary updates makes 
> no sense.
> 
> 
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  http://www.FreeBSD.org
> 
>   The need of the many outweighs the greed of the few.
> 
> 
> ___
> 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"

___
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: drm / drm2 removal in 12

[Joe Maloney]

Thanks for the drm-next efforts.  I could not, and would not be using
FreeBSD without it.

Joe Maloney

On Mon, Aug 27, 2018 at 5:58 AM Thomas Mueller  wrote:

> Excerpt from Oliver Pinter:
>
> > Let's do some more step backwards, and see how the graphics driver
> > developments works from the corporation side.
> > They not bother about any of the BSDs, they focus only to Windows and
> > Linux. If you want to use a recent (haha recent, something after  2014)
> you
> > are forced to use new drivers from linux.
> > The fore/advantage on the Linux side are the zillions of corporately paid
> > kernel developers.
> > They can just focus on a new hw supports, on freebsd side, there are no
> > corporately paid drm driver developer. Sadly.
> > In linux word their internal KPI (try a Google for a "stable API
> nonsense"
> > words) moves so fastly, that porting of these drivers gets non trivial
> > without a dedicated paid team.
>
> > If you want to change on this situation, try to learn for you could help
> or
> > send directed donations to freebsd foundation. ;)
>
> Linux and FreeBSD are not the only open-source OSes.
>
> There is also (Net, Open, DragonFly)BSD, Haiku, OpenIndiana and others.
>
> Maybe better would be for the hardware manufacturers to release more
> general specifications that could be adapted to any OS, by the NetBSD
> developers, Haiku developers, etc.  Certainly not to ignore Linux.
>
> Tom
>
> ___
> freebsd-sta...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
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: LUA loader: bhyve now doesn't?

[Joe Maloney]

I ran into this as well months ago.  To workaround it I extracted
userboot.so for the VM's, and launched bhyve with the alternate
userboot.so.  You can use a flag as described in the manpage to start
userboot.so from an alternate location.

https://www.freebsd.org/cgi/man.cgi?query=bhyveload=8

Also support was recently added for vm-bhyve to specify alternate
userboot.so location for one that is compatible with 4th.  You just need to
extract that somewhere onto the host, and specify it to load when starting
the VM.

https://github.com/churchers/vm-bhyve/blob/d4532f6da3e155a4430acbb9138e59c0d5abfc39/sample-templates/config.sample

Alternatively you could just use UEFI, or UEFI-CSM firmware.

Joe Maloney
QA Manager / iXsystems
Enterprise Storage & Servers Driven By Open Source


On Sun, Aug 19, 2018 at 11:38 AM Larry Rosenman  wrote:

> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote:
> > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman  wrote:
> >
> > > With today's change to LUA as the loader, I seem to have an issue with
> > > bhyhve:
> > >
> > > Consoles: userboot
> > >
> > > FreeBSD/amd64 User boot, Revision 1.1
> > > (Thu Nov 16 15:04:02 CST 2017 r...@borg.lerctr.org)
> > > Startup error in /boot/lua/loader.lua:
> > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
> > >
> > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970
> > > syms=[0x8+0x14cf28+0x8+0x163e57]
> > > Hit [Enter] to boot immediately, or any other key for command prompt.
> > > Booting [/boot/kernel/kernel]...
> > >
> > > These VM's have been running for MONTHS.
> > >
> > > Ideas?
> > >
> >
> > There's no boot/lua/loader.lua.
> >
> > You can either fix that, or you can recompile with
> > LOADER_DEFAULT_INTERP=4th for the moment.
> actually on the host there is:
> borg.lerctr.org /home/ler $ ls -l /boot/lua/
> total 131
> -r--r--r--  1 root  wheel   3895 Aug 19 09:46 cli.lua
> -r--r--r--  1 root  wheel   3204 Aug 19 09:46 color.lua
> -r--r--r--  1 root  wheel  14024 Aug 19 09:46 config.lua
> -r--r--r--  1 root  wheel  10302 Aug 19 09:46 core.lua
> -r--r--r--  1 root  wheel   9986 Aug 19 09:46 drawer.lua
> -r--r--r--  1 root  wheel   3324 Aug 19 09:46 hook.lua
> -r--r--r--  1 root  wheel   2543 Aug 19 09:46 loader.lua
> -r--r--r--  1 root  wheel   2431 Aug 19 09:46 logo-beastie.lua
> -r--r--r--  1 root  wheel   2203 Aug 19 09:46 logo-beastiebw.lua
> -r--r--r--  1 root  wheel   1958 Aug 19 09:46 logo-fbsdbw.lua
> -r--r--r--  1 root  wheel   2399 Aug 19 09:46 logo-orb.lua
> -r--r--r--  1 root  wheel   2119 Aug 19 09:46 logo-orbbw.lua
> -r--r--r--  1 root  wheel  12010 Aug 19 09:46 menu.lua
> -r--r--r--  1 root  wheel   3941 Aug 19 09:46 password.lua
> -r--r--r--  1 root  wheel   2381 Aug 19 09:46 screen.lua
> borg.lerctr.org /home/ler $
>
> This is when booting the vm, and it's not on the vm's disk.
>
> So the bhyveload behavior *CHANGED*.
>
> POLA?
>
>
> >
> > Warner
> > ___
> > 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"
>
> --
> Larry Rosenman https://people.FreeBSD.org/~ler/
> Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
> US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
>
___
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: Boot freezing after kernel load - root on zfs

[Joe Maloney]

Ben,
do you by chance have multicons enabled with comconsole, vidconsole?  This 
looks exactly like a race we encountered where the remaining output was 
actually being redirected to serial on some systems when multicons was being 
used.  It appeared to be a lockup when it wasn’t because keyboard input would 
also break.

> On Jun 23, 2018, at 10:40 AM, Allan Jude  wrote:
> 
>> On 2018-06-23 00:37, Warner Losh wrote:
>> There were some issues with legacy geely booting recently. What version?
>> UEFI or legacy BIOS booting?
>> 
>> Warner 
>> 
>> On Fri, Jun 22, 2018, 10:26 PM Ben Woods > > wrote:
>> 
>>On 23 June 2018 at 12:08, Allan Jude >> wrote:
>> 
>>> If you just press shift a bunch of times, does it print the Mount root
>>> prompt?
>>> --
>>> Allan Jude
>>> 
>> 
>> 
>>No, unfortunately not. But please keep any troubleshooting suggestions
>>coming!
>> 
>>I have tried booting with the KVM monitor and USB disconnected, with the
>>same result.
>> 
>>It is also worth noting I can successfully boot from a USB stick running
>>the latest 12-current snapshot
>>FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there
>>I can
>>import both of my zpools (zroot and zstore), and then export them again
>>before rebooting - still can't boot from disk.
>> 
>>--
>>From: Benjamin Woods
>>woods...@gmail.com 
>>___
>>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
>>"
>> 
> 
> Warner: it is not that in this case, the screenshots show it getting
> just past mountroot, so it is well into the kernel when it is stopping.
> 
> -- 
> Allan Jude
> 
___
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: [RFC] Deprecation and removal of the drm2 driver

[Joe Maloney]

I personally wish that more drivers, and firmware were separated from
base.

For example wireless firmware:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433

That was a ticket which I chimed in on about a firmware I needed to make my
wireless adapter work.  I went through numerous efforts on IRC, and
elsewhere to try to bring attention that ticket in order to attempt to get
that firmware backported for several 10.x releases in a row without
success.  The firmware worked perfectly fine in PC-BSD where it was cherry
picked for numerous 10.x releases.

Technically since I was using PC-BSD, and was a committer for that project
I had no real dire need to reach out to FreeBSD about the issue.  I was
simply trying to help anyone else who might be encountering the same issue
trying to use stock FreeBSD because it was a simple backport.  If my effort
had turned out to be more fruitful I would have spent more time pursuing
tickets, diffs, or whatever to get more things back-ported when I found
them.  I am not sure where the breakdown was which did not allow that to
happen.  Anyways I don't want to bikeshed, or anything but I just wanted to
point out how I think having more drivers, and firmware in ports could be
helpful to enhance compatibility for end users.

Having a separate port for legacy drm could definitely make things easier
to providing installation options for end users, and automating the post
install action chosen in TrueOS, GhostBSD, and future derivative projects
tailored for the desktop use case.  For example for TrueOS we boot the
installer in failsafe mode with either VESA, or SCFB depending on whether
or not BIOS, or EFI is booted.  Then we could simply make a checkbox for
legacy intel, or skylake + to install the correct package then the module
path for either driver can more or less remain the same.  Eventually with
something like devmatch maybe that can even be fully automatic.

Joe Maloney

On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen 
wrote:

> On Thu, 31 May 2018, Konstantin Belousov wrote:
>
> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>>
>> We're not replacing anything. We are moving the older drm1 and drm2 from
>>> kernel to ports to make it easier for the majority of the users to load
>>> the
>>> correct driver without conflicts.
>>>
>>
>> You do understand that you increase your maintainence load by this move.
>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable
>> branches, so you will need to chase these updates.
>>
>
> I agree.  One argument previously made was that it's easier
> to maintain in ports.  One data point from me - I rarely
> update my ports, I update my OS much more frequently.  In
> fact, some times my ports get so out of date I just
> (take off and) nuke /usr/local (from orbit, it's the only
> way to be sure).
>
> Also, are we trying to solve a problem by moving drm[2] to
> ports that won't be a problem when base is pkg'ized?  If
> drm[2] is a package unto itself, then you don't have this
> problem of ports conflicting with it, at least not so
> much.  You can either not install the base drm[2] package
> or deinstall it to make way for a conflicting port.  Once
> drm[2] is pkg rm'd, it's not going to be reinstalled
> again when you update the base OS.
>
> And don't we have the same problem with sendmail and a
> few other base services?
>
> --
> DE
>
> ___
> 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"
>
___
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: 12-Current panics on boot (didn't a week ago.)

[Joe Maloney]

ity 350
> Event timer "HPET2" frequency 14318180 Hz quality 350
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> pcib0:  port 0xcf8-0xcff on acpi0
> pci0:  on pcib0
> amdsmn0:  on hostb0
> amdtemp0:  on hostb0
>
>
> On Sun, Mar 25, 2018 at 04:35:31AM +, Jonathan Looney wrote:
> > For now, you can update through r331485 and then take TCP_BLACKBOX out of
> > your kernel config file. That won’t really “fix” anything, but should at
> > least get you a booting system (assuming the new code from r331347 is
> > really triggering a problem).
> >
> >
> > I’ll take another look to see if I missed something in the commit. But,
> at
> > the moment, I’m hard-pressed to see how r331347 would cause the problem
> you
> > describe.
> >
> >
> > Jonathan
> >
> > On Sat, Mar 24, 2018 at 9:17 PM Andrew Reilly <arei...@bigpond.net.au>
> > wrote:
> >
> > > OK, I've completed the search: r331346 works, r331347 panics
> > > somewhere in the initialization of random.
> > >
> > > In the 331347 change (Add the "TCP Blackbox Recorder") I can't see
> > > anything obvious to tweak, unfortunately.  It's a fair chunk of new
> > > code but it's all network-stack related, and my kernel is panicking
> > > long before any network activity happens.
> > >
> > > Any suggestions?
> > >
> > > Cheers,
> > >
> > > Andrew
> > >
> > > On Sat, Mar 24, 2018 at 05:23:18PM -0600, Warner Losh wrote:
> > > > Thanks Andrew... I can't recreate this on my VM nor my real hardware.
> > > >
> > > > Warner
> > > >
> > > > On Sat, Mar 24, 2018 at 5:22 PM, Andrew Reilly <
> arei...@bigpond.net.au>
> > > > wrote:
> > > >
> > > > > So, r331464 crashes in the same place, on my system.  r331064 still
> > > boots
> > > > > OK.  I'll keep searching.
> > > > >
> > > > > One week ago there was a change to randomdev to poll for signals
> every
> > > so
> > > > > often, as a defence against very large reads.  That wouldn't have
> > > > > introduced a race somewhere,
> > > > > or left things in an unexpected state, perhaps?  That change
> (r331070)
> > > by
> > > > > cem@ is just a few revisions after the one that is working for me.
> > > I'll
> > > > > start looking there...
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Andrew
> > > > >
> > > > > On Sun, Mar 25, 2018 at 07:49:17AM +1100, Andrew Reilly wrote:
> > > > > > Hi Warner,
> > > > > >
> > > > > > The breakage was in 331470,  and at least one version earlier,
> that I
> > > > > updated past when it panicked.
> > > > > >
> > > > > > I'm guessing that kdb's inability to dump would be down to it not
> > > having
> > > > > found any disk devices yet, right?  So yes, bisecting to narrow
> down
> > > the
> > > > > issue is probably the best bet.  I'll try your r331464: if that
> works
> > > that
> > > > > leaves only four or five revisions.  Of course the breakage could
> be
> > > > > hardware specific.
> > > > > >
> > > > > > Cheers,
> > > > > > --
> > > > > > Andrew
> > > > >
> > >
> > ___
> > 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"
> ___
> 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"
>


-- 
Joe Maloney
QA Manager / iXsystems
Enterprise Storage & Servers Driven By Open Source
___
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"

newcons splash screen

[Joe Maloney]

Hello, 
is it possible to use a splash screen yet with newcons? I've been looking at 
the source code for VT, and it would appear there has been some work done 
towards this? 

https://github.com/freebsd/freebsd/blob/master/sys/dev/vt/vt.h 

Also the wiki page shows limited support: 

https://wiki.freebsd.org/Newcons 

I've tried the standard method of enabling a splash screen but it of course 
does not work. I don't think I was able to get it to work with syscons either 
whereas it used to work. 

https://www.freebsd.org/doc/handbook/boot-splash.html 

Is there another way? Or is it still not ready yet? 

Joe Maloney 
___
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: Packaging the FreeBSD base system with pkg(8)

[Joe Maloney]

Awesome.  Thanks for the update, and info Glen.  It looks like I will be 
subscribing to another list tonight!


Joe Maloney

On 01/27/16 16:33, Glen Barber wrote:

As many know, work has been in progress for quite some time to provide
the ability to package and upgrade the FreeBSD base system using pkg(8).
The majority of the initial implementation has provided much of the core
functionality to make this possible, however much work still needs to be
done.

Over the past few weeks, there have been several inquiries on if this
work is still targeted for the 11.0-RELEASE, as well as the status of
the project branch (base/projects/release-pkg).

The answer to the first question is: Yes.  This is still targeted for
11.0-RELEASE, which was one of the requirements during discussion of the
new support model announced early last year [1].

The status of the in progress work is a bit more complex to answer in
a short email, but work on packaging the FreeBSD base system is indeed
ongoing, and has been my primary focus over the past several weeks.

I am finishing an initial list of outstanding items that need to be
resolved before the project branch can feasibly merged back to head,
which I will send to the new freebsd-pkgbase@ mailing list.  People
interested in discussion surrounding this topic are urged to subscribe:

 https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase

Finally, I want to personally thank Baptiste Daroussin for all of his
tireless efforts to get us to the point we are at now.  Without his
ideas and insights, as well as ensuring pkg(8) contained the necessary
functionality, we would not be anywhere close to completing this work
for the 11.0-RELEASE.

[1]
https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html

Thanks.

Glen



___
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: isofs kernel panic

[Joe Maloney]

For me installing the binary dists from the latest snapshot into a jail 
will produce a panic, and reboot on the host as well.  I noticed this while 
trying to generate an ISO.  The older dists from early the December 
snapshot worked without issue.


Joe Maloney


On December 27, 2015 10:35:43 AM Allan Jude <allanj...@freebsd.org> wrote:


On 2015-12-27 03:38, Shawn Webb wrote:

Hey All,

This is from booting a new installer ISO, generated today from a very
recent commit:

=== Begin Log ===
Trying to mount root from cd9660:/dev/iso9660/11_0__HBSD_AMD64_CD [ro]...
lock order reversal:
 1st 0xfe00f6222e40 bufwait (bufwait) @ 
 /jenkins/workspace/HardenedBSD-master-amd64/sys/vm/vm_pager.c:380
 2nd 0xf800063785f0 isofs (isofs) @ 
 /jenkins/workspace/HardenedBSD-master-amd64/sys/kern/imgact_elf.c:883

stack backtrace:
#0 0x80a7ce70 at witness_debugger+0x70
#1 0x80a7cd71 at witness_checkorder+0xe71
#2 0x80a0033b at __lockmgr_args+0xd3b
#3 0x80ac2fdc at vop_stdlock+0x3c
#4 0x80fc0fc0 at VOP_LOCK1_APV+0x100
#5 0x80ae397a at _vn_lock+0x9a
#6 0x809c4b01 at exec_elf64_imgact+0xa91
#7 0x809e35e9 at kern_execve+0x4b9
#8 0x809e2ddc at sys_execve+0x4c
#9 0x809c760a at start_init+0x26a
#10 0x809eadb4 at fork_exit+0x84
#11 0x80e4e9ae at fork_trampoline+0xe
userret: returning with the following locks held:
exclusive lockmgr bufwait (bufwait) r = 0 (0xfe00f6222c10) locked @ 
/jenkins/workspace/HardenedBSD-master-amd64/sys/vm/vm_pager.c:380
exclusive lockmgr bufwait (bufwait) r = 0 (0xfe00f6222e40) locked @ 
/jenkins/workspace/HardenedBSD-master-amd64/sys/vm/vm_pager.c:380

panic: witness_warn
=== End Log ===

This is 11-CURRENT/amd64, based on HardenedBSD commit
f0a4c61a2e9e2433db632d70d5764e79c5b84b7a. I booted the ISO up in bhyve
using vmrun.sh. I haven't ruled out anything on HardenedBSD's side, yet,
but we don't have any changes that would cause a panic'ing LOR in
vm_pager.c. I'll do some more investigative work when I get some more
sleep. But if anyone has any ideas, please let me know. I kinda wonder
if this is related to the recent VFS changes by FreeBSD.

Thanks,



I saw the same thing with an ISO I made last night, but also see it with
the latest official snapshot ISO as well.

--
Allan Jude




___
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: SVN r292469 breaks VirtualBox

[Joe Maloney]

I ran into this months earlier with NextBSD.  Replacing 
vm_pageout_grow_cache(). in memobj-r0drv-freebsd.c with this fixed the issue:

vm_pageout_reclaim_contig(1, 0, VM_MAX_ADDRESS, PAGE_SIZE, 0, 3);

Joe Maloney

> On Dec 19, 2015, at 7:45 PM, Alan Cox <a...@rice.edu> wrote:
> 
> On 12/19/2015 19:00, Michael Butler wrote:
>> While the kernel modules will build, they won't load ..
>> 
>> kernel: linker_load_file: Unsupported file type
>> kernel: link_elf_obj: symbol vm_pageout_grow_cache undefined
>> kernel: linker_load_file: Unsupported file type
>> kernel: KLD vboxnetflt.ko: depends on vboxdrv - not available or version
>> mismatch
>> kernel: linker_load_file: Unsupported file type
>> kernel: link_elf_obj: symbol vm_pageout_grow_cache undefined
>> kernel: linker_load_file: Unsupported file type
>> kernel: KLD vboxnetadp.ko: depends on vboxdrv - not available or version
>> mismatch
>> kernel: linker_load_file: Unsupported file type
>> 
> 
> VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c will need to be
> patched to use vm_page_reclaim_contig() instead of vm_pageout_grow_cache().
> 
> ___
> 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"

___
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: Base Packaging in 11

[Joe Maloney]

I have been experimenting with this, and have successfully packaged base.  I 
figured out that make packages would do that.

http://skynet.desktopbsd.net/packages/

I have been unable to figure out how to package the kernel yet.  Is it possible 
at this stage to do that with another command, or is it something that will be 
added later?  I would love to be an early tester, and help out with this effort.

Joe Maloney

> On Dec 18, 2015, at 8:05 PM, Baptiste Daroussin <b...@freebsd.org> wrote:
> 
> On Fri, Dec 18, 2015 at 03:21:13PM -0800, Roger Marquis wrote:
>> Forwarding this from freebsd-security in case anyone here can update us
>> regarding the status of base packaging or has URLs for projects/release-pkg.
>> 
>> Roger
>> 
> Packaging base is happening here:
> https://svnweb.freebsd.org/base/projects/release-pkg/
> 
> It is mostly stalled for month due to lack of time working on it.
> The TODO list is mostly:
> - implement priotity in plist for pkg to ensure the ordre files will be 
> replaced
> - finishing flexible dependencies and use it by default in pkg
> - tracking down all issues from installworld that results files not installed 
> by
>  install(1) and files installed twice
> 
> In my opinion it should not be made the default mechanism for 11.0-RELEASE if 
> we
> are not able to provide our first packages for testing by the end of january 
> to
> leave enough time for testing and fixes before the release.
> 
> While I was pretty confident few month ago, things has changed since and I
> cannot spend the necessary time on it for various reasons.
> 
> Best regards,
> Bapt

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

Re: EFI and i915kms questions

[Joe Maloney]

FYI it’s changed a bit more, and line 372 is now line 364 with different 
options.  Going to try this first which was now at line 364.

https://github.com/pkgdemon/freebsd/commit/f72323b10a9dd6da79f0dae1a6fd68823ec66f7d

Joe Maloney

> On Dec 3, 2015, at 11:58 AM, Joe Maloney <jmalo...@pcbsd.org> wrote:
> 
> Will give this a try, build an image and report back for sure.  Thanks!
> 
> Joe Maloney
> 
>> On Dec 2, 2015, at 1:39 AM, Jean-Sébastien Pédron 
>> <jean-sebastien.ped...@dumbbell.fr> wrote:
>> 
>> On 02/12/2015 02:00, John Baldwin wrote:
>>> Note that at the top of the function it invokes IICBUS_TRANSFER on a 
>>> different
>>> device when force_bit_dev is true:
>>> 
>>> 370 sx_xlock(_priv->gmbus_sx);
>>> 371 if (sc->force_bit_dev) {
>>> 372 dumbbell282199  error = 
>>> -IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
>>> 373 kib 235783  goto out;
>>> 374 }
>>> 
>>> Hmm, I would try changing the line at 470 to match the line at 372.
>>> 
>>> They used to match, and then this change:
>> 
>> You're right. This is something I fixed in my i915 update branch but
>> forgot to commit to HEAD...
>> 
>> Joe, could you please try what John suggests to confirm?
>> 
>> -- 
>> Jean-Sébastien Pédron
>> 
> 
> ___
> 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"

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

Re: EFI and i915kms questions

[Joe Maloney]

It works!  Would it be helpful if I did a pull request from github, or just let 
you guys take it from here?  Thanks for helping me figure out how to get up, 
and running!  This will be so much better than the framebuffer driver I was 
having to use.

Joe Maloney

> On Dec 3, 2015, at 12:33 PM, Joe Maloney <jmalo...@pcbsd.org> wrote:
> 
> FYI it’s changed a bit more, and line 372 is now line 364 with different 
> options.  Going to try this first which was now at line 364.
> 
> https://github.com/pkgdemon/freebsd/commit/f72323b10a9dd6da79f0dae1a6fd68823ec66f7d
> 
> Joe Maloney
> 
>> On Dec 3, 2015, at 11:58 AM, Joe Maloney <jmalo...@pcbsd.org> wrote:
>> 
>> Will give this a try, build an image and report back for sure.  Thanks!
>> 
>> Joe Maloney
>> 
>>> On Dec 2, 2015, at 1:39 AM, Jean-Sébastien Pédron 
>>> <jean-sebastien.ped...@dumbbell.fr> wrote:
>>> 
>>> On 02/12/2015 02:00, John Baldwin wrote:
>>>> Note that at the top of the function it invokes IICBUS_TRANSFER on a 
>>>> different
>>>> device when force_bit_dev is true:
>>>> 
>>>> 370sx_xlock(_priv->gmbus_sx);
>>>> 371if (sc->force_bit_dev) {
>>>> 372dumbbell282199  error = 
>>>> -IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
>>>> 373kib 235783  goto out;
>>>> 374}
>>>> 
>>>> Hmm, I would try changing the line at 470 to match the line at 372.
>>>> 
>>>> They used to match, and then this change:
>>> 
>>> You're right. This is something I fixed in my i915 update branch but
>>> forgot to commit to HEAD...
>>> 
>>> Joe, could you please try what John suggests to confirm?
>>> 
>>> -- 
>>> Jean-Sébastien Pédron
>>> 
>> 
>> ___
>> 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"
> 
> ___
> 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"

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

Re: EFI and i915kms questions

[Joe Maloney]

Will give this a try, build an image and report back for sure.  Thanks!

Joe Maloney

> On Dec 2, 2015, at 1:39 AM, Jean-Sébastien Pédron 
> <jean-sebastien.ped...@dumbbell.fr> wrote:
> 
> On 02/12/2015 02:00, John Baldwin wrote:
>> Note that at the top of the function it invokes IICBUS_TRANSFER on a 
>> different
>> device when force_bit_dev is true:
>> 
>> 370  sx_xlock(_priv->gmbus_sx);
>> 371  if (sc->force_bit_dev) {
>> 372  dumbbell282199  error = 
>> -IICBUS_TRANSFER(dev_priv->bbbus[unit], msgs, nmsgs);
>> 373  kib 235783  goto out;
>> 374  }
>> 
>> Hmm, I would try changing the line at 470 to match the line at 372.
>> 
>> They used to match, and then this change:
> 
> You're right. This is something I fixed in my i915 update branch but
> forgot to commit to HEAD...
> 
> Joe, could you please try what John suggests to confirm?
> 
> -- 
> Jean-Sébastien Pédron
> 

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

Re: EFI and i915kms questions

[Joe Maloney]

Thank you.  For what it’s worth I was able to grab a dump after setting that 
sysctl.  It looks like this maybe the culprit?

panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ 
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:362

Since it is to large for posting here.  I will include a link to the entire 
dump on pastebin if anyone is interesting in looking at it.

http://pastebin.com/mzS5svy8

In addition I did a little further testing to narrow down the issue.

10.1-RELEASE WORKS
10.2-RELEASE WORKS

I recall trying a 10.2-STABLE image that crashed as well.  I can tell you for 
sure that the following releases all the way back to August have the issue for 
CURRENT.

FreeBSD-11.0-CURRENT-amd64-20150804-r286285-memstick.img
FreeBSD-11.0-CURRENT-amd64-20150917-r287930-memstick.img
FreeBSD-11.0-CURRENT-amd64-20151001-r288459-memstick.img
FreeBSD-11.0-CURRENT-amd64-20151119-r291085-memstick.img

If there is an archive of older images for CURRENT I would be happy to try 
those to help further narrow down where things broke.

Joe Maloney


> On Nov 21, 2015, at 5:53 AM, Jean-Sébastien Pédron 
> <jean-sebastien.ped...@dumbbell.fr> wrote:
> 
> On 13/11/2015 18:15, Joe Maloney wrote:
>> Hello,
> 
> Hi!
> 
>> Sometime after changes in FreeBSD 10-STABLE, 10.2 onwards, and 
>> recent 11 CURRENT the resolution no longer sets properly when using
>> UEFI boot. It now boots with a 640x480 resolution, and kldload
>> i915kms results in a black screen. I have not been able to grab a
>> debug log, or crash dump even with all of the debugging features
>> turned on. I cannot ssh into the laptop when this panic occurs, and
>> the screen is black so I can’t really see what happened. I’m curious
>> if there is anything else I can do besides enabling dumpdev or
>> kldload -v i915kms > output.txt that doesn’t give me any detail.
>> Nothing shows up in /var/crash or whatever the directory was.
> 
> You could try to set debug.debugger_on_panic=0 in /etc/sysctl.conf. It
> often helps to at least get core dumps when the crash happens in a video
> driver.
> 
> -- 
> Jean-Sébastien Pédron
> 

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

EFI and i915kms questions

[Joe Maloney]

Hello,
please let me know if this isn’t the best list to ask these particular 
questions, and which list is.  I have an Acer Travelmate P653 model MS2352 with 
an Intel HD4000 (I think) Gen 3 graphics card.  Unfortunately pciconf, and 
dmesg do not show useful information other than intel gen3 graphics.  This 
laptop doesn’t give me the option to disable CSM.  It also boots whatever is 
available whether EFI only is selected or not.  FreeBSD 10.1 worked on this 
laptop, and loaded i915kms properly.  PCBSD has always worked, and still works 
even with their 11 CURRENT images which no longer use grub.

Sometime after changes in FreeBSD 10-STABLE, 10.2 onwards, and recent 11 
CURRENT the resolution no longer sets properly when using UEFI boot.  It now 
boots with a 640x480 resolution, and kldload i915kms results in a black screen. 
 I have not been able to grab a debug log, or crash dump even with all of the 
debugging features turned on.  I cannot ssh into the laptop when this panic 
occurs, and the screen is black so I can’t really see what happened.  I’m 
curious if there is anything else I can do besides enabling dumpdev or kldload 
-v i915kms > output.txt that doesn’t give me any detail.  Nothing shows up in 
/var/crash or whatever the directory was.

I’ve noticed if I compile from PCBSD’s fork of FreeBSD current source on top of 
FreeBSD it works.  I have been unable to track down the difference at this 
point.  I’ve been working on it for a few months but I have not figured it out. 
 I would appreciate any help I could get in tracking down the cause to fix the 
problem for others.  I can’t seem to find that it’s a problem for anyone else 
however after months of research.

I did find one interesting thing.  If I mount the EFI partition, and replace 
/mnt/efi/boot/bootx64.efi (boot1.efi) with loader.efi by cp /boot/loader.efi 
/mnt/efi/boot/bootx64.efi i get full 1366x768 console resolution.  I can then 
use scfb at least if I delete the i915kms* drivers to start X.

I tested boot1.efi on a mac, and it of course sets the proper 1920x1080 
resolution it should.  I am curious what the difference is between boot1.efi, 
and loader.efi.  Is a device id or something missing from boot1.efi for my 
laptop to set the proper resolution?  It’s it the fact that I can’t disable 
CSM, and it’s somehow booting non EFI?  Can I remove certain things don’t force 
EFI only, or somehow force FreeBSD to disable CSM?  Can I somehow roll an EFI 
only release of FreeBSD for further testing?  If so what would I need to 
remove, or disable?  Does anyone have any suggestions on what I could try to 
gather dump information as well regarding the i915kms lockup?

Joe Maloney



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