Re: Build failed in Jenkins: FreeBSD_HEAD #2473

[Ryan Stone]

*sigh*, this was bad timing by Jenkins.  This is already fixed in
r279440 (it's good to see that Jenkins will catch this kind of thing
so quickly though)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Build failed in Jenkins: FreeBSD_HEAD #2473

[jenkins-admin]

See 

Changes:

[rstone] Add macros to make code compile in kernel

Make it possible to compile libnv in the kernel.  Mostly this
involves wrapping functions that have a different signature in
the kernel and in userland (e.g. malloc()) in a macro that will
conditionally expand to the right API depending on whether the
code is being compiled for the kernel or not.

I have also #ifdef'ed out all of file descriptor-handling code,
as well as the unsafe varargs functions.

Differential Revision:  https://reviews.freebsd.org/D1882
Reviewed by:jfv
MFC after:  1 month
Sponsored by:   Sandvine Inc

[rstone] Allow Illumos code to co-exist with nv(9)

Differential Revision:  https://reviews.freebsd.org/D1881
Reviewed by:jfv, will
Suggested by:   pjd
MFC after:  1 month
Sponsored by:   Sandvine Inc

[rstone] Prevent creation of an invalid nvlist

If an nvlist is set as a child of another nvlist with
nvlist_move_nvlist then fail the operation and set the parent
nvlist to the error state.

Differential Revision:  https://reviews.freebsd.org/D1880
Reviewers:  jfv
MFC after:  1 month
Sponsored by:   Sandvine Inc

[rstone] Don't allocate memory for operations that do not insert

Almost every operation performed on an nvlist was allocating a
new string to hold the key name.  The nvlist_exists* family of
functions would always return false if they failed to allocate
the string.  The rest of the functions would outright abort().
Fix the non-varargs variants of the functions to perform the
requested operations directly and the varargs versions to
allocate the string and call into the non-varargs versions.
The varargs versions are still broken and really can't be fixed,
so we might consider axing them entirely.  However, now the non-
varargs functions are always safe to call.

Differential Revision:  https://reviews.freebsd.org/D1879
Reviewed by:pjd, jfv
MFC after:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Add function to force an nvlist into the error state

Add an nvlist_set_error() function that can be used to force an
nvlist into the error state.  This is useful both for writing
tests and for writing APIs that use nvlists internally.

Differential Revision:  https://reviews.freebsd.org/D1878
Reviewed by:pjd, jfv
MFC After:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Implement asprintf in libkern

Differential Revision:  https://reviews.freebsd.org/D1877
Reviewed by:pjd, jfv
MFC After:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Extend the unit test to fix the bug caught in r277925

Differential Revision:  https://reviews.freebsd.org/D1888
MFC After:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Add tests for dnvlist_take_*

Differential Revision:  https://reviews.freebsd.org/D1876
Reviewed by:jfv, pjd
MFC after:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Add tests for dnv_get_*

Differential Revision:  https://reviews.freebsd.org/D1875
Reviewed by:jfv, pjd
MFC after:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Add tests for nvlist_free* functions

Differential Revision:  https://reviews.freebsd.org/D1874
Reviewed by:jfv, pjd
MFC after:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Add tests for nvlist_take_*

Differential Revision:  https://reviews.freebsd.org/D1873
Reviewed by:jfv, pjd
MFC after:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Add test cases for nvlist_move_*

Differential Revision:  https://reviews.freebsd.org/D1872
Reviewed by:jfv, pjd
MFC after:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Add tests for nvlist_pack/unpack

Differential Revision:  https://reviews.freebsd.org/D1871
Reviewed by:jfv, pjd
MFC after:  1 month
Sponsored by:   Sandvine Inc.

[rstone] Add tests for nvlist_clone

Differential Revision:  https://reviews.freebsd.org/D1870
Reviewed by:pjd, jfv
MFC after:  1 month
Sponsored by:   Sandvine Inc

[rstone] Tests of basic nvlist add functions

Differential Revision:  https://reviews.freebsd.org/D1869
Reviewed by:jfv, pjd
MFC after:  1 month
Sponsored by: 

HEADS UP: PCI SR-IOV infrastructure has been committed to head

[Ryan Stone]

I've just finished committing support for PCI Single Root I/O
Virtualization in the pci subsystem to head.  This should be a no-op
for everyone right now, but there were some minor refactorings in the
pci code that could have a lingering bug.  I did make sure to test
that it boots on a variety of systems (but only i386/amd64, as that's
all that I have access to).

What's been committed to head is only the pci subsystem side of
things, along with the userland tools to configure SR-IOV (along with,
I'm happy to say, a full set of man pages).  What's not in head yet
are any drivers making use of the infrastructure.  Full support for
ixl(4) is complete and I've sent the patch to jfv@; I hope to see the
driver support committed soon.  I don't have any word on timelines for
getting support in other drivers.  Unfortunately adding SR-IOV support
to a driver is not trivial as the standard leaves a lot of the details
up to particular implementations (in the same way the the PCIe
standard does not define how to send a packet from a NIC; instead
defining how the PCIe device will expose its registers and whatnot,
and its up to the PCIe device and driver to understand how to poke at
the registers to send a packet).  I have heard anecdotally that a
number of driver maintainers have been very interested in this work so
I hope that to see more drivers supported SR-IOV in the near future.
I encourage all driver maintainers to read over the new manpages and
contact me if they have any questions about the new infrastructure.

Anybody interested in using SR-IOV should try to attend BSDCan 2015,
as I will be giving a talk on the subject.  I intend to focus more on
the system administration side of configuring and using SR-IOV rather
than the details of implementing an SR-IOV driver.

If anybody did an "svn up" half-way through my muddled series of
commits, sorry about the temporary breakage.  My
buildworld/buildkernel on r279466 just completed successfully so
please make sure that you have at least that revision.  If you still
have problems, please let me know.

I do want to thank John Baldwin for advice about the PCI Subsystem and
newbus and Jack Vogel for his help with the Fortville NIC, including
getting me early access to the VF driver for testing purposes.  Thanks
to everybody who reviewed the changes.  Specially thanks to Mark
Johnston and Sean Mahood, who literally spent hours with me in a
meeting room reviewing the entire patch series last summer
(thankfully, those hours at least weren't consecutive).

Above all, thanks to Sandvine Inc. for sponsoring this work.  This is
definitely the biggest contribution we've ever made to FreeBSD and I
hope to see this kind of thing continue.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atkbd.c not compiling?

[Oliver Pinter]

On Sat, Feb 28, 2015 at 11:19 PM, Garrett Cooper  wrote:
> On Feb 28, 2015, at 14:15, Garrett Cooper  wrote:
>
>> On Feb 28, 2015, at 13:56, Ryan Stone  wrote:
>>
>>> On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper  
>>> wrote:
 I’m not sure about key_map — are you building with syscons or vt?
>>>
>>> I have no idea.  I'm just running make tinderbox.  So far
>>> _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed,
>>> among others.
>>>
>>> i386.LINT and sparc64.LINK have both "device sc" and "device vt" from
>>> what I can see
>>
>> I think I figured it out. Is it because MK_VT != “no” and MK_LEGACY_CONSOLE 
>> == “no”?
>
> … or because MK_SYSCONS == no?

No, when you try to compile vt enabled kernel on system which running
on syscons, or the versa, then you got this problem.
Try to compile with the us.pc-ctrl or us.ctrl keyboard layout.

In bugzilla exists some patch, that fixes this issue, by altering the
font search path.

The other remaining problem is, when use try to use the VT, and it
required the kbdmux layer. The kbdmux layer then discards the custom
keyboard layout, which is configured at ukbd or atkbd level. Fix
already exists in bugzilla too.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sa(4) driver changes available for test

[Dan Langille]

> On Feb 28, 2015, at 6:15 PM, Kenneth D. Merry  wrote:
> 
>> On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote:
>> 
>>> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry  wrote:
>>> 
>>> 
>>> I have updated the patches.
>>> 
>>> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
>>> I committed those separately.
>>> 
>>> I have (hopefully) fixed the build for the stable/10 patches by MFCing
>>> dependencies.  (One of them mav did for me, thanks!)
>>> 
>>> Rough draft commit message:
>>> 
>>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
>> 
>> 
>> I have current installed and running with Bacula, but I have not tried the 
>> tape drive yet.
> 
> Thanks for all your work on this!
> 
>> It seems like your changes are in there from about 5 days ago.
> 
> Yes, that is correct.
> 
>> Having solved my server hardware issues, I'm now having issues with the 
>> autochanger mechanism 
>> of the tape library.  
> 
> Does it work with chio(1)?
> 
> Does it look like hardware or software?  (If it is software, I can help
> with that.)
> 
> 

Hardware. The screw drive for the tape robot is sticky. It can be moved by 
hand, but the motor in this DL 891 cannot. It might need lube. It was suspect 
last time I used it.  Worst case, I will remove ins of the two DLT 8000 tape 
drives and load tapes manually. 
-- 
Dan Langille
http://langille.org/


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

Re: sa(4) driver changes available for test

[Kenneth D. Merry]

On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote:
> 
> > On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry  wrote:
> > 
> > 
> > I have updated the patches.
> > 
> > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> > I committed those separately.
> > 
> > I have (hopefully) fixed the build for the stable/10 patches by MFCing
> > dependencies.  (One of them mav did for me, thanks!)
> > 
> > Rough draft commit message:
> > 
> > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
> 
> 
> I have current installed and running with Bacula, but I have not tried the 
> tape drive yet.
> 

Thanks for all your work on this!

> It seems like your changes are in there from about 5 days ago.

Yes, that is correct.

> Having solved my server hardware issues, I'm now having issues with the 
> autochanger mechanism 
> of the tape library.  

Does it work with chio(1)?

Does it look like hardware or software?  (If it is software, I can help
with that.)

Ken
-- 
Kenneth Merry
k...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Build failed in Jenkins: FreeBSD_HEAD #2472

[jenkins-admin]

See 

Changes:

[loos] Add ofw_gpiobus_parse_gpios(), a new public function, to parse the gpios
property for devices that doesn't descend directly from gpiobus.

The parser supports multiple pins, different GPIO controllers and can use
arbitrary names for the property (to match the many linux variants:
cd-gpios, power-gpios, wp-gpios, etc.).

Pass the driver name on ofw_gpiobus_add_fdt_child().  Update gpioled to
match.

An usage example of ofw_gpiobus_parse_gpios() will follow soon.

[kib] Supposed fix for some SandyBridge mobile CPUs hang on AP startup when
x2APIC mode is detected and enabled.  Current theory is that switching
the APIC mode while an IPI is in flight might be the issue.

Postpone switching to x2APIC mode until we are guaranteed that all
starting IPIs are already send and aknowledged.  Use aps_ready signal
as an indication that the BSP is done with us.

Tested by:  adrian
Sponsored by:   The FreeBSD Foundation
MFC after:  2 months

[kan] Avoid closing unallocated socket in case socreate fails.

Found by: Brainy Code Scanner
Reported by: Maxime Villard 
MFC after: 2 weeks

[kan] Avoid lookup of CODESET aliases using uninitialized path

We do not use iconv.alias file, so avoid using the vestiges
of the code that do.

Differential Revision:  https://reviews.freebsd.org/D1729
Reviewed by: emaste
MFC after: 2 weeks

[loos] Rename and move gpiobus_alloc_ivars() and gpiobus_free_ivars() so they 
can
be used on non FDT systems.

This prevents access to uninitialized memory on drivers that try to access
pin flags on non FDT systems.

[kib] Some fixes for fdescfs lookup code.

Do not ever return doomed vnode from lookup.  This could happen, if
not checked, since dvp is relocked in the 'looking up ourselves' case.

In the other case, since dvp is relocked, mount point might go away
while fdesc_allocvp() is called.  Prevent the situation by doing
vfs_busy() before unlocking dvp.  Reuse the vn_vget_ino_gen() helper.

Reported and tested by: pho
Sponsored by:   The FreeBSD Foundation
MFC after:  2 weeks

[alc] Eliminate a variable that became unused when VFS_LOCK_GIANT() was
eliminated.

MFC after:  3 days

[loos] Add a driver for the Maxim DS3231 a low-cost, extremely accurate (+-2PPM)
I2C real-time clock (RTC).

The DS3231 has an integrated temperature-compensated crystal oscillator
(TXCO) and crystal.

DS3231 has a temperature sensor, an independent 32kHz output (which can be
turned on and off by the driver) and another output that can be used as
interrupt for alarms or as a second square-wave output, which frequency and
operation mode can be set by driver sysctl(8) knobs.

Differential Revision:  https://reviews.freebsd.org/D1016
Reviewed by:ian, rpaulo
Tested on:  Raspberry pi model B

[arybchik] sfxge: compile out LRO if kernel is compiled without IPv4 and IPv6

Sponsored by:   Solarflare Communications, Inc.
Approved by:gnn (mentor)

--
[...truncated 258685 lines...]
CC='cc  ' mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE 
-DHAVE_KERNEL_OPTION_HEADERS -I. 
-I 
-I 
-I
 -std=iso9899:1999   

 

--- depend_subdir_sfxge ---
In file included from 
:40:
In file included from 
:87:
:39:2:
 error: LRO
#error LRO
 ^
--- depend_subdir_si ---
--- device_if.h ---
awk -f 
 
 -h
--- depend_subdir_sfxge ---
1 error generated.
--- depend_subdir_si ---
--- isa_if.h ---
awk -f 
 
 -h
--- pci_if.h ---
awk -f 
 
 -h
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE 
-DHAVE_KERNEL_OPTION_HEADERS -I. 
-I 
-I 
-I
 -std=iso9899:1999   

Re: atkbd.c not compiling?

[Oliver Pinter]

On Sat, Feb 28, 2015 at 10:25 PM, Ryan Stone  wrote:
> I updated my source tree this morning and now I'm seeing this compile
> error in "make tinderbox";
>
> /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:382:26: error: use of 
> undecla
> red identifier 'key_map'; did you mean 'keymap'?
> keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT);
>^~~
>keymap
> /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:358:12: note: 'keymap' 
> declar
> ed here
> keymap_t *keymap;
> /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:383:26: error: use of 
> undecla
> red identifier 'accent_map'; did you mean 'accentmap_t'?
> accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT);
>^
> /repos/users/rstone/freebsd/sys/sys/kbio.h:210:26: note: 'accentmap_t' 
> declared
> here
> typedef struct accentmap accentmap_t;
>

Hi!

See these PRs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193817
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744

>
>
> (By the way, this is the second time in two days that "make tinderbox"
> has been broken for me.  It's extremely frustrating that I can't test
> my pending commits because others haven't done me the same courtesy)
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sa(4) driver changes available for test

[Dan Langille]

> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry  wrote:
> 
> 
> I have updated the patches.
> 
> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> I committed those separately.
> 
> I have (hopefully) fixed the build for the stable/10 patches by MFCing
> dependencies.  (One of them mav did for me, thanks!)
> 
> Rough draft commit message:
> 
> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt


I have current installed and running with Bacula, but I have not tried the tape 
drive yet.

It seems like your changes are in there from about 5 days ago.

Having solved my server hardware issues, I'm now having issues with the 
autochanger mechanism 
of the tape library.  

— 
Dan Langille
http://langille.org/





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

Re: atkbd.c not compiling?

[Garrett Cooper]

On Feb 28, 2015, at 14:15, Garrett Cooper  wrote:

> On Feb 28, 2015, at 13:56, Ryan Stone  wrote:
> 
>> On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper  
>> wrote:
>>> I’m not sure about key_map — are you building with syscons or vt?
>> 
>> I have no idea.  I'm just running make tinderbox.  So far
>> _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed,
>> among others.
>> 
>> i386.LINT and sparc64.LINK have both "device sc" and "device vt" from
>> what I can see
> 
> I think I figured it out. Is it because MK_VT != “no” and MK_LEGACY_CONSOLE 
> == “no”?

… or because MK_SYSCONS == no?


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: atkbd.c not compiling?

[Garrett Cooper]

On Feb 28, 2015, at 13:56, Ryan Stone  wrote:

> On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper  wrote:
>> I’m not sure about key_map — are you building with syscons or vt?
> 
> I have no idea.  I'm just running make tinderbox.  So far
> _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed,
> among others.
> 
> i386.LINT and sparc64.LINK have both "device sc" and "device vt" from
> what I can see

I think I figured it out. Is it because MK_VT != “no” and MK_LEGACY_CONSOLE == 
“no”?


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: atkbd.c not compiling?

[Garrett Cooper]

On Feb 28, 2015, at 13:56, Ryan Stone  wrote:

> On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper  wrote:
>> I’m not sure about key_map — are you building with syscons or vt?
> 
> I have no idea.  I'm just running make tinderbox.  So far
> _.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed,
> among others.
> 
> i386.LINT and sparc64.LINK have both "device sc" and "device vt" from
> what I can see

It looks like a few keyboard drivers would be broken. Might be related to 
[AT]KBD_DFLT_KEYMAP...

From sys/dev/kbd/kbdtables.h :

 31 #ifndef KBD_DFLT_KEYMAP
 32 
 33 /* US iso8859 */
 34 #define ISO_ACCENTCHARS
 35 /*
 36  * Automatically generated from /usr/share/syscons/keymaps/us.iso.kbd.
 37  * DO NOT EDIT!
 38  */
 39 static keymap_t key_map = { 0x6d, {

From sys/dev/atkbd/atkbd.c:

 265 /* the initial key map, accent map and fkey strings */
 266 #ifdef ATKBD_DFLT_KEYMAP
 267 #define KBD_DFLT_KEYMAP
 268 #include "atkbdmap.h"
 269 #endif
 270 #include 


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: atkbd.c not compiling?

[Ryan Stone]

On Sat, Feb 28, 2015 at 4:51 PM, Garrett Cooper  wrote:
> I’m not sure about key_map — are you building with syscons or vt?

I have no idea.  I'm just running make tinderbox.  So far
_.sparc64.LINT, _.i386.LINT-NOINET and _.i386.LINT-VIMAGE have failed,
among others.

i386.LINT and sparc64.LINK have both "device sc" and "device vt" from
what I can see
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atkbd.c not compiling?

[Garrett Cooper]

On Feb 28, 2015, at 13:25, Ryan Stone  wrote:

> I updated my source tree this morning and now I'm seeing this compile
> error in "make tinderbox";
> 
> /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:382:26: error: use of 
> undecla
> red identifier 'key_map'; did you mean 'keymap'?
>keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT);
>   ^~~
>   keymap
> /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:358:12: note: 'keymap' 
> declar
> ed here
>keymap_t *keymap;
> /repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:383:26: error: use of 
> undecla
> red identifier 'accent_map'; did you mean 'accentmap_t'?
>accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT);
>   ^
> /repos/users/rstone/freebsd/sys/sys/kbio.h:210:26: note: 'accentmap_t' 
> declared
> here
> typedef struct accentmap accentmap_t;
> 
> 
> 
> (By the way, this is the second time in two days that "make tinderbox"
> has been broken for me.  It's extremely frustrating that I can't test
> my pending commits because others haven't done me the same courtesy)

I’m not sure about key_map — are you building with syscons or vt?


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: atkbd.c not compiling?

[Ryan Stone]

And now this:

/repos/users/rstone/freebsd-2/sys/modules/sfxge/../../dev/sfxge/sfxge_rx.h:39:2:
error:
  LRO
#error LRO


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

atkbd.c not compiling?

[Ryan Stone]

I updated my source tree this morning and now I'm seeing this compile
error in "make tinderbox";

/repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:382:26: error: use of undecla
red identifier 'key_map'; did you mean 'keymap'?
keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT);
   ^~~
   keymap
/repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:358:12: note: 'keymap' declar
ed here
keymap_t *keymap;
/repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:383:26: error: use of undecla
red identifier 'accent_map'; did you mean 'accentmap_t'?
accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT);
   ^
/repos/users/rstone/freebsd/sys/sys/kbio.h:210:26: note: 'accentmap_t' declared
here
typedef struct accentmap accentmap_t;



(By the way, this is the second time in two days that "make tinderbox"
has been broken for me.  It's extremely frustrating that I can't test
my pending commits because others haven't done me the same courtesy)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Jenkins build is back to stable : FreeBSD_HEAD-tests2 #786

[jenkins-admin]

See 

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

Jenkins build is still unstable: FreeBSD_HEAD-tests2 #785

[jenkins-admin]

See 

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

Re: sa(4) driver changes available for test

[Dan Langille]

> On Feb 28, 2015, at 11:48 AM, Dan Langille  wrote:
> 
> 
>> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry  wrote:
>> 
>> 
>> I have updated the patches.
>> 
>> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
>> I committed those separately.
>> 
>> I have (hopefully) fixed the build for the stable/10 patches by MFCing
>> dependencies.  (One of them mav did for me, thanks!)
>> 
>> Rough draft commit message:
>> 
>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
>> 
>> The patches against FreeBSD/head as of SVN revision 278975:
>> 
>> http://people.freebsd.org/~ken/sa_changes.20150218.1.txt
>> 
>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
>> 
>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt
> 
> Not sure what I've done wrong here.
> 
> I've applied your patches and run make buildworld against:

It appears 'patch -p0' is my friend...

It's been a long time..

— 
Dan Langille
http://langille.org/





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

Re: sa(4) driver changes available for test

[Dan Langille]

> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry  wrote:
> 
> 
> I have updated the patches.
> 
> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> I committed those separately.
> 
> I have (hopefully) fixed the build for the stable/10 patches by MFCing
> dependencies.  (One of them mav did for me, thanks!)
> 
> Rough draft commit message:
> 
> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
> 
> The patches against FreeBSD/head as of SVN revision 278975:
> 
> http://people.freebsd.org/~ken/sa_changes.20150218.1.txt
> 
> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
> 
> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt

Not sure what I've done wrong here.

I've applied your patches and run make buildworld against:

[root@cuppy:/usr/src] # svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn0.us-west.freebsd.org/base/stable/10
Relative URL: ^/stable/10
Repository Root: https://svn0.us-west.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 278721
Node Kind: directory
Schedule: normal
Last Changed Author: ngie
Last Changed Rev: 278721
Last Changed Date: 2015-02-13 21:46:22 + (Fri, 13 Feb 2015)

But I get:

rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> lib/libmp (cleandir)
rm -f Version.map libmp.3.gz libmp.3.cat.gz
rm -f a.out mpasbn.o mpasbn.o.tmp 
rm -f mpasbn.po  mpasbn.po.tmp
rm -f mpasbn.So mpasbn.so mpasbn.So.tmp
rm -f libmp.so
rm -f libmp.a libmp_p.a libmp.so.7
rm -f Version.map
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> lib/libmt (cleandir)
cd: /usr/src/lib/libmt: No such file or directory
*** Error code 2

Stop.
make[3]: stopped in /usr/src/lib
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src


> 
> Thanks,
> 
> Ken
> 
> On Fri, Feb 13, 2015 at 17:32:32 -0700, Kenneth D. Merry wrote:
>> 
>> I have a fairly large set of changes to the sa(4) driver and mt(1) driver
>> that I'm planning to commit in the near future.
>> 
>> A description of the changes is here and below in this message.
>> 
>> If you have tape hardware and the inclination, I'd appreciate testing and
>> feedback.
>> 
>> 
>> Rough draft commit message:
>> 
>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt
>> 
>> The patches against FreeBSD/head as of SVN revision 278706:
>> 
>> http://people.freebsd.org/~ken/sa_changes.20150213.3.txt
>> 
>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278721.
>> 
>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt
>> 
>> 
>> The intent is to get the tape infrastructure more up to date, so we can
>> support LTFS and more modern tape drives:
>> 
>> http://www.ibm.com/systems/storage/tape/ltfs/
>> 
>> I have ported IBM's LTFS Single Drive Edition to FreeBSD.  The port depends
>> on the patches linked above.  It isn't fully cleaned up and ready for
>> redistribution.  If you're interested, though, let me know and I'll tell
>> you when it is ready to go out.  You need an IBM LTO-5, LTO-6, TS1140 or
>> TS1150 tape drive.  HP drives aren't supported by IBM's LTFS, and older
>> drives don't have the necessary features to support LTFS.
>> 
>> The commit message below outlines most of the changes.
>> 
>> A few comments:
>> 
>> 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately.
>> 
>> 2. The XML output is similar to what GEOM and CTL do.  It would be nice to
>>   figure out how to put a standard schema on it so that standard tools
>>   could read it.  I don't know how feasible that is, since I haven't
>>   time to dig into it.  If anyone has suggestions on whether that is
>>   feasible or advisable, I'd appreciate feedback.
>> 
>> 3. I have tested with a reasonable amount of tape hardware (see below for a
>>   list), but more testing and feedback would be good.
>> 
>> 4. Standard 'mt status' output looks like this:
>> 
>> # mt -f /dev/nsa3 status  -v
>> Drive: sa3:  Serial Number: 101500520A
>> -
>> Mode  Density  Blocksize  bpi  Compression
>> Current:  0x5a:LTO-6   variable   384607   enabled (0xff)
>> -
>> Current Driver State: at rest.
>> -
>> Partition:   0  Calc File Number:   0 Calc Record Number: 0
>> Residual:0  Reported File Number:   0 Reported Record Number: 0
>> Flags: BOP
>> 
>> 5. 'mt status -v' looks like this:
>> 
>> # mt -f /dev/nsa3 status  -v
>> Drive: sa3:  Serial Number: 101500520A
>> -
>> Mode  Density  Blocksize  bpi  Compression
>> Current:  0x5a:LTO-6   variable   384607   enabled (0xff)
>> -
>> Current Driver State: at rest.
>> -
>> Partition:   0  Calc File Number:   0

Re: sa(4) driver changes available for test

[Dan Langille]

> On Feb 28, 2015, at 1:47 AM, Kenneth D. Merry  wrote:
> 
> On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote:
>> 
>>> On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry  wrote:
>>> 
>>> On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
 
> On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry  wrote:
> 
> 
> I have a fairly large set of changes to the sa(4) driver and mt(1) driver
> that I'm planning to commit in the near future.
> 
> A description of the changes is here and below in this message.
> 
> If you have tape hardware and the inclination, I'd appreciate testing and
> feedback.
 
 I have a DLT 8000 and an SDLT 220.
 
 I don't have anything running current, but I have a spare machine which I 
 could use for testing.
 
 Do you see any value is tests with that hardware? I'd be testing it via 
 Bacula.
 
 disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer.
 
>>> 
>>> Actually, yes.  Bacula is a bit tricky to configure, so your trying it out
>>> would be helpful if you have the time.
>> 
>> I have been unable to test yet.  I've encountered time and hardware issues.
> 
> I know how that goes!  (On both counts.)

Hardware issues fixed.  Now upgrading that zfsroot box from 9.2 to 10.1 RELEASE.

  sudo freebsd-update -r 10.1-RELEASE upgrade

Then I'll grab sources, apply your 10 STABLE patches,  and build world.

> 
>> I may be able to try tomorrow.
> 
> So I have tested building it and it does build at least.  If you're able to
> figure out some of the answers below, that would be great!
> 
>>> 
>>> In looking at the manuals for both the SDLT 220 and the DLT 8000, they both
>>> claim to support long position information for the SCSI READ POSITION
>>> command.
>>> 
>>> You can see what I'm talking about by doing:
>>> 
>>> mt eod
>>> mt status
>>> 
>>> On my DDS-4 tape drive, this shows:
>>> 
>>> # mt -f /dev/nsa3 status
>>> Drive: sa3:  Serial Number: HJ00YWY
>>> -
>>> Mode  Density  Blocksize  bpi  Compression
>>> Current:  0x26:DDS-4   1024 bytes 97000enabled (DCLZ)
>>> -
>>> Current Driver State: at rest.
>>> -
>>> Partition:   0  Calc File Number:  -1 Calc Record Number: -1
>>> Residual:0  Reported File Number:  -1 Reported Record Number: -1
>>> Flags: None
>>> 
>>> But on an LTO-5, which will give long position information, I get:
>>> 
>>> [root@doc ~]# mt status
>>> Drive: sa0: 
>>> -
>>> Mode  Density  Blocksize  bpi  Compression
>>> Current:  0x58:LTO-5   variable   384607   enabled (0x1)
>>> -
>>> Current Driver State: at rest.
>>> -
>>> Partition:   0  Calc File Number:   2 Calc Record Number: -1
>>> Residual:0  Reported File Number:   2 Reported Record Number: 32373
>>> Flags: None
>>> 
>>> That, in combination with the changes I made to the position information
>>> code in the driver, mean that even the old MTIOCGET ioctl should return an
>>> accurate file number at end of data.  e.g., on the LTO-5:
>>> 
>>> [root@doc ~]# mt ostatus
>>> Mode  Density  Blocksize  bpi  Compression
>>> Current:  0x58:LTO-5   variable   384607   0x1
>>> -available modes-
>>> 0:0x58:LTO-5   variable   384607   0x1
>>> 1:0x58:LTO-5   variable   384607   0x1
>>> 2:0x58:LTO-5   variable   384607   0x1
>>> 3:0x58:LTO-5   variable   384607   0x1
>>> -
>>> Current Driver State: at rest.
>>> -
>>> File Number: 2  Record Number: -1   Residual Count -1
>>> 
>>> So the thing to try, in addition to just making sure that Bacula continues
>>> to work properly, is to try setting this for the tape drive in
>>> bacula-sd.conf:
>>> 
>>> Hardware End of Medium = yes
>>> 
>>> It looks like the Bacula tape program (btape) has a test mode, and it would
>>> be good to run through the tests on one of the tape drives and see whether
>>> they work, and whether the results are different before and after the
>>> changes.  I'm not sure how to enable the test mode.
>>> 
 I'll let the other Bacula devs know about this.  They deal with the 
 hardware.  I work on PostgreSQL.
 
>>> 
>>> Thanks!  If there are additional features they would like out of the tape
>>> driver, I'm happy to talk about it.  (Or help if they'd like to use the new
>>> status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.)
>>> 
>>> Ken
>>> -- 
>>> Kenneth Merry
>>> k...@freebsd.org
>> 
>> ? 
>> Dan Langille
>> http://langille.org/
>> 
>> 
>> 
>> 
>> 
> 
> Ken
> -- 
> Kenneth Merry
> k...@freebsd.org

— 
Dan Langille
http://langille.org/





__

Jenkins build is still unstable: FreeBSD_HEAD-tests2 #784

[jenkins-admin]

See 

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

Jenkins build is still unstable: FreeBSD_HEAD-tests2 #783

[jenkins-admin]

See 

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