Re: [osol-discuss] Does solaris 10 08/07 Support MSI-x
Hi Pradeep, I came across this link. http://developers.sun.com/solaris/articles/interrupt_handlers.html Regards, Arun This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] cdrw command burning CD
This morning I successfully burned a DVD with GUI in SXDE, which is looking very similar as in OpenSolaris. So this means there is something wrong in OpenSolaris. The next step will be trying to use cdrecord in OpenSolaris. I first will probably need to reinstall OpenSolaris since the upgrade did not really succeed very well. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
Oscar del Rio [EMAIL PROTECTED] wrote: man in snv_91 dumps core when there are certain directories in the PATH. I have a rather long PATH but was able to reproduce it with a trimmed one. bash-3.2$ PATH=/usr/bin:/bin man man (man page shown OK) bash-3.2$ PATH=/usr/bin:/bin:/usr/bin/X11 man man Segmentation Fault (core dumped) If it domes coren then you should run at least file core to know _which_ program did dump core 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] How a (wrong) accent can lock y ou out of your server
Hi Nico, I wanted to submit the issue, but not able to reproduce it. I'm trying on SXCE build 92, but looks good there: -- ... Proseguire nella connessione (sì/no)? - I have tried for both SPARC,x86 and also UTF-8 an ISO .. Could you post your configuration where you have observed the issue ? Thanks Regards, Petr H. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] dram scrubbing cause hard hang on amd family 15 model 33 step 2
Hello I'm experiencing hard hang when dram scrubbing is enabled (after 2h55 of idle uptime). Amd erratum #99 should not affect this opteron processor since it's a revision E When I disable the scrubbing with oa_scrub_rate_dram=0 in /etc/system there is no problem at all. After a solaris update, I ran again into this issue, since the way to disable scrubbing has changed : it is now : set mc-amd:mc_scrub_rate_dram=0 When I disable the scrubbing the hang doesn't occur... I don't understand why the scrubbing hangs the server with this opteron revision. Does anyone has a clue ? This thread http://www.opensolaris.org/jive/thread.jspa?messageID=50240 seem to show the problem is corrected but it is not ... Thanks in advance Guy This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [ufs-discuss] PANIC! mounting cdrom slice on b78
Scott Rotondo [EMAIL PROTECTED] wrote: Did you run a test with the original filesystem, or what do you like to tell us here? I didn't test anything. I was just pointing out, based on simple examination of the source code, that line 944 is sure to panic if fsp contains random bits, but if it's set to NULL then line 943 will prevent 944 from executing at all. If you didn't test anything, why do you just repeat well known facts? 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] Nvidia 780a drivers
Thanks lars I had already set this up manually so Nwam was not enabled anyway, but here is a copy of what I did which was just run through your steps any way. I do not think the current nge driver is capable of dealing with this network card that somes as part of the 780a chipset. I also lot's of stuff on google where the linux and freebsd community are having the same issues. I have also logged and RFE which has now been accepted as no CR 6716752 . Anyway here is the commands executed. __ # svcs -a |grep physical disabled 19:14:57 svc:/network/physical:nwam online 19:15:03 svc:/network/physical:default # svcadm disable svc:/network/physical:nwam # svcadm enable svc:/network/physical:default # svcs -a |grep physical disabled 19:14:57 svc:/network/physical:nwam online 19:15:03 svc:/network/physical:default # ifconfig /dev/nge0 down ifconfig: setifflags: SIOCGLIFFLAGS: /dev/nge0: no such interface # ifconfig -a lo0: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 index 1 inet 127.0.0.1 netmask ff00 nge0: flags=201000843UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS mtu 1500 index 2 inet 10.1.1.101 netmask ff00 broadcast 10.255.255.255 ether 7a:a6:73:c6:1f:0 lo0: flags=2002000849UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL mtu 8252 index 1 inet6 ::1/128 # ifconfig nge0 down # ifconfig nge0 unplumb # ifconfig /dev/nge0 plumb ifconfig: cannot open link /dev/nge0: DLPI link does not exist # ifconfig nge0 plumb # ifconfig -a lo0: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 index 1 inet 127.0.0.1 netmask ff00 nge0: flags=201000842BROADCAST,RUNNING,MULTICAST,IPv4,CoS mtu 1500 index 3 inet 0.0.0.0 netmask 0 ether 7a:a6:73:c6:1f:0 lo0: flags=2002000849UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL mtu 8252 index 1 inet6 ::1/128 # ifconfig nge0 10.1.1.101 netmask 255.0.0.0 broadcast 10.255.255.255 up # # # ping 10.1.1.101 10.1.1.101 is alive # ping 10.1.1.1 no answer from 10.1.1.1 # # netstat -r Routing Table: IPv4 Destination Gateway Flags Ref Use Interface - - -- - default 10.1.1.1 UG1 0 arpanet dbsol-1 U 1 20 nge0 localhostlocalhostUH1377 lo0 Routing Table: IPv6 Destination/MaskGateway Flags Ref UseIf --- --- - --- --- - ::1 ::1 UH 1 21 lo0 This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nvidia 780a drivers
Also just for your further edification I also grabbed output from the files which I had already created. # tail -f /var/adm/messages Jun 20 19:20:09 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:20:11 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:20:51 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:20:53 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:21:33 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:21:35 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:22:15 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:22:19 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:23:37 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:23:38 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex After making changes Jun 20 19:27:51 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:27:55 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:28:39 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:28:41 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:29:21 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:29:23 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex ___ # cat /etc/netmasks 10.0.0.0255.0.0.0 --- # cat /etc/defaultrouter 10.1.1.1 --- # cat /etc/nsswitch.conf passwd: files group: files hosts: files ipnodes:files networks: files protocols: files rpc:files ethers: files netmasks: files bootparams: files publickey: files # At present there isn't a 'files' backend for netgroup; the system will # figure it out pretty quickly, and won't use netgroups at all. netgroup: files automount: files aliases:files services: files printers: user files auth_attr: files prof_attr: files project:files tnrhtp: files tnrhdb: files --- # cat /etc/resolv.conf nameserver 61.9.133.193 nameserver 61.9.134.49 domain home.net.au --- # cat /etc/hostname.nge0 10.1.1.101 --- # cat /etc/hosts 127.0.0.1 localhost 10.1.1.101 dbsol-1 loghost This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Western Digital SATA drives and Pioneer Blu-ray SATA do not register in b90
I have sent you a copy of the outputs you asked for, there are no console outputs. I have attached cfgadm and prtconf outputs and sent you email directly for /var/adm/messages file as to large to paste. *** Does anyone know how to attach files, as when I try in this forum I get an error message saying I do not have permissions to edit cfgadm -la |grep sata sata0/0unknown connectedunconfigured unknown sata0/1::dsk/c2t1d0disk connectedconfigured ok sata0/2unknown connectedunconfigured unknown sata0/3unknown connectedunconfigured unknown sata0/4unknown connectedunconfigured unknown sata0/5::dsk/c2t5d0disk connectedconfigured ok __ *** note only 1 and 5 are recognised by opensolaris I have placed actual details below 0 is a Seagate ST332061 3AS 1 is a Seagate ST325062 4AS 2 is PIONEER BD-ROM BDC-202 CdRom Device Blu-Ray 3 is Western Digital WDC WD25 00KS-00MJB0 4 is Western Digital WDC WD25 00KS-00MJB0 5 is Seagate ST325062 4AS __ prtconf -vp System Configuration: Sun Microsystems i86pc Memory size: 4095 Megabytes System Peripherals (PROM Nodes): Node 0x01 bios-boot-device: '81' stdout: name: 'i86pc' Node 0x02 existing: 00d7c000..02a0f801. name: 'ramdisk' Node 0x03 bus-type: 'isa' device_type: 'isa' name: 'isa' Node 0x04 compatible: 'pciex_root_complex' device_type: 'pciex' reg: .. #size-cells: 0002 #address-cells: 0003 name: 'pci' Node 0x05 reg: .... compatible: 'pci10de,754.1043.82e7.a2' + 'pci10de,754.1043.82e7' + 'pci1043,82e7' + 'pci10de,754.a2' + 'pci10de,754' + 'pciclass,05' + 'pciclass,0500' model: 'Ram' power-consumption: 0001.0001 66mhz-capable: fast-back-to-back: devsel-speed: max-latency: min-grant: subsystem-vendor-id: 1043 subsystem-id: 82e7 unit-address: '0' class-code: 0005 revision-id: 00a2 vendor-id: 10de device-id: 0754 name: 'pci1043,82e7' Node 0x06 reg: 0800.... compatible: 'pci10de,75d.1043.82e7.a2' + 'pci10de,75d.1043.82e7' + 'pci1043,82e7' + 'pci10de,75d.a2' + 'pci10de,75d' + 'pciclass,060100' + 'pciclass,0601' model: 'ISA bridge' power-consumption: 0001.0001 66mhz-capable: fast-back-to-back: devsel-speed: max-latency: min-grant: subsystem-vendor-id: 1043 subsystem-id: 82e7 unit-address: '1' class-code: 00060100 revision-id: 00a2 vendor-id: 10de device-id: 075d name: 'pci1043,82e7' Node 0x07 assigned-addresses: 81000910..fc00..0040.81000920..1c00..0040.81000924..1c40..0040 reg: 0900.....01000910....0040.01000920....0040.01000924....0040 compatible: 'pci10de,752.1043.82e7.a1' + 'pci10de,752.1043.82e7' + 'pci1043,82e7' + 'pci10de,752.a1' + 'pci10de,752' + 'pciclass,0c0500' + 'pciclass,0c05' model: 'SMBus (System Management Bus)' power-consumption: 0001.0001 66mhz-capable: fast-back-to-back: devsel-speed: interrupts: 0001 max-latency: min-grant: subsystem-vendor-id: 1043 subsystem-id: 82e7 unit-address: '1,1' class-code: 000c0500 revision-id: 00a1 vendor-id: 10de device-id: 0752 name: 'pci1043,82e7' Node 0x08 reg: 0a00.... compatible: 'pci10de,751.1043.82e7.a1' + 'pci10de,751.1043.82e7' + 'pci1043,82e7' + 'pci10de,751.a1' + 'pci10de,751' + 'pciclass,05' + 'pciclass,0500' model: 'Ram' power-consumption: 0001.0001 66mhz-capable: fast-back-to-back: devsel-speed:
Re: [osol-discuss] Nvidia 780a drivers
Hi, just for curiosity, there should (hopefully) be some managed network element (switch) between your box and the remaining part of the network. Policy defined on given port, to which your box has been connected, might easily cause such link flapping. If so, check the switch configuration and logs for more info. It does not have to be necessarily the driver issue.. /j. On Fri, Jun 20, 2008 at 03:06:26AM -0700, Darren wrote: Also just for your further edification I also grabbed output from the files which I had already created. # tail -f /var/adm/messages Jun 20 19:20:09 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:20:11 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:20:51 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:20:53 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:21:33 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:21:35 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:22:15 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:22:19 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:23:37 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:23:38 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex After making changes Jun 20 19:27:51 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:27:55 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:28:39 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:28:41 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex Jun 20 19:29:21 dbsol-1 mac: [ID 486395 kern.info] NOTICE: nge0 link down Jun 20 19:29:23 dbsol-1 mac: [ID 435574 kern.info] NOTICE: nge0 link up, 1000 Mbps, full duplex ___ # cat /etc/netmasks 10.0.0.0 255.0.0.0 --- # cat /etc/defaultrouter 10.1.1.1 --- # cat /etc/nsswitch.conf passwd: files group: files hosts: files ipnodes:files networks: files protocols: files rpc:files ethers: files netmasks: files bootparams: files publickey: files # At present there isn't a 'files' backend for netgroup; the system will # figure it out pretty quickly, and won't use netgroups at all. netgroup: files automount: files aliases:files services: files printers: user files auth_attr: files prof_attr: files project:files tnrhtp: files tnrhdb: files --- # cat /etc/resolv.conf nameserver 61.9.133.193 nameserver 61.9.134.49 domain home.net.au --- # cat /etc/hostname.nge0 10.1.1.101 --- # cat /etc/hosts 127.0.0.1 localhost 10.1.1.101 dbsol-1 loghost This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org /Jan Friedel jf (at) Sun.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
Joerg Schilling wrote: Oscar del Rio [EMAIL PROTECTED] wrote: bash-3.2$ PATH=/usr/bin:/bin:/usr/bin/X11 man man Segmentation Fault (core dumped) If it domes coren then you should run at least file core to know _which_ program did dump core core: ELF 32-bit LSB core file 80386 Version 1, from 'man' ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
I wrote: bash-3.2$ PATH=/usr/bin:/bin:/usr/bin/X11 man man Segmentation Fault (core dumped) core: ELF 32-bit LSB core file 80386 Version 1, from 'man' The problem seems to be with the new feature of man to deduce the MANPATH from the PATH, so for example /usr/openwin/bin in PATH gives /usr/openwin/man in MANPATH (last dir removed and man added) But then /usr/bin/X11 becomes /usr/bin/man which is the man program itself and not a directory. I guess man is then trying to open itself as a directory and failing. /usr/bin/X11 is a symlink to /usr/X11/bin in Solaris 10+; I've had it in my PATH for a long time for compatibility with older OS's - don't remember which. xstat(2, /usr/bin/X11, 0x08047B68)= 0 xstat(2, /usr/bin/man, 0x08047B68)= 0 access(/usr/bin/man, R_OK|X_OK) = 0 open(/usr/bin/man/man.cf, O_RDONLY) Err#20 ENOTDIR openat(AT_FDCWD, /usr/bin/man, O_RDONLY|O_NDELAY|O_LARGEFILE) = 3 fcntl(3, F_SETFD, 0x0001) = 0 fstat64(3, 0x08047AA0) = 0 close(3)= 0 xstat(2, /usr/bin/man, 0x08047B58)= 0 Incurred fault #6, FLTBOUNDS %pc = 0x08056196 siginfo: SIGSEGV SEGV_MAPERR addr=0x Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] StarOffice and JDS Missing
Can anyone tell me what happened to JDS and StarOffice in the new release of OpenSolaris 2008.05? I ended up going back to Solaris 10 due to the missing StarOffice and JDS. This message was sent by Blackberry wireless email and is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] StarOffice and JDS Missing
Stuart {Balckberry handheld} wrote:
Can anyone tell me what happened to JDS and StarOffice in the new release of
OpenSolaris 2008.05? I ended up going back to Solaris 10 due to the missing
StarOffice and JDS.
JDS was just GNOME with a Sun theme, and it was replaced by a
much newer GNOME with a different Sun theme, so it's mostly
still there - what is missing that you were looking for?
As for StarOffice, OpenSolaris provides OpenOffice.org in the
pkg repo, you just have to download it from the pkg manager.
--
-Alan Coopersmith- [EMAIL PROTECTED]
Sun Microsystems, Inc. - X Window System Engineering
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] StarOffice and JDS Missing
Stuart {Balckberry handheld} writes:
Can anyone tell me what happened to JDS and StarOffice in the new release of
OpenSolaris 2008.05? I ended up going back to Solaris 10 due to the missing
StarOffice and JDS.
Would this help?
http://dlc.sun.com/osol/docs/content/IPS/instdevsoft.html#openoffice
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
Oscar del Rio wrote: The problem seems to be with the new feature of man to deduce the MANPATH from the PATH, so for example /usr/openwin/bin in PATH gives /usr/openwin/man in MANPATH (last dir removed and man added) But then /usr/bin/X11 becomes /usr/bin/man which is the man program itself and not a directory. I guess man is then trying to open itself as a directory and failing. Thanks for this additional info, I've added it to the bug report you filed (6717067 - though you won't see the bug update on bugs.opensolaris.org until the next once-a-day resync). -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Veritas volumes on Global zone, best way to present to the Local Zone
Veritas Volume manager only runs within the Global Zone, it is not supported within the local zones, as they share the global zone kernel. I just want to know if there was a preference when presenting volumes to the local zones, ufs versus lofs This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Minor outage at 9 am PDT
We need to make a small firewall change in 15 minutes so you might experience a small 1-2 minute delay in accessing os.org. Derek -- Derek Cicero Program Manager Solaris Kernel Group, Software Division ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
Insofar as /usr/bin/X11 is a symlink to /usr/X11/bin
(compatibility thing?), I suppose that using realpath(3)
on the pathnames (at least if {name}/../man wasn't a
directory or symlink to a directory) might take care of
that.
The premise IMO is great: useful behavior from man
without having to set MANPATH explicitly. The devil
seems to be in the details of such oddities...
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
Mike Gerdts wrote: I've sent mail to request-sponsor to get someone to help me with the putback of the fix. I expect that I will have a fix ready for code review by Monday. Thanks for reporting the bug and sorry for creating it! Thank you for the quick analysis and fix. It makes sense. In the meantime the workaround would be to remove /usr/bin/X11 from the PATH or define a MANPATH. I remember why I have /usr/bin/X11 in my PATH: To be able to run xterm on an old IRIX system that has /usr/bin/X11 but not /usr/X11/bin IRIX 5.3 IP20 mips %ls -d /usr/bin/X11 /usr/X11/bin /usr/bin/X11 /usr/X11/bin: No such file or directory ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
Resending after subscribing to related lists... On Fri, Jun 20, 2008 at 11:56 AM, Mike Gerdts [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 9:59 AM, Alan Coopersmith [EMAIL PROTECTED] wrote: Oscar del Rio wrote: The problem seems to be with the new feature of man to deduce the MANPATH from the PATH, so for example /usr/openwin/bin in PATH gives /usr/openwin/man in MANPATH (last dir removed and man added) But then /usr/bin/X11 becomes /usr/bin/man which is the man program itself and not a directory. I guess man is then trying to open itself as a directory and failing. What is really happening is that /usr/bin/X11 as a PATH element doesn't fit the standard layout of: $prefix/bin $prefix/sbin $prefix/man man is chopping the last directory component of the PATH element off, then appending man (also tries share/man). That is /usr/bin/X11 becomes /usr/bin/man. That logic works great for (e.g.) /usr/local/bin which becomes /usr/local/man. man does verify the existence of /usr/bin/man - but fails to verify that it is a directory. See path_to_manpath() in man.c for details. The code that then tries to determine the man section list from the directories /usr/bin/man/* fails when it tries to opendir(/usr/bin/man) and returns without building the section list. The crash is happening as duplicate man directories and sections are removed because it assumes the section list is non-null. An empty section list would be OK, but a NULL section list blows up. There are two obvious ways to address this: 1) Use realpath() on each path directory prior to turning it into a man directory. This will break the functionality of allowing $prefix/bin - $prefix/$arch/bin with a shared $prefix/man (no $prefix/arch/man). 2) Use the a special pathmap (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/man/src/man.c#204) entry to map /usr/bin/X11 to /usr/X11/share/man. I'm leaning toward fixing it with #2. As I was looking into this I came across the following that I will address at the same time. - path_to_manpath() should not allow a directory to be added to manpath if no sections are found. - When checking for the existence of man and share/man directories, be sure they are directories I've sent mail to request-sponsor to get someone to help me with the putback of the fix. I expect that I will have a fix ready for code review by Monday. Thanks for reporting the bug and sorry for creating it! Mike -- Mike Gerdts http://mgerdts.blogspot.com/ -- Mike Gerdts http://mgerdts.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nvidia 780a drivers
I had this problem. it was my el cheapo switch. I found two solutions - 1. replace switch. 2. tell driver to not auto-negotiate. fix it to 100mbps full duplex This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
Mike Gerdts wrote: The code that then tries to determine the man section list from the directories /usr/bin/man/* fails when it tries to opendir(/usr/bin/man) and returns without building the section list. The crash is happening as duplicate man directories and sections are removed because it assumes the section list is non-null. An empty section list would be OK, but a NULL section list blows up. There are two obvious ways to address this: 1) Use realpath() on each path directory prior to turning it into a man directory. This will break the functionality of allowing $prefix/bin - $prefix/$arch/bin with a shared $prefix/man (no $prefix/arch/man). 2) Use the a special pathmap (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/man/src/man.c#204) entry to map /usr/bin/X11 to /usr/X11/share/man. I'm leaning toward fixing it with #2. As I was looking into this I came across the following that I will address at the same time. - path_to_manpath() should not allow a directory to be added to manpath if no sections are found. - When checking for the existence of man and share/man directories, be sure they are directories I agree /usr/bin/X11 is a special case and probably needs to be handled as such. (And yes, it was added for compatibility with .cshrc/.profiles for users of other Unixes.) Does the second item mean you'll be adding checks to the path_to_manpath code to protect against segfaults in other special cases, by basically doing something like changing the check from: if (stat(mand, sb) == 0) to: if ((stat(mand, sb) == 0) (S_ISDIR(sb.mode)) ? (I realize that's not safe against race conditions, but since man isn't setuid, that seems okay.) -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
Oscar del Rio [EMAIL PROTECTED] wrote: Mike Gerdts wrote: I've sent mail to request-sponsor to get someone to help me with the putback of the fix. I expect that I will have a fix ready for code review by Monday. Thanks for reporting the bug and sorry for creating it! Thank you for the quick analysis and fix. It makes sense. In the meantime the workaround would be to remove /usr/bin/X11 from the PATH or define a MANPATH. I remember why I have /usr/bin/X11 in my PATH: To be able to run xterm on an old IRIX system that has /usr/bin/X11 but not /usr/X11/bin Whether code is broken or not does not depend on whether the input is legal. 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] [osol-bugs] man: segmentation fault (snv_91)
On Fri, Jun 20, 2008 at 12:57 PM, Alan Coopersmith [EMAIL PROTECTED] wrote: Does the second item mean you'll be adding checks to the path_to_manpath code to protect against segfaults in other special cases, by basically doing something like changing the check from: if (stat(mand, sb) == 0) to: if ((stat(mand, sb) == 0) (S_ISDIR(sb.mode)) ? (I realize that's not safe against race conditions, but since man isn't setuid, that seems okay.) That was the plan. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-bugs] man: segmentation fault (snv_91)
On Fri, 20 Jun 2008 20:11:00 +0200 [EMAIL PROTECTED] (Joerg Schilling) wrote: Oscar del Rio [EMAIL PROTECTED] wrote: Mike Gerdts wrote: I've sent mail to request-sponsor to get someone to help me with the putback of the fix. I expect that I will have a fix ready for code review by Monday. Thanks for reporting the bug and sorry for creating it! Thank you for the quick analysis and fix. It makes sense. In the meantime the workaround would be to remove /usr/bin/X11 from the PATH or define a MANPATH. I remember why I have /usr/bin/X11 in my PATH: To be able to run xterm on an old IRIX system that has /usr/bin/X11 but not /usr/X11/bin Whether code is broken or not does not depend on whether the input is legal. And the quality of the code can be inferred from how it behaves when the input isn't legal. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nvidia 780a drivers
One more thing to test ... Some motherboards that I have had the pleasure to know,did not manage to Warm boot from Windows to Unix , be it FreeBSD or Solaris , with a working NIC at the end of the process. Probably Windows does not reset the NIC in the shutdown process. I always had to COLD boot Unix by turning off the power ( i.e. unplug it ) . So I if you have not tried it, I recommend you to unplug/replug the computers power cable and then boot it directly to Solaris, and pray that it works //Lars This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nvidia 780a drivers
Lars noway thanks but that sounds like rubbish, and in fact I have hard reset and powered up directly prior. Come on, I do appreciate your enthusiam though. I am about to log a bug as suggested by several other sun engineers I have been in contact with. The nforce 780a has some differences that will need to be added to the O/S. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nvidia 780a drivers
Hi Infact it's not rubbish. Please search the archives. This problem is also evident on Linux and *BSD too. I have an Asus M2NPV board here with nvidia chipset. I had several of same problems that you had. A synopsis is as follows: 1. The NIC flaps (another user me had same issue - bad switch. Please search the archives). 2. The NIC has MAC address in reverse. I have put the right address in hostname.nge0. It won't connect without this fix. 3. The PCI ID of the sata chip is not in database. As a result HDD is being driven by ata rather than nv_sata driver. No problems apart from loss of hot plug functionality (which I don't use). 4. The sound chip just sucks. Really. It fights for the IRQ with the NIC driver. Sometimes it just causes the NIC to freeze. No data will go through. The solution is to re-plumb the interface. 5. If I boot in windows, the NIC will NOT come up. It just won't connect. The solution is to either do a proper cold boot OR just go into NIC netboot PROM for a second or two. That resets it nicely. The windows drivers work (??) right but then I don't believe that specs are open source. I also tried Masa-san's nfe driver. It works right, as long as I don't put the switch in the loop. But I don't have that luxury. Lesson: Stay away from cheap HW. It causes more headache. I've wasted enough time on this mobo that the better one would have saved me a lot of money and anguish. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Support for AMD 780G chipset? OMG!!!
this is an officially CUT feature (that is, it was removed from the final product, and will have to wait for future hardware revisions to work) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
