freemangordon | uvos__: I think the same charge-mode bug appeared. LED is green, but battery on the screen has just one thin red line and nothing happens | 16:48 |
---|---|---|
freemangordon | it seems this happens only after batter was so empty that mce shut it down | 16:50 |
freemangordon | any hint how to debug? | 16:50 |
freemangordon | if I disconnect the charger, it shuts down | 16:52 |
freemangordon | is it possible that it tries to open the battery sys node only once? | 16:53 |
freemangordon | after reboot it displayed half battery | 16:53 |
freemangordon | hmm, could be related to charger driver | 17:10 |
freemangordon | no, this is different issue (ke-recv unbinding musb-hdrc causing it to send 0mA allowed current) | 17:27 |
freemangordon | Wizzup: any idea what's going on here https://pastebin.com/982WS9T9 ? | 17:36 |
freemangordon | this happens on boot with USB cable connected to PC | 17:36 |
Wizzup | freemangordon: what about it? | 17:56 |
freemangordon | it remains disconnected | 17:57 |
freemangordon | so if you boot with cable attached neither charging nor usb0 work | 17:58 |
freemangordon | until you detach/attach the cable | 17:58 |
freemangordon | will provide le-recv log in a minute | 17:58 |
freemangordon | *ke-recv | 17:59 |
freemangordon | Wizzup: https://pastebin.com/S7Tuxwy5 | 18:01 |
Wizzup | is kernel in the right state? | 18:02 |
freemangordon | what do you mean? | 18:02 |
freemangordon | what to check? | 18:02 |
Wizzup | well, ke-recv just follows kernel/udev state | 18:02 |
freemangordon | sure, but how is that state set? | 18:02 |
Wizzup | by kernel/drivers I think? | 18:03 |
freemangordon | where? | 18:03 |
Wizzup | I don't know | 18:03 |
freemangordon | what to verify | 18:03 |
Wizzup | I would check some /sys | 18:03 |
freemangordon | ah | 18:03 |
Wizzup | or maybe udevadm can tell you | 18:03 |
freemangordon | yeah, /sys it is, but which one? | 18:03 |
Wizzup | or whatever the things is to query uevent files of specific /sys | 18:03 |
Wizzup | hmm, probably the usb and battery, let me check | 18:03 |
freemangordon | ok, but which one? | 18:03 |
freemangordon | usb power supply: POWER_SUPPLY_STATUS=Not charging | 18:04 |
Wizzup | https://github.com/maemo-leste/ke-recv/blob/master/src/udev-helper.c#L118 | 18:04 |
freemangordon | what does it expect from battery? | 18:04 |
freemangordon | and actually we *can* read the mode from extcon ;) | 18:05 |
Wizzup | https://github.com/maemo-leste/ke-recv/blob/master/src/udev-helper.c#L170 | 18:05 |
Wizzup | well at the time of writing I don't think the extcon was working | 18:05 |
Wizzup | this is mostly used for triggers | 18:05 |
Wizzup | https://github.com/maemo-leste/ke-recv/blob/master/src/udev-helper.c#L200 | 18:05 |
freemangordon | hmm, where is that 'type' located, lemme try to find it | 18:06 |
freemangordon | ah | 18:06 |
freemangordon | in usb: POWER_SUPPLY_TYPE=USB | 18:06 |
freemangordon | Wizzup: also, what about "USB_SDP"? | 18:07 |
Wizzup | maybe we need to add it? | 18:07 |
freemangordon | shall I start ke-recv from console to see what will it say? | 18:08 |
Wizzup | https://github.com/maemo-leste/ke-recv/blob/master/src/udev-helper.h#L26 | 18:08 |
Wizzup | sure | 18:08 |
freemangordon | Probing for drivers for Nokia N900 | 18:09 |
freemangordon | Cannot find supply for Nokia N900 | 18:09 |
freemangordon | Probing for drivers for LIME2 | 18:09 |
freemangordon | Found supply | 18:09 |
freemangordon | Found otg | 18:09 |
freemangordon | that's all | 18:09 |
freemangordon | Wizzup: but, even with wall charger connected (DCP) it is the same | 18:09 |
freemangordon | otg mode is b_idle | 18:11 |
freemangordon | in /sys/module/musb_hdrc/drivers/platform:musb-hdrc/musb-hdrc.2.auto | 18:11 |
freemangordon | Wizzup: umm... | 18:14 |
freemangordon | https://github.com/maemo-leste/ke-recv/blob/master/src/udev-helper.c#L131 | 18:14 |
freemangordon | why is that battery? | 18:14 |
freemangordon | shouldn't that be "usb"? | 18:14 |
freemangordon | also, on init update_info() is not called | 18:16 |
freemangordon | is that by design? | 18:16 |
Wizzup | dinner at, back in a bit | 18:17 |
freemangordon | ok | 18:18 |
Wizzup | freemangordon: I think it's probably good to call it on init | 18:55 |
Wizzup | freemangordon: maybe because of your new kernel patch it mistakes it for a lime | 18:55 |
Wizzup | that's what it looks like to me | 18:55 |
freemangordon | because of extcon? | 19:11 |
freemangordon | ok, there is /sys/class/extcon/extcon0 | 19:15 |
freemangordon | BTW, why do we care which device is that? | 19:16 |
freemangordon | I think if we have extcon, we should not care about otg at all | 19:16 |
freemangordon | but just enumerate extconN and try to find USB_XXX cables | 19:17 |
freemangordon | unless I am missing something | 19:17 |
freemangordon | what I didn't get though, is shall I set USB cable state to on if it is DCP port | 19:19 |
Wizzup | You can try to make it generic if you want, I found that a big challenge | 19:19 |
Wizzup | on some devices, certain things didn't trigger in udev | 19:19 |
freemangordon | sure, just tell me what we need to detect | 19:20 |
freemangordon | I have allwinner here as well | 19:20 |
freemangordon | so I can test there too | 19:20 |
freemangordon | it is also good testbed because it can charge from either USB or dedicated port | 19:21 |
freemangordon | just tell me what needs to be detected | 19:21 |
Wizzup | the tablet should be similar to lime2 I think | 19:21 |
freemangordon | mhm | 19:21 |
Wizzup | although I suppose the lime has no battery typiclaly | 19:21 |
Wizzup | while you may have one | 19:22 |
freemangordon | yes | 19:22 |
Wizzup | anyway I think my idea was to just add some things to this list until we found a more generic way | 19:22 |
Wizzup | given that it now finds your d4 to be a lime2, I think it's related to the kernel changes | 19:22 |
freemangordon | ok, but what do you need detected? USB cable? | 19:22 |
freemangordon | and not host? | 19:22 |
Wizzup | I think so, yes | 19:22 |
Wizzup | I don't know what DCP is to be honest | 19:22 |
freemangordon | Dedicated Charger Port | 19:23 |
freemangordon | wall charger | 19:23 |
freemangordon | SDP is Standard Downstream Port or USB 2.0 port, IIUC | 19:24 |
freemangordon | Charging Downstream Port or CDP is some USB2.0 that is able to provide up to 900mA | 19:24 |
freemangordon | but I don;t know how is that detected | 19:24 |
freemangordon | seems some game with D+/D- voltages is required | 19:26 |
Wizzup | I think that for those we don't want to show the dialog | 19:26 |
Wizzup | or load a gadget, really, unless we need to have one loaded | 19:27 |
Wizzup | of course we could have it show some icon for dedicated wall charger | 19:27 |
freemangordon | we need to have gadget loaded for USB/SDP only | 19:27 |
tmlind | freemangordon: fyi, because of commit 1ec92e974277 ("tty: n_gsm: fix decoupled mux resource"), there's a double free now in maemo-5.18.y kernel tree.. kfree in gsm_serdev_unregister_device() should be removed | 19:27 |
tmlind | last kref release already takes care of it | 19:28 |
tmlind | otherwise unloading serdev-ngsm will cause random oopses | 19:28 |
freemangordon | umm, why do you tell that to me? | 19:28 |
freemangordon | you want me to make a patch? | 19:28 |
freemangordon | I mean - I don;t object | 19:29 |
tmlind | rebasing stuff on v6.1-rc tree | 19:29 |
freemangordon | just don;t understand what am I required to do :) | 19:29 |
tmlind | and noticed this and you have patches applied on top in maemo-5.18.y :) | 19:29 |
freemangordon | ok | 19:29 |
freemangordon | tmlind: any idea why is sre so quiet? | 19:30 |
tmlind | yeah a patch to drop that kfree would be good to apply | 19:30 |
tmlind | i think sre is overly busy with work | 19:30 |
freemangordon | ah | 19:30 |
freemangordon | also, did you understand what greg wanted me to do i his comment re [PATCH] usb: phy: add dedicated notifier for charger events? | 19:31 |
freemangordon | sometimes reviews are so fuzzy... | 19:31 |
freemangordon | what is "notifier type"? | 19:32 |
freemangordon | sorry for pestering you, but I don't know whom else to ask | 19:32 |
freemangordon | this https://www.spinics.net/lists/linux-usb/msg233507.html | 19:33 |
freemangordon | Wizzup: so, the plan is: if there is extcon, use it, otherwise fallback to device-specific matching, ok? | 19:35 |
freemangordon | I think we will only need 'hack' for n900 | 19:36 |
freemangordon | Wizzup: also, what that note is supposed to mean? https://github.com/maemo-leste/ke-recv/blob/master/src/udev-helper.c#L91 | 19:36 |
Wizzup | sounds like the mode doesn't trigger udev | 19:39 |
Wizzup | kernel needs to do things to trigger | 19:39 |
Wizzup | not all drivers do this | 19:39 |
tmlind | freemangordon: maybe he just wants the event type there for the notifier? see include/linux/device/bus.h for BUS_NOTIFY_ADD_DEVICE and other events for example | 19:40 |
tmlind | so a single notifier but with multiple event types | 19:40 |
freemangordon | and data parameter type to depend on event type? yeah, that would work | 19:41 |
freemangordon | but it would have been good if he stated that in a clear form :( | 19:41 |
tmlind | yeah i think that's what he means :) | 19:42 |
freemangordon | toldya it's fuzzy :) | 19:42 |
freemangordon | I'll wait some time for a follow-up and will send v2 if there is none | 19:43 |
tmlind | yeah ok | 19:43 |
tmlind | freemangordon: rebased your n_gsm patches to v6.1-rc5 fyi, i'll fold in your audio timeout change, ok? | 20:00 |
tmlind | looks like at least one fix is needed to more patches from daniel now merged, need to test a bit more | 20:00 |
tmlind | hmm still seeing audio timeout errors for 4806a000.serial:modem:audio-codec@2.. | 20:02 |
freemangordon | timeout patch is needed for sure | 20:03 |
tmlind | maybe i just need to reboot as i did not scp over the updated audio module :) | 20:03 |
freemangordon | :) | 20:04 |
freemangordon | Wizzup: https://pastebin.com/fG4L4u1R | 20:05 |
freemangordon | unplug/plug wall charger | 20:05 |
freemangordon | looks ok to me | 20:05 |
tmlind | freemangordon: i think the real fix for the n_gsm initial timeouts would be to add deferred probe support to ohci-platform so phy-mapphone-mdm6600 won't init the phy until it's functional.. and then serdev-ngsm could wait for the phy too.. no luck trying to use serdev_device_wait_for_cts() to check when it might work | 20:06 |
freemangordon | hmm, yeah | 20:08 |
Wizzup | uvos__: I have bt working on my hyundai i30 | 21:37 |
Wizzup | audio sink and events work | 21:37 |
Wizzup | i got PLAY_CD | 21:37 |
Wizzup | mpv plays | 21:37 |
buZz | w00t | 21:51 |
buZz | :) finally some internet again, my landlord cancelled the isp and 'forgot' to tell me | 21:51 |
Wizzup | calls also worked | 21:52 |
Wizzup | I mean | 21:52 |
Wizzup | no audio | 21:52 |
Wizzup | but ofono+bluez did the right thing | 21:52 |
Wizzup | the car went into calling mode | 21:52 |
Wizzup | freemangordon: ^^ | 21:52 |
buZz | hahah cool | 21:52 |
buZz | using blueman? or straight up bluetoothctl | 21:52 |
Wizzup | combination | 21:53 |
Wizzup | blueman has weird settings | 21:53 |
Wizzup | and also I had to set the class of the device to "phone" | 21:53 |
Wizzup | otherwise the car would not see it | 21:54 |
Wizzup | so I dumped bluetooth info of my gf's android phone | 21:54 |
buZz | ah, are those binary blobs? | 21:54 |
Wizzup | no, just reading it from my d4 | 21:54 |
Wizzup | sudo hciconfig hci0 class 005a020c | 21:55 |
Wizzup | blueman resets it by making it non discoverable and some other stuff | 21:55 |
Wizzup | anyway I think this can be configured.. | 21:55 |
Wizzup | most of the time went into figuring out that the car won't play music over bt when a usb stick is plugged in | 21:55 |
Wizzup | still crackles though. | 21:56 |
buZz | even if you disable wifi? | 21:56 |
freemangordon | nice | 21:56 |
Wizzup | with ifconfig? didn't try | 21:56 |
Wizzup | but I was not connected to any wifi | 21:56 |
Wizzup | freemangordon: my h-d is now messed up (smaller), anything I can do to debug/dump info? | 22:13 |
Wizzup | I think I have debug on in x, but I think it's a h-d thing | 22:13 |
Wizzup | another interesting side effect is that it only redraws the screen on some action, like, when I touch it again | 22:15 |
Wizzup | again, this is an old bug even fremantle has | 22:15 |
Wizzup | I can try to rotate my phone | 22:16 |
Wizzup | rotating rotates hildon-home but not hildon-desktop or xrandr it seems | 22:16 |
buZz | Wizzup: or with that wifidisable statusmenu plugin | 22:19 |
buZz | but ifconfig down should be fine yeah | 22:19 |
buZz | i think the crackles are just the wifi trying to scan for stuff, maybe i could scan the wifi externally a bit | 22:20 |
buZz | s/scan/sniff/ | 22:20 |
freemangordon | Wizzup: yes, I know that bug, but it is so rare that I don;t think we'll be able to fix it | 22:23 |
Wizzup | I have it no | 22:23 |
Wizzup | now | 22:23 |
freemangordon | yes, but I have no diea where to look in | 22:25 |
freemangordon | *idea | 22:25 |
freemangordon | maybe try to enable h-d debug | 22:26 |
freemangordon | SIGUSR1 or SIGUSR2 | 22:26 |
* freemangordon checks | 22:26 | |
freemangordon | Wizzup: send SIGUSR1 to hildon-dekstop | 22:27 |
freemangordon | https://github.com/maemo-leste/hildon-desktop/blob/master/src/main.c#L380 | 22:28 |
Wizzup | ok, and how do I capture stederr? | 22:28 |
Wizzup | stderr* | 22:28 |
Wizzup | freemangordon: so the not-launcher pid, yeah? | 22:29 |
Wizzup | to the* | 22:29 |
Wizzup | user 3736 0.0 0.0 1636 844 ? Ss 20:29 0:00 /usr/bin/hildon-desktop | 22:29 |
freemangordon | yeah | 22:29 |
Wizzup | user 3739 0.7 3.9 98472 40008 ? Ssl 20:29 0:55 /usr/bin/hildon-desktop | 22:29 |
freemangordon | why stderr? | 22:29 |
freemangordon | 3739 | 22:29 |
Wizzup | how do I watch debug? | 22:29 |
freemangordon | should be in syslog | 22:29 |
Wizzup | which file? | 22:29 |
freemangordon | /var/log/syslog | 22:30 |
Wizzup | I just see cron there | 22:30 |
freemangordon | well, no idea what happens if G_MESSAGES_DEBUG is not set | 22:30 |
Wizzup | probably nothing :( | 22:30 |
freemangordon | glib that is | 22:30 |
freemangordon | attach gdb | 22:31 |
freemangordon | not that I know what to do there :) | 22:31 |
buZz | Wizzup: capture stderr is 2> bla.log | 22:32 |
freemangordon | buZz: already running process | 22:33 |
Wizzup | [ 6231.717] (II) OMAP(0): drmmode_reallocate_scanout:1193 restoring CRTCs | 22:33 |
Wizzup | [ 6231.717] (II) OMAP(0): drmmode_reallocate_scanout:1197 restore CRTC 1 | 22:33 |
Wizzup | [ 6231.717] (II) OMAP(0): drmmode_restore_crtc:273 create framebuffer: 960x540 | 22:33 |
Wizzup | [ 6231.717] (EE) OMAP(0): ERROR: failed to set mode: Invalid argument | 22:33 |
Wizzup | [ 6231.717] (EE) OMAP(0): ERROR: failed to reconfig crtc 1 | 22:33 |
Wizzup | [ 6231.978] (II) OMAP(0): drmmode_set_mode_major:406: Exiting | 22:33 |
Wizzup | maybe this is it | 22:33 |
freemangordon | that's ok | 22:33 |
buZz | oh, eh, dont know :P | 22:33 |
Wizzup | ok, maybe not | 22:34 |
freemangordon | Wizzup: looks like some GL transformation matrix is wrong | 22:34 |
Wizzup | I think it happened when I rotated the device during unlock | 22:34 |
freemangordon | if you find a way to repro that'd be cool | 22:34 |
freemangordon | but, as you said, even fremantle suffers from that bug | 22:34 |
freemangordon | I was never able to find any sane way to track or repro | 22:35 |
Wizzup | G_MESSAGES_DEBUG=all ? | 22:35 |
freemangordon | mhm | 22:35 |
freemangordon | but, how would you set that to a running process? | 22:35 |
Wizzup | I didn't, I killed it | 22:36 |
Wizzup | hoping it would re-appear | 22:36 |
Wizzup | but nope | 22:36 |
Wizzup | I suppose I could have made a core dump... | 22:36 |
freemangordon | looks like a bug in some tidy class | 22:37 |
freemangordon | or in clutter itself | 22:38 |
freemangordon | anyway, zzz time, night! | 22:38 |
buZz | nn | 22:38 |
sicelo | < freemangordon> I think we will only need 'hack' for n900 -- what is it missing? extcon? | 22:47 |
uvos | it appears i was unbanned | 23:34 |
uvos | great | 23:34 |
Wizzup | hi | 23:43 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!