Re: Testing requested: Hybrid ISO/USB boot

[Benno Rice]

> On Mar 22, 2018, at 1:48 PM, Thomas Schmitt <scdbac...@gmx.net> wrote:
> 
> Hi,
> 
> Benno Rice wrote:
>> I’ve been working on the ability to create hybrid ISO/HDD boot images for
>> x86, a la what Linux systems do with ISOHYBRID.
> 
> Waving friendly over the fence i feel entitled to give some neighbor's
> review.

Hello! Thanks for your response.

[snip]

>> https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz
> 
> This does not look much like it addresses EFI.
> 
>  $ xorriso -indev hybrid-bootonly.iso -report_el_torito plain 
> -report_system_area plain
>  ...
>  El Torito catalog  : 19  1
>  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz LBA
>  El Torito boot img :   1  BIOS  y   none  0x  0x00  4  20
>  El Torito boot img :   2  BIOS  y   none  0x  0x00   1600  24
>  ...
>  MBR partition table:   N Status  TypeStart   Blocks
>  MBR partition  :   1   0x80  0xa51   16
> 
> UEFI 2.4, 12.3.2.1, says about El Torito:
> "A Platform Id of 0xEF indicates an EFI System Partition."
> But entry 2 of this catalog is in a section with Platform Id 0x00 (x86 BIOS).
> 
> If byte 38977 (decimal) was 0xef rather than 0x00, then it would be marked
> as an El Torito boot image for EFI.

I think I’ve addressed this in this revision:

https://svnweb.freebsd.org/changeset/base/331463 
<https://svnweb.freebsd.org/changeset/base/331463>

And I’ve regenerated the image here:

https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz 
<https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz>

> Further: This section begins at byte address 38976 by a byte value 0x90.
> According to El Torito specs this means that another section follows.
> Correct would be value 0x91, which announces the end of the catalog.
> (El Torito 1.0, Figure 4, Offset 0)

I’ll look into this too.

> On HDD, EFI looks for specially marked partitions in GPT or MBR partition
> table.
> In MBR partiton table it looks for a partition of type 0xEF.
> (UEFI 2.4, 5.2.2)
> In GPT it looks for Type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
> (UEFI 2.4, Table 19)
> 
> So to mark the EFI partition, hybrid-bootonly.iso should have a MBR
> partition number 2 with type 0xEF, start at 512-byte block 24*2048/512 = 96,
> size 1600 blocks.
> (Strangely El Torito addresses by 2048-byte blocks but counts by 512-byte
> blocks. Size limit is 65535 blocks. But counts 0 and 1 mean to EFI
> "up to end of medium”.)

I’ll look in to this one too.

>> I’ve tested this image under qemu 
> 
> OVMF/SDK-II/Tianocore is too tolerant with the EFI specs and with silently
> using BIOS boot equipment. Real iron EFIs insist much more in compliance.

So it appears. Thanks again for looking at this!

Thanks,
Benno.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Testing requested: Hybrid ISO/USB boot

[Benno Rice]

Hello all!

I’ve been working on the ability to create hybrid ISO/HDD boot images for x86, 
a la what Linux systems do with ISOHYBRID. The general theory seems to be that 
ISO images have a 32KB hunk of zeroes at the front that they generally ignore 
so we’ll stick something in there that can handle booting if need be. The cases 
generally break down as follows:

UEFI with CD: Boots using an EFI system partition embedded in the ISO image. 
This loads loader, and so on.
UEFI with HDD: Same as above as UEFI doesn’t really care what the underlying 
medium is and it sees the ISO image.
Legacy BIOS with CD: Boots using El Torrito as always.

And now for the new part:

Legacy BIOS with HDD: Sees a DOS MBR stuck in the 32KB at the front of the ISO 
image. This MBR contains our MBR boot code, which sees an active BSD slice 
containing a variant of our BSD boot code that reads from the ISO filesystem 
instead of UFS. This finds loader in the ISO filesystem and loads that. Loader 
has had support for reading ISO9660 images off HDDs added. Everything continues 
normally after that.

The review for these changes is here:

https://reviews.freebsd.org/D14799 

And a version of the standard “bootonly” ISO image built with these changes is 
here:

https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz 


I’ve tested this image under qemu and VMware under all four of the BIOS/UEFI 
and CD/HDD combinations. I’ve also booted a system build around an Asus X399 
Prime motherboard with this dd’ed to a USB stick. I’d love some testing on more 
systems, especially things that are more likely to have more customized boot 
firmwares (I’m thinking Dell, HP, etc).

Many thanks,
Benno.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Benno Rice]

> On Jun 26, 2017, at 13:25, Konstantin Belousov  wrote:
> 
> On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote:
>> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov 
>> wrote:
>> 
>>> No need, I understood why MAP_STACK failed in this case, thanks to the
>>> ktrace log. This is indeed something ruby-specific, or rather, triggered
>>> by ruby special use of libthr. It is not related to the main stack
>>> split.
>>> 
>>> It seems that ruby requested very small stack for a new thread, only 5
>>> pages in size.  This size caused the stack gap to be correctly calculated
>>> as having zero size, because the whole stack is allocated by initial grow.
>>> But then there is no space for the guard page, which caused mapping failure
>>> for it, and overall stack mapping failure.
>>> 
>>> Try this.
>>> https://people.freebsd.org/~kib/misc/vm2.2.patch
>>> 
>>> 
>> I managed to get the "Cannot allocate red zone for initial thread" at the
>> start of installworld (doing CC feature detection, IIRC) going from r306247
>> to r320328.
>> 
>> Is it worth trying that patch out?
> 
> Ensure that you run a kernel past r320344 and then show me ktrace of
> the failing process.

So I’m running r320364 with a ZFS root:

> uname -a
FreeBSD bjrbsd 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320364: Mon Jun 26 
12:35:03 PDT 2017 benno@bjrbsd:/src/obj/src/freebsd/sys/GENERIC-NODEBUG  
amd64

While upgrading I discovered that the zfs command works fine in multiuser but 
fails in single-user in the way described above:

# zfs mount -a
Fatal error 'Cannot allocate red zone for initial thread' at line 393 in file 
/src/freebsd/lib(something)/thread/thr_init.c (errno = 12)
Abort trap (core dumped)

I booted into single-user and ran zfs under ktrace and I’ve put the results up 
for you:

https://people.freebsd.org/~benno/ktrace.out.txt
https://people.freebsd.org/~benno/ktrace.out
https://people.freebsd.org/~benno/zfs.core
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Possible bug in or around posix_fadvise after r292326

[Benno Rice]

Hi Konstantin,

I recently updated my dev box to r292962. After doing this I attempted to set 
up PostgreSQL 9.4. When I ran initdb the last phase hung. Using procstat -kk I 
found it appeared to be stuck in a loop inside a posix_fadvise syscall. I could 
not ^C or ^Z the initdb process. I could kill it but a subsequent attempt to rm 
-rf the /usr/local/pgsql/data directory also got stuck and was unkillable by 
any means. Rebooting allowed me to remove the directory but the initdb process 
still hung when I re-ran it.

I tried PostgreSQL 9.3 with similar results.

Looking at the source code for initdb I found that it calls posix_fadvise like 
so[1]:

 /*
  * We do what pg_flush_data() would do in the backend: prefer to use
  * sync_file_range, but fall back to posix_fadvise.  We ignore errors
  * because this is only a hint.
  */
 #if defined(HAVE_SYNC_FILE_RANGE)
 (void) sync_file_range(fd, 0, 0, SYNC_FILE_RANGE_WRITE);
 #elif defined(USE_POSIX_FADVISE) && defined(POSIX_FADV_DONTNEED)
 (void) posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED);
 #else
 #error PG_FLUSH_DATA_WORKS should not have been defined
 #endif

Looking for recent commits involving POSIX_FADV_DONTNEED I found r292326:

https://svnweb.freebsd.org/changeset/base/292326 


Backing this revision out allowed the initdb process to complete.

My current theory is that some how we’re getting ENOLCK or EAGAIN from the 
BUF_TIMELOCK call in bnoreuselist:

https://svnweb.freebsd.org/base/head/sys/kern/vfs_subr.c?view=annotate#l1676 


Leading to an infinite loop in vop_stdadvise:

https://svnweb.freebsd.org/base/head/sys/kern/vfs_default.c?annotate=292373#l1083
 


I haven’t managed to dig any deeper than that yet.

Is there any other information I could give you to help narrow this down?

Thanks,
Benno.

[1] 
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/initdb/initdb.c;h=35e39ce4b31b2f437d6e28eaf90500a22d229c6a;hb=HEAD#l631
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Possible bug in or around posix_fadvise after r292326

[Benno Rice]

> On Jan 4, 2016, at 22:05, Benno Rice <be...@freebsd.org> wrote:
> 
> Hi Konstantin,
> 
> I recently updated my dev box to r292962. After doing this I attempted to set 
> up PostgreSQL 9.4. When I ran initdb the last phase hung. Using procstat -kk 
> I found it appeared to be stuck in a loop inside a posix_fadvise syscall. I 
> could not ^C or ^Z the initdb process. I could kill it but a subsequent 
> attempt to rm -rf the /usr/local/pgsql/data directory also got stuck and was 
> unkillable by any means. Rebooting allowed me to remove the directory but the 
> initdb process still hung when I re-ran it.

[snip]

> 
> I haven’t managed to dig any deeper than that yet.
> 
> Is there any other information I could give you to help narrow this down?

Rebooted with a WITNESS kernel and got the following LOR after initdb started:

https://gist.github.com/jeamland/69a07c4523f0dea4c26c 
<https://gist.github.com/jeamland/69a07c4523f0dea4c26c>


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pmspcv panic on boot on this box

[Benno Rice]

Can you try the attached patch and let me know if it fixes the issue?

Many thanks,
Benno.



pmspcv.diff
Description: Binary data


 On Jul 30, 2015, at 11:55 AM, Benno Rice be...@freebsd.org wrote:
 
 Hi Larry,
 
 I’ve brought this to the attention of PMC Sierra and we’re pretty sure we’ve 
 worked out what the problem is. I’m just waiting on their review of the fix 
 I’ve suggested.
 
 Sorry this has caused you problems.
 
 Many apologies,
   Benno.
 
 On Jul 28, 2015, at 2:01 PM, Larry Rosenman l...@lerctr.org wrote:
 
 When I upgraded an approximately 3 month old -CURRENT system to yesterday, I 
 got page not present panics, after a message about pmspcv not supporting
 my ahd(4) deviceid. 
 
 I did NOT capture the panic, but adding
 
 nodevice pmspcv
 
 Allowed me to boot. 
 
 Dmesg.boot from the WORKING system attached. 
 
 I *CAN* work with someone if they want. 
 
 
 dmesg.boot___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: pmspcv panic on boot on this box

[Benno Rice]

Hi Larry,

I’ve brought this to the attention of PMC Sierra and we’re pretty sure we’ve 
worked out what the problem is. I’m just waiting on their review of the fix 
I’ve suggested.

Sorry this has caused you problems.

Many apologies,
Benno.

 On Jul 28, 2015, at 2:01 PM, Larry Rosenman l...@lerctr.org wrote:
 
 When I upgraded an approximately 3 month old -CURRENT system to yesterday, I 
 got page not present panics, after a message about pmspcv not supporting
 my ahd(4) deviceid. 
 
 I did NOT capture the panic, but adding
 
 nodevice  pmspcv
 
 Allowed me to boot. 
 
 Dmesg.boot from the WORKING system attached. 
 
 I *CAN* work with someone if they want. 
 
 
 dmesg.boot___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: UEFI

[Benno Rice]

On 03/10/2013, at 3:35 AM, John Baldwin j...@freebsd.org wrote:

 On Sunday, September 22, 2013 3:00:22 pm Michael Copeland wrote:
 I noticed on freebsdnews that UEFI support could make it into release.
 https://wiki.freebsd.org/UEFI
 http://svnweb.freebsd.org/base/projects/uefi/
 
 I've tested it as shown in the wiki link and it only reboots the vm.
 I'm just wondering if that news was accurate or if it's still going to be a
 long while till we have proper support for UEFI.
 
 It is not in the base tree yet, so it seems unlikely to make it in for 10.0.

I got snowed under at work and so haven't had a chance to get it in. The 
changes needed to LLVM/Clang have been done and I'm currently checking a patch 
that adds the necessary support in to our in-tree version (hat tip to dim@). I 
should have some space soon to actually get a working version ready but it 
won't make 10.0. I'm aiming for 10.1.

Cheers,
Benno.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: UEFI

[Benno Rice]

On 03/10/2013, at 7:46 AM, Michael Copeland mich...@kryptos-security.com 
wrote:

 Hmm
 Should I build with GCC?
 
Yes, the in-tree version of clang doesn't understand __attribute__((ms_abi)) 
and so it won't generate the Microsoft function call code that UEFI expects. 
You'll need gcc = 4.7 so you'll need it from ports. This has been one of the 
blockers on getting it done (beyond my lack of time).

Cheers,
Benno.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Patch to teach config(8) about platforms.

[Benno Rice]

On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote:
 On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote:
   
   Agreed. There's an advantage there, but see also my reply to
   Juli about the use of machine to mean MACHINE_ARCH and the
   use of platform to mean MACHINE. This I don't find appealing.
  
  I can see your point here, but if needed I'd rather see them renamed to
  MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE
  and MACHINE_ARCH are confusingly similar.
 
 I'm not sure I understand you. I don't mind the capitalization,
 just that we have MACHINE_ARCH and MACHINE defined on the hand
 and machine and platform on the other. If you would ask a
 person how they should be related, I can imagine that the
 logical should would be to relate machine to MACHINE and
 platform to MACHINE_ARCH. Which is opposite to what Juli
 proposed. That's the unappealing part. Not a biggy, but
 something that's better avoided now than fixed later.

In that case I'm mostly in agreement.  Avoiding confusion is a Good
Thing(tm).

[snip]

   Agreed. We should not do the same, but instead of saying that we
   do mips and powerpc different, I think we should say that mips and
   powerpc do it the normal way and pc98 does it differently. I like
   to use an extra keyword for the weird case (pc98) and not the normal
   (common) case. See also above, this is looking at it from a point
   of view we'll going to have in the future, not a point of view
   we all have now.
  
  Ok, so are you saying here that Juli's patch is ok but we need to look
  at how we deal with pc98?
 
 I would not introduce a platform/foo.h, but rather
 machine/${variant}/foo.h. The reason for this is that the
 /usr/include/platform directory is only needed on powerpc and mips,
 which seems to indicate that it should be under machine. Also,
 the use of machine/${variant} allows us to install the headers for
 all variants, which may improve cross-building. Note that I haven't
 tried it on for size, so I'm not fixated on it. I was hoping this
 would fall out of the discussion.
 
 You see how the current approach affects other architectures if you
 look at the diff for src/sys/conf/kmod.mk. All architectures,
 including those that don't have multiple variants will have a link
 added that mirrors the machine link. I find that aestheticly
 displeasing. If you have the variants under machine, you don't
 have to create more links.
 
 The change to src/include/Makefile also seems to have a bug in
 that it depends in /usr/include/platform to be created by
 mtree, but I don't see and diff for that. Adding platform to
 BSD.include.dist means that every architecture gets the
 directory. Otherwise it has to be created by hand for those
 platforms that have it.
 
 The same happens in config(8) where we create a platform link
 in all cases, not just for powerpc and mips.

Ok, the nice side to having platform/foo.h is that (to go back to the
endian example) you can have machine/endian.h including
platform/endian.h and not having to be a mess like:

#if defined(POWERMAC)
#include machine/powermac/endian.h
#elsif defined(LITTLE_ENDIAN_ARCH)
#include machine/little_endian_arch/endian.h
#elsif
...
#endif

It doesn't have to be /usr/include/platform, it could be
/usr/include/machine/platform for instance, but it'd be nice for it to
have a constant name.

  Or are you saying that you would prefer to change how the machine  
  directive works in config(8) and introduce a new non-standard
  directive for pc98?
 
 That was the thought I was playing with.

Hmm.  Juli, what do you think of this?

We could perhaps introduce platform and make it mutually exclusive
with machine, and that way if the config file has a machine
directive we get the old behaviour and only invoke the new behaviour
when we have a platform directive.  Then we can start transitioning
over to it as needed.  This is pretty much a no-op on sparc64, ia64 and
alpha (AFAIK) but powerpc can switch, and i386/pc98 can switch to it
later on.  Perhaps this could be a target for 6.0.

  If the former, I agree totally.  If the latter, I'm not so sure.  I'd
  rather see the directive be platform as that is a much more accurate
  name for it IMO.  If this means we kill off the machine directive, then
  that may be how it works.
 
 I don't have a problem with the name platform, although I avoid it
 for now to avoid confusion.

*nod* Fair enough.

-- 
Benno Rice [EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: Patch to teach config(8) about platforms.

[Benno Rice]

On Thu, 2003-01-30 at 15:48, David O'Brien wrote:
 On Tue, Jan 28, 2003 at 09:37:16PM -0800, Juli Mallett wrote:
  I've made a note that you don't think my way is optimal.  I do, and
  that's that, at this point.  No black magic, no convoluted config
  files, etc.  Go deal with the ODE config and Mach's configuration
  files, I have.  Or NetBSD's.  Or OpenBSD's.  At this point, I am
  convinced that the platform keyword is the least offensive and most
  productive way of doing all of this, and so on, being someone who
  has worked with more backwards methods, and being the person who
  had to deal with this first, and came up with something that suits
  the two groups who need it most (the pc98 mistake is probably near
  impossible to correct, due to the historical nature), MIPS, and
  PowerPC.
 
 Juli, you need to convince many more than just yourself that this is a
 good approach for something that is so over-reaching and will be
 something we *all* have to live with.  Right now you don't have much of a
 buy-in for this, and we haven't even seen public support for it from
 Peter (the config(8) maintainer).
 
 Possibly you have a very eloquent design, and that once something is
 implemented using it the rest of us will have our light bulbs turned on.
 Maybe this is something that should remain in a Perforce tree until that
 time.

I actually think this design is a good thing.  I look at the way NetBSD
does sub-ports and I find it mildly confusing unless you know a port is
a sub-port of one of the top-level ports (eg, macppc's relationship to
powerpc) it looks like it's a top-level port in it's own right.  This
system would allow us to group all the sub-ports in the same directory,
thus clearly showing the relationship.

I would like to see the framework for this brought in, then when I start
work on making FreeBSD work on the Teron CX boards I can use it.  We can
also aim (if we wish) to move pc98 over to this.  Alpha could also use
this to separate out the various platforms and we could also use it to
distinguish between acpi and legacy PC systems if we want.

By rejecting this, you're forcing powerpc platform ports (of which there
will be more than one, I can assure you) to do pc98-style hackery in
order to exist.  I really don't want this.  It's my aim with the powerpc
port to enable vendors to support their hardware with a minimum of
effort.  This means making adding new platforms easy and quick.  Juli's
system allows this.  The current system doesn't.

-- 
Benno Rice [EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: Patch to teach config(8) about platforms.

[Benno Rice]

On Thu, 2003-01-30 at 15:57, David O'Brien wrote:
 On Tue, Jan 28, 2003 at 11:46:47PM -0800, Marcel Moolenaar wrote:
  I would not introduce a platform/foo.h, but rather
  machine/${variant}/foo.h. The reason for this is that the
  /usr/include/platform directory is only needed on powerpc and mips,
  which seems to indicate that it should be under machine. Also,
  the use of machine/${variant} allows us to install the headers for
  all variants, which may improve cross-building.
 
 This is a very nice way of adding the complexity when it is needed, but
 not getting in the way of those cases where it isn't needed.

Except that it requires us to know which platform variant directory to
use in each case.  If this directory is then copied or symlinked to
/usr/include/platform or /usr/include/machine/platform, I don't object
but otherwise it'll lead to an ifdef nightmare in the machine includes.

-- 
Benno Rice [EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: Patch to teach config(8) about platforms.

[Benno Rice]

On Wed, 2003-01-29 at 11:18, Juli Mallett wrote:
 * De: Juli Mallett [EMAIL PROTECTED] [ Data: 2003-01-28 ]
   [ Subjecte: Re: Patch to teach config(8) about platforms. ]
 
 In short, platform provides machinery for a single port of FreeBSD
 which represents exactly one MACHINE_ARCH to support a numbe of
 different hardware platforms - MACHINE - under a unified system,
 without interfering with how anything works, and without doing it in
 a convoluted/imho-backwards way.  There is not a way to mix MACHINE
 and MACHINE_ARCH within a single port, as it is now.  You have to
 duplicate things like pc98 does.

I'd also like to point out that PowerPC will benefit greatly from this. 
PowerPC platforms vary wildly in how they do various things (incl.
endianness in some cases) and so this provides a much cleaner mechanism
to select a set of platform quirks than trying to do what i386/pc98
do.

-- 
Benno Rice [EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: Patch to teach config(8) about platforms.

[Benno Rice]

On Wed, 2003-01-29 at 16:18, Marcel Moolenaar wrote:
 On Tue, Jan 28, 2003 at 08:57:38PM -0800, Juli Mallett wrote:
  
  Yes, you are following me.  But also, you mention that machine
  as implemented means what I said it means, but there is other
  precident for using it as I say.  For example, BSD/OS uses
  machine sparc and options SUN4M.  NetBSD uses machine in a
  way more similar to what you want, but like machine sgimips mips
  for example.  What we want...  Could be done with machine, if we
  allow there to be no files.XXX for a given machine XXX and so
  on, but I think this is less clear.  How would you propose to write
  the following:
  
  %%%
  machine mips
  platformsgimips
  %%%
  
  Would you write it as:
  
  %%%
  machine mips sgimips
  %%%
 
 No, I see MACHINE_ARCH implied by where you run config. This seems
 strange and I'm not completely sure it's a good thing, but
 MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and
 defining the architecture in the kernel config file only allows
 a limited freedom; namely the freedom to have the config file
 outside the source tree. It basicly only defines a directory,
 nothing else. See also below for pc98.
 
 Thus, MACHINE_ARCH is not specified and machine holds the
 implementation (ie platform). This is exactly what we have
 now, so you don't change the meaning.

This is just confusing.  Having just played with this, if I specify
machine i386 while in the sys/powerpc/conf directory, I end up with an
unbuildable configuration as it sucks in the i386 Makefile but assumes
that it's arch-specific files are in ../../include.

This means that we would need to use:

machine powermac

in the config file while being in the powerpc directory, and then have a
sys/conf/*.powermac (along with all the other ones).  This to me is
backwards.

If we follow Juli's suggestion, we have:

machine powerpc
platformpowermac

and this uses the standard sys/conf/*.powerpc and simply pick up a set
of platform-dependant includes from sys/powerpc/powermac.  The options
logic handles the rest as we already have lines in
sys/conf/files.powerpc like:

powerpc/powermac/uninorth.c optionalpowermac pci
powerpc/powermac/macio.coptionalpowermac pci
powerpc/powermac/ata_macio.coptionalpowermac ata

Then when we head off to implement a little-endian powerpc platform we
can use:

machine powerpc
platformlittle-endian-platform

and it'll grab it's includes out of sys/powerpc/little-endian-platform
and we can do the same sort of files.powerpc magic as above.

Juli's form is also more explicit, which I find appealing.

  There's more at stake than just what we need, it also has to make
  sense when we don't need it, and so on.  The above two things I
  have suggested break in dumb ways...  If you just figure out the
  MACHINE_ARCH based on /sys/XXX/conf's XXX bit, then you could
  define MACHINE based on the machine directive, and as such, on
  i386 and sparc64 and ... it would do the right thing, and it
  would allow the MIPS stuff to be done, but it breaks the existing
  pc98 stuff, because it resides in /sys/$MACHINE.
 
 Correct. I either want pc98 transformed or if that's not possible
 or feasible, a keyword root, tree, directory or 
 nonstandardlocation to tell config(8) that the (sub-)port is
 not where we normally have it. We then create a new keyword,
 but it explcitly means a location, a path. The introduction of
 platform is more confusing. First of all it maps to MACHINE,
 while we have the machine keyword mapping to something else.
 This is illogical. The machine keyword basicly controls
 source layout and has nothing to do with the machine you're
 building for. Again, illogical.
 
 So, I'm not opposed to having a new variable if it's too hard to
 do it without, but I think there's a more logical/optimal scheme
 of naming and attaching meaning that does not affect the common
 case (it only affects pc98).

Juli's patches don't touch the common case.  If you don't specify a
platform then you don't get that extra logic.  Easy.  I agree that
moving pc98 over to whatever system we want to use is a good idea, but
for the moment I'd be happy with not forcing mips and powerpc down the
same road as pc98 which I see as being overly painful and confusing.

-- 
Benno Rice [EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: Patch to teach config(8) about platforms.

[Benno Rice]

On Wed, 2003-01-29 at 17:25, Marcel Moolenaar wrote:
 On Wed, Jan 29, 2003 at 04:56:10PM +1100, Benno Rice wrote:
   
   No, I see MACHINE_ARCH implied by where you run config. This seems
   strange and I'm not completely sure it's a good thing, but
   MACHINE_ARCH is defined in /sys/${ARCH}/include/param.h and
   defining the architecture in the kernel config file only allows
   a limited freedom; namely the freedom to have the config file
   outside the source tree. It basicly only defines a directory,
   nothing else. See also below for pc98.
   
   Thus, MACHINE_ARCH is not specified and machine holds the
   implementation (ie platform). This is exactly what we have
   now, so you don't change the meaning.
  
  This is just confusing.  Having just played with this, if I specify
  machine i386 while in the sys/powerpc/conf directory, I end up with an
  unbuildable configuration as it sucks in the i386 Makefile but assumes
  that it's arch-specific files are in ../../include.
 
 Yes. We now have config(8) interpret machine in such a way that
 it works for pc98 and therefore does not work right iwith what we
 like to achieve. That needs to change for it to work.

Agreed.

  Juli's form is also more explicit, which I find appealing.
 
 Agreed. There's an advantage there, but see also my reply to
 Juli about the use of machine to mean MACHINE_ARCH and the
 use of platform to mean MACHINE. This I don't find appealing.

I can see your point here, but if needed I'd rather see them renamed to
MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE
and MACHINE_ARCH are confusingly similar.

  Juli's patches don't touch the common case.
 
 We have 3 architectures that have multiple machines or platforms
 (mips, powerpc and i386). Setting platform for mips and powerpc
 and not i386 means that you're setting it for the common case,
 because you could have nonstandardlocation defined for only pc98.
 Again, this is just looking at it from a different point of view,
 but a point of view we all have in a year from now when we moved
 there.

True.  This is fixable though.

  platform then you don't get that extra logic.  Easy.  I agree that
  moving pc98 over to whatever system we want to use is a good idea, but
  for the moment I'd be happy with not forcing mips and powerpc down the
  same road as pc98 which I see as being overly painful and confusing.
 
 Agreed. We should not do the same, but instead of saying that we
 do mips and powerpc different, I think we should say that mips and
 powerpc do it the normal way and pc98 does it differently. I like
 to use an extra keyword for the weird case (pc98) and not the normal
 (common) case. See also above, this is looking at it from a point
 of view we'll going to have in the future, not a point of view
 we all have now.

Ok, so are you saying here that Juli's patch is ok but we need to look
at how we deal with pc98?

Or are you saying that you would prefer to change how the machine
directive works in config(8) and introduce a new non-standard
directive for pc98?

If the former, I agree totally.  If the latter, I'm not so sure.  I'd
rather see the directive be platform as that is a much more accurate
name for it IMO.  If this means we kill off the machine directive, then
that may be how it works.

-- 
Benno Rice [EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

kthread.9 out of date

[Benno Rice]

I have just discovered the hard way that the kthread.9 manual page is
slightly out of date.

Having never done man page work before, I've attached a diff of the
proposed change and if someone could give this a once-over and fix
and/or commit it, that'd rock.

Thanks. =)

-- 
Benno Rice
[EMAIL PROTECTED]

Index: kthread.9
===
RCS file: /home/ncvs/src/share/man/man9/kthread.9,v
retrieving revision 1.11
diff -u -r1.11 kthread.9
--- kthread.9	10 Oct 2002 00:29:22 -	1.11
+++ kthread.9	18 Oct 2002 09:36:21 -
@@ -44,7 +44,7 @@
 .Ft void
 .Fn kproc_shutdown void *arg int howto
 .Ft int
-.Fn kthread_create void (*func)(void *) void *arg struct proc **newpp int flags const char *fmt ...
+.Fn kthread_create void (*func)(void *) void *arg struct proc **newpp int flags int pages const char *fmt ...
 .Ft void
 .Fn kthread_exit int ecode
 .Ft int
@@ -121,6 +121,10 @@
 .Fa flags
 argument specifies a set of flags as described in
 .Xr rfork 2 .
+The
+.Fa pages
+argument specifies the size of the new kthread's kernel stack in pages.
+If 0 is used, the default kernel stack size is allocated.
 The rest of the arguments form a
 .Xr printf 9
 argument list that is used to build the name of the new thread and is stored



signature.asc
Description: This is a digitally signed message part

Re: Thread state

[Benno Rice]

On Fri, 2002-07-12 at 08:47, John Baldwin wrote:
 Currently, sparc64 SMP panics before getting out of single user mode
 because there is an optimization case in cpu_switch() (if we are
 switching back to the same thread, we just return right away) that
 doesn't set td_state to TDS_RUNNING.  Also, according to Peter, the
 code in ia64's cpu_switch() doesn't work either.  Rather than try to
 fix this in the assembler though, I think it is easier to just set
 the thread state once in C at the end of choosethread().  It is a
 lot easier to maintain down the road.  The patch to do this is at
 http://www.freebsd.org/~jhb/patches/kse_switch.patch
 
 It has been tested on sparc64, alpha, and i386 all with SMP.  I
 would like to commit it soonish.  Comments?

I think it's a great idea.
No problems from here. =)

-- 
Benno Rice
[EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: PAM broke?

[Benno Rice]

On Tue, 2002-04-16 at 10:07, Dan Eischen wrote:
 Fresh cvsup and buildworld from today's -current seems to have
 broken pam logins for telnet and ssh.  Fresh mergemaster too.

[snip]

 Any clues?

Remove -DYP from the CFLAGS in /usr/lib/libpam/modules/pam_unix/Makefile
and rebuild/reinstall libpam.

This took me about an hour to track down. =(

-- 
Benno Rice
[EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: PAM broke?

[Benno Rice]

On Tue, 2002-04-16 at 13:43, Daniel Eischen wrote:
 On 16 Apr 2002, Benno Rice wrote:
  On Tue, 2002-04-16 at 10:07, Dan Eischen wrote:
   Fresh cvsup and buildworld from today's -current seems to have
   broken pam logins for telnet and ssh.  Fresh mergemaster too.
  
  [snip]
  
   Any clues?
  
  Remove -DYP from the CFLAGS in /usr/lib/libpam/modules/pam_unix/Makefile
  and rebuild/reinstall libpam.
 
 Thanks, that did the trick.
 
 Anyone know if this is the correct fix?  It shouldn't be left
 broken.

I think des's commit that removed the _use_yp variable from
usr.sbin/vipw/pw_util.c fixed it.  I managed to get an unresolved symbol
error for _use_yp out of pam with the attached patch.

-- 
Benno Rice
[EMAIL PROTECTED]


Index: contrib/openpam/lib/openpam_dynamic.c
===
RCS file: /home/ncvs/src/contrib/openpam/lib/openpam_dynamic.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 openpam_dynamic.c
--- contrib/openpam/lib/openpam_dynamic.c   7 Mar 2002 19:24:22 -   1.1.1.2
+++ contrib/openpam/lib/openpam_dynamic.c   16 Apr 2002 03:49:27 -
@@ -67,6 +67,7 @@
*strrchr(vpath, '.') = '\0';
if ((dlh = dlopen(vpath, RTLD_NOW)) == NULL) {
free(module);
+   openpam_log(PAM_LOG_ERROR, %s, dlerror());
return (NULL);
}
}



signature.asc
Description: This is a digitally signed message part

Re: Intel i830 driver?

[Benno Rice]

On Sat, 2002-04-06 at 15:17, James Satterfield wrote:
 Anyone working on one of these?

What kind of driver do you mean?

I have an i830MP chipset in my Dell Inspiron 4100 and it's working fine.

-- 
Benno Rice
[EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: ACPI autoload failed -- unable to install (fwd)

[Benno Rice]

On Fri, 2002-03-15 at 14:49, Jeff Kletsky wrote:
 Tried the obvious -- manually loading acpi.ko -- still fails

[snip]

   7) Remove acpi.ko.flp, insert mfsroot.flp
 
  boot
 
  ...and watch the BTX halt

Can you provide a copy of the BTX fault information?

It's a bit hard to debug unless you can give us information like that.

-- 
Benno Rice
[EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: Non 386 testers REALLY NEEDED

[Benno Rice]

--=-c5mu7fd8+iIeadXPJgcR
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-02-07 at 08:01, Julian Elischer wrote:
=20
 for the set of patches at:
 http://www.freebsd.org/~julian/adiff
=20
 these patches SHOULD NOT EFFECT your system except to do some
 slight re-aranging of stuff in the kernel.
=20
 THe aim is to get this committed to 'clarify' the upcoming
 KSE commit in http://www.freebsd.org/~julian/thediff
=20
 which includes adiff as a subset.
=20
 when adiff is committed thediff will become a lot easier for people to=20
 read and check. I'd like to get adiff in relatively soon.

This causes some breakage in PowerPC but I'm working on it.  Go ahead
and commit and I'll fix PowerPC up after.

--=20
Benno Rice
[EMAIL PROTECTED]

--=-c5mu7fd8+iIeadXPJgcR
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org

iEYEABECAAYFAjxiXwIACgkQXjRwWofFmQkwBwCbBNexhLf2sKe8ZckvRwyYO6mw
IWgAni8WYxq6OsO1904GUM/nRN+P//IT
=I2dZ
-END PGP SIGNATURE-

--=-c5mu7fd8+iIeadXPJgcR--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Non 386 testers REALLY NEEDED

[Benno Rice]

On Thu, 2002-02-07 at 08:01, Julian Elischer wrote:
 
 for the set of patches at:
 http://www.freebsd.org/~julian/adiff
 
 these patches SHOULD NOT EFFECT your system except to do some
 slight re-aranging of stuff in the kernel.
 
 THe aim is to get this committed to 'clarify' the upcoming
 KSE commit in http://www.freebsd.org/~julian/thediff
 
 which includes adiff as a subset.
 
 when adiff is committed thediff will become a lot easier for people to 
 read and check. I'd like to get adiff in relatively soon.

This causes some breakage in PowerPC but I'm working on it.  Go ahead
and commit and I'll fix PowerPC up after.

-- 
Benno Rice
[EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

FreeBSD/powerpc commit candidate for review

[Benno Rice]

After considration of the last patchset I put up, I decided to get the
stuff in a slightly cleaner condition before I committed.

The results are now at:
http://people.freebsd.org/~benno/commit/powerpc.diff

There's still a lot of commented or #if 0'd out code, but I've cleaned up
a lot of warnings, did a style pass of sorts and also managed to get VM
initialising properly. =)

You can see the current boot messages from my iMac at:
http://jeamland.net/~benno/powerpc-boot.txt

It hangs after the mountroot prompt.

I'd like to commit this around the end of this week.

Replies have been set to go to freebsd-ppc.

-- 
Benno Rice
[EMAIL PROTECTED]

 PGP signature

Re: Patch to allow overriding of nm in lorder, genassym.sh

[Benno Rice]

On Fri, Dec 15, 2000 at 01:09:12AM -0800, Marcel Moolenaar wrote:
 Benno Rice wrote:
  
   genassym.sh and lorder.sh are also missing support for the -aout/-elf
   command line option, and this breaks building of kernels in a non-native
   object format.  I think the correct fix is is to set OBJFORMAT before
   running shell scripts that run binary utilities, not to clutter the
   shell scripts with code to select the correct binarary utility.
  
  This doesn't fix my problem though.  The problem I'm facing is that the
  command 'nm' is hardcoded into both genassym.sh and lorder.sh, when I
  need to run 'powerpc-elf-nm'.  Even if we were to move that piece of config
  into OBJFORMAT, it'd still require some kind of magic in the scripts.
 
 Having nm(1) hardcoded is not a problem if you can cross build. I assume
 our toolchain has support for the powerpc and thus will build and
 install nm(1) in the object tree. Yes, if cross building doesn't work
 yet, we're forced to revert to hackery because we don't have sufficient
 flexibility and all we basicly need is a prefix, right? (for example
 "powerpc-elf-" or "ia64-unknown-linux-")

AFAIK, there is no powerpc support in our toolchain yet.  It's on obrien's
todo list (and if it isn't, I'll put it there =)).  As to the use of a prefix,
I just thought it'd be easier to be able to completely override the name of
the binary we're using in the same way that I could do:

setenv CC /usr/local/bin/ultra-funky-c-compiler-pro

and have it work.

-- 
Benno Rice
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Patch to allow overriding of nm in lorder, genassym.sh

[Benno Rice]

On Fri, Dec 15, 2000 at 10:12:05PM -0800, Marcel Moolenaar wrote:
 Benno Rice wrote:
  
  As to the use of a prefix,
  I just thought it'd be easier to be able to completely override the name of
  the binary we're using in the same way that I could do:
  
  setenv CC /usr/local/bin/ultra-funky-c-compiler-pro
  
  and have it work.
 
 But can we not already do:
 
   set path=(/usr/local/ultra-funky-c-compiler-pro/bin $path)
   cc -Oberserk -c foo.c
 
 and have it work?

Not if the binary's not called cc, no.
The nm binary I'm trying to use is called powerpc-elf-nm
I can set CC in my environment to powerpc-elf-gcc and, provided I have my
path set correctly, it works.  I can't do the same with NM.  This is what
my patch addresses.

-- 
Benno Rice
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Patch to allow overriding of nm in lorder, genassym.sh

[Benno Rice]

On Thu, Dec 14, 2000 at 11:18:41PM +1100, Bruce Evans wrote:
 On Wed, 13 Dec 2000, Benno Rice wrote:
 
  Does anyone object to me committing the attached patch?
  
  It basically allows the overriding of nm in lorder(1) and
  sys/kern/genassym.sh using the environment variable NM.
  
  I've been using this locally as I've been building with 'powerpc-elf-nm'
  rather than nm.
  
  Comments?  Objections?  Review? =)
 
 I don't like this much.  I think I would prefer to use an extension of
 OBJFORMAT to control all binary utilites consistently.  Where do you
 set NM and corresponding variables for other binary utilities?

The compilers et al (from what I can see) have an executable prefix (eg
powerpc-elf) compiled in.  This is overridable using things like
GCC_EXEC_PREFIX but using a scheme like this would still require putting
an environment variable into the scripts.  I'm happy to do it this way
if people prefer it though.  I chose the way I did it as it allows people
to set NM in Makefiles and have it used by the scripts in the same way CC
can be set and used.

 genassym.sh and lorder.sh are also missing support for the -aout/-elf
 command line option, and this breaks building of kernels in a non-native
 object format.  I think the correct fix is is to set OBJFORMAT before
 running shell scripts that run binary utilities, not to clutter the
 shell scripts with code to select the correct binarary utility.

This doesn't fix my problem though.  The problem I'm facing is that the
command 'nm' is hardcoded into both genassym.sh and lorder.sh, when I
need to run 'powerpc-elf-nm'.  Even if we were to move that piece of config
into OBJFORMAT, it'd still require some kind of magic in the scripts.

-- 
Benno Rice
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message