Re: [panic] 10.1-RELEASE-p14 #4 r285499M sporadic reboot
* Zeus Panchenko, 2015-07-22 : > on important production server I've started to experience weird regular > (once a day-two) sporadic reboots after last upgrade (2015-07-17), and > would appreciate if someone could help me to analyze further and fix the > issue. > > Collected crash information below > > full logs are available upon request. For the record, I observed a similar crash today: ceuta-ng.act-europe.fr dumped core - see /var/crash/vmcore.2 Tue Sep 29 18:25:59 CEST 2015 FreeBSD ceuta-ng.act-europe.fr 10.1-RELEASE-p8 FreeBSD 10.1-RELEASE-p8 #2 r280990M: Tue Jul 7 18:18:21 CEST 2015 root@lynchburg:/usr/obj/usr/src/releng/10.1/sys/ADACORE_FW amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x8040 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80d4f81c stack pointer = 0x28:0xfe011bfaf810 frame pointer = 0x28:0xfe011bfaf820 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 = 12 (swi1: netisr 0) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: #0 0x80977830 at kdb_backtrace+0x60 #1 0x8093c955 at panic+0x155 #2 0x80d5dc3f at trap_fatal+0x38f #3 0x80d5df58 at trap_pfault+0x308 #4 0x80d5d5ba at trap+0x47a #5 0x80d434a2 at calltrap+0x8 #6 0x80e7000b at bounce_bus_dmamap_load_buffer+0x1bb #7 0x80972b42 at bus_dmamap_load_mbuf_sg+0x72 #8 0x819ca83e at igb_refresh_mbufs+0x19e #9 0x819ca642 at igb_rxeof+0x692 #10 0x819cb9a0 at igb_poll+0x110 #11 0x8092bd6c at netisr_poll+0xfc #12 0x80a09c3d at swi_net+0x1d #13 0x8090ea8b at intr_event_execute_handlers+0xab #14 0x8090eed6 at ithread_loop+0x96 #15 0x8090c6aa at fork_exit+0x9a #16 0x80d439de at fork_trampoline+0xe Uptime: 3d17h55m1s Dumping 448 out of 4069 MB:..4%..11%..22%..33%..43%..54%..61%..72%..83%..93% Reading symbols from /boot/kernel/carp.ko.symbols...done. Loaded symbols for /boot/kernel/carp.ko.symbols Reading symbols from /boot/kernel/if_igb.ko.symbols...done. Loaded symbols for /boot/kernel/if_igb.ko.symbols Reading symbols from /boot/kernel/pflog.ko.symbols...done. Loaded symbols for /boot/kernel/pflog.ko.symbols Reading symbols from /boot/kernel/pf.ko.symbols...done. Loaded symbols for /boot/kernel/pf.ko.symbols Reading symbols from /boot/kernel/pfsync.ko.symbols...done. Loaded symbols for /boot/kernel/pfsync.ko.symbols Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. Loaded symbols for /boot/kernel/ng_socket.ko.symbols Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_mppc.ko.symbols...done. Loaded symbols for /boot/kernel/ng_mppc.ko.symbols Reading symbols from /boot/kernel/rc4.ko.symbols...done. Loaded symbols for /boot/kernel/rc4.ko.symbols Reading symbols from /boot/kernel/if_tap.ko.symbols...done. Loaded symbols for /boot/kernel/if_tap.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:219 #1 0x8093c5d2 in kern_reboot (howto=260) at /usr/src/releng/10.1/sys/kern/kern_shutdown.c:452 #2 0x8093c994 in panic (fmt=) at /usr/src/releng/10.1/sys/kern/kern_shutdown.c:759 #3 0x80d5dc3f in trap_fatal (frame=, eva=) at /usr/src/releng/10.1/sys/amd64/amd64/trap.c:865 #4 0x80d5df58 in trap_pfault (frame=0xfe011bfaf760, usermode=) at /usr/src/releng/10.1/sys/amd64/amd64/trap.c:676 #5 0x80d5d5ba in trap (frame=0xfe011bfaf760) at /usr/src/releng/10.1/sys/amd64/amd64/trap.c:440 #6 0x80d434a2 in calltrap () at /usr/src/releng/10.1/sys/amd64/amd64/exception.S:232 #7 0x80d4f81c in pmap_kextract (va=0) at /usr/src/releng/10.1/sys/amd64/amd64/pmap.c:639 #8 0x80e7000b in bounce_bus_dmamap_load_buffer ( dmat=0xf80002b8ae00, map=0x81637498, buf=, buflen=, pmap=0x816beb60, flags=, segs=) at /usr/src/releng/10.1/sys/x86/x86/busdma_bounce.c:690 #9 0x80972b42 in bus_dmamap_load_mbuf_sg (dmat=0xf80002b8ae00, map=0x0, m0=, segs=0xfe011bfaf930
Re: .zfs snapshot dir disappears and a crash later on, while umounting (8.0-RC1)
* György Vilmos, 2009-06-11 : > Subject: .zfs snapshot dir disappears and a crash later on, while > umounting For the record, I got the same symptom here on 8.0-RC1. > #7 0x807ba96e in calltrap () at /usr/src/sys/amd64/amd64/ > exception.S:209 > #8 0x80517925 in _sx_xlock (sx=0xa0, opts=0, > file=0x80f045e8 "/usr/src/sys/modules/zfs/../../cddl/contrib/ > opensolaris/uts/common/fs/zfs/zfs_ctldir.c", > line=1288) at atomic.h:143 > #9 0x80e97e55 in zfsctl_umount_snapshots (vfsp=Variable > "vfsp" is not available. > ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/ Clearly looks like something in the .zfs structure gets botched at some point... I'll keep the crash dump for a while, if more information is needed please let me know. Thomas. melamine.cuivre.fr.eu.org dumped core - see /var/crash/vmcore.0 Fri Nov 6 01:23:21 CET 2009 FreeBSD melamine.cuivre.fr.eu.org 8.0-RC1 FreeBSD 8.0-RC1 #0: Tue Oct 6 19:43:29 UTC 2009 r...@melamine2.cuivre.fr.eu.org:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: <6>ifa_del_loopback_route: deletion failed <5>tun2: link state changed to DOWN <118>Nov 6 00:16:38 melamine syslogd: exiting on signal 15 info: [drm] Resetting GPU Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xa8 fault code = supervisor write data, page not present instruction pointer = 0x20:0x8058cbf5 stack pointer = 0x28:0xff815d480970 frame pointer = 0x28:0xff815d480980 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 = 41907 (reboot) trap number = 12 panic: page fault cpuid = 0 Uptime: 15d10h25m49s Physical memory: 12270 MB Dumping 5655 MB: 5640 5624 5608 5592 5576 5560 5544 5528 5512 5496 5480 5464 5448 5432 5416 5400 5384 5368 5352 5336 5320 5304 5288 5272 5256 5240 5224 5208 5192 5176 5160 5144 5128 5112 5096 5080 5064 5048 5032 5016 5000 4984 4968 4952 4936 4920 4904 4888 4872 4856 4840 4824 4808 4792 4776 4760 4744 4728 4712 4696 4680 4664 4648 4632 4616 4600 4584 4568 4552 4536 4520 4504 4488 4472 4456 4440 4424 4408 4392 4376 4360 4344 4328 4312 4296 4280 4264 4248 4232 4216 4200 4184 4168 4152 4136 4120 4104 4088 4072 4056 4040 4024 4008 3992 3976 3960 3944 3928 3912 3896 3880 3864 3848 3832 3816 3800 3784 3768 3752 3736 3720 3704 3688 3672 3656 3640 3624 3608 3592 3576 3560 3544 3528 3512 3496 3480 3464 3448 3432 3416 3400 3384 3368 3352 3336 3320 3304 3288 3272 3256 3240 3224 3208 3192 3176 3160 3144 3128 3112 3096 3080 3064 3048 3032 3016 3000 2984 2968 2952 2936 2920 2904 2888 2872 2856 2840 2824 2808 2792 2776 2760 2744 2728 2712 2696 2680 2664 2648 2632 2616 2600 2584 2568 2552 2536 2520 2504 2488 2472 2456 2440 2424 2408 2392 2376 2360 2344 2328 2312 2296 2280 2264 2248 2232 2216 2200 2184 2168 2152 2136 2120 2104 2088 2072 2056 2040 2024 2008 1992 1976 1960 1944 1928 1912 1896 1880 1864 1848 1832 1816 1800 1784 1768 1752 1736 1720 1704 1688 1672 1656 1640 1624 1608 1592 1576 1560 1544 1528 1512 1496 1480 1464 1448 1432 1416 1400 1384 1368 1352 1336 1320 1304 1288 1272 1256 1240 1224 1208 1192 1176 1160 1144 1128 1112 1096 1080 1064 1048 1032 1016 1000 984 968 952 936 920 904 888 872 856 840 824 808 792 776 760 744 728 712 696 680 664 648 632 616 600 584 568 552 536 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /
Re: [kde-freebsd] problem hal - k3b ?
* Oliver Peter, 2007-04-26 : > > My problem is the same as Beni's. Splash screen appears and hangs. > > I have to press power button to turn off and on my laptop. > > Didn't try ctrl+alt+del though. > > I have the same problem with my 7.0-CURRENT (yesterday). > If I can assist you testing or debugging drivers please drop me an > e-mail. > > FreeBSD 7.0-CURRENT i386 with k3b-1.0_1 / hal-0.5.8.20070403_1 This looks similar to kern/112119, which is fixed by rev. 1.52 of sys/dev/ata/atapi-cam.c, committed today on HEAD. Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
* Ganbold, 2007-04-30 : > Scott, Thomas, thank you very much for the effort fixing this problem. > k3b starts fine with this patch. Thanks for your feedback. The fix has been committed on HEAD. Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
* Scott Long, 2007-04-27 :
> Oh hell, I know exactly what the problem is! The opcode for a
> TEST_UNIT_READY is 0x00. This is probably the command that is
> generating the CHECK_CONDITION. The test for saved_cmd is entirely
> bogus.
H. Looks like a very plausible culprit. Good catch Scott!
(I felt there had to be something wrong when I wrote that test,
incidentally, precisely because of TEST_UNIT_READY).
Nikolay, Ganbold, (and others), here's another patch against 1.42.2.3,
please let me know if it works for you.
Thomas.
Index: atapi-cam.c
===
RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.50
diff -u -r1.50 atapi-cam.c
--- atapi-cam.c 14 Mar 2007 01:59:00 - 1.50
+++ atapi-cam.c 27 Apr 2007 19:26:09 -
@@ -729,7 +743,7 @@
* issued a REQUEST SENSE automatically and that operation
* returned without error.
*/
- if (request->u.atapi.saved_cmd != 0 && request->error == 0) {
+ if (request->u.atapi.sense.key != 0 && request->error == 0) {
bcopy (&request->u.atapi.sense, &csio->sense_data,
sizeof(struct atapi_sense));
csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/112119: system hangs when starts k3b on RELENG_6
* Ganbold.TS, 2007-04-27 :
> I tried your patch at
> http://www.freebsd.org/cgi/query-pr.cgi?pr=103602&getpatch=12 and the
> problem is still the same. Ssytem freezes upon start of k3b.
>
> I also tried your attached patch, which reverts part of rev. 1.42.2.3
> and the problem is still the same, system hangs when starts k3b.
Thanks, that's useful info. Please try the attached patch instead, which
reverts another part of 1.42.2.3 (I'm trying to figure out exactly
*which* part of this change is causing the problem).
Also, were you able to capture system console output at the point where
the crash occurs? We might have some indications there.
Thomas.
Index: atapi-cam.c
===
RCS file: /space/mirror/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.42.2.3
retrieving revision 1.42.2.2
diff -u -r1.42.2.3 -r1.42.2.2
--- atapi-cam.c 29 Mar 2007 20:08:32 - 1.42.2.3
+++ atapi-cam.c 6 Mar 2007 16:56:50 - 1.42.2.2
@@ -697,39 +680,32 @@
csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
} else if (request->result != 0) {
- if ((request->flags & ATA_R_TIMEOUT) != 0) {
- rc = CAM_CMD_TIMEOUT;
- } else {
- rc = CAM_SCSI_STATUS_ERROR;
- csio->scsi_status = SCSI_STATUS_CHECK_COND;
+ rc = CAM_SCSI_STATUS_ERROR;
+ csio->scsi_status = SCSI_STATUS_CHECK_COND;
- if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) {
+ if ((csio->ccb_h.flags & CAM_DIS_AUTOSENSE) == 0) {
#if 0
- static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
- sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
- 0, 0, 0, 0, 0 };
-
- bcopy (ccb, request->u.atapi.ccb, sizeof ccb);
- request->data = (caddr_t)&csio->sense_data;
- request->bytecount = sizeof(struct atapi_sense);
- request->transfersize = min(request->bytecount, 65534);
- request->timeout = csio->ccb_h.timeout / 1000;
- request->retries = 2;
- request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE;
- hcb->flags |= AUTOSENSE;
+ static const int8_t ccb[16] = { ATAPI_REQUEST_SENSE, 0, 0, 0,
+ sizeof(struct atapi_sense), 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0 };
+
+ bcopy (ccb, request->u.atapi.ccb, sizeof ccb);
+ request->data = (caddr_t)&csio->sense_data;
+ request->bytecount = sizeof(struct atapi_sense);
+ request->transfersize = min(request->bytecount, 65534);
+ request->timeout = csio->ccb_h.timeout / 1000;
+ request->retries = 2;
+ request->flags = ATA_R_QUIET|ATA_R_ATAPI|ATA_R_IMMEDIATE;
+ hcb->flags |= AUTOSENSE;
- ata_queue_request(request);
- return;
+ ata_queue_request(request);
+ return;
#else
- /*
-* Use auto-sense data from the ATA layer, if it has
-* issued a REQUEST SENSE automatically and that operation
-* returned without error.
-*/
- if (request->u.atapi.saved_cmd != 0 && request->error == 0) {
- bcopy (&request->u.atapi.sense, &csio->sense_data,
sizeof(struct atapi_sense));
- csio->ccb_h.status |= CAM_AUTOSNS_VALID;
- }
+ /* The ATA driver has already requested sense for us. */
+ if (request->error == 0) {
+ /* The ATA autosense suceeded. */
+ bcopy (&request->u.atapi.sense, &csio->sense_data,
sizeof(struct atapi_sense));
+ csio->ccb_h.status |= CAM_AUTOSNS_VALID;
}
#endif
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: k3b problem
* Ganbold, 2007-04-25 : > With this revision of atapi-cam.c k3b application hangs on splash screen > and I had to use power button only to restart the machine. I am confused. Is your *application* hanging, or is the *whole system* hanging? In either case nothing can be said on this problem without at least the following information: * complete boot -v output * backtrace of the point where the system hangs Also, it would be really helpful to open a proper PR in GNATS rather than relying on untracked discussion for the investigation of this issue. Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atapicam problem
* [EMAIL PROTECTED], 2006-10-26 : >Thomas, do you think this could be related to the problem I had with >atapi_cam slowing my machine down to an unuseable state? I don't think the patch I sent would change anything, it's just a plain protection against a null pointer dereference so that we can get debugging traces. With this patch you should be able to run with CAM debugging options, and from there we can hopefully diagnose the exact cause of the problems you're seeing. Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atapicam problem
* Benjamin Lutz, 2006-10-16 :
> Well, I'm having problems with that. I built a new kernel with all the
> CAM debugging options enabled (otherwise it's GENERIC), but this one
> would panic as soon as I load the atapicam module if I load it
> manually, or as soon as drive detection starts if the boot loader loads
> it. I've had a look at the dump with kgdb, and it appears that a
> null-dereference happens in line 4205 of sys/cam/cam_xpt.c: path2 is
> NULL.
OK, sorry for the delay, can you apply the attached patch and try again?
Thomas.
Index: cam_xpt.c
===
RCS file: /space/mirror/ncvs/src/sys/cam/cam_xpt.c,v
retrieving revision 1.155.2.8
diff -u -r1.155.2.8 cam_xpt.c
--- cam_xpt.c 23 Sep 2006 18:42:08 - 1.155.2.8
+++ cam_xpt.c 26 Oct 2006 09:16:07 -
@@ -4202,6 +4202,9 @@
int retval = 0;
+ if (path1 == NULL || path2 == NULL)
+ return (-1);
+
if (path1->bus != path2->bus) {
if (path1->bus->path_id == CAM_BUS_WILDCARD)
retval = 1;
pgpMd4nh8eUoS.pgp
Description: PGP signature
Re: atapicam problem
* Benjamin Lutz, 2006-10-11 : > This seems to be the exact same issue that I'm having. Since those > threads are from March 2006, and I'm running FreeBSD-6.2-PRERELEASE, it > appears that the problem has not yet been fixed, so I'd like to ask you > to have another look at it. If you need more debugging data, I'll be > happy to provide as much as I can, just tell me what you need. As I mentioned on the previous thread you quoted, I can't see anything abnormal here. Can you provide complete traces with CAM debugging options enabled? please include boot -v output. Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Fwd: Re: [Fwd: Re: Still ATAPICAM Lockup/Slowdown]]
* Adam Retter, 2006-03-30 : > Have spoken to Soren, from my bootlog he believes that the problem is in > atapicam causing the system to lock up. He is happy to answer some > questions but doesnt have time to delve into atapicam himself. OK, fair enough. Next question is, where are we spending time? It would be useful if you could enable CAM traces so we see what is going on there. Can you send me a boot -v log with the following options in your kernel config: options CAMDEBUG options CAM_DEBUG_BUS=-1 options CAM_DEBUG_TARGET=-1 options CAM_DEBUG_LUN=-1 options CAM_DEBUG_FLAGS=CAM_DEBUG_INFO|CAM_DEBUG_CDB|CAM_DEBUG_TRACE (note, this well be a VERY verbose kerne). Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still ATAPICAM Lockup/Slowdown
* Adam Retter, 2006-03-30 : > Just wandering if you received my boot output that you asked for and if > so if there is any news on solving this? Got it, did not find anything that would ring a bell, maybe the Søren has an idea? Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still ATAPICAM Lockup/Slowdown
* Adam Retter, 2006-03-22 : > For booting with or without the apaicam module compiled into the Kernel? With ATAPI/CAM would be more useful. Thanks, Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Still ATAPICAM Lockup/Slowdown
* Adam Retter, 2006-03-22 : > FreeBSD funkalicious.home.dom 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #9: > Wed Mar 22 00:31:59 GMT 2006 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/funkalicious i386 Please provide complete boot -v output. Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD binary upgrade / gmirror
* rihad, 2005-10-08 : > Now I want to do a binary upgrade to FreeBSD 5.4, but the new > sysinstall's disklabel editor only recognizes the IDE disks and does not > consider the GEOM mirror (mentioned in /etc/fstab, btw). How do I go > about this? Thanks. Did you try "gmirror load" from a sysinstall shell? Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.4-RELEASE: asr/fxp interrupt storm
When trying to upgrade a 5.2.1-REL machine to 5.4, I get an 'Interrupt storm detected on IRQ 11 fxp0 fxp1' message right after 'Waiting for SCSI devices to settle', and a freeze after that. As far as I can tell from the 5.2.1 boot messages, IRQ11 is actually allocated to the asr controller. Is this a known issue? Anything I should try? 5.2.1 dmesg output below. Thomas. Copyright (c) 1992-2004 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.2.1-RELEASE-p9 #2: Wed Sep 15 20:39:57 CEST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/RELENG_5_2/sys/MYKERNEL Preloaded elf kernel "/boot/kernel.old/kernel" at 0xc099a000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc099a270. link_elf: symbol device_get_sysctl_tree undefined KLD file acpi.ko - could not finalize loading Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) III CPU family 1266MHz (1263.45-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 1342111744 (1279 MB) avail memory = 1295372288 (1235 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 13 entries at 0xc00f3bc0 pcib1: at pcibus 1 on motherboard pci1: on pcib1 pci_cfgintr: 1:7 INTA BIOS irq 7 pci_cfgintr: 1:7 INTB BIOS irq 9 pci_cfgintr: 1:9 INTA BIOS irq 11 ahc0: port 0x2400-0x24ff mem 0xfeae-0xfeae0fff irq 7 at device 7.0 on pci1 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0x2000-0x20ff mem 0xfeaf-0xfeaf0fff irq 9 at device 7.1 on pci1 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs pcib2: at device 9.0 on pci1 pci2: on pcib2 asr0: mem 0xfa00-0xfbff irq 11 at device 9.1 on pci1 asr0: major=154 asr0: ADAPTEC 3210S FW Rev. 370F, 2 channel, 256 CCBs, Protocol I2O pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci_cfgintr: 0:3 INTA BIOS irq 10 pci_cfgintr: 0:4 INTA BIOS irq 5 pci_cfgintr: 0:12 INTA BIOS irq 11 pci_cfgintr: 0:15 INTA BIOS irq 10 fxp0: port 0x1400-0x143f mem 0xfe8a-0xfe8b,0xfe8e-0xfe8e0fff irq 10 at device 3.0 on pci0 fxp0: Ethernet address 00:03:47:f1:52:de miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0x1440-0x147f mem 0xfe86-0xfe87,0xfe88-0xfe880fff irq 5 at device 4.0 on pci0 fxp1: Ethernet address 00:03:47:f1:52:e1 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at device 12.0 (no driver attached) isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x410-0x413,0x3a0-0x3af,0-0x3,0-0x7,0-0x3,0-0x7 at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] ohci0: mem 0xfe84-0xfe840fff irq 10 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib3: at pcibus 3 on motherboard pci3: on pcib3 pci_cfgintr: 3:9 INTA BIOS irq 11 em0: port 0x3000-0x303f mem 0xfebe-0xfebf irq 11 at device 9.0 on pci3 em0: Speed:1000 Mbps Duplex:Full orm0: at iomem 0xe4000-0xe7fff,0xd1000-0xd6fff,0xcb000-0xd0fff,0xc9800-0xcafff,0xc8000-0xc97ff,0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 flags 0x10 on isa0 sio1: type 16550A, console vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 1263452498 Hz quality 800 Timecounters tick every 10.000 msec IP Filter: v3.4.31 initialized. Default = pass all, Logging = enabled Waiting 3 seconds for SCSI devices to settle GEOM: create disk da4 dp=0xc720b850 GEOM: create disk da5 dp=0xc720c450 GEOM: create disk da6 dp=0xc720d050 GEOM: create disk da7 dp=0xc7204c50 GEOM: create disk da8 dp=0xc7206850 GEOM: create disk da9 dp=0xc7207450 GEOM: create disk da0 dp=0xc7208050 GEOM: create disk da1 dp=0xc7208c50 GEOM: create disk da2 dp=0xc71fe850 GEOM: create disk da3 dp=0xc7201450 GEOM: create disk cd0 dp=0xc6f90600 pass9 at asr0 bus 0 target 6 lun 0 pass9: Fixed Processor SCSI-2 device pass11 at asr0 bus 1 target 15 lun 0 pass11: Fixed Processor SCSI-2 device da0 at asr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device
Re: UPDATE3: ATA mkIII official patches - please test!
On Tue, Mar 22, 2005 at 12:55:26PM +0100, Gary Jennejohn wrote: > > If I dont get any significant showstopper reports this is what will get > > committed to -current soon (plus what I might get done until then of new > > features). > What's with ATAPICAM? I've done some preparatory work to adapt ATAPI/CAM for mkII, which is not completed yet. I hope to have some time to work on it in early April. Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atapicam & Promise [maybe PR/73675]
* Peter Wullinger, 2004-11-17 : > additional debugging information (if somebody tells me how to get some), > test patches and the usual stuff, if anybody feels inclined to fix the > problem. Complete output from a verbose boot (boot -v at the loader prompt) would be useful. > == dmesg == > atapci0: port > 0xd800-0xd80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0 > atapci1: port > 0x8800-0x880f,0x9000-0x9003,0x9400-0x9407,0x9800-0x9803,0xa000-0xa007 mem > 0xe480-0xe4803fff irq 10 at device 11.0 on pci0 > ad0: 117800MB [239340/16/63] at ata0-master > UDMA100 > ad1: 117800MB [239340/16/63] at ata0-slave UDMA100 > acd0: DVDROM at ata1-master UDMA33 > afd0: REMOVABLE at ata1-slave BIOSPIO > acd1: CDRW at ata2-master UDMA33 > GEOM_VINUM: subdisk home.p1.s0 is up > GEOM_VINUM: subdisk home.p0.s0 is up > [...] > interrupt storm > == dmesg == The ATAPI/CAM parts are completely missing from this report. -- [EMAIL PROTECTED] pgpY5BPSEjqzV.pgp Description: PGP signature
Re: messed up /etc/gettytab
* jag, 2003-11-28 : > Would anybody post /etc/gettytab from release 4.9 You can get a fresh one from /usr/src/etc/gettytab -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apm suspend/resume panic - atapicam related
Le 2002-11-17, Christian Brueffer écrivait :
> fangorn# ata0: resetting devices .. done
> ata1: resetting devices .. ata1-slave: ATAPI identify retries exceeded
> done
OK, it looks to me like we are invalidating the param field of the
struct atadev for your ata1 slave (BTW, a complete dmesg.boot would be
useful here.
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x1
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc0155171
> stack pointer = 0x10:0xc032c8b4
> frame pointer = 0x10:0xc032c8b4
> 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 = Idle
> interrupt mask = bio
> kernel: type 12 trap, code=0
> Stopped at atapi_start+0x9:movzbw 0x1(%eax),%ax
> db> tr
> atapi_start(c15d0f50) at atapi_start+0x9
> ata_start(c15d0f00,c02ebe16,c15c3900,c03957c0,400) at ata_start+0xda
> ata_reinit(c15d0f00,c15c3900,c032c900,c01291a6,c15c3900) at ata_reinit+0x2ed
Makes sense. What I cannot entirely figure out is why this does not
happen when you disable ATAPI/CAM. Supposing that your ATAPI device
is a CD drive, do you also have atapicd in the kernel? Does the
'identify retries exceeded message' also occur when you disable
atapicam? When you disable atapicam, is atapicd enabled?
Also, it would be interesting to know whether the enclosed patch works
around the problem. It is likely to make your ata1-slave device unusable
after a suspend/resume, in which case you should then perform an
'atacontrol reinit 1' and see if it improves the situation. If you can
test this, please also do an 'atacontrol list 1' and 'camcontrol
devlist' at each step.
Thanks for taking the time to report this issue!
Thomas.
Index: ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.158
diff -u -r1.158 ata-all.c
--- ata-all.c 7 Nov 2002 22:23:46 - 1.158
+++ ata-all.c 17 Nov 2002 22:59:28 -
@@ -906,14 +906,20 @@
if (newdev & ATA_ATAPI_MASTER && !ch->device[MASTER].driver)
atapi_attach(&ch->device[MASTER]);
else if (ch->devices & (ATA_ATAPI_MASTER) && ch->device[MASTER].driver) {
- ata_getparam(&ch->device[MASTER], ATA_C_ATAPI_IDENTIFY);
- atapi_reinit(&ch->device[MASTER]);
+ if (ata_getparam(&ch->device[MASTER], ATA_C_ATAPI_IDENTIFY)) {
+ ata_printf(ch, ATA_MASTER, "ata_getparam failed\n");
+ ch->devices &= ~ATA_ATAPI_MASTER;
+ } else
+ atapi_reinit(&ch->device[MASTER]);
}
if (newdev & ATA_ATAPI_SLAVE && !ch->device[SLAVE].driver)
atapi_attach(&ch->device[SLAVE]);
else if (ch->devices & (ATA_ATAPI_SLAVE) && ch->device[SLAVE].driver) {
- ata_getparam(&ch->device[SLAVE], ATA_C_ATAPI_IDENTIFY);
- atapi_reinit(&ch->device[SLAVE]);
+ if (ata_getparam(&ch->device[SLAVE], ATA_C_ATAPI_IDENTIFY)) {
+ ata_printf(ch, ATA_SLAVE, "ata_getparam failed\n");
+ ch->devices &= ~ATA_ATAPI_SLAVE;
+ } else
+ atapi_reinit(&ch->device[SLAVE]);
}
#endif
#ifdef DEV_ATAPICAM
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: bug in daily/security?
Le 2002-11-15, Steve Watt écrivait : > cmp: EOF on /tmp/security.Gp3TTMhi3j Please see the patch to security.functions I posted on -stable yesterday. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: SCSI emulation help and patching
Le 2002-11-01, [EMAIL PROTECTED] écrivait : > NB, I had to apply the following patch in order to compile > a kernel *without* ATAPICAM; I'm not 100% sure it's the > correct patch. Indeed. Will fix, thanks. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: SCSI emulation help and patching
Le 2002-10-31, Andy Sparrow écrivait : > Yup, that's probably it. I just (re)patched my src tree after a fresh > cvsup, and this file fails to patch with atapicam-STABLE-config-20020820. > diff. Here's sys/conf/files.rej: A patch is not needed anymore: I have MFCd ATAPI/CAM on the RELENG_4 branch a few minutes ago. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ppp(8) v. 3.1 : PPPoE lqr problem.
Le 2002-10-01, Artur Pydo écrivait : > Since the end of August i had problems running my ADSL connection. > I discovered that ppp changed its behaviour regarding lqr after > the upgrade from version 2.3.3 to 3.1. This is probably a coincidence. I saw that when France Telecom changed some ADSL equipment: the new BASs indeed do not reply to LCP Echo Request frames. I have notified them of this problem several times since then, to no avail. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 2nd X server, howto?
Le 2002-07-29, stan écrivait : > I need to run a 2nd X server on my STABLE machine, so that I can use it to > display a brain dead commercial app from a remote machine. This app will > core dump, if the server has more than 256 colors, and I don't want to live > with that for normal operation. You just need to start the 2nd server on a different display: startx -- :1 It will grab the next free virtual console and display there. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: NIS server status
Le 2002-06-12, Doug Hardie écrivait : > ypbind, to not create a pid file. I have a process that periodically > checks the important server pid files and makes sure the process is > still allive. It then pages me if the process has died. That would > be really helpful for ypserv and ypbind if they would create a pid > file once they are up and running correctly. Why not use something along the line of: ps ax|grep ypserv|grep -v grep > /dev/null || ypserv from a crontab entry? -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problems with Toshiba DVD drives and cdrdao-ata
Le 2002-04-16, Herbert J. Skuhra écrivait : > Any ideas what could be the problem? This might be related to the ogle issue reported on -stable recently by Stephen Hilton. His problem also also involves a Toshiba DVD drive. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: port forward only account?
Le 2002-04-12, Rasputin écrivait :
> What's a suitable shell? It should be able to hold a session open,
> but not do anything else.
main() { for (;;) pause (); }
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Failure to attach SCSI CD burner
Le 2001-08-29, Thomas Quinot écrivait : > > Apply the attached patch in place of the one I gave you before and send the > > output when you boot. This will print out the SCSI status byte. > Thanks, applied, I'll let you know as soon as I get a chance to reboot. OK, here we are: (cd0:sym0:0:2:0): autosense is NOT valid (cd0:sym0:0:2:0): flags = 0x40 status = 0x4c (cd0:sym0:0:2:0): SCSI status = 0x8 (cd0:sym0:0:2:0): got CAM status 0x4c (cd0:sym0:0:2:0): fatal error, failed to attach to device (cd0:sym0:0:2:0): lost device (cd0:sym0:0:2:0): removing device entry Isn't that 'SCSI_STATUS_BUSY' ? Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Failure to attach SCSI CD burner
Le 2001-08-29, Kenneth D. Merry écrivait : > Apply the attached patch in place of the one I gave you before and send the > output when you boot. This will print out the SCSI status byte. Thanks, applied, I'll let you know as soon as I get a chance to reboot. > This problem is happening with a bad CD-R, right? Yes. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: OpenSSH 2.9
Le 2001-07-27, Matt Heckaman écrivait : > I'm wondering if there are any plans to MFC OpenSSH 2.9 before the release > of 4.4 and if not, is there a specific reason, or has it just not been > tested enough? Thanks :) bin/28724 is still an open issue. -- [EMAIL PROTECTED] PGP signature
Re: Recompiling -stable sysinstall
Le 2001-06-15, Thomas Quinot écrivait :
> for map in ${KEYMAPS} ; do \
> - kbdcontrol -L $$map | \
> + (cd ${.CURDIR}/../../share/syscons/keymaps; \
> + kbdcontrol -L $$map) | \
> sed -e '/^static accentmap_t/,$$d' >> keymap.tmp ; \
An alternative to this change is MFC'ing change 1.110 from the
file that now is src/usr.sbin/sysinstall/Makefile in -CURRENT:
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/Makefile,v
retrieving revision 1.109
retrieving revision 1.110
diff -u -p -r1.109 -r1.110
--- src/usr.sbin/sysinstall/Makefile2001/05/10 15:57:16 1.109
+++ src/usr.sbin/sysinstall/Makefile2001/05/12 09:19:36 1.110
@@ -1,4 +1,4 @@
-# $FreeBSD: /home/ncvs/src/usr.sbin/sysinstall/Makefile,v 1.109 2001/05/10 15:
57:16 sobomax Exp $
+# $FreeBSD: /home/ncvs/src/usr.sbin/sysinstall/Makefile,v 1.110 2001/05/12 09:
19:36 sobomax Exp $
PROG= sysinstall
MAN= sysinstall.8
@@ -84,7 +84,8 @@ KEYMAPS= be.iso br275.iso danish.iso fin
keymap.h:
rm -f keymap.tmp
for map in ${KEYMAPS} ; do \
- kbdcontrol -L $$map | \
+ env KEYMAP_PATH=${.CURDIR}/../../share/syscons/keymaps \
+ kbdcontrol -L $$map | \
sed -e '/^static accentmap_t/,$$d' >> keymap.tmp ; \
done
echo "static struct keymapInfo keymapInfos[] = {" >> keymap.tmp
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Recompiling -stable sysinstall
Hi all,
Trying to resolve a sysinstall problem (PR kern/24596), I endeavoured
to recompile sysinstall. My source tree was cvsupped yesterday, and
I have made a buildworld and buildkernel, but not installworld yet.
Sysinstall failed to compile, because its Makefile assumes that the
installed syscons keymaps match the source tree version (which was not
the case because my previous make world did not include the Ukrainian
keymaps).
I do not know whether sysinstall should be comilable when world has
been built but not yet installed. If so the following patch resolves
this problem (it uses the source tree keymaps instead of the installed
ones):
--- release/sysinstall/Makefile.distThu Jun 14 21:55:05 2001
+++ release/sysinstall/Makefile Fri Jun 15 14:52:04 2001
@@ -87,7 +87,8 @@
keymap.h:
rm -f keymap.tmp
for map in ${KEYMAPS} ; do \
- kbdcontrol -L $$map | \
+ (cd ${.CURDIR}/../../share/syscons/keymaps; \
+ kbdcontrol -L $$map) | \
sed -e '/^static accentmap_t/,$$d' >> keymap.tmp ; \
done
echo "static struct keymapInfo keymapInfos[] = {" >> keymap.tmp
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: XF86 4 on 4.3-RELEASE?
Le 2001-03-09, Irvine Short écrivait : > XF86 4 on 4.3-RELEASE? > Anyone know if this will be the case? The XFree 4 port already builds and works flawlessly on 4.2-STABLE. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Userland PPP hanging instead of terminating
I am using pptpclient with the userland PPP daemon, and have been occasionally encountering the following situation: * for some reason, the data link layer (here, a PPTP tunnel) goes down; * ppp closes the LCP... * ...but the PPP process hangs indefinitely rather than terminating. Here is an excerpt of ppp.log: Mar 4 22:40:14 melusine ppp[19179]: tun0: Phase: deflink: Disconnected! Mar 4 22:40:14 melusine ppp[19179]: tun0: Phase: deflink: Connect time: 105 sec s: 931 octets in, 1214 octets out Mar 4 22:40:14 melusine ppp[19179]: tun0: Phase: deflink: : 13 packets in, 38 p ackets out Mar 4 22:40:14 melusine ppp[19179]: tun0: Phase: total 20 bytes/sec, peak 97 b ytes/sec on Sun Mar 4 22:40:14 2001 Mar 4 22:40:14 melusine ppp[19179]: tun0: Phase: deflink: lcp -> closed Mar 4 22:40:14 melusine ppp[19179]: tun0: Phase: bundle: Dead The next line should be a tun0: Phase: PPP Terminated (normal). but this does not occur, and pid 19179 is hanging, blocked in a tunread that won't return. Is this a known problem? I have observed this behaviour on a 4.2-STABLE system. Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
