On 3 September 2011 12:35, Eitan Adler wrote:
> The best way to do this is to find a known working version of the
> kernel and then "bisect" the version from the known bad and known good
> versions until you arrive at the breaking commit. It is easier if you
> look at the svn log to see which com
On Sat, Sep 3, 2011 at 12:24 AM, Adrian Chadd wrote:
> Hi,
>
> The most direct way to fix this is to find the exact commit which
> introduced the break.
>>> Anything else you'd like me to try?
The best way to do this is to find a known working version of the
kernel and then "bisect" the version
Hi,
The most direct way to fix this is to find the exact commit which
introduced the break.
Thanks,
Adrian
On 3 September 2011 00:27, Daniel Eischen wrote:
> On Thu, 25 Aug 2011, Daniel Eischen wrote:
>
>> On Thu, 25 Aug 2011, John Baldwin wrote:
>>
>>> On Wednesday, August 24, 2011 8:19:4
Brandon Gooch wrote:
> On Thu, Sep 1, 2011 at 8:09 PM, Brandon Gooch
> wrote:
> > On Fri, May 27, 2011 at 8:09 AM, Rick Macklem
> > wrote:
> >>> On Thu, 26 May 2011, Rick Macklem wrote:
> >>> ...
> >>> > http://people.freebsd.org/~rmacklem/dtrace.patch
> >>> >
> >>> Hmm. Is it just me?
> >>> Try
On Thu, 25 Aug 2011, Daniel Eischen wrote:
On Thu, 25 Aug 2011, John Baldwin wrote:
On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote:
Hello,
I have an older Dell 4150 laptop that takes forever to build
world, so I don't update it that often. The last time I
updated it was March
The patches can be found at the same locations:
head - http://people.freebsd.org/~avg/stop_scheduler_on_panic.diff
stable/8 - http://people.freebsd.org/~avg/stop_scheduler_on_panic.8.x.diff
Additionally, if you use a USB keyboard, then the following patch is required
for
proper operation in post
2011/9/2 John Baldwin :
> A more useful test would be to alter pmap.h so it says:
>
> #ifndef NKPT
> #define NKPT doesnt_compile
> #endif
Uhm fair enough, thanks for the explanation John.
--
Robert Millan
___
freebsd-current@freebsd.org mailing list
ht
on 02/09/2011 01:29 Nathan Whitehorn said the following:
> On 09/01/11 17:23, Matt Thyer wrote:
>> Probably the real solution is to use MBR and have BSDinstall and the install
>> kernel support UFS labels. Space on the memstick is not an issue.
>
> Both support that. The issue is makefs(8).
Here
On 09/01/2011 22:36, Sebastian Chmielewski wrote:
>
> hi,
> I'm running FreeBSD-CURRENT r224522M installed on ZFS Root and GPT
> partitions and this setup is running fine. Today I've updated to r225312 and
> after rebooting I've got following error message from boot loader:
>
> ZFS: i/o error - a
on 01/09/2011 23:36 Sebastian Chmielewski said the following:
>
> hi,
> I'm running FreeBSD-CURRENT r224522M installed on ZFS Root and GPT
> partitions and this setup is running fine. Today I've updated to r225312 and
> after rebooting I've got following error message from boot loader:
>
> ZFS: i
On Friday, September 02, 2011 1:23:16 am Robert Millan wrote:
> 2011/9/1 John Baldwin :
> > In general we force the relevant C files to use opt_*.h includes and avoid
> > nested includes of those in headers.
>
> With this approach I can't trust that this feature will do the right
> thing. I would
On Fri, Sep 2, 2011 at 1:49 PM, Sergey Kandaurov wrote:
> On 2 September 2011 15:41, Piotr Kubaj
> wrote:
> > 1. It's in the dump file.
> > 2. In BEASTIE.
> > 3. As I wrote before, 9.0-BETA1, but I had used this kernel with
> 8.2-RELEASE
> > and 8.2-STABLE (only did slight modifications for 9.0)
On 2 September 2011 15:41, Piotr Kubaj wrote:
> 1. It's in the dump file.
> 2. In BEASTIE.
> 3. As I wrote before, 9.0-BETA1, but I had used this kernel with 8.2-RELEASE
> and 8.2-STABLE (only did slight modifications for 9.0).
> 4. I'm not really into it, what exactly do you mean?
I see from you
1. It's in the dump file.
2. In BEASTIE.
3. As I wrote before, 9.0-BETA1, but I had used this kernel with 8.2-RELEASE
and 8.2-STABLE (only did slight modifications for 9.0).
4. I'm not really into it, what exactly do you mean?
BEASTIE
Description: Binary data
dump
Description: Binary data
_
2011/9/1 John Baldwin :
> In general we force the relevant C files to use opt_*.h includes and avoid
> nested includes of those in headers.
With this approach I can't trust that this feature will do the right
thing. I would rather modify pmap.h by hand than run the unnecessary
risk.
> Do you kno
On 09/01/11 20:26, Matt Thyer wrote:
Advocacy by the project members is not going to be taken as seriously as an
independent third party comparison.
It's clear to me that the project should stick to improving it's own feature
set and leave these sorts of things to others.
Otherwise we're strayi
16 matches
Mail list logo
