Bug 700343

Summary: netjet - blacklist Digium TDM400P
Product: Red Hat Enterprise Linux 6 Reporter: tbsky <tbskyd>
Component: kernelAssignee: Prarit Bhargava <prarit>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: low Docs Contact:
Priority: medium    
Version: 6.0CC: arozansk, eguan, pbenas
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: kernel-2.6.32-157.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-06 13:20:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
RHEL6 patch for this issue none

Description tbsky 2011-04-28 07:49:36 UTC 
Description of problem:

I install 64bit RHEL6 on a machine which has AMD Athlon 64 X2 4000+ CPU.
I install "cpuspeed" package to save power, and the default GOVERNOR setting of /etc/sysconfig/cpuspeed is empty (which become ondemand for AMD k8). my cpu can work on frequency 1000,1800,2000,2100 MHZ. but it always keep running at 1800MHZ instead of 1000MHZ when system is idle.

if I change the default GOVERNOR to "userspace", then everything is normal. I have installed other linux distribution with "ondemand" GOVERNOR before and it runs correctly. so the hardware should be ok for linux.

I also measure the power consuming of the whole machine when idle:

102W: no cpuspeed (run 2100MHZ)
95W: default ondemand governor (run 1800MHZ)
85W: userspace governor (run 1000MHZ)

Version-Release number of selected component (if applicable):
kernel-2.6.32-71.el6.x86_64
cpuspeed-1.5-15.el6.x86_64

How reproducible:
every time

Steps to Reproduce:
1. install cpu speed package and start it
2. cat /proc/cpuinfo and check the cpu speed when system idle
  
Actual results:
CPU run at high frequency(although not highest frequency) when system idle

Expected results:
CPU should run at lowest frequency when system idle

Additional info:
dmesg info for my cpu:

powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ processors (2 cpu cores) (version 2.20.00)
powernow-k8:    0 : fid 0xd (2100 MHz), vid 0xc
powernow-k8:    1 : fid 0xc (2000 MHz), vid 0xd
powernow-k8:    2 : fid 0xa (1800 MHz), vid 0xf
powernow-k8:    3 : fid 0x2 (1000 MHz), vid 0x12
Comment 2 RHEL Program Management 2011-04-29 06:02:16 UTC 
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 3 tbsky 2011-04-29 12:29:50 UTC 
hi:
   do you mean I should test RHEL 6.1 beta?
Comment 4 tbsky 2011-05-24 03:57:56 UTC 
finally I find out my problem is related to a hardware card.

I have an unused asterisk voice card in the system. and linux auto detect it then assign a wrong driver(netjet) for it. with that wrong driver auto installed, cpu won't go down to 1000MHZ with default setup. it's interesting and I am happy I finally find out the reason. I blacklist the driver and everything is normal now.
Comment 5 Prarit Bhargava 2011-05-24 10:41:36 UTC 
(In reply to comment #4)
> finally I find out my problem is related to a hardware card.
> 
> I have an unused asterisk voice card in the system. and linux auto detect it
> then assign a wrong driver(netjet) for it. with that wrong driver auto
> installed, cpu won't go down to 1000MHZ with default setup. it's interesting
> and I am happy I finally find out the reason. I blacklist the driver and
> everything is normal now.

Interesting ... can you send me the PCI ID of the asterisk voice card?  If there is a PCI collision we (Red Hat) should fix that.

Can you just cut and paste the output of 'lspci -xxx -vv' here?

Thanks,

P.
Comment 6 tbsky 2011-05-24 15:45:42 UTC 
hi:
   ok. the card is digium TDM400P, search internet and I found recent linux kernel has include a conflict driver for it, so basically asterisk users with this kind of card will met the collision problem and need to blacklist "netjet" driver manually to use the card. the card is currently unused in my system so I didn't notice the problem.
   below is my card info of "lspci -xxx -vv" result:

04:07.0 Communication controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN interface
        Subsystem: Device b100:0003
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr+ DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (250ns min, 32000ns max)
        Interrupt: pin A routed to IRQ 17
        Region 0: I/O ports at c800 [size=256]
        Region 1: Memory at fd7fe000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=55mA PME(D0+,D1-,D2+,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: wctdm
        Kernel modules: wctdm, hisax, netjet
00: 59 e1 01 00 47 01 10 03 00 00 80 07 00 40 00 00
10: 01 c8 00 00 00 e0 7f fd 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 b1 03 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 01 80
40: 01 00 62 ec 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Comment 7 Prarit Bhargava 2011-05-24 17:26:19 UTC 
Yeah ... sure enough:

00: 59 e1 01 00 47 01 10 03 00 00 80 07 00 40 00 00

VENDOR_ID = 0xe159
DEVICE_ID = 0x0001

which maps to

PCI_VENDOR_ID_TIGERJET, PCI_DEVICE_ID_TIGERJET_300 in the kernel.  I'll see what the upstream maintainer suggests.

P.
Comment 8 Prarit Bhargava 2011-05-25 12:17:52 UTC 
Upstream blacklist patch here:

http://marc.info/?l=linux-netdev&m=130632555108457&w=2

P.
Comment 9 Prarit Bhargava 2011-05-25 22:33:38 UTC 
(In reply to comment #8)
> Upstream blacklist patch here:
> 
> http://marc.info/?l=linux-netdev&m=130632555108457&w=2
> 
> P.

David Miller accepted this patch upstream.  I'll post for RHEL.

http://marc.info/?l=linux-netdev&m=130636067426562&w=2

P.
Comment 10 Prarit Bhargava 2011-05-25 22:43:41 UTC 
Created attachment 500952 [details]
RHEL6 patch for this issue
Comment 11 RHEL Program Management 2011-05-25 22:49:22 UTC 
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.
Comment 15 Aristeu Rozanski 2011-06-14 14:58:39 UTC 
Patch(es) available on kernel-2.6.32-157.el6
Comment 19 errata-xmlrpc 2011-12-06 13:20:15 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2011-1530.html