Hi folks,
I've been using FC2 and devel kernels for one of our dual-Opteron systems and am very happy with recent improvements. Everything works well for us including:
- AMD IDE interface - tg3 driver (dual Broadcom BCM5704 GigE) - 3w_9xxx driver (8-port 3ware SATA card)
The only request I have is that the following be added to the x86_64-SMP kernel config:
CONFIG_HIGHMEM=y CONFIG_HIGHMEM64G=y
I've been building custom kernels based on the testing SRPMs with just this one small change and (for us at least) it works well on:
kernel-2.6.7-1.494 kernel-2.6.8-1.524 kernel-2.6.8-1.533
Would it be possible to make "CONFIG_HIGHMEM64G=y" the default for SMP x86_64 kernels? I bow to the kernel experts, but it does appear to be a reasonable default given the likelihood of SMP Opterons having more than 4Gig RAM.
And I'll gladly add this to bugzilla if someone will recommend the best topic for it.
Ed
I would second this motion. Can't imagine why you would have less than 4GB on a quad opteron :)
How does HIGHMEM64G differ from HIGHMEM ?
-n.
On Mon, 2004-08-30 at 23:31 -0400, Ed Hill wrote:
Hi folks,
I've been using FC2 and devel kernels for one of our dual-Opteron systems and am very happy with recent improvements. Everything works well for us including:
- AMD IDE interface
- tg3 driver (dual Broadcom BCM5704 GigE)
- 3w_9xxx driver (8-port 3ware SATA card)
The only request I have is that the following be added to the x86_64-SMP kernel config:
CONFIG_HIGHMEM=y CONFIG_HIGHMEM64G=y
I've been building custom kernels based on the testing SRPMs with just this one small change and (for us at least) it works well on:
kernel-2.6.7-1.494 kernel-2.6.8-1.524 kernel-2.6.8-1.533
Would it be possible to make "CONFIG_HIGHMEM64G=y" the default for SMP x86_64 kernels? I bow to the kernel experts, but it does appear to be a reasonable default given the likelihood of SMP Opterons having more than 4Gig RAM.
And I'll gladly add this to bugzilla if someone will recommend the best topic for it.
Ed
-- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3@mit.edu ed@eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464
Alan Cox wrote:
On Tue, Aug 31, 2004 at 03:12:39PM +0900, Naoki wrote:
I would second this motion. Can't imagine why you would have less than 4GB on a quad opteron :)
An opteron can address more than 4GB without highmem of any kind when running in 64bit mode.
But I need it for my 32 Exabyte system (2^65 bytes)!!! No rush though... memtestx64-86 is going to take 4 more months before it gets its first run through.
On Tue, 2004-08-31 at 07:01, Stephen J Smoogen wrote:
Alan Cox wrote:
An opteron can address more than 4GB without highmem of any kind when running in 64bit mode.
But I need it for my 32 Exabyte system (2^65 bytes)!!! No rush though... memtestx64-86 is going to take 4 more months before it gets its first run through.
Wow, I guess now we know where the budget deficit went... Let's ignore all the consequences apart from cost and see what the budget for this thing might be. Since you guys are obviously buying in bulk I guess you can get good memory for say $0.10 per MB (1 GB, or 2^30 bytes of memory, for $30). You want, eh, 2^35 times that, or about 34 billion 1 GB memory sticks. So that memory alone should have cost about $3.4 trillion. That's got to be some computer! ;)
Cheers, Per
On Tue, 2004-08-31 at 03:08, Arjan van de Ven wrote:
CONFIG_HIGHMEM=y CONFIG_HIGHMEM64G=y
these don't exist for x86-64 !!!!
Hi Arjan & others,
Thank you for setting me straight on this issue.
I guess it was just a coincidence that some of the kernels worked with mem=12G and others didn't. I've moved the machine to a new location and now *none* of the kernels I have (neither mine nor the Fedora ones) will boot with "mem=12G". The best I can get to work is "mem=3950M".
I'll try re-seating the RAM and see if that helps.
Ed
On Tue, Aug 31, 2004 at 10:42:14AM -0400, Ed Hill wrote:
I guess it was just a coincidence that some of the kernels worked with mem=12G and others didn't. I've moved the machine to a new location and now *none* of the kernels I have (neither mine nor the Fedora ones) will boot with "mem=12G". The best I can get to work is "mem=3950M".
If you don't specify mem= does it find all your RAM. ALso what chipset ?
On Tue, 2004-08-31 at 10:53, Alan Cox wrote:
On Tue, Aug 31, 2004 at 10:42:14AM -0400, Ed Hill wrote:
I guess it was just a coincidence that some of the kernels worked with mem=12G and others didn't. I've moved the machine to a new location and now *none* of the kernels I have (neither mine nor the Fedora ones) will boot with "mem=12G". The best I can get to work is "mem=3950M".
If you don't specify mem= does it find all your RAM. ALso what chipset ?
The chipset is an AMD-8131 and the board details are at:
http://www.msicomputer.com/product/p_spec.asp?model=K8D_Master-F
I did the following boot tests:
2.6.8-1.533 "mem=3950M" ==> OK 2.6.8-1.533 "mem=12G" ==> causes immediate re-boot early in the boot stage (too fast to read) 2.6.8-1.533 wo/ any "mem=" ==> same immediate re-boot problem
And then I tried re-seated the RAM and now it won't POST. Rats! This is disappointing.
Ed
On Tue, 2004-08-31 at 10:53, Alan Cox wrote:
On Tue, Aug 31, 2004 at 10:42:14AM -0400, Ed Hill wrote:
I guess it was just a coincidence that some of the kernels worked with mem=12G and others didn't. I've moved the machine to a new location and now *none* of the kernels I have (neither mine nor the Fedora ones) will boot with "mem=12G". The best I can get to work is "mem=3950M".
If you don't specify mem= does it find all your RAM. ALso what chipset ?
Hi folks,
Since the K8D_Master-F MB would no longer POST, we swapped in a Tyan 2885 with the below HW. The good news is that we're not having any memory recognition problems. The bad news is that we now have an annoying but otherwise harmless boot situation which is:
- the initial boot always fails very early in the boot process and causes a system reset - a warm reboot commences - this second attempt (and any further warm reboots) work just fine - any complete power-down will cause the first boot attempt to fail
And I've seen this with both my own kernels (built from the FC2 SRPMS) and the following FC2 kernels:
title Fedora Core (2.6.8-1.533.edhillsmp) root (hd0,0) kernel /boot/vmlinuz-2.6.8-1.533.edhillsmp ro root=LABEL=/ initrd /boot/initrd-2.6.8-1.533.edhillsmp.img title Fedora Core (2.6.7-1.515smp) root (hd0,0) kernel /boot/vmlinuz-2.6.7-1.515smp ro root=LABEL=/ initrd /boot/initrd-2.6.7-1.515smp.img title Fedora Core (2.6.6-1.435.2.3smp) root (hd0,0) kernel /boot/vmlinuz-2.6.6-1.435.2.3smp ro root=LABEL=/ initrd /boot/initrd-2.6.6-1.435.2.3smp.img
Any ideas what may be causing these first boots to fail?
Ed
$ uname -a Linux XXX 2.6.8-1.533.edhillsmp #1 SMP Mon Aug 30 23:18:09 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux
$ /sbin/lspci 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05) 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) 00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02) 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) 00:07.5 Multimedia audio controller: Advanced Micro Devices [AMD] AMD-8111 AC97 Audio (rev 03) 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) 00:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 02:07.0 RAID bus controller: 3ware Inc 3ware ATA-RAID 02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02) 03:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) 03:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) 03:0b.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) Silicon Image SiI 3114 SATARaid Controller (rev 02) 03:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) 04:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-8151 System Controller (rev 13) 04:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8151 AGP Bridge (rev 13) 05:00.0 VGA compatible controller: nVidia Corporation NV28GL [Quadro4 980 XGL] (rev a1)
Ed Hill wrote:
On Tue, 2004-08-31 at 10:53, Alan Cox wrote:
On Tue, Aug 31, 2004 at 10:42:14AM -0400, Ed Hill wrote:
I guess it was just a coincidence that some of the kernels worked with mem=12G and others didn't. I've moved the machine to a new location and now *none* of the kernels I have (neither mine nor the Fedora ones) will boot with "mem=12G". The best I can get to work is "mem=3950M".
If you don't specify mem= does it find all your RAM. ALso what chipset ?
Hi folks,
Since the K8D_Master-F MB would no longer POST, we swapped in a Tyan 2885 with the below HW. The good news is that we're not having any memory recognition problems. The bad news is that we now have an annoying but otherwise harmless boot situation which is:
- the initial boot always fails very early in the boot process and causes a system reset
- a warm reboot commences
- this second attempt (and any further warm reboots) work just fine
- any complete power-down will cause the first boot attempt to fail
Sounds like crap hardware. I heard of something like that before.. it was 'fixed' with a 'BIOS' update..
On Wednesday 01 September 2004 14:28, Stephen J Smoogen wrote:
Since the K8D_Master-F MB would no longer POST, we swapped in a Tyan 2885 with the below HW. The good news is that we're not having any memory recognition problems. The bad news is that we now have an annoying but otherwise harmless boot situation which is:
Sounds like crap hardware. I heard of something like that before.. it was 'fixed' with a 'BIOS' update..
A friend of mine is running 2 systems with that board without issues. So its either a outdated/buggy bios as previously suggested or you got yet another bad board in front of you...
Either way, does it do anything different if you turn off ACPI on bootup?
Peter.
On Wed, Sep 01, 2004 at 06:38:16PM -0400, Peter Arremann wrote:
On Wednesday 01 September 2004 14:28, Stephen J Smoogen wrote:
Since the K8D_Master-F MB would no longer POST, we swapped in a Tyan 2885 with the below HW. The good news is that we're not having any memory recognition problems. The bad news is that we now have an annoying but otherwise harmless boot situation which is:
Sounds like crap hardware. I heard of something like that before.. it was 'fixed' with a 'BIOS' update..
A friend of mine is running 2 systems with that board without issues. So its either a outdated/buggy bios as previously suggested or you got yet another bad board in front of you...
Likewise my 2885 is rock solid out of the box with FC2
On Thu, 2004-09-02 at 05:34, Alan Cox wrote:
Likewise my 2885 is rock solid out of the box with FC2
I wish we could say the same. Our new Tyan 2885 MB seems to be fine as long as we don't create a lot of writes to the 3ware 9xxx controller. When we do, the machine oopses within ~15--30min. The 3rd oops I was not able to find in /var/log/messages but it looked similar to the second.
Can someone please suggest whats causing these oopses and how we might fix it? We're willing to try just about anything including new kernels, fresh installs, etc.
And many thanks for all the help so far!
Ed
===== 2 oopses writing to 3ware 9xxx RAID array =====
Sep 1 16:05:20 adams kernel: general protection fault: 0000 [1] SMP Sep 1 16:05:20 adams kernel: CPU 1 Sep 1 16:05:20 adams kernel: Modules linked in: sata_sil(U) libata(U) floppy(U) sg(U) nfsd(U) exportfs(U) md5(U) ipv6(U) parport_pc(U) lp(U) parport(U) autofs4(U) nfs(U) lockd(U) sunrpc(U) iptable_filter(U) ip_tables(U) tg3(U) ohci1394(U) ieee1394(U) dm_mod(U) ohci_hcd(U) button(U) battery(U) asus_acpi(U) ac(U) ext3(U) jbd(U) 3w_9xxx(U) sd_mod(U) scsi_mod(U) Sep 1 16:05:20 adams kernel: Pid: 20158, comm: rsync Not tainted 2.6.8-1.533.edhillsmp Sep 1 16:05:20 adams kernel: RIP: 0010:[<ffffffff80124861>] <ffffffff80124861>{do_page_fault+1340} Sep 1 16:05:20 adams kernel: RSP: 0018:0000010031e619d8 EFLAGS: 00010002 Sep 1 16:05:20 adams kernel: RAX: 0000e987f000f0e0 RBX: 0000000000000001 RCX: 000ffffffffff000 Sep 1 16:05:20 adams kernel: RDX: 0000e987f000f000 RSI: 0000010000000000 RDI: 0000010031e61a98 Sep 1 16:05:20 adams kernel: RBP: 000003010383a4b0 R08: 000003010383a4b0 R09: 0000000300000000 Sep 1 16:05:20 adams kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 00000100b7720e90 Sep 1 16:05:20 adams kernel: R13: 0000000000000000 R14: 0000010031e61a98 R15: 00000100d2990940 Sep 1 16:05:20 adams kernel: FS: 0000002a9557bd40(0000) GS:ffffffff804ee280(0000) knlGS:000000000082e560 Sep 1 16:05:20 adams kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Sep 1 16:05:20 adams kernel: CR2: 000003010383a4b0 CR3: 0000000004862000 CR4: 00000000000006e0 Sep 1 16:05:20 adams kernel: Process rsync (pid: 20158, threadinfo 0000010031e60000, task 00000100b7720e90) Sep 1 16:05:20 adams kernel: Stack: 00000101050d4e00 0000000000030001 0000010031e61a78 000001002831d130 Sep 1 16:05:20 adams kernel: 000001002831d240 0000000000000246 00000100d79b7ea0 ffffffff801801b0 Sep 1 16:05:20 adams kernel: 0000000000000246 0000000000000246 Sep 1 16:05:20 adams kernel: Call Trace:<ffffffff801801b0>{__find_get_block+181} <ffffffff801801e2>{__getblk+43} Sep 1 16:05:20 adams kernel: <ffffffff80111ffd>{error_exit+0} <ffffffff801348d5>{__wake_up_common+40} Sep 1 16:05:20 adams kernel: <ffffffff801a2174>{__mark_inode_dirty+40} <ffffffff80134980>{__wake_up+102} Sep 1 16:05:20 adams kernel: <ffffffff8015b358>{generic_file_buffered_write+1085} Sep 1 16:05:20 adams kernel: <ffffffff8015b755>{generic_file_aio_write_nolock+741} Sep 1 16:05:20 adams kernel: <ffffffff8015b8c0>{generic_file_aio_write+126} <ffffffffa00471ea>{:ext3:ext3_file_write+22} Sep 1 16:05:20 adams kernel: <ffffffff8017d200>{do_sync_write+173} <ffffffff80191ed4>{__pollwait+0} Sep 1 16:05:20 adams kernel: <ffffffff801369e2>{autoremove_wake_function+0} <ffffffff8019288a>{sys_select+1177} Sep 1 16:05:20 adams kernel: <ffffffff8017d2fc>{vfs_write+208} <ffffffff8017d3e4>{sys_write+69} Sep 1 16:05:20 adams kernel: <ffffffff80111562>{system_call+126} Sep 1 16:05:20 adams kernel: Sep 1 16:05:20 adams kernel: Code: 48 8b 14 06 f6 c2 01 0f 84 9c fc ff ff 48 89 e8 48 21 ca 48 Sep 1 16:05:20 adams kernel: RIP <ffffffff80124861>{do_page_fault+1340} RSP <0000010031e619d8>
Sep 1 18:04:34 adams kernel: Unable to handle kernel paging request at 000003010383aff0 RIP: Sep 1 18:04:34 adams kernel: <ffffffff80130a9e>{__wake_up_common+37} Sep 1 18:04:34 adams kernel: PML4 0 Sep 1 18:04:34 adams kernel: Oops: 0000 [1] SMP Sep 1 18:04:34 adams kernel: CPU 1 Sep 1 18:04:34 adams kernel: Modules linked in: 3w_9xxx nfsd exportfs md5 ipv6 parport_pc lp parport autofs4 nfs lockd sunrpc iptable_filter ip_tables tg3 ohci1394 ieee1394 dm_mod ohci_hcd button battery asus_acpi ac ext3 jbd sd_mod scsi_mod Sep 1 18:04:34 adams kernel: Pid: 62, comm: kswapd1 Not tainted 2.6.7-1.515smp Sep 1 18:04:34 adams kernel: RIP: 0010:[<ffffffff80130a9e>] <ffffffff80130a9e>{__wake_up_common+37} Sep 1 18:04:34 adams kernel: RSP: 0018:00000101ffef7ae8 EFLAGS: 00010046 Sep 1 18:04:34 adams kernel: RAX: 000001010383aff0 RBX: 0000000000000001 RCX: 0000000000000000 Sep 1 18:04:34 adams kernel: RDX: 0000000000000001 RSI: 0000000000000003 RDI: 000001010383afe8 Sep 1 18:04:34 adams kernel: RBP: 00000101ffef7b18 R08: 000003010383aff0 R09: 00000101ffef7a30 Sep 1 18:04:34 adams kernel: R10: 0000000000000206 R11: 0000010102bedb80 R12: 000001010383afe8 Sep 1 18:04:34 adams kernel: R13: 00000100d4ea2e50 R14: 00000100d4ea2e50 R15: 0000010102bedb80 Sep 1 18:04:34 adams kernel: FS: 0000002a9557e800(0000) GS:ffffffff8047b600(0000) knlGS:0000000000000000 Sep 1 18:04:34 adams kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Sep 1 18:04:34 adams kernel: CR2: 000003010383aff0 CR3: 0000000004862000 CR4: 00000000000006e0 Sep 1 18:04:34 adams kernel: Process kswapd1 (pid: 62, threadinfo 00000101ffef6000, task 00000100d9eb9210) Sep 1 18:04:34 adams kernel: Stack: 0000000300000000 000001010383afe8 0000010100000780 00000100d4ea2e50 Sep 1 18:04:34 adams kernel: 00000100d4ea2e50 00000101ffef7e58 00000101ffef7b38 ffffffff80130afb Sep 1 18:04:34 adams kernel: 0000000000000206 0000000000000001 Sep 1 18:04:34 adams kernel: Call Trace:<ffffffff80130afb>{__wake_up+33} <ffffffff8015a7d5>{shrink_zone+3713} Sep 1 18:04:34 adams kernel: <ffffffff802e972c>{__down_failed_trylock+53} <ffffffff80159896>{shrink_slab+119} Sep 1 18:04:34 adams kernel: <ffffffff8015aeaa>{balance_pgdat+468} <ffffffff8015acd8>{balance_pgdat+2} Sep 1 18:04:34 adams kernel: <ffffffff8015b06f>{kswapd+257} <ffffffff80132652>{autoremove_wake_function+0} Sep 1 18:04:34 adams kernel: <ffffffff80132652>{autoremove_wake_function+0} <ffffffff8012f2ed>{schedule_tail+11} Sep 1 18:04:34 adams kernel: <ffffffff80110d03>{child_rip+8} <ffffffff8015af6e>{kswapd+0} Sep 1 18:04:34 adams kernel: <ffffffff80110cfb>{child_rip+0} Sep 1 18:04:34 adams kernel: Sep 1 18:04:34 adams kernel: Code: 4d 8b 30 49 39 c0 74 28 49 8d 78 e8 45 8b 68 e8 4c 89 f9 8b Sep 1 18:04:34 adams kernel: RIP <ffffffff80130a9e>{__wake_up_common+37} RSP <00000101ffef7ae8> Sep 1 18:04:34 adams kernel: CR2: 000003010383aff0
===== 2 oopses writing to 3ware 9xxx RAID array =====
On Thu, Sep 02, 2004 at 11:58:30AM -0400, Ed Hill wrote:
long as we don't create a lot of writes to the 3ware 9xxx controller. When we do, the machine oopses within ~15--30min. The 3rd oops I was not able to find in /var/log/messages but it looked similar to the second.
First guess would be the 3w-9xxx then. I've got adaptec scsi in mine and even under high load that is behaving.
Nothing much useful in the traces
I would recommend compiling a vanilla kernel, with only the components you need and see if you have the same problem occurs. I am currently running vanilla 2.6.8 and have written many gigabytes of data on a terabyte 9500S-12 raid setup without fault, but I use the XFS filesystem instead of ext3. I personally believe, but with no evidence to back it up, that compiling ext3 into the kernel, and not running it as a module, gives a more stable system.
I would suggest trying the latest kernel, with only the hardware you use compiled in (if you dont use the parallel port, seral ata, ipv6, dont add it in) and see if it works any better.
If it doesnt you may have a hardware problem of some sort.
Peter Maas
On Thu, Sep 02, 2004 at 11:58:30AM -0400, Ed Hill wrote:
long as we don't create a lot of writes to the 3ware 9xxx controller. When we do, the machine oopses within ~15--30min. The 3rd oops I was not able to find in /var/log/messages but it looked similar to the second.
On Thu, Sep 02, 2004 at 12:12:59PM -0400, Alan Cox wrote:
On Thu, Sep 02, 2004 at 11:58:30AM -0400, Ed Hill wrote:
long as we don't create a lot of writes to the 3ware 9xxx controller. When we do, the machine oopses within ~15--30min. The 3rd oops I was not able to find in /var/log/messages but it looked similar to the second.
First guess would be the 3w-9xxx then. I've got adaptec scsi in mine and even under high load that is behaving.
More specifically, a 9xxx thing... Checked with my friend, he's running 8xxx fine...
Peter.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday 02 September 2004 11:56, Peter Arremann wrote:
More specifically, a 9xxx thing... Checked with my friend, he's running 8xxx fine...
9xxx is a pretty significant upgrade from 3ware, and it requires the use of a complete new driver. Unfortunately 3ware hasn't been too smart in writing this driver and they still use a lot of deprecated header files in the driver compile. I haven't checked recently, but I'm not even sure if the 9xxx driver has made kernel mainstream yet. I am still working with 3ware to clean up their driver code a bit.
- -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating
On Thu, Sep 02, 2004 at 01:36:29PM -0700, Jesse Keating wrote:
Hash: SHA1
On Thursday 02 September 2004 11:56, Peter Arremann wrote:
More specifically, a 9xxx thing... Checked with my friend, he's running 8xxx fine...
9xxx is a pretty significant upgrade from 3ware, and it requires the use of a complete new driver. Unfortunately 3ware hasn't been too smart in writing this driver and they still use a lot of deprecated header files in the driver compile. I haven't checked recently, but I'm not even sure if the 9xxx driver has made kernel mainstream yet. I am still working with 3ware to clean up their driver code a bit.
At least it is part of the latest Fedora Core 2 updates, so probably it was introduced in 2.6.8.
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Arjan van de Ven -
Axel Thimm -
Ed Hill -
Jesse Keating -
Naoki -
Per Bjornsson -
Peter Arremann -
Peter Maas -
Stephen Smoogen