Re: [osol-discuss] SXCE95 extremely unstable on x64 laptop

[Frank Hofmann]

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

[Frank . Hofmann]

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] pci driver locking

[Frank . Hofmann]

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] ps -ef running really slow on non-global zone

[Frank . Hofmann]

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 " 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//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

[Frank . Hofmann]

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] OT - [ug-bosug] Open Source, 450 BC

[Frank . Hofmann]

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 , during the earliest period of
>> the [Romane] Republic the laws were kept secret by the 
>> *pontifices
>> * and other representatives of the 
>> patricianclass, and were enforced 
>> with untoward severity, especially against the
>> plebeian  class. A plebeian named
>> Terentilius  proposed in 462 
>> BCthat an official legal
>> code  should be published, so
>> that plebeians could not be surprised and would know the law.
>>
>> Patricians long opposed this request, but in ca. 450 
>> BC,
>> a Decemvirate , or board of ten
>> men, was appointed to draw up a code. ...
>>
>> The first Decemvirate  completed
>> the first ten codes in 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 , the second
>> Decemvirate completed the last two codes, and after a 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 
>> bronze)
>> which were posted in the Roman 
>> Forumso that all Romans could read 
>> and know them. - from 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] USB drive for Linux -> OS migration: file system?

[Frank . Hofmann]

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

[Frank . Hofmann]

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] filesync depth

[Frank . Hofmann]

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

[Frank . Hofmann]

On Tue, 24 Jun 2008, takafumi ashiba wrote:

> Hi FrankH,
>
> Thank you for your reply.
>
> I would like to use filesync to backup from local disk(UFS) to file server.
> The size of local disk is 3TB. so, I plan to backup incrementaly everyday.
> I think to use ufsdump & ufsrestore. but ufsdump can't backup until level 9.
> And if I delete a file which backuped yesterday, but a file can't delete on 
> file server.
> So file server's disk is increased forever.
>
> By the way, If rsync is implemeted in solaris,  I wants to use that.

Then please do so, because it's there, actively maintained, and does, for 
all your description, seem to do what you want.

filesync is for "small syncs" - no more than e.g. a project work 
directory, a single user's home directory (or better: documents folder). 
It never was meant to be a whole-server-backup mechanism.

FrankH.

>
> Because the performance of filesync is slow.
> I think this problem is caused by small block size.
> #define   COPY_BSIZE  8192/* block size for file copies   */

The code is ancient, no functional updates since about 1997. Behaviour on 
current systems could therefore best be characterized by "showing symptoms 
of bit rot".

FrankH.

>
> Regards,
>
>
> 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] filesync depth

[Frank . Hofmann]

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] cdrw command & burning CD

[Frank . Hofmann]

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] [ufs-discuss] PANIC! mounting cdrom slice on b78

[Frank . Hofmann]

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] [ufs-discuss] PANIC! mounting cdrom slice on b78

[Frank . Hofmann]

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] PANIC! mounting cdrom slice on b78

[Frank . Hofmann]

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: 8005003b cr4: 6f8
> 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 "" 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: 8005003b cr4: 6f8
>> 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:   

Re: [osol-discuss] how to mount my second harddisk with ext3 filesystem

[Frank . Hofmann]

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] Need advice to select clustering OS

[Frank . Hofmann]

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] How to get current working directory of the current process in the kernel

[Frank . Hofmann]

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 
>>
>> 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] How to get current working directory of the current process in the kernel

[Frank . Hofmann]

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 

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

[Frank . Hofmann]

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] The ZFS inventor and Linus sitting in a tree?

[Frank . Hofmann]

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] VirtualBox

[Frank . Hofmann]

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] open solaris installed to native linux partition?

[Frank . Hofmann]

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] open solaris installed to native linux partition?

[Frank . Hofmann]

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] lookuppnvp:: i just do not get it...how it get vnode by given pathname?

[Frank . Hofmann]

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] the progress of "open" system call !!!

[Frank . Hofmann]

On Wed, 7 May 2008, xulari wrote:

> when we open a file, how solaris get the vnode of this file from the path of
> the file??? related with dnlc

Try this:

dtrace -Fn "
syscall::open64:entry {self->t=1}
fbt::: /self->t == 1/ {}
fbt::fop_*:entry /self->t/ {self->t++}
fbt::fop_*:return /self->t/ {self->t--}
syscall::open64:return {self->t=0; exit(0)}
"

and read through the output.

As with your previous question, what are you trying to achieve ?

FrankH.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] help me...! system call rename(2)

[Frank . Hofmann]

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

[Frank . Hofmann]

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/" 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?

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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)

[Frank . Hofmann]

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] USB drive unusable (with snv_85)

[Frank . Hofmann]

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] Solaris 10 system hangs

[Frank . Hofmann]

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

[Frank . Hofmann]

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=en&q=kmem_flags&a=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] panic[cpu1]/thread=d3738de0: kernel heap corruption detected

[Frank . Hofmann]

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 ...
>
> ─ Confirm Information for pcn0
> ─
>
>  > 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
>
>
>
>
>
>
>
> ───
>Esc-2_ContinueEsc-4_ChangeEsc-6_Help
>
>
> ─ Date and Time
> 
>
>  > 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.
> ─ Solaris Interactive Installation
> ─
>
>  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 selections (called a
>  profile) will be displayed.
>
>  There are two ways to install your Solaris software:
>
>   - "Standard" installs your system from a standard Solaris Distribution.
>  Selecting "Standard" allows you to choose between initial install
>  and upgrade, if your system is upgradable.
>   - "Flash" installs your system from one or more Flash Archives.
>
>
>
> 
> kernel memory allocator: buffer freed to wrong cache
> buffer was allocated from kmem_alloc_320,
> caller attempting free to kmem_alloc_8.
> buffer=d36f2400  bufctl=0  cache: kmem_alloc_8
>
> 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_mag

Re: [osol-discuss] kernel threads

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank Hofmann]

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 i38

Re: [osol-discuss] Kernel Panic with sfmmu_tsbmiss_exception+0x54() in stack trace

[Frank . Hofmann]

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

[Frank Hofmann]

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.29  .
> 05/01/2008  11.29  ..
> 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

Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlockedonSolarisx86machine

[Frank Hofmann]

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 "$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

[Frank . Hofmann]

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 onSolarisx86machine

[Frank Hofmann]

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

[Frank Hofmann]

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] SIGSEGV in libc.so.1`_malloc_unlocked onSolarisx86 machine

[Frank Hofmann]

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 somepl

Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on Solaris x86 machine

[Frank . Hofmann]

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] SIGSEGV in libc.so.1`_malloc_unlocked on Solaris x86 machine

[Frank . Hofmann]

On Mon, 24 Dec 2007, Vamsee Priya 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

Try libumem, see manpage, usually as simple as:

LD_PRELOAD=libumem.so UMEM_DEBUG=default /path/to/your/program

and then attach mdb to it. If you actually need to run it under mdb 
control to start with, then do:

::setenv LD_PRELOAD libumem.so
::setenv UMEM_DEBUG default
::run

If you're not getting coredumps, check the "coreadm" settings for the 
machine and/or the process in question. That should tell you where (if not 
the current working dir of the process) corefiles would end up. Also check 
"ulimit -c" on whether the coredumpsize has been unduly limited.

Once things crash with libumem and umem debugging enabled, rum 
"::umem_status" from within mdb.

> Sun studio compiler to run dbx.
> Any more tools with which I can debug futher?

a) check coreadm and ulimit -c settings
b) try libumem and UMEM_DEBUG. See libumem(3LIB).

FrankH.

>
> Thanks
> Priya
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of [EMAIL PROTECTED]
> Sent: Monday, December 24, 2007 2:27 PM
> To: Vamsee Priya
> Cc: opensolaris-discuss@opensolaris.org
> Subject: Re: [osol-discuss] SIGSEGV in libc.so.1`_malloc_unlocked on
> Solaris x86 machine
>
>
>> Hi All
>>
>> When I use my 32 bit binary on Solaris x86 machine, I get a
> segmentation
>> fault with the following stack trace.
>>
>> libc.so.1`_malloc_unlocked+0x14c(4000, 3, 80a3130, 1, 8046a38, 805763f)
>> libc.so.1`malloc+0x39(4000, 0, 8046a1c, fef9e455, fef9158c, 4)
>> meta_del+0x13(2, 80a3100, 10, 0)
>> standby_fix+0x75e(2, 8047e8f, 8046b10, 0)
>> standby+0xcc(2, 8047e8f, 0, 0, 8046bc7)
>> main+0xd59(6, 8047d80, 8047d9c)
>> _start+0x80(6, 8047e48, 8047e67, 8047e6a, 8047e7c, 8047e8f)
>>
>
>
> This stacktrace is symptomatic for memory corruption; because the 32 bit
>
> and 64 bit allocators round up differently, it is possible that the
> error
> is masked in 64 bit mode.
>
> Start debugging, e.g., using watchmalloc or libumem or dbx run time
> access
> checking.
>
> 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] system reboot after panic

[Frank . Hofmann]

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):
>
> 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):
>
> 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
>

Re: [osol-discuss] [perf-discuss] how to disable sun cc optimization partly in program?

[Frank Hofmann]

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=5322&r2=5084
http://src.opensolaris.org/source/diff/onnv/onnv-gate/usr/src/uts/i86pc/os/mlsetup.c?r1=5338&r2=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 f

Re: [osol-discuss] [perf-discuss] how to disable sun cc optimization partly in program?

[Frank Hofmann]

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 

Re: [osol-discuss] help - coredump & third party app developer is blaiming O/S

[Frank . Hofmann]

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  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

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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] Nameclash on svn_77 because Sun is ignoring PSARC discussions

[Frank . Hofmann]

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] wanted: way to "sync" from openboot without crash dump

[Frank . Hofmann]

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 " 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] wanted: way to "sync" from openboot without crash dump

[Frank . Hofmann]

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] wanted: way to "sync" from openboot without crash dump

[Frank . Hofmann]

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] Porting a kernel module from Solaris SPARC platform to Solaris X86 platform

[Frank . Hofmann]

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] Does Solaris has similar Linux command "mount -o" which can mount IMG file with specified offset?

[Frank . Hofmann]

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] common ( Win64/Linux/SNV/UNIX ) filesystem du jour ?

[Frank . Hofmann]

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] mounting more than two FAT volumes in an extended partition

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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

[Frank . Hofmann]

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)

[Frank . Hofmann]

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

[Frank Hofmann]

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

[Frank Hofmann]

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

[Frank Hofmann]

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 
>> # 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] funding priorities [was Re: A big PCFS change in the pipeline]

[Frank Hofmann]

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=1&minDisplay=on&bugStatus=1-dispatched&category=kernel&subcategory=pcfs
http://bugs.opensolaris.org/bugdatabase/search.do?process=1&minDisplay=on&bugStatus=2-incomplete&category=kernel&subcategory=pcfs
http://bugs.opensolaris.org/bugdatabase/search.do?process=1&minDisplay=on&bugStatus=3-accepted&category=kernel&subcategory=pcfs
http://bugs.opensolaris.org/bugdatabase/search.do?process=1&minDisplay=on&bugStatus=4-defer&category=kernel&subcategory=pcfs
http://bugs.opensolaris.org/bugdatabase/search.do?process=1&minDisplay=on&bugStatus=5-cause+known&category=kernel&subcategory=pcfs
http://bugs.opensolaris.org/bugdatabase/search.do?process=1&minDisplay=on&bugStatus=6-fix+understood&category=kernel&subcategory=pcfs
http://bugs.opensolaris.org/bugdatabase/search.do?process=1&minDisplay=on&bugStatus=7-fix+in+progress&category=kernel&subcategory=pcfs
http://bugs.opensolaris.org/bugdatabase/search.do?process=1&minDisplay=on&bugStatus=9-fix+failed&category=kernel&subcategory=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

[Frank Hofmann]

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] A big PCFS change in the pipeline

[Frank Hofmann]

On Thu, 6 Sep 2007, Kaiwai Gardiner wrote:

[ ... ]
> 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?

I'm not aware of any Sun-internal resource commitment for that :(

>
>>> Also, is there an eta on when FATex will supported?
>>
>> What's FATex ?
>
> Oops, I meant exFAT: http://en.wikipedia.org/wiki/ExFAT

This is fascinating !

Is there a more detailed specification out there, that does more than give 
a feature list ? Anything that at least would hint at the metadata 
structure ?

FrankH.

>
> Matthew
>
>
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] A big PCFS change in the pipeline

[Frank Hofmann]

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

[Frank Hofmann]

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

[Frank Hofmann]

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

Re: [osol-discuss] A big PCFS change in the pipeline

[Frank Hofmann]

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

[Frank Hofmann]

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

[osol-discuss] A big PCFS change in the pipeline

[Frank . Hofmann]

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

[Frank Hofmann]

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

[Frank Hofmann]

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] Using script (perl or korn) to determine opened ports (Method must work in Solaris 8, 9 and 10)

[Frank . Hofmann]

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] snv_70 odd behavior

[Frank . Hofmann]

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] SXCE 70's installer and laying out file systems

[Frank . Hofmann]

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] Can't use DVD and USB, why?

[Frank Hofmann]

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?

[Frank Hofmann]

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] Can't use DVD and USB, why?

[Frank Hofmann]

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] An Open Letter to the Solaris Community.

[Frank Hofmann]

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.

[Frank Hofmann]

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

[Frank Hofmann]

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

[Frank Hofmann]

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]
>>> ___
>>> _Web: ___http://uk.fujitsu.com_ 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++ )?

[Frank Hofmann]

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