Re: cdrecord produces broken CDs on -CURRENT
On Mon, 26 Nov 2001, Kenneth D. Merry wrote: So did you try the statically linked -stable binary on -current? Yes, I used the newest version from the ports (compiled on -CURRENT) and the staticly linked from -STABLE both on -CURRENT, and the CDs are identical. Is it completely static? (i.e. ldd cdrecord should report that it isn't a dynamic executable) Yes it is. That may help narrow the problem down somewhat. I'm not sure, though, whether the -stable binary will work with the pass interface on -current. It doesn't matter wether I take cdrecord from -CURRENT or from -STABLE, the CDs (I burn on -CURRENT) are identical. Are there any areas with good data on the CD? i.e. can you see any pattern to the corruption? If you compare the same CD burned from -current and -stable you might begin to see a patern. Yes, about half of the CD is correct, and the rest is filled up with binary zero. If there are data other then zero on the CD, then they are correct. Is the table of contents correct? I don't know, but I don't think so. The first 60kB (exact 60kB!) of the broken CD are zeros, and I can't mount it. Ken -- Kenneth Merry [EMAIL PROTECTED] Ciao Christoph :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord produces broken CDs on -CURRENT
On Mon, 26 Nov 2001, Joerg Wunsch wrote: Kenneth D. Merry [EMAIL PROTECTED] wrote: Are there any areas with good data on the CD? i.e. can you see any pattern to the corruption? If you compare the same CD burned from -current and -stable you might begin to see a patern. I tried a test-burn with a FreeBSD-current from yesterday, on a YAMAHA CRW2100S 1.0H writer (writing a CD-RW), and can't see any failure. It's only a small directory tree, but MD5-comparing the tree on the CD-RW with the original on UFS only reveals the added TRANS.TBL files, no other differences. # cdrecord -version Cdrecord 1.9 (i386-unknown-freebsd5.0) Copyright (C) 1995-2000 Jörg Schilling # ls -l `which cdrecord` -r-xr-xr-x 1 root wheel - 163392 Apr 4 2001 /usr/local/bin/cdrecord* # ldd `which cdrecord` /usr/local/bin/cdrecord: libcam.so.2 = /usr/lib/libcam.so.2 (0x2808a000) libc.so.5 = /usr/lib/libc.so.5 (0x2809a000) libsbuf.so.2 = /usr/lib/libsbuf.so.2 (0x2814e000) (I haven't rebuilt the binary after upgrading -current, for months as you can see.) Maybe there are other problems. But I had no problems (burning CDs on -CURRENT) until the beginning of october. (I run make world about once a week). And with -STABLE everything is fine until now. It is the same box, I (try to) burn the same image, the only difference is the FreeBSD version. So it can't be only a hardware problem. Ciao Christoph :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic changing screen mode with vidcontrol
VESA is broked. Remove VESA from your config. Been this way for months. It also will panic once in a VESA mode, such as my favorite and yours, 132x60, when switching from vty to vty. Peter Jeremy wrote: Having installed a new kernel and userland from sources about a day old, my vidcontrol command now causes a panic: Fatal trap 12: page fault while in vm86 mode fault virtual address = 0xc359b fault code = user read, page not present instruction pointer = 0xc000:0x359b stack pointer = 0x0:0xf82 frame pointer = 0x0:0xfdc code segment= base 0x2, limit 0x5004f, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags= interrupt enabled, resume, vm86, IOPL = 0 current process = 57775 (vidcontrol) The backtrace shows nothing useful - gdb doesn't seem to handle tracing through vm86 :-(. The command I used was vidcontrol 132x60 after confirming that this was listed in vidcontrol -i mode. I have previously been using VESA_132x60, but that also panics now. Any suggestions where to look? Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali, 1995 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic changing screen mode with vidcontrol
Andrew Kenneth Milton wrote +---[ Peter Jeremy ]-- | Having installed a new kernel and userland from sources about a day | old, my vidcontrol command now causes a panic: [snip] | The command I used was vidcontrol 132x60 after confirming that | this was listed in vidcontrol -i mode. I have previously been | using VESA_132x60, but that also panics now. Was X running ? I get a panic on changing to VESA modes when X is already running. It will do this regardless if X is running. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali, 1995 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic changing screen mode with vidcontrol
+---[ Jim Bryant ]-- | Andrew Kenneth Milton wrote | | +---[ Peter Jeremy ]-- | | Having installed a new kernel and userland from sources about a day | | old, my vidcontrol command now causes a panic: | | [snip] | | | The command I used was vidcontrol 132x60 after confirming that | | this was listed in vidcontrol -i mode. I have previously been | | using VESA_132x60, but that also panics now. | | Was X running ? | | I get a panic on changing to VESA modes when X is already running. | | | It will do this regardless if X is running. Not for me d8) Only when I have X running. When I don't have X I can happily switch between different consoles and modes. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lomac import broke world
In article [EMAIL PROTECTED]
Andrey A. Chernov [EMAIL PROTECTED] wrote:
cc -O -pipe -march=pentiumpro -DSETPROCTITLE -DLOGIN_CAP -DVIRTUAL_HOSTING
-Wall
-DINET6 -I/usr/src/libexec/ftpd -Dmain=ls_main
-I/usr/src/libexec/ftpd/../../bin/ls -DUSE_PAM
-o ftpd ftpd.o ftpcmd.o logwtmp.o popen.o ls.o cmp.o
print.o
util.o -lmd -lcrypt -lutil -lopie -lpam
ls.o: In function `display':
ls.o(.text+0x9b0): undefined reference to `lomac_start'
ls.o(.text+0xd02): undefined reference to `get_lattr'
ls.o(.text+0xfe2): undefined reference to `lomac_stop'
*** Error code 1
I use the next patch to buildworld :
N.Dudorov
Index: Makefile
===
RCS file: /scratch/CVS/src/libexec/ftpd/Makefile,v
retrieving revision 1.44
diff -b -u -r1.44 Makefile
--- Makefile9 Jul 2001 17:46:24 - 1.44
+++ Makefile27 Nov 2001 11:04:44 -
@@ -19,7 +19,7 @@
LSDIR= ../../bin/ls
.PATH: ${.CURDIR}/${LSDIR}
-SRCS+= ls.c cmp.c print.c util.c
+SRCS+= ls.c cmp.c print.c util.c lomac.c
CFLAGS+=-Dmain=ls_main -I${.CURDIR}/${LSDIR}
.if !defined(NOPAM)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
Found this to be helpful after seeing: stage 2: cleaning up the object tree ... === usr.bin/tip .depend, line 886: Inconsistent operator for tip make: fatal errors encountered -- cannot continue and the tail end of /usr/obj/usr/src/usr.bin/tip/.depend (which was 886 lines long) was: /usr/obj/usr/src/i386/usr/include/errno.h \ /usr/obj/usr/src/i386/usr/include/limits.h \ /usr/obj/usr/src/i386/usr/include/sys/syslimits.h tip: /usr/obj/usr/src/i386/usr/lib/libc.a I don't use -DNOCLEAN or anything like that, so it looks as if forcibly removing the /usr/obj/usr/src/usr.bin/tip directory does something that the normal make buildworld does not... and which is useful in this case. Still building, but I'm way beyond that stage, at least. Cc:ing Warner, in case UPDATING might merit a brief mention. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, Nov 27, 2001 at 06:35:49AM -0800, David Wolfskill wrote: Found this to be helpful after seeing: stage 2: cleaning up the object tree ... === usr.bin/tip .depend, line 886: Inconsistent operator for tip make: fatal errors encountered -- cannot continue and the tail end of /usr/obj/usr/src/usr.bin/tip/.depend (which was 886 lines long) was: /usr/obj/usr/src/i386/usr/include/errno.h \ /usr/obj/usr/src/i386/usr/include/limits.h \ /usr/obj/usr/src/i386/usr/include/sys/syslimits.h tip: /usr/obj/usr/src/i386/usr/lib/libc.a I don't use -DNOCLEAN or anything like that, so it looks as if forcibly removing the /usr/obj/usr/src/usr.bin/tip directory does something that the normal make buildworld does not... and which is useful in this case. Still building, but I'm way beyond that stage, at least. Cc:ing Warner, in case UPDATING might merit a brief mention. Simply removing the /usr/obj/usr/src/usr.bin/tip/.depend file should work as well. And yes, mentioning this in UPDATING ASAP would be great. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, Nov 27, 2001 at 06:35:49AM -0800, David Wolfskill wrote: Found this to be helpful after seeing: stage 2: cleaning up the object tree ... === usr.bin/tip .depend, line 886: Inconsistent operator for tip make: fatal errors encountered -- cannot continue and the tail end of /usr/obj/usr/src/usr.bin/tip/.depend (which was 886 lines long) was: /usr/obj/usr/src/i386/usr/include/errno.h \ /usr/obj/usr/src/i386/usr/include/limits.h \ /usr/obj/usr/src/i386/usr/include/sys/syslimits.h tip: /usr/obj/usr/src/i386/usr/lib/libc.a I don't use -DNOCLEAN or anything like that, so it looks as if forcibly removing the /usr/obj/usr/src/usr.bin/tip directory does something that the normal make buildworld does not... and which is useful in this case. Still building, but I'm way beyond that stage, at least. Cc:ing Warner, in case UPDATING might merit a brief mention. Simply removing the /usr/obj/usr/src/usr.bin/tip/.depend file should work as well. And yes, mentioning this in UPDATING ASAP would be great. I don't think this is UPDATING material. People shouldn't be using -DNOCLEAN unless they understand the consequences. Cheers, -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, Nov 27, 2001 at 03:44:06PM +, Brian Somers wrote: On Tue, Nov 27, 2001 at 06:35:49AM -0800, David Wolfskill wrote: [...] I don't use -DNOCLEAN or anything like that, so it looks as if forcibly ^ removing the /usr/obj/usr/src/usr.bin/tip directory does something that the normal make buildworld does not... and which is useful in this case. Still building, but I'm way beyond that stage, at least. Cc:ing Warner, in case UPDATING might merit a brief mention. Simply removing the /usr/obj/usr/src/usr.bin/tip/.depend file should work as well. And yes, mentioning this in UPDATING ASAP would be great. I don't think this is UPDATING material. People shouldn't be using -DNOCLEAN unless they understand the consequences. Ahh, but he's not using -DNOCLEAN. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, Nov 27, 2001 at 03:44:06PM +, Brian Somers wrote:
On Tue, Nov 27, 2001 at 06:35:49AM -0800, David Wolfskill wrote:
Found this to be helpful after seeing:
stage 2: cleaning up the object tree
...
=== usr.bin/tip
.depend, line 886: Inconsistent operator for tip
make: fatal errors encountered -- cannot continue
and the tail end of /usr/obj/usr/src/usr.bin/tip/.depend (which was 886
lines long) was:
/usr/obj/usr/src/i386/usr/include/errno.h \
/usr/obj/usr/src/i386/usr/include/limits.h \
/usr/obj/usr/src/i386/usr/include/sys/syslimits.h
tip: /usr/obj/usr/src/i386/usr/lib/libc.a
I don't use -DNOCLEAN or anything like that, so it looks as if forcibly
removing the /usr/obj/usr/src/usr.bin/tip directory does something that
the normal make buildworld does not... and which is useful in this case.
Still building, but I'm way beyond that stage, at least.
Cc:ing Warner, in case UPDATING might merit a brief mention.
Simply removing the /usr/obj/usr/src/usr.bin/tip/.depend file should
work as well. And yes, mentioning this in UPDATING ASAP would be
great.
I don't think this is UPDATING material. People shouldn't be using
-DNOCLEAN unless they understand the consequences.
The problem is that those not using -DNOCLEAN are affected as well.
The explanation lies in the fact that before these changes were
repo-backed-out, tip used to be a PROG under usr.bin/tip, and
as such /usr/obj/usr/src/usr.bin/tip/.depend had a regular :
dependency line for tip. Now, tip is back again a SUBDIR,
and bsd.subdir.mk has the following line that correlates with
the dependency line from a stale .depend:
${SUBDIR}::
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, 27 Nov 2001 18:03:45 +0200, Ruslan Ermilov wrote: | Did you do a component build without `make obj'? That would leave | turds, and I'm pretty sure the buildworld target doesn't repeat the | cleandir target. | | depend is included by make(1) automatically, before a cleandir | target has a chance to be executed. Try this: Oh, bummer. All the more reason to have one's nightly CURRENT builds preceded with a rm -rf /usr/obj. :-) A ``rm -fr /usr/obj; make -DNOCLEAN buildworld'' is quicker than ``make buildworld'' anyway :*) Ciao, Sheldon. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, Nov 27, 2001 at 04:20:54PM +, Brian Somers wrote: A ``rm -fr /usr/obj; make -DNOCLEAN buildworld'' is quicker than ``make buildworld'' anyway :*) Really? Is this recommended? ==Michael Mad doc PR submitter Lucas -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
On Tue, Nov 27, 2001 at 04:20:54PM +, Brian Somers wrote: A ``rm -fr /usr/obj; make -DNOCLEAN buildworld'' is quicker than ``make buildworld'' anyway :*) Really? Is this recommended? Yes, except I meant ``rm -fr /usr/obj/*''. ==Michael Mad doc PR submitter Lucas -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
In message [EMAIL PROTECTED] Michael Lucas writes: : On Tue, Nov 27, 2001 at 04:20:54PM +, Brian Somers wrote: : : A ``rm -fr /usr/obj; make -DNOCLEAN buildworld'' is quicker than : ``make buildworld'' anyway :*) : : : Really? Is this recommended? Only unofficially :-) For a while I had /usr/obj on a separate partition that I'd newfs before each build. That was before I had a laptop that was fast enough to be able to build both current and stable on :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic changing screen mode with vidcontrol
On 27-Nov-01 Jim Bryant wrote: VESA is broked. Remove VESA from your config. Been this way for months. It also will panic once in a VESA mode, such as my favorite and yours, 132x60, when switching from vty to vty. Ouch, this is not good. This means vm86 is likely broke. Hmm, I wonder if the TSS is broken somehow? Can you narrow this down to a particular commit? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rm -rf /usr/obj/usr/src/usr.bin/tip helps build -CURRENT
In message [EMAIL PROTECTED] Brian Somers writes: : Simply removing the /usr/obj/usr/src/usr.bin/tip/.depend file should : work as well. And yes, mentioning this in UPDATING ASAP would be : great. simply removing .depend is not enough. I had to kill the whole tip directory. I got a different error when I didn't. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord produces broken CDs on -CURRENT
As Christoph Herrmann wrote: Maybe there are other problems. But I had no problems (burning CDs on -CURRENT) until the beginning of october. (I run make world about once a week). And with -STABLE everything is fine until now. It is the same box, I (try to) burn the same image, the only difference is the FreeBSD version. So it can't be only a hardware problem. I just tried it again, since i had to prepare a full FreeBSD 4.4-stable release CD anyway. It works for me. So it must be something that only appears on some hardware. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PC Card hang
My laptop is hanging when I boot it after this commit. The system hangs when pccardd is started. If no cards are installed, the boot proceeds without a problem and the system hangs when the first card is inserted. I have attached my kernel configuration and dmesg output from a kernel checked out right before this commit. Please let me know if I can provide any further information or assistance. Thanks for you help Jim Bloom [EMAIL PROTECTED] Modified files: sys/pccard i82365.h pcic.c pcic_isa.c pcic_pci.c Log: o Try to do 3.3V support better for the 6722 and 6729/30. o Bite the bullet and create controller types for the 6729 and also for the 673x. Rename the 672x to 6722. o Define minimal extended register info (just register 0xa for reading VS[12]). # I think the last version may have broken 673x controllers, but this should # fix them. Tested on the 6722, but not the 6729. Ideas from: Chiharu Shibata-san's article in bsd-nomads:15866 Revision ChangesPath 1.23 +18 -5 src/sys/pccard/i82365.h 1.169 +32 -14src/sys/pccard/pcic.c 1.23 +3 -3 src/sys/pccard/pcic_isa.c 1.106 +5 -5 src/sys/pccard/pcic_pci.c machine i386 cpu I486_CPU cpu I586_CPU ident LAPTOP maxusers32 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols options INVARIANTS options INVARIANT_SUPPORT # options MUTEX_DEBUG options WITNESS options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security options FFS #Berkeley Fast Filesystem options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console #optionsUSERCONFIG #boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options IPFIREWALL #firewall options IPDIVERT#divert sockets options DDB #kernel debugger # Obsolete option # options MD_NSECT=1 device isa # Add PCI to work around broken ATA driver # devicepci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc device atkbd device psm device vga # syscons is the default console driver, resembling an SCO console device sc # Floating point support - do not disable. device npx # Power management support (see LINT for more options) device apm # Advanced Power Management # PCCARD (PCMCIA) support device card device pcic # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip# TCP/IP over parallel device ppi # Parallel port interface device # ISA Ethernet NICs. device ed device miibus # Pseudo devices - the number indicates how many units to allocated. device loop# Network loopback device ether # Ethernet support device sl 1 # Kernel SLIP device ppp 1 # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory disks device pmtimer # Adjust system timer at wakeup time device random # for IPv6 device gif #IPv6 and IPv4 tunneling device faith #for IPv6 and IPv4 translation # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf
Re: PC Card hang
A later kernel (possibly today's source) say that it is a 6722 instead of a 672x. Other changes in the dmesg output (copied by hand since the machine does not survive) are : pcic0: Autodected 3.3V card (once per card) pcic0: reset 1 int is 0 stat is cc (once per card, stat was df or ff before) pcic0: reset 2 int is 60 stat is cc pcic0: reset 3 int is 60 stat is cc The machine is an old AST Ascentia 810N. Jim Warner Losh wrote: In message [EMAIL PROTECTED] Jim Bloom writes: : I have attached my kernel configuration and dmesg output from a kernel : checked out right before this commit. Please let me know if I can : provide any further information or assistance. What does one from right after say? It looks like you have a CLPD6722 in your machine... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PC Card hang
In message [EMAIL PROTECTED] Jim Bloom writes: : A later kernel (possibly today's source) say that it is a 6722 instead of a : 672x. Other changes in the dmesg output (copied by hand since the machine does : not survive) are : : : pcic0: Autodected 3.3V card (once per card) : pcic0: reset 1 int is 0 stat is cc(once per card, stat was df or ff before) : pcic0: reset 2 int is 60 stat is cc : pcic0: reset 3 int is 60 stat is cc : : The machine is an old AST Ascentia 810N. Thanks Jim. I hvae an old toshiba satelite that I thought had a topic in it when I bought it that turned out to have a 6722 in it. I'll see if I can get -current on it, but it may have to wait until after Dec 10th when I get back from Japan. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/conf files src/sys/dev/ciss ciss.c cissio.h cissreg.h cissvar.h src/sys/modules Makefile src/sys/modules/ciss Makefile src/sys/i386/conf NOTES
In article [EMAIL PROTECTED] you wrote:
msmith 2001/11/27 15:08:37 PST
Modified files:
sys/conf files
sys/modules Makefile
sys/i386/confNOTES
Added files:
sys/dev/ciss ciss.c cissio.h cissreg.h cissvar.h
sys/modules/ciss Makefile
Log:
Add the 'ciss' driver, which supports the Compaq SmartRAID 5* family of
RAID controllers (5300, 532, 5i, etc.)
Thanks to Compaq and Yahoo! for support during the development of this
driver.
MFC after: 1 week
Revision ChangesPath
1.584 +1 -0 src/sys/conf/files
1.1 +3368 -0 src/sys/dev/ciss/ciss.c (new)
1.1 +203 -0src/sys/dev/ciss/cissio.h (new)
1.1 +670 -0src/sys/dev/ciss/cissreg.h (new)
1.1 +375 -0src/sys/dev/ciss/cissvar.h (new)
1.981 +7 -0 src/sys/i386/conf/NOTES
1.218 +1 -0 src/sys/modules/Makefile
1.1 +11 -0 src/sys/modules/ciss/Makefile (new)
And I can buildkernel only after the next patch:
Index: sys/dev/ciss/ciss.c
===
RCS file: /scratch/CVS/src/sys/dev/ciss/ciss.c,v
retrieving revision 1.1
diff -b -u -r1.1 ciss.c
--- sys/dev/ciss/ciss.c 27 Nov 2001 23:08:36 - 1.1
+++ sys/dev/ciss/ciss.c 28 Nov 2001 06:51:18 -
@@ -216,7 +216,7 @@
static struct cdevsw ciss_cdevsw = {
ciss_open, ciss_close, noread, nowrite, ciss_ioctl,
nopoll, nommap, nostrategy, ciss, CISS_CDEV_MAJOR,
-nodump, nopsize, 0, -1
+nodump, nopsize, 0, NULL
};
/
@@ -3210,7 +3210,7 @@
* Handle an open on the control device.
*/
static int
-ciss_open(dev_t dev, int flags, int fmt, struct proc *p)
+ciss_open(dev_t dev, int flags, int fmt, struct thread *td)
{
struct ciss_softc *sc;
@@ -3228,7 +3228,7 @@
* Handle the last close on the control device.
*/
static int
-ciss_close(dev_t dev, int flags, int fmt, struct proc *p)
+ciss_close(dev_t dev, int flags, int fmt, struct thread *td)
{
struct ciss_softc *sc;
@@ -3247,7 +3247,7 @@
* simplify the porting of Compaq's userland tools.
*/
static int
-ciss_ioctl(dev_t dev, u_long cmd, caddr_t addr, int32_t flag, struct proc *p)
+ciss_ioctl(dev_t dev, u_long cmd, caddr_t addr, int32_t flag, struct thread *td)
{
struct ciss_softc *sc;
interror;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: where is the idle_loop in current ?
On Mon, 26 Nov 2001, John Baldwin wrote: We don't do preemption in the kernel yet, so they need to yield the CPU when another thread is available. The page zeroing thread does this wrong as it should check procrunnable() instead of switching after doing N pages. The idle Except it would always find at least itself runnable :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
