Re: [osol-discuss] USB pen drive not detected
> I'm having some problems > with a new USB drive I just bought, Opensolaris > snv_134 is detecting it at all, Are there any error messages logged to the console / the /var/adm/messages file when you hotplug the USB drive? tail -f /var/adm/messages and hot plug the USB drive. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] No network/Internet
> >> j...@opensolaris:~$ ifconfig nge0 > >> ifconfig: status: SIOCGLIFFLAGS: nge0: no such interface > > > > nVidia MCP61 should work in build 73 or newer: > >http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6497473 > > Is the nge driver matter here? The original message said: > ... > And finally, this is my network adapter: BroadCom AC131 (MCP61 nForce 4 LAN). > > According to the Foxconn web page the NIC is Broadcom AC131: > > http://www.foxconnchannel.com/product/Motherboards/detail_overview.aspx?id=en-us412 As far as I understand it, the Broadcom AC131 is the PHY chip attached at the nVidia MCP61 network controller. The nVidia MCP61 ethernet controller should be handled by the Solaris nge driver. The device driver utility is reporting that the nge driver will be used with the nVidia MCP61 device: http://www.opensolaris.org/jive/thread.jspa?messageID=502914#502914 Maybe the nge driver needs some special code to handle the Broadcom AC131 PHY ? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] No network/Internet
> j...@opensolaris:~$ ifconfig nge0 > ifconfig: status: SIOCGLIFFLAGS: nge0: no such interface nVidia MCP61 should work in build 73 or newer: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6497473 Is there a new network interface after ifconfig -a plumb ? In case the interface nge0 is now visible: does ifconfig report the correct MAC address for the nge interface? Sometimes the MAC is reversed, and the nge interface does not work. Like this: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6658667 IIRC, although bug 6658667 is marked as closed / fixed, there were still a few cases where the nge interface reports the reversed MAC, and you had to use the workaround from bug 6658667... > The only adapter available after doing this commands is now "lo0". > > - But the annoying fact is that if i run OpenSolaris > under VirtualBox, the internet works. VirtualBox emulates an intel hw ethernet nic, so that a different solaris driver is used. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] C programming, invalid argc value
> I retested with gcc 3.4.3 and everything works fine. > Using the 4.3.3 compiler, the breakpoint is being set right at the address of > main > before the prologue code is executed. I will need to investigate why > that is happening. Hmm... On opensolaris b134, after "pkg install gcc-43", and compiling the test programm with the new installed gcc 4.3.3 compiler (with "-g" or with "-g -O") it still works for me. Which assembler is used by your gcc 4.3.3? gcc 4.3.3 on opensolaris b134 uses /usr/bin/gas, and that is gnu assembler version 2.19. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] C programming, invalid argc value
> I can reproduce the problem on my system running bash so I don't think > it is related the the shell: > > (gdb) b main > Breakpoint 1 at 0x8050ccc: file g.c, line 4. > (gdb) r > Starting program: /home/gvasick/a.out > > Breakpoint 1, main (argc=260904, argv=0xfef90018) at g.c:4 Which compiler, compiler version, gdb version did you use? What compilation flags? What does the test program look like? Using Opensolaris b134, gcc 3.4.3, gdb 6.8, a simple "hello, world" type test program, and compilation options "-g -O" it works for me. For me, the "b main" command sets a breakpoint at offset 12 relative to the symbol "main", after main's function prologue. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] unable to mount volume [usb drives won't mount]
> here's the lshal with all the entires > pertaining to this usbstick > there is 'volume' entry Hal's volume entry for the usb device looks good. I think the next step is that hal-storage-mount gets started (?), and it is supposed to mount the pcfs file system. Are there any error messages in hald service' log file, /var/svc/log/system-hal:default.log ? In case that does not help: You could try to enable verbose debug messages for "hald", and check /var/adm/messages for any errors / failures when trying to mount the usb device. Note that the hald(1M) manual page example for enabling hal debug output is incorrect and does not work. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6526240 To enable hald verbose debug messages, edit the file /lib/svc/method/svc-hal and start the hald process like this: /usr/lib/hal/hald --daemon=yes --verbose=yes --use-syslog After making that change, restart the hal service with "svcadm restart hal". You should now find lots of hal debug messages in /var/adm/messages. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] unable to mount volume [usb drives won't mount]
> fstype gives unknown fs_type Hmm, fstyp should work, too. Did you use the block device, /dev/dsk/... ? > also, here's the lshal with all the entires > pertaining to this usbstick > there is 'volume' entry > volume.label = 'USB4G' (string) ... > volume.fstype = 'pcfs' (string) Hal seems to have no problem finding the correct volume label, and file system type. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] unable to mount volume [usb drives won't mount]
> yes. this drive is fat32. since the thread started, i > reformated and made sure it had a volume label (which > it didn't before). Did you already try the "fstyp -v /dev/dsk/c6t0d0p1" command? See also this thread: http://opensolaris.org/jive/thread.jspa?messageID=344425#344425 (An invalid volume label seems to prevent automounting a fat filesystem) -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] unable to mount volume [usb drives won't mount]
> yes. this drive is fat32. since the thread started, i > reformated and made sure it had a volume label (which > it didn't before). it still does not automount, but > command line mount now works. STILL ... i'd like to > figure out why drives aren't automounting. Ok, so usb device drivers, sd disk driver and the pcfs filesystem isn't the problem. Going back to the lshal output... The storage.bus = 'usb' entry with info.category = 'storage' is for the usb disk drive. Is there an info.category = 'volume' entry following the storage entry? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] unable to mount volume [usb drives won't mount]
> pfexec fdisk -R -W - /dev/rdsk/c6t0d0p0 > ... > * IdAct Bhead Bsect BcylEhead Esect EcylRsect Numsect > 1101 1 0 25463 488 63 7855722 ,,, Ok, and "pfexec fstyp -v /dev/dsk/c6t0d0p1" ? Seems to be a pcfs filesystem. What happens when you try a manual mount? pfexec mount -F pcfs /dev/dsk/c6t0d0p1 /mnt -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] unable to mount volume [usb drives won't mount]
> block.device = '/dev/dsk/c6t0d0p0' (string) ... > info.product = 'USB 2.0 FD' (string) Hmm, is that an USB floppy drive? I guess there is a floppy media inserted in the drive. Is the media ok? Floppy media usually has no MBR partition table, so pfexec fdisk -R -W - /dev/rdsk/c6t0d0p0 will probably report junk values in the fdisk output. Since there is no MBR partition table, you also have to check the file system format on the /dev/dsk/c6t0d0p0 device, pfexec fstyp -v /dev/dsk/c6t0d0p0 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] unable to mount volume [usb drives won't mount]
> b134 > usb sticks and usb drives won't automount or by cl > can find devices with format -e or rmformat -l, so > they're there ... just can't mount What kind of file system is used on these usb devices? FAT? Or NTFS? What is reported by "pfexec fdisk -R -W - /dev/rdsk/c?t0d0p0" ? (where /dev/rdsk/c?t0d0p0 is the logical node name from rmformat -l ) And "pfexec fstyp -v /dev/dsk/c?t0d0p1" "pfexec fstyp -v /dev/dsk/c?t0d0p2" "pfexec fstyp -v /dev/dsk/c?t0d0p3" "pfexec fstyp -v /dev/dsk/c?t0d0p4" ? (Note: /dev/dsk/... , instead of dev/rdsk/... ) > gnome gives the popup error 'unable to mount volume' > and cl gives 'no block device' error. What is the exact command you tried when trying to mount the device? Seems as if you tried to mount using the char device /dev/rdsk/... instead of the block device /dev/dsk/ > weirdthis worked perfectly up until recently. all > of a sudden ... no usb drives can mount. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] A stupid question probably - forgive me
> Where exactly can I get SNV build 134 from. http://www.genunix.org/ http://www.genunix.org/distributions/indiana/osol-dev-134-x86.iso -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Trouble formating usb external hard drive.
> I have a 1Tbyte usb external HD that I want to be > able to read with windows and b134. I have tried all > of the below but am unable to get solaris to read and > write to it. > > mkfs -F pcfs -o fat=32 /dev/rdsk/c10t0d0p1 > *Bad Sig on master boot record! The following commands would emulate creating a 1TB (marketing TB) pcfs filesystem on a lofi device: # mkfile -n 1953125000b /var/tmp/1tb # lofiadm -a /var/tmp/1tb /dev/lofi/1 # fdisk /dev/rlofi/1 -> 1Create a partition -> D=FAT32LBA -> 100 -> 6Exit (update disk configuration and exit) # fdisk -R -W - /dev/rlofi/1 * /dev/rlofi/1 default fdisk table * Dimensions: *512 bytes/sector * 5 sectors/track * 1 tracks/cylinder * 43944 cylinders ... * * IdAct Bhead Bsect BcylEhead Esect EcylRsect Numsect 12128 19531 2 25463 10235 1953046635 0 00 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 # mkfs -F pcfs -o fat=32 /dev/rlofi/1:c Construct a new FAT file system on /dev/rlofi/1:c: (y/n)? y # mount -F pcfs /dev/lofi/1:c /mnt # df -h /mnt Filesystem size used avail capacity Mounted on /dev/lofi/1:c 931G64K 931G 1%/mnt -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Trouble formating usb external hard drive.
> mkfs -F pcfs -o fat=32 /dev/rdsk/c10t0d0p1 > *Bad Sig on master boot record! Did you use "fdisk" on the /dev/rdsk/c10t0d0p0 device and did you create a Windows LBA primary fdisk partition? > mkfs -F pcfs -o fat=32 /dev/rdsk/c10t0d0p1:c > *No such logical drive (missing extended partition entry) That should be /dev/rdsk/c10t0d0p0:c but it needs the windows lba fdisk partition entry. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] unable to break out of X
> I attempted to change my display settings and somehow > broke X. It only displays that x can not be started > hit enter for a console prompt. The console prompt > never appears. If I can not get to to the prompt how > can I fix it? Can anyone provide suggestion on how > to boot without X attempting to start? I am using > Opensolaris x86 on a Dell optiplex 755. I do not > know the build because I can not get in. Boot into single user mode? In the GRUB boot menu, edit the menu entry and delete the splashimage, foreground and background lines, remove the ",console=graphics" option at the end of the kernel$ line, and append option "-s" (single user mode) at the end of the kernel$ line. Boot using the modified entry. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] where is on-src.tar.bz2
> The ON source was available for us to download at - > OpenSolaris Download Center > http://dlc.sun.com/osol/on/downloads/current/ > > But it is missing for some time. Anybody knows why? Found on the above page: Source tarballs have been deprecated in favour of the onnv project's Mercurial repository [*]. Please see the onnv project page for more information on how to checkout/clone the repository to download the source. [*] http://opensolaris.org/os/project/onnv -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b134 panics on bootup after install
> I have installed b134 on a clevo laptop. The live cd > booted just fine and the install went on without a > problem. After the install when I reboot the system > comes up with the initial grub screen just after the > OS is selected the screen goes black and the system > reboots. Did you try tz boot in text mode with the kernel debugger enabled? What kind of panic do you get ? Edit the grub menu entry, remove the splashimage, foreground and background lines; remove the ",console=graphics" option from the kernel$ line, and append options " -kv" at the end of the kernel$ line. Boot using the modified entry. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Transfered 23 GB over SCP from USA to Germany
> > The differences reported by cmp -l are in octal; > > so this is actually a single bit error. > > But then TCP checksums should discover the problem That bit could have fllipped both on the sending or the receiving machine (before or after TCP is used). -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Transfered 23 GB over SCP from USA to Germany
> I redownloaded the file cpartad and compared it with > "cmp -l" with the old file: > $ cmp -l cpartad cpartad.old > 4962108197 271 371 > > $ bc > ibase=10 > obase=2 > 271 > 1 > 371 > 101110011 > > It seems that 5 bits are wrong of the 23GB file transfer. The differences reported by cmp -l are in octal; so this is actually a single bit error. % bc obase=2 ibase=8 271 10111001 371 1001 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Transfered 23 GB over SCP from USA to Germany
> When I compared the two files with md5sum on each > side, I got different checksums. > I did so a split of the file to 5 GB parts and compared: > > Solaris: ... > 199d15f5204c14a97d29f86b14cd154b cpartad > Linux: ... > 0509b68893216f894ee394c0ab212cd2 cpartad You could transfer the "cpartad" 5 GB part to the other side, make sure that this time the 5 GB part isn't corrupted, and "cmp .-l" the corrupted and non-corrupted part. How many bytes are different? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] install Open Solaris on usb memory stick
> Can someone point me to the procedure for how to > install on a memory stick. Should be identical to the procedure when you install to a regular hdd. It gets problematic when you try to connect the installed usb storage device to a random machine - most likely the kernel refuses to boot on the new machine (see bug 6779374 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6779374 ) The same problem exists when you connect the usb storage device on the same computer that you used for installation, but use a different usb port. OpenSolaris defect 4755 contains a modified scsa2usb kernel module to work around the issue https://defect.opensolaris.org/bz/show_bug.cgi?id=4755 But I've no idea if the 1.5 year old kernel module still works with current opensolaris. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] build fails from fresh install?
> That is, the build mail at least reported > "completed", the packages built, and I was able to > update and boot my server from the results. > > But, there are still all sorts of errors in the mail > to root. The rest of the garbage in there is all > "normal"? The "build noise differences" is ok. It compares the current successful build output against the failed build, and all the error messages from the previous build are now missing. This should go away with the next build. I think the build errors for the cpio archives are more or less ok, it's from the old svr4 packaging (bfu archives) which is going away soon. I'm not sure about the cstyle errors and warnings. Seems I have cstyle checks disabled in my nightly environment, because I don't get messages like this. The core file from dmake in usr/src/./uts/intel/core is interesting. Is that an old core file? You should manually remove it, and pay attention if subsequent builds produce random core files. Could be a hint for either a software bug in dmake, or buggy hardware (memory), or system running out of memory, -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] build fails from fresh install?
> I then did a nightly ./opensolaris.sh from within my
> environment. My build system is a dual 2.1GHz
> Celeron (64-bit) with 4GB RAM. Should be plenty.
> After about 5 hours, the job completed, and I
> received the attached mail. I did build as root,
> which may be bad, but...
>
> Nothing in there explicitly suggests that the build
> process was entirely unsuccessful, nor what I'd need
> to do to fix it.
The subject of the mail says " Nightly ... Build ... Failed.";
that build was not successful,
Have a look at the "log/log.{TIMESTAMP}/nightly.log"
file, it contains the full build log
Could be missing perl 5.10 modules, see:
http://static.opensolaris.org/on/flagdays/pages/20100616235920.html
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting desktop to auto sleep
> The laptop still does not power down, because every > 30 seconds there is a batch of writes to the hdd drive, > apparently from zfs, and that keeps the hdd powered up. It was caused by b134 gnome-terminal. I had an iostat running in a gnome-terminal window, and the periodic iostat output is written to a temporary file by gnome-terminal. This kept the hdd busy. Older gnome-terminals (b111) didn't write terminal output to a disk file. Workaround is to use xterm instead of b134 gnome-terminal. for a command that periodically produces output Another problematic binary is firefox. It periodically writes to the sqlite database files in the profile directory $HOME/.mozilla/firefox/*.default/ -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] zfs periodic writes on idle system [Re: Getting desktop to auto sleep]
Why does zfs produce a batch of writes every 30 seconds on opensolaris b134 (5 seconds on a post b142 kernel), when the system is idle? On an idle OpenSolaris 2009.06 (b111) system, /usr/demo/dtrace/iosnoop.d shows no i/o activity for at least 15 minutes. The same dtrace test on an idle b134 system shows a batch of writes every 30 seconds. And on current opensolaris bits, on an idle system, I see writes every 5 seconds. The periodic writes prevents that the disk can enter power save mode. And this breaks the /etc/power.conf autoS3 feature. Why does zfs have to write something to disk when the system is idle? > > Putting the flag does not seem to do anything to the > > system. Here is my power.conf file: > ... > > autopm enable > > autoS3 enable > > S3-support enable > > Problem seems to be that all power managed devices > must be at their lowest power level, otherwise autoS3 > won't suspend the system. And somehow one or more > device does not reach the lowest power level. ... > The laptop still does not power down, because every > 30 seconds there is a batch of writes to the hdd drive, > apparently from zfs, and that keeps the hdd powered > up. > > The periodic writes can be monitored with: > > dtrace -s /usr/demo/dtrace/iosnoop.d -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting desktop to auto sleep
> Putting the flag does not seem to do anything to the > system. Here is my power.conf file: ... > autopmenable > autoS3enable > S3-supportenable Problem seems to be that all power managed devices must be at their lowest power level, otherwise autoS3 won't suspend the system. And somehow one or more device does not reach the lowest power level. The number of devices that are currently not at their lowest power level can be monitored on the kernel variable "pm_comps_notlowest", e.g. like this: # echo pm_comps_notlowest::print | mdb -k 0x3 When the returned number ever reaches 0, the system should start the auto suspend. On my Tecra A10 laptop running b134 the s-ata hdd and s-ata optical device are power managed, and both cpu cores are power managed. I experimented with these additional /etc/power.conf entries to get the hdd and dvd drive powered down: device-thresholds /p...@0,0/pci1179,1...@1f,2/d...@0,0 (20s 20s 20s) device-thresholds /p...@0,0/pci1179,1...@1f,2/cd...@1,0 60s These physical device paths are from: # iostat -En c5t0d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: Hitachi HTS72323 Revision: C30F Serial No: Size: 320,07GB <320072933376 bytes> Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 10 Predictive Failure Analysis: 0 c5t1d0 Soft Errors: 0 Hard Errors: 10 Transport Errors: 0 Vendor: MATSHITA Product: DVD-RAM UJ880AS Revision: 1.21 Serial No: Size: 0,00GB <0 bytes> Media Error: 0 Device Not Ready: 10 No Device: 0 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0 # ls -l /dev/rdsk/c5t0d0s2 lrwxrwxrwx 1 root root 51 Feb 20 20:26 /dev/rdsk/c5t0d0s2 -> ../../devices/p...@0,0/pci1179,1...@1f,2/d...@0,0:c,raw # ls -l /dev/rdsk/c5t1d0s2 lrwxrwxrwx 1 root root 52 Feb 20 20:26 /dev/rdsk/c5t1d0s2 -> ../../devices/p...@0,0/pci1179,1...@1f,2/cd...@1,0:c,raw I also experimented with disabling event mode for cpupm, by changing cpupm to poll mode in power.conf, cpupm enable poll-mode The laptop still does not power down, because every 30 seconds there is a batch of writes to the hdd drive, apparently from zfs, and that keeps the hdd powered up. The periodic writes can be monitored with: dtrace -s /usr/demo/dtrace/iosnoop.d After I lowered the hdd timeouts to 7 seconds, the hdd would transition from active->idle->standby->off before the next batch of zfs writes (in 3*7 = 21 seconds), and the system did automatically enter S3. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting desktop to auto sleep
> keithk wrote: > > > Hi eam1, > > I did. After which, I reboot the system. Still nothing happens. > > This is a well known bug that was introduced with SXCE build 130. Is there a bug filed to track this problem? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Getting desktop to auto sleep
> I am running Opensolaris snv_134 on a dell computer. > I am able to suspend the desktop at will, but does > not seem to be able to set a timeout for the desktop > to suspend after a configurable idle time using Power > Manager. The Power Manager does not offer me the > slider where I can see the idle time like I can when > I am on Ubuntu Linux. This might work by setting "autoS3 enable" (and "autopm enable") in /etc/power.conf, see man power.conf(4) -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] append new disk, has no /dev/dsk node for entire disc
> ls /dev/dsk/c4t?d0 > /dev/dsk/c4t0d0 /dev/dsk/c4t1d0 /dev/dsk/c4t2d0 > /dev/dsk/c4t3d0 /dev/dsk/c4t4d0 Are you sure those /dev/dsk/c*d0 entries are device nodes? Try "ls -l /dev/dsk/c*d0" and "ls -lL /dev/dsk/c*d0", maybe they are files that have been created by accident by a user user with root privileges? > where /dev/dsk/c4t5d0 ??? Such a device does not exist. c?t?d? is the prefix of a disk device name, it is followed by p0 (whole disk), p1 .. pN (fdisk partition) or s0 .. sN (solaris slice). -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] My box crashed (amd64 on 134a)
> not found: ddi_get_parent_data > not found: kdi_dvec_memavail ... > krtld: error during initial load/link phase > > krtld could neither locate nor resolve symbols for: > /platform/i86pc/kernel/amd64/unix the boot archive. Most likely the boot archive file /platform/i86pc/amd64/boot_archive and/or /platform/i86pc/boot_archive is corrupted. Try to fix it by building from scratch a fresh set of boot archive files. Boot from the LiveCD or a old working BE. Mount the broken BE, e.g. to /mnt, remove /mnt/platform/i86pc/boot_archive and /mnt/platform/i86pc/amd64/boot_archive and run "bootadm update-archive -R /mnt". Try to boot from the BE. If that doesn't fix the problem, you may have to remove or rename the /mnt/platform/i86pc/archive_cache directory hierarchy and repeat rebuilding the boot archive files. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] PC Emulator for OpenSolaris?
> Basically, is there a Windows emulator... that will allow me to > run Windows-based applications or Windows itself on > top of OpenSolaris? http://www.virtualbox.org/ -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] community driven distro...
> I don't type pathnames longer than 100 characters, > which is 20 characters wider than a normal page. > > > Try again with a path name > 100 chars and check what > > happens. I did verify a failure with Indiana build 134 > > But I don't use that on my system anyway...:-/ My opensolaris b134 system has such pathnames, e.g. under /usr/share/doc/libsigc++-2.0 Try to create a gnutar archive from that directory and unpack it with solaris tar, and check if all files are copied ok: (cd / ; /usr/gnu/bin/tar cf - usr/share/doc/libsigc++-2.0 ) | (cd /tmp ; /bin/tar xf - ) -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to configure openSolaris resolution on VirtualBox
> The vbox ticket #6181 have no help.
>
> And the problem isn't fixed.
Hmm, seems I found something...
In the guest window's "Machine" -> "Auto-resize Guest Display"
menu item ("Host-G" keyboard shortcut): is the menu item
enabled, and does it show a checked icon?
I just repeated the installation of the guest additions
in my old opensolaris b132 guest (the one from vbox
ticket #6181), this time with vbox 3.1.8 running on
opensolaris build 134. The problem is that the
"auto-resize guest display" option is not checked after
the guest additions are installed and I log out from
the gnome desktop and re-login. All I have to do is
to issue a "Host-G" command, and the guest window
is automatically adjusted.
So it seems that the problem is that under certain
unknown conditions the "auto-resize guest display"
option is not checked...
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to configure openSolaris resolution on VirtualBox
> Thank you, I will look into that problem if can help me. The vbox ticket #6181 probably won't help much. It is set to closed / fixed, but as far as I understand it, some superfluous logging was removed from the Solaris vbox guest kernel module, but the root cause for the broken auto-resizing wasn't found, and could not be reproduced by the vbox developers. And I was able to reproduce the problem on exactly one specific combination of host os / guest os / vbox version. On other combinations the auto-resizing did work just fine. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How to configure openSolaris resolution on VirtualBox
> Thank you, but I cannot adjust it as I want. > For example, I press , fullscreen the > VirtualBox, but the OS screen donot change, just fill > black around with it! Hmm, I wonder if mouse pointer integration is working with your opensolaris vbox guest? Some time ago I had a problem with the vbox guest additions for an opensolaris b132 guest; mouse pointer integration did work, but the b132 guest refused to adjust the screen size: http://www.virtualbox.org/ticket/6181 The problem didn't occur any more after I installed a b133 guest. The root cause for this problem is unknown. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Errors from USB flash drives used for booting.
> I'm getting the following errors when booting from flash: > WARNING: > /p...@0,0/pci1043,8...@1d,7/stor...@2/d...@0,0 (sd1): > Check Condition on REQUEST SENSE Hmm, the flash device seems to have signaled an error condition for some (scsi) command; and when asked for the exact cause for the error (request sense) it refused to report the error details. I guess this is one of the flash devices that needs either the "modesensevalue" or "reduced-cmd-support" workaround enabled in /kernel/drv/scsa2usb.conf -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris & SATA disks...
> 2.) Is there a negative effect if the SATA disks connected to those ports only > run as IDE (aka cmdk driver?) ata / cmdk has not 64bit dma support, so that the driver has to use dma bounce buffers to access physical memory > 4GB. Using ahci should avoid this issue. No hotplug / NCQ with ata / cmdk. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] When we install opensolaris 2009.6, does it layout a zfs file system?
> I am wondering what is the file system that > opensolaris 2009.6 creates for its installation, is > it zfs or ufs? zfs -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b137 based on tonic or otherwise
> I don't know why but I > expected that the release build to be available in > the Mercurial repository after it gets released. > > $ hg clone -r b111b ssh://anon at hg dot opensolaris dot org/hg/onnv/onnv-gate > abort: unknown revision 'b111b'! > > So no, you cannot build previous releases of the OpenSolaris > distribution making it a closed product. It's not in the mercurial repository, but there is: http://dlc.sun.com/osol/on/downloads/b111b/ http://dlc.sun.com/osol/on/downloads/ -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] krtld: failed to open
> I have a x4150 running 5.11: > 5.11 snv_85 i86pc i386 i86pc > > After upgrading the SP FW, I wasn't able to boot it up. > > After the grub menu was displayed it complained: > > krtld: failed to open > krtld: bind_primary(): no relocation information found for module > /platform/i86pc/kernel/amd64/unix > krtld: error during initial load/link phase I suspect the boot_archive file got corrupted. Boot using the failsafe grub boot entry (SX:CE), or boot from the LiveCD (OpenSolaris). Mount the hdd root filesystem, e.g. to /mnt Change the timestamp for one of the files that goes into the boot_archive (to force rebuilding the archive); and rebuild the archive: touch /mnt/etc/system bootadm update-archive -R /mnt -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Bug 6932552: B134 Splashscreen crasch Kernel must be fixed for 2010.3
> After a while I was able to grab the screen immediately before the reboot and > the following is its content: > /kernel/misc/pci_autoconfig: undefined symbole 'class_pci_items' > /kernel/misc/pci_autoconfig: undefined symbole 'class_pci' > /kernel/misc/pci_autoconfig: undefined symbole 'pcie_get_rc_dip' > WARNING: mod_load: cannot load module 'pci_autoconfig' > panic[cpu0]/thread=fec22680 failed to load misc/pci_autoconfig This problem is documented in the opensolaris dev build announcement: http://www.opensolaris.org/jive/thread.jspa?threadID=125446&tstart=0 6914346 upgrade from OpenSolaris 2009.06 (111b2) to 130 fails with stale http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6914346 After updating to build 130 or beyond, the system may panic with messages of the form /kernel/misc/amd64/pci_autoconfig: undefined symbol 'pcie_get_rc_dip' WARNING: mod_load: cannot load module 'pci_autoconfig' panic[cpu0]/thread=fbc2e3a0: failed to load misc/pci_autoconfig Work-around: Boot the original boot environment (BE) instead and correct the boot archive as follows u...@host$ pfexec beadm mount /mnt u...@host$ pfexec bootadm update-archive -F -R /mnt u...@host$ pfexec beadm unmount At this point, the new BE can be booted into. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is rxvt terminal type supported?
> OpenSolaris does not have an rxvt terminfo entry > > % ls -l /usr/share/lib/terminfo/r/rxvt > /usr/share/lib/terminfo/r/rxvt: No such file or directory Seem this is bug 6839489: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6839489 An ncurses rxvt terminfo entry exists in /usr/gnu/lib/terminfo/r/rxvt but not in the solaris default terminfo database. Workaround: cp /usr/gnu/lib/terminfo/r/rxvt /usr/share/lib/terminfo/r/rxvt -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is rxvt terminal type supported?
> use mrxvt application. So, the problem is not with terminal application > on OpenSolaris, it doesn't run X at all (yet), but with OpenSolaris' > man, vi and other curses/termcap/you_know_better applications. To me it > looks like problem with curses/termcap capabilities. It works fine with > TERM=xterm but doesn' with TERM=rxvt. OpenSolaris does not have an rxvt terminfo entry % ls -l /usr/share/lib/terminfo/r/rxvt /usr/share/lib/terminfo/r/rxvt: No such file or directory The rxvt application on OpenSolaris is using the xterm terminfo entry. Maybe you could compile (or copy) the terminfo entry from NetBSD on OpenSolaris ? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris 2010.03 improvements?
> | No I meant a 64bit version of OpenSolaris. Right > now it's only available in 64bit for SPARC if I'm not > mistaken. > > Solaris has been a mixed 32/64bit install for many years. > > The installer runs 32bit. This has changed in OpenSolaris. The OpenSolaris x86 installer / livecd runs the 64-bit kernel on 64 bit capable hardware, unless your system has less then 1 GB of physical memory. (Running the 64-bit kernel is important to install to disks > 1TB) -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SIL0680 driver?
> I could use some help in making my SIL-680 board work > under eon (or Opensolaris in general). Does the card have a "raid-mode" jumper? I think raid mode needs to be disabled. Or is there a "non-raid-mode" firmware available for the card? Otherwise I think that a "non-raid-mode" SIL-680 board should work with the standard pci-ide / cmdk driver in p-ata mode. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6867542 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] osol b133 X freezes
CC-ed to xwinow-discuss, thread started at
http://www.opensolaris.org/jive/thread.jspa?threadID=125150&tstart=0
> > Do you find the following error message in /var/log/Xorg.0.log ?
> >
> > intel_bufmgr_fake.c:392: Error waiting for fence: Device busy.
>
> No. I find in Xorg.0.log :
> [...]
> Error in I830WaitLpRing(), timeout for 2 seconds
> pgetbl_ctl: 0xcffc0001 getbl_err: 0x0100
> ipeir: 0x iphdr: 0x5404
> LP ring tail: 0xff48 head: 0xff18 len:
> 0x0001f001 start 0x
> eir: 0x esr: 0x0011 emr: 0xfffd
> instdone: 0xc081 instpm: 0x
> memmode: 0x0306 instps: 0x800f0044
> hwstam: 0xeffe ier: 0x8053 imr: 0x7fae iir: 0x0040
> [...]
> Fatal server error:
> lockup
> [...]
> _fence_emit_internal: drm_i915_irq_emit: -9
Hmm, this message appears in bug 6857531
"_fence_emit_internal: drm_i915_irq_emit: -9"
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6857531
As far as I understand that bug report, some
hardware configuration setting ("GTT") is lost
after a suspend / resume? Did you use
suspend / resume before Xorg locked up?
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] osol b133 X freezes
> if i do truss -p 630 (Xorg process) i get and endless repetition of: > > /1: setcontext(0xFD7FFFDFEB60) > /1: Received signal #14, SIGALRM, in ioctl() [caught] > /1: ioctl(14, 0x46445, 0xFD7FFFDFF3FC) Err#4 EINTR > /1: lwp_sigmask(SIG_SETMASK, 0x2000, 0x) = 0xFFBFFEFF > [0x] That looks similar to what was reported in this thread: http://www.opensolaris.org/jive/thread.jspa?threadID=124807&tstart=0 (The user in that thread mentioned that b131 was ok, and the problem started in b132) Do you find the following error message in /var/log/Xorg.0.log ? intel_bufmgr_fake.c:392: Error waiting for fence: Device busy. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] very long wait in the end of pkg install
> As a matter of fact I had also thunderbird+firefox so the memory usage > was a bit high. I just retried it now without any other "heavy app" > other than X+gnome, and it went much much faster (7-8mn) Since b132 there is a java vm process running on the gnome desktop. It displays an icon in the gnome panel showing a tooltip text that "all system resources are healty". You may want to stop that java process to some save 50+ MB of memory. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] very long wait in the end of pkg install
> > Has pkg been always that slow? > > > > I suspect that pkg has been reasonably fast for the > > first few packages that you installed, but has > > become slower and slower the more packages > > have been installed? > > Hello Mr. Keil: If you suspect a standard bin/pkg to run ^reasonably > fast ^, then all your systems must be Quad core i7´s with 8GB ram. > > If you are a regular follower of pkg-discuss and caiman-discuss, then > you should know the memory consumption peak values and associated > problems. > > > What you meant in this context was probably ^RELAtively fast ^, but that is a > difference. > The rela- then only refers to other IPS pkg- testruns themselves, > rather than to any truly ^reasonably fast ^ packaging system. The worst install time I've been able to reproduce so far with "pkg install wireshark" was 3 - 4 minutes. I tried a virtualbox guest with 768 MB of memory (single core); and I tried on a core2 duo laptop with grub "uppermem 1024000", The worst time I've seen to far is an order of magnitude better than the 2 hours reported in this thread. In my tests the pkg process consumes 340 MB (which is a *lot* for installing a single package) but I expect that such a process size is ok for a system with 1GB of ram. So I think some important piece of information is missing for reproducing the bug. For example the system might use part of system ram for video ram so that less than 1GB of ram was available; or lots of other applications where running consuming memory; or the process size of pkg is much bigger than 340 MB (because lots of packages have already been installed ?) ... -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] very long wait in the end of pkg install
> BTW when did pkg switch to python 2.6 ? It has been using python 2.6 for several builds now. I have an old b129 installation and that is using python 2.6 for /usr/bin/pkg. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] very long wait in the end of pkg install
> > I suspect that pkg has been reasonably fast for the > > first few packages that you installed, but has > > become slower and slower the more packages > > have been installed? > > > Not that much packages installed after fress install That is, on your fresh b133 install from livecd, the first package install "pkg install diagnostic/wireshark" is already slow in the post install phase (slow: more than 10 minutes) ? What process size is listed by prstat or top for the "pkg" process during the post install phase? (In top I observe 180M during the install phase, and 390M post install, on a fresh b133 install, when I install wireshark as the first package) -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] very long wait in the end of pkg install
> # tail pkg.log
> 1.7255 schedctl() = 0xFEC69000
> 0.0002sigaction(SIGINT, 0x08047650, 0x080476D0) = 0
> 421.4744 open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/messages.mo",
> O_RDONLY) Err#2 ENOENT
stack backtrace for the pkg process at the
time after the sigaction() system call:
core 'core.3048' of 3048: /usr/bin/python2.6 /usr/bin/pkg install
diagnostic/wireshark
fed85a88 update_refs (fedf3a50) + c
fed8644c collect (2, fedcc63c, 80476d8, fed86e72) + 238
fed86e9c PyGC_Collect (0, fedcc63c, 80476f8, fed78c98, 0, fedcc63c) + 34
fed766e7 Py_Finalize (0, fedcc63c, 8047738, fed7791b, 0, fedcc63c) + 47
fed78c98 Py_Exit (0, fedcc63c, 8047738, fed77912) + 18
fed7791b handle_system_exit (80a3a40, fedcc63c, 8047778, fed78152, 80a3a40,
80a3a40) + 13f
fed77959 PyErr_PrintEx (1, 8047af7, 101, fed77608) + 31
fed77619 PyErr_Print (80477c0, fefc47a4, 8047aff, 1, fed76c46, 0) + 1d
fed772b2 PyRun_SimpleFileExFlags (fef867e8, 8047af7, 1, 804789c) + 1c2
fed76c46 PyRun_AnyFileExFlags (fef867e8, 8047af7, 1, 804789c) + 6e
fed85694 Py_Main (4, 80479a8, feef6f25, 8050b88, 1, 0) + a94
08050bdf main (4, 80479a8, 80479bc, 804799c) + 63
08050aed _start (4, 8047ae4, 8047af7, 8047b04, 8047b0c, 0) + 7d
Python seems to be running a garbage collection
at system exit, and this touches lots of memory.
And I suspect that the pkg process on your machine
has a RSS > available free memory.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] very long wait in the end of pkg install
> I ran pkg install with truss, in the hope of
> discovering why it takes so long to complete,
> especially AFTER it has reported that every thing is installed.
You are running a fresh install of b133, correct?
Has pkg been always that slow?
I suspect that pkg has been reasonably fast for the
first few packages that you installed, but has
become slower and slower the more packages
have been installed?
> I ran into this (for me) mysterious result :
>
> # truss -o pkg.log -D pkg install diagnostic/wireshark
> # tail pkg.log
> 1.7255schedctl() = 0xFEC69000
> 0.0002sigaction(SIGINT, 0x08047650, 0x080476D0) = 0
> 421.4744 open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES/messages.mo",
> O_RDONLY) Err#2 ENOENT
Yep, a truss with options "-m all -t all" shows that there
are lots of FLTPAGE pagefaults before the failed
LC_MESSAGES/messages open.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> I lost my snapshots on swap now. do I need them ? No, snapshots on a swap zvol are just a waste of disk space. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> Do you think that it will continue and complete the > update? My vm build is still in creating plan phase > but I can see/hear the hardrive reading and writing > and every once and a while I see the network icon > flicker... > > My notebook which was started earlier is doing the > same...Neither is downloading updates yet. I hope > that this isn't all wasted time.How long did your > 1 GB vm take to finish create plan and then download > new files? The whole pkg image-upgrade completed in 1 - 1.5 hours. But with a pkg process size of 1.3 GB instead of 700 MB it wouldn't surprise me to see upgrade times of a day or something like that... -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> That is not good..Won't the machine just page to > compensate, though? That's what I've been observing, with a 1GB virtualbox guest and pkg image-update. It pages and is slow, but doesn't freeze. But in my experiment the pkg process size is ~ 650 - 700 mbyte. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> A few data points, for those who are about to do > this. On a single-CPU 2GB system I get: > > PID USERNAME NLWP PRI NICE SIZE RES STATE TIMECPU COMMAND > 37 root1 600 1231M 1131M sleep6:10 1.36% pkg This system had lots of extra ips packages installed on top of the livecd contents, correct? I suspect that on a system with 1GB of memory it will get almost impossible to pkg image-update if the pkg process uses that much memory... -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> I just tried to pkg image-update a 64-bit b132 vbox guest. > 768 MB of memory, and 512 MB swap. It failed during > "Creating Plan" because the system was running out of > memory. With 1 GB of memory and 1 GB of swap the pkg image-update from b132 to b133 worked. The pkg process had a maximum process size of ~ 650 MB, and ~ 350 MB of swap space was used. My b132 test install had almost no extra packages installed - that is, it contained more or less the contents of the b132 livecd. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> Tried once again, it seems to freeze each time when > there is about 4K ram left. Is that a 32- or a 64-bit system? > I do have 4G swap, almost not used at all. Hmm, that is unexpected. How did you watch swap space usage? swap -l ? I just tried to pkg image-update a 64-bit b132 vbox guest. 768 MB of memory, and 512 MB swap. It failed during "Creating Plan" because the system was running out of memory. But the pkg pkg process size did grow to more than 600 MB, and swap space was used. But it didn't freeze the system... -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> it freezes during the "Creating plan" when running pkg image-update, > either from b131 be or b132 (I kept both). > it freezes during the "evaluating SUNWgcc package" > when trying to ugrade from gui > > I know the memory pressure msg is not directly related, but I can see > the memory being eaten up when running vmstat, untill it freezes. Did you check with "top" if there is a process that keeps growing and consumes all the memory? I suspect that it is the "pkg" utility that consumes all the memory. This could be similar to defect 9388: "pkg image-update needs to cap memory usage " http://defect.opensolaris.org/bz/show_bug.cgi?id=9388 > That is up to a certain point because as image-update runs with a quite > high priority, console output tends to be very slow and erratic (which > in my opinion is very wrong, you should NOT get unresponsive shell when > running an update). A "pkg" process that is using huge amounts of memory could explain this... The system probably has become slow due to pageing; until it freezes. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> Same here with me - thought that it may be some > problem in the versions since 128a - but it happens > more often. with 133 not as often as with 132 but > yesterday 2 times. > > Thinkpad T61p with 4GB RAM - Virtualbox with win64 running . Do you always get the freezes when virtualbox was running? Could this be a virtualbox problem, like ticket 5864 http://www.virtualbox.org/ticket/5864 > Freeze occurs in the same manner - tcp defensive mode > on ... by by OS Are you sure you get the "tcp defensive mode" message on b133? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> I've noticed that since b132 my laptop freezes under > load. Just dies without any message other than > "memory pressure, tcp defensive mode on". > Probably short of memory. I've _only_ 1GB which used > to be quite ok for a laptop. AFAIK, the warning message is wrong. Although all memory is in use, the system should be able to shrink some caches to free memory. But b131, b132 TCP got this wrong and enters defensive mode, and I think this could affect network connectivity. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6910378 > Now trying to upgrade to b133 and hoping for the > best, it just dies in the same way, whaterver trick I > try (gui, pkg cmd line, text mode...) Does it freeze during the b132 -> b133 upgrade? Or did the upgrade succeed, but the upgraded b133 freezes in the same way b132 did? The "WARNING: Memory pressure: TCP defensive mode on" message should be gone in b133... http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6910378 > So am I forced back to reinstall ? Do you have a b130 (or older) BE? Maybe you could activate that and upgrade directly from b130 to b133, avoiding bug 6910378 ? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Unable to ugrade from b132 to b133 : system freeze
> I thought it was a problem with the graphics driver, but you are right > as soon as I start gdm the box dies and my remote ssh session are dead.. What graphics hardware is that? Intel video? Could be 6914386, which is not yet fixed in b133 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6914386 Or http://defect.opensolaris.org/bz/show_bug.cgi?id=13598 > I will try again to see if I can get any error messages... Only got 1GB! Try to boot b133 in single user mode with debugger enabled (GRUB kernel$ boot option "-sk"), type the SHIFT key to switch from graphics boot logo to text console, login using your primary account, and try dd if=/dev/agpgart Does that panic the kernel? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Missing drivers in OpenSolaris.
> What other drivers are currently not distributed with OpenSolaris? E.g. Adaptec *adp* drivers are missing in OpenSolaris http://defect.opensolaris.org/bz/show_bug.cgi?id=112 http://defect.opensolaris.org/bz/show_bug.cgi?id=7976 I think there was the idea to make them available via the "extra" repository, but it seems that has not yet happened. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Problem with the forum
> Sry I didn't found the right place for this, but I > wanted to inform you about 3 problems with this > forum: Try the website-discuss list / forum http://www.opensolaris.org/jive/forum.jspa?forumID=29 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [laptop-discuss] Toshiba M10 - 111 to 131 upgrade issues - GDM fails, blank screen
Robert Milkowski wrote: > On 03/02/2010 12:25, Jürgen Keil wrote: > > Robert Milkowski wrote: > > > >> Toshiba R600, up-to snv_129 X is working fine. > >> snv_131 and the moment Xorg starts the notebook does hard-reset (quick > >> power-off) - no crash dump, no nothing, When I booted under kernel > >> debugger the box just hangs and I can't go into the debugger. > >> > >> I tried to boot into single user mode, console is fine, then manually > >> start Xorg binary and laptop does a hard-reset almost right-away. > >> > > What happens when you boot into single user mode > > under kernel debugger, and open the /dev/agpgart device, > > e.g. like this > > > > true< /dev/agpgart > > > > Does that panic the kernel? > > > > yes, it does in hat_devload() > > ? That looks a lot like 6914386 "X freeze (and reboot) a build 130 system" http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6914386 Which got a "commit to fix" for b134. I've just installed b132 on a Tecra A10, like this: - boot and install b132 using the vesa install option unfortunately there was a new problem with vesa, compiz and a white screen (defect 14387, http://defect.opensolaris.org/bz/show_bug.cgi?id=14387 ) but with metacity instead of compiz the gui installer worked ok - boot b132 from hdd into single user mode - disable the broken chipset flush code in the agptarget driver, using the following patch: echo "intel_chipset_flush_setup?w c3" | mdb -w /kernel/drv/agptarget echo "intel_chipset_flush_setup?w c3" | mdb -w /kernel/drv/amd64/agptarget halt (My Tecra A10 seems to work just fine with the chipset flush code disabled; YMMV) - reboot into b132 - remove the /etc/X11/xorg.conf file (it forces the use of the vesa driver, after the vesa install) and logout from Xorg - Xorg should no be using the intel video driver A similar patch should work when you upgrade to b132 using the dev pkg. After the upgrade, mount the new b132 BE and apply the above patch to the b132 kernel/drv/agptarget and kernel/drv/amd64/agptarget binary. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Memory usage increasing during idle
> have 64bit system running on computer with 8gb RAM. > immediately after start ::memstat (mdb -k) shows > 1164MB of "Kernel", but after 2 or 3 days of idle > this number increased to ~2500MB. is it Ok or > something wrong? Should be ok. Could be cron jobs running during the night that looks at lot of files (e.g. /usr/lib/fs/nfs/nfsfind), and that fills some system caches. In case you suspect that there is a kernel memory leak: enable kernel heap memory checking, force a kernel crash dump, and use mdb ::findleaks on the crash dump: http://docs.sun.com/app/docs/doc/816-5041/kmem-1?a=view -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [laptop-discuss] Toshiba M10 - 111 to 131 upgrade issues - GDM fails, blank screen
> >> The stack matches that in 6914386 which is possibly a duplicate of > >> 6911372 which is fixed in snv_131. This was introduced in b130, so it > >> fits your problem. > >> > >> My suggestion would be to jump back to b129 (or whatever was your last > >> stable one) and upgrade to b131 which is currently available. Let us > >> know if you still get the above panic. > > > > On my Tecra A10 the fix for 6911372 did *not* fix the panic. > > I've already pointed out to Brian, my stack trace was on 131 And the panic should also be seen in b132 and b133 ... -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Boot Speed
> online 20:00:10 svc:/application/desktop-cache/icon-cache:default > online 20:01:08 svc:/system/hal:default ... > Note that between icon-cache:default and hal:default > there is an almost 60-second gap, I didn't find other > gaps like this in the whole svcs -a output. Is there a ps/2 floppy drive present in this system? Is the ps/2 legacy floppy controller enabled in the system's bios? This could be defect 4714? HALD takes more than 60 seconds to start http://defect.opensolaris.org/bz/show_bug.cgi?id=4714 Or Bug 6294851 Some system boards incorrectly detect floppy controller as needing FDCMODE_30, fail to detect change http://bugs.opensolaris.org/view_bug.do?bug_id=6294851 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [laptop-discuss] Toshiba M10 - 111 to 131 upgrade issues - GDM fails, blank screen
Robert Milkowski wrote: > Toshiba R600, up-to snv_129 X is working fine. > snv_131 and the moment Xorg starts the notebook does hard-reset (quick > power-off) - no crash dump, no nothing, When I booted under kernel > debugger the box just hangs and I can't go into the debugger. > > I tried to boot into single user mode, console is fine, then manually > start Xorg binary and laptop does a hard-reset almost right-away. What happens when you boot into single user mode under kernel debugger, and open the /dev/agpgart device, e.g. like this true < /dev/agpgart Does that panic the kernel? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [laptop-discuss] Toshiba M10 - 111 to 131 upgrade issues - GDM fails, blank screen
> The stack matches that in 6914386 which is possibly a duplicate of > 6911372 which is fixed in snv_131. This was introduced in b130, so it > fits your problem. > > My suggestion would be to jump back to b129 (or whatever was your last > stable one) and upgrade to b131 which is currently available. Let us > know if you still get the above panic. On my Tecra A10 the fix for 6911372 did *not* fix the panic. The agptarget driver is trying to allocate a page of device memory for "chipset flush", installs the physical address (for a free page) in the device, constructs a "reg" property entry for that physical device memory address, and then calls ddi_regs_map_setup() to map the physical device memory address. hat_devload() notices that a free page is going to be mapped, and panics: http://defect.opensolaris.org/bz/show_bug.cgi?id=14101 http://defect.opensolaris.org/bz/show_bug.cgi?id=13598#c12 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Boot Speed
> Don't know if this is related, Probably not, unless it hangs before displaying the SunOS copyright banner of the kernel. > but I too have slow boot time for my Acer > 7720G notebook and build 131. > > Though I don't see 4 minute boot up time, it is more > like 2+ minutes to GDM. There is a RFE that is complaining about slow OpenSolaris boot, but it contains no facts to back up that claim: http://defect.opensolaris.org/bz/show_bug.cgi?id=13946 > When I enable -v and text booting, I see the drivers rolling. What is > interesting is that the drivers seemingly loads more than once. > For example, Acer Crystal Webcam is getting printed twice at interval of > 40-45 seconds. Same with a few other drivers as well. When the kernel runs out of free memory, one of the cleanup actions is unloading of unused device drivers, to free some memory. The next time the device is accessed the driver will automatically load and you'll see another attach message. How much memory does your system have? With a text boot, how much time passes between selecting an entry in the grub boot menu until the SunOS copyright banner appears on the screen? With a text boot (non verbose), how much time passes between printing the SunOS copyright banner and reporting the machine's "Hostname: ..." ? When you look at the timestamps for the services in online state in "svcs -a" output, how much time passes between the first online service until the gdm service starts up? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Need to find files with in name. How?
> So I have lots of files with weird characters in the > name. Those , , etc characters are listed as > "?", for instance "Making?Food?Recipe.doc". The > version of CIFS I use, (b125) does not allow listing > of files with those characters in WinXP clients. I > must stay with b125 because of issues in later > builds. > > So I need to somehow, find all these files and rename > them in an automatic way. I have tried > ls -R | grep "?" > and then I find all file names with strange > characters. But, I dont see the path to the file. > Somewhere, in all subdirectories there are some > files. But in which sub directory? Where? So I > searched each file and renamed it manually. But that > sucks. Hey, I am on Unix, not on Windows, there > should be a way to automate it! > > Is there any automatic way to search and replace? I > can replace all "?" with "a", that is ok. I think > there is a program in IPS which identifies files > which has "?" in file names? And I can convert those > file names? That is, some (all?) of the filenames use 8-bit ISO8859-1 encoding, and you need UTF-8 for CIFS? An idea would be to send the filenames through an "iconv -f UTF-8 ..." and rename those files where iconv complains about illegal UTF-8 sequences in the input data - those should be the files that are listed with "?" in them. Something like this: echo "$file" | iconv -f UTF-8 -t UTF-8 > /dev/null 2> /dev/null if [ $? -ne 0 ]; then file_utf8="`echo "$file" | iconv -f ISO8859-1 -t UTF-8`" mv "$file" "$file_utf8" fi -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Boot Speed
> Interestingly with grub in verbose the system waits > at the findroot line. Seems to be stuck in the BIOS when trying to read from one or more of the 16 HDDs connected to this system. > Without the findroot line it brings up the "SunOS > Release 5.11 Version ..." copyright banner and ends > on the next line (mem). There it waits. IIRC, the Solaris kernel collects BIOS EDD information and the contents of the first sector for each BIOS accessible disk at startup; the hang here might have the same root cause as the grub findroot hang. > Hmmm. This is strange. > I wonder if it BIOS / drive boot related. This system > runs EFI. > Where to go from here? Maybe you can find out which BIOS drive causes the hangs, by - entering grub command line mode (type 'c' in the grub menu - check what BIOS hdd devices are available with the (incomplete) grub command root (hd (no RETURN) followed by a TAB character. Grub should try to autocomplete the "hd" device name and should print a list of valid "hdN" device names. With 16 HDD, I'd expect that grub finds possible disks as "hd0", "hd1", ... "hd15" ? - Now try "root (hdN)" commands, for all possible disk devices reported by the autocompletion in the previous step. replace hdN by one of the disk names returned. I suspect that there is at least one BIOS hdN device that hangs the root command. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Boot Speed
> So the main issue is: > > After selecting an entry in grub to boot from, and > before the "SunOS Release 5.11 Version ..." copyright > banner appears there is a flashing "_" for ~4-5 > minutes. > > Is there anyway to get text or any logging/tracing in > this time? Did you try the "verbose" grub command? > Or even what is meant to be happening... In the verbose grub output you should see how grub runs each boot command, searches for the root disk using the "findroot" command, loads the "unix" kernel binary and the big "boot_archive" file. See the attached screen image. Maybe it is hanging in the findroot command, where it is scanning all disk devices visible by BIOS for the disk containing the filesystem with the "pool_rpool" signature file. Would it boot faster when you edit the grub boot commands and delete the findroot command? Without the findroot it would use the same drive as root device that was used to load grub. -- This message posted from opensolaris.org screendump.png Description: Binary data ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Boot Speed
> >Which version of opensolaris are you using? > It is a clean install of b131 (the issue occurred in > all of the b12x series also iirc) > > >Are there lots of snapshots on the zpools? > No, only 4 or 5 on my rpool. Ok, so it isn't the problem with zpool import running for a long time when *lots* of snapshots have been created (6761786). > >To trace grub's progress loading the kernel and > >boot archive, edit the grub boot commands and > >insert a "verbose" command as the first > >command. > I thought I already had that, what do I change on the > following? > kernel$ /platform/i86pc/kernel/$ISADIR/unix -B > $ZFS-BOOTFS,console=text -v -m verbose With the "-m verbose" option smf(5) starts to output verbose debug output when starting services. But smf(5) starts much later. Try something like this: verbose findroot (pool_rpool,0,a) bootfs rpool/ROOT/opensolaris-1 kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=text -v module$ /platform/i86pc/$ISADIR/boot_archive -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Boot Speed
> I have been finding my system taking a long time to > boot. In the order of 5 to 8 minutes. Part of it is > the zpools I have. Which version of opensolaris are you using? Are there lots of snapshots on the zpools? > However booting in text mode it > takes a long time to get any text on the screen. The > system sits at the flashing "_" for 4m 10s (to the > closest 10s). Is that after you select an entry in grub to boot from, and before the "SunOS Release 5.11 Version ..." copyright banner appears? But the SunOS copyright banner does appear on the vga console, or is the console output routed to a serial port? How is the boot disk connected to the system? S-ATA? P-ATA? USB? > Is there any way I can do boot tracing? To trace progress after the kernel starts running, boot the solaris kernel with the "-v" option. Add "-v" at the end of the kernel$ line in the grub boot entry. To trace grub's progress loading the kernel and boot archive, edit the grub boot commands and insert a "verbose" command as the first command. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] help with opensolaris pgrep
> For instance, i have a script which i use to check if > rsync is running, if it isn't running, then it will > rsync, if it is, then it should skip rsync. I put > this in crontab for every 15 minutes. > > On FreeBSD this works fine, on OpenSolaris it doesn't > seem to be working. > > any idea why this should be? > #!/bin/sh > PATH=/bin:/usr/bin:/usr/sbin > SERVICE='rsync' > REMOTE='wonsl...@xxx..xxx:/home/xx/x/' > LOCAL='/tank/nas/dump/' > LOG='/export/home/wonslung/log/rsync.log' > if pgrep -u $USER $SERVICE > then > echo "$SERVICE is running, skipping" > > $SERVICE -ave ssh --delete $REMOTE $LOCAL >>$LOG > fi USER not defined in the cron environment? The crontab(1) manual page documents these environment variables are available: HOME, SHELL, TZ And when I check the environment variables in a cron job, I actually see PATH and LOGNAME to be defined, too: HOME=/files/jk LOGNAME=jk PATH=/usr/bin: SHELL=/usr/bin/sh TZ=Europe/Berlin -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] memory consumption in b131
> while in my laptop I have an onboard intel : > PCI:*(0:0:2:0) 8086:27a2:1028:01c2 Intel Corporation Mobile 945GM/GMS, > 943/940GML Express Integrated Graphics Controller rev 3, Mem @ > 0xeff0/524288, 0xd000/268435456, 0xefec/262144, I/O @ > 0xeff8/8, BIOS @ 0x/65536 ... > (==) intel(0): VideoRam: 262144 KB Hmm, so the laptop has 1G of ram, and the onboard intel video grabs 256M of it, so that only 768M remain for the operating system. Does this system have any bios setup options to reduce the amount of video memory allocated for the onboard intel video? > I guess there is nothing more to do, but it still > certainly feels like Xorg is very demanding > Should I try to increase swap allocation (512M feels > a bit short maybe) ? You can try that, and it should help with the fork failures. But having more memory available for the OS (install more memory or at least reduce the amount grabbed by intel video) would probably be better. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] memory consumption in b131
> However, I found that Xorg memory usage is still very high : > > 1446 root 448M 150M sleep 450 0:04:53 4.4% Xorg/3 > especially compared to the one on my home server, > with basically the same session apps running > (including compiz, awn and conky) : > > 720 root 88M 58M sleep 590 1:01:32 0.1% Xorg/3 > Any idea where I could look further and what might be > the cause (does it make any sense to blame the > graphic adapter, or rather lack of it ?). A big chunk of the memory size reported for Xorg is usually the mapped frame buffer memory. I suspect the first card has e.g 256 mbyte of video memory, while the other card in the home server is some old video card with e.g. 8 mbyte of video memory. The exact amount of video memory found on each of the systems should be reported somewhere in the /var/log/Xorg.0.log file. Note that some cards use main system memory as frame buffer memory (e.g. intel video, or nvidia cards with "turbo cache", ati cards with "hypermemory", ...). In that case it might make sense to enter the bios setup and reduce the amount of video memory assigned to the video card, so that more memory remains usable for the operating system. The other source of memory usage for Xorg is probably pixmaps / images that are displayed, e.g. when you have lots of firefox tabs open. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] memory consumption in b131
> E.g. on my b129 box a gnome-terminal process
> is using 68 (!) shared libraries
>
> % pldd `pgrep -x gnome-terminal` | wc -l
> 68
On opensolaris b131, this has increased to 76
shared libraries.
> % pmap -x `pgrep -x gnome-terminal` | grep cache | wc -l
> 55
b131: 71 "cache" files
> pmap -x `pgrep -x gnome-terminal` | nawk '/cache/ { i += $3; } END {print i}'
>13720
b131: checking the SIZE instead of RSS shows that
b131 is using about 50M more virtual memory
because the /usr/share/icons/nimbus/icon-theme.cache
file is mapped. The nimbus icon-theme.cache
file is mapped into a lot of gnome processes, each
of them seems to have grown by at least 50M.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] memory consumption in b131
> Yes In deed I run compiz, though the "normal > variant", mostly to be able to run avant-window. > It seems too be the bug you refer to. If you have compiz enabled, logout from gnome desktop and start a new session, is the gconfd-2 process size still that large? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] memory consumption in b131
> PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP ... > 2749 bruno 195M 136M sleep 590 0:00:04 0.0% gconfd-2/1 The memory usage of that gconfd-2 process is very high. On my opensolaris b131 system gconfd-2 consumes 13M memory, with a RSS of 7MB. For some reason the gconfd-2 process on your box uses an additional 180M of memory. Could be a bug. Does the size of the gconfd-2 process increase over time (a memory leak?) ? Did you enable or disable compiz (visual effects) in this gnome session? http://defect.opensolaris.org/bz/show_bug.cgi?id=14237 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] memory consumption in b131
> I'm very puzzled by the memory usage in recent builds of osol-dev.
Yep.
E.g. on my b129 box a gnome-terminal process
is using 68 (!) shared libraries
% pldd `pgrep -x gnome-terminal` | wc -l
68
And I see lots of virtual memory used for mapping
the various font / icon-theme / mime / ... caches.
Seems that 20% of the memory used by a gnome-
terminal is used by these mapped cache files.
% pmap -x `pgrep -x gnome-terminal` | grep cache | wc -l
55
% pmap -x `pgrep -x gnome-terminal` | nawk '/cache/ { i += $3; } END {print
i}'
13720
(55 mapped file, 13,72 mbytes resident in memory)
It also seems excessive that the (sparse?)
/usr/share/icons/*/icon-theme.cache
files consume more memory than all of the icon
files in a subdirectory combined.
A lot of that memory is shared between processes, though.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] MSI K8T-NEO2
> Thanks for the response. Here are the files as > requested. > When I run Install Solaris from the desktop there are > no drive or partition selections so I can't complete > the install. I have a 200GB Seagate drive attached to > the onboard SATA controller. And that's apparently a VIA chipset SATA controller: pci bus 0x cardnum 0x0f function 0x00: vendor 0x1106 device 0x3149 VIA Technologies, Inc. VIA VT6420 SATA RAID Controller I think that VIA SATA controllers are not supported by Solaris, similar to this bug: Bug ID 6411071 Synopsissata hdd is not recognised during install. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6411071 Is there a BIOS setting to disable the RAID mode of the VIA chipset SATA controller? Try to set the controller to P-ATA legacy mode, or maybe AHCI mode; that should be supported by OpenSolaris. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 128a was the latest fairly stable build
> 2) "WARNING: Mobile 4 Series chipset present, activating quirks" Message > Seen at 124/128/129/130 > > Suggested work around is not usefull as it affects the use of Vbox. > > 3) Not powering off properly. > Seen at 124/128/129 > > When powered off/down , activity lights stay active. > > 4) suspend.resume not working > > at 128, shut lid, open lid, box will not re-activate, > have to power cycle. I can confirm these three problems, and disabling VT-d is a workaround for all three problems. I can leave VT-x enabled. With VT-x enabled and VT-d disabled, Virtualbox is able to start 64 bit guests. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] b131 cryptic message
> After new install of b131, I get these messages : > ip: [ID 224711 kern.warning] WARNING: Memory pressure: TCP defensive mode on Looks similar to these bugs: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6910378 http://defect.opensolaris.org/bz/show_bug.cgi?id=14098 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] disk controllers numbering in b131
> ugrading from SXCE b130 to osol-b131 Upgrading from SX:CE to OpenSolaris isn't possible, did you reinstall OpenSolaris b131 from scratch? > the numbering of sata disks in ahci mode changed > > Is this a (small) bug ? Controller numbers shouldn't change by an upgrade. But for a new install they may change. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] pcieb5: Failed setting hotplug framework
> İnstall Solaris Express Community Edition b130, ... > [ID 441510 kern.warning] WARNING: pcie_hp_init: initialize hotplug controller > failed with -1 > [ID 552151 kern.warning] WARNING: pcieb5: Failed setting hotplug framework These messages should not appear any more on the console in b131 or newer: Bug ID 6904360 PCI hotplug errors during net boot (jumpstart) of snv_128/osol_128a on x86 systems. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6904360 -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris snv_130 panic.
> Experiencing very strange behaviour with upgraded > OpenSolaris machine ( from snv_124 to snv_130 ) > > Machine gets panic, with the following error: Just a wild guess... An opensolaris upgrade currently has a nasty bug that results in old kernel modules ending in the boot_archive: Bug ID: 6914346 Synopsis: upgrade from OpenSolaris 2009.06 (111b2) to 130 fails with stale archive_cache http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6914346 Could that bug be an explanation for the panic you're getting? Could you try to workaround from CR 6914346 and force building a fresh boot_archive ? Would that avoid the panic ? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why format says "drive type unknown" and ask for all information?
> How am I suppose to figure out those numbers? > > If fdisk can figure out the dimension, I suppose the > information format needed can be figured out > somehow? Did you create a Solaris fdisk partition in the fdisk utility? Is there a SunOS disk label written to the Solaris fdisk partition? You'll get the "drive type unknown" message when when there is no Solaris fdisk partition / no SunOS disk label. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] dev releases do not boot up from vmware
> I installed open solaris snv_111b on vmware esxi. ... > When i try to > boot opensoalris-1 from GNU GRUB Menu it dumps some > junk output and navigates back to GRUB Menu screen. I think that is a known problem: http://defect.opensolaris.org/bz/show_bug.cgi?id=6837 Or http://bugs.opensolaris.org/view_bug.do?bug_id=6820826 http://bugs.opensolaris.org/view_bug.do?bug_id=6820576 Workaround: For VMware (only), disable pcieb by adding -B disable-pcieb=true to the kernel command line (assumes you don't need any virtual devices that are behind the virtual PCIe bridges. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris, Solaris 10, SXCE, Indiana: which to use for a developer?
> On Sat, Jan 02, 2010, Jürgen Keil wrote: > [OpenSolaris Indiana: GNU?] > > > Well, it does have both the gnu utilities (/usr/gnu/bin) > > and the solaris counterparts, and in the default setup > > the /usr/gnu/bin directory is ahead of /usr/bin in $PATH. > > I simply removed /usr/gnu/bin from $PATH, but I still got vim instead > of vi[1] (in /usr/bin AFAIR), Yep, that's true. OpenSolaris does not have the real "vi". Not sure what the reason is; the source seems be available in the onnv mercurial repository, so I guess the real "vi" would be re-distributable with OpenSolaris. > and bash as root sh. Ok, so change root's shell in /etc/passwd. > If there is a way to > configure OpenSolaris to be(have) like Sun's Solaris > (for which I develop software and to which I'm used (besides > *BSD)), then please let me know. If you target Solaris 10, then you should probably run Solaris 10 on your development system, too. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why is nightly trying to build amd64 bits on an intel atom based system
> nightly is giving me a bunch of errors relating to > not being able to find usr/src/Makefile.master.64, > which are valid because it's not there. Hmm, seems your opensolaris sources are corrupted, because I have that file: % ls -l /files/snv_131_jk/usr/src/Makefile.master.64 -rw-r--r-- 1 jk usr 2452 Sep 30 22:54 /files/snv_131_jk/usr/src/Makefile.master.64 See also: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/Makefile.master.64 > 1) why is nightly trying to build 64 bit on atom So that the resulting packages contain both 32- and 64-bits. Solaris is always installed with full 32- and 64-bit support, even on systems that have 32-bit support only. > 2) why doesnt hg clone or update bringover > Makefile.master.64 - it's there Works for me. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris, Solaris 10, SXCE, Indiana: which to use for a developer?
> last week, I decided to upgrade and got a OpenSolaris version > (osol-0906-x86.iso). Unfortunately, that was not what I expected: > it seems to be a SunOS 5.x kernel with GNU userland > (let's just say that I don't want GNU: GNU's not Unix). Well, it does have both the gnu utilities (/usr/gnu/bin) and the solaris counterparts, and in the default setup the /usr/gnu/bin directory is ahead of /usr/bin in $PATH. That way the default setup looks like "GNU userland". You can change that by moving /usr/gnu/bin to the end of $PATH. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] image-update failed; "ZFS returned an error"
> Ah, yup, it is. :( > > Doesn't seem to work with lzjb either. lzjb compression does work on a zfs root filesystem. Note that the /rpool/boot/grub/* files are also read during boot and must not be compressed with gzip (lzjb is ok). There are no checks in the zfs code that prevent the use of gzip compression for the /rpool/boot/grub/* files. Btw. if you want to save as much disk space as possible on the zfs root filesystem: create and fill the zfs root fs with gzip-9 compression; when the filesystem is filled, change the compression to lzjb; mount it; make fresh copies of some files (these are read by grub at boot time and must not be compressed with gzip): platform/i86pc/kernel/unix platform/i86pc/kernel/amd64/unix platform/i86pc/boot_archive platform/i86pc/amd64/boot_archive boot/solaris.xpm E.g. for each of the above files: 1. mount -F zfs rpool/ROOT/opensolaris-N /mnt 2. cd /mnt/platform/i86pc/kernel/unix cp -p unix xx && mv xx unix ... repeat 2. for each of the above files ... That way the opensolaris livecd needs about 1.2GB space in the zpool. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] image-update failed; "ZFS returned an error"
> # beadm activate osol-130_trytryagain > set_bootfs: failed to set bootfs property for pool rpool: operation not > supported on this type of pool > be_activate: failed to set bootfs pool property for > rpool/ROOT/osol-130_trytryagain > Unable to activate osol-130_trytryagain > ZFS returned an error. Is that zfs root filesystem gzip compressed? Booting from gzip compressed zfs filesystems is not supported and trying to set the pool's bootfs property to such a filesystem would result in a "cannot set property for 'rpool': operation not supported on this type of pool" error message. -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Kernel panic of an assumed fixed bug
> I just received a kernel panic of a bug that is > assumably fixed: > > > Dec 15 19:09:30 iunis ^Mpanic[cpu1]/thread=ff01bdbc3180: > Dec 15 19:09:30 iunis genunix: [ID 335743 kern.notice] BAD TRAP: type=e (#pf > Page fault) rp=ff0008339c80 addr=8 occurred in module "ip" due to a NULL > pointer dereference > Dec 15 19:09:30 iunis unix: [ID 10 kern.notice] > Dec 15 19:09:30 iunis unix: [ID 839527 kern.notice] httpd: > Dec 15 19:09:30 iunis unix: [ID 753105 kern.notice] #pf Page fault The stack backtrace that should be following in the log might contain more interesting information... "NULL pointer dereference" panic does not reveal much... > Bugreport: > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6233919 Why do you think that your system's panic is the same as bug 6233919? There's not much information visible in bugs.opensolaris.org for that bug. And the bug seems to quite old. > And now? Republish the bug? Filing a new bug is a good idea (assuming this isn't a duplicate). -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_111b x86 crashing
> There is no "panic" or "syncing filesystems" in > /var/adm/messages. Is it possible to boot the server with kernel option "-k", disable the gui, and reproduce the mkfile crash ? Does it reboot, or does it enter the kernel debugger ? -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
