Re: Strange dma_init error on current with awe64 and floppy
On Wed, Nov 08, 2000 at 03:11:46AM +0100, [EMAIL PROTECTED] wrote: I'm sure I must have overseen something trivial, but currently I can't figure out what it is. The lower 16 MB memory has been used for kernel text, data, bss arrays allocated by vm_page_startup() memory allocated via malloc() with M_ZERO I don't think that is the problem. I tried an older PRENGSMP kernel nearly the same config like the actual one. Same means a bit larger, more devices. Know I build a GENERIC kernel striped down to the devices I thibk I need in kernel. Other devices like the bktr and the pcm are loaded as module. The config file is here http://www.radio-do.de/~fn/G5SMP The dmesg is http://www.radio-do.de/~fn/dmesg.txt Here the out from top right after boot into single user mode and after going multi user. In sum the used mem is 11460K. There should be space for the dma buffer needed for sound card and fdc. Is there other memory in use that top doesn't show ? Because the physical memory is 512M. last pid:41; load averages: 0.05, 0.03, 0.01 up 0+00:02:0909:31:41 2 processes: 1 running, 1 sleeping Mem: 704K Active, 1776K Inact, 7716K Wired, 1264K Buf, 490M Free Swap: PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 41 root 46 0 1900K 1076K CPU1 0 0:00 0.00% 0.00% top 6 root 10 0 716K 368K wait 0 0:00 0.00% 0.00% sh last pid: 425; load averages: 0.48, 0.12, 0.04 up 0+00:02:3509:32:07 66 processes: 5 running, 44 sleeping, 17 waiting Mem: 43M Active, 9580K Inact, 14M Wired, 80K Cache, 12M Buf, 434M Free Swap: 550M Total, 550M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 10 root -22 0 0K 0K RUN1 1:35 49.81% 49.71% idle: cpu1 11 root -22 0 0K 0K RUN0 1:35 49.37% 49.27% idle: cpu0 337 nobody84 16 14636K 13824K CPU1 0 0:13 90.23% 45.46% setiathome 334 nobody83 16 15148K 14336K RUN0 0:13 89.94% 45.31% setiathome 358 root 10 0 1128K 1012K wait 0 0:00 2.86% 1.37% bash 210 root 2 0 2116K 1392K select 1 0:00 0.41% 0.24% sshd 425 root 49 0 1944K 1152K CPU0 0 0:00 0.00% 0.00% top some ideas how to track this further ? Regards, Frank -- ~/.signature not found: wellknown error 42 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvs problems
I updated my sources using cvsup, and i am unable to make the world : the message i get is : === doc /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/gperf/doc created for /usr/src/gnu/usr.bin/gperf/doc make: don't know how to make bool-array.cc. Stop *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. So, what should i do ? In advance, thaks a lot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
licq after crt* change
Hi! licq doesn't work since crt* change.. (coredumps) Any workaround? (recompile if licq qt doesn't help). /usr/ports/net/licq Dmitry. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: umount -f busted
At Tue, 07 Nov 2000 14:54:50 MST, Warner Losh wrote: In message [EMAIL PROTECTED] Alfred Perlstein writes: : Yes, this used to work quite well for some time, I have no idea : who broke it. Maybe you can sprinkle some printfs in the code and : narrow it down a bit? I'll give it a shot. I'm glad to see it is a "should work but is busted" rather than a "depreicated functionality, cope." situtation. This seems to be an realy old problem, see PR 765 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=765 /Johan K To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with dlopen()/dlsym() after recent crt* changes
John Polstra [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Alexander N. Kabaev [EMAIL PROTECTED] wrote: Why FreeBSD does not link libgcc into shared libraries by default? Everyone else is doing that. Linking shared libraries with libgcc seems to be the ultimate work-around. Are there any compatibility problems which are keeping FreeBSD from doing that? None that I'm aware of. I agree we should do it. I'll talk to David O'Brien and find out whether he has any objections. Do it, do it! The jdk 1.2.2 (FreeBSD) port broke in the predictable way (no exception-handling functions) until I had the libraries linked with -lgcc_pic. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/defaults/rc.conf
I've had been considering running xinted for some time now, and thanks to Forest's suggestions I've been able to successfully get it up and running smoothly. I am personnaly left wondering why not just replact inetd altogether with this version? It certainly enhances security a bit. Well these are just thoughts from the peanut gallery. Cheers, Mikel Forrest Aldrich wrote: At 09:30 AM 11/7/2000 +, Konstantin Chuguev wrote: If xinetd has a startup script, why don't you just set inetd_enable="NO" and let the /usr/local/etc/rc.d/xinetd.sh start normally? You need to edit no /etc/rc.* files (except for rc.conf.local, obviously). [ .. ] Sure that would work, but for the type of service it is, this seems rather ambiguous. I would rather see this service handled in the rc.* scripts, where other similar services are handled. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: umount -f busted
In message [EMAIL PROTECTED] Johan Karlsson writes: : At Tue, 07 Nov 2000 14:54:50 MST, Warner Losh wrote: : In message [EMAIL PROTECTED] Alfred Perlstein writes: : : Yes, this used to work quite well for some time, I have no idea : : who broke it. Maybe you can sprinkle some printfs in the code and : : narrow it down a bit? : : I'll give it a shot. I'm glad to see it is a "should work but is : busted" rather than a "depreicated functionality, cope." situtation. : : This seems to be an realy old problem, see PR 765 : http://www.FreeBSD.org/cgi/query-pr.cgi?pr=765 It is a problem that I could have sworn worked before SMPNG. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
The IRQ allocation needs the RF_SHAREABLE flag or it will blow up in the case where the IRQ is shared with another device. So the EISA attachment doesn't set RF_SHAREABLE if the system is using a level sensitive interrupt? -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/defaults/rc.conf
On Wed, 08 Nov 2000 09:30:02 EST, Mikel wrote: I am personnaly left wondering why not just replact inetd altogether with this version? It certainly enhances security a bit. Well these are just thoughts from the peanut gallery. Too many of those and a mailing list becomes unreadable. :-) However, as a show of good faith, I'll say that your question has been asked _many_ times before and it should not be hard for you to find the answer in the archives. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: umount -f busted
On Wed, Nov 08, 2000 at 07:43:24AM -0700, Warner Losh wrote: It is a problem that I could have sworn worked before SMPNG. Negative, this occurs on releng_4 machines for me as well. It also was occuring on my -current workstation that was about 110 days old before a disk went out, so it was definatly pre-smpng. -- Bill Fumerola - Lame Duck, BOFH / Chimes, Inc. [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: umount -f busted
On Wed, Nov 08, 2000 at 07:43:24AM -0700, Warner Losh scribbled: | In message [EMAIL PROTECTED] Johan Karlsson writes: | : At Tue, 07 Nov 2000 14:54:50 MST, Warner Losh wrote: | : In message [EMAIL PROTECTED] Alfred Perlstein writes: | : : Yes, this used to work quite well for some time, I have no idea | : : who broke it. Maybe you can sprinkle some printfs in the code and | : : narrow it down a bit? | : I'll give it a shot. I'm glad to see it is a "should work but is | : busted" rather than a "depreicated functionality, cope." situtation. | : This seems to be an realy old problem, see PR 765 | : http://www.FreeBSD.org/cgi/query-pr.cgi?pr=765 | It is a problem that I could have sworn worked before SMPNG. I distinctly remember trying to do the exact same thing and not being able to in 4.0-current vs. 3-stable. (Because it eventually panic'ed the nfs client and cost me a night of work.) Was this a "works sometimes" thing? -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: So the EISA attachment doesn't set RF_SHAREABLE if the system is using a level sensitive interrupt? The current EISA code isn't as smart as it should be. I've got uncommitted code that ties it to the ELCR. Bus front end code shouldn't have to know about level/edge triggered IRQs. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: So the EISA attachment doesn't set RF_SHAREABLE if the system is using a level sensitive interrupt? The current EISA code isn't as smart as it should be. Speaking of that, I'd like to see the EISA code move to be more like PCI. We should see if there is something at slot 0 and only then attempt to probe for sub-devices on the bus. The only reason this isn't done is because I, due to the fledgling nature of the EISA code and the ahc VL card's almost looking like EISA cards, did the wrong thing here. We also need to be verifying that io ranges required to probe for slots are not already claimed by other devices before we blindly access them. For this to all work with the VL ahc cards, the EISA code will have to release all resources associated with empty slots and the ahc driver will have to grow an ISA front end. I'm willing to help out on this work (still have a functional EISA machine), but I stopped short last time over concern on how to support Alpha/PA-RISC machines that might have multiple EISA busses. I've got uncommitted code that ties it to the ELCR. Is this stuff documented anywhere? I've always wanted to gain access to the aic7xxx card's nonvolatile region in the ELCR, but I could never find out how to do this. Bus front end code shouldn't have to know about level/edge triggered IRQs. So long as the ELCR is guaranteed to work. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs problems
On Wed, Nov 08, 2000 at 10:18:18AM +0100, urded wrote: I updated my sources using cvsup, and i am unable to make the world : the message i get is : === doc /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/gperf/doc created for /usr/src/gnu/usr.bin/gperf/doc make: don't know how to make bool-array.cc. Stop You probably have a stale /usr/obj, or stray files in your source tree. Kris PGP signature
Re: vx driver patch
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : Bus front end code shouldn't have to know about level/edge triggered IRQs. The cardbus code, for example, will or in the RF_SHAREABLE bit when appropriate. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: Speaking of that, I'd like to see the EISA code move to be more like PCI. We should see if there is something at slot 0 and only then attempt to probe for sub-devices on the bus. Humm... I've got EISA BIOS extension code that correctly returns IDs but not resources for a given slot. I suspect that nobody actually implemented that part of the spec. The only reason this isn't done is because I, due to the fledgling nature of the EISA code and the ahc VL card's almost looking like EISA cards, did the wrong thing here. We also need to be verifying that io ranges required to probe for slots are not already claimed by other devices before we blindly access them. For this to all work with the VL ahc cards, the EISA code will have to release all resources associated with empty slots and the ahc driver will have to grow an ISA front end. The EISA code currently doesn't reserve resources for empty slots. I'd like to make the bus driver reserve all EISA specific address space though. I'm willing to help out on this work (still have a functional EISA machine), but I stopped short last time over concern on how to support Alpha/PA-RISC machines that might have multiple EISA busses. I can't see how multiple EISA busses would be possible. While a PCI-EISA bridge might make it easier, you've only got one valid set of IO port ranges and ELCR ports. I suppose you could remap the address space but who needs more than 10 EISA slots anyway? I've got uncommitted code that ties it to the ELCR. Is this stuff documented anywhere? I've always wanted to gain access to the aic7xxx card's nonvolatile region in the ELCR, but I could never find out how to do this. Humm... Try ftp://ftp.jurai.net/users/winter/eisabook.zip I can't remember where I got it at the moment but its a pretty good reference. Bus front end code shouldn't have to know about level/edge triggered IRQs. So long as the ELCR is guaranteed to work. It is. I've been running the code for almost 6 months. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Warner Losh wrote: The cardbus code, for example, will or in the RF_SHAREABLE bit when appropriate. Right, but the drivers that are consumers of the PCI or CARDBUS bus interface shouldn't have to deal with RF_SHAREABLE; the bus driver should do that. I grant you that this isn't the case at the moment but it should be. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
In message [EMAIL PROTECTED] "Matthew N. Dodd" writes: : On Wed, 8 Nov 2000, Warner Losh wrote: : The cardbus code, for example, will or in the RF_SHAREABLE bit when : appropriate. : : Right, but the drivers that are consumers of the PCI or CARDBUS bus : interface shouldn't have to deal with RF_SHAREABLE; the bus driver should : do that. I grant you that this isn't the case at the moment but it should : be. We are in violent agreement. The cardbus bridge code is the one that adds RF_SHAREABLE in the right places. This should allow us, in the fullness of time, to share interrupts for the 16-bit cards in cardbus sockets, for example, w/o sharing them for those cards in a i82365SL socket. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
The only reason this isn't done is because I, due to the fledgling nature of the EISA code and the ahc VL card's almost looking like EISA cards, did the wrong thing here. We also need to be verifying that io ranges required to probe for slots are not already claimed by other devices before we blindly access them. For this to all work with the VL ahc cards, the EISA code will have to release all resources associated with empty slots and the ahc driver will have to grow an ISA front end. The EISA code currently doesn't reserve resources for empty slots. I'd like to make the bus driver reserve all EISA specific address space though. This would prevent an ISA card that just happens to use an EISA like identification scheme from attaching after EISA. Unfortunately, the 2842VL card does this. I'm willing to help out on this work (still have a functional EISA machine), but I stopped short last time over concern on how to support Alpha/PA-RISC machines that might have multiple EISA busses. I can't see how multiple EISA busses would be possible. While a PCI-EISA bridge might make it easier, you've only got one valid set of IO port ranges and ELCR ports. I suppose you could remap the address space but who needs more than 10 EISA slots anyway? I just want to make sure that we at least support the EISA Alpha machines. I honestly don't know how they were set up. Is this stuff documented anywhere? I've always wanted to gain access to the aic7xxx card's nonvolatile region in the ELCR, but I could never find out how to do this. Humm... Try ftp://ftp.jurai.net/users/winter/eisabook.zip I can't seem to fetch it. Permission denied. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: Try ftp://ftp.jurai.net/users/winter/eisabook.zip I can't seem to fetch it. Permission denied. Damn firewall. Try with passive mode off. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unwanteed halt powerdown under -current (linuxerator?)
Not really. See my previous mail. It seems that a SYSV4 Syscall maps to the evil call. Unless you had the SVR4 module loaded, it would still have been run as a FreeBSD binary, which would give you exactly the same behaviour. Is it possible to refuse to run the binary, unless it is FreeBSD branded? It would seem that FreeBSD branding should be there, and that a non-matching branding should be result in a failure. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
The EISA code currently doesn't reserve resources for empty slots. I'd like to make the bus driver reserve all EISA specific address space though. This would prevent an ISA card that just happens to use an EISA like identification scheme from attaching after EISA. Unfortunately, the 2842VL card does this. There are a huge number of VESA Localbus cards that identify as EISA cards, including having all the EISA device identifier stuff in tehir ROMs. The disk controllers are the worst, but I have seen at least two video boards that do the same thing. Though I'd like to deprecate VESA Localbus as an abomination, I guess it has to be supported. Maybe it would be possible to have a separate "VLBus" bus that went in before the EISA bus? Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Terry Lambert wrote: Maybe it would be possible to have a separate "VLBus" bus that went in before the EISA bus? I'm still not clear as to why we need to differentiate them. There really is no requirement that slot 0 be present (other than it being standard and all.) Can we even tell if which EISA devices are really VL devices in disguise? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
I'm still not clear as to why we need to differentiate them. There really is no requirement that slot 0 be present (other than it being standard and all.) Can we even tell if which EISA devices are really VL devices in disguise? The only reason is to return the EISA probe to a read-only probe. The ahc VL cards require that their ID0 register be written too prior to reading the ID byte. This isn't required for true EISA cards and may prove harmful to other devices that just happen to be in that space. For instance, some PCI devices can be identified as EISA cards if you probe the full EISA bus blindly. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Wed, 8 Nov 2000, Justin T. Gibbs wrote: The only reason is to return the EISA probe to a read-only probe. The ahc VL cards require that their ID0 register be written too prior to reading the ID byte. Humm... I had wondered why that was there. Is there a way to detect VLB devices some other way? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
Humm... I had wondered why that was there. Is there a way to detect VLB devices some other way? This is specific to the aha2842 and is the only way I know of detecting those boards. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: licq after crt* change
On Wed, Nov 08, 2000 at 12:46:43PM +0300, Dmitry Valdov wrote: licq doesn't work since crt* change.. (coredumps) Any workaround? (recompile if licq qt doesn't help). /usr/ports/net/licq IIRC, the discussion about that found that it wasn't crt*'s fault but rather a bug in the dynamic linker. John Polstra fixed it and MFC'd yesterday. Please upgrade and try again. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/defaults/rc.conf
On Wed 2000-11-08 (09:30), Mikel wrote: I've had been considering running xinted for some time now, and thanks to Forest's suggestions I've been able to successfully get it up and running smoothly. I am personnaly left wondering why not just replact inetd altogether with this version? It certainly enhances security a bit. How does it enhance security? My main concern: (nbm@scythe) /usr/src/usr.sbin/inetd find . -type f -name "*.c" | xargs wc -l | grep total 2933 total vs: (nbm@scythe) /home/nbm/security/xinetd-2.1.8.9pre10 find . -type f -name "*.c" | xargs wc -l | grep total 23149 total Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mergemaster and $FreeBSD$
My machines get their source code from a local CVS mirror of the FreeBSD source tree, which is at /home/cvs/freebsd/src.. we have our own CVSROOT stuff of course. So when stuff is checked out of the freebsd/* repostitories, the $FreeBSD$ tags don't get substituted correctly. This causes mergemaster to list a zillion files as having differences in only this string every upgrade.. even worse, mergemaster in some cases seems to be comparing only the $FreeBSD$ strings and incorrectly concluding that certain files don't need upgrading, when in fact they do. So.. what stuff in /home/cvs/CVSROOT can I change so that sources in freebsd/* get $FreeBSD$ substitution, but other sources get the normal $Id$ substitution? Surely someone has solved this already.. ? Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: licq after crt* change
In article [EMAIL PROTECTED], Will Andrews [EMAIL PROTECTED] wrote: On Wed, Nov 08, 2000 at 12:46:43PM +0300, Dmitry Valdov wrote: licq doesn't work since crt* change.. (coredumps) Any workaround? (recompile if licq qt doesn't help). /usr/ports/net/licq IIRC, the discussion about that found that it wasn't crt*'s fault but rather a bug in the dynamic linker. John Polstra fixed it and MFC'd yesterday. Please upgrade and try again. Well ... the problem I fixed didn't involve any core dumps. :-) It's probably something different. I'd need to see a stack trace to know for sure. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
"Matthew N. Dodd" wrote: On Wed, 8 Nov 2000, Terry Lambert wrote: Maybe it would be possible to have a separate "VLBus" bus that went in before the EISA bus? I'm still not clear as to why we need to differentiate them. There really is no requirement that slot 0 be present (other than it being standard and all.) Can we even tell if which EISA devices are really VL devices in disguise? Do you want to know what is even funnier? One of my onboard ahc *PCI* controllers (7895 based I think) also responds to the EISA probes if I enable EISA. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vx driver patch
On Thu, 9 Nov 2000, Peter Wemm wrote: Do you want to know what is even funnier? One of my onboard ahc *PCI* controllers (7895 based I think) also responds to the EISA probes if I enable EISA. What machine and what does the output from the probe/attach look like? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird errors during kernel build
At 13:37 6-11-00 -0500, drwilco wrote: Yes I do have PERL_THREADED=true. Or rather I did have it until a minute ago =) Building world kernel was succesful without PERL_THREADED. Maybe a warning should be added to /etc/make.conf? DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] Please review and commit (Re: if_tap and devfs)
Hello All, anyone wants to review and commit the following patch. thanks, emax __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ if_tap.c.diff
Re: [PATCH] Please review and commit (Re: if_tap and devfs)
I just glanced at it and see no major mistakes. Sorry I don't have time for a real review. Poul-Henning In message [EMAIL PROTECTED], Maksim Yevmenkin writes: --0-783368690-973704660=:11219 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello All, anyone wants to review and commit the following patch. thanks, emax __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ --0-783368690-973704660=:11219 Content-Type: application/x-unknown; name="if_tap.c.diff" Content-Transfer-Encoding: base64 Content-Description: if_tap.c.diff Content-Disposition: attachment; filename="if_tap.c.diff" KioqIGlmX3RhcC5jLm9yaWcJTW9uIE5vdiAgNiAwOToyNDowOCAyMDAwCi0t LSBpZl90YXAuYwlNb24gTm92ICA2IDEwOjI2OjM1IDIwMDAKKioqKioqKioq KioqKioqCioqKiA3OSw4NCAqKioqCi0tLSA3OSw4NSAtLS0tCiAgc3RhdGlj IGludCAJCXRhcG1vZGV2ZW50CV9fUCgobW9kdWxlX3QsIGludCwgdm9pZCAq KSk7CiAgCiAgLyogZGV2aWNlICovCisgc3RhdGljIHZvaWQJCXRhcGNsb25l CV9fUCgodm9pZCAqLCBjaGFyICosIGludCwgZGV2X3QgKikpOwogIHN0YXRp YyB2b2lkCQl0YXBjcmVhdGUJX19QKChkZXZfdCkpOwogIAogIC8qIG5ldHdv cmsgaW50ZXJmYWNlICovCioqKioqKioqKioqKioqKgoqKiogMTMxLDE1NyAq KioqCiAgCWludAkJIHR5cGU7CiAgCXZvaWQJCSpkYXRhOwogIHsKISAJc3Rh dGljIGludAkJIGF0dGFjaGVkID0gMDsKISAJc3RydWN0IGlmbmV0CQkqaWZw ID0gTlVMTDsKISAJaW50CQkJIHVuaXQsIHM7CiAgCiAgCXN3aXRjaCAodHlw ZSkgewogIAljYXNlIE1PRF9MT0FEOgogIAkJaWYgKGF0dGFjaGVkKQogIAkJ CXJldHVybiAoRUVYSVNUKTsKICAKICAJCWNkZXZzd19hZGQoJnRhcF9jZGV2 c3cpOwogIAkJYXR0YWNoZWQgPSAxOwogIAlicmVhazsKICAKISAJY2FzZSBN T0RfVU5MT0FEOgogIAkJaWYgKHRhcHJlZmNudCA+IDApCiAgCQkJcmV0dXJu IChFQlVTWSk7CiAgCiAgCQljZGV2c3dfcmVtb3ZlKCZ0YXBfY2RldnN3KTsK ICAKICAJCXVuaXQgPSAwOwogIAkJd2hpbGUgKHVuaXQgPD0gdGFwbGFzdHVu aXQpIHsKICAJCQlzID0gc3BsaW1wKCk7CiAgCQkJVEFJTFFfRk9SRUFDSChp ZnAsICZpZm5ldCwgaWZfbGluaykKICAJCQkJaWYgKChzdHJjbXAoaWZwLT5p Zl9uYW1lLCBUQVApID09IDApIHx8Ci0tLSAxMzIsMTY0IC0tLS0KICAJaW50 CQkgdHlwZTsKICAJdm9pZAkJKmRhdGE7CiAgewohIAlzdGF0aWMgaW50CQlh dHRhY2hlZCA9IDA7CiEgCXN0YXRpYyBldmVudGhhbmRsZXJfdGFnCWVoX3Rh ZyA9IE5VTEw7CiAgCiAgCXN3aXRjaCAodHlwZSkgewogIAljYXNlIE1PRF9M T0FEOgogIAkJaWYgKGF0dGFjaGVkKQogIAkJCXJldHVybiAoRUVYSVNUKTsK ICAKKyAJCWVoX3RhZyA9IEVWRU5USEFORExFUl9SRUdJU1RFUihkZXZfY2xv bmUsIHRhcGNsb25lLCAwLCAxMDAwKTsKICAJCWNkZXZzd19hZGQoJnRhcF9j ZGV2c3cpOwogIAkJYXR0YWNoZWQgPSAxOwogIAlicmVhazsKICAKISAJY2Fz ZSBNT0RfVU5MT0FEOiB7CiEgCQlpbnQJdW5pdDsKISAKICAJCWlmICh0YXBy ZWZjbnQgPiAwKQogIAkJCXJldHVybiAoRUJVU1kpOwogIAorIAkJRVZFTlRI QU5ETEVSX0RFUkVHSVNURVIoZGV2X2Nsb25lLCBlaF90YWcpOwogIAkJY2Rl dnN3X3JlbW92ZSgmdGFwX2NkZXZzdyk7CiAgCiAgCQl1bml0ID0gMDsKICAJ CXdoaWxlICh1bml0IDw9IHRhcGxhc3R1bml0KSB7CisgCQkJaW50CQkgczsK KyAJCQlzdHJ1Y3QgaWZuZXQJKmlmcCA9IE5VTEw7CisgCiAgCQkJcyA9IHNw bGltcCgpOwogIAkJCVRBSUxRX0ZPUkVBQ0goaWZwLCAmaWZuZXQsIGlmX2xp bmspCiAgCQkJCWlmICgoc3RyY21wKGlmcC0+aWZfbmFtZSwgVEFQKSA9PSAw KSB8fAoqKioqKioqKioqKioqKioKKioqIDE3OSwxODUgKioqKgogIAkJfQog IAogIAkJYXR0YWNoZWQgPSAwOwohIAlicmVhazsKICAKICAJZGVmYXVsdDoK ICAJCXJldHVybiAoRU9QTk9UU1VQUCk7Ci0tLSAxODYsMTkyIC0tLS0KICAJ CX0KICAKICAJCWF0dGFjaGVkID0gMDsKISAJfSBicmVhazsKICAKICAJZGVm YXVsdDoKICAJCXJldHVybiAoRU9QTk9UU1VQUCk7CioqKioqKioqKioqKioq KgoqKiogMTg3LDE5MiAqKioqCi0tLSAxOTQsMjM0IC0tLS0KICAKICAJcmV0 dXJuICgwKTsKICB9IC8qIHRhcG1vZGV2ZW50ICovCisgCisgCisgLyoKKyAg KiBERVZGUyBoYW5kbGVyCisgICoKKyAgKiBXZSBuZWVkIHRvIHN1cHBvcnQg dHdvIGtpbmQgb2YgZGV2aWNlcyAtIHRhcCBhbmQgdm1uZXQKKyAgKi8KKyBz dGF0aWMgdm9pZAorIHRhcGNsb25lKGFyZywgbmFtZSwgbmFtZWxlbiwgZGV2 KQorIAl2b2lkCSphcmc7CisgCWNoYXIJKm5hbWU7CisgCWludAkgbmFtZWxl bjsKKyAJZGV2X3QJKmRldjsKKyB7CisgCWludAkgdW5pdCwgbWlub3I7Cisg CWNoYXIJKmRldmljZV9uYW1lID0gTlVMTDsKKyAKKyAJaWYgKCpkZXYgIT0g Tk9ERVYpCisgCQlyZXR1cm47CisgCisgCWRldmljZV9uYW1lID0gVEFQOwor IAlpZiAoZGV2X3N0ZGNsb25lKG5hbWUsIE5VTEwsIGRldmljZV9uYW1lLCAm dW5pdCkgIT0gMSkgeworIAkJZGV2aWNlX25hbWUgPSBWTU5FVDsKKyAKKyAJ CWlmIChkZXZfc3RkY2xvbmUobmFtZSwgTlVMTCwgZGV2aWNlX25hbWUsICZ1 bml0KSAhPSAxKQorIAkJCXJldHVybjsKKyAKKyAJCW1pbm9yID0gKHVuaXQg fCAgVk1ORVRfREVWX01BU0spOworIAl9CisgCWVsc2UKKyAJCW1pbm9yID0g dW5pdDsKKyAKKyAJKmRldiA9IG1ha2VfZGV2KCZ0YXBfY2RldnN3LCBtaW5v ciwgVUlEX1JPT1QsIEdJRF9XSEVFTCwgMDYwMCwgIiVzJWQiLAorIAkJCWRl dmljZV9uYW1lLCB1bml0KTsKKyB9IC8qIHRhcGNsb25lICovCiAgCiAgCiAg LyoK --0-783368690-973704660=:11219-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HPT370 RAID - booting
It seems [Ivan Debn_r] wrote: I'm just looking at the disk partitions, and the first 63 sectors are by default marked as unused. So is it really nescessary to have the ofset in the ar driver for HPT? I would prefer to have the requirement to not to use dangerously dedicated, but be able to boot the drive and install on it as a normal one. Well, for all I care it can be changed, and I put a note in there to mail you when users have RAID's that suddenly disappear :) Seriously I'm tempted to have a chat with HighPoint if they could maybe change this to use a setup like Promise do Correct me if I'm wrong, but in RAID1 it is essential to be able to take one of the drives and boot from it almost as if it was singe simple disk. How does the driver handles situation when there is one of the mirror drives broken or missing ? The driver doesnt handle that, its up to the BIOS for now. Is it possible to query the driver to check, if the drives are OK from the userland ? No, again the BIOS is to be used for now, if the RAID is broken it wont be configured in the driver. This might change in the (not too distant) future, but for now this is all there is, but I thought this feature was essential enough to put it in as is. On the bright side remember that FreeBSD is the only free OS that has support for these ATA RAID cards and tagged queueing, but I only have this much spare time to do it. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: HPT370 RAID - booting
Thanks for feedback. Please tell me if tou find this scenario possible: I will install on one of the drives - ad0. It will work normally. Than a few day, weeks, later, when we decide that the ar is fine, go to the RAID bios, duplicate the disk ad0 to ad1 and RAID1 them. Other than changing /etc/fstab entries, it should work fine - or am I wrong ? I understand that it will definitely not work, if the ar driver offsets its partitions by 10. But with offset=0, will I be fine? Those are just my thoughs, because I have to make that machine work, and unfortunately have not that much time to experiment. You have been very helpful, thanks for great work on ata. If I knew, that Promise is that better supported, I would go for that. But anyway, HPT was on the mainboard, and it looked very attractive after you CVS messages. Maybe we should mention these shortcomings somewhere. Ivan -Original Message- From: Soren Schmidt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 08, 2000 6:20 PM To: [Ivan Debn_r] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: HPT370 RAID - booting It seems [Ivan Debn_r] wrote: I'm just looking at the disk partitions, and the first 63 sectors are by default marked as unused. So is it really nescessary to have the ofset in the ar driver for HPT? I would prefer to have the requirement to not to use dangerously dedicated, but be able to boot the drive and install on it as a normal one. Well, for all I care it can be changed, and I put a note in there to mail you when users have RAID's that suddenly disappear :) Seriously I'm tempted to have a chat with HighPoint if they could maybe change this to use a setup like Promise do Correct me if I'm wrong, but in RAID1 it is essential to be able to take one of the drives and boot from it almost as if it was singe simple disk. How does the driver handles situation when there is one of the mirror drives broken or missing ? The driver doesnt handle that, its up to the BIOS for now. Is it possible to query the driver to check, if the drives are OK from the userland ? No, again the BIOS is to be used for now, if the RAID is broken it wont be configured in the driver. This might change in the (not too distant) future, but for now this is all there is, but I thought this feature was essential enough to put it in as is. On the bright side remember that FreeBSD is the only free OS that has support for these ATA RAID cards and tagged queueing, but I only have this much spare time to do it. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA RAID - sysinstall solution
OK, i tested this. Sysinstall works fine now, and the system installs OK
from the SNAP 5 ftp server. ON reboot, however, the computer thing refuses
to boot of the RAID device. After the BIOS message "verifying
DMI.."(or similar) the system hangs.
Does anybody know why this could be?
jan
On Mon, 6 Nov 2000, [iso-8859-2] Ivan Debnár wrote:
I'm using HTP 370 ATA RAID controller, which should have been supported in
stable and current according to CVS messages from Soren.
But as few of us found, it is not, in fact.
KERNEL recognises device ar0.
4.2 sysinstall does not offer ar0 as disk drive
5.0-current sysinstall offers it, but is not able to create slices on it.
(DEBUG: MakeDev unknown major/minor).
So I looked through sysinstall source and libdisk source and guess what ! -
libdisk doesn't know about ar? devices yet.
Could someone update the libdisk source in stable and current to include the
device?
The files affected are:
/src/lib/libdisk/create_chunk.c
/src/lib/libdisk/disk.c
--- disk.c.orig Thu Sep 14 14:10:45 2000
+++ disk.c Mon Nov 6 23:41:45 2000
@@ -461,7 +461,7 @@
}
#endif
-static char * device_list[] = {"wd", "ad", "da", "wfd", "fla", "idad",
"mlxd", "amrd", "twed", 0};
+static char * device_list[] = {"wd", "ad", "da", "wfd", "fla", "idad",
"mlxd", "amrd", "twed", "ar", 0};
char **
Disk_Names()
--- create_chunk.c.orig Fri Jul 14 08:30:59 2000
+++ create_chunk.c Mon Nov 6 23:46:59 2000
@@ -300,6 +300,8 @@
cmaj = 147, p += 4;
else if (!strncmp(p, "da", 2)) /* CAM support */
cmaj = 13, p += 2;
+else if (!strncmp(p, "ar", 2)) /* ATA RAID */
+ cmaj = 157, p += 2;
else {
msgDebug("MakeDev: Unknown major/minor for devtype %s\n", p);
return 0;
Unfortunately I am not able to compile and try this, but if someone can
create a set of 4-STABLE or 5-CURRENT installation disks and e-mail them,
I'm willing to try.
Those diffs are against 2000-10-30 stable, so they are just to show changes
what I thing should be done to actual current files. This should make
Current install on ATA RAID hopefully. I don't know, if it will make STABLE
sysinstall recognize the ar device. I hope so.
Ivan Debnár
Online Consulting, s.r.o.
tel.://+421 88 4146721
fax://+421 88 4142231
http://www.o-c.sk
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ATA RAID - sysinstall solution
OK, i tested this. Sysinstall works fine now, and the system installs OK from the SNAP 5 ftp server. ON reboot, however, the computer thing refuses to boot of the RAID device. After the BIOS message "verifying DMI.."(or similar) the system hangs. Because of the offset 10, sysinstall wrote the fdisk table to the wrong location on the disk... The following little patch fixes this. This should work for both 4 and 5 trees: - look for .. += rdp-offset in ata-raid.c - make this line conditional if (buf1-drive) .. += rdp-offset Of course, as Soren pointed out, you're risking screwing your first partition if you're NOT using an fdisk compatible layout. However, without this patch the RAID is not bootable, so for me the case is clear:-) I've used this with a RAID0 here successfully (incl. booting off it). About the other suggestion, initially installing on the single drive, and then mirroring it (turning it into a RAID1): should work, but be careful not to use the original disk up to the last cylinder. The RAID will be (just) slightly smaller than the individual disk, and if you filled your single disk to the end, FreeBSD will reject the last partition as being out of disk limits. You'll have to adjust the disklabel after the change. Of course, this will also only work with the above patch, or the disklabel won't be found. Good luck, Markus BTW: and many thanks to Soren for his work! -- KPNQwest Switzerland Ltd P.O. Box 1600, Hohlstrasse 550, CH-8048 Zuerich Tel: +41-1-439-4390, Fax: +41-1-439-4391 Markus Wild, Manager Network Operations, e-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ATA RAID - sysinstall solution
I have the same problem on 4, and I have a response from Soren: --- start --- Ugh, booting from the HPT RAID is not supported as is. This is due to the HPT using sector #9 for the RAID config stuff, this is not compatible with our bootcode/loader as in some circumstances it would happily overwrite this config info, trashing the RAID in the process. Therefore the code uses an offset of 10 into the physical disks. However if you always use an fdisk partition table, and newer uses the first 10 sectors on the disk, you could make the offset 0 in the driver, and have booting work that way, or buy a promise :) I'm not sure I've used the rigth thing as default here, but at least this was POLA seen with my dangerously dedicated eyes... --- end --- This is bad, but I hope we will help Soren to sort thing out on how to get to do it. We will keep in touch. Ivan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 08, 2000 4:44 PM To: Ivan Debnr Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: ATA RAID - sysinstall solution OK, i tested this. Sysinstall works fine now, and the system installs OK from the SNAP 5 ftp server. ON reboot, however, the computer thing refuses to boot of the RAID device. After the BIOS message "verifying DMI.."(or similar) the system hangs. Does anybody know why this could be? jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HPT370 RAID - booting
I'm just looking at the disk partitions, and the first 63 sectors are by default marked as unused. So is it really nescessary to have the ofset in the ar driver for HPT? I would prefer to have the requirement to not to use dangerously dedicated, but be able to boot the drive and install on it as a normal one. Correct me if I'm wrong, but in RAID1 it is essential to be able to take one of the drives and boot from it almost as if it was singe simple disk. How does the driver handles situation when there is one of the mirror drives broken or missing ? Is it possible to query the driver to check, if the drives are OK from the userland ? Ivan Debnr Online Consulting, s.r.o. tel.://+421 88 4146721 fax://+421 88 4142231 http://www.o-c.sk BEGIN:VCARD VERSION:2.1 N:Debnár;Ivan FN:Ivan Debnár ORG:Online Consulting, s.r.o. TEL;WORK;VOICE:+421 (88) 4146721 TEL;HOME;VOICE:+421 (88) 4171223 TEL;CELL;VOICE:+421 (903) 506197 TEL;WORK;FAX:+421 (88) 4142231 ADR;WORK:;;Rudlovská cesta 53;Banská Bystrica;;974 01;Slovak Republic LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Rudlovsk=E1 cesta 53=0D=0ABansk=E1 Bystrica 974 01=0D=0ASlovak Republic BDAY:19770829 EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:2922T091913Z END:VCARD
