Re: Several LOR's with most recent install media

[Chris H]

On Wed, 02 Mar 2016 21:49:39 -0800 "Chris H"  wrote

> Hello all,
>  I just finished an install off of the
> 11.0-CURRENT-i386-20160206-r295345-bootonly iso image burnt to DVD.
> After rebooting to the fresh install; shutting down the system
> results in several LOR's. Given so much information is dumped to
> screen, and that I no longer have access to the system; How can I
> get a copy of the LOR's output? I can capture the screen with my
> cell phone. But the information would sure be a lot more valuable
> in text form; no? :-)
> 
> Thanks for any suggestions.
> 
OK. Just got a couple more while checking out head/ports

Mar  2 22:00:00 spare newsyslog[705]: logfile turned over due to size>100K
Mar  2 22:12:00 spare kernel: lock order reversal:
Mar  2 22:12:00 spare kernel: 1st 0xda5f45a0 bufwait (bufwait) @
/usr/src/sys/kern/vfs_bio.c:3488
Mar  2 22:12:00 spare kernel: 2nd 0xc6880600 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
Mar  2 22:12:00 spare kernel: stack backtrace:
Mar  2 22:12:00 spare kernel: #0 0xc0c86001 at witness_debugger+0x81
Mar  2 22:12:00 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a
Mar  2 22:12:00 spare kernel: #2 0xc0c31a5
Mar  2 22:12:00 spare kernel: 1 at _sx_xlock+0x71
Mar  2 22:12:00 spare kernel: #3 0xc0ef0b
Mar  2 22:12:01 spare kernel: 70 at ufsdirhash_add+0x40
Mar  2 22:12:01 spare kernel: #4 0xc0ef3b32 at ufs_direnter+0x682
Mar  2 22:12:01 spare kernel: #5 0xc0efc8bb at ufs_mkdir+0x7eb
Mar  2 22:12:01 spare kernel: #6 0xc11ad428 at VOP_MKDIR_APV+0x108
Mar  2 22:12:01 spare kernel: #7 0xc0ced83a at kern_mkdirat+0x23a
Mar  2 22:12:01 spare kernel: #8 0xc0ced5f1 at sys_mkdir+0x31
Mar  2 22:12:01 spare kernel: #9 0xc117d4ed at syscall+0x37d
Mar  2 22:12:01 spare kernel: #10 0xc116827f at Xint0x80_syscall+0x2f
Mar  2 22:19:31 spare kernel: lock order reversal:
Mar  2 22:19:31 spare kernel: 1st 0xc71704a4 ufs (ufs) @
/usr/src/sys/kern/vfs_subr.c:873
Mar  2 22:19:31 spare kernel: 2nd 0xda5f4458 bufwait (bufwait) @
/usr/src/sys/ufs/ffs/ffs_vnops.c:263
Mar  2 22:19:31 spare kernel: 3rd 0xcb9e07f8 ufs (ufs) @
/usr/src/sys/kern/vfs_subr.c:2476
Mar  2 22:19:31 spare kernel: stack backtrace:
Mar  2 22:19:31 spare kernel: #0 0xc0c86001 at witness_debugger+0x81
Mar  2 22:19:31 spare kernel: #1 0xc0c85f2a at witness_checkorder+0xd6a
Mar  2 22:19:31 spare kernel: #2 0xc0c00c57 at __lockmgr_args+0xd57
Mar  2 22:19:31 spare kernel: #3 0xc0eeb374 at ffs_lock+0x84
Mar  2 22:19:31 spare kernel: #4 0xc11adef8 at VOP_LOCK1_APV+0x118
Mar  2 22:19:31 spare kernel: #5 0xc0cf0b16 at _vn_lock+0x96
Mar  2 22:19:31 spare kernel: #6 0xc0cdf2d4 at vget+0x64
Mar  2 22:19:31 spare kernel: #7 0xc0cd1a01 at vfs_hash_get+0xd1
Mar  2 22:19:31 spare kernel: #8 0xc0ee5d64 at ffs_vgetf+0x44
Mar  2 22:19:31 spare kernel: #9 0xc0edd36b at softdep_sync_buf+0xb0b
Mar  2 22:19:31 spare kernel: #10 0xc0eec0ba at ffs_syncvnode+0x2aa
Mar  2 22:19:31 spare kernel: #11 0xc0eeb206 at ffs_fsync+0x26
Mar  2 22:19:31 spare kernel: #12 0xc11acde8 at VOP_FSYNC_APV+0x108
Mar  2 22:19:31 spare kernel: #13 0xc0cbfc40 at bufsync+0x40
Mar  2 22:19:31 spare kernel: #14 0xc0cdd1f4 at bufobj_invalbuf+0x94
Mar  2 22:19:31 spare kernel: #15 0xc0ce07d0 at vgonel+0x1b0
Mar  2 22:19:31 spare kernel: #16 0xc0ce374b at vnlru_proc+0x65b
Mar  2 22:19:31 spare kernel: #17 0xc0bead5e at fork_exit+0x7e

Sorry for any undesirable line-wraps.
I can attache the output, if needed.

Thanks for any help preventing these.

--Chris


___
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: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)

[O. Hartmann]

On Wed, 2 Mar 2016 18:48:24 +
Martin Smith  wrote:

> On 02/03/2016 05:02, O. Hartmann wrote:
> > Hello list.
> >
> > I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445
> > as NetBIOS service (tcp/139) has been deprecated due to serious
> > vulnerability issues.
> >
> > Until the disabling of NetBIOS and tcp/139 we used successfully autofs and
> > mount_smbfs. this is no longer working. I tried to force autofs/mount_smbfs
> > to bind to port 445 on the server via ://@xxx.xxx.xxx.xxx:445/sharename,
> > but this doesn't work.
> >
> > Trying to mount a share from a samba 4.3 server (FreeBSD CURRENT,
> > net/samba43, both most recent sources), where I configured samba_server via
> > smb ports = 445 to use port tcp 445 only and only SMB2 and SMB3 (server min
> > protocol = SMB2) protocols via the following command:
> >
> > mount_smbfs -I xxx.xxx.xxx.xxx -U a_user -W \
> > WORKGROUP //a_u...@xxx.xxx.xxx.xxx:445/sharename /mnt
> >
> > results in the error
> >
> > mount_smbfs: unable to open connection: syserr = RPC struct is bad
> >
> > Setting "smb ports = 139,445" and "server min protocol = NT1" seems to
> > work, the share can be bound, but this is SMB over tcp/139 and not CIFS.
> >
> > I desperately need CIFS and I need tcp/445 since tcp/139 is from now on
> > firewalled.
> >
> > So: what do I miss here?  
> I think this is a windows server problem, though I am not in a position 
> to make any useful suggestions
> except to say that I am continually coming up against similar problems 
> with windows machines as well
> sorry I cant be any more help

Since I manag to connect to a SAMBA 4.3 server via 445/tcp only, but only when
"min protocol = NT1" is set (tried also SMB2). Connecting to Windows 2012 R2
doesn't work. I guess mount_smbfs "understands" only NT1 and below, the Win
2012R2 offers at least SMB2? 

> 
> 
> >
> > Kind regards and thank you in advance,
> >
> > O. Hartmann
> >
> > P.S. Please CC me  

___
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: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)

[O. Hartmann]

On Wed, 2 Mar 2016 17:49:40 +0300
"Andrey V. Elsukov"  wrote:

> On 02.03.16 17:29, O. Hartmann wrote:
> > My interpretation of the above errors are: FreeBSD is incapable to handle
> > CIFS over tcp/445. The above URL/site claims to have solved the problem,
> > but it seems not true for CURRENT.   
> 
> Did you try some FUSE CIFS implementations?
> 
FUSE and its sibblings doesn't get attention, since it is something additional
from ports. We have for the project security considerations and my intention is
to perform that task with most FreeBSD-only software. But thanks anyway - I
didn't have that project in mind so far, only SAMBA 4.3, misused as a client ...


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

Several LOR's with most recent install media

[Chris H]

Hello all,
 I just finished an install off of the
11.0-CURRENT-i386-20160206-r295345-bootonly iso image burnt to DVD.
After rebooting to the fresh install; shutting down the system
results in several LOR's. Given so much information is dumped to
screen, and that I no longer have access to the system; How can I
get a copy of the LOR's output? I can capture the screen with my
cell phone. But the information would sure be a lot more valuable
in text form; no? :-)

Thanks for any suggestions.

--Chris


___
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: CAM Shingled Disk support patches available

[Scott Long]

> On Mar 2, 2016, at 2:25 PM, Kenneth D. Merry  wrote:
> 
>> 
>> 
>> void scsi_ata_pass(struct ccb_scsiio *csio, u_int32_t retries,
>>  void (*cbfcnp)(struct cam_periph *, union ccb *),
>>  u_int32_t flags, u_int8_t tag_action,
>>  struct ata_cmd *cmd, struct ata_res *res,
>>  u_int8_t *data_ptr, u_int32_t dxfer_len,
>>  u_int8_t *data_ptr, u_int16_t dxfer_len,
> 
> I assume you only intended one line there, not two. :)
> 

Indeed =-)

>>  u_int8_t sense_len, u_int32_t timeout);
>> 
>> To differentiate between the 12 and 16 byte variants, you???d look at the
>> AP_EXTEND flag in the protocol field.  Btw, the handling of that flag is
>> inconsistent in the implementation of the existing scsi_ata_pass_16().  If
>> the caller providse an ata_res pointer then it gets filled on completion,
>> otherwise the caller does its best to look at 12.2.2.6 and extract what it
>> can from the sense descriptor.
>> 
>> So my proposal is to create a new scsi_ata_pass and deprecate but not remove
>> scsi_ata_pass_16.  Tell people that if they need to use it, dxfer_len is 
>> going to
>> have lower priority than sector_count/sector_count_exp if the latter 
>> multiply to
>> more than 65535.
> 
> In general I think that's a reasonable idea, but we should probably go
> further.
> 
> While we're at it, we should figure out what we need to do to add the
> Auxiliary register to struct ata_cmd.  We'll need that to do the NCQ
> versions of the various SMR commands, as well as TRIM.
> 

Warner and I talked about this, and I thought that at one point we had a patch
that defined a ‘struct ata_cmd_aux’.  As with function signatures, I’m very
much against redefining structures, and I think it’s reasonable to create a
new structure for what’s basically a late addition to the specs.  I need to read
more of the draft ACS and SATA specs to see if there’s anything else on the
horizon that should also be included.  However, and I talk a little bit about
this below, I think the situation is a bit more complicated than just adding
a field to the structure.  The ata_cmd structure mostly models what’s in an
ATA taskfile, and the taskfile definition, whether from ACS or APT, has never
been expanded to include the aux (and aux_exp) registers.  They exist only
in SATA as part of the Device-to-Host (D2H) FIS.  However, I’m kinda back
and forth on this; maybe my interpretation of ata_cmd is too strict, and we
can stick in whatever is needed and let the SIM deal with it.

At one point I had some patches that defined the
various FIS packets and allowed the periphs to send in an XPT_SATA_FIS
instead of an XPT_ATA_IO, but it seemed to not provide much value since
most drivers (and hardware) still operate in terms of legacy ATA taskfiles.
It also wasn’t clear in the scheme of driving I/O via a FIS where the
responsibility of the periph stopped and the SIM started; If the periph
sends a H2D FIS to initiate an I/O, does it need to then drive the PIO
and/or DMA FIS’s as well?  The FIS is really in the realm of the transport,
not the protocol, and it’s a huge shame that ATA is starting to blur the lines
by having the FIS Aux registers be part of the protocol.

> The obvious challenge is that probably means changing the existing struct
> ccb_ataio CCB and bumping the CAM version.  At least that will be source
> compatible, but will require ifdefs if people want to compile on older
> versions of FreeBSD.  But in that case, they'll also be faced with no
> support for sending the NCQ versions of the commands, anyway.  No way
> around that, though, since we have to follow the changing specs.
> 

Again, not a fan of redefining the structures.

A couple of other thoughts here.  Steve Hartland was right about not abusing
the AP_EXTEND flag.  What are your thoughts on having a new flag
in the function to signal 12 vs 16 byte variants?  Also do you have any thoughts
on the existing arguments?  I’m not sure that tag_action has ever made any
sense for the ATA transport, there’s no such a thing as ordered tags in ATA
and we don’t expose the NCQ tag number outside of the SIM.
MSG_SIMPLE_Q_TAG definitely has no meaning in ATA.  I think the
argument could go away.

Second, I’m not sure that cam_ata_pass (or cam_ata_pass_16, for that matter)
is the right place to include the aux register.  My reading is that it’s 
implementing
the 12.2.2.x chapter of SAT-3, and that doesn’t have any allowance for the
aux register.  SAT-4 r.04a doesn’t seem to mention this register either.  The
register seems to only be exposed when you have access to creating a H2D FIS,
and SAT is pretty much silent on that.  IIRC, when Warner implemented
NCQ TRIM, which required the Aux register, it could only be used on devices
attached via AHCI; LSI controllers had no way of expressing the register.  
Still,
we could add this ad-hoc to cam_ata_pass().  Maybe instead of it 

FreeBSD_HEAD_i386 - Build #2496 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #2496 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2496/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2496/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2496/console

Change summaries:

296331 by jhibbits:
Let rman_init() initialize the default rman range.

If rm_start and rm_end are both 0 on input to rman_init(), rman_init()
pre-initializes them to the default range.  No need to set it before.

296330 by jhibbits:
Another convert to bus_alloc_resource_anywhere().

Depending on how cbus hands out resources, this could actually be
bus_alloc_resource_any() instead.

296329 by jhibbits:
Allocate the PCI BAR resource with bus_alloc_resource_any()

We don't support allocating any other range with PCI BARs.

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

[CFT] packaging the base system with pkg(8)

[Glen Barber]

For those who have missed the initial email surrounding this topic, we
are planning on packaging the base system with pkg(8) for 11.0-RELEASE.

https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-January/00.html

At this time, I believe the major blockers and critical issues have been
resolved where it is time for an official call-for-testing.

Please note, as with any development branch, this is not yet intended
for production environments.  Testing on virtual machines or dedicated
testing machines is strongly encouraged.

Also note (as repeated below), running 'pkg delete -a' will implicitly
remove base system packages after they are installed.

To obtain the sources for testing, please use the projects/release-pkg
branch:

 # svn co svn://svn.freebsd.org/base/projects/release-pkg /usr/src

The projects/release-pkg branch is (at this time) in sync with head
revision r296327.

After checking out the project branch, build the userland and kernel as
normal with the 'buildworld' and 'buildkernel' targets.  Afterward,
packages can be created with the 'packages' target.

 # cd /usr/src
 # make [make flags] buildworld
 # make [make flags] buildkernel
 # make packages

At present, the base system consists of 755 packages with the default
build (empty src.conf(5) and make.conf(5)) for amd64.  The number of
packages depends on several factors, but for most cases a runtime binary
is split into several components.  In particular, most shared libraries
are individually packaged, in addition to debugging symbols, profiling
libraries, and 32-bit packaged separately.

The package repository will be created within /usr/obj/usr/src/repo by
default.

To enable the repository, create /usr/local/etc/pkg/repos/base.conf with
the following contents:

 # FreeBSD base system repository
 FreeBSD-base: {
   url: "file:///usr/obj/usr/src/repo/${ABI}/latest",
   mirror_type: "none",
   enabled: yes
 }

To initially bootstrap the 'FreeBSD-*' packages, they must be forcibly
installed.  Package registration is not performed during 'installworld'
or 'installkernel', and there are no immediate plans to do this.

This can be done by running:

 # pkg update -r FreeBSD-base
 # pkg install -g 'FreeBSD-*'

Please note the following:

1) The pkg(8) binary is required for this to work, however an additional
   patch against the ports-mgmt/pkg port is required to properly track
   base system shared libraries.  The patch against the ports-mgmt/pkg
   port is attached.  In my testing, excluding this patch has not caused
   anything horrible to happen, however applying both patches is
   suggested at this point.  The main noticeable effect of excluding the
   patch is system binary packages and their dependent library packages
   are not directly linked, which makes it possible to delete a library
   package that is required by a runtime binary.

2) At present, running 'pkg delete -a' will implicitly remove the
   'FreeBSD-*' packages, leaving the system in an unusable state.  There
   are valid use cases for removing all packages, such as test chroot(8)
   or jail(8) environments, so a solution to avoid accidental foot
   shooting is still being investigated.

3) With the attached patch, /lib32 and /usr/lib32 shared libraries are
   not tracked.  Since they are optional and do not affect the default
   running userland, this should not prevent testing, however it is
   worth noting.

4) For kernel packages, the first listed kernel in KERNCONF is installed
   as /boot/kernel, and subsequent kernels in KERNCONF are installed as
   /boot/kernel.${KERNEL}.  Building GENERIC is not required, as each
   kernel package is named with the kernel name included.  For example,
   if 'KERNCONF=MYLOCALKERNEL' is set in make.conf(5), the resulting
   kernel package will be 'FreeBSD-kernel-mylocalkernel-release', and
   the debug symbols as 'FreeBSD-kernel-mylocalkernel-debug'.

5) There are still a few outstanding issues with configuration file
   merging, which is still being investigated.

Please follow up on the freebsd-pkgbase@ mailing list with problems (and
successes).

Many suggestions were made, such as further granularity between runtime
binaries and daemons (rwho(1) and rwhod(8) is one example I recall
off-hand), that have not been implemented yet (and also not forgotten).

Thank you in advance to everyone that can test this, so we can get this
completed in time for 11.0-RELEASE.

Glen

Index: ports-mgmt/pkg/files/patch-libpkg_pkg__config.c
===
--- ports-mgmt/pkg/files/patch-libpkg_pkg__config.c (nonexistent)
+++ ports-mgmt/pkg/files/patch-libpkg_pkg__config.c (working copy)
@@ -0,0 +1,15 @@
+--- libpkg/pkg_config.c.orig   2016-01-26 23:32:05 UTC
 libpkg/pkg_config.c
+@@ -390,6 +390,12 @@ static struct config_entry c[] = {
+   "VALID_URL_SCHEME",
+   "pkg+http,pkg+https,https,http,ftp,file,ssh",
+   },
++  {
++  PKG_BOOL,

Re: SVN r296272 breaks virtualbox

[Jung-uk Kim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/ 1/16 05:29 PM, Michael Butler wrote:
> The removal of "taskqueue_enqueue_fast" breaks the virtualbox
> kmods:
> 
> Mar  1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914
> offMax=0x151c Mar  1 16:54:36 toshi kernel: link_elf_obj: symbol 
> taskqueue_enqueue_fast undefined Mar  1 16:54:36 toshi kernel:
> linker_load_file: Unsupported file type Mar  1 16:54:36 toshi
> kernel: link_elf_obj: symbol taskqueue_enqueue_fast undefined Mar
> 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type 
> Mar  1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on
> vboxnetflt - not available or version mismatch Mar  1 16:54:36
> toshi kernel: linker_load_file: Unsupported file type

It should be fixed now (r409965).

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW12mUAAoJEHyflib82/FGjCoIAI7SgVEn4KsODrF4/y/Aifp1
vw9jDQ9oGo7z3zRKk7C14/tLeS6Z+GjrfZldKOJBZHKoWLlzs9+WCpXmESez10Kj
0nR3dbk2RHAE0iHFqwz7jzzANGu/eZohsgQ44a7ZhZcnrlUchGLCIz3eZMQWctYz
KFUHLewYbr0/nBn/HB5G/5LI/DEBvhlxgplfjOFyvjZXXeYWot3q2cUvhNUjWQMf
B3iqXmeMQmQ4lHPA/GkIDpIUwhi0sSn8FoaaV+dF13MU023lBE//klcUn5GbYd4Y
4DkLzZJKy4gpfdKelkSU8GUAVERRKonxkROtRRvt9eioE8IpEcT2KDMkshEmXFU=
=Fj+q
-END PGP SIGNATURE-
___
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: Bay Trail 32bit UEFI

[Joe Holden]

On 02/03/2016 19:45, Lundberg, Johannes wrote:

On Wed, Mar 2, 2016 at 11:37 AM, Jakob Alvermark > wrote:

On Wed, March 2, 2016 20:00, Lundberg, Johannes wrote:
> On Wed, Mar 2, 2016 at 2:10 AM, Joe Holden > wrote:
>
>
>> On 02/03/2016 01:45, Lundberg, Johannes wrote:
>>
>>
>>> CherryTrail devices/boards with 64bit UEFI are already out. Upgrading
>>>  the hardware is one solution (I did).
>>>
>>> I'm thinking of the sticks etc, they all have 32bit UEFI and no
>>>
>> CSM/legacy boot, but have 64bit cpus
>>
>
>
>
> Yeah and it sucks. All to adapt to Microsoft who couldn't make 64bit UEFI
>  boot loader in time (or so I heard)... I heard though that newer (Linux)
> versions of Intel Compute Stick would have 64bit UEFI but I'm not sure.

The Intel Compute sticks can boot both 32 and 64 bit. It doesn't
matter if
you have the Windows or Linux version. (The difference between the
is the
amount of RAM and onboard storage, the firmware is the same)

I have the Windows one and it boots 64 bit just fine.
You can select it in the settings. (OS setting: Windows=32 bit,
Linux=64 bit)


That's great. However, as for all other BayTrail devices out there that
does not support Linux officially I think you're stuck with 32bit.


Jakob

My point was that it is possible to boot amd64 bit kernels from 32bit 
UEFI, grub (and therefore, linux) does it.
I think even openbsd at least has a 32bit loader, I'd settle for 32bit 
but the problem is I can't easily boot it.


___
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: CAM Shingled Disk support patches available

[Kenneth D. Merry]

On Tue, Mar 01, 2016 at 20:07:19 -0700, Scott Long wrote:
> Hi Ken,
> 
> I???m against changing the function signature of scsi_ata_pass_16().  Even
> if you manage to get things right with symbol versioning, it still leads to
> problems of code compatibility.  Maybe pre-existing binaries will work, but
> source code will forever have to include an #if __FreeBSD_version <
> xx bit of nonsense.

Good point, that would be annoying.

> I agree that it was incorrect for dxferlen to be declared as a uint16_t.
> However, the function already contains a sector count argument pair.  In
> theory the sector count multiplied by the sector length, both of which the
> application should know in order to arrive at a sensible dxferlen, can
> substitute for the dxferlen argument.  If so, then we can just ignore that
> argument and declare that sector_count has logical priority.

Okay.  That will probably work for the most part.

> Really though, I think that scsi_ata_pass_16() is a crummy function.  If its
> purpose is to implement SAT-3 12.2.2, it does an incredibly poor job at it:
> 
> - By my count, it only covers 12 of the available 13 registers.
> 
> - It has no 12 byte, opcode 0xa1 variant.
> 
> - It doesn???t make any allowance for providing the response registers to the
> caller on completion.  Well, maybe it kinda does through a sense descriptor,
> but???. it???s kinda open to vague interpretation.
> 
> - Its use of the registers is clunky, assuming for example that you???ll only 
> want
> to fill the six LBA registers with a host-ordered 64-bit number.  There are
> plenty of commands that re-use sub-parts of the LBA, features, and/or sector
> count registers for different things.  
> 
> I know you stated that you didn???t want to do this, but I think it???s 
> better to start
> over with a better function that has a better signature and a new name.  In 
> fact,
> I think it???s better to use the existing ata_cmd and ata_res structures from 
> sys/cam/ata/ata_all.h, provide accessors for the multi-byte registers if 
> needed,
> provide a 12-byte compatibility, and simply the signature.  Something like 
> this:
> 
> void scsi_ata_pass(struct ccb_scsiio *csio, u_int32_t retries,
>   void (*cbfcnp)(struct cam_periph *, union ccb *),
>   u_int32_t flags, u_int8_t tag_action,
>   struct ata_cmd *cmd, struct ata_res *res,
>   u_int8_t *data_ptr, u_int32_t dxfer_len,
>   u_int8_t *data_ptr, u_int16_t dxfer_len,

I assume you only intended one line there, not two. :)

>   u_int8_t sense_len, u_int32_t timeout);
> 
> To differentiate between the 12 and 16 byte variants, you???d look at the
> AP_EXTEND flag in the protocol field.  Btw, the handling of that flag is
> inconsistent in the implementation of the existing scsi_ata_pass_16().  If
> the caller providse an ata_res pointer then it gets filled on completion,
> otherwise the caller does its best to look at 12.2.2.6 and extract what it
> can from the sense descriptor.
> 
> So my proposal is to create a new scsi_ata_pass and deprecate but not remove
> scsi_ata_pass_16.  Tell people that if they need to use it, dxfer_len is 
> going to
> have lower priority than sector_count/sector_count_exp if the latter multiply 
> to
> more than 65535.

In general I think that's a reasonable idea, but we should probably go
further.

While we're at it, we should figure out what we need to do to add the
Auxiliary register to struct ata_cmd.  We'll need that to do the NCQ
versions of the various SMR commands, as well as TRIM.

The obvious challenge is that probably means changing the existing struct
ccb_ataio CCB and bumping the CAM version.  At least that will be source
compatible, but will require ifdefs if people want to compile on older
versions of FreeBSD.  But in that case, they'll also be faced with no
support for sending the NCQ versions of the commands, anyway.  No way
around that, though, since we have to follow the changing specs.

Ken
-- 
Kenneth Merry
k...@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: Build error on current@r296308: 'yacc.h' file not found

[David Cornejo]

On Wed, Mar 2, 2016 at 11:04 AM, Bryan Drewery  wrote:
> On 3/2/2016 12:52 PM, Bryan Drewery wrote:
>> On 3/2/2016 11:00 AM, Kurt Jaeger wrote:
>>> Hi!
>>>
>>> Today, I upgraded to r296308 and had this failure during buildworld:
>>>
>>> ===> usr.bin/mkesdb_static (obj,build-tools)
>>> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static 
>>> -I/usr/src/usr.bin/mkesdb_static/../mkesdb  
>>> -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -std=gnu99  
>>> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o 
>>> lex.o
>>> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' 
>>> file not found
>>> #include "yacc.h"
>>> 1 error generated.
>>> *** Error code 1
>>>
>>> A 'script' output is available at 
>>> http://people.freebsd.org/~pi/logs/src-up-2
>>>
>>> Is it just me or ... ?
>>>
>>
>> My fault. I am working on a fix.
>>
>
> Fixed in r296324.
>
> --
> Regards,
> Bryan Drewery
>

fix worked, thank you for quick resolution!

dave 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: Build error on current@r296308: 'yacc.h' file not found

[Bryan Drewery]

On 3/2/2016 12:52 PM, Bryan Drewery wrote:
> On 3/2/2016 11:00 AM, Kurt Jaeger wrote:
>> Hi!
>>
>> Today, I upgraded to r296308 and had this failure during buildworld:
>>
>> ===> usr.bin/mkesdb_static (obj,build-tools)
>> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static 
>> -I/usr/src/usr.bin/mkesdb_static/../mkesdb  
>> -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -std=gnu99  
>> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o 
>> lex.o
>> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' 
>> file not found
>> #include "yacc.h"
>> 1 error generated.
>> *** Error code 1
>>
>> A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2
>>
>> Is it just me or ... ?
>>
> 
> My fault. I am working on a fix.
> 

Fixed in r296324.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Build error on current@r296308: 'yacc.h' file not found

[Kurt Jaeger]

Hi!

> I have the same compilation error when I tried to build current today as well.

/usr/src/usr.bin/mkcsmapper/Makefile.inc has the same problem.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: Build error on current@r296308: 'yacc.h' file not found

[Bryan Drewery]

On 3/2/2016 11:00 AM, Kurt Jaeger wrote:
> Hi!
> 
> Today, I upgraded to r296308 and had this failure during buildworld:
> 
> ===> usr.bin/mkesdb_static (obj,build-tools)
> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static 
> -I/usr/src/usr.bin/mkesdb_static/../mkesdb  
> -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -std=gnu99  
> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o lex.o
> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' 
> file not found
> #include "yacc.h"
> 1 error generated.
> *** Error code 1
> 
> A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2
> 
> Is it just me or ... ?
> 

My fault. I am working on a fix.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)

[O. Hartmann]

Am Wed, 2 Mar 2016 16:01:57 +0100
Rainer Hurling  schrieb:

> Hi Oliver,
> 
> Am 02.03.16 um 15:29 schrieb O. Hartmann:
> > On Tue, 1 Mar 2016 23:39:22 +0200
> > "Reko Turja"  wrote:
> >  
> >> -Original Message-
> >> From: O. Hartmann
> >> Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8)  
> >>>
> >>> I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445
> >>> as NetBIOS service (tcp/139) has been deprecated due to serious
> >>> vulnerability issues. .
> >>> .
> >>> .
> >>> I desperately need CIFS and I need tcp/445 since tcp/139 is from now on
> >>> firewalled.  
> >>
> >> There's actually alternative available that's far more UNIX-friendly and 
> >> not
> >> depending on the SAMBA foibles.
> >>
> >> https://technet.microsoft.com/en-us/library/jj574143.aspx?f=255=-2147217396
> >>
> >> Of course, you need to have admin access to the server or get the admins
> >> enable NFS on it.
> >>
> >> -Reko
> >>
> >> (I've used the Windows NFS the other way around- FreeBSD NFS shares mounted
> >> with on Win7.) ___
> >> 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" 
> >>  
> >
> > Using others than CIFS is impossible, I'm dependend on existing services.
> > Within the next forseable time port tcp/139 gets firewalled.
> >
> > So far I have compiled NETSMB, SMBFS, LIBMCHAIN and LIBICONV (I think the
> > latter two are prerequests for NETSMB/SMBFS, didn't find much in the very
> > sparse and unfinished docs for that subject!) into the kernel.
> >
> > I found this following the exact subject I ran into:
> >
> > http://agreif.blogspot.de/2014/01/blog-post.html
> >
> > It doesn't work with either SAMBA 4.3 or Windows Server 2012 R2. Consider 
> > the
> > following situation.
> >
> > Windows/samba server has IP 10.0.0.1, it's WINS name is locus, its domain is
> > ASUF the user is pimmel. The passowrd is in /etc/nsmb.conf,
> > hashed:
> >
> >
> > [default]
> > charsets=utf-8:utf-8
> >
> > [LOCUS:PIMMEL]
> > address=10.0.0.1
> > password=$$ajdhasuih57
> >
> > The, following the above instructions, the mount_smbfs(8) command would be
> >
> > mount_smbfs -I10.0.0.1 -Wasuf -N //pimmel@10.0.0.1:445/share /mnt
> >
> > If -W is fed with ASUF (all uppercase), I get a strange error:
> >
> > mount_smbfs: invalid local charset specification (IT4)
> >
> > Connecting to the SAMBA 4.3 server, and with -Wasuf, I get
> >
> > mount_smbfs: unable to open connection: syserr = RPC struct is bad
> >
> > Connectingto the Windows 2012 R2 server results in
> >
> > mount_smbfs: unable to open connection: syserr = Connection reset by peer
> >
> > First, the manpage for mount_smbfs(8) is everything else than FreeBSD 
> > standard!
> > There is an unexplained option "-n opt". What is that?
> >
> > Second, CIFS over tcp/445 seems to be now very(!) common in the Windooze 
> > world
> > - why is that fact not reflected by FreeBSD? I tried to find some
> > explanations/manpages for "man netsmb" or "smbfs" (the kernel options), but
> > none found :-(
> >
> > My interpretation of the above errors are: FreeBSD is incapable to handle 
> > CIFS
> > over tcp/445. The above URL/site claims to have solved the problem, but it
> > seems not true for CURRENT.  
> 
> For me, the described scenario works well with base smbfs (on recent 
> HEAD amd64). My configuration differs in some way from yours.

I use recent HEAD (most recent, just recompiled world a minute ago ...)

> 
> GROUPNAME, SERVERNAME, and USERNAME should be written in capital letters 
> (?), domainname\\username in small letters (?):

I have almost every permutation used by now. Using -WUPPERCASE on the 
commandline gives
me strange errors like:
mount_smbfs: invalid local charset specification (IT4),

-wlowercase doen't.

Using tcp/139 NetBIOS with both Samba 4.3 and Win 2012 R2 works with lowercase 
username,
servername.

> 
> 
> # ---
> #cat /etc/nsmb.conf
> ...
> [default]
> workgroup=GROUPNAME
> 
> [SERVERNAME]
> nbns=xxx.xxx.xxx.xxx  (IPv4 address)
> charsets=UTF-8:CP866
> addr=servername.xxx.de
> 
> [SERVERNAME:USERNAME]
> username=domainname\\username
> password=HASHED_PASSWORD
> 
> 
> # ---
> My entries in /etc/fstab look like this:
> ...
> ### Mountpoints for mount_smbfs (of base system)
> //username@servername/dir /SMB/DIRsmbfs   rw,late 0   0
> 
> [and this also works with port 445:]
> //username@servername:445/dir /SMB/DIRsmbfs   rw,late
> 0 0
> 
> 
> # ---
> !!! If this was a real hashed password in your mail above, you should 
> change it ...

it isn't ;-)

> 
> HTH and greetings,
> Rainer

Thanks and kind regards,
Oliver


pgprV2vAFJaH7.pgp
Description: OpenPGP digital 

Re: Bay Trail 32bit UEFI

[Jakob Alvermark]

On Wed, March 2, 2016 20:00, Lundberg, Johannes wrote:
> On Wed, Mar 2, 2016 at 2:10 AM, Joe Holden  wrote:
>
>
>> On 02/03/2016 01:45, Lundberg, Johannes wrote:
>>
>>
>>> CherryTrail devices/boards with 64bit UEFI are already out. Upgrading
>>>  the hardware is one solution (I did).
>>>
>>> I'm thinking of the sticks etc, they all have 32bit UEFI and no
>>>
>> CSM/legacy boot, but have 64bit cpus
>>
>
>
>
> Yeah and it sucks. All to adapt to Microsoft who couldn't make 64bit UEFI
>  boot loader in time (or so I heard)... I heard though that newer (Linux)
> versions of Intel Compute Stick would have 64bit UEFI but I'm not sure.

The Intel Compute sticks can boot both 32 and 64 bit. It doesn't matter if
you have the Windows or Linux version. (The difference between the is the
amount of RAM and onboard storage, the firmware is the same)

I have the Windows one and it boots 64 bit just fine.
You can select it in the settings. (OS setting: Windows=32 bit, Linux=64 bit)

Jakob

___
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: Build error on current@r296308: 'yacc.h' file not found

[Jack L.]

I have the same compilation error when I tried to build current today as well.

On Wed, Mar 2, 2016 at 11:48 AM, Kurt Jaeger  wrote:
> Hi!
>
>> Today, I upgraded to r296308 and had this failure during buildworld:
>>
>> ===> usr.bin/mkesdb_static (obj,build-tools)
>> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static 
>> -I/usr/src/usr.bin/mkesdb_static/../mkesdb  
>> -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -std=gnu99  
>> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o 
>> lex.o
>> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' 
>> file not found
>> #include "yacc.h"
>> 1 error generated.
>> *** Error code 1
>>
>> A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2
>>
>> Is it just me or ... ?
>
> If I change the sequence in
>
> /usr/src/usr.bin/mkesdb/Makefile.inc
>
> for line
>
> SRCS+=  lex.l yacc.y
>
> to
>
> SRCS+=  yacc.y lex.l
>
> it builds ? That file was last touched 4 years ago ?
>
> --
> p...@opsec.eu+49 171 3101372 4 years to 
> go !
> ___
> 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: Build error on current@r296308: 'yacc.h' file not found

[Kurt Jaeger]

Hi!

> Today, I upgraded to r296308 and had this failure during buildworld:
> 
> ===> usr.bin/mkesdb_static (obj,build-tools)
> cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static 
> -I/usr/src/usr.bin/mkesdb_static/../mkesdb  
> -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -std=gnu99  
> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o lex.o
> /usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' 
> file not found
> #include "yacc.h"
> 1 error generated.
> *** Error code 1
> 
> A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2
> 
> Is it just me or ... ?

If I change the sequence in

/usr/src/usr.bin/mkesdb/Makefile.inc

for line

SRCS+=  lex.l yacc.y

to

SRCS+=  yacc.y lex.l

it builds ? That file was last touched 4 years ago ?

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: Bay Trail 32bit UEFI

[Lundberg, Johannes]

On Wed, Mar 2, 2016 at 11:37 AM, Jakob Alvermark 
wrote:

> On Wed, March 2, 2016 20:00, Lundberg, Johannes wrote:
> > On Wed, Mar 2, 2016 at 2:10 AM, Joe Holden  wrote:
> >
> >
> >> On 02/03/2016 01:45, Lundberg, Johannes wrote:
> >>
> >>
> >>> CherryTrail devices/boards with 64bit UEFI are already out. Upgrading
> >>>  the hardware is one solution (I did).
> >>>
> >>> I'm thinking of the sticks etc, they all have 32bit UEFI and no
> >>>
> >> CSM/legacy boot, but have 64bit cpus
> >>
> >
> >
> >
> > Yeah and it sucks. All to adapt to Microsoft who couldn't make 64bit UEFI
> >  boot loader in time (or so I heard)... I heard though that newer (Linux)
> > versions of Intel Compute Stick would have 64bit UEFI but I'm not sure.
>
> The Intel Compute sticks can boot both 32 and 64 bit. It doesn't matter if
> you have the Windows or Linux version. (The difference between the is the
> amount of RAM and onboard storage, the firmware is the same)
>
> I have the Windows one and it boots 64 bit just fine.
> You can select it in the settings. (OS setting: Windows=32 bit, Linux=64
> bit)
>

That's great. However, as for all other BayTrail devices out there that
does not support Linux officially I think you're stuck with 32bit.


>
> Jakob
>
>

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
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: Could somebody just commit this patch: The new command line option to set the daemon(8) process title ?

[Conrad Meyer]

Committed in r296321, thanks!

On Wed, Mar 2, 2016 at 11:02 AM, Yuri  wrote:
> On 02/29/2016 15:05, Conrad Meyer wrote:
>>
>> I'd be happy to (+ manual page changes) if I don't hear any objection
>> in the next few days.  I would keep [pid] in the title and just
>> replace argv0 with the -t argument.
>
>
> Conrad,
>
> thank you for taking it.
>
> Best,
>
> Yuri
>
> ___
> 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: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)

[Martin Smith]

On 02/03/2016 05:02, O. Hartmann wrote:

Hello list.

I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445 as 
NetBIOS
service (tcp/139) has been deprecated due to serious vulnerability issues.

Until the disabling of NetBIOS and tcp/139 we used successfully autofs and 
mount_smbfs.
this is no longer working. I tried to force autofs/mount_smbfs to bind to port 
445 on the
server via ://@xxx.xxx.xxx.xxx:445/sharename, but this doesn't work.

Trying to mount a share from a samba 4.3 server (FreeBSD CURRENT, net/samba43, 
both most
recent sources), where I configured samba_server via smb ports = 445 to use 
port tcp 445
only and only SMB2 and SMB3 (server min protocol = SMB2) protocols via the 
following
command:

mount_smbfs -I xxx.xxx.xxx.xxx -U a_user -W \
WORKGROUP //a_u...@xxx.xxx.xxx.xxx:445/sharename /mnt

results in the error

mount_smbfs: unable to open connection: syserr = RPC struct is bad

Setting "smb ports = 139,445" and "server min protocol = NT1" seems to work, 
the share
can be bound, but this is SMB over tcp/139 and not CIFS.

I desperately need CIFS and I need tcp/445 since tcp/139 is from now on 
firewalled.

So: what do I miss here?
I think this is a windows server problem, though I am not in a position 
to make any useful suggestions
except to say that I am continually coming up against similar problems 
with windows machines as well

sorry I cant be any more help




Kind regards and thank you in advance,

O. Hartmann

P.S. Please CC me


___
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: Could somebody just commit this patch: The new command line option to set the daemon(8) process title ?

[Yuri]

On 02/29/2016 15:05, Conrad Meyer wrote:

I'd be happy to (+ manual page changes) if I don't hear any objection
in the next few days.  I would keep [pid] in the title and just
replace argv0 with the -t argument.


Conrad,

thank you for taking it.

Best,
Yuri

___
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: Bay Trail 32bit UEFI

[Lundberg, Johannes]

On Wed, Mar 2, 2016 at 2:10 AM, Joe Holden  wrote:

> On 02/03/2016 01:45, Lundberg, Johannes wrote:
>
>> CherryTrail devices/boards with 64bit UEFI are already out. Upgrading
>> the hardware is one solution (I did).
>>
>> I'm thinking of the sticks etc, they all have 32bit UEFI and no
> CSM/legacy boot, but have 64bit cpus



Yeah and it sucks. All to adapt to Microsoft who couldn't make 64bit UEFI
boot loader in time (or so I heard)...
I heard though that newer (Linux) versions of Intel Compute Stick would
have 64bit UEFI but I'm not sure.


>
> I never did try FreeBSD on BayTrail but for running Linux on BayTrail I
>> used special built Grub that was 32bit but could load 64bit OS. Could
>> this kind of Grub boot a 64bit FreeBSD, I wonder?
>>
>> I looked at this but honestly it looked like a giant nightmare - I did
> get grub loading on a test platform (tablet, for display etc) but didn't
> manage to make it boot anything
>

This page contains some instructions and a downloadable booti32.efi image
that you can put in the EFI folder. That will boot a 64bit grub that should
be able to boot a 64bit OS.

http://liliputing.com/2013/10/booting-ubuntu-asus-transformer-book-t100.html

I do have customized Arch Linux memstick image with Grub and this
booti32.efi image so it boots on these systems. This can be used to install
a Grub bootloader that maybe can boot FreeBSD.

One question is, would Grub's filesystem drivers for FreeBSD work in this
mode?

Maybe I should give it a shot today..


>
>> On Tue, Mar 1, 2016 at 5:20 PM, John Baldwin > > wrote:
>>
>> On Sunday, February 28, 2016 07:00:06 AM Joe Holden wrote:
>> > Hi all,
>> >
>> > Apologies if this is the wrong list...
>> >
>> > Is there any plan to support booting FreeBSD on 32bit UEFI systems
>> (with
>> > or without 64bit kernel/userland)? Obviously there is no i386 efi
>> loader
>> > currently so neither is possible...
>>
>> I don't think anyone is actively working on it.  I think it shouldn't
>> be
>> that much work once the i386 loader is resurrected.  The i386 kernel
>> just
>> needs to use the EFI memory map and I think the rest of it should
>> generally
>> just work.
>>
>> --
>> John Baldwin
>> ___
>> 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
>> "
>>
>
>
>

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
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"

Build error on current@r296308: 'yacc.h' file not found

[Kurt Jaeger]

Hi!

Today, I upgraded to r296308 and had this failure during buildworld:

===> usr.bin/mkesdb_static (obj,build-tools)
cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static 
-I/usr/src/usr.bin/mkesdb_static/../mkesdb  
-I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -std=gnu99  
-Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex.c -o lex.o
/usr/src/usr.bin/mkesdb_static/../mkesdb/lex.l:44:10: fatal error: 'yacc.h' 
file not found
#include "yacc.h"
1 error generated.
*** Error code 1

A 'script' output is available at http://people.freebsd.org/~pi/logs/src-up-2

Is it just me or ... ?

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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: CAM Shingled Disk support patches available

[Douglas Gilbert]

On 16-03-01 10:07 PM, Scott Long via freebsd-scsi wrote:

Hi Ken,

I’m against changing the function signature of scsi_ata_pass_16().  Even
if you manage to get things right with symbol versioning, it still leads to
problems of code compatibility.  Maybe pre-existing binaries will work, but
source code will forever have to include an #if __FreeBSD_version <
xx bit of nonsense.

I agree that it was incorrect for dxferlen to be declared as a uint16_t.
However, the function already contains a sector count argument pair.  In
theory the sector count multiplied by the sector length, both of which the
application should know in order to arrive at a sensible dxferlen, can
substitute for the dxferlen argument.  If so, then we can just ignore that
argument and declare that sector_count has logical priority.

Really though, I think that scsi_ata_pass_16() is a crummy function.  If its
purpose is to implement SAT-3 12.2.2, it does an incredibly poor job at it:

- By my count, it only covers 12 of the available 13 registers.

- It has no 12 byte, opcode 0xa1 variant.

- It doesn’t make any allowance for providing the response registers to the
caller on completion.  Well, maybe it kinda does through a sense descriptor,
but…. it’s kinda open to vague interpretation.

- Its use of the registers is clunky, assuming for example that you’ll only want
to fill the six LBA registers with a host-ordered 64-bit number.  There are
plenty of commands that re-use sub-parts of the LBA, features, and/or sector
count registers for different things.

I know you stated that you didn’t want to do this, but I think it’s better to 
start
over with a better function that has a better signature and a new name.  In 
fact,
I think it’s better to use the existing ata_cmd and ata_res structures from
sys/cam/ata/ata_all.h, provide accessors for the multi-byte registers if needed,
provide a 12-byte compatibility, and simply the signature.  Something like this:

void scsi_ata_pass(struct ccb_scsiio *csio, u_int32_t retries,
   void (*cbfcnp)(struct cam_periph *, union ccb *),
   u_int32_t flags, u_int8_t tag_action,
   struct ata_cmd *cmd, struct ata_res *res,
   u_int8_t *data_ptr, u_int32_t dxfer_len,
   u_int8_t *data_ptr, u_int16_t dxfer_len,
   u_int8_t sense_len, u_int32_t timeout);


uint32_t and uint8_t please :-)

For the pendants:
  https://www.freebsd.org/cgi/man.cgi?query=style=9

"The project is slowly moving to use the ISO/IEC 9899:1999
(``ISO C99'') unsigned integer identifiers of the form uintXX_t
in preference to the older BSD-style integer identifiers of
the form u_intXX_t. New code should use the former, and old
code should be converted to the new form if other major work is
being done in that area and there is no overriding reason to
prefer the older BSD-style. Like white-space commits, care should
be taken in making uintXX_t only commits."

The Linux kernel ain't much better with u8, u16 and u32 typedefs
everywhere.

Doug Gilbert


To differentiate between the 12 and 16 byte variants, you’d look at the
AP_EXTEND flag in the protocol field.  Btw, the handling of that flag is
inconsistent in the implementation of the existing scsi_ata_pass_16().  If
the caller providse an ata_res pointer then it gets filled on completion,
otherwise the caller does its best to look at 12.2.2.6 and extract what it
can from the sense descriptor.

So my proposal is to create a new scsi_ata_pass and deprecate but not remove
scsi_ata_pass_16.  Tell people that if they need to use it, dxfer_len is going 
to
have lower priority than sector_count/sector_count_exp if the latter multiply to
more than 65535.

Scott




On Mar 1, 2016, at 3:47 PM, Kenneth D. Merry  wrote:

I have a new set of SMR patches available.  (See the original message below
for a more detailed description of what these patches do.)

The primary change is to add library versioning to libcam so that we can
change the function prototype of scsi_ata_pass_16() in a way that won't
break existing binaries.

If someone more familiar with library versioning wants to review this, I'd
appreciate it.

The patches are here:

FreeBSD/head, as of SVN revision 296278

https://people.freebsd.org/~ken/cam_smr.head.20160301.1.txt

stable/10, as of SVN revision 296248

https://people.freebsd.org/~ken/cam_smr.stable10.20160301.1.txt

(Note that although there is a stable/10 version of the patches, I'm not
planning to merge them to stable/10 because of the change to struct bio.  I
can't really figure out a good way to make that backward compatible.  If
there is consensus that breaking it is fine because it isn't a user API,
then that may be another story.)

The problem is that the existing, in-tree version of scsi_ata_pass_16() has
a dxfer_len argument that is a uint16_t.  That restricts transfer sizes to
64KB.  So, we need to update it to allow larger than 64K 

Re: SVN r296272 breaks virtualbox

[John Baldwin]

On Wednesday, March 02, 2016 07:27:45 AM Kurt Jaeger wrote:
> Hi!
> 
> > > > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods:
> [...]
> > Then the port needs to be patched?  It's been using an API deprecated
> > for the last 15 years.  A simple s/taskqueue_enqueue_fast/taskqueue_enqueue/
> > will fix it.
> 
> A patch is possible if a new __FreeBSD_version is created for that
> API. Who can do that ?

You don't need a new bump.  taskqueue_enqueue has worked fine for a "fast"
taskqueue since 700013, so you can use that version.  OTOH, I would be
surprised if VirtualBox worked on FreeBSD 6.x.

-- 
John Baldwin
___
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: Bay Trail 32bit UEFI

[John Baldwin]

On Tuesday, March 01, 2016 05:45:04 PM Lundberg, Johannes wrote:
> CherryTrail devices/boards with 64bit UEFI are already out. Upgrading the
> hardware is one solution (I did).
> 
> I never did try FreeBSD on BayTrail but for running Linux on BayTrail I
> used special built Grub that was 32bit but could load 64bit OS. Could this
> kind of Grub boot a 64bit FreeBSD, I wonder?

Mmm, booting an amd64 kernel from an i386 UEFI loader would be a bit more
work.  OTOH, in the non-UEFI case we use an i386 loader that boots an
amd64 kernel, so it isn't impossible.

-- 
John Baldwin
___
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 r296272 breaks virtualbox

[John Baldwin]

On Wednesday, March 02, 2016 07:06:26 AM Howard Su wrote:
> On Tue, Mar 1, 2016 at 10:28 PM Kurt Jaeger  wrote:
> 
> > Hi!
> >
> > > > > The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods:
> > [...]
> > > Then the port needs to be patched?  It's been using an API deprecated
> > > for the last 15 years.  A simple
> > s/taskqueue_enqueue_fast/taskqueue_enqueue/
> > > will fix it.
> >
> > A patch is possible if a new __FreeBSD_version is created for that
> > API. Who can do that ?
> >
> There is no version pump and it is not needed. r296272 didn't have any
> behavior change. binary compatible is kept as well.

Actually, I broke binary compat in HEAD as 11.0 hasn't shipped yet and
11.0 won't be released for a while yet.  In this case I think ripping
the band-aid off is fine, especially since the replacement API has been
ready for such a long time (and goes back to 7.0).

-- 
John Baldwin
___
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: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)

[Rainer Hurling]

Hi Oliver,

Am 02.03.16 um 15:29 schrieb O. Hartmann:

On Tue, 1 Mar 2016 23:39:22 +0200
"Reko Turja"  wrote:


-Original Message-
From: O. Hartmann
Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8)


I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445
as NetBIOS service (tcp/139) has been deprecated due to serious
vulnerability issues. .
.
.
I desperately need CIFS and I need tcp/445 since tcp/139 is from now on
firewalled.


There's actually alternative available that's far more UNIX-friendly and not
depending on the SAMBA foibles.

https://technet.microsoft.com/en-us/library/jj574143.aspx?f=255=-2147217396

Of course, you need to have admin access to the server or get the admins
enable NFS on it.

-Reko

(I've used the Windows NFS the other way around- FreeBSD NFS shares mounted
with on Win7.) ___
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"


Using others than CIFS is impossible, I'm dependend on existing services.
Within the next forseable time port tcp/139 gets firewalled.

So far I have compiled NETSMB, SMBFS, LIBMCHAIN and LIBICONV (I think the
latter two are prerequests for NETSMB/SMBFS, didn't find much in the very
sparse and unfinished docs for that subject!) into the kernel.

I found this following the exact subject I ran into:

http://agreif.blogspot.de/2014/01/blog-post.html

It doesn't work with either SAMBA 4.3 or Windows Server 2012 R2. Consider the
following situation.

Windows/samba server has IP 10.0.0.1, it's WINS name is locus, its domain is
ASUF the user is pimmel. The passowrd is in /etc/nsmb.conf,
hashed:


[default]
charsets=utf-8:utf-8

[LOCUS:PIMMEL]
address=10.0.0.1
password=$$ajdhasuih57

The, following the above instructions, the mount_smbfs(8) command would be

mount_smbfs -I10.0.0.1 -Wasuf -N //pimmel@10.0.0.1:445/share /mnt

If -W is fed with ASUF (all uppercase), I get a strange error:

mount_smbfs: invalid local charset specification (IT4)

Connecting to the SAMBA 4.3 server, and with -Wasuf, I get

mount_smbfs: unable to open connection: syserr = RPC struct is bad

Connectingto the Windows 2012 R2 server results in

mount_smbfs: unable to open connection: syserr = Connection reset by peer

First, the manpage for mount_smbfs(8) is everything else than FreeBSD standard!
There is an unexplained option "-n opt". What is that?

Second, CIFS over tcp/445 seems to be now very(!) common in the Windooze world
- why is that fact not reflected by FreeBSD? I tried to find some
explanations/manpages for "man netsmb" or "smbfs" (the kernel options), but
none found :-(

My interpretation of the above errors are: FreeBSD is incapable to handle CIFS
over tcp/445. The above URL/site claims to have solved the problem, but it
seems not true for CURRENT.


For me, the described scenario works well with base smbfs (on recent 
HEAD amd64). My configuration differs in some way from yours.


GROUPNAME, SERVERNAME, and USERNAME should be written in capital letters 
(?), domainname\\username in small letters (?):



# ---
#cat /etc/nsmb.conf
...
[default]
workgroup=GROUPNAME

[SERVERNAME]
nbns=xxx.xxx.xxx.xxx  (IPv4 address)
charsets=UTF-8:CP866
addr=servername.xxx.de

[SERVERNAME:USERNAME]
username=domainname\\username
password=HASHED_PASSWORD


# ---
My entries in /etc/fstab look like this:
...
### Mountpoints for mount_smbfs (of base system)
//username@servername/dir   /SMB/DIRsmbfs   rw,late 0   0

[and this also works with port 445:]
//username@servername:445/dir   /SMB/DIRsmbfs   rw,late 0   0


# ---
!!! If this was a real hashed password in your mail above, you should 
change it ...


HTH and greetings,
Rainer

___
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: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)

[Andrey V. Elsukov]

On 02.03.16 17:29, O. Hartmann wrote:
> My interpretation of the above errors are: FreeBSD is incapable to handle CIFS
> over tcp/445. The above URL/site claims to have solved the problem, but it
> seems not true for CURRENT. 

Did you try some FUSE CIFS implementations?

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)

[O. Hartmann]

On Tue, 1 Mar 2016 23:39:22 +0200
"Reko Turja"  wrote:

> -Original Message- 
> From: O. Hartmann 
> Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8) 
> >
> > I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445
> > as NetBIOS service (tcp/139) has been deprecated due to serious
> > vulnerability issues. .
> > .
> > .
> > I desperately need CIFS and I need tcp/445 since tcp/139 is from now on
> > firewalled.   
> 
> There's actually alternative available that's far more UNIX-friendly and not
> depending on the SAMBA foibles.
> 
> https://technet.microsoft.com/en-us/library/jj574143.aspx?f=255=-2147217396
> 
> Of course, you need to have admin access to the server or get the admins
> enable NFS on it.
> 
> -Reko
> 
> (I've used the Windows NFS the other way around- FreeBSD NFS shares mounted
> with on Win7.) ___
> 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"

Using others than CIFS is impossible, I'm dependend on existing services.
Within the next forseable time port tcp/139 gets firewalled.

So far I have compiled NETSMB, SMBFS, LIBMCHAIN and LIBICONV (I think the
latter two are prerequests for NETSMB/SMBFS, didn't find much in the very
sparse and unfinished docs for that subject!) into the kernel.

I found this following the exact subject I ran into:

http://agreif.blogspot.de/2014/01/blog-post.html

It doesn't work with either SAMBA 4.3 or Windows Server 2012 R2. Consider the
following situation.

Windows/samba server has IP 10.0.0.1, it's WINS name is locus, its domain is
ASUF the user is pimmel. The passowrd is in /etc/nsmb.conf,
hashed:


[default]
charsets=utf-8:utf-8

[LOCUS:PIMMEL]
address=10.0.0.1
password=$$ajdhasuih57

The, following the above instructions, the mount_smbfs(8) command would be

mount_smbfs -I10.0.0.1 -Wasuf -N //pimmel@10.0.0.1:445/share /mnt

If -W is fed with ASUF (all uppercase), I get a strange error:

mount_smbfs: invalid local charset specification (IT4)

Connecting to the SAMBA 4.3 server, and with -Wasuf, I get

mount_smbfs: unable to open connection: syserr = RPC struct is bad

Connectingto the Windows 2012 R2 server results in 

mount_smbfs: unable to open connection: syserr = Connection reset by peer

First, the manpage for mount_smbfs(8) is everything else than FreeBSD standard!
There is an unexplained option "-n opt". What is that?

Second, CIFS over tcp/445 seems to be now very(!) common in the Windooze world
- why is that fact not reflected by FreeBSD? I tried to find some
explanations/manpages for "man netsmb" or "smbfs" (the kernel options), but
none found :-(

My interpretation of the above errors are: FreeBSD is incapable to handle CIFS
over tcp/445. The above URL/site claims to have solved the problem, but it
seems not true for CURRENT. 

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

random ZFS panic...

[Larry Rosenman]

Was rebooting my laptop, and got the following:


trivet dumped core - see /var/crash/vmcore.0

Wed Mar  2 06:09:19 CST 2016

FreeBSD trivet 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r296287: Tue Mar  1 
19:13:37 CST 2016 root@trivet:/usr/obj/usr/src/sys/GENERIC  amd64

panic: from debugger

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
<118>.
<118>Terminated
<118>Mar  2 06:07:22 trivet syslogd: exiting on signal 15
<5>wlan0: link state changed to DOWN
Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 0 done
All buffers synced.
lock order reversal:
 1st 0xf80012855d50 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222
 2nd 0xf800128557c8 zfs_gfs (zfs_gfs) @ 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:494
stack backtrace:
#0 0x80a825a0 at witness_debugger+0x70
#1 0x80a824a1 at witness_checkorder+0xe71
#2 0x80a00a6b at __lockmgr_args+0xd3b
#3 0x80ace2bc at vop_stdlock+0x3c
#4 0x80fcb010 at VOP_LOCK1_APV+0x100
#5 0x80aeef9a at _vn_lock+0x9a
#6 0x820c8b13 at gfs_file_create+0x73
#7 0x820c8bbd at gfs_dir_create+0x1d
#8 0x82191f57 at zfsctl_mknode_snapdir+0x47
#9 0x820c9135 at gfs_dir_lookup+0x185
#10 0x820c961d at gfs_vop_lookup+0x1d
#11 0x82190f75 at zfsctl_root_lookup+0xf5
#12 0x82191e13 at zfsctl_umount_snapshots+0x83
#13 0x821aacfb at zfs_umount+0x7b
#14 0x80ad7c70 at dounmount+0x530
#15 0x80ae127b at vfs_unmountall+0x6b
#16 0x80ac24f9 at bufshutdown+0x3b9
#17 0x80a26fe9 at kern_reboot+0x189
lock order reversal:
 1st 0xf800125197c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1222
 2nd 0xf8000ffbc240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2498
stack backtrace:
#0 0x80a825a0 at witness_debugger+0x70
#1 0x80a824a1 at witness_checkorder+0xe71
#2 0x80a00a6b at __lockmgr_args+0xd3b
#3 0x80ace2bc at vop_stdlock+0x3c
#4 0x80fcb010 at VOP_LOCK1_APV+0x100
#5 0x80aeef9a at _vn_lock+0x9a
#6 0x80adf553 at vget+0x63
#7 0x808fcb4d at devfs_allocv+0xcd
#8 0x808fc653 at devfs_root+0x43
#9 0x80ad7b8f at dounmount+0x44f
#10 0x80ae12d4 at vfs_unmountall+0xc4
#11 0x80ac24f9 at bufshutdown+0x3b9
#12 0x80a26fe9 at kern_reboot+0x189
#13 0x80a26e03 at sys_reboot+0x3e3
#14 0x80e7a15b at amd64_syscall+0x2db
#15 0x80e5926b at Xfast_syscall+0xfb
Uptime: 7h20m6s


Fatal trap 9: general protection fault while in kernel mode
cpuid = 2; apic id = 02
instruction pointer = 0x20:0x8215369b
stack pointer   = 0x28:0xfe02329189b0
frame pointer   = 0x28:0xfe02329189c0
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 = 0 (dbu_evict)
Uptime: 7h20m7s
Dumping 2338 out of 8050 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/coretemp.ko.debug...done.
done.
Loaded symbols for /boot/kernel/coretemp.ko
Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ichsmb.ko.debug...done.
done.
Loaded symbols for /boot/kernel/ichsmb.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/smbus.ko.debug...done.
done.
Loaded symbols for /boot/kernel/smbus.ko
Reading symbols from /boot/kernel/hwpmc.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/hwpmc.ko.debug...done.
done.
Loaded symbols for /boot/kernel/hwpmc.ko
Reading symbols from /boot/kernel/iwn135fw.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/iwn135fw.ko.debug...done.
done.
Loaded symbols for /boot/kernel/iwn135fw.ko
Reading symbols from /boot/kernel/aesni.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/aesni.ko.debug...done.
done.
Loaded symbols for /boot/kernel/aesni.ko
Reading symbols from 

Re: Bay Trail 32bit UEFI

[Joe Holden]

On 02/03/2016 01:45, Lundberg, Johannes wrote:

CherryTrail devices/boards with 64bit UEFI are already out. Upgrading
the hardware is one solution (I did).

I'm thinking of the sticks etc, they all have 32bit UEFI and no 
CSM/legacy boot, but have 64bit cpus



I never did try FreeBSD on BayTrail but for running Linux on BayTrail I
used special built Grub that was 32bit but could load 64bit OS. Could
this kind of Grub boot a 64bit FreeBSD, I wonder?

I looked at this but honestly it looked like a giant nightmare - I did 
get grub loading on a test platform (tablet, for display etc) but didn't 
manage to make it boot anything


On Tue, Mar 1, 2016 at 5:20 PM, John Baldwin > wrote:

On Sunday, February 28, 2016 07:00:06 AM Joe Holden wrote:
> Hi all,
>
> Apologies if this is the wrong list...
>
> Is there any plan to support booting FreeBSD on 32bit UEFI systems (with
> or without 64bit kernel/userland)? Obviously there is no i386 efi loader
> currently so neither is possible...

I don't think anyone is actively working on it.  I think it shouldn't be
that much work once the i386 loader is resurrected.  The i386 kernel
just
needs to use the EFI memory map and I think the rest of it should
generally
just work.

--
John Baldwin
___
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: SVN r296272 breaks virtualbox

[Vladimir Zakharov]

On Tue, Mar 01, 2016, Michael Butler wrote:
> The removal of "taskqueue_enqueue_fast" breaks the virtualbox kmods:
> 
> Mar  1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 offMax=0x151c
> Mar  1 16:54:36 toshi kernel: link_elf_obj: symbol
> taskqueue_enqueue_fast undefined
> Mar  1 16:54:36 toshi kernel: linker_load_file: Unsupported file type
> Mar  1 16:54:36 toshi kernel: link_elf_obj: symbol
> taskqueue_enqueue_fast undefined
> Mar  1 16:54:36 toshi kernel: linker_load_file: Unsupported file type
> Mar  1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on vboxnetflt -
> not available or version mismatch
> Mar  1 16:54:36 toshi kernel: linker_load_file: Unsupported file type

Attached patch for emulators/virtualbox-ose and rebuilding
virtualbox-ose and virtualbox-ose-kmod fixed problem for me.

===
--- 
files/patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c.orig   
2016-03-02 10:15:39.814893000 +0300
+++ files/patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c
2016-03-02 10:16:39.070847000 +0300
@@ -1,10 +1,5 @@
-Add VLAN trunking support to vboxnetflt
-
-See:   
http://lists.freebsd.org/pipermail/freebsd-emulation/2012-April/009698.html
-See:   
http://lists.freebsd.org/pipermail/freebsd-emulation/2013-May/010605.html
-Submitted by:  Landon J Fuller 
 ./src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c.orig
2013-04-12 06:38:11.0 -0400
-+++ ./src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c 
2013-05-25 20:14:52.152180452 -0400
+--- src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c.orig  
2016-01-19 22:18:38.0 +0300
 src/VBox/HostDrivers/VBoxNetFlt/freebsd/VBoxNetFlt-freebsd.c   
2016-03-02 10:10:21.181922000 +0300
 @@ -51,6 +51,7 @@
  #include 
  #include 
@@ -13,6 +8,24 @@

  #include 
  #include 
+@@ -369,7 +370,7 @@
+ mtx_lock_spin(>u.s.inq.ifq_mtx);
+ _IF_ENQUEUE(>u.s.inq, m);
+ mtx_unlock_spin(>u.s.inq.ifq_mtx);
+-taskqueue_enqueue_fast(taskqueue_fast, >u.s.tskin);
++taskqueue_enqueue(taskqueue_fast, >u.s.tskin);
+ }
+ /*
+  * Handle mbufs on the outgoing hook, frames going to the interface
+@@ -387,7 +388,7 @@
+ mtx_lock_spin(>u.s.outq.ifq_mtx);
+ _IF_ENQUEUE(>u.s.outq, m);
+ mtx_unlock_spin(>u.s.outq.ifq_mtx);
+-taskqueue_enqueue_fast(taskqueue_fast, >u.s.tskout);
++taskqueue_enqueue(taskqueue_fast, >u.s.tskout);
+ }
+ else
+ {
 @@ -427,6 +428,8 @@
  struct ifnet *ifp = pThis->u.s.ifp;
  unsigned int cSegs = 0;
===

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
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"