Jump to content

Custom Driver Woes - Help Please!


Recommended Posts

So I thought things were going well after finally building a driver for my new HighPoint DC7280 SATA controller.  The system booted fine with no errors.  I rebooted 4 times and the 4th syslog is attached for reference.  I could see the 2 NTFS-formatted drives attached to the controller in Disk Admin under unmenu, and I could even mount them as read-only and share them and see their data across my network.  Life seemed grand, and then I tried to assign one of the two drives on the DC7280 as disk2 in my basic configuration I'm trying to setup and suddenly things went to crap.  unRAID Main was no longer accessible, and I got a segmentation fault after rebooting.

 

One thing I noticed in the 1st-4th syslogs is that the HPT driver is marked as proprietary so I got the "taints kernel" message:

 

Sep 23 03:07:33 Tower kernel: dc7280: module license 'Proprietary' taints kernel.

Sep 23 03:07:33 Tower kernel: Disabling lock debugging due to kernel taint

 

Does that matter?  I have no idea as this past week has been my first time working in Linux at this level.  Meaning I know how to use a Linux computer at work for my job, but beyond that I'm clueless.

 

As for the segmentation fault here's part of the syslog:

 

Sep 23 05:08:28 tower kernel: md: disk2: ATA_OP_SETIDLE1 ioctl error: -1

Sep 23 05:08:28 tower kernel: BUG: unable to handle kernel paging request at 4f000004

Sep 23 05:08:28 tower kernel: IP: [<f83a41c6>] md_thread+0x7a/0xdc [md_mod]

Sep 23 05:08:28 tower kernel: *pdpt = 000000001ed0d001 *pde = 0000000000000000

Sep 23 05:08:28 tower kernel: Oops: 0000 [#1] SMP

Sep 23 05:08:28 tower kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/serial

Sep 23 05:08:28 tower kernel: Modules linked in: md_mod xor ahci r8169 dc7280(P)

Sep 23 05:08:28 tower kernel:

Sep 23 05:08:28 tower kernel: Pid: 1497, comm: spinupd Tainted: P           (2.6.32.9-unRAID #1) System Product Name

Sep 23 05:08:28 tower kernel: EIP: 0060:[<f83a41c6>] EFLAGS: 00010246 CPU: 0

Sep 23 05:08:28 tower kernel: EIP is at md_thread+0x7a/0xdc [md_mod]

Sep 23 05:08:28 tower kernel: EAX: 00000000 EBX: 4f000000 ECX: decdbfa4 EDX: 00000246

Sep 23 05:08:28 tower kernel: ESI: f778ef40 EDI: f778ef4c EBP: decdbfb8 ESP: decdbf94

Sep 23 05:08:28 tower kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068

Sep 23 05:08:28 tower kernel: Process spinupd (pid: 1497, ti=decda000 task=f6c16940 task.ti=decda000)

Sep 23 05:08:28 tower kernel: Stack:

Sep 23 05:08:28 tower kernel:  f6c16940 00000000 f6c16940 c1033939 f778ef50 f778ef50 def15d04 f778ef40

Sep 23 05:08:28 tower kernel: <0> f83a414c decdbfe0 c1033885 00000000 00000000 00000000 decdbfcc decdbfcc

Sep 23 05:08:28 tower kernel: <0> c1033824 00000000 00000000 00000000 c100339f def15cf8 00000000 00000000

Sep 23 05:08:28 tower kernel: Call Trace:

Sep 23 05:08:28 tower kernel:  [<c1033939>] ? autoremove_wake_function+0x0/0x30

Sep 23 05:08:28 tower kernel:  [<f83a414c>] ? md_thread+0x0/0xdc [md_mod]

Sep 23 05:08:28 tower kernel:  [<c1033885>] ? kthread+0x61/0x68

Sep 23 05:08:28 tower kernel:  [<c1033824>] ? kthread+0x0/0x68

Sep 23 05:08:28 tower kernel:  [<c100339f>] ? kernel_thread_helper+0x7/0x1a

Sep 23 05:08:28 tower kernel: Code: dc 89 45 e4 8d 45 ec 89 45 ec 89 45 f0 8d 55 e0 b9 01 00 00 00 89 f8 e8 ee f8 c8 c8 f6 46 18 01 75 19 e8 f1 f4 c8 c8 85 c0 75 10 <8b> 43 04 f6 40 08 04 75 07 e8 47 a8 ef c8 eb d2 8d 46 0c 8d 55

Sep 23 05:08:28 tower kernel: EIP: [<f83a41c6>] md_thread+0x7a/0xdc [md_mod] SS:ESP 0068:decdbf94

Sep 23 05:08:28 tower kernel: CR2: 000000004f000004

Sep 23 05:08:28 tower kernel: ---[ end trace e22bc4060bd284ff ]---

Sep 23 05:08:28 tower kernel: emhttp[1478]: segfault at 0 ip (null) sp bfe7e650 error 14 in emhttp[8048000+11000]

 

The full log file is attached.

 

The interesting thing is I was able to reboot with my old pre-driver bzimage/bzroot and clean things up, and then reboot with the modded versions, and the controller was seen again with the drives.  So before I left for work this morning I attached a spare 320GB Seagate to the DC7280 and started running preclear_disk.sh on it.  That was working fine when I left - we'll see where it is when I get home.

 

Can anyone offer me any insight as to what I might try next to debug this issue?  I'm about to give up on this new controller and either return it, or go back to WHSv1 for the time being as it works under that environment.

 

Thanks!

syslog-2011-09-23-dc7280-4th-boot.txt

syslog-2011-09-23-segfault.txt

Link to comment

OK, so given some sage advice on this forum and taking into account the many hours of time I've spent working on this DC7280 card, I'm conceding defeat to the HPT.  (This is partially due to their apparently horrific tech support by the way.)

 

So I'm going to switch motherboards to a Biostar TH67B (yes I know it has THAT NIC, but so does my ASUS and it's fine) and get 2 Supermicro AOC-SASLP-MV8 cards.  The mobo has 6 SATA ports, 2 of which are 6Gbps which should be great for parity and cache drives.  So I'll have a total of 20 SATA ports and by all accounts on this forum those Supermicro controllers will be the ticket.

 

All in all I feel like I learned a bit about compiling drivers, but I've got to move on and get my server back up and running!

 

Thanks to all for feedback on the HPT DC7280!

Link to comment

OK, so given some sage advice on this forum and taking into account the many hours of time I've spent working on this DC7280 card, I'm conceding defeat to the HPT.  (This is partially due to their apparently horrific tech support by the way.)

 

So I'm going to switch motherboards to a Biostar TH67B (yes I know it has THAT NIC, but so does my ASUS and it's fine) and get 2 Supermicro AOC-SASLP-MV8 cards.  The mobo has 6 SATA ports, 2 of which are 6Gbps which should be great for parity and cache drives.  So I'll have a total of 20 SATA ports and by all accounts on this forum those Supermicro controllers will be the ticket.

 

All in all I feel like I learned a bit about compiling drivers, but I've got to move on and get my server back up and running!

 

Thanks to all for feedback on the HPT DC7280!

 

You may want to check out the SAS2LP

Link to comment

PMP's work, but you will be limited in speed. For a mid sized array that should not be an issue.

but when you get into large 20 drive arrays. you don't want parity gen, check or rebuilds to run over a day.

 

As drives get bigger and arrays hold more drives this becomes more of an issue.

 

So given this statement and the fact I already have a pile of drives and data to store, even if I could get the DC7280 to work it could prove to be problematic since it's just a PM based controller, correct?

 

No that's not quite what I meant. I have not found that the DC7280 is a PMP controller.

I.E. Controller using downstream PMP (Port MultiPliers).

It's an advanced controller and requires extra drivers in the kernel. This may prove to be problematic in the future.

 

 

1. Its a future driver support issue. (you can ask limetech to include it).

2.  The spinup/spindown and smart access api's may or may not work, or could break in the future.

 

I know limetech had to make allot of effort to support the Supermicro AOC-SASLP controllers.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...