Re: Keyspan USB serial adapter
On Tue, Sep 16, 2008 at 09:24:26PM -0700, Jeremy Chadwick wrote: Since you're still in the market: I've heard wonderful things about any of the USB serial adapters that use the Prolific chip; see uplcom(4). I can second that. I use a Sitecom CN-104 (also Prolific) with several devices like Sun hardware and Soekris/Wrap systems boards and it al works perfectly (FreeBSD/Linux and Windows). http://www.sitecom.com/product.php?productname=USB+to+serial+cable+%96+60cmproductcode=CN-104productid=31subgroupid=20 -- Regards, Richard. /* Homo Sapiens non urinat in ventum */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unsupported NVIDIA SATA controller
Joseph Olatt wrote: Gavin Atkinson wrote: Out of interest, what motherboard is this on? Is there a way to find out the motherboard details without opening up the box? Yes. Install and run dmidecode from ports/sysutils/dmidecode. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small. -- Ville Vainio ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible UDP related deadlock in 7.1-PRERELEASE
On Mon, 15 Sep 2008, Norbert Papke wrote: With WITNESS enabled, I now experience panics and could not follow your instructions. There is no core dump. The following gets logged to /var/log/messages: shared lock of (rw) udpinp @ /usr/src/sys/netinet/udp_usrreq.c:864 while exclusively locked from /usr/src/sys/netinet6/udp6_usrreq.c:940 panic: share-excl KDB: stack backtrace: db_trace_self_wrapper(c06fda7c,f6b96978,c052046a,c06fbb5d,c07695c0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c06fbb5d,c07695c0,c06febd1,f6b96984,f6b96984,...) at kdb_backtrace+0x29 panic(c06febd1,c070c409,3ac,c0709eee,360,...) at panic+0xaa witness_checkorder(ccd5209c,1,c0709eee,360,8,...) at witness_checkorder+0x17c _rw_rlock(ccd5209c,c0709eee,360,c07780e0,cd4652c8,...) at _rw_rlock+0x2a udp_send(d3942000,0,c580f400,c68faa00,0,...) at udp_send+0x197 udp6_send(d3942000,0,c580f400,c68faa00,0,...) at udp6_send+0x140 sosend_generic(d3942000,c68faa00,f6b96be8,0,0,...) at sosend_generic+0x50d sosend(d3942000,c68faa00,f6b96be8,0,0,...) at sosend+0x3f kern_sendit(cd465230,f,f6b96c64,0,0,...) at kern_sendit+0x106 sendit(0,871b9fe,0,c68faa00,1c,...) at sendit+0x182 sendto(cd465230,f6b96cfc,18,cd465230,c072bab8,...) at sendto+0x4f syscall(f6b96d38) at syscall+0x293 Note that I do not use IPv6, none of my network interfaces is configured for it. Dear Norbert, Thanks for this report -- the additional WITNESS debugging information is very helpful, and the above warning may well be the source of the problem you're experiencing. To clarify what you're seeing a bit: some applications that are adapted to use both IPv4 and IPv6 open combined v4/v6 sockets. This is possible because there is a section of the IPv6 address space that contains the v4 address space. When an application sends to a v4 address using a v6 socket (wave hands here) the kernel actually calls the v4 UDP code from within the v6 socket code, and it turns out there's a locking bug in that path. So likely some application you are running is using this compatibility mode, and hence triggering this bug. I need to think for a bit about the best way to fix it (it's easy to hack around, but obviously hacking around is not the desired solution), and I'll get back to you later this week with a patch. For my reference, it would probably be helpful to know what the application is, since apparently this didn't arise in our testing. You can type show pcpu at the DDB prompt after this panic to show what thread is currently running. Thanks, Robert N M Watson Computer Laboratory University of Cambridge Also, since I enabled WITNESS, I get the following logged during system startup: Enabling pf. lock order reversal: 1st 0xc09af92c pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contri b/pf/net/pf_ioctl.c:1394 2nd 0xc07b4d68 ifnet (ifnet) @ /usr/src/sys/net/if.c:1558 KDB: stack backtrace: db_trace_self_wrapper(c06fda7c,f4914a60,c0552c75,c06fed11,c07b4d68,...) at db_tr ace_self_wrapper+0x26 kdb_backtrace(c06fed11,c07b4d68,c0703ca2,c0703ca2,c0703c73,...) at kdb_backtrace +0x29 witness_checkorder(c07b4d68,9,c0703c73,616,572,...) at witness_checkorder+0x5e5 _mtx_lock_flags(c07b4d68,0,c0703c73,616,c0104414,...) at _mtx_lock_flags+0x34 ifunit(c6ef5c20,0,c09adfb5,572,c0703a71,...) at ifunit+0x2f pfioctl(c566ce00,c0104414,c6ef5c20,3,c60c38c0,...) at pfioctl+0x2b43 devfs_ioctl_f(c588bb94,c0104414,c6ef5c20,c54bb900,c60c38c0,...) at devfs_ioctl_f +0xe6 kern_ioctl(c60c38c0,3,c0104414,c6ef5c20,100,...) at kern_ioctl+0x243 ioctl(c60c38c0,f4914cfc,c,c0718d59,c072b350,...) at ioctl+0x134 syscall(f4914d38) at syscall+0x293 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281ab6f3, esp = 0xbfbfde3c, ebp = 0xbfbfde68 --- pf enabled I tried to unload 'pf' to see if it was the culprit. However, even without pf loaded, I experience the panic. Is there anything else I can try to provide better insight into what might be going on? Cheers, -- Norbert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Supermicro PDSMI failed to boot on fresh RELENG_7/amd64
Colleagues, 3 of 4 times this machine failed to boot, panicing somewhere in late kernel initialization phase (before /sbin/init is executed) I have serial console and KDB enabled, so can do experiments. Last two crashes: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x8:0x8026978a stack pointer = 0x10:0x80611810 frame pointer = 0x10:0x80611830 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at kobj_lookup_method_mi+0xa: movq0x8(%rdi),%rax db bt Tracing pid 0 tid 0 td 0x80544000 kobj_lookup_method_mi() at kobj_lookup_method_mi+0xa kobj_lookup_method() at kobj_lookup_method+0x1f acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0xc1 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_attach() at acpi_attach+0x984 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a nexus_attach() at nexus_attach+0x19 device_attach() at device_attach+0x69 root_bus_configure() at root_bus_configure+0x28 configure() at configure+0xa mi_startup() at mi_startup+0x59 btext() at btext+0x2c Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0x8016f8a1 stack pointer = 0x10:0x80611850 frame pointer = 0x10:0x806118d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at acpi_wake_sysctl_walk+0xa1: cmpq$0x804f8420,(%rax) db bt Tracing pid 0 tid 0 td 0x80544000 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0xa1 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_attach() at acpi_attach+0x984 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a nexus_attach() at nexus_attach+0x19 device_attach() at device_attach+0x69 root_bus_configure() at root_bus_configure+0x28 configure() at configure+0xa mi_startup() at mi_startup+0x59 btext() at btext+0x2c Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI blacklist question
Hello, I have recently updated a machine to 7-stable. ACPI doesn't seem to work correctly on this machine. With earlier versions of FreeBSD (including the latest RELENG_6), I got this line in dmesg: ACPI disabled by blacklist. Contact your BIOS vendor. And everything was fine. The box runs perfectly well with ACPI disabled. (I can't get a BIOS update because the mainboard is too old.) When I updated to RELENG_7 a few days ago, the above line did _not_ appear anymore, and the machine didn't proceed to boot, so I had to travel to the console. :-( After disabling ACPI manually via boot.conf hint, it is up and running fine again. Now i'm wondering: Has the ACPI blacklist been removed intentionally, or is this a regression? Certainly I did not find any mentioning of it in UPDATING or anywhere else. Best regards Oliver PS: This is a Gigabyte GA-6BXD board with two Celeron-466 processors on it. Apart from not wanting ACPI it is rock- solid, and I expect it to be in production for DNS, packet filtering, mail backup and small web server for at least another 10 years. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence -- Jacek Generowicz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.3 reboot -d doesn't work
Hello List, I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 /etc/defaults/rc.conf dumpdir=/var/crash# Directory where crash dumps are to be stored savecore_flags= # Used if dumpdev is enabled above, and present. Z2873# sysctl -a |grep physmem hw.physmem: 259481600 Swap: 1024M Total, 1024M Free Z2873# dumpon -v /dev/ad0s1b kernel dumps on /dev/ad0s1b reboot -d ... dumping 255M 2 chunks Then nothing - the system doesn't reboot and I have to hard reset it. When it comes back up there is no crash file in /var/crash from /var/log/messages: Sep 17 07:28:12 Z2873 kernel: ad0: 28615MB IBM DJSA-230 JS6OAB0A at ata0-master UDMA66 Sep 17 07:28:12 Z2873 kernel: Trying to mount root from ufs:/dev/ad0s1a Sep 17 07:28:12 Z2873 savecore: no dumps found Is this broken? Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
floppy disk controller broken
Hello, when testing FreeBSD-7.1-BETA i discovered that the floppy disk controller doesn't work correctly. Trying to format a floppy (perhaps with bad blocks) i get: Processing fdformat: ioctl(FD_FORM): Device not configured instead of the normal E letter. I then checked the same problem is present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in 2006! Of course the floppy disk driver is particularly messy, but this is not pretty. (*) i386/103862: Error with fdformat -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible UDP related deadlock in 7.1-PRERELEASE
On September 17, 2008, Robert Watson wrote: On Mon, 15 Sep 2008, Norbert Papke wrote: With WITNESS enabled, I now experience panics and could not follow your instructions. There is no core dump. The following gets logged to /var/log/messages: shared lock of (rw) udpinp @ /usr/src/sys/netinet/udp_usrreq.c:864 while exclusively locked from /usr/src/sys/netinet6/udp6_usrreq.c:940 panic: share-excl KDB: stack backtrace: db_trace_self_wrapper(c06fda7c,f6b96978,c052046a,c06fbb5d,c07695c0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c06fbb5d,c07695c0,c06febd1,f6b96984,f6b96984,...) at kdb_backtrace+0x29 panic(c06febd1,c070c409,3ac,c0709eee,360,...) at panic+0xaa witness_checkorder(ccd5209c,1,c0709eee,360,8,...) at witness_checkorder+0x17c _rw_rlock(ccd5209c,c0709eee,360,c07780e0,cd4652c8,...) at _rw_rlock+0x2a udp_send(d3942000,0,c580f400,c68faa00,0,...) at udp_send+0x197 udp6_send(d3942000,0,c580f400,c68faa00,0,...) at udp6_send+0x140 sosend_generic(d3942000,c68faa00,f6b96be8,0,0,...) at sosend_generic+0x50d sosend(d3942000,c68faa00,f6b96be8,0,0,...) at sosend+0x3f kern_sendit(cd465230,f,f6b96c64,0,0,...) at kern_sendit+0x106 sendit(0,871b9fe,0,c68faa00,1c,...) at sendit+0x182 sendto(cd465230,f6b96cfc,18,cd465230,c072bab8,...) at sendto+0x4f syscall(f6b96d38) at syscall+0x293 Note that I do not use IPv6, none of my network interfaces is configured for it. To clarify what you're seeing a bit: some applications that are adapted to use both IPv4 and IPv6 open combined v4/v6 sockets. This is possible because there is a section of the IPv6 address space that contains the v4 address space. When an application sends to a v4 address using a v6 socket (wave hands here) the kernel actually calls the v4 UDP code from within the v6 socket code, and it turns out there's a locking bug in that path. So likely some application you are running is using this compatibility mode, and hence triggering this bug. Thank you for this explanation. It helps my peace of mind to understand the context. I need to think for a bit about the best way to fix it (it's easy to hack around, but obviously hacking around is not the desired solution), and I'll get back to you later this week with a patch. I am certainly happy to try a patch when it becomes available. For my reference, it would probably be helpful to know what the application is, since apparently this didn't arise in our testing. You can type show pcpu at the DDB prompt after this panic to show what thread is currently running. This may be difficult. I was not entirely clear in my description of the panic. I experience spontaneous reboots when the panic is occurs. DDB is not invoked, nor is a core generated. My suspicion is that ktorrent, the KDE3 torrent client, is triggering this condition. When I broke into DDB with a non-WITNESS kernel, I observed that one of the ktorrent threads was locked on *udpinp. Additionally, hald, ntpd and the NIC interrupt thread had *udp locked. Not sure if this is information is helpful. Cheers, -- Norbert. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64
On Wed, 17 Sep 2008, Dmitry Morozovsky wrote: DM Colleagues, DM DM 3 of 4 times this machine failed to boot, panicing somewhere in late kernel DM initialization phase (before /sbin/init is executed) DM DM I have serial console and KDB enabled, so can do experiments. Update: booting GENERIC in single user succeeds, but then after pressing ^D machine stucks running sh very slowly: # ^Dload: 0.56 cmd: sh 57 [runnable] 0.90u 2.72s 18% 1760k load: 0.62 cmd: sh 57 [runnable] 1.41u 5.93s 28% 1760k load: 0.65 cmd: sh 57 [runnable] 1.81u 8.80s 32% 1760k load: 0.99 cmd: ps 61 [runnable] 11.44u 106.73s 36% 1124k load: 0.99 cmd: sh 57 [runnable] 3.63u 24.01s 3% 1760k Loading configuration files. load: 0.99 cmd: sh 57 [runnable] 12.58u 95.10s 37% 1884k (these lines consume 5-10 minutes...) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64
On Wed, Sep 17, 2008 at 03:30:45PM +0400, Dmitry Morozovsky wrote:
Colleagues,
3 of 4 times this machine failed to boot, panicing somewhere in late kernel
initialization phase (before /sbin/init is executed)
{snip}
We have many (specifically, 6) PDSMI+ (not PDSMI) boxes which do not
exhibit this problem.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3 reboot -d doesn't work
On Wed, Sep 17, 2008 at 07:36:46AM -0400, Stephen Clark wrote: I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 /etc/defaults/rc.conf dumpdir=/var/crash# Directory where crash dumps are to be stored savecore_flags= # Used if dumpdev is enabled above, and present. Z2873# sysctl -a |grep physmem hw.physmem: 259481600 Swap: 1024M Total, 1024M Free Z2873# dumpon -v /dev/ad0s1b kernel dumps on /dev/ad0s1b reboot -d ... dumping 255M 2 chunks Then nothing - the system doesn't reboot and I have to hard reset it. When it comes back up there is no crash file in /var/crash from /var/log/messages: Sep 17 07:28:12 Z2873 kernel: ad0: 28615MB IBM DJSA-230 JS6OAB0A at ata0-master UDMA66 Sep 17 07:28:12 Z2873 kernel: Trying to mount root from ufs:/dev/ad0s1a Sep 17 07:28:12 Z2873 savecore: no dumps found Is this broken? It's a known problem. If when the machine reboots, you forcefully enter single-user, you should be able to get the kernel dump using savecore. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3 reboot -d doesn't work
On Wed, Sep 17, 2008 at 09:25:37AM -0700, Jeremy Chadwick wrote: On Wed, Sep 17, 2008 at 07:36:46AM -0400, Stephen Clark wrote: I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 [...] reboot -d ... dumping 255M 2 chunks Then nothing - the system doesn't reboot and I have to hard reset it. When it comes back up there is no crash file in /var/crash [...] It's a known problem. If when the machine reboots, you forcefully enter single-user, you should be able to get the kernel dump using savecore. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 Your PR doesn't look like Stephen's problem to me, since according to his description the system hangs when trying to do the dump so there won't be anything on the disk for savecore to save. - Ed ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: alpm(4) I/O range is claimed by ACPI
On Tuesday 16 September 2008 10:58:54 pm KAHO Toshikazu wrote: Hello, I am sorry to mistake copying message-id and break mail thread. I tried looking for this device in the DSDT, I don't see anything which obviously resembles it. The equivalent Linux driver has a means of forcing the mapping to be set up if it isn't available: http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3 It looks like there used to be a means of doing this in the FreeBSD driver but it got nuked. And that ASUS didn't much care about power management support in this machine... If you can re-enable it in such a way that it uses bus_alloc_resource(), then the driver will probably work fine. How to re-enable it? Please give me some points. PCIR_BAR is always 0, even if any values are written by pciconf. Well, bus_alloc_resource() will allocate resources for the BAR and update the BAR for you, the question is if you need to hardcode the range to bus_alloc_resource() or not. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI blacklist question
On Wednesday 17 September 2008 07:47:18 am Oliver Fromme wrote:
Hello,
I have recently updated a machine to 7-stable.
ACPI doesn't seem to work correctly on this machine.
With earlier versions of FreeBSD (including the latest
RELENG_6), I got this line in dmesg:
ACPI disabled by blacklist. Contact your BIOS vendor.
And everything was fine. The box runs perfectly well
with ACPI disabled. (I can't get a BIOS update because
the mainboard is too old.)
When I updated to RELENG_7 a few days ago, the above line
did _not_ appear anymore, and the machine didn't proceed
to boot, so I had to travel to the console. :-(
After disabling ACPI manually via boot.conf hint, it is
up and running fine again.
Now i'm wondering: Has the ACPI blacklist been removed
intentionally, or is this a regression? Certainly I did
not find any mentioning of it in UPDATING or anywhere
else.
This is a regression. Try this fix:
Index: acpi_quirk.c
===
--- acpi_quirk.c(revision 183112)
+++ acpi_quirk.c(working copy)
@@ -149,9 +149,9 @@
if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_FADT, 0, fadt)))
bzero(fadt, sizeof(fadt));
if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_DSDT, 0, dsdt)))
- bzero(fadt, sizeof(dsdt));
+ bzero(dsdt, sizeof(dsdt));
if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_XSDT, 0, xsdt)))
- bzero(fadt, sizeof(xsdt));
+ bzero(xsdt, sizeof(xsdt));
/* Then, override the quirks with any matched from table signatures. */
for (entry = acpi_quirks_table; entry-match; entry++) {
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI blacklist question
John Baldwin wrote:
Oliver Fromme wrote:
[...]
Now i'm wondering: Has the ACPI blacklist been removed
intentionally, or is this a regression? Certainly I did
not find any mentioning of it in UPDATING or anywhere
else.
This is a regression. Try this fix:
Index: acpi_quirk.c
===
--- acpi_quirk.c (revision 183112)
+++ acpi_quirk.c (working copy)
@@ -149,9 +149,9 @@
if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_FADT, 0, fadt)))
bzero(fadt, sizeof(fadt));
if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_DSDT, 0, dsdt)))
-bzero(fadt, sizeof(dsdt));
+bzero(dsdt, sizeof(dsdt));
if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_XSDT, 0, xsdt)))
-bzero(fadt, sizeof(xsdt));
+bzero(xsdt, sizeof(xsdt));
/* Then, override the quirks with any matched from table signatures. */
for (entry = acpi_quirks_table; entry-match; entry++) {
Thanks for the quick reply. I will try this on Friday
when I'm near the console. I'm a little reluctant to
try it remotely.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
The ITU has offered the IETF formal alignment with its
corresponding technology, Penguins, but that won't fly.
-- RFC 2549
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyspan USB serial adapter
| By Richard Arends [EMAIL PROTECTED] | [ 2008-09-17 07:05 +0200 ] On Tue, Sep 16, 2008 at 09:24:26PM -0700, Jeremy Chadwick wrote: Since you're still in the market: I've heard wonderful things about any of the USB serial adapters that use the Prolific chip; see uplcom(4). I can second that. I use a Sitecom CN-104 (also Prolific) with several devices like Sun hardware and Soekris/Wrap systems boards and it al works perfectly (FreeBSD/Linux and Windows). Thanks. I decided to not take a chance and ordered a Prolific based Iogear adapter. :) Thanks, Aragon (who wishes laptops still had com ports) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3 reboot -d doesn't work
On Wed, Sep 17, 2008 at 01:03:46PM -0400, Ed Maste wrote: On Wed, Sep 17, 2008 at 09:25:37AM -0700, Jeremy Chadwick wrote: On Wed, Sep 17, 2008 at 07:36:46AM -0400, Stephen Clark wrote: I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 [...] reboot -d ... dumping 255M 2 chunks Then nothing - the system doesn't reboot and I have to hard reset it. When it comes back up there is no crash file in /var/crash [...] It's a known problem. If when the machine reboots, you forcefully enter single-user, you should be able to get the kernel dump using savecore. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 Your PR doesn't look like Stephen's problem to me, since according to his description the system hangs when trying to do the dump so there won't be anything on the disk for savecore to save. You're right, thanks Ed. His when it comes back up there is no crash file is what threw me for a loop. Stephen, does the problem *only* happen when using the -d flag, or does the system lock up on reboot in general? If the latter, try using one or both of the following sysctls: hw.acpi.handle_reboot=1 hw.acpi.disable_on_reboot=1 If the lesser, I've no idea. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
dtrace: processing aborted: Abort due to systemic unresponsiveness (dtrace_gethrtime()?) - and kgdb
Hi! I got curious in dtrace, and after mr's sys/amd64/amd64/trap.c commit (r183050, thanx! :) I was able to build a kernel that could kldload dtraceall on 7-stable amd64, but trying even simple things like dtrace -n tick-1sec only runs for a short time, or not at all, ending with $subject: # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m CPU IDFUNCTION:NAME 1 32125 :tick-1sec dtrace: processing aborted: Abort due to systemic unresponsiveness # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m dtrace: processing aborted: Abort due to systemic unresponsiveness # Looking around on the net I find that this is probably related to dtrace_gethrtime() (this box is SMP), which I see defined in sys/amd64/amd64/tsc.c, but also in sys/cddl/dev/dtrace/amd64/dtrace_subr.c, and in sys/cddl/dev/dtrace/i386/dtrace_subr.c, but nowhere under sys/i386. The versions in sys/cddl/dev/dtrace take cpu-dependent tsc offsets into account which the one in sys/amd64/amd64/tsc.c doesn't, is there any particular reason this version is used? Also I don't see it in HEAD... Wondering, Juergen PS: I also found out that kgdb doesn't seem to like dtrace bits in the kernel, backtraces look like from a kernel without debug symbols, even if I don't use dtrace or even kldload it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy disk controller broken
On Wednesday 17 September 2008 11:04:33 am Michel Talon wrote: Hello, when testing FreeBSD-7.1-BETA i discovered that the floppy disk controller doesn't work correctly. Trying to format a floppy (perhaps with bad blocks) i get: Processing fdformat: ioctl(FD_FORM): Device not configured instead of the normal E letter. I then checked the same problem is present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in 2006! Of course the floppy disk driver is particularly messy, but this is not pretty. (*) i386/103862: Error with fdformat It looks like the ioctl to format a track used to never report failures from the controller. The newer driver does. What I've done with fdformat is to make it just ignore the errors in userland instead. Try this: Index: fdformat.c === --- fdformat.c (revision 183112) +++ fdformat.c (working copy) @@ -75,8 +75,7 @@ f.fd_formb_secno(i) = il[i+1]; f.fd_formb_secsize(i) = secsize; } - if(ioctl(fd, FD_FORM, (caddr_t)f) 0) - err(EX_OSERR, ioctl(FD_FORM)); + (void)ioctl(fd, FD_FORM, (caddr_t)f); } static int -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote: I think FreeBSD is getting in a difficult position now because there's so much cool new stuff being shoe-horned in, but without the necessary volume of contributors to back it up with testing and bug fixes. On Sep 15, 2008, at 11:56 PM, Mark Linimon wrote: We're interested in suggestions about how to get more people involved with testing and bug fixes. There's certainly no lack of demand for the features -- all the way from running on inexpensive wireless routers all the way up to 'enterprise- grade' distributed storage solutions. (These are real examples from various mailing lists.) So, in your opinion, what's the way to reconcile all these demands (features + stability + long-term support of release branches) with a group that is 95%-plus volunteer effort? As I have said to you directly in personal e-mail, the maintenance schedule is creating a chicken and egg problem. If companies weren't forced to run internal distribution and release management on their own, they could allocate more resources (ie volunteers -- PAID ones!) to testing and release management of the main distribution. To speak personally from my own experience: our business can not afford to pay me to help develop a release effort with an unknown maintenance period (6.4-REL). Since we need to have a clear maintenance window for any installed/upgraded host, we are forced to provide that support internally. If we had known (and longer than 12 month) maintenance periods for a given release, then I could avoid maintaining this infrastructure internally and would have somewhere in the neighborhood of 20 hours a month I could dedicate to testing and bug fixes of FreeBSD as a whole. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 16, 2008, at 12:38 AM, Matthew Seaman wrote: On 'long term support of release branches' -- a volunteer project is always going to struggle to provide this without some form of income to support the necessary hardware and personnel resources needed. Or in other words, if FreeBSD users want the same sort of support structure as they can get from a commercial vendor, it's going to take a commercial vendor to supply it. FreeBSD Corporation anyone? I disagree. The entire advantage of open source is the advantage provided by shared interest in a working product. Each party can put in a little and the product is improved for everyone. If we remove the factors that hamstring companies from providing more resources to assist, then you can get more resources working on the problem - to everyone's benefit. I'm not kidding when I say that nearly everyone I know who uses FreeBSD in their company spends a lot of time managing their internal distribution. (And every reply to this topic on this mailing list has echoed the exact same statement.) None of the ones I know personally have any interest in doing this, and would be happier focusing their effort on the mainstream release. A bunch of us made proposals to our $EMPLOYERs to make this happen, but there was no apparent interest from the release team so the effort was abandoned. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Mon, 15 Sep 2008, Jo Rhett wrote: Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an appropriately supported release when the decision for the support cycle is completely up in the air? On Sep 16, 2008, at 12:47 PM, Robert Watson wrote: The FreeBSD Project, as with any other company or organization, responds to events as they occur. We try to plan ahead, and when things go better or worse than expected, we sometimes change the plans. As far as I know we've never *shortened* the expected support timeline for any branch or release, but we have on occasion lenthened them when we feel it's important to do so. I'm not sure what other answer is possible. No other answer. But nobody has yet provided what the EoL period is going to be. I have no problems with a period being extended ;-) But the business needs to know the minimum EoL for a given release to determine if upgrading to that release is viable. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Wed, 17 Sep 2008, Jo Rhett wrote: On Mon, 15 Sep 2008, Jo Rhett wrote: Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an appropriately supported release when the decision for the support cycle is completely up in the air? On Sep 16, 2008, at 12:47 PM, Robert Watson wrote: The FreeBSD Project, as with any other company or organization, responds to events as they occur. We try to plan ahead, and when things go better or worse than expected, we sometimes change the plans. As far as I know we've never *shortened* the expected support timeline for any branch or release, but we have on occasion lenthened them when we feel it's important to do so. I'm not sure what other answer is possible. No other answer. But nobody has yet provided what the EoL period is going to be. I have no problems with a period being extended ;-) But the business needs to know the minimum EoL for a given release to determine if upgrading to that release is viable. Well, a starting answer is the policy found on http://security.FreeBSD.org/: Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. At the time of release, we know if a release is considered early adopter, and attempt to clearly mark it as such. The harder question is whether or not we will start out considering a release normal or extended -- sometimes we are able to make that decision at the time of the release (i.e., we believe firmly it's the last release on the branch at the time of release), but on the whole we will make that decision based on the facts on the ground. An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently, and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: alpm(4) I/O range is claimed by ACPI
Hello, Well, bus_alloc_resource() will allocate resources for the BAR and update the BAR for you, the question is if you need to hardcode the range to bus_alloc_resource() or not. It is necessary for a pci device to set the BAR, if the device would use memory or I/O space, isn't it? I don't know why the BAR is not settable, but I think it is disabled by some reasons and the BAR may be settable if the device could be enabled. If the device have default I/O space, it needs to hardcode the range or isa attach code. The device dose not seem to have default I/O space. This problem is not so important for myself, but it is a good if it was solved. -- KAHO Toshikazu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently I understand what you mean, but the statement is blatantly false as stated. Anyone selling software to the US Government *must* specify (or meet, depending) a minimum support period, and must also specify a cost the agency can pay to extend the support period. Not relevant to FreeBSD -- just qualifying the statement as it stands. For the obvious comparison, Solaris versions have well- published release and support periods, usually upwards of 8 years. Obviously they have more resources to do this, I'm just pointing out that the statement you made is incorrect as stated. and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. I am amazed at the preposterously large elephant in the room that none of you are willing to address. Watching each of you dance around it would be terribly funny if it didn't affect my job so badly. (and if I wasn't going to have to bail on FreeBSD and go to some crap form of Linux because the FreeBSD developers appear to be unwilling to consider the idea of getting more help) Your limitation is resources, right? You've calculated what you can support based on the resources you have, right? We are talking about ways to increase the resources available to you... right? So the math on which the conclusions are reached then changes. So lets figure out... what do the basis numbers need to be to change the support period? Obviously this is a bit of hand waving. These numbers are unlikely to be empirical. But try. Examine the concept of having increased resources. What do you need. How do you need it, to make a real change? Please stop avoiding even considering what people are offering to you. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming Releases Schedule...
Another thing that I believe would help: Voting on PRs. Currently a maintainer has no idea if a PR is due to one guy's flakey hardware or if 50 people have had the same problem and are waiting for a fix. For each major problem report, there are probably many people who tried FreeBSD on particular hardware and just silently gave up when it failed. Ability to vote up on a PR on the freebsd website would give maintainers a tool to see which PRs are affecting the userbase. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
