i915kms breakage
Hello, ever since I've merged yesterday, it would seem that the i915kms driver panics every time it is loaded. Unfortunately, I am not able to provide a dump of the panic, as I am unable to see what the panic is, or what is even going on as a matter of fact due to my screen being overtaken by a driver that has just panicked. call doadump() does not seem to work either. Is anyone else having these problems, or know where the issue might be occurring? -- Best regards, Domagoj Stolfa signature.asc Description: PGP signature
Re: Problem with pkg
Having the same issues, even after numerous attempts to manually fix it. -- Best regards, Domagoj Stolfa On Mon, Feb 27, 2017 at 11:34:34PM +0900, Tomoya Tabuchi wrote: > On Mon, Feb 27, 2017 at 01:02:23PM +, Filippo Moretti wrote: > > After a blackout caused by my wife I only get a few pkg shown with the > > command pkg info while they should be hundreds.I also get this error > > message when trying to install packages by pkg installpkg: Repository > > FreeBSD load error: access repo file(/var/db/pkg/repo-FreeBSD.sqlite) > > failed: No such file or directory(I do have a file name local.sqlite)Is > > there a way to recover the pkg database or should I reinstall the OS.Filippo > > > > > > ___ > > 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" > > Hello, > > I have a similar problem. > pkg(8) tells me to do a `pkg update', and when I do that I get the following. > > Updating FreeBSD repository catalogue... > pkg: Repository FreeBSD load error: access repo > file(/var/db/pkg/repo-FreeBSD.sqlite) failed: No such file or directory > meta.txz : 100% 944 B 0.9kB/s > 00:01 > packagesite.txz : 100%6 MiB 986.3kB/s > 00:06 > pkg: rsa verify failed: error:04091077:rsa routines:INT_RSA_VERIFY:wrong > signature length > pkg: No trusted certificate has been used to sign the repository > Unable to update repository FreeBSD > Error updating repositories! > > I am on r314247 and the version of pkg(8) is 1.10.0. > > Tomoya > ___ > 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" signature.asc Description: PGP signature
Re: ASLR
Hello, > For better or worse the term ASLR is today in common use to refer to a > number of different approaches. Using what has become a generic term > allows the implementation to change in the future, without changing > the interface (e.g. sysctls, userland tools, etc.). If I'm not mistaken, ASR is the approach that was first taken by the PaX team in an attempt to randomize mmaps. It later evolved into ASLR, however I do agree that one should call this ASLR for compatibility reasons in the future. > I wish there was a concise, technical comparison of the approaches > implemented by different operating systems, but I've unfortunately not > found one. FWIW, ASLR is just a workaround and has it's weaknesses[1], but is a workaround I would like to see implemented in FreeBSD, be it ASLR or ASR, until a proper solution comes along. [1] https://www.blackhat.com/docs/asia-16/materials/asia-16-Marco-Gisbert-Exploiting-Linux-And-PaX-ASLRS-Weaknesses-On-32-And-64-Bit-Systems-wp.pdf -- Best regards, Domagoj Stolfa signature.asc Description: PGP signature
syslogd: select: Bad File descriptor
> latest changes is causing cpu load and ‘last message repeated times, > I guess the eggnog is affecting too early > > cheers, > danny Having the issue as well. -- Best regards, Domagoj Stolfa. signature.asc Description: PGP signature
RFC: DTrace probes for debugging or testing in userland programs
Hello, > To be clear: my proposal is to replace only debug logging (i.e. for > developers), not the other logging in general, as the subject line > says. Although I agree that DTrace is not lightweight, I think > impact of just adding tracing probes is small. > > -- Hiroki I believe this would indeed be beneficial for debugging. My main concern is the way that we would have to attach to probes should we use SDT provider as it works now. If we were to create probes for each of the daemons, which we would then run individually, and if I'm not mistaken, that would spawn 2 times the amount of processes than are currently spawned due to each ``dtrace'' call from the command line spawns a process. Currently, I'm personally leaning towards a different provider, or perhaps a generalization of some operating principles in the SDT provider, so that code duplication can be avoided. Implementing a different provider would allow for a way to automatically log and fire the probes(this can be done quite easily in the provider). Additionally, the user could attach to the probes and perform some different operations in them as well. If we say that the logging level is 0, we could use a linker set and patch up the daemons to nops, so that there is no overhead. If we want to log something, we could simply patch them back in(this could be a sysctl). If the user wants to log something, one could attach to the probe using ``dtrace'', which would cause the provider to then patch up only that probe in the daemons, resulting in no overhead in other daemons. The sole purpose of this is to have a way to toggle logging and avoid spawning many processes of dtrace in order to log. The functionality could also be implemented in the way that Adrian was talking about, we could just say that the log is a debug log, and we only want to trigger it when a certain flag is set. -- Best regards, Domagoj Stolfa. signature.asc Description: PGP signature
RFC: DTrace probes for debugging or testing in userland programs
Hello, > I'd love to see a unified-ish logging API for FreeBSD applications. I > always end up reusing some C code I have here that I based on some > Squid style logging API in ages past. I could always polish it up and > put it up for review. > > I'm not a big fan of requiring dtrace to use it though. On a lot of > the embedded systems dtrace varies from "it's very big" through to "we > don't have enough RAM/flash to do this". DTrace indeed is very heavyweight, this could be an opt-in kind of thing compile time, hidden somewhere in the logging system employed. Personally, I think that keeping the diffs in the actual daemons to the bare minimum(1-2 LoC) should be one of the priorities. Additionally, the logging system should by default be lightweight, with compile time options to change the actual logging method(a simple log, DTrace, ...). > So although I like the sentiment, I don't think using dtrace for > program logging is the right answer. I like what apple did to wrap > the program logging stuff so people didn't just write their own > libraries (hi!) and so there's a unified-ish way to interact with > apple programs. I think we could do with that. This sounds like a pretty clean solution, and the logging method could be hid somewhere deep in there. I would personally like to see an option where I could pick DTrace for logging, as it allows for some interesting scripts to be written, however I tend to agree that this should not be the default. -- Best regards, Domagoj Stolfa. signature.asc Description: PGP signature
RFC: DTrace probes for debugging or testing in userland programs
Hello, > You can try to compile a new syslogd, run it, and then attach > dtrace(1) to the syslogd process by "dtrace -q -CI./ > -s ./syslogd_trace.d -p `pgrep syslogd`" in the same directory. one thing that comes to mind is the lack of a way to actually fire these probes without running plenty of DTrace scripts. The SDT provider dynamically links onto the binary using the linker set, so that probes can be called. This is accomplished using the DTrace command that you've issued, would we need to issue one for each daemon that operates in such a way? > Questions from me are the following: > > 1. Where should foo_probes.d and foo_trace.d be installed? And if > they depend on foo.h, where should foo.h be? > > 2. Is documenting probes into foo.8 reasonable? This would again depend on the way that they're implemented. If USDTs are used, documenting them might be beneficial, as the user might at one point want to turn them off dynamically or write their own script. > foo_probes.d and foo_trace.d are added. The former is the > definition of USDT probes, and the latter is a D script example to > reproduce the original debug log by dprintf() or something like > that. A section to describe what probes are available is added into > foo.8. One can trace the foo daemon using "dtrace -Cs foo_trace.d -p > `pgrep foo`" on runtime, and also can create own script. > > foo.h may be added because foo_probes.d and foo_trace.d often require > information of data structure used in foo.c. > > * Possible incompatible change > > A debug flag to activate additional logging is no longer necessary > after this rewrite, so we can remove it (-d flag in the case of > syslogd). And dump of the internal state can be implemented as a > SIGINFO handler. In the syslogd example, SIGINFO dumps syslogd > configuration and access control list. One thing that could be done as well is instead of using the SDT provider, a new provider could be written, which could in turn be controlled by the additional flags, or pehaps even a sysctl integer that would specify the level of logging that one would want. This provider could also be entirely disabled, causing it to disable all the existing probes and, similarly to SDT, use the linker set to patch a couple of nops back in. The user could also attach to this provider with their own scripts, should they wish to perform some other form of monitoring as well. This might be redundant with the SDT provider though, so perhaps a more generic, backwards-compatible way can be thought of that would allow this sort of behaviour? -- Best regards, Domagoj Stolfa. signature.asc Description: PGP signature
urtwn(4) with Edimax EW-7722UTn V2
Hello, I have been using the Edimax EW-7722UTn V2(RTL8192CU) USB WiFi for a while. It worked perfectly. In the past 2-3 weeks I have mainly been using wired internet and after a couple of upgrades, and I am uncertain which one caused the issue, my throughput has gone down to around 0.16Mbps downstream and maximum throughput upstream. As I am using CDG as the CC algorithm, I have tested others as well and there is no change in behaviour. ___ 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: The OpenBSD pledge
On Mon, Jun 13, 2016 at 9:44 AM, Florian Ermisch < florian.ermi...@alumni.tu-berlin.de> wrote: > > > Am 11. Juni 2016 18:31:25 MESZ, schrieb Alan Somers <asom...@freebsd.org>: > > On Sat, Jun 11, 2016 at 5:32 AM, Domagoj Stolfa > > <domagoj.sto...@gmail.com> wrote: > > > Yes, it would maybe make sense to do so. I am not too familiar with > > > capsicum(4), but glancing over it, it might be possible. If > > anything, it > > > would allow for code reuse from the OpenBSD ports and increased > > portability > > > in the future. Maybe the people who have worked with capsicum(4) or > > have > > > developed it could give some more insight on this. > > > > > > > I don't see how it would be possible. Capsicum is all about file > > descriptors. When you call cap_enter(), you give up the ability to > > access global namespaces. For example, you can no longer open files > > (except using openat(2) for files in a subdirectory of a directory > > which is already opened). OTOH, pledge is all about sycalls. When > > you pledge, you give up the ability to use certain syscalls, > > regardless of what file descriptors they might involve. So for > > example, a program that uses pledge(2) to prohibit networking syscalls > > can't simply replace pledge(2) with cap_enter(2), because it may need > > to open files after pledging. > > > > -Alan > > Thanks for the clarification, Alan. > So pledge(2) would, if implemented in > FreeBSD, complement capsicum. > They would only overlap around file > descriptors, where capsicum could > enforce a processes pledge like to only > ever write to one file which is its logfile. > > Florian > It indeed does seem like they could complement each other. One could pledge the entire program and use capsicum(4) to limit certain file descriptors even further, but not the rest of the program, such as a TCP socket. This does seem like increased simplicity in limiting the whole program using pledge(2) and the additional benefit that capsicum(4) offers in terms of file descriptors. The question remains though, how would they interact with each other? A single pledge(2) call, as Alan said could limit the operation of capsicum(4). Domagoj ___ 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"
Fwd: The OpenBSD pledge
Yes, it would maybe make sense to do so. I am not too familiar with capsicum(4), but glancing over it, it might be possible. If anything, it would allow for code reuse from the OpenBSD ports and increased portability in the future. Maybe the people who have worked with capsicum(4) or have developed it could give some more insight on this. Domagoj ___ 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 OpenBSD pledge
Has there been discussion on the OpenBSD's pledge going into the FreeBSD kernel as an atomic syscall or as a MAC plugin? ___ 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"
