On Fri, 27 Jul 2007, Alan Stern wrote:
>
> I don't think it's a refcounting problem. My guess is that the
> underlying cause is the bug in your urb->status removal patch for
> usb_start_wait_urb() -- the one I fixed here:
>
> http://marc.info/?l=linux-usb-devel&m=118531582013355&w=2
>
> Of
On Thu, 19 Jul 2007, Greg KH wrote:
>
> Here are some more USB patches and fixes against your 2.6.22 git tree.
>
> They add a new usb gadget driver, more urb->status cleanups, a new sysfs
> attribute to get the raw config of the usb device, and some bugfixes and
> documentation updates.
I have
On Thu, 12 Jul 2007, Greg KH wrote:
>
> Here are a bunch of USB patches and fixes against your 2.6.22 git tree.
This also seems to contain some *totally*pointless* config variable
changes, that actually break simple things like "make oldconfig".
This commit is insane: acb11c8b8020f1f1b254515202
On Wed, 13 Jun 2007, Michal Piotrowski wrote:
>
> Subject: hibernate(?) fails totally - regression
> References : http://lkml.org/lkml/2007/6/1/401
> Submitter : David Greaves <[EMAIL PROTECTED]>
> Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]>
> Caused-By : Tejun Heo <[EMAIL PROTECTED
On Fri, 25 May 2007, Andrew Morton wrote:
>
> > > There is an additional factor - dumps contain data which variously is -
> > > copyright third parties, protected by privacy laws, just personally
> > > private, security sensitive (eg browser history) and so on.
> >
> > Yes.
>
> We're uninteres
On Fri, 25 May 2007, Chuck Ebbert wrote:
>
> Windows can dump memory to the swap file on crash. Default is a "minidump"
> IIRC but you can set it to dump all memory (or none.)
And Linux can too.
And exactly as with Windows, nobody should ever use it. It's a *developer*
thing. It's not a user
On Fri, 25 May 2007, Alan Cox wrote:
>
> There is an additional factor - dumps contain data which variously is -
> copyright third parties, protected by privacy laws, just personally
> private, security sensitive (eg browser history) and so on.
Yes.
I'm sure we've had one or two crashdumps ov
On Fri, 25 May 2007, Chris Newport wrote:
>
> Maybe we should take a hint from Solaris.
No. Solaris is shit. They make their decisions based on "we control the
hardware" kind of setup.
> If the kernel crashes Solaris dumps core to swap and sets a flag.
> At the next boot this image is copied t
On Fri, 25 May 2007, Stefan Richter wrote:
> Ingo Molnar wrote:
> > i was adding WARN_ON()s that werent true 'warnings' but 'bugs'.
>
> IME, the trace dump in the kernel log looks scary enough to be
> eventually reported, even if prefixed with "WARNING:".
Oh, absolutely. It will stand out like
On Thu, 24 May 2007, Ingo Molnar wrote:
>
> i very much agree that this kmalloc_index() one shouldnt be called a
> "BUG: ", but if you look at the majority of WARN_ON() instances they are
> checks for clear, serious kernel bugs.
I _still_ disagree.
There's a huge difference between "You kill
On Thu, 24 May 2007, Andrew Morton wrote:
> On Thu, 24 May 2007 10:12:14 -0700 (PDT)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > > BUG: at include/linux/slub_def.h:88 kmalloc_index()
> >
> > I'm going to change that "BUG:" to "W
On Thu, 24 May 2007, Christoph Lameter wrote:
>
> On Thu, 24 May 2007, Michal Piotrowski wrote:
>
> > Memory management
> >
> > Subject: kernel BUG at include/linux/slub_def.h:88 kmalloc_index()
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=8476
> > Submitter : Cherwin R. Noo
On Fri, 27 Apr 2007, Greg KH wrote:
>
> Ugh, I just realized that this mite break people using 'git bisect' and
> diving down into this usb branch. If you want, I can just redo this
> whole tree after you pull the driver patches so this doesn't happen.
Let's do that. I pushed out my pull of th
On Fri, 9 Mar 2007, Ingo Molnar wrote:
> > Some day we may have modesetting support in the kernel for some
> > graphics hw, right now it's pretty damn spotty.
>
> having no video is what i'd have expected - but getting a /hang/ is not
> what i'd have expected.
I debugged a case exactly like t
On Fri, 9 Mar 2007, Ingo Molnar wrote:
>
> disabling the following radeonfb options in the .config made resume work
> again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very rare laptops
(largely PPC Macs) where people had
[ Eric, Ingo, can you double-check the timer initialization after resume?
We appear to have several reports of date not advancing, and while this
could be some SATA issue, it could easily be a timer tick issue too ]
On Thu, 8 Mar 2007, Michael S. Tsirkin wrote:
>
> Here's the status with -
On Fri, 8 Dec 2006, Greg KH wrote:
>
> Here are some patches that move the HID code to a new directory allowing
> it to be used by other kernel subsystems easier.
I pulled. However, I think the Kconfig changes are HORRIBLE.
I don't understand why people don't use "select" more. Why should Kconf
On Wed, 15 Nov 2006, Andi Kleen wrote:
> >
> > Meanwhile we should restore the NMI counter to fix this bug.
>
> No, it was always oprofile who was buggy here, silently taking
> the nmi watchdog away.
Andi, your "blame game" doesn't matter.
The fact is, it used to work, and the kernel changed
On Thu, 28 Sep 2006, Greg KH wrote:
>
> Here are some more USB bugfixes and device ids 2.6.18. They should all
> fix the reported problems in your current tree (if not, please let me
> know.)
>
> All of these changes have been in the -mm tree for a while.
Maybe I shouldn't have hurried you.
On Thu, 28 Sep 2006, Greg KH wrote:
> >
> > Greg, can we please feed fixes to me faster?
>
> Faster? My god man, I just found out a few minutes ago that these were
> causing problems for people. I had only applied them to my local tree
> about 12 hours ago :)
Umm. I'm just saying that that f
On Thu, 28 Sep 2006, Alan Stern wrote:
>
> Another example of a bug for which the fix hasn't yet gone upstream to
> Linus. The -mm kernel should work. It you want to apply the fix
> yourself, it's these two patches:
Greg, can we please feed fixes to me faster?
Linus
--
On Thu, 22 Jun 2006, Greg KH wrote:
>
> Here are the two patches that fix the suspend issue and the USB oops
> issue in your current tree.
Ack. My box works again with this.
Linus
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly w
On Thu, 22 Jun 2006, Greg KH wrote:
>
> I saw this once when debugging the usb code, but could never reproduce
> it, so I attributed it to an incomplete build at the time, as a reboot
> fixed it.
I'm pretty sure the build was good, but it may well be timing-related.
> Is this easy to trigger fo
On Wed, 21 Jun 2006, Greg KH wrote:
>
> Here are a lot of USB patches for 2.6.17. They do the following:
I think these may be responsible for:
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.1
On Thu, 22 Jun 2006, Linus Torvalds wrote:
>
> After that, I'm not quite sure what you mean by "--dry-run". Do you mean
> to know about file-level conflicts? You do need to do the merge in order
> to know whether the conflicts can be resolved, but even without doin
On Thu, 22 Jun 2006, Sam Ravnborg wrote:
>
> Personally I'm still missing two things:
> 1) A command to let me see what this Linus guy have applied compared to
> my tree - without touching anything in my tree. bk changes -R
git fetch linus
git log ..linus
Yes, it will fetch the
On Thu, 22 Jun 2006, Greg KH wrote:
>
> I take that back. I just used -M for the W1 patch series and I think it
> is very helpful as it shows only the lines that change in a rename,
> which can easily get lost in the noise of a longer patch.
Yes. The main reason to do rename detection is not t
On Wed, 21 Jun 2006, Greg KH wrote:
>
> Ok, but how? I'm generating the diffstat in my script with:
>
> git diff origin..HEAD | diffstat -p1 >> $TMP_FILE
Btw, with a recent git (ie 1.4.0+), you can just do
git diff -M --stat origin..HEAD
to do that much more efficiently, and w
On Wed, 21 Jun 2006, Greg KH wrote:
>
> Ok, but how? I'm generating the diffstat in my script with:
>
> git diff origin..HEAD | diffstat -p1 >> $TMP_FILE
>
> Is there a better way to see these renames? In playing around with 'git
> diff' I didn't see how to do it, but I'm probably just
On Wed, 21 Jun 2006, Greg KH wrote:
>
> 123 files changed, 4169 insertions(+), 2440 deletions(-)
Btw, I get
119 files changed, 3888 insertions(+), 2159 deletions(-)
Why? Becuause my default pull script has rename detection enabled, and I
get:
rename include/linux/{usb_cdc.h => usb/cdc.h}
On Sun, 5 Feb 2006, Greg KH wrote:
>
> I thought we had fixed up all non-gpl USB drivers, and was wrong to do
> this.
There's also "usb_match_id". Should I just add that myself?
Linus
---
This SF.net email is sponsored by: Sp
On Tue, 29 Nov 2005, Greg KH wrote:
>
> include/linux/pci_ids.h |3 --
>
> Grant Coady:
> pci_ids.h: remove duplicate entries
Why is this in the USB tree, and WHY THE HELL DOES IT EXIST IN THE FIRST
PLACE?
Not only does it have absolutely nothing to do with USB, it's total
On Wed, 23 Nov 2005, Greg Kroah-Hartman wrote:
>
> Here are a few PCI, USB, hwmon, and documentation patches against your
> latest git tree, they have all been in the past few -mm releases just
> fine.
Is there any reason you don't use git to sync up?
Linus
---
On Thu, 13 Oct 2005, Pete Zaitcev wrote:
>
> The whole application cannot exit and leave URBs running behind,
> because usbdevio_release() blocks until they are terminated.
Wrong.
You just do a fork(), and a close in the parent.
"release()" won't be called until the _last_ close, and the task
On Tue, 11 Oct 2005, Greg KH wrote:
>
> Ugh, but it looks like Linus already committed your previous patch, with
> some changes by him. Care to send a delta from what is currently in his
> tree (2.6.14-rc4 has it) and this patch?
I _think_ I fixed the disconnect thing too, although I think Har
On Mon, 10 Oct 2005, Harald Welte wrote:
>
> Sorry, I've been busy, mostly with the annual netfilter developer
> workshop. What about the following proposed fix:
Yes, looks ok, apart from some small details. Like "uid" adn "euid" is of
type "uid_t", not "pid_t", and I think that "kill_proc_inf
On Sat, 1 Oct 2005, Harald Welte wrote:
>
> please find the patch below. It compiles, but I didn't yet have the
> time to verify it makes the bug disappear and the async urb delivery is
> still working.
No, you can't re-use "check_kill_permissions()" like this, even though I
do understand the
On Fri, 30 Sep 2005, Chris Wright wrote:
>
> Sorry, I missed the thread up to this, but this looks fundamentally
> broken. The kill_proc_info_as_uid() idea is not sufficient because more
> than uid/euid are needed for permission check. There's capabilities and
> security labels.
Not for this
On Wed, 28 Sep 2005, David Brownell wrote:
>
> You could try adding
>
> ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
>
> near the end of ohci_pci_suspend().
Btw, wouldn't this make more sense in ohci_hub_suspend()? That would pair
up with the resume, and there seems to
On Fri, 30 Sep 2005, Harald Welte wrote:
>
> I'm probably the person in this thread who understands the least about
> the USB stack and the scheduler, but if there is no implementation of
> Linus' suggested "PID approach" yet, I'd be willing to write a patch and
> test it. Please let me know.
H
On Wed, 28 Sep 2005, David Brownell wrote:
>
> You could try adding
>
> ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
>
> near the end of ohci_pci_suspend().
Give it up.
The right thing is to not free and re-aquire the damn interrupt in the
first place. It was a MISTAK
On Wed, 28 Sep 2005, Daniel Ritz wrote:
>
> cc:ing linus since he seems to have a strong opinion about that
> free_irq-in-suspend
> thing...not doing it for USB fixes the problem for both cases: APM suspend
> and ACPI
> suspend...
Trivial decision: if not freeing the irq fixes the problem, th
On Tue, 27 Sep 2005, Sergey Vlasov wrote:
>
> The initial patch added get_task_struct()/put_task_struct() calls to
> fix this - are they forbidden too?
They are sure as hell not something that a _driver_ is supposed to use.
> It at least has sigio_perm(), which prevents exploiting it to send
>
On Tue, 27 Sep 2005, Alan Cox wrote:
>
> Which doesn't take very long to arrange. Relying on pids is definitely a
> security problem we don't want to make worse than it already is.
The thing is, the current code is _worse_.
MUCH worse.
And it's worse exactly because it does things really wr
On Tue, 27 Sep 2005, Sergey Vlasov wrote:
>
> And then a process calls USBDEVFS_SUBMITURB and immediately exits; its
> pid gets reused by a completely different process (maybe even
> root-owned), then the urb completes, and kill_proc_info() sends the
> signal to the unsuspecting process.
Ehh..
On Sun, 25 Sep 2005, Harald Welte wrote:
>
> async_completed() calls send_sig_info(), which in turn does a
> spin_lock(&tasklist_lock) to protect itself from task_struct->sighand
> from going away. However, the call to
> "spin_lock_irqsave(task_struct->sighand->siglock)" causes an oops,
> becau
On Thu, 9 Jun 2005, Greg KH wrote:
>
> Please pull from:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/
>
> drivers/block/ub.c | 10 -
> drivers/pci/hotplug/cpci_hotplug_core.c |4
> drivers/pci/hotplug/cpci_hotplug_pci.c | 10 +
>
On Wed, 23 Feb 2005, Telemaque Ndizihiwe wrote:
>
> This Patch replaces "(2 * HZ)" with "DATA_TIMEOUT" which is defined as
> #define DATA_TIMEOUT (2 * HZ)
> in /drivers/usb/atm/speedtch.c in kernel 2.6.10.
Your patches are white-space damaged due to linewrap (and possibly other
issues, but
On Thu, 9 Dec 2004, Greg KH wrote:
>
> No, the "fun" problem with this specific field (the wTotalLength one) is
> that we initially read them in from the hardware (which for USB is in le
> order) and then, in a later function, convert all of the le fields to
> native cpu order so that all device
On Thu, 9 Dec 2004, Greg KH wrote:
>
> Greg Kroah-Hartman:
> o USB: fix another sparse warning in the USB core
This one looks incorrect.
The code doesn't _fix_ any warnings. It just shuts them up, without fixing
anything at all.
The fact is "le16_to_cpu()" should act on a le16 value, and
On Sat, 20 Nov 2004, David Brownell wrote:
>
> I thought I'd poke at the "sparse" lock checking stuff too,
> and as I half expected, it didn't like the way all the HCDs
> temporarily yield their spinlocks while calling out to URB
> completion handlers. But a fix to remove the warnings is
> simp
On Fri, 27 Aug 2004, Albert Cahalan wrote:
>
> Sure. That has nothing to do with whether it would
> be legal or not. It had been implied (by Greg KH)
> that you thought Linux-specific proprietary drivers
> using hooks are illegal.
And they may be. As I said, your posturing doesn't matter. Using
On Fri, 27 Aug 2004, Kenneth Lavrsen wrote:
>
> Try and see this from the developers perspective and then remember that he
> is a human beeing.
Hey, have you read the thread at all?
Respecting the developer is exactly why the code has been removed.
Being a developer gives you not only legal
Can we drop this straw-man discussion now?
We don't do binary hooks in the kernel. Full stop. It's a gray area
legally (and whatever you say won't change that), but it's absolutely not
gray from a distribution standpoint.
AND IT WASN'T EVER THE REASON FOR REMOVING THE DRIVER IN THE FIRST PLACE!
On Thu, 26 Aug 2004, Linus Torvalds wrote:
>
> At no point was it a legal argument. In fact, since none of the people
> involved were layers, you shouldn't even try to _make_ it a legal
> arguments.
Before somebody points out that I do legal arguments too, I just wish to
On Thu, 26 Aug 2004, Craig Milo Rogers wrote:
> On 04.08.26, Greg KH wrote:
> > Greg Kroah-Hartman:
> > o USB: rip out the whole pwc driver as the author wishes to have done
> > o USB: rip the pwc decompressor hooks out of the kernel, as they are a GPL
> > violation
>
> The decompres
On Thu, 26 Aug 2004, Eric St-Laurent wrote:
>
> I understand the need to remove the decompressors hooks, i can live with
> the inconveniences for the time being.
I think everybody can understand that part.
> However, i think that the GPL pwc driver should stay in, regardless of
> the author op
On Sun, 16 May 2004, David Brownell wrote:
>
> More like this then? I'm not sure whether you'd prefer
> to apply that logic to the "struct pm_info" innards too.
> That file has multiple CONFIG_PM sections, too.
I was thinking just putting it in the existing wrapper sections.
We already have w
On Sun, 16 May 2004, David Brownell wrote:
>
> Speaking of which, please consider merging this. It
> missed Greg's push on Friday, but it's needed to build
> OHCI and EHCI with CONFIG_USB_DEBUG when !CONFIG_PM.
I really have #ifdef's inside code. Even when it is in header files.
So I'd much r
On Sat, 15 May 2004, Olaf Hering wrote:
> On Fri, May 14, Greg KH wrote:
>
> > drivers/usb/misc/cytherm.c |9
>
> current Linus tree does not compile:
Replace all "led" with "cytherm". The code was crap, and would never have
compiled with debugging on anyway.
On Fri, 20 Feb 2004, Hollis Blanchard wrote:
>
> And USB, when it creates its bus_type, does this:
> int usb_dma_supported(struct device *dev, u64 mask) {
> usb_dev *usbdev = to_usb_device(dev);
> return usbdev->root_hub->controller->bus->dma_supported(controlle
On Fri, 20 Feb 2004, Hollis Blanchard wrote:
>
> Well, I was picturing all those *_dma_supported() functions as being
> plugged into (new) fields in struct bus_type:
> struct bus_type {
> ...
> int (*dma_supported)(struct device *dev, u64 mask);
> }
Ok,
On Thu, 19 Feb 2004, David S. Miller wrote:
> On Fri, 20 Feb 2004 18:10:41 +1100
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > Hrm... so if the USB device drivers are actually doing the dma mapping
> > themselves, it make sense for them to pass their own struct device, no ?
>
> That
On Fri, 20 Feb 2004, Benjamin Herrenschmidt wrote:
>
> > Well, we do. The pcibios_xxx routines get called for all PCI devices
> > during discovery, and that's when you'd fill them in.
>
> But what about USB or FireWire devices ? In theory, I'd like to see
> the driver for those not have to bot
On Fri, 20 Feb 2004, Benjamin Herrenschmidt wrote:
>
> Yes, but we don't have a hook for actually filling this pointer, do we ?
Well, we do. The pcibios_xxx routines get called for all PCI devices
during discovery, and that's when you'd fill them in.
Anyway, I found the bug - the "asm-generic
On Fri, 20 Feb 2004, Benjamin Herrenschmidt wrote:
>
> A while ago, I've advertised making this API a set of function
> pointers attached to the struct device inherited from the bus
> parent, so the core code just set one for the root PCIs and
> everybody inherits them But of course, since x
On Thu, 19 Feb 2004, Greg KH wrote:
>
> Here are some USB patches for 2.6.3. Here are the main types of changes:
> - switch usb code to use dmapools instead of pcipools which
> makes the embedded people happy.
However, this makes the ppc64 people very unhappy.
I've just yesterda
On Wed, 24 Sep 2003, Ruud Linders wrote:
> >
> > Is this different from a plain kernel _without_ the patch?
>
> No difference.
Ok. I committed my version as "better than what is there now", but clearly
it's not good enough.
So we should really add code to sd_read_cache_type() to default to
wr
On Tue, 23 Sep 2003, Ruud Linders wrote:
>
> I tried the patch but it doesn't work for me using an USB-2 Memory stick
> "DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded).
>
> After a 3 minute time-out I get
> "SCSI device sda: drive cache: write through"
> and the device starts
On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote:
>
> No, the design goal of "hot-pluggable" is that it indicates that
> the device can disappear any moment. Nothing at all about SCSI
> compliance.
You're talking past each other.
Server people think that "hot-pluggable" means "I will tell the system
On 22 Sep 2003, James Bottomley wrote:
>
> I think we could try 4 bytes for this (even to avoid wide residue
> problems) and see how it goes.
How about just trusting the size (and as far as I can tell from the SCSI
specs, the size is the size _without_ the header and block descriptors),
and ca
On Mon, 22 Sep 2003, David Brownell wrote:
> > Again, this case worked fine with the sd.c changes, so it does seem to be
> > all related to "big" transfers out of the mode page.
>
> Or at any rate, "big enough" to confuse the device.
Yes. Additional testing (making the code just increase the si
On Mon, 22 Sep 2003, Patrick Mansfield wrote:
> On Mon, Sep 22, 2003 at 09:09:47AM -0700, Linus Torvalds wrote:
> >
> > (Btw, where are the different mode sense pages documented?)
>
> The latest SCSI 3 draft standards are online as follows, the SCSI 2 specs
> are al
On Mon, 22 Sep 2003, David Brownell wrote:
>
> In this case, because it's not "EHCI + USB 2.0 hub", it's still using
> the OHCI companion controller. So that wasn't a new case.
Ok. Here's the broken case with an added usb-2 hub in between. It is
indeed a bit different.
Again, this case worked
On Mon, 22 Sep 2003, David Brownell wrote:
>
> Linus Torvalds wrote:
> > Interesting data-point: the device is a happy EHCI camper, and is
> > totally able to read codepage 8 on EHCI.
> >
> > However, if I put it behind a USB-1 hub on the EHCI port, I see the
>
[ Andries added to the cc ]
On Mon, 22 Sep 2003, Patrick Mansfield wrote:
>
> I can modify the patch for that.
How about just making the sd.c layer more robust? That has worked well in
the past, and it seems wrong to have to add more and more flags.
In particular, while hunting down the usb-1
On Mon, 22 Sep 2003, Alan Stern wrote:
>
> This problem has been cropping up with many, many USB storage devices.
Interesting data-point: the device is a happy EHCI camper, and is totally
able to read codepage 8 on EHCI.
However, if I put it behind a USB-1 hub on the EHCI port, I see the same
On Mon, 22 Sep 2003, Matthew Dharm wrote:
>
> You say this worked with UHCI 'some time ago'? Perhaps that was before all
> this mode page 8 stuff got settled?
Quite possible. But it definitely works with EHCI today, so it's still a
HC issue..
Linus
-
On Sun, 21 Sep 2003, Linus Torvalds wrote:
> >
> > Odd... why do we ask for the first 8 bytes of page 8? The header alone is
> > 8 bytes anyway, the response looks good.
>
> It tries to read the cache type. It tries to read the header first, in
> order to figur
On Sun, 21 Sep 2003, Matthew Dharm wrote:
>
> > usb-storage: queuecommand called
> > usb-storage: *** thread awakened.
> > usb-storage: Command READ_CAPACITY (10 bytes)
> >
> > SCSI device sda: 2000880 512-byte hdwr sectors (1024 MB)
>
> Normal READ_CAPACITY -- is that size correct?
Yes. I've
On Sun, 21 Sep 2003, Matthew Dharm wrote:
>
> There's more to analyize, but on first inspection that babble looks bad.
>
> We submitted a single URB with a 128 byte buffer. We received 64 bytes. I
> don't think a babble is actually possible here
>
> So something has gone bad at a lower lev
I have a nice USB-2-capable compact flash reader that works perfectly on
my EHCI system, and that I've also verified some time ago on an UHCI setup
(but hey, the UHCI part could have rotted over time).
However, on a HP laptop I have with an ALI southbridge, the USB subsystem
dies badly wheneve
On Sat, 21 Jun 2003, Matthew Dharm wrote:
>
> I don't see how a sense command sent from the scsi-generic interface will
> affect (or be affected by) use_10_for_ms -- if scsi-generic issues the
> command, this code path won't try to interpret the data at all. Perhaps
> I'm confused?
Yeah, it onl
On Sat, 21 Jun 2003, Matthew Dharm wrote:
>
> I mean, this works, it's not difficult to follow, and meets all the
> operational goals.
As far as I can tell, your patch is not actually all that stable.
Imagine a flaky SCSI connection (think iscsi or whatever), where your
commands are getting los
On Sat, 21 Jun 2003, Matthew Dharm wrote:
>
> This patch makes sr.c respect the use_10_for_ms flag.
Ouch.
Is there some SCSI person out there that would be willing to make sr.c
look a bit more like sd.c in this respect? This is a bit hacky, I think,
but I guess the sr.c layout forces that..
On Sat, 21 Jun 2003, Linus Torvalds wrote:
>
> > So, if my theory sounds correct to you, can you try moving the call to
> > scsi_device_register() to the end of scsi_add_lun()?
>
> Yes.
>
> I also have this strong urge make the default "use_10_for_ms" va
On Sat, 21 Jun 2003, Matthew Dharm wrote:
>
> However, my top suspect is the call to scsi_device_register() in
> scsi_add_lun(), which takes place _well_ before the sdev is properly
> configured. At first, I thought that just creates some devfs entries, but
> if that is what triggers the probing
On Fri, 20 Jun 2003, Linus Torvalds wrote:
>
> Are you sure that your devices don't just handle READ_6 and SENSE_6 ok?
I'm pretty sure your devices just handle it.
Because adding some debugging code seems to clearly show that when you
moved the setting of "use_10_for_XX&q
On Fri, 20 Jun 2003, Matthew Dharm wrote:
>
> This is actually the second complaint I've gotten along these lines... in
> the other case, it appeared that the MODE_SENSE/MODE_SENSE_10 logic had
> gotten screwed up.
>
> I think it might actually be a merging problem somewhere along the line,
> bec
USB storage is broken for me recently (like in the last 5 days or so). My
good old SIIG USB-2 "hi-speed" CF reader that used to be very reliable now
will refuse to even read the partition table.
The problem _seems_ to be that somebody broken the READ_10 logic, and it
now always does a READ_6. W
On Wed, 26 Mar 2003, Bill Davidsen wrote:
>
> Another "bk-only" patch. Guess I'd better look at the free (as in license,
> not cost) clone again.
Well, since BK has made it so trivial for me to merge with Greg, the thing
is already integrated into my tree, and as a result the patches should
al
On 24 Mar 2003, James Bottomley wrote:
> >
> > For disk-like media:
> >
> > READ_10
> > WRITE_10
>
> We do about the best we can for read and write. For sd, we gauge the
> size of the command from the size of the medium: <1Gb=> six byte, from
> 1Gb to 2Tb 10 byte, over 2Tb 16 byte, so I think
On Sun, 23 Mar 2003, Matthew Dharm wrote:
> On Sun, Mar 23, 2003 at 07:26:09PM -0600, James Bottomley wrote:
> > The problem with this type of approach is that there's no unified list
> > of "known good" commands that actually let you operate a device. The
> > SCSI and ATAPI standards have been
On Sat, 22 Mar 2003, Matthew Dharm wrote:
>
> As I see it, SCSI commands break down into two basic categories: common
> and uncommon. Common things (basic read and write, 36-byte INQUIRY, eject,
> etc.) are all fine, but the 'uncommon' things (checking cache type,
> 255-byte INQUIRY, etc) cause
On Sat, 22 Mar 2003, Matthew Dharm wrote:
>
> This patch changes how devices a probed on a SCSI bus if they are on an
> emulated host.
I really think this is wrong. I'd much much rather get _rid_ of that
stupid "emulated" flag, instead of adding meaning to it.
> If a host is emulated, we (a) do
On Thu, 9 Jan 2003, Greg KH wrote:
> Hm, looks like you didn't get the USB changes I sent :)
I did, but they got applied after 2.5.55 was released (they're part of the
current BK tree).
Linus
---
This SF.NET email is sponsor
On Tue, 17 Dec 2002, David Brownell wrote:
>
> There do seem to be some EHCI issues, mostly with bulk (sigh) though.
Yeah, I think I saw them earlier, and they've been able to lock up the
machine completely at times.
But the oops was new - I've been using this USB reader for some time,
includin
The latest USB updates seem to be buggy.
My USB-2 setup that used to mostly work, now oopses in khubd in
when I insert my CompactFlash reader into my
external USB hub:
drivers/usb/core/hub.c: new USB device 04:07.2-3.1, assigned address 3
Unable to handle kernel NULL pointer der
On Fri, 1 Nov 2002, David Brownell wrote:
>
> >>Oct 31 22:58:47 tove kernel: drivers/usb/core/message.c: usb_control/bulk_msg:
>timeout
> >>Oct 31 22:58:47 tove kernel: drivers/usb/host/ohci-dbg.c: UNLINK dc8e2b1c
>dev:4,ep=0-I,CTRL,flags:0,len:0/1,stat:-2
> >>Oct 31 22:58:47 tove k
On Thu, 31 Oct 2002, Greg KH wrote:
>
> Did 2.5.44 work, but 2.5.45 not work for the printer?
Nope. That machine ran 2.5.42 (or maybe 41) before that, and failed
similarly. I updated it to BK as of an hour ago, and since it still failed
I did the report. So it's been going on for at least a fe
1 - 100 of 109 matches
Mail list logo
