Attempting to boot into ramdisk on 8.3
I have a build process (which worked at release 7.3) that makes a bootable ISO using a ramdisk image as the boot volume. At release 8 it panics right after reporting the real memory size with: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode ... [thread pid 0 tid 0 ] Stopped at pmap_enter+0x19a:moveq (%rcx),%r14 (I have the text frozen on another screen if more data is needed, I've literally spent weeks trying to get this panic to appear on the screen so it's not going anywhere.) I build the world with this system without cross compiling. # uname -mrs FreeBSD 8.3-RC1 amd64 The system that paniced is very similar: a 64-bit amd4 system. What am I doing wrong, if anything? How can I do a successful large ramdisk boot? My process is to copy the entire OS to a ramdisk and boot off of that. I use the following ideas for this: /boot/loader.conf: mfsroot_type="mfs_root" mfsroot_name="/mfsboot" vfs.root.mountfrom="ufs:md0" vfs.root.mountfrom.options="rw" ## Tunables kern.ipc.nmbclusters=32768 net.inet.tcp.tcbhashsize=16384 vm.pmap.pg_ps_enabled=1 accf_http_load="YES" net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 The size of mfsboot is 600M. The diff between GENERIC and my kernel config, comments left in so people can see what I was doing 7.3ish: 28.43d26 < ### FBCD64 SPECIFIC < #options MD_ROOT_SIZE="524288" < options GEOM_UZIP < #options INCLUDE_CONFIG_FILE < #options ZERO_COPY_SOCKETS < #options HZ=1000 < #options DEVICE_POLLING < #options NKPT=600# not set up on amd64 < # < # Debugging < options KDB < options DDB < options BREAK_TO_DEBUGGER < options ALT_BREAK_TO_DEBUGGER Thanks in advance for any assistance! -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< One of the most common defenses against really learning something is to believe that one knows it already. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Attempting to boot into ramdisk on 8.3
Replying to myself here for the edification of those interested. A value of 320 for NKPT eliminated this crash, set in the kernel config file: options NKPT=320 For those of you with large ramdisk booting requirements, this one option will likely save you hours of trial and error. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< None should say "I can trust" or "I cannot trust" until they are the master of the option of trusting or not trusting. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You Using FreeBSD?
Flemming Jacobsen writes: > Damien Fleuriot wrote: >> You missed the bit about 3 reboots, while these don't take 15 mins each, >> they're still time consuming and disruptive. >> 1/ reboot after installing new kernel >> 2/ reboot after installing new world >> 3/ reboot after rebuilding ports > Or ... use sysbuild (/usr/src/tools/tools/sysbuild) and just boot > once. I respectfully disagree here. Sysbuild makes some assumptions about the partition layout which you'd need to factor in before you created your server. For the average layout (single disk, single partition), sysbuild won't be easy to make work. More generally, it's best not to clutter this interesting thread with delusions of rapidity. Given ports/packages/rpms/etc ... I claim it does not matter what system you use: There's just too much software out there that all has to work together to expect a simple upgrade to take 5 minutes on a well managed production server. I believe the more cogent solution is along these lines: Kevin Oberman writes: > Make your own freebsd-update server and build whatever custom system > you need. It does not need to be a GENERIC kernel. It does not need to > be RELEASE.Then use freebsd-update to update all of your production > systems with a single reboot and about 15 minutes (depending on system > and disk speed and I have not actually timed it).and it can be done > without console access or a single-user boot. If you take some time and plan your deployment and server layout, a single (even virtualized) server dedicated to building world and ports can help homogenize and streamline upgrades of large numbers of FreeBSD servers. I'd imagine that anything over 10 servers would almost demand this kind of attention to detail, but that's me. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< People complain about time being short, going fast. But when it seems to go slowly they complain that it drags. Let us consider the people, not the supposed movements of time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
Mehmet Erol Sanliturk writes: > If you are NOT using FreeBSD for any area or some areas , would you please > list those areas with most important first to least important last ? 1) I don't use FreeBSD for virtualization as the host OS. I really want to, becaus I want to be able to somewhat trust the kernel hosting my virtual machines. FreeBSD technology, support, and documentation for this idea appears unavailable. 2) I don't use FreeBSD for a 'modern' desktop. By 'modern' I mean areas which most rank and file users would need: day-to-day non technical browsing with flash, applications like skype, syncing to mobile devices, etc. I'd imagine this is important for rank and file users. However, I'm an old schooler who likes text based applications and command lines, and I personally feel that a lot of the desktop technologies out there (Gnome, KDE, Aqua, Windows) are inherently unsafe (security wise) for a desktop I do software development on. One glance at my X-mailer should tell many people where I'm at. ;) As an example (please don't think I'm singling KDE out here, I can likely find examples for each desktop technology out there) I was given to understand that the KDE file browser allowed the execution of javascript. This single rumor has kept me from trying out KDE for years. Again, nothing against KDE in particular, all of the 'user friendly' desktop technologies likely have something just as egregious. Thus, in many ways I feel it's a *feature* of FreeBSD that the desktop software lags behind everyone else. I don't want flash in my Firefox. I don't want hal, bonjour, or dbus as an extra attack surface. I don't want gnome to auto discover all the fileshares on my network(s). 3) I don't use FreeBSD for games, sadly. This is the only place where I will tolerate having a Windoze box, for my love of games exceeds my hatred of windows (yes I -really- do love games) and it's hard to find a better platform for games. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Freedom is free of the need to be free.-George Clinton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
Lars Engels writes: > I guess he made his experiences with that some years ago when support > for amd64 in the ports was not very mature. But this has changed since > then, apart from a few ports almost all of them should work on amd64 > without problems. I can vouch for this. I have several production and two development amd64 machines. I've yet to have a problem with a port because of the architecture. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Man does not have a capacity of instant comprehension. So rare is the knowledge of how to train this, that most people and institutions have compromised by playing upon man's proneness to conditioning and indoctrination instead. The end of *that* road is the ant-heap. Or, at best, the beehive. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
Gary Palmer writes: > Have you looked at VirtualBox? /usr/ports/emulators/virtualbox-ose > Its not a fully featured replacement for vSphere (e.g. no equivalent > of vMotion) but it is a perfectly workable virtualisation solution > for a number of situations. I don't necessarily need vMotion. Thanks greatly for the tip, which is very valuable and the reason I like discussions like these. As I am trying to try this, of course I ran into a snag. This snag is very relevant to the current discussion(s) about ports and "ease of use". # cd /usr/ports/emulators/virtualbox-ose # make config I'm now presented with a number of options, but no real documentation for what these options actually mean (to say nothing of the -fine points- which can be drastically important). I can pretty much guess Qt4 is for a GUI frontend, but pulseaudio? Eh? Why do I need sound, especially pulseaudio, in a virtualbox hypervisor? What is VDE? Do I really need that to do intra-virtual-box networking at all or are there other solutions? I know. Google is a resource. Still, would it kill us to have some sort of extra file of textual documentation lying around for each port that explained each option in a bit more depth, what ports it will try to include, and why you'd want it or not want it? Ok so continuing... # make install ...way later... In file included from socket/qabstractsocket.cpp:2927: .moc/release-shared/moc_qabstractsocket.cpp:14:2: error: #error "This file was generated using the moc from 4.7.4. It" .moc/release-shared/moc_qabstractsocket.cpp:15:2: error: #error "cannot be used with the include files from this version of Qt." .moc/release-shared/moc_qabstractsocket.cpp:16:2: error: #error "(The moc has changed too much.)" Here you "just have to know" that this kind of an error likely means that the qt4-moc port is out of date. At this point, a "normal" user gives up. (A smarter "normal" user gave up when they couldn't figure out what the port options really meant.) When I talk about documentation and support being unavailable, this is a decent example of what I mean. I see features and pkgng and things being offered up as solutions...these are all well and good, but in my opinion more comprehensive documentation and support in these areas would do more good than pkgng. Even for us seasoned experts, installing something new out of ports is sometimes met with at least an hour of googling, re-compiling, re-installing, and struggling. It goes smoothly often enough, but IMO not often enough for prime time. All these ideas presume that the FreeBSD community wants more users. I have a vague impression that a percentage of the community really doesn't. I'm not commenting on this other than to say I understand both sides and that my comments really only make sense if FreeBSD as a community really does want more users. :) Anyway, given my workload, it will probably take me a man week to get two virtualized test servers. Someone I know with a vmware gui and windows is doing this in 15 minutes (and that's being careful). Just my $0.02. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< There's only one corner of the universe you can be certain of improving and that's your own self. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
Mark Linimon writes: > On Sun, Jun 03, 2012 at 07:24:11PM -0700, Dave Hayes wrote: >> I see features and pkgng and things being offered up as solutions... >> these are all well and good, but in my opinion more comprehensive >> documentation and support in these areas would do more good than pkgng. > IMHO pkgng and optionsng are necessary, but not sufficient, to solve > our current problems. Optionsng is nice, but lacking in documentation. Is it too much to ask port maintainers to write a bit more documentation on the options they are providing? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Sunshine proves it's own existence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
Chris Rees writes: > On Jun 4, 2012 9:50 AM, "Dave Hayes" wrote: >> Mark Linimon writes: >> > On Sun, Jun 03, 2012 at 07:24:11PM -0700, Dave Hayes wrote: >> >> I see features and pkgng and things being offered up as solutions... >> >> these are all well and good, but in my opinion more comprehensive >> >> documentation and support in these areas would do more good than pkgng. >> > IMHO pkgng and optionsng are necessary, but not sufficient, to solve >> > our current problems. >> Optionsng is nice, but lacking in documentation. Is it too much to ask >> port maintainers to write a bit more documentation on the options they >> are providing? > Where are you looking? I updated the Porter's Handbook- is there something > missing? Yes there is...my point. :) Perhaps I was unclear. Optionsng is likely a fine project. However, it does not include the idea of extra documentation on the user selectable options provided to a port. Often when building a port I am presented with a list of build options. For example, virtualbox has this: OPTIONS= QT4 "Build with QT4 Frontend" on \ DEBUG "Build with debugging symbols" off \ GUESTADDITIONS "Build with Guest Additions" off \ DBUS "Build with D-Bus and HAL support" on \ PULSEAUDIO "Build with PulseAudio" off \ X11 "Build with X11 support" on \ UDPTUNNEL "Build with UDP tunnel support" on \ VDE "Build with VDE support" off \ VNC "Build with VNC support" off \ WEBSERVICE "Build Webservice" off \ NLS "Native language support" on What I feel is missing from ports is the information that would allow me to make intelligent decisions about each option. To see what's missing, consider the following questions: - Why would I want pulseaudio in a hypervisor? - What, exactly, are guestadditions and why would I want them? - Why does this need dbus and hal? - What is VDE? - What webservice? etc. The porter's handbook is fine if you are writing ports. It's using them that can get opaque. There's meta topics also, these would be great to know about without having to read 200 mail messages: - Some people do not like pulseaudio for good technical reasons. What are those? What are the non-technical opinion based reasons? - What are the common objections to HAL and DBUS? It's this kind of attention to communication that I think FreeBSD, in any attempt to reach more users, needs to strongly consider. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Treat people as if they are what they ought to be, and you help them to become what they are capable of being. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
Chris Nehren writes: > The descriptions of the options assume the admin is familiar with the > software they're installing. I do not think it is the FreeBSD Project's > purview to document every option for every port. At the very least it'd > take quite a lot of time and effort to document all of that. That's a fair position. Perhaps it would not be too much trouble to add this one idea to optionsng: a "more info" field on each option knob which may be filled in by a port maintainer. > Beyond this, such explanations would duplicate each port's own > documentation. Not necessarily. I don't have an example offhand, but I suspect there are a number of FreeBSD specific option knobs applied to ports. > If you're not familiar with something, you very probably shouldn't be > installing it. Basing my argument here on assumptions that FreeBSD wants more users, I would argue that the better policy is to be liberal in who you help and conservative in who you call unfamiliar. In this spirit, I can guarantee you that there are plenty of people who will install despite your requirement above, set some option that they shouldn't (or fail to set one that they should), and then come away with a bad experience. Instead, if the person familiar with the software (who is ostensibly writing the port) could spend just 5 more minutes writing a simple "this option is documented at url://..." or "dont set this if you have port foo installed" that would help a lot of people. > Show me one other similar packaging system that does this level of > handholding. The only comparable ones I can think of are portage and > macports, and they certainly don't, either. The absence of such a system isn't really relevant to the idea of improving the current one is it? :) -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
Daniel Kalchev writes: > On 04.06.12 22:32, Dave Hayes wrote: >> That's a fair position. Perhaps it would not be too much trouble to add >> this one idea to optionsng: a "more info" field on each option knob >> which may be filled in by a port maintainer. > The pkg-descr file in the port already contains link to the software's > origin. The various options the software has are or should be described > there. We definitely don't want the ports cluttered with extraneous and > sometimes out of date (and thus misleading) information. I'm describing more of a use case here, not attempting to specify an implementation. If a user invokes 'make', a window is presented to them with various options. It's probably very common that this is met with an initial reaction of "what the hell do these do?", even from the most seasoned of admins (presuming they are unfamiliar with the software they have been asked to install). I claim it would be an improvement to have that information at the fingertips of the make invoker. I believe this is the first time I've seen more documentation labeled as "extraneous". :) I had thought to suggest an implementation by having a simple pkg-option-desr file which describes the options and implications in each port. Are you suggesting that such a file would be unwelcome? I have built many ports for many years. IIRC I've seen the option descriptions you mention in pkg-descr maybe 0.1% of the time. (That's my sense, not a measured objective number.) Usually I have to go digging through the Makefile, then the source to find these answers. > In all case, compiling from source is not for those having no clue > what they do. ... you need to make informed decisions on options > yourself. If this is beyond you (and not you personally), ... > Since it is very likely that you interpret this as yet another elitist > comment, Actually, I hadn't thought of this conceptual linkage until you suggested it here. :) Still, you are quite correct. The likelihood of anyone interpreting your position as 'elitist' from these comments is high. I will, of course, not interpret them that way. > If this is beyond you (and not you personally), then by all means use > pre-packaged software in binary form. Heh. Even this idea is beyond most normal users, who should likely use PC-BSD or Ubuntu. In responding in this thread, I was thinking of the reasonably clued system admin level users when I said "users". As an SA, in many situations, you aren't able to have fun digging for information. It's much easier to have the answers right here in front of you. I know if I ever committed a port, I would quite likely spend the extra five minutes to put option documentation in a number of places, even if this angered some of the more anal of the community. > elsewhere" or "apparently, you don't want the number of FreeBSD users to > grow". Then you waste everyone's time -- that could be spent on > answering other people's "stupid" questions. I see. Personally, I believe this way: It is the responsibility of the responder to determine whether their response is a waste of time or not. Blaming anyone else other than you (the generic 'you', not you personally) for the inappropriate use of your time should only really happen in an employment or indentured servitude relationship; certainly not on a mailing list. :) Given that the "FreeBSD wants more users" idea is repeatedly brought up on lists (at least this is my impression), I would presume that the subject of 'more users' is somewhat relevant to some people; one look at the subject of this thread should be enough to demonstrate relevance. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Implementation: (n.) The fruitless struggle by the talented and underpaid to fulfill promises made by the rich and ignorant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Documenting 'make config' options
Doug Barton writes: > On 06/06/2012 11:59, Dave Hayes wrote: >> I'm describing more of a use case here, not attempting to specify an >> implementation. If a user invokes 'make', a window is presented to them >> with various options. It's probably very common that this is met with an >> initial reaction of "what the hell do these do?", even from the most >> seasoned of admins (presuming they are unfamiliar with the software they >> have been asked to install). I claim it would be an improvement to have >> that information at the fingertips of the make invoker. > What manner of providing this information would meet your needs? Personally, a 'pkg-options-descr' text file would suit me just fine. I don't claim this is a good or bad idea from the general perspective of FreeBSD users as a group. ;) From that perspective, the menu example suggested by Warren Block is decent; perhaps with an added button to "reset to defaults". From a quick persual of dialog(1), I'm sure something similar in functionality could be used without having to modify dialog itself. My loose attempt at requirements is that "enough" information about each option be in one place in the port skeleton to make an informed decision about whether to turn that option on or off. There should be a clear paragraph explaining what the option does, what consequences it might have if you enable/disable it, and why the default was chosen. BTW, thank you for changing the subject line. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Never promise, even by implication, without fulfilling your promise. The only acceptable alternative to completing an undertaking is to over-fulfil it. To betray any promise, explicit or otherwise, will harm you more than it can harm anyone else. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Documenting ports options (was Re: Why Are You NOT Using FreeBSD ?)
[ This probably should be redirected to freebsd-ports but I am not subscribed so the anal mailer will likely reject such a submission ] Rainer Duffner writes: > Am 06.06.2012 um 20:59 schrieb Dave Hayes: >> I believe this is the first time I've seen more documentation labeled as >> "extraneous". :) I had thought to suggest an implementation by having a >> simple pkg-option-desr file which describes the options and implications >> in each port. Are you suggesting that such a file would be unwelcome? >> > No, but take a look at the nginx port, which (I'm too lazy to count) > has gained a couple of dozens of options over the years. This is a port I use often, and yes...it's a lot of work to document it. It is good to read the nginx wiki to learn what these are and perhaps any initial foray into documenting these options should merely be a set of links, each one telling us where this option is discussed on the nginx wiki. I had to go read the wiki too, and it's required reading if you do advanced nginx work like I do. Still, it takes 5 minutes to add links to a text file in the port eh? > Asking him to do even more work - I wouldn't dare to do that ;-) So don't ask, just write some links. ;) > Sometimes, options only make sense in context of the selection of > options of other ports and it thus may no be easily explainable in one > line. I don't understand Are you saying this is a reason not to document what these options do? > Personally, I don't need more frequent FreeBSD-releases but two or > maybe three ports-tree freezes per year would be good. While I have learned a bit more about ports by reading this and other threads, I rarely worry about ports freezes. Production software in ports is a moving target (security fixes, bug fixes, etc). I use portsnap a lot. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Exaggeration is a standard peculiarity of man. To deprecate is often a form of exaggeration which people do not notice because it appears to be its opposite. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
Adam Strohl writes: > There in lies the question -- why do you need to compile a port which > was just released? Is it a security thing or is it "I want the latest" > ? I'm just curious (and totally uninterested in how this ranks in your > "worse question" list). If I weren't honorable, I'd consider this question a troll. It's so far afield from my daily reality...well I'm going to take this at face value, because maybe -I've- got something wrong. ;) Let's just consider Firefox, which has a rather aggressive release schedule (once a month). $ pkg_info -r firefox-10.0.3,1 | grep Dependency | wc -l 175 Look at some of these dependencies: $ pkg_info -r firefox-10.0.3,1 | grep Dependency | sort ... Dependency: cairo-1.10.2_3,1 ... Dependency: gtk-2.24.6 ... Dependency: libgnome-2.32.0 ... Dependency: perl-threaded-5.14.2_2 ... Dependency: python27-2.7.2_4 Basically, everytime you want to upgrade firefox to 'stay current', you are upgrading a fair number of heavyweight packages. The chances that these will change month to month are high. (In the interests of brevity I will leave the verification of this to interested parties). Any of the ports listed above can have dependencies and consequences that reach very far into your workflow. If you do not upgrade them, you risk that firefox breaks in unknown ways. This is a rock and a hard place...do you upgrade everything from scratch (safest, but the 48 hour downtime is not unreasonable) or do you try to just replace that one port (risky, but you'll likely be up in an hour)? For firefox, it might very well be a security thing that causes the upgrade. Note well that I am not running 12 (is it at 12 now? 13? urgh.) because I'm in development and I do not want to touch certain other ports. Do I have this wrong? Anyone see a problem with this picture? What can we do to "just upgrade" in a safe fashion when we want to? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< The treasure house within you contains everything, and you are free to use it. You don't need to seek outside. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Locking a file backed mdconfig into memory
On FreeBSD 7.3-STABLE I'm mounting a DVD and doing something like this: mdconfig -a -t vnode -o reserve -o readonly -f /dvd/file so that /dvd/file becomes the backing storage for my memory disk. Now if the system is under severe memory pressure, will this memory get swapped out, causing a read from the DVD? How would I tell the system to never swap this file out of ram, even under severe memory pressure? The idea is to load this backing storage once and only once from the DVD into memory and leave it there. Thanks in advance. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Have you noticed how economical the human race is with it's idols? It sets them up, enjoys them, then falls upon them and devours them until nothing is left. Even the complete consumption of the idol, if it is another human being, is not the end. There are then hundreds of years worth of argument and analysis to be worked through... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Locking a file backed mdconfig into memory
Clifton Royston writes: > It sounds like what you really want is to load the contents of the > specified file as a memory system? That's not part of mdconfig's > repertoire, to the best of my recollection. So if, in /etc/loader.conf, I do this: rootfs_load="YES" rootfs_type="mfs_root" rootfs_name="/mfsboot" vfs.root.mountfrom="ufs:md0" and /mfsboot comes from a bootable DVD, am I to assume that this mount is under the same constraint? Specifically, this constraint is that the /mfsboot file (and hence the DVD) will be read repeatedly if the system is under memory pressure. > If that's what you want, you need to use a different tool; the purpose > of mdconfig is to provide scratch disk. The backing store is to > specify a region its contents can be swapped out to if the system is > under memory pressure (which certainly won't work with a DVD) Heh. Certainly I am using tools for purposes which may not match the original intention. If I wanted to run the rootfs on a memory device which did -not- swap to the backing store of /mfsboot, how would I go about doing that? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Faith (n): The quality by which we believe what we would otherwise think was false. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Locking a file backed mdconfig into memory
Jeremy Chadwick writes: > On Fri, May 28, 2010 at 10:57:29AM -0700, Dave Hayes wrote: >> Clifton Royston writes: >> > It sounds like what you really want is to load the contents of the >> > specified file as a memory system? That's not part of mdconfig's >> > repertoire, to the best of my recollection. >> >> So if, in /etc/loader.conf, I do this: >> >> rootfs_load="YES" >> rootfs_type="mfs_root" >> rootfs_name="/mfsboot" >> vfs.root.mountfrom="ufs:md0" > > I think you mean /boot/loader.conf? Yes, you are correct. > And I think you meant this for variable names, in addition to what > vfs.root.mountfrom should be (specific to RELENG_8): > mfsroot_load="YES" > mfsroot_type="mfs_root" > mfsroot_name="/some/path/mfsroot" I'm using RELENG_7, but it seems rootfs_* works just like mfsroot_* ... is the former deprecated? > vfs.root.mountfrom="ufs:/dev/md0" Hm, 'ufs:md0' currently works. What trouble can be had from using the abbreviated device name? > If using RELENG_7 and the mfsroot was made on RELENG_7, replace > "/dev/md0" with "/dev/md0c". Is there a reason for doing this? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< If you want to strengthen an enemy -- hate them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Locking a file backed mdconfig into memory
Garrett Cooper writes: > This is how I do it in my quickie loader.rc: > include /boot/loader.4th > set vfs.root.mountfrom="ufs:/dev/md0" > load /kernel > load -t mfs_root /mfsroot > start I used to do exactly this back at FreeBSD 4.11 to boot off a cdrom. Nice to know it still works this way. Jeremy Chadwick writes: > However, what I'm having trouble understanding is what exactly > preload_search_info() looks for and how all this actually connects > and works. It appears to me that there are specific drivers located in > src/sys/dev that are KLD-supported and others which are expected to be > included in the kernel statically. Maybe this confusion explains why /dev/md0c is giving me random crashes at the moment? Of course, another theory might be the size of my initial ramdisk (300Mb). Would there any known bug where booting off a large ramdisk causes unreadable panics to flash past the console too rapidly to view? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< By and large, language is a tool for concealing the truth. -George Carlin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Locking a file backed mdconfig into memory
Jeremy Chadwick writes: > Is the mfsroot file compressed (.gz extension)? Reason I ask is that > the OP states he's using RELENG_7... Yes it is compressed. > http://jdc.parodius.com/freebsd/pxeboot_serial_install_7.html#step7 Thanks much for this. I did a simple test, I rebuilt a DVD that wasn't booting to use a lower level of compression (gzip -9 to gzip -6) on mfsroot without changing anything else. This caused it to boot normally. I'm not sure it's conclusive evidence, but it certainly looks like a weak datapoint supporting this kernel bug being the source of my problem. Is this problem fixed in 8.0 or by a patch? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Suggested definition of "sin": Trading aliveness for survival. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Locking a file backed mdconfig into memory
Jeremy Chadwick writes: > CC'ing jhb@ since he last updated PR kern/120127 (which I would say is > still a problem on RELENG_7 :-) ). John, are you aware of any gzip > decompression / mfsroot changes which might explain the problem on > RELENG_7? I haven't done a "thorough" series of tests, but on my > testbed boxes RELENG_8 works fine with a gzip'd mfsroot. I can get you an iso that crashes when you try to boot it, if that will help? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Your ego is a failed API for a system that doesn't need your input. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Locking a file backed mdconfig into memory
Dave Hayes writes: > Jeremy Chadwick writes: >> CC'ing jhb@ since he last updated PR kern/120127 (which I would say is >> still a problem on RELENG_7 :-) ). John, are you aware of any gzip >> decompression / mfsroot changes which might explain the problem on >> RELENG_7? I haven't done a "thorough" series of tests, but on my >> testbed boxes RELENG_8 works fine with a gzip'd mfsroot. > I can get you an iso that crashes when you try to boot it, if that > will help? Well this doesn't seem to be the compression issue, since I just tried a test without compressing the ramdisk image. It still crashes. I'm back to thinking it's the size of the ramdisk image itself, but really I've no clue. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< "In theory, there is no difference between theory and practice. In practice, there is." -- Jan L. A. Van De Snepscheut ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Locking a file backed mdconfig into memory
John Baldwin writes: > Ok, if you are using a stock mfsroot from a release build, that should > work fine. If you have built a custom mfsroot that is larger, then > you may need to increase NKPT on i386. In very recent 7 and later you > can do this by setting it to a new value in your kernel config. In > older versions you can do this by manually adding a #define to set a > new value of NKPT in opt_global.h or hacking on the source directly. Is this also true for amd64 (which is my particular target)? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< "Be who you are and say what you feel, because those who mind don't matter, and those who matter don't mind." - Dr. Seuss ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Locking a file backed mdconfig into memory
John Baldwin writes: > On Wednesday 02 June 2010 6:37:59 pm Dave Hayes wrote: >> John Baldwin writes: >> > Ok, if you are using a stock mfsroot from a release build, that should >> > work fine. If you have built a custom mfsroot that is larger, then >> > you may need to increase NKPT on i386. In very recent 7 and later you >> > can do this by setting it to a new value in your kernel config. In >> > older versions you can do this by manually adding a #define to set a >> > new value of NKPT in opt_global.h or hacking on the source directly. >> >> Is this also true for amd64 (which is my particular target)? > > It might be. What is the panic you are seeing? I can't see the panic as it repeatedly scrolls across the console screen faster than I can read it. In this case the mfsroot is around 275MB. I have noticed that sometimes I can build an mfsroot that does not crash of this size. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< People usually oppose things because they are ignorant of them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 7.3p1 repeatable crash when running on ramdisk
I work with a small number of FreeBSD 7.3p1 amd64 systems which are running off of an MFS root partition loaded via a DVD, and there have been a couple of problems with the mfsroot. I'd like to focus on one in particular and see if the assembled minds here have any insight as to what this might be. Basically if I do this: # yes >/crashme the system doesn't panic, there's no warning (except for some random 'k' characters being output to the console) and the machine simply resets. I have some configuration details on the following URL: http://www.jetcafe.org/dave/freebsd/dvdconfig.html for perusal. The df for said machine looks like so: Filesystem SizeUsed Avail Capacity Mounted on /dev/md0c 270M231M 39M85%/ devfs 1.0K1.0K 0B 100%/dev /dev/acd0 606M606M 0B 100%/cd0 /dev/md1.uzip 254M225M 29M89%/usr /dev/md231M 30K 30M 0%/usr_rw :/usr_rw284M254M 30M89%/usr /dev/da1s1d653G1.0G600G 0%/rw procfs 4.0K4.0K 0B 100%/proc I would expect that a system running off of MFS would inform one via log files or console messages when I fill up the root partition. I'd say it's definately a bug but I'm not sure if it's mine or not. :) Thanks in advance for any answers you all can provide. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< A poor man shames us all. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Panic: attempted pmap_enter on 2MB page
What does the above mentioned panic mean? I'm booting from an mfsroot off of a DVD with a loader.conf like this: autoboot_delay="5" mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/mfsboot" vfs.root.mountfrom="ufs:md0" vfs.root.mountfrom.options="rw" kern.ipc.nmbclusters=32768 net.inet.tcp.tcbhashsize=16384 vm.pmap.pg_ps_enabled=1 vm.kmem_size="2G" accf_http_load="YES" net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 This is FreeBSD 8.1-RELEASE amd64 running with the debugger installed into the kernel. Thanks in advance for any insight provided. :) -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< No one is lazy except in the pursuit of another one's goal. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic: attempted pmap_enter on 2MB page
Alan Cox writes: > I'm afraid that I can't offer much insight without a stack trace. At > initialization time, we map the kernel with 2MB pages. I suspect that > something within the kernel is later trying to change one those mappings. > If I had to guess, it's related to the mfs root. Here is the stack trace. The machine is sitting here in KDB if you need me to extract any information from it. I db> bt Tracing pid 0 tid 0 td 0x80c67140 kdb_enter() at kdbenter+0x3d panic() at panic+0x17b pmap_enter() at pmap_enter+0x641 kmem_malloc() at kmem_malloc+0x1b5 uma_large_malloc() at uma_large_malloc+0x4a malloc() at malloc+0xd7 acpi_alloc_wakeup_handler() at acpi_alloc_wakeup_handler+0x82 mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< Only one who is seeking certainty can be uncertain. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic: attempted pmap_enter on 2MB page
Alan Cox writes: > There are two pieces of information that might be helpful: the value of > the global variable "kernel_vm_end" and the virtual address that was > passed to pmap_enter(). I'm afraid I don't have enough experience with this debugger to get these values with offhand commands. I could trial and error my way through figuring it out, but I'd rather get the data you expect. :) If you could give me the commands to do this, I'd be happy to type them in and get a response to you. > Is this problem reproducible? I don't recall if you mentioned that > earlier. Sort of. It seems that everytime I generate a bootable FreeBSD ISO, a die is rolled. If it comes up a certain number then it crashes, otherwise it's fine. ;) My ISO generation process might be relevant; I create a 600MB ramdisk (it used to be 512 on FreeBSD 7.3) which loads from the ISO on boot. This winds up being the root partition. As a datapoint the same die roll happens on FreeBSD 7.3 although the chance of working seems to be greater. If you'd like a copy of the ISO to see this for yourself I can make it available. I'm guessing it will also crash for you in this way modulo hardware issues. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< The treasure house within you contains everything, and you are free to use it. You don't need to seek outside. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic: attempted pmap_enter on 2MB page
Alan Cox writes: > When you build your kernel for this ISO are you increasing the value of > NKPT? No. I was under the impression that this value auto-tunes on amd64, is that correct? -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>> The opinions expressed above are entirely my own <<< >From your first day at school you are cut off from life to make theories. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
AHCI Patsburg SATA controller and slow transfer speed
Greetings all. I'm on FreeBSD 9.1-STABLE #0 r251391M. I'm noticing two of my SATA disks are at half speed. Is this normal or is there some configuration I'm forgetting? # dmesg | grep -C 4 ahc ... ahci0: port 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f mem 0xd0b0-0xd0b007ff irq 21 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ... ada0: ATA-8 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ^ ada2: Command Queueing enabled ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ^^^ ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad10 # pciconf -lcvb ahci0@pci0:0:31:2: class=0x010601 card=0x35ae8086 chip=0x1d028086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Patsburg 6-Port SATA AHCI Controller' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0x2070, size 8, enabled bar [14] = type I/O Port, range 32, base 0x2060, size 4, enabled bar [18] = type I/O Port, range 32, base 0x2050, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x2040, size 4, enabled bar [20] = type I/O Port, range 32, base 0x2020, size 32, enabled bar [24] = type Memory, range 32, base 0xd0b0, size 2048, enabled cap 05[80] = MSI supports 1 message enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 13[b0] = PCI Advanced Features: FLR TP Thanks for any insight provided. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< "The ultimate aim of dancing is to be able to move *without* thinking. To *be* danced." -John Blacking ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: AHCI Patsburg SATA controller and slow transfer speed
On 06/27/13 18:38, Jeremy Chadwick wrote: Next, this statement by ahci(4) then confuses the user: ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported Yes, this confuses even a seasoned user. ;) TL;DR -- Your motherboard offers 6 ports, 2 of which are SATA600, 4 of which are SATA300, and despite the line shown above by FreeBSD not matching reality, everything is working as designed. It wasn't too long, I *did* read both messages, and thank you both very much for the insight. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Nobody wants constructive criticism. It's all we can do to put up with constructive praise. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
9-STABLE, clang, and virtualbox
I've been trying to get emulators/virtualbox-ose-kmod to compile from ports on a clang built 9-STABLE: # uname -v FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 r...@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix After some work I can get it to compile, but then I get this: # kldload /boot/modules/vboxdrv.ko kldload: can't load /boot/modules/vboxdrv.ko: Exec format error # dmesg | tail -2 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type # kldxref -d /boot/modules/vboxdrv.ko ... /boot/modules/vboxdrv.ko depends on kernel.901505 (901505,99) module vboxdrv interface vboxdrv.1 # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel depends on kernel.901504 (901504,99) module ppi_ppbus depends on ppbus.1 (1,1) /boot/kernel/kernel depends on kernel.901504 (901504,99) module xpt depends on cam.1 (1,1) What's going on here and how can I debug this one? It seems that the module vboxdrv.ko has the correct versions. Thanks in advance for any assistance anyone can provide. :) -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Imagination is not a talent of some men, but it is the health of every man. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9-STABLE, clang, and virtualbox
On 08/26/13 13:16, Glen Barber wrote: On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: I've been trying to get emulators/virtualbox-ose-kmod to compile from ports on a clang built 9-STABLE: # uname -v FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 r...@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix After some work I can get it to compile, but then I get this: # kldload /boot/modules/vboxdrv.ko kldload: can't load /boot/modules/vboxdrv.ko: Exec format error # dmesg | tail -2 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type # kldxref -d /boot/modules/vboxdrv.ko ... /boot/modules/vboxdrv.ko depends on kernel.901505 (901505,99) module vboxdrv interface vboxdrv.1 # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel depends on kernel.901504 (901504,99) module ppi_ppbus depends on ppbus.1 (1,1) /boot/kernel/kernel depends on kernel.901504 (901504,99) module xpt depends on cam.1 (1,1) What's going on here and how can I debug this one? It seems that the module vboxdrv.ko has the correct versions. Thanks in advance for any assistance anyone can provide. :) What is the svn revision of your /usr/src/ checkout? 251391. See the uname above. :) -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< A question about the sky -- The answer about a rope. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9-STABLE, clang, and virtualbox
On 08/26/13 14:21, Glen Barber wrote: On Mon, Aug 26, 2013 at 02:16:39PM -0700, Dave Hayes wrote: On 08/26/13 13:16, Glen Barber wrote: On Mon, Aug 26, 2013 at 01:01:06PM -0700, Dave Hayes wrote: I've been trying to get emulators/virtualbox-ose-kmod to compile >from ports on a clang built 9-STABLE: # uname -v FreeBSD 9.1-STABLE #0 r251391M: Tue Jun 4 09:47:42 PDT 2013 r...@fb9build.jetcafe.org:/usr/obj/usr/src.amd64/sys/GENERIC amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd9.1 Thread model: posix After some work I can get it to compile, but then I get this: # kldload /boot/modules/vboxdrv.ko kldload: can't load /boot/modules/vboxdrv.ko: Exec format error # dmesg | tail -2 KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type # kldxref -d /boot/modules/vboxdrv.ko ... /boot/modules/vboxdrv.ko depends on kernel.901505 (901505,99) module vboxdrv interface vboxdrv.1 # kldxref -d /boot/kernel | grep -C 3 /boot/kernel/kernel depends on kernel.901504 (901504,99) module ppi_ppbus depends on ppbus.1 (1,1) /boot/kernel/kernel depends on kernel.901504 (901504,99) module xpt depends on cam.1 (1,1) What's going on here and how can I debug this one? It seems that the module vboxdrv.ko has the correct versions. Thanks in advance for any assistance anyone can provide. :) What is the svn revision of your /usr/src/ checkout? 251391. See the uname above. :) That does not mean your current checkout matches that revision. In my case it doesI checked with svn info before I sent the mail. -- Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Only one who is seeking certainty can be uncertain. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Pf, rtable, and rdr...bug?
Hello everyone. I'm having a problem with using rdr in an existing pf that uses
rtable. I'm running 10.1-STABLE #0 r282154 and I believe this is a bug, but it
could also be something I haven't spotted.
I have a firewall with three interfaces. The ip addresses have been changed to
protect the innocent. :)
- a slow net (1.2.3.0/24) interface: em0 @ 1.2.3.10
- a fast net (4.5.6.0/24) interface: em1 @ 4.5.6.10
- an internal net (192.168.4.0/24) interface: em2 @ 192.168.4.10
I route the internal net traffic over the fast cable net, and allow the
internet net to access machines on the slower work net. Both default routes for
the slow and fast net are .1 addresses (e.g. 1.2.3.1 and 4.5.6.1). I use an
alias on both the slow and fast net (.42) to route the traffic from so I can
see what's going on. I have net.fibs="2" in loader.conf and two different
default routes set up for each fib. The default "default route" (fib 0) is
1.2.3.1.
Here's my pf ruleset that works, paraphrased.
$slow_net = "1.2.3.0/24"
$slow_if = "em0"
$slow_nat_ip = "1.2.3.42"
$fast_net = "4.5.6.0/24"
$fast_if = "em1"
$fast_nat_ip = "4.5.6.42"
$int_net = "192.168.4.0/24"
$int_if = "em2"
$int_ip = "192.168.4.10" # I don't alias this side
table const { 10/8, 172.16/12, 192.168/16 }
nat log in $fast_if inet from $int_if:network to ! $slow_net -> $fast_nat_ip
nat log on $slow_if inet from $int_if:network to $slow_net -> $slow_nat_ip
block in log all
antispoof log quick for { $slow_if $fast_if $int_if }
pass in log quick on $int_if inet from $int_net to !$slow_if:network
modulate state rtable 1
pass in log quick on $int_if inet from $int_net to $slow_if:network
modulate state rtable 0
pass log on $slow_if inet from ! to any modulate state
pass out log inet from any to any modulate state
So I tried to use rdr to forward some ports from the to a machine on the
internal net:
$webserver = "192.168.4.22"
rdr on $fast_if inet proto tcp from any to port 80 -> $webserver
This doesn't work. When I turn on tcpdump on all three interfaces, I see the
packets coming in from the fast net to the internal net. The responses are
appearing on the slow net, with the IP addresses of the fast net. So if I see
this from em1:
14:34:11.887357 IP 10.11.12.13:18600 > 4.5.6.42:80 ...
I then see the response...but on em0:
14:34:12.087283 IP 4.5.6.42:80 > 10.11.12.13:18600 ...
Why doesn't this response packet go out the proper interface?
Thanks in advance for any insight. If I don't hear from anyone, I'm going to
assume this is a bug and file a bug report.
--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
>>>> *The opinions expressed above are entirely my own* <<<<
A path and a gateway have no meaning or use once the
objective is in sight.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
SCB - timed out on FreeBSD 4.10-p2
[Reposted, no answer from the SCSI list] I'm wondering if this has been seen before exactly? I'm seeing the following on a FreeBSD server: /kernel: (da1:ahd1:0:0:0): SCB 0x12 - timed out /kernel: (da1:ahd1:0:0:0): Other SCB Timeout /kernel: ahd1: Recovery Initiated - Card was not paused Googling around a bit gave me a weak theory that the seagate firmware might be defective, but that diagnosis is several months old. Can anyone shed some light on this? I can provide more data on request. The server has the following relevant devices on it: /kernel: The Regents of the University of California. All rights reserved. /kernel: FreeBSD 4.10-RELEASE-p2 #0: Fri Jul 30 02:50:53 PDT 2004 /kernel: [EMAIL PROTECTED]:/usr/src/sys/compile/DTE /kernel: Timecounter "i8254" frequency 1193182 Hz /kernel: CPU: Intel(R) Xeon(TM) CPU 2.60GHz (2599.72-MHz 686-class CPU) /kernel: Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 /kernel: Features=0xbfebfbff /kernel: Hyperthreading: 2 logical CPUs /kernel: real memory = 1073217536 (1048064K bytes) /kernel: avail memory = 1022291968 (998332K bytes) ... /kernel: ahd0: port 0x4000-0x40ff,0x4400-0x44ff mem 0xfc40-0xfc401fff irq 11 at device 2.0 on pci6 /kernel: aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs /kernel: ahd1: port 0x4800-0x48ff,0x4c00-0x4cff mem 0xfc402000-0xfc403fff irq 11 at device 2.1 on pci6 /kernel: aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs ... /kernel: da0 at ahd0 bus 0 target 0 lun 0 /kernel: da0: Fixed Direct Access SCSI-3 device /kernel: da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled /kernel: da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) /kernel: da1 at ahd1 bus 0 target 0 lun 0 /kernel: da1: Fixed Direct Access SCSI-3 device /kernel: da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled /kernel: da1: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) The motherboard specs can be found at: http://www.supermicro.com/products/motherboard/Xeon/E7500/P4DP8-G2.cfm Thanks in advance. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< Man is most nearly himself when he achieves the seriousness of a child at play. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: status of ATA subsystem
otterr <[EMAIL PROTECTED]> writes: > If stability is an issue, maybe you should look into RELENG_4_5 for only > fixes since -RELEASE. This is true. However, stability is an issue AND I also want the newer things in -STABLE, like sendmail 8.12 (ducks), and even Soren's ATA based cdrecord so I can finally burn CDs on my arbitrary CDRW drive here. So I believe the properly phrased questions are a) "What is the stability status of the current changes to the ATA subsystem in -STABLE?". and b) "We'd like to know the first date (past today) that someone sups -STABLE who runs ATA devices, and sees no problems." and c) "We'd like to know the last date (past today) that someone sups -STABLE who runs ATA devices, and sees problems." If I've been too specific, I'm sure someone will hit me with a cluebat. =) -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< By definition, when you are investigating the unknown, you do not know what you will find or even when you have found it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: status of ATA subsystem
Craig Boston <[EMAIL PROTECTED]> writes: > You want stability *AND* bleeding edge features? How about a potion of > immortaility while we're at it? (only joking, of course) Heh. The struggle for perfection rarely implies that absolute perfection will be achieved. This does not mean I will refrain from struggling. ;) > I'd say to be absolutely sure, pick a machine that's generally > reperensative of the hardware you have (but not too terribly > important), do a buildworld and buildkernel, installkernel, reboot > and see if it works. An excellent suggestion, which I will plan on taking. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< Angels can fly because they take themselves lightly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Heads up, a bit: ephemeral port range changes
Forgive me if I don't understand something. I presume you are changing the default values of net.inet.ip.portrange.first and net.inet.ip.portrange.last? If this is true, and it follows that you can change these back to their previous values, what is the fuss about? -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< The practice of study only too often makes people mere repeaters and producers of cliches and sayings. Such study has been all but wasted. The product has taken the form in which we find it because it is an unsuitable graft upon an unprepared basis. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
Terry Lambert (who fits my arbitrary definition of a "good" cynic) writes: > It's a hazard of Open Source projects, in general, that there are > so many people hacking on whatever they think is cool that nothing > ever really gets built to a long term design plan that's stable > enough that a book stands a chance of having a 1 year lifetime. I could not help but notice your multiple attempts at expresing this particular concept often, that is...an implied necessity of a book that explains what's going on under the kernel hood. I agree that such a book would rapidly be out of date, but I also see the necessity thereof. So, it's time to question the assumption that the information you want available should be in "a book". Many websites have "annotation" as a form of ad-hoc documentation (e.g. php.net). Why not have someone take a crack at documenting the FreeBSD kernel, and perhaps use some annotation feature to create a "living" document which (hopefully) comes close to describing the kernel architechture? If you want to track a moving target, perhaps you need to use a moving track? -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< "What's so special about the Net? People -still- don't listen..." -The Unknown Drummer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
Brooks Davis <[EMAIL PROTECTED]> writes: > DO NOT EVEN CONSIDER STARTING THIS THREAD!!! It's been hashed Double gah. Forget I said anything. ;) > However, just ranting about this problem[0] won't accomplish anything > other then wasting a lot of time and energy, IMO. There's plenty of > historic evidence to support this view in the archives. If you want > change you'll have to try another one. These kinds of threads are indicative of a meta-problem. The loop goes like this: 1) Someone new brings up a "flame...er hashed over" problem again, usually because it really is a problem. 2) People jump on the person (inadvertently hard perhaps) who brings it up. 3) The person goes to the archives to find this discussion and can't do it due to the inadequecies of the mailing list search and browse features 4) Said person goes away frustrated 5) Go to 1 Meanwhile the original problem never gets solved nor even (useful) mindshare thrown at it. Am I flaming about this? No. Do I want some way to solve these (and other) problems without irritating everyone who's already fla...er discussed this before? YES, and there needs to be a faster way to get up to speed with these legacy discussions. A couple examples off the top of my head of these kinds of discussions are: * naming of -stable * why Xfree86 v4 wasn't in FreeBSD (until now) All this dovetails with something I expressed earlier, with regards to annotating documentation. Somehow, this community needs to be able to process a certan class of ideas in a format other than linear mailing lists. Perhaps some sort of meta-document is needed which describes how things currently work, and some sort of attachable discussion needs to go with ideas in that document. Perhaps this is the handbook? I don't have a completely clear picture yet. Maybe some of you can help me get one? =) -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< A sample is a sample. Yet nobody would buy my house when I showed them a brick from it. - Mulla Nasrudin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ATA tags bug fix committed to -releng4
Gavin Atkinson <[EMAIL PROTECTED]> writes: > If you mean the READ_BIG timeouts I and others were having with my > DVD drive, then no, this patch has not fixed them. The DVD-ROM works > fine in both UDMA and WDMA under both linux and windows. I currently run a number of FreeBSD 4.5-p4 machines directly off of CDROM. That means I can guarantee they are all running the exact same code, no slight divergences of kernel configuration or anything like that. There are a few of these machines that I've seen the READ_BIG errors on. They happen occasionally but fairly consistantly when you run the OS off of CDROM. Here are some dmesg snippets from machines that have the problem: Machine A: acd0: DVD-ROM at ata0-master using PIO4 acd0: READ_BIG - ILLEGAL REQUEST asc=64 ascq=00 error=01 Machine B: acd0: CDROM at ata1-master using PIO4 acd0: READ_BIG command timeout - resetting (...we then change the CD drive on the -same- machine...) acd0: CDROM at ata1-master using PIO4 acd0: READ_BIG command timeout - resetting Machine C: acd0: CD-RW at ata1-master using PIO4 acd0: READ_BIG - ILLEGAL REQUEST asc=64 ascq=00 error=00 Here are some from machines that do not have the problem: Machine 1: acd0: CDROM at ata1-master using PIO4 Machine 2: acd0: CDROM at ata0-master using PIO4 It's very important to note that these are all -older- CDROM/DVD-ROM devices, as in 2-3 years older. I hope this data helps. The problem has existed since before the ata MFC (unless 4.5-p4 somehow got the MFC). I have a theory on why we see so many problems, culled mostly from other experts telling me random things here and there. The caveat on this is that I am not working on device drivers every day, nor do I know much about low level hardware details. With the following, I've merely observed the data given to me and drafted a theory to support the data. If I'm wrong, tell me...and I'd really love to know why I'm wrong if I am. Also, apologies if this has been touched upon before...you never know when a discussion is "verboten" on this list. ;) We all are painfully aware of how these different ATAPI drives work just fine with linux and windows, while on FreeBSD it's touch and go. Some people never see any problems, others of us have yet to have burncd or cdrecord (or whatever) work a CD-RW drive properly enough to burn CDs. A while ago, someone knowledgable (might have even been Soren) told me that both linux and windows use some sort of SCSI emulation layer between their operating system and ATAPI devices. According to Soren, FreeBSD uses a direct ATAPI subsystem, it doesn't go through this layer (most probably for speed). So I contend that the vendor support for the emulation is a lot less sloppy than the support for direct ATAPI. Thus, it's a LOT more work to keep up a direct ATAPI driver suite, especially since there seems to be some hardware dependance involved. (Anyone noticed how little free time Soren has?) My question would be: why don't we have an interface to the more robust SCSI emulation layer of these devices? I recognize there is loss of speed to be endured, but the upside is that we could use a lot more drives on FreeBSD. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< Half of being smart is knowing what you're dumb at. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: strange ATA behavior with -STABLE
Eric Olsen <[EMAIL PROTECTED]> writes: > acd0: CDROM at ata1-slave PIO4 ... >> sysctl -a | egrep "\.ata" > hw.ata.atapi_dma: 1 Hmm, isn't that sysctl supposed to put the CDROM in DMA mode? -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< There is no distinctly native American criminal class except Congress. -- Mark Twain To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Panic: vm_page_insert: already inserted
I've recently experienced this crash on 4.6.2-RELEASE. Relevant
information is appended to this email message. My question is: should
I submit a PR or try to troubleshoot my hardware?
--
Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED]
>>> The opinions expressed above are entirely my own <<<
Nasrudin was carrying home a piece of liver and the recipe for liver
pie. Suddenly a bird of prey swooped down and snatched the piece of
meat from his hand. As the bird flew off, Nasrudin called after it,
"Foolish bird! You have the liver, but what can you do with it without
the recipe?"
# gdb -k kernel.debug vmcore.0
GNU gdb 4.18 (FreeBSD)
...
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD at phsyical address 0x004fa000
initial pcb at physical address 0x00439120
panicstr: vm_page_insert: already inserted
panic messages:
---
panic: vm_page_insert: already inserted
...
#0 dumpsys () at ../../kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc01ebdd7 in boot (howto=256) at ../../kern/kern_shutdown.c:316
#2 0xc01ec215 in panic (fmt=0xc03b9ac0 "vm_page_insert: already inserted")
at ../../kern/kern_shutdown.c:595
#3 0xc030494d in vm_page_insert (m=0xc0b33e24, object=0xdebc9180, pindex=0)
at ../../vm/vm_page.c:374
#4 0xc0304e1c in vm_page_alloc (object=0xdebc9180, pindex=0, page_req=2) at
../../vm/vm_page.c:844
#5 0xc021324a in allocbuf (bp=0xd1b0ba74, size=1024) at
../../kern/vfs_bio.c:2511
#6 0xc0212e2a in getblk (vp=0xdeae9800, blkno=0, size=1024, slpflag=0,
slptimeo=0)
at ../../kern/vfs_bio.c:2286
#7 0xc0210d8e in bread (vp=0xdeae9800, blkno=0, size=1024, cred=0x0,
bpp=0xdf505e38)
at ../../kern/vfs_bio.c:508
#8 0xc02f1da0 in ffs_read (ap=0xdf505e9c) at ../../ufs/ufs/ufs_readwrite.c:273
#9 0xc02f8d06 in ufs_readdir (ap=0xdf505eec) at vnode_if.h:334
#10 0xc02f96e9 in ufs_vnoperate (ap=0xdf505eec) at
../../ufs/ufs/ufs_vnops.c:2422
#11 0xc021ed1b in getdirentries (p=0xdecf3c20, uap=0xdf505f80) at
vnode_if.h:769
#12 0xc0358739 in syscall2 (frame={tf_fs = -1070333905, tf_es = 47, tf_ds =
47, tf_edi = 134553824,
tf_esi = 134581888, tf_ebp = -1077937636, tf_isp = -548380716, tf_ebx =
672081412,
tf_edx = 134581888, tf_ecx = 134553824, tf_eax = 196, tf_trapno = 7,
tf_err = 2,
tf_eip = 671765424, tf_cs = 31, tf_eflags = 582, tf_esp = -1077937680,
tf_ss = 47})
at ../../i386/i386/trap.c:1167
#13 0xc03494e5 in Xint0x80_syscall ()
#14 0x280a1b36 in ?? ()
#15 0x280a1386 in ?? ()
#16 0x80496ce in ?? ()
#17 0x804b5d8 in ?? ()
#18 0x8049397 in ?? ()
(kgdb) up 3
#3 0xc030494d in vm_page_insert (m=0xc0b33e24, object=0xdebc9180, pindex=0)
at ../../vm/vm_page.c:374
374 panic("vm_page_insert: already inserted");
(kgdb) print m
$1 = 0x0
(kgdb) up
#4 0xc0304e1c in vm_page_alloc (object=0xdebc9180, pindex=0, page_req=2) at
../../vm/vm_page.c:844
844 vm_page_insert(m, object, pindex);
(kgdb) print m
$2 = 0xc0b33e24
(kgdb) print *m
$3 = {pageq = {tqe_next = 0xc0c96ba4, tqe_prev = 0xc0458310}, hnext = 0x0,
listq = {
tqe_next = 0xc0ea20ec, tqe_prev = 0xdee4a8b8}, object = 0xdee4a8a0, pindex
= 102,
phys_addr = 149848064, md = {pv_list_count = 0, pv_list = {tqh_first = 0x0,
tqh_last = 0xc0b33e48}},
queue = 0, flags = 1, pc = 8, wire_count = 0, hold_count = 0, act_count = 0
'\000', busy = 0 '\000',
valid = 0 '\000', dirty = 0 '\000'}
# uname -a
FreeBSD cdbuilder 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Sat Aug 17 18:02:09
PDT 2002 unixwiz@cdbuilder:/usr/src/sys/compile/ARCHIVE i386
# dmesg
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.6.2-RELEASE #0: Sat Aug 17 18:27:38 PDT 2002
unixwiz@cdbuilder:/usr/src/sys/compile/DTE
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (797.42-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x686 Stepping = 6
Features=0x383f9ff
real memory = 535560192 (523008K bytes)
avail memory = 515907584 (503816K bytes)
Preloaded elf kernel "kernel" at 0xc04db000.
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 10 entries at 0xc00f30f0
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
pci0: on pcib0
pci0: at 1.0 irq 11
pcib1: at device 30.0 on pci0
pci1: on pcib1
fxp0: port 0xde80-0xdebf mem
0xff70-0xff7f,0xff8fd000-0xff8fdfff irq 3 at device 1.0 on pci1
fxp0: Ethernet address 00:d0:b7:e2:f4:45
inphy0: on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci1: (vendor=0x1274, dev=0x1371) at 7.0 irq 9
ahc0: port 0xd400-0xd4ff mem
0xff8fe000-0xff8fefff irq 10 at device 9.0 on pci1
aic7890/91: Ultra2 Wide Channe
Re: ATA errors
local freebsd stable writes: > Try "FreeBSD ATA READ_BIG" in groups.google.com, you will see over > 500 hits. ...and not one actual ubiquitous solution. ;) For those curious about official status, the bug has been placed in the PR system as "kern/44197". I'll save interested readers the work, you can look at it here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/44197 Note that it's still open. I suspect this means there isn't a fix. -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] >>> The opinions expressed above are entirely my own <<< There is a great deal of talk about loyalty from the bottom to the top. Loyalty from the top down is even more necessary and much less prevalent. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
