Re: x for users slow
> On Monday 01 August 2005 17:34, Eriq wrote: > > after all of this, I notice that it takes a user about a minute after > > 'startx' to get into X. Yes I know, but I still like the colors :) > > anyway this doesn't happen when I logon as root and start X. Blackbox is > > the WM hope this helps. > > At a wild guess I would say your DNS is broken. Umm, yup, maybe. There might be another phenomena, however. I resisted moving my laptop from XFree86 to XOrg until it became too much of a pain staying back. I only switched when VMware broke for me and I needed to try OpenOffice. When I finally moved to Xorg (and rebuilt all my ports with portupgrade for good measure), the first thing I noticed was that it took almost a couple of minutes[0] on my laptop (1GHz PIII) for 'wdm' to display the login window and overlay the background over the grey weave. The hdd LED was lit solidly the entire time. IIRC, the same machine (actually, it had a slower CPU then) with XFree86 took maybe 10-15 seconds when I typed 'wdm&&exit' at a root prompt. This is with 4.1[01]-STABLE, the built-in graphics are ATI Rage Mobility (Mach64), not exactly bleeding edge (and fairly well supported). Other than that idiosyncracy, (and some infrequent odd effects with either xine or mplayer that can be cleared by re-starting the X server, at least some of which also happened with XFree68 and are probably due to the player apps), the Xorg server seems to work just fine. It does seem to behave somewhat differently to XFree86 on startup, however. If all he's noticing is a slow X startup with the Xorg server, thats an from me. I can't comment if starting it as a user is even slower, because I almost never use 'startx', I always run a display manager and log into that. Cheers, AS [0] OK, I haven't actually timed it, but it's at least a minute, probably longer and it's 100% consistant. pgpKpKAgF3LYF.pgp Description: PGP signature
PCI probe problem? Can't get CMD646 out of BIOSPIO mode?
Hi, I'm having a little trouble getting a CMD646 (built into to my laptop's docking station) to do anything other than BIOSPIO. It comes up in BIOSPIO, and atacontrol fails to set it higher... Not surprisingly, it pegs the CPU mightily when I try to use anything on those interfaces. Luckily my DVD-R has burnfree, but even so it's running @ 25% rated speed and completely flattening the system to do it... There's several devices on the PCI bus behind the bridge (I presume) for the docking station, a SymBIOS SCSI controller (which works fine), the CMD646 and a second TI cardbus/PCMCICA controller (which seems to get irq=255, and doesn't work; unfortunate as the built-in PC-cards are deliberately obscured when the laptop is docked). I tried setting hw.ata.atapi.dma=1, which doubled the reported speed for the IDE devices on the laptop's internal IDE controller (whoo-hoo!), but this didn't affect the stuff on the CMD646... If I'm reading the code right, the PCI probe for the CMD646 returns various I/O addresses and sizes. However, all of the sizes are < ATA_BMIOSIZE, and thus channel->r_bmio gets set to zero (in ata-dma.c). So the dmesg probe says "bmaddr=0x", which I intuit is "no address for Busmastering for you". I tried setting PCI_ENABLE_IO_MODES, which made little difference (I diff'd the dmesg's from 'boot -v'). Can anyone make any suggestions for perhaps getting this to work a little better, or is my only hope to eat a PCI slot for a Promise/HighPoint Ultra IDE controller? Which is preferred or are they pretty much as good as each other? Thanks for any help! Cheers, AS [boot -v dmesg attached:] syncing disks... 111 done Uptime: 40m2s The operating system has halted. Please press any key to reboot. Rebooting... Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.10-STABLE #139: Sun Oct 10 22:30:16 PDT 2004 [EMAIL PROTECTED]:/usr/src/sys/compile/tureg Calibrating clock(s) ... TSC clock: 796538270 Hz, i8254 clock: 1193183 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Intel Pentium III (796.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 536805376 (524224K bytes) Physical memory chunk(s): 0x01000 - 0x9efff, 647168 bytes (158 pages) 0x00048c000 - 0x01ffe7fff, 532004864 bytes (129884 pages) avail memory = 517795840 (505660K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f67c0 bios32: Entry = 0xfd82c (c00fd82c) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x2b0 pnpbios: Found PnP BIOS data at 0xc00f67f0 pnpbios: Entry = f:9c4f Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: ACPI: 000f6780 Preloaded elf kernel "kernel" at 0xc0465000. Preloaded elf module "snd_maestro3.ko" at 0xc04650a8. Preloaded elf module "snd_pcm.ko" at 0xc046514c. VESA: information block 56 45 53 41 00 02 00 01 00 01 00 00 00 00 22 00 00 01 7f 00 00 01 0b 01 00 01 21 01 00 01 2a 01 00 01 00 01 01 01 10 01 11 01 12 01 03 01 13 01 14 01 15 01 05 01 16 01 17 01 18 01 07 01 19 01 VESA: 0 mode(s) found module_register_init: MOD_LOAD (vesa, c0300898, 0) error 6 Pentium Pro MTRR support enabled Creating DISK md0 md0: Malloc disk pci_open(1):mode 1 addr port (0x0cf8) is 0x80003904 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Using $PIR table, 9 entries at 0xc00fdf30 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard found-> vendor=0x8086, dev=0x7190, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base f800, size 26 found-> vendor=0x8086, dev=0x7191, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found-> vendor=0x8086, dev=0x7110, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base 1460, size 4 found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=10 map[20]: type 1, range 32, base 1440, size 5 found-> vendor=0x8086, dev=0x7113, revid=0x03 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[90]: type 1, range 32, base 2180, size 4 found-> vendor=0x104c, dev=0xac51, revid=0x00 class=06-07
Re: [releng_4 tinderbox] failure on alpha/alpha
> > The same thing started in -PORTS quite some time ago, where I find > > personally find that it generates more [EMAIL PROTECTED] than the real traffic at > > times. > > You're entitled to your opinion, Thanks, I will clarify it further for you. > but since you've never had to deal > with the flood of support requests when INDEX builds were broken by > careless committers before I started the automated tinderbox, Wouldn't the real issue be to control the careless committers then? Or to target them specifically and directly with the Tinderbox failures? When I automated overnight builds of mutiple branches of a commercial product on mutiple OS platforms, sending those build results company-wide was never considered as an option. I just don't see why it isn't more appropriate to simply limit the messages to people with a commit bit, a specific email alias, or even people who checked stuff in since the last sucessful Tinderbox. > I'd > suggest you try to consider it from point of view of those of us who > are actually involved in the support of the OS. It's not that I don't appreciate the efforts that are being made so much as I question the elegance of the solution employed. Some people pay for (limited) bandwidth by time on-line, and cannot filter except after receipt, thus have no choice but to *pay* to retrieve those messages before filtering them, so it's not simply a question of whether they "just hit delete" or filter them out or whatever. Those messages thus inevitably dilute the value of the list for them, I suggest you try to consider it from *their* point of view. There's also the issue that all the descriptive fields for -STABLE and -PORTS say that these are "discussion" lists - which *used* to be true. Multiple posts from Bots don't make for much of a "discussion", in my book. Whatever. Procmail works for me, but not everyone has that choice. AS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ThinkPad R31 - Lucent windmodem woes....
> Sorry to hear that you got stuck with an mWave ISDN part. I didn't > know such a thing existed. Heh. It's *huge*, it's a full-length ISA card - about the only one I've ever seen, modulo the Archive QIC-02 interfaces I still have... Still, it came with a "free" IBM NT-1, which is worth more than I paid for the mWave, so I don't feel gouged at all. :) Cheers, AS msg51951/pgp0.pgp Description: PGP signature
Re: TV output turn on
> > Have you tried 'mplayer'? It seems to be more flexible (and faster, > > smoother, etc.) for most of the DVD's I own. > > Ditto, although the video/audio sync sometimes has to be adjusted by > +/- 200ms. Ogle has also gotten much, much better of late, and offers > DVD menu support. Heh. Yes, I sometimes run it just to see what they look like, particularly if I have a DVD (IIRC, "The Professional" did this) that plays some segment that isn't the feature by default, and you need to work out where to point 'mplayer' so you can watch the movie... > > Hmm? I don't see how v4l will make any difference? I could (easily > > ;-) be wrong, but I thought video4linux was video-capture-related? > > My reading of the GATOS website suggests that atitvout is built on > top of video4linux, which, in addition to video capture, also attempts > to pull some of the lower level Xlib functionality into the kernel and > present a common API to video in/out tools. > > I could (easily :-) be wrong, but I did spend quite some time on > this, hoping to make better use of my Radeon VIVO. I ended up buying > a Hauppauge WinTV Go! card to get by for now. Huh. Perusing the 'atitvout' web page /again/ (which is at http://www.stud.uni-hamburg.de/users/lennart/projects/atitvout), I still can't see any mention of 'video4linux', the author seems to be saying that it uses ATI VESA calls to set up the functionality. However, as I don't have anything that would benefit from this (or could test it on), my interest is fairly academic... > > I use the Gatos ATI drivers on my Mobility M1 to provide XvImage > > support (hardware scaling and color transform), and they work great. > > Indeed they do. Last crack, they didn't build against XFree86 > 4.2.x (one of the Radeon chip constants got bifurcated in X, but GATOS > didn't track this change). Perhaps this has been fixed by now--I miss > having hardware scaling on my laptop, and I haven't had time to bake > and contribute a patch. Another option is to use DGA - this often gives the very best results, actually, for all that it's a potential security hole (actually, a perfectly acceptable tradeoff for a single-user machine, IMHO, I generally set 'mplayer' SGID something that I chmod /dev/mem group read/writable to, and add ). Also, note that you don't need to build the Gatos drivers (unless you really, really, distrust pre-compiled binaries! ;-). This is because the XFree86 portable/loadable modules scheme is platform (but not processor)-independant. I just install the Linux x86 Gatos binary drivers on top of XFree86, and they get loaded into the XFree86 server at run-time using their own scheme and then run directly - without going through the Linuxator, so you don't even need that installed. Been doing this for about the last 4-5 revs of these drivers, from XFree86 4.1 up to the current FreeBSD port version, has always Just Worked As Designed. > > drm and dri are not available for the Rage 128 Mobility M1, so I > > don't see how they are necessary to use the Gatos stuff... > > They're needed for v4l, which in turn is (I believe) needed for > atitvout. OK, you may be right - I certainly can't test it :) > If someone shows me to be wrong, I'll be *ecstatic*. I'd love to > yank out the WinTV card and put a slot fan in its place. There's > nothing wrong with the WinTV card, mind you, and this is not a knock > at Hauppauge; I just hate having redundant cards in my machine. Yes, I love my WinTV. Oooh, that sounds like something else. :) > > Heh. After two years of using my laptop to do just that, I'm > > astonished how much better (particularly more vibrant colors) > > everything looks on a CRT since I started docking it... :-) > > Iiyama. The only way to fly. :-) I bought a refurb'd IBM P201 oh, 5 years ago for $600 - which was a pretty good deal for a 20" Trinitron multisync monitor that did 1600x1200@85hz at the time... Only time I've ever regretted it is whenever I have to pick it up and move it :-) Cheers, AS msg51315/pgp0.pgp Description: PGP signature
Laptop with fresh -STABLE spontaneously suspends
Hi, Since I cvsup'd to a Nov 5th -STABLE, my laptop (Omnibook 6000) has taken to spontaneously deciding to suspend itself if I haven't typed on it for some minutes (probably at least 30 minutes). Oddly, I've also seen it decide to suspend itself within 2-3 seconds of being manually resumed, e.g. before it had actually finished resuming. I've checked the BIOS settings, and those are set to not perform any power-saving at all whilst the machine is on AC power. As it's doing this whilst docked (and thus on AC power), it shouldn't be this... This literally only started happening since the buildworld/installworld, but it's gonna be a problem if it persists... The log messages look entirely normal: Nov 8 12:52:47 tureg apmd[180]: apmevent 0002 index 1 Nov 8 12:52:47 tureg apmd: suspend at 20021108 12:52:47 Nov 8 12:53:11 tureg /kernel: resumed from suspended mode (slept 00:00:17) Nov 8 12:53:13 tureg /kernel: ata0: resetting devices .. done Nov 8 12:53:13 tureg /kernel: ata1: resetting devices .. done Nov 8 12:53:13 tureg /kernel: ata2: resetting devices .. done Nov 8 12:53:13 tureg /kernel: ata3: resetting devices .. done Nov 8 12:53:11 tureg apmd[180]: apmevent 0003 index 2 Nov 8 12:53:13 tureg apmd: resumed at 20021108 12:53:13 except that the suspend wasn't initiated by a human hitting the blue button or closing the lid, like it should be... The only other thing I've changed recently is to add a 'sym' device and plug in an ADIC autochanger - but I can't see that that would cause this, and I'm almost positive that I'd done this before the latest buildworld without seeing it. Anyone else seeing anything similar on a recent -STABLE or have any ideas on how to debug this? Regards, AS msg51197/pgp0.pgp Description: PGP signature
Re: SCSI emulation help and patching
> Le 2002-10-31, Andy Sparrow écrivait : > > > Yup, that's probably it. I just (re)patched my src tree after a fresh > > cvsup, and this file fails to patch with atapicam-STABLE-config-20020820. > > diff. Here's sys/conf/files.rej: > > A patch is not needed anymore: I have MFCd ATAPI/CAM on the RELENG_4 > branch a few minutes ago. Woo-Hoo! Thanks Thomas!! Cheers, AS msg50985/pgp0.pgp Description: PGP signature
Re: Possible trojan since upgrade
> On Sat, 28 Sep 2002, MikeM wrote: > > > Do you mean the MX with the higher number, rather than lower number? > > For my domain, my backup MX is priority 100, my main MX is priority 0. > > Or do I have these critters set up backwards? Nope, you're good. BTW, I seem to recall that the Cricket Liu DNS book (might be the Sendmail "Bat" book though) still advises not using an MX value of 0 for the primary, due to some (unspecified, IIRC), broken MTAs. Never seen it cause a problem myself though... > Yep--Andy means the lower priority MX host, which is the higher numbered. Heh, my original post was rather confusing. Thanks, that was exactly what I meant. > I hadn't given much thought to it, but his message makes a lot of sense. > Personally, I can think of three clients off the top of my head who don't > bother to pay much attention to backup MX hosts, but who think it's > critically important to secure they're primary. Well, there's ratware that'll hit those backup MX hosts first, usually just the highest-numbered, IIRC. Probably won't be much of an issue while there's still N zillion unsecured proxies in the world on broadband connections, or telcos with unresponsive abuse desks hosting spammers in emerging countries. Jeez, I can't even /read/ >75% of the spam I get these days, and a lot of the English slime I get is actually hosted overseas... Cheers, AS msg49995/pgp0.pgp Description: PGP signature
Re: Cursor (trackpoint) "creep" with moused?
> Toshiba trackpoints will ocasionally recalibrate themselves, which > manifests as about 5 seconds of creep - longer if you try and fight it :). Exactly - this in fact, was what I was doing, which I've only realised since I understood the underlying mechanism. As soon as I noticed the creep, I'd both become acutely aware of it, and try to compensate for it - which made it persist. When I first saw this, I thought that the trackpoint hadn't correctly returned to a neutral position, so I'd try to provide input and hope that it would, in fact, center itself (and at least I'd keep the mouse near where I wanted it to be). I seem to have never lost this habit - which is, of course, precisely what you /shouldn't/ do, if the hardware is to compensate for some bias. Now, in fact, I'm having fun with it. I can provoke it at will by gently applying pressure in a single direction. After a few seconds, it "notices" that there's an inbuilt bias, and the creep will stop - at which point, releasing the pressure gives a creep in the opposite direction, which similarly lasts for a few seconds before it corrects again. > At least on toshiba my porteget 300CT and 320CT laptops lthis is so, and I > hear from many other toshiba users that this is 'normal'. > > As for minutes of creep (the original poster mentioned it fixing itself > after 45 seconds...) Heh. This would appear to be some kind of time dilation effect due to irritation. It certainly doesn't take that long now... Thanks all! AS msg49235/pgp0.pgp Description: PGP signature
Re: Problems with mount_smbfs
Much as I hate to reply to my own post, leaving *only* NETSMB commented out in the kernel config fixes the panic, and although there's still some strangeness with loading smbfs, it seems to load on the second try: tureg# kldstat Id Refs AddressSize Name 1 14 0xc010 2fd818 kernel 21 0xc03fe000 8cb0 snd_maestro3.ko 31 0xc0407000 1880csnd_pcm.ko 41 0xc1d34000 7000 linprocfs.ko 51 0xc1dc4000 2000 blank_saver.ko 63 0xc1dca000 14000linux.ko 71 0xc1e4a000 7d000ltmdm.ko 81 0xc1ed6000 2000 rtc.ko 91 0xc1ee1000 9000 vmmon_up.ko 101 0xc1eed000 4000 if_tap.ko 114 0xc1ef4000 9000 netgraph.ko 121 0xc1f03000 3000 ng_ether.ko 131 0xc1f07000 4000 ng_bridge.ko 141 0xc1f0e000 3000 ng_socket.ko tureg# kldload smbfs module_register: module iconv already exists! linker_file_sysinit "libiconv.ko" failed to register! 17 kldload: can't load smbfs: Exec format error tureg# kldload smbfs netsmb_dev: loaded tureg# andy@tureg[52]-> kldstat Id Refs AddressSize Name 1 17 0xc010 2fd818 kernel 21 0xc03fe000 8cb0 snd_maestro3.ko 31 0xc0407000 1880csnd_pcm.ko 41 0xc1d34000 7000 linprocfs.ko 51 0xc1dc4000 2000 blank_saver.ko 63 0xc1dca000 14000linux.ko 71 0xc1e4a000 7d000ltmdm.ko 81 0xc1ed6000 2000 rtc.ko 91 0xc1ee1000 9000 vmmon_up.ko 101 0xc1eed000 4000 if_tap.ko 114 0xc1ef4000 9000 netgraph.ko 121 0xc1f03000 3000 ng_ether.ko 131 0xc1f07000 4000 ng_bridge.ko 141 0xc1f0e000 3000 ng_socket.ko 162 0xc1f6 3000 libiconv.ko 171 0xc1f64000 1c000smbfs.ko 181 0xc1f44000 3000 libmchain.ko Uhh, is this right? Regards, AS msg48156/pgp0.pgp Description: PGP signature
Problems with mount_smbfs
Hi, I've been getting the following for the last few weeks in -STABLE when trying to mount a SMB share; the first attempt gives: bash-2.05a# mount_smbfs -I server -W //user@server/share /mnt mount_smbfs: vfsload(smbfs): Exec format error kldstat shows: bash-2.05a# kldstat Id Refs AddressSize Name 1 15 0xc010 307e54 kernel 21 0xc0408000 8cb0 snd_maestro3.ko 31 0xc0411000 1880csnd_pcm.ko 41 0xc1d34000 7000 linprocfs.ko 51 0xc1dc4000 2000 blank_saver.ko 63 0xc1dc6000 14000linux.ko 71 0xc1e4a000 7d000ltmdm.ko 81 0xc1ed6000 2000 rtc.ko 91 0xc1ee1000 9000 vmmon_up.ko 101 0xc1eec000 4000 if_tap.ko 114 0xc1ef3000 9000 netgraph.ko 121 0xc1f0 3000 ng_ether.ko 131 0xc1f05000 4000 ng_bridge.ko 141 0xc1f0c000 3000 ng_socket.ko 161 0xc2a37000 3000 libiconv.ko and I get this on the console: module_register: module iconv already exists! linker_file_sysinit "libiconv.ko" failed to register! 17 Trying again, the message is different, I get module_register: module dev_netsmb already exists! linker_file_sysinit "smbfs.ko" failed to register! 17 on the console, and kldstat shows: bash-2.05a# kldstat Id Refs AddressSize Name 1 17 0xc010 307e54 kernel 21 0xc0408000 8cb0 snd_maestro3.ko 31 0xc0411000 1880csnd_pcm.ko 41 0xc1d34000 7000 linprocfs.ko 51 0xc1dc4000 2000 blank_saver.ko 63 0xc1dc6000 14000linux.ko 71 0xc1e4a000 7d000ltmdm.ko 81 0xc1ed6000 2000 rtc.ko 91 0xc1ee1000 9000 vmmon_up.ko 101 0xc1eec000 4000 if_tap.ko 114 0xc1ef3000 9000 netgraph.ko 121 0xc1f0 3000 ng_ether.ko 131 0xc1f05000 4000 ng_bridge.ko 141 0xc1f0c000 3000 ng_socket.ko 162 0xc2a37000 3000 libiconv.ko 171 0xc2a1d000 1a000smbfs.ko 181 0xc2a3a000 3000 libmchain.ko Errr. This used to work, as recently as about ~4-5 weeks ago, but has been failing for a few weeks now. Kernel config included: options NETSMB #SMB/CIFS requester options NETSMBCRYPTO#encrypted password support for SMB options LIBMCHAIN #mbuf management library options LIBICONV so I'm really stumped as to why the kernel is even trying to load the modules (which are up-to-date with the kernel & userland, on a cvsup from last night, 29th July, BTW). libiconv was portupgraded, and made no difference to the symptoms. I read the archives, and this seemed to be a problem circa 4.5-RELEASE, someone at that time suggested that not statically compiling NETSMB into the kernel helped. I left only NETSMBCRYPTO in the kernel (as the other 3 have KLMs), and got this entirely repeatable crash-on-boot (pardon typing): Booting [kernel]... Copyright (c) 1992-2002 The FreeBSD Project Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer= 0x8:0xc0183f09 stack pointer = 0x10:0xc0440fb4 frame pointer = 0x10:0xc0440fc0 code segment = bane 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 Current process= Idle kernel: type 12 trap, code = 0 Stopped at0xc0183f09: movl 0(%esi),%ebx db> trace (null)(0) at 0xc0183f09 (null)(c035ec84,c0440ff8,c0128ed0) at 0xc0188444d (null)(0,0,0,0,0) at 0xc016f200 (null)() at 0xc0128ed0 Loading the modules into the kernel from the loader gives precisely the same results, e.g. no boot with that kernel. Anyone got any suggestions? Regards, AS msg48155/pgp0.pgp Description: PGP signature
Re: Changes to tar (was Re: strange SSH / tar problem)
Hey Mike, Just as a POI, I think you'd get better results with 'rsync' for this application (from the people that brought you Samba, readily available via ports) - it'll do intelligent copying, when archiving can maintain a directory of the previous versions for files that change, uses SSH as the transport, can be bandwith-limited and will compress the stream in-line. Course, it'd still be good to fix any tar issues :) Cheers, AS > Actually, someone pointed out this is a tar problem. I forgot that > RELENG_4 has a whole new version of tar. tar (GNU tar) 1.13.25 vs 1.11.2. > > Old version of tar both forms work fine. > granite# tar -czf t.tgz /tmp/root > granite# tar -czf - /tmp/root > t2.tgz > granite# tar -tzf t2.tgz > root/ > root/ps.out > root/m.sort > root/q.out > root/nestat.out > root/m.list > root/s.dead > root/s1 > root/s2 > root/exp.list > root/dead.txt > root/dsl.out > root/code-red.txt > root/mail.access.times > root/own.txt > root/ms.rot > root/dead.sort > root/files.txt > root/mail.list > root/f.out > root/m.dort > root/du.out > root/list.txt > root/list.txt2 > root/dead.list > root/deadmail/ > granite# ls -l *.tgz > -rw-r--r-- 1 root wheel 1424563 Jul 27 09:44 t.tgz > -rw-r--r-- 1 root wheel 1424563 Jul 27 09:45 t2.tgz > granite# > > new version of tar > > > news% tar -czf - test-files > t2.tgz > news% tar -czf t.tgz test-files > news% tar -tzf t2.tgz > test-files/ > test-files/ps.out > test-files/netstat.out > test-files/mount.out > test-files/ipfw.out > test-files/if.out > test-files/t.zip > > gzip: stdin: decompression OK, trailing garbage ignored > tar: Child returned status 2 > tar: Error exit delayed from previous errors > news% ls -l *.tgz > -rw-r--r-- 1 mdtancsa wheel 4320 Jul 27 09:46 t.tgz > -rw-r--r-- 1 mdtancsa wheel 10240 Jul 27 09:46 t2.tgz > news% > > At 04:13 PM 7/26/2002 -0400, Mike Tancsa wrote: > > >On a number of my servers I use tar via ssh to do frequent backups of > >files to a central backup server. The backup server is running an older > >ssh, but the same problem happens with the most recent versions. > > > >SSH-1.99-OpenSSH_2.9 FreeBSD localisations 20020307 > > > >If I do a tar over ssh the resulting file has an error at the end. > > > >e.g. source is running SSH-1.99-OpenSSH_3.4p1 FreeBSD-20020702 > >destination (20020307) > >tar -cpzf - /etc /usr/local/etc | /usr/bin/ssh > >[EMAIL PROTECTED] "cat - > > >/path-to-files/userid/backup.`date "+%y%m%d"`.tgz" > > > > > >When I go to test the file, I get > > > >tar -tzf backup.020726.tgz > > > >usr/local/etc/apache.bak/httpd.conf.default > > > >gzip: stdin: decompression OK, trailing garbage ignored > >usr/local/etc/apache.bak/access.conf.default > >usr/local/etc/apache.bak/access.conf > >tar: child returned status 2 > > > >It seems to work OK, but I was a bit surprised about the warning message > > > > From the source server > >md5 * > >MD5 (t.zip) = 868cd7e432dc2ad7049a2c61a2403194 > >MD5 (t2.zip) = 90279347e332762c0fc43798b4ae4d57 > >MD5 (webalizer.conf) = dd948a77ba729a471f7ade18088b3680 > >tar -cpzf - /tmp/test-files | /usr/bin/ssh [EMAIL PROTECTED] > >"cat - > /path-to-files/userid/testb.`date "+%y%m%d"`.tgz" > > > >and the target server > > > >tar -xzf testb.020726.tgz > > > >gzip: stdin: decompression OK, trailing garbage ignored > >tar: child returned status 2 > > > >cd test-files/ > >backupserver# md5 * > >MD5 (t.zip) = 868cd7e432dc2ad7049a2c61a2403194 > >MD5 (t2.zip) = 90279347e332762c0fc43798b4ae4d57 > >MD5 (webalizer.conf) = dd948a77ba729a471f7ade18088b3680 > > > > > >The sshd_config and ssh_config on both machines are stock. If I got from a > >stable box as of today to another stable box as of today, the same error > >happens. > > > > ---Mike > > > >Mike Tancsa, tel +1 519 651 3400 > >Sentex Communications,[EMAIL PROTECTED] > >Providing Internet since 1994www.sentex.net > >Cambridge, Ontario Canada www.sentex.net/mike > > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] > >with "unsubscribe freebsd-stable" in the body of the message > > > Mike Tancsa,tel +1 519 651 3400 > Sentex Communications, [EMAIL PROTECTED] > Providing Internet since 1994www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > msg48025/pgp0.pgp Description: PGP signature
Re: Server won't boot after recompile the kernel with ipfw support
> Setting firewall_type to a file name will just ensure that no rules are > added at all, it won't match any cases in /etc/rc.firewall. Scanning rc.network quickly, it looks like you're correct for recent -STABLE. In which case the following comments in rc.firewall should be reaped, surely?: # Define the firewall type in /etc/rc.conf. Valid values are: # open - will allow anyone in # client - will try to protect just this machine # simple - will try to protect a whole network # closed - totally disables IP services except via lo0 interface # UNKNOWN - disables the loading of firewall rules. # filename - will load the rules in the given filename (full path required) # msg45894/pgp0.pgp Description: PGP signature
Re: crashes on 4.5-RELEASE
> FYI, this machine is an HP Omnibook 6000. It has the "xl" ethernet > built in and this is the interface I'm using. I've had one of these for over a year, and I use the network & NFS fairly heavily. It's very stable for me (only remaining niggles on this platform for me were sound and xl0 post-resume - but these were completely addressed for me by a couple of commits just pre-4.5-RELEASE). > I do have soft updates turned on on the single / filesystem on this > box. Should I turn them off? They don't cause me any problems (in fact quite the opposite, I think), I've been running them for quite some time. Never caused a single funny for me.. > I would be happy to supply my kernel config file to anyone interested. I'd be happy to provide you with mine, this might be quicker :) > P.S. I also have the problem with these Omnibooks that if you tell them > to "reboot" (or "halt" followed by pressing any key to reboot), they > hang in a weird kind of half power on state. The display goes black > (the backlight turns off), but if you shine a flashlight on the LCD, > you can still see text there. The Power light on the front does not > turn off, and the machine still generates plenty of heat, but the cpu > cooling fan will not turn itself on. Any suggestions for that? Ahh yes, everything in this area used to work fine (including 'shutdown -p'), but broke after Warner made the PCI-routing changes for PCCARD. He can reproduce it with his hardware, and it's not a real big thing anyway (plus he's doing some good work *waves*, don't wanna distract him with trifles).. Just 'halt' the machine, and use the little power key in the top-left corner when it says to "Press Any Key". It'll startup clean. Cheers, AS msg41843/pgp0.pgp Description: PGP signature
Re: Is vmnet broken in 4.5?
Hey Eugene, With the exception that I *can* ping the vmnet1 interface but the ICMP echo replies from FreeBSD never make it back to the VMware hosted OS, and neither side can get the ARP address of the other, I see very much the same symptoms as you. I'm running 4.4-STABLE RC2 (I'm waiting for XFree86-4.2.0 to make it back into ports before I update again, as this version works for me). All my ports and everything in the OS are at the same level (buildworld, buildkernel, portupgrade etc). Everything's working great AFAICS, with the minor exception of this. Cheers, AS > Hi. > > My vmware2 use netgraph bridge to access the network. Under 4.4 all work > fine. But after upgrade to 4.5 I got some trouble. I can't see my FBSD box > under vmware, but all other boxes in network work fine. I can't ping from > FBSD box to vmnet1 address. > > It seems, vmware guest OS can't get arp address of FBSD. > > + > xl0 > 172.17.1.206/16 <--> 172.17/16 (DHCP server, Internet, etc) > | > FBSD 4.5| > ++ > vmnet1 > 172.17.240.241/16 <--> 172.17.5.121/16 (vmware2, win98se) | > -+ > > Some usefull info: > > Win98SE (guest OS) use DHCP server for assigning IP address, DNSes & > default gateway. > > - > box$ ping 172.17.1.206 > PING 172.17.1.206 (172.17.1.206): 56 data bytes > 64 bytes from 172.17.1.206: icmp_seq=0 ttl=64 time=0.162 ms > > - > box$ ping 172.17.240.241 > PING 172.17.240.241 (172.17.240.241): 56 data bytes > ping: sendto: Host is down > > and in the same time we can see next > > box# tcpdump -i xl0 host 172.17.240.241 > tcpdump: listening on xl0 > arp who-has 172.17.240.241 tell 172.17.1.206 > arp who-has 172.17.240.241 tell 172.17.1.206 > . > > - > c:\Program files\FAR> ping 172.17.1.206 > pinging 172.17.1.206 > timeout > ... > timeout > > and in the same time > > box# tcpdump -i vmnet1 host 172.17.5.121 > tcpdump: listening on vmnet1 > 172.17.1.206 > 172.17.5.121: icmp: echo reply > 172.17.1.206 > 172.17.5.121: icmp: echo request > 172.17.1.206 > 172.17.5.121: icmp: echo request > 172.17.1.206 > 172.17.5.121: icmp: echo request > 172.17.1.206 > 172.17.5.121: icmp: echo request > 172.17.1.206 > 172.17.5.121: icmp: echo request > 172.17.1.206 > 172.17.5.121: icmp: echo request > 172.17.5.121 > 172.17.1.206: icmp: echo request > 172.17.1.206 > 172.17.5.121: icmp: echo reply > > > > c:\Program files\FAR> ping 172.17.0.1 > > answer, size=32 bytes, time=21ms, TTL=64 > . > > c:\Program files\FAR> ping www.mtu.ru > > pinging 195.34.32.10 > answer, size=32 bytes, time=157ms, TTL=248 > . > > > > box# uname -a > FreeBSD badger.imedia.ru 4.5-RELEASE FreeBSD 4.5-RELEASE #29: Tue Feb 5 > 11:00:19 MSK 2002 > [EMAIL PROTECTED]:/var/devel/CVSUP/src/sys/compile/BADGER i386 > > box# kldstat > Id Refs AddressSize Name > 1 15 0xc010 2873d0 kernel > 21 0xc0388000 542c snd_es137x.ko > 31 0xc038e000 157b4snd_pcm.ko > 41 0xc0f92000 c3000vinum.ko > 51 0xc1088000 7000 linprocfs.ko > 61 0xc1112000 2000 green_saver.ko > 73 0xc11c 15000linux.ko > 81 0xc1115000 2000 rtc.ko > 101 0xc12b6000 4000 if_tap.ko > 121 0xc13d2000 3000 ng_socket.ko > 133 0xc13d8000 9000 netgraph.ko > 151 0xc13e1000 3000 ng_ether.ko > 161 0xc13e4000 4000 ng_bridge.ko > 171 0xc12aa000 9000 vmmon_up.ko > 181 0xc17de000 8000 cd9660.ko > > box# ifconfig -a > xl0: flags=8943 mtu 1500 > options=3 > inet 172.17.1.206 netmask 0x broadcast 172.17.255.255 > atalk 228.127 range 220-230 phase 2 broadcast 0.255 > ether 00:50:da:cd:b2:0e > media: Ethernet autoselect (100baseTX ) > status: active > lp0: flags=8810 mtu 1500 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff00 > atalk 0.0 range 0-0 phase 2 > vmnet1: flags=8843 mtu 1500 > inet 172.17.240.241 netmask 0x broadcast 172.17.255.255 > ether 00:bd:e7:14:00:01 > Opened by PID 41162 > > box# netstat -nr -f inet > Routing tables > > Internet: > DestinationGatewayFlagsRefs Use Netif Expire > default172.17.0.1 UGSc 34 75xl0 > 127.0.0.1 127.0.0.1 UH 3 102683lo0 > 172.17 link#1 UC 110xl0 > 172.17.0.1 0:d0:b7:a9:f:f9UHLW 38 5864104xl0 1193 > 172.17.1.206 0:50:da:cd:b2:eUHLW2 1114lo0 > 172.17.5.121 0:bd:e7:da:d5:31 UHLW1 1336xl0762 > 172.17.120.66 link#1 UHLW1 49xl0 > 172.17.124.5 0:50:8b:69:c3:d5 UHLW0 714xl0 1195 > 172.17.124.209 0:d0:b7:a9:37:c8 UHLW15
Re: Partnership Proposal
> You know, I tried to forward this to the FBI, but apparently the hojillions > in tax $$ we give the US government every year isn't enough to allow > the FBI to have a mail server that actually works. Yeah, and the US Secret Service's web site on the topic has borken Java$cript that doesn't work correctly with Linux Netscrape. *sigh* Anyway, the correct address to complain about 4-1-9 scams is actually: [EMAIL PROTECTED] I note that this apparently originated from a NYC IP address rather than the more usual Nigerian Internet Cafe, so you might get more activity from this report than is normal :) Enjoy. AS msg41592/pgp0.pgp Description: PGP signature
Re: [wm-user] wdm
>
> Has anyone been able to get wdm-120 working with FreeBSD 4.5-STABLE
> and windowmaker-0.80.0?
Yes, using it right now:
andy@omni[191]-> pkg_info | grep wdm
wdm-1.20WINGs Display Manager; an xdm replacement
andy@omni[192]-> pkg_info | grep windowmaker
windowmaker-0.80.0 GNUStep-compliant NeXTStep window manager clone
andy@omni[193]-> uname -a
FreeBSD omni.geek4food.org 4.5-RC FreeBSD 4.5-RC #75: Sun Jan 20 01:49:17 PST
2002 [EMAIL PROTECTED]:/usr/src/sys/compile/tureg i386
> One thing I found was that wdm-1.20 was being linked against
> libPropList. I removed that as from what I see it only needs
> to be linked against libWINGS. That removed this error message
> in the xdm-error.log:
>
> wdmLogin error: could not open domain file /root/GNUstep/Defaults/wdmLogin
> for reading: no such file or directory
>
> I am still getting:
>
> Caught signal 11.
>
> Server aborting
>
> I slo get this message on the console:
>
> sigreturn: eflags = 0x13207
Ahhh. Now I've seen this (or something very similar, couldn't swear to the
exact hex sigreturn) a couple of times myself, and I never found out quite
what caused it.
Searching the FreeBSD archives never turned up anything (which is why I just
cross-posted the reply, in case someone else goes looking).
However, I did find out that it was basically caused by something in the
system being out-of-date. Which, as I cvsup all the time and don't necessarily
re-build the ports, isn't too surprising...
In one instance, rebuilding WindowMaker, WDM & all the ports that it depended
on sorted it out. Another time, I had to completely rebuild *all* the ports
(doing the above plus X and a whole bunch of other stuff didn't sort it out,
so I did a pkg_delete `pkg_info | awk '{print $1}'` and started again).
I can only assume that something was stale in the system, and this was causing
the problem.
> Any help would be greatly appreciated.
Vance, 'portupgrade' is your friend, if you've not looked at it, I can
heartily recommend it. It rocks.
My advice would be to pick a good moment to CVSup the complete source tree,
ports and all, go through the regular 'buildworld', 'buildkernel',
'mergemaster' cycle, and, having freshly rebooted into a good, clean, running
system, install 'portupgrade' if you don't have it already, fix up your ports
database and rebuild the whole lot.
At the end, the whole system will be squeaky clean, and every single port on
the system will be rebuilt with the new binaries, libraries, updated to the
latest versions etc. All that remains would be to rebuild any ports you happen
to prefer to build with custom options, and you're all done.
Works for me, every time.
HTH.
Cheers,
AS
msg41096/pgp0.pgp
Description: PGP signature
Re: xl0 tx underrun / watchdog errors
> On Sat, 22 Sep 2001, Lamont Granquist wrote: > > > > > > > So you're suggesting its just this? > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=11869 > > Yes, that looks exactly like the problem I had. The network would just > stop working when copying files to and fro another host. Didn't see the > patch though, so I ended up putting an Intel EEPRO in the box instead. Didn't even know that this fix existed. Incrementing to 300 seems to fix my problems completely (integrated NIC in HP Omnibook 6000). Can we get this MFC'd? Looks like it's been in -CURRENT for over two years now... Cheers, AS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: mkisofs not in 4.4-RELEASE
> > mkisofs was not included in the 4.4-R version > of cdrtools, and is not otherwise on the base > installation CD. Is it on one of the other > CDs? Is it in -STABLE? cdrtools is much less > useful without it. It's not in the base -STABLE, but it's in /usr/ports/sysutils. Cheers, AS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
