Re: [osol-discuss] SXCE95 extremely unstable on x64 laptop
On Mon, 18 Aug 2008, Patrick Ale wrote: On Mon, Aug 18, 2008 at 10:54 AM, Ghee Teo [EMAIL PROTECTED] wrote: Patrick Ale wrote: Hi, I get random kernel panics when running SXCE 95 with the 64 bit kernel. The panics seem to have to do with reads/writes to disk. I can reproduce the panics every time I try to copy things from/to my USB stick or when I insert my USB wifi stick which is driven by the SUNWrum driver (which writes lts to /var/adm/messages). What file system have you on the USB? I have seen a FAT32 share filesystem causes kernel crashing when copy data to it on an earlier version. Can I see a stacktrace of this please ? Thx, FrankH. I tried ext2fs and FAT32 on my USB stick. But also downloading from sun download center directly to my ZFS pool or UFS filesystem causes panics, again, only with the 64 bit kernel loaded. -- Patrick ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pci driver locking
On Mon, 7 Jul 2008, Siegfried Schmidt wrote: Hi, thanks for your ideas. Normally my transfer of one byte needs about 3 - 4 microseconds (i have mentioned). Sometimes we need up to 50 - 80 microseconds for one byte. So i think other threads or processes gets the cpu and my driver was interrupted. I have done some dtrace tests, but up to now I can't find what happend. Preemption and interrupt is measureable with DTrace, via the sched provider's on-cpu / off-cpu probes. If you see those fire while you're in the 'critical' path in your driver, you know. Also, in S10 / Opensolaris, you can use ::interrupts in mdb and/or the intradm command would allow you to check what other interrupt if any is bound to the CPU you're executing your program on. The intention is to know what happens within such a 50 - 80 microseconds transfer in Solaris and what can we do to eliminate these 50 - 80 us transfers. Have you got any realtime processes running ? In-kernel preemption only happens if there's realtime stuff around. Else, it could be interrupts, but that can be checked via the above. FrankH. sigi This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] ps -ef running really slow on non-global zone
On Mon, 7 Jul 2008, Darren Archibald wrote: Has anyone encountered any issues with the 'ps -ef' command running really slow on a non-global zone ? Th ecommand runs instantly on the global zone, but takes around 1 minute to show all running proccesses on the local zone? Obviously need to do some further investigation, but just wondered if someone had a quick fix. No quick fix, but would you be willing to do a bit of testing to narrow it down ? a) Is there a runtime difference between ps -ef in the local zone, and ps -efz localzoneid in the global zone ? b) Do consecutive ps runs take the same time ? c) truss -Deal ps -ef, what does it show, runtimes of the open/read on /proc/PID/psinfo for both situations, run in global zone and run in local zone ? The intent is to narrow down is this slow in general or just slow on a particular set of processes ? Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pci driver locking
On Sat, 5 Jul 2008, [EMAIL PROTECTED] wrote: Hi, [EMAIL PROTECTED] wrote: On Fri, 4 Jul 2008, Siegfried Schmidt wrote: Hi, I have written a driver for a special PCI Card on Solaris 10, Dual Core 2,4 GHz. The application uses the driver via ioctl to get one byte from the PCI Card. I use ddi_getxx to read the registers of the PCI Card, locked with mutex_enter and mutex_exit. Between ioctl_entry and ioctl_return (within my ioctl-function) the driver must run without interruptions (the PCI Card itself don't use interrupts) by other threads, process, interrupts, timers or other kernel code. How can I do this? (runtime of the ioctl function is about 3-4 microseconds) The only way I see to achieve all of this is to: - use a dedicated CPU - use a dedicated handler thread Using a dedicated handler thread bound to a dedicated CPU means: - that CPU will not participate in interrupt handling - no other process/thread/timer will be scheduled But more practically, disable kernel preemption, kpreempt_disable(), and temporarily disable interrupts, cli(). ddi_enter_critical(9f)/ddi_exit_critical(9f) is the ddi way to do this. max Thanks, the thought went through my mind that there actually was a DDI func for this but hmm, just couldn't remember what it was and my usual method of grep'ing /usr/share/man/man9f/ didn't come up with it either. Thx Max ! FrankH. I don't understand why, if the only thing you need to do is a single ddi_getXX call, you need to have the entire thing locked. Can you explain ? FrankH. Any ideas are welcome... sigi This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OT - [ug-bosug] Open Source, 450 BC
On Fri, 4 Jul 2008, Manish Chakravarty wrote: Please mark such posts [OT] Indeed, not quite sure whether legal code and computer code are related. It's a case for -advocacy mailing lists, I guess. But even then, the Roman law is far from the first one made public. There are things more than a millenium older than that: http://en.wikipedia.org/wiki/Code_of_Hammurabi (Enjoy the discussion elsewhere - [EMAIL PROTECTED] is suggested :) FrankH. Thanks, Manish On Fri, Jul 4, 2008 at 11:37 AM, Sivasubramanian Muthusamy [EMAIL PROTECTED] wrote: According to traditional, semi-legendary historical accounts preserved in Livy http://en.wikipedia.org/wiki/Livy, during the earliest period of the [Romane] Republic the laws were kept secret by the *pontificeshttp://en.wikipedia.org/wiki/Pontifex_Maximus * and other representatives of the patricianhttp://en.wikipedia.org/wiki/Patricianclass, and were enforced with untoward severity, especially against the plebeian http://en.wikipedia.org/wiki/Plebeian class. A plebeian named Terentilius http://en.wikipedia.org/wiki/Terentilius proposed in 462 BChttp://en.wikipedia.org/wiki/462_BCthat an official legal code http://en.wikipedia.org/wiki/Code_%28law%29 should be published, so that plebeians could not be surprised and would know the law. Patricians long opposed this request, but in ca. 450 BChttp://en.wikipedia.org/wiki/450_BC, a Decemvirate http://en.wikipedia.org/wiki/Decemviri, or board of ten men, was appointed to draw up a code. ... The first Decemvirate http://en.wikipedia.org/wiki/Decemvirate completed the first ten codes in 450 BC http://en.wikipedia.org/wiki/450_BC. Here is how Livy describes their creation, ...every citizen should quietly consider each point, then talk it over with his friends, and, finally, bring forward for public discussion any additions or subtractions which seemed desirable. In 449 BC http://en.wikipedia.org/wiki/449_BC, the second Decemvirate completed the last two codes, and after a secessio plebishttp://en.wikipedia.org/wiki/Secessio_plebisto force the Senate to consider them, the *Law of the Twelve Tables* was formally promulgated. The Twelve Tables were literally drawn up on twelve ivory tablets (Livy says bronzehttp://en.wikipedia.org/wiki/Bronze) which were posted in the Roman Forumhttp://en.wikipedia.org/wiki/Roman_Forumso that all Romans could read and know them. - from Twelve Tables http://en.wikipedia.org/wiki/Twelve_Tables, Wikipedia Shouldn't this be considered the origin of Open Source ? -- Sivasubramanian Muthusamy Turiya http://www.linkedin.com/in/sivasubramanianmuthusamy ___ ug-bosug mailing list List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Owner: mailto:[EMAIL PROTECTED] List-Archives: http://www.opensolaris.org/jive/forum.jspa?forumID=54 -- Manish Chakravarty http://manish-chaks.livejournal.com/ -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pci driver locking
On Fri, 4 Jul 2008, Siegfried Schmidt wrote: Hi, I have written a driver for a special PCI Card on Solaris 10, Dual Core 2,4 GHz. The application uses the driver via ioctl to get one byte from the PCI Card. I use ddi_getxx to read the registers of the PCI Card, locked with mutex_enter and mutex_exit. Between ioctl_entry and ioctl_return (within my ioctl-function) the driver must run without interruptions (the PCI Card itself don't use interrupts) by other threads, process, interrupts, timers or other kernel code. How can I do this? (runtime of the ioctl function is about 3-4 microseconds) The only way I see to achieve all of this is to: - use a dedicated CPU - use a dedicated handler thread Using a dedicated handler thread bound to a dedicated CPU means: - that CPU will not participate in interrupt handling - no other process/thread/timer will be scheduled But more practically, disable kernel preemption, kpreempt_disable(), and temporarily disable interrupts, cli(). I don't understand why, if the only thing you need to do is a single ddi_getXX call, you need to have the entire thing locked. Can you explain ? FrankH. Any ideas are welcome... sigi This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] USB drive for Linux - OS migration: file system?
On Thu, 26 Jun 2008, Kristian Rink wrote: Folks; another migration-related question: I do have a fairly well sized USB drive to hold data so far to share between Linux, Windows and OpenSolaris, thus the lowest common denominator (in terms of file systems) being FAT32. Taken into account I do have also to backup a few VirtualBox images (which are larger than FAT32 allows), I will have to reformat this drive anyhow, so my question: What kind of file system would suit best the need of being written to in Linux _and_ read from in OpenSolaris? (This is just for the migration of config and some data indeed, I'll have to go for FAT32 again after for the Windows situations anyhow...). In that case, I'd use star to write directly to the media, i.e. create an empty/unused primary partition on the drive (what'd be /dev/hd.X, 1 = X = 4, on Linux, and /dev/dsk/...p[1-4] on Solaris), and then do: cd /dir-to-backup-from; star cvf /dev/dsk/hde2 . on Linux, and cd /dir-to-restore-in; star xvf /dev/dsk/c...p2 on Solaris to extract it. That's capable of 4GB files, UNIX permissions, long filenames, ... - for a simple data transfer/copy, it's also much faster than FAT32. FrankH. Comments, anyone? TIA and best regards, Kristian -- Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab: [EMAIL PROTECTED] * icq: 48874445 * fon: ++49 176 2447 2771 One dreaming alone, it will be only a dream; many dreaming together is the beginning of a new reality. (Hundertwasser) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] filesync depth
On Tue, 24 Jun 2008, takafumi ashiba wrote: The filesync command has a maximum recursion depth of 20 levels .#*define* MAX_DEPTH 20 /* how deep to recurse */ But, my file server's depth is 30~40 levels. So anyone change max_depth? I would like to be abe to change the depth by command's option. What exactly do you use filesync for, and why are other options such as rsync, cp -rp, zfs send, etc. not applicable ? filesync is not exactly designed for backups, so what are you doing with it ? Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] filesync depth
On Tue, 24 Jun 2008, takafumi ashiba wrote: Hi FrankH, because it's there, Where is rsync in opensolaris ? I searched in /onnv/onnv-gate/usr, but I can't find rsync source. Not in the ON tree, but in SFW. See: http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/rsync/rsync-2.6.9/ OpenSolaris is more than just ON :) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] filesync depth
On Tue, 24 Jun 2008, takafumi ashiba wrote: Thanks FrankH, I hope rsync to move from SFW to ON. joyce200 May I ask why is it important / relevant where the rsync sourcecode is maintained ? SFW, ON, X11, ... - all source repositories, all parts of OpenSolaris. There should be no difference ? Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] cdrw command burning CD
On Wed, 18 Jun 2008, Emmanuel De Paepe wrote:
[EMAIL PROTECTED]:~# cdrw
bash: cdrw: command not found
[EMAIL PROTECTED]:~# echo $PATH
/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/sfw/bin
Why is this not working?
$ pkginfo -l SUNWcdrw
PKGINST: SUNWcdrw
NAME: utility for writing to CD-R/RW and DVD{+-}R/RW disks
CATEGORY: system
ARCH: i386
VERSION: 11.11,REV=2008.03.22.10.56
BASEDIR: /
VENDOR: Sun Microsystems, Inc.
DESC: utility for writing to CD-R/RW and DVD{+-}R/RW disks
PSTAMP: elpaso20080322110021
INSTDATE: Mar 31 2008 04:48
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES:9 installed pathnames
7 shared pathnames
7 directories
1 executables
1 setuid/setgid executables
151 blocks used (approx)
If you don't have that then it's simply not installed (and therefore not
in your path).
FrankH.
Also I tried the graphical interface but received an error back when burning
would start.
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
--
No good can come from selling your freedom, not for all the gold in the world,
for the value of this heavenly gift far exceeds that of any fortune on earth.
--
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] PANIC! mounting cdrom slice on b78
Hi Kyle, given that what happens looks ever-so-slightly different each time, a hardware glitch could be possible; to exclude this, would you happen to know whether these panics occurred before build 78 as well ? If they occur if you use the b77 hsfs module on your post-b78 system ? Does the machine you're using have a history of hardware issues, or other symptoms that'd point at flaky hardware (such as e.g. ZFS block checksumming errors) ? There have been two changes to HSFS in b78 as far as I remember (the readahead speed improvements and the hardlink support), I wouldn't associate either with e.g. screwed vfs linkage (as two of these stacktraces show), but then, stranger regressions have occurred. Can you put the bzip2-compressed crashdumps into some accessible location so that we can have a look ? Have cc:'ed ufs-discuss, as that's often used as discussion forum for legacy filesystems. Thanks, FrankH. On Wed, 11 Jun 2008, Kyle McDonald wrote: And Again. I don't know enough about the panic dumps to say if they're the same or not, but I've been doing (slightly) different things st the time of each panic. Here's the latest dump: # mount -o ro /dev/dsk/c2t0d0s1 /mnt1 Jun 11 17:02:26 Boot ufs: NOTICE: mount: not a UFS magic number (0x6c8) mount: /dev/dsk/c2t0d0s1 is not this fstype # mount -F hsfs /dev/dsk/c2t0d0s1 /mnt1 hsfs mount: /dev/dsk/c2t0d0s1 is not an hsfs file system. # mount -o ro /dev/dsk/c2t0d0s2 /mnt1 mount: /dev/dsk/c2t0d0s2 is not this fstype # bash bash-3.2# mount -F hsfs -o ro /dev/dsk/c2t0d0s2 /mnt1 hsfs mount: /dev/dsk/c2t0d0s2 is not an hsfs file system. bash-3.2# mount -F hsfs -o ro /dev/dsk/c2t0d0s3 /mnt1 mount: /dev/dsk/c2t0d0s3 no such device bash-3.2# mount -o ro /dev/dsk/c2t0d0s3 /mnt1 mount: I/O error mount: Cannot mount /dev/dsk/c2t0d0s3 bash-3.2# mount -o ro /dev/dsk/c2t0d0s4 /mnt1 mount: I/O error mount: Cannot mount /dev/dsk/c2t0d0s4 bash-3.2# mount -f hsfs -o ro /dev/dsk/c2t0d0s4 /mnt1 mount: /dev/dsk/c2t0d0s4 no such device bash-3.2# mount -f hsfs -o ro /dev/dsk/c2t0d0s5 /mnt1 panic[cpu2]/thread=ff02d573d760: BAD TRAP: type=e (#pf Page fault) rp=ff001047d9b0 addr=40 occurred in module genunix due to a NULL pointer dereference mount: #pf Page fault Bad kernel fault at addr=0x40 pid=1172, pc=0xfba81ac3, sp=0xff001047daa0, eflags=0x10207 cr0: 8005003bpg,wp,ne,et,ts,mp,pe cr4: 6f8xmme,fxsr,pge,mce,pae,pse,de cr2: 40cr3: 22cbb9000cr8: c rdi: fbca24e0 rsi:1 rdx:8 rcx:4 r8: fbca26b0 r9:0 rax:0 rbx:0 rbp: ff001047dac0 r10: 270005 r11: 2c r12: 270005 r13: 270005 r14: ff001047db08 r15:0 fsb:0 gsb: ff02d50aaac0 ds: 4b es: 4b fs:0 gs: 1c3 trp:e err:0 rip: fba81ac3 cs: 30 rfl:10207 rsp: ff001047daa0 ss: 38 ff001047d890 unix:die+c8 () ff001047d9a0 unix:trap+13b1 () ff001047d9b0 unix:cmntrap+e9 () ff001047dac0 genunix:vfs_devismounted+23 () ff001047dbd0 hsfs:hs_getmdev+12b () ff001047dc70 hsfs:hsfs_mount+195 () ff001047dca0 genunix:fsop_mount+21 () ff001047de00 genunix:domount+8fa () ff001047de80 genunix:mount+d2 () ff001047dec0 genunix:syscall_ap+8f () ff001047df10 unix:brand_sys_sysenter+1e6 () syncing file systems... done dumping to /dev/dsk/c1t0d0s3, offset 431030272, content: kernel 100% done: 260327 pages dumped, compression ratio 5.74, dump succeeded rebooting... -Kyle Kyle McDonald wrote: It happenned again. Only this time it happenned when I started 'bash' (after failing[no such device] to mount s7 of the same CD.) Here's the panic this time: # mount -F hsfs -o ro /dev/dsk/c2t0d0s7 /mnt mount: /dev/dsk/c2t0d0s7 no such device # bash panic[cpu0]/thread=ff02d58d46e0: BAD TRAP: type=e (#pf Page fault) rp=ff00104e7db0 addr=a occurred in module unknown due to a NULL pointer dereference sh: #pf Page fault Bad kernel fault at addr=0xa pid=1199, pc=0xa, sp=0xff00104e7ea0, eflags=0x10246 cr0: 8005003bpg,wp,ne,et,ts,mp,pe cr4: 6f8xmme,fxsr,pge,mce,pae,pse,de cr2: acr3: 22fd88000cr8: c rdi: ff02d46a9400 rsi: ff030240d040 rdx: ff02d58d46e0 rcx:3 r8: ff02faddc628 r9: ff02faa16708 rax:e rbx: fbc77b90 rbp: ff02d4f7f048 r10: ff02d560c008 r11:0 r12: 4af r13: 2eb r14: ff02d59171f0 r15: ff02d58d46e0 fsb:0 gsb: fbc26770 ds: 4b es: 4b fs:0 gs:
Re: [osol-discuss] [ufs-discuss] PANIC! mounting cdrom slice on b78
On Mon, 16 Jun 2008, Robert William Fuller wrote: [EMAIL PROTECTED] wrote: Hi Kyle, given that what happens looks ever-so-slightly different each time, a hardware glitch could be possible; to exclude this, would you happen to know whether these panics occurred before build 78 as well ? If they occur if you use the b77 hsfs module on your post-b78 system ? Does the machine you're using have a history of hardware issues, or other symptoms that'd point at flaky hardware (such as e.g. ZFS block checksumming errors) ? Did anybody else notice they're all NULL pointer de-references??? It's probably not a hardware problem For example, if it's a memory problem, then you'll often see random pointers, but not 3 NULL pointers in a row They all look, from my first glance, like there's a vfs_t with a NULL vfs_next field around. By the codepath in HSFS, that's impossible if the mount succeeded, but would be normal if it failed. A HW glitch that could cause this would only need to corrupt the return code from mount, register bitflips; You're right that won't be like an obvious HW issue (and a flip of a pointer-with-many-bits-set to a NULL is not how hardware problems usually manifest themselves). I'm not saying it's that. Just saying my mind could come up with a mechanism that'd explain it that way, which is not too-far-off. Wouldn't explain why now, and why only in these codepaths. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [ufs-discuss] PANIC! mounting cdrom slice on b78
On Mon, 16 Jun 2008, Juergen Keil wrote: Robert William Fuller wrote: [EMAIL PROTECTED] wrote: Hi Kyle, given that what happens looks ever-so-slightly different each time, a hardware glitch could be possible; to exclude this, would you happen to know whether these panics occurred before build 78 as well ? If they occur if you use the b77 hsfs module on your post-b78 system ? Does the machine you're using have a history of hardware issues, or other symptoms that'd point at flaky hardware (such as e.g. ZFS block checksumming errors) ? Did anybody else notice they're all NULL pointer de-references??? It's probably not a hardware problem For example, if it's a memory problem, then you'll often see random pointers, but not 3 NULL pointers in a row Yep, I noticed that, too. IIRC a bug like ``kmem_free(NULL, size)'' somewhere in the kernel can have the effect that a subsequent ``kmem_alloc(size, KM_SLEEP)'' somewhere else in the kernel will return with a NULL pointer! (Assuming you run release bits) If this is so, then it's a bug and should be fixed. Quote kmem_alloc(9F): NOTES kmem_alloc(0, flag) always returns NULL. kmem_free(NULL, 0) is legal. That's manpage - consider it a spec ... For that reason I did suggest to Kyle to try to reproduce this hsfs mount panic with kmem heap checking enabled. Add the following line to /etc/system, reboot, retry to reproduce the hsfs mount panic: set kmem_flags=0xf Good idea. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] how to mount my second harddisk with ext3 filesystem
On Thu, 22 May 2008, Jan Friedel wrote: On Thu, May 22, 2008 at 06:00:35AM -0700, elflord woods wrote: hi all i have a toshiba laptop i have two hard disk. used to install linux and disk2 i use for backup files how can i see all the disks on my system ? and how should i go about to mount it ? i plan to mkdir /food but next i dont know which is my second disk in /dev Beside no support for ext2/3 (there is ongoing project for it), use format(1M) to see the disks your system sees and can operate (or `cfgadm -alv`, or ..). To witness, the project is at: http://www.opensolaris.org/os/project/ext3/ FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to get current working directory of the current process in the kernel
On Tue, 20 May 2008, NiuLin wrote: Hello everyone: When I am programming a kernel module for Solaris, I encountered one problem: I cannot get the the absolute path for the current working directory of the current process. In user space, we can do this by calling getcwd(), but this function does not take kernel address as parameter so I can not call it in the kernel. Then how can I getcwd in the kernel? I can get the vnode pointer of the current dir, If there are any some easy ways to convert the vnode pointer to the absolute path name, it's ok too. Use this one: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/lookup.c#vnodetopath FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to get current working directory of the current process in the kernel
On Tue, 20 May 2008, NiuLin wrote: Thanks a lot for your quick reply! Actually, I have found this code already, but as I know, dogetcwd is not exported by the kernel (not found in the include files). How can I call this function? #include /sys/pathname.h for vnodetopath(). FrankH. 2008/5/20 [EMAIL PROTECTED]: On Tue, 20 May 2008, NiuLin wrote: Hello everyone: When I am programming a kernel module for Solaris, I encountered one problem: I cannot get the the absolute path for the current working directory of the current process. In user space, we can do this by calling getcwd(), but this function does not take kernel address as parameter so I can not call it in the kernel. Then how can I getcwd in the kernel? I can get the vnode pointer of the current dir, If there are any some easy ways to convert the vnode pointer to the absolute path name, it's ok too. Use this one: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/lookup.c#vnodetopath FrankH. -- Thanks and Regards, Niu Lin -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to get current working directory of the current process in the kernel
On Tue, 20 May 2008, NiuLin wrote: Thanks! I'm sorry I have missed some information in my original post, I'm writing the module for Solaris 8, I checked the header files of Solaris 8 but cannot find vnodetopath. Which function can I use on Solaris 8? Please ask Sun Developer support for S8, this forum is about OpenSolaris ... FrankH. 2008/5/20 [EMAIL PROTECTED]: On Tue, 20 May 2008, NiuLin wrote: Thanks a lot for your quick reply! Actually, I have found this code already, but as I know, dogetcwd is not exported by the kernel (not found in the include files). How can I call this function? #include /sys/pathname.h for vnodetopath(). FrankH. 2008/5/20 [EMAIL PROTECTED]: On Tue, 20 May 2008, NiuLin wrote: Hello everyone: When I am programming a kernel module for Solaris, I encountered one problem: I cannot get the the absolute path for the current working directory of the current process. In user space, we can do this by calling getcwd(), but this function does not take kernel address as parameter so I can not call it in the kernel. Then how can I getcwd in the kernel? I can get the vnode pointer of the current dir, If there are any some easy ways to convert the vnode pointer to the absolute path name, it's ok too. Use this one: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/lookup.c#vnodetopath FrankH. -- Thanks and Regards, Niu Lin -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- -- Thanks and Regards, Niu Lin -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Need advice to select clustering OS
On Tue, 20 May 2008, Roberto carabajal wrote: Hello: I am new to OpenSolaris.Please, I apologize if my questions are too primitive for advanced users. Before hearing about OpenSolatis I had the idea to use 16 surplus Sun Sparc 10 Stations to implement a Mosix cluster. I would appreciate advice about using these machines to built clusters. Can I use OpenSolaris for this .? Is it better ?. Can I installe OpenSolaris and run other Linux code ?. Are there some tutorials about developing clusters ?. Hmm, Mosix is a dead / discontinued product. Also not sure if the MOSIX patches were ever available for SPARC Linux. They definitely never got ported to Linux 2.6.x hence you'd be stuck with four-year-old kernels and a correspondingly old userland. All of that is off-topic for opensolaris-discuss, though; even the usage of SparcStation-10 is somewhat off-topic because opensolaris does not support the sun4m hardware, if you've got SPARC you need UltraSPARC. You can read a bit about that here: http://www.opensolaris.org/jive/thread.jspa?messageID=10866 That said, wrt. to clustering and OpenSolaris, check out the HA Clustering and HPC (High Performance Computing) communities, you'll find tons of material there: http://www.opensolaris.org/os/community/ha-clusters/ http://www.opensolaris.org/os/community/hpcdev/ Thanks very much. Roberto You're welcome, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] The ZFS inventor and Linus sitting in a tree?
On Mon, 19 May 2008, Joerg Schilling wrote: andrew [EMAIL PROTECTED] wrote: I don't think ZFS being added to Linux will mean Solaris loses an advantage. I think it was probably inevitable that Sun would want ZFS to get the maximum possible distribution across different operating systems. One of the main reasons for opening up Solaris was to reduce the barrier to entry for those wanting to use Solaris. By having ZFS included in other operating systems, the barrier to entry is reduced, since more people will have ZFS skills before they look at Solaris. Clearly there is a down side in that you can use ZFS without using a Sun product, but if this were a problem for Sun then they would not have open sourced Solaris in the first place. This is because, by open sourcing Solaris they make it more likely that Solaris features will be included in other operating systems. Anyway, this talk looks a bit like the case where a boy scout is trying to help an old lady to cross the street while the lady does not like to cross the street at all. Why to probably help people who don't like to get help? I am in fear that Sun spends money on helping Linux to get ZFS while the same money could better help Solaris to implement a decent pcfs or to enhance hsfs. Please, Joerg, let it rest. We have tried (in vain) to get hsfs/pcfs work through in an accelerated internal fashion but that failed, for reasons that I really don't want to go through right now. I admit that I have not exactly put up a stellar performance there and I apologize to you for failing you when acting as internal liason for this. I could have done better, working with other internal stakeholders more intensively than I did. But re-iterating Sun does not want that, Sun prioritizes wrongly, etc. etc. - it doesn't solve the underlaying issue, and it doesn't progress work towards solving these known deficits either. I agree with you that the legacy filesystems in Solaris aren't perfect and deserve some attention. But should that attention really be drawn away from the future, from the key distinguishers of Solaris' technology ? Quite honestly, I'd love to have ZFS on Microsoft Windows ... FrankH. I am in fear that this ends up in a license discussion. I am in fear that someone at Sun is going to give ZFS a less free license than it has now. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] open solaris installed to native linux partition?
On Wed, 14 May 2008, Milan Cermak wrote: Hi Steve. steve wrote: Question 1: I have been searching for information as to weather open solaris will install to a native linux partition, or ext2 file system? Reason is so i can setup to read/write from either linux or solaris. As is, i have only been user of linux for 12mths, so please excuse my ignorance. OpenSolaris doesn't understand ext2/3 partition. It doesn't understart extended partition scheme. It needs one primary partition and will create it's own partition scheme there. Then it will create a filesystem with either ufs or zfs. On the other hand, Linux understands OpenSolaris partition scheme and ufs file system. It can also be made to understand zfs through fuse. Question 2: Will open solaris detect the other os (pclinuxos)? Possibly yes. OpenSolaris will not detect it as a Linux but will ignore it as an unknown partition. That's precise - it will do nothing about it. That in particular means that it doesn't _support_ it in any way either, in particular ... At present i am dual booting from grub (pclinuxos 2008) and have windows xp as the other os. I intend to install to the present ´c´drive (first slice), and understand the bootloader (grub) will be overwritten. OpenSolaris installs GRUB and it can be configured to boot a linux kernel. ... it means that you install OpenSolaris, you'll loose the ability to boot a concurrently existing Linux installation. can be configured isn't quite right - _you_ will have to configure OpenSolaris grub _yourself_ to do this. You don't do it - you loose it. It's not technically difficult, just append the Linux boot entries from the Linux grub's /boot/grub/menu.lst to the one on the Solaris installation. Since you can't read/write any Linux filesystem from OpenSolaris out of the box, it's a good idea to copy the Linux grub/menu.lst onto e.g. a removeable medium (memory stick or such). After installing OpenSolaris and booting into it the first time, use that to get the Linux grub config appended to the Solaris one. On next reboot, you should get your grub menu entries for Linux back. OpenSolaris grub is perfectly capable of booting Linux; the other way round is not true, Linux' grub can't deal with opensolaris (except by chainloading). FrankH. Regards, Milan Cermak -- * There is an ancient curse saying: 'Interesting times on you.' * That's disputed: http://en.wikipedia.org/wiki/May_you_live_in_interesting_times ;-) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] open solaris installed to native linux partition?
On Wed, 14 May 2008, Milan Cermak wrote: Joerg Schilling wrote: Milan Cermak [EMAIL PROTECTED] wrote: On the other hand, Linux understands OpenSolaris partition scheme and ufs file system. It can also be made to understand zfs through fuse. Linux does not support UFS. Linux may have support for a modified UFS that is in use on *BSD since ~ 1994, but this is not complatible with the changes introduced in the main UFS line around 1988. As far as I know, Linux kernel has support for Solaris variant of UFS. I've been using it on my notebook last year. And yes, it's only partial support. Writing is experimental and dangerous. I used just a read-only form. Normal reading of a cleanly-unmounted filesystem will do fine. It's just the edges that will cause problems, things like: - do sparse files work correctly ? - do files that posix_fallocate(3C) was used on work correctly ? - does it deal with the Solaris Multi-TB UFS extension ? - does it deal with non-clean filesystems that use logging ? - can it handle filesystems that went through growfs(1M) ? - can Linux access e.g. a SVM metadevice with a UFS on it ? - can you access/honour UFS ACLs ? xattrs ? If all you want is a small filesystem to export a bit of data from Solaris to Linux, it's ok. But Linux UFS support (in all variants) was and is labeled EXPERIMENTAL for a reason. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] VirtualBox
On Wed, 14 May 2008, Dennis Clarke wrote: On Wed, May 14, 2008 at 12:56 PM, Mike DeMarco [EMAIL PROTECTED] wrote: Has anyone gotten Virtual box up and running? I have installed the package, but if I try to run it I get: VirtualBox -help Usage: basename string [ suffix ] Unknown application - VirtualBox Usage: basename string [ suffix ] Unknown application - I thought windows had cryptic messages! More info The above messages is from VirtualBox in /usr/bin/ The install put VirtualBox in /opt/VirtualBox if I run /opt/VirtualBox I get: /opt//VirtualBox ld.so.1: VirtualBox: fatal: relocation error: file VirtualBox: symbol _ZTI12QListBoxItem: referenced symbol not found Killed Oh, that is ugly. Looks like the binary was compiled on a higher/other rev of Solaris and now you can not run it on some other version. That does not normally happen unless someone stepped outside of the rules. Hmm, not sure on that. The symbol above missing to me looks like the Qt library (that the virtualbox GUI wants) is missing, and/or not in the path where the linker is looking for it. The symbol is just a mangled C++ name: /share/SUNWspro_all/i386/latest/SUNWspro/bin/dem _ZTI12QListBoxItem _ZTI12QListBoxItem == typeinfo for QListBoxItem What does 'ldd' say on your virtualbox binary - does it find everything ? FrankH. What rev of Solaris are you trying this with? Just report what uname -a says Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] lookuppnvp:: i just do not get it...how it get vnode by given pathname?
On Wed, 7 May 2008, xulari wrote: hi ,rlhamil : i can dtrace the syscall open, and i come to here : http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/vnode.c#fop_lookup how we get ufs_lookup or #fs_lookup by fop_lookup? int line 3293 : it just call a function pointer... i can't get it... What's unclear about calling through a function pointer ? That's simply OOP with a crowbar - virtual methods in C. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] help me...! system call rename(2)
On Sun, 4 May 2008, leno wrote: mv /export/home/us/oldfile /export/home/us/newfile but rename(2) never update cache path. v_path = /export/home/us/oldfile. help me...,how about update caceh path? Why do you need that ? v_path is _NOT_ the cached path used for name lookups via system call. It's the pathname the vnode had when it was first initialized. Doing a rename() syscall does not preserve that. There's a request for enhancement pending that asks to have rename() update v_path. Question is - what's gained by that, compared to what it will cost to do that ? FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pstack on Solaris 9
On Mon, 21 Apr 2008, Grigoris Beis wrote: Hello everyone, Is there a way to filter out the pstack command so that it does not print the stack output of every thread of my multithreaded application but only of the one thread that crashes every time? For instance, if thread#1 is the one that crashes, how can I isolate the stack output of that thread only using pstack? My multithreaded application runs on Solaris 9. Thank you in advance, Not sure if pstack does that on S9, but you can always move the corefile over to opensolaris and have a look there; the syntax is (example): # pstack 143/25 143:/usr/sbin/nscd - lwp# 25 / thread# 25 fed31b97 nanosleep (fd39df80, fd39df88) 0805cbda reaper (80a4348) + 1ba fed2e652 _thr_setup (fe9cc200) + 52 fed2e8b0 _lwp_start (fe9cc200, 0, 0, 0, 0, 0) nscd on my box has 31 threads, the above shows the stack for the 25th. If you've got a corefile, just pstack core/id will do ? FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How can I tell what kind of blank media is in a CD/DVD recorder before I burn it?
On Wed, 16 Apr 2008, Artem Kachitchkine wrote: Why used second class information from HAL while cdrecord gives you complete and correct information? As always, you are absolutely right, Joerg! It's a bit like a politician's answer to a journalist: After the election, are you going to lower the taxes ? We propose an overall lessening of the financial burden caused by the overboarding of the federal budget in some areas, and in order to achieve that we've come up with a detailed plan outlining both our proposals for securing future funding of crucial operations and our timelines for implementing these changes. Of course we want to make sure that our people will end up having more money for themselves ! Who wants to hear a statement that long ? And by the way, does that actually mean yes ? If you want to hear nothing but yes or no, it's not helpful to be answered in an essay, no matter how complete, exhaustive and verifiable :( FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] opensolaris on a logical partition
On Fri, 11 Apr 2008, Gorky Hasseldorf wrote: Thanks frankho for the reply. It seems this is a difficult task for the moment and people are working on it. I will be in trouble to install it on a logical partition. On this computer, Mandriva 2007, FC6, Windows XP and open SuSE 10.2 work fine. I have created additional partitions. I thought I could install opensolaris on one of the empty partitions. All those partitions are logical ones. Hi Gorky, as mentioned, this is unfortunately not (yet) possible. Solaris right now requires a primary partition. Can you relocate the free space (the empty logical partition) to either the end or the start of the extended partition ? If so, you could shrink it and create a new primary from the freed space, which would allow you to install Solaris. But then, you're using SuSE 10.2 / FC6 ? You might want to try installing OpenSolaris as a Xen domU as both of these Linux distributions include the hypervisor. Yes, it's not directly-on-metal but installing in a virtualized environment allows to bypass the need for a primary partition. We've got a Xen port, it's fully paravirtualized so you don't have a huge speed impact by running it as Xen domU. See the xVM project here: http://www.opensolaris.org/os/community/xen/ and the [EMAIL PROTECTED] forum for help/troubleshooting. Would that be an option ? FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] opensolaris on a logical partition
On Fri, 11 Apr 2008, Gorky Hasseldorf wrote: Is it possible to install opensolaris on a logical partition? The real Solaris needs a primary partition. I have space to install on a logical partition. Please tell me. If you say this is possible, I will download and install it. Depends on finishing this one: http://www.opensolaris.org/jive/thread.jspa?messageID=84316 FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-code] Paging in network driver
On Mon, 7 Apr 2008, Pradeepg wrote: Is it possible to implement page mechanism in Network drivers for allocating DMA buffers ( instead of using ddi functions to allocate DMA buffers) . Is there any sample driver which implemented this in opensource. Thanks in Advance Ramya. Hi Rayma, why do you want to do this, i.e. in which ways are the DDI functions insufficient for your driver ? FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] USB drive unusable (with snv_85)
On Mon, 7 Apr 2008, ChaoHong Guo wrote: Joerg Schilling 写道: Bruno Damour [EMAIL PROTECTED] wrote: hello, I have a USB pen drive, formatted with FAT32. It is working with correct speed under linux, windows, freebsd. I mean I can copy to and from files. In the contrary, it is VERY slow on opensolaris. I mean a transfer of 10 files total 1GB takes around 3 mn on windows and 1 1/2 hour in solaris. Is there any explanation / workaround ? You most likely run USB-1.1 only. You need to check why... Jörg If we follow ufs and zfs, and enable pcfs_getpage() to inline pnv_getpages(), maybe we get better performance ? Or read-ahead before page fault is useful ? pcfs' scaling is negative because of the per-mountpoint lock. I.e. you copy two files at the same time and it'll take longer than to copy them in sequence. You could increase the thoughput for a single copy by implementing readahead. Problem is, pcfs doesn't cache block lists (fat cluster chains) either, so you might still end up with a significant number of fat lookups if the block (cluster) size is less than the MMU pagesize / segmap blocksize (which it often is). From my point of biew, it's easier to write a completely new driver than to try to enhance the existing one. FrankH. -minskey ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] USB drive unusable (with snv_85)
On Mon, 7 Apr 2008, Jürgen Keil wrote: the pcfs driver (fat32 implementation in solaris) is severly limited in its speed, it gives a maximum speed of ~3mb/s, so don't expect to have higher speeds... True, but... 1 Gbyte in 90 minutes is less than 200 kbytes / second. Very fragmented file ? 1GB in one file or 1GB in 10 files, being copied simultaneously ? Both would reduce the throughput with PCFS to far less than the device speed. But Juergen is correct of course, try to see first what your interface gives you when reading / writing raw. That's the benchmark, you can't expect pcfs to beat these numbers - and if they're too low, the first thing to address is why the device doesn't do USB 2 (though it should ?). FrankH. Bruno: is both reading from and writing to the USB drive slow? How much physical memory do you have installed in the machine? Try to read 100mbytes directly from the raw usb storage device, using different block sizes; how long does it take? # ptime dd if=/dev/rdsk/c6t0d0p0 of=/dev/null bs=8k count=12800 12800+0 records in 12800+0 records out real 14.449 user0.039 sys 0.345 # ptime dd if=/dev/rdsk/c6t0d0p0 of=/dev/null bs=32k count=3200 3200+0 records in 3200+0 records out real 11.531 user0.010 sys 0.141 # ptime dd if=/dev/rdsk/c6t0d0p0 of=/dev/null bs=256k count=400 400+0 records in 400+0 records out real 10.706 user0.002 sys 0.085 This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris 10 system hangs
On Fri, 4 Apr 2008, amit yadav wrote: Hi, I've installed Solaris 10 OS patch cluster even then I see the issue i.e. my system is getting hang once I stop my application. Machine info is given below; (root)# uname -a SunOS 5.10 Generic_120011-14 sun4u sparc SUNW,Netra-210 This forum is about opensolaris; can you re-test with a reasonably recent OpenSolaris build, and make a crashdump from that available ? With OpenSolaris' tool set, you cannot even open the Solaris 10 crashdump you're having - it's slightly difficult to help you with S10 issues here. If you've got only one CPU, it's possible to starve the system using realtime threads. How exactly the resulting hang will look like depends very strongly on what your RT processes/threads are doing. Compute-bound RT threads on a single-CPU machine _will_ hang you, so can you be a bit more specific on: - why you use RT - how you use RT - why you think it's an operating system problem Also, generically if this is a need to deploy fast question, is it acceptable to run your software on a multiprocessor machine, within a dedicated processor set (so that it can't starve others) ? And as said, please test on OpenSolaris, Thanks, FrankH. This time i've also taken the crash dump .From crashdump following info I got ; 1)I see the application threads not letting anything else run 2)The system would hang because it cannot run anything other than real time modules. This sys has 1 cpu. As cpu has to run all the 7 real time process first because they have higher priority and as they're waiting. But still I wont able to root caused the exact problem . -Amit - You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] panic[cpu1]/thread=d3738de0: kernel heap corruption detected
Hi Dennis, Best would be not only to boot kmdb, but also to use the -ad boot options to have kmdb prompt you. When unix/genunix is loaded, set kmem_flags to 0xf via kmem_flags/W f That'll allow better diagnosis, see the memory debugging section of the modular debugger guide. Bye, FrankH. On Mon, 4 Feb 2008, Dennis Clarke wrote: With SXCE snv_81 this happens during install. Here are the details : 1. Solaris Interactive (default) 2. Custom JumpStart 3. Solaris Interactive Text (Desktop session) 4. Solaris Interactive Text (Console session) 5. Apply driver updates 6. Single user shell Enter the number of your choice. Selected: 4 Solaris Interactive Text (Console session) Using install cd in /dev/dsk/c0t0d0p0 Using RPC Bootparams for network configuration information. Attempting to configure interface pcn1... Skipped interface pcn1 Attempting to configure interface pcn0... Skipped interface pcn0 Reading ZFS config: done. Setting up Java. Please wait... Serial console, reverting to text install Beginning system identification... Searching for configuration file(s)... Search complete. Sorry, I need to know a more specific terminal type than unknown. Broken Pipe Discovering additional network configuration... Select a Language 1. English 2. French 3. German 4. Italian 5. Japanese 6. Korean 7. Simplified Chinese 8. Spanish 9. Swedish 10. Traditional Chinese Please make a choice (1 - 10), or press h or ? for help: 1 What type of terminal are you using? 1) ANSI Standard CRT 2) DEC VT52 3) DEC VT100 4) Heathkit 19 5) Lear Siegler ADM31 6) PC Console 7) Sun Command Tool 8) Sun Workstation 9) Televideo 910 10) Televideo 925 11) Wyse Model 50 12) X Terminal Emulator (xterms) 13) CDE Terminal Emulator (dtterm) 14) Other Type the number of your choice and press Return: 3 Completing system identification... in.rdisc: No interfaces up then comes the usual sequence ... #9472; Confirm Information for pcn0 #9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472; Confirm the following information. If it is correct, press F2; to change any information, press F4. Networked: Yes Use DHCP: No Host name: titan IP address: 192.168.35.42 System part of a subnet: Yes Netmask: 255.255.255.0 Enable IPv6: No Default Route: Specify one Router IP Address: 192.168.35.1 #9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472; Esc-2_ContinueEsc-4_ChangeEsc-6_Help #9472; Date and Time #9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472; Accept the default date and time or enter new values. Date and time: 2008-02-04 00:21 Year (4 digits) : 2008 Month (1-12) : 02 Day(1-31) : 04 Hour (0-23) : 00 Minute (0-59) : 22 System identification is completed. System identification complete. Starting Solaris installation program... Executing JumpStart preinstall phase... Searching for SolStart directory... Checking rules.ok file... Using begin script: install_begin Using finish script: patch_finish Executing SolStart preinstall phase... Executing begin script install_begin... Begin script install_begin execution completed. #9472; Solaris Interactive Installation #9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472;#9472; On the following screens, you can accept the defaults or you can customize how Solaris software will be installed by: - Selecting the type of Solaris software to install - Selecting disks to hold software you've selected - Selecting unbundled products to be installed with Solaris - Specifying how file systems are laid out on the disks After completing these tasks, a summary of your
Re: [osol-discuss] panic[cpu1]/thread=d3738de0: kernel heap corruption detected
On Mon, 4 Feb 2008, Dennis Clarke wrote: [ ... ] Hi Dennis, Best would be not only to boot kmdb, but also to use the -ad boot options to have kmdb prompt you. I must recall how to do that. I think one must simple edit the GRUB menu.lst entry and specify -kad -B console=ttya or something like that. Yes. When unix/genunix is loaded, set kmem_flags to 0xf via kmem_flags/W f well .. if I look here : panic[cpu1]/thread=d3738de0: kernel heap corruption detected d3738cc0 genunix:kmem_error+416 (6, d3036030, d36f24) d3738cf0 genunix:kmem_slab_free+21a (d3036030, d36f2400) d3738d20 genunix:kmem_magazine_destroy+b9 (d3036030, d459ed80,) d3738d58 genunix:kmem_cache_magazine_purge+8d (d3036030) d3738d78 genunix:kmem_cache_magazine_resize+23 (d3036030, 0, 0, 0, ) d3738dc8 genunix:taskq_thread+176 (d36d8f08, 0) d3738dd8 unix:thread_start+8 () I see kmem_slab_free there and I'm guessing that this page will help: http://docs.sun.com/app/docs/doc/817-2543/modules-24?l=enq=kmem_flagsa=view The dcmd ::kmem_log seems reasonable .. if i can get to that point. Will only tell you what you need if you had kmem_flags set. Are you trying to install a debug build ? If so, kmem debugging active is the case by default. Good luck! FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
On Mon, 28 Jan 2008, [EMAIL PROTECTED] wrote: Hi, [ ... ] Calling lwp_create from a kernel driver will get you into trouble. Why would you want to create an LWP from within a kernel driver ? My present code uses thread_create(). I am seeing kernel panics due to an ASSERT fail in the sfmmu_tsbmiss_exception(). And why do you think that would have anything to do with each other ? If you're looking for something entirely different, the way how to find out which LWP is executing your kernel driver code, use: klwp_t *curlwp = ttolwp(threadp()); Can you clarify what you want to achieve ? If I do this in my thread, I am getting curlwp as NULL. because there is no LWP created when I do a thread_create(). And this sfmmu_tsbmiss_exception() is doing the same thing. 11824 /* 11825 * Must set lwp state to LWP_SYS before 11826 * trying to acquire any adaptive lock 11827 */ Can you explain that sourcecode comment ? It's wrong, but why you think this should be so might give more insight as to what your expectations actually are ? 11828 lwp = ttolwp(curthread); 11829 ASSERT(lwp); // this is causing kernel panic And what is unusual by that ? Not every thread has an LWP, it's pretty normal to see ttolwp(curthread) being NULL. The only thing that tells you is that the currently running thread is not part of any userland process but has been created by the kernel itself, or by some kernel driver. So, to avoid this I was just trying to see if it is possible to use lwp_create(). Creating a kernel thread does not imply that a klwp_t is created. What information from an lwp do you need? If there is no user level, you should not need an lwp. So, why do you think you need one? Seconding Max here - why do you think you need one ? Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
On Mon, 28 Jan 2008, [EMAIL PROTECTED] wrote: [ ... ] My present code uses thread_create(). I am seeing kernel panics due to an ASSERT fail in the sfmmu_tsbmiss_exception(). Can you please post the part of the output of ::msgbuf (from mdb on your crashdump) following the panic[cpu...] line ? I do think you're running way down the wrong track there. You get a trap because of an invalid pointer, that the trap handling mechanism doesn't tell you that clearly but fails somewhere else is more than likely just an artifact. The _real_ meat is elsewhere. when you do crashdump analysis, don't always focus only on the topmost function in a stacktrace. There's more to it than that and the bug you try to track down fix isn't necessarily at the very place where things fall over. Are you willing to share that crashdump with the community ? Thx, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] kernel threads
On Fri, 25 Jan 2008, ramana polamarasetti wrote: Hi, Can anyone tell me what are all the differences between the threads created with thread_create() and those created with lwp_create()? And is there any way to get an lwp, but using thread_create()? Thanks for any help, Ramana Where do you want to create threads ? In you application ? In a kernel driver of yours ? If the former, i.e. you want to use threads in your application, then you're way along the wrong path, check thr_create() resp. pthread_create() instead. If the latter, i.e. you want to create a thread from within your kernel driver, then please consider first whether other asynchronous mechanisms (taskq or timeout) would do instead. The use of threads breaks power management interfaces, and creates difficult-to-deal-with races on driver unloading. In any case, if you have to it's thread_create(). Calling lwp_create from a kernel driver will get you into trouble. Why would you want to create an LWP from within a kernel driver ? If you're looking for something entirely different, the way how to find out which LWP is executing your kernel driver code, use: klwp_t *curlwp = ttolwp(threadp()); Can you clarify what you want to achieve ? thanks, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Sun StorEdge T3B T3+ 2TB volume limit and opening firmware
On Tue, 22 Jan 2008, Mauro Mozzarelli wrote: This has little to do with OpenSolaris, however, having posted this question on forums.sun.com it was suggested to post the issue here. Sun T3 (and 61xx) series storage arrays can be upgraded with any Fibre Channel or FATA drive sizes, however they are afflicted by a 2 terabytes total volume limit. This is because their firmware uses a 12 bytes SCSI CDB (Command Descriptor Block) that prevents from addressing more than 2TB. Apparently Sun does not have any plan to fix this problem, at least for T3, T3+, and 61xx (excluding 6140), because it is seen as an enhancement and Sun only release bug fixes for these products. The fix should be quite simple as it is about using a 16 bytes CDB, however, it requires having access to the firmware source code... Although these arrays are End Of Lined by Sun, there is still a second hand market sustained by the very same people who, financed personally, use inexepensive hardware to contribute to projects like OpenSolaris. Please, could you join me in sending a request to Sun to either fix this issue or open the storage array firmware like they did for solaris? Hm, one of the potential problems there might be that the firmware for those devices possibly has not been written by Sun, but licensed. Don't know this for sure but it would be anything but unusual. FrankH. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Any update on build 79 release
On Mon, 21 Jan 2008, W. Wayne Liauh wrote: -Aubrey Intel OpenSolaris Team ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org What does Intel OpenSolaris Team mean? (Reason I'm asking is that Solaris seems to be better supported on the X3100 chipset--re Lenovo ThinkPad R61i--than Linux.) Should be related to: http://opensolaris.org/os/project/intel-platform/ FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Panic with trap data type: 0x31 (data access MMU miss) in a kernel module
On Fri, 18 Jan 2008, Vamsee Priya wrote: Hi All, I have a kernel module which panics at 2 different places with the following pani message : trap data type: 0x31 (data access MMU miss) When does this kind of a trap occur actually? Under the same circumstances when you get SIGSEGV or SIGBUS in a userland application. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Exceptions in Solaris kernel and filesystem
On Wed, 16 Jan 2008, kanishk wrote: Thank you. I needed some information on what kind of Exceptions can be on the Kernel and Filesystem in Solaris and how to restore them. We're going circles ? What do you mean by exception ? Please give examples. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Exceptions in Solaris kernel and filesystem
On Tue, 15 Jan 2008, kanishk wrote: hi, Can you let me know Exceptions in Solaris kernel and filesystem and how to restore them With the question phrased as broadly as that, I'd recommend: Have a backup ready. Can you please clarify what you mean by exceptions, and what sort of procedure/task you have in mind when you say restore ? Thanks, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSSH and Solaris/OpenSolaris/Indiana
On Mon, 14 Jan 2008, [EMAIL PROTECTED] wrote: It is not impossible at all. Merely improbable. Even with current techniques. So improbable because ( 2^128 - 1 ) = 340282366920938463463374607431768211455 is a staggeringly large number. Even Mathematica takes a pause to factor a number that has prime factors in that scale. But it can be done. Like landing on the moon. No, it cannot; it is even *theoretically* impossible to brute force a password of that length. The universe is just not big enough. When 56 bits keys were introduced they were, perhaps, merely infeasible to crack; but it was known that it was theoretically possible within 10-20 years, hence the design lifetime of DES. (Didn't it expire in the 80s or early 90s?) Possibly in 1984 :) (sorry couldn't resist :) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] *** introductory notes *** [PCFS BUG] date, time and case error + I/O err
Hi Stefano, You've found a new bug ... The foldcase mount option, as explained in the manpage mount_pcfs(1m), should return all filenames as uppercase only. You find that it does not do that for the directory names, in fact it seems to do the reverse there. But in any case, foldcase is not doing what you want. Even fixing the above will not give you the same behaviour as Linux/Windows. That is historical. I don't know if I can somehow have the old ARC case for pcfs' foldcase mount option opened so that you can read up on the story - the behaviour is sort-of cast in stone there (unless someone requests _and_ implements a change). Generically, FAT as a filesystem is _NOT_ case dependent. It does not, by definition, allow filename case as distinguisher. What it shows and what it shows not is therefore, to a degree, irrelevant. The correct behaviour to deal with FAT filesystems would be to implement case-insensitive filename lookups, as per: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6417428 And: http://www.opensolaris.org/os/community/arc/caselog/2007/244/ That'd give you the behaviour you get under Windows - the attempt to open Doc.txt will succeed if there's a DOC.txt or DOC.TXT or whatever combination of upper/lowercase. I have to stress that anything else but that will not give you the semantics that you need to use FAT as generic interchange filesystem, especially since you use it to build software on. And for archiving, you'll never quite get it to work correctly if you rely on filename case. Strangely enough, if you _extract_ and archive with mixed-case short filenames on PCFS on Solaris, the case will be correct on Linux/Windows/Solaris. But that will _not_ be the situation if you extract on Linux/Windows. One could say what Solaris does works on all three of them while what Linux/Windows do does not. Pointing out bugs ... but then, technically the reason for that feature is a bug in Solaris, but it has so nice consequences that we preserve the behaviour ... Sounds horribly incomprehensible ? Oh yes :( As far as the timestamp issue goes - not much I can do there (right now). FrankH. On Thu, 10 Jan 2008, Stefano Spinucci wrote: Doing some tests with OpenSolaris and the foldcase/nofoldcase mount option, I found that: * with the nofoldcase mount option (the default mount option) some short dirs created on windows (and not on linux) are shown upcase, all others files and dirs are shown correctly mixedcase * with the foldcase mount option the behavior is inverted, and some short dirs created on windows are shown lowcase, all other files and dirs are shown upcase maybe the upcase showing of short dirs created on windows in nofoldcase is not a bug but a feature, but I don't understand why only Solaris/OpenSolaris (and not Windows nor Linux) should display those dirs as upcase. furthermore, I guess the foldcase behavior is a bug, as you can see on the attached list of three ls -1R on a test directory. ls -1R on Linux (ubuntu 7.10) with the standard mount option: testdir/linux: Dir.txt File.txt LongDirectory LongFileTxt.txt testdir/winxp: Dir.txt File.txt LongDirectory LongFileTxt.txt ls -1R on OpenSolaris (snv_75) with the standard mount option nofoldcase: TESTDIR/linux: Dir.txt File.txt LongDirectory LongFileTxt.txt TESTDIR/WINXP: Dir.txt File.txt LongDirectory LongFileTxt.txt ls -1R on OpenSolaris (snv_75) with foldcase mount option : testdir/LINUX: DIR.TXT FILE.TXT LONGDIRECTORY LONGFILETXT.TXT testdir/winxp: DIR.TXT FILE.TXT LONGDIRECTORY LONGFILETXT.TXT PS I wrote 2 days ago to Prabahar Jeyar (the engineer who works on 6615883) asking for confirmation that the subtle and potentially damaging date bug 'll be fully resolved in snv_81, but I get no reply. Meanwhile, be careful considering a FAT32 filesystem useful to be interoperable between OpenSolaris and Linux/Windows, because when copying a file from a FAT32 disk the new file access and modify date is incremented by 1 day, and when writing a file to a FAT32 disk also the change date is incremented by 1 day. bye --- Stefano Spinucci Hi, already replied to the same posting from Stefano. These are known: a) case is not a bug - see foldcase mount option. b) The time difference is 6615883 c) The I/O error is very likely 6587983. No need to log new bugs. Thanks, FrankH. On Sat, 5 Jan 2008, Stefano Spinucci wrote: *** introductory notes *** message posted on opensolaris-discuss and opensolaris-bugs the following bugs are tested with solaris, opensolaris, linux and windows, on an manually mounted internal FAT32 disk and an automatically mounted external FAT32 key; solaris is SunOS solaris-devx 5.11 snv_70b i86pc i386 i86pc, opensolaris is SunOS opensolaris 5.11 snv_75 i86pc i386 i86pc Solaris, linux is Ubuntu 7.10, windows is Windows XP SP2. *** first bug: LAST MODIFICATION DATE/TIME
Re: [osol-discuss] Kernel Panic with sfmmu_tsbmiss_exception+0x54() in stack trace
On Wed, 9 Jan 2008, Vamsee Priya wrote: Hi All, We have a kernel module called IPFS which lies in between VFS and UFS. We are getting a kernel panic (with the following stack trace) very frequently on ATCA blades where as the panic is almost rare on CPCI blades. Hi Vamsee, Are you willing to share the sourcecode for that driver ? Are you considering an OpenSolaris project for this ? Generically, filesystem filter drivers on Solaris are unsupported - you're doing something there that the filesystem framework is not designed to deal with. That doesn't mean it's impossible to do, but honestly, makes it difficult to advise if there are no sources to look into. Below, you're trying a VOP_READ() operation on a vnode bound to a fifo, and hence that ends in strread(); need the crashdump to tell you more about where exactly the invalid pointer comes from. Given that you say you're trying to interpose on top of UFS, that you end up attempting to read from a stream seems unexpected/undesired. Most likely you missed a VN_HOLD() where you first picked up a reference to that vnode, and later the vnode that at one point in time might've been UFS got released and reused (for a fifo not a file). As far as crashdump analysis on SPARC goes: There's an old book (now out of print but still available 2nd hand via e.g. Amazon), called Panic !. It's quite outdated regarding the dump analysis techniques but covers the SPARC architecture (assembly language, register windows) well enough. There are also courses on it - Max Bruning, who posts on mdb-discuss every now and then, for example, teaches a good one. Have you tried to talk to your local OpenSolaris users group (see the references on the website at http://opensolaris.org/os/community/advocacy/usergroups/ug-leaders/) ? It's possible to set something up, usually only a question of who covers the costs :) FrankH. sfmmu_tsbmiss_exception+0x54(2a1038555a0, 42001, 31, 0, d5b28, 6001e6d0800) ktl0+0x64(60008a47564, 42f98, 1, fff8, 1e5b76, 1) uiomove+0x90(60008a4755c, 8, 0, 2a103855950, 0, 8) struiocopyout+0x38(60008cf2fc0, 2a103855950, 2a103855864, 0, 60008a47564, 1) strread+0x4b4(0, 2a103855950, 0, 6001f93fd28, 0, 0) ipfs_in+0x1e8(0, 30022006540, 6001f93fd28, 8, 2a103855ab0, 0) ipfs_active_in+0xec(60005e8c000, 30022006540, 3001f1f5ec0, 60011bc6000, 0, 60005e8c0d8) thread_start+4(60005e8c000, 0, 0, 0, 0, 0). When can this sfmmu_tsbmiss_exception occur? Thanks in advance Regards, Priya -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [PCFS BUG] date, time and case error + I/O error on a good file
Hi Stefano, these are known. a) case wrong is actually not a bug. Solaris shows you what's really stored on the medium. Windows and Linux, by default, print filenames in lowercase even if they're actually stored in uppercase on disk (which they will be for names that fit into the old DOS-style 8.3 name scheme). To force Solaris to show this behaviour, mount the medium with the foldcase mount option - see mount_pcfs(1M) or pcfs(7fs) manpages. b) The time off by one hour (you're on central european time) is known, that's an oversight of the timezone mount option changes that I did last August, at the moment OpenSolaris' pcfs will report you timestamps in GMT only. Someone else may be able to tell you if there's a schedule for that fix to go out. Reference: http://bugs.opensolaris.org/view_bug.do?bug_id=6615883 c) The I/O error on good file is, in all likelihood, bug 6587983 (PCFS pc_validcl() check is incorrect / too restrictive after fix for 5047630) http://bugs.opensolaris.org/view_bug.do?bug_id=6587983 Help with PCFS ? God knows. FrankH. On Sat, 5 Jan 2008, Stefano Spinucci wrote: *** introductory notes *** the following bugs are tested with solaris, opensolaris, linux and windows, on an manually mounted internal FAT32 disk and an automatically mounted external FAT32 key; solaris is SunOS solaris-devx 5.11 snv_70b i86pc i386 i86pc, opensolaris is SunOS opensolaris 5.11 snv_75 i86pc i386 i86pc Solaris, linux is Ubuntu 7.10, windows is Windows XP SP2. *** first bug: LAST MODIFICATION DATE/TIME AND CASE WRONGLY SHOWN ON FILE READ *** description: - on solaris a lowcase file is shown as upcase + the date is incremented of 1 day - on opensolaris a lowcase file is shown as upcase + the date is incremented of 1 day and 1 hour listing the same directory on linux, windows, solaris and opensolaris: ### linux: date ok, time ok, case ok total 12 drwx-- 2 ste root 4096 2008-01-05 15:29 . drwx-- 7 ste root 4096 2008-01-05 16:38 .. -rwx-- 1 ste root 3399 2008-01-03 17:45 solaris ### windows: date ok, time ok, case ok 05/01/2008 11.29DIR . 05/01/2008 11.29DIR .. 03/01/2008 17.45 3.399 solaris ### solaris: date wrong, time ok, case wrong total 23 drwxrwxrwx 1 ste staff 4096 Jan 6 14:45:50 2008 . drwxrwxrwx 1 ste staff 4096 Jan 2 00:00:00 1980 .. -rwxrwxrwx 1 ste staff 3399 Jan 4 17:45:36 2008 SOLARIS ### opensolaris: date wrong, time wrong, case wrong total 12 drwxrwxrwx 1 ste staff 4096 Jan 6 2008 . drwxrwxrwx 1 ste staff 4096 Jan 5 16:11 .. -rwxrwxrwx 1 ste staff 3399 Jan 4 18:45 SOLARIS *** second bug: A FILE CREATED IN DAY 'N' HAS MODIFY DAY 'N+1' AND IF COPIED WITH RSYNC HAS MODIFY DATE 'N+2' *** description: - a file created today is written with date tomorrow; copying the same file with rsync --times some seconds after the creation the date of the copied file is incremented of 2 days from today the script I used to test the bug with rsync: ### script to be executed on a FAT32 formatted disk. ### the sleep is needed to let the bug manifest himself ### ### note that the current date is 2007-1-5, the file is created with date ### 2007-1-6 and rsync copied with date 2007-1-7 # date Sat Jan 5 15:21:31 CET 2008 [ ! -d testdir ] mkdir testdir [ ! -d testdir.bak ] mkdir testdir.bak # echo xyz testdir/testfile # stat testdir/testfile File: `testdir/testfile' Size: 4 Blocks: 1 IO Block: 4096 regular file Device: 1981010h/26742800d Inode: 1711135027 Links: 1 Access: (0777/-rwxrwxrwx) Uid: ( 101/ ste) Gid: ( 10/ staff) Access: 2008-01-06 15:21:30.0 +0100 Modify: 2008-01-06 15:21:30.0 +0100 Change: 2008-01-06 15:21:30.0 +0100 # sleep 2 # rsync --times testdir/* testdir.bak/ # stat testdir.bak/testfile File: `testdir.bak/testfile' Size: 4 Blocks: 1 IO Block: 4096 regular file Device: 1981010h/26742800d Inode: 1711135157 Links: 1 Access: (0777/-rwxrwxrwx) Uid: ( 101/ ste) Gid: ( 10/ staff) Access: 2008-01-06 01:00:00.0 +0100 Modify: 2008-01-07 15:21:30.0 +0100 Change: 2008-01-07 15:21:30.0 +0100 *** third bug: I/O ERROR ON A GOOD FILE *** a file, correctly read (with md5sum) by linux and windows shows the following error on solaris and opensolaris: # md5sum /media/lap0-iop/mydocuments/it.repo/office/ooo/docs/0200WG-WriterGuide.pdf md5sum: /media/lap0-iop/mydocuments/it.repo/office/ooo/docs/0200WG-WriterGuide.pdf: I/O error *** final notes *** I'm a former fulltime linux user, willing to use linux as a desktop and solaris as my file server. Please let me know if I can do something to help further with those bugs... bye --- Stefano Spinucci This message posted from opensolaris.org
Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlockedonSolarisx86machine
Try to run this on OpenSolaris, not on something older. The advantages are: - the failure mode below doesn't exist in OpenSolaris (check the code - you won't find that ufs_fault call anymore) - you can DTrace on function arguments easily (ok, that's on S10 as well) - you get function arguments even in a kernel crashdump just by frameptr$C. For S10, the strategy how to pry func arguments out of kernel stacks is outlined in this piece: http://opensolaris.org/os/community/documentation/files/book.pdf Read chapters 3 and the examples 6/7. Best wishes, happy new year ! FrankH. On Thu, 3 Jan 2008, Vamsee Priya wrote: Hi Thanks a lot for your helpI could find the bug in my programI corrected one of the data types and everything worked fine I have a kernel module which uses this user program...I am getting a panic with the following stack trace. Jan 3 10:42:16 upsuite1 genunix: [ID 938853 kern.notice] ufs_dirremove: namlen == 0 Jan 3 10:42:16 upsuite1 genunix: [ID 938853 kern.notice] ufs_dirremove: namlen == 0 Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe8000851770 genunix:vcmn_err+13 (fe80008517a0, 8) Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe80008517a0 ufs:real_panic_v+120 () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe80008517f0 ufs:ufs_fault_v+b6 () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe80008518d0 ufs:ufs_fault+9b () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe80008519a0 ufs:ufs_dirremove+245 () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe8000851a10 ufs:ufs_rmdir+ad () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe8000851a20 genunix:fop_rmdir+e () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe8000851a20 genunix:fop_rmdir+e () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe8000851ae0 ipfs:ipfs_lose+36d () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe8000851de0 ipfs:ipfs_ioctl+2075 () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe8000851df0 genunix:fop_ioctl+b () Jan 3 10:42:16 upsuite1 genunix: [ID 655072 kern.notice] fe8000851ed0 genunix:ioctl+ac () When does name length for ufs_rmdir comes as zero? I tried to print in some statements to get what is the actual name and length. But I don't get them printed Thanks Priya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, December 27, 2007 2:48 PM To: Vamsee Priya Cc: [EMAIL PROTECTED]; opensolaris-discuss@opensolaris.org Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlockedonSolarisx86machine Hi I have tried LD_PRELOAD and UMEM_DEBUG with my program on Sparc. Everything worked. I also am unable to find any bug in my program. No clue as to who is the culprit.. You will need to go over your code and check it carefully. Something is copying a few extra bytes into a structure. (Note that structures aligments and sizes are different in x86 (smaller) and that therefor overruns which happen on x86 may not happen on SPARC. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlockedonSolarisx86machine
On Thu, 27 Dec 2007, Vamsee Priya wrote: Hi I have tried LD_PRELOAD and UMEM_DEBUG with my program on Sparc. Everything worked. I also am unable to find any bug in my program. No clue as to who is the culprit.. Are you willing to share the coredump, and/or the application sourcecode (for the function active_out to start with) ? Thx, FrankH. Thanks Priya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 6:52 PM To: Vamsee Priya Cc: [EMAIL PROTECTED]; opensolaris-discuss@opensolaris.org Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlockedonSolarisx86machine On Wed, 26 Dec 2007, Vamsee Priya wrote: Hi, From the umem_status I too agree that some thing in my program corrupted the memory. I am working on as to what caused the problem. The same program works fine always in SPARC platform. Why is it that it is causing problems on x86 architecture only? There are differences between CPU architectures that go beyond this is 32bit this is 64bit. Again, data structure alignment/padding rules and operand sizes come to mind. Have you ever run your program on SPARC with libumem/UMEM_DEBUG ? It might well fail in the same way (under memory debugging). As said, whether a bug such as this causes a program failure or not depends - on how lucky you are :) From the stacktraces you have, the function active_out() is the place to look. You allocate a piece of memory there, do something with it and in the process of that overwrite the buffer beyond its end, and then you try to free it. That's when libumem tells you oh no, not with me ... I know what you did FrankH. Thanks Priya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 6:36 PM To: Vamsee Priya Cc: opensolaris-discuss@opensolaris.org Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked onSolarisx86machine This is the o/p I get with umem_status when I attach mdb to the process running. Status: ready and active Concurrency:0 Logs: (inactive) Message buffer: umem allocator: redzone violation: write past end of buffer buffer=80c7c68 bufctl=80c8ce8 cache: umem_alloc_80 This error basically says: you have allocated an X (= 80 bytes) of memory but you wrote more than 80 bytes in that buffer. The buffer was allocated from this point in your application: previous transaction on buffer 80c7c68: thread=1 time=T-0.000415973 slab=80b8ed8 cache: umem_alloc_80 libumem.so.1'?? (0xfef99a48) libumem.so.1'umem_cache_alloc+0xe1 libumem.so.1'umem_alloc+0x3f libumem.so.1'malloc+0x23 ipfs_diff.exe'get_meta+0x28e--- here ipfs_diff.exe'active_out+0xb5 ipfs_diff.exe'active+0xe0 ipfs_diff.exe'main+0xd59 ipfs_diff.exe'_start+0x80 And was freed here at which point the corruption was detected. umem: heap corruption detected stack trace: libumem.so.1'?? (0xfef96099) libumem.so.1'?? (0xfef98b1c) libumem.so.1'umem_free+0xf6 libumem.so.1'?? (0xfef97c05) libumem.so.1'free+0x14 ipfs_diff.exe'meta_free+0xbf ipfs_diff.exe'active_out+0x44e ipfs_diff.exe'active+0xe0 ipfs_diff.exe'main+0xd59 ipfs_diff.exe'_start+0x80 You could look at the buffer (+ 0t80) and see what was written there. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked onSolarisx86 machine
On Wed, 26 Dec 2007, Vamsee Priya wrote: Hi Apart from the scenario I explained below, I also get a SIGABRT with the following stack trace This is libumem catching a memory error (either a double free or a heap overrun). On this coredump, what'S the output of ::umem_status when you load it in mdb ? FrankH. libc.so.1`_lwp_kill+0x15(1, 6) libc.so.1`raise+0x1f(6) libumem.so.1`umem_do_abort+0x25(9, fefb5000, 804691c, fef98b1c, fefa3ae8, 80aa810) libumem.so.1`umem_err_recoverable+0x46(fefa3ae8) libumem.so.1`umem_error+0x453(1, 80aa810, 80c7c68) libumem.so.1`umem_free+0xf6(80c7c68, 50) libumem.so.1`process_free+0xfd(80c7c70, 1, 0, 80469a8, 805890b, 80c7c70) libumem.so.1`free+0x14(80c7c70, 80c1b48, 0, 80c1b60) meta_free+0xbf(80469f0, 80c1b88, 1, 80a0bd0, 0, 0) active_out+0x44e(6, 8047e1f, 0, 65) active+0xe0(2, 8047e1f, 0, 0, 8046b57) main+0xd59(6, 8047d0c, 8047d28) _start+0x80(6, 8047dd8, 8047df7, 8047dfa, 8047e0c, 8047e1f) Please suggest me as to what can be done to over come these issues. Thanks Priya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vamsee Priya Sent: Wednesday, December 26, 2007 2:48 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: opensolaris-discuss@opensolaris.org Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked onSolarisx86 machine Hi All, Thanks a lot for the responses. I used libumem to find out where the error occurred. But after I set the variables LD_PRELOAD and UMEM_DEBUG, I found that sometimes the SIGSEGV was gone But this process runs on two machines simultaneously and these two machines communicate about the progress of each process. When SIGSEGV is gone (on the machine where it occurs), I find that other machine gets a SIGABRT signal and the generated core dump shows the following info when I use a mdb to see what's happening.( I have set the variables LD_PRELOAD and UMEM_DEBUG on this machine where I get the following core) mdb core mdb: core file data for mapping at fedd not saved: Interrupted system call mdb: core file data for mapping at fede not saved: Interrupted system call mdb: core file data for mapping at fedf not saved: Interrupted system call mdb: core file data for mapping at fee01000 not saved: Interrupted system call mdb: core file data for mapping at fee1 not saved: Interrupted system call mdb: core file data for mapping at fee2 not saved: Interrupted system call mdb: core file data for mapping at feea not saved: Interrupted system call mdb: core file data for mapping at feea5000 not saved: Interrupted system call mdb: core file data for mapping at feeb not saved: Interrupted system call mdb: core file data for mapping at fef76000 not saved: Interrupted system call mdb: core file data for mapping at fef7c000 not saved: Interrupted system call mdb: core file data for mapping at fef8 not saved: Interrupted system call mdb: core file data for mapping at fef9 not saved: Interrupted system call mdb: core file data for mapping at fefb5000 not saved: Interrupted system call mdb: core file data for mapping at fefba000 not saved: Interrupted system call mdb: core file data for mapping at fefd not saved: Interrupted system call mdb: core file data for mapping at fefda000 not saved: Interrupted system call mdb: core file data for mapping at feffa000 not saved: Interrupted system call mdb: core file data for mapping at feffb000 not saved: Interrupted system call mdb: warning: librtld_db failed to initialize; shared library information will not be available Loading modules: [ ld.so.1 ] ::umem_status mdb: invalid command '::umem_status': unknown dcmd name I am not getting as to what can be done further. If I do not set the LD_PRELOAD and UMEM_DEBUG on the machine which has the above core, I find a SIGSEGV similar to the one I reported in my first mail (i.e in _malloc_unlocked() ) function. Please provide me with some inputs as to how can I proceed further? Thanks Priya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, December 24, 2007 6:21 PM To: [EMAIL PROTECTED] Cc: Vamsee Priya; opensolaris-discuss@opensolaris.org Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on Solarisx86 machine On Mon, 24 Dec 2007, [EMAIL PROTECTED] wrote: Hi I don't find a core dump generated when a SIGSEGV is received. I set the LD_PRELOAD variable to watchmalloc.so.1 but could not find the actual place of seg. fault as the core dump file is not generated. (I got the stack trace I pasted when I attached mdb to the process) I don't have a Sun studio compiler to run dbx. Any more tools with which I can debug futher? You can use coreadm to redirect the core someplace. Does your program call chdir()? If so, the core dump will be elsewhere. Note that with watchmalloc.so.1 you will also need to set some
Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked onSolarisx86machine
On Wed, 26 Dec 2007, Vamsee Priya wrote: Hi, From the umem_status I too agree that some thing in my program corrupted the memory. I am working on as to what caused the problem. The same program works fine always in SPARC platform. Why is it that it is causing problems on x86 architecture only? There are differences between CPU architectures that go beyond this is 32bit this is 64bit. Again, data structure alignment/padding rules and operand sizes come to mind. Have you ever run your program on SPARC with libumem/UMEM_DEBUG ? It might well fail in the same way (under memory debugging). As said, whether a bug such as this causes a program failure or not depends - on how lucky you are :) From the stacktraces you have, the function active_out() is the place to look. You allocate a piece of memory there, do something with it and in the process of that overwrite the buffer beyond its end, and then you try to free it. That's when libumem tells you oh no, not with me ... I know what you did FrankH. Thanks Priya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 6:36 PM To: Vamsee Priya Cc: opensolaris-discuss@opensolaris.org Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked onSolarisx86machine This is the o/p I get with umem_status when I attach mdb to the process running. Status: ready and active Concurrency:0 Logs: (inactive) Message buffer: umem allocator: redzone violation: write past end of buffer buffer=80c7c68 bufctl=80c8ce8 cache: umem_alloc_80 This error basically says: you have allocated an X (= 80 bytes) of memory but you wrote more than 80 bytes in that buffer. The buffer was allocated from this point in your application: previous transaction on buffer 80c7c68: thread=1 time=T-0.000415973 slab=80b8ed8 cache: umem_alloc_80 libumem.so.1'?? (0xfef99a48) libumem.so.1'umem_cache_alloc+0xe1 libumem.so.1'umem_alloc+0x3f libumem.so.1'malloc+0x23 ipfs_diff.exe'get_meta+0x28e--- here ipfs_diff.exe'active_out+0xb5 ipfs_diff.exe'active+0xe0 ipfs_diff.exe'main+0xd59 ipfs_diff.exe'_start+0x80 And was freed here at which point the corruption was detected. umem: heap corruption detected stack trace: libumem.so.1'?? (0xfef96099) libumem.so.1'?? (0xfef98b1c) libumem.so.1'umem_free+0xf6 libumem.so.1'?? (0xfef97c05) libumem.so.1'free+0x14 ipfs_diff.exe'meta_free+0xbf ipfs_diff.exe'active_out+0x44e ipfs_diff.exe'active+0xe0 ipfs_diff.exe'main+0xd59 ipfs_diff.exe'_start+0x80 You could look at the buffer (+ 0t80) and see what was written there. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked onSolarisx86 machine
On Wed, 26 Dec 2007, Vamsee Priya wrote: Hi I thought that the bug might be in my program. But everything works fine with 64 bit binaryare there any flags that need to be set/unset while compling? And I reiterate that things worked fine some times with the 32 bit binary also I'd put it that way: sometimes is not exactly an indicator that the program works [ well under all circumstances ]. There are differences between 64bit and 32bit (data structure padding and operand sizes) that might hide a problem in 64bit - for example, if you're overwriting the end of a data structure by two bytes; in 32bit mode, no padding might've been added and you'd corrupt another piece of data that happens to be adjacent in memory. In 64bit mode, padding might add e.g. four bytes at the end of that struct and while you still overflow it, there's no data-in-use being overwritten and the program stays stable. Your program would still have a bug, but unless you create a 32bit version of it, it won't bite. Similar differences can occur if you have a 32bit program on, say, Windows and Solaris - a bug may strike only on one and not on the other, due to differences in data structure alignments and sizes, or due to differences in how e.g. malloc() works. Especially heap overflows and double frees are not fatal at all times, and not always fatal with all malloc implementations. But they're bugs in your program nonetheless. One such is what libumem has caught in the stacktrace you've shown, whether it's an overwrite-past-end or a double free, you'll see from ::umem_status. Ergo: That your program works in one environment is no guarantee that it's bug free. If it falls over, with a different compiler, different OS/rev, faced with different input or linked against different libraries, then first strategy should always be to suspect your own program. Unless you've got the sort of program that has already been tested and validated against literally gazillions of such combinations, and shown to work well - and now you find such a change (e.g. by the OS vendor) breaks it. The vendor of the failing OS will then be highly interested in working with you :) FrankH. Thanks Priya -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 5:59 PM To: Vamsee Priya Cc: opensolaris-discuss@opensolaris.org Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked onSolarisx86 machine Hi Apart from the scenario I explained below, I also get a SIGABRT with the following stack trace libc.so.1`_lwp_kill+0x15(1, 6) libc.so.1`raise+0x1f(6) libumem.so.1`umem_do_abort+0x25(9, fefb5000, 804691c, fef98b1c, fefa3ae8, 80aa810) libumem.so.1`umem_err_recoverable+0x46(fefa3ae8) libumem.so.1`umem_error+0x453(1, 80aa810, 80c7c68) libumem.so.1`umem_free+0xf6(80c7c68, 50) libumem.so.1`process_free+0xfd(80c7c70, 1, 0, 80469a8, 805890b, 80c7c70) libumem.so.1`free+0x14(80c7c70, 80c1b48, 0, 80c1b60) meta_free+0xbf(80469f0, 80c1b88, 1, 80a0bd0, 0, 0) active_out+0x44e(6, 8047e1f, 0, 65) active+0xe0(2, 8047e1f, 0, 0, 8046b57) main+0xd59(6, 8047d0c, 8047d28) _start+0x80(6, 8047dd8, 8047df7, 8047dfa, 8047e0c, 8047e1f) Please suggest me as to what can be done to over come these issues. Fix the bug in your program :-) This is a abort() from libumem which indicates that it found an error in your program. So you need to take the core from SIGABRT and run that with mdb. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] system reboot after panic
This is: 6367349 Panic on port_remove_event_doneq which has been fixed in OpenSolaris about 1 1/2 years ago. Since you're on Solaris 10, any rev released in 2007 has the patch for this integrated. For more details on S10 patch details or when/how fixed in S10, ask the usual support channels ;) Merry christmas, FrankH. On Thu, 20 Dec 2007, Yi Kong wrote: Frank is right. I got this: # echo ::msgbuf | mdb -k /var/crash/unknown/[uv]*2 MESSAGE PCI-device: [EMAIL PROTECTED], ohci1 ohci1 is /[EMAIL PROTECTED],60/[EMAIL PROTECTED] pcisch0 at root: SAFARI 0x1c 0x60 pcisch0 is /[EMAIL PROTECTED],60 NOTICE: ce0: no fault external to device; service available NOTICE: ce0: xcvr addr:0x01 - link up 100 Mbps full duplex NOTICE: ce1: no fault external to device; service available NOTICE: ce1: xcvr addr:0x01 - link up 100 Mbps full duplex sd3 at mpt0: target 2 lun 0 sd3 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 sd4 at mpt0: target 3 lun 0 sd4 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 dump on /dev/dsk/c1t0d0s1 size 2002 MB IP Filter: v4.0.2, running. pseudo-device: devinfo0 devinfo0 is /pseudo/[EMAIL PROTECTED] pseudo-device: pseudo1 pseudo1 is /pseudo/[EMAIL PROTECTED] pseudo-device: fssnap0 fssnap0 is /pseudo/[EMAIL PROTECTED] pseudo-device: ramdisk1024 ramdisk1024 is /pseudo/[EMAIL PROTECTED] pseudo-device: winlock0 winlock0 is /pseudo/[EMAIL PROTECTED] pseudo-device: fcode0 fcode0 is /pseudo/[EMAIL PROTECTED] pseudo-device: lockstat0 lockstat0 is /pseudo/[EMAIL PROTECTED] pseudo-device: vol0 vol0 is /pseudo/[EMAIL PROTECTED] pseudo-device: llc10 llc10 is /pseudo/[EMAIL PROTECTED] pseudo-device: tod0 tod0 is /pseudo/[EMAIL PROTECTED] pseudo-device: lofi0 lofi0 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd0 wrsmd0 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd1 wrsmd1 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd2 wrsmd2 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd3 wrsmd3 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd4 wrsmd4 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd5 wrsmd5 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd6 wrsmd6 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd7 wrsmd7 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd8 wrsmd8 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd9 wrsmd9 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd10 wrsmd10 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd11 wrsmd11 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd12 wrsmd12 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd13 wrsmd13 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd14 wrsmd14 is /pseudo/[EMAIL PROTECTED] pseudo-device: wrsmd15 wrsmd15 is /pseudo/[EMAIL PROTECTED] pseudo-device: rsm0 rsm0 is /pseudo/[EMAIL PROTECTED] pseudo-device: trapstat0 trapstat0 is /pseudo/[EMAIL PROTECTED] pseudo-device: rmcadm0 rmcadm0 is /pseudo/[EMAIL PROTECTED] pseudo-device: tsalarm0 tsalarm0 is /pseudo/[EMAIL PROTECTED] pseudo-device: dtrace0 dtrace0 is /pseudo/[EMAIL PROTECTED] pseudo-device: fbt0 fbt0 is /pseudo/[EMAIL PROTECTED] pseudo-device: profile0 profile0 is /pseudo/[EMAIL PROTECTED] pseudo-device: systrace0 systrace0 is /pseudo/[EMAIL PROTECTED] pseudo-device: sdt0 sdt0 is /pseudo/[EMAIL PROTECTED] pseudo-device: fasttrap0 fasttrap0 is /pseudo/[EMAIL PROTECTED] pseudo-device: pool0 pool0 is /pseudo/[EMAIL PROTECTED] pseudo-device: fcp0 fcp0 is /pseudo/[EMAIL PROTECTED] pseudo-device: fcsm0 fcsm0 is /pseudo/[EMAIL PROTECTED] /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1 (mpt1): Rev. 7 LSI, Inc. 1030 found. /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1 (mpt1): mpt1 supports power management. /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1 (mpt1): mpt1 Firmware version v1.3.24.0 /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1 (mpt1): mpt1: IOC Operational. PCI-device: [EMAIL PROTECTED],1, mpt1 mpt1 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1 /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0 (st10): HP DAT-72 st10 at mpt1: target 3 lun 0 st10 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0 su1 at ebus0: offset 0,2e8 su1 is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED],2e8 PCI-device: [EMAIL PROTECTED], uata0 uata0 is /[EMAIL PROTECTED],60/[EMAIL PROTECTED] sd0 at uata0: target 0 lun 0 sd0 is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0 (st10): HP DAT-72 st10 at mpt1: target 3 lun 0 st10 is /[EMAIL PROTECTED],70/[EMAIL PROTECTED],1/[EMAIL PROTECTED],0 panic[cpu2]/thread=300075ce980: BAD TRAP: type=31 rp=2a100d994c0 addr=0 mmu_fsr=0 occurred in module genunix d ue to a NULL pointer dereference httpd: trap type = 0x31 pid=29966, pc=0x10f2878, sp=0x2a100d98d61, tstate=0x441607, context=0xd4a g1-g7:
Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on Solaris x86 machine
On Mon, 24 Dec 2007, [EMAIL PROTECTED] wrote: Hi I don't find a core dump generated when a SIGSEGV is received. I set the LD_PRELOAD variable to watchmalloc.so.1 but could not find the actual place of seg. fault as the core dump file is not generated. (I got the stack trace I pasted when I attached mdb to the process) I don't have a Sun studio compiler to run dbx. Any more tools with which I can debug futher? You can use coreadm to redirect the core someplace. Does your program call chdir()? If so, the core dump will be elsewhere. Note that with watchmalloc.so.1 you will also need to set some other variables. ... which are, like all good Solaris features, documented in the manpages, watchmalloc(3MALLOC) in that case :) watchmalloc and libumem are somewhat complementary, some problems are easier to track with one some easier with the other. Merry christmas, FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [perf-discuss] how to disable sun cc optimization partly in program?
On Sat, 22 Dec 2007, Minskey Guo wrote:
On 2007-12-22, at 下午9:17, 陶捷 TaoJie wrote:
Hi Bart,
I noticed this email just now :(
Thank you for your advice.
Are there any barrier instructions on x86/x64 could force the rdtsc to
behave sychronously?
iret, xchg, cpuid, sfence, lock, etc. but cpuid changes eax etc, sfence is
not available for all pentium (PIII ???)
We had this discussion with AMD a while ago; if I remember correctly, but
Bart may well step in here, is that the only thing that's guaranteed in
all situations and fully vendor/chip-rev independent is CPUID. Which is
sort of a barrier sledgehammer. Takes thousands of cycles.
Wondering - what _exactly_ are you planning to do ? Instruction-based
sampling can be done via CPU performance monitoring counters, the old
sample time, do something, sample time again is sort-of superseded by
those. High-level access in Solaris would be via the cpc(7d) driver.
FrankH.
My concern is
---
rdtsc
[barrier]
AA
BB
CC
XX
[barrier]
rdtsc
(2nd rdtsc - 1st rdtsc) should be the time cost of these inner
instructions/functions.
And it should be equal to or greater than the actual cost.
Are there any barrier instructions to force rdtsc execute before AA and 2nd
rdtsc execute after XX?
using some continuous nops? or some instrcution else?
sfence
rdtsc
x
sfence
rdtsc
maybe cpuid is available if exa can be corrupted, or you can save it
somewhere before cpuid .
-minskey
Btw, you mentioned you had the experience of performance measuring.
Are there any recommended articles about performance measuring on x86/x64
platform?
Are there any recommended atricles about measuring instrcution cost?
For example, in some books, they said nop costs 1 cycle on Pentium, costs 3
cycle on 386. How to get these precise costs?
Thank you :)
Another question:
In SMP or Multi-core (or say CMT) platform, each processor/core does have
its own tsc register on its chip, doesn't it?
Then, how could gethrtime() guarantee to provide the system-wide time? I
mean if a program runing on CPU1 for a while and then running on CPU2,
would gethrtime() - gethrtime() be the precise time cost? Does gethrtime()
read ticks from CPU's tsc register or read it from system-wide timer( e.g.
8253 chip for x86)?
I'm not familiar with timer... sorry for these stupid questions :-(
Kind Regards,
TJ
2007/10/30, Bart Smaalders [EMAIL PROTECTED]:
?? TaoJie wrote:
Dear all:
My platform is:
Intel Pentium 4 CPU
OpenSolaris B74, built by myself
Sun Studio 11
In my program, I use asm(rdtsc) to measure the time cost between two
rdtsc.
for example:
int some_func(...)
{
long long time1, time2;
int i = 3198, j = 324;
asm volatile(rdtsc : =A (time1));
i = i + j * i / j;
asm volatile(rdtsc : =A (time2))
return i;
}
int main(...)
{
some_func();
}
When I compile this program using cc example.c and disasmble a.out
by dis, the program logic is ok. The output is
some_func()
main+0x36: 0f 31 rdtsc
main+0x38: 89 45 f4 movl %eax,-0xc(%ebp)
main+0x3b: 89 55 f8 movl %edx,-0x8(%ebp)
main+0x3e: 8b 45 e8 movl -0x18(%ebp),%eax
main+0x41: 03 45 e4 addl -0x1c(%ebp),%eax
main+0x44: 89 45 e8 movl %eax,-0x18(%ebp)
main+0x47: 8b 45 e8 movl -0x18(%ebp),%eax
main+0x4a: 0f af 45 e4imull -0x1c(%ebp),%eax
main+0x4e: 89 45 e8 movl %eax,-0x18(%ebp)
main+0x51: 8b 45 e8 movl -0x18(%ebp),%eax
main+0x54: 99 cltd
main+0x55: f7 7d e4 idivl -0x1c(%ebp)
main+0x58: 8b d0 movl %eax,%edx
main+0x5a: 89 55 e8 movl %edx,-0x18(%ebp)
main+0x5d: 0f 31 rdtsc
main+0x5f: 89 45 ec movl %eax,-0x14(%ebp)
main+0x62: 89 55 f0 movl %edx,-0x10(%ebp)
When I compile this program using cc -xO5, the dis output is
some_func()
main+0x7: 0f 31 rdtsc
main+0x9: 89 45 e8 movl %eax,-0x18(%ebp)
main+0xc: 89 55 ec movl %edx,-0x14(%ebp)
main+0xf: 0f 31 rdtsc
main+0x11: 89 45 f0 movl %eax,-0x10(%ebp)
main+0x14: 89 55 f4 movl %edx,-0xc(%ebp)
main+0x17: 8b 5d f0 movl -0x10(%ebp),%ebx
main+0x1a: 8b 45 f4 movl -0xc(%ebp),%eax
main+0x1d: 8b 4d e8 movl -0x18(%ebp),%ecx
main+0x20: 8b 55 ec movl -0x14(%ebp),%edx
main+0x23: 2b d9 subl %ecx,%ebx
Re: [osol-discuss] [perf-discuss] how to disable sun cc optimization partly in program?
On Sat, 22 Dec 2007, 陶捷 TaoJie wrote: 2007/12/22, Frank Hofmann [EMAIL PROTECTED]: On Sat, 22 Dec 2007, Minskey Guo wrote: On 2007-12-22, at 下午9:17, 陶捷 TaoJie wrote: Hi Bart, I noticed this email just now :( Thank you for your advice. Are there any barrier instructions on x86/x64 could force the rdtsc to behave sychronously? iret, xchg, cpuid, sfence, lock, etc. but cpuid changes eax etc, sfence is not available for all pentium (PIII ???) We had this discussion with AMD a while ago; if I remember correctly, but Do you remember the topic of that discussion? Was related to: http://src.opensolaris.org/source/diff/onnv/onnv-gate/usr/src/uts/intel/ia32/ml/i86_subr.s?r1=5322r2=5084 http://src.opensolaris.org/source/diff/onnv/onnv-gate/usr/src/uts/i86pc/os/mlsetup.c?r1=5338r2=5084 Bart may well step in here, is that the only thing that's guaranteed in all situations and fully vendor/chip-rev independent is CPUID. Which is sort of a barrier sledgehammer. Takes thousands of cycles. Because it will takes thousands of cycles? Yes. It takes thousands of cycles, then it will affact the testing result a bit. But it seems a good generic resolution. btw, On P4 and the later Intel platform, which instruction is the best barrier? On AMD Opteron and the later AMD platform, which instruction is? The only one that allows serialization even for instructions that do not access memory is cpuid. All else (mfence and varieties, iret) have cornercases where they may not serialize [on all cpu varieties]. The source above should give you some more details. Wondering - what _exactly_ are you planning to do ? Instruction-based sampling can be done via CPU performance monitoring counters, the old sample time, do something, sample time again is sort-of superseded by those. High-level access in Solaris would be via the cpc(7d) driver. OK, I'll try to find some articles about performance monitoring counters and the cpc driver in Solaris to read. Start with the source and with this one: http://docs.sun.com/app/docs/doc/816-5172/6mbb7btcs?a=view A program, I want to analysis its detail behavior. In a word, I want to know the time cost of any sub-flow on the whole program flow. Suppose the program flow is a long vertical line like *main* *func1 * *func2 * *func3 * *some key instructions in func3 (record it as #1)* *func4* *func3* *func2 * *func1 * *some key instructions in func1 (record it as #2)* *exit in main* Again, see source above. Or, rather, try using CPC, and/or DTrace's timestampers. If it's your own sourcecode, userland SDT probes might give you the necessary sampling hooks as well. I'm interested in func4 takes how much time? #1 takes how much time? #2 takes how much time? control transfered from func2 to func3 (this is a function call) takes how much time? during func4, this program may be interrupted by some event, if so, it takes how much time? and it spends how much time to re-gain the CPU if not, that's all right. To this problem, are there any good suggestions? If the time involved in all these samples is _not_ microscopic, then DTrace's sampling might well tell you. If it is microscopic, though, then CPC (or even your own use of CPU performance monitoring facilities, to avoid a kernel driver overhead) might become necessary. Correctly sampling micro-events is a hard task, and I'm not aware of a generic good suggestion. Have a great weekend, FrankH. Kind Regards, TJ FrankH. My concern is --- rdtsc [barrier] AA BB CC XX [barrier] rdtsc (2nd rdtsc - 1st rdtsc) should be the time cost of these inner instructions/functions. And it should be equal to or greater than the actual cost. Are there any barrier instructions to force rdtsc execute before AA and 2nd rdtsc execute after XX? using some continuous nops? or some instrcution else? sfence rdtsc x sfence rdtsc maybe cpuid is available if exa can be corrupted, or you can save it somewhere before cpuid . -minskey Btw, you mentioned you had the experience of performance measuring. Are there any recommended articles about performance measuring on x86/x64 platform? Are there any recommended atricles about measuring instrcution cost? For example, in some books, they said nop costs 1 cycle on Pentium, costs 3 cycle on 386. How to get these precise costs? Thank you :) Another question: In SMP or Multi-core (or say CMT) platform, each processor/core does have its own tsc register on its chip, doesn't it? Then, how could gethrtime() guarantee to provide the system-wide time? I mean if a program runing on CPU1 for a while and then running on CPU2, would gethrtime() - gethrtime() be the precise time cost? Does gethrtime() read ticks from CPU's tsc register or read it from system-wide timer( e.g. 8253 chip for x86)? I'm not familiar with timer... sorry for these stupid questions :-( Kind Regards, TJ 2007/10/30, Bart Smaalders
Re: [osol-discuss] help - coredump third party app developer is blaiming O/S
On Wed, 19 Dec 2007, UNIX admin wrote: [ ... ] When I see something like that, I go through the roof. Probably because I experience it every day, so I've grown extremely sensitive to it. You wanted to help. The other guy was just trying to put the blame on someone else hoping that the problem would go away. I agree with you there. I only posted a followup to explain a bit where this sort of behaviour comes from. I'm actually pretty disillusioned about this analytical troubleshooting stuff. What the advocates thereof miss to state is that _NOT_ everyone can be made into a good troubleshooter by virtue of a managemented process for how to perform troubleshooting - and that really good troubleshooters actually employ such techniques without having to force themselves into the corset of a process either. But then, if the boss (who makes the training + process mandatory) and the salesperson (who wants to cash in on the comission for the training sale) agree that it's a good thing, then it will be _made_ into a good thing. At all costs [ which won't reflect in this boss' budget ] ... You've pretty much shown already how good troubleshooting works - ask all the time what else can I find out [ before asserting blame ] ?. That is, as I called it earlier, optional thinking. If one wants to, one can find it in the abovementioned process, but I've _never_ seen it mentioned / taught as the key deciding element in properly doing it. All that's being taught is the procedure to follow. Unfortunately, all the goal-oriented and process-focussed behaviour at work often discourages or sometimes even punishes optional thinking and inquisitiveness. If all the worker has is a direction don't spend more than X minutes on it - get it off your desk and this is how, and that worker is a procedural person, they will just execute. Get it off their desk, no matter what. If your boss gives you pushback for having spent too much time analyzing instead of helping the customer, do you have the stamina to tell him off [ and get your coat leave ] ? You're right that long-term average, doing technically bad work will have negative effects. But then, who, these days, works to a ten-year vision ? (Merry christmas, in any case !) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] help - coredump third party app developer is blaiming O/S
On Wed, 19 Dec 2007, UNIX admin wrote: Hi, Got an app that coredumps and the app developer is blaming the O/S install as the problem. This is the truss output (last part shown): Incurred fault #6, FLTBOUNDS %pc = 0x0001C88C siginfo: SIGSEGV SEGV_MAPERR addr=0xFF2707B0 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0xFF2707B0 is is the pstack output: Look, right there your can see that the crash has been caused by a SEGV, which is a segmentation fault. As soon as you see that, it's game over: what it means is that a piece of code tried to access an address outside of his process space. This usually happens with pointers, often when a function accesses a struct which either contains a bogus value, or a NULL pointer. So either the developer of the app is not very savvy with programming on UNIX(R), or they're giving you a bunch of bulls**t to get rid of you in a convenient way. That's a bit harsh. Maybe the developer simply has _learned_ to develop and troubleshoot in this way: - if it happens on platform X but not on platform Y, what's the conclusion ? platform X has a problem Sounds strange to act like this ? Well - check, for example: http://www.itsmsolutions.com/newsletters/DITYvol2iss24.htm It's being taught that way. Particularly if people don't understand all of the methodology, but focus on the 'single steps', i.e. rip the questions out of context. Which, as the above shows, is all too common. Why does that happen ? Personality profiling often ends up categorizing people into procedural and optional behaviour patterns wrt. to how they work. The former will follow checklists, such as the example just shown, and are very prone to strongly believe argumentation as just shown is actually technical. The latter will be horrified by that and say need more info / looking into before asserting any blame. Who makes a better programmer ? Good question. I know many procedural people who churn out code at 20x as fast as I could... Vendors like finger pointing, but all that does is make them lose business... Not necessarily. This sort of behaviour is normal. That's why I gave an extensive answer. All shown so far points towards an application bug, but then if more information surfaces that'd show Solaris did something wrong which surprised the application - fine, I'll investigate then. Just so far, no such information has been forthcoming. They might already have found their bug :-) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] help - coredump third party app developer is blaiming O/S
On Tue, 18 Dec 2007, Wayne Farris wrote: Hi, Got an app that coredumps and the app developer is blaming the O/S install as the problem. This is the truss output (last part shown): [ ... ] Incurred fault #6, FLTBOUNDS %pc = 0x0001C88C siginfo: SIGSEGV SEGV_MAPERR addr=0xFF2707B0 Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0xFF2707B0 This is the pstack output: m0072057_wmc:pstack core core 'core' of 22652: qlsc list -a wmc -q 8 0001c88c IDtoPATH (ffbfda30, 112, ff2707ac, ff3806ec, 278d, de9) + 14 0001c390 openMsg (ff1866c0, 112, 46800, 336, 30578, ffbfda30) + 15c 00013228 qlist(ffbfdc68, 0, 1, ff17, 80808080, 77148) + 304 00012b18 main (58c, 14, 12000, 76b70, 1, 32e68) + 780 00011f48 _start (0, 0, 0, 0, 0, 0) + 108 m0072057_wmc: Can anyone here tell me if these outputs contain any hints as to what might be the problem? This is Solaris 10 and the main difference between our server and the application developers is the level of the kernel patches (ours is later than theirs). Yes, the function IDtoPATH(), part of this application, accessing its third argument, ff2707ac at offset 4 within whatever it expects this data structure to be, and finding that this address is invalid. Bad pointer, one would say. From a programmer's point of view, openMsg() called IDtoPATH() and passed an invalid pointer to that function. Hence it crashes. I do not see where one could blame Solaris from that. It's all within application code, the whole sequence from: main()-qlist()-openMsg()-IDtoPATH() Please ask them if they are willing to share: - the sourcecode for their app - the coredump from that app crash - comments / analysis logs/reports they've created so far ? all that could help pinpointing what goes wrong. Thanks, FrankH. Wayne This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] system reboot after panic
On Mon, 17 Dec 2007, Yi Kong wrote: My Sunfire V440 rebooted with error: www savecore: [ID 570001 auth.error] reboot after panic: BAD TRAP: type=31 rp=2a100d994c0 addr=0 mmu_fsr=0 occurred in module genunix due to a NULL pointer dereference Dec 12 15:25:43 www savecore: [ID 748169 auth.error] saving system crash dump in /var/crash/unknown/*.2 Any body can help? Please post the full set of panic messages; you can get that as the output of the following command: echo ::msgbuf | mdb /var/crash/unknown/[uv]*2 FrankH. Thanks Yi This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] wanted: way to sync from openboot without crash dump
On Thu, 13 Dec 2007, Richard L. Hamilton wrote: On Thu, 13 Dec 2007, Richard L. Hamilton wrote: Sometimes a large system, despite precautions (or in the absence of them), runs out of resources (VM, mainly) to the degree that no useful progress is being made: that is, one can't even log in and kill the hogging processes. (At least on SPARC) the usual workaround would be to break to the boot PROM and sync; however, this invariably causes a crash dump to be taken. In the Workaround: If you have obpdebug defined, you can do: dumpvp 0 x!; sync at the ok prompt to force skipping the dump. Thanks - _that's_ the sort of thing I was looking for; although it presupposes that obpdebug support is loaded, which I suppose it usually isn't by default. If you know the address of the 'dumpvp' (or 'dumphdr') global, then you can just do addr 0 x!. Have used this technique in the past, equipped with a directory containing a set of kernel patches to look them up. Cumbersome, though. It's possible to code an OBP add-on like the 'sync' command. Search the source for add_vx_handler(), it's technically simple. A point can be made for/against a sparc-only/-specific or generic - via dumpadm - method. But that discussion would be something for ARC-level. [ ... ] Because I'd really rather the buffers got flushed, to minimize data loss? Great if everything was on zfs (and great to ignore SPARC-specific features if you live your life only on x86, I guess). Well, minimize. Thing is, without a recovery/rollback/checkpointing mechanism, you can't really know whether you've lost something, and/or if you've lost something critical. It's like returning from holiday and finding your front door broken. You look inside and nothing _seems_ amiss. But then, do you remember where Granny left her money jar ? I'd think saying rely on sync is the wrong word. It's more like uttering a prayer - calms the soul, and won't do no harm, and there are believers who will strongly claim it did them good. You don't really _know_, though. But there's nothing wrong with a good belief, mind you :) My experience there is rather that if the 'syncing filesystems ...' part works, then the dump will not hang either. They tend to go through the same I/O drivers/devices. In fact, the 'syncing ...' part accesses more I/O devs than the 'dumping ...' part does (the former goes for everything unflushed, while the latter only attempts to get at the dump device). We do have some service documents explaining how to get a dump if the box hangs during 'syncing filesystems ...' - but none to my knowledge that do the opposite. The time the dump takes, though, is known to be high. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nameclash on svn_77 because Sun is ignoring PSARC discussions
On Fri, 14 Dec 2007, Joerg Schilling wrote: [EMAIL PROTECTED] wrote: It's very simple, Joerg, first to integrate wins. WRONG: in the OSS world the first user os a name wins and the imagemagick name is thus illegal. Says who? And who keeps the record or registry? Do you like to ignore that my compare is genric and thus correctly using the name and that it is 20 years older than imagemagick? compare as a word dates back to probably 1000BC when the latin language developed. Its use in english is post-norman, though, being imported from french, but even that makes the english word almost thousand years old. What, except a) that I was tortured with Latin in school, and b) that I can sound quite patronizing if I chose to, does that prove ? Generic words can't be trademarked. That's why everyone can call their stuff Windows, Microsoft lost a corresponding lawsuit a few years ago. You chose a simple english word, you can't claim exclusive rights to it. A prefix/suffix, schily_compare, or at least as you do it with the other utilities that you wrote, scompare, would come closer to trademark-able terms, as Apple/Intel are demonstrating with the iStuff. For name collisions, there's always PATH to sort out your preference. /usr/bin vs. /usr/ucb vs. /usr/xpg4/bin vs. /usr/xpg6/bin comes to mind. The world isn't out there to get you. Really. Btw, PSARC knows something like a minority vote. You can leave a record there saying you disagree with something, and state the reasons. Which is even possible if you're not a voting member. It goes on record and allows you righteousness later, you should've listened see what happened. Whether that's a useful thing to do is another question, but it's really going too far now ... FrankH. Because if Sun does not rename the image magick program Sun verifies that PSARC discussions are just to fool people but do not have useful resaults. Remember Joerg, being listened to is NOT the same as getting your way. It is just another chance to verify that there is collaboration on OpenSolaris and not just ignorant domination from Sun. Do we have an OpenSolaris community or is this just a fake? The real compare is 20 years older and I did _warn_ _before_ the name appeared in /usr/bin. For this reason, this is an important bug in Solaris Express. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Porting a kernel module from Solaris SPARC platform to Solaris X86 platform
On Thu, 13 Dec 2007, Vamsee Priya wrote: Hi I am trying to port a kernel module (which acts as a layer between VFS and UFS) from Solaris sparc platform to Solaris x86 platform. Interesting - which module/product is that ? I am facing many kernel panics happening at different places. Not surprised. Filesystem filter drivers in Solaris are not supported. Rather, there is no framework to create such drivers, and hence writing one necessarily gets you into hairy areas, where you have to use on undocumented interfaces, and encounter breakage as kernel changes happen. Some times things work fine without panics. This confirms me that there is no problem with the code. Can you describe a bit in more detail what the driver does ? Is it opensource, and/or are you planning to turn this driver into an OpenSolaris project ? Can anyone suggest me as to what aspect should I look into to avoid these panics. Well, please first be more specific as to how these panics look like. Even better would be if you could share the module, its sourcecode and instructions how to set it up / use it so that we can reproduce and help. FrankH. Thanks in advance. Priya -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] wanted: way to sync from openboot without crash dump
On Thu, 13 Dec 2007, Richard L. Hamilton wrote: Sometimes a large system, despite precautions (or in the absence of them), runs out of resources (VM, mainly) to the degree that no useful progress is being made: that is, one can't even log in and kill the hogging processes. (At least on SPARC) the usual workaround would be to break to the boot PROM and sync; however, this invariably causes a crash dump to be taken. In the common case where dump partition = swap partition, the dump might well not be complete anyway, since swap was already full. And one may well know by experience what the likely culprits are. And on a large system, the crash dump can take longer to complete than the subsequent reboot! Sounds like a reasonably simple RFE: dumpadm should have option to request skipping dumps I.e. like dumpadm -c none and/or dumpadm -d none. The forced association of you've got swap we will dump seems arbitrary. Note that swap partition full doesn't impact the ability to dump, as the dump will happily overwrite whatever was on there before the dump started. Shouldn't need PROM modifications that I can see. Just modify dumpsys(), dump_ioctl() (DIOCGETCONF / DIOCSETCONF) and the dumpadm command. I estimate around 50 lines of codechange, and takers ? FrankH. So it would be really nice to have an option to force a sync and reboot _without_ taking a crash dump. The ability to pass the option would require boot PROM support (or else some obscure use of an existing command to set something the kernel could readily detect); but the ability to optionally _not_ take the crash dump even if it otherwise could and would, would require kernel support. Granted, the situation shouldn't come up all that often. But it has been known to do so (and one of the culprits tends to be a 3rd-party system monitoring application that I won't name; ironic, IMO, that something intended to warn of problems instead causes them); and when it does, reducing the down-time by the 5-10 minutes that a really long crash dump can take, would IMO be quite helpful. Am I nuts, or is that a generic enough issue that someone else might agree that it's interesting? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] wanted: way to sync from openboot without crash dump
On Thu, 13 Dec 2007, Richard L. Hamilton wrote: Sometimes a large system, despite precautions (or in the absence of them), runs out of resources (VM, mainly) to the degree that no useful progress is being made: that is, one can't even log in and kill the hogging processes. (At least on SPARC) the usual workaround would be to break to the boot PROM and sync; however, this invariably causes a crash dump to be taken. In the Workaround: If you have obpdebug defined, you can do: dumpvp 0 x!; sync at the ok prompt to force skipping the dump. You could also force it to don't do it via /etc/system: set dump_timeout=0 There are probably a few more undocumented variables to achieve similar. It's really a question of preference. A sync --nodump would only benefit SPARC; one could argue that SPARC-only features are so last millenium. And one could ask why don't you just 'boot' instead of 'sync' then. FrankH. common case where dump partition = swap partition, the dump might well not be complete anyway, since swap was already full. And one may well know by experience what the likely culprits are. And on a large system, the crash dump can take longer to complete than the subsequent reboot! So it would be really nice to have an option to force a sync and reboot _without_ taking a crash dump. The ability to pass the option would require boot PROM support (or else some obscure use of an existing command to set something the kernel could readily detect); but the ability to optionally _not_ take the crash dump even if it otherwise could and would, would require kernel support. Granted, the situation shouldn't come up all that often. But it has been known to do so (and one of the culprits tends to be a 3rd-party system monitoring application that I won't name; ironic, IMO, that something intended to warn of problems instead causes them); and when it does, reducing the down-time by the 5-10 minutes that a really long crash dump can take, would IMO be quite helpful. Am I nuts, or is that a generic enough issue that someone else might agree that it's interesting? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] common ( Win64/Linux/SNV/UNIX ) filesystem du jour ?
On Sun, 9 Dec 2007, Cyril Plisko wrote: On Dec 9, 2007 8:11 PM, Dennis Clarke [EMAIL PROTECTED] wrote: The next question is how to create a single filesystem on a USB attached device ( like a USB Stick from SanDisk or Kingston etc ) where the filesystem is supported and read/write functional on all of Win32/Win64/Linux and Solaris/UNIX. I don't think that NTFS is worth looking at because it is closed and proprietary. Microsoft could bork that up at a whim without telling anyone. The only two others I see are old world FAT nd FAT32. The FAT type filesystem is too small and restricted for anything real world. That leaves FAT32. Am I missing anything ? Any suggestions ? Dennis, As long as your media is less than 32GB FAT32 should be ok. Another possibility is UDF. Although last time I check Windows considered it to be read-only (that was quite some time ago and I am not sure what is the status today) FAT32 larger than 32GB just works fine (apart from the abysmal speed if a filesystem of that size gets fragmented), even on Windows. The problem is that Windows will not let you create and/or properly scandisk/chkdsk such a large FAT32. But that's an arbitrary limitation created by Microsoft to push people towards NTFS (and to avoid having to deal with service inquiries ... or the need to improve the implementation). If you create the fs under Linux or Solaris, and fsck it under Linux, there's no issue at all with using a FAT32 filesystem of up to 1TB. If you really want to go beyond that, hmm - no good idea either. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Does Solaris has similar Linux command mount -o which can mount IMG file with specified offset?
On Tue, 11 Dec 2007, Josh Lange wrote: On Dec 11, 2007 1:25 AM, Zhang, Frank F [EMAIL PROTECTED] wrote: Does Solaris has similar Linux command mount -o which can mount IMG file with specified offset? Or if I can get an Utility to do this kind of job? Are you talking about mapping an image file to a loop device, and mount it -o loop ? I haven't tried the loop arguement to mount on solaris, but it's pretty easy to manually mapping a file to a loop device, and then mounting the loop device. Check out: lofiadm(1M) As for mounting the image with an offset, I'm not aware of how you are doing this in linux, and generally this isn't needed for an iso image, but you may consider using dd(1M) to cut the image into multiple files. On Solaris, it depends on the filesystem. FAT filesystems within images of PC-style partitioned disks can be mounted using the 'normal' PCFS syntax /dev/lofi/1:[c-z] but that functionality is limited to PCFS. It's not a generic lofi thing. Although it should be - the request is not new, see: http://bugs.opensolaris.org/view_bug.do?bug_id=4765069 and what's associated with it. But then, there's always more than one way to do it ... and in case of what you can do right now, creating an iSCSI target where the backing store is your partitioned image file, and then using the iSCSI initiator on the same machine to access it (as a sd-managed disk) should allow you to get the partitions. Sounds a bit like poke around the back, through the ribs and up right into the eye, but hey ... :) Have you tried the iscsitadm / iscsiadm workaround ? FrankH. Thanks! Frank ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounting more than two FAT volumes in an extended partition
On Mon, 3 Dec 2007, vineet kumar wrote: Hi, I am using SXCE build76. i have a extended partition on my drive with 4 FAT32 volumes. But I can mount only the first two. a) How exactly are you trying to mount them, i.e. which device name do you specify for the mount command ? b) exactly what failures (error messages on the mount command line and in /var/adm/messages) do you get ? c) How does the partition table look like ? You can use Moinak's tool here: http://blogs.sun.com/moinakg/entry/solaris_x86_partition_table_viewer to prettyprint it, including the logical drives. Is it a known limitation of Solaris or is there some bug or problem ? that depends. Is there a workaround for this? ditto. FrankH. Regards, Vineet This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Instruction design using SAM
On Thu, 15 Nov 2007, Ajay Ramesh wrote: I want to design folowing SAM in solaris please some body help me My memory tells me that is a repeat request ... Anyway, OpenSolaris is a software project. CPU design isn't exactly what people here focus on, and/or have great expertise in... It might be a better idea to inquire about such things with our friends over at http://www.opensparc.net - that would help you more. By the way, there's a huge amount of samples (both circuit diagrams and VHDL code) for various processor subsystems out on the Web. Even wikipedia's cpu design / alu design webpages provide such links. Likely, noone will take your task of integrating various subpieces (that you might find pre-cooked) into the coherent whole that the project below asks for. There's a little bit of homework involved for every student :) FrankH. 2. Design of a 16 bit Processor: Assume the design includes a Program Counter, Accumulator, Arithmetic Logic Unit and Instruction Register. Let “addr” denote the address (field) and “mem [addr]” denotes contents of memory location “addr”. Note 1: The Memory is external to the Processor Note 2: Assume memory is 4K by 16 bits A. Design an Instruction Set to do the following: 1. Load Accumulator from memory location “addr” 2. Store Contents of Accumulator to memory location ‘addr” 3. Add the Contents of Accumulator and memory location “addr” and store in Accumulator 4. Subtract the Contents of memory location “addr” from Accumulator and store in Accumulator The instruction set reference manual for the Z80, M6502, or i8008 will provide examples for that. 5. Load the Program Counter from memory location “addr” 6. Set the Accumulator to “addr” if accumulator = zero 7. Set the Accumulator to “addr” if accumulator not equal to zero 8. Stop the Processor B. Write the Block Diagram of the Data path for the Processor Note: This must include the Address Bus, Data Bus, ALU, PC, ACC, IR and external memory. Question: What is the size of the Address Bus? Question: What is the size of the Data Bus? Questions: What are the Control Signals? C. ALU Design: 1. The ALU functions are : A+B, A-B, A+1, B+1, B, Clear 2. Design the ALU in Verilog/VHDL/C 3. Write a Testbench and Verify that the ALU works properly. Notes: Simulate with a standard Simulator such as ModelTech ModelSim Assume 2s complement arithmetic – why do this? D. Write the Register Transfer Level Organization of the Processor 1. Write a Block Diagram of the Processor at the Register Level 2. Write the Verilog/VHDL/JHDL register level code 3. Write the Testbench for the Processor – how will it initialize? 4. Simulate with a standard Simulator such as Model Tech ModelSim E. Extensions to the 16 bit Processor 1. How many op-codes are there in the Processor now? 2. How many can be added without much change? 3. Write down some suitable opcodes and the corresponding operands 4. Iterate on the procedures described above to verify functionality 5. Extend the Address Space 6. Add more addressing modes 7. For Subroutine calls, add the capability to save the PC 8. Add more Registers 9. Add support for Interrupts 10. Add support for a Condition Code register 3. Pipelining: 3 stage pipelining 5 stage pipelining (to be expanded further) 4. Level 1 Cache design: Different types of Caches: Direct, Set Associative, etc Design of a cache Cache Simulation Cost of Cache vs. Simple RAM organization Measurement of Cache Performance Incorporate Cache design into your Processor Design Must be able to turn Cache on or off Measure the performance with and without Cache enabled This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [advocacy-discuss] Project Indiana and the OpenSolaris name
On Thu, 1 Nov 2007, Alan Burlison wrote: [ ... ] Personally I don't know what the opinion of the community is on this issue, mainly because the vast majority of the voting members choose to keep quiet. All I see is a small number of voluble individuals stating and restating their opinions and claiming that they are the 'voice of the majority'. A vote is how we gauge the collective opinion of the community, not statements from one individual or another. I have to agree with Alan here. To conclude the majority approves from the the majority is silent implies that silence == approval. Such an assumption seems a bit far-fetched. That anyone opposing a proposal will have to rally their supporters and be visible about their opposition is obvious. But that someone proposing will not have to rally _their_ supporters but may assume approval-by-silence is bad governance. It's what drives people away from politics, and what gives organizations that work like this (e.g.: European Council) such a bad reputation with the people they govern. Govern by edict and your subjects will learn to hate you. People may or may not agree with what you propose, but unless you've put the question to the vote, some will be disgruntled - not because they'd object to the action as such, but because they object to the way it was done. That said, /me is now stepping back into the silent majority :) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] package add and remove in non-interactive mode
On Wed, 31 Oct 2007, Shawn Walker wrote: On 31/10/2007, Nikolay Molchanov [EMAIL PROTECTED] wrote: I'm not suggesting to change stdio, I'm suggesting to change pkgrm code to use read(0, buf, 1); in loop to read 1 byte from standard input until the end of line or EOF happens. Basically it is the same loop as it uses to write its questions: 12580:write(2, D, 1)= 1 12580:write(2, o, 1)= 1 12580:write(2, , 1)= 1 12580:write(2, y, 1)= 1 12580:write(2, o, 1)= 1 12580:write(2, u, 1)= 1 12580:write(2, , 1)= 1 ... In this case it will leave the pointer in the input file at the beginning of next line, so the child process will read from this point. That seems like a lot of hackery for little benefit. The whole thing reads a bit like How do we solve a problem that is ages old and must have been solved before ?. Isn't this exactly what programs like expect were supposed to address / allow - remote-control/script things that request user input, aka read from stdin ? FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Opensolaris as my main laptop OS, advice needed !? (fwd)
On Tue, 30 Oct 2007, Joerg Schilling wrote: James Carlson [EMAIL PROTECTED] wrote: Note that 32-bit applications have no problem handling large files on Solaris, so it's really more of an issue in run-time memory space than anything else. 32bit Applications cannot access files with file stamps that do not fit into the 32 bit range. This is why Solaris currently has too few 64 bit applications ;-) Note that PCFS can easily create such time stamps. You won't see them by default, thanks to PSARC 2005/361 (bug 6248624) - PCFS clamps the timestamps to the UN*X 32bit time_t range unless explicitly told not to by a mount option (noclamptime). See pcfs(7fs) and mount_pcfs(1m) about that. And yes, that was done because it causes too many unexpected failures. FrankH. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why disk partition method can affect Solaris OS bootable or not
On Wed, 17 Oct 2007, A. Stockinger wrote: [ ... ] For coexistence of Solaris and Linux there is no chance for only one Grub screen, we need this Grub hopping. Hope that helps you. Don't quite understand that. I never found it a problem for Solais' grub to boot my Linux installation, even Linux fs'ses that were within an extended partition. Solaris, on install (or on refreshing grub) does not autogenerate you grub menu lines for the Linux roots, but manually adding them to Solaris' /boot/grub/menu.lst (i.e. copying the entries from the corresponding Linux file) always worked just fine. Which is not the case if I use Linux' grub in the MBR - that doesn't like to boot Solaris directly at all. At least not the one from Fedora 7 and SuSE 9.x, but haven't tried any newer Linux ones since so my datapoint there is stale. Summary: If you install in order: - Windows - Linux - Solaris then you have Solaris' grub in the MBR, and the only thing you need to do to get this grub version directly boot all of your operating systems is to add the Linux menu.lst entries to /boot/grub/menu.lst on Solaris. FrankH. Adi This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] how to mount drives
On Wed, 19 Sep 2007, vijay wrote: 1. how to mount windows ntfs and fat32 drives in solaris11? 2. how to configure or start broadband connection in solaris11? 3. how to mount USB drives in solaris11? Rob answered these. 4. while mounting Fat32 it gives I/O error Does that also happen if you use PCFS as changed here: http://cr.grommit.com/~frankho/ you need a recent - later than build 72 - opensolaris kernel, and then you can use these modules. Thanks, FrankH. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [OT] s10u4 DVD iso link-count oddity
On Fri, 14 Sep 2007, [EMAIL PROTECTED] wrote:
Sorry this is s10 but I thought someone here may have some idea about this
I just noticed (thanks to star complaining about missing links) that
numerous ( 2000) files on the s10u4 SPARC DVD seem anomalous.
# cd root of dvd
# ls -il Solaris_10/Tools/Boot/usr/bin/{cp,ln,mv}
2777075 -r-xr-xr-x 3 root bin 27360 Jan 25 2007
Solaris_10/Tools/Boot/usr/bin/cp
2777524 -r-xr-xr-x 3 root bin 27360 Jan 25 2007
Solaris_10/Tools/Boot/usr/bin/ln
2777654 -r-xr-xr-x 3 root bin 27360 Jan 25 2007
Solaris_10/Tools/Boot/usr/bin/mv
# find . -inum 2777075
These directory entries are normally (in /usr/bin) links to the same
file. It looks like the files have become copies on the DVD but the
link-count field still reports the original number of links.
Maybe this is normal, but I don't remember seeing it before.
I don't know if this will cause any problems.
I think this is an issue with the hsfs reader in Solaris; it does not
generate inodes in a way that makes hardlinks work.
(Although I also think that was recently fixed)
Yes:
4294956 hsfs creates wrong inode numbers for hard links
went into build 72.
FrankH.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] A big PCFS change in the pipeline
On Sun, 9 Sep 2007, John Weekley wrote: Joerg Schilling wrote: Mario Goebbels [EMAIL PROTECTED] wrote: Ok, dumb question of the day: How do I actually install and use the precompiled modules? I've dropped them (i86 and amd64) into the respective driver directories, did rem_drv and add_drv, but it still seems to load the internal one. You do not need add_drv for filesystems. Just replace the binary in /kernel/fs or modunload the loaded binary and then modload a different binary. Jörg What build were the modules intended for? I'm trying it on B72 and get Sep 9 10:39:09 vj genunix: [ID 819705 kern.notice] /kernel/fs/amd64/pcfs: undefined symbol Sep 9 10:39:09 vj genunix: [ID 826211 kern.notice] 'vnevent_rename_dest_dir' Sep 9 10:39:09 vj genunix: [ID 472681 kern.notice] WARNING: mod_load: cannot load module 'pcfs' Hi John, they're built from the latest sources. On Aug/14th, the following fix: 6367770 RFE: add userland interface to fem (file event monitoring) (PSARC/2007/027) went in, and that modified all filesystem backends - including PCFS. Filesystem modules built from sources later than that date will require a matching kernel, or you'll see the module load fail as per above. So no build 71. I _think_ the re-spun build 72 is fine, but if in doubt then a BFU from archives built after Aug/14th will do. FrankH. Thanks, John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] funding priorities [was Re: A big PCFS change in the pipeline]
On Fri, 7 Sep 2007, Dennis Clarke wrote: [ ... ] I expect that the first release of Indiana will change a lot of things and I *hope* that bureaucratic modis operandi will be one of the things to slowly slip away. I hope for the same. Although, as you say, changing code is the trivial part. Changing business processes and policies is what's hard. And yanking a supertanker such as Sun Microsystems around takes quite some time, and now and then makes undesirably big waves :( [ ... ] can't Kaiwai Gardiner spend the pittance it would take to hire a team of engineers to redesign PCFS in OpenSolaris? Because, maybe, it's a pity to see how little comes out of Sun wrt. to such a tiny project as PCFS ? I mean, it's the same things that annoy people for decades, and still noone acknowledges it / works on it ? I can understand that one would think Sun has had so much time to do something about it why oh why just don't they. It's hard to argue with this. But it's doubly hard for those who actually have tried to do something about it, if only a little, to continue to see allegations of not enough not enough. As far as PCFS goes, I'm not hiding diagnostics from you, nor ideas, as much as I'm aware. Everyone can have a look at the buglist for the product here: http://bugs.opensolaris.org/bugdatabase/search.do?process=1minDisplay=onbugStatus=1-dispatchedcategory=kernelsubcategory=pcfs http://bugs.opensolaris.org/bugdatabase/search.do?process=1minDisplay=onbugStatus=2-incompletecategory=kernelsubcategory=pcfs http://bugs.opensolaris.org/bugdatabase/search.do?process=1minDisplay=onbugStatus=3-acceptedcategory=kernelsubcategory=pcfs http://bugs.opensolaris.org/bugdatabase/search.do?process=1minDisplay=onbugStatus=4-defercategory=kernelsubcategory=pcfs http://bugs.opensolaris.org/bugdatabase/search.do?process=1minDisplay=onbugStatus=5-cause+knowncategory=kernelsubcategory=pcfs http://bugs.opensolaris.org/bugdatabase/search.do?process=1minDisplay=onbugStatus=6-fix+understoodcategory=kernelsubcategory=pcfs http://bugs.opensolaris.org/bugdatabase/search.do?process=1minDisplay=onbugStatus=7-fix+in+progresscategory=kernelsubcategory=pcfs http://bugs.opensolaris.org/bugdatabase/search.do?process=1minDisplay=onbugStatus=9-fix+failedcategory=kernelsubcategory=pcfs Sorry, can't list a simpler method, since bugs.opensolaris.org doesn't allow multiple states to be specified for a single search, and you'll get a lot of closed bugs listed if you don't specify a category. Some of these are in the works, others are evaluated to a degree that it's known what causes the problem. Not all of them have people working on them. Feel free to ask questions about the specifics of any particular bug, I'll reply in a spare minute. Now according to this: http://www.opensolaris.org/os/community/on/dev_solaris/ the PCFS source falls into the 2nd category. Which can be translated as endless reservoir of work... Thing is, as an employee, I have to do the work I'm assigned to. I can assist with other things as long as there's no interference between interest and duty. But there is now :( Hence, as said, all willing to help with troubleshooting and/or coding advice, but I can't do the actual coding and integration work for PCFS anymore. Not beyond this change, and not on company time, anyway. And interest - well. FAT is important enough to have stayed around for 30+ years. It'll stay for a while. But technically, I think for something like FAT, a userspace implementation, via FUSE or a related mechanism, just has so many advantages that I won't spend my personal time on the kernel driver anymore. I'll personally go to FUSE. Not everyone might agree with me on that. Hence I've told people here's a start of a code cleanup for the kernel driver. Honestly, this is all I meant to convey. Had I had any idea what waves that would make I might better have remained silent ... FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] A big PCFS change in the pipeline
On Thu, 6 Sep 2007, Joerg Schilling wrote: Kaiwai Gardiner [EMAIL PROTECTED] wrote: So this is sketched out roughly, but no coding has started on this yet (and, given my commitments changed, isn't going to start by myself any time soon either). Cool but in regards to how the FAT is read, that is, dumping the whole thing in memory rather than a gradual read - is that going to be a addressed soon? This is wat I found when doing a code review on the changes. It seems that there needs to be a paying customer who files a bug report. One that escalates a bug report. It has been filed a few years back, for reference: http://bugs.opensolaris.org/view_bug.do?bug_id=4993461 From a technical point of view, I think the singlethreadedness needs to be addressed first before the FAT caching can be properly solved. That's so because if there's no proper locking scheme designed _before_ one changes the FAT32 caching, one will, in the end, have to design the locking scheme around whatever the caching methodology will be. design around sounds awful to my technical sense ... But I'm quite open to suggestions; if you have codechanges that have a demonstratable benefit, pls. submit them, I'll be more than happy to give you a review, and help with integration. The original intention from Frank was to totally rewrite pcfs but this has been stopped in spring due to lack of resources. Sometimes, dreams are just that, dreams, and waking up means we find priorities and objectives in the real world are different. Regards, FrankH. k ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] A big PCFS change in the pipeline
On Thu, 6 Sep 2007, Lurie wrote: Darn, too bad :( the speed is definitely not fantastic (3.8mb/s read vs 15-20mb/s in Linux for a usb flash stick) + the mem usage... The change does nothing for the (non-)speed, unfortunately. It does: - enable access to 2kB secsize media (like video iPod) - improve media compatibility (much less false rejects) See other postings. Speed suffers from the singlethreadedness, from the bad FAT lookup strategies / too-frequent FAT accesses, and from the lack of readahead in PCFS. Future work :) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] A big PCFS change in the pipeline
On Tue, 4 Sep 2007, Fintan Ryan wrote: Hi Folks, This is great to see, I was playing with the binaries that were available from August 14th a few days ago in order a new iPod nano, one question though - is the code in the webrev substantially different from the code base that the binaries from Aug 14th were built from? If so would it be possible to get the updated binaries posted as well? The code is only very slightly different; I've uploaded re-built files, though. Same names. Thanks ! FrankH. - Fintan This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] A big PCFS change in the pipeline
On Wed, 5 Sep 2007, Kaiwai Gardiner wrote: On Tue, 2007-09-04 at 13:46 -0700, Fintan Ryan wrote: Hi Folks, This is great to see, I was playing with the binaries that were available from August 14th a few days ago in order a new iPod nano, one question though - is the code in the webrev substantially different from the code base that the binaries from Aug 14th were built from? If so would it be possible to get the updated binaries posted as well? - Fintan Just a follow up to that, does it address long standing performance issues with the pcfs design. Nope, this doesn't attempt to solve that yet. The biggest performance inhibitor is the singlethreadedness, 4293035. A rough design sketch how to get rid of that would look like this: Locks needed in struct pcfs: - a 'pcfs_instancelock' to do the forced umount synchronisation in the PCFS_ENTER() / PCFS_EXIT() style (as ZFS does) * every op does the enter/exit protocol - a 'pcfs_renamelock' to synchronize between vnode ops that require updates to directory structure (create, rename, remove of files/dirs) and all other vnodeops * every op that requires vnode persistence does RW_READER * every op that does directory modification does RW_WRITER - a 'pcfs_fatlock' (possibly in a rangelock style to allow parallelism) to synchronize updating the FAT on alloc/free * FAT reads (pc_getcluster, pc_freeclusters - or their callers) do RW_READER * FAT writes (pc_setcluster, pc_alloccluster - or their callers) do RW_WRITER - a 'pc_nodelock' for the file nodes * RW_READER for things that do not modify more than atime * RW_WRITER for modifications to the file size/contents * atomic ops for pc_flags renamelock and the nodelock should be modeled after the nfs reentrant-safe / interruptible shared-exclusive locks, since they'll be held over duration of a vnode op (and those can recurse - infamous write/read = getpage/putpage problem, and layering such as via sendfile and/or NFS). That should allow a reasonable amount of concurrency, while at the same time avoiding typical deadlock scenarios. For the above outlined simplicity of locking, we would, in the initial delivery, still singlethread: - writes (only one writer per file) - directory updates of any sort (create/delete/rename will block all other operation on the filesystem) So this is sketched out roughly, but no coding has started on this yet (and, given my commitments changed, isn't going to start by myself any time soon either). Also, is there an eta on when FATex will supported? What's FATex ? FrankH. Matthew ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] A big PCFS change in the pipeline
On Wed, 5 Sep 2007, Fintan Ryan wrote: This is great to see, I was playing with the binaries that were available from August 14th a few days ago in order a new iPod nano, one question though - is the code in the webrev substantially different from the code base that the binaries from Aug 14th were built from? If so would it be possible to get the updated binaries posted as well? The code is only very slightly different; I've uploaded re-built files, though. Same names. Excellent thanks Frank, I'll give them a run later on. Let me know what you find :) Thanks ! FrankH. - Fintan ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] A big PCFS change in the pipeline
Hi,
this is a heads-up of a significant codechange about to go into PCFS.
I've put a webrev for the proposed change up at:
http://cr.grommit.com/~frankho/
Why is this big / significant ?
a) it provides most of the support for media with 2kB sectorsize
(the infamous my iPod isn't accessible problem)
Most of this was contributed by Juergen Keil - thanks, Juergen !
b) it changes the way how you'll troubleshoot PCFS. In particular,
most of the occurances of PC_DPRINTF() have been eliminated, and
even if you crank up the `pcfsdebuglevel` tunable you'll not see a
big number of messages on console/syslog anymore.
This is because most of these messages were just function entry/exit
brackets, and others were simply not helpful.
- function entry/return bracketing should be done with DTrace,
that's what fbt:pcfs::entry {} / fbt:pcfs::return {} would be
for.
- where the messages remain, they have been cleaned up to give
enough / reasonable information.
In addition to that, PCFS got a few statically-defined tracepoints,
via DTrace SDT. The most important of these are:
sdt:pcfs:parseBPB:parseBPB-initial {}
sdt:pcfs:parseBPB:parseBPB-final {}
which deliver a score-based match for what PCFS could figure out
about the FAT bootsector.
How does this look like ? Best, try on your own system, use the
changes from above, and the following DTrace script:
http://cr.grommit.com/~frankho/pcfs-mount-diagnose.d
and then simply mount a PCFS filesystem.
In short, it's DTrace time.
c) There's some new behaviour in there which may surprise you, such as:
- validation of filesystem size against media size. PCFS will now
give you warning messages that there might be errors on access
if the filesystem doesn't fit on the medium.
If you see this, and believe you shouldn't, please contact us.
- access time updates are disabled by default on removeable media.
You're not likely to notice this as atime granularity on FAT is
days anyway; but then, some of you seem to test this area more
intense than I used to, so just following principle of least
surprise.
- the mountpoint for a FAT filesystem will no longer report a
timestamp of Jan 1st 1970 ('unix time zero'). Instead, it'll
report the time when the mount was done.
If you feel that there are problems with this change, or things that it
doesn't address but should, please reply; otherwise, enjoy the piece, and
thanks to Juergen Keil and Alex Zakharov for their fix contributions !
FrankH.
--
No good can come from selling your freedom, not for all the gold in the world,
for the value of this heavenly gift far exceeds that of any fortune on earth.
--
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Adobe Acrobat for Solaris x86
On Fri, 24 Aug 2007, Kaiwai Gardiner wrote: [ ... acroread/UNIX blog ... ] Setting up blogs mean jack if they don't actually produce some damn results - damn I hate it when companies think that with a blog and a few hollow words that they can create a so-called 'community'. Less blathering more programming and compiling. Up till to this blog, Adobe hasn't even created as much 'blather' as stating that any acroread/UNIX development _is_ actually going on. acroread/UNIX. Not acroread/Linux, not acroread/UN*X. Even hollow words coming out of Adobe wrt. to that is far far more than what used to come out of Abode - nothing at all, that was. If that's not encouraging to you, feel free to go back sulking in your cave ;) but personally, I take it as a great sign of things to come ! Good news indeed :) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_70 odd behavior
On Wed, 22 Aug 2007, [EMAIL PROTECTED] wrote: [ ... ] Anyway, the original problem I ran into is a simpler one: that hsfs will detect a filesystem as hsfs without then also wanting to mount it. That, of course, won't do. Casper Thanks for bringing it back to the topic :) Can anyone actually come up with reasons why HAL should not simply mount all filesystem types found on such a medium, onto different mountpoints (/media/hsfsmnt, /media/udfsmnt, ... ?) ? One could argue that on a writeable medium, double detection should lead to a refusal to mount. On a readonly medium, though, there can be no harm in allowing all ways in. Now how to find out whether a medium doesn't allow writes ... another problem, but again, workaround would be to simply mount all multiple detections - but all readonly. What do people think on that ? FrankH. Note: There's no proper solution to 'hybrids' but to access them via all. As Vista generates ISO9660/UDF hybrids where the ISO9660 side only says 'this needs UDF', someone else can easily create an iso9660/udf hybrid where the other is true, and the udf side says 'look at this via iso9660 and you see' - just showing one-of-a-hybrid always puts the problem up that you might show the one that doesn't contain what you want to see. For the user, it counts that all is there. If it's in the expected/hoped-for place, for the better, but to start with, better have it than not. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SXCE 70's installer and laying out file systems
On Mon, 20 Aug 2007, UNIX admin wrote: I suggest people with issues take them to those lists rather than air them here. Super. So: - this is not a Solaris helpdesk - Solaris 10 is not to be discussed here - issues with OpenSolaris are not to be discussed here What IS to be discussed on openSolaris-discuss then? Discussions on what (not) to discuss seem always welcome. That's why the list is -discuss. That's what it is about :) (couldn't resist) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_70 odd behavior
On Mon, 20 Aug 2007, [EMAIL PROTECTED] wrote: Some DVDs contain two filesystems [1], hence mountable as either hsfs and udfs. fstyp returns the first match, and that's what HAL will use. One fix would be to treat these in the same fashion we treat hybrid data+audio media, i.e. pop a dialog asking for user's preference. A simpler but less generic fix would be in HAL: if libfstyp returns hsfs, call it again to check for udfs [2]. If anyone is willing to contribute code [3], I'll happily sponsor. Why can't HAL simply cycle through the media, and mount ALL filesystems it finds on it? Unfortunately, there's some media which hsfs recognizes but then fails to mount. Do you have example images of these, and are bug reports open for those ? Generically, the 'cycle through' isn't that splendid an idea, especially with multi-faced filesystems; a CD may contain: - an ElTorito boot image which is a FAT filesystem - an ISO9660 filesystem that'll be recognized as HSFS - an UDF filesystem that may or may not be recognized as UDFS Which one _do_ you want to mount ? Assuming no bugs in the fstyp backends, fstyp on such a medium would say 'multiple matches'. Who sets the preference ? For readonly media, case can be made to simply mount them all (to different places. Is that what you mean ? FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Using script (perl or korn) to determine opened ports (Method must work in Solaris 8, 9 and 10)
On Tue, 21 Aug 2007, Steven Sim wrote: Gurus; Is there a way, through the procfs of Solaris to determine whether the a process has opened listening network ports? Either using Perl or otherwise? I know of a very iterative approach but if we apply the approach to all the ports and the processes in a running system, it well...does not really perform. I was wondering whether there was a specific API call in the Solaris procfs which readily gives the opened network port (if the process has one)? The above methodology must work in all three Solaris version. 8, 9 and 10. This implies no dtrace and no special pfiles output parsing (the pfiles output in Solaris 10 easily provides the network port). Warmest Regards Steven Sim With those requirements in mind: - faster than 'iterative' - running on S8/S9/S10 you're nailed to lsof. May need occasional recompile, but then it works on S8+, and it's blindingly fast (because it doesn't try to do the sort of locking that procfs does). FrankH. Fujitsu Asia Pte. Ltd. _ This e-mail is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- No good can come from selling your freedom, not for all the gold in the world, for the value of this heavenly gift far exceeds that of any fortune on earth. -- ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Can't use DVD and USB, why?
On Tue, 14 Aug 2007, Orvar Korvar wrote: # mount -F pcfs /dev/dsk/c2t0d0p0:c /mnt/tempMountPoint/ mount: I/O error How strange. I am beginning to think that Ive missed something basic here. If you have OpenSolaris (need around ~build 25), you can use the patches / modules from: http://cr.grommit.com/~frankho/ There's a DTrace script in there as well that helps nicely to diagnose mount failures, use it like: dtrace -s pcfs-mount-diagnose.d -c mount -F pcfs /dev/dsk/c2t0d0p0:c /mnt/tempMountPoint/ to find out what PCFS is actually detecting. This _depends_ on the modules above, doesn't work with S10 pcfs and/or default onnv/opensolaris pcfs. FrankH. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Can't use DVD and USB, why?
Anyone willing to test the fix for that ? There's more than one bug open against 2kB sector size support, in fact in total there are five ... the one below among them. FrankH. On Sun, 12 Aug 2007, [EMAIL PROTECTED] wrote: Regarding the USB device problems. Stock Solaris has an open bug against it about large USB devices formated as FAT with a 2K sector size. The Solaris code used to determine drive characteristics makes some unwarrented assumptions. The OpenSolaris bug report is here http://bugs.opensolaris.org/view_bug.do;jsessionid=28aade27cf7a71d6a45feab8fce?bug_id=6393753 You can work around the problem by installing mtools and using the device name created by vold (get it from the rmformat command.) You can dump out file system characteristics using fstyp. -- Geoff Lane This is your head..THiS iS yoUR HeAD On WindOwS. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Can't use DVD and USB, why?
On Mon, 13 Aug 2007, Orvar Korvar wrote: fdisk lists a DOS-BIG partition. But bash-3.00# mount -F pcfs /dev/dsk/c2t0d0p0 /mnt/tempMountPoint/ mount: I/O error is the result. You need to use /dev/dsk/c2t0d0p0:c - p0 is the whole disk, unpartitioned, and _that_ contains no recognizable filesystem. FrankH. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] An Open Letter to the Solaris Community.
On Fri, 10 Aug 2007, Joerg Schilling wrote: [ ... ] You may quote other people's work _without_ ever asking them for permission in case this is needed for your work and as long as your work has enough own creation level to make it a separate work. That might or might not be correct given the gritty details where the legislation in different countries is different. Though in the end, it doesn't matter. You may be allowed to do that, fully within your rights. But that's not the point. It doesn't actually help either of: - integrate a Linux ZFS with 'Linux mainstream'. - maintain a Linux ZFS when Linux changes ... yet again. - find co-workers who will help with coding/maintenance. It doesn't encourage cooperation. And even if there were a e.g. a WTO decision that the so-called 'linking clause' of the GPL is null and void, and several high court rulings worldwide confirming so, it wouldn't stop people who _like_ to think it's valid from adopting a stance that no matter what, they'll use all means they can to obstruct those who do not agree with them. Several Linux kernel developers have openly stated so. Or, on a different end, the Debian Free Software Guidelines are way more restrictive than the GPL. It's a political agenda, not a question of what's legally/technically possible. Linux developers don't _want_ non-GPL code in the kernel, and unless you have a significant tendency towards masochism (or are well-paid to do it) and are willing to update your port chain whenever compatibility with your module is deliberately broken next (greetings to Ati/Nvidia), you'd better not try or else you'll regret the continuous waste of effort. Personally, I think they're shooting themselves in the foot, definitely long-term. But then, this talk about how to get code from OpenSolaris into Linux is somewhat off-topic; back in usenet days, I'd have pointed you towards comp.unix.advocacy :) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] An Open Letter to the Solaris Community.
On Wed, 8 Aug 2007, Nico Sabbi wrote: Joerg Schilling wrote: Nico Sabbi [EMAIL PROTECTED] wrote: [ ... ] This is opensolaris. If you like it, do it! Jörg you explained yourself that doing it is one thing, integrating it in Opensolaris is a totally different thing that only the members of some board can decide. Since the ports of eclipse and kde exist already now, it's up to the board to decide what to do with them Not quite. For one thing, what you're asking for is integration of KDE and Eclipse into a specific distribution, probably Solaris Express. That's different from integrating into OpenSolaris. Are KDE and Eclipse part of the Linux kernel ? Are they part of the GNU compiler collection ? Are they integrated with GNU libc ? Ah, and yes, it'd really be a great idea to actually integrate them both into GNOME ... You're asking for co-packaging, what in terms of OpenSolaris is called a WAD - the term would roughly describe what's commonly referred to as distribution. That's a collection of various so-called, again in terms of OpenSolaris, consolidations, which are e.g. X11, ON, install, Java - which are not fully self-contained, but also not tightly coupled. There's no need to create a new build of the X server each time a new build of the ON kernel components go out. Same would be true for e.g. Eclipse and KDE. The mythical entity you refer to as The board will not object to a specific consolidation's idea of what code/feature/subsystem should go in or out as long as there are no side effects beyond that consolidation. Adding new software packages therefore needs talking to the specific people who work on the umbrella thing - and that's the consolidation, the community that'd embrace your project(s). Trying to integrate a new manual page, would you talk to a kernel engineer or a documentations maintainer ? I guess you get the idea now. Assuming you have a piece of code, a specific item of software you want to have distributed as part of some OpenSolaris distribution, you would, in order: - ask the maintainer(s) of that distribution how that'd work - ask people from a related community what'd be needed and only _then_ start worrying about what strange questions they might come up with. What Joerg was talking about was code integration into the ON consolidation (kernel/libraries/UN*X utils), that currently uses what's called a sponsorship model where you dump your code onto some Sun person for them to turn the internal wheels and get stuff in. If you search the archives for e.g. ksh93 you'll see that such integration discussions can take a very long time. But that's far from what you want. You're not developing a kernel driver, a UN*X utility of a fix/enhancement to libc. You're simply requesting (some) (Open)Solaris distributions to include additional software. Which might have its own pitfalls, ok. Have you tried talking to talk to any distribution maintainer ? FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Regarding CDDL - using ufs code
On Fri, 3 Aug 2007, amol wrote:
Hi,
I want to use the struct direct datastructure from the file ufs_fsdir.h -
just that
data structure in a proprietary code. I read the CDDL CDDL FAQ and i know I
am allowed to do that, but I am not sure how much source code I need to
release under CDDL.
Am I allowed to do the following?:
- take the data structure
- save it in a .h file, which will have the required license text present.
- make just this .h file open source and leave the .c files that use the data
structure closed-source.
Thanks,
Amol
If you're so horridly worried about licensing nits, I suggest to sidestep
_that_ problem.
Compare struct direct from:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/fs/ufs_fsdir.h
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ufs/dir.h?rev=1.12
The first one, CDDL/OpenSolaris, is:
struct direct {
uint32_td_ino; /* inode number of entry */
ushort_td_reclen; /* length of this record */
ushort_td_namlen; /* length of string in d_name */
chard_name[MAXNAMLEN + 1]; /* name must be no longer than this */
};
The second one, BSD/FreeBSD, is:
struct direct {
u_int32_t d_ino;/* inode number of entry */
u_int16_t d_reclen; /* length of this record */
u_int8_t d_type; /* file type, see below */
u_int8_t d_namlen; /* length of string in d_name */
char d_name[MAXNAMLEN + 1];/* name with length = MAXNAMLEN */
};
Layout compatible, but the second one is BSD licensed.
Finally:
For the real license zealots, pick:
http://lxr.linux.no/source/include/linux/ufs_fs.h#L326
In short, you have all options.
FrankH.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] FW: USB disk at mini root
On Thu, 19 Jul 2007, Murugathasan Simon wrote: Hi Anybody who can help? logger(1) - the command should do exactly what you want ... FrankH. Regards Simon Simon Murugathasan Customer Solution Architect Central Architecture and Design, FPM FUJITSU Lovelace Road, Bracknell, Berks, RG12 8SN Tel: +44 (0) 870 234 or internally 7302 8100 Mob: +44 (0) 778 715 1861 E-mail: [EMAIL PROTECTED] Web: http://uk.fujitsu.com Fujitsu Services Limited, Registered in England no 96056, Registered Office: 22 Baker Street, London, W1U 3BW This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 19 July 2007 11:38 To: Murugathasan Simon Subject: Re: USB disk at mini root I think you'd better send this question to [EMAIL PROTECTED] I am not familiar with syslogd. I just know special function calls are needed to generate syslog message. I don't know how this can be done simply by scripts. Sophia Murugathasan Simon wrote: Sophia, Thanks for your help. Can I ask one more question on Sol10? I am trying to run some scripts under rcS.d rc2.d on the way up after a reboot, the problem is that no messages are displayed on the console even though the scripts ran successfully. I've not gone through the service route (ie creating xml file and then register on the repository). Do you know why this is happening? Is it due syslogd is not running at that time the script execution? Thanks Regards Simon Simon Murugathasan Customer Solution Architect Central Architecture and Design, FPM FUJITSU Lovelace Road, Bracknell, Berks, RG12 8SN Tel: +44 (0) 870 234 or internally 7302 8100 Mob: +44 (0) 778 715 1861 E-mail: [EMAIL PROTECTED] Web: http://uk.fujitsu.com Fujitsu Services Limited, Registered in England no 96056, Registered Office: 22 Baker Street, London, W1U 3BW This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 21 June 2007 09:03 To: Murugathasan Simon Cc: [EMAIL PROTECTED] Subject: Re: USB disk at mini root USB disk is supported at mini root. Are you sure the disk was not detected? What is prtconf -D result? And what is format -e result? If you cannot see the disk device in the outputs, please try to insert it again to see if there is any change. Once you can see the disk, use mount command to manually mount it. For cdrw and cdrecord usage ,please check the manpages. This list may not give you more information than that. Murugathasan Simon wrote: Hi, How do I make the USB disk available at mini root? I am trying to make bootable Solaris 10 DVD and then put the flash archive either on the same DVD or on a USB disk but unable to detect once I've booted off the customised Sol 10 DVD (at present I can't fit the flash archive on the same DVD so looking at a USB disk option)? Secondly, is it possible either to use cdrw or cdrecord to write multiple sessions? In other word if I can't fit everything on one DVD try to continue with a second DVD. Thanks Regards Simon *Simon Murugathasan * *Customer Solution Architect* *Central Architecture and Design, FPM* *FUJITSU Lovelace Road, Bracknell, Berks, RG12 8SN *Tel: +44 (0) 870 234 or internally 7302 8100 Mob: +44 (0) 778 715 1861 E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]___ _Web: ___http://uk.fujitsu.com_ BLOCKED::http://uk.fujitsu.com Fujitsu Services Limited, Registered in England no 96056, Registered Office: 22 Baker Street, London, W1U 3BW *This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free.* ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Windows switcher: Wine for Solaris ( DC++ )?
On Fri, 27 Jul 2007, Joerg Schilling wrote: Orvar Korvar [EMAIL PROTECTED] wrote: In my opionion, Blastwave and the likes, should be high on Sun's priority list. It seems that to compile a program under Solaris takes years of experience. Sun and you all guys are doing a terrific job with Solaris, and I and many more really appreciate what you do. Btw, Linux sucks! :o) I dont like Linus and as Stallman said: well, Im not the one who wants to call GNU for Stallmanix. It seems hodge-podge helter skelter. Not stable APIs and stuff. Thanx for your time reading my first steps into the Solaris world, on my way on becoming an expert!! ;o) Software that has been well written for portability does not givee problems whencompiling on Solaris. In former times, all software did follow Open Source ethics and was made cleanly portable to all important platforms. Read on ... I really hope that the free availability of Solaris and Sun Studio will change things back to a state we did have in the early 1990s where software usually did work out of the box on SunOS. That's the difference - not so much that people in the late 80s and early 90s were writing more portable software. The main freeware/opensource target platform at that time was SunOS4 and software naturally worked there. Trying to compile the same on HP/UX 8.x didn't usually succeed out of the box, nor (often enough) trying to compile the same thing on a Solaris 2 / SunOS 5 machine. Or, gasp, the then-still-infant early Linux versions. Some people managed to write properly portable software, but in many cases there's that platform-specific interface here and that proprietary thing here, and ah, yea, all those funky differences in what libraries to link with on what platforms (-lnsl -lresolv -lsocket, anyone ?). The main opensource target platform these days is Linux. And even there, compiling a package on Fedora 7 that works nicely on Debian Etch may well fail. This is just better hidden from you as the distributors do that work for you, mostly ... I don't think from but it then ran fine on SunOS one can conclude that the quality of code in the early 90s was that much better. There were less half-completed/abandoned/unmaintained opensource projects out there back then... FrankH. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] lex flex
On Wed, 18 Jul 2007, ÌÕœÝ Tao Jie wrote: Dear all: There're two lexical analyzer generator in Solaris/OpenSolaris /usr/ccs/bin/lex /usr/sfw/bin/flex What's the difference between these 2 tools? Are they replaceable? http://flex.sourceforge.net/manual/Lex-and-Posix.html#Lex-and-Posix Thanks in advance. p.s. And what about yacc and bison? Bison's manual claims that 'bison -y' accepts yacc input, and bison were 'upward compatible' with yacc. That means parsers written for yacc can be instantiated with bison. The reverse may or may not be true - depending on whether bison features have been used that yacc doesn't have. Although the bison manual isn't very clear on where exactly the differences are, i.e. what bison constructs might need to be avoided. FrankH. Regards TJ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] The reason for non-working arrows and backspace?
On Wed, 4 Jul 2007, [EMAIL PROTECTED] wrote: Hi, although I really like Opensolaris I find really hideous having the terminal spit out control sequences when hitting arrow keys and backspace instead of moving the cursor (the only extra key that works correctly is Del, and it works backwards Is this with GNOME Terminal? You can set the backspace/delete key to more sane values. Also, you may want to change your shell to tcsh or bash. The latter is one of the things that always nags at me. Ever noticed that when you log into a SPARC box via serial line, arrow keys actually work in ksh. Log into the same SPARC box via other means, and they won't. Why on earth is this so ? (switched to bash for no other reason than to have working arrow keys) FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Slow usb flash-drive performance
On Tue, 3 Jul 2007, Lurie wrote: The read speed of the same memory stick in linux is around 13mb/s, and in Solaris it's barely 3.5mb/s, it seems to be a vfat issue though, as if I format the drive with ufs it seems fast enough, but this isn't really a solution as it loses its flexibility (can't read in windows, can't write in linux, etc..). Has anyone else been experiencing this ? Yes, it's normal. Currently running snv_60, but had the same issue with all the previous builds I've used. Not surprised. If there were any quick turnkey solution to PCFS performance, I'd love to be the first to tell you. Have stared into the PCFS code too long, reaching the point of mental derangement, and what one finds there is not pretty. If anyone's interested in a bit more background, check the following bugIDs: http://bugs.opensolaris.org/view_bug.do?bug_id=6498039 http://bugs.opensolaris.org/view_bug.do?bug_id=6420811 http://bugs.opensolaris.org/view_bug.do?bug_id=4993461 http://bugs.opensolaris.org/view_bug.do?bug_id=4293035 FrankH. Thanks. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Suggestion: PCFS Open Development Project
On Sat, 2 Jun 2007, Martin Cerveny wrote: Hello, I've put a webrev of the so-far tested part of the rewrite here: http://cr.grommit.com/~frankho/webrev-pcfs/ if you're curious. There's far more to come, trickling in ever so slowly. Can you make webrev compare against ssh://[EMAIL PROTECTED]/hg/onnv/onnv-gate ? Should be no difference - there's only one set of PCFS sources, and the fix throughput is minimal. In which way is the above webrev lacking ? Many things are missing like cp_to_utf8(). ? Missing from where ? When will this project be officially visible ? At the moment, it looks like a multi-month delay. FrankH. Thanks, M.C This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
