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: Dell PERC6?
On Fri, Jan 18, 2008 at 10:35:21AM +0100, Ferdinand Goldmann wrote: Jeremy Chadwick wrote: You'd be best off with RELENG_7 and not 6.3, but yes, the controller in question should work on RELENG_6 and RELENG_6_3. Very well, seems like I am going to give RELENG_7 a try then. Thanks to everyone who replied! Another user just posted to -stable about problems with these Dell machines and PERC6. I'm not sure if you're subscribed to -stable or not, so here's the thread: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039791.html -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
Hi, We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg00506.html I was reading the mailing list and found that some of the people are happily using this hardware with the latest FreeBSD: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039675.html I just wonder what the status of mfi driver? Maybe it's not fully tested or there will be some important fixes before 7.0 final? We are going to try different RAID combinations but it definitely not working using 6x146GB as RAID5. Maybe someone could share the RAID combinations they successfully are running on? Thanks in advance. Kind Regards, Aldas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0, ZFS and freebsd-update
Royce Williams wrote: s3raphi wrote, on 1/18/2008 12:19 PM: I am trying to run freebsd-update on 7.0-RC1 on a system with a ZFS root and am also having problems with flags: [EMAIL PROTECTED] ~]# freebsd-update install Installing updates...chflags: ///lib/libc.so.7: Operation not supported Is there a workaround for this? Since all of my filesystems on my 7.0 system are ZFS, I've been making a copy of freebsd-update with the chflag calls commented out. Since ZFS doesn't support flags yet, this is harmless. If any of your primary filesystems are not ZFS, this is not a good solution. If you go this route, you'll have to watch for changes to freebsd-update and reapply them. I expect that once ZFS is no longer considered experimental, freebsd-update will have a way to handle this. Royce Probably chflags failure should not be treated as a fatal error. NFS / would have the same failure mode. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: patch for review: ATI SB600 SATA AHCI
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]
Re: 7.0-PRERELEASE desktop system periodically freezes momentarily
Kris, Latest captures (of interest) - they're not hard to come by, it seems. I see more than a couple of these every hour at least while I'm actively doing anything on this system, and I've witnessed up to two or three times that many at times. It seems my initial glee about catching Epiphany out was unfounded. Each capture has successively shown a different process/thread with the long exclusive cpu use, and the first one I've linked to here doesn't even show any active 'running' processes for the period in question, it has evolution and xorg 'yielding' and irq14 in 'runq'. The second one shows 'xorg' with exclusive 'running' for the duration. So it's proving quite variable, and after examining more than a handful of these I'm surmising that the 'freeze' is interfering with ktr logging somehow, resulting in the loss of one or more data points and resulting in the anomalous graphs as I mentioned in my previous message. I won't strive to take any more of these for now unless you indicate that you believe it could be useful. If I happen to catch any that look of particular interest I'll post them up and send links. In the meantime I'll revert to a standard GENERIC kernel, too, to gauge how much effect running with this KTR-enabled kernel on the frequency of these events, and the mouse disconnects. I'm keen to hear your take on what you think might be going on here. http://au.dyndns.ws/public/ktr-sched-200801200302.out.bz2 http://au.dyndns.ws/public/ktr-sched-200801210207.out.bz2 Wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: bad pte
Hello!
Is this something, that should be fixed in the 6.3? The kernel is 6.2-STABLE
from June (see uptime).
Thanks!
-mi
Unread portion of the kernel message buffer:
TPTE at 0x8038 IS ZERO @ VA 7000
panic: bad pte
cpuid = 1
Uptime: 133d0h42m22s
Dumping 3583 MB (2 chunks)
chunk 0: 1MB (151 pages) ... ok
chunk 1: 3583MB (917104 pages)panic: ahd_run_qoutfifo recursion
cpuid = 1
3567 3551 3535 3519 3503 3487 3471 3455 3439 3423 3407 3391 3375 3359 3343
3327 3311 3295 3279 3263 3247 3231 3215 3199 3183 3167 3151 3135 3119 3103 3087
3071 3055 3039 3023 3007 2991 2975 2959 2943 2927 2911 2895 2879 2863 2847 2831
2815 2799 2783 2767 2751 2735 2719 2703 2687 2671 2655 2639 2623 2607 2591 2575
2559 2543 2527 2511 2495 2479 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319
2303 2287 2271 2255 2239 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063
2047 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807
1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551
1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295
1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039
1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735
719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415
399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95
79 63 47 31 15
#0 doadump () at pcpu.h:172
172 __asm __volatile(movq %%gs:0,%0 : =r (td));
(kgdb) #0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x8028fa27 in boot (howto=260)
at /var/src/sys/kern/kern_shutdown.c:409
#3 0x802900c1 in panic (fmt=0xff00567ba260 )
at /var/src/sys/kern/kern_shutdown.c:565
#4 0x803c03d8 in pmap_remove_pages (pmap=0xff0051ab7c00, sva=0,
eva=140737488355328) at /var/src/sys/amd64/amd64/pmap.c:2746
#5 0x8026f963 in exec_new_vmspace (imgp=0x0, sv=0x805a99e0)
at vm_map.h:251
#6 0x80257577 in exec_elf64_imgact (imgp=0xb745b9e0)
at /var/src/sys/kern/imgact_elf.c:668
#7 0x802701ec in kern_execve (td=0xff00567ba260,
args=0xb745bb30, mac_p=0x0) at /var/src/sys/kern/kern_exec.c:426
#8 0x80270d6f in execve (td=0xff00567ba260, uap=0x0)
at /var/src/sys/kern/kern_exec.c:188
#9 0x803c8571 in syscall (frame=
{tf_rdi = 140737488349781, tf_rsi = 140737488349224, tf_rdx =
140737488349240, tf_rcx = 0, tf_r8 = 34367075043, tf_r9 = 11, tf_rax = 59,
tf_rbx = 140737488350300, tf_rbp = 140737488349072, tf_r10 = 31, tf_r11 = 4,
tf_r12 = 140737488349224, tf_r13 = 0, tf_r14 = 0, tf_r15 = 0, tf_trapno = 12,
tf_addr = 34366651872, tf_flags = 0, tf_err = 2, tf_rip = 34366652876, tf_cs =
43, tf_rflags = 518, tf_rsp = 140737488347816, tf_ss = 35}) at
/var/src/sys/amd64/amd64/trap.c:803
#10 0x803afed8 in Xfast_syscall ()
at /var/src/sys/amd64/amd64/exception.S:270
#11 0x0008006981cc in ?? ()
(kgdb)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
[ambrisko@ and scottl@ added to CCs] Hi there, In message [EMAIL PROTECTED], Aldas Nabazas [EMAIL PROTECTED] writes We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg00506.html I was reading the mailing list and found that some of the people are happily using this hardware with the latest FreeBSD: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039675.html I just wonder what the status of mfi driver? Maybe it's not fully tested or there will be some important fixes before 7.0 final? We are going to try different RAID combinations but it definitely not working using 6x146GB as RAID5. This is extremely disappointing to read, as I was relatively close to buying a Poweredge 2950 III with PERC 6/i. However, it's no good to me if mfi(4) has issues with large virtual disks; the tentative disk configuration is 2x146GB as RAID 1 and 4x750GB (or 1TB) as RAID 5. Looking at CVSweb: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mfi/ the updates for the 1078 chip which powers the PERC 6 series were contributed by LSI, so you would have hoped things were right. There is a disclaimer on the code, but you would also hope that someone in the know is testing it, especially as my impression has always been that the FreeBSD community is favourably disposed towards LSI storage controllers and that LSI and their vendors try to help the FreeBSD developers. Maybe someone could share the RAID combinations they successfully are running on? I haven't been keeping a very close eye on the problem as I don't currently have any hardware - but is the issue simply one of virtual disk size - there's a cut-off size after which things don't work properly? You could try pulling disks from your server (or removing them from the virtual disk) one by one until things start to work. To save a lot of pain you could create a virtual disk containing one disk as RAID 0 (a single disk) and install the OS on it, leaving the other five disks to play with. I do hope that someone is in a position to investigate this quickly - even if it's too late to get the fix in 7.0-RELEASE now. There's nothing that I can see as relevant that's waiting for MFC, anyway. Of course, it's worth checking whether you've got the latest firmware on the PERC 6/i - the latest version from Dell appears to be 6.0.1-0080. If this doesn't get fixed soon, I'm either going to have to go to another hardware vendor that uses a different RAID controller (HP is a possibility - though we're an all Dell shop) or - sniff - leave FreeBSD in favour of a Linux distribution. I realise that FreeBSD is a volunteer project, and that users can't have any specific expectations - this is not a threat, as I like FreeBSD and want to remain in the community, but I would need a new server to work properly! Looking at CVSweb, it seems that ambrisko@ and scottl@ are the two people most closely associated with the mfi code - I've added them into the CCs. My apologies if that was unwelcome. Best wishes, David -- David Wood [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Scheduler in Various Docs
The comments regarding SCHED_ULE and SCHED_4BSD are inconsistent with information found in the email archives. LINT says ULE is experimental. The handbook doesn't mention ULE at all. The archives say ULE is the new recommended scheduler. If ULE is in fact the current recommendation, then a few docs need to be updated. Regards, Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
On Sun, Jan 20, 2008 at 04:48:56PM +, David Wood wrote: [ambrisko@ and scottl@ added to CCs] Hi there, In message [EMAIL PROTECTED], Aldas Nabazas [EMAIL PROTECTED] writes We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg00506.html I was reading the mailing list and found that some of the people are happily using this hardware with the latest FreeBSD: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039675.html I just wonder what the status of mfi driver? Maybe it's not fully tested or there will be some important fixes before 7.0 final? We are going to try different RAID combinations but it definitely not working using 6x146GB as RAID5. I do not know if the mfi(4) driver has any problems with large disks, but it is however well known that fdisk(8) and bsdlabel(8) (the tools normally used to partition disks) have problems with volumes larger than 2TB. If you want to use volumes larger than 2TB then gpt(8) is the recommended way to partition the disks. It is however doubtful if the BIOS in your system will allow you to boot from a gpt(8) parttioned volume which is best solved with having a separate - smaller - boot volume where the OS itself is installed. This is extremely disappointing to read, as I was relatively close to buying a Poweredge 2950 III with PERC 6/i. However, it's no good to me if mfi(4) has issues with large virtual disks; the tentative disk configuration is 2x146GB as RAID 1 and 4x750GB (or 1TB) as RAID 5. Looking at CVSweb: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mfi/ the updates for the 1078 chip which powers the PERC 6 series were contributed by LSI, so you would have hoped things were right. There is a disclaimer on the code, but you would also hope that someone in the know is testing it, especially as my impression has always been that the FreeBSD community is favourably disposed towards LSI storage controllers and that LSI and their vendors try to help the FreeBSD developers. Maybe someone could share the RAID combinations they successfully are running on? I haven't been keeping a very close eye on the problem as I don't currently have any hardware - but is the issue simply one of virtual disk size - there's a cut-off size after which things don't work properly? You could try pulling disks from your server (or removing them from the virtual disk) one by one until things start to work. To save a lot of pain you could create a virtual disk containing one disk as RAID 0 (a single disk) and install the OS on it, leaving the other five disks to play with. I do hope that someone is in a position to investigate this quickly - even if it's too late to get the fix in 7.0-RELEASE now. There's nothing that I can see as relevant that's waiting for MFC, anyway. Of course, it's worth checking whether you've got the latest firmware on the PERC 6/i - the latest version from Dell appears to be 6.0.1-0080. If this doesn't get fixed soon, I'm either going to have to go to another hardware vendor that uses a different RAID controller (HP is a possibility - though we're an all Dell shop) or - sniff - leave FreeBSD in favour of a Linux distribution. I realise that FreeBSD is a volunteer project, and that users can't have any specific expectations - this is not a threat, as I like FreeBSD and want to remain in the community, but I would need a new server to work properly! Looking at CVSweb, it seems that ambrisko@ and scottl@ are the two people most closely associated with the mfi code - I've added them into the CCs. My apologies if that was unwelcome. -- Insert your favourite quote here. Erik Trulsson [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: Scheduler in Various Docs
Jason C. Wells wrote: The comments regarding SCHED_ULE and SCHED_4BSD are inconsistent with information found in the email archives. LINT says ULE is experimental. The handbook doesn't mention ULE at all. The archives say ULE is the new recommended scheduler. If ULE is in fact the current recommendation, then a few docs need to be updated. To add to Jason's point - why does GENERIC still default to SCHED_4BSD? Are there plans to change this before 7.0 is truly released? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
Erik Trulsson wrote: On Sun, Jan 20, 2008 at 04:48:56PM +, David Wood wrote: [ambrisko@ and scottl@ added to CCs] Hi there, In message [EMAIL PROTECTED], Aldas Nabazas [EMAIL PROTECTED] writes We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg00506.html This post is related to using BSDLabel and FDISK MBR partition tables with a disk over 2Tb. This is a known limitation of this type of partition table where the max size is 2Tb. If you wish to make a larger partition you must use GPT or the raw device with no partition table (Not recommended). I was reading the mailing list and found that some of the people are happily using this hardware with the latest FreeBSD: http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039675.html I just wonder what the status of mfi driver? Maybe it's not fully tested or there will be some important fixes before 7.0 final? We are going to try different RAID combinations but it definitely not working using 6x146GB as RAID5. I do not know if the mfi(4) driver has any problems with large disks, but it is however well known that fdisk(8) and bsdlabel(8) (the tools normally used to partition disks) have problems with volumes larger than 2TB. If you want to use volumes larger than 2TB then gpt(8) is the recommended way to partition the disks. It is however doubtful if the BIOS in your system will allow you to boot from a gpt(8) parttioned volume which is best solved with having a separate - smaller - boot volume where the OS itself is installed. I have 5 PERC6/i based systems awaiting deployment atm, might be able to do some very limited testing on one of them if time permits. However I have some very large arrays running on PERC5/e's (6TB Raid 50 - 5 disk spans - 15 * 500Gb disks spread over 2 md1000 shelves) (the systems run RELENG_6_2) and have not seem any issues with them. They are a single gpt partition with UFS2 on them. As far as I have seen in the last ~8 months there have been no issues with the mfi driver and large arrays. However I cannot say at this stage if the same can be said for the PERC6/i. This is extremely disappointing to read, as I was relatively close to buying a Poweredge 2950 III with PERC 6/i. However, it's no good to me if mfi(4) has issues with large virtual disks; the tentative disk configuration is 2x146GB as RAID 1 and 4x750GB (or 1TB) as RAID 5. Looking at CVSweb: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mfi/ There is one related PCI ID's change to do with DELL sub vendor id's I think that is only on HEAD. Any chance of getting this MFC'd? Tom the updates for the 1078 chip which powers the PERC 6 series were contributed by LSI, so you would have hoped things were right. There is a disclaimer on the code, but you would also hope that someone in the know is testing it, especially as my impression has always been that the FreeBSD community is favourably disposed towards LSI storage controllers and that LSI and their vendors try to help the FreeBSD developers. Maybe someone could share the RAID combinations they successfully are running on? I haven't been keeping a very close eye on the problem as I don't currently have any hardware - but is the issue simply one of virtual disk size - there's a cut-off size after which things don't work properly? You could try pulling disks from your server (or removing them from the virtual disk) one by one until things start to work. To save a lot of pain you could create a virtual disk containing one disk as RAID 0 (a single disk) and install the OS on it, leaving the other five disks to play with. I do hope that someone is in a position to investigate this quickly - even if it's too late to get the fix in 7.0-RELEASE now. There's nothing that I can see as relevant that's waiting for MFC, anyway. Of course, it's worth checking whether you've got the latest firmware on the PERC 6/i - the latest version from Dell appears to be 6.0.1-0080. If this doesn't get fixed soon, I'm either going to have to go to another hardware vendor that uses a different RAID controller (HP is a possibility - though we're an all Dell shop) or - sniff - leave FreeBSD in favour of a Linux distribution. I realise that FreeBSD is a volunteer project, and that users can't have any specific expectations - this is not a threat, as I like FreeBSD and want to remain in the community, but I would need a new server to work properly! Looking at CVSweb, it seems that ambrisko@ and scottl@ are the two people most closely associated with the mfi code - I've added them into the CCs. My apologies if that was unwelcome. ___ freebsd-stable@freebsd.org mailing list
Re: Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
Hi there, In message [EMAIL PROTECTED], Erik Trulsson [EMAIL PROTECTED] writes On Sun, Jan 20, 2008 at 04:48:56PM +, David Wood wrote: In message [EMAIL PROTECTED], Aldas Nabazas [EMAIL PROTECTED] writes We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at least one guy has similar problem reported earlier: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg0 0506.html I do not know if the mfi(4) driver has any problems with large disks, but it is however well known that fdisk(8) and bsdlabel(8) (the tools normally used to partition disks) have problems with volumes larger than 2TB. If you want to use volumes larger than 2TB then gpt(8) is the recommended way to partition the disks. It is however doubtful if the BIOS in your system will allow you to boot from a gpt(8) parttioned volume which is best solved with having a separate - smaller - boot volume where the OS itself is installed. Erik's reminder is timely for those with 2TB volumes. You must use gpt and not fdisk on any disk, be it a single drive (in the future, at least!) or a virtual disk on a RAID setup that are bigger than 2TB. It may be wise to use gpt on any virtual disk that you might grow to 2TB or larger in the future, so long as you're not needing to boot from that virtual disk. fdisk will not work properly with 2TB and larger volumes - the MBR / partition table setup can't cope with these large volumes. You can't boot from a GPT volume - that's a limitation of the BIOS architecture. There is some thought about using EFI on x64 hardware in the future (EFI is used on ia64 hardware; GPT is part of EFI), but we're not there yet. This isn't just about adding GPT support to the BIOS - the whole BIOS setup is wedded to MBR. If you need to boot from a 2TB array, create two virtual disks - one smaller than 2TB to boot from (and use MBR on that), then the residue can be GPT. However, Erik's 6*146 is only 846GB, which should be fine as an MBR / partition table volume (and the use of RAID 5 means you only have 5*146 usable in any case). The referenced problem on freebsd-questions sounds like a failure to use GPT, but Erik's problem sounds different. When I said there was nothing relevant waiting for MFC, I was aware of the change that Tom mentioned, but that seems to be about Dell PERC 6 being identified as such rather than a MegaRAID. It doesn't seem that it will change the behaviour of the driver in any way. There's another change in -CURRENT to do with the log buffer; again, that doesn't seem to be relevant here. Nevertheless, if one or both of these changes are felt stable enough to be MFCed to RELENG_7 and ideally RELENG_7_0, that would be good. I do have my doubts as to whether agreement will be got to merge them to RELENG_7_0 at this stage, however. Erik - can you post dmesg output, details on how you've arranged the physical disks into virtual disks, exactly how you get an anomalous result, and why you think what you're seeing is wrong. I went to look at HP, and I wasn't particularly happy with their offering. The Proliant DL380 G5 isn't a bad machine - but it uses 2.5 inch disks, and I prefer the 6 x 3.5 inch option available with the Dell Poweredge 2950. With the current state of development of disks and my requirement for a high capacity array, a 3.5 inch based machine is more suited to my needs. I also prefer the way that you order a Dell. I do hope we can reassure ourselves over the PERC 6/i. The PERC 5 series seems to have an excellent reputation under FreeBSD, and hopefully the newer PERC 6 series will soon get the same excellent reputation. Best wishes, David -- David Wood [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: Scheduler in Various Docs
Jason C. Wells wrote:
X-Face:
#0jV*~a}VtKS-E/!EJpH('H1Va}24dxF0oT+.R3Gu8C;xhSC+|+H84YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Lnb+9Fw|[EMAIL
PROTECTED]ZwA]5%_AU?}DezfE1!H?3E$!Yve7.O+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze^5]+r(XJ+m7`/vMDc$'wy|$nE`e
The comments regarding SCHED_ULE and SCHED_4BSD are inconsistent with
information found in the email archives. LINT says ULE is experimental.
The handbook doesn't mention ULE at all. The archives say ULE is the
new recommended scheduler.
If ULE is in fact the current recommendation, then a few docs need to be
updated.
I noticed this in the sched_ule(4) man page as well. ULE is said to
be experimental and refers the reader to a non-existent BUGS section
(removed before RELENG_7 was created). The commit log also states
that ULE is no longer buggy or experimental, so at the very least,
the man page is slightly inconsistent with itself and its last commit
log.
Jeff
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Scheduler in Various Docs
On 1/20/08, Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: Jason C. Wells wrote: The comments regarding SCHED_ULE and SCHED_4BSD are inconsistent with information found in the email archives. LINT says ULE is experimental. The handbook doesn't mention ULE at all. The archives say ULE is the new recommended scheduler. If ULE is in fact the current recommendation, then a few docs need to be updated. To add to Jason's point - why does GENERIC still default to SCHED_4BSD? Are there plans to change this before 7.0 is truly released? Excuse me for my bad english... This question was mentioned two or three months ago. The answer was that in 7.1, after the ULE will be tested in 7.0, it will be the defacto scheduler in FreeBSD. First, the scheduler need the best benchark in the world; a few thousand users testing in real-life situations on a daily basis. Regards. -- Have a nice day ;-) TooManySecrets Dijo Confucio: Exígete mucho a ti mismo y espera poco de los demás. Así te ahorrarás disgustos. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Scheduler in Various Docs
Jeremy Chadwick wrote: On Sun, Jan 20, 2008 at 07:40:07PM +0100, TooMany Secrets wrote: On 1/20/08, Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: Jason C. Wells wrote: The comments regarding SCHED_ULE and SCHED_4BSD are inconsistent with information found in the email archives. LINT says ULE is experimental. The handbook doesn't mention ULE at all. The archives say ULE is the new recommended scheduler. If ULE is in fact the current recommendation, then a few docs need to be updated. To add to Jason's point - why does GENERIC still default to SCHED_4BSD? Are there plans to change this before 7.0 is truly released? Excuse me for my bad english... This question was mentioned two or three months ago. The answer was that in 7.1, after the ULE will be tested in 7.0, it will be the defacto scheduler in FreeBSD. First, the scheduler need the best benchark in the world; a few thousand users testing in real-life situations on a daily basis. This is correct. There was a very large discussion on freebsd-current (which would've been discussing 7.x at that point) about what scheduler should be the default for RELENG_7 (4BSD or the new ULE (a.k.a. SMP2)). It was voted (note the quotes) that SCHED_4BSD should remain the default until 7.1 was released, since if there turned out to be a gigantic bug in the new scheduler, we wouldn't want people to get bit by it (thus harming the stability reputation of -RELEASE and -STABLE). The 4BSD scheduler is still considered stable and has a track record to prove it. In a way, SCHED_ULE on 7.x is still considered experimental in the sense that it needs lots of people testing it. So far all the results have been positive (unlike SCHED_ULE on 6.x and 5.x, which were very broken -- hence the rewrite!). If the OP wants to read the thread/discussion (it's long), I can dig up a URL to it in the archives. Thanks. You both answered my question admirably. ___ 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
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[2]: Scheduler in Various Docs
Hello Stephen, Sunday, January 20, 2008, 7:12:49 PM, you wrote: Jason C. Wells wrote: The comments regarding SCHED_ULE and SCHED_4BSD are inconsistent with information found in the email archives. LINT says ULE is experimental. The handbook doesn't mention ULE at all. The archives say ULE is the new recommended scheduler. If ULE is in fact the current recommendation, then a few docs need to be updated. To add to Jason's point - why does GENERIC still default to SCHED_4BSD? Actually, 8.0-CURRENT has the SCHED_ULE scheduler set as default. Are there plans to change this before 7.0 is truly released? No, this will not be changed for 7.0, but it's planned for 7.1. -- Best regards, Danielmailto:[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]
Re: patch for review: ATI SB600 SATA AHCI
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 -- Regards, Torfinn Ingolfsen ___ 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]
problems with LC_ALL
Hi, I am using darwing in a mac book pro, when I open terminal I get the following message that appears only in my account, I would like to get help in order to fix it. Last login: Sun Jan 20 14:32:18 on ttys001 perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = UTF-8 are supported and installed on your system. perl: warning: Falling back to the standard locale (C). I have tried but without success. The languaje is EN_US with iso and the keyboard is in spanish, but not problem with it. thanks, Javier Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7, RELENG_7_0, RELENG_7_BP, RELENG_7_0_BP - difference?
Hi Jakub, In message [EMAIL PROTECTED], Jakub Siroky [EMAIL PROTECTED] writes I should probably know that, but: what's the difference between these branches? RELENG_7 is 7-STABLE. RELENG_7_0 will become 7.0-RELEASE, and is what you should track now if you intend to upgrade to 7.0-RELEASE. After 7.0-RELEASE, it will be turned over to the security team, and only security fixes and errata will be checked in (7.0-RELEASE-p1 etc.). The _BP versions mark the branch points - where the tree was when the tag mentioned was branched. They won't be updated at all. Corrections are welcomed if I've misunderstood. Best wishes, David -- David Wood [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
7-PRERELEASE Xorg - Fatal server error:could not open default font 'fixed'
Greetings, Well, after not having any luck with Xorg after a fresh install of 7. I decided to try a more recent cvsup of the ports tree and try again. After issuing: cvsup -g -L 2 ports-supfile portsdb -uU pkgdb -F And following up with a portupgrade -a -e -f -y Portupgrade finished without error. So I elected to bounce the box and issue startx after logging in. Good news. No more Xorg dumping core. Bad news. Xorg exits before completeting with the following error: Fatal server error: could not open default font 'fixed' The man page provided no help. Google provided no cure. Yahoo provided no cure. I tried make uninstall of every misc font file I could imagine. Then make installing all of them. But still no joy. :( Please help. Thank you. --Chris -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7-PRERELEASE Xorg - Fatal server error:could not open default font 'fixed'
On 20/01/2008, Chris H. [EMAIL PROTECTED] wrote: Greetings, Well, after not having any luck with Xorg after a fresh install of 7. I decided to try a more recent cvsup of the ports tree and [...] you need ports/x11-fonts/font-alias -- panic: kernel trap (ignored) -- Regards, Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7-PRERELEASE Xorg - Fatal server error:could not open default font 'fixed'[SOLVED]
Quoting Kimi [EMAIL PROTECTED]: On 20/01/2008, Chris H. [EMAIL PROTECTED] wrote: Greetings, Well, after not having any luck with Xorg after a fresh install of 7. I decided to try a more recent cvsup of the ports tree and [...] you need ports/x11-fonts/font-alias Thank you! You rock! That did it. You're the best. :) I can't believe I overlooked that. --Chris -- panic: kernel trap (ignored) -- Regards, Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ZFS assert panic
I have done everyday work on my ZFS-enabled FreeBSD7 box. It is having 4*250G disks in a RAIDZ array (the base system is on a separate disk). %uname -a FreeBSD ginger.apathy.szote.u-szeged.hu 7.0-RC1 FreeBSD 7.0-RC1 #0: Mon Dec 24 10:10:07 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 %cat info.0 Dump header from device /dev/ad4s1b Architecture: amd64 Architecture Version: 2 Dump Length: 253394944B (241 MB) Blocksize: 512 Dumptime: Sun Jan 20 23:51:58 2008 Hostname: Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-RC1 #0: Mon Dec 24 10:10:07 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Panic String: solaris assert: sm-sm_space == space (0x1686d4800 == 0x1686d3800), file: /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 357 Dump Parity: 4000765979 Bounds: 0 Dump Status: good Of course I have tried the things described at [1] but they did not work, same crash occured when importing. Haven't yet tried OpenSolaris, though. I can provide the dump should it be needed. TIA for looking into the issue. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS assert panic
Silly me, forgot the [1] URL: http://tinyurl.com/2ytg3w ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)
David Wood wrote: [ambrisko@ and scottl@ added to CCs] Hi there, What really needs to happen as a result of this thread is the following, and I would appreciate volunteers taking up these tasks in some form: 1) FAQ entries written/updated/clarified/advertised as to how FreeBSD, disklabels, FDISK tables, GPT tables, and the PC BIOS work with regard to disk sizes. Having some press articles and blogs published on the subject in conjunction would be extra good. 2) sysinstall needs to be updated to understand the 2TB problem and provide unambiguous information to the user about it. 3) sysinstall needs to be further updated to give the user options for doing GPT partitioning with MBR compatibility for booting. #1 and #2 are vital to get done. #3 is a very strong nice to have. Please, anyone, feel free to work on these tasks with or without coordination with myself or others. They need to be done. Thanks, Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance! [SOLVED]
El vie, 11-01-2008 a las 18:15 +0100, Kris Kennaway escribió: Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threadstransactions/sec 1 755 8 7129 40 6580 100 6768 Hi. May i ask what kind of hardware is running this test? Just wanted to compare with this AMDX2 4600+ 2G DDR800 box wich gives: 1 500 2 887 4 880 6 834 8 791 thanks! ___ 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
Volker wrote: If nobody complains until tuesday (2008-01-22), I'll file a PR for that patch. Hi, there was several PR's and patches for ATI. http://lists.freebsd.org/pipermail/freebsd-current/2008-January/081982.html http://lists.freebsd.org/pipermail/freebsd-current/2007-November/079466.html http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113195 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118193 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/116125 I think Soren and Xin are busy and don't have time for do it. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
