request:help reqd in using bus_dma functions
hello group ,
I am writing a network driver where in have created tags and maps for
tx_desc of transmit-q-size by using these functions .
1. bus_dma_tag_create
2. bus_dmamap_create
3.bus_dmamem_alloc
struct _tx_desc {
DWORD data_buff;
DWORD cvbcnxt;
DWORD channel_no;
DWORD pend_desc;
};
For a packet to be transmitted a packet's address should be placed in
tx_desc_q 's DWORD data_buff field and update the rest of the fields .Then
h/w detects the presence of the packet and tranmits the packet
now to test I want to load a buffer like (char buff[50])in tx_q space can
any one tell me in which order I can use bus_dma functions .I have gone th'
docs but not very sure as I'm writing n/w drivers for the first time .I'm
not clear with the dma concepts . I'm getting confused kindly help
Now should I use bus_dmamap_load(bus_dma_tag_t dmat, bus_dmamap_t map, void
*buf, bus_size_t buflen, bus_dmamap_callback_t *callback,void *callback_arg,
int flags);
I'm not getting what callback func should to how to get the mapped address
and place into tx_desc_q 's
Thanks and regards,
Member
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yar, First let me say that you've obviously put a lot of work into this, and you have some very interesting ideas here that are worthy of further discussion. Please don't let any of my comments here be understood as criticism, or an attempt to discourage you. Second, I'd like to point out that it's generally a bad idea to cross post to more than one list. I've set a reply-to for hackers@, if you'd rather have the discussion on current@ that's fine too, but please pick one. Finally, please be aware that in src/MAINTAINERS I have requested pre-commit approval on changes to mergemaster. I hope that you'll respect that. I have some more specific comments below. Yar Tikhiy wrote: | Folks, | | I've got tired of dumb default choices mergemaster(8) offers and modified | it to be a bit smarter. While I can appreciate your frustration, the way you've phrased this departs from the project's tradition of respect for fellow developers and their work. A better way for you to deal with your frustration here would have been to send me, or alternatively, one of the mailing lists, a post which stated your frustrations and asked for an explanation of the reasons for the defaults. I am sure that you meant no actual insult here, so I'll not say anything more about this topic. | Upgrading /etc often, as when following CURRENT, is much less pain to me | now. One of the design decisions that you need to be aware of for this project since day one was to try and balance intelligent behavior and configuration options that would be useful for the very small percentage of the FreeBSD user community that constitutes our developers, versus the needs of the vast majority of "regular" users who need to be able to use the tool without becoming experts in either our build system, or the tool itself. That is why every single default for mergemaster is to do nothing. It was a purposeful decision to require the user to examine change requests, and make an affirmative choice to approve them. I find your idea of an "expert" mode for mm to be an interesting one, and I think that enough time has gone by so that it will be "safe" to add this. However I'd like to add a big, hairy warning message that says that users who enable this option do so at their own risk, etc. I need to think more about this. | The fruitiest features are as follows: | | - mergemaster no longer teases you with pauses in -v mode. Use -N (novice | mode) if you still want the pauses. I'm inclined to alter this to hide the pauses behind an expert mode flag, but I need to study your patch more before I give a more firm opinion on this. Do you have another strong reason for adding this mode? | - "Stale" rc.d files can be rm'ed or kept on individual basis. I think this is a good compromise for those who insist on "polluting" /etc/rc.d with non-system stuff. :) If you're so inclined, could you add a knob to specify a list of files to exclude from consideration? If not, I'll take a look at it. It should also be noted that I have a plan (and a POC) that will allow us to migrate to full rcorder treatment for both /etc/rc.d/ and /usr/local/etc/rc.d/ scripts, but I'm waiting for 6.0-RELEASE to get out the door before starting that bikeshed. | - There is expert mode, -E. In this mode, | mergemaster offers more dangerous defaults, mostly [install] or [delete] | depending on the question. So you can just keep hitting Enter most of | the time if your /etc is just slightly modified. In addition, you get | the 's' choice when in a subdirectory: auto-install all files from this | subdirectory -- much useful to deal with sweeping changes to rc.d or | periodic. Hrrrm ... this is partially in violation of one of my other design goals, which is to have admins actually SEE the changes to the things that they're installing, but this is also one of the least popular aspects of the thing, so I'm inclined to lean into the wind on this one. I would like to consider /etc/defaults/ exempt from this treatment however. I still feel strongly that admins should see what is being changed there since those changes are much more likely to introduce a problem than any other directory. | Feedback is welcome. And please please don't skip making a backup of | your /etc before running mergemaster! I can't be responsible for its | loss due to bugs in my code or whatever. While on the one hand I certainly appreciate and agree with this sentiment, not introducing changes that violate POLA, or are very dangerous to unsophisticated users, is one of the reason I request pre-commit approval. Thanks again for your work on this, Doug - -- ~This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDPN41yIakK9Wy8PsRAoA4AKC2X04Xnok/nj+nIdEpN7r8Z2/b/wCgtoQE Wov5z1ozZ9tLGFY+VwTTMdQ= =JMsn -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailin
Re: journaling fs and large mailbox format
In <[EMAIL PROTECTED]>, Alin-Adrian Anton <[EMAIL PROTECTED]> typed: > I run out of inodes with Maildir, and there were just a few hundred > accounts. Outlook ppl tend to "leave their messages on server if they > are not 7 days old" and this brings Christmas every day. How many files was that, and on how big a file system? Something seems out of kilter. > Mike Meyer wrote: > > The solution isn't to avoid Maildir/mh - the solution is to tune the > file system for the expected usage. > > Well, I dislike throwing up my problems to a superior level, and act > like it was brilliant. It was just running away from the issue, instead > of dealing with it. More exactly, storage problems are database theory. > Storing the mail is a classic database problem. Throwing this up to the > filesystem level is not an elegant way of dealing with it, because now > the filesystem must solve it, and this imposes new restrictions to the > filesystem. I hate to tell you this, but a file system *is* a database. Unix file systems tend to be pretty simple databases, but that's not true on all systems. Using the file system in lieue of a more complicated database - if it will work - is a time-honored unix technic. I keep a couple of gig of mail archived, and let the file system deal with sorting it out by date. Someone's got to solve the problems. If you can find an existing tool to do it for you, that's brilliant, whether the tool is a file system, a database, or a custom application. But there are tradeoffs to each such solution, and you're the only one who can decide if a specific solution is right for you or not. > I agree, B-trees are for database index problems, and not only, however, > just imagine what would happen if mySQL or PostgreSQL would throw away > their database indexing/locking issue up to the filesystem level? It > would be a total hoax, one would need separate filesystem tuning for > mysql, one for postresql, one for mail, one for apache, etc.. This just > brings headaches and unnecessarry restrictions to the partitioning schema. That depends on the underlying file system, and how flexible it is. Apache, mail, etc tend to work ok with a standard Unix file system. Database have more stringent requirements - including performance constraints. I remember commercial databases recommending that you hand them raw disk devices, and skip the OS file system manipulations completely. File systems have gotten a lot better since then, so they may not do that any longer. > This is why something like dbmail seems more appropiate in my opinion > (conceptually). Well, it's more appropriate for some uses. I punted on mbox format in the 80s, when I realized that I could use stock unix commands for manipulating single messages if I used mh mailboxes. This was a major win, as there weren't very good tools for manipulating single messages in an mbox. If your usage is restricted to people doing POP/IMAP, then dbmail would certainly work better. The downside is that you can't use Unix tools to manipulate messages. The upside (?) is that you can use SQL to manipulate messages, which may be a major win. I'm certainly going to check it out. Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
On 29 Sep, Doug Barton wrote: > Mike Meyer wrote: >> A 4K block won't hold your median file. But an 8K block wastes a lot of >> space. You might get a file with 0 blocks and 3 frags, assuming that UFS2 >> will do that, which doesn't seem good. If UFS2 won't do that, you get a >> lot of half-empty blocks, which likewise isn't good. The other option is >> a 4K block size, which means you get a lot of 1 block + 1 frag files. >> That seems optimal in this case. > > That's a logical analysis, but you're missing one important premise. UFS > doesn't do "more than one file per frag" until the file system gets close to > filling up, and the optimization switches from time to space. Therefore, in > your example you're actually wasting more space than you would with 8k > blocks, and as a side effect making the fs less efficient in at least 2 ways. If you know that most of the files are write-once and don't grow over time, you can tune the file system to always do space optimization. I used to do this with classic Usenet spools and it worked well. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
Alin-Adrian Anton wrote: XFS fits incredibly well with Maildir, however this I did not test practically I am curious as to what the defaults are for frag, inode, and block sizes on XFS, and whether that is one of the factors that make it work well with maildir. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
Eric Anderson wrote: Alin-Adrian Anton wrote: I don't know if the mbox format can handle this, and I know Maildir cannot handle this on UFS2 standard install, no matter of soft-updates. (because it exhaustes the free nodes) So I currently have no solution for this stuff. I'm not sure how you came to this conclusion, or what the history is, but I see no reason why UFS2 would have any adverse affects on maildir format mail system. You can set the number of inodes to be created to a higher number when using newfs on the filesystem, so if you believe that is an issue, you should be able to tweak it to your needs. mbox starts to break down on large mailboxes with many messages. 50mb may or may not be in that range, but maildir is much better for performance. I run out of inodes with Maildir, and there were just a few hundred accounts. Outlook ppl tend to "leave their messages on server if they are not 7 days old" and this brings Christmas every day. OK now i received some directions of how to tune it for Maildir, and there's also this link I received: http://www.mostlygeek.com/node/11 A quick note - run the mail area on a RAID array, preferrably a RAID0+1 (or 10 depending on who you ask). Disks are nearly always a bottleneck, so if you can keep your random read/writes fast, the whole system will feel snappy. Defenately. Also there is this: http://www.dbmail.org/ something more appropiate to my principles, however I was told it's not so stable. You might try posting this to freebsd-isp@, since many people there have much larger installations running than this, and can probably provide some good hints. Thanks for the tip. Mike Meyer wrote: > The solution isn't to avoid Maildir/mh - the solution is to tune the file system for the expected usage. Well, I dislike throwing up my problems to a superior level, and act like it was brilliant. It was just running away from the issue, instead of dealing with it. More exactly, storage problems are database theory. Storing the mail is a classic database problem. Throwing this up to the filesystem level is not an elegant way of dealing with it, because now the filesystem must solve it, and this imposes new restrictions to the filesystem. I agree, B-trees are for database index problems, and not only, however, just imagine what would happen if mySQL or PostgreSQL would throw away their database indexing/locking issue up to the filesystem level? It would be a total hoax, one would need separate filesystem tuning for mysql, one for postresql, one for mail, one for apache, etc.. This just brings headaches and unnecessarry restrictions to the partitioning schema. This is why something like dbmail seems more appropiate in my opinion (conceptually). >Neither journaling nor soft updates would solve the problem of running out of inodes. The only solution there is more inodes. XFS may be flexible enough to deal with file systems that far from the norm - but I wouldn't write a business plan based on it without checking first. XFS fits incredibly well with Maildir, however this I did not test practically (i'd need Linux for that :) ). I think having XFS and maybe ReiserFS in BSD is a must (and obviously there must be reasons for being a must, one of them being a large scale Maildir situation), however it's just my opinion. ZCB wrote: >From personal experience on a smaller system(~1000 accounts and nearly all ways less than 45MB boxes) I would suggest avoiding mboxes all together. Maildir is all ways the way to go. For cleaning stuff out automatically and ect, maildir is much nicer as well. Hm ok, thank's for the info. >Also is this vnodes or inodes? See the tuning man pages. For vnodes, there are some sysctls. Inodes. I'll try both tuning the FS and using dbmail, and see what happens. Thank you all. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A smarter mergemaster
On Friday 30 September 2005 08:15, Yar Tikhiy wrote: > Feedback is welcome. And please please don't skip making a backup of > your /etc before running mergemaster! I can't be responsible for its > loss due to bugs in my code or whatever. This work does look neat, but.. Try etcmerge :) It's a bit of a pain to get started with it, but it is a *lot* faster (human input wise) than mergemaster. It only asks you about files that you have modified rather than ones that have been changed by committers (ie does a 3 way merge). It does have problems handling DB files, but that is usually not a big problem to fix. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpiz2GDG1KuU.pgp Description: PGP signature
A smarter mergemaster
Folks, I've got tired of dumb default choices mergemaster(8) offers and modified it to be a bit smarter. Upgrading /etc often, as when following CURRENT, is much less pain to me now. The modified mergemaster is available from P4 for now since I'd like to have it tested well before it hits the src tree. The path is //depot/user/yar/hack/usr.sbin/mergemaster, also accessible via web as http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/yar/hack/usr.sbin/mergemaster Since mergemaster still is a shell script, you can just grab and run it. The manual page there has been updated as well. The fruitiest features are as follows: - mergemaster no longer teases you with pauses in -v mode. Use -N (novice mode) if you still want the pauses. - "Stale" rc.d files can be rm'ed or kept on individual basis. - There is expert mode, -E. In this mode, mergemaster offers more dangerous defaults, mostly [install] or [delete] depending on the question. So you can just keep hitting Enter most of the time if your /etc is just slightly modified. In addition, you get the 's' choice when in a subdirectory: auto-install all files from this subdirectory -- much useful to deal with sweeping changes to rc.d or periodic. Feedback is welcome. And please please don't skip making a backup of your /etc before running mergemaster! I can't be responsible for its loss due to bugs in my code or whatever. -- Yar ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
Mike Meyer wrote: This seems very reasonable. The trick is figuring out what "the median file size" is. I grabbed my mail archive, but that's unlikely to be representative of most users. You either need to guess right, or make arrangements to reformat the file system using current dasa at regular intervals. Sorry if I wasn't explicit enough. I was suggesting that the user who submitted the original message actually measure this, and then yes, a newfs'ing of the file system will be necessary. Or you could of course create a new data disk, formatted to fit your specs, then copy the data over, etc. Taking Doug's suggestion into account, and using the data I had, the correct answer would be an 8K/1K file system, possibly with "-i 2048" to double the number of inodes. I'm not convinced that increasing the number of inodes in this way would be the right way to go. The default is 4*, which is usually pretty reasonable. I imagine (although it's impossible to state conclusively without seeing the files), that the inode problem is a symptom, and that tuning the block size will fix the real problem. However, I did see an interesting possibility. What do you do if the median file size is, for example, 4.1K? You make the block size 8k. A 4K block won't hold your median file. But an 8K block wastes a lot of space. You might get a file with 0 blocks and 3 frags, assuming that UFS2 will do that, which doesn't seem good. If UFS2 won't do that, you get a lot of half-empty blocks, which likewise isn't good. The other option is a 4K block size, which means you get a lot of 1 block + 1 frag files. That seems optimal in this case. That's a logical analysis, but you're missing one important premise. UFS doesn't do "more than one file per frag" until the file system gets close to filling up, and the optimization switches from time to space. Therefore, in your example you're actually wasting more space than you would with 8k blocks, and as a side effect making the fs less efficient in at least 2 ways. hth, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
In <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]> typed: > Mike Meyer wrote: > > The solution isn't to avoid Maildir/mh - the solution is to tune the > > file system for the expected usage. FreeBSD (and Unix in general) > > gives you lots of knobs to deal with things like this. Learn to use > > them. > > > > The default block and frag size are relatively large - 2K and 16K > > appear to be the defaults on 5.x. A quick look at my mail for 2005 > > shows 32,267 messages ranging from 280 bytes to 6+ meg, with a mean > > size of less than 8K. I'd go with 4k blocks and a 512 byte frag size - > > because that will give you four times as many inodes as the default > > parameters. 8K/1K is also tempting, but you'll probably want to > > specify -i 2048 to get the same number of inodes as you get with a > > 4K/512b file system. > > In this situation, since any given file in a maildir directory is very > unlikely to grow, it seems to me to make sense that the right way to tune > the fs would be to find the median file size and make the block size large > enough to handle files of that size. That should give you the right tradeoff > between speed and efficiency. This seems very reasonable. The trick is figuring out what "the median file size" is. I grabbed my mail archive, but that's unlikely to be representative of most users. You either need to guess right, or make arrangements to reformat the file system using current dasa at regular intervals. Taking Doug's suggestion into account, and using the data I had, the correct answer would be an 8K/1K file system, possibly with "-i 2048" to double the number of inodes. However, I did see an interesting possibility. What do you do if the median file size is, for example, 4.1K? A 4K block won't hold your median file. But an 8K block wastes a lot of space. You might get a file with 0 blocks and 3 frags, assuming that UFS2 will do that, which doesn't seem good. If UFS2 won't do that, you get a lot of half-empty blocks, which likewise isn't good. The other option is a 4K block size, which means you get a lot of 1 block + 1 frag files. That seems optimal in this case. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
Mike Meyer wrote: The solution isn't to avoid Maildir/mh - the solution is to tune the file system for the expected usage. FreeBSD (and Unix in general) gives you lots of knobs to deal with things like this. Learn to use them. The default block and frag size are relatively large - 2K and 16K appear to be the defaults on 5.x. A quick look at my mail for 2005 shows 32,267 messages ranging from 280 bytes to 6+ meg, with a mean size of less than 8K. I'd go with 4k blocks and a 512 byte frag size - because that will give you four times as many inodes as the default parameters. 8K/1K is also tempting, but you'll probably want to specify -i 2048 to get the same number of inodes as you get with a 4K/512b file system. I agree generally with your thinking here, and wanted to add a little more analysis based on my experience. When I was facing a similar problem with a large authoritative name server installation, I got the advice to find the median file size, and tune the file system so that the block size was 2x the median file size (with the fragment size being 1/8th the block size of course). The reasoning behind this was that because the files I was working with could grow, it made sense to make sure that even if it grew the file could stay within one block. This is slightly wasteful of space (very slightly), but resulted in a much more efficient operation. In this situation, since any given file in a maildir directory is very unlikely to grow, it seems to me to make sense that the right way to tune the fs would be to find the median file size and make the block size large enough to handle files of that size. That should give you the right tradeoff between speed and efficiency. hth, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
On Thu, 29 Sep 2005, Rob Watt wrote:
On Thu, 29 Sep 2005, Robert Watson wrote:
Could you dump the contents of *td and *td->td_proc for me? I'm quite
interested to know what the value in td->td_proc->p_state is, among other
things. If I could also have you generate a dump of the KSE group
structures in td->td_proc->p_ksegrps and the threads in
td->td_proc->p_threads.
I've attached a file with many of the values you have asked for. We
looked at some of the threads referenced by td->td_proc->p_threads, but
we weren't sure we were walking the list correctly. Do you have any tips
for walking those thread lists?
Could you tell me if the program named by p->p_comm is linked against a
threading library? If it's a custom app, you may already know, and if
not, you can run ldd on the application to see what it is linked
against.
The programs named by p->p_comm is linked against the pthreads library.
This seems to be enough information to at least track this down a bit:
td_ksegrp is NULL, rather than a corrupt value, which suggests that the
thread is incompletely initialized. Other hints that this are the case
are that td_critnest is 1 (as is set when it is allocated), and the state
is TDS_INACTIVE. Some other fields are set though, such as td_oncpu,
which is normally initialized to NOCPU.
(kgdb) p *td
$1 = {td_proc = 0xff004aa9f000, td_ksegrp = 0x0, td_plist =
{tqe_next = 0xff 00b4798000,
tqe_prev = 0xff00a97ae010}, td_kglist = {tqe_next =
0xff00b4798000,
tqe_prev = 0xff00a97ae020}, td_slpq = {tqe_next = 0x0, tqe_prev
= 0x ff001fac7c10}, td_lockq = {
tqe_next = 0xff00a97ae000, tqe_prev = 0xb6797a70},
td_runq = {tq e_next = 0x0,
tqe_prev = 0x80608180}, td_selq = {tqh_first = 0x0, tqh_last
= 0xfff fff00633112c0},
td_sleepqueue = 0xff00382b0400, td_turnstile = 0xff00c1712900,
td_umtx q = 0xff00d1207080,
td_tid = 100253, td_flags = 16777216, td_inhibitors = 0, td_pflags =
128, td_d upfd = 0, td_wchan = 0x0,
td_wmesg = 0x0, td_lastcpu = 2 '\002', td_oncpu = 2 '\002',
td_owepreempt = 0 '\0', td_locks = 0,
td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested =
{lh_first =
0x0}, td_sleeplocks = 0x0,
td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred =
0xf f00ad18f200,
td_standin = 0x0, td_upcall = 0x0, td_sticks = 0, td_uuticks = 0,
td_usticks =
0, td_intrval = 0,
td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits =
{4294967295, 4 294967295, 4294967295,
4294967295}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_generation
= 14, td _sigstk = {ss_sp = 0x0,
ss_size = 0, ss_flags = 0}, td_kflags = 0, td_xsig = 0,
td_profil_addr = 0, td_profil_ticks = 0,
td_base_pri = 182 '\u', td_priority = 182 '\u', td_pcb =
0xb68 dcd10, td_state = TDS_INACTIVE,
td_retval = {1, 29309280}, td_slpcallout = {c_links = {sle = {sle_next
= 0x0},
tqe = {tqe_next = 0x0,
tqe_prev = 0xff001fac7d80}}, c_time = 55907602, c_arg =
0xff0063 311260,
c_func = 0x802e32a0 , c_mtx = 0x0, c_flags =
16}, td _frame = 0xb68dcc40,
td_kstack_obj = 0xff0087f93d20, td_kstack = 18446744072477315072,
td_kstac k_pages = 4,
td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0,
td_critnest = 1, td_md = {
md_spinlock_count = 1, md_saved_flags = 582}, td_sched =
0xff0063311488}
I'm not familiar with the internals of the thread and KSE life cycle here,
so I think we'll need to look to those more familiar with this to
understand what of two things may be going on:
(1) Is the fact that td_ksegrp != NULL an invariant for a connected
thread, and that kern_proc is relying on that but the thread code is
failing to implement it safely?
(2) Is td_ksegrp sometimes left legitimately as NULL as part of the thread
life cycle, and that kern_proc incorrectly assumes that it is never
NULL when hooked up to a thread.
This suggests a possible work-around of simply testing td_ksegrp for NULL
in kern_proc in order to avoid this, while attempting to resolve whether
an invariant is violated (or incorrectly assumed), which might require
some serious thinking and a solution that is non-trivial. Something like
the following might work in the mean time:
Index: kern_proc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v
retrieving revision 1.231
diff -u -r1.231 kern_proc.c
--- kern_proc.c 27 Sep 2005 18:03:15 - 1.231
+++ kern_proc.c 29 Sep 2005 20:50:33 -
@@ -882,6 +882,8 @@
} else {
_PHOLD(p);
FOREACH_THREAD_IN_PROC(p, td) {
+ if (td->td_ksegrp == NULL)
+ continue;
fill_kinfo_thread(td, &kinfo_proc);
PROC_UNLOCK(p);
error = SYSCTL_OUT(req, (caddr_t)&kinfo_pro
Re: anyone using security/dropbear?
On Thu, Sep 29, 2005 at 12:58:17PM -0700, Doug Barton wrote: > Depending on why that program needs random bits, that could be a very bad > idea. Take a look at the following page and see if it helps: > > http://people.freebsd.org/~dougb/randomness.html A handy resource, thanks. As I mentioned in some private email on this matter, my short-term goal was to just get it working, to suss out the behavior of the CLI. If I adopt this tool, I'll certainly take all of these suggestions into account. (Again, to all: thank for the feedback!) > -- > > This .signature sanitized for your protection > -- Brian Reichert <[EMAIL PROTECTED]> 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: anyone using security/dropbear?
Brian Reichert wrote: On Thu, Sep 29, 2005 at 02:14:13PM -0400, Kris Kennaway wrote: Check the source.. is it using /dev/urandom (which never blocks), or /dev/random (which I still don't think blocks, but may return short reads). Either way, it sounds like some level of application bug...it probably should be using the former source, but even if it's not, it shouldn't be blocking. ktrace shows /dev/random, and indeed, very short reads. Let me try another maunal build, pushing it to /dev/urandom. Depending on why that program needs random bits, that could be a very bad idea. Take a look at the following page and see if it helps: http://people.freebsd.org/~dougb/randomness.html -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dev_lock() question
In message <[EMAIL PROTECTED]>, John Baldwin writes: >On Thursday 29 September 2005 02:14 pm, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, John Baldwin writes: >> >Actually, you would think that it could be initialized either via an early >> >SYSINIT() or in the init_mutexes() function in kern_mutex.c and thus not >> > need the early check and avoid penalizing dev_lock(). >> > >> >phk, how early his dev_lock needed? >> >> Far too early due to console madness (in syscons I belive). > >So would mutex_init() work? Havn't tried. It basically has to work right before the copyright is printed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dev_lock() question
On Thursday 29 September 2005 02:14 pm, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Baldwin writes: > >Actually, you would think that it could be initialized either via an early > >SYSINIT() or in the init_mutexes() function in kern_mutex.c and thus not > > need the early check and avoid penalizing dev_lock(). > > > >phk, how early his dev_lock needed? > > Far too early due to console madness (in syscons I belive). So would mutex_init() work? It's called very early in the MD startup code right after things like curthread are initialized. If dev_lock() is called before mutex_init() it can't work right anyway as mtx_init() doesn't work until then. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufsstat implementation
On 2005-09-29 13:21, Eric Anderson <[EMAIL PROTECTED]> wrote: > I've been looking at the ufs code, and thinking about wedging in some > statistic gathering pieces pretty much copied from the nfs code (and > nfsstat) to provide nearly the same functionality. > > I realize that adding statistic gathering code would techinically reduce > filesystem performance, so should I put a wrapper around the code pieces > checking a sysctl, or use #ifdef's around it, or neither? It would take running an implementation with and without ufsstats to see what the impact on filesystem performance is, so it seems to me the natural choise for early stages of development is an #ifdef that can easily be turned on/off and control where all of the code goes in or nothing at all :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ufsstat implementation
I've been looking at the ufs code, and thinking about wedging in some statistic gathering pieces pretty much copied from the nfs code (and nfsstat) to provide nearly the same functionality. I realize that adding statistic gathering code would techinically reduce filesystem performance, so should I put a wrapper around the code pieces checking a sysctl, or use #ifdef's around it, or neither? Also - am I going about this the right way, or is there a better way to record these statistics? Thanks! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: anyone using security/dropbear?
On Thu, Sep 29, 2005 at 02:14:13PM -0400, Kris Kennaway wrote: > Check the source.. is it using /dev/urandom (which never blocks), or > /dev/random (which I still don't think blocks, but may return short > reads). Either way, it sounds like some level of application bug...it > probably should be using the former source, but even if it's not, it > shouldn't be blocking. ktrace shows /dev/random, and indeed, very short reads. Let me try another maunal build, pushing it to /dev/urandom. Thanks for the quick feedback... > Kris -- Brian Reichert <[EMAIL PROTECTED]> 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dev_lock() question
In message <[EMAIL PROTECTED]>, John Baldwin writes: >Actually, you would think that it could be initialized either via an early >SYSINIT() or in the init_mutexes() function in kern_mutex.c and thus not need >the early check and avoid penalizing dev_lock(). > >phk, how early his dev_lock needed? Far too early due to console madness (in syscons I belive). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: anyone using security/dropbear?
On Thu, Sep 29, 2005 at 02:10:55PM -0400, Brian Reichert wrote: > I've tried using the dropbear client (0.46), built both from source and > ports, and consistently get this message: > > dbclient: Warning: Reading the random source seems to have blocked. > If you experience problems, you probably need to find a better entropy > source. > > Googling for this diagnostic yields essentially no info, so I don't > know if there's something weird about my FBSD install (4.11-R). > > Has anyone seen this before, or have any advice on the matter? Check the source.. is it using /dev/urandom (which never blocks), or /dev/random (which I still don't think blocks, but may return short reads). Either way, it sounds like some level of application bug...it probably should be using the former source, but even if it's not, it shouldn't be blocking. Kris pgpk4tg8jdaUs.pgp Description: PGP signature
anyone using security/dropbear?
I've tried using the dropbear client (0.46), built both from source and ports, and consistently get this message: dbclient: Warning: Reading the random source seems to have blocked. If you experience problems, you probably need to find a better entropy source. Googling for this diagnostic yields essentially no info, so I don't know if there's something weird about my FBSD install (4.11-R). Has anyone seen this before, or have any advice on the matter? -- Brian Reichert <[EMAIL PROTECTED]> 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
On Wed, 28 Sep 2005, Rob Watt wrote: We re-compiled the kernel with 'options KDB_STOP_NMI', and were able to get a much more full analysis of what was happening on the 6-BETA5 crash. Great. We crashed in top again, and it does look like we may have hit a kern_proc bug. This sounds good, or at least, promising. in the attached file type3-core.txt you can see that it hits an exception in: 0x802b897a is in fill_kinfo_thread (/usr/src/sys/kern/kern_proc.c:736). 731 } 732 733 kg = td->td_ksegrp; 734 735 /* things in the KSE GROUP */ 736 kp->ki_estcpu = kg->kg_estcpu; 737 kp->ki_slptime = kg->kg_slptime; 738 kp->ki_pri.pri_user = kg->kg_user_pri; 739 kp->ki_pri.pri_class = kg->kg_pri_class; 740 (kgdb) frame 8 #8 0x802b897a in fill_kinfo_thread (td=0xff0063311260, kp=0xb62d8510) at /usr/src/sys/kern/kern_proc.c:733 733 kg = td->td_ksegrp; (kgdb) p kg->kg_estcpu Cannot access memory at address 0x173 (kgdb) p td->td_ksegrp $1 = (struct ksegrp *) 0x0 (kgdb) p kp->ki_estcpu $2 = 0 (kgdb) p kg $4 = (struct ksegrp *) 0x12b it seems that kg is an invalid pointer. Could you dump the contents of *td and *td->td_proc for me? I'm quite interested to know what the value in td->td_proc->p_state is, among other things. If I could also have you generate a dump of the KSE group structures in td->td_proc->p_ksegrps and the threads in td->td_proc->p_threads. Could you tell me if the program named by p->p_comm is linked against a threading library? If it's a custom app, you may already know, and if not, you can run ldd on the application to see what it is linked against. Depending on how much time you have available, it might make sense for me to grab from you a copy of your source tree, compiled kernel with debug symbols, and core dump. We have started our tests again without running top. Hope you have a great vacation. It was brief but very enjoyable, and quite disconnected :-). Thanks, Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dev_lock() question
On Thursday 29 September 2005 01:04 pm, Stanislav Sedov wrote:
> On Thu, Sep 29, 2005 at 06:55:38PM +0200, Divacky Roman wrote:
> > Hi,
> >
> > dev_lock() looks this way:
> >
> > void
> > dev_lock(void)
> > {
> > if (!mtx_initialized(&devmtx))
> > mtx_init(&devmtx, "cdev", NULL, MTX_DEF);
> > mtx_lock(&devmtx);
> > }
> >
> > I wonder why is the mtx_initialized checking necessary? shouldnt explicit
> > initialization be sufficient?
> >
> > thnx for answer
> >
> > roman
>
> Moving "mtx_initialized()" check into mtx_init will decrease speed of other
> mutexes initialization. We must check if it's initialized here because of
> it's not permiited to pass already initialized mutex to mtx_init().
Actually, you would think that it could be initialized either via an early
SYSINIT() or in the init_mutexes() function in kern_mutex.c and thus not need
the early check and avoid penalizing dev_lock().
phk, how early his dev_lock needed?
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dev_lock() question
On Thu, Sep 29, 2005 at 06:55:38PM +0200, Divacky Roman wrote:
> Hi,
>
> dev_lock() looks this way:
>
> void
> dev_lock(void)
> {
> if (!mtx_initialized(&devmtx))
> mtx_init(&devmtx, "cdev", NULL, MTX_DEF);
> mtx_lock(&devmtx);
> }
>
> I wonder why is the mtx_initialized checking necessary? shouldnt explicit
> initialization be sufficient?
>
> thnx for answer
>
> roman
Moving "mtx_initialized()" check into mtx_init will decrease speed of other
mutexes initialization. We must check if it's initialized here because of
it's not permiited to pass already initialized mutex to mtx_init().
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dev_lock() question
Hi,
dev_lock() looks this way:
void
dev_lock(void)
{
if (!mtx_initialized(&devmtx))
mtx_init(&devmtx, "cdev", NULL, MTX_DEF);
mtx_lock(&devmtx);
}
I wonder why is the mtx_initialized checking necessary? shouldnt explicit
initialization be sufficient?
thnx for answer
roman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
From personal experience on a smaller system(~1000 accounts and nearly all ways less than 45MB boxes) I would suggest avoiding mboxes all together. Maildir is all ways the way to go. For cleaning stuff out automatically and ect, maildir is much nicer as well. Also is this vnodes or inodes? See the tuning man pages. For vnodes, there are some sysctls. On Thu, 29 Sep 2005 04:11:29 +0300 Alin-Adrian Anton <[EMAIL PROTECTED]> wrote: > Dear Hackers, > > First of all thank you for your time and attention. > > I am in the position to implement a large-scale mail server > and I will never go for anything else but FreeBSD (fixation?). > > It should be able to handle graceously 4000 e-mail accounts > where a minimum of 50 Mb/mailbox would be a requirement. In the > begining, it is desirable that users could use as much free space > as available, so this implies some gigabytes/mailbox. > > I don't know if the mbox format can handle this, and I know > Maildir cannot handle this on UFS2 standard install, no matter of > soft-updates. (because it exhaustes the free nodes) So I currently > have no solution for this stuff. > > I was wondering what is the status of Journaling File > Systems on FreeBSD? Any which is usable and mature, with write > access? XFS would fit amazingly well with Maildir, but.. I doubt > it's anything else but readonly. > > So any suggestion would really help a lot. Thank's in > advance. > > > Yours Sincerely, > -- > Alin-Adrian Anton > GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 > 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA > > "It is dangerous to be right when the government is wrong." - > Voltaire ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: journaling fs and large mailbox format
In <[EMAIL PROTECTED]>, Alin-Adrian Anton <[EMAIL PROTECTED]> typed: > I am in the position to implement a large-scale mail server and I will > never go for anything else but FreeBSD (fixation?). How are users going to get to the mail? Web browsers? IMAP? POP? > I don't know if the mbox format can handle this, and I know Maildir > cannot handle this on UFS2 standard install, no matter of soft-updates. > (because it exhaustes the free nodes) So I currently have no solution > for this stuff. Large mailboxes in mbox format are a loss, because you have to rewrite all/most of the mailbox to make changes in it. In particular, a fetchmail process - read and delete the messages in chronological order - is an O(n**2) process. This applies to pretty much any mail format that stores all the messages in one file. The alternatives are things like mh and Mailder. Yes, those will have problems on UFS file systems that you build with the default parameters. That's because mail messages tend to be very small files - typically a few k - so a file system full of them is will have a very odd distribution of files sizes when compared to more usual file systems. The solution isn't to avoid Maildir/mh - the solution is to tune the file system for the expected usage. FreeBSD (and Unix in general) gives you lots of knobs to deal with things like this. Learn to use them. The default block and frag size are relatively large - 2K and 16K appear to be the defaults on 5.x. A quick look at my mail for 2005 shows 32,267 messages ranging from 280 bytes to 6+ meg, with a mean size of less than 8K. I'd go with 4k blocks and a 512 byte frag size - because that will give you four times as many inodes as the default parameters. 8K/1K is also tempting, but you'll probably want to specify -i 2048 to get the same number of inodes as you get with a 4K/512b file system. > I was wondering what is the status of Journaling File Systems on > FreeBSD? Any which is usable and mature, with write access? XFS would > fit amazingly well with Maildir, but.. I doubt it's anything else but > readonly. Neither journaling nor soft updates would solve the problem of running out of inodes. The only solution there is more inodes. XFS may be flexible enough to deal with file systems that far from the norm - but I wouldn't write a business plan based on it without checking first. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [BUGI] IOCTL :Facing problems while acccessing data from kernel space
On 28.09-13:40, rashmi ns wrote:
[ ... ]
> I was trying to add a new ioctl command like
> > #define HDLCMODE _IOR('6',0xF,int)
> > when i trying to uprintf the data which was sent from the user-space in
> > the device-driver-ioctl-routine i'll get a different value than which was
> > passed. Can anybody please tell me why this is happening . I pass the
> > address of an integer where data is stored from the user space as third arg
> > to the ioctl call .
i would guess that it's a simple typo and your pointer conversions
are off somewhere.
i.e.
uprintf( "%d", (int*)data ) ;
instead of
uprintf( "%d", *(int*)data ) ;
otherwise, use a debugger or post the code.
--
t
t
w
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
Robert, On Tue, 27 Sep 2005, Robert Watson wrote: > Great. As mentioned I'll be offline for about the next 48 hours, but back > after then. If we can get a nice clean crash out of this, would really be > best. If it's top panicking, it could well be due to a bug in the process > monitoring code, in kern_proc. We've run into bugs a few times there in > the past, generally associated with threading or races in process > creation/teardown, in which partially initialized (or torn down) processes > are accessed by another thread and are in an unexpected state. We re-compiled the kernel with 'options KDB_STOP_NMI', and were able to get a much more full analysis of what was happening on the 6-BETA5 crash. We crashed in top again, and it does look like we may have hit a kern_proc bug. in the attached file type3-core.txt you can see that it hits an exception in: 0x802b897a is in fill_kinfo_thread (/usr/src/sys/kern/kern_proc.c:736). 731 } 732 733 kg = td->td_ksegrp; 734 735 /* things in the KSE GROUP */ 736 kp->ki_estcpu = kg->kg_estcpu; 737 kp->ki_slptime = kg->kg_slptime; 738 kp->ki_pri.pri_user = kg->kg_user_pri; 739 kp->ki_pri.pri_class = kg->kg_pri_class; 740 (kgdb) frame 8 #8 0x802b897a in fill_kinfo_thread (td=0xff0063311260, kp=0xb62d8510) at /usr/src/sys/kern/kern_proc.c:733 733 kg = td->td_ksegrp; (kgdb) p kg->kg_estcpu Cannot access memory at address 0x173 (kgdb) p td->td_ksegrp $1 = (struct ksegrp *) 0x0 (kgdb) p kp->ki_estcpu $2 = 0 (kgdb) p kg $4 = (struct ksegrp *) 0x12b it seems that kg is an invalid pointer. We have started our tests again without running top. Hope you have a great vacation. - Rob Watt type3-core.txt Description: Binary data Copyright (c) 1992-2005 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 6.0-BETA5 #1: Tue Sep 27 17:38:32 EDT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LOCAL-DEBUG-NMI WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual Core AMD Opteron(tm) Processor 275 (2190.05-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> Hyperthreading: 2 logical CPUs real memory = 3942580224 (3759 MB) avail memory = 3807399936 (3631 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 10 on acpi0 pci_link1: irq 5 on acpi0 pci_link2: irq 11 on acpi0 pci_link3: irq 9 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 6.0 on pci0 pci3: on pcib1 ohci0: mem 0xfeafc000-0xfeafcfff irq 19 at device 0.0 on pci3 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfeafd000-0xfeafdfff irq 19 at device 0.1 on pci3 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered pci3: at device 6.0 (no driver attached) fxp0: port 0xbc00-0xbc3f mem 0xfeafb000-0xfeafbfff,0xfeaa-0xfeab irq 18 at device 8.0 on pci3 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:e0:81:31:89:1c isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pcib2: at device 10.0 on pci0 pci2: on pcib2 em0: port 0x8880-0x88bf mem 0xfc8c-0xfc8d,0xfc80-0xfc83 irq 26 at device 2.0 on pci2 em0: Ethernet address: 00:04:23:ba:d0:42 em0: Speed:N/A Duplex:N/A em1: port 0x8c00-0x8c3f mem 0xfc8e-0xfc8f,0xfc88-0xfc8b irq 27 at device 2.1 on pci2 em1: Ethernet address: 00:04:23:ba:d0:43 em1: Speed:N/A Duplex:N/A em2: port 0x8480-0x84bf mem 0xfc78-0xfc79,0xfc74-0xfc77 irq 27 at device 3.0 on pci2 em2: E
invalid geometry for >1TB
Hi hackers, tryin' to install 4.11 or 5.x on a Dell box with a Perc 3/Di Raid controller (with 5x 300GB scsis). I get 'invalid geometry' when running sysinstall/fdisk on the 'disk', the geometry presented being: 145815 cyl / 255 heads / 63 sectors I tried to press 'A' for allocate the whole disk, and after several more warnings it did that, but now the 'free' space in the list has a big minus value as 'Offset'. Is that a problem? What should I do in order to get fbsd on this box? Change geometry? Any other hacks/workarounds? Thanks, bogdan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
