thelounge7571340 has quit [Remote host closed the connection]
Etrien__ has joined #asahi-dev
Etrien has quit [Ping timeout: 480 seconds]
Core1050 has joined #asahi-dev
DarkShadow4444 has quit [Remote host closed the connection]
Core9066 has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
rmk: thank you :)
<nicolas17>
I wonder why compiling a kernel for 6 minutes gets my M2 fans to go fast, but running a bunch of xdelta3 instances for hours doesn't heat up that much, on Intel I'd say "it makes more memory accesses, so it's using less CPU because it's stalled waiting for memory" but apple silicon has such high memory bandwidth that I'm skeptical of that being the only reason
<chadmed>
aiui we dont yet put the memory controller into the higher pstate, so that could still be the case
<nicolas17>
are there any performance counters I can access from Linux?
Dcow_ has quit [Remote host closed the connection]
<nicolas17>
chadmed: that would explain why ffmpeg on macOS also manages to cause more heat, apples and oranges but still
<chadmed>
yeah theres a PMU driver, accessible through the normal sysfs mechanism i think
<nicolas17>
(I didn't test ffmpeg on Linux)
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
riker77 has quit [Ping timeout: 480 seconds]
riker77 has joined #asahi-dev
<nicolas17>
chadmed: kernel "make -j8 vmlinux" gets 1.91 instructions per cycle, 8 simultaneous xdelta instances (with a 256MB "source window" which makes it use about 1.3GB RAM) gets 0.68 insn per cycle
<tpw_rules>
just out of curiosity, what do you do with lots of xdelta'ing?
<nicolas17>
tpw_rules: I was investigating a way to store tons of .ipsw files using little storage :)
<tpw_rules>
precomp + dwarfs
<tpw_rules>
if you ditch precomp and set dwarfs up with a giant lookback value, you'll get instant access too (though it will probably be slow to create)
<nicolas17>
I got some impressive results running bsdiff between two dyld_shared_caches btw
<nicolas17>
but it needs a ton of RAM
<tpw_rules>
actually now that i think about it, idk if anyone's tried to hook it up to macfuse before. might not be great if you want to create or mount on macos. but i'd be interested to try it. how did you create your corpus
<nicolas17>
and then I started having RAM problems on my desktop PC, I identified the bad DIMM, and went from 16GB to 8GB, which made bsdiff impractical
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
ccs1 has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
nicolas17: compiling does not benefit from memory bandwidth, everyone confuses bandwidth and latency :)
<marcan>
adding more bandwidth isn't going to help memory accesses go quicker
<marcan>
it only helps you do more of them in parallel, which compiling doesn't
<marcan>
because compiling doesn't parallelize at that level
<nicolas17>
marcan: compiling is fast and warms up the CPU to the point it brings up the fans, I'm sure it has enough memory bandwidth/latency; *other* workloads, despite putting all cores at 100% usage, aren't causing that much heat and *those* may be stalling for memory
SSJ_GZ has joined #asahi-dev
Method_ has quit [Remote host closed the connection]
Method has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
nicolas17: could be :)
<marcan>
it could be there is something particularly sub-optimal about whatever xdelta is doing
<marcan>
like enough memory-memory dependencies that the speculation can't do anything about it
hippo2012 has joined #asahi-dev
hippo2012 has left #asahi-dev [#asahi-dev]
hippo2012 has joined #asahi-dev
hippo2012 has quit [Quit: Leaving.]
hippo2012 has joined #asahi-dev
hippo2012 has quit [Quit: Leaving.]
nicolas17 has quit [Quit: Konversation terminated!]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
<marcan>
so I just tried to do an Asahi install to an external disk because why not (it might work, though locked to one machine) and:
<marcan>
The new partition to be added will be of a filesystem personality of APFS apfs APFS 7C3457EF-0000-11AA-AA11-00306543ECAC
<marcan>
Error finding last partition on map (there must pre-exist at least one partition): Invalid request (-69886)
<marcan>
... why is Apple tooling so broken
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Etrien__ has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-dev
<marcan>
aand nope, fuOS on USB doesn't work.
<marcan>
there's at least two problems, #1 kmutil doesn't read the adminuser file from the right place
<marcan>
#2 I'm not sure yet, it's bootlooping
<marcan>
I wonder if any of this is fixed in newer macOS versions...
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
oh... I think I screwed this up, lol
amarioguy2 has joined #asahi-dev
<marcan>
... how did I end up with a 0-byte m1n1.bin?
<marcan>
ok, so it actually works! we can do stage1 installs directly to USB
<marcan>
only problem is m1n1 now needs an xHCI+USBMS stack written in Rust ;)
<marcan>
but I'm going to commit the required installer shenanigans as expert-only and only allow the m1n1/tethered install option, so people can play around with it
<marcan>
I haven't tested it yet, but I think it should be possible to make such an external drive bootable on another Mac by re-running the installer in the "fix my boot policy" mode
<sven>
usbms is simple enough, xhci will be a pain though :D
<marcan>
xHCI isn't that bad, but then you also need to do the whole USB stack thing (hubs, etc.)
<marcan>
that's the worst part IMO
<marcan>
parsing descriptors and all that "fun" stuff
<marcan>
(hence, Rust)
<jannau>
we could just embed u-boot once the upstream devicetree has enough features
lamlam has joined #asahi-dev
<marcan>
yeah, I thought of that, though it's not ideal
<jannau>
it's certainly not a good idea right now
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
lamlam has quit [Remote host closed the connection]
codingkoopa9 has quit []
mrkajetanp has quit [Remote host closed the connection]
codingkoopa9 has joined #asahi-dev
Dcow has joined #asahi-dev
<sven>
jannau: have you already thought about how to represent multiple drm connectors in the dt?
<sven>
I finally can’t procrastinate looking at the typec subsystem anymore
chengsun has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has quit [Ping timeout: 480 seconds]
<jannau>
I looked at the existing bindings in Documentation/devicetree/bindings/display/{bridge,connector,panel} which are no good fits since they expect directly driveable hardware behind it. the connectors not so much but no usb-c connector
<jannau>
the dp connector is cleary written with pure dp connectors in mind
amarioguy2 has quit [Remote host closed the connection]
chengsun has joined #asahi-dev
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
<kettenis>
jannau: did you see marex's post on the u-boot usb stuff?
<jannau>
yes, I haven't tested it yet but based on that random delays fixed it for previously I don't doubt that it works
<jannau>
sigh, apple's DCP split is annoying. I have the impression someone looked at all functions and decided based on some criteria which ones need to be executed on the co-processor. after that was done both parts were stitched together to make it work
<jannau>
for display brightness control I write what appears to be DAC register but DCP reports back the birghtness in nits
<kettenis>
would be good if you replied to the message
<kettenis>
I'll do the same; hopefully it'll make the 2023.01 release
thelounge7571340 has joined #asahi-dev
ccs1 has quit [Ping timeout: 480 seconds]
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
jannau: re tipd on M2, any particular devices/charger you use?
<marcan>
(just want to get it 100% identical)
<marcan>
(I remember stuff like that mattering in the past)
<jannau>
marcan: I don't think it depends on the device/charger. I see it with original apple charger and anker and aukey usb-pd chargers. device was in most cases a yubikey 5 usb-c
<sven>
jannau: hrm, i'm a bit confused by that switch stuff. there's already that typec connector binding, the typec mux mess and pretty much all that's missing is some property for the atcphy node that indicates it can mux dp-altmode,tbt, etc.
<sven>
and a graph connection to the DRM connector and then we can just use that oob_hotplug mechanism that already exists
<sven>
oh.. maybe I should read the entire thread and not just the original patch
<jannau>
hmm, not even sure if that was the relevant thread remembered
<sven>
i think the last mails are pretty much "just use the type c connector" + they seem to introduce that mode-switch property
<sven>
the typec_mux stuff is a bit weird and i'm still confused by it. last time I looked at it it looked like there was a different mux for each mode or something
<sven>
that's why I just hacked it in atcphy-wip but now i'm at a point where that won't work nicely any longer :D
<sven>
I actually need the hotplug callback for dcp now and soon also for thunderbolt
<marcan>
jannau: So one charger and one device?
grange_c has joined #asahi-dev
<jannau>
marcan: yes, that's the usual start config. charger in the back port
<jannau>
I just tried to reproduce it on j314 but it seems to be stable there
Core9066 has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<sven>
looks like 144a96f7f96e412c3367f51cf2c57f52e3f1110d fixes my confusion. so essentially atcphy just needs "mode-switch" to support all altmodes
<jannau>
marcan: reproducible with the charger alone in the back port on the m2. front port appears to be fine until the issue is triggered on the back port
Core1050 has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
<jannau>
happens on the front port as well, just hit a stretch over 5 reconnections without hit
systwi has quit [Read error: Connection reset by peer]
systwi has joined #asahi-dev
<marcan>
fixed the installer issues when there is a pending macOS upgrade (I think)
<marcan>
I think that ticks off all the longtime installer snags people have been running into
<jannau>
great, I guess that means another round of installer testing
gladiac has joined #asahi-dev
balrog has quit [Ping timeout: 480 seconds]
<jannau>
is there another interpration for nits2mAmps0thOrderCoef = 1245
<jannau>
nits2mAmps1stOrderCoef and nits2mAmps2ndOrderCoef which is not a quadratic polynomial?
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
balrog has joined #asahi-dev
<jannau>
the coeficients don't make much sense to in that context: 4928 + 870292 * x + 41164 * x**2
<jannau>
the 1st degree coefficient is only 20 times larger than the 2nd degree coefficient while the expected range of x is [0,525]
<povik>
what if x plugged into the polynomial is [0.0,1.0] ?
chengsun has quit [Ping timeout: 480 seconds]
<povik>
not that ~870 amps is sensible either :D
<jannau>
coefficients are most likely 16.16 fixed point
<jannau>
and the adt has "calibratedMaxCurrent = 904383"
chengsun has joined #asahi-dev
<amarioguy>
sven: regarding my previous patch, wolfram asked if a v4 was coming - given we already integrated the "final" version into the asahi tree, would it be best to send v4 through mailing lists directly or do we want to wait until the project begins sending the currently bundle of changes upstream?
<amarioguy>
especially since i'm not sure if that tps issue was resolved yet...
<amarioguy>
s/currently/current*
<j`ey>
amarioguy: there's no such thing as 'the project beings sending the currently bundle of changes upstream'
<amarioguy>
ah lol
<amarioguy>
still, should probably ask about the TPS issue before we send a v4
<povik>
jannau: you get roughly that maximum at x=1.0, as you probably noticed
amarioguy has quit [Quit: Leaving]
<jannau>
not sure by which value I should norm the brightness. all devices have the same coefficients and conversion tables
<sven>
amarioguy: imho the tps thing is a bug in the tps driver, I’d send out a v4
<jannau>
amarioguy: also seems to show only on (my) m2 macbook pro. marcan wants to see if it is reproducible for him
<jannau>
although I think I saw it on another device
<sven>
yeah, I can’t reproduce it here on the mini either
<sven>
jannau: we’ll also need some way to encode which connector maps to which atcphy
<sven>
and a way to encode that connectors on die 0 can only be routed to dcpext on die 0
<sven>
the first part is probably easy if the connectors are just sub nodes. we could just give them a phys=<atcphyX> property
<marcan>
jannau: ok, reproduced
<marcan>
let me see if I can pull off some hardware i2c logging...
<sven>
also, can I volunteer you to make this work on t600x with more than one dcpext once I get it in a reasonable shape on t8013? :>
<jannau>
sven: which part of the connector are we speaking about? the usb or the drm one?
<jannau>
I'll look at t600x
<sven>
drm
<sven>
usb will remain more or less like it’s in that old atc wip branch
<sven>
it’ll just get another graph connection to the drm connector
<jannau>
wouldn't that need multiple phys to work? and if that works it should also solve the die issue
<sven>
hmm?
<sven>
so each type-c port has its own atcphy (and probably will get another phy for dpin0/1)
<sven>
each type-c port also has its own display crossbar mux but we can just ignore that for now
<jannau>
in my model dcpext have a connector subnode
<jannau>
thich can be routed to every usb-c port on the same die
<sven>
oh, i was thinking about having the connector subnode on the display-subsystem
<sven>
because that thing has to decide the muxing
<sven>
but maybe having it as a dcpext subnode makes more sense
bluetail has joined #asahi-dev
<jannau>
drm has a concept of possible connectors for each crtc (== dcpext)
<sven>
I think we'll also need three connectors (dpphy, dpin0/1) for each type-c port
Gaspare has joined #asahi-dev
<sven>
we'll have to be able to describe tiled displays which will use dpin0/1 at the same time
<sven>
hrm, or maybe fake the tiled displays into a single connector
<jannau>
shouldn't tiled displays just work with dcpextX,0/dcpextX,1? ut cases like thunderbolt hubs with a connected thunderbolt display and dp alt mode will require 3 connectors
Method is now known as Method_
<sven>
so in my head I still have a drm connector connected to a single phy and a crossbar mux. in that case we'd need two drm connectors for the dcpextX,0/dcpextX,1 case since both muxes have to be configured
<sven>
(and I suspect that dpin0/1 will become another phy)
ccs1 has quit [Ping timeout: 480 seconds]
<sven>
hrm, what happens to the oob hotplug notification if you have a single type c port connected to multiple drm connectors?
<sven>
(drm_connector_oob_hotplug_event)
<jannau>
no idea but that sounds like a problem which has to have already a solution for DP MST over thunderbolt/usb-c
<sven>
not really :(
<sven>
DP MST over thunderbolt/usb-c on intel machine happens by magic afaict
<sven>
i.e. there's no OOB event required
<sven>
and wouldn't DP MST use two connectors anyway?
<jannau>
it wouldn't. I expect it to use 2 CRTCs though
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
lamlam has quit [Remote host closed the connection]
<marcan>
ok, for starters there's a bug in the IRQ handler. if the event read fails, event is uninitialized, but then it decides whether to return IRQF_HANDLED or not based on that.
<marcan>
I don't know that that's the problem yet but that's broken
<sven>
jannau: not totally sure yet, but afaict mst creates a new connector on the fly
Core8788 has joined #asahi-dev
<sven>
marcan: huh, even on the latest rc? I vaguely remember a patch that fixed that issue
<marcan>
who decided that was a good idea? I'm seeing clock stretching from this thing of... exactly 10ms
nicolas17 has joined #asahi-dev
<sven>
in the pasemi thing?
<marcan>
yes
<marcan>
the timeout in m1n1 is 50ms, for the record
<marcan>
which seems a lot saner
<sven>
those boards had like two chips on the i2c bus
<marcan>
yeah but we kept it with the irq support :p
<sven>
cause it worked so far
<marcan>
I wonder if it's configurable somewhere
<marcan>
this ought to be platform-specific
<marcan>
lol, like every driver has a random hardcoded timeout
<marcan>
but the i2c core has an actual timeout field too
chadmed_ has quit [Quit: Page closed]
<marcan>
ah, but that's for arbitration loss
<marcan>
anyway, looking at other drivers, 100ms-1s seems to be common
<marcan>
10ms is ridiculous
<marcan>
and the irq path does *not* actually check whether the timeout expired
<marcan>
this is broken
<marcan>
very very broken
cylm has joined #asahi-dev
<sven>
the irq path rereads status, doesn’t it?
<sven>
oh, but then there’s no follow up check if XEN was actually set
<marcan>
yeah
<marcan>
it instead checks the timeout counter which is not touched
<marcan>
I'll send a fix
<sven>
irq isn’t even upstream yet
<marcan>
ah, easier then
<sven>
amarioguy can just fix it in v4 I guess
<jannau>
not reproducible with 20 ms irq timeout (just for testing)
<marcan>
... why is cpufreq crashing on me now?
<sven>
:D
<sven>
looks like everything’s broken today!
duban6 has quit []
<sven>
I’m hunting down yet another udelay that’s missing somewhere i atcphy.c. every now and then altmode doesn’t come up
<sven>
which is also very annoying to test :(
<marcan>
ah, because I'm dumb
<marcan>
and then the next problem is that when i2c *does* time out, it breaks forever and cannot recover
<sven>
huh, that sounds broken. I thought there’s a reset on timeout
bluetail has quit [Ping timeout: 480 seconds]
<marcan>
no, it doesn't reset
<marcan>
also, the datasheet says the *hardware* timeout is 25ms (!)
<marcan>
so that's... borderline for us, lol
<marcan>
unless Apple extended it or made it configurable (they probably did?)
Gaspare has quit [Quit: Gaspare]
bluetail has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
zjstraus has joined #asahi-dev
VinDuv has joined #asahi-dev
Gaspare has joined #asahi-dev
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
daniels has quit [Ping timeout: 480 seconds]
nathanchance has quit [Ping timeout: 480 seconds]
khilman has quit [Ping timeout: 480 seconds]
khilman has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
Puto has quit [Ping timeout: 480 seconds]
jkkm has quit [Ping timeout: 480 seconds]
_alice has quit [Ping timeout: 480 seconds]
austriancoder has quit [Ping timeout: 480 seconds]
mmarchini____ has quit [Ping timeout: 480 seconds]
Gaspare has quit [Quit: Gaspare]
daniels has joined #asahi-dev
nathanchance has joined #asahi-dev
Manouchehri has quit [Ping timeout: 480 seconds]
NekomimiScience has quit [Ping timeout: 480 seconds]
eric_engestrom has quit [Ping timeout: 480 seconds]
austriancoder has joined #asahi-dev
_alice has joined #asahi-dev
jbowen has joined #asahi-dev
<marcan>
jannau: going to do a kernel build, do you have any DCP updates?
jkkm has joined #asahi-dev
Puto has joined #asahi-dev
NekomimiScience has joined #asahi-dev
mmarchini____ has joined #asahi-dev
Manouchehri has joined #asahi-dev
<marcan>
in the meantime, it's pushed to asahi-wip with improved pasemi-i2c error recovery
<marcan>
I tested it setting the timeout to 2ms, it fails as you would expect but doesn't go into a spiral of doom
<ChaosPrincess>
marcan: mind looking at pwm v-idk-which?
eric_engestrom has joined #asahi-dev
<marcan>
either way, I think that's *finally* release material soon
<jannau>
brightness control is not yet ready but there might be something which can be merged
<marcan>
ChaosPrincess: I would but I'm kind of running behind on progress report / kernel update so I'm going to punt that one to next time, sorry. hopefully it won't be as long as this one though.
<marcan>
don't want to add any more variables
<ChaosPrincess>
:(
<ChaosPrincess>
Come on, its a tiny driver. :P
<marcan>
yes, I know, but it's always "one more tiny thing" :)
* millenialhacker
I can hear chadmed telling me to use his overlay for everything xD
* millenialhacker
cp grub.cfg grub.cfg.bak && sed -i 's/rc2/rc3/g' grub.cfg
millenialhacker has quit [Quit: Konversation terminated!]
<ChaosPrincess>
also make sure you updated the dtbs and such
millenialhacker has joined #asahi-dev
<millenialhacker>
ok, still no backlight
<millenialhacker>
I'm using right kernel
<millenialhacker>
ChaosPrincess what do you mean by update dtbs?
<j`ey>
you need new device trees
<ChaosPrincess>
you need to inject new dtbs into m1n1
<millenialhacker>
ahh, need to recompile m1n1 then
<millenialhacker>
just stage2 right
<millenialhacker>
?
<j`ey>
yeah
<ChaosPrincess>
you dont need to recompile, just cat m1n1, all dtbs and u-boot
<millenialhacker>
m1 is t8103-j293.dtb right?
<j`ey>
millenialhacker: m1 mbp?
<millenialhacker>
yup
<j`ey>
then yeah 293
<sven>
bah.. I just can't find the last udelay that's missing to make altmode work every single time :/
qyousef has quit [Ping timeout: 480 seconds]
millenialhacker has quit [Quit: Konversation terminated!]
Puto has quit [Ping timeout: 480 seconds]
jonmasters_ has quit [Ping timeout: 480 seconds]
cptcobalt has quit [Ping timeout: 480 seconds]
snek has quit [Ping timeout: 480 seconds]
liszt_ has quit [Ping timeout: 480 seconds]
msteffen has quit [Ping timeout: 480 seconds]
esden has quit [Ping timeout: 480 seconds]
sjg1 has quit [Ping timeout: 480 seconds]
tardyp has quit [Ping timeout: 480 seconds]
azenla has quit [Ping timeout: 480 seconds]
jesse-s has quit [Ping timeout: 480 seconds]
robher has quit [Ping timeout: 480 seconds]
skmp__ has quit [Ping timeout: 480 seconds]
jonmasters_ has joined #asahi-dev
jbowen has quit [Ping timeout: 480 seconds]
cptcobalt has joined #asahi-dev
Puto has joined #asahi-dev
qyousef has joined #asahi-dev
jesse-s has joined #asahi-dev
msteffen has joined #asahi-dev
liszt_ has joined #asahi-dev
tardyp has joined #asahi-dev
snek has joined #asahi-dev
jbowen has joined #asahi-dev
azenla has joined #asahi-dev
skmp__ has joined #asahi-dev
sjg1 has joined #asahi-dev
esden has joined #asahi-dev
robher has joined #asahi-dev
millenialhacker has joined #asahi-dev
<millenialhacker>
Ok, tried rebooting after concatenating new dtb to my current m1n1 stage2 but lost wifi and pwm driver load failed, forgot to copy the error but it said error finding something defaulting to off
<millenialhacker>
but lack of wifi was surprising...
ashi has joined #asahi-dev
millenialhacker has quit [Quit: Konversation terminated!]
millenialhacker has joined #asahi-dev
<millenialhacker>
update-m1n1 script did the trick
<millenialhacker>
but I see this error:
<millenialhacker>
[ 1.957813] leds_pwm pwmleds: failed to read period for kbd_backlight, default to off
<millenialhacker>
Oh, I haven't tried it yet. Is HDMI over USB-C supported btw?
<sven>
it's only supported in my local tree for now
* millenialhacker
feels envy of sven
<sven>
and it's not reliable yet
<sven>
well, unless I add a usleep(10); after every single register poke :p
bluetail has quit [Ping timeout: 480 seconds]
<jannau>
I'm not sure if envy is the right word
<millenialhacker>
not sure how it works, but I remember when inspecting ISP stuff, that MacOS write to some registers, wait some nanoseconds, and the poke back the register to see if there an ACK value.
<sven>
that too
<sven>
the mmio reads/writes look exactly the same as XNU's. it's a delay somewhere that I can't easily see in the mmio trace
<millenialhacker>
I wouldn't be surprise of something similar in Linux world
<millenialhacker>
Have you tried going one by one?
<millenialhacker>
or it is a too naive approach?
<millenialhacker>
I have zero context, just trying to be rubber duck here
<sven>
well, every single test requires me too boot ~20 times to be sure it works
<sven>
i'll probably have to disassemble xnu and find its iodelays :(
<millenialhacker>
or you can add a custom parameter to your kernel driver, I mean 1 delay in some part, 2 delay in another part, 3 and so on.
<millenialhacker>
you can test without recompile at least
<sven>
the recompile really isn't the issue
<millenialhacker>
20 boots because it's not 100% repro I guess
<sven>
yeah, it's just unstable
<sven>
it works, I dunno, 9/10 times without any issue
<sven>
and usually 20 retries are enough to catch it
<millenialhacker>
does it requires reboot to properly work after it fails ? or it auto-recovers plugging and unplugging?
<sven>
there's no hotplug support yet :D
<sven>
I could probably hack some bind/unbind thing but since reboots itself are fast enough it doesn't matter
<millenialhacker>
You will have fun looking IOKit stuff
<millenialhacker>
:D
<sven>
do you still feel envy? :P
<millenialhacker>
hahaha at least is fun, isn't it?
<millenialhacker>
If you set async tracer in HV, is not possible to measure register time access without incurring in too much overhead?
<millenialhacker>
I mean just listening the write not actually running python code to do something when the registers are read/write
<millenialhacker>
I thought Hector mentioned there was some kind of low overhead tracing API in m1n1 hv
<sven>
huh, maybe I can just set a breakpoint on iodelay
<millenialhacker>
that's another good idea
<millenialhacker>
I didn't know that can be done
<sven>
maybe. I assume xnu uses iodelay all over the place
<sven>
might get too spammy, but let's see
<millenialhacker>
I set a hv breakpoint close to when I needed to test something regarding mmio regs
<millenialhacker>
not sure of you iodelay brk works, is it SW or HW brkp ?
<sven>
iodelay is literally a XNU function that's not inline for some reason iirc
<sven>
*inlined
<millenialhacker>
could be possible to only set it up after your first hit hv breakpoint to close to when you actually plug the thing into the laptop?