Re: statd/lockd startup failure

[George Mitchell]

On 03/09/11 03:09, Daniel Braniss wrote:

Under 8.2-PRERELEASE (GENERIC kernel), about 15% of the times I boot up
(with rpc.statd and rpc.lockd enabled in rc.conf), I get:

Feb  4 07:31:11 wonderland rpc.statd: bindresvport_sa: Address already in use
Feb  4 07:31:11 wonderland root: /etc/rc: WARNING: failed to start statd

and slightly later:

Feb  4 07:31:36 wonderland kernel: NLM: unexpected error contacting NSM, 
stat=5, errno=35

I can start rpc.statd and rpc.lockd manually at this point (and I have to
start them to run firefox and mail with my NFS-mounted home directory and
mail spool).  But what might cause the above errors?   -- George Mitchell


We have been seeing this too, with the addition of mountd.
So I decided to try and track it down.
rpc.lockd, rpc.statd or mountd, all share the same code for allocating
address/port. I added some more info to be displayed in case of error,
mainly the ai_family and port, so after many successfull reboots, I got:

Mar  9 09:18:19 chamsa mountd[1070]: bindresvport_sa: (2/617) Address already
in use

but:

chamsa>   rpcinfo | grep mountd
 151udp   0.0.0.0.2.105  mountd superuser
 153udp   0.0.0.0.2.105  mountd superuser
 151tcp   0.0.0.0.2.105  mountd superuser
 153tcp   0.0.0.0.2.105  mountd superuser

BTW, 0.0.0.2.105 is 617, and 2 is AF_INET

the above is wierd, since the rpc stuff happens after the bindresvport_sa(...)

danny




Thanks for the analysis.  The reason I originally posted is to see why
this might have popped up in 8.x, as it never happened in 7.x.
-- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Firefox startup impacted by distributed.net client

[George Mitchell]

Original message, from ten months ago:

http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html

Briefly, running the distributed.net client on my FreeBSD 8.0 box
made Firefox take forever to start up (90 seconds vs. 2 seconds).
The distributed.net client is essentially 100% CPU bound, with
occasional file I/O and even more occasional socket I/O, running
at nice 20.  The problem has persisted since then.

So I finally compiled up a kernel using SCHED_4BSD instead of
SCHED_ULE.  Problem fixed.

It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0,
since I still have the awful NFS client performance problem (though
not as bad as before the Rick Macklem patch).    -- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Firefox startup impacted by distributed.net client

[George Mitchell]

On 03/23/11 17:57, Matthias Gamsjager wrote:

Have you tried 8 stable?


The box I tried SCHED_4BSD on was running 8.2_PRERELEASE, which still
had the problem described.  Has the scheduler changed significantly
between 8.2_PRERELEASE and stable?  -- George Mitchell


On 23 Mar 2011 22:12, "George Mitchell"  wrote:

Original message, from ten months ago:

http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html

Briefly, running the distributed.net client on my FreeBSD 8.0 box
made Firefox take forever to start up (90 seconds vs. 2 seconds).
The distributed.net client is essentially 100% CPU bound, with
occasional file I/O and even more occasional socket I/O, running
at nice 20. The problem has persisted since then.

So I finally compiled up a kernel using SCHED_4BSD instead of
SCHED_ULE. Problem fixed.

It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0,
since I still have the awful NFS client performance problem (though
not as bad as before the Rick Macklem patch). -- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

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


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

Re: Firefox startup impacted by distributed.net client

[George Mitchell]

On 03/23/11 18:52, Jeremy Chadwick wrote:

On Wed, Mar 23, 2011 at 06:24:05PM -0400, George Mitchell wrote:

On 03/23/11 17:57, Matthias Gamsjager wrote:

Have you tried 8 stable?


The box I tried SCHED_4BSD on was running 8.2_PRERELEASE, which still
had the problem described.  Has the scheduler changed significantly
between 8.2_PRERELEASE and stable?  -- George Mitchell


On 23 Mar 2011 22:12, "George Mitchell"   wrote:

Original message, from ten months ago:

http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html

Briefly, running the distributed.net client on my FreeBSD 8.0 box
made Firefox take forever to start up (90 seconds vs. 2 seconds).
The distributed.net client is essentially 100% CPU bound, with
occasional file I/O and even more occasional socket I/O, running
at nice 20. The problem has persisted since then.

So I finally compiled up a kernel using SCHED_4BSD instead of
SCHED_ULE. Problem fixed.

It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0,
since I still have the awful NFS client performance problem (though
not as bad as before the Rick Macklem patch). -- George Mitchell


No, it hasn't.

You didn't provide any hardware details of your system in the link you
referenced (post to -hackers).  It matters.  dmesg output (regardless of
what scheduler you're using in the kernel) would be useful.


Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.2-PRERELEASE #0: Mon Mar 21 16:03:28 EDT 2011
geo...@scollay.m5p.com:/usr/obj/usr/src/sys/SCOLLAY amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Sempron(tm) 140 Processor (2712.36-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f62  Family = 10  Model = 6 
Stepping = 2


Features=0x78bfbff
  Features2=0x802009
  AMD 
Features=0xee500800
  AMD 
Features2=0x37fd

  TSC: P-state invariant
real memory  = 2147483648 (2048 MB)
avail memory = 1792958464 (1709 MB)
ACPI APIC Table: <012810 APIC1758>
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <012810 RSDT1758> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 6ff0 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0
cpu0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pci0:  at device 0.0 (no driver attached)
isab0:  port 0x900-0x9ff at device 1.0 on pci0
isa0:  on isab0
pci0:  at device 1.1 (no driver attached)
pci0:  at device 1.2 (no driver attached)
ohci0:  mem 0xdfffb000-0xdfffbfff 
irq 21 at device 2.0 on pci0

ohci0: [ITHREAD]
usbus0:  on ohci0
ehci0:  mem 
0xdfffac00-0xdfffacff irq 22 at device 2.1 on pci0

ehci0: [ITHREAD]
usbus1: EHCI version 1.0
usbus1:  on ehci0
pcib1:  at device 4.0 on pci0
pci1:  on pcib1
hdac0:  mem 
0xdfff4000-0xdfff7fff irq 23 at device 5.0 on pci0

hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 6.0 on pci0

ata0:  on atapci0
ata0: [ITHREAD]
ata1:  on atapci0
ata1: [ITHREAD]
nfe0:  port 0xe480-0xe487 mem 
0xdfff9000-0xdfff9fff irq 20 at device 7.0 on pci0

miibus0:  on nfe0
rgephy0:  PHY 3 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 
1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 
1000baseT-FDX-flow-master, auto, auto-flow

nfe0: Ethernet address: 48:5b:39:07:a8:78
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
nfe0: [FILTER]
atapci1:  port 
0xe400-0xe407,0xe080-0xe083,0xe000-0xe007,0xdc00-0xdc03,0xd880-0xd88f 
mem 0xdfff8000-0xdfff8fff irq 21 at device 8.0 on pci0

atapci1: [ITHREAD]
ata2:  on atapci1
ata2: [ITHREAD]
ata3:  on atapci1
ata3: [ITHREAD]
atapci2:  port 
0xd800-0xd807,0xd480-0xd483,0xd400-0xd407,0xd080-0xd083,0xd000-0xd00f 
mem 0xdffef000-0xdffe irq 22 at device 8.1 on pci0

atapci2: [ITHREAD]
ata4:  on atapci2
ata4: [ITHREAD]
ata5:  on atapci2
ata5: [ITHREAD]
pcib2:  at device 9.0 on pci0
pci2:  on pcib2
pcib3:  at device 11.0 on pci0
pci3:  on pcib3
pcib4:  at device 12.0 on pci0
pci4:  on pcib4
vgapci0:  mem 
0xde00-0xdeff,0xc000-0xcfff,0xdd00-0xddff irq 23 
at device 13.0 on pci0

acpi_button0:  on acpi0
atrtc0:  port 0x70-0x71 irq 8 on acpi0
ppc0:  port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppc0: [ITHREAD]
ppbus0:  on ppc0
ppi0:  on ppbus0
plip0:  on ppbus0
plip0: [ITHREAD]
lpt0:  on ppbus0
lpt0: [ITHREAD]
lpt0: Interrupt-driven port
acpi_hpet0:  iomem 0xfed0-0xfed00fff on 
acpi0

Tim

Re: Heads up: you'll need to do a fresh "config KERNEL" etc

[George Mitchell]

On 05/14/11 20:05, Rick Macklem wrote:

Hi,

Just a heads up that after a commit going into stable/8 in a few
minutes, you'll need to do a fresh kernel build, starting at
"config GENERIC", including rebuilding the NFS related modules.

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



Sensational!  With this update, I finally get NFS client performance
as good as (or better than) 7.x, and I have a warm, fuzzy feeling
about 8.x at last.  (Except for SCHED_ULE, which gives terrible
performance on a single-core machine with a compute-bound process
running in the background.)  Thanks!      -- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Heads up: you'll need to do a fresh "config KERNEL" etc

[George Mitchell]

On 05/19/11 18:53, Rick Macklem wrote:

On 05/14/11 20:05, Rick Macklem wrote:

Hi,

Just a heads up that after a commit going into stable/8 in a few
minutes, you'll need to do a fresh kernel build, starting at
"config GENERIC", including rebuilding the NFS related modules.

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



Sensational! With this update, I finally get NFS client performance
as good as (or better than) 7.x, and I have a warm, fuzzy feeling
about 8.x at last. (Except for SCHED_ULE, which gives terrible
performance on a single-core machine with a compute-bound process
running in the background.) Thanks! -- George Mitchell


There's a weird (and you need to have a weird sense of humour to
enjoy it) flick called "Stranger than Paradise".

Anyhow, the above sounds like good news, although the commit it
was related to should have had no effect on perf, from what I can
see.

Assuming that you are using the regular 8.n client (and not the new
one), there have been some commits related to krpc bugs that could have
fixed cases which would have caused poor perf., although all of those
(except one where a client would hang on a TCP reconnect attempt) are in
8.2.

So, happy to hear it works for you now, but have no idea why;-) rick


Full disclosure: I was upgrading from 8.2-PRERELEASE, so it might well
have been some earlier change instead of this one.  -- George


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



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

Statistics?

[George Mitchell]

In a couple of days, I'll be shutting down a 7.1-RELEASE server which
has been running continuously for 769 days, in order to add some memory
to it and update to 8.2-STABLE.  It has received over 1 billion packets
and transmitted over 1.4 billion, of which over 20 million in each
direction were IPv6 packets.  Are there any other statistics that anyone
would like to see before I shut it down?

The only strange thing I've seen over the last two years are that there
are 2,634 lingering sockets listed in "netstat -a" in CLOSED state from
when client machines, having automounted /usr/home and /var/mail from
this server, were shut down.  Notwithstanding, I've had a very warm,
fuzzy feeling about 7.1-RELEASE for a long time now!

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

Re: TCP Reassembly Issues

[George Mitchell]

On 11/24/11 21:00, Jeremy Chadwick wrote:

[...]
If none of this solves the problem, then I consider this a priority 0
blocker (read: "all hands on deck") issue with the IP stack in FreeBSD
9.x and will need immediate attention.

I would strongly recommend a developer or clueful end-user begin
tracking down who committed all of these bits and CC them into the
thread.  I would start by looking who implemented the
net.inet.tcp.reass.cursegments sysctl, because that isn't in RELENG_8 at
all.



I've tried out the 9.0 release candidates, and what I notice is that for
a few minutes after the system starts, I get wonderful NFS read
throughput (7+ MB/s over a 100 megabit interface) -- more than twice as
fast as 7.n or 8.n on the same hardware -- quickly degrading to abysmal
(less than 0.5 MB/s).  Is this possibly related to the problem under
discussion?      -- George Mitchell

P.S. A lot of other 9.0 features look very nice indeed!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TCP Reassembly Issues

[George Mitchell]

On 11/26/11 00:23, Lawrence Stewart wrote:

[...]
Could those who have reported the bug and are able to recompile their
kernel to test a patch please try the following and report back to the
list:

http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch
[...]

Works for me!  I'm now getting a sustained throughput of 7.4MB/s,
compared to 4.3MB/s on 8.2-STABLE and 3.2MB/s on 7.4-RELEASE, all on
the same hardware (HP notebook with re 100Mb/s interface, reading from
an 8.2-STABLE server with an alc 1000Mb/s interface, via two gigabit
switches).

But I'm still bemused that there should have been any TCP reassembly
going on.  Doesn't that imply that there was packet fragmentation?  My
network is uniformly 1500 byte MTU. -- George
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TCP Reassembly Issues

[George Mitchell]

On 11/26/11 02:56, Jeremy Chadwick wrote:

[...]
This entire situation leads me to believe very few people are doing
quality testing of RELENG_9, yet we're already into 9.0-RC2.  Please
don't tell me "that's exactly why you should be running RELENG_9!"; that
is completely backwards and I refuse to get into a flame war about it,
because it's this simple: 90%+ of those running FreeBSD on servers need
something that's stable, we can't risk wonkiness (especially of this
degree!) on systems taking production traffic.  Did no one actually test
the change *thoroughly*?  Imagine had this lay dormant until 9.0-RELEASE.
[...]


  L U   U    OOO  N   N E
P   P L U   U S O   O NN  N E
  L U   U  SSS  O   O N N N EEE
P L U   U S O   O N  NN E
P L  UUU     OOO  N   N E

I didn't get a warm, fuzzy feeling about FreeBSD 7 until 7.1, and
FreeBSD 8 was worse -- no warm, fuzzy feeling until 8.2.  And I am still
not sold on SCHED_ULE:  Start as many compute-bound programs as there
are CPUs, and prepare for poor (to put it kindly) interactive response.
That's not everybody's usage pattern, but it seems plausible enough to
me to preclude SCHED_ULE as the default scheduler until it is fixed.

On the good side, I'm pleased with the new 9.0 boot menu, and I'm very
happy that the ahci driver automatically creates symbolic links to the
old device names for its disks.  I like that I don't have to tab to the
"Okay" button in configuration dialogs any more (though I was surprised
the first time it happened).

But I hope this gets fixed for my flash card reader/writer:

ugen0.5:  at usbus0
umass0:  on 
usbus0

umass0:  SCSI over Bulk-Only; quirks = 0x4101
umass0:2:0:-1: Attached to scbus2
(probe0:umass-sim0:0:0:0): AutoSense failed
(da0:umass-sim0:0:0:0): got CAM status 0x4
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
(da0:umass-sim0:0:0:0): lost device - 0 outstanding
(da0:umass-sim0:0:0:0): removing device entry

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

SCHED_ULE should not be the default

[George Mitchell]

dnetc is an open-source program from http://www.distributed.net/.  It
tries a brute-force approach to cracking RC4 puzzles and also computes
optimal Golomb rulers.  It starts up one process per CPU and runs at
nice 20 and is, for all intents and purposes, 100% compute bound.

Here is what happens on my system, running 9.0-PRERELEASE, with and
without dnetc running, with SCHED_ULE and SCHED-4BSD, when I run the
command:

time make buildkernel KERNCONF=WONDERLAND

(I get similar results on 8.x as well.)

SCHED_4BSD, dnetc not running:
1329.715u 123.739s 24:47.95 97.6%   6310+1987k 11233+11098io 419pf+0w

SCHED_4BSD, dnetc running:
1329.364u 115.158s 26:14.83 91.7%   6325+1987k 10912+11060io 393pf+0w

SCHED_ULE, dnetc not running:
1357.457u 121.526s 25:20.64 97.2%   6326+1990k 11234+11149io 419pf+0w

SCHED_ULE, dnetc running:
Still going after seven and a half hours of clock time, up to
compiling netgraph/bluetooth.  (Completed in another five minutes
after stopping dnetc so I could write this message in a reasonable
amount of time.)

Not everybody runs this sort of program, but there are plenty of
similar projects out there, and people who try to participate in
them will be mightily displeased with their FreeBSD systems when
they do.  Is there some case where SCHED_ULE exhibits significantly
better performance than SCHED_4BSD?  If not, I think SCHED-4BSD
should remain the default GENERIC configuration until this is fixed.
-- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SCHED_ULE should not be the default

[George Mitchell]

On 12/09/11 10:17, Attilio Rao wrote:

[...]
More precisely I'd be interested in KTR traces.
To be even more precise:
With a completely stable GENERIC configuration (or otherwise please
post your kernel config) please add the following:
options KTR
options KTR_ENTRIES=262144
options KTR_COMPILE=(KTR_SCHED)
options KTR_MASK=(KTR_SCHED)

While you are in the middle of the slow-down (so once it is well
established) please do:
# sysclt debug.ktr.cpumask=""


wonderland# sysctl debug.ktr.cpumask=""
debug.ktr.cpumask: 
sysctl: debug.ktr.cpumask: Invalid argument



In the end go with:
# ktrdump -ctf>  ktr-ule-problem.out


It's 44MB, so it's at http://www.m5p.com/~george/ktr-ule-problem.out



and send the file to this mailing list.

Thanks,
Attilio




I hope this helps.    -- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SCHED_ULE should not be the default

[George Mitchell]

On 12/09/11 19:59, Attilio Rao wrote:

[...]

What svn revision did you use for it?
What is the CPUs frequencies of machines generating this?

Attilio




Hope the attached helps. -- George Mitchell
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-PRERELEASE #1: Wed Dec  7 20:31:19 EST 2011
geo...@wonderland.m5p.com:/usr/obj/usr/src/sys/WONDERLAND amd64
module uaudio already present!
CPU: AMD Athlon(tm) II Dual-Core M320 (2094.80-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f62  Family = 10  Model = 6  Stepping = 2
  
Features=0x178bfbff
  Features2=0x802009
  AMD 
Features=0xee500800
  AMD 
Features2=0x377f
  TSC: P-state invariant
real memory  = 3221225472 (3072 MB)
avail memory = 2821079040 (2690 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 4
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
cpu0:  on acpi0
cpu1:  on acpi0
acpi_ec0:  port 0x62,0x66 on acpi0
acpi_button0:  on acpi0
acpi_button1:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pcib0: Length mismatch for 3 range: 800 vs 7ff
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
vgapci0:  port 0x3000-0x30ff mem 
0xc000-0xcfff,0xd030-0xd030,0xd020-0xd02f irq 18 at 
device 5.0 on pci1
pcib2:  at device 5.0 on pci0
pci2:  on pcib2
ath0:  mem 0xd010-0xd010 irq 17 at device 0.0 on pci2
ath0: AR9285 mac 192.2 RF5133 phy 14.0
pcib3:  at device 6.0 on pci0
pci3:  on pcib3
re0:  port 0x2000-0x20ff mem 
0xd001-0xd0010fff,0xd000-0xd000 irq 18 at device 0.0 on pci3
re0: Using 1 MSI-X message
re0: Chip rev. 0x2480
re0: MAC rev. 0x0040
miibus0:  on re0
rlphy0:  PHY 1 on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
re0: Ethernet address: 00:26:9e:bf:bc:5d
ahci0:  port 
0x4038-0x403f,0x404c-0x404f,0x4030-0x4037,0x4048-0x404b,0x4010-0x401f mem 
0xd0408000-0xd04083ff irq 22 at device 17.0 on pci0
ahci0: AHCI v1.10 with 2 3Gbps ports, Port Multiplier supported
ahcich0:  at channel 0 on ahci0
ahcich1:  at channel 1 on ahci0
ohci0:  mem 0xd0407000-0xd0407fff irq 16 at 
device 18.0 on pci0
usbus0:  on ohci0
ohci1:  mem 0xd0406000-0xd0406fff irq 16 at 
device 18.1 on pci0
usbus1:  on ohci1
ehci0:  mem 0xd0408500-0xd04085ff irq 17 at 
device 18.2 on pci0
usbus2: EHCI version 1.0
usbus2:  on ehci0
ohci2:  mem 0xd0405000-0xd0405fff irq 18 at 
device 19.0 on pci0
usbus3:  on ohci2
ohci3:  mem 0xd0404000-0xd0404fff irq 18 at 
device 19.1 on pci0
usbus4:  on ohci3
ehci1:  mem 0xd0408400-0xd04084ff irq 19 at 
device 19.2 on pci0
usbus5: EHCI version 1.0
usbus5:  on ehci1
pci0:  at device 20.0 (no driver attached)
hdac0:  mem 0xd040-0xd0403fff 
irq 16 at device 20.2 on pci0
isab0:  at device 20.3 on pci0
isa0:  on isab0
pcib4:  at device 20.4 on pci0
pci4:  on pcib4
battery0:  on acpi0
acpi_acad0:  on acpi0
acpi_lid0:  on acpi0
acpi_tz0:  on acpi0
acpi_tz0: _CRT value is absurd, ignored (-273.2C)
hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
Event timer "HPET1" frequency 14318180 Hz quality 450
atrtc0:  port 0x70-0x71 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model Generic PS/2 mouse, device ID 0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
ppc0: cannot reserve I/O port range
acpi_throttle0:  on cpu0
hwpstate0:  on cpu0
Timecounters tick every 1.000 msec
hdac0: HDA Codec #0: IDT 92HD75B3
hdac0: HDA Codec #1: Lucent/Agere Systems (Unknown)
pcm0:  at cad 0 nid 1 on hdac0
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 480Mbps High Speed USB v2.0
usbus3: 12Mbps Full Speed USB v1.0
usbus4: 12Mbps Full Speed USB v1.0
usbus5: 480Mbps High Speed USB v2.0
ugen0.1:  at usbus0
uhub0:  on usbus0
ugen1.1:  at usbus1
uhub1:  on usbus1
ugen2.1:  at usbus2
uhub2:  on usbus2
ugen3.1:  at usbus3
uhub3:  on usbus3
ugen4.1:  at usbus4
uhub4:  on usbus4
ugen5.1

Re: SCHED_ULE should not be the default

[George Mitchell]

On 12/12/11 19:29, Doug Barton wrote:

[...]

I switched to 4BSD, problem gone.

[...]


Ditto.  If there's some common situation where the average user would
have a perceptibly better experience with ULE, let's go for it.  But
when there's a plausible usage scenario in which ULE gives OVER AN
ORDER OF MAGNITUDE worse performance[1], making ULE the default seems
like a bad choice.      -- George Mitchell

[1] 
http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064773.html

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

Re: SCHED_ULE should not be the default

[George Mitchell]

On 12/12/11 11:18, Bruce Cran wrote:

On 12/12/2011 15:51, Steve Kargl wrote:

This comes up every 9 months or so, and must be approaching FAQ
status. In a HPC environment, I recommend 4BSD. Depending on the
workload, ULE can cause a severe increase in turn around time when
doing already long computations. If you have an MPI application,
simply launching greater than ncpu+1 jobs can show the problem. PS:
search the list archives for "kargl and ULE".


This isn't something that can be fixed by tuning ULE? For example for
desktop applications kern.sched.preempt_thresh should be set to 224 from
its default. I'm wondering if the installer should ask people what the
typical use will be, and tune the scheduler appropriately.



I tried my "make buildkernel" test with "dnetc" running after setting
kern.sched.preempt_thresh set to 224.  It did far worse than before,
getting only as far as compiling bxe overnight (compared to getting
to netgragh with the default kern.sched.preempt_thresh setting).
-- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SCHED_ULE should not be the default

[George Mitchell]

On 12/13/11 18:02, Marcus Reid wrote:

[...]
The issues that I've seen with ULE on the desktop seem to be caused by X
taking up a steady amount of CPU, and being demoted from being an
"interactive" process.  X then becomes the bottleneck for other
processes that would otherwise be "interactive".  Try 'renice -20
' and see if that makes your problems go away.

Marcus
[...]


renice on X has no effect.  Stopping my compute-bound dnetc process
immediately speeds everything up; restarting it slows it back down.


On 12/13/11 19:01, m...@freebsd.org wrote:
> [...]
> Has anyone experiencing problems tried to set sysctl 
kern.sched.steal_thresh=1 ?

> [...]

1 appears to be the default value for kern.sched.steal_thresh.

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

Re: SCHED_ULE should not be the default

[George Mitchell]

On 12/09/11 19:57, George Mitchell wrote:

On 12/09/11 10:17, Attilio Rao wrote:

[...]
More precisely I'd be interested in KTR traces.
To be even more precise:
With a completely stable GENERIC configuration (or otherwise please
post your kernel config) please add the following:
options KTR
options KTR_ENTRIES=262144
options KTR_COMPILE=(KTR_SCHED)
options KTR_MASK=(KTR_SCHED)

While you are in the middle of the slow-down (so once it is well
established) please do:
# sysclt debug.ktr.cpumask=""


wonderland# sysctl debug.ktr.cpumask=""
debug.ktr.cpumask: 
sysctl: debug.ktr.cpumask: Invalid argument



In the end go with:
# ktrdump -ctf> ktr-ule-problem.out


It's 44MB, so it's at http://www.m5p.com/~george/ktr-ule-problem.out


There have been 22 downloads of this file so far; does anyone who
looked at it have any results to report?

Dear Secret Masters of FreeBSD: Can we have a decision on whether to
change back to SCHED_4BSD while SCHED_ULE gets properly fixed?

-- George Mitchell





and send the file to this mailing list.

Thanks,
Attilio




I hope this helps. -- George Mitchell


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

Re: SCHED_ULE should not be the default

[George Mitchell]

On 12/14/11 12:54, Tom Evans wrote:

[...] This thread has shown that ULE performs poorly
in very specific scenarios where the server is loaded with NCPU+1 CPU
bound processes, [...]


Minor correction: Problem occurs when there are nCPU compute-bound
processes, not nCPU + 1.-- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SCHED_ULE should not be the default

[George Mitchell]

On 12/14/11 21:05, Oliver Pinter wrote:

[...]
Hi!

Can you try with this settings:

op@opn ~>  sysctl kern.sched.
kern.sched.cpusetsize: 8
kern.sched.preemption: 0
kern.sched.name: ULE
kern.sched.slice: 13
kern.sched.interact: 30
kern.sched.preempt_thresh: 224
kern.sched.static_boost: 152
kern.sched.idlespins: 1
kern.sched.idlespinthresh: 16
kern.sched.affinity: 1
kern.sched.balance: 1
kern.sched.balance_interval: 133
kern.sched.steal_htt: 1
kern.sched.steal_idle: 1
kern.sched.steal_thresh: 1
kern.sched.topology_spec:
  
   0, 1
   

 0, 1

   
  

[...]


Sorry I didn't try this earlier, but I had time this morning.
Apparently you can't change kern.sched.preemption without
recompiling, so I did that.  It didn't help, and subjectively it
made interactive performance worse.  I changed preempt_thresh and
observed no difference.  There were only a couple of small
differences between your other settings and the 9.0-PRERELEASE
defaults.

Summing up for the record, in my original test:
1. It doesn't matter whether X is running or not.
2. The problem is not limited to two or fewer CPUs.  (It also happens
   for me on a six-CPU system.)
3. It doesn't require nCPU + 1 compute-bound processes, just nCPU.

With nCPU compute-bound processes running, with SCHED_ULE, any other
process that is interactive (which to me means frequently waiting for
I/O) gets ABYSMAL performance -- over an order of magnitude worse than
it gets with SCHED_4BSD under the same conditions.-- George
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SCHED_ULE should not be the default

[George Mitchell]

On 12/22/11 04:07, Adrian Chadd wrote:

Are you able to go through the emails here and grab out Attilio's
example for generating KTR scheduler traces?


Adrian
[...]

I've put up two such files:
http://www.m5p.com/~george/ktr-ule-problem.out
http://www.m5p.com/~george/ktr-ule-interact.out
but I don't know how to analyze them myself.  What do all of us do next?
-- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

9.0-RC3 umass quirks?

[George Mitchell]

I have a USB compact flash reader-writer which is normally connected to
my computer all the time but rarely contains a compact flash card.  Here
is a snippet from a verbose dmesg with FreeBSD 9.0-RC3:


ugen0.5:  at usbus0
umass0:  on 
usbus0

umass0:  SCSI over Bulk-Only; quirks = 0x4101
umass0:2:0:-1: Attached to scbus2
(probe0:umass-sim0:0:0:0): SCSI status error
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not 
present)

(probe0:umass-sim0:0:0:0): Error 6, Unretryable error
(probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0?
...
(probe0:umass-sim0:0:0:0): AutoSense failed
(probe0:umass-sim0:0:0:0): Error 5, Unretryable error
GEOM: new disk da0
pass2 at umass-sim0 bus 0 scbus2 target 0 lun 0
pass2:  Removable Direct Access SCSI-0 device
pass2: 1.000MB/s transfers
...
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Retrying command
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Retrying command
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Retrying command
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Retrying command
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Error 5, Retries exhausted
(da0:umass-sim0:0:0:0): got CAM status 0x4
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
(da0:umass-sim0:0:0:0): lost device - 0 outstanding
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Error 5, Retries exhausted
(da0:umass-sim0:0:0:0): removing device entry
Opened disk da0 -> 5


Everything works normally, but the above events take about half a
minute and bring the booting-up procedure to a halt while the
retries finish.  Is there a umass quirk I could enable to speed up
whatever is happening here?  usbconfig -d 0.5 dump_device_desc says:

ugen0.5:  at usbus0, cfg=0 md=HOST spd=FULL 
(12Mbps) pwr=ON


  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x
  bDeviceSubClass = 0x
  bDeviceProtocol = 0x
  bMaxPacketSize0 = 0x0040
  idVendor = 0x05e3
  idProduct = 0x0703
  bcdDevice = 0x0032
  iManufacturer = 0x  
  iProduct = 0x0001  
  iSerialNumber = 0x  
  bNumConfigurations = 0x0001

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

Re: 9.0-RC3 umass quirks?

[George Mitchell]

On 01/-10/63 14:59, George Mitchell wrote:

I have a USB compact flash reader-writer which is normally connected to
my computer all the time but rarely contains a compact flash card. Here
is a snippet from a verbose dmesg with FreeBSD 9.0-RC3:


ugen0.5:  at usbus0
umass0:  on
usbus0
umass0: SCSI over Bulk-Only; quirks = 0x4101
umass0:2:0:-1: Attached to scbus2
(probe0:umass-sim0:0:0:0): SCSI status error
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not
present)
(probe0:umass-sim0:0:0:0): Error 6, Unretryable error
(probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0?
...
(probe0:umass-sim0:0:0:0): AutoSense failed
(probe0:umass-sim0:0:0:0): Error 5, Unretryable error
GEOM: new disk da0
pass2 at umass-sim0 bus 0 scbus2 target 0 lun 0
pass2:  Removable Direct Access SCSI-0 device
pass2: 1.000MB/s transfers
...
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Retrying command
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Retrying command
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Retrying command
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Retrying command
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Error 5, Retries exhausted
(da0:umass-sim0:0:0:0): got CAM status 0x4
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
(da0:umass-sim0:0:0:0): lost device - 0 outstanding
(da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR
(da0:umass-sim0:0:0:0): Error 5, Retries exhausted
(da0:umass-sim0:0:0:0): removing device entry
Opened disk da0 -> 5


Everything works normally, but the above events take about half a
minute and bring the booting-up procedure to a halt while the
retries finish. Is there a umass quirk I could enable to speed up
whatever is happening here? usbconfig -d 0.5 dump_device_desc says:

ugen0.5:  at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x
bDeviceSubClass = 0x
bDeviceProtocol = 0x
bMaxPacketSize0 = 0x0040
idVendor = 0x05e3
idProduct = 0x0703
bcdDevice = 0x0032
iManufacturer = 0x 
iProduct = 0x0001 
iSerialNumber = 0x 
bNumConfigurations = 0x0001



Here's the corresponding dmesg output from 8.2-STABLE:

ugen0.5:  at usbus0
umass0:  on 
usbus0

umass0:  SCSI over Bulk-Only; quirks = 0x
umass0: Get Max Lun not supported (USB_ERR_STALLED)
umass0:2:0:-1: Attached to scbus2
(probe0:umass-sim0:0:0:0): SCSI status error
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 1 0 0 ff 0
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not 
present)

(probe0:umass-sim0:0:0:0): Error 6, Unretryable error
(probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0?
(probe0:umass-sim0:0:0:0): SCSI status error
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not 
present)

(probe0:umass-sim0:0:0:0): Error 6, Unretryable error
GEOM: new disk da0
pass2 at umass-sim0 bus 0 scbus2 target 0 lun 0
pass2:  Removable Direct Access SCSI-0 device
pass2: 1.000MB/s transfers
(da0:umass-sim0:0:0:0): SCSI status error
(da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0:  Removable Direct Access SCSI-0 device
da0: 1.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
(da0:umass-sim0:0:0:0): SCSI status error
(da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
Opened disk da0 -> 6
(da0:umass-sim0:0:0:0): SCSI status error
(da0:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
(da0:umass-sim0:0:0:0): Error 6, Unretryable error
Opened disk da0 -> 6

(which all took only a couple of seconds, comp

Re: [releng_8_2 tinderbox] failure on powerpc/powerpc

[George Mitchell]

On 02/02/12 15:37, FreeBSD Tinderbox wrote:

[... one of three errors it's been reporting repeatedly for days ...]

Talk about a lack of focus!  Apparently two or three people have all
recently checked in code without first verifying that it compiled (let
alone ran), or else possibly did not completely commit their changes,
and then absconded to a place where they fail to receive these emails
about the problems.  Can someone please either diagnose these errors or
else revert the deficient commits?  -- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ata_controlcmd undefined

[George Mitchell]

I csupped my 9.0-STABLE kernel on Sunday and now get this message
at the beginning of booting up:

link-elf-obj: symbol ata_controlcmd undefined
KLD file atapicat.ko - could not finalize loading

Kernel configuration is GENERIC (except scheduler is SCHED_4BSD).
-- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ata_controlcmd undefined

[George Mitchell]

On 06/05/12 11:20, Oliver Fromme wrote:

George Mitchell<>  wrote:
  >  I csupped my 9.0-STABLE kernel on Sunday and now get this message
  >  at the beginning of booting up:
  >
  >  link-elf-obj: symbol ata_controlcmd undefined
  >  KLD file atapicat.ko - could not finalize loading

The same happened to me, except that I had "device atapicam"
statically in my kernel config.  When building the new kernel,
linking failed because of missing symbols (ata_controlcmd and
others).

It seems that atapicam is now obsolet and has been replaced by
"options ATA_CAM" which is already present in GENERIC.

Okay, thanks for the explanation.

Have you tried removing atapicam_load from /boot/loader.conf
(I guess that's where you're trying to load the module)?


Yes.


  >  Kernel configuration is GENERIC (except scheduler is SCHED_4BSD).

Just out of curiosity, why do you prefer SCHED_4BSD?


Don't get me started!  -- George


Best regards
Oliver



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

9.0-STABLE: Can't umount umass device

[George Mitchell]

uname -a:
FreeBSD wonderland.m5p.com 9.0-STABLE FreeBSD 9.0-STABLE #9: Sun Jun  3 
10:01:09 EDT 2012 
geo...@wonderland.m5p.com:/usr/obj/usr/src/sys/WONDERLAND  amd64


dmesg | grep umass:
umass0:  on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x4000
umass0:3:0:-1: Attached to scbus3
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not 
ready to ready change, medium may have changed)

da0 at umass-sim0 bus 0 scbus3 target 0 lun 0

# mount -t msdosfs /dev/da0s1 /flash
# umount /flash
umount: unmount of /flash failed: Device busy

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

Re: 9.0-STABLE: Can't umount umass device

[George Mitchell]

On 07/04/12 00:14, Jason Hellenthal wrote:


fstat /flash ?


# fstat /flash
USER CMD  PID   FD MOUNT  INUM MODE SZ|DV R/W NAME
george   gam_server  1654 5730 /flash   131072 drwxr-xr-x   32768  r  /flash
george   gam_server  1654 5731 -131072 -rwxr-xr-x 512  r  /flash

Thanks for the tip,  But, AARGH!  Everything in the world seems to
depend on this gamin thing.  What's the recommended course of
action?-- George



On Tue, Jul 03, 2012 at 08:42:55PM -0400, George Mitchell wrote:

uname -a:
FreeBSD wonderland.m5p.com 9.0-STABLE FreeBSD 9.0-STABLE #9: Sun Jun  3
10:01:09 EDT 2012
geo...@wonderland.m5p.com:/usr/obj/usr/src/sys/WONDERLAND  amd64

dmesg | grep umass:
umass0:  on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x4000
umass0:3:0:-1: Attached to scbus3
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not
ready to ready change, medium may have changed)
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0

# mount -t msdosfs /dev/da0s1 /flash
# umount /flash
umount: unmount of /flash failed: Device busy

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




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

Re: 9.0-STABLE: Can't umount umass device

[George Mitchell]

On 07/04/12 00:42, Ian Lepore wrote:

On Tue, 2012-07-03 at 20:42 -0400, George Mitchell wrote:

uname -a:
FreeBSD wonderland.m5p.com 9.0-STABLE FreeBSD 9.0-STABLE #9: Sun Jun  3
10:01:09 EDT 2012
geo...@wonderland.m5p.com:/usr/obj/usr/src/sys/WONDERLAND  amd64

dmesg | grep umass:
umass0:  on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x4000
umass0:3:0:-1: Attached to scbus3
(probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not
ready to ready change, medium may have changed)
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0

# mount -t msdosfs /dev/da0s1 /flash
# umount /flash
umount: unmount of /flash failed: Device busy

-- George Mitchell


Are you running a desktop environment that automatically launches
gam_server to watch for changes on mounted filesystems?  If so, the fix
is to edit /usr/local/etc/gamin/gaminrc and tell it to use polling
rather than kernel notification on the mount points you use for
removable media.

-- Ian

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


Thanks, this was the problem.  By the way, here between these two rows
of equals signs is the total amount of documentation that the gamin
port/package installed on my system:
==
==
Google showed me what to put in my /usr/local/etc/gamin/gaminrc file:

poll /flash

I appreciate the help! -- George
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Odd ttyvN TERM settings

[George Mitchell]

Up through FreeBSD 8.x, the ttyvN consoles had a TERM setting of cons25.
On FreeBSD 9.n, it appears to be xterm for ttyv0, but it's still cons25
for ttyv1-ttyv8 (even though they all appear to act like xterms).  Not
surprisingly, this leads to less than desirable results when trying to
run vi (or other such programs) on ttyv1 through ttyv8, unless you
remember to setenv TERM xterm.

Why did we change from cons25 to xterm?  How can we get all the ttyvNs
to get the correct TERM setting?  -- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Odd ttyvN TERM settings

[George Mitchell]

On 07/08/12 10:14, Ronald Klop wrote:

On Sun, 08 Jul 2012 16:00:16 +0200, George Mitchell
 wrote:


Up through FreeBSD 8.x, the ttyvN consoles had a TERM setting of cons25.
On FreeBSD 9.n, it appears to be xterm for ttyv0, but it's still cons25
for ttyv1-ttyv8 (even though they all appear to act like xterms).  Not
surprisingly, this leads to less than desirable results when trying to
run vi (or other such programs) on ttyv1 through ttyv8, unless you
remember to setenv TERM xterm.

Why did we change from cons25 to xterm?  How can we get all the ttyvNs
to get the correct TERM setting?  -- George Mitchell


What is in your /etc/ttys?

This is the ttys file on 9-STABLE on amd64:
http://svnweb.freebsd.org/base/stable/9/etc/etc.amd64/ttys?revision=225736&view=markup&pathrev=238244


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



Apparently I raced through mergemaster too fast (on two different
machines, as well).  That's where the problem was.  Thanks for the
help!   -- George

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

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[George Mitchell]

On 12/23/20 11:58 AM, Warner Losh wrote:

[...]

mergemaster and etcupdate can cope without them.

Warner
[...]


Until this moment, I had never heard of etcupdate, and I had
mergemaster practically programmed into my fingers for system updates.
So I read the man page for etcupdate, and it looks like just what I
should have been using all along!

Given that my habitual method for updating with mergemaster will
clearly not work any more, it seems highly regrettable that there
is no reference to etcupdate anywhere in the FreeBSD Handbook, or
in /usr/src/UPDATING in the tail end COMMON ITEMS section.  If it
hadn't been for this email thread, I never would have found out
about it (and I would have become highly wrought when update time
rolled around once again).

Could someone who is more familiar with etcupdate please modify
/usr/src/UPDATING and the Handbook appropriately?  Thanks. -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: How do I know if my 13-stable has security patches?

[George Mitchell]

On 2/25/21 3:56 PM, Warner Losh wrote:

[...]
We should likely just publish the 'v' number in the advisories. It's
basically a count back to the start of the project. We put that number in
uname already. []

+1 !!! -- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: Deprecating base system ftpd

[George Mitchell]

On 4/10/21 2:58 AM, Scott Bennett via freebsd-stable wrote:

[...]I would like
something far smaller, namely, a choice of schedulers during/just
after installation of a -RELEASE without having to a) download the
entire source tree, b) make buildworld, and c) make buildkernel.
[...]


+1 many times over!  I've been hoping someone would implement the
schedulers as linkable kernel modules.  Surely such a thing is
theoretically possible?  Maybe there would have to be a dummy
scheduler module capable of only single-CPU single-threaded
execution to get the kernel to the point where the user-specified
real scheduler could be loaded for further operations.

This is based, of course, on my complete lack of knowledge about
whether the scheduler interface is even compatible with the linkable
kernel module interface, etc., etc.  But it sure would be nice.
-- George



OpenPGP_signature
Description: OpenPGP digital signature

Re: FreeBSD 9.1 stability/robustness?

[George Mitchell]

On 11/01/12 22:14, Brett Glass wrote:

I need to build up a few servers and routers, and am wondering how
FreeBSD 9.1 is shaping up. Will it be likely to be more stable and
robust than 9.0-RELEASE? Are there issues that will have to wait
until 9.2-RELEASE to be fixed? Opinions welcome.

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



Personally I don't have a warm, fuzzy feeling about 9.x yet.  I'm
sticking with 8.3 with 4BSD scheduler for now.   -- George Mitchell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SU+J on 9.1-RC2 ISO

[George Mitchell]

On 11/03/12 15:09, Jeremy Chadwick wrote:

(Please keep me CC'd, as I'm not subscribed to -stable)

I've CC'd Nathan Whitehorn, who according to bsdinstall(8) is the
author (not sure if maintainer) of the code.

This default has already begun to bite users/SAs in the ass:

http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html

SU+J (the journalling part specifically) needs to be disabled by default
in the installer.  This default was a very bad choice and should not
have been done.  It either indicates someone was out of touch with the
rest of the issues surrounding the feature, or that someone
intentionally decided "it's the best way to get people using it for
testing" (I have seen this justification presented in the past, and it
is the wrong approach).

However, since some people DO want it (and those folks don't use dump),
the installer should be modified to make SU+J support toggleable via a a
checkbox.  The default, obviously, should be unchecked.

If the user checks the checkbox, an ominous warning message should be
displayed informing the user of the repercussions.  The only option at
that point should be "OK", after which the checkbox is checked.

Do not tell me "send patches".  This issue/problem has gone on long
enough, and the community bitched hard/long enough, that the person who
committed this default should be responsible for fixing it.

We should operate under the assumption that this bug/problem will never
be fixed.  It probably will be, but again, we must operate with the
assumption that Kirk et al will require years to fix it.  (It has
already been something like 9 months.  Or is it a year?)

[...]


I will give this comment a BIG, BIG, +1!   --  George

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

Re: [releng_9_1 tinderbox] failure on powerpc64/powerpc

[George Mitchell]

On 11/04/12 14:59, FreeBSD Tinderbox wrote:

TB --- 2012-11-04 19:53:34 - tinderbox 2.9 running on freebsd-stable.sentex.ca
TB --- 2012-11-04 19:53:34 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE 
FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 
mdtan...@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server  amd64
TB --- 2012-11-04 19:53:34 - starting RELENG_9_1 tinderbox run for 
powerpc64/powerpc
TB --- 2012-11-04 19:53:34 - cleaning the object tree
TB --- 2012-11-04 19:53:34 - checking out /src from 
svn://svn.freebsd.org/base/releng/9.1
TB --- 2012-11-04 19:53:34 - cd /tinderbox/RELENG_9_1/powerpc64/powerpc
TB --- 2012-11-04 19:53:34 - /usr/local/bin/svn cleanup /src
TB --- 2012-11-04 19:54:02 - /usr/local/bin/svn update /src
TB --- 2012-11-04 19:54:02 - WARNING: /usr/local/bin/svn returned exit code  1
TB --- 2012-11-04 19:54:02 - WARNING: sleeping 30 s and retrying...
TB --- 2012-11-04 19:54:32 - /usr/local/bin/svn update /src
TB --- 2012-11-04 19:54:32 - WARNING: /usr/local/bin/svn returned exit code  1
TB --- 2012-11-04 19:54:32 - WARNING: sleeping 60 s and retrying...
TB --- 2012-11-04 19:55:32 - /usr/local/bin/svn update /src
TB --- 2012-11-04 19:55:32 - WARNING: /usr/local/bin/svn returned exit code  1
TB --- 2012-11-04 19:55:32 - WARNING: sleeping 90 s and retrying...
TB --- 2012-11-04 19:57:02 - /usr/local/bin/svn update /src
TB --- 2012-11-04 19:57:02 - WARNING: /usr/local/bin/svn returned exit code  1
TB --- 2012-11-04 19:57:02 - WARNING: sleeping 120 s and retrying...
TB --- 2012-11-04 19:59:02 - /usr/local/bin/svn update /src
TB --- 2012-11-04 19:59:02 - WARNING: /usr/local/bin/svn returned exit code  1
TB --- 2012-11-04 19:59:02 - ERROR: unable to check out the source tree
TB --- 2012-11-04 19:59:02 - 3.92 user 4.38 system 328.82 real


http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9_1-powerpc64-powerpc.full
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



Gosh, I'm SO looking forward to depending on svn instead of csup for
software updates.-- George
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

boot2 FreeBSD 9.2-RC1 r253913M

[George Mitchell]

boot2 gives me a "boot: " prompt but will not accept input from the
keyboard on an HP CQ61-420US notebook.  Fortunately, it times out
after a few seconds and boots normally after that.  But it's still
a bit annoying.   -- George
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: boot2 FreeBSD 9.2-RC1 r253913M

[George Mitchell]

On 08/04/13 15:27, George Mitchell wrote:

boot2 gives me a "boot: " prompt but will not accept input from the
keyboard on an HP CQ61-420US notebook.  Fortunately, it times out
after a few seconds and boots normally after that.  But it's still
a bit annoying.   -- George


The "M" is because I rolled back r250907 due to the reports of NFS
deadlocks.  -- George
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 9.2-RC2 Now Available

[George Mitchell]

On 08/16/13 22:17, Glen Barber wrote:

The second release candidate builds of the 9.2-RELEASE release cycle
are now available on the FTP servers for the amd64, i386, ia64, powerpc,
powerpc64, and sparc64 architectures.
[...]
Glen


Has any progress been made on diagnosing this NFS deadlock?

http://lists.freebsd.org/pipermail/freebsd-stable/2013-August/074746.html

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

Upgrading via source build, 10.4->11.2

[George Mitchell]

/usr/src/UPDATING says:

To build a kernel
-
If you are updating from a prior version of FreeBSD (even one just
a few days old), you should follow this procedure.  It is the most
failsafe as it uses a /usr/obj tree with a fresh mini-buildworld,

make kernel-toolchain
make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=YOUR_KERNEL_HERE
make -DALWAYS_CHECK_MAKE installkernel KERNCONF=YOUR_KERNEL_HERE

But at the very end of this procedure, I get:

[...]
===> zlib (install)
install -T release -o root -g wheel -m 555   zlib.ko /boot/kernel/
install -T debug -o root -g wheel -m 555   zlib.ko.debug
/usr/lib/debug/boot/kernel/
kldxref /boot/kernel
kldxref: unknown metadata record 4 in file atacard.ko
kldxref: unknown metadata record 4 in file atp.ko
kldxref: unknown metadata record 4 in file atp.ko
[...etc...]

Should I have started with "make buildworld," or would that have
bombed out even worse?  Do I reboot and "make buildworld"?  Or do
I "make buildworld" now, while still running 10.4?  -- George



signature.asc
Description: OpenPGP digital signature

Re: Upgrading via source build, 10.4->11.2

[George Mitchell]

On 12/4/18 9:35 PM, Warner Losh wrote:
> On Tue, Dec 4, 2018, 7:25 PM George Mitchell  [...]
>> kldxref /boot/kernel
>> kldxref: unknown metadata record 4 in file atacard.ko
>> kldxref: unknown metadata record 4 in file atp.ko
>> kldxref: unknown metadata record 4 in file atp.ko
>> [...etc...]
>>
>> Should I have started with "make buildworld," or would that have
>> bombed out even worse?  Do I reboot and "make buildworld"?  Or do
>> I "make buildworld" now, while still running 10.4?  -- George
>>
> 
> Just ignore the warnings. They are harmless.
> 
> Warner
> [...]

Thanks, that's what I expected.  But what I really need to know is
whether to make buildworld under 10.4 or 11.2.  Or do I do it twice?
And presumably I can't run mergemaster until after buildworld.
-- George



signature.asc
Description: OpenPGP digital signature

Re: Upgrading via source build, 10.4->11.2

[George Mitchell]

On 12/5/18 9:31 AM, Miroslav Lachman wrote:
> George Mitchell wrote on 2018/12/05 14:24:
>> [...]
>>  But what I really need to know is
>> whether to make buildworld under 10.4 or 11.2.  Or do I do it twice?
>> And presumably I can't run mergemaster until after buildworld.
> 
> I did upgrade from 10.4 to 11.2 on all our machines, just one builworld,
> buildkernel on shared build server (NFS exported /usr/obj + /usr/src),
> then installkernel, mergemaster -p, installworld, mergemaster, shutdown
> -r now.
> 
> Miroslav Lachman
> [...]

Thanks!  In the end, I did a buildworld under 10.4, reboot into 11.2,
mergemaster -p, installworld, mergemaster, reboot.  That all seemed to
work fine.  Today, out of caution, I'll do another buildworld,
buildkernel, installkernel, reboot, mergemaster -p, installworld,
mergemaster, reboot before I take the really big step: upgrading to a
Ryzen processor and from 8GB memory to 32GB.  Then I can worry about
ports.  I might get brave enough to try poudriere again, though so far
portmaster has done the job for me.

I use rsync to propagate /usr/src and /usr/obj to my other machines
so that I can installkernel and installworld on them in single user
mode (hard to use NFS when booting in single user).-- George



signature.asc
Description: OpenPGP digital signature

Re: DNS Flag Day and freebsd.org problems

[George Mitchell]

On 1/17/19 6:55 PM, David Magda wrote:
> Hello,
> 
> On February 1, 2019, there will be some major changes to DNS with regards to 
> EDNS:
> [...]
> It turns out that freebsd.org is effected by this:
> [...]
> Who is the person that should be looking at this for FreeBSD?
> [...]

According to freebsd.org's SOA record, that would be
hostmas...@freebsd.org.   -- George



signature.asc
Description: OpenPGP digital signature

Re: 11.4 sendmail with SASL and ports openssl?

[George Mitchell]

On 2020-08-11 09:49, Bengt Ahlgren wrote:
> I have since long compiled sendmail in base with SASL using a src.conf
> like this:
> 
> # sendmail with SASL required for outgoing SMTP AUTH, see:
> # https://www.freebsd.org/doc/en/books/handbook/SMTP-Auth.html
> # depends on port security/cyrus-sasl2
> SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL
> SENDMAIL_LDFLAGS=-L/usr/local/lib
> SENDMAIL_LDADD=-lsasl2
> 
> Since I'm still using 11.4, I had to start using openssl from ports due
> to qt5 5.15.  Then the above didn't work anymore, so a bit reluctantly I
> added -I/usr/local/include to the CFLAGS above, fearing that some other
> random include file could be picked up.  It however compiled and the
> resulting binary is linked thus:
> 
> # ldd /usr/obj/usr/src/usr.sbin/sendmail/sendmail
> /usr/obj/usr/src/usr.sbin/sendmail/sendmail:
> libsasl2.so.3 => /usr/local/lib/libsasl2.so.3 (0x8008db000)
> libutil.so.9 => /lib/libutil.so.9 (0x800af9000)
> libssl.so.11 => /usr/local/lib/libssl.so.11 (0x800d0d000)
> libcrypto.so.11 => /usr/local/lib/libcrypto.so.11 (0x80100)
> libwrap.so.6 => /usr/lib/libwrap.so.6 (0x8014cb000)
> libc.so.7 => /lib/libc.so.7 (0x8016d4000)
> libdl.so.1 => /usr/lib/libdl.so.1 (0x801a8b000)
> libthr.so.3 => /lib/libthr.so.3 (0x801c8c000)
> 
> Does this look right?  Are there any know issues with this?
> 
> Thanks,
> 
> Bengt
> [...]

I've run into enough problems over SSL with qt5 and FreeBSD 11 that I
have been running this command:

cd /usr/ports; svn update -r541317 Mk/Uses/qt.mk devel/qt5 */qt5-*

after every svn update to circumvent the very problem you're seeing.
For some reason or other, I haven't yet been able to muster a whole
lot of enthusiasm for updating to FreeBSD 12 yet. -- George



signature.asc
Description: OpenPGP digital signature

Upgrading, 11.4 -> 12.1

[George Mitchell]

1. Is there a way to shut "make delete-old" up?  For most minor
upgrades, of course, it never says anything.  But for an upgrade such
as this, it forces me to type "y" upwards of a hundred times.
All the things it's deleting look plausible to me and I've never had
occasion to tell it NOT to delete a file.  Is there a way to tell it
to just assume "y"?

2. I run X with no explicit configuration file, and this has gone
very well so far, but not today.  X starts up the display with no
problem, but it can't find any input devices.  The relevant part of
the server log says:

[16.719] (II) config/devd: probing input devices...
[16.719] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device
atkbd0
[16.719] (II) config/devd: detected event input: System keyboard
multiplexer, bustype=0006, vendor=, product=, version=
[16.719] (II) config/devd: adding input device /dev/input/event0
[16.719] (**) System keyboard multiplexer: Applying InputClass
"Evdev keyboard"
[16.719] (II) No input driver specified, ignoring this device.
[16.719] (II) This device may have been added with another device file.
[16.719] (EE) config/devd: error 1 adding device /dev/input/event0
[16.719] (II) config/devd: detected event input: System mouse,
bustype=0006, vendor=, product=, version=
[16.719] (II) config/devd: adding input device /dev/input/event1
[16.719] (II) No input driver specified, ignoring this device.
[16.719] (II) This device may have been added with another device file.
[16.719] (EE) config/devd: error 1 adding device /dev/input/event1
[16.719] (II) config/devd: detected event input: AT keyboard,
bustype=0011, vendor=0001, product=0001, version=
[16.719] (II) config/devd: adding input device /dev/input/event2
[16.719] (**) AT keyboard: Applying InputClass "Evdev keyboard"
[16.719] (II) No input driver specified, ignoring this device.
[16.719] (II) This device may have been added with another device file.
[16.719] (EE) config/devd: error 1 adding device /dev/input/event2
[16.719] (II) This device may have been added with another device file.
[16.719] (EE) config/devd: error 1 adding device /dev/input/event3
[16.719] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device
kbdmux0
[16.719] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device
sysmouse
[16.719] (II) config/devd: detected USB HID of unknown type
[16.719] (II) config/devd: [sysctl] usb_id: 0x046d:0xc31c
[16.719] (II) config/devd: [sysctl] vendor: USB, product: Keyboard
[16.719] (II) config/devd: adding input device /dev/uhid0
[16.719] (II) No input driver specified, ignoring this device.
[16.719] (II) This device may have been added with another device file.
[16.719] (EE) config/devd: error 1 adding device /dev/uhid0
[16.719] (II) config/devd: EVDEV_SUPPORT is enabled, ignoring device
ukbd0


Does this mean I need to provide a configuration file?  Where are the
input drivers it couldn't find?  Since I have so far tried the upgrade
on only one machine, the X server was compiled under 11.3:

X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
[11.901] Build Operating System: FreeBSD 11.3-RELEASE-p12 amd64
[11.901] Current Operating System: FreeBSD court 12.1-RELEASE-p8
FreeBSD 12.1-RELEASE-p8 r364978 M5P amd64
[11.901] Build Date: 26 August 2020  10:56:12AM

Help ...-- George



signature.asc
Description: OpenPGP digital signature

Re: Upgrading, 11.4 -> 12.1

[George Mitchell]

On 2020-08-31 15:47, Navdeep Parhar wrote:
> On 8/31/20 12:44 PM, George Mitchell wrote:
>> 1. Is there a way to shut "make delete-old" up?  For most minor
>> upgrades, of course, it never says anything.  But for an upgrade such
>> as this, it forces me to type "y" upwards of a hundred times.
>> All the things it's deleting look plausible to me and I've never had
>> occasion to tell it NOT to delete a file.  Is there a way to tell it
>> to just assume "y"?
>
> Use "make -DBATCH_DELETE_OLD_FILES ...".  See build(7) for details.
>
> Regards,
> Navdeep
>
Thank you, Navdeep and Lukasz!
-- George



signature.asc
Description: OpenPGP digital signature

Re: Upgrading, 11.4 -> 12.1

[George Mitchell]

On 2020-08-31 15:48, Kurt Jaeger wrote:
> Hi!
> [...]
>
> I'm guessing: Do you have the dbus and hald daemon running ?
>
> hald_enable="YES"
> dbus_enable="YES"
>
> in /etc/rc.conf ?
>
Yes, I do.  Should I disable them, then? -- George




signature.asc
Description: OpenPGP digital signature

Re: Upgrading, 11.4 -> 12.1

[George Mitchell]

On 2020-08-31 16:28, Kevin Oberman wrote:
> [...]
> This question would be both more appropriate and more likely to get a
> knowledgeable response if submitted to x11@. [...]

While waiting in vain for a response, I resorted to reading
/usr/ports/UPDATING and the install message for xorg-server.
After installing x11-drivers/xf86-input-libinpout and making sure
kern.evdev.rcpt_mask was set correctly, my problem was fixed.
Let this be a lesson to me!-- George



signature.asc
Description: OpenPGP digital signature

Re: Jenkins build is still unstable: FreeBSD_stable_10 #356

[George Mitchell]

On 08/08/16 18:56, jenkins-ad...@freebsd.org wrote:
> See 
> [...]

Can someone please clarify for me the distinction between
succeeding vs. failing and being stable vs. unstable?   -- George

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

Re: Jenkins build is still unstable: FreeBSD_stable_10 #356

[George Mitchell]

On 08/09/16 05:10, Craig Rodrigues wrote:
> 
> 
> On Mon, Aug 8, 2016 at 4:26 PM, George Mitchell  <mailto:george+free...@m5p.com>> wrote:
> [...]
> Can someone please clarify for me the distinction between
> succeeding vs. failing and being stable vs. unstable?   -- George
> 
> 
> Unstable means the build succeeded, but one of the tests is failing.
> [...]

Thanks for the explanation!-- George

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

Re: [Bug 211491] System hangs after "Uptime" on reboot with iSCSI, zfs, and altroot

[George Mitchell]

Will someone PLEASE remove freebsd-stable from the CC list of this
ticket?  Thank you. -- George

On 08/09/16 19:10, bugzilla-nore...@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211491
> 
> Ngie Cooper  changed:
> 
>What|Removed |Added
> 
>  CC|freebsd-b...@freebsd.org,   |n...@freebsd.org
>|freebsd-stable@FreeBSD.org  |
>Severity|Affects Many People |Affects Some People
> 
> --- Comment #13 from Ngie Cooper  ---
> Please don't add -current or -stable to bugs like this; it spams the list
> unnecessarily (this issue impacts users of iSCSI + ZFS -- which seems a bit
> niche right now)
> 

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

Re: Benchmarks results for FreeBSD 11

[George Mitchell]

On 08/23/16 02:32, Erich Dollansky wrote:
> Hi,
> 
> On Mon, 22 Aug 2016 03:22:35 +
> Kubilay Kocak  wrote:
> 
>> On Mon, 22 Aug 2016, 11:31 AM Mark Linimon 
>> wrote:
>>
>>> On Mon, Aug 22, 2016 at 09:57:24AM +1000, Dewayne Geraghty wrote:  
 unless knowledgable people respond publicly and/or in the phoronix
 forums [...] this interpretation of reality will be fixed in
 decision- makers' minds and consequently the uptake (and support)
 of FreeBSD.  
>>>
>>> IIRC this has been done before and hasn't really been productive.
>>> OTOH I don't recall the details.
>>>
>>> FreeBSD hasn't had a benchmarking guru since Kris Kennaway retired
>>> from working on FreeBSD.  
>>
>>
>> Michael has reached out off-list (thanks!) If anyone else is
>> interested, I'd be happy to create a dedicated IRC channel on
>> freenode to widen and focus the freebsd performance discussion net
>> and doc any outcomes/notes in the FreeBSD Wiki.
>>
> this is good. So, how can we help him to get things straight the next
> time?
> 
> Erich
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
Off-the-wall note: has anyone tried comparing SCHED_ULE to SCHED_BSD?
-- George
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Failing to upgrade from 10.1-RELEASE to 10.3-STABLE

[George Mitchell]

# freebsd-update -r 10.3-STABLE upgrade
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.1-RELEASE from update5.freebsd.org...
done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base world/lib32

The following components of FreeBSD do not seem to be installed:
world/doc world/games

Does this look reasonable (y/n)? y

Fetching metadata signature for 10.3-STABLE from update5.freebsd.org...
failed.
Fetching metadata signature for 10.3-STABLE from update4.freebsd.org...
failed.
Fetching metadata signature for 10.3-STABLE from update6.freebsd.org...
failed.
Fetching metadata signature for 10.3-STABLE from update3.freebsd.org...
failed.
No mirrors remaining, giving up.

What am I doing wrong?  (I get the same failure attempting to upgrade
to 10.1-RELEASE and 10.2-RELEASE.) -- George
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Failing to upgrade from 10.1-RELEASE to 10.3-STABLE

[George Mitchell]

On 10/09/16 15:57, Kurt Jaeger wrote:
> Hi!
> 
>> What am I doing wrong?  (I get the same failure attempting to upgrade
>> to 10.1-RELEASE and 10.2-RELEASE.) -- George
> 
> Ah, one thing:
> 
> Please do update to the latest 10.1-REL patch level, first.
> 
After upgrading to the latest 10.1-RELEASE:

I can update to 10.3-RELEASE, and that will probably do for now.
Should it have worked to update from 10.1-RELEASE to 10.3-STABLE
directly?  If I decide to upgrade from 10.3-RELEASE to 10.3-STABLE
later on, should I expect that to work?   -- George
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Failing to upgrade from 10.1-RELEASE to 10.3-STABLE

[George Mitchell]

On 10/10/16 03:04, Matthew Seaman wrote:
> [...]
> Most of the time you should be able to upgrade from any patch level of
> release to the latest on any supported release branch using
> freebsd-update(8).  However there have been a number of occasions where
> changes to freebsd-update itself cause that not to work.  This is one of
> those occasions.
> 
> As you've discovered, the answer is to update to the latest patch level
> of the branch you're already on, which will pull in the necessary fixes
> to freebsd-update(8), and then you can upgrade to a more recent branch.
> 
> As other people have noted, you can't use freebsd-update(8) to get to
> 10.3-STABLE -- for that, you need to build the OS from source.
> 
>   Cheers,
> 
>   Matthew
> 
> 
Thanks for the further details. -- George
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Clandestine USB SD card slot

[George Mitchell]

Whoops, I should send this to freebsd-stable instead of freebsd-usb.
Sorry! -- George

On 10/16/16 09:22, George Mitchell wrote:
> On 10/15/16 23:10, Anthony Jenkins wrote:
>> On 10/15/16 18:28, George Mitchell wrote:
>>> FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 18:38:15 UTC 2016
>>> Acer Aspire E15
>>> There is a slot on the front of this laptop which sure looks like an
>>> SD card slot, which I hope corresponds to one of these:
>>>
>>> ugen1.1:  at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
>>> pwr=SAVE (0mA)
>>> ugen0.1:  at usbus0, cfg=0 md=HOST spd=SUPER
>>> (5.0Gbps) pwr=SAVE (0mA)
>>> ugen2.1:  at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps)
>>> pwr=SAVE (0mA)
>>> ugen1.2:  at usbus1, cfg=0 md=HOST
>>> spd=HIGH (480Mbps) pwr=SAVE (100mA)
>>> ugen2.2:  at usbus2, cfg=0 md=HOST
>>> spd=HIGH (480Mbps) pwr=SAVE (100mA)
>>> ugen0.2:  at usbus0, cfg=0 md=HOST
>>> spd=SUPER (5.0Gbps) pwr=ON (224mA)
>>> ugen1.3:  at usbus1, cfg=0 md=HOST spd=FULL
>>> (12Mbps) pwr=SAVE (100mA)
>>> ugen2.3:  at usbus2, cfg=0 md=HOST
>>> spd=FULL (12Mbps) pwr=ON (100mA)
>>> ugen1.4:  at usbus1, cfg=0 md=HOST
>>> spd=LOW (1.5Mbps) pwr=ON (100mA)
>>> ugen1.5:  at usbus1, cfg=0 md=HOST spd=FULL
>>> (12Mbps) pwr=SAVE (100mA)
>>> ugen1.6:  at usbus1, cfg=0 md=HOST
>>> spd=FULL (12Mbps) pwr=ON (100mA)
>>> ugen1.7:  at usbus1, cfg=0 md=HOST
>>> spd=FULL (12Mbps) pwr=ON (100mA)
>>> ugen1.8:  at usbus1, cfg=0 md=HOST
>>> spd=HIGH (480Mbps) pwr=ON (500mA)
>>>
>>> But inserting a card into the slot produces no results, even with
>>> sysctl hw.usb.umass.debug=1 hw.usb.ugen.debug=1 hw.usb.dev.debug=1.
>>> (sysctl hw.usb.debug=1 produces way too much output all the time.)
>>> Any suggestions on how I can get this slot to overcome its shyness?
>>> (I am not subscribed to the list; please CC me.)  -- George
>> Your card reader is probably on the PCI bus (and likely not supported by
>> FreeBSD); I couldn't find any of your USB Pid:Vids as card readers.
>>
>> [ajenkins@ajenkins-hplaptop ~]$ pciconf -lv
>> ...
>> none2@pci0:3:0:0:   class=0xff card=0x1995103c chip=0x522910ec
>> rev=0x01 hdr=0x00
>> vendor = 'Realtek Semiconductor Co., Ltd.'
>> device = 'RTS5229 PCI Express Card Reader'
>>
>> Anthony Jenkins
>>
> Ah!  It didn't occur to me to run pciconf.  "pciconf -lv" shows this:
> 
> sdhci_pci0@pci0:0:20:7:   class=0x080501 card=0x08651025 chip=0x78131022
> rev=0x01 hdr=0x00
> vendor = 'Advanced Micro Devices, Inc. [AMD]'
> device = 'FCH SD Flash Controller'
> class  = base peripheral
> subclass   = SD host controller
> 
> So not only is it (apparently) recognized, but the sdhci_pci driver
> attached to it!  But inserting or removing a card shows no activity.
> What's my next step?  -- George
> 

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

Re: Clandestine USB SD card slot

[George Mitchell]

On 10/16/16 14:16, Warner Losh wrote:
> On Sun, Oct 16, 2016 at 12:08 PM, Warren Block  wrote:
>> On Sun, 16 Oct 2016, George Mitchell wrote:
>>
>>>> So not only is it (apparently) recognized, but the sdhci_pci driver
>>>> attached to it!  But inserting or removing a card shows no activity.
>>>> What's my next step?  -- George
>>
>>
>> Is a device created for the empty reader?  It's worth trying to force a
>> retaste of that device with 'true > /dev/daX' after the card is inserted.
> 
> Don't look for da anything. Look for mmcsd something. The sdhci_pci
> driver provides disks that are mmcsdX. Looks like card change
> interrupts aren't happening, or there's something else making the
> driver unhappy with the SDHCI controller though...
> 
> Warner
> [...]

No /dev/mm*; no log output on card insertion/removal even with
sysctl hw.sdhci.debug=1.  Other sysctl info:

sysctl -a | grep sdhci
device  sdhci
hw.sdhci.enable_msi: 1
hw.sdhci.debug: 1
dev.sdhci_pci.0.%parent: pci0
dev.sdhci_pci.0.%pnpinfo: vendor=0x1022 device=0x7813 subvendor=0x1025
subdevice=0x0865 class=0x080501
dev.sdhci_pci.0.%location: pci0:0:20:7
dev.sdhci_pci.0.%driver: sdhci_pci
dev.sdhci_pci.0.%desc: Generic SD HCI
dev.sdhci_pci.%parent:

-- George

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

Re: Clandestine USB SD card slot

[George Mitchell]

On 10/16/16 17:40, George Mitchell wrote:
> On 10/16/16 14:16, Warner Losh wrote:
>> On Sun, Oct 16, 2016 at 12:08 PM, Warren Block  wrote:
>>> On Sun, 16 Oct 2016, George Mitchell wrote:
>>>
>>>>> So not only is it (apparently) recognized, but the sdhci_pci driver
>>>>> attached to it!  But inserting or removing a card shows no activity.
>>>>> What's my next step?  -- George
>>>
>>>
>>> Is a device created for the empty reader?  It's worth trying to force a
>>> retaste of that device with 'true > /dev/daX' after the card is inserted.
>>
>> Don't look for da anything. Look for mmcsd something. The sdhci_pci
>> driver provides disks that are mmcsdX. Looks like card change
>> interrupts aren't happening, or there's something else making the
>> driver unhappy with the SDHCI controller though...
>>
>> Warner
>> [...]
> 
> No /dev/mm*; no log output on card insertion/removal even with
> sysctl hw.sdhci.debug=1.  Other sysctl info:
> 
> sysctl -a | grep sdhci
> devicesdhci
> hw.sdhci.enable_msi: 1
> hw.sdhci.debug: 1
> dev.sdhci_pci.0.%parent: pci0
> dev.sdhci_pci.0.%pnpinfo: vendor=0x1022 device=0x7813 subvendor=0x1025
> subdevice=0x0865 class=0x080501
> dev.sdhci_pci.0.%location: pci0:0:20:7
> dev.sdhci_pci.0.%driver: sdhci_pci
> dev.sdhci_pci.0.%desc: Generic SD HCI
> dev.sdhci_pci.%parent:
> 
> -- George
> 
After setting hw.sdhci.debug=1 and hw.mmc.debug=1 in /etc/sysctl.conf
and doing a verbose boot, then inserting and removing an SD card, all
I get in "dmesg | egrep mmc\|sdhci" is:

sdhci_pci0:  mem 0xf0c6c000-0xf0c6c0ff irq 16 at device
20.7 on pci0
sdhci_pci0: 1 slot(s) allocated
sdhci_pci0:  mem 0xf0c6c000-0xf0c6c0ff irq 16 at device
20.7 on pci0
sdhci_pci0-slot0: 50MHz 8bits 3.3V DMA
sdhci_pci0-slot0: == REGISTER DUMP ==
sdhci_pci0-slot0: Sys addr: 0x | Version:  0x1001
sdhci_pci0-slot0: Blk size: 0x | Blk cnt:  0x
sdhci_pci0-slot0: Argument: 0x | Trn mode: 0x
sdhci_pci0-slot0: Present:  0x01f2 | Host ctl: 0x
sdhci_pci0-slot0: Power:0x | Blk gap:  0x
sdhci_pci0-slot0: Wake-up:  0x | Clock:0x
sdhci_pci0-slot0: Timeout:  0x | Int stat: 0x
sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
sdhci_pci0-slot0: AC12 err: 0x | Slot int: 0x00ff
sdhci_pci0-slot0: Caps: 0x21de32b2 | Max curr: 0x00c80064
sdhci_pci0-slot0: ===
sdhci_pci0: 1 slot(s) allocated

(Same for "egrep mmc\|sdhci /var/log/messages".)

"pciconf -lv" suggests this is a:
sdhci_pci0@pci0:0:20:7: class=0x080501 card=0x08651025 chip=0x78131022
rev=0x01 hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'FCH SD Flash Controller'
class  = base peripheral
subclass   = SD host controller

Are there some quirks I should define for this controller?  -- George
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Clandestine USB SD card slot

[George Mitchell]

On 10/17/16 11:02, George Mitchell wrote:
> [...]
> After setting hw.sdhci.debug=1 and hw.mmc.debug=1 in /etc/sysctl.conf
> and doing a verbose boot, then inserting and removing an SD card, all
> I get in "dmesg | egrep mmc\|sdhci" is:
> 
> sdhci_pci0:  mem 0xf0c6c000-0xf0c6c0ff irq 16 at device
> 20.7 on pci0
> sdhci_pci0: 1 slot(s) allocated
> sdhci_pci0:  mem 0xf0c6c000-0xf0c6c0ff irq 16 at device
> 20.7 on pci0
> sdhci_pci0-slot0: 50MHz 8bits 3.3V DMA
> sdhci_pci0-slot0: == REGISTER DUMP ==
> sdhci_pci0-slot0: Sys addr: 0x | Version:  0x1001
> sdhci_pci0-slot0: Blk size: 0x | Blk cnt:  0x
> sdhci_pci0-slot0: Argument: 0x | Trn mode: 0x
> sdhci_pci0-slot0: Present:  0x01f2 | Host ctl: 0x
> sdhci_pci0-slot0: Power:0x | Blk gap:  0x
> sdhci_pci0-slot0: Wake-up:  0x | Clock:0x
> sdhci_pci0-slot0: Timeout:  0x | Int stat: 0x
> sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb
> sdhci_pci0-slot0: AC12 err: 0x | Slot int: 0x00ff
> sdhci_pci0-slot0: Caps: 0x21de32b2 | Max curr: 0x00c80064
> sdhci_pci0-slot0: ===
> sdhci_pci0: 1 slot(s) allocated
> 
> (Same for "egrep mmc\|sdhci /var/log/messages".)
> 
> "pciconf -lv" suggests this is a:
> sdhci_pci0@pci0:0:20:7: class=0x080501 card=0x08651025 chip=0x78131022
> rev=0x01 hdr=0x00
> vendor = 'Advanced Micro Devices, Inc. [AMD]'
> device = 'FCH SD Flash Controller'
> class  = base peripheral
> subclass   = SD host controller
> 
> Are there some quirks I should define for this controller?  -- George
> 

For those coming in late:
FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 18:38:15 UTC 2016 -- George
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: huge nanosleep variance on 11-stable

[George Mitchell]

On 11/01/16 23:45, Kevin Oberman wrote:
> On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening 
> wrote:
> 
>> Sorry, that should be ~*30ms* to get 30fps, though the variance is still
>> up to 500ms for me either way.
>>
>> On 11/01/16 14:29, Jason Harmening wrote:
>>> repro code is at http://pastebin.com/B68N4AFY if anyone's interested.
>>>
>>> On 11/01/16 13:58, Jason Harmening wrote:
 Hi everyone,

 I recently upgraded my main amd64 server from 10.3-stable (r302011) to
 11.0-stable (r308099).  It went smoothly except for one big issue:
 certain applications (but not the system as a whole) respond very
 sluggishly, and video playback of any kind is extremely choppy.

 [...]
> I eliminated the annoyance by change scheduler from ULE to 4BSD. That was
> it, but I have not seen the issue since. I'd be very interested in whether
> the scheduler is somehow impacting timing functions or it's s different
> issue. I've felt that there was something off in ULE for some time, but it
> was not until these annoying hiccups convinced me to try going back to
> 4BSD.
> 
> Tip o' the hat to Doug B. for his suggestions that ULE may have issues that
> impacted interactivity.
> [...]

Not to beat a dead horse, but I've been a non-fan of SCHED_ULE since
it was first introduced, and I don't like it even today.  I run the
distributed.net client on my machines, but even without that, ULE
screws interactive behavior.  With distributed.net running and ULE,
a make buildworld/make buildkernel takes 10 2/3 hours on 10.3-RELEASE
on a 6-CPU machine versus 2 1/2 hours on the same machine with 4BSD
and distributed.net running.  I'm told that SCHED_ULE is the greatest
thing since sliced bread for some compute load or other (details are
scarce), but I (fortunately) don't often have to run heavy server
type loads; and for everyday use (even without distributed.net
running), SCHED_4BSD is my choice by far.  It's too bad I can't run
freebsd_update with it, though.

I promise to shut up about this now.   -- George
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ath0 associated, wlan0 not associated

[George Mitchell]

Originally posted to freebsd-wireless; no solution yet so I thought
I'd try here.  After booting up, my ath0 interface says it is
associated, but my wlan0 says it is not:


FreeBSD 10.3-RELEASE-p11
wpa_supplicant v2.0
Copyright (c) 2003-2012, Jouni Malinen  and contributors

ath0@pci0:2:0:0:class=0x028000 card=0x064211ad chip=0x0036168c rev=0x01
hdr=0x00
vendor = 'Qualcomm Atheros'
device = 'QCA9565 / AR9565 Wireless Network Adapter'
class  = network

grep wlan /etc/rc.conf:
create_args_wlan0="country US"
ifconfig_wlan0="WPA DHCP"
wlans_ath0="wlan0"

And the result is:

ifconfig wlan0:
wlan0: flags=8c43 metric
0 mtu 1500
ether d0:53:49:91:6f:a1
inet6 fe80::d253:49ff:fe91:6fa1%wlan0 prefixlen 64 scopeid 0x4
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
nd6 options=23
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid "" channel 2 (2417 MHz 11g ht/40+)
regdomain FCC country US indoor ecm authmode WPA2/802.11i privacy ON
deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS
ampdulimit 8k ampdudensity 8 shortgi wme burst roaming MANUAL

ifconfig ath0:
ath0: flags=8843 metric 0 mtu 2290
ether d0:53:49:91:6f:a1
nd6 options=21
media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng
status: associated

grep wpa /var/log/messages:
ov  1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Trying to associate
with xx:xx:xx:xx:xx:xx (SSID='yy' freq=2417 MHz)
Nov  1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Associated with
60:e3:27:7b:e8:42
Nov  1 09:16:54 haymarket wpa_supplicant[389]: wlan0: WPA: Key
negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
Nov  1 09:16:54 haymarket wpa_supplicant[389]: wlan0:
CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=1
id_str=]
Nov  1 09:16:55 haymarket wpa_supplicant[389]: wlan0: WPA: Key
negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
Nov  1 09:16:56 haymarket wpa_supplicant[389]: wlan0: WPA: Key
negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
Nov  1 09:16:57 haymarket wpa_supplicant[389]: wlan0: WPA: Key
negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
Nov  1 09:16:57 haymarket wpa_supplicant[389]: wlan0:
CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx reason=0
Nov  1 09:16:59 haymarket wpa_supplicant[389]: wlan0: Trying to
associate with xx:xx:xx:xx:xx:xx (SSID='yy' freq=2417 MHz)
Nov  1 09:17:09 haymarket wpa_supplicant[389]: wlan0: Authentication
with xx:xx:xx:xx:xx:xx timed out.
Nov  1 09:17:09 haymarket wpa_supplicant[389]: wlan0:
CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx2 reason=3
locally_generated=1
Nov  1 09:18:13 haymarket wpa_supplicant[389]: wlan0: Trying to
associate with xx:xx:xx:xx:xx:xx (SSID='yy' freq=2417 MHz

etc.

So how does ath0 get associated but not wlan0?   -- George

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

Re: ath0 associated, wlan0 not associated

[George Mitchell]

Thanks for the suggestion.  I won't be able to try it until after a
business trip next week.  Any patches available that apply to 10.3?
-- George

On 11/03/16 18:48, Adrian Chadd wrote:
> hi,
> 
> can you please try freebsd-11.0 ? I fixed a whole bunch of bugs in the
> AR9380 HAL and it may have improved that device.
> 
> Thanks!
> 
> 
> -a
> 
> 
> On 3 November 2016 at 07:09, George Mitchell  wrote:
>> Originally posted to freebsd-wireless; no solution yet so I thought
>> I'd try here.  After booting up, my ath0 interface says it is
>> associated, but my wlan0 says it is not:
>>
>>
>> FreeBSD 10.3-RELEASE-p11
>> wpa_supplicant v2.0
>> Copyright (c) 2003-2012, Jouni Malinen  and contributors
>>
>> ath0@pci0:2:0:0:class=0x028000 card=0x064211ad chip=0x0036168c 
>> rev=0x01
>> hdr=0x00
>> vendor = 'Qualcomm Atheros'
>> device = 'QCA9565 / AR9565 Wireless Network Adapter'
>> class  = network
>>
>> grep wlan /etc/rc.conf:
>> create_args_wlan0="country US"
>> ifconfig_wlan0="WPA DHCP"
>> wlans_ath0="wlan0"
>>
>> And the result is:
>>
>> ifconfig wlan0:
>> wlan0: flags=8c43 metric
>> 0 mtu 1500
>> ether d0:53:49:91:6f:a1
>> inet6 fe80::d253:49ff:fe91:6fa1%wlan0 prefixlen 64 scopeid 0x4
>> inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255
>> nd6 options=23
>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
>> status: no carrier
>> ssid "" channel 2 (2417 MHz 11g ht/40+)
>> regdomain FCC country US indoor ecm authmode WPA2/802.11i privacy ON
>> deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS
>> ampdulimit 8k ampdudensity 8 shortgi wme burst roaming MANUAL
>>
>> ifconfig ath0:
>> ath0: flags=8843 metric 0 mtu 2290
>> ether d0:53:49:91:6f:a1
>> nd6 options=21
>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng
>> status: associated
>>
>> grep wpa /var/log/messages:
>> ov  1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Trying to associate
>> with xx:xx:xx:xx:xx:xx (SSID='yy' freq=2417 MHz)
>> Nov  1 09:16:54 haymarket wpa_supplicant[389]: wlan0: Associated with
>> 60:e3:27:7b:e8:42
>> Nov  1 09:16:54 haymarket wpa_supplicant[389]: wlan0: WPA: Key
>> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
>> Nov  1 09:16:54 haymarket wpa_supplicant[389]: wlan0:
>> CTRL-EVENT-CONNECTED - Connection to xx:xx:xx:xx:xx:xx completed [id=1
>> id_str=]
>> Nov  1 09:16:55 haymarket wpa_supplicant[389]: wlan0: WPA: Key
>> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
>> Nov  1 09:16:56 haymarket wpa_supplicant[389]: wlan0: WPA: Key
>> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
>> Nov  1 09:16:57 haymarket wpa_supplicant[389]: wlan0: WPA: Key
>> negotiation completed with xx:xx:xx:xx:xx:xx [PTK=CCMP GTK=TKIP]
>> Nov  1 09:16:57 haymarket wpa_supplicant[389]: wlan0:
>> CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx reason=0
>> Nov  1 09:16:59 haymarket wpa_supplicant[389]: wlan0: Trying to
>> associate with xx:xx:xx:xx:xx:xx (SSID='yy' freq=2417 MHz)
>> Nov  1 09:17:09 haymarket wpa_supplicant[389]: wlan0: Authentication
>> with xx:xx:xx:xx:xx:xx timed out.
>> Nov  1 09:17:09 haymarket wpa_supplicant[389]: wlan0:
>> CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx2 reason=3
>> locally_generated=1
>> Nov  1 09:18:13 haymarket wpa_supplicant[389]: wlan0: Trying to
>> associate with xx:xx:xx:xx:xx:xx (SSID='yy' freq=2417 MHz
>>
>> etc.
>>
>> So how does ath0 get associated but not wlan0?   -- George
>>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 

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

Re: ath0 associated, wlan0 not associated

[George Mitchell]

On 11/05/16 01:05, Adrian Chadd wrote:
> nope, sorry.  There's a lot of work in the -11 wifi stack and drivers.
> 
> 
> -a
> 
> [...]

Okay, I downloaded and installed 11.0-RELEASE on a spare slice, and
dmesg tells me the following (with regard to ath0):


ath0:  mem 0xf0a0-0xf0a7 irq 36 at
device 0.0 on pci2
ath0: WB335 2-ANT card detected
ath0: Bluetooth Antenna Diversity card detected
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 RX streams; 1 TX streams
ath0: QCA9565 mac 704.1 RF5110 phy 2523.1
ath0: 2GHz radio: 0x; 5GHz radio: 0x

But ifconfig tells me there is no "ath0" interface ... Does 11.0
handle wifi in some unfamiliar manner?  I put my usual wifi magic
into rc.conf:

create_args_wlan0="country US"
ifconfig_wlan0="WPA DHCP"
wlans_ath0="wlan0"

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

Re: ath0 associated, wlan0 not associated

[George Mitchell]

On 11/05/16 13:00, George Mitchell wrote:
> On 11/05/16 01:05, Adrian Chadd wrote:
>> nope, sorry.  There's a lot of work in the -11 wifi stack and drivers.
>>
>>
>> -a
>>
>> [...]
> 
> Okay, I downloaded and installed 11.0-RELEASE on a spare slice, and
> dmesg tells me the following (with regard to ath0):
> 
> 
> ath0:  mem 0xf0a0-0xf0a7 irq 36 at
> device 0.0 on pci2
> ath0: WB335 2-ANT card detected
> ath0: Bluetooth Antenna Diversity card detected
> ath0: [HT] enabling HT modes
> ath0: [HT] enabling short-GI in 20MHz mode
> ath0: [HT] 1 stream STBC receive enabled
> ath0: [HT] 1 RX streams; 1 TX streams
> ath0: QCA9565 mac 704.1 RF5110 phy 2523.1
> ath0: 2GHz radio: 0x; 5GHz radio: 0x
> 
> But ifconfig tells me there is no "ath0" interface ... Does 11.0
> handle wifi in some unfamiliar manner?  I put my usual wifi magic
> into rc.conf:
> 
> create_args_wlan0="country US"
> ifconfig_wlan0="WPA DHCP"
> wlans_ath0="wlan0"
> 
> -- George
> 
I forgot to copy my wpa_supplicant.conf over.  Now it works!  (I
guess the invisible ath0 is just how 11.0 works?)  -- George
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Symbol/library versioning ...

[George Mitchell]

... is a topic I just marginally understand.  But pkg 1.9.3 fails
on FreeBSD 10.1-RELEASE-p35 because /lib/libc.so.7 contains no
definition for "openat", though /lib/libc.so.7 on 10.3-RELEASE-p11
does define it.  I confess to being baffled.  How is this supposed
to work?  10.1-RELEASE is still supported, right?-- George
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Symbol/library versioning ...

[George Mitchell]

On 11/15/16 11:24, Konstantin Belousov wrote:
> On Tue, Nov 15, 2016 at 10:59:57AM -0500, George Mitchell wrote:
>> ... is a topic I just marginally understand.  But pkg 1.9.3 fails
>> on FreeBSD 10.1-RELEASE-p35 because /lib/libc.so.7 contains no
>> definition for "openat", though /lib/libc.so.7 on 10.3-RELEASE-p11
>> does define it.  I confess to being baffled.  How is this supposed
>> to work?  10.1-RELEASE is still supported, right?-- George
> 
> Let me guess.  You are trying to run a pkg binary, built on 10.3 system,
> on the 10.1 system, do you ?  If yes, this is not supported and often
> breaks.
> _[...]

... oops ... that's exactly what I did.  Sorry for the noise.  -- George

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

10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

After today's OpenSSH security message, I did:

cd /usr
rm -rf obj
cd src
svn update -r311916
make buildworld

After a while, I got to:

building shared library libc.so.7
cc (a very long compile line)
./libc.so.7: unsupported file layout
*** Error code 1

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

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

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

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

Stop.
make: stopped in /usr/src

freebsd-version -ku
10.3-RELEASE-p13
10.3-RELEASE-p15

I am using a generic kernel, except for using SCHED_4BSD.  If it
weren't for that, I would just use freebsd-update.

Googling suggests that my build tree is somehow mixing up 32 and 64
bit files.  (I'm running on an amd64 machine.)  How do I get this
cleared up? -- George



signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 17:25, Dimitry Andric wrote:
> On 11 Jan 2017, at 21:24, George Mitchell  wrote:
>>
>> After today's OpenSSH security message, I did:
>>
>> cd /usr
>> rm -rf obj
> 
> Hmm, not sure if it is wise to completely remove the /usr/obj directory.
> Did you re-create it afterwards?

In the past, "make buildworld" has taken care of that (as far as I
could tell).

> 
> 
>> cd src
>> svn update -r311916
>> make buildworld
>>
>> After a while, I got to:
>>
>> building shared library libc.so.7
>> cc (a very long compile line)
>> ./libc.so.7: unsupported file layout
> 
> If things went correctly, the libc.so.7 file should be in
> /usr/obj/usr/src/lib/libc.  If so, can you post the output of:
> 
> file /usr/obj/usr/src/lib/libc/libc.so.7
> readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
> 
> -Dimitry
> 
root@sullivan:/usr/src # file /usr/obj/usr/src/lib/libc/libc.so.7
/usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit LSB shared object,
x86-64, version 1 (FreeBSD), dynamically linked, not stripped
root@sullivan:/usr/src # readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - FreeBSD
  ABI Version:   0
  Type:  DYN (Shared object file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x3aee0
  Start of program headers:  64 (bytes into file)
  Start of section headers:  1644696 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 6
  Size of section headers:   64 (bytes)
  Number of section headers: 40
  Section header string table index: 37

That isn't the only libc.so.7 in my build tree, though:

/usr/obj/usr/src/tmp/lib/libc.so.7:ELF 64-bit LSB shared object,
x86-64, version 1 (FreeBSD), dynamically linked, not stripped
/usr/obj/usr/src/lib/libc/libc.so.7:   ELF 64-bit LSB shared object,
x86-64, version 1 (FreeBSD), dynamically linked, not stripped
/usr/obj/lib32/usr/src/lib/libc/libc.so.7: ELF 32-bit LSB shared object,
Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped




signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 17:20, Kevin Oberman wrote:
> [...]
> 
> While I have no suggestions about the error building libc, your statement
> that you can't use freebsd-update due to your use of a custom kernel is
> incorrect. This is a common misconception and, in cases of very limited
> disk space, may be true, it is rare. It is helped by the fact that the man
> page makes no mention of how to so this. (You do still need to build a new
> kernel if the update does, indeed, touch the kernel.)
> 
> All you need is a GENERIC kernel in /boot/GENERIC. You can either build it
> or download it. See the FreeBSD Handbook Section 23.2.3.1, “Custom Kernels
> with FreeBSD 9.X and Later”
> 
> for details on downloading a GENERIC kernel. Before any upgrade, major or
> minor, you might wat to re-reas that section.
> 
> Once the GENERIC kernel is in /boot, you may use freebsd-update and, if the
> GENERIC kernel is not updated, you're good to go. If it is, you will need
> to build and install a new custom kernel and reboot. Since most security
> patches don't touch the kernel, this is usually not needed. I believe that
> the 10.3 kernel was last touched in p11.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
Thanks, I'll try that the next time I have a chance.  When I naively
tried a straight "freebsd-update" a few months ago, of course it
overwrote my SCHED_4BSD kernel with a SCHED_ULE one.-- George



signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 17:40, Dimitry Andric wrote:
> On 11 Jan 2017, at 23:35, George Mitchell  wrote:
>>
>> On 01/11/17 17:25, Dimitry Andric wrote:
>>> On 11 Jan 2017, at 21:24, George Mitchell  wrote:
> ...
>>>> building shared library libc.so.7
>>>> cc (a very long compile line)
>>>> ./libc.so.7: unsupported file layout
>>>
>>> If things went correctly, the libc.so.7 file should be in
>>> /usr/obj/usr/src/lib/libc.  If so, can you post the output of:
>>>
>>> file /usr/obj/usr/src/lib/libc/libc.so.7
>>> readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
>>>
>>> -Dimitry
>>>
>> root@sullivan:/usr/src # file /usr/obj/usr/src/lib/libc/libc.so.7
>> /usr/obj/usr/src/lib/libc/libc.so.7: ELF 64-bit LSB shared object,
>> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
>> root@sullivan:/usr/src # readelf -h /usr/obj/usr/src/lib/libc/libc.so.7
>> ELF Header:
>>  Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00
>>  Class: ELF64
>>  Data:  2's complement, little endian
>>  Version:   1 (current)
>>  OS/ABI:UNIX - FreeBSD
>>  ABI Version:   0
>>  Type:  DYN (Shared object file)
>>  Machine:   Advanced Micro Devices X86-64
>>  Version:   0x1
>>  Entry point address:   0x3aee0
>>  Start of program headers:  64 (bytes into file)
>>  Start of section headers:  1644696 (bytes into file)
>>  Flags: 0x0
>>  Size of this header:   64 (bytes)
>>  Size of program headers:   56 (bytes)
>>  Number of program headers: 6
>>  Size of section headers:   64 (bytes)
>>  Number of section headers: 40
>>  Section header string table index: 37
>>
>> That isn't the only libc.so.7 in my build tree, though:
>>
>> /usr/obj/usr/src/tmp/lib/libc.so.7:ELF 64-bit LSB shared object,
>> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
>> /usr/obj/usr/src/lib/libc/libc.so.7:   ELF 64-bit LSB shared object,
>> x86-64, version 1 (FreeBSD), dynamically linked, not stripped
>> /usr/obj/lib32/usr/src/lib/libc/libc.so.7: ELF 32-bit LSB shared object,
>> Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
> 
> Hm, that all looks perfectly normal, supposing that you are on amd64.
> Maybe it's the stripping that fails?  Do you have STRIP defined in your
> environment, or make.conf?
> 
> -Dimitry
> 
No, STRIP is not defined anywhere.  -- George



signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 15:24, George Mitchell wrote:
> After today's OpenSSH security message, I did:
> 
> cd /usr
> rm -rf obj
> cd src
> svn update -r311916
> make buildworld
> 
> After a while, I got to:
> 
> building shared library libc.so.7
> cc (a very long compile line)
> ./libc.so.7: unsupported file layout
> *** Error code 1
> 
> Stop.
> make[4]: stopped in /usr/src/lib/libc
> *** Error code 1
> 
> Stop.
> make[3]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src
> 
> freebsd-version -ku
> 10.3-RELEASE-p13
> 10.3-RELEASE-p15
> 
> I am using a generic kernel, except for using SCHED_4BSD.  If it
> weren't for that, I would just use freebsd-update.
> 
> Googling suggests that my build tree is somehow mixing up 32 and 64
> bit files.  (I'm running on an amd64 machine.)  How do I get this
> cleared up? -- George
> 
For the sake of completeness, here's the complete build log that
terminated in the above error:  http://m5p.com/typescript.xz
-- George



signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 17:46, George Mitchell wrote:
> On 01/11/17 17:20, Kevin Oberman wrote:
>> [...]
>>
>> While I have no suggestions about the error building libc, your statement
>> that you can't use freebsd-update due to your use of a custom kernel is
>> incorrect. This is a common misconception and, in cases of very limited
>> disk space, may be true, it is rare. It is helped by the fact that the man
>> page makes no mention of how to so this. (You do still need to build a new
>> kernel if the update does, indeed, touch the kernel.)
>>
>> All you need is a GENERIC kernel in /boot/GENERIC. You can either build it
>> or download it. See the FreeBSD Handbook Section 23.2.3.1, “Custom Kernels
>> with FreeBSD 9.X and Later”
>> <https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html#freebsd-update-custom-kernel-9x>
>> for details on downloading a GENERIC kernel. Before any upgrade, major or
>> minor, you might wat to re-reas that section.
>>
>> Once the GENERIC kernel is in /boot, you may use freebsd-update and, if the
>> GENERIC kernel is not updated, you're good to go. If it is, you will need
>> to build and install a new custom kernel and reboot. Since most security
>> patches don't touch the kernel, this is usually not needed. I believe that
>> the 10.3 kernel was last touched in p11.
>> --
>> Kevin Oberman, Part time kid herder and retired Network Engineer
>> E-mail: rkober...@gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>> ___
>> freebsd-stable@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>>
> Thanks, I'll try that the next time I have a chance.  When I naively
> tried a straight "freebsd-update" a few months ago, of course it
> overwrote my SCHED_4BSD kernel with a SCHED_ULE one.-- George
> 
Just to refresh my memory of what happened a few months ago, I tried
the following experiment.  I copied my current modified kernel:

rsync -av /boot/kernel/ /boot/my.kernel/

Then with my modified kernel still in place, I said:

freebsd-update fetch
freebsd-update install

With not a qualm in the world, freebsd-update installed a fresh
SCHED_ULE kernel in /boot.  (Happily, it did save my current kernel
in /boot/kernel.old.)  That's what happened last year, too.  Why
didn't freebsd-update notice that I had a modified kernel and at
least notify me that something funky was going on?  -- George



signature.asc
Description: OpenPGP digital signature

Re: 10.3-RELEASE-p13 "unsupported file layout"

[George Mitchell]

On 01/11/17 15:24, George Mitchell wrote:
> After today's OpenSSH security message, I [tried a buildworld and]
>  got to:
> 
> building shared library libc.so.7
> cc (a very long compile line)
> ./libc.so.7: unsupported file layout
> [...]

I never did figure out the cause of this problem, but I did my
buildworld on another machine with no problem.  Then I rsync'd
/usr/src and /usr/obj back to the first machine and installed
the world.  Afterwards, I did one more buildworld on the first
machine, and it succeeded.  I think my original /usr/src tree
might have been corrupt, though I really don't know.  At least
everything is working now.   -- George



signature.asc
Description: OpenPGP digital signature

Re: Freebsd 11 - /usr/bin missing [xl]zgrep/zegrep/zfgrep

[George Mitchell]

On 03/22/17 00:07, Kyle Evans wrote:
> [...]
> For grep(1) to be GNU grep while xzgrep to secretly be a link to BSD
> grep would be quite surprising to me as a user/admin, especially since
> there are very real output and argument differences between the two.
> [...]
It would not surprise me.  Knowing, to begin with, that GNU grep does
not support uncompressing its input, I would *never* expect bzgrep
(etc.) to link to GNU grep.-- George




signature.asc
Description: OpenPGP digital signature

Re: Ryzen issues on FreeBSD (can we sum up yet)?

[George Mitchell]

On 02/12/18 16:49, Don Lewis wrote:
> [...]
> I'm having really good luck with the kernel patch attached to this
> message:
> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=417183+0+archive/2018/freebsd-hackers/20180211.freebsd-hackers
> 
> Since applying that patch, I did three poudriere runs to build the set
> of ~1700 ports that I use.  Other than one gmake-related build runaway
> that I've also seen on my AMD FX-8320E, I didn't see any random port
> build failures.  When I was last did some testing a few weeks ago,
> lang/go would almost always fail.  I also would seem random build
> failures in lang/guile or finance/gnucash (which uses guile during its
> build) on both my Ryzen and FX-8320E machines, but those built cleanly
> all three times.
> 
> I even built samba 16 times in a row without a hang.
> [...]

Until this thread started last year, I had been on the verge of
upgrading the build server on my net to a Ryzen.  Needless to say, I
postponed the change.  Now it seems there is hope that a resolution for
the issue may be in sight.  Is it time to survey everyone's experience
with the problem, and determine whether the cited patch helps?  My
sincere thanks in advance.  -- George



signature.asc
Description: OpenPGP digital signature

Re: Stability of 11.1S

[George Mitchell]

On 03/21/18 04:51, Eitan Adler wrote:
> On 19 March 2018 at 22:59, Dewayne Geraghty
>  wrote:
>> [...]
>> PS Normally I would bisect, but we're converting 2 large PROLOG applications
>> to erlang... (prayers welcome)
> [...]

What next, converting a FORTH application to LISP?  (Sorry, couldn't
resist ...)-- George



signature.asc
Description: OpenPGP digital signature

Re: kern.sched.quantum: Creepy, sadistic scheduler

[George Mitchell]

On 04/04/18 06:39, Alban Hertroys wrote:
> [...]
> That said, SCHED_ULE (the default scheduler for quite a while now) was 
> designed with multi-CPU configurations in mind and there are claims that 
> SCHED_4BSD works better for single-CPU configurations. You may give that a 
> try, if you're not already on SCHED_4BSD.
> [...]

A small, disgruntled community of FreeBSD users who have never seen
proof that SCHED_ULE is better than SCHED_4BSD in any environment
continue to regularly recompile with SCHED_4BSD.  I dread the day when
that becomes impossible, but at least it isn't here yet.  -- George



signature.asc
Description: OpenPGP digital signature

Re: kern.sched.quantum: Creepy, sadistic scheduler

[George Mitchell]

On 04/04/18 10:34, Peter wrote:
> [...] It does not make sense to me if now we state that
> we cannot do it anymore because single-CPU is uncommon today.
> [...]
+1.-- George



signature.asc
Description: OpenPGP digital signature

Re: more data: SCHED_ULE+PREEMPTION is the problem

[George Mitchell]

On 04/07/18 10:18, Peter wrote:
> [...]
> B. Findings:
> 
> 1. Filesystem
> 
> I could never reproduce this when reading from plain UFS. Only when
> reading from ZFS (direct or via l2arc).
> [...]
My consistent way of reproducing the problem was to run ports/misc/dnetc
while trying to buildworld/buildkernel.  But I was always building on a
UFS partition.  I don't know why your results would be different.
-- George



signature.asc
Description: OpenPGP digital signature

more data: SCHED_ULE+PREEMPTION is the problem

[George Mitchell]

On 04/07/18 10:18, Peter wrote:
> Hi all,
> [...]
Thanks for all the investigation!
> 3. kern.sched.preempt_thresh
> 
> I could make the problem disappear by changing kern.sched.preempt_thresh
>  from the default 80 to either 11 (i5-3570T) or 7 (p3) or smaller. This
> seems to correspond to the disk interrupt threads, which run at intr:12
> (i5-3570T) or intr:8 (p3).
> [...]

More data.  With SCHED_4BSD at FreeBSD 10.4-RELEASE-p8 #0 r331984:
kern.sched.runq_fuzz: 1
kern.sched.ipiwakeup.useloop: 0
kern.sched.ipiwakeup.usemask: 1
kern.sched.ipiwakeup.delivered: 376139898
kern.sched.ipiwakeup.requested: 376137875
kern.sched.ipiwakeup.enabled: 1
kern.sched.slice: 12
kern.sched.quantum: 94488
kern.sched.name: 4BSD
kern.sched.preemption: 1
kern.sched.cpusetsize: 8
With dnetc running on a 6-core AMD CPU from a few years back,
"time make buildworld" yields:

6640.224u 828.874s 2:14:37.73 92.4% 28525+494k 31633+431554io 33192pf+0w

I shifted to a GENERIC kernel, FreeBSD 10.4-RELEASE-p8 #0 r332560:
kern.sched.topology_spec: 
 
  0, 1, 2, 3, 4, 5
  
   
0, 1, 2, 3, 4, 5
   
  
 


kern.sched.steal_thresh: 2
kern.sched.steal_idle: 1
kern.sched.balance_interval: 127
kern.sched.balance: 1
kern.sched.affinity: 1
kern.sched.idlespinthresh: 157
kern.sched.idlespins: 1
kern.sched.static_boost: 152
kern.sched.preempt_thresh: 80
kern.sched.interact: 30
kern.sched.slice: 12
kern.sched.quantum: 94488
kern.sched.name: ULE
kern.sched.preemption: 1
kern.sched.cpusetsize: 8

I stupidly typed "make buildworld" without the "time" command, but the
build log started at Mon Apr 16 13:49:12 EDT 2018 and completed at
Tue Apr 17 00:22:23 EDT 2018.  You read that right: 2+ hours vs 10 1/2!
So I set "sysctl kern.sched.preempt_thresh=5" (a wild guess on my part)
and started another "time make buildworld".  It's still going now, but
subjectively it's still running like molasses.  I'll post more results
later after trying sysctl kern.sched.preempt_thresh=0.

By the way, over the years that this discussion has been going on, I've
*never* had a response to my question: "What is the workload for which
SCHED_ULE outperforms SCHED_4BSD?"-- George




signature.asc
Description: OpenPGP digital signature

Re: kern.sched.quantum: Creepy, sadistic scheduler

[George Mitchell]

On 04/17/18 17:20, EBFE via freebsd-stable wrote:
> On Tue, 17 Apr 2018 09:05:48 -0700
> Freddie Cash  wrote:
> 
>> # Tune for desktop usage
>> kern.sched.preempt_thresh=224
>>
>> ​Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor
>> (3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU.
> 
> For interactive tasks, there is a "special" tunable:
> % sysctl kern.sched.interact
> kern.sched.interact: 10 # default is 30
> % sysctl -d kern.sched.interact
> kern.sched.interact: Interactivity score threshold
> 
> reducing the value from 30 to 10-15 keeps your gui/system responsive,
> even under high load.
> [...]

I suspect my case (make buildworld while running misc/dnetc) doesn't
qualify.  However, I just completed a SCHED_ULE run with
preempt_thresh set to 5, and "time make buildworld" reports:
7336.748u 677.085s 9:25:19.86 23.6% 27482+473k 42147+431581io 38010pf+0w
Much closer to SCHED_4BSD!  I'll try preempt_thresh=0 next, and I
guess I'll at least try preempt_thresh=224 to see how that works
for me. -- George



signature.asc
Description: OpenPGP digital signature

Re: kern.sched.quantum: Creepy, sadistic scheduler

[George Mitchell]

On 04/17/18 19:01, George Mitchell wrote:
> On 04/17/18 17:20, EBFE via freebsd-stable wrote:
>> [...]
>> For interactive tasks, there is a "special" tunable:
>> % sysctl kern.sched.interact
>> kern.sched.interact: 10 # default is 30
>> % sysctl -d kern.sched.interact
>> kern.sched.interact: Interactivity score threshold
>>
>> reducing the value from 30 to 10-15 keeps your gui/system responsive,
>> even under high load.
>> [...]
> 
> I suspect my case (make buildworld while running misc/dnetc) doesn't
> qualify.  However, I just completed a SCHED_ULE run with
> preempt_thresh set to 5, and "time make buildworld" reports:
> 7336.748u 677.085s 9:25:19.86 23.6% 27482+473k 42147+431581io 38010pf+0w
> Much closer to SCHED_4BSD!  I'll try preempt_thresh=0 next, and I
> guess I'll at least try preempt_thresh=224 to see how that works
> for me. -- George
> 
I've now done SCHED_ULE runs with preempt_thresh set to 0, 1, 5, 80,
and 224.  The wall clock time is uniformly in the vicinity of 10 hours.
The "time" output is consistent with SCHED_4BSD, but the wall clock
time is really what I care about.

Now I have set kern.sched.preempt_thresh back to the default of 80 and
I am experimenting with kern.sched.interact.  I'm pretty sure that
setting kern.sched.preempt_thresh is not the answer to my problem.
-- George



signature.asc
Description: OpenPGP digital signature

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[George Mitchell]

> On Wed, 30 May 2018 15:50:39 +
> Glen Barber  wrote:
> 
>> Hi,
>>
>> Could folks please help boot-test the most recent 12.0-CURRENT amd64
>> memstick images on various hardware?  Note, this is not a request to
>> install 12.0-CURRENT, only a boot-test with various system knobs
>> tweaked.
>>
>> The most recent images are available at:
>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img
>>
>> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
>> would like to get this included in the upcoming 11.2-RELEASE if the
>> change that had been committed addresses several boot issues reported
>> recently.
>>
>> Please help test, and report back (both successes and failures).
>>
>> Thanks,
>>
>> Glen
>>
> 
> 

Acer Aspire E15 (E5-521-844N)

Boots in Legacy mode.  In UEFI mode, the BIOS forced secure boot
and would not allow me to boot from the image.

This laptop is generally not recommended for FreeBSD.  I bought it
because of the A8 processor and the 1TB disk.  But the disk is as slow
as molasses and the keyboard tends to drop spaces and returns.  The
Radeon R5 graphics work in VESA mode, and I was able to get better
performance at an earlier stage of 11-STABLE, but I have seemingly
forgotten the correct magic to get kernel mode setting to work on
11-BETA.-- George



signature.asc
Description: OpenPGP digital signature

Re: PRERELEASE back?

[George Mitchell]

On 06/02/18 11:14, Kevin Oberman wrote:
> After teh announcement of RC1 I updated my 11-STABLE box, expecting wither
> that I would see RC1 or STABLE, depending on whether the 11.2 BRANCH had
> been created, but instead I am "back" at 11.2-PRERELEASE #1.
> 
> Is this intentional? At least it is confusing.
> [...]
It appears that the immediate cause is:

Revision 334460 - Directory Listing
Modified Fri Jun 1 00:28:29 2018 UTC (39 hours, 4 minutes ago) by gjb

Rename stable/11 back to -PRERELEASE for the duration of the
11.2-RELEASE cycle, now that releng/11.2 had branched.

Bump __FreeBSD_version.

Approved by:re (implicit)
Sponsored by:   The FreeBSD Foundation

-- George



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD 11.2-RC1 Now Available

[George Mitchell]

On 06/01/18 21:31, Glen Barber wrote:
> [...]
> If you would like to use SVN to do a source based update of an existing
> system, use the "stable/11" branch.
> [...]

So what's releng/11.2, chopped liver?  -- George



signature.asc
Description: OpenPGP digital signature

fence_wait returned with error -512?

[George Mitchell]

Any idea what this means?

Jun  9 19:57:43 haymarket kernel: fence_wait returned with error -512
Jun  9 19:59:52 haymarket kernel: fence_wait returned with error -512
Jun  9 20:00:40 haymarket kernel: fence_wait returned with error -512
Jun  9 20:11:30 haymarket last message repeated 19 times
Jun  9 20:21:46 haymarket last message repeated 14 times
Jun  9 20:29:30 haymarket last message repeated 13 times
Jun  9 20:55:28 haymarket kernel: fence_wait returned with error -512
Jun  9 21:19:44 haymarket kernel: fence_wait returned with error -512
Jun  9 21:23:20 haymarket last message repeated 2 times
Jun  9 21:39:23 haymarket last message repeated 3 times
Jun  9 21:44:28 haymarket last message repeated 5 times
Jun  9 21:59:42 haymarket last message repeated 5 times
Jun  9 22:09:16 haymarket last message repeated 4 times
Jun  9 22:18:57 haymarket last message repeated 8 times
Jun  9 23:47:45 haymarket kernel: fence_wait returned with error -512
Jun 10 05:50:07 haymarket kernel: fence_wait returned with error -512
Jun 10 05:54:42 haymarket kernel: fence_wait returned with error -512
Jun 10 07:10:39 haymarket kernel: fence_wait returned with error -512

FreeBSD 11.2-RC1 #0 r334470 on an amd64; machine was doing an overnight
build of a bunch of ports.  No obvious sign of distress.-- George



signature.asc
Description: OpenPGP digital signature

Ryzen consensus

[George Mitchell]

Based on people's recent Ryzen experiences, is it fair to say that
FreeBSD 11.2 is now believed to work on Ryzens, if you have a recent
enough Ryzen and your motherboard has been updated to the latest BIOS?
-- George



signature.asc
Description: OpenPGP digital signature

Re: Ryzen consensus

[George Mitchell]

Thanks to all who responded!  I guess it's off to Microcenter this
week.  -- George



signature.asc
Description: OpenPGP digital signature