| === bjf is now known as bjf-afk | ||
| billybigrig | anyone know why i can't build the nvidia module? | 00:20 |
|---|---|---|
| billybigrig | billybigrigger@cabo:~$ sudo dkms build -m nvidia -v 185.18.14 -k 2.6.31-rc2-billybigrigger-07.13 | 00:22 |
| billybigrig | Error! Bad return status for module build on kernel: 2.6.31-rc2-billybigrigger-07.13 (x86_64) | 00:22 |
| billybigrig | *** Unable to determine the target kernel version. *** make: *** [select_makefile] Error 1 | 00:32 |
| billybigrig | no body can answer? | 00:51 |
| jjohansen | smb: I have tested Jaunty on my machine now with suspend and hibernate kernel builds, no thermal problems. But under 11.1 it goes into thermal shutdown | 10:33 |
| apw | jjohansen, heh thanks for the testing there | 10:40 |
| smb | jjohansen, that sounds good, yet unexpected. but thanks for testing :) | 10:40 |
| Keybuk | apw: err, you didn't include the inotify patches I sent in the most recent kernel upload ? | 12:16 |
| apw | Keybuk, hrm, tim actually put that upload together | 12:17 |
| apw | ok tim said "i'll apply if they don't make it into -rc3" ... | 12:18 |
| apw | did you check if they made it in via mainline ... | 12:18 |
| Keybuk | they aren't in mainline yet | 12:18 |
| Keybuk | which is why I forwarded them | 12:18 |
| apw | hrm | 12:19 |
| apw | Keybuk, i'll look at them now | 12:20 |
| apw | Keybuk, is there a bug for these regressions? | 12:31 |
| Keybuk | apw: a bug? | 12:32 |
| Keybuk | not in LP, I went directly to the upstream ;) | 12:32 |
| apw | yeah a lp bug number? if so i'll include it | 12:32 |
| Keybuk | I can open a bug if you like | 12:32 |
| apw | no need, just would use it if there | 12:32 |
| apw | Keybuk, you need a test kernel for these? | 12:33 |
| Keybuk | apw: no, just a release | 12:33 |
| Keybuk | already tested Eric's patches for him | 12:33 |
| apw | ok thanks | 12:33 |
| apw | i think i am out of the country | 12:34 |
| apw | in dublin. need to confirm when i get back exactly | 12:35 |
| Keybuk | ? | 12:35 |
| apw | gah wrong channel | 12:35 |
| apw | Keybuk, ok they are applied so they deffo make the next upload | 12:50 |
| apw | will talk to tim about getting that to be soon | 12:50 |
| Keybuk | apw: could we do an upload especially please | 12:50 |
| Keybuk | without these patches, inotify is basically useless | 12:51 |
| apw | i am sure we can, just want to touch with him to see if there is anything else urgent | 12:52 |
| apw | will start preparing it | 12:52 |
| tseliot | amitk: do you deal with input devices in the kernel? | 13:26 |
| UnderSampled | hello | 13:31 |
| UnderSampled | I get WARNING at /build/builddd/linux-2.6.28/kernal/smo.c:333 smo_function_mask+0x1d4/0x1e0() | 13:31 |
| UnderSampled | Whenever I boot into 9.04, whether that mean into a live cd, the 'check disk for errors', or after upgrading 8.10 to 9.04 after a fresh install | 13:33 |
| UnderSampled | oh, and the capslock and scrolllock keys blink at a constant rate | 13:34 |
| UnderSampled | Any Ideas? | 13:34 |
| amitk | tseliot: not specifically | 13:44 |
| tseliot | amitk: I have a doubt on passing EVIOCGID to ioctl() and on using id[ID_VENDOR], id[ID_PRODUCT], id[ID_VERSION] to check the model of a touchpad | 13:46 |
| tseliot | amitk: would it make sense to check id[ID_VERSION] to identify a specific model when id[ID_VENDOR] and id[ID_PRODUCT] are the same for all Synaptics touchpads? | 13:47 |
| tseliot | note: I called ioctl(fd, EVIOCGID, id) | 13:48 |
| tseliot | I would like to use it to add quirks to the synaptics driver | 13:50 |
| rtg_ | apw, by the way, there are 2 Karmic commits with an identical log message; 6325628641e58310d93acd8f0261a76752e38544 and 14b5433606289dbc5b6fd70ced11462f80e95003. How did the first one get there? It doesn't exist in Linus tree. | 13:52 |
| === bjf-afk is now known as bjf | ||
| apw | rtg_, i see the first one as a stable commit which we applied, and the second is a real upstream commit | 13:54 |
| apw | i see that one in my linus tree too | 13:55 |
| apw | i would guess it may have gotten reverted | 13:55 |
| * apw checks | 13:55 | |
| rtg_ | apw, carried forward from Jaunty? It should have disappeared | 13:55 |
| apw | yes, unless someone reverted the original upstreaming ... will check | 13:55 |
| amitk | tseliot: I don't see drivers/input/mouse/synaptics.c having any ioctls | 13:55 |
| apw | rtg, no by extreme bad luck it applied twice | 13:56 |
| apw | if (scan->channel_count == 0) { | 13:56 |
| apw | IWL_DEBUG_SCAN(priv, "channel count %d\n", scan->channel_count); | 13:56 |
| apw | goto done; | 13:56 |
| apw | } | 13:56 |
| apw | if (scan->channel_count == 0) { | 13:56 |
| apw | IWL_DEBUG_SCAN("channel count %d\n", scan->channel_count); | 13:56 |
| apw | goto done; | 13:56 |
| apw | } | 13:56 |
| apw | looks benign | 13:56 |
| apw | we can drop that one on the next rebase | 13:56 |
| * apw reverts it in our tree | 13:57 | |
| rtg_ | apw, it causes an error when IWL_DEBUGFS is defined. | 13:57 |
| tseliot | amitk: I meant the Synaptics X driver. ID_VENDOR, ID_PRODUCT and ID_VERSION are defined in input.h though. | 13:57 |
| apw | rtg_, yeah it looks like the number of params to IWL_DEBUG_SCAN has changed and its left behind | 13:57 |
| apw | just revert it | 13:57 |
| rtg_ | apw, why not just rebase and drop the commit altogether? It'll avoid future conflicts | 13:58 |
| apw | well i guess i should | 13:58 |
| apw | yep, can do, after this upload? | 13:58 |
| rtg_ | might aswell do it now | 13:58 |
| apw | ok | 13:58 |
| UnderSampled | Could someone please help me trouble shoot> | 14:05 |
| amitk | tseliot: you'll have to try it. But it seems like the model id is stored in the synaptics driver's private data structure | 14:08 |
| tseliot | amitk: ok, thanks | 14:09 |
| amitk | tseliot: http://lxr.linux.no/linux+v2.6.30/drivers/input/mouse/synaptics.c#L652 | 14:09 |
| amitk | and http://lxr.linux.no/linux+v2.6.30/drivers/input/mouse/synaptics.c#L167 | 14:10 |
| tseliot | amitk: it says "Encode touchpad model so that it can be used to set input device->id.version and be visible to userspace" | 14:11 |
| mjg59 | tseliot: What quirks do you want to add? Note that several cases where we'd like to add quirks (the Dell mini, for example) don't have any destinctive information in the vendor or ID fields | 14:13 |
| tseliot | mjg59: I know how to prevent the cursor from jumping on the Dell Mini 10v: http://bugs.freedesktop.org/show_bug.cgi?id=21614 | 14:14 |
| ubot3 | Freedesktop bug 21614 in Input/synaptics "Touchpad cursor jumps when two fingers are used" [Normal,New] | 14:14 |
| tseliot | mjg59: and since that code doesn't solve the problem on all touchpads I wanted to add a quirk for the Dell | 14:15 |
| tseliot | and checking ID_VENDOR, ID_PRODUCT and ID_VERSION should be enough | 14:15 |
| mjg59 | tseliot: It's not | 14:16 |
| mjg59 | tseliot: You get identical values to the Eee | 14:16 |
| mjg59 | Sorry, not the Eee. Some Aspire Ones. | 14:16 |
| tseliot | mjg59: you get identical ID_VENDOR and ID_PRODUCT because they are Synaptics but do you also get the same ID_VERSION? | 14:17 |
| mjg59 | Yes | 14:18 |
| tseliot | oh | 14:18 |
| tseliot | mjg59: so are you saying that quirks are not possible? | 14:18 |
| mjg59 | No, I'm just saying that you're concentrating on the wrong aspect of it | 14:19 |
| tseliot | ok | 14:19 |
| tseliot | any suggestions? | 14:19 |
| mjg59 | The ones that people are having problems with all appear to be Synaptics (as opposed to ALPS or Elantech) without two-finger detection | 14:19 |
| mjg59 | So you could possibly just key it off that? | 14:20 |
| tseliot | mjg59: maybe. I need to check what my other Synaptics touchpads report. | 14:21 |
| smb | mjg59, While you are around, might I abuse your time with another quirk question? In that case acpi_video... | 14:22 |
| smb | I looked at a bug report where people had regressions with backlight control. From the acpi dump and the dmesg it looks clear that the problem is that the only acpi video device with _BCL defines a _ADR with a pci device id that does not exist. So with kernels before the check people got working backlight control (though it sounds strange) but with it they don't. | 14:25 |
| mjg59 | What hardware is this? | 14:27 |
| smb | mjg59, Are you aware of similar cases and how would be the chances for dmi quirks in that area? | 14:27 |
| smb | Acer 6920G | 14:27 |
| mjg59 | Does acer-wmi work? | 14:27 |
| smb | no | 14:27 |
| mjg59 | Unfortunate | 14:27 |
| mjg59 | Got the bug number? | 14:27 |
| smb | Pretty much. Yep, a sec | 14:28 |
| smb | https://bugs.launchpad.net/bugs/333386 | 14:28 |
| ubot3 | Malone bug 333386 in linux "Cannot change brightness with 2.6.27-11+ kernel" [Medium,Confirmed] | 14:28 |
| === bjf is now known as bjf-afk | ||
| smb | mjg59, I would have tried with an external DSDT file but iasl explodes more or less when trying to recompile | 14:30 |
| mjg59 | Oh, ugh. It's one of those bugs where unrelated issues have appeared. | 14:30 |
| smb | mjg59, Yeah, its sometimes hard to keep "my backlight does not work" outside | 14:32 |
| mjg59 | smb: I think the user's doing something wrong when trying to use acer-wmi | 14:32 |
| smb | mjg59, But in the end I concentrated on the Acer and saw that _ADR for GFX0 is 0002000 while the video device seems to be 01.0 | 14:32 |
| mjg59 | I can't see any way he can get permission denied if he's actually running as root, which makes me think he's doing sudo echo foo >brightness | 14:33 |
| mjg59 | Which won't work | 14:33 |
| mjg59 | Oh, I see, he did finally check that | 14:33 |
| smb | mjg59, It was part of my learning curve to find out what regressed as well. | 14:33 |
| mjg59 | Is he using the binary nvidia drivers? | 14:33 |
| mjg59 | If so, brightness control gets more complicated | 14:33 |
| === bjf-afk is now known as bjf | ||
| mjg59 | Because they disable the SMI access that the legacy paths use | 14:34 |
| mjg59 | The smartdimmer pins may be hooked up | 14:34 |
| smb | mjg59, I am not 100% sure. But as he says he has a working backlight when using the kernel just before we pulled the pci checking patch and there he had gfx0 I assume that case is good | 14:34 |
| mjg59 | It may have worked by accident | 14:35 |
| smb | It seems at least some sort of accident as the acpi information is so incorrect. I can give him a recent kernel without the check to compare. But the question is how to move on | 14:36 |
| mjg59 | The machine will come in two forms - integrated Intel and discrete Nvidia | 14:37 |
| mjg59 | The same DSDT is used on both | 14:37 |
| smb | The next kernel update will get that laptop back into that state (unless nouveau is better at controlling the backlight without acpi support) | 14:37 |
| mjg59 | The ACPI information appears to be for the Intel device, not the nvidia one | 14:37 |
| mjg59 | novueau will drive the backlight if the smartdimmer pins are hooked up | 14:37 |
| mjg59 | Assuming recent enough nouveau | 14:38 |
| mjg59 | But he's using the binary nvidia drivers | 14:38 |
| smb | Somehow this accidental thing looks a bit like that T61(?) case | 14:38 |
| mjg59 | Yes | 14:39 |
| mjg59 | The Radeon code on the T61 happens to work on the Intel hardware as well | 14:39 |
| smb | The whole information obviously is for the wrong device but some way it works when being poked at | 14:39 |
| mjg59 | But the correct approach is to use the opregion code in recent i915 | 14:39 |
| mjg59 | That's why the patch didn't get merged until the opregion stuff was added | 14:40 |
| smb | So here is the other direction, the nvidia device seems to react on the intel defined device. The nvidia device in acpi does not define any backlight control, so the only reasonable way would be to have the nvidia driver doing something (if possible) or a bios update (guess unlikely). | 14:43 |
| mjg59 | Correct | 14:43 |
| mjg59 | Unless nvidia have a sideband brightness interface | 14:44 |
| smb | Even worse as that laptop seems to come up with extremely dimmed backlight. :/ | 14:44 |
| mjg59 | Which is possible, I haven't figured out what all of their ACPI methods do yet | 14:44 |
| smb | Hm, a sideband brightness interface? Would that be visible in the acpi code? I am slowly digging my way into that area... | 14:46 |
| mjg59 | Uh. | 14:46 |
| mjg59 | I see a _BCL and _BQC in his DSDT for the nvidia device. | 14:47 |
| mjg59 | Under PEGP | 14:47 |
| mjg59 | And again under NVGA | 14:47 |
| mjg59 | One of those ought to be bound | 14:48 |
| smb | mjg59, Arg, sorry. I believe the problem was _DOD _DOS | 14:48 |
| mjg59 | Those shouldn't be required for brightness changing | 14:48 |
| mjg59 | They're just the display switch hotkeys | 14:48 |
| mjg59 | Let me look at the kernel | 14:48 |
| mjg59 | Right, they're only under the Intel one | 14:49 |
| smb | GFX0 is the only one defining thoise. and acpi_video check for them to decide this is a video device | 14:49 |
| mjg59 | Sigh. | 14:49 |
| mjg59 | Ok, acpi_video needs fixing not to have that requirement | 14:49 |
| smb | o some other values which are not there | 14:49 |
| mjg59 | But I can see why it would make that assumption | 14:49 |
| smb | I think it was three different set of methods. If any of those sets is there the check is good | 14:50 |
| mjg59 | Yeah, and this doesn't have any of them | 14:50 |
| smb | But _DOD, _DOS was the only set present for any device | 14:50 |
| smb | So GFX0 (the intel) is the only candidate for acpi_video | 14:51 |
| mjg59 | Yeah | 14:51 |
| mjg59 | But the spec doesn't actually require that | 14:51 |
| mjg59 | It should also check the children and see whether they have any backlight control methods | 14:52 |
| smb | So basically backlight control gets somewhat independent of the video device itself (if that is formulated understandably) | 14:53 |
| mjg59 | /kind/ of | 14:53 |
| mjg59 | What's weird is that EVGA and NVGA both seem to have the same addresses | 14:53 |
| mjg59 | Oh, wait, I think I see a minimal patch | 14:54 |
| smb | hasn't NVGA adr zero | 14:54 |
| mjg59 | So does EVGA | 14:54 |
| mjg59 | They're both children of PEGP | 14:54 |
| smb | Oh, I see | 14:55 |
| mjg59 | ANyway | 14:55 |
| smb | Hm, yeah and _DOD is there for several devices, only _DOS is there once | 14:56 |
| mjg59 | Does http://www.codon.org.uk/~mjg59/tmp/acpi_switch.diff fix it? | 14:56 |
| smb | I'll create a kernel with it and we will see | 14:57 |
| smb | I haven't got the hardware, so I need to put it into the bug report | 14:57 |
| mjg59 | As long as that gets it recognised it looks like it'll work - the code is identical | 15:01 |
| mjg59 | So I think I'll just submit that upstream anyway | 15:01 |
| smb | mjg59, Thanks for now. Somehow I missed that _DOD is present for all devices and might be used as an alternative. | 15:02 |
| mjg59 | Ok | 15:02 |
| mjg59 | Let me know if it works | 15:02 |
| mjg59 | Note that it probably won't do anything for any T61 people | 15:02 |
| smb | mjg59, Sure. Yeah, probably this setup is different. But for the time being we can fix those with acpi_backlight=vendor and thinkpad-acpi backlight=1 | 15:03 |
| mjg59 | T61 should work fine upstream | 15:03 |
| mjg59 | You need the i915 opregion support code | 15:04 |
| smb | Oh, likely yes. I was more referring to Jaunty which is missing that but has the check slipped in | 15:04 |
| amitk | NOTICE: Upcoming Ubuntu Kernel Team Meeting - Tuesday, 14th of July - 17:00 UTC i.e. Today, in about an hour in #ubuntu-meeting | 16:02 |
| === amitk changed the topic of #ubuntu-kernel to: "Home: https://wiki.ubuntu.com/KernelTeam/ || Karmic Kernel Version: 2.6.31 || Ubuntu Kernel Team Meeting - Tuesday, 14th of July - 17:00 UTC" | ||
| bjf | amitk, that's in 2 hours right? | 16:06 |
| amitk | bjf: err, right. | 16:07 |
| amitk | NOTICE: Upcoming Ubuntu Kernel Team Meeting - Tuesday, 14th of July - 17:00 UTC i.e. Today, in about 2 hours in #ubuntu-meeting | 16:07 |
| amitk | :) | 16:07 |
| UnderSampled | can someone help me with this? | 16:53 |
| UnderSampled | http://yfrog.com/5fdumpij | 16:53 |
| tseliot | mjg59: there must be a bug somewhere (in the kernel?) as the Synaptics driver (when testing BTN_TOOL_DOUBLETAP) reports that the touchpad of the Dell Mini 10v multi-finger detection but, as evtest shows, it's not true | 16:55 |
| tseliot | s/multi-finger/has multi-finger/ | 16:56 |
| mjg59 | tseliot: Can you put dmesg somewhere? | 16:56 |
| UnderSampled | hello hggdh | 16:57 |
| hggdh | UnderSampled: hello | 16:57 |
| tseliot | mjg59: http://pastebin.ubuntu.com/218063/ | 16:59 |
| UnderSampled | I just tried the alternate install disk, but it does the same | 17:01 |
| mjg59 | tseliot: What kernel version are you looking at? | 17:01 |
| tseliot | mjg59: Jaunty's i.e. 2.6.28-11-generic | 17:02 |
| mjg59 | Looks like it was fixed in .29 | 17:03 |
| UnderSampled | hggdh, you said that it hasn't shown all of the information. It freazes sometime during boot, usually either before anything is displayed or with the warning somewhere on the page | 17:03 |
| hggdh | UnderSampled: have you looked at https://wiki.ubuntu.com/DebuggingKernelOops? | 17:03 |
| UnderSampled | no | 17:04 |
| tseliot | mjg59: ok, thanks, I'll try with .29 then | 17:04 |
| hggdh | UnderSampled: and, genrically, at https://wiki.ubuntu.com/DebuggingProcedures#Kernel | 17:04 |
| UnderSampled | hggdh: just above the warning, it shows "Kernel panic - not sycing: fatal exception in interupt" | 17:05 |
| UnderSampled | then it says"---------------[ cut here ]----------------" | 17:06 |
| tseliot | mjg59: do you happen to have a link to the exact commit? | 17:07 |
| mjg59 | e42b6646a8298fe06a33a0f68dab661335f5db6e | 17:09 |
| tseliot | mjg59: thanks a lot. BTW the quirk works now with 2.6.29 | 17:15 |
| mjg59 | Cool | 17:15 |
| rtg_ | Keybuk, linux 2.6.31-3.19 uploadedwith your fsnotify and inotify patches | 17:17 |
| tseliot | smb: would it be possible to have that commit ^^ in Jaunty? The diff is very small: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/input/mouse/synaptics.c;h=865fc69e9bc39e8ef81b213722e572c95917fb0e;hp=d349c4a5e3e84488a4e812e33e6e547aac4d97e7;hb=e42b6646a8298fe06a33a0f68dab661335f5db6e;hpb=cec87e38e92cdfe86678ca2a5c29c38d05127601 | 17:17 |
| Keybuk | rtg_: thanks | 17:19 |
| smb | tseliot, the patch itself looks sensible. I guess we need to get together a good reason for the impact to get a SRU | 17:20 |
| rtg_ | cjwatson, I've narrowed down the Karmic sshd annoyance to a relatively simple scenario. The first time after boot sshd fails to fully release a connection when the client is shutting down. If you stop/start /etc/init.d/ssh then all works fine thereafter. I'll see about instrumenting the initial invocation to get some debug. | 17:37 |
| cjwatson | odd - ok | 17:38 |
| Sarvatt | thanks TheMuso, will finally be able to install from a powerpc alternate cd again without starting from intrepid and upgrading all the way -- [Config] Enable CONFIG_BLK_DEV_IDECD on powerpc | 17:40 |
| amitk | ********* 15 min warning for meeting ****************** | 17:46 |
| === Nicke_ is now known as Nicke | ||
| JFo | hi ogasawara | 18:57 |
| JFo | sorry I haven't been available for a bit | 18:57 |
| JFo | I'm still finishing up moving my household | 18:58 |
| JFo | :-/ | 18:58 |
| ogasawara | JFo: no worries | 18:58 |
| JFo | I saw your e-mail, but I have yet to act upon it | 18:58 |
| JFo | will do so this evening | 18:58 |
| ogasawara | JFo: great, let me know if you have any questions | 18:58 |
| JFo | I certainly will, thanks so much for the feedback | 18:59 |
| JFo | <-trying to be a better bug triager :) | 18:59 |
| Kano | hi apw , you added aufs again? i really thought i had to do it again myself. what did change your mind? | 19:50 |
| amitk | Kano: vfs mounts still has several bugs that won't get fixed in 2.6.31 | 19:52 |
| Kano | funny, i am patching aufs2 since ages now on my own... | 19:52 |
| Kano | fuse-unionfs was really slow as hell ;) | 20:00 |
| Dinh | hello manjo? | 20:17 |
| manjo | Dinh, hello sir | 20:17 |
| manjo | Dinh, did u get my mail with the location of the kernel ? | 20:17 |
| Dinh | cool...i still can't build it...what was your build command? | 20:17 |
| Dinh | yes, can you also put the zimage file there as well? | 20:18 |
| manjo | Dinh, k will do | 20:18 |
| Dinh | manjo: brb | 20:19 |
| manjo | Dinh, done | 20:19 |
| manjo | Dinh, I did a cross compile using the compiler from codesourcery... make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- you need to have the cross gcc in ur path | 20:22 |
| manjo | Dinh, http://www.codesourcery.com/sgpp/lite/arm/portal/release858 | 20:23 |
| manjo | Dinh, brb bio break :) | 20:24 |
| Dinh | manjo: i did that cross_compile settting...let me try the zimage with the system.map file and look at the log_buf | 20:29 |
| manjo | Dinh, k | 20:29 |
| Dinh | manjo: kernel panic in mxc_timer_init() | 20:35 |
| Dinh | let me try rebuiding again | 20:35 |
| manjo | Dinh, where in mxc_timer_init() ? | 20:35 |
| manjo | we know that the kernel does not boot | 20:36 |
| manjo | Dinh, can you paste the panic message ? | 20:36 |
| Dinh | manjo: i have to do a memory dump...1 sec | 20:40 |
| Dinh | manjo: Backtrace (mxc_timer_init+0x0/0x4c) from (mx51_babbage_timer_init+0x0/0x4) from (time_init+0x1c/0x24) | 20:43 |
| manjo | Dinh, in one of my attempts to compile the kernel I got an error message ... include/linux/jiffies.h:257:31: error: division by zero in #if | 20:45 |
| manjo | but it went away later when I used the config options i pointed you to | 20:46 |
| Dinh | manjo: here's my cross_compile path /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- | 20:46 |
| Dinh | when do a build: >make ARCH=arm CROSS_COMPILE=${CROSS_COMPILE} | 20:47 |
| Dinh | I get this error: scripts/mod/modpost.c: In function `match': scripts/mod/modpost.c:699: parse error before `const' | 20:47 |
| manjo | did u use the config options like I suggested ? | 20:48 |
| Dinh | manjo [yes] | 20:48 |
| manjo | Dinh, that is strange.. compiles for me | 20:49 |
| manjo | which cross compiler are you using ? from codesourcery ? | 20:50 |
| Dinh | manjo[anyways..the crash is coming from mx51_babbage_timer_init() in /arch/arm/mach-mx51/mx51_babbage.c | 20:50 |
| === kancerman_ is now known as kancerman | ||
| Dinh | manjo [ the standard arm compile gcc compiler from Redhat] | 20:51 |
| manjo | Dinh, so the crash must be in timer_clk = clk_get(NULL, clk_timer); in arch/arm/plat-mxc/time.c but i dont know why... | 20:53 |
| manjo | Dinh, my compiler is arm-none-linux-gnueabi-gcc-4.3.3 | 20:55 |
| manjo | Dinh, can you try the compiler from http://www.codesourcery.com/sgpp/lite/arm/portal/release858 ? | 20:56 |
| manjo | just get the tar package and untar it in ~/bin something like that .... | 20:56 |
| Dinh | manjo: yeah..let me work on that...i there's some changes in mxc_timer_init function in your tree that I'm not sure about, I'll email you what we have in ours... | 20:57 |
| manjo | Dinh, ok sounds good | 20:58 |
| manjo | what is ur tree based on ? | 20:58 |
| manjo | kernel version ? | 20:58 |
| Dinh | manjo[2.6.28...but I'm not sure why you need these changes for a platform file][ | 21:00 |
| manjo | Dinh, note that the kernel you downloaded is 2.6.31 based | 21:09 |
| manjo | Dinh, with patches from FS | 21:10 |
| Dinh | manjo: yeah, i know...i'm not sure about the changes in low-level platform timer code | 21:11 |
| manjo | Dinh, k | 21:11 |
| Dinh | wait...i sent you the wrong stuff...the crash is in mxc_timer_init...i sent you code for mxc_clocks_init | 21:12 |
| Dinh | manjo: i think i know why the crash is happening... | 21:15 |
| manjo | Dinh, u rock! | 21:15 |
| Dinh | if you look at /arch/arm/plat-mxc/time.c and the function mxc_timer_init(), I don't think timer_base is getting the correct memory address | 21:16 |
| manjo | Dinh, I guessed that .... see my previous comment .. | 21:17 |
| manjo | Dinh, so do we know why address is bad ? | 21:18 |
| Dinh | manjo: how come there is a case for CONFIG_ARCH_MX5 ? only MX1, MX2 and MX3? | 21:19 |
| Dinh | i mean no case for MX5? | 21:20 |
| manjo | hmm right | 21:20 |
| manjo | } else | 21:20 |
| manjo | BUG(); | 21:20 |
| manjo | Dinh, that is your code correcct ? :) | 21:20 |
| Dinh | manjo: no, i just sent you our code | 21:21 |
| manjo | Dinh, ok looking .. | 21:21 |
| manjo | Dinh, do you want me to rebuild and re-upload .. ? | 21:22 |
| Dinh | yeah sure.. | 21:24 |
| manjo | Dinh, rebuilding now | 21:27 |
| zetanuxi | how offten does a kernel completly disappear from grub? =/ | 21:28 |
| manjo | Dinh, some pieces missing still ...int i =3D 0, j =3D 0, reg; | 21:28 |
| Dinh | manjo: downloading the new tool chain now | 21:28 |
| manjo | error: invalid suffix "D" on integer constant | 21:28 |
| Dinh | manjo: i made a mistake...put back your original version of mxc_clocks_init(), you don't need to change that... | 21:29 |
| manjo | Dinh, heh | 21:29 |
| zetanuxi | if a kernel option disappears from grub, do i need to do a clean install to restore it? | 21:30 |
| manjo | Dinh, do we know why we dont have CONFIG_ARCH_MX5 in arch/arm/plat-mxc/time.c ? | 21:32 |
| Dinh | manjo: i have no idea | 21:33 |
| manjo | u have that in ur tree ? | 21:33 |
| manjo | Dinh, in the .config CONFIG_ARCH_MX51=y | 21:34 |
| manjo | so in mxc_timer_init() we will aways hit BUG(); in the CONFIG_ARCH_MX51 case... so it needs a similar entry in that file | 21:35 |
| manjo | #ifdef CONFIG_ARCH_MX51 | 21:35 |
| manjo | timer_base = IO_ADDRESS(GPT1_BASE_ADDR); | 21:35 |
| manjo | irq = MXC_INT_GPT; | 21:35 |
| manjo | #endif | 21:35 |
| Dinh | yep..in the past we used CONFIG_ARCH_MX1 , 2, 3...but we have changed to use more specific names...CONFIG_ARCH_MX51 | 21:37 |
| manjo | let me add that bit and build you a kernel | 21:38 |
| Dinh | and the TIMER_BASE define is defined in your board-mx51_babbage.h, in our tree it was mxc_timer.h | 21:38 |
| Dinh | in /plat-mxc/include/mach/ | 21:39 |
| manjo | hardware.h 84 #define cpu_is_mx51() | 21:39 |
| Dinh | yeah, so add code to get the TIMER_BASE and it should be good to go | 21:41 |
| manjo | building now | 21:41 |
| manjo | Dinh, called seng ? | 21:42 |
| Dinh | i haven't...i'll call hime now...i'm extracting the new build tools. | 21:43 |
| manjo | Dinh, cool | 21:44 |
| Dinh | email me his # again? the previous # didn't work | 21:44 |
| manjo | k | 21:45 |
| manjo | Dinh, you should get in ur sms | 21:46 |
| Dinh | got it | 21:47 |
| manjo | that is my google voice sms service | 21:49 |
| manjo | Dinh, can you try with the new kernel I uploaded to my ppl page ? | 21:51 |
| manjo | it better fscking boot :) | 21:52 |
| Dinh | manjo: i wouldn't count on it...but we'll get past the timer crash... | 21:54 |
| manjo | Dinh, yeah me too... I see CONFIG_ARCH is tons of places ... | 21:55 |
| Dinh | manjo: just tried the image in /try1 folder...still crashes | 21:59 |
| manjo | Dinh, no | 21:59 |
| manjo | not in try1 | 21:59 |
| manjo | that is the old stuff | 21:59 |
| Dinh | oh ok...good | 21:59 |
| Dinh | in the main folder? | 22:00 |
| manjo | yes sir | 22:00 |
| manjo | phewww | 22:00 |
| Dinh | manjo: hmm...failure is still in mxc_timer_init | 22:05 |
| Dinh | let me get my build going... | 22:05 |
| manjo | same place ? | 22:05 |
| Dinh | i think so | 22:06 |
| manjo | k | 22:07 |
| manjo | Dinh, ur mxc_timer_init() code looks a lot less simpler with no cases | 22:11 |
| Dinh | manjo: yes, because it gets the TIMER_BASE from the correct hw file...i'm not sure why you guys need those changes... | 22:14 |
| manjo | k | 22:14 |
| Dinh | manjo: ok, I'm finally building | 23:09 |
| manjo | Dinh, cool ... | 23:18 |
| manjo | Dinh, you think you will be able to get the jtag home for tomorrow ? | 23:18 |
| manjo | my board should show up tomorrow at home | 23:18 |
| Dinh | yeah, i'll bring my whole setup home today... | 23:19 |
| manjo | heh cool! | 23:19 |
| manjo | cant wait to see that jtag ... | 23:19 |
| Dinh | manjo F*** still getting an error: | 23:20 |
| Dinh | drivers/hwmon/isl29003.c: In function 'isl29003_i2c_remove': | 23:20 |
| manjo | Dinh, how about this ... you bring the setup home ... I can swing by later this evening with some thing to drink | 23:20 |
| Dinh | i'm going out to dinner..won't be back til 9 or so... | 23:21 |
| Dinh | you can come by tomorrow morning | 23:21 |
| manjo | ok I need to go to the hospital | 23:21 |
| manjo | tomorrow we can hash this out .. | 23:21 |
| Dinh | ok, i'll send out a quick status... | 23:21 |
| manjo | 9am sounds ok ? | 23:21 |
| manjo | Dinh, I should be up around 7am buzz me on this channel when you are ready tomorrow | 23:22 |
| manjo | Dinh, did u cd debian/config and then cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51 > ../../.config ? | 23:24 |
| manjo | if you do that you should not see that build failure | 23:24 |
| Dinh | yeah, i did that...i get a different error when i do that...let me start over | 23:24 |
| Dinh | is cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51 > ../../.config 1 whole command? or is it cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51 > ../../.config, then cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51 > ../../.config | 23:28 |
| manjo | no one command | 23:28 |
| manjo | you need to cat config.common.ubuntu armel/config.common.armel armel/config.flavour.imx51 into your .config | 23:29 |
| Dinh | ah ok...got it...i was doing it as 2 commands earlier...i think its working now | 23:29 |
| manjo | ok | 23:29 |
| Dinh | sure..come by tomorrow at 9...irish coffee? | 23:33 |
| manjo | in the morning! | 23:33 |
| manjo | ok by me :) | 23:33 |
| manjo | I can bring some einstin bagel | 23:33 |
| Dinh | nah..i got tons of bagels... | 23:34 |
| Dinh | manjo: sweet..it finished building | 23:41 |
| manjo | Dinh, cool... | 23:41 |
| manjo | Dinh, does it have the fix that I put in earlier ? | 23:42 |
| Dinh | not yet..set me a patch for what you put in | 23:42 |
| manjo | ok | 23:42 |
| manjo | Dinh, offing u a patch on irc | 23:48 |
| manjo | offering | 23:48 |
| Dinh | how do i accept it? | 23:49 |
| manjo | Dinh, I emailed it to you as attachment | 23:50 |
| manjo | never mind the irc transfer | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!