Re: infinite loop when copying to ext2fs

2008-03-01 Thread Jakub Siroky
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

2008-01-20 Thread Jakub Siroky
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

2008-01-20 Thread Jakub Siroky
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

2008-01-20 Thread Jakub Siroky
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?

2008-01-20 Thread Jakub Siroky
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

2008-01-19 Thread Jakub Siroky
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

2008-01-19 Thread Jakub Siroky
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

2008-01-18 Thread Jakub Siroky
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?

2008-01-18 Thread Jakub Siroky
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]