--- Log for 22.04.121 Server: tepper.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 17 hours and 52 minutes ago 00.10.01 Join daswf852 [0] (~daswf852@unaffiliated/dwf) 00.17.31 *** Saving seen data "./dancer.seen" 01.00.05 Nick mendel_munkis_ is now known as mendel_munkis (~mendelmun@ool-43568247.dyn.optonline.net) 01.26.27 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:6cf4:e88:37b3:4460) 01.30.55 Quit ZincAlloy (Ping timeout: 260 seconds) 01.36.53 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:6cf4:e88:37b3:4460) 01.41.07 Quit ZincAlloy (Ping timeout: 250 seconds) 01.54.04 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 01.58.48 Quit ZincAlloy (Ping timeout: 265 seconds) 02.04.30 Join nihilazo [0] (e33ac355b6@198.108.76.81) 02.17.34 *** Saving seen data "./dancer.seen" 02.18.20 Join petur [0] (~petur@199.59.5.11) 02.18.20 Quit petur (Changing host) 02.18.20 Join petur [0] (~petur@rockbox/developer/petur) 02.26.10 Quit bluebrother (Remote host closed the connection) 02.33.42 Quit ecs (Remote host closed the connection) 02.33.58 Join ecs [0] (esawady@sourcehut/interns/ecs) 02.41.32 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 02.42.14 Join fs-bluebot [0] (~fs-bluebo@55d4bc24.access.ecotel.net) 02.50.53 Quit edhelas (Remote host closed the connection) 03.56.27 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 04.16.03 Quit S|h|a|w|n (Quit: Leaving) 04.17.37 *** Saving seen data "./dancer.seen" 05.07.22 Quit petur (Quit: Connection reset by beer) 05.36.47 Quit Acou_Bass (Ping timeout: 265 seconds) 05.49.37 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 06.01.13 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 06.17.38 *** Saving seen data "./dancer.seen" 07.09.22 # huh, the ipod6g with the shutdown issue has an ssd that claims to support ATA power management. 07.11.30 # identifies itself as "CF card" 07.15.51 # I suspect the fix is still to disable power management commands, but we'll need a different heuristic. 07.32.23 # the backlight shouldn't block anything... 07.45.39 # speachy: it sounds more and more like these pretend CF cards don't properly implement ATA 07.46.00 # i've never seen issues like this with true CF cards 07.46.55 # no idea. 07.46.57 # i wonder if we could use the same approach the LK uses 07.47.06 # and that is? 07.47.25 # lists of devices known to not do something properly to disable stuff selectively 07.47.35 # they use hard-coded tables for crap like this 07.48.03 # (I tossed out a build that completely disables power management in the ipod6g's ata driver to see if that will matter) 07.48.21 # if the iFlash adapters identify themselves in the ATA info we could selectively enable workaronds 07.48.54 # assuming no better solution is found 07.49.03 # there's a _lot_ of stuff out there that uses the same ATA->SD chipset not made by iflash. 07.49.20 # i know. 07.49.36 # but should we punish everyone by disabling PM? 07.49.39 # nothing consistent I can use to generate a heuristic yet 07.49.56 # or here's an idea 07.50.04 # would making it a menu option workaround be viable? 07.50.49 # that way we can let the user choose what they want to use 07.57.23 # speachy: oh, this user on forums. they're using the extensions I added to disk info? 07.59.08 # ... wow a bit of an attitude this one has 07.59.10 # o.O 08.04.51 # I mean, not much I can do when my ISP has a major outage. heh. 08.10.28 # I'm loathe to add a menu option for this but.. might be prudent. 08.17.39 *** No seen item changed, no save performed. 08.17.56 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-5545-1de4-4b23-f8cd.res6.spectrum.com) 08.19.31 Quit Saijin_Naib_ (Ping timeout: 245 seconds) 08.31.53 # speachy: simplest option without adding a ton of dynamic code heuristics 08.32.10 # making it user selectable, defaulting to whichever is better for stability 08.33.24 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 08.35.21 Quit speachy (Ping timeout: 245 seconds) 08.47.44 Join speachy [0] (~speachy@209.2.65.77) 08.48.52 # hmm.. another possibility 08.49.00 # we don't actually ever issue a FLUSH CACHE command 08.56.02 # speachy: doesn't sound like something we need to do normally 08.56.05 # but 08.56.09 # when going to sleep? 08.56.14 # yea probably a good idea 08.56.17 # exactly 08.56.23 # or shutdown 08.56.29 # we can combine with a timeout 08.56.30 # I think with spinning rust it's sort of implied 08.56.32 # or wait period 08.56.35 # that when you sleep you flush things 08.56.37 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 08.57.07 # doesn't matter for any read buffers 08.57.07 # but god knows what these wonky CF/SD adapters actually implement 08.57.16 # one way to find out 08.57.24 # the scientific method :D 08.58.41 # speachy: wouldn't it be funny if the problem was due to us forgetting to perform the ATA equivalent of fflush? 09.01.10 # huh, typo in the ATA-8 specification. 09.01.53 # from the spec it sounds like this should be safe to issue on all targets before we're preparing to shutdown or so 09.02.45 # it was added in ATA-4 09.03.14 # so if the device advertises support for it we should probably use it sometimes 09.03.49 # another possibility is to completely disable powersaving stuff for anything that identifies itself as a CF card. 09.03.59 # (or CFA-compliant, more accurately..) 09.04.06 Quit massiveH (*.net *.split) 09.04.06 Quit Acou_Bass (*.net *.split) 09.04.06 Quit Rower (*.net *.split) 09.04.06 Quit kugel (*.net *.split) 09.04.18 # via that bit I added to disk info? 09.04.29 # dunno. Just going by the spec here 09.04.50 # I added those checks mostly as some extra info for users. 09.04.54 # all of the dumps I have from the SD->CF thingeys advertise themselves as such 09.05.04 # you mean as 09.05.21 # CF compatible, not Fixed, Removeable? 09.05.33 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.05.33 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 09.05.33 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 09.05.33 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.05.39 # that's what real CF cards do, most of the time 09.05.41 # 0x848a in the first word of the identify info 09.05.49 # also bit 2 of word 83 09.05.56 # (treated as equivalent in the spec) 09.06.02 # I see. 09.06.17 # I know some things cared about the fixed bit and such 09.06.40 # maybe we should look at what Linux does for CF cards connected to an IDE bus 09.06.51 # but, heh, CFA also mandates SLEEP support. :D 09.07.01 Quit Rower (Ping timeout: 245 seconds) 09.07.11 # let's not disable PM just yet 09.07.23 # last resort in my book 09.07.23 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 09.07.34 # (this is the iflash-quad-on-ipod-video issue, not the lcd stuck-on on the 6g) 09.07.42 # i know 09.07.48 # ATA should have nothing to do with the LCD issue 09.08.23 # actually I suspect the lcd-stuck-on might be entirely due to LCD settings; maybe the user configured it to stay on permanently, and the shutdown code can't handle that. 09.08.38 # well during shutdown we should turn it off anyway 09.09.01 # but -- the lcd isn't shut down until after the disk is shut down. 09.09.02 # assuming that's even the issue 09.09.11 # and that can block forever 09.09.29 # well at least until the battery dies 09.09.31 # :D 09.09.40 # or our sun engulfs the planet 09.09.51 # lol 09.13.14 # the ipod6g ata driver doesn't use CMD_SLEEP, it uses CMD_STANDBY_IMMEDIATE 09.13.59 # without checking to see if it's supported, I might add. 09.14.07 # we could also be dealing with stupid hardware / firmware that won't flush unless ordered to 09.16.31 # maybe that's why this problem doesn't seem to be reported on the 6g series. 09.16.58 # standby_immediate causes a cache flush 09.17.16 # interesting. 09.20.49 # standby isn't as deep as sleep 09.20.58 # so sleep implies flushing caches too 09.24.07 # <_bilgus> bahus on the forums posted about a 3rd party fat32 formatter that appears to be just the ticket for these windows users http://ridgecrop.co.uk/index.htm?guiformat.htm 09.24.41 # <_bilgus> reading the writeup on the cli version http://ridgecrop.co.uk/index.htm?guiformat.htm 09.25.29 # <_bilgus> http://ridgecrop.co.uk/fat32format.htm 09.25.33 # <_bilgus> rather 09.26.19 # oh that's good 09.26.26 # <_bilgus> anyway I never realized the sector size would be so important in the size of the FAT table 09.27.14 # <_bilgus> I mean DUH 09.27.55 # _bilgus: yeah, it is one of the primary variables. : ) 09.30.05 # ... though at this point, actually implementing exfat is a good idea. 09.30.38 # a substantial undertaking to be sure, but at least now it's actually viable legally. 09.32.07 # <_bilgus> wouldn't you have to have fat to leave the bootloader and then switch to exfat? 09.32.35 # depends on the target.. but yeah 09.32.44 # the bootloader would have to support it too 09.33.19 # <_bilgus> I've put partitions on a sdcard 09.33.35 # most of our targets don't support multiple partitions. 09.34.21 # though that's easy to change from the rb perspective 09.34.22 # <_bilgus> as long as it picks up the first or do they fail to boot? 09.35.05 # (ie we don't turn on MULTIVOLUME for most targets) 09.35.27 # I think the various OFs don't generally care about anything other than the 1st partition 09.35.58 # but one of he points of supporitng exfat is to not require folks to have to reformat their cards 09.36.24 # <_bilgus> yeah they come formatted that way 09.41.55 # I wonder if there's any power disadvantage to using STANDBY_IMMEDIATE instead of SLEEP on the older spinning rust systems 09.42.30 # (eg the irivers and 1g-5g ipods) 09.42.48 # (whjich I think exclusively used toshiba disks) 09.48.08 # iriver H10 uses a hitachi 09.48.11 # originally 09.48.33 # and seagate for the 5G/6G variants 09.49.19 # (I'm talking about the 1.8" ones, not the microdrive-based ones..) 09.49.44 # huh, the ATA driver used to use STANDBY_IMMEDIATE but that was yanked in favor of SLEEP... in 2002. 09.50.03 # the H10 20GB doesn't use a microdrive 09.50.14 # but ok 09.56.24 # ; sighs. 09.57.22 # ? 09.57.26 # find something? 09.57.48 # spec-reading doesn't help much when it's the implementation that's b0rked. 09.58.07 # there's the spec and then there's reality 09.58.30 # spec is only good if people always implement it right 09.58.37 # a lot of these devices claim to implement powermgmt. 09.59.31 # maybe the right thing to do is use STANDBY_IMMEDIATE instead of SLEEP on these devices. 09.59.52 # but I'll have to wait to see what the results of the last few test builds turn out to be 10.00.25 # (eg use SLEEP on spinning rust but STANDBY_IMMEDIATE on things that advertise as CF?) 10.00.42 # would be interesting to figure out what the ipod firmware actually uses 10.08.27 Quit pamaury (Ping timeout: 260 seconds) 10.08.51 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.17.42 *** Saving seen data "./dancer.seen" 10.22.14 Quit massiveH (Quit: Leaving) 10.34.49 # <_bilgus> I'm having a hard time figuring out a good way to represent the keymaps in a form easily digestible lua and easily parsable for me 10.36.16 # <_bilgus> being that multiple contexts are capable of being remapped to the same user_ctx 10.37.25 # <_bilgus> i'm thinking they should all carry a tag to their parent and then I can collect them when I want to display or generate a keymap 10.38.44 # <_bilgus> for saving and restoreing I should be able to just serialize the table and restore without care to the order 10.39.38 # <_bilgus> I still need a way for a user to recover from bad keymaps 10.40.20 # <_bilgus> like maybe make it apply only if no buttons are pressed 10.40.28 # <_bilgus> ? 10.41.13 # <_bilgus> if select is held on startup keymap is not applied 10.41.39 # <_bilgus> wouldn't work for touch targets 10.41.55 # <_bilgus> would they need key remapping? 10.41.58 # well, touch targets don't need keymaps in teh traditional sense 10.42.43 # <_bilgus> so select or vol up or something not currently used disableskey remap with a splash 10.44.39 # <_bilgus> If I rempapped my direction keys in the main menu well shame on me but how do I recover? go into OF nad delete the remap file that would be annoying 10.45.27 # <_bilgus> otherwise it could apply temporary and only apply on startup if you were able to go set it 10.45.47 # <_bilgus> but that seems annoying from a experienced user perspective 10.56.13 # well, mucking with keymaps is something that's inherently dangerous and might cause your player to eat your cat 10.56.48 # so.. as long as there is a documented way of resetting to "stock" keymaps I'd not worry about it. 11.00.27 # <_bilgus> deleting the keymap does that 11.00.55 # <_bilgus> but i figured if you can screw it up on player you should be able to recover on player 11.22.11 # well, we have a "Restore to default settings" keypress on boot, right? 11.40.41 Join MrZeus_ [0] (~MrZeus@2a02:c7f:a0aa:4400:486b:5309:1b8:cfe0) 12.17.44 *** Saving seen data "./dancer.seen" 12.47.03 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 12.55.31 Quit atsampson (Ping timeout: 260 seconds) 13.12.18 Join atsampson [0] (~ats@cartman.offog.org) 13.25.03 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.34.07 Join MrZeus__ [0] (~MrZeus@194.37.96.153) 13.35.26 # oh joy, here's a dump from an actual iflash-branded device, and it _doesn't_ advertise itself as CF. 13.37.31 Quit MrZeus_ (Ping timeout: 260 seconds) 13.48.33 Quit nihilazo (*.net *.split) 13.56.15 # <_bilgus> speachy, oh do we that will work as long as I make sure it happens before the keymap is loaded? 14.00.03 Join nihilazo [0] (e33ac355b6@198.108.76.81) 14.08.23 Join chris_s [0] (02cdf09c@dslb-002-205-240-156.002.205.pools.vodafone-ip.de) 14.09.23 # don't hold me to that but I seem to recall it being there 14.11.20 # Speaking of the "Restore to default settings" keypress: That's actually (for whatever reason) the Hold slider on iPods. Which is not a great idea, because iPods automatically turn on when docked and/or connected to power. It was one of the first things that motivated me to look into compiling my own build of Rockbox (since it's trivial to change in 14.11.21 # code), because having the settings reset all the time was so irritating in practice. 14.11.51 # I think there's actually a patch in Flyspray by someone, although i haven't looked at it 14.12.36 # FS#13193 (I think it would be a better idea to simply use a different button for that on iPods though) 14.12.37 # https://www.rockbox.org/tracker/task/13193 Add option to disable settings reset on startup (patches, unconfirmed) 14.17.48 *** Saving seen data "./dancer.seen" 14.18.32 Quit chris_s (Quit: Connection closed) 14.18.52 # yeah, I'd concur 14.38.11 Quit fs-bluebot (Ping timeout: 240 seconds) 14.40.02 Quit bluebrother (Ping timeout: 246 seconds) 14.46.33 # well, no change. drat. 14.47.09 # disabling power saving altogether didn't change things, adding an explicit flush didn't change things. 14.47.21 # backing off DMA didn't help either. 14.47.27 # so there's _another_ failure mode going on. 14.55.48 Quit pamaury (Remote host closed the connection) 14.58.44 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 15.06.23 Join chris_s [0] (02cdf09c@dslb-002-205-240-156.002.205.pools.vodafone-ip.de) 15.07.57 # @speachy: I wonder why Rockbox on the iPod 4G on the other hand doesn't have the same issues with the iFlash adapter (at least using UDMA1) 15.08.09 # ah, but which iflash adapter.. 15.10.19 # the Solo, admittedly – I've had the same issues doing USB file transfers with that one in Rockbox on an iPod video though. 15.11.18 # so the same adapter, behaving differently depending on which one it's plugged into.. interesting. 15.11.44 # I wasn't able at the time to test whether it *only* has issues in USB mode (on iPod 5Gs). 15.12.24 # IIRC starting with the 5G they went away from the 50-pin CF connector? 15.13.30 # if so, I wonder if it ends up getting pinstrapped differently and acts slightly differently -- and if that might show up in the identify_info dump 15.13.45 # no idea, yeah they started using ZIF connectors on the 5G: https://www.iflash.xyz/store/hdd-ribbon/ 15.13.47 # (eg on these dumps it's not identifying itself as a CF adapter) 16.00.47 # great, no immediate way to tell the microdrives apart from the actual solid-state CF cards. 16.17.51 *** Saving seen data "./dancer.seen" 16.42.41 Quit chris_s (Quit: Ping timeout (120 seconds)) 16.54.08 # * speachy rubs his forehead. 16.56.19 # ok, the latest test build seemed to work. It ignores the flag saying power management isn't supported, and issues STANDBY_IMMEDIATE. 16.56.33 # oh and a flush cache first. 16.57.45 Quit MrZeus__ (Ping timeout: 260 seconds) 16.58.22 # if I go forward with this, what impacts will it have on spinning rust? 17.11.20 # "Find out next time the adventures of speachy." 17.11.25 # :P 17.11.31 # same irc time, same irc channel 17.12.17 # well, guess I'm done for the day. cat just completely engulfed my test rig. 17.24.19 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 17.24.19 Quit pixelma (Quit: .) 17.25.05 Join fs-bluebot [0] (~fs-bluebo@55d4bc24.access.ecotel.net) 17.25.19 Join pixelma [0] (marianne@rockbox/staff/pixelma) 17.25.19 Join amiconn [0] (jens@rockbox/developer/amiconn) 17.25.30 Join daswf8527 [0] (~daswf852@unaffiliated/dwf) 17.26.50 # braewoods: if you could try g#3552 on your iriver devices, I'd appreciate it 17.27.02 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 17.27.05 # preferably both modded and umodded. 17.27.32 Quit daswf852 (Ping timeout: 240 seconds) 17.27.33 Nick daswf8527 is now known as daswf852 (~daswf852@unaffiliated/dwf) 17.29.46 # * speachy pokes bluebot again. 17.31.02 Join MrZeus__ [0] (~MrZeus@2a02:c7f:a0aa:4400:486b:5309:1b8:cfe0) 17.37.37 # speachy: I don't have the original hard drive anymore except for the H10 5GB 17.40.41 # I need some confidence this doesn't cause regressions, so anything that can be tested will help 17.41.09 # chris_s: if you could try g#3552 as well.. 17.41.27 # all I can say so far is that my mini2g hasn't eaten its microdrive yet. 17.50.05 Quit mendel_munkis (Remote host closed the connection) 17.50.23 Join mendel_munkis [0] (~mendelmun@ool-43568247.dyn.optonline.net) 17.53.04 Quit lebellium (Quit: Leaving) 17.53.12 Join chris_s [0] (02cdf09c@dslb-002-205-240-156.002.205.pools.vodafone-ip.de) 17.54.36 # sure thing  :) 17.55.39 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 18.15.09 Quit chris_s (Quit: Ping timeout (120 seconds)) 18.17.53 *** Saving seen data "./dancer.seen" 18.34.26 Quit ZincAlloy (Quit: Leaving.) 18.36.17 Quit ufdm (Quit: Leaving) 18.42.45 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:894f:8a9a:1d21:ce0e) 18.44.38 Join Soap [0] (~Soap@rockbox/staff/soap) 18.44.57 Quit ZincAlloy (Client Quit) 18.56.06 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 19.03.39 Join chris_s [0] (02cdf09c@dslb-002-205-240-156.002.205.pools.vodafone-ip.de) 19.04.41 Quit Soap (Ping timeout: 240 seconds) 19.05.11 # no problems so far on the iPod 4G using iFlash Solo. I'll check the unmodded iPod Photo/color tomorrow, but that one wasn't super reliable using Rockbox's USB mode in the first place last time I checked 19.07.49 # (that could have also been an issue with MacOS though,the volume would unexpectedly disappear after transferring a limited amount of data iirc...) 19.08.24 Quit chris_s (Client Quit) 19.10.50 Join Soap [0] (~Soap@rockbox/staff/soap) 19.12.21 Join Soap_ [0] (~Soap@rockbox/staff/soap) 19.15.12 Quit Soap (Ping timeout: 240 seconds) 19.21.40 Join Soap [0] (~Soap@rockbox/staff/soap) 19.21.52 Quit Soap_ (Ping timeout: 240 seconds) 19.23.45 Join Soap_ [0] (~Soap@rockbox/staff/soap) 19.26.11 Quit Soap (Ping timeout: 240 seconds) 19.35.01 Join MrZeus_ [0] (~MrZeus@194.37.96.153) 19.35.55 Quit pamaury (Ping timeout: 260 seconds) 19.38.15 Quit MrZeus__ (Ping timeout: 260 seconds) 19.52.55 # Build Server message: New build round started. Revision 79d1b68fe2, 298 builds, 9 clients. 19.53.44 Join amachronic [0] (~amachroni@82.132.187.194) 19.57.29 # seems that USB is not working as well as it appeared on the M3K 20.02.21 # I assume the designware USB driver works reliably on the other ports, 20.02.45 # it would seem so 20.02.53 # but for some reason I'm getting hangs and lockups 20.03.07 # plugged into a USB 2 or USB3 port? 20.03.12 # USB3 20.03.21 # haven't tried USB2 yet 20.03.41 # might be worth a try, if nothing else it mucks with the timing a bit 20.04.10 # It seems there's multiple symptoms but I'm not sure what the real cause is. 20.04.14 # (There's still a report of the X3 having some usb hiccups, but it seems to only affect USB2 host contollers) 20.04.26 # Build Server message: Build round completed after 691 seconds. 20.04.29 # Build Server message: Revision 79d1b68fe2 result: All green 20.04.38 # cache management differences between ARM and MIPS? 20.04.55 # it seems data corruption isn't the issue. 20.04.57 # oddly 20.05.31 # I was able to write 20 gigs, and read them back just fine, so I'd figure cache bugs would've manifested 20.05.35 # well, the x1000 is considerably faster than any of the other dwc2 SoCs.. 20.05.38 # it only affects the early connection setup. 20.05.51 # could be a classic race condition 20.06.09 # it does seem to occur most frequently when HID + mass storage are enabled together. 20.06.22 # using mass storage only seems to be less problematic 20.07.21 Quit cockroach (Quit: leaving) 20.08.28 # it appears that on occasion, Rockbox doesn't respond on the mass storage endpoint 20.08.53 # causing the host to try resetting, and that causes a hard lockup. 20.09.39 # pressing HID keys tricks the host into thinking the device is alive, 20.10.21 # but after a while rockbox panics with usb_dw_gonak_effective: failed! 20.16.01 # I really need to get this port onto my M3K. 20.16.15 # so I can actually help dig into this stuff 20.16.15 # well, it's at least one command to install now 20.16.53 # I hope this iflash stuff can finally be put to rest now 20.17.55 *** Saving seen data "./dancer.seen" 20.25.20 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 20.40.13 Quit amachronic (Quit: amachronic) 20.50.23 # I think the underlying issue with the iflash stuff is that we might be entering sleep _too_ aggressively, as in momentary pauses between usb transfers are enough to trigger it. 20.51.08 # and that's exacerbated by the iflash's chipset/firmware's not-quite-ATA-compliance 21.01.32 # Build Server message: New build round started. Revision f968d6032a, 298 builds, 9 clients. 21.05.46 # speachy: does this change things for bootloaders? i suspect not as the bootloaders almost never spindown the disks 21.05.54 # plus BLs typically just rea 21.05.56 # read 21.06.01 # only do writes if in USB mode 21.07.04 Quit MrZeus_ (Ping timeout: 252 seconds) 21.07.22 # yeah, probably won't affect the bootloaders at all unless they do writes 21.11.17 # amachronic: any objection to moving the m3k from 'unusable' to merely 'unstable' ? 21.12.18 # (it'll start showing up in nightly build list, get voice builds, and so forth) 21.12.51 # Build Server message: Build round completed after 679 seconds. 21.12.54 # Build Server message: Revision f968d6032a result: All green 21.35.37 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) 21.36.42 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 21.37.37 Quit St3ak (Client Quit) 21.38.54 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 22.17.58 *** Saving seen data "./dancer.seen" 22.21.20 Quit Strife89 (Quit: No Ping reply in 180 seconds.) 22.22.45 Join Strife89 [0] (~quassel@adsl-74-250-152-173.ags.bellsouth.net) 22.27.05 Quit cockroach (Quit: leaving) 22.58.35 Quit Saijin_Naib (Ping timeout: 250 seconds) 23.06.58 Quit ac_laptop (Ping timeout: 252 seconds)