Re: Results of BIND RFC
On Fri, 02 Apr 2010 08:55:07 + "Poul-Henning Kamp" mentioned: > In message <20100402013353.f544e8ad.s...@freebsd.org>, Stanislav Sedov writes: > >On Fri, 02 Apr 2010 17:26:13 +0900 > >Randy Bush mentioned: > > >Ports doesn't support cross-compilation yet, > >and it would be a pity to find yourself > >bootstrapping another tiny arm platform and > >having to use ports to have a usable system. > > The result of the RFC was that bind is not a mandatory component > to make "a usable system", so you argument suffers from bad logic. > > The fact that you want BIND on your arm, is no different from > somebody else wanting postfix on a MIPS. Sorry, I think I was not clear enough. What I actually want is to have a couple of the important tools in the base while moving everything also in ports. By important tools I mean nslookup (and maybe dig), and at least the first one is cruicial for the system bringup. That one is also nice to have on the livecd, which currently includes (I believe) only the base system. -- Stanislav Sedov ST4096-RIPE ___ 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: Results of BIND RFC
On Fri, 02 Apr 2010 17:26:13 +0900 Randy Bush mentioned: > > i don't mind if dig, doc, et alia are not in base, as long as they are a > separate port from the bind hippo. > The major benefit of having them in the base is the ability to cross-compile them when building the distribution for another platform. Ports doesn't support cross-compilation yet, and it would be a pity to find yourself bootstrapping another tiny arm platform and having to use ports to have a usable system. -- Stanislav Sedov ST4096-RIPE ___ 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: Results of BIND RFC
On Thu, 01 Apr 2010 15:16:59 -0700 Doug Barton mentioned: > > Of course this change will have some costs. Users of named who rely on > the current defaults will have some change management to deal with, > however the costs will be minimal. The one area that has come up > repeatedly in previous discussions about this topic is that users like > having access to the command line tools dig, host, and nslookup. To deal > with that issue I will be creating a bind-tools port so that those who > want just those tools can easily add them, without the overhead of the > rest of the BIND suite. If anyone has suggestions for other BIND tools > that should be included in the port, please let me know. Hey, Doug! While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? -- Stanislav Sedov ST4096-RIPE pgprZIyg771Gg.pgp Description: PGP signature
Re: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64
On Mon, 26 Oct 2009 15:49:37 +0100 "Johan Hendriks" mentioned: > I saw a commit from Bjoern A. Zeeb which describe the hang, but do not > know if this can be reverted back to 8.x before the release. > > svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb > > regards, and thank you for your time. > cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry) > I believe bz's patch should fix it for you. You can either apply it by hand, or disable ASF mode by putting the following into /boot/loader.conf: hw.bge.allow_asf=0 The latter will be off by default in 8.0, but this change was not done by the point when RC1 was branched. It should be disabled by default in RC2 though, when it will be ready. -- Stanislav Sedov ST4096-RIPE pgp8uvkKHR1n9.pgp Description: PGP signature
Re: em driver input errors
On Wed, 5 Aug 2009 00:30:20 -0700 (PDT) alexpalias-bsdsta...@yahoo.com mentioned: > dev.em.0.rx_processing_limit=300 > dev.em.1.rx_processing_limit=300 > dev.em.2.rx_processing_limit=300 > dev.em.3.rx_processing_limit=300 > This tunables only affects polling mode. Do you use polling with this adapters or just standard interrupt-based mode? <.. snip ..> > em0: Excessive collisions = 0 > em0: Sequence errors = 0 > em0: Defer count = 402 > em0: Missed Packets = 12762 > em0: Receive No Buffers = 0 > em0: Receive Length Errors = 0 > em0: Receive errors = 0 > em0: Crc errors = 0 > em0: Alignment errors = 0 > em0: Collision/Carrier extension errors = 0 > em0: RX overruns = 237 > em0: watchdog timeouts = 0 > em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 > em0: XON Rcvd = 249 > em0: XON Xmtd = 244 > em0: XOFF Rcvd = 402 > em0: XOFF Xmtd = 261 > em0: Good Packets Rcvd = 3092053709 > em0: Good Packets Xmtd = 2622962119 > em0: TSO Contexts Xmtd = 12760095 > em0: TSO Contexts Failed = 0 > >From the output it looks like that the driver is unable to process the adapter input queue fast enough so it runs out of free descriptors. One of the easiest things you can try is to enable the polling mode and see if it improves the situation. You may want also to play with rx_processing_limit tunables in that case. The em(4) driver in HEAD also includes multiqueue processing fetaure so it is possible it will improve the situation for you too. -- Stanislav Sedov ST4096-RIPE pgp3lzqSBCjBm.pgp Description: PGP signature
Re: ext2 inode size patch - RE: PR kern/124621
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 3 Dec 2008 17:53:43 -0500
"Josh Carroll" mentioned:
> > Ok, I describe my concern once more. I do not object against the checking
> > of the inode size. But, if inode size is changed, then some data is added
> > to the inode, that could (and usually does, otherwise why extend it ?)
> > change intrerpetation of the inode. Thus, we need a verification of the
> > fact that simply ignoring added fields does not damage filesystem or
> > cause user data corruption. Verification != testing.
>
> Let me take another crack at explaining why I think this patch is not
> dangerous.
>
> The inode size is determined by reading the following member:
>
> __u16 s_inode_size;
>
> of the ext2_super_block structure.
>
> I took a look at the Linux 2.6.27.7 kernel source, and indeed they do
> something very similar if not the same:
>
> #define EXT2_INODE_SIZE(s) (EXT2_SB(s)->s_inode_size)
>
> If you compare to what I did:
>
> #define EXT2_INODE_SIZE(s) ((s)->u.ext2_sb.s_inode_size)
>
> This is really the same thing, since EXT2_SB is defined (in the Linux
> kernel src as):
>
> #ifdef __KERNEL__
> #include
> static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb)
> {
> return sb->s_fs_info;
> }
>
> And struct ext2_sb_info has the following member:
>
> int s_inode_size;
>
> Essentially, the changes I made simply query the existing information
> from the filesystem, which is what the Linux kernel does as well.
>
> The inode size, blocks per group, etc are all defined at filesystem
> creation time by mke2fs and it ensures the sanity of the relationship
> between the inodes/blocks/block groups.
>
> The first diagram here:
>
> http://sunsite.nus.sg/LDP/LDP/tlk/node95.html
>
> Makes it clear that as long as the number of inodes per block and the
> blocks per group is is sane during fs creation, looking up the inode
> size as my patch does is fine, since the creation of the filesystem is
> ensures a correct by construction situation. We're simply reading the
> size of the inode based on the filesystem.
>
> I hope this is sufficient to convince some further thought about
> committing this.
>
> For those interested in the relevant Linux kernel source, you can have
> a look at line 105 of include/linux/ext2_fs.h from the linux-2.6.27.7
> kernel source.
>
Hi Josh!
I've commited the similar patch today that should be fixing your problem.
Can you check this, please?
Sorry I've missed this thread in the first place.
- --
Stanislav Sedov
ST4096-RIPE
-BEGIN PGP SIGNATURE-
iEYEARECAAYFAklzYsoACgkQK/VZk+smlYF3ZwCeOyVUdzrKOdu4Pg3ztAZ0QQaY
GGIAnA+oL054T0EAajbfwpYSTDRKVISC
=jJFT
-END PGP SIGNATURE-
!DSPAM:497362c8967002668918391!
___
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: FreeBSD 7.1 Content
On Wed, 3 Sep 2008 17:01:31 -0600 Dan Allen <[EMAIL PROTECTED]> mentioned: > Phillip Salzman wrote: > > An easy answer would be to put the web-browser and such the first > > disk, but > > I don't think it would solve anything. If it kept with those, > > FreeBSD would > > find itself just moving towards the same work being done at PC-BSD, > > wouldn't > > it? > > When I see almost 200 MB free on disc1 of 7.0, and I remember the > handy apps & pkgs which used to be on past releases of FreeBSD, I do > not see it as moving towards PC-BSD as much as I see it as going back > to what FreeBSD used to have just a few releases ago. > In truth, for workstations and laptops at least, most of us do want a > web browser. Not having a decent web browser out of the box in 2008 > after 15 years of web browser development gives BSD a really archaic > look and feel. We all know that BSD is the best, most solid OS out > there - but occasionally we need to do a bit of marketing, we need to > show our stuff to let others see that "we get it". > Dan > I don't think the the problem really is in including the web browser, or X11 or not. All of us have different preferences on which soft we want to have on the first CD. That is I won't probably want a web browser when installing the server, but php, ruby and nginx instead. I think, that the current set of packages for the first CD is reasonable enough. The real problem is that our installation program isn't flexible enough and, truly speaking, obsolete. There're several programs of preparing the new generation installation system for FreeBSD, and after it's finished we'll probably able to prepare target-oriented CD sets, e.g. one for server installs, one for workstations, etc. It should be also good enough to allow you easily install any software you want whatever way you prefer. -- Stanislav Sedov ST4096-RIPE pgpyw0ps4Sct8.pgp Description: PGP signature
Re: Is it safe to delete /bin/[ && /usr/bin/false?
On Tue, 02 Sep 2008 12:25:51 -0700 [EMAIL PROTECTED] mentioned: > > Good. Perhaps you (or anyone) can suggest how I might debug /when/where/ > these eval are called. I could use /usr/bin/script, but not sure how to > (e)grep the culprit(s). > Try to find the exact script which causes this (it'd be pretty easy if you could find a port with this error reproducible). Then you will be able to track the problem down by inserting a couple of echos/exits in the offending script and observing the result. -- Stanislav Sedov ST4096-RIPE pgp1w1hzDf9yi.pgp Description: PGP signature
Re: Xorg and ATI card query.
On Mon, 12 Mar 2007 18:40:07 + Yann Golanski <[EMAIL PROTECTED]> mentioned: > I have an ATI Radeon X1950 Sapphire and I am trying to get X/FreeBSD working > with it. My system is a clean install of FreBSD. I've managed to get > VESA to "work" but cannot get much more than that. > > fglrx gives me an error at compile time since I do not have > /usr/X11R6/bin/moc installed. > > Would an install of Xorg 7 be useful here? What else can I try? I > know I could use Linux and the ATI drivers but I'd rather use FreeBSD if > possible. > > FreeBSD nightwatch.neverness.org 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan > 12 11:05:30 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 > > Find attached the dmesg, xorg.conf and /var/log/xorg.0.log files. If anyone > wants more information let me know. > > I am happy to beta-test software to get this to work. > AFAIK, opensource Xorg ati drivers doesn't work with anything beyond x1800. flgrx is only linux binary, however, so you couldn't use it for FreeBSD. -- Stanislav Sedov ST4096-RIPE pgpUWYOFF10xP.pgp Description: PGP signature
Re: Newbie Sempron/ISO question
On Thu, 1 Feb 2007 21:16:12 -0800 (PST) Thomas Roberts <[EMAIL PROTECTED]> mentioned: > I need help deciding which ISO to install on my > machine, which is a Compaq Presario SR1620NX. The > FreeBSD/amd64 Project web page says the Sempron uses > the AMD64 architecture so I installed the amd64 > 6.2-RELEASE ISO. Since I want to stay with STABLE I > started reading on how to do it and am now confused as > to what I should do.The /var/log/dmesg.today file > says: > > CPU: AMD Sempron(tm) Processor 3400+ (1989.82-MHz > k8-class CPU) > Origin="AuthenticAMD" Id=0x20ff2 Stepping=2 > > While searching through bsdforums.org a poster said > the k8-class CPU is an Athlon64 locked in 32-bit mode > and if anyone has this CPU they should be using the > i386 ISO. > > Whether I use the i386 or amd64 ISO I will be putting > the CPUTYPE?=k8 in my make.conf file so my question is > "Since I am specifying the CPUTYPE should I stay with > amd64 or start over with i386?" I am not worried > about not having 64-bit capabilities, but I am worried > that using the i386 ISO will not use the CPU to its fulest. > Since you have successfully installed 6.2/amd64 this is essentially an AMD64-enabled machine. So don't worry and use amd64 edition and use k8 as CPU type. -- Stanislav Sedov ST4096-RIPE pgppG4QfIqsFj.pgp Description: PGP signature
Re: Loader hang
On Thu, 1 Feb 2007 13:45:33 +1030 "Daniel O'Connor" <[EMAIL PROTECTED]> mentioned: > Hi *, > I recently installed 6.2 on a Supermicro P8SCT and I found that the loader > would hang after a few seconds unless I disabled the Adaptec 29160's BIOS. > > It also has a 3ware 8006-2LP (which I am booting off). The SCSI card only has > a tape drive on it though so I'm surprised it would install a BIOS at all > (after probing) > > Interestingly the hang only occurred when booting the installed version - when > booting from the CD it worked perfectly.. > That's because loader won't touch hadrdrives when booting from CD. > Anyone seen anything similar? Any suggestions for debugging? :) Have you tried to boot anything else (Linux, Windows, etc)? Probably, the Host adapter's BIOS is broken, so try to update it to the latest version. -- Stanislav Sedov ST4096-RIPE pgpJUwI2uMbjO.pgp Description: PGP signature
Re: DRM disabled?
On Sun, 14 Jan 2007 11:56:43 -0600 (CST) Larry Rosenman mentioned: > Greetings, > I finally have FreeBSD back on my HP ZE5700US Laptop. I was wondering if > anyone knew why > the DRM is being disabled. I have the agp device static in the kernel, and > have attached a dmesg, as well as the X log, and > also the full kernel config. > > Ideas? For dri to work you should install recent Xorg (7.1 - 7.2) as drm on your card will not work with 6.9. You can find instructions how to obtain Xorg 7.2 featured ports tree on http://wiki.freebsd.org/. However, you might want to wait until Xorg modular will be committed into the tree. Hopefully, that will be done soon. -- Stanislav Sedov ST4096-RIPE pgpOLCgHBCfQr.pgp Description: PGP signature
