electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #glasgow
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
GNUmoon2 has quit [Quit: Leaving]
aquijoule_ has joined #glasgow
richbridger has quit [Ping timeout: 276 seconds]
_whitelogger has joined #glasgow
egg|anbo|egg has joined #glasgow
diverger has joined #glasgow
josi7 has joined #glasgow
<yorick>
okay, so I connect my glasgow, it shows up in lsusb, then I run 'glasgow voltage', it disconnects and reconnects, no longer shows up in lsusb, returns E: g.cli: device not found
<yorick>
I'll try to update the software
<yorick>
W: g.device.hardware: device 003/027 did not re-enumerate after firmware upload
<yorick>
this worked before :/
<yorick>
the kernel does say "new usb device found", etc
diverger has quit [K-Lined]
josi7 has quit [Ping timeout: 256 seconds]
<d1b2>
<Attie> @yorick that's not right... did you self assemble? have you verified for shorts on the I/O supplies, and possibly the I2C bus?
<yorick>
Attie: this is one of yours ;)
<yorick>
it worked before
<d1b2>
<Attie> ah - do you have anything connected to the ports? sitting on any conducive "stuff"?
<yorick>
nope, it's in a plexiglass case with nothing connected
<d1b2>
<Attie> does this happen each time you replug it?
<d1b2>
<Attie> can you verify the firmware? (e.g MD5 vs what's in the repo)
<yorick>
I sprayed it with some canned air for good measure, didn't help
<yorick>
it happens each time, yes
<yorick>
how do I verify the firmware?
<yorick>
adding -v results in:
<yorick>
D: g.device.hardware: found revC1 device without firmware
<yorick>
D: g.device.hardware: loading built-in firmware to revC1 device
<yorick>
W: g.device.hardware: device 003/047 did not re-enumerate after firmware upload
<d1b2>
<Attie> did you clone and use setup.py, or use pip?
<yorick>
I cloned and ran nix-shell -p python3 python3Packages.libusb1 python3Packages.aiohttp python3Packages.bitarray python3Packages.crcmod python3Packages.setuptools python3Packages.pyvcd python3Packages.fx2 python3Packages.nmigen
<jpa->
some googling found issues where some stray package has installed /etc/udev/rules.d/50-udev-default.rules which overrides the real one that is under /lib, and causes all kind of weird things, including lsusb not showing stuff; so worth checking that that file does not exist on your system
<yorick>
I don't have that file
<jpa->
ok
<d1b2>
<Attie> can you try ls -l /sys/bus/usb/devices/ with / without glasgow plugged in?
<d1b2>
<Attie> identify the line
<d1b2>
<Attie> and then share the vid/pid - e.g: tail /sys/bus/usb/devices/1-4.4.4/id{Product,Vendor}
<d1b2>
<Attie> (snip off the :x.y)
<yorick>
20b7:9db1
<d1b2>
<Attie> right, so lsusb -vd 20b7:9db1 should indeed work
<yorick>
it does not :)
bvernoux has joined #glasgow
<d1b2>
<Attie> yeah 😦
<d1b2>
<Attie> glasgow list shows nothing?
<yorick>
hm, the glasgow software version on the laptop doesn't have list, I can try to update
<yorick>
Attie: no, it shows up in glasgow list :)
<d1b2>
<Attie> ... so it works now?
<yorick>
sorry, I'm testing on the laptop, where it works all the time
<yorick>
it doesn't show up on glasgow list on the desktop, indeed
<d1b2>
<Attie> oh
<d1b2>
<Attie> same for the /sys/bus/usb above - was that on laptop or desktop?
<yorick>
laptop
<yorick>
these not-working and lsusb things may be unrelated
<d1b2>
<Attie> oh, and lsusb doesn't show it on laptop too?
<d1b2>
<Attie> ok, can you try the /sys/bus/usb on desktop pls?
<yorick>
ID 20b7:9db1 Qi Hardware Glasgow Debug Tool
<yorick>
similar output
josi7 has joined #glasgow
<yorick>
it shows up in lsusb -t but not lsusb
<d1b2>
<Attie> weird...
<d1b2>
<Attie> i need to run off now, sorry!
<d1b2>
<Attie> happy to continue this later if you don't figure it out
<d1b2>
<Attie> (gl!)
<yorick>
I'm afraid I'm gonna have to debug lsusb
bvernoux1 has joined #glasgow
egg|anbo|egg has joined #glasgow
bvernoux has quit [Ping timeout: 240 seconds]
egg|anbo|egg_ has quit [Ping timeout: 276 seconds]
aquijoule_ has quit [Ping timeout: 256 seconds]
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #glasgow
Foxyloxy has joined #glasgow
richbridger has joined #glasgow
jstein has joined #glasgow
mndza has joined #glasgow
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #glasgow
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel_ has joined #glasgow
electronic_eel_ has quit [Client Quit]
electronic_eel has joined #glasgow
bvernoux1 has joined #glasgow
bvernoux has quit [Ping timeout: 272 seconds]
noson has joined #glasgow
noson has left #glasgow [#glasgow]
alice__ has quit [Quit: See you.]
_alice- has joined #glasgow
<d1b2>
<Hardkrash> What is the root controller of the USB on the laptop?
coon has joined #glasgow
<yorick>
how do I know?
<yorick>
it's an intel kaby lake cpu
<coon>
is there a newer version than revC in development / is it worth to wait until some possible revD gets released?
<tomtastic>
yes there is, but I think revD is a long way off
<d1b2>
<DX-MON> so.. there will be a revD.. however, unless it has some planned feature not on revC that you specifically need.. there's no point to waiting as all revisions are supported for life
<coon>
thx for the info
<d1b2>
<DX-MON> revC3 solves some issues with revC2 that need redressing badly. revC1 is the current "stable" revision
<coon>
ah, hm
<d1b2>
<DX-MON> revC3 is what will be produced for the campaign
<d1b2>
<DX-MON> it fixes some issues with the ADC configuration that couldn't really be addressed in firmware
<d1b2>
<DX-MON> (I2C bus address collision..)
<d1b2>
<Hardkrash> Some intel EHCI root ports have issues with devices and "unplugging" does it work on the laptop if you place a powered USB High speed (2.0) hub in the path?
<sorear>
the letters identify "market segments", the number is an ordinal version. D and E are under development but they don't replace C
<yorick>
Hardkrash: it already works on the laptop, just doesn't show up in lsusb
<yorick>
the non-working desktop has an amd x570
<DX-MON>
I'm very intrigued to know what OS, kernel, etc.. you're running on that rig as I use an AMD X570 based machine and have had no problems with Glasgow just working
<electronic_eel>
yorick: my guess is that it is a software issue you are having. one way to rule out a hw issue would be to run a known-good live linux off a usb drive on your desktop
<yorick>
linux 5.10.10
<electronic_eel>
for example a live linux image from arch should work well
<DX-MON>
preferably using kernel 5.5 or newer
<DX-MON>
ah.. I wonder yorick.. if part of your problem is the udev rule you're using
<DX-MON>
I keep meaning to contrib an Arch rule as the default one is.. not quite right
<DX-MON>
because Arch uses the tag to give user access
<DX-MON>
stuff changed in udev etc etc.. I need to contrib this back at some point
<electronic_eel>
yeah, all newer distros use the uaccess tag and not the groups
<yorick>
anyways, the laptop doesn't have the udev rule on it :P
<electronic_eel>
but the original rule has both, groups and uacess
<yorick>
still doesn't show up in lsusb
<DX-MON>
and plugdev doesn't exist on Arch
<yorick>
yeah, I don't have plugdev on nixos
<yorick>
what handles the tag?
<DX-MON>
it's.. complicated systemd stuff
<yorick>
logind?
<DX-MON>
no, systemd itself
<whitequark>
does the rule break if you don't have the requested group?
<DX-MON>
actually, technically it's udevd
<electronic_eel>
does the missing plugdev rule cause issues on arch?
<DX-MON>
yes
<whitequark>
oh
<DX-MON>
and the way I wrote the rule to use the action-goto bit is actually important on Arch too
<electronic_eel>
hmm, maybe the way forward then is to remove the whole group thing and just use the uacess tag?
<DX-MON>
the group is required for it to work on Debian
<yorick>
DX-MON: does arch do anything special for uaccess?
<yorick>
why does arch have it but not debian?
<electronic_eel>
DX-MON: does debian not honor the uacess tag?
<DX-MON>
depends on the version of Debian
<yorick>
I can find references to uaccess all the way from 2012
<DX-MON>
Buster with no BPO uses a udevd old enough to not know about uaccess
<yorick>
no, uaccess was a thing back in 2010 already
<DX-MON>
Debian didn't use it back then
<yorick>
what does the distro have to do to use this?
<yorick>
" The access control lists of devices with the uaccess tag will be updated automatically when a user logs in through systemd-logind"
<DX-MON>
I'm not sure on the details, but it's a cross between how udev is configured exactly, what groups exist in /etc/group, how the kernel is configured, etc
<DX-MON>
I know for a fact (because I've tried), that uaccess doesn't work on vanilla Buster
<DX-MON>
if you enable BPO it will then start working
<DX-MON>
(once you update)
<DX-MON>
and I also know that Arch doesn't like it when you don't use that action-goto stuff
<yorick>
maybe it's running a devtmpfs without acls
<electronic_eel>
the action-goto stuff seems harmless and shouldn't hurt usage on other distros
<yorick>
anyways, yeah, I also think my issue is a software issue
<DX-MON>
yeah, it's mostly a change for sanity in the way udev rules are processed
<DX-MON>
as for devtmpfs.. no, Arch mounts with `rw,nosuid,relatime,size=32896236k,nr_inodes=8224059,mode=755,inode64`
<yorick>
I can thunderbolt in another usb controller if that'd help
<electronic_eel>
yorick: could it be that your version of libusb is somehow borked? it is used by lsusb and glasgow both
<electronic_eel>
yorick: you wrote that glasgow worked on your desktop before. maybe rollback to a libusb from the time when it was working?
mndza has quit [Ping timeout: 265 seconds]
<yorick>
it looks like 1.0.23 does work and 1.0.24 does not
<DX-MON>
this could also be down to an upgrade to udev vs the rules file.. because modern udev ignores "malformed" rules
<DX-MON>
(even if they're syntactically correcT)
<electronic_eel>
DX-MON: the udev rules just change permissions. when yorick ran lsusb with sudo, it should have shown up properly, regardless of udev rules
<DX-MON>
ah, that's true
<DX-MON>
I missed that they're having problems even as root
<yorick>
yep, 1.0.23 works with lsusb and glasgow, libusb 1.0.24 does not enumerate it
<DX-MON>
which is what 1.0.24-2 means in Arch land
<yorick>
I can try that
<whitequark>
hm this is weird, debian's libusb 1.0.24 works
<yorick>
did libusb not release that :/
<yorick>
maybe debian also backported the patch?
<DX-MON>
Debian probably has their own variant of that patch
<whitequark>
oh oops i missed the patch
<yorick>
we'll apply the patch in nixos
<DX-MON>
when I can find the spoons, I'll see about opening a PR with some of my udev rule changes to Glasgow so things are less bumpy for even more post-campaign new users
<whitequark>
sgtm
<d1b2>
<Attie> just comming back now - @yorick so it was a libusb issue?
<yorick>
yes
<d1b2>
<Attie> interesting, thanks for keeping us in the loop
<yorick>
I'm still rebuilding to test, but it's looking very likely
<d1b2>
<Attie> understood... i'd be very intrigued to know the details of what's gone wrong here - whether it's something unexpected in the glasgow descriptors, or if it's genuinely broken handling in libusb
<d1b2>
<Attie> digging into @DX-MON 's patch, it looks like an iphone was ignored / missed
<d1b2>
<Attie> *too
<DX-MON>
looking at that GH issue thread.. looks like it's a little from column A and a little from column B - libusb regressed and it might possibly be because Glasgow's descriptors are subtly broken
<yorick>
I've poked the libusb people about releasing libusb 1.0.25 in the meantime
<agg>
you can see why people just use HID, huh
<d1b2>
<Attie> looks like its affected a few devices, and there's a fix to libusb, so probably not worth worrying about glasgow 🙂
<DX-MON>
might still hook mine through Vizsla and see if I can figure out which exact descriptor it's tripping up on
<d1b2>
<Attie> you received it? 😄
<DX-MON>
'bout to give myself tons of practice on stream as I debug SPIFlashProgrammer..
<DX-MON>
mhm
<yorick>
electronic_eel: Attie: DX-MON: yes! applying this patch resolves both of my issues
<d1b2>
<Attie> yey / gl!
<yorick>
thanks a lot for your help!
<d1b2>
<Attie> brillaint! thanks for the feedback
<DX-MON>
ah, I'm glad you've got it working with that
<yorick>
the laptop was running an older libusb for my user installs (glasgow) vs my system packages (usbutils)
<_whitenotifier>
[glasgow] attie opened pull request #269: doc: add details about libusb bug - https://git.io/JtaIP