Re: no hw.acpi.video.lcd0 with graphics/drm-510-kmod

2022-05-23 Thread Maurizio Vairani 
Il giorno dom 22 mag 2022 alle ore 18:08 Pete Wright 
ha scritto:

> hello,
> i have a lenovo P43s laptop running current.  i've noticed that since
> graphics/drm-510-kmod became available hw.acpi.video.lcd0 ceases to
> exist (which makes it impossible to adjust screen brightness).  i've
> installed graphics/drm-54-kmod and things work as expected.  previously
> i was running drm-devel-kmod without issues, so i think it's probably an
> issue with the 5.10 driver?
>
> i can file a bug report for this (or just test out patches here if
> that's easier), but wanted to see if anyone here had observed this on
> other laptops first.
>
> cheers,
> -pete
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
>
> Hello,
to adjust screen brightness, on a Lenovo ThinkPad T450, I use the
graphics/intel-backlight port.
Regards,
Maurizio

Lenovo ThinkPad T450 panic in vm_page_alloc_check

2022-01-03 Thread Maurizio Vairani 
Hello, second panic today.
The laptop is running:
> uname -a
FreeBSD NomadBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 e9016c0be: Sun Jan  2
04:27:33 CET 2022 root@NomadBSD:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
 amd64
The backtrace command shows:
(kgdb) backtrace
#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=textdump@entry=0) at
/usr/src/sys/kern/kern_shutdown.c:399
#2  0x804c590a in db_dump (dummy=,
dummy2=, dummy3=, dummy4=) at
/usr/src/sys/ddb/db_command.c:575
#3  0x804c57c2 in db_command (last_cmdp=,
cmd_table=, dopager=dopager@entry=1) at
/usr/src/sys/ddb/db_command.c:482
#4  0x804c541d in db_command_loop () at
/usr/src/sys/ddb/db_command.c:535
#5  0x804c8a56 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270
#6  0x80c4e63b in kdb_trap (type=type@entry=3, code=code@entry=0,
tf=tf@entry=0xfe0107440980) at /usr/src/sys/kern/subr_kdb.c:733
#7  0x810c695a in trap (frame=0xfe0107440980) at
/usr/src/sys/amd64/amd64/trap.c:609
#8  
#9  kdb_enter (why=0x812c3774 "panic", msg=) at
/usr/src/sys/kern/subr_kdb.c:506
#10 0x80c00d30 in vpanic (fmt=0x812a7e39 "page %p has
object", ap=ap@entry=0xfe0107440ae0) at
/usr/src/sys/kern/kern_shutdown.c:908
#11 0x80c00ac3 in panic (fmt=0x81e8cea0 
"\223\002(\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:844
#12 0x80f74eb8 in vm_page_alloc_check (m=0x80,
m@entry=0xfe000e199f90)
at /usr/src/sys/vm/vm_page.c:2540
#13 0x80f74987 in vm_page_alloc_domain_after (object=, object@entry=0xf801f7801948, pindex=pindex@entry=27, domain=0,
req=,
mpred=, mpred@entry=0xfe0011ff3a30) at
/usr/src/sys/vm/vm_page.c:2075
#14 0x80f745c4 in vm_page_alloc_after (object=0xf801f7801948,
pindex=27, req=1, mpred=0xfe0011ff3a30) at
/usr/src/sys/vm/vm_page.c:1940
#15 vm_page_alloc (object=0xf801f7801948, pindex=27, req=) at /usr/src/sys/vm/vm_page.c:1911
#16 0x80f5a850 in vm_fault_allocate (fs=fs@entry=0xfe0107440cb8)
at /usr/src/sys/vm/vm_fault.c:1199
#17 0x80f59396 in vm_fault_object (fs=0xfe0107440cb8,
behindp=0xfe0107440cac, aheadp=0xfe0107440cb0) at
/usr/src/sys/vm/vm_fault.c:1414
#18 vm_fault (map=, map@entry=0xfe0106d96000,
vaddr=, vaddr@entry=45983234252800,
fault_type=fault_type@entry=2 '\002',
fault_flags=, fault_flags@entry=0, m_hold=, m_hold@entry=0x0) at /usr/src/sys/vm/vm_fault.c:1549
#19 0x80f58ee1 in vm_fault_trap (map=0xfe0106d96000,
vaddr=vaddr@entry=45983234252800, fault_type=,
fault_flags=fault_flags@entry=0,
signo=0xfe0107440f04, ucode=0xfe0107440f00) at
/usr/src/sys/vm/vm_fault.c:667
#20 0x810c6f9d in trap_pfault (frame=frame@entry=0xfe0107440f40,
usermode=true, signo=, signo@entry=0xfe0107440f04,
ucode=, ucode@entry=0xfe0107440f00) at
/usr/src/sys/amd64/amd64/trap.c:850
#21 0x810c6552 in trap (frame=0xfe0107440f40) at
/usr/src/sys/amd64/amd64/trap.c:385
#22 
#23 0x29d1a8913b05 in ?? ()
Backtrace stopped: Cannot access memory at address 0xc91868

I can share the /var/crash directory if needed.

Regards
--
Maurizio

Lenovo ThinkPad T450 panic in vm_freelist_rem()

2022-01-03 Thread Maurizio Vairani 
Hello and happy new year.

The laptop is running:
> uname -a
FreeBSD NomadBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 e9016c0be: Sun Jan  2
04:27:33 CET 2022 root@NomadBSD:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
 amd64

The backtrace command shows:
#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=textdump@entry=0) at
/usr/src/sys/kern/kern_shutdown.c:399
#2  0x804c590a in db_dump (dummy=,
dummy2=, dummy3=, dummy4=) at
/usr/src/sys/ddb/db_command.c:575
#3  0x804c57c2 in db_command (last_cmdp=,
cmd_table=, dopager=dopager@entry=1) at
/usr/src/sys/ddb/db_command.c:482
#4  0x804c541d in db_command_loop () at
/usr/src/sys/ddb/db_command.c:535
#5  0x804c8a56 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270
#6  0x80c4e63b in kdb_trap (type=type@entry=3, code=code@entry=0,
tf=tf@entry=0xfe00fc7ae970) at /usr/src/sys/kern/subr_kdb.c:733
#7  0x810c695a in trap (frame=0xfe00fc7ae970) at
/usr/src/sys/amd64/amd64/trap.c:609
#8  
#9  kdb_enter (why=0x812c3774 "panic", msg=) at
/usr/src/sys/kern/subr_kdb.c:506
#10 0x80c00d30 in vpanic (fmt=0x812b6aa3 "Bad link elm %p
next->prev != elm", ap=ap@entry=0xfe00fc7aead0) at
/usr/src/sys/kern/kern_shutdown.c:908
#11 0x80c00ac3 in panic (fmt=0x81e8cea0 
"\223\002(\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:844
#12 0x80f8376a in vm_freelist_rem (fl=0xff660cc45778, m=0x80,
order=0) at /usr/src/sys/vm/vm_phys.c:390
#13 vm_phys_free_pages (m=0xfe0002ad8ac8, order=order@entry=0) at
/usr/src/sys/vm/vm_phys.c:1124
#14 0x80f7b7ac in vm_page_zone_release (arg=,
store=0xf80001783010, cnt=188) at /usr/src/sys/vm/vm_page.c:2596
#15 0x80f55a4d in bucket_drain (zone=zone@entry=0xfe0019861800,
bucket=, bucket@entry=0xf80001783000) at
/usr/src/sys/vm/uma_core.c:1363
#16 0x80f50936 in bucket_free (zone=0xfe0019861800,
bucket=0xf80001783000, udata=0x0) at /usr/src/sys/vm/uma_core.c:521
#17 zone_put_bucket (zone=0xfe0019861800, zone@entry=0xf80001783000,
domain=, bucket=0xf80001783000, bucket@entry
=0xfe0105017560,
udata=udata@entry=0x0, ws=false) at /usr/src/sys/vm/uma_core.c:904
#18 0x80f57823 in zone_free_bucket (zone=zone@entry=0xfe0019861800,
bucket=bucket@entry=0xf80001783000, udata=udata@entry=0x0,
itemdomain=itemdomain@entry=0, ws=) at
/usr/src/sys/vm/uma_core.c:4643
#19 0x80f51091 in cache_free (zone=zone@entry=0xfe0019861800,
cache=, udata=udata@entry=0x0, itemdomain=1, itemdomain@entry
=0)
at /usr/src/sys/vm/uma_core.c:4710
#20 0x80f4fec8 in uma_zfree_arg (zone=0xfe0019861800,
item=0xfe0007970ca0, item@entry=0xfe0007970c38, udata=udata@entry
=0x0)
at /usr/src/sys/vm/uma_core.c:4514
#21 0x80f73515 in uma_zfree (zone=0x81e8cea0 ,
item=) at /usr/src/sys/vm/uma.h:404
#22 0x80f7348b in vm_page_free (m=0x81e8cea0 )
at /usr/src/sys/vm/vm_page.c:1330
#23 0x80f6d66d in vm_object_terminate_pages
(object=0xf8012e589108) at /usr/src/sys/vm/vm_object.c:907
#24 vm_object_terminate (object=object@entry=0xf8012e589108) at
/usr/src/sys/vm/vm_object.c:958
#25 0x80f6d37d in vm_object_deallocate (object=0xf8012e589108)
at /usr/src/sys/vm/vm_object.c:693
#26 0x80f5f309 in vm_map_entry_deallocate
(entry=0xf8012e5fb420, system_map=0) at /usr/src/sys/vm/vm_map.c:3813
#27 vm_map_process_deferred () at /usr/src/sys/vm/vm_map.c:613
#28 0x80f66aa9 in _vm_map_unlock (map=, line=4002,
file=) at /usr/src/sys/vm/vm_map.c:676
#29 vm_map_remove (map=, map@entry=0xfe01056713f0,
start=4096, end=) at /usr/src/sys/vm/vm_map.c:4002
#30 0x80f5edf9 in vmspace_dofree (vm=0xfe01056713f0) at
/usr/src/sys/vm/vm_map.c:382
#31 vmspace_exit (td=td@entry=0xfe0105017560) at
/usr/src/sys/vm/vm_map.c:457
#32 0x80bb2fe8 in exit1 (td=, rval=,
signo=signo@entry=0) at /usr/src/sys/kern/kern_exit.c:421
#33 0x80bb2a8d in sys_exit (td=0x81e8cea0 ,
uap=) at /usr/src/sys/kern/kern_exit.c:212
#34 0x810c771e in syscallenter (td=) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189
#35 amd64_syscall (td=0xfe0105017560, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:1191
#36 
#37 0x00080848d1fa in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffe848

I can share the /var/crash directory if needed.

Regards
--
Maurizio

Kernel panic on Lenovo Thinkpad T450

2021-11-08 Thread Maurizio Vairani 
On this laptop I've been using FreeBSD 14 for a few months now and
sometimes it panics, but after upgrading to:

uname -a

FreeBSD NomadBSD 14.0-CURRENT FreeBSD 14.0-CURRENT #0 e2157cd00: Sat Nov  6
03:21:26 CET 2021 root@NomadBSD:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

It always panics, usually when I run Firefox. The backtrace of these dumps
show these lines:

#10 0x80c2b578 in vpanic (fmt=0x811ff8df "%s",
ap=, ap@entry=0xfe01246b3860) at
/usr/src/sys/kern/kern_shutdown.c:908

#11 0x80c2b303 in panic (fmt=0x81e9f1e0 
"\033\300*\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:844

#12 0x810f4f07 in trap_fatal (frame=0xfe01246b3a60,
eva=491328337975) at /usr/src/sys/amd64/amd64/trap.c:946

#13 0x810f4fa9 in trap_pfault (frame=frame@entry=0xfe01246b3a60,
usermode=false, signo=, signo@entry=0x0, ucode=,

ucode@entry=0x0) at /usr/src/sys/amd64/amd64/trap.c:765

#14 0x810f45a7 in trap (frame=0xfe01246b3a60) at
/usr/src/sys/amd64/amd64/trap.c:443

#15 

#16 0x837692c9 in drm_prime_handle_to_fd_ioctl () from
/boot/modules/drm.ko

#17 0x8375cc52 in drm_ioctl_kernel () from /boot/modules/drm.ko

#18 0x8375cfaf in drm_ioctl () from /boot/modules/drm.ko

#19 0x80e92727 in linux_file_ioctl_sub (fp=,
filp=0x837692a0 , fop=, cmd=,

data=, td=) at
/usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:993

#20 linux_file_ioctl (fp=, cmd=,
data=, cred=, td=0xf802aef6)

at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:1610

#21 0x80ca1f52 in fo_ioctl (fp=, com=3222037549,
data=0x1, active_cred=0x0, td=0xfe0124afa1e0) at
/usr/src/sys/sys/file.h:360

#22 kern_ioctl (td=, td@entry=0xfe0124afa1e0,
fd=, com=, com@entry=3222037549,

data=0x1 ,
data@entry=0xfe01246b3d50
"\n") at /usr/src/sys/kern/sys_generic.c:803

#23 0x80ca1ca4 in sys_ioctl (td=0xfe0124afa1e0,
uap=0xfe0124afa5d0) at /usr/src/sys/kern/sys_generic.c:711

#24 0x810f58de in syscallenter (td=) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189

#25 amd64_syscall (td=0xfe0124afa1e0, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:1191

#26 

#27 0x00080ce80f0a in ?? ()

Backtrace stopped: Cannot access memory at address 0x7fffda48


What can I do ?

I can share the /var/crash directory content if necessary.

Thanks

--

Maurizio

Re: OpenZFS port updated

2020-04-29 Thread Maurizio Vairani 
Il giorno ven 17 apr 2020 alle ore 20:36 Ryan Moeller 
ha scritto:

> FreeBSD support has been merged into the master branch of the openzfs/zfs
> repository, and the FreeBSD ports have been switched to this branch.
>
> OpenZFS brings many exciting features to FreeBSD, including:
>  * native encryption
>  * improved TRIM implementation
>  * most recently, persistent L2ARC
>
> Of course, avoid upgrading your pools if you want to keep the option to go
> back to the base ZFS.
>
> OpenZFS can be installed alongside the base ZFS. Change your loader.conf
> entry to openzfs_load=“YES” to load the OpenZFS module at boot, and set
> PATH to find the tools in /usr/local/sbin before /sbin. The base zfs tools
> are still basically functional with the OpenZFS module, so changing PATH in
> rc is not strictly necessary.
>
> The FreeBSD loader can boot from pools with the encryption feature
> enabled, but the root/bootenv datasets must not be encrypted themselves.
>
> The FreeBSD platform support in OpenZFS does not yet include all features
> present in FreeBSD’s ZFS. Some notable changes/missing features include:
>  * many sysctl names have changed (legacy compat sysctls should be added
> at some point)
>  * zfs send progress reporting in process title via setproctitle
>  * extended 'zfs holds -r' (
> https://svnweb.freebsd.org/base?view=revision=290015)
>  * vdev ashift optimizations (
> https://svnweb.freebsd.org/base?view=revision=254591)
>  * pre-mountroot zpool.cache loading (for automatic pool imports)
>
> To the last point, this mainly effects the case where / is on ZFS and
> /boot is not or is on a different pool. OpenZFS cannot handle this case
> yet, but work is in progress to cover that use case. Booting directly from
> ZFS does work.
>
> If there are pools that need to be imported at boot other than the boot
> pool, OpenZFS does not automatically import yet, and it uses
> /etc/zfs/zpool.cache rather than /boot/zfs/zpool.cache to keep track of
> imported pools.  To ensure all pool imports occur automatically, a simple
> edit to /etc/rc.d/zfs will suffice:
>
> diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs
> index 2d35f9b5464..8e4aef0b1b3 100755
> --- a/libexec/rc/rc.d/zfs
> +++ b/libexec/rc/rc.d/zfs
> @@ -25,6 +25,13 @@ zfs_start_jail()
>
>  zfs_start_main()
>  {
> +   local cachefile
> +
> +   for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> +   if [ -f $cachefile ]; then
> +   zpool import -c $cachefile -a
> +   fi
> +   done
> zfs mount -va
> zfs share -a
> if [ ! -r /etc/zfs/exports ]; then
>
> This will probably not be needed long-term. It is not necessary if the
> boot pool is the only pool.
>
> Happy testing :)
>
> - Ryan
> ___
> 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"
>

On my laptop I am testing the new OpenZFS, I am running:

> uname -a

FreeBSD NomadBSD 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC  amd64

> freebsd-version -ku

12.1-RELEASE-p3

12.1-RELEASE-p4

I want let ZFS to write to the laptop SSD only every 1800 seconds:

> sudo zfs set sync=disabled zroot

and I have added these lines in /etc/sysctl.conf:

# Write to SSD every 30 minutes.

# 19/04/20 Added support for OpenZFS.

# Force commit Transaction Group (TXG) at 1800 secs, increase to aggregated

# more data (default 5 sec)

# vfs.zfs.txg.timeout for ZFS, vfs.zfs.txg_timeout for OpenZFS

vfs.zfs.txg.timeout=1800

vfs.zfs.txg_timeout=1800

# Write throttle when dirty "modified" data reaches 98% of dirty_data_max

#(default 60%)

vfs.zfs.delay_min_dirty_percent=98

# Force commit Transaction Group (TXG) if dirty_data reaches 95% of

# dirty_data_max (default 20%)

# vfs.zfs.dirty_data_sync_pct for ZFS, vfs.zfs.dirty_data_sync_percent for
OpenZFS

vfs.zfs.dirty_data_sync_pct=95

vfs.zfs.dirty_data_sync_percent=95

For testing the above settings I use the command: ‘zpool iostat -v -Td
zroot 600’ .

On the classic FreeBSD ZFS the output of the above command is similar to:

Tue Apr 28 14:44:08 CEST 2020

 capacity operationsbandwidth

pool  alloc   free   read  write   read  write

  -  -  -  -  -  -

zroot 31.9G  61.1G206 38  5.52M   360K

  diskid/DISK-185156448914p2  31.9G  61.1G206 38  5.52M   360K

  -  -  -  -  -  -

Tue Apr 28 14:54:08 CEST 2020

 capacity operationsbandwidth

pool  alloc   free   read  write   read  write

  -  -  -  -  -  -

zroot 31.9G  61.1G  8  0   297K  0

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

2018-06-06 Thread Maurizio Vairani 
2018-05-30 17:50 GMT+02:00 Glen Barber :

> Hi,
>
> Could folks please help boot-test the most recent 12.0-CURRENT amd64
> memstick images on various hardware?  Note, this is not a request to
> install 12.0-CURRENT, only a boot-test with various system knobs
> tweaked.
>
> The most recent images are available at:
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-
> IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-
> IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img
>
> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
> would like to get this included in the upcoming 11.2-RELEASE if the
> change that had been committed addresses several boot issues reported
> recently.
>
> Please help test, and report back (both successes and failures).
>
> Thanks,
>
> Glen
>
>
Hi,
successfully tested the memstick.img on:

Mac mini Mid 2011, BIOS and UEFI
Desktop based on Asus H81M-K mainboard, BIOS and UEFI

--
Maurizio
___
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: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

2018-06-02 Thread Maurizio Vairani 
2018-05-30 17:50 GMT+02:00 Glen Barber :

> Hi,
>
> Could folks please help boot-test the most recent 12.0-CURRENT amd64
> memstick images on various hardware?  Note, this is not a request to
> install 12.0-CURRENT, only a boot-test with various system knobs
> tweaked.
>
> The most recent images are available at:
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-
> IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-
> IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img
>
> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
> would like to get this included in the upcoming 11.2-RELEASE if the
> change that had been committed addresses several boot issues reported
> recently.
>
> Please help test, and report back (both successes and failures).
>
> Thanks,
>
> Glen
>
>
Hi,
successfully tested the memstick.img on:

HP Microserver Gen8, BIOS
Samsung NP270E5E laptop, BIOS and UEFI

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

net/isboot-kmod works with net/istgt but not with ctld(8)

2018-04-03 Thread Maurizio Vairani 
I am successfully running a diskless TrueOS, a FreeBSD 12-CURRENT derivate,
desktop with the net/istgt port installed in a FreeBSD 11-RELEASE server. I
am using this setup without any error, but it is a bit slow.

I want to test ctld on my server, but when the diskless PC loads the isboot
driver it loops with a lot of these error messages:

“soreceive BHS is not complete, remaining byte(s)=48

do login failed

soreceive BHS is not complete, remaining byte(s)=48

do login failed”

The source code, of the isboot-kmod driver, that prints the error message
is:

/* BHS */

   flags = MSG_WAITALL;

   uio.uio_resid = ISCSI_BHS_LEN;

   error = soreceive(sess->so, NULL, , , NULL, );

   if (error) {

  ISBOOT_ERROR("soreceive BHS error %d\n", error);

  return (error);

   }

   if (uio.uio_resid != 0) {

  ISBOOT_ERROR("soreceive BHS is not complete, remaining "

  "byte(s)=%d\n", (int) uio.uio_resid);

  return (EIO);

   }

source file: iscsi.c, proc: isboot_recv_pdu()

The ISCSI_BHS_LEN constant is 48 and seems that no bytes are read.

On the server, in /var/log/messages, I can read a lots of messages like:

“Mar 28 16:32:39 clover-nas2 ctld[59634]: 192.168.0.164: protocol error:
received invalid opcode 0x83

Mar 28 16:32:39 clover-nas2 ctld[40784]: child process 59634 terminated
with exit status 1

Mar 28 16:32:40 clover-nas2 ctld[59637]: 192.168.0.164: protocol error:
received invalid opcode 0x83

Mar 28 16:32:40 clover-nas2 ctld[40784]: child process 59637 terminated
with exit status 1”

The isboot driver send an unrecognized opcode 0x83 to the cltd daemon ...,
but I cannot continue, I need some help from the community. :-)

Note: the patch for compiling and running isboot-kmod in FreeBSD 12 is at:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226982

Regards,

Maurizio
___
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: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

2018-03-28 Thread Maurizio Vairani 
2018-02-04 14:40 GMT+01:00 Andriy Gapon <a...@freebsd.org>:

> On 04/02/2018 11:50, Maurizio Vairani wrote:
> > I have added a socket in the ifioctl() call as in the
> > /usr/src/sys/nfs/bootp_subr.c source.
> > Please let me know if you prefer a patch.
>
> A patch here https://reviews.freebsd.org/ would be the best.
>
> --
> Andriy Gapon
>

Hi,
I have uploaded a patch here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226982
--
Maurizio
___
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: Testing requested: Hybrid ISO/USB boot

2018-03-23 Thread Maurizio Vairani 
2018-03-22 19:06 GMT+01:00 Benno Rice :

> Hello all!
>
> I’ve been working on the ability to create hybrid ISO/HDD boot images for
> x86, a la what Linux systems do with ISOHYBRID. The general theory seems to
> be that ISO images have a 32KB hunk of zeroes at the front that they
> generally ignore so we’ll stick something in there that can handle booting
> if need be. The cases generally break down as follows:
>
> UEFI with CD: Boots using an EFI system partition embedded in the ISO
> image. This loads loader, and so on.
> UEFI with HDD: Same as above as UEFI doesn’t really care what the
> underlying medium is and it sees the ISO image.
> Legacy BIOS with CD: Boots using El Torrito as always.
>
> And now for the new part:
>
> Legacy BIOS with HDD: Sees a DOS MBR stuck in the 32KB at the front of the
> ISO image. This MBR contains our MBR boot code, which sees an active BSD
> slice containing a variant of our BSD boot code that reads from the ISO
> filesystem instead of UFS. This finds loader in the ISO filesystem and
> loads that. Loader has had support for reading ISO9660 images off HDDs
> added. Everything continues normally after that.
>
> The review for these changes is here:
>
> https://reviews.freebsd.org/D14799 
>
> And a version of the standard “bootonly” ISO image built with these
> changes is here:
>
> https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz <
> https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz>
>
> I’ve tested this image under qemu and VMware under all four of the
> BIOS/UEFI and CD/HDD combinations. I’ve also booted a system build around
> an Asus X399 Prime motherboard with this dd’ed to a USB stick. I’d love
> some testing on more systems, especially things that are more likely to
> have more customized boot firmwares (I’m thinking Dell, HP, etc).
>
> Many thanks,
> Benno.
> ___
> 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"
>
Hi Benno,
thank you for your work.

On a Mac mini "Core i5" 2.3 (Mid-2011), booting via USB, it hangs very
early, after writing:
FreeBSD/x86 bootstrap loader, version 1.1
(Wed Mar 21 10:27:48 PDT 2018 benno@bobthe)

Regards,
Maurizio
___
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: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

2018-02-08 Thread Maurizio Vairani 
2018-02-07 19:29 GMT+01:00 John Nielsen <li...@jnielsen.net>:

> > On Feb 7, 2018, at 6:07 AM, Maurizio Vairani <maurizio1...@gmail.com>
> wrote:
> >
> > 2018-02-06 23:02 GMT+01:00 John Nielsen <li...@jnielsen.net>:
> > > On Feb 6, 2018, at 11:50 AM, Ian Lepore <i...@freebsd.org> wrote:
> > >
> > > On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> > >>
> > >> Apparently sending a NULL socket pointer to ifioctl hasn't worked
> > >> since this commit in 2011:
> > >> https://svnweb.freebsd.org/base?view=revision=218757
> > >>
> > >> So I'm going to add this patch to the port unconditionally once it
> > >> works.
> > >>
> > >> Unfortunately, I can't compile the port with either my patch below or
> > >> your original replacement version of isboot_ifup(). :( Did you make
> > >> other changes? Here's the error I'm getting:
> > >>
> > >> --- isboot.o ---
> > >> isboot.c:425:53: error: incomplete definition of type 'struct thread'
> > >> error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
> > >>   ~~^
> > >> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
> > >> thread'
> > >> struct thread;
> > >>^
> > >> 1 error generated.
> > >>
> > >
> > > Try adding #include  if it's not already in the list.  It
> > > may be that that file got included via pollution from some other header
> > > file in the past and maybe now that has changed.
> > >
> > > If you're already including sys/proc.h then I'm clueless.
> >
> > Thanks Ian, that appears to work.
> >
> > Maurizio, can you apply the attached patch to a clean ports tree and see
> if isboot-kmod will build and function properly for you? This is all the
> changes from this thread and the previous one. If you let me know it works
> I'll get the port updated.
> >
> >
> > Hi John, I need some help.
> >
> > I am running:
> >  # uname -a
> > FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25
> 04:48:52 UTC 2018 r...@releng3.nyi.freebsd.org:/
> usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> >
> > after upgrading the ports tree with:
> > # portsnap fetch update
> >
> > I have copied the directory /usr/ports/net/isboot-kmod/ in
> /root/src/isboot-kmod and /root/src/isboot-kmod.orig
> > # ls -l /root/src
> > total 6
> > drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod
> > drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod.orig
> > -rw-rw-rw-  1 root  wheel  5630 Feb  7 11:38 isboot_patch.txt
> >
> > Trying to apply the patch I obtain the error:
> > # cd /root/src
> > # patch -sC < isboot_patch.txt
> > 2 out of 2 hunks failed while patching isboot-kmod/Makefile
> > 5 out of 5 hunks failed while patching isboot-kmod/files/patch-isboot.c
> >
> > What I am missing ?
> > Thanks again for your work.
>
> Not sure but I ran in to similar issues testing here as well. Here's the
> "svn diff" patch which does work for me. Note that this one should be
> applied from within the isboot-kmod directory.
>
>
With this patch I receive this error :
# pwd
/root/src/isboot-kmod
# patch -sC  < ../isboot-kmod-0.2.13_2.diff.txt
2 out of 2 hunks failed while patching Makefile
5 out of 5 hunks failed while patching files/patch-isboot.c
___
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: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

2018-02-07 Thread Maurizio Vairani 
2018-02-06 23:02 GMT+01:00 John Nielsen :

> > On Feb 6, 2018, at 11:50 AM, Ian Lepore  wrote:
> >
> > On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> >>
> >> Apparently sending a NULL socket pointer to ifioctl hasn't worked
> >> since this commit in 2011:
> >> https://svnweb.freebsd.org/base?view=revision=218757
> >>
> >> So I'm going to add this patch to the port unconditionally once it
> >> works.
> >>
> >> Unfortunately, I can't compile the port with either my patch below or
> >> your original replacement version of isboot_ifup(). :( Did you make
> >> other changes? Here's the error I'm getting:
> >>
> >> --- isboot.o ---
> >> isboot.c:425:53: error: incomplete definition of type 'struct thread'
> >> error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
> >>   ~~^
> >> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
> >> thread'
> >> struct thread;
> >>^
> >> 1 error generated.
> >>
> >
> > Try adding #include  if it's not already in the list.  It
> > may be that that file got included via pollution from some other header
> > file in the past and maybe now that has changed.
> >
> > If you're already including sys/proc.h then I'm clueless.
>
> Thanks Ian, that appears to work.
>
> Maurizio, can you apply the attached patch to a clean ports tree and see
> if isboot-kmod will build and function properly for you? This is all the
> changes from this thread and the previous one. If you let me know it works
> I'll get the port updated.
>
>
> Hi John, I need some help.

I am running:
 # uname -a
FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
UTC 2018 
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

after upgrading the ports tree with:
# portsnap fetch update

I have copied the directory /usr/ports/net/isboot-kmod/ in
/root/src/isboot-kmod and /root/src/isboot-kmod.orig
# ls -l /root/src
total 6
drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod
drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod.orig
-rw-rw-rw-  1 root  wheel  5630 Feb  7 11:38 isboot_patch.txt

Trying to apply the patch I obtain the error:
# cd /root/src
# patch -sC < isboot_patch.txt
2 out of 2 hunks failed while patching isboot-kmod/Makefile
5 out of 5 hunks failed while patching isboot-kmod/files/patch-isboot.c

What I am missing ?
Thanks again for your work.
--
Maurizio
___
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: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

2018-02-04 Thread Maurizio Vairani 
2018-01-29 18:38 GMT+01:00 John Nielsen <li...@jnielsen.net>:

> [ resending from correct email address ]
>
> On Jan 29, 2018, at 6:05 AM, Maurizio Vairani <maurizio1...@gmail.com>
> wrote:
>
> I am running
> # uname
> -a
>
> FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
> UTC 2018 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.
> amd64/sys/GENERIC
> amd64
>
> After compiling the kernel module as discussed in this thread :
> https://lists.freebsd.org/pipermail/freebsd-current/
> 2018-January/068272.html
>
> I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
> boot driver version 0.2.13, starts I receive a panic:
> https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4
>
> Any idea?
>
>
> Bummer!
>
> Aoyama-san-
>
> Are you still maintaining isboot? Can you help debug this issue on FreeBSD
> 12-CURRENT?
>
> Once we get it working I will update the port with whatever is needed and
> send you the patches in case you'd like to cut a new release.
>
> Thank you!
>

I have solved the issue changing the function isboot_ifup() in the source
file isboot.c.

static int
isboot_ifup(struct ifnet *ifp)
{
struct socket *so;
struct ifreq ifr;
struct thread *td;
int error;

td = curthread;
error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
if (error) {
printf("%s: socreate, error=%d\n", __func__, error);
return (error);
}

/* boot NIC */
memset(, 0, sizeof(ifr));
strlcpy(ifr.ifr_name, ifp->if_xname, sizeof(ifr.ifr_name));

/* set IFF_UP */
error = ifioctl(so, SIOCGIFFLAGS, (caddr_t), td);
if (error) {
printf("%s: ifioctl SIOCGIFFLAGS, error=%d\n", __func__, error);
return (error);
}

ifr.ifr_flags |= IFF_UP;
error = ifioctl(so, SIOCSIFFLAGS, (caddr_t), td);
if (error) {
printf("%s, ifioctl SIOCSIFFLAGS, error=%d\n", __func__, error);
return (error);
}
soclose(so);
return (0);
}

I have added a socket in the ifioctl() call as in the
/usr/src/sys/nfs/bootp_subr.c source.
Please let me know if you prefer a patch.
--
Regards,
Maurizio
___
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"

Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

2018-01-29 Thread Maurizio Vairani 
I am running
# uname
-a

FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25 04:48:52
UTC 2018 
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

After compiling the kernel module as discussed in this thread :
https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068272.html

I can boot FreeBSD via iSCSI using iPXE. But when the isboot, the iSCSI
boot driver version 0.2.13, starts I receive a panic:
https://mega.nz/#!tkVwBBKA!PUj14-Za6KCNaoo9hxuXORRLQoWkb4LMvTdUA1BorD4

Any idea?
--
Thanks,
Maurizio
___
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: Error compiling isboot-kmod

2018-01-29 Thread Maurizio Vairani 
2018-01-27 17:20 GMT+01:00 Ian Lepore :

> On Fri, 2018-01-26 at 23:20 -0700, John Nielsen wrote:
> > >
> > > On Jan 26, 2018, at 9:42 PM, John Nielsen  wrote:
> > >
> > > >
> > > > [...]
> > > --- iscsi.o ---
> > > iscsi.c:1146:3: error: incompatible pointer types passing 'void
> (struct mbuf *, void *, void *)' to parameter of type 'm_ext_free_t *' (aka
> 'void (*)(struct mbuf *)') [-Werror,-Wincompatible-pointer-types]
> > >MEXTADD(md, (caddr_t)ds_dd, (ISCSI_ALIGN(pp->ds_len)
> > >^~~~
> > > /usr/src/sys/sys/mbuf.h:887:42: note: expanded from macro 'MEXTADD'
> > >m_extadd((m), (char *)(buf), (size), (free), (arg1),
> (arg2),\
> > > ^~
> > > /usr/src/sys/sys/mbuf.h:634:59: note: passing argument to parameter
> here
> > > void m_extadd(struct mbuf *, char *, u_int, m_ext_free_t,
> > Looks like iscsi.c needs to be fixed up following r324446
> > (https://svnweb.freebsd.org/changeset/base/324446). Starting to be
> > out of my depth unless there's a mechanical way to make the changes?
> >
> >
>
> I'm not set up to test-compile this against -current right now, so I'm
> not sure if this is all that remains or just another breadcrumb on the
> trail, but... try the attached patch.
>
> -- Ian
>
> --- iscsi.c.orig2018-01-27 08:43:26.937858000 -0700
> +++ iscsi.c 2018-01-27 09:15:39.631501000 -0700
> @@ -1071,17 +1071,23 @@
>  }
>
>
> -#if __FreeBSD_version >= 110
> +#if __FreeBSD_version >= 1200051
> +static void
> +isboot_free_mbufext(struct mbuf *m)
> +{
> +   void *p = m->m_ext.ext_arg1;
> +#elif __FreeBSD_version >= 110
>  static void
>  isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
>  #elif __FreeBSD_version >= 150 && __FreeBSD_version < 110
>  static int
>  isboot_free_mbufext(struct mbuf *m, void *p, void *optarg)
> +{
>  #else
>  static void
>  isboot_free_mbufext(void *p, void *optarg)
> -#endif
>  {
> +#endif
>
> ISBOOT_TRACE("isboot_free_mbufext\n");
> if (p == NULL)
>
>
Applying this patch the module is compilable, but  when I use it I receive
a 'Fatal trap 12'. I will open a new discussion.

Thanks to all of you.
Maurizio
___
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: Error compiling isboot-kmod

2018-01-26 Thread Maurizio Vairani 
2018-01-24 17:19 GMT+01:00 Warner Losh <i...@bsdimp.com>:

>
>
> On Wed, Jan 24, 2018 at 3:12 AM, Maurizio Vairani <maurizio1...@gmail.com>
> wrote:
>
>> On this CURRENT snapshot
>> # uname -a
>> FreeBSD freebsd12 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r327788: Wed Jan 10
>> 22:55:40 UTC 2018
>> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>>
>> I can't compile the kernel module isboot-kmod:
>> # cd /usr/ports/net/isboot-kmod && make
>> ===>  License BSD2CLAUSE accepted by the
>> user
>>
>> ===>   isboot-kmod-0.2.13_1 depends on file: /usr/local/sbin/pkg - found
>> ===> Fetching all distfiles required by isboot-kmod-0.2.13_1 for building
>> ===>  Extracting for isboot-kmod-0.2.13_1
>> => SHA256 Checksum OK for isboot-0.2.13.tar.gz.
>> ===>  Patching for isboot-kmod-0.2.13_1
>> ===>  Applying FreeBSD patches for isboot-kmod-0.2.13_1
>> ===>  Configuring for isboot-kmod-0.2.13_1
>> ===>  Building for isboot-kmod-0.2.13_1
>> --- machine ---
>> --- x86 ---
>> --- machine ---
>> machine -> /usr/src/sys/amd64/include
>> --- x86 ---
>> x86 -> /usr/src/sys/x86/include
>> --- objwarn ---
>> --- opt_cam.h ---
>> --- objwarn ---
>> Warning: Object directory not changed from original
>> /usr/ports/net/isboot-kmod/work/isboot-0.2.13/src
>> --- opt_cam.h ---
>> :> opt_cam.h
>> --- isboot.o ---
>> --- ibft.o ---
>> --- isboot.o ---
>> cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
>> -nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
>> -mno-omit-leaf-frame-pointer   -MD  -MF.depe$
>> d.isboot.o -MTisboot.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
>> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
>> -fstack-protector -Wall -Wredundant-dec$
>> s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
>> -Wpointer-arith
>> -Winline -Wcast-qual -Wundef -Wno-pointer-sign
>> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs $
>> fdiagnostics-show-option -Wno-unknown-pragmas
>> -Wno-error-tautological-compare -Wno-error-empty-body
>> -Wno-error-parentheses-equality -Wno-error-unused-function
>> -Wno-error-pointer-s$
>> gn -Wno-error-shift-negative-value -Wno-error-address-of-packed-member
>> -mno-aes -mno-avx  -std=iso9899:1999 -c isboot.c -o isboot.o
>> --- ibft.o ---
>> cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
>> -nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
>> -mno-omit-leaf-frame-pointer   -MD  -MF.depe$
>> d.ibft.o -MTibft.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
>> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
>> -fstack-protector -Wall -Wredundant-decls -$
>> nested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
>> -Winline -Wcast-qual -Wundef -Wno-pointer-sign
>> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdi$
>> gnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare
>> -Wno-error-empty-body -Wno-error-parentheses-equality
>> -Wno-error-unused-function -Wno-error-pointer-sign $
>> Wno-error-shift-negative-value -Wno-error-address-of-packed-member
>> -mno-aes -mno-avx  -std=iso9899:1999 -c ibft.c -o ibft.o
>> --- iscsi.o ---
>> cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
>> -nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
>> -mno-omit-leaf-frame-pointer   -MD  -MF.depe$
>> d.iscsi.o -MTiscsi.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
>> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
>> -fstack-protector -Wall -Wredundant-decls
>> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
>> -Winline -Wcast-qual -Wundef -Wno-pointer-sign
>> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -f$
>> iagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compar
>> e
>> -Wno-error-empty-body -Wno-error-parentheses-equality
>> -Wno-error-unused-function -Wno-error-pointer-sig$
>>  -Wno-error-shift-negative-value -Wno-error-address-of-packed-member
>> -mno-aes -mno-avx  -std=iso9899:1999 -c iscsi.c -o iscsi.o
>> In file included from iscsi.c:62:
>> In file included from /usr/src/sys/cam/cam_ccb.h:1035:
>> In file included from /usr/src/sys/cam/mmc/mmc_bus.h:5:
>> In file included from /usr/src/sys/dev/mmc/bridge.h:59:
>> /usr/src/sys/sys/bus.h:726:10: fatal error: 'device_if.h' file not found
&g

Error compiling isboot-kmod

2018-01-24 Thread Maurizio Vairani 
On this CURRENT snapshot
# uname -a
FreeBSD freebsd12 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r327788: Wed Jan 10
22:55:40 UTC 2018
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64

I can't compile the kernel module isboot-kmod:
# cd /usr/ports/net/isboot-kmod && make
===>  License BSD2CLAUSE accepted by the
user

===>   isboot-kmod-0.2.13_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by isboot-kmod-0.2.13_1 for building
===>  Extracting for isboot-kmod-0.2.13_1
=> SHA256 Checksum OK for isboot-0.2.13.tar.gz.
===>  Patching for isboot-kmod-0.2.13_1
===>  Applying FreeBSD patches for isboot-kmod-0.2.13_1
===>  Configuring for isboot-kmod-0.2.13_1
===>  Building for isboot-kmod-0.2.13_1
--- machine ---
--- x86 ---
--- machine ---
machine -> /usr/src/sys/amd64/include
--- x86 ---
x86 -> /usr/src/sys/x86/include
--- objwarn ---
--- opt_cam.h ---
--- objwarn ---
Warning: Object directory not changed from original
/usr/ports/net/isboot-kmod/work/isboot-0.2.13/src
--- opt_cam.h ---
:> opt_cam.h
--- isboot.o ---
--- ibft.o ---
--- isboot.o ---
cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer   -MD  -MF.depe$
d.isboot.o -MTisboot.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -Wall -Wredundant-dec$
s -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs $
fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-s$
gn -Wno-error-shift-negative-value -Wno-error-address-of-packed-member
-mno-aes -mno-avx  -std=iso9899:1999 -c isboot.c -o isboot.o
--- ibft.o ---
cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer   -MD  -MF.depe$
d.ibft.o -MTibft.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -Wall -Wredundant-decls -$
nested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdi$
gnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality
-Wno-error-unused-function -Wno-error-pointer-sign $
Wno-error-shift-negative-value -Wno-error-address-of-packed-member
-mno-aes -mno-avx  -std=iso9899:1999 -c ibft.c -o ibft.o
--- iscsi.o ---
cc  -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer   -MD  -MF.depe$
d.iscsi.o -MTiscsi.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -f$
iagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality
-Wno-error-unused-function -Wno-error-pointer-sig$
 -Wno-error-shift-negative-value -Wno-error-address-of-packed-member
-mno-aes -mno-avx  -std=iso9899:1999 -c iscsi.c -o iscsi.o
In file included from iscsi.c:62:
In file included from /usr/src/sys/cam/cam_ccb.h:1035:
In file included from /usr/src/sys/cam/mmc/mmc_bus.h:5:
In file included from /usr/src/sys/dev/mmc/bridge.h:59:
/usr/src/sys/sys/bus.h:726:10: fatal error: 'device_if.h' file not found
#include "device_if.h"
 ^
1 error generated.
*** [iscsi.o] Error code 1

make[2]: stopped in /usr/ports/net/isboot-kmod/work/isboot-0.2.13/src
1 error

make[2]: stopped in /usr/ports/net/isboot-kmod/work/isboot-0.2.13/src
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/net/isboot-kmod
*** Error code 1

Stop.
make: stopped in /usr/ports/net/isboot-kmod

--
Regards
Maurizio
___
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: Programmatically cache line

2018-01-03 Thread Maurizio Vairani 
2018-01-02 2:27 GMT+01:00 blubee blubeeme :

> On Tue, Jan 2, 2018 at 12:26 AM, Ian Lepore  wrote:
>
> > On Mon, 2018-01-01 at 12:36 +0200, Konstantin Belousov wrote:
> > > On Mon, Jan 01, 2018 at 06:52:37AM +, David Chisnall wrote:
> > > >
> > > > On 1 Jan 2018, at 05:09, Adrian Chadd 
> wrote:
> > > > >
> > > > >
> > > > > On 30 December 2017 at 00:28, Konstantin Belousov  wrote:
> > > > > >
> > > > > > On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote:
> > > > > > >
> > > > > > > Is there some way to programmatically get the CPU cache line
> > sizes on
> > > > > > > FreeBSD?
> > > > > > There are, all of them are MD.
> > > > > >
> > > > > > On x86, the CPUID instruction leaf 0x1 returns the information in
> > > > > > %ebx register.
> > > > > Hm, weird. Why don't we extend sysctl to include this info?
> > > For the same reason we do not provide a sysctl to add two integers.
> > >
> > > >
> > > >
> > > > It would be nice to expose this kind of information via VDSO or
> > similar.  There are a lot of similar bits of info that people want to use
> > for ifunc and, SVE is going to have a bunch of similar requirements.
> > > >
> > > Is VDSO a new trendy word ?
> > >
> > > ifunc resolvers in usermode on FreeBSD/x86 get four arguments which
> > > are essentially cpu_features / cpu_features2 / cpu_stdext_features /
> > > cpu_stdext_features2.  I suspect that only FreeBSD/x86 arches have the
> > > ifunc support, in rtld and coming shortly in kernel.
> > >
> > > Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3)
> > > interface exported from libc.
> > >
> > > ARM* did not implemented yet the ifunc stubs in rtld. I believe this is
> > > considered a low priority because there is no ready to use toolchain
> > > which allow to utilize ifuncs on FreeBSD, except if you use recent bfd
> > > ld externally.
> >
> > Linux exports this info using getauxval().  I think we should support
> > getauxval() and as many of the AT_* values that linux defines as makes
> > sense for us to do.
> >
> > I think it was a mistake to give our version of the function a
> > different name and different semantics, but this is something that
> > affects mainly ports, and I don't yet have enough info to make the case
> > that being linux-compatible will ease porting rather than complicate it
> > (in some cases, patches will be needed either way).
> >
> > -- Ian
> >
> FreeBSD implements hardware specific atomic instructions [man atomic] or
> look at: #include 
>
> but implementing something that returns size of cache lines is somehow out
> of the question?
>
> If you're working with atomic data structures and want to ensure there's no
> false sharing the
> simplest method I know is to put some padding that's sizeof(cache_line) -
> sizeof(data_members)
> so that you can try to get them to live on different cache line.
>
> Do we have to go in and write inline assembly to grab the size of the cache
> line or wouldn't it
> be simpler to have atomic.h return this info?
>
> You can use CPUCTL(4).
___
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: i915kms breakage

2017-04-29 Thread Maurizio Vairani 
2017-04-29 0:52 GMT+02:00 Andrey Fesenko <f0and...@gmail.com>:

> On Fri, Apr 28, 2017 at 10:10 PM, Maurizio Vairani
> <maurizio1...@gmail.com> wrote:
> > 2017-04-22 14:47 GMT+02:00 Domagoj Stolfa <domagoj.sto...@gmail.com>:
> >
> >> Hello,
> >>
> >> ever since I've merged yesterday, it would seem that the i915kms driver
> >> panics every time it is loaded. Unfortunately, I am not able to provide
> >> a dump of the panic, as I am unable to see what the panic is, or what is
> >> even going on as a matter of fact due to my screen being overtaken by
> >> a driver that has just panicked. call doadump() does not seem to work
> >> either.
> >>
> >> Is anyone else having these problems, or know where the issue might be
> >> occurring?
> >>
> >> The same happens with 12.0-CURRENT r317513 updated yesterday. The laptop
> > is a Samsung NP270E5E with Intel Graphics 4000,
> > http://www.samsung.com/us/computer/pcs/NP270E5E-K02US-specs
> > --
>
> i5 r317402 and r317437 run only single mode, after r317561 work Xorg again
> :)
>

Thanks Andey,
updated to r317579 and works for me too.
--
Maurizio
___
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: i915kms breakage

2017-04-28 Thread Maurizio Vairani 
2017-04-22 14:47 GMT+02:00 Domagoj Stolfa :

> Hello,
>
> ever since I've merged yesterday, it would seem that the i915kms driver
> panics every time it is loaded. Unfortunately, I am not able to provide
> a dump of the panic, as I am unable to see what the panic is, or what is
> even going on as a matter of fact due to my screen being overtaken by
> a driver that has just panicked. call doadump() does not seem to work
> either.
>
> Is anyone else having these problems, or know where the issue might be
> occurring?
>
> The same happens with 12.0-CURRENT r317513 updated yesterday. The laptop
is a Samsung NP270E5E with Intel Graphics 4000,
http://www.samsung.com/us/computer/pcs/NP270E5E-K02US-specs
--
Regards,
Maurizio
___
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: New rc.d scripts on current

2016-04-25 Thread Maurizio Vairani 
2016-04-24 21:26 GMT+02:00 Lars Engels :

> On Sun, Apr 24, 2016 at 08:33:11AM -0700, Manfred Antar wrote:
> > Updated /etc yesterday via mergemaster.
> > Now I’m getting this on reboot. Everything seems to be working alright.
> >
> > eval: disk: not found
> > eval: disk: not found
> > eval: ${GELI ...}: Bad substitutio
> > FreeBSD/amd64 (pozo.com) (ttyu0)
> >
> > login:
> >
> > Not sure if it is error or new feature.
> >
> > Manfred
>
> It was my fault. the geli2 rc script had the description text in the
> "name" variable.
>

I am receiving this message too:

/etc/rc.d/ccd: descConcatenated disks setup:not found

Regards,
Maurizio
___
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"