Re: [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged
On Fri, Sep 06, 2019, Borislav Petkov wrote: > On Fri, Sep 06, 2019 at 08:46:18AM -0700, Johannes Erdfelt wrote: > > That said, we very much rely on late microcode loading and it has helped > > us and our customers significantly. > > You do realize that you rely on an update method which *won't* work in > all possible cases and then you *will* have to reboot if the microcode > patching *must* happen early, do you? Yeah. I even explained some cases where it wouldn't work. If we get a microcode update that isn't late loadable, then yes, we have to do something different. That doesn't mean that late loading isn't still useful. In practice, it can be very valuable. It isn't bad or dangerous in vast majority of cases. We haven't had a microcode update across all of the models of Intel CPUs we have (going back a handful of generations) in the past almost two years that wasn't safely late loadable. Just as I can't know for sure that every future microcode update will be safely late loadable, you can't know for sure that every future microcode update won't be safely late loadable. > > It's really easy to say "fix your infrastructure" when you're not > > running that infrastructure. > > I'm not saying you should fix your infrastructure now - I'm saying you > should keep that in mind when thinking whether to rely more on late > loading or not. Who knows, maybe newer generation machines in the fleet > could do load balancing, live migration, whatever fancy new cloud stuff > it is, to facilitate a proper reboot. We are well aware of the downsides of late microcode loading and live patching. However, like I said, it's currently the best tools available. We are certainly looking at other options, but some aren't feasible for mitigating security vulnerabilities where time to getting patched is very much important. > > The more reboots we can avoid, the better it is for us and our > > customers. > > So how do you update the kernels on those machines? Or you live-patch in > the new functionality too? Depends on what kind of patch is needed. Livepatching, while having it's own set of problems, has been very valuable for us. We do use other techniques as well particularly when it's not time sensitive. > > I understand that it could be unsafe to late load some rare microcode > > updates (theoretical or not). However, that is certainly the exception. > > We have done this multiple times on our fleet and we plan to continue > > doing so in the future. > > The fact that it has worked for you does not make it right. It won't > magically become safe, as tglx said. It very much makes it right because it's still a tool that can be used safely in the right cases. Just because it can't be used 100% of the time (even if it is close to that in practice) doesn't make it magically unsafe either. > Practically speaking, late loading probably won't disappear as it is > being used apparently. Just don't expect that it will get "extended" if > that extension brings with itself fallout and duct tape fixes left and > right. I don't have a particular use case for the patchset at hand and I'm certainly not arguing for or against this patchset. But I do get concerned when there is talk about removing a feature we currently use extensively. I'm happy to hear it will likely not be removed and I hope it was partly because I spoke up to show that is actively being used and it's important to us. JE
Re: [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged
On Fri, Sep 06, 2019, Borislav Petkov wrote: > On Fri, Sep 06, 2019 at 07:40:39AM -0700, Johannes Erdfelt wrote: > > I ask because we have successfully used late microcode loading on tens > > of thousands of hosts. > > How do you deal with all the mitigations microcode loaded late? We developed livepatches to add the necessary support. I understand we aren't the typical Linux user. We do custom development and validation to support our use case. That said, we very much rely on late microcode loading and it has helped us and our customers significantly. > > I'm a bit worried to see that there is a push to remove a feature that > > we currently rely on. > > I'd love to remove it. And the fact that people rely on it more instead > of fixing their infrastructure to reboot machines and do early microcode > updates is making it worse. Microcode update should be batched with > kernel updates and that's it. They happen normally once-twice per year - > except the last two years but the last two years are not normal anyway > - and done. No need to do some crazy CPUID features reloading dances in > the kernel and making sure cores will see the updated paths and so on. It's really easy to say "fix your infrastructure" when you're not running that infrastructure. Reboots suck. Customers hate it. Operations hates it. When you get into the number of hosts we have, you run into all kinds of weird failure scenarios. (What do you mean that the NIC that was working just fine before the reboot is no longer seen on the PCI bus?) The more reboots we can avoid, the better it is for us and our customers. I understand that it could be unsafe to late load some rare microcode updates (theoretical or not). However, that is certainly the exception. We have done this multiple times on our fleet and we plan to continue doing so in the future. There just aren't any good alternatives currently. JE
Re: [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged
On Fri, Sep 06, 2019, Thomas Gleixner wrote:
> What your customers are asking for is a receipe for disaster. They can
> check the safety of late loading forever, it will not magically become safe
> because they do so.
>
> If you want late loading, then the whole approach needs to be reworked from
> ground up. You need to make sure that all CPUs are in a safe state,
> i.e. where switching of CPU feature bits of all sorts can be done with the
> guarantee that no CPU will return to the wrong code path after coming out
> of safe state and that any kernel internal state which depends on the
> previous set of CPU feature bits has been mopped up and switched over
> before CPUs are released.
You say that switching of CPU feature bits is problematic, but adding
new features should result only in a warning ("x86/CPU: CPU features
have changed after loading microcode, but might not take effect.").
Removing a CPU feature bit could be problematic. Other than HLE being
removed on Haswell (which the kernel shouldn't use anyway), have there
been any other cases?
I ask because we have successfully used late microcode loading on tens
of thousands of hosts. I'm a bit worried to see that there is a push to
remove a feature that we currently rely on.
JE
Re: Oops caused by race between livepatch and ftrace
On Mon, May 20, 2019, Josh Poimboeuf wrote: > I think you must have been looking at an old version. > > [(v5.2-rc1)] ~/git/linux $ grep jeyu MAINTAINERS > M:Jessica Yu Operator error on my part. I was looking at a different directory with an old branch checked out. Sorry! > Can you try this patch (completely untested)? It seems to be working fine for me. No crashes in a loop for a few minutes, when it would usually only take a couple of tries to reproduce the issue for me. I'll see if I can better reproduce the race from the ftrace side since every crash I have seen for this issue has been in apply_relocate_add on the livepatch side. JE
Re: Oops caused by race between livepatch and ftrace
On Mon, May 20, 2019, Joe Lawrence wrote: > [ fixed jeyu's email address ] Thank you, the bounce message made it seem like my mail server was blocked and not that the address didn't exist. I think MAINTAINERS needs an update since it still has the @redhat.com address. > On 5/20/19 3:49 PM, Johannes Erdfelt wrote: > > [ ... snip ... ] > > > > I have put together a test case that can reproduce the crash using > > KVM. The tarball includes a minimal kernel and initramfs, along with > > a script to run qemu and the .config used to build the kernel. By > > default it will attempt to reproduce by loading multiple livepatches > > at the same time. Passing 'test=ftrace' to the script will attempt to > > reproduce by racing with ftrace. > > > > My test setup reproduces the race and oops more reliably by loading > > multiple livepatches at the same time than with the ftrace method. It's > > not 100% reproducible, so the test case may need to be run multiple > > times. > > > > It can be found here (not attached because of its size): > > http://johannes.erdfelt.com/5.2.0-rc1-a188339ca5-livepatch-race.tar.gz > > Hi Johannes, > > This is cool way to distribute the repro kernel, modules, etc! This oops was common in our production environment and was particularly annoying since livepatches would load at boot and early enough to happen before networking and SSH were started. Unfortunately it was difficult to reproduce on other hardware (changing the timing just enough) and our production environment is very complicated. I spent more time than I'd like to admit trying to reproduce this fairly reliably. I knew that I needed to help make it as easy as possible to reproduce to root cause it and for others to take a look at it as well. > These two testing scenarios might be interesting to add to our selftests > suite. Can you post or add the source(s) to livepatch-test.ko to the > tarball? I made the livepatches using kpatch-build and this simple patch: diff --git a/fs/proc/version.c b/fs/proc/version.c index 94901e8e700d..6b8a3449f455 100644 --- a/fs/proc/version.c +++ b/fs/proc/version.c @@ -12,6 +12,7 @@ static int version_proc_show(struct seq_file *m, void *v) utsname()->sysname, utsname()->release, utsname()->version); + seq_printf(m, "example livepatch\n"); return 0; } I just created enough livepatches with the same source patch so that I could reproduce the issue somewhat reliably. I'll see if I can make something that uses klp directly. The rest of the userspace in the initramfs is really straight forward with the only interesting parts being a couple of shell scripts. JE
Oops caused by race between livepatch and ftrace
There exists a race condition between livepatch and ftrace that can cause an oops similar to this one: BUG: unable to handle page fault for address: c005b1d9 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 3ea0c067 P4D 3ea0c067 PUD 3ea0e067 PMD 3cc13067 PTE 3b8a1061 Oops: 0003 [#1] PREEMPT SMP PTI CPU: 1 PID: 453 Comm: insmod Tainted: G O K 5.2.0-rc1-a188339ca5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014 RIP: 0010:apply_relocate_add+0xbe/0x14c Code: fa 0b 74 21 48 83 fa 18 74 38 48 83 fa 0a 75 40 eb 08 48 83 38 00 74 33 eb 53 83 38 00 75 4e 89 08 89 c8 eb 0a 83 38 00 75 43 <89> 08 48 63 c1 48 39 c8 74 2e eb 48 83 38 00 75 32 48 29 c1 89 08 RSP: 0018:b223c00dbb10 EFLAGS: 00010246 RAX: c005b1d9 RBX: RCX: 8b200060 RDX: 000b RSI: 004b000b RDI: 96bdfcd33000 RBP: b223c00dbb38 R08: c005d040 R09: c005c1f0 R10: 96bdfcd33c40 R11: 96bdfcd33b80 R12: 0018 R13: c005c1f0 R14: c005e708 R15: 8b2fbc74 FS: 7f5f447beba8() GS:96bdff90() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c005b1d9 CR3: 3cedc002 CR4: 00360ea0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: klp_init_object_loaded+0x10f/0x219 ? preempt_latency_start+0x21/0x57 klp_enable_patch+0x662/0x809 ? virt_to_head_page+0x3a/0x3c ? kfree+0x8c/0x126 patch_init+0x2ed/0x1000 [livepatch_test02] ? 0xc006 do_one_initcall+0x9f/0x1c5 ? kmem_cache_alloc_trace+0xc4/0xd4 ? do_init_module+0x27/0x210 do_init_module+0x5f/0x210 load_module+0x1c41/0x2290 ? fsnotify_path+0x3b/0x42 ? strstarts+0x2b/0x2b ? kernel_read+0x58/0x65 __do_sys_finit_module+0x9f/0xc3 ? __do_sys_finit_module+0x9f/0xc3 __x64_sys_finit_module+0x1a/0x1c do_syscall_64+0x52/0x61 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5f44764881 Code: 0e 4c 8b 44 24 10 4d 8d 48 08 4c 89 4c 24 10 44 8b 4c 24 08 4d 8b 00 4c 01 c9 41 83 f9 2f 76 05 48 8b 4c 24 10 4c 8b 09 0f 05 <48> 89 c7 e8 f7 e9 fd ff 48 83 c4 58 c3 56 31 d2 be 02 00 08 00 bf RSP: 002b:7ffcf1e64b80 EFLAGS: 0212 ORIG_RAX: 0139 RAX: ffda RBX: 006229a0 RCX: 7f5f44764881 RDX: RSI: 0041a506 RDI: 0003 RBP: 0041a506 R08: R09: 7ffcf1e64c48 R10: 0003 R11: 0212 R12: R13: 006228c0 R14: R15: Modules linked in: livepatch_test03(OK+) livepatch_test01(OK+) livepatch_test11(OK+) livepatch_test06(OK+) livepatch_test04(OK+) livepatch_test02(OK+) livepatch_test10(OK+) livepatch_test16(OK+) livepatch_test18(OK-) livepatch_test12(OK) CR2: c005b1d9 ---[ end trace 52fee0aa635dd5a1 ]--- The oops occurs because both livepatch and ftrace remap the module text section at the same. After ftrace is done, it can leave the module text text section mapped RO when the livepatch code is expecting it to be RW. CPU A CPU B set_all_modules_text_rw (module is now RW) module_disable_ro (module is still RW) set_all_modules_text_ro (module is now RO) apply_relocate_add (oops) I've reproduced it from the latest code in git (a188339ca5a3), 5.0.17, 4.19.44, 4.14.120, 4.9.177 and some kernels in between. I haven't tried reproducing on any kernel older than 4.9. From looking at the older versions in git, it will likely be harder to reproduce since the kernel switched in 4.5 to remapping RW once from remapping on every write. The oops will only occur if CONFIG_STRICT_MODULE_RWX is enabled (previously called CONFIG_DEBUG_SET_MODULE_RONX). I've found two ways the race condition can be reproduced: 1) loading multiple livepatches at the same time 2) loading a livepatch at the same time ftrace is patching code They are both ultimately the same root cause since livepatch uses ftrace to perform the patching. I have put together a test case that can reproduce the crash using KVM. The tarball includes a minimal kernel and initramfs, along with a script to run qemu and the .config used to build the kernel. By default it will attempt to reproduce by loading multiple livepatches at the same time. Passing 'test=ftrace' to the script will attempt to reproduce by racing with ftrace. My test setup reproduces the race and oops more reliably by loading multiple livepatches at the same time than with the ftrace method. It's not 100% reproducible, so the test
Re: Linux 2.4.32-pre2
On Thu, Jul 28, 2005, Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > diff --git a/drivers/usb/host/uhci.c b/drivers/usb/host/uhci.c > --- a/drivers/usb/host/uhci.c > +++ b/drivers/usb/host/uhci.c > @@ -2924,7 +2924,7 @@ static int alloc_uhci(struct pci_dev *de > } > > /* Only place we don't use the frame list routines */ > - uhci->fl->frame[i] = uhci->skeltd[irq]->dma_handle; > + uhci->fl->frame[i] = uhci->skeltd[irq]->dma_handle | > UHCI_PTR_QH; > } > > start_hc(uhci); Am I missing something here? We're certainly adding TDs to the schedule, so why is this patch setting the QH bit? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.32-pre2
On Thu, Jul 28, 2005, Marcelo Tosatti [EMAIL PROTECTED] wrote: diff --git a/drivers/usb/host/uhci.c b/drivers/usb/host/uhci.c --- a/drivers/usb/host/uhci.c +++ b/drivers/usb/host/uhci.c @@ -2924,7 +2924,7 @@ static int alloc_uhci(struct pci_dev *de } /* Only place we don't use the frame list routines */ - uhci-fl-frame[i] = uhci-skeltd[irq]-dma_handle; + uhci-fl-frame[i] = uhci-skeltd[irq]-dma_handle | UHCI_PTR_QH; } start_hc(uhci); Am I missing something here? We're certainly adding TDs to the schedule, so why is this patch setting the QH bit? JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB API, ioctl's and libusb
On Thu, Jan 27, 2005, DervishD <[EMAIL PROTECTED]> wrote: > Didn't knew about that... Thanks a lot for the info!. Is there > any documentation available for the ioctl USB interface to the > kernel? Any API guide or something like that? You can use the kernel sources to see how to use it. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB API, ioctl's and libusb
On Thu, Jan 27, 2005, DervishD [EMAIL PROTECTED] wrote: Didn't knew about that... Thanks a lot for the info!. Is there any documentation available for the ioctl USB interface to the kernel? Any API guide or something like that? You can use the kernel sources to see how to use it. JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB API, ioctl's and libusb
On Wed, Jan 26, 2005, DervishD <[EMAIL PROTECTED]> wrote: > * Oliver Neukum <[EMAIL PROTECTED]> dixit: > > Am Mittwoch, 26. Januar 2005 13:20 schrieb DervishD: > > > ? ? My question is: which interface should be used by user space > > > applications, or ioctl's? Is the ioctl interface > > > deprecated in any way? In the "Programming guide for Linux USB Device > > > Drivers", located in http://usb.in.tum.de/usbdoc/, I can't find ioctl > > > interface references :? > > You are supposed to use libusb. > > That's irrelevant, the program I was trying to fix uses libusb. > My question is about the preferred kernel interface, 'cause I don't > know if it's the ioctl one or the URB one (well, I'm calling 'URB' > interface the API that is implemented using URB's inside the kernel). ioctl() calls are for userspace only. It just so happens there is an ioctl() call that provides an URB like interface and an ioctl() call that provides a synchronous call to do a control message. > BTW, and judging from the program I've read, there are lots of > operations that must be done using 'usb_control_msg', and libusb > implements that function with exactly the same interface as the > kernel. The only difference is that libusb uses ioctl and the kernel > implements the function using URB's. IMHO libusb doesn't provide a > cleaner API, the only advantage of libusb is portability. Anyway, > I've not used it enough to judge, I'm more concerned about kernel USB > interface, not libusb one. I think you're looking at this incorrectly. You use the kernel API for kernel modules. You can use either the ioctl() API or libusb for userspace applications. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB API, ioctl's and libusb
On Wed, Jan 26, 2005, DervishD [EMAIL PROTECTED] wrote: * Oliver Neukum [EMAIL PROTECTED] dixit: Am Mittwoch, 26. Januar 2005 13:20 schrieb DervishD: ? ? My question is: which interface should be used by user space applications, linux/usb.h or ioctl's? Is the ioctl interface deprecated in any way? In the Programming guide for Linux USB Device Drivers, located in http://usb.in.tum.de/usbdoc/, I can't find ioctl interface references :? You are supposed to use libusb. That's irrelevant, the program I was trying to fix uses libusb. My question is about the preferred kernel interface, 'cause I don't know if it's the ioctl one or the URB one (well, I'm calling 'URB' interface the API that is implemented using URB's inside the kernel). ioctl() calls are for userspace only. It just so happens there is an ioctl() call that provides an URB like interface and an ioctl() call that provides a synchronous call to do a control message. BTW, and judging from the program I've read, there are lots of operations that must be done using 'usb_control_msg', and libusb implements that function with exactly the same interface as the kernel. The only difference is that libusb uses ioctl and the kernel implements the function using URB's. IMHO libusb doesn't provide a cleaner API, the only advantage of libusb is portability. Anyway, I've not used it enough to judge, I'm more concerned about kernel USB interface, not libusb one. I think you're looking at this incorrectly. You use the kernel API for kernel modules. You can use either the ioctl() API or libusb for userspace applications. JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI fundamental locking problems
On Tue, Jul 03, 2001, Jeff Garzik <[EMAIL PROTECTED]> wrote: > I was reading through the ACPI spec, to see what was required to obtain > the IRQ routing table from AML. FWIW, ia64 already does this, if you're looking for the code to do it. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI fundamental locking problems
On Tue, Jul 03, 2001, Jeff Garzik [EMAIL PROTECTED] wrote: I was reading through the ACPI spec, to see what was required to obtain the IRQ routing table from AML. FWIW, ia64 already does this, if you're looking for the code to do it. JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Still some problems with UHCI driver in 2.4.5 on VIA chipsets
On Tue, Jun 19, 2001, Dylan Griffiths <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt wrote: > > Could you load uhci with the debug=1 option? > > I did an 'insmod uhci.o debug=1' but the dmesg output did not alter. > > My easy steps to reproduce it is to 'delete selected images' in gphoto such > that there will be no images in the camera left when the operation is done. > At loast it doesn't lock up the camera like it used to :-/ > > I think this may be a problem in the dc2xx.o then, since uhci didn't reveal > any new messages. It's possible. Many cameras are touchy wrt to the commands it receives. If one is slightly wrong, some of them will just stop talking. Did you try with the usb-uhci driver as well? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Still some problems with UHCI driver in 2.4.5 on VIA chipsets
On Tue, Jun 19, 2001, Dylan Griffiths [EMAIL PROTECTED] wrote: Johannes Erdfelt wrote: Could you load uhci with the debug=1 option? I did an 'insmod uhci.o debug=1' but the dmesg output did not alter. My easy steps to reproduce it is to 'delete selected images' in gphoto such that there will be no images in the camera left when the operation is done. At loast it doesn't lock up the camera like it used to :-/ I think this may be a problem in the dc2xx.o then, since uhci didn't reveal any new messages. It's possible. Many cameras are touchy wrt to the commands it receives. If one is slightly wrong, some of them will just stop talking. Did you try with the usb-uhci driver as well? JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Still some problems with UHCI driver in 2.4.5 on VIA chipsets
On Sun, Jun 17, 2001, Dylan Griffiths <[EMAIL PROTECTED]> wrote: > dmesg log: > usb.c: registered new driver dc2xx > dc2xx.c: v1.0.0 David Brownell, <[EMAIL PROTECTED]> > dc2xx.c: USB Camera Driver for Kodak DC-2xx series cameras > PCI: Found IRQ 5 for device 00:04.2 > PCI: The same IRQ used for device 00:04.3 > uhci.c: USB UHCI at I/O 0xd400, IRQ 5 > usb.c: new USB bus registered, assigned bus number 1 > hub.c: USB hub found > hub.c: 2 ports detected > PCI: Found IRQ 5 for device 00:04.3 > PCI: The same IRQ used for device 00:04.2 > uhci.c: USB UHCI at I/O 0xd000, IRQ 5 > usb.c: new USB bus registered, assigned bus number 2 > hub.c: USB hub found > hub.c: 2 ports detected > uhci.c: Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti > Fliegl, Thomas Sailer, Roman Weissgaerber > uhci.c: USB Universal Host Controller Interface driver > hub.c: USB new device connect on bus1/2, assigned device number 2 > dc2xx.c: USB Camera #0 connected, major/minor 180/80 > ** here is where it froze ** > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb.c: USB disconnect on device 2 > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > ** rmmod the drivers ** > dc2xx.c: USB Camera #0 disconnected > usb.c: USB disconnect on device 1 > usb.c: USB bus 1 deregistered > usb.c: USB disconnect on device 1 > usb.c: USB bus 2 deregistered > usb.c: deregistering driver dc2xx > ** usbcore refuses to rmmod because its ref cnt won't decrement, this also > affected it before I had the usb_control/bulk_msg timeout/loop issues ** Could you load uhci with the debug=1 option? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Still some problems with UHCI driver in 2.4.5 on VIA chipsets
On Sun, Jun 17, 2001, Dylan Griffiths [EMAIL PROTECTED] wrote: dmesg log: usb.c: registered new driver dc2xx dc2xx.c: v1.0.0 David Brownell, [EMAIL PROTECTED] dc2xx.c: USB Camera Driver for Kodak DC-2xx series cameras PCI: Found IRQ 5 for device 00:04.2 PCI: The same IRQ used for device 00:04.3 uhci.c: USB UHCI at I/O 0xd400, IRQ 5 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 5 for device 00:04.3 PCI: The same IRQ used for device 00:04.2 uhci.c: USB UHCI at I/O 0xd000, IRQ 5 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected uhci.c: Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber uhci.c: USB Universal Host Controller Interface driver hub.c: USB new device connect on bus1/2, assigned device number 2 dc2xx.c: USB Camera #0 connected, major/minor 180/80 ** here is where it froze ** usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb.c: USB disconnect on device 2 usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout ** rmmod the drivers ** dc2xx.c: USB Camera #0 disconnected usb.c: USB disconnect on device 1 usb.c: USB bus 1 deregistered usb.c: USB disconnect on device 1 usb.c: USB bus 2 deregistered usb.c: deregistering driver dc2xx ** usbcore refuses to rmmod because its ref cnt won't decrement, this also affected it before I had the usb_control/bulk_msg timeout/loop issues ** Could you load uhci with the debug=1 option? JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drivers/usb/ov511.c does not compile
On Fri, Jun 15, 2001, Kelledin Tane <[EMAIL PROTECTED]> wrote: > Apologies if this has been posted before. I imagine it has. > > In kernel 2.4.5 stock, ov511.c fails to compile. A little intelligent > searching through 2.4.4 source reveals that the following line in 2.4.4: > > static const char version[] = "1.28"; > > is missing in 2.4.5, and this is why it does not compile. While I could > fix this myself manually (and plan to do so), it would be nice to get > the developer's blessing on this, and also nice to know exactly what > version number to give this driver in 2.4.5 stock. This has already been fixed in the 2.4.5 pre patches. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drivers/usb/ov511.c does not compile
On Fri, Jun 15, 2001, Kelledin Tane [EMAIL PROTECTED] wrote: Apologies if this has been posted before. I imagine it has. In kernel 2.4.5 stock, ov511.c fails to compile. A little intelligent searching through 2.4.4 source reveals that the following line in 2.4.4: static const char version[] = 1.28; is missing in 2.4.5, and this is why it does not compile. While I could fix this myself manually (and plan to do so), it would be nice to get the developer's blessing on this, and also nice to know exactly what version number to give this driver in 2.4.5 stock. This has already been fixed in the 2.4.5 pre patches. JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual Athlon on 2.2.19 ?
On Thu, May 24, 2001, Prasanna P Subash <[EMAIL PROTECTED]> wrote: > Without the patch below the boot up would hang right after it detected the > ide devices. > > After applying the patch it booted all the way but the keyboard would hang. > > BTW I'm trying to port this patch back to the 2.2.18 TL-Kernel. Are there > anymore changes I have to look at ? There were 2 patches. The one that went into 2.2.20-pre1 (not the patch you just sent) and the patch you just sent. You need both. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual Athlon on 2.2.19 ?
On Thu, May 24, 2001, Prasanna P Subash <[EMAIL PROTECTED]> wrote: > I have a dual athlon on the 760MP chipset. > 2.2.20pre1 and 2 dont work. I got it to work partly after applying Johannes > Erdfel's 760MP patch in io_apic.c. Even after applying the patch, there > are messages like 2.2.20pre1 and pre2 both have the patch I created already applied. If you had to apply them yourself then something is wrong. > hdc: IRQ probe failed(0) > hdd: IRQ probe failed(0) > hde: IRQ probe failed(0) > > hdc: lost interrupt > hdc: lost interrupt > > and then the machine hangs randomly. I an guessing the io_apic does not > route the interrupts correctly. That would be the problem. Which patch of mine did you apply? Which motherboard are you doing your testing with? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual Athlon on 2.2.19 ?
On Thu, May 24, 2001, Prasanna P Subash [EMAIL PROTECTED] wrote: Without the patch below the boot up would hang right after it detected the ide devices. After applying the patch it booted all the way but the keyboard would hang. BTW I'm trying to port this patch back to the 2.2.18 TL-Kernel. Are there anymore changes I have to look at ? There were 2 patches. The one that went into 2.2.20-pre1 (not the patch you just sent) and the patch you just sent. You need both. JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dual Athlon on 2.2.19 ?
On Thu, May 24, 2001, Prasanna P Subash [EMAIL PROTECTED] wrote: I have a dual athlon on the 760MP chipset. 2.2.20pre1 and 2 dont work. I got it to work partly after applying Johannes Erdfel's 760MP patch in io_apic.c. Even after applying the patch, there are messages like 2.2.20pre1 and pre2 both have the patch I created already applied. If you had to apply them yourself then something is wrong. hdc: IRQ probe failed(0) hdd: IRQ probe failed(0) hde: IRQ probe failed(0) hdc: lost interrupt hdc: lost interrupt and then the machine hangs randomly. I an guessing the io_apic does not route the interrupts correctly. That would be the problem. Which patch of mine did you apply? Which motherboard are you doing your testing with? JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thu, May 17, 2001, Pavel Machek <[EMAIL PROTECTED]> wrote: > > > But no, I don't actually like sockets all that much myself. They are hard > > > to use from scripts, and many more people are familiar with open/close and > > > read/write. > > > > Agreed. > > > > It would be nice to use open/close/read/write for control and bulk and > > sockets for interrupt and isochronous. > > What makes interrupt so different? Last time I checked int pipes were very > similar to bulk pipes... Do you care about "packet boundaries"? You can > somehow emulate with read, too... We probably could. It would have interesting semantics however. We would have to have an ioctl or something else to specify period, and if it's one shot, etc. We could probably shoehorn isochronous semantics onto read/write as well, but I don't want to begin to think how ugly that'll be. The reason I don't favor the read/write idea for interrupt and isochronous are the fact that they are so different. We could shoehorn the semantics onto it, but we'd just be moving the problem from one place to somewhere else. A completely ioctl solution would work better in that case since it's cleaner. The only problem would be the fact it's called ioctl. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thu, May 17, 2001, Pavel Machek [EMAIL PROTECTED] wrote: But no, I don't actually like sockets all that much myself. They are hard to use from scripts, and many more people are familiar with open/close and read/write. Agreed. It would be nice to use open/close/read/write for control and bulk and sockets for interrupt and isochronous. What makes interrupt so different? Last time I checked int pipes were very similar to bulk pipes... Do you care about packet boundaries? You can somehow emulate with read, too... We probably could. It would have interesting semantics however. We would have to have an ioctl or something else to specify period, and if it's one shot, etc. We could probably shoehorn isochronous semantics onto read/write as well, but I don't want to begin to think how ugly that'll be. The reason I don't favor the read/write idea for interrupt and isochronous are the fact that they are so different. We could shoehorn the semantics onto it, but we'd just be moving the problem from one place to somewhere else. A completely ioctl solution would work better in that case since it's cleaner. The only problem would be the fact it's called ioctl. JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thu, May 17, 2001, Kai Henningsen <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Johannes Erdfelt) wrote on 15.05.01 in ><[EMAIL PROTECTED]>: > > > I had always made the assumption that sockets were created because you > > couldn't easily map IPv4 semantics onto filesystems. It's unreasonable > > to have a file for every possible IP address/port you can communicate > > with. > > Not at all. What is unreasonable is douing a "ls" on the directory in > question. > > Big deal; make it mode d--x--x--x. Problem solved. > > And I'm pretty certain stuff like that *has* been done - wasn't there a > ftp file system where you could "ls /mountpoint/ftp.kernel.org/pub/linux"? I think this is the difference between reasonable and unreasonable. I'm sure it could be done, but should it? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Thu, May 17, 2001, Kai Henningsen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Johannes Erdfelt) wrote on 15.05.01 in [EMAIL PROTECTED]: I had always made the assumption that sockets were created because you couldn't easily map IPv4 semantics onto filesystems. It's unreasonable to have a file for every possible IP address/port you can communicate with. Not at all. What is unreasonable is douing a ls on the directory in question. Big deal; make it mode d--x--x--x. Problem solved. And I'm pretty certain stuff like that *has* been done - wasn't there a ftp file system where you could ls /mountpoint/ftp.kernel.org/pub/linux? I think this is the difference between reasonable and unreasonable. I'm sure it could be done, but should it? JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre1: Problems with SMP
On Wed, May 16, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote: > On Wed, May 16, 2001 at 12:56:55PM -0700, Johannes Erdfelt wrote: > > Could you try this patch? It applies on top of 2.2.20pre1 > > > > It also cleans up a couple of comments > > That fixes it alright. Excellent. Alan, could you apply the patch to 2.2.20pre2? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
> > On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> > >
> > > That does indeed correct the problem. 2.2.20pre1 now works
> > > as expected.
> >
> > Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does
> > 2.4 work on this system?
>
> The last 2.4 kernel I tried was 2.4.3 I believe and it
> worked fine more or less. I haven't tried any later 2.4
> kernels yet.
Could you try this patch? It applies on top of 2.2.20pre1
It also cleans up a couple of comments
JE
--- arch/i386/kernel/io_apic.c.old Wed May 16 12:48:03 2001
+++ arch/i386/kernel/io_apic.c Wed May 16 12:55:30 2001
@@ -204,6 +204,8 @@
/*
* We disable IO-APIC IRQs by setting their 'destination CPU mask' to
* zero. Trick by Ramesh Nalluri.
+ * Not anymore. This causes problems on some IO-APIC's, notably AMD 760MP's
+ * So we do it a more 2.4 kind of way now which should be safer -jerdfelt
*/
DO_ACTION( mask,0, |= 0x0001, io_apic_sync(entry->apic))/* mask = 1 */
DO_ACTION( unmask, 0, &= 0xfffe, )/* mask = 0 */
@@ -646,8 +648,8 @@
entry.delivery_mode = dest_LowestPrio;
entry.dest_mode = 1;/* logical delivery */
- entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest = 0xff; /* but no route */
+ entry.mask = 1; /* disable IRQ */
+ entry.dest.logical.logical_dest = 0xff;
idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote:
On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote:
That does indeed correct the problem. 2.2.20pre1 now works
as expected.
Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does
2.4 work on this system?
The last 2.4 kernel I tried was 2.4.3 I believe and it
worked fine more or less. I haven't tried any later 2.4
kernels yet.
Could you try this patch? It applies on top of 2.2.20pre1
It also cleans up a couple of comments
JE
--- arch/i386/kernel/io_apic.c.old Wed May 16 12:48:03 2001
+++ arch/i386/kernel/io_apic.c Wed May 16 12:55:30 2001
@@ -204,6 +204,8 @@
/*
* We disable IO-APIC IRQs by setting their 'destination CPU mask' to
* zero. Trick by Ramesh Nalluri.
+ * Not anymore. This causes problems on some IO-APIC's, notably AMD 760MP's
+ * So we do it a more 2.4 kind of way now which should be safer -jerdfelt
*/
DO_ACTION( mask,0, |= 0x0001, io_apic_sync(entry-apic))/* mask = 1 */
DO_ACTION( unmask, 0, = 0xfffe, )/* mask = 0 */
@@ -646,8 +648,8 @@
entry.delivery_mode = dest_LowestPrio;
entry.dest_mode = 1;/* logical delivery */
- entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest = 0xff; /* but no route */
+ entry.mask = 1; /* disable IRQ */
+ entry.dest.logical.logical_dest = 0xff;
idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre1: Problems with SMP
On Wed, May 16, 2001, Shane Wegner [EMAIL PROTECTED] wrote: On Wed, May 16, 2001 at 12:56:55PM -0700, Johannes Erdfelt wrote: Could you try this patch? It applies on top of 2.2.20pre1 It also cleans up a couple of comments That fixes it alright. Excellent. Alan, could you apply the patch to 2.2.20pre2? JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Tue, May 15, 2001, James Simmons <[EMAIL PROTECTED]> wrote: > > Personally, I'd really like to see /dev/ttyS0 be the first detected serial > > port on a system, /dev/ttyS1 the second, etc. Currently there are plenty of > > different serial hardware with all their own drivers and /dev entries. For > > embedded systems with serial consoles, and also across architectures, this > > is a pain since the filesystem and namely /dev/inittab has to be adjusted > > for all different types of UARTs. This is not the case for every different > > type of NICs and that's a good thing. > > I couldn't agree with you more. It gives me headaches at work. One note, > their is a except to the eth0 thing. USB to USB networking. It uses usb0, > etc. I personally which they use eth0. USB to USB networking cables aren't ethernet. There are USB to ethernet adapters and they do appear as eth0. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Tue, May 15, 2001, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Tue, 15 May 2001, Johannes Erdfelt wrote: > > > > Even bulk has issues because USB pipe's aren't necessarily streams, they > > can packetized in the psuedo weird way that USB does things. > > This is ok. "pipe" does not mean that the write data doesn't have > boundaries. > > Think about UDP. It's done with file desriptors, yet it is very much > packetized. > > Even a regular "pipe" actually has packet behaviour: a single write of < > PIPEBUF is guaranteed by UNIX to complete atomically, which is exactly so > that people can use pipes in a "packet" environment. > > A file descriptor does NOT imply that the data you read or write must be > one mushy stream of bytes. It's ok to honour write() packet boundaries > etc. > > You should absolutely NOT think that "we cannot send a packet down the > control pipe because multiple writers might confuse each other". You can > still require that separate packets be cleanly delimeted. > > It's a huge mistake to think that you _have_ to use ioctl's to get > "packet" behaviour, or to get structured reads/writes. We never made that assumption. We used ioctl's since it was the easiest and consistent way of solving the problem at the moment. We never said it was the pefect solution :) > The advantage of read/write is that it doesn't _force_ a packet on you, > but the kernel really doesn't care if you have some structure to your read > and write requests. No argument here. I completely agree. The problem with the shared control pipe is not 2 writers stomping on each other, it's permissions. You can have 2 interfaces on one device which are completely seperate from each other and you'd like 2 seperate users/programs to have access to each interface. Each endpoint is guaranteed to be unique to an interface, except for the default control pipe. A simple solution would be to clone the default control pipe for each interface and manage the permissions independantly. The major problem with read/write and USB is that while it can solve the problem for control and bulk pipes, it can't for interrupt and isochronous pipes. > > > or possibly you take a more socket-like approach and do > > > > > > fd = socket(part-of-the-structure); > > > bind(fd, more-of-the-structure) > > > connect(fd, last-part-of-the-structure); > > > > I don't like socket's since we do have a well bound set of endpoints. We > > don't have 4 billion IP's with 64k ports to choose from. We have x > > endpoints that the device tells us about ahead of time. > > Note that "sockets" != "IPv4". Sockets just have names, they can be IPv4 > (4+2 byte things), they can be pathnames (UNIX domain) and they can be > large IPv6 (16+2 or whatever). Or they could be small USB names. There's > nothing fundamentally wrong with "binding" a one-byte address and a > one-byte "interface" name. You'd just create a AF_USB layer ;) I had always made the assumption that sockets were created because you couldn't easily map IPv4 semantics onto filesystems. It's unreasonable to have a file for every possible IP address/port you can communicate with. It's not so unreasonable with USB however since the data set (endpoints) is significantly smaller and manageable. It can be placed in the filesystem namespace without any problems. That being said, we can't solve all of USB's problems that way. AF_USB would probably solve them all however. > But no, I don't actually like sockets all that much myself. They are hard > to use from scripts, and many more people are familiar with open/close and > read/write. Agreed. It would be nice to use open/close/read/write for control and bulk and sockets for interrupt and isochronous. Although I think that's just too complicated. It's probably easier to make everything a socket and deal with it that way. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Tue, May 15, 2001, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Tue, 15 May 2001, James Simmons wrote:
> > >
> > > And if write() has too much overhead - we'd better fix _that_, because
> > > it's much more likely hotspot than ioctl ever will be.
> >
> > I would use write except we use write to draw into the framebuffer. If I
> > write to the framebuffer with that data the only thing that will happen is
> > I will get pretty colors on my screen.
>
> Note that this was the same argument that the USB people had, and it was
> wrong then. It's wrong now.
Hardly pretty and definately not perfect, but that's mostly because we
haven't solved the other problems yet.
> The USB people decided on using ioctl's, because the way USB works you
> send a packet down a "USB pipe", which is identified by the direction, the
> device number and the type (and other details). So what the USB system
> does to expose this to user land is very similar to what you propose for
> ioctl's: a structured ioctl that has a "data" field.
>
> What Al is saying, and what makes perfect sense is that you generate a
> separate fd for each "pipe". It's even more obvious in the case of USB,
> because, by golly, the things are actually _called_ "pipes" in the USB
> documentation, which should have made people make the immediate
> association. Instead of doing
That was not why we did it that way. We used ioctl's because there is no
way to apply USB semantics to file streams.
> fd = open("unstructured-name" ...);
> ioctl(fd, MAGICIOCTL, { structured data });
>
> you do
>
> fd = open("/structured/name", ...);
> write(fd, data, size);
That was the plan, but unfortunately USB pipes aren't what you or I
would consider a pipe normally.
Take isochronous pipe's for instance. How would we apply that to a
normal file stream? Or an interrupt pipe?
Even bulk has issues because USB pipe's aren't necessarily streams, they
can packetized in the psuedo weird way that USB does things.
I'm all for seperating out each endpoint into a seperate file in your
/structured/name way since it's necessary for multi interface devices,
but we still have problems with sharing the default control pipe for
instance.
> or possibly you take a more socket-like approach and do
>
> fd = socket(part-of-the-structure);
> bind(fd, more-of-the-structure)
> connect(fd, last-part-of-the-structure);
I don't like socket's since we do have a well bound set of endpoints. We
don't have 4 billion IP's with 64k ports to choose from. We have x
endpoints that the device tells us about ahead of time.
> and use write() there (or use "sendto()" etc which allow more dynamic
> structure constructs - you don't have to statically bind the fd early at
> bind/connect time.
sendto() is the only reason I can think that socket's would be useful.
bulk pipes are more like a sequenced datagram transport than anything.
However, it still doesn't seem to apply cleanly to the other 3 types of
pipe type's.
Perhaps we can create some new families specifically for USB?
> This, btw, is Al Viro's wet dream. But I have to agree: using name spaces
> etc is MUCH preferable to ioctl's, makes code more readable and logical,
> and often makes it possible to do things you couldn't sanely do before
> (control these things from scripts etc).
I think this is an excellent idea as well. Just USB is poor example
since the real problem with USB is not the naming, it's applying USB
semantics to file streams or sockets.
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Tue, May 15, 2001, Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 15 May 2001, James Simmons wrote:
And if write() has too much overhead - we'd better fix _that_, because
it's much more likely hotspot than ioctl ever will be.
I would use write except we use write to draw into the framebuffer. If I
write to the framebuffer with that data the only thing that will happen is
I will get pretty colors on my screen.
Note that this was the same argument that the USB people had, and it was
wrong then. It's wrong now.
Hardly pretty and definately not perfect, but that's mostly because we
haven't solved the other problems yet.
The USB people decided on using ioctl's, because the way USB works you
send a packet down a USB pipe, which is identified by the direction, the
device number and the type (and other details). So what the USB system
does to expose this to user land is very similar to what you propose for
ioctl's: a structured ioctl that has a data field.
What Al is saying, and what makes perfect sense is that you generate a
separate fd for each pipe. It's even more obvious in the case of USB,
because, by golly, the things are actually _called_ pipes in the USB
documentation, which should have made people make the immediate
association. Instead of doing
That was not why we did it that way. We used ioctl's because there is no
way to apply USB semantics to file streams.
fd = open(unstructured-name ...);
ioctl(fd, MAGICIOCTL, { structured data });
you do
fd = open(/structured/name, ...);
write(fd, data, size);
That was the plan, but unfortunately USB pipes aren't what you or I
would consider a pipe normally.
Take isochronous pipe's for instance. How would we apply that to a
normal file stream? Or an interrupt pipe?
Even bulk has issues because USB pipe's aren't necessarily streams, they
can packetized in the psuedo weird way that USB does things.
I'm all for seperating out each endpoint into a seperate file in your
/structured/name way since it's necessary for multi interface devices,
but we still have problems with sharing the default control pipe for
instance.
or possibly you take a more socket-like approach and do
fd = socket(part-of-the-structure);
bind(fd, more-of-the-structure)
connect(fd, last-part-of-the-structure);
I don't like socket's since we do have a well bound set of endpoints. We
don't have 4 billion IP's with 64k ports to choose from. We have x
endpoints that the device tells us about ahead of time.
and use write() there (or use sendto() etc which allow more dynamic
structure constructs - you don't have to statically bind the fd early at
bind/connect time.
sendto() is the only reason I can think that socket's would be useful.
bulk pipes are more like a sequenced datagram transport than anything.
However, it still doesn't seem to apply cleanly to the other 3 types of
pipe type's.
Perhaps we can create some new families specifically for USB?
This, btw, is Al Viro's wet dream. But I have to agree: using name spaces
etc is MUCH preferable to ioctl's, makes code more readable and logical,
and often makes it possible to do things you couldn't sanely do before
(control these things from scripts etc).
I think this is an excellent idea as well. Just USB is poor example
since the real problem with USB is not the naming, it's applying USB
semantics to file streams or sockets.
JE
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Tue, May 15, 2001, Linus Torvalds [EMAIL PROTECTED] wrote: On Tue, 15 May 2001, Johannes Erdfelt wrote: Even bulk has issues because USB pipe's aren't necessarily streams, they can packetized in the psuedo weird way that USB does things. This is ok. pipe does not mean that the write data doesn't have boundaries. Think about UDP. It's done with file desriptors, yet it is very much packetized. Even a regular pipe actually has packet behaviour: a single write of PIPEBUF is guaranteed by UNIX to complete atomically, which is exactly so that people can use pipes in a packet environment. A file descriptor does NOT imply that the data you read or write must be one mushy stream of bytes. It's ok to honour write() packet boundaries etc. You should absolutely NOT think that we cannot send a packet down the control pipe because multiple writers might confuse each other. You can still require that separate packets be cleanly delimeted. It's a huge mistake to think that you _have_ to use ioctl's to get packet behaviour, or to get structured reads/writes. We never made that assumption. We used ioctl's since it was the easiest and consistent way of solving the problem at the moment. We never said it was the pefect solution :) The advantage of read/write is that it doesn't _force_ a packet on you, but the kernel really doesn't care if you have some structure to your read and write requests. No argument here. I completely agree. The problem with the shared control pipe is not 2 writers stomping on each other, it's permissions. You can have 2 interfaces on one device which are completely seperate from each other and you'd like 2 seperate users/programs to have access to each interface. Each endpoint is guaranteed to be unique to an interface, except for the default control pipe. A simple solution would be to clone the default control pipe for each interface and manage the permissions independantly. The major problem with read/write and USB is that while it can solve the problem for control and bulk pipes, it can't for interrupt and isochronous pipes. or possibly you take a more socket-like approach and do fd = socket(part-of-the-structure); bind(fd, more-of-the-structure) connect(fd, last-part-of-the-structure); I don't like socket's since we do have a well bound set of endpoints. We don't have 4 billion IP's with 64k ports to choose from. We have x endpoints that the device tells us about ahead of time. Note that sockets != IPv4. Sockets just have names, they can be IPv4 (4+2 byte things), they can be pathnames (UNIX domain) and they can be large IPv6 (16+2 or whatever). Or they could be small USB names. There's nothing fundamentally wrong with binding a one-byte address and a one-byte interface name. You'd just create a AF_USB layer ;) I had always made the assumption that sockets were created because you couldn't easily map IPv4 semantics onto filesystems. It's unreasonable to have a file for every possible IP address/port you can communicate with. It's not so unreasonable with USB however since the data set (endpoints) is significantly smaller and manageable. It can be placed in the filesystem namespace without any problems. That being said, we can't solve all of USB's problems that way. AF_USB would probably solve them all however. But no, I don't actually like sockets all that much myself. They are hard to use from scripts, and many more people are familiar with open/close and read/write. Agreed. It would be nice to use open/close/read/write for control and bulk and sockets for interrupt and isochronous. Although I think that's just too complicated. It's probably easier to make everything a socket and deal with it that way. JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
On Tue, May 15, 2001, James Simmons [EMAIL PROTECTED] wrote: Personally, I'd really like to see /dev/ttyS0 be the first detected serial port on a system, /dev/ttyS1 the second, etc. Currently there are plenty of different serial hardware with all their own drivers and /dev entries. For embedded systems with serial consoles, and also across architectures, this is a pain since the filesystem and namely /dev/inittab has to be adjusted for all different types of UARTs. This is not the case for every different type of NICs and that's a good thing. I couldn't agree with you more. It gives me headaches at work. One note, their is a except to the eth0 thing. USB to USB networking. It uses usb0, etc. I personally which they use eth0. USB to USB networking cables aren't ethernet. There are USB to ethernet adapters and they do appear as eth0. JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote: > On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote: > > On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote: > > > > > > That does indeed correct the problem. 2.2.20pre1 now works > > > as expected. > > > > Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does > > 2.4 work on this system? > > The last 2.4 kernel I tried was 2.4.3 I believe and it > worked fine more or less. I haven't tried any later 2.4 > kernels yet. That's fine. The I/O APIC code is different and I tried to make the 2.2 code work like the 2.4 code with minimal changes. However, the changes aren't trivial. I'll take a quick look and see if I can find any more significant differences. I wonder if I have a VIA board laying around here. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote: > On Mon, May 07, 2001 at 11:36:49AM +0100, Alan Cox wrote: > > > Just booted up 2.2.20pre1 and am getting some funny > > > results. The system boots but is very slow. Every few > > > seconds I get: > > > Stuck on TLB IPI wait (CPU#0) > > > > > > Booting vanilla 2.2.19 works fine. The machine is an > > > Intel Pentium III 850MHZ on an Abit VP6 board. If any > > > further information is needed, let me know. > > > > Can you back out the change to io_apic.c and tell me if that fixes it. If so > > let Johannes Erdfelt and I know. > > That does indeed correct the problem. 2.2.20pre1 now works > as expected. Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does 2.4 work on this system? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote: On Mon, May 07, 2001 at 11:36:49AM +0100, Alan Cox wrote: Just booted up 2.2.20pre1 and am getting some funny results. The system boots but is very slow. Every few seconds I get: Stuck on TLB IPI wait (CPU#0) Booting vanilla 2.2.19 works fine. The machine is an Intel Pentium III 850MHZ on an Abit VP6 board. If any further information is needed, let me know. Can you back out the change to io_apic.c and tell me if that fixes it. If so let Johannes Erdfelt and I know. That does indeed correct the problem. 2.2.20pre1 now works as expected. Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does 2.4 work on this system? JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.20pre1: Problems with SMP
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote: On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote: On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote: That does indeed correct the problem. 2.2.20pre1 now works as expected. Hmm, that uses a VIA based chipset. I didn't know they did SMP yet. Does 2.4 work on this system? The last 2.4 kernel I tried was 2.4.3 I believe and it worked fine more or less. I haven't tried any later 2.4 kernels yet. That's fine. The I/O APIC code is different and I tried to make the 2.2 code work like the 2.4 code with minimal changes. However, the changes aren't trivial. I'll take a quick look and see if I can find any more significant differences. I wonder if I have a VIA board laying around here. JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.3ac13
On Tue, Apr 24, 2001, Michael Meissner <[EMAIL PROTECTED]> wrote: > and it doesn't ask whether I want to build the normal USHI USB driver either as > a module or builtin to the kernel, only whether I want to build the alternative > USHI USB dirver (the JE driver). Make xconfig asks whether you want to build > both drivers. I'm not sure whether this was a bug in previous versions or > not. That's probably because you selected the alternative UHCI driver to build into the kernel. In that case, the other UHCI driver is not available as an option anymore. If you select it as a module, then both will be available. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB problems since 2.4.2
On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote: > > > On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote: > > > Kernel: 2.4.2 - latest (2.4.3-ac12) > > > Platform: x86 on mangled Slack7.1 > > > Hardware: MSI 694D Pro-AR > > > ( http://www.msicomputer.com/products/detail.asp?ProductID=150 ) > > > > > > Problem: USB devices timeout on address assignment. Course thats with the > > > non JE driver, with the JE driver the bus doesnt even say that anything > > > gets connected. > > > > > > when any device is plugged in: > > > * > > > hub.c: USB new device connect on bus1/1, assigned device number 4 > > > usb_control/bulk_msg: timeout > > > usb.c: USB device not accepting new address=4 (error=-110) > > > hub.c: USB new device connect on bus1/1, assigned device number 5 > > > usb_control/bulk_msg: timeout > > > usb.c: USB device not accepting new address=5 (error=-110) > > > * > > > > Can you try booting your kernel with the "noapic" option and see if it > > still happens? > > DING DING DING! that did the trick. Thnx! It's less than optimal however. You have an IRQ routing problem with your I/O APIC's it seems. A BIOS upgrade may fix this, but I don't know if it will in your particular case. "noapic" will make things work atleast, but everything will be sent to one CPU (assuming you have more than one CPU :) JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB problems since 2.4.2
On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote: > Kernel: 2.4.2 - latest (2.4.3-ac12) > Platform: x86 on mangled Slack7.1 > Hardware: MSI 694D Pro-AR > ( http://www.msicomputer.com/products/detail.asp?ProductID=150 ) > > Problem: USB devices timeout on address assignment. Course thats with the > non JE driver, with the JE driver the bus doesnt even say that anything > gets connected. > > when any device is plugged in: > * > hub.c: USB new device connect on bus1/1, assigned device number 4 > usb_control/bulk_msg: timeout > usb.c: USB device not accepting new address=4 (error=-110) > hub.c: USB new device connect on bus1/1, assigned device number 5 > usb_control/bulk_msg: timeout > usb.c: USB device not accepting new address=5 (error=-110) > * Can you try booting your kernel with the "noapic" option and see if it still happens? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB problems since 2.4.2
On Mon, Apr 23, 2001, josh [EMAIL PROTECTED] wrote: Kernel: 2.4.2 - latest (2.4.3-ac12) Platform: x86 on mangled Slack7.1 Hardware: MSI 694D Pro-AR ( http://www.msicomputer.com/products/detail.asp?ProductID=150 ) Problem: USB devices timeout on address assignment. Course thats with the non JE driver, with the JE driver the bus doesnt even say that anything gets connected. when any device is plugged in: * hub.c: USB new device connect on bus1/1, assigned device number 4 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=4 (error=-110) hub.c: USB new device connect on bus1/1, assigned device number 5 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=5 (error=-110) * Can you try booting your kernel with the noapic option and see if it still happens? JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB problems since 2.4.2
On Mon, Apr 23, 2001, josh [EMAIL PROTECTED] wrote: On Mon, Apr 23, 2001, josh [EMAIL PROTECTED] wrote: Kernel: 2.4.2 - latest (2.4.3-ac12) Platform: x86 on mangled Slack7.1 Hardware: MSI 694D Pro-AR ( http://www.msicomputer.com/products/detail.asp?ProductID=150 ) Problem: USB devices timeout on address assignment. Course thats with the non JE driver, with the JE driver the bus doesnt even say that anything gets connected. when any device is plugged in: * hub.c: USB new device connect on bus1/1, assigned device number 4 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=4 (error=-110) hub.c: USB new device connect on bus1/1, assigned device number 5 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=5 (error=-110) * Can you try booting your kernel with the noapic option and see if it still happens? DING DING DING! that did the trick. Thnx! It's less than optimal however. You have an IRQ routing problem with your I/O APIC's it seems. A BIOS upgrade may fix this, but I don't know if it will in your particular case. noapic will make things work atleast, but everything will be sent to one CPU (assuming you have more than one CPU :) JE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB with 2.4.3-ac{1,3,7} without devfs-> aic7xxx ?
On Tue, Apr 17, 2001, FAVRE Gregoire <[EMAIL PROTECTED]> wrote: > Thus spake Johannes Erdfelt ([EMAIL PROTECTED]): > > > You should probably bring up things like this on the Linux USB list. > > Well, where is that mailing list? http://www.linux-usb.org > > What does /proc/interrupts show for the 2.4.3-ac7 case? > > Exactly the same as the one from 2.4.3: > CPU0 > 0: 30204 XT-PIC timer > 1:522 XT-PIC keyboard > 2: 0 XT-PIC cascade > 7: 293087 XT-PIC aic7xxx, usb-uhci > 8: 1 XT-PIC rtc > 10:794 XT-PIC eth0, bttv > 11: 47362 XT-PIC saa7146(1) > 12: 2346 XT-PIC PS/2 Mouse > 14: 6615 XT-PIC ide0 > 15: 37 XT-PIC ide1 > NMI: 0 > LOC: 30165 > ERR: 0 > MIS: 0 > > Sorry for the strange looking of my copy and paste to vim... You may want to turn off auto-indent under vim, or you can always just remove the excess spaces by hand. > Maybe the driver don't like IRQ sharing, but I can't change it: aic7xxx > and usb are onboard, and changing the IRQ for aic7xxx change also the > one from usb (P2B-LS mother board). Nope. Both drivers support IRQ sharing just fine. > > s10sh doesn't use anything under /dev, it's all under /proc/bus/usb, > > however, you are having a problem before it gets to s10sh at all. > > So, as my only change in config betweem 2.4.3 and 2.4.3-ac[137] was the > removing of devfs, that's not the problem... Yeah. I don't think there are any changes in the USB code between 2.4.3 and 2.4.3-ac[137]. I'll have to check and see. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB with 2.4.3-ac{1,3,7} without devfs
You should probably bring up things like this on the Linux USB list. On Tue, Apr 17, 2001, FAVRE Gregoire <[EMAIL PROTECTED]> wrote: > Under 2.4.3 I manage uploading photo from my Digital IXUS using USB_UHCI > with s10h, but under ac series, I don't manage, only other things I have > changed is removing devfs which I don't need in fact... [snip] > And as I power on my camera: > > hub.c: USB new device connect on bus1/1, assigned device number 2 > usb_control/bulk_msg: timeout > usb.c: USB device not accepting new address=2 (error=-110) > hub.c: USB new device connect on bus1/1, assigned device number 3 > usb_control/bulk_msg: timeout > usb.c: USB device not accepting new address=3 (error=-110) What does /proc/interrupts show for the 2.4.3-ac7 case? [snip] > I don't think, because under 2.4.3 with devfs, /dev/usb is empty... > > Thanks you in advance for your help, s10sh doesn't use anything under /dev, it's all under /proc/bus/usb, however, you are having a problem before it gets to s10sh at all. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB with 2.4.3-ac{1,3,7} without devfs
You should probably bring up things like this on the Linux USB list. On Tue, Apr 17, 2001, FAVRE Gregoire [EMAIL PROTECTED] wrote: Under 2.4.3 I manage uploading photo from my Digital IXUS using USB_UHCI with s10h, but under ac series, I don't manage, only other things I have changed is removing devfs which I don't need in fact... [snip] And as I power on my camera: hub.c: USB new device connect on bus1/1, assigned device number 2 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=2 (error=-110) hub.c: USB new device connect on bus1/1, assigned device number 3 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=3 (error=-110) What does /proc/interrupts show for the 2.4.3-ac7 case? [snip] I don't think, because under 2.4.3 with devfs, /dev/usb is empty... Thanks you in advance for your help, s10sh doesn't use anything under /dev, it's all under /proc/bus/usb, however, you are having a problem before it gets to s10sh at all. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in uhci.c running 2.4.2-ac28
On Mon, Apr 02, 2001, Jeff Golds <[EMAIL PROTECTED]> wrote: > Let me show what I got with the 2.4.2 kernel with USB support enabled. > > Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad > Mar 19 14:10:31 Eng99 last message repeated 108 times > Mar 19 14:11:37 Eng99 last message repeated 93 times > Mar 19 14:12:39 Eng99 last message repeated 87 times > Mar 19 14:13:40 Eng99 last message repeated 20 times > Mar 19 14:14:45 Eng99 last message repeated 42 times > Mar 19 14:15:46 Eng99 last message repeated 47 times > Mar 19 14:16:47 Eng99 last message repeated 127 times > Mar 19 14:17:50 Eng99 last message repeated 7074 times > Mar 19 14:18:51 Eng99 last message repeated 3342 times > Mar 19 14:19:52 Eng99 last message repeated 10948 times > Mar 19 14:20:00 Eng99 last message repeated 15 > times > > This happens after simply fiddling around with ethernet settings (it's a > PCI ethernet card). In fact, my syslog is FULL of these messages... my > syslog was 3x larger than usual. The console is just about unusable > because of all the spam. > > Something seems terribly wrong with the uhci driver... I've disabled it > on my system and it's fine now (I don't need USB). Do you get the same messages with the usb-uhci driver? > My system: > Slot 1 P3-850 > VIA chipset MB (not sure of exact chipset, can find out if needed) Some of the VIA chipsets have port aliasing problems supposedely. This may cause your controller to go insane like you've described. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in uhci.c running 2.4.2-ac28
On Mon, Apr 02, 2001, Pete Zaitcev <[EMAIL PROTECTED]> wrote: > > Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST) > > From: Ketil Froyn <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > > While running kernel 2.4.2-ac28, I switched on spinlock debugging and > > verbose BUG() reporting (I always use sysrq). Anyway, while running this I > > got an oops after about 2 or 3 minutes running, several times, exact same > > place each time, which I traced back to rh_int_timer_do(). > > This was in uhci.c (I used CONFIG_USB_UHCI_ALT). [...] I > > recompiled with usb-uhci.c instead (CONFIG_USB_UHCI), and now I don't get > > the oops any more. > > I am behind usb-uhci for a reason. Alan bounced your report > to me but I do not see a case for action... What do you mean by "behind". Have you tried the latest patches for uhci.c? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in uhci.c running 2.4.2-ac28
On Mon, Apr 02, 2001, Pete Zaitcev [EMAIL PROTECTED] wrote: Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST) From: Ketil Froyn [EMAIL PROTECTED] To: [EMAIL PROTECTED] While running kernel 2.4.2-ac28, I switched on spinlock debugging and verbose BUG() reporting (I always use sysrq). Anyway, while running this I got an oops after about 2 or 3 minutes running, several times, exact same place each time, which I traced back to rh_int_timer_do(). This was in uhci.c (I used CONFIG_USB_UHCI_ALT). [...] I recompiled with usb-uhci.c instead (CONFIG_USB_UHCI), and now I don't get the oops any more. I am behind usb-uhci for a reason. Alan bounced your report to me but I do not see a case for action... What do you mean by "behind". Have you tried the latest patches for uhci.c? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in uhci.c running 2.4.2-ac28
On Mon, Apr 02, 2001, Jeff Golds [EMAIL PROTECTED] wrote: Let me show what I got with the 2.4.2 kernel with USB support enabled. Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad Mar 19 14:10:31 Eng99 last message repeated 108 times Mar 19 14:11:37 Eng99 last message repeated 93 times Mar 19 14:12:39 Eng99 last message repeated 87 times Mar 19 14:13:40 Eng99 last message repeated 20 times Mar 19 14:14:45 Eng99 last message repeated 42 times Mar 19 14:15:46 Eng99 last message repeated 47 times Mar 19 14:16:47 Eng99 last message repeated 127 times Mar 19 14:17:50 Eng99 last message repeated 7074 times Mar 19 14:18:51 Eng99 last message repeated 3342 times Mar 19 14:19:52 Eng99 last message repeated 10948 times Mar 19 14:20:00 Eng99 last message repeated 15 times This happens after simply fiddling around with ethernet settings (it's a PCI ethernet card). In fact, my syslog is FULL of these messages... my syslog was 3x larger than usual. The console is just about unusable because of all the spam. Something seems terribly wrong with the uhci driver... I've disabled it on my system and it's fine now (I don't need USB). Do you get the same messages with the usb-uhci driver? My system: Slot 1 P3-850 VIA chipset MB (not sure of exact chipset, can find out if needed) Some of the VIA chipsets have port aliasing problems supposedely. This may cause your controller to go insane like you've described. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] [PATCH] USB suspend when no devices attached
On Fri, Mar 16, 2001, Grover, Andrew <[EMAIL PROTECTED]> wrote: > This is a preliminary patch against 2.4.2 to uhci.c that puts the host > controller into global suspend when there are no devices attached. This > conserves power on mobile systems, and because suspending the host > controller ceases UHCI's incessant busmastering activity, it allows the CPU > to enter a deeper idle state. > > The main problem with this implementation is that it just looks at the 2 > root hub ports and suspends if nothing is connected. Ideally, it would be > smart enough to realize it can also suspend when only hubs are present, or > when all devices on the USB are also suspended. I hope a USB expert can add > these enhancements, as it's beyond me. If you want it to be seamless, you really can't do that. USB is a polled bus, so the HC needs to send something to the device so it tells us that something has changed, like a device being plugged into a hub (not the root hub). > You should be able to verify this patch is working in one of two ways: > 1) Turn on USB debug messages, and look for suspend_hc and wakeup_hc > messages > 2) Download the latest ACPI patch from > http://developer.intel.com/technology/iapc/acpi/downloads.htm and verify > that /proc/acpi/processor/0/status shows mostly 0's for busmastering > activity (as opposed to mostly F's) when no USB devices are connected. Thanks for the patch. I'll integrate into my patch and send it off to Linus as well after I run it through it's paces. It looks good on visual inspection atleast. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] [PATCH] USB suspend when no devices attached
On Fri, Mar 16, 2001, Grover, Andrew [EMAIL PROTECTED] wrote: This is a preliminary patch against 2.4.2 to uhci.c that puts the host controller into global suspend when there are no devices attached. This conserves power on mobile systems, and because suspending the host controller ceases UHCI's incessant busmastering activity, it allows the CPU to enter a deeper idle state. The main problem with this implementation is that it just looks at the 2 root hub ports and suspends if nothing is connected. Ideally, it would be smart enough to realize it can also suspend when only hubs are present, or when all devices on the USB are also suspended. I hope a USB expert can add these enhancements, as it's beyond me. If you want it to be seamless, you really can't do that. USB is a polled bus, so the HC needs to send something to the device so it tells us that something has changed, like a device being plugged into a hub (not the root hub). You should be able to verify this patch is working in one of two ways: 1) Turn on USB debug messages, and look for suspend_hc and wakeup_hc messages 2) Download the latest ACPI patch from http://developer.intel.com/technology/iapc/acpi/downloads.htm and verify that /proc/acpi/processor/0/status shows mostly 0's for busmastering activity (as opposed to mostly F's) when no USB devices are connected. Thanks for the patch. I'll integrate into my patch and send it off to Linus as well after I run it through it's paces. It looks good on visual inspection atleast. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.2 and AMD-760MP I/O APIC
The I/O APIC code for 2.2 contains a little trick which sets the destination
to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC
on AMD-760MP systems causing a lockup during boot.
This patch removes that trick in favor of doing what 2.4 does, masking out
the entries.
This patch is relative to 2.2.18, but should apply cleanly to 2.2.19-pre
since -pre17 doesn't touch this code at all.
JE
--- linux-2.2.18.orig/arch/i386/kernel/io_apic.cMon Sep 4 13:39:16 2000
+++ linux-2.2.18/arch/i386/kernel/io_apic.c Thu Mar 15 17:23:46 2001
@@ -200,8 +200,6 @@
* We disable IO-APIC IRQs by setting their 'destination CPU mask' to
* zero. Trick by Ramesh Nalluri.
*/
-DO_ACTION( disable, 1, &= 0x00ff, io_apic_sync(entry->apic))/* destination = 0x00
*/
-DO_ACTION( enable, 1, |= 0xff00, )/* destination
= 0xff */
DO_ACTION( mask,0, |= 0x0001, io_apic_sync(entry->apic))/* mask = 1 */
DO_ACTION( unmask, 0, &= 0xfffe, )/* mask = 0 */
@@ -612,7 +610,7 @@
entry.delivery_mode = dest_LowestPrio;
entry.dest_mode = 1;/* logical delivery */
entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest = 0;/* but no route */
+ entry.dest.logical.logical_dest = 0xff; /* but no route */
idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {
@@ -1017,13 +1015,10 @@
static void enable_edge_ioapic_irq(unsigned int irq)
{
self_IPI(irq);
- enable_IO_APIC_irq(irq);
+ unmask_IO_APIC_irq(irq);
}
-static void disable_edge_ioapic_irq(unsigned int irq)
-{
- disable_IO_APIC_irq(irq);
-}
+static void disable_edge_ioapic_irq(unsigned int irq) { /* nothing */ }
/*
* Starting up a edge-triggered IO-APIC interrupt is
@@ -1239,7 +1234,7 @@
pin1 = find_timer_pin(mp_INT);
pin2 = find_timer_pin(mp_ExtINT);
- enable_IO_APIC_irq(0);
+ unmask_IO_APIC_irq(0);
if (!timer_irq_works()) {
if (pin1 != -1)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.2 and AMD-760MP I/O APIC
The I/O APIC code for 2.2 contains a little trick which sets the destination
to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC
on AMD-760MP systems causing a lockup during boot.
This patch removes that trick in favor of doing what 2.4 does, masking out
the entries.
This patch is relative to 2.2.18, but should apply cleanly to 2.2.19-pre
since -pre17 doesn't touch this code at all.
JE
--- linux-2.2.18.orig/arch/i386/kernel/io_apic.cMon Sep 4 13:39:16 2000
+++ linux-2.2.18/arch/i386/kernel/io_apic.c Thu Mar 15 17:23:46 2001
@@ -200,8 +200,6 @@
* We disable IO-APIC IRQs by setting their 'destination CPU mask' to
* zero. Trick by Ramesh Nalluri.
*/
-DO_ACTION( disable, 1, = 0x00ff, io_apic_sync(entry-apic))/* destination = 0x00
*/
-DO_ACTION( enable, 1, |= 0xff00, )/* destination
= 0xff */
DO_ACTION( mask,0, |= 0x0001, io_apic_sync(entry-apic))/* mask = 1 */
DO_ACTION( unmask, 0, = 0xfffe, )/* mask = 0 */
@@ -612,7 +610,7 @@
entry.delivery_mode = dest_LowestPrio;
entry.dest_mode = 1;/* logical delivery */
entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest = 0;/* but no route */
+ entry.dest.logical.logical_dest = 0xff; /* but no route */
idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {
@@ -1017,13 +1015,10 @@
static void enable_edge_ioapic_irq(unsigned int irq)
{
self_IPI(irq);
- enable_IO_APIC_irq(irq);
+ unmask_IO_APIC_irq(irq);
}
-static void disable_edge_ioapic_irq(unsigned int irq)
-{
- disable_IO_APIC_irq(irq);
-}
+static void disable_edge_ioapic_irq(unsigned int irq) { /* nothing */ }
/*
* Starting up a edge-triggered IO-APIC interrupt is
@@ -1239,7 +1234,7 @@
pin1 = find_timer_pin(mp_INT);
pin2 = find_timer_pin(mp_ExtINT);
- enable_IO_APIC_irq(0);
+ unmask_IO_APIC_irq(0);
if (!timer_irq_works()) {
if (pin1 != -1)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]
On Fri, Mar 09, 2001, David S. Miller <[EMAIL PROTECTED]> wrote: > Manfred Spraul writes: > > Do lots of drivers need the reverse mapping? It wasn't on my todo list > > yet. > > I am against any API which provides this. It can be extremely > expensive to do this on some architectures, and since the rest > of the PCI dma API does not provide such an interface neither > should the pool routines. The API I hacked together for uhci.c didn't have this. > Drivers can keep track of this kind of information themselves, > and that is what I tell every driver author to do who complains > of a lack of a "bus_to_virt()" type thing, it's just lazy > programming. Once I worked around not having a "bus_to_virt()" type thing I was happier with the resulting code. I completely agree. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch [RFC: API]
On Fri, Mar 09, 2001, David S. Miller [EMAIL PROTECTED] wrote: Manfred Spraul writes: Do lots of drivers need the reverse mapping? It wasn't on my todo list yet. I am against any API which provides this. It can be extremely expensive to do this on some architectures, and since the rest of the PCI dma API does not provide such an interface neither should the pool routines. The API I hacked together for uhci.c didn't have this. Drivers can keep track of this kind of information themselves, and that is what I tell every driver author to do who complains of a lack of a "bus_to_virt()" type thing, it's just lazy programming. Once I worked around not having a "bus_to_virt()" type thing I was happier with the resulting code. I completely agree. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] philips rush usb support
On Sat, Feb 24, 2001, Pifko Krisztian <[EMAIL PROTECTED]> wrote: > I've made a patch which adds usb support for the philips > rush mp3 player. The driver is mainly the rio500 driver > only the rush specific parts were modified. > > The patch is against 2.4.2. > > It uses char 180 65 at /dev/usb/rush. > > Userspace stuff should be found at http://openrush.sourceforge.net > if you have a rush. It works for me on ia32 with the model sa125. Why can't the entire driver be in userspace? It appears it uses a completely proprietary protocol and you've created a completely proprietary interface to the kernel. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Proliant hangs with 2.4 but works with 2.2.
On Sun, Feb 18, 2001, lafanga lafanga <[EMAIL PROTECTED]> wrote: > The programs 'gpm', 'kudzu' and 'startx' all hang the server immediately > after they exit (with exit status 0). I cannot pinpoint why the kernel hangs > and would appreciate any help. The only thing I suspect it may be is that it > is a dual processor mobo with only one processor but I don't know how this > detection has changed in the 2.4 kernels. I bet you it has to do with the PS/2 port. Do you have a mouse plugged in? Does the 1600 use a Serverworks chipset? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Proliant hangs with 2.4 but works with 2.2.
On Sun, Feb 18, 2001, lafanga lafanga [EMAIL PROTECTED] wrote: The programs 'gpm', 'kudzu' and 'startx' all hang the server immediately after they exit (with exit status 0). I cannot pinpoint why the kernel hangs and would appreciate any help. The only thing I suspect it may be is that it is a dual processor mobo with only one processor but I don't know how this detection has changed in the 2.4 kernels. I bet you it has to do with the PS/2 port. Do you have a mouse plugged in? Does the 1600 use a Serverworks chipset? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [drizzt.dourden@iname.com: USB mass storage and USB message]
On Thu, Feb 15, 2001, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I'm using the usb-uhci core with the 8200e storage drivers. I don't why > the kernel logs the next message: > > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > (well a lot of them) If it says, uhci.c, then it would be uhci.o. If it says usb-uhci.c, then it's usb-uhci.o. Your statement conflicts with the log you pasted. Which one is it? > The kernel is 2.4.1, the hardware a Celeron 566 with a VIA chipset, with the > next cat /proc/pci > > This doesn't hapeng with the uhci module. > > I was testing the cd writer with cdrecord at x1 speed( well, at least it can > finish th simulation, because with the pre series, it can finished). Did you get an oops? Is the khubd process zombied? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [drizzt.dourden@iname.com: USB mass storage and USB message]
On Thu, Feb 15, 2001, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm using the usb-uhci core with the 8200e storage drivers. I don't why the kernel logs the next message: uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 (well a lot of them) If it says, uhci.c, then it would be uhci.o. If it says usb-uhci.c, then it's usb-uhci.o. Your statement conflicts with the log you pasted. Which one is it? The kernel is 2.4.1, the hardware a Celeron 566 with a VIA chipset, with the next cat /proc/pci This doesn't hapeng with the uhci module. I was testing the cd writer with cdrecord at x1 speed( well, at least it can finish th simulation, because with the pre series, it can finished). Did you get an oops? Is the khubd process zombied? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mucho timeouts on USB
On Fri, Feb 09, 2001, John Cavan <[EMAIL PROTECTED]> wrote: > Just got a D-Link USB radio (R100) and I'm seeing lots of timeouts with > it. I've seen this through the last few 2.4.1+ and -ac+ kernels. > > Current config: > > Dual P3-500 w/ 512mb of RAM > Tyan Tiger 133 mobo with VIA chipset, onboard USB > Kernel 2.4.1-ac9 compiled with egcs-1.1.2 > > The only thing funky is that three devices are sharing an interrupt: > >CPU0 CPU1 > 0: 216690 219652IO-APIC-edge timer > 1: 3564 3816IO-APIC-edge keyboard > 2: 0 0 XT-PIC cascade > 3: 7 20IO-APIC-edge serial > 5: 1017 1135 IO-APIC-level EMU10K1 > 8: 0 1IO-APIC-edge rtc > 11: 22978 22756 IO-APIC-level aic7xxx, eth0, usb-uhci > 12: 64220 63272IO-APIC-edge PS/2 Mouse > 14: 12132 12810IO-APIC-edge ide0 > 15: 3 10IO-APIC-edge ide1 > NMI: 436327 436327 > LOC: 436151 436128 > ERR: 0 > > The ethernet card is a 3Com 3c905, the SCSI card is Adaptec 7892B (19160 > card). No problems with either as far as I can tell, but one of these > modules may not be playing nice with interrupt sharing. > > The messages: > > usb.c: registered new driver usbdevfs > usb.c: registered new driver hub > usb-uhci.c: $Revision: 1.251 $ time 17:33:47 Feb 9 2001 > usb-uhci.c: High bandwidth mode enabled > usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 11 > usb-uhci.c: Detected 2 ports > usb.c: new USB bus registered, assigned bus number 1 > usb_control/bulk_msg: timeout > usb.c: USB device not accepting new address=2 (error=-110) > usb.c: USB device 3 (vend/prod 0x4b4/0x1002) is not claimed by any > active driver. > usb_control/bulk_msg: timeout > usb.c: error getting string descriptor 0 (error=-110) > usb_control/bulk_msg: timeout > usb.c: error getting string descriptor 0 (error=-110) > usb_control/bulk_msg: timeout > usb.c: error getting string descriptor 0 (error=-110) > usb_control/bulk_msg: timeout > usb.c: error getting string descriptor 0 (error=-110) > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout Looks like an IRQ routing problem. We've seen a lot of these and I'm not sure why the current IRQ routing code doesn't work correctly on some systems but works fine on others. Does anyone have any idea why it's not working for him? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Mucho timeouts on USB
On Fri, Feb 09, 2001, John Cavan [EMAIL PROTECTED] wrote: Just got a D-Link USB radio (R100) and I'm seeing lots of timeouts with it. I've seen this through the last few 2.4.1+ and -ac+ kernels. Current config: Dual P3-500 w/ 512mb of RAM Tyan Tiger 133 mobo with VIA chipset, onboard USB Kernel 2.4.1-ac9 compiled with egcs-1.1.2 The only thing funky is that three devices are sharing an interrupt: CPU0 CPU1 0: 216690 219652IO-APIC-edge timer 1: 3564 3816IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3: 7 20IO-APIC-edge serial 5: 1017 1135 IO-APIC-level EMU10K1 8: 0 1IO-APIC-edge rtc 11: 22978 22756 IO-APIC-level aic7xxx, eth0, usb-uhci 12: 64220 63272IO-APIC-edge PS/2 Mouse 14: 12132 12810IO-APIC-edge ide0 15: 3 10IO-APIC-edge ide1 NMI: 436327 436327 LOC: 436151 436128 ERR: 0 The ethernet card is a 3Com 3c905, the SCSI card is Adaptec 7892B (19160 card). No problems with either as far as I can tell, but one of these modules may not be playing nice with interrupt sharing. The messages: usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.251 $ time 17:33:47 Feb 9 2001 usb-uhci.c: High bandwidth mode enabled usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 11 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=2 (error=-110) usb.c: USB device 3 (vend/prod 0x4b4/0x1002) is not claimed by any active driver. usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb.c: error getting string descriptor 0 (error=-110) usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout usb_control/bulk_msg: timeout Looks like an IRQ routing problem. We've seen a lot of these and I'm not sure why the current IRQ routing code doesn't work correctly on some systems but works fine on others. Does anyone have any idea why it's not working for him? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DNS goofups galore...
On Thu, Feb 08, 2001, Michael H. Warfield <[EMAIL PROTECTED]> wrote: > But, wait a minute. CNAME -> CNAME is a "must not". MX -> CNAME > is a "should not". The "should not" leaves it to be implimentation > dependent and not an outright ban. Sooo... Actually, I had this conversation recently. I checked a variety of places and I couldn't find an RFC that said CNAME -> CNAME is a "must not". In fact I found this snippet in rfc1912 which seems to imply that it is legal: Also, having chained records such as CNAMEs pointing to CNAMEs may make administration issues easier, but is known to tickle bugs in some resolvers that fail to check loops correctly. As a result some hosts may not be able to resolve such names. *shrug* JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel memory allocations alignment
On Sun, Feb 04, 2001, Andi Kleen <[EMAIL PROTECTED]> wrote: > "Hen, Shmulik" <[EMAIL PROTECTED]> writes: > > > Actually yes. We were warned that on IA64 architecture the system will halt > > when accessing any type of variable via a pointer if the pointer does not > > contain an aligned address matching that type. Until now we were using a > > That will need to be fixed with a handler anyways, the network stack requires > unaligned accesses. If the IA64 port doesn't handle that it it's buggy and > trivially remotely crashable. That ia64 port now supports unaligned accesses in kernel mode. (via the latest patch) It was more a debugging aid in the beginning than inability to do. > Of course it'll always be much faster to use aligned accesses that do not > need an exception. Absolutely. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel memory allocations alignment
On Sun, Feb 04, 2001, Andi Kleen [EMAIL PROTECTED] wrote: "Hen, Shmulik" [EMAIL PROTECTED] writes: Actually yes. We were warned that on IA64 architecture the system will halt when accessing any type of variable via a pointer if the pointer does not contain an aligned address matching that type. Until now we were using a That will need to be fixed with a handler anyways, the network stack requires unaligned accesses. If the IA64 port doesn't handle that it it's buggy and trivially remotely crashable. That ia64 port now supports unaligned accesses in kernel mode. (via the latest patch) It was more a debugging aid in the beginning than inability to do. Of course it'll always be much faster to use aligned accesses that do not need an exception. Absolutely. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail not dealing with ECN
On Thu, Jan 25, 2001, David S. Miller <[EMAIL PROTECTED]> wrote: > > H. Peter Anvin writes: > > > RFC793, where is lists the unused flag bits as "reserved". > > > That is pretty clear to me. It just has to say that > > > they are reserved, and that is what it does. > > > > > > > Is the definition of "reserved" defined anywhere? In a lot of specs, > > "reserved" means MBZ. > > > > Note, that I'm not arguing with you. I'm trying to pick this apart. > > It says "reserved for future use, must be zero". > > I think the descrepency (and thus what the firewalls are doing) comes > from the ambiguous "must be zero". I cannot fathom the RFC authors > meaning this to be anything other than "must be set to zero by current > implementations" or else what is the purpose of the "reserved for > future use part" right? > > Honestly, is there anyone here who can tell me honestly that when they > see the words "reserved" in the description of a bit field description > (in a hardware programmers manual of some device, for example) that > they think it's ok the read the value and interpret it in any way? > > To me it's always meant "we want to do cool things in the future, > things we haven't thought of now, so don't interpret these bits so we > can do that and you will still work". Generally it's to ensure that all implementations set those bit by default to 0 as well. Then in the future, 0 means "I don't support this feature either by choice or by not implementing it yet". JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: In kernel 2.4.0 in alloc_uhci when doing request_irq()
On Thu, Jan 25, 2001, Thunder from the hill <[EMAIL PROTECTED]> wrote:
> I am using an usual VIA MPV3 onboard USB device (on a AMD K6-II 400
> machine), and it has ever worked fine on Linux (until including
> 2.4.0-test10). Now I wanted to use the "retail" 2.4.0-kernel, and USB
> gets stuck while booting. Last messages are:
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> usb-uhci.c: $Revision: 1.251 $time 07:06:37 Jan 14 2001
> usb-uhci.c: high bandwidth mode enabled
> PCI: Assigned IRQ 10 for device 00:07.2
> usb-uhci.c: USB UHCI at I/O 0xe400, IRQ 10
> usb-uhci.c: Detected 2 ports
> usb.c: new USB bus registered, assigned bus number 1
>
> That's all.
> I debugged a while and noticed that the error occurs beyond
> drivers/usb/usb-uhci.c in the function alloc_uhci() after start_hc (s);
> when calling request_irq(), the line reads:
> if (request_irq (irq, uhci_interrupt, SA_SHIRQ, MODNAME, s)) {
> The called function crashes somewhere on top, as I noticed.
> Is there a patch avariable, or should I do further investigation?
No patches that I've seen. It sounds more like you have an IRQ routing
problem and the IRQ isn't getting acknowledged correctly and is flooding
the machine.
You can try putting a printk in uhci_interrupt to see how often it gets
called.
Also, do you have a PnP setting in your BIOS? Can you try changing it?
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: In kernel 2.4.0 in alloc_uhci when doing request_irq()
On Thu, Jan 25, 2001, Thunder from the hill [EMAIL PROTECTED] wrote:
I am using an usual VIA MPV3 onboard USB device (on a AMD K6-II 400
machine), and it has ever worked fine on Linux (until including
2.4.0-test10). Now I wanted to use the "retail" 2.4.0-kernel, and USB
gets stuck while booting. Last messages are:
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.251 $time 07:06:37 Jan 14 2001
usb-uhci.c: high bandwidth mode enabled
PCI: Assigned IRQ 10 for device 00:07.2
usb-uhci.c: USB UHCI at I/O 0xe400, IRQ 10
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
That's all.
I debugged a while and noticed that the error occurs beyond
drivers/usb/usb-uhci.c in the function alloc_uhci() after start_hc (s);
when calling request_irq(), the line reads:
if (request_irq (irq, uhci_interrupt, SA_SHIRQ, MODNAME, s)) {
The called function crashes somewhere on top, as I noticed.
Is there a patch avariable, or should I do further investigation?
No patches that I've seen. It sounds more like you have an IRQ routing
problem and the IRQ isn't getting acknowledged correctly and is flooding
the machine.
You can try putting a printk in uhci_interrupt to see how often it gets
called.
Also, do you have a PnP setting in your BIOS? Can you try changing it?
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail not dealing with ECN
On Thu, Jan 25, 2001, David S. Miller [EMAIL PROTECTED] wrote: H. Peter Anvin writes: RFC793, where is lists the unused flag bits as "reserved". That is pretty clear to me. It just has to say that they are reserved, and that is what it does. Is the definition of "reserved" defined anywhere? In a lot of specs, "reserved" means MBZ. Note, that I'm not arguing with you. I'm trying to pick this apart. It says "reserved for future use, must be zero". I think the descrepency (and thus what the firewalls are doing) comes from the ambiguous "must be zero". I cannot fathom the RFC authors meaning this to be anything other than "must be set to zero by current implementations" or else what is the purpose of the "reserved for future use part" right? Honestly, is there anyone here who can tell me honestly that when they see the words "reserved" in the description of a bit field description (in a hardware programmers manual of some device, for example) that they think it's ok the read the value and interpret it in any way? To me it's always meant "we want to do cool things in the future, things we haven't thought of now, so don't interpret these bits so we can do that and you will still work". Generally it's to ensure that all implementations set those bit by default to 0 as well. Then in the future, 0 means "I don't support this feature either by choice or by not implementing it yet". JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
On Sat, Jan 20, 2001, Russell King <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt writes: > > They need to be visible via DMA. They need to be 16 byte aligned. We > > also have QH's which have similar requirements, but we don't use as many > > of them. > > Can we get away from the "16 byte aligned" and make it "n byte aligned"? > I believe that slab already has support for this? If you look at the part of the message that I quoted and you cut off, the requirements for UHCI are the data structures MUST be 16 byte aligned. I don't mind if the API is more generalized, but those are the requirements that were asked about in this specific case. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
On Sat, Jan 20, 2001, Russell King [EMAIL PROTECTED] wrote: Johannes Erdfelt writes: They need to be visible via DMA. They need to be 16 byte aligned. We also have QH's which have similar requirements, but we don't use as many of them. Can we get away from the "16 byte aligned" and make it "n byte aligned"? I believe that slab already has support for this? If you look at the part of the message that I quoted and you cut off, the requirements for UHCI are the data structures MUST be 16 byte aligned. I don't mind if the API is more generalized, but those are the requirements that were asked about in this specific case. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
On Sat, Jan 20, 2001, Manfred Spraul <[EMAIL PROTECTED]> wrote: > > > > TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I > > haven't checked recently). That's a waste of space for an entire page. > > > > However, having every driver implement it's own slab cache seems a > > complete waste of time when we already have the code to do so in > > mm/slab.c. It would be nice if we could extend the generic slab code to > > understand the PCI DMA API for us. > > > I missed the beginning of the thread: > > What are the exact requirements for TD's? > I have 3 tiny updates for mm/slab.c that I'll send to Linus as soon as > 2.4 has stabilized a bit more, perhaps I can integrate the code for USB. They need to be visible via DMA. They need to be 16 byte aligned. We also have QH's which have similar requirements, but we don't use as many of them. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
On Sat, Jan 20, 2001, Russell King <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt writes: > > On Fri, Jan 19, 2001, Miles Lane <[EMAIL PROTECTED]> wrote: > > > Johannes Erdfelt wrote: > > > > > > > TODO > > > > > > > > - The PCI DMA architecture is horribly inefficient on x86 and ia64. The > > > > result is a page is allocated for each TD. This is evil. Perhaps a slab > > > > cache internally? Or modify the generic slab cache to handle PCI DMA > > > > pages instead? > > > > > > This might be the kind of thing to run past Linus when the 2.5 tree > > > opens up. Are these inefficiencies necessary evils due to workarounds > > > for whacky bugs in BIOSen or PCI chipsets or are they due to poor > > > design/implementation? > > > > Looks like poor design/implementation. Or perhaps it was designed for > > another reason than I want to use it for. > > Why? What are you trying to do? Allocate one area per small structure? > Why not allocate one big area and allocate from that (like the tulip > drivers do for their TX and RX rings)? > > I don't really know what you're trying to do/what the problem is because > there isn't enough context left in the original mail above, and I have > no idea whether the original mail appeared here or where I can read it. I was hoping the context from the original TODO up there was sufficient and it looked like it was enough. TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I haven't checked recently). That's a waste of space for an entire page. However, having every driver implement it's own slab cache seems a complete waste of time when we already have the code to do so in mm/slab.c. It would be nice if we could extend the generic slab code to understand the PCI DMA API for us. > > I should also check architectures other than x86 and ia64. > > This is an absolute must. Not really. The 2 interesting architectures are x86 and ia64 since that's where you commonly see UHCI controllers. While you can add UHCI controllers to most any other architecture which has PCI, you usually see OHCI on those systems. I was curious to see if any other architectures implemented it differently and I was just expecting too much out of the API. You pretty much confirmed my suspicions when you suggested doing what the tulip driver does. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
On Sat, Jan 20, 2001, Russell King [EMAIL PROTECTED] wrote: Johannes Erdfelt writes: On Fri, Jan 19, 2001, Miles Lane [EMAIL PROTECTED] wrote: Johannes Erdfelt wrote: TODO - The PCI DMA architecture is horribly inefficient on x86 and ia64. The result is a page is allocated for each TD. This is evil. Perhaps a slab cache internally? Or modify the generic slab cache to handle PCI DMA pages instead? This might be the kind of thing to run past Linus when the 2.5 tree opens up. Are these inefficiencies necessary evils due to workarounds for whacky bugs in BIOSen or PCI chipsets or are they due to poor design/implementation? Looks like poor design/implementation. Or perhaps it was designed for another reason than I want to use it for. Why? What are you trying to do? Allocate one area per small structure? Why not allocate one big area and allocate from that (like the tulip drivers do for their TX and RX rings)? I don't really know what you're trying to do/what the problem is because there isn't enough context left in the original mail above, and I have no idea whether the original mail appeared here or where I can read it. I was hoping the context from the original TODO up there was sufficient and it looked like it was enough. TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I haven't checked recently). That's a waste of space for an entire page. However, having every driver implement it's own slab cache seems a complete waste of time when we already have the code to do so in mm/slab.c. It would be nice if we could extend the generic slab code to understand the PCI DMA API for us. I should also check architectures other than x86 and ia64. This is an absolute must. Not really. The 2 interesting architectures are x86 and ia64 since that's where you commonly see UHCI controllers. While you can add UHCI controllers to most any other architecture which has PCI, you usually see OHCI on those systems. I was curious to see if any other architectures implemented it differently and I was just expecting too much out of the API. You pretty much confirmed my suspicions when you suggested doing what the tulip driver does. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
On Sat, Jan 20, 2001, Manfred Spraul [EMAIL PROTECTED] wrote: TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I haven't checked recently). That's a waste of space for an entire page. However, having every driver implement it's own slab cache seems a complete waste of time when we already have the code to do so in mm/slab.c. It would be nice if we could extend the generic slab code to understand the PCI DMA API for us. I missed the beginning of the thread: What are the exact requirements for TD's? I have 3 tiny updates for mm/slab.c that I'll send to Linus as soon as 2.4 has stabilized a bit more, perhaps I can integrate the code for USB. They need to be visible via DMA. They need to be 16 byte aligned. We also have QH's which have similar requirements, but we don't use as many of them. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
On Fri, Jan 19, 2001, Miles Lane <[EMAIL PROTECTED]> wrote: > Johannes Erdfelt wrote: > > > TODO > > > > - The PCI DMA architecture is horribly inefficient on x86 and ia64. The > > result is a page is allocated for each TD. This is evil. Perhaps a slab > > cache internally? Or modify the generic slab cache to handle PCI DMA > > pages instead? > > This might be the kind of thing to run past Linus when the 2.5 tree > opens up. Are these inefficiencies necessary evils due to workarounds > for whacky bugs in BIOSen or PCI chipsets or are they due to poor > design/implementation? Looks like poor design/implementation. Or perhaps it was designed for another reason than I want to use it for. 2.5 is probably where any core changes will happen, if any. But for now I suspect I'll need to workaround it in my driver. I should also check architectures other than x86 and ia64. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
On Fri, Jan 19, 2001, Miles Lane [EMAIL PROTECTED] wrote: Johannes Erdfelt wrote: TODO - The PCI DMA architecture is horribly inefficient on x86 and ia64. The result is a page is allocated for each TD. This is evil. Perhaps a slab cache internally? Or modify the generic slab cache to handle PCI DMA pages instead? This might be the kind of thing to run past Linus when the 2.5 tree opens up. Are these inefficiencies necessary evils due to workarounds for whacky bugs in BIOSen or PCI chipsets or are they due to poor design/implementation? Looks like poor design/implementation. Or perhaps it was designed for another reason than I want to use it for. 2.5 is probably where any core changes will happen, if any. But for now I suspect I'll need to workaround it in my driver. I should also check architectures other than x86 and ia64. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB broken in 2.4.0
On Sat, Jan 06, 2001, antirez <[EMAIL PROTECTED]> wrote: > On Fri, Jan 05, 2001 at 04:48:00PM -0800, Dunlap, Randy wrote: > > This rings a small bell with me. > > There was a change by Dan Streetman IIRC to limit > > usbdevfs bulk transfers to PAGE_SIZE (4 KB for x86, > > or 0x1000). Anything larger than that returns > > an error (-EINVAL). > > Yes, devio.c, proc_bulk(): > > if (len1 > PAGE_SIZE) > return -EINVAL; > > Actually it is the max transfer size I can reach. > I guess that to limit the page size can be an impementation > advantage but it may slow-down a bit some userspace driver. > I feel that even if the linux way is to implement the USB > drivers in kernel space a full-featured USB user space access > should be allowed. This is the responsibility of the user space access. Using 4k reads versus 8k reads won't increase performance (noticably), or will it function any more correctly. The next version of libusb will split up reads correctly so applications using the library don't need to worry about this. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB broken in 2.4.0
On Sat, Jan 06, 2001, antirez [EMAIL PROTECTED] wrote: On Fri, Jan 05, 2001 at 04:48:00PM -0800, Dunlap, Randy wrote: This rings a small bell with me. There was a change by Dan Streetman IIRC to limit usbdevfs bulk transfers to PAGE_SIZE (4 KB for x86, or 0x1000). Anything larger than that returns an error (-EINVAL). Yes, devio.c, proc_bulk(): if (len1 PAGE_SIZE) return -EINVAL; Actually it is the max transfer size I can reach. I guess that to limit the page size can be an impementation advantage but it may slow-down a bit some userspace driver. I feel that even if the linux way is to implement the USB drivers in kernel space a full-featured USB user space access should be allowed. This is the responsibility of the user space access. Using 4k reads versus 8k reads won't increase performance (noticably), or will it function any more correctly. The next version of libusb will split up reads correctly so applications using the library don't need to worry about this. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: make menuconfig: where's USB Mass Storage?
On Fri, Jan 05, 2001, Keith Owens <[EMAIL PROTECTED]> wrote: > On Fri, 5 Jan 2001 02:42:11 -0200, > Fr d ric L . W . Meunier <[EMAIL PROTECTED]> wrote: > >Is this just me? Configuring 2.4.0 with make menuconfig with > >CONFIG_EXPERIMENTAL=y I get no prompt for USB Mass Storage, > >but the .config is saved with # CONFIG_USB_STORAGE is not set > > CONFIG_USB_STORAGE is only available if you have both USB and SCSI > selected. Is that the correct combination? I have no idea, but that > is what is coded. Yup, obviously USB is required, but USB storage devices are all SCSI (atleast the class devices are), so we need the SCSI layer as well. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: make menuconfig: where's USB Mass Storage?
On Fri, Jan 05, 2001, Keith Owens [EMAIL PROTECTED] wrote: On Fri, 5 Jan 2001 02:42:11 -0200, Fr d ric L . W . Meunier [EMAIL PROTECTED] wrote: Is this just me? Configuring 2.4.0 with make menuconfig with CONFIG_EXPERIMENTAL=y I get no prompt for USB Mass Storage, but the .config is saved with # CONFIG_USB_STORAGE is not set CONFIG_USB_STORAGE is only available if you have both USB and SCSI selected. Is that the correct combination? I have no idea, but that is what is coded. Yup, obviously USB is required, but USB storage devices are all SCSI (atleast the class devices are), so we need the SCSI layer as well. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: usb broken in 2.4.0 prerelease versus 2.2.18
On Mon, Jan 01, 2001, Heitzso <[EMAIL PROTECTED]> wrote: > Johannes, I apologize for not getting back to you earlier. > Holidays, a changing kernel, and work, kept me away from > the test. No problem. > DATA: s10sh 0.1.9 is a program used to access the USB > bus to get to digital cameras and download pictures, etc. > I used it for quite awhile with 2.4.0 test up until > test 10(?) or so when it broke. I then switched over to > 2.2.18 where s10sh works fine. With the 2.4.0 > prerelease out I compiled the 2.4.0 prerelease kernel > and tested and the 2.4.0 prerelease kernel still breaks > s10sh though the same s10sh program works fine with 2.2.18. > > I cannot say that 2.4.0 is broken because I don't know > if it is expected for a program like s10sh to break over > the kernel shift. What was odd for me was that is worked > fine for quite awhile with 2.4.0 then snapped. Technically, 2.4.0 is the newer code and the 2.2.18 code is a backport of the 2.4.0 code. There isn't significant amounts of difference between them, but the 2.2.18 code is slightly out of date. > DEFINITION of SNAPPED: s10sh provides a command GETALL > to download all of the pictures in a camera's 'directory'. > Running GETALL under 2.4.0 now has the first picture file > being somewhat reasonably sized, the second being roughly > 200M in size, then the next being almost a gig in size, > etc. until the parition I was in filled up and everything > stops. I then rebooted to 2.2.18 and the same program > downloaded the pictures just fine. > > If someone wants my .config files for 2.2.18 and 2.4.0 > let me know with instructions for getting it to you > (i.e. attachments versus ...) Sounds like something got corrupted or expecting the wrong size bulk transfers. Could you give me your .config's? Attachment is fine (just don't send them to the list). JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: usb broken in 2.4.0 prerelease versus 2.2.18
On Mon, Jan 01, 2001, Heitzso [EMAIL PROTECTED] wrote: Johannes, I apologize for not getting back to you earlier. Holidays, a changing kernel, and work, kept me away from the test. No problem. DATA: s10sh 0.1.9 is a program used to access the USB bus to get to digital cameras and download pictures, etc. I used it for quite awhile with 2.4.0 test up until test 10(?) or so when it broke. I then switched over to 2.2.18 where s10sh works fine. With the 2.4.0 prerelease out I compiled the 2.4.0 prerelease kernel and tested and the 2.4.0 prerelease kernel still breaks s10sh though the same s10sh program works fine with 2.2.18. I cannot say that 2.4.0 is broken because I don't know if it is expected for a program like s10sh to break over the kernel shift. What was odd for me was that is worked fine for quite awhile with 2.4.0 then snapped. Technically, 2.4.0 is the newer code and the 2.2.18 code is a backport of the 2.4.0 code. There isn't significant amounts of difference between them, but the 2.2.18 code is slightly out of date. DEFINITION of SNAPPED: s10sh provides a command GETALL to download all of the pictures in a camera's 'directory'. Running GETALL under 2.4.0 now has the first picture file being somewhat reasonably sized, the second being roughly 200M in size, then the next being almost a gig in size, etc. until the parition I was in filled up and everything stops. I then rebooted to 2.2.18 and the same program downloaded the pictures just fine. If someone wants my .config files for 2.2.18 and 2.4.0 let me know with instructions for getting it to you (i.e. attachments versus ...) Sounds like something got corrupted or expecting the wrong size bulk transfers. Could you give me your .config's? Attachment is fine (just don't send them to the list). JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: usb broken in 2.4.0 test 12 versus 2.2.18
On Mon, Dec 18, 2000, Heitzso <[EMAIL PROTECTED]> wrote: > I have a Canon usb camera that I access via a > recent copy of the s10sh program (with -u option). > > Getting to the camera via s10sh -u worked through > large sections of 2.4.0 test X but broke recently. > I cannot say for certain which test/patch the > break occurred in. > > Running 2.4.0 test12 malloc errors appear. > Everything is fine with 2.2.18. I haven't tried > the test13 series of patches. > > key .config options: > CONFIG_USB on > DEVICEFS on > HOTPLUG on > UHCI on > everything else off (i.e. printers, keyboards, > mice, etc.). > > Baseline system is RH6.2 with most patches applied > (so avoiding RH7 compiler problems). Basic dev > environment is same (i.e. compiling the two kernels > on the same box). > > If someone wants to email me a debug sequence or > ask more specific questions feel free. Could you give us the exact error message you saw? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: usb broken in 2.4.0 test 12 versus 2.2.18
On Mon, Dec 18, 2000, Heitzso [EMAIL PROTECTED] wrote: I have a Canon usb camera that I access via a recent copy of the s10sh program (with -u option). Getting to the camera via s10sh -u worked through large sections of 2.4.0 test X but broke recently. I cannot say for certain which test/patch the break occurred in. Running 2.4.0 test12 malloc errors appear. Everything is fine with 2.2.18. I haven't tried the test13 series of patches. key .config options: CONFIG_USB on DEVICEFS on HOTPLUG on UHCI on everything else off (i.e. printers, keyboards, mice, etc.). Baseline system is RH6.2 with most patches applied (so avoiding RH7 compiler problems). Basic dev environment is same (i.e. compiling the two kernels on the same box). If someone wants to email me a debug sequence or ask more specific questions feel free. Could you give us the exact error message you saw? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] PROBLEM: USB (MS Intellimouse specifically) does not work with SMP Linux 2.2.18.
On Tue, Dec 12, 2000, Laramie Leavitt <[EMAIL PROTECTED]> wrote: > [1.] One line summary of the problem: > USB (MS Intellimouse specifically) does not work with SMP kernel 2.2.18. > > [2.] Full description of the problem/report: > When trying to install a Microsoft Intellimouse Explorer (USB) > to a SMP kernel, I get the following error multiple times: > > usb.c: USB device not accepting new address (error=-110) > > If USB is compiled in, then it happens several times during the > boot sequence. > > Everything works fine on a single-processor kernel. I have tried > installing all of USB as modules, and I have tried compiling it > into the kernel with no change. > > System is a MSI 694D-Pro AR motherboard (Via 694X chipset) > Dual 500 Mhz Celeron processors, 500 Mhz (Not overclocked) > Microsoft Intellimouse explorer. > > I suspect that it is an issue where locking is required, > but none currently exists, either in mousedev, usb, or > uhci. (Great logic--those are the main modules that should > be in use.) I suspect that the problem can be duplicated > on my system under Linux 2.4.0-test11, but, alas, I cannot > get linux 2.4 to boot right now. > > I don't see the hid module in the status output like I do on > the uni-processor kernel. Maybe those structures need locks. Unlikely. Many people use that particular mouse with your particular HCD in SMP every day. Like myself. In fact I am right now, using 2.2.18. What is more likely the cause is an IRQ routing problem. Can you check /proc/interrupts and see if the interrupt count is going up? Also, can you check your BIOS and see if it is configured for MPS 1.4? If so, change it to MPS 1.1. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] PROBLEM: USB (MS Intellimouse specifically) does not work with SMP Linux 2.2.18.
On Tue, Dec 12, 2000, Laramie Leavitt [EMAIL PROTECTED] wrote: [1.] One line summary of the problem: USB (MS Intellimouse specifically) does not work with SMP kernel 2.2.18. [2.] Full description of the problem/report: When trying to install a Microsoft Intellimouse Explorer (USB) to a SMP kernel, I get the following error multiple times: usb.c: USB device not accepting new address (error=-110) If USB is compiled in, then it happens several times during the boot sequence. Everything works fine on a single-processor kernel. I have tried installing all of USB as modules, and I have tried compiling it into the kernel with no change. System is a MSI 694D-Pro AR motherboard (Via 694X chipset) Dual 500 Mhz Celeron processors, 500 Mhz (Not overclocked) Microsoft Intellimouse explorer. I suspect that it is an issue where locking is required, but none currently exists, either in mousedev, usb, or uhci. (Great logic--those are the main modules that should be in use.) I suspect that the problem can be duplicated on my system under Linux 2.4.0-test11, but, alas, I cannot get linux 2.4 to boot right now. I don't see the hid module in the status output like I do on the uni-processor kernel. Maybe those structures need locks. Unlikely. Many people use that particular mouse with your particular HCD in SMP every day. Like myself. In fact I am right now, using 2.2.18. What is more likely the cause is an IRQ routing problem. Can you check /proc/interrupts and see if the interrupt count is going up? Also, can you check your BIOS and see if it is configured for MPS 1.4? If so, change it to MPS 1.1. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB-related lockup in test12-pre5
On Fri, Dec 08, 2000, Johannes Erdfelt <[EMAIL PROTECTED]> wrote: > On Fri, Dec 08, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote: > > On Thu, 7 Dec 2000, Johannes Erdfelt wrote: > > > > > Could you try the alternate UHCI driver? You may need to disable the > > > UHCI driver you have configured for the option to become visible. > > > > Differently broken: > > uhci: host controller process error. something bad happened > > uhci: host controller halted. very bad > > > > ... but at least the machine doesn't die. This was working in test11, > > IIRC. Certainly in test10. > > I'm sure you can guess from the messages that we have a problem. > > However, I haven't seen that error in a long time. Lemme go back and > look in the docs to see if I can get some more information as to why > that would actually happen. Actually, looking back at your previous email, enabling bus mastering may make this error go away. Could you give -pre7 a try? Or have you already? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB-related lockup in test12-pre5
On Fri, Dec 08, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote: > On Thu, 7 Dec 2000, Johannes Erdfelt wrote: > > > Could you try the alternate UHCI driver? You may need to disable the > > UHCI driver you have configured for the option to become visible. > > Differently broken: > uhci: host controller process error. something bad happened > uhci: host controller halted. very bad > > ... but at least the machine doesn't die. This was working in test11, > IIRC. Certainly in test10. I'm sure you can guess from the messages that we have a problem. However, I haven't seen that error in a long time. Lemme go back and look in the docs to see if I can get some more information as to why that would actually happen. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB-related lockup in test12-pre5
On Fri, Dec 08, 2000, David Woodhouse [EMAIL PROTECTED] wrote: On Thu, 7 Dec 2000, Johannes Erdfelt wrote: Could you try the alternate UHCI driver? You may need to disable the UHCI driver you have configured for the option to become visible. Differently broken: uhci: host controller process error. something bad happened uhci: host controller halted. very bad ... but at least the machine doesn't die. This was working in test11, IIRC. Certainly in test10. I'm sure you can guess from the messages that we have a problem. However, I haven't seen that error in a long time. Lemme go back and look in the docs to see if I can get some more information as to why that would actually happen. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB-related lockup in test12-pre5
On Fri, Dec 08, 2000, Johannes Erdfelt [EMAIL PROTECTED] wrote: On Fri, Dec 08, 2000, David Woodhouse [EMAIL PROTECTED] wrote: On Thu, 7 Dec 2000, Johannes Erdfelt wrote: Could you try the alternate UHCI driver? You may need to disable the UHCI driver you have configured for the option to become visible. Differently broken: uhci: host controller process error. something bad happened uhci: host controller halted. very bad ... but at least the machine doesn't die. This was working in test11, IIRC. Certainly in test10. I'm sure you can guess from the messages that we have a problem. However, I haven't seen that error in a long time. Lemme go back and look in the docs to see if I can get some more information as to why that would actually happen. Actually, looking back at your previous email, enabling bus mastering may make this error go away. Could you give -pre7 a try? Or have you already? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB-related lockup in test12-pre5
On Thu, Dec 07, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote: > Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make > this magically go away? I doubt it. Probably not. Enabling bus mastering is the difference between USB working at all (transfering data to the device) and not working. > This happened when trying to run excel under wine. Dual Celeron with > CONFIG_USB_UHCI. Could you try the alternate UHCI driver? You may need to disable the UHCI driver you have configured for the option to become visible. > >>EIP; c0270c21<= > Trace; c01f488e > Trace; ca8578be <[audio]usbout_completed+7e/c0> > Trace; c01ffc3e > Trace; c01ffd49 It looks like you were using USB audio? Could you explain what you were doing when the oops happened? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB-related lockup in test12-pre5
On Thu, Dec 07, 2000, David Woodhouse [EMAIL PROTECTED] wrote: Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make this magically go away? I doubt it. Probably not. Enabling bus mastering is the difference between USB working at all (transfering data to the device) and not working. This happened when trying to run excel under wine. Dual Celeron with CONFIG_USB_UHCI. Could you try the alternate UHCI driver? You may need to disable the UHCI driver you have configured for the option to become visible. EIP; c0270c21 stext_lock+4e6d/8f50 = Trace; c01f488e usb_submit_urb+1e/30 Trace; ca8578be [audio]usbout_completed+7e/c0 Trace; c01ffc3e process_urb+1de/230 Trace; c01ffd49 uhci_interrupt+b9/120 It looks like you were using USB audio? Could you explain what you were doing when the oops happened? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre6
On Wed, Dec 06, 2000, Miles Lane <[EMAIL PROTECTED]> wrote:
> Hmm. Your patch doesn't test whether pci_enable_device(dev)
> was successful, does it?
Umm, it does. If pci_enable_device wasn't successful, it returns -ENODEV.
Your patch below calls pci_set_master if enabling the device fails and
then ignores the device.
Is that what you meant?
JE
> I think what you want is:
>
> diff -u --new-file drivers/usb/uhci.c~ drivers/usb/uhci.c
> --- drivers/usb/uhci.c~ Tue Dec 5 23:55:38 2000
> +++ drivers/usb/uhci.cWed Dec 6 14:50:00 2000
> @@ -2380,8 +2380,10 @@
> /* disable legacy emulation */
> pci_write_config_word(dev, USBLEGSUP, 0);
>
> -
> if (pci_enable_device(dev) < 0)
> +
> if (pci_enable_device(dev) < 0) {
> +
> pci_set_master(dev);
> return -ENODEV;
> +
> }
>
> if (!dev->irq) {
> err("found UHCI device with no IRQ assigned. check BIOS settings!");
> diff -u --new-file drivers/usb/usb-uhci.c~ drivers/usb/usb-uhci.c
> --- drivers/usb/usb-uhci.c~ Tue Dec 5 23:55:38 2000
> +++ drivers/usb/usb-uhci.cWed Dec 6 14:50:09 2000
> @@ -2939,8 +2939,10 @@
> {
> int i;
>
> -
> if (pci_enable_device(dev) < 0)
> +
> if (pci_enable_device(dev) < 0) {
> +
> pci_set_master(dev);
> return -ENODEV;
> +
> }
>
> /* Search for the IO base address.. */
> for (i = 0; i < 6; i++) {
> diff -u --new-file drivers/usb/usb-ohci.c# drivers/usb/usb-ohci.c
> --- drivers/usb/usb-ohci.c# Wed Dec 6 14:56:12 2000
> +++ drivers/usb/usb-ohci.cWed Dec 6 14:49:34 2000
> @@ -2320,8 +2320,10 @@
> unsigned long mem_resource, mem_len;
> void *mem_base;
>
> -
> if (pci_enable_device(dev) < 0)
> +
> if (pci_enable_device(dev) < 0) {
> +
> pci_set_master(dev);
> return -ENODEV;
> +
> }
>
> /* we read its hardware registers as memory */
> mem_resource = pci_resource_start(dev, 0);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test12-pre6
On Wed, Dec 06, 2000, Miles Lane [EMAIL PROTECTED] wrote:
Hmm. Your patch doesn't test whether pci_enable_device(dev)
was successful, does it?
Umm, it does. If pci_enable_device wasn't successful, it returns -ENODEV.
Your patch below calls pci_set_master if enabling the device fails and
then ignores the device.
Is that what you meant?
JE
I think what you want is:
diff -u --new-file drivers/usb/uhci.c~ drivers/usb/uhci.c
--- drivers/usb/uhci.c~ Tue Dec 5 23:55:38 2000
+++ drivers/usb/uhci.cWed Dec 6 14:50:00 2000
@@ -2380,8 +2380,10 @@
/* disable legacy emulation */
pci_write_config_word(dev, USBLEGSUP, 0);
-
if (pci_enable_device(dev) 0)
+
if (pci_enable_device(dev) 0) {
+
pci_set_master(dev);
return -ENODEV;
+
}
if (!dev-irq) {
err("found UHCI device with no IRQ assigned. check BIOS settings!");
diff -u --new-file drivers/usb/usb-uhci.c~ drivers/usb/usb-uhci.c
--- drivers/usb/usb-uhci.c~ Tue Dec 5 23:55:38 2000
+++ drivers/usb/usb-uhci.cWed Dec 6 14:50:09 2000
@@ -2939,8 +2939,10 @@
{
int i;
-
if (pci_enable_device(dev) 0)
+
if (pci_enable_device(dev) 0) {
+
pci_set_master(dev);
return -ENODEV;
+
}
/* Search for the IO base address.. */
for (i = 0; i 6; i++) {
diff -u --new-file drivers/usb/usb-ohci.c# drivers/usb/usb-ohci.c
--- drivers/usb/usb-ohci.c# Wed Dec 6 14:56:12 2000
+++ drivers/usb/usb-ohci.cWed Dec 6 14:49:34 2000
@@ -2320,8 +2320,10 @@
unsigned long mem_resource, mem_len;
void *mem_base;
-
if (pci_enable_device(dev) 0)
+
if (pci_enable_device(dev) 0) {
+
pci_set_master(dev);
return -ENODEV;
+
}
/* we read its hardware registers as memory */
mem_resource = pci_resource_start(dev, 0);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
