Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot
Small brainfart earlier; the setting that caused the kernel crash was when using 16MB for the IGP and the working setting is 32MB, not 32 and 64MB respectively as I said originally. Here's the memory map on 16MB of shared memory that crashes the kernel: Region 0: type 1 at 0x1000 for 635KB Region 1: type 2 at 0x9fc00 for 1KB Region 2: type 2 at 0xe6000 for 104KB Region 3: type 1 at 0x10 for 2079552KB Region 4: type 3 at 0x7efd for 56KB Region 5: type 4 at 0x7efde000 for 136KB Region 6: type 2 at 0xfec0 for 4KB Region 7: type 2 at 0xfee0 for 1024KB Region 8: type 2 at 0xfff8 for 512KB Low ram: 639KB High ram: 2079552KB Total free memory: 2080187KB And here's for 32MB: Region 0: type 1 at 0x1000 for 635KB Region 1: type 2 at 0x9fc00 for 1KB Region 2: type 2 at 0xe6000 for 104KB Region 3: type 1 at 0x10 for 2063168KB Region 4: type 3 at 0x7dfd for 56KB Region 5: type 4 at 0x7dfde000 for 136KB Region 6: type 2 at 0xfec0 for 4KB Region 7: type 2 at 0xfee0 for 1024KB Region 8: type 2 at 0xfff8 for 512KB Low ram: 639KB High ram: 2063168KB Total free memory: 2063803KB On Tue, Jul 12, 2016 at 1:37 AM, Mike Larkin wrote: > On Mon, Jul 11, 2016 at 04:36:44PM -0700, Mike Larkin wrote: > > On Tue, Jul 12, 2016 at 01:28:21AM +0200, stolendata.net wrote: > > > I just managed to get it to boot. The machine is running sort of > headless > > > with only the on-board IGP available, using 32MB of shared memory. I > > > stepped this setting up in the BIOS to give the IGP 64MB of RAM and > i386 > > > now boots, both the full install as well as the ramdisk kernel. > > > > > > If it's of any value, dmesg.boot: http://pastebin.com/raw/ww0ezzed > > > And sensors: http://pastebin.com/raw/ZZSNk6mG > > > > > > Pardon the ANSI codes or whatever the garbage in the dmesg output is. > I've > > > no idea why that shows up in 5.9. > > > > Can you show the output of "machine memory" at the boot> prompt? > > ... for both IGP settings, please. > > -ml > > > > > I'm wondering if this machine has an odd memory layout. > > > > (The trash in dmesg was just scribbled memory from a previous boot, linux > > from the looks of it) > > > > -ml > > > >
Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot
I just managed to get it to boot. The machine is running sort of headless with only the on-board IGP available, using 32MB of shared memory. I stepped this setting up in the BIOS to give the IGP 64MB of RAM and i386 now boots, both the full install as well as the ramdisk kernel. If it's of any value, dmesg.boot: http://pastebin.com/raw/ww0ezzed And sensors: http://pastebin.com/raw/ZZSNk6mG Pardon the ANSI codes or whatever the garbage in the dmesg output is. I've no idea why that shows up in 5.9. (I'm mailing these to dmesg@... as well) On Tue, Jul 12, 2016 at 12:32 AM, Mike Larkin wrote: > On Tue, Jul 12, 2016 at 12:30:23AM +0200, stolendata.net wrote: > > Alright, ddb prompt pops up on i386. Last output from kernel: > > > > real mem ... > > avail mem ... > > kernel: page fault trap, code=0 > > Stopped at memcpy+0x13:repe movsl(%esi),%es:(%edi) > > in ddb: > trace > > ps > > take some pictures and send some links. > > > > > > If there's any chance you think you can guide me through pulling some > > valuable info from here and on, I'm game. > > > > >
Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot
https://i.imgur.com/EAqLSPJ.jpg https://i.imgur.com/FBh4syj.jpg On Tue, Jul 12, 2016 at 12:32 AM, Mike Larkin wrote: > On Tue, Jul 12, 2016 at 12:30:23AM +0200, stolendata.net wrote: > > Alright, ddb prompt pops up on i386. Last output from kernel: > > > > real mem ... > > avail mem ... > > kernel: page fault trap, code=0 > > Stopped at memcpy+0x13:repe movsl(%esi),%es:(%edi) > > in ddb: > trace > > ps > > take some pictures and send some links. > > >
Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot
Alright, ddb prompt pops up on i386. Last output from kernel: real mem ... avail mem ... kernel: page fault trap, code=0 Stopped at memcpy+0x13:repe movsl(%esi),%es:(%edi) If there's any chance you think you can guide me through pulling some valuable info from here and on, I'm game. On Tue, Jul 12, 2016 at 12:12 AM, Mike Larkin wrote: > On Tue, Jul 12, 2016 at 12:09:03AM +0200, stolendata.net wrote: > > GENERIC.MP AMD64/5.9-release booted from full install on USB disk > behaves > > the exact same way as the ramdisk kernel, stops booting at the same > point. > > Do you want me to try a full i386 install as well? > > > > Please, since at least i386 panics. You might get into ddb and can do a > backtrace. > > -ml > > > On Mon, Jul 11, 2016 at 11:41 PM, Mike Larkin > wrote: > > > > > On Mon, Jul 11, 2016 at 11:36:22PM +0200, stolendata.net wrote: > > > > > > > > > > > If it's of any value to help narrow the problem down, this > particular CPU > > > > model is probably not the culprit. I've been running OpenBSD on one > on > > > > another board since 4.9. > > > > > > > > > > Even though you don't have a full install, can you try booting a > regular > > > non-ramdisk kernel instead? The ramdisk kernel has a bunch of stuff > > > stripped > > > out (including ddb), and trying a regular kernel may give us more data > > > points. > > > Of course, it won't boot since you don't have a full install, but if it > > > gets > > > that far, that's information as well. > > > > > > This can be done in a variety of ways, including using another machine > and > > > installing to a USB stick. > > > > > > -ml > > > >
Re: Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot
GENERIC.MP AMD64/5.9-release booted from full install on USB disk behaves the exact same way as the ramdisk kernel, stops booting at the same point. Do you want me to try a full i386 install as well? On Mon, Jul 11, 2016 at 11:41 PM, Mike Larkin wrote: > On Mon, Jul 11, 2016 at 11:36:22PM +0200, stolendata.net wrote: > > > > > If it's of any value to help narrow the problem down, this particular CPU > > model is probably not the culprit. I've been running OpenBSD on one on > > another board since 4.9. > > > > Even though you don't have a full install, can you try booting a regular > non-ramdisk kernel instead? The ramdisk kernel has a bunch of stuff > stripped > out (including ddb), and trying a regular kernel may give us more data > points. > Of course, it won't boot since you don't have a full install, but if it > gets > that far, that's information as well. > > This can be done in a variety of ways, including using another machine and > installing to a USB stick. > > -ml > > > > > On Mon, Jul 11, 2016 at 11:05 PM, Mike Larkin > wrote: > > > > > On Mon, Jul 11, 2016 at 10:37:23PM +0200, stolendata.net wrote: > > > > > > > With 5.9/AMD64-release the kernel manages to get just a few steps > > > further, > > > > crashing after a few lines of the "BIOS0" enumeration. If a picture > of > > > this > > > > would help let me know and I'll fire the machine up again. I've tried > > > > > > This would be nice, if you could. It would indicate if i386 and amd64 > are > > > failing at the same place. > > > > > > -ml > > > > > > >
Fwd: plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot
http://i.imgur.com/2G0LRZj.jpg At this point the boot stops progressing and the machine idles indefinitely with cursor blinking. Keyboard input has no effect. If it's of any value to help narrow the problem down, this particular CPU model is probably not the culprit. I've been running OpenBSD on one on another board since 4.9. On Mon, Jul 11, 2016 at 11:05 PM, Mike Larkin wrote: > On Mon, Jul 11, 2016 at 10:37:23PM +0200, stolendata.net wrote: > > > With 5.9/AMD64-release the kernel manages to get just a few steps > further, > > crashing after a few lines of the "BIOS0" enumeration. If a picture of > this > > would help let me know and I'll fire the machine up again. I've tried > > This would be nice, if you could. It would indicate if i386 and amd64 are > failing at the same place. > > -ml > >
plain ol' x86 PC can't boot 5.9-release, kernel crashes right at boot
Apologies if this is not the preferred mailing list for this. As I can't get the machine to boot, I'll just provide a picture of the crash: http://i.imgur.com/KDcPwTg.jpg With 5.9/AMD64-release the kernel manages to get just a few steps further, crashing after a few lines of the "BIOS0" enumeration. If a picture of this would help let me know and I'll fire the machine up again. I've tried fiddling around with various CPU- and on-board features in the BIOS to no avail, no change in behavior. The board is an MSI K9N6SGM-V (nForce 430/MCP61). It has the latest available BIOS flashed, and memory + SATA drive is working just fine - the machine has been running Arch Linux for the past two years without any problems.
Re: powersave clients on ral(4) hostap fail even if wifi-chip is supported
I reported this about a month and a half ago. Same problem with my RT2860 device, and for the past years I've handled it the same way you did: by having the clients rapidly pinging the AP to prevent them from entering power saving mode. I never got any response indicating that someone is looking into it, or even confirming the bug, so I chalked it down to ral(4) never having had the ability to manage power saving clients and that a mistake simply made its way into the ral(4) man page. I recently opted for getting an athn(4) device instead, which supports power saving clients perfectly fine. The card (or perhaps athn(4)) induces notably higher latency between it and its clients, but at least the clients don't lose connection all the time. On Sat, Jul 13, 2013 at 12:47 PM, David Fouces wrote: > We have some machines that are used as wireless routers/access point > running ral(4) in hostap mode. Equipped with Encore ENLWI-N cards (RT2860 + > 2820), which the manual page to ral says that RT2860 should be able to > handle powersave clients. > > The problem is almost all clients that connect to them lose connection > repeatedly, in specific it is almost always the laptops and smartphones. We > can solve it for the laptop temporary by preventing powersave, starting a > bat/sh script that is pinging the router every 0.4 seconds. But this is not > a sustainable solution. > > The same problem showed with a different model RT2860 card from Edimax > brand, with same connection problem behavior compared to Encore's RT2860 > card.
Re: ral(4) still can't power save in host ap mode on chipsets that appear supported
My bad, thanks for the clarification. However, RAL(4) is still not capable of properly managing power saving clients. I've been running this Edimax EW-7728IN card (RT2860; see dmesg in initial report) as HostAP since 4.9, so I'm well-acquainted with the problems seen by the clients as I've had to develop various client-side tricks to mitigate during the past 2 years. I've gone through all versions from 4.9 to 5.3, and RAL(4) just doesn't cope with power saving clients yet. I've previously even resorted to trying a second card of the samel model, just in case something really odd was going on, but as expected the other card acted no different. I'll gladly test out any eventual patches, if anyone would happen to find out where the problem is and want the code tested. On Tue, Jun 4, 2013 at 3:56 PM, David Coppa wrote: > > 802.11 power saving mode for clients does not work for ral(4). > HostAP support for clients using power saving mode does work instead > and without the need to push any knob.
Re: ral(4) still can't power save in host ap mode on chipsets that appear supported
Perhaps I was being vague, perhaps you didn't read the report through...: Enabling the "powersave" option for a RAL(4) device does not work, while the man page suggests that it SHOULD work, in just the same way with just the same results as it does for f.e. ATHN(4) as of the release of 5.3: "Power-saving clients supported in hostap mode with acx(4) and athn(4)." The long-standing and well-known problem of wireless clients experiencing connection drops and packet loss when connected to a RAL(4) device running in HostAP mode is STILL present, even on ralink families that the man page claim should finally be supported. On Tue, Jun 4, 2013 at 3:25 PM, Stuart Henderson wrote: > On 2013/06/04 15:20, stolendata.net wrote: > > The man page of ral(4) makes it understood that power saving in host ap > > mode is now finally working, but only for certain ralink chipset families > > (RT2800 being among those that should work). A list of exceptions is > > provided in the man page: "On the RT2500, RT2501 and RT2600 chipsets, > host > > AP mode doesn't support power saving." > > > > However, trying to enable power saving on 5.3-RELEASE/i386, whether by > > issuing the option to ifconfig or providing it in hostname.if, only > yields > > the error "SIOCS80211POWER: Invalid argument". > > > > Excerpt from my dmesg: > > > > ral0 at pci1 dev 7 function 0 "Ralink RT2860" rev 0x00: apic 2 int 5, > > address 00:1f:1f:81:6b:92 > > ral0: MAC/BBP RT2860 (rev 0x0102), RF RT2820 (MIMO 2T3R) > > > > The 'powersave' flag is only for client devices. > > 'Power saving support for host ap' means that the AP is able to > buffer packets for *clients* in power-save mode. There is nothing to > configure for this.
