LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 12-05-2010, 06:41 PM   #16
lpallard
Member
 
Registered: Nov 2008
Location: Milky Way
Distribution: Slackware (various releases)
Posts: 970

Original Poster
Rep: Reputation: 44
Smile


Tried it five times in a row to be sure it would not crash and was working fine...

Works perfectly it goes to sleep and comes back no problem. At least this works flawlessly on this machine... Not the same for the ATI card... (piece of *!?*!)

Thanks GrapefruiTgirl for your help!
 
Old 12-05-2010, 07:36 PM   #17
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
ATI problem suggestions..

Quote:
Originally Posted by lpallard View Post
Tried it five times in a row to be sure it would not crash and was working fine...

Works perfectly it goes to sleep and comes back no problem. At least this works flawlessly on this machine...
That's great! Glad to hear it.
Quote:
Not the same for the ATI card... (piece of *!?*!)
Maybe a similar solution? I have next to no hands-on experience with ATI cards & drivers (my roommates ATI laptop suspends well, FWIW), but try unplugging the fglrx or whatever driver you're using, before suspend?

You may not (probably won't) be able to do this unless you shut X down before suspend (even if the module is attempted to be unplugged by the script AFTER switching to the non-X VT, X probably will not release the driver because it (X11) *is* still running on the other VT, but worth a try).

If you can't unplug it with X still running on the other VT, create yourself a new rc script similar to your mythbackend script (or modify that one), except this one would, in combination with the suspend script, perform the following sequence:

1) kill mythbackend or whatever may be running on X
2) switch to the console
3) shut X11 down (if this involves killing a KDE, there may be a cleaner way to tell KDE to exit)
4) unplug the ATI driver.
5) go to sleep.

upon resume, it should:
1) re-insert the ATI driver (optional - X11 will do this anyhow.)
2) restart X11 on VT7 (I guess you use VT7? Most probably..)
3) switch back to VT7 (if it hasn't happened automatically - depends how you start X - I use `startx` command, but starting a login manager like KDM will also do it.)
4) restart any apps you want running (mythbackend?)

You'd want to maybe make a teensy modification the suspend script a little bit in order to achieve the above sequence of operations for the resume operation. Below, see the red line I commented out. The reason is so that we do not switch back to VT7 before X starts; my worry is that X11 will refuse to start on VT7 if we have already changed back to VT7 first; X11 might decide the VT is in use, and quit. This may be a needless worry, but I haven't tried this exact thing lately so I don't know if it would fail or not - maybe try it and see. See below for the simple edit (on my version of the script, it's line #337):
Code:
 # Resuming now;

 $hwclock --hctosys # adjust OS clock
 message R
 # reinsert removed modules
 [ ! "$insert_list" ] && insert_list="$unplug_list"
 for mod in $insert_list; do
   $modprobe $mod 2>/dev/null
 done;
 sleep 1 # let things settle
 # Kill any running dhcpcd & restart networking as during a cold boot:
 [ "$(ps ax | grep dhcpcd)" ] && killall -q dhcpcd
 $net_init_script $net_init_script_arg > $console
# chvt $original_vt
 # check if want to run any external thing/command after resuming; I put this
 # _after_ the chvt back to the original VT in case we want to start an
 # X-dependant application but don't want to frig around with $DISPLAY vars
 # and app CLI switches to make it start on the right VT.
 [ "$external_after_suspend" = "yes" ] && external_prog start
 logging stop
 rm -f $log_pidfile $fork_pidfile
} # end of 'do_suspend'
Two things or so, to keep in mind RE all the above:
1) If the ATI driver itself is not the problem (another driver, hardware, acpi..), obviously much/most/some of this will be non-relevant.
2) killing X11 and (especially/particuarly) restarting it, will be done differently if you're using a login manager, such as KDM. At this very moment, I can't advise precisely how, but taking the lead from the /etc/rc.d/rc.4 file may be a good idea.
3) I'm assuming the other machine uses Slackware too, yes?
Quote:
Thanks GrapefruiTgirl for your help!
You're very welcome! If you decide to investigate further the ATI machine situation, let us know how it goes and/or what you discover. Cheers.

Last edited by GrapefruiTgirl; 12-05-2010 at 07:37 PM.
 
Old 12-05-2010, 07:43 PM   #18
lpallard
Member
 
Registered: Nov 2008
Location: Milky Way
Distribution: Slackware (various releases)
Posts: 970

Original Poster
Rep: Reputation: 44
OMG! I should have specified that my ATI problem was not related to the suspend on ram thing... I was just whining about the fact that nothing works well with that ATI card.. audio over hdmi is horrible (work 70% of the time, the rest of the time it is choppy or cuts off every once in a while, graphics are choppy, video tearing, low fps, visual glitches, etc....) basically a huge mess... the list is too long !

I will probably switch to a nvidia card.

I feel bad about your long reply. I am sorry!

Thanks!
 
Old 12-05-2010, 07:59 PM   #19
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
Oh hey, that's OK.

Someone may find it helpful! Don't feel bad.

Cheers!
 
Old 12-05-2010, 08:21 PM   #20
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 3,919

Rep: Reputation: 779Reputation: 779Reputation: 779Reputation: 779Reputation: 779Reputation: 779Reputation: 779
Quote:
Originally Posted by lpallard View Post
The strangest thing is KDE showed a popup saying:
Code:
KDE detected that one or more internal sound devices were removed.
Do you want KDE to permanently forget about these devices?
This is the list of devices KDE thinks can be removed:
Output: HD-Audio Generic, ATI HDMI (HDMI Audio Output)
WTF? This is my main audio output device!...
I get this occasionally on my laptop, although that is on recovery from suspend to disk. OpenSUSE 11.3, KDE 4.5.3, and I assume that this is a KDE bug, but it may be a bug from somewhere else in the infrastructure being passed on to KDE.

Don't remember this ever happening with KDE 3.5.x, or even early versions of of KDE 4.x, for that matter, although everything else went wrong with early versions of 4.x, so that hardly seems like a way forward.
 
Old 12-06-2010, 05:03 PM   #21
lpallard
Member
 
Registered: Nov 2008
Location: Milky Way
Distribution: Slackware (various releases)
Posts: 970

Original Poster
Rep: Reputation: 44
Grapefruitgirl, would you know how to modify KDE so it uses your script instead of whatever functions are normally called for the suspend to ram ? (thinking about the K menu -> Leave -> Shutdown (and then sleep to ram) or simply -> Sleep?

Yes the sound bug is weird... I will keep monitoring that for complications and refer to LQ if necessary...
 
Old 12-06-2010, 05:39 PM   #22
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
Quote:
Originally Posted by lpallard View Post
Grapefruitgirl, would you know how to modify KDE so it uses your script instead of whatever functions are normally called for the suspend to ram ? (thinking about the K menu -> Leave -> Shutdown (and then sleep to ram) or simply -> Sleep?
I do not know exactly how those KDE menu buttons work, and no longer use KDE for some time now. I do remember that it was simple enough to create a new launcher/button on the kDE panel or menu though, which you could configure to execute the s2 script. However, the script needs root priveleges to run.

What I've done in the past when I needed to run such a script or tool (as root) using a KDE launch button, was use `kdesu` like so in my launcher configuration dialog's "path to application" field:
Code:
'kdesu /path/to/script arg [arg2 ...]'
This will prompt for the root password. If you don't want this, then you'll need to research more into how those KDE buttons work without asking for a password; maybe they use a SUID binary, but I really don't know. I hope someone else can shed some light on exactly how they do this.

Last edited by GrapefruiTgirl; 12-06-2010 at 05:42 PM. Reason: added couple words
 
Old 12-06-2010, 06:44 PM   #23
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
daemon-mode for the suspend script - allows suspend by regular user

I had dinner, and it gave me an idea, which works! It is not elegant (except in its relative simplicity) and you will probably maybe want to tighten up the permissions for the directory this uses, though for your intended purpose on an HTPC, loose permissions on this empty tempfile are not a gigantic concern.

(Slightly off-topic: I like this idea. I might incorporate it in a more permanent way directly within the suspend script itself, so that regular users can suspend their machines using the script, without the need to switch to root. i.e. daemon-mode will be an option for the script somehow.)

Here's the idea:
In one of your root-owned bash rc startup scripts (like rc.local), you would have the following command:
Code:
/etc/rc.d/rc.suspend2_daemon & disown
What that command will do is during power-up, start the following script, and detach it from its parent tty so it runs like a daemon in the background:
Code:
#!/bin/bash
# This script is /etc/rc.d/rc.suspend2_daemon         

if [ ! -d /tmp/suspendmenow ]; then
        mkdir -p /tmp/suspendmenow
else
        rm -rf  /tmp/suspendmenow/*
        chown sasha:users /tmp/suspendmenow
        chmod 777 /tmp/suspendmenow
fi

while true; do
        sleep 1
        if [ -f /tmp/suspendmenow/doit ]; then
                rm -f /tmp/suspendmenow/doit
                sync
                /usr/bin/s2 mem
        fi
done
Now that that's all set up and assuming you've rebooted or manually run the command above, the "daemon" will be started. To use it, you can do one of two things:

(1) give the command in a terminal:
Code:
touch /tmp/suspendmenow/doit
or

(2) make your KDE button issue the above (1) command.

The daemon, upon seeing that file exists, will delete the tempfile and execute your suspend script, putting machine to sleep.

It works great for me! Let me know if it works for you.

If there's a better idea, or ways to improve this, I am interested in hearing about it, as well as about how the KDE buttons work, if someone knows.

Last edited by GrapefruiTgirl; 12-06-2010 at 06:45 PM.
 
Old 12-06-2010, 06:47 PM   #24
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 7,140
Blog Entries: 52

Rep: Reputation: Disabled
Quote:
Originally Posted by GrapefruiTgirl View Post
I had dinner, and it gave me an idea, which works!
What? You can learn bash scripting just by eating a meal? Wow!
 
Old 12-06-2010, 07:21 PM   #25
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
Quote:
Originally Posted by brianL View Post
What? You can learn bash scripting just by eating a meal? Wow!
You're surprised? Even considering all the genetically modified food being born & eaten every day around the world, you're surprised that I can turn some cow, and a small pile of tubers, into a simple bash script???
 
Old 12-06-2010, 07:25 PM   #26
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 7,140
Blog Entries: 52

Rep: Reputation: Disabled
Ah yes, the marvels of modern science. My food musn't be genetically modified, 'cause I know nowt about owt. (as we say in Oldham )
 
Old 12-19-2010, 09:52 PM   #27
lpallard
Member
 
Registered: Nov 2008
Location: Milky Way
Distribution: Slackware (various releases)
Posts: 970

Original Poster
Rep: Reputation: 44
Well I guess it works perfectly!

Now I need to find a way to make it nicer.... I'll dig on some forums and post back once I know how to hack the KDE menus...

Thanks GrapefruiTgirl!!!
 
Old 12-21-2010, 06:18 PM   #28
lpallard
Member
 
Registered: Nov 2008
Location: Milky Way
Distribution: Slackware (various releases)
Posts: 970

Original Poster
Rep: Reputation: 44
Well... I guess I'm back to the beginning...

this morning I activated the suspend 2 ram script that so far worked flawessly and after returning from work I reactivated the machine to be greeted by this:

Code:
Restarting tasks ... done.
saa7164[0]: Dumping the bus structure:
saa7164[0]:  .type             = 2
saa7164[0]:  .dev->bmmio       = 0xffffc90010c80000
saa7164[0]:  .m_wMaxReqSize    = 0x100
saa7164[0]:  .m_pdwSetRing     = 0xffffc90010c81000
saa7164[0]:  .m_dwSizeSetRing  = 0x1000
saa7164[0]:  .m_pdwGetRing     = 0xffffc90010c82000
saa7164[0]:  .m_dwSizeGetRing  = 0x1000
saa7164[0]:  .m_dwSetReadPos   = 0xf4 (0x3eaba28e)
saa7164[0]:  .m_dwSetWritePos  = 0xf0 (0xdf55bead)
saa7164[0]:  .m_dwGetReadPos   = 0xfc (0x5ca79d23)
saa7164[0]:  .m_dwGetWritePos  = 0xf8 (0xeb7aa6c2)
------------[ cut here ]------------
kernel BUG at /root/saa7164-stable/v4l/saa7164-bus.c:106!
invalid opcode: 0000 [#1] SMP 
last sysfs file: /sys/power/state
CPU 1 
Pid: 3556, comm: mythbackend Tainted: P           2.6.33.4 #3 M4A785T-M/System Product Name
RIP: 0010:[<ffffffffa00da802>]  [<ffffffffa00da802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
RSP: 0018:ffff8801016c7b38  EFLAGS: 00010292
RAX: 0000000000000039 RBX: ffff88012c9e0000 RCX: ffffffff821e6d00
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff821e6bb4
RBP: ffff8801016c7b38 R08: 00000000ffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 000000000000000e R12: ffff88012c9e0000
R13: 0000000000000000 R14: ffff8801016c7c48 R15: ffff8801016c7db4
FS:  00007f6a207f8710(0000) GS:ffff880006040000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6a31a0d380 CR3: 000000011c610000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mythbackend (pid: 3556, threadinfo ffff8801016c6000, task ffff880107745cc0)
Stack:
 ffff8801016c7ba8 ffffffffa00dad5e ffff88011c505818 ffff880107723fb8
<0> 0000000000013b80 0000000000013b80 ffff8801016c7db4 0000000000013b80
<0> 0000000000013b80 ffff8801016c7c48 ffff88012c9e0000 0000000000000000
Call Trace:
 [<ffffffffa00dad5e>] saa7164_bus_set+0x3e/0x5e0 [saa7164]
 [<ffffffffa00dbefc>] saa7164_cmd_set+0xfc/0x1b0 [saa7164]
 [<ffffffffa00dc09f>] saa7164_cmd_send+0xef/0x870 [saa7164]
 [<ffffffff81114b3a>] ? __d_lookup+0xaa/0x140
 [<ffffffff81113baf>] ? dput+0xbf/0x190
 [<ffffffff8110ac95>] ? path_to_nameidata+0x25/0x60
 [<ffffffff8110c6e0>] ? link_path_walk+0x610/0xd90
 [<ffffffff8111ac39>] ? mntput_no_expire+0x29/0xf0
 [<ffffffff8111ac39>] ? mntput_no_expire+0x29/0xf0
 [<ffffffffa00dcb65>] saa7164_api_transition_port+0x35/0x60 [saa7164]
 [<ffffffffa00d87a6>] saa7164_dvb_stop_feed+0xb6/0x260 [saa7164]
 [<ffffffffa005a905>] dmx_ts_feed_stop_filtering+0x55/0xd0 [dvb_core]
 [<ffffffffa0058e4a>] dvb_dmxdev_feed_stop+0x9a/0xc0 [dvb_core]
 [<ffffffffa0059175>] dvb_dmxdev_filter_stop+0xa5/0x100 [dvb_core]
 [<ffffffffa0059dda>] dvb_demux_release+0x4a/0x210 [dvb_core]
 [<ffffffff81101cc5>] __fput+0xf5/0x210
 [<ffffffff81101e05>] fput+0x25/0x30
 [<ffffffff810fe1ed>] filp_close+0x5d/0x90
 [<ffffffff810fe2b5>] sys_close+0x95/0xe0
 [<ffffffff810028db>] system_call_fastpath+0x16/0x1b
Code: 00 00 83 d0 00 c1 ea 02 89 d2 48 c1 e2 02 48 03 57 30 8b 12 39 97 20 01 00 00 73 13 c7 05 63 a5 00 00 ff ff 00 00 e8 4e fd ff ff <0f> 0b eb fe 85 c0 75 e9 c9 c3 0f 1f 40 00 55 48 89 e5 48 83 ec 
RIP  [<ffffffffa00da802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
 RSP <ffff8801016c7b38>
---[ end trace 473a9dc672e47099 ]---
saa7164[0]: i2c_xfer(num = 2)
saa7164[0]: i2c_xfer(num = 2) addr = 0x19  len = 0x1
saa7164[0]: saa7164_api_i2c_read()
saa7164[0]: saa7164_cmd_send(unitid = CX24228/S5H1411-2 (TOP) (38) , command = 0x85, sel = 0x0)
saa7164[0]: saa7164_cmd_send() pcommand_t.seqno = 1
saa7164[0]: saa7164_cmd_send() pcommand_t.size = 2
saa7164[0]: saa7164_bus_set()
saa7164[0]: Dumping the bus structure:
saa7164[0]:  .type             = 2
saa7164[0]:  .dev->bmmio       = 0xffffc90010c80000
saa7164[0]:  .m_wMaxReqSize    = 0x100
saa7164[0]:  .m_pdwSetRing     = 0xffffc90010c81000
saa7164[0]:  .m_dwSizeSetRing  = 0x1000
saa7164[0]:  .m_pdwGetRing     = 0xffffc90010c82000
saa7164[0]:  .m_dwSizeGetRing  = 0x1000
saa7164[0]:  .m_dwSetReadPos   = 0xf4 (0x3eaba28e)
saa7164[0]:  .m_dwSetWritePos  = 0xf0 (0xdf55bead)
saa7164[0]:  .m_dwGetReadPos   = 0xfc (0x5ca79d23)
saa7164[0]:  .m_dwGetWritePos  = 0xf8 (0xeb7aa6c2)
------------[ cut here ]------------
kernel BUG at /root/saa7164-stable/v4l/saa7164-bus.c:106!
invalid opcode: 0000 [#2] SMP 
last sysfs file: /sys/module/pcmcia/initstate
CPU 0 
Pid: 2484, comm: mythbackend Tainted: P      D    2.6.33.4 #3 M4A785T-M/System Product Name
RIP: 0010:[<ffffffffa00da802>]  [<ffffffffa00da802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
RSP: 0018:ffff880101711678  EFLAGS: 00010296
RAX: 0000000000000039 RBX: ffff88012c9e0000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff821e6bb4
RBP: ffff880101711678 R08: 00000000ffffffff R09: 0000000000000002
R10: ffffffff81c6e420 R11: ffff88012fb6190f R12: ffff88012c9e0000
R13: 0000000000000000 R14: ffff880101711788 R15: ffff880101711916
FS:  00007f6a2a835710(0000) GS:ffff880006000000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006f0e24 CR3: 000000011c610000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mythbackend (pid: 2484, threadinfo ffff880101710000, task ffff88010c776a00)
Stack:
 ffff8801017116e8 ffffffffa00dad5e 0000000000000085 ffff880101711916
<0> ffff8801017116b8 ffffffff810428ba ffff880101711916 ffff88012c9e0c20
<0> ffff8801017116c8 ffff880101711788 ffff88012c9e0000 0000000000000000
Call Trace:
 [<ffffffffa00dad5e>] saa7164_bus_set+0x3e/0x5e0 [saa7164]
 [<ffffffff810428ba>] ? __cond_resched+0x2a/0x40
 [<ffffffffa00dbefc>] saa7164_cmd_set+0xfc/0x1b0 [saa7164]
 [<ffffffffa00dc09f>] saa7164_cmd_send+0xef/0x870 [saa7164]
 [<ffffffff81047368>] ? vprintk+0x198/0x430
 [<ffffffff8154e378>] ? fbcon_cursor+0x1d8/0x340
 [<ffffffff815523f0>] ? bit_cursor+0x0/0x6c0
 [<ffffffff819ffff3>] ? printk+0x41/0x43
 [<ffffffffa00de2a4>] saa7164_api_i2c_read+0x124/0x290 [saa7164]
 [<ffffffffa00d7d3e>] i2c_xfer+0xee/0x180 [saa7164]
 [<ffffffffa00006dc>] i2c_transfer+0xac/0x100 [i2c_core]
 [<ffffffff81111910>] ? __pollwait+0x0/0xf0
 [<ffffffffa003a7fe>] T.363+0x5e/0x90 [s5h1411]
 [<ffffffffa003aded>] s5h1411_read_snr+0xcd/0x250 [s5h1411]
 [<ffffffffa003af7e>] s5h1411_read_signal_strength+0xe/0x10 [s5h1411]
 [<ffffffffa0060bc8>] dvb_frontend_ioctl_legacy+0x1d8/0xd50 [dvb_core]
 [<ffffffff81912cad>] ? sock_alloc_send_pskb+0x1cd/0x320
 [<ffffffff819a3721>] ? unix_stream_recvmsg+0x331/0x6d0
 [<ffffffff8191a845>] ? memcpy_fromiovec+0x75/0x90
 [<ffffffff819163ed>] ? skb_queue_tail+0x4d/0x60
 [<ffffffff81913e0d>] ? sock_def_readable+0x1d/0x80
 [<ffffffffa006188b>] dvb_frontend_ioctl+0x14b/0xf20 [dvb_core]
 [<ffffffff8190fbf9>] ? sock_aio_write+0x139/0x150
 [<ffffffffa0057b4b>] dvb_usercopy+0xcb/0x1d0 [dvb_core]
 [<ffffffffa0061740>] ? dvb_frontend_ioctl+0x0/0xf20 [dvb_core]
 [<ffffffff811000e2>] ? do_sync_write+0xd2/0x110
 [<ffffffff810e2b08>] ? do_wp_page+0x398/0x7a0
 [<ffffffffa0057c85>] dvb_generic_ioctl+0x35/0x40 [dvb_core]
 [<ffffffff8110fddf>] vfs_ioctl+0x9f/0xd0
 [<ffffffff8111031a>] do_vfs_ioctl+0x8a/0x5a0
 [<ffffffff811108b1>] sys_ioctl+0x81/0xa0
 [<ffffffff810028db>] system_call_fastpath+0x16/0x1b
Code: 00 00 83 d0 00 c1 ea 02 89 d2 48 c1 e2 02 48 03 57 30 8b 12 39 97 20 01 00 00 73 13 c7 05 63 a5 00 00 ff ff 00 00 e8 4e fd ff ff <0f> 0b eb fe 85 c0 75 e9 c9 c3 0f 1f 40 00 55 48 89 e5 48 83 ec 
RIP  [<ffffffffa00da802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
 RSP <ffff880101711678>
---[ end trace 473a9dc672e4709a ]---
ehci_hcd: module is already loaded
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Error: Driver 'ohci_hcd' is already registered, aborting...
hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
saa7164[0]: i2c_xfer(num = 2)
saa7164[0]: i2c_xfer(num = 2) addr = 0x19  len = 0x1
saa7164[0]: saa7164_api_i2c_read()
saa7164[0]: saa7164_cmd_send(unitid = CX24228/S5H1411-1 (TOP) (7) , command = 0x85, sel = 0x0)
saa7164[0]: saa7164_cmd_send() pcommand_t.seqno = 2
saa7164[0]: saa7164_cmd_send() pcommand_t.size = 2
saa7164[0]: saa7164_bus_set()
saa7164[0]: Dumping the bus structure:
saa7164[0]:  .type             = 2
saa7164[0]:  .dev->bmmio       = 0xffffc90010c80000
saa7164[0]:  .m_wMaxReqSize    = 0x100
saa7164[0]:  .m_pdwSetRing     = 0xffffc90010c81000
saa7164[0]:  .m_dwSizeSetRing  = 0x1000
saa7164[0]:  .m_pdwGetRing     = 0xffffc90010c82000
saa7164[0]:  .m_dwSizeGetRing  = 0x1000
saa7164[0]:  .m_dwSetReadPos   = 0xf4 (0x3eaba28e)
saa7164[0]:  .m_dwSetWritePos  = 0xf0 (0xdf55bead)
saa7164[0]:  .m_dwGetReadPos   = 0xfc (0x5ca79d23)
saa7164[0]:  .m_dwGetWritePos  = 0xf8 (0xeb7aa6c2)
------------[ cut here ]------------
kernel BUG at /root/saa7164-stable/v4l/saa7164-bus.c:106!
invalid opcode: 0000 [#3] SMP 
last sysfs file: /sys/module/saa7164/initstate
CPU 1 
Pid: 2335, comm: kdvb-ad-0-fe-0 Tainted: P      D    2.6.33.4 #3 M4A785T-M/System Product Name
RIP: 0010:[<ffffffffa00da802>]  [<ffffffffa00da802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
RSP: 0018:ffff88011c77f900  EFLAGS: 00010286
RAX: 0000000000000039 RBX: ffff88012c9e0000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff821e6bb4
RBP: ffff88011c77f900 R08: 00000000ffffffff R09: 0000000000000002
R10: ffffffff81c6e420 R11: ffff88012fb60cff R12: ffff88012c9e0000
R13: 0000000000000000 R14: ffff88011c77fa10 R15: ffff88011c77fb9e
FS:  00007fb17b38e710(0000) GS:ffff880006040000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000081c340 CR3: 0000000002040000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kdvb-ad-0-fe-0 (pid: 2335, threadinfo ffff88011c77e000, task ffff88012e07c8e0)
Stack:
 ffff88011c77f970 ffffffffa00dad5e 0000000000000085 ffff88011c77fb9e
<0> ffff88011c77f940 ffffffff810428ba ffff88011c77fb9e ffff88012c9e0368
<0> ffff88011c77f950 ffff88011c77fa10 ffff88012c9e0000 0000000000000000
Call Trace:
 [<ffffffffa00dad5e>] saa7164_bus_set+0x3e/0x5e0 [saa7164]
 [<ffffffff810428ba>] ? __cond_resched+0x2a/0x40
 [<ffffffffa00dbefc>] saa7164_cmd_set+0xfc/0x1b0 [saa7164]
 [<ffffffffa00dc09f>] saa7164_cmd_send+0xef/0x870 [saa7164]
 [<ffffffff8100324e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff81047368>] ? vprintk+0x198/0x430
 [<ffffffff8154e378>] ? fbcon_cursor+0x1d8/0x340
 [<ffffffff815523f0>] ? bit_cursor+0x0/0x6c0
 [<ffffffff819ffff3>] ? printk+0x41/0x43
 [<ffffffffa00de2a4>] saa7164_api_i2c_read+0x124/0x290 [saa7164]
 [<ffffffffa00d7d3e>] i2c_xfer+0xee/0x180 [saa7164]
 [<ffffffffa00006dc>] i2c_transfer+0xac/0x100 [i2c_core]
 [<ffffffffa003a7fe>] T.363+0x5e/0x90 [s5h1411]
 [<ffffffffa003acbd>] s5h1411_read_status+0x12d/0x190 [s5h1411]
 [<ffffffffa005ff4c>] dvb_frontend_swzigzag+0x9c/0x290 [dvb_core]
 [<ffffffffa00605a8>] dvb_frontend_thread+0x468/0x770 [dvb_core]
 [<ffffffff81065d40>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa0060140>] ? dvb_frontend_thread+0x0/0x770 [dvb_core]
 [<ffffffff81065846>] kthread+0x96/0xa0
 [<ffffffff81003694>] kernel_thread_helper+0x4/0x10
 [<ffffffff810657b0>] ? kthread+0x0/0xa0
 [<ffffffff81003690>] ? kernel_thread_helper+0x0/0x10
Code: 00 00 83 d0 00 c1 ea 02 89 d2 48 c1 e2 02 48 03 57 30 8b 12 39 97 20 01 00 00 73 13 c7 05 63 a5 00 00 ff ff 00 00 e8 4e fd ff ff <0f> 0b eb fe 85 c0 75 e9 c9 c3 0f 1f 40 00 55 48 89 e5 48 83 ec 
RIP  [<ffffffffa00da802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
 RSP <ffff88011c77f900>
---[ end trace 473a9dc672e4709b ]---
r8169: eth0: link up
eth0: no IPv6 routers present
?!?!?!? I am clueless... the modules saa7164 is in the script within the unload modules section...

Anybody???

EDIT: Its getting ugly. The sound device bug I mentioned in an earlier post happens again and now the machine no longer reboots or halt after one of these kernel seizures... Needs manual reset or unplug.

Last edited by lpallard; 12-21-2010 at 09:41 PM.
 
Old 12-22-2010, 08:55 AM   #29
GrapefruiTgirl
Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550Reputation: 550
I'm not really sure about all that stuff either.. If it isn't being caused by flaky failing hardware, then according to the strings within those log messages, there's a bug in the saa7146 driver module or elsewhere in the V4L subsystem somewhere. Most of that output you pasted, appears to be the type of stuff you'd submit to a bug-fixer or driver developer, but I don't know how complete it is, or under what conditions they might have you try to reproduce the situation to help them with debugging, assuming they agree that it's a bug, and one worth working on asap..

Did you verify that the module did infact get unplugged before the suspend? Maybe it refused to unplug, or took longer than it should have, resulting in a suspend happening while it was still plugged in. Just a theory!

If absolutely nothing else changed (software or OS updates, new hardware, etc..) between the last time (when this worked) and this time (it doesn't work), then hardware sticks out as failing (especially considering that weird sound buzz thing too).

Keep us posted!
 
Old 12-22-2010, 12:27 PM   #30
lpallard
Member
 
Registered: Nov 2008
Location: Milky Way
Distribution: Slackware (various releases)
Posts: 970

Original Poster
Rep: Reputation: 44
Are you thinking about mobo failure or tv tuner? since this problems correlates to the sound problem, I am thinking about mobo. Agree?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problems after resuming from suspend to ram chessonly Linux - General 1 08-10-2012 08:55 AM
Plz explain Suspend to Disk and Suspend to Ram pkhera_2001 Linux - Newbie 2 02-18-2008 08:23 AM
Suspend to RAM problems broxtor Ubuntu 0 03-31-2007 03:40 AM
How to suspend to ram ? I have problems. gkiagia Linux - Laptop and Netbook 3 09-09-2006 04:45 AM
modem usability problems after starting from "suspend to RAM" pusrob Linux - Networking 1 06-17-2006 03:54 AM


All times are GMT -5. The time now is 10:23 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration