Re: Error in libstdc++ buildworld
On Sun, Nov 19, 2000 at 12:45:11PM -0600, Mark R Grant wrote: 1. I cleaned up the source directories using "cd /usr ; make cleandir" 2. I cleaned up the object directories using "cd /usr/obj ; chflags -R noschg * ; rm -rf *" These two steps should be reversed. The `make cleandir' in #1 will clean out the /usr/obj/...dir shadow tree if it exists, else the dir w/in /usr/src/ ``make cleandir make cleandir'' is the way to ensure that /usr/src is truely clean (or do your step #2 above first). 4. I decided that since I am too much of a novice at this, I should use the buildworld and installworld seperately. I ran "cd /usr/src ; make -j2 buildworld" With -jX (X 1), you cannot trust any error output. You would be better off not using -j until you know you can build the world. From the output you provide I'm not sure why the /usr/obj/usr/src/i386/mk directory doesn't exist. But please try your step #2, followed by our step #1 and see if this goes away. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
On Fri, Nov 17, 2000 at 05:58:30PM -0800, Kris Kennaway wrote: On Fri, Nov 17, 2000 at 12:55:28PM +0100, Soren Schmidt wrote: I thought I was the only one, since my question on the freebsd-current mailing list went unanswered. You are _not_ alone, there has been numerous complains about this on the list, but so far they have not been taken seriously :| One of my non-SMP machines reliably wedges whenever I do heavy disk I/O. I can't break to debugger. Nov 4 15:46:41 mollari /boot/kernel/kernel: atapci0: Intel PIIX3 ATA controller port 0xffa0-0xffaf at device 7.1 on pci0 Nov 4 15:46:41 mollari /boot/kernel/kernel: ata0: at 0x1f0 irq 14 on atapci0 Nov 4 15:46:41 mollari /boot/kernel/kernel: ahc0: Adaptec 2940 Ultra SCSI adapter port 0xfc00-0xfcff mem 0xffbeb000-0xffbebfff irq 15 at device 11.0 on pci0 Nov 4 15:46:41 mollari /boot/kernel/kernel: aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs Well, adding INVARIANTS, INVARIANTS_SUPPORT, MUTEX_DEBUG and WITNESS didn't give me anything to go off. Interestingly though - I thrashed the disks for about 15 minutes to no avail before kldloading random.ko and firing up ssh, at which point it froze within a few minutes while typing. Obviously one data point isn't much to go off, but it might be somewhere to start looking. Kris PGP signature
-current scheduler strangeness
Hi, today I upgraded my 5.0-CURRENT from PRE_SMPNG to -current from about 5-6 hours. everything went fine, the system is working, but I now notice the following: whenever I compile something (say a port) and play an mp3 in xmms at the same time, the mp3 playing is frequently interrupted, or loops for a second. when I stop the compile, the mp3 files are playing ok. with PRE_SMPNG I never experienced such behavior, even with 2 or 3 simultaneous compiles. I am attaching the dmesg output and my kernel config file if that would be helpful. as you can see, pcm shows: pcm0: hwptr went backwards 3896 - 3720 with PRE_SMPNG it didn't show such things, and when I do not load the machine with compiles, it never displays such messages and plays fine. any info will be greatly appreciated. -tacho -- [i don't follow] | [http://daemonz.org/ || [EMAIL PROTECTED]] [everything should be made as simple as possible, but no simpler] 0x44FC3339 || [02B5 798B 4BD1 97FB F8DB 72E4 DCA4 BE03 44FC 3339] # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/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 (http://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 NOTES configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.291 2000/11/15 18:36:24 imp Exp $ machine i386 #cpuI386_CPU #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident THING maxusers32 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols #optionsMATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required #optionsDEVFS #Device 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 options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual 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 extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa #device eisa device pci #optionsCOMPAT_OLDISA # compatability shims for lnc, le #optionsCOMPAT_OLDPCI # compatability shims for lnc # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering options ATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device amd # AMD
Re: -current scheduler strangeness
as a followup, whenever I have disk access the problem shows also... On Mon, Nov 20, 2000 at 02:23:26PM +0200, Stanislav Grozev wrote: Hi, today I upgraded my 5.0-CURRENT from PRE_SMPNG to -current from about 5-6 hours. everything went fine, the system is working, but I now notice the following: whenever I compile something (say a port) and play an mp3 in xmms at the same time, the mp3 playing is frequently interrupted, or loops for a second. when I stop the compile, the mp3 files are playing ok. with PRE_SMPNG I never experienced such behavior, even with 2 or 3 simultaneous compiles. I am attaching the dmesg output and my kernel config file if that would be helpful. as you can see, pcm shows: pcm0: hwptr went backwards 3896 - 3720 with PRE_SMPNG it didn't show such things, and when I do not load the machine with compiles, it never displays such messages and plays fine. any info will be greatly appreciated. -tacho # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/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 (http://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 NOTES configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.291 2000/11/15 18:36:24 imp Exp $ machine i386 #cpu I386_CPU #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident THING maxusers 32 #To statically compile in device wiring instead of /boot/device.hints #hints"GENERIC.hints" #Default places to look for devices. #makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols #options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required #options DEVFS #Device 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 options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual 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 extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O deviceisa #device eisa devicepci #options COMPAT_OLDISA # compatability shims for lnc, le #options COMPAT_OLDPCI # compatability shims for lnc # Floppy drives devicefdc # ATA and ATAPI devices deviceata deviceatadisk # ATA disk drives deviceatapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering options ATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device
Re: -current scheduler strangeness
Stanislav Grozev wrote:
as a followup, whenever I have disk access the problem shows also...
pcm0: Yamaha OPL-SAx at port
0x220-0x22f,0x530-0x537,0x388-0x38b,0x330-0x331,0x370-0x371 irq 5 drq 0,1 on isa0
It could be due to my commit in which I reduced buffer size in mss driver from 64K to
4K. Please try to increase it to 8KB, 16KB etc and let me know if it
helps ("#define MSS_BUFFSIZE (4096)" line in src/sys/dev/sound/isa/mss.c).
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current scheduler strangeness
Stanislav Grozev wrote: Hi, today I upgraded my 5.0-CURRENT from PRE_SMPNG to -current from about 5-6 hours. everything went fine, the system is working, but I now notice the following: whenever I compile something (say a port) and play an mp3 in xmms at the same time, the mp3 playing is frequently interrupted, or loops for a second. when I stop the compile, the mp3 files are playing ok. with PRE_SMPNG I never experienced such behavior, even with 2 or 3 simultaneous compiles. I am attaching the dmesg output and my kernel config file if that would be helpful. as you can see, pcm shows: pcm0: hwptr went backwards 3896 - 3720 I get this too. However for me it's related to using the mouse (though maybe using the mose uses CPU and it's actually CPU) I'm using the snd_maestro module. This has been happenning since before the SMPNG tag was layed down so it's not related to the new SMP code.. with PRE_SMPNG it didn't show such things, and when I do not load the machine with compiles, it never displays such messages and plays fine. any info will be greatly appreciated. -tacho -- [i don't follow] | [http://daemonz.org/ || [EMAIL PROTECTED]] [everything should be made as simple as possible, but no simpler] 0x44FC3339 || [02B5 798B 4BD1 97FB F8DB 72E4 DCA4 BE03 44FC 3339] Name: THING THINGType: Plain Text (text/plain) Encoding: quoted-printable dmesgName: dmesg Type: Plain Text (text/plain) Part 1.2Type: application/pgp-signature -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current scheduler strangeness
On Mon, Nov 20, 2000 at 02:37:39PM +0200, Maxim Sobolev wrote:
pcm0: Yamaha OPL-SAx at port
0x220-0x22f,0x530-0x537,0x388-0x38b,0x330-0x331,0x370-0x371 irq 5 drq 0,1 on isa0
It could be due to my commit in which I reduced buffer size in mss driver from 64K
to 4K. Please try to increase it to 8KB, 16KB etc and let me know if it
helps ("#define MSS_BUFFSIZE (4096)" line in src/sys/dev/sound/isa/mss.c).
the results:
8k - plays absolute garbage (this is strange, because with 4k it plays music,
but skips)
16k - plays music, the skips aren't so often heard as with 4k, but are
often enough to be annoying
32k - everything plays fine, even with 3 compilations and heavy disk access.
so, thanks for the quick answer - I will now keep it at 32k, i don't know
the rationale of downing this to 4k. maybe you should commit it to 32k in
the repo too?
-tacho
--
[i don't follow] | [http://daemonz.org/ || [EMAIL PROTECTED]]
[everything should be made as simple as possible, but no simpler]
0x44FC3339 || [02B5 798B 4BD1 97FB F8DB 72E4 DCA4 BE03 44FC 3339]
PGP signature
Re: -current scheduler strangeness
Stanislav Grozev wrote:
On Mon, Nov 20, 2000 at 02:37:39PM +0200, Maxim Sobolev wrote:
pcm0: Yamaha OPL-SAx at port
0x220-0x22f,0x530-0x537,0x388-0x38b,0x330-0x331,0x370-0x371 irq 5 drq 0,1 on isa0
It could be due to my commit in which I reduced buffer size in mss driver from 64K
to 4K. Please try to increase it to 8KB, 16KB etc and let me know if it
helps ("#define MSS_BUFFSIZE (4096)" line in src/sys/dev/sound/isa/mss.c).
the results:
8k - plays absolute garbage (this is strange, because with 4k it plays music,
but skips)
16k - plays music, the skips aren't so often heard as with 4k, but are
often enough to be annoying
32k - everything plays fine, even with 3 compilations and heavy disk access.
so, thanks for the quick answer - I will now keep it at 32k, i don't know
the rationale of downing this to 4k. maybe you should commit it to 32k in
the repo too?
Maybe it should be self tuning according to the speed of the data.
I don't understand why the hwptr would go backwards due to system load..
if this is an underflow, then the message should say so...
-tacho
--
[i don't follow] | [http://daemonz.org/ || [EMAIL PROTECTED]]
[everything should be made as simple as possible, but no simpler]
0x44FC3339 || [02B5 798B 4BD1 97FB F8DB 72E4 DCA4 BE03 44FC 3339]
Part 1.2Type: application/pgp-signature
--
__--_|\ Julian Elischer
/ \ [EMAIL PROTECTED]
( OZ) World tour 2000
--- X_.---._/ presently in: Budapest
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current scheduler strangeness
On Mon, Nov 20, 2000 at 05:35:40AM -0800, Julian Elischer wrote: Maybe it should be self tuning according to the speed of the data. I don't understand why the hwptr would go backwards due to system load.. if this is an underflow, then the message should say so... Just FYI, I also get this behaviour with my SB 64 AWE ISA PnP card and a recent -CURRENT. The 'hwptr went backwards' messages are triggered most often by heavy disk access (esp CVS operations), compiles and using the Linux emulation, but sometimes by using the mouse on the console as well (this is a serial mouse) Of course, bloated software makes things worse, so RealPlayer is a really bad offender. The messages did not start with SMPNG but got a *lot* more frequent in the last couple of weeks, making listening to mp3-s a real annoyance during any more serious system activity. (Earlier, ie in the early fall and in the summer) these messages were almost never seen while in console mode, but only with X and RealPlayer messing things up. The sound card works fine otherwise. (have not tried recording.) (just my HUF 0.02:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: binutils commit breaks kernel builds?
On Wed, 15 Nov 2000, David O'Brien wrote: On Wed, Nov 15, 2000 at 04:15:55PM +0100, Harti Brandt wrote: with fresh sources from today 6:00 MET kernel builds fail. The victim is I'm done with the upgrade - you may have easily CVSuped during the upgrade process. Can you wait an hour or so, CVSup again and see if you still see the problem? Is anyone else experience[31~ing this? Well, I cvsuped twice and it didn't work. But today everything is fine. Thanks, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT is freezing again ...
Interestingly though - I thrashed the disks for about 15 minutes to no avail before kldloading random.ko and firing up ssh, at which point it froze within a few minutes while typing. Obviously one data point isn't much to go off, but it might be somewhere to start looking. Now that I've (almost) cleared get_cyclecounter(9) out of my TODO, I can use it, and then go about getting rid of most malloc(9)s and all TAILQs in random.ko. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USW2 Root: -current build report for Mon Nov 20 02:06:26 CST 2000
Kaboom. Looks like the fixes to perl unfixed the release. --- Forwarded Message Return-Path: [EMAIL PROTECTED] Delivery-Date: Mon Nov 20 05:13:27 2000 Return-Path: [EMAIL PROTECTED] Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by winston.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eAKDDRI71931 for [EMAIL PROTECTED]; Mon, 20 Nov 2000 05:13:27 -0800 (PST) (envelope-from [EMAIL PROTECTED]) Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 403446E253D for [EMAIL PROTECTED]; Mon, 20 Nov 2000 05:13:48 -0800 (PST) Received: by hub.freebsd.org (Postfix) id 30F8637B4C5; Mon, 20 Nov 2000 05:13:48 -0800 (PST) Delivered-To: [EMAIL PROTECTED] Received: from usw2.freebsd.org (usw2.freebsd.org [209.180.6.226]) by hub.freebsd.org (Postfix) with ESMTP id B2B5337B479 for [EMAIL PROTECTED]; Mon, 20 Nov 2000 05:13:47 -0800 (PST) Received: (from root@localhost) by usw2.freebsd.org (8.11.1/8.11.0) id eAKDDlw23230 for [EMAIL PROTECTED]; Mon, 20 Nov 2000 07:13:47 -0600 (CST) (envelope-from root) Date: Mon, 20 Nov 2000 07:13:47 -0600 (CST) From: USW2 Root [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: -current build report for Mon Nov 20 02:06:26 CST 2000 Doing nightly build attempt for 5.0-20001120-CURRENT at Mon Nov 20 02:06:26 CST 2000 Updating source tree... Making release... Release build of 5.0-20001120-CURRENT was an abject failure. install -c -o root -g wheel -m 444 libperl_p.a /R/stage/trees/bin/usr/lib install -c -s -o root -g wheel -m 444 libperl.so.4 /R/stage/trees/bin/usr/lib ln -sf libperl.so.4 /R/stage/trees/bin/usr/lib/libperl.so === gnu/usr.bin/perl/perl cd /usr/src/gnu/usr.bin/perl/perl ; make install DESTDIR=/R/stage/trees/bin SHARED=copies install -c -s -o root -g wheel -m 555 perl /R/stage/trees/bin/usr/bin /R/stage/trees/bin/usr/bin/perl5 - /R/stage/trees/bin/usr/bin/perl /R/stage/trees/bin/usr/bin/perl5.6.0 - /R/stage/trees/bin/usr/bin/perl === gnu/usr.bin/perl/suidperl cd /usr/src/gnu/usr.bin/perl/suidperl ; make install DESTDIR=/R/stage/trees/bin SHARED=copies install -c -s -o root -g wheel -m 511 suidperl /R/stage/trees/bin/usr/bin /R/stage/trees/bin/usr/bin/sperl5 - /R/stage/trees/bin/usr/bin/suidperl /R/stage/trees/bin/usr/bin/sperl5.6.0 - /R/stage/trees/bin/usr/bin/suidperl === gnu/usr.bin/perl/library cd /usr/src/gnu/usr.bin/perl/library ; make install DESTDIR=/R/stage/trees/bin SHARED=copies === gnu/usr.bin/perl/library/B miniperl: not found *** Error code 127 Stop in /usr/obj/usr/src/gnu/usr.bin/perl/library/B/ext/B. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/library/B. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/library. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/library. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /usr/src/release. --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Error in libstdc++ buildworld
In article [EMAIL PROTECTED], David O'Brien [EMAIL PROTECTED] wrote: One cannot "upgrade"[*] to -CURRENT using he "RELENG_4" tag. The "RELENG_4" is the 4.x code base. To get -CURRENT source one would use no tag. Not correct! One should use "tag=.". If he uses no tag then he'll get the RCS files. 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: USW2 Root: -current build report for Mon Nov 20 02:06:26 CST 2000
Jordan Hubbard wrote: Kaboom. Looks like the fixes to perl unfixed the release. I'll take a look at it. I tested a buildworld and an installworld, so this failure is unexpected. I don't have an explanation yet. This can take a couple of hours... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cardbus fixes
I've been side tracked for a long time since after the con with various more urgant things to do, and have left the cardbus stuff along for a while, but now that thanksgiving is near, I might have some more time to work on this... On Sat, Nov 18, 2000 at 10:05:01PM -0700, Justin T. Gibbs wrote: While working on getting the APA-1480 to work under FreeBSD's new cardbus support, I ran into several issues. 1) When mucking with mapping registers, it is best to *not* have io or memory space access enabled. This patch defers the setting of these bits until after all of the mapping registers are probed. It might be even better to defer this until a particular mapping is activated and to disable that type of access when a new register is activated. Good... 2) The PCI spec is very explicit about how mapping registers and the expansion ROM mapping register should be probed. This patch makes cardbus_add_map() follow the spec. Gook... 3) The PCI spec allows a device to use the same address decoder for expansion ROM access as is used for memory mapped register access. This patch carefully enables and disables ROM access along with resource (de)activiation. Hmm... I didn't think of this... 4) The cardbus CIS code treats the CIS_PTR as a mapping register if it is mentioned in the CIS. I don't have a spec handy to understand why the CIS_PTR is mentioned in the CIS, but allocating a memory range for it is certainly bogus. My patch ignores bar #6 to prevent the mapping. 5) The CIS code allocated duplicate resources to those already found by cardbus_add_resources(). The fix is to pass in the bar computed from the CIS instead of the particular resource ID for that bar, so bus_generic_alloc_resource succeeds in finding the old resource. It seems somewhat strange that we have to have two methods for finding and activating the mapping registers. Isn't one method sufficient? 6) cardbus_read_exrom_cis() failed to advance correctly to higer rom images. To effect the fix, the cis_ptr value must be provided to the different CIS reading methods, unaltered. 7) The CIS code seems to use the wrong bit to determine rather a particular register mapping is for I/O or memory space. From looking at the two cards I have, it seems TPL_BAR_REG_AS should be 0x10 instead of 0x08. Otherwise, all registers that should be I/O mapped gain a second mapping in memory space. Okay... CIS stuff is nasty in the current code. Basically - First, the whole CIS reading needs to be rewritten. The current practice of reading the whole rom then passing it to various functions is bad because it would fail for CIS tuples that should make the reader jump around, say, to another rom image or whatever. Second, the BAR mapping stuff, yes, it is wrong. I don't know where I got the idea of doing it wrong in the first place... too much coding late at night without proper documentation I guess... I've had a fix sitting on my local tree for a while, and will commit that soon-ish. And lastly, as for why we need to read the BAR at all, I thought about this briefly when I first wrote the code and came up with the logic that there might be some random cardbus device that stuck a BAR outside of the normal registers but still had the proper mapping in the CIS. For "normal" cards this additional mapping doesn't do anything as they are already mapped. This attempt at mapping BARs using both the PCI and the CIS methods has made the resource allocation functions more ugly than it needs to be. I'm wondering if perhaps one of the two should just be left out. 8) The cardbus bridge code leaves memory space prefetching enabled. Prefetching is only allowed if the target device indicates (through its mapping register) that prefetching is allowable. My patch simply disables prefetching and includes code to detect this capability and pass an RF flag to enable it, but nothing more. Good... I was wondering whether I should leave that enabled or not. 9) The pccbb code was impoperly handling the I/O and mem range limit registers. The limit register indicates the highest valid address in the window, not the first invalid address outside the window. Oops... One last thing that is started here is an attempt to rely more heavily on PCI register definitions and eventually functions, to get things done. The cardbus code duplicates a lot of functionality that is already available in the pci code (mapping register size/type detection). Good. One other thing that struck me while I was looking at this was that the resource manager should be providing the "resource pooling" that pccbb_cardbus_auto_open() emulates. Although the cardbus bridges we support only provide 4K granularity for memory mapped windows, things like external rom access often can be mapped on 2K boundaries. This could allow the resource
Problem Compiling Kernel
I CVSup'ed the sources today, built and installed world and everything was fine. When I tried to compile the kernel, I recieve this error when I do the 'make depend' ./aicasm -nostdinc -I- -I. -I../../ -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -I../../cam/scsi -I../../dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h ../../dev/aic7xxx/aic7xxx.seq ./aicasm: Stopped at file ../../dev/aic7xxx/aic7xxx.seq, line 81 - syntax error ./aicasm: Removing aic7xxx_seq.h due to error ./aicasm: Removing aic7xxx_reg.h due to error *** Error code 65 I looked at the file aic7xxx.seq on line 81, but I did not see any errors. This is on a Dell Latitude 600 PIII. Please let me know if anyone has a suggestion or needs more information. Thanks in advance! Corey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Getting at cardbus CIS data from inside drivers
Okay. Recently, David O'Brien handed me an Intel 10/100 Cardbus NIC, which uses the 21143-PB chip. It's a non-MII card (has a Quality Semi symbol PHY). Unfortunately, it looks like Intel has taken a few shortcuts with this card: the serial EEPROM doesn't contain any useful information. Instead, the MAC address and, I presume, the GPIO programming info is stored in the CIS. When the card is inserted, the cardbus code prints out several 'Function Extension' lines, one of which contains the MAC address. The problem is, there's no way for me to obtain this info from inside the driver, unless I map the expansion ROM directly and grovel through the CIS myself, which I don't want to do. I have the card working at the moment using a couple of ugly cheats: I programmed the MAC address in manually using ifconfig dc0 ether blah, and I brute forced the GPIO settings so that all of the pins are configured as outputs and are forced to 1's. This seems to be enough to activate the transceiver, and I can exchange traffic. (I'm composing this e-mail with it right now.) The LED programming is still off though: both LEDs are lit green, and stay on regardless of link indication or speed. Is there any support planned for externalizing the CIS info somehow, i.e. by providing bus methods to call the CIS parsing routines? Another way to do it would be to pass the info down to the child device using ivars. I would imaging that there's similar support for this in Windows, otherwise Intel's driver wouldn't work. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Bill Paul writes: : Is there any support planned for externalizing the CIS info somehow, : i.e. by providing bus methods to call the CIS parsing routines? Another : way to do it would be to pass the info down to the child device using : ivars. I would imaging that there's similar support for this in Windows, : otherwise Intel's driver wouldn't work. Yes. There's two things we're planning on exporting. First is to export parsed data as various Ivars, like we do for the the 16-bit cards. This will likely be the interface that you want to use, since we know about network nic addresses. The whole CIS parsing for cardbus is a little bogus at the moment, so we're looking at making it much less bogus. The other interface will be an enumerative interface where you can get a callback for each CIS entry. These will be bus method based so that they will be the same between 16-bit and 32 bit code. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
