Re: wired memory leak at r298785

2016-05-03 Thread Mark Johnston 
On Tue, May 03, 2016 at 08:20:46PM +0200, Trond Endrestøl wrote:
> On Tue, 3 May 2016 08:27-0600, Scott Long wrote:
> > > On May 3, 2016, at 12:20 AM, Mark Johnston  wrote:
> > > This was causing problems on one of my amd64 systems, so it's not
> > > specific to powerpc64. It turns out to be due to r298004: the CCB
> > > allocated in cam_periph_devctl_notify() never gets freed. The patch
> > > below seems to fix it.
> > 
> > Thanks Mark, that looks like the right fix.  I’ll put it in today.
> > 
> > Scott
> 
> A few of my stable/10 systems simple froze due to this bug. Would it 
> be possible for the kernel to detect when it's running low on (kernel) 
> memory, or when it's completely out of (kernel) memory, and call on 
> panic() only to limp away for a day or so before rebooting again?

I don't know of a mechanism in the kernel that would let you do this.
The closest thing I can think of would be a cron job that periodically
checks the amount of leaked memory with

  vmstat -m | awk '/CAM CCB/{print $(NF - 3)}'

and triggers a reboot once that value rises above some threshold.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot with floppy enabled doesn't.....

2016-05-03 Thread John Baldwin 
On Tuesday, May 03, 2016 10:20:21 PM Joel Dahl wrote:
> On Tue, May 03, 2016 at 12:58:15PM -0700, John Baldwin wrote:
> > On Tuesday, May 03, 2016 03:37:27 PM Michael Butler wrote:
> > > On 05/03/16 11:21, Larry Rosenman wrote:
> > > > On 2016-05-03 05:49, Joel Dahl wrote:
> > > >> On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:
> > > >>> On a current -CURRENT if my Floppy disk controller and device are
> > > >>> ENABLED, we do NOT pass mount root, and the floppy disk
> > > >>> light is ON.
> > > >>
> > > >> Just a "me too". But this is with VMware Fusion. If I disable the
> > > >> floppy from
> > > >> BIOS, the virtual machine boots. If I leave it enabled, it hangs.
> > > > Thanks for posting that I'm not the only one, and it's not flakey 
> > > > hardware.
> > > > 
> > > 
> > > I have an, otherwise extremely reliable but ancient, Intel TR440BXA
> > > motherboard doing this :-(
> > > 
> > > What drove me mad for a while is that I have an identical machine, with
> > > exception of 10k RPM SCSI disks, which doesn't hang. I simply optioned
> > > out "device fdc" and it's behaved ever since,
> > 
> > Larry wasn't able to get into DDB when his box hung, are either of you able
> > to get into DDB when it hangs?
> 
> Um, ctrl-alt-backspace doesn't work for me, but ctrl-alt-esc does.
> 
> I uploaded a few screenshots here: https://www.vnode.se/files/freebsd/

Thanks.  It seems like the fdc worker thread isn't there and GEOM is stuck
waiting for that thread to do something (well waiting for the commands
that thread handles to be executed).

First step would be just add a 'panic' to fdc_start_worker() in fdc.c at
the end to make sure it is getting called.  (And when it drops you into ddb
you should be able to see the fdc0 kproc in 'ps' output).

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

Re: boot with floppy enabled doesn't.....

2016-05-03 Thread Michael Butler 
On 05/03/16 15:58, John Baldwin wrote:
> On Tuesday, May 03, 2016 03:37:27 PM Michael Butler wrote:
>> On 05/03/16 11:21, Larry Rosenman wrote:
>>> On 2016-05-03 05:49, Joel Dahl wrote:
 On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:
> On a current -CURRENT if my Floppy disk controller and device are
> ENABLED, we do NOT pass mount root, and the floppy disk
> light is ON.

 Just a "me too". But this is with VMware Fusion. If I disable the
 floppy from
 BIOS, the virtual machine boots. If I leave it enabled, it hangs.
>>> Thanks for posting that I'm not the only one, and it's not flakey hardware.
>>>
>>
>> I have an, otherwise extremely reliable but ancient, Intel TR440BXA
>> motherboard doing this :-(
>>
>> What drove me mad for a while is that I have an identical machine, with
>> exception of 10k RPM SCSI disks, which doesn't hang. I simply optioned
>> out "device fdc" and it's behaved ever since,
> 
> Larry wasn't able to get into DDB when his box hung, are either of you able
> to get into DDB when it hangs?

Unfortunately, mine is sitting in a remote data-centre. The best I could
do was get the remote hands to show me the boot messages via photo, i.e.
it hung immediately after the "mounting root from .." text, the same as
described by others,

imb


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

Re: boot with floppy enabled doesn't.....

2016-05-03 Thread Joel Dahl 
On Tue, May 03, 2016 at 12:58:15PM -0700, John Baldwin wrote:
> On Tuesday, May 03, 2016 03:37:27 PM Michael Butler wrote:
> > On 05/03/16 11:21, Larry Rosenman wrote:
> > > On 2016-05-03 05:49, Joel Dahl wrote:
> > >> On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:
> > >>> On a current -CURRENT if my Floppy disk controller and device are
> > >>> ENABLED, we do NOT pass mount root, and the floppy disk
> > >>> light is ON.
> > >>
> > >> Just a "me too". But this is with VMware Fusion. If I disable the
> > >> floppy from
> > >> BIOS, the virtual machine boots. If I leave it enabled, it hangs.
> > > Thanks for posting that I'm not the only one, and it's not flakey 
> > > hardware.
> > > 
> > 
> > I have an, otherwise extremely reliable but ancient, Intel TR440BXA
> > motherboard doing this :-(
> > 
> > What drove me mad for a while is that I have an identical machine, with
> > exception of 10k RPM SCSI disks, which doesn't hang. I simply optioned
> > out "device fdc" and it's behaved ever since,
> 
> Larry wasn't able to get into DDB when his box hung, are either of you able
> to get into DDB when it hangs?

Um, ctrl-alt-backspace doesn't work for me, but ctrl-alt-esc does.

I uploaded a few screenshots here: https://www.vnode.se/files/freebsd/

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

Re: Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

2016-05-03 Thread Jung-uk Kim 
On 05/ 3/16 03:55 PM, John Baldwin wrote:
> On Tuesday, May 03, 2016 12:18:22 AM Mark Millard wrote:
>> On 2016-May-2, at 11:04 PM, Mark Millard  wrote:
>>
>>> I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS 
>>> X to -r298793. This was via buildworld buildkernel then installing them, 
>>> like normal for me.
>>>
>>> The result is about 10-11 minutes after starting to boot FreeBSD shuts down 
>>> with (for example):
>>> (the root login line is just to give an idea of the time frame after the 
>>> login prompt)
>>>
 May  2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0
 May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
 fixed event - PM_Timer (0), disabling (20160422/evevent-323)
 May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
 fixed event - RealTimeClock (4), disabling (20160422/evevent-323)
 May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
 GPE 01, disabling event (20160422/evgpe-834)
 May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
 GPE 03, disabling event (20160422/evgpe-834)
 May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
 GPE 04, disabling event (20160422/evgpe-834)
 May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
 GPE 05, disabling event (20160422/evgpe-834)
 May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
 GPE 06, disabling event (20160422/evgpe-834)
 May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
 GPE 07, disabling event (20160422/evgpe-834)
 May  2 22:01:45 FreeBSDx64 kernel: .
 May  2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down
 May  2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM
 May  2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting
 May  2 22:01:46 FreeBSDx64 kernel: .
 May  2 22:01:47 FreeBSDx64 kernel: , 576.
 May  2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15
>>>
>>>
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>>
>> I had duplicated the directory tree that held the virtual machine on Mac OS 
>> X before booting FreeBSD in VirtualBox to install the kernel and world. This 
>> was running -r297769.
>>
>> When I boot the -r297769 11.0 virtual machine instead of the -r298793 one 
>> the problem does not occur.
>>
>> Both -r297769 and -r298793 11.0-'s have /usr/ports -r414369 and the ports 
>> were built before the -r298793 buildworld/buildkernel was done. And both 
>> -r297769 and -r298793 11.0's are running under the same vintage of Virtual 
>> Box (5.0.20 r106931).
>>
>> So what is different is just the FreeBSD vintage.
>>
>> 11.0's -r297769 virtual machine does contain the buildworld/buildkernel 
>> /usr/obj material for -r298793, it is just not installed.
> 
> This was already covered in an earlier thread.  r298838 has the fix /
> workaround.

FYI, the upstream was notified and a patch is available from here:

https://github.com/acpica/acpica/pull/138

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature

Re: boot with floppy enabled doesn't.....

2016-05-03 Thread Larry Rosenman 

On 2016-05-03 14:54, Joel Dahl wrote:

On Tue, May 03, 2016 at 10:21:25AM -0500, Larry Rosenman wrote:

On 2016-05-03 05:49, Joel Dahl wrote:
> On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:
>> On a current -CURRENT if my Floppy disk controller and device are
>> ENABLED, we do NOT pass mount root, and the floppy disk
>> light is ON.
>
> Just a "me too". But this is with VMware Fusion. If I disable the
> floppy from
> BIOS, the virtual machine boots. If I leave it enabled, it hangs.
Thanks for posting that I'm not the only one, and it's not flakey
hardware.


I forgot to mention that -CURRENT from three weeks ago works. I rebuilt
-CURRENT today and now it hangs.
As I said in my Original post, April 18 works, not sure when it broke 
after that :(


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

2016-05-03 Thread John Baldwin 
On Tuesday, May 03, 2016 12:18:22 AM Mark Millard wrote:
> On 2016-May-2, at 11:04 PM, Mark Millard  wrote:
> 
> > I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS 
> > X to -r298793. This was via buildworld buildkernel then installing them, 
> > like normal for me.
> > 
> > The result is about 10-11 minutes after starting to boot FreeBSD shuts down 
> > with (for example):
> > (the root login line is just to give an idea of the time frame after the 
> > login prompt)
> > 
> >> May  2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
> >> fixed event - PM_Timer (0), disabling (20160422/evevent-323)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
> >> fixed event - RealTimeClock (4), disabling (20160422/evevent-323)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 01, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 03, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 04, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 05, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 06, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for 
> >> GPE 07, disabling event (20160422/evgpe-834)
> >> May  2 22:01:45 FreeBSDx64 kernel: .
> >> May  2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down
> >> May  2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM
> >> May  2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting
> >> May  2 22:01:46 FreeBSDx64 kernel: .
> >> May  2 22:01:47 FreeBSDx64 kernel: , 576.
> >> May  2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15
> > 
> > 
> > ===
> > Mark Millard
> > markmi at dsl-only.net
> 
> I had duplicated the directory tree that held the virtual machine on Mac OS X 
> before booting FreeBSD in VirtualBox to install the kernel and world. This 
> was running -r297769.
> 
> When I boot the -r297769 11.0 virtual machine instead of the -r298793 one the 
> problem does not occur.
> 
> Both -r297769 and -r298793 11.0-'s have /usr/ports -r414369 and the ports 
> were built before the -r298793 buildworld/buildkernel was done. And both 
> -r297769 and -r298793 11.0's are running under the same vintage of Virtual 
> Box (5.0.20 r106931).
> 
> So what is different is just the FreeBSD vintage.
> 
> 11.0's -r297769 virtual machine does contain the buildworld/buildkernel 
> /usr/obj material for -r298793, it is just not installed.

This was already covered in an earlier thread.  r298838 has the fix /
workaround.

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

Re: boot with floppy enabled doesn't.....

2016-05-03 Thread John Baldwin 
On Tuesday, May 03, 2016 03:37:27 PM Michael Butler wrote:
> On 05/03/16 11:21, Larry Rosenman wrote:
> > On 2016-05-03 05:49, Joel Dahl wrote:
> >> On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:
> >>> On a current -CURRENT if my Floppy disk controller and device are
> >>> ENABLED, we do NOT pass mount root, and the floppy disk
> >>> light is ON.
> >>
> >> Just a "me too". But this is with VMware Fusion. If I disable the
> >> floppy from
> >> BIOS, the virtual machine boots. If I leave it enabled, it hangs.
> > Thanks for posting that I'm not the only one, and it's not flakey hardware.
> > 
> 
> I have an, otherwise extremely reliable but ancient, Intel TR440BXA
> motherboard doing this :-(
> 
> What drove me mad for a while is that I have an identical machine, with
> exception of 10k RPM SCSI disks, which doesn't hang. I simply optioned
> out "device fdc" and it's behaved ever since,

Larry wasn't able to get into DDB when his box hung, are either of you able
to get into DDB when it hangs?

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

Re: boot with floppy enabled doesn't.....

2016-05-03 Thread Joel Dahl 
On Tue, May 03, 2016 at 10:21:25AM -0500, Larry Rosenman wrote:
> On 2016-05-03 05:49, Joel Dahl wrote:
> > On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:
> >> On a current -CURRENT if my Floppy disk controller and device are
> >> ENABLED, we do NOT pass mount root, and the floppy disk
> >> light is ON.
> > 
> > Just a "me too". But this is with VMware Fusion. If I disable the 
> > floppy from
> > BIOS, the virtual machine boots. If I leave it enabled, it hangs.
> Thanks for posting that I'm not the only one, and it's not flakey 
> hardware.

I forgot to mention that -CURRENT from three weeks ago works. I rebuilt
-CURRENT today and now it hangs.

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

Re: boot with floppy enabled doesn't.....

2016-05-03 Thread Michael Butler 
On 05/03/16 11:21, Larry Rosenman wrote:
> On 2016-05-03 05:49, Joel Dahl wrote:
>> On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:
>>> On a current -CURRENT if my Floppy disk controller and device are
>>> ENABLED, we do NOT pass mount root, and the floppy disk
>>> light is ON.
>>
>> Just a "me too". But this is with VMware Fusion. If I disable the
>> floppy from
>> BIOS, the virtual machine boots. If I leave it enabled, it hangs.
> Thanks for posting that I'm not the only one, and it's not flakey hardware.
> 

I have an, otherwise extremely reliable but ancient, Intel TR440BXA
motherboard doing this :-(

What drove me mad for a while is that I have an identical machine, with
exception of 10k RPM SCSI disks, which doesn't hang. I simply optioned
out "device fdc" and it's behaved ever since,

imb

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

Re: wired memory leak at r298785

2016-05-03 Thread Trond Endrestøl 
On Tue, 3 May 2016 08:27-0600, Scott Long wrote:

> 
> > On May 3, 2016, at 12:20 AM, Mark Johnston  wrote:
> > 
> > On Mon, May 02, 2016 at 08:55:58PM -0400, Steve Wills wrote:
> >> Hi,
> >> 
> >> On 05/ 2/16 09:32 AM, Steve Wills wrote:
> >>> Hi,
> >>> 
> >>> Just did my monthly update and r298785 seems to be leaking wired memory
> >>> rather rapidly. My system has 8gb of RAM and the amount of wired memory
> >>> just goes up and up continuously. It takes about 12 hours before it
> >>> exhausts all the RAM and sort of locks up (though shutdown still works).
> >>> 
> >>> I also made one other change to the system at the same time as updating,
> >>> which was to add another disk and configure it using ZFS. Perhaps this
> >>> is a ZFS on PowerPC64 issue? My amd64 box running the same rev of
> >>> CURRENT doesn't have the issue.
> >>> 
> >> 
> >> I've rebooted the box and started repeatedly logging the output of
> >> vmstat -m. It seems to show CAM CCB using a lot of memory and growing
> >> rather rapidly. For example, here's a few lines of diff output:
> >> 
> >> - CAM CCB 91418 182836K - 187149 2048
> >> + CAM CCB 447070 894140K - 900292 2048
> >> 
> >> from two samples that are 60 minutes apart.
> >> 
> >> The box is isn't terribly busy, it's just running the monitoring daemons
> >> running (snmpd, collectd), whatever web requests are hitting it (very
> >> few if any), this logging process, and my shell, etc.
> > 
> > This was causing problems on one of my amd64 systems, so it's not
> > specific to powerpc64. It turns out to be due to r298004: the CCB
> > allocated in cam_periph_devctl_notify() never gets freed. The patch
> > below seems to fix it.
> 
> Thanks Mark, that looks like the right fix.  I’ll put it in today.
> 
> Scott

A few of my stable/10 systems simple froze due to this bug. Would it 
be possible for the kernel to detect when it's running low on (kernel) 
memory, or when it's completely out of (kernel) memory, and call on 
panic() only to limp away for a day or so before rebooting again?

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r298143: something wrong with autofs?

2016-05-03 Thread O. Hartmann 
Am Sun, 17 Apr 2016 12:39:44 +0200
Edward Tomasz Napierała  schrieb:

> On 0417T1057, O. Hartmann wrote:
> > 
> > Running FreeBSD 11.0-CURRENT #32 r298143: Sun Apr 17 09:48:26 CEST 2016  
> > amd64, on
> > both server and client, reveals today that AUTOFS seems not to work. Did 
> > something
> > changed unnoticed?
> > 
> > I realized, that no exported filesystem is bound so far. On the server's 
> > side, all  
> 
> "Bound"?

... means: the cleint does not mount/bind the NFS exported filesystem anymore.

> 
> > daemons necessary are configured as they were before in a working state and 
> > as I can
> > see so far, they are up and running and also listening to their 
> > sockets/IPs.   
> 
> Could you describe in more detail what are you seeing?  Also, the usual autofs
> debugging technique ("pkill automountd && while :; do automountd -d; done") 
> might
> sched some light.

Well, I see nothing! That is my problem. I setup several NFSv4 exported 
filesystems which
were mounted on demand via autofs - that workd. Since I do not use/need those 
filesystems
on a dailt basis, I realized too late that in the meanwhile those filesystems 
are not
present on the client (autofs) anymore. I'm not aware of having changed 
anything in the
configuration and I didn't receive any heads-ups that essential changes had 
been made.

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



pgpawDVp_f9k8.pgp
Description: OpenPGP digital signature

Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

2016-05-03 Thread Guillermo Garc?a Rojas 
Hi,

I'm having the same issue with downloaded ISO from Monday May 2nd under 
VirtualBox same version.

It happens at 10 minutes after system is started.

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

Re: CAM I/O Scheduler (was Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd))

2016-05-03 Thread Warner Losh 

> On May 3, 2016, at 8:05 AM, Warren Block  wrote:
> 
> On Tue, 3 May 2016, Johan Hendriks wrote:
> 
>> Op 02/05/16 om 02:49 schreef Warren Block:
>>  CAM I/O Scheduler
>> 
>> Links
>> I/O Scheduling in FreeBSD's CAM Subsystem (PDF) URL:
>> https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf
>> The BSDCan 2015 Talk URL: https://www.youtube.com/watch?v=3WqOLolj5EU
>> 
>> Contact: Warner Losh 
>> 
>> An enhanced CAM I/O scheduler has been committed to the tree. By
>> default, this scheduler implements the old behavior. In addition, an
>> advanced adaptive scheduler is available. Along with the scheduler,
>> SATA disks can now use Queued Trims with devices that support them.
>> Details about the new scheduler are available in the I/O Scheduling 
>> in
>> FreeBSD's CAM Subsystem article (PDF) or from the BSDCan 2015 talk.
>> I updated my source today, but CAM_ADAPTIVE_IOSCHED yields an error about an 
>> unknown option.
>> If I use CAM_NETFLIX_IOSCHED the kernel compiles.
>> Is the name CAM_NETFLIX_IOSCHED changing to CAM_ADAPTIVE_IOSCHED?
> 
> That is my understanding, yes.  Warner can certainly explain it better than I 
> can, so CCed.

I’m changing it to CAM_ADAPTIVE_IOSCHED, but haven’t yet due to “work flow” 
issues
in making sure that the Netflix repo doesn’t see a large number of conflicts 
when this
is merged. I’ll see if I can finish today, but CAM_NETFLIX_IOSCHED is the old 
name.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: boot with floppy enabled doesn't.....

2016-05-03 Thread Larry Rosenman 

On 2016-05-03 05:49, Joel Dahl wrote:

On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:

On a current -CURRENT if my Floppy disk controller and device are
ENABLED, we do NOT pass mount root, and the floppy disk
light is ON.


Just a "me too". But this is with VMware Fusion. If I disable the 
floppy from

BIOS, the virtual machine boots. If I leave it enabled, it hangs.
Thanks for posting that I'm not the only one, and it's not flakey 
hardware.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: wired memory leak at r298785

2016-05-03 Thread Scott Long 

> On May 3, 2016, at 12:20 AM, Mark Johnston  wrote:
> 
> On Mon, May 02, 2016 at 08:55:58PM -0400, Steve Wills wrote:
>> Hi,
>> 
>> On 05/ 2/16 09:32 AM, Steve Wills wrote:
>>> Hi,
>>> 
>>> Just did my monthly update and r298785 seems to be leaking wired memory
>>> rather rapidly. My system has 8gb of RAM and the amount of wired memory
>>> just goes up and up continuously. It takes about 12 hours before it
>>> exhausts all the RAM and sort of locks up (though shutdown still works).
>>> 
>>> I also made one other change to the system at the same time as updating,
>>> which was to add another disk and configure it using ZFS. Perhaps this
>>> is a ZFS on PowerPC64 issue? My amd64 box running the same rev of
>>> CURRENT doesn't have the issue.
>>> 
>> 
>> I've rebooted the box and started repeatedly logging the output of
>> vmstat -m. It seems to show CAM CCB using a lot of memory and growing
>> rather rapidly. For example, here's a few lines of diff output:
>> 
>> - CAM CCB 91418 182836K - 187149 2048
>> + CAM CCB 447070 894140K - 900292 2048
>> 
>> from two samples that are 60 minutes apart.
>> 
>> The box is isn't terribly busy, it's just running the monitoring daemons
>> running (snmpd, collectd), whatever web requests are hitting it (very
>> few if any), this logging process, and my shell, etc.
> 
> This was causing problems on one of my amd64 systems, so it's not
> specific to powerpc64. It turns out to be due to r298004: the CCB
> allocated in cam_periph_devctl_notify() never gets freed. The patch
> below seems to fix it.

Thanks Mark, that looks like the right fix.  I’ll put it in today.

Scott

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

CAM I/O Scheduler (was Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd))

2016-05-03 Thread Warren Block 

On Tue, 3 May 2016, Johan Hendriks wrote:


Op 02/05/16 om 02:49 schreef Warren Block:
  CAM I/O Scheduler

     Links
     I/O Scheduling in FreeBSD's CAM Subsystem (PDF) URL:
     https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf
     The BSDCan 2015 Talk URL: https://www.youtube.com/watch?v=3WqOLolj5EU

     Contact: Warner Losh 

     An enhanced CAM I/O scheduler has been committed to the tree. By
     default, this scheduler implements the old behavior. In addition, an
     advanced adaptive scheduler is available. Along with the scheduler,
     SATA disks can now use Queued Trims with devices that support them.
     Details about the new scheduler are available in the I/O Scheduling in
     FreeBSD's CAM Subsystem article (PDF) or from the BSDCan 2015 talk.

I updated my source today, but CAM_ADAPTIVE_IOSCHED yields an error about an 
unknown option.
If I use CAM_NETFLIX_IOSCHED the kernel compiles.
Is the name CAM_NETFLIX_IOSCHED changing to CAM_ADAPTIVE_IOSCHED?


That is my understanding, yes.  Warner can certainly explain it better 
than I can, so CCed.


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

Re: Kernel panic from recent build

2016-05-03 Thread Eric van Gyzen 
I intend it as a workaround to be committed, not as debugging.

Eric

On 05/02/2016 18:51, Ryan Stone wrote:
> Do we need this debug output?  It's quite clear from the acpidump output
> that there is an entry for APIC ID 0 in memory domain 0 and memory
> domain 1.  Not sure if that's legal by the spec.
> 
> On Mon, May 2, 2016 at 6:17 PM, Eric van Gyzen  > wrote:
> 
> On 05/02/2016 16:14, Bill O'Hanlon wrote:
> > On Mon, May 2, 2016 at 3:55 PM, John Baldwin  > wrote:
> >
> >> On Monday, May 02, 2016 01:35:54 PM Bill O'Hanlon wrote:
> >>> ​
> >>>  IMG_20160502_130335.jpg
> >>> <
> >> 
> https://drive.google.com/file/d/1dtJxTwWXfhXVUUtn1Vvpzh3laJt7AILyCg/view?usp=drive_web
> >>> ​
> >>> I'm getting the following panic from a recent (May 2, 2016) build.
> >>> panic: Duplicate local APIC ID 0
> >>>
> >>> The system is a Dell Precision T5500 with generic factory BIOS 
> settings.
> >>> It has run previous builds without event for several years.
> >>>
> >>> I'm attaching a link to a photo of the screen for added details.
> >> Try setting 'hint.srat.0.disabled=1' at the loader prompt and then grab
> >> the output of 'acpidump -t' on your next boot.  The SRAT table used by
> >> the NUMA code appears to be corrupted by your BIOS.
> >>
> >> --
> >> John Baldwin
> >>
> >
> > That allowed me to boot.  I'm attaching the output of 'acpidump -t'.
> > Thanks!
> 
> Bill,
> 
> Do you have the time and interest to test this patch?  If so, remove the
> line that you added to /boot/loader.conf so the patch actually gets
> exercised.
> 
> Eric
> 
> 
> diff --git a/sys/x86/acpica/srat.c b/sys/x86/acpica/srat.c
> index 85f1922..1d0f73d 100644
> --- a/sys/x86/acpica/srat.c
> +++ b/sys/x86/acpica/srat.c
> @@ -201,8 +201,12 @@ srat_parse_entry(ACPI_SUBTABLE_HEADER *entry, void
> *arg)
>  "enabled" : "disabled");
>  if (!(cpu->Flags & ACPI_SRAT_CPU_ENABLED))
>  break;
> -KASSERT(!cpus[cpu->ApicId].enabled,
> -("Duplicate local APIC ID %u", cpu->ApicId));
> +if (cpus[cpu->ApicId].enabled) {
> +printf("SRAT: Duplicate local APIC ID %u\n",
> +cpu->ApicId);
> +*(int *)arg = ENXIO;
> +break;
> +}
>  cpus[cpu->ApicId].domain = domain;
>  cpus[cpu->ApicId].enabled = 1;
>  break;
> 
> ___
> freebsd-current@freebsd.org 
> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org
> "
> 
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd)

2016-05-03 Thread Johan Hendriks 


Op 02/05/16 om 02:49 schreef Warren Block:
> CAM I/O Scheduler
>
>Links
>I/O Scheduling in FreeBSD's CAM Subsystem (PDF) URL:
>https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf
>The BSDCan 2015 Talk URL: https://www.youtube.com/watch?v=3WqOLolj5EU
>
>Contact: Warner Losh 
>
>An enhanced CAM I/O scheduler has been committed to the tree. By
>default, this scheduler implements the old behavior. In addition, an
>advanced adaptive scheduler is available. Along with the scheduler,
>SATA disks can now use Queued Trims with devices that support them.
>Details about the new scheduler are available in the I/O Scheduling in
>FreeBSD's CAM Subsystem article (PDF) or from the BSDCan 2015 talk.
>
>The adaptive I/O scheduler is disabled by default, but can be enabled
>with options CAM_ADAPTIVE_IOSCHED in the kernel config file. This
>scheduler allows favoring reads over writes (or vice versa),
>controlling the IOPs, bandwidth, or concurrent operations (read,
> write,
>trim), and permits the selection of static or dynamic control of these
>operations. In addition, a number of statistics are collected for
> drive
>operations that are published via sysctl. One advanced use for the
>adaptive I/O scheduler is to compensate for deficiencies in some
>consumer-grade SSDs. These SSDs exhibit a performance cliff if too
> much
>data is written to them too quickly due to internal garbage
> collection.
>Without the I/O scheduler, read and write performance drop
>substantially once garbage collection kicks in. The adaptive I/O
>scheduler can be configured to monitor read latency. As read latency
>climbs, the I/O scheduler reduces the allowed write throughput, within
>limits, to attempt to maximize read performance. A simple use of the
>adaptive I/O scheduler would be to limit write bandwidth, IOPs or
>concurrent operations statically.
>
>Future work on the I/O scheduler will be coupled with improvements to
>the upper layers. The upper layers will be enhanced to communicate how
>urgent I/O requests are. The I/O scheduler will inform the upper
> layers
>of how full the I/O queues are, so less urgent I/O can be submitted to
>the lower layers as quickly as possible without overwhelming the lower
>layers or starving other devices of requests.
>
>This project was sponsored by Netflix.
>  __
I updated my source today, but CAM_ADAPTIVE_IOSCHED yields an error
about an unknown option.
If I use CAM_NETFLIX_IOSCHED the kernel compiles.
Is the name CAM_NETFLIX_IOSCHED changing to CAM_ADAPTIVE_IOSCHED?

regards
Johan

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

Re: boot with floppy enabled doesn't.....

2016-05-03 Thread Joel Dahl 
On Sat, Apr 30, 2016 at 10:36:53PM -0500, Larry Rosenman wrote:
> On a current -CURRENT if my Floppy disk controller and device are 
> ENABLED, we do NOT pass mount root, and the floppy disk
> light is ON.

Just a "me too". But this is with VMware Fusion. If I disable the floppy from
BIOS, the virtual machine boots. If I leave it enabled, it hangs.

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

FreeBSD_HEAD_i386 - Build #3035 - Fixed

2016-05-03 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3035 - Fixed:

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

Change summaries:

298974 by sephe:
tcp/lro: Refactor the active list operation.

Ease more work concerning active list, e.g. hash table etc.

Reviewed by:gallatin, rrs (earlier version)
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6137

298971 by royger:
xen/i386: enable the platform hypercall for i386

Not sure why the platform hypercall was disabled on i386, just enable it in
order to fix compilation of the PV timer on i386.

Sponsored by: Citrix Systems R

298956 by sephe:
kern: Add phashinit_flags(), which allows malloc(M_NOWAIT)

It will be used for the upcoming LRO hash table initialization.
And probably will be useful in other cases, when M_WAITOK can't
be used.

Reviewed by:jhb, kib
Sponsored by:   Microsoft OSTC
Differential Revision:  https://reviews.freebsd.org/D6138

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

Re: boot fails "Can't stat /dev/da0a: No such file or directory"

2016-05-03 Thread Edward Tomasz Napierała 
On 0503T1922, Graham Menhennitt wrote:
> On 3/05/2016 06:42 PM, Edward Tomasz Napierała wrote:
> > On 0502T0643, Graham Menhennitt wrote:
> >> On 30/04/2016 06:53 PM, Graham Menhennitt wrote:
> >>> Hi all,
> >>>
> >>> I have a USB disk that I use for backup. Up till now, it's mounted
> >>> without any problems at boot time. After updating to -current as of
> >>> yesterday, it doesn't mount and causes the boot to fail.
> >>>
> >>> My /etc/fstab looks like:
> >>>
> >>> # DeviceMountpointFStypeOptionsDumpPass#
> >>>
> >>> /dev/ada0s1a/ufsrw11
> >>> /dev/ada0s1bnoneswapsw00
> >>> /dev/da0a/backupufsrw,late11
> >>>
> >>>
> >>> I tried adding the "late" to fix the problem, but it doesn't help.
> >>>
> >>> The error message is:
> >>>
> >>> /dev/ada0s1a: clean...
> >>> Can't stat /dev/da0a: No such file or directory
> >>> Unknown error; help!
> >>> ERROR: ABORTING BOOT (sending SIGTERM to parent)!
> >>>
> >>>
> >>> (hand transcribed - maybe typos)
> >>>
> >>> Can anybody help, please.
> >>>
> >>> Thanks,
> >>> Graham
> >> Sorry, I forgot to mention...
> >>
> >> I commented out that line from fstab which allows the boot to complete.
> >> I can then manually mount it without any problems. It looks like the
> >> device doesn't get created early enough.
> > Have you run mergemaster after upgrade?  In particular, do you have
> > the current version of /etc/rc.d/mountcritlocal?
> >
> Thanks for replying, Edward. Yes I've installed that file. The delay
> that Dave told me about has fixed the problem.

Still, it would be nice if this worked by default.  The updated
mountcritlocal script should wait for USB to release root tokens
if the mount initially fails,

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

Re: boot fails "Can't stat /dev/da0a: No such file or directory"

2016-05-03 Thread Graham Menhennitt 
On 3/05/2016 06:42 PM, Edward Tomasz Napierała wrote:
> On 0502T0643, Graham Menhennitt wrote:
>> On 30/04/2016 06:53 PM, Graham Menhennitt wrote:
>>> Hi all,
>>>
>>> I have a USB disk that I use for backup. Up till now, it's mounted
>>> without any problems at boot time. After updating to -current as of
>>> yesterday, it doesn't mount and causes the boot to fail.
>>>
>>> My /etc/fstab looks like:
>>>
>>> # DeviceMountpointFStypeOptionsDumpPass#
>>>
>>> /dev/ada0s1a/ufsrw11
>>> /dev/ada0s1bnoneswapsw00
>>> /dev/da0a/backupufsrw,late11
>>>
>>>
>>> I tried adding the "late" to fix the problem, but it doesn't help.
>>>
>>> The error message is:
>>>
>>> /dev/ada0s1a: clean...
>>> Can't stat /dev/da0a: No such file or directory
>>> Unknown error; help!
>>> ERROR: ABORTING BOOT (sending SIGTERM to parent)!
>>>
>>>
>>> (hand transcribed - maybe typos)
>>>
>>> Can anybody help, please.
>>>
>>> Thanks,
>>> Graham
>> Sorry, I forgot to mention...
>>
>> I commented out that line from fstab which allows the boot to complete.
>> I can then manually mount it without any problems. It looks like the
>> device doesn't get created early enough.
> Have you run mergemaster after upgrade?  In particular, do you have
> the current version of /etc/rc.d/mountcritlocal?
>
Thanks for replying, Edward. Yes I've installed that file. The delay
that Dave told me about has fixed the problem.

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

Re: boot fails "Can't stat /dev/da0a: No such file or directory"

2016-05-03 Thread Edward Tomasz Napierała 
On 0502T0643, Graham Menhennitt wrote:
> On 30/04/2016 06:53 PM, Graham Menhennitt wrote:
> > Hi all,
> >
> > I have a USB disk that I use for backup. Up till now, it's mounted
> > without any problems at boot time. After updating to -current as of
> > yesterday, it doesn't mount and causes the boot to fail.
> >
> > My /etc/fstab looks like:
> >
> > # DeviceMountpointFStypeOptionsDumpPass#
> >
> > /dev/ada0s1a/ufsrw11
> > /dev/ada0s1bnoneswapsw00
> > /dev/da0a/backupufsrw,late11
> >
> >
> > I tried adding the "late" to fix the problem, but it doesn't help.
> >
> > The error message is:
> >
> > /dev/ada0s1a: clean...
> > Can't stat /dev/da0a: No such file or directory
> > Unknown error; help!
> > ERROR: ABORTING BOOT (sending SIGTERM to parent)!
> >
> >
> > (hand transcribed - maybe typos)
> >
> > Can anybody help, please.
> >
> > Thanks,
> > Graham
> Sorry, I forgot to mention...
> 
> I commented out that line from fstab which allows the boot to complete.
> I can then manually mount it without any problems. It looks like the
> device doesn't get created early enough.

Have you run mergemaster after upgrade?  In particular, do you have
the current version of /etc/rc.d/mountcritlocal?

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

FreeBSD_HEAD_amd64_gcc - Build #1212 - Fixed

2016-05-03 Thread jenkins-admin 
FreeBSD_HEAD_amd64_gcc - Build #1212 - Fixed:

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

Change summaries:

298955 by pfg:
sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

298954 by adrian:
[bwn] update bwn_dummy_transmission().

This is based on the b43 code.  It'll be used by the upcoming 11n phy.

Obtained from:  Linux b43 (concept)

298953 by adrian:
[bwn] add PHY types for later PHYs.

Obtained from:  Linux b43

298952 by adrian:
[bwn] migrate bwn_dummy_transmission() back to main, as it'll be used by other 
PHYs.

The Linux b43 driver uses this in other PHYs besides the g PHY.

298951 by jhb:
Revert bus_get_cpus() for now.

I really thought I had run this through the tinderbox before committing,
but many places need  ->  for  now.

298950 by jhb:
Fix an off by one error when remapping MSI-X vectors.

pci_remap_msix() can be used to alter the mapping of allocated
MSI-X vectors to the MSI-X table.  The code had an off by one error
when adding the IRQ resources after performing a remap.  This was
fatal for any vectors in the table that used the "last" valid IRQ as
those vectors were assigned a garbage IRQ value.

MFC after:  3 days

298949 by peter:
Change a rounding operation that had missing braces into a roundup2()
macro.  Adjust the buffer clipping code to work as expected.

This prevented a number of machines in the FreeBSD.org cluster from
booting due to "ZFS: i/o error - all block copies unavailable"
after an unclean shutdown.

298948 by adrian:
[bwn] break out the 'g' phy code into a separate source file.

* Break out the 'g' phy code;
* Break out the debugging bits into a separate source file, since
  some debugging prints are done in the phy code;
* Make some more chip methods in if_bwn.c public.

This brings the size of if_bwn.c down to 6,805 lines which is now
approaching managable.

298947 by adrian:
[bhnd] fix more module dependencies.

Submitted by:   Landon Fuller 
Differential Revision:  https://reviews.freebsd.org/D6180

298946 by avos:
bsdinstall: fix static address assignment for protected wireless networks.

Filter out IFCONFIG_PREFIX variable (which may contain WPA keyword)
from ifconfig parameters.

PR: 169199

298945 by tuexen:
Undo a spell fix introduced in r298942, which breaks compilation.

298944 by adrian:
[bwn] break out the LP PHY code into a separate file.

This (and eventually migrating the other PHY code out) is in preparation
for adding the 11n PHY.  No, the 11ac PHY (for the BCM4260 softmac part) isn't
yet open source, so we can't grow that.  Yet.

This trims ~3,700 lines of code from if_bwn.c, bringing it down to a slightly
less crazy sounding 10,446 lines of code.

298943 by adrian:
[bhnd] add module dependencies.

Submitted by:   Landon Fuller 
Differential Revision:  https://reviews.freebsd.org/D6179

298942 by pfg:
netinet/sctp*: minor spelling fixes in comments.

No functional change.

Reviewed by:tuexen

298941 by avos:
net80211: fix MAC address change via SIOCSIFLLADDR ioctl.

Recheck MAC address on SIOCSIFFLAGS; as a result,
'ifconfig wlan0 ether ' can be used after interface startup.

PR: 208933

298940 by pfg:
sys/vm: minor spelling fixes in comments.

No functional change.

298939 by pfg:
dev/ath: minor spelling fixes in comments.

No functional change.

Reviewed by:adrian

298938 by pfg:
Enhance the ddb examine (x) command.

* Change x/a to work similar to gdb.  The content of the memory is
  treated as an address, printed symbolically and the address is advanced.
  This way you can x/a  and then just hit return a bunch
  of times to locate useful data on the stack.

* Add x/p.  The content of the memory is treated as an address and
  printed as hex.

This is based on the similar commit from DragonFlyBSD without the
cosmetic changes.

Relnotes:   yes
Obtained from:  DragonflyBSD (Matthew Dillon)
Reference:  0624d20e86affcd708609cbf9014207537537a72

298937 by adrian:
[asmc] add support for more models and restore keyboard backlight after resume.

This patch adds support for restoring backlight after resume and adds models
Macbook3,1
MacbookAir5,1
MacbookAir5,2

It also incorporates fixes for bug #175260, bug #203610 and bug #203512
so those can be closed if this patch is applied.

PR: kern/209156
PR: kern/175260
PR: kern/203610
PR: kern/203512
Submitted by:   Johannes Lundberg 

298936 by avos:
iwm: fix parameters for iwm_add_channel_band()

It accepts , not
.

Reported by:adrian

298935 by adrian:
[bhnd] add missing bus interface SRC bits, required after the last source 
import.

298934 by royger:
xen/control: improve suspend/resume

Implement several small improvements to

Re: Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

2016-05-03 Thread Mark Millard 
On 2016-May-2, at 11:04 PM, Mark Millard  wrote:

> I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS X 
> to -r298793. This was via buildworld buildkernel then installing them, like 
> normal for me.
> 
> The result is about 10-11 minutes after starting to boot FreeBSD shuts down 
> with (for example):
> (the root login line is just to give an idea of the time frame after the 
> login prompt)
> 
>> May  2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
>> fixed event - PM_Timer (0), disabling (20160422/evevent-323)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for 
>> fixed event - RealTimeClock (4), disabling (20160422/evevent-323)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 01, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 03, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 04, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 05, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 06, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
>> 07, disabling event (20160422/evgpe-834)
>> May  2 22:01:45 FreeBSDx64 kernel: .
>> May  2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down
>> May  2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM
>> May  2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting
>> May  2 22:01:46 FreeBSDx64 kernel: .
>> May  2 22:01:47 FreeBSDx64 kernel: , 576.
>> May  2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net

I had duplicated the directory tree that held the virtual machine on Mac OS X 
before booting FreeBSD in VirtualBox to install the kernel and world. This was 
running -r297769.

When I boot the -r297769 11.0 virtual machine instead of the -r298793 one the 
problem does not occur.

Both -r297769 and -r298793 11.0-'s have /usr/ports -r414369 and the ports were 
built before the -r298793 buildworld/buildkernel was done. And both -r297769 
and -r298793 11.0's are running under the same vintage of Virtual Box (5.0.20 
r106931).

So what is different is just the FreeBSD vintage.

11.0's -r297769 virtual machine does contain the buildworld/buildkernel 
/usr/obj material for -r298793, it is just not installed.

===
Mark Millard
mar...@dsl-only.net

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

Re: wired memory leak at r298785

2016-05-03 Thread Mark Johnston 
On Mon, May 02, 2016 at 08:55:58PM -0400, Steve Wills wrote:
> Hi,
> 
> On 05/ 2/16 09:32 AM, Steve Wills wrote:
> > Hi,
> > 
> > Just did my monthly update and r298785 seems to be leaking wired memory
> > rather rapidly. My system has 8gb of RAM and the amount of wired memory
> > just goes up and up continuously. It takes about 12 hours before it
> > exhausts all the RAM and sort of locks up (though shutdown still works).
> > 
> > I also made one other change to the system at the same time as updating,
> > which was to add another disk and configure it using ZFS. Perhaps this
> > is a ZFS on PowerPC64 issue? My amd64 box running the same rev of
> > CURRENT doesn't have the issue.
> > 
> 
> I've rebooted the box and started repeatedly logging the output of
> vmstat -m. It seems to show CAM CCB using a lot of memory and growing
> rather rapidly. For example, here's a few lines of diff output:
> 
> - CAM CCB 91418 182836K - 187149 2048
> + CAM CCB 447070 894140K - 900292 2048
> 
> from two samples that are 60 minutes apart.
> 
> The box is isn't terribly busy, it's just running the monitoring daemons
> running (snmpd, collectd), whatever web requests are hitting it (very
> few if any), this logging process, and my shell, etc.

This was causing problems on one of my amd64 systems, so it's not
specific to powerpc64. It turns out to be due to r298004: the CCB
allocated in cam_periph_devctl_notify() never gets freed. The patch
below seems to fix it.

It's possible to trace CCB allocations/frees using dtrace, which makes
many of these sorts of problems trivial to find. Running

# dtrace -n 'dtmalloc::CAM_CCB: {printf("%s", execname); stack();}'

and examining the output showed that hald was frequently allocating CCBs
at cam_periph_error+0x48f, but never freeing them. This corresponds to
the allocation in cam_periph_devctl_notify().

diff --git a/sys/cam/cam_periph.c b/sys/cam/cam_periph.c
index 85b2ff9..1f7be4f 100644
--- a/sys/cam/cam_periph.c
+++ b/sys/cam/cam_periph.c
@@ -1876,6 +1876,7 @@ cam_periph_devctl_notify(union ccb *ccb)
 
if (cgd->ccb_h.status == CAM_REQ_CMP)
sbuf_bcat(, cgd->serial_num, cgd->serial_num_len);
+   xpt_free_ccb((union ccb *)cgd);
}
sbuf_printf(, "\" ");
sbuf_printf(, "cam_status=\"0x%x\" ", ccb->ccb_h.status);
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_i386 - Build #3034 - Still Failing

2016-05-03 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #3034 - Still Failing:

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

Change summaries:

298955 by pfg:
sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

298954 by adrian:
[bwn] update bwn_dummy_transmission().

This is based on the b43 code.  It'll be used by the upcoming 11n phy.

Obtained from:  Linux b43 (concept)

298953 by adrian:
[bwn] add PHY types for later PHYs.

Obtained from:  Linux b43

298952 by adrian:
[bwn] migrate bwn_dummy_transmission() back to main, as it'll be used by other 
PHYs.

The Linux b43 driver uses this in other PHYs besides the g PHY.



The end of the build log:

[...truncated 189090 lines...]
ctfconvert -L VERSION -g usb_parse.o
--- usb_process.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -MD  
-MF.depend.usb_process.o -MTusb_process.o -mno-mmx -mno-sse -msoft-float 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/usb/usb_process.c
--- usb_msctest.o ---
ctfconvert -L VERSION -g usb_msctest.o
--- usb_request.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -MD  
-MF.depend.usb_request.o -MTusb_request.o -mno-mmx -mno-sse -msoft-float 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/usb/usb_request.c
--- usb_process.o ---
ctfconvert -L VERSION -g usb_process.o
--- usb_transfer.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -MD  
-MF.depend.usb_transfer.o -MTusb_transfer.o -mno-mmx -mno-sse -msoft-float 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/usb/usb_transfer.c
--- usb_hub.o ---
ctfconvert -L VERSION -g usb_hub.o
--- usb_util.o ---
--- usb_pf.o ---
ctfconvert -L VERSION -g usb_pf.o
--- usb_util.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -MD  
-MF.depend.usb_util.o -MTusb_util.o -mno-mmx -mno-sse -msoft-float 
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs 
-fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body  
-Wno-error-parentheses-equality -Wno-error-unused-function  
-Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx  
-std=iso9899:1999 -Werror  /usr/src/sys/dev/usb/usb_util.c
--- ukbd.o ---
cc  -c -O -pipe  -g -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -MD  
-MF.depend.ukbd.o -MTukbd.o -mno-mmx -mno-sse -msoft-float -ffreestanding 
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  
-Wno-error-tautological-compare -Wno-error-empty-body

Jenkins build is back to normal : FreeBSD_HEAD #240

2016-05-03 Thread jenkins-admin 
See 

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

Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box

2016-05-03 Thread Mark Millard 
I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS X 
to -r298793. This was via buildworld buildkernel then installing them, like 
normal for me.

The result is about 10-11 minutes after starting to boot FreeBSD shuts down 
with (for example):
(the root login line is just to give an idea of the time frame after the login 
prompt)

> May  2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for fixed 
> event - PM_Timer (0), disabling (20160422/evevent-323)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for fixed 
> event - RealTimeClock (4), disabling (20160422/evevent-323)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 01, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 03, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 04, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 05, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 06, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for GPE 
> 07, disabling event (20160422/evgpe-834)
> May  2 22:01:45 FreeBSDx64 kernel: .
> May  2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down
> May  2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM
> May  2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting
> May  2 22:01:46 FreeBSDx64 kernel: .
> May  2 22:01:47 FreeBSDx64 kernel: , 576.
> May  2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15


===
Mark Millard
markmi at dsl-only.net


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

Re: wired memory leak at r298785

2016-05-03 Thread Steve Wills 
On 05/ 2/16 11:24 PM, Warner Losh wrote:
> 
> 
> On Mon, May 2, 2016 at 6:55 PM, Steve Wills  > wrote:
> 
> Hi,
> 
> On 05/ 2/16 09:32 AM, Steve Wills wrote:
> > Hi,
> >
> > Just did my monthly update and r298785 seems to be leaking wired
> memory
> > rather rapidly. My system has 8gb of RAM and the amount of wired
> memory
> > just goes up and up continuously. It takes about 12 hours before it
> > exhausts all the RAM and sort of locks up (though shutdown still
> works).
> >
> > I also made one other change to the system at the same time as
> updating,
> > which was to add another disk and configure it using ZFS. Perhaps this
> > is a ZFS on PowerPC64 issue? My amd64 box running the same rev of
> > CURRENT doesn't have the issue.
> >
> 
> I've rebooted the box and started repeatedly logging the output of
> vmstat -m. It seems to show CAM CCB using a lot of memory and growing
> rather rapidly. For example, here's a few lines of diff output:
> 
> - CAM CCB 91418 182836K - 187149 2048
> + CAM CCB 447070 894140K - 900292 2048
> 
> from two samples that are 60 minutes apart.
> 
> The box is isn't terribly busy, it's just running the monitoring daemons
> running (snmpd, collectd), whatever web requests are hitting it (very
> few if any), this logging process, and my shell, etc.
> 
> Could this be related to recent changes in CURRENT?
> 
> Copying Scott and Warner in case they have comments on this since I'm
> told they have been active in this area recently.
> 
> 
> I've been looking into it. I'm not sure what's up since I don't see it
> in production. I'll give it a bump in priority though.
> 

Thanks! I did notice that killing bsnmpd drastically slowed the rate of
growth, but didn't completely eliminate it.

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