<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugzilla.yoctoproject.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugzilla.yoctoproject.org/"
          
          maintainer="it-coreprojects-helpdesk@linuxfoundation.org"
>

    <bug>
          <bug_id>1541</bug_id>
          
          <creation_ts>2011-09-29 19:56:34 +0000</creation_ts>
          <short_desc>preempt-rt kernel shutdown now command does not work</short_desc>
          <delta_ts>2011-12-15 11:37:53 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>6</classification_id>
          <classification>Yocto Project Subprojects</classification>
          <product>Kernel</product>
          <component>kernel-tooling</component>
          <version>unspecified</version>
          <rep_platform>x86</rep_platform>
          <op_sys>x86_64</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>Medium</priority>
          <bug_severity>major</bug_severity>
          <target_milestone>1.2</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="kishore">kishore.k.bodke</reporter>
          <assigned_to name="Bruce Ashfield">bruce.ashfield</assigned_to>
          <cc>bruce.ashfield</cc>
    
    <cc>yp.kernel.watcher</cc>
    
    <cc>yp.watcher</cc>
          
          
          <cf_os>---</cf_os>
          <cf_regression_type>---</cf_regression_type>
          
          <cf_docchange>---</cf_docchange>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>16568</commentid>
    <comment_count>0</comment_count>
    <who name="kishore">kishore.k.bodke</who>
    <bug_when>2011-09-29 19:56:34 +0000</bug_when>
    <thetext>“shutdown –h now” command is not working on core-image-sato image with preempt-rt kernel 3.0.4  on Romley and crystal forest BSP

I get 
Warning**: could not initialize ACPI battery.
Xinit: connection to X server lost.
xinit: uexpected signal 15


For the non-rt &quot;shutdown now&quot; works perfectly fine. 
For the rt kernel, after the command is issued, it tries to halt the system and hangs there  forever after the connection to the X server is lost.

Thanks
Kishore</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>16619</commentid>
    <comment_count>1</comment_count>
    <who name="Darren Hart">dvhart</who>
    <bug_when>2011-10-03 09:21:18 +0000</bug_when>
    <thetext>Confirmed on the n450 -rt vs. -minimal images. The Xinit messages are a red herring, they appear on non-rt as well. However, using a core-image-rt image, I see the following on the console, and then the system hangs, unresponsive to user input and does not shutdown:

INIT: Switching to runlevel: 0
INIT: Switching to runlevel: 0
INIT: Sending processes the TERM signal
INIT: Sending processes the KILL signal
Stopping syslogd/klogd: stopped syslogd (pid 1010)
stopped klogd (pid 1012)
done
Deconfiguring network interfaces... done.
Sending processes the TERM signal
Sending processes the KILL signal
Unmounting remote filesystems...
Deactivating swap...
Unmounting lcoal filesystems...
md: stopping all md device.
e1000e 0000:04:00.0: PCI INT A disabled

Running &quot;reboot&quot; however works as expected.

Booting with &quot;maxcpus=1&quot; allows &quot;shutdown -h now&quot; to work properly as well, per Bruce&apos;s suggestion.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>16702</commentid>
    <comment_count>2</comment_count>
    <who name="Darren Hart">dvhart</who>
    <bug_when>2011-10-04 15:52:42 +0000</bug_when>
    <thetext>This is fixed in -rt16, which is the version following -rt14 (where it was still broken). The delta from 14 to 15 is available here:

https://tglx.de/~tglx/rt/older/patch-3.0.4-rt14-rt15.patch.gz

Changes from 15 to 16 are just dropping patches to apply against 3.0.6.

Full preempt_rt 3.0.6-rt16 patch is available here:
https://tglx.de/~tglx/rt/patch-3.0.6-rt16.patch.gz

And the broken out patch set is available here:
https://tglx.de/~tglx/rt/patches-3.0.6-rt16.tar.gz

Bruce, so long as preempt-rt remains in a rebasing quilt tree, I suggest we rebase and use the full patch set. I&apos;d rather rebase and have the individual patches than not rebase and have a non-contextual chunk to patch from -14 to -15.

This will get fixed once we update the main yocto repository to 3.0.6 and then update the preempt-rt branch to -rt16.

Assigning to Bruce to make that clear, although I can help with the preempt-rt branch once 3.0.6 is in.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>16703</commentid>
    <comment_count>3</comment_count>
    <who name="Bruce Ashfield">bruce.ashfield</who>
    <bug_when>2011-10-04 19:13:12 +0000</bug_when>
    <thetext>I&apos;ve been sitting on the -rt updates on purpose, since this close to 1.1 a non-fastforward
update isn&apos;t something I&apos;d like to do to the repo, and even less do any real tweaking of
the -rt content. 

An issue like this, I&apos;d suggest we can fix it post 1.1 with a new / rebased -rt patch queue,
but if we fix it for 1.1, I&apos;d want to do an incremental update on the rt branches, not a rebuild.

I think we agree here, since we don&apos;t be doing 3.0.6 for 1.1, we can deal with both these at
the same time. The plan has always been to rebuild the rt series when appropriate, and I&apos;d
agree that it is appropriate post 1.1.

As such, I tagged this as 1.2. If anyone disagrees, feel free to interject.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>17674</commentid>
    <comment_count>4</comment_count>
    <who name="Bruce Ashfield">bruce.ashfield</who>
    <bug_when>2011-12-15 11:37:53 +0000</bug_when>
    <thetext>This has been fixed by the RT updates in the 3.0.x kernel.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>