from:"Andre Albsmeier"

Re: svn commit: r359203 - stable/11/sys/conf

2020-03-22 Thread Andre Albsmeier

On Sun, 22-Mar-2020 at 02:26:15 +, Alan Somers wrote:
> Author: asomers
> Date: Sun Mar 22 02:26:14 2020
> New Revision: 359203
> URL: https://svnweb.freebsd.org/changeset/base/359203
> 
> Log:
>   MFC r354779:
>   
>   Actually hook CAM_IO_STATS up to the build

And CAM_TEST_FAILURE (esp. 2 times)? Can't find any references to this...

>   ...
> @@ -1344,6 +1345,9 @@ options SCSI_NO_SENSE_STRINGS
>  options  SCSI_NO_OP_STRINGS
>  options  SCSI_DELAY=5000 # Be pessimistic about Joe SCSI device
>  options  CAM_IOSCHED_DYNAMIC
> +options  CAM_TEST_FAILURE
> +options  CAM_IO_STATS
> +options  CAM_TEST_FAILURE
>  
>  # Options for the CAM CDROM driver:
>  # CHANGER_MIN_BUSY_SECONDS: Guaranteed minimum time quantum for a changer LUN
> 
> Modified: stable/11/sys/conf/options
> ==
> --- stable/11/sys/conf/optionsSun Mar 22 01:40:12 2020
> (r359202)
> +++ stable/11/sys/conf/optionsSun Mar 22 02:26:14 2020
> (r359203)
> @@ -334,6 +334,8 @@ CAM_DEBUG_LUN opt_cam.h
>  CAM_DEBUG_FLAGS  opt_cam.h
>  CAM_BOOT_DELAY   opt_cam.h
>  CAM_IOSCHED_DYNAMIC  opt_cam.h
> +CAM_IO_STATS opt_cam.h
> +CAM_TEST_FAILURE opt_cam.h
>  SCSI_DELAY   opt_scsi.h
>  SCSI_NO_SENSE_STRINGSopt_scsi.h
>  SCSI_NO_OP_STRINGS   opt_scsi.h
> ___
> svn-src-stable...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-stable-11
> To unsubscribe, send any mail to "svn-src-stable-11-unsubscr...@freebsd.org"

-- 
FreeBSD: We eat penguins for breakfast
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r346775 - stable/11/usr.sbin/nfsdumpstate

2019-04-29 Thread Andre Albsmeier

On Sat, 27-Apr-2019 at 02:13:15 +, Rick Macklem wrote:
> Author: rmacklem
> Date: Sat Apr 27 02:13:15 2019
> New Revision: 346775
> URL: https://svnweb.freebsd.org/changeset/base/346775
> 
> Log:
>   MFC: r346190
>   Fix nfsdumpstate(8) so that it can print out INET6 callback addresses.
>   
>   The patch adds support for printing of INET6 callback addresses.
>   It also adds the #ifdef INET, INET6 as requested by bz@.

We should also put ifdefs around the nbuf def:

#ifdef INET6
char nbuf[INET6_ADDRSTRLEN];
#endif

-Andre

> 
> Modified:
>   stable/11/usr.sbin/nfsdumpstate/Makefile
>   stable/11/usr.sbin/nfsdumpstate/nfsdumpstate.c
> Directory Properties:
>   stable/11/   (props changed)
> 
> Modified: stable/11/usr.sbin/nfsdumpstate/Makefile
> ==
> --- stable/11/usr.sbin/nfsdumpstate/Makefile  Sat Apr 27 02:05:04 2019
> (r346774)
> +++ stable/11/usr.sbin/nfsdumpstate/Makefile  Sat Apr 27 02:13:15 2019
> (r346775)
> @@ -1,6 +1,15 @@
>  # $FreeBSD$
>  
> +.include 
> +
>  PROG=nfsdumpstate
>  MAN= nfsdumpstate.8
> +
> +.if ${MK_INET_SUPPORT} != "no"
> +CFLAGS+= -DINET
> +.endif
> +.if ${MK_INET6_SUPPORT} != "no"
> +CFLAGS+= -DINET6
> +.endif
>  
>  .include 
> 
> Modified: stable/11/usr.sbin/nfsdumpstate/nfsdumpstate.c
> ==
> --- stable/11/usr.sbin/nfsdumpstate/nfsdumpstate.cSat Apr 27 02:05:04 
> 2019(r346774)
> +++ stable/11/usr.sbin/nfsdumpstate/nfsdumpstate.cSat Apr 27 02:13:15 
> 2019(r346775)
> @@ -121,13 +121,14 @@ dump_openstate(void)
>  {
>   struct nfsd_dumplist dumplist;
>   int cnt, i;
> + char nbuf[INET6_ADDRSTRLEN];
>  
>   dumplist.ndl_size = DUMPSIZE;
>   dumplist.ndl_list = (void *)dp;
>   if (nfssvc(NFSSVC_DUMPCLIENTS, ) < 0)
>   errx(1, "Can't perform dump clients syscall");
>  
> - printf("%-13s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %-15s %s\n",
> + printf("%-13s %9.9s %9.9s %9.9s %9.9s %9.9s %9.9s %-45s %s\n",
>   "Flags", "OpenOwner", "Open", "LockOwner",
>   "Lock", "Deleg", "OldDeleg", "Clientaddr", "ClientID");
>   /*
> @@ -143,9 +144,23 @@ dump_openstate(void)
>   dp[cnt].ndcl_nlocks,
>   dp[cnt].ndcl_ndelegs,
>   dp[cnt].ndcl_nolddelegs);
> - if (dp[cnt].ndcl_addrfam == AF_INET)
> - printf("%-15s ",
> + switch (dp[cnt].ndcl_addrfam) {
> +#ifdef INET
> + case AF_INET:
> + printf("%-45s ",
>   inet_ntoa(dp[cnt].ndcl_cbaddr.sin_addr));
> + break;
> +#endif
> +#ifdef INET6
> + case AF_INET6:
> + if (inet_ntop(AF_INET6, [cnt].ndcl_cbaddr.sin6_addr,
> + nbuf, sizeof(nbuf)) != NULL)
> + printf("%-45s ", nbuf);
> + else
> + printf("%-45s ", " ");
> + break;
> +#endif
> + }
>   for (i = 0; i < dp[cnt].ndcl_clid.nclid_idlen; i++)
>   printf("%02x", dp[cnt].ndcl_clid.nclid_id[i]);
>   printf("\n");
> ___
> svn-src-stable...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-stable-11
> To unsubscribe, send any mail to "svn-src-stable-11-unsubscr...@freebsd.org"

-- 
Linux is only free if your time is worthless.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r341794 - stable/11/etc/periodic/weekly

2018-12-21 Thread Andre Albsmeier

On Sun, 16-Dec-2018 at 06:47:04 +0700, Eugene Grosbein wrote:
> 15.12.2018 23:58, Ian Lepore wrote:
> 
> > It uses sysrc, which sources in /usr/share/bsdconfig/common.subr; this
> > is the first reference to sysrc in any periodic script, so it does
> > establish a new dependency, requiring sysrc to be installed on any
> > system that runs periodic scripts.
> 
> Thanks, I've re-implemented this without sysrc.
> 
> > A safer way to extract the root path of all running jails might be
> > something like:
> > 
> >   if which -s jls; then
> >   allpaths="$(jls -d path)"
> >   for onepath in ${allpaths}; do 
> >   # do whatever with ${onepath} here
> >   done
> >   fi
> 
> This needs to check for all configured full-blown jails including maybe not 
> running at the moment.
> sysrc is handy but is not really necessary.
> 
> Andre, this should fix it for your case, please test:
> 
> fetch -o /tmp/noid.diff 
> 'https://svnweb.freebsd.org/base/head/usr.sbin/periodic/etc/weekly/340.noid?view=patch=342141=342140=342141'
> cd /etc/periodic/weekly && patch -p5 < /tmp/noid.diff

Yes, that fixes it, thanks. But please note that I don't use jails and don't
have jail(8) installed at all (WITHOUT_JAIL).

Also, maybe we should check if jail(8) exists before running $(jail ...) or
even the whole "if" expression. The result will probably be the same but one
can clearly see that it depends on jail(8) and maybe one can then even leave
out the 2>/dev/null so errors can come through (no idea if this is something
that can happen). Something like (bad indenting to be ignored):

--- 340.noid.ORI2018-12-22 08:26:24.515158000 +0100
+++ 340.noid2018-12-22 08:27:51.985887000 +0100
@@ -21,6 +21,7 @@
# of this script.

exclude=''
+if [ -x /usr/sbin/jail ]; then
if [ $(sysctl -n security.jail.jailed) = 0 ]; then
# For jail_conf
. /etc/rc.subr
@@ -29,7 +30,7 @@
sep=:
OIFS="$IFS"
IFS="$sep"
-   for param in $(jail -f "$jail_conf" -e "$sep" 2>/dev/null)
+   for param in $(jail -f "$jail_conf" -e "$sep")
do
case "$param" in
path=*)
@@ -44,6 +45,7 @@
done
IFS="$OIFS"
fi
+fi

rc=$(find -H ${weekly_noid_dirs:-/} \
\( $exclude ! -fstype local -prune -or -name \* \) -and \

(Or replace the -x by some which(1) construct...)

Sorry for the late reply but I was on holidays (and had to wait for the weekly
run anyway).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r341794 - stable/11/etc/periodic/weekly

2018-12-15 Thread Andre Albsmeier

On Mon, 10-Dec-2018 at 14:24:42 +, Eugene Grosbein wrote:
> Author: eugen
> Date: Mon Dec 10 14:24:41 2018
> New Revision: 341794
> URL: https://svnweb.freebsd.org/changeset/base/341794
> 
> Log:
>   MFC r340322-r340324,r340327: periodic/etc/weekly/340.noid
>   
>   Prevent periodic/etc/weekly/340.noid from descending into root directories
>   of jails. Jails have their own user/group databases and this script
>   can produce multiple false warnings, not to mention significant extra
>   load in case of large jailed subtrees. Leave this check for jailed
>   invocations of the same script.

This gave me:

Check for files with an unknown user or group:
.: cannot open /usr/share/bsdconfig/common.subr: No such file or directory

on systems where bsdconfig is not installed.

-Andre

> 
> Modified:
>   stable/11/etc/periodic/weekly/340.noid
> Directory Properties:
>   stable/11/   (props changed)
> 
> Modified: stable/11/etc/periodic/weekly/340.noid
> ==
> --- stable/11/etc/periodic/weekly/340.noidMon Dec 10 14:19:57 2018
> (r341793)
> +++ stable/11/etc/periodic/weekly/340.noidMon Dec 10 14:24:41 2018
> (r341794)
> @@ -16,8 +16,26 @@ case "$weekly_noid_enable" in
>   echo ""
>   echo "Check for files with an unknown user or group:"
>  
> + # Host should not test jailed subtrees as jails have their own
> + # databases of users and groups. Leave them for jailed invocations
> + # of this script.
> +
> + exclude=''
> + if [ $(sysctl -n security.jail.jailed) = 0 ]; then
> + sep=:
> + OIFS="$IFS"
> + IFS="$sep"
> + for param in $(jail -f "`sysrc -n jail_conf`" -e "$sep" 2>/dev/null)
> + do
> + case "$param" in
> + path=*) exclude="$exclude -path ${param#path=} -prune -or"
> + esac
> + done
> + IFS="$OIFS"
> + fi
> +
>   rc=$(find -H ${weekly_noid_dirs:-/} \
> - \( ! -fstype local -prune -or -name \* \) -and \
> + \( $exclude ! -fstype local -prune -or -name \* \) -and \
>   \( -nogroup -o -nouser \) -print | sed 's/^/  /' |
>   tee /dev/stderr | wc -l)
>   [ $rc -gt 1 ] && rc=1
> ___
> svn-src-stable...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-stable-11
> To unsubscribe, send any mail to "svn-src-stable-11-unsubscr...@freebsd.org"

-- 
"FreeBSD has always been the operating system that GNU/Linux-based
operating systems should have been."
   - Frank Pohlmann, IBM
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r339008 - in stable/11: include/rpcsvc lib/libutil libexec/rpc.rquotad sys/cddl/contrib/opensolaris/uts/common/fs/zfs usr.bin/quota

2018-12-04 Thread Andre Albsmeier

On Sat, 29-Sep-2018 at 00:44:23 +, Sean Eric Fagan wrote:
> Author: sef
> Date: Sat Sep 29 00:44:23 2018
> New Revision: 339008
> URL: https://svnweb.freebsd.org/changeset/base/339008
> 
> Log:
>   MFC r336017,r338799
>   
>   r336017
>   This exposes ZFS user and group quotas via the normal
>   quatactl(2) mechanism.  (Read-only at this point, however.)
>   In particular, this is to allow rpc.rquotad query quotas
>   for NFS mounts, allowing users to see their quotas on the
>   hosts using the datasets.
>   
>   The changes specifically:
>   
>   * Add new RPC entry points for querying quotas.
>   * Changes the library routines to allow non-UFS quotas.

This broke repquota on my UFS. I fixed it with:

--- lib/libutil/quotafile.c.ORI 2018-09-29 11:56:05.0 +0200
+++ lib/libutil/quotafile.c 2018-12-04 13:00:04.450826000 +0100
@@ -125,18 +125,18 @@
strlcpy(qf->fsname, fs->fs_file, sizeof(qf->fsname));
if (stat(qf->fsname, ) != 0)
goto error;
qf->dev = st.st_dev;
qcmd = QCMD(Q_GETQUOTASIZE, quotatype);
+   serrno = hasquota(fs, quotatype, qf->qfname, sizeof(qf->qfname));
if (quotactl(qf->fsname, qcmd, 0, >wordsize) == 0)
return (qf);
/* We only check the quota file for ufs */
if (strcmp(fs->fs_vfstype, "ufs")) {
errno = 0;
goto error;
}
-   serrno = hasquota(fs, quotatype, qf->qfname, sizeof(qf->qfname));
if (serrno == 0) {
errno = EOPNOTSUPP;
goto error;
}
qf->accmode = openflags & O_ACCMODE;


Apparently it wants qf->qfname to be filled in by hasquota(). No idea
if calling hasquota() hurts for non-UFS...

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

Re: svn commit: r333673 - in stable/11/etc: etc.aarch64 etc.amd64 etc.arm etc.i386 etc.powerpc etc.riscv etc.sparc64

2018-05-18 Thread Andre Albsmeier

On Wed, 16-May-2018 at 13:18:38 +, Warner Losh wrote:
> Author: imp
> Date: Wed May 16 13:18:37 2018
> New Revision: 333673
> URL: https://svnweb.freebsd.org/changeset/base/333673
> 
> Log:
>   MFC r333436: only launch getty if underlying device exists

Can the onifexists thing work under 11? I had problems
with my ttys until I switched  back to "on". I also can't
find an MFC of r315733 which apparently implemented this
in HEAD...
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331506 - in stable/11/sys: arm/at91 arm/broadcom/bcm2835 arm/freescale/imx arm/freescale/vybrid arm/lpc arm/samsung/exynos arm/ti dev/flash dev/spibus dev/xilinx mips/atheros mips/med

2018-03-28 Thread Andre Albsmeier

On Sat, 24-Mar-2018 at 23:23:31 +, Ian Lepore wrote:
> Author: ian
> Date: Sat Mar 24 23:23:31 2018
> New Revision: 331506
> URL: https://svnweb.freebsd.org/changeset/base/331506
> 
> Log:
>   MFC r310017, r310229, r312289, r327260, r329539, r329544-r329546, r329620,
>   r329729, r329911, r32
>   ...
>   r329546:
>   Build at45d and mx25l SPI flash drivers as modules.
>   ...

Probably missing:

--- sys/modules/spi/mx25l/Makefile.ORI  2018-03-25 19:36:19.825192000 +0200
+++ sys/modules/spi/mx25l/Makefile  2018-03-29 07:23:45.630508000 +0200
@@ -10,6 +10,7 @@
bus_if.h \
device_if.h \
spibus_if.h \
+   opt_platform.h
 
 .if !empty(OPT_FDT)
 SRCS+= ofw_bus_if.h
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331502 - stable/11/sys/modules/i2c/iicbus

2018-03-28 Thread Andre Albsmeier

On Sat, 24-Mar-2018 at 22:50:59 +, Ian Lepore wrote:
> Author: ian
> Date: Sat Mar 24 22:50:59 2018
> New Revision: 331502
> URL: https://svnweb.freebsd.org/changeset/base/331502
> 
> Log:
>   MFC r329534-r329535
>   
>   r329534:
>   Arrange SRCS= as 1 file per line, alphabetical, so it's easier to maintain.
>   Whitespace only, no functional changes.
>   
>   r329535:
>   Add iic_recover_bus.c, now part of iicbus.  This should have been added
>   as part of r320463.

And this one probably too ;-).
 
--- Makefile.ORI2018-03-29 06:40:08.695742000 +0200
+++ Makefile2018-03-29 06:40:20.743473000 +0200
@@ -13,6 +13,7 @@
iicbus_if.h \
iiconf.c \
iiconf.h \
+   opt_platform.h
 
 .if !empty(OPT_FDT)
 SRCS+= ofw_iicbus.c ofw_bus_if.h
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r328692 - in stable/11/sys: conf dev/nvme

2018-02-08 Thread Andre Albsmeier

On Thu, 01-Feb-2018 at 16:53:08 +, Alexander Motin wrote:
> Author: mav
> Date: Thu Feb  1 16:53:08 2018
> New Revision: 328692
> URL: https://svnweb.freebsd.org/changeset/base/328692
> 
> Log:
>   MFC r322995 (by imp):
>   Add new compile-time option NVME_USE_NVD that sets the default value

We probably need this one as well:

me-2@buildbox:/usr/src>odiff sys/modules/nvme/Makefile
--- sys/modules/nvme/Makefile.ORI   2017-05-31 06:17:35.982891000 +0200
+++ sys/modules/nvme/Makefile   2018-02-09 06:19:57.268173000 +0100
@@ -17,6 +17,7 @@
bus_if.h\
device_if.h \
opt_cam.h   \
+   opt_nvme.h  \
pci_if.h
 
 .include 

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

Re: svn commit: r322345 - stable/11/lib/libc/x86/sys

2017-08-13 Thread Andre Albsmeier

On Sun, 13-Aug-2017 at 16:37:36 +0300, Konstantin Belousov wrote:
> On Sun, Aug 13, 2017 at 03:13:11PM +0200, Andre Albsmeier wrote:
> > On Thu, 10-Aug-2017 at 09:00:15 +, Konstantin Belousov wrote:
> > > Author: kib
> > > Date: Thu Aug 10 09:00:15 2017
> > > New Revision: 322345
> > > URL: https://svnweb.freebsd.org/changeset/base/322345
> > > 
> > > Log:
> > >   MFC r321608:
> > >   Use MFENCE to serialize RDTSC on non-Intel CPUs.
> > 
> > This broke libc on my
> > 
> > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 
> > 4.0.0)
> > VT(vga): text 80x25
> > CPU: AMD-K6tm w/ multimedia extensions (199.44-MHz 586-class CPU)
> >   Origin="AuthenticAMD"  Id=0x562  Family=0x5  Model=0x6  Stepping=2
> >   Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX>
> >   AMD Features=0x400<>
> > 
> > On system start, it actually makes various programmes hang until
> > Ctrl-C is pressed. Reboot is not possible (endlessly hanging with
> > 'zillions of defunct processes).
> > 
> > Going back to r322042 fixes it...
> 
> Indeed code is broken on i386 machines which have CPUID but no SSE.

Wonder how many of these still exist...

> Try this.

I just compiled and installed libc.so.7 with this patch on the machine
in question and the test I used for hunting down the reason (ls -l /lib) 
was OK. I then rebooted the whole box and it looked good as well.

I did not compile stuff which links libc statically and hung before (devd)
but I am pretty sure this will be OK as well...

Thanks,

-Andre

> 
> diff --git a/lib/libc/x86/sys/__vdso_gettc.c b/lib/libc/x86/sys/__vdso_gettc.c
> index 4ada5e7eac1..ef2ca69edf7 100644
> --- a/lib/libc/x86/sys/__vdso_gettc.c
> +++ b/lib/libc/x86/sys/__vdso_gettc.c
> @@ -101,6 +101,7 @@ init_fence(void)
>  #if defined(__i386__)
>   u_int cpuid_supported, p[4];
>  
> + lfence_works = LMB_NONE;
>   __asm __volatile(
>   "   pushfl\n"
>   "   popl%%eax\n"
> @@ -121,8 +122,7 @@ init_fence(void)
>   cpuidp(0x1, p);
>   if ((p[3] & CPUID_SSE2) != 0)
>   lfence_works = select_lmb();
> - } else
> - lfence_works = LMB_NONE;
> + }
>  #elif defined(__amd64__)
>   lfence_works = select_lmb();
>  #else

-- 
My other computer is your windows box.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r322345 - stable/11/lib/libc/x86/sys

2017-08-13 Thread Andre Albsmeier

On Thu, 10-Aug-2017 at 09:00:15 +, Konstantin Belousov wrote:
> Author: kib
> Date: Thu Aug 10 09:00:15 2017
> New Revision: 322345
> URL: https://svnweb.freebsd.org/changeset/base/322345
> 
> Log:
>   MFC r321608:
>   Use MFENCE to serialize RDTSC on non-Intel CPUs.

This broke libc on my

FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 
4.0.0)
VT(vga): text 80x25
CPU: AMD-K6tm w/ multimedia extensions (199.44-MHz 586-class CPU)
  Origin="AuthenticAMD"  Id=0x562  Family=0x5  Model=0x6  Stepping=2
  Features=0x8001bf
  AMD Features=0x400<>

On system start, it actually makes various programmes hang until
Ctrl-C is pressed. Reboot is not possible (endlessly hanging with
'zillions of defunct processes).

Going back to r322042 fixes it...

-Andre

> 
> Modified:
>   stable/11/lib/libc/x86/sys/__vdso_gettc.c
> Directory Properties:
>   stable/11/   (props changed)
> 
> Modified: stable/11/lib/libc/x86/sys/__vdso_gettc.c
> ==
> --- stable/11/lib/libc/x86/sys/__vdso_gettc.c Thu Aug 10 06:59:43 2017
> (r322344)
> +++ stable/11/lib/libc/x86/sys/__vdso_gettc.c Thu Aug 10 09:00:15 2017
> (r322345)
> @@ -52,57 +52,108 @@ __FBSDID("$FreeBSD$");
>  #endif
>  #include "libc_private.h"
>  
> +static enum LMB {
> + LMB_UNKNOWN,
> + LMB_NONE,
> + LMB_MFENCE,
> + LMB_LFENCE
> +} lfence_works = LMB_UNKNOWN;
> +
>  static void
> -lfence_mb(void)
> +cpuidp(u_int leaf, u_int p[4])
>  {
> +
> + __asm __volatile(
>  #if defined(__i386__)
> - static int lfence_works = -1;
> + "   pushl   %%ebx\n"
> +#endif
> + "   cpuid\n"
> +#if defined(__i386__)
> + "   movl%%ebx,%1\n"
> + "   popl%%ebx"
> +#endif
> + : "=a" (p[0]),
> +#if defined(__i386__)
> + "=r" (p[1]),
> +#elif defined(__amd64__)
> + "=b" (p[1]),
> +#else
> +#error "Arch"
> +#endif
> + "=c" (p[2]), "=d" (p[3])
> + :  "0" (leaf));
> +}
> +
> +static enum LMB
> +select_lmb(void)
> +{
> + u_int p[4];
> + static const char intel_id[] = "GenuntelineI";
> +
> + cpuidp(0, p);
> + return (memcmp(p + 1, intel_id, sizeof(intel_id) - 1) == 0 ?
> + LMB_LFENCE : LMB_MFENCE);
> +}
> +
> +static void
> +init_fence(void)
> +{
> +#if defined(__i386__)
>   u_int cpuid_supported, p[4];
>  
> - if (lfence_works == -1) {
> - __asm __volatile(
> - "   pushfl\n"
> - "   popl%%eax\n"
> - "   movl%%eax,%%ecx\n"
> - "   xorl$0x20,%%eax\n"
> - "   pushl   %%eax\n"
> - "   popfl\n"
> - "   pushfl\n"
> - "   popl%%eax\n"
> - "   xorl%%eax,%%ecx\n"
> - "   je  1f\n"
> - "   movl$1,%0\n"
> - "   jmp 2f\n"
> - "1: movl$0,%0\n"
> - "2:\n"
> - : "=r" (cpuid_supported) : : "eax", "ecx", "cc");
> - if (cpuid_supported) {
> - __asm __volatile(
> - "   pushl   %%ebx\n"
> - "   cpuid\n"
> - "   movl%%ebx,%1\n"
> - "   popl%%ebx\n"
> - : "=a" (p[0]), "=r" (p[1]), "=c" (p[2]), "=d" (p[3])
> - :  "0" (0x1));
> - lfence_works = (p[3] & CPUID_SSE2) != 0;
> - } else
> - lfence_works = 0;
> - }
> - if (lfence_works == 1)
> - lfence();
> + __asm __volatile(
> + "   pushfl\n"
> + "   popl%%eax\n"
> + "   movl%%eax,%%ecx\n"
> + "   xorl$0x20,%%eax\n"
> + "   pushl   %%eax\n"
> + "   popfl\n"
> + "   pushfl\n"
> + "   popl%%eax\n"
> + "   xorl%%eax,%%ecx\n"
> + "   je  1f\n"
> + "   movl$1,%0\n"
> + "   jmp 2f\n"
> + "1: movl$0,%0\n"
> + "2:\n"
> + : "=r" (cpuid_supported) : : "eax", "ecx", "cc");
> + if (cpuid_supported) {
> + cpuidp(0x1, p);
> + if ((p[3] & CPUID_SSE2) != 0)
> + lfence_works = select_lmb();
> + } else
> + lfence_works = LMB_NONE;
>  #elif defined(__amd64__)
> - lfence();
> + lfence_works = select_lmb();
>  #else
> -#error "arch"
> +#error "Arch"
>  #endif
>  }
>  
> +static void
> +rdtsc_mb(void)
> +{
> +
> +again:
> + if (__predict_true(lfence_works == LMB_LFENCE)) {
> + lfence();
> + return;
> + } else if (lfence_works == LMB_MFENCE) {
> + mfence();
> + return;
> + } else if (lfence_works == LMB_NONE) {
> + return;
> + }
> + init_fence();
> + goto

Re: svn commit: r275890 - in stable/9: contrib/bind9 contrib/bind9/bin/check contrib/bind9/bin/confgen contrib/bind9/bin/dig contrib/bind9/bin/dig/include/dig contrib/bind9/bin/dnssec contrib/bind9/bi

2015-01-01 Thread Andre Albsmeier

On Thu, 18-Dec-2014 at 08:36:21 +, Erwin Lansing wrote:
 Author: erwin
 Date: Thu Dec 18 08:36:19 2014
 New Revision: 275890
 URL: https://svnweb.freebsd.org/changeset/base/275890
 
 Log:
   Update BIND to 9.9.6-P1

This leads to a regression due to a bug in nsupdate. A vendor patch
is available from https://kb.isc.org/article/AA-01220/. It applies
cleanly to 9.3-STABLE and fixes the problem. It would be great if
someone could commit this.

I've CC'ed the maintainer of the port dns/bind99 as it should be
affected as well.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r275890 - in stable/9: contrib/bind9 contrib/bind9/bin/check contrib/bind9/bin/confgen contrib/bind9/bin/dig contrib/bind9/bin/dig/include/dig contrib/bind9/bin/dnssec contrib/bind9/bi

2014-12-19 Thread Andre Albsmeier

On Thu, 18-Dec-2014 at 08:36:21 +, Erwin Lansing wrote:
 Author: erwin
 
 Log:
   Update BIND to 9.9.6-P1
   

I just noticed again that dnssec-importkey does not appear
in usr.sbin/Makefile, is this intentional? If not we should
probably add

SUBDIR+=dnssec-importkey
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r273973 - head/sys/dev/vt

2014-12-04 Thread Andre Albsmeier

On Sun, 02-Nov-2014 at 16:04:49 +, Jean-Sebastien Pedron wrote:
 Author: dumbbell
 Date: Sun Nov  2 16:04:48 2014
 New Revision: 273973
 URL: https://svnweb.freebsd.org/changeset/base/273973
 
 Log:
   vt(4): Fix keyboard allocation when kbdmux(4) isn't used
   
   The problem was that only the kbdmux keyboard index was saved in
   vd-vd_keyboard. This index is -1 when kbdmux isn't used. In this
   case, the keyboard was correctly allocated, but the returned index was
   discarded.
   
   PR: 194718
   MFC after:  1 week

Could someone please MFC this to 9? The patch is slightly
different here but works:

--- sys/dev/vt/vt_core.c.ORI2014-07-22 17:29:27.0 +0200
+++ sys/dev/vt/vt_core.c2014-12-04 17:04:12.0 +0100
@@ -559,7 +559,6 @@
idx0 = kbd_allocate(kbdmux, -1, (void *)vd-vd_keyboard,
vt_kbdevent, vd);
/* XXX: kb_token lost */
-   vd-vd_keyboard = idx0;
if (idx0 != -1) {
DPRINTF(20, %s: kbdmux allocated, idx = %d\n, __func__, idx0);
k0 = kbd_get_keyboard(idx0);
@@ -583,6 +582,7 @@
idx0 = kbd_allocate(*, -1, (void *)vd-vd_keyboard,
vt_kbdevent, vd);
}
+   vd-vd_keyboard = idx0;
DPRINTF(20, %s: vd_keyboard = %d\n, __func__, vd-vd_keyboard);
 
return (idx0);


Thanks,

-Andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r252063 - stable/9/sys/geom/mirror

2013-09-28 Thread Andre Albsmeier

On Fri, 21-Jun-2013 at 19:36:34 +0200, Scott Long wrote:
 Author: scottl
 Date: Fri Jun 21 17:36:33 2013
 New Revision: 252063
 URL: http://svnweb.freebsd.org/changeset/base/252063
 
 Log:
   MFC r252010, r252011:
   
   Mark geom_mirror as capable of unmapped i/o
   
   Obtained from:  Netflix
 ...
 + /* A provider underneath us doesn't support unmapped */
 + if ((dp-flags  G_PF_ACCEPT_UNMAPPED) == 0) {
 + G_MIRROR_DEBUG(0, cancelling unmapped 
 + because of %s\n, dp-name);
 + pp-flags = ~G_PF_ACCEPT_UNMAPPED;
 + }

Is the \n intended here? It produces blank lines in dmesg:
  
...
ada1: SAMSUNG HD321KJ CP100-11 ATA-8 SATA 2.x device
ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada1: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)
Timecounter TSC-low frequency 1099900874 Hz quality 800
GEOM_MIRROR: cancelling unmapped because of ada1
  
GEOM_MIRROR: cancelling unmapped because of ada0
  
GEOM_MIRROR: Device mirror/m0 launched (2/2).
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
...

-Andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r254897 - in stable/9: contrib/bind9 contrib/bind9/bin contrib/bind9/bin/check contrib/bind9/bin/confgen contrib/bind9/bin/dig contrib/bind9/bin/dig/include/dig contrib/bind9/bin/dnsse

2013-08-29 Thread Andre Albsmeier

On Mon, 26-Aug-2013 at 07:17:42 +, Erwin Lansing wrote:
 Author: erwin
 Date: Mon Aug 26 07:17:41 2013
 New Revision: 254897
 URL: http://svnweb.freebsd.org/changeset/base/254897
 
 Log:
   MFC r254651:
   
   Update Bind to 9.9.3-P2

Thanks!

However, when enabling WITH_BIND_SIGCHASE in make.conf I get:

cc -O2 -pipe -DVERSION='9.9.3-P2' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE 
-DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='/var' -DNS_SYSCONFDIR='/etc/namedb' 
-DNAMED_CONFFILE='/etc/namedb/named.conf' 
-DRNDC_CONFFILE='/etc/namedb/rndc.conf' 
-DRNDC_KEYFILE='/etc/namedb/rndc.key' -I/src/src-9/usr.bin/dig/../../lib/bind 
-DDIG_SIGCHASE -I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/bind9/include 
-I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/dns/include/dst  
-I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/dns/include  
-I/src/src-9/usr.bin/dig/../../lib/bind/dns 
-I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/isccc/include 
-I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/isccfg/include 
-I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/isc/unix/include  
-I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/isc/pthreads/include  
-I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/isc/include  
-I/src/src-9/usr.bin/dig/../../lib/bind/isc 
-I/src/src-9/usr.bin/dig/../../contrib/bind
 9/lib/lwres/unix/include  
-I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/lwres/include  
-I/src/src-9/usr.bin/dig/../../lib/bind/lwres 
-I/src/src-9/usr.bin/dig/../../contrib/bind9/bin/dig/include 
-I/src/src-9/usr.bin/dig/../../contrib/bind9/lib/isc/x86_32/include 
-UENABLE_ALTQ -std=gnu99 -fstack-protector -Wsystem-headers -Werror 
-Wno-pointer-sign -c 
/src/src-9/usr.bin/dig/../../contrib/bind9/bin/dig/dighost.c
cc1: warnings being treated as errors
/src/src-9/usr.bin/dig/../../contrib/bind9/bin/dig/dighost.c: In function 
'nameFromString':
/src/src-9/usr.bin/dig/../../contrib/bind9/bin/dig/dighost.c:4336: warning: 
passing argument 2 of 'isc__buffer_init' discards qualifiers from pointer 
target type
*** [dighost.o] Error code 1

How should we deal with this?

Changing the Makefiles of dig, host and nslookup to WARNS?=0
or patching dighost.c in contrib/bind9 directly?

--- dighost.c.ORI   2013-08-27 08:31:49.0 +0200
+++ dighost.c   2013-08-29 09:54:43.0 +0200
@@ -4333,7 +4333,7 @@
REQUIRE(p_ret != NULL);
REQUIRE(str != NULL);
 
-   isc_buffer_init(buffer, str, len);
+   isc_buffer_init(buffer, (char*)str, len);
isc_buffer_add(buffer, len);
 
dns_fixedname_init(fixedname);

Thanks,

-Andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

2013-07-11 Thread Andre Albsmeier

On Fri, 12-Jul-2013 at 00:02:11 +0200, Kenneth D. Merry wrote:
 On Thu, Jul 11, 2013 at 14:53:32 -0600, Kenneth D. Merry wrote:
  On Wed, Jul 10, 2013 at 20:58:33 +0200, Andre Albsmeier wrote:
   On Wed, 10-Jul-2013 at 20:49:15 +0200, Kenneth D. Merry wrote:
On Wed, Jul 03, 2013 at 07:43:49 +0200, Andre Albsmeier wrote:
 On Wed, 03-Jul-2013 at 07:22:36 +0200, Kenneth D. Merry wrote:
  On Tue, Jul 02, 2013 at 07:53:33 +0200, Andre Albsmeier wrote:
   On Tue, 25-Jun-2013 at 23:43:50 +0200, Kenneth D. Merry wrote:
Author: ken
Date: Tue Jun 25 21:43:49 2013
New Revision: 252214
URL: http://svnweb.freebsd.org/changeset/base/252214
   
   Hi Ken,
   
Log:
  MFC: 249658, 249701

  Update chio(1) and ch(4) to support reporting element 
designators.

  This allows mapping a tape drive in a changer (as reported by
  'chio status') to a sa(4) driver instance by comparing the
  serial numbers.

  The designators can be ASCII (which is printed out directly), 
binary
  (which is printed in hex format) or UTF-8, which is printed 
in either
  native UTF-8 format if the terminal can support it, or in %XX 
notation
  for non-ASCII characters.  Thanks to Hiroki Sato hrs@ for 
the
  explanation and example UTF-8 printing code.

  chio.h:   Modify the changer_element_status 
structure to add new
fields and definitions from the SMC3r16 spec.

Rename the original CHIOGSTATUS ioctl to 
OCHIOGTATUS and
define a new CHIOGSTATUS ioctl.

Clean up some tab/space issues.

  chio.c:   For the 'status' subcommand, print the 
designator field
if it is supplied by a device.

  scsi_ch.h:Add new flags for DVCID and CURDATA to the READ
ELEMENT STATUS command structure.

Add a read_element_status_device_id structure
for the data fields in the new standard. Add new
unions, dt_or_obsolete and voltage_devid, to 
hold
and address data from either SCSI-2 or newer 
devices.

  scsi_ch.c:Implement support for fetching device IDs with 
READ
ELEMENT STATUS data.

Add new arguments to scsi_read_element_status() 
to
allow the user to request the DVCID and CURDATA 
bits.
   
   This broke chio status when talking to my QUALSTAR TLS-8211 
   library:
   
   Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): READ 
   ELEMENT STATUS. CDB: b8 10 fd e8 00 01 03 00 04 00 00 00
   Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): CAM 
   status: SCSI Status Error
   Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI 
   status: Check Condition
   Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI 
   sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
   Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): 
   Command byte 6 is invalid
   Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): 
   Error 22, Unretryable error
   
   scsi_cmd-flags (Byte 6) must be zero for this library so I had 
   to use
   this workaround to make it work again until a better solution is 
   available:
   
   --- sys/cam/scsi/scsi_ch.c.ORI2013-06-26 13:38:54.0 
   +0200
   +++ sys/cam/scsi/scsi_ch.c2013-07-02 07:42:24.0 
   +0200
   @@ -1245,8 +1245,8 @@
  /* tag_action */ MSG_SIMPLE_Q_TAG,
  /* voltag */ want_voltags,
  /* sea */ softc-sc_firsts[chet],
   -  /* dvcid */ 1,
   -  /* curdata */ 1,
   +  /* dvcid */ 0,
   +  /* curdata */ 0,
  /* count */ 1,
  /* data_ptr */ data,
  /* dxfer_len */ 1024,
   @@ -1284,8 +1284,8 @@
  /* voltag */ want_voltags,
  /* sea */ softc-sc_firsts[chet]
  + cesr-cesr_element_base,
   -  /* dvcid */ 1,
   -  /* curdata */ 1,
   +  /* dvcid */ 0,
   +  /* curdata */ 0,
  /* count */ cesr-cesr_element_count

Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

2013-07-10 Thread Andre Albsmeier

On Wed, 10-Jul-2013 at 20:49:15 +0200, Kenneth D. Merry wrote:
 On Wed, Jul 03, 2013 at 07:43:49 +0200, Andre Albsmeier wrote:
  On Wed, 03-Jul-2013 at 07:22:36 +0200, Kenneth D. Merry wrote:
   On Tue, Jul 02, 2013 at 07:53:33 +0200, Andre Albsmeier wrote:
On Tue, 25-Jun-2013 at 23:43:50 +0200, Kenneth D. Merry wrote:
 Author: ken
 Date: Tue Jun 25 21:43:49 2013
 New Revision: 252214
 URL: http://svnweb.freebsd.org/changeset/base/252214

Hi Ken,

 Log:
   MFC: 249658, 249701
 
   Update chio(1) and ch(4) to support reporting element designators.
 
   This allows mapping a tape drive in a changer (as reported by
   'chio status') to a sa(4) driver instance by comparing the
   serial numbers.
 
   The designators can be ASCII (which is printed out directly), binary
   (which is printed in hex format) or UTF-8, which is printed in 
 either
   native UTF-8 format if the terminal can support it, or in %XX 
 notation
   for non-ASCII characters.  Thanks to Hiroki Sato hrs@ for the
   explanation and example UTF-8 printing code.
 
   chio.h:   Modify the changer_element_status structure 
 to add new
 fields and definitions from the SMC3r16 spec.
 
 Rename the original CHIOGSTATUS ioctl to OCHIOGTATUS 
 and
 define a new CHIOGSTATUS ioctl.
 
 Clean up some tab/space issues.
 
   chio.c:   For the 'status' subcommand, print the designator 
 field
 if it is supplied by a device.
 
   scsi_ch.h:Add new flags for DVCID and CURDATA to the READ
 ELEMENT STATUS command structure.
 
 Add a read_element_status_device_id structure
 for the data fields in the new standard. Add new
 unions, dt_or_obsolete and voltage_devid, to hold
 and address data from either SCSI-2 or newer devices.
 
   scsi_ch.c:Implement support for fetching device IDs with READ
 ELEMENT STATUS data.
 
 Add new arguments to scsi_read_element_status() to
 allow the user to request the DVCID and CURDATA bits.

This broke chio status when talking to my QUALSTAR TLS-8211 library:

Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): READ 
ELEMENT STATUS. CDB: b8 10 fd e8 00 01 03 00 04 00 00 00
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): CAM 
status: SCSI Status Error
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI 
status: Check Condition
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI 
sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Command 
byte 6 is invalid
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Error 22, 
Unretryable error

scsi_cmd-flags (Byte 6) must be zero for this library so I had to use
this workaround to make it work again until a better solution is 
available:

--- sys/cam/scsi/scsi_ch.c.ORI  2013-06-26 13:38:54.0 +0200
+++ sys/cam/scsi/scsi_ch.c  2013-07-02 07:42:24.0 +0200
@@ -1245,8 +1245,8 @@
 /* tag_action */ MSG_SIMPLE_Q_TAG,
 /* voltag */ want_voltags,
 /* sea */ softc-sc_firsts[chet],
-/* dvcid */ 1,
-/* curdata */ 1,
+/* dvcid */ 0,
+/* curdata */ 0,
 /* count */ 1,
 /* data_ptr */ data,
 /* dxfer_len */ 1024,
@@ -1284,8 +1284,8 @@
 /* voltag */ want_voltags,
 /* sea */ softc-sc_firsts[chet]
 + cesr-cesr_element_base,
-/* dvcid */ 1,
-/* curdata */ 1,
+/* dvcid */ 0,
+/* curdata */ 0,
 /* count */ cesr-cesr_element_count,
 /* data_ptr */ data,
 /* dxfer_len */ size,

-Andre
   
   Oops, sorry.
   
   We need to check the SCSI version to see whether to set those bits, and
   also fall back in case it doesn't work.
   
   I am on vacation and have very spotty net access.  I can't do anything
   about it until I get back next week.
   
   Justin and Alan (CCed) can work on the fix, though.
  
  Take your time, for me it's working

Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

2013-07-02 Thread Andre Albsmeier

On Wed, 03-Jul-2013 at 07:22:36 +0200, Kenneth D. Merry wrote:
 On Tue, Jul 02, 2013 at 07:53:33 +0200, Andre Albsmeier wrote:
  On Tue, 25-Jun-2013 at 23:43:50 +0200, Kenneth D. Merry wrote:
   Author: ken
   Date: Tue Jun 25 21:43:49 2013
   New Revision: 252214
   URL: http://svnweb.freebsd.org/changeset/base/252214
  
  Hi Ken,
  
   Log:
 MFC: 249658, 249701
   
 Update chio(1) and ch(4) to support reporting element designators.
   
 This allows mapping a tape drive in a changer (as reported by
 'chio status') to a sa(4) driver instance by comparing the
 serial numbers.
   
 The designators can be ASCII (which is printed out directly), binary
 (which is printed in hex format) or UTF-8, which is printed in either
 native UTF-8 format if the terminal can support it, or in %XX notation
 for non-ASCII characters.  Thanks to Hiroki Sato hrs@ for the
 explanation and example UTF-8 printing code.
   
 chio.h:   Modify the changer_element_status structure to 
   add new
   fields and definitions from the SMC3r16 spec.
   
   Rename the original CHIOGSTATUS ioctl to OCHIOGTATUS and
   define a new CHIOGSTATUS ioctl.
   
   Clean up some tab/space issues.
   
 chio.c:   For the 'status' subcommand, print the designator field
   if it is supplied by a device.
   
 scsi_ch.h:Add new flags for DVCID and CURDATA to the READ
   ELEMENT STATUS command structure.
   
   Add a read_element_status_device_id structure
   for the data fields in the new standard. Add new
   unions, dt_or_obsolete and voltage_devid, to hold
   and address data from either SCSI-2 or newer devices.
   
 scsi_ch.c:Implement support for fetching device IDs with READ
   ELEMENT STATUS data.
   
   Add new arguments to scsi_read_element_status() to
   allow the user to request the DVCID and CURDATA bits.
  
  This broke chio status when talking to my QUALSTAR TLS-8211 library:
  
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): READ ELEMENT 
  STATUS. CDB: b8 10 fd e8 00 01 03 00 04 00 00 00
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): CAM status: 
  SCSI Status Error
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI status: 
  Check Condition
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI sense: 
  ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Command byte 6 
  is invalid
  Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Error 22, 
  Unretryable error
  
  scsi_cmd-flags (Byte 6) must be zero for this library so I had to use
  this workaround to make it work again until a better solution is available:
  
  --- sys/cam/scsi/scsi_ch.c.ORI  2013-06-26 13:38:54.0 +0200
  +++ sys/cam/scsi/scsi_ch.c  2013-07-02 07:42:24.0 +0200
  @@ -1245,8 +1245,8 @@
   /* tag_action */ MSG_SIMPLE_Q_TAG,
   /* voltag */ want_voltags,
   /* sea */ softc-sc_firsts[chet],
  -/* dvcid */ 1,
  -/* curdata */ 1,
  +/* dvcid */ 0,
  +/* curdata */ 0,
   /* count */ 1,
   /* data_ptr */ data,
   /* dxfer_len */ 1024,
  @@ -1284,8 +1284,8 @@
   /* voltag */ want_voltags,
   /* sea */ softc-sc_firsts[chet]
   + cesr-cesr_element_base,
  -/* dvcid */ 1,
  -/* curdata */ 1,
  +/* dvcid */ 0,
  +/* curdata */ 0,
   /* count */ cesr-cesr_element_count,
   /* data_ptr */ data,
   /* dxfer_len */ size,
  
  -Andre
 
 Oops, sorry.
 
 We need to check the SCSI version to see whether to set those bits, and
 also fall back in case it doesn't work.
 
 I am on vacation and have very spotty net access.  I can't do anything
 about it until I get back next week.
 
 Justin and Alan (CCed) can work on the fix, though.

Take your time, for me it's working right now
with the above patch...

-Andre

 
 Ken
 -- 
 Kenneth Merry
 k...@freebsd.org
 

-- 
Linux: Sozialismus, der nicht funktioniert
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

2013-07-01 Thread Andre Albsmeier

On Tue, 25-Jun-2013 at 23:43:50 +0200, Kenneth D. Merry wrote:
 Author: ken
 Date: Tue Jun 25 21:43:49 2013
 New Revision: 252214
 URL: http://svnweb.freebsd.org/changeset/base/252214

Hi Ken,

 Log:
   MFC: 249658, 249701
 
   Update chio(1) and ch(4) to support reporting element designators.
 
   This allows mapping a tape drive in a changer (as reported by
   'chio status') to a sa(4) driver instance by comparing the
   serial numbers.
 
   The designators can be ASCII (which is printed out directly), binary
   (which is printed in hex format) or UTF-8, which is printed in either
   native UTF-8 format if the terminal can support it, or in %XX notation
   for non-ASCII characters.  Thanks to Hiroki Sato hrs@ for the
   explanation and example UTF-8 printing code.
 
   chio.h:   Modify the changer_element_status structure to add new
 fields and definitions from the SMC3r16 spec.
 
 Rename the original CHIOGSTATUS ioctl to OCHIOGTATUS and
 define a new CHIOGSTATUS ioctl.
 
 Clean up some tab/space issues.
 
   chio.c:   For the 'status' subcommand, print the designator field
 if it is supplied by a device.
 
   scsi_ch.h:Add new flags for DVCID and CURDATA to the READ
 ELEMENT STATUS command structure.
 
 Add a read_element_status_device_id structure
 for the data fields in the new standard. Add new
 unions, dt_or_obsolete and voltage_devid, to hold
 and address data from either SCSI-2 or newer devices.
 
   scsi_ch.c:Implement support for fetching device IDs with READ
 ELEMENT STATUS data.
 
 Add new arguments to scsi_read_element_status() to
 allow the user to request the DVCID and CURDATA bits.

This broke chio status when talking to my QUALSTAR TLS-8211 library:

Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): READ ELEMENT 
STATUS. CDB: b8 10 fd e8 00 01 03 00 04 00 00 00
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): CAM status: SCSI 
Status Error
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI status: Check 
Condition
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): SCSI sense: 
ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Command byte 6 is 
invalid
Jul  2 07:08:22 kern.crit server kernel: (ch0:ahd3:0:1:0): Error 22, 
Unretryable error

scsi_cmd-flags (Byte 6) must be zero for this library so I had to use
this workaround to make it work again until a better solution is available:

--- sys/cam/scsi/scsi_ch.c.ORI  2013-06-26 13:38:54.0 +0200
+++ sys/cam/scsi/scsi_ch.c  2013-07-02 07:42:24.0 +0200
@@ -1245,8 +1245,8 @@
 /* tag_action */ MSG_SIMPLE_Q_TAG,
 /* voltag */ want_voltags,
 /* sea */ softc-sc_firsts[chet],
-/* dvcid */ 1,
-/* curdata */ 1,
+/* dvcid */ 0,
+/* curdata */ 0,
 /* count */ 1,
 /* data_ptr */ data,
 /* dxfer_len */ 1024,
@@ -1284,8 +1284,8 @@
 /* voltag */ want_voltags,
 /* sea */ softc-sc_firsts[chet]
 + cesr-cesr_element_base,
-/* dvcid */ 1,
-/* curdata */ 1,
+/* dvcid */ 0,
+/* curdata */ 0,
 /* count */ cesr-cesr_element_count,
 /* data_ptr */ data,
 /* dxfer_len */ size,

-Andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r227961 - head/sbin/camcontrol

2011-12-02 Thread Andre Albsmeier

On Fri, 25-Nov-2011 at 05:03:37 +0100, Ed Maste wrote:
 Author: emaste
 Date: Fri Nov 25 04:03:37 2011
 New Revision: 227961
 URL: http://svn.freebsd.org/changeset/base/227961
 
 Log:
   Add firmware update support for SCSI devices.
 
 ...
 
 Added: head/sbin/camcontrol/fwdownload.c
 ==
 --- /dev/null   00:00:00 1970   (empty, because file is newly added)
 +++ head/sbin/camcontrol/fwdownload.c   Fri Nov 25 04:03:37 2011
 (r227961)
 @@ -0,0 +1,380 @@
 +/*-
 + * Copyright (c) 2011 Sandvine Incorporated. All rights reserved.
 + * Copyright (c) 2002-2011 Andre Albsmeier an...@albsmeier.net
 + * All rights reserved.
 + *

We should not forget Marc Frajola who sent me his ddys.c for
updating IBM DDYS drives ages ago. He allowed me to use his
code but wanted to be credited -- I think we should continue
to honour his wish. His file contained the following note:

 * TeraSolutions IBM drive firmware update utility
 *
 * (C) Copyright 2000, TeraSolutions, Inc.  All Rights Reserved.
 *   This software contains proprietary trade secrets of
 *   TeraSolutions, Inc.  Redistribution without prior written
 *   consent is prohibited.
 *
 * By Marc Frajola, 08/15/2000

and in fwprog.c I had him mentioned this way:

 * ...
 *  Many thanks goes to Marc Frajola m...@terasolutions.com from
 *  TeraSolutions for the initial idea and his programme for upgrading
 *  the firmware of I*M DDYS drives ...
 * ...

I think you guys find something that is appropriate...

Thanks,

-Andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r218277 - in stable/7/sys: kern sys

2011-04-15 Thread Andre Albsmeier

On Fri, 04-Feb-2011 at 14:44:59 +, John Baldwin wrote:
 Author: jhb
 Date: Fri Feb  4 14:44:59 2011
 New Revision: 218277
 URL: http://svn.freebsd.org/changeset/base/218277
 
 Log:
   MFC 217075:
   Retire PCONFIG and leave the priority of thread0 alone when waiting for
   interrupt config hooks to execute.
   
   To preserve the KBI, I did not renumber priorities but simply removed
   PCONFIG.
 
 Modified:
   stable/7/sys/kern/subr_autoconf.c
   stable/7/sys/sys/priority.h
 Directory Properties:
   stable/7/sys/   (props changed)
   stable/7/sys/cddl/contrib/opensolaris/   (props changed)
   stable/7/sys/contrib/dev/acpica/   (props changed)
   stable/7/sys/contrib/pf/   (props changed)
 
 Modified: stable/7/sys/kern/subr_autoconf.c
 ==
 --- stable/7/sys/kern/subr_autoconf.c Fri Feb  4 14:44:42 2011
 (r218276)
 +++ stable/7/sys/kern/subr_autoconf.c Fri Feb  4 14:44:59 2011
 (r218277)
 @@ -108,7 +108,7 @@ run_interrupt_driven_config_hooks(dummy)
   warned = 0;
   while (!TAILQ_EMPTY(intr_config_hook_list)) {
   if (msleep(intr_config_hook_list, intr_config_hook_lock,
 - PCONFIG, conifhk, WARNING_INTERVAL_SECS * hz) ==
 + 0, conifhk, WARNING_INTERVAL_SECS * hz) ==
   EWOULDBLOCK) {
   mtx_unlock(intr_config_hook_lock);
   warned++;


This broke several of my machines in a somewhat strange way:

After upgrading them (17) to a recent 7-STABLE (as of 2011-04-12)
I noticed that some (4) of them didn't start. All 4 didn't find
their boot device anymore. What they all got in common is:

- an Adaptec 2940 Ultra SCSI adapter
- two SCSI harddisks (da0 and da1) of various brands
- one SCSI CDROM drive (cd0)

To be exact, none of the three devices (da0, da1, cd0) were
detected at all. Other machines with a similar configuration
(2940 and da0/da1) but _without_ the CDROM drive didn't have
any problems. So I simply removed the CDROM drives on the 4
machines in question and they all booted again.

Today I decided to dig into this and after reverting(*) the
above change, they worked with the CDROM again. I have cross-
checked it 3 times. No idea what's happening here...

-Andre

(*) To be honest, I use this patch so I had to modify only one file:

--- sys/kern/subr_autoconf.c.ORI2011-02-05 13:14:11.0 +0100
+++ sys/kern/subr_autoconf.c2011-04-15 14:34:31.0 +0200
@@ -108,7 +108,7 @@
warned = 0;
while (!TAILQ_EMPTY(intr_config_hook_list)) {
if (msleep(intr_config_hook_list, intr_config_hook_lock,
-   0, conifhk, WARNING_INTERVAL_SECS * hz) ==
+   PRI_MIN_KERN + 32, conifhk, WARNING_INTERVAL_SECS * hz) ==
EWOULDBLOCK) {
mtx_unlock(intr_config_hook_lock);
warned++;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r218277 - in stable/7/sys: kern sys

2011-04-15 Thread Andre Albsmeier

On Fri, 15-Apr-2011 at 18:35:05 +0200, John Baldwin wrote:
 On Friday, April 15, 2011 9:25:25 am Andre Albsmeier wrote:
  On Fri, 04-Feb-2011 at 14:44:59 +, John Baldwin wrote:
   Author: jhb
   Date: Fri Feb  4 14:44:59 2011
   New Revision: 218277
   URL: http://svn.freebsd.org/changeset/base/218277
   
   Log:
 MFC 217075:
 Retire PCONFIG and leave the priority of thread0 alone when waiting for
 interrupt config hooks to execute.
 
 To preserve the KBI, I did not renumber priorities but simply removed
 PCONFIG.
   
   Modified:
 stable/7/sys/kern/subr_autoconf.c
 stable/7/sys/sys/priority.h
   Directory Properties:
 stable/7/sys/   (props changed)
 stable/7/sys/cddl/contrib/opensolaris/   (props changed)
 stable/7/sys/contrib/dev/acpica/   (props changed)
 stable/7/sys/contrib/pf/   (props changed)
   
   Modified: stable/7/sys/kern/subr_autoconf.c
   
 ==
   --- stable/7/sys/kern/subr_autoconf.c Fri Feb  4 14:44:42 2011
 (r218276)
   +++ stable/7/sys/kern/subr_autoconf.c Fri Feb  4 14:44:59 2011
 (r218277)
   @@ -108,7 +108,7 @@ run_interrupt_driven_config_hooks(dummy)
 warned = 0;
 while (!TAILQ_EMPTY(intr_config_hook_list)) {
 if (msleep(intr_config_hook_list, intr_config_hook_lock,
   - PCONFIG, conifhk, WARNING_INTERVAL_SECS * hz) ==
   + 0, conifhk, WARNING_INTERVAL_SECS * hz) ==
 EWOULDBLOCK) {
 mtx_unlock(intr_config_hook_lock);
 warned++;
  
  
  This broke several of my machines in a somewhat strange way:
  
  After upgrading them (17) to a recent 7-STABLE (as of 2011-04-12)
  I noticed that some (4) of them didn't start. All 4 didn't find
  their boot device anymore. What they all got in common is:
  
  - an Adaptec 2940 Ultra SCSI adapter
  - two SCSI harddisks (da0 and da1) of various brands
  - one SCSI CDROM drive (cd0)
  
  To be exact, none of the three devices (da0, da1, cd0) were
  detected at all. Other machines with a similar configuration
  (2940 and da0/da1) but _without_ the CDROM drive didn't have
  any problems. So I simply removed the CDROM drives on the 4
  machines in question and they all booted again.
  
  Today I decided to dig into this and after reverting(*) the
  above change, they worked with the CDROM again. I have cross-
  checked it 3 times. No idea what's happening here...
  
  -Andre
  
  (*) To be honest, I use this patch so I had to modify only one file:
  
  --- sys/kern/subr_autoconf.c.ORI2011-02-05 13:14:11.0 +0100
  +++ sys/kern/subr_autoconf.c2011-04-15 14:34:31.0 +0200
  @@ -108,7 +108,7 @@
  warned = 0;
  while (!TAILQ_EMPTY(intr_config_hook_list)) {
  if (msleep(intr_config_hook_list, intr_config_hook_lock,
  -   0, conifhk, WARNING_INTERVAL_SECS * hz) ==
  +   PRI_MIN_KERN + 32, conifhk, WARNING_INTERVAL_SECS * hz) ==
  EWOULDBLOCK) {
  mtx_unlock(intr_config_hook_lock);
  warned++;
 
 Do you get any warnings about CAM timeouts, etc. when these probe?  A verbose 

This is a part of a verbose dmesg with a working(!) kernel:

Apr 15 12:44:33 kern.crit inside kernel: splash: image decoder found: 
snake_saver
Apr 15 12:44:33 kern.crit inside kernel: lo0: bpf attached
Apr 15 12:44:33 kern.crit inside kernel: (noperiph:ahc0:0:-1:-1): SCSI bus 
reset delivered. 0 SCBs aborted.
Apr 15 12:44:33 kern.crit inside kernel: ahc0: Selection Timeout on A:5. 0 
SCBs aborted
Apr 15 12:44:33 kern.crit inside kernel: ahc0: Selection Timeout on A:2. 0 
SCBs aborted
Apr 15 12:44:33 kern.crit inside kernel: ahc0: Selection Timeout on A:3. 0 
SCBs aborted
Apr 15 12:44:33 kern.crit inside kernel: ahc0: Selection Timeout on A:4. 0 
SCBs aborted
Apr 15 12:44:33 kern.crit inside kernel: (probe0:ahc0:0:0:0): Retrying Command
Apr 15 12:44:33 kern.crit inside kernel: (probe1:ahc0:0:1:0): Retrying Command
Apr 15 12:44:33 kern.crit inside kernel: (probe6:ahc0:0:6:0): Retrying Command
Apr 15 12:44:33 kern.crit inside kernel: (probe6:ahc0:0:6:0): error 22
Apr 15 12:44:33 kern.crit inside kernel: (probe6:ahc0:0:6:0): Unretryable 
Error
Apr 15 12:44:33 kern.crit inside kernel: (probe6:ahc0:0:6:0): Down reving 
Protocol Version from 4 to 2?
Apr 15 12:44:33 kern.crit inside kernel: (probe0:ahc0:0:0:0): Down reving 
Protocol Version from 4 to 2?
Apr 15 12:44:33 kern.crit inside kernel: (probe1:ahc0:0:1:0): Down reving 
Protocol Version from 4 to 2?
Apr 15 12:44:33 kern.crit inside kernel: (ahc0:A:6:0): Sending SDTR period c, 
offset f
Apr 15 12:44:33 kern.crit inside kernel: (ahc0:A:6:0): Received SDTR period 
19, offset f
Apr 15 12:44:33 kern.crit inside kernel: Filtered to period 19, offset f
Apr 15 12:44:33 kern.crit inside kernel: ahc0: target 6 synchronous at 
10.0MHz, offset = 0xf
Apr 15 12:44:33 kern.crit

Re: svn commit: r205614 - stable/7/sys/dev/msk

2010-04-07 Thread Andre Albsmeier

On Wed, 07-Apr-2010 at 19:04:04 +0200, Pyun YongHyeon wrote:
 On Wed, Apr 07, 2010 at 07:34:17AM +0200, Andre Albsmeier wrote:
  On Tue, 06-Apr-2010 at 22:29:49 +0200, Pyun YongHyeon wrote:
   On Tue, Apr 06, 2010 at 09:59:36PM +0200, Andre Albsmeier wrote:
On Tue, 06-Apr-2010 at 20:44:56 +0200, Pyun YongHyeon wrote:
 On Tue, Apr 06, 2010 at 08:00:27PM +0200, Andre Albsmeier wrote:
  On Tue, 06-Apr-2010 at 15:46:26 +0200, Andre Albsmeier wrote:
   On Mon, 05-Apr-2010 at 20:06:42 +0200, Pyun YongHyeon wrote:
 
 [...]
 
As you know 1.18.2.38 removed taskqueue based interrupt 
handling so
it could be culprit of the issue. But that revision also removed
two register accesses in TX path so I'd like to know which one
caused the issue. 
   
   I have now tried rev. 1.18.2.38 with this patch (no idea if
   this is right ;-)):
   
   --- if_msk.c.1.18.2.382010-04-06 15:09:19.0 +0200
   +++ if_msk.c.1.18.2.38.TRY2010-04-06 15:38:13.0 
   +0200
   @@ -3327,6 +3327,11 @@
 uint32_t control, status;
 int cons, len, port, rxprog;

   + int idx;
   + idx = CSR_READ_2(sc, STAT_PUT_IDX);
   + if (idx == sc-msk_stat_cons)
   + return (0);
   +
 /* Sync status LEs. */
 bus_dmamap_sync(sc-msk_stat_tag, sc-msk_stat_map,
 BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE);
   @@ -3407,7 +3412,7 @@
 if (rxput[MSK_PORT_B]  0)
 msk_rxput(sc-msk_if[MSK_PORT_B]);

   - return (rxprog  sc-msk_process_limit ? EAGAIN : 0);
   + return (sc-msk_stat_cons != CSR_READ_2(sc, STAT_PUT_IDX));
}

static void
   
   Now performance seems to be the same as with the older
   driver (at least here at work) and in both directions!
   Some numbers:
   
   em0 writes to rev. 1.18.2.36: 20 
   seconds
   em0 writes to rev. 1.18.2.38: 50 
   seconds
   em0 writes to rev. 1.18.2.38 with patch from above:   23 
   seconds
   same as before but with int_holdoff: 100 - 1:20 
   seconds
   
   rev. 1.18.2.36 writes to em0: 22 
   seconds
   rev. 1.18.2.38 writes to em0: 40 
   seconds
   rev. 1.18.2.38 with patch from above writes to em0:   21 
   seconds
   same as before but with int_holdoff: 100 - 1:20 
   seconds
   
   It seems that these two CSR_READ_2s really help ;-).
   
   As I said, this is at work and with slightly different machines.
   I will try things at home later but I am rather confident of
   receiving good results there as well...
  
  OK, tests at home show similar good results with the
  above patch. When setting int_holdoff to 3, performance
  seems equal to the older versions.
  
 
 Thanks a lot for narrowing down the issue.
 Because the msk_handle_events() are called in interrupt handler
 I'd like to remove the two register accesses in fast path. It seems
 accessing STAT_PUT_IDX triggers status updates. Would you try
 attached patch and let me know whether the patch makes any
 difference?

 Index: sys/dev/msk/if_msk.c
 ===
 --- sys/dev/msk/if_msk.c  (revision 206204)
 +++ sys/dev/msk/if_msk.c  (working copy)
 @@ -1470,6 +1470,7 @@
   /* WA for dev. #4.18 */
   CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21);
   CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07);
 + CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 10));
   } else {
   CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
   CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
 @@ -1481,9 +1482,16 @@
   CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190);
   }
   /*
 -  * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI.
 +  * STAT_TX_TIMER_INI, STAT_ISR_TIMER_INI and STAT_LEV_TIMER_INI
 +  * as well as various water mark registers seem to control when
 +  * controller initiates status LE update.
 +  * It's not clear how these registers interact with interrupt
 +  * state but STAT_TX_TIMER_INI seems to control status update
 +  * time after crossing a threshold(STAT_TX_IDX_TH) value. Due to
 +  * the complexity of various parameters that may affect status
 +  * update just use hardware default until we know better
 +  * the internal things of status updates.
*/
 - CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000));
  
   /* Enable status unit. */
   CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON

Re: svn commit: r205614 - stable/7/sys/dev/msk

2010-04-06 Thread Andre Albsmeier

On Tue, 06-Apr-2010 at 22:29:49 +0200, Pyun YongHyeon wrote:
 On Tue, Apr 06, 2010 at 09:59:36PM +0200, Andre Albsmeier wrote:
  On Tue, 06-Apr-2010 at 20:44:56 +0200, Pyun YongHyeon wrote:
   On Tue, Apr 06, 2010 at 08:00:27PM +0200, Andre Albsmeier wrote:
On Tue, 06-Apr-2010 at 15:46:26 +0200, Andre Albsmeier wrote:
 On Mon, 05-Apr-2010 at 20:06:42 +0200, Pyun YongHyeon wrote:
   
   [...]
   
  As you know 1.18.2.38 removed taskqueue based interrupt handling so
  it could be culprit of the issue. But that revision also removed
  two register accesses in TX path so I'd like to know which one
  caused the issue. 
 
 I have now tried rev. 1.18.2.38 with this patch (no idea if
 this is right ;-)):
 
 --- if_msk.c.1.18.2.382010-04-06 15:09:19.0 +0200
 +++ if_msk.c.1.18.2.38.TRY2010-04-06 15:38:13.0 +0200
 @@ -3327,6 +3327,11 @@
   uint32_t control, status;
   int cons, len, port, rxprog;
  
 + int idx;
 + idx = CSR_READ_2(sc, STAT_PUT_IDX);
 + if (idx == sc-msk_stat_cons)
 + return (0);
 +
   /* Sync status LEs. */
   bus_dmamap_sync(sc-msk_stat_tag, sc-msk_stat_map,
   BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE);
 @@ -3407,7 +3412,7 @@
   if (rxput[MSK_PORT_B]  0)
   msk_rxput(sc-msk_if[MSK_PORT_B]);
  
 - return (rxprog  sc-msk_process_limit ? EAGAIN : 0);
 + return (sc-msk_stat_cons != CSR_READ_2(sc, STAT_PUT_IDX));
  }
  
  static void
 
 Now performance seems to be the same as with the older
 driver (at least here at work) and in both directions!
 Some numbers:
 
 em0 writes to rev. 1.18.2.36: 20 seconds
 em0 writes to rev. 1.18.2.38: 50 seconds
 em0 writes to rev. 1.18.2.38 with patch from above:   23 seconds
 same as before but with int_holdoff: 100 - 1:20 
 seconds
 
 rev. 1.18.2.36 writes to em0: 22 seconds
 rev. 1.18.2.38 writes to em0: 40 seconds
 rev. 1.18.2.38 with patch from above writes to em0:   21 seconds
 same as before but with int_holdoff: 100 - 1:20 
 seconds
 
 It seems that these two CSR_READ_2s really help ;-).
 
 As I said, this is at work and with slightly different machines.
 I will try things at home later but I am rather confident of
 receiving good results there as well...

OK, tests at home show similar good results with the
above patch. When setting int_holdoff to 3, performance
seems equal to the older versions.

   
   Thanks a lot for narrowing down the issue.
   Because the msk_handle_events() are called in interrupt handler
   I'd like to remove the two register accesses in fast path. It seems
   accessing STAT_PUT_IDX triggers status updates. Would you try
   attached patch and let me know whether the patch makes any
   difference?
  
   Index: sys/dev/msk/if_msk.c
   ===
   --- sys/dev/msk/if_msk.c  (revision 206204)
   +++ sys/dev/msk/if_msk.c  (working copy)
   @@ -1470,6 +1470,7 @@
 /* WA for dev. #4.18 */
 CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21);
 CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07);
   + CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 10));
 } else {
 CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
 CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
   @@ -1481,9 +1482,16 @@
 CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190);
 }
 /*
   -  * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI.
   +  * STAT_TX_TIMER_INI, STAT_ISR_TIMER_INI and STAT_LEV_TIMER_INI
   +  * as well as various water mark registers seem to control when
   +  * controller initiates status LE update.
   +  * It's not clear how these registers interact with interrupt
   +  * state but STAT_TX_TIMER_INI seems to control status update
   +  * time after crossing a threshold(STAT_TX_IDX_TH) value. Due to
   +  * the complexity of various parameters that may affect status
   +  * update just use hardware default until we know better
   +  * the internal things of status updates.
  */
   - CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000));

 /* Enable status unit. */
 CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON);
  
  After applying this patch against an original 1.18.2.39
  things became even worse. After 4 minutes of waiting I
  aborted untar'ing the file ;-). Setting int_holdoff=2
  made things better, now it took 65 seconds for untar'ing...
  
 
 :-(
 
 By chance, did you disable MSI(msi_disable=1)?

Yes. Do you want me to test again with MSI enabled?

-Andre

-- 
Regression testing? What's that? If it compiles,
it is good, if it boots up, it is perfect

Re: svn commit: r205614 - stable/7/sys/dev/msk

2010-04-06 Thread Andre Albsmeier

On Mon, 05-Apr-2010 at 20:06:42 +0200, Pyun YongHyeon wrote:
 On Mon, Apr 05, 2010 at 04:59:37PM +0200, Andre Albsmeier wrote:
  On Wed, 24-Mar-2010 at 18:21:05 +0100, Pyun YongHyeon wrote:
   Author: yongari
   Date: Wed Mar 24 17:21:05 2010
   New Revision: 205614
   URL: http://svn.freebsd.org/changeset/base/205614
   
   Log:
 MFC r204545:
   Remove taskqueue based interrupt handling. After r204541 msk(4)
   does not generate excessive interrupts any more so we don't need
   to have two copies of interrupt handler.
   While I'm here remove two STAT_PUT_IDX register accesses in LE
   status event handler. After r204539 msk(4) always sync status LEs
   so there is no need to resort to reading STAT_PUT_IDX register to
   know the end of status LE processing. Just trust status LE's
   ownership bit.
  
  This ruined the performance on my system heavily. I noticed it
  when unpacking a local tar archive onto an NFS-mounted location
  on an em(4)-based box. This archive is about 50MB of size with
  a bit over 5600 files so files have an average size of 9 kB.
  
  I also noticed the slowdown when doing rdist-based updates (again
  lots of small files) onto the other box.
  
  Just pumping bytes over the network shows no problems -- I can
  transmit 100-105 MB/s and receive 95-100 MB/s when talking
  to this em(4)-based box without problem (and as it was before).
  
  When copying a few big files (several GBs of size) over NFS
  I get something between 70 and 90 MB/s which is the same as
  what I had got before.
  
  If have made some tests to track down when the issues began.
  Problems started with rev. 1.18.2.37 of if_msk.c but could
  be alleviated by setting dev.mskc.0.int_holdoff to 1 or 0.
  Things really got problematic with rev. 1.18.2.38 -- adjusting
  dev.mskc.0.int_holdoff helped a lot but we are far from what
  we had with 1.18.2.36 or earlier. I did 5 rounds of testing,
  each with the same set of if_msk.c revisions and values for
  int_holdoff (where appropriate) just to check reproducibility:
  
  if_msk.c rev.   round1  round2  round3  round4  round5
  
  1.18.2.34   17,115  18,408  17,977  16,412  19,170
  1.18.2.35   18,414  17,863  17,000  18,428  18,093
  1.18.2.36   19,631  18,167  18,105  18,401  17,995
  1.18.2.37   22,707  24,830  24,322  23,613  22,498
   int_holdoff=10 19,259  19,870  19,355  18,725  19,273
   int_holdoff=1  18,464  18,218  17,862  16,701  17,798
   int_holdoff=0  19,423  18,507  19,505  20,714  20,460
  1.18.2.38   57,169  53,394  58,721 not done
   int_holdoff=10 30,266  33,493  33,240  33,247  30,470
   int_holdoff=1  27,013  28,777  28,047  25,858  27,615
   int_holdoff=0  40,284  33,040  33,726  36,834  35,235
  
  All this is on 
  
  FreeBSD-7.3-STABLE
  
  CPU: Intel(R) Core(TM)2 Quad CPUQ9650  @ 3.00GHz (3001.18-MHz 686-class 
  CPU)
Origin = GenuineIntel  Id = 0x1067a  Family = 6  Model = 17  Stepping = 
  10
  
  dev.mskc.0.%desc: Marvell Yukon 88E8053 Gigabit Ethernet
  dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02
  
  hw.msk.msi_disable was set to 1 but didn't change results
  when commenting it out.
  
  Any ideas or things I can try?
  
 
 Could you narrow down which side(RX or TX) cause the issue you're
 seeing? From your description it's not clear whether msk(4) is used
 as sender or receiver.

Well, both. I will try to describe the setup more exactly:

On the msk(4)-box a locally residing tar file (48 MB size
containing 5600 files) is unpacked onto an NFS volume.
This NFS volume is mounted from another box which got
an em(4)-based NIC. I have now measured the amounts of
data being sent end received simply by using netstat:

About 62 MB are being sent out of the msk(4)-box to the
em(4)-based NFS box and about 22 MB are received on the
msk(4)-box from the em(4)-based NFS box.

I have now tried the reverse direction as well: The em(4)-
based box mounts an NFS volume from the msk(4)-box and
unpacks the same tar file (now the 62 MB are received on
the msk(4)-box and 22 MB are transmitted from the msk(4)-
box). The results are similar:

rev. 1.18.2.38: 48,243 seconds
rev. 1.18.2.36: 17,536 seconds

But I noticed another thing here at work: If I choose a
remote machine which uses myk(4) (not msk(4)) instead of
em(4) there are no performance issues noticable. Unfortu-
natley I can't test msk(4) on the remote side at the
moment... So the performance issues exist only when the
new msk driver is talking to an em-based NIC...

 As you know 1.18.2.38 removed taskqueue based interrupt handling so
 it could be culprit of the issue. But that revision also removed
 two register accesses in TX path so I'd like to know which one
 caused the issue. 

I have now tried rev. 1.18.2.38 with this patch (no idea if
this is right ;-)):

--- if_msk.c.1.18.2.38  2010-04-06 15:09:19.0 +0200
+++ if_msk.c.1.18.2.38.TRY

Re: svn commit: r205614 - stable/7/sys/dev/msk

2010-04-06 Thread Andre Albsmeier

On Tue, 06-Apr-2010 at 15:46:26 +0200, Andre Albsmeier wrote:
 On Mon, 05-Apr-2010 at 20:06:42 +0200, Pyun YongHyeon wrote:
  On Mon, Apr 05, 2010 at 04:59:37PM +0200, Andre Albsmeier wrote:
   On Wed, 24-Mar-2010 at 18:21:05 +0100, Pyun YongHyeon wrote:
Author: yongari
Date: Wed Mar 24 17:21:05 2010
New Revision: 205614
URL: http://svn.freebsd.org/changeset/base/205614

Log:
  MFC r204545:
Remove taskqueue based interrupt handling. After r204541 msk(4)
does not generate excessive interrupts any more so we don't need
to have two copies of interrupt handler.
While I'm here remove two STAT_PUT_IDX register accesses in LE
status event handler. After r204539 msk(4) always sync status LEs
so there is no need to resort to reading STAT_PUT_IDX register to
know the end of status LE processing. Just trust status LE's
ownership bit.
   
   This ruined the performance on my system heavily. I noticed it
   when unpacking a local tar archive onto an NFS-mounted location
   on an em(4)-based box. This archive is about 50MB of size with
   a bit over 5600 files so files have an average size of 9 kB.
   
   I also noticed the slowdown when doing rdist-based updates (again
   lots of small files) onto the other box.
   
   Just pumping bytes over the network shows no problems -- I can
   transmit 100-105 MB/s and receive 95-100 MB/s when talking
   to this em(4)-based box without problem (and as it was before).
   
   When copying a few big files (several GBs of size) over NFS
   I get something between 70 and 90 MB/s which is the same as
   what I had got before.
   
   If have made some tests to track down when the issues began.
   Problems started with rev. 1.18.2.37 of if_msk.c but could
   be alleviated by setting dev.mskc.0.int_holdoff to 1 or 0.
   Things really got problematic with rev. 1.18.2.38 -- adjusting
   dev.mskc.0.int_holdoff helped a lot but we are far from what
   we had with 1.18.2.36 or earlier. I did 5 rounds of testing,
   each with the same set of if_msk.c revisions and values for
   int_holdoff (where appropriate) just to check reproducibility:
   
   if_msk.c rev.   round1  round2  round3  round4  round5
   
   1.18.2.34   17,115  18,408  17,977  16,412  19,170
   1.18.2.35   18,414  17,863  17,000  18,428  18,093
   1.18.2.36   19,631  18,167  18,105  18,401  17,995
   1.18.2.37   22,707  24,830  24,322  23,613  22,498
int_holdoff=10 19,259  19,870  19,355  18,725  19,273
int_holdoff=1  18,464  18,218  17,862  16,701  17,798
int_holdoff=0  19,423  18,507  19,505  20,714  20,460
   1.18.2.38   57,169  53,394  58,721 not done
int_holdoff=10 30,266  33,493  33,240  33,247  30,470
int_holdoff=1  27,013  28,777  28,047  25,858  27,615
int_holdoff=0  40,284  33,040  33,726  36,834  35,235
   
   All this is on 
   
   FreeBSD-7.3-STABLE
   
   CPU: Intel(R) Core(TM)2 Quad CPUQ9650  @ 3.00GHz (3001.18-MHz 
   686-class CPU)
 Origin = GenuineIntel  Id = 0x1067a  Family = 6  Model = 17  Stepping 
   = 10
   
   dev.mskc.0.%desc: Marvell Yukon 88E8053 Gigabit Ethernet
   dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02
   
   hw.msk.msi_disable was set to 1 but didn't change results
   when commenting it out.
   
   Any ideas or things I can try?
   
  
  Could you narrow down which side(RX or TX) cause the issue you're
  seeing? From your description it's not clear whether msk(4) is used
  as sender or receiver.
 
 Well, both. I will try to describe the setup more exactly:
 
 On the msk(4)-box a locally residing tar file (48 MB size
 containing 5600 files) is unpacked onto an NFS volume.
 This NFS volume is mounted from another box which got
 an em(4)-based NIC. I have now measured the amounts of
 data being sent end received simply by using netstat:
 
 About 62 MB are being sent out of the msk(4)-box to the
 em(4)-based NFS box and about 22 MB are received on the
 msk(4)-box from the em(4)-based NFS box.
 
 I have now tried the reverse direction as well: The em(4)-
 based box mounts an NFS volume from the msk(4)-box and
 unpacks the same tar file (now the 62 MB are received on
 the msk(4)-box and 22 MB are transmitted from the msk(4)-
 box). The results are similar:
 
 rev. 1.18.2.38:   48,243 seconds
 rev. 1.18.2.36: 17,536 seconds
 
 But I noticed another thing here at work: If I choose a
 remote machine which uses myk(4) (not msk(4)) instead of
 em(4) there are no performance issues noticable. Unfortu-
 natley I can't test msk(4) on the remote side at the
 moment... So the performance issues exist only when the
 new msk driver is talking to an em-based NIC...
 
  As you know 1.18.2.38 removed taskqueue based interrupt handling so
  it could be culprit of the issue. But that revision also removed
  two register accesses in TX path so I'd like to know which one
  caused

Re: svn commit: r205614 - stable/7/sys/dev/msk

2010-04-06 Thread Andre Albsmeier

On Tue, 06-Apr-2010 at 20:44:56 +0200, Pyun YongHyeon wrote:
 On Tue, Apr 06, 2010 at 08:00:27PM +0200, Andre Albsmeier wrote:
  On Tue, 06-Apr-2010 at 15:46:26 +0200, Andre Albsmeier wrote:
   On Mon, 05-Apr-2010 at 20:06:42 +0200, Pyun YongHyeon wrote:
 
 [...]
 
As you know 1.18.2.38 removed taskqueue based interrupt handling so
it could be culprit of the issue. But that revision also removed
two register accesses in TX path so I'd like to know which one
caused the issue. 
   
   I have now tried rev. 1.18.2.38 with this patch (no idea if
   this is right ;-)):
   
   --- if_msk.c.1.18.2.382010-04-06 15:09:19.0 +0200
   +++ if_msk.c.1.18.2.38.TRY2010-04-06 15:38:13.0 +0200
   @@ -3327,6 +3327,11 @@
 uint32_t control, status;
 int cons, len, port, rxprog;

   + int idx;
   + idx = CSR_READ_2(sc, STAT_PUT_IDX);
   + if (idx == sc-msk_stat_cons)
   + return (0);
   +
 /* Sync status LEs. */
 bus_dmamap_sync(sc-msk_stat_tag, sc-msk_stat_map,
 BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE);
   @@ -3407,7 +3412,7 @@
 if (rxput[MSK_PORT_B]  0)
 msk_rxput(sc-msk_if[MSK_PORT_B]);

   - return (rxprog  sc-msk_process_limit ? EAGAIN : 0);
   + return (sc-msk_stat_cons != CSR_READ_2(sc, STAT_PUT_IDX));
}

static void
   
   Now performance seems to be the same as with the older
   driver (at least here at work) and in both directions!
   Some numbers:
   
   em0 writes to rev. 1.18.2.36: 20 seconds
   em0 writes to rev. 1.18.2.38: 50 seconds
   em0 writes to rev. 1.18.2.38 with patch from above:   23 seconds
   same as before but with int_holdoff: 100 - 1:20 seconds
   
   rev. 1.18.2.36 writes to em0: 22 seconds
   rev. 1.18.2.38 writes to em0: 40 seconds
   rev. 1.18.2.38 with patch from above writes to em0:   21 seconds
   same as before but with int_holdoff: 100 - 1:20 seconds
   
   It seems that these two CSR_READ_2s really help ;-).
   
   As I said, this is at work and with slightly different machines.
   I will try things at home later but I am rather confident of
   receiving good results there as well...
  
  OK, tests at home show similar good results with the
  above patch. When setting int_holdoff to 3, performance
  seems equal to the older versions.
  
 
 Thanks a lot for narrowing down the issue.
 Because the msk_handle_events() are called in interrupt handler
 I'd like to remove the two register accesses in fast path. It seems
 accessing STAT_PUT_IDX triggers status updates. Would you try
 attached patch and let me know whether the patch makes any
 difference?

 Index: sys/dev/msk/if_msk.c
 ===
 --- sys/dev/msk/if_msk.c  (revision 206204)
 +++ sys/dev/msk/if_msk.c  (working copy)
 @@ -1470,6 +1470,7 @@
   /* WA for dev. #4.18 */
   CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21);
   CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07);
 + CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 10));
   } else {
   CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
   CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
 @@ -1481,9 +1482,16 @@
   CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190);
   }
   /*
 -  * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI.
 +  * STAT_TX_TIMER_INI, STAT_ISR_TIMER_INI and STAT_LEV_TIMER_INI
 +  * as well as various water mark registers seem to control when
 +  * controller initiates status LE update.
 +  * It's not clear how these registers interact with interrupt
 +  * state but STAT_TX_TIMER_INI seems to control status update
 +  * time after crossing a threshold(STAT_TX_IDX_TH) value. Due to
 +  * the complexity of various parameters that may affect status
 +  * update just use hardware default until we know better
 +  * the internal things of status updates.
*/
 - CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000));
  
   /* Enable status unit. */
   CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON);

After applying this patch against an original 1.18.2.39
things became even worse. After 4 minutes of waiting I
aborted untar'ing the file ;-). Setting int_holdoff=2
made things better, now it took 65 seconds for untar'ing...

-Andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r205614 - stable/7/sys/dev/msk

2010-04-05 Thread Andre Albsmeier

On Wed, 24-Mar-2010 at 18:21:05 +0100, Pyun YongHyeon wrote:
 Author: yongari
 Date: Wed Mar 24 17:21:05 2010
 New Revision: 205614
 URL: http://svn.freebsd.org/changeset/base/205614
 
 Log:
   MFC r204545:
 Remove taskqueue based interrupt handling. After r204541 msk(4)
 does not generate excessive interrupts any more so we don't need
 to have two copies of interrupt handler.
 While I'm here remove two STAT_PUT_IDX register accesses in LE
 status event handler. After r204539 msk(4) always sync status LEs
 so there is no need to resort to reading STAT_PUT_IDX register to
 know the end of status LE processing. Just trust status LE's
 ownership bit.

This ruined the performance on my system heavily. I noticed it
when unpacking a local tar archive onto an NFS-mounted location
on an em(4)-based box. This archive is about 50MB of size with
a bit over 5600 files so files have an average size of 9 kB.

I also noticed the slowdown when doing rdist-based updates (again
lots of small files) onto the other box.

Just pumping bytes over the network shows no problems -- I can
transmit 100-105 MB/s and receive 95-100 MB/s when talking
to this em(4)-based box without problem (and as it was before).

When copying a few big files (several GBs of size) over NFS
I get something between 70 and 90 MB/s which is the same as
what I had got before.

If have made some tests to track down when the issues began.
Problems started with rev. 1.18.2.37 of if_msk.c but could
be alleviated by setting dev.mskc.0.int_holdoff to 1 or 0.
Things really got problematic with rev. 1.18.2.38 -- adjusting
dev.mskc.0.int_holdoff helped a lot but we are far from what
we had with 1.18.2.36 or earlier. I did 5 rounds of testing,
each with the same set of if_msk.c revisions and values for
int_holdoff (where appropriate) just to check reproducibility:

if_msk.c rev.   round1  round2  round3  round4  round5

1.18.2.34   17,115  18,408  17,977  16,412  19,170
1.18.2.35   18,414  17,863  17,000  18,428  18,093
1.18.2.36   19,631  18,167  18,105  18,401  17,995
1.18.2.37   22,707  24,830  24,322  23,613  22,498
 int_holdoff=10 19,259  19,870  19,355  18,725  19,273
 int_holdoff=1  18,464  18,218  17,862  16,701  17,798
 int_holdoff=0  19,423  18,507  19,505  20,714  20,460
1.18.2.38   57,169  53,394  58,721 not done
 int_holdoff=10 30,266  33,493  33,240  33,247  30,470
 int_holdoff=1  27,013  28,777  28,047  25,858  27,615
 int_holdoff=0  40,284  33,040  33,726  36,834  35,235

All this is on 

FreeBSD-7.3-STABLE

CPU: Intel(R) Core(TM)2 Quad CPUQ9650  @ 3.00GHz (3001.18-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x1067a  Family = 6  Model = 17  Stepping = 10

dev.mskc.0.%desc: Marvell Yukon 88E8053 Gigabit Ethernet
dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02

hw.msk.msi_disable was set to 1 but didn't change results
when commenting it out.

Any ideas or things I can try?

Thanks,

-Andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r198244 - in stable/7/sys: . contrib/pf kern sys

2009-10-24 Thread Andre Albsmeier

On Mon, 19-Oct-2009 at 19:11:00 +, Andrew Gallatin wrote:
 Author: gallatin
 Date: Mon Oct 19 19:11:00 2009
 New Revision: 198244
 URL: http://svn.freebsd.org/changeset/base/198244
 
 Log:
   MFC of 178042 to allow safe firmware(9) loading from NIC watchdog handlers.
Also MFCed are the related changes 178016, 183614 and 184842.
   
 ...
 
 Modified: stable/7/sys/kern/subr_firmware.c
 ==
 --- stable/7/sys/kern/subr_firmware.c Mon Oct 19 18:52:05 2009
 (r198243)
 +++ stable/7/sys/kern/subr_firmware.c Mon Oct 19 19:11:00 2009
 (r198244)
 @@ -1,5 +1,5 @@
  /*-
 - * Copyright (c) 2005, Sam Leffler s...@errno.com
 + * Copyright (c) 2005-2008, Sam Leffler s...@errno.com
   * All rights reserved.
   *
   * Redistribution and use in source and binary forms, with or without
 @@ -41,6 +41,10 @@ __FBSDID($FreeBSD$);
  #include sys/priv.h
  #include sys/proc.h
  #include sys/module.h
 +#include sys/eventhandler.h
 +
 +#include sys/filedesc.h
 +#include sys/vnode.h

This broke make world on 7-STABLE when MODULES_WITH_WORLD
is defined. The fix is:

--- sys/modules/firmware/Makefile.ORI   2007-10-24 19:13:38.0 +0200
+++ sys/modules/firmware/Makefile   2009-10-24 19:38:10.0 +0200
@@ -3,6 +3,6 @@
 .PATH: ${.CURDIR}/../../kern
 
 KMOD=  firmware
-SRCS=  subr_firmware.c
+SRCS=  subr_firmware.c vnode_if.h
 
 .include bsd.kmod.mk


-Andre
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r359203 - stable/11/sys/conf

Re: svn commit: r346775 - stable/11/usr.sbin/nfsdumpstate

Re: svn commit: r341794 - stable/11/etc/periodic/weekly

Re: svn commit: r341794 - stable/11/etc/periodic/weekly

Re: svn commit: r339008 - in stable/11: include/rpcsvc lib/libutil libexec/rpc.rquotad sys/cddl/contrib/opensolaris/uts/common/fs/zfs usr.bin/quota

Re: svn commit: r333673 - in stable/11/etc: etc.aarch64 etc.amd64 etc.arm etc.i386 etc.powerpc etc.riscv etc.sparc64

Re: svn commit: r331506 - in stable/11/sys: arm/at91 arm/broadcom/bcm2835 arm/freescale/imx arm/freescale/vybrid arm/lpc arm/samsung/exynos arm/ti dev/flash dev/spibus dev/xilinx mips/atheros mips/med

Re: svn commit: r331502 - stable/11/sys/modules/i2c/iicbus

Re: svn commit: r328692 - in stable/11/sys: conf dev/nvme

Re: svn commit: r322345 - stable/11/lib/libc/x86/sys

Re: svn commit: r322345 - stable/11/lib/libc/x86/sys

Re: svn commit: r275890 - in stable/9: contrib/bind9 contrib/bind9/bin/check contrib/bind9/bin/confgen contrib/bind9/bin/dig contrib/bind9/bin/dig/include/dig contrib/bind9/bin/dnssec contrib/bind9/bi

Re: svn commit: r275890 - in stable/9: contrib/bind9 contrib/bind9/bin/check contrib/bind9/bin/confgen contrib/bind9/bin/dig contrib/bind9/bin/dig/include/dig contrib/bind9/bin/dnssec contrib/bind9/bi

Re: svn commit: r273973 - head/sys/dev/vt

Re: svn commit: r252063 - stable/9/sys/geom/mirror

Re: svn commit: r254897 - in stable/9: contrib/bind9 contrib/bind9/bin contrib/bind9/bin/check contrib/bind9/bin/confgen contrib/bind9/bin/dig contrib/bind9/bin/dig/include/dig contrib/bind9/bin/dnsse

Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

Re: svn commit: r252214 - in stable/9: bin/chio sys/cam/scsi sys/sys

Re: svn commit: r227961 - head/sbin/camcontrol

Re: svn commit: r218277 - in stable/7/sys: kern sys

Re: svn commit: r218277 - in stable/7/sys: kern sys

Re: svn commit: r205614 - stable/7/sys/dev/msk

Re: svn commit: r205614 - stable/7/sys/dev/msk

Re: svn commit: r205614 - stable/7/sys/dev/msk

Re: svn commit: r205614 - stable/7/sys/dev/msk

Re: svn commit: r205614 - stable/7/sys/dev/msk

Re: svn commit: r205614 - stable/7/sys/dev/msk

Re: svn commit: r198244 - in stable/7/sys: . contrib/pf kern sys

30 matches

Site Navigation

Mail list logo

Footer information