Re: savecore: first and last dump headers disagree on /dev/ad0b
On 2003/10/07 18:11:30, Doug White wrote: On Tue, 7 Oct 2003, YONETANI Tomokazu wrote: The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33 controller, to which the IDE disk is attached. The size of the IDE hard disk is 4Gbytes, and the size of the kernel dump and physical memory both fits in that size. The ROSB4 is known to have data-corruption problems with running in UDMA mode. The dump is probably tripping over this, which is why Tor's patch works since it demotes the device back to PIO. You could optionally set hw.ata.ata_dma=0 in loader.conf to disable UDMA rather than apply the patch. Yes, setting hw.ata.ata_dma=0 allowed me to dump a usable core file. Thanks. -- YONETANI Tomokazu / Ergo-Brains Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: savecore: first and last dump headers disagree on /dev/ad0b
On Tue, 7 Oct 2003, Kris Kennaway wrote: On Tue, Oct 07, 2003 at 06:11:30PM -0700, Doug White wrote: On Tue, 7 Oct 2003, YONETANI Tomokazu wrote: The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33 controller, to which the IDE disk is attached. The size of the IDE hard disk is 4Gbytes, and the size of the kernel dump and physical memory both fits in that size. The ROSB4 is known to have data-corruption problems with running in UDMA mode. The dump is probably tripping over this, which is why Tor's patch works since it demotes the device back to PIO. I also had problems dumping onto a UDMA66 disk on a promise PDC20267 controller - it seemed to dump OK (dump was readable after I recovered the disk), but it (or maybe the crash itself) trashed the partition table. Well that woudl be funny since the problem boards were replaced with Tyan S2518s, which have a PDC20267 onboard as well as the ROSB4. The disks were attached to the Promise, and never had any data corruption issues with them, at least under linnex. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: savecore: first and last dump headers disagree on /dev/ad0b
On Wed, Oct 08, 2003 at 07:05:49PM -0700, Doug White wrote: The ROSB4 is known to have data-corruption problems with running in UDMA mode. The dump is probably tripping over this, which is why Tor's patch works since it demotes the device back to PIO. I also had problems dumping onto a UDMA66 disk on a promise PDC20267 controller - it seemed to dump OK (dump was readable after I recovered the disk), but it (or maybe the crash itself) trashed the partition table. Well that woudl be funny since the problem boards were replaced with Tyan S2518s, which have a PDC20267 onboard as well as the ROSB4. The disks were attached to the Promise, and never had any data corruption issues with them, at least under linnex. This is a FreeBSD bug that was introduced within the past few months, perhaps with ATAng. Kris pgp0.pgp Description: PGP signature
Re: savecore: first and last dump headers disagree on /dev/ad0b
Hello.
-CURRENT as of yesterday can't save kernel dump:
savecore: first and last dump headers disagree on /dev/ad0b
savecore: unsaved dumps found but not saved
Is this a known issue?
Yes.
I had the same problem on my development machine at the end of August and
ended up using the enclosed patch to get working dumps.
- Tor Egge
Index: sys/dev/ata/ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.187
diff -u -r1.187 ata-all.c
--- sys/dev/ata/ata-all.c 27 Aug 2003 15:27:56 - 1.187
+++ sys/dev/ata/ata-all.c 31 Aug 2003 22:31:33 -
@@ -109,9 +109,11 @@
ch-device[MASTER].channel = ch;
ch-device[MASTER].unit = ATA_MASTER;
ch-device[MASTER].mode = ATA_PIO;
+ch-device[MASTER].dumping = 0;
ch-device[SLAVE].channel = ch;
ch-device[SLAVE].unit = ATA_SLAVE;
ch-device[SLAVE].mode = ATA_PIO;
+ch-device[SLAVE].dumping = 0;
ch-dev = dev;
ch-state = ATA_IDLE;
bzero(ch-queue_mtx, sizeof(struct mtx));
Index: sys/dev/ata/ata-all.h
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.h,v
retrieving revision 1.65
diff -u -r1.65 ata-all.h
--- sys/dev/ata/ata-all.h 25 Aug 2003 11:13:04 - 1.65
+++ sys/dev/ata/ata-all.h 31 Aug 2003 22:56:14 -
@@ -227,6 +227,7 @@
intcmd;/* last cmd executed */
intmode; /* transfermode */
+intdumping;/* panic dump in progress */
void (*setmode)(struct ata_device *atadev, int mode);
};
Index: sys/dev/ata/ata-disk.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.159
diff -u -r1.159 ata-disk.c
--- sys/dev/ata/ata-disk.c 25 Aug 2003 09:01:49 - 1.159
+++ sys/dev/ata/ata-disk.c 31 Aug 2003 23:18:40 -
@@ -336,6 +336,26 @@
if (!adp)
return ENXIO;
+/* Some chipsets must be configured for PIO before dump starts. */
+if (adp-device-dumping == 0) {
+ adp-device-dumping = 1;
+ adp-device-setmode(adp-device, ATA_PIO_MAX);
+}
+if (length == 0) {
+ int error = 0;
+ /* Commit dump to media */
+ if (adp-device-param != NULL
+ adp-device-param-support.command2 ATA_SUPPORT_FLUSHCACHE) {
+ error = ata_controlcmd(adp-device, ATA_FLUSHCACHE, 0, 0, 0);
+ if (error != 0)
+ ata_prtdev(adp-device, Flush cache failed\n);
+ else
+ ata_prtdev(adp-device, Flush cache succeeded\n);
+ } else
+ ata_prtdev(adp-device, Flush cache skipped\n);
+ return error;
+}
+
bzero(request, sizeof(struct ata_request));
request.device = adp-device;
request.data = virtual;
@@ -352,13 +372,15 @@
if (adp-device-channel-hw.transaction(request) == ATA_OP_FINISHED)
return EIO;
-while (request.bytecount request.donecount) {
+while (adp-device-channel-running == request) {
DELAY(20);
- adp-device-channel-running = request;
adp-device-channel-hw.interrupt(adp-device-channel);
- adp-device-channel-running = NULL;
if (request.status ATA_S_ERROR)
return EIO;
+}
+if (request.bytecount request.donecount) {
+ printf(Short write?);
+ return EIO;
}
return 0;
}
Index: sys/dev/ata/ata-queue.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-queue.c,v
retrieving revision 1.4
diff -u -r1.4 ata-queue.c
--- sys/dev/ata/ata-queue.c 28 Aug 2003 08:22:53 - 1.4
+++ sys/dev/ata/ata-queue.c 31 Aug 2003 22:35:30 -
@@ -106,9 +106,36 @@
ata_controlcmd(struct ata_device *atadev, u_int8_t command, u_int16_t feature,
u_int64_t lba, u_int16_t count)
{
-struct ata_request *request = ata_alloc_request();
+struct ata_request *request;
int error = ENOMEM;
+/* Handle calls from addump */
+if (atadev-dumping) {
+ struct ata_request request2;
+ request = request2;
+ bzero(request, sizeof(struct ata_request));
+ request-device = atadev;
+ request-u.ata.command = command;
+ request-u.ata.lba = lba;
+ request-u.ata.count = count;
+ request-u.ata.feature = feature;
+ request-flags = ATA_R_CONTROL;
+ request-timeout = 5;
+ if (atadev-channel-hw.transaction(request) ==
+ ATA_OP_CONTINUES) {
+ while (atadev-channel-running == request
+ (request-status ATA_S_ERROR) == 0) {
+ DELAY(20);
+ atadev-channel-hw.interrupt(atadev-channel);
+ }
+ }
+ error = request-result;
+ if ((request-status
Re: savecore: first and last dump headers disagree on /dev/ad0b
On Tue, 7 Oct 2003, YONETANI Tomokazu wrote: The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33 controller, to which the IDE disk is attached. The size of the IDE hard disk is 4Gbytes, and the size of the kernel dump and physical memory both fits in that size. The ROSB4 is known to have data-corruption problems with running in UDMA mode. The dump is probably tripping over this, which is why Tor's patch works since it demotes the device back to PIO. You could optionally set hw.ata.ata_dma=0 in loader.conf to disable UDMA rather than apply the patch. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: savecore: first and last dump headers disagree on /dev/ad0b
On Tue, Oct 07, 2003 at 06:11:30PM -0700, Doug White wrote: On Tue, 7 Oct 2003, YONETANI Tomokazu wrote: The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33 controller, to which the IDE disk is attached. The size of the IDE hard disk is 4Gbytes, and the size of the kernel dump and physical memory both fits in that size. The ROSB4 is known to have data-corruption problems with running in UDMA mode. The dump is probably tripping over this, which is why Tor's patch works since it demotes the device back to PIO. I also had problems dumping onto a UDMA66 disk on a promise PDC20267 controller - it seemed to dump OK (dump was readable after I recovered the disk), but it (or maybe the crash itself) trashed the partition table. Kris pgp0.pgp Description: PGP signature
Re: savecore: first and last dump headers disagree on /dev/ad0b
On Tue, 7 Oct 2003, Kris Kennaway wrote: I also had problems dumping onto a UDMA66 disk on a promise PDC20267 controller - it seemed to dump OK (dump was readable after I recovered the disk), but it (or maybe the crash itself) trashed the partition table. Kris I mentioned the very same problem last June in a few posts here. I guess no one else experienced this issue, or there would have been some kind of response. In fact, I haven't been able to recover a crashdump since I switched over to current at the beginning of the year. I have a promise PDC20269 UDMA133 and a Maxtor 60G. More recently, though, sometime in mid September, a panic and crash dump trash my partition table as well. And it's repeatable, but I'm not going to try again to see if it was fixed :) -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
savecore: first and last dump headers disagree on /dev/ad0b
Hello. -CURRENT as of yesterday can't save kernel dump: savecore: first and last dump headers disagree on /dev/ad0b savecore: unsaved dumps found but not saved Is this a known issue? I need to be able to dump to this device because I've seen reliably reproducible panics to be reported, and saving kernel dumps is not supported by ips(4). /dev/ad0 is an IDE hard disk capable of UDMA33 and dedicated to saving kernel dumps, and is not used as a swap device, so I think misc/55933 is not relavant. How can I force it to save the kernel dump; I've tried -f optition, but it didn't work. I've seen no odd messages while it's dumping, just the numbers counted up from 16 to 512. The hardware is IBM NetFinity 6000R, and it has ServerWorks ROSB4 UDMA33 controller, to which the IDE disk is attached. The size of the IDE hard disk is 4Gbytes, and the size of the kernel dump and physical memory both fits in that size. Please tell me if I missed any information you need. Regards. -- YONETANI Tomokazu / Ergo-Brains Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
