Manuel Bouyer wrote:
> > Few minor points. Does atabus_alloc_drives() need to use M_NOWAIT and
> > malloc(9), instead of kmem(9)?
>
> At first glance I'd say it should always be called from the atabus thread,
> so it should be OK
Could you change it then? Generally, KM_NOSLEEP should not be us
On Wed, Jul 04, 2012 at 09:45:58PM +0300, Andreas Gustafsson wrote:
> I don't know. To help narrow down the possible differences, the
> autobuild system is running 5.1_STABLE, and invokes build.sh like
> this, in a freshly checked out source tree (from a date-based
> CVS checkout from anoncvs)
On Jul 5, 3:37am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/fs/msdosfs
| > Well, I am not sure if KASSERT() is the best solution here. But
| > what else can we do? I agree that there should be at least a
| > warning.
|
| Check
| (secsize != 0 && secsize <
Paul Goyette wrote:
> My test-bed does not run any i386 builds. I do only amd64-on-amd64-host
Right, but the TNF testbed also does amd64-on-amd64-host builds,
and unlike yours, they are failing.
--
Andreas Gustafsson, g...@gson.org
On Wed, 4 Jul 2012, Andreas Gustafsson wrote:
Paul Goyette wrote:
My test-bed does not run any i386 builds. I do only amd64-on-amd64-host
Right, but the TNF testbed also does amd64-on-amd64-host builds,
and unlike yours, they are failing.
Ah, yes, I see that now.
On Wed, 4 Jul 2012, Andreas Gustafsson wrote:
I see that it is also failing on my own testbed which is running the
same scripts as the TNF one, but not on Paul Goyette's, which is
running a different set of scripts.
My test-bed does not run any i386 builds. I do only amd64-on-amd64-host
Hi Reinoud,
Thank you for your quick response.
You wrote:
> Its weird that this comes up since i build tested it for amd64 (native) and
> i386 (cross om amd64) with success here on NetBSD 6.0_BETA2.
I see that it is also failing on my own testbed which is running the
same scripts as the TNF one,
christos@ wrote:
> | Anyway KASSERT() (or sanity check) should also be centralized
> | to getdisksize()?
>
> Well, I am not sure if KASSERT() is the best solution here. But
> what else can we do? I agree that there should be at least a
> warning.
Check
(secsize != 0 && secsize <= MAXBSIZE && pow
On Jul 5, 1:34am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/sys/fs/msdosfs
| Hmm, as you say md(4) would have failed in msdosfs_mountfs()
| even before getdisksize() was introduced and the only problem
| was in disklabel support addition to md(4).
That is cor
christos@ wrote:
> In article <120704210521.m0104...@mirage.ceres.dti.ne.jp>,
> Izumi Tsutsui wrote:
> >
> >The problem is getdisksize() was introduced after 5.0
> >and it assumed DIOCGPART always returned valid values,
> >but no one confirmed if the assumption was correct.
>
> What do you thin
On Mon, Jul 02, 2012 at 06:15:50PM +, Manuel Bouyer wrote:
> cvs rdiff -u -r1.117 -r1.118 src/sys/dev/pcmcia/wdc_pcmcia.c
wdcp is used before it is set.
Joerg
Hi Andreas,
On Wed, Jul 04, 2012 at 04:28:00PM +0300, Andreas Gustafsson wrote:
> The NetBSD-current/i386 release build has been broken for several days
> now, starting with your commits of 2012-06-30 15:03:56 UTC. It's
> failing with:
>
> --- kern-GENERIC_USERMODE ---
> cc1: warnings be
In article <120704210521.m0104...@mirage.ceres.dti.ne.jp>,
Izumi Tsutsui wrote:
>
>The problem is getdisksize() was introduced after 5.0
>and it assumed DIOCGPART always returned valid values,
>but no one confirmed if the assumption was correct.
What do you think the drivers called before to get
dholland@ wrote:
> On Wed, Jul 04, 2012 at 01:45:08AM +0900, Izumi Tsutsui wrote:
> > > getdisksize() is not complicated; it tries DIOCGPART and then
> > > DIOCGWEDGEINFO and that's about it.
> >
> > Yes, but it is not implementation issue but design issue.
> >
> > > I think it's wrong for
On Mon, Jul 02, 2012 at 11:13:51PM +0100, Mindaugas Rasiukevicius wrote:
> "Manuel Bouyer" wrote:
> > Module Name:src
> > Committed By: bouyer
> > Date: Mon Jul 2 18:15:48 UTC 2012
> >
> > ...
> >
> > Log Message:
> > Add sata Port MultiPlier (PMP) support to the ata
15 matches
Mail list logo
