# Fssh_packet_write_wait: Connection to 77.183.250.3 port 22: Broken pipe
On recent 12-STABLE, 12.1-RELENG and 12.2-RELENG I face a very nasty problem which occured a while ago after it seemed to have vanished for a while: running ssh in a xterm on FreeBSD boxes as mentioned at the beginning ends up very rapidly in a lost connection with # Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe The backend is in most cases a CURRENT, 12.1-RELENG or 12.2-RELENG or 12-STABLE server. A couple of months ago we moved from 11.3-RELENG to 12.1-RELENG (server side, clients were always 13-CURRENT or 12-STABLE). With FreeBSD 11 as the backend, those broken pipes occured, but not that frequent and rapid as it is the fact now. The "problem" can be mitigated somehow: running top or using the console prevents the broken pipe fault for a while, but it still occurs. Running "screen" (port sysutils/screen) does extend the usability of the console for a significant timespan, but the broken pipe also occurs randomly, but it takes a significant time to occur. All systems mentioned above are highly customized, so I used the chance of another, more "generic" scenario to test. The backend is a most recent Xigmanas machine (running Hardened FreeBSD 12, latest official issue, its based on FBSD 12.1). Accessing clients are recent GhostBSD or FreeBSD 12.2-RELENG, utilizing Remmina (port sysutils/remmina). It doesn't matter whether I take the ports from our local poudriere driven repository or from one of the official ones. SSH via Remmina dies the same death as it does on all customized boxes. And those failing scenarios are occur in all kind of networks, home-ISP-lab/work, lab's network, home's network with foreign, Linux based CPE or other vendor's CPE. My conclusion is: either there is a serious problem with FreeBSD since 12, or there is a config issue I'm not aware of, even with "vanilla" installations from official repository running unchanged. Kind regards, oh pgpNL8yYhtBwN.pgp Description: OpenPGP digital signature
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
>> SHA-256 arrives, if you look at the git history. > git's SHA-256 [...] requiring a super new git version to even test it out. It's "in" current release 2.30.0 and before, duly caveated as experimental and not fully featured yet... git-init(1) --object-format= Specify the given object format (hash algorithm) for the repository. The valid values are sha1 and (if enabled) sha256. sha1 is the default. > continue to test how well it works and monitor the > ecosystem for a transition in a few years when it is robust.. Sure, though perhaps freebsd may then find to enjoy a more middle lead, ahead than the rather later move of svn->git, and being already git it will be far less work. There should be some freebsd press release when the current git deploy is all done, as new people from outside will like to know last big OS is on git and then use it more too. > signatures of the magnet links Signing torrent.asc, with stronger or even same hash as BT protocol, still serve purpose of authenticate torrent file back to a signer to the degree therein, caveat their platform security, caveat sha-1 inside torrent still being abuseable by third party, caveat etc. With no torrent.asc there is nothing directly saying the torrent file / infohash itself went through freebsd project. Whether torrent or git or else, there can be useable scope and case for such "stronger over weaker" constructions. gpg offers better hash algos than sha-1 these days, all users should look into configuring and using it, same goes for abandoning the old [a]symmetric algos and weaker keys, made with old weak /dev/random, etc. One cannot sign or verify anything without knowing gpg first :) And even port called "age" is of simple utility too. ___ 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: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 2020-12-29 20:59, Chris wrote: On 2020-12-29 16:46, John-Mark Gurney wrote: Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100: |SolarWinds supply chain attack, being able to smuggle a modified file |into a git repo, say an OS's build server, such that the tools don't |know the tree is modified is a real problem... SHA-256 arrives, if you look at the git history. Until then signing a git tag even with SHA-1 is better than being unsealed. Actually, no it is not. It provides a false sense a security. SHA-1 should only be used as a checksum (detecting non-malicous corruption) now. There's a reason I stopped signing (and even removed the historical signatures) of the magnet links that I produce for FreeBSD. This is also why I expanded the snapaid tool to support releases, to make it extermely easy to verify signatures: https://www.funkthat.com/gitea/jmg/snapaid This attack, well, interesting that FreeBSD with so many developers with ssh push hasn't been soiled more often. I am And that is why it isn't a major problem yet, in that there are additional layers of security, both ssh and https that help ensure integrity of the repo in transit... cautious regarding such, there is a tremendous amount of propaganda against Russia and China going on .. and then who tapped the cables, who has the budget, hmm. I have read one US national security alert report once, and all i could see was I am well aware of this, and infact, the reason I've been pushing for better security like this IS because of the actions of the NSA... I used to get lunch on a weekly basis across the street from one of the early revealed NSA wiretap rooms. OK I've been pondering this since last night. If this is a reasonable concern, and given all that's already gone into coercing git into something FreeBSD friendly. Is it reasonable to consider putting all that effort that's already been excreted, and what would need to be done. To cobble up a FreeBSD version? [tongue-in-cheek] fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed face-palm; that was: fuc-git. A failed attempt at wit. :-( the rest holds true. that acronym. Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum. Better; hmac-sha384, or any of a number of other digests. I'm just thinking that if everyone pitched in, what with all the other work that's already been done. It'd all get done on a timeline that wouldn't leave the FreeBSD repo unsafe. Mind you; much of this is all conceptual. But I just thought (hoped) it might be worth while. --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 2020-12-29 16:46, John-Mark Gurney wrote: Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100: |SolarWinds supply chain attack, being able to smuggle a modified file |into a git repo, say an OS's build server, such that the tools don't |know the tree is modified is a real problem... SHA-256 arrives, if you look at the git history. Until then signing a git tag even with SHA-1 is better than being unsealed. Actually, no it is not. It provides a false sense a security. SHA-1 should only be used as a checksum (detecting non-malicous corruption) now. There's a reason I stopped signing (and even removed the historical signatures) of the magnet links that I produce for FreeBSD. This is also why I expanded the snapaid tool to support releases, to make it extermely easy to verify signatures: https://www.funkthat.com/gitea/jmg/snapaid This attack, well, interesting that FreeBSD with so many developers with ssh push hasn't been soiled more often. I am And that is why it isn't a major problem yet, in that there are additional layers of security, both ssh and https that help ensure integrity of the repo in transit... cautious regarding such, there is a tremendous amount of propaganda against Russia and China going on .. and then who tapped the cables, who has the budget, hmm. I have read one US national security alert report once, and all i could see was I am well aware of this, and infact, the reason I've been pushing for better security like this IS because of the actions of the NSA... I used to get lunch on a weekly basis across the street from one of the early revealed NSA wiretap rooms. OK I've been pondering this since last night. If this is a reasonable concern, and given all that's already gone into coercing git into something FreeBSD friendly. Is it reasonable to consider putting all that effort that's already been excreted, and what would need to be done. To cobble up a FreeBSD version? [tongue-in-cheek] fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed that acronym. Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum. Better; hmac-sha384, or any of a number of other digests. I'm just thinking that if everyone pitched in, what with all the other work that's already been done. It'd all get done on a timeline that wouldn't leave the FreeBSD repo unsafe. Mind you; much of this is all conceptual. But I just thought (hoped) it might be worth while. --Chris ___ 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"
if you are exporting UFS file systems via NFS on a post Nov. 15 system, there is a problem
If you are exporting UFS file systems via NFS and your kernel is built from head/current sources newer than Nov. 15 (r367672 or newer), the NFS service will be broken. The only workaround is to turn both SU and SU+j off for the exported file systems via tunefs. rick ___ 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"
Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
Hi freebsd-hackers@, CC'd freebsd-current@,
I hope you all had a wonderful holiday season.
I recently got a HP Spectre x360 13t-aw200 which is an Intel
TigerLake-based laptop. It has the Intel "Evo" branding and an "Optane"
SSD which I disabled (so I can get a "second" SSD).
On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ
I don't know if it is HP or Intel, but the VMD IDs device id is
8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also have
this device ID [1].
Sadly, NVMe RAID is forced on this laptop.
I wrote a rough patch to add the device IDs, and the patch is below:
--- a/sys/dev/vmd/vmd.c
+++ b/sys/dev/vmd/vmd.c
@@ -66,13 +66,20 @@ struct vmd_type {
#define INTEL_VENDOR_ID0x8086
#define INTEL_DEVICE_ID_VMD0x201d
#define INTEL_DEVICE_ID_VMD2 0x28c0
+#define INTEL_DEVICE_ID_VMD3 0x9a0b
static struct vmd_type vmd_devs[] = {
{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume
Management Device" },
{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume
Management Device" },
+{ INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume
Management Device" },
{ 0, 0, NULL }
However, I get a panic whenever I use this patch:
https://imgur.com/a/XUQksOi
Without this patch, I am able to boot fine but can't see the SSD or any
nvd* devices beyond a "none" device in `pciconf -lv`.
For those who know about PCI/ACPI subsystems, can you please tell me
what's going wrong?
I'm still debugging in the meanwhile, but am no expert on PCI/ACPI
subsystems. I may know more than most PC builders or CS grads, but not
really enough to do it full-time.
The Spectre's SSD works fine with Windows 10 (obviously) and Linux
(Fedora and Debian tested).
Best,
Neel Chauhan
Sources:
[1]: Linux probes:
* Vostro: https://certification.ubuntu.com/hardware/202007-28047
* XPS: https://linux-hardware.org/?probe=ba53f6e513
___
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"
r367672 broke the NFS server
Hi, Post r367671... When multiple files are being created by an NFS client in the same directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP. This results in a EIO return to the NFS client. --> This causes "nfsv4 client/server protocol prob err=10026" on the client for NFSv4.0 mounts. --> This explains why this error has been reported by several people lately, although it should "never happen". Unfortunately, for the NFS server, the Lookup call is done separately and it will not be easy to redo it, given the current NFS code structure. Is there another way to deal with the problem r367672 was fixing that avoids ufs_create() returning ERELOOKUP? rick ___ 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: HEADS UP: FreeBSD src repo transitioning to git this weekend
Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100: > |SolarWinds supply chain attack, being able to smuggle a modified file > |into a git repo, say an OS's build server, such that the tools don't > |know the tree is modified is a real problem... > > SHA-256 arrives, if you look at the git history. Until then > signing a git tag even with SHA-1 is better than being unsealed. Actually, no it is not. It provides a false sense a security. SHA-1 should only be used as a checksum (detecting non-malicous corruption) now. There's a reason I stopped signing (and even removed the historical signatures) of the magnet links that I produce for FreeBSD. This is also why I expanded the snapaid tool to support releases, to make it extermely easy to verify signatures: https://www.funkthat.com/gitea/jmg/snapaid > This attack, well, interesting that FreeBSD with so many > developers with ssh push hasn't been soiled more often. I am And that is why it isn't a major problem yet, in that there are additional layers of security, both ssh and https that help ensure integrity of the repo in transit... > cautious regarding such, there is a tremendous amount of > propaganda against Russia and China going on .. and then who > tapped the cables, who has the budget, hmm. I have read one US > national security alert report once, and all i could see was I am well aware of this, and infact, the reason I've been pushing for better security like this IS because of the actions of the NSA... I used to get lunch on a weekly basis across the street from one of the early revealed NSA wiretap rooms. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: HEADS UP: FreeBSD src repo transitioning to git this weekend
John-Mark Gurney wrote in <20201229011939.gu31...@funkthat.com>: |Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100: |>|Then there's also the point that the repo is (looks like it) using |>|SHA-1 hashes, which are effectively broken, so depending upon them |>|to validate the tree is questionable anyways. |> |> git uses the hardened SHA-1 for sure, which is, as far as i know, |> at least safe against the known attack. |> I .. have not tracked this, but i think upgrading to SHA-256 is |> possible, once this will become standard. Just even more |> metadata, then. I have not looked into this, still in progress. | |A new attack came out earlier this year: |https://eprint.iacr.org/2020/014.pdf Impressive document. Not a mathematician here, but still. |>From the paper: |> In particular, chosen-prefix collisions can break signature schemes and |> handshake security in secure channel protocols (TLS, SSH), if generated |> extremely quickly. | |The previous attack in 2017 did not break SHA-1 enough to render it's |use by git vulnerable, but the writing was on the wall for SHA-1... | |I believe this new attack makes git's use a SHA-1 vulnerable... |The type/length prefix that prevented the previous attacks from |working is not effective against the new attack... | |Also, the cost of the attack is not great ($45k), considering the recent Ha. |SolarWinds supply chain attack, being able to smuggle a modified file |into a git repo, say an OS's build server, such that the tools don't |know the tree is modified is a real problem... SHA-256 arrives, if you look at the git history. Until then signing a git tag even with SHA-1 is better than being unsealed. This attack, well, interesting that FreeBSD with so many developers with ssh push hasn't been soiled more often. I am cautious regarding such, there is a tremendous amount of propaganda against Russia and China going on .. and then who tapped the cables, who has the budget, hmm. I have read one US national security alert report once, and all i could see was a supposed russian who logged into an open management console, and immediately logged out again (if the session was printed correctly). On some software where this login possibility was publicly announced as being a problem months before. (I read around once i read this report.) So given that the software would at least log such login attempts it could even have been seen as a kind reminder, whatever. Maybe not. Was it "national security alert"?, i think yes. Well. It is always easy to point with fingers at someone else. But as always, situation is horror. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ 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: git and the loss of revision numbers
On 12/29/20 7:11 AM, monochrome wrote: > ok, this appears to be what I was looking for > > example: > git reset --hard f20c0e331 > then: > git pull --ff-only > is again able to update as normal > > I should point out also that this is from the point of view of any > random person just building freebsd from source, not a developer, so > there are no local changes. Though it does blow away changes to the conf > file, that's a lesser issue to deal with. One other thing to consider is that if you are trying to track down a regression, you can use 'git bisect' to do this and it will do the binary search for you. In the case of searching for a regression, you will be better served by that tool than trying to use 'git reset --hard' directly. The other approach you can use to avoid having to look up hashes would be to create your own local tags each time you update. Then you can easily go back to that tag by name instead of having to look up the hash. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816
On Mon, Dec 28, 2020 at 12:44:18PM -0800, John Baldwin wrote:
> On 12/28/20 12:24 PM, John Baldwin wrote:
> > I got this panic again today in a VM when quitting a gdb
> > session after killing a child process via 'kill'.
> >
> > panic: Assertion pgrp->pg_jobc > 0 failed at
> > /git/bhyve/sys/kern/kern_proc.c:816
> > cpuid = 1
> > time = 1609185862
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe00946547f0
> > vpanic() at vpanic+0x181/frame 0xfe0094654840
> > panic() at panic+0x43/frame 0xfe00946548a0
> > _refcount_update_saturated() at _refcount_update_saturated/frame
> > 0xfe00946548e0
> > killjobc() at killjobc+0x6a6/frame 0xfe0094654940
> > exit1() at exit1+0x6af/frame 0xfe00946549b0
> > sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe00946549c0
> > amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0094654af0
> > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0094654af0
> > --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8024c8f0a, rsp =
> > 0x7fffe358, rbp = 0x7fffe370 ---
> > KDB: enter: panic
> > [ thread pid 44034 tid 102484 ]
> > Stopped at kdb_enter+0x37: movq$0,0x10ab066(%rip)
> >
> > From what I can tell, the child process that was killed via 'kill' has
> > not yet exited and is stuck in ptracestop() from fork():
> >
> > (kgdb) where
> > #0 sched_switch (td=0xfe0094001a00, flags=) at
> > /git/bhyve/sys/kern/sched_ule.c:2147
> > #1 0x80bf4015 in mi_switch (flags=266) at
> > /git/bhyve/sys/kern/kern_synch.c:542
> > #2 0x80bfeba5 in thread_suspend_switch (td=,
> > p=)
> > at /git/bhyve/sys/kern/kern_thread.c:1477
> > #3 0x80bef04b in ptracestop (td=0xfe0094001a00, sig=17, si=0x0)
> > at /git/bhyve/sys/kern/kern_sig.c:2642
> > #4 0x80ba1a54 in fork_return (td=0xfe0094001a00,
> > frame=0xfe0094671b00)
> > at /git/bhyve/sys/kern/kern_fork.c:1106
> > #5 0x80ba18b0 in fork_exit (callout=0x80ba1950
> > , arg=0xfe0094001a00,
> > frame=0xfe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069
> > #6
> > #7 0x0008007b71aa in ?? ()
> >
> > kgdb can't find the panicking process due to the zombproc removal, so I will
> > have to go work on kgdb to recover from that change. :(
>
> I've come up with a shorter reproducer (original was trying to debug a perl
> script
> in OpenSSL's test suite).
>
> Compile this program:
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> int
> main(void)
> {
> pid_t pid, wpid;
>
> pid = fork();
> if (pid == -1)
> err(1, "fork");
> if (pid == 0) {
> printf("I'm in the child\n");
> exit(1);
> }
> printf("I'm in the parent\n");
> wpid = waitpid(pid, NULL, 0);
> if (wpid < 0)
> err(1, "waitpid");
>
> return (0);
> }
>
> Then in gdb do the following:
>
> # gdb101 ./forktest
> ...
> (gdb) catch fork
> Catchpoint 1 (fork)
> (gdb) r
> Starting program: /mnt/forktest/forktest
>
> Catchpoint 1 (forked process 830), _fork () at _fork.S:4
> 4 _fork.S: No such file or directory.
> (gdb) kill
> Kill the program being debugged? (y or n) y
> [Inferior 1 (process 828) killed]
> (gdb) quit
>
>
https://reviews.freebsd.org/D27816
___
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: git and the loss of revision numbers
On 29/12/20 18:38, Andriy Gapon wrote: On 2020-12-29 17:11, monochrome wrote: ok, this appears to be what I was looking for example: git reset --hard f20c0e331 then: git pull --ff-only is again able to update as normal I should point out also that this is from the point of view of any random person just building freebsd from source, not a developer, so there are no local changes. Though it does blow away changes to the conf file, that's a lesser issue to deal with. git stash [save] and git stash pop can be used to try[*] to preserve minor local changes. [*] there can be merge conflicts after stash pop if the same file(s) are changed upstream as well. Anyone who already uses git knows this, probably, but for the sake of people who have no experience with it "git stash pop" behaviour can be startling(at least, it was for me when I first used it): after a "git stash pop" which causes conflicts git will set up to actaully create a commit in the branch with the resolved conflict, which (usually for me) is not what one really wants. I usually just do "git reset; git stash drop" in this case and then fix conflicts, to leave me with no extra commits, the changes in my checkout as I want them and no stashed ones (gt does not remove the stash until you commit the resolved changes, which, as I said is not what I want to do usually) I hope I clearly explained this, and if this was obvious to everyone, sorry for the noise! -- Guido Falsi ___ 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: git and the loss of revision numbers
On 2020-12-29 17:11, monochrome wrote: > ok, this appears to be what I was looking for > > example: > git reset --hard f20c0e331 > then: > git pull --ff-only > is again able to update as normal > > I should point out also that this is from the point of view of any > random person just building freebsd from source, not a developer, so > there are no local changes. Though it does blow away changes to the conf > file, that's a lesser issue to deal with. git stash [save] and git stash pop can be used to try[*] to preserve minor local changes. [*] there can be merge conflicts after stash pop if the same file(s) are changed upstream as well. -- Andriy ___ 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: git and the loss of revision numbers
monochrome: > the g is also in the uname output: > > main-c421-gf20c0e331-dirty It's the brand new format: -c-g[-dirty] https://cgit.freebsd.org/src/commit/sys/conf/newvers.sh?id=8d405efd73d3991fe1647f91a2b7c9989dd5f18f -- Christian "naddy" Weisgerber na...@mips.inka.de ___ 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: git and the loss of revision numbers
ok, this appears to be what I was looking for example: git reset --hard f20c0e331 then: git pull --ff-only is again able to update as normal I should point out also that this is from the point of view of any random person just building freebsd from source, not a developer, so there are no local changes. Though it does blow away changes to the conf file, that's a lesser issue to deal with. thanks! On 12/29/20 9:37 AM, Andriy Gapon wrote: On 2020-12-29 02:56, Pete Wright wrote: On 12/28/20 4:38 PM, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. I think that git checkout is a wrong tool here. I personally would use git reset --hard . Note that that command would also revert any local uncommitted changes as well! My view of the difference between the commands: - checkout: stage[*] a change that would modify the current state of the branch to the selected commit's state - reset: change the current branch (its head) to point to the selected commit [*] by stage I mean modify the working copy and the index. That is, if after git checkout you would run git commit then you would commit a change that reverts the current branch to the selected point. ___ 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: git and the loss of revision numbers
On 2020-12-29 02:56, Pete Wright wrote: > > On 12/28/20 4:38 PM, monochrome wrote: >> what would be the git command for reverting source to a previous >> version using these numbers? for example, with svn and old numbers: >> svnlite update -r367627 /usr/src >> > I will generally just checkout the short git hash like so in my local > checkout: > $ git checkout gb81783dc98e6 > > you can quickly get the hashes by running "git log" from your checkout. I think that git checkout is a wrong tool here. I personally would use git reset --hard . Note that that command would also revert any local uncommitted changes as well! My view of the difference between the commands: - checkout: stage[*] a change that would modify the current state of the branch to the selected commit's state - reset: change the current branch (its head) to point to the selected commit [*] by stage I mean modify the working copy and the index. That is, if after git checkout you would run git commit then you would commit a change that reverts the current branch to the selected point. -- Andriy ___ 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: git and the loss of revision numbers
On 12/29/20 7:15 AM, Kristof Provost wrote: On 29 Dec 2020, at 4:33, monochrome wrote: sry forgot details: source tree @ ead01bfe8 git -C /usr/src checkout gf20c0e331 error: pathspec 'gf20c0e331' did not match any file(s) known to git what is the 'g' for? That would have been a typo, I think. the g is also in the uname output: main-c421-gf20c0e331-dirty git -C /usr/src checkout f20c0e331 M sys/amd64/conf/GENERIC HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root bundle yet I don't see any indication that anything changed, and now it wont update at all: If something went wrong there’d be error output. Git is *fast*, which can lead you to assume it’s not done anything when it has in fact done exactly what you asked. You should be on that commit now. that was the full output, and nothing showing that it changed/reverted any files, and the contents of /usr/src/.git/refs/heads/main is still ead01bfe8618e879b3b23c6cf9f026eadcc7d2b3 is there another place to find the current revision of the source? the point here is to revert to a previous known working state of the source tree exactly like svnlite update -rXX /usr/src used to do, and svn could then update from that point again with the same command used to do regular update: svnlite update /usr/src git -C /usr/src pull --ff-only You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull Yes, you can’t merge to a detached head. Return to your original branch (presumably git checkout main) and then pull. Regards, Kristof ___ 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" the point is, there are only 4 commands we need to do this entire thing and it should be ironed out: 1. initially download the source tree 2. get the current local source tree revision 3. update the local source tree 4. revert local source tree to previous state thanks for your input! ___ 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: git and the loss of revision numbers
On 29 Dec 2020, at 4:33, monochrome wrote: sry forgot details: source tree @ ead01bfe8 git -C /usr/src checkout gf20c0e331 error: pathspec 'gf20c0e331' did not match any file(s) known to git what is the 'g' for? That would have been a typo, I think. git -C /usr/src checkout f20c0e331 M sys/amd64/conf/GENERIC HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root bundle yet I don't see any indication that anything changed, and now it wont update at all: If something went wrong there’d be error output. Git is *fast*, which can lead you to assume it’s not done anything when it has in fact done exactly what you asked. You should be on that commit now. git -C /usr/src pull --ff-only You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull Yes, you can’t merge to a detached head. Return to your original branch (presumably git checkout main) and then pull. Regards, Kristof ___ 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: Need some help with audio/sound (to get S/PDIF Toslink to work).
Thank you. I already read this thread while researching. Doesn't help me, because not a single "Digital" output/device appears in my FreeBSD 13.0-CURRENT System: pcm0: on emu10kx0 pcm0: pcm1: on emu10kx0 pcm2: on emu10kx0 pcm3: on emu10kx0 These 4 or 5 are just analog outputs/devices. Maybe the digital (S/PDIF, Toslink) issn't recognized by the system?! But I don't know how to "make" it recognized by FreeBSD. With Devuan (ALSA) and Win10 (Creative Driver) everything is working fine there. I also tried OSS, ALSA and PulseAudio with FreeBSD, but no chance to make it work. Am 29.12.2020 um 11:55 schrieb fischerking1...@yahoo.co.jp: https://forums.freebsd.org/threads/console-player-and-s-pdif-toslink.63371/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Need some help with audio/sound (to get S/PDIF Toslink to work).
https://forums.freebsd.org/threads/console-player-and-s-pdif-toslink.63371/ ___ 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"
Need some help with audio/sound (to get S/PDIF Toslink to work).
Hi there. I'm using FreeBSD (13.0-CURRENT) since 09/2020 at my Raspberry Pi 4B as Home-and-Web-Server-OS with Apache, PHP, SQLite etc... And it works like a charm! Furthermore I'm trying to switch with my main workstation from Win10 to FreeBSD too. Because the more I'm working with FreeBSD, the more I realize that it's the only sane OS out there. Now, I really would like to remove my Win10 Installation, but unfortunately I still have an issue with FreeBSD 13.0-CURRENT for which I can't find solutions, even after reading the whole handbook and searching the www for weeks: I've got an "SoundBlaster Audigy Rx" Soundcard with "Creative E-MU CA10300" Chipset, using the BSDs "EMU10Kx" Kernel Module. The mixer shows all in/outputs right and volume-control of all analog I/Os is working fine with my "Behringer MS40" Speakers and "Alienware TactX" Headset. BUT the digital output (S/PDIF, Toslink) does NOT work. Even if I set dig1/dig2/dig3 and all other outputs to "100:100" within the mixer - still no sound via Toslink. With Devuan (ALSA) or Win10 (native Creative Driver) it is working properly. So it can't be a hardware issue. I also tried OSS, ALSA and PulseAudio with FreeBSD, searched the web for hours, tried this and that, but still no sound via Toslink... (Fortunately) this is the only Hardware-Issue I have. But it is important to me to get S/PDIF Toslink to work! I hope that someone around here can give me some hints, advice, solutions... Regards, blackfoxx My Hardware-Setup: http://www.sysprofile.de/id182580 dmesg.boot: [1] ---<>--- [1] Copyright (c) 1992-2020 The FreeBSD Project. [1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [1] The Regents of the University of California. All rights reserved. [1] FreeBSD is a registered trademark of The FreeBSD Foundation. [1] FreeBSD 13.0-CURRENT #0 : Sat Dec 26 23:08:09 UTC 2020 [1] FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.0-rc2-0-g414f32a9e86) [1] WARNING: WITNESS option enabled, expect reduced performance. [1] VT(efifb): resolution 1280x800 [1] FreeBSD: initialize and check features (__FreeBSD_version 1300133). [1] CPU: Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz (3200.19-MHz K8-class CPU) [1] Origin="GenuineIntel" Id=0x206d7 Family=0x6 Model=0x2d Stepping=7 [1]Features=0xbfebfbff [1]Features2=0x1fbee3bf [1] AMD Features=0x2c100800 [1] AMD Features2=0x1 [1] XSAVE Features=0x1 [1] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID [1] TSC: P-state invariant, performance statistics [1] real memory = 17179869184 (16384 MB) [1] avail memory = 16491573248 (15727 MB) [1] Event timer "LAPIC" quality 600 [1] ACPI APIC Table: [1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs [1] FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads [1] FreeBSD/SMP Online: 1 package(s) x 4 core(s) [1] random: unblocking device. [1] Firmware Warning (ACPI): 32/64X length mismatch in FADT/Pm1aEventBlock: 32/16 (20201113/tbfadt-748) [1] Firmware Warning (ACPI): 32/64X length mismatch in FADT/PmTimerBlock: 32/24 (20201113/tbfadt-748) [1] Firmware Warning (ACPI): Invalid length for FADT/Pm1aEventBlock: 16, using default 32 (20201113/tbfadt-850) [1] Firmware Warning (ACPI): Invalid length for FADT/PmTimerBlock: 24, using default 32 (20201113/tbfadt-850) [1] ioapic1 irqs 24-47 [1] ioapic0 irqs 0-23 [1] Launching APs: 2 1 3 [1] random: entropy device external interface [1] WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. [1] kbd1 at kbdmux0 [1] 000.39 [4346] netmap_init netmap: loaded module [1] [ath_hal] loaded [1] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 440.100 Fri May 29 08:11:49 UTC 2020 [1] nexus0 [1] efirtc0: [1] efirtc0: registered as a time-of-day clock, resolution 1.00s [1] cryptosoft0: [1] aesni0: [1] acpi0: [1] acpi0: Power Button (fixed) [1] cpu0: on acpi0 [1] atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 [1] atrtc0: registered as a time-of-day clock, resolution 1.00s [1] Event timer "RTC" frequency 32768 Hz quality 0 [1] attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 [1] Timecounter "i8254" frequency 1193182 Hz quality 0 [1] Event timer "i8254" frequency 1193182 Hz quality 100 [1] hpet0: iomem 0xfed0-0xfed03fff on acpi0 [1] Timecounter "HPET" frequency 14318180 Hz quality 950 [1] Event timer "HPET" frequency 14318180 Hz quality 550 [1] Event timer "HPET1" frequency 14318180 Hz quality 440 [1] Event timer "HPET2" frequency 14318180 Hz quality 440 [1] Event timer "HPET3" frequency 14318180 Hz quality 440 [1] Event timer "HPET4" frequency 14318180 Hz quality 440 [1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 [1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 [1] acpi_button0: on acpi0 [1] pcib0: port 0xcf8-0xcff on acpi0 [1] pci0: on pcib0 [1] pcib1: at device 1.0 on pci0 [1] pci1: on pcib1 [1] pcib2: at device 1.1 on pci0 [1] pci2: on pcib2 [1] xhci0:
