Hi, 2011/5/5 Arnaud Patard <[email protected]>: > Martin Michlmayr <[email protected]> writes:
>> Here are some outstanding bugs/tasks regarding the ARM kernels: >> #604013 base: "ls -al" on armel inside loopback mounted ISO image failes >> with -1 ENOMEM >> Nobody has been able to reproduce and the submitter doesn't respond. >> Maybe ping the submitter again, close if no reply. Looks like ownership problem, already closed. >> #622325 linux-image-2.6.38-2-orion5x: Problem With I2C >> Forward upstream, bisect. I am unable to test this one. I got no hardware. As a side note: The code that introduces that message is found at http://lxr.linux.no/linux+v2.6.38/drivers/i2c/busses/i2c-mv64xxx.c#L370 On DNS323 "m41t80" is an i2c device at 0x68, but I fail to see what can be going wrong, maybe it ring some bell on your side. >> #614593 Please add new armel kernel flavour for the Marvell DB-78x00-BP >> Development Board >> I still believe this is a bad idea since it will make kernel builds >> slower for very little gain (there are no users of this board outside >> of our buildd infrastructure). A similar problem exists on MIPS and I >> think Ben wanted to look into the possibility of adding configs >> without enabling them by default but providing an easy way to compile >> the image. > I can't comment on that one but at least, the solution of adding support > but not enabling it by default may be a solution. I think that would be helpful. Steve is taking the burden of building those kernels, I have carbon copied him to check his input about it. If it is fine, I can try to prepare a patch for Arnaud suggestion, which it is fine with me too. >> squashfs: #613658 There are some options that may have to be selected >> on ARM. > hmm... I didn't notice this bug. The ARM options are enabled by default > like the other options. I don't know if it can have some side effects at > run time. I guess it should be fine otherwise some Kconfig patching will > be needed (I'm thinking of the ARMTHUMB decoder option) This bug has first to be fixed in common code, which has happen on SVN trunk. We need to enable on armel/armhf common file: (sounds about right?) CONFIG_XZ_DEC=m CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y Would it be sensible to add ... ? #. "Additional option for memory-constrained systems" CONFIG_SQUASHFS_EMBEDDED=y I think it would be interesting to have one armel/armhf common config, but I have not yet looked into that. >> Also: look through open bugs to see if there are other ARM related >> issues. I have just sent a patch that applies on current trunk for Bug#625804: rtc/mc13xxx: don't call rtc_device_register with the lock held Best regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
