Re: Waaaarg, we just blew out the kernel again..
> On Tue, 18 Dec 2001, Gerhard Sittig wrote: > > > bzip2 has been around for a while and has been shipped since > > 4.4-RELEASE. :) When I see the constant "who put another > > three KB into the kernel and thus broke release?" against the > > "9KB plus for the loader versus 40KB gain for the kernel" > > switching to bzip2 should give some room to breath(sp?). > > Is there much difference in speed between the compression methods? That > is, would bzip2 be an issue on older, low-spec machines? bzip2 is expensive in the compression pass; I don't think decompression is much different though. btw, thanks to Gerhard for pointing out that I don't pay close enough attention to my commit mail. 8) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: WARNING: loader(8) metadata is missing!
> This is the message that popup just before the kernel load, and at the beginn > ing of the boot process, > there is another strange message "no /boot/loader". > > Do you know what does it mean? It means you deleted, renamed or moved /boot. Don't do that. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: DLS360 and SMP
> > Just got my hands on a brand new DL360 from compaq. (Dual 1G Procs with > a gig of ram). Loaded FreeBSD 4.4 on it from the CD and made a custome > SMP kernel and low and behold it hangs at the APIC_IO. "hangs at the APIC_IO" doesn't mean anything. Copy the last few lines of kernel output if you want to convey any useful information. > My question is will a CVSUP fix this? No. The DL360 works fine (I have one next to me right now making an awful racket). You probably just need to update the BIOS and set it up correctly (try setting the OS for 'Linux' or 'Unixware 7'). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: rl driver: need help in adding new chipset
> However, when the computer boots with the new kernel, even though it > recognizes the chip, it tells me: It's recognising the chip because you've told it to. But it looks like there are more differences than just the ID. > rl0: port 0x6000-0x60ff mem 0xe000-0xe000 > 00ff irq 11 at device 18.0 on pci0 > rl0: Ethernet address: 04:20:00:00:15:10 > rl0: unknown device ID: 0 > device_probe_and_attach: rl0 attach returned 6 > > or on another boot: > > rl0: port 0x6000-0x60ff mem 0xe000-0xe000 > 00ff irq 11 at device 18.0 on pci0 > rl0: Ethernet address: 00:02:01:41:00:43 > rl0: unknown device ID: 1000 > device_probe_and_attach: rl0 attach returned 6 > > Notice that both the 'unknown device ID' and the ethernet address > changes... Sounds like the device is not directly compatible. You're probably going to have to go find out what else is different. The Linux driver may be a good place to start, or if you're lucky, Realtek may have some datasheets you can look at. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4-rc4 Install hangs on RAID controller
I haven't been able to do any testing for the 4.4 release, unfortunately; time simply hasn't been available. However, the controller should work. Make sure that it's not in I2O mode, and that the array is not degraded or rebuilding. > I'm attempting to install FreeBSD-stable on a Micron NetFRAME 3100 - it is a > dual Pentium II with an AMI MegaRAID Express controller. Looking at the > sources for the amr driver, this card (Series 762) appears to be supported. > > However, while booting from the install CD, the controller is detected > properly but the boot process stops once the logical disk is reported. An > install without the RAID controller works fine. > > So, are only specific firmware versions of this controller supported ? Is > there some option on the controller I need to adjust ? > > Any help is appreciated. > > Thanks, > Craig > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: New kernel option CPU_ENABLE_SSE
> >> Because not all i686'es support SSE. > > > >So detect it automatically based on the CPU feature bits. > > > >Needing a kernel compile option for this is unforgivably lame. If you > >want to be able to disable it, use a tunable. > > Perhaps; the "gist" I get is that the compile option is for > some "field-testing." Maybe similarly appropriate would be > something similar to "NO_F00F_HACK"; for example, > "CPU_DISABLE_SSE" or "CPU_NO_ENABLE_SSE" (?). All of this stuff is unforgivably lame. Tunables. Tunables. Dammit. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: New kernel option CPU_ENABLE_SSE
> > --R+My9LyyhiUvIEro > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Thu, Aug 16, 2001 at 04:20:35PM -0400, Kenneth W Cochran wrote: > > > Assuming CPU_ENABLE_SSE is a Good Thing, why not make it > > "default" with the "cpu I686_CPU" kernel config directive > > (similar to F00F_HACK auto-include with I586_CPU)? > > Because not all i686'es support SSE. So detect it automatically based on the CPU feature bits. Needing a kernel compile option for this is unforgivably lame. If you want to be able to disable it, use a tunable. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: PERC 3 Dell 2500 and FreeBSD 4.3 stable
> Hope this helps others on Dell, it would be great to get Dell to > offers these controllers instead of those crappy PERC controllers, but > these I guess are too expensive??? There's not much more subjective than RAID controllers, except perhaps text editors. 8) I'm glad you're happy with the DPT controllers, but the other Adaptec controllers you're bashing are actually quite widely liked, and when they're working, they do perform noticeably better... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: pnpbios: Bad PnP BIOS data checksum
> What's mean "pnpbios: Bad PnP BIOS data checksum" ? It means that your PnP BIOS data has a bad checksum. We don't trust it in this case. Some vendors don't bother to compute the checksum for this structure; we are more conservative than Microsoft, and refuse to use the PnP BIOS in this case. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD 4.3 and 6G RAM
> So, someone wanting to implement this in FreeBSD isn't starting from > square one? That depends on how you number your squares. > Can the NetBSD stuff be fairly easily ported to FreeBSD, or is their VM > system too funky? It's just different. But no, the NetBSD work doesn't immediately translate. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Slow response time
> Hi, > I am following 4.3-stable since I did a CD-ROM install of 4.3-release. A > few weeks ago I did build the world which succeeded in my opinion. > Additionally I upgraded to XFree86 4.1.0_4 and KDE 2.1.1. The problem is > that now sometimes the x-server takes ages to come up after 'startx' and > sometimes applications within X, like Xemacs or even a simple terminal, > take a lot of time to come up, too. Sounds like DNS lookups. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Why is the STABLE branch not so stable anymore?
> On 11-Jun-2001, Jordan Hubbard wrote: > > Hmmm. It seems like this thread has degraded to simple > > project-bashing so I'll not be a party to keeping it on life support > > any longer. > > I don't think this is the case at all. For whatever it's worth, it > doesn't appear that the stability of -stable is the same priority it > used to be. It's hardly project-bashing to raise concerns of this > nature on the -stable mailing list. When the concerns are unsubstantiated, and in fact just plain wrong, then yes, it becomes plain project-bashing. To answer the original questions: no, there has been no degradation of concern over the stability of -stable recently, nor are there any plans for such a thing to happen. There have been a few mishaps, as can be expected in any engineering project, and they're being dealt with as best and expediently as they can be. Please consider the amount of work being put in to ensure that -stable isn't broken on a regular basis, and contrast this against the amount of work going on there in general and the relatively small amount of breakage that does occur. No, it's not nice when it happens, but folks, the problem you're panicking about simply doesn't exist. 8) The sky isn't falling, ok? If you want to help improve the stability of -stable, the right way is to get involved in the feedback process. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FORTH: Modifying loader...
> I've been waiting for a FORTH-geek to pop his head up; I > have most of "nextboot" reimplemented... I've added "fwrite" > and "flseek" verbs. I've thought about kidnapping an > astronomer. 8-). > > The current problem is that the biosdisk.c doesn't contain > "write" code, and that the libstand code wouldn't call it > if it did. > > I'm not really interested in creating or extending files, > and with those restrictions, it seems possible to do the > job. > > Is anyone interested in helping out with the code? I've wanted someone to fix the libstand filesystems to support overwrite for some time, so yes, I'd be happy to help here. > The basic plan is to take a file that has: > > "A A A B B B\n" > > and rewrite it as: > > "A A B B B A\n" > > (a rotor; slightly different than the original nextboot, > but acceptable, given the constraint of keeping the file > exactly the same length), and then use the first string > "A" (might be "disk1s1a:/kernel") to set curr_dev to the > "disk1s1a:" part, and then try to boot the "/kernel" part. I actually had a fairly different and more generic idea in mind; an 8k "boot.variables" file in /boot, which holds variables marked with 'save '. So you would do something like: set kernel_list="kernel.new,kernel.default,kernel.emergency" set kernel_index=0 save kernel_list save kernel_index to set things up. If the format of the file was sensible, manipulating it from userspace would be trivial as well. > I'll write the user space utility, and I'm willing to do > the UFS code as well, but it's been 15 years since I've > done FORTH, and I'm not too confident of the VM86 calls > in biosboot.c for writing, either. I can't help with the FORTH, but I certainly know what needs to be done in biosdisk.c. Note that the SRM equivalent can't write to the disk, so this *won't* work for the Alpha. 8( Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: CS4232 with pcm driver returns device_probe_and_attach: pcm0 attach returned 6
>
> If I specify
>
> device pcm0 at isa? port 0x534 irq 7
>
> I get:
>
> mss_detect, busy still set (0xff)
> pcm0 failed to probe at port 0x534-0x53b irq 7 on isa0
>
> with
>
> device pcm0 at isa? port? irq? drq1 flags 0x15
You *should* just be able to use the PnP BIOS. However:
> pnpbios: Bad PnP BIOS data checksum
Try ignoring the PnP BIOS checksum error (yes, believe it or not, some
people either can't add, or can't be bothered to, and you wonder why PC
systems have a reputation for being crap?).
/sys/i386/i386/bios.c:
127 }
128 /* If checksum is OK, enable use of the entrypoint */
129 if (ck == 0) {
Change this to if (1) {
130 PnPBIOStable = pt;
131 if (bootverbose) {
and just put
device pcm
in your kernel config, and see how that goes.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
proc->pstats / SIGVTALRM
In fielding a question from someone regarding what appears to be SIGVTALRM sniping on their system, I noticed that the pstats structure (which holds the p_timer fields which are used to track interval timers) is outside the bzero-on-allocation region of the proc structure. Thus it seems to me that it would be possible for garbage to be present in these fields, leading to possible spurious generation of this signal. Can anyone point out where I'm mistaken here? Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 3ware & mysql, again
> Mike Smith writes: > > > > > > I recall something about this on another FreeBSD list a week or so ago. > > > Supposedly there is a firmware update available that fixes this problem. > > > > It's not clear whether Raymond is talking about the same symptoms or not > > (as he doesn't clarify this). It's not certain that 3ware have actually > > fixed the problem yet; last I heard they were still working on it. > > Hum. Ok. The actual error messages (from dmesg and > /var/log/messages) were of the form > "twe0: command failed - device failure". At this point it was > impossible to do *anything* to the filesystem(s) on the disks > connected to the 3ware controller. This is a totally different and unrelated failure. It's not clear what is going wrong here though; I'll have to ask 3ware what this suggests. > I've looked at 3Ware's web site, and they claim that the new > firmware (version 6.6) fixes certain problems with RAID 5 > configurations. My configuration is RAID 0, so it is entirely possible > that the new firmware will have no effect for me. The RAID 5 issue is not related to this (and does not affect FreeBSD). > Version 6.6 supposedly requires an updated driver - is the > driver in -stable so updated? If so, I'll go ahead and backup my data > and upgrade the firmware. No driver changes are required. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Running Stable on remote production server
> I have been reading the instructions for tracking stable and what is > recommended in the way of procedures. It seems from this that it would be > extremely hard to follow these recommendations for a remote POP. IE moving > to single user mode and on the whole messing with the machine for several > hours at a time. It's entirely unnecessary to go single-user when updating a machine; just rebuild the world, optionally run mergemaster, and reboot. Exceptions to this rule do occur, but they're *extremely* rare. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: CFLAGS Optimization
> :: The risk is the same in Linux; they both use gcc, and it's gcc which > :: has the optimizer bugs. It's more common to use absurd gcc > :: optimizations in the Linux community for some reason (perhaps they're > :: used to code misbehaving, so additional brokenness from the gcc > :: doesn't add much ;-) > :: > :: Just Say No. > > Hrrmm... that's tantamount to saying Linux and FreeBSD has a fundamentally > b0rken compiler. It would be more accurate to say that Linux and FreeBSD have a compiler with optimiser bugs, but that's widely known. Don't sound so surprised. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: mylex dac960pl and FreeBSD 4.3 - bus_dmamap_load
> Hmm, I just went through all of the mlx related files and none of them > changed between 4.2-RELEASE and 4.3-RELEASE. So it looks like there is > something more sinister going on. This is a known problem. I don't know what's up, and I can't reproduce it (as I don't have any of these cards). I suspect that it may be an issue with non-page-aligned I/O and the very limited scatter-gather that these cards support. You might try overriding the assignment in mlx_disk.c: 279 dsk->si_iosize_max = imin(s1, s2); and change it to eg. (8 * PAGE_SIZE) instead to see if this masks the problem. > -gordon > > On Mon, 7 May 2001, Matt Groener wrote: > > > I have been trying to get anyone to respond to this issue as well. > > I have offered both my time and the fact that I own many many Mylex > > cards and would be happy to test, mail them out, perform magic > > tricks, etc., to get some assistance. > > > > Greg Loomis (of vinum fame) helped me out with a problem with > > Mylex RAID's and vinum, only to have it fail again at this point. > > (He is not responsible for this error or Mylex drivers; I only > > mention this because he bailed me out last minute and then I still > > got stuck with this driver issue, which was a bummer for me). > > The problem is confirmed to not be present at 4.2-RELEASE. I have > > back-ported Greg's fix for 4.2-RELEASE to get around the Mylex > > problem for the time being. > > > > I am not using the Mylex card as a boot device if that is of concern. > > > > I only have Mylex cards with 2.73 firmware or lower (they are mostly > > scavenged cards from Alpha's now running in Intel chassis). It is possible > > that others do not experience with problem with other Mylex cards besides > > the 960's, or with newer firmware. > > > > Anyone comment on what has changed, or can the Mylex driver maintainer > > (looks to be msmith?) offer any thoughts for us stuck with cards that no > > longer work? > > > > Thanks, > > -matt > > > > > > On Sun, 6 May 2001, Paul Murphy wrote: > > > > > Jacek Jêdrzejczak wrote: > > > > > > > > > > > mlx0: DAC96PL, 2 channels, firmware 2.73-0-00, 4MB > > > > mlxd0: on mlx0 > > > > mlxd0: 20335MB (41646080 sectors) RAID 5 (online) > > > > > > > > No matter which installation process i choose (floppies - kern.flp & > > > > mfsroot.flp or bootable cd) i always get this error message: > > > > > > > > > > > > bus_dmamap_load: Too many segs! buf_len ðxaa0 > > > > mlx0: I/O error - attempt to write beyond end of drive > > > > > > > > > > I have the exact same machine with the exact same problem! > > > > > > I sure would like to know the answer too. > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-stable" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-scsi" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: problem booting 4.3-RC1 (BTX problem)
This is a known bug in the SRC-U21 and SRC-U31 BIOS, for which there is no solution. You cannot use these controllers with FreeBSD. > There is a problem booting 4.3-RC1 on server with Intel Server RAID > Controller U2-1(SRCU21) with logical volumes created (without > logical disks everything is OK). > > > There is BTX diagnostic: > > int=000d err= efl=00030006 eip=06ab > eax=000cc895 ebx=02900116 ecx=0004 edx=0080 > esi=3236 edi=3228 ebp= esp=03fa > cs=c900 ds=c900 es=9c80 fs=9c80 gs=9c80 ss=9abe > cs:eip=26 0f 01 14 0f 20 c0 0c-01 0f 22 c0 eb 00 b8 10 > ss:esp=0c 32 31 00 90 02 95 09-00 00 02 02 38 91 00 00 > BTX halted > > > Dmitry. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 3ware + 3dmd - how?
> Thomas> there are some hints how to install and to run the 3dmd under > Thomas> FreeBSD? I'm able to run the program, but nothing happen when > Thomas> using a browser to get information about the RAID controller. > > Mike> I suspect you haven't made the /dev/twe0 device node; > > You know, this fixed it for me too. I was having the same problem. Sorry; I really need to fix the packaging for this and spank the 3ware folks. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 3ware problems
> The first time I did this I thought something was broken when I > watched the newfs output those duplicate super block locations. It was > about 10 seconds between each block! After a search of the FreeBSD > lists I found a reference to initializing the array, and just waited. > > On ttyv1 the kernel issues a message when the array initialization is > done, so I usually just wait for that. Newfs is even more pessimal, due to the alignment fixup the driver has to perform. However, the array is perfectly usable while it's being initialised. Just. Dog. Slow. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: NatSemi network cards
> I have not been able to find any reference to this card in any compatibility > documentation for FreeBSD. Is it supported by 4.2, and if not, will 4.3 > support it? man 4 sis See also HARDWARE.TXT, which explicitly lists this card. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD 4.x and BSDi 4.x binary compatible?
> :: Actually, on the same note, I'm planning on flying a 747 jet later > :: this evening, anyone know what I should watch out for? Any tips > :: for a smooth ride? > > Yeah, don't pack the AK-47 and Semtex in the hand luggage. ;-) > > Thanks Alfie, I'll make sure to ask you next time I need some more useful > info. Actually, his point was a bit more subtle than that. You asked about binary incompatibility, but then talked about recompiling on FreeBSD. Your question was, in effect, a non sequiter; a point Alfred just tried to make clear. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: [NFS] Incompatible: FreeBSD 4.2 client, Linux 2.2.18 nfsv3 server, read-only export
> At least from looking at the Linux 2.2.18 code, if you get EROFS back > from the Linux server, the actual set of access bits you get back won't > have the right bits set; "nfsd_access()" just jumps to "out:" if it gets > a "read-only file system" error, and that doesn't set "*access" to the > result. Oh. "Joy". > If you do want to work around the Linux bug, you'd probably have to send > another ACCESS request over the wire, with the write bits turned off; > I'm not sure whether that's worth the effort or not. Based on that; no. I think if people want to run v3 against a Linux server, they will just have to turn the ACCESS cache off. In the meantime, is there any constructive way we can encourage the Linux NFS folks to fix this behaviour? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Athlon and 4.2 Release
> > I strongly suspect its an IRQ conflict. Every problem of this sort > > that I've seen with the A7V has been an IRQ conflict, including the > > problem I had with my own. Specificly I had to hard set the IRQ on my > > NIC through the PCI management section of the bios. ... > It certainly is an IRQ conflict between the 3C905B NIC and the promise > controller. I could install and reboot just fine with the NIC > removed. Er, folks, no. You can share IRQs just fine with PCI. You don't have "IRQ conflicts" just because two devices are driving the same interrupt. There are plenty of other possibilites for trouble, but having the same IRQ is not in and of itself going to do this. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: AMI MegaRAID Enterprise 1600
> harddrive while running FreeBSD. The controler reacts on this with a wild > beeping and beeping does not stop until the array has been rebuild or > checked on consistency. But there was no message of any kind of error or > drive failure or that the controler moans due some drive failures. Is this > normal or is there a special way to check this? The driver doesn't (at this point in time) have any way of reporting array status changes. I have the information necessary to deal with this to hand, but have not had time to implement it. 8( AMI also have a FreeBSD port of their MegaManager software, but I'm not sure what their plans might be with regards to releasing it. > Another question regards to the way the controler acts with its > harddrives. How can I figure out in which way the controler accesses its > drives? Means: how to check whether Ultra2/160m, FAST, Wide/Ultra Wide or > simply Ultra 16 Bit is used as protocol? The reason why I want to know > this is explained in part two ... The driver ought to be able to work this out as well. See above inre time. I don't have any answers about the remainder, I'm sorry. I'm moving right now and all my controllers are boxed, but it really does sound like you have major termination issues. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Can this really be true? FreeBSD not working on IBM T20's
> On Thu, 30 Nov 2000, Peter Lai wrote: > > So use ext2 or some other FS for your freebsd slices! > > Has anyone actually validated this as a solution? Installation using this as a technique would be very difficult. You'd also need a -current loader with ext2 support. I do not consider it a solution. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Anyone tried fresh 4.2-RELEASE buildworld ?
> > I'm stuck in a compiler error (signal 4) while trying "make buildworld" in a > > fresh 4.2-RELEASE installation. I sent a PR already, but I would like to > > know if anyone here has gotten 4.2-RELEASE fresh installed (I mean, not > > cvsup'd) and build world'd. > > It seems very much to me as if this is a local error; I've installed > 4.2 quite a few times now on various machines and not had any problems > like this, nor have I received any other reports like yours. We've actually seen a couple of reports over time that the Cyrix 166+ CPUs do this. It's never been tracked down to either a compiler/CPU interaction or an OS/CPU/chipset interaction, but it would be fair to say that a CPU swap to another model will probably get you out of the woods. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Removal of Disklabel (was: Re: Dangerously Dedicated)
> As the PC architecture requires, just use an fdisk partition rather > than a disklabel slice (slices are what UNIX vendors call them). For > that matter I'd be happy if we removed disklabel from the picture > entirely. I think that should be our goal. The architecture requires > an fdisk label and disklabel is redundant. It seems like a no-brainer > to me, just remove support for disklabel entirely. Simple and end of > argument. This is painful for lots of other reasons, and the counter-argument is that this is change for change's sake rather than change to a useful end. We also need a native disk divvying method for platforms that don't have their own (eg. Alpha). The BSD disklabel serves this purpose well. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.2-BETA hangs on boot
> i'm not entirely sure i understand. "pnp o/s = no" causes the bios > to assign an irq to the pcic controller, meaning the pcic controller > raises that interrupt on insertions/removals, but the driver, > operating in polling mode, never clears the interrupt so the machine > wedges trying to service it? if this is correct, how does ddb > manage to unwedge things? In some cases, the issue is that the interrupt generated by the bridge is level-triggered, which means that a failure to handle and clear it results in an interrupt loop. I don't know why breaking to DDB would ever fix this. If the interrupt is shared with other hardware (in your case, it appears to be shared with the UHCI controller, which is normal) then the interplay simply becomes more complex (because the failure may be due to bad behaviour in other code which responds differently when single-stepped due to timing interactions with the hardware). > the fix in -current is the pci interrupt routing code which allows > us to set "pnp os = yes" in the bios and let freebsd make irq > assignments only for devices it understands? any chance this will > MFC-ed? The "correct" fix is to improve our old and badly broken pccard/cardbus code, which is a work in progress. The interrupt routing code exists so that we can deal with bridges which don't have an interrupt correctly assigned (typically it's connected OK, but we don't know where to). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: IDE RAID?
> I'm going to install a new FreeBSD server and I'm looking into an > Ultra-ATA 100 RAID solution. You should be more worried about functionality than buzzword-compliance. ATA-100 isn't really all that important in the scheme of things here. > So far, my searches on Dejanews seem to > indicate that there are some problems with either installing FreeBSD, or > booting FreeBSD from a RAID volume. I would like to configure two hard > drives in a mirror (RAID1) config, and install and run the latest > FreeBSD-STABLE on it. I'm considering either the Abit Hot Rod 100 or the > Promise Fasttrack 100 RAID PCI cards. Does anyone have experience with > either of those? Yeah. They're not "RAID controllers" as such, they just have BIOS support for striped and mirrored configurations. If you expect the mirror to work like a "real" mirror, right now your best bet is going to be one of the 3ware cards; I'd expect that someone will improve the intelligence in the ATA RAID code at some point, but right now it's way too raw (IMO) for production use. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: i386/20379
> > On the other hand, there *is* an easy workaround to turn them off, so in > > the worst case we would have an escape route. > > > > Jordan, what's your feeling on this? I don't have a 450GX board to test > > with. 8( > > I feel it looks like a small but smelly hack and I also have bad > feelings about it. :) What's this "easy workaround to turn them off" > you're alluding to? set machdep.pci.bios="disable" in the loader disables searching for (and thus use of) the PCI BIOS interface. If you check back up the log for this PR, you'll see that an earlier respondent has indicated that the PCI BIOS code on these boards seems to DTRT where our own register-level code doesn't. Alternatively (a POLA issue, I guess at worst) I can bring it in but default it to "disable", so that people with this problem will have to set it to "enable". Then it would become an errata issue. As I mentioned elsewhere though, the PCI BIOS code has been remarkably complaint-free over the last ~6mo or so in -current... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: i386/20379
> Forwarding this to stable, as I've sent it to current by mistake.. > > At Fri, 03 Nov 2000 06:14:49 +0900, > I wrote: > > > > Would someone take a look at i386/20379, which adds support for Intel > > 450GX chipset? > > > > The fix is simple enough to get into 4.2-RELEASE. Intel 450GX used to > > be a highend chipset for servers in the PentiumPro era, and such a > > chipset should be supported by 4.2-RELEASE! :) > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=20379 The feedback on this PR is confusing. It sounds like the register-level PCI configuration space probe fails, but this is basically the same code that's in 3.x. At any rate, I am a little wary of bringing the PCI BIOS config space access functions back to 4.x so late. I should have looked at this earlier, I'm sorry. On the other hand, there *is* an easy workaround to turn them off, so in the worst case we would have an escape route. Jordan, what's your feeling on this? I don't have a 450GX board to test with. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: diskless boot failures with PXE 2.0 boot, diskless X11 Termi
> On Tue, Oct 31, 2000 at 10:26:12PM +0100, O. Hartmann wrote: > > On Tue, 31 Oct 2000, John Baldwin wrote: > > All right, I saw I was false in using bootp ... :-( > > One question about diskless booting. How to boot FreeBSD > 4.0, with out > /boot/loader to have properly libkvm working ? Typically you don't. Booting without the loader is discouraged. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: cvs commit: src/sys/dev/twe twe_freebsd.c twe_tables.h tweio.h twe.c twe_compat.h twereg.h twevar.h twe_disk.c
> > > Hi, > I just got a new batch of 3Ware 6200s I plan to deploy for RAID1 > systems. I installed the card and 2 Quantums into an existing test system > > 4.1.1-STABLE FreeBSD 4.1.1-STABLE #1: Mon Oct 30 13:42:15 EST 2000 > > i.e. post twe commits. At boot up time, I get > > twe0: AEN: > > Is this a firmware issue ? What is the reccomended firmware to work with > on FreeBSD ? It should be harmless, but you should be running the most recent firmware (6.13). There's a new version of the driver in 4.2 which should be more informative (but it still doesn't know what 0x0c means). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! MFC's
> > There are some things which are broken in -stable that need to be > fixed (alpha booting, e.g.). We'll try to leave the world a better > place for our efforts. -stable world builds, installs and boots on my pws433 as of earlier today (with dfr's ata fix). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: PERC2 RAID support in 4.1-STABLE
> > Its a shorter PCI card than the others, single channel, SCSI > > LVD. It has OK performance. I am currently using it in a > > RAID0+1 type config. > > Where can I learn more about the pitfalls? I have a model 466 > waiting to get employed (RAID5 config with three IBM drives) and > get very poor throughput in the 3MB/s range. I'm aware of the > expensive directory manipulations but even "dd if=/dev/zero > of=$FILE bs=8388608 count=..." is this slow and I don't know > where to start searching. This has been with 4.0-R and 4.1-R, > cvsup to -STABLE has just finished and results will be available > soon. The IBM drives I have play very poorly in RAID configurations. Having said that, you will want to enable write caching on both the drives and the controller for best performance. You'll also want to use the "DirectIO" option on the array. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Signal 4 while compiling 4.1.1
> I just compiled Gimp on the same system without any hitches. Other > programs as well. I also ran memory tests and verified the > motherboard's temperature via the BIOS and visually checked the fans. > > It's my belief that within the last three weeks new code was inserted > into STABLE that was never fully tested to compile on an AMD CPU. > > We now have another user who has posted a similar if not identical > problem while compiling 4.1.1 using an AMD processor. This is starting > to look like a coding problem. To paraphrase Babbage: "I an not able rightly to apprehend the kind of confusion of ideas that could provoke such a conclusion." -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: More panics (different hardware)
Please press the 'scroll lock' key to scroll upwards and report the real error message. Before you post it, take a few minutes to check the handbook section on kernel debugging and try giving us enough information to actually help you. You wouldn't ring your doctor up and say "Hey doc, I hurt" and expect him to tell you what's wrong. Why do you subject us to a comparable form of abuse? > Just as a follow up to my constant panic report on 4.1-S with my > Athlon system, I'd like to say that my Pentium 200 system has now joined > in. This P200 system has served me with 100% rock solid stability for > years. Not once has it had any weird behaviour. Anyways, the behaviour > on both systems is the same. A fault at virtual address 0x30, preceeded > by another fault which by that time has scrolled off the screen. The key > phrase here seems to be "supervisor read, page not present". > > I feel I should add here that I am a commercial unix shell > provider, and so I get the worst imaginable traffic on the internet. This > P200 box doesn't allow shell access though, since it's only a web server. > > A system with 3 bad sticks of ram, and a rock solid system > suddenly going bad? C'mon guys. Will nothing short of ECC RAM prove to > you guys the existance of a software fault? Anybody wanna lend me some? > :) (the P200 RAM is 72-pin so no, not the same kind as the Athlon's) > > BTW, 3.5-S ran fine on both systems...at least until it had to > access the large Maxtor HD in the Athlon ... which is what prompted me to > go to 4.1-S. > > Finally, for some good news. The P200 system is physically > accessible to me, so I will try to find a spare hard drive, and make some > crash dumps for the list's benefit. > > Thanks for all the responses I've gotten on this subject! They're > greatly appreciated and help me maintain my sanity. :) > > --Bart > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: cvs commit: src/release Makefile
> > I don't change change my mind (this change is not needed), but here is > yet another aspects. > > jkh> Agreed - vnconfig is supposed to load the vn module and does, > jkh> at least, in -current. > > However, this commit maybe assumes that if somebody want to do "make > release" of 5-current with 4-stable of /usr/src (oops, I have a > mistake in previous mail). > > Under such situation, vn module of 4-stable should be loaded; but > vnconfig(8) runs under chroot environment which is maybe 5-current > world. You know, loading vn.ko of *5-current* to *4-stable kernel This is actually a bug in the autoload implementation; vfsload should be doing the right thing and fetching the module from the 'true' module path, not from the build area. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Mylex adapters with 2.x firmware and "couldn't map register window"
> At 10:03 AM -0700 2000/9/21, Mike Smith wrote: > > >>4) Add the line > >> controller asr > >>to your kernel configuration file and rebuild/reinstall your kernel. > > When doing a "config -r KERNEL", I was told: > > # config -r KERNEL > Removing old directory ../../compile/KERNEL: Done. > config: line 123: Obsolete keyword 'controller' found - use 'device' > Don't forget to do a ``make depend'' > Kernel build directory is ../../compile/KERNEL Ok. I'll update the build instructions (or just integrate the damn thing as soon as we get a bug sorted out). > > Bug in the kit. Say 'touch opt_asr.h' and try again, or just use the > > module. > > Okay, will do. Note, after testing, what has to be touched is > /usr/src/sys/opt_asr.h, not /usr/src/sys/dev/asr/opt_asr.h, as I had > erroneously first thought. Actually, just touch it in the compile directory. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Mylex adapters with 2.x firmware and "couldn't map register window"
I've had a lot of requests for something to be done about this, and I've finally gotten a few minutes to make it happen. The fix for this has been committed to -stable, and there's a kit for 4.1-RELEASE users wanting to install on these adapters at http://people.freebsd.org/~msmith/RAID/mylex/mlx2_patchkit.tar.gz Note that this has only been lightly tested; the changes don't affect other adapters, but I don't have one of these adapters to test with directly (all my v2.x adapters have memory windows). I have two success reports already though, and I'd like to hear a few more. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: PNPBIOS and atkbd
> > Since someone clued me in about using the PNPBIOS option to automate > some isa resource allocations I have been experimenting with it. I've > managed to remove most of the irq stuff from my kernel configuration > file, apart from a few culprits. The main one is the keyboard and > mouse. The minimum working config I have found is: > device atkbdc > device atkbd0 at atkbdc? irq 1 > device psm0at atkbdc? irq 12 > If I remove the irq statements the kernel panics when probing the > keyboard "nexus_setup_intr: NULL irq resource!" which is a bit of a > shame. IWBNI the driver could get that information from PNP. Hmm, but > the PNP probe messages don't seem to have the necessary information. > > The other annoyance is that I have to tell vga and syscons to find > themselves on the ISA bus. Does PNP not inform the OS about them > either? It does, actually. The problem is that the early console attach happens long before we start paying attention to this information. The problem is reasonably well understood - the "correct" solution hasn't quite made itself known yet. (It probably involves some extra access methods to the PnP information, so consider this "something that will eventually be fixed".) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Promise-66 RAID
> > If you want a supported ATA RAID solution, see www.3ware.com. > > I'm curious how well the 3ware cards work under FreeBSD feature-wise? Can you > hot-swap drives (assuming you have an IDE hot-swap frame and cartridge like > Promise cards support)? The 6x00 series cards support hotswap. You need to reboot with the 5x00 cards. Note that ATA has no out-of-band swap notification, so working out whether a new disk has been inserted is an iffy proposition at best. > Can a broken mirror be rebuilt on-the-fly while > FreeBSD is running? or do you have to run some sort of BIOS or DOS utility to > get things going again? With the 5x00 adapters you need to reboot and handhold the BIOS. The sample I have has bad firmware, and doesn't do this right, but they've just posted a firmware upgrade that is meant to resolve this, as well as adding support for RAID10 (mirrored stripes - go-faster stuff). The 6x00 adapters are meant to resolve all this; I'll have one next week and will be adding support ASAP. Note that you can't do *any* of this with ccd or Vinum (apart from the online rebuild), and you can't get a reliable boot volume without a BIOS-level solution. I'd love to see Vinum understand the Promise config information, for example. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Mylex 160/170/352/2000/3000 driver available
--- Blind-Carbon-Copy X-Mailer: exmh version 2.1.1 10/15/1999 To: [EMAIL PROTECTED] Subject: Mylex 160/170/352/2000/3000 driver available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Jul 2000 03:18:38 -0700 From: Mike Smith <[EMAIL PROTECTED]> I'm pleased to finally announce the first public BETA version of a new driver for the current family of Mylex PCI-SCSI RAID adapters. This driver provides support for the following adapters: AcceleRAID 160 AcceleRAID 170 AcceleRAID 352 eXtremeRAID 2000 eXtremeRAID 3000 The driver can be found at http://people.freebsd.org/~msmit/RAID/index.html#mylex Note that this version of the driver provides read/write support but no status monitoring or management. Thanks go to the folks at Mylex for their support and patience, as well as to BSDi for funding development of this driver. Thanks also to Leonard Zubkoff, whose Linux driver allowed me discover and avoid a few critical documentation errors which had blocked me for quite some time. - -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] --- End of Blind-Carbon-Copy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Driver for Adaptec/Dell/HP PCI:SCSI RAID adapters available
--- Blind-Carbon-Copy X-Mailer: exmh version 2.1.1 10/15/1999 To: [EMAIL PROTECTED] Subject: Driver for Adaptec/Dell/HP PCI:SCSI RAID adapters available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Jul 2000 15:53:40 -0700 From: Mike Smith <[EMAIL PROTECTED]> The first BETA version of the 'aac' driver for the Adaptec AAC-364 'Jalapeno' and AAC-3642 'Jalapeno II' RAID adapters is available from http://people.freebsd.org/~msmith/RAID/index.html#adaptec These adapters are OEMed by Dell as the PERC 2/QC and by HP as the HP NetRAID-4m. The driver has been tested on FreeBSD 5.0-CURRENT, but is known to build and should function just fine on 4.0-STABLE as well. Testers are encouraged to contact me for assistance, or to report on progress. Thanks go to BSDi for funding the development of this driver, and Adaptec for supplying me with a profusion of sample adapters and the source for their Linux driver to work from. Particular thanks to Justin Gibbs for finding the right person at Adaptec to make all this happen. - -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] --- End of Blind-Carbon-Copy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Color ls
> On Tue, Jul 18, 2000 at 05:31:47PM -0700, Mike Smith wrote: > > > Yes. Any program that expects colour to work. > > In what sense? The color codes are absorbed by xterm and it > looks like it probably does without doing color stuff. Do you > know of a program which actually has problems? I can think of dozens. Try anything that depends on colour to identify eg. menu selections. > > The correct fix here is to tell your xterms to identify themselves as > > xterm-color. This will then proceed to break anyone that wants to use an > > xtern to talk to a system that doesn't know what xterm-color is. > > Yeah. Believe it or not, I log in to lots of random Suns and don't > like having to reset TERM. So fix your Sun systems so that they recognise xterm-color. > > The more correct fix here is to stop worrying about fucking colourised ls > > output and focus on the seventeen dozen more important things that need > > your angst. > > I don't like colorized ls. I do like colorized mutt. But thanks > for telling me what I should care about. Tell me what my proposed > solution breaks, for real. The xterm terminal definition does not support colour. It is an error to corrupt our terminal capabilities database such that we use the xterm-color definitions for a terminal identifying itself as 'xterm'. If you want Mutt to work, set your terminal type correctly. If you have to access a broken remote host, fix your exported terminal type correctly. You are attempting to rationalise "wrong" behaviour, and that's just plain "wrong". -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Color ls
> On Wed, Jul 19, 2000 at 01:08:41AM +0100, Josef Karthauser wrote: > > > joe@cuddy[503]: export TERM=xterm-color > > joe@cuddy[504]: vi > > xterm-color: Unknown terminal type > > Visual needs addressable cursor or upline capability > > :q > > joe@cuddy[505]: uname -a > > SunOS cuddy 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-1 > > That's not the issue. > > What we want to do is have TERM=xterm be the same as xterm-color > is now. > > If you log in to a FreeBSD box from your Sun, and *then* set > TERM=xterm-color and run things on the FreeBSD box, do the color > escape sequences screw anything up? Yes. Any program that expects colour to work. The correct fix here is to tell your xterms to identify themselves as xterm-color. This will then proceed to break anyone that wants to use an xtern to talk to a system that doesn't know what xterm-color is. The more correct fix here is to stop worrying about fucking colourised ls output and focus on the seventeen dozen more important things that need your angst. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Synching my src...
> > > > This is a pet peeve of mine. Freebsd-stable is supposed to be the mailing > > list that is required reading for anyone tracking stable, where all useful > > information related to tracking stable is to be found. > > > > However, the list is increasingly such a high-volume, low signal-to-noise-ratio > > chatfest that it no longer serves its intended purpose for even moderately > > busy people. A prohibitive amount of time is required to sort out what is > > relevant from what isn't. ... > I'll add my second to that proposal. This is just the sort of chitchat that you're both supposedly opposed to. And now you've gone and started another lengthy meta-thread about list usage (which anyone with half a clue could have told you was pointless) to further reduce the signal-to-noise ratio. Surely not what you really intended. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ServerWorks ServerSet III LE chipset?
> We are wondering if we should expect any problems with the chipset > in subject? You will need 4-stable to run correctly on this chipset in SMP mode, 4.0-release has problems with APIC initialisation. > How about the Adaptec 7892 SCSI? Should be fine. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Dump takes ages on SCSI. (several times faster on IDE)
> I have a PIII/450 with a venerable Adaptec 2940UW and a Quantum 9G > SCSI disk. > > Recenly, I was generating many crash dumps and was using a serial > console (so I was watching them). I came to a point in my debugging > where I needed another PCI slot, so I removed the 2940 and loaded an > IDE drive with the same build of FreeBSD. > > I then noticed that the IDE would crashdump somewhere around 10 times > faster than the SCSI disk. > > Why? Can the SCSI speed be improved? IDE disks typically default to write-cache enabled (the drive returns the command as complete as soon as it's given to the drive), while SCSI disks default to write-cache disabled (the drive doesn't return the command as complete until it's hit the media). In the dump context, this means that with a SCSI disk you spend a lot of time waiting for this back-and-forth handshaking, which you don't get with IDE disks. If you have the WCE bit set on the drive in question, it will go faster. The fact that SCSI commands are more expensive than IDE commands is also significant given that dump I/O is performed one page at a time. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kerneld for FreeBSD
> * Mike Smith <[EMAIL PROTECTED]> [000605 16:58] wrote: > > > > > Well, it would be nice to auto-load or unload any module that is needed. > > > not just ethernet and fs types. That's basically the idea. Say, if you > > > load a driver that uses some resources that another one can use while the > > > first one is off... that's what I'm talking about. > > > > "Some resources?" Er, no offence, but you're not making any sense. > > non shareable ISA irqs? They're "non shareable" at the hardware level ... like all the "non shareable" hardware resources. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 3.4-STABLE -> 4.0-RELEASE upgrade: unable to mount root partition
> > > Mounting root from ufs:wd0s1a > > > wd0: bad sector table not supported > > > wd0s1: bad sector table not supported ... > a) how to tell if your drive has bad144 on it See error messages above. > b) how to remove bad144 without reformatting your drive There are no tools to do this. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: -CURRENT Mylex on stable?
> > - Original Message - > From: "Mike Smith" <[EMAIL PROTECTED]> > > | > I'm missing where the end result of > | > diff/patch differs from the files themselves. It's a nice exercise, but > | > kind of a PITA when you're not a CVS user. > | > | The goal is to extract the changes I made to portions of the driver that > | are largely common between the two versions. > > OK, I'm trying even harder not to be flippant. But let me get this > straight. There are some changes I want, but some I don't. How am I > supposed to know what those changes are? Because it sounds like what you're > telling me to do is to merge some changes but not others, without me knowing > which specific changes I want. You're supposed to take the diffs I pointed you at, which only contain the changes you want. I also supplied you with a web-based interface which details exactly which changes are and aren't relevant to the bug in question. > Not to complain (too much), but since I wanted these bugs fixed in the first > place, why not just shoot me a set of diffs that would allow me to try the > patches under 4-stable? Is there a schedule for MFCing them instead? Because I can't test them under -stable, and I don't have any tools for building an array on a 2.x controller on i386 yet (because I am still _writing_ them), and I am more interested in the 6.x firmware because these controllers are actually out there in the marketplace, and I'm also working on drivers for AMI and 3ware as well as a few others on top of all my other work. And basically, the 2.x firware support was done primarily for folks running Alpha systems, where it's still current and where tools are still easily obtained. In the fullness of time, I'll get the 2.x stuff MFCed, or someone else with a 2.x controller will beat me to it. In the meantime, I'm sorry to say that you've been prioritised. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: -CURRENT Mylex on stable?
> > - Original Message - > From: "Mike Smith" <[EMAIL PROTECTED]> > > | 1) Get the diffs. > | > | You will need a CVS repository, or use the cvsweb interface > | at http://www.freebsd.org/cgi/cvsweb.cgi to extract the diffs. > | Note that mlx.c, mlx_disk.c, mlx_pci.c and mlxvar.h all changed > | in this fix. > | > | 2) Apply the diffs. > > OK, not to be flippant, but is there any reason I couldn't just use the > CURRENT version of those files? Yes, otherwise I would just have told you to fetch them. > I'm missing where the end result of > diff/patch differs from the files themselves. It's a nice exercise, but > kind of a PITA when you're not a CVS user. The goal is to extract the changes I made to portions of the driver that are largely common between the two versions. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: console disappears after reboot
> > So in summary; there's nothing that will "decide there is no built-in > > console" unless you explicitly tell it to go look for itself. Anything > > that's causing the system to talk to a serial console is at the admin's > > request. At this point in time, there is no way to force a change of > > console once the system is up and running. > > Unfortunately experience tells us otherwise. If we boot with no VGA > plugged in, we can't plug one in later and expect to see a console. If this is what is actually happening (ie. you do not have -P in / boot.config), then you have a video card which fails when there is no monitor connected, and it is not at all reasonable to expect syscons to probe/attach to this. > It seems that FreeBSD 3.1+ scans for a console, and if it can't find kb > / vga it switches to serial. The old machines all work fine as they are > 3.0 or less. This assumption is false. > I know I can set the console device in /boot/loader.conf, but this leads > to other problems (possibly a bug here): on some machines we get a > "/boot/loader not found - Disk error 0x1", and we suspect that this is > to do with the boot partition not being constrained to the first 1024 > cylinders. That's probably true. You shouldn't do this. > Anyway, to cut a long story short, I would prefer to simply do something > in /etc/rc.local to force the console back to local kb/vga, or disable > the serial console in the kernel itself... so my question is: what? Is > there such a command/setting? No. Under the circumstances you've described, it wouldn't help anyway, since there's nothing that you can do at that point that won't fail in the same fashion that the earlier syscons probe did. There have been some changes in syscons in 4.0 which may make it more generous in dealing with your video adapter, but if syscons is not attaching to your vide hardware, or the keyboard controller in these systems is failing with the switch turned off, there is nothing that can be done about it on software. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HPDA/DAC960PL errors
> > > Well, perhaps not. Running the old firmware, 2.39, my install of 4.0 fails > > > early on copying files: > > > > > > bus_dmamap_load : Too many segs! buf_len = 0x1 > > > mlx0 : I/O error -- attempt to write beyond end of drive > > > > > > Any idea what these mean? > > > > The 2.x firmware only supports a very small number of scatter/gather > > segments (17). It looks like someone's trying to do a non-page-aligned > > 64kb transaction there and we're overflowing. Addressing this is > > probably going to require a driver patch. 8( > > Ok. I know how I'm going to have to deal with this; the problem is that > we only use 16 of the 17 available S/G segments (so I can pack the S/G > tables without crossing page boundaries). This is going to take a little > while to implement, unfortunately. (Just to continue talking to myself) - The reason I never ran into this, I realised, is that I did all my work on the 2.x firmware in Alpha systems which have an 8k page size. With a 64k d_maxio, you'll never see more than 9 segments. Sorry about this. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HPDA/DAC960PL errors
> > Well, perhaps not. Running the old firmware, 2.39, my install of 4.0 fails > > early on copying files: > > > > bus_dmamap_load : Too many segs! buf_len = 0x1 > > mlx0 : I/O error -- attempt to write beyond end of drive > > > > Any idea what these mean? > > The 2.x firmware only supports a very small number of scatter/gather > segments (17). It looks like someone's trying to do a non-page-aligned > 64kb transaction there and we're overflowing. Addressing this is > probably going to require a driver patch. 8( Ok. I know how I'm going to have to deal with this; the problem is that we only use 16 of the 17 available S/G segments (so I can pack the S/G tables without crossing page boundaries). This is going to take a little while to implement, unfortunately. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HPDA/DAC960PL errors
> > | Well, I have good news, I think. The mlx driver _seems_ to work as-is > (from > | a kernel built with 4.0-STABLE). I get a warning about an old BIOS rev, > but > | it looks functional. The driver reported the correct logical drive size > and > | no other errors. > > Well, perhaps not. Running the old firmware, 2.39, my install of 4.0 fails > early on copying files: > > bus_dmamap_load : Too many segs! buf_len = 0x1 > mlx0 : I/O error -- attempt to write beyond end of drive > > Any idea what these mean? The 2.x firmware only supports a very small number of scatter/gather segments (17). It looks like someone's trying to do a non-page-aligned 64kb transaction there and we're overflowing. Addressing this is probably going to require a driver patch. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: How good is AMI MegaRAID support?
> > - Original Message - > From: "Mike Smith" <[EMAIL PROTECTED]> > > | If that's what they say, I'd be inclined to believe them. Since I've > not > | encountered any fatal problems with the 2.x firmware, I can't suggest > | that upgrading would actually win you very much. > > I'm not even sure the HPDA flavor of cards is supported by FreeBSD to > begin with. I hooked up my HPDA DAC960PL to a 4.0-STABLE box (cvsup'd > last night) today and during bootup I get: > > mlx0: port 0xdc80-0xdcff irq 11 at > device 13.0 on pci0 > mlx0: couldn't allocate mailbox window > device_probe_and_attach: mlx0 attach returned 6 What firmware revision are you running? This looks like your card isn't supporting a memory-mapped region for the mailbox window - I should check for this I guess. I'm fairly sure that 2.42 or later will work. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: How good is AMI MegaRAID support?
> On Sat, 29 Apr 2000 13:13:37 PDT, Mike Smith wrote: > > > >You leave out "how well you want it to perform" as well. All other > >things being equal, the PCI:SCSI adapters will give you better bang for > >your buck. > > Out of curiosity, how would a PCI-RAID (SCSI) adapter compare with > vanilla PCI-SCSI cards and vinum? It seems to me that the host CPU(s) > are much faster than the processors on the PCI-SCSI adapters. Or are > both of these "fast-enough" and thus performance differences are largely > an irrelevent consideration? (They both have similar software issues > but I suspect vinum is easier to debug. :) All other things being equal, software RAID is going to be faster. (ie. same disks, same # of SCSI channels, etc.) The hardware solution's sell there is: - better support/functionality (enclosure management, etc.) - better survivability (battery-backed cache) Plus you get a stack of SCSI channels onboard the card. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: amr still seems to have issues.
> * Mike Smith <[EMAIL PROTECTED]> [000420 11:39] wrote: > > > Hi, we're running 4.0-stable as of Sat Apr 15 18:39:08 PDT 2000 > > > which include the recent amr fixes which we were hoping would cure > > > the lockups with amr. Unfortunatly we are now experiancing reboots, > > > the messages file reveals this: > > > > > > Apr 15 13:31:06 abacus /kernel: amr0: command 31 wedged after 30 seconds > > > > This is extra-bad. Without more feedback from the controller (no > > documentation from AMI yet, sorry. 8() I can only wonder whether you're > > getting a SCSI bus error of some sort that's causing the kernel to time > > these commands out (because the controller is taking too long to respond). > > > > You could try increasing the timeout allowance in amr_periodic(), or just > > disable the poll entirely. This won't help if the controller is really > > dropping commands, though. > > > > > Right now I'm attempting to log off a serial console to see what's > > > going on, however this box has been in production (and doing miserably) > > > for some time now so doing debugging is pretty difficult as well as > > > time consuming where I really need to be working on other issues. > > > > At this point, I have no other ideas, sorry. > > Here's something I hope it helps: Hmm. Looks like I'm not retiring the wedged command correctly. This is a symptom, rather than the real problem, though. See if disabling the command timeout stuff makes the system happy - either these commands are just taking a _long_ time to complete, or you have another problem. I _still_ think you have disk, cable or enclosure issues, but now that you've precipitated this case I can go look at what I'm doing wrong here. Thanks! > amr0: command 40 wedged after 30 seconds > biodone: page busy < 0, pindex: 144, foff: 0x(0,9), resid: 4096, index: 0 > iosize: 8192, lblkno: 72, flags: 0x30020aa0, npages: 2 > valid: 0xff, dirty: 0x0, wired: 1 > panic: biodone: page busy < 0 > > mp_lock = 0101; cpuid = 1; lapic.id = > boot() called on cpu#1 > > syncing disks... > > Fatal trap 12: page fault while in kernel mode > mp_lock = 0102; cpuid = 1; lapic.id = > fault virtual address = 0x30 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0226765 > stack pointer = 0x10:0xff80dd9c > frame pointer = 0x10:0xff80dda0 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 = Idle > interrupt mask = bio <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 0102; cpuid = 1; lapic.id = > boot() called on cpu#1 > Uptime: 2d4h11m39s > amrd0: still open, can't shutdown > > dumping to dev #da/0x20001, offset 128 > dump 1023 1022 Aborting dump due to I/O error. > (da0:ahc1:0:6:0): WRITE(06). CDB: a 7 da f7 8 0 > (da0:ahc1:0:6:0): error code 0 at block no. -964632618 (decimal) > failed, reason: i/o error > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > > Any ideas? > > -- > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > "I have the heart of a child; I keep it in a jar on my desk." > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: SlickEdit for FreeBSD (fwd)
> Is anyone using SlickEdit for Linux under emulation? The vendor does not > seem interested in producing a native version... I looked at it a while back; it worked fine. The only real issue I had with it was that you needed (then) to brand a couple of binaries for the install to work correctly. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Custom boot disks
> > I have several systems with broken PCI chipsets that I need to upgrade to > > 3.4-R from 2.2.7-R. I've patched 'pcibus.c' to fix the problem on these > > systems (reversed the config mode probe order) but now I need to build > > boot/install stiffies to get these machines up and running. Is there any > > quick/simple way to do this without going through a 'make release' > > process? > > Just make a kernel and make sure you keep "options MFS" and "options > MFS_ROOT" in there. Then whap it over the kernel on kern.flp, which > you can mount as a normal floppy. Don't forget to gzip it first, as it probably won't fit otherwise. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: "dangerously dedicated"
> >>>>> "MS" == Mike Smith <[EMAIL PROTECTED]> writes: > > MS> Regardless of what you think, the only correct way to divvy up a disk on > MS> a PC is to start with an MBR and work down from there. There is no other > MS> way to do this properly, and to think otherwise merely demonstrates your > MS> ignorance. > > Excuse me, but an MBR is not an FDISK label. I had a system that had > BSD/OS instaled on it with no FDISK label and it worked just fine. The first 512 bytes of any disk attached to a PC are assumed to be a valid MBR. Such a valid MBR includes boot code, a table describing four disk regions and a checksum. This table of disk regions must be present; you cannot expect reliable operation without it. > Who's demonstrating ignorance here? "It works for me" isn't even close to a valid argument. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: "dangerously dedicated"
> > Why is using /dev/da0a stupid? FreeBSD is the only system I've > encountered that totally locks up (during a 3.3-RELEASE install from > CD) when there is no fdisk disk label. Is that why it is stupid? You can't boot from a disk that doesn't have an MBR on it. This is a feature of the PC BIOS, and it can't be worked around. > BSD/OS and Linux (RedHat 6.1) both deal with the lack of an fdisk disk > label just fine, and BSD/OS doesn't even require one, letting you use > the direct unix partitioning scheme. I much prefer it that way as it > just makes sense on a dedicated box, which is what all of mine are. You're out of your depth here, unfortunately. Both of these systems do install an MBR, they just don't tell you that they are. Regardless of what you think, the only correct way to divvy up a disk on a PC is to start with an MBR and work down from there. There is no other way to do this properly, and to think otherwise merely demonstrates your ignorance. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: booting 3.x from CD?
> > > > > The booting process would halt at either the point where it says > > > > > > > > > > Timecounter "i8254" frequency 1193182 Hz > > > > > > > > > > or it would pass exactly this point and then halt at the next > > > > > screen (the one where you select wether you want to config your > > > > > kernel in visual mode etc.). At one of these points it would > > > > > simply freeze, no panic, no dump, nothing. ... > This is the commit that broke things for me. A kernel built from > the sources just before it boots, a kernel built from the sources > right after it "freezes" at the point above. Which one of the points above? > I have absolutely no idea how to debug the problem I described > above, as not even setting "boot_ddb" managed to break into a > debugger where I would be able to at least try to have a closer > look at this problem. > Does somebody have any ideas what I could try out? Sounds like you've got BIOS problems. Look for an upgrade from your vendor, and then start breaking down the kernel boot process to see if you can find where exactly it's hanging up. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: K6-MTRRs
> Roman Shterenzon had the audacity to say: > > What models/revisions seem to be broken? > > I *think* that K6-2 mtrr works. > > > > That's the impression I was under. I have gotten no information from AMD to say > that the MTRRs on their K6-2 line don't work. The only things I know of is that > the first-gen chips didn't have them, and the code checks for that. Are you sure > that it isn't some interpretation problem with the tech docs? If the original K6's don't have memory range registers, how could we have tested them and discovered they didn't work? At any rate, you're encouraged to talk to the author/maintainer of the code, Brian Feldman (copied). If you can make it work, wonderful. > > On Mon, 6 Mar 2000, Mike Smith wrote: > > > > > > Well, I know that they are different form those on the PII/III line, > > > > and that there are only two. I think that they are implemented in some > > > > windows drivers and programs. Maybe whoever is in charge of it could > > > > contact me, I have some AMD tech docs and maybe I could take a crack at > > > > it. > > > > > > I'm not sure I follow you. We have implemented support for the K6 memory > > > range registers, and having done so, discovered that they don't behave > > > like they should. Thus, support was disabled for these CPUs. There's > > > nothing more to do, as far as I'm aware - the hardware itself is broken. > > > > > > > --cokane > > > > > > > > Mike Smith had the audacity to say: > > > > > > I know that the k6 mtrr code is broken. Who is actively working on > > > > > > this? I have been messing with it and know that it screws up the > > > > > > framebuffer writes in xfree86 4.0. It prevents the writes of certain > > > > > > parts of the pixel values. > > > > > > > > > > Evidence suggests that the problem is actually in the K6 itself. > > > > > > > > > > -- > > > > > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > > > > > \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] > > > > > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > > with "unsubscribe freebsd-stable" in the body of the message > > > > > > -- > > > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > > > \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] > > > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] > > > > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-stable" in the body of the message > > > > > > > --Roman Shterenzon, UNIX System Administrator and Consultant > > [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: console disappears after reboot
> [moved to -stable from -security] > > "Crist J. Clark" <[EMAIL PROTECTED]> writes: > > Adam Laurie wrote, > > > Crist J. Clark wrote: > > > > > Anyway, to cut a long story short, I would prefer to simply do something > > > > > in /etc/rc.local to force the console back to local kb/vga, or disable > > > > > the serial console in the kernel itself... so my question is: what? Is > > > > > there such a command/setting? > > > > If a console has "died," you should [HUP init] > > > Unfortunately not. I assume it only tries to refresh the serial console. > > I don't think so. Is the getty(8) for the device (I assume ttyv0) still > > in the ps(1) output? If it is, perhaps kill it. Either kill it dead > > and SIGHUP init(8) to start the new one, or maybe some signal (a HUP?) > > refreshes a getty. > > You're totally off the track. His problem is that the kernel (or the > boot loader) decides that there is no built-in console and uses a > serial console instead. This has nothing to do with init(8). I guess > the right person to answer this kind of question would be Mike Smith > or Daniel Sobral. I don't have any context for this, so it's a bit hard to be sure. The decision as to which console to use is normally made by boot2; it will use the video and keyboard BIOS unless: a) the -h flag is supplied in /boot.config b) the -P flag is supplied in /boot.config AND the BIOS has not set the 'extended keyboard present' flag. This decision can be overridden with a setting in /boot/loader.conf which can cause the loader to switch to another console, and it can be overridden again by flags set on an sio device. So in summary; there's nothing that will "decide there is no built-in console" unless you explicitly tell it to go look for itself. Anything that's causing the system to talk to a serial console is at the admin's request. At this point in time, there is no way to force a change of console once the system is up and running. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: fbsdboot.exe can't load elf kernels
The ability to load and start a kernel != the ability to boot and run same. You cannot boot and run FreeBSD once DOS has been booted on the system. You should give up now before you waste any more of your or our time. There are good technical reasons why this is the case. If you don't understand them, please trust those of us that do. Thankyou. > hello. > > On Wed, 12 Jan 2000, Max Khon wrote: > > > ftp://iclub.nsu.ru/pub/FreeBSD/incoming/fbsdboot.exe > > I have not tested it. Tell me if it works or not. > > it can boot elf cernels, but i have: > > no init > panic: no init > > rebooting at N seconds... > > maybe i must specify root device? but how? > i dont remember such problems with old fbsdboot.exe > (or it's kernel's problem?) > > anton. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: fbsdboot.exe can't load elf kernels
> Hu... I can easily cram boot0, boot1 and boot2 in there, but loader > is a bit to big at 128K bytes :-(. You don't need the loader for most 'embedded' applications. Boot2 will do you fine. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: fbsdboot.exe can't load elf kernels
> > > > No. If you think about what BIOS code actually does, this should really > > be fairly obvious. > > Sorry, I'm clueless 8). What does it do, exactly? Provides an abstract interface to a completely arbitrary hardware instance. Since there are no hardware standards at this level, you'd have to duplicate the unix-specific BIOS for every piece of hardware out there. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: fbsdboot.exe can't load elf kernels
> > > Nearly 100% of "modern" Flash Memory devices either emulate an IDE drive > > in Hardware or have emulate a standard BIOS disk device using some sort of > > BIOS driver, usually in such a way so that it will boot a DOS-like OS from > > it. > > Which brings up the question that keeps nagging at me: How possible is > it to create a pc bios that is geared towards BSD/linux? This would > include its own lightweight repair shell. Couldn't this solve a lot of > problems with pc hardware, to have a unix-oriented bios? No. If you think about what BIOS code actually does, this should really be fairly obvious. In all reality, new BIOS features are actually directed towards the same sort of problems that we're facing, even if the process is driven largely by Microsoft. Take a look at eg. ACPI to see what I mean. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: fbsdboot.exe can't load elf kernels
> > Of course, the ones which truly emulate an IDE drive at the hardware level > > just work like an IDE drive, although slower on writes. > > > > The BIOS ones get tricky. Obviously, if the boot loader only uses bios > > calls to do it's dirty work, these work well, at least through the boot > > process. If the boot loader tries to access the hardware directly, and it > > doesn't directly support the flash device, then the boot loader doesn't > > work. Of course, this also applies to the OS. > > And that's assuming you could actually get a UFS partition on the "drive > emulator thing"? But if you were only capable of loading files to a fat16, > then wouldn't fbsdboot.exe (or whatever it's called) be necessary? No. Firstly, you are again raising a hypothetical question without actually suggesting anything that might require this, so bear with me if I don't take it too seriously. Things just don't really work like this. However, if you assume that you can for some reason only boot from a FAT16 filesystem, and for some reason you want to run FreeBSD on this hardware and only this hardware, then you would rewrite boot2 to read FAT filesystems. There is still no need to boot DOS. In a very few cases, you'll find disk 'emulators' that offer BIOS interfaces to the emulated disk. These are rapidly declining in popularity because they offer very poor performance for Windows-using customers. They also typically fare very poorly or not at all under other operating systems, as they tend to require timer interrupts in a very hostile fashion. Please; take it from me that "booting DOS to boot another operating system" is so far beyond a joke in most situations that we don't even want to pretend in public that it's done, let alone talk about supporting it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Temperature Findings
> I had one my technicians set up a scope to test the voltage readings and > a Cooper temperature gauge to check the case temp. We decided to abandon > the CPU test since we had no accurate way to attach the gauge. Our > findings: > The voltage readings by the winbond IC in the bios are accurate. > The case temperature was 5F cooler than reported. > So I would conclude the readings from the bios are a fairly accurate > representation of the machines current condition. > > Things I failed to mention. > The CPU's were overclocked by 100MHz > Core CPU Voltage was raised a 1/2 step to 2.05V > > o This still does not explain the differences between Linux > and FreeBSD. The difference has already been explained as a different instruction mix. This should be obvious to anyone that has been in the industry for as long as you have. > o The standard 3.3-RELEASE UniProcessor kernel runs identical to > Linux. This is because both systems use the HLT instruction, which has a low power consumption. You've already been told this. > o FreeBSD SMP kernels immediately run hotter than the standard > kernel. FreeBSD doesn't use HLT in the SMP implementation. You've been told this as well. > I put Core voltage back to normal and set the CPU's to standard > settings. The result was much better but it still runs about 14 degrees > hotter.(acceptable) 26 degrees was not. > > Has anyone else checked this. Just checking the Generic versus a SMP > kernel you should see this. This is commonly known behaviour. Your problem is simply that your cooling setup is not adequate to support your system running at 100% duty cycle. You've been told this already. You need to upgrade your cooling arrangements, and you've been told _that_ already too. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Panic: Out of mbuf clusters
> OK, so I raised NMBCLUSTERS to 4096, and installed a second freebsd-stable > box also with NMBCLUSTERS at 4096, and I managed to have them both panic > at the same time (unfortunately, only one of them gave me a crash dump). > But anyway, here is the stack trace, hopefully someone can tell me if this > is the same as the known problem, and whether 4.0 would fix it. Again, 4096 is (obviously) not high enough. No, upgrading to 4.x won't "fix" your problem. The panic is telling you that you _have_not_ tuned the system correctly. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
FreeBSD/Alpha (was Re: AMD 3DNow instructions on FreeBSD )
> Does FeeBSD/Alpha run reliably on an AXPpci33 with Quantum > Fireball (SCSI)? Yes; we do test installs onto one (although I think it has a 2GB Empire in it at the moment, the furball was too small). -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Re[4]: SOFTUPDATES
> On Tue, 21 Dec 1999, Ben WIlliams wrote: > > > Tuesday, December 21, 1999 > >So that's a "Yes you need [br]oot & fixit"? (I actually tried it > > with wd0s1a too and got the same effect.) I'll just take my disks next > > time I go up to see the router/webserver/mailserver(pop&smtp)/ > > pain-in-my-ass box and be done with it. > > > >Thanks for the input. > > > > No, you just need to use the correct device. I just did a server today, > I booted single user and turned softupdates on for ALL filesystems, > including root. Just in case nobody has noticed, you can pass a mountpoint as an argument to tunefs and it will (mostly) correctly guess the device (by reading /etc/fstab). ie. one says tunefs -n enable /usr rather than guessing at which device to use. Much more robust. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Mylex RAID controller driver update
> On Tue, 21 Dec 1999, Mike Smith wrote: > > > > > The third update to the Mylex PCI:SCSI RAID controller driver for > > FreeBSD-3.x-STABLE is now available at > > > > http://www.freebsd.org/~msmith/RAID/mylex/mlx-stable-991221.tar.gz > > > > According to the README: > > Copy the files mlx.c, mlxvar.h, mlxreg.h and mlxio.h into /sys/pci... > > however, mlxio.h is not present in the archive (and doesn't appear to be > required for any of the sources)...typo in README or missing file? Typo in README, thanks for spotting it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /boot/loader fails to reset AMD K6-II FPU
I believe I've already replied to this; it does indeed appear to be a BIOS bug. The 'reboot' loader command simply re-invokes the bootstrap interrupt, it doesn't attempt a complete system restart. It seems that some BIOSsen don't deal with this very well. > this may be a BIOS/Mainboard issue, so I ask here > before filling out a PR. > > When I reboot the system from the /boot/loader > command line (with `reboot'), the system is > being resetted, the kernel loads and starts, > and when the FPU is being initialized the kernel > traps. > > Can anyone reproduce this? > > At least this CPU seems to be affected: > > CPU: AMD-K6(tm) 3D processor (400.91-MHz 586-class CPU) > Origin ÿAuthenticAMD" Id ðx58c Stepping ñ2 > Featuresÿ8021bf > AMD Featuresÿ8800 > > Björn > > -- > -BEGIN GEEK CODE BLOCK- > GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L---(++) !E W- N+ o>+ > K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ > --END GEEK CODE BLOCK-- > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Don't use the "custom" install option for 3.4
> On Mon, Dec 20, 1999 at 10:31:17PM -0800, Jordan K. Hubbard wrote: > > It's broken, sorry (I usually only test with "Novice" since so many > > more people use it). I'll add something to the errata, until then > > please use Novice or Express. I'm also sure that this is a completely > > Will the 3.4 CDs be pressed with this bug? Yes; we only just hit the this-year window last night with a few minutes to spare. I _did_ manage to work around the "can't boot on some ATAPI CDROMs" bug for CD #1, if that's any consolation. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: mountd and rpc.statd won't run
> Bill Fumerola wrote: > > > I'm just suggesting we not just discredit the original poster, because it > > did happen. It's been about 3 months, but I think the original cause was > > network_interfaces only containing the ethernet card after installation. > > > That was most certainly the case for me. It would be _so_ much more helpful for someone to actually detail the steps they had followed to get into this state. So far, it's literally easier to believe in mass hallucinations. Give us something more to work on. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: URGENT (?) booting from CD on Atapi
> Mike Smith once wrote: > > > > A machine with SCSI disks and an ATAPI CD-ROM (no IDE disks) would > > > not boot from 3.3 CD if the SCSI disks are online. It would say: > > > "Read Error" on the upper left of the screen -- where you'd normally > > > see the spinning dash. I suspect, this is a loader's bug :(, which > > > may make it to 3.4 ... > > > This is a bug in your BIOS, or your configuration of your system. The > > loader is not running at that point; the 'Read Error' message is boot1 > > trying to load boot2 and failing, typically due to a bad value in %dl > > passed by the BIOS. > > Well, I figured, it is not the BIOS, who says "Read Error", but did not > know which part of the boot process :) I was hoping to shed some light > on the problem, that was reported shortly after the 3.3RELEASE, when > some people were and some were not able to boot from their CD-ROMs. May > be this (common?) BIOS' brokennes can be worked around in boot1? No. The 3.3-RELEASE issue (which was also detailed here) was another BIOS bug which prevented the CDROM from being recognised as bootable at all. If your code is never run, you can't 'work around' anything. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Netgear FA410TXc
> Anyone now if the this PCMCIA ethernet card is going to make it in to > the main source tree. I have a laptop with this card and am currently > running OpenBSD which is supported. The problem is that my habits and > openbsd arre not the same. I know the card is supported in PAO but I > like staying with STABLE more than release. > > If anyone has any way of knowing if this is going to happen or if there > is a way to stay STABLE with PAO I am all ears. I'm using one right now under -current; it should probably work on -stable as well. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Bugfixed AMI MegaRAID driver for -stable available
Due to a programming error, the previous release of the AMI MegaRAID driver for FreeBSD 3.x would not work with Enterprise 418 and 428 series controllers. This has been corrected, and the new driver is available at http://www.freebsd.org/~msmith/RAID/ami/amr-stable-991214.tar.gz There are no other changes in this release. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: printer problems using 3.4RC kernel
You're not clear about what you're printing, where you're printing it to, or what the actual output looks like, but these symptoms are entirely consistent with you trying to print plain text or some other encoding to the printer. You need to ensure that you're actually printing to the correct printer device. > Hello everyone, > > I've just finished cvsup'ing 3.3-stable, to bring my 3.3-Release system up > to date. Everything went fine and seems to be working except for my laser > jet printer. Its a NEC SuperScript 870 which emulates to a HPLJ IIP. The > printer gets recognized fine during bootup and everthing appears to be OK > until I try to send roughly more than 1 page of data to it. The page can > be sent by cat 'filename' | lpr, using a2ps, or just dumping from a > webpage with html, it doesn't seem to matter. What happens is I only get > a small amout of data on each page, and then the next page is sucked into > the printer and again only a small amount of data is placed on it. I am > using apsfilter as the printers textfilter. > > I compared my boot logs with the new kernel to the GENERIC 3.3R kernel I > was using previously, and there isn't a bit of difference in them. All I > did was eliminate devices that weren't getting found anyways. I'm sure it > has to do with the kernel, or its config, as if I boot off my old GENERIC > kernel my printer functions properly. > > The one thing I've noticed is when the printer is working correctly, there > is significantly more delay from when I send the printjob to the printer, > and when it starts printing. Booting off of the kernel I compiled, there > is almost no delay between when I tell the system to print, and when the > printer starts to suck in the paper and print out small portions of what > it should be printing spread out over many pages. > > If anyone else is seeing this problem and has any ideas, I would love to > hear them. > > thank you, > > Roger > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kernel compile succeeds but is unusable, take two
>It was suggested to me that I should post my config file along with > the exact commands I issue to build my kernel so here they are. > # devicenpx0at isa? port IO_NPX irq 13 > device npx0at isa? port IO_NPX Why did you do this? You MUST NOT dink with this line. > # pseudo-device pty 16 Taking pty's out is a bad idea too. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kernel not patching?
> OK... in my ongoing strange saga, I added > > char *dgilbert_bre5_top = "dgilbert_bre5_top"; > > as a global variable in vinumraid5.c --- I'm doing this as part of a > strategy to track down a memory (stack) corruption bug. > > Anyways... when I recompile the kernel, it compiles this one > module... and this global variable is referenced. When I then search > for this string (by lessing the kernel and searching for dgilbert), I > can't find it in the kernel's image. What's up? Module != kernel -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: StarOffice 5 on a SMP system..... or Applixware...
> Probably shouldent have phrased it like that...sorry. I downloaded StarOffice > at www.sun.com. I guess what I would like to ask is this then, > > 1) How well does ApplixWare handle MS Office97 files? Quite well. I even have reasonable results with FastSaved documents. > 2) Do you know of any plans for Applixware to support Office 2000 formats? It does already. > 3) How well does Applix share files with StarOffice (I aleady have a few in >StarOffice format, although I suppose I could change them to .txt >format and use them that way) It claims to read/write them; I haven't tested it. > 4) And this is the biggie.Does the Applix lisence allow for multiple copies >of the software (For example on a laptop and Desktop) with one purchase or >would I have to purchase two copies... The Applixware office licence allows a single user unlimited use of the software. Since you are a single user, you'd be fine. > Regarding question #2, sibce The Applixware we have is a port from the Linux > one, does this mean we will have to wait untill Applix gets Office 2000 support > 1st or will we be able to work on the source ourself? It's not "a port from the Linux one"; Applixware builds for about a dozen or so platforms, and the FreeBSD port has equal status with the rest of them. As I've already stated above, it already has O2k support. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: IDA driver issues upon installation. Probing devices hangs
> I've tried moving irq's around and removing some other cards but nothing. > If I boot without the ida driver, it works ifne except that I don't have > any drives to install on. Oops, I forgot to mention; you can't install onto an 'ida' drive; you need a system drive. You will want one anyway; swapping onto a RAID5 array is a pretty lame idea. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: IDA driver issues upon installation. Probing devices hangs
None of the interested developers have access to one of these machines anymore; it's quite possible that things have been changed or broken to some degree of late. > I am trying to install the stable snapshot from 10301999 on a compaq > proliant 4500 with a smart array controller. I recompile the installation -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Signal 11 on 3.3 installation
> Just a update on 3.3 > Today (25Sept) I downloaded the latest snap of 3.3 (19990925) and tried to > install it. I got the same signal 11 at the exact same spot as before! To > help with memory, it was just after filling in the blanks on the network > configuration screen. When I then clicked on the ok button, up popped the > "caught signal 11" screen! Now the weird part. I then used these same > disks to upgrade my 3.2 and it worked great! No problems on the software > side (I made a mistake on what to mount, but that was my fault). Perhaps > this should be sent to hackers or current? No. You haven't included anything like enough information yet for the report to be at all useful. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: softupdates in latest build?
> At 11:29 AM -0700 1999/9/6, Mike Smith wrote: > > > I'll say it again; read what has already been said. Most of us are > > heartily sick of your side of the argument, and you're not likely to > > get many useful responses while you continue to display basic ignorance > > of the issues involved. > > I think I'm beginning to understand the attitude problem that > Linux advocates have accused the FreeBSD camp of. What, that we have no time for people that can't be bothered to help themselves, even when asked to? You've walked into a contentious issue spewing FUD, patently disregarded the suggestion to take a little time to familiarise yourself with the history of this issue in our context, and now you expect us to feel sorry for you? Brad; this isn't a kindergarten. You are addressing the FreeBSD developer community here, and you are telling us that you think the end result of a long decision process was a stupid idea. Do you really expect that sort of thing to be well received? You could have started with "I was surprised to find that bpf was enabled. Why was this done? Where can I read about the decision process that resulted in this change?". Unfortunately, you've discovered that there are a lot more of us that there is of you, and that we don't suffer abuse at all gently. The suggestion to go read up on the issue was not meant as a brush-off; it was a well-intentioned gesture with the aim of educating you in a fashion that doesn't involve some poor bastard like me re-typing every salient point that was made during the whole process. Please do us the courtesy of informing yourself to the best possible extent so that we can communicate meaningfully and usefully with you. As you say, this isn't Linux. We don't have a history of mailing lists and newsgroups filled with whining newbies that have driven the developers away to other, closed areas, and we plan to keep things that way. If it results in a few slightly bruised noses evey now and then, that's a price we've demonstrated we're willing to pay. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel fails to compile today...
> > > I noticed the same behavior when I compiled the kernel with apm enabled: > > > > > >device apm0at isa? flags 0x0020 # STAT-CLOCK BROKEN > > > > > > however, when I define: > > > > > >device apm0at isa? disable flags 0x31 # Advanced Power Management > > > > > > everything works fine. I'm using a 3.3-RC SMP-Kernel and with the current > > > settings I don't have any idle time displays in top and uptime. > > > > APM and SMP are almost guaranteed not to work correctly. > > > > Yes, I know. All I wanted to have is correct idle time information from > programs like top, ... > > Therfore I had to mark the STATclock as broken by enabling apm. If there > are other ways to accomplish this, I would like to hear about it. Er. In the example above you say "is broken when APM is enabled, works when APM disabled". This is the result I expect. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Kernel fails to compile today...
> I noticed the same behavior when I compiled the kernel with apm enabled: > >device apm0at isa? flags 0x0020 # STAT-CLOCK BROKEN > > however, when I define: > >device apm0at isa? disable flags 0x31 # Advanced Power Management > > everything works fine. I'm using a 3.3-RC SMP-Kernel and with the current > settings I don't have any idle time displays in top and uptime. APM and SMP are almost guaranteed not to work correctly. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Fixes for build problems with SMP-stable
Ok; now I have a working -stable SMP system I can actually test this. What _was_ I smoking before? Can anyone with a -stable SMP system please apply the patches at http://www.freebsd.org/~msmith/stable-smp.diff and let me know whether these result in a buildable and runnable kernel? We need to get this into -stable ASAP for obvious reasons. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: -stable kernel build failed.
> > 8/31 12:00 GMT+0800 cvsup to the newest src tree, but my -stable box > can't build a new kernel : My bad, patch error. Should be fixed now. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: On freezes in 3.2-Stable (fwd)
> I didn't realize this person asked this off list, so I am forwarding > my reply onto the list, it has information in it that someone should > use to write a FAQ/FSA, this issue has come up some many times over > the years that I am getting sick of reading it every time memory > generations change. > > Basic rule, Don't ever expect to be able to drive more than 72 DRAM > chips with anything in the PC world, period. You have to do bus > buffering using balanced drivers and real clean layout work on the PC Board, > and there ain't a PC maker out there who is going to bother with > this unless they are supporting 8 sockets or more in high dollar > server machines. Er. The Intel AD450NX has 32 DIMM sockets. Unless someone starts making 2-chip DIMMs, I don't see how you would run 8GB in this box (and I have seen it being done under other operating systems). You might want to qualify the issue a little further; specifically with regard to "typical memory controllers", logic families and fanout. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: On freezes in 3.2-Stable
> > Anyone know if patching FreeBSD is required in order to support > 1GB RAM? Anyone successfully running their box w/ 1GB RAM > and 3.2-S? We have built several releases (including 3.2, if I remember correctly) on a box with 1GB of memory, using no special patches or configuration options. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
