Re: evdev broken
Shawn Webb writes: > > > > It looks like evdev support in the kernel is broken. > > > > sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to > > > > different evdev-related symbols. > > > > > > > > I have the following options in my kernel config: > > > > > > > > options EVDEV_SUPPORT > > > > options EVDEV_DEBUG > > > > options UINPUT_DEBUG > > > > > > Did you add "device evdev"? > > > > Good catch! I did not. Adding now and I'll report back when > > buildkernel finishes. > > That did the trick. Thanks! > > Seems like evdev doesn't have a manpage, which is why I didn't > know to include it in my kernel config. On a system running: FreeBSD 12.0-CURRENT #0 r326723: Sat Dec 9 12:30:04 EST 2017 amd64 there is a man page, in section 4x. That's the good news. The bad news is I see no mention of needing to add anything to the kernel; it's presented as a Xorg input device. Reported as "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224793;. Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
/usr/obj is 11GB huge on FreeBSD 12-current
Wolfram Schneider writes: > I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > is now 11GB huge: > > FreeBSD 12-current > $ du -hs /usr/obj > 11G /usr/obj > > on FreeBSD 11-stable it was less the size: > $ du -hs /usr/obj > 5.6G /usr/obj Mine - also 12-current - reports 7.6G. May we see your kernel config file, src.conf, and make.conf? Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
buildkernel fails for rev 326557
Hello: I am trying to update a system from: FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03 UTC 2016 amd64 to: huff@> svn info Path: . Working Copy Root Path: /usr/src URL: http://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 326557 Node Kind: directory Schedule: normal Last Changed Author: eadler Last Changed Rev: 326557 Last Changed Date: 2017-12-04 23:43:39 -0500 (Mon, 04 Dec 2017) After "rm -rf /usr/obj": Buildworld completes successfully. Buildkernel, with "-j1", fails with: `svm.c' is up to date. `svm_support.S' is up to date. `npt.c' is up to date. `ivrs_drv.c' is up to date. `amdvi_hw.c' is up to date. `svm_msr.c' is up to date. `afterdepend' was not built (made 1, flags 2019, type 3018001)! `afterdepend' has .ORDER dependency against .depend (made 1, flags 301b, type 3020001) `opt_global.h' was not built (made 0, flags 2009, type 300)! *** [all_subdir_vmm] Error code 1 make[3]: stopped in /usr/src/sys/modules 1 error make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/JERUSALEM 1 error make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/JERUSALEM *** [buildkernel] Error code 2 Rechecking src/UPDATING shows nothing interesting. The kernel config file is appended. Have I screwed something up, or is there a problem elsewhere? Respectfully, Robert Huff # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (https://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: head/sys/amd64/conf/GENERIC 326377 2017-11-29 23:41:49Z scottl $ cpu HAMMER ident JERUSALEM makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options VIMAGE # Subsystem virtualization, e.g. VNET options INET# InterNETworking options INET6 # IPv6 communications protocols options IPSEC # IP (v4/v6) security options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 options TCP_OFFLOAD # TCP offload options TCP_HHOOK # hhook(9) framework for TCP options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device options NFSCL # Network Filesystem Client options NFSD# Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD32# Compatible with i386 binaries #optionsCOMPAT_FREEBSD4 # Compatible with FreeBSD4 #optionsCOMPAT_FREEBSD5 # Compatible with FreeBSD5 #optionsCOMPAT_FREEBSD6 # Compatible with FreeBSD6 #optionsCOMPAT_FREEBSD7 # Compatible with FreeBSD7 #optionsCOMPAT_FREEBSD9 # Compatible
Re: questions re updating to -CURRENT
Jakub Lach writes: > Are you sure you are not using drm2 already? I would check > with kldstat. Ckecked; it's there. > The message in UPDATING is about removing > old code from the tree. Maybe ... but this is one of those things that (in my experience) either Just Work or Go Horribly Wrong. The latter is not nearly as much fun as it says in the brochure. Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
questions re updating to -CURRENT
Hello: I finally get to update a system from: FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03 UTC 2016 amd64 to -CURRENT. After reading src/UPDATING, I understand everything (I think) _except_: 20170311: The old drm (sys/dev/drm/) drivers for i915 and radeon have been removed as the userland we provide cannot use them. The KMS version (sys/dev/drm2) supports the same hardware. I assume the new kernel bits will be automatically built and installed. Are there any changes I need to make elsewhere, e.g. loader,conf or ports? Also: as part of the "safest in-place upgrade" ... how do rm -rf /usr/obj/* and make cleanworld differ? Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFT: Please help testing the llvm/clang 3.5.0 import
Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Point of information: this seems useful for developers, and (almost entirely) useless for everyone else. Are there other cohorts that want this badly? If that's correct, and there's a simple switch for configuration ... why should this default to what's useful for the (much?) smaller number of people? About what am I ignorant? Curiously, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
What is xmmintrin.h, and why aren't ports finding it?
Chris H writes: Working on a recent 11-CURRENT install (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014) svn info /usr/ports Revision: 372176 Given the above, and the fact that I have installed lang/gcc-48. Is there any reason that any port wanting to include xmmintrin.h fails to find it? Even though dmesg messages reflects the fact that gcc48 is included within my $PATH? Start by looking at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190669 Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't build CURRENT/amd64 using 9.3?
Fixed by scrubbing 9.3 and installing 10.1-RC3, which solved a couple of other issues. Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't build CURRENT/amd64 using 9.3?
Garrett Cooper writes: The message is telling you (indirectly) that you need to run make buildworld successfully first? Recapping: Current system: FreeBSD 9.3-RELEASE #0 r268512: Fri Jul 11 03:13:02 UTC 2014 i386 Source tree at CURRENT/r273626. No make.conf. src.conf: KERNCONF=GENERIC TARGET=amd64 TARGET_ARCH=amd64 Build uses this script: #! /bin/sh cd /usr/src if [ -f buildworld.log ] then rm buildworld.log fi chflags -R noschg /usr/obj/* rm -rf /usr/obj make cleandir date ./buildworld.time make -j 1 TARGET=amd64 TARGET_ARCH=amd64 buildworld ./buildworld.log 21 tail -n 50 /usr/src/buildworld.log | sendmail huff Build log at http://users.rcn.com/roberthuff/bl.gz; So: is that or is it not a valid world build? Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't build CURRENT/amd64 using 9.3?
Ian Lepore writes: I have a system running FreeBSD 9.3-RELEASE #0 r268512: Fri Jul 11 03:13:02 UTC 2014 i386 I have updated the source tree to CURRENT r273542. If I build make buildworld for the GENERIC kernel and no make.conf or src.conf, it succeeds. If I use an empty make.conf and src.conf of TARGET=amd64 TARGET_ARCH=amd64 it dies with ld -o gcrt1.o -r crt1_s.o gcrt1_c.o crt1_s.o: file not recognized: File format not recognized *** Error code 1 Try putting the TARGET= and TARGET_ARCH= on the make command line rather than in src.conf. I know the manpage says you can put them in src.conf, but I wonder if we've broken that and you're the first person to try since then. When I do this, I get instead: echo special chroot buildopts DIRPRFX=rescue/rescue/chroot/ rescue.conf echo progs chown rescue.conf echo special chown srcdir /usr/src/rescue/rescue/../../usr.sbin/chown rescue.conf echo special chown buildopts DIRPRFX=rescue/rescue/chown/ rescue.conf echo ln chown chgrp rescue.conf MAKE=/usr/obj/usr/src/make.i386/bmake MAKEOBJDIRPREFIX=/usr/obj/amd64.amd64/usr/src/rescue/rescue crunchgen -fq -m rescue.mk -c rescue.c rescue.conf crunchgen: make error: cd /usr/src/rescue/rescue/../../bin/cat /usr/obj/usr/src/make.i386/bmake -f /tmp//crunchgen_rescueH6FUZJ -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/cat/ loop crunchgen: make error: echo 'OBJS= 'cat.o crunchgen: make error: cd /usr/src/rescue/rescue/../../bin/chflags /usr/obj/usr/src/make.i386/bmake -f /tmp//crunchgen_rescueH6FUZJ -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chflags/ loop crunchgen: make error: echo 'OBJS= 'chflags.o ... and so on for another 400+ lines before it again dies. Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't build CURRENT/amd64 using 9.3?
Putting TARGET/TARGET_ARCH on the command line didn't help. Adding -j 1 to make - did. I am now doing make buildkernel with TARGET/TARGET_ARCH on the command line. For installkernel, do I need to use them also, or will it magically know where to look? Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't build CURRENT/amd64 using 9.3?
roberth...@rcn.com writes: I am now doing make buildkernel with TARGET/TARGET_ARCH on the command line. For installkernel, do I need to use them also, or will it magically know where to look? Kernel built. However: huff@ make installkernel ERROR: No kernel GENERIC to install. *** Error code 1 Stop. bmake: stopped in /usr/src *** [installkernel] Error code 1 Stop in /usr/src. huff@ make TARGET=amd64 TARGET_ARCH=amd64 installkernel ERROR: Please set DESTDIR! *** Error code 1 Stop. bmake: stopped in /usr/src *** [installkernel] Error code 1 Stop in /usr/src. I believe there is a kernel in /usr/obj/amd64.amd64/usr/src/sys/GENERIC, and world in /usr/obj/amd64.amd64/usr/src. How do I make sure these get installed in the right place(s)? Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't build CURRENT/amd64 using 9.3?
David Wolfskill writes: Kernel built. However: huff@ make installkernel ERROR: No kernel GENERIC to install. *** Error code 1 ... I believe there is a kernel in /usr/obj/amd64.amd64/usr/src/sys/GENERIC, and world in /usr/obj/amd64.amd64/usr/src. ... I believe that the cited message refers to the kernel configuration file, which is expected to be in sys/amd64/conf/GENERIC within the src hierarchy. Like this: huff@ pwd /usr/src huff@ dir sys/amd64/conf/GENERIC -rw-rw-r-- 1 root wheel 14594 Oct 23 07:28 sys/amd64/conf/GENERIC ? Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't build CURRENT/amd64 using 9.3?
David Wolfskill writes: I believe that the cited message refers to the kernel configuration file, which is expected to be in sys/amd64/conf/GENERIC within the src hierarchy. Like this: huff@ pwd /usr/src huff@ dir sys/amd64/conf/GENERIC -rw-rw-r-- 1 root wheel 14594 Oct 23 07:28 sys/amd64/conf/GENERIC ? If the make installkernel is being done from /usr/src, yes. Contents of /etc/make.conf and/or /etc/src.conf may have bearing on this, as well. No make.conf. src.conf= #KERNCONF=JERUSALEM KERNCONF=GENERIC #WITH_LIBICONV_COMPAT=yes #TARGET=amd64 #TARGET_ARCH=amd64 Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
can't build CURRENT/amd64 using 9.3?
I have a system running FreeBSD 9.3-RELEASE #0 r268512: Fri Jul 11 03:13:02 UTC 2014 i386 I have updated the source tree to CURRENT r273542. If I build make buildworld for the GENERIC kernel and no make.conf or src.conf, it succeeds. If I use an empty make.conf and src.conf of TARGET=amd64 TARGET_ARCH=amd64 it dies with echo '#define EXTRA_MODES_FILE i386/i386-modes.def' tm.h (cd /usr/src/gnu/lib/csu; /usr/obj/usr/src/make.i386/bmake -f /usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile MFILE=/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/Makefile GCCDIR=/usr/src/gnu/lib/csu/../../../contrib/gcc options.h) LC_ALL=C awk -f /usr/src/gnu/lib/csu/../../../contrib/gcc/opt-gather.awk /usr/src/gnu/lib/csu/../../../contrib/gcc/c.opt /usr/src/gnu/lib/csu/../../../contrib/gcc/common.opt /usr/src/gnu/lib/csu/../../../contrib/gcc/config/i386/i386.opt optionlist LC_ALL=C awk -f /usr/src/gnu/lib/csu/../../../contrib/gcc/opt-functions.awk -f /usr/src/gnu/lib/csu/../../../contrib/gcc/opth-gen.awk optionlist options.h rm -f .depend CC='cc ' mkdep -f .depend -a -DCRT_BEGIN -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3 -I/usr/src/gnu/lib/csu/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -std=gnu89 /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c TMP=_depend$$; sed -e 's/^\([^\.]*\).o[ ]*:/\1.o \1.po \1.So:/' .depend $TMP; mv $TMP .depend cc -O2 -pipe -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3 -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -I/usr/src/gnu/lib/csu/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -std=gnu89 -Qunused-arguments -g0 -DCRT_BEGIN -c -o crtbegin.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c cc -O2 -pipe -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3 -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -I/usr/src/gnu/lib/csu/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -std=gnu89 -Qunused-arguments -g0 -DCRT_END -c -o crtend.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c cc -O2 -pipe -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3 -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -I/usr/src/gnu/lib/csu/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -std=gnu89 -Qunused-arguments -g0 -DCRT_BEGIN -DCRTSTUFFT_O -c -o crtbeginT.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c cc -O2 -pipe -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3 -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -I/usr/src/gnu/lib/csu/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -std=gnu89 -Qunused-arguments -g0 -DCRT_BEGIN -DCRTSTUFFS_O -DSHARED -fpic -c -o crtbeginS.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c cc -O2 -pipe -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3 -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -I/usr/src/gnu/lib/csu/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/csu/../../../contrib/gcc/config -I/usr/src/gnu/lib/csu/../../../contrib/gcc -I. -I/usr/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -std=gnu89 -Qunused-arguments -g0 -DCRT_END -DCRTSTUFFS_O -DSHARED -fpic -c -o crtendS.o /usr/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbegin.o /usr/obj/usr/src/tmp/usr/lib/crtbegin.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtend.o /usr/obj/usr/src/tmp/usr/lib/crtend.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginT.o /usr/obj/usr/src/tmp/usr/lib/crtbeginT.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtbeginS.o /usr/obj/usr/src/tmp/usr/lib/crtbeginS.o sh /usr/src/tools/install.sh -o root -g wheel -m 444 crtendS.o /usr/obj/usr/src/tmp/usr/lib/crtendS.o echo === lib/csu/i386-elf (obj,depend,all,install); cd /usr/src/lib/csu/i386-elf /usr/obj/usr/src/make.i386/bmake MK_TESTS=no DIRPRFX=lib/csu/i386-elf/ obj
pcmcia cdrom/irq sharing problem?
Hi all, I've just upgraded my system to today's -CURRENT (I was running a -CURRENT from April 2001). Although I encountered some problems, the UPDATING file got me through (I love the way FreeBSD documents stuff) and my system is running fine (background fsck, great!) except for my PCMCIA CDROM player. I have a Sony VAIO Z600 laptop by the way. I was hoping somebody can point me in the right direction (searching the web/mailinglist archives didn't help). My CDROM player was always correctly identified with my previous install as NinjaATA on irq 3 (slot 0 on pccard0). After the upgrade, it is recognised, but assigned irq 9 (which is not in pccard.conf) after which the system hangs until the card is removed. This irq is (and was) shared with fxp0, pcm0. I've turned off PnP in the BIOS to no avail. I've tried a NEWCARD kernel, which does not even recognise the card. My PCMCIA wireless card works fine (also on irq 9). Attached are kernel messages when inserting the card (with the april 2001 -CURRENT, today's -CURRENT with oldcard and today's -CURRENT with newcard), dmesg output and kernel config file. Regards, Walter. -- Walter Belgers Si hoc signum legere potes, operis boni in rebus [EMAIL PROTECTED] Latinis alacribus et fructuosis potiri potes! kernel messages with April 2001 kernel Sep 19 20:18:32 bwerk /boot/kernel/kernel: pccard: card inserted, slot 0 Sep 19 20:18:31 bwerk pccardd[178]: Card (NinjaATA-) [V1.0] [AP00 ] matched (NinjaATA-) [(null)] [(null)] Sep 19 20:18:37 bwerk /boot/kernel/kernel: ata4 at port 0x180-0x187,0x386 iomem 0xd4000-0xd4fff irq 3 slot 0 on pccard0 Sep 19 20:18:37 bwerk /boot/kernel/kernel: ata4-slave: identify retries exceeded Sep 19 20:18:37 bwerk /boot/kernel/kernel: acd0: CDROM TOSHIBA CD-ROM XM-1902B at ata4-master BIOSPIO Sep 19 20:18:37 bwerk pccardd[178]: ata4: NinjaATA inserted. Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: card inserted: event=0x, state=3510 Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccard0: chip_socket_enable Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_socket_enable: Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: pccbb_power: CARD_VCC_5V and CARD_VPP_VCC [15] Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: pccbb_pcic_wait_ready: status 0x7f Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: card type is mem Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccard0: read_cis Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_mem_map window 0 bus 10001000+400+e000 card addr 0 Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_do_mem_map window 0: 8001 8001 3fff 10 (10001000+0400.1000*e000) Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_do_mem_map window 0: 8001 8001 7fff 10 (10001000+0400.1000*e000) Oct 16 10:59:37 bwerk /boot/kernel/kernel: cis mem map c8569000 Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccard0: CIS tuple chain: Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_DEVICE type=funcspec speed=100ns Oct 16 10:59:37 bwerk /boot/kernel/kernel: 01 03 dc 00 ff Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_VERS_1 Oct 16 10:59:37 bwerk /boot/kernel/kernel: 15 1a 04 01 20 00 4e 69 6e 6a 61 41 54 41 2d 00 Oct 16 10:59:37 bwerk /boot/kernel/kernel: 56 31 2e 30 00 41 50 30 30 20 00 ff Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CONFIG Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1a 05 01 23 00 02 03 Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CFTABLE_ENTRY Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1b 15 e1 01 3d 11 55 1e fc 23 f0 61 80 01 07 86 Oct 16 10:59:37 bwerk /boot/kernel/kernel: 03 01 30 68 d0 10 00 Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CFTABLE_ENTRY Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1b 0f 22 38 f0 61 90 01 07 96 03 01 30 68 d0 10 Oct 16 10:59:37 bwerk /boot/kernel/kernel: 00 Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CFTABLE_ENTRY Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1b 0f 23 38 f0 61 a0 01 07 a6 03 01 30 68 d0 10 Oct 16 10:59:38 bwerk /boot/kernel/kernel: 00 Oct 16 10:59:38 bwerk /boot/kernel/kernel: CISTPL_NO_LINK Oct 16 10:59:38 bwerk /boot/kernel/kernel: 14 00 Oct 16 10:59:38 bwerk /boot/kernel/kernel: CISTPL_END Oct 16 10:59:38 bwerk /boot/kernel/kernel: ff Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: check_cis_quirks Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: CIS version PCCARD 2.0 or 2.1 Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: CIS info: , NinjaATA-, V1.0, AP00 Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: Manufacturer code 0x, product 0x Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: function 0: unspecified, ccr addr 200 mask 3 Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: function 0, config table entry 33: I/O card; irq mask d068; iomask 10, iospace 180-187 386-387; memspace 0-fff; rdybsy_active wp_active
VIRUS WARNING
WARNING! This mail is generated automatically by virus-scanning software. There was virus found in one or more attachment in e-mail sent by: Peter Wagner [EMAIL PROTECTED] at date: Thu, 2 Nov 2000 09:34:34 - , with subject "US PRESIDENT AND FBI SECRETS =PLEASE VISIT = (http://WWW.2600.CO M)=". There is list of infected files: Found virus "VBS/LoveLetter.worm" in DOMEO.JPG.vbs Please clean files and resend Your message, Your message was dropped. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
