info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Debian Jessie on QNAP TS-112P - Reboot instead of shutdown
212 views
Skip to first unread message
Helge Wiemann
Apr 8, 2016, 8:20:03 PM4/8/16
to
Hello,
I think the issue is known bug in the current Kirkwood kernel, hence I
don't want to dwell on the subject. I upgraded to Debian Jessie recently
on my QNP TS-112P and ever since I have been unable to shutdown my
system, because it restarts rather than turns itself off when I issue
"shutdown -h now" or "poweroff".
Since I don't want to wait for a kernel update I was wondering if I can
install this kernel image:
linux-image-4.3.0-0.bpo.1-kirkwood (4.3.5-1~bpo8+1)
I found it here:
https://packages.debian.org/jessie-backports/linux-image-4.3.0-0.bpo.1-kirkwood
Would this fix my problem and will I be able to install it without
bricking my system? "dkpg -i" tells me this will break flash-kernel,
therefore I did not go ahead.
I am at a loss here... Thank you.
HW
I think the issue is known bug in the current Kirkwood kernel, hence I
don't want to dwell on the subject. I upgraded to Debian Jessie recently
on my QNP TS-112P and ever since I have been unable to shutdown my
system, because it restarts rather than turns itself off when I issue
"shutdown -h now" or "poweroff".
Since I don't want to wait for a kernel update I was wondering if I can
install this kernel image:
linux-image-4.3.0-0.bpo.1-kirkwood (4.3.5-1~bpo8+1)
I found it here:
https://packages.debian.org/jessie-backports/linux-image-4.3.0-0.bpo.1-kirkwood
Would this fix my problem and will I be able to install it without
bricking my system? "dkpg -i" tells me this will break flash-kernel,
therefore I did not go ahead.
I am at a loss here... Thank you.
HW
Roger Shimizu
Apr 13, 2016, 6:20:03 PM4/13/16
to
On Sat, Apr 9, 2016 at 4:54 AM, Helge Wiemann <helge....@gmx.com> wrote:
> Hello,
>
> I think the issue is known bug in the current Kirkwood kernel, hence I don't
> want to dwell on the subject. I upgraded to Debian Jessie recently on my QNP
> TS-112P and ever since I have been unable to shutdown my system, because it
> restarts rather than turns itself off when I issue "shutdown -h now" or
> "poweroff".
there's recent fix for shutdown/reboot on QNAP:
> Hello,
>
> I think the issue is known bug in the current Kirkwood kernel, hence I don't
> want to dwell on the subject. I upgraded to Debian Jessie recently on my QNP
> TS-112P and ever since I have been unable to shutdown my system, because it
> restarts rather than turns itself off when I issue "shutdown -h now" or
> "poweroff".
- https://bugs.debian.org/807696
- https://bugs.debian.org/810680
So probably a kernel upgrade can help you resolve the issue.
> Since I don't want to wait for a kernel update I was wondering if I can
> install this kernel image:
>
> linux-image-4.3.0-0.bpo.1-kirkwood (4.3.5-1~bpo8+1)
>
> I found it here:
>
> https://packages.debian.org/jessie-backports/linux-image-4.3.0-0.bpo.1-kirkwood
>
> Would this fix my problem and will I be able to install it without bricking
> my system? "dkpg -i" tells me this will break flash-kernel, therefore I did
> not go ahead.
- https://packages.debian.org/jessie-backports/flash-kernel
If you add backports repo to your sources.list:
deb http://<mirror>/debian jessie-backports main
it should be as simple as "apt install"
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1
Martin Michlmayr
Apr 13, 2016, 7:30:02 PM4/13/16
to
* Roger Shimizu <rogers...@gmail.com> [2016-04-14 03:12]:
My suspicion is that this problem is related to the introduction of
wakealarm support in qcontrol. I believe someone else reported a
similar problem in the past but I don't have a reference right now.
--
Martin Michlmayr
http://www.cyrius.com/
> > I think the issue is known bug in the current Kirkwood kernel, hence I don't
> > want to dwell on the subject. I upgraded to Debian Jessie recently on my QNP
> > TS-112P and ever since I have been unable to shutdown my system, because it
> > restarts rather than turns itself off when I issue "shutdown -h now" or
> > "poweroff".
>
> there's recent fix for shutdown/reboot on QNAP:
> - https://bugs.debian.org/807696
> - https://bugs.debian.org/810680
Neither of those bugs apply to the kernel in jessie, though.
> > want to dwell on the subject. I upgraded to Debian Jessie recently on my QNP
> > TS-112P and ever since I have been unable to shutdown my system, because it
> > restarts rather than turns itself off when I issue "shutdown -h now" or
> > "poweroff".
>
> there's recent fix for shutdown/reboot on QNAP:
> - https://bugs.debian.org/807696
> - https://bugs.debian.org/810680
My suspicion is that this problem is related to the introduction of
wakealarm support in qcontrol. I believe someone else reported a
similar problem in the past but I don't have a reference right now.
--
Martin Michlmayr
http://www.cyrius.com/
Helge Wiemann
Apr 13, 2016, 8:50:03 PM4/13/16
to
Martin & Roger,
Appreciate your responses and continuing support.
I installed the new kernel from the backports, but to no avail. A
shutdown still results in a reboot. I even removed the qcontrol package
to see what would happen, but it makes no difference.
I also suspect it has to do with qcontrol because I believe the problems
started not right after the upgrade to Jessie, but when I upgraded to
the latest version of qcontrol (which I did a few days after my upgrade
to Jessie).
Whatever the issue is, I guess I have to wait until a fixed version of
qcontrol is available. It is what it is. Shit happens. :-)
Helge
Appreciate your responses and continuing support.
I installed the new kernel from the backports, but to no avail. A
shutdown still results in a reboot. I even removed the qcontrol package
to see what would happen, but it makes no difference.
I also suspect it has to do with qcontrol because I believe the problems
started not right after the upgrade to Jessie, but when I upgraded to
the latest version of qcontrol (which I did a few days after my upgrade
to Jessie).
Whatever the issue is, I guess I have to wait until a fixed version of
qcontrol is available. It is what it is. Shit happens. :-)
Helge
Helge Wiemann
Apr 17, 2016, 2:40:03 PM4/17/16
to
Martin & Roger
A quick update: I had to reinstall the entire system because of a
network glitch during a kernel upgrade which resulted in a bricked
device. After resetting my NAS and installing Jessie from scratch the
reboot issue disappeared and the system has been running well since.
So apparently something got messed up when I upgraded from Wheezy to
Jessie and I am inclined to attribute my problems to the upgrade process
rather than the kernel or qcontrol.
I am staying away from qcontrol and did not make any changes to it.
However, all is good now.
Thank you for your patience and support. I really appreciate your help.
Helge
A quick update: I had to reinstall the entire system because of a
network glitch during a kernel upgrade which resulted in a bricked
device. After resetting my NAS and installing Jessie from scratch the
reboot issue disappeared and the system has been running well since.
So apparently something got messed up when I upgraded from Wheezy to
Jessie and I am inclined to attribute my problems to the upgrade process
rather than the kernel or qcontrol.
I am staying away from qcontrol and did not make any changes to it.
However, all is good now.
Thank you for your patience and support. I really appreciate your help.
Helge
jfc
Apr 20, 2016, 6:40:02 PM4/20/16
to
Hello,
I get the same issue since I upgraded my Qnap TS-119P II | Turbo to
Jessie. I'm not able to shutdown my Qnap anymore, it always reboot
whatever command I use (halt, shutdown, systemctl).
Is there a way to fix that, without going to a fresh install?
Thanks,
jfc
I get the same issue since I upgraded my Qnap TS-119P II | Turbo to
Jessie. I'm not able to shutdown my Qnap anymore, it always reboot
whatever command I use (halt, shutdown, systemctl).
Is there a way to fix that, without going to a fresh install?
Thanks,
jfc
Martin Michlmayr
Apr 22, 2016, 4:50:04 PM4/22/16
to
* jfc <deb...@inax.fr> [2016-04-20 20:21]:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794266
> I get the same issue since I upgraded my Qnap TS-119P II | Turbo to
> Jessie. I'm not able to shutdown my Qnap anymore, it always reboot
> whatever command I use (halt, shutdown, systemctl).
I just found the bug report again (not that it contains more info):
> Jessie. I'm not able to shutdown my Qnap anymore, it always reboot
> whatever command I use (halt, shutdown, systemctl).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794266
Uwe Kleine-König
Apr 27, 2016, 5:40:03 PM4/27/16
to
Hello Helge,
On 04/17/2016 04:18 PM, Helge Wiemann wrote:
> However, all is good now.
can you try if doing:
echo +2 > /sys/class/rtc/rtc0/wakealarm
triggers the problem again?
If so,
echo 0 > /sys/class/rtc/rtc0/wakealarm
might fix it again.
Do you have something about rtc in your dmesg in the broken case?
Best regards
Uwe
On 04/17/2016 04:18 PM, Helge Wiemann wrote:
> However, all is good now.
echo +2 > /sys/class/rtc/rtc0/wakealarm
triggers the problem again?
If so,
echo 0 > /sys/class/rtc/rtc0/wakealarm
might fix it again.
Do you have something about rtc in your dmesg in the broken case?
Best regards
Uwe
jfc
Apr 30, 2016, 1:50:03 PM4/30/16
to
Hi Martin,
Thanks for your help. I followed the given procedure and I can power off the Qnap now.
Thanks for your help. I followed the given procedure and I can power off the Qnap now.
qnap:/home/jfc# echo 0-0030 >
/sys/bus/i2c/devices/0-0030/driver/unbind
qnap:/home/jfc# i2cget 0 0x30 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x30, data address
0x01, using read byte data.
Continue? [Y/n] y
Error: Read failed
qnap:/home/jfc# i2cget 0 0x30 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-0, chip address 0x30, data address
0x01, using read byte data.
Continue? [Y/n] y
Martin Michlmayr
Jul 15, 2016, 3:00:02 PM7/15/16
to
I don't think it has been mentioned here, but Uwe Kleine-König has
found and fixed this bug!
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794266#95
found and fixed this bug!
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794266#95
Helge Wiemann
Jul 16, 2016, 12:30:02 PM7/16/16
to
Hello Martin,
Thank you for posting this. Although the shutdown issue disappeared
after reinstalling the entire system my NAS would still occasionally
boot and immediately shutdown for no obvious reason. A second boot would
bring the system up as expected, but it was annoying nonetheless.
I tried this fix and the problem has entirely gone away! No random
shutdown while booting.
So thank you for making the connection and posting the link here.
Helge
--
Thank you for posting this. Although the shutdown issue disappeared
after reinstalling the entire system my NAS would still occasionally
boot and immediately shutdown for no obvious reason. A second boot would
bring the system up as expected, but it was annoying nonetheless.
I tried this fix and the problem has entirely gone away! No random
shutdown while booting.
So thank you for making the connection and posting the link here.
Helge
--
Helge Wiemann
Jul 17, 2016, 6:50:02 AM7/17/16
to
Hello Uwe,
Sorry for my late reply, but I stopped watching this thread and relied
on the mailing system to send me a notification (which never came). I
learned from Martin yesterday there has been a fix and he kindly
forwarded your solution to me.
This is what made my problems disappear entirely:
apt install i2c-tools
echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
i2cget -y 0 0x30 0x80
I ignored the error message and have not had an issue since. Thanks a
lot for your help, this is great news!
HW
Sorry for my late reply, but I stopped watching this thread and relied
on the mailing system to send me a notification (which never came). I
learned from Martin yesterday there has been a fix and he kindly
forwarded your solution to me.
This is what made my problems disappear entirely:
apt install i2c-tools
echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
i2cget -y 0 0x30 0x80
I ignored the error message and have not had an issue since. Thanks a
lot for your help, this is great news!
HW
Uwe Kleine-König
Jul 17, 2016, 12:00:02 PM7/17/16
to
Hello Helge,
On Sun, Jul 17, 2016 at 08:25:37AM +0200, Helge Wiemann wrote:
> Sorry for my late reply, but I stopped watching this thread and relied on
> the mailing system to send me a notification (which never came). I learned
> from Martin yesterday there has been a fix and he kindly forwarded your
> solution to me.
>
> This is what made my problems disappear entirely:
>
> apt install i2c-tools
> echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
> i2cget -y 0 0x30 0x80
I'm glad I could help, but still I wonder about your case.
You wrote: "Although the shutdown issue disappeared after reinstalling
"immediatly shutdown"? Is this like a power off, or a clean reboot like
"init 6"? And I don't see what a reboot would change for the rtc chip
that I would expect only be able to wake up the machine but not shut it
down. Do you have a boot log? Can you reproduce the problem, e.g. by
setting the alarm:
echo +150 > /sys/bus/i2c/devices/0-0030/rtc/rtc*/wakealarm
and then wait 3 minutes.
If yes, goes the problem away after:
for i in +150 0 +150 0; do
echo $i > /sys/bus/i2c/devices/0-0030/rtc/rtc*/wakealarm
done
instead of the i2cget command?
On a side note I also don't understand why reinstalling the NAS changes
anything. Does the installer access the rtc other than setting the time?
Best regards
Uwe
On Sun, Jul 17, 2016 at 08:25:37AM +0200, Helge Wiemann wrote:
> Sorry for my late reply, but I stopped watching this thread and relied on
> the mailing system to send me a notification (which never came). I learned
> from Martin yesterday there has been a fix and he kindly forwarded your
> solution to me.
>
> This is what made my problems disappear entirely:
>
> apt install i2c-tools
> echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
> i2cget -y 0 0x30 0x80
You wrote: "Although the shutdown issue disappeared after reinstalling
the entire system my NAS would still occasionally boot and immediately
shutdown for no obvious reason. A second boot would bring the system up
as expected, but it was annoying nonetheless."
I have no explanation for this behavior. What do you mean saying
shutdown for no obvious reason. A second boot would bring the system up
as expected, but it was annoying nonetheless."
"immediatly shutdown"? Is this like a power off, or a clean reboot like
"init 6"? And I don't see what a reboot would change for the rtc chip
that I would expect only be able to wake up the machine but not shut it
down. Do you have a boot log? Can you reproduce the problem, e.g. by
setting the alarm:
echo +150 > /sys/bus/i2c/devices/0-0030/rtc/rtc*/wakealarm
and then wait 3 minutes.
If yes, goes the problem away after:
for i in +150 0 +150 0; do
echo $i > /sys/bus/i2c/devices/0-0030/rtc/rtc*/wakealarm
done
instead of the i2cget command?
On a side note I also don't understand why reinstalling the NAS changes
anything. Does the installer access the rtc other than setting the time?
Best regards
Uwe
Uwe Kleine-König
Jul 18, 2016, 7:30:03 PM7/18/16
to
Hello Helge,
On Mon, Jul 18, 2016 at 08:24:38PM +0200, Helge Wiemann wrote:
> Issuing...
>
> echo +150 > /sys/bus/i2c/devices/0-0030/rtc/rtc*/wakealarm
>
> ...would not work as I don't have the "rtc" directory.
But you have /sys/bus/i2c/devices/0-0030? Even if you didn't unbind the
driver with the command line that I mentioned in the bug report?
> But I have attached
> my log file and it clearly indicates there is indeed an RTC issue.
I only see the following related to rtcs:
> Jul 12 21:22:16 MediaCenter kernel: [ 2.815689] rtc-mv rtc-mv: internal RTC not ticking
> Jul 12 21:22:16 MediaCenter kernel: [ 2.828086] rtc (null): invalid alarm value: 1900-1-12 19:19:0
> Jul 12 21:22:16 MediaCenter kernel: [ 2.834150] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0
> Jul 12 21:22:16 MediaCenter kernel: [ 2.861368] rtc-s35390a 0-0030: setting system clock to 2016-07-12 19:22:02 UTC (1468351322)
The first is harmless, the second is also harmless and fixed in when my
patches go in. The two last lines are obviously ok.
One thing that I consider strange is:
> Jul 10 14:28:58 MediaCenter systemd[1]: Starting [Cron] "00 23 * * * /sbin/poweroff"...
I guess something (anacron?) tries to catch up that the machine was
already off at 23:00 yesterday? That could explain why you have to boot
twice and is independant of an rtc issue.
> I do not have an answer to your questions, but let me explain again what
> happened before I applied your patch:
>
> Every other boot or so when I pushed the ON button on my NAS the system
> would try to boot (first beep) and then immediately shut down (another beep)
> while in the middle of the process. I think you will see the exact same
> thing in the log files.
>
> It would not matter how I would shut down the system the night before
> (either by pushing the button or sending an SSH command), my NAS would
> consistently show this pattern every second time I would try to boot it
> again.
>
> Whether it has anything to do with RTC I do not know, but I doubt it. All I
> can confirm is that your fix did the magic and I have not had to start the
> NAS twice ever since.
If my suspicion above is right, it could only be that the rtc is
relevant because it influences the check "Given the last shutdown time
and the current boot time, was the job at 23:00 last night done or
should it be done now instead?".
Best regards
Uwe
On Mon, Jul 18, 2016 at 08:24:38PM +0200, Helge Wiemann wrote:
> Issuing...
>
> echo +150 > /sys/bus/i2c/devices/0-0030/rtc/rtc*/wakealarm
>
> ...would not work as I don't have the "rtc" directory.
But you have /sys/bus/i2c/devices/0-0030? Even if you didn't unbind the
driver with the command line that I mentioned in the bug report?
> But I have attached
> my log file and it clearly indicates there is indeed an RTC issue.
I only see the following related to rtcs:
> Jul 12 21:22:16 MediaCenter kernel: [ 2.815689] rtc-mv rtc-mv: internal RTC not ticking
> Jul 12 21:22:16 MediaCenter kernel: [ 2.828086] rtc (null): invalid alarm value: 1900-1-12 19:19:0
> Jul 12 21:22:16 MediaCenter kernel: [ 2.834150] rtc-s35390a 0-0030: rtc core: registered rtc-s35390a as rtc0
> Jul 12 21:22:16 MediaCenter kernel: [ 2.861368] rtc-s35390a 0-0030: setting system clock to 2016-07-12 19:22:02 UTC (1468351322)
The first is harmless, the second is also harmless and fixed in when my
patches go in. The two last lines are obviously ok.
One thing that I consider strange is:
> Jul 10 14:28:58 MediaCenter systemd[1]: Starting [Cron] "00 23 * * * /sbin/poweroff"...
I guess something (anacron?) tries to catch up that the machine was
already off at 23:00 yesterday? That could explain why you have to boot
twice and is independant of an rtc issue.
> I do not have an answer to your questions, but let me explain again what
> happened before I applied your patch:
>
> Every other boot or so when I pushed the ON button on my NAS the system
> would try to boot (first beep) and then immediately shut down (another beep)
> while in the middle of the process. I think you will see the exact same
> thing in the log files.
>
> It would not matter how I would shut down the system the night before
> (either by pushing the button or sending an SSH command), my NAS would
> consistently show this pattern every second time I would try to boot it
> again.
>
> Whether it has anything to do with RTC I do not know, but I doubt it. All I
> can confirm is that your fix did the magic and I have not had to start the
> NAS twice ever since.
If my suspicion above is right, it could only be that the rtc is
relevant because it influences the check "Given the last shutdown time
and the current boot time, was the job at 23:00 last night done or
should it be done now instead?".
Best regards
Uwe
Helge Wiemann
Jul 19, 2016, 8:10:03 PM7/19/16
to
Hello Uwe,
I do have "/sys/bus/i2c/devices/0-0030", but did not specifically follow
your instructions you described in the bug report. If it helps you I
will, please let me know.
I am running a cron job to switch off my NAS at 11 PM. However, my issue
(shutting down after a short boot) was not related to that, I did not
see any particular pattern at all. This issue did still occur when I
switched off my NAS using the power button or SSH. So I doubt either RTC
or Crontab are the culprits.
Whatever the issue was, it's a thing of the past as your fixed worked.
Thanks a lot for that!
Helge
--
I do have "/sys/bus/i2c/devices/0-0030", but did not specifically follow
your instructions you described in the bug report. If it helps you I
will, please let me know.
I am running a cron job to switch off my NAS at 11 PM. However, my issue
(shutting down after a short boot) was not related to that, I did not
see any particular pattern at all. This issue did still occur when I
switched off my NAS using the power button or SSH. So I doubt either RTC
or Crontab are the culprits.
Whatever the issue was, it's a thing of the past as your fixed worked.
Thanks a lot for that!
Helge
--
Uwe Kleine-König
Jul 19, 2016, 8:20:02 PM7/19/16
to
Hello,
On Tue, Jul 19, 2016 at 09:47:04PM +0200, Helge Wiemann wrote:
> I do have "/sys/bus/i2c/devices/0-0030", but did not specifically follow
> your instructions you described in the bug report. If it helps you I will,
> please let me know.
>
> I am running a cron job to switch off my NAS at 11 PM. However, my issue
> (shutting down after a short boot) was not related to that, I did not see
> any particular pattern at all. This issue did still occur when I switched
> off my NAS using the power button or SSH. So I doubt either RTC or Crontab
> are the culprits.
I think you're wrong here. Reading your syslog I see the following:
- You shut down your machine at Jul 9 22:29
- You booted it at Jul 10 14:28
- Log has:
Jul 10 14:59:37 MediaCenter systemd[1]: Starting [Cron] "00 23 * * * /sbin/poweroff".
Jul 10 14:59:37 MediaCenter systemd[1]: Started [Cron] "00 23 * * * /sbin/poweroff".
and in the following the machine shuts down.
- In the following boot at Jul 10 15:00 this is not mentioned and the
machine boots up successfully.
So my suspection is that at 14:59 the poweroff job was caught up for
because it didn't run the day before. Then at 15:00 it wasn't run,
because it already was active a minute before.
Assuming your machine still has a (more or less) accurate date in its
rtc, I'm sure the issue returns if you disable the machine before 23:00
and restart it the next day. Given that you don't have the path
/sys/bus/i2c/devices/0-0030/rtc maybe the driver fails to bind now
because the rtc hardware is in a strange state and so the cron daemon
doesn't notice it has to catch up for the poweroff job?
Can you provide a boot log of the supposed fixed current state?
Best regards
Uwe
On Tue, Jul 19, 2016 at 09:47:04PM +0200, Helge Wiemann wrote:
> I do have "/sys/bus/i2c/devices/0-0030", but did not specifically follow
> your instructions you described in the bug report. If it helps you I will,
> please let me know.
>
> I am running a cron job to switch off my NAS at 11 PM. However, my issue
> (shutting down after a short boot) was not related to that, I did not see
> any particular pattern at all. This issue did still occur when I switched
> off my NAS using the power button or SSH. So I doubt either RTC or Crontab
> are the culprits.
- You shut down your machine at Jul 9 22:29
- You booted it at Jul 10 14:28
- Log has:
Jul 10 14:59:37 MediaCenter systemd[1]: Starting [Cron] "00 23 * * * /sbin/poweroff".
Jul 10 14:59:37 MediaCenter systemd[1]: Started [Cron] "00 23 * * * /sbin/poweroff".
and in the following the machine shuts down.
- In the following boot at Jul 10 15:00 this is not mentioned and the
machine boots up successfully.
So my suspection is that at 14:59 the poweroff job was caught up for
because it didn't run the day before. Then at 15:00 it wasn't run,
because it already was active a minute before.
Assuming your machine still has a (more or less) accurate date in its
rtc, I'm sure the issue returns if you disable the machine before 23:00
and restart it the next day. Given that you don't have the path
/sys/bus/i2c/devices/0-0030/rtc maybe the driver fails to bind now
because the rtc hardware is in a strange state and so the cron daemon
doesn't notice it has to catch up for the poweroff job?
Can you provide a boot log of the supposed fixed current state?
Best regards
Uwe
Helge Wiemann
Aug 6, 2016, 7:20:02 PM8/6/16
to
Hello Uwe,
It took a little longer as I was out of town for two weeks.
Ever since I applied your patch the system clock would not sync and
point to January 1st (1970?). Is there any way I can reverse the stuff I
did to my NAS?
Once I have done that I will retest again and see if I get to the gist
of the problem. I want to go through the whole procedure again and
understand what the issue is.
Would you mind? Thank you.
Helge
On 07/19/2016 10:10 PM, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jul 19, 2016 at 09:47:04PM +0200, Helge Wiemann wrote:
>> I do have "/sys/bus/i2c/devices/0-0030", but did not specifically follow
>> your instructions you described in the bug report. If it helps you I will,
>> please let me know.
>>
>> I am running a cron job to switch off my NAS at 11 PM. However, my issue
>> (shutting down after a short boot) was not related to that, I did not see
>> any particular pattern at all. This issue did still occur when I switched
>> off my NAS using the power button or SSH. So I doubt either RTC or Crontab
>> are the culprits.
>
> I think you're wrong here. Reading your syslog I see the following:
>
> - You shut down your machine at Jul 9 22:29
> - You booted it at Jul 10 14:28
> - Log has:
> Jul 10 14:59:37 MediaCenter systemd[1]: Starting [Cron] "00 23 * * * /sbin/poweroff".
> Jul 10 14:59:37 MediaCenter systemd[1]: Started [Cron] "00 23 * * * /sbin/poweroff".
> and in the following the machine shuts down.
> - In the fo llowing boot at Jul 10 15:00 this is not mentioned and the
It took a little longer as I was out of town for two weeks.
Ever since I applied your patch the system clock would not sync and
point to January 1st (1970?). Is there any way I can reverse the stuff I
did to my NAS?
Once I have done that I will retest again and see if I get to the gist
of the problem. I want to go through the whole procedure again and
understand what the issue is.
Would you mind? Thank you.
Helge
On 07/19/2016 10:10 PM, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jul 19, 2016 at 09:47:04PM +0200, Helge Wiemann wrote:
>> I do have "/sys/bus/i2c/devices/0-0030", but did not specifically follow
>> your instructions you described in the bug report. If it helps you I will,
>> please let me know.
>>
>> I am running a cron job to switch off my NAS at 11 PM. However, my issue
>> (shutting down after a short boot) was not related to that, I did not see
>> any particular pattern at all. This issue did still occur when I switched
>> off my NAS using the power button or SSH. So I doubt either RTC or Crontab
>> are the culprits.
>
> I think you're wrong here. Reading your syslog I see the following:
>
> - You shut down your machine at Jul 9 22:29
> - You booted it at Jul 10 14:28
> - Log has:
> Jul 10 14:59:37 MediaCenter systemd[1]: Starting [Cron] "00 23 * * * /sbin/poweroff".
> Jul 10 14:59:37 MediaCenter systemd[1]: Started [Cron] "00 23 * * * /sbin/poweroff".
> and in the following the machine shuts down.
Uwe Kleine-König
Aug 7, 2016, 9:10:02 AM8/7/16
to
Hello Helge,
On 08/06/2016 08:55 PM, Helge Wiemann wrote:
> Ever since I applied your patch the system clock would not sync and
> point to January 1st (1970?). Is there any way I can reverse the stuff I
> did to my NAS?
What is my patch? Can you show your boot log? What is the output on
console and boot log when doing the following commands:
# echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/unbind
# echo 1 > /sys/kernel/debug/tracing/events/i2c/enable
# i2cget -y 0 0x30 0x80
# echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/bind
# cat /sys/kernel/debug/tracing/trace
Best regards
Uwe
On 08/06/2016 08:55 PM, Helge Wiemann wrote:
> Ever since I applied your patch the system clock would not sync and
> point to January 1st (1970?). Is there any way I can reverse the stuff I
> did to my NAS?
console and boot log when doing the following commands:
# echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/unbind
# echo 1 > /sys/kernel/debug/tracing/events/i2c/enable
# i2cget -y 0 0x30 0x80
# echo 0-0030 > /sys/bus/i2c/drivers/rtc-s35390a/bind
# cat /sys/kernel/debug/tracing/trace
Best regards
Uwe
Uwe Kleine-König
Aug 7, 2016, 9:50:02 AM8/7/16
to
Hello Helge,
On 08/07/2016 11:37 AM, Helge Wiemann wrote:
> apt install i2c-tools
> echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
>
> 1) -bash: echo: write error: No such device
> 2) no output
> 3) i2cget -y 0 0x30 0x80
> 4) -bash: echo: write error: No such device
>
> Trace & system log are attached.
Your i2c bus is stuck, probably because the rtc pulls down the SDA line.
Can you make your machine completely voltage free for a moment? That is
remove any power cords and a maybe existing backup battery.
If you are able to locate the chip on your pcb, there must be 0 V
between pin 4 (VSS) and pin 8 (VDD).
Best regards
Uwe
On 08/07/2016 11:37 AM, Helge Wiemann wrote:
> apt install i2c-tools
> echo 0-0030 > /sys/bus/i2c/devices/0-0030/driver/unbind
> i2cget -y 0 0x30 0x80
>
> This is what you asked for:
>
>
> 1) -bash: echo: write error: No such device
> 2) no output
> 3) i2cget -y 0 0x30 0x80
> 4) -bash: echo: write error: No such device
>
> Trace & system log are attached.
Your i2c bus is stuck, probably because the rtc pulls down the SDA line.
Can you make your machine completely voltage free for a moment? That is
remove any power cords and a maybe existing backup battery.
If you are able to locate the chip on your pcb, there must be 0 V
between pin 4 (VSS) and pin 8 (VDD).
Best regards
Uwe
Uwe Kleine-König
Aug 8, 2016, 7:20:02 AM8/8/16
to
Hello Helge,
Cc: += linux-i2c
On Sun, Aug 07, 2016 at 08:48:29PM +0200, Helge Wiemann wrote:
> I located the battery and removed it for 60 seconds, then booted up my NAS
> and performed your commands. My syslog and tracelog are attached.
>
> I think this made no difference. The date is still incorrect.
This didn't help, the bus is still stuck:
> [ 2.817881] i2c i2c-0: mv64xxx_i2c_fsm: Ctlr Error -- state: 0x7, status: 0x38, addr: 0x30, flags: 0x1
This translates to:
state: MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_DATA
status: MV64XXX_I2C_STATUS_MAST_LOST_ARB
Not sure this is accurate though.
From a quick look the mv64xxx driver doesn't support bus recovery. So
unless someone implements this the best bet is probably:
- do it by hand, maybe from the bootloader
- do it really by hand, by shortcutting ground and SCL up to 9 times
until SDA goes high again.
Maybe someone from the i2c folks has a better idea.
Best regards
Uwe
Cc: += linux-i2c
On Sun, Aug 07, 2016 at 08:48:29PM +0200, Helge Wiemann wrote:
> I located the battery and removed it for 60 seconds, then booted up my NAS
> and performed your commands. My syslog and tracelog are attached.
>
> I think this made no difference. The date is still incorrect.
> [ 2.817881] i2c i2c-0: mv64xxx_i2c_fsm: Ctlr Error -- state: 0x7, status: 0x38, addr: 0x30, flags: 0x1
This translates to:
state: MV64XXX_I2C_STATE_WAITING_FOR_SLAVE_DATA
status: MV64XXX_I2C_STATUS_MAST_LOST_ARB
Not sure this is accurate though.
From a quick look the mv64xxx driver doesn't support bus recovery. So
unless someone implements this the best bet is probably:
- do it by hand, maybe from the bootloader
- do it really by hand, by shortcutting ground and SCL up to 9 times
until SDA goes high again.
Maybe someone from the i2c folks has a better idea.
Best regards
Uwe
0 new messages