**** BEGIN LOGGING AT Sat Mar 05 23:59:56 2005 Mar 06 00:19:26 dyoung: I need the xilinx library for Eagle... Mar 06 03:57:57 ka6sox, I have a partial xilinx library, but its on the work lappy, which is well; at work. Mar 06 09:49:30 dyoung: I'll fake it then Mar 06 09:49:35 NP Mar 06 10:04:00 morning Mar 06 10:09:01 Morning. Mar 06 10:16:16 <[g2]> beewoolie-away, morning! Mar 06 10:18:45 [g2]: Doin' a little work on the ext2 driver. I've got it parsing the inodes. Working on the directory searching. Mar 06 10:18:58 <[g2]> awesome! Mar 06 10:19:11 <[g2]> that's exciting Mar 06 10:19:22 <[g2]> were your ears burning about 15 minutes ago ? Mar 06 10:19:36 Uh, yeah, sure. Flames and all. Mar 06 10:20:31 <[g2]> http://groups.yahoo.com/group/nslu2-linux/message/4849 **** ENDING LOGGING AT Sun Mar 06 11:20:55 2005 **** BEGIN LOGGING AT Sun Mar 06 11:24:04 2005 **** ENDING LOGGING AT Sun Mar 06 11:30:27 2005 **** BEGIN LOGGING AT Sun Mar 06 11:34:05 2005 Mar 06 11:50:07 <[g2]> beewoolie-away, ever use lmza compression ? Mar 06 11:50:20 Don't know it. Mar 06 11:50:27 Is it better than bzip? Mar 06 11:50:28 <[g2]> ok Mar 06 11:50:47 <[g2]> I think it's supposed to compress better than bzip2 Mar 06 11:51:16 <[g2]> I heard some ppl getting a 1.2MB kernel down < 1MB Mar 06 11:54:06 There is no comparison with bzip on the 7-zip pae. Mar 06 11:54:37 (page) Mar 06 13:29:10 ~seen kas11 Mar 06 13:29:11 kas11 <~kas11@193-63.73-24.tampabay.rr.com> was last seen on IRC in channel #openjtag, 19d 22h 40m 33s ago, saying: 'as I recall, you have a problem when the id doesn't fit in 8 bits'. Mar 06 13:29:14 kas11 <~karen@193-63.73-24.tampabay.res.rr.com> was last seen on IRC in channel #openjtag, 2d 23h 7m 42s ago, saying: 'I was happy to see that we now have Sir Billy Gates...who sez BSODs don't pay'. Mar 06 13:29:32 ~seen dyoung Mar 06 13:29:33 dyoung is currently on #openjtag Mar 06 13:29:34 dyoung is currently on #openjtag (1d 23h 37m 16s) #nslu2-linux (1d 23h 37m 16s) #oe (1d 23h 37m 16s). Has said a total of 238 messages. Is idling for 7m 4s Mar 06 13:29:56 ~lart qbot Mar 06 13:29:57 * qbot drops a truckload of VAXen on ka6sox-away Mar 06 13:29:57 * purl nabs the moon and broadsides qbot with the sea of tranquility Mar 06 13:30:53 ~lart purl Mar 06 13:30:53 * qbot --purges purl Mar 06 13:30:53 * purl crushes purl with a full height scsi disk Mar 06 13:31:08 ~insult qbot Mar 06 13:31:10 qbot is nothing but a vain bucket of bawdy pus Mar 06 13:31:29 same bot...different reactions. Mar 06 13:32:33 ~karma dyoung Mar 06 13:32:34 dyoung has karma of 4 Mar 06 13:32:34 dyoung has neutral karma Mar 06 13:32:54 ~stats Mar 06 13:32:54 Since Sun Mar 6 11:33:11 2005, there have been 0 modifications and 0 questions and 0 dunnos and 0 morons and 0 commands. I have been awake for 1h 59m 43s this session, and currently reference 51 factoids. I'm using about 11872 kB of memory. Mar 06 13:32:55 Since Mon Feb 28 23:53:00 2005, there have been 75 modifications, 665 questions, 0 dunnos, 0 morons and 516 commands. I have been awake for 5d 21h 39m 54s this session, and currently reference 108252 factoids. I'm using about 18716 kB of memory. With 0 active forks. Process time user/system 10910.86/738.52 child 797.55/66.28 Mar 06 16:30:23 ~seen qbot Mar 06 16:30:24 i haven't seen 'qbot', ka6sox Mar 06 16:30:55 ~seen purl Mar 06 16:30:55 purl is currently on #openjtag. Has said a total of 4 messages. Is idling for 2h 58m Mar 06 16:31:07 ~lart qbot Mar 06 16:31:08 * qbot whacks ka6sox with the cluebat Mar 06 16:31:20 purl: stats Mar 06 16:32:32 You broke it! Mar 06 16:32:39 ~stats Mar 06 16:32:39 Since Sun Mar 6 11:33:11 2005, there have been 0 modifications and 1 question and 0 dunnos and 0 morons and 0 commands. I have been awake for 4h 59m 28s this session, and currently reference 51 factoids. I'm using about 11912 kB of memory. Mar 06 16:33:16 yepo Mar 06 16:39:25 <[g2]> dyoung, get you module in ? Mar 06 16:41:47 Nope. Mar 06 16:43:17 dont have a device to test it with yet. Mar 06 17:00:57 <[g2]> AH Mar 06 17:01:11 <[g2]> that never stopped kergoth :) Mar 06 17:01:17 yeah Mar 06 17:01:25 Actaully its written/. Mar 06 17:01:28 just didnt run it yet. Mar 06 17:01:48 <[g2]> :) Mar 06 17:02:47 <[g2]> beewoolie-away, a read from disk can trigger the "nobody cared" int Mar 06 17:03:04 <[g2]> cat sources/* > /dev/nul Mar 06 17:03:10 <[g2]> triggers it Mar 06 17:03:11 [g2]: That's also interesting. Mar 06 17:03:32 <[g2]> well you ask interesting questions Mar 06 17:03:41 <[g2]> that's a read from the hd Mar 06 17:03:49 [g2] does it do that uner EHCI only? or under OHCI as well? Mar 06 17:04:02 Either it's a timing problem with the ehci driver, or there is some peculiar interaction with the upper-layer driver. Mar 06 17:04:42 What I'd do is add code to the interrupt handler to dump the ehci registers when it is going to return without processing an interrupt. Mar 06 17:06:05 I can imagine that what is happening is this: there is time for the ehci driver to service two requests from the hardware. It does so, but an interrupt has been signaled and recognized by the kernel. It comes back to the driver, but there is nothing to do. Mar 06 17:06:51 [g2]: Have you tried bonnie to see what the disk throughput looks like? Mar 06 17:07:06 <[g2]> http://www.textuality.com/bonnie/ Mar 06 17:07:08 <[g2]> looking now Mar 06 17:07:27 Debian has an arm binary. Mar 06 17:08:14 BTW, I've got the ext2 driver in APEX working. I'm adding a capability for following symlinks. Mar 06 17:08:55 <[g2]> AWESOME Mar 06 17:09:12 <[g2]> so we can build ext2 as the rootfs Mar 06 17:09:32 <[g2]> and lose the kernel partition Mar 06 17:09:35 I believe so. There is an important piece of glue that we may have to hack for the time being. Mar 06 17:09:43 APEX doesn't have a way to chain drivers. Mar 06 17:10:10 <[g2]> I don't think we'd need to chain drivers Mar 06 17:10:13 We need that in order to flexibly handle interfacing ext2 to various lower-level drivers. Mar 06 17:10:18 <[g2]> at least not for a while :) Mar 06 17:10:29 Well, it's about structure. It can be hacked for now. Mar 06 17:10:50 <[g2]> I don't think I quite understand what your are saying Mar 06 17:11:00 ext2 is only an fs driver. Mar 06 17:11:06 <[g2]> are you talking about pulling the kernel out of the fs ? Mar 06 17:11:13 It doesn't know anything about the underlying hw access. Mar 06 17:11:30 Yeah. The problem is that the ext2 driver is now hard-wired to read from compact flash. Mar 06 17:11:45 <[g2]> ok I get it now Mar 06 17:11:46 We want to be able to read from an arbitrary source. Mar 06 17:11:56 <[g2]> CF, USB, NET, .... Mar 06 17:12:06 <[g2]> well not really net but you get the idea Mar 06 17:12:06 Moreover, I need to have a couple of layers of chaining so that the partition code can be pulled from the ext2 driver. Mar 06 17:12:12 Right. Mar 06 17:12:32 <[g2]> you can loop mount ext2 but not jffs2 Mar 06 17:12:36 I've been mulling over it since I don't want to do it badly. Mar 06 17:12:45 I don't know what you mean? Mar 06 17:12:58 You can mount jffs2 over RAM. Mar 06 17:13:17 <[g2]> just saying the ext2 is just a logical structure that more easily abstracted Mar 06 17:13:23 Right. Mar 06 17:13:39 I Mar 06 17:13:41 <[g2]> and there needs to be a driver mechanism supporting the device access Mar 06 17:13:50 I''ll probably have to implement jffs2 at some point, too. Mar 06 17:13:57 <[g2]> which is the chaining you are talking about Mar 06 17:14:02 Yeah. Mar 06 17:14:25 <[g2]> Do you handle compressed ext2 ? Mar 06 17:14:26 Really, I've done the hard part. This chaining part is only a problem because it is exposed to the user. Mar 06 17:14:42 I don't know. Is the compression at the file level? Mar 06 17:14:55 <[g2]> no the ext2 level Mar 06 17:15:06 <[g2]> rootfs.ext2.gz Mar 06 17:15:09 I have a zlib inflat module implemented. Mar 06 17:15:20 <[g2]> another chain in the link :) Mar 06 17:15:24 I don't know if that will work. Mar 06 17:15:34 I need to be able to do random access. Mar 06 17:15:56 <[g2]> I think all it does is uncompress the image into memory Mar 06 17:16:16 <[g2]> so it a time space trade-off Mar 06 17:16:18 At some point, we need to just accept what we've got working and move on. Mar 06 17:16:41 <[g2]> nod. but ext2.gz is pretty standard Mar 06 17:16:57 The point here is that we can pull data from a ext2 partition in flash. Right? Mar 06 17:17:03 <[g2]> we've got bigger fish to fry atm Mar 06 17:17:16 If the user wants to conerve space, I think we're better off supporting jffs2 or cramfs. Mar 06 17:17:34 <[g2]> cramfs is RO Mar 06 17:17:45 Well, ext2.gz isn't going to be writable. Mar 06 17:18:08 <[g2]> no it'd be a ramdisk Mar 06 17:18:14 <[g2]> writeable in ram Mar 06 17:18:30 Well, I can extract the ext2.gz into ram if that is what we need. That's easy. Mar 06 17:18:38 <[g2]> that's all Mar 06 17:19:22 I suppose that is what we need anyway. I believe the kernel can inflate the ramdisk, too. Mar 06 17:19:36 ~praise beewoolie-away Mar 06 17:19:36 All Hail beewoolie-away! Mar 06 17:19:37 If we do it ourselves, it just shortens the process. Mar 06 17:19:47 * beewoolie-away waves Mar 06 17:20:15 <[g2]> that and it hard for the kernel to pull itself out of the middle of a compressed image its in Mar 06 17:20:35 Klein bottle of a boot process. Mar 06 17:21:00 <[g2]> is that those little ships in the bottle ? Mar 06 17:21:28 http://www.google.com/search?q=klein+bottle&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox&rls=org.mozilla:en-US:unofficial Mar 06 17:22:37 <[g2]> nod. Mar 06 17:23:09 <[g2]> like the strip that you cut and twist and tape back together Mar 06 17:23:22 There are going to be some details to work out. I may just have to get my sh*t together and figure out how to implement the region descriptors. Mar 06 17:23:30 Mobius strip. Mar 06 17:23:38 <[g2]> exactly Mar 06 17:24:14 a 4D mobius. Mar 06 17:24:27 I feel my brain going into a spacial anomoly. Mar 06 17:24:36 * beewoolie-away holds his aching head. Mar 06 17:25:00 I feel the need to shovel some dirt. back later. Mar 06 17:25:54 <[g2]> ok so back to reality EHCI Mar 06 17:28:24 It's an external chip, right? Mar 06 17:28:29 <[g2]> nod Mar 06 17:28:34 <[g2]> NEC Mar 06 17:29:05 Is this driver custom/specific to the ixp? Mar 06 17:29:38 <[g2]> I think the NEC chip is pretty standard Mar 06 17:29:47 <[g2]> it's probably a port from x86 Mar 06 17:30:02 <[g2]> or maybe native in the kernel Mar 06 17:30:16 It's important only in that if it is *not* custom, then we should worry. Mar 06 17:31:07 <[g2]> ummm, you mean if it's *not* custom then there are arch issue that are probably ignored Mar 06 17:31:17 Yeah. Mar 06 17:31:21 something like that. Mar 06 17:31:22 <[g2]> :) Mar 06 17:32:11 <[g2]> Funny, when you say it that way it sounds so sensible :) Mar 06 17:32:42 Do you have a kernel config for the slug? I want to know what USB options are set. Mar 06 17:32:54 <[g2]> sure Mar 06 17:34:27 You're defining EHCI as well as OHCI. Is that necessary? Mar 06 17:34:35 <[g2]> yes Mar 06 17:34:58 <[g2]> well maybe not Mar 06 17:35:13 <[g2]> there's an on board ohci that's not wired to anything Mar 06 17:35:26 That's why I ask. Mar 06 17:35:36 Sur it is. Mar 06 17:35:48 Have you tried enabling USB_DEBUG? Mar 06 17:35:49 <[g2]> the ixp420 has an ohci controller iirc Mar 06 17:35:51 thats how rwhitby made accessslug work. Mar 06 17:36:04 ohci Mar 06 17:36:05 the nec part has 2 ohci and ehci port. Mar 06 17:36:07 not uhci Mar 06 17:36:34 the ixp420 has onboard UHCI. Mar 06 17:36:54 [g2]: I'd set the debug option and try your test again. Mar 06 17:36:55 that should read: the nec part has 2 ohci and 1 ehci port. Mar 06 17:37:07 Are we using the ohci ports? Mar 06 17:37:18 Well they work.... Mar 06 17:37:42 Its unclear to me if the chip decides to do the right thing or... ?? Mar 06 17:37:44 <[g2]> maybe they are conflicting Mar 06 17:38:13 They "sort of" work. Mar 06 17:38:15 When i turn off ohci it has the same net result. Mar 06 17:38:45 well, rod's "access slug" has ehci turned off because its busted, and everything works just fine with only ohci turned on. Mar 06 17:39:52 <[g2]> OK the point is this happens under load Mar 06 17:40:10 <[g2]> I doubt that a 12Mbs connection could trigger the condition Mar 06 17:40:22 <[g2]> or it might just be rare Mar 06 17:40:47 <[g2]> Maybe he could spends many hours coping 380MB worth of files Mar 06 17:40:56 <[g2]> at 1MB a second Mar 06 17:41:29 <[g2]> maybe that'd would trigger it Mar 06 17:42:02 It looks like we're using the PCI implementation. Mar 06 17:42:29 Does it say something about (PCI) in the dmesg's? Mar 06 17:42:41 With respect to the USB controller? Mar 06 17:43:26 <[g2]> you mean on boot ? Mar 06 17:43:35 PCI: enabling device 0000:00:01.2 (0140 -> 0142) Mar 06 17:43:35 ehci_hcd 0000:00:01.2: EHCI Host Controller Mar 06 17:43:35 ehci_hcd 0000:00:01.2: irq 26, pci mem 48002000 Mar 06 17:43:35 ehci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1 Mar 06 17:43:35 ehci_hcd 0000:00:01.2: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10 Mar 06 17:44:13 OK. Then it's using the ehci driver and not the ohci driver. Mar 06 17:44:27 It also says this though Mar 06 17:44:28 ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) Mar 06 17:44:29 <[g2]> it says the same with ohci Mar 06 17:44:29 PCI: enabling device 0000:00:01.0 (0140 -> 0142) Mar 06 17:44:29 ohci_hcd 0000:00:01.0: OHCI Host Controller Mar 06 17:44:30 ohci_hcd 0000:00:01.0: irq 28, pci mem 48000000 Mar 06 17:44:32 ohci_hcd 0000:00:01.0: new USB bus registered, assigned bus number 2 Mar 06 17:44:36 <[g2]> different irq Mar 06 17:44:50 Which interrupt is being 'Nobody'd'? Mar 06 17:44:55 26 or 28 Mar 06 17:44:57 and theres another oneusing irq27 Mar 06 17:45:00 26 Mar 06 17:45:05 for the EHCI componemt. Mar 06 17:45:24 So, it's definitely the ehci that's going awry. Mar 06 17:45:28 I'm sorry if I'm confusing the issue. Mar 06 17:46:00 I'm just attempting to point out the facts. Mar 06 17:46:05 <[g2]> 26: 208268 ehci_hcd Mar 06 17:46:15 <[g2]> irq26: nobody cared Mar 06 17:46:25 I'd still like to see a test with the USB DEBUG config set. Mar 06 17:46:31 <[g2]> dyoung, help appreciatied Mar 06 17:46:32 It'll tell us a lot about what's happening. Mar 06 17:46:38 * [g2] just built Mar 06 17:46:48 I don't have a USB drive. Mar 06 17:47:55 Otherwise I'd do it. Mar 06 17:48:06 okay I'm gonna go shovel now. Mar 06 17:48:09 <[g2]> beewoolie-away, is such an over-achiever :) Mar 06 17:48:23 * beewoolie-away waves Mar 06 17:49:30 * [g2] hugs beewoolie-away Mar 06 17:50:22 <[g2]> Ok from the OLD Linksys firmware I just noticed this Mar 06 17:50:25 <[g2]> ehci_hcd 00:01.2: NEC Corporation USB 2.0 Mar 06 17:50:25 <[g2]> ehci_hcd 00:01.2: irq 26, pci mem c3801f00 Mar 06 17:50:25 <[g2]> usb.c: new USB bus registered, assigned bus number 1 Mar 06 17:50:25 <[g2]> PCI: 00:01.2 PCI cache line size set incorrectly (0 bytes) by BIOS/FW. Mar 06 17:50:25 <[g2]> PCI: 00:01.2 PCI cache line size corrected to 32. Mar 06 17:50:26 <[g2]> ehci_hcd 00:01.2: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-19/2.4 Mar 06 17:51:08 <[g2]> the cache line size set incorrectly is interesting Mar 06 17:51:16 That's because we don't set it at all. Mar 06 17:51:33 Redboot would have to do it, but we might as well let the driver do it. Mar 06 17:52:22 <[g2]> that's the PCI cache line size Mar 06 17:52:42 * [g2] flashing Mar 06 17:52:48 I thought it was the CPU cache line size, really. Mar 06 17:53:05 <[g2]> dunno Mar 06 17:54:48 I don't know much about PCI. I think I like it that way. Mar 06 18:05:16 <[g2]> ok TAKE 2 Mar 06 18:05:35 <[g2]> the config option didn't get set Mar 06 18:26:38 <[g2]> beewoolie-away, it looks the same Mar 06 18:28:20 <[g2]> root@LKG0F9D2C:/media/hdd# cat /proc/config.gz | gunzip | grep -i USB_DEBUG Mar 06 18:28:21 <[g2]> CONFIG_USB_DEBUG=y Mar 06 18:28:36 <[g2]> the output look really similar Mar 06 18:29:07 There is no difference when you get the error? Mar 06 18:29:24 <[g2]> well is seems slightly more tolerant Mar 06 18:29:36 <[g2]> well it Mar 06 18:32:11 In the code, there are a couple of extra options. ehci_stats and ehci_verbose_debug. They're worth a try. Mar 06 18:33:37 <[g2]> this is mildly interesting http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg31981.html Mar 06 18:35:35 It looks like it may be possible that there is an interrupt being signaled and the driver is ignoring it. Mar 06 18:36:24 not very relevent, tho. Mar 06 18:36:56 <[g2]> I don't see those ehci options Mar 06 18:37:25 They're in the source file for the hcd. drivers/usb/host/ehci-hcd.c Mar 06 18:37:36 There's another thing we should do.... Mar 06 18:38:16 I'd like to know if the controller is experiencing an interrupt that it cannot process. Mar 06 18:38:53 I'd like to add a line to the ehci-hcd.c file just before it masks status with intr_mask in ehci_irq(). Mar 06 18:38:57 Something like this: Mar 06 18:39:34 if (status & ~INTR_MASK) printk ("%s: ignoring %x\n", status & ~INTR_MASK); Mar 06 18:40:14 I'd have to pull the datasheet to explore this further is that message ever appears. Mar 06 18:44:23 <[g2]> ummm we sould be getting stats Mar 06 18:57:51 Did you add the printk, too? Mar 06 18:59:21 <[g2]> nod. Mar 06 18:59:38 <[g2]> >Kernel panic - not syncing: Aiee, killing interrupt handler! Mar 06 19:00:07 <[g2]> Unable to handle kernel paging request at virtual address 00002008 Mar 06 19:00:08 <[g2]> pgd = c0004000 Mar 06 19:00:08 <[g2]> [00002008] *pgd=00000000 Mar 06 19:00:08 <[g2]> Internal error: Oops: 17 [#1] Mar 06 19:00:08 <[g2]> Modules linked in: ehci_hcd ixp425_eth ixp400 Mar 06 19:00:08 <[g2]> CPU: 0 Mar 06 19:00:10 <[g2]> PC is at strnlen+0x1c/0x44 Mar 06 19:00:11 Oops. I forgot to add this: Mar 06 19:00:20 <[g2]> LR is at vsnprintf+0x308/0x578 Mar 06 19:00:26 if (status & ~INTR_MASK) printk ("%s: ignoring %x\n", __FUNCTION__, status & ~INTR_MASK) Mar 06 19:00:31 ooops. Mar 06 19:00:36 <[g2]> :) Mar 06 19:00:46 The compiler usually complains. Mar 06 19:10:17 <[g2]> DS time :) Mar 06 19:10:21 <[g2]> ub 3-0:1.0: USB hub found Mar 06 19:10:21 <[g2]> hub 3-0:1.0: 5 ports detected Mar 06 19:10:21 <[g2]> ehci_irq: ignoring 2008 Mar 06 19:10:21 <[g2]> usb 3-1: new high speed USB device using ehci_hcd and address 2 Mar 06 19:10:21 <[g2]> ehci_irq: ignoring 8008 Mar 06 19:10:22 <[g2]> ehci_irq: ignoring 8008 Mar 06 19:10:24 <[g2]> ehci_irq: ignoring 8008 Mar 06 19:10:26 <[g2]> ehci_irq: ignoring 8008 Mar 06 19:10:28 <[g2]> ehci_irq: ignoring 8008 Mar 06 19:10:29 Ah. Mar 06 19:10:30 <[g2]> ehci_irq: ignoring 8008 Mar 06 19:10:32 <[g2]> ehci_irq: ignoring 8008 Mar 06 19:10:35 Let's see what we can find? Mar 06 19:10:37 <[g2]> ehci_irq: ignoring a008 Mar 06 19:10:50 Are you getting nobody cared messages? Mar 06 19:11:19 <[g2]> that's on the load of the driver Mar 06 19:11:30 <[g2]> I'm run the dd to generate the nobody cared Mar 06 19:12:00 <[g2]> I"m generating a bunch more Mar 06 19:12:09 <[g2]> (from the mount) Mar 06 19:12:36 <[g2]> ok I think this is the guy Mar 06 19:12:41 I wasn't expecting to see the ignore message without nobody-cared, too Mar 06 19:13:24 Don't we have datasheets on the nslu2 wiki? Mar 06 19:13:47 <[g2]> http://www.necel.com/usb/en/product/upd720101.html. Mar 06 19:16:37 Need a login to get the DS. Mar 06 19:16:49 It may be better to get the ehci spec. Mar 06 19:20:38 Do you get any other bits? Mar 06 19:21:03 I've got the spec. It says that 0x8 is an interrupt bit, but the driver may not be using it. Mar 06 19:24:59 <[g2]> ehci_irq: ignoring 8008 Mar 06 19:24:59 <[g2]> ehci_irq: ignoring 8008 Mar 06 19:24:59 <[g2]> irq26: nobody cared Mar 06 19:24:59 <[g2]> PC is at ehci_watchdog+0xe8/0xf4 [ehci_hcd] Mar 06 19:25:18 <[g2]> a couple times we get a008 Mar 06 19:26:14 <[g2]> we generate nearly 6K printk's while dd'ing that 128MB file of zeros Mar 06 19:26:43 <[g2]> Are we generating that on every interrupt ? Mar 06 19:26:51 <[g2]> because it's never cleared ? Mar 06 19:27:55 The bits that aren't being cleared are status bits for other conditions. As far as I can tell, there isn't any significance to them unless bit 3 is set in the interrupt enable register, which I doubt. Mar 06 19:30:13 Is the USB controller on a 16 or 32 bit bus? Do you know? Mar 06 19:30:54 It might be worth trying to change the register accesses to 16 bits instead of 32 if the bus is 16 bits. Mar 06 19:32:11 I'm giving in for the night. Mar 06 19:32:28 I'll be back tomorrow. Maybe I'll have an inspiration while I sleep. Mar 06 19:33:16 Frankly, I think that this might be a red herring. Mar 06 19:33:32 It may simply be that the controller is having a burp. Mar 06 19:33:38 Nite. Mar 06 19:36:23 <[g2]> nite **** ENDING LOGGING AT Sun Mar 06 21:56:37 2005 **** BEGIN LOGGING AT Sun Mar 06 22:26:04 2005 **** ENDING LOGGING AT Sun Mar 06 23:18:05 2005 **** BEGIN LOGGING AT Sun Mar 06 23:24:04 2005 **** ENDING LOGGING AT Sun Mar 06 23:30:23 2005 **** BEGIN LOGGING AT Sun Mar 06 15:40:05 2005 **** ENDING LOGGING AT Sun Mar 06 23:59:56 2005