Re: How to obtain serial number in linux
On Wed, 2007-06-20 at 16:52 -0400, Ivan Krstić wrote: This is a complete non-sequitur. Remember the bloody mess that was PSN? I remember a lot of noise and pointless paranoia, but no actual _mess_. But I don't own a tinfoil hat -- so maybe someone's controlling my brain to make me not see the problem. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: System update spec proposal
On Tue, 2007-06-26 at 15:59 -0400, Mike C. Fletcher wrote: * VServer only appeared in public discussions yesterday or so AFAIK, yet it's apparently already the chosen path for doing the system compartmentalization. It's a short-term hack, because the people working on the security stuff let it all slide for too long and now have declared that we don't have time to do anything sensible. It will be dropped as soon as possible, because we know it's not a viable and supportable plan in the long (or even medium) term. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: System update spec proposal
On Tue, 2007-06-26 at 20:45 -0400, Ivan Krstić wrote: On Jun 26, 2007, at 7:23 PM, David Woodhouse wrote: because the people working on the security stuff let it all slide for too long and now have declared that we don't have time to do anything sensible. That's a cutely surreal take on things -- I really appreciate you trying to defuse the situation with offbeat humor :) Nevertheless, it's an accurate description of what happened. To avoid ruffling feathers unnecessarily I suppose I should have made it clear that there is no blame to be assigned here -- the kernel hackers who would ideally have worked on this were simply busy doing more important things like power management and didn't do anything more than just say No, VServer is not workable, which evidently wasn't taken sufficiently seriously. The plan of record is to use this vserver crap for as short a period of time as possible, until we can implement something which is supportable upstream. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: System update spec proposal
On Wed, 2007-06-27 at 18:37 -0400, Ivan Krstić wrote: On Jun 27, 2007, at 2:57 AM, David Woodhouse wrote: Nevertheless, it's an accurate description of what happened. Let's agree to disagree. Sounds like a fine plan. As long as we're united on the common goal to drop vserver as soon as possible and replace it with something which is viable and supportable, I really don't care enough to argue about whatever else we might have disagreed upon. I certainly didn't mean to place blame at your door -- you needed input from kernel hackers and you didn't get it because we were all busy doing other things. That's not your fault. In any case, it doesn't matter at this point. We have work to do. Indeed. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: HAL battery and ac_adapter
On Tue, 2007-07-03 at 18:14 +0100, Richard Hughes wrote: http://people.freedesktop.org/~hughsient/fedora/7/i386/ Upload the PowerPC version too please; I'd like to test it with the new PMU battery driver too. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: GPLv3
On Fri, 2007-07-13 at 11:00 -0700, Greg KH wrote: Isn't there a concern that the on-board security firmware in XO would constitute tivoization essentially of the same sort that GPLv3 aims to block? Which is one reason the Linux kernel developers do not agree with that part of the GPLv3 :) That's one reason why _some_ Linux kernel developers do not agree with that part of the GPLv3. Others disagree with it because they think the GPlv2 actually requires the keys already, and the GPLv3 just takes it too far. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: profiling the resume path
On Wed, 2007-08-29 at 08:31 -0400, Marcelo Tosatti wrote: What you think is the easier/proper way to postpone this console work to happen after the resume process is finished? It's spending all its time waiting for characters to be sent out a serial port which isn't even going to have anything attached to it? Have you considered dropping 'console=ttyS0' from the kernel command line? :) -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: profiling the resume path
On Sun, 2007-09-02 at 04:10 -0400, Marcelo Tosatti wrote: Note: ohci_pci_resume does msleep 20. Hm. It's just waiting for the hardware to settle, right? Do the resume functions for the devices themselves actually have to wait until this is complete, before they can do anything? It really sounds like we need to decouple suspend/resume of individual hardware devices from the full system suspend. It should be almost completely asynchronous. Why can't I start running userspace after resume, before I've reinitialised the USB thermometer which is plugged in? Why don't we just block access to that particular device until it's complete (and take that device off-line to save power even when the full system isn't suspended). -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: profiling the resume path
On Mon, 2007-09-03 at 04:05 -0400, Marcelo Tosatti wrote: This interrupt scheduled for 233-40ms is what sounds wrong. It should just continue to blaze off the EHCI resume path. ... after 20ms have passed, not almost 200. Ah, right. Sorry, I missed the order of magnitude discrepancy. Are we just miscalculating the setting of the wakeup interrupt? More debugging of that calculation might be in order... -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: profiling the resume path
On Mon, 2007-09-03 at 09:27 +0100, David Woodhouse wrote: On Mon, 2007-09-03 at 04:05 -0400, Marcelo Tosatti wrote: This interrupt scheduled for 233-40ms is what sounds wrong. It should just continue to blaze off the EHCI resume path. ... after 20ms have passed, not almost 200. Ah, right. Sorry, I missed the order of magnitude discrepancy. Are we just miscalculating the setting of the wakeup interrupt? More debugging of that calculation might be in order... Can you comment out the 'if(tbase_get_deferrable(nte-base)) continue;' in __next_timer_interrupt() at about line 678 of kernel/timer.c ? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell
On Thu, 2007-09-13 at 06:12 -0400, Bernardo Innocenti wrote: There was an alternative libertas driver which uses the device in 'dumb' mode with the kernel's mac80211 stack. Coupled with mesh support in mac80211 that might make a somewhat suboptimal alternative to truly free firmware. Fascinating. This way at least we use a smaller portion of the closed firmware. Where is this driver maintained? 'Maintained' is a bit of a strong word what we have is found at http://lists.infradead.org/pipermail/libertas-dev/2007-August/000641.html And is mesh networking really (going to be) supported in softmac? It's a safe bet that the mac80211 stack will grow 802.11s support at some point. It may well be useful for us to do it relatively soon. We could use _any_ Linux-supported softmac card to interact with the mesh that way. I'd suggest whoever starts a firmware rewriting effort to go this route, at least initially. So they can relay on known-good mac80211 code while rewriting just a tiny low-level RF driver. s/known-good/debuggable/ -- and it might not require too many changes to the existing firmware. In the long run, softmac¹ definitely isn't the way to go for XO -- even if you switch it to being completely autonomous while the XO is off, you just don't want to be processing all the infrastructure stuff on the Geode. For _debugging_ generic mesh stuff, however, I suspect that's precisely how we want it. When it comes to time to thinking about Gen2... CSR have fullmac devices and a whole lot of Linux clue. Definitely worth investigating. -- dwmw2 ¹ by 'softmac' I mean the generic term -- a software MAC. Not the 'softmac' stack which Johannes wrote for use with bcm43xx. We're abandoning that and moving to mac80211 (née the DeviceScape stack). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery info
On Tue, 2007-09-11 at 18:54 -0400, Eduardo Silva wrote: who knows how can I get the battery capacity in the latest builds, ex: 4000mAh I don't believe we're given this information from the EC. Perhaps we could manage to work it out though -- Richard? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Using 3rd Party Commercial/Free BIOS With XO Laptops
On Tue, 2007-09-25 at 08:07 -0400, Bernardo Innocenti wrote: The fact that the XO has an x86 CPU makes porting OSes and applications easier, That might be true for non-portable operating systems which are bound to x86, but I dispute that it's true for any well-written application. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: something went wrong in the file system
On Fri, 2007-10-12 at 12:30 -1000, Mitch Bradley wrote: This sounds a lot like a problem that I was working on yesterday. (for reference: https://dev.laptop.org/ticket/4184 ) Can you go on IRC (freenode, #olpc) ? If so, I would like to work with you to see if my latest firmware works around your problem. I've pushed changes to the OLPC kernel tree which should cope with this problem, and should prevent it happening again. More to the point, the code should now tell us _why_ it was happening. I'd very much like it if someone could run the new kernel, repeat whatever they did to cause this thing to happen in the first place, and then give me all the kernel messages following the one which looks like: 'Error in jffs2_write_dirent() -- name contains zero bytes!' -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
On Fri, 2007-12-14 at 09:54 +0200, Artem Bityutskiy wrote: UBI/UBIFS is too large and difficult to implement their support in XO boot-loader. So I plan to use the following scheme: 1. Have 2 MTD partitions - mtd0 and mtd1. mtd0 is small (say, 10MiB), and has JFFS2 FS. It contains /boot, /boot-alt, and everything else which the boot-loader would like to have. mtd1 is large, and it spans up to the end of the flash chip. 2. When booting, the bootloader reads kernel, initrd and the other stuff from the JFFS2 FS on MTD 0. It has to be trivial as the boot-loader already can read JFFS2 FS. http://git.infradead.org/?p=openfirmware.git;a=commitdiff;h=a0b5a7b0c OpenFirmware boots from the partition named 'boot' in the RedBoot partition table. The rest are yours to play with as you see fit. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DCON improvements...
Thanks for the feedback, Adam. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DCON improvements...
On Fri, 2007-12-21 at 09:04 +, David Woodhouse wrote: Thanks for the feedback. Unfortunately it didn't reach the people it needs to, because for some reason you dropped them from Cc. Please could you check what caused your mailer to misbehave, and remedy that? Btw, it also broke threading by omitting In-Reply-To: and References: headers. It'd be appreciated if you could remedy that too. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC News 2007-12-30
On Sun, 2007-12-30 at 12:05 -1000, Mitch Bradley wrote: I meant the OLPC kernel. I presume that OLPC changes will be offered to mainline in some batch fashion, rather than piecemeal. This particular one is of no upstream value in isolation, as it is utterly dependent on OLPC-specific EC commands. As a general rule, that is totally incorrect. Changes should be pushed towards upstream _before_ they're ever committed to our tree, and any change which has been made only in the OLPC tree and not pushed upstream should be considered volatile and likely to disappear... like the private wireless ioctls I removed last week because they weren't upstream for example¹. However, you're right about this patch not going upstream -- I thought I'd already told you that the naïve patch to cs5536_warm_reset() as shown in ticket #4397 was not acceptable. It doesn't live in that function, and even if it did, it shouldn't be happening unconditionally based on CONFIG_OLPC. -- dwmw2 ¹ I have actually put them back now, temporarily. But they will be going away again. Nothing is stable until it's upstream. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: iwpriv (Was: OLPC News 2007-12-30)
On Mon, 2007-12-31 at 12:56 -0500, Bernardo Innocenti wrote: btw, we still have code in /etc/init.d/olpc-configure that tries to use one of those private ioctls to remap the leds, and outputs errors if they're missing. Is this still needed? Yes, I think so. And I think it probably even justifies a private ioctl. So it'll get proper consideration and it'll get sent upstream. Not just dumped into our kernel and forgotten. However, you're right about this patch not going upstream -- I thought I'd already told you that the naïve patch to cs5536_warm_reset() as shown in ticket #4397 was not acceptable. It doesn't live in that function, and even if it did, it shouldn't be happening unconditionally based on CONFIG_OLPC. An interesting goal would be cleaning up CONFIG_OLPC so that it could be enabled in stock kernels of standard Linux distros. I actually see that as a prerequisite for getting the thing upstream. And the first step along that path is to stop making it worse. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: iwpriv (Was: OLPC News 2007-12-30)
On Mon, 2007-12-31 at 18:10 +, David Woodhouse wrote:
An interesting goal would be cleaning up CONFIG_OLPC so that
it could be enabled in stock kernels of standard Linux distros.
I actually see that as a prerequisite for getting the thing upstream.
And the first step along that path is to stop making it worse.
Let's see if we can repeat history. If experience with the libertas
driver is anything to go by, I predict that by starting to look at the
problem, I will provoke others into a generating a storm of conflicting
patches by attempting to do the same thing themselves¹.
So here's an untested patch to make the reboot fixups slightly more
generic, so that we can easily add our own 'fixup' for the XO in a
fashion which will actually be mergeable upstream.
Untested-but-otherwise-Signed-Off-By: David Woodhouse [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/reboot_32.c b/arch/x86/kernel/reboot_32.c
index bb1a0f8..dedb1d8 100644
--- a/arch/x86/kernel/reboot_32.c
+++ b/arch/x86/kernel/reboot_32.c
@@ -332,9 +332,7 @@ static void native_machine_shutdown(void)
#endif
}
-void __attribute__((weak)) mach_reboot_fixups(void)
-{
-}
+void (*mach_reboot_fixup)(void);
static void native_machine_emergency_restart(void)
{
@@ -347,7 +345,8 @@ static void native_machine_emergency_restart(void)
/* rebooting needs to touch the page at absolute addr 0 */
*((unsigned short *)__va(0x472)) = reboot_mode;
for (;;) {
- mach_reboot_fixups(); /* for board specific fixups */
+ if (mach_reboot_fixup)
+ mach_reboot_fixup();
mach_reboot();
/* That didn't work - force a triple fault.. */
load_idt(no_idt);
diff --git a/arch/x86/kernel/reboot_fixups_32.c
b/arch/x86/kernel/reboot_fixups_32.c
index f452726..d9607a7 100644
--- a/arch/x86/kernel/reboot_fixups_32.c
+++ b/arch/x86/kernel/reboot_fixups_32.c
@@ -14,16 +14,18 @@
#include asm/msr.h
#include asm/geode.h
-static void cs5530a_warm_reset(struct pci_dev *dev)
+static pci_dev *cs5530a_pci_dev;
+
+static void cs5530a_warm_reset(void)
{
/* writing 1 to the reset control register, 0x44 causes the
cs5530a to perform a system warm reset */
- pci_write_config_byte(dev, 0x44, 0x1);
+ pci_write_config_byte(cs5530_pci_dev, 0x44, 0x1);
udelay(50); /* shouldn't get here but be safe and spin-a-while */
return;
}
-static void cs5536_warm_reset(struct pci_dev *dev)
+static void cs5536_warm_reset(void)
{
/* writing 1 to the LSB of this MSR causes a hard reset */
wrmsrl(MSR_DIVIL_SOFT_RESET, 1ULL);
@@ -48,24 +50,23 @@ static struct device_fixup fixups_table[] = {
* do return, we keep looking and then eventually fall back to the
* standard mach_reboot on return.
*/
-void mach_reboot_fixups(void)
+int mach_reboot_fixup_setup(void)
{
struct device_fixup *cur;
struct pci_dev *dev;
int i;
- /* we can be called from sysrq-B code. In such a case it is
-* prohibited to dig PCI */
- if (in_interrupt())
- return;
-
for (i=0; i ARRAY_SIZE(fixups_table); i++) {
cur = (fixups_table[i]);
dev = pci_get_device(cur-vendor, cur-device, NULL);
if (!dev)
continue;
- cur-reboot_fixup(dev);
+ cs5530a_pci_dev = dev;
+ mach_reboot_fixup = cur-reboot_fixup;
}
+ return 0;
}
+subsys_initcall(mach_reboot_fixup_setup);
+
diff --git a/include/asm-x86/reboot_fixups.h b/include/asm-x86/reboot_fixups.h
index 0cb7d87..4f79001 100644
--- a/include/asm-x86/reboot_fixups.h
+++ b/include/asm-x86/reboot_fixups.h
@@ -1,6 +1,6 @@
#ifndef _LINUX_REBOOT_FIXUPS_H
#define _LINUX_REBOOT_FIXUPS_H
-extern void mach_reboot_fixups(void);
+extern void (*mach_reboot_fixup)(void);
#endif /* _LINUX_REBOOT_FIXUPS_H */
--
dwmw2
¹ Only this time I don't actually plan to follow through; I'm relying on
the interference
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: loss of wireless after joyride-1496 update
On Thu, 2008-01-03 at 10:05 -0800, Dan Krejsa wrote: I (perhaps foolishly) updated to joyride-1496, and after rebooting my G1G1 XO cannot connect to my wireless router. After a while, the neigborhood view becomes completely blank. From a terminal, what happens when you run 'iwlist scan'? Can you show the output when you run the 'dmesg' command? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: loss of wireless after joyride-1496 update
On Thu, 2008-01-03 at 22:09 -0800, Dan Krejsa wrote: Attached are the output from 'iwlist scan' and dmesg. 'quibble' is the router I'm trying to connect to. It's a netgear WPN824v2. After collecting these logs, and making another unsuccessful attempt to connect to quibble (i.e. clicking on quibble's icon in the neighborhood view, waiting for it to stop blinking; winds up with no white outline), I ran 'iwlist scan' again. Then I went back to the neighborhood view and lo and behold, I was connected to quibble. This sounds like GUI confusion to me. First you say it didn't connect, and then you say it did. Please, use 'iwconfig' and 'ifconfig' to confirm for sure whether you were associated to the AP. And don't rely on Legacy IP -- run an RADVD dæmon advertising IPv6 addresses, which will be much more reliable at giving you addresses whenever you're associated. If NetworkManager really is failing to associate, I'd like to see debug logs from the driver while it does so. First, enable debugging by: echo 0x6184 /sys/module/libertas/parameters/libertas_debug Then, run 'dmesg -c' to clear the kernel's log buffer. Then make the attempt to join the network, then run 'dmesg somefile' to store the log buffer again. And mail the log to me, along with 'iwconfig' output showing the current state of the device. If you can repeat the process to show me both a working and a failing attempt to join the network, that would be useful. Thanks. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1514
On Sun, 2008-01-06 at 01:45 -0500, Michael Stone wrote: On Sun, Jan 06, 2008 at 12:37:33AM -0500, Build Announcer Script wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1514/ +kernel.i586 0:2.6.22-20071213.7.olpc.807beb7d0b8a49a -kernel.i586 0:2.6.22-20071231.3.olpc.71454c965b73c4e Why did the kernel revert? So that we can be in the wonderful position of not having a _single_ shipping build which actually has a wireless driver that's expected to work? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: jffs zlib tuning
On Mon, 2008-01-07 at 18:15 +0100, NoiseEHC wrote: This message is primarily written for Bernardo Innocenti but everybody with relevant knowledge is welcomed to give some insight. I have decided two months ago that will write an asm implementation for zlib inflate (decompression) since Mitch Bradley said that the read speed is 3MB/sec which is dominated by the decompression code. http://lists.laptop.org/pipermail/devel/2007-November/007527.html Since then I went through the pain of installing linux in VirtualPC, compiling the code in linux and ended up with a kernel module which can test zlib code finally (took a month of my spare time, if I would have known this in advance I would not have started...). Now I understand the zlib code but need some info before acting on wrong assumptions: 1. Did anybody profile the kernel while reading files? Last thing I red on this list is that the profiler does not work on the XO in kernel mode. Did anybody fix that I believe that standard kernel profiling (on timer ticks) has always worked, and even continues to work even though we use a tickless kernel now. I think oprofile also works. 2. How does the file reading work? As I imagine the flash is read by DMA and the resulting data is uncompressed to a buffer. Is it correct?. Yes, that's right. Is the decompressed data gets copied to the target location or does it gets decompressed to their final place? http://dev.laptop.org/git?p=olpc-2.6;a=blob;f=fs/jffs2/read.c#l81 If it is copied, did somebody profile how much time it takes? These questions are important to know how much L2 cache is trashed in the process and which data needs prefetching. That hasn't been profiled specifically, no. 3. How long is the average data length which jffs2 uses for calling inflate? The maximum length of uncompressed data is 4KiB. The mean is probably slightly less than that. You could instrument the jffs2dump program from mtd-utils to give you more accurate answers. If you want to get involved with compression, see http://www.inf.u-szeged.hu/jffs2/bbc.php -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
On Tue, 2008-01-08 at 19:34 -0700, Rob Savoye wrote: Sigh, I am getting so tired of this issue with codecs... Gnash for the XO is built without support for any proprietary audio or video codecs. Because of the patent laws, the OLPC project (which is based in the US) cannot redistribute these codecs. So, although Gnash supports dailymotion just fine, it'll never work on the XO unless it's built with support for these codecs, namely FLV, ON2, and MP3. Does Gnash not use gstreamer and hence work with the extra codec plugins which are already available in livna? Having to _build_ it with the problematic support would seem to be a poor design decision. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Dailymotion for XO laptop
On Tue, 2008-01-08 at 20:06 -0700, Rob Savoye wrote: To go along with this, I've been working on a clone of the Adobe Media Server, so we can steam free codecs. Right now you can only do this with icecast, but it doesn't speak the flash protocols, which Gnash now supports. Oooh. Gnash now supports RTMP? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 2008-01-09 at 11:34 -0500, John Watlington wrote: Right now we have a problem with mesh portal discovery. The DHCP procedure currently being used only discovers the nearest mesh portal when it is first run (DHCP_DISCOVER), not when it tries to renew (DHCP_REQUEST). Furthermore, as the address previously assigned indicates which mesh portal was selected, it seems like we should always be discovering, not renewing... Legacy IP doesn't work well and doesn't really give us what we need in the long term... or even the medium term. We've known that all along. What do you propose to do about it? Throw away pointless engineering into cobbling together some way of making Legacy IP work a bit better? I seriously hope not. Just switch off the Legacy IP, as we should have done months ago, and get on with making things work properly. Anything else is a distraction. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 2008-01-09 at 14:33 -0500, John Watlington wrote: Unsolicited RAs for IPv6 mean that IPv6 isn't the panacea to this problem. It's easy to discover the shortest way out of the mesh (nearest mesh portal), but setting up the larger mesh networkl infrastucture means you also need to provide a way to route packets back INTO the mesh through the MPP nearest the destination laptop. I have yet to see a good description of how to make IPv6 work right on a mesh with multiple portals.One would be welcome! I talked to cscott and Michail about this briefly when I was in Boston in December. I suspect we should turn off the automatic response to RA in the kernel, and handle it in userspace. We need some special handling in userspace anyway, to pick up DNS server details from RA. We can also check the mesh path length to the origin of each RA we see, and choose the best one. I have such a method for IPv4 defined, but due to an error in modifying the DHCP client, it doesn't handle laptops moving around in the mesh once they've chosen an MPP. (BTW, the error was mine) Is there a hack which would work around that -- like reducing the lease time? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 2008-01-09 at 14:43 -0500, Michail Bletsas wrote: What do you propose to do about it? Throw away pointless engineering into cobbling together some way of making Legacy IP work a bit better? I seriously hope not. Just switch off the Legacy IP, as we should have done months ago, and get on with making things work properly. Anything else is a distraction. You definitely live in a universe different from mine. Regardless of how much we try to make the XO to only talk to other XOs at the p2p application level, there is this small thingy out there called the web which is going to require Legacy IP for the foreseeable future... NAT-PT and proxying should solve that problem relatively simply. I should investigate the implementation at http://tomicki.net/naptd.php -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell microkernel replacement
http://www.csr.com/products/unifirange.htm -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell microkernel replacement
On Sun, 2008-01-13 at 02:30 -0500, Albert Cahalan wrote: David Woodhouse writes: http://www.csr.com/products/unifirange.htm They claim that that is a 1-chip solution. Is it really? I have no reason to believe otherwise -- why do you ask? Some people make some fairly preposterous claims in marketing material but rarely do they make claims which could be so easily disproved. After all, even the most pointy-haired of managers can usually manage to count as far as two. :) Marvell uses a 2-chip solution. If a 2-chip solution is OK, then one could start with a 1-chip softmac solution and add any arbitrary processor. That CPU could be ARM, MIPS, sh3, sh4, sh5, CRIS, ColdFire, Blackfin, 186, PDP-11, IA-64... Fewer chips is generally better. If we could put the _whole_ thing on one die -- the kind of thing IBM are really good at doing for their customers -- then that would be ideal. I don't think we're quite going to manage _that_ level of integration, but we could certainly do better than we have in the current XO design. In any case: At minimum one must get promises in writing, but it's far better to have actual published documentation first. Don't forget about the errata! Having seen the kind of NDA and documentation that CSR give to Linux hackers, I have faith that something entirely acceptable can be worked out, should we want to go down that path. They very much seem to GetIt™. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Outstanding kernel patches
Stuck in tin cans again, I've been looking at building an OLPC kernel based on 2.6.24, starting by going through the diffs between our stable tree and 2.6.22 (on which it's based). Ideally, we should be committing almost nothing directly to our tree -- it should _all_ be going upstream. As much as possible, I try to commit to the git tree which I'm going to ask Linus to pull from and _then_ cherry-pick those commits into the OLPC tree. If we don't do it like that, we need to remember to chase our changes upstream. Here's a quick summary of what looks like it needs to be (cleaned up and) pushed upstream... dwmw2: some olpc_battery changes libertas private ioctls jffs2 crc noise Jordan: [PATCH] Add a configuration option to avoid automatically probing VGA scx200_acb: Add a module option to tune the SMB_CLK [PATCH] Add a notifier list for VT console modes geode video support DCON (or maybe this is dwmw2's) Jon Corbet: Some cafe_ccic.c changes Andres / other: cs5535audio promfs DISABLE_SUSPEND_VT_SWITCH make config_noninteractive sysprof pci: do not delay when changing power states on OLPC atkbd/i8042 hacks olpc touchpad Core OLPC platform support: - Need to clean up the device-tree handling. Can we use fdt? - PCI support - EC support - Power management I'm willing to take on the core platform support and try to get that upstream -- we really ought to get at least the basics of that ready for when the 2.6.25 merge window opens. That's only a quick pass; if you know you've committed something to the OLPC tree which you haven't also sent to Linus, please think about what needs doing to get it ready for the (imminent) 2.6.25 merge window. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Outstanding kernel patches
On Mon, 2008-01-14 at 06:48 -0700, Jonathan Corbet wrote: Actually, I've sent all of my changes into the mainline; I *believe* that things need to go the other way. There were some things I put in which ran afoul of a freeze on the OLPC side. Sounds good to me; I'll just drop any cafe_ccic changes when I update to 2.6.24 then, and bug you if we see any regressions. :) Thanks. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Thu, 2008-01-17 at 12:32 -0500, Michail Bletsas wrote: There is an iwpriv eth0 radiooff/radioon IOCTL hook in the firmware which was meant to control the radio power directly - it was removed a few months ago since it wasn't considered to its thing in the proper linux manner. I looked for it and I couldn't find it. Please could you point me at the commit in which it was removed? I'm not entirely sure it ever made it into our driver. Certainly it never made it into the upstream driver, and the upstream driver is all that really matters, in the long term. ** I don't know how iwconfig eth0 txpower off is implemented, if it uses the same IOCTL with iwpriv eth0 radiooff, then it is doing the right thing. It uses CMD_802_11_RADIO_CONTROL with the RADIO_OFF argument, which I believe is the correct thing to do. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 10:08 -0500, Dan Williams wrote: Yes. The active antennas firmware would need to be slightly altered to start on firmware boot, but the normal XO firmware should certainly be radio-off-until-driver-enabled (by setting IFF_UP or device open). Let us make a clear distinction between the two types of 'active antenna' here. The ones which are actually attached to servers and acting as wireless devices for a computer, we want to act like in the XO. When they come up automatically into mesh repeater mode, that's actually a complete PITA -- and it means we can't reboot the servers because then the driver can't initialise the wireless because it's in mesh repeater mode and doesn't respond properly to being reset. Only for the standalone devices which we're going to hang in a corridor and feed 5v do we want _any_ kind of automatic network operation. And then it needs to be configurable -- we have to set the channel. Since we need a way to configure the channel on the active antennae, let's use channel zero to indicate 'no automatic mesh'. And please can we have that firmware by tomorrow, Ulan Bator time -- so that I can actually set up the school server so that it's rebootable without subsequently having to disconnect and reconnect the firmware? I'd do it myself, but bug #429 bites again... -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 16:56 -0500, John Watlington wrote: Michail, This would be 3107, right ? 3109 is when we started seeing the auto-update mode. OK, so can we go between 3109 and 3107 in both directions using libertas-flash.py or did the protocol get changed without telling us? We never did get Marvell's 'firmware update' patch for the driver to apply to the kernel they claim it applies to, did we? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 15:50 -0500, Michail Bletsas wrote: Ideally, we want to just kill the auto-mesh-repeater mode, where boot2 times out after 5 seconds and loads the firmware from the internal flash (which is obviously larger on these devices than on the XO). Can we achieve that just by updating to a 'normal' Boot2 version from the XO? Yes, that is all that is needed to disable autoboot on the active antennas. OK, that's the plan for the Mongolia deployment then. Wad, please can you confirm (with libertas-flash.py) and forward me the current (XO) version of Boot2, so I can do that? Thanks. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 14:47 -0500, Dan Williams wrote: What is the post-boot firmware flash functionality supposed to apply to, the host-less active antenna? (which is what I heretofore had understood). As Ben says, they're the same thing. If you don't load the firmware within 5 seconds of the boot2 code starting up, the thing loads its own firmware from the internal flash. Yes, it's horrid. It doesn't even preserve the boot2 version, because we did some stupid hack to preserve that in the _driver_ rather than keeping it internal, so when we send the CMD_802_11_RESET command to kick the device back into boot2, we get 'device firmware changed' from the kernel and it appears as a completely new device... Ideally, we want to just kill the auto-mesh-repeater mode, where boot2 times out after 5 seconds and loads the firmware from the internal flash (which is obviously larger on these devices than on the XO). Can we achieve that just by updating to a 'normal' Boot2 version from the XO? (Yes, I should be sleeping. No, I have no idea what timezone I'm in). -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Serious side effect of #6299 (silencing salut so gabble can connect)
On Thu, 2008-02-14 at 17:56 -0200, Ricardo Carrano wrote: If you don't turn many XOs on at the same time, you won't have salut preventing gabble to work. My fear is that we are complicating things unnecessarily. But we _do_ turn on many XOs at the same time. Hell, we've seen one teacher putting the kids through what seemed like rifle drill, opening them up by numbers at the start of the lesson... -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireshark
On Mon, 2008-02-25 at 15:02 -0500, Ricardo Carrano wrote: 14:43:34 Err file about_dlg.c: line 250 (splash_update): assertion failed: (ul_sofar = ul_count) Aborted (core dumped) We shouldn't be hacking epan/dissectors/register.c directly -- it's autogenerated. If we'd regenerated it using the proper tool, it would have increased the counts in the register_count() function accordingly. But we didn't, and that's why the count of registered protocols exceeds the 'maximum'. Since it's autogenerated, it is sufficient just to remove it in the RPM specfile and it'll get created again appropriately. ftp://ftp.infradead.org/pub/wireshark/wireshark.spec (with RPMs in the same directory) -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireshark
On Mon, 2008-02-25 at 04:37 -0500, John Watlington wrote: http://dev.laptop.org/~wad/wireshark-0.99.7.mesh.patch Has this been submitted to the wireshark developers? I took a quick look through it and removed some whitespace noise, and spotted a change in add_fixed_field() behaviour in the CAT_HT case. It used to lack a break; and thus fall through to the default: case. But now it doesn't, because you added a break there before your new code for CAT_VENDOR_SPECIFIC. If you really mean that as a bug fix, it should be submitted as a separate patch instead of a subtle side-effect of the mesh support. On a similar note -- in dissect_snap() in packet-llc.c, are you intentionally falling through to the OUT_ENCAP_ETHER case? If so, it's probably worth a comment to that effect. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Scanning and probe requests
On Wed, 2008-03-05 at 20:09 -0300, Ricardo Carrano wrote: It may be possible that NetworkManager is triggering the scannings (any other possibility?). Anyway, why 4 scan commands and how this becomes 2 probe requests? Any ideas? We send multiple scan commands to the firmware for each scan command from userspace because the buffer for scan results is limited in size -- so we scan only four channels at a time. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Thu, 2008-04-17 at 17:09 -0400, Michael Stone wrote: Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows: Currently firmware 5.110.22.p8/9 does not support more than 8 multicast mac addresses. Is there a possibility that any given point of time there are more than 8 multicast address required? Is this going to be a problem for anyone? Theoretically we go into ALLMULTI mode (and filter on the host) when we exceed the size of the multicast list that the device can handle. There shouldn't be a hard limit on the number of multicast groups that userspace can join; it just gets less efficient. However, we believe that size to be 32 (MRVDRV_MAX_MULTICAST_LIST_SIZE in defs.h). -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 10:58 -0400, Ricardo Carrano wrote: Mmm, if the driver says it is 32 and the firmware only allows for 8, we have a problem, don't we? ;-) Indeed. Do we know which versions of firmware support which numbers of addresses? Remember, this driver handles lots of devices, some with non-mesh firmware. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 11:43 -0400, Polychronis Ypodimatopoulos wrote: Is it possible to associate shared activities with ethernet ports instead of whole multicast addresses? Then we would only need one single multicast address and do the filtering on the ethernet ports (eg IP is port 0x0800). At the very least, the multicast address is 6 bytes and the ethernet port is 2 bytes. That's possible, yes -- although you won't get the device filtering it for you then. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 11:50 -0400, Polychronis Ypodimatopoulos wrote: what's possible? why not? David Woodhouse wrote: On Fri, 2008-04-18 at 11:43 -0400, Polychronis Ypodimatopoulos wrote: Is it possible to associate shared activities with ethernet ports instead of whole multicast addresses? Then we would only need one single multicast address and do the filtering on the ethernet ports (eg IP is port 0x0800). At the very least, the multicast address is 6 bytes and the ethernet port is 2 bytes. That's possible, yes -- although you won't get the device filtering it for you then. Error. Question upside down. Please don't top-post. It's possible to do as you say -- to use different ports for different activities (although I read 'UDP ports' where you actually said 'ethernet ports' so perhaps I misunderstood). The device firmware doesn't speak IPv6 or Legacy IP, however -- and we wouldn't want it to, even if we trusted it. So it wouldn't filter for only those ports you're interested in; it'll give you all packets for that address. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 12:08 -0400, Polychronis Ypodimatopoulos wrote: Dynamic mapping from a single 6-byte address to multiple 16-byte addresses? The other way round. Given an IPv6 multicast address, there exists a MAC address associated with that IPv6 address. When we join the multicast group, we tell the device that we want to receive packets addressed to that MAC address. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 12:01 -0400, Polychronis Ypodimatopoulos wrote: You're not following: Ethernet ports are bytes 12-14 (2 bytes total) on _all_ ethernet frames. IP has nothing to do with this. Instead of looking at the first 6 bytes (destination mac) for a specific multicast address, the filter should be looking at bytes 12-14 for a specific ethernet port. Ah, sorry. I read it as UDP ports. It would be hard to do this -- there's a defined mapping from IPv6 addresses to the multicast MAC addresses used, and high-level applications don't get to muck around with low-level details of the Ethernet frames. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 12:01 -0400, Polychronis Ypodimatopoulos wrote: You're not following: Ethernet ports are bytes 12-14 (2 bytes total) on _all_ ethernet frames. IP has nothing to do with this. Instead of looking at the first 6 bytes (destination mac) for a specific multicast address, the filter should be looking at bytes 12-14 for a specific ethernet port. Forgive my ignorance... you're not talking about the EtherType field, which is set to 0x800 to indicate IPv4 packets or 0x86dd for IPv6? It doesn't seem practical to use that for application-specific purposes. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 14:19 -0400, Ricardo Carrano wrote: The multicast filter was implemented in 22p8 (with the limit of 8 since them). Is that what you're asking? Then the firmware was just ignoring the MAC list before then, and always implementing the ALLMULTI behaviour? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Thin firmware + driver first development release
On Fri, 2008-05-09 at 16:06 -0700, Javier Cardona wrote: Hi, We are happy to announce the first development release of the wireless firmware + driver compatible with the kernel's mac80211 stack. This is a first step towards supporting a soft Access Point (hostap) on the xo, a project in which are actively working. The release is made of the following pieces: Firmware: http://dev.laptop.org/pub/firmware/libertas/thinfirm Driver: git clone git://dev.laptop.org/users/javier/libertastf.git HOW_TO: http://dev.laptop.org/pub/firmware/libertas/thinfirm/HOW_TO Excellent; thanks. Were you planning to make the API for this 'thin firmware' compatible with the 'thin firmware' on other devices? Should the folks working on http://git.infradead.org/mrv8k-2.6.git be trying to merge with your driver? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Fri, 2008-05-09 at 21:00 -0700, [EMAIL PROTECTED] wrote: Each device maintains its own list of bound multicast addresses. Those lists are merged and purged from duplicate addresses before being sent to firmware. The maximum number of multicast addresses per virtual device has been cut in half to ensure that the merged list can be accommodated by the hardware. Also, configuration flags are ORed before being sent to firmware, which appears to be the least conflicting way of combining two virtual operating modes into one for a single physical device. Based on patches from Ashish Shukla and David Woodhouse. Signed-off-by: Javier Cardona [EMAIL PROTECTED] Tested by: Ricardo Carrano [EMAIL PROTECTED] Looks good, but please don't introduce any more of the 'u8' and 'u32' nonsense. If types are user-visible, we have to use the '__u32' form. If not, we might as well use the types that the C language provides. I've been slowly fixing that throughout the libertas driver as I've been rewriting it (which task is a bit on hold right now, I know...) On an SMP host, are you sure we can't end up setting the multicast list simultaneously on the two logical devices? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 13:47 +0100, David Woodhouse wrote: On Fri, 2008-05-09 at 21:00 -0700, [EMAIL PROTECTED] wrote: Each device maintains its own list of bound multicast addresses. Those lists are merged and purged from duplicate addresses before being sent to firmware. The maximum number of multicast addresses per virtual device has been cut in half to ensure that the merged list can be accommodated by the hardware. Also, configuration flags are ORed before being sent to firmware, which appears to be the least conflicting way of combining two virtual operating modes into one for a single physical device. Based on patches from Ashish Shukla and David Woodhouse. Signed-off-by: Javier Cardona [EMAIL PROTECTED] Tested by: Ricardo Carrano [EMAIL PROTECTED] Looks good, but please don't introduce any more of the 'u8' and 'u32' nonsense. If types are user-visible, we have to use the '__u32' form. If not, we might as well use the types that the C language provides. I've been slowly fixing that throughout the libertas driver as I've been rewriting it (which task is a bit on hold right now, I know...) On an SMP host, are you sure we can't end up setting the multicast list simultaneously on the two logical devices? (A: No.) And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote: And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work Hm, a single cup of tea mostly achieves that; sorry :) I was missing the fact that priv-packetfilter[] is now an array. It got a bit clearer after I reformatted it to stop trying to fit in 80 columns. Sometimes the code just doesn't fit; it's painful to try to make it. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 12:30 -0700, Andrew Morton wrote: On Tue, 13 May 2008 13:20:19 -0400 Andres Salomon [EMAIL PROTECTED] wrote: On Tue, 13 May 2008 15:45:39 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote: And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work Hm, a single cup of tea mostly achieves that; sorry :) I was missing the fact that priv-packetfilter[] is now an array. It got a bit clearer after I reformatted it to stop trying to fit in 80 columns. Sometimes the code just doesn't fit; it's painful to try to make it. Gosh, I sure wish you, Andrew, checkpatch.pl, and Ingo[0] were all on the same page regarding that.. it would sure make my life easier. David is off in his own little world on this and can be safely ignored. Meanwhile the rest of us are forced to stare at crocks of shit like http://userweb.kernel.org/~akpm/x.jpg, wondering who hates us and why. I think the large amount of whitespace in the screenshot at http://david.woodhou.se/narrow.png shows quite effectively why I think you're talking nonsense on this particular topic. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 16:15 -0700, Andrew Morton wrote: On Tue, 13 May 2008 19:12:27 -0400 Andres Salomon [EMAIL PROTECTED] wrote: And FWIW, I like the 80 char limit _except_ when it comes to strings. I don't normally bother about the strings, unless it is obvious that the surrounding code has worked to prevent them from wrapping (and if I notice that). Or if they make code particularly hard to read and alter. I've seen some which wander out to column 130, which is getting daft. The code at http://userweb.kernel.org/~akpm/x.jpg has short strings, but it has gone and stuffed the _arguments_ onto the same line too, which is just obnoxious. I would probably accept patches to move the arguments onto the next line; I don't think that would make the overall code less readable. In fact, I would normally put the arguments on the next line these days anyway -- but that particular piece of debugging code dates from before all this pointless fuss about 80 columns got started, so it was never an issue. It could probably do with printk priorities too, while we're at it. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 15:06 -0700, Andrew Morton wrote: On Tue, 13 May 2008 22:59:26 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 12:30 -0700, Andrew Morton wrote: On Tue, 13 May 2008 13:20:19 -0400 Andres Salomon [EMAIL PROTECTED] wrote: On Tue, 13 May 2008 15:45:39 +0100 David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote: And even without that, it doesn't seem to do the right thing. Set IFF_PROMISC mode on one interface, then on the other, then clear it on the first it should remain set in hardware. And AFAICT it doesn't. I'll see if I can make it work Hm, a single cup of tea mostly achieves that; sorry :) I was missing the fact that priv-packetfilter[] is now an array. It got a bit clearer after I reformatted it to stop trying to fit in 80 columns. Sometimes the code just doesn't fit; it's painful to try to make it. Gosh, I sure wish you, Andrew, checkpatch.pl, and Ingo[0] were all on the same page regarding that.. it would sure make my life easier. David is off in his own little world on this and can be safely ignored. Meanwhile the rest of us are forced to stare at crocks of shit like http://userweb.kernel.org/~akpm/x.jpg, wondering who hates us and why. I think the large amount of whitespace in the screenshot at http://david.woodhou.se/narrow.png shows quite effectively why I think you're talking nonsense on this particular topic. That's an 80-column display. Seems to be something like an 80-row display too. Even if you have one of those weird rotatable monitors and you've put it into portrait mode, it's not particularly realistic. Mine, on the other hand, is less contrived -- it's a web browser which is no wider than it _has_ to be these days, to view news.bbc.co.uk. And the code in question is not the example you chose, which I would accept patches for, but lbs_set_if_multicast_list() -- shown at http://david.woodhou.se/then-and-now.html in both the original 80-column and the more readable slightly wider versions. If that's the best your can do, you have nothing. In the past, after fixing the 80-column nonsense to make code more readable, I've immediately spotted bugs which weren't apparent before (commit f6f0f818, for example). I do try to keep code within 80 columns where I can; it's a reasonable guideline -- but I also accept that sometimes it just doesn't fit, and it would be foolish and counter-productive to try to force it. I'm sorry if that offends you, but making code more readable helps me find real bugs, and that is more important to me than the 80-column rule. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 19:12 -0400, Andres Salomon wrote: Can we come to a consensus for the sake of outside contributors? Rather than telling the cozybit folks one thing, and having checkpatch.pl and CodingStyle claim another (Dave, surely you wouldn't argue against using checkpatch?), can we get our stories straight? Please? Checkpatch is a useful tool but I use it with the line length check patched out, and I take the rest of its output with a pinch of salt. As for getting our stories straight... let's defer to Linus, who at various times has said the following: Quite frankly, I've several times been *this* close (holds up fingers so you can't even see between them) to just remove checkpatch entirely. I'm personally of the opinion that a lot of checkpatch fixes are anything but. That mainly concerns fixing overlong lines (where the fixed version is usually worse than the original), but it's been true for some other warnings too. -- http://lkml.org/lkml/2008/2/21/334 Quite frankly, I personally am considering removing checkpatch.pl. That thing is just a nazi dream. That hard-coded 80-character limit etc is just bad taste. Dammit, code cleanliness is not about automated and mindless slavish following of rules. A process that is too inflexible is a *bad* process. I'd much rather have a few 80+ character lines than stupid and unreadable line wrapping just because the line hit 87 characters in length. I don't have 25 lines on a screen either. -- http://lkml.org/lkml/2007/6/23/189 -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Wed, 2008-05-14 at 02:17 -0700, Andrew Morton wrote: On Wed, 14 May 2008 09:44:12 +0100 David Woodhouse [EMAIL PROTECTED] wrote: I'm sorry if that offends you, but making code more readable helps me find real bugs, and that is more important to me than the 80-column rule. Code which wraps due to excess line sizes is less readable that code which avoids this. Your rhetorical trick of saying it is more readable is of course unsubstantiated and incorrect, which makes everything else you say baseless. Andrew, I'm disappointed in you. You actually _removed_ a concrete example which substantiated my observation (an observation which Linus has also made), and then called it 'unsubstantiated and incorrect'. That's somewhat disingenuous of you. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: School server stuff
On Mon, 2008-05-12 at 23:49 -0400, John Watlington wrote: On May 12, 2008, at 8:46 PM, Marcus Leech wrote: A few questions: What driver is required on an ordinary Linux system for the active antennae? [I ask because plugging one in to a hot-off-the-presses F9 system causes said system to freeze instantly :-( ] The stock upstream libertas kernel might work, given proper firmware in /lib/firmware. It most certainly should -- and was tested fairly recently. If you have problems, file a bug in Fedora bugzilla. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] libertas: Extend CMD_MESH_CONFIG to get and set persistent mesh default params.
On Thu, 2008-05-15 at 11:01 -0700, Brian Cavagnolo wrote:
This patch is based on a patch from Shailendra Govardhan. It introduces
several new iwprivs: {get,set}_bootflag {get,set}_boottime {get,set}_def_chan
{get,set}_def_protid {get,set}_def_metid {get,set}_def_meshcap
{get,set}_def_meshid. These commands are only supported on Marvell hardware
that implements persistent defaults, such as the OLPC Active Antenna.
Accordingly, this patch may not be suitable for upstream merging.
See http://dev.laptop.org/ticket/6823 for minimal testing results and known
issues. See
http://www.laptop.org/teamwiki/index.php/Tech:Wireless#Firmware_image_which_stores_the_mesh_parameters_in_flash
for iwpriv documentation.
Signed-off-by: Brian Cavagnolo [EMAIL PROTECTED]
---
Hm. I was intending to veto the addition of any more private ioctls to
the olpc tree, because they all need fixing to use cfg80211 or something
else upstream, and we only make pain for ourselves by adding to the
divergence -- adding new APIs to userspace when we _know_ are going to
have to change them is just silly.
But this is the _one_ thing which might actually be OK to do with a
private ioctl, since it's very hardware-specific. Unlike like all the
mesh-mangling stuff where we really ought to be compatible with o11s.
So maybe, just maybe, we _can_ do this with iwpriv and push that
upstream.
If you want to revamp the patch to apply to the upstream kernel and see
what people think of it, go ahead.
--
dwmw2
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote:
On an SMP host, are you sure we can't end up setting the multicast list
simultaneously on the two logical devices?
(A: No.)
Try it like this... completely untested and hence probably broken in
some stupid and minor way, but testing is something for tomorrow, not
Sunday night when I'm supposed to be cooking dinner.
We now merge duplicates from the two address lists while we're building
the CMD_MAC_MULTICAST_ADR packet to send to the device, so we don't
artificially limit each device to MRVDRV_MAX_MULTICAST_LIST_SIZE/2
addresses. We'll go into allmulti mode only if the total number of
addresses, excluding duplicates, exceeds the limit. Although I'm not
wonderfully happy that we don't have any way of interrogating the
firmware for its limit; what happens when we send more addresses than
the firmware can cope with?
We also deal with the locking issues -- that we could be in
lbs_set_multicast_list() for eth0 and msh0 simultaneously on two
different CPUs -- by punting the actual work to a workqueue. Which can
lock and use the multicast lists directly from each device, so we don't
need our own copy of each.
And it moves CMD_MAC_MULTICAST_ADR to a direct command, as we have been
doing for all commands.
Overall, it results in the net addition of five lines of code, instead
of the 64 lines added by the previous version :)
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index 6328b95..2473ba8 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -778,28 +778,6 @@ out:
return ret;
}
-static int lbs_cmd_mac_multicast_adr(struct lbs_private *priv,
- struct cmd_ds_command *cmd,
- u16 cmd_action)
-{
- struct cmd_ds_mac_multicast_adr *pMCastAdr = cmd-params.madr;
-
- lbs_deb_enter(LBS_DEB_CMD);
- cmd-size = cpu_to_le16(sizeof(struct cmd_ds_mac_multicast_adr) +
-S_DS_GEN);
- cmd-command = cpu_to_le16(CMD_MAC_MULTICAST_ADR);
-
- lbs_deb_cmd(MULTICAST_ADR: setting %d addresses\n,
pMCastAdr-nr_of_adrs);
- pMCastAdr-action = cpu_to_le16(cmd_action);
- pMCastAdr-nr_of_adrs =
- cpu_to_le16((u16) priv-nr_of_multicastmacaddr);
- memcpy(pMCastAdr-maclist, priv-multicastlist,
- priv-nr_of_multicastmacaddr * ETH_ALEN);
-
- lbs_deb_leave(LBS_DEB_CMD);
- return 0;
-}
-
/**
* @brief Get the radio channel
*
@@ -1279,8 +1257,7 @@ void lbs_set_mac_control(struct lbs_private *priv)
cmd.action = cpu_to_le16(priv-mac_control);
cmd.reserved = 0;
- lbs_cmd_async(priv, CMD_MAC_CONTROL,
- cmd.hdr, sizeof(cmd));
+ lbs_cmd_async(priv, CMD_MAC_CONTROL, cmd.hdr, sizeof(cmd));
lbs_deb_leave(LBS_DEB_CMD);
}
@@ -1392,10 +1369,6 @@ int lbs_prepare_and_send_command(struct lbs_private
*priv,
cmdptr, cmd_action);
break;
- case CMD_MAC_MULTICAST_ADR:
- ret = lbs_cmd_mac_multicast_adr(priv, cmdptr, cmd_action);
- break;
-
case CMD_802_11_MONITOR_MODE:
ret = lbs_cmd_802_11_monitor_mode(cmdptr,
cmd_action, pdata_buf);
@@ -1484,7 +1457,7 @@ int lbs_prepare_and_send_command(struct lbs_private *priv,
ret = lbs_cmd_bcn_ctrl(priv, cmdptr, cmd_action);
break;
default:
- lbs_deb_host(PREP_CMD: unknown command 0x%04x\n, cmd_no);
+ lbs_pr_err(PREP_CMD: unknown command 0x%04x\n, cmd_no);
ret = -1;
break;
}
diff --git a/drivers/net/wireless/libertas/cmdresp.c
b/drivers/net/wireless/libertas/cmdresp.c
index 5abecb7..4c3c5ec 100644
--- a/drivers/net/wireless/libertas/cmdresp.c
+++ b/drivers/net/wireless/libertas/cmdresp.c
@@ -316,7 +316,6 @@ static inline int handle_cmd_response(struct lbs_private
*priv,
break;
- case CMD_RET(CMD_MAC_MULTICAST_ADR):
case CMD_RET(CMD_802_11_RESET):
case CMD_RET(CMD_802_11_AUTHENTICATE):
case CMD_RET(CMD_802_11_BEACON_STOP):
@@ -376,8 +375,8 @@ static inline int handle_cmd_response(struct lbs_private
*priv,
break;
default:
- lbs_deb_host(CMD_RESP: unknown cmd response 0x%04x\n,
-le16_to_cpu(resp-command));
+ lbs_pr_err(CMD_RESP: unknown cmd response 0x%04x\n,
+ le16_to_cpu(resp-command));
break;
}
lbs_deb_leave(LBS_DEB_HOST);
diff --git a/drivers/net/wireless/libertas/dev.h
b/drivers/net/wireless/libertas/dev.h
index 0d9edb9..e12ce65 100644
--- a/drivers/net/wireless/libertas/dev.h
+++ b/drivers/net/wireless/libertas/dev.h
@@ -140,6 +140,8 @@ struct lbs_private
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Mon, 2008-05-19 at 07:01 -0400, Dan Williams wrote: Is the firmware multicast address limit the same for every firmware from 5.0.x up to 9? Is it something that people with the firmware dev kit can change with a recompile? Because if it changes between any of the firmware revisions already out there (including for 8385 CF, 8686 SDIO, 8388 USB, etc) then we'll probably need a lookup table. If we can avoid a lookup table, that would be nice. Perhaps we could list the MAC addresses after trying to set them, and see how many we get back? Unless there's a better way... I just hope the different firmwares does something sensible when they get more than they can handle? Like automatically going into ALLMULTI mode? That would be nice, but I find it unlikely. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Sun, 2008-05-18 at 20:48 +0100, David Woodhouse wrote:
Try it like this... completely untested and hence probably broken in
some stupid and minor way, but testing is something for tomorrow, not
Sunday night when I'm supposed to be cooking dinner.
This version seems to work, and as an added bonus even gets it right
when you bring devices up and down.
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index 6328b95..2473ba8 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -778,28 +778,6 @@ out:
return ret;
}
-static int lbs_cmd_mac_multicast_adr(struct lbs_private *priv,
- struct cmd_ds_command *cmd,
- u16 cmd_action)
-{
- struct cmd_ds_mac_multicast_adr *pMCastAdr = cmd-params.madr;
-
- lbs_deb_enter(LBS_DEB_CMD);
- cmd-size = cpu_to_le16(sizeof(struct cmd_ds_mac_multicast_adr) +
-S_DS_GEN);
- cmd-command = cpu_to_le16(CMD_MAC_MULTICAST_ADR);
-
- lbs_deb_cmd(MULTICAST_ADR: setting %d addresses\n,
pMCastAdr-nr_of_adrs);
- pMCastAdr-action = cpu_to_le16(cmd_action);
- pMCastAdr-nr_of_adrs =
- cpu_to_le16((u16) priv-nr_of_multicastmacaddr);
- memcpy(pMCastAdr-maclist, priv-multicastlist,
- priv-nr_of_multicastmacaddr * ETH_ALEN);
-
- lbs_deb_leave(LBS_DEB_CMD);
- return 0;
-}
-
/**
* @brief Get the radio channel
*
@@ -1279,8 +1257,7 @@ void lbs_set_mac_control(struct lbs_private *priv)
cmd.action = cpu_to_le16(priv-mac_control);
cmd.reserved = 0;
- lbs_cmd_async(priv, CMD_MAC_CONTROL,
- cmd.hdr, sizeof(cmd));
+ lbs_cmd_async(priv, CMD_MAC_CONTROL, cmd.hdr, sizeof(cmd));
lbs_deb_leave(LBS_DEB_CMD);
}
@@ -1392,10 +1369,6 @@ int lbs_prepare_and_send_command(struct lbs_private
*priv,
cmdptr, cmd_action);
break;
- case CMD_MAC_MULTICAST_ADR:
- ret = lbs_cmd_mac_multicast_adr(priv, cmdptr, cmd_action);
- break;
-
case CMD_802_11_MONITOR_MODE:
ret = lbs_cmd_802_11_monitor_mode(cmdptr,
cmd_action, pdata_buf);
@@ -1484,7 +1457,7 @@ int lbs_prepare_and_send_command(struct lbs_private *priv,
ret = lbs_cmd_bcn_ctrl(priv, cmdptr, cmd_action);
break;
default:
- lbs_deb_host(PREP_CMD: unknown command 0x%04x\n, cmd_no);
+ lbs_pr_err(PREP_CMD: unknown command 0x%04x\n, cmd_no);
ret = -1;
break;
}
diff --git a/drivers/net/wireless/libertas/cmdresp.c
b/drivers/net/wireless/libertas/cmdresp.c
index 5abecb7..4c3c5ec 100644
--- a/drivers/net/wireless/libertas/cmdresp.c
+++ b/drivers/net/wireless/libertas/cmdresp.c
@@ -316,7 +316,6 @@ static inline int handle_cmd_response(struct lbs_private
*priv,
break;
- case CMD_RET(CMD_MAC_MULTICAST_ADR):
case CMD_RET(CMD_802_11_RESET):
case CMD_RET(CMD_802_11_AUTHENTICATE):
case CMD_RET(CMD_802_11_BEACON_STOP):
@@ -376,8 +375,8 @@ static inline int handle_cmd_response(struct lbs_private
*priv,
break;
default:
- lbs_deb_host(CMD_RESP: unknown cmd response 0x%04x\n,
-le16_to_cpu(resp-command));
+ lbs_pr_err(CMD_RESP: unknown cmd response 0x%04x\n,
+ le16_to_cpu(resp-command));
break;
}
lbs_deb_leave(LBS_DEB_HOST);
diff --git a/drivers/net/wireless/libertas/dev.h
b/drivers/net/wireless/libertas/dev.h
index 0d9edb9..e12ce65 100644
--- a/drivers/net/wireless/libertas/dev.h
+++ b/drivers/net/wireless/libertas/dev.h
@@ -140,6 +140,8 @@ struct lbs_private {
wait_queue_head_t waitq;
struct workqueue_struct *work_thread;
+ struct work_struct mcast_work;
+
/** Scanning */
struct delayed_work scan_work;
struct delayed_work assoc_work;
diff --git a/drivers/net/wireless/libertas/hostcmd.h
b/drivers/net/wireless/libertas/hostcmd.h
index f29bc5b..c36ab31 100644
--- a/drivers/net/wireless/libertas/hostcmd.h
+++ b/drivers/net/wireless/libertas/hostcmd.h
@@ -219,6 +219,7 @@ struct cmd_ds_mac_control {
};
struct cmd_ds_mac_multicast_adr {
+ struct cmd_header hdr;
__le16 action;
__le16 nr_of_adrs;
u8 maclist[ETH_ALEN * MRVDRV_MAX_MULTICAST_LIST_SIZE];
@@ -703,7 +704,6 @@ struct cmd_ds_command {
struct cmd_ds_802_11_rf_antenna rant;
struct cmd_ds_802_11_monitor_mode monitor;
struct cmd_ds_802_11_rate_adapt_rateset rateset;
- struct cmd_ds_mac_multicast_adr madr;
struct cmd_ds_802_11_ad_hoc_join adj;
struct cmd_ds_802_11_rssi rssi
Re: [PATCH olpc/stable] Rate adaptation configuration via iwconfig.
On Fri, 2008-05-23 at 14:21 -0700, Javier Cardona wrote: Implemented rate adaptation support via 'iwconfig rate' API. It is now possible to specify a bit-rate value and append 'auto'. That will configure rate adaptation to use all bit-rates equal or lower than than selected value. Made lbs_cmd_802_11_rate_adapt_rateset a direct command. This patch is made against olpc/stable so testing can start right away. If feedback is good, I'll adapt to libertas-2.6 and resubmit to libertas-dev. Looks good to me; thanks. And you've even moved it out of the big switch statements, which is great. Acked-By: David Woodhouse [EMAIL PROTECTED] -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 10:37 -0400, Michail Bletsas wrote: The userspace tool is extremely awkward to use (since it requires the driver modules to be unloaded which in turn makes the identification of devices on the XO even more difficult) I believe there's a way for libusb to unbind the existing driver and steal the device for itself. We just never bothered to _do_ it because it was never really an issue. Dan? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 10:12 -0400, Dan Williams wrote: So why are we doing this with the driver, and not the userspace update tool? Marvell keeps wanting to do firmware update in the driver, and we (David and I at least) keep saying no. If there are issues that prevent the userspace firmware update tool from working, then we need to fix those issues. Firmware updates from the driver were a disaster the first time around, and I don't quite see how that may have changed this time? And if we _are_ going to do it in the driver, which is far from clear, then look at the way the dell_rbu driver gets firmware from userspace with an asynchronous request_firmware() call. That's probably the way we'd want to do it. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:34 -0300, Ricardo Carrano wrote: A necessary rectification: Firmware updates from the driver are the only method that works currently. If we want to name one method a disaster, we would have to choose the userspace tool, since it will brick many of your active antennae. Bug number(s), please. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:44 -0300, Ricardo Carrano wrote: Please check comment on: http://wiki.laptop.org/go/Active_Antenna_Reprogramming#User_Space_Method Where am I looking? The 'has failed twice' claim? That's hardly a decent bug report. Put a coherent report in trac, and we'll look at it. Let's see a dump of the contents of the flash on the offending units. The userspace tool does exactly the same as the kernel was doing to program the firmware -- there's absolutely no reason why it should be any different. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:03 -0400, John Watlington wrote: My bad. This is now Trac #7170 http://dev.laptop.org/ticket/7170 All of the information in this ticket comes from email exchanged with dcbw and dwmw2 when I first discovered it. Didn't we fix that months ago by increasing the time we wait for flashing? Is this really what Ricardo was talking about? He needs to be careful he doesn't get the same kind of reputation as Michail already has. We have enough people whose words need to be taken with a _large_ pinch of salt around here already. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: JFFS2 error messages
On Tue, 2008-06-03 at 12:13 -0400, C. Scott Ananian wrote: 2008/6/3 Bill Mccormick [EMAIL PROTECTED]: A couple of my XOs are reporting what look like FS error messages on boot: [91.463670] JFFS2 notice: (664) check_node_data: wrong data CRC in data node at 0x1ec215f0: read 0x3e7c7e03, calculated 0xf7e1d50c ... is this a known problem? According to Dave Woodhouse, who wrote JFFS2, these notices typically mean that at some point you've hard powered off, and as a result JFFS has some uncommitted data lying around on flash. It's almost always harmless, a part of the journal which was never committed: either it was a new write which hadn't yet been synced, or it was a GC write which just doesn't achieve anything now. However, these messages *could* indicate an actual problem -- we never came up with a good heuristic for when _not_ to complain. Woodhouse suggests that in the future perhaps we should write a 'yes, I know there's a CRC failure' node _after_ the offending node, when we reboot and find it since directly rewriting the node is not an option due to the mechanics of NAND flash; that would help confine these messages to immediately after a hard reboot. At present, you'll keep seeing a bad CRC message every time that particular JFFS node is accessed until it is eventually GC'ed. Anyone want to volunteer to turn the above into a FAQ which would be discoverable on our wiki, so that future wonderers don't have to pry the information from the head of dwmw2? I think it's already in trac as an RFE. I even respond to email about it when the email in question isn't HTML. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:28 -0400, Dan Williams wrote: I'm happy to test this out and try to get the userspace tool working again if given: Last time I knew, the userspace tool _was_ working. Although we'd stripped out the support from the kernel driver ages ago and wrote libertas-flash.py, Michail for some reason told Marvell to put it back into the driver instead of updating libertas-flash.py as they should have done -- but we _fixed_ that back in January when I was in Mongolia and had active antennae to update, didn't we? I'm a bit confused that we're having the same discussion _again_. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND out of space crash
On Mon, 2008-07-21 at 09:51 -0700, Deepak Saxena wrote: On Jul 21 2008, at 13:39, C. Scott Ananian was caught saying: 2) JFFS2's behavior when the file system is almost full. When it gets almost full, it can spend all its time trying to garbage collect, and you can lose completely (the system sort of gets the slows, and grinds to a halt). As to 2), there are patches done by Nokia (deployed on the N800 and similar devices) that reserve some extra space and report out of space before the system gets the slows. These are in Dave's incoming queue to merge into JFFS2 the last I heard. I don't know if he's merged them. These are less critical, IMO. I have filled up NAND, and the slows are not debilitating. The issues above are. We should encourage Dave to fix this issue and the other known JFFS2 bugs (trac #6480, for instance) -- or get dsaxena to do so -- for 9.1. #6480 is fixed as of yesterday, should be in next joyride. Yeah. Since it was purely cosmetic I figured it might as well just wait to come through 'naturally'. I'll be re-doing Nokia's patches so that they go upstream if we still want them after 8.2 is out; however, I don't think the approach used by them actually helps us. We already have a very limited amount of storage space and reserving space for the root user just reduces what the end user can actually use. I think analyzing performance of non-JFFS2 file systems and picking a replacement should be a high-priority item for 9.1 update. I'm looking at making btrfs work on pure flash. It looks fairly sane in that respect. Using a 'standard' file system will have benefits... -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NAND out of space crash
On Mon, 2008-07-21 at 10:29 -0700, Deepak Saxena wrote: I can go ahead and apply the existing Nokia patch into the 8.2 kernel as a short-term measure but don't want to arbitrarilly choose a reservation size. Dave, do you have a suggestion as to what percentage should be reserved to keep the GC from going out of control? If not, we'll need to run some performance tests to find the sweet spot. I don't have a suggestion. But I'd prefer not to apply the overly complex patch from Artem -- just add a 'root only' threshold and hard-code it for now (we should really expose _all_ the thresholds in sysfs). -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH 1/3] Use PCI_DEVICE_ID_88ALP01 for CAFÉ chip, rather than PCI_DEVICE_ID_CAFE.
Probably better to use the official designation.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
---
(Carried in git://git.infradead.org/~dwmw2/random-2.6.git)
drivers/mmc/host/sdhci-pci.c |2 +-
include/linux/pci_ids.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index fcb14c2..0341cfb 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -326,7 +326,7 @@ static const struct pci_device_id pci_ids[] __devinitdata =
{
{
.vendor = PCI_VENDOR_ID_MARVELL,
- .device = PCI_DEVICE_ID_MARVELL_CAFE_SD,
+ .device = PCI_DEVICE_ID_MARVELL_88ALP01_SD,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
.driver_data= (kernel_ulong_t)sdhci_cafe,
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index f1624b3..ef6ef64 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1521,7 +1521,7 @@
#define PCI_DEVICE_ID_MARVELL_GT64260 0x6430
#define PCI_DEVICE_ID_MARVELL_MV64360 0x6460
#define PCI_DEVICE_ID_MARVELL_MV64460 0x6480
-#define PCI_DEVICE_ID_MARVELL_CAFE_SD 0x4101
+#define PCI_DEVICE_ID_MARVELL_88ALP01_SD 0x4101
#define PCI_VENDOR_ID_V3 0x11b0
#define PCI_DEVICE_ID_V3_V960 0x0001
--
1.5.5.1
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
[PATCH 2/3] [MTD] [NAND] Define and use PCI_DEVICE_ID_MARVELL_88ALP01_NAND for CAFÉ
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
---
(Carried in git://git.infradead.org/~dwmw2/random-2.6.git)
drivers/mtd/nand/cafe_nand.c |6 +-
include/linux/pci_ids.h |1 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index 95345d0..b8064bf 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -1,6 +1,9 @@
/*
* Driver for One Laptop Per Child ‘CAFÉ’ controller, aka Marvell 88ALP01
*
+ * The data sheet for this device can be found at:
+ *http://www.marvell.com/products/pcconn/88ALP01.jsp
+ *
* Copyright © 2006 Red Hat, Inc.
* Copyright © 2006 David Woodhouse [EMAIL PROTECTED]
*/
@@ -842,7 +845,8 @@ static void __devexit cafe_nand_remove(struct pci_dev *pdev)
}
static struct pci_device_id cafe_nand_tbl[] = {
- { 0x11ab, 0x4100, PCI_ANY_ID, PCI_ANY_ID },
+ { PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_88ALP01_NAND,
+ PCI_ANY_ID, PCI_ANY_ID },
{ }
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ef6ef64..e6240b7 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1521,6 +1521,7 @@
#define PCI_DEVICE_ID_MARVELL_GT64260 0x6430
#define PCI_DEVICE_ID_MARVELL_MV64360 0x6460
#define PCI_DEVICE_ID_MARVELL_MV64460 0x6480
+#define PCI_DEVICE_ID_MARVELL_88ALP01_NAND 0x4100
#define PCI_DEVICE_ID_MARVELL_88ALP01_SD 0x4101
#define PCI_VENDOR_ID_V3 0x11b0
--
1.5.5.1
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
[PATCH 3/3] Define and use PCI_DEVICE_ID_MARVELL_88ALP01_CCIC for CAFÉ camera driver
Also, stop looking at the NAND controller (0x4100) and checking the
device class. For a while during development, all three functions on the
chip had the same ID. We made them fix that fairly promptly, and we can
forget about it now.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
---
(Carried in git://git.infradead.org/~dwmw2/random-2.6.git)
drivers/media/video/cafe_ccic.c | 13 +++--
include/linux/pci_ids.h |1 +
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c
index c149b7d..ea0db81 100644
--- a/drivers/media/video/cafe_ccic.c
+++ b/drivers/media/video/cafe_ccic.c
@@ -2091,15 +2091,8 @@ static int cafe_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
int ret;
- u16 classword;
struct cafe_camera *cam;
- /*
-* Make sure we have a camera here - we'll get calls for
-* the other cafe devices as well.
-*/
- pci_read_config_word(pdev, PCI_CLASS_DEVICE, classword);
- if (classword != PCI_CLASS_MULTIMEDIA_VIDEO)
- return -ENODEV;
+
/*
* Start putting together one of our big camera structures.
*/
@@ -2287,8 +2280,8 @@ static int cafe_pci_resume(struct pci_dev *pdev)
static struct pci_device_id cafe_ids[] = {
- { PCI_DEVICE(0x11ab, 0x4100) }, /* Eventual real ID */
- { PCI_DEVICE(0x11ab, 0x4102) }, /* Really eventual real ID */
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL,
+PCI_DEVICE_ID_MARVELL_88ALP01_CCIC) },
{ 0, }
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index e6240b7..6cf53f4 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1523,6 +1523,7 @@
#define PCI_DEVICE_ID_MARVELL_MV64460 0x6480
#define PCI_DEVICE_ID_MARVELL_88ALP01_NAND 0x4100
#define PCI_DEVICE_ID_MARVELL_88ALP01_SD 0x4101
+#define PCI_DEVICE_ID_MARVELL_88ALP01_CCIC 0x4102
#define PCI_VENDOR_ID_V3 0x11b0
#define PCI_DEVICE_ID_V3_V960 0x0001
--
1.5.5.1
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: LBA NAND corruption
On Tue, 2008-10-21 at 12:22 -0400, John Watlington wrote: Mitch, One of the LBA NAND test machines killed it's MBR. It started with a failed comparison of the commonly written blocks, then stopped talking to the device at all. On reboot, fdisk showed no partition table. dd of /dev/lba showed all FFs for the first 16K, then 00 for the next 2K, then data. Suggestions on how to proceed w. debugging are welcome. This is one of the reasons I'm so concerned about this type of device. When you're dealing with stuff in software, if you have a bug you can whip the developers harder. When something goes wrong inside the device's internal firmware, there really isn't much you can do about it at all. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: LBA NAND corruption
On Tue, 2008-10-21 at 08:41 -1000, Mitch Bradley wrote: For example, consider yourself. When you worked for RH, OLPC could get lots of your valuable attention because of the OLPC/RH connection. But now that you are associated with Intel, what is the situation? (Perhaps we could in fact get some of your cycles; I'm just saying that the answer doesn't seem obvious and straightforward.) Now I work for Intel, I hear occasional vague rumours that you found something wrong, but you never actually seem to _tell_ me so... -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New mesh throughput record?
On Wed, 2008-10-22 at 00:01 -1000, Mitch Bradley wrote: It might also be a Linux scheduler artifact, perhaps related to the multithreaded nature of the Libertas driver. That's possible -- TX packets aren't sent directly from the driver's hard_start_xmit() function, but are just queued for the main thread to send them. It's like that because that was the 'sledgehammer' fix for the evil locking problems which the original driver had. There will be a certain amount of latency introduced by the current setup, obviously. If we believe we now have a handle on the concurrency issues, then we could sensibly look at moving the actual TX handling back into the TX routines. Carefully. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] cafe_nand: remove busy-wait loop
On Wed, 2008-12-10 at 15:36 -0500, Chris Ball wrote: Hi John, It's unfortunate that there's no block device way to access Flash chips in Linux without using a filesystem at all. It's much easier to measure and tune I/O performance without a filesystem first, then see what (filesystem or driver) optimizations are required to make a particular filesystem fast on that device. What's wrong with just reading from the character device /dev/mtd0? Does e.g. dd if=mtd0 of=somefile bs=1M count=20 accomplish this? (When a program expects a block device argument, you can give a raw mtd0 instead.) No, that's only for mount. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: CL1B power distribution
On Sun, 2009-04-26 at 00:40 -0400, Benjamin M. Schwartz wrote: John Watlington wrote: Quick straw poll on how many people think it is useful enough have individual control over the power supplied to each connector to raise the cost of the laptop by $0.15 ? Turning off a single port to which nothing is connected saves no power, right? I don't see the appeal. It was nice that we could stagger the switching on of USB ports, to avoid crashes due to power surges and resulting drops on the power rail. How sure are you that we won't need similar workarounds in CL1B? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC does end run around IP addresses
On Sat, 2010-01-09 at 04:03 -0600, Mikus Grinbergs wrote: What I see the XOs doing is an end run around my concept of how remote nodes are supposed to be accessed. I believe 'ping' is behaving the standards-compliant way (192.168.1.0/24 does not access 169.254.0.0/16, and vice versa). Whereas what shows up in the XO Neighborhood View (and in 'olpc-xos') appears to ignore standards-compliance. Surely all your machines can communicate quite happily using IPv6 link-local addresses? Why this fascination with Legacy IP? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC does end run around IP addresses
On Wed, 2010-01-13 at 09:02 -0600, Mikus Grinbergs wrote: Because none of my facilities (including my desktops) are set up to use IPv6. If you're running any recent OS, I strongly suspect you'll find that they are. More to the point -- I have an emotional prejudice against IPv6 -- I am NOT looking forward to the day when my refrigerator has its own IPv6 address, and reports to third parties how much beer I have downed. Nothing prevents it from doing that with Legacy IP either :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
+
+ switch (tech.intval) {
+ case POWER_SUPPLY_TECHNOLOGY_NiMH:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 300*.8;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ case POWER_SUPPLY_TECHNOLOGY_LiFe:
+ switch (mfr) {
+ case 1: /* Gold Peak */
+ val-intval = 280;
+ break;
+ case 2: /* BYD */
+ val-intval = 310;
+ break;
+ default:
+ return -EIO;
+ }
+ break;
+
+ default:
+ return -EIO;
+ }
+
+ return ret;
+}
I don't much like hard-coding it in the kernel. Can the firmware expose
these values in the device-tree?
--
dwmw2
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
On Fri, 2010-12-10 at 16:38 -0800, Andres Salomon wrote: It there is, it's not at all clear. The values are fetched from the EC, which get them from the EEPROM. If the EC knows them, can't we ask the EC rather than pulling numbers our of our arse in the kernel? The DT has a battery entry, but it contains nothing useful: /proc/device-tree/batt...@0/name /proc/device-tree/batt...@0/reg /proc/device-tree/batt...@0/.node The driver ought to be matching on that rather than registering its own platform device. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH 0/3] olpc-battery: add properties needed by UPower
On Tue, 2010-12-21 at 16:43 -0800, Andres Salomon wrote: Given that OLPC machines out there currently have broken battery information with UPower and friends, I think that the patches should be applied. Doing stuff in the EC or device-tree may be done in the future, but even after it's written debugged, it will still take some time for people to upgrade their firmware. Agreed. In the general case in future though, it would be really useful if we could avoid having magic numbers like this in the kernel; we want them to come from as close to the hardware as possible. Given that we *have* a sane firmware on OLPC, we should be using it. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Building kernel RPMs with patches from git
On Thu, 2008-05-08 at 10:06 +1200, Martin Langhoff wrote:
Dennis, David,
There is right now something that I am having trouble understanding
how it's done - related to kernel packaging. Is there any
documentation on how the RH team manages kernels with additional
patches?
All I can find is tips to manage the patches as patches, but that is
so oldstyle. I want a git-integrated workflow... or quilt or whatever.
What I would like to do is to track the appropriate git branch that RH
has for F7 kernels, and merge in the Libertas patches. Right now we
are doing a pretty hackish thing ;-)
Is there anything like this? I'm sure the RH kernel team is using _some_
dscm...
Actually, we don't. It really is just patches -- and we try to have as
few of those as possible.
We don't normally do development directly on the packaged kernel. The
real development happens in rawhide, which tracks upstream -- so we work
on the upstream kernel's git tree. Then we can just create patches and
add them to the RPM.
I believe there is a way to make quilt use RPM specfiles. I've never
really bothered looking it up, though -- others may know more, if you
ask in the right places (like fedora-kernel-list, which I've added to
Cc).
If I really have to hack on the RPM-built kernel directly for some
reason, I'll do something like this -- starting from the _very_
beginning just in case...
Obviously, start by checking the kernel in question out from Fedora CVS,
just as you would for any other package. I'll use anoncvs here, but
presumably any OLPC developer would have a proper account of their own
and be a real part of the Fedora community.
$ cd ~/working/fedora-pkgs
$ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/pkgs co common
$ cvs -d :pserver:[EMAIL PROTECTED]:/cvs/pkgs co kernel/F-7
$ cd kernel/F-7
Then, I find it useful to disable a bunch of the builds I'm not
interested in, to speed things up and to make sure that the tree I'm
left with in my build directory is actually the one I want to frob with:
$ cat GNUmakefile EOF
ppc: DIST_DEFINES += --with baseonly
ppc64: DIST_DEFINES += --with baseonly
i686: DIST_DEFINES += --with baseonly
include Makefile
EOF
Finally, you can build a kernel by running 'make i686'. Or just run
through and apply the patches by running 'make prep'.
If I want to play, I'll usually build a kernel package, and install it
on the unit under test. Then I can go and edit the source files in the
build tree in ~/working/fedora-pkgs/kernel/F-7/kernel-2.6.23/linux-2.6.23.i686
and I can rebuild both kernel and modules and replace them individually
for testing.
When I'm done, generating a patch is as simple as:
$ cd kernel-2.6.23
$ for a in `find linux-2.6.23 -name \*~` ; do diff -up ${a%%\~} $a ; done | tee
linux-2.6-foo.patch
Then I can add that patch to the specfile, do a final build (make i686)
to test, and commit it.
If your editor doesn't leave backup files around or you've done it in so
many sessions that your backup files aren't the originals, you can run
'make prep' and then do a recursive diff between the clean
linux-2.6.23.noarch and your edited linux-2.6.23.i686 directories.
For libertas, we really ought to fix up the private ioctl crap so that
it's acceptable upstream, and then we could merge it into the Fedora
kernel. Hell, if you ask John nicely, maybe he'd let us do it anyway --
I've just been assuming he'd say 'no'. We try not to put things into
Fedora which aren't going upstream, in general.
--
dwmw2
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
