Re: Crash during boot [g_part_wither()?] @r329259

2018-02-14 Thread Justin Hibbits 
On Wed, Feb 14, 2018 at 8:49 AM, David Wolfskill  wrote:
> On Wed, Feb 14, 2018 at 06:09:51AM -0800, Cy Schubert wrote:
>> Try reverting this https://svnweb.freebsd.org/changeset/base/329225 for now.
>> 
>
> Aye; thanks:  after 'svn merge -c -329225 ^/head /usr/src' & a
> rebuild/install, the boot completes:
>
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #104  
> r329259M/329260:1200058: Wed Feb 14 06:40:10 PST 2018 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
> amd64
>
> Thanks!
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> The circus around that memo helps confirm that Mr. Trump is unfit for office.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Hi David,

Sorry, this was my fault.  I didn't think the partition table could
ever have NULL(incomplete?) entries, but I was wrong.  Fixed with
r329262.

- Justin
___
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 boot loader coming very soon

2018-02-14 Thread David Wolfskill 
Also, after reverting r329225, I was able to build & boot the build
machine with the Lua loader... but I didn't even see any way of
interacting with it on the serial console.  (I do get that opportunity
with the Forth loader.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Crash during boot [g_part_wither()?] @r329259

2018-02-14 Thread David Wolfskill 
On Wed, Feb 14, 2018 at 06:09:51AM -0800, Cy Schubert wrote:
> Try reverting this https://svnweb.freebsd.org/changeset/base/329225 for now.
> 

Aye; thanks:  after 'svn merge -c -329225 ^/head /usr/src' & a
rebuild/install, the boot completes:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #104  
r329259M/329260:1200058: Wed Feb 14 06:40:10 PST 2018 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

RE: Crash during boot [g_part_wither()?] @r329259

2018-02-14 Thread Cy Schubert 
Try reverting this https://svnweb.freebsd.org/changeset/base/329225 for now.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
 or 
The need of the many outweighs the greed of the few.
---

-Original Message-
From: David Wolfskill
Sent: 14/02/2018 05:04
To: curr...@freebsd.org
Subject: Crash during boot [g_part_wither()?] @r329259

I got one of these on each of my laptop and build machine; details
beelow are from the build machine (which has a serial console and
runs a vanilla GENERC kernel).

Previous (successful) builld was r329197 (for both machines), yesterday.

Copy/paste from serial console:

...
da1: Serial Number 2010081884130
da1: 40.000MB/s transfers
da1: Attempt to query device size failed: NOT READY, Medium not present
da1: quirks=0x2
ugen0.3:  at usbus0
da1: Delete methods: 
ukbd0 on uhub1
ukbd0:  on 
usbus0
pass8 at umass-sim0 bus 0 scbus6 target 0 lun 2
kbd2 at ukbd0
kbd2: ukbd0, generic (0), config:0x0, flags:0x3dpass8:  Removable Direct Access SCSI device

pass8: Serial Number 2010081884130
pass8: 40.000MB/s transfersrandom: harvesting attach, 8 bytes (4 bits) from 
ukbd0

da2 at umass-sim0 bus 0 scbus6 target 0 lun 2
da2:  Removable Direct Access SCSI device
da2: Serial Number 2010081884130
da2: 40.000MB/s transfers
da2: Attempt to query device size failed: NOT READY, Medium not present
da2: quirks=0x2
da2: Delete methods: 
(probe0:umass-sim0:0:0:3): Down reving Protocol Version from 2 to 0?


Fatal trap 12: page fault while in kernel mode
pass9 at umass-sim0 bus 0 scbus6 target 0 lun 3
cpuid = 4; apic id = 04
fault virtual address   = 0x78
pass9:  Removable Direct Access SCSI device
fault code  = supervisor write data, page not present
pass9: Serial Number 2010081884130
ugen0.4:  at usbus0
pass9: 40.000MB/s transfersinstruction pointer  = 0x20:0x80a20c87

stack pointer   = 0x28:0xfe428a10
da3 at umass-sim0 bus 0 scbus6 target 0 lun 3
da3:  Removable Direct Access SCSI device
da3: Serial Number 2010081884130
da3: 40.000MB/s transfers
da3: Attempt to query device size failed: NOT READY, Medium not present
da3: quirks=0x2
frame pointer   = 0x28:0xfe428a30
da3: Delete methods: 
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (g_event)
[ thread pid 13 tid 100044 ]
Stopped at  g_part_wither+0x37: movq$0,offset+0x40(%rdi)
db> bt
Tracing pid 13 tid 100044 td 0xf800039d2000
g_part_wither() at g_part_wither+0x37/frame 0xfe428a30
g_run_events() at g_run_events+0x344/frame 0xfe428a70
fork_exit() at fork_exit+0x84/frame 0xfe428ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe428ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db> 


(This is still using the Forth loader, FWIW.)

On the laptop, I tried issuing the "panic" command (within ddb), and got
a core file, but the result appears to be a 'panic: from debugger', and
the stack trace doesn't reflect the above, so it's not clear to me that
that was a useful thing for me to have done.

Is there some poking I can do to this to shed more light?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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 boot loader coming very soon

2018-02-14 Thread David Wolfskill 
On Mon, Feb 12, 2018 at 08:27:27AM -0700, Warner Losh wrote:
> ...
> So please give it a spin and give me any feedback, documentation updates
> and/or bug fixes. I'm especially interested in reviews from people that
> have embedded Lua in other projects or experts in Lua that can improve the
> robustness of the menu code.
> 

I was able to build, install, and (start to -- not loader's fault)
boot my laptop; I have placed screenshots at
.

Some notes:
* For loader_1_lua.jpg, I had (reflexively) already hit "v" to boot
  verbosely, so "Verbose:On" does NOT reflect the default.  On the
  other hand, "ACPI   :off" DOES reflect the default, which is
  opposite from the Forth loader (ref. loader_1_4th.jpg); I suspect that
  this warrants changing.

* The lower left corner of the box seems to have an odd artifact for the
  Lua loader.  I haven't looked, but suspect it will be easy to fix.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Crash during boot [g_part_wither()?] @r329259

2018-02-14 Thread David Wolfskill 
I got one of these on each of my laptop and build machine; details
beelow are from the build machine (which has a serial console and
runs a vanilla GENERC kernel).

Previous (successful) builld was r329197 (for both machines), yesterday.

Copy/paste from serial console:

...
da1: Serial Number 2010081884130
da1: 40.000MB/s transfers
da1: Attempt to query device size failed: NOT READY, Medium not present
da1: quirks=0x2
ugen0.3:  at usbus0
da1: Delete methods: 
ukbd0 on uhub1
ukbd0:  on 
usbus0
pass8 at umass-sim0 bus 0 scbus6 target 0 lun 2
kbd2 at ukbd0
kbd2: ukbd0, generic (0), config:0x0, flags:0x3dpass8:  Removable Direct Access SCSI device

pass8: Serial Number 2010081884130
pass8: 40.000MB/s transfersrandom: harvesting attach, 8 bytes (4 bits) from 
ukbd0

da2 at umass-sim0 bus 0 scbus6 target 0 lun 2
da2:  Removable Direct Access SCSI device
da2: Serial Number 2010081884130
da2: 40.000MB/s transfers
da2: Attempt to query device size failed: NOT READY, Medium not present
da2: quirks=0x2
da2: Delete methods: 
(probe0:umass-sim0:0:0:3): Down reving Protocol Version from 2 to 0?


Fatal trap 12: page fault while in kernel mode
pass9 at umass-sim0 bus 0 scbus6 target 0 lun 3
cpuid = 4; apic id = 04
fault virtual address   = 0x78
pass9:  Removable Direct Access SCSI device
fault code  = supervisor write data, page not present
pass9: Serial Number 2010081884130
ugen0.4:  at usbus0
pass9: 40.000MB/s transfersinstruction pointer  = 0x20:0x80a20c87

stack pointer   = 0x28:0xfe428a10
da3 at umass-sim0 bus 0 scbus6 target 0 lun 3
da3:  Removable Direct Access SCSI device
da3: Serial Number 2010081884130
da3: 40.000MB/s transfers
da3: Attempt to query device size failed: NOT READY, Medium not present
da3: quirks=0x2
frame pointer   = 0x28:0xfe428a30
da3: Delete methods: 
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 13 (g_event)
[ thread pid 13 tid 100044 ]
Stopped at  g_part_wither+0x37: movq$0,offset+0x40(%rdi)
db> bt
Tracing pid 13 tid 100044 td 0xf800039d2000
g_part_wither() at g_part_wither+0x37/frame 0xfe428a30
g_run_events() at g_run_events+0x344/frame 0xfe428a70
fork_exit() at fork_exit+0x84/frame 0xfe428ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe428ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db> 


(This is still using the Forth loader, FWIW.)

On the laptop, I tried issuing the "panic" command (within ddb), and got
a core file, but the result appears to be a 'panic: from debugger', and
the stack trace doesn't reflect the above, so it's not clear to me that
that was a useful thing for me to have done.

Is there some poking I can do to this to shed more light?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

2018-02-14 Thread Vladimir Zakharov 
On Tue, Feb 13, 2018, Bryan Drewery wrote:
> On 2/13/2018 1:48 AM, Vladimir Zakharov wrote:
> > On Mon, Feb 12, 2018, Bryan Drewery wrote:
> >> On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
> >>> Hello, Bryan!
> >>>
> >>> On Fri, Feb 09, 2018, Bryan Drewery wrote:
>  On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> > Hello!
> >
> > For some time (about a week) building and installing kernel fails with
> > the error "Variable OBJTOP is recursive." when going to build/install
> > module from ports.
> >
> > Last successful build was at r328426. Next build at r328527 failed and
> > still broken at r328649.
> >
> > Without PORTS_MODULES building and installing kernel succeeds. Another
> > workaround: ignore error and build/install module directly from ports.
> > ...
> 
>  For some reason I cannot recreate this issue.
> >>>
> >>> It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
> >>> At least, removing it fixes build for me.
> >>>
> >>> Build successful with the following settings:
> >>> # cat /etc/src-env.conf
> >>> WITH_META_MODE=
> >>> #WITH_AUTO_OBJ=
> >>>
> >>
> >> Please try this patch (requires a buildkernel).
> >>
> >> https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
> >>
> > 
> > Fixed partly:
> > | buildkernel  | installkernel |
> > r329196 | OK   | FAIL(*)   |
> > r329169 + patch | OK   | OK|
> > r329196 + WITH_AUTO_OBJ | FAIL |   |
> > r329169 + WITH_AUTO_OBJ + patch | FAIL |   |
> > 
> > (*) - same error "Variable OBJTOP is recursive".
> > 
> 
> Thanks, r329232 should fix it.

Not yet. 'installkernel' still fails (see below). Can be fixed either by
explicit setting WITHOUT_AUTO_OBJ in /etc/src-env.conf or by applying
previous patch (s/build/stage/ in kern.post.mk:89).

# svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 329259
Node Kind: directory
Schedule: normal
Last Changed Author: eadler
Last Changed Rev: 329259
Last Changed Date: 2018-02-14 10:59:30 +0300 (Wed, 14 Feb 2018)

# cat /etc/src-env.conf
WITH_META_MODE=
#WITH_AUTO_OBJ=

# env | grep MAKE
MAKEOBJDIRPREFIX=/home/obj

# make -j 4 buildkernel && make installkernel
...
===> Ports module graphics/drm-next-kmod (all)
cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX  -u CPP  
-u MAKESYSPATH  -u MAKEOBJDIR  MAKEFLAGS="-j 4 -J 15,16 -j 4 -J 15,16 -D 
NO_MODULES_OBJ .MAKE.LEVEL.ENV=MAKELEVEL KERNEL=kernel TARGET=amd64 
TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys  
PATH=/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/home/obj/usr/src/amd64.amd64/tmp/legacy/bin:/home/obj/usr/src/amd64.amd64/tmp/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
  SRC_BASE=/usr/src  OSVERSION=1200058  
WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B clean 
build
===>  Cleaning for drm-next-kmod-g20180117
===>  License BSD2CLAUSE MIT GPLv2 accepted by the user
===>   drm-next-kmod-g20180117 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by drm-next-kmod-g20180117 for building
===>  Extracting for drm-next-kmod-g20180117
=> SHA256 Checksum OK for FreeBSDDesktop-kms-drm-g20180117-622fdd1_GH0.tar.gz.
===>  Patching for drm-next-kmod-g20180117
===>   drm-next-kmod-g20180117 depends on file: /usr/local/bin/ccache - found
===>  Configuring for drm-next-kmod-g20180117
===>  Building for drm-next-kmod-g20180117
[Creating objdir obj...]
...
--
>>> Kernel build for GENERIC-NODEBUG completed on Wed Feb 14 11:09:45 MSK 2018
--
--
>>> Installing kernel GENERIC-NODEBUG on Wed Feb 14 11:09:45 MSK 2018
--
...
kldxref /boot/kernel
===> Ports module graphics/drm-next-kmod (install)
cd ${PORTSDIR:-/usr/ports}/graphics/drm-next-kmod; env  -u CC  -u CXX  -u CPP  
-u MAKESYSPATH  -u MAKEOBJDIR  MAKEFLAGS=".MAKE.LEVEL.ENV=MAKELEVEL 
KERNEL=kernel MK_AUTO_OBJ=no TARGET=amd64 TARGET_ARCH=amd64"  
SYSDIR=/usr/src/sys  
PATH=/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/home/obj/usr/src/amd64.amd64/tmp/legacy/bin:/home/obj/usr/src/amd64.amd64/tmp/usr/sbin:/home/obj/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
  SRC_BASE=/usr/src  OSVERSION=1200058  
WRKDIRPREFIX=/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B 
deinstall reinstall
===>

Re: devd in r329188M don't start

2018-02-14 Thread Jakob Alvermark 

Yes, it seems to be working. Thanks!


Jakob


On 02/13/18 13:50, Hans Petter Selasky wrote:

On 02/13/18 10:47, Jakob Alvermark wrote:

+1

My USB mouse was working fine before the switch to devmatch. Now I 
have to 'kldload ums' manually.


Same for USB audio, snd_uaudio.ko was loaded by devd before.



Hi,

This is a known issue.

Can you try the attached patch?

Rebuild devmatch(8) and reinstall /etc/devd/devmatch.conf and 
/etc/rc.d/devmatch only.


--HPS


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