Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH
On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best alexbes...@math.uni-muenster.de wrote: hi everyone, together with hugh mahon (the author of ee) i've been trying to fix a nasty bug in ee. for some reason ee exits (not crashes) and leaves the console corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all running ee instances). I noticed this the other day when working on a new 8.0-RC1 system... in my case I was using putty (Windows ssh client) to access the system and maximised the window I had ee running in, and noticed ee just dumped me straight to the prompt. I am wondering if this has anything to do with the new tty subsystem in 8.0, as this wasn't a problem I've experienced before under 7.x... Maybe worth cc'ing ed@ to see if he has any thoughts? --Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Common interface for sensors/health monitoring
On Mon, Aug 24, 2009 at 2:38 AM, Marc Balmerm...@msys.ch wrote: Am 23.08.2009 um 18:24 schrieb Alexander Leidinger: On Sun, 23 Aug 2009 17:13:42 +0200 Marc Balmer m...@msys.ch wrote: Am 23.08.2009 um 17:08 schrieb Alexander Leidinger: On Sat, 22 Aug 2009 21:02:32 +0200 Aurélien Méré aurelien.m...@amc-os.com wrote: I'm just afraid by reading your email that the situation doesn't seem to have evolved since the discussion regarding the SoC, maybe even more taboo, and that I'll have to keep writing my own software and drivers to get the data I want in the future if I want to get this data under FreeBSD.. Is it the case ? It is not taboo, it is just that nobody wants to spend his spare time with something like this now. I hope people spend their time on thinking what was bad with the sensor framework last time and improve on that, instead. Go and read in the archives about it, maybe you understand why there's not much motivation to spend spare time on such a topic. Everyone should have the right to come back with a subject, if work is put into it. Or is the stanza that once there has been a heated discussion about a topic, there is no possibility to come back to it, maybe making it better a seccond time? And no, I have no plans to do so... I am just a bit astonished about the attitude... I for one would be quite happy to contribute towards such an effort. I would much rather contribute towards a project-wide monitoring solution rather than continuing to extend/maintain my own ad-hoc monitoring scripts. I am sure many others are in a similar position... it seems crazy that we are all re-inventing the wheel instead of contributing to a common effort. Is there a summary (perhaps something suitable to go on the Project Ideas page) that outlines: - An outline of what such a system should provide - What it should NOT provide (ie. what would be out of scope) - What lessons should be learned from the SoC effort (ie. both good points and what NOT to do) - Suggested starting points Maybe that would go a long way to ensuring anyone wanting to start such an effort without getting to the end and having their efforts rejected... Yes, bits of this can be found in the past mailing list posts, but it would nice to have an clear official summary of this so that any volunteer effort has the best chance of being accepted... -- Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64
Jeff Wheelhouse wrote: Also, if you have a good test case, it might be worth grabbing a box w/o gmirror that can generate a crashdump and reproduce it there. Not an option for us right now; spare 8-core boxes are hard to come by. We're looking for a USB hard drive or something we can dump to. Can you set your dump device to the underlying GEOM component's swap partition rather than to the gmirror device...? -- Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years
Curtis Penner wrote: Let us take this further. ... When you do a system install it is like jumping back to the 80's. The front-end is like something from the DOS days. You have to be tech savvy to know what you want to do. ... I am looking forward to a time when installing BSD is point and click with not much understanding of what is going on (unless I want to go advance and do special custom work). Ivan Voras has done some great work on addressing this with his finstall project: http://wiki.freebsd.org/finstall http://sourceforge.net/projects/finstall --Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
Jordan Gordeev wrote: Matthew Dillon wrote: We use vkernel's for development and debugging. ... One interesting side-effect of having a vkernel so easily accessible is that it opens up kernel development to normal programmers. More DragonFly developers have been dipping their fingers into the kernel code in the last 6 months then in all the time before then. That alone justifies the time spent doing it. Except for hardware device driver development, the agonizing engineering cycle for kernel development is completely gone now. I have thought of the vkernel primarily as an aid to kernel development (where performance is not a prime concern), not as a virtualisation solution that will compete with Xen and VMWare. It's difficult to compete with thousands of men-hours paid by corporate funding. So far nobody has expressed interest in vkernels as a tool for kernel development. And I got the general impression that I've proposed something stupid and useless. I can see this would be advantageous for lowering the barrier for kernel development. The easier this is made, the better chance we have of people having a go at fixing issues in some of the unmaintained bits and pieces out there. I recall trying to take the leap into kernel development some years back to fix some issues in NWFS and SMBFS; even though I was using VMware for testing, I still found the whole compile/install/reboot test cycle a bit tedious. If it were a matter of just Ctrl-C'ing a kernel and then waiting 5 seconds or a new one to boot up, while still having the rest of the machine available outside to view/edit source at the same time, it would be much simpler... -- Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stale mount on disconnected device: how to delete it?
On 18/12/2007 5:09 AM, Peter Jeremy wrote: On Mon, Dec 17, 2007 at 03:07:02AM -0800, Yuri wrote: I had USB camera connected and recognized as umass0 and mounted as /mnt/camera on /dev/da0s1. Camera was disconnected while it was still mounted. This triggers known and extremely painful to fix bugs in FreeBSD. Your best work-around is to use ports/emulators/mtools rather than mount_msdosfs to to access removable devices. Every time this comes up it's branded with the really hard to fix message, but I seem to recall the last time this came up Matt Dillon chimed in and said he'd managed to fix it in Dragonfly without too much pain. I had a browse back a while ago at the commits on DF to try and pinpoint the changes that were required to see how practical they were to bring across to FreeBSD; I don't profess to be an expert and have yet to investigate the changes in any detail, but these were the commits I identified: http://freshbsd.org/2007/06/14/03/55/27 http://freshbsd.org/2007/06/17/06/08/52 http://freshbsd.org/2007/06/14/02/09/30 http://freshbsd.org/2007/06/13/21/58/38 http://freshbsd.org/2007/06/13/21/53/39 If someone else is interested in looking at this, it may provide a useful starting point... --Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Getting nonstandard serial baud rates w/FTDI
On 25/10/2007 8:59 AM, Bernd Walter wrote:
On Wed, Oct 24, 2007 at 09:53:06AM -0700, Brooks Talley wrote:
Hi, everyone. I'm pulling my hair out in great chunks.
I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to
serial port at 25 baud. The FTDI chip definitely supports this rate. The
port mounts at /dev/cuaU0.
The problem is that
/usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this line:
ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate))
...
Any ideas on how to get this to work? It doesn't seem like it should be this
difficult!
You need to add support in the uftdi driver itself.
There is an enum containing ftdi_8u232am_* fields and a switch/case in
the driver.
The hex value divides the 48MHz clock and leaves a factor 8.
So 0x0018 should be the right value for 25bps.
There is an OpenBSD patch to calculate the rates dynamically:
http://archive.openbsd.nu/?ml=openbsd-techa=2006-06m=2083975
Something similar (but in better style IMHO) is commited to OpenBSD,
which we should merge into our source.
There looks to me to be an issue with an assignment operation (=) rather
than equality test (==) in the following section of the patch:
+ /* Special cases for 2M and 3M. */
+ if ((speed = UI(300 * 0.97)) (speed = UI(200 * 0.97)) \
(speed = UI(200 * 1.03))) { result = 1; goto done; }
I would imagine the (speed = UI(200 * 0.97)) should be == rather
than = for this to make sense...?
--Antony
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slight problem with make actual-package-depends with ports
On 18/07/2007 10:46 AM, Stephen Montgomery-Smith wrote: I appreciate that most people won't have this problem, but it has bitten me. After you have made and installed a port, but don't clean it, and then made a bunch of other ports, if you go back to the original port and then do make package, then +CONTENTS can be a bit messed up for the package. This is because the creation of other ports might disturb _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. This happens to me because I make all my ports on one machine and then copy them as packages to other machines. Then on the other machines, the structure of /var/db/pkg gets a bit messed up and pkg_delete -r malfunctions. It seems to me that the cure is to slightly change make actual-package-depends so that if the port is already installed, it just uses +CONTENTS. I can't comment on the particular approach taken in your patch, but can certainly attest to experiencing the same problem and it being frustrating to identify what was going on. It was only after much hair-pulling that I discovered that doing a 'make clean' at the appropriate time before package building fixed the problem. Otherwise I was winding up with plenty of seemingly OK packages that were missing critical files (in this instance, various PHP5 extension ports that were installing but missing the actual .so files!) --Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slight problem with make actual-package-depends with ports
On 18/07/2007 5:44 PM, Garrett Cooper wrote: Antony Mawer wrote: On 18/07/2007 10:46 AM, Stephen Montgomery-Smith wrote: I appreciate that most people won't have this problem, but it has bitten me. After you have made and installed a port, but don't clean it, and then made a bunch of other ports, if you go back to the original port and then do make package, then +CONTENTS can be a bit messed up for the package. This is because the creation of other ports might disturb _LIB_RUN_DEPENDS and might put in some extra entries in +CONTENTS. This happens to me because I make all my ports on one machine and then copy them as packages to other machines. Then on the other machines, the structure of /var/db/pkg gets a bit messed up and pkg_delete -r malfunctions. It seems to me that the cure is to slightly change make actual-package-depends so that if the port is already installed, it just uses +CONTENTS. I can't comment on the particular approach taken in your patch, but can certainly attest to experiencing the same problem and it being frustrating to identify what was going on. It was only after much hair-pulling that I discovered that doing a 'make clean' at the appropriate time before package building fixed the problem. Otherwise I was winding up with plenty of seemingly OK packages that were missing critical files (in this instance, various PHP5 extension ports that were installing but missing the actual .so files!) --Antony Installing ports registers them on the machine as packages, by simulating a package install via stdin. Was that forgotten? -Garrett The packages were definitely installed, by working through and doing make install on the desired ports... I was aiming to uninstall existing PHP5 packages on deployed servers, and then install from a freshly updated set. The new ports were successfully installed, but for whatever reason some of the packages created were missing the .so files. I removed all the installed packages, make clean'd everything, then started again and the next respin worked fine (without updating the ports tree). Unfortunately I can't recall the exact thing that solved it; I seem to recall a make clean was involved, but don't recall whether it was explicitly running one before or after a make package, or whether it was *avoiding* running one...! --Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_upgrade (was Re: pkg_add does not backtrack, does it?)
On 8/02/2007 9:02 AM, Ulrich Spoerlein wrote: Kip Macy wrote: On Wed, 7 Feb 2007, Joan Picanyol i Puig wrote: I know what I'd like: a utility in the base system for binary upgrading of packages. More flexible logic in how the '-r' option is handled would be nice (being able to fetch all packages from All/ even if you are on RELENG). Doesn't freebsd-update fetch install pkg_upgrade -a look nice for keeping up to date? The obvious hairy details must be harder than it seems, I'm sure others have considered it (and would have done it) before. portupgrade -aPP Requires a fully populated /usr/ports together with an up-to-date INDEX. Not exactly what we are looking for here. I hacked together an ugly shell script, that will use pkg_version (it can grab the INDEX from the pkg-site via ftp) and gives you the feature to pkg_delete/pkg_add selected packages. Yes - we found the same thing a few months ago when we were faced with upgrading a large number of packages on many systems in an automated manner. We wanted to build the packages ourselves (no problems there), then use portupgrade or something similar to handle fixing the dependency links in the package information. We ended up having to push out a minimal /usr/ports/ tree of _just_ the packages we were updating and dependencies (enough to keep portupgrade happy and allow it to work), along with the package files and an INDEX file, and let portupgrade take it from there. It was definitely a painful and kludgy process, and something that would be great to come up with an easier way of doing! Having to push out portupgrade (and ruby as a result) was a fairly bulky requirement just to upgrade some packages... --Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI express support?
On 21/08/2006 3:09 AM, David Gilbert wrote: I got a PCI express version of the Intel gigabit adaptor to try. Heh. Comes with a big-ass heatsink on the card. I found that a bit amusing. But it doesn't probe up. Is this because PCI Express is not supported (1x in this case --- the little slot), or because I need to put in the constants for this card? You might want to try the latest Intel driver from their site, or alternatively I think the latest driver has been merged to 6.1-STABLE. I had a Intel Pro/1000 PT, and it was only recognised in -CURRENT. Using the official Intel driver allowed me to get it running on 6.1. This was prior to the recent MFC of the newer driver. -Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
libutil properties_read() bug: patch for review
Hi, I recently hit upon a bug in sysinstall, getting an Invalid realloc size of 0 error that caused sysinstall to terminate. I eventually tracked it down to a bug in the properties_read() function of libutil, which occurs only when reading a properties file of 4096 bytes or greater. This is because libutil discards its current state when the buffer runs out (4096 bytes) and it must refill the buffer, causing the properties file (*.inf) to be incorrectly read. I've made a patch that's attached to the PR I filed, PR 89181, but was hoping to get some extra eyes on the patch to make sure that there's nothing amiss with the patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=89181 Hopefully someone can review this and see about getting it committed for 6.1! -Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Bonsai-style interface (cvs change history) for FreeBSD CVS?
Hi, I thought this might be the most appropriate place to raise this - I was wondering whether or not there was any chance of a Bonsai (http://www.mozilla.org/projects/bonsai/) interface to the FreeBSD CVS repository. I was going to have a look at doing this locally and trying to hook it into CVSup (normally it ties into the CVS server to track commits as they are made), but if it were available as a public resource then I would imagine this would be to benefit of others as well. Is there any possibility and/or interest in the FreeBSD project setting up an interface? Is there something similar already out there? I know the commit mailing lists, but have in the past found Bonsai a more capable tool for monitoring/locating commits and determining how large and how wide-reaching the changes were. If this is the wrong list, then please redirect this message as appropriate. Please CC me in any responses as I am not subscribed to this list. Regards Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
