Re: small patch to avoid warning in gcc 6
On Tue, Jun 7, 2016 at 6:47 PM, Joe Perches wrote:
> On Tue, 2016-06-07 at 18:41 -0600, Reinoud Koornstra wrote:
>> Hello Everybody,
>>
>> A small patch that doesn't really do anything other than getting rid
>> of a warning in gcc 6.1.0.
>>
>> drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dump_lrc’:
>> drivers/gpu/drm/i915/i915_debugfs.c:2060:6: warning: suggest explicit
>> braces to avoid ambiguous ‘else’ [-Wparentheses]
>>if (ctx != dev_priv->kernel_context)
>> ^
>
> Likely there should be 2 pairs of braces added:
>
> list_for_each_entry(ctx, &dev_priv->context_list, link) {
> if (ctx != dev_priv->kernel_context) {
> for_each_ring(ring, dev_priv, i)
> i915_dump_lrc_obj(m, ctx, ring);
> }
> }
>
Added in version 2 of the patch.
The previous patch already got rid of the warning, but this one adds
braces to the loop as well.
Thanks,
Reinoud.
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index a0f1bd7..a48d228 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2056,10 +2056,12 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
if (ret)
return ret;
- list_for_each_entry(ctx, &dev_priv->context_list, link)
- if (ctx != dev_priv->kernel_context)
+ list_for_each_entry(ctx, &dev_priv->context_list, link) {
+ if (ctx != dev_priv->kernel_context) {
for_each_ring(ring, dev_priv, i)
i915_dump_lrc_obj(m, ctx, ring);
+ }
+ }
mutex_unlock(&dev->struct_mutex);
small patch to avoid warning in gcc 6
Hello Everybody,
A small patch that doesn't really do anything other than getting rid
of a warning in gcc 6.1.0.
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dump_lrc’:
drivers/gpu/drm/i915/i915_debugfs.c:2060:6: warning: suggest explicit
braces to avoid ambiguous ‘else’ [-Wparentheses]
if (ctx != dev_priv->kernel_context)
^
Thanks,
Reinoud.
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index a0f1bd7..0e30887 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2057,9 +2057,10 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
return ret;
list_for_each_entry(ctx, &dev_priv->context_list, link)
- if (ctx != dev_priv->kernel_context)
+ if (ctx != dev_priv->kernel_context) {
for_each_ring(ring, dev_priv, i)
i915_dump_lrc_obj(m, ctx, ring);
+ }
mutex_unlock(&dev->struct_mutex);
Re: pull-request: wireless-drivers-next 2016-05-13 (take two)
On Thu, May 19, 2016 at 6:45 AM, Kalle Valo wrote: > Hi Dave, > > this the second version of the last pull request to net-next for 4.7, > which got postponed due to the recent iwlwifi merge conflict. Now that > Linus fixed the merge problem in his tree I actually didn't have to fix > anything in my tree anymore. So that's why I still use the same tag as > in my previous pull request. > > The only dependency is that you need Linus' iwlwifi fix in your tree > before you pull this: > > 0e034f5c4bc4 iwlwifi: fix mis-merge that breaks the driver > > So if you could pull latest Linus' tree to net-next that would solve > that. I just did a test merge of that on your net-next tree and didn't > see any conflicts, so this pull should go smoothly. Also these patches > have been in linux-next at least a week now. But please let me know if > you see any issues. > > And I think a lesson learned from this is that I need to immediately > merge wireless-drivers to wireless-drivers-next if there are any > conflicts between the trees. Or how do you suggest to handle cases like > that? > > Kalle > > > The following changes since commit ede00a5ceb4d903a8c137a52bb77d574baaef8bd: > > Merge tag 'wireless-drivers-next-for-davem-2016-05-02' of > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next > (2016-05-03 00:35:16 -0400) > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git > tags/wireless-drivers-next-for-davem-2016-05-13 > > for you to fetch changes up to 52776a700b53969345a3cc5daed1c797d016a188: > > Merge ath-next from ath.git (2016-05-11 23:23:51 +0300) > > > > wireless-drivers patches for 4.7 > > Major changes: > > iwlwifi > > * remove IWLWIFI_DEBUG_EXPERIMENTAL_UCODE kconfig option > * work for RX multiqueue continues > * dynamic queue allocation work continues > * add Luca as maintainer > * a bunch of fixes and improvements all over Can you let me know when this is merged in 4.6+, then I'll try it right away. Thanks, Reinoud. > > brcmfmac > > * add 4356 sdio support > > ath6kl > > * add ability to set debug uart baud rate with a module parameter > > wil6210 > > * add debugfs file to configure firmware led functionality > > > Alan Liu (1): > ath10k: add max_tx_power for QCA6174 WLAN.RM.2.0 firmware > > Anilkumar Kolli (1): > ath10k: fix kernel panic, move arvifs list head init before htt init > > Bjorn Andersson (1): > wcn36xx: Set SMD timeout to 10 seconds > > Christian Daudt (1): > brcmfmac: Add 4356 sdio support > > Dan Carpenter (3): > rtlwifi: rtl818x: silence uninitialized variable warning > airo: prevent potential underflow in airo_set_freq() > atmel: potential underflow in atmel_set_freq() > > Denys Vlasenko (1): > rtlwifi: rtl818x: Deinline indexed IO functions, save 21568 bytes > > Emmanuel Grumbach (5): > iwlwifi: mvm: don't override the rate with the AMSDU len > iwlwifi: mvm: allow a debug knob for Tx A-MSDU even if rate control > forbids it > iwlwifi: remove IWLWIFI_DEBUG_EXPERIMENTAL_UCODE > iwlwifi: don't access a nonexistent register upon assert > iwlwifi: add default value to disable_11ac mod param description > > Golan Ben-Ami (1): > iwlwifi: mvm: add more registers to dump upon error > > Gregory Greenman (2): > iwlwifi: consider VHT 160MHz while parsing NVM > iwlwifi: turn on SGI support for VHT 160MHz > > Guy Mishol (1): > wlcore/wl12xx: Fix fw logger over sdio > > Haim Dreyfuss (4): > iwlwifi: Rename 9560 to 9260 and add new PCI IDs for it > iwlwifi: allow combining different phy images with mac images > iwlwifi: Fix firmware name maximum length definition > iwlwifi: pcie: don't wake up the NIC when writing CSRs in MSIX mode > > Helmut Schaa (4): > ath9k: reuse ar9003_hw_tx_power_regwrite for tx99 setup > ath9k: Move TX99 config option under ath9k debugging > ath9k: Simplify ar9003_hw_tx99_set_txpower > ath9k: Fix symbol overlap window for half/quarter channels > > Jes Sorensen (11): > rtl8xxxu: Rename rtl8xxxu.c to rtl8xxxu_core.c > rtl8xxxu: move rtl8192e related code into rtl8xxxu_8192e.c > rtl8xxxu: move rtl8723b related code into rtl8xxxu_8723b.c > rtl8xxxu: move rtl8723a related code into rtl8xxxu_8723a.c > rtl8xxxu: move rtl8188[cr] and rtl8192c related code into > rtl8xxxu_8192c.c > rtl8xxxu: Rename rtl8723a_stop_tx_beacon() to rtl8xxxu_stop_tx_beacon() > rtl8xxxu: rename rtl8723a_channel_group() to > rtl8xxxu_gen1_channel_to_group() > rtl8xxxu: Rename rtl8723a_disabled_to_emu() to > rtl8xxxu_disabled_to_emu() > rtl8xxxu: Split rtl8723a_h2c_cmd() into a gen1 and a gen2 version > rtl8xxxu: rtl8xxxu_prepare_calibrate() is never used on gen1 >
Re: [GIT] Networking
On Thu, May 19, 2016 at 2:20 AM, Reinoud Koornstra
wrote:
> On Wed, May 18, 2016 at 12:51 PM, Linus Torvalds
> wrote:
>> On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
>> wrote:
>>>
>>> From what I can tell, there's a merge bug in commit 909b27f70643,
>>> where David seems to have lost some of the changes to
>>> iwl_mvm_set_tx_cmd().
>>>
>>> I do not know if that's the reason for the problem I see. But I will test.
>>
>> Yes. The attached patch that fixes the incorrect merge seems to fix
>> things for me.
>>
>> That should mean that the assumption that this problem existed in v4.6
>> too was wrong, because the incorrect merge came in later. I think
>> Luciano mis-understood "v4.6+" to mean plain v4.6.
>>
>> Reinoud Koornstra, does this patch fix things for you too?
>
> Indeed, I meant 4.6+, not 4.6.
> The patch you attached doesn't change existing code for me in 4.6+ as
> these two lines are already in there.
> Thanks,
>
> Reinoud.
>
In the 4.6+ code from today I reverted commit 5c08b0f5026f.
Now iwlwifi works fine for me again.
So it's as the Intel guys suspected.
I'll attached my revert compared to the current 4.6+ development code.
Thanks,
Reinoud.
>>
>>Linus
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index c53aa0f..00c9298 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,7 +211,6 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff
*skb,
struct iwl_tx_cmd *tx_cmd,
struct ieee80211_tx_info *info, u8 sta_id)
{
- struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 fc = hdr->frame_control;
u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -295,7 +294,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff
*skb,
tx_cmd->tx_flags = cpu_to_le32(tx_flags);
/* Total # bytes to be transmitted */
tx_cmd->len = cpu_to_le16((u16)skb->len +
- (uintptr_t)skb_info->driver_data[0]);
+ (uintptr_t)info->driver_data[0]);
tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
tx_cmd->sta_id = sta_id;
@@ -443,11 +442,10 @@ static void iwl_mvm_set_tx_cmd_crypto(struct iwl_mvm *mvm,
*/
static struct iwl_device_cmd *
iwl_mvm_set_tx_params(struct iwl_mvm *mvm, struct sk_buff *skb,
- struct ieee80211_tx_info *info, int hdrlen,
- struct ieee80211_sta *sta, u8 sta_id)
+ int hdrlen, struct ieee80211_sta *sta, u8 sta_id)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
- struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct iwl_device_cmd *dev_cmd;
struct iwl_tx_cmd *tx_cmd;
@@ -467,10 +465,10 @@ iwl_mvm_set_tx_params(struct iwl_mvm *mvm, struct sk_buff
*skb,
iwl_mvm_set_tx_cmd_rate(mvm, tx_cmd, info, sta, hdr->frame_control);
- memset(&skb_info->status, 0, sizeof(skb_info->status));
- memset(skb_info->driver_data, 0, sizeof(skb_info->driver_data));
+ memset(&info->status, 0, sizeof(info->status));
+ memset(info->driver_data, 0, sizeof(info->driver_data));
- skb_info->driver_data[1] = dev_cmd;
+ info->driver_data[1] = dev_cmd;
return dev_cmd;
}
@@ -478,25 +476,22 @@ iwl_mvm_set_tx_params(struct iwl_mvm *mvm, struct sk_buff
*skb,
int iwl_mvm_tx_skb_non_sta(struct iwl_mvm *mvm, struct sk_buff *skb)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
- struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
- struct ieee80211_tx_info info;
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct iwl_device_cmd *dev_cmd;
struct iwl_tx_cmd *tx_cmd;
u8 sta_id;
int hdrlen = ieee80211_hdrlen(hdr->frame_control);
- memcpy(&info, skb->cb, sizeof(info));
-
- if (WARN_ON_ONCE(info.flags & IEEE80211_TX_CTL_AMPDU))
+ if (WARN_ON_ONCE(info->flags & IEEE80211_TX_CTL_AMPDU))
return -1;
- if (WARN_ON_ONCE(info.flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM &&
-(!info.control.vif ||
- info.hw_queue != info.control.vif->cab_queue)))
+ if (WARN_ON_ONCE(info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM &&
+(!info->control.vif ||
+ info->hw_queue != inf
Re: [GIT] Networking
On Wed, May 18, 2016 at 12:51 PM, Linus Torvalds wrote: > On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds > wrote: >> >> From what I can tell, there's a merge bug in commit 909b27f70643, >> where David seems to have lost some of the changes to >> iwl_mvm_set_tx_cmd(). >> >> I do not know if that's the reason for the problem I see. But I will test. > > Yes. The attached patch that fixes the incorrect merge seems to fix > things for me. > > That should mean that the assumption that this problem existed in v4.6 > too was wrong, because the incorrect merge came in later. I think > Luciano mis-understood "v4.6+" to mean plain v4.6. > > Reinoud Koornstra, does this patch fix things for you too? Indeed, I meant 4.6+, not 4.6. The patch you attached doesn't change existing code for me in 4.6+ as these two lines are already in there. Thanks, Reinoud. > >Linus
Re: [GIT] Networking
On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano
wrote:
> On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
>> On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
>> wrote:
>> >
>> > Hi Emmanuel, Linus,
>> >
>> >
>> > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
>> > >
>> > > On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
>> > > wrote:
>> > > >
>> > > >
>> > > > On Tue, May 17, 2016 at 12:11 PM, David Miller > > > > .net
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > >
>> > > > > Highlights:
>> > > > Lowlights:
>> > > >
>> > > > 1) the iwlwifi driver seems to be broken
>> > > >
>> > > > My laptop that uses the intel 7680 iwlwifi module no longer
>> > > > connects
>> > > > to the network. It fails with a "Microcode SW error detected."
>> > > > and
>> > > > spews out register state over and over again.
>> > > Can we have the register state and the ASSERT / NMI / whatever
>> > > that
>> > > goes along with it?
>> > > This clearly means that the firmware is crashing, but I don't
>> > > know
>> > > why,
>> > > I copied here the lines that I need from another bug with another
>> > > device with another firmware,
>> > > but the log that we will still explain what I need:
>> > I managed to reproduce this bug locally with Linus' master. I'm
>> > investigating the cause and I'll let you how it goes.
>> I did run the latest git code as well 4.6+
>> iwlwifi went pearshape in my case as well.
>> I just updated the microcode as well, it didn't matter.
>> 4.6-rc7 works fine and no errors are reported with iwlwifi.
>>
>> Here's output that might come in handy
>
> Thanks! That is helpful.
>
> Since you say that 4.6-rc7 works but 4.6 doesn't, the prime suspect is
> commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the
> AMSDU len"), which is the only iwlwifi patch between those two
> releases.
>
> Could you try to revert that and see if the error is gone?
Will do, since git revert failed I'll revert manually and report back.
>
> --
> Cheers,
> Luca.
Re: [GIT] Networking
On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano wrote: > Hi Emmanuel, Linus, > > > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote: >> On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds >> wrote: >> > >> > On Tue, May 17, 2016 at 12:11 PM, David Miller > > > wrote: >> > > >> > > >> > > Highlights: >> > Lowlights: >> > >> > 1) the iwlwifi driver seems to be broken >> > >> > My laptop that uses the intel 7680 iwlwifi module no longer >> > connects >> > to the network. It fails with a "Microcode SW error detected." and >> > spews out register state over and over again. >> Can we have the register state and the ASSERT / NMI / whatever that >> goes along with it? >> This clearly means that the firmware is crashing, but I don't know >> why, >> I copied here the lines that I need from another bug with another >> device with another firmware, >> but the log that we will still explain what I need: > > I managed to reproduce this bug locally with Linus' master. I'm > investigating the cause and I'll let you how it goes. I did run the latest git code as well 4.6+ iwlwifi went pearshape in my case as well. I just updated the microcode as well, it didn't matter. 4.6-rc7 works fine and no errors are reported with iwlwifi. Here's output that might come in handy [ 17.436340] iwlwifi :04:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm [ 17.714920] iwlwifi :04:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 SNIP [ 114.837923] wlp4s0: authenticate with 00:30:44:1d:cf:2b [ 114.841365] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3) [ 114.842073] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 2/3) [ 115.041992] iwlwifi :04:00.0: Microcode SW error detected. Restarting 0x200. [ 115.041995] iwlwifi :04:00.0: CSR values: [ 115.041996] iwlwifi :04:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG) [ 115.042000] iwlwifi :04:00.0:CSR_HW_IF_CONFIG_REG: 0X40489204 [ 115.042003] iwlwifi :04:00.0: CSR_INT_COALESCING: 0X8040 [ 115.042006] iwlwifi :04:00.0: CSR_INT: 0X [ 115.042009] iwlwifi :04:00.0:CSR_INT_MASK: 0X [ 115.042013] iwlwifi :04:00.0: CSR_FH_INT_STATUS: 0X [ 115.042016] iwlwifi :04:00.0: CSR_GPIO_IN: 0X [ 115.042019] iwlwifi :04:00.0: CSR_RESET: 0X [ 115.042022] iwlwifi :04:00.0:CSR_GP_CNTRL: 0X080403c5 [ 115.042026] iwlwifi :04:00.0: CSR_HW_REV: 0X0144 [ 115.042029] iwlwifi :04:00.0: CSR_EEPROM_REG: 0X [ 115.042032] iwlwifi :04:00.0: CSR_EEPROM_GP: 0X8000 [ 115.042035] iwlwifi :04:00.0: CSR_OTP_GP_REG: 0X803a [ 115.042038] iwlwifi :04:00.0: CSR_GIO_REG: 0X001f0044 [ 115.042042] iwlwifi :04:00.0:CSR_GP_UCODE_REG: 0X [ 115.042045] iwlwifi :04:00.0: CSR_GP_DRIVER_REG: 0X [ 115.042048] iwlwifi :04:00.0: CSR_UCODE_DRV_GP1: 0X [ 115.042051] iwlwifi :04:00.0: CSR_UCODE_DRV_GP2: 0X [ 115.042054] iwlwifi :04:00.0: CSR_LED_REG: 0X0060 [ 115.042058] iwlwifi :04:00.0:CSR_DRAM_INT_TBL_REG: 0X88035a74 [ 115.042061] iwlwifi :04:00.0:CSR_GIO_CHICKEN_BITS: 0X27800200 [ 115.042064] iwlwifi :04:00.0: CSR_ANA_PLL_CFG: 0Xd5d5 [ 115.042067] iwlwifi :04:00.0: CSR_MONITOR_STATUS_REG: 0X3d0801bd [ 115.042070] iwlwifi :04:00.0: CSR_HW_REV_WA_REG: 0X0001001a [ 115.042074] iwlwifi :04:00.0:CSR_DBG_HPET_MEM_REG: 0X [ 115.042075] iwlwifi :04:00.0: FH register values: [ 115.042086] iwlwifi :04:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X455fd200 [ 115.042097] iwlwifi :04:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X04556370 [ 115.042108] iwlwifi :04:00.0: FH_RSCSR_CHNL0_WPTR: 0X0078 [ 115.042119] iwlwifi :04:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X00801114 [ 115.042129] iwlwifi :04:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X00fc [ 115.042140] iwlwifi :04:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X0303 [ 115.042151] iwlwifi :04:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X [ 115.042162] iwlwifi :04:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001 [ 115.042173] iwlwifi :04:00.0: FH_TSSR_TX_ERROR_REG: 0X [ 115.042278] iwlwifi :04:00.0: Start IWL Error Log Dump: [ 115.042279] iwlwifi :04:00.0: Status: 0x, count: 6 [ 115.042280] iwlwifi :04:00.0: Loaded firmware version: 16.242414.0 [ 115.042281] iwlwifi :04:00.0: 0x0034 | NMI_INTERRUPT_WDG [ 115.042282] iwlwifi :04:00.0: 0x059002A0 | trm_hw_status0 [ 115.042283] iwlwifi :04:00.0: 0x | trm_hw_status1 [ 115.042284] iwlwifi :04:00.0: 0x0B2C | branchlink2 [ 115.042285] iwlwifi :04:00.0: 0x00016A90 | interruptlink
compile failure linux 3.10 with gcc 4.9.3 for mips
Hi Everyone, Did anybody enounter the following compiler problem with linux 3.10.81? gcc version is 4.9.3 for mips. arch/mips/kernel/r4k_fpu.S: Assembler messages: arch/mips/kernel/r4k_fpu.S:59: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f0,272+0($4)' arch/mips/kernel/r4k_fpu.S:60: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f2,272+16($4)' arch/mips/kernel/r4k_fpu.S:61: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f4,272+32($4)' arch/mips/kernel/r4k_fpu.S:62: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f6,272+48($4)' arch/mips/kernel/r4k_fpu.S:63: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f8,272+64($4)' arch/mips/kernel/r4k_fpu.S:64: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f10,272+80($4)' arch/mips/kernel/r4k_fpu.S:65: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f12,272+96($4)' arch/mips/kernel/r4k_fpu.S:66: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f14,272+112($4)' arch/mips/kernel/r4k_fpu.S:67: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f16,272+128($4)' arch/mips/kernel/r4k_fpu.S:68: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f18,272+144($4)' arch/mips/kernel/r4k_fpu.S:69: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f20,272+160($4)' arch/mips/kernel/r4k_fpu.S:70: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f22,272+176($4)' arch/mips/kernel/r4k_fpu.S:71: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f24,272+192($4)' arch/mips/kernel/r4k_fpu.S:72: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f26,272+208($4)' arch/mips/kernel/r4k_fpu.S:73: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f28,272+224($4)' arch/mips/kernel/r4k_fpu.S:74: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f30,272+240($4)' arch/mips/kernel/r4k_fpu.S:135: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f0,272+0($4)' arch/mips/kernel/r4k_fpu.S:136: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f2,272+16($4)' arch/mips/kernel/r4k_fpu.S:137: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f4,272+32($4)' arch/mips/kernel/r4k_fpu.S:138: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f6,272+48($4)' arch/mips/kernel/r4k_fpu.S:139: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f8,272+64($4)' arch/mips/kernel/r4k_fpu.S:140: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f10,272+80($4)' arch/mips/kernel/r4k_fpu.S:141: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f12,272+96($4)' arch/mips/kernel/r4k_fpu.S:142: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f14,272+112($4)' arch/mips/kernel/r4k_fpu.S:143: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f16,272+128($4)' arch/mips/kernel/r4k_fpu.S:144: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f18,272+144($4)' arch/mips/kernel/r4k_fpu.S:145: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f20,272+160($4)' arch/mips/kernel/r4k_fpu.S:146: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f22,272+176($4)' arch/mips/kernel/r4k_fpu.S:147: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f24,272+192($4)' arch/mips/kernel/r4k_fpu.S:148: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f26,272+208($4)' arch/mips/kernel/r4k_fpu.S:149: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f28,272+224($4)' arch/mips/kernel/r4k_fpu.S:150: Error: opcode not supported on this processor: mips3 (mips3) `ldc1 $f30,272+240($4)' Thanks, Reinoud. -- 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/
