Re: cvsup 06/05/2003 breaks nvidia driver
[EMAIL PROTECTED] wrote: I am not on my 5.1-BETA2 system right now, so I don't have any useful details, but after CVSuping /usr/src early 05/06/2003 (after midnight), then build world and recompiling and installing my kernel, the nvidia driver checks out when X is loaded with a failure to initialize the driver. The system in question has run 5.1-BETA1 and earlier 5.1-BETA2 code before without any nvidia driver problem. In the meantime, any suggestions on how to provide useful information, other than just the XFree86.0.log file, would be helpful. I have used both of the native nvidia driver and the ports-linux version (once), but tend to stay with the native version (1.0-3203). There was yet another ABI change recently that affected the nvidia driver. The only thing to do is just recompile that driver. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-RELEASE TODO
This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Desired Features for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Documentation items that must be resolved for 5.1 ++ |Issue |Status |Responsible |Description | ++ Areas requiring immediate testing ++ | Issue | Status | Responsible |Description| |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| | || | PAE support allows the| | || | use of up to 64GB of RAM | | PAE support for | -- | --| on Pentium Pro and above | | i386 || | systems. Virtual | | || | addresses are still | | || | constrained to 32-bits. | |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || | is welcome. | |---++---+---| | || | For 5.1-RELEASE, the | | || | default file system type | | || | for newly created file| | || | systems is UFS2 rather| | UFS2 as || | than UFS1. newfs(8) and | | installation, | -- | Robert Watson | sysinstall(8) have been | | newfs default || | updated to use this new | | || | default. Testing to make | | || | sure all goes well after | | || | the change (committed on | | || | April 20, 2003) is vital. | |---++---+---| | || | Support for pluggable | | || | directory services using | | || | NSS, including| | || | adaptations of current| | || Jacques | directory services (local | | NSSwitch support | -- | Vidrine | databases, NIS), and | | || | support for new services | | |
calcru: negative time of -X
Is this a problem, or basically the same thing as the failed to force tx message, just annoying :). this isn't the same uname, i got this while doing an install world over NFS. the date on the previous kernel (that this happened to) was May 30 16:47 EST uname -a: FreeBSD mp3.earthlink.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Jun 3 03:19:52 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MP3 i386 If needed, I can run a cvsup tonight and an install world to see if i get the same thing. I can attach dmesg or a link to it if needed as well. calcru: negative time of -253917 usec for pid 38074 (cc1) calcru: negative time of -263047 usec for pid 46765 (cpp0) dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state calcru: negative time of -57346 usec for pid 56261 (cpp0) dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state calcru: negative time of -492777 usec for pid 75854 (cc1) calcru: negative time of -660022 usec for pid 95854 (sh) dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state calcru: negative time of -277297 usec for pid 1771 (cpp0) dc0: failed to force tx and rx to idle state calcru: negative time of -182752 usec for pid 5497 (cpp0) __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
On Thu, 5 Jun 2003, Terry Lambert wrote: I hesistate to suggest this because everyone always gives me crap about me not disclosing the bug, but unless you are ready to grovel around in locore, and figure out what the root cause is for the difference in behaviour, I'm going to say that the most likely cause is that a DDB kernel uses more memory. Given that, I'm going to suggest you try again without DDB, but with: options DISABLE_PSE options DISABLE_PG_G If it doesn't fix the problem, then you haven't really lost anything but the time it takes to compile, reboot, rename, and reboot again. A non disclosure agreement is a non disclosure agreement, so no crap from me. I'll give that a try and see if it makes a difference. I don't remember off of the top of my head from the previous posts on this subject, but does this bug apply to an Athlon XP as well? -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Thu, 5 Jun 2003, Robert Watson wrote: This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: Well, we won't be needing *that* anymore :-). Expect the 5.2 TODO to trickle in every few weeks for the next few months, and feel free to submit updates to the TODO list to [EMAIL PROTECTED] I should say, of course, that the primary goals for 5.2 are not new software features (although those will happen too), but improved performance, robustness, and usability across all of our platforms, so don't submit too many feature TODO items that will distract people from making that happen :-). I think I speak for everyone when I say I'm on the edge of my seat for RELENG_5 being branched--5.x has been a long time coming, but it's going to be well worth it. Thanks again to everyone who made the 5.1 release process happen, especially to those who spent the last couple of weeks chasing down obscure and difficult bugs (the ones that make such a difference); and to those who made the push to make libthr and libkse so much more functional. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
New loader(8) plugin
Is there any real reason why loader.rc is not updated by default? I'd be interested to know how many people out there have it tweaked. Right now, when upgrading, this file is not updated with a fresh copy. Perhaps, it would make sense to always install it as /boot/loader.rc.default or /boot/loader.rc.freebsd, at the minimum? What do you think? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: New loader(8) plugin
Ruslan Ermilov wrote: Is there any real reason why loader.rc is not updated by default? I'd be interested to know how many people out there have it tweaked. Right now, when upgrading, this file is not updated with a fresh copy. Perhaps, it would make sense to always install it as /boot/loader.rc.default or /boot/loader.rc.freebsd, at the minimum? What do you think? Cheers, I was well aware of the Makefile rules involving loader.rc when I did the work I did, and I left them the way they were as a compromise to all of the people who strongly stated that they had no intention of using the new bootloader. I suspect that _very_ few people have custom loader.rc files. If someone wants to tackle making it modular, that's fine with me. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New loader(8) plugin
Ruslan Ermilov wrote: Is there any real reason why loader.rc is not updated by default? I'd be interested to know how many people out It was my decision. Before I wrote the stuff in *.4th that is used nowadays to read loader.conf, one had to write a loader.rc script to do any kind of special processing one wanted. Also, if anyone *does* want something more sophisticated, like my menu that allows me to chose different extra *.conf files, which in turn allows me to do stuff like selecting between 4.x and 5.x from inside loader instead of boot0, one has to change loader.rc. We standard loader.rc does provide for flexibility in the following ways: 1) User may change /boot/loader.conf and /boot/loader.conf.local, while we may change /boot/defaults/loader.conf. 2) User may change /boot/loader.rc as he deems fit, while we may change loader.4th and support.4th to add features. Granted, the general overlay of loader.rc does restrict somewhat what features we can introduce. To my mind, however, it is possible to introduce Scott's beastie menu by making changes to loader.4th. In particular, we could change start in loader.4th, and, if we *really* feel like it is needed, copy the old version to some other word (old-start, non-beastie-start, whatever :). Also, if we do go that way, I'd like, for source style reasons, to have Scott's script changed not to use evaluate. :-) there have it tweaked. Right now, when upgrading, this file is not updated with a fresh copy. Perhaps, it would make sense to always install it as /boot/loader.rc.default or /boot/loader.rc.freebsd, at the minimum? What do you think? That is a very good idea though it might be misleading -- default seems like something we would do if nothing else takes precedence -- but we could change loader so. The name loader.rc.freebsd is not misleading, but it isn't particularly leading either :-). I'd prefer loader.rc.sample in this particular case. Another idea is getting the md5 of the present version, and then having the installation procedure overwrite any present file if it has the same md5. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Ingrate, n.: A man who bites the hand that feeds him, and then complains of indigestion. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-BETA2 FAILURE on IBM A30p Thinkpad
Kevin Oberman wrote: From: Jesse D. Guardiani [EMAIL PROTECTED] Date: Sat, 24 May 2003 02:12:32 -0400 Sender: [EMAIL PROTECTED] Andre Guibert de Bruet [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Jesse, IBM just released (As of 5/20/2003) a new version (1EET70WW (1.16)) of your laptop's BIOS. Could you update it and see if it helps any? These kernel panics still occur with the 1.16 BIOS. As an update, I have successfully installed 5.0-RELEASE on this laptop without any kernel panics. However, neither ACPI or APM works. If I disable ACPI then the kernel locks up right before it detects my keyboard controller. I'm beginning to get discouraged. Does you r kernel configuration have: optionsDISABLE_PSE optionsDISABLE_PG_G I just discovered that a kernel built with these options will not boot on my ThinkPad T30 unless I remove APM. Well, apparently Thomas Girard discovered the problem for me. Entering: set hw.pci.allow_unsupported_io_range=1 at the loader prompt in 5.1-RC1 (and probably both BETAs) fixes everything right up! I'll be returning to my favorite O/S, FreeBSD, from Debian Linux with the release of 5.1-RELEASE. Hurray! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: phoenix crash in libc_r on sparc64
On Wed, 2003/06/04 at 00:30:36 -0700, Kris Kennaway wrote:
On Mon, Jun 02, 2003 at 04:15:43PM -0700, Kris Kennaway wrote:
phoenix on my sparc64 crashed while idle with the following:
Fatal error '_waitq_insert: Already in queue' at line 321 in file
/usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 2)
Any ideas?
It should have dropped a core - can you please take a look at it with
gdb?
One of the libc_r tests seems to hang:
Test static library:
--
Test c_user c_system c_total chng
passed/FAILEDh_user h_system h_total % chng
--
hello_d 0.00 0.020.02
passed
--
hello_s 0.00 0.020.02
passed
--
join_leak_d 0.77 0.180.95
passed
--
mutex_d 9.0892.42 101.50
passed
--
sem_d 0.01 0.020.02
passed
--
sigsuspend_d0.00 0.020.02
passed
--
sigwait_d 0.00 0.020.02
*** FAILED ***
--
guard_s.pl
It's been sitting there for hours now.
This an unfortunate failure mode, which is caused by a fault on the
stack while all signals are masked (by libc_r internals, I assume);
the kernel will fail to store the user register windows on the stack,
and because SIGILL is blocked, it cannot notify (or terminate) the
process and is stuck trying to copy out the register windows over and
over.
P.S. Why do 3 of the tests even fail on i386?
The guard test includes constants which are machine- and
compiler-specific, probably this broke due to a gcc upgrade.
The sigwait test is killed by it's own SIGUSR1, and this behaviour
actually looks correct to me (but I could easily be wrong, since the
signal behaviour of pthreads seems to be quite complex).
The propagate test failure is due to problems in libc (failing to
use the underscored versions of functions overridden in libc_r). The
attached patch should fix that; Daniel, does this look OK to you?
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: gen/sysconf.c
===
RCS file: /vol/ncvs/src/lib/libc/gen/sysconf.c,v
retrieving revision 1.20
diff -u -r1.20 sysconf.c
--- gen/sysconf.c 17 Nov 2002 08:54:29 - 1.20
+++ gen/sysconf.c 4 Jun 2003 20:44:47 -
@@ -40,6 +40,7 @@
#include sys/cdefs.h
__FBSDID($FreeBSD: src/lib/libc/gen/sysconf.c,v 1.20 2002/11/17 08:54:29 dougb Exp
$);
+#include namespace.h
#include sys/param.h
#include sys/time.h
#include sys/sysctl.h
@@ -52,6 +53,7 @@
#include pthread.h /* we just need the limits */
#include time.h
#include unistd.h
+#include un-namespace.h
#include ../stdlib/atexit.h
#include ../stdtime/tzfile.h
@@ -560,7 +562,7 @@
value = socket(PF_INET6, SOCK_DGRAM, 0);
errno = sverrno;
if (value = 0) {
- close(value);
+ _close(value);
return (200112L);
} else
return (0);
Index: include/namespace.h
===
RCS file: /vol/ncvs/src/lib/libc/include/namespace.h,v
retrieving revision 1.16
diff -u -r1.16 namespace.h
--- include/namespace.h 1 May 2003 19:03:13 - 1.16
+++ include/namespace.h 4 Jun 2003 20:38:29 -
@@ -122,8 +122,10 @@
/*#define sigaction _sigaction*/
#definesigprocmask _sigprocmask
#definesigsuspend _sigsuspend
+#definesleep _sleep
#definesocket _socket
#definesocketpair _socketpair
+#definewait_wait
#definewait4 _wait4
#definewaitpid
Re: USB printing mangles printjob :-(
On Thu, 5 Jun 2003 13:49:25 +0200 Bernd Walter [EMAIL PROTECTED] wrote: If I send that file to the printer via the parallel port, it prints perfectly. If I send it via USB/ulpt there are corrupted bytes in the job which mess up the printout in various ways. I've seen this too on current. It seemed that bytes are lost if output is blocked due to a full printers input buffer. I've thought that this was an incompatibility between my USB-printer adapter and the printer because the adapter works with other printers. With a May 30 kernel I have no problems with my HP Deskjet 895Cxi. Perhaps it depends on a certain chipset or printer... [EMAIL PROTECTED]:7:2: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x16 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)' class= serial bus subclass = USB Bye, Alexander. -- Failure is not an option. It comes bundled with your Microsoft product. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
VIA ACPI power management controller
Hi, is there a way to teach our ACPI implementation about [EMAIL PROTECTED]:7:4: class=0x068000 card=0x chip=0x30571106 rev=0x40 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class= bridge subclass = PCI-unknown Bye, Alexander. -- I believe the technical term is Oops! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-BETA from Jun 2 PANIC
GDB backtrace attached. /S GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x68 fault code = supervisor read, page not present instruction pointer = 0x8:0xc020dafd stack pointer = 0x10:0xe9d28ab8 frame pointer = 0x10:0xe9d28ae0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 10631 (sh) trap number = 12 panic: page fault Stack backtrace: syncing disks, buffers remaining... 3854 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 3845 giving up on 2816 buffers Uptime: 22h59m35s Dumping 511 MB [CTRL-C to abort] 16[CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 48[CTRL-C to abort] 64 80 96 112 128 144 160 176 192[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 208[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 224[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- warning: cannot find file for module rtc.ko warning: cannot find file for module vmmon_up.ko warning: cannot find file for module vmnet.ko Error while mapping shared library sections: rtc.ko: No such file or directory. Error while mapping shared library sections: vmmon_up.ko: Unknown error: 0. Error while mapping shared library sections: vmnet.ko: Unknown error: 0. Reading symbols from /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/vesa/vesa.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/vesa/vesa.ko.debug Reading symbols from /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/linux/linux.ko.debug Reading symbols from /boot/kernel/if_fxp.ko...done. Loaded symbols for /boot/kernel/if_fxp.ko Reading symbols from /boot/kernel/miibus.ko...done. Loaded symbols for /boot/kernel/miibus.ko Reading symbols from /boot/kernel/if_xl.ko...done. Loaded symbols for /boot/kernel/if_xl.ko Reading symbols from /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/agp/agp.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/agp/agp.ko.debug Reading symbols from /boot/kernel/nvidia.ko...done. Loaded symbols for /boot/kernel/nvidia.ko Reading symbols from /boot/kernel/ipl.ko...done. Loaded symbols for /boot/kernel/ipl.ko Reading symbols from /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug Reading symbols from /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/acpi/acpi.ko.debug Error while reading shared library symbols: rtc.ko: No such file or directory. Error while reading shared library symbols: vmmon_up.ko: No such file or directory. Error while reading shared library symbols: vmnet.ko: No such file or directory. Reading symbols from /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/if_---Type return to continue, or q return to quit--- tap/if_tap.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/THIRST/modules/usr/src/sys/modules/if_tap/if_tap.ko.debug Reading symbols from /boot/kernel/netgraph.ko...done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_bridge.ko...done. Loaded symbols for /boot/kernel/ng_bridge.ko Reading symbols from /boot/kernel/ng_socket.ko...done. Loaded symbols for /boot/kernel/ng_socket.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:238 238 dumping++; (kgdb) bt #0 doadump ()
Re: USB printing mangles printjob :-(
On Thu, Jun 05, 2003 at 04:11:23PM +0200, Alexander Leidinger wrote: On Thu, 5 Jun 2003 13:49:25 +0200 Bernd Walter [EMAIL PROTECTED] wrote: If I send that file to the printer via the parallel port, it prints perfectly. If I send it via USB/ulpt there are corrupted bytes in the job which mess up the printout in various ways. I've seen this too on current. It seemed that bytes are lost if output is blocked due to a full printers input buffer. I've thought that this was an incompatibility between my USB-printer adapter and the printer because the adapter works with other printers. With a May 30 kernel I have no problems with my HP Deskjet 895Cxi. Perhaps it depends on a certain chipset or printer... As my Adapter works with some printers my guess is a timing triggered bug. We will see exactly what it was when it's fixed :) -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: sed breakage
I managed to break sed in the course of fixing a bug yesterday. If you are having problems with buildworld breakage, ensure that you have the most recent version of sed by updating your source and rebuilding it manually. You need: $FreeBSD: src/usr.bin/sed/process.c,v 1.31 2003/06/05 12:10:19 fanf Exp $ The broken revision is: $FreeBSD: src/usr.bin/sed/process.c,v 1.30 2003/06/04 15:31:55 fanf Exp $ Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ HUMBER THAMES DOVER: SOUTHWESTERLY 4 OR 5, OCCASIONALLY 6. RAIN LATER. MODERATE OR GOOD. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
Bryan Liesner wrote: A non disclosure agreement is a non disclosure agreement, so no crap from me. I'll give that a try and see if it makes a difference. I don't remember off of the top of my head from the previous posts on this subject, but does this bug apply to an Athlon XP as well? The PSE bug applies to all CPU's that support 4M pages; it is a hardware bug. The PG_G is a seperate order of operation problem that gets workked around by disabling it; it is a software bug. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
Alexander Leidinger wrote: is there a way to teach our ACPI implementation about [EMAIL PROTECTED]:7:4: class=0x068000 card=0x chip=0x30571106 rev=0x40 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class= bridge subclass = PCI-unknown You could write code. There's documentation available from Via, but they only automatically give it to companies who are willing to sign NDA. They state on their site that they make decisions on sending technical documentation to Open Source driver writers on a case by case basis (which means they may tell you no, even if you are willing to NDA). You may have better luck with converting a Linux driver, if there's source available for one somewhere. Be aware that if your machine is a B (82C686B), then you have the buggy version of the chip; you need to eiter not use the second IDE channel for anything, or you need a BIOS update, or you need to make BIOS advanced settings changes (if your BIOS supports it, if you have the documentation necessary to make the changes, if the values are unlabelled in your BIOS, and if you can find and read the German web site that talks about the settings). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote: On Wed, 2003-06-04 at 14:16, Paul Richards wrote: On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote: Interfaces actually can be added at runtime. Existing objects (i.e. objects instantiated before the new interface was added) will continue to work as before. If methods from the new interface are called on old objects, the default method will be called. How can you add an interface at runtime? By loading a kernel module. If I load e.g. the agp kernel module, I add the agp_if interface to the kernel. Yes, I know that you can load a pre-compiled interface at runtime and thereby add that interface, but you can only create interfaces at build time because each method in the interface is uniquely identified by a kobjop_desc struct, which is what I was referring to. The code which is doing the method dispatch has no real idea what methods (or what interfaces for that matter) that the object's class implements. You can't use the classes method table layout for the ops table since the caller has no way of knowing that layout (and the layout will be different for almost every class in the system). One possible way of making this slightly simpler might be to make the class point at a table indexed by interface ID, each entry of which is a table indexed by a method ID from that interface. This sounds fine in theory but in practice, it would end up slower due to the two memory accesses. That's along the lines of what I suggested at the start of the thread :-) -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Thu, 2003-06-05 at 15:51, Paul Richards wrote: On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote: On Wed, 2003-06-04 at 14:16, Paul Richards wrote: On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote: Interfaces actually can be added at runtime. Existing objects (i.e. objects instantiated before the new interface was added) will continue to work as before. If methods from the new interface are called on old objects, the default method will be called. How can you add an interface at runtime? By loading a kernel module. If I load e.g. the agp kernel module, I add the agp_if interface to the kernel. Yes, I know that you can load a pre-compiled interface at runtime and thereby add that interface, but you can only create interfaces at build time because each method in the interface is uniquely identified by a kobjop_desc struct, which is what I was referring to. What has build time got to do with anything? At build time, you have no idea what interfaces are available either. Besides modules can be built at a different time from the rest of the kernel. The code which is doing the method dispatch has no real idea what methods (or what interfaces for that matter) that the object's class implements. You can't use the classes method table layout for the ops table since the caller has no way of knowing that layout (and the layout will be different for almost every class in the system). One possible way of making this slightly simpler might be to make the class point at a table indexed by interface ID, each entry of which is a table indexed by a method ID from that interface. This sounds fine in theory but in practice, it would end up slower due to the two memory accesses. That's along the lines of what I suggested at the start of the thread :-) Its still slower and wastes more memory and bloats the code for every call site. I have a better approach in mind which I will be trying out soonish. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Thu, 05 Jun 2003 07:45:03 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Be aware that if your machine is a B (82C686B), then you have It is. the buggy version of the chip; you need to eiter not use the second IDE channel for anything, or you need a BIOS update, or Not using the second IDE channel: not an option. BIOS update: how do I know if the latest BIOS for the port has the appropriate fix? I don't think the support people know enough to answer such a question. you need to make BIOS advanced settings changes (if your BIOS supports it, if you have the documentation necessary to make the changes, if the values are unlabelled in your BIOS, and if you can find and read the German web site that talks about the settings). Reading German is not a problem for me. But there are a lot of German webpages out there... which one? But this doesn't matter at the moment, there isn't a driver... Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New loader(8) plugin
On Thu, Jun 05, 2003 at 10:58:08AM -0300, Daniel C. Sobral wrote: Ruslan Ermilov wrote: Is there any real reason why loader.rc is not updated by default? I'd be interested to know how many people out It was my decision. Before I wrote the stuff in *.4th that is used nowadays to read loader.conf, one had to write a loader.rc script to do any kind of special processing one wanted. Also, if anyone *does* want something more sophisticated, like my menu that allows me to chose different extra *.conf files, which in turn allows me to do stuff like selecting between 4.x and 5.x from inside loader instead of boot0, one has to change loader.rc. We standard loader.rc does provide for flexibility in the following ways: 1) User may change /boot/loader.conf and /boot/loader.conf.local, while we may change /boot/defaults/loader.conf. 2) User may change /boot/loader.rc as he deems fit, while we may change loader.4th and support.4th to add features. Granted, the general overlay of loader.rc does restrict somewhat what features we can introduce. We could avoid this problem by having the standard loader.rc installed to /boot/defaults/loader.rc, and modifying loader(8) to parse /boot/loader.rc if it exists, and /boot/defaults/loader.rc otherwise. To my mind, however, it is possible to introduce Scott's beastie menu by making changes to loader.4th. In particular, we could change start in loader.4th, and, if we *really* feel like it is needed, copy the old version to some other word (old-start, non-beastie-start, whatever :). Also, if we do go that way, I'd like, for source style reasons, to have Scott's script changed not to use evaluate. :-) I can't comment here, Forth is double Dutch for me. ;) -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: ACPI and PCI vs interrupt routing on Sony VAIO's
On 04-Jun-2003 Paul Richards wrote:
On Wed, Jun 04, 2003 at 04:42:56AM -0700, Jun Su wrote:
Good Explain.
The same problem is in my PCG-R505DC.
Yes, it sounds exactly like the problem with my laptop too.
Please try:
Index: pci.c
===
RCS file: /usr/cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.215
diff -u -r1.215 pci.c
--- pci.c 31 May 2003 20:34:36 - 1.215
+++ pci.c 2 Jun 2003 20:09:08 -
@@ -798,7 +798,7 @@
}
if (cfg-intpin 0 PCI_INTERRUPT_VALID(cfg-intline)) {
-#ifdef __ia64__
+#if defined(__ia64__) || (defined(__i386__) !defined(SMP))
/*
* Re-route interrupts on ia64 so that we can get the
* I/O SAPIC interrupt numbers (the BIOS leaves legacy
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2311] ACPI and PCI vs interrupt routing on Sony VAIO's
On 04-Jun-2003 M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : I'm currently working on making the PCI interrupt routing work for SMP : and once that is done I plan to commit a change to make this : : #if defined(__ia64__) || defined(__i386__) : : However, if people find that the above patch fixes a lot of UP : machines for now I might commit it. I know that my Fiva 205 works with ACPI as long as I enter the right overrides to get the right interrupts. I've been using something similar. However, why not all architectures? Ideally, all architectures would route all PCI interrupts, and that is a good goal. However, I'm going to leave that up to each platform to implement and then add themselves to this list. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: VIA ACPI power management controller
On 05-Jun-2003 Alexander Leidinger wrote: Hi, is there a way to teach our ACPI implementation about [EMAIL PROTECTED]:7:4: class=0x068000 card=0x chip=0x30571106 rev=0x40 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class= bridge subclass = PCI-unknown It doesn't really need to know about it. Perhaps acpi should include a dummy driver similar to the 'hostb' driver to eat such devices. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Robert Watson wrote: | |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: VIA ACPI power management controller
On Thu, 05 Jun 2003 11:33:13 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: On 05-Jun-2003 Alexander Leidinger wrote: Hi, is there a way to teach our ACPI implementation about [EMAIL PROTECTED]:7:4: class=0x068000 card=0x chip=0x30571106 rev=0x40 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class= bridge subclass = PCI-unknown It doesn't really need to know about it. Perhaps acpi should include a dummy driver similar to the 'hostb' driver to eat such devices. Does this mean it should already display some thermal information, or does this mean it just needs to eat this device to be able to display the thermal information (I assume the information available via (x)mbmon should also be available via ACPI...)? (8) [EMAIL PROTECTED] # sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S1 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 0 hw.acpi.s4bios: 1 hw.acpi.verbose: 0 hw.acpi.disable_on_poweroff: 1 hw.acpi.cpu.max_speed: 2 hw.acpi.cpu.current_speed: 2 hw.acpi.cpu.performance_speed: 2 hw.acpi.cpu.economy_speed: 1 Bye, Alexander. -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP client dumping core
Try this patch: Yes, it works now, thanks. Will this patch be commited to src, or should I keep it and apply locally? Fred -- How much does it cost to entice a dope-smoking UNIX system guru to Dayton? -- UNIX/WORLD's First Annual Salary Survey, Brian Boyle pgp0.pgp Description: PGP signature
Re: 5.1-RELEASE TODO
Lars Eggert wrote: Robert Watson wrote: | |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Thu, Jun 05, 2003 at 04:06:16PM +0100, Doug Rabson wrote: On Thu, 2003-06-05 at 15:51, Paul Richards wrote: On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote: On Wed, 2003-06-04 at 14:16, Paul Richards wrote: On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote: Interfaces actually can be added at runtime. Existing objects (i.e. objects instantiated before the new interface was added) will continue to work as before. If methods from the new interface are called on old objects, the default method will be called. How can you add an interface at runtime? By loading a kernel module. If I load e.g. the agp kernel module, I add the agp_if interface to the kernel. Yes, I know that you can load a pre-compiled interface at runtime and thereby add that interface, but you can only create interfaces at build time because each method in the interface is uniquely identified by a kobjop_desc struct, which is what I was referring to. What has build time got to do with anything? At build time, you have no idea what interfaces are available either. Besides modules can be built at a different time from the rest of the kernel. My point was simply that interfaces can't be created other than at compile time because the kobjop_desc structures are used as unique identifiers. I wasn't making this point in relation to the discussion on knowing what methods are in the class, just from the point that interfaces can't be created or modified at runtime. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
Paul Richards wrote: On Wed, Jun 04, 2003 at 02:43:20PM +0100, Doug Rabson wrote: On Wed, 2003-06-04 at 14:16, Paul Richards wrote: How can you add an interface at runtime? By loading a kernel module. If I load e.g. the agp kernel module, I add the agp_if interface to the kernel. Yes, I know that you can load a pre-compiled interface at runtime and thereby add that interface, but you can only create interfaces at build time because each method in the interface is uniquely identified by a kobjop_desc struct, which is what I was referring to. The data structures associated with VFS do not have this design limitation, unless youaccidently add it (which is what started this thread in the first place). Since calls are by desciptor, and descriptor reference are arbitrary, you can create interfaces at runtime because you can add arbitrary descriptors. The Netgraph code can also create interfaces at runtime, though it does this in a different way (nodes who attach to them have to know about them, so the only way to add and use a new one is to load two modules, not one). One possible way of making this slightly simpler might be to make the class point at a table indexed by interface ID, each entry of which is a table indexed by a method ID from that interface. This sounds fine in theory but in practice, it would end up slower due to the two memory accesses. That's along the lines of what I suggested at the start of the thread :-) I'm not sure it could be made SMP safe. However, as to speed... the vnops array has this same limitation on speed; you can actually reduce this to one memory access at runtime, by precomputing the array position for the specific interface. The cost from doing this is that you have to rebuild all of your already created FS instances each time you add a VOP, for each mounted FS, so that the array reference doesn't run off the end of decriptor list. Another downside is that it is then nearly impossible to proxy across a single channel (e.g. to a filesystem developement framework in user space or across a network) without a very expensive reverse lookup. IMO, you would flag the underlying FS, and not do the optimization, if it was of one of those types. If the VOP's are relatively lightweight, you can get about an 8% speed improvement from doing the precomputation, and avoiding marshalling the data ito and out of a descriptor (these are around the numbers we achieved at Artisoft, when we ported the VFS stacking and FFS and UFS to Windows 95). Another trick you used to be able to do, before vfs_default.c, was to coelesce NULL layers that didn't have explicit vnode implementations of their own (e.g. the same way UFS and FFS are pre-coelesced). This saves the call-through. Actually, you could do this for GEOM, today, if you were willing to strip out the per-layer statistics gathering requirement; it would let you precompute the relative offsets per layer, and come up with a single parametric translation for an arbitrary number of layers, so long as there was a 1:1 block mapping. This would probably recover some of the speed lost in 5.x from using GEOM. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 5.1-RELEASE TODO
FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott Will this lead to an extension of the release schedule for 5.1 until most of the problems are fixed? To me it looks like there are more and more reports about panics every day :( Erik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 5.1-RELEASE TODO
--On Thursday, June 05, 2003 18:59:49 +0200 Erik Paulsen Skaalerud [EMAIL PROTECTED] wrote: FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott Will this lead to an extension of the release schedule for 5.1 until most of the problems are fixed? To me it looks like there are more and more reports about panics every day :( Erik For the record, yesterday's sources STILL produce the panic at 0x7 for me on transition to battery. I can get more crashdumps/kernels if someone asks. I've mentioned this for the last ~1.5 months. LER ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Larry Rosenman wrote: --On Thursday, June 05, 2003 18:59:49 +0200 Erik Paulsen Skaalerud [EMAIL PROTECTED] wrote: FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott Will this lead to an extension of the release schedule for 5.1 until most of the problems are fixed? To me it looks like there are more and more reports about panics every day :( Erik For the record, yesterday's sources STILL produce the panic at 0x7 for me on transition to battery. I can get more crashdumps/kernels if someone asks. I've mentioned this for the last ~1.5 months. LER The official position is that ACPI is in a transition period right now, and that while that gets worked out we encourage people to disable it on their systems if they are not in a position to actively debug and fix it. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth stack for FreeBSD
On Wed, Jun 04, 2003 at 09:32:32AM -0700, Maksim Yevmenkin wrote: Dear Hackers, Another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030604.tar.gz I am regret to announce that this is probably the last release. My company has announced that they will pull out of USA and i will most likely loose my job. Unless i find another position, i will be forced to return back home. If anyone knows/wants to hire a H1B slave please drop me a e-mail. I will consider any position within USA or even Europe. I am *really* sorry :( I will try to do my best and support the code, but i can not make any promises at this point. Awww :-( Someone should probably make you a committer so you can just update the Bluetooth code in FreeBSD as you feel like. ;-) Hey, thanks for all the good bluetooth work! -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
Alexander Leidinger wrote: Terry Lambert [EMAIL PROTECTED] wrote: Be aware that if your machine is a B (82C686B), then you have It is. the buggy version of the chip; you need to eiter not use the second IDE channel for anything, or you need a BIOS update, or Not using the second IDE channel: not an option. Additional PCI IDE controller... BIOS update: how do I know if the latest BIOS for the port has the appropriate fix? I don't think the support people know enough to answer such a question. They had better, or you had better find a different vendor. Reading German is not a problem for me. But there are a lot of German webpages out there... which one? But this doesn't matter at the moment, there isn't a driver... Here's the German page: http://www.hardtecs4u.com/reviews/2001/ep8kta3-mod/index12.php Basically: o Disable PCI master read caching o Lower PCI latency to 0-32 o Disable PCI delay transaction Yes, it's ugly on your PCI throughput; you are better off adding an IDE interface on a PCI card, IMO. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR in kern_thread.c
I was playing with libkse and got the follow LOR: lock order reversal 1st 0xc6ce0aa8 sigacts (sigacts) @ /local/usr.src/sys/kern/subr_trap.c:248 2nd 0xc6cbc250 process lock (process lock) @ /local/usr.src/sys/kern/kern_threa d.c:1439 Stack backtrace: backtrace(c04fd0b6,c6cbc250,c04f9a3a,c04f9a3a,c04fae7a) at backtrace+0x17 witness_lock(c6cbc250,8,c04fae7a,59f,c6bb8130) at witness_lock+0x692 _mtx_lock_flags(c6cbc250,0,c04fae7a,59f,c6cbc1e4,2,0,0,0) at _mtx_lock_flags+0xb 2 thread_signal_add(c6bb8130,2,c04fa4c7,85e,280a1e20) at thread_signal_add+0xe1 postsig(2,0,c04fcb3a,f8,20800) at postsig+0x34f ast(e98d9d48) at ast+0x41d doreti_ast() at doreti_ast+0x17 -gordon pgp0.pgp Description: PGP signature
Re: VIA ACPI power management controller
Alexander Leidinger wrote: On Thu, 05 Jun 2003 11:33:13 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: It doesn't really need to know about it. Perhaps acpi should include a dummy driver similar to the 'hostb' driver to eat such devices. Does this mean it should already display some thermal information, or does this mean it just needs to eat this device to be able to display the thermal information (I assume the information available via (x)mbmon should also be available via ACPI...)? Yes, if you have a BIOS that knows about all the ACPI features, and knows how to talk to the thermal monitoring parts of the chip. Again, this is a BIOS issue; you should contact your motherboard manufacturer. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2332] Re: 5.1-RELEASE TODO
On Thu, 5 Jun 2003, Scott Long wrote: Larry Rosenman wrote: For the record, yesterday's sources STILL produce the panic at 0x7 for me on transition to battery. I can get more crashdumps/kernels if someone asks. I've mentioned this for the last ~1.5 months. The official position is that ACPI is in a transition period right now, and that while that gets worked out we encourage people to disable it on their systems if they are not in a position to actively debug and fix it. For those who find they may need to disable acpi, you can selectively disable different components. Larry, since yours is on battery transition, try debug.acpi.disable.ec=1 or possibly one of the other options. I recall that you had a thermal problem also. For Paul, who was having irq probing issues, try hw.acpi.pci.link.%d.%d.%d.irq to set it explicitly while leaving ACPI enabled. http://www.freebsd.org/cgi/man.cgi?query=acpiapropos=0sektion=0manpath=FreeBSD+5.0-currentformat=html I have been working on Campi's and LER's problems. But I only do this in my free time. Your best bet is acpi-jp@ as the Intel people are very good at this. Several other BSD users have been stepping up to help on that list and they are very much appreciated. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Thu, 5 Jun 2003 16:14:25 +0200, Alexander Leidinger [EMAIL PROTECTED] wrote: Hi, is there a way to teach our ACPI implementation about [EMAIL PROTECTED]:7:4: class=0x068000 card=0x chip=0x30571106 rev=0x40 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class= bridge subclass = PCI-unknown I own the same chipest here, which it is support in 4.x and no longer in 5.x.. :-( Note that, I only check in the 5.x's NOTES and haven't tried to put some opinion from 4.x to 5.x yet. I don't know if it will work. In 4.x, you just add in the kernel config following: === # VT82C686A/B ACPI Power Management Controller device smbus device viapm device iicbus device iicbb device ic device iic device iicsmb === I would like to see someone to bring 4.x drivers to 5.x as well. Too bad, I know nothing with C, but just a hello world. Cheers, Mezz Bye, Alexander. -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Thu, 05 Jun 2003 13:10:35 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2003 16:14:25 +0200, Alexander Leidinger [EMAIL PROTECTED] wrote: Hi, is there a way to teach our ACPI implementation about [EMAIL PROTECTED]:7:4: class=0x068000 card=0x chip=0x30571106 rev=0x40 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class= bridge subclass = PCI-unknown Oh, it seems to be little different but I have the same 'VT82C686A/B ACPI Power Management Controller'.. === [EMAIL PROTECTED]:7:4: class=0x0c0500 card=0x30571106 chip=0x30571106 rev=0x40 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class= serial bus -- diff here.. subclass = SMBus -- diff here.. === Cheers, Mezz I own the same chipest here, which it is support in 4.x and no longer in 5.x.. :-( Note that, I only check in the 5.x's NOTES and haven't tried to put some opinion from 4.x to 5.x yet. I don't know if it will work. In 4.x, you just add in the kernel config following: === # VT82C686A/B ACPI Power Management Controller device smbus device viapm device iicbus device iicbb device ic device iic device iicsmb === I would like to see someone to bring 4.x drivers to 5.x as well. Too bad, I know nothing with C, but just a hello world. Cheers, Mezz Bye, Alexander. -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Thursday 05 June 2003 20:10, Jeremy Messenger wrote: I own the same chipest here, which it is support in 4.x and no longer in 5.x.. :-( Note that, I only check in the 5.x's NOTES You didn't check in the right NOTES then. 5-CURRENT has different NOTES files, one general, machine independent and several smaller others for each platform. The machine independent is in /usr/src/sys/conf, the others are in /usr/src/sys/ARCH/conf. -- | Michael Nottebrock| KDE on FreeBSD | ,ww | | [EMAIL PROTECTED] | --- | ,wWWCybaWW_) | | --- | http://freebsd.kde.org | free `WSheepW'| | http://tigress.com/lofi | --- | node II II | pgp0.pgp Description: signature
Re: VIA ACPI power management controller
On Thu, 5 Jun 2003 20:56:50 +0200, Michael Nottebrock [EMAIL PROTECTED] wrote: On Thursday 05 June 2003 20:10, Jeremy Messenger wrote: I own the same chipest here, which it is support in 4.x and no longer in 5.x.. :-( Note that, I only check in the 5.x's NOTES You didn't check in the right NOTES then. 5-CURRENT has different NOTES files, one general, machine independent and several smaller others for each platform. The machine independent is in /usr/src/sys/conf, the others are in /usr/src/sys/ARCH/conf. Do'h! You are right that I didn't check in /usr/src/sys/conf/.. It does exist and I am doing the rebuild kernel right now.. Thanks.. It's only thing that I dislike about 5.x is example configure files move to the different places (ie: NOTES, make.conf and etc).. I will get use to them, thought.. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
k5 build failure
kerberos5 sources cvsup'd from about 30 minutes ago. thanks. -Anthony. FreeBSD tool. 5.1-BETA FreeBSD 5.1-BETA #1: Wed May 21 10:11:40 EDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TOOL i386 === doc === lib === lib/libroken === lib/libvers === lib/libasn1 === lib/libhdb === lib/libkrb5 cc -O -pipe -mcpu=pentiumpro -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/des -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/include -I/usr/obj/usr/src/kerberos5/lib/libkrb5/../../lib/libkrb5 -I/usr/obj/usr/src/kerberos5/lib/libkrb5/../../lib/libasn1 -I/usr/src/kerberos5/lib/libkrb5/../../include -DHAVE_CONFIG_H -DINET6 -c /usr/src/crypto/heimdal/lib/krb5/crypto.c -o crypto.o /usr/src/crypto/heimdal/lib/krb5/crypto.c: In function `krb5_DES_schedule': /usr/src/crypto/heimdal/lib/krb5/crypto.c:157: warning: passing arg 2 of `DES_set_key' from incompatible pointer type /usr/src/crypto/heimdal/lib/krb5/crypto.c: In function `DES_string_to_key_int': /usr/src/crypto/heimdal/lib/krb5/crypto.c:187: incompatible type for argument 1 of `memset' /usr/src/crypto/heimdal/lib/krb5/crypto.c: In function `RSA_MD4_DES_checksum': /usr/src/crypto/heimdal/lib/krb5/crypto.c:934: warning: passing arg 4 of `DES_cbc_encrypt' from incompatible pointer type /usr/src/crypto/heimdal/lib/krb5/crypto.c: In function `RSA_MD4_DES_verify': /usr/src/crypto/heimdal/lib/krb5/crypto.c:957: warning: passing arg 4 of `DES_cbc_encrypt' from incompatible pointer type /usr/src/crypto/heimdal/lib/krb5/crypto.c: In function `RSA_MD5_DES_checksum': /usr/src/crypto/heimdal/lib/krb5/crypto.c:1009: warning: passing arg 4 of `DES_cbc_encrypt' from incompatible pointer type *** Error code 1 Stop in /usr/src/kerberos5/lib/libkrb5. *** Error code 1 Stop in /usr/src/kerberos5/lib. *** Error code 1 Stop in /usr/src/kerberos5. pgp0.pgp Description: PGP signature
Re: our compiler can't convert longlong to float? 5.1-RC1
Another thing with this code.
#include stdio.h
typedef long long longlong;
main()
{
longlong ll=1;
float f;
FILE *file=fopen(conftestval, w);
f = (float) ll;
fprintf(file,%g\n,f);
close(file);
I think this has to be fclose
exit (0);
}
--
Jan Stocker [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Thu, 05 Jun 2003 13:56:15 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2003 20:56:50 +0200, Michael Nottebrock [EMAIL PROTECTED] wrote: On Thursday 05 June 2003 20:10, Jeremy Messenger wrote: I own the same chipest here, which it is support in 4.x and no longer in 5.x.. :-( Note that, I only check in the 5.x's NOTES You didn't check in the right NOTES then. 5-CURRENT has different NOTES files, one general, machine independent and several smaller others for each platform. The machine independent is in /usr/src/sys/conf, the others are in /usr/src/sys/ARCH/conf. Do'h! You are right that I didn't check in /usr/src/sys/conf/.. It does exist and I am doing the rebuild kernel right now.. Thanks.. Here's the result: # dmesg | grep via viapropm0: SMBus I/O base at 0x5000 viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at device 7.4 on pci0 viapropm0: failed to enable port mapping! viapropm0: could not allocate bus space device_probe_and_attach: viapropm0 attach returned 6 [EMAIL PROTECTED]:7:4: class=0x0c0500 card=0x30571106 chip=0x30571106 rev=0x40 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class= serial bus subclass = SMBus I don't know what the errors mean.. Cheers, Mezz It's only thing that I dislike about 5.x is example configure files move to the different places (ie: NOTES, make.conf and etc).. I will get use to them, thought.. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: k5 build failure
On Thu, Jun 05, 2003 at 03:28:01PM -0400, Anthony Schneider wrote: kerberos5 sources cvsup'd from about 30 minutes ago. [...] cc -O -pipe -mcpu=pentiumpro -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/des -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/include -I/usr/obj/usr/src/kerberos5/lib/libkrb5/../../lib/libkrb5 -I/usr/obj/usr/src/kerberos5/lib/libkrb5/../../lib/libasn1 -I/usr/src/kerberos5/lib/libkrb5/../../include -DHAVE_CONFIG_H -DINET6 -c /usr/src/crypto/heimdal/lib/krb5/crypto.c -o crypto.o /usr/src/crypto/heimdal/lib/krb5/crypto.c: In function `krb5_DES_schedule': /usr/src/crypto/heimdal/lib/krb5/crypto.c:157: warning: passing arg 2 of `DES_set_key' from incompatible pointer type [...] Stop in /usr/src/kerberos5/lib/libkrb5. *** Error code 1 rm -rf /usr/obj/usr/src cd /usr/src make cleandir Then try again. -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: k5 build failure
same error. On Thu, Jun 05, 2003 at 11:17:07PM +0300, Ruslan Ermilov wrote: On Thu, Jun 05, 2003 at 03:28:01PM -0400, Anthony Schneider wrote: kerberos5 sources cvsup'd from about 30 minutes ago. [...] cc -O -pipe -mcpu=pentiumpro -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/des -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/include -I/usr/obj/usr/src/kerberos5/lib/libkrb5/../../lib/libkrb5 -I/usr/obj/usr/src/kerberos5/lib/libkrb5/../../lib/libasn1 -I/usr/src/kerberos5/lib/libkrb5/../../include -DHAVE_CONFIG_H -DINET6 -c /usr/src/crypto/heimdal/lib/krb5/crypto.c -o crypto.o /usr/src/crypto/heimdal/lib/krb5/crypto.c: In function `krb5_DES_schedule': /usr/src/crypto/heimdal/lib/krb5/crypto.c:157: warning: passing arg 2 of `DES_set_key' from incompatible pointer type [...] Stop in /usr/src/kerberos5/lib/libkrb5. *** Error code 1 rm -rf /usr/obj/usr/src cd /usr/src make cleandir Then try again. -- Ruslan ErmilovSysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: USB printing mangles printjob :-(
Can't say I've ever had a problem with my HP DJ5550 on a USB port. On Thu, 5 Jun 2003 16:26:25 +0200 Bernd Walter [EMAIL PROTECTED] wrote: On Thu, Jun 05, 2003 at 04:11:23PM +0200, Alexander Leidinger wrote: On Thu, 5 Jun 2003 13:49:25 +0200 Bernd Walter [EMAIL PROTECTED] wrote: If I send that file to the printer via the parallel port, it prints perfectly. If I send it via USB/ulpt there are corrupted bytes in the job which mess up the printout in various ways. I've seen this too on current. It seemed that bytes are lost if output is blocked due to a full printers input buffer. I've thought that this was an incompatibility between my USB-printer adapter and the printer because the adapter works with other printers. With a May 30 kernel I have no problems with my HP Deskjet 895Cxi. Perhaps it depends on a certain chipset or printer... As my Adapter works with some printers my guess is a timing triggered bug. We will see exactly what it was when it's fixed :) -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI + PCMCIA panic's.
Hello, I am having an issue with using acpi on a Compaq Armada M700. Without ACPI everything work's great with the exception of APM. (I had it working on a prior install, now for some reason it isn't). I've just lived with the fact that ACPI + PCMCIA didn't appear to like each other. It does random thing's when acpi in enabled, either it panic's, or it locks the laptop up and your forced to power the machine off (taking the card out doesn't bring it back), or, the laptop just reboots. Cardbus card's however work flawlessly with acpi enabled. I'm using Craig Boston's patch for the M700 ACPI problems. The link to his post is: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=868479+0+archive/2002/freebsd-current/20021208.freebsd-current This has allowed ACPI to work, and do everything it's suppost to, with the exception of PCMCIA. I have tested this using a GENERIC Kernel without any mod's what so ever and get the exact same results. The two devices I am having problems with are, my wireless pcmcia card, it's a Intersil based clone, and a SanDisk PCMCIA CF card reader. When it panic's here's what I get: wi0: INTERSIL HFA384x/IEEE at port 0x100-0x13f irq 11 fuction 0 config 1 on pccard0 NMI ISA a1, EISA ff RAM parity error, likely hardware failure. Fatal trap 19: non-maskable interrupt trap while in kernel mode instruction pointer = 0x8 :0xc0206b72 stack pointer = 0x10 :0xcf7edac0 frame pointer = 0x10 :0xcf7edae0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 8 (cbb0) trap number = 19 panic: non-maskable interrupt trap syncing disks, buffers remaining... done Uptime: 3s Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort or: pccard1: Allocation failed for cfe 0 ata2: SunDisk SDP at port 0x100-0x10f irq 11 function 0 config 1 on pccard1 kernel trap 19 with interrupts disabled NMI ISA b1, EISA ff RAM parity error, likely hardware failure. Fatal trap 19: non-maskable interrupt trap while in kernel mode instruction pointer = 0x8 :0xc039d9a0 stack pointer = 0x10 :0xcf7f0b00 frame pointer = 0x10 :0xcf7f0b3c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 current process = 9 (cbb1) trap number = 19 panic: non-maskable interrupt trap syncing disks, buffers remaining... done Uptime: 2s Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort --- I'm not sure if I've missed something that I should have done, but I'd appreciate any help in fixing this. I really need to be able to use ACPI, but at the same time have the ability to use the memory card reader and wi0. Once again, both work flawlessly when booting with ACPI disabled. Is there a part of ACPI I can disable to to get pcmcia working? Or is there a patch I could try, to try and fix this? The load on this machine is new, and can be trashed if need be, willing to test any patch. I am using the latest -CURRENT, but the problem exists since 5.0DP2 at least. Thank you, Chris. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 06/05/2003 breaks nvidia driver
Thanks for the suggestion about recompiling the nvidia driver, but I do after each kernel compile and install, so that isn't the answer, though not a bad idea. Recompiles of both the Linux-nvidia-port and the standalone-nvidia driver failed, so I am in the process, now, of backing out of everything that was updated. Are there any suggestions for better diagnosing of the problem? On 5 Jun, Scott Long wrote: [EMAIL PROTECTED] wrote: I am not on my 5.1-BETA2 system right now, so I don't have any useful details, but after CVSuping /usr/src early 05/06/2003 (after midnight), then build world and recompiling and installing my kernel, the nvidia driver checks out when X is loaded with a failure to initialize the driver. The system in question has run 5.1-BETA1 and earlier 5.1-BETA2 code before without any nvidia driver problem. In the meantime, any suggestions on how to provide useful information, other than just the XFree86.0.log file, would be helpful. I have used both of the native nvidia driver and the ports-linux version (once), but tend to stay with the native version (1.0-3203). There was yet another ABI change recently that affected the nvidia driver. The only thing to do is just recompile that driver. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2325] Re: ACPI and PCI vs interrupt routing on SonyVAIO's
John Baldwin wrote:
Please try:
Index: pci.c
===
RCS file: /usr/cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.215
diff -u -r1.215 pci.c
--- pci.c 31 May 2003 20:34:36 - 1.215
+++ pci.c 2 Jun 2003 20:09:08 -
@@ -798,7 +798,7 @@
}
if (cfg-intpin 0 PCI_INTERRUPT_VALID(cfg-intline)) {
-#ifdef __ia64__
+#if defined(__ia64__) || (defined(__i386__) !defined(SMP))
/*
* Re-route interrupts on ia64 so that we can get the
* I/O SAPIC interrupt numbers (the BIOS leaves legacy
Works for me. I now have sound without any pciconf commands. Most happy.
(...and I wouldn't have thought to do that there, guess that's why I'm
not the one with the commit access ).
It does try and route the same LNKx interrupts multiple times, but I guess
that won't matter unless they decide to change.
Iain
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
i386-undermydesk-freebsd?
What does i386-undermydesk-freebsd refer to? What is it used for? Is there an i386-inthedrawer-freebsd, or i386-intheXbox-freebsd? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386-undermydesk-freebsd?
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: What does i386-undermydesk-freebsd refer to? What is it used for? Is there an i386-inthedrawer-freebsd, or i386-intheXbox-freebsd? As a general rule of thumb, FreeBSD boxes should be kept under desks. If your system isn't under a desk, consider moving it. Best regards, Mike Barcroft ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386-undermydesk-freebsd?
On Thu, 5 Jun 2003, Mike Barcroft wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: What does i386-undermydesk-freebsd refer to? What is it used for? Is there an i386-inthedrawer-freebsd, or i386-intheXbox-freebsd? As a general rule of thumb, FreeBSD boxes should be kept under desks. If your system isn't under a desk, consider moving it. I must voice my difference of opinion because I have carpeted floors. At this point in time my Hoover isn't powered by FreeBSD... ;-) Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386-undermydesk-freebsd?
I thought it was the Monica Lewinsky edition of FreeBSD. On Thursday, June 5, 2003, at 07:20 PM, Mike Barcroft wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: What does i386-undermydesk-freebsd refer to? What is it used for? Is there an i386-inthedrawer-freebsd, or i386-intheXbox-freebsd? As a general rule of thumb, FreeBSD boxes should be kept under desks. If your system isn't under a desk, consider moving it. Best regards, Mike Barcroft ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Way forward with BIND 8
[ Please respect followups to -arch, thanks. ] As most of you are probably already aware, there have been two recent releases of BIND 8. Version 8.3.5 is the bugfix, and new minor features release on the 8.3.x branch that we've currently got in the tree already. 8.4.0 is (more or less) the all the bug fixes from 8.3.5, plus support for IPv6 transport version. Because there are over 14k lines of diff between the source for 8.3.5 and 8.4.0, I'm hesitant to import the latter right away. Instead, as the nominal BIND maintainer, I'm proposing the following plan: 1. Import 8.3.5 into HEAD, and upgrade the bind8 port. At the same time, create a bind84 port for the 8.4.x branch. The port will include the PORT_REPLACES_BASE functionality that we already have. 2. At some suitable point in the near future (definitely before the next 4.x release), MFC 8.3.5. 3. At some suitable point in the future, probably after the BIND 8.4.1 release, import 8.4.x into HEAD. I'm definitely in favor of improving support for IPv6, and BIND 8.4.x is going to be a big step in this direction. I'm just not sure that we should be adopting it in the base right away. My personal feeling is that having it in the ports for the convenience of early adopters is sufficient. However, my purpose in writing is to poll the community... I'm willing to be persuaded if folks have strong feelings about adopting 8.4.x in the base sooner rather than later, speak up now. FYI, for those wondering why I'm not considering BIND 9 for import, please see http://people.freebsd.org/~dougb/whybind8.html Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 06/05/2003 breaks nvidia driver
On Thu, 5 Jun 2003, 18:56-0500, [EMAIL PROTECTED] wrote: Thanks for the suggestion about recompiling the nvidia driver, but I do after each kernel compile and install, so that isn't the answer, though not a bad idea. Recompiles of both the Linux-nvidia-port and the standalone-nvidia driver failed, so I am in the process, now, of backing out of everything that was updated. Are there any suggestions for better diagnosing of the problem? nvidia.ko and X work OK for me on yesterday -current: nvidia0: GeForce4 MX 460 mem 0xef80-0xef87,0xf000-0xf7ff,0xed00-0xedff irq 11 at device 0.0 on pci1 Don't know what linux-nvidia-port is for. [...] -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP client dumping core
On Thu, 5 Jun 2003, 12:57-0300, Fred Souza wrote: Try this patch: Yes, it works now, thanks. Will this patch be commited to src, or should I keep it and apply locally? I have posted the patch to [EMAIL PROTECTED], hope he will commit it soon or later. FreeBSD will get this code with a next lukemftp import. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR: sched lock vs. sio + panic in sched_choose()
I've been getting a lot of these for the last two weeks on my SMP box. This panic is on -CURRENT from earlier today. Scheduler is ULE. lock order reversal 1st 0xc047f820 sched lock (sched lock) @ /usr/src/sys/kern/kern_intr.c:548 2nd 0xc04b83c0 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3242 Stack backtrace: backtrace(c0400378,c04b83c0,c0463120,c0463120,c041266b) at backtrace+0x17 witness_lock(c04b83c0,8,c041266b,caa,c11efc00) at witness_lock+0x697 _mtx_lock_spin_flags(c04b83c0,0,c041266b,caa,0) at _mtx_lock_spin_flags+0xd1 siocnputc(c0463280,d,5,d1d62b68,0) at siocnputc+0x81 cnputc(a,,1,c0415c53,c) at cnputc+0x56 putchar(a,d1d62b68,d1d62ab4,c0491d40,0) at putchar+0xcd kvprintf(c0415c52,c025eba0,d1d62b68,a,d1d62b88) at kvprintf+0x7d printf(c0415c52,c,c0415a4d,c03fe55b,c0489b20) at printf+0x57 trap_fatal(d1d62c14,38,d1d62bf0,c0236c9d,38) at trap_fatal+0x76 trap(d1d60018,c0240010,c0470010,c11dcbe0,c0482280) at trap+0x123 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0253ec7, esp = 0xd1d62c54, ebp = 0xd1d62c68 --- sched_choose(c11dee40,c03fe7a6,28c,0,c11db668) at sched_choose+0x77 choosethread(c11dcbe0,2,c03fdb89,1dc,b6e81bd0) at choosethread+0x36 mi_switch(c047f820,0,c03fb1fd,224,c11db5ac) at mi_switch+0x200 ithread_loop(c11da180,d1d62d48,c03fb0ae,30c,55ff44fd) at ithread_loop+0x256 fork_exit(c022caf0,c11da180,d1d62d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d62d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0253ec7 stack pointer = 0x10:0xd1d62c54 frame pointer = 0x10:0xd1d62c68 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (swi7: tty:sio clock) kernel: type 12 trap, code=0 Stopped at sched_choose+0x77: movl0x38(%eax),%eax I recall most if not all of these panics occuring when swi7: tty:sio clock is the current process. These are not completely repeatable, but if I simply reboot a couple of times, I can get the panic to occur while the rc scripts are being run. -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Way forward with BIND 8
At 12:09 AM -0700 2003/06/06, Doug Barton wrote: FYI, for those wondering why I'm not considering BIND 9 for import, please see http://people.freebsd.org/~dougb/whybind8.html I might be able to buy your arguments for supporting BIND 8 instead of BIND 9 in -STABLE, but not in -CURRENT. BIND 9 is the future. BIND 8 is ancient spaghetti code that only kinda-semi-sorta holds together, and there is only one guy working on maintaining it during the turn-down phase to EOL. BIND 9 uses new secure programming techniques that cause it to apply near-paranoid checks to data inputs and intentionally crash if it finds anything amiss. This helps ensure that almost all major input bugs are found and fixed before the code ever leaves the ISC. There's no sense re-hashing all these issues in e-mail -- I've got a whole host of reasons why BIND 8 is bad, and why BIND 9 is better. See slides 66-72 of my talk _Domain Name Server Comparison: BIND 8 vs. BIND 9 vs. djbdns vs. ???_, as presented at RIPE 44 in Amsterdam (at http://www.shub-internet.org/brad/papers/dnscomparison/DNSComp-RIPE44.pdf.gz). Also note that if you're going to flame someone for development on BIND 9, you shouldn't be flaming Nominum. They no longer do any work on BIND 9, and some of the people who were doing that work have been transferred to work directly for the ISC (as opposed to doing the work as Nominum employees under contract to the ISC). Indeed, even when Nominum was doing development on BIND 9 under contract to the ISC, the ISC still controlled the direction of the development and the overall manner in which the code would be written, with Nominum handling the implementation details. Therefore, even if you had these complaints years ago, you should still have addressed them to the ISC, not Nominum. Anyway, the argument for having separate -STABLE and -CURRENT branches is so that development on new code can progress, and adventurous types can give the new stuff a try (and help debug it), while less adventurous types can stick with tried-n-true. If you believe this argument at all, you cannot possibly justify keeping BIND 8 in -CURRENT. Virtually everything negative you have to say about BIND 9 is something that could also be said of -CURRENT. How do you expect that we can ever arrive at a -STABLE without first having a -CURRENT? Well, the same is true for BIND 9. Indeed, I'd say that BIND 9 is much more mature and production-ready than -CURRENT is most of the time (situations such as the current transition where we're just about to make 5.x the new -STABLE being the one exception I can think of). -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Way forward with BIND 8
On Fri, 6 Jun 2003, Brad Knowles wrote: At 12:09 AM -0700 2003/06/06, Doug Barton wrote: FYI, for those wondering why I'm not considering BIND 9 for import, please see http://people.freebsd.org/~dougb/whybind8.html I might be able to buy your arguments for supporting BIND 8 instead of BIND 9 in -STABLE, but not in -CURRENT. Regardless of whether I agree with the points you make here or not, the FreeBSD development model requires that what we import in -current, for the most part, be what we plan to eventually MFC. That factor alone eliminates the possibility of importing BIND 9 at this time. There's no sense re-hashing all these issues in e-mail and yet you felt the need to do so. Also note that if you're going to flame someone for development on BIND 9, Nothing I've had to say on this issue should be (or I think reasonably can be) interpreted as a flame. I've simply stated the reasons I think that BIND 9 isn't suitable for one particular purpose. Anyway, the argument for having separate -STABLE and -CURRENT branches is so that development on new code can progress, and adventurous types can give the new stuff a try (and help debug it), while less adventurous types can stick with tried-n-true. Correct, however historically the project has chosen what it wants to be adventurous about. Using the tried and true versions of things in src/contrib gives us more flexibility to be adventurous in the parts of the tree that are generated by the project. However, those who really want to embark on the adventure of testing bind 9 in production can do so using the port. Using the combination of NO_BIND in /etc/make.conf and PORT_REPLACES_BASE_BIND9 in ports/net/bind9, you can even have exactly what you're asking for. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Thu, 05 Jun 2003 14:57:19 -0500 Jeremy Messenger [EMAIL PROTECTED] wrote: Do'h! You are right that I didn't check in /usr/src/sys/conf/.. It does exist and I am doing the rebuild kernel right now.. Thanks.. Here's the result: # dmesg | grep via viapropm0: SMBus I/O base at 0x5000 viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at device 7.4 on pci0 viapropm0: failed to enable port mapping! viapropm0: could not allocate bus space device_probe_and_attach: viapropm0 attach returned 6 I don't know what the errors mean.. (4) [EMAIL PROTECTED] % dmesg |grep via Preloaded elf module /boot/kernel/snd_via82c686.ko at 0xc04ffc20. viapropm0: SMBus I/O base at 0x5000 viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at device 7.4 on pci0 viapropm0: failed to enable port mapping! viapropm0: could not allocate bus space device_probe_and_attach: viapropm0 attach returned 6 This problem is under investigation. We already know why this error gets printed, but there is still a discussion how to fix it cleanly. When you install xmbmon you can get some information out of it: ---snip--- (5) [EMAIL PROTECTED] % mbmon Temp.= 0.0, 0.0, 24.7; Rot.= 3479,0,0 Vcore = 1.64, 3.27; Volt. = 3.29, 5.00, 12.19, 0.00, 0.00 ---snip--- I started the thread to know how to integrate it into ACPI. Bye, Alexander. -- The computer revolution is over. The computers won. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 06/05/2003 breaks nvidia driver
After having installed 5.1-RC1, the nvidia driver, and named, are back in full operation. Yeah! On Thu, 5 Jun 2003 [EMAIL PROTECTED] wrote: Thanks for the suggestion about recompiling the nvidia driver, but I do after each kernel compile and install, so that isn't the answer, though not a bad idea. Recompiles of both the Linux-nvidia-port and the standalone-nvidia driver failed, so I am in the process, now, of backing out of everything that was updated. Are there any suggestions for better diagnosing of the problem? On 5 Jun, Scott Long wrote: [EMAIL PROTECTED] wrote: I am not on my 5.1-BETA2 system right now, so I don't have any useful details, but after CVSuping /usr/src early 05/06/2003 (after midnight), then build world and recompiling and installing my kernel, the nvidia driver checks out when X is loaded with a failure to initialize the driver. The system in question has run 5.1-BETA1 and earlier 5.1-BETA2 code before without any nvidia driver problem. In the meantime, any suggestions on how to provide useful information, other than just the XFree86.0.log file, would be helpful. I have used both of the native nvidia driver and the ports-linux version (once), but tend to stay with the native version (1.0-3203). There was yet another ABI change recently that affected the nvidia driver. The only thing to do is just recompile that driver. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Thu, 05 Jun 2003 10:14:39 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Alexander Leidinger wrote: Terry Lambert [EMAIL PROTECTED] wrote: Be aware that if your machine is a B (82C686B), then you have It is. I'm not that sure anymore... see below. the buggy version of the chip; you need to eiter not use the second IDE channel for anything, or you need a BIOS update, or Not using the second IDE channel: not an option. Additional PCI IDE controller... Having this information available via ACPI isn't worth that much money for me. I already get thermal information with xmbmon. BIOS update: how do I know if the latest BIOS for the port has the appropriate fix? I don't think the support people know enough to answer such a question. They had better, or you had better find a different vendor. It's an old board (KT133A chipset), my desktop system. I don't care that much, and I don't expect the vendor to support it for that long (typically I'm more optimistic, but it seems I know too much about how bad the world in reality is now). Basically: o Disable PCI master read caching o Lower PCI latency to 0-32 o Disable PCI delay transaction Yes, it's ugly on your PCI throughput; you are better off adding an IDE interface on a PCI card, IMO. I'm a little bit confused now... atapci0: VIA 82C686B UDMA100 controller port 0xd000-0xd00f at device 7.1 on pci0 viapropm0: VIA VT82C686A Power Management Unit port 0x5000-0x500f at device 7.4 on pci0 pcm0: VIA VT82C686A port 0xe400-0xe403,0xe000-0xe003,0xdc00-0xdcff irq 5 at device 7.5 on pci0 I think I should look at the chip itself... Bye, Alexander. -- Yes, I've heard of decaf. What's your point? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Lars Eggert writes: Robert Watson wrote: | |---++---+-- -| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+-- -| FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Also FYI. On my Shuttle AK35GTR (Version 1), when I turn on ACPI in the _latest_ BIOS version available I see something like: ffs_ufs: died with signal 8 on boot and the kernel then hangs. I _must_ turn off ACPI with FreeBSD, although it works with Windows XP. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Reproducible hard freeze on 5.1-CURRENT
Upon launching samba-2.2.8a (via ports) on the below system, the machine immediately hard freezes. I've included interesting portions of kernel config. Any suggestions how I can acquire more useful information ? # uname -a FreeBSD darwin 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Jun 5 12:28:54 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/darwin i386 options INCLUDE_CONFIG_FILE ident darwin machine i386 cpu I686_CPU options SMP options APIC_IO #optionsADAPTIVE_MUTEXES #optionsMUTEX_DEBUG #optionsMUTEX_PROFILING makeoptions DEBUG=-g makeoptions CONF_CFLAGS=-fno-builtin options KTRACE options KTRACE_REQUEST_POOL=101 options DDB options DDB_TRACE options DDB_UNATTENDED options ALT_BREAK_TO_DEBUGGER options SHOW_BUSYBUFS #optionsWITNESS #optionsWITNESS_DDB #optionsWITNESS_SKIPSPIN #optionsINVARIANTS #optionsINVARIANT_SUPPORT #optionsDIAGNOSTIC options INET options TCPDEBUG options TCP_DROP_SYNFIN options RANDOM_IP_ID options ZERO_COPY_SOCKETS options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK options PFIL_HOOKS options IPSTEALTH options IPSEC options IPSEC_ESP options IPSEC_DEBUG #optionsSCHED_4BSD options SCHED_ULE options COMPAT_43 options COMPAT_FREEBSD4 --- Robin P. Blanchard Systems Integration Specialist Georgia Center for Continuing Education fon: 706.542.2404 | fax: 706.542.6546 --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Thu, 05 Jun 2003 10:14:39 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Here's the German page: http://www.hardtecs4u.com/reviews/2001/ep8kta3-mod/index12.php Basically: o Disable PCI master read caching o Lower PCI latency to 0-32 o Disable PCI delay transaction Yes, it's ugly on your PCI throughput; you are better off adding an IDE interface on a PCI card, IMO. Isn't this the famous VIA bug which every computer magazine reported about? I thought we already have a fix in the tree for this: (2) [EMAIL PROTECTED] # dmesg |grep south atapci0: Correcting VIA config for southbridge data corruption bug Bye, Alexander. -- Yes, I've heard of decaf. What's your point? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
interesting problem
So... I have this nice SATA drive and controller which I believe is supported by FreeBSD but not in the default build for releases. What is the best way to cross-build a version of FreeBSD's release ISOs that will include drivers not included in the default distribution? Or is it possible to supply a driver during sysinstall time to have FreeBSD recognize my hard disk? Currently I can only get Mandrake linux 9.1 to install on this disk as it has the 2.4.21[pre release I assume] linux kernel that does recognize this controller [even Windows XP Pro does not recognize this newer hardware and I didn't get a floppy drive yet for the new machine]. Can I cross compile FreeBSD 5.1 [RC or otherwise] from Mandrake Linux to include the necessary support then burn a CD of the generated ISO images? It would be super-cool if I could :) and a decent learning experience Might be worth documenting it if I can figure it out. Dave ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTP and command-line multiple downloads
On Sat, Feb 15, 2003 at 05:46:37PM +0300, Yar Tikhiy wrote: On Fri, Feb 14, 2003 at 03:37:49PM -0800, Kris Kennaway wrote: On Fri, Feb 14, 2003 at 03:34:06PM -0800, Kris Kennaway wrote: Since upgrading bento to running 5.0, it appears that I can no longer download multiple files from a FTP server by specifying a glob pattern on the command-line: e.g. /usr/bin/ftp -4a ftp://snapshots.jp.freebsd.org/pub/FreeBSD/snapshots/alpha/5-LATEST/base/base.\?\? This appears to work (as it used to) under 4.x. As far as I can see, this is a client-side problem of CURRENT's ftp(1). FreeBSD ftp(1) was completely replaced with lukemftp, ftp client from NetBSD, in CURRENT a year ago. The commit message was promising: ...Lukemftp supports most of the previous features of FreeBSD ftp, but has been better maintained and includes new features. Unfortunately, this particular feature doesn't fall into that most; lukemftp can't seem to detect a glob pattern on the command line. I must admit that I overlooked this feature in lukemftp. In fact, lukemftp can download multiple files specified as a wildcard via ftp. However, lukemftp accepts wildcards only in the classic ftp file specification, i.e., host:path/file, and not in URLs. Do you think the ability to use command-line wildcards should be extended to URLs as well? Luke Mewburn may be convinced to do that in his ftp client. Technically, the task is as easy as removing a single logical subexpression from an if statement. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Way forward with BIND 8
On Fri, Jun 06, 2003 at 03:01:02AM -0700, Doug Barton wrote: FreeBSD development model requires that what we import in -current, for the most part, be what we plan to eventually MFC. That factor alone eliminates the possibility of importing BIND 9 at this time. Sorry to wade in here - let me just ask for clarification on something. Are you stating as the BIND maintainer around these parts that FreeBSD will never have BIND 9? That even though BIND 8 is no longer a current release according to the ISC webpage, and they're only carrying it as it is still in wide usage - i.e. everybody should be upgrading to 9 - you don't plan to drop 9 in as the standard, default resolver? Not just now, but you have no plans to do so currently at all? It's your use of the word eventually which is pricking my ears up here.. This is almost as bad as OpenBSD sticking with BIND 4... Correct, however historically the project has chosen what it wants to be adventurous about. Using the tried and true versions of things in src/contrib gives us more flexibility to be adventurous in the parts of the tree that are generated by the project. ISC claim BIND 9 to be the current release. 9.2.2 was released on March 3rd. I've been running it on one box here since March 5th. I have no issues. It is stable. It *will* act as a drop-in replacement for BIND 8 if you wish, except it's more secure, development is continuing on it, and in my experience, it performs better. I'm sure you have your reasons, I'm just not sure what they are. Can you spell out the objections? Perhaps off list? I'm just curious... not even you, anybody here who can explain why 9 is evil and 8 is great... 9 in production can do so using the port. Using the combination of NO_BIND in /etc/make.conf and PORT_REPLACES_BASE_BIND9 in ports/net/bind9, you can even have exactly what you're asking for. But why make users jump through hoops to run the most secure, stable and supported version of BIND? Sorry, just don't get it... -- Paul Robinson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Way forward with BIND 8
On 2003.06.06 14:36:44 +0100, Paul Robinson wrote: This is almost as bad as OpenBSD sticking with BIND 4... OpenBSD has actually uses BIND 9 now... -- Simon L. Nielsen pgp0.pgp Description: PGP signature
Re: interesting problem
It seems David Leimbach wrote: So... I have this nice SATA drive and controller which I believe is supported by FreeBSD but not in the default build for releases. What is the best way to cross-build a version of FreeBSD's release ISOs that will include drivers not included in the default distribution? Or is it possible to supply a driver during sysinstall time to have FreeBSD recognize my hard disk? There is no ATA support that is not included in the stock GENERIC kernel, so I'm not sure what you mean here ? It would be helpfull to know what controller and disk we are talking about, 'a' SATA controller and disk isn't really helpfull :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
How to ask for help on this list (was Re: Reproducible hard freezeon 5.1-CURRENT)
On Fri, 6 Jun 2003 08:48:17 -0400 Robin P. Blanchard [EMAIL PROTECTED] wrote: Upon launching samba-2.2.8a (via ports) on the below system, the machine immediately hard freezes. I've included interesting portions of kernel config. Any suggestions how I can acquire more useful information ? [snip] #optionsWITNESS #optionsWITNESS_DDB #optionsWITNESS_SKIPSPIN #optionsINVARIANTS #optionsINVARIANT_SUPPORT #optionsDIAGNOSTIC [snip] #optionsSCHED_4BSD options SCHED_ULE This is not to pick on you in particular. There have been a lot of these lately and I just picked this one to reply to. None of this is new, these points have already been made elsewhere and people on this list should be familiar with them. But I'll go ahead and point them out anyway. If you experience a freeze, panic, or any other fatal problem please keep in mind the following things: 1. There is a reason SCHED_ULE is labeled 'experimental'. It means that this is a new feature that needs some more testing and deguggin. Don't be surprised if it panics your system, eats your homework, or causes your hair to fall out. If you insist on using it, then please properly label your email with such information, and at the very least try to determine if _not_ using it makes your problems go away. 2. Before you report a problem enable all the debugging options in your kernel configuration file. If you don't want to put up with the reduction in performance, then build two kernels from the same source: one without the debuging options and one with. When you hit a problem, boot into the kernel with the debugging options and try to reproduce the problem. Report any Lock Oreder Reversals (LORs) and other errors reported by the kernel. When you do report a problem like my box freezes it is essential that you at least have 'options DDB' in your kernel so you can attempt to enter the kernel debugger and get an idea of what's happening. If enabling the debugging options makes your problems go away, that is helpful information in and of itself, so report it. 3. There is an entry in The Handbook and the Articles that provide information on how to obtain debuging information from your kernel. Greg Lehey also has an article about that in the works (see archives). Please read these before you ask How can I get more debugging information. 4. Some problems, are caused by faulty hardware. The ports tree has some applications you can use to check your hardware (memtest86, etc). If you see random panics and/or freezes it may be a good idea to use some of these programs to check your hardware. Believe it or not, hardware does fail, so don't discount this possibility. 5. You can greatly increase the chance that your problem gets resolved if you provide good quality debugging information, and actually do some of the diagnosing yourself. Even a partial attempt at solving the problem is better than nothing. 6. Finally, please try to understand that this is a volunteer project. Few developers actually get paid to work on FreeBSD, and when they do it's usually for something specific that their employer needs. Most developers give up free time during the week to work on FreeBSD. So, it may not be possible to devote the time and energy you believe your problem deserves. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interesting problem
On Friday, June 6, 2003, at 08:53 AM, Soeren Schmidt wrote: It seems David Leimbach wrote: So... I have this nice SATA drive and controller which I believe is supported by FreeBSD but not in the default build for releases. What is the best way to cross-build a version of FreeBSD's release ISOs that will include drivers not included in the default distribution? Or is it possible to supply a driver during sysinstall time to have FreeBSD recognize my hard disk? There is no ATA support that is not included in the stock GENERIC kernel, so I'm not sure what you mean here ? It would be helpfull to know what controller and disk we are talking about, 'a' SATA controller and disk isn't really helpfull :) Interesting... I thought for certain someone had told me there was a driver for the Silicon Image Sil 3112A Controller in FreeBSD. The disk is a Western Digital Raptor http://www.westerndigital.com/en/products/serialata/ EnterpriseDrives.asp#spec So far it works quite nicely with Mandrake 9.1. I have another disk I can load FreeBSD onto. How would I go about getting/adding support for this controller? Dave -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interesting problem
It seems dave wrote: It seems David Leimbach wrote: So... I have this nice SATA drive and controller which I believe is supported by FreeBSD but not in the default build for releases. What is the best way to cross-build a version of FreeBSD's release ISOs that will include drivers not included in the default distribution? Or is it possible to supply a driver during sysinstall time to have FreeBSD recognize my hard disk? There is no ATA support that is not included in the stock GENERIC kernel, so I'm not sure what you mean here ? It would be helpfull to know what controller and disk we are talking about, 'a' SATA controller and disk isn't really helpfull :) Interesting... I thought for certain someone had told me there was a driver for the Silicon Image Sil 3112A Controller in FreeBSD. No, that one is no supported (yet). The disk is a Western Digital Raptor http://www.westerndigital.com/en/products/serialata/ EnterpriseDrives.asp#spec So far it works quite nicely with Mandrake 9.1. I have another disk I can load FreeBSD onto. How would I go about getting/adding support for this controller? Get me a 3112 based controller on my desk :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Way forward with BIND 8
On Fri, Jun 06, 2003 at 03:01:02AM -0700, Doug Barton wrote: On Fri, 6 Jun 2003, Brad Knowles wrote: At 12:09 AM -0700 2003/06/06, Doug Barton wrote: FYI, for those wondering why I'm not considering BIND 9 for import, please see http://people.freebsd.org/~dougb/whybind8.html I might be able to buy your arguments for supporting BIND 8 instead of BIND 9 in -STABLE, but not in -CURRENT. Regardless of whether I agree with the points you make here or not, the FreeBSD development model requires that what we import in -current, for the most part, be what we plan to eventually MFC. That factor alone eliminates the possibility of importing BIND 9 at this time. Why? There's no basis for assuming that everything that goes into -current must be MFCd. The -current branch is for our next generation version of the OS with all the new whizzy features we might want and BIND9 is therefore exactly the sort of thing to add to -current, with no intention of ever MFCing it. The requirement is that nothing goes direct into -stable, that it must all go through -current first. that doesn't however imply that everything going into -current must be suitable for MFCing. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Fri, 6 Jun 2003, Alexander Leidinger wrote: This problem is under investigation. We already know why this error gets printed, but there is still a discussion how to fix it cleanly. This is what I'll likely commit in the short term. Index: pci.c === RCS file: /home/cvs/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.215 diff -u -u -r1.215 pci.c --- pci.c 31 May 2003 20:34:36 - 1.215 +++ pci.c 4 Jun 2003 12:38:12 - @@ -175,6 +175,12 @@ enable these bits correctly. We'd like to do this all the time, but there\n\ are some peripherals that this causes problems with.); +static int pci_disable_io_mode_sanity = 0; +TUNABLE_INT(hw.pci.disable_io_mode_sanity, (int *)pci_disable_io_mode_sanity); +SYSCTL_INT(_hw_pci, OID_AUTO, disable_io_mode_sanity, CTLFLAG_RW, + pci_disable_io_mode_sanity, 0, + Disable PCI IO mode sanity checks in resource allocation.); + /* Find a device_t by bus/slot/function */ device_t @@ -1326,6 +1332,7 @@ struct pci_devinfo *dinfo = device_get_ivars(child); struct resource_list *rl = dinfo-resources; pcicfgregs *cfg = dinfo-cfg; + int error; /* * Perform lazy resource allocation @@ -1358,7 +1365,8 @@ * Enable the I/O mode. We should also be allocating * resources too. XXX */ - if (PCI_ENABLE_IO(dev, child, type)) + error = PCI_ENABLE_IO(dev, child, type); + if (error !pci_disable_io_mode_sanity) return (NULL); break; } -- | 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 | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Way forward with BIND 8
Paul Robinson wrote: On Fri, Jun 06, 2003 at 03:01:02AM -0700, Doug Barton wrote: FreeBSD development model requires that what we import in -current, for the most part, be what we plan to eventually MFC. That factor alone eliminates the possibility of importing BIND 9 at this time. Sorry to wade in here - let me just ask for clarification on something. Are you stating as the BIND maintainer around these parts that FreeBSD will never have BIND 9? That even though BIND 8 is no longer a current release according to the ISC webpage, and they're only carrying it as it is still in wide usage - i.e. everybody should be upgrading to 9 - you don't plan to drop 9 in as the standard, default resolver? Not just now, but you have no plans to do so currently at all? It's your use of the word eventually which is pricking my ears up here.. Just to jump in and help out. The at this time part of his response says to me that the current mixed status of 5 as -CURRENT as well as -RELEASE and the current effort to get 5 -STABLE is what's preventing the import of BIND 9. Once 5 is branched to a 6-CURRENT, I'm sure the possibility will open up to import BIND 9 again. At that time ... Correct, however historically the project has chosen what it wants to be adventurous about. Using the tried and true versions of things in src/contrib gives us more flexibility to be adventurous in the parts of the tree that are generated by the project. ISC claim BIND 9 to be the current release. 9.2.2 was released on March 3rd. I've been running it on one box here since March 5th. I have no issues. It is stable. It *will* act as a drop-in replacement for BIND 8 if you wish, except it's more secure, development is continuing on it, and in my experience, it performs better. I'm sure you have your reasons, I'm just not sure what they are. Can you spell out the objections? Perhaps off list? I'm just curious... not even you, anybody here who can explain why 9 is evil and 8 is great... I don't know details. But my experience with the FreeBSD folks is that they don't jump on a new version just because the vendor says, everyone should move to this new version. Apache, as a related example, is pushing hard to have everyone on 2.x. But if Apache were a part of the base FreeBSD and it moved to 2.x, it would have major stability problems with things like PHP (who is recommending that people do NOT use Apache 2 with PHP) So, as I see it, the FreeBSD developers carefully evaluate claims of newer, better and make decisions based on internal testing and experience - not marketing hype. Of course, the BIND folks don't want to continue to maintain BIND 8, so it's only natural for them to push BIND 9. 9 in production can do so using the port. Using the combination of NO_BIND in /etc/make.conf and PORT_REPLACES_BASE_BIND9 in ports/net/bind9, you can even have exactly what you're asking for. But why make users jump through hoops to run the most secure, stable and supported version of BIND? Sorry, just don't get it... Because, in the conservative opinion of the FreeBSD developers, it's not that proven yet. Also, the current development status of the source tree makes it a PITA to do at this time. Personally, I don't consider installing a port jumping through hoops, but that's just me. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On Fri, 6 Jun 2003 10:25:55 -0400 (EDT) Matthew N. Dodd [EMAIL PROTECTED] wrote: This is what I'll likely commit in the short term. [globally disable the check with a sysctl] To have this at boot time we have to set it in loader.conf, but then we not only do not check for viapm, we also don't check for every user of this API... I haven't followed the entire discussion, but what happened to the proposal to just disable the test for known bad hardware? Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interesting problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 06 June 2003 14.21, Soeren Schmidt wrote: Get me a 3112 based controller on my desk :) If this is an option, let me know what make and model you would need and I will make sure we get a sponsor for such a controller from the sponsor of www.fruitsalad.org so that you can work on a driver, let me know if we want to go ahead and get this going, is it also possible to work on 3ware SATA support if I provide such a controller? Matt - -- - Matt Douhan www.fruitsalad.org CCIE #4004 *** ping elvis *** *** elvis is alive *** -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+4M29kU5PITZniCURAmTeAJ9dLpPJNtTza25ZTaaYH0o2Q7QRGwCcCcgJ k0S/ArdjNY17fW6jhKX43EY= =zLnv -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup 06/05/2003 breaks nvidia driver
If you started X (by itself) and the screen flickered on and off, then I would suspect that it is being told to use a video mode that your card, or more likely - monitor, won't support. If that is true, then you could be in danger of damaging your monitor. 1) Got all available documentation available (online and from supplied manuals) on my flat-panel monitor and video card with respect to video modes, including horizontal and vertical frequencies 2) Manually modified a previously existing (FBSD-4.8) XF86Config file to include the proper frequencies and raw modelines (without all of the frequency information) for the identified video modes from the documentation 3) Downloaded the FreeBSD nvidia driver from nvidia.com 4) Compiled and installed the nvidia driver 5) Included nvidia enable in /boot/loader.conf 6) Started X by itself to make sure that it was stable with the default mode that I had chosen in the XF86Config file (ie; the basic/default X window was steady) 7) Started X + Gnome and used xvidtune to fine tune the modelines and choose which to use 8) Found some reference to two settable sysctl variables (hw.nvidiaAGP..) and enabled them, though they don't appear to be necessary for normal operation 9) Found some reference (nvidia MANual page?) about three AGP modes definable in the XF86Config file (chooses between OS AGP support versus onboard AGP support), though they don't seem to be necessary 10) Recompile nvidia driver after every 5.1 kernel recompile Worked with 5.1-BETA1, and 5.1-BETA2 (up until the last source update, May 28th or so). Works with 5.1-RC1. I did not try 5.0. On 6 Jun, Matt wrote: none said: After having installed 5.1-RC1, the nvidia driver, and named, are back in full operation. Yeah! Can I just ask you a question abuot this? What are the steps you went through to get this driver to work? I tried this on 5.0-CURRENT a while back and the below happened: I have a nvidia geforce 4 MX 220. I tried installing /usr/ports/x11/nvidia-driver which compiled fine. I changed the XF86Config to use driver nvidia, kldload'd the module which loaded fine and detected my video card. However when I started X the screen flickered on and off several times and then the pc rebooted without any panic or anything. I tried adding agp options etc and same thing happened. What have you done to get it to work? I'm on 5.1-RELEASE now but have not tried it again yet. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA ACPI power management controller
On 05-Jun-2003 Alexander Leidinger wrote: On Thu, 05 Jun 2003 11:33:13 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: On 05-Jun-2003 Alexander Leidinger wrote: Hi, is there a way to teach our ACPI implementation about [EMAIL PROTECTED]:7:4: class=0x068000 card=0x chip=0x30571106 rev=0x40 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C686A/B ACPI Power Management Controller' class= bridge subclass = PCI-unknown It doesn't really need to know about it. Perhaps acpi should include a dummy driver similar to the 'hostb' driver to eat such devices. Does this mean it should already display some thermal information, or does this mean it just needs to eat this device to be able to display the thermal information (I assume the information available via (x)mbmon should also be available via ACPI...)? If your ACPI support includes a thermal zone it will show up in the sysctl. The only reason to eat this device is to keep people from asking why it is there. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: LOR: sched lock vs. sio + panic in sched_choose() [ULE + SMPpanic]
On 06-Jun-2003 David P. Reese Jr. wrote: I've been getting a lot of these for the last two weeks on my SMP box. This panic is on -CURRENT from earlier today. Scheduler is ULE. lock order reversal 1st 0xc047f820 sched lock (sched lock) @ /usr/src/sys/kern/kern_intr.c:548 2nd 0xc04b83c0 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3242 This is a duplicate panic because you are using a serial console. Stack backtrace: backtrace(c0400378,c04b83c0,c0463120,c0463120,c041266b) at backtrace+0x17 witness_lock(c04b83c0,8,c041266b,caa,c11efc00) at witness_lock+0x697 _mtx_lock_spin_flags(c04b83c0,0,c041266b,caa,0) at _mtx_lock_spin_flags+0xd1 siocnputc(c0463280,d,5,d1d62b68,0) at siocnputc+0x81 cnputc(a,,1,c0415c53,c) at cnputc+0x56 putchar(a,d1d62b68,d1d62ab4,c0491d40,0) at putchar+0xcd kvprintf(c0415c52,c025eba0,d1d62b68,a,d1d62b88) at kvprintf+0x7d printf(c0415c52,c,c0415a4d,c03fe55b,c0489b20) at printf+0x57 This is the real panic below: trap_fatal(d1d62c14,38,d1d62bf0,c0236c9d,38) at trap_fatal+0x76 trap(d1d60018,c0240010,c0470010,c11dcbe0,c0482280) at trap+0x123 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0253ec7, esp = 0xd1d62c54, ebp = 0xd1d62c68 --- sched_choose(c11dee40,c03fe7a6,28c,0,c11db668) at sched_choose+0x77 choosethread(c11dcbe0,2,c03fdb89,1dc,b6e81bd0) at choosethread+0x36 mi_switch(c047f820,0,c03fb1fd,224,c11db5ac) at mi_switch+0x200 ithread_loop(c11da180,d1d62d48,c03fb0ae,30c,55ff44fd) at ithread_loop+0x256 fork_exit(c022caf0,c11da180,d1d62d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d62d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0253ec7 stack pointer = 0x10:0xd1d62c54 frame pointer = 0x10:0xd1d62c68 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (swi7: tty:sio clock) kernel: type 12 trap, code=0 Stopped at sched_choose+0x77: movl0x38(%eax),%eax This is a ULE and SMP panic that Jeff keeps looking for. Seems to be a NULL pointer deference of some sort. I recall most if not all of these panics occuring when swi7: tty:sio clock is the current process. These are not completely repeatable, but if I simply reboot a couple of times, I can get the panic to occur while the rc scripts are being run. Can you do a 'l *sched_choose+0x77' in gdb on kernel.debug to get the source line corresponding to this panic? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: k5 build failure
Maybe you could show us your /etc/make.conf and the exact command line (and environment) to build world then? it now dies with the appended error. make.conf: # -- use.perl generated deltas -- # # Created: Tue May 20 15:18:24 2003 # Setting to use base perl from ports: PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo command is: cvsup -g /root/supfile cd /usr/src make buildworld supfile has everything except games and ports. i think i might want to just completely delete /usr/src and start over. -Anthony. cc -O -pipe -mcpu=pentiumpro -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/gssapi -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/lib/des -I/usr/src/kerberos5/lib/libgssapi/../../../crypto/heimdal/include -I/usr/obj/usr/src/kerberos5/lib/libgssapi/../../lib/libasn1 -I/usr/obj/usr/src/kerberos5/lib/libgssapi -I/usr/src/kerberos5/lib/libgssapi/../../include -DHAVE_CONFIG_H -DINET6 -c /usr/src/crypto/heimdal/lib/gssapi/get_mic.c -o get_mic.o /usr/src/crypto/heimdal/lib/gssapi/get_mic.c: In function `mic_des': /usr/src/crypto/heimdal/lib/gssapi/get_mic.c:116: incompatible type for argument 1 of `memset' *** Error code 1 Stop in /usr/src/kerberos5/lib/libgssapi. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. pgp0.pgp Description: PGP signature
[PATCH] hcsecd(8) Bluetooth link keys/PIN codes management daemon
Dear Hackers,
please find attached patch for the hcsecd(8) Bluetooth link keys/PIN
codes management daemon. this patch is against the latest release
http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030604.tar.gz
hcsecd(8) is now able to cache link keys that were generated from the
PIN codes. to preserve link keys between restarts hcsecd(8) will dump
links keys on disk and read them upon next start.
this functionality is required to implement link keys database for
'paired' devices. in particular one can now 'pair' cell phone and PC
(with PIN code) and both sides will store the link key. in the future
the cell the phone can accept incoming connection from the PC without
being put into 'discoverable' mode. ('discoverable' mode is when the
cell phone answers inquiry).
note that hcsecd(8) must be running all the time, otherwise cell phone
will not be able to receive link key and will 'forget' PC on next
connection attempt. if this happens 'paring' procedure must be repeated.
i would like to thank Alex [EMAIL PROTECTED] for reporting this
problem and helping with testing.
thanks,
max
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
hcsecd.patch
Description: hcsecd.patch
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Ports Bug (Nagios)
I found a bug in the /ports/net/naios port. More correctly, I think it would be in /ports/net/nagios-plugins. I had Postgres 7.2 installed on my system. I did this manually from source. It seems that when you choose to have postgres support for nagios, it doesn't check to see if the library exists, but instead looks to see if the port was installed. This resulted in my install getting clobbered, directory permissions getting reassigned and my database going down. TTYL Adam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports Bug (Nagios)
Adam wrote: I found a bug in the /ports/net/naios port. More correctly, I think it would be in /ports/net/nagios-plugins. I had Postgres 7.2 installed on my system. I did this manually from source. It seems that when you choose to have postgres support for nagios, it doesn't check to see if the library exists, but instead looks to see if the port was installed. This resulted in my install getting clobbered, directory permissions getting reassigned and my database going down. A lot of ports have this problem. For example, I saw it recently with py-MySQLdb, which attempted to re-install MySQL for me. ugh Fortunately, I've long ago learned an important lesson: If you compile software manually, do NOT install it in /usr/local. Otherwise, the FreeBSD ports/package system will happily blow it away for you. Of course, if you install it elsewhere, then ports won't find it and will install a new version in /usr/local anyway. At least this way your custom version won't get destroyed. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom_vol_ffs problems
I've nailed it down to this: geom_vol_ffs assumes that a file system
is able to fill the partition completely. That's not a valid
assumption, since the file system size is a multiple of the file
system block size (in my case 16k bytes = 32 blocks), and the
partition size is/should be a multiple of the sectors/cylinder count
(in my case 1008).
For this assumption to be valid, the sectors/cylinder count would have
to be a multiple of the file system block size (measured in blocks),
and there's no guarantee that that's the case.
In my case, the size of the filesystem on ad0s3f (the one that does
not appear in /dev/vol/) is one block less than the size of ad0s3f
itself, so geom_vol_ffs refuses to create a provider for it (lines 96
and 102 in geom_vol_ffs.c):
if (fs-fs_old_size * fs-fs_fsize !=
(int32_t) pp-mediasize) {
g_free(fs);
continue;
}
Part of the problem here is my disklabel - it's hand-made, and the
size of the f partition (where geom_vol_ffs fails) is an odd number
- 3054277 - so that's impossible for the file system to fill it
completely.
I should create my disklabels so that the size of each partition is a
multiple of the number of sectors per cylinder. However, this is not
sufficient for geom_vol_ffs to do what it's supposed to, for the
reason explained above.
I think geom_vol_ffs.c at least should test for this instead:
if ((fs-fs_old_size * fs-fs_fsize
(int32_t) pp-mediasize) ||
((int32_t) pp-mediasize - fs-fs_old_size * fs-fs_fsize =
fs-fs_bsize)) {
g_free(fs);
continue;
}
The (fs-fs_old_size * fs-fs_fsize (int32_t) pp-mediasize) test is
probably not sufficient by itself, unless GEOM is modified to ignore
c partitions, that usually start with a valid UFS magic (unless the
partition with offset 0 is a swap partition, of course).
I would prefer telling GEOM to ignore c partitions, and test for
this:
if (fs-fs_old_size * fs-fs_fsize
(int32_t) pp-mediasize) {
g_free(fs);
continue;
}
as that would make geom_vol_ffs continue to work even if you dd(1) an
existing file system from a small to a larger partition/disk, but that
may have other implications I'm not aware of?
--
Per Kristian Hove
Dept. of Mathematical Sciences
Norwegian University of Science and Technology
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] Tweak re-routing of PCI interrupts
I have a small tweak to the PCI code that re-routes PCI interrupts.
Basically, it does two things, 1) make the comment less ia64-specific
and 2) if the interrupt route returns an invalid IRQ (i.e. 255), then
we don't change the intline. In other words, if we can't route the
interrupt, we just assume that the firmware knows more than we do and
go with the value it stuck in the register. 1) is a no-brainer, but
I wonder what people think about 2). Patch below:
Index: pci.c
===
RCS file: /usr/cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.216
diff -u -r1.216 pci.c
--- pci.c 4 Jun 2003 21:10:15 - 1.216
+++ pci.c 6 Jun 2003 18:10:14 -
@@ -782,7 +782,7 @@
pcicfgregs *cfg = dinfo-cfg;
struct resource_list *rl = dinfo-resources;
struct pci_quirk *q;
- int b, i, f, s;
+ int b, i, irq, f, s;
b = cfg-bus;
s = cfg-slot;
@@ -800,14 +800,18 @@
if (cfg-intpin 0 PCI_INTERRUPT_VALID(cfg-intline)) {
#if defined(__ia64__) || (defined(__i386__) !defined(SMP))
/*
-* Re-route interrupts on ia64 so that we can get the
-* I/O SAPIC interrupt numbers (the BIOS leaves legacy
-* PIC interrupt numbers in the intline registers).
+* Try to re-route interrupts. Sometimes the BIOS or
+* firmware may leave bogus values in these registers.
+* If the re-route fails, then just stick with what we
+* have.
*/
- cfg-intline = PCIB_ROUTE_INTERRUPT(pcib, dev, cfg-intpin);
+ irq = PCIB_ROUTE_INTERRUPT(pcib, dev, cfg-intpin);
+ if (PCI_INTERRUPT_VALID(irq))
+ cfg-intline = irq;
+ else
#endif
- resource_list_add(rl, SYS_RES_IRQ, 0, cfg-intline,
- cfg-intline, 1);
+ irq = cfg-intline;
+ resource_list_add(rl, SYS_RES_IRQ, 0, irq, irq, 1);
}
}
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: geom_vol_ffs problems
On Fri, Jun 06, 2003 at 07:38:36PM +0200, Per Kristian Hove wrote: I've nailed it down to this: geom_vol_ffs assumes that a file system is able to fill the partition completely. That's not a valid assumption, since the file system size is a multiple of the file system block size (in my case 16k bytes = 32 blocks), and the partition size is/should be a multiple of the sectors/cylinder count (in my case 1008). Thanks for doing this analysis. I've run into the same thing here at work but I just haven't had any time to debug it. I'll see if I can work something up that'll address this problem. -gordon pgp0.pgp Description: PGP signature
Re: SMBFS automounting broken?
On Wed, Jun 04, 2003 at 06:57:09PM -0400, The Anarcat wrote: Hi! Recently, I noticed that my samba shares were not automounted on boot. What I understand of it is that netfs_types is defined in rc.d/mountcritlocal, but not in rc.d/mountcritremote, which makes the code: You are a little late. I committed a solution to this problem on the 1st. I asked re@ for permission to MFC but that request was denied (understandably from my point of view). -gordon pgp0.pgp Description: PGP signature
Re: [PATCH] Tweak re-routing of PCI interrupts
On Fri, Jun 06, 2003 at 02:13:31PM -0400, John Baldwin wrote: I have a small tweak to the PCI code that re-routes PCI interrupts. Basically, it does two things, 1) make the comment less ia64-specific and 2) if the interrupt route returns an invalid IRQ (i.e. 255), then we don't change the intline. Sounds reasonable. I can test the code. Without the logic the BigSur I have wont boot, so I know immediately if the additional test breaks anything, although I'm pretty sure it wont. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMBFS automounting broken?
On Fri Jun 06, 2003 at 11:23:37AM -0700, Gordon Tetlow wrote: On Wed, Jun 04, 2003 at 06:57:09PM -0400, The Anarcat wrote: Hi! Recently, I noticed that my samba shares were not automounted on boot. What I understand of it is that netfs_types is defined in rc.d/mountcritlocal, but not in rc.d/mountcritremote, which makes the code: You are a little late. I committed a solution to this problem on the 1st. I asked re@ for permission to MFC but that request was denied (understandably from my point of view). Oh, sorry for the noise.. :) A. -- C'est avec les pierres de la loi qu'on a bâti les prisons, et avec les briques de la religion, les bordels. - Blake, William pgp0.pgp Description: PGP signature
Re: [PATCH] Tweak re-routing of PCI interrupts
In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : I have a small tweak to the PCI code that re-routes PCI interrupts. : Basically, it does two things, 1) make the comment less ia64-specific : and 2) if the interrupt route returns an invalid IRQ (i.e. 255), then : we don't change the intline. In other words, if we can't route the : interrupt, we just assume that the firmware knows more than we do and : go with the value it stuck in the register. 1) is a no-brainer, but : I wonder what people think about 2). Patch below: I think #2 isn't so good. #1 is a no-brainer :-) : #if ... ... : + irq = PCIB_ROUTE_INTERRUPT(pcib, dev, cfg-intpin); : + if (PCI_INTERRUPT_VALID(irq)) : + cfg-intline = irq; : + else : #endif : + irq = cfg-intline; : + resource_list_add(rl, SYS_RES_IRQ, 0, irq, irq, 1); : } : } The part I don't like is that if we can't route an interrupt, we assume that the interrupt that was written there before is good and routed. This strikes me as an unwise assumption. Also, we haven't recorded our info in the underlying pci register. Don't know if that will matter for other OSes that are booted after we are. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Tweak re-routing of PCI interrupts
On 06-Jun-2003 M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : I have a small tweak to the PCI code that re-routes PCI interrupts. : Basically, it does two things, 1) make the comment less ia64-specific : and 2) if the interrupt route returns an invalid IRQ (i.e. 255), then : we don't change the intline. In other words, if we can't route the : interrupt, we just assume that the firmware knows more than we do and : go with the value it stuck in the register. 1) is a no-brainer, but : I wonder what people think about 2). Patch below: I think #2 isn't so good. #1 is a no-brainer :-) : #if ... ... : + irq = PCIB_ROUTE_INTERRUPT(pcib, dev, cfg-intpin); : + if (PCI_INTERRUPT_VALID(irq)) : + cfg-intline = irq; : + else : #endif : + irq = cfg-intline; : + resource_list_add(rl, SYS_RES_IRQ, 0, irq, irq, 1); : } : } The part I don't like is that if we can't route an interrupt, we assume that the interrupt that was written there before is good and routed. This strikes me as an unwise assumption. I don't strongly disagree. Hence my request for comments. I've been of both minds on this one and just want to see what the consensus is. Also, we haven't recorded our info in the underlying pci register. Don't know if that will matter for other OSes that are booted after we are. Don't think it matters as far as reboots, but I do think that this code should write the updated intpin to the actual config register. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-06-06 18:49:32 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-06-06 18:49:32 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-06-06 18:51:51 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make -B buildworld
Rebuilding the temporary build tree
stage 1: legacy release compatibility shims
stage 1: bootstrap tools
stage 2: cleaning up the object tree
stage 2: rebuilding the object tree
stage 2: build tools
stage 3: cross tools
stage 4: populating
/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include
stage 4: building libraries
[...]
cc -O -pipe -mcpu=pentiumpro -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -std=gnu99 -c
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/msun/src/w_y1.c -o w_y1.o
cc -O -pipe -mcpu=pentiumpro -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -std=gnu99 -c
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/msun/src/w_y1f.c -o w_y1f.o
cc -O -pipe -mcpu=pentiumpro -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -std=gnu99 -c
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/msun/src/w_yn.c -o w_yn.o
cc -O -pipe -mcpu=pentiumpro -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -std=gnu99 -c
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/msun/src/w_ynf.c -o w_ynf.o
cc -O -pipe -mcpu=pentiumpro -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -std=gnu99 -c
i387_e_acos.S -o i387_e_acos.o
{standard input}: Assembler messages:
{standard input}:19: Error: junk `(__ieee754_acos)' after expression
{standard input}:19: Error: junk `(__ieee754_acos)' after expression
*** Error code 1
Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/msun.
*** Error code 1
Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1
Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1
Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
*** Error code 1
Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src.
TB --- 2003-06-06 19:04:25 - /usr/bin/make returned exit code 1
TB --- 2003-06-06 19:04:25 - ERROR: failed to build world
TB --- 2003-06-06 19:04:25 - tinderbox aborted
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Tweak re-routing of PCI interrupts
On Fri, Jun 06, 2003 at 02:13:31PM -0400, John Baldwin wrote: I have a small tweak to the PCI code that re-routes PCI interrupts. Basically, it does two things, 1) make the comment less ia64-specific and 2) if the interrupt route returns an invalid IRQ (i.e. 255), then we don't change the intline. In other words, if we can't route the interrupt, we just assume that the firmware knows more than we do and go with the value it stuck in the register. 1) is a no-brainer, but I wonder what people think about 2). Patch below: I will test this, as my printserver tried all pci device with irq 255. I already wondered how you could route interrupts without ACPI until I booted my printserver with a recent kernel. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Tweak re-routing of PCI interrupts
On Fri, Jun 06, 2003 at 12:36:54PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : I have a small tweak to the PCI code that re-routes PCI interrupts. : Basically, it does two things, 1) make the comment less ia64-specific : and 2) if the interrupt route returns an invalid IRQ (i.e. 255), then : we don't change the intline. In other words, if we can't route the : interrupt, we just assume that the firmware knows more than we do and : go with the value it stuck in the register. 1) is a no-brainer, but : I wonder what people think about 2). Patch below: I think #2 isn't so good. #1 is a no-brainer :-) : #if ... ... : + irq = PCIB_ROUTE_INTERRUPT(pcib, dev, cfg-intpin); : + if (PCI_INTERRUPT_VALID(irq)) : + cfg-intline = irq; : + else : #endif : + irq = cfg-intline; : + resource_list_add(rl, SYS_RES_IRQ, 0, irq, irq, 1); : } : } The part I don't like is that if we can't route an interrupt, we assume that the interrupt that was written there before is good and routed. This strikes me as an unwise assumption. Also, we haven't Unless you find a reliable way to ask the BIOS how the board is wired, whatelse would you do than trust the inline register? recorded our info in the underlying pci register. Don't know if that will matter for other OSes that are booted after we are. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Tweak re-routing of PCI interrupts
On Fri, Jun 06, 2003 at 03:04:43PM -0400, John Baldwin wrote: On 06-Jun-2003 M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: Also, we haven't recorded our info in the underlying pci register. Don't know if that will matter for other OSes that are booted after we are. Don't think it matters as far as reboots, but I do think that this code should write the updated intpin to the actual config register. I have no clue what alphas would think about this when we use that codepath some day. In some cases the inline registers on alpha seem to be correct but have different numbering than we use within FreeBSD. I rather prefer not to change informations that SRM or PAL might use. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] Tweak re-routing of PCI interrupts
In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : On Fri, Jun 06, 2003 at 12:36:54PM -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : John Baldwin [EMAIL PROTECTED] writes: : : I have a small tweak to the PCI code that re-routes PCI interrupts. : : Basically, it does two things, 1) make the comment less ia64-specific : : and 2) if the interrupt route returns an invalid IRQ (i.e. 255), then : : we don't change the intline. In other words, if we can't route the : : interrupt, we just assume that the firmware knows more than we do and : : go with the value it stuck in the register. 1) is a no-brainer, but : : I wonder what people think about 2). Patch below: : : I think #2 isn't so good. #1 is a no-brainer :-) : : : #if ... : ... : : + irq = PCIB_ROUTE_INTERRUPT(pcib, dev, cfg-intpin); : : + if (PCI_INTERRUPT_VALID(irq)) : : + cfg-intline = irq; : : + else : : #endif : : + irq = cfg-intline; : : + resource_list_add(rl, SYS_RES_IRQ, 0, irq, irq, 1); : : } : : } : : The part I don't like is that if we can't route an interrupt, we : assume that the interrupt that was written there before is good and : routed. This strikes me as an unwise assumption. Also, we haven't : : Unless you find a reliable way to ask the BIOS how the board is wired, : whatelse would you do than trust the inline register? $PIR table does this for PCIBIOS. Other mechanisms do it for ACPI. Pre PCIBIOS machines you are SOL. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
