On Tue, 2007-01-02 at 11:58 +, Alan wrote:
...
>
> I'm sending this now rather than after running full test suites so that
> it can get the maximal testing in a short time. I'll be running tests on
> this after lunch.
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
>
> ---
On Sun, 31 Dec 2006 17:19:44 -0800 (PST), Linus Torvalds wrote:
> In order to not get in trouble with MADR ("Mothers Against Drunk
> Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
[...]
> At which point the first thing on any self-respecting geek's mind should
>
On Sun, 31 Dec 2006 17:19:44 -0800 (PST), Linus Torvalds wrote:
In order to not get in trouble with MADR (Mothers Against Drunk
Releases) I decided to cut the 2.6.20-rc3 release early rather than wait
[...]
At which point the first thing on any self-respecting geek's mind should
obviously
On Tue, 2007-01-02 at 11:58 +, Alan wrote:
...
I'm sending this now rather than after running full test suites so that
it can get the maximal testing in a short time. I'll be running tests on
this after lunch.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
---
Alan wrote:
Once combined mode is fixed not to abuse resources (and it originally
did it that way for a good reason I grant and am not criticising that) the
entire management for legacy mode, mixed mode and native mode resources
for an ATA device (including 0x170, 0x3F6 and other wacky magic)
> Thus, if you avoid calling pci_request_regions (as your patch does), you
> must manually provide the same guarantees that pci_request_regions
> provides to its callers.
pci_request_regions reserves only BAR4/BAR5 in legacy mode because of the
fact the resources are mashed and eventually
> 1) Programmatically reserve /all/ resources associated with
> our PCI device
> 2) Manually reserve resources associated with our PCI device,
> but are not listed in struct pci_dev.
Which it doesn't actually do. You reserve 0x1F0-0x1F7 but forget the
other register.
Or maybe this rephrase helps:
Regardless of how the IDE quirks have configured the PCI BARs, libata is
written to assume that /all/ struct pci_dev resources for a single PCI
device are reserved to the libata driver.
Thus, if you avoid calling pci_request_regions (as your patch does), you
Alan wrote:
2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
(a) I'm well of aware of this, and (b) that changes nothing.
I
> 2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
> libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You
never
Alan wrote:
Actually it didn't reserve BAR1 and BAR3 in legacy mode precisely because
of the PCI resource mismanagement in the old tree. So you take your pick.
I pick old bugs over new regressions.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Alan wrote:
We use BAR5 on two devices in legacy mode. Both of those reserve all the
other resources.
Translation: You want to hand-wave away an obvious regression that YOU
have created with your fix-to-a-fix.
It's not regressing anything.
False:
2.6.0 - 2.6.19: libata guarantees that
On Tue, 02 Jan 2007 16:32:01 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Jeff Garzik wrote:
> > * After your patch, the code explicitly calls pci_request_region() for
> > BARs 0-4, but never for BAR5.
>
> Without checking for failures, I might add.
The old code didn't reserve 1 or 3 at all
> > We use BAR5 on two devices in legacy mode. Both of those reserve all the
> > other resources.
>
> Translation: You want to hand-wave away an obvious regression that YOU
> have created with your fix-to-a-fix.
It's not regressing anything.
> Why INTRODUCE these 2.6.20 Alan-isms, if they are
Jeff Garzik wrote:
* After your patch, the code explicitly calls pci_request_region() for
BARs 0-4, but never for BAR5.
Without checking for failures, I might add.
Let's call that regression/obvious bug #4, because the previous code
actually CARED if the resource was reserved.
Alan wrote:
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
Yes, it's "silly" people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of. They only needed
to make two minor changes to make it
> > This is a silly complaint because the SFF layer in libata doesn't handle
> > this case yet anyway.
>
> Yes, it's "silly" people people use configurations you find inconvenient.
>
> At least one embedded x86 case cares, that I know of. They only needed
> to make two minor changes to make it
Alan wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one
On Tue, Jan 02, 2007 at 11:58:34AM +, Alan wrote:
> This is a slight variant on the patch I posted December 16th to fix
> libata combined mode handling. The only real change is that we now
> correctly also reserve BAR1,2,4. That is basically a neatness issue.
Thanks,
I can confirm that with
On Mon, 1 Jan 2007, Alan wrote:
>
> If you revert the commit you end with all the PCI resource tree breakage
> back
Which weren't a regression or anything new.
Alan: regressions are what we don't do. Ever. If your second patch is
found to have some other problems, we revert them both. It's
> Appears to work just fine here (compiles, boots and I'm
> typing this email :). The build warnings below seem new
> to me - but I guess they're harmless...
They are harmless. For the 2.6.21 code base they will go away as well.
-
To unsubscribe from this list: send the line "unsubscribe
On 1/2/07, Alan <[EMAIL PROTECTED]> wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one channel native
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one channel native
On 1/2/07, Alan [EMAIL PROTECTED] wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it
Appears to work just fine here (compiles, boots and I'm
typing this email :). The build warnings below seem new
to me - but I guess they're harmless...
They are harmless. For the 2.6.21 code base they will go away as well.
-
To unsubscribe from this list: send the line unsubscribe
On Mon, 1 Jan 2007, Alan wrote:
If you revert the commit you end with all the PCI resource tree breakage
back
Which weren't a regression or anything new.
Alan: regressions are what we don't do. Ever. If your second patch is
found to have some other problems, we revert them both. It's that
On Tue, Jan 02, 2007 at 11:58:34AM +, Alan wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Thanks,
I can confirm that with
Alan wrote:
This is a slight variant on the patch I posted December 16th to fix
libata combined mode handling. The only real change is that we now
correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
Yes, it's silly people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of. They only needed
to make two minor changes to make it work.
*It
Alan wrote:
This is a silly complaint because the SFF layer in libata doesn't handle
this case yet anyway.
Yes, it's silly people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of. They only needed
to make two minor changes to make it work.
Jeff Garzik wrote:
* After your patch, the code explicitly calls pci_request_region() for
BARs 0-4, but never for BAR5.
Without checking for failures, I might add.
Let's call that regression/obvious bug #4, because the previous code
actually CARED if the resource was reserved.
We use BAR5 on two devices in legacy mode. Both of those reserve all the
other resources.
Translation: You want to hand-wave away an obvious regression that YOU
have created with your fix-to-a-fix.
It's not regressing anything.
Why INTRODUCE these 2.6.20 Alan-isms, if they are going
On Tue, 02 Jan 2007 16:32:01 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Jeff Garzik wrote:
* After your patch, the code explicitly calls pci_request_region() for
BARs 0-4, but never for BAR5.
Without checking for failures, I might add.
The old code didn't reserve 1 or 3 at all let alone
Alan wrote:
We use BAR5 on two devices in legacy mode. Both of those reserve all the
other resources.
Translation: You want to hand-wave away an obvious regression that YOU
have created with your fix-to-a-fix.
It's not regressing anything.
False:
2.6.0 - 2.6.19: libata guarantees that
Alan wrote:
Actually it didn't reserve BAR1 and BAR3 in legacy mode precisely because
of the PCI resource mismanagement in the old tree. So you take your pick.
I pick old bugs over new regressions.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You
never
Alan wrote:
2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the
libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked
BAR 0 to BAR 3 of a compatibility mode controller
(a) I'm well of aware of this, and (b) that changes nothing.
I
Or maybe this rephrase helps:
Regardless of how the IDE quirks have configured the PCI BARs, libata is
written to assume that /all/ struct pci_dev resources for a single PCI
device are reserved to the libata driver.
Thus, if you avoid calling pci_request_regions (as your patch does), you
1) Programmatically reserve /all/ resources associated with
our PCI device
2) Manually reserve resources associated with our PCI device,
but are not listed in struct pci_dev.
Which it doesn't actually do. You reserve 0x1F0-0x1F7 but forget the
other register. BTW
Thus, if you avoid calling pci_request_regions (as your patch does), you
must manually provide the same guarantees that pci_request_regions
provides to its callers.
pci_request_regions reserves only BAR4/BAR5 in legacy mode because of the
fact the resources are mashed and eventually cleaare
Alan wrote:
Once combined mode is fixed not to abuse resources (and it originally
did it that way for a good reason I grant and am not criticising that) the
entire management for legacy mode, mixed mode and native mode resources
for an ATA device (including 0x170, 0x3F6 and other wacky magic)
On Mon, Jan 01, 2007 at 03:34:53PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 1 Jan 2007, Alan wrote:
> >
> > Want a fix Linus given Jeff is away ?
>
> Send it over, and please cc Alessandro and others that can test it. Things
> obviously aren't broken on _my_ machines ;)
Can I get a copy of
Cyrill V. Gorcnov wrote:
On Monday 01 January 2007 04:19, you wrote:
|
| In order to not get in trouble with MADR ("Mothers Against Drunk
| Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
| for midnight, because it's bound to be new years _somewhere_ out there.
On Mon, 1 Jan 2007, Alan wrote:
>
> Want a fix Linus given Jeff is away ?
Send it over, and please cc Alessandro and others that can test it. Things
obviously aren't broken on _my_ machines ;)
And if we end up having more problems related to this in -rc4, I'll just
revert both your fix and
> * I was unable to argue against Alan's logic behind
> 368c73d4f689dae0807d0a2aa74c61fd2b9b075f but I just don't like it.
> Regardless of whether or not this truly reflects how the PCI device is
> wired, it makes pci_request_regions() and similar resource handling code
> behave differently.
On Mon, 1 Jan 2007 12:13:08 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Jeff,
> what was the resolution to this one? Just revert the offending commit, or
> what?
If you revert the commit you end with all the PCI resource tree breakage
back
>
> We're about five weeks into the
Linus Torvalds wrote:
Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a
two-month release rather than the usual dragged-out three months, so I'd
like to get these regressions to be
Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a
two-month release rather than the usual dragged-out three months, so I'd
like to get these regressions to be actively fixed. By forcible
The final 2.6.20 release note should mention the following commit in some
way: "[NETFILTER]: Kconfig: improve conntrack selection"
It will break existing iptable setups without warning becausee it
disables all related .config options. If one says NO to the new
NF_CONNTRACK_ENABLED "Netfilter
On 1/1/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
In order to not get in trouble with MADR ("Mothers Against Drunk
Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
for midnight, because it's bound to be new years _somewhere_ out there. So
here's to a happy 2007 for
On Monday 01 January 2007 02:19, Linus Torvalds wrote:
> In order to not get in trouble with MADR ("Mothers Against Drunk
> Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
> for midnight, because it's bound to be new years _somewhere_ out there. So
> here's to a happy
On Monday 01 January 2007 10:45, you wrote:
| Cyrill V. Gorcnov wrote:
| > On Monday 01 January 2007 04:19, you wrote:
| > |
| > | In order to not get in trouble with MADR ("Mothers Against Drunk
| > | Releases") I decided to cut the 2.6.20-rc3 release early rather than
wait
| > |
On Monday 01 January 2007 10:45, you wrote:
| Cyrill V. Gorcnov wrote:
| On Monday 01 January 2007 04:19, you wrote:
| |
| | In order to not get in trouble with MADR (Mothers Against Drunk
| | Releases) I decided to cut the 2.6.20-rc3 release early rather than
wait
| | for
On Monday 01 January 2007 02:19, Linus Torvalds wrote:
In order to not get in trouble with MADR (Mothers Against Drunk
Releases) I decided to cut the 2.6.20-rc3 release early rather than wait
for midnight, because it's bound to be new years _somewhere_ out there. So
here's to a happy 2007 for
On 1/1/07, Linus Torvalds [EMAIL PROTECTED] wrote:
In order to not get in trouble with MADR (Mothers Against Drunk
Releases) I decided to cut the 2.6.20-rc3 release early rather than wait
for midnight, because it's bound to be new years _somewhere_ out there. So
here's to a happy 2007 for
The final 2.6.20 release note should mention the following commit in some
way: [NETFILTER]: Kconfig: improve conntrack selection
It will break existing iptable setups without warning becausee it
disables all related .config options. If one says NO to the new
NF_CONNTRACK_ENABLED Netfilter
Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a
two-month release rather than the usual dragged-out three months, so I'd
like to get these regressions to be actively fixed. By forcible
Linus Torvalds wrote:
Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a
two-month release rather than the usual dragged-out three months, so I'd
like to get these regressions to be
On Mon, 1 Jan 2007 12:13:08 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
If you revert the commit you end with all the PCI resource tree breakage
back
We're about five weeks into the 2.6.20-rc
* I was unable to argue against Alan's logic behind
368c73d4f689dae0807d0a2aa74c61fd2b9b075f but I just don't like it.
Regardless of whether or not this truly reflects how the PCI device is
wired, it makes pci_request_regions() and similar resource handling code
behave differently.
On Mon, 1 Jan 2007, Alan wrote:
Want a fix Linus given Jeff is away ?
Send it over, and please cc Alessandro and others that can test it. Things
obviously aren't broken on _my_ machines ;)
And if we end up having more problems related to this in -rc4, I'll just
revert both your fix and the
Cyrill V. Gorcnov wrote:
On Monday 01 January 2007 04:19, you wrote:
|
| In order to not get in trouble with MADR (Mothers Against Drunk
| Releases) I decided to cut the 2.6.20-rc3 release early rather than wait
| for midnight, because it's bound to be new years _somewhere_ out there. So
On Mon, Jan 01, 2007 at 03:34:53PM -0800, Linus Torvalds wrote:
On Mon, 1 Jan 2007, Alan wrote:
Want a fix Linus given Jeff is away ?
Send it over, and please cc Alessandro and others that can test it. Things
obviously aren't broken on _my_ machines ;)
Can I get a copy of the fix
On Monday 01 January 2007 04:19, you wrote:
|
| In order to not get in trouble with MADR ("Mothers Against Drunk
| Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
| for midnight, because it's bound to be new years _somewhere_ out there. So
| here's to a happy
On Sun, Dec 31, 2006 at 05:19:44PM -0800, Linus Torvalds wrote:
> Alexey Dobriyan (2):
> V4L/DVB (5012): Usbvision fix: It was using "&&" instead "&"
> fuse: fix typo
Second is from Thomas Hisch <[EMAIL PROTECTED]>, actually.
-
To unsubscribe from this list: send the line
On Sunday 31 December 2006 20:19, Linus Torvalds wrote:
>In order to not get in trouble with MADR ("Mothers Against Drunk
>Releases") I decided to cut the 2.6.20-rc3 release early rather than
> wait for midnight, because it's bound to be new years _somewhere_ out
> there. So here's to a happy 2007
In order to not get in trouble with MADR ("Mothers Against Drunk
Releases") I decided to cut the 2.6.20-rc3 release early rather than wait
for midnight, because it's bound to be new years _somewhere_ out there. So
here's to a happy 2007 for everybody.
The big thing at least for me personally
In order to not get in trouble with MADR (Mothers Against Drunk
Releases) I decided to cut the 2.6.20-rc3 release early rather than wait
for midnight, because it's bound to be new years _somewhere_ out there. So
here's to a happy 2007 for everybody.
The big thing at least for me personally is
On Sunday 31 December 2006 20:19, Linus Torvalds wrote:
In order to not get in trouble with MADR (Mothers Against Drunk
Releases) I decided to cut the 2.6.20-rc3 release early rather than
wait for midnight, because it's bound to be new years _somewhere_ out
there. So here's to a happy 2007 for
On Sun, Dec 31, 2006 at 05:19:44PM -0800, Linus Torvalds wrote:
Alexey Dobriyan (2):
V4L/DVB (5012): Usbvision fix: It was using instead
fuse: fix typo
Second is from Thomas Hisch [EMAIL PROTECTED], actually.
-
To unsubscribe from this list: send the line unsubscribe
On Monday 01 January 2007 04:19, you wrote:
|
| In order to not get in trouble with MADR (Mothers Against Drunk
| Releases) I decided to cut the 2.6.20-rc3 release early rather than wait
| for midnight, because it's bound to be new years _somewhere_ out there. So
| here's to a happy 2007
72 matches
Mail list logo
