[osol-discuss] technical (kernel?) discussion list progress?
Hi All, There was some discussion about having a more technical mailing list/community ala freebsd hackers/lkml/... Was there any progress made on that? I'm definitely interested in discoverying/learning more about the internals of Solaris. thanks, peter ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: RFE: /etc/systemtuneabletosetthedefaultpagesize
Dennis Clarke schrieb: In what sense? It already says "the sun4u architecture doesn't support the 4K blocksize". It simply seems odd to refer to the 4K page size for the non-sun4u hardware when Solaris 10 does not support sun4m or sun4d etc etc. Simply leave the manpage with an 8K page size ( block size ) and leave it at that. Well, there still exists one non-sun4u supported hardware with even gaining popularity: i86pc. I still sometimes create filesystems with -b 4096 -f 512 (my news spool, performance doesn't matter, but size does). But why is UFS in Solaris limited to 8K blocks max? UFS on FreeBSD (even UFS1) uses 16K blocks as default for years. Daniel ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Solaris on Intel Macs??
Juergen Keil wrote: Or I can wait until the grub menu timeout expires. This starts loading the default entry. multiboot and the boot_archive is loaded. Text screen is cleared, , and the system hangs - before printing the "SunOS Release 5.xx" copyright string. A completely wild guess but maybe we got into multiboot's main and got to here: Hmm, I've already tried to search for "gateA20" code in multiboot, but havn't found such a piece of code... http://cvs.opensolaris.org/source/xref/on/usr/src/psm/stand/boot/i386/common/key board.c#kb_init These loops (called via ischar() / getchar() => kb_ischar() / kb_getchar()) look interesting and would hang on systems that don't have a ps/2 keyboard controller, so it could be a problem with the intel macs. But would the kernel call them when it was not started with the "-a" flag? I guess when started with "-a" the kernel would try to read various parameters from the console. Is there any reason to call ischar() / getchar() when "-a" is not passed to the kernel? If this is similiar to a different platform I worked on you might want to try removing the i8042 driver... just a wild guess. peter ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: RFE: /etc/systemtuneabletosetthedefaultpagesize
The filesystems appear to be prepared to handle multiple pages per block but not multiple blocks per page. >>> >>> Hence no 4K blocksize on UltraSPARC. >>> >>> (But even 4K pages with 8K blocks didn't work right on x86, at least) >>> >> >>maybe it is time to update the newfs manpage. For Solaris 10 at least. > > > In what sense? It already says "the sun4u architecture doesn't > support the 4K blocksize". > It simply seems odd to refer to the 4K page size for the non-sun4u hardware when Solaris 10 does not support sun4m or sun4d etc etc. Simply leave the manpage with an 8K page size ( block size ) and leave it at that. The references to frag size of 1K or disks that are 1GB insize seem a little old fashioned. Of historical value only I think. Then again .. I actually managed to create a ZFS filesystem on a 12 year old HP C3010 disk. So .. anything is possible. Just not very reasonable. Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: RFE: /etc/systemtuneabletosetthedefaultpagesize
> >> >>>The filesystems appear to be prepared to handle multiple pages per block >>>but not multiple blocks per page. >> >> Hence no 4K blocksize on UltraSPARC. >> >> (But even 4K pages with 8K blocks didn't work right on x86, at least) >> > >maybe it is time to update the newfs manpage. For Solaris 10 at least. In what sense? It already says "the sun4u architecture doesn't support the 4K blocksize". The x86 issue was fixed before S10 was released. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Solaris on Intel Macs??
> > Or I can wait until the grub menu timeout expires. This starts loading the > > default entry. multiboot and the boot_archive is loaded. Text screen is > > cleared, , and the system hangs - before printing the > > "SunOS Release 5.xx" copyright string. > > A completely wild guess but maybe we got into multiboot's main and > got to here: > Hmm, I've already tried to search for "gateA20" code in multiboot, but havn't found such a piece of code... > http://cvs.opensolaris.org/source/xref/on/usr/src/psm/stand/boot/i386/common/key board.c#kb_init These loops (called via ischar() / getchar() => kb_ischar() / kb_getchar()) look interesting and would hang on systems that don't have a ps/2 keyboard controller, so it could be a problem with the intel macs. But would the kernel call them when it was not started with the "-a" flag? I guess when started with "-a" the kernel would try to read various parameters from the console. Is there any reason to call ischar() / getchar() when "-a" is not passed to the kernel? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: RFE: /etc/systemtuneabletosetthedefaultpagesize
> >>The filesystems appear to be prepared to handle multiple pages per block >>but not multiple blocks per page. > > Hence no 4K blocksize on UltraSPARC. > > (But even 4K pages with 8K blocks didn't work right on x86, at least) > maybe it is time to update the newfs manpage. For Solaris 10 at least. -- Dennis Clarke ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: RFE: /etc/systemtuneabletosetthedefaultpagesize
>The filesystems appear to be prepared to handle multiple pages per block >but not multiple blocks per page. Hence no 4K blocksize on UltraSPARC. (But even 4K pages with 8K blocks didn't work right on x86, at least) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Solaris on Intel Macs??
Juergen Keil wrote: Or I can wait until the grub menu timeout expires. This starts loading the default entry. multiboot and the boot_archive is loaded. Text screen is cleared, , and the system hangs - before printing the "SunOS Release 5.xx" copyright string. A completely wild guess but maybe we got into multiboot's main and got to here: http://cvs.opensolaris.org/source/xref/on/usr/src/psm/stand/boot/i386/common/keyboard.c#kb_init Nice work so far! -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Solaris on Intel Macs??
> > The next try was with more console_putchar calls added to the > > gateA20() code. This narrowed it down to the loop waiting for an > > empty keyboard controller input buffer. > > So how far did you get after that ? Well, it doesn't hang any more after printing "Loading stage2 ", after I added some code [*] to grub's gateA20() function. grub is now able to load and display the menu.lst file and the splashimage. grub reports reasonable base and upper memory. I can type exactly *one* character on the usb keyboard. When trying to read a second character from the keyboard, the system hangs. Or I can wait until the grub menu timeout expires. This starts loading the default entry. multiboot and the boot_archive is loaded. Text screen is cleared, , and the system hangs - before printing the "SunOS Release 5.xx" copyright string. [*] diff -rub ../opensolaris-20060404/usr/src/grub/grub-0.95/stage2/asm.S usr/src/grub/grub-0.95/stage2/asm.S --- ../opensolaris-20060404/usr/src/grub/grub-0.95/stage2/asm.S 2006-04-05 23:28:21.0 +0200 +++ usr/src/grub/grub-0.95/stage2/asm.S 2006-04-10 18:11:44.152925307 +0200 @@ -1787,7 +1787,30 @@ jnz 3f ret -3: /* use keyboard controller */ +3: /* +* try to switch gateA20 using PORT92, the "Fast A20 and Init" +* register +*/ +mov$0x92, %dx +inb%dx, %al + /* skip the port92 code if it's unimplemented (read returns 0xff) */ + cmpb$0xff, %al + jz 6f + + /* set or clear bit1, the ALT_A20_GATE bit */ + movb4(%esp), %ah + testb %ah, %ah + jz 4f + orb $2, %al + jmp 5f +4: and$0xfd, %al + + /* clear the INIT_NOW bit; don't accidently reset the machine */ +5: and $0xfe, %al + outb%al, %dx + + +6: /* use keyboard controller */ pushl %eax callgloop1 @@ -1797,9 +1820,12 @@ gloopint1: inb $K_STATUS + cmpb$0xff, %al + jz gloopint1_done andb$K_IBUF_FUL, %al jnz gloopint1 +gloopint1_done: movb$KB_OUTPUT_MASK, %al cmpb$0, 0x8(%esp) jz gdoit @@ -1820,6 +1846,8 @@ gloop1: inb $K_STATUS + cmpb$0xff, %al + jz gloop2ret andb$K_IBUF_FUL, %al jnz gloop1 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: RFE: /etc/systemtuneabletosetthedefaultpagesize
Hi, Roland Mainz wrote: serious cycles on this though we'd like to, and the folks who were in involved in 64K simply don't have any interest in working on this in the open. Why ? What do they fear ? Being swamped&overburned with too many emails or what ? This is a community -- it's up to them whether they want to participate. The VOP_GETPAGE() and VOP_PUTPAGE() interfaces were added in the page cache unification which I believe (without looking) dates back to SunOS 4.x. The original vnode interface specification from srk was based on the buffer cache. Who or what is "srk" ? Steve Kleiman. Looking at the notes at the end of the paper it says that the architecture was designed by Bill Joy but (I'm told) Steve was the original implementor of the vnode interfaces. The major problem with these interfaces is that they expose PAGESIZE to filesystems. UFS in particuar is problematic because (as I've said before) it assumes that PAGESIZE <= MAXBSIZE. Yes, but in the x86 case we have PAGESIZE != MAXBSIZE so these locations are likely well-known and we do not have to search anymore... The filesystems appear to be prepared to handle multiple pages per block but not multiple blocks per page. The right way to fix this is to refactor the VM/FS interfaces to remove PAGESIZE from them. That work is getting underway now. What about skipping UFS in the initial pass and only concentrate - as Holger Berger suggested - on NFS booting ? That sounds like a fine idea. BTW: Are the ZFS/zfsboot people aware of the problem ? IMO at least the person(s) working on zfsboot should be warned that relying on pagesize for whatever reason may be bad... ZFS doesn't have any of these issues; when Jeff Bonwick started ZFS he knew more about the VM system than most of us did back then, and specifically he realized how broken the VM/FS interfaces are long before we did. One "for instance" is to go look at the ZFS implementation of mmap() and compare it to UFS. UFS has all sorts of horrible deadlocks between mmap() fault-driven file I/O and its other data paths due to the page cache, whereas ZFS does not. ZFS doesn't exhibit similar problems partly because it requires transactional interfaces -- from the time the data is checksummed to when the transaction group is committed the data buffers have to be immutable. Pulling this off with a unified page cache is simply impractical, since every write would require a writers-lock plus a global TLB shootdown to prevent subsequent writes. Modern architectures are capable of copying the data in about 1/10th of the time it takes to make a user-mapped buffer immutable on an MP. Logging UFS also has transactional issues which have been band-aided over leading to locking hell and codepaths so twisted they make my head spin. VOP_GETPAGE() and VOP_PUTPAGE() and their reliance on PAGESIZE lead to a complete lack of transactional semantics which more and more modern filesystems are starting to require. Since extensive file system changes are necessary one way or the other to pull this off, myself and others would prefer to take the tact (since we have to go there eventually ANYWAY) of blowing up VOP_*PAGE(), and introducing a new VOP_IO() interface which does not depend on PAGESIZE at all. Instead of a page_t, it would use a base/bounds pair attached to a different data structure which is associated with the I/O transaction. What about committing the original solution first (excluding UFS (e.g. make UFS module unloadable for now in a 64k kernel) and concentrating on a prototype which can only boot via NFS) ? You're welcome to try to implement partial-page reads and writes in the VOP layer if you want. Myself, I wouldn't waste my time on it. As you can see from the discussion thread I think there is a lot more than throwing the code over the wall, Yes... but at least the hungry wolves can chew on it for some time until complains come back... :-) :) because it implicitly assumes that their approach was the best approach to solving the problem or was even tractable. Ok... I'll try to sync with Holger berger then how to proceed... Sounds good. - Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: C shells
Thanks for all the information to all of you. Does anybody know when Solaris will get the latest tcsh? Current is 6.14.0 and Solaris 10 includes 6.12.0. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Solaris on Intel Macs Petition?
It seems obvious from a previous thread that the idea of that the idea of running Solaris on the Mac Intel is a popular idea among the community. I suggest we encourage Apple to help us make Solaris a reality on Mac Intel hardware. What we could do is create a petition of names that would not only be interested in running Solaris on the Mac but would also be willing to help in the effort in some way. I am really not sure how receptive Apple would be to the idea but we'll never know until we ask, right? Bill rushmores.net This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Solaris on Intel Macs??
Jürgen Keil wrote: The next try was with more console_putchar calls added to the gateA20() code. This narrowed it down to the loop waiting for an empty keyboard controller input buffer. So how far did you get after that ? -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] RFE: New version of |strcat()| ...
> >Note: This extension is already available in Linux - the only thing ToDo >would it to port it to Solaris, write a WideChar version of it and then >propose it to the standard bodies (which ones ?) ... So the Linuxites are willing to implement, non-standard, unsafe functions like stp* but refuse to implement strl*() because you really ought to use memcpy instead? Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Solaris on Intel Macs??
> > It hangs in GRUB's gateA20() subroutine, > > How did you figure it out?!?!?!?! I'd love to know the process you used! By adding "debug printfs" to the grub source code; I used console_putchar(char) calls. And building a custom bootable Solaris x86 CD with the modified boot/grub/stage2_eltorito file. The character printed before the gateA20(1) call in init_bios_info() appeared on the console, the character printed after the gateA20(1) call doesn't appear on the console. The next try was with more console_putchar calls added to the gateA20() code. This narrowed it down to the loop waiting for an empty keyboard controller input buffer. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] OpenSolaris Weekly News #7
Hi, Here's OpenSolaris Weekly News #5. As always feedback, or content [from the missing represented communities] welcome. Glynn == Bernd Schemmer asked [1] if there were any Perl interfaces to SMF. Stephen Hahn replied [2] that it would be a good OpenSolaris project, but mentioned also that it could be possible to use the Visual Panels Java SMF classes with either Jython or Groovy. 1. http://mail.opensolaris.org/pipermail/smf-discuss/2006-April/000483.html 2. http://mail.opensolaris.org/pipermail/smf-discuss/2006-April/000488.html Christine Tran asked [3] whether it was possible to define error states for a service instance. David Bustos replied [4] saying that it would soon be possible with smf_method(5) which allowed a service to deliver a monitor that SMF could use to assess the heath of the service. 3. http://mail.opensolaris.org/pipermail/smf-discuss/2006-April/000492.html 4. http://mail.opensolaris.org/pipermail/smf-discuss/2006-April/000496.html Alan Coopersmith mailed [5] with a list of possible projects regarding the newly released X Server consolidation. 5. http://mail.opensolaris.org/pipermail/xwin-discuss/2006-April/000179.html Stephen Hahn posted [6] the DSCM selection draft, noting that a recommendation to adopt Mercurial [7] as the distributed source code management solution for OpenSolaris. 6. http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html 7. http://www.selenic.com/mercurial/wiki/index.cgi Linda Bernal mailed [8] with a link to the latest OpenSolaris community newsletter for March. 8. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015004.html Max announced [9] that he was holding a Solaris Internals course in San Jose, between 26 and 30th June for anyone interested in kernel source code, mdb, dtrace and other tools. 9. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015029.html Baban Kenkre proposed [10] project Winchester, for schema mapping and Active Directory interoperability. Anand Sekhar proposed [11] project Duckwater, simplified name services management. Nicholas Williams proposed [12] project RENO, aiming to revamp Solaris login infrastructure specifically to provide a link between network authentication frameworks and PAM. 10. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015046.html 11. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015063.html 12. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015087.html Stephen Lau announced [13] that the ON sources for build 37 were now available. He also announced [14] the nightly drop 20060404 included putbacks freeing the ata driver along with a bunch of SPARC drivers, and the demise of DMI. It also included a flagday to support building cleanly with gcc [15] 13. http://mail.opensolaris.org/pipermail/opensolaris-announce/2006-April/000100.html 14. http://mail.opensolaris.org/pipermail/opensolaris-announce/2006-April/000104.html 15. http://opensolaris.org/os/community/tools/gcc/flagday/ Moinak Ghosh announced [16] that BelaniX 4.2 was now available, which was mostly a bug fix release. Joerg Schilling announced [17] that SchilliX 0.5.2 was available, which now included an SVr4 package database so that Blastwave [18] packages could now be installed. 16. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015117.html 17. http://mail.opensolaris.org/pipermail/opensolaris-discuss/2006-April/015121.html 18. http://www.blastwave.org/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: BeleniX 0.4.2 Released
> I am also attaching a screenshot showing how KWord is behaviing > strangely, ie, fonts are shown with a red-colored vertical bar at > the beginning position of each character. (OOps, for some reason > I am not allowed to attach a file.) Assuming that the screenshot is not too large, you could upload it to the BeleniX discussion page here: http://www.genunix.org/wiki/index.php/Talk:Belenix (Free) Registration required! :) Venky. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
