Re: Lucent Orinoco Gold PCCard?
On Fri, Dec 08, 2000 at 11:23:00PM -0700, Wes Peters wrote: I am told that the Apple "AirPort Base Station", which is $399, works well and can be configured with the Java-based thing in the ports collection. I am further told that the Lucent/ORiNOCO RG-1000 base station is virtually identical, although more expensive and somehow inferior, although I don't understand the exact inferiorities. They're the same thing in different cases, it's hard to see how one can be superior in any way other than price. "The most stupid thing was that you couldn't set its network name to anything other than its serial number because on bootup, it copies its serial number over the first five bytes of the network name. It also can't be fully configured without the Windows software -- which is a bit misleading for me to say because even with the Windows software, you can only set it up to use the modem or provide NAT routing via Ethernet, and not set it up to do bridging." I am thinking of getting one of these things, despite my strong desire to avoid owning such a stupid looking piece of hardware. Wait for the LinkSys; the dual antennas and price differential will be worth the wait. If the plethora of 802.11b equipment at BSDCon 2k is any indication, interoperability should be pretty good. But will I be able to configure the LinkSys? That's my primary concern. I only have FreeBSD, so if it requires any proprietary software at all, I can't use it. Besides that, I'll only be using this 10 feet away from the base. :-) -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
On Wed, Dec 06, 2000 at 07:23:40PM -0800, Charlie Root wrote: There is definately a trend to lower prices. I just found this. A new intel Intel PRO/Wireless 2011 LAN access point and two pcmcia cards for $699. The access point sounds interesting. I personally would like to use it as a repeater and network bridge. I am told that the Apple "AirPort Base Station", which is $399, works well and can be configured with the Java-based thing in the ports collection. I am further told that the Lucent/ORiNOCO RG-1000 base station is virtually identical, although more expensive and somehow inferior, although I don't understand the exact inferiorities. I am thinking of getting one of these things, despite my strong desire to avoid owning such a stupid looking piece of hardware. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new rc.network6 and rc.firewall6
The solution is very simple. Put a statically linked Perl in /sbin, and write the startup system in Perl. For user convenience, it should have a Gnome interface and a PostgreSQL backend, so we should also put X and pgsql in /sbin. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 10:50:11PM -0500, Mike Meyer wrote: Christopher Masto writes: I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. As cdrecord isn't part of FreeBSD, this is clearly the wrong place to ask about that. Joe Schilling watches [EMAIL PROTECTED], and that's the place to ask. I've been told that ATAPI CD-Rs use the same basic command set (MMC) as SCSI ones, only they don't have legacy problems - so it should be possible. Actually, that's why this would be the appropriate place. cdrecord is designed to do that sort of thing - it separates out the driver interface and has several already, including support for Linux's "ATAPI over SCSI". It just doesn't work with FreeBSD because our ATAPI driver doesn't make available the low-level communication it needs. But whatever. I've personally decided to give up on it and get a SCSI CD-R at some point. I'm just confused by the desire to avoid cdrecord, since in my experience, it has worked great. It also has a lot of nifty options. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for review (LPDEST vs PRINTER)
On Wed, Aug 02, 2000 at 09:35:23PM -0400, Garance A Drosihn wrote: The other printing-system alternative is LPRng (which people can install from ports). LPRng does add the 'lpstat' command, in addition to replacing lpr/lpq/lprm. And if I am reading this code right, it does check LPDEST for all of those commands, *-but-* it has PRINTER taking precedence over LPDEST, and not the way POSIX (apparently) describes it. From testing, it appears that you are reading the code correctly. The documentation for LPRng, however, indicates for the SysV commands that LPDEST takes precedence. It's probably just an oversight. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for comments: new `lpd' suite feature
On Sun, Jul 16, 2000 at 08:15:05PM -0400, Garrett Wollman wrote: On Sun, 16 Jul 2000 16:46:58 -0400, Christopher Masto [EMAIL PROTECTED] said: Huh? Security through ignorance? Remember that `lpr' is setuid-root and uses a ``privileged'' port for its communications. Many sites may still be using trusted-host ``authentication'' internally, and LPRng's ``feature'' may enable a compromise of some such service. (Got enough scare quotes there?) That is indeed something I failed to consider. I suppose it would be necessary to have some control over that feature in some environments. I just find it incredibly convenient to be able to install LPRng on a bunch of client machines and just rm /etc/printcap, set $PRINTER, and be done with it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Gnome INSANE shared memory usage
m 262190 0 --rwarwarwa rootchris 2 32768586324 m 196655 0 --rwarwarwachrischris 2 32768567324 m 262192 0 --rwarwarwa rootchris 2 32768586324 m 262193 0 --rwarwarwa rootchris 2 32768586324 m 196658 0 --rwarwarwachrischris 2 32768567324 m 262195 0 --rwarwarwa rootchris 2 32768586324 m 196660 0 --rwarwarwachrischris 2 32768567324 m 262197 0 --rwarwarwa rootchris 2 32768586324 m 196662 0 --rwarwarwachrischris 2 32768567324 m 196663 0 --rw-r--r-- rootwheel 5 4096324400 m 131128 0 --rwarwarwachrischris 2 32768565324 m 196665 0 --rwarwarwachrischris 2 32768565324 m 131130 0 --rwarwarwachrischris 2 32768565324 m 131131 0 --rwarwarwachrischris 2 32768565324 m 131132 0 --rwarwarwachrischris 2 32768567324 m 131133 0 --rwarwarwachrischris 2 32768565324 m 131134 0 --rwarwarwachrischris 2 32768565324 m 196671 0 --rw-r--r-- rootwheel 2 4096324586 m 196672 0 --rw-r--r-- rootwheel 2 4096324586 m 196673 0 --rw-r--r-- rootwheel 2 4096324599 m 196674 0 --rw-r--r-- rootwheel 2 4096324599 m 196675 0 --rw-r--r-- rootwheel 3 4096324599 m 196676 0 --rw-r--r-- rootwheel 2 4096324599 m 196677 0 --rwarwarwa rootchris 2 32768586324 m 65606 0 --rw-r--r-- rootwheel 2 4096324599 m 65607 0 --rw-r--r-- rootwheel 2 4096324599 m 65608 0 --rw-r--r-- rootwheel 2 4096324599 m 65609 0 --rw-r--r-- rootwheel 2 4096324599 m 65610 0 --rw-r--r-- rootwheel 2 4096324599 m 65611 0 --rw-r--r-- rootwheel 2 4096324599 m 65612 0 --rw-r--r-- rootwheel 2 4096324599 m 65613 0 --rw-r--r-- rootwheel 2 4096324599 m 65614 0 --rw-r--r-- rootwheel 2 4096324599 m 65615 0 --rw-r--r-- rootwheel 2 4096324599 m 65616 0 --rw-r--r-- rootwheel 2 4096324599 m 65617 0 --rw-r--r-- rootwheel 2 4096324599 m 65618 0 --rw-r--r-- rootwheel 2 4096324599 m 65619 0 --rw-r--r-- rootwheel 2 4096324599 m 65620 0 --rw-r--r-- rootwheel 2 4096324599 m 65621 0 --rw-r--r-- rootwheel 2 4096324599 m 65622 0 --rw-r--r-- rootwheel 2 4096324599 m 65623 0 --rw-r--r-- rootwheel 2 4096324599 m 65624 0 --rw-r--r-- rootwheel 2 4096324599 m 65625 0 --rw-r--r-- rootwheel 2 4096324599 m 65626 0 --rw-r--r-- rootwheel 2 4096324599 m 852059 0 --rwarwarwachrischris 2 32768 5409324 m 720988 0 --rwarwarwachrischris 2 32768 5409324 m 458845 0 --rwarwarwachrischris 2 32768 5409324 m 196702 0 --rw-r--r-- rootwheel 2 4096324599 m 65631 0 --rwarwarwachrischris 2 32768 5409324 m 65632 0 --rw-r--r-- rootwheel 2 4096324 5409 These are the processes mentioned there: 324 ?? Ss 9:21.71 /usr/X11R6/bin/X -dpi 128 -auth /usr/X11R6/lib/X11/wd 400 ?? Is 0:10.15 gmc --sm-config-prefix /gmc-Vex391/ --sm-client-id 11 402 ?? Ss 1:12.42 panel --sm-config-prefix /panel.d/default-aIQ389/ --s 408 ?? Is 0:03.04 deskguide_applet --activate-goad-server deskguide_app 410 ?? Is 0:02.57 tasklist_applet --activate-goad-server tasklist_apple 412 ?? Is 0:01.08 gweather --activate-goad-server gweather --goad-fd 12 548 p2- I 0:00.34 gnome-session --sm-disable --sm-config-prefix=/Left/ 563 ?? Ss 0:07.12 sawfish --sm-client-id 11d13615c7961030077000 565 ?? Is 0:06.03 gmc --sm-config-prefix /gmc-Vex391/ --sm-client-id 11 567 ?? Ss 0:03.96 panel --sm-config-prefix /panel.d/default-aIQ389/ --s 586 ?? Ss29:37.62 gkrellm 599 ?? Is 2:28.99 netscape 5409 ?? S 0:00.94 xchat 12638 ?? I 0:00.15 rxvt -- Christopher Masto Senior Network M
Re: Gnome INSANE shared memory usage
On Fri, Jun 23, 2000 at 08:22:00PM +0300, Maxim Sobolev wrote: Hmm, where my crystal ball... Aha, I see - probably you are using Xfree 4.0, while your friend Xfree3.5*. It is where the problem lie (see below). That is correct. "It has noting to do with kernel/gnome. XFree 4.0 is known to be very hungry for the shared memory, so you should increase SHMSEG parameter in your kernel config file. There are no guidelines as to what exact number will be sufficient, so you should define it in experimental way. I personally set it to 100 (options SHMSEG=100) and do not see any warnings anymore." Unfortunately, these are my current settings: options SHMALL=1025 options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" options SHMMAXPGS=1025 options SHMMIN=2 options SHMMNI=256 options SHMSEG=128 I can increase it more, but I think this is quite a ridiculous amount of shared memory to be using. Something must be wrong. I am now searching for a way to disable the MIT-SHM extension in the X server, but I think I may have to recompile. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome INSANE shared memory usage
On Fri, Jun 23, 2000 at 02:30:42PM -0400, Shawn Halpenny wrote: I have not had any of the problems he's describing. I have never modified my shared memory settings in my kernel config either. If the problem is indeed Xfree 4.0, then I guess it must be a driver issue (I'm using the neomagic driver). I think you may have a point there. While trying to find out whether XFree86 had an option to disable the MIT-SHM extension (it doesn't as far as I could tell - I ended up editing the binary and NOPping it out) I noticed that some of the code seems to be in the hardware driver area. I'm using a dual-headed configuration with a Voodoo 3 and a Number Nine (S3 ViRGE VX). -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome INSANE shared memory usage
On Sat, Jun 24, 2000 at 12:29:56AM +0200, Alexander Sanda wrote: BTW: It's for sure _not_ a -current issue and might have nothing to do with FreeBSD at all, since I'am running 4.0-STABLE on this machine, with Xfree 4.0 and Gnome 1.2. Which video card/driver are you using? (Mine is tdfx and s3virge) -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
On Fri, Jun 09, 2000 at 01:14:35PM -0400, Jeroen C. van Gelderen wrote: I'm not sure it is a good idea to name this variable VMWare as that is implementation specific. It may be better to have a var named 'emulation' set to 'none' or 'vmware' or 'bochs' or ... Mmm.. or, giving forth the ability to do in/out instructions, so the non-generic code would be entirely in the add-on forth piece. I'm not sure if there are any security implications there.. at boot time the machine is essentially as single-user as it's ever going to be. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMware detection code in boot loader
extern void ficlOutb(FICL_VM *pVM); extern void ficlInb(FICL_VM *pVM); I'm an idiot. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB/Orb/kue/iopener/filesystem corruption
For those following along, it's definately kue-related. On Tue, Apr 04, 2000 at 06:40:22PM -0400, Christopher Masto wrote: Next time I get a chance, I'll try: Filesystem-intensive activity without using kue at all, then a reboot and fsck. Tested, absolutely no problems. In fact, I'm writing this from the i-opener (running ppp). Loading kue as a module. Same disaster. Instant filesystem damage if I use the maching at all with kue up. Simulating the i-opener situation with my laptop. Haven't tried yet.. it's nearly 4AM. Getting more details on the kernel panic. Haven't managed a panic this time around. I'm still stumped as to what exactly is going on.. whether kue is corrupting random memory, or umass's buffers.. I may just try to find an aue-based adapter to try. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USB/Orb/kue/iopener/filesystem corruption
On Mon, Apr 03, 2000 at 01:27:25PM -0400, Christopher Masto wrote: Regarding USB drives, I have been using the Orb "2.2GB" USB-SCSI version with some success. There do seem to be some serious filesystem corruption problems, but I haven't had time to determine where they're coming from. I often get corruption-related panics while trying to install packages, and fsck always finds a number of serious problems and removes about a dozen files (from /usr/lib mostly, so I'll eventually lose something important). When I download something large, such as XFree86, the file's checksum comes out wrong and gzip fails with errors. I tried this again last night. I bought some new cartridges for the Orb drive, and installed -current on one, built a kernel, and installed quite a few packages by chrooting to it and pkg_adding them. Big things, like XFree86. I then built a kernel and booted it on my laptop, using the Orb as a root filesystem. Everything seemed to go well, and fsck found no errors. I then took it home and did the same thing on my i-opener. It seemed to work well, and I spent quite a bit of time trying to get X configured properly (at which I didn't quite succeed, but that's another story). After a couple of hours, I plugged in a D-Link 650 (kue) ethernet, and ssh'd to another machine, on which I started to FTP a few things. After a couple of minutes, I got "kue0: watchdog timeout" and seemed to stop transmitting packets. I unplugged the kue, plugged it back in, and got a panic (unfortunately I don't have the details at the moment.. I'll try to record them tonight). Upon rebooting, the filesystem was corrupted. I brought it back today to the same machine that I installed everything from yesterday, and confirmed it: ** /dev/da0a (NO WRITE) ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes UNKNOWN FILE TYPE I=55632 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? no UNKNOWN FILE TYPE I=16 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? no UNKNOWN FILE TYPE I=285768 UNEXPECTED SOFT UPDATE INCONSISTENCY CLEAR? no ** Phase 2 - Check Pathnames DUP/BAD I=55632 OWNER=root MODE=100644 SIZE=2623 MTIME=Nov 5 22:14 1994 FILE=/usr/local/share/bx/translation/CP437 UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? no BAD TYPE VALUE I=55632 OWNER=root MODE=100644 SIZE=2623 MTIME=Nov 5 22:14 1994 FILE=/usr/local/share/bx/translation/CP437 UNEXPECTED SOFT UPDATE INCONSISTENCY FIX? no DUP/BAD I=16 OWNER=root MODE=40755 SIZE=2560 MTIME=Apr 3 22:03 2000 DIR=/usr/share/zoneinfo/America UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? no fsck: cannot find inode 16 It happens with or without soft updates, by the way. This time I happened to have them on. I can conclude from this that it's not the drive or the media, and it doesn't appear to be the USB stack or umass driver. I think that something, when using the kue driver at the same time, is causing the damage. That's very odd, because I'm using the same D-Link ethernet adapter that I've used for months with my laptop, and didn't have any problems. The only difference may be that they're compiled in to the kernel now. Next time I get a chance, I'll try: Filesystem-intensive activity without using kue at all, then a reboot and fsck. Loading kue as a module. Simulating the i-opener situation with my laptop. Getting more details on the kernel panic. This is bizzare. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB/Orb/kue/iopener/filesystem corruption
On Wed, Apr 05, 2000 at 12:07:55AM +0100, Nick Hibma wrote: Why does this sound like the warning that is written in the manual of the Iomega Zip drive: do not connect more than one Zip drive to the same USB host data might corrupted. Or something similar... But.. but.. I only have the one drive connected. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl 5.6.0?
On Sun, Apr 02, 2000 at 05:56:22PM -0400, Chuck Robey wrote: On Sun, 2 Apr 2000, Thomas T. Veldhouse wrote: Are there any plans to merge perl-5.6.0 into current? I don't have any plans for using it currently, but I curious. Hmm. What with the nightmarish build structure of perl, I'm sure that reading this is just going to wreck Mark's day. In light of that, and in the absence of both any real software that needs the upgrade, and lack of confidence in a really squeaky new release, why don't we all grant Mark a little slack on this, at least for a while. I've been running Perl 5 since before it was included with FreeBSD, and I've never noticed anything nightmarish about the build process. I tried 5.6 a couple of days ago, and it built and tested out of the box. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl 5.6.0?
On Mon, Apr 03, 2000 at 10:52:13AM +0100, Nick Hibma wrote: Are there actually any good reasons why we _should_ upgrade in the first place? Of course. We now have an obsolete version of Perl. That should be reason enough to upgrade. 5.6 is the first major release in over a year. It has significant new syntax that I intend to start using immediately, as will much of the rest of the Perl community. "Why haven't you upgraded yet?" is a rather traditional battle cry. I don't know whey they called it 5.6.0.. I'm dropping the .0, because it seems to inspire the usual "point-oh fear". This is not a "point-oh" release in the usual sense, and waiting for 5.6.1 would be a mistake. This message should not be construed as whining and prodding our Perl maintainer. Although I haven't looked at how it's done, I'm sure that integrating Perl with FreeBSD's build process is a difficult and tedious thing, and if I wanted it that badly, I would be offering patches. This is merely a rebuttal to the silly idea that FreeBSD should stick with an obsolete version of Perl indefinately. It needs to be updated in a timely manner, which probably means any time before the next FreeBSD release. (With allowances for going into current first, etc.). -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USB Zip 250 working (was Re: umass driver)
On Sun, Mar 19, 2000 at 03:24:36PM +, Nick Hibma wrote: If anyone is using the umass driver, please send me the output of (*) dmesg | grep '^\(.hci\|usb\|umass\|da\|(da\)' \ mail -s 'Drive info' [EMAIL PROTECTED] Just wanted to point out that the USB Zip 250 is working after your recent commit to umass.c. uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xb400-0xb41f irq 9 at device 4.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 umass0: Iomega USB Zip 250, rev 1.10/1.00, addr 3 da0 at umass0 bus 0 target 0 lun 0 da0: IOMEGA ZIP 250 31.G Removable Direct Access SCSI-0 device da0: 650KB/s transfers da0: 239MB (489532 512 byte sectors: 64H 32S/T 239C) da0s1: type 0xa5, start 32, end = 489471, size 489440 : OK Having heard some vaguely encouraging things from the Linux world, though, I'm considering swapping it for an Orb 2.2GB drive. Any idea whether they're mass storage class or something proprietary? -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
On Wed, Mar 22, 2000 at 03:02:02AM +, Paul Richards wrote:
I've got a different but I think related panic.
#9 0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
busy!!!")
at ../../kern/kern_shutdown.c:552
#10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
at ../../vm/vm_page.h:346
I've been playing around with one of those iopener things and got
myself into a state I thought I could get out of with the help of a
USB Zip drive. Unfortunately, upon purchasing and connecting one,
I discovered that I can't access it without a panic, which I
point out here on the chance it's also related.
#7 0xc024ac2c in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1018879976, tf_esi = 256, tf_ebp = -919618472, tf_isp = -919618500,
tf_ebx = -1071201278, tf_edx = 0, tf_ecx = -1070746656, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1071396739, tf_cs = 8, tf_eflags = 582,
tf_esp = -1071099905, tf_ss = -1071212893}) at ../../i386/i386/trap.c:549
#8 0xc023c87d in Debugger (msg=0xc02696a3 "panic") at machine/cpufunc.h:64
#9 0xc01549e8 in panic (fmt=0xc026c402 "allocbuf: buffer too small")
at ../../kern/kern_shutdown.c:552
#10 0xc0178f5a in allocbuf (bp=0xc3452018, size=83886080) at ../../kern/vfs_bio.c:2346
#11 0xc0178f01 in geteblk (size=83886080) at ../../kern/vfs_bio.c:2315
#12 0xc025cb57 in dsinit (dev=0xc0be1e00, lp=0xc0c490f4, sspp=0xc0c490f0)
at ../../kern/subr_diskmbr.c:186
#13 0xc015eec6 in dsopen (dev=0xc0be1e00, mode=8192, flags=0, sspp=0xc0c490f0,
lp=0xc0c490f4) at ../../kern/subr_diskslice.c:683
#14 0xc015dfbf in diskopen (dev=0xc0be1e00, oflags=1, devtype=8192, p=0xc88be860)
at ../../kern/subr_disk.c:146
#15 0xc018ae65 in spec_open (ap=0xc92fbe10) at ../../miscfs/specfs/spec_vnops.c:191
#16 0xc018ad65 in spec_vnoperate (ap=0xc92fbe10)
at ../../miscfs/specfs/spec_vnops.c:117
#17 0xc01ff2e9 in ufs_vnoperatespec (ap=0xc92fbe10) at ../../ufs/ufs/ufs_vnops.c:2301
#18 0xc018595f in vn_open (ndp=0xc92fbedc, fmode=1, cmode=0) at vnode_if.h:189
#19 0xc0181951 in open (p=0xc88be860, uap=0xc92fbf80) at ../../kern/vfs_syscalls.c:994
#20 0xc024b4ce in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077937212, tf_esi = 134894800, tf_ebp = -1077937132,
tf_isp = -919617580, tf_ebx = 0, tf_edx = 8, tf_ecx = 134894828, tf_eax = 5,
tf_trapno = 12, tf_err = 2, tf_eip = 672026540, tf_cs = 31, tf_eflags = 642,
tf_esp = -1077937316, tf_ss = 47}) at ../../i386/i386/trap.c:1073
#21 0xc023cf26 in Xint0x80_syscall ()
I'm not intimately familiar with the function involved, and I'm out of
time tonight, so I'm backing up a few days to see if it goes away.
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Tue, Feb 29, 2000 at 03:57:19PM -0600, Ade Lovett wrote: On Tue, Feb 29, 2000 at 01:41:43PM -0500, Christopher Masto wrote: In any case, one major offender is imlib. Since I've recently gone Gnome, I've had to turn off imlib's "MIT-SHM shared memory" option or things would go bad after a few minutes or hours of use. Can you expand a bit on "go bad"? I have a couple of machines here running with GNOME for days on end with no shared memory problems. Title bars in sawmill suddenly turning black, GNOME pixmaps disappearing/getting corrupted, that sort of thing. I'm not seeing any leaks, though: [...] Shared Memory: T ID KEYMODE OWNERGROUP SEGSZ CPID LPID m 655362622055 --rw-r--r-- rootwheel 1048576298298 m 41615362 792064 --rw-rw-rw- adestaff 4 12549 12549 Funny, I even have the option turned off and I've still got: chris@lion-around:~$ ipcs -bpm Shared Memory: T ID KEYMODE OWNERGROUP SEGSZ CPID LPID m 655365432010 --rwa--pgsqlpgsql120204204 m 655375432001 --rw---pgsqlpgsql 1063936204204 m 655385432007 --rw---pgsqlpgsql 96424204204 m 196611 0 --rw-r--r-- rootwheel 4096837 53838 m 131076 0 --rw-r--r-- rootwheel 4096837 55434 m 3211269 0 --rwarwarwachrischris 1420800 41206 41206 m 1310726 0 --rw-r--r-- rootwheel 4096837 55429 m 1310727 0 --rwarwarwachrischris 65536934837 m 131080 0 --rw-r--r-- rootwheel 4096837926 m 131081 0 --rwarwarwachrischris 65536934837 m 131082 0 --rwarwarwachrischris 65536934837 m 196619 0 --rw-r--r-- rootwheel 4096837934 Still, it's not just me. Several friends have come to me after my recommendation that they try sawmill+GNOME with the complaint that their title bars were getting messed up, and turning of MIT-SHM solved it. One is running -current, another is running 3.4-RELEASE. And I've heard the same thing on the mailing lists. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, Mar 01, 2000 at 11:54:35AM -0500, Adam wrote:
#!/bin/sh
ipcs | sed "s/[ ][ ]*/ /g" | cut -f 2 -d" " | sed
"s/[^0-9]//g" | xargs -t -n 1 ipcrm -m
Always with the sed. ipcrm `ipcs -m | awk '$1 == "m" { print "-m " $2 }'`
anyone?
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, Mar 01, 2000 at 06:20:28PM +0100, Anton Berezin wrote: I would say that the programs you've mentioned are badly written then. It takes no more than XSync(disp,False); shmctl( shmid, IPC_RMID, 0); It takes no more than a well-designed operating system service to ensure that badly written programs don't fail to release resources when they crash. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, Mar 01, 2000 at 11:28:13AM -0800, John Polstra wrote: It takes no more than a well-designed operating system service to ensure that badly written programs don't fail to release resources when they crash. We didn't design that particular service. That's why it's called System V shared memory. I did mean to imply that it was poorly designed, but not that it was designed by FreeBSD's designers. Also, it's persistent for legitimate design reasons, just like files are. Applications need to clean up after themselves. You can have many more than 32 files. Files are (usually) well-organized and have names, so you can wipe out your web browser's cache or lock file relatively easily. Files take up a negligible fraction of the available file space. SysV shared memory is limited, unnamed, unorganized, and uses up a very scarce resource. The OS has no way of knowing whether an application wants its shared memory segments to survive after it terminates. That's unfortunate. That's one of the reasons I try to stay away from SysV IPC. I don't like to have to reboot. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Two queries [ KDE / XFree86 ]
On Tue, Feb 29, 2000 at 05:56:08PM +, Thomas Graichen wrote: one other thing: does anyone have the XFree86 pre 4.0 snapshot running with moused and SysMouse ? - it works fine for me without moused and the moues directly under X - but with moused and "SysMouse" "/dev/sysmouse" nothing happens when moving the mouse - any further XF86Config magic required for this ? - does anyone have an hint here ? (btw. - all this on a fresh 4.0-CURRENT box) This works for me with moused: Identifier "Mouse1" Driver "mouse" Option "Resolution" "100" Option "Buttons""5" Option "Protocol""Auto" Option "Device" "/dev/mouse" -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Tue, Feb 29, 2000 at 09:57:48AM +, Cliff Rowley wrote: More likely work in progress with broken gtk desktop voodoo. Dont you think that would be bit of a cooincidence? Since the messages are almost identical in nature to the ones I've been getting from other programs *not* gtk/gdk based ;) The link between them so far is shared memory... Personally, I have this extreme distaste for sysv shared memory. It is a very scarce resource that is not freed automatically, and seems to go completely against the unix model. Reminds me of having to free memory on the Amiga, and slowly running out of chip RAM. In any case, one major offender is imlib. Since I've recently gone Gnome, I've had to turn off imlib's "MIT-SHM shared memory" option or things would go bad after a few minutes or hours of use. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Tue, Feb 29, 2000 at 08:08:45PM +, Cliff Rowley wrote: It'd be nice if we had a utility that could clean out and reclaim the shared memory in 1 swoop. Then we'd be able to shut down XFree86 (and obviously any other apps using shared memory), and get on with life :) Uh.. ipcrm? The problem is that I always end up taking something out that's in use.. or intentionally left around unattached, so it just _looks_ like it's not in use. I think imlib does this as some sort of cache (ugh!). Then I experience a variety of even more annoying random behavior. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of 'device awe' ?
On Tue, Feb 22, 2000 at 04:10:02PM -0800, Andy Sparrow wrote: AFAIK, the AWE cannot work without this, and the cards PnPinfo seems to not include the other two registers - and if you don't probe them, then the 'awe' driver check doesn't see the EMU8000... Is there even a single person out there able to use the AWE device under Voxware in -current? No, but that's sort of moot as far as I'm concerned, since I also can't record sound (see "Creative SB AWE64 recording does not work" on freebsd-current). It comes out as static regardless of the input source. There are just so many things broken right now, I haven't got time to worry about not having sound recording, but it'll be sad if 4.0 is released in this state. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Wed, Feb 09, 2000 at 09:45:42PM -0500, Chuck Robey wrote: Flattening out the unecessarily deep ports directory structure would help, too. Probably, 98 percent of it could be done with a script, and it would greatly decrease cvsup time and space. I've often thought that it might be better if each port were a single tar file or something instead of the 30+ files that many of them now contain. From there, it seems like a straightforward step to not keep the tar files on your machine, much like you don't keep the distfiles. "make-port xmms" or whatever could go out and grab the xmms port tar file from ftpX.freebsd.org, extract it to the appropriate place, then do a make as usual. I haven't had time to try to implement it, though. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Creative SB AWE64 recording does not work
On Tue, Feb 01, 2000 at 09:07:49PM -0800, Brian Beattie wrote: A kernel, current, sources cvsuped today. When I try to record from line, (source does not seem to matter), I get full scale white noise. The remainder of the system is from about a week ago, I will try a buildworld/installworld later. I have the same problem with world built yesterday (same card). It's sort of a loud buzzing/hissing noise that gets recorded, regardless of the input. section from dmesg --- sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm0: SB DSP 4.16 on sbc0 unknown0: Game at port 0x200-0x207 on isa0 unknown1: WaveTable at port 0x620-0x623 on isa0 --- Here's mine: isa_probe_children: probing PnP devices sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm1: SB DSP 4.16 on sbc0 pcm: setmap 8000, 2000; 0xc807e000 - 8000 pcm: setmap a000, 2000; 0xc808 - a000 unknown0: Game at port 0x200-0x207 on isa0 unknown1: WaveTable at port 0x620-0x623 on isa0 -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Moused hanging...
On Sun, Jan 23, 2000 at 02:13:17PM -0500, Donn Miller wrote: Hi, I've noticed a strange problem with vidcontrol and moused recently with current. I also had the same problem about 3 weeks back, and it doesn't seem to be occurring all that regularly. Here's what I was doing: I had just exited out of X, XFree86 Version 3.9.17. I had two sessions of bladeenc going simultaneously (if that even matters). I'm guessing maybe the issue is with the PCI bus being accessed by moused and the ATA driver at the same time, since bladeenc does generate some disk activity. Anyway, I heard a `pop' through my speakers, and at the same time, moused went dead. I su'd to root, killed and restarted moused. I could not get my moused cursor back (tried vidcontrol -m off ; vidcontrol -m on a couple of times). This used to happen to me a lot with my Mouse Systems PS/2 mouse. I blamed it on static. I'm not sure when or why it stopped happening. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Neat little DPT utils...
On Wed, Jan 19, 2000 at 09:48:33AM -0600, damieon wrote: I was taking a look through the list archives, and it seems that this issue has come up before, I found that someone had decided that it was looking for depends that are in FreeBSD 2 or something. Are there Unfortunately, we currently have a regression problem in FreeBSD. Newer releases tend to drop support for things that have no active maintainer (or a maintainer who is too worn out by continually rewriting his or her software to cope with changed interfaces). Another unfortunate side effect of this is that some developers base their work on older releases rather than chase the moving target of -current. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck of /, related to last post.
On Thu, Dec 30, 1999 at 11:14:58AM -0500, David Gilbert wrote: "Bill" == Bill Fumerola [EMAIL PROTECTED] writes: Bill On Thu, 30 Dec 1999, David Gilbert wrote: Related to my last post, the system came up and started to fsck. It appears, with current, that the system will refuse to r/w mount root even though the fsck has complete successfully. Is this an rc-file out-of-date issue, or has something changed in the kernel. Bill Reboot. I don't know why it works, but it does. :- Right... I already knew that, but it's a manual reboot... and this is "suboptimal" (ie. requiring operator intervention). If you re-MAKEDEV your device nodes, it shouldn't happen again. It would be nice if something were fixed to actually say what's going on instead of confusing the hell out of people, since there seems to be a thread on this every day on -current. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lost PCMCIA sio (was: HEADSUP: wd driver will be retired!)
On Thu, Dec 09, 1999 at 11:01:16PM -0500, Greg Lehey wrote: pccardd[47]: driver allocation failed for Motorola(MONTANA 33.6 FAX/MODEM): Device not configured This closely parallels my experience. I used to get: Dec 5 11:57:53 mojave /kernel.old: sio1 at port 0x2e8-0x2ef irq 5 slot 1 on pccard0 Dec 5 11:57:53 mojave /kernel.old: sio1: type 16550A Now I get: Dec 9 20:08:02 mojave pccardd[53]: driver allocation failed for CIRRUS LOGIC 56K MODEM(CL-MD56XX): Device not configured This happened some time towards the end of last month. I saw the message about the missing #include "card.h", and that was it (along with a broken prototype). Still freezes when I eject, but I'll try again after cvsupping Warner's latest. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is there any way to use ATAPI CD-R?
On Thu, Dec 09, 1999 at 06:38:46AM +0300, Andrey A. Chernov wrote: On Wed, Dec 08, 1999 at 09:34:24PM +0100, Soren Schmidt wrote: I use it every day, well almost :) Look in /usr/share/examples/atapi... Thanks! Do you have a plan to merge ATAPI as part of SCSI (CAM) interface as NetBSD already does? It will solve problems with all SCSI-only CD* soft automatically. I'd love to see that. I have an ATAPI CD-R that doesn't seem to work properly with the worm stuff, but is supposedly supported by the cdrecord program. But we don't yet have the interface cdrecord wants. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Wed, Dec 08, 1999 at 10:56:24AM -0800, Mike Smith wrote: You shouldn't remove a function until it has been properly replaced. A very simple concept some people seem to have trouble grasping. Actually, that's not at all correct. We've demonstrated a number of times now that you reach a point where a brutal cutover is required. Failure to do so leaves people clutching the old security blanket for years, and massively impedes further development. Unfortunately, FreeBSD has far too many examples of a working system being replaced with a less functional system. Just off the top of my head, there were the SCSI drivers lost to CAM, the PCCARD system, sound drivers, and now ATA. All of those things needed to be redesigned, but I think it's unfortunate and dangerous to public perception when version X has less hardware support than version X-1. Right now, I have no sound (not detected), no USB (panic on removal), can't use my sio pccard, can't eject my ed pccard, my IDE drives are taking hours to dump and fsck, and my TV card is missing every other line if I try to use the (not working anyway) closed caption decoder. Now, I running -current on this machine, I've asked for problems, and I have them. I try to fix them and/or send decent bug reports when I can, and I don't piss and moan when something breaks, because it's -current. I just get a feeling sometimes like we're moving forward on a treadmill that's moving backward just slightly faster. My opinion is that the right approach is to change the defaults sooner, but remove the old code later. In other words, -current's GENERIC should have been using new-ATA as soon as it was working, but we shouldn't remove the wd driver entirely until all of its functionality is available in its replacement. Of course, in reality, APIs change and old code isn't always worth the effort of porting, so sometimes you just have to let go. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Wed, Dec 08, 1999 at 10:31:22PM +0100, Soren Schmidt wrote: Hmm, well, if you want support for any of the new ata-66 controllers you have to use the ata driver, so you loose some you win some. Given that my patch for the SiS works and a patch I got from Luoqi, the ONLY support you are loosing is the Cyrix. Personally, I've been using the new ata driver since it was first announced and haven't had any problems with it. But it appeared that a bunch of people piped up with various reasons they couldn't use it, so it seemed that it's a bit premature to delete wd entirely. Well, progress doesn't come for free you know, somebody has to do the hard work of actually implementing things. So if you think its going too slowly, do something about it, help out where you can, but complaining isn't helping anybody :) I'm not complaining. My remarks were not intended as an attack or complaint. I just think that it is a bad idea to completely delete the old driver while there are still a reasonable number of people who can't use the new one. As I said, I think it should have become the default a long time ago, so these people would have been somewhat more likely to have shown up before crunch time. I would love to do nothing more than help out with FreeBSD, but like almost all of us, my available time is limited. I have contributed my comments, bug reports, and occasional bits and pieces of code. This particular message should be interpreted more as a suggestion that new systems be made the default sooner in -current in order to get wider testing, but at the same time, the old system should be left as an option until that testing indicates it's safe for it to go away. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Wed, Dec 08, 1999 at 12:52:37PM -0800, Mike Smith wrote: Unfortunately, FreeBSD has far too many examples of a working system being replaced with a less functional system. Just off the top of my head, there were the SCSI drivers lost to CAM, the PCCARD system, sound drivers, and now ATA. Actually, most of this is histrionics. CAM didn't lose us SCSI drivers; we actually _gained_ from it. We gained quite a bit from it, but let's not rewrite history. I remember quite clearly that there was a very popular Adaptec SCSI controller missing when the switch to CAM was made, and a lot of people were inconvenienced. That is a matter of recorded historical fact. Please don't misinterpret me; I am not suggesting that CAM shouldn't have happened, that anyone did anything wrong or that it should have been handled differently. I am merely pointing out that "CAM didn't lose us SCSI drivers" is inaccurate. We haven't "lost" the pccard system at all Again, this is not accurate. I have a laptop with which, two months ago, I could use my LinkSys ethernet card, and I could use my digital camera's compact flash adapter. I could eject them and put them back in numerous times. I could suspend and resume. Due to some changes in the pccard system, I can no longer do these things. Due to some more recent changes, I can't even use my wireless IP card at all. So it is a simple matter of fact that functionality has been lost. Of course it is only temporary. Once again, I ask that you don't misinterpret this simple statement of fact as a complaint or attack. Warner's pccard work was desperately needed and I am confident that eventually everything will be back and better than ever. And I am not only willing, but happy to deal with these problems that I have brought upon myself by choosing to run -current on my laptop. and the new sound code is on a feature-par with both of the old ones. When it works, it works very well. But again, the fact is that I had sound on this computer three years ago. I had sound a few weeks ago. Then I didn't. Then it came back. Now it's gone again. It'll probably come back next time I build a kernel (I have an AWE64). But the fact is that something WAS lost: $ cat /dev/audio zsh: device not configured: /dev/audio What we need here is a commitment to these new initiatives, not a lot of fence-sitting and clutching our knitting to our chests. All of these initiatives were started to deal with massive problems in the subsystems they replace; clinging to the old code rather than getting on-board and helping with the new code directly impedes the resolution of these problems. Again, I say, think of what we're trying to achieve here. I fully agree that these things are neccessary and good. I just think we need avoid jumping the gun on removing the old code, when some people still need it to boot their machines. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Wed, Dec 08, 1999 at 10:52:42PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : Right now, I have no sound (not detected), no USB (panic on removal), : can't use my sio pccard, can't eject my ed pccard, my IDE drives are : taking hours to dump and fsck, and my TV card is missing every other : line if I try to use the (not working anyway) closed caption decoder. I have some patches for the can't eject the network cards from a user that I'm trying out and would then need to get committed to the network layer to properly support if_detach(). What's wrong with your sio pccard? Mine works well enough... After the December 2nd change, as I reported: Hmm.. something's not right. I can eject my ed card (though I get the "pccard: card removed, slot 0" message twice. But it doesn't attach if I insert it again. "driver allocation failed for Linksys(Combo PCMCIA EthernetCard (EC): Device not configured". * sio is a bit worse, it doesn't work the first time (same error: * device not configured). I have since been completely bogged down in work, and I haven't even touched the machine since then. Our major product demo is tomorrow, Friday is major construction and rewiring on top of feedback from the demo, and on Saturday there's a complete power down to change out the building's UPS and then move an OC-3. With luck, if I'm still alive on Sunday, I'll be able to confirm whether the problem is still present and if so, try to fix it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ed driver, resources not released (was: Re: PCCARD eject freeze)
On Tue, Dec 07, 1999 at 09:22:31AM -0700, Warner Losh wrote:
In message [EMAIL PROTECTED] Nick Hibma writes:
: Hm, The machine is not crashing at the moment when unplugging the
: device. But plugging it back in gives me a 'No free configuration for
: card Ethernet' ('Ethernet' being the quite splendid name of the card in
: the CIS).
:
: A quick browse reveals the following difference between ep and ed. It
: doesn't have any effect however.
:
: Let me know if I can test anything. I'd like to get that working, but
: don't have the time to dig into this (utun driver is more important :)
Quick question. If you kill and restart pccardd does the problem go
away?
It doesn't for me (I have the same problem). This last commit was
unfortunate, as it didn't really help the eject situation and now
I can't use my sio card at all. :-(
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Wed, Dec 01, 1999 at 09:05:38AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Mike Smith writes: : The only "right" solution is for us to mandate that people down cards : before ejecting them. The physical design of pccards basically gives us : no other option. No matter how hard we try to get it "right" for : spontaneous removal, we can't win that fight. I agree with this. In fact the pccard standard is very careful to state that pccard and cardbus support hot insertion rather than hot swap. I wanted to make it suck less and give poorly written drivers more of a chance to work. I think it's pretty much a given, though, that once one puts a pccard in a laptop, one is very unlikely to be happy if one can't remove it without powering down the machine. Particularly given that laptops are much more useful if you can suspend them. So we need something. I would like to see that something along the lines of a method to shut down the card in preparation for removal, regardless of what kind of card it is. In other words, whereas right now I would have to "ifconfig down" if it's an ethernet card, "pppctl close" if it's a serial card, and unmount the filesystem if it's a flash card, I think there needs to be a way to say "shut down slot X" and either have those things happen based on a shutdown script, or make the underlying drivers fail gracefully (although I have difficulty imagining that happening in the case of a read/write mounted filesystem). There are other contexts for the same issues anyway. USB has devices that go away suddenly, and it _is_ designed to be hot-removable, so people are going to be pulling the plug on network adapters, ZIP drives, etc. We need drivers that are capable of going away cleanly, or at least without a panic. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Wed, Dec 01, 1999 at 12:02:54PM -0800, Mike Smith wrote: On Wed, Dec 01, 1999 at 09:05:38AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Mike Smith writes: : The only "right" solution is for us to mandate that people down cards : before ejecting them. ... I would like to see that something along the lines of a method to shut down the card in preparation for removal, That's what I said above. The part after the comma was the point of the sentence. That the method to deactivate the card not be specific to the type of card in use, but rather to have a generic mechanism. That's quite possibly exactly what you said, in which case I'm just agreeing with you. :-) In other words, whereas right now I would have to "ifconfig down" if it's an ethernet card, "pppctl close" if it's a serial card, and unmount the filesystem if it's a flash card, None of those actions would be adequate. I meant to illustrate what I felt would be the wrong approach. I think I didn't get my point across, so I will rephrase it. Rather than ending up with a system where you can take the card out if it's "not in use" (where the definition of "not in use" is different for each device), I think it is important that instead the user can say "I want to take the card out of slot X, so make it possible for me to do so or tell me why I can't." There are other contexts for the same issues anyway. USB has devices that go away suddenly, and it _is_ designed to be hot-removable, so people are going to be pulling the plug on network adapters, ZIP drives, etc. We need drivers that are capable of going away cleanly, or at least without a panic. You can't do this with pccard, full stop. It's not a code problem, it's a design problem fundamental to pccards. I know that. The point was that lots of new busses ARE designed for hot plugging and unplugging, so it's not just pccard that needs to deal with it. Once the underlying mechanism is established for a driver to safely and cleanly go away, pccard just becomes a matter of telling the driver to go away before touching the eject button. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 02:59:10PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : I found that the only message printed was "ready to power off". bingo. looks like we're not deleting the child. Try replacing that for loop with something like: pccarddev = devclass_get_device(pccard_devclass, slt-slot); device_get_children(pccarddev, kids, nkids) for (i = 0; i nkids; i++) device_delete_child(pccarddev, kid[0]); It isn't quite right, but if it works then I know the right fix. Hey, we're getting somewhere. It works, in that it stops the panic. I get the "ed0: unloaded" message, and the machine doesn't panic, but there are still some problems. It seems that device_delete_child is failing (I forgot to print the return code, but it is not zero), and reinserting the card results in "ed0 already exists, using next available unit number", and then the dreaded "driver allocation failed" (presumably the resources have not been freed). Putting in a different kind of card ends up with two children, so it seems that the only part of the delete actually happens. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 02:54:28PM -0800, Frank Mayhar wrote:
On Tue, Nov 30, 1999 at 02:59:10PM -0700, Warner Losh wrote:
pccarddev = devclass_get_device(pccard_devclass, slt-slot);
device_get_children(pccarddev, kids, nkids)
for (i = 0; i nkids; i++)
device_delete_child(pccarddev, kid[0]);
I'll bet Warner meant
device_delete_child(pccarddev, kid[i]);
up there, and not
device_delete_child(pccarddev, kid[0]);
Did you try that?
Yes, the actual code I used is:
pccarddev = devclass_get_device(pccard_devclass, slt-slotnum);
device_get_children(pccarddev, kids, nkids);
printf("pccard: %d kids\n", nkids);
for (i = 0; i nkids; i++) {
printf("pccard: deleting kid %d\n", i);
if (ret=device_delete_child(pccarddev, kids[i]))
printf("pccard: delete kid %d failed: %d\n", i, ret);
}
It's not quite working. I think I got away ok with the ethernet card
because it wasn't being accessed, but my CDPD card with a running PPP
session pretty reliably still freezes up. Hrm. No, it's not freezing
up, it's a panic, but I'm running X and can't get to it.
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 04:04:40PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Christopher Masto writes: : Hey, we're getting somewhere. It works, in that it stops the panic. : I get the "ed0: unloaded" message, and the machine doesn't panic, but : there are still some problems. It seems that device_delete_child : is failing (I forgot to print the return code, but it is not zero), : and reinserting the card results in "ed0 already exists, using : next available unit number", and then the dreaded "driver allocation : failed" (presumably the resources have not been freed). : : Putting in a different kind of card ends up with two children, so : it seems that the only part of the delete actually happens. Hmmm... That's something... How do you know that the delete_child is failing? An if printing that it failed or conjecture based on the insertion results? I added a check of the return value. It seemed to be returning 12 (ENOMEM), but I'm not sure if that's real or garbage, since I'm having trouble finding a code path that would return that. And further data on the CDPD card.. removing it while PPP is still running just paniced in sioioctl. However, the delete_child didn't fail for sio, unlike with ed. I'm going to reboot and see if I can successfully remove and reinsert the card if I make sure nothing has sio open at the time. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
I'm on my way out for dinner, just thought I'd mention the latest experiment results. On Tue, Nov 30, 1999 at 04:19:18PM -0700, Warner Losh wrote: : And further data on the CDPD card.. removing it while PPP is still : running just paniced in sioioctl. However, the delete_child didn't : fail for sio, unlike with ed. I'm going to reboot and see if I can : successfully remove and reinsert the card if I make sure nothing has : sio open at the time. Hmmm. The sioioctl tells me that there is the memory problem I alluded to in the previous message.. At least that's my hunch... I just tried it without the device in use, and it froze solid after: pccard: 1 kids pccard: deleting kid 0 sio3: unload,gone pccard: delete kid 0 failed: 18 pccard: ready to power off pccard: card removed, slot 0 Ho hum. sio_pccard_detach also needs to be fixed to return 0, but I don't think that explains the freeze. Unfortunately, while I can sometimes squeeze in a few minutes to try quick fixes, my current job doesn't leave me with time to get enough clue to really work on this. If you lived in New York, I'd lend you my laptop. :-/ Good luck getting yours back. I have the same model, and desperately hoping I won't also have to deal with Sony's famous customer disservice. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD eject freeze (was Re: your mail)
On Tue, Nov 30, 1999 at 04:52:33PM -0700, Warner Losh wrote:
It would help me if you could send me your patches...
Well, here's all I've got. It's basically just a sloppy version of
what you suggested.
Index: pccard.c
===
RCS file: /usr/local/ncvs/freebsd/src/sys/pccard/pccard.c,v
retrieving revision 1.93
diff -u -r1.93 pccard.c
--- pccard.c1999/11/20 05:01:59 1.93
+++ pccard.c1999/12/01 02:33:52
@@ -177,8 +177,10 @@
disable_slot(struct slot *slt)
{
device_t pccarddev;
+ device_t *kids;
+ int nkids;
struct pccard_devinfo *devi;
- int i;
+ int i, ret;
/*
* Unload all the drivers on this slot. Note we can't
@@ -191,14 +193,26 @@
* driver is accessing the device and it is removed, then
* all bets are off...
*/
- pccarddev = devclass_get_device(pccard_devclass, 0);
- for (devi = slt-devices; devi; devi = devi-next) {
- if (devi-isahd.id_device != 0) {
- device_delete_child(pccarddev, devi-isahd.id_device);
- devi-isahd.id_device = 0;
- }
+ pccarddev = devclass_get_device(pccard_devclass, slt-slotnum);
+ device_get_children(pccarddev, kids, nkids);
+ printf("pccard: %d kids\n", nkids);
+ for (i = 0; i nkids; i++) {
+ printf("pccard: deleting kid %d\n", i);
+ if (ret=device_delete_child(pccarddev, kids[i]))
+ printf("pccard: delete kid %d failed: %d\n", i, ret);
}
+ /* for (devi = slt-devices; devi; devi = devi-next) {
+ printf("pccard: considering delete\n");
+ if (devi-isahd.id_device != 0) {
+ printf("pccard: doing the delete\n");
+ if (device_delete_child(pccarddev, devi-isahd.id_device))
+ printf("pccard: device_delete_child failed\n");
+ devi-isahd.id_device = 0;
+ }
+ }
+ */
+ printf("pccard: ready to power off\n");
/* Power off the slot 1/2 second after removal of the card */
slt-poff_ch = timeout(power_off_slot, (caddr_t)slt, hz / 2);
slt-pwr_off_pending = 1;
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ps on 4.0-current
On Wed, Nov 24, 1999 at 12:54:15AM +0100, Poul-Henning Kamp wrote: I'm personally leaning towards the opinion that the argv is public property and should be visible, but then again, I can see the point in hiding it in some circumstances. I'll stick a sysctl in there which defaults to the "open" position and people who need to hide it can set it to "close" to do so. Please. Thank you. Not everyone wears the sysadmin hat with the face shield and gas mask, as much as it may currently be in style. If it can work both ways, even better. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netscape and -current
On Tue, Nov 23, 1999 at 11:44:33AM +0800, Peter Wemm wrote:
I'd be curious to know if this fixes it on a -current kernel (after rev 1.377
of i386/machdep.c)
Yep, except this needs to come out:
+ scp = (struct osigcontext *)ucp;
+
+ if (useracc((caddr_t)scp, sizeof (struct osigcontext), VM_PROT_READ)) {
+ if (scp-sigcntxp-sc_trapno == 0x01d516)
^^
And that does the trick.
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fsck follies
On Sun, Nov 21, 1999 at 10:36:32PM +1000, Stephen McKay wrote: When the system came back up, fsck -p didn't like the vinum volume. No sweat, I ran it manually. There were many INCORRECT BLOCK COUNT I=n (4 should be 0) messages. I assumed this was an artifact of soft updates. The fsck completed successfully. Being paranoid, I reran fsck. This time it reported a number of unreferenced inodes (199 to be exact), and linked them in to lost+found. It is this last item that bothers me. When the first fsck completed, the filesystem should have been structurally correct. But it wasn't. A third fsck confirmed that 2 runs of fsck were enough. Presumably you are using vinum for mirroring? I have had to stop doing so after trashing several filesystems. There are some serious bugs that allow the plexes to get out of sync; as reads from a mirror set are round-robin, this can be very bad. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PC-Card ejection(suspend) with 4-current
On Wed, Nov 10, 1999 at 03:05:28PM -0700, Warner Losh wrote: : # or we need to rewrite and maintain pccard code(/sys/dev/pccard)? That's the real answer. Anybody willing to help, please let me know. I have probe/attach code for the pcic code (in /sys/dev/pcic) going, but I've not hooked up the pccard stuff to it. My work on this is on hold for the moment until my Sony VAIO gets back from Sony... Hopefully by Friday when I head off for the weekend... I'm willing to try/test anything, but as I am stuck with enormous amounts of work for the rest of the year, I can only spend minimal time actually touching the code. I'd love to see this fixed, though. It's an incredible annoyance to have to shut my laptop off instead of suspending. As for the arguments about "safe" removal, let's not let the quest for the perfect shed kill this; if the device has to be disabled before removing it, so be it.. but right now it's not possible to remove a pccard at all. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor heads up - /etc/make.conf{,.local} being moved
On Tue, Nov 02, 1999 at 10:41:19PM +, Jason C. Wells wrote: Put me down as wanting two files. An extra file is just more shtuff to keep track of. I too am iffy on /etc/defaults. If the purpose of defaults is to keep "standard" things in isolation then lets do that. Begrudgingly, defaults do clean up /etc a bit. It makes mergemastering easier too. The defaults will be better when they become more complete. The thing about the defaults/foo.conf, foo.conf, foo.conf.local scheme is that you don't _have_ to use foo.conf.local if you don't want to. Some of us have a use for it, such as putting site configuration in foo.conf, and machine configuration in foo.conf.local. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA module breaks USB?
On Sun, Oct 31, 1999 at 09:39:33PM -0700, Nick Hibma wrote: ohci0: OPTi 82C861 (FireLink) USB controller irq 9 at device 11.0 on pci0 +ohci_waitintr: timeout IRQ 9 is shared with the VGA controller. Perhaps calling the VESA BIOS caused it to do something strange that interfered with the delivery of this interrupt on your motherboard. No, this has something to do with soft resetting vs. hard resetting. It might be that this is related to soft rebooting out of Windows. Try switching off and on your machine. I don't have Windows, but I can try a hard boot at some point and see if it helps. I can also try to fiddle with the IRQs just in case, but they are after all being assigned by FreeBSD. For now I've just turned off VESA, but I think it is going to become non-optional at some point and I'd hate to see my USB go away. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VESA module breaks USB?
nterrupt: error=0x00 atapi: phew, got back from tsleep ast0: OnStream DI-30/1.00 tape drive at ata1 as slave ast0: 2097KB/s, transfer limit 1 blk, 2048KB buffer, DMA ast0: OnStream ADR (15Gyte) media, lock, eject, ecc, 32kb atapi: starting MODE_SENSE atapi: ccb = 1a-08-30-00-08-00-00-00-00-00-00-00-00-00-00-00 atapi_interrupt: enter atapi_interrupt: length=8 reason=0x0a atapi_interrupt: enter atapi_interrupt: length=8 reason=0x03 atapi_interrupt: error=0x00 atapi: phew, got back from tsleep atapi: starting MODE_SENSE atapi: ccb = 1a-08-36-00-0c-00-00-00-00-00-00-00-00-00-00-00 atapi_interrupt: enter atapi_interrupt: length=12 reason=0x0a atapi_interrupt: enter atapi_interrupt: length=12 reason=0x03 atapi_interrupt: error=0x00 atapi: phew, got back from tsleep atapi: starting MODE_SELECT atapi: ccb = 15-10-00-00-0c-00-00-00-00-00-00-00-00-00-00-00 atapi_interrupt: enter atapi_interrupt: length=12 reason=0x08 atapi_interrupt: enter atapi_interrupt: length=12 reason=0x03 atapi_interrupt: error=0x00 atapi: phew, got back from tsleep atapi: starting READ_POSITION atapi: ccb = 34-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 atapi_interrupt: enter atapi_interrupt: length=20 reason=0x03 atapi_interrupt: read size problem, 20 bytes residue atapi_interrupt: error=0x24 atapi: starting REQUEST_SENSE atapi: ccb = 03-00-00-00-12-00-00-00-00-00-00-00-00-00-00-00 atapi_interrupt: enter atapi_interrupt: length=16 reason=0x0a atapi_interrupt: enter atapi_interrupt: length=16 reason=0x03 atapi_interrupt: read size problem, 2 bytes residue atapi: READ_POSITION - NOT READY skey=2 asc=3a ascq=00 error=04 atapi_interrupt: error=0x24 atapi: phew, got back from tsleep Considering FFS root f/s. changing root device to wd0s1a wd0s1: type 0xa5, start 0, end = 4999679, size 4999680 : OK start_init: trying /sbin/init -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SOLVED (partly): Re: Can't start vinum with new kernels
I found out what was causing "Can't get device list: Cannot allocate memory".. libdevstat mismatch. Now I'm getting a panic, but hopefully I'll have a decent backtrace out of it soon. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SOLVED (partly): Re: Can't start vinum with new kernels
On Sun, Oct 03, 1999 at 12:42:54PM -0700, Jake Burkholder wrote: I found out what was causing "Can't get device list: Cannot allocate memory".. libdevstat mismatch. Now I'm getting a panic, but hopefully I'll have a decent backtrace out of it soon. then promptly rebuilt the world, and everything was fine. the panic could be from old /sbin/vinum with new kernel and/or vinum.ko, I'd suggest rebuilding that too. Nope, I've been rebuilding them all along. Just got it again.. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x8:0xc017cf0f stack pointer = 0x10:0xcdacfb9c frame pointer = 0x10:0xcdacfbcc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 16 (vinum) interrupt mask = bio kernel: type 12 trap, code=0 Stopped at getblk+0x21b: cmpl$0x3,0x48(%edx) db trace getblk(0,8,1000,0,0) at getblk+0x21b bread(0,8,1000,0,cdacfc3c) at bread+0x22 _end(c1150800,c1151000,2,1200,0) at 0xc108d0f3 _end(c1098284,4,0,c1062800,cdacfd74) at 0xc108e19e _end(c1062800,c109813c,0,0,cdacfd98) at 0xc108c009 _end(c1062800,c109813c,cdacfdf4,c106c580,cc734500) at 0xc108c063 _end(c106c580,c4004640,c1062800,3,cc734500) at 0xc1092658 spec_ioctl(cdacfdf4,cdacfdd8,c0206489,cdacfdf4,cdacfe84) at spec_ioctl+0x33 spec_vnoperate(cdacfdf4,cdacfe84,c0189a3c,cdacfdf4,c1081dc0) at spec_vnoperate+0x15 ufs_vnoperatespec(cdacfdf4,c1081dc0,0,400,0) at ufs_vnoperatespec+0x15 vn_ioctl(c1081dc0,c4004640,c1062800,cc734500,cc734500) at vn_ioctl+0x114 ioctl(cc734500,cdacff80,4,bfbfd4f0,4) at ioctl+0x20b syscall(2f,2f,2f,4,bfbfd4f0) at syscall+0x195 Xint0x80_syscall() at Xint0x80_syscall+0x26 Waiting for the dump now.. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vinum panic
On Sun, Oct 03, 1999 at 03:09:02PM -0400, Christopher Masto wrote:
Now I'm getting a panic, but hopefully I'll have a decent backtrace
out of it soon.
Well...
#0 0xc018a06b in getblk (vp=0x0, blkno=0x8, size=0x1000, slpflag=0x0, slptimeo=0x0)
at ../../kern/vfs_bio.c:2110
#1 0xc0188346 in bread (vp=0x0, blkno=0x8, size=0x1000, cred=0x0, bpp=0xcda6fc3c) at
../../kern/vfs_bio.c:478
#2 0xc014b40f in read_drive (drive=0xc1083000, buf=0xc108b000, length=0x2,
offset=0x1200)
at ../../dev/vinum/vinumio.c:284
#3 0xc014c4b2 in vinum_scandisk (devicename=0xc02c6824, drives=0x4) at
../../dev/vinum/vinumio.c:959
#4 0xc01494f5 in parse_config (cptr=0xc1063000 "read", keyset=0xc02a71d0, update=0x0)
at ../../dev/vinum/vinumconfig.c:1516
#5 0xc014954f in parse_user_config (cptr=0xc1063000 "read", keyset=0xc02a71d0) at
../../dev/vinum/vinumconfig.c:1559
#6 0xc014c9d4 in vinumioctl (dev=0xc106e700, cmd=0xc4004640, data=0xc1063000 "read",
flag=0x3, p=0xcc6e3500)
at ../../dev/vinum/vinumioctl.c:110
#7 0xc019c8bf in spec_ioctl (ap=0xcda6fdf4) at ../../miscfs/specfs/spec_vnops.c:519
#8 0xc019c135 in spec_vnoperate (ap=0xcda6fdf4) at
../../miscfs/specfs/spec_vnops.c:125
#9 0xc02135e5 in ufs_vnoperatespec (ap=0xcda6fdf4) at ../../ufs/ufs/ufs_vnops.c:2313
#10 0xc0196b98 in vn_ioctl (fp=0xc10580c0, com=0xc4004640, data=0xc1063000 "read",
p=0xcc6e3500) at vnode_if.h:425
#11 0xc01750df in ioctl (p=0xcc6e3500, uap=0xcda6ff80) at ../../sys/file.h:166
#12 0xc025ad01 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi =
0x4, tf_esi = 0xbfbfd4a8,
tf_ebp = 0xbfbfd8a8, tf_isp = 0xcda6ffd4, tf_ebx = 0x4, tf_edx = 0x8085da5,
tf_ecx = 0xbfbfd4d0, tf_eax = 0x36,
tf_trapno = 0x7, tf_err = 0x2, tf_eip = 0x8064f6c, tf_cs = 0x1f, tf_eflags =
0x246, tf_esp = 0xbfbfd488,
tf_ss = 0x2f}) at ../../i386/i386/trap.c:1056
#13 0xc024cc36 in Xint0x80_syscall ()
#14 0x804cdd7 in ?? ()
#15 0x8048492 in ?? ()
#16 0x80482fd in ?? ()
#17 0x80480e9 in ?? ()
Obviously a NULL vp is being passed down from somewhere..
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vinum panic
On Mon, Oct 04, 1999 at 09:57:42AM +0930, Greg Lehey wrote: I've seen this, and I thought I had fixed it in revision 1.44 of sys/dev/vinum/vinumio.c. Note also that the drive state is down, so it shouldn't be reading it in the first place. Which revision are you using? It's 1.44. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
On Thu, Aug 26, 1999 at 10:35:27PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Dillon writes: That fixes a problem with ccd, but not the one causing John's failures. You will note that with John's failure's the I/O is properly page-aligned. The fix to ccd deals with a misalignment problem. No it doesn't. johns failure is clearly the si_bsize* problem, the tell-tale sign is all the zeros in there. What John didn't tell us is if he uses vn, ccd or vinum (or something else!) Well, I just had much the same blowup with source from last night and I'm using vinum, (and not vn or ccd). Recompiling now to see if it's still there. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
On Thu, Aug 26, 1999 at 11:04:44PM +0200, Poul-Henning Kamp wrote: Well, I just had much the same blowup with source from last night and I'm using vinum, (and not vn or ccd). Recompiling now to see if it's still there. Ok, I havn't touched vinum (grog generally want to do this himself), I will try that fix next. FYI, here's what it looked like: (I don't know what's with the garbage, maybe it was my serial console) [everything apparently normal until..] Doing initial network setup: hostname. lgo0: flags=8049UeP,LOOPBACK,RUNNIsNG,MULTICAST mt:u 16384 inet 1 27.0.0.1 netmaskI 0xff00 /O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 60512, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 15 Flushed all rules. 00100 allow ip from any to any via lo0 00200 deny ip from asny to 127.0.0.0/p8 65000 allow iep from any to ancy Firewall rule_s loaded, startigng divert daemones:. add net deftault: gateway 16p7.206.208.254 Aadditional routingg options: tcp eextensions=NO TCPs keepalive=YES.: routing daemons :. Mounting NFSI file systems. /O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 5672, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 /etc/rc: chflags: I/O error /etc/rc: chown: sI/O error padditional daemoens:c_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 24352, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 6 syslogd/etc/rc: syslogds: I/O error p. ec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 8192, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 Doing additionals network setup: pportmape/etc/rc: /usr/sbcin/portmap: I/O _error getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 8192, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 . Starting finasl network daemonps:. e/etc/rc: kvm_mkdcb: I/O error _getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 4132, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 /etc/rc: dev_mkdb: I/O error spec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 49152, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 12 /etc/rc: /usr/bin/objformat: I/O error setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout starting standarsd daemons:p inetdec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 24576, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 6 /etc/rc: inetd: sI/O error p cronec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 24576, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 6 /etc/rc: cron: Is/O error p sendmailec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 57344, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 14 /etc/rc: /usr/sbsin/sendmail: I/Op error e. c_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 4088, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 1 /etc/rc: uname: I/O error Local package initialization:spec_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a86c0 size: 0, resid: 0, a_count: 75, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 1 /etc/rc: /usr/loscal/etc/rc.d/50.pm3.sh: I/O errore c_getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a86c0 size: 0, resid: 0, a_count: 81, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 1 /etc/rc: /usr/loscal/etc/rc.d/sshpd.sh: I/O errore c. _getpages: I/O read failure: (error code=0) bp 0xc6321358 vp 0xcc6a9500 size: 0, resid: 0, a_count: 4248, valid: 0x0 nread: 0, reqpage: 0, pindex: 0, pcount: 2 /etc/rc: mktemp: I/O error Thu Aug 26 16:14:22 EDT 1999cu: Got hangup signal I'll let you know if the patch to vinum cures it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel problems (spec_getpages vm_fault)
On Thu, Aug 26, 1999 at 11:04:44PM +0200, Poul-Henning Kamp wrote: Ok, I havn't touched vinum (grog generally want to do this himself), the fix is probably something like this: Index: vinum.c === RCS file: /home/ncvs/src/sys/dev/vinum/vinum.c,v retrieving revision 1.29 diff -u -r1.29 vinum.c --- vinum.c 1999/08/24 02:18:55 1.29 +++ vinum.c 1999/08/26 21:04:03 @@ -271,6 +271,9 @@ int devminor;/* minor number */ devminor = minor(dev); +dev-si_bsize_phys = DEV_BSIZE; +dev-si_bsize_best = BLKDEV_IOSIZE; +dev-si_bsize_max = MAXBSIZE; Bingo! Thank you. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current broken?
Yesterday and today, after a cvsup and kernel build, I get a panic very early in the boot on my laptop. What's left on the screen is a general protection fault in kernel mode, and an attempt to trace just causes another panic. Tomorrow I will put a serial cable on it and get some details, but I'm guessing that this comes from the recent BUF_STRATEGY stuff, possibly breaking in the wd driver (which might be why there hasn't been a report yet if most everyone is using ata). I'm stuck with wd for the moment (pccard compact flash stuff), so if that's it and it hasn't been repaired by then, I'll dig into it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ide_pci.c DMA broken
keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0at atkbdc? irq 12 # Options for psm: #optionsPSM_HOOKAPM #optionsPSM_RESETAFTERSUSPEND device vga0at isa? port ? conflicts # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? device npx0at nexus? port IO_NPX irq 13 device apm0at nexus? flags 0x20 # Advanced Power Management device sio0at isa? port IO_COM1 flags 0x90 irq 4 device sio1at isa? port IO_COM2 irq 3 device sio2at isa? port 0x3e8 irq 10 # Parallel port device ppc0at isa? port? flags 0x40 irq 7 controller ppbus0 device lpt0at ppbus? device plip0 at ppbus? device ppi0at ppbus? device ep0 at isa? port 0x300 irq 10 # SMB Bus controller smbus0 controller intpm0 controller alpm0 device smb0 at smbus? # PCCARD controller card0 device pcic0 at card? #device pcic0 options PCIC_RESUME_RESET # Sound device pcm0 at isa? port ? irq 5 drq 1 flags 0x0 #controller snd0 #device sb0 at isa? port 0x220 irq 5 drq 1 #device sbxvi0 at isa? drq 5 #device sbmidi0 at isa? port 0x330 #device awe0 at isa? port 0x620 # USB controller uhci0 controller ohci0 controller usb0 #controller umass0 device ums0 device ukbd0 device ulpt0 device uhid0 device ugen0 pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 32 pseudo-device gzip# Exec gzipped a.out's pseudo-device snp 3 # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing # This provides support for System V shared memory and message queues. # options SYSVSHM options SYSVMSG options SYSVSEM # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. pseudo-device bpf 4 #Berkeley packet filter #optionsNETATALK options MSGBUF_SIZE=16384 options DDB #optionsDDB_UNATTENDED options BREAK_TO_DEBUGGER options SOFTUPDATES options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=100 options ICMP_BANDLIM options DUMMYNET options USER_LDT #optionsVM86 #optionsVESA options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L I really don't know crap about what's going on in that part of the kernel, but I'll do whatever I can to help track this down. Or perhaps it will be intuitively obvious from this report. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USB fixes for cdevsw change
USB stopped working as of the recent cdevsw cleanup. This fixes it.
Index: usb.c
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usb.c,v
retrieving revision 1.12
diff -u -r1.12 usb.c
--- usb.c 1999/05/30 16:51:51 1.12
+++ usb.c 1999/06/01 00:30:23
@@ -129,7 +129,7 @@
/* strategy */ nostrategy,
/* name */ usb,
/* parms */ noparms,
- /* maj */ -1,
+ /* maj */ USB_CDEV_MAJOR,
/* dump */ nodump,
/* psize */ nopsize,
/* flags */ 0,
Index: usbdi.c
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.17
diff -u -r1.17 usbdi.c
--- usbdi.c 1999/05/31 11:25:21 1.17
+++ usbdi.c 1999/06/01 00:30:23
@@ -80,12 +80,6 @@
static SIMPLEQ_HEAD(, usbd_request) usbd_free_requests;
-#if defined(__FreeBSD__)
-#define USB_CDEV_MAJOR 108
-
-extern struct cdevsw usb_cdevsw;
-#endif
-
#ifdef USB_DEBUG
char *usbd_error_strs[USBD_ERROR_MAX] = {
NORMAL_COMPLETION,
Index: usbdi.h
===
RCS file: /usr/cvs/freebsd/src/sys/dev/usb/usbdi.h,v
retrieving revision 1.11
diff -u -r1.11 usbdi.h
--- usbdi.h 1999/05/20 20:02:37 1.11
+++ usbdi.h 1999/06/01 00:30:23
@@ -115,6 +115,12 @@
#define USBD_NO_TIMEOUT 0
#define USBD_DEFAULT_TIMEOUT 5000 /* ms = 5 s */
+#if defined(__FreeBSD__)
+#define USB_CDEV_MAJOR 108
+
+extern struct cdevsw usb_cdevsw;
+#endif
+
usbd_status usbd_open_pipe
__P((usbd_interface_handle iface, u_int8_t address,
u_int8_t flags, usbd_pipe_handle *pipe));
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: zzz crashing in current OR inthand_remove not removing handlers properly
On Mon, May 17, 1999 at 09:00:50AM -0600, Nate Williams wrote: Hi, on a -current from around a week ago `zzz' always managed to crash my machine. The relevant parts from the panic and the backtrace are included below. It seems that the cause of this was a stray interrupt was arriving after having unloaded the driver. For some reason it wasn't handled by isa_strayintr, and the reason for that was that inthand_remove didn't manage to remove the interrupt (and get it replaced by the stray function) correctly. After applying the patch at the end of this mail I can once again sleep my laptop succesfully. Wow. I think that's actually done the trick. Not only can I suspend, but I can now remove my 3C589 without a panic. ... well, I just managed to lock up the machine.. but I think that was from a missed remove event. I must have lost that polling patch somewhere along the way. If you're polling, it's *REAL* easy to lockup the machine inside the card's interrupt handler, with no chance of it every escaping since the 'poll' can't interrupt the IRQ. Actually, I was not polling, which I thought might have been why pccard didn't notice when I removed my network card. Polling didn't fix that, so I looked elsewhere. It turns out that after a hibernate (but not after a suspend), insert/remove events stop working unless the kernel is compiled with PCIC_RESUME_RESET. With that and Assar's patch, my vaio is reasonably usable. (I hook it up to the ethernet at work, so having to shut down to remove the card or even just suspend is rather tedious.) The solution is to not poll and to make sure insertion/removal events generate an interrupt which can inform the card's interrupt handlers that there is no more card. Fortunately the interrupts do seem to work on this machine. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: zzz crashing in current OR inthand_remove not removing handlers properly
, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing # This provides support for System V shared memory and message queues. # options SYSVSHM options SYSVMSG options SYSVSEM # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. pseudo-device bpfilter 4 #Berkeley packet filter #optionsNETATALK options DDB options BREAK_TO_DEBUGGER options DDB_UNATTENDED options SOFTUPDATES options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=100 options ICMP_BANDLIM options DUMMYNET options USER_LDT options VM86 options VESA options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTIC options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: zzz crashing in current OR inthand_remove not removing handlers properly
On Mon, May 17, 1999 at 04:33:12AM +0200, Assar Westerlund wrote: Hi, on a -current from around a week ago `zzz' always managed to crash my machine. The relevant parts from the panic and the backtrace are included below. It seems that the cause of this was a stray interrupt was arriving after having unloaded the driver. For some reason it wasn't handled by isa_strayintr, and the reason for that was that inthand_remove didn't manage to remove the interrupt (and get it replaced by the stray function) correctly. After applying the patch at the end of this mail I can once again sleep my laptop succesfully. Wow. I think that's actually done the trick. Not only can I suspend, but I can now remove my 3C589 without a panic. ... well, I just managed to lock up the machine.. but I think that was from a missed remove event. I must have lost that polling patch somewhere along the way. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IBM's Via Voice
On Mon, May 03, 1999 at 03:51:21PM -0700, Amancio Hasty wrote:
After playing a little more with ViaVoice, I can't seem to load the sample
binaries the come back with :
./hello
./hello: error in loading shared libraries
/usr/lib/libsmapi.so: undefined symbol: __bzero
objdump --dynamic-syms /compat/linux/usr/lib/libsmapi.so | grep bzero
DYNAMIC SYMBOL TABLE:
DF *UND* 0035 __bzero
w DF *UND* 0035 bzero
Does anyone know what the difference is between symbol
type and w?
No, but I have the same problem. But for anyone else who can't even
get this far.. I needed to install the ldconfig-1.9.5-15.i386.rpm
RPM.
Annoyingly, the Audio Setup Guru works. So close..
--
Christopher Masto Senior Network Monkey NetMonger Communications
ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Our routed - Vern says it's old and buggy.
On Wed, Apr 28, 1999 at 02:45:50PM +1200, Joe Abley wrote: It's also probably worth mentioning that Zebra is being developed in an extremely active and proactive fashion, and the principal developers are extremely open to contributed feedback and code. And it says right on their information page, Currently we are developing zebra under: GNU/Linux 2.0.X GNU/Linux 2.2.X FreeBSD 2.2.8 FreeBSD 3.X FreeBSD 4.X [...] IPv6 support is for. FreeBSD with INRIA FreeBSD with KAME GNU/Linux with IPv6 GNU/Hurd with pfinet6 (under development) This seems like a very good thing. I have not tried Zebra, but unless there is something horribly wrong with it, I think it makes more sense to help them than to fall prey to Not Invented Here and do our own OSPF. Hopefully nobody will start a fight over the license. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
New ATA driver and crash dumps
My machine panicked today for the first time since switching to the new ATA drivers, and I noticed that I no longer have crash dumps. Is this something that is expected to be put back in soon? I know Søren's a busy guy, and I'm glad we have the results of his work. I just hope the old drivers don't get killed off until the replacement has the same functionality. Then again, wddump() is only 100 lines of code, so I should probably try to fix it myself before whining. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
/etc/hosts.allow
Why are we installing a hosts.allow with live entries in it? Why are we allowing the people at mydomain.com (MyInternet Services in Seattle) access to sendmail, while blocking the currently-non-existant d00d.org and spamnest.org from various services? I think it would make sense to have sample entries commented out (the addition of ALL : ALL : allow at the top is not quite the same). It may also make sense to use reserved domains like example.com. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
UPDATING needs updating
Mightn't it be a good idea to mention the egcs move in /usr/src/UPDATING? -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: UPDATING needs updating
On Fri, Apr 09, 1999 at 03:54:27AM +0200, Sheldon Hearn wrote: On Thu, 08 Apr 1999 14:24:19 -0400, Christopher Masto wrote: Mightn't it be a good idea to mention the egcs move in /usr/src/UPDATING? Now that both bootstrapping and -j8 seem to be working, it wouldn't be very useful. Not very useful to tell people about the first major compiler change in years? It may not break make world, but it certainly breaks things like C++ library compatability and a large part of the ports collection. Suprises should be documented. -current users should be reading -current, but that doesn't mean someone might not join after the egcs discussion. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: was: some woes about rc.conf.site
On Tue, Feb 09, 1999 at 10:11:48PM +, Adrian Wontroba wrote: On Sun, Feb 07, 1999 at 03:14:22PM -0500, Christopher Masto wrote: I haven't used it yet, but I definately think the idea is an improvement. I hate trying to update /etc after an upgrade.. if it's been a while, or it's between major versions, it can take a very significant amount of time. Have you tried the mergemaster port for this? It greatly speeds the task. Yes, I have. It doesn't make much of a dent in the real problem, which is separating diffs like: - portmap_enable=YES# Run the portmapper service (or NO) + portmap_enable=YES# Run the portmapper service (or NO). from - portmap_enable=NO # Run the portmapper service (or NO). + portmap_enable=YES# Run the portmapper service (or NO). from portmap_enable=YES# Run the portmapper service (or NO). + portmap_flags=# Flags to portmap (if enabled). ad infinitum. The latest compromise is still good enough for me. I just don't want to go back to having to edit the same file that I have to upgrade. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: was: some woes about rc.conf.site
I haven't used it yet, but I definately think the idea is an improvement. I hate trying to update /etc after an upgrade.. if it's been a while, or it's between major versions, it can take a very significant amount of time. Anything that moves local changes to a seperate file is a blessing. Also, having had sysinstall destroy my /etc/rc.conf on more than one occasion, I am grateful to not have it touched any more. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Floppy Tape Driver.....
I have an Exabyte Eagle TR-3 drive, and I had a look at the floppy tape situation a while back. The driver is.. well.. inadequate. It makes a lot of assumptions that are quite a few years incorrect. But they're probably still needed if someone has those old drives. New drives come in all sorts of configurations and can be queried for the correct parameters, among other differences. Also, it's weirdly split into kernel and user-level parts, and makes no attempt whatsoever to pretend to be a proper Unix tape. I was going to fix all of this a while back, and I still have the pile of documentation on how floppy tape works. I think I planned to write a standard QIC header at the beginning of the tape and fake up SCSI-like behavior (end of file marks, etc.). Hackers have bizzare motivations sometimes, and my motivation for this project was to back up my machine so I could install it anew. Unfortunately, it's now been so long that I really have to reinstall _before_ I'd want to start on such a thing. And I'm not sure I care anymore. I certainly don't have the free time for some time to come. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
On Fri, Jan 29, 1999 at 06:28:46PM -0500, Bill Paul wrote:
- Change the if() clause so that it looks like this:
if (sc-pn_promisc_war /* ifp-if_flags IFF_PROMISC*/) {
(In other words, comment out the test for the IFF_PROMISC flag.)
This will enable the workaround all the time and allow the receiver bug
to be detected and handled properly.
Compile a new kernel with this change and see if the problem persists.
Report back your findings (one way or the other) so that I'll know if
I should modify the code in the repository.
I'm sad to say, this didn't solve the problem. It still happens
exactly as before, and still goes away immediately if I run a tcpdump
on another console (but not if I do tcpdump -p).
I did add a printf when pn_promisc_war is set to 1 just to make sure
that it was being properly detected and turned on, and it is.. but
enabling the workaround all the time doesn't seem to help.
--
Christopher MastoDirector of Operations NetMonger Communications
ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net
Good tools allow users to do stupid things. -- Clay Shirky
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Network/ARP problem? Maybe pn driver?
snd0: SoundBlaster 16 4.13 sbmidi0 at 0x330 on isa snd0: SoundBlaster MPU-401 imasks: bio c008c040, tty c007109a, net c007109a BIOS Geometries: 0: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 1: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 2: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 3: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 4: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 5: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 6: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 7: 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 0 accounted for Device configuration finished. IP packet filtering initialized, divert enabled, rule-based forwarding enabled, logging limited to 100 packets/entry bpf: tun0 attached bpf: sl0 attached bpf: ppp0 attached new masks: bio c008c040, tty c007109a, net c007109a bpf: lo0 attached IP Filter: initialized. Default = pass all, Logging = enabled Considering MFS root f/s. No MFS image available as root f/s. Considering FFS root f/s. changing root device to wd0s2a wd0s1: type 0xb, start 63, end = 8193149, size 8193087 : OK wd0s2: type 0xa5, start 8193150, end = 12594959, size 4401810 : OK ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates By the way, it's running: FreeBSD 4.0-CURRENT #1: Sun Jan 24 23:39:56 EST 1999 But I had the same problems with a 3.0-CURRENT snapshot (I upgraded it in case this problem had already been fixed). This machine is not mine; I will only have access to it for another week or so, but during that time I will be able to do any testing or diagnostics needed. I'd appreciate any ideas or suggestions. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
On Fri, Jan 29, 1999 at 02:52:07PM -0800, Bill Fenner wrote: Can you run a tcpdump arp on the machine that is having the problem, as well? This could help to determine if it's a driver problem (e.g. if the replies don't show up) or an ARP problem (e.g. if the replies do show up but arp doesn't use them). Good idea. Hmm. Running tcpdump seems to make the problem go away. The ARP replies show up immediately appear in the table. Clue. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
On Fri, Jan 29, 1999 at 06:02:16PM -0500, Alfred Perlstein wrote: On Fri, 29 Jan 1999, Christopher Masto wrote: I hope I'm not just being really stupid, but I think there's a problem somewhere. If it's a configuration error on my part, then I think I'd better take a vacation, considering what my job is supposed to be. Anyway, I have a machine that is exhibiting a weird network problem. My guess is that ARP is not working, or perhaps something that ARP depends on (broadcasts?) is not working. i didn't see your netmask's, can you show me those please? on the broken box, and on one of the working boxes? Yes, sorry.. I accidentally deleted that part of the message. Here's the broken box: pn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 209.54.21.233 netmask 0xff00 broadcast 209.54.21.255 ether 00:a0:cc:3b:66:51 media: 10baseT/UTP half-duplex supported media: autoselect 100baseTX full-duplex 100baseTX half-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP 10baseT/UTP half-duplex And here's a working one: ep0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet 209.54.21.199 netmask 0xff00 broadcast 209.54.21.255 ether 00:60:97:a3:63:e6 The 255.255.255.0 netmask is correct here, despite the router being at .129. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Network/ARP problem? Maybe pn driver?
On Fri, Jan 29, 1999 at 06:28:46PM -0500, Bill Paul wrote: Hmm. Running tcpdump seems to make the problem go away. The ARP replies show up immediately appear in the table. Clue. You should have tried that first. I'm sorry. I ran tcpdump on a different host precisely because I didn't want to interfere with the problem and make it harder to debug. I overlooked the obvious. There's something I'd like you to try for me. (Don't delay in trying this; I've had a long string of people who appear suddenly, complain about a problem of some sort, then vanish before I can extract enough information from them to find a solution.) I have been active with FreeBSD for the past four years. I have not appeared suddenly, nor do I intend to vanish. The delay in responding to your message is solely a result of a dinner party I had to attend. I was menaced by a bug in the PNIC's receive DMA operation which, according to all my tests, only appeared in promiscuous mode. I devised a workaround, however it's only enabled when the IFF_PROMISC flag is set on the interface. Running tcpdump (without the -p flag) places the interface in promiscuous mode and enables the workaround. Given what you've said, it's possible that we need to enable the workaround all the time, not just in promiscuous mode. I would say you're quite right, considering the result of tcpdump -n -p arp: 20:32:36.302468 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:36.303175 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:37.310842 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:37.311563 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:38.320858 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:38.321579 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:39.330866 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:39.331600 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:40.340883 arp who-has 209.54.21.129 tell 209.54.21.233 20:32:40.341581 arp who-has 209.54.21.129 tell 209.54.21.233 Run again without -p, and voila: 20:33:30.232549 arp who-has 209.54.21.129 tell 209.54.21.233 20:33:30.233301 arp reply 209.54.21.129 is-at 0:e0:b0:e2:bc:79 Do me the following: - Bring up /sys/pci/if_pn.c in your favorite editor. [...] Compile a new kernel with this change and see if the problem persists. Report back your findings (one way or the other) so that I'll know if I should modify the code in the repository. I will have the results for you by tomorrow. Thank you very much for your assistance. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
On Fri, Jan 29, 1999 at 01:25:07PM +1100, Bruce Evans wrote: yeah but not a SINGLE person has said to not commit the patch to style(9) Of course I object. My mail system appears to have accidentally deleted your excellent and well-considered reasons for not allowing style(9) to say it's OK to use extra braces or parenthesis when it makes your code more comprehensible. Perhaps you could repeat it? so I'm going to do it later tonight.. If you commit it, then I will back it out. This list is getting almost as bad as perl5-porters. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
On Fri, Jan 29, 1999 at 02:26:51PM +1100, Bruce Evans wrote: My mail system appears to have accidentally deleted your excellent and well-considered reasons for not allowing style(9) to say it's OK to use extra braces or parenthesis when it makes your code more comprehensible. Perhaps it is in some of your backups from 5 years ago. Perhaps you could repeat it? style(9) is supposed to document KNF. It is not supposed to document best coding practices, julian's preferences or bde's preferences. So kernel code should not follow best coding practices (remember, the current style guide says Don't use parenthesis unless they're required for precedence). It should be a _restriction_ on FreeBSD code (and not just kernel code: This file specifies the preferred style for kernel source files in the FreeBSD source tree. It is also a guide for preferred user land code style. ) that parenthesis are not allowed, even if they aid readability and maintainability, just because they are not required for precedence. The document is in error one way or the other. It calls itself a style guide, starts out using the word preferred, and contains lots of dos and don'ts. If it is going to make coding style suggestions, they should be useful suggestions. Parenthesis are allowed to make your code easier to read, even if not strictly required by the compiler is a much more useful suggestion than what is currently there. If it's not making coding suggestions, then it should not use words like do and don't, and the introduction should be rewritten. And in my opinion, it should then be deleted because it would be of no value. Not everyone comes to FreeBSD with the same background and expectations. People WILL read a document called FreeBSD Style Guide and expect that it DOES contain best coding practices, or at least the preferences of the FreeBSD core team. Such a document should either not be provided, peppered with disclaimers about its purpose, or (IMHO preferably) contain correct recommendations. The inertia here sometimes is truly astounding. The apparent infallability of code and historical documents anyone tries to update suggests that the Pope was involved with CSRG. Encouraging unreadable code is something I find highly questionable. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
On Thu, Jan 28, 1999 at 09:39:36PM -0700, Nate Williams wrote: Encouraging unreadable code is something I find highly questionable. I find the KNF style highly readable. As a matter of fact, I find the extra parentheses *often* to be a bunch of noise. And, as Bruce implied, if you don't know your precedence rules, you shouldn't be doing kernel programming. Then either delete the style guide or write DO NOT READ THIS UNLESS YOU ARE AN APPROVED KERNEL PROGRAMMER at the top. Look, I program mainly in perl. I know the difference between readability and noise. I know when it works just fine but it's making trouble for those who come after you. And I know the difference between a clever hack and a critical piece of production code. Programming, particularly for a widely-used piece of critical system software, should not be centered on showing off your incredible prowess with precedence rules. Don't put unnecessary parens and braces in your code if you don't want to. But if someone feels that an expression is complicated enough to deserve giving the next person to look at it a few hints as to its intended order of operations, then please don't say they're not allowed to do so. Even the great Berkeley gods have made mistakes. Anything that helps avoid those mistakes, including -Wall, or extra parens and braces just to make it more obvious what you're doing, is a good thing. It means that FreeBSD will have fewer errors, fewer panics, and bugs will be found more quickly. Correct software is becoming an endangered species these days. When a proposal is made that has no effect other than to allow a tiny bit of freedom in the direction of enhanced correctness and maintainability, please don't stand in the way. As for noise, there are situations where excess punctuation is just noise, and there are situations that benefit from more than the bare minumum of decorations. Anyone doing kernel programming ought to know the difference, just as they ought to know their precedence rules. And there's always peer review for mere mortals who actually still have peers. I end with someone else's style guide, if only because of my evil streak: o Just because you CAN do something a particular way doesn't mean that you SHOULD do it that way. [...] Along the same lines, just because you CAN omit parentheses in many places doesn't mean that you ought to: return print reverse sort num values %array; return print(reverse(sort num (values(%array; When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. Even if you aren't in doubt, consider the mental welfare of the person who has to maintain the code after you, and who will probably put parentheses in the wrong place. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE DMA works, I'll be a...
Well, now I'm plenty confused. I wasn't aware that IDE DMA didn't work, so this subject line caught me a bit by suprise. Maybe I just have supported hardware everywhere, or maybe I'm missing something and I don't even know it. Or maybe I'm just posting this for comparison purposes. I know that this 2.5-year-old machine has an Asus motherboard of some sort: FreeBSD 4.0-CURRENT #1: Sun Jan 24 02:49:52 EST 1999 r...@lion-around.at.yiff.net:/usr/local/usr-src/sys/compile/LION-AROUND Timecounter i8254 frequency 1193182 Hz CPU: Pentium/P54C (166.19-MHz 586-class CPU) Origin = GenuineIntel Id = 0x52c Stepping=12 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 100663296 (98304K bytes) config quit avail memory = 94875648 (92652K bytes) Preloaded elf kernel kernel at 0xf02d9000. Probing for devices on PCI bus 0: chip0: Intel 82439 rev 0x03 on pci0.0.0 chip1: Intel 82371SB PCI to ISA bridge rev 0x01 on pci0.7.0 ide_pci0: Intel PIIX3 Bus-master IDE controller rev 0x00 on pci0.7.1 [...] wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa wdc0: unit 0 (wd0): WDC AC32500H, DMA, 32-bit, multi-block-16 wd0: 2441MB (4999680 sectors), 4960 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): CD-ROM CDU311/3.0i, removable, accel, dma, iordis acd0: drive speed 1378KB/sec, 128KB cache [...] wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa wdc1: unit 0 (wd2): Maxtor 91008D7, DMA, 32-bit, multi-block-16 wd2: 9617MB (19696320 sectors), 19540 cyls, 16 heads, 63 S/T, 512 B/S On the old wd0 that I got with the machine: $ time dd if=/dev/zero of=test2 bs=32k count=1024 1024+0 records in 1024+0 records out 33554432 bytes transferred in 5.177823 secs (6480413 bytes/sec) dd if=/dev/zero of=test2 bs=32k count=1024 0.03s user 2.08s system 28% cpu 7.458 total $ time dd if=/dev/rwd0 of=/dev/null bs=32k count=1024 1024+0 records in 1024+0 records out 33554432 bytes transferred in 4.064697 secs (8255088 bytes/sec) dd if=/dev/rwd0 of=/dev/null bs=32k count=1024 0.00s user 0.14s system 3% cpu 4.070 total And on the brand spanking new Maxtor UltraDMA happy happy: $ time dd if=/dev/zero of=test2 bs=32k count=1024 1024+0 records in 1024+0 records out 33554432 bytes transferred in 3.073696 secs (10916640 bytes/sec) dd if=/dev/zero of=test2 bs=32k count=1024 0.01s user 2.26s system 72% cpu 3.124 total $ time dd if=/dev/rwd2 of=/dev/null bs=32k count=1024 1024+0 records in 1024+0 records out 33554432 bytes transferred in 2.521986 secs (13304765 bytes/sec) dd if=/dev/rwd2 of=/dev/null bs=32k count=1024 0.00s user 0.13s system 5% cpu 2.528 total Just out of curiosity, I compared with a machine with what was at the time an expensive SCSI controller. Same CPU as mine. FreeBSD 2.2.7-STABLE #0: Sat Aug 8 22:38:59 EDT 1998 [...] ahc0 Adaptec 3940 Ultra SCSI host adapter rev 0 int a irq 9 on pci1:4:0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16 SCBs (ahc0:0:0): SEAGATE ST34371W 0484 type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4148MB (8496884 512 byte sectors) $ time dd if=/dev/zero of=test2 bs=32k count=1024 1024+0 records in 1024+0 records out 33554432 bytes transferred in 3.393906 secs (9886671 bytes/sec) dd if=/dev/zero of=test2 bs=32k count=1024 0.04s user 1.33s system 40% cpu 3.411 total $ time dd if=/dev/rsd0 of=/dev/null bs=32k count=1024 1024+0 records in 1024+0 records out 33554432 bytes transferred in 3.525452 secs (9517767 bytes/sec) dd if=/dev/rsd0 of=/dev/null bs=32k count=1024 0.03s user 0.12s system 2% cpu 5.330 total The bleeding edge and I have a pretty good relationship. I haven't been bitten by softupdates, IDE DMA, or the new VM (well, I did have that panic, but the fix had already become available). Of course, I'm now running afoul of 4.0-related libtool breakage in the ports collection, but it's not exactly a mystery to fix. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Running 4.0, a few weirdies
I just finished a make world and kernel build from sourced cvsuped at around Jan 23, 21:00 EST. There were no build problems, and I saw the crypt backout was in, so I installed it. System seems to be working so far, but with the following suprises: The old unable to mount /, specified device does not match root device on booting. My /etc/fstab had (working with -current from just a few weeks ago): /dev/wd0s1a / ufs rw 1 1 I thought this was the new world order.. apparently not. I had to change it back to: /dev/wd0a / ufs rw 1 1 Mucking with the kernel config file's root on xxx didn't seem to make any difference. I didn't see anything about this change in /usr/src/UPDATING, and I must have missed its mention on this list. After fixing that, I ran into problems with libcrypt. Specifically, everything seems to be linked against libcrypt.so.3 insert pause as I get distracted, go to look at something with Netscape, and experience lockup, assuming kernel panic.. back to the old kernel for now Ahem. As I was saying, everything (well, login, su, cvs, perl, etc.) seems to be linked against libcrypt.so.3, but there was no such version installed. I have in /usr/obj/..blah../tmp/usr/lib: lrwxr-xr-x 1 root wheel 13 Jan 22 19:58 libcrypt.a@ - libexpcrypt.a lrwxr-xr-x 1 root wheel 14 Jan 22 19:58 libcrypt.so@ - libexpcrypt.so lrwxr-xr-x 1 root wheel 16 Jan 22 19:58 libcrypt.so.2@ - libexpcrypt.so.3 lrwxr-xr-x 1 root wheel 16 Jan 22 19:58 libcrypt.so.3@ - libexpcrypt.so.3 But in /usr/lib: lrwxrwxrwx 1 root wheel 12 Oct 5 08:39 /usr/lib/libcrypt.so@ - libscrypt.so lrwxrwxrwx 1 root wheel 14 Oct 5 08:39 /usr/lib/libcrypt.so.2@ - libscrypt.so.2 Which would seem to explain how it happened, but obviously installworld doesn't put these into /usr/lib.. all the other libraries have current timestamps. Speaking of timestamps.. when I booted the new kernel, my clock came up wrong. Really confused me when I reconfigured the kernel and make said it was up to date. Somehow it had gone back about 20 hours. I ntpdated it back to normal, but next time I rebooted, it had gone ahead a couple of hours. I've now booted my week-old kernel, and the time was not altered. That's all that I noticed. I will try another update to get Matt's vm fix.. if it still panics, I'll get a proper backtrace. And yes, I'm using INVARIANTS. -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Running 4.0, a few weirdies
On Sun, Jan 24, 1999 at 03:46:53AM -0500, Christopher Masto wrote: That's all that I noticed. I will try another update to get Matt's vm fix.. if it still panics, I'll get a proper backtrace. And yes, I'm using INVARIANTS. Well, I resupped and rebuilt, and did the thing that crashed it before, and it didn't crash this time. Not a very interesting machine, but everything seems to work. (I just need to remember to put the AWE32 pnp stuff in /kernel.config or wherever it belongs.) Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Sun Jan 24 02:49:52 EST 1999 r...@lion-around.at.yiff.net:/usr/local/usr-src/sys/compile/LION-AROUND Timecounter i8254 frequency 1193182 Hz CPU: Pentium/P54C (166.19-MHz 586-class CPU) Origin = GenuineIntel Id = 0x52c Stepping=12 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 100663296 (98304K bytes) config quit avail memory = 94875648 (92652K bytes) Preloaded elf kernel kernel at 0xf02d9000. Probing for devices on PCI bus 0: chip0: Intel 82439 rev 0x03 on pci0.0.0 chip1: Intel 82371SB PCI to ISA bridge rev 0x01 on pci0.7.0 ide_pci0: Intel PIIX3 Bus-master IDE controller rev 0x00 on pci0.7.1 vga0: S3 ViRGE VX graphics accelerator rev 0x02 int a irq 11 on pci0.12.0 Probing for PnP devices: CSN 1 Vendor ID: CTL00c1 [0xc1008c0e] Serial 0x0dc2a4bc Comp ID: PNPb02f [0x2fb0d041] Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model NetScroll Mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A ppc0 at 0x378 irq 7 on isa ppc0: W83877F chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold nlpt0: generic printer on ppbus 0 nlpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 plip0: PLIP network interface on ppbus 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa wdc0: unit 0 (wd0): WDC AC32500H, DMA, 32-bit, multi-block-16 wd0: 2441MB (4999680 sectors), 4960 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): CD-ROM CDU311/3.0i, removable, accel, dma, iordis acd0: drive speed 1378KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa wdc1: unit 0 (wd2): Maxtor 91008D7, DMA, 32-bit, multi-block-16 wd2: 9617MB (19696320 sectors), 19540 cyls, 16 heads, 63 S/T, 512 B/S 1 3C5x9 board(s) on ISA found at 0x300 ep0 at 0x300-0x30f irq 10 on isa ep0: utp[*UTP*] address 00:60:97:a3:63:e6 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface apm0 not found sb0 at 0x220 irq 5 drq 1 on isa snd0: SoundBlaster 16 4.16 sbxvi0 at drq 5 on isa snd0: SoundBlaster 16 4.16 sbmidi0 at 0x330 on isa snd0: SoundBlaster MPU-401 awe0 at 0x620 on isa AWE32: not detected Intel Pentium detected, installing workaround for F00F bug IP packet filtering initialized, divert enabled, rule-based forwarding enabled, logging limited to 100 packets/entry IP Filter: initialized. Default = pass all, Logging = enabled ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates -- Christopher MastoDirector of Operations NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Good tools allow users to do stupid things. -- Clay Shirky To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
