Re: SMP Version of tar
Don't worry. I'm well known to over-optimize for both size and speed. I have an old Pentium 3 800MHz single core that I can use to simulate an embedded device (well, a decently powered one), to verify that I'm not killing the single-core performance (I could add CPU capability detection to help with that). Also, I still need to find time to do all this research and development. -Brandon On 10/2/2012 3:06 AM, Adrian Chadd wrote: .. please keep in mind that embedded platforms (a) don't necessarily benefit from it, and (b) have a very small footprint. Bloating out the compression/archival tools for the sake of possible SMP support will make me very, very sad. Adrian ___ 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
SMP Version of tar
I would be willing to work on a SMP version of tar (initially just gzip or something). I don't have the best experience in compression, and how to multi-thread it, but I think I would be able to learn and help out. Note: I would like to make this for *BSD under the BSD license. I am aware that there are already tools to do this (under GPL), but I would really like to see this existent in the FreeBSD base. Anyone interested? -Brandon ___ 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: Random Hangs and Freezes
Try grabbing the latest nvidia driver off the nvidia site. Its not really a matter of fixing deadlocks with nvidia, its a matter of finding which driver verion deadlocks on stuff you never use. Deadlocks with nvidia are nearly as bad on Windows too (I get about 2 a day) On Sep 1, 2012 7:54 AM, a...@hush.com wrote: I'll try that, I just wasn't sure if 9.1-RC1 had a repo for pkgng. Tho, I'll upgrade now and let you know if it solves anything. On Fri, 31 Aug 2012 22:01:25 +0100 lokada...@gmx.de wrote: On 08/31/12 22:09, a...@hush.com wrote: On Fri, 31 Aug 2012 20:31:13 +0100 lokada...@gmx.de wrote: On 08/31/12 19:04, a...@hush.com wrote: Let me know what information you may need. Which Version of FreeBSD you are running? I'm currently running FreeBSD 9.0, I don't recall having this issue on 8.2 when I used it. Rather it seems to be a new issue I have with ___ 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 Can you upgrade to 9.1-RC1? ___ 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 ___ 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
Pre-make and Post-make scripts
I'm curious as to how the best way of having a script run before and after make would be done. Would this require modification of the FreeBSD make template, or is this functionality already built in? The goal of this is to set up a script that prior to a build sends up a filesystem in ram (tmpfs) for the build to occur in, and afterwards saves the filesystem from ram onto the actual disk for backup/archiving. We all know that our poor disks could use a little break from the strain of build processes. -Brandon ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
As the original poster of this thread, I can also say that Doug is correct. The issue is not rc, it is the actual kernel boot process. Maybe I could see rc becoming an issue in a massive server environment where there are a lot of userland processes to start, but that delay would most likely be in the programs themselves and not rc (I think of rc as more of a dispatcher). When it comes to a desktop/laptop/simple server and all you do with rc is configure a static IP, start dbus/hal/sshd, and maybe launch a few jails... at least 90-98% of the boot process is spent doing the kernel work. -Brandon On 6/18/2012 6:53 PM, Doug Barton wrote: It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost certainly isn't going to help the goal of actually making the boot time faster. But, I'm willing to be proven wrong by someone who actually _implements_ one of these systems and can demonstrate, in a statistically rigorous fashion, how much the boot time is improved. Doug ___ 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 ___ 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: FreeBSD Boot Times
On 6/13/2012 10:19 AM, Nathan Whitehorn wrote: On 06/12/12 18:00, Richard Yao wrote: On 06/11/12 18:51, Garrett Cooper wrote: On Mon, Jun 11, 2012 at 3:21 PM, Brandon Falkbfalk_...@brandonfa.lk wrote: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. The single process nature of rc is a big part of the problem, as is the single AP bootup of FreeBSD right before multiuser mode. There are a number of threads that discuss this (look for parallel rc bootup or something like that in the current, hacker, and rc archives -- the most recent discussion was probably 6~9 months ago). Given past experience, a big part of getting past the parallelized rc mess would be to make services fail/wait gracefully for all their resources to come up before proceeding. It's not easy, but it's possible with enough resources. HTH, -Garrett ___ 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 Gentoo FreeBSD shares OpenRC with Gentoo Linux. OpenRC is a BSD 2-clause licensed System V init system replacement that supports parallel boot. Its boot performance is competitive with systemd and Ubuntu's upstart. If FreeBSD's init system is serializing the boot process, it might be worthwhile to consider importing OpenRC. ___ 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 Please don't change any of the user-facing aspects of the RC system. One of the things that brought me (and many others I know) to FreeBSD, besides working sound, was having an rc.conf that was easy to configure instead of the nightmare that is System V init. -Nathan ___ 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 Sorry guys, I was very busy last night. The issue is not the init system, rather the kernel. Maybe for a server does the init system start to get lengthy, but at least on my desktop environment where I have almost nothing for RC to do, the kernel bootup takes about 95% of the boot process. If I were to really delve into this (as it would require extensive changes in the kernel [I think]), I would probably end up branching FreeBSD either to a new OS, or if I got permission, to just another branch of FreeBSD. -Brandon ___ 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: FreeBSD Boot Times
Ill do some profiling tonight and get back to you then. On Jun 12, 2012 3:27 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Tuesday 12 June 2012 08:23:33 Andriy Gapon wrote: on 12/06/2012 01:21 Brandon Falk said the following: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Do you have a breakdown of the boot time between pre-loader, loader, kernel and rc stages? Note: This isn't really an issue, moreso a curiosity. Ditto. :-) BTW: Booting over USB is slow because many small chuncks of data is read instead of a few big chunks when loading the kernel and modules at the loader time. --HPS ___ 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
FreeBSD Boot Times
Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. -Brandon ___ 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
High-res Timers
Does anyone have a quick list of high-resolution timer functions? Both user-land and kernel-land? It would be greatly appreciated (doing some performance timing for applications). -Brandon ___ 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: Graphical Terminal Environment
I'm still avidly trying to work on this idea, but right now the issue seems to be with AMD and NVIDIA not documenting their protocols. Intel does a good job, but I don't have any Intel chips with graphics laying around. Right now I've targeted what I think is the main issue, and that is the closed-protocol GPU. I'm working on a minimal GPU right now on an FPGA. Not sure if it will actually end up going anywhere, but I would really like to see an open-hardware GPU out on the market. Certainly it would not be an NVIDIA or AMD killer, but it would be a good card for people who just want to watch videos, browse the web, run terminals, etc. The main focus of this GPU would be to maximize resolutions and monitors, and minimize cost. Currently it looks like I could run 4 monitors at 1080p for about $50 (that's not taking into account bulk-order costs). I could try to work with nouveau (as I did before) but I'll just never feel ok with using a system that uses 'blobs' (nouveau terms for the bits that are sent to the card without knowing what they really are). -Brandon On 4/8/2012 3:45 PM, Michael Cardell Widerkrantz wrote: Since Brandon started this in a sort of rambling mood I'm keeping up with the tradition... This is just what's on top of my mind right now. per...@pluto.rain.com, 2012-03-06 17:05 (+0100): I _think_ SunTools/SunView were proprietary, Absolutely. although it's possible that Sun released the source code at some point. Much of the actual window system in SunView was implemented in the kernel, IIRC. That might not be interesting in this case. Another system I used on quite memory-starved Sun 3/50s (as little as 4 meg) and 3/60s and later on SPARCstations, was the Bellcore MGR window system: http://hack.org/mc/mgr/ http://en.wikipedia.org/wiki/ManaGeR Many users in the Lysator academic computing society where I first met MGR preferred it to SunView. It was really nice on monochrome monitors at 1152x900. It's also network transparent so you can run remote graphics applications. MGR was ported to a lot of systems, including FreeBSD. It might still compile, but it's unlikely to support anything higher than 640x480 on FreeBSD. If anyone tries to compile it and runs into problems I might be able to help. Just e-mail me. To support higher resolutions on FreeBSD Brandon would have to rewrite the functions in libbitblit. One way to do it would be to use vgl(3) to implement the libbitblit functions. Should be pretty straightforward, I think, and not too much work. On the other hand vgl(3) probably only supports VESA so Brandon will still have to write a special libbitblit for the nvidia card he mentions. MGR doesn't tile windows but Brandon might want to add a mode to do that. MGR has a slightly bothersome license, though, forbidding commercial sales so this might not be the best way forward. On Sun SPARCs under SunOS it was also possible to run a tiling window system called Oberon. It shares its name with a programming language and a complete native operating system. Oberon is a complete environment using the Oberon programming language so it might not be what Brandon wants but it might be interesting to look at nonetheless. I believe Oberon is still available and can run either as a native operating system or as an environment under other systems. The SPARC port I used many years ago was running under SunOS but was running directly on the console. I don't know if there are any modern Oberon systems that can do that. Incidentally, Oberon was one of the inspirations behind Rob Pike's acme editor on Plan 9. Acme, however, just handles text. Oberon does graphics as well. I've been thinking something along the same lines as Brandon for several years now: to write a lightweight window system. For many years I resisted X and kept using MGR, even going so far as porting MGR to Solaris and to Linux/SPARC just to be able to keep using MGR on more modern systems. I gave up, I think, around 1994. If I would do it again I would probably not work on MGR but I might use it for some ideas. One thing that MGR does that I wouldn't do was to force all graphics operations to be done through escape codes in terminal windows. While it might be great for network transparance it's not so great for the speed of local programs. The Wayland project is interesting but seems very Linux oriented. On the other hand work on KMS/GEM support on FreeBSD is coming along. It might be possible to get Wayland running on FreeBSD. I haven't looked into it myself (yet). James Gosling, who wrote both the Andrew window system and Sun's NeWS (not SunView, the *other* Sun window system, the one with a Postscript interpreter) has written an interesting paper about window system design. I have a copy here: http://hack.org/mc/texts/gosling-wsd.pdf Some people have mentioned Plan 9's 8 1/2 and rio. They are both very interesting window systems. While I think they have a very clean design I think
Re: Reverse engineering; How to...
Reverse engineering a whole driver could take a very long time, even with the proper tools. If it's possible, return the adapter, and buy a new one and verify that the chipset is supported before you buy it. Last time I bought a wireless card I sat in the store looking at the Wireless support list for BSD before buying. http://www.freebsd.org/relnotes/CURRENT/hardware/support.html#WLAN I very strongly suggest that you get a card with an Atheros chipset, as those are by far the best supported on BSD. -Brandon On 3/28/2012 4:22 PM, Chris.H wrote: Greetings, Over the past year, in an effort to convert my server farm to wireless, I've purchased some half a dozen USB wireless dongles, at a total cost of ~150.00. Unfortunately, none of them are (yet) supported — I know, I know, I've already had this debate with both dev's, users. On the up-side, I've devised a resource that will greatly assist would-be adopters in selecting, and researching these, and other adapters _currently supported_ under under FreeBSD. That said; the adapter I most recently purchased, is quite nice (Cisco(Linksys) AE2500 Wireless-N). Boasts 2.5/5GHz @300Mbps. I figured (wrongly) because Linksys is so well supported on FreeBSD, that the likelihood of this being supported would be good. At any rate, given it's not, and because I _do_ have the Window$ drivers on the install CD. What are the possibilities I can reverse-engineer the drivers into a FreeBSD loadable module? I can unpack the setup file to extract the .sys files. While I _could_ utilize the ndisulator to load them, that's not my goal. Should I unpack the .sys file, and attempt to decompile/disassemble it? Or attempt to load it, and dump it from memory? — hacker/cracker advice _strongly_ desired — ## #usbconfig -d ugen1.2 dump_device_desc ugen1.2: Linksys AE2500 Cisco at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ff bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x13b1 idProduct = 0x003a bcdDevice = 0x0001 iManufacturer = 0x0001 Cisco iProduct = 0x0002 Linksys AE2500 iSerialNumber = 0x0003 0001 bNumConfigurations = 0x0001 ## P.S. This message was sent from my smart phone. Apologies for any (mis)formatting. :-( --Chris.H ___ 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
De-warning...ing clang Kernel Builds
Is there anyone actively working on cleaning up the codebase to not throw warnings when built with clang. I realize these warnings do not matter, but I generally prefer to get rid of warnings if possible. I can't imagine it would take too long, although I could see an issue with developers not familiar with the clang warning system forgetting to check clang builds for warnings while they add new code. -Brandon ___ 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: Graphical Terminal Environment
On 3/7/2012 2:06 PM, Peter Jeremy wrote: If you're looking for something minimal, vector support should be one of the first things to go. At small sizes (in terms of dots), the best fonts are all bitmaps, rather than vector descriptions. One of the features of TrueType and Postscript is that a vendor can provide hand-tweaked bitmap glyphs for small sizes of a vector font. Likewise the VT100 demonstrated that you don't need vector line drawing to draw boxes. Some points to keep in mind: Anything beyond what is supported in your VESA BIOS requires custom support for your specific video chip. This is part of the code in x11-drivers/xf86-video-*. LCD monitors look fairly poor unless driven at their native resolution so, unless your VESA BIOS provide a mode that suits your monitor, you will need custom driver code. I do plan on writing a small little driver for NVIDIA cards (it's what I have). I'm assuming it can't be terribly hard to detect the monitor's resolution, set to that resolution, then start displaying dots... you never know though... I'll be having a fun time with nouveau for the next few weeks :) -Brandon ___ 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: Graphical Terminal Environment
On 3/6/2012 11:05 AM, per...@pluto.rain.com wrote: Brandon Falk bfalk_...@brandonfa.lk wrote: I havent tried tmux yet, but on my system im only able to get 80x40 with vidcontrol on one monitor. But with xterm in xorg i can get 319x89 per monitor ... To get higher resolution than what vidcontrol provides, you'll most likely need to run the display in graphic mode (which is what X11 does) rather than in text mode. That means that you will need to either use, or reinvent, the lowest levels of X (display driver, window mapping) and at least part of the xterm/rxvt application (terminal emulation, font rasterizing, perhaps scrolling). You could, however, eliminate the X practice of using the network to connect the terminal emulator to the display; this would give you an architecture resembling SunView (and its predecessor, SunTools). I _think_ SunTools/SunView were proprietary, although it's possible that Sun released the source code at some point. You could try doing some research with Google and/or the Internet Archive. That's pretty much my plan. To write some lower level drivers to put the system in a graphics mode. I have 4 monitors and there is no other way to get multiple monitors without a GPU specific driver (at least from my VGA OSDev experience). My goal will be to make a driver that will be able to be runnable by any other driver easily. Instead of having to use Xorg, just calls to the video driver to set the mode to graphics, then some primitive functions to draw lines and dots. I don't see why Xorg should dominate the drivers completely, I really wish it was a matter of having an open, well documented, easy to use API that you can just give direct commands to. From my understanding, this is the current model: [ Apps ] | v [ Xorg ] | v [ Driver ] | v [ GPU] I think it should be the following: [ Apps ] | v [ Xorg ] [ Apps ] | | v v [Driver ] | v [ GPU ] Does this make sense to anyone else? I really want to get this idea across because I think it would be really beneficial. -Brandon ___ 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: Graphical Terminal Environment
On 3/6/2012 10:49 AM, Ian Lepore wrote: With that model and your statement that the driver should support only primitive functions to draw lines and dots, that leaves the non-trivial problem of font rendering to the app. Given your original goal, font rendering is pretty much the bulk of what you want to do, is the app layer the right place for it? -- Ian I'd plan to have it do more than just lines and dots. Pretty much anything you'd need to set up a basic interface with text, boxes, maybe circles. Just an API similar to OpenGL for 2d graphics minus shading and lighting. Think of anything you'd need for making simple 2d apps, and I'd throw it in. I completely understand the concept of having the app do as little of the graphics processing as possible. I'm not sure why I didn't mention the ability to draw fonts in the previous email. Think of a mix of ncurses simplicity for text-only apps, but with a twist of support for primitive drawing capabilities (line and dots [text drawing is just implied]). -Brandon ___ 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: Graphical Terminal Environment
On 3/6/2012 11:19 AM, Adam Vande More wrote: On Tue, Mar 6, 2012 at 9:55 AM, Brandon Falk bfalk_...@brandonfa.lk mailto:bfalk_...@brandonfa.lk wrote: I'd plan to have it do more than just lines and dots. Pretty much anything you'd need to set up a basic interface with text, boxes, maybe circles. Just an API similar to OpenGL for 2d graphics minus shading and lighting. Think of anything you'd need for making simple 2d apps, and I'd throw it in. Sounds like you are reinventing SDL. -- Adam Vande More SDL is massive to what I plan on doing, and SDL is dependent on X11. I don't plan on making it powerful enough to really do any graphics, although I'd branch the driver, one for minimal use in a high resolution terminal environment, and the other could be for maybe designing a whole new future for even games and such. -Brandon ___ 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: Graphical Terminal Environment
On 3/6/2012 12:30 PM, Tom Evans wrote: On Tue, Mar 6, 2012 at 4:27 PM, Brandon Falk bfalk_...@brandonfa.lk wrote: SDL is massive to what I plan on doing, and SDL is dependent on X11. Incorrect. SDL has no dependency upon X. Linux users can run SDL applications directly on a framebuffer device. Cheers Tom According to wikipedia: On X Window System https://en.wikipedia.org/wiki/X_Window_System platforms, including Linux https://en.wikipedia.org/wiki/Linux and OpenVMS https://en.wikipedia.org/wiki/OpenVMS, SDL uses Xlib https://en.wikipedia.org/wiki/Xlib to communicate with the X11 system for graphics and events. I'd have to look into that if it does work without xlib/X11. Although SDL is under the GPL still and I'd love to write mine under the BSD license. (If you haven't noticed, I'm going to keep finding excuses to write this as I really am kindof excited to learn/work on it) -Brandon ___ 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: Graphical Terminal Environment
On 3/6/2012 1:39 PM, Mike Meyer wrote: On Mon, 5 Mar 2012 23:39:57 -0500 Brandon Falk bfalk_...@brandonfa.lk wrote: I've been thinking for a while about possibly making an extremely lightweight environment that supports full monitor resolution, custom fonts, and terminals... that's about it. Essentially, an x11 that only supports tiling xterms all over the place. I do everything through terminals, and I think it'd be a fun project to make something that's only purpose is to make it so you can use your entire screen to its fullest (larger resolutions, smaller fonts, etc). Just a graphical tty. Since no one has mentioned it, if that's all you want, then all you really need to do is figure out how create one max-sized terminal on each physical screen. The screen command (ports/sysutils/screen) will then let you create multiple shell sessions on each screen, including tiling multiple sessions on the screen. It didn't interact well with emacs, and emacs would do pretty much everything I wanted it to do, so I stopped using it a while back for that kind of thing. I also find the comment that X is quite large amusing, because I wind up comparing it to the competition (the Mac UI being the only other current one that runs on top of Unix), and it looks quite compact. You might try a custom build of X, turning off all the stuff you don't need, and disabling the loading of any extensions you don't need, and see how much you can shrink it by before tackling rewriting it. You may even be able to lose the requirement for a pointer. I'm also curious as to why you want the ability to draw lines, circles, etc. to handle an array of terminals. Screen shows that can be done with nothing but a CGA. It might be education, though. mike You seem to understand exactly want I want. Just small font terminals on all screens, and I was actually thinking `screen` would do the trick for the splitting/management of them. As for stripping down X, I might do so as a proof of concept, but in the end I want to develop my own for my own learning. When I mention lines, circles, etc I was thinking moreso at the very low level of fonts being drawn by lines and dots (although I would like to branch it eventually to support 2d graphics where people could maybe make some 2d games, but keep the high-res terminal on the side to keep it minimal). I also may want to draw some lines to border terminal windows (screen would eliminate this obviously). -Brandon ___ 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: Graphical Terminal Environment
On 3/6/2012 2:52 PM, b. f. wrote: Brandon Falk bfalk_bsd at brandonfa.lk wrote: I've been thinking for a while about possibly making an extremely lightweight environment that supports full monitor resolution, custom fonts, and terminals... that's about it. You may also want to look at our system libvgl ( vgl(3) ), ports/devel/directfb ( http://directfb.org/ ), and ports/graphics/svgalib ( http://www.svgalib.org/ ). Someone has mentioned wayland -- there was also an older X variant called tinyX that is still used by some minimalistic Linux distributions, and was loosely based on the X.org kdrive server. b, Thanks for all the links. I'm going to have to try some of this out. I think I am just going to end up writing a minimal NVIDIA driver that can set the video mode, resolution, and draw some lines for now. I've never actually worked with a video card before, only BIOS VGA functions and framebuffers. -Brandon ___ 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: Graphical Terminal Environment
I want to learn but at the same time I want to create this graphical terminal under the BSD license so I would be able to have an entire system under the BSD license, with a bit better interface than 80x25 or 90x30 for that matter. Xorg has such a large dependency base that I bet somewhere down the line there'd be some gpl'd code, although I may be wrong. On Mar 6, 2012 5:06 PM, Dieter BSD dieter...@engineer.com wrote: Brandon writes: (If you haven't noticed, I'm going to keep finding excuses to write this as I really am kindof excited to learn/work on it) ideas: Display PostScript rio (from Plan 9) If you're mainly looking for a low-level graphics project, maybe reverse engineer something on the GPU (e.g. UVD) ___ 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 ___ 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
Graphical Terminal Environment
I've been thinking for a while about possibly making an extremely lightweight environment that supports full monitor resolution, custom fonts, and terminals... that's about it. Essentially, an x11 that only supports tiling xterms all over the place. I do everything through terminals, and I think it'd be a fun project to make something that's only purpose is to make it so you can use your entire screen to its fullest (larger resolutions, smaller fonts, etc). Just a graphical tty. Not sure how stupid this idea sounds (or if it even is already done). I've seen graphical terminals that use 1024x768 VESA graphics, but I've never seen one that can tile multiple terminals over say, 4 monitors at 1080p. I'm completely oblivious to how X11 actually gets data to the screen (besides drivers that depend on X11 itself... and this is not stripped down X11, it's a 'replacement' for people who don't need a graphical environment, but would appreciate a much more expandable terminal environment), and I'd love to get some advice or maybe even work with a team if someone thinks this idea is good. Seems like it'd be a driver specific thing at the very core of the issue. Do drivers tie in with X11, or do they do what I think they should... draw graphics where commanded to (via some universal OpenGL style API, not OpenGL-Xorg-Driver). Perhaps that's how they are... I'm rambling. Tell me if you need any clarifications, as I'm lacking in sleep and tomorrow when I read this it will probably not make any sense. -Brandon ___ 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: Graphical Terminal Environment
I'm actually talking about perhaps getting rid of X11 totally. It's overkill for what I need. I use dwm right now and I basically want to create a dwm that doesn't have the massive X11 backend. X11 is well written, but it's getting outdated and quite large, especially if you only need terminals and no graphics (and really, I just want to learn, I understand that I'm 'reinventing the wheel'). On Tue, Mar 6, 2012 at 12:30 AM, matt sendtom...@gmail.com wrote: On 03/05/12 20:39, Brandon Falk wrote: I've been thinking for a while about possibly making an extremely lightweight environment that supports full monitor resolution, custom fonts, and terminals... that's about it. Essentially, an x11 that only supports tiling xterms all over the place. I do everything through terminals, and I think it'd be a fun project to make something that's only purpose is to make it so you can use your entire screen to its fullest (larger resolutions, smaller fonts, etc). Just a graphical tty. Not sure how stupid this idea sounds (or if it even is already done). I've seen graphical terminals that use 1024x768 VESA graphics, but I've never seen one that can tile multiple terminals over say, 4 monitors at 1080p. I'm completely oblivious to how X11 actually gets data to the screen (besides drivers that depend on X11 itself... and this is not stripped down X11, it's a 'replacement' for people who don't need a graphical environment, but would appreciate a much more expandable terminal environment), and I'd love to get some advice or maybe even work with a team if someone thinks this idea is good. Seems like it'd be a driver specific thing at the very core of the issue. Do drivers tie in with X11, or do they do what I think they should... draw graphics where commanded to (via some universal OpenGL style API, not OpenGL-Xorg-Driver). Perhaps that's how they are... I'm rambling. Tell me if you need any clarifications, as I'm lacking in sleep and tomorrow when I read this it will probably not make any sense. -Brandon ___ 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 Ratpoison is in ports and I think it does what you're asking...aka a tiling wm aimed at keyboard control. Just use a very minimal xinitrc? Matt ___ 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: Graphical Terminal Environment
I havent tried tmux yet, but on my system im only able to get 80x40 with vidcontrol on one monitor. But with xterm in xorg i can get 319x89 per monitor. Until i get about half of that, i wont be convinced to use something existing. Anyways, I'm off to sleep. Night, Brandon ___ 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: [clang] Build error on r232474 (and a few before, don't know exactly which)
On 3/3/2012 9:29 PM, Brandon Falk wrote: On 3/3/2012 9:13 PM, Joshua Isom wrote: On 3/3/2012 6:30 PM, Dimitry Andric wrote: Huh, that's weird. I see no reason that it wouldn't install cc during the cross-tools stage, unless you have WITHOUT_GCC in your src.conf (and aren't using WITH_CLANG_IS_CC at the same time). Can you post your src.conf file, please? I've had this happen for a while but kept forgetting to post a pr. If you define WITHOUT_GCC, a cc isn't created in /usr/obj/usr/src/tmp/usr/bin but if you go into the directory and do a symbolic link from clang, and restart make with -DNO_CLEAN it'll work and complete. One of the programs hardcodes cc and doesn't check the environment, I forget which. Built the code until it failed. Then did a `ln -s /usr/obj/root/src/tmp/usr/bin/clang /usr/obj/root/src/tmp/usr/bin/cc` and a `make -DNO_CLEAN -j12 buildworld` and it finished just fine. Thanks for the help, although we've got to sort this hardcode out somewhere :P -Brandon Falk FIXED Sometime between 12 hours prior, and r232529 this bug was fixed. Just did a successful build on r232529. -Brandon ___ 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
[clang] Build error on r232474 (and a few before, don't know exactly which)
I'm trying to build r232474 with clang (build environment is 10.0-CURRENT
r231589 amd64 with clang), and I fail on `make -j16 buildworld`. I've tried
with and without threads. I've built so many builds of clang that I can't even
count, so I'm confident my environment is set up properly. I'm building under a
virtual machine, although I've never had issues with that before.
error
=== gnu/usr.bin/texinfo/doc (all)
makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi -o
info.info
makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi
-o info-stnd.info
ln -fs
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi
texinfo.texi
makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi
-o texinfo.info
gzip -cn info.info info.info.gz
gzip -cn info-stnd.info info-stnd.info.gz
gzip -cn texinfo.info texinfo.info.gz
1 error
*** [everything] Error code 2
1 error
*** [buildworld] Error code 2
1 error
END error
Make.conf
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP=clang-cpp
.endif
NO_WERROR=
WERROR=
NO_FSCHG=
# added by use.perl 2012-03-03 16:12:59
PERL_VERSION=5.12.4
END Make.conf
-Brandon
___
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: [clang] Build error on r232474 (and a few before, don't know exactly which)
On 3/3/2012 6:40 PM, Dan Nelson wrote:
In the last episode (Mar 03), Brandon Falk said:
I'm trying to build r232474 with clang (build environment is 10.0-CURRENT
r231589 amd64 with clang), and I fail on `make -j16 buildworld`. I've
tried with and without threads. I've built so many builds of clang that I
can't even count, so I'm confident my environment is set up properly. I'm
building under a virtual machine, although I've never had issues with that
before.
You didn't actually paste an error at all below, but the fact that the
top-level make reported an error from one of the sub-makes. You'll need to
either capture the entire build log and scroll through it from the bottom up
to find the error message, or build without -j16 so the error is at the
bottom of the output.
error
=== gnu/usr.bin/texinfo/doc (all)
makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi -o
info.info
makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi
-o info-stnd.info
ln -fs
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi
texinfo.texi
makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi
-o texinfo.info
gzip -cn info.info info.info.gz
gzip -cn info-stnd.info info-stnd.info.gz
gzip -cn texinfo.info texinfo.info.gz
1 error
*** [everything] Error code 2
1 error
*** [buildworld] Error code 2
1 error
END error
Make.conf
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP=clang-cpp
.endif
NO_WERROR=
WERROR=
NO_FSCHG=
# added by use.perl 2012-03-03 16:12:59
PERL_VERSION=5.12.4
END Make.conf
-Brandon
___
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
Oops, I meant to paste the URL for the entire log. You can find it here:
http://www.brandonfa.lk/freebsd-clang/log.gz
I'll start a build without threads right now.
-Brandon
___
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: [clang] Build error on r232474 (and a few before, don't know exactly which)
On 3/3/2012 6:49 PM, Brandon Falk wrote:
On 3/3/2012 6:40 PM, Dan Nelson wrote:
In the last episode (Mar 03), Brandon Falk said:
I'm trying to build r232474 with clang (build environment is
10.0-CURRENT
r231589 amd64 with clang), and I fail on `make -j16 buildworld`. I've
tried with and without threads. I've built so many builds of clang
that I
can't even count, so I'm confident my environment is set up
properly. I'm
building under a virtual machine, although I've never had issues
with that
before.
You didn't actually paste an error at all below, but the fact that the
top-level make reported an error from one of the sub-makes. You'll
need to
either capture the entire build log and scroll through it from the
bottom up
to find the error message, or build without -j16 so the error is at the
bottom of the output.
error
=== gnu/usr.bin/texinfo/doc (all)
makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi
-o info.info
makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi
-o info-stnd.info
ln -fs
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi
texinfo.texi
makeinfo --no-split -I /root/src/gnu/usr.bin/texinfo/doc -I
/root/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc
texinfo.texi -o texinfo.info
gzip -cn info.info info.info.gz
gzip -cn info-stnd.info info-stnd.info.gz
gzip -cn texinfo.info texinfo.info.gz
1 error
*** [everything] Error code 2
1 error
*** [buildworld] Error code 2
1 error
END error
Make.conf
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP=clang-cpp
.endif
NO_WERROR=
WERROR=
NO_FSCHG=
# added by use.perl 2012-03-03 16:12:59
PERL_VERSION=5.12.4
END Make.conf
-Brandon
Oops, I meant to paste the URL for the entire log. You can find it
here: http://www.brandonfa.lk/freebsd-clang/log.gz
I'll start a build without threads right now.
-Brandon
I was trying to navigate the log in `edit`. Now that I'm in vim I
quickly found the error.
lint: cannot exec /usr/obj/root/src/tmp/usr/bin/cc: No such file or
directory
*** [llib-lposix.ln] Error code 1
This error is repeated in a few places.
-Brandon
___
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: [clang] Build error on r232474 (and a few before, don't know exactly which)
On 3/3/2012 7:30 PM, Dimitry Andric wrote: On 2012-03-04 00:52, Brandon Falk wrote: ... I was trying to navigate the log in `edit`. Now that I'm in vim I quickly found the error. lint: cannot exec /usr/obj/root/src/tmp/usr/bin/cc: No such file or directory *** [llib-lposix.ln] Error code 1 Huh, that's weird. I see no reason that it wouldn't install cc during the cross-tools stage, unless you have WITHOUT_GCC in your src.conf (and aren't using WITH_CLANG_IS_CC at the same time). Can you post your src.conf file, please? I do not have a src.conf. It's a completely fresh install of BSD with the exception of my make.conf (and I double checked just incase). No variable WITH_CLANG_IS_CC is defined. -Brandon ___ 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: [clang] Build error on r232474 (and a few before, don't know exactly which)
On 3/3/2012 9:13 PM, Joshua Isom wrote: On 3/3/2012 6:30 PM, Dimitry Andric wrote: Huh, that's weird. I see no reason that it wouldn't install cc during the cross-tools stage, unless you have WITHOUT_GCC in your src.conf (and aren't using WITH_CLANG_IS_CC at the same time). Can you post your src.conf file, please? I've had this happen for a while but kept forgetting to post a pr. If you define WITHOUT_GCC, a cc isn't created in /usr/obj/usr/src/tmp/usr/bin but if you go into the directory and do a symbolic link from clang, and restart make with -DNO_CLEAN it'll work and complete. One of the programs hardcodes cc and doesn't check the environment, I forget which. ___ 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 Built the code until it failed. Then did a `ln -s /usr/obj/root/src/tmp/usr/bin/clang /usr/obj/root/src/tmp/usr/bin/cc` and a `make -DNO_CLEAN -j12 buildworld` and it finished just fine. Thanks for the help, although we've got to sort this hardcode out somewhere :P -Brandon Falk ___ 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: OS support for fault tolerance
On 2/14/2012 12:05 PM, Jason Hellenthal wrote: On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote: On 2/14/12 6:23 AM, Maninya M wrote: For multicore desktop computers, suppose one of the cores fails, the FreeBSD OS crashes. My question is about how I can make the OS tolerate this hardware fault. The strategy is to checkpoint the state of each core at specific intervals of time in main memory. Once a core fails, its previous state is retrieved from the main memory, and the processes that were running on it are rescheduled on the remaining cores. I read that the OS tolerates faults in large servers. I need to make it do this for a Desktop OS. I assume I would have to change the scheduler program. I am using FreeBSD 9.0 on an Intel core i5 quad core machine. How do I go about doing this? What exactly do I need to save for the state of the core? What else do I need to know? I have absolutely no experience with kernel programming or with FreeBSD. Any pointers to good sources about modifying the source-code of FreeBSD would be greatly appreciated. This question has always intrigued me, because I'm always amazed that people actually try. From my viewpoint, There's really not much you can do if the core that is currently holding the scheduler lock fails. And what do you mean by 'fails? do you run constant diagnostics? how do you tell when it is failed? It'd be hard to detect that 'multiply' has suddenly started giving bad results now and then. if it just stops then you might be able to have a watchdog that notices, but what do you do when it was half way through rearranging a list of items? First, you have to find out that it held the lock for the module and then you have to find out what it had done and clean up the mess. This requires rewriting many many parts of the kernel to remove 'transient inconsistent states. and even then, what do you do if it was half way through manipulating some hardware.. and when you've figured that all out, how do you cope with the mess it made because it was dying? Say for example it had started calculating bad memory offsets before writing out some stuff and written data out over random memory? but I'm interested in any answers people may have How about core redundancy ? effectively this would reduce the amount of available cores in half in you spread a process to run on two cores at the same time but with an option to adjust this per process etc... I don't see it as unfeasable. The overhead for all of the error checking and redundancy makes this idea pretty impractical. You'd have to have 2 cores to do the exact same thing, then some 'master' core that makes sure they're doing the right stuff, and if you really want to think about it... what if the core monitoring the cores fails... there's a threshold of when redundancy gets pointless. Perhaps I'm missing out on something, but you can't check the checker (without infinite redundancy). Honestly, if you're worried about a core failing, please take your server cluster out of the 1000 deg C forge. -Brandon ___ 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: cdparanoia stuck in cbwait
On Mon, Nov 07, 2011 at 04:58:53AM +0800, Denise H. G. wrote: Hi. Are you running FreeBSD 9.0? If yes, it seems that cdparanoia is broken because of some changes inside kernel, specifically, changes in scsi interfaces. If you have your system upgraded to 9.0, but not recompiled cdparanoia, you might run into some problems. I'm running FreeBSD 10.0-CURRENT amd64 (r226909) everything built in clang. About as unstable as one can possibly get. -Brandon ___ 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
cdparanoia stuck in cbwait
Hello, I was got some read errors when I was reading from my disk, which is fine. But then cdparanoia starting to no longer respond. Now it's zombied and sitting in cbwait. `kill -9 pid` does not take it down, it seems like it's stuck in the kernel (?). Is this an issue to look at cdparanoia for, or to look in the kernel? Perhaps cdparanoia or the kernel should have some sort of a timeout? Currently it looks like the only fix is a full reboot. Regards, Brandon Falk ___ 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: cdparanoia stuck in cbwait
On Sat, Nov 05, 2011 at 12:48:02PM -0400, Mark Johnston wrote: On Sat, Nov 05, 2011 at 12:42:12PM -0400, Brandon Falk wrote: Hello, I was got some read errors when I was reading from my disk, which is fine. But then cdparanoia starting to no longer respond. Now it's zombied and sitting in cbwait. `kill -9 pid` does not take it down, it seems like it's stuck in the kernel (?). Is this an issue to look at cdparanoia for, or to look in the kernel? Perhaps cdparanoia or the kernel should have some sort of a timeout? Currently it looks like the only fix is a full reboot. I've seen this problem a couple of times on -BETA2 as well. I haven't had time to try and figure out what's causing it, but a camcontrol reset of the bus will fix the problem without a reboot IIRC. -Mark No luck on the reset. When I reset, it says it was reset successfully, but cdparanoia still sits zombied, and nothing changes. If I do `camcontrol stop`, camcontrol hangs and becomes a zombie too (until I kill it's parent process) -Brandon ___ 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: cdparanoia stuck in cbwait
On Sat, Nov 05, 2011 at 01:47:03PM -0400, Mark Johnston wrote: On Sat, Nov 05, 2011 at 01:09:40PM -0400, Brandon Falk wrote: On Sat, Nov 05, 2011 at 12:48:02PM -0400, Mark Johnston wrote: On Sat, Nov 05, 2011 at 12:42:12PM -0400, Brandon Falk wrote: Hello, I was got some read errors when I was reading from my disk, which is fine. But then cdparanoia starting to no longer respond. Now it's zombied and sitting in cbwait. `kill -9 pid` does not take it down, it seems like it's stuck in the kernel (?). Is this an issue to look at cdparanoia for, or to look in the kernel? Perhaps cdparanoia or the kernel should have some sort of a timeout? Currently it looks like the only fix is a full reboot. I've seen this problem a couple of times on -BETA2 as well. I haven't had time to try and figure out what's causing it, but a camcontrol reset of the bus will fix the problem without a reboot IIRC. -Mark No luck on the reset. When I reset, it says it was reset successfully, but cdparanoia still sits zombied, and nothing changes. If I do `camcontrol stop`, camcontrol hangs and becomes a zombie too (until I kill it's parent process) Hm, perhaps I'm misremembering it. I'll try to reproduce it when I get a chance. I did a reboot, which ended up hanging... I had to forcefully reboot as it seems the reboot process must not have liked that lingering request. I booted up, and I got the same error when the CD was in the drive... I've not had issues with other CDs, nor did I have an issue till I ripped the first 8 tracks of this one... that's when everything went wrong. I'll try the sysctl stuff mentioned before. -Brandon ___ 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
Issue building pango on FreeBSD 10.0 amd64 (r226893) with clang
I'm currently getting this issue building pango (everything, including world
and kernel, have been built with clang):
/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-color-table.h:762:
syntax error, unexpected identifier in 'guint16 name_offset;' at
'guint16'
/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-color-table.h:768:
syntax error, unexpected identifier, expecting ',' or ';' in 'static const
ColorEntry color_entries[] = {' at 'color_entries'
/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-language-sample-table.h:52:
syntax error, unexpected identifier in 'LANGUAGE(' at 'LANGUAGE'
CCLD libpangoxft-1.0.la
CCLD libpangocairo-1.0.la
/usr/bin/ld: /usr/local/lib/libXft.a(xftdpy.o): relocation R_X86_64_32
against `_XftDisplayInfo' can not be used when making a shared object;
recompile with -fPIC
/usr/local/lib/libXft.a: could not read symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
gmake[4]: *** [libpangoxft-1.0.la] Error 1
gmake[4]: *** Waiting for unfinished jobs
g-ir-scanner: Pango: warning: 57 warnings suppressed (use --warn-all to see
them)
gmake[4]: Leaving directory
`/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr/ports/x11-toolkits/pango/work/pango-1.28.4'
gmake: *** [all] Error 2
*** Error code 1
Any ideas? Perhaps it's just some crazy temporary issue? I'll look into it
tomorrow, but I gotta catch some sleep.
Thanks in advance,
Brandon Falk
___
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: Issue building pango on FreeBSD 10.0 amd64 (r226893) with clang
On 10/29/2011 1:51 AM, Brandon Falk wrote:
I'm currently getting this issue building pango (everything, including world
and kernel, have been built with clang):
/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-color-table.h:762:
syntax error, unexpected identifier in 'guint16 name_offset;' at
'guint16'
/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-color-table.h:768:
syntax error, unexpected identifier, expecting ',' or ';' in 'static const
ColorEntry color_entries[] = {' at 'color_entries'
/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-language-sample-table.h:52:
syntax error, unexpected identifier in 'LANGUAGE(' at 'LANGUAGE'
CCLD libpangoxft-1.0.la
CCLD libpangocairo-1.0.la
/usr/bin/ld: /usr/local/lib/libXft.a(xftdpy.o): relocation R_X86_64_32
against `_XftDisplayInfo' can not be used when making a shared object;
recompile with -fPIC
/usr/local/lib/libXft.a: could not read symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
gmake[4]: *** [libpangoxft-1.0.la] Error 1
gmake[4]: *** Waiting for unfinished jobs
g-ir-scanner: Pango: warning: 57 warnings suppressed (use --warn-all to see
them)
gmake[4]: Leaving directory
`/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr/ports/x11-toolkits/pango/work/pango-1.28.4'
gmake: *** [all] Error 2
*** Error code 1
Any ideas? Perhaps it's just some crazy temporary issue? I'll look into it
tomorrow, but I gotta catch some sleep.
Thanks in advance,
Brandon Falk
___
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
(I'm the original poster... just on a different email)
I went to bed, and woke up, and the port(s) were fixed and the issues
went away.
[NOTE: This was not a clang issue, gcc acted the same way]
To continue with my build (of vim which has now succeeded), I had to
deinstall and reinstall the following ports (due to getting the same
errors on these ports):
x11-fonts/libXft
x11/libXi
x11/libXrandr
x11/libXcursor
x11/libXcomposite
x11/libXdamage
Perhaps I'll have the same issue on other ports, and I'll have to
reinstall them. But I doubt anyone has really experienced this issue, as
it seems like it was a small window in ports where this error occurred?
Or perhaps it's a 10.0 issue that's been ongoing and discussed elsewhere.
Anyways... this is FIXED.
Regards,
Brandon Falk
___
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: 9-beta1 installer - partition editor
Original Message Subject:Re: 9-beta1 installer - partition editor Date: Wed, 31 Aug 2011 10:19:32 -0400 From: Brandon Falk falk...@gamozo.org To: Ivan Voras ivo...@freebsd.org On 8/31/2011 6:19 AM, Ivan Voras wrote: On 31/08/2011 02:40, Nathan Whitehorn wrote: On 08/30/11 19:07, Ivan Voras wrote: It was a plain install on a RAID volume which appears as ordinary da0 drive. I did do a couple of start-overs so it could be that some state got lost. It definitely did NOT show mount points in the dialog which lists newly created partitions. Which partitioning scheme did you use? How did you lay out the partitions? I did not deviate from defaults until the partition editor, where I deleted existing partitions (Linux) and tried to create new ones. So, it's a MBR scheme, and I intended to create three partitions, for /, for /srv and a swap partition. I think Andrey's idea about what went wrong with the swap partition is most probably correct, so this only leaves the inability to register mount points with the partitions. However, if as Brandon suggested this is already fixed, don't bother. I'll try the BETA2 when ISOs become available and will post screenshots (IPMI) if it fails again. ___ 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 Sorry, I was using GPT, so that could be why my results differed. -Brandon Falk ___ 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: 9-beta1 installer - partition editor
On 8/30/2011 8:27 AM, Ivan Voras wrote: Am I doing something wrong or the BETA1 installer cannot be used to manually create the partition scheme? 1) it doesn't accept freebsd-swap as partition type (invalid argument) 2) it doesn't recognize that I have actually created a root (/) mount point; since it doesn't show mountpoints maybe it forgets the input from the dialog? The partition editor looks very rudimentary and feature-less. It really should show space left on the drive. ___ 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 What is the rev you are using, as well as the arch? I've had no issues ever with partitioning (less the limitations of the partitioner) on numerous revs of 9, although all of my testing has been done on the exact same arch. I also use guided partitioning, and partition entire disk, then I go through and delete all the partitioning info, and start from scratch (why I do this, I have no clue). As for size left, that's something that really bothers me. I usually go through into command line, and use gpart to set up my system instead. I do not have BETA1 available right now on CD, but I do have BETA2 rev 225251. On this system I'm not able to replicate your issue (amd64). I know I'm using a newer rev, but I've been using 9 for a long time now, and I've yet to have an issue with the partitioner. As for your second question, where did you create the root mount point prior to the editor? Or was it still on the editor that you made it? -Brandon Falk ___ 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: Issue with 'Unknown Error: -512'
On 7/25/2011 4:47 AM, Robert Watson wrote: On Mon, 18 Jul 2011, Andriy Gapon wrote: In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi' test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi' test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. Any tips? Otherwise I'll be looking into this today myself. Just a hint that you could try using DTrace syscall and fbt providers to see where in kernel (if in kernel) that -512 return value originates. Jon Anderson spotted that here during some Capsicum work -- initially we were concerned it was a local patch, but it sounds like it might be less local. I think he saw it on calls to open(2) as well, and I couldn't help but wonder (given its recent arrival) if it was an outcome of the change to break falloc into two parts, leading to some or another problematic handling of file descriptor numbers. I.e., it's not so much that -512 is being returned, as a number that's a bad file descriptor. (Although now having seen 512 twice on two different machines, that particular explanation seems less credible). Perhaps this is indeed unrelated to Capsicum, and triggered by a clang bug or something else. I've CC'd Jon, maybe he has gained further insight since we chatted. Robert I've been building head every single day to check for the disappearance of this bug, and it seems to be gone as of 224302 (maybe before, but 224302 is what I built). I wrote a program to do tons of open()s and truncate()s to try to get the error, where initially I'd get an error every other attempt, then it was every 100 or so iterations it would fail, now I've tested 500,000 opens and truncates and there have been no issues. -Brandon Falk ___ 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: Issue with 'Unknown Error: -512'
On 7/19/2011 10:31 AM, Brandon Falk wrote: On 7/19/2011 5:14 AM, Dimitry Andric wrote: On 2011-07-18 16:53, Brandon Falk wrote: In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). I have never seen this, neither with clang-compiled nor gcc-compiled systems. Can you please verify if it still occurs if you build your system with gcc? If you don't want (or can) rebuild the whole system, you can try to rebuild just your kernel with gcc, and see if the problems disappear. Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi' test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi' test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. I have been running clang-compiled systems for a long time now, and have never seen this. It works fine here, I cannot reproduce any of your examples. Do you build with any special settings in make.conf or src.conf, particularly modified CFLAGS or COPTFLAGS? What is your architecture, i386 or amd64? Any other non-standard configuration or environment settings? Dimitry, I will try to build with gcc sometime today. I might as well try out a different filesystem too. I have no special settings besides CPUTYPE?=native, but there was someone with a similar error who did not specify a cpu type when building, so I know that isn't a problem. Arch is amd64, no other nonstandard configuration. -Brandon Falk ___ 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 I just did a clang build with CPUTYPE?=native and the unknown error issue has seemed to calm down a large amount. I still occasionally get it, but given multiple attempts at say compiling software, it will move on and all will be well. It is for sure not happening every other O_TRUNC, but it is still happening. Depending on system configuration, this still could cause some major issues for people. I'll keep my eye out and see what changes and try to figure out how to duplicate the issue on the new rev. Rev: 224221 Built with clang and CPUTYPE?=native -Brandon Falk ___ 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: Issue with 'Unknown Error: -512'
On 7/19/2011 7:31 AM, Garrett Cooper wrote: On Tue, Jul 19, 2011 at 4:58 AM, Garrett Cooperyaneg...@gmail.com wrote: On Mon, Jul 18, 2011 at 5:19 PM, Brandon Falkfalk...@gamozo.org wrote: On 7/18/2011 10:18 AM, Andriy Gapon wrote: on 18/07/2011 17:53 Brandon Falk said the following: Hello, In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi'test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi'test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. Any tips? Otherwise I'll be looking into this today myself. Just a hint that you could try using DTrace syscall and fbt providers to see where in kernel (if in kernel) that -512 return value originates. Update: I've traced more and more into the kernel, and currently I have found the following trace: ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) vn_truncate() (in sys/kern/vfs_vnops.c:636) kern_openat() (in sys/kern/vfs_syscalls.c:1043) kern_open() (in sys/kern/vfs_syscalls.c:1035) open() (in sys/kern/vfs_syscalls.c:1006) ufs_setattr() returns with -1 (EPERM) I'll continue to try to find the exact problem. A quick workaround currently would probably be to use a different filesystem other than ufs, but then again, I have no clue if other filesystems have the same issue. Hopefully that trace will help anyone who wants to help out. What UFS options do you have defined in your kernel? Also, what does mount say and have you tried running as root? Thanks, -Garrett Garrett, I am running as root. No issues with the mounting. As for options, which do you want? -Brandon Falk ___ 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: Issue with 'Unknown Error: -512'
On 7/19/2011 5:14 AM, Dimitry Andric wrote: On 2011-07-18 16:53, Brandon Falk wrote: In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). I have never seen this, neither with clang-compiled nor gcc-compiled systems. Can you please verify if it still occurs if you build your system with gcc? If you don't want (or can) rebuild the whole system, you can try to rebuild just your kernel with gcc, and see if the problems disappear. Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi' test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi' test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. I have been running clang-compiled systems for a long time now, and have never seen this. It works fine here, I cannot reproduce any of your examples. Do you build with any special settings in make.conf or src.conf, particularly modified CFLAGS or COPTFLAGS? What is your architecture, i386 or amd64? Any other non-standard configuration or environment settings? Dimitry, I will try to build with gcc sometime today. I might as well try out a different filesystem too. I have no special settings besides CPUTYPE?=native, but there was someone with a similar error who did not specify a cpu type when building, so I know that isn't a problem. Arch is amd64, no other nonstandard configuration. -Brandon Falk ___ 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
Issue with 'Unknown Error: -512'
Hello, In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi' test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi' test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. Any tips? Otherwise I'll be looking into this today myself. -Brandon Falk ___ 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: Issue with 'Unknown Error: -512'
On 7/18/2011 10:18 AM, Andriy Gapon wrote: on 18/07/2011 17:53 Brandon Falk said the following: Hello, In recent branches (confirmed with 224119) builds compiled with clang happen to throw 'Unknown error: -512' in a lot of places, making the system unusable. (Untested on gcc compiled systems). Originally I thought the problem was with specific programs, then I narrowed it down to file I/O, and now I've narrowed it down to open() with O_TRUNC. Without O_TRUNC there seems to be no issues whatsoever. With O_TRUNC on open() it fails with that 'Unknown error: -512' every other time you run the program. Common issues, portsnap is affected, making it impossible to fetch/extract ports. As well as redirecting output in shells eg `echo 'hi' test` fails every other try. You have the same issue with text editors like `edit` where it fails every other save. There are no issues with `echo 'hi' test` as there is no O_TRUNC, it only seems to be an O_TRUNC error. Any tips? Otherwise I'll be looking into this today myself. Just a hint that you could try using DTrace syscall and fbt providers to see where in kernel (if in kernel) that -512 return value originates. Update: I've traced more and more into the kernel, and currently I have found the following trace: ufs_setattr() (in sys/ufs/ufs/ufs_vnops.c:507) (In truncate a bunch of stuff is done, but it succeeds until VOP_SETATTR) vn_truncate() (in sys/kern/vfs_vnops.c:636) kern_openat() (in sys/kern/vfs_syscalls.c:1043) kern_open() (in sys/kern/vfs_syscalls.c:1035) open() (in sys/kern/vfs_syscalls.c:1006) ufs_setattr() returns with -1 (EPERM) I'll continue to try to find the exact problem. A quick workaround currently would probably be to use a different filesystem other than ufs, but then again, I have no clue if other filesystems have the same issue. Hopefully that trace will help anyone who wants to help out. -Brandon Falk ___ 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: System Fails to Boot (Deadlock?)
On 7/13/2011 10:58 AM, John Baldwin wrote: On 7/13/11 9:37 AM, Brandon Falk wrote: On 7/13/2011 6:49 AM, John Baldwin wrote: On Tuesday, July 12, 2011 6:10:05 pm Brandon Falk wrote: Hello, My machine somehow fails to boot into FreeBSD (off the cd, since it fails to boot, I can't install it in the first place). It goes through and ends up stopping deadlock style. No printouts of errors (besides a ppc problem, which is not fatal) and no crash/oops/panic. It just... stops and locks up. I know my motherboards PCI system has failed, as well as lan (getting a new one tomorrow), which is probably what is causing the problem. The thing is that Windows 7 and Linux happen to boot just fine on my machine, so although my system has a failing motherboard and may cause errors, I still feel like it shouldn't be causing this much of an issue on boot. I tried verbose logging and got no more information anyways. It will be nearly impossible to diagnose this error so I'm looking for tips on where to look. How far does it get when it locks? Is it able to load /boot/loader off of the CD ok? Is it getting into the kernel far enough to output stuff to the console? Is it getting into sysinstall and hanging at some sysinstall screen? Also, is this host on the network and able to PXE? It's a lot easier to test custom kernels if needed using PXE than CDs (no need to burn a new CD each time, etc.). Since it's on a native box, I have no good way of copying the text, so perhaps later I'll copy it by hand. /boot/loader launches just fine, and it's outputting messages just fine, until it just halts. It does not hit sysinstall. This box also does not have net as LAN is shot on the motherboard (hence getting the new motherboard). What is the last message it outputs before it hangs? Hello, Sorry, I've been busy with work and I can't be bothered with rebooting my machine right now. But, it seems I have duplicated a very similar issue under a VM. Under the 9.0-CURRENT-201105-amd64-bootonly.iso iso it 'locks' up during boot with yet again no error message or crash. This only seems to happen when 8 cores are allocated to the VM, everything is just fine and dandy with 4, 2, or 1 core(s). (Note, on my native box I was using the 8.2-RELEASE amd64 bootonly iso). On the VM the last messages I get are: SMB: AP CPU #x Launched! x being a number inclusive and between 1-7, in a random order (obviously the cpus start at 'random' times). I cannot duplicate this error on a successfully installed FreeBSD-8.2-RELEASE-amd64 using the same hardware settings. Hmm, I just thought perhaps it is a CD issue... I tried FreeBSD-8.2-RELEASE-amd64-bootonly on 8, 4, 2, and 1 cores, and it seems to work just fine... argh. -Brandon ___ 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: System Fails to Boot (Deadlock?)
On 7/13/2011 8:14 PM, Brandon Falk wrote: On 7/13/2011 10:58 AM, John Baldwin wrote: On 7/13/11 9:37 AM, Brandon Falk wrote: On 7/13/2011 6:49 AM, John Baldwin wrote: On Tuesday, July 12, 2011 6:10:05 pm Brandon Falk wrote: Hello, My machine somehow fails to boot into FreeBSD (off the cd, since it fails to boot, I can't install it in the first place). It goes through and ends up stopping deadlock style. No printouts of errors (besides a ppc problem, which is not fatal) and no crash/oops/panic. It just... stops and locks up. I know my motherboards PCI system has failed, as well as lan (getting a new one tomorrow), which is probably what is causing the problem. The thing is that Windows 7 and Linux happen to boot just fine on my machine, so although my system has a failing motherboard and may cause errors, I still feel like it shouldn't be causing this much of an issue on boot. I tried verbose logging and got no more information anyways. It will be nearly impossible to diagnose this error so I'm looking for tips on where to look. How far does it get when it locks? Is it able to load /boot/loader off of the CD ok? Is it getting into the kernel far enough to output stuff to the console? Is it getting into sysinstall and hanging at some sysinstall screen? Also, is this host on the network and able to PXE? It's a lot easier to test custom kernels if needed using PXE than CDs (no need to burn a new CD each time, etc.). Since it's on a native box, I have no good way of copying the text, so perhaps later I'll copy it by hand. /boot/loader launches just fine, and it's outputting messages just fine, until it just halts. It does not hit sysinstall. This box also does not have net as LAN is shot on the motherboard (hence getting the new motherboard). What is the last message it outputs before it hangs? Hello, Sorry, I've been busy with work and I can't be bothered with rebooting my machine right now. But, it seems I have duplicated a very similar issue under a VM. Under the 9.0-CURRENT-201105-amd64-bootonly.iso iso it 'locks' up during boot with yet again no error message or crash. This only seems to happen when 8 cores are allocated to the VM, everything is just fine and dandy with 4, 2, or 1 core(s). (Note, on my native box I was using the 8.2-RELEASE amd64 bootonly iso). On the VM the last messages I get are: SMB: AP CPU #x Launched! x being a number inclusive and between 1-7, in a random order (obviously the cpus start at 'random' times). I cannot duplicate this error on a successfully installed FreeBSD-8.2-RELEASE-amd64 using the same hardware settings. Hmm, I just thought perhaps it is a CD issue... I tried FreeBSD-8.2-RELEASE-amd64-bootonly on 8, 4, 2, and 1 cores, and it seems to work just fine... argh. -Brandon Hello, Sorry for spamming out more and more messages, but I noticed another pattern in the VM. It happens to fail sometimes even on 4 cores, it seems to be COMPLETELY random (ugh...), in the matter that one time it will boot, I'll do nothing but hit 'reboot', then it will work, then it wont, then it will, etc. I am not making any modifications to the system or hardware, it just seems to be completely random. I bet that sometime I may be able to get it to boot in a kernel with even 8 cores, but the randomness would make it very hard to do so. I'll try to get more information when I get back soon. Give me a heads up if this problem seems to be a common issue or something I may be overlooking. I'm anticipating putting FreeBSD on my main machine, but since I have 12 cores on my main machine, I don't think it will boot any time soon... -Brandon ___ 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
System Fails to Boot (Deadlock?)
Hello, My machine somehow fails to boot into FreeBSD (off the cd, since it fails to boot, I can't install it in the first place). It goes through and ends up stopping deadlock style. No printouts of errors (besides a ppc problem, which is not fatal) and no crash/oops/panic. It just... stops and locks up. I know my motherboards PCI system has failed, as well as lan (getting a new one tomorrow), which is probably what is causing the problem. The thing is that Windows 7 and Linux happen to boot just fine on my machine, so although my system has a failing motherboard and may cause errors, I still feel like it shouldn't be causing this much of an issue on boot. I tried verbose logging and got no more information anyways. It will be nearly impossible to diagnose this error so I'm looking for tips on where to look. I'm an avid programmer and I could fix the problem if I were able to find it. I could just compile custom kernels to give printout and debug messages every step, but that would be a long process if there is a better way. Keep in mind I do not have FreeBSD installed, no serial or parallel ports, and I'm booting from a CD. Once I get the new motherboard I will probably not care about fixing this problem, as I'd be replacing it. So this is more of an overnight deal that I'd like to look into. System: Intel i7 970 24GB ram Asus Sabertooth X58 motherboard If you need more system info, I'd be glad to give it. -Brandon Falk ___ 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
Leaks in libc?
The simple program:
#include stdlib.h
#include stdio.h
int main()
{
puts(Apple cider);
return 0;
}
Yields the following result in valgrind:
==4703== Memcheck, a memory error detector
==4703== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4703== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==4703== Command: ./a.out
==4703==
Apple cider
==4703==
==4703== HEAP SUMMARY:
==4703== in use at exit: 4,096 bytes in 1 blocks
==4703== total heap usage: 1 allocs, 0 frees, 4,096 bytes allocated
==4703==
==4703== LEAK SUMMARY:
==4703==definitely lost: 0 bytes in 0 blocks
==4703==indirectly lost: 0 bytes in 0 blocks
==4703== possibly lost: 0 bytes in 0 blocks
==4703==still reachable: 0 bytes in 0 blocks
==4703== suppressed: 4,096 bytes in 1 blocks
==4703==
==4703== For counts of detected and suppressed errors, rerun with: -v
==4703== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Any ideas why the standard libraries are leaking like this? Is it
perhaps a bug with valgrind, or maybe FreeBSD automatically cleans up so
they took the cleanup out of their libc?
FreeBSD 8.0 x86_64
Thanks,
Brandon
___
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
