Re: Race VT+X11 on -current
* Allan Jude allanj...@freebsd.org [150508 16:29]: [..] My experience is a little different. When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) Sometimes when I resume, it seems like the keyboard is frozen. If I alt+f1, then alt+f9, it seems to work fine after that. I'd never though of trying just alt+f9 right away, as I could already see my X session. Not sure if this is related, but it sounds very similar. Similar problem on 10-STABLE: I usually start X by running startx on ttyv0. After exiting X screen shows ttyv0 again but keyboard appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to ttyv1 and back unfreezes keyboard. Wolfgang ___ 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: hastd fail and panic on MAXPHYS=1m
On Fri, May 08, 2015 at 06:02:03AM +0900, Daisuke Aoyama wrote: Hi all, I have problem with MAXPHYS=1m. (I don't know MAXPHYS=1m works on HAST.) I put options MAXPHYS=(1024*1024) in kernel config. Then, update primary node to the kernel and world. If the role back to primary on the machine, writing to the hast device cause an error and panic. I didn't check carefully, but it seems that geom_gate.ko use MAXPHYS=1m and hastd use MAXPHYS=128k. Of course, secondary is MAXPHYS=128k at this time. Is it an expected result? Putting options MAXPHYS... in kernel config does not change the value for userspace (hastd). You might want to try adding to make.conf: CFLAGS += -DMAXPHYS=1048576 and rebuild userspace (or just hastd). Also, running the secondary with smaller MAXPHYS will likely fail too. If you can't reinstall simultaneously I suggest running only the updated primary (don't starting the secondary) until the secondary is updated. -- Mykola Golub ___ 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 to do about RCS/OpenRCS
On 05/08/15 15:59, Davide Italiano wrote: On Fri, May 8, 2015 at 1:34 PM, Pedro Giffuni p...@freebsd.org wrote: Hi; I guess I see the following options: 1) Just leave GNU RCS in the tree. 2) Improve OpenRCS so it can be swapped in. 3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate) and import just a /bin/ident binary (perhaps from OpenRCS). Both 2) and 3) require some work. I suspect 3) requires less. :) I honestly don't see a real problem with (1): we do want to replace as much GNU software as we can but not at the cost of making our life unnecessarily difficult. To be honest I'm not entirely sure what's the real reason of this crusade. FreeBSD can't import newer version of some components of the toolchain (e.g. compiler, linker, debugger) and some of them are slowly (or less slowly) bitrotting. I feel that in that case there's a real goal which justifies all the headache derived from the conversion. Having a consistent license for all the OS has important advantages. The main principle is that while we are fine about sharing and having other people re-use our code we don't really want to have to check with a lawyer before taking any decision. Some years ago, this was basically impossible due to the toolchain, now it seems possible although it certainly requires more work. For GNU RCS, I'm not completely sure there is. I've never heard anybody complaining about lack of features for RCS or bugs. My $0.02, I suspect very few people really rely on it and just complain for the sake of doing it, but I'm not gonna argue on this further. I think there are legitimate reasons for having it in base. That said, unfortunately there's a lot more than doing the conversion and fixing the code so that the testsuite will pass. You need to upstream the fixes and so deal with another layer and other maintainers otherwise the code in base and the one upstream will diverge. We do that with GNU code anyways. The latest (GPLv3) version of RCS has already diverged and is incompatible for some third party software so we basically ran out of support from upstream. OpenRCS has it's own share of problems but generally we can work with the OpenBSD maintainers to get things to improve. I think I found the issue at hand and the code has an /* XXX: This is wrong ... */ Which doesn't really get me nearer to a solution but at least upstream knows where to look. We can wait. People rely from time to time on bugs of old software (e.g. single vs double dash options) and are gonna complain. The testsuite, even if comprehensive, unlikely will cover some corner cases and suddenly software will start breaking. In other words, a lot of (unneeded) work for you for a software that just worked fine(TM) until yesterday. I'm not gonna stop you from doing this, but I learned the hard way that it's something that can/should be avoided unless really necessary (and a better license doesn't seem to be a strong enough reason, IMHO). No one (or at least not me) is going to replace GNU RCS with something of considerable less quality just for the license. Pedro. ___ 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
Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again
Ref. http://docs.FreeBSD.org/cgi/mid.cgi?20150415134515.GQ1224 -- similar symptoms. And again, I captured screenshots on a phone, but FreeBSD doesn't seem to recognize the (USB-attached) phone as something that might act like a file system (I guess; I'm a bit new to smartphones). In this case, my starting-point was r282623; sources were updated to r282676. I was able to update from: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #55 r282623M/282623:1100072: Fri May 8 05:40:49 PDT 2015 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY amd64 to FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #56 r282676M/282676:1100073: Sat May 9 05:50:15 PDT 2015 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY amd64 without incident, but the update from: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1590 r282623M/282623:1100072: Fri May 8 06:40:11 PDT 2015 r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 was only able to build; the panic occurs before we've found any disks, so I can't get a crash dump. I do have a kdb prompt, though, so if someone has a suggestion for something to check, please let me know. (Mind, reading email will be rather awkward while the laptop is exploring the mysteries of a panic, so that might be worth bearing in mind.) Just prior to the bactrace, I see: ... hdaa1: 30 41f0 15 0 Speaker None 1/8 Rear Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex hdac1 (HDA driver mutex) r = 0 (0xcfef... src/sys/dev/sound/pci/hda/hdaa.c:1571 The most recent relevant entries in the backtrace are: hdaa_configure() hdaa_attach() device_attach() bus_generic_attach() hdacc_attach() device_attach() bus_generic_attach() hdac_attach2() run_interrupt_driven_config_hooks() boot_interrupt_driven_config_hooks() mi_startup() begin() The panic message is fatal trap 12: page fault while in kernel mode ... fault code = supervisor read, page not present ... current process = 0 (swapper) ... Stopped at ... = hdaa_configure+0x14af: movb0x3,%dl The only commit I see in the range from r282623 - r282676 that looks as if it might be implicated to me is r282650, but I don't see anything glaringly obvious. Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp2aMZQtcAY7.pgp Description: PGP signature
Re: What to do about RCS/OpenRCS
On May 9, 2015, at 8:05 AM, Pedro Giffuni p...@freebsd.org wrote: We do that with GNU code anyways. The latest (GPLv3) version of RCS has already diverged and is incompatible for some third party software so we basically ran out of support from upstream. OpenRCS has it's own share of problems but generally we can work with the OpenBSD maintainers to get things to improve. But really, how often does the RCS code change? This is a piece of software you get running once, and then leave alone. The last thing we want is for it to start growing features :-P There seems to be an ever-increasing paranoia about adopting code in the base. Are we going to end up at the point where /usr/src/ is nothing but a bunch of Makefiles with VPATH pointed at /usr/src/contrib? I get it for large outside components that are moving targets (e.g. llvm). But RCS? I think the paranoia might be a bit overdone in this case. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: What to do about RCS/OpenRCS
Maybe off-topic, but functionality-wise it might make much more sense to import Fossil. RCS has too many limitations this day and age when better tools are available. Of course, this would require people to learn something new, which I know can be a challenge. Jos ___ 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
