--- Log opened Mon Oct 27 00:00:34 2014 00:48 <*> Quits ->woglinde_ [~henning@e179188208.adsl.alicedsl.de] [Ping timeout: 244 seconds] 00:51 <*> Quits ->kwizart [~kwizart@fedora/kwizart] [Remote host closed the connection] 02:58 <*> Lt_Tinkle_ is now known as Lt_Tinkle 03:41 <*> Quits ->sirderpalot [~pzzt@unaffiliated/sirderpalot] [Read error: Connection reset by peer] 03:52 <*> Quits ->woshty [~irc@84.200.211.57] [Ping timeout: 250 seconds] 03:53 <*> Joins[#ac100] ->woshty [~irc@84.200.211.57] 03:55 <*> Joins[#ac100] ->sirderpalot [~pzzt@unaffiliated/sirderpalot] 05:28 <*> Quits ->woshty [~irc@84.200.211.57] [Ping timeout: 250 seconds] 05:29 <*> Joins[#ac100] ->stuw_ [~stuw@87.255.14.112] 05:46 <*> Joins[#ac100] ->woshty [~irc@84.200.211.57] 05:48 <*> Quits ->stuw_ [~stuw@87.255.14.112] [Read error: Connection reset by peer] 08:17 <*> Quits ->sirderpalot [~pzzt@unaffiliated/sirderpalot] [Read error: Connection reset by peer] 08:31 <*> Joins[#ac100] ->sirderpalot [~pzzt@unaffiliated/sirderpalot] 09:33 <*> Quits ->vanger [~Android@87.252.227.63] [Ping timeout: 250 seconds] 09:52 <*> Quits ->zombah_ [~zombah@194.165.0.6] [Quit: Leaving] 10:03 <*> Joins[#ac100] ->woglinde [~henning@fb-n15-11.unbelievable-machine.net] 10:05 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 10:06 <*> Joins[#ac100] ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] 10:14 <*> Joins[#ac100] ->vanger [~Android@178.172.239.240] 10:42 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-xwgrdglzutvghlmp] 11:08 <*> Joins[#ac100] ->lovecraftian [~cthulhu@77.228.175.74] 11:08 <*> Quits ->lovecraftian [~cthulhu@77.228.175.74] [Changing host] 11:08 <*> Joins[#ac100] ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] 12:43 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.172.107] 13:01 <*> Quits ->brightkill [~brightkil@95.153.172.107] [Ping timeout: 244 seconds] 13:06 <*> phh_ is now known as phh 13:20 <*> Quits ->woshty [~irc@84.200.211.57] [Ping timeout: 250 seconds] 13:26 <*> Joins[#ac100] ->woshty [~irc@84.200.211.57] 13:28 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.172.107] 13:56 <*> Quits ->brightkill [~brightkil@95.153.172.107] [Ping timeout: 260 seconds] 15:19 <*> Quits ->marvin24_ [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 15:21 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 15:28 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.172.107] 15:54 <*> Joins[#ac100] ->afaerber_ [~andreasf_@p5494332F.dip0.t-ipconnect.de] 15:57 <*> Quits ->afaerber [~andreasf_@p5494036D.dip0.t-ipconnect.de] [Ping timeout: 240 seconds] 15:57 <*> afaerber_ is now known as afaerber 16:03 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 16:26 <*> Quits ->indy [~indy@shadow.kastnerove.cz] [Ping timeout: 244 seconds] 16:50 <*> Quits ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] [Quit: "cheerio chaps"] 17:01 <*> Joins[#ac100] ->lovecraftian [~cthulhu@77.228.175.74] 17:01 <*> Quits ->lovecraftian [~cthulhu@77.228.175.74] [Changing host] 17:01 <*> Joins[#ac100] ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] 17:16 <*> Joins[#ac100] ->marvin24_ [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 17:17 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Ping timeout: 265 seconds] 17:49 <*> Quits ->stenzel [stenzel@nat/ibm/x-xwgrdglzutvghlmp] [Ping timeout: 265 seconds] 18:08 <*> Quits ->brightkill [~brightkil@95.153.172.107] [Ping timeout: 244 seconds] 18:10 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.172.107] 18:38 <*> Joins[#ac100] ->indy [~indy@shadow.kastnerove.cz] 18:39 <*> Quits ->vanger [~Android@178.172.239.240] [Read error: Connection reset by peer] 18:45 <*> Joins[#ac100] ->vanger [~Android@by1-office.wargaming.net] 19:03 <*> Joins[#ac100] ->stuw_ [~stuw@87.255.14.112] 19:05 <*> Quits ->vanger [~Android@by1-office.wargaming.net] [Read error: Connection reset by peer] 20:15 <*> Joins[#ac100] ->vanger [~Android@93.125.41.28] 20:18 <*> Joins[#ac100] ->vanger_ [~Android@87.252.227.63] 20:19 <*> Quits ->vanger [~Android@93.125.41.28] [Ping timeout: 245 seconds] 20:20 <*> Quits ->woglinde [~henning@fb-n15-11.unbelievable-machine.net] [Ping timeout: 272 seconds] 21:29 <*> Joins[#ac100] ->lenios [~lenios@unaffiliated/lenios] 22:02 <*> Joins[#ac100] ->zombah_ [~zombah@194.165.0.6] 22:16 <*> Quits ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] [Quit: leaving] 22:18 <*> Quits ->stuw_ [~stuw@87.255.14.112] [Read error: Connection reset by peer] 22:25 <*> Quits ->brightkill [~brightkil@95.153.172.107] [Ping timeout: 245 seconds] 22:27 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.172.107] 22:35 <*> Quits ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] [Quit: "cheerio chaps"] 22:49 <*> Joins[#ac100] ->woglinde [~henning@f052066051.adsl.alicedsl.de] 23:12 <*> Quits ->brightkill [~brightkil@95.153.172.107] [Ping timeout: 256 seconds] 23:12 <*> Quits ->woshty [~irc@84.200.211.57] [Read error: Connection reset by peer] 23:13 <*> Joins[#ac100] ->woshty [~irc@84.200.211.57] 23:19 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.172.107] 23:23 <*> Joins[#ac100] ->marvin24 [~quassel@p20030053CC37C700685A35EC4A097773.dip0.t-ipconnect.de] --- Day changed Tue Oct 28 2014 00:12 <*> Quits ->brightkill [~brightkil@95.153.172.107] [Ping timeout: 250 seconds] 00:14 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.172.107] 00:59 <*> Quits ->zombah_ [~zombah@194.165.0.6] [Quit: Leaving] 01:19 <*> Quits ->marvin24 [~quassel@p20030053CC37C700685A35EC4A097773.dip0.t-ipconnect.de] [Remote host closed the connection] 01:21 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 02:15 <*> Quits ->sirderpalot [~pzzt@unaffiliated/sirderpalot] [Ping timeout: 240 seconds] 02:24 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 02:39 <*> Quits ->woglinde [~henning@f052066051.adsl.alicedsl.de] [Ping timeout: 256 seconds] 04:09 <*> Quits ->pranza [pranza@pranza.audiomastering.lt] [Quit: ðikt!] 04:14 <*> Joins[#ac100] ->sirderpalot [~pzzt@unaffiliated/sirderpalot] 04:16 <*> Joins[#ac100] ->pranza [pranza@pranza.audiomastering.lt] 04:21 <*> Joins[#ac100] ->zombah_ [~zombah@194.165.0.6] 07:33 <*> Joins[#ac100] ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] 07:57 <*> Quits ->sirderpalot [~pzzt@unaffiliated/sirderpalot] [Ping timeout: 256 seconds] 08:24 <*> Joins[#ac100] ->sirderpalot [~pzzt@unaffiliated/sirderpalot] 08:26 <*> Quits ->zombah_ [~zombah@194.165.0.6] [Quit: Leaving] 08:51 <*> Quits ->lenios [~lenios@unaffiliated/lenios] [Remote host closed the connection] 09:04 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 09:35 <*> Joins[#ac100] ->woglinde [~henning@fb-n15-11.unbelievable-machine.net] 09:55 <*> Joins[#ac100] ->lovecraftian [~cthulhu@77.228.175.74] 09:55 <*> Quits ->lovecraftian [~cthulhu@77.228.175.74] [Changing host] 09:55 <*> Joins[#ac100] ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] --- Log opened Thu Oct 30 07:32:03 2014 07:32 <*> Joins[#ac100] ->gildean_ [gildean@salaliitto.com] 07:32 <*> Topic for #ac100: French on #ac100-fr | Italian on #ac100-it | Russian on #ac100-ru | Wiki: http://ac100.grandou.net | Sources: http://gitorious.org/ac100/ | Developer team & mailing-list: https://launchpad.net/~ac100 | Check logs on http://ac100.tunk.org/logs 07:32 <*> Topic set by ggrandou [~quassel@clochette.grandou.net] [Mon Aug 15 20:06:17 2011] 07:32 [Users #ac100] 07:32 [ afaerber ] [ gildean ] [ janus ] [ nchauvet_web] [ puther ] [ topi` ] 07:32 [ antoszka ] [ gildean_] [ jbrown ] [ ogra_ ] [ scoopr ] [ vanger ] 07:32 [ arune ] [ gtom ] [ kenws ] [ p2-mate ] [ sirderpalot] [ warfare] 07:32 [ betaboon ] [ Hobbes` ] [ Lt_Tinkle] [ panda|z ] [ slackner ] [ woshty ] 07:32 [ brightkill] [ huuu3 ] [ marvin24 ] [ PaulFertser ] [ Snark ] [ XTaran ] 07:32 [ Chipaca ] [ indy ] [ mmind00 ] [ phh ] [ stuw ] [ zombah ] 07:32 [ DanSwano ] [ infinity] [ nashpa ] [ pranza ] [ taruti ] 07:32 <*> Irssi: #ac100: Total of 41 nicks [0 ops, 0 halfops, 0 voices, 41 normal] 07:32 <*> Channel #ac100 created Sat Sep 18 20:56:21 2010 07:33 <*> Irssi: Join to #ac100 was synced in 75 secs 09:39 <*> Joins[#ac100] ->woglinde [~henning@fb-n15-11.unbelievable-machine.net] 10:06 <*> Joins[#ac100] ->lovecraftian [~cthulhu@77.228.175.74] 10:06 <*> Quits ->lovecraftian [~cthulhu@77.228.175.74] [Changing host] 10:06 <*> Joins[#ac100] ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] 10:07 <*> Joins[#ac100] ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] 10:20 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 10:43 <*> Joins[#ac100] ->nchauvet_web_ [5bdf4991@gateway/web/freenode/ip.91.223.73.145] 10:49 <*> Quits ->nchauvet_web_ [5bdf4991@gateway/web/freenode/ip.91.223.73.145] [Quit: Page closed] 11:01 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-ikcmfikswsldiwdl] 12:31 <*> Joins[#ac100] ->vanger_ [~Android@93.125.19.211] 12:33 <*> Quits ->vanger [~Android@87.252.227.63] [Ping timeout: 245 seconds] 12:35 <*> Quits ->vanger_ [~Android@93.125.19.211] [Ping timeout: 260 seconds] 13:12 <*> Joins[#ac100] ->vanger [~Android@by1-office.wargaming.net] 13:14 <*> Joins[#ac100] ->vanger_ [~Android@178.172.239.240] 13:14 <*> Quits ->vanger [~Android@by1-office.wargaming.net] [Read error: Connection reset by peer] 13:25 <*> Quits ->afaerber [~andreasf_@p54941D4F.dip0.t-ipconnect.de] [Quit: Verlassend] 13:26 <*> Joins[#ac100] ->afaerber [~andreasf_@p54941D4F.dip0.t-ipconnect.de] 13:28 <*> Joins[#ac100] ->vanger [~Android@by1-office.wargaming.net] 13:28 <*> Quits ->vanger_ [~Android@178.172.239.240] [Read error: Connection reset by peer] 13:32 <*> Quits ->vanger [~Android@by1-office.wargaming.net] [Read error: Connection reset by peer] 13:33 <*> Joins[#ac100] ->vanger [~Android@by1-office.wargaming.net] 14:04 <*> Joins[#ac100] ->vanger_ [~Android@178.172.239.240] 14:05 <*> Quits ->vanger [~Android@by1-office.wargaming.net] [Ping timeout: 255 seconds] 14:05 <*> Quits ->vanger_ [~Android@178.172.239.240] [Read error: Connection reset by peer] 14:07 <*> Joins[#ac100] ->vanger [~Android@178.172.239.240] 14:17 <*> Quits ->afaerber [~andreasf_@p54941D4F.dip0.t-ipconnect.de] [Quit: Verlassend] 14:21 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 14:28 <*> Joins[#ac100] ->afaerber [andreasf_@nat/suse/x-ddzxgpmvvbzxuovk] 14:30 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 15:51 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 16:15 <*> Quits ->brightkill [~brightkil@95.153.188.107] [Ping timeout: 244 seconds] 17:02 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 17:07 <*> Quits ->stenzel [stenzel@nat/ibm/x-ikcmfikswsldiwdl] [Ping timeout: 250 seconds] 18:33 <*> Joins[#ac100] ->Nectar [uid44925@gateway/web/irccloud.com/x-dinufthvpjxveqhj] 18:36 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.188.107] 19:07 <*> Quits ->vanger [~Android@178.172.239.240] [Ping timeout: 244 seconds] 19:32 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 20:09 <*> Quits ->afaerber [andreasf_@nat/suse/x-ddzxgpmvvbzxuovk] [Quit: Verlassend] 20:12 <*> Joins[#ac100] ->vanger [~Android@87.252.227.63] 20:27 <*> Joins[#ac100] ->kwizart [~kwizart@fedora/kwizart] 20:30 <*> Joins[#ac100] ->lenios_ [~lenios@unaffiliated/lenios] 20:31 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 20:38 <*> Joins[#ac100] ->stuw_ [~stuw@87.255.14.112] 20:49 <*> Quits ->woglinde [~henning@fb-n15-11.unbelievable-machine.net] [Ping timeout: 255 seconds] 21:15 <*> Joins[#ac100] ->zombah_ [~zombah@194.165.0.6] 21:34 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 21:50 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 21:52 <*> Quits ->stuw_ [~stuw@87.255.14.112] [Read error: Connection reset by peer] 21:54 <*> Joins[#ac100] ->gomiboy [~frodone@ppp-21-97.21-151.libero.it] 22:15 <*> Quits ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] [Quit: leaving] 23:12 <*> Quits ->gomiboy [~frodone@ppp-21-97.21-151.libero.it] [Quit: Leaving.] 23:24 <*> Joins[#ac100] ->woglinde [~henning@e179136186.adsl.alicedsl.de] 23:24 <*> Quits ->woglinde [~henning@e179136186.adsl.alicedsl.de] [Client Quit] 23:24 <*> Joins[#ac100] ->woglinde [~henning@e179136186.adsl.alicedsl.de] 23:31 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 23:33 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] --- Day changed Fri Oct 31 2014 00:33 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 01:12 <*> Quits ->woglinde [~henning@e179136186.adsl.alicedsl.de] [Ping timeout: 258 seconds] 01:12 <*> Quits ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] [Quit: Lost terminal] 01:16 <*> Quits ->kwizart [~kwizart@fedora/kwizart] [Quit: Quitte] 01:18 <*> Joins[#ac100] ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] 01:19 <*> Joins[#ac100] ->afaerber [~andreasf_@p54941825.dip0.t-ipconnect.de] 02:07 <*> Quits ->lenios_ [~lenios@unaffiliated/lenios] [Remote host closed the connection] 02:32 <*> Quits ->sirderpalot [~pzzt@unaffiliated/sirderpalot] [Ping timeout: 265 seconds] 02:56 <*> Joins[#ac100] ->sirderpalot [~pzzt@unaffiliated/sirderpalot] 03:12 <*> Quits ->sirderpalot [~pzzt@unaffiliated/sirderpalot] [Ping timeout: 264 seconds] 03:27 <*> Joins[#ac100] ->sirderpalot [~pzzt@unaffiliated/sirderpalot] 05:04 <*> Quits ->sirderpalot [~pzzt@unaffiliated/sirderpalot] [Ping timeout: 256 seconds] 05:33 <*> Joins[#ac100] ->stuw_ [~stuw@87.255.14.112] 05:47 <*> Quits ->stuw_ [~stuw@87.255.14.112] [Read error: Connection reset by peer] 06:01 <*> Joins[#ac100] ->sirderpalot [~pzzt@unaffiliated/sirderpalot] 06:12 <*> Quits ->Nectar [uid44925@gateway/web/irccloud.com/x-dinufthvpjxveqhj] [Quit: Connection closed for inactivity] 07:36 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Ping timeout: 265 seconds] 07:39 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 09:07 <*> Joins[#ac100] ->Tequila [~guillaume@cab.pkg.fr] 09:08 <*> Joins[#ac100] ->Aryaman [Bruno1@I.Eated.The.Coooki.es] 09:09 <*> Parts[#ac100] ->Aryaman [Bruno1@I.Eated.The.Coooki.es] ["Leaving"] 09:35 <*> Quits ->zombah_ [~zombah@194.165.0.6] [Quit: Leaving] 09:36 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 10:23 <*> Quits ->mmind00 [~quassel@gloria.sntech.de] [Quit: No Ping reply in 180 seconds.] 10:24 <*> Joins[#ac100] ->mmind00 [~quassel@gloria.sntech.de] 11:17 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-xeiycjhqvcluesyw] 11:31 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 11:35 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 11:59 <*> Quits ->vanger [~Android@87.252.227.63] [Read error: No route to host] 12:03 <*> Joins[#ac100] ->vanger [~Android@87.252.227.63] 12:07 <*> Quits ->vanger [~Android@87.252.227.63] [Ping timeout: 240 seconds] 12:42 <*> Joins[#ac100] ->vanger [~Android@178.172.239.242] 12:45 <*> Quits ->vanger [~Android@178.172.239.242] [Read error: Connection reset by peer] 12:47 <*> Joins[#ac100] ->vanger [~Android@178.172.239.242] 12:50 <*> Joins[#ac100] ->vanger_ [~Android@by1-office.wargaming.net] 12:50 <*> Quits ->vanger [~Android@178.172.239.242] [Read error: Connection reset by peer] 13:48 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 14:32 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 14:43 <*> Joins[#ac100] ->mirco_ [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 14:43 <*> Quits ->DanSwano [~danswano@93.81.234.22] [Read error: Connection reset by peer] 14:46 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Ping timeout: 265 seconds] 14:46 <*> mirco_ is now known as mirco 14:54 <*> Quits ->brightkill [~brightkil@95.153.188.107] [Ping timeout: 244 seconds] 15:35 <*> Quits ->nchauvet_web [5bdf4991@gateway/web/freenode/ip.91.223.73.145] [Quit: Page closed] 15:58 <*> Quits ->afaerber [~andreasf_@p54941825.dip0.t-ipconnect.de] [Ping timeout: 245 seconds] 16:05 <*> Joins[#ac100] ->nchauvet_web [5bdf4991@gateway/web/freenode/ip.91.223.73.145] 16:17 <*> Joins[#ac100] ->afaerber [~andreasf_@p54940FDF.dip0.t-ipconnect.de] 16:52 <*> Quits ->stenzel [stenzel@nat/ibm/x-xeiycjhqvcluesyw] [Ping timeout: 264 seconds] 17:01 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.188.107] 17:17 <*> Quits ->sirderpalot [~pzzt@unaffiliated/sirderpalot] [Ping timeout: 250 seconds] 17:38 <*> Quits ->brightkill [~brightkil@95.153.188.107] [Ping timeout: 245 seconds] 18:33 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 18:37 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 18:53 <*> Joins[#ac100] ->Nectar [uid44925@gateway/web/irccloud.com/x-xqacfxbgsinarjwg] 18:53 <*> Quits ->nchauvet_web [5bdf4991@gateway/web/freenode/ip.91.223.73.145] [Ping timeout: 246 seconds] 19:04 <*> Quits ->vanger_ [~Android@by1-office.wargaming.net] [Read error: Connection reset by peer] 19:05 <*> Joins[#ac100] ->vanger [~Android@178.172.239.242] 20:07 <*> Joins[#ac100] ->kwizart [~kwizart@fedora/kwizart] 20:39 <*> Joins[#ac100] ->zombah_ [~zombah@194.165.0.6] 21:07 <*> Joins[#ac100] ->vanger_ [~Android@178.172.239.242] 21:07 <*> Quits ->vanger [~Android@178.172.239.242] [Read error: Connection reset by peer] 21:32 <*> Quits ->Nectar [uid44925@gateway/web/irccloud.com/x-xqacfxbgsinarjwg] [Quit: Connection closed for inactivity] 21:41 <*> Quits ->vanger_ [~Android@178.172.239.242] [Ping timeout: 240 seconds] 21:54 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 21:55 <*> Joins[#ac100] ->woglinde [~henning@p4FE4DD73.dip0.t-ipconnect.de] 21:58 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 22:10 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.188.107] 22:29 <*> Joins[#ac100] ->vanger [~Android@87.252.227.63] 23:05 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 23:25 <*> Quits ->vanger [~Android@87.252.227.63] [Ping timeout: 244 seconds] --- Day changed Sat Nov 01 2014 01:40 <*> Quits ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] [Quit: "cheerio chaps"] 01:50 <*> Quits ->kwizart [~kwizart@fedora/kwizart] [Quit: Quitte] 02:03 <*> Quits ->woglinde [~henning@p4FE4DD73.dip0.t-ipconnect.de] [Ping timeout: 258 seconds] 03:10 <*> Joins[#ac100] ->AC`97 [~pzzt@104-55-170-125.lightspeed.sntcca.sbcglobal.net] 03:45 <*> AC`97 is now known as sirderpalot 05:13 <*> Quits ->indy [~indy@shadow.kastnerove.cz] [Ping timeout: 256 seconds] 05:19 <*> Joins[#ac100] ->indy [~indy@shadow.kastnerove.cz] 05:25 <*> Quits ->sirderpalot [~pzzt@104-55-170-125.lightspeed.sntcca.sbcglobal.net] [Read error: Connection reset by peer] 05:42 <*> Joins[#ac100] ->sirderpalot [~pzzt@unaffiliated/sirderpalot] 08:36 <*> Quits ->sirderpalot [~pzzt@unaffiliated/sirderpalot] [Remote host closed the connection] 11:09 <*> Joins[#ac100] ->woglinde [~henning@p4FE4DD73.dip0.t-ipconnect.de] 11:12 <*> Joins[#ac100] ->kwizart [~kwizart@fedora/kwizart] 11:41 <*> Joins[#ac100] ->lovecraftian [~cthulhu@77.228.175.74] 11:41 <*> Quits ->lovecraftian [~cthulhu@77.228.175.74] [Changing host] 11:41 <*> Joins[#ac100] ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] 11:48 <*> Quits ->kwizart [~kwizart@fedora/kwizart] [Remote host closed the connection] 12:48 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 13:51 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 14:18 <*> Quits ->woglinde [~henning@p4FE4DD73.dip0.t-ipconnect.de] [Ping timeout: 256 seconds] 14:26 <*> Joins[#ac100] ->vanger [~Android@87.252.227.63] 14:42 <*> Quits ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] [Quit: "cheerio chaps"] 14:46 <*> Joins[#ac100] ->henkye [~henk@2a00:1028:96d1:bc82:6e62:6dff:fe16:a094] 15:09 <*> Quits ->henkye [~henk@2a00:1028:96d1:bc82:6e62:6dff:fe16:a094] [Quit: WeeChat 0.4.3] 16:18 <*> Joins[#ac100] ->afaerber_ [~andreasf_@p549411CE.dip0.t-ipconnect.de] 16:21 <*> Quits ->afaerber [~andreasf_@p54940FDF.dip0.t-ipconnect.de] [Ping timeout: 244 seconds] 16:46 <*> Joins[#ac100] ->woglinde [~henning@p4FE4DD73.dip0.t-ipconnect.de] 16:57 <*> Joins[#ac100] ->woglinde_ [~henning@p4FE4DD73.dip0.t-ipconnect.de] 17:00 <*> Quits ->woglinde [~henning@p4FE4DD73.dip0.t-ipconnect.de] [Ping timeout: 244 seconds] 17:12 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 17:20 <*> Joins[#ac100] ->woglinde [~henning@p4FE4D467.dip0.t-ipconnect.de] 17:23 <*> Quits ->woglinde_ [~henning@p4FE4DD73.dip0.t-ipconnect.de] [Ping timeout: 260 seconds] 18:17 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 18:18 <*> Quits ->woglinde [~henning@p4FE4D467.dip0.t-ipconnect.de] [Ping timeout: 264 seconds] 19:11 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 20:36 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 21:40 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 22:08 <*> Joins[#ac100] ->lautriv [~lautriv@f050082209.adsl.alicedsl.de] 22:57 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 23:25 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 23:32 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 23:35 <*> Joins[#ac100] ->woglinde [~henning@p4FE4D467.dip0.t-ipconnect.de] --- Day changed Sun Nov 02 2014 00:14 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 00:14 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 00:33 <*> Joins[#ac100] ->brightkill_ [~atomic@95.153.188.107] 00:50 <*> Quits ->brightkill_ [~atomic@95.153.188.107] [Ping timeout: 244 seconds] 02:32 <*> Quits ->zombah_ [~zombah@194.165.0.6] [Quit: Leaving] 02:35 <*> Quits ->woglinde [~henning@p4FE4D467.dip0.t-ipconnect.de] [Ping timeout: 244 seconds] 09:26 <*> Quits ->brightkill [~brightkil@95.153.188.107] [Ping timeout: 245 seconds] 09:26 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.188.107] 11:03 <*> Joins[#ac100] ->woglinde [~henning@p4FE4D467.dip0.t-ipconnect.de] 11:04 <*> Joins[#ac100] ->woglinde_ [~henning@p4FE4D467.dip0.t-ipconnect.de] 11:08 <*> Quits ->woglinde [~henning@p4FE4D467.dip0.t-ipconnect.de] [Ping timeout: 256 seconds] 11:09 <*> woglinde_ is now known as woglinde 13:06 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 13:15 <*> Quits ->jbrown [~jules@5751dfa3.skybroadband.com] [Quit: Client exiting] 13:42 <*> Joins[#ac100] ->jbrown [~jules@5751dfa3.skybroadband.com] 14:12 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 14:16 <*> Quits ->brightkill [~brightkil@95.153.188.107] [Ping timeout: 245 seconds] 14:18 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.195.150] 14:23 <*> Quits ->woglinde [~henning@p4FE4D467.dip0.t-ipconnect.de] [Ping timeout: 272 seconds] 16:18 <*> Joins[#ac100] ->afaerber__ [~andreasf_@p54942B4C.dip0.t-ipconnect.de] 16:21 <*> Quits ->afaerber_ [~andreasf_@p549411CE.dip0.t-ipconnect.de] [Ping timeout: 256 seconds] 16:35 <*> Quits ->brightkill [~brightkil@95.153.195.150] [Quit: "!@#^&*NO CARRIER] 16:35 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.195.150] 17:56 <*> Quits ->lautriv [~lautriv@f050082209.adsl.alicedsl.de] [Ping timeout: 244 seconds] 18:09 <*> Joins[#ac100] ->lautriv [~lautriv@f050082185.adsl.alicedsl.de] 18:11 <*> Quits ->brightkill [~brightkil@95.153.195.150] [Ping timeout: 240 seconds] 18:32 <*> Joins[#ac100] ->heiko_ [5847feca@gateway/web/freenode/ip.88.71.254.202] 18:35 < heiko_> hi, can someone confirm, that the kernel from https://launchpad.net/~marvin24/+archive/ubuntu/ppa does not support hdmi? 18:41 <*> Joins[#ac100] ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] 19:16 <*> Netsplit *.net <-> *.split quits: afaerber__ 19:20 <*> Joins[#ac100] ->afaerber__ [~andreasf_@p54942B4C.dip0.t-ipconnect.de] 19:43 <*> Joins[#ac100] ->zombah_ [~zombah@194.165.0.6] 19:51 <*> afaerber__ is now known as afaerber 20:09 <*> Joins[#ac100] ->lovecraftian [~cthulhu@77.228.175.74] 20:09 <*> Quits ->lovecraftian [~cthulhu@77.228.175.74] [Changing host] 20:09 <*> Joins[#ac100] ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] 20:15 <*> Quits ->lautriv [~lautriv@f050082185.adsl.alicedsl.de] [Ping timeout: 256 seconds] 20:52 <*> Quits ->lovecraftian [~cthulhu@unaffiliated/lovecraftian] [Quit: "cheerio chaps"] 21:05 <*> Joins[#ac100] ->brightkill [~brightkil@95.153.195.150] 21:35 <*> Quits ->heiko_ [5847feca@gateway/web/freenode/ip.88.71.254.202] [Ping timeout: 246 seconds] 21:54 <*> Joins[#ac100] ->kwizart [~kwizart@fedora/kwizart] 21:57 <*> Quits ->kwizart [~kwizart@fedora/kwizart] [Read error: Connection reset by peer] 22:10 <*> Quits ->vanger [~Android@87.252.227.63] [Read error: Connection reset by peer] 22:41 <*> Quits ->mirco [~mirco@ip-176-198-211-199.hsi05.unitymediagroup.de] [Quit: mirco] 22:43 <*> Joins[#ac100] ->kwizart [~kwizart@fedora/kwizart] 23:50 <*> Quits ->zombah_ [~zombah@194.165.0.6] [Quit: Leaving] --- Log closed Mon Nov 03 00:00:09 2014 --- Log opened Mon Oct 26 00:00:06 2015 10:33 <*> Joins[#ac100] ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] 11:21 <*> Joins[#ac100] ->zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] 11:27 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-qdjtsemfhgfyelll] 13:25 <*> Joins[#ac100] ->gordan [~gordan@213.1.211.27] 13:26 < gordan> Hi all. 13:27 < gordan> What is the AC100 support like in mainline kernels these days? 13:27 < gordan> Say, in the 3.18.x LT? 13:27 < gordan> Or 4.1.x LT? 13:27 < zombah> gordan: its fine 13:28 < gordan> Are special nvec patches still required to get things like the touchpad and keyboard working? 13:28 < zombah> gordan: no 13:28 < gordan> Awesome. WiFi also works with the driver that ships with mainline? 13:28 < zombah> gordan: yes 13:29 < gordan> Great. Does this work in 3.18.x or will I need 4.1.x? 13:29 < zombah> gordan: i usually post my test results here https://paz00.ru/index.php/Mainline/Upstream_kernel 13:31 < warfare> Oh, 4.2.1 is working? I need to pull my ac100 of the shelf and build some kernels. And probably do a software upgrade. 13:31 < zombah> yes im using 4.2.3 right now 13:36 < PaulFertser> Hi :) any news regarding suspend-to-ram on mainline kernel + uboot? 13:36 < gordan> zombah: Thanks for the link, having a read now. :) Pleased to meet you, BTW. I'm the one that was, back in the day, at least partially responsible for some of the more insane mods: https://www.altechnative.net/tag/ac100/ 13:36 < PaulFertser> Is it stable now? 13:37 < gordan> Wait - there's now uboot that works on the AC100? 13:37 < gordan> No more need to mess about with aboot? 13:37 < PaulFertser> gordan: I was using uboot for two years or so :) 13:37 < zombah> PaulFertser: hello, for me its status unknow, i cant suspend even on kernel which others say suspend works 13:38 < PaulFertser> zombah: ugh, sayd 13:38 < PaulFertser> gordan: http://ac100.grandou.net/debian_uboot that's how I was using it. 13:38 < zombah> gordan: mainline u-boot works fine, but with no nvec support 13:38 < gordan> PaulFertser, shows how long I've not been using my AC100. :( But I need to get it up and running and updated again, need a small protable machien with tons of battery life. 13:38 < PaulFertser> zombah: and I assume still no hw scaling/colourspace conversion for video? 13:39 < PaulFertser> gordan: without suspend-to-ram the battery life is not that impressive :( 13:39 < zombah> PaulFertser: yes, only basic 2d with modesettings driver 13:39 < PaulFertser> zombah: so nothing really changed, just more stuff upstreamed from temporary git trees, right? 13:39 < gordan> Hang on, that page says keyboard and screen don't work in uboot. What exactly is the point of uboot, then? 13:40 < gordan> Might as well use aboot, at least that gives the backup kernel boot option. 13:40 < zombah> PaulFertser: yes not much activity couple past years 13:40 < warfare> gordan: The u-boot with nvec patches has working screen and keyboard. 13:41 < PaulFertser> gordan: I use uboot to boot, why might I need keyboard or screen for that? 13:41 < zombah> screen works fine for a long time in upstream u-boot 13:41 < PaulFertser> Yes, I haven't updated that page since long. 13:42 < gordan> warfare - where do I find the patched uboot or the nvec patch? 13:44 < zombah> gordan: https://github.com/ac100-ru/u-boot-ac100-exp/commits/tegra-master-exp 13:44 < zombah> gordan: or you want binary& 13:44 < gordan> zombah: Source + build instructions is more than fine. :) 13:45 < zombah> gordan: build with make paz00_defconfig then make 13:45 < gordan> Oh, wait, this is the denx uboot? Awesome, that's what I use on my *Plugs 13:46 < gordan> I take it the default branch of that repository is the one to use? 13:47 < gordan> Looking through the branches some are like 8 thousand commits further ahead. 13:47 < gordan> And master is 20 thousand commits behind. 13:47 < gordan> It seems... extreme... 13:47 < zombah> gordan: depends what you want 13:48 < zombah> gordan: there is newer branches but they have more various problems 13:48 < gordan> I just want working uboot with keyboard and display support so that if I botch a kernel upgrade I can just boot the old kernel. :) 13:48 < warfare> I got my u-boot from http://ac100.grandou.net/sosbootr5 13:48 < gordan> So default branch (tegra-master-exp) is the one that "just works"? 13:48 < zombah> gordan: yes 13:49 < zombah> gordan: it is source of sosbootr5 binary imho 13:49 < gordan> Splendid. Thanks. 13:57 < PaulFertser> gordan: haha, in case of a botched upgrade I have two wires sticking out, I'll solder usb serial to them when needed ;) 13:58 < gordan> Well, I'm far from averse to the idea of soldering wires, but I prefer to be abel to recover in seconds rather than hours. 13:58 < gordan> Practicality rates very highly on my list of priorities. :) 13:59 < PaulFertser> Since new kernels do not add any new functionality I just do not upgrade :( 14:00 < PaulFertser> I hoped ac100 would become a fully functional device but alas. 14:00 < PaulFertser> Of course, it's still very nice to have, I even used it for work for some time because I prefer lighter equipment when riding a bicycle. 14:01 < zombah> it is very easy to recovery with sosboot even if you flash something wrong 14:02 < zombah> wo any additional wires 14:03 < PaulFertser> Early in the process I decided to get read of all android stuff on it, so I just flashed uboot and use LVM on all the other flash space. So no sosboot for me. 14:04 < warfare> PaulFertser: You could still sosboot through recovery mode. 14:04 < zombah> PaulFertser: sosboot runs in memory, loaded from PC with tegraucm tool 14:04 < zombah> tegrarcm i mean 14:05 < PaulFertser> zombah: I see. I used to run uboot the same way. 14:05 < zombah> PaulFertser: yes its easy to test newer u-boot/kernels this way 14:06 < PaulFertser> zombah: indeed 14:06 < gordan> I do like to keep up to date with kernels, just to avoid risk of privilege escalation bugs that some malware merchant might stack with things like remote code execution exploits in, say, a web browser (like the recent Firefox pdf.js remote code execution bug). 14:06 < PaulFertser> I never wanted though as no features I needed were added... I could probably have implemented suspend myself but I didn't have enough motivation to hack that deep. 14:08 < gordan> I notice on the SOSBOOT r5 page it says that it doesn't fit onto partition 5. What are the implications of that WRT nvflash-ing it on? 14:08 < gordan> Does this require re-partitioning the AC100? 14:08 < zombah> gordan: no need to flash it, run it from PC with mini-usb cable and tegrarcm tool 14:09 < gordan> So that is just the installer, that then goes and installs uboot in place of aboot? 14:09 < zombah> gordan: it can or you can install u-boot yourself with dd 14:10 < zombah> but manual methon require additional steps 14:10 < gordan> Right, OK. I'll run the script and see how I get on. And read the script if needed. Thanks for your help guys. :) 14:11 < zombah> gordan: i have notes how to flash manually if you need https://paz00.ru/index.php/Flashing_Uboot_to_MMC 14:12 < gordan> Ooo, veryhandy. Thank you. :) 14:13 < gordan> Seems my entertainment for next week is sorted. 14:13 < gordan> Might even get around to porting my OC-ing patches to newer kernels. :) 14:13 < gordan> Unless somebody has done it already. 14:14 < zombah> gordan: mainline kernel lack frequency scaling for memory imho 14:14 < gordan> My OC-ing patches didn't re-clock memory, either. 14:14 < gordan> But bumping the Tegra2 from 1000 to 1400MHz is definitely a feelable difference. 14:16 < gordan> From memory, 1200MHz is safe without doing anything special to the machine, 1400MHz does require the copper shim mod for prolonged bursts of speed (or running a temperature monitoring throttling daemon) 14:16 < zombah> yes, i tried various oc patches in the past but didnt found any bonuses myself 14:17 < zombah> but that probably depends on use case 8) 14:22 < gordan> My AC100s were used as a compile farm. 14:22 < gordan> When I was building RedSleeve EL6. 14:22 < gordan> Bumping the CPU speed by 40% directly translated into a similar compile speed boost. 14:23 < gordan> Tegra2 has tons of CPU cache so memory speed is less determining to the performance of that kind of a load. 15:46 <*> Quits ->pranza [pranza@pranza.audiomastering.lt] [Read error: Connection reset by peer] 18:54 <*> Quits ->stenzel [stenzel@nat/ibm/x-qdjtsemfhgfyelll] [Ping timeout: 240 seconds] 18:57 <*> Quits ->zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] [Quit: Leaving] 19:19 <*> Quits ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] [Quit: leaving] 19:47 <*> Quits ->gordan [~gordan@213.1.211.27] [Quit: Konversation terminated!] 21:25 <*> Joins[#ac100] ->Nemo__ [5a11615e@gateway/web/freenode/ip.90.17.97.94] 21:25 <*> Quits ->Nemo__ [5a11615e@gateway/web/freenode/ip.90.17.97.94] [Client Quit] --- Day changed Tue Oct 27 2015 10:15 <*> Joins[#ac100] ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] 10:51 <*> Quits ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] [Quit: leaving] 10:52 <*> Joins[#ac100] ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] 10:57 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-vgfuqhfrzonclvay] 12:43 <*> Quits ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] [Ping timeout: 240 seconds] 12:43 <*> Joins[#ac100] ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] 17:14 <*> Quits ->stenzel [stenzel@nat/ibm/x-vgfuqhfrzonclvay] [Ping timeout: 240 seconds] 19:13 <*> Quits ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] [Remote host closed the connection] 19:56 <*> Joins[#ac100] ->stuw2 [~AndChat33@41.33.149.146] 20:35 <*> Quits ->stuw2 [~AndChat33@41.33.149.146] [Read error: Connection reset by peer] 20:35 <*> Joins[#ac100] ->stuw3 [~AndChat33@41.33.149.146] 20:52 <*> Quits ->stuw3 [~AndChat33@41.33.149.146] [Ping timeout: 265 seconds] 21:13 <*> Quits ->nashpa [~nashpa@dliviu.plus.com] [Quit: Going away] 21:14 <*> Joins[#ac100] ->nashpa [~nashpa@dliviu.plus.com] 21:16 <*> Quits ->nashpa [~nashpa@dliviu.plus.com] [Client Quit] 21:41 <*> Joins[#ac100] ->nashpa [~nashpa@dliviu.plus.com] 21:48 <*> Joins[#ac100] ->stuw2 [~AndChat33@41.33.149.146] 22:11 <*> Quits ->stuw2 [~AndChat33@41.33.149.146] [Ping timeout: 265 seconds] 22:39 <*> Quits ->nashpa [~nashpa@dliviu.plus.com] [Quit: Going away] 22:40 <*> Joins[#ac100] ->nashpa [~nashpa@dliviu.plus.com] 22:52 <*> Quits ->nashpa [~nashpa@dliviu.plus.com] [Quit: Going away] 22:53 <*> Joins[#ac100] ->nashpa [~nashpa@dliviu.plus.com] --- Day changed Wed Oct 28 2015 10:19 <*> Joins[#ac100] ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] 11:04 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-xncxgbkmbaiuzmru] 11:23 <*> Quits ->indy [~indy@shadow.kastnerove.cz] [Ping timeout: 250 seconds] 11:33 <*> Joins[#ac100] ->zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] 12:00 <*> Joins[#ac100] ->indy [~indy@shadow.kastnerove.cz] 12:31 <*> Quits ->nashpa [~nashpa@dliviu.plus.com] [Ping timeout: 250 seconds] 14:43 <*> Joins[#ac100] ->nashpa [~nashpa@dliviu.plus.com] 16:56 <*> Quits ->betaboon [~betaboon@ip5f5b05dd.dynamic.kabel-deutschland.de] [Ping timeout: 255 seconds] 18:26 <*> Joins[#ac100] ->betaboon [~betaboon@ip5f5b05dd.dynamic.kabel-deutschland.de] 18:50 <*> Quits ->stenzel [stenzel@nat/ibm/x-xncxgbkmbaiuzmru] [Ping timeout: 240 seconds] 19:35 <*> Quits ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] [Quit: leaving] 19:38 <*> Quits ->zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] [Quit: Leaving] 22:44 <*> Joins[#ac100] ->pranza [pranza@pranza.audiomastering.lt] 22:44 <*> Quits ->pranza [pranza@pranza.audiomastering.lt] [Client Quit] --- Day changed Thu Oct 29 2015 09:06 <*> Quits ->nchauvet [z6bohsa5dn@92.103.166.6] [Remote host closed the connection] 09:36 <*> Joins[#ac100] ->nchauvet [0jbgahr4ia@92.103.166.6] 10:45 <*> Joins[#ac100] ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] 11:12 <*> Joins[#ac100] ->woglinde [~henning@fb-n15-11.unbelievable-machine.net] 11:16 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-ujkfrcpyskvxxuup] 12:01 <*> Joins[#ac100] ->gordan [~gordan@31.99.41.188] 12:19 <*> Joins[#ac100] ->zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] 12:48 <*> Quits ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] [Ping timeout: 252 seconds] 12:50 <*> Joins[#ac100] ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] 13:51 <*> Joins[#ac100] ->gordan_ [~gordan@31.99.41.188] 13:52 <*> Quits ->gordan [~gordan@31.99.41.188] [Read error: Connection reset by peer] 13:53 <*> gordan_ is now known as gordan 15:27 <*> Joins[#ac100] ->gordan_ [~gordan@31.99.41.188] 15:28 <*> Parts[#ac100] ->gordan_ [~gordan@31.99.41.188] [] 15:35 <*> Joins[#ac100] ->gordan_ [~gordan@213.1.211.27] 15:35 <*> Parts[#ac100] ->gordan_ [~gordan@213.1.211.27] [] 15:38 <*> Quits ->gordan [~gordan@31.99.41.188] [Ping timeout: 272 seconds] 16:01 <*> Quits ->zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] [Quit: Leaving] 16:19 <*> Joins[#ac100] ->marvin24_ [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 16:22 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Ping timeout: 246 seconds] 17:32 <*> Joins[#ac100] ->gordan [~gordan@213.1.211.27] 17:36 <*> Parts[#ac100] ->gordan [~gordan@213.1.211.27] [] 18:57 <*> Quits ->stenzel [stenzel@nat/ibm/x-ujkfrcpyskvxxuup] [Ping timeout: 260 seconds] 19:22 <*> Quits ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] [Quit: leaving] 19:28 <*> Quits ->woglinde [~henning@fb-n15-11.unbelievable-machine.net] [Ping timeout: 252 seconds] 20:13 <*> Joins[#ac100] ->gordan [~gordan@cpc70801-aztw27-2-0-cust515.18-1.cable.virginm.net] 20:13 <*> Parts[#ac100] ->gordan [~gordan@cpc70801-aztw27-2-0-cust515.18-1.cable.virginm.net] [] 22:35 <*> Joins[#ac100] ->woglinde [~henning@f052200196.adsl.alicedsl.de] --- Day changed Fri Oct 30 2015 02:39 <*> Quits ->woglinde [~henning@f052200196.adsl.alicedsl.de] [Ping timeout: 272 seconds] 04:49 <*> Quits ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] [Ping timeout: 265 seconds] 04:49 <*> Joins[#ac100] ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] 05:06 <*> Quits ->GekkePrutser [sid50410@gateway/web/irccloud.com/x-cupgncavhqiltwhd] [Read error: Connection reset by peer] 05:11 <*> Joins[#ac100] ->GekkePrutser [sid50410@gateway/web/irccloud.com/x-rarsymfffdfycqil] 10:47 <*> Joins[#ac100] ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] 10:54 <*> Joins[#ac100] ->woglinde [~henning@fb-n15-11.unbelievable-machine.net] 11:26 <*> Joins[#ac100] ->gordan [~gordan@213.1.211.27] 11:26 <*> Parts[#ac100] ->gordan [~gordan@213.1.211.27] [] 11:28 <*> Joins[#ac100] ->zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] 11:52 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-diwzkykchhueiobi] 12:38 <*> Quits ->zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] [Quit: Leaving] 12:38 <*> Joins[#ac100] ->zombah [~zombah@2a02:28:3:1:214:4fff:fe47:5920] 12:51 <*> Quits ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] [Ping timeout: 240 seconds] 12:52 <*> Joins[#ac100] ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] 16:19 <*> Quits ->stenzel [stenzel@nat/ibm/x-diwzkykchhueiobi] [Remote host closed the connection] 16:21 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-kzatvcmxvsyekftb] 16:22 <*> Quits ->stenzel [stenzel@nat/ibm/x-kzatvcmxvsyekftb] [Remote host closed the connection] 16:24 <*> Quits ->marvin24_ [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Ping timeout: 240 seconds] 16:26 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 16:28 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-ohaolkbtcjlyneen] 16:29 <*> Quits ->stenzel [stenzel@nat/ibm/x-ohaolkbtcjlyneen] [Remote host closed the connection] 16:59 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-jjlgfjwuvjpvdeto] 17:03 <*> Quits ->stenzel [stenzel@nat/ibm/x-jjlgfjwuvjpvdeto] [Remote host closed the connection] 17:08 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-booqoybwmfdgaygg] 17:09 <*> Quits ->stenzel [stenzel@nat/ibm/x-booqoybwmfdgaygg] [Remote host closed the connection] 17:10 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-okgnbxnpgxyewiym] 17:24 <*> Quits ->stenzel [stenzel@nat/ibm/x-okgnbxnpgxyewiym] [Remote host closed the connection] 17:25 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-yhpvcxwknfheazuq] 17:31 <*> Quits ->stenzel [stenzel@nat/ibm/x-yhpvcxwknfheazuq] [Remote host closed the connection] 18:14 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-gjfuobedsexxeenr] 18:35 <*> Quits ->woglinde [~henning@fb-n15-11.unbelievable-machine.net] [Ping timeout: 260 seconds] 18:38 <*> Quits ->stenzel [stenzel@nat/ibm/x-gjfuobedsexxeenr] [Ping timeout: 244 seconds] 18:54 <*> Quits ->ppisati [~ppisati@2-230-238-136.ip204.fastwebnet.it] [Quit: leaving] --- Day changed Sat Oct 31 2015 00:23 <*> Joins[#ac100] ->woglinde [~henning@x55b344e1.dyn.telefonica.de] 05:26 <*> Quits ->woglinde [~henning@x55b344e1.dyn.telefonica.de] [Ping timeout: 252 seconds] 18:17 <*> Joins[#ac100] ->woglinde [~henning@f052237254.adsl.alicedsl.de] 19:04 <*> Quits ->woglinde [~henning@f052237254.adsl.alicedsl.de] [Ping timeout: 265 seconds] --- Day changed Sun Nov 01 2015 04:25 <*> Joins[#ac100] ->stuw_ [~stuw_@87.255.2.172] 05:39 <*> Quits ->stuw_ [~stuw_@87.255.2.172] [Ping timeout: 240 seconds] 08:07 <*> Quits ->infinity [adconrad@loki.0c3.net] [Ping timeout: 255 seconds] 08:07 <*> Joins[#ac100] ->infinity [adconrad@loki.0c3.net] 09:11 <*> Quits ->infinity [adconrad@loki.0c3.net] [Ping timeout: 240 seconds] 09:12 <*> Joins[#ac100] ->infinity [adconrad@loki.0c3.net] 09:25 <*> Quits ->infinity [adconrad@loki.0c3.net] [Ping timeout: 250 seconds] 09:31 <*> Joins[#ac100] ->infinity [adconrad@loki.0c3.net] 09:39 <*> Quits ->infinity [adconrad@loki.0c3.net] [Ping timeout: 265 seconds] 09:40 <*> Joins[#ac100] ->infinity [adconrad@loki.0c3.net] 09:51 <*> Quits ->infinity [adconrad@loki.0c3.net] [Ping timeout: 260 seconds] 09:52 <*> Joins[#ac100] ->infinity [adconrad@loki.0c3.net] 10:08 <*> Joins[#ac100] ->stuw_ [~stuw_@87.255.2.172] 11:12 <*> Quits ->infinity [adconrad@loki.0c3.net] [Ping timeout: 250 seconds] 11:12 <*> Joins[#ac100] ->infinity [adconrad@loki.0c3.net] 12:55 <*> Quits ->infinity [adconrad@loki.0c3.net] [Ping timeout: 264 seconds] 13:01 <*> Joins[#ac100] ->infinity [adconrad@loki.0c3.net] 14:04 <*> Quits ->stuw_ [~stuw_@87.255.2.172] [Ping timeout: 255 seconds] 14:32 <*> Quits ->infinity [adconrad@loki.0c3.net] [Ping timeout: 265 seconds] 14:33 <*> Joins[#ac100] ->infinity [~adconrad@loki.0c3.net] 14:37 <*> Quits ->infinity [~adconrad@loki.0c3.net] [Ping timeout: 240 seconds] 14:38 <*> Joins[#ac100] ->infinity [adconrad@loki.0c3.net] 17:23 <*> Joins[#ac100] ->stuw_ [~stuw_@87.255.2.172] 21:44 <*> Quits ->nashpa [~nashpa@dliviu.plus.com] [Ping timeout: 240 seconds] 21:52 <*> Joins[#ac100] ->nashpa [~nashpa@dliviu.plus.com] 22:17 <*> Quits ->stuw_ [~stuw_@87.255.2.172] [Ping timeout: 272 seconds] 23:08 <*> Quits ->infinity [adconrad@loki.0c3.net] [Ping timeout: 240 seconds] 23:09 <*> Joins[#ac100] ->infinity [adconrad@loki.0c3.net] --- Log closed Mon Nov 02 00:00:15 2015 --- Log opened Mon Oct 24 00:00:46 2016 00:02 < PaulFertser> marvin24: so that's the real reason X.org wasn't able to use synaptics driver. 00:08 <*> Joins[#ac100] ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 01:31 <*> Quits ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 256 seconds] 01:34 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:456c:d35d:798f:ca09] 01:38 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:456c:d35d:798f:ca09] [Ping timeout: 260 seconds] 03:41 <*> Joins[#ac100] ->GeneralIdler [~calvin@2001:4b98:dc0:47:216:3eff:fe18:5d33] 03:41 <*> Joins[#ac100] ->PaulFertser_ [paul@2001:470:26:54b:260:98ff:feef:cb79] 03:42 <*> Quits ->Hobbes` [~calvin@2001:4b98:dc0:47:216:3eff:fe18:5d33] [Write error: Broken pipe] 03:42 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:b8e8:64f2:4ca8:518f] 03:42 <*> Quits ->PaulFertser [paul@2001:470:26:54b:260:98ff:feef:cb79] [Remote host closed the connection] 03:47 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:b8e8:64f2:4ca8:518f] [Ping timeout: 250 seconds] 04:02 <*> Joins[#ac100] ->topi`_ [~topi@kaverit.org] 04:04 <*> Quits ->topi` [topi@kaverit.org] [Ping timeout: 265 seconds] 04:31 <*> Quits ->warfare [~falk@kilbeggan.fourecks.de] [Ping timeout: 268 seconds] 04:31 <*> Joins[#ac100] ->warfare [~falk@kilbeggan.fourecks.de] 04:31 <*> Quits ->pranza [pranza@pranza.audiomastering.lt] [Ping timeout: 268 seconds] 06:22 <*> Joins[#ac100] ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 07:56 <*> Quits ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 250 seconds] 09:34 <*> PaulFertser_ is now known as PaulFertser 09:47 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 09:51 <*> Quits ->stuw [~stuw@31.44.80.66] [Ping timeout: 260 seconds] 10:00 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 10:23 < PaulFertser> Hm, regarding stability, so far so good. 10:32 <*> Joins[#ac100] ->jiuce19 [~tz2625@itepkrysun.itep.kit.edu] 10:44 < marvin24> PaulFertser: that's a pretty old commit 10:45 < PaulFertser> marvin24: I'll send a revert now and will CC you, ok? 10:45 < PaulFertser> Along with an appropriate commit message of course. 10:45 < marvin24> I'm not sure if this is the real reason 10:45 < marvin24> are you on mainline? 10:45 < PaulFertser> marvin24: I can explain 10:45 < PaulFertser> marvin24: yes 10:46 < PaulFertser> marvin24: you mark the port as pass-through capable and so probing of all advanced PS/2 protocols is skipped by generic psmouse code. 10:46 < PaulFertser> So the touchpad is detected as regular ImPS/2 mouse and not as a touchpad. 10:47 < PaulFertser> If I either force the protocol to "elantech" (via sysfs node) or modify the kernel accordingly, the X.org driver start seeing it as a proper touchpad and so all synaptics configuration (zones, acceleration etc) becomes available. 10:47 < marvin24> why does passthrough skip something? 10:48 < marvin24> I'm pretty sure I had it going before 10:48 < PaulFertser> But are you sure you had it working as a touchpad and not mouse? 10:48 < marvin24> I like to check this first 10:48 < marvin24> can you give me a few days to try myself? 10:48 < PaulFertser> The obvious symptom for me was that the cursor is slow compared to previous behaviour. 10:48 < marvin24> that commit is from 2011... 10:48 < PaulFertser> And that X.org driver treated it as a mouse and not as touchpad. 10:50 < PaulFertser> marvin24: sure thing, so you want me to not send revert just now? Ok, I'll wait then. 10:50 < PaulFertser> What I can say for sure is that on your kernel it was detected as Elantech and was working properly. On mainline the elantech detection is skipped. 10:51 < marvin24> Yes, please wait 10:51 < PaulFertser> Also, I see absolutely no reason to mark it as pass-through, see https://lkml.org/lkml/2003/7/6/7 for the initial motivation that lead to introduction of this option. 10:51 < marvin24> I'll try to check this evening 10:51 < PaulFertser> Sure, np. 10:51 < PaulFertser> It's probably nobody complained because nobody tried to use synaptics tools. 10:51 < PaulFertser> It sort of works with ImPS/2. 10:51 < marvin24> AFAIR, the ec just sends the ps/2 commands to the toucchpad (passthrough) 10:51 < marvin24> that was the motivation 10:52 < PaulFertser> Yes, it does. 10:52 < marvin24> only one command (I think some kind of reset) is skipped by the ec 10:53 < PaulFertser> But ps/2 pass through mode means that this ps/2 device has some other device connected to it. In case of some synaptics touchpad it's really the case as there's also a stick present and working as a slave ps/2 device. 10:53 < PaulFertser> EC is not a PS/2 device, it's just a transport. 10:58 < PaulFertser> marvin24: please also see http://blog.amigas.ru/wp-content/uploads/2014/03/touchpad_RevB.pdf page 52 11:04 < marvin24> looks reasonable 11:08 < PaulFertser> Other than this issue and nvec_event absence, it seems to be working just fine. 11:08 < PaulFertser> marvin24: many thanks for that! 11:09 < marvin24> PaulFertser: yes, I just stopped adding features (and cleanups) because the device-tree presentation wasn't finished 11:09 < marvin24> I'm not sure how to proceed further 11:10 < marvin24> nvec can't live forever in staging and we seem to have to way to get i2c slave support working in an upstream acceptable way 11:12 < PaulFertser> Why can't it live forever in staging? ;) 11:12 < marvin24> stuw made great process on adding the slave support to the tegra i2c driver 11:13 < marvin24> it is really unfortune, that all the work was done for nothing 11:13 < marvin24> and without nvec, no ac100 support in the kernel :-( 11:13 < stuw> marvin24: it's not great yet because patches are not accepted :) 11:14 < marvin24> still, you put a lot of work into it 11:15 < PaulFertser> tbh, I do not feel motivated to really get involved as I do not see the features I need myself being worked on my anybody. And I just need 2d colourspace conversion and hw scaling acceleration. Of course, hw media decoding would be awesome too. If it was coming, I'd be motivated to get suspend/resume working, probably forward-port and make acceptable UDC, etc. 11:15 < marvin24> that's already great! 11:15 < marvin24> PaulFertser: maybe you could ask NVIDIA to open more documentation for this old engine 11:16 < marvin24> now that they moved to desktop gpu's, there may be some chance 11:16 < PaulFertser> marvin24: but who would work with that? I have no experience working with graphics at all, it's not a weekend job for me to implement even basic features even when the docs are there. 11:17 < PaulFertser> Basic 2d acceleration is possible with docs that were already released. 11:17 < marvin24> that should not hinder them to release the docs 11:18 < marvin24> PaulFertser: I missed that somehow 11:18 < marvin24> maybe in the tegra trm 11:22 < PaulFertser> 11:32 < indy> PaulFertser, tegra2 trm pages 1124-1196 (host1x), 1197-1428 (gr2d) and 1429-1449 (epp), not much documented vi (video input - camera, etc), gr3d, mpe (mpeg video encoder), isp (image signa 11:22 < PaulFertser> l processor), tvo (tv output), vde (video decode engine) 11:22 < indy> PaulFertser, yes 11:22 < PaulFertser> indy: I was just passing to marvin24 the info you got me. 11:23 < PaulFertser> indy: btw, do you have your ac100 handy? Can you check how the touchpad works on it? 11:23 < PaulFertser> Specifically, "lsinput" section and Xorg.0.log contents. 11:24 < PaulFertser> And probably if synaptics configuration works, "synclient -l" 11:24 < PaulFertser> indy: not that it's too important, just if it's really handy. 11:25 < indy> PaulFertser, i'm on business trip for next three weeks and i took only flyswatter2 and few armv8 boards :) 11:25 < PaulFertser> indy: wise choice :) 11:26 < indy> and ez-usb fx3 + icestick 12:00 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 12:01 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 12:06 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 12:07 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 12:50 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 13:37 < PaulFertser> haha, it works so nicely that I'm afraid to run apt-get distupgrade :) 14:31 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 245 seconds] 15:39 <*> Joins[#ac100] ->kwizart_ [~kwizart@srv02.kwizart.net] 15:44 <*> Netsplit *.net <-> *.split quits: DanSwano, kwizart, warfare 15:50 <*> Joins[#ac100] ->warfare [~falk@kilbeggan.fourecks.de] 15:51 <*> Joins[#ac100] ->DanSwano [~danswano@109.234.34.139] 15:51 <*> kwizart_ is now known as kwizart 15:52 <*> Quits ->kwizart [~kwizart@srv02.kwizart.net] [Changing host] 15:52 <*> Joins[#ac100] ->kwizart [~kwizart@fedora/kwizart] 17:01 < PaulFertser> I'm so glad I was documenting all my ac100 findings on the wiki, it's of such a great help to me :) 17:01 < PaulFertser> E.g. every now and then I need to reconfigure alsa mixer and I find this: "Setting “SpeakerOut N Mux” to “RP/+R” and “SpeakerOut Mux” to “HPOut Mix” seems to be the only correct way to drive the integrated speakers. " yay 17:07 < PaulFertser> I wonder where angeli is now, I wanted to help him so he could enjoy ac100 as much as I do now, heh. 17:41 <*> Quits ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] [Read error: Connection reset by peer] 17:41 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] 19:17 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 19:20 <*> Quits ->panda| [~panda|z@li914-99.members.linode.com] [Quit: ZNC - http://znc.in] 19:29 < marvin24> PaulFertser: http://paste.debian.net/889348/ 19:29 < marvin24> with ubuntu standard kernel 19:31 <*> Joins[#ac100] ->panda|z [~panda|z@li914-99.members.linode.com] 19:36 < PaulFertser> marvin24: can you please also show dmesg? 19:38 < marvin24> PaulFertser: http://paste.debian.net/889349/ 19:44 < PaulFertser> marvin24: please see v4.3-7-gec6184b , (this commit is not present in v4.4, apparently was merged later) 19:47 < PaulFertser> v4.6-rc1~9^2~54^2~1 19:48 < marvin24> PaulFertser: ok, give me some time to compile a current kernel myself (or maybe I just install a new ubuntu one) 19:48 < marvin24> you can post a patch if you like, I'll comment later on it 19:48 < PaulFertser> marvin24: np, I'll wait :) 19:49 < marvin24> please add the commit above which broke it to the patch description 19:49 < PaulFertser> Of course 19:50 < PaulFertser> Well, conceptually it was broken before that too as it's misusing the pass through flag but it surfaced thanks to that specific commit indeed. 19:55 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 21:05 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 260 seconds] 21:06 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 21:09 <*> Quits ->damex [~damex@funtoo/dev/damex] [Max SendQ exceeded] 21:10 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 21:11 <*> Joins[#ac100] ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 21:17 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 276 seconds] 21:19 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 21:37 <*> Quits ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] [Read error: Connection reset by peer] 21:38 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] 21:38 <*> Quits ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] [Changing host] 21:38 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] 21:38 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 276 seconds] 22:12 <*> Joins[#ac100] ->digetx [digetx@gateway/shell/panicbnc/x-gfgocevgtwhymvxe] 22:46 <*> Quits ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] [Ping timeout: 252 seconds] 23:18 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] 23:18 <*> Quits ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] [Changing host] 23:18 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] 23:48 <*> Quits ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 250 seconds] --- Day changed Tue Oct 25 2016 00:16 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Quit: Quitte] 00:55 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 01:13 <*> Quits ->damex [~damex@funtoo/dev/damex] [Remote host closed the connection] 02:09 <*> Joins[#ac100] ->tz2625_ [~tz2625@itepkrysun.itep.kit.edu] 02:12 <*> Quits ->jiuce19 [~tz2625@itepkrysun.itep.kit.edu] [Ping timeout: 245 seconds] 02:17 <*> Quits ->janus [Janus@bnc.animux.de] [Ping timeout: 245 seconds] 02:22 <*> Joins[#ac100] ->janus [Janus@bnc.animux.de] 02:42 <*> Netsplit *.net <-> *.split quits: arune, topi`_ 02:43 <*> Netsplit over, joins: topi`_, arune 02:43 <*> Quits ->p2-mate [~p2@emantra.psychaos.be] [Ping timeout: 256 seconds] 02:43 <*> Joins[#ac100] ->p2-mate [~p2@emantra.psychaos.be] 03:27 <*> Joins[#ac100] ->p2-mate_ [~p2@emantra.psychaos.be] 03:28 <*> Quits ->p2-mate [~p2@emantra.psychaos.be] [Ping timeout: 256 seconds] 07:26 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 07:27 <*> Joins[#ac100] ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 07:56 <*> You're now known as gildean 07:59 <*> Quits ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 245 seconds] 09:41 <*> Quits ->DanSwano [~danswano@109.234.34.139] [Ping timeout: 265 seconds] 09:42 <*> Joins[#ac100] ->Dan_Swano [~danswano@109.234.34.139] 10:27 <*> Dan_Swano is now known as DanSwano 11:54 <*> Quits ->stuw [~stuw@31.44.80.66] [] 12:31 <*> Quits ->damex [~damex@funtoo/dev/damex] [Remote host closed the connection] 12:36 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 12:43 <*> Quits ->damex [~damex@funtoo/dev/damex] [Remote host closed the connection] 12:52 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 13:54 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 244 seconds] 14:12 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 14:20 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 276 seconds] 14:32 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 14:54 < marvin24> PaulFertser: ok, I was able to reproduce the touchpad problem 14:54 < marvin24> you can add my Acked-By to the patch 14:57 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 15:06 < PaulFertser> marvin24: thank you :) 15:13 < PaulFertser> Almost 2 days uptime by now, that's just awesome compared to what it was. 15:13 < PaulFertser> Silly me for not updating earlier. 15:15 < marvin24> PaulFertser: arr, just found that I booted the wrong kernel 15:15 < marvin24> now I get no mouse at all 15:15 < marvin24> and mail was already send :-( 15:17 < marvin24> PaulFertser: https://paste.debian.net/889631/ 15:17 < marvin24> it clearly shows up as a keyboard now 15:18 <*> Quits ->damex [~damex@funtoo/dev/damex] [Remote host closed the connection] 15:20 < PaulFertser> marvin24: so that was the original motivation for your patch? 15:20 < marvin24> PaulFertser: I'm not sure anymore 15:20 < PaulFertser> marvin24: eh, I thought it was just for "beauty" purporses. 15:20 < marvin24> PaulFertser: but it works in your case 15:20 < PaulFertser> marvin24: anyways, pass-through is certainly wrong. 15:20 < PaulFertser> marvin24: tbh, I haven't tried exactly reverting it. 15:20 < marvin24> I wonder why it doesn't here 15:21 < marvin24> oh 15:21 < PaulFertser> marvin24: would you agree on me doing runtime-testing of revert and then finding the proper solution to "detected as keyboard" problem this evening, not right now? 15:22 < marvin24> sure - take your time 15:22 < PaulFertser> I was going to recompile anyway to add nvec_event to my local build 15:33 < PaulFertser> I can't agree there're any issues with that patch specifically, it does the right thing regardless of whether touchpad works after it or not ;) 15:33 <*> Quits ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] [Read error: Connection reset by peer] 15:34 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] 15:34 <*> Quits ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] [Changing host] 15:34 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] 15:50 <*> Quits ->tz2625_ [~tz2625@itepkrysun.itep.kit.edu] [Quit: Leaving] 16:37 < marvin24> this is on 4.8.4 btw 17:02 <*> Joins[#ac100] ->lovecraftian_ [~ianlovecr@unaffiliated/lovecraftian] 17:06 <*> Quits ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] [Ping timeout: 252 seconds] 17:09 <*> Quits ->panda|z [~panda|z@li914-99.members.linode.com] [Ping timeout: 260 seconds] 17:09 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 17:25 <*> Quits ->damex [~damex@funtoo/dev/damex] [Remote host closed the connection] 17:27 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 18:16 < PaulFertser> Ok, same is reproducible here. 18:17 < PaulFertser> Should be easy to fix, working on it. 18:46 < PaulFertser> marvin24: btw, I think we shouldn't have atkbd enabled in the config at all as there's no hw ps/2 port that one can connect a keyboard to anyway. 18:55 < PaulFertser> Apparently our touchpad answers something on keyboard SET LEDS command so the atkbd driver decides it's a keyboard. This specific atkbd code is not going to change. We can workaround it by manually binding psmouse driver in init scripts 18:59 < PaulFertser> Or we can add a kludge to nvec to prevent that specific command from working :) 19:13 < PaulFertser> marvin24: what would you prefer me to do? 19:40 < marvin24> PaulFertser: not sure why somethings should send a set leds command to the touchpad 19:41 < marvin24> but userspace hacks are always bad 19:56 < PaulFertser> marvin24: well, when you attach something to ps/2 the kernel tries to detect a keyboard. Sending a leds off command is apparently a long-established way to do that. 19:57 < PaulFertser> btw, real ps/2 ports are exactly the same, you can connect two mice or two keyboards to a regular ATX motherboard, hotplugging works too. 20:01 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 20:14 <*> Quits ->damex [~damex@funtoo/dev/damex] [Remote host closed the connection] 21:04 <*> Joins[#ac100] ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 21:15 <*> Quits ->GeneralIdler [~calvin@2001:4b98:dc0:47:216:3eff:fe18:5d33] [Remote host closed the connection] 21:22 <*> Quits ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Read error: Connection reset by peer] 21:24 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 23:41 <*> Joins[#ac100] ->panda|z [~panda|z@li204-128.members.linode.com] --- Day changed Wed Oct 26 2016 00:02 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 01:49 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 256 seconds] 07:34 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 07:35 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 08:14 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 260 seconds] 08:38 <*> Quits ->damex [~damex@funtoo/dev/damex] [Remote host closed the connection] 08:40 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 10:18 <*> Quits ->lovecraftian_ [~ianlovecr@unaffiliated/lovecraftian] [Quit: "cheerio chaps"] 10:48 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-xpbtyrmhuoqydeyk] 11:24 <*> Joins[#ac100] ->marvin24_ [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 11:28 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Ping timeout: 256 seconds] 11:52 <*> Joins[#ac100] ->damex_ [~damex@funtoo/dev/damex] 11:55 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 260 seconds] 12:10 <*> Joins[#ac100] ->damex__ [~damex@funtoo/dev/damex] 12:13 <*> Quits ->damex_ [~damex@funtoo/dev/damex] [Ping timeout: 250 seconds] 12:31 <*> Quits ->damex__ [~damex@funtoo/dev/damex] [Ping timeout: 256 seconds] 12:42 <*> Joins[#ac100] ->damex__ [~damex@funtoo/dev/damex] 13:14 <*> Quits ->stuw [~stuw@31.44.80.66] [Read error: Connection reset by peer] 13:14 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 14:11 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] 14:37 <*> p2-mate_ is now known as p2-mate 15:25 <*> Quits ->damex__ [~damex@funtoo/dev/damex] [Ping timeout: 256 seconds] 15:42 <*> Quits ->nashpa [~nashpa@dliviu.plus.com] [Ping timeout: 258 seconds] 15:42 <*> Joins[#ac100] ->nashpa [~nashpa@dliviu.plus.com] 16:34 <*> Quits ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] [Read error: Connection reset by peer] 16:35 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] 16:35 <*> Quits ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] [Changing host] 16:35 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] 18:17 <*> Quits ->stenzel [stenzel@nat/ibm/x-xpbtyrmhuoqydeyk] [Ping timeout: 245 seconds] 19:21 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 19:43 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 245 seconds] 20:04 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 20:23 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 20:29 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 245 seconds] 21:13 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 22:30 <*> Quits ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] [Read error: Connection reset by peer] 22:31 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] 22:31 <*> Quits ->lovecraftian [~ianlovecr@2.155.71.16.dyn.user.ono.com] [Changing host] 22:31 <*> Joins[#ac100] ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] 23:12 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 23:14 < PaulFertser> marvin24_: so, any preference? I can try digging the possibility to detect LEDS OFF event on nvec_ps2 level and make it fail when running on paz00, would it be a reasonable solution in your book? 23:28 < marvin24_> PaulFertser: I tried to understand how the detection works at all 23:29 < marvin24_> seems we just don't send all required info and also we return nothing to the probe routine 23:29 < marvin24_> it would be enough if we just return that we are not a keyboard 23:29 < marvin24_> you can check the probe in atkbd.c 23:30 < marvin24_> but I failed to find out how to return data 23:30 < marvin24_> there is a magic parms array 23:30 < marvin24_> which is passed via the parent device of serio 23:30 < marvin24_> or something like this 23:32 < marvin24_> ATKBD_CMD_GETID should return something which says "I'm a mouse" 23:32 < marvin24_> http://lxr.free-electrons.com/source/drivers/input/keyboard/atkbd.c#L749 23:33 < PaulFertser> marvin24_: imho nvec_ps2 just passes the data unaltered back and forth. So when our touchpad is asked of its ID it returns something sane (not keyboard) but then when asked to turn off leds it "complies" so atkbd detection code decides it's a keyboard. 23:34 < marvin24_> AFAIU, it should only do the leds trick, if the GETID command fails 23:34 < marvin24_> no? 23:35 < marvin24_> and 0xa5a5 is not a keyboard 23:35 < marvin24_> I still don't understand what goes wrong 23:36 < PaulFertser> marvin24_: yes, getid command fails 23:36 < PaulFertser> Then it does the leds off trick 23:36 < PaulFertser> But touchpad apparently says ok to that. 23:37 < marvin24_> getid should not fail 23:37 < marvin24_> what do we return on ps2_command? 23:39 < marvin24_> mmh, "0" 23:44 < PaulFertser> getid returns not-keyboard result I think. 23:44 < PaulFertser> marvin24_: ok, so basically you want me to fully trace atkbd detection sequence and see if we break one of the assumptions about the API. 23:44 < PaulFertser> Right? 23:44 < PaulFertser> I will. 23:45 < marvin24_> that would be the best (read clean) solution 23:45 < marvin24_> no hacks please 23:46 < marvin24_> the ps2 driver is hack enough :-) 23:47 < PaulFertser> marvin24_: I will investigate it all right but I can't promise we won't have to add another hack in the end ;) But I see your point, I'm obviously not fully understanding the process that leads to the failure, I agree. 23:49 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Quit: Quitte] 23:50 < marvin24_> PaulFertser: http://lxr.free-electrons.com/source/drivers/input/serio/libps2.c#L246 23:50 < marvin24_> cmdcnt is 2 for GETID 23:50 < marvin24_> so this always fails - strange ... 23:52 < marvin24_> bedtime ... 23:53 < PaulFertser> Will check it tomorrow 23:53 < PaulFertser> Good night --- Day changed Thu Oct 27 2016 00:39 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 252 seconds] 00:55 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 256 seconds] 01:15 < PaulFertser> Hm, the wifi error seems to be back, I wonder why the hell I'm the only one seeing it. 01:15 < PaulFertser> That failed vendor request, heh. 04:19 <*> Quits ->digetx [digetx@gateway/shell/panicbnc/x-gfgocevgtwhymvxe] [Ping timeout: 258 seconds] 04:25 <*> Joins[#ac100] ->digetx [digetx@gateway/shell/panicbnc/x-rtqvpqtvhxhqmnji] 07:22 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 07:43 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 07:54 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 260 seconds] 09:48 < PaulFertser> Am I really the only one seeing those vendor request rt2800usb issues?.. 09:55 < marvin24_> PaulFertser: dmesg output, wrong firmware? 09:55 < marvin24_> normally, they are harmless 09:55 < marvin24_> current firmware is 0.29 10:04 <*> Quits ->p2-mate [~p2@emantra.psychaos.be] [Quit: leaving] 10:09 < PaulFertser> marvin24_: latest linux git tree firmware, harm is beyond reasonable, wifi stops working, unloading the module works but loading leads to Oops. 10:17 < PaulFertser> Firmwre version 0.36 10:17 < PaulFertser> I'll post the errors when they appear again. 10:27 < stuw> PaulFertser: What is "LEDS OFF event" ? 10:27 < PaulFertser> stuw: host asks keyboard to turn off the leds. 10:28 < stuw> is this a PS/2 command? 10:28 < stuw> I don't understand how it's handled by driver and/or nvec 10:28 < stuw> We have led toggle command in keyboard driver (to handle led on the CAPS button) 10:29 < stuw> nvec_kbd_toggle_led() function 10:32 < PaulFertser> stuw: it's a keyboard protocol command sent over serial bus (ps/2 or old AT) 10:33 < stuw> ah, and our ps2 driver passes this command to the NVEC. Right? 10:36 < PaulFertser> stuw: afaict, yes, but nvec is supposed to send it raw over its physical ps/2 port. 10:42 < stuw> PaulFertser: do you have ps2 commands (req+resp) log for probing? 10:46 <*> Quits ->damex [~damex@funtoo/dev/damex] [Remote host closed the connection] 10:47 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 10:50 < marvin24_> stuw: the problem is (partly), that we never return something 10:51 < stuw> marvin24_: what do you mean? 10:52 < stuw> never return something for any command? or for specific commands? 10:53 < PaulFertser> stuw: I soon will 10:54 < stuw> PaulFertser: cool, I think it will help to understand what is going on 10:54 < PaulFertser> stuw: haha 10:54 < stuw> )))) 10:55 < stuw> oh, it's all about nvec :) 10:55 < PaulFertser> stuw: well, duh, I was told to install current version and be happy. But now I'm told to do kernel work again, that's not too cool I'd say. 10:56 < stuw> yeah, I also disappointed when I need to fix something instead of using device. 10:56 < PaulFertser> I would be happy to do some kernel work if I know the device will work nicely after that. But after two days of flawless work I'm seeing wifi issues that force me to reboot the device :( 10:58 < stuw> strange 11:01 < marvin24_> stuw: for all commands 11:01 < marvin24_> PaulFertser: hey, you can just leave it as it is and use a ps/2 mouse 11:02 < marvin24_> instead of a touchpad, whatever the difference is 11:03 < PaulFertser> marvin24_: I can compile the kernel without atkbd and that would be the easiest way to get touchpad properly working too. 11:04 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-kagjrbpcscjrmrnl] 11:05 < marvin24_> PaulFertser: sure, if you are ok with this solution - it's up to you 11:05 < marvin24_> seems there is a new wifi firmware 11:06 < marvin24_> maybe this one create problems 11:08 < PaulFertser> marvin24_: are you using ac100 often or just occasionally boot it? 11:08 < marvin24_> the latter one 11:09 < marvin24_> I can tell that wifi is running stable for two days now 11:09 < PaulFertser> The very same vendor request problem appeared with old firmware that was latest when I just started with ac100. 11:09 < PaulFertser> First time I booted, it was stable for me too... 11:10 < marvin24_> normally, these vendor requests are uncritical 11:11 < marvin24_> or does the wifi connection break? 11:32 < PaulFertser> marvin24_: oh yes it does 11:33 < marvin24_> PaulFertser: can you try to revert to the old firmware? 11:34 < PaulFertser> marvin24_: I can, sure, just tell me where to get a specific file and I'll use it. 11:35 < marvin24_> PaulFertser: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/rt2870.bin?id=5c10f3d6a5c76dca943ae68926b602bd0a1eae35 11:36 < PaulFertser> [ 5050.365842] ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.29 11:36 < marvin24_> yep 12:49 < PaulFertser> marvin24_: stuw: http://paste.debian.net/890325/ first is atkbd module autoloaded during normal boot, second is after rmmoding and modprobing it. If I prevent atkbd from being loaded during the boot (by removing it from /lib/modules), it doesn't misdetect the kb after manual insmod, so it's not first vs second run issue. 13:07 < PaulFertser> So from atkbd POV: reset the keyboard, try to request id. When it gets fa 00, all fine, not a keyboard, leave alone. 13:08 < PaulFertser> But if it doesn't answer, it tries the LEDs trick. 13:08 < PaulFertser> 200ms should be plenty of time to answer but it fails during the boot, probably due to kernel busy in parallel with other stuff. 13:09 < PaulFertser> And later it answer f2 (get id) request in 15ms 13:20 <*> Joins[#ac100] ->p2-mate [~p2@emantra.psychaos.be] 14:04 < marvin24_> PaulFertser: reset does not detect a keyboard 14:04 < PaulFertser> I suspect nvec communication issue, not that there's something wrong with touchpad itself or atkbd. 14:04 < marvin24_> only getid 14:04 < PaulFertser> marvin24_: yes, but in the first run getid remains unanswered. 14:04 < marvin24_> but the pad does not respond 14:05 < marvin24_> that's also fine 14:05 < PaulFertser> Either that, or nvec doesn't properly pass the data back and forth. 14:05 < marvin24_> we need to fill something into parms array 14:05 < PaulFertser> The pad responds to getid on later inquiries. 14:05 < marvin24_> does it? 14:06 < marvin24_> maybe the messages are not in sync 14:06 < marvin24_> ff -> fa aa 00 14:06 < marvin24_> f2 -> fa 00 14:06 < marvin24_> f2 -> fe? 14:07 < marvin24_> no ed -> fe 14:07 < PaulFertser> marvin24_: I can repeat rmmod && modprobe any number of times and it's every time like in the "Right detection" section. 14:08 < PaulFertser> Only the first load when done automatically (or with statically linked in module) fails. 14:11 < marvin24_> PaulFertser: can you post the difference? 14:14 < PaulFertser> marvin24_: my paste contains both. The first part is atkbd autoloaded by udev, the second is my manual removal/insertion. 14:14 < PaulFertser> marvin24_: if you need something else, I'll get and post it, sure. 14:15 < marvin24_> the messages on the bus are the same, AFAICT 14:15 < marvin24_> they shouldn't matter at all, becasue we never return the result 14:20 < PaulFertser> The main difference imho is that in the first case touchpad doesn't reply to f2 command. 14:21 < PaulFertser> Doesn't reply to f2 at all. 14:23 < marvin24_> PaulFertser: that's not sure, as I said, the messages may not be in sync, eg. the reply comes before the command 14:23 < marvin24_> you could try to add some dev_dbg lines into atkbd.c to see what's going on 14:26 < PaulFertser> marvin24_: the messages in the kernel log have proper timestamps afaict, I do not think their order can be confusing. 14:26 < PaulFertser> f2 doesn't get any reply so atkbd proceeds with ed 14:26 < PaulFertser> Do you doubt that? 14:30 < marvin24_> PaulFertser: in the output you posted, the first line ist the response to the second line - no? 14:30 < marvin24_> and again, we don't return anything - so the response don't matter at all 14:32 < PaulFertser> marvin24_: no, the very first line appears anyway, even without atkbd loaded at all ever. 14:33 < PaulFertser> marvin24_: ps2 is a bidirectional communication bus, so we do return data and atkbd pays attention to the result. It's not returned in the function return code sense, but they're delivered to atkbd by other means. 14:33 < marvin24_> PaulFertser: ok, you also be the answer to the mouse reset in the probe function 14:33 <*> Joins[#ac100] ->stuw_ [~stuw@31.44.80.66] 14:34 < marvin24_> PaulFertser: yes, we should return something, but unfortunately, there is no code doing it 14:35 < marvin24_> that should be done my ps2_handle_response 14:35 < PaulFertser> marvin24_: it doesn't matter, ps2_command waits for the reply from the device anyway. 14:35 < marvin24_> PaulFertser: that's also not the case 14:35 < marvin24_> we are writing async 14:35 < marvin24_> as I said, lot of hacks 14:36 < marvin24_> that means, we don't really care what comes back 14:36 < PaulFertser> marvin24_: look at __ps2_command , it has wait_event_timeout(ps2dev->wait... timeout) 14:36 <*> Quits ->stuw [~stuw@31.44.80.66] [Ping timeout: 265 seconds] 14:36 < PaulFertser> marvin24_: so it does wait for our reply 14:37 < marvin24_> but where is the other side of ps2dev->wait? 14:37 < PaulFertser> ps2_handle_response called from nvec_ps2 14:38 < marvin24_> there is also ps2_handle_ack 14:38 < marvin24_> anyway, both functions are never called by us 14:50 < PaulFertser> Well, I think what happens is that we call serio_interrupt, atkbd_interrupt gets called and it eventually calls ps2_handle_response. Enough of a proof: http://paste.debian.net/890352/ ? 14:56 < PaulFertser> marvin24_: http://paste.debian.net/890364/ 14:58 <*> Quits ->stuw_ [~stuw@31.44.80.66] [Remote host closed the connection] 14:59 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 15:00 < PaulFertser> stuw: http://paste.debian.net/890364/ 15:07 < marvin24_> PaulFertser: sorry, I missed that function 15:07 < marvin24_> so, yes, we reply 15:11 < marvin24_> so, getid fails and setleds return ack 15:12 < marvin24_> and probe returns early 15:12 < marvin24_> touchpad should not return ack 15:14 < stuw> The driver doesn't reply to f2 command on boot, but it replyes after rmmod+modprobe. Right? 15:14 <*> Quits ->PaulFertser [paul@2001:470:26:54b:260:98ff:feef:cb79] [Ping timeout: 260 seconds] 15:15 <*> Joins[#ac100] ->PaulFertser [paul@2001:470:26:54b:260:98ff:feef:cb79] 15:16 < PaulFertser> marvin24_: sorry, got disconnected, did you answer anything after "we reply"? 15:17 < marvin24_> PaulFertser: [14:08:01] so, yes, we reply 15:17 < marvin24_> [14:12:32] so, getid fails and setleds return ack 15:17 < marvin24_> [14:13:03] and probe returns early 15:17 < marvin24_> [14:13:14] touchpad should not return ack 15:17 < marvin24_> [14:15:11] The driver doesn't reply to f2 command on boot, but it replyes after rmmod+modprobe. Right? 15:17 < PaulFertser> stuw: right 15:17 <*> Joins[#ac100] ->stuw_ [~stuw@31.44.80.66] 15:18 < PaulFertser> stuw: interesting thing about http://paste.debian.net/890364/ is line 8 15:18 < marvin24_> my, shouldn't f2 be submitted with 0 as argument 15:19 < marvin24_> I mean ed 15:20 <*> Quits ->stuw [~stuw@31.44.80.66] [Ping timeout: 245 seconds] 15:20 < marvin24_> 10ed, send ed with one argument (which is 00) 15:20 < PaulFertser> Well, we have an example of proper communication: http://paste.debian.net/890352/ 15:22 < marvin24_> PaulFertser: can you test to reset the mouse twice in nvec_ps2 probe? 15:22 < marvin24_> nvec_write_async(nvec, mouse_reset, sizeof(mouse_reset)); 15:33 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 260 seconds] 15:33 <*> Quits ->lovecraftian [~ianlovecr@unaffiliated/lovecraftian] [Read error: Connection reset by peer] 15:46 < marvin24_> the original driver does it up to 20 times... 15:50 < marvin24_> https://gitlab.com/ac100/original-kernel/blob/2.6.32/drivers/input/mouse/nvec_mouse.c#L746 16:08 <*> Quits ->marvin24_ [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 16:09 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 16:21 <*> Quits ->stenzel [stenzel@nat/ibm/x-kagjrbpcscjrmrnl] [Ping timeout: 260 seconds] 16:23 < PaulFertser> marvin24: how about doing it zero times? 16:23 < PaulFertser> marvin24: now I see the reason. nvec_ps2 sends a PS/2 command during probe, and atkbd receives it unexpectedly. 16:23 < PaulFertser> marvin24: that reset is a clear layering violation. 16:24 < PaulFertser> If you absolutely need to send it, you must wait for a reply too, before registering a serio bus. But I do not see why that reset might be needed. 16:24 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 16:25 < PaulFertser> marvin24: in what case a reset is needed? Seems to work fine for me without one. 16:32 < marvin24> PaulFertser: if it works find, I'm also fine to kill it 16:32 < marvin24> it was used in the original driver to be able to identify the mouse 16:34 < PaulFertser> marvin24: it works for me but probably won't work for you, who knows. It's clearly a really wrong way of doing it behind serio's back, so no wonder it's problematic. 16:34 < marvin24> I'll try it just now 16:36 < marvin24> arrr, just being caught by the "panel does not corretly init" bug 16:51 < marvin24> PaulFertser: ok, removing the "mouse reset" also works for me 16:52 < PaulFertser> marvin24: I'm retesting and sending a patch then. 16:52 < PaulFertser> Thank you for the hint, heh. 16:52 < PaulFertser> I didn't expect such a layering violation 16:53 < marvin24> well, the driver just tried to mimik the original driver probe 16:53 < marvin24> but the original driver never supported touchpad operatition 16:54 < marvin24> mmh, the panel problem seems to be related to heat 16:57 < PaulFertser> I think had ac100 turning off completely due to heat but it was in the summer outdoors iirc. 17:02 < PaulFertser> marvin24: I think those are two different issues, I am not sure there should be a single patch covering both. 17:03 < marvin24> PaulFertser: ok, you can create two patches then, called 1/2 and 2/2 (see git-sendemail) 17:03 < marvin24> we first have to apply your fix, and then later, apply the type change 17:04 < marvin24> we must not confuse gregk 17:39 <*> Joins[#ac100] ->kjeldo [53594afd@gateway/web/freenode/ip.83.89.74.253] 17:59 < PaulFertser> I hope this way I sent now is not confusing anybody. 18:08 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-nnrqqjiztzyoiznr] 18:16 <*> Quits ->stenzel [stenzel@nat/ibm/x-nnrqqjiztzyoiznr] [Ping timeout: 276 seconds] 18:41 < marvin24> PaulFertser: yes, better 18:41 < marvin24> thanks 18:41 < PaulFertser> marvin24: thank you! 18:41 < marvin24> btw, ec is connected to ps/2 with one side 18:41 < marvin24> and i2c on the other one 18:46 < marvin24> maybe too late for 4.10 already 19:52 < marvin24> every time something is posted to ac100 ml, I get a message from Valeriy P Yefimov 19:53 < marvin24> Спасибо . Письмо получил . 19:53 < marvin24> Заявка в Кассу Взаимопомощи https://bitfinex.vkonekte.com/kassa 19:53 < marvin24> whatever he wants to sell me ... 20:46 < PaulFertser> marvin24: that's pure scam 20:47 < PaulFertser> I think you should simply unsubscribe him. 21:10 <*> Joins[#ac100] ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 23:40 < marvin24> PaulFertser: the thing is that he is not subscribed at all 23:46 < PaulFertser> marvin24: I'll soon have some minimal code to support LID events, will you want to have a preview before I send it? --- Day changed Fri Oct 28 2016 00:05 < PaulFertser> marvin24: do you get any "ec system event" in dmesg with current kernel when you press power button shortly? 00:07 < PaulFertser> Also, on my device 80 is produced for lid open, 82 for lid closed while the code that used to work before expects 80 for power button, 02 for lid close, 00 for lid open 00:17 < PaulFertser> Yes, my old kernel logs show 02 and 00 for lid events and here 0x80 as if pwr button bit is stuck. 00:17 < PaulFertser> I might try rebooting the ec, heh. 00:40 < PaulFertser> haha, apparently new fancy stuff nvec_event_mask is not too correct 00:54 < PaulFertser> ok, behaves as expected now 01:02 <*> Quits ->damex [~damex@funtoo/dev/damex] [Remote host closed the connection] 01:06 < PaulFertser> marvin24: stuw__ : please feel free to review http://paste.debian.net/890503/ 01:14 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 01:17 <*> Quits ->stuw_ [~stuw@31.44.80.66] [Ping timeout: 265 seconds] 01:48 <*> Quits ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 260 seconds] 02:30 <*> Quits ->kjeldo [53594afd@gateway/web/freenode/ip.83.89.74.253] [Ping timeout: 260 seconds] 05:30 <*> Quits ->panda|z [~panda|z@li204-128.members.linode.com] [Ping timeout: 250 seconds] 05:34 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 05:35 <*> Joins[#ac100] ->panda|z [~panda|z@li204-128.members.linode.com] 06:08 <*> Joins[#ac100] ->kjeldo [d5538725@gateway/web/freenode/ip.213.83.135.37] 07:30 <*> Joins[#ac100] ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 08:24 <*> Quits ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 244 seconds] 09:24 < PaulFertser> Damn wifi, left it overnight without any wifi activity, woke up to see rt2xc00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0228 with error -110 09:24 < PaulFertser> And it's not harmless, I'll need to reboot to get wifi working. 09:40 < PaulFertser> I left it at 01:08 and the first message appeared at 03:59. All the messages say -110 (-ETIMEDOUT). Means the card just doesn't answer the request at all. But it's still present in lsusb. 10:25 <*> Quits ->stuw [~stuw@31.44.80.66] [Ping timeout: 260 seconds] 10:33 < marvin24> PaulFertser: which kernel are you using? 10:36 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 10:36 < PaulFertser> marvin24: 4.8.0-rc6 10:48 < PaulFertser> marvin24: and I'm using a regular ath9k AP here. 10:49 < marvin24> I can let it run over the weekend to see if it also fails 10:49 < PaulFertser> Regarding the LID events 10:49 < marvin24> you should use a stable kernel btw 10:49 < PaulFertser> Would you like to discuss it before I send it? 10:50 < PaulFertser> Well, it was the closest to stable when I decided to upgrade. 10:50 < PaulFertser> I doubt the wifi issue would be solved though... 10:51 < marvin24> I'll take a look at the event patch 10:51 < PaulFertser> Ok, tia 10:53 < marvin24> PaulFertser: did you forgot to remove the event_mask calls in nvec.c? 10:53 < PaulFertser> marvin24: indeed, good catch! 10:55 < PaulFertser> marvin24: what kernel version do you recommend me to use now (for using, not for preparing patches for staging)? 10:55 < marvin24> PaulFertser: normally, you should use 4.8.0 10:56 < PaulFertser> Got it. 10:56 < marvin24> you patchc fails to apply btw 10:59 < PaulFertser> marvin24: hm, it didn't fail to apply to linux-next. 10:59 < marvin24> maybe the debian paste was corrupted 10:59 < PaulFertser> Probably pasting to pastebin got it mangled 10:59 < PaulFertser> Yes 11:00 < marvin24> PaulFertser: use http://sprunge.us/ 11:00 < PaulFertser> Let me resend 11:00 < marvin24> cat patch.txt | curl -F 'sprunge=<-' http://sprunge.us 11:02 < PaulFertser> http://sprunge.us/ChTS 11:18 < marvin24> PaulFertser: you need to return some proper error if input_allocate_devices fails 11:19 < PaulFertser> marvin24: isn't propogating whatever error that lead to a failure the right thing here? 11:20 < marvin24> you are not propagating it.... 11:20 < PaulFertser> Ah 11:20 < PaulFertser> Silly me, indeed. 11:20 < marvin24> just return -ENOMEM 11:21 < marvin24> also you need to call input_free_device if input_register_device fails 11:21 < marvin24> and also call input_unregister_device in the remove function (which does not exist) 11:23 < PaulFertser> marvin24: I think devm takes care of that 11:24 < PaulFertser> "Such managed input 11:24 < PaulFertser> 2077 * devices need not be explicitly unregistered or freed," 11:26 < marvin24> register_device is not managed 11:27 < PaulFertser> marvin24: are we talking about freeing something that input_register_device allocates? 11:27 < marvin24> http://lxr.free-electrons.com/source/drivers/input/input.c#L2063 11:27 < PaulFertser> Then if I understand it right, http://lxr.free-electrons.com/source/drivers/input/input.c#L2075 11:28 < marvin24> PaulFertser: ah, ok, I should read the whole manual :-) 11:29 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-eewsmpptlsnldntz] 11:29 < PaulFertser> marvin24: I really appreciate detailed review btw. 11:32 < marvin24> PaulFertser: ideally, we would need an nvec_event.cc driver which does all the work 11:32 < marvin24> and nvec_paz00 which registers the switches 11:32 < marvin24> that's because events are part of the nvec spec 11:33 < marvin24> but well... 11:35 < PaulFertser> I found https://www.kernel.org/doc/readme/drivers-staging-nvec-README and thought there's no specification. 11:37 < marvin24> PaulFertser: check your mail (in 5 mins) 11:38 < PaulFertser> ack 11:42 < PaulFertser> Most likely that nvec driver is only used by the few remaining ac100 owners anyways. 11:45 < marvin24> PaulFertser: yes 11:45 < marvin24> and event is not a "device" of its own, it's configured via system 11:46 < marvin24> doesn't matter, just keep it as it is 11:46 < marvin24> PaulFertser: can you allocate paz00_extra_input dynamicly (same as the led structure) 11:47 < marvin24> ah, forget it 11:50 < PaulFertser> I can embed it into struct nvec_chip probably but nvec.c itself has e.g. static nvec_power_handle. 11:53 < marvin24> PaulFertser: it's ok, just keep it as you had it 11:55 < marvin24> you could rename paz00_extra_input to nvec_keys maybe (that's shorter and more consitent), but this is just a matter of taste 11:57 < PaulFertser> Well, we also have an nvec keyboard so I thought extra_input is less confusing. 11:57 < PaulFertser> And LID switch is not really a key. 11:59 < marvin24> as I said, just a matter of taste, ignore me 12:05 < marvin24> PaulFertser: are these switches/buttons supposed to do anything (beside printing a message in syslog)? 12:05 < PaulFertser> marvin24: I use "sudo input-events 3" for testing 12:05 < PaulFertser> And then I'd recommend triggerhappy daemon to blank the display when LID is closed. 12:05 < PaulFertser> (or count on DE to do that but I do not use a DE) 12:06 < PaulFertser> I've tested pressing power button with lid "closed" (using external magnet) too, that worked (original nvec_event.c code wouldn't handle that). 12:07 < marvin24> I remember that it tried to suspend when the lid closes in the past (don't know which kernel it was) 12:07 < PaulFertser> That's what any modern DE would do by default I think. 12:09 < marvin24> ok, I wasn't sure which part of the system handles these things 12:09 < marvin24> mmh, where could I tell the kernel which suspend method to use 12:09 < marvin24> (LP0 or LP1) 12:10 < PaulFertser> I am still considering implementing that lp0 s2ram method but I'm hesitating as sometimes I have a feeling I can just throw it out of the window especially when it's not stable enough in the already "supported" features. 12:11 < marvin24> yes, I just tried "echo mem > /sys/power/state" 12:11 <*> Quits ->p2-mate [~p2@emantra.psychaos.be] [Ping timeout: 256 seconds] 12:11 < marvin24> it wakes up and immediately suspends again 12:11 < marvin24> I think this was a know bug 12:16 <*> Joins[#ac100] ->p2-mate [~p2@emantra.psychaos.be] 12:17 < PaulFertser> I think most DEs react similarly to power button press. 12:17 < PaulFertser> Oh shit, I've forgotten to regenerate initramfs. Serial time for me again. 12:26 < marvin24> PaulFertser: patch looks fine to me 12:26 < marvin24> PaulFertser: if you are still motivated, you could also move the speaker unmute out of nvec.c in a second patch 12:27 < PaulFertser> You can choose between LP1 and LP2 by changing "nvidia,suspend-mode" DT property, it's set to LP1 currently. 12:27 < marvin24> LP2 should be no problem 12:27 < PaulFertser> marvin24: why do we have it in LP1 then? :) 12:27 < stuw> marvin24: PaulFertser: sorry, I don't have enough time for good patch review :( 12:27 < PaulFertser> stuw: np 12:27 < marvin24> PaulFertser: well, LP1 should work ... 12:27 < PaulFertser> stuw: staging/* isn't worth much attention anyway, imho. 12:28 < PaulFertser> btw, the "pop" sound is still there and it's still annoying 12:29 < marvin24> PaulFertser: unfortunately, as long as it sits there, someone has to take care of it 12:29 < stuw> one moment about new devices - maybe it would be usefull to attach power button events to the keyboard. We have short and long press. 12:29 < PaulFertser> stuw: long pwr button press is handled by EC in hardware, it just switches everything off, right? 12:30 < PaulFertser> stuw: I think the keyboard handling is not paz00 specific while lid and pwr button events are. 12:30 < stuw> PaulFertser: no. press shorter that 1 sec, press for time >4 sec and <8 sec 12:30 < stuw> press longer than 8 seconds switches device off 12:31 < PaulFertser> But what mask is required to sense that >4s event? 12:32 < PaulFertser> stuw: on my x86 laptop there're different input devices for lid, sleep and two power buttons, a device per every button. 12:32 < PaulFertser> So it's kinda common to have a dedicated device for additional events. 12:36 < stuw> PaulFertser: https://github.com/ac100-ru/picasso-kernel/commit/3a2ff2a9d776d12445a90611c5be45997520544d - maybe it can help. I don't remember details about nvec packets for this cases 12:38 < PaulFertser> stuw: I see your point 13:09 <*> Quits ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] [Ping timeout: 260 seconds] 13:10 <*> Quits ->kjeldo [d5538725@gateway/web/freenode/ip.213.83.135.37] [Ping timeout: 260 seconds] 13:14 < PaulFertser> marvin24: just tried lp1 suspend, it surprisingly worked, including resuming 13:15 < PaulFertser> I can't believe my eyes :) 13:15 < PaulFertser> There must be some gotcha 13:15 < PaulFertser> Probably won't work with X started :) 13:28 < PaulFertser> stuw: are you sure you've ever seen long press events? Can't get it to work here even though I enabled reporting all of them. 13:28 < stuw> PaulFertser: yes, I'm sure. One of them is system event IIRC 13:29 < stuw> PaulFertser: is your patch for short press? 13:29 < PaulFertser> Hm, short press and lid switch are system events 13:29 < PaulFertser> stuw: short press + lid, yes. 13:30 < stuw> zombah: do you remember something about long press of power key? 13:32 < zombah> stuw: i remember that its not working 13:33 < PaulFertser> marvin24: after resume the touchpad got detected as keyboard again. 13:34 <*> Joins[#ac100] ->pranza [pranza@pranza.audiomastering.lt] 13:34 < PaulFertser> And second suspend hanged the system. 13:36 <*> Joins[#ac100] ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] 13:38 < PaulFertser> Why isn't the paz00 mode set to LP2 then if LP1 isn't stable? 13:48 < PaulFertser> marvin24: lp2 seems to be working while lp1 seems to be not stable with X running. 13:49 < PaulFertser> Hm, nope, after trying some more times, lp2 failed to suspend too, the power led is constantly on. 13:53 < PaulFertser> Yes, hangs in lp2 during _suspend_ without any X running. 14:05 < PaulFertser> Hanged on ~25th try 14:06 < PaulFertser> stuw: I blame nvec ;) 14:08 < zombah> as i remember trimslice sleeps fine, so probably nvec have some pm problems 14:08 < marvin24> PaulFertser: here it resumes, and after that, the system is shut down by OS 14:09 < PaulFertser> marvin24: it runs at least once for me with X.org too. 14:09 < PaulFertser> marvin24: shutdown is probably thanks to Unity or some other complicated strange software. 14:09 < PaulFertser> marvin24: I'm trying from text console and trying multiple times. 14:09 < marvin24> PaulFertser: X should be no problem, because graphics is purly handled by kernel 14:10 < PaulFertser> marvin24: it's a problem because it runs unity ;) 14:11 < PaulFertser> marvin24: can you try suspending while holding Shift? Seems the probability to hang during suspend (wth power led ON) is really high in this case. 14:11 < marvin24> PaulFertser: no unity, lxde 14:11 < marvin24> suspend via "echo mem > state" 14:11 < PaulFertser> marvin24: Yes, that way. 14:11 < PaulFertser> While holding shift 14:11 < marvin24> maybe I should try pm-suspend 14:11 < PaulFertser> (right shift in my case) 14:11 < PaulFertser> Shouldn't affect anything really. 14:13 < PaulFertser> Hm, not really consistent 14:13 < marvin24> ok, with pm-suspend at came back and stayed online 14:13 < PaulFertser> Shift doesn't always cause a hang 14:13 < marvin24> PaulFertser: yes, it's just unreliable 14:13 < PaulFertser> One try doesn't seem to mean much in this case. 14:13 < marvin24> that's what makes it hard to debug 14:15 < PaulFertser> I blame nvec 14:16 < marvin24> fixes welcome ;-) 14:20 < PaulFertser> Without nvec modules it doesn't suspend at all, heh. 14:21 < marvin24> PaulFertser: you could try to remove all, but the core driver 14:24 < PaulFertser> With nvec.ko it suspends but apparently no resume event is enabled 14:26 < marvin24> PaulFertser: can't be 14:28 <*> Joins[#ac100] ->kjeldo [53594afd@gateway/web/freenode/ip.83.89.74.253] 14:28 < marvin24> PaulFertser: maybe we need kbd 14:28 < PaulFertser> marvin24: with nvec_kbd it resumes on keyboard press, without it it doesn't, I tried several times. 14:28 < marvin24> yes, it programs the keyboard as a wake source 14:29 < PaulFertser> I wonder how it happened ac100 users didn't really want suspend support... 14:29 < marvin24> PaulFertser: it has been tried for long time, but given up 14:30 < stuw> PaulFertser: yes, suspen probably depends from nvec. https://paz00.ru/index.php/Suspend_debugging#Tests 14:31 < PaulFertser> Nice plan 14:31 < PaulFertser> I feel like smoking one 14:32 < PaulFertser> (in russian it's used to denote weed) 14:35 < PaulFertser> With just nvec.ko and nvec_kbd.ko lp2 in console seems reliable, it ran for some 30 cycles by now 14:57 < PaulFertser> Yes, plenty of cycles with one keyboard key permanently pressed and X running. 15:17 < PaulFertser> Hangs with either nvec_ps2 or nvec_power 15:21 < PaulFertser> Rebooted another time and now nvec_ps2 doesn't seem to harm, wth. 15:23 < zombah> timing probably, defered init or something 15:23 < PaulFertser> Or just luck 15:30 < PaulFertser> No, it just hanged again. 15:41 < marvin24> maybe we need to shutdown more of nvec 15:41 < marvin24> e.g. stop workqueue and irq 15:41 < marvin24> during suspend 15:45 < PaulFertser> Cycling nicely so far without nvec_ps2 and nvec_power. 15:48 < marvin24> PaulFertser: maybe these drivers try to communicate while ec is still not ready 15:48 < PaulFertser> marvin24: I'm not sure why you're telling me this :) 15:50 < PaulFertser> I mean it's an obvious theory. 15:51 < PaulFertser> stuw: so, I forget about long press and send as it is? 15:52 < stuw> PaulFertser: yes :) We will fix long press later (if it doesn't work) %) 16:05 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 250 seconds] 16:19 < PaulFertser> marvin24: http://sprunge.us/CXVa I think I've accounted for all your notes now. 16:35 < PaulFertser> lp1 suspend/resume works too it seems 16:35 < PaulFertser> 50 cycles 16:52 < PaulFertser> something's buggy with my latest patches regarding short button press though. 16:53 < PaulFertser> And for whatever reason the regular ec keyboard now doesn't work for me, input device doesn't report anything but it works for resuming. 17:05 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 17:12 <*> Quits ->stenzel [stenzel@nat/ibm/x-eewsmpptlsnldntz] [Ping timeout: 260 seconds] 17:35 < PaulFertser> I wonder if suspend-resume is stable for anybody else if nvec_ps2 and nvec_power are disabled. 17:36 < marvin24> PaulFertser: you have to descibe a bit more exact what is done in the patch description 17:37 < marvin24> in fact, you are moving the stuff from nvec to nvec_paz00 17:37 < marvin24> also you seem to fix a the power button 17:37 < PaulFertser> marvin24: fix in what sense? 17:37 < marvin24> bit 15 > bit 7 17:37 < PaulFertser> It never worked anyway. 17:37 < PaulFertser> So it's not a fix, that was dead code. 17:39 < marvin24> call it how you like, it's a non obvious change 17:39 < marvin24> reviewers will ask about it 17:39 < PaulFertser> I do not think commit message needs to describe what is obvious from the patch itself, it needs to describe motivation for that. 17:39 < PaulFertser> Nobody cares about ac100 anyway :/ 17:40 < PaulFertser> btw, 100 cycles with lp1 and without nvec_ps2, nvec_power without a glitch. 17:40 < marvin24> you will be surprised how "penetrant" reviewers on ldp are .... 17:41 < marvin24> that's good news 17:41 marvin24 needs to go shopping 17:57 < PaulFertser> Great, integrated keyboard doesn't work before nvec_ps2 is loaded. 18:57 < PaulFertser> Has anyone actually tried to measure power consumption in different modes on ac100? 19:21 < PaulFertser> Another 500 lp1 cycles with X.org running. 19:39 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 19:40 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 19:42 <*> Quits ->stuw [~stuw@31.44.80.66] [Ping timeout: 252 seconds] 20:10 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 260 seconds] 20:12 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 20:15 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 20:22 <*> Quits ->damex [~damex@funtoo/dev/damex] [Read error: Connection reset by peer] 20:50 <*> Quits ->jbrown [~jules@2a02:c7d:8e9c:4500:2af1:eff:fe0e:8884] [Quit: Leaving] 21:03 <*> Joins[#ac100] ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 21:21 < stuw__> PaulFertser> Another 500 lp1 cycles with X.org running <- without nvec_ps2 and nvec_power? 21:22 < stuw__> PaulFertser, do any of this drivers break suspend? 21:22 < PaulFertser> stuw__: yes, without, seems either of them break suspend. 21:27 < stuw__> PaulFertser, it's a progress then! 21:36 < PaulFertser> stuw__: useless unless someone put plenty of time into digging deeper :/ 22:32 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:5b6:2ca4:cb0a:e9be] 22:47 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 22:50 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:5b6:2ca4:cb0a:e9be] [Ping timeout: 250 seconds] 22:54 <*> Quits ->DanSwano [~danswano@109.234.34.139] [Read error: Connection reset by peer] 22:56 < marvin24> or just unload the drivers before suspend and reload them on resume 22:56 < marvin24> :-) 23:35 < PaulFertser> marvin24: it oopses on unloading --- Day changed Sat Oct 29 2016 01:46 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 01:49 < stuw__> maybe it oopses on suspen when no one can see it? %) 01:57 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Remote host closed the connection] 02:01 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:14f8:653d:741a:d6d4] 02:06 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:14f8:653d:741a:d6d4] [Ping timeout: 245 seconds] 02:20 <*> Quits ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 265 seconds] 04:22 <*> Quits ->kjeldo [53594afd@gateway/web/freenode/ip.83.89.74.253] [Quit: Page closed] 06:03 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:7cf4:da5e:2f21:188a] 06:08 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:7cf4:da5e:2f21:188a] [Ping timeout: 250 seconds] 08:04 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:119a:864b:d4e0:8a5c] 08:09 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:119a:864b:d4e0:8a5c] [Ping timeout: 260 seconds] 09:52 <*> Joins[#ac100] ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 10:26 < marvin24> PaulFertser: this should not happen - it worked fine in the past 11:13 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 11:58 <*> Joins[#ac100] ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 12:00 <*> Quits ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Read error: Connection reset by peer] 12:01 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:50cc:c6e2:c669:4e22] 12:04 <*> Joins[#ac100] ->stuw_ [~stuw@2a02:2168:1674:e700:d5f6:aa04:e3bb:2c17] 12:06 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:50cc:c6e2:c669:4e22] [Ping timeout: 250 seconds] 12:18 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:9c30:d413:5ce5:52ad] 12:22 <*> Quits ->stuw_ [~stuw@2a02:2168:1674:e700:d5f6:aa04:e3bb:2c17] [Ping timeout: 260 seconds] 12:23 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:9c30:d413:5ce5:52ad] [Ping timeout: 260 seconds] 12:25 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:b53f:4533:8b48:ca6] 12:34 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:b53f:4533:8b48:ca6] [Ping timeout: 250 seconds] 12:35 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:ac7a:2606:2fb7:2648] 12:37 <*> Joins[#ac100] ->stuw_ [~stuw@2a02:2168:1674:e700:895e:959c:64:5a2e] 12:40 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:ac7a:2606:2fb7:2648] [Ping timeout: 250 seconds] 12:42 <*> Joins[#ac100] ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 12:44 <*> Quits ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Read error: Connection reset by peer] 12:45 <*> Quits ->stuw_ [~stuw@2a02:2168:1674:e700:895e:959c:64:5a2e] [Ping timeout: 260 seconds] 12:45 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:9d5e:6ba5:6d48:9e7e] 12:48 <*> Joins[#ac100] ->stuw_ [~stuw@2a02:2168:1674:e700:8907:b7ab:896:6f62] 12:50 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:9d5e:6ba5:6d48:9e7e] [Ping timeout: 250 seconds] 12:57 <*> Quits ->stuw_ [~stuw@2a02:2168:1674:e700:8907:b7ab:896:6f62] [Ping timeout: 260 seconds] 12:59 <*> Joins[#ac100] ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 13:02 <*> Quits ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Read error: Connection reset by peer] 13:07 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:9904:566c:1075:72d2] 13:09 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 13:12 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:9904:566c:1075:72d2] [Ping timeout: 250 seconds] 13:16 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Read error: Connection reset by peer] 13:16 <*> Joins[#ac100] ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 13:18 <*> Quits ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Read error: Connection reset by peer] 13:18 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:1cf6:b928:d0cd:f794] 13:25 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:1cf6:b928:d0cd:f794] [Ping timeout: 250 seconds] 13:37 <*> Joins[#ac100] ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 13:57 <*> Joins[#ac100] ->jbrown [~jules@host86-157-139-19.range86-157.btcentralplus.com] 14:19 <*> Quits ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Remote host closed the connection] 14:28 <*> Joins[#ac100] ->kjeldo [53594afd@gateway/web/freenode/ip.83.89.74.253] 15:08 <*> Quits ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] [Ping timeout: 245 seconds] 15:08 <*> Joins[#ac100] ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] 15:16 <*> Quits ->jbrown [~jules@host86-157-139-19.range86-157.btcentralplus.com] [Ping timeout: 250 seconds] 15:34 <*> Joins[#ac100] ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 15:34 <*> Quits ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Remote host closed the connection] 17:35 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:8022:8274:fd57:7ac3] 17:40 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:8022:8274:fd57:7ac3] [Ping timeout: 250 seconds] 17:56 <*> Joins[#ac100] ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 18:19 <*> Joins[#ac100] ->stuw_ [~stuw@2a02:2168:1674:e700:20cd:f4e2:63bb:84ff] 18:19 <*> Quits ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Read error: Connection reset by peer] 18:24 <*> Quits ->stuw_ [~stuw@2a02:2168:1674:e700:20cd:f4e2:63bb:84ff] [Ping timeout: 260 seconds] 18:25 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:cc29:4ee9:edcf:48bc] 18:32 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:cc29:4ee9:edcf:48bc] [Remote host closed the connection] 20:32 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:cc29:4ee9:edcf:48bc] 20:37 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:cc29:4ee9:edcf:48bc] [Ping timeout: 260 seconds] 22:59 <*> Joins[#ac100] ->deephead99 [~user@37-139-52-89.mrhost.biz] 23:11 < PaulFertser> marvin24: I think if you build modular nvec* you'll see it too. I'll provide an oops if you want :) 23:14 <*> Joins[#ac100] ->Hobbes` [~calvin@2001:4b98:dc0:47:216:3eff:fe18:5d33] --- Day changed Sun Oct 30 2016 00:34 <*> Joins[#ac100] ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 00:39 <*> Quits ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 256 seconds] 00:53 <*> Quits ->stuw__ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 247 seconds] 00:55 < PaulFertser> Yesterday I was thinking something is wrong with my serial and that I won't be able to continue with suspend/resume adventures. Today I was commuting and thinking about it and came to a conclusion I simply have two minicoms running. Came home, lsof, voila, exactly! 01:08 <*> Quits ->deephead99 [~user@37-139-52-89.mrhost.biz] [Quit: Leaving] 01:25 < PaulFertser> Now that's a decent hint, just on failed suspend (or rather, I now think it's a failed suspend preparation so there's no resume source): 01:25 < PaulFertser> [ 410.590006] Freezing remaining freezable tasks ... (elapsed 0.007 seconds) done. 01:25 < PaulFertser> (elapsed 0.005 seconds) done. 01:25 < PaulFertser> [ 413.106173] nvec 7000c500.nvec: timeout waiting for sync write to complete 01:25 < PaulFertser> [ 413.124879] PM: suspend of devices complete after 2526.661 msecs 01:56 < PaulFertser> Knowing how "stable" communication with nvec is it's kind of obvious now how suspend might easily fail in way that the device won't be able to resume... 02:23 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 02:35 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:75e7:7d3c:413:663a] 02:40 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:75e7:7d3c:413:663a] [Ping timeout: 260 seconds] 03:16 <*> Quits ->nashpa [~nashpa@dliviu.plus.com] [Ping timeout: 260 seconds] 03:36 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:6506:cc7c:3583:f0e2] 03:40 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:6506:cc7c:3583:f0e2] [Ping timeout: 250 seconds] 05:37 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:51d2:724:e976:5278] 05:42 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:51d2:724:e976:5278] [Ping timeout: 260 seconds] 07:38 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:2185:a771:a0c0:8e2d] 07:43 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:2185:a771:a0c0:8e2d] [Ping timeout: 260 seconds] 09:38 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:2c57:a078:9fc1:9db3] 09:43 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:2c57:a078:9fc1:9db3] [Ping timeout: 260 seconds] 09:48 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 09:57 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 10:02 < PaulFertser> Heh, first you write "keep these sync or you'll break suspend", then change nvec_write_sync to nvec_toggle_global_events which is async :) 10:42 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 260 seconds] 10:48 < PaulFertser> I got some oops, trying to decode it. Heh, I thought I know how to read compiler-optimised code. 10:56 < PaulFertser> Almost every time I suspected a compiler bug it was actually a bug in my code. Wonder if it's the case here as well... 11:10 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 11:11 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 11:40 < PaulFertser> marvin24: can you please help me understand nvec timeout handling logic? I have hesitations about locking etc. 11:43 < PaulFertser> Is it (nvec_request_master) supposed to transfer a message indefinitely until it's delivered? 13:16 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 13:40 <*> Joins[#ac100] ->stuw [~stuw@2a02:2168:1674:e700:2c57:a078:9fc1:9db3] 13:43 < PaulFertser> stuw: hey :) can you probably help me understand nvec driver logic better? 13:44 < PaulFertser> I have hesitations wrt locking and retransmissions. 13:45 <*> Quits ->stuw [~stuw@2a02:2168:1674:e700:2c57:a078:9fc1:9db3] [Ping timeout: 250 seconds] 14:39 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 260 seconds] 15:00 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 15:06 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 15:26 <*> Joins[#ac100] ->nashpa [~nashpa@dliviu.plus.com] 15:41 <*> Joins[#ac100] ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] 15:45 <*> Quits ->stuw [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 245 seconds] 16:28 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 250 seconds] 16:43 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 17:03 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 245 seconds] 17:07 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 18:29 <*> Joins[#ac100] ->jbrown [~jules@2a02:c7d:8e9c:4500:2af1:eff:fe0e:8884] 19:08 <*> Quits ->damex [~damex@funtoo/dev/damex] [Read error: Connection reset by peer] 19:12 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 19:16 <*> Quits ->damex [~damex@funtoo/dev/damex] [Max SendQ exceeded] 19:17 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 19:29 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 256 seconds] 19:34 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 19:37 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 20:04 <*> Joins[#ac100] ->damex [~damex@funtoo/dev/damex] 20:07 < PaulFertser> stuw_: ayt? 20:08 < stuw_> PaulFertser, yes 20:08 < PaulFertser> stuw_: are you familiar with the current nvec driver? Can you please clarify some questions? 20:08 < stuw_> let's try 20:10 < PaulFertser> stuw_: so, I'm looking at nvec_request_master . What's supposed to happen after 5s timeout occurs there? Retransmission? What if the interrupt comes after wait_for_completion... at some different points of time, is it really not racy? 20:11 <*> Quits ->damex [~damex@funtoo/dev/damex] [Ping timeout: 260 seconds] 20:11 < stuw_> afair 5 is is a timeout for complete fail. Nvec should try to resend data multiple times. Per-message timeouts are shorter 20:11 < PaulFertser> stuw_: another question: why nvec_write_sync has a 2s timeout and not something more than 5s to align with that request_master code? 20:12 < stuw_> from 20 to 600 ms iirc 20:12 < stuw_> let me check datasheet 20:12 < stuw_> PaulFertser, do you have the TRM for NVEC ? 20:12 < PaulFertser> I'm asking about code architecture rather than specific values. 20:13 < PaulFertser> stuw_: yes 20:13 < PaulFertser> stuw_: nvec_suspend doesn't properly handle the result of nvec_write_sync so that's why suspend/resume sometimes fails. Do you need a proof? 20:14 < stuw_> I saw your message in the channel log :) 20:14 < PaulFertser> stuw_: also, nvec_toggle_global_events is async and that is not meaningful either for the suspend path. 20:14 < stuw_> yes, syn/async mess 20:15 < PaulFertser> stuw_: the thing is, after I started to handle nvec_write_sync return code properly I ended up with failing nvec_msg_alloc after few other attempts. 20:16 < PaulFertser> stuw_: i have a feeling the messages are not getting released properly in certain conditions. 20:16 < stuw_> I didn't finish adding debugging code. My filling is that messages are not removed if driver fails to send it. 20:16 < PaulFertser> stuw_: I've spent most of my lovely sunday trying to dig all this. And the more time I spent, the more messy it all seemed. 20:17 < PaulFertser> I'm even considering rewriting the core of the driver because I'm feeling more and more unhappy looking at it... 20:18 < stuw_> Yes. The problem with debugging is timings. I used ring buffer for 2int debugging values (time and msg code). Then I printed them outside of irc context. 20:18 < stuw_> PaulFertser, maybe it's a good idea to take my patches for upstream 20:18 < stuw_> I rewrote nvec handling 20:19 < stuw_> I think it looks much simpler in my patches 20:19 < PaulFertser> The irq state machine is still too complicated. Using numbers instead of meaningful names for the states isn't helping either. 20:19 < PaulFertser> stuw_: oh, and it wasn't merged? 20:19 < stuw_> of course my patches were not merged :) 20:19 < PaulFertser> Why of course? 20:20 < stuw_> because device tree was not ready and I failed to get proper decicion in time. 20:20 < PaulFertser> But DT is not necessary for staging code, or were you merging to mainline? 20:20 < stuw_> I still have no enough time for ac100 because of my main job 20:21 < stuw_> PaulFertser, I prepared patches to move i2c code to the tegra_i2c driver 20:21 < stuw_> to separate i2c and nvec logic 20:21 < PaulFertser> From encouraging talks on this channel I started to think nvec code is in a good enough shape nowadays... 20:22 < PaulFertser> l1 suspend seems really stable on Tegra2 level. But nvec as it is currently is really spoiling the fun, to say the least. 20:24 < stuw_> yes, nvec_interrupt is a little bit complex in current implementation 20:25 < stuw_> PaulFertser, https://patchwork.kernel.org/project/linux-arm-kernel/list/?submitter=121761 20:26 < stuw_> ah, and Wolfram failed to use my driver to read some i2c device using tegra (don't know exact version) 20:36 < PaulFertser> stuw_: ok, thanks for the link 22:18 < PaulFertser> stuw_: did anybody use an LA when working on NVEC? 22:24 < stuw_> PaulFertser, LA ? 22:26 < PaulFertser> stuw_: yes, a logic analyser, to see real over-the-wire data 22:27 < stuw_> PaulFertser, one moment 22:31 < stuw_> PaulFertser, https://paz00.ru/index.php/Nvec 22:31 < stuw_> scroll to bottom 22:33 < PaulFertser> stuw_: I see. So the answer is basically, someone did, but haven't figured out anything important to remove the odd delays and other strange artifacts from the code. 22:33 < PaulFertser> Right? 22:40 < PaulFertser> Reading that page makes me sadder. 22:45 < stuw_> I used LS. I tuned code to make delays shorter. I remember some difference in delays between original code and mine. But I don't remember if it was u-boot or kernel. 22:46 < stuw_> Also I didn't check suspend logic. My logic sniffer can't scan for a long time. 1-2 sec for 4MHz max IIRC 22:47 < stuw_> PaulFertser, basic timings are fine 22:47 < stuw_> Issue: huge delay between first and second bytes <-- this one is strance 22:49 < PaulFertser> stuw_: suspend logic is broken because the current nvec.c code is broken imho.. 22:50 < PaulFertser> It's not a problem with the timings or something like that. I think the driver is written the way that makes it fragile and too complex to be understandable, so some unusual conditions are mishandled. 22:51 < stuw_> PaulFertser, agree. We can try to make it more simple. 22:52 < PaulFertser> I might get some time off work (unpayed of course) then I might have enough energy to do something about it. But I'm depressed with the situation. And my OpenOCD work is stalled, and I guess people need OpenOCD more than I need this silly netbook :/ 22:53 < PaulFertser> stuw_: how much would I need to pay if I wanted to hire you to make lp1 suspend/resume as reliable as it is on any Tegra2 devboard? 22:55 < stuw_> PaulFertser, I'm not sure I can finish it :) My main job is not related to hardware. It's just a hobby 22:55 < stuw_> can==able 22:55 < PaulFertser> My main job is related, but I mostly do stm32 programming lately. 23:01 < stuw_> I hope that I can continue nvec preparation in late december. 23:07 < stuw_> PaulFertser, main problem with nvec - lack of debugging. It's not trivial to figure out why queue is full and driver can't allocate new packets without debugging. 23:36 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.nationalcablenetworks.ru] [Ping timeout: 244 seconds] --- Log closed Mon Oct 31 00:00:55 2016 --- Log opened Mon Oct 23 00:00:59 2017 00:29 <*> Parts[#ac100] ->toneeq [~toneeq@84.225.c10008-a53.dsl-dynamic.vsi.ru] [] 00:43 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 00:49 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 01:50 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 264 seconds] 03:36 <*> Parts[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] [] 07:33 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 08:17 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 240 seconds] 10:47 <*> Quits ->stuw2 [~stuw@31.44.80.66] [Ping timeout: 248 seconds] 10:58 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-yqqqbqfnstchhavv] 12:02 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 12:46 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 12:50 <*> Quits ->DanSwano [~danswano@109.234.34.139] [Ping timeout: 240 seconds] 15:01 <*> Joins[#ac100] ->stuw2 [~stuw@83.69.216.10] 15:01 <*> Quits ->stuw [~stuw@31.44.80.66] [Read error: Connection reset by peer] 15:02 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 15:05 <*> Quits ->stuw2 [~stuw@83.69.216.10] [Ping timeout: 264 seconds] 15:08 <*> Quits ->stuw [~stuw@31.44.80.66] [Remote host closed the connection] 15:09 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 15:13 <*> Quits ->stuw [~stuw@31.44.80.66] [Ping timeout: 248 seconds] 15:17 <*> Joins[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] 15:41 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 15:54 <*> Joins[#ac100] ->jbrown [~jules@mtrlpq4709w-lp140-02-65-93-224-29.dsl.bell.ca] 16:18 <*> Quits ->stuw [~stuw@31.44.80.66] [Remote host closed the connection] 16:19 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 18:36 <*> Quits ->stenzel [stenzel@nat/ibm/x-yqqqbqfnstchhavv] [Ping timeout: 264 seconds] 20:47 <*> Quits ->jbrown [~jules@mtrlpq4709w-lp140-02-65-93-224-29.dsl.bell.ca] [Ping timeout: 248 seconds] 21:58 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 22:10 <*> Quits ->tmn505 [~anon@155-133-15-140.interka.pl] [Remote host closed the connection] 22:10 <*> Joins[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] 23:52 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] --- Day changed Tue Oct 24 2017 00:07 <*> Joins[#ac100] ->jbrown [~jules@2605:8d80:583:7c86:f882:67b:2db0:9fa9] 00:52 <*> Quits ->jbrown [~jules@2605:8d80:583:7c86:f882:67b:2db0:9fa9] [Ping timeout: 252 seconds] 02:22 <*> Joins[#ac100] ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] 02:29 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 240 seconds] 03:28 <*> Parts[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] [] 05:35 <*> Quits ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] [Ping timeout: 252 seconds] 05:36 <*> Joins[#ac100] ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] 07:10 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 08:57 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 240 seconds] 10:54 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-zyickfylrrldvxha] 11:19 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 12:43 <*> Joins[#ac100] ->DanSwano [~danswano@109.234.34.139] 14:52 <*> Joins[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] 17:56 <*> Joins[#ac100] ->angeli [~root@178-37-205-178.adsl.inetia.pl] 17:56 < angeli> hello 17:56 < angeli> I tried to understand the status of 1GB RAM upgrade 17:57 < angeli> is this successful or not, please? 17:57 < angeli> paz00.ru is not very clear about it or I am too stupid to understand... 17:59 < angeli> uppsss I am root 17:59 < angeli> :D 17:59 < angeli> brb 17:59 <*> Quits ->angeli [~root@178-37-205-178.adsl.inetia.pl] [Client Quit] 17:59 <*> Joins[#ac100] ->agneli [~agneli@178-37-205-178.adsl.inetia.pl] 18:00 < agneli> back :) 18:09 < PaulFertser> agneli: stuw probably knows 18:39 < stuw> One guy re-soldered ram but we failed to get all 1gb working - system decides that only 512gb is installed (it's not trivial without serial console + forum is not very fast way to communicate) 18:43 <*> Quits ->stenzel [stenzel@nat/ibm/x-zyickfylrrldvxha] [Ping timeout: 240 seconds] 19:16 < agneli> thank stuw 19:16 < agneli> so basically we have no idea if it will work or not? 19:16 < agneli> + I understand that all chips listed on paz00.ru are OK? 19:17 < agneli> so I can solder them if I decide to try and then ensure I do have serial console connected :D 19:17 < agneli> an pray u have time? ;) 19:17 < agneli> an = and 19:20 < stuw> agneli: I don't know what chips are good and what are not. 19:21 < stuw> http://4pda.ru/forum/index.php?s=&showtopic=367318&view=findpost&p=59383097 (in russian) 19:24 < stuw> https://www.dropbox.com/s/yfvp68f8nb3i9xm/ac100_1gb_ram.jpg?dl=0 top (before), bottom (after) 19:28 < agneli> I have seen that, thank you 19:28 < agneli> are we like 75% sure this is just configuration issue? 19:31 < stuw> ¯\_(ツ)_/¯ 19:31 < stuw> I don't know 19:44 < agneli> hehehe OK 19:44 < agneli> thank you stuw! 19:44 < agneli> I will think about it 20:11 <*> Joins[#ac100] ->agneli_ [~agneli@178-37-205-178.adsl.inetia.pl] 20:14 <*> Quits ->agneli [~agneli@178-37-205-178.adsl.inetia.pl] [Ping timeout: 240 seconds] 22:34 <*> agneli_ is now known as agneli 22:57 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 23:56 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 248 seconds] --- Day changed Wed Oct 25 2017 00:15 <*> Quits ->agneli [~agneli@178-37-205-178.adsl.inetia.pl] [Ping timeout: 258 seconds] 00:27 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 00:31 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 00:50 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 240 seconds] 01:12 <*> Quits ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] [Ping timeout: 248 seconds] 01:14 <*> Joins[#ac100] ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] 01:21 <*> Quits ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] [Ping timeout: 248 seconds] 01:28 <*> Joins[#ac100] ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] 03:21 <*> Parts[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] [] 03:58 <*> Quits ->DanSwano [~danswano@109.234.34.139] [Ping timeout: 246 seconds] 03:59 <*> Joins[#ac100] ->DanSwano [~danswano@109.234.34.139] 06:01 <*> Quits ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] [Ping timeout: 248 seconds] 06:51 <*> Joins[#ac100] ->jbrown [~jules@mtrlpq4709w-lp140-02-65-93-224-29.dsl.bell.ca] 08:08 <*> Joins[#ac100] ->agneli [~agneli@178-37-152-180.adsl.inetia.pl] 08:16 <*> Quits ->jbrown [~jules@mtrlpq4709w-lp140-02-65-93-224-29.dsl.bell.ca] [Remote host closed the connection] 08:28 <*> Joins[#ac100] ->agneli_ [~agneli@178-37-199-69.adsl.inetia.pl] 08:31 <*> Quits ->agneli [~agneli@178-37-152-180.adsl.inetia.pl] [Ping timeout: 240 seconds] 10:39 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-qivwwauettmhujgx] 10:50 <*> Joins[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] 11:41 <*> Joins[#ac100] ->agneli [~agneli@77-253-183-25.adsl.inetia.pl] 11:44 <*> Quits ->agneli_ [~agneli@178-37-199-69.adsl.inetia.pl] [Ping timeout: 240 seconds] 11:49 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 12:43 <*> Parts[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] [] 16:01 <*> Joins[#ac100] ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] 16:04 <*> Joins[#ac100] ->agneli_ [~agneli@static-81-219-26-252.devs.futuro.pl] 16:07 <*> Quits ->agneli [~agneli@77-253-183-25.adsl.inetia.pl] [Ping timeout: 255 seconds] 17:15 <*> Joins[#ac100] ->stuw2 [~stuw@31.44.80.66] 17:15 <*> Quits ->stuw [~stuw@31.44.80.66] [Read error: Connection reset by peer] 17:17 <*> Joins[#ac100] ->agneli [~agneli@dynamic-87-105-244-202.ssp.dialog.net.pl] 17:20 <*> Quits ->agneli_ [~agneli@static-81-219-26-252.devs.futuro.pl] [Ping timeout: 240 seconds] 17:35 <*> stuw2 is now known as stuw 18:13 <*> Joins[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] 18:38 <*> Quits ->stenzel [stenzel@nat/ibm/x-qivwwauettmhujgx] [Ping timeout: 264 seconds] 20:58 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 21:42 <*> Joins[#ac100] ->agneli_ [~agneli@78.10.146.198] 21:45 <*> Quits ->agneli [~agneli@dynamic-87-105-244-202.ssp.dialog.net.pl] [Ping timeout: 246 seconds] 23:51 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 240 seconds] --- Day changed Thu Oct 26 2017 00:18 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 00:20 <*> Quits ->agneli_ [~agneli@78.10.146.198] [Ping timeout: 252 seconds] 03:46 <*> Parts[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] [] 04:31 <*> Quits ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] [Ping timeout: 258 seconds] 08:04 <*> Joins[#ac100] ->agneli [~agneli@178-37-154-166.adsl.inetia.pl] 09:58 <*> Joins[#ac100] ->stuw2 [~stuw@31.44.80.66] 09:58 <*> Quits ->stuw [~stuw@31.44.80.66] [Read error: Connection reset by peer] 11:02 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 11:04 <*> Quits ->stuw2 [~stuw@31.44.80.66] [Ping timeout: 240 seconds] 11:15 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-ivosvfubhsnnxzfg] 11:34 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 11:44 <*> Quits ->DanSwano [~danswano@109.234.34.139] [Remote host closed the connection] 13:06 <*> Joins[#ac100] ->DanSwano [~danswano@109.234.34.139] 13:26 <*> Quits ->indy [~indy@shadow.kastnerove.cz] [Ping timeout: 240 seconds] 13:32 <*> Joins[#ac100] ->indy [~indy@shadow.kastnerove.cz] 13:44 <*> Joins[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] 13:58 <*> Quits ->stuw [~stuw@31.44.80.66] [] 16:02 <*> Quits ->tmn505 [~anon@155-133-15-140.interka.pl] [Ping timeout: 260 seconds] 16:10 <*> Joins[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] 16:28 <*> Joins[#ac100] ->marvin24_ [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 16:29 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Ping timeout: 255 seconds] 16:31 <*> Quits ->marvin24_ [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 16:32 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 18:21 <*> Quits ->stenzel [stenzel@nat/ibm/x-ivosvfubhsnnxzfg] [Ping timeout: 255 seconds] 19:39 <*> Joins[#ac100] ->jbrown [~jules@mtrlpq4709w-lp140-02-65-93-224-29.dsl.bell.ca] 20:40 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 23:17 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 240 seconds] 23:56 <*> Quits ->agneli [~agneli@178-37-154-166.adsl.inetia.pl] [Ping timeout: 255 seconds] --- Day changed Fri Oct 27 2017 01:12 <*> Parts[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] [] 01:12 <*> Joins[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] 01:55 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 03:30 <*> Quits ->tmn505 [~anon@155-133-15-140.interka.pl] [Quit: tmn505] 03:35 <*> Quits ->pranza [pranza@pranza.audiomastering.lt] [Ping timeout: 258 seconds] 04:05 <*> Quits ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] [Ping timeout: 248 seconds] 07:26 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 08:12 <*> Joins[#ac100] ->agneli [~agneli@178-37-154-166.adsl.inetia.pl] 08:14 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 248 seconds] 08:52 <*> Quits ->jbrown [~jules@mtrlpq4709w-lp140-02-65-93-224-29.dsl.bell.ca] [Ping timeout: 240 seconds] 10:08 <*> Joins[#ac100] ->nchauvet [~nchauvet@LFbn-MAR-1-466-201.w2-15.abo.wanadoo.fr] 11:07 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-amgpvlxwgtnqwnrd] 11:23 <*> Joins[#ac100] ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] 12:04 <*> Quits ->nchauvet [~nchauvet@LFbn-MAR-1-466-201.w2-15.abo.wanadoo.fr] [Ping timeout: 240 seconds] 12:17 <*> Quits ->DanSwano [~danswano@109.234.34.139] [Ping timeout: 246 seconds] 12:26 <*> Joins[#ac100] ->DanSwano [~danswano@109.234.34.139] 12:31 <*> Joins[#ac100] ->stuw [~stuw@31.44.80.66] 12:38 <*> Joins[#ac100] ->norly [~norly@enpas.org] 12:38 <*> Parts[#ac100] ->norly [~norly@enpas.org] ["JOIN #azubi"] 12:40 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 14:08 <*> Joins[#ac100] ->tmn505 [~anon@155-133-15-140.interka.pl] 15:53 <*> Joins[#ac100] ->jbrown [~jules@mtrlpq4709w-lp140-02-65-93-224-29.dsl.bell.ca] 16:10 <*> Quits ->stenzel [stenzel@nat/ibm/x-amgpvlxwgtnqwnrd] [Remote host closed the connection] 16:12 <*> Joins[#ac100] ->stenzel [stenzel@nat/ibm/x-rxhwqyuthaxqdpfv] 18:34 <*> Quits ->stenzel [stenzel@nat/ibm/x-rxhwqyuthaxqdpfv] [Ping timeout: 240 seconds] 23:30 <*> Quits ->agneli [~agneli@178-37-154-166.adsl.inetia.pl] [Ping timeout: 255 seconds] --- Day changed Sat Oct 28 2017 00:10 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 01:49 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Remote host closed the connection] 01:59 <*> Joins[#ac100] ->tmn505_ [tmn505@odin.sdf-eu.org] 02:00 <*> Quits ->tmn505 [~anon@155-133-15-140.interka.pl] [Quit: tmn505] 02:26 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 260 seconds] 04:04 <*> Quits ->tmn505_ [tmn505@odin.sdf-eu.org] [Quit: leaving] 08:42 <*> Quits ->jbrown [~jules@mtrlpq4709w-lp140-02-65-93-224-29.dsl.bell.ca] [Remote host closed the connection] 10:32 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 12:00 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 13:51 <*> Joins[#ac100] ->tmn505 [tmn505@odin.sdf-eu.org] 14:06 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Read error: Connection reset by peer] 14:07 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 16:09 <*> Quits ->tmn505 [tmn505@odin.sdf-eu.org] [Quit: leaving] 16:10 <*> Joins[#ac100] ->tmn505 [tmn505@odin.sdf-eu.org] 16:11 <*> Quits ->tmn505 [tmn505@odin.sdf-eu.org] [Client Quit] 16:11 <*> Joins[#ac100] ->tmn505 [tmn505@odin.sdf-eu.org] 16:51 <*> Quits ->tmn505 [tmn505@odin.sdf-eu.org] [Quit: leaving] 16:52 <*> Joins[#ac100] ->tmn505 [tmn505@odin.sdf-eu.org] 16:54 <*> Quits ->tmn505 [tmn505@odin.sdf-eu.org] [Client Quit] 16:55 <*> Joins[#ac100] ->tmn505 [tmn505@odin.sdf-eu.org] 17:41 <*> Quits ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] [Remote host closed the connection] 17:43 <*> Joins[#ac100] ->marvin24 [~quassel@egonalter-2-pt.tunnel.tserv6.fra1.ipv6.he.net] 18:12 <*> Joins[#ac100] ->agneli [~agneli@178-37-154-166.adsl.inetia.pl] 18:17 <*> Joins[#ac100] ->jbrown [~jules@206.108.186.141] 19:19 <*> Quits ->tmn505 [tmn505@odin.sdf-eu.org] [Quit: leaving] 19:37 <*> Joins[#ac100] ->tmn505 [tmn505@odin.sdf-eu.org] 21:17 <*> Quits ->jbrown [~jules@206.108.186.141] [Ping timeout: 246 seconds] --- Day changed Sun Oct 29 2017 00:22 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 240 seconds] 00:30 <*> Quits ->agneli [~agneli@178-37-154-166.adsl.inetia.pl] [Ping timeout: 240 seconds] 01:27 <*> Joins[#ac100] ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] 02:07 <*> Quits ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] [Quit: Quitte] 02:40 <*> Quits ->tmn505 [tmn505@odin.sdf-eu.org] [Quit: leaving] 07:29 <*> Quits ->jbrown [~jules@bas7-montreal02-65-93-224-29.dsl.bell.ca] [Ping timeout: 248 seconds] 09:10 <*> Joins[#ac100] ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] 09:57 <*> Quits ->indy [~indy@shadow.kastnerove.cz] [Quit: ZNC - http://znc.sourceforge.net] 10:26 <*> Quits ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] [Ping timeout: 255 seconds] 10:27 <*> Joins[#ac100] ->ogra_ [~ogra_@p5098ed03.dip0.t-ipconnect.de] 11:08 <*> Joins[#ac100] ->indy [~indy@shadow.kastnerove.cz] 12:21 <*> Joins[#ac100] ->gouchi [~gouchi@ivr94-8-88-162-27-162.fbx.proxad.net] 21:43 <*> Quits ->p2-mate [~p2@emantra.psychaos.be] [Ping timeout: 246 seconds] 21:57 <*> Joins[#ac100] ->p2-mate [~p2@emantra.psychaos.be] 23:38 <*> Quits ->stuw_ [~stuw@broadband-178-140-64-215.moscow.rt.ru] [Ping timeout: 248 seconds] --- Log closed Mon Oct 30 00:00:09 2017 --- Log opened Mon Oct 22 00:00:50 2018 --- Log closed Mon Oct 29 00:00:05 2018 --- Log opened Mon Oct 28 00:00:06 2019 --- Log closed Mon Nov 04 00:00:16 2019 --- Log opened Mon Oct 26 00:00:25 2020 --- Log closed Mon Nov 02 00:00:34 2020 --- Log opened Mon Oct 25 00:00:45 2021 --- Log closed Mon Nov 01 00:00:55 2021 --- Log opened Mon Oct 24 00:00:48 2022 --- Log closed Mon Oct 31 00:00:58 2022