IRC log for #arm-netbook on 20100322

03:36.10*** join/#arm-netbook Baybal (~baybal@S0106001e58392615.vs.shawcable.net)
03:40.32*** join/#arm-netbook Baybal (~baybal@S0106001e58392615.vs.shawcable.net)
07:34.55*** join/#arm-netbook SQlvpapir (~teis@188.177.95.62)
10:49.16*** join/#arm-netbook lkcl (~lkcl@nat66.mia.three.co.uk)
12:30.16fjpbjdooks: I have Debian Installer running now, but getting spinlock recursion bug from dm9000.
12:30.51fjpI've tried cherry-picking some post-2.6.24 changes but they don't help.
12:30.59fjpis lost
12:39.45fjpStrange thing is that networking seemed to work fine with earlier custom kernels.
12:52.34*** join/#arm-netbook ibot (ibot@rikers.org)
12:52.34*** topic/#arm-netbook is ARM netbook GNU/Linux hacking - logs: http://ibot.rikers.org/%23arm-netbook
12:55.53fjpThis seems to describe it: http://lists.openwall.net/netdev/2007/11/20/152
12:56.10fjpBut that's before .24
13:02.12fjpYay! The patch posted there (although probably not 100% correct) works for me.
13:03.38fjpI do get one 'NETDEV WATCHDOG: eth0: transmit timed out', but after that DHCP is OK and networking works.
13:05.31fjpAnd partman shows the two flash cards :-)
13:07.02mnemoc:D
13:38.45fjplkcl: Looks like I'm going to get to keep the netbook :-)
13:53.58lkclyeay
14:09.31fjpUgh.
14:09.47lkclfjp: checking the chitech disassembly, the dm9000_timeout function looks nothing like that
14:09.56lkcli've alerted them to the problem.
14:09.59lkclugh?
14:10.07lkclwassup?
14:10.10fjpWhy the heck did I name the branches 2.4.27 and 2.4.33 instead of 2.6.24 and 2.6.33?
14:10.29lkcli have no idea :)
14:10.41lkcli um didn't want to say anything...
14:11.18fjpI think I'm going to have to fix that.
14:18.29fjplkcl: Looks nothing like what?
14:54.01bjdooksfjp: weird, the dm9000 works fine for us
14:54.43bjdooksone of my devboards is using dm9000 to provide nfsroot
15:03.46fjpbjdooks: Yeah. Any idea what could be causing the initial watchdog timeout?
15:05.00bjdooks#1 cause of problems is bad io setup
15:06.06fjpCould be. We do have an iomem bit that isn't present with the ChiTech kernel.
15:06.29fjp0000004a-0000004a : dm9000
15:06.33fjpf7600300-f76fffff : dm9000
15:06.33fjp<PROTECTED>
15:06.44fjpThe first line is extra.
15:07.16fjpBut after the initial timeout it works perfectly.
15:10.39fjpThe spinlock issue still seems to be present in current mainline code though if there ever should be a watchdog timeout.
15:11.09bjdookshmm, not seen a watchdog timeout in a while
15:11.19bjdooksthe machine on my left is running 2.6.33 + -simtec patchset
15:11.31fjpSee http://lists.openwall.net/netdev/2007/11/20/152
15:13.35bjdooksi think that got fied by ensuring dm9000_init_dm9000 required the caller to hold the spinlock
15:14.13fjpBut init calls dm9000_hash_table which still sets a spinlock
15:14.49bjdookshmm
15:30.05lkclfjp: the dm9000_timeout function in the chitech kernel looks nothing like the 2.6.24.7 dm9000.c that we have
15:30.09lkcllunch
15:34.06bjdookspersonally, don't care pre 2.6.32
15:34.53lkclbjdooks: interrupting lunch, so just a quick one: remember that chitech have those incorrect capacitor values and also the crossover with possible interference, and one person has reported that when charging, the dm9000 fails to operate correctly
15:35.04lkclso i think it "works for you" because you followed the app notes correctl
15:35.23lkclbut, for people who _haven't_, the dm9000 goes slightly wonky, gets unhappy and resets.
15:35.27lkclthis is "recovery"
15:35.39lkclit means that there is a _slim_ chance that the dm9000 will go wrong for you
15:35.39fjpUnderstand. But we're stuck with it a bit longer for this system.
15:35.45lkclbut for us it goes wrong _all_ the time.
15:36.06lkclbjdooks: yes, but we'll catch up once we have completely stable code, all drivers working :)
15:36.16fjpBut as I say, that spinlook issue looks to be still present in current mainline (.34-rc2)
15:36.29fjpspinlock even
16:05.56lkclso yes, it would simply be a matter of time before someone's dm9000, even on a "working" system, hit a problem, crashed, timed out and blam
16:07.20lkclbjdooks: btw, i negotiated with a company who are willing to sponsor the creation of an S5PC100-based SO-DIMM, with a license for ORCAD.
16:08.08lkcldo you think that you (or simtec officially) would be able to help, in return for rights to use+modify+distribute+etc. the resultant PCB designs?
16:20.36mnemoclkcl: hi,  please don't forget to mail me (and fjp) the business analysis you sent to mid-fun :)
16:20.43lkcloh good grief
16:20.58lkcloh wait - i know where it is: it's sent to legal@lists.gpl-violations.org
16:21.01lkcli remember now.
16:21.11lkclyou can find it on lists.gpl-violations.org
16:22.28mnemoclkcl is it supposed to be an attached pdf or something else?
16:22.33lkclno, email
16:23.35mnemocso you will make me read all the related threads :< .... ok
16:23.54mnemochttp://lists.gpl-violations.org/pipermail/legal/2010-March/thread.html
16:37.21mnemoci have to admit the thread is good reading actually
16:43.18mnemochttp://news.gmane.org/gmane.law.gpl.violations.legal <--- much better ui
16:47.30fjpwonders if the whole approach is not too aggressive; especially taking Chinese culture into account
16:48.39fjplkcl: I seriously doubt that that patch is needed for them if their timeout function is so different.
16:49.07lkclwell...
16:49.09fjpAlso, the patch is far from ideal as it will run the init function without spinlock protection.
16:49.15lkclouch!
16:50.56lkcli started out fine.  the repeated stating of the "give us lots of money and we'll give you the code" position is what really did it, for me.
16:51.12fjpHmm. But dm9000_open also calls _init without spinlock
16:51.13lkclthey made it clear that they hadn't read what i'd written.
16:51.19lkclso...
16:51.21lkclshrugs
16:51.44fjpMaybe best to forget about them for now and concentrate on backporting
16:51.50lkclyes.
16:52.13lkclthat seems to work well - it takes them a good couple of days to translate / process what we write.
16:52.26fjpBTW, to check your code, wouldn't it make sense to compare disassembies of their and our kernels?
16:52.44fjpE.g. for current state of poweroff?
16:56.10lkcli was thinking about doing that, but it's such a pain doing the disassembly that i was just going to use gcc -E if needed
16:56.15lkclsorry gcc -s
16:56.53fjpthinks the patch is OK for now; if things go splat we'll find out soon enough
16:57.34lkclit's taken several days to identify  functions and data - eventually i wrote an IDC script which could turn 12,000 addresses into functions (!)
16:58.08lkclyes.  remember i did accidentally activate the poweroff GPIO in smdk6410_machine_init so i know it's correct :)
16:58.40fjpWhat we have currently doesn't work yet.
16:58.52*** join/#arm-netbook SQlvpapir (~teis@188.177.95.62)
16:59.31fjpBTw, you know that you have to edit arch/arm/mach-s3c6410/mach-ctpc89e.c now, right?
17:01.25lkclyes
17:01.53lkclfjp: i'll check it again
17:19.07SQlvpapirlkcl, how do we tell the machine to boot from SD card instead of the nand? if I copied it to the SD card with dd as you suggested in your mail what do you expect to happen?
17:23.18lkclthere's a switch on the *underside* of the so-dimm
17:23.20lkclflick it
17:23.51lkcli _believe_ - the hypothesis is - that this is wired to the s3c6410 pin which says "please boot from mmc drive 1 instead of 0"
17:23.54lkclsimple as that
17:23.58lkclbut, it could be total shite.
17:24.02lkclsomeone has to try
17:24.50lkclif it's the case, then it is brilliant, because we can recover machines, and also begin reverse-engineering u-boot _without_ bricking the machine.
17:25.17lkclis off shopping
17:36.27fjpQ is: how do you verify that it actually booted off the SD card instead of nand...
17:37.24fjpI think you'll have to change something on th SD card to be able to check.
17:42.38bjdooksthe s3c6410 has a set of pins which are read at startup to determine boot mode
17:54.42SQlvpapirI noticed the screw near the SD card slot is missing
17:55.04fjpI have that! I had a loose screw in mine.
17:55.33SQlvpapirwell what do you know :)
17:55.52SQlvpapirI found the appropriate screwdriver so I'm going in now
17:56.32SQlvpapirlkcl, since you had it open, are all the external screws the same?
17:56.53fjpNo. Two are slightly longer.
17:57.32SQlvpapirta
17:57.32fjpI'm not 100% sure, but I've used them in the outside back holes.
17:57.40fjpWould be nice if you could confirm.
17:58.10fjpoutside rear I mean
18:00.24SQlvpapirhmm I'm not very good at this :p
18:03.24SQlvpapirlkcl, did you use force or did you 'pry' it open with a flat screwdriver? it seems to fit very good in the read (near screen hinges)
18:05.18SQlvpapirlkcl, maybe I missed something.. screws under the rubber standoffs?
18:06.00fjpSQlvpapir: You need to lift out the keyboard first. There are clips at the rear.
18:07.26fjpThen disconnect the keyboard; remove the three screws holding the plate below it; disconnect the touchpad; remove that plate.
18:08.58SQlvpapirfjp, can the tiny 3 'pins' holding the keyboard down near the screen be pushed in?
18:09.19SQlvpapirmaybe I should get glasses
18:09.55fjpNo. You just have to widen the gap a bit and nudge the keyboard up.
18:10.02SQlvpapiroh I see
18:10.15SQlvpapirjust had success with brute force
18:10.39fjpMain thing is not to break off the clips...
18:15.30SQlvpapiramazing
18:29.47SQlvpapira AAA battery is too big. I'll have to speak with my electronics guy to see what kind of capacity can be crammed in there
18:31.21SQlvpapirwas surprised to see that there is no 2nd antenna cable for 3g
18:32.25SQlvpapirall I've got (not-in-use) is a 16gb sdhc card, will give it a try after the movie.
18:36.57lkclSQLvpapir: yes be VERY careful removing the keyboard connector.
18:37.41lkclSQlvpapir: if it's an SATA / PATA one it will not work.  only USB devices will work.  plus, there are some GPIO pins that are needed to be pulled to activate power to the PCI-e
18:38.15lkclit's assumed that you're going to put a WIFI or a 3G modem in there, so to save power, they're left switched off
18:55.54fjphas kernel module udebs now
18:56.28lkclfjp: just remembered: adam had the dm9000 disconnect whenever he connected power.  from this i conclude that the capacitors lacking that bjdooks noticed are causing fluctuations, causing the dm9000 to crash, triggering the dm9000_timeout, BLAT, segfault, bye bye ethernet.
18:56.55lkclso, there is some evidence to suggest that yes, their binary kernel has the same issue
18:57.03lkclyaay, well done
18:57.56fjpI've noticed that eth0 is always slow to come up, even with the original kernel.
19:03.38fjpHmm. We don't have the wireless driver in this kernel source, do we?
19:06.52SQlvpapirlkcl, I thought I broke it at first but its a different style than I'm used to
19:07.03lkclwhat is?
19:07.19lkclohh, the clip on the keyboard connector?
19:07.30lkclyes, there are two styles.
19:07.42lkclthis one's cheaper.
19:07.50lkclBE VERY CAREFUL when pushing it back in.
19:08.28lkclfor the mouse one, i recommend you disconnect _both_ ends, then insert into the PCB first, and into the trackpad second.
19:08.38lkcli think...
19:08.51lkclyes.  i believe you'll find it's easier that way round.
20:54.41SQlvpapirlkcl, my netbook is fitted with a chrontel 7026b-tf
20:54.56SQlvpapirwhere your picture has nothing
20:56.04lkclwoot!
20:56.50SQlvpapirjust noticed
20:56.56SQlvpapirwill upload picture in a bit
21:00.16SQlvpapirlkcl, only ~1mbit upload so please do not link to it in the mailing list ;) feel free to use the picture though http://dreijer.dk/~teis/20100322451.JPG
21:01.36SQlvpapirnow I begin to wonder how many of the netbooks are equipped with what
21:05.35SQlvpapirmaybe they simply ran out of the little fellas. thats the only difference I've been able to spot
21:09.28SQlvpapirfjp, ^^
21:10.15fjpNo idea. I haven't taken out the mainboard yet.
21:14.00fjpA 30 sec timeout is just enough for the eth0 watchdog timeout and to get DHCP.
21:14.57mnemoca tv chip???
21:15.19fjpis not that interested as he does not have a TV...
21:16.19SQlvpapirmnemoc, the datasheet sites link to is dead and there is not much info in the top20 list
21:17.01SQlvpapirbut its supposed to be able to do 720p.. I'm hoping its either dvi or hdmi, but I dont really have a clue about that.
21:17.09SQlvpapirmnemoc, did you have a look inside yours?
21:17.17mnemocnot yet
21:17.57mnemoci hope to have some time this weekend
21:18.50SQlvpapirmnemoc, note the difference above the sd card slot http://dreijer.dk/~teis/20100322451.JPG (takes 30s to load) http://lkcl.net/arm_systems/CT-PC89E/photos/IMG_3145.jpg
21:19.31mnemocfjp: how much quota we got in alioth for the wiki? (to host pictures of the different boards)
21:19.55fjpmnemoc: No fixed quota.
21:20.08fjpBut don't abuse the diskspace...
21:20.32fjpBetter to upload reduced resolution/size images when possible.
21:20.39fjpAnd no duplicates.
21:20.55mnemocfjp: sure.... but first the admin has to install and setup the wiki ;-)
21:21.08fjpWell, see my mail.
21:21.21fjpWe already have wikis we can use elsewhere.
21:21.32mnemocelinux?
21:21.45fjpYes, and the standard Debian wiki.
21:22.40fjpIf it's really wanted, fine.
21:23.02fjpBut if we can do with a simple static page on alioth with links, that's fine too.
21:25.14lkclSQlvpapir, is there an sdcard holder?
21:26.38SQlvpapirlkcl, huh?
21:27.05SQlvpapirsd(hc) card is working fine if thats the question
21:28.04lkclsorry, simcard holder
21:28.20lkclis there a simcard holder attached
21:28.38SQlvpapirwill check in 5
21:29.55lkclack.
21:30.37SQlvpapirnope nothing
21:35.42fjpHmm. Installing using ext4 to a USB stick does not work: fs cannot be mounted; ext2 works fine
21:36.09fjpCould be that ext4 support in .24 isn't good enough. Or maybe something else.
21:36.40fjpBut, it's installing.
21:36.54fjpLet's see if it wants to install the kernel from alioth...
21:37.18mnemocext4 started to be decent around .30
21:37.42mnemocthe experimental flag was removed in .28
21:38.10fjpBut even with the last 2 upstream kernels there were still plenty of fixes.
21:38.18mnemocand i still have panics in ubuntu/2.6.31
21:38.35fjpSo what FS should we use for now on SD card, given .24?
21:38.53mnemocext2 i would say
21:39.17mnemocanything with journal will kill the card
21:39.23fjpYes. That's what I was thinking. On small SD cards a journal does not really make sense.
21:39.32fjpOpinions vary about that.
21:39.46fjpSwap is advised against.
21:40.03mnemocminize the writes as much as you can
21:40.17mnemocminimize*
21:40.23fjpjournal only causes many more writes with some tasks
21:40.25fjpYes.
21:40.33fjpNeed to tune logging as well.
21:41.33fjpI doubt the base system will fit on my 256MB USB stick..
21:42.05mnemocusb/sata ?
21:42.58mnemocfor development an external sata disk will do great
21:43.13mnemocfor real life... you will need to switch to emdebian anyway
21:43.35fjpHmm. Could use my external USB hard disk maybe.
21:43.36fjpYes.
21:43.55mnemocyou only need to *boot* from the SD
21:45.20fjpYes. I'm planning to use the nand for a minimal / only and have the rest on the external SD card.
21:47.45fjpSo, should I add emdebian by default to the sources.list?
21:48.16fjpDo they already have a squeeze archive?
21:49.00mnemochttp://www.emdebian.org/grip/
21:49.12mnemoc"Grip is a light grip on Debian Squeeze"
21:51.03mnemocif i were you (actually, if i would have time) i would use the normal debian and a usb/sata for storage/building and SD for swap until .33 is running and then debootstrap grip into the NAND
21:54.34mnemoci actually have to find the time to do the same with my frelling gdium or the patchset from mandriva with get unusably old again (lastest is .29) .... with the difference that the gdium doesn't have a NAND but a 16GB usb stick
21:55.57mnemocusign coreutils, full NLS and glibc in the chitech is kind of sucidal
21:57.17mnemoci really need to get those patches in sync with the work lemote is doing
21:58.02mnemocbut at least a .deb of that .29 (instead of the current .24)
22:00.38mnemoci want "spare" time! :'(
22:29.19SQlvpapirI dd'ed mmcblk0 to mmcblk1. the machine is still open but I'll wait with the switch-flipping until I've had some sleep
22:41.06*** join/#arm-netbook lkcl (~lkcl@nat65.mia.three.co.uk)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.