On Monday 15 October 2007 11:38:33 pm Eric W. Biederman wrote:
> > I don't follow your logic. We don't need SWAP > RAM in order to swap
> > effectively, IMO.
>
> The steady state of a system that is heavily and usably swapping but
> not thrashing is that all of the pages in RAM are in the swap cach
Jeff Garzik wrote:
> Greg KH wrote:
>> On Mon, Oct 15, 2007 at 03:36:15AM -0500, Rob Landley wrote:
>>> The point I was trying to make is that it seems to me like it would
>>> be possible to keep the namespace separate here, and thus reduce the
>>> enumeration problems to the point where common cas
Nick Piggin wrote:
On Monday 15 October 2007 19:52, Rob Landley wrote:
On Monday 15 October 2007 8:37:44 am Nick Piggin wrote:
You really shouldn't configure
so much [swap] unless you do want the kernel to actually use it all, right?
Two words: "Software suspend". I've actually
[EMAIL PROTECTED] wrote:
> On Mon, 15 Oct 2007, Stefan Richter wrote:
>> Low-level networking drivers suggest a default interface name (per
>> interface or as a template like eth%d into which the networking core
>> inserts a lowest spare number).
...
>> Could low-level SCSI drivers provide similar
On 10/14/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> I didn't notice that qemu was involved. Does qemu have an emulator for the
> gdth hardware?
>
I think no, the kernel just probe exist or not hardware, and hangs after that.
-
To unsubscribe from this list: send the line "unsubscribe linux-sc
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Mon, 15 Oct 2007 23:05:07 -0600
> Remove FC4 and all associated drivers
>
> This code has been slowly rotting for about eight years. It's currently
> impeding a few SCSI cleanups, and nobody seems to have hardware to test
> it an
On Mon, 15 Oct 2007, Greg KH wrote:
On Mon, Oct 15, 2007 at 10:04:01PM -0600, Matthew Wilcox wrote:
On Mon, Oct 15, 2007 at 07:54:22PM -0700, [EMAIL PROTECTED] wrote:
do PCI devices reorder their bus numbers spontaniously, or only if you
change the hardware?
The only system I've had that reo
On Tuesday 16 October 2007 14:38, Eric W. Biederman wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > On Tuesday 16 October 2007 13:55, Eric W. Biederman wrote:
> > I don't follow your logic. We don't need SWAP > RAM in order to swap
> > effectively, IMO.
>
> The steady state of a system that i
[EMAIL PROTECTED] writes:
>
> on some kernel versions you are correct about needing swap > ram, but on
> current
> versions you are not. the swap space gets allocated as needed, and re-used as
> needed (I don't know the mechanism of this, but I remember the last time this
> changed from vm=max(ra
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Tuesday 16 October 2007 13:55, Eric W. Biederman wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>
>> > How much swap do you have configured? You really shouldn't configure
>> > so much unless you do want the kernel to actually use it all, right?
>>
>
On Mon, Oct 15, 2007 at 10:04:01PM -0600, Matthew Wilcox wrote:
> On Mon, Oct 15, 2007 at 07:54:22PM -0700, [EMAIL PROTECTED] wrote:
> > do PCI devices reorder their bus numbers spontaniously, or only if you
> > change the hardware?
>
> The only system I've had that reordered PCI bus numbers was
On Tuesday 16 October 2007 13:55, Eric W. Biederman wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
> > How much swap do you have configured? You really shouldn't configure
> > so much unless you do want the kernel to actually use it all, right?
>
> No.
>
> There are three basic swapping scenario
On Mon, 15 Oct 2007 22:04:01 -0600
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 15, 2007 at 07:54:22PM -0700, [EMAIL PROTECTED] wrote:
> > do PCI devices reorder their bus numbers spontaniously, or only if
> > you change the hardware?
>
> The only system I've had that reordered PCI bus
On Mon, 15 Oct 2007, Matthew Wilcox wrote:
On Mon, Oct 15, 2007 at 07:54:22PM -0700, [EMAIL PROTECTED] wrote:
do PCI devices reorder their bus numbers spontaniously, or only if you
change the hardware?
The only system I've had that reordered PCI bus numbers was when I had a
partitionable syst
On Mon, 15 Oct 2007, Eric W. Biederman wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
How much swap do you have configured? You really shouldn't configure
so much unless you do want the kernel to actually use it all, right?
No.
There are three basic swapping scenarios.
- Pushing unused data
On Mon, Oct 15, 2007 at 07:54:22PM -0700, [EMAIL PROTECTED] wrote:
> do PCI devices reorder their bus numbers spontaniously, or only if you
> change the hardware?
The only system I've had that reordered PCI bus numbers was when I had a
partitionable system and changed the partitioning. Not quite
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Monday 15 October 2007 18:04, Rob Landley wrote:
>> On Sunday 14 October 2007 8:45:03 pm Theodore Tso wrote:
>
>> > > excuse for conflating different categories of devices in the first
>> > > place.
>> >
>> > See the thinkpad Ultrabay drive example abov
On Mon, 15 Oct 2007, Stefan Richter wrote:
Subject: Re: What still uses the block layer?
Matthew Wilcox wrote:
On Mon, Oct 15, 2007 at 04:26:04AM -0500, Rob Landley wrote:
Combining USB and IDE into the same /dev/sd? namespace makes enumerating the
IDE devices much harder than in the traditio
On Mon, 15 Oct 2007, Greg KH wrote:
On Mon, Oct 15, 2007 at 05:08:36AM -0500, Rob Landley wrote:
On Monday 15 October 2007 4:06:20 am Julian Calaby wrote:
On 10/15/07, Rob Landley <[EMAIL PROTECTED]> wrote:
I note that the eth0 and eth1 names are dynamically assigned on a first
come first ser
On Mon, 15 Oct 2007, Theodore Tso wrote:
On Mon, Oct 15, 2007 at 03:04:00AM -0500, Rob Landley wrote:
just
as Ethernet and PPP interfaces really are fundamentally the same
thing.
They're the same thing?
Do you mean that on a system with both, going:
ifconfig eth1 66.92.53.140
ifconfig p
On Tue, 16 Oct 2007, Neil Brown wrote:
On Monday October 15, [EMAIL PROTECTED] wrote:
Therefore it is best to not have stable single-number naming schemes
for any devices on any machines. Why? Because it ensure there will
not be any second class citizens.
This is where we disagree. The exi
James wrote:
> In that case, the correct fix
> is actually to move the scatterlist include from scsi_error.c (where the
> scatterlist was originally used locally) into scsi_eh.h, like this.
I suspect you're correct, yes.
--
I won't rest till it's the best ...
On Mon, 2007-10-15 at 17:08 -0700, Paul Jackson wrote:
> James wrote:
> > The requirement for struct scatterlist is the same
> > before and after the gid scsi-misc patch.
>
> Not so. The git-scsi-misc.patch in 2.6.23-mm1 clearly adds the line:
>
> struct scatterlist sense_sgl;
>
> as part
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix kernel-api docbook warnings.
Warning(linux-2.6.23-git8//drivers/message/fusion/mptscsih.c:2618): No
description found for parameter 'sc'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/message/fusion/mptscsih.c | 10 +++---
1 file ch
James wrote:
> The requirement for struct scatterlist is the same
> before and after the gid scsi-misc patch.
Not so. The git-scsi-misc.patch in 2.6.23-mm1 clearly adds the line:
struct scatterlist sense_sgl;
as part of the added struct scsi_eh_save in scsi/scsi_eh.h.
This bit me while I
On Mon, 15 Oct 2007 19:35:30 -0400
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-10-13 at 22:35 -0700, Paul Jackson wrote:
> > From: Paul Jackson <[EMAIL PROTECTED]>
> >
> > The added line in scsi_eh.h:
> > struct scatterlist sense_sgl;
> > fails to compile, with the error:
> >
[adding back CCs which were dropped because I'm stupid - sorry!]
On 10/16/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> On Monday 15 October 2007 5:27:55 am Julian Calaby wrote:
> > On 10/15/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> > > On Monday 15 October 2007 4:06:20 am Julian Calaby wrote:
>
On Monday October 15, [EMAIL PROTECTED] wrote:
> > Therefore it is best to not have stable single-number naming schemes
> > for any devices on any machines. Why? Because it ensure there will
> > not be any second class citizens.
>
> This is where we disagree. The existence of devices you cannot
On Sat, 2007-10-13 at 22:35 -0700, Paul Jackson wrote:
> From: Paul Jackson <[EMAIL PROTECTED]>
>
> The added line in scsi_eh.h:
> struct scatterlist sense_sgl;
> fails to compile, with the error:
> field 'sense_sgl' has incomplete type
> unless scatterlist.h happens to be included
> s
On Monday 15 October 2007 12:25:13 pm Greg KH wrote:
> Oh, and this seems like a very Ubuntu specific rant, might I suggest you
> contact the Ubuntu developers about this? The kernel doesn't dictate
> that the distro has to use these long identifiers, and there is nothing
> we can do about it.
I
Bartlomiej Zolnierkiewicz wrote:
On Friday 12 October 2007, Jeff Garzik wrote:
[ I just sent this upstream to Andrew and Linus ]
Now that I have nailed down the corruption problem, I can attend to
this... Fun stuff:
* port multiplier support (like an ethernet hub, only dumber)
Great to see
> This is where we disagree. The existence of devices you cannot stably
> enumerate does not eliminate the existence of devices you trivially can.
"trivially"
You are I assume familiar in full with EDD 3.0, EDD 1.x and the Ralf
Brown documentation on the BIOS drive mappings and tables for diff
On Monday 15 October 2007 8:10:49 am James Bottomley wrote:
> OK, so could we get back to the original discussion? The question I
> think you meant to ask is "does SCSI use the block layer, and if so;
> how?"
>
> The answer is yes (just do an ls /sys/block on any scsi machine). The
> how is that
Rob Landley wrote:
I realize that both views are valid. This is why the US has a house and a
senate, and filters things through both views. My gripe is that forcing my
laptop to look at my USB devices to find my SATA hard drive is aligned with
only one of those viewpoints, and completely oppo
On Monday 15 October 2007 6:19:58 am Neil Brown wrote:
> On Monday October 15, [EMAIL PROTECTED] wrote:
> > This is my objection. Even when enumerating multiple devices of the same
> > type is tricky, enumerating multiple devices of _different_ types should
> > not be. There's a great big type ind
On Monday 15 October 2007 5:32:32 am Loïc Grenié wrote:
> You are really looking like you are out for a fight.
...
> Your objection is interesting. It is lost in the middle of e-mails
> which, to the untrained eye, look like you are trying to fight everyone and
> everybody.
...
> ...holy
Am Mon, Oct 15, 2007 at 04:26:04AM -0500 schrieb Rob Landley:
> To clarify, I think that merging ide, sata, usb, firewire, and others into a
> single device namespace causes each type of device to inherit that
> namespace's cumulative ordering issues, which is a bad thing. I have no real
> atta
From: Randy Dunlap <[EMAIL PROTECTED]>
Pluto drivers uses disable/enable_irq(), so add prototypes for them.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/scsi/pluto.c |1 +
1 file changed, 1 insertion(+)
--- linux-2.6.23-git7.orig/drivers/scsi/pluto.c
+++ linux-2.6.23-git7/dri
> > I think I see two problems ... one is that fc4 plainly depends on SCSI,
Does it? It builds with SCSI=n.
> > yet it's not mentioned in the fc4 Kconfig file. The other is that,
> > given this dependency, fc4 should come after scsi. And maybe even be
> > included from drivers/scsi/Kconfig rat
Fix IRQ reporting - just assign the ->pci_dev pointer earlier and use the
pci_dev irq field rather than keeping a private one
Init the spinlock as it works better on SMP that way
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.van
On Mon, Oct 15, 2007 at 07:00:22AM -0700, Arjan van de Ven wrote:
> that's a choice Ubuntu made in their udev scripts... if you don't like
> it, complain to them.
Keeping the naming as hda while changing the semantics (such as the
reduced number of partitions) would have been differently confusi
Greg KH wrote:
On Mon, Oct 15, 2007 at 03:36:15AM -0500, Rob Landley wrote:
The point I was trying to make is that it seems to me like it would be
possible to keep the namespace separate here, and thus reduce the enumeration
problems to the point where common cases (like my laptop) aren't impac
On Mon, Oct 15, 2007 at 08:18:24PM +0200, Boaz Harrosh wrote:
> This is all new territory for me. But CONFIG_SCSI_PLUTO is dependent on
> SCSI and fc.c is not the real driver just the needed bits from the sparc
> side. So the code mess calls for a Kconfig mess, I guess.
I've spent a lot of time lo
oofff that was to fast, sorry. Wrong sg_count in unmapping.
---
- pluto.c was still issuing use_sg == 0 commands down to
fc.c, which was already converted. Fix that by adding
a member to hold the inquiry_sg in struct fcp_cmnd
and using it when mapping/unmapping of command payload,
Matthew Wilcox wrote:
> On Mon, Oct 15, 2007 at 07:26:51PM +0200, Boaz Harrosh wrote:
>> @@ -22,6 +22,8 @@ source "drivers/misc/Kconfig"
>>
>> source "drivers/ide/Kconfig"
>>
>> +source "drivers/fc4/Kconfig"
>> +
>> source "drivers/scsi/Kconfig"
>>
>> source "drivers/ata/Kconfig"
>
> I th
On Mon, Oct 15, 2007 at 08:00:22PM +0200, Boaz Harrosh wrote:
> Some people, me included, might like this approach better
I think I prefer this approach too.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
From: Kristen Carlson Accardi <[EMAIL PROTECTED]>
If a scsi_device supports async notification for media change, then
let user
space know this capability exists by creating a new sysfs entry
"media_change_notify", which will be 1 if it is supported,
On Mon, Oct 15, 2007 at 07:26:51PM +0200, Boaz Harrosh wrote:
> @@ -22,6 +22,8 @@ source "drivers/misc/Kconfig"
>
> source "drivers/ide/Kconfig"
>
> +source "drivers/fc4/Kconfig"
> +
> source "drivers/scsi/Kconfig"
>
> source "drivers/ata/Kconfig"
I think I see two problems ... one is tha
On Mon, Oct 15, 2007 at 10:25:13AM -0700, Greg KH wrote:
> Use mount-by-label instead, it's much saner and handles device name
> movement just fine (as does the UUID method that you seem to hate.)
> Look in /dev/disk/ for a wide range of options that you have in which to
> choose how to pick your b
Some people, me included, might like this approach better
- pluto.c was still issuing use_sg == 0 commands down to
fc.c, which was already converted. Fix that by adding
a member to hold the inquiry_sg in struct fcp_cmnd
and using it when mapping/unmapping of command payload,
On Mon, Oct 15, 2007 at 07:25:14PM +0200, Boaz Harrosh wrote:
> From: Matthew Wilcox <[EMAIL PROTECTED]>
>
> Remove uses of the scsi_cmnd ->done method from the fc4 driver. It was
> being abused to flag commands that had already been through queuecommand;
> use the fcmd->proto value for that inst
Alan Cox wrote:
You can pull a Model and Serial number via hdparm -i, but it's not as
easy to manipulate as a fixed-length MAC address. That's why people
tend to use filesystem UUID's.
ATA8 at the moment looks set to add a true "MAC" or "WWN" type identifier
to each device.. Right now model
- pluto.c was still issuing use_sg == 0 commands down to
fc.c, which was already converted. Fix that by adding
a member to hold the inquiry_buffer in struct fcp_cmnd
and using it when mapping/unmapping of command payload,
if needed.
- Also fix a compilation warning in pluto_in
On Mon, Oct 15, 2007 at 05:08:36AM -0500, Rob Landley wrote:
> On Monday 15 October 2007 4:06:20 am Julian Calaby wrote:
> > On 10/15/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> > > I note that the eth0 and eth1 names are dynamically assigned on a first
> > > come first serve basis (like scsi). T
On Mon, Oct 15, 2007 at 03:36:15AM -0500, Rob Landley wrote:
>
> The point I was trying to make is that it seems to me like it would be
> possible to keep the namespace separate here, and thus reduce the enumeration
> problems to the point where common cases (like my laptop) aren't impacted by
- It was suggested on the linux-scsi-ml that:
"Well if fc4.c compiles OK on non-sparc64 then perhaps we should
enable compilation on non-sparc64. It will increase maintainability
and code quality and stuff."
- WATCH OUT Distro maintainers:
"otoh people might end up ship
From: Matthew Wilcox <[EMAIL PROTECTED]>
Remove uses of the scsi_cmnd ->done method from the fc4 driver. It was
being abused to flag commands that had already been through queuecommand;
use the fcmd->proto value for that instead. The fcmd->done pointer now
becomes irrelevant. Reuse the fcp_scsi
I'm sending a small lift-up to the drivers/scsi/pluto.c and
drivers/fc4/fc.c pair, that where a bit stepped on lately.
Matthew this includes your patch, I just fixed up the patch
comment, since You had a good comment on the first patch
but sent a better second patch with no comment. (And my set
d
Matthew Wilcox wrote:
> On Mon, Oct 15, 2007 at 04:26:04AM -0500, Rob Landley wrote:
>> Combining USB and IDE into the same /dev/sd? namespace makes enumerating the
>> IDE devices much harder than in the traditional "/dev/hdb doesn't move
>> without a screwdriver" model. The merger creates a new
On Mon, Oct 15, 2007 at 04:26:04AM -0500, Rob Landley wrote:
> For example, usb devices are never easy to order. IDE devices (back when
> they
> had their own namespace) were trivial to order back when /dev/hda couldn't
> move without use of a screwdriver.
Ah, but it could. If you had more th
Theodore Tso wrote:
> On Mon, Oct 15, 2007 at 03:04:00AM -0500, Rob Landley wrote:
>> Ok, I'll bite. If it's all "real" scsi, why does ioctl(SG_EMULATED_HOST)
>> exist? exist if it's all "real" scsi?
>
> SG_EMULATED_HOST was added before Linux 2.4, at least six or seven
> years ago.
SG_EMULATED
On Mon, 15 Oct 2007 03:36:15 -0500
Rob Landley <[EMAIL PROTECTED]> wrote:
> The point I was trying to make is that it seems to me like it would
> be possible to keep the namespace separate here, and thus reduce the
> enumeration problems to the point where common cases (like my laptop)
> aren't im
>> Compile tested and applies cleanly to 2.6.23.
>> I don't have this hardware anymore and cannot run test these patches.
>
> I can test these patches on an aic7892 controller later on today if you want.
Works fine for me tested on :
03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160
On Mon, Oct 15, 2007 at 02:29:45PM +0100, Alan Cox wrote:
> > You can pull a Model and Serial number via hdparm -i, but it's not as
> > easy to manipulate as a fixed-length MAC address. That's why people
> > tend to use filesystem UUID's.
>
> ATA8 at the moment looks set to add a true "MAC" or
> You can pull a Model and Serial number via hdparm -i, but it's not as
> easy to manipulate as a fixed-length MAC address. That's why people
> tend to use filesystem UUID's.
ATA8 at the moment looks set to add a true "MAC" or "WWN" type identifier
to each device.. Right now model/serial is no
On Mon, Oct 15, 2007 at 03:04:00AM -0500, Rob Landley wrote:
> Ok, I'll bite. If it's all "real" scsi, why does ioctl(SG_EMULATED_HOST)
> exist? exist if it's all "real" scsi?
SG_EMULATED_HOST was added before Linux 2.4, at least six or seven
years ago. Back then the migration of ATA devices th
On Sun, 2007-10-14 at 18:45 -0500, Rob Landley wrote:
> On Sunday 14 October 2007 5:24:32 pm James Bottomley wrote:
> > On Sat, 2007-10-13 at 16:05 -0600, Matthew Wilcox wrote:
> > > On Thu, Oct 11, 2007 at 08:11:21PM -0500, Rob Landley wrote:
> > > > My impression from asking questions on the linu
> For the desktop I don't object to the scsi layer. I object to the naming.
> Merging a half-dozen different types of devices into a single name space, and
They *are* SCSI devices. USB storage is a SCSI over USB transport. ATAPI
is a SCSI over ATA transport. SAS is much the same thing, as is F
On Mon, Oct 15, 2007 at 11:37:44PM +1000, Nick Piggin wrote:
> I hate to go completely offtopic here, but disks are so incredibly
> slow when compared to RAM that there is really nothing the kernel
> can do about this. Presumably the job will finish, given infinite
> time.
About 6 weeks ago, on a
On Sunday 14 October 2007 18:47, Gabriel C wrote:
> > Compile tested and applies cleanly to 2.6.23.
> > I don't have this hardware anymore and cannot run test these patches.
>
> I can test these patches on an aic7892 controller later on today if you want.
I'd appreciate that.
Do you, by any chan
On Monday October 15, [EMAIL PROTECTED] wrote:
>
> This is my objection. Even when enumerating multiple devices of the same
> type
> is tricky, enumerating multiple devices of _different_ types should not be.
> There's a great big type indicator that is being _deliberately_ ignored, and
> la
2007/10/15, Rob Landley <[EMAIL PROTECTED]>:
> On Sunday 14 October 2007 8:45:03 pm Theodore Tso wrote:
>> On Sun, Oct 14, 2007 at 06:45:44PM -0500, Rob Landley wrote:
>>> I admit a certain amount of personal annoyance that once the SCSI
>>> layer consumes a category of device (USB, SATA, PATA), th
On Friday 12 October 2007 23:08:21 Jeff Garzik wrote:
> Bernd Schubert wrote:
> > a) 2.6.23 + sil-patch I posted, this is on a customer system (though my
> > former group), I wouldn't like to use -mm there.
> >
> > b) .config is attached
> >
> > c) attached
> >
> > d) attached (don't get irritaded
On Monday 15 October 2007 4:06:20 am Julian Calaby wrote:
> On 10/15/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> > I note that the eth0 and eth1 names are dynamically assigned on a first
> > come first serve basis (like scsi). This never causes me a problem
> > because the driver loading order is
On Monday 15 October 2007 19:52, Rob Landley wrote:
> On Monday 15 October 2007 8:37:44 am Nick Piggin wrote:
> > > Virtual memory isn't perfect. I've _always_ been able to come up with
> > > examples where it just doesn't work for me. This doesn't mean VM
> > > overcommit should be abolished, be
On Monday 15 October 2007 8:37:44 am Nick Piggin wrote:
> > Virtual memory isn't perfect. I've _always_ been able to come up with
> > examples where it just doesn't work for me. This doesn't mean VM
> > overcommit should be abolished, because it's useful more often than not.
>
> I hate to go comp
On Monday 15 October 2007 12:44:19 am Stefan Richter wrote:
> Rob Landley wrote:
> > I was at least attempting to ask a serious question.
>
> ...
>
> > Actually, I was going through Documentation/block thinking about making a
> > 00-INDEX for it, but my earlier questions of the scsi guys left me wi
On Monday 15 October 2007 1:00:15 am Greg KH wrote:
> If you hate USB storage devices using scsi, please use the ub driver,
> that is what it was written for.
For the embedded space, the ability to configure out the scsi layer is
interesting from a size perspective. I bookmarked that a while bac
On 10/15/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> I note that the eth0 and eth1 names are dynamically assigned on a first come
> first serve basis (like scsi). This never causes me a problem because the
> driver loading order is constant, and once you figure out that eth0 is
> gigabit and eth1
On Sun, Oct 14, 2007 at 11:00:15PM -0700, Greg KH wrote:
> If you hate USB storage devices using scsi, please use the ub driver,
> that is what it was written for.
The ub driver is a really dumb piece of shit. It only drivers usb storage
devices using a scsi protocol set, and duplicates the scsi
--- Rob Landley <[EMAIL PROTECTED]> wrote:
> On Sunday 14 October 2007 7:45:46 pm Luben Tuikov wrote:
> > Matthew's expletive and extremely rude response really shows
> > the general attitude of the linux-scsi people.
>
> No, it doesn't. James Bottomley has been exceedingly polite and helpful, as
On Monday 15 October 2007 18:04, Rob Landley wrote:
> On Sunday 14 October 2007 8:45:03 pm Theodore Tso wrote:
> > > excuse for conflating different categories of devices in the first
> > > place.
> >
> > See the thinkpad Ultrabay drive example above.
>
> Last week I drove my laptop so deep into s
On Sunday 14 October 2007 8:45:03 pm Theodore Tso wrote:
> On Sun, Oct 14, 2007 at 06:45:44PM -0500, Rob Landley wrote:
> > I admit a certain amount of personal annoyance that once the SCSI
> > layer consumes a category of device (USB, SATA, PATA), they can
> > often _only_ be used by going through
Andrew Morton wrote:
> >
> > avoid buffer overflow when returning sense data.
> >
>
> That's really not enough information, sorry.
>
> > index 8b384fa..d32a4a9 100644
> > --- a/drivers/scsi/hptiop.c
> > +++ b/drivers/scsi/hptiop.c
> > @@ -375,8 +375,9 @@ static void hptiop_host_request_callback
>
84 matches
Mail list logo
