Re: infinite loop when copying to ext2fs
I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I did not noticed it before because I started using ext2fs extensively some months ago. Regards, Jakub On Sat, 19 Jan 2008 16:44:34 +0100 Kris Kennaway [EMAIL PROTECTED] wrote: Kris Kennaway wrote: Jakub Siroky wrote: I have two large ext2fs partitions (368 and 313GB) to hold data shared between several OSes. While there were no problems on 6-STABLE branch I was quite disappointed after upgrade to 7-STABLE. Whenever I copy/write to ext2fs partition the system freezes totally without crashdump. So I set debugging settings to kernel config (DEBUG,WITNESS,..) and in console I reproduced error situation ending with full screen of unstoppable running text with lot of memory addresses and a few recognisable words: 'new block bit set for ext already' - again with no crashdump. Then I have formatted 1GB partition with ext2fs and the problem on this small partition appears only sometimes. OK, I am able to reproduce this. Kris Is anyone able to look at this? I could not spot a candidate change that has not been merged to 6.x. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch for review: ATI SB600 SATA AHCI
Hello, I've been using these patches for some time with success. Although slight correction to patches is needed - code placement changed a bit (in case of line wrapping, see the attachments). --- ata-chipset.c.orig Mon Oct 9 23:01:35 2006 +++ ata-chipset.c Wed Sep 5 22:08:02 2007 @@ -1239,12 +1239,16 @@ struct ata_pci_controller *ctlr = device_get_softc(dev); struct ata_chip_id *idx; static struct ata_chip_id ids[] = -{{ ATA_ATI_IXP200,0x00, 0,0, ATA_UDMA5, IXP200 }, - { ATA_ATI_IXP300,0x00, 0,0, ATA_UDMA6, IXP300 }, - { ATA_ATI_IXP400,0x00, 0,0, ATA_UDMA6, IXP400 }, - { ATA_ATI_IXP300_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP300 }, - { ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, - { ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, +{{ ATA_ATI_IXP200,0x00, 0,0, ATA_UDMA5, IXP200 }, + { ATA_ATI_IXP300,0x00, 0,0, ATA_UDMA6, IXP300 }, + { ATA_ATI_IXP400,0x00, 0,0, ATA_UDMA6, IXP400 }, + { ATA_ATI_IXP600,0x00, 0,ATISINGLE, ATA_UDMA6, IXP600 }, + { ATA_ATI_IXP700,0x00, 0,ATISINGLE, ATA_UDMA6, IXP700 }, + { ATA_ATI_IXP300_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP300 }, + { ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, + { ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, + { ATA_ATI_IXP600_S1, 0x00, 0,AHCI, ATA_SA300, IXP600 }, + { ATA_ATI_IXP700_S1, 0x00, 0,AHCI, ATA_SA300, IXP700 }, { 0, 0, 0, 0, 0, 0}}; char buffer[64]; @@ -1271,6 +1275,18 @@ if (ata_setup_interrupt(dev)) return ENXIO; + +if (ctlr-chip-cfg2 AHCI) { + ctlr-r_rid2 = PCIR_BAR(5); + ctlr-r_type2 = SYS_RES_MEMORY; + if ((ctlr-r_res2 = bus_alloc_resource_any(dev, ctlr-r_type2, + ctlr-r_rid2, + RF_ACTIVE))) + return ata_ahci_chipinit(dev); +} + +if (ctlr-chip-cfg2 ATISINGLE) + ctlr-channels = 1; ctlr-setmode = ata_ati_setmode; return 0; -- ata-pci.h.orig Sat Sep 30 21:51:49 2006 +++ ata-pci.h Wed Sep 5 22:00:21 2007 @@ -102,6 +102,10 @@ #define ATA_ATI_IXP300_S1 0x436e1002 #define ATA_ATI_IXP400_S1 0x43791002 #define ATA_ATI_IXP400_S2 0x437a1002 +#define ATA_ATI_IXP600_S1 0x43801002 +#define ATA_ATI_IXP600 0x438c1002 +#define ATA_ATI_IXP700_S1 0x43901002 +#define ATA_ATI_IXP700 0x439c1002 #define ATA_CENATEK_ID 0x16ca #define ATA_CENATEK_ROCKET 0x000116ca @@ -415,6 +419,7 @@ #define VIABUG 0x0200 #define VIABAR 0x0400 #define VIAAHCI 0x0800 +#define ATISINGLE 0x1000 On Sun, 20 Jan 2008 04:13:34 +0100 Volker [EMAIL PROTECTED] wrote: Hi! I've done the following local changes to get the ATA controller being correctly detected and initialized as an AHCI controller on an HP 6715b notebook using ATI SB-600 chipset. With stock kernel, the ATA controller is being recognized as a generic ATA controller and devices being driven in UDMA-33 mode. With the following patch, the controller is being initialized in AHCI mode and devices being set to SATA-150/300 mode. atapci0: ATI IXP600 SATA300 controller port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x5020 atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xd0609000 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected %atacontrol mode ad4 current mode = SATA150 My patch has been tested on RELENG_7 as of 2008-01-19. Please review, check and test if possible. Should work on 8-CURRENT, too. If nobody complains until tuesday (2008-01-22), I'll file a PR for that patch. Volker --- sys/dev/ata/ata-chipset.c.orig 2008-01-20 03:22:37.0 +0100 +++ sys/dev/ata/ata-chipset.c 2008-01-20 03:30:03.0 +0100 @@ -1348,6 +1348,7 @@ { ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, { ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, { ATA_ATI_IXP600,0x00, 0,0, ATA_UDMA6, IXP600 }, + { ATA_ATI_IXP600_S1, 0x00, 0, AHCI, ATA_SA300, IXP600 }, { ATA_ATI_IXP700,0x00, 0,0, ATA_UDMA6, IXP700 }, { 0, 0, 0, 0, 0, 0}}; @@ -1360,7 +1361,10 @@ if (ctlr-chip-cfg1 SIIMEMIO) ctlr-chipinit = ata_sii_chipinit; else - ctlr-chipinit = ata_ati_chipinit; + if (ctlr-chip-cfg2 AHCI) + ctlr-chipinit = ata_ahci_chipinit; + else + ctlr-chipinit = ata_ati_chipinit; return 0; } --- sys/dev/ata/ata-pci.h.orig 2008-01-20 03:22:28.0 +0100
Re: patch for review: ATI SB600 SATA AHCI
Yes, maybe this is the same patch you've mentioned. In RELENG_7_0 I had to manually update concerned files - look up the lines and add the information at proper place. I don't understand the meaning of functions besides chipset static definitions, but it has been working on 6.2-STABLE and RELENG_7_0 without problems. On Sun, 20 Jan 2008 17:54:40 +0100 Volker [EMAIL PROTECTED] wrote: On 12/23/-58 20:59, Jakub Siroky wrote: Hello, I've been using these patches for some time with success. Although slight correction to patches is needed - code placement changed a bit (in case of line wrapping, see the attachments). --- ata-chipset.c.orig Mon Oct 9 23:01:35 2006 +++ ata-chipset.c Wed Sep 5 22:08:02 2007 @@ -1239,12 +1239,16 @@ struct ata_pci_controller *ctlr = device_get_softc(dev); struct ata_chip_id *idx; static struct ata_chip_id ids[] = -{{ ATA_ATI_IXP200,0x00, 0,0, ATA_UDMA5, IXP200 }, - { ATA_ATI_IXP300,0x00, 0,0, ATA_UDMA6, IXP300 }, - { ATA_ATI_IXP400,0x00, 0,0, ATA_UDMA6, IXP400 }, - { ATA_ATI_IXP300_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP300 }, - { ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, - { ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, +{{ ATA_ATI_IXP200,0x00, 0,0, ATA_UDMA5, IXP200 }, + { ATA_ATI_IXP300,0x00, 0,0, ATA_UDMA6, IXP300 }, + { ATA_ATI_IXP400,0x00, 0,0, ATA_UDMA6, IXP400 }, + { ATA_ATI_IXP600,0x00, 0,ATISINGLE, ATA_UDMA6, IXP600 }, + { ATA_ATI_IXP700,0x00, 0,ATISINGLE, ATA_UDMA6, IXP700 }, + { ATA_ATI_IXP300_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP300 }, + { ATA_ATI_IXP400_S1, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, + { ATA_ATI_IXP400_S2, 0x00, SIIMEMIO, 0, ATA_SA150, IXP400 }, + { ATA_ATI_IXP600_S1, 0x00, 0,AHCI, ATA_SA300, IXP600 }, + { ATA_ATI_IXP700_S1, 0x00, 0,AHCI, ATA_SA300, IXP700 }, { 0, 0, 0, 0, 0, 0}}; char buffer[64]; @@ -1271,6 +1275,18 @@ if (ata_setup_interrupt(dev)) return ENXIO; + +if (ctlr-chip-cfg2 AHCI) { + ctlr-r_rid2 = PCIR_BAR(5); + ctlr-r_type2 = SYS_RES_MEMORY; + if ((ctlr-r_res2 = bus_alloc_resource_any(dev, ctlr-r_type2, + ctlr-r_rid2, + RF_ACTIVE))) + return ata_ahci_chipinit(dev); +} + +if (ctlr-chip-cfg2 ATISINGLE) + ctlr-channels = 1; ctlr-setmode = ata_ati_setmode; return 0; -- ata-pci.h.orig Sat Sep 30 21:51:49 2006 +++ ata-pci.h Wed Sep 5 22:00:21 2007 @@ -102,6 +102,10 @@ #define ATA_ATI_IXP300_S1 0x436e1002 #define ATA_ATI_IXP400_S1 0x43791002 #define ATA_ATI_IXP400_S2 0x437a1002 +#define ATA_ATI_IXP600_S1 0x43801002 +#define ATA_ATI_IXP600 0x438c1002 +#define ATA_ATI_IXP700_S1 0x43901002 +#define ATA_ATI_IXP700 0x439c1002 #define ATA_CENATEK_ID 0x16ca #define ATA_CENATEK_ROCKET 0x000116ca @@ -415,6 +419,7 @@ #define VIABUG 0x0200 #define VIABAR 0x0400 #define VIAAHCI 0x0800 +#define ATISINGLE 0x1000 Jakub, I think your patch is against old code before the ATA code has been restructured. I've tried a similar patch (provided by Coleman Kane) against recent RELENG_7 but applying the patch failed. That has been the reason for me to write a new patch (at least for the chipset my notebook is using, as I don't know much about other chipsets). I've just been unsure whether or not calling ata_ahci_init is everything what is required for proper chip initialization or not but from what I was reading out of the current code, other functions don't do much more. I may include other chipset changes (from your patch) and send a new patch if my patch does not miss anything for proper operation. At least the codes changes work here for me (or I haven't noticed anything bad). @sos: can you comment on this? Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch for review: ATI SB600 SATA AHCI
Just my info: dmesg| grep ata atapci0: ATI AHCI controller port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] ata4: ATA channel 2 on atapci0 ata4: [ITHREAD] ata5: ATA channel 3 on atapci0 ata5: [ITHREAD] atapci1: ATI IXP600 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf900-0xf90f at device 20.1 on pci0 ata0: ATA channel 0 on atapci1 ata0: [ITHREAD] acd0: DVDR LITE-ON DVDRW LH-18A1H/HL03 at ata0-master UDMA33 acd1: DVDROM TOSHIBA DVD-ROM SDM2012C/TU01 at ata0-slave UDMA33 ad4: 381553MB WDC WD4000YS-01MPB1 09.02E09 at ata2-master SATA300 ad8: 476940MB WDC WD5000YS-01MPB1 09.02E09 at ata4-master SATA300 atacontrol mode ad4: current mode = SATA300 uname -a: FreeBSD dev.citybikes.cz 7.0-RC1 FreeBSD 7.0-RC1 #4: Sun Jan 20 01:33:16 CET 2008 [EMAIL PROTECTED]:/usr/build/obj/usr/build/src_releng_7_0/sys/TWINSF amd64 lshal: system.product = 'GA-MA69G-S3H' system.vendor = 'Gigabyte Technology Co., Ltd.' On Sun, 20 Jan 2008 21:27:32 +0100 Torfinn Ingolfsen [EMAIL PROTECTED] wrote: Hello, On Sun, 20 Jan 2008 04:13:34 +0100 Volker [EMAIL PROTECTED] wrote: 6715b notebook using ATI SB-600 chipset. With stock kernel, the ATA I have a machine with an Asus M2A-VM HDMI motherboard[1], which also have this chipset. My patch has been tested on RELENG_7 as of 2008-01-19. Please review, check and test if possible. Should work on 8-CURRENT, too. I had to hand apply part of the patch (probably a whitespace problem when I copied it from the mail), but it built fine. From dmesg, before the patch: atapci0: ATI ATA controller port 0xfc00-0xfc07,0xf800-0xf803,0xf400-0xf407,0xf000-0xf003,0xec00-0xec0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] atapci1: ATI IXP600 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe400-0xe40f at device 20.1 on pci0 ata0: ATA channel 0 on atapci1 ata0: [ITHREAD] acd0: DVDR Optiarc DVD RW AD-5170A/1.12 at ata0-master UDMA66 ad4: 476940MB SAMSUNG HD501LJ CR100-12 at ata2-master UDMA33 From dmesg, after the patch: tapci0: ATI IXP600 SATA300 controller port 0xfc00-0xfc07,0xf800-0xf803,0xf400-0xf407,0xf000-0xf003,0xec00-0xec0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] ata4: ATA channel 2 on atapci0 ata4: [ITHREAD] ata5: ATA channel 3 on atapci0 ata5: [ITHREAD] atapci1: ATI IXP600 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe400-0xe40f at device 20.1 on pci0 ata0: ATA channel 0 on atapci1 ata0: [ITHREAD] acd0: DVDR Optiarc DVD RW AD-5170A/1.12 at ata0-master UDMA66 ad4: 476940MB SAMSUNG HD501LJ CR100-12 at ata2-master SATA300 I haven't done any tests to see if it changes performance in any way, at least it reports SATA 300: [EMAIL PROTECTED] atacontrol mode ad4 current mode = SATA300 This is on: [EMAIL PROTECTED] uname -a FreeBSD kg-vm.kg4.no 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #4: Sun Jan 20 19:27:36 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 References: 1) info about my machine http://tingox.googlepages.com/asus_m2a-vm_hdmi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_7, RELENG_7_0, RELENG_7_BP, RELENG_7_0_BP - difference?
I should probably know that, but: what's the difference between these branches? Thanks Jakub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic when copying to ext2fs
I have tried these options in the config, but with same results (unstoppable dump and crash): makeoptions DEBUG=-g options WITNESS options WITNESS_KDB options KDB options KDB_TRACE options DIAGNOSTIC options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options DEBUG_LOCKS options DEBUG_VFS_LOCKS I haven't tried debugging via serial port, however. And the problem can be reproduced on ext2fs volume of any size. Next step would be original GENERIC config. Jakub On Sat, 19 Jan 2008 00:12:18 +0100 Kris Kennaway [EMAIL PROTECTED] wrote: Jakub Siroky wrote: I have two large ext2fs partitions (368 and 313GB) to hold data shared between several OSes. While there were no problems on 6-STABLE branch I was quite disappointed after upgrade to 7-STABLE. Whenever I copy/write to ext2fs partition the system freezes totally without crashdump. So I set debugging settings to kernel config (DEBUG,WITNESS,..) and in console I reproduced error situation ending with full screen of unstoppable running text with lot of memory addresses and a few recognisable words: 'new block bit set for ext already' - again with no crashdump. Then I have formatted 1GB partition with ext2fs and the problem on this small partition appears only sometimes. 1) Please wrap your lines so your emails can be easily read. 2) Check the developer's handbook, it explains how to configure the debugger so you can investigate this further. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic when copying to ext2fs
No, I cannot. While in normal operation the Ctrl+Alt+Esc on console brings debugger screen, in this crash condition even the NumLock does not work. Jakub On Sat, 19 Jan 2008 14:52:08 +0100 Kris Kennaway [EMAIL PROTECTED] wrote: Jakub Siroky wrote: I have tried these options in the config, but with same results (unstoppable dump and crash): makeoptions DEBUG=-g options WITNESS options WITNESS_KDB options KDB options KDB_TRACE options DIAGNOSTIC options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options DEBUG_LOCKS options DEBUG_VFS_LOCKS I haven't tried debugging via serial port, however. And the problem can be reproduced on ext2fs volume of any size. Next step would be original GENERIC config. What do you mean by unstoppable? Can you not break to DDB from the console? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic when copying to ext2fs
I have two large ext2fs partitions (368 and 313GB) to hold data shared between several OSes. While there were no problems on 6-STABLE branch I was quite disappointed after upgrade to 7-STABLE. Whenever I copy/write to ext2fs partition the system freezes totally without crashdump. So I set debugging settings to kernel config (DEBUG,WITNESS,..) and in console I reproduced error situation ending with full screen of unstoppable running text with lot of memory addresses and a few recognisable words: 'new block bit set for ext already' - again with no crashdump. Then I have formatted 1GB partition with ext2fs and the problem on this small partition appears only sometimes. Thank you for reply Jakub Siroky ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: To 6.3 or to 7.0 that is the question?
Hello, please could you try to make large (hundred of GB) ext2 volume with e2fsprogs and copy large amount of data to it? On amd64 SMP (two cores) RELENG_7_0 it should lead to unrecoverable panic or scrolling strings ext2_new_block: bit already set for block %d. On 6.2-STABLE there is no problem with linux partitions. Jakub Siroky On Fri, 18 Jan 2008 16:48:28 -0500 Mike Tancsa [EMAIL PROTECTED] wrote: At 04:11 PM 1/18/2008, Steven Hartland wrote: I know 7 has had a lot of work done on locking and ULE but are there any other reasons to go for that instead of 6.3? Conversely are there any reason which would point away from 7 such as stability issues? I think it depends what apps you run, what drivers you rely on. The less esoteric your hardware is, the better the chances are that things will work well (eg. em nics vs nfe or tl etc etc). Our production experiences with 7 have been good so far. I just did a rather busy customer mail server this morning and so far so good. I migrated it from 6.3 to 7 and am just finishing the portupgrade process. We have also been running a 7.x box in our spam/virus scanning cluster since late Nov 2007 and no issues there either. We havent done any benchmarks to see if its faster than the 6.x boxes, but its certainly stable so far and seems to at least keep up to the other boxes. I am also testing a core2 and quad core box with 8 gig of RAM on a 4 port Areca controller that will replace a 6.2 postgresql server next week some time. Just doing some benchmarking/testing of that now and hope to have RELENG_7 64bit deployed next week on it if all goes as planned. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]