date:20150406

Re: Early use of log() does not end up in kernel msg buffer

2015-04-06 Thread Poul-Henning Kamp


In message <552326a2.5000...@badgerio.us>, Eric Badger writes:

>> The reason was systems not running syslog having slow serial consoles.
>
>Correct me if I've misunderstood, but that doesn't seem to matter here; 
>the proposed change adds logging to the message buffer but leaves 
>logging to the console (when no syslog is listening) unchanged.

Sorry, I must have misunderstood the question then.

I don't think I have any opinion on the log() function.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: Early use of log() does not end up in kernel msg buffer

2015-04-06 Thread Eric Badger


On 04/06/2015 04:11 PM, Poul-Henning Kamp wrote:


In message <2033248.eu3rhs8...@ralph.baldwin.cx>, John Baldwin writes:


I think phk@ broke this back in 70239.  Before that the log() function did
this:

log()
{

/* log to the msg buffer */
kvprintf(fmt, msglogchar, ...);

if (!log_open) {
/* log to console */
kvprintf(fmt, putchar, ...);
}
}

I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to
do this.

The reason was systems not running syslog having slow serial consoles.



Correct me if I've misunderstood, but that doesn't seem to matter here; 
the proposed change adds logging to the message buffer but leaves 
logging to the console (when no syslog is listening) unchanged.


Eric
___
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: Nothing can boot anymore - video issues

2015-04-06 Thread Devin Teske

> On Apr 6, 2015, at 1:35 PM, Shawn Webb  wrote:
> 
> On Mon, 2015-04-06 at 13:59 -0400, Shawn Webb wrote:
>> On Sun, 2015-04-05 at 12:07 -0700, Rui Paulo wrote:
>>> On Apr 5, 2015, at 09:11, Shawn Webb  wrote:

 So I just updated my laptop and desktop to a recent HEAD. Both machines
 boot using gptzfsboot. The boot spinner shows, then when it's supposed to
 transition to the Beastie logo screen, the monitor funks out. Booting never
 finishes. Below is a link to a picture of my laptop.

 http://imgur.com/l3mLDBX
>>> 
>>> Try reverting the Forth changes.  That's all that comes to mind.
>>> 
>>> --
>>> Rui Paulo
>> 
>> I'm going through commit-by-commit from April 3rd to March 31st, which
>> will take a big chunk of time. It's really weird that no one else has
>> reported this since even my VirtualBox VMs have this same issue.
>> 
>> Thanks,
>> 
>> Shawn
> 
> I've figured out the commit that caused the breakage. Looks like the
> boot Forth changes are pretty bad. The commit that caused the breakage,
> as far as I can tell is, r280974. Reverting that and the two commits
> above that revision regarding sys/boot/forth allowed me to boot again.
> 
> Now the boot screen looks like this: http://imgur.com/I9SVHfT
> 
> I can now boot, but as you see, the boot screen's messed up.
> 

Why the screen looks that way (no brand and no logo):
You were caught in a small window of broken-ness.

Window was between:
https://svnweb.freebsd.org/base?view=revision&revision=280933 

and
https://svnweb.freebsd.org/base?view=revision&revision=281002 

A window of approximately 2 days.

As for why the screen got wonky … well… your comp and my
comp don’t agree on ANSI sequences. I’ve reverted the offending
changes so that we may once-again agree on ANSI codes. ;D
— 
Cheers,
Devin
___
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: panic: object has cached pages on recent HEAD

2015-04-06 Thread Don Lewis

On  6 Apr, To: curr...@freebsd.org wrote:
> I just got this panic on my port builder machine running a recent
> version of HEAD (last updated in the last few days):
> 
> panic: object has cached pages on recent HEAD
> 
> As you can see, I was pushing it really hard:
> 
> last pid: 76867;  load averages: 62.92, 41.93, 41.40up 7+10:24:04  
> 13:45:01
> 448 processes: 97 running, 344 sleeping, 7 stopped
> CPU: 79.1% user,  0.0% nice, 20.9% system,  0.0% interrupt,  0.0% idle
> Mem: 5887M Active, 163M Inact, 6085M Wired, 17M Cache, 832K Buf, 3658M Free
> ARC: 1482M Total, 163M MFU, 663M MRU, 7080K Anon, 70M Header, 579M Other
> Swap: 40G Total, 9167M Used, 31G Free, 22% Inuse, 1152K In
> 
>   PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAND
> 73630 root  1  770   195M   181M CPU55   0:06  37.28% cc1plus
> 75387 root  1  780   209M   193M RUN 2   0:06  36.60% cc1plus
> 75615 root  1  740   150M   133M RUN 7   0:04  36.20% cc1plus
> 74151 root  1  780   306M   290M RUN 0   0:12  31.77% cc1plus
> 72986 root  1  780   282M   264M RUN 5   0:19  30.24% cc1plus
> 72985 root  1  770   292M   272M RUN 1   0:18  28.00% cc1plus
> 75912 root  1  750   106M 97604K RUN 3   0:03  27.73% cc1plus
> 74501 root  1  800   293M   280M RUN 7   0:11  27.14% cc1plus
> 73442 root  1  770   329M   299M RUN 2   0:13  26.54% cc1plus
> 75715 root  1  750 96996K 81424K RUN 3   0:02  22.51% cc1plus
> 74645 root  1  780   252M   236M RUN 6   0:09  21.73% cc1plus
> 75630 root  1  770   208M   189M RUN 4   0:08  19.27% cc1plus
> 74324 root  1  780   322M   308M RUN 4   0:11  19.17% cc1plus
> 75494 root  1  740   138M   126M RUN 4   0:04  19.07% cc1plus
> 74848 root  1  730 98180K 85192K RUN 2   0:02  16.12% cc1plus
> 76292 root  1  730 63108K 46904K RUN 0   0:01  15.92% cc1plus
> 
> A screenshot with a backtrace is here:
> 
> 
> Is there anything I should check in DDB before I reboot?  I can get the
> svn revision after I do that.
> 
> I've never crashed this machine before, so I don't know if crashdumps
> work.

I was able to call doadump() from ddb, but when I rebooted, savecore was
not able to find the dump.  I dumped to swap, which is mirrored ...

FreeBSD zipper.catspoiler.org 11.0-CURRENT FreeBSD 11.0-CURRENT #13
r280327M: Sun Mar 29 22:26:50 PDT 2015

I am running with this custom patch so that pre-compiled headers work
with gcc:

Index: sys/vm/vm_mmap.c
===
--- sys/vm/vm_mmap.c(revision 280837)
+++ sys/vm/vm_mmap.c(working copy)
@@ -325,6 +325,8 @@
 * There should really be a pmap call to determine a reasonable
 * location.
 */
+   if (addr != 0 && (flags & MAP_ANON) == 0)
+   flags |= MAP_RESERVED0100;
PROC_LOCK(td->td_proc);
if (addr == 0 ||
(addr >= round_page((vm_offset_t)vms->vm_taddr) &&
@@ -1665,6 +1667,8 @@
else if ((flags & MAP_ALIGNMENT_MASK) != 0)
findspace = VMFS_ALIGNED_SPACE(flags >>
MAP_ALIGNMENT_SHIFT);
+   else if ((flags & MAP_RESERVED0100) != 0)
+   findspace = VMFS_ANY_SPACE;
else
findspace = VMFS_OPTIMAL_SPACE;
rv = vm_map_find(map, object, foff, addr, size,

___
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: async pass(4) patches available

2015-04-06 Thread Kenneth D. Merry

On Mon, Apr 06, 2015 at 15:39:56 +0200, Fabian Keil wrote:
> "Kenneth D. Merry"  wrote:
> 
> > I have put patches to add an asynchronous interface to the pass(4) driver
> > and add a new camdd(8) utility here:
> > 
> > FreeBSD/head as of SVN revision 280857:
> > 
> > http://people.freebsd.org/~ken/async_pass.head.20150330.1.txt
> [...]
> > Comments and testing are welcome!  As I said, camdd(8) in particular is a
> > work in progress.  It could use some cleanup and there are some more
> > useful features that could be added there.
> 
> I've been using the patch for a couple of days on an amd64 system
> based on 11.0-CURRENT r280952 and didn't notice any obvious
> regressions using the system as usual.
> 
> Scrubbing a pool once revealed checksum errors which I haven't
> seen before:
> 
> [fk@kendra ~]$ zpool status -v dpool
>   pool: dpool
>  state: ONLINE
> status: One or more devices has experienced an unrecoverable error.  An
> attempt was made to correct the error.  Applications are unaffected.
> action: Determine if the device needs to be replaced, and clear the errors
> using 'zpool clear' or replace the device with 'zpool replace'.
>see: http://illumos.org/msg/ZFS-8000-9P
>   scan: scrub repaired 0 in 1h52m with 0 errors on Thu Apr  2 13:01:44 2015
> config:
> 
> NAME  STATE READ WRITE CKSUM
> dpool ONLINE   0 0 0
>   gpt/dpool-ada0.eli  ONLINE   0 0 6
> 
> errors: No known data errors
> 
> Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 
> 60 30 17 61 55 40 31 00 00 00 00 00
> Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): CAM status: ATA Status 
> Error
> Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): ATA status: 51 (DRDY 
> SERV ERR), error: 40 (UNC )
> Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): RES: 51 40 3e 61 55 40 
> 31 00 00 00 00
> Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): Error 5, Retries 
> exhausted
> Apr  2 12:31:34 kendra kernel: GEOM_ELI: g_eli_read_done() failed 
> gpt/dpool-ada0.eli[READ(offset=414970949120, length=24576)]
> 
> However the issue doesn't seem to be (easily) reproducible
> and could be unrelated.

It is unlikely that this is related to the pass(4) driver patches.  Possible,
but highly unlikely.  camdd(8) doesn't support ATA passthrough yet, so the
only way to access it with camdd is with the file I/O method.

> I also tried to test camdd, but didn't get it to work.
> Some failed attempts:
> 
> [fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536 -o file=blafsel.img
> (pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00 
> (pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> 13 bytes read from pass2
> 13 bytes written to blafsel.img
> 20.3203 seconds elapsed
> 0.00 MB/sec
> [fk@kendra ~]$ sudo hd blafsel.img 
>   55 53 42 53 d9 02 00 00  00 00 01 00 01   |USBS.|
> 000d
> [fk@kendra ~]$ sudo dd if=/dev/da0 bs=1k count=1  | hd | head -n 1
> 1+0 records in
> 1+0 records out
> 1024 bytes transferred in 0.000603 secs (1697756 bytes/sec)
>   fc 31 c0 8e c0 8e d8 8e  d0 bc 00 0e be 1a 7c bf  |.1|.|

One possibility is that the device doesn't support 6-byte read/write
requests.  The da(4) driver has quirk entries and code to figure that out
and default to 10-byte read/write requests, but camdd(8) doesn't have
anything like that yet.

I've attached patches to camdd that allow you to specify a minimum command
size.  So, apply the patches, rebuild camdd, and try this:

# sudo camdd -i pass=da0,bs=65536,mcs=10 -o file=blafsel.img

We'll see if that helps.  I'm not sure why you were even able to get 13
bytes back.  That is very strange.

> Trying the block size suggested in the manual result in:
> 
> [fk@kendra ~]$ sudo camdd -i pass=da0,bs=1M -o file=blafsel.img
> camdd: camdd_pass_run: error sending CAMIOQUEUE ioctl to pass2: Invalid 
> argument
> camdd: camdd_pass_run: CCB address is 0x80250e420: Invalid argument
> 0 bytes read from pass2
> 0 bytes written to blafsel.img
> 0.0007 seconds elapsed
> 0.00 MB/sec
> 
> Apr  5 19:08:20 kendra kernel: (pass2:umass-sim0:0:0:0): passmemsetup: data 
> length 1048576 > max allowed 65536 bytes
> 

Yes.  By default, if you don't specify a blocksize, camdd(8) should limit
the I/O size to the controller's maximum or 128K, whichever is smaller.  If
you specify an I/O size, it will try to use that.

Thanks for testing the code, I really appreciate it!

Let me know how the patch works!

Ken
-- 
Kenneth Merry
k...@freebsd.org
 //depot/users/kenm/FreeBSD-test2/usr.sbin/camdd/camdd.8#1 - 
/usr/home/kenm/perforce4/kenm/FreeBSD-test2/usr.sbin/camdd/camdd.8 
*** /tmp/tmp.54366.13   Mon Apr  6 21:56:38 2015
--- /usr/home/kenm/perforce4/kenm/FreeBSD-test2/usr.sbin/camdd/camdd.8  Mon Apr 
 6 21:23:29 2015
***
*** 31,37 
  .\" 
  .\" $FreeBSD$
  .\"
! .Dd March 13, 2015
  .Dt CAMDD 8
  .Os
  .Sh NAME
-

Re: Early use of log() does not end up in kernel msg buffer

2015-04-06 Thread Adrian Chadd

On 6 April 2015 at 14:11, Poul-Henning Kamp  wrote:
> 
> In message <2033248.eu3rhs8...@ralph.baldwin.cx>, John Baldwin writes:
>
>>I think phk@ broke this back in 70239.  Before that the log() function did
>>this:
>>
>>log()
>>{
>>
>>   /* log to the msg buffer */
>>   kvprintf(fmt, msglogchar, ...);
>>
>>   if (!log_open) {
>>   /* log to console */
>>   kvprintf(fmt, putchar, ...);
>>   }
>>}
>>
>>I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to
>>do this.
>
> The reason was systems not running syslog having slow serial consoles.

.. and that's still a thing, btw.



-adrian
___
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: Early use of log() does not end up in kernel msg buffer

2015-04-06 Thread Poul-Henning Kamp


In message <2033248.eu3rhs8...@ralph.baldwin.cx>, John Baldwin writes:

>I think phk@ broke this back in 70239.  Before that the log() function did
>this:
>
>log()
>{
>
>   /* log to the msg buffer */
>   kvprintf(fmt, msglogchar, ...);
>
>   if (!log_open) {
>   /* log to console */
>   kvprintf(fmt, putchar, ...);
>   }
>}
>
>I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to
>do this.

The reason was systems not running syslog having slow serial consoles.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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"

panic: object has cached pages on recent HEAD

2015-04-06 Thread Don Lewis

I just got this panic on my port builder machine running a recent
version of HEAD (last updated in the last few days):

panic: object has cached pages on recent HEAD

As you can see, I was pushing it really hard:

last pid: 76867;  load averages: 62.92, 41.93, 41.40up 7+10:24:04  13:45:01
448 processes: 97 running, 344 sleeping, 7 stopped
CPU: 79.1% user,  0.0% nice, 20.9% system,  0.0% interrupt,  0.0% idle
Mem: 5887M Active, 163M Inact, 6085M Wired, 17M Cache, 832K Buf, 3658M Free
ARC: 1482M Total, 163M MFU, 663M MRU, 7080K Anon, 70M Header, 579M Other
Swap: 40G Total, 9167M Used, 31G Free, 22% Inuse, 1152K In

  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAND
73630 root  1  770   195M   181M CPU55   0:06  37.28% cc1plus
75387 root  1  780   209M   193M RUN 2   0:06  36.60% cc1plus
75615 root  1  740   150M   133M RUN 7   0:04  36.20% cc1plus
74151 root  1  780   306M   290M RUN 0   0:12  31.77% cc1plus
72986 root  1  780   282M   264M RUN 5   0:19  30.24% cc1plus
72985 root  1  770   292M   272M RUN 1   0:18  28.00% cc1plus
75912 root  1  750   106M 97604K RUN 3   0:03  27.73% cc1plus
74501 root  1  800   293M   280M RUN 7   0:11  27.14% cc1plus
73442 root  1  770   329M   299M RUN 2   0:13  26.54% cc1plus
75715 root  1  750 96996K 81424K RUN 3   0:02  22.51% cc1plus
74645 root  1  780   252M   236M RUN 6   0:09  21.73% cc1plus
75630 root  1  770   208M   189M RUN 4   0:08  19.27% cc1plus
74324 root  1  780   322M   308M RUN 4   0:11  19.17% cc1plus
75494 root  1  740   138M   126M RUN 4   0:04  19.07% cc1plus
74848 root  1  730 98180K 85192K RUN 2   0:02  16.12% cc1plus
76292 root  1  730 63108K 46904K RUN 0   0:01  15.92% cc1plus

A screenshot with a backtrace is here:


Is there anything I should check in DDB before I reboot?  I can get the
svn revision after I do that.

I've never crashed this machine before, so I don't know if crashdumps
work.

___
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: Nothing can boot anymore - video issues

2015-04-06 Thread Shawn Webb

On Mon, 2015-04-06 at 13:59 -0400, Shawn Webb wrote:
> On Sun, 2015-04-05 at 12:07 -0700, Rui Paulo wrote:
> > On Apr 5, 2015, at 09:11, Shawn Webb  wrote:
> > > 
> > > So I just updated my laptop and desktop to a recent HEAD. Both machines
> > > boot using gptzfsboot. The boot spinner shows, then when it's supposed to
> > > transition to the Beastie logo screen, the monitor funks out. Booting 
> > > never
> > > finishes. Below is a link to a picture of my laptop.
> > > 
> > > http://imgur.com/l3mLDBX
> > 
> > Try reverting the Forth changes.  That's all that comes to mind.
> > 
> > --
> > Rui Paulo
> 
> I'm going through commit-by-commit from April 3rd to March 31st, which
> will take a big chunk of time. It's really weird that no one else has
> reported this since even my VirtualBox VMs have this same issue.
> 
> Thanks,
> 
> Shawn

I've figured out the commit that caused the breakage. Looks like the
boot Forth changes are pretty bad. The commit that caused the breakage,
as far as I can tell is, r280974. Reverting that and the two commits
above that revision regarding sys/boot/forth allowed me to boot again.

Now the boot screen looks like this: http://imgur.com/I9SVHfT

I can now boot, but as you see, the boot screen's messed up.

Thanks,

Shawn


signature.asc
Description: This is a digitally signed message part

Re: Is a high witness refcount indicative of a missing unlock?

2015-04-06 Thread John Baldwin

On Sunday, March 29, 2015 02:29:42 PM Lars wrote:
> Hi,
> I am poking around for a cause for my repeating deadlock issues on my system 
> based on r 279869. ddb show witness show the “vnode interlock” and the “zfs” 
> locks both with reference counts over 200K. Obviously they are related, and 
> there is a find running (all the filesystems on this machine are zfs ( minus 
> the specialty ones like devfs).
> 
> I don’t see any other withness entry with reference counts even in the 
> ballpark of these two, so does this indicate that we have a vnode/zfs path 
> were we don’t unlock?

The ref count just means that the locks exist (so you have 200k ZFS vnodes),
not that the locks are currently held.  The reference count on the witness
object is bumped when a lock is created that uses that witness object and
released when the lock is destroyed.

-- 
John Baldwin
___
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: Early use of log() does not end up in kernel msg buffer

2015-04-06 Thread John Baldwin

On Thursday, March 26, 2015 10:20:13 PM Eric Badger wrote:
> Using log(9) when no process is reading the log results in the message 
> going only to the console (contrast with printf(9), which goes to the 
> console and to the kernel message buffer in this case). I believe it is 
> truer to the semantics of logging for messages to *always* go to the 
> message buffer (where they can eventually be collected and in fact put 
> into a logfile). I therefore propose the attached patch, which sends 
> log(9) to the message buffer always, and to the console only if no one 
> has yet opened the log.
> 
> It may be more complete to log to the console only if the log level is 
> greater than some (user defined) value, but this seems like that might 
> be more than necessary for this case.
> 
> Thoughts?

I think phk@ broke this back in 70239.  Before that the log() function did
this:

log()
{

/* log to the msg buffer */
kvprintf(fmt, msglogchar, ...);

if (!log_open) {
/* log to console */
kvprintf(fmt, putchar, ...);
}
}

I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to
do this.

-- 
John Baldwin
___
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: How to hotplug pci/e devices in freeBSD? (Or How to remove and rescan/re-enumerate pci device?)

2015-04-06 Thread John Baldwin

On Thursday, April 02, 2015 10:17:47 AM Eran Harpaz wrote:
> I'm looking for a way to refresh/re-enumerate the pci device list.
> 
> In Linux, you can remove a particular pci device, and then after preforming
> a "rescan" the device will appear again. In Linux it is done by:
> 
> echo 1 > /sys/bus/pci/devices/.../remove
> echo 1 > /sys/bus/pci/rescan
> 
> I'm looking for a similar functionality in freeBSD.
> 
> *What do I want to achieve?*
> 
> I'm using freeBSD and my pcie device can be reset from the host. But when
> it boots again, it's uncommunicative, so I want to rescan the pci devices
> in order to initiate a new connection between the host and the device.
> 
> Any idea would be appreciated, even if it takes some coding effort.

This is not currently supported.  Hotplug support is being worked on by
jmg@.  However, if you want to rescan a non-hotplug device (e.g. flashing
an FPGA board), then I can probably add extensions to devctl in HEAD to
let you do this.

-- 
John Baldwin
___
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: SSE in libthr

2015-04-06 Thread John Baldwin

On Saturday, March 28, 2015 10:41:48 AM Adrian Chadd wrote:
> Ok, so how do we reduce the amount of FPU save and restores, or make
> them cheaper?

Or make them more useful.  If you are using SSE/AVX more often between context
switches in ways that are beneficial then that might offset the cost of the
save and restore and result in a net win.  I have variants of strlen, memcpy,
and memset that use SSE.  However, microbenchmarks aren't super useful as you
have noted.  If you would like to try these out in some real workloads I can
provide a patch to libc.

-- 
John Baldwin
___
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: Nothing can boot anymore - video issues

2015-04-06 Thread Shawn Webb

On Sun, 2015-04-05 at 12:07 -0700, Rui Paulo wrote:
> On Apr 5, 2015, at 09:11, Shawn Webb  wrote:
> > 
> > So I just updated my laptop and desktop to a recent HEAD. Both machines
> > boot using gptzfsboot. The boot spinner shows, then when it's supposed to
> > transition to the Beastie logo screen, the monitor funks out. Booting never
> > finishes. Below is a link to a picture of my laptop.
> > 
> > http://imgur.com/l3mLDBX
> 
> Try reverting the Forth changes.  That's all that comes to mind.
> 
> --
> Rui Paulo

I'm going through commit-by-commit from April 3rd to March 31st, which
will take a big chunk of time. It's really weird that no one else has
reported this since even my VirtualBox VMs have this same issue.

Thanks,

Shawn


signature.asc
Description: This is a digitally signed message part

Re: [RFC] Add "GELI Passphrase:" prompt to boot loader

2015-04-06 Thread Devin Teske

> On Apr 6, 2015, at 10:52 AM, Eric van Gyzen  wrote:
> 
> On 04/06/2015 13:39, Devin Teske wrote:
>> 
>>> On Apr 6, 2015, at 10:24 AM, Eric van Gyzen  wrote:
>>> 
>>> On 04/06/2015 12:58, Devin Teske wrote:
 Hi -current,

 I have a pending enhancement to the boot loader that Colin P. and I
 have been working on together.

 URL: https://reviews.freebsd.org/D2105 

 The nature of the patch is to cause the boot loader to prompt for the
 GELI passphrase and then pass that on (through a kenv(1) variable)
 to Colin’s code in geom_eli.ko where it will be:

 (a) picked up for-use as the initial passphrase attempt(s)
 (b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
 returns nothing

 NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
 “kenv: unable to get kern.geom.eli.passphrase”

 The problem that I (we) need help in solving is:

 If the geom_eli.ko module doesn’t get loaded, then the variable
 (kern.geom.eli.passphrase) is not zeroed.

 While I do think that this is of minimal concern (not loading the GELI
 module means you won’t be able to get past the mountroot prompt in
 the case where GELI is required to boot), I discussed with Colin and
 I think we are in consensus that the resetting of the variable should
 perhaps be moved to another section of the kernel to prevent leakage
 of this sensitive information being passed through kenv(1) variable(s).

 Issue for me is, I’m not sure where the best place to move this to.
 Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):

 https://svnweb.freebsd.org/base?view=revision&revision=273489 

 108 

  /* Wipe the passphrase from the 
 environment. */
 109 

  kern_unsetenv("kern.geom.eli.passphrase");

 Need to move that preferably to some place in the kernel that is NOT
 optional in the compilation process. Suggestions?
>>> 
>>> How about putting it right after a successful mount of the root file 
>>> system? 
>>> (I've never used GELI, so this could be as "right out" as five.)
>>> 
>> 
>> I think that’s an excellent idea.
>> 
>> /me rummages through source
>> 
>> I’m thinking that the best place might be where we deal with the registered
>> event handler for mountroot.
>> 
>> 
>> One place that I crawled upon that looks particularly sexy is in start_init()
>> of sys/kern/init_main.c:
>> 
>> ### BEGIN SNIPPET ###
>> /*
>> * Start the initial user process; try exec’ing each pathname in init_path.
>> * The program is invoked with one argument containing the boot flags.
>> */
>> static void
>> start_init(void *dummy)
>> {
>>  vm_offset_t addr;
>>  struct execve_args args;
>>  int options, error;
>>  char *var, *path, *next, *s;
>>  char *ucp, **uap, *arg0, *arg1;
>>  struct thread *td;
>>  struct proc *p;
>> 
>>  mtx_lock(&Giant);
>> 
>>  GIANT_REQUIRED;
>> 
>>  td = furthered;
>>  p = td->td_proc;
>> 
>>  vfs_mountroot();
>> 
>>  ### RFC for code placement ###
>>  /* XXX Put reset of kern.geom.eli.passphrase here XXX */
>>  ##
>> 
>>  /*
>>   * Need just enough stack to hold the faked-up “execve()” arguments.
>>   */
>>  // snip rest //
>> ### END SNIPPET ###
>> 
>> Or can you think of a better place?
> 
> That looks good to me, although I'm no expert in this area, so you might wait
> for more opinions.
> 

Kk. In the meantime, I’ve updated the patch in D2105 to reflect the new 
potential
outcome. Worth noting, that I left the kern_unsetenv() call in 
sys/geom/eli/geom_eli.c
in-tact (didn’t see any harm in calling kern_unsetenv() on the same variable 
twice; no
real conerns of removing it, just didn’t see any harm in leaving it).

Would like feedback on phabricator.
https://reviews.freebsd.org/D2105 
— 
Cheers,
Devin
___
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: [RFC] Add "GELI Passphrase:" prompt to boot loader

2015-04-06 Thread Eric van Gyzen

On 04/06/2015 13:39, Devin Teske wrote:
> 
>> On Apr 6, 2015, at 10:24 AM, Eric van Gyzen  wrote:
>>
>> On 04/06/2015 12:58, Devin Teske wrote:
>>> Hi -current,
>>>
>>> I have a pending enhancement to the boot loader that Colin P. and I
>>> have been working on together.
>>>
>>> URL: https://reviews.freebsd.org/D2105 
>>>
>>> The nature of the patch is to cause the boot loader to prompt for the
>>> GELI passphrase and then pass that on (through a kenv(1) variable)
>>> to Colin’s code in geom_eli.ko where it will be:
>>>
>>> (a) picked up for-use as the initial passphrase attempt(s)
>>> (b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
>>> returns nothing
>>>
>>> NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
>>> “kenv: unable to get kern.geom.eli.passphrase”
>>>
>>> The problem that I (we) need help in solving is:
>>>
>>> If the geom_eli.ko module doesn’t get loaded, then the variable
>>> (kern.geom.eli.passphrase) is not zeroed.
>>>
>>> While I do think that this is of minimal concern (not loading the GELI
>>> module means you won’t be able to get past the mountroot prompt in
>>> the case where GELI is required to boot), I discussed with Colin and
>>> I think we are in consensus that the resetting of the variable should
>>> perhaps be moved to another section of the kernel to prevent leakage
>>> of this sensitive information being passed through kenv(1) variable(s).
>>>
>>> Issue for me is, I’m not sure where the best place to move this to.
>>> Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):
>>>
>>> https://svnweb.freebsd.org/base?view=revision&revision=273489 
>>> 
>>>
>>>
>>> 108 
>>> 
>>>   /* Wipe the passphrase from the environment. */
>>> 109 
>>> 
>>>   kern_unsetenv("kern.geom.eli.passphrase");
>>>
>>> Need to move that preferably to some place in the kernel that is NOT
>>> optional in the compilation process. Suggestions?
>>
>> How about putting it right after a successful mount of the root file system? 
>> (I've never used GELI, so this could be as "right out" as five.)
>>
> 
> I think that’s an excellent idea.
> 
> /me rummages through source
> 
> I’m thinking that the best place might be where we deal with the registered
> event handler for mountroot.
> 
> 
> One place that I crawled upon that looks particularly sexy is in start_init()
> of sys/kern/init_main.c:
> 
> ### BEGIN SNIPPET ###
> /*
>  * Start the initial user process; try exec’ing each pathname in init_path.
>  * The program is invoked with one argument containing the boot flags.
>  */
> static void
> start_init(void *dummy)
> {
>   vm_offset_t addr;
>   struct execve_args args;
>   int options, error;
>   char *var, *path, *next, *s;
>   char *ucp, **uap, *arg0, *arg1;
>   struct thread *td;
>   struct proc *p;
> 
>   mtx_lock(&Giant);
> 
>   GIANT_REQUIRED;
> 
>   td = furthered;
>   p = td->td_proc;
> 
>   vfs_mountroot();
> 
>   ### RFC for code placement ###
>   /* XXX Put reset of kern.geom.eli.passphrase here XXX */
>   ##
> 
>   /*
>* Need just enough stack to hold the faked-up “execve()” arguments.
>*/
>   // snip rest //
> ### END SNIPPET ###
> 
> Or can you think of a better place?

That looks good to me, although I'm no expert in this area, so you might wait
for more opinions.

Eric
___
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: [RFC] Add "GELI Passphrase:" prompt to boot loader

2015-04-06 Thread Devin Teske


> On Apr 6, 2015, at 10:24 AM, Eric van Gyzen  wrote:
> 
> On 04/06/2015 12:58, Devin Teske wrote:
>> Hi -current,
>> 
>> I have a pending enhancement to the boot loader that Colin P. and I
>> have been working on together.
>> 
>> URL: https://reviews.freebsd.org/D2105 
>> 
>> The nature of the patch is to cause the boot loader to prompt for the
>> GELI passphrase and then pass that on (through a kenv(1) variable)
>> to Colin’s code in geom_eli.ko where it will be:
>> 
>> (a) picked up for-use as the initial passphrase attempt(s)
>> (b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
>> returns nothing
>> 
>> NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
>> “kenv: unable to get kern.geom.eli.passphrase”
>> 
>> The problem that I (we) need help in solving is:
>> 
>> If the geom_eli.ko module doesn’t get loaded, then the variable
>> (kern.geom.eli.passphrase) is not zeroed.
>> 
>> While I do think that this is of minimal concern (not loading the GELI
>> module means you won’t be able to get past the mountroot prompt in
>> the case where GELI is required to boot), I discussed with Colin and
>> I think we are in consensus that the resetting of the variable should
>> perhaps be moved to another section of the kernel to prevent leakage
>> of this sensitive information being passed through kenv(1) variable(s).
>> 
>> Issue for me is, I’m not sure where the best place to move this to.
>> Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):
>> 
>> https://svnweb.freebsd.org/base?view=revision&revision=273489 
>> 
>> 
>> 
>> 108 
>> 
>>/* Wipe the passphrase from the environment. */
>> 109 
>> 
>>kern_unsetenv("kern.geom.eli.passphrase");
>> 
>> Need to move that preferably to some place in the kernel that is NOT
>> optional in the compilation process. Suggestions?
> 
> How about putting it right after a successful mount of the root file system? 
> (I've never used GELI, so this could be as "right out" as five.)
> 

I think that’s an excellent idea.

/me rummages through source

I’m thinking that the best place might be where we deal with the registered
event handler for mountroot.


One place that I crawled upon that looks particularly sexy is in start_init()
of sys/kern/init_main.c:

### BEGIN SNIPPET ###
/*
 * Start the initial user process; try exec’ing each pathname in init_path.
 * The program is invoked with one argument containing the boot flags.
 */
static void
start_init(void *dummy)
{
vm_offset_t addr;
struct execve_args args;
int options, error;
char *var, *path, *next, *s;
char *ucp, **uap, *arg0, *arg1;
struct thread *td;
struct proc *p;

mtx_lock(&Giant);

GIANT_REQUIRED;

td = furthered;
p = td->td_proc;

vfs_mountroot();

### RFC for code placement ###
/* XXX Put reset of kern.geom.eli.passphrase here XXX */
##

/*
 * Need just enough stack to hold the faked-up “execve()” arguments.
 */
// snip rest //
### END SNIPPET ###

Or can you think of a better place?
— 
Devin
___
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: [RFC] Add "GELI Passphrase:" prompt to boot loader

2015-04-06 Thread Eric van Gyzen

On 04/06/2015 12:58, Devin Teske wrote:
> Hi -current,
>
> I have a pending enhancement to the boot loader that Colin P. and I
> have been working on together.
>
> URL: https://reviews.freebsd.org/D2105 
>
> The nature of the patch is to cause the boot loader to prompt for the
> GELI passphrase and then pass that on (through a kenv(1) variable)
> to Colin’s code in geom_eli.ko where it will be:
>
> (a) picked up for-use as the initial passphrase attempt(s)
> (b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
> returns nothing
>
> NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
> “kenv: unable to get kern.geom.eli.passphrase”
>
> The problem that I (we) need help in solving is:
>
> If the geom_eli.ko module doesn’t get loaded, then the variable
> (kern.geom.eli.passphrase) is not zeroed.
>
> While I do think that this is of minimal concern (not loading the GELI
> module means you won’t be able to get past the mountroot prompt in
> the case where GELI is required to boot), I discussed with Colin and
> I think we are in consensus that the resetting of the variable should
> perhaps be moved to another section of the kernel to prevent leakage
> of this sensitive information being passed through kenv(1) variable(s).
>
> Issue for me is, I’m not sure where the best place to move this to.
> Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):
>
> https://svnweb.freebsd.org/base?view=revision&revision=273489 
> 
>
>
> 108 
> 
> /* Wipe the passphrase from the environment. */
> 109 
> 
> kern_unsetenv("kern.geom.eli.passphrase");
>
> Need to move that preferably to some place in the kernel that is NOT
> optional in the compilation process. Suggestions?

How about putting it right after a successful mount of the root file system? 
(I've never used GELI, so this could be as "right out" as five.)

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

[RFC] Add "GELI Passphrase:" prompt to boot loader

2015-04-06 Thread Devin Teske

Hi -current,

I have a pending enhancement to the boot loader that Colin P. and I
have been working on together.

URL: https://reviews.freebsd.org/D2105 

The nature of the patch is to cause the boot loader to prompt for the
GELI passphrase and then pass that on (through a kenv(1) variable)
to Colin’s code in geom_eli.ko where it will be:

(a) picked up for-use as the initial passphrase attempt(s)
(b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
returns nothing

NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
“kenv: unable to get kern.geom.eli.passphrase”

The problem that I (we) need help in solving is:

If the geom_eli.ko module doesn’t get loaded, then the variable
(kern.geom.eli.passphrase) is not zeroed.

While I do think that this is of minimal concern (not loading the GELI
module means you won’t be able to get past the mountroot prompt in
the case where GELI is required to boot), I discussed with Colin and
I think we are in consensus that the resetting of the variable should
perhaps be moved to another section of the kernel to prevent leakage
of this sensitive information being passed through kenv(1) variable(s).

Issue for me is, I’m not sure where the best place to move this to.
Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):

https://svnweb.freebsd.org/base?view=revision&revision=273489 



108 

  /* Wipe the passphrase from the environment. */
109 

  kern_unsetenv("kern.geom.eli.passphrase");

Need to move that preferably to some place in the kernel that is NOT
optional in the compilation process. Suggestions?
— 
Cheers,
Devin
___
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: async pass(4) patches available

2015-04-06 Thread Fabian Keil

"Kenneth D. Merry"  wrote:

> I have put patches to add an asynchronous interface to the pass(4) driver
> and add a new camdd(8) utility here:
> 
> FreeBSD/head as of SVN revision 280857:
> 
> http://people.freebsd.org/~ken/async_pass.head.20150330.1.txt
[...]
> Comments and testing are welcome!  As I said, camdd(8) in particular is a
> work in progress.  It could use some cleanup and there are some more
> useful features that could be added there.

I've been using the patch for a couple of days on an amd64 system
based on 11.0-CURRENT r280952 and didn't notice any obvious
regressions using the system as usual.

Scrubbing a pool once revealed checksum errors which I haven't
seen before:

[fk@kendra ~]$ zpool status -v dpool
  pool: dpool
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: scrub repaired 0 in 1h52m with 0 errors on Thu Apr  2 13:01:44 2015
config:

NAME  STATE READ WRITE CKSUM
dpool ONLINE   0 0 0
  gpt/dpool-ada0.eli  ONLINE   0 0 6

errors: No known data errors

Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 
30 17 61 55 40 31 00 00 00 00 00
Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): CAM status: ATA Status 
Error
Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV 
ERR), error: 40 (UNC )
Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): RES: 51 40 3e 61 55 40 31 
00 00 00 00
Apr  2 12:31:34 kendra kernel: (ada0:ahcich0:0:0:0): Error 5, Retries exhausted
Apr  2 12:31:34 kendra kernel: GEOM_ELI: g_eli_read_done() failed 
gpt/dpool-ada0.eli[READ(offset=414970949120, length=24576)]

However the issue doesn't seem to be (easily) reproducible
and could be unrelated.

I also tried to test camdd, but didn't get it to work.
Some failed attempts:

[fk@kendra ~]$ sudo camdd -i pass=da0,bs=65536 -o file=blafsel.img
(pass2:umass-sim0:0:0:0): READ(6). CDB: 08 00 00 00 80 00 
(pass2:umass-sim0:0:0:0): CAM status: CCB request completed with an error
13 bytes read from pass2
13 bytes written to blafsel.img
20.3203 seconds elapsed
0.00 MB/sec
[fk@kendra ~]$ sudo hd blafsel.img 
  55 53 42 53 d9 02 00 00  00 00 01 00 01   |USBS.|
000d
[fk@kendra ~]$ sudo dd if=/dev/da0 bs=1k count=1  | hd | head -n 1
1+0 records in
1+0 records out
1024 bytes transferred in 0.000603 secs (1697756 bytes/sec)
  fc 31 c0 8e c0 8e d8 8e  d0 bc 00 0e be 1a 7c bf  |.1|.|

Trying the block size suggested in the manual result in:

[fk@kendra ~]$ sudo camdd -i pass=da0,bs=1M -o file=blafsel.img
camdd: camdd_pass_run: error sending CAMIOQUEUE ioctl to pass2: Invalid argument
camdd: camdd_pass_run: CCB address is 0x80250e420: Invalid argument
0 bytes read from pass2
0 bytes written to blafsel.img
0.0007 seconds elapsed
0.00 MB/sec

Apr  5 19:08:20 kendra kernel: (pass2:umass-sim0:0:0:0): passmemsetup: data 
length 1048576 > max allowed 65536 bytes

Fabian


pgpzmTviVSYQN.pgp
Description: OpenPGP digital signature

Re: Early use of log() does not end up in kernel msg buffer

Re: Early use of log() does not end up in kernel msg buffer

Re: Nothing can boot anymore - video issues

Re: panic: object has cached pages on recent HEAD

Re: async pass(4) patches available

Re: Early use of log() does not end up in kernel msg buffer

Re: Early use of log() does not end up in kernel msg buffer

panic: object has cached pages on recent HEAD

Re: Nothing can boot anymore - video issues

Re: Is a high witness refcount indicative of a missing unlock?

Re: Early use of log() does not end up in kernel msg buffer

Re: How to hotplug pci/e devices in freeBSD? (Or How to remove and rescan/re-enumerate pci device?)

Re: SSE in libthr

Re: Nothing can boot anymore - video issues

Re: [RFC] Add "GELI Passphrase:" prompt to boot loader

Re: [RFC] Add "GELI Passphrase:" prompt to boot loader

Re: [RFC] Add "GELI Passphrase:" prompt to boot loader

Re: [RFC] Add "GELI Passphrase:" prompt to boot loader

[RFC] Add "GELI Passphrase:" prompt to boot loader

Re: async pass(4) patches available

20 matches

Site Navigation

Mail list logo

Footer information