login
Search
power_meter pci_slot hed fan container acpi_cpufreq mperf cpufreq_conservative cpufreq_userspace cpufreq_stats cpufreq_powersave dm_crypt fuse loop eeprom via_cputemp i2c_dev nvram padlock_aes aes_i586 aes_generic padlock_sha sha256_generic sha1_generic via_rng msr cpuid snd_hda_codec_realtek snd_hda_intel snd_hda_codec arc4 snd_hwdep ecb snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi b43 snd_rawmidi uvcvideo snd_seq_midi_event joydev videodev btusb snd_seq rng_core video ac battery tpm_tis v4l1_compat tpm tpm_bios output power_supply i2c_viapro snd_timer ideapad_laptop snd_seq_device serio_raw wmi mac80211 cfg80211 processor snd pcspkr i2c_core psmouse button bluetooth evdev shpchp soundcore snd_page_alloc rfkill pci_hotplug ext3 jbd mbcache raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod dm_mirror dm_region_hash dm_log dm_mod btrfs zli b_deflate crc32c libcrc32c sd_mod crc_t10dif ata_generic uhci_hcd pata_via libata ssb ehci_hcd tg3 scsi_mod usbcore pcmcia via_sdmmc mmc_core pcmcia_core 11 3f c8 85 c0 75 0a be ef ff ff ff e9 d3 00 00 00 8b 76 1c 83 ee 1c <8b> 46 1c I almost missed this posting. Please post wireless problems with linux-wireless@vger.kernel.org for better visibility. I have a BCM4312 (14e4:4315) on a netbook that does not have this problem, thus I will have to rely on your debugging. An additional difficulty is that the only changes to b43 between 2.6.36 and 2.6.37 are adding an additional PCI ID, some fixes to the SDIO driver, and some code for an 802.11n device. None of these should affect your 802.11 b/g unit. Is it possible for you to bisect between 2.6.36 and 2.6.37-rc5? I wish I could suggest some way to minimize the number of commits and builds, but the problem could be anywhere. Larry --
Hello Larry,
To be honest, I never bisected such a huge amount of commits before and
I'm somewhat afraid of doing it.
However, I think I'm able to nail the issue down to:
commit 84c164a34ffe67908a932a2d641ec1a80c2d5435 which went to 2.6.37-rc1.
Author: John W. Linville <linville@tuxdriver.com>
Date: Fri Aug 6 15:31:45 2010 -0400
b43: move hwrng registration driver to wireless core initialization
Message-ID: <1281126412-5089-1-git-send-email-linville@tuxdriver.com>
http://marc.info/?l=linux-wireless&m=128112658829379&w=2
I did 2 things:
1. I (manually) reverted 84c164a34ffe67908a932a2d641ec1a80c2d5435 from
2.6.37-rc7: The crash disappears, b43 is useable.
2. I added 84c164a34ffe67908a932a2d641ec1a80c2d5435 to 2.6.36.2: The
crash shows up as with vanilla 2.6.37-rc7.
I'm not sure why this is not reproducible for you, probably it has
something to do with the VIA Nano having a second HW-RNG driven by
via-rng. I experienced crashes in the past with earlier kernels when I
tried to move RNGs around via /sys/devices/virtual/misc/hw_random, but
never took the time to trace them down since I just got it working :)
Oh, I'm still able to trigger a crash with
$ cat /sys/devices/virtual/misc/hw_random/rng_available
on 2.6.37-rc7 without 84c164a34ffe67908a932a2d641ec1a80c2d5435 as well
as on vanilla 2.6.36.2. Probably this is (better) reproducible for you?
I suspect both (the 84c164a34ffe67908a932a2d641ec1a80c2d5435 crash as
well as the cat rng_available crash) having something to do with a
partially uninitialized rng-struct, or better: parts of the rng-struct
that are free()d too early (i.e. within its lifetime).
regards
Mario
--
Doing it right is no excuse for not meeting the schedule.
-- Plant Manager, Delphi Corporation
Thanks for finding the problem. Obviously, I did not go back far enough in the record to find the commit that you implicate. Please show the output of "egrep "B43|RNG|RANDOM" .config". It should not matter, but please try the attached patch. Larry
CONFIG_B43=m CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y CONFIG_B43_PCMCIA=y CONFIG_B43_SDIO=y CONFIG_B43_PIO=y CONFIG_B43_PHY_LP=y CONFIG_B43_LEDS=y CONFIG_B43_HWRNG=y # CONFIG_B43_DEBUG is not set CONFIG_B43LEGACY=m CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_LEDS=y CONFIG_B43LEGACY_HWRNG=y CONFIG_B43LEGACY_DEBUG=y CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y # CONFIG_B43LEGACY_DMA_MODE is not set # CONFIG_B43LEGACY_PIO_MODE is not set CONFIG_HW_RANDOM=m CONFIG_HW_RANDOM_TIMERIOMEM=m CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_GEODE=m CONFIG_HW_RANDOM_VIA=m CONFIG_HW_RANDOM_VIRTIO=m CONFIG_SSB_B43_PCI_BRIDGE=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_ANSI_CPRNG=m It will surely not matter: if CONFIG_B43_HWRNG would not have been defined, hwrng_register() would not have been reached in the dump from my first mail. If you really like me to try that patch, I'll do so when I'm awake again and will then answer you that nothing has changed :) Mario -- It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories instead of theories to suit facts. -- Sherlock Holmes by Arthur Conan Doyle
No, don't bother. I do have a different request. The byte counts for my 32-bit system do not match yours. Could you please use the following command to find the instructions that are failing? objdump -l -d drivers/char/hw_random/core.o | less Use the search to find the start of hwrng_register, then add 0x4c to the starting address. Once I see hte instruction that is failing, I should be able to find where the failure occurs. The order in which things are registered should not cause an error, but who knows? Larry --
Alright, here we go...
[ 30.012695] BUG: unable to handle kernel paging request at 4b28f458
[ 30.012708] IP: [<f90703cc>] hwrng_register+0x4c/0x139 [rng_core]
00000380 <hwrng_register>:
hwrng_register():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:299
380: 56 push %esi
381: 53 push %ebx
...
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:312
3c6: 8b 76 1c mov 0x1c(%esi),%esi
3c9: 83 ee 1c sub $0x1c,%esi
prefetch():
/tmp/1/linux-source-2.6.37-rc7/arch/x86/include/asm/processor.h:837
3cc: 8b 46 1c mov 0x1c(%esi),%eax
3cf: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi
hwrng_register():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:312
3d3: 81 fe f8 ff ff ff cmp $0xfffffff8,%esi
3d9: 75 d4 jne 3af <hwrng_register+0x2f>
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:319
312 list_for_each_entry(tmp, &rng_list, list) {
313 if (strcmp(tmp->name, rng->name) == 0)
314 goto out_unlock;
315 }
This is btw. the same data that is accessed in the cat rng_available
crash via hwrng_attr_available_show():
[ 389.303538] BUG: unable to handle kernel paging request at 288dcb5b
[ 389.303553] IP: [<f8dda34c>] hwrng_attr_available_show+0x5c/0x90 [rng_core]
000002f0 <hwrng_attr_available_show>:
hwrng_attr_available_show():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:236
2f0: 55 push %ebp
...
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:245
346: 8b 5b 1c mov 0x1c(%ebx),%ebx
349: 83 eb 1c sub $0x1c,%ebx
prefetch():
/tmp/1/linux-source-2.6.37-rc7/arch/x86/include/asm/processor.h:837
34c: 8b 43 1c mov 0x1c(%ebx),%eax
34f: 8d 74 26 00 lea ...The head of the rng_list is damaged. It is initialized at compile time and should be OK. To help discover the order in which hwrng_register() is called, apply the attached patch. Run it once with commit 84c164a34ffe67908a installed, and once with it reverted. Thanks, Larry
All right, 3 dmesg excerpts attached... 2.6.37-rc7-vanilla.dmesg: 2.6.37-rc7 vanilla (i.e. with 84c164a34ffe67908a), crashing via-rng is registered first, b43-rng second 2.6.37-rc7-without.dmesg: 2.6.37-rc7 with 84c164a34ffe67908a reverted, not crashing b43-rng is registered first, via-rng second 2.6.37-rc7-without+modprobe.dmesg: 2.6.37-rc7 with 84c164a34ffe67908a reverted, b43 blacklisted and manually modprobed after via-rng, crashing via-rng is registered first, b43-rng second Seems like the crash shows up when b43-rng is registered second, but not when via-rng is registered second. Btw.: `cat rng_available' does also not crash when via-rng is registered second. regards Mario
Added the two listed maintainers for hardware randon-number generators and dropped the wireless and b43 lists. Matt and Herbert: There is a regression in 2.6.37-rcX relative to 2.6.36. The problem shows as the following kernel BUG: [ 30.313362] BUG: unable to handle kernel paging request at 60870667 [ 30.313372] IP: [<f8f4e3df>] hwrng_register+0x5f/0x14d [rng_core] [ 30.313391] *pdpt = 0000000036c34001 *pde = 0000000000000000 [ 30.313403] Oops: 0000 [#1] SMP [ 30.313411] last sysfs file: /sys/module/bluetooth/initstate [ 30.313420] Modules linked in: l2cap crc16 parport_pc ppdev lp parport sbs sbshc power_meter pci_slot hed fan container acpi_cpufreq mperf cpufreq_conservative cpufreq_userspace cpufreq_stats cpufreq_powersave dm_crypt fuse loop eeprom via_cputemp i2c_dev nvram padlock_aes aes_i586 aes_generic padlock_sha sha256_generic sha1_generic via_rng msr cpuid snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss arc4 snd_pcm ecb snd_seq_midi snd_rawmidi snd_seq_midi_event b43 snd_seq snd_timer rng_core uvcvideo video snd_seq_device joydev mac80211 videodev ideapad_laptop output btusb battery processor bluetooth tpm_tis snd v4l1_compat ac tpm wmi power_supply cfg80211 soundcore snd_page_alloc tpm_bios rfkill button shpchp pcspkr i2c_viapro evdev i2c_core psmouse serio_raw pci_hotplug ext3 jbd mbcache raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod dm_mirror dm_region_hash dm_log dm_mod btrfs zlib_deflate crc32c libcrc32c sd_mod crc_t10dif ata_generic pata_via libata uhci_hcd ssb ehci_hcd tg3 via_sdmmc usbcore scsi_mod pcmcia thermal mmc_core pcmcia_core libphy thermal_sys nls_base [last unloaded: scsi_wait_scan] [ 30.313670] [ 30.313681] Pid: 1742, comm: NetworkManager Not tainted 2.6.37-rc7-self #3 MoutCook/20021,2959 [ 30.313692] EIP: 0060:[<f8f4e3df>] EFLAGS: 00010216 CPU: 0 [ 30.313706] EIP is at hwrng_register+0x5f/0x14d [rng_core] [ ...
I believe I can confirm the bug does not directly belong to b43:
I created a second via-rng driver (just copied via-rng.c to via-rng2.c
and changed the via_rng.name) and modprobed it. I blacklisted b43 to
keep it out of the game.
Virtually the same crash dump as with b43 shows up when I modprobe
via-rng2 after via-rng is loaded already.
Attached is a dmesg excerpt from a 2.6.37-rc7 kernel built with Larrys
hwrng_debug patch applied (which basically calls dump_stack() in
hwrng_register()).
objdump of hw_random/core.o:
00000380 <hwrng_register>:
hwrng_register():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:299
380: 56 push %esi
...
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:315
3d9: 8b 76 1c mov 0x1c(%esi),%esi
3dc: 83 ee 1c sub $0x1c,%esi
prefetch():
/tmp/1/linux-source-2.6.37-rc7/arch/x86/include/asm/processor.h:837
3df: 8b 46 1c mov 0x1c(%esi),%eax
3e2: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi
hwrng_register():
/tmp/1/linux-source-2.6.37-rc7/drivers/char/hw_random/core.c:315
3e6: 81 fe f8 ff ff ff cmp $0xfffffff8,%esi
hw_random/core.c:
313 /* Must not register two RNGs with the same name. */
314 err = -EEXIST;
315 list_for_each_entry(tmp, &rng_list, list) {
316 if (strcmp(tmp->name, rng->name) == 0)
317 goto out_unlock;
318 }
Larry: Thanks for your help!
regards
Mario
--
Goethe war nicht gerne Minister. Er beschaeftigte sich lieber geistig.
-- Lukasburger Stilblueten
My suspicion is that VIA's xstore is writing more than 4 bytes as the list pointer happens to lie immediately after rng->priv which is where xstore is writing to. Harald, do you know whether this is documented or is this a known errata item? Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
The following patch should be able to test if xstore is overwriting the list
pointer.
Larry
---
Index: wireless-testing/include/linux/hw_random.h
===================================================================
--- wireless-testing.orig/include/linux/hw_random.h
+++ wireless-testing/include/linux/hw_random.h
@@ -38,6 +38,7 @@ struct hwrng {
int (*data_read)(struct hwrng *rng, u32 *data);
int (*read)(struct hwrng *rng, void *data, size_t max, bool wait);
unsigned long priv;
+ char junk[12];
/* internal. */
struct list_head list;
Confirmed. No crashes with the junk buffer in action. I applied both patches (dump_stack() in hwrng_register() and junk[] after priv data) to vanilla 2.6.37-rc7 and tested both: via-rng and my via+rng2 as well as via-rng and b43-rng - no crashes. The (previously also crashing) `cat rng_available' does survive as well: $ cat /sys/devices/virtual/misc/hw_random/rng_available via b43_phy0 via2 $ Attached 2 dmesg excerpts. regards & g'nite Mario -- Tower: "Say fuelstate." Pilot: "Fuelstate." Tower: "Say again." Pilot: "Again." Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..."
Thanks for checking. Can you provide the output of cat /proc/cpuinfo Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
attached.
Mario
--
The only thing to be scared of, son, is tomorrow.
I don't live for tomorrow. Never saw the fun in it.
-- Denny Crane, Boston Legal
Thanks.
Can you please test the following patch?
diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index 794aacb..507a57f 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -24,6 +24,7 @@
* warranty of any kind, whether express or implied.
*/
+#include <crypto/padlock.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/hw_random.h>
@@ -34,7 +35,6 @@
#include <asm/i387.h>
-#define PFX KBUILD_MODNAME ": "
enum {
@@ -90,8 +90,10 @@ static inline u32 xstore(u32 *addr, u32 edx_in)
static int via_rng_data_present(struct hwrng *rng, int wait)
{
+ char buf[16 + PADLOCK_ALIGNMENT - STACK_ALIGN] __attribute__
+ ((aligned(STACK_ALIGN)));
+ u32 *via_rng_datum = (u32 *)PTR_ALIGN(&buf[0], PADLOCK_ALIGNMENT);
u32 bytes_out;
- u32 *via_rng_datum = (u32 *)(&rng->priv);
int i;
/* We choose the recommended 1-byte-per-instruction RNG rate,
@@ -115,6 +117,7 @@ static int via_rng_data_present(struct hwrng *rng, int wait)
break;
udelay(10);
}
+ rng->priv = *via_rng_datum;
return bytes_out ? 1 : 0;
}
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 2e992bc..2e56508 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -9,6 +9,7 @@
#include <crypto/algapi.h>
#include <crypto/aes.h>
+#include <crypto/padlock.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
@@ -21,7 +22,6 @@
#include <asm/byteorder.h>
#include <asm/processor.h>
#include <asm/i387.h>
-#include "padlock.h"
/*
* Number of data blocks actually fetched for each xcrypt insn.
diff --git a/drivers/crypto/padlock-sha.c b/drivers/crypto/padlock-sha.c
index d3a27e0..adf075b 100644
--- a/drivers/crypto/padlock-sha.c
+++ b/drivers/crypto/padlock-sha.c
@@ -13,6 +13,7 @@
*/
#include <crypto/internal/hash.h>
+#include <crypto/padlock.h>
#include <crypto/sha.h>
#include ...Hello Herbert, Hmmm, yes - the patch fixes the crashes, i.e. no more crashes with either sequence of module-loading, cat rng_available works as well, but... Having this patch active rngd complains: rngd[1435]: rngd 2-unofficial-mt.13 starting up... rngd[1435]: block failed FIPS test: 0x1f rngd[1435]: block failed FIPS test: 0x1f ... rngd[1435]: stats: entropy added to kernel pool: 0 rngd[1435]: stats: FIPS 140-2 successes: 0 rngd[1435]: stats: FIPS 140-2 failures: 10 It doesn't do this without the patch. The only available rng was via, I did blacklist the others just to be sure. regards Mario -- The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol. -- Larry Wall
Hmm, can you print out what it's actually producing (e.g., by stracing rngd)? Can you also double-check that this doesn't happen with Larry's patch? Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
# ps -ef | grep 'rng[d]' # cat /sys/devices/virtual/misc/hw_random/rng_available via # hexdump -n 512 -C /dev/hwrng 00000000 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00000010 ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 # hexdump -n 512 -C /dev/hwrng 00000000 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 # hexdump -n 1024 -C /dev/hwrng 00000000 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000060 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 # hexdump -n 1024 -C /dev/hwrng 00000000 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| 00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000070 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 Nope, it doesn't do this with Larry's patch. Mario -- The Encyclopedia Galactica, in its chapter on Love states that it is far too complicated to define. The Hitchhiker's Guide to the Galaxy has this to say on the subject of love: Avoid, if at all possible.
Weird.
Can you please try this patch against vanilla to print out the
raw output of xstore?
diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index 794aacb..4408d4e 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -24,6 +24,7 @@
* warranty of any kind, whether express or implied.
*/
+#include <crypto/padlock.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/hw_random.h>
@@ -34,7 +35,6 @@
#include <asm/i387.h>
-#define PFX KBUILD_MODNAME ": "
enum {
@@ -85,13 +85,16 @@ static inline u32 xstore(u32 *addr, u32 edx_in)
:"D"(addr), "d"(edx_in));
irq_ts_restore(ts_state);
+ printk(KERN_DEBUG "0x%x\n", *addr);
return eax_out;
}
static int via_rng_data_present(struct hwrng *rng, int wait)
{
+ char buf[16 + PADLOCK_ALIGNMENT - STACK_ALIGN] __attribute__
+ ((aligned(STACK_ALIGN)));
+ u32 *via_rng_datum = (u32 *)PTR_ALIGN(&buf[0], PADLOCK_ALIGNMENT);
u32 bytes_out;
- u32 *via_rng_datum = (u32 *)(&rng->priv);
int i;
/* We choose the recommended 1-byte-per-instruction RNG rate,
@@ -115,6 +118,7 @@ static int via_rng_data_present(struct hwrng *rng, int wait)
break;
udelay(10);
}
+ rng->priv = *via_rng_datum;
return bytes_out ? 1 : 0;
}
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 2e992bc..2e56508 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -9,6 +9,7 @@
#include <crypto/algapi.h>
#include <crypto/aes.h>
+#include <crypto/padlock.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
@@ -21,7 +22,6 @@
#include <asm/byteorder.h>
#include <asm/processor.h>
#include <asm/i387.h>
-#include "padlock.h"
/*
* Number of data blocks actually fetched for each xcrypt insn.
diff --git a/drivers/crypto/padlock-sha.c b/drivers/crypto/padlock-sha.c
index d3a27e0..adf075b 100644
--- ...# ps -ef | grep 'rng[d]'
# cat /sys/devices/virtual/misc/hw_random/rng_available
via
# hexdump -n 16 -C /dev/hwrng
00000000 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000010
#
kern.log meanwhile (lines numbered):
1 Jan 4 23:56:40 ideapad kernel: [ 151.714225] 0x0
2 Jan 4 23:56:40 ideapad kernel: [ 151.714236] 0xffffffff
3 Jan 4 23:56:40 ideapad kernel: [ 151.714239] 0x0
4 Jan 4 23:56:40 ideapad kernel: [ 151.714251] 0xffffffff
...
233 Jan 4 23:56:40 ideapad kernel: [ 151.715967] 0x0
234 Jan 4 23:56:40 ideapad kernel: [ 151.715980] 0xffffffff
235 Jan 4 23:56:40 ideapad kernel: [ 151.715982] 0x0
236 Jan 4 23:56:40 ideapad kernel: [ 151.715995] 0xffffffff
237 Jan 4 23:56:40 ideapad kernel: [ 151.720342] 0x0
238 Jan 4 23:56:40 ideapad kernel: [ 151.720347] 0x0
239 Jan 4 23:56:40 ideapad kernel: [ 151.720361] 0x0
240 Jan 4 23:56:40 ideapad kernel: [ 151.720365] 0x0
...
8163 Jan 4 23:56:40 ideapad kernel: [ 151.987049] 0x0
8164 Jan 4 23:56:40 ideapad kernel: [ 151.987061] 0x0
8165 Jan 4 23:56:40 ideapad kernel: [ 151.987063] 0x0
8166 Jan 4 23:56:40 ideapad kernel: [ 151.987075] 0x0
Mario
--
If her DNA was off by one percentage point, she'd be a dolphin.
-- Dr. Gregory House
AFAIK, he is building with the mainline 2.6.37-rc7/8 tree from Linus, thus the build should be clean, but thanks for the heads-up. In an Email from Herbert Xu that did not go to the wireless or b43 lists, it is suspected that the xstore command on a VIA CPU might generate more than 4 bytes of output and clobber the list header. We now also know that a second copy of via-rng will also fail, thus b43 is cleared. Larry --
I suspect that there is some "hw_random.h" header version mixup is going on here. The layout of struct hwrng was changed recently. Your crash seems to happen on the list head embedded in struct hwrng. Please make sure that your build environment is clean and you're not using any external stuff such as compat-wireless. All of hwrng-core, rng-via and b43 must be compiled against the same hw_random.h. -- Greetings Michael. --
| Jesse Barnes | Re: [stable] [BUG][PATCH] cpqphp: fix kernel NULL pointer dereference |
| Greg KH | [003/136] p54usb: add Zcomax XG-705A usbid |
| Magnus Damm | [PATCH 03/07] ARM: Use shared GIC entry macros on Realview |
| Oliver Neukum | Re: [Bug #13682] The webcam stopped working when upgrading from 2.6.29 to 2.6.30 |
| Martin Schwidefsky | Re: [PATCH] optimized ktime_get[_ts] for GENERIC_TIME=y |
git: | |
| Junio C Hamano | Re: Some advanced index playing |
| Jeff King | Re: confusion over the new branch and merge config |
| Robin Rosenberg | Re: cvs2svn conversion directly to git ready for experimentation |
| Linus Torvalds | git binary size... |
| Ævar Arnfjörð Bjarmason | Re: Challenge with Git-Bash |
| Linux Kernel Mailing List | md: move allocation of ->queue from mddev_find to md_probe |
| Linux Kernel Mailing List | md: raid0: Represent zone->zone_offset in sectors. |
| Linux Kernel Mailing List | [ARM] S3C24XX: Add gpio_to_irq() facility |
| Linux Kernel Mailing List | md: raid0_make_request(): Replace local variable block by sector. |
| L |