hi sorry for being late in reply but I had some problems in the last week. I
hope u still remeber what I was talking about :)
@chargen
Thanx for ur reply.
Embedded computer systems permeate all aspects of our daily lives.
Alarm clocks, coffee makers, digital watches, cell phones, and automobiles
ar
On Wed, Jun 23, 2010 at 08:45:31AM -0700, Ted Faber wrote:
> On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote:
> > I have to admit that I'm more than a little surprised that this
> > problem does not affect modules that in src, but maybe that's because
> > I don't know all that much about
Hi Kostik,
This patch seems to have faded out from memory. Is it possible to go
forward and commit it?
Thanks,
Regards.
On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote:
> Below is the prototype that seems to work for me both with patched and
> old rtld on i386. Patch also contai
2010/6/23 Eugene Grosbein :
> On 23.06.2010 23:03, rank1see...@gmail.com wrote:
>> I've escaped to loader prompt:
>> Current device is disk0s3a, from which this loader is running.
>>
>> My USB stick is device1 and device1s2a is UFS /, on which I would like to
>> reach some file or simply list direc
On Wed, Jun 23, 2010 at 9:03 AM, wrote:
> I've escaped to loader prompt:
> Current device is disk0s3a, from which this loader is running.
>
> My USB stick is device1 and device1s2a is UFS /, on which I would like to
> reach some file or simply list directory.
IIRC, there is no way to do this (bu
You *should* be able to use device1s2a:/ as a syntax, but I noticed a bug in
our old loader code that parses devicenames like that where it wouldn't work
correctly with unit numbers. I don't know if that bug is still around, but
setting currdev did work around it.
/Andrew
> -Original
On 23.06.2010 23:03, rank1see...@gmail.com wrote:
> I've escaped to loader prompt:
> Current device is disk0s3a, from which this loader is running.
>
> My USB stick is device1 and device1s2a is UFS /, on which I would like to
> reach some file or simply list directory.
>
> Syntax?
I guess, you
I've escaped to loader prompt:
Current device is disk0s3a, from which this loader is running.
My USB stick is device1 and device1s2a is UFS /, on which I would like to
reach some file or simply list directory.
Syntax?
___
freebsd-hackers@freebsd.org m
On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote:
> I have to admit that I'm more than a little surprised that this
> problem does not affect modules that in src, but maybe that's because
> I don't know all that much about FreeBSD's build infrastructure. Are
> the src modules being linke
on 23/06/2010 18:03 Ryan Stone said the following:
> On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon wrote:
>> Which also brings the question - what arch(s) is affected?
>> I tested on amd64.
>
> This should explain it. It looks to me like i386 uses kern/link_elf.c
> as its linker, while amd64 use
On Wed, Jun 23, 2010 at 2:56 AM, Ivan Voras wrote:
> On 06/21/10 02:25, Garrett Cooper wrote:
>
>> For whatever reason my source tree wasn't prebuilt, so I reran
>> buildkernel and everything was fine once again.
>
> So, do the tests pass now? :)
Not 100%, but that might be a problem with the tes
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon wrote:
>
> Which also brings the question - what arch(s) is affected?
> I tested on amd64.
This should explain it. It looks to me like i386 uses kern/link_elf.c
as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can
only find the sectio
On Wed, Jun 23, 2010 at 10:10:59AM +0300, Andriy Gapon wrote:
> on 23/06/2010 10:02 Andriy Gapon said the following:
> > I don't dispute that it is found broken in particular environments, I just
> > think
> > that the analysis could be incorrect.
>
> Which also brings the question - what arch(s)
On 06/21/10 02:25, Garrett Cooper wrote:
> For whatever reason my source tree wasn't prebuilt, so I reran
> buildkernel and everything was fine once again.
So, do the tests pass now? :)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.
Patrick Mahan writes:
> My issue is that if there is a build failure at any point, the
> status does not seem to be propagated upward. For example, if
> the kernel fails to build due to incorrect code, the script
> -kernel64.sh stops (verifable by examining the logfile),
> however, the make will
On Wednesday 23 June 2010 09:10:59 Andriy Gapon wrote:
> on 23/06/2010 10:02 Andriy Gapon said the following:
> > I don't dispute that it is found broken in particular environments, I
> > just think that the analysis could be incorrect.
Ok.
>
> Which also brings the question - what arch(s) is af
on 23/06/2010 10:02 Andriy Gapon said the following:
> I don't dispute that it is found broken in particular environments, I just
> think
> that the analysis could be incorrect.
Which also brings the question - what arch(s) is affected?
I tested on amd64.
--
Andriy Gapon
___
on 23/06/2010 09:52 Hans Petter Selasky said the following:
> On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
>> on 23/06/2010 03:38 Hans Petter Selasky said the following:
>>> Hi,
>>>
>>> I'm creating a new thread on this issue.
>>>
>>> On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone w
18 matches
Mail list logo
