Re: panic with CF drive + USB reader
Bernd, . Seems that handling the stalled condition failed. Can you try the following patch: I was *just* going to write you saying it was still running with this patch, which would have been the longest yet. But then I saw these messages: umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed initiate_write_filepage: already started initiate_write_filepage: already started initiate_write_filepage: already started umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed initiate_write_filepage: already started And the box paniced again: panic: initiate_write_inodeblock_ufs2: already started cpuid = 0; lapic.id = Stack backtrace: backtrace(c033157d,0,c0341a7f,e96a1ab0,100) at backtrace+0x17 panic(c0341a7f,c01bc427,c7dabdf4,e96a1ad0,e96a1ad0) at panic+0x13d initiate_write_inodeblock_ufs2(c6f4cb00,d29060b8,c01fd879,0,d29060b8) at initiate_write_inodeblock_ufs2+0x68f softdep_disk_io_initiation(d29060b8,c17fbf30,e96a1bb4,c01fda2b,d29060b8) at softdep_disk_io_initiation+0x80 spec_xstrategy(c6d88490,d29060b8,e96a1bb4,c017dfcc,e96a1be0) at spec_xstrategy+0x104 spec_specstrategy(e96a1be0,e96a1bfc,c01f8550,e96a1be0,1) at spec_specstrategy+0x1b spec_vnoperate(e96a1be0,1,c6bfc800,d2a5f680,e96a1bdc) at spec_vnoperate+0x18 bwrite(d29060b8,100,c63304c0,e96a1c3c,80012) at bwrite+0x403 vfs_bio_awrite(d29060b8,80012,0,c63304c0,c017dfcc) at vfs_bio_awrite+0x27b vop_stdfsync(e96a1cdc,0,c6d88490,e96a1ca4,c017dfcc) at vop_stdfsync+0x1b1 spec_fsync(e96a1cdc,e96a1d18,c020b613,e96a1cdc,20002) at spec_fsync+0x31 spec_vnoperate(e96a1cdc,20002,c63304c0,c0335c1b,0) at spec_vnoperate+0x18 sched_sync(0,e96a1d48,0,0,0) at sched_sync+0x1e3 fork_exit(c020b430,0,e96a1d48) at fork_exit+0xb2 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe96a1d7c, ebp = 0 --- Debugger(panic) Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0 It seems that this happens under light or no load only. I had been doing a heavy cycle of dump/restore/dd, etc, and all was well. Could it be that the MicroDrive does some kind of internal power management that delays its reponses some, and the kernel doesn't expect that? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic with CF drive + USB reader
On Mon, Aug 25, 2003 at 04:22:57PM -0700, Lars Eggert wrote: It seems that this happens under light or no load only. I had been doing a heavy cycle of dump/restore/dd, etc, and all was well. Could it be that the MicroDrive does some kind of internal power management that delays its reponses some, and the kernel doesn't expect that? Yes microdrives stop spinning when idle for a while to save energy for batterie powered devices and possibly to decrease wear. That could explain on how to trigger this problem. Handling should have been done transparently by your reader. Is your reader declared to support microdrives? -- 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: Please test: USB floppies
On Monday 25 August 2003 23:19, Nate Lawson wrote: If anyone has a USB floppy drive that is giving them problems, please let me know. Hello, this one needs NO_SYNC I think. Played a bit some time ago but had no luck (I'm no programmer) port 1 addr 2: full speed, power 500 mA, config 1, NEC USB UF000x(0x0040), NEC(0x0409), rev 1.23 ___ Here's some log: umass0: NEC NEC USB UF000x, rev 1.10/1.23, addr 2 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 (probe0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 target 0 lun 0 da0: NEC USB UF000x 1.23 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 and more log: (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 umass0: Unsupported UFI command 0x35 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x6, scsi status == 0x0 Thanks, Thank you, -Harry Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] pgp0.pgp Description: signature
Re: nge (Dlink 500-T [Gigabit Driver]) Failure on 5.1
In message: [EMAIL PROTECTED] Nick H. - Network Operations [EMAIL PROTECTED] writes: : That occurs when I do a kldload if_nge.ko Try again. I've seen exactly this on some cardbus cards whose drivers are dynamically loaded via devd on card insertion. Sometimes I need to detach/attach the device to be able to get the memory. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/sys soundcard.h vs. gkrellmvolume2
On Monday 25 August 2003 09:27 pm, Craig Boston wrote:
Anyway, I'm attaching a quick workaround if anyone else running current
runs in to this.
Earth to brain, come in please! Actually attaching the patch this time.
--- unix_mixer.c.orig Mon Aug 25 21:10:46 2003
+++ unix_mixer.cMon Aug 25 21:15:03 2003
@@ -36,6 +36,10 @@
#include mixer.h
#include common_mixer.h
+#ifdef SOUND_MIXER_INFO
+#undef SOUND_MIXER_INFO
+#endif
+
/* tries to open a mixer device, returns NULL on error or otherwise an mixer_t
* struct */
mixer_t *mixer_open(char *id) {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Mon, Aug 25, 2003 at 19:25:42 +0200, Thomas Quinot wrote: Le 2003-08-25, Matt ?crivait : db trace free_hcb(c40f1040,c03c7e40,101,c41d5800,c1528130) at free_hcb+0x2e atapi_action(c40f1440,c41d5800,c0132b33,c41db000,c41d5800) at atapi_action+ox56c OK, so that presumably means we're going through action_oom, and so you should have had one of the following messages on the console: printf(cannot allocate ATAPI/CAM hcb\n); printf(cannot allocate ATAPI/CAM request\n); printf(cannot allocate ATAPI/CAM buffer\n); It would be interesting to know which, if any, of these messages you saw. Also, please try whether the following patch improves the situation: I had the following panic (-current from today (Monday), in free_hcb()), and didn't see either of those messages: Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% acd0: DVDR SONY DVD RW DRU-500A at ata0-master UDMA33 Waiting 2 seconds for SCSI devices to settle Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc019106e stack pointer = 0x10:0xe5e83a24 frame pointer = 0x10:0xe5e83a30 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 = 19 (swi3: cambio) kernel: type 12 trap, code=0 Stopped at free_hcb+0x2e: movl%eax,0(%edx) db trace free_hcb(cbd59000,c0407fe0,101,cb9d1c00,c048f880) at free_hcb+0x2e atapi_action(cb9a2740,cb9d1c00,cb97ac18,cb97ac00,cb99cc30) at atapi_action+0xb53 xpt_run_dev_sendq(cb9a27c0,cb97ac18,5,c083ad14,c042c164) at xpt_run_dev_sendq+0x1fe xpt_action(cb9d1c00,4,c013b720,20,cbd50600) at xpt_action+0x38c probestart(cbd4ea80,cb9d1c00,5,c0138cb6,cb951780) at probestart+0x32f xpt_run_dev_allocq(cb9a27c0,cb97ac08,5) at xpt_run_dev_allocq+0x1ca xpt_schedule(cbd4ea80,5,c47aec14,c47af260,c0487720) at xpt_schedule+0x2ae probedone(cbd4ea80,cb9d1c00,c03dfd02,0,c046f6ac) at probedone+0x55c camisr(c046f6ac,0,c03dfcf9,215,c47aeb58) at camisr+0x2a3 ithread_loop(c47a5800,e5e83d48,c03dfb67,314,e77fffbf) at ithread_loop+0x182 fork_exit(c023b360,c47a5800,e5e83d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe5e83d7c, ebp = 0 --- Index: atapi-cam.c === RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.20 diff -u -r1.20 atapi-cam.c --- atapi-cam.c 24 Aug 2003 17:48:05 - 1.20 +++ atapi-cam.c 25 Aug 2003 17:24:44 - @@ -59,7 +59,7 @@ int lun; union ccb*ccb; int flags; -#define DOING_AUTOSENSE 1 +#define QUEUED 0x0001; I had to remove the semicolon at the end of the line above in order for things to compile. Now with the patch, the probe hangs here: acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% acd0: DVDR SONY DVD RW DRU-500A at ata0-master UDMA33 Waiting 2 seconds for SCSI devices to settle (probe0:ata0:0:0:0): out of memory, freezing queue. Breaking into the debugger doesn't show anything useful: db trace siointr1(c4788800,0,c03f4d5d,695,e5e39ce8) at siointr1+0xd5 siointr(c4788800) at siointr+0x35 Xfastintr4() at Xfastintr4+0xba --- interrupt, eip = 0xc03980e4, esp = 0xe5e39ce8, ebp = 0xe5e39ce8 --- cpu_idle(c0483b40,2,c03dfcf2,5f,1be) at cpu_idle+0x24 idle_proc(0,e5e39d48,c03dfba7,314,bb14d6e) at idle_proc+0x3c fork_exit(c023a7a0,0,e5e39d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe5e39d7c, ebp = 0 --- Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic, then trashed IDE drive - from kernel dump?
The last known good state of my system was a world and kernel from Sunday, Aug 24 at approx 12:00 EDT. This problem is from a kernel built from sources current as of Aug 26th at approx 22:00 EDT Here's the sequence - I booted the system, had a panic while running sysctl from etc/rc.d/devd. It completed a core dump, and rebooted. (Good, I thought, this time I'll have a dump for a backtrace). The system rebooted and found no bootable disks. I had to repartition the disk and restore from backup. I suspect the dump scribbled all over the drive... This is repeatable, and I found out, I have good backups :) Anything I can do to help, please let me know. I'll try to get some sort of a backtrace, but I think doing it from a core dump will be futile... Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic, then trashed IDE drive - from kernel dump?
Just a follow up to this - cannot get it to panic with DDB compiled in. hmmm... On Mon, 25 Aug 2003, Bryan Liesner wrote: The last known good state of my system was a world and kernel from Sunday, Aug 24 at approx 12:00 EDT. This problem is from a kernel built from sources current as of Aug 26th at approx 22:00 EDT Here's the sequence - I booted the system, had a panic while running sysctl from etc/rc.d/devd. It completed a core dump, and rebooted. (Good, I thought, this time I'll have a dump for a backtrace). The system rebooted and found no bootable disks. I had to repartition the disk and restore from backup. I suspect the dump scribbled all over the drive... This is repeatable, and I found out, I have good backups :) Anything I can do to help, please let me know. I'll try to get some sort of a backtrace, but I think doing it from a core dump will be futile... Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- = = Bryan D. LiesnerLeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED] Home of the Gipper= = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: blockable sleep lock (sleep mutex) UMA pcpu @vm/uma_core.c:1381
It looks like the Nvidia driver is attempting to allocate memory while holding a spinlock. Either that or we're explicitly in a critical section when it calls the UMA memory allocation routine (or malloc in this case). That's most likely a problem in the Nvidia driver (judging solely from your backtrace) and so I would advise you to contact its maintainer. -Bosko On Sat, Aug 23, 2003 at 07:00:47PM -0400, [EMAIL PROTECTED] wrote: Hi I am running FreeBSD 5.1-CURRENT #4: Sat Aug 23 18:14:15 AST 2003. I have been trying to use the NVidia driver from the /usr/ports/x11/nvidia-driver but it causes random panics like this. The full backtrace is at http://196.12.160.4/~iceadmin/btfull If you need more information ask please. (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc031b04c in boot (howto=260) at ../../../kern/kern_shutdown.c:372 #2 0xc031b3d7 in panic () at ../../../kern/kern_shutdown.c:550 #3 0xc0322f65 in mi_switch () at ../../../kern/kern_synch.c:473 #4 0xc032285a in msleep (ident=0xc060e578, mtx=0xc060e580, priority=68, wmesg=0xc052bcab wdrain, timo=0) at ../../../kern/kern_synch.c:255 #5 0xc0361fd2 in bwrite (bp=0xc7a5ec08) at ../../../kern/vfs_bio.c:363 #6 0xc0363d81 in vfs_bio_awrite (bp=0xc7a5ec08) at ../../../kern/vfs_bio.c:1709 #7 0xc036b647 in vop_stdfsync (ap=0xcd849944) at ../../../kern/vfs_default.c:737 #8 0xc02e0c00 in spec_fsync (ap=0xcd849944) at ../../../fs/specfs/spec_vnops.c:417 #9 0xc02dfed8 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:122 #10 0xc0455047 in ffs_sync (mp=0xc2b5ea00, waitfor=2, cred=0xc12b8e80, td=0xc05e2120) at vnode_if.h:627 #11 0xc037795b in sync (td=0xc05e2120, uap=0x0) at ../../../kern/vfs_syscalls.c:142 #12 0xc031aba0 in boot (howto=256) at ../../../kern/kern_shutdown.c:281 #13 0xc031b3d7 in panic () at ../../../kern/kern_shutdown.c:550 #14 0xc033fff0 in witness_lock (lock=0xc061b820, flags=8, file=0xc053cdcf vm/uma_core.c, line=1381) ---Type return to continue, or q return to quit--- at ../../../kern/subr_witness.c:610 #15 0xc031144a in _mtx_lock_flags (m=0xc12cd130, opts=0, file=0xc0579fec \t?S?\t, line=-1067337696) at ../../../kern/kern_mutex.c:336 #16 0xc047dd96 in uma_zalloc_arg (zone=0xc061b820, udata=0x0, flags=257) at ../../../vm/uma_core.c:1381 #17 0xc030f8b3 in malloc (size=3234049760, type=0xc089b300, flags=257) at ../../../vm/uma.h:229 #18 0xc086ae87 in os_alloc_mem () from /boot/kernel/nvidia.ko #19 0xc074a7fc in __nvsym00027 () from /boot/kernel/nvidia.ko #20 0xc08551d9 in __nvsym04619 () from /boot/kernel/nvidia.ko #21 0xc0855025 in __nvsym00709 () from /boot/kernel/nvidia.ko #22 0xc07da74f in __nvsym03562 () from /boot/kernel/nvidia.ko #23 0xc07d9731 in __nvsym03559 () from /boot/kernel/nvidia.ko #24 0xc081af2a in __nvsym00646 () from /boot/kernel/nvidia.ko #25 0xc074cbf7 in __nvsym00752 () from /boot/kernel/nvidia.ko #26 0xc074d929 in rm_isr_bh () from /boot/kernel/nvidia.ko #27 0xc086c418 in nvidia_intr () from /boot/kernel/nvidia.ko #28 0xc03075b2 in ithread_loop (arg=0xc29fa080) at ../../../kern/kern_intr.c:534 #29 0xc03065bf in fork_exit (callout=0xc0307430 ithread_loop, arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:796 Abel Alejandro. - This mail sent through IMP: http://horde.org/imp/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3C940 / Asus P4P800 gigabit LAN driver
On Mon, Aug 25, 2003 at 11:20:23AM -0500, Glenn Johnson wrote: On Mon, Aug 25, 2003 at 11:14:25AM +0100, Stuart Walsh wrote: On Sun Aug 24, 10:42P -0500, Glenn Johnson wrote: On Sun, Aug 24, 2003 at 01:22:39PM +0200, Wilko Bulte wrote: On Sat, Aug 23, 2003 at 04:45:30PM +0100, Stuart Walsh wrote: Hi, I ported the openbsd additions to the sk driver to support the 3c940 gigabit network card which is commonly found in the above asus motherboard. Testers/comments/commits welcome, but please don't blame me if it burns your house down or something :) Hi Stuart, I tried this patch instead of the earlier ones you pointed me to on IRC. Unfortunately my Asus P4P800 still locks up solid (reset button required) after printing the 3c940's ethernet address. I'm interested to know if other P4P800 owners have the same issue. I have an Abit IS7 with a 3c940. I also get a lockup at boot time. I tried loading the module after bootup as well. I tried that two times; it loaded one time and locked the machine up the other time. Does it lock up after printing the ethernet address as in Wilko's case? Yes. Does the card work properly if the module does manage to load? I do not know. I did not have a cable plugged in to the 3c940 port at the time. I do remember some message about not being able to set up a jumbo frame. I was going to plug a cable into the port to see if it worked but I was not able to get the module to load again without locking up the machine. Also could you mail your dmesg. Yes, but not until I get home later this evening as the 3c940 is on my home system. Here is my dmesg output: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #94: Mon Aug 25 22:43:06 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GFORCE Preloaded elf kernel /boot/kernel/kernel at 0xc0433000. Preloaded elf module /boot/kernel/if_xl.ko at 0xc04331f4. Preloaded elf module /boot/kernel/miibus.ko at 0xc04332a0. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc043334c. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04333f8. Preloaded elf module /boot/kernel/random.ko at 0xc04334a4. Preloaded elf module /boot/kernel/acpi.ko at 0xc0433550. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2405.47-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 536805376 (511 MB) avail memory = 516743168 (492 MB) Changing APIC ID for IO APIC #0 from 0 to 2 on chip Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: IntelR AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00fdd30 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 16 - irq 2 IOAPIC #0 intpin 19 - irq 5 IOAPIC #0 intpin 18 - irq 9 IOAPIC #0 intpin 23 - irq 10 IOAPIC #0 intpin 17 - irq 11 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB at device 29.2 (no driver attached) pci0: serial bus, USB at device 29.3 (no driver attached) pci0: serial bus, USB at device 29.7 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 pci2: network, ethernet at device 2.0 (no driver attached) xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xa400-0xa47f mem 0xfb004000-0xfb00407f irq 11 at device 9.0 on pci2 xl0: Ethernet address: 00:01:02:84:81:50 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 SATA150 controller port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 irq 9 at device 31.2 on pci0 ata0: at 0x1f0 irq 14 on atapci0
Re: 64 bit quantities in statfs ?
On Mon, Aug 25, 2003, Garrett Wollman wrote: On Sun, 24 Aug 2003 16:04:40 -0700, David Schultz [EMAIL PROTECTED] said: Yep, looks broken. In the POSIX standard, the functionality of statfs() is provided by statvfs(), so implementing the latter may be a way out that doesn't involve breaking any ABIs. statfs() is a lot more useful interface than statvfs(). I'd like to keep statvfs() as the ``standard'' interface, rather than extending it to cover all of the information that statfs() has. In order to grow statfs() we need to rev libc. It might be appropriate to do that in the 5.2 time frame, if we are still anticipating that 5.2 will be the -stable crossover point. RE team? We can't fix statfs() until 6.0. statvfs() is potentially just as useful, and it doesn't suffer from the same problems. Despite being underspecified by the standard, many systems, e.g. Solaris, make it convey at least as much information as statfs(). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi-da does not work with INVARIANTS (fwd)
On Mon, Aug 25, 2003 at 18:29:49 -0600, Kenneth D. Merry wrote:
On Mon, Aug 25, 2003 at 13:49:30 -0700, Nate Lawson wrote:
Ken is aware of the following problem. It is in both cd(4) and da(4) as
well as stable and current. One possible approach would be to run
{da,cd}register() from a task queue and not at interrupt time.
That would be tricky, since the peripheral registration process currently
expects a success/failure return from the peripheral constructor.
Just putting the sysctl creation in a task queue, though, would not be too
difficult.
One question I have, though, is whether task queues run in a thread context
or not. If not, then we'll have the same problem.
The answer is -- the currently defined task queues use software
interrupts.
If it is possible to create a task queue that uses a kernel thread instead,
that might be a generally useful thing. (And it might solve this
particular issue.)
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi-da does not work with INVARIANTS (fwd)
In message: [EMAIL PROTECTED] Kenneth D. Merry [EMAIL PROTECTED] writes: : If it is possible to create a task queue that uses a kernel thread instead, : that might be a generally useful thing. (And it might solve this : particular issue.) I'm not sure that a taskqueue can do this, but NEWCARD uses a kernel thread to process pccard events and attach/detach devices for all the reasons that have been outlined in the rest of this thread. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success (fwd)
eh? i silently assumed that it already was commited! i used bluetooth
on my T30 on -current which is maybe three weeks old and it works!
and to make this very clear, it did NOT work on a -current from around
the time when i sent that email below. the patch fixed it back then,
nothing else did.
so, now i am confused...
On Mon, Aug 25, 2003 at 01:24:20PM -0700, Lee Damon wrote:
Does anyone have an estimate of when this patch will be checked in?
Please?
thanks,
nomad
--- Forwarded Messages
Date: Mon, 16 Jun 2003 23:37:38 +0200
From: Tobias Roth [EMAIL PROTECTED]
To: Lee Damon [EMAIL PROTECTED]
Subject: Re: IBM T30 bluetooth - success
Message-ID: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Mon, Jun 16, 2003 at 02:22:02PM -0700, Lee Damon wrote:
What did you do?
in short, whining to some people about usb being broken until
someone (Bernd Walter) came up with a patch :-)
Other than that, I just followed Pavs tutorials at
http://www.oook.cz/bsd
good luck, t.
--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=usb_working.diff
Index: usb_subr.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.54
diff -u -r1.54 usb_subr.c
--- usb_subr.c14 Jan 2003 23:07:43 - 1.54
+++ usb_subr.c14 Jun 2003 16:01:38 -
@@ -964,6 +964,7 @@
usbd_device_handle dev;
struct usbd_device *hub;
usb_device_descriptor_t *dd;
+ usb_port_status_t ps;
usbd_status err;
int addr;
int i;
@@ -1020,12 +1021,14 @@
up-device = dev;
dd = dev-ddesc;
/* Try a few times in case the device is slow (i.e. outside specs.) */
- for (i = 0; i 3; i++) {
+ for (i = 0; i 15; i++) {
/* Get the first 8 bytes of the device descriptor. */
err = usbd_get_desc(dev, UDESC_DEVICE, 0, USB_MAX_IPACKET, dd);
if (!err)
break;
usbd_delay_ms(dev, 200);
+ if ((i 3) == 3)
+ usbd_reset_port(up-parent, port, ps);
}
if (err) {
DPRINTFN(-1, (usbd_new_device: addr=%d, getting first desc
--PNTmBPCT7hxwcZjr--
--- Message 2
Date: Tue, 17 Jun 2003 07:07:25 +0200
From: Bernd Walter [EMAIL PROTECTED]
To: Lee Damon [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: IBM T30 bluetooth - success
Message-ID: [EMAIL PROTECTED]
On Mon, Jun 16, 2003 at 04:31:25PM -0700, Lee Damon wrote:
I can second that success. Any chance of getting this patch checked in?
I just wait on a review.
- --
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
--- End of Forwarded Messages
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another pmap related panic
On Fri, 22 Aug 2003, Mark Tinguely wrote: I got another pmap related panic on my HTT SMP machine. If I don't get that completely wrong, it dies again after accessing the return value of pmap_pte_quick(). I haven't buried myself in the 5.x pmap/vm code, but I did a visual inspection of the Bosko Milekic PSE changes and they do look correct to me -- good job. Do these crashes happen with the HTT turned off? It appears interesting that both sources of your panics are in a pv_list loop. I guess I don't know the vm_page_queue_mtx locking well enough, but I see asserts if MA_OWNED, but I see how these are set to limit one processor in the queue. I have now applied Boskos Patch to a recent -CURRENT and also turned on INVARIANTS - same panic, same place in pmap_is_modified(). A UP kernel seems to be ok, but I would need to let it run longer. I'm starting to think of bad RAM. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Virus Alert
The mail message (file: document_9446.pif) you sent to [EMAIL PROTECTED] contains a virus (WORM_SOBIG.F). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
SENDMAIL_MC
Hi, I have SENDMAIL_MC and SENDMAIL_SUBMIT_MC defined in /etc/make.conf (both with the full path, i.e. /etc/mail/...). From the documentation I take it, that this should work. My installworld however breaks because src/etc/sendmail/Makefile strips the pathname from the variables before trying to install the files. So, is this supposed to work this way? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [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: IBM T30 bluetooth - success (fwd)
On Tue, Aug 26, 2003 at 08:46:12AM +0200, Tobias Roth wrote: eh? i silently assumed that it already was commited! i used bluetooth on my T30 on -current which is maybe three weeks old and it works! and to make this very clear, it did NOT work on a -current from around the time when i sent that email below. the patch fixed it back then, nothing else did. so, now i am confused... It's a timing related hardwarebug on power up. Other environment temperatures, etc may change things. -- 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: HEADS UP! ATAng committed
On Sun, Aug 24, 2003 at 11:27:05AM +0200, Soren Schmidt wrote: ATAng has just been committed. You need to make world after this update as atacontrol etc needs to pick up the changes. After updating to ATAng my DVD drive isn't detected. I get following message: ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED Before it was: DVD-ROM LG DVD-ROM DRD-8120B at ata1-slave UDMA33 Is there anything I can do, to provide you more specific information, please contact me. Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ATAng has just been committed. You need to make world after this update as atacontrol etc needs to pick up the changes. Just want to report initial success with this - my smp machine previously would not recognize my offboard pci-based ide devices with an smp kernel, but now it's working fine. I'm getting some unpleasant-looking messages when the drives get probed at boot-time, though: FreeBSD 5.1-CURRENT #0: Sun Aug 24 06:20:33 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/JKERN [...] atapci1: Promise PDC20262 UDMA66 controller port 0xef00-0xef3f,0xefa8-0xefab,0xefa0-0xefa7,0xefac-0xefaf,0xefe0-0xefe7 mem 0xfebc-0xfebd irq 11 at device 13.0 on pci0 ata2: at 0xefe0 on atapci1 ata3: at 0xefa0 on atapci1 [...] ata2-master: WARNING - ATA_IDENTIFY recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - SET_MULTI recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: 57241MB ST360021A [116301/16/63] at ata2-master UDMA66 ata3-master: WARNING - ATA_IDENTIFY recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - SET_MULTI recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - SETFEATURES recovered from missing interrupt ad1: 25965MB Maxtor 92720U8 [52755/16/63] at ata3-master UDMA66 ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - WRITE_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - WRITE_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - WRITE_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - WRITE_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt etc. Haven't seen any more of these messages since boot-time, and the everything seems to be working fine, but I still wonder what that's all about? -Jason -- Freud himself was a bit of a cold fish, and one cannot avoid the suspicion that he was insufficiently fondled when he was an infant. -- Ashley Montagu -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE/S1BXswXMWWtptckRAlEJAKCZ8VGpH70D6zdzPQiI4Dgc0yfjGQCgg9dm /DsP4A5uLYEFBy7ZqiZID8k= =STWA -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another pmap related panic
It could be a memory problem. Could you also please apply an assert to pmap_enter_quick() + INVARIANTS. This is a quick test that checks all the other paths that call pmap_enter_quick() are locked out so that two processors cannot be using the PADDR1/PMAP1 at the same time. --- pmap.c.orig Mon Aug 25 08:46:03 2003 +++ pmap.c Tue Aug 26 07:16:06 2003 @@ -2056,6 +2056,7 @@ pmap_enter_quick(pmap_t pmap, vm_offset_ pt_entry_t *pte; vm_paddr_t pa; + mtx_assert(vm_page_queue_mtx, MA_OWNED); /* * In the case that a page table page is not * resident, we are creating it here. --Mark Tinguely [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another pmap related panic
On Tue, 26 Aug 2003, Mark Tinguely wrote: It could be a memory problem. Could you also please apply an assert to pmap_enter_quick() + INVARIANTS. This is a quick test that checks all the other paths that call pmap_enter_quick() are locked out so that two processors cannot be using the PADDR1/PMAP1 at the same time. --- pmap.c.orig Mon Aug 25 08:46:03 2003 +++ pmap.cTue Aug 26 07:16:06 2003 @@ -2056,6 +2056,7 @@ pmap_enter_quick(pmap_t pmap, vm_offset_ pt_entry_t *pte; vm_paddr_t pa; + mtx_assert(vm_page_queue_mtx, MA_OWNED); /* * In the case that a page table page is not * resident, we are creating it here. This panics the machine at boot time: panic: mutex vm page queue mutex not owned at /usr/src/sys/i386/i386/pmap.c:2012 cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db where Debugger(c06809e2,0,c0680099,dff17880,100) at Debugger+0x55 panic(c0680099,c06910df,c0695c11,7dc,c0c35378) at panic+0x15f _mtx_assert(c06e9800,1,c0695c11,7dc,c1a45600) at _mtx_assert+0xec pmap_enter_quick(c25d60b0,8048000,c1a45600,0,7) at pmap_enter_quick+0x33 vm_map_pmap_enter(c25d6000,8048000,c0c35378,0,0) at vm_map_pmap_enter+0x26d vm_map_insert(c25d6000,c0c35378,0,0,8048000) at vm_map_insert+0x2ef elf32_map_insert(c25d6000,c0c35378,0,0,8048000) at elf32_map_insert+0x2ea elf32_load_section(c25c7d3c,c25d6000,c67b77fc,c0c35378,0) at elf32_load_section+0x12a exec_elf32_imgact(dff17b3c,0,c067e454,105,c06ddfe0) at exec_elf32_imgact+0x273 kern_execve(c25c8720,bfb2,bfbfffe4,0,0) at kern_execve+0x38c execve(c25c8720,dff17cf0,0,0,dff17cd8) at execve+0x30 start_init(0,dff17d48,c067e5ac,314,0) at start_init+0x43e fork_exit(c04cfbd0,0,dff17d48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdff17d7c, ebp = 0 --- regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another pmap related panic
MY APOLOGIES, I am s embarrassed. I should have placed that in pmap_pte_quick(), not pmap_enter_quick(). --Mark Tinguely [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
stray irq's in systat
Hi, When running 'systat -vmstat 1' on FreeBSD 5.1-CURRENT #1: Mon Aug 25 14:54:14 EDT 2003, the interrupts section shows irq's 0 and 6 as stray. I remember this would happen on 4.x when I took out lpt drivers from the kernel, and didn't disable lpt in the bios. This however is not the case, and start irq's do not show up under 4.8 on this box. everything is working ok, I am just curious why they are showing up. # dmesg|grep 'irq 0' # dmesg|grep 'irq 6' fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0 Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another pmap related panic
On Tue, 26 Aug 2003, Mark Tinguely wrote: MY APOLOGIES, I am s embarrassed. I should have placed that in pmap_pte_quick(), not pmap_enter_quick(). This one panics, too, right at boot time. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another pmap related panic
Mark Tinguely wrote: It could be a memory problem. Could you also please apply an assert to pmap_enter_quick() + INVARIANTS. This is a quick test that checks all the other paths that call pmap_enter_quick() are locked out so that two processors cannot be using the PADDR1/PMAP1 at the same time. Neither of Lukas's panics suggests that PADDR1/PMAP1 is being used. The faulting virtual addresses are fault virtual address = 0xbfca1974 and fault virtual address = 0xbfcadf10 which are within the PTmap, not PADDR1. In other words, pmap_pte_quick() concluded that the given pmap was currently active and therefore the pte was accessible through the mapping that each address space has to its own page table. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HTT on current
JYI, I tested machdep.hlt_logical_cpus=0/1, buildworld, and found no particular reason to disable HTT as below with Zeon 2.8Ghz x 2, 1GBmem, Slow IDE HDD. It may not be the common case, so just for your info. # sysctl machdep.hlt_logical_cpus=0 # /usr/bin/time make -j32 buildworld 1910.29 real 2520.53 user 777.30 sys # sysctl machdep.hlt_logical_cpus=1 # /usr/bin/time make -j32 buildworld 2289.33 real 2666.66 user 645.88 sys ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another pmap related panic
Thank-you, The fact that pmap_pte_quick() panics on the untrue mutex should indicate that it is possible that 2 processors may enter pmap_pte_quick() at the same time and therefore it is possible to have the one processor invalidate the VA/PA mapping using PADDR1/PMAP1. If that is true then the first processor should trap/panic when dereferencing the VA address. If the above is true, a PADDR1 mutex could be added, or use a seperate PADDR/PMAP per processor. Looks like there is already mutex for the copy maps. Did you want me to work up a test PADDR mutex? --Mark. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
My DVD drive is no longer working.. anyway around this? Before ATAng: acd1: DVD-ROM HL-DT-STDVD-ROM GDR8160B at ata1-slave PIO4 After ATAng: ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
Soren,
My machine panic when pax a directory to the software raid. The same step works just
fine for an
older kernel before the ATAng commit. After this panic, the raid is broken and has to
be created
manually. The controller is a Highpoint 370 with bios 2.34 with 2 IDE IBM DTLA-307030
attached to
the two UDMA100 interfaces. I have been able to dump core and backtrace the panic as
shown below.
Is it a unique problem on me? Thanks for any advice...
panic: initiate_write_inodeblock_ufs2: already started
panic: from debugger
Uptime: 2m45s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416
432 448 464 480 496
---
Reading symbols from
/usr/obj/usr/src/sys/SHIZUKA/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/SHIZUKA/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/logo_saver.ko...done.
Loaded symbols for /boot/kernel/logo_saver.ko
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0254380 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0254768 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc014ba82 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc014b9e2 in db_command (last_cmdp=0xc046c120, cmd_table=0x0,
aux_cmd_tablep=0xc0422284, aux_cmd_tablep_end=0xc0422288)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc014bb25 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc014eb45 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc03b5d4c in kdb_trap (type=3, code=0, regs=0xdc39ea3c)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc03c75aa in trap (frame=
{tf_fs = -831782888, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1069454141,
tf_ebp =
-600184184, tf_isp = -600184216, tf_ebx = 0, tf_edx = 0, tf_ecx = -1068875680, tf_eax
= 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1069850620, tf_cs = 8, tf_eflags = 642, tf_esp =
-1069434333,
tf_ss = -1069505986})
at /usr/src/sys/i386/i386/trap.c:577
#9 0xc03b76f8 in calltrap () at {standard input}:102
#10 0xc02546a5 in panic (
fmt=0xc0416cc3 initiate_write_inodeblock_ufs2: already started)
at /usr/src/sys/kern/kern_shutdown.c:534
#11 0xc035e2e6 in initiate_write_inodeblock_ufs2 (inodedep=0xc42b6800, bp=0x0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3893
---Type return to continue, or q return to quit---
#12 0xc035d46d in softdep_disk_io_initiation (bp=0xce641830)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3459
#13 0xc0214954 in spec_xstrategy (vp=0xc41dfdb0, bp=0xce641830)
at /usr/src/sys/sys/buf.h:413
#14 0xc0214aab in spec_specstrategy (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:529
#15 0xc0213c18 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:122
#16 0xc029da9b in bwrite (bp=0xce641830) at vnode_if.h:1141
#17 0xc029ffd9 in vfs_bio_awrite (bp=0xce641830)
at /usr/src/sys/kern/vfs_bio.c:1709
#18 0xc02a0e16 in flushbufqueues (flushdeps=0)
at /usr/src/sys/kern/vfs_bio.c:2171
#19 0xc02a097c in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:2072
#20 0xc023d091 in fork_exit (callout=0xc02a0840 buf_daemon, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:796
__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stray irq's in systat
On Tue, 26 Aug 2003, Mike Jakubik wrote:
When running 'systat -vmstat 1' on FreeBSD 5.1-CURRENT #1: Mon Aug 25
14:54:14 EDT 2003, the interrupts section shows irq's 0 and 6 as stray. I
remember this would happen on 4.x when I took out lpt drivers from the
kernel, and didn't disable lpt in the bios. This however is not the case,
and start irq's do not show up under 4.8 on this box. everything is working
ok, I am just curious why they are showing up.
This is caused by a race calling update_intrname().
Most of the patch consists of comments about unfixed races. There are many
other bugs in this area.
%%%
Index: intr_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/isa/intr_machdep.c,v
retrieving revision 1.73
diff -u -2 -r1.73 intr_machdep.c
--- intr_machdep.c 20 Oct 2002 18:02:46 - 1.73
+++ intr_machdep.c 6 Apr 2003 10:14:13 -
@@ -663,13 +637,40 @@
ithread_priority(flags), flags, cookiep);
- if ((flags INTR_FAST) == 0 || errcode)
+ if ((flags INTR_FAST) == 0 || errcode) {
/*
* The interrupt process must be in place, but
* not necessarily schedulable, before we
-* initialize the ICU, since it may cause an
+* initialize the ICU, since initializing it may cause an
* immediate interrupt.
+*
+* The pointer to the interrupt counter (which is changed if
+* the name is changed) must be in place for the same reason.
+* Otherwise, we could and did get normal interrupts bogusly
+* counted as stray ones, which mainly messed up systat(8)'s
+* layout.
+*
+* XXX we depend on the interrupt being set up not already
+* being enabled here. This is part of the API, and the
+* locking for it is hopefully adequate. However, the
+* locking is inadequate for other interrupts being set
+* up concrrently (we race in update_intrname()) and for
+* spurious interrupts (update_intrname() and icu_setup()
+* need a common lock).
+*
+* XXX icu_unset() is only called from isa_defaultirq(), so
+* I don't see how bus_teardown_intr() can work. I think
+* it leaves a garbage pointer to the interrupt handler.
+* In the non-fast case, the pointer is to sched_ithd() so
+* which cannot be unloaded, so the only damage is that we
+* waste time checking for errors that shouldn't happen.
+* In the fast case, the pointer may be into an unloaded
+* module. Presumably the interrupt is masked in another
+* way, else we would have more problems. However, spurious
+* interrupts can't be masked in the ICU.
*/
+ update_intrname(irq, name);
if (icu_setup(irq, sched_ithd, arg, flags) != 0)
panic(inthand_add: Can't initialize ICU);
+ }
if (errcode)
@@ -677,4 +678,9 @@
if (flags INTR_FAST) {
+ /*
+* XXX this clause repeats a lot of code, apparently just to
+* vary the handler and to avoid panicing if icu_setup() fails.
+*/
+ update_intrname(irq, name);
errcode = icu_setup(irq, handler, arg, flags);
if (errcode bootverbose)
@@ -685,5 +691,4 @@
}
- update_intrname(irq, name);
return (0);
}
%%%
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stray irq's in systat
any plans to commit this?
On Wed, 27 Aug 2003, Bruce Evans wrote:
On Tue, 26 Aug 2003, Mike Jakubik wrote:
When running 'systat -vmstat 1' on FreeBSD 5.1-CURRENT #1: Mon Aug 25
14:54:14 EDT 2003, the interrupts section shows irq's 0 and 6 as stray. I
remember this would happen on 4.x when I took out lpt drivers from the
kernel, and didn't disable lpt in the bios. This however is not the case,
and start irq's do not show up under 4.8 on this box. everything is working
ok, I am just curious why they are showing up.
This is caused by a race calling update_intrname().
Most of the patch consists of comments about unfixed races. There are many
other bugs in this area.
%%%
Index: intr_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/isa/intr_machdep.c,v
retrieving revision 1.73
diff -u -2 -r1.73 intr_machdep.c
--- intr_machdep.c20 Oct 2002 18:02:46 - 1.73
+++ intr_machdep.c6 Apr 2003 10:14:13 -
@@ -663,13 +637,40 @@
ithread_priority(flags), flags, cookiep);
- if ((flags INTR_FAST) == 0 || errcode)
+ if ((flags INTR_FAST) == 0 || errcode) {
/*
* The interrupt process must be in place, but
* not necessarily schedulable, before we
- * initialize the ICU, since it may cause an
+ * initialize the ICU, since initializing it may cause an
* immediate interrupt.
+ *
+ * The pointer to the interrupt counter (which is changed if
+ * the name is changed) must be in place for the same reason.
+ * Otherwise, we could and did get normal interrupts bogusly
+ * counted as stray ones, which mainly messed up systat(8)'s
+ * layout.
+ *
+ * XXX we depend on the interrupt being set up not already
+ * being enabled here. This is part of the API, and the
+ * locking for it is hopefully adequate. However, the
+ * locking is inadequate for other interrupts being set
+ * up concrrently (we race in update_intrname()) and for
+ * spurious interrupts (update_intrname() and icu_setup()
+ * need a common lock).
+ *
+ * XXX icu_unset() is only called from isa_defaultirq(), so
+ * I don't see how bus_teardown_intr() can work. I think
+ * it leaves a garbage pointer to the interrupt handler.
+ * In the non-fast case, the pointer is to sched_ithd() so
+ * which cannot be unloaded, so the only damage is that we
+ * waste time checking for errors that shouldn't happen.
+ * In the fast case, the pointer may be into an unloaded
+ * module. Presumably the interrupt is masked in another
+ * way, else we would have more problems. However, spurious
+ * interrupts can't be masked in the ICU.
*/
+ update_intrname(irq, name);
if (icu_setup(irq, sched_ithd, arg, flags) != 0)
panic(inthand_add: Can't initialize ICU);
+ }
if (errcode)
@@ -677,4 +678,9 @@
if (flags INTR_FAST) {
+ /*
+ * XXX this clause repeats a lot of code, apparently just to
+ * vary the handler and to avoid panicing if icu_setup() fails.
+ */
+ update_intrname(irq, name);
errcode = icu_setup(irq, handler, arg, flags);
if (errcode bootverbose)
@@ -685,5 +691,4 @@
}
- update_intrname(irq, name);
return (0);
}
%%%
Bruce
___
[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: HEADS UP! ATAng committed
On Tue, 26 Aug 2003, Wiktor Niesiobedzki wrote: On Sun, Aug 24, 2003 at 11:27:05AM +0200, Soren Schmidt wrote: ATAng has just been committed. You need to make world after this update as atacontrol etc needs to pick up the changes. After updating to ATAng my DVD drive isn't detected. I get following message: ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED Try backing out rev.1.5 of ata-lowlevel.c. It clobbers the signature of all 3 atapi drives on one of my systems here. This results the atapi drives being further probed as ata drives and the probe soon fails with the above error. Output from ATAog for these atapi drives: Aug 27 00:16:50 gamplex kernel: afd0: 96MB IOMEGA ZIP 100 ATAPI [96/64/32] at ata0-slave PIO0 Aug 27 00:16:50 gamplex kernel: acd0: CD-RW RICOH CD-RW MP7320A at ata1-slave UDMA33 Aug 27 00:16:50 gamplex kernel: acd1: CDROM ATAPI 44X CDROM at ata2-slave PIO4 Aug 27 00:16:50 gamplex kernel: cd1 at ata2 bus 0 target 1 lun 0 Aug 27 00:16:50 gamplex kernel: cd1: ATAPI 44X CDROM 3.40 Removable CD-ROM SCSI-0 device Aug 27 00:16:50 gamplex kernel: cd1: 16.000MB/s transfers Aug 27 00:16:50 gamplex kernel: cd1: cd present [317714 x 2048 byte records] Aug 27 00:16:50 gamplex kernel: cd0 at ata1 bus 0 target 1 lun 0 Aug 27 00:16:50 gamplex kernel: cd0: RICOH CD-RW MP7320A bp13 Removable CD-ROM SCSI-0 device Aug 27 00:16:50 gamplex kernel: cd0: 33.000MB/s transfers Aug 27 00:16:50 gamplex kernel: cd0: cd present [320930 x 2048 byte records] Aug 27 00:16:50 gamplex kernel: da0 at ata0 bus 0 target 1 lun 0 Aug 27 00:16:50 gamplex kernel: da0: IOMEGA ZIP 100 14.A Removable Direct Access SCSI-0 device Aug 27 00:16:50 gamplex kernel: da0: 3.300MB/s transfers Aug 27 00:16:50 gamplex kernel: da0: 96MB (196608 512 byte sectors: 64H 32S/T 96C) ata0 and ata1 are on a BX chipset, and ata2 and ata3 are on an old highpoint chipset. ata0 has a working ata drive on the master. ata1 has a broken ata drive on the master (I keep it for debugging ata; it probes correctly but recently became unreadable on block 0). ata2 has no master. ata3 has no drives. Breaking the probe of the atapi drives avoids some other bugs: - a panic for atapicam (already reported). - spurious interrupts on ata2. -current somehow recovers after reporting about 10 such interrupts, but my -mycurrent spins endlessly on them. I suspect Giant locking problems. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
cdrecord causes panic
When trying to burn with -current from 11 August or later I get a panic. panic: vm_fault_copy_wired: page missing This happens with both ULE and 4BSD schedulers. I'm using the sym driver on a Tekram 390u3d, LSI 53C1010-33 chip CD Writer is a Plextor 4/2/20 I can see several vm_* files was updated at the time burning broke, so it's probably related to that. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atapicam panic at boot.
last night's sources: free_hcb() atapi_action() xpt_run_dev_sendq() xpt_action() probe_start() ... appears to be a memory access error. -Alfred ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HTT on current
On 26-Aug-2003 Yamada Ken Takeshi wrote: JYI, I tested machdep.hlt_logical_cpus=0/1, buildworld, and found no particular reason to disable HTT as below with Zeon 2.8Ghz x 2, 1GBmem, Slow IDE HDD. It may not be the common case, so just for your info. # sysctl machdep.hlt_logical_cpus=0 # /usr/bin/time make -j32 buildworld 1910.29 real 2520.53 user 777.30 sys # sysctl machdep.hlt_logical_cpus=1 # /usr/bin/time make -j32 buildworld 2289.33 real 2666.66 user 645.88 sys One test is not sufficient. -current is also not the best place to test. :) When I first implemented HTT in -current and -stable, I did some worldstone benchmarks on -stable on a machine with a single HTT CPU. Note that I was comparing a UP kernel with an SMP kernel as well, so some of the speed decrease of the SMP kernel could be due to it being an SMP kernel, not due to HTT. I did 16 trials (first one was throwaway) of back-to-back buildworlds of the same version of -stable using make, make -j2, and make -j4 for the following configurations: UP, HTT, HTT with smp_idle_hlt, and HTT with pause instructions added to stable and smp_idle_hlt. The fastest build time belonged to UP without any -j option. However, the next fastest ended up being the HTT with pause and smp_idle_hlt. The averages were 19:03 and 19:42 respectively with a standard deviation in both cases of around 3.5 seconds. That is only with 15 real trials though, so I'm not sure what kind of 90% confidence interval you would get from that. I did find that with the hlt and pause additions, the HTT kernel did complete the -j2 and -j4 builds faster than the UP kernel, but those builds still took longer than a build without -j. I can't remember if I committed the addition of the pause instructions to stable or not. If I didn't then I really should do that prior to 4.9. -- 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: atapicam panic at boot.
free_hcb() atapi_action() xpt_run_dev_sendq() xpt_action() probe_start() ... I think some people are already tracking this down related to the recent update of the ata drivers. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! ATAng committed
On Wed, 27 Aug 2003 03:10:27 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: On Tue, 26 Aug 2003, Wiktor Niesiobedzki wrote: On Sun, Aug 24, 2003 at 11:27:05AM +0200, Soren Schmidt wrote: ATAng has just been committed. You need to make world after this update as atacontrol etc needs to pick up the changes. After updating to ATAng my DVD drive isn't detected. I get following message: ata1-slave: FAILURE - ATA_IDENTIFY status=51READY,DSC,ERROR error=4ABORTED Try backing out rev.1.5 of ata-lowlevel.c. It clobbers the signature of all 3 atapi drives on one of my systems here. This results the atapi drives being further probed as ata drives and the probe soon fails with the above error. Confirmed.. I went back to 'src/sys/dev/ata/ata-lowlevel.c,v 1.4' and all is well again. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PCMCIA trouble with Xircom, CIS is too long -- truncating
Hi, good and bad news. Good news is that -current installation CD-Rom (JPSNAP of yesterday) doesn't panic during boot anymore, which was the case previously (or when inserting the card). Thanks a lot, this is a very good progress, I'm very pleased ! But the fix opened another problem. The card isn't recognized by the FreeBSD anymore: [... kernel boot messages ...] Timecounters tick every 10.000 msec CIS is too long -- truncating pccard0: Card has no functions cbb0: PC Card activation failed [...] When trying to do installation, the NIC isn't found. The PCMCIA card is a: Xircom RealPort Ethernet 10/100+Modem 56, REM55G-100. Here a dump of the CIS: [EMAIL PROTECTED] ~ pccardc dumpcis Configuration data for card in slot 0 Tuple #1, code = 0x1 (Common memory descriptor), length = 2 000: 00 ff Common memory device information: Device number 1, type No device, WPS = OFF Speed = No speed, Memory block size = reserved, 32 units Tuple #2, code = 0x17 (Attribute memory descriptor), length = 2 000: 00 ff Attribute memory device information: Device number 1, type No device, WPS = OFF Speed = No speed, Memory block size = reserved, 32 units Tuple #3, code = 0x15 (Version 1 info), length = 59 000: 05 00 58 69 72 63 6f 6d 00 43 72 65 64 69 74 43 010: 61 72 64 20 45 74 68 65 72 6e 65 74 20 31 30 2f 020: 31 30 30 20 2b 20 4d 6f 64 65 6d 20 35 36 00 43 030: 45 4d 35 36 00 31 2e 30 30 00 ff Version = 5.0, Manuf = [Xircom], card vers = [CreditCard Ethernet 10/100 + Modem 56] Addit. info = [CEM56],[1.00] Tuple #4, code = 0x88 (Unknown), length = 8 000: e8 11 bb 00 00 00 00 00 Tuple #5, code = 0x20 (Manufacturer ID), length = 5 000: 05 01 0a 11 46 PCMCIA ID = 0x105, OEM ID = 0x110a Tuple #6, code = 0x44 (Card init date), length = 4 000: 41 43 a1 28 Tuple #7, code = 0x1a (Configuration map), length = 5 000: 01 3f 80 ff 67 Reg len = 2, config register addr = 0xff80, last config = 0x3f Registers: XXX--XX- Tuple #8, code = 0x1b (Configuration entry), length = 20 000: e7 c1 9d 0f 55 4d 5d 4e e0 17 17 ea 60 e8 02 07 010: f0 bc 8e 20 Config index = 0x27(default) Interface byte = 0xc1 (I/O) +RDY/-BSY active, wait signal supported Vcc pwr: Nominal operating supply voltage: 5 x 1V Minimum operating supply voltage: 4.5 x 1V Maximum operating supply voltage: 5.5 x 1V Continuous supply current: 4.5 x 100mA Wait scale Speed = 1.2 x 10 ms RDY/BSY scale Speed = 1.2 x 10 ms Card decodes 10 address lines, full 8/16 Bit I/O I/O address # 1: block start = 0x2e8 block length = 0x8 IRQ modes: Level, Pulse, Shared IRQs: 2 3 4 5 7 9 10 11 15 Max twin cards = 0 Misc attr: (Power down supported) Tuple #9, code = 0x1b (Configuration entry), length = 7 000: 1f 08 ea 60 e8 03 07 Config index = 0x1f Card decodes 10 address lines, full 8/16 Bit I/O I/O address # 1: block start = 0x3e8 block length = 0x8 Tuple #10, code = 0x1b (Configuration entry), length = 7 000: 17 08 ea 60 f8 02 07 Config index = 0x17 Card decodes 10 address lines, full 8/16 Bit I/O I/O address # 1: block start = 0x2f8 block length = 0x8 Tuple #11, code = 0x1b (Configuration entry), length = 7 000: 0f 08 ea 60 f8 03 07 Config index = 0xf Card decodes 10 address lines, full 8/16 Bit I/O I/O address # 1: block start = 0x3f8 block length = 0x8 Tuple #12, code = 0x1b (Configuration entry), length = 3 000: 3f 08 63 Config index = 0x3f Card decodes 3 address lines, full 8/16 Bit I/O Tuple #13, code = 0x21 (Functional ID), length = 2 000: 02 00 Serial port/modem Tuple #14, code = 0x22 (Functional EXT), length = 4 000: 00 02 0f 5c Serial interface extension: 16550 UART, Parity - Space,Mark,Odd,Even Data bit - 7bit,8bit, Stop bit - 1bit,2bit Tuple #15, code = 0x22 (Functional EXT), length = 12 000: 02 06 00 3f 1c 03 03 0f 07 00 01 b5 Data modem services available: Tuple #16, code = 0x22 (Functional EXT), length = 8 000: 13 06 00 0b 00 02 00 b5 Fax1/modem services available: Tuple #17, code = 0x21 (Functional ID), length = 2 000: 06 00 Network/LAN adapter Tuple #18, code = 0x22 (Functional EXT), length = 8 000: 04 06 00 10 a4 bb 11 e8 Network node ID: 00 10 a4 bb 11 e8 Tuple #19, code = 0x8a (Unknown), length = 12 000: 32 30 30 31 48 57 42 42 31 31 45 38 Tuple #20, code = 0x8b (Unknown), length = 4 000: 01 00 00 00 Tuple #21, code = 0x14 (No link), length = 0 Tuple #22, code = 0xff (Terminator), length = 0 2 slots found What more infos do you need ? Andreas /// --
8.26.03 build getty error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just did a full world rebuild. After which, I ran mergemaster. When I do a regular boot I get this error: Bus error Pid 43 (rcorder), uid 0: exited on signal 10 Can't exec getty '/usr/libexec/getty' for port /dev/ttyv*' The ttvy are 0-5. I can boot into single mode fine, and mount all partitions, but I don't know what to look for. /etc/gettytab looks ok, altough I don't know what a problem would look like. The file is intact, however. I can even do: '/usr/libexec/getty Pc' and get an amnesiac login. Also, like an idiot, I think I might have deleted my /etc backup. Not a good day for me. I looked through UPDATING and didn't see any mention of an issues related to this. Where have I gone wrong? - -- Mike Loiterman grantADLER Tel: 630-302-4944 Fax: 773-868-0071 Email: [EMAIL PROTECTED] PGP Key 0xD1B9D18E -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 Comment: This message has been digitally signed by Mike Loiterman iQA/AwUBP0vY7mjZbUnRudGOEQKVrQCg29GETwm5PcnjTdYMNeoBkndGZ/8AoNdM 5eqgtg9WeMB5fbl9IjJjDM8j =6p2F -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Question: should I even bother?
Over the past few weeks, I have posted messages about panics that I've been having. No answers at all. Yesterday, I posted about a repeatable problem where dumps just destroy my IDE drive. No answers. Pretty serious problem. No, my swap partition doesn't start at sector 0. Have I offended some or all of you somehow? I'd like to contribute in some way... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 8.26.03 build getty error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Loiterman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just did a full world rebuild. After which, I ran mergemaster. When I do a regular boot I get this error: Bus error Pid 43 (rcorder), uid 0: exited on signal 10 Can't exec getty '/usr/libexec/getty' for port /dev/ttyv*' The ttvy are 0-5. I can boot into single mode fine, and mount all partitions, but I don't know what to look for. /etc/gettytab looks ok, altough I don't know what a problem would look like. The file is intact, however. I can even do: '/usr/libexec/getty Pc' and get an amnesiac login. Also, like an idiot, I think I might have deleted my /etc backup. Not a good day for me. I looked through UPDATING and didn't see any mention of an issues related to this. Where have I gone wrong? Opps. I forgot to merge hostname. My fault. Hope this helps someone else out. - -- Mike Loiterman grantADLER Tel: 630-302-4944 Fax: 773-868-0071 Email: [EMAIL PROTECTED] PGP Key 0xD1B9D18E -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 Comment: This message has been digitally signed by Mike Loiterman iQA/AwUBP0viOGjZbUnRudGOEQLtqACdHfVQOrh1HJdWkO0caS9ULz3eIccAnjfv Ny19zIDdu7auD5/qmn/zz1N1 =meYy -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel panic with CAM on current (fatal trap 12)
Hi, I compiled world and kernel tonight (Aug 26th) on my Thinkpad R40 with a CD/RW drive. I tried my old settings with cam enabled so I can use cdrecord. During boot I got a kernel panic about 10 seconds after the kernel detected the CD/RW drive. Here some info: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present [...IP/SP reg values changing...] 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 = 20 (swi3:cambio) trap number = 12 In verbose mode it also showed some non-retryable errors while accessing ata0 and sbp0, before the kernel stops with the panic. I could start the latest kernel after removing sbp, umass, cam-stuff and atapicam and recompiling it. The last kernel without these effects was compiled on Aug 18th. I hope it helps, if not, I can write down more information for you. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Question: should I even bother?
On 26-Aug-2003 Bryan Liesner wrote: Over the past few weeks, I have posted messages about panics that I've been having. No answers at all. Yesterday, I posted about a repeatable problem where dumps just destroy my IDE drive. No answers. Pretty serious problem. No, my swap partition doesn't start at sector 0. Have I offended some or all of you somehow? I'd like to contribute in some way... No, I doubt you've offended anyone. However, most people working on FreeBSD have a steady state of being really busy and unfortunately some bug reports don't always get followed up on. Including stack traces with panic reports can greatly aid in getting the panics resolved. Note that the panic in specfs that a lot of folks were seeing has been recently fixed and I saw many unanswered reports of that panic as reports were coming in well after the problem had been identified and even fixed. The ata(4) driver was just rewritten and is a bit rocky apparently. I haven't dared to upgrade to it yet, so if it's trashing your disks you might want to keep an old kernel around to get work done with. :) -- 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: Radeon 7500 w/ DRI locking on restart of X
I have precisely the same symptoms as what Glenn listed. I have now tried the forcepcimode option on the laptop and unfortunately experienced what appears to be the opposite effect to what Glenn noted. I get a black screen with lots of disk activity. I can log in remotely (at least that seemed to work every time) and a top listing shows X taking up more and more CPU cycles. It seems to be scribbling to the disk making temporary files as well because eventually I couldn't edit the XF86Config file any longer -- I was getting a no space left on device error. I ended up taking out all options short of disabling DRI altogether and eventually discovered the only way I could run with DRI switches on and forcepcimode set to true was to unload the agp module from kernel space. This got it started just fine but there was no DRI. It seems that X is getting confused and somehow PCI and AGP modes are duking it out... Here is a listing of the X modules from ports: XFree86-4.3.0,1 XFree86-FontServer-4.3.0 XFree86-Server-4.3.0_5 XFree86-clients-4.3.0_1 XFree86-documents-4.3.0 XFree86-font100dpi-4.3.0 XFree86-font75dpi-4.3.0 XFree86-fontCyrillic-4.3.0 XFree86-fontDefaultBitmaps-4.3.0 XFree86-fontEncodings-4.3.0 XFree86-fontScalable-4.3.0 XFree86-libraries-4.3.0_3 Xaw3d-1.5 Xft-2.1_8 This is what I see from 'dmesg | grep drm' : drm0: ATI Radeon LW Mobility 7 (AGP) port 0xcc00-0xccff mem 0xfcff-0xfcff,0xe000-0xe7ff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe800 64MB info: [drm] Initialized radeon 1.8.0 20020828 on minor 0 Here is the output of 'head /var/log/XFree86.0.log' : XFree86 Version 4.3.0 (DRI trunk) Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: FreeBSD 4.8-RELEASE i386 [ELF] Build Date: 09 August 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, The above was built on 08/03/03 in the evening. Here is 'uname -a': FreeBSD NitroPhys.welchsmnet.net 4.8-RELEASE FreeBSD 4.8-RELEASE #1: Thu May 29 11:24:46 CDT 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/NITROPHYS i386 The kernel is compiled with SSE support. I have tried turning off all options in the config file and different AGP modes. I always get the same results. My 5.1-RELEASE install is just using the X off the install disc with the kernel module that shipped with it. Same exact issues. I believe I saw a commit to DRI CVS a while back that was supposed to address this very issue (comment said something about locks on logout with GDM) but it didn't change anything for me. Let me know what else you'd like to have in the way of info. Sean ---Original Message--- From: Glenn Johnson [EMAIL PROTECTED] Sent: 08/26/03 03:55 PM To: Eric Anholt [EMAIL PROTECTED] Subject: Re: Radeon 7500 w/ DRI locking on restart of X On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote: On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote: I had similar problem with a 7200 and OGL. I solved the problem by turning off some of the options in the X config. On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch [EMAIL PROTECTED] wrote: Is anyone else seeing this issue? I'm running into it on desktop boxes and a laptop running 4.8-RELEASE with up to date ports collections and various versions of DRI installed over a ports version of X. I'm also seeing this under 5.1-RELEASE on the laptop. Everything works perfectly unless/until I restart the X server. This appears to be initiated automatically when running GDM -- ie, GDM starts, you log in using that X session, you log out and the session stops, GDM starts X again and displays the login screen. This seems to happen a bit more than 1/3 of the times I try it (intentionally or not). It isn't much of a problem on the laptop as I'm the only user and tend to turn the machine off when I log out but it is causing all sorts of issues on the desktops because they are intended to be used as multi-user (serially and also simultaneously) systems. Any ideas? The instability goes away completely with DRI disabled, but part of the use of these desktops is in the accelerated OpenGL rendering... Sean (CC'ed to -current since it's not -stable specific) This is an example of why people need to send PRs and not just emails. I realize now I've seen emails on this before, but I had forgotten about them because they seemed isolated and I didn't have them piling up in my assigned prs list (things pile up in my mailboxes easily, and I don't go back and check very often). Speaking for myself, I was not sure whether the problem was a BIOS setting problem, a graphics card problem, a FreeBSD
