Re: Can't forward X11 apps over ssh since migrating to 13-CURRENT

[O'Connor, Daniel]

> On 22 Sep 2020, at 08:06, Patrick McMunn  wrote:
> I don't know if it's just coincidental or if it's because of some change in
> 13-CURRENT, but I recently migrated from 12.1-STABLE, and now I am unable
> to forward X11 apps over ssh. The only app I was accustomed to running this
> way was Handbrake. It worked fine before, but now i get this:
> 
> $ ghb
> Unable to init server: Could not connect to 127.0.0.1: Connection refused
> 
> (ghb:87219): Gtk-WARNING **: 13:12:41.281: cannot open display:
> 
> I have tried other apps like Wireshark and even xclock just to see, but
> they won't work either. Has anyone else had problems with X11 forwarding on
> 13-CURRENT? If it's working for everyone else, at least I can know it's
> probably not 13-CURRENT's fault, and I need to look elsewhere for the
> cause. And yes, my sshd_config has it enabled. It worked fine before, and I
> made sure to keep the same config.

What is the value of DISPLAY? (ie echo $DISPLAY)

Is sshd listening on that port? eg..
[test 3:36] ~> echo $DISPLAY
localhost:11.0
[test 3:36] ~> sockstat|grep 6011
radarsshd   5414  8  tcp6   ::1:6011  *:*
radarsshd   5414  9  tcp4   127.0.0.1:6011*:*

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


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

Re: Lockdown adaX numbers to allow booting ?

[O'Connor, Daniel]

> On 14 Oct 2019, at 19:08, Kurt Jaeger  wrote:
> 
> Hi!
> 
> You're probably looking for this:
> https://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html
 
 Would glabel solve it?
>>> 
>>> The disks are not gpart-formatted, they are used raw.
>> 
>> What file system are they formatted with?
> 
> ZFS, see
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2019-September/074398.html

Given this:
https://lists.freebsd.org/pipermail/freebsd-current/2019-September/074395.html

I think your problem is far earlier than changing ada probe order will help.

It would seem more likely to be a BIOS or BTX problem :(

I would definitely try moving ada0 and ada1 to the first SATA ports to see if 
that helps.

Does anything show up on the VGA console?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


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

Re: Lockdown adaX numbers to allow booting ?

[O'Connor, Daniel]

> On 21 Sep 2019, at 02:36, Garrett Wollman  
> wrote:
> 
> In article <20190920155304.gn3...@zxy.spb.ru>, s...@zxy.spb.ru writes:
> 
>> Location of device in multi-chassis storage system is different story.
>> I am don't know how to field engineer insert disks in chassis.
>> For me simple is find in /var/run/dmesg.boot S/N <=> daXY mapping and
>> turn ON led by sas2ircu.
> 
> sesutil does this for you!
> 
> # sesutil locate daXY on
> # sesutil locate daXY off
> 
> So long as your enclosure supports SES (all the modern ones I've seen
> do) and is enumerable by ses(4).

FWIW I find it doesn't work on the Supermicro chassis (SYS-5019S-MR) we use 
with SATA disks.
[chumphon 2:42] ~> sudo sesutil locate ada0 on
sesutil: Count not find the SES id of device 'ada0'

(Also I just noticed a spelling error in the above, "Count" should be "Could")

[chumphon 2:42] ~> sudo sesutil map
ses0:
Enclosure Name: AHCI SGPIO Enclosure
Enclosure ID:0
Element 0, Type: Array Device Slot
Status: Unsupported (0x00 0x00 0x00 0x00)
Element 1, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 000
Element 2, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 001
Element 3, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 002
Element 4, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 003
Element 5, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 004
Element 6, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 005
Element 7, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 006
Element 8, Type: Array Device Slot
Status: Unknown (0x06 0x00 0x00 0x00)
Description: SLOT 007

Using led(4) works:
echo 1 | sudo tee /dev/led/ahci0.X.fault 
(The X lines up with the "ahcich4" part of dmesg for adaX)
although I find you can only turn the LED on and not off which limits it's 
usefulness somewhat..

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


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

Re: Lockdown adaX numbers to allow booting ?

[O'Connor, Daniel]

> On 14 Oct 2019, at 03:17, Kurt Jaeger  wrote:
>>> You're probably looking for this:
>>> https://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html
>> 
>> Would glabel solve it?
> 
> The disks are not gpart-formatted, they are used raw.

What file system are they formatted with?
UFS has both labels and IDs which show up in /dev/ufs and /dev/ufsid 
respectively.

(see the glabel man page)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


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

Re: nvdXpY dissapears while ZFS pool on it is imported

[O'Connor, Daniel]

> On 6 Oct 2019, at 01:06, Bernd Walter  wrote:
> 
> On Sat, Oct 05, 2019 at 02:50:21PM +0900, Tomoaki AOKI wrote:
>> Hi.
>> 
>> By sets of commits starting from r351355 though r351747, nvd driver
>> creates partitioned GEOM provider like /dev/nvd0p1.
>> 
>> Unfortunately, these partitioned GEOM providers dissapears when
>> importing ZFS pool on it leaving /dev/nvd0, and re-appears when
>> exporting the pool.
>> 
>> Mounting filesystems other than ZFS (at least msdosfs) doesn't
>> affect.
> 
> It is not ZFS itself, it is the use of /dev/diskid/*, which ZFS prefers
> to open.
> Either explicitly import the volume with /dev/nvd* or use the other
> partitions with /dev/diskid/*
> What really sucks is that volume labels also disappear - e.g. /dev/msdosfs.

It Would Be Nice (tm) if all of the aliases were symlinks pointing to the 
canonical device which didn't disappear when it was opened.

No idea how feasible that is though :)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


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

Re: ipv6/ppp: FreeBSD obtains linklocal on tun0 only

[O'Connor, Daniel]

> On 3 Dec 2018, at 08:15, O. Hartmann  wrote:
> 
> 
> The documentation lacks in many aspects how to deal with IPv6, especially 
> when it comes
> to "well known things from the old IPv4 world". Since DDNS also is still 
> something people
> use with IPv6, MYADDR6 doesn't carry the IPV6 address obtained after rtsold 
> has been
> started and rtsol tun0 has been issued as described above (MYADDR6/HISADDR6 
> are assigned
> with the linklocal addresses).

FWIW I use dhcp6c to get an IPv6 range from my ISP.

My /usr/local/etc/dhcp6c.conf looks like..

interface ng0 {
send ia-pd 0;
};

id-assoc pd {
prefix-interface bridge0 {
sla-id 0;
sla-len 8;
};
};

I am using mpd5 for PPPoE and bridge0 is my LAN interface.

My /etc/rtadvd.conf looks like..
# Leaving rltime at the default gives 
http://www.freebsd.org/cgi/query-pr.cgi?pr=162547
# setting it to 0 prevents it being used as a router. Setting to 1800 (the 
putative default)
# works..
bridge0:\
:rltime#1800:\
:rdnss="xxx":\
:dnssl="yyy":

where xxx is the IPv6 address of my server and yyy is my domain.

(I'm not sure if the comment regarding rltime is true any more though but it 
works so I don't touch it ;)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


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

Re: Testing requested: Hybrid ISO/USB boot

[O'Connor, Daniel]

> On 24 Mar 2018, at 07:31, Benno Rice  wrote:
> I think I’ve addressed this in this revision:
> 
> https://svnweb.freebsd.org/changeset/base/331463 
> 
> 
> And I’ve regenerated the image here:
> 
> https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz 
> 

Hi Benno,
I tried this image on a Supermicro SYS-5019S-M (X11SSH-Fmotherboard) and it 
boots both ways (USB was via a USB stick, ISO was via the IPMI CD emulation 
with the Java JNLP applet)

The USB way booted legacy and the CD emulation booted UEFI (not sure if that's 
significant).

I also tried renaming it to .img and then telling the JNLP applet it was a hard 
disk image but the BIOS didn't detect it.

It also has a 'Web ISO' option but I can't figure out how you're supposed to 
enter a URL so I couldn't try it.

Thanks for the work!

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: USB stack

[O'Connor, Daniel]

> On 4 Jan 2018, at 09:23, Gary Jennejohn  wrote:
>> What is an "LG v30"?
>> 
> It's a smartphone from LG and only supports USB2 speed.  The reported
> transfer rate is no big surprise.

OK thanks.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: USB stack

[O'Connor, Daniel]

> On 3 Jan 2018, at 11:56, blubee blubeeme <gurenc...@gmail.com> wrote:
> On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel <dar...@dons.net.au> wrote:
> 
> 
> > On 3 Jan 2018, at 11:31, blubee blubeeme <gurenc...@gmail.com> wrote:
> > Does FreeBSD current USB stack support usb >= 2.0 devices?
> 
> Absolutely.
> 
> > Testing out the USB devices support I get about 7.2-7.8 megabytes per
> > second which seems odd.
> 
> What sort of test? What sort of device? What sort of port?
> 
> What is the output of dmesg and usbconfig?
> 
> I transferred about 30GB of audio from laptop to Samsung usb class 10 usb 
> device connected to LG v30.
> 
> current usbconfig shows this:
> ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) 
> pwr=SAVE (0mA)
> ugen0.3:  at usbus0, cfg=0 md=HOST 
> spd=HIGH (480Mbps) pwr=ON (500mA)
> ugen0.2:  at usbus0, cfg=0 md=HOST spd=FULL 
> (12Mbps) pwr=ON (100mA)

Ugh, your mail client has mangled things, oh well.

You missed posting the output of dmesg..

What is an "LG v30"?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: USB stack

[O'Connor, Daniel]

> On 3 Jan 2018, at 11:31, blubee blubeeme  wrote:
> Does FreeBSD current USB stack support usb >= 2.0 devices?

Absolutely.

> Testing out the USB devices support I get about 7.2-7.8 megabytes per
> second which seems odd.

What sort of test? What sort of device? What sort of port?

What is the output of dmesg and usbconfig?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: RFC: Removing hpt* drivers from GENERIC

[O'Connor, Daniel]

> On 26 Oct 2017, at 08:13, Colin Percival  wrote:
> My reason for wanting to remove them is that the hpt27xx and hptnr drivers
> spend ~150 ms in their DEVICE_PROBE routines every time the system boots.
> Since they are roughly 1000x slower than the median driver, this is clearly
> excessive; unfortunately the time is being spent inside a binary blob, so
> there is no apparent way to fix the drivers.  (The other three drives from
> the same vendor -- hptiop, hptmv, and hptrr -- don't exhibit this particular
> bug, but I don't see any strong argument in favour of not removing them along
> with the two problem drivers.)
> 
> All of these are available via kernel modules, so the impact upon users
> should be minimal.  Obviously I would not plan on MFCing this change.

Seems sensible to me, but also worth contacting the blob authors if possible 
and asking them what gives (and if they can fix it).

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Destroy GPT partition scheme absolutely, how?

[O'Connor, Daniel]

> On 27 Sep 2016, at 14:28, Warner Losh  wrote:
> dd of 2MB of zeros to the start and end of the disk. That will destroy
> pretty much everything. For SSDs, sometimes you can do the same with
> TRIMs only faster (other times they are slower or unreliable).

Yeah, but it would be nicer to not have to know that particular magic 
incarnation :)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Destroy GPT partition scheme absolutely, how?

[O'Connor, Daniel]

> On 27 Sep 2016, at 06:21, John Baldwin  wrote:
> That doesn't always work.  In particular, if a disk was partitioned with GPT
> and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the
> MBR will leave most of the GPT intact and the disk will come up with the old
> GPT partitions, not as a raw disk.

I wonder how feasible it would be to have a command which runs destroy for 
every known partition scheme on a particular device..

Sure there would be some duplicate zeroing but it's not likely to be 
significantly slower and considerably more robust.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Somethign missing in my environment?

[O'Connor, Daniel]

> On 18 Aug 2016, at 20:59, Willem Jan Withagen  wrote:
>> 
>> Remove NO_CLEAN et al and delete /usr/obj/* then try again.
> 
> It is running single thread, but compiling clang is a rather hefty build.

Yes but you are having weird issues so.. Time to go back to basics :)

>> Has it ever worked for you? When did it stop? What changed then?
> 
> Ehhh, , having asked customers that question plenty of time. I give
> the answer reluctantly...
> 
> But it has been working on this server from the day I installed it,
> which is somewhere around end of 2013. last time I used it was around
> May this year, to get a then uptodate current.
> Now I want to go forward again, but this was the result.
> 
> I could/will try to build it on another amd64 server and install from there.

Clean /usr/obj and leave it run overnight :)

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Somethign missing in my environment?

[O'Connor, Daniel]

> On 18 Aug 2016, at 06:12, Willem Jan Withagen  wrote:
> 
>> There's nothing immediately obvious.  I suggest trying without the
>> "-DNOCLEAN -DNO_CLEAN" - they are shortcuts that aren't guaranteed to
>> work under all circumstances.  And if that still fails, skip the '-j8'
>> because it's possible there are still race conditions in buildworld
>> (though that is very unlikely).
> 
> Been there, done that, in all kinds of variations, but no go.
> 
> Where should is definition normally come from?
> /usr/obj/usr/srcs/head/src/tmp/usr/lib/libgcc_s.so: undefined reference
> to `__gxx_personality_v0'
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [h_raw.full] Error code 1
> 
> Or should it be available in libgcc_s.so, and did it not get include in
> a bizare way

Remove NO_CLEAN et al and delete /usr/obj/* then try again.

Has it ever worked for you? When did it stop? What changed then?

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Passwordless accounts vi ports!

[O'Connor, Daniel]

> On 11 Aug 2016, at 14:35, O. Hartmann  wrote:
> [...]
> Checking for passwordless accounts:
> polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin
> pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin
> saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh
> clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin
> bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin
> [...]

My clamav and pulse users have a password field of * - i.e. they're disabled 
(AND the shell is nologin)

I suspect this is a bug in the check not the ports.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Passwordless accounts vi ports!

[O'Connor, Daniel]

> On 11 Aug 2016, at 15:36, O'Connor, Daniel <dar...@dons.net.au> wrote:
> My clamav and pulse users have a password field of * - i.e. they're disabled 
> (AND the shell is nologin)
> 
> I suspect this is a bug in the check not the ports.

Sorry, I just saw your next email, please disregard.

It does indeed look like a bug then, I don't have a -current box handy to repro 
though sorry :(

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Digi Watchport/T temperature sensor as /dev/ttyU

[O'Connor, Daniel]

> On 23 Jul 2016, at 02:05, O. Hartmann  wrote:
> 
> I tried to load any available USB serial port/adaptor driver available to 
> make this
> sensor attach as a ttyU? as it does in Linux (/dev/ttyUSB), but no luck so 
> far. I'm not
> familiar with serial consoles or the derial capabilities of FreeBSD, so i 
> might have
> overseen something essential. I'd like to access the sensor to retrieve 
> temperature data,
> even if it is in a crude way. Poking around with USB, I found that the sensor 
> device does
> release some informations, so hopefully there is a way to make it look like a 
> tty, see my
> attempts to get some informations out of the device below.

Do you know what driver picks it up in Linux?
It's pretty likely you just need to add an entry in one of the existing drivers 
to tell it about this device.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Read-only /usr/obj/ no longer kosher?

[O'Connor, Daniel]

 On 27 Aug 2015, at 08:25, Pawel Jakub Dawidek p...@freebsd.org wrote:
 On Tue, Aug 25, 2015 at 03:32:35PM -0700, NGie Cooper wrote:
 On Tue, Aug 25, 2015 at 3:21 PM, Xin Li delp...@delphij.net wrote:
 On 08/25/15 14:55, Pawel Jakub Dawidek wrote:
 Now that I think of it, it might have been that I did
 buildworld/buildkernel before -p1. Then freebsd-update updated
 newvers.sh and then I was trying to do installworld.
 
 Yes, I can now reproduce it with source updated to -p2.
 
 Yes, that's because freebsd-version.sh is generated from the files (but
 it's not clear to me whether if it's a bug or a feature that 'make
 install' checks if it's up-to-date and decides to regenerate it...).
 
 It's a quirk for sure. If you change the behavior, people will
 definitely complain as they will now need to go back and rebuild
 everything.
 
 What we have now is misleading. People should recompile. It is rather
 rare to see security advisory which bumps only patch level and something
 that doesn't require recompilation (eg. a shell script). Current
 behaviour would make people think they are running latest patch level
 because freebsd-version says so, eventhough they only did 'make
 installworld' without rebuilding affected binaries.

So..
How hard would it be to force CC/CXX to /usr/bin/false during installworld?

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)

[O'Connor, Daniel]

 On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
 
 O'Connor, Daniel dar...@dons.net.au wrote:
 However, Crochet _does_ build on the NFS client _and_ when the source
 tree isn't in /usr/src which makes this issue very strange :-/
 
 I've seen similar errors in rescue... (no NFS) though I cannot 
 quite recall the cause other than it seems very sensitive
 to MAKEOBJDIRPREFIX value.

Yeah the subject is wrong (I just updated it).

I just did a build like so and it worked..
env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld

But this did not..
make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64

So, it seems MAKEOBJDIRPREFIX only works as an environmental variable - I 
wonder if there is a way the make system can be changed to warn about that?

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)

[O'Connor, Daniel]

 On 20 Jul 2015, at 04:29, Simon J. Gerraty s...@juniper.net wrote:
 O'Connor, Daniel dar...@dons.net.au wrote:
 
 But this did not..
 make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64
 
 Nor should it.
 There are several makefiles in the tree that expect to be able to 
 change MAKEOBJDIRPREFIX in the environment of a sub-make.
 When you set it on the command line like that you prevent such changes
 from working.

Ahh.. You learn something new every day :)

 So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
 
 Yes, it has always been documented that way.

Weird, I could have sworn I have set it on the command line and had it work, 
but..

 - I wonder if there is a way the make system can be changed to warn
 about that?
 
 I thought there was a check in src/Makefile for that.

Not so far as I can tell - it certainly gets quite far before blowing up with a 
non useful error message :)

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)

[O'Connor, Daniel]

 On 20 Jul 2015, at 11:40, Simon J. Gerraty s...@juniper.net wrote:
 
 O'Connor, Daniel dar...@dons.net.au wrote:
 So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
 
 Weird, I could have sworn I have set it on the command line and had it
 work, but..
 
 In most normal usage you will likely not notice a difference.
 It is only when a makefile is being clever that things go south when
 you break its expectations.

I guess, buildworld is pretty clever though :)

 I thought there was a check in src/Makefile for that.
 
 Not so far as I can tell - it certainly gets quite far before blowing
 up with a non useful error message :)
 
 The check in src/Makefile is only guarding against MAKEOBJDIRPREFIX set
 in say make.conf, it explicitly discards the possibility of setting
 MAKEOBJDIRPREFIX on command line - which seems wrong.
 
 Also with bmake, you *can* usefully set MAKEOBJDIRPREFIX in a makefile
 since the choice of .OBJDIR can be made after make starts reading
 makefiles.
 
 So the current test is perhaps out dated on that score too - though
 only if something like auto.obj.mk is being used (-DWITH_AUTO_OBJ)
 which I don't think I've tested with buildworld.

I know sod all about *make but as an 'end user' a seat belt to warn about this 
problem would be Really Nice (tm).

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: -current broken when src is on NFS

[O'Connor, Daniel]

 On 18 Jul 2015, at 13:59, Tim Kientzle t...@kientzle.com wrote:
 Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already 
 set it to something else.  (This avoids cross-polluting the builds if you do 
 regular manual cross-builds on the same machine.)
 
 If you’re having issues with /usr/obj being on NFS, that could be a factor.

I removed NFS from the equation by building on the machine holding the source 
and it still bombs out.

However, Crochet _does_ build on the NFS client _and_ when the source tree 
isn't in /usr/src which makes this issue very strange :-/

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: -current broken when src is on NFS

[O'Connor, Daniel]

 On 17 Jul 2015, at 14:27, O'Connor, Daniel dar...@dons.net.au wrote:
 On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
 r285066 fixed a POLA violation w.r.t. the old NFS client where the new
 client didn't return an EEXIST error return for symlink or mkdir to userland.
 The behaviour of not returning this error to userland (which was inherited 
 from
 OpenBSD and was not the behaviour of the old FreeBSD NFS client but was 
 default
 for the new NFS client) can be enabled via:
 vfs.nfs.ignore_eexist=1
 
 You could try setting that sysctl and seeing if it makes any difference?
 
 That is the only recent change to the NFS client that *might* affect this.
 
 No dice :(
 
 It's pretty weird, it bombs out if either src or obj is on NFS..
 But even weirder is that if I build with crochet (a wrapper for cross 
 building to arm) it works. It doesn't work if I cross build manually and I 
 haven't been able to determine why crochet works yet.
 
 Relly frustraing :(

So, it turns out NFS is not an issue.. I think it must be that it's not on 
/usr/src.

I changed to building on the NFS server (which runs 10 but building -current 
should work OK) and it still bombs out.
--- rescue.all__D ---
make[5]: make[5]: don't know how to make 
/src/obj-amd64//src/FreeBSD-SVN/rescue/rescue//src/FreeBSD-SVN/bin/cat/cat.o. 
Stop

That still doesn't explain how crochet and freebsd-wifi-build work though - I 
thought it was because they don't build rescue, but crochet does.

Does anyone else see this?

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

-current broken when src is on NFS

[O'Connor, Daniel]

I am seeing the following breakage when building -current and the source is on 
NFS

make -j 4 buildworld
...
--- rescue.all__D ---
--- rescue ---
MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk exe
--- sbin.all__D ---
--- pfctl_qstats.o ---
cc  -O2 -pipe   -Wall -Wmissing-prototypes -Wno-uninitialized 
-Wstrict-prototypes -DENABLE_ALTQ -I/src/FreeBSD-HEAD/sbin/pfctl -DWITH_INET6 
-DWITH_INET -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter -Qunused-arguments -c 
/src/FreeBSD-HEAD/sbin/pfctl/pfctl_qstats.c -o pfctl_qstats.o
--- rescue.all__D ---
--- cat_stub.c ---
echo int _crunched_cat_stub(int argc, char **argv, char **envp){return 
main(argc,argv,envp);} cat_stub.c
make[5]: make[5]: don't know how to make 
/usr/obj/src/FreeBSD-HEAD/rescue/rescue//src/FreeBSD-HEAD/bin/cat/cat.o. Stop

make[5]: stopped in /usr/obj/src/FreeBSD-HEAD/rescue/rescue
*** [rescue] Error code 2

I copied this source tree to /usr/src (UFS) and it built fine - I guess it's 
possible it is barfing on the path name but I figure someone else would have 
noticed that.

The NFS server is running 10.0-RELEASE and the NFS client is running -current 
r285456, lockd is running and seems to be working (e.g., cat -l works)

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: -current broken when src is on NFS

[O'Connor, Daniel]

 On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
 r285066 fixed a POLA violation w.r.t. the old NFS client where the new
 client didn't return an EEXIST error return for symlink or mkdir to userland.
 The behaviour of not returning this error to userland (which was inherited 
 from
 OpenBSD and was not the behaviour of the old FreeBSD NFS client but was 
 default
 for the new NFS client) can be enabled via:
 vfs.nfs.ignore_eexist=1
 
 You could try setting that sysctl and seeing if it makes any difference?
 
 That is the only recent change to the NFS client that *might* affect this.

No dice :(

It's pretty weird, it bombs out if either src or obj is on NFS..
But even weirder is that if I build with crochet (a wrapper for cross building 
to arm) it works. It doesn't work if I cross build manually and I haven't been 
able to determine why crochet works yet.

Relly frustraing :(

 To be honest, I have no idea what the correct behaviour for // in a 
 pathname is?

Nothing, they just get eaten. This isn't AmigaDOS! :)

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: gettimeofday((void *)-1, NULL) implicates core dump on recent FreeBSD 11-CURRENT

[O'Connor, Daniel]

 On 8 Jul 2015, at 08:11, Garrett Wollman woll...@hergotha.csail.mit.edu 
 wrote:
 Perhaps the test was (erroneously) written to assume that
 gettimeofday() was a system call, and could therefore detect invalid
 pointers and return [EFAULT].  This has not been the case for some
 time.  (In HEAD, not since r237434, which is three years ago.)

In defence of the test, the man page says it can return EFAULT.

(IMO the man page and test should change..)

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: obtaining a minidump from panic() called from NMI handler

[O'Connor, Daniel]

 On 13 Jun 2015, at 09:17, Julian Elischer jul...@freebsd.org wrote:
 
 could it be that more than one CPUs get the NMI at the same time?
 i guess, its possible. is there an easy way to check for that?
 hard code checks in the code so that all except the first do something 
 different.
 (even only as a debug check).. like write to some location and loop...

How about just something to the effect of..
if (curcpu != cpu0)
while (1)
;

--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/

[O'Connor, Daniel]

On 30 Oct 2014, at 19:44, Steven Hartland kill...@multiplay.co.uk wrote:
 On 30/10/2014 08:24, O'Connor, Daniel wrote:
 On 30 Oct 2014, at 13:23, Steven Hartland kill...@multiplay.co.uk wrote:
 Making things harder to manage vs saving a little bit of space on the
 root partition really doesn't sound like a good idea; especially when
 with the ZFS install, which I would suggest is becoming the norm, the
 root partition doesn't suffer from space issues anyway.
 Note that it’s not “a little bit” of space.
 [freebsd10 8:21] /boot/kernel ll kernel *.ko| awk '{i += $5} END {print $5}'
 49312
 [freebsd10 8:21] /boot/kernel ll *.symbols | awk '{i += $5} END {print $5}’
 212464
 
 i.e. the debug information is more than 4x larger than the code its for (!).
 That's still a trivial about of space in the grand scheme of things.

Yes.

 I agree managing the symbol files does become significantly more difficult 
 in this case but the patch makes quite a substantial difference to the 
 number of kernels you can keep in / (especially on older installs which have 
 1GB roots).
 The better solution is to not use a 1GB root.

Unfortunately once you install it’s impossible to expand. There are quite a few 
older systems that have been upgraded with relatively small root partitions.

 Perhaps there could be a flag to disable it just for the kernel that could 
 be put into /etc/make.conf? That way it’s set and forget if you are kernel 
 juggling.
 Making it a none default option which can be used by those who have got 
 limited space on their root.

Perhaps, but the defaults have been for quite small root partitions for a long 
time so I expect there are a lot of systems with a small root.

Regards,
Daniel O’Connor

Senior Software Engineer
Isilon Platforms Team



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

Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/

[O'Connor, Daniel]

On 30 Oct 2014, at 13:23, Steven Hartland kill...@multiplay.co.uk wrote:
 Making things harder to manage vs saving a little bit of space on the 
 root partition really doesn't sound like a good idea; especially when 
 with the ZFS install, which I would suggest is becoming the norm, the 
 root partition doesn't suffer from space issues anyway.

Note that it’s not “a little bit” of space.
[freebsd10 8:21] /boot/kernel ll kernel *.ko| awk '{i += $5} END {print $5}'
49312
[freebsd10 8:21] /boot/kernel ll *.symbols | awk '{i += $5} END {print $5}’
212464

i.e. the debug information is more than 4x larger than the code its for (!).

I agree managing the symbol files does become significantly more difficult in 
this case but the patch makes quite a substantial difference to the number of 
kernels you can keep in / (especially on older installs which have 1GB roots).

Perhaps there could be a flag to disable it just for the kernel that could be 
put into /etc/make.conf? That way it’s set and forget if you are kernel 
juggling.

Regards,
Daniel O’Connor

Senior Software Engineer
Isilon Platforms Team



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

Re: What do you use for kernel debugging?

[O'Connor, Daniel]

On 1 Oct 2014, at 15:54, O'Connor, Daniel Daniel.O'con...@emc.com wrote:
 On 1 Oct 2014, at 14:33, Adrian Chadd adr...@freebsd.org wrote:
 There's also something for XHCI.
 
 So I see..
 
 Section 7.6 in here has details..
 http://www.intel.com.au/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf
 
 Interestingly unlike the EHCI version it does not require hardware between 
 the debugger and debugee, only a special cable. (see 
 http://msdn.microsoft.com/en-us/library/windows/hardware/hh439372(v=vs.85).aspx)

I wrote a quick program to dump xHCI extended capabilities 
https://gist.github.com/DanielO/c42819ae69a1f680039a

Run pciconf -lb and look for the base value for xhciX then run the command with 
that like so..
xhci0@pci0:3:0:0:   class=0x0c0330 card=0x077815ad chip=0x077815ad rev=0x00 
hdr=0x00
bar   [10] = type Memory, range 64, base 0xfd4c, size 131072, enabled

root@foo:~ # ./xhcicap 0xfd4c
HCCPARAMS1 = 0x0388f283
xECP (0xfd4c0e20) = ID 2 (Supported protocol) Specific 0x0300
xECP (0xfd4c0e23) = ID 3 (Extended PM) Specific 0x4253
(this is a VMWare Fusion guest with USB3 enabled)

I ran it on Gigabyte Z77-D3H board (only real hardware I had handy with USB3) 
which has 2 USB3 controllers - one on the Intel chipset, the other an Etron 
EJ168. It shows..

Intel..
HCCPARAMS1 = 0x20007181
xECP (0xf7f08000) = ID 2 (Supported protocol) Specific 0x200
xECP (0xf7f08008) = ID 1 (Legacy support) Specific 0x3001

Etron..
HCCPARAMS1 = 0x040050af
xECP (0xf7c01000) = ID 1 (Legacy support) Specific 0x

Neither support debugging (and according to the spec the later is broken as it 
is supposed to have at least one ‘supported protocol’ entry).

Regards,
Daniel O’Connor

Senior Software Engineer
Isilon Platforms Team



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

Re: What do you use for kernel debugging?

[O'Connor, Daniel]

On 1 Oct 2014, at 14:33, Adrian Chadd adr...@freebsd.org wrote:
 There's also something for XHCI.

So I see..

Section 7.6 in here has details..
http://www.intel.com.au/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf

Interestingly unlike the EHCI version it does not require hardware between the 
debugger and debugee, only a special cable. (see 
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439372(v=vs.85).aspx)

A quick search shows the cable is pretty cheap ($15 for a short one)

 Please please write it for freebsd. :)

Not sure I have the cycles :(

 
 -a
 
 
 On 30 September 2014 21:45, O'Connor, Daniel Daniel.O'con...@emc.com wrote:
 
 On 1 Oct 2014, at 0:14, Julian Elischer jul...@freebsd.org wrote:
 Unfortunately you can't use a USB serial as it requires the USB stack
 be  working before it can be used..
 similar with ethernet connected debugging which requires that the
 driver for the ethernet hardware support it.
 (which why we don't have it in the tree though it has been done
 several times in the past).
 
 There IS a USB debug standard, Linux has some code to support it.
 
 I am not sure what percentage of hardware has it hooked up though (the host 
 controller has a designated debug port but it could physically be anything).
 
 http://www.coreboot.org/EHCI_Debug_Port
 
 The hardware is bit more expensive than a null modem or firewire cable 
 though :(
 
 Regards,
Daniel O’Connor
 
 Senior Software Engineer
 Isilon Platforms Team
 
 
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Regards,
Daniel O’Connor

Senior Software Engineer
Isilon Platforms Team



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

Re: What do you use for kernel debugging?

[O'Connor, Daniel]

On 1 Oct 2014, at 0:14, Julian Elischer jul...@freebsd.org wrote:
 Unfortunately you can't use a USB serial as it requires the USB stack 
 be  working before it can be used..
 similar with ethernet connected debugging which requires that the 
 driver for the ethernet hardware support it.
 (which why we don't have it in the tree though it has been done 
 several times in the past).

There IS a USB debug standard, Linux has some code to support it.

I am not sure what percentage of hardware has it hooked up though (the host 
controller has a designated debug port but it could physically be anything).

http://www.coreboot.org/EHCI_Debug_Port

The hardware is bit more expensive than a null modem or firewire cable though :(

Regards,
Daniel O’Connor

Senior Software Engineer
Isilon Platforms Team



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