[arch-general] Battery question about a Firmware Bug in logs.
I am running Arch on a Toshiba Qosmio x505-q887. I have tried everything I can find online and in the wikis in setting things up but no matter what I have tried I can not get rid of the message in the logs, though my battery life seems semi reasonable, roughly 1.75hrs on average so far with not much tweaking being done to help extend. Error: [Firmware Bug]: battery: (dis)charge rate invalid. Is this something I should be worried about? Will it screw up my battery in charging and use right now as is? I am not really finding much online in relation to this actual error in the logs. Mostly its people saying that the logs report that the discharge rate is 0% and mine just says discharging and gives no rate or anything. I am fully updated currently, not on testing repos. I also do get 2 other messages in the logs that I am not sure if they are related. [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored From what I read and understand online, is this is of no real concern and I don't need to worry about it. Is this correct in my thinking and understanding? PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug. I have tried doing what it says in the Kernel boot args but it just gives me the same message but saying to do the reverse and use pci=crs. I have not looked much into this one, but don't want to leave out something that may be causing what I am asking. I can send any configs if needed Thanks for anyone's time and effort in helping.
I am running Arch on a Toshiba Qosmio x505-q887. I have tried everything I can find online and in the wikis in setting things up but no matter what I have tried I can not get rid of the message in the logs, though my battery life seems semi reasonable, roughly 1.75hrs on average so far with not much tweaking being done to help extend.
Error: [Firmware Bug]: battery: (dis)charge rate invalid.
Is this something I should be worried about? Will it screw up my battery in charging and use right now as is? I am not really finding much online in relation to this actual error in the logs. Mostly its people saying that the logs report that the discharge rate is 0% and mine just says discharging and gives no rate or anything.
I am fully updated currently, not on testing repos. I also do get 2 other messages in the logs that I am not sure if they are related.
[Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored From what I read and understand online, is this is of no real concern and I don't need to worry about it. Is this correct in my thinking and understanding?
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug. I have tried doing what it says in the Kernel boot args but it just gives me the same message but saying to do the reverse and use pci=crs. I have not looked much into this one, but don't want to leave out something that may be causing what I am asking.
I can send any configs if needed
Thanks for anyone's time and effort in helping. Also to add some more that I found while still tinkering with this and applying the Kernel update that just came through. acpi -V tell me the last full capacity I have gotten is 70%, could that be why I am getting
On 01/03/2012 08:20 PM, Don Juan wrote: the invalid (dis)charge rate warning? Thanks
On 01/04/2012 01:53 AM, Don Juan wrote:
On 01/03/2012 08:20 PM, Don Juan wrote:
I am running Arch on a Toshiba Qosmio x505-q887. I have tried everything I can find online and in the wikis in setting things up but no matter what I have tried I can not get rid of the message in the logs, though my battery life seems semi reasonable, roughly 1.75hrs on average so far with not much tweaking being done to help extend.
Error: [Firmware Bug]: battery: (dis)charge rate invalid.
Is this something I should be worried about? Will it screw up my battery in charging and use right now as is? I am not really finding much online in relation to this actual error in the logs. Mostly its people saying that the logs report that the discharge rate is 0% and mine just says discharging and gives no rate or anything.
I am fully updated currently, not on testing repos. I also do get 2 other messages in the logs that I am not sure if they are related.
[Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored From what I read and understand online, is this is of no real concern and I don't need to worry about it. Is this correct in my thinking and understanding?
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug. I have tried doing what it says in the Kernel boot args but it just gives me the same message but saying to do the reverse and use pci=crs. I have not looked much into this one, but don't want to leave out something that may be causing what I am asking.
I can send any configs if needed
Thanks for anyone's time and effort in helping. Also to add some more that I found while still tinkering with this and applying the Kernel update that just came through. acpi -V tell me the last full capacity I have gotten is 70%, could that be why I am getting the invalid (dis)charge rate warning?
Thanks
Well the only other info I can find online, besides trying different settings which have had no effect. I have tried numerous fixes/workarounds that were posted in regards to people having a similar bug but it was in regards to acpi telling them it was discharging at zero rate. My output is as follows Battery 0: Discharging, 87%, 01:57:08 remaining That is all the output I get. Is there a file that is related to discharge rate some place I can not find? Is this rate built into the kernel? From what I read this is built in to the kernel but I am not sure I am grasping that. Am I chasing something that is moot to overall performance and stability of the laptop? Can I give any other info I am not thinking of sharing? Is this question that bad I get the silence? ;) Anyways thanks for reading, hope I am not just pumping noise Don
On Wed, Jan 04, 2012 at 01:45:43PM -0800, Don Juan wrote:
Battery 0: Discharging, 87%, 01:57:08 remaining
That is all the output I get. Is there a file that is related to discharge rate some place I can not find? Is this rate built into the kernel? From what I read this is built in to the kernel but I am not sure I am grasping that. Am I chasing something that is moot to overall performance and stability of the laptop? Can I give any other info I am not thinking of sharing? Is this question that bad I get the silence? ;)
well, back when I was using a laptop I used /proc/acpi/battery/BAT*/* where a state file gave information in mAh about the full state and the present state in which it is discharging. crafting a progressive algorithm that dynamically averages battery usage and calculates a remaining time from it shouldn't be that hard. I'm not really sure where the mechanism that is trying to calculate these things for you is coming from, and myself would try to shut it down / see myself to make things cope with strange data. How correct is the estimate you get, anyway? On another notice, does the error make your cpu go crazy or something else imminent like this? Because otherwise I wouldn't worry too much about it. cheers! mar77i
On Thu, 5 Jan 2012 00:14:42 +0100 Martti Kühne <mysatyre@gmail.com> wrote:
On Wed, Jan 04, 2012 at 01:45:43PM -0800, Don Juan wrote:
Battery 0: Discharging, 87%, 01:57:08 remaining
That is all the output I get. Is there a file that is related to discharge rate some place I can not find? Is this rate built into the kernel? From what I read this is built in to the kernel but I am not sure I am grasping that. Am I chasing something that is moot to overall performance and stability of the laptop? Can I give any other info I am not thinking of sharing? Is this question that bad I get the silence? ;)
well, back when I was using a laptop I used /proc/acpi/battery/BAT*/* where a state file gave information in mAh about the full state and the present state in which it is discharging. crafting a progressive algorithm that dynamically averages battery usage and calculates a remaining time from it shouldn't be that hard.
I'm not really sure where the mechanism that is trying to calculate these things for you is coming from, and myself would try to shut it down / see myself to make things cope with strange data. How correct is the estimate you get, anyway?
On another notice, does the error make your cpu go crazy or something else imminent like this? Because otherwise I wouldn't worry too much about it.
cheers! mar77i
/proc ACPI entries have been deprecated. All files are now located in /sys/class/power_supply. The correctness of numbers in there depends on your BIOS and can be completely nonexistent... -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On 01/04/2012 03:30 PM, Leonid Isaev wrote:
On Thu, 5 Jan 2012 00:14:42 +0100 Martti Kühne<mysatyre@gmail.com> wrote:
On Wed, Jan 04, 2012 at 01:45:43PM -0800, Don Juan wrote:
Battery 0: Discharging, 87%, 01:57:08 remaining
That is all the output I get. Is there a file that is related to discharge rate some place I can not find? Is this rate built into the kernel? From what I read this is built in to the kernel but I am not sure I am grasping that. Am I chasing something that is moot to overall performance and stability of the laptop? Can I give any other info I am not thinking of sharing? Is this question that bad I get the silence? ;)
well, back when I was using a laptop I used /proc/acpi/battery/BAT*/* where a state file gave information in mAh about the full state and the present state in which it is discharging. crafting a progressive algorithm that dynamically averages battery usage and calculates a remaining time from it shouldn't be that hard.
I'm not really sure where the mechanism that is trying to calculate these things for you is coming from, and myself would try to shut it down / see myself to make things cope with strange data. How correct is the estimate you get, anyway?
On another notice, does the error make your cpu go crazy or something else imminent like this? Because otherwise I wouldn't worry too much about it.
cheers! mar77i /proc ACPI entries have been deprecated. All files are now located in /sys/class/power_supply. The correctness of numbers in there depends on your BIOS and can be completely nonexistent...
I do know this laptop has a buggy DSDT but I have never had luck in trying to get the errors fixed. I can never find things online in relation to the errors it produces, best I have ever done is clear 2 of the 200 something errors when trying to recompile it :P I guess that must be it though the BIOS not playing nice, just weird it only shows on the Arch kernel. Maybe I need to finally figure out how to do my DSDT.
On 01/04/2012 03:14 PM, Martti Kühne wrote:
On Wed, Jan 04, 2012 at 01:45:43PM -0800, Don Juan wrote:
Battery 0: Discharging, 87%, 01:57:08 remaining
That is all the output I get. Is there a file that is related to discharge rate some place I can not find? Is this rate built into the kernel? From what I read this is built in to the kernel but I am not sure I am grasping that. Am I chasing something that is moot to overall performance and stability of the laptop? Can I give any other info I am not thinking of sharing? Is this question that bad I get the silence? ;)
well, back when I was using a laptop I used /proc/acpi/battery/BAT*/* where a state file gave information in mAh about the full state and the present state in which it is discharging. crafting a progressive algorithm that dynamically averages battery usage and calculates a remaining time from it shouldn't be that hard.
I'm not really sure where the mechanism that is trying to calculate these things for you is coming from, and myself would try to shut it down / see myself to make things cope with strange data. How correct is the estimate you get, anyway?
On another notice, does the error make your cpu go crazy or something else imminent like this? Because otherwise I wouldn't worry too much about it.
cheers! mar77i Thanks for your time, here is the info from where they have it in /sys/ now.
/sys/class/power_supply/BAT1 charge_full 5652000 charge_full_design 8000000 current_now 3929000 cycle_count 0 voltage_min_design 11282000 voltage_now 11436000 I do not get this message in the logs on other Linux distros running a 3.1 kernel. Also my charge_full shows 6843005 for charge_full on my sid partition. I do not have anything that I notice going on idle system give an average 2% cpu usage no crazy spikes no overheating things like that. I just keep getting the message in the log and I never like messages I do not understand being there especially when the battery is behaving differently than on sid. Side not how bad is it to just let the computer run out of juice and watch the acpi power info until it shuts off? I did notice that at 0% battery it was still going but I did not want to push my luck.
I don't know that it is directly relevant, but I have a Toshiba Qosimo X505-Q830, and I get (when plugged in and fully charged): [✍] /sys/class/power_supply/BAT1 $ cat uevent POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Full POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12500000 POWER_SUPPLY_CURRENT_NOW=0 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7245000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134 And in everything.log I get: kernel: [ 6.705931] [Firmware Bug]: battery: (dis)charge rate invalid. kernel: [ 6.705993] ACPI: Battery Slot [BAT1] (battery present) I don't currently pass any ACPI parameters to my boot. Just a point of comparison.
I don't know that it is directly relevant, but I have a Toshiba Qosimo X505-Q830, and I get (when plugged in and fully charged):
[✍] /sys/class/power_supply/BAT1 $ cat uevent
POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Full POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12500000 POWER_SUPPLY_CURRENT_NOW=0 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7245000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134
And in everything.log I get:
kernel: [ 6.705931] [Firmware Bug]: battery: (dis)charge rate invalid. kernel: [ 6.705993] ACPI: Battery Slot [BAT1] (battery present)
I don't currently pass any ACPI parameters to my boot.
Just a point of comparison. do you know if changing the numbers in say VOLTAGE_NOW to match min on mine would do anything? I know I can just try but is there something bad
On 01/04/2012 03:43 PM, Jason Melton wrote: that could happen? At least you have the same kernel message as me and basically the same laptop as me. I wish I could get mine to charge that close to full again while using Arch. Thanks for posting that though makes me feel better
On Thu, Jan 5, 2012 at 8:53 AM, Don Juan <donjuansjiz@gmail.com> wrote:
do you know if changing the numbers in say VOLTAGE_NOW to match min on mine would do anything? I know I can just try but is there something bad that could happen? At least you have the same kernel message as me and basically the same laptop as me. I wish I could get mine to charge that close to full again while using Arch.
Thanks for posting that though makes me feel better
I honestly don't know enough to say. I've never bothered with the battery life (I'm almost always plugged in), so this is an area I've never researched. I did experiment a little with unplugging and seeing what happens, all of these were run immediately after one another, immediately after unplugging the power: [✍] /sys/class/power_supply/BAT1 $ cat uevent POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12326000 POWER_SUPPLY_CURRENT_NOW=2340000 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7135000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134 [✍] /sys/class/power_supply/BAT1 $ cat uevent POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12319000 POWER_SUPPLY_CURRENT_NOW=2317000 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7131000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134 [✍] /sys/class/power_supply/BAT1 $ cat uevent POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12321000 POWER_SUPPLY_CURRENT_NOW=2442000 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7127000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134 [✍] /sys/class/power_supply/BAT1 $ cat uevent POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12315000 POWER_SUPPLY_CURRENT_NOW=2374000 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7119000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134
On Thu, Jan 5, 2012 at 8:53 AM, Don Juan<donjuansjiz@gmail.com> wrote:
do you know if changing the numbers in say VOLTAGE_NOW to match min on mine would do anything? I know I can just try but is there something bad that could happen? At least you have the same kernel message as me and basically the same laptop as me. I wish I could get mine to charge that close to full again while using Arch.
Thanks for posting that though makes me feel better
I honestly don't know enough to say. I've never bothered with the battery life (I'm almost always plugged in), so this is an area I've never researched.
I did experiment a little with unplugging and seeing what happens, all of these were run immediately after one another, immediately after unplugging the power:
[✍] /sys/class/power_supply/BAT1 $ cat uevent
POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12326000 POWER_SUPPLY_CURRENT_NOW=2340000 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7135000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134 [✍] /sys/class/power_supply/BAT1 $ cat uevent
POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12319000 POWER_SUPPLY_CURRENT_NOW=2317000 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7131000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134 [✍] /sys/class/power_supply/BAT1 $ cat uevent
POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12321000 POWER_SUPPLY_CURRENT_NOW=2442000 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7127000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134 [✍] /sys/class/power_supply/BAT1 $ cat uevent
POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_STATUS=Discharging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CYCLE_COUNT=0 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=12500000 POWER_SUPPLY_VOLTAGE_NOW=12315000 POWER_SUPPLY_CURRENT_NOW=2374000 POWER_SUPPLY_CHARGE_FULL_DESIGN=8000000 POWER_SUPPLY_CHARGE_FULL=7245000 POWER_SUPPLY_CHARGE_NOW=7119000 POWER_SUPPLY_MODEL_NAME=NS2P3SZNJ5WR POWER_SUPPLY_MANUFACTURER=SANYO POWER_SUPPLY_SERIAL_NUMBER=134 Thank you that looks similar to how mine is responding, I just don't
On 01/04/2012 04:00 PM, Jason Melton wrote: think its allowing it to fully charge on mine. I like you am mostly plugged in as well, but would be nice to know I can use the battery and rely on what results I am getting, though mostly my VOLTAGE_NOW is lower than MIN_DESIGN. Guess that just is me doing lots of testing, to figure the rest out. Side note since you have a Qosmio as well have you ever tried messing with DSDT on yours? Appreciate your time.
On Thu, Jan 5, 2012 at 9:07 AM, Don Juan <donjuansjiz@gmail.com> wrote:
On 01/04/2012 04:00 PM, Jason Melton wrote:
On Thu, Jan 5, 2012 at 8:53 AM, Don Juan<donjuansjiz@gmail.com> wrote:
Side note since you have a Qosmio as well have you ever tried messing with DSDT on yours?
Appreciate your time.
Nah, never messed with DSDT - I barely understand what it is. I have tried to document this laptop on the wiki[1], so I would encourage you to do the same. And, since we are talking about Qosmio's in general, I'll note that I get total system freezes that I think happen if wireless drivers are loaded when there is a wired connection. Alt+SysRq will not get out of this freeze, you have to power off and back on. I also rmmod rtl8192se and rtlwifi now when I am using a wired connection, and that seems to have resolved things. I'm not confident enough in that diagnosis to put it on the wiki, though. Peace [1] https://wiki.archlinux.org/index.php/Toshiba_Qosimo_X505-Q830
On 01/04/2012 04:19 PM, Jason Melton wrote:
On Thu, Jan 5, 2012 at 9:07 AM, Don Juan<donjuansjiz@gmail.com> wrote:
On 01/04/2012 04:00 PM, Jason Melton wrote:
On Thu, Jan 5, 2012 at 8:53 AM, Don Juan<donjuansjiz@gmail.com> wrote:
Side note since you have a Qosmio as well have you ever tried messing with DSDT on yours?
Appreciate your time.
Nah, never messed with DSDT - I barely understand what it is. I have tried to document this laptop on the wiki[1], so I would encourage you to do the same. I plan to when I am sure I have things set up properly and working without issue. Been keeping lots of notes of what I install how I configure it and so on.
And, since we are talking about Qosmio's in general, I'll note that I get total system freezes that I think happen if wireless drivers are loaded when there is a wired connection. Alt+SysRq will not get out of this freeze, you have to power off and back on. I also rmmod rtl8192se and rtlwifi now when I am using a wired connection, and that seems to have resolved things. I'm not confident enough in that diagnosis to put it on the wiki, though.
Peace
[1] https://wiki.archlinux.org/index.php/Toshiba_Qosimo_X505-Q830
For me the system freezes happened during shutdown reboot dropping to init 3 and so on. What I found it to be was the Nvidia closed driver and the nouveau driver giving me the freezing issues. Though just tried the beta driver last night and I got lockups quickly after booting into X. Though for me Alt+SysRq+R+E+I+S+U+B always gives me cleaner shutdown in those types of lock ups. If I use the nv driver, the one you rarely hear anyone ever say to use for nvidia stuff anymore, works for me. No desktop candy type effects but I don't care about that. I just blacklisted nouveau and vesa and made sure the xf86-video-nv was installed. And everything has been great while using this driver while xorg and nvidia figure things out. I could never get nouveau to work properly for me. But with wifi on and being used the whole time and on nv driver the system seems to run really smooth, with occasional lag opening a window full screen. But maybe your issue is different, though I remember when I used Fedora for awhile I had issues with the rtl driver provided and had to use an older version I dl'd from the website and it eliminated the lock up.
participants (4)
-
Don Juan
-
Jason Melton
-
Leonid Isaev
-
Martti Kühne