Back
[19:58:49] <andypugh> Sep 19 01:37:09 dn2800 kernel: [12179.901096] RTAPI: Task 1[f5e68800]: Fault with vec=13, signo=11 ip=f829f2c5. ---- cat/proc/modules --- hm2_pci 9808 0 - Live 0xf829f000 ----- addr2line -e hm2_pci.ko 0x2c5 ------
[19:59:30] <andypugh> hm2_pci.c:204 ----- *(u32*)buffer = *(u32*)src;
[19:59:54] <andypugh> I am thinking that just isn't where my problem is?
[20:05:22] <andypugh> The problem occurs when I start threads. That addr2line puts the error in hm2_pci_read which I rather suspect is one of the most dependable bits of code in the whole package
[20:27:06] <jepler> it could fault there if board->base is wrong, if addr is an unexpected value, if size is an unexpected value, or if buffer is not valid or doesn't point to big enough storage
[20:28:01] <jepler> or if seb's august 3 change to that function has some not-yet-spotted bug :-P
[20:30:13] <jepler> if you objdump -d hm2_pci.ko and look for the instruction at address 0x2c5 and see whether it is the load or store; that will tell you whether to suspect addr or buffer more
[20:30:42] <jepler> (assuming it hasn't been optimized into a rep movsl or so)
[20:30:58] <andypugh> For the time being I am blaming me, and will look more carefully tomorrow.
[20:31:54] <andypugh> Most probably I have carelessly written out-of-bounds or similar.
[20:32:38] <andypugh> Though previously addr2line has not missed the target.
[20:33:10] <jepler> it occurs to me that if you wanted to do your work on top of the UB3 branch you would potentially have a hostmot2 driver you could debug in gdb, and might be able to get away without rebooting after each crash
[20:33:18] <jepler> don't worry, the crash can occur on that line *and it can be 100% your fault*
[20:33:26] <jepler> like if you passed in NULL for buffer, f'rinstance
[20:33:54] <andypugh> Yes, the thought of moving to UB3 and into userspace does seem appealing at these junctures.
[20:35:03] <andypugh> But then I realise that I have no idea how to use gdb, and go back to what I know. (also, this isn't reboot-every-time bad. That was earlier in the evening.
[20:35:15] <jepler> that's worth something then
[20:35:34] <jepler> it's true, you would probably lose at least one evening to building ub3 and getting the most basic gdb under your belt
[20:36:28] <andypugh> And I have one evening to fix the broken driver I pushed at the weekend (I am away from friday to sunday_
[20:36:49] <andypugh> And it's too late to manage much more tonight)
[20:36:55] <jepler> go have a sleep, then
[20:37:37] <andypugh> The SSI driver is currently perfect unless you have more than one encoder...
[20:37:59] <jepler> you should be able to simply find the place you wrote "1" and write a bigger number there.
[20:38:05] <jepler> <j/k>
[20:39:51] <jepler> you might have to not only use ub3 branch but also get an rt-preempt kernel :-/
[20:40:29] <andypugh> I have that, I did some testing there.
[20:40:45] <andypugh> I think I see two huge clues:
[20:40:46] <andypugh> http://pastebin.com/uKLmVQ4M
[20:41:15] <jepler> Sep 19 02:23:06 dn2800 kernel: [14934.487959] hm2/hm2_5i25.0: command_addr: 0xC0516250
[20:41:21] <jepler> yes that seems like it sure could be a wrong value
[20:41:33] <andypugh> And, thinking about it, I did have "Sep 19 02:23:06 dn2800 kernel: [14934.481999] hm2/hm2_5i25.0: We don't handle BISS or Fanuc yet, sorry"
[20:42:24] <andypugh> So, it's probably just that I didn't actually write those bits of the driver yet, and I can basically relax.
[20:43:23] <andypugh> (I was testing config string entries,and forgot that once they worked I would hit lack-of-driver bugs :-)
[20:45:04] <jepler> oh
[20:46:15] <andypugh> If I leave out the BiSS and Fanuc configs, 'tis all fine :-)
[20:55:20] <andypugh> I never hit "the zone" coding stuff at home. When you have a list of things in your head part-coded and eventualities to cover, and dare not stop typing in case you drop a thread, no matter how late you have to stay. IRC, email, and just, actually, being at home in your own time get in the way. It's a satisfying place to be though, perhaps I should turn off the net, hide the wine, and just get down to it. But this
[20:55:21] <andypugh> (for me) a hobby.
[20:59:24] <jepler> it's been hard fo rme to find the hobby in linuxcnc for a couple of years now
[21:00:31] <jepler> I used to come home and code linuxcnc for 4, 6, 8 hours a night .. it's just not that gripping for me anymore
[21:00:43] <andypugh> I keep switching areas. I was building machines and machining stuff between Wichita and a few weeks ago
[21:00:44] <jepler> but that's OK, it is still a project with lots of interested and capable people
[21:01:44] <jepler> anyway, just in case it helps you next time around, I went ahead and wrote up some (verified!) instructions on how to run the debugger on the ubc3 branch.
http://emergent.unpythonic.net/01379554481
[21:02:34] <andypugh> This SSI stuff was meant to be a short easy project to get my dev systems working and me onto coding. However it has turned out to be hard, I am not sure that the plan to do this then get back to tool table is going to happen that way.
[21:07:33] <andypugh> It's actually quite interesting. We had a driver for each hm2 module, then PCW created smart-serial where the modules tell us what data they take/make and how that is packed in the bit registers, then SSI / BiSS came along where the users need to tell us how the data is packed into the bit stream, and now I rather suspect that the whole of hm2_encoder.c could be encapsulated in a string like "counts%32sindex-enabl
[21:09:18] <andypugh> It's a classic case of "if we were starting now, we would do it differently". And I am _still_ impressed by how many layers of abstraction seb put in the original driver.
[21:10:37] <andypugh> Seb put in arbitrary interfaces with arbitrary cards. I added arbitrary modules with arbitrary pins.
[21:18:22] <andypugh> Anyway, gdb clues bookmarked, thanks. Time to sleep.
[22:04:47] <KGB-linuxcnc> 03jepler 05master c73f4da 06linuxcnc 10src/hal/drivers/mesa-hostmot2/ 10hostmot2.c 10hostmot2.h 10pins.c * undo unintended permissions changes
[22:04:47] <KGB-linuxcnc> 03jepler 05master f745010 06linuxcnc 04configs/sim/gscreen_custom/sim.tbl.bak * backup file should not be tracked by git
[22:04:51] <KGB-linuxcnc> 03jepler 05master a7ccc9a 06linuxcnc 10(9 files in 4 dirs) * Add license notices
[23:02:45] <linuxcnc-build> build #1018 of deb-hardy-rt-binary-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-rt-binary-i386/builds/1018 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:05:14] <linuxcnc-build> build #1016 of deb-hardy-sim-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-sim-binary-amd64/builds/1016 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:05:33] <linuxcnc-build> build #1015 of deb-hardy-sim-binary-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-sim-binary-i386/builds/1015 blamelist: Jeff Epler <jepler@unpythonic.net>