xterm - truetype fonts and missing underscore
Hello, recently (not sure exactly when) my xterms no longer showed the underscore character. In my .Xresources I had (and have had this setting for years): XTerm*faceName: Monospace XTerm*faceSize: 10 I noticed when experimenting and modifying values that for one choice the bottom part of letters like 'g' was missing. So changed faceSize to 11 and all is good. In gnome-terminal with Monospace/10 font underscores showed up fine (and was ok in gnome font selector). So it appears to be xterm specific. Has anyone else experienced this? cheers -- Tony Maheremail: tonyma...@optusnet.com.au ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: xterm - truetype fonts and missing underscore
On 08/25/11 01:27, Volodymyr Kostyrko wrote: 24.08.2011 12:01, Tony Maher wrote: Hello, recently (not sure exactly when) my xterms no longer showed the underscore character. In my .Xresources I had (and have had this setting for years): XTerm*faceName: Monospace XTerm*faceSize: 10 I noticed when experimenting and modifying values that for one choice the bottom part of letters like 'g' was missing. So changed faceSize to 11 and all is good. In gnome-terminal with Monospace/10 font underscores showed up fine (and was ok in gnome font selector). So it appears to be xterm specific. Has anyone else experienced this? +1 from me http://lists.nongnu.org/archive/html/freetype/2011-08/msg00020.html Ok. Thanks for the link. cheers -- Tony Maheremail: tonyma...@optusnet.com.au ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: xterm - truetype fonts and missing underscore
On 08/25/11 01:43, Mark Saad wrote: What else is in you .Xresources file. I removed it entirely and problem remains. Also have you tried using xft formated font names. Ie xft:luxi mono:size=10 ? xterm -fa 'xft:luxi mono:size=10' produces an xterm which display correctly xterm -fa 'xft:Monospace:size=10' produces an xterm that displays incorrectly. The linkVolodymyr Kostyrko explains the problem. cheers -- Tony Maheremail: tonyma...@optusnet.com.au ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
7.1 prelease, dump, dtrace
Hello, Just some observations. I upgrade from 7.0 release to 7.1 prerelease (Oct 16) which went fine as usual :-) Then wanted to try dtrace. Initially just added options options KDTRACE_HOOKS options DDB_CTF options KDTRACE_FRAME Made kernel and rebooted ok. Then read handbook and followed # cd /usr/src # make WITH_CTF=1 buildworld # make WITH_CFT=1 kernel # make WITH_CFT=1 installworld # mergemaster -Ui Rebooted GEOM: new disk ar0 Trying to mount root from ufs:/dev/ar0s2a start_init: trying /sbin/init init died (signal 6, exit 0) panic: Going nowhere without my init! cpuid = 0 Uptime: 6s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Hmmm. Run restore from backup disk (7.0) cvsup again and reinstall 7.1 Do the dtrace kernel mods and just make kernel WITH_CFT=1. Reboot everything appears ok. Power up the USB disk used for backups. Hmmm. Hard lock. Page fault in usb3. Load up kernel with dtrace but not with WITH_CFT=1. Same problem. Next time power on disk before booting. Boots ok and usb disk mounts ok. Ok rebuild kernel without any dtrace options and reboot. Now can power on usb disk after booting and it all works ok. Ok - so stay away from dtrace for now! On another subject dump. I dump to a usb disk and to save space pipe output thru gzip before sending to disk $DUMP $ARGS -$LVL -f - /dev/$fs | gzip -1 -c > $dumpfile ; This has been working fine. A month ago I got a new larger usb disk so tried to send directly to disk and avoid the gzip. Dump stalled. Tried thru gzip to new disk - works fine. I saw the threads about dump stalling so stuck with piping thru gzip. Read it is supposed to be fixed under 7.1 so tried dump direct to disk under 7.1 and it works fine! System is FreeBSD 7.1-PRERELEASE #6: Fri Oct 17 19:55:21 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KARMA Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz (2687.71-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4208721920 (4013 MB) avail memory = 4049219584 (3861 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard ... ... So dump good, dtrace not so good! (dtrace -l worked) Everything else appears to be working fine. Thanks for all the hard work. cheers -- Tony Maheremail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7.1 Release and usb keyboard/mouse problems
Hello, I have been running FreeBSD 7 from around 2008-10-20 and experienced the occasional problems with usb mouse and keyboard. The mouse pointer slowly drift to a corner of the screen and not respond, and the keyboard would become unresponsive. Unplugging and plugging back in fixed the problem. This would happen a few times per week. However after I upgraded to 7.1-RELEASE-p2, I now get this problem every few hours if idle (hard to know exactly when it occurs since i am not at keyboard) and a few minutes if doing a background compilation. The keyboard often shows one of the LEDs constantly flashing at high speed. Unplugging and replugging often does not work and needs to be done several times (and use a different usb port). I saw some email reports and tried in /boot/device.hints hint.atkbd.0.disable="1" hint.atkbdc.0.disable="1" No change. Tried a different mouse and it would continue to work but my normal mouse would disconnect. Tried an identical keyboard and it exhibited the same problem ruling out a bad keyboard. I then tried another keyboard and have not had any problem since. The main thing I can see different is the working keyboard is a Logitech and the two problematic keyboards are (very) cheap noname keyboards. Both the mice are Logitech but the mouse that has problems is very old (from around year 2000 - model M-BA47). The working mouse is newer but still fairly old (Model M-UV96). The box is a amd64 with Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GH 4GB RAM and motherboard is Intel DP35DP. So my setup now appears to be fine. If anyone is having similar problems, I suggest trying different (more modern) mice/keyboards. cheers -- Tony Maheremail: tonyma...@optusnet.com.au ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.1 Release and usb keyboard/mouse problems
Andrei Kolu wrote: Martin wrote: Am Sat, 17 Jan 2009 21:23:09 +1100 schrieb Tony Maher : Hello, I have been running FreeBSD 7 from around 2008-10-20 and experienced the occasional problems with usb mouse and keyboard. The mouse pointer slowly drift to a corner of the screen and not respond, and the keyboard would become unresponsive. Unplugging and plugging back in fixed the problem. This would happen a few times per week. Hi, I've reported problems like this on -STABLE more than once already. Apparently it is a very uncommon problem for the developers. I have to say that all my new PCs and the new laptop has problems with USB keyboards and mice generally. The laptop (IBM Thinkpad T60p) has the most problems, -STABLE switches the USB devices off in intervals of about 2h. I have updated (flashed) my BIOS firmware on this mainboard here (Gigabyte GA-EP35C-DS3R rev 2.1) to the recent firmware F4a (it's a 6 month old beta release). The problem worsened now. I cannot get my USB mouse working until I reattach it physically. This is not a problem on other OSes, it seems. During device detection and initialization of uhci/ehci my USB-mouse is switched off and does not get power anymore. I get the same effect on -CURRENT as of yesterday. Mouse is Logitech G5, btw. I tried various USB settings in BIOS. USB mouse support on/off, USB legacy device support on/off. What else can I do? This is very annoying. (I wonder if it can be the source of many problems that people report here about umass devices.) Hi, I have similar problem with Gigabyte GA-X48-DS4- I can't boot from usb flash drive or usb floppy drive 9times of 10. My APC ups was recognized only after OS is booted up and usb cable reinserted. Looks like this is Gigabyte problem only- all other motherboards work without any usb issues. Bios upgrade does not help. Changing any bios setting does not help either. My problem is on an Intel based board. Just tried my USB based disk and it appears to work fine. It was just the old keyboard and mouse. Since replacing them there has been zero problems. Given the symptoms it appears it is a subtle timing bug and thus unfortunately very hard to debug. :-( You could try reverting to older versions to try an pinpoint which commit changed things. Very time consuming I know. sorry -- Tony Maheremail: tonyma...@optusnet.com.au ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.1 Release and usb keyboard/mouse problems (and Xorg)
Tony Maher wrote: Hello, I have been running FreeBSD 7 from around 2008-10-20 and experienced the occasional problems with usb mouse and keyboard. The mouse pointer slowly drift to a corner of the screen and not respond, and the keyboard would become unresponsive. Unplugging and plugging back in fixed the problem. This would happen a few times per week. However after I upgraded to 7.1-RELEASE-p2, I now get this problem every few hours if idle (hard to know exactly when it occurs since i am not at keyboard) and a few minutes if doing a background compilation. The keyboard often shows one of the LEDs constantly flashing at high speed. Unplugging and replugging often does not work and needs to be done several times (and use a different usb port). I saw some email reports and tried in /boot/device.hints hint.atkbd.0.disable="1" hint.atkbdc.0.disable="1" No change. Tried a different mouse and it would continue to work but my normal mouse would disconnect. Tried an identical keyboard and it exhibited the same problem ruling out a bad keyboard. I then tried another keyboard and have not had any problem since. The main thing I can see different is the working keyboard is a Logitech and the two problematic keyboards are (very) cheap noname keyboards. Both the mice are Logitech but the mouse that has problems is very old (from around year 2000 - model M-BA47). The working mouse is newer but still fairly old (Model M-UV96). The box is a amd64 with Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GH 4GB RAM and motherboard is Intel DP35DP. So my setup now appears to be fine. If anyone is having similar problems, I suggest trying different (more modern) mice/keyboards. Unfotunately things got worse after more port upgrades. With Xorg 7.4 and gnome could not even get the logon screen - just a busy cursor. The Xorg.0.log had a message like (EE) Logitech USB Keyboard: cannot open "/dev/ukbd0" (EE) PreInit failed for input device "Logitech USB Keyboard" (II) UnloadModule: "kbd" which made me think this was the problem. However I now have everything working fine and still get this message. Reverting X and gnome back and applications like xterms were slow to start up plus mouse was slow to respond. Tried lots of options but in the end gave up and went for a clean install of 7.1 (First time I have ever had to do this in over 10 years of using FreeBSD!) Everything worked pretty good. Did a cvsup and upgraded everything and all works fine. The only problems I did encounter were/are: 1. my xorg.conf options were ignored Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbOptions" "ctrl:nocaps" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection /var/log/Xorg.0.log shows (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled. Not sure why this is. Man page says Option "AllowEmptyInput" "boolean" If enabled, don't add the standard keyboard and mouse drivers, if there are no input devices in the config file. Enabled by default if AutoAddDevices and AutoEnableDevices is enabled, oth- erwise disabled. If AllowEmptyInput is on, devices using the kbd or mouse driver are ignored. It is not set in my xorg.conf and neither are Auto* directives. ~:255 egrep 'Auto|Allow' /usr/local/etc/X11/xorg.conf ~:256 To get the ctrl:nocaps used the gnome keyboard setting tool. Mouse works fine except the side button does no work and fixed that by adding moused_flags="-m2=4" to rc.conf. 2. gxine after upgrade would always segmentation fault. I used portupgrade -y -m BATCH=true gxine and this appears to be the problem. I rebuilt using make config selecting all options except lirc support. Did portupgrade -w -W gxine and it now works fine. 3. At some point along the line I (re)discovered the 'fc-cache -f -v' which fixed slow xterm startup. I tried plugging in the old keyboard and mouse along side the more modern ones I have been using since the problems started and they appear to be ok. I was using the old mouse but the new keyboard (with the other two still attached). I was going to say they worked fine but just before the start of this paragraph I started to get '9' repeated across the screen and the keyboard was unresponsive. I had also just powered up a USB drive a few minutes before this happened but I had run with this configuration all day yesterday without problems.. I have removed the older keyboard and mouse for now.
Re: Broken loader in STABLE
Adam Retter wrote: > On Fri, 2006-09-08 at 08:48 +1000, Tony Maher wrote: >>Do you have any compile options in /etc/make.conf? >>These can affect loader. > > Yes, these are set in make.conf, but I have always had these set and > there have been no problems in the past... > > > # Compile for Pentium 4 CPU > CPUTYPE=p4 > > # Compiler optimisation flags > CFLAGS= -O2 -pipe -funroll-loops -ffast-math > > # Compiler optimisation flags for the Kernel > COPTFLAGS= -O2 -pipe -funroll-loops -ffast-math >From private email from someone else with same problem (they had -funroll-loops in make.conf), "optimizations are bad for the loader"... but it still works fine for me using -O -pipe. -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: optimization levels for 6-STABLE build{kernel,world}
Gary Kline wrote: > > > A couple of things. Will having gcc unroll loops have any > negative consequences? (I can't imagine how:: but better > informed than to have something crash inexplicability.) > With 6.X safe at -O2 and with -funroll-loops, that should be > a slight gain, right? (It also will make an upgrade from 5.5 > to 6.[12] that much more rational.) -funroll-loops affect loader see http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028145.html -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
Marc G. Fournier wrote: > On Tue, 12 Sep 2006, Steve O'Hara-Smith wrote: > >> On Tue, 12 Sep 2006 10:55:48 -0500 >> Greg Barniskis <[EMAIL PROTECTED]> wrote: >> >>> If you /track/ STABLE by frequently cvsupping it and rebuilding your >>> system, you will very likely encounter a serious problem sooner or >>> later. That's why tracking it is not recommended for production >>> systems. >> >> >> I did exactly that all the way from 2.0 to 4.11 on various machines >> without ever having any trouble. > > > Ditto ... in fact, I do that on my desktop and have yet to hit a problem > ... -STABLE *is* generally very stable ... > > Stupid question here ... if -STABLE shouldn't be tracked, who exactly is > doing testing on it? Those doing "the work" on -CURRENT, I would > imagine, are tracking -CURRENT, and testing the code put in there for > bugs ... when deemed 'bug free', then its being MFCd to -STABLE, but if > those of us that *are* tracking -STABLE stop'd tracking it ... who would > be testing it? It is not that you should not track it but where you should be tracking/testing it. Not on critical production servers would be a good start ;-) -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5 to 6
Andrew Reilly wrote: > On Mon, Oct 23, 2006 at 10:05:30PM -0700, Doug Barton wrote: > >>Andrew Reilly wrote: >> >> >>>So: my two cents: it can work, but it's possible for it not to >>>work, and care is required. >> >>That's always true, but worth a reminder nonetheless. :) >> >> >>>[*] The production server is using a software RAID mirror on >>>a pair of SATA drives on a low-end Intel P4/ICH6 motherboard, >>>using ar(4), configured by atacontrol. Fsck on 6.x can't find >>>any superblocks on /usr, but 5.5 is fine. >> >>By chance did you upgrade this fs in place from a 4.x install? In >>other words, do you have only UFS1? > > > That's an interesting question. This server has been through a > goodly few incarnations, over many years. Once upon a time it > was running 3.4 or there abouts. I thought that I had re-built > it from scratch the last time (to 5.3), which presumably would > have given me UFS2, but the possibility exists... > > How would I be able to tell? tunefs -p lists ACLs and MAC > multlabel and soft updates, but of those only soft updates is > enabled, so I don't know if that is conclusive. Did UFS2 give > us anything beyond ACLs and largeness? bsdlabel, mount and df > don't seem to give any particular indication... > > Cheers, > dumpfs / | more magic 19540119 (UFS2) timeThu Oct 26 14:29:14 2006 -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5 to 6
Andrew Reilly wrote: > On Thu, Oct 26, 2006 at 04:14:53PM +1000, Tony Maher wrote: > >>dumpfs / | more >>magic 19540119 (UFS2) timeThu Oct 26 14:29:14 2006 > > > Thanks for the tip. Same on this system, so I must have given > it a proper clean install when I moved to 5.3. > > The dumpfs output seems to say a lot of interesting things. > Might dumpfs /usr be able to tell me why the 6.2-BETA > kernel/fsck can't find it's super-blocks? Sorry do not know much about these commands but doesn't ffsinfo show superblock info? ffsinfo -o /var/tmp/ffsinfo.log / = START SUPERBLOCK = # [EMAIL PROTECTED]: primary sblock sblknoint32_t 0x0028 cblknoint32_t 0x0030 iblknoint32_t 0x0038 dblknoint32_t 0x0bb8 old_cgoffset int32_t 0x old_cgmaskint32_t 0x old_time int32_t 0 old_size int32_t 0x ... state int32_t 0x old_postblformat int32_t 0x old_nrpos int32_t 0x spare5int32_t[2] 0x 0x magic int32_t 0x19540119 = END SUPERBLOCK = > Hmm, that's odd. Most of the 400 cylinder groups in /usr have a > "time" value that is in about the last month (most much closer > to "now" than that). The very last one doesn't seem to have > been touched since Jul 2005, which is plausibly when I formatted > it. Neither does it list any inodes used. Is this normal > behaviour or a sign of something ill? I see: magic 19540119 (UFS2) timeThu Oct 26 20:55:15 2006 superblock location 65536 id [ 42d64d1d 5cdf5278 ] ncg 6 size524288 blocks 506487 bsize 16384 shift 14 mask0xc000 fsize 2048shift 11 mask0xf800 frag8 shift 3 fsbtodb 2 minfree 8% optim timesymlinklen 120 maxbsize 16384 maxbpg 2048maxcontig 8 contigsumsize 8 nbfree 48586 ndir107 nifree 136086 nffree 1667 bpg 11761 fpg 94088 ipg 23552 nindir 2048inopb 64 maxfilesize 140806241583103 sbsize 2048cgsize 16384 csaddr 3000cssize 2048 sblkno 40 cblkno 48 iblkno 56 dblkno 3000 cgrotor 4 fmod0 ronly 0 clean 0 avgfpdir 64 avgfilesize 16384 flags none fsmnt / volname swuid 0 cs[].cs_(nbfree,ndir,nifree,nffree): (10282,26,23415,292) (5367,10,21384,206) (5706,16,21567,1081) (10078,25,2269 6,84) (10792,30,23472,4) (6361,0,23552,0) blocks in last group 6731 cg 0: magic 90255 tell18000 timeFri Oct 13 17:27:50 2006 cgx 0 ndblk 94088 niblk 23552 initiblk 256 nbfree 10282 ndir26 nifree 23415 nffree 292 rotor 15880 irotor 7 frotor 3104 frsum 1 3 1 16 11 19 7 sum of frsum: 292 clusters 1-7: 7 2 2 13 1 0 0 clusters size 8 and over: 6 clusters free: 384, 413, 439, 444, 473-475, 477, 540-541, 544-545, 550, 626-630, 636, 675-686, 695-698, 745-748, 795-798, 837-850, 866-868, 887-1042, 1051-1054, 1101-1104, 1151-1154, 1201-1204, 1251-1254, 1301-1304, 1351-1354, 1401-1404, 1451-1454, 1501-1504, 1543-1786, 1971-1985, 1994-11760 inodes used:0-14, 16-61, 63-65, 67-136, 138-140 blks free: 3002-3007, 3009-3015, 3017-3023, 3027-3031, 3050-3055, 3066-3085, 3091-3095, 3098-3103, 3122-3127, 3130-3135, 3138-3149, 3152-3157, 3163-3167, 3171-3175, 3179-3183, 3187-3196, 3266-3271, 3276-3279, 3285-3287, 3296-3301, 3304-3311, 3328-3331, 3344-3347, 3354-3364, 3374-3375, 3384-3389, 3392-3398, 3400-3406, 3408-3412, 3416-3419, 3424-3430, 3432-3438, 3440-3446, 3448-3453, 3472-3477, 3512-3519, 3540-3543, 3548-3559, 3576-3581, 3647-3653, 3764-3767, 3774-3775, 3784-3813, 3816-3823, 4051-4055, 4244-4247, 4315-4335, 4352-4367, 4396-4407, 4414-4415, 4564-4567, 4652-4655, 4740-4743, 4828-4831, 4916-4919, 5004-5047, 5088-5095, 5400-5495, 5560-5591, 5960-5991, 6360-6391, 6696-6807, 6924-6951, 7096-8343, 8408-8439, 8808-8839, 9208-9239, 9608-9639, 10008-10039, 10408-10439, 10808-10839, 11208-11239, 11608-11639, 12008-12039, 12344-14295, 15768-15887, 15952-94087 ... -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: a place for configuration files
Andrzej Cuber wrote: > ... > In RedHat and Fedora distributions all configuration files are located > at /etc. > I am very new to FreeBSD but I found it difficult. After installing > desired package I have to add it to /etc/rc.conf in order to start it as > a service and then I have to look for configuration folder in > /usr/local/etc. > > Is there any reason why the configuration files are placed in those > different locations? If you want to be consistent you could add to /etc/rc.conf rc_conf_files="/etc/rc.conf /etc/rc.conf.local /usr/local/etc/rc.conf" Then your startup variables could go into /usr/local/etc/rc.conf and all your ports config stuff would live in /usr/local/etc hierarchy. There maybe a problem if /usr/local/etc/rc.conf is on another partition not available early enough in startup process. Caveat emptor. -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Need help with isp driver and disk arrary
Claus Guttesen wrote: >>I am having a problem with the isp driver seeing a StorageTek disk >>array LUNs. I am directly attaching to the array and everything works >>find as long as I plug into the A controller on the array. When I >>connect up to the B controller, I can not see any of the LUNs >>advertised. The QLogic firmware can see the LUNs. The only difference >>I can see are that the LUNs start at 0 on the A side and at 3 on the B >>side. > > > In 5.x (and probably still applies to 6.x) LUN's have to start at 0 in > order to be visible. So you have to change or LUN-mask so they start > at 0. And in 4.x. This behaviour is unlikely to change since the standards only require checking for device at lun 0 (and if found then scanning for more). You can use camcontrol to rescan the bus (or device) to make it visible. -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Need help with isp driver and disk arrary
[EMAIL PROTECTED] wrote: >>You can use camcontrol to rescan the bus (or device) to make it visible. > > > Thanks for the help. Looks like I am out of luck on this one. > Rescanning the bus does not show the LUNs. Remapping the LUN is out > due to license issues with the unit. I am investigating how much it > will cost to activate the feature but I don't have high hopes of that > happening. Sorry it as a long time ago - you actually have to specify the lun rather than the bus From: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=21038+0+/usr/local/www/db/text/2003/freebsd-scsi/20030727.freebsd-scsi Finally was able to see disk with a 'camcontrol rescan 1:0:4' command. Previous 'camcontrol rescan all' and 'camcontrol rescan 1' failed to see disk. -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Maximum Swapsize
Pete Slagle wrote: > Daniel O'Connor wrote: > >> The old "swap size = 2x RAM" rule is no longer applicable unless you >> have a very special application. > > This "rule" always seemed counterintuitive to me anyway. > > When you have very limited physical RAM you need a lot of swap space. > When you have more than enough RAM you don't need any swap space at all. > For a given set of applications, as RAM increases you need less swap > space, not more. And vice versa. Provided the maximum "working set" of processes fits into RAM, you have sufficient RAM. Seldom used processes can be swapped out with minimal impact on the system. So as well as the "very special aplication" exception, the workload patterns (over a day) may allow for reduced RAM and utilize swap instead. In which case swap size should be sized to match. Maybe not important for a single machine but for multiple machines the cost of RAM memory adds up. -- tonym ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rsh problems
> : rshdauthrequiredpam_deny.so > : to > : rshdauthsufficient pam_deny.so > : > : fixes the problem. > : > : Should this be changed in CVS or is there some reason why it should remain > : 'required'? > > I think it should be changed back. We're going to get a lot of > questions about this, I think. Hmm - turns out the above is not the whole solution but a partial hack. freebsd> rsh office Password: works but /var/log/messages gives: Nov 9 20:20:17 office rlogind[10201]: auth_pam: Permission denied Nov 9 20:20:17 office rlogind[10201]: PAM authentication failed Something still screwy with this (or is it just me!). Sorry but I don't have the expertise or time to debug this and 4.2 due real soon :-( thanks tonym To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: rsh problems
> Try, > > rshdauthsufficient pam_permit.so > > Nothing breaks and rsh behaviour is restored, including prompting for > passwords when required. Thanks. Mike Ruhl suggested the same a day ago and yes it works fine. tonym To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problem With sshd When updating to -STABLE
you forgot mergemaster step. tonym To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Adaptec 19160 and Data Parity Errors
Hello, I had a 4.2 release with Generic kernel on a Pentium 233MHz MMX, and wanted to add scsi tape drive. Installed an Adaptec 19160 and it detected fine but hung after the 15s waiting for scsi devices to settle message. (there are no devices and card set to auto terminate and also tried termination on) Last messages was Mounting root from ufs:/dev/ads01a Put the card in a 4.3-beta box (Celeron 300A built a couple of days ago) and it worked fine. So upgraded the 4.2R to 4.3-beta. Now it boots up but get constant bold messages ahc: Data Parity Error Detected during address or write data phase PCI Interupt at seqaddr=0x8 <- this also alternates with 0x9o They look like they occur on every access to PCI bus. i.e. they do stop but accesses to disk appear to star the these messages again. There is graphics card and intel 100Mb ethernet card occupying 2 PCI slots. Have tried the adaptec card in both the availble free PCI slots - same deal. Tried BIOS setting plug-n-play of and on. Any ideas? Hardware problems? Bios problems? thanks tonym To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Adaptec 19160 and Data Parity Errors
> Nothing was committed that would affect reported PCI parity errors. > It may be that your chipset just doesn't generate parity correctly. > It may also be that the card edge is dirty or the slot is. Hard > to say. The parity error reporting can be disabled if necessary. > I'll look into adding a device flag for that in the near future. Ok. I dont think its the card since its brand new and works ok in the other box. I'll try cleaning the slots and addtionally installing an older 2940 board (have to retrieve it from another box at home so it will take a couple of days). BTW I believe the motherboard uses VIA chipset (and its obviously old version) thank you tonym To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Out of buffer space
Hello, I have also had my laptop freeze twice in the last 30 hours. It is a Dell Inspiron 3500 (maybe somethign specific to Dell?). Everything works fine [1] and last freeze was while building a port. Was in X and cursor still moved but buttons/keyboard had no effect. Nothing in the log files either. I (foolishly) ejected both pcmcia cards with no effect but didn't think to test network first. Reinsertion of cards had no effect and external ethernet dongle leds were all off (not surprising). I also saw out of buffer space earlier in the day but I had been experimenting with vmware at the time and (I think) rebooted shortly after seeing th message to clear it. The first freeze yesterday occured while I was out and the laptop sitting idle on the home network. If it happens again I'll file a PR but there is not much to go on :-( tonym [1] except the warm reboot with pcmcia card inserted http://www.freebsd.org/cgi/query-pr.cgi?pr=29794 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
