one of the top features a distribution must always ship in a working state is wireless. Yet we have no way to test it in an automated way. To be able to do that via openQA we need qemu to emulate a wireless adapter. Whether it's emulating existing hardware or implements some virtio device that only works on Linux doesn't matter.
No Hackers yet
This project is part of:
Hack Week 10
Comments
-
almost 12 years ago by vbotka | Reply
FYI. " wifi-test is fully automated test script for linux wireless drivers" available at http://wireless.kernel.org/en/developers/Testing/wifi-test . Some results of the tests can be found at http://users.suse.cz/~vbotka/wt/. Cisco AP, Dlink and ASUS AP with CLI (Command Line Interface). For example, Dlink DWL-8200 AP and Cisco1200 series AP is needed. HTH.
-vlado
-
over 11 years ago by bmwiedemann | Reply
So emulating the wireless adapter alone is not sufficient - it also needs an access point (either physical or virtual) to receive the raw wireless 802.11* data and respond to association requests etc.
-
over 11 years ago by a_faerber | Reply
Some years ago an Austrian university tried to contribute Wifi emulation but threw a big blob at us, mixing random Windows hacks with the actual adapter/network emulation code, and didn't care to clean that up. Probably still available in qemu-devel archives as a starting point.
-
Similar Projects
early stage kdump support by mbrugger
Project Description
When we experience a early boot crash, we are not able to analyze the kernel dump, as user-space wasn't able to load the crash system. The idea is to make the crash system compiled into the host kernel (think of initramfs) so that we can create a kernel dump really early in the boot process.
Goal for the Hackweeks
- Investigate if this is possible and the implications it would have (done in HW21)
- Hack up a PoC (done in HW22 and HW23)
- Prepare RFC series (giving it's only one week, we are entering wishful thinking territory here).
update HW23
- I was able to include the crash kernel into the kernel Image.
- I'll need to find a way to load that from
init/main.c:start_kernel()probably afterkcsan_init() - I workaround for a smoke test was to hack
kexec_file_load()systemcall which has two problems:- My initramfs in the porduction kernel does not have a new enough kexec version, that's not a blocker but where the week ended
- As the crash kernel is part of init.data it will be already stale once I can call
kexec_file_load()from user-space.
The solution is probably to rewrite the POC so that the invocation can be done from init.text (that's my theory) but I'm not sure if I can reuse the kexec infrastructure in the kernel from there, which I rely on heavily.
update HW24
- Day1
- rebased on v6.12 with no problems others then me breaking the config
- setting up a new compilation and qemu/virtme env
- getting desperate as nothing works that used to work
- Day 2
- getting to call the invocation of loading the early kernel from
__initafterkcsan_init()
- getting to call the invocation of loading the early kernel from
Day 3
- fix problem of memdup not being able to alloc so much memory... use 64K page sizes for now
- code refactoring
- I'm now able to load the crash kernel
- When using virtme I can boot into the crash kernel, also it doesn't boot completely (major milestone!), crash in
elfcorehdr_read_notes()
Day 4
- crash systems crashes (no pun intended) in
copy_old_mempage()link; will need to understand elfcorehdr... - call path
vmcore_init() -> parse_crash_elf_headers() -> elfcorehdr_read() -> read_from_oldmem() -> copy_oldmem_page() -> copy_to_iter()
- crash systems crashes (no pun intended) in
Day 5
- hacking
arch/arm64/kernel/crash_dump.c:copy_old_mempage()to see if crash system really starts. It does. - fun fact: retested with more reserved memory and with UEFI FW, host kernel crashes in init but directly starts the crash kernel, so it works (somehow) \o/
- hacking
TODOs
- fix elfcorehdr so that we actually can make use of all this...
- test where in the boot
__init()chain we can/should callkexec_early_dump()