Serious file system corruption with RAID5+SMP and kernels above 2.4.0
Two days ago I tried new kernels on my SMP SW RAID5 System and expirienced serous file system corruption with kernels 2.4.1-pre8,9 as 2.4.0-ac8,9,10. The same error has been reported by other people on this list. With 2.4.0 release everything runs fine. So I backsteped to it and had no error since. Comparing Patches from 2.4.1-pre8,9 and 2.4.0-ac10,9 leads me to the question if the chances to the MMX und i387 code in this patches could have broken raid5 under SMP? My boot.log file states that it uses p5_mmx block moves for performance reasons. In the 2.4.1 series are no changes to raid5 but the corruption issue which expirience are in both kernel series the same. Best regards - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel freeze on 2.4.0.prerelease
On all kernels newer than 2.4.0t13p3 I have the following problem. shorly after boot (some seconds) the system freeze. I can only swith consoles but i am not able to login. Over the net I get onyl responses to pings nothing else. Up to kernel 2.4.0.t13p3 everythings works fine. Sorry for this simple description, but I am not able to get more clear infos. No oops, nothing in the logs after reboot with 240t13p3. Perhaps someone has an idea where to dig? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel freeze on 2.4.0.prerelease (smp,raid5)
On all kernels newer than 2.4.0t13p3 I have the following problem. shorly after boot (some seconds) the system freeze. I can only swith consoles but i am not able to login. Over the net I get onyl responses to pings nothing else. Up to kernel 2.4.0.t13p3 everythings works fine. Sorry for this simple description, but I am not able to get more clear infos. No oops, nothing in the logs after reboot with 240t13p3. Perhaps someone has an idea where to dig? ps: Here is my short system description: Dual Celeron (SMP) Raid5 (3 drives actuall 2 drives degra. mode) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel freeze on 2.4.0.prerelease (smp,raid5)
Perhaps a deadlock with a normal (not irq) spinlock.
Could you enable SysRQ and press ++ ("showPc")
Then write down the EIP values (including the [< >] brackets) and
translate them with ksymoops.
Ksymoops repeats only the EIP values.
But searching through the System.map file has only Labels from
the raid5 staff around.
As stated in my first mail I run actually my raid5 devices in degrated mode
and as I remenber there has been some raid5 stuff changed between
test13p3 and newer kernels.
Hope this gives someone an idea?
Bye Otto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel freeze on 2.4.0.prerelease (smp,raid5)
On Tue, 02 Jan 2001 18:19:41 +0100, Otto Meier wrote:
>>Dual Celeron (SMP,raid5)
>> As stated in my first mail I run actually my raid5 devices in degrated mode
>> and as I remenber there has been some raid5 stuff changed between
>> test13p3 and newer kernels.
>So tell us, why do you run your raid5 devices in degraded mode?? I
>cannot be good for performance, and certainly isn't good for
>redundancy!!! But I'm not complaining as you found a bug...
I am actually in the middle of the conversion process to raid5 but it takes a while
I am to lazy :-) to get the next drive free to get raid5 into the fully running mode.
>> Hope this gives someone an idea?
>Yep. This, combined with a related bug report from [EMAIL PROTECTED]
>strongly suggests the following patch.
>Writes to the failed drive are never completing, so you eventually
>run out of stripes in the stripe cache and you block waiting for a
>stripe to become free.
>Please test this and confirm that it works.
It really did the trick you are great.
The system runs now for over a hour otherwise it would have crashed after some
seconds (20 to 30).
btw what does this message in boot.msg mean?
<4>raid5: switching cache buffer size, 4096 --> 1024
<4>raid5: switching cache buffer size, 1024 --> 4096
the log of the raid init you find below.
Thanks again
Otto
--- ./drivers/md/raid5.c 2001/01/03 09:04:05 1.1
+++ ./drivers/md/raid5.c 2001/01/03 09:04:13
@@ -1096,8 +1096,10 @@
bh->b_rdev = bh->b_dev;
bh->b_rsector = bh->b_blocknr * (bh->b_size>>9);
generic_make_request(action[i]-1, bh);
- } else
+ } else {
PRINTK("skip op %d on disc %d for sector %ld\n", action[i]-1, i, sh->sector);
+ clear_bit(BH_Lock, &bh->b_state);
+ }
}
}
>Raid5 (3 drives actuall 2 drives degra. mode)
<6>raid5: device hdg7 operational as raid disk 1
<6>raid5: device hde7 operational as raid disk 0
<1>raid5: md1, not all disks are operational -- trying to recover array
<6>raid5: allocated 3264kB for md1
<1>raid5: raid level 5 set md1 active with 2 out of 3 devices, algorithm 2
<4>RAID5 conf printout:
<4> --- rd:3 wd:2 fd:1
<4> disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde7
<4> disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg7
<4> disk 2, s:0, o:0, n:2 rd:2 us:1 dev:[dev 00:00]
<4>RAID5 conf printout:
<4> --- rd:3 wd:2 fd:1
<4> disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde7
<4> disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg7
<4> disk 2, s:0, o:0, n:2 rd:2 us:1 dev:[dev 00:00]
<6>md: updating md1 RAID superblock on device
<4>hdg7 [events: 0087](write) hdg7's sb offset: 24989696
<6>md: recovery thread got woken up ...
<3>md1: no spare disk to reconstruct array! -- continuing in degraded mode
<6>md: recovery thread finished ...
<4>hde7 [events: 0087](write) hde7's sb offset: 24989696
<4>.
<4>... autorun DONE.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Kernel crash during resync of raid5 on SMP
I run a Dual prozessor SMP system on 2.4.2-ac12 for a while in degraded mode. Today I put in a new disk to switch to full raid5 mode. Shortly after the command raidhotadd the system crashed with the message lost interrupt on cpu1. This continued after reboot. I finaly managed to get it running again by booting with kernel parameter maxcpus=1. In this one CPU mode it finished resycing. During this process I was never able to resync with two CPU's. After finishing rescyncing the system run now fine in SMP Dual mode again. Perhaps there might be an issue with spinlocks during resyncing. Bye Otto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel crash during resync of raid5 on SMP
On Thu, 8 Mar 2001 08:55:28 +1100 (EST), Neil Brown wrote: >On Wednesday March 7, [EMAIL PROTECTED] wrote: >> I run a Dual prozessor SMP system on 2.4.2-ac12 for a while >> in degraded mode. Today I put in a new disk to switch to >> full raid5 mode. Shortly after the command raidhotadd the >> system crashed with the message lost interrupt on cpu1. > >Was there an Oops? Can we see? decoded with ksymoops of course. Unfortunatly I entered this command remotely. The console Display was off at that time. >Are you happy to retry? (i.e. raidsetfaulty; raidhotremove, >raidhotadd). If so, Could you try with 2.4.2? I would not really like to do that, as of now everything runs fine again for a day. >Where abouts in the sync-process did it die? Start? end? middle? >various? After the first crash I needed to reboot. It crashed again shortly after boot message that it starts to resync. This happens several times until I used the kernel parameter MAXcpus=1. Then it worked without a problem. After resyncing finished I could start it again in SMP mode and everything worked fine again. Sorry that can not shed any more light on it. Otto >NeilBrown > > >> >> This continued after reboot. I finaly managed to get it running again >> by booting with kernel parameter maxcpus=1. In this one CPU mode >> it finished resycing. >> >> During this process I was never able to resync with two CPU's. >> >> After finishing rescyncing the system run now fine in SMP Dual mode again. >> >> Perhaps there might be an issue with spinlocks during resyncing. >> >> Bye Otto >> >> >> >> >> >> > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
UDMA 5 on Promise ULTRA 100
I run linux 2.4.2-ac24 on the ULTRA 100 card with pdc 20267 Chip. Drives are MAXTOR 53073H4 UDMA100. Everything runs fine so far. The only thing which iritates me is that : /proc/ide/pdc202xx reports that the drives run in UDMA4 mode. I have the above mentioned drives running as master each as a single drive on its interface. How can I achive that the drives run in UDMA5 ? Otto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Driver for sata adapter promise sata300 tx4
Daniel Drake wrote:
Otto Meier wrote:
This card use the sata chip pdc 40718 (as of my card)
the lastest sata_promise kernel with sata promise patch driver
doesn't recognise
this card.
I added the following line to static struct pci_device_id
pdc_ata_pci_tbl[] in sata_promise.c:
{ PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
and the card was recognised and seam to work without errors so far.
Yes, this should be fine (this is a 4-port SATA card right?)
Are you happy to produce and submit a patch yourself (read
Documentation/SubmittingPatches) or should I submit one for you?
Thanks,
Daniel
Yes you are right it is a 4-port sata-II 300 card (PDC40718 ). According to
the promise feature list it should support :
SATA300™ TX4 Highlights
* Native Command Queuing (NCQ)
* SATA Tagged Command Queuing (TCQ)
* Large LBA support for drives above 137GB
* Supports Serial ATAPI devices
* Disk Activity LED Headers
* Flexible future-proof upgrade for users with motherboards that
only have a PCI interface
My question is also are these features (NCQ/TCQ) and the heigher
datarate be supported by this
modification? or is only the basic feature set of sata 150 TX4 supported?
Here is the patch:
--- linux/drivers/scsi/sata_promise.c.orig 2005-08-01 17:09:48.474824778
+0200
+++ linux/drivers/scsi/sata_promise.c 2005-07-31 12:57:06.415979512 +0200
@@ -183,6 +183,8 @@ static struct pci_device_id pdc_ata_pci_
board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
+ { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
Thanks
Otto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Driver for sata adapter promise sata300 tx4
Daniel Drake wrote:
Otto Meier wrote:
This card use the sata chip pdc 40718 (as of my card)
the lastest sata_promise kernel with sata promise patch driver
doesn't recognise
this card.
I added the following line to static struct pci_device_id
pdc_ata_pci_tbl[] in sata_promise.c:
{ PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
and the card was recognised and seam to work without errors so far.
Yes, this should be fine (this is a 4-port SATA card right?)
Are you happy to produce and submit a patch yourself (read
Documentation/SubmittingPatches) or should I submit one for you?
Thanks,
Daniel
Yes you are right it is a 4-port sata-II 300 card (PDC40718 ). According to
the promise feature list it should support :
SATA300™ TX4 Highlights
* Native Command Queuing (NCQ)
* SATA Tagged Command Queuing (TCQ)
* Large LBA support for drives above 137GB
* Supports Serial ATAPI devices
* Disk Activity LED Headers
* Flexible future-proof upgrade for users with motherboards that
only have a PCI interface
My question is also are these features (NCQ/TCQ) and the heigher
datarate be supported by this
modification? or is only the basic feature set of sata 150 TX4 supported?
Here is the patch:
--- linux/drivers/scsi/sata_promise.c.orig 2005-08-01 17:09:48.474824778 +0200
+++ linux/drivers/scsi/sata_promise.c 2005-07-31 12:57:06.415979512 +0200
@@ -183,6 +183,8 @@ static struct pci_device_id pdc_ata_pci_board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
+ { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
Thanks
Otto
I just saw the patches of Luke Kosewski regarding the SATA150 TX4 antipating
them it might be right to modify the patch to
--- linux/drivers/scsi/sata_promise.c.orig 2005-08-01 17:09:48.474824778 +0200
+++ linux/drivers/scsi/sata_promise.c 2005-07-31 12:57:06.415979512 +0200
@@ -183,6 +183,8 @@ static struct pci_device_id pdc_ata_pci_board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
+ { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_40518 },
{ PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
bye
Otto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Driver for sata adapter promise sata300 tx4
Jens Axboe wrote: On Mon, Aug 01 2005, Jeff Garzik wrote: Jens Axboe wrote: On Mon, Aug 01 2005, Daniel Drake wrote: Otto Meier wrote: My question is also are these features (NCQ/TCQ) and the heigher datarate be supported by this modification? or is only the basic feature set of sata 150 TX4 supported? NCQ support is under development. Search the archives for Jens Axboe's recent patches to support this. I don't know about TCQ. It's done for ahci, because we have documentation. I have no intention on working on NCQ for chipset where full documentation is not available. But the bulk of the code is the libata core support, adding NCQ support to a sata_* driver should now be fairly trivial (with docs). I have docs for the Promise NCQ stuff. Once NCQ is fully fleshed out (I haven't wrapped my brain around it in a couple weeks), it shouldn't be difficult to add NCQ support to sata_promise. Excellent! Sounds great. If you have implemented NCQ for sata_promise it would be nice if you could forward me the patch, because i'm not subscribed to the ML's best regards Otto Meier - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] aktivate sata300 TX4 in sata_promise
Hallo,
this Patch get the Promise SATA300 TX4 card working.
Please accept. Patch is against 2.6.13-rc3-git5.
Signed-off-by: Otto Meier <[EMAIL PROTECTED]>
--- linux/drivers/scsi/sata_promise.c.orig 2005-08-01
17:09:48.474824778 +0200
+++ linux/drivers/scsi/sata_promise.c 2005-07-31 12:57:06.415979512 +0200
@@ -183,6 +183,8 @@ static struct pci_device_id pdc_ata_pci_
board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
+{ PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
dyntick for x86_64
Hi, As of now there is only support for x86 arch of dyntick in 2.6.21. When will it be available for x86_64? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
sata_promise disk error 2.6.22-rc5 with hrt1 patch
Hello, I got the following in my logs: Jun 24 19:06:40 gate2 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jun 24 19:06:40 gate2 kernel: ata4.00: (port_status 0x1000) Jun 24 19:06:40 gate2 kernel: ata4.00: cmd 35/00:00:c1:17:92/00:04:17:00:00/e0 tag 0 cdb 0x0 data 524288 out Jun 24 19:06:40 gate2 kernel: res 50/00:00:c0:1b:92/00:00:17:00:00/e0 Emask 0x20 (host bus error) Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168 Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168 Jun 24 19:06:40 gate2 kernel: ata4.00: configured for UDMA/133 Jun 24 19:06:40 gate2 kernel: ata4: EH complete Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] 488397168 512-byte hardware sectors (250059 MB) Jun 24 19:06:40 gate2 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jun 24 19:06:40 gate2 kernel: ata4.00: (port_status 0x1000) Jun 24 19:06:40 gate2 kernel: ata4.00: cmd 25/00:00:c1:15:92/00:02:17:00:00/e0 tag 0 cdb 0x0 data 262144 in Jun 24 19:06:40 gate2 kernel: res 50/00:00:c0:17:92/00:00:17:00:00/e0 Emask 0x20 (host bus error) Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168 Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = 488397168, hpa_sectors = 488397168 Jun 24 19:06:40 gate2 kernel: ata4.00: configured for UDMA/133 Jun 24 19:06:40 gate2 kernel: ata4: EH complete Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write Protect is off Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] 488397168 512-byte hardware sectors (250059 MB) Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write Protect is off Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA The system continued without seeing other effects. It is runnuning a 2.6.22-rc5 kernel with hrt1 patch. The drive ist part of a raid5 with 4 identical drives lspci -vvv gives: 02:06.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02) Subsystem: Promise Technology, Inc. PDC40718 (SATA 300 TX4) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel_pstate: Change busy calculation to use fixed point math.
On my i3-4330 this patch fixed the problem. works fine
Thanks
Am 26.02.2014 01:39, schrieb Rafael J. Wysocki:
> On Tuesday, February 25, 2014 10:35:37 AM dirk.brande...@gmail.com wrote:
>> From: Dirk Brandewie
>>
>> Commit fcb6a15c2e Take core C0 time into account for core busy calculation.
>>
>> Introduced a regression on some processor SKUs supported by
>> intel_pstate. This was caused by the truncation caused by using
>> integer math to calculate core busy and C0 percentages.
>>
>> On a i7-4770K processor operating at 800Mhz going to 100% utilization
>> the percent busy of the CPU using integer math is 22% it actually is
>> 22.85%. This value scaled to the current frequency returned 97 which
>> the PID interpreted as no error and did not adjust the P state.
>>
>> Tested on i7-4770K, i7-2600, i5-3230M
>>
>> References:
>>https://lkml.org/lkml/2014/2/19/626
>>https://bugzilla.kernel.org/show_bug.cgi?id=70941
>>
>> Signed-off-by: Dirk Brandewie
> Queued up as a fix for 3.14.
>
> Thanks!
>
>> ---
>> drivers/cpufreq/intel_pstate.c | 28 ++--
>> 1 file changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
>> index e908161..2cd36b9 100644
>> --- a/drivers/cpufreq/intel_pstate.c
>> +++ b/drivers/cpufreq/intel_pstate.c
>> @@ -39,9 +39,10 @@
>> #define BYT_TURBO_RATIOS0x66c
>>
>>
>> -#define FRAC_BITS 8
>> +#define FRAC_BITS 6
>> #define int_tofp(X) ((int64_t)(X) << FRAC_BITS)
>> #define fp_toint(X) ((X) >> FRAC_BITS)
>> +#define FP_ROUNDUP(X) ((X) += 1 << FRAC_BITS)
>>
>> static inline int32_t mul_fp(int32_t x, int32_t y)
>> {
>> @@ -556,18 +557,20 @@ static void intel_pstate_get_cpu_pstates(struct
>> cpudata *cpu)
>> static inline void intel_pstate_calc_busy(struct cpudata *cpu,
>> struct sample *sample)
>> {
>> -u64 core_pct;
>> -u64 c0_pct;
>> +int32_t core_pct;
>> +int32_t c0_pct;
>>
>> -core_pct = div64_u64(sample->aperf * 100, sample->mperf);
>> +core_pct = div_fp(int_tofp((sample->aperf)),
>> +int_tofp((sample->mperf)));
>> +core_pct = mul_fp(core_pct, int_tofp(100));
>> +FP_ROUNDUP(core_pct);
>> +
>> +c0_pct = div_fp(int_tofp(sample->mperf), int_tofp(sample->tsc));
>>
>> -c0_pct = div64_u64(sample->mperf * 100, sample->tsc);
>> sample->freq = fp_toint(
>> -mul_fp(int_tofp(cpu->pstate.max_pstate),
>> -int_tofp(core_pct * 1000)));
>> +mul_fp(int_tofp(cpu->pstate.max_pstate * 1000), core_pct));
>>
>> -sample->core_pct_busy = mul_fp(int_tofp(core_pct),
>> -div_fp(int_tofp(c0_pct + 1), int_tofp(100)));
>> +sample->core_pct_busy = mul_fp(core_pct, c0_pct);
>> }
>>
>> static inline void intel_pstate_sample(struct cpudata *cpu)
>> @@ -579,6 +582,10 @@ static inline void intel_pstate_sample(struct cpudata
>> *cpu)
>> rdmsrl(MSR_IA32_MPERF, mperf);
>> tsc = native_read_tsc();
>>
>> +aperf = aperf >> FRAC_BITS;
>> +mperf = mperf >> FRAC_BITS;
>> +tsc = tsc >> FRAC_BITS;
>> +
>> cpu->sample_ptr = (cpu->sample_ptr + 1) % SAMPLE_COUNT;
>> cpu->samples[cpu->sample_ptr].aperf = aperf;
>> cpu->samples[cpu->sample_ptr].mperf = mperf;
>> @@ -610,7 +617,8 @@ static inline int32_t
>> intel_pstate_get_scaled_busy(struct cpudata *cpu)
>> core_busy = cpu->samples[cpu->sample_ptr].core_pct_busy;
>> max_pstate = int_tofp(cpu->pstate.max_pstate);
>> current_pstate = int_tofp(cpu->pstate.current_pstate);
>> -return mul_fp(core_busy, div_fp(max_pstate, current_pstate));
>> +core_busy = mul_fp(core_busy, div_fp(max_pstate, current_pstate));
>> +return FP_ROUNDUP(core_busy);
>> }
>>
>> static inline void intel_pstate_adjust_busy_pstate(struct cpudata *cpu)
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.14-rc4 xHCI] Regression haswell B85 with xHCI on
I migrated my system from H77 Ivy-bridge to a haswell Platform B85 i3-4330. The system has three dvb-c usb receivers connected. On the Ivy Platform everything runs fine with xHCI. On the haswell Platform xHCI explodes with following messages: 2014-02-27T16:45:53.518332+01:00 vnas kernel: [ 222.218703] xhci_hcd :00:14.0: xHCI host not responding to stop endpoint command. 2014-02-27T16:45:53.518342+01:00 vnas kernel: [ 222.218712] xhci_hcd :00:14.0: Assuming host is dying, halting host. 2014-02-27T16:45:53.518346+01:00 vnas kernel: [ 222.218808] xhci_hcd :00:14.0: HC died; cleaning up 2014-02-27T16:45:53.518349+01:00 vnas kernel: [ 222.218870] usb 1-1: USB disconnect, device number 2 2014-02-27T16:45:53.518351+01:00 vnas kernel: [ 222.218880] usb 1-1.2: USB disconnect, device number 7 2014-02-27T16:45:53.518353+01:00 vnas kernel: [ 222.218979] em2884 #0: writing to i2c device at 0x52 failed (error=-19) 2014-02-27T16:45:53.518356+01:00 vnas kernel: [ 222.218988] drxk: i2c write error at addr 0x29 2014-02-27T16:45:53.518358+01:00 vnas kernel: [ 222.218993] em2884 #2: writing to i2c device at 0x52 failed (error=-19) 2014-02-27T16:45:53.518361+01:00 vnas kernel: [ 222.218997] drxk: i2c write error at addr 0x29 2014-02-27T16:45:53.518364+01:00 vnas kernel: [ 222.219001] drxk: write_block: i2c write error at addr 0x831ffd 2014-02-27T16:45:53.518366+01:00 vnas kernel: [ 222.219006] drxk: write_block: i2c write error at addr 0x831ffd 2014-02-27T16:45:53.518368+01:00 vnas kernel: [ 222.219012] em2884 #1: writing to i2c device at 0x52 failed (error=-19) 2014-02-27T16:45:53.518371+01:00 vnas kernel: [ 222.219017] drxk: i2c write error at addr 0x29 2014-02-27T16:45:53.518373+01:00 vnas kernel: [ 222.219021] drxk: write_block: i2c write error at addr 0x831ffd 2014-02-27T16:45:53.518375+01:00 vnas kernel: [ 222.219070] em2884 #0: Disconnecting em2884 #0 2014-02-27T16:45:53.518962+01:00 vnas kernel: [ 222.219076] em2884 #0: Closing audio extension This happens when more then one DVB-C receiver is connected. With only one it works. If I disable xHCI Mode in Bios and run only with EHCI. Everything is running fine either. lsusb: Bus 001 Device 002: ID 8087:8008 Intel Corp. Bus 002 Device 002: ID 8087:8000 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 003: ID 2109:2811 Bus 002 Device 004: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light Bus 002 Device 005: ID 03eb:201l3 Atmel Corp. Bus 002 Device 006: ID 9e88:9e8f Bus 002 Device 007: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB Bus 002 Device 008: ID 2040:1605 Hauppauge Bus 002 Device 009: ID 2040:1605 Hauppauge Bus 002 Device 010: ID 2040:1605 Hauppauge Bus 002 Device 011: ID 04e6:5116 SCM Microsystems, Inc. SCR331-LC1 / SCR3310 SmartCard Reader Bus 002 Device 012: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 002 Device 013: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light Bus 002 Device 014: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light lspci: xHCI disabled: 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5) 00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family
[3.14-rc3] possible regression Haswell runs only at 770Mhz with powersave governor
Hello, My System which runs with older kernels up to 3.13.3 fine on my i3-4330 with 3.5 Ghz and governor powersave. and pstate driver. With kernel 3.14-rc3 and Governor powersave it runs only at 770Mhz and never switches to higher Freq. on load. Even compiling a kernel with make -j4 does not change freq. With governor performance it switches to 3.5 Ghz and stays there. Any Idea how to fix this? Best regards -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.14-rc3] possible regression Haswell runs only at 770Mhz with powersave governor
Am 20.02.2014 17:48, schrieb Dirk Brandewie: > On 02/20/2014 07:01 AM, Borislav Petkov wrote: >> Add lists to CC. >> >> On Thu, Feb 20, 2014 at 03:32:36PM +0100, Otto Meier wrote: >>> Hello, >>> >>> My System which runs with older kernels up to 3.13.3 >>> fine on my i3-4330 with 3.5 Ghz and governor powersave. >>> and pstate driver. >>> >>> With kernel 3.14-rc3 and Governor powersave it runs >>> only at 770Mhz and never switches to higher Freq. on load. >>> Even compiling a kernel with make -j4 does not change freq. >>> > > commit fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4 seems to be the culprit > >>> With governor performance it switches to 3.5 Ghz and stays >>> there. >>> >>> Any Idea how to fix this? >>> > > Greg KH is seeing the same thing on his Haswell system. I am trying > to figure what went south. > > https://lkml.org/lkml/2014/2/19/626 > > > Can you send me the .config for the broken kernel also the output of > gcc -v > > > >>> Best regards >> > > > Hello I reverted the mentioned commit. it now seams to work. But total idle power comsumption is aprox. 5 Watts higher as running kernel 3.13.3. Measured with a true rms powermeter on primery side. gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.8 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux) .config: # # Power management and ACPI options # CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATE_CALLBACKS=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_AUTOSLEEP=y CONFIG_PM_WAKELOCKS=y CONFIG_PM_WAKELOCKS_LIMIT=100 CONFIG_PM_WAKELOCKS_GC=y CONFIG_PM_RUNTIME=y CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_PM_ADVANCED_DEBUG=y # CONFIG_PM_TEST_SUSPEND is not set CONFIG_PM_SLEEP_DEBUG=y # CONFIG_DPM_WATCHDOG is not set CONFIG_PM_TRACE=y CONFIG_PM_TRACE_RTC=y CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_EC_DEBUGFS is not set CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_PROCESSOR_AGGREGATOR=m CONFIG_ACPI_THERMAL=m CONFIG_ACPI_NUMA=y CONFIG_ACPI_CUSTOM_DSDT_FILE="" # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_INITRD_TABLE_OVERRIDE=y CONFIG_ACPI_DEBUG=y CONFIG_ACPI_PCI_SLOT=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y # CONFIG_ACPI_SBS is not set # CONFIG_ACPI_HED is not set # CONFIG_ACPI_CUSTOM_METHOD is not set CONFIG_ACPI_BGRT=y CONFIG_ACPI_APEI=y # CONFIG_ACPI_APEI_GHES is not set CONFIG_ACPI_APEI_PCIEAER=y # CONFIG_ACPI_APEI_MEMORY_FAILURE is not set # CONFIG_ACPI_APEI_EINJ is not set # CONFIG_ACPI_APEI_ERST_DEBUG is not set # CONFIG_ACPI_EXTLOG is not set CONFIG_SFI=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_COMMON=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m bye -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xhci USB3 on h87 does behave buggy
I just changed MB for my Home Server from GA75N to H87-ITX. Attached to this server I run 3 WINTV HVR 930C DVB-C usb receivers. with the Series Seven MB everything works as it should. with the H87 MB the USB3 Stack crashed as soon as i get more then one Stream from the DVB-C receivers. the Error Message is: 2013-12-07T12:29:23.935232+01:00 vnas kernel: [ 591.234611] xhci_hcd :00:14.0: xHCI host not responding to stop endpoint command. 2013-12-07T12:29:23.935243+01:00 vnas kernel: [ 591.234614] xhci_hcd :00:14.0: Assuming host is dying, halting host. 2013-12-07T12:29:23.935244+01:00 vnas kernel: [ 591.234662] xhci_hcd :00:14.0: HC died; cleaning up 2013-12-07T12:29:23.935248+01:00 vnas kernel: [ 591.234679] usb 3-3: USB disconnect, device number 2 2013-12-07T12:29:23.935249+01:00 vnas kernel: [ 591.234681] usb 3-3.1: USB disconnect, device number 6 2013-12-07T12:29:23.935505+01:00 vnas pcscd[2715]: 48591788 ifdwrapper.c:348:IFDStatusICC() Card not transacted: 612 2013-12-07T12:29:23.935688+01:00 vnas pcscd[2715]: 0008 eventhandler.c:303:EHStatusHandlerThread() Error communicating to: SCR3310 Smart Card Reader [CCID Interface (21120519102521) 00 00 2013-12-07T12:29:23.936112+01:00 vnas kernel: [ 591.234802] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1 2013-12-07T12:29:23.936116+01:00 vnas kernel: [ 591.234811] cp210x 3-3.1:1.0: device disconnected 2013-12-07T12:29:23.937251+01:00 vnas kernel: [ 591.236161] em2884 #0: writing to i2c device at 0x52 failed (error=-5) 2013-12-07T12:29:23.937256+01:00 vnas kernel: [ 591.236163] drxk: i2c write error at addr 0x29 2013-12-07T12:29:23.937257+01:00 vnas kernel: [ 591.236165] drxk: write_block: i2c write error at addr 0x831ffd 2013-12-07T12:29:23.937258+01:00 vnas kernel: [ 591.236168] em2884 #1: writing to i2c device at 0x52 failed (error=-5) 2013-12-07T12:29:23.937258+01:00 vnas kernel: [ 591.236169] drxk: i2c read error at addr 0x29 2013-12-07T12:29:23.937259+01:00 vnas kernel: [ 591.236201] usb 3-3.2: USB disconnect, device number 7 2013-12-07T12:29:23.937259+01:00 vnas kernel: [ 591.236307] em2884 #1: writing to i2c device at 0xc2 failed (error=-19) 2013-12-07T12:29:23.937260+01:00 vnas kernel: [ 591.236309] xc5000: I2C read failed 2013-12-07T12:29:23.937269+01:00 vnas kernel: [ 591.236310] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... 2013-12-07T12:29:23.937270+01:00 vnas kernel: [ 591.236327] xc5000: firmware read 12401 bytes. 2013-12-07T12:29:23.937270+01:00 vnas kernel: [ 591.236327] xc5000: firmware uploading... 2013-12-07T12:29:23.937271+01:00 vnas kernel: [ 591.236330] em2884 #1: writing to i2c device at 0xc2 failed (error=-19) 2013-12-07T12:29:23.937271+01:00 vnas kernel: [ 591.236331] xc5000: I2C write failed (len=3) 2013-12-07T12:29:23.937272+01:00 vnas kernel: [ 591.236332] xc5000: firmware upload failed... 2013-12-07T12:29:23.937272+01:00 vnas kernel: [ 591.236335] em2884 #1: writing to i2c device at 0x52 failed (error=-19) 2013-12-07T12:29:23.937273+01:00 vnas kernel: [ 591.236336] drxk: i2c read error at addr 0x29 2013-12-07T12:29:23.937273+01:00 vnas kernel: [ 591.236337] drxk: Error -19 on mpegts_stop 2013-12-07T12:29:23.937274+01:00 vnas kernel: [ 591.236338] em2884 #1: writing to i2c device at 0x52 failed (error=-19) 2013-12-07T12:29:23.937274+01:00 vnas kernel: [ 591.236338] drxk: i2c write error at addr 0x29 2013-12-07T12:29:23.937275+01:00 vnas kernel: [ 591.236339] drxk: Error -19 on setoperation_mode 2013-12-07T12:29:23.937275+01:00 vnas kernel: [ 591.236340] drxk: Error -22 on start 2013-12-07T12:29:23.937276+01:00 vnas kernel: [ 591.236372] drxk: Error -22 on get_lock_status No USB device is working anymore this is only fixable with reboot. With only one DVB-C receiver attached everthing is working. if have tried kernel 3.11.10 3.12.3 3.13-rc3. SO: The system works fine with H75 usb3 xhci. the System crashes with H87 usb3 xhci and more than one DVB-C receivers streaming. Any Idea how to fix? Bye -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] wrong pinning definition or uart_c in pinctrl-meson-gxbb.c
Hi i tried to use uart_C of the the odroid-c2.
I enabled it int the dts file. During boot it crashed when the
the sdcard slot is addressd.
After long search in the net i found this:
https://forum.odroid.com/viewtopic.php?f=139&t=25371&p=194370&hilit=uart_C#p177856
After changing the pin definitios accordingly erverything works.
Uart_c is functioning and sdcard ist working.
Patch attached
Bye Otto
Hi i tried to use uart_C of the the odroid-c2.
I enabled it int the dts file. During boot it crashed when the
the sdcard slot is addressd.
After long search in the net i found this:
https://forum.odroid.com/viewtopic.php?f=139&t=25371&p=194370&hilit=uart_C#p177856
After changing the pin definitios accordingly erverything works.
Uart_c is functioning and sdcard ist working.
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c2019-08-26 18:24:45.450089334 +0200
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c2019-09-05 13:07:38.518637214 +0200
@@ -192,8 +192,8 @@ static const unsigned int uart_rts_b_pin
static const unsigned int uart_tx_c_pins[] = { GPIOY_13 };
static const unsigned int uart_rx_c_pins[] = { GPIOY_14 };
-static const unsigned int uart_cts_c_pins[]= { GPIOX_11 };
-static const unsigned int uart_rts_c_pins[]= { GPIOX_12 };
+static const unsigned int uart_cts_c_pins[]= { GPIOY_11 };
+static const unsigned int uart_rts_c_pins[]= { GPIOY_12 };
static const unsigned int i2c_sck_a_pins[] = { GPIODV_25 };
static const unsigned int i2c_sda_a_pins[] = { GPIODV_24 };
@@ -439,10 +439,10 @@ static struct meson_pmx_group meson_gxbb
GROUP(pwm_f_x, 3, 18),
/* Bank Y */
- GROUP(uart_cts_c, 1, 19),
- GROUP(uart_rts_c, 1, 18),
- GROUP(uart_tx_c,1, 17),
- GROUP(uart_rx_c,1, 16),
+ GROUP(uart_cts_c, 1, 17),
+ GROUP(uart_rts_c, 1, 16),
+ GROUP(uart_tx_c,1, 19),
+ GROUP(uart_rx_c,1, 18),
GROUP(pwm_a_y, 1, 21),
GROUP(pwm_f_y, 1, 20),
GROUP(i2s_out_ch23_y, 1, 5),
signed off Otto Meier gf...@gmx.net
[PATCH] fix Uart_C Pinning of odroidc2 in linux-4.12.-rc7
Please find attached a fix for wrong uart_c pinning of odroid-c2
in mainline kernels
Regards
Otto
--- linux-next-20170623/drivers/pinctrl/meson/pinctrl-meson-gxbb.c.orig 2017-06-23 11:30:35.072037057 +0200
+++ linux-next-20170623/drivers/pinctrl/meson/pinctrl-meson-gxbb.c 2017-06-26 12:31:27.161783467 +0200
@@ -202,8 +202,8 @@ static const unsigned int uart_rts_b_pin
static const unsigned int uart_tx_c_pins[] = { PIN(GPIOY_13, EE_OFF) };
static const unsigned int uart_rx_c_pins[] = { PIN(GPIOY_14, EE_OFF) };
-static const unsigned int uart_cts_c_pins[] = { PIN(GPIOX_11, EE_OFF) };
-static const unsigned int uart_rts_c_pins[] = { PIN(GPIOX_12, EE_OFF) };
+static const unsigned int uart_cts_c_pins[] = { PIN(GPIOY_11, EE_OFF) };
+static const unsigned int uart_rts_c_pins[] = { PIN(GPIOY_12, EE_OFF) };
static const unsigned int i2c_sck_a_pins[] = { PIN(GPIODV_25, EE_OFF) };
static const unsigned int i2c_sda_a_pins[] = { PIN(GPIODV_24, EE_OFF) };
@@ -444,10 +444,10 @@ static struct meson_pmx_group meson_gxbb
GROUP(pwm_f_x, 3, 18),
/* Bank Y */
- GROUP(uart_cts_c, 1, 19),
- GROUP(uart_rts_c, 1, 18),
- GROUP(uart_tx_c, 1, 17),
- GROUP(uart_rx_c, 1, 16),
+ GROUP(uart_cts_c, 1, 17),
+ GROUP(uart_rts_c, 1, 16),
+ GROUP(uart_tx_c, 1, 19),
+ GROUP(uart_rx_c, 1, 18),
GROUP(pwm_a_y, 1, 21),
GROUP(pwm_f_y, 1, 20),
GROUP(i2s_out_ch23_y, 1, 5),
