On Tue, Jan 08, 2008 at 08:10:42PM -0800, Andrew Morton wrote:
[...]
> I must say that the number of bugs which actually go away when the user
> stops using nvidia/fglrx/ndiswrapper/etc is a small minority.
[...]
> But people who think that removing the nvidia driver will
> magically fix that
On Tue, 08 Jan 2008 23:01:07 -0500 [EMAIL PROTECTED] wrote:
> On Mon, 07 Jan 2008 16:19:30 MST, Matthew Wilcox said:
> > On Mon, Jan 07, 2008 at 06:04:25PM -0500, [EMAIL PROTECTED] wrote:
> > > Theoretically, at least. Sometimes, in the real world, other constraints
> > > enter into it...
> >
>
On Mon, 07 Jan 2008 16:19:30 MST, Matthew Wilcox said:
> So you're saying that you can't find reliable ways to reproduce problems
> on demand? Those are some of the lower quality bug reports, so I don't
> think we're losing much by having you not report them.
And in the next e-mail in my lkml
On Mon, 07 Jan 2008 16:19:30 MST, Matthew Wilcox said:
> On Mon, Jan 07, 2008 at 06:04:25PM -0500, [EMAIL PROTECTED] wrote:
> > Theoretically, at least. Sometimes, in the real world, other constraints
> > enter into it...
>
> So you're saying that you can't find reliable ways to reproduce
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> These things *are* fairly rare (most bugs by _far_ are of the trivial
> stupid kind), but some of those things can stay around for a long
> time, and it can take months of different people reporting similar
> problems until somebody finally puts
On Tue, 8 Jan 2008, Stefan Richter wrote:
> Matthew Wilcox wrote:
> > So you're saying that you can't find reliable ways to reproduce problems
> > on demand? Those are some of the lower quality bug reports,
>
> Or those are the more difficult problems.
Indeed. If it's some race condition, or
* James Bottomley <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2008-01-06 at 17:12 +0100, Ingo Molnar wrote:
> > * James Bottomley <[EMAIL PROTECTED]> wrote:
> >
> > > > The reproducer came to you via Peter Osterlund who has never
> > > > authored a single drivers/scsi/ commit before (according to
Matthew Wilcox wrote:
> So you're saying that you can't find reliable ways to reproduce problems
> on demand? Those are some of the lower quality bug reports,
Or those are the more difficult problems.
--
Stefan Richter
-=-==--- ---= -=---
http://arcgraph.de/sr/
--
To unsubscribe from this
Matthew Wilcox wrote:
So you're saying that you can't find reliable ways to reproduce problems
on demand? Those are some of the lower quality bug reports,
Or those are the more difficult problems.
--
Stefan Richter
-=-==--- ---= -=---
http://arcgraph.de/sr/
--
To unsubscribe from this
* James Bottomley [EMAIL PROTECTED] wrote:
On Sun, 2008-01-06 at 17:12 +0100, Ingo Molnar wrote:
* James Bottomley [EMAIL PROTECTED] wrote:
The reproducer came to you via Peter Osterlund who has never
authored a single drivers/scsi/ commit before (according to git-log)
and
On Tue, 8 Jan 2008, Stefan Richter wrote:
Matthew Wilcox wrote:
So you're saying that you can't find reliable ways to reproduce problems
on demand? Those are some of the lower quality bug reports,
Or those are the more difficult problems.
Indeed. If it's some race condition, or
* Linus Torvalds [EMAIL PROTECTED] wrote:
These things *are* fairly rare (most bugs by _far_ are of the trivial
stupid kind), but some of those things can stay around for a long
time, and it can take months of different people reporting similar
problems until somebody finally puts two and
On Mon, 07 Jan 2008 16:19:30 MST, Matthew Wilcox said:
On Mon, Jan 07, 2008 at 06:04:25PM -0500, [EMAIL PROTECTED] wrote:
Theoretically, at least. Sometimes, in the real world, other constraints
enter into it...
So you're saying that you can't find reliable ways to reproduce problems
on
On Mon, 07 Jan 2008 16:19:30 MST, Matthew Wilcox said:
So you're saying that you can't find reliable ways to reproduce problems
on demand? Those are some of the lower quality bug reports, so I don't
think we're losing much by having you not report them.
And in the next e-mail in my lkml
On Tue, 08 Jan 2008 23:01:07 -0500 [EMAIL PROTECTED] wrote:
On Mon, 07 Jan 2008 16:19:30 MST, Matthew Wilcox said:
On Mon, Jan 07, 2008 at 06:04:25PM -0500, [EMAIL PROTECTED] wrote:
Theoretically, at least. Sometimes, in the real world, other constraints
enter into it...
So you're
On Tue, Jan 08, 2008 at 08:10:42PM -0800, Andrew Morton wrote:
[...]
I must say that the number of bugs which actually go away when the user
stops using nvidia/fglrx/ndiswrapper/etc is a small minority.
[...]
But people who think that removing the nvidia driver will
magically fix that
On Mon, Jan 07, 2008 at 06:04:25PM -0500, [EMAIL PROTECTED] wrote:
> Theoretically, at least. Sometimes, in the real world, other constraints
> enter into it...
So you're saying that you can't find reliable ways to reproduce problems
on demand? Those are some of the lower quality bug reports,
On Mon, 07 Jan 2008 14:37:17 MST, Matthew Wilcox said:
> If you can reproduce a bug reliably, you can reproduce it without the
> nvidia module loaded.
Theoretically, at least. Sometimes, in the real world, other constraints
enter into it...
You're welcome to stop by and figure out why (I've
> Personally, I've lost count of the number of times I've *not* reported a
> bug/oops just because of the "NVidia users this means you" statement, only
> to have the exact same issue reported several weeks/months later by somebody
> who's able to replicate it with an untainted kernel.
If you can
> Personally, I've lost count of the number of times I've *not* reported a
> bug/oops just because of the "NVidia users this means you" statement, only
> to have the exact same issue reported several weeks/months later by somebody
> who's able to replicate it with an untainted kernel.
And I've
On Sun, 06 Jan 2008 22:08:13 +0100, Willy Tarreau said:
> even slightly annoying, we never get it. Have you noticed the number of
> "me too" on the list ? Users find any sort of excuse for not having filed
> a report in the first time, but are still willing to confirm another
> one's bug. That's
> "Stefan" == Stefan Richter <[EMAIL PROTECTED]> writes:
Stefan> John Stoffel wrote:
>> The question to me really revolves around how do you automate the
>> process in a transparent manner so that people don't have to change
>> much how they interact with lkml.
Stefan> I think the more
John Stoffel wrote:
> The question to me really revolves around how do you automate the
> process in a transparent manner so that people don't have to change
> much how they interact with lkml.
I think the more important questions are:
- Are there people who know how to get reports to
I'll agree with what Willy wrote here, Bugzilla is a pain to use, you
can't just dump an email into it and have it captured. I think we
should be looking at something more like 'WebRT' which is an *issue*
tracker software. But that too might be too heavy weight and too
noisy as well.
And
I'll agree with what Willy wrote here, Bugzilla is a pain to use, you
can't just dump an email into it and have it captured. I think we
should be looking at something more like 'WebRT' which is an *issue*
tracker software. But that too might be too heavy weight and too
noisy as well.
And
John Stoffel wrote:
The question to me really revolves around how do you automate the
process in a transparent manner so that people don't have to change
much how they interact with lkml.
I think the more important questions are:
- Are there people who know how to get reports to
Stefan == Stefan Richter [EMAIL PROTECTED] writes:
Stefan John Stoffel wrote:
The question to me really revolves around how do you automate the
process in a transparent manner so that people don't have to change
much how they interact with lkml.
Stefan I think the more important questions
On Sun, 06 Jan 2008 22:08:13 +0100, Willy Tarreau said:
even slightly annoying, we never get it. Have you noticed the number of
me too on the list ? Users find any sort of excuse for not having filed
a report in the first time, but are still willing to confirm another
one's bug. That's
Personally, I've lost count of the number of times I've *not* reported a
bug/oops just because of the NVidia users this means you statement, only
to have the exact same issue reported several weeks/months later by somebody
who's able to replicate it with an untainted kernel.
And I've lost
Personally, I've lost count of the number of times I've *not* reported a
bug/oops just because of the NVidia users this means you statement, only
to have the exact same issue reported several weeks/months later by somebody
who's able to replicate it with an untainted kernel.
If you can
On Mon, 07 Jan 2008 14:37:17 MST, Matthew Wilcox said:
If you can reproduce a bug reliably, you can reproduce it without the
nvidia module loaded.
Theoretically, at least. Sometimes, in the real world, other constraints
enter into it...
You're welcome to stop by and figure out why (I've sunk
On Mon, Jan 07, 2008 at 06:04:25PM -0500, [EMAIL PROTECTED] wrote:
Theoretically, at least. Sometimes, in the real world, other constraints
enter into it...
So you're saying that you can't find reliable ways to reproduce problems
on demand? Those are some of the lower quality bug reports, so
On Sun, Jan 06, 2008 at 10:08:13PM +0100, Willy Tarreau wrote:
> On Sun, Jan 06, 2008 at 09:58:02PM +0200, Adrian Bunk wrote:
> > On Sun, Jan 06, 2008 at 08:10:44PM +0100, Willy Tarreau wrote:
> > > I, as an end user of ntpd, have been harrassed to use it to get an
> > > ntp bug reported "because
On Sun, Jan 06, 2008 at 09:58:02PM +0200, Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 08:10:44PM +0100, Willy Tarreau wrote:
> > I, as an end user of ntpd, have been harrassed to use it to get an
> > ntp bug reported "because by mail it would get lost". What complicated
>
> Noone knows how many
* Stefan Richter <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > If lkml traffic is too big then i'd suggest to set up email
> > filters to separate out mails that have 'SCSI' in their subject line
>
> Good idea. Minor flaw: If somebody forgets to Cc LSML, he might also
> forget to put
On Sun, Jan 06, 2008 at 08:10:44PM +0100, Willy Tarreau wrote:
> On Sun, Jan 06, 2008 at 08:56:25PM +0200, Adrian Bunk wrote:
> > On Sun, Jan 06, 2008 at 07:34:02PM +0100, Willy Tarreau wrote:
> > >...
> > > As to using bugzilla for bug tracking... Well, I agree that bug
> > > tracking is
On Sun, Jan 06, 2008 at 08:56:25PM +0200, Adrian Bunk wrote:
> On Sun, Jan 06, 2008 at 07:34:02PM +0100, Willy Tarreau wrote:
> >...
> > As to using bugzilla for bug tracking... Well, I agree that bug
> > tracking is important when you work on multiple problems at once.
> > But bugzilla should be
On Sun, Jan 06, 2008 at 07:34:02PM +0100, Willy Tarreau wrote:
>...
> As to using bugzilla for bug tracking... Well, I agree that bug
> tracking is important when you work on multiple problems at once.
> But bugzilla should be the developer's tool, not the end user's.
> That means that it should
On Sun, 2008-01-06 at 10:44 -0800, Linus Torvalds wrote:
>
> On Sun, 6 Jan 2008, Linus Torvalds wrote:
> >
> > That said:
> >
> > > pktcdvd shouldn't be mucking with the size of the underlying CD/DVD ...
> >
> > I'm not sure if it should be mucking with the size or not, but it
> > definitely
On Sun, 6 Jan 2008, Linus Torvalds wrote:
>
> That said:
>
> > pktcdvd shouldn't be mucking with the size of the underlying CD/DVD ...
>
> I'm not sure if it should be mucking with the size or not, but it
> definitely shouldn't be mucking with the block-size, because that can
> indeed cause
On Sun, Jan 06, 2008 at 11:36:23AM -0600, James Bottomley wrote:
> On Sun, 2008-01-06 at 10:11 -0700, Matthew Wilcox wrote:
> > If there's willingness to change, I'm willing to put some effort into
> > moving us to a bug tracking system that fits our workflow better than
> > bugzilla. But if that
On Sun, 6 Jan 2008, James Bottomley wrote:
> > index 993f78c..6a20da9 100644
> > --- a/fs/block_dev.c
> > +++ b/fs/block_dev.c
> > @@ -1191,6 +1191,7 @@ static int do_open(struct block_device *bdev, struct
> > file *file, int for_part)
> > }
> > if
On Sun, 2008-01-06 at 10:11 -0700, Matthew Wilcox wrote:
> On Sun, Jan 06, 2008 at 09:20:45AM -0600, James Bottomley wrote:
> > This bug was actually hidden in bugzilla for ages, where Matthew Wilcox
> > was trying to deal with it on his own. The first I heard of it (apart
> > from a linux-scsi
Ingo Molnar wrote:
> If lkml traffic is too big then i'd suggest to set up email
> filters to separate out mails that have 'SCSI' in their subject line
Good idea. Minor flaw: If somebody forgets to Cc LSML, he might also
forget to put SCSI or scsi into the Subject.
> or body.
This yields
On Sun, Jan 06, 2008 at 09:20:45AM -0600, James Bottomley wrote:
> This bug was actually hidden in bugzilla for ages, where Matthew Wilcox
> was trying to deal with it on his own. The first I heard of it (apart
> from a linux-scsi question on 13 November, when regrettably, I was busy
> with other
On Sun, 2008-01-06 at 17:12 +0100, Ingo Molnar wrote:
> * James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > > The reproducer came to you via Peter Osterlund who has never
> > > authored a single drivers/scsi/ commit before (according to git-log)
> > > and who (and here i'm out on a limb
On Sun, Jan 06, 2008 at 02:55:07PM +0100, Thomas Meyer wrote:
> This is the correct setup to trigger the bug. And the commit
> 6f5391c283d7fdcf24bf40786ea79061919d1e1d has nothing to do with this
> bug. It was bad luck that i couldn't trigger the bug with said commit
> reverted (in my tests, the
On Sun, 2008-01-06 at 18:19 +0200, Boaz Harrosh wrote:
> On Sun, Jan 06 2008 at 5:43 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >
> > This all still leaves the question unanswered why that commit
> > 6f5391c283d7fdcf24bf40786ea79061919d1e1d changed any behaviour at all.
> >
On Sun, Jan 06 2008 at 5:43 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> This all still leaves the question unanswered why that commit
> 6f5391c283d7fdcf24bf40786ea79061919d1e1d changed any behaviour at all.
> Because the thing that Peter is describing has nothing to do with any
>
* James Bottomley <[EMAIL PROTECTED]> wrote:
> > The reproducer came to you via Peter Osterlund who has never
> > authored a single drivers/scsi/ commit before (according to git-log)
> > and who (and here i'm out on a limb guessing it) does not even
> > follow [EMAIL PROTECTED]
> >
> > this
On Sun, 2008-01-06 at 17:45 +0200, Adrian Bunk wrote:
> Bugzilla for tracking and mailing lists for discussing are not mutually
> exclusive.
I didn't ever say they were. What I said was we needed the work flow on
the mailing lists.
> What about asking the Bugzilla admins to set the default
On Sun, Jan 06, 2008 at 09:20:45AM -0600, James Bottomley wrote:
>
> On Sun, 2008-01-06 at 15:47 +0100, Ingo Molnar wrote:
> > * James Bottomley <[EMAIL PROTECTED]> wrote:
> >
> > > > I can repeat this bug, both with and without the scsi patch that is
> > > > claimed to make a difference, both
On Sun, 2008-01-06 at 15:47 +0100, Ingo Molnar wrote:
> * James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > > I can repeat this bug, both with and without the scsi patch that is
> > > claimed to make a difference, both with an external USB drive and an
> > > internal IDE drive.
> > >
> > > To
On Sun, 6 Jan 2008, James Bottomley wrote:
On Sat, 2008-01-05 at 19:43 -0800, Linus Torvalds wrote:
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 993f78c..6a20da9 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1191,6 +1191,7 @@ static int do_open(struct block_device *bdev, struct
* James Bottomley <[EMAIL PROTECTED]> wrote:
> > I can repeat this bug, both with and without the scsi patch that is
> > claimed to make a difference, both with an external USB drive and an
> > internal IDE drive.
> >
> > To repeat:
> >
> > 1. Start with an empty drive.
> > 2. pktsetup 0
On Sat, 2008-01-05 at 19:43 -0800, Linus Torvalds wrote:
> fs/block_dev.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/fs/block_dev.c b/fs/block_dev.c
> index 993f78c..6a20da9 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -1191,6 +1191,7 @@ static int
On Sat, 2008-01-05 at 19:43 -0800, Linus Torvalds wrote:
> This all still leaves the question unanswered why that commit
> 6f5391c283d7fdcf24bf40786ea79061919d1e1d changed any behaviour at
> all.
> Because the thing that Peter is describing has nothing to do with any
> low-level drivers
On Sun, 2008-01-06 at 03:55 +0100, Peter Osterlund wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2 Jan 2008, James Bottomley wrote:
> >
> > > Look at the taxonomy of the bug. This is the form of the error:
> > >
> > > buffer I/O error on device sr0, logical block 20304
> >
Hi,
I confirm Peter's observations:
> To repeat:
>
> 1. Start with an empty drive.
> 2. pktsetup 0 /dev/scd0
> 3. Insert a CD containing an isofs filesystem.
> 4. mount /dev/pktcdvd/0 /mnt/tmp
> 5. umount /mnt/tmp
> 6. Press the eject button.
> 7. Insert a DVD containing a
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Does a patch like this change the behaviour you see at all?
> + bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
It does fix my scenario, with the trivial fix of adding bdev-> at the
beginning of that line, ie:
diff --git
Linus Torvalds [EMAIL PROTECTED] writes:
Does a patch like this change the behaviour you see at all?
+ bd_inode-i_size = (loff_t)get_capacity(disk)9;
It does fix my scenario, with the trivial fix of adding bdev- at the
beginning of that line, ie:
diff --git
Hi,
I confirm Peter's observations:
To repeat:
1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3. Insert a CD containing an isofs filesystem.
4. mount /dev/pktcdvd/0 /mnt/tmp
5. umount /mnt/tmp
6. Press the eject button.
7. Insert a DVD containing a non-writable
On Sun, 2008-01-06 at 03:55 +0100, Peter Osterlund wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
On Wed, 2 Jan 2008, James Bottomley wrote:
Look at the taxonomy of the bug. This is the form of the error:
buffer I/O error on device sr0, logical block 20304
attempt to access
On Sat, 2008-01-05 at 19:43 -0800, Linus Torvalds wrote:
This all still leaves the question unanswered why that commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d changed any behaviour at
all.
Because the thing that Peter is describing has nothing to do with any
low-level drivers
On Sat, 2008-01-05 at 19:43 -0800, Linus Torvalds wrote:
fs/block_dev.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 993f78c..6a20da9 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1191,6 +1191,7 @@ static int
* James Bottomley [EMAIL PROTECTED] wrote:
I can repeat this bug, both with and without the scsi patch that is
claimed to make a difference, both with an external USB drive and an
internal IDE drive.
To repeat:
1. Start with an empty drive.
2. pktsetup 0 /dev/scd0
3.
On Sun, 6 Jan 2008, James Bottomley wrote:
On Sat, 2008-01-05 at 19:43 -0800, Linus Torvalds wrote:
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 993f78c..6a20da9 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1191,6 +1191,7 @@ static int do_open(struct block_device *bdev, struct
On Sun, 2008-01-06 at 15:47 +0100, Ingo Molnar wrote:
* James Bottomley [EMAIL PROTECTED] wrote:
I can repeat this bug, both with and without the scsi patch that is
claimed to make a difference, both with an external USB drive and an
internal IDE drive.
To repeat:
1.
On Sun, Jan 06, 2008 at 09:20:45AM -0600, James Bottomley wrote:
On Sun, 2008-01-06 at 15:47 +0100, Ingo Molnar wrote:
* James Bottomley [EMAIL PROTECTED] wrote:
I can repeat this bug, both with and without the scsi patch that is
claimed to make a difference, both with an external
On Sun, 2008-01-06 at 17:45 +0200, Adrian Bunk wrote:
Bugzilla for tracking and mailing lists for discussing are not mutually
exclusive.
I didn't ever say they were. What I said was we needed the work flow on
the mailing lists.
What about asking the Bugzilla admins to set the default owner
On Sun, 2008-01-06 at 18:19 +0200, Boaz Harrosh wrote:
On Sun, Jan 06 2008 at 5:43 +0200, Linus Torvalds [EMAIL PROTECTED] wrote:
This all still leaves the question unanswered why that commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d changed any behaviour at all.
Because the thing
On Sun, Jan 06, 2008 at 02:55:07PM +0100, Thomas Meyer wrote:
This is the correct setup to trigger the bug. And the commit
6f5391c283d7fdcf24bf40786ea79061919d1e1d has nothing to do with this
bug. It was bad luck that i couldn't trigger the bug with said commit
reverted (in my tests, the
On Sun, 2008-01-06 at 17:12 +0100, Ingo Molnar wrote:
* James Bottomley [EMAIL PROTECTED] wrote:
The reproducer came to you via Peter Osterlund who has never
authored a single drivers/scsi/ commit before (according to git-log)
and who (and here i'm out on a limb guessing it) does
On Sun, Jan 06, 2008 at 09:20:45AM -0600, James Bottomley wrote:
This bug was actually hidden in bugzilla for ages, where Matthew Wilcox
was trying to deal with it on his own. The first I heard of it (apart
from a linux-scsi question on 13 November, when regrettably, I was busy
with other
Ingo Molnar wrote:
If lkml traffic is too big then i'd suggest to set up email
filters to separate out mails that have 'SCSI' in their subject line
Good idea. Minor flaw: If somebody forgets to Cc LSML, he might also
forget to put SCSI or scsi into the Subject.
or body.
This yields false
On Sun, 2008-01-06 at 10:11 -0700, Matthew Wilcox wrote:
On Sun, Jan 06, 2008 at 09:20:45AM -0600, James Bottomley wrote:
This bug was actually hidden in bugzilla for ages, where Matthew Wilcox
was trying to deal with it on his own. The first I heard of it (apart
from a linux-scsi
On Sun, 6 Jan 2008, James Bottomley wrote:
index 993f78c..6a20da9 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1191,6 +1191,7 @@ static int do_open(struct block_device *bdev, struct
file *file, int for_part)
}
if
On Sun, Jan 06, 2008 at 11:36:23AM -0600, James Bottomley wrote:
On Sun, 2008-01-06 at 10:11 -0700, Matthew Wilcox wrote:
If there's willingness to change, I'm willing to put some effort into
moving us to a bug tracking system that fits our workflow better than
bugzilla. But if that effort
On Sun, 6 Jan 2008, Linus Torvalds wrote:
That said:
pktcdvd shouldn't be mucking with the size of the underlying CD/DVD ...
I'm not sure if it should be mucking with the size or not, but it
definitely shouldn't be mucking with the block-size, because that can
indeed cause huge
On Sun, 2008-01-06 at 10:44 -0800, Linus Torvalds wrote:
On Sun, 6 Jan 2008, Linus Torvalds wrote:
That said:
pktcdvd shouldn't be mucking with the size of the underlying CD/DVD ...
I'm not sure if it should be mucking with the size or not, but it
definitely shouldn't be
On Sun, Jan 06, 2008 at 08:56:25PM +0200, Adrian Bunk wrote:
On Sun, Jan 06, 2008 at 07:34:02PM +0100, Willy Tarreau wrote:
...
As to using bugzilla for bug tracking... Well, I agree that bug
tracking is important when you work on multiple problems at once.
But bugzilla should be the
On Sun, Jan 06, 2008 at 08:10:44PM +0100, Willy Tarreau wrote:
On Sun, Jan 06, 2008 at 08:56:25PM +0200, Adrian Bunk wrote:
On Sun, Jan 06, 2008 at 07:34:02PM +0100, Willy Tarreau wrote:
...
As to using bugzilla for bug tracking... Well, I agree that bug
tracking is important when you
* Stefan Richter [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
If lkml traffic is too big then i'd suggest to set up email
filters to separate out mails that have 'SCSI' in their subject line
Good idea. Minor flaw: If somebody forgets to Cc LSML, he might also
forget to put SCSI or
On Sun, Jan 06, 2008 at 09:58:02PM +0200, Adrian Bunk wrote:
On Sun, Jan 06, 2008 at 08:10:44PM +0100, Willy Tarreau wrote:
I, as an end user of ntpd, have been harrassed to use it to get an
ntp bug reported because by mail it would get lost. What complicated
Noone knows how many thousand
On Sat, 6 Jan 2008, Peter Osterlund wrote:
>
> The problem is that pktcdvd opens the cd device in non-blocking mode
> when pktsetup is run, and doesn't close it again until pktsetup -d
> is run. The effect is that if you meanwhile open the cd device,
> blkdev.c:do_open() doesn't call
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Wed, 2 Jan 2008, James Bottomley wrote:
>
> > Look at the taxonomy of the bug. This is the form of the error:
> >
> > buffer I/O error on device sr0, logical block 20304
> > attempt to access beyond end of device
> > sr0: rw=0, want=81224,
Linus Torvalds [EMAIL PROTECTED] writes:
On Wed, 2 Jan 2008, James Bottomley wrote:
Look at the taxonomy of the bug. This is the form of the error:
buffer I/O error on device sr0, logical block 20304
attempt to access beyond end of device
sr0: rw=0, want=81224, limit=40944
The
On Sat, 6 Jan 2008, Peter Osterlund wrote:
The problem is that pktcdvd opens the cd device in non-blocking mode
when pktsetup is run, and doesn't close it again until pktsetup -d
is run. The effect is that if you meanwhile open the cd device,
blkdev.c:do_open() doesn't call bd_set_size()
On Wed, 2 Jan 2008, James Bottomley wrote:
> >
> > To say that another way:
> >
> > "the code is functionally equivalent, EXCEPT IT ISN'T, and it's
> > known to be broken".
> >
> > wouldn't you say my version is more honest and correct?
>
> No. Just because a bug appears when a
On Wed, 2008-01-02 at 12:45 -0800, Linus Torvalds wrote:
>
> On Wed, 2 Jan 2008, James Bottomley wrote:
> >
> > OK ... I'll revert it. However, I still think it's the wrong course of
> > action, because as far as my analysis goes, this code is functionally
> > equivalent to what went before
On Wed, Jan 02, 2008 at 12:49:32PM -0800, Linus Torvalds wrote:
> Maybe it's not that one suspicious test. Maybe it's somethign else. But
> that commit was confirmed to break something, almost two months ago. You
> guys seem to be in denial, and saying "it didn't change anything".
>
> And no,
On Wed, 2 Jan 2008, Christoph Hellwig wrote:
>
> I think you misunderstood Matthew here. REQ_TYPE_BLOCK_PC is indeed
> used by any kind of SG_IO or similar passthrough no matter where it
> originates. And exactly because REQ_TYPE_BLOCK_PC are entirely passthru
> the actual driver (sd, sr or
On Wed, 2 Jan 2008, James Bottomley wrote:
>
> OK ... I'll revert it. However, I still think it's the wrong course of
> action, because as far as my analysis goes, this code is functionally
> equivalent to what went before with the exception that we now rely on
> the request->cmd_type
On Wed, Jan 02, 2008 at 11:57:10AM -0800, Linus Torvalds wrote:
> On Wed, 2 Jan 2008, Matthew Wilcox wrote:
> >
> > sd_done and sr_done are called for REQ_TYPE_FS -- if the request comes
> > in through one of the SG interfaces, we call scsi_setup_blk_pc_cmnd()
> > which sets the ->done callback
On Wed, Jan 02, 2008 at 11:57:10AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 2 Jan 2008, Matthew Wilcox wrote:
> >
> > sd_done and sr_done are called for REQ_TYPE_FS -- if the request comes
> > in through one of the SG interfaces, we call scsi_setup_blk_pc_cmnd()
> > which sets the ->done
On Wed, 2008-01-02 at 12:40 -0700, Matthew Wilcox wrote:
> On Wed, Jan 02, 2008 at 11:19:14AM -0800, Linus Torvalds wrote:
> > It's totally immaterial if we have one reporter or many. The fact is, that
> > thing has been outstanding for almost two months now. The root cause is
> > almost
On Wed, 2 Jan 2008, Matthew Wilcox wrote:
>
> sd_done and sr_done are called for REQ_TYPE_FS -- if the request comes
> in through one of the SG interfaces, we call scsi_setup_blk_pc_cmnd()
> which sets the ->done callback to scsi_blk_pc_done.
Why do you think that REQ_TYPE_BLOCK_PC has
On Wed, Jan 02, 2008 at 11:19:14AM -0800, Linus Torvalds wrote:
> It's totally immaterial if we have one reporter or many. The fact is, that
> thing has been outstanding for almost two months now. The root cause is
> almost certainly known (and Matthew is apparently even aware of it), but
I
On Wed, 2 Jan 2008, James Bottomley wrote:
>
> I disagree with this. We only have one reporter of a problem and it
> appears to be some type of obscure interaction with pktdvd which no-one
> can track down (although it's not really helped by the reporter not
> being very responsive).
It's
On Wed, 2008-01-02 at 17:25 +0100, Ingo Molnar wrote:
> revert commit:
>
> commit 6f5391c283d7fdcf24bf40786ea79061919d1e1d
> Author: Matthew Wilcox <[EMAIL PROTECTED]>
> Date: Tue Sep 25 12:42:04 2007 -0400
>
> [SCSI] Get rid of scsi_cmnd->done
>
> this is a
1 - 100 of 114 matches
Mail list logo
