On 9/17/10 4:45 PM, Pawel Jakub Dawidek wrote:
Hi.
My company was in need for functionality similar to nextboot(8), but on
boot loader level, so we can have two partitions we boot from where one
is known to be good and the other is used for upgrades. We upgrade by
dd(1)ing entire partition imag
Hi.
My company was in need for functionality similar to nextboot(8), but on
boot loader level, so we can have two partitions we boot from where one
is known to be good and the other is used for upgrades. We upgrade by
dd(1)ing entire partition image onto unused partition, we mark it as
try-to-boot
On Fri, Sep 17, 2010 at 10:36 PM, Kostik Belousov wrote:
> On Fri, Sep 17, 2010 at 09:55:26PM +0200, Norberto Lopes wrote:
>> Hi.
>> I've been taking a look at ktrace and kdump in order to get (1) familiar
>> with the sources and (2) to finally try to give back something to the
>> community.
>>
On Fri, Sep 17, 2010 at 09:55:26PM +0200, Norberto Lopes wrote:
> Hi.
> I've been taking a look at ktrace and kdump in order to get (1) familiar with
> the sources and (2) to finally try to give back something to the community.
>
> So far from what I've seen, and after reading this thread
> http
Hi.
I've been taking a look at ktrace and kdump in order to get (1) familiar with
the sources and (2) to finally try to give back something to the community.
So far from what I've seen, and after reading this thread
http://lists.freebsd.org/pipermail/freebsd-arch/2006-April/005107.html it seems
>> John Baldwin wrote:
> Oh, yes. I've updated the patch to remove D_NEEDGIANT.
So far (last 24 hours) my tun(4) with your patch was very stable.
I am updating it to remove D_NEEDGIANT. Thank you!
//Marcin
___
freebsd-current@freebsd.org mailing list
on 17/09/2010 18:36 M. Warner Losh said the following:
>
> so is there support for the following:
Aye.
> Index: subr_bus.c
> ===
> --- subr_bus.c(revision 212791)
> +++ subr_bus.c(working copy)
> @@ -3996,9 +3996,11
I created hackish scripts to generate pci_vendors file from Boemler and
Mares (pciids.sf.net) lists. I haven't found the Hart list.
The results of the scripts are here:
http://www.alexdupre.com/pci_vendors/mares.txt
http://www.alexdupre.com/pci_vendors/boemler.txt
http://www.alexdupre.com/pci_ven
In message: <20100917055953.gf1...@pluto.vnode.local>
Joel Dahl writes:
: On 16-09-2010 8:28, John Baldwin wrote:
: > On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote:
: > > I noticed this during boot (HEAD from yesterday):
: > >
: > > hpet0: [FILTER]
: > > hpet0: [FILTER]
In message: <201009160828.35520@freebsd.org>
John Baldwin writes:
: On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote:
: > I noticed this during boot (HEAD from yesterday):
: >
: > hpet0: [FILTER]
: > hpet0: [FILTER]
: > hpet0: [FILTER]
: > hpet0: [FILTER]
: > hpet0: [FI
On 9/17/2010 1:27 AM, Rui Paulo wrote:
> On 17 Sep 2010, at 07:55, Rui Paulo wrote:
>
>> On 17 Sep 2010, at 02:44, Justin T. Gibbs wrote:
>>
>>> At Spectra Logic, we are using FreeBSD amd64 under Xen to serve storage
>>> to other Xen domains. Over the past 9 months, we've made several changes
>>>
In message: <4c91100c.5060...@freebsd.org>
Doug Barton writes:
: > Most of the code is there anyway, and it isn't evolving as fast as
: > BIND.
:
: That is actually a more rational argument, even if I don't agree with
: it. FWIW, part of the reason that I don't agree with it is that a
In message: <4c911214.7060...@freebsd.org>
Alexander Motin writes:
: Joel Dahl wrote:
: > I noticed this during boot (HEAD from yesterday):
: >
: > hpet0: [FILTER]
: > hpet0: [FILTER]
: > hpet0: [FILTER]
: > hpet0: [FILTER]
: > hpet0: [FILTER]
: > hpet0: [FILTER]
: > hpet0: [FILTER]
:
On Thursday, September 16, 2010 9:02:23 am Marcin Cieslak wrote:
> Dnia 15.09.2010 John Baldwin napisaĆ/a:
> > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
> >> Output queue of tun(4) gets full after some time when sending lots of data.
> >> I have been observing this on -CURRENT
[re-post, my address book was polluted with cu_rrr_ent@ entry, sorry]
on 09/09/2010 11:01 Andriy Gapon said the following:
> on 26/07/2010 19:07 Andriy Gapon said the following:
>>
>> Anyone knows any reason why VM_KMEM_SIZE_SCALE on amd64 should not be set to
>> 1?
>> I mean things potentially
On 17 Sep 2010, at 07:55, Rui Paulo wrote:
> On 17 Sep 2010, at 02:44, Justin T. Gibbs wrote:
>
>> At Spectra Logic, we are using FreeBSD amd64 under Xen to serve storage
>> to other Xen domains. Over the past 9 months, we've made several changes
>> to FreeBSD's Xen support. These include:
>>
16 matches
Mail list logo